Published on: 2016-07-31T05:18:18+00:00
In a Bitcoin developers' mailing list discussion, Paul Sztorc proposed the implementation of "alerts" to address the problem of transactions referencing block content on a "pretender block." However, there is still an issue with constructing a block that cannot be proven invalid. While it is possible to prove the invalidity of a transaction within a well-formed block, there is no way to prove that a block is not well-formed. This could result in a valid block with some transactions being withheld until it becomes stale, making it impossible for full nodes and miners to accept it without knowing all the transactions in the block.The proposed solution to this problem is for users to demand the full block from attackers. However, this opens up the possibility of attackers launching denial-of-service attacks by providing bogus incomplete-block claims. This is particularly problematic for users who rely on Simplified Payment Verification (SPV) and do not have the bandwidth to run a full node.In another discussion on the bitcoin-dev mailing list, Paul Sztorc expressed confusion about how segwit (Segregated Witness) would help in this context. Another member of the community, Bryan, shared a link to discussions on the topic that took place on the bitcoin-core-dev chat channel in December 2015. Although the link is currently unavailable, it may have contained useful information regarding the potential benefits of segwit.The idea of incentivizing users to provide proof of invalid block content dates back to Satoshi's whitepaper. This concept would be particularly valuable for Alice, who is running an SPV client. Paul Sztorc suggests that implementing "alerts" would be relatively straightforward and offers details on how this could be achieved using a new OP code. He also acknowledges that implementing "fraud proofs" (as they are now called) would require significant engineering work and asks if anyone can direct him to the problems associated with this approach.Sztorc outlines a proposed solution involving the creation of an OP Code called "OP FraudProof." This OP Code would include arguments such as a block number, block header, and merkle path from the header to an invalid transaction. In practice, this OP Code can be used in a transaction where Alice provides 1 BTC and X provides 0.2 BTC. If X signs the transaction, Alice assumes the block is invalid and stops offering to buy fraud proofs for it. If X does not sign, Alice gets her money back plus 0.2 BTC from Eric for wasting her time. Sztorc notes that the definition of an "invalid transaction" could refer to either a script that fails or a double-spend.While acknowledging that implementing this solution is not a simple task, Sztorc does not consider it to be a significant engineering overhaul. He also mentions that segwit may have a role in supporting this solution, although he does not fully understand why.
Updated on: 2023-08-01T18:47:59.873532+00:00