Published on: 2016-09-19T19:53:46+00:00
In an email conversation, Peter Todd corrected his suggestion regarding the catch-up formula and provided a new probability formula to determine whether honest miners can build a chain N blocks long before dishonest miners. The new formula is CDF[Erlang(N, q) - Erlang(N, 1-q), 0]. He also offered assistance with numeric calculations. A digital signature was attached to the email.On bitcoin-dev, Tom Harding pointed out that the probability of dishonest miners finding N blocks in a row immediately differs from the probability of them building a chain N blocks long, considering the random walk. In response, Peter Todd suggested using Satoshi's formula from bitcoin.pdf, section 11, which yields different results. If a timestamp contains only a block height instead of actual block headers, there is no risk if the Bitcoin node is in sync with the most-work chain. However, if the verifier is not in sync, an attacker can sybil attack the verifier's node to make them believe that blocks with invalid timestamps are part of the most-work chain. This case is similar to a payee being sybil attacked, requiring the same analysis. It is important to note that timestamps should not include block headers of allegedly confirming blocks, as this is a weak proof due to the ease of creating a block. OpenTimestamps does not include block headers in timestamps, but it is worth mentioning explicitly.In a message on bitcoin-dev, Peter Todd discusses the probability of dishonest miners finding N blocks in a row immediately. He explains the need for the probability of building a chain N blocks long, taking the random-walk into account. He suggests using Satoshi's formula from bitcoin.pdf, section 11, which produces different results compared to the previous method. A q value of .5 is considered totally insecure as both factions will eventually possess a chain of length N anchored at x during the wild reorg melee.The discussion revolves around timestamps in OpenTimestamps. One person suggests considering earlier blocks, while another argues that timestamps are proofs of existence prior to a specific time and cannot have a "wrong order" in timestamp proofs. OpenTimestamps verifies plausible dates for various use cases, such as timestamped git commits. An example is provided with the date on the git commit, a date for the PGP signature, and a third date for the Bitcoin timestamp. Peter Todd's contact information is given at the end of the email.The author proposes a scheme for interpreting the nTime fields in block headers for timestamping purposes using the Bitcoin blockchain. The purpose is to provide evidence of a message's existence before a certain point in time. The algorithm defines time T as the maximum nTime out of the N blocks confirming the timestamp, including the first block committing the timestamp. Max_offset represents the maximum expected nTime offset from an honest miner. Dishonest miners can create an invalid timestamp if they find all N blocks, but if an honest miner finds any block, the nTime field will be set correctly. UI considerations include not displaying timestamps until local time surpasses the timestamp and rounding up the timestamp to the nearest day for display.
Updated on: 2023-08-01T19:01:15.049485+00:00