Published on: 2020-08-02T14:22:30+00:00
In an email exchange, ZmnSCPxj discussed the issue with SCRIPT re-evaluation and reorgs. They explained that reorgs cause nodes to do more processing even with Floating-point Nakamoto Consensus. This is because a node can still observe a reorg if it first receives a lower-scored block before a higher-scored block. This increases the processing load on validating fullnodes and prevents pruning from working for them.Miners can also mount a DoS on validating fullnodes with `OP_PUBREF` and Floating-Point Nakamoto Consensus by re-mining the same block and broadcasting it if it has a higher score than the previous chain tip. This locks the blockchain and increases the load on fullnodes, which have to re-validate uses of `OP_PUBREF` that might refer to the chain tip.ZmnSCPxj responded to Michael's suggestion for solving re-orgs in a different way by saying "Hard NAK." They pointed out important problems with Michael's proposal, such as encouraging address reuse, hurting fungibility and privacy, preventing pruning, requiring the creation of another index to previous block data, increasing requirements on fullnodes, and needing SCRIPT to be re-evaluated on transactions arriving in new blocks to protect against reorgs of the chaintip, particularly `OP_PUBREF` references near the chaintip. ZmnSCPxj noted that none of these issues were addressed in Michael's proposal and that the proposal only considered clients without considering the implications for validators.The email thread includes an HTML attachment and a non-text attachment titled "Floating-Point Nakamoto Consensus.pdf," which may contain further information related to the discussion.In response to an original posting, ZmnSCPxj highlighted several important issues with the proposed opcode called Hard NAK. These issues include hurting fungibility and privacy by encouraging address reuse, preventing pruning, requiring the creation of another index to previous block data, which increases requirements on fullnodes, and needing SCRIPT to be re-evaluated on transactions arriving in new blocks to protect against reorgs of the chaintip. ZmnSCPxj noted that none of these issues have been addressed in the current proposal and that it only considers clients without considering what validators would need to implement to validate new blocks with this opcode.The email thread also mentions a BIP that describes a new opcode enabling transactions that are about 37% smaller than traditional single-source segwit transactions. The size savings vary based on the number of inputs. This pursuit of smaller transactions is important for Inclusive Accountability as it reduces the amount of data recorded on the chain, leading to improved frugality by allowing more transactions to be confirmed in a block and enabling small value inputs to be referenced without losing unrecoverable value due to transaction overhead. The BIP can be found on GitHub at https://github.com/TheRook/bip-pubref/blob/master/bip-PubRef.mediawiki.On the Ethereum side, a variant of this technology called Ditto Transactions is described, which can be found at https://ethereum-magicians.org/t/eip-ditto-transactions/4455.
Updated on: 2023-08-02T02:32:11.433756+00:00