Published on: 2019-07-29T03:39:15+00:00
In a recent conversation between Mike and ZmnSCPxj, the topic of transaction pruning in Bitcoin Core was discussed. Pruning involves discarding transaction data after validation while keeping only the UTXO set. However, ZmnSCPxj raised concerns about the future use of pruned data in a potential `OP_PUBREF` referencing pruned blocks. They suggested that a consensus rule should be established to determine how pruned validators can access necessary data. ZmnSCPxj and Mike also discussed the potential implications of using `OP_PUBREF` on the blockchain. They noted that current applications using txids to refer to previous transactions would not be affected by short-ranged history rewrites. However, there is a potential for a targeted attack where a large payout going to a `scriptPubKey` that uses `OP_PUBREF` on a recently-confirmed transaction is replaced with one that pays to a different public key through a history-rewrite attack. The suggestion was made to consider a "deeply-confirmed" point, such as 100 blocks, to mitigate this risk. The conversation also touched on the challenge of dealing with large data sets and the need to account for real-world limits on computability. Projects like Apache HTTPD's Bucket-Brigade and leveldb have addressed these challenges. Pruning was seen as an asset for PubRef but posed a problem if necessary data from pruned transactions is needed in the future.The discussion between Mike and ZmnSCPxj highlighted the potential attacks on the blockchain due to the use of `OP_PUBREF`. It was suggested that 100 blocks might be an acceptable time frame for such attacks, similar to the acceptance of miner coinbase maturity. There were concerns about the size of the data set required for validating scripts and the need for pruning to address this. However, it was noted that current pruned nodes did not retain the necessary data and would need to re-download the entire blockchain.In the email exchange, Mike and ZmnSCPxj discussed the potential benefits and drawbacks of adding `OP_PUBREF` to the SCRIPT language used in Bitcoin transactions. They explored the possibility of compressing SegWit transactions and reducing costs without compromising privacy. However, concerns were raised about address reuse and the limited access to transaction data within a SCRIPT. The computational effort required to maintain a database resolving public references was also noted. It was suggested that the validity of a PUBREF index should be re-evaluated during chain tip reorganizations unless a certain number of blocks have confirmed the data.The conversation between Mike Brooks and ZmnSCPxj delved into the potential adoption of a new opcode that would allow scripts to refer to data on the blockchain. While this could reduce transaction sizes and save costs, there were concerns about address reuse and the increased validation costs and storage requirements. Other proposals like batching, lightning, MAST, Schnorr signatures, and taproot/graftroot were mentioned as alternatives to address these issues.The idea of introducing an opcode to allow scripts to refer to blockchain data was discussed in the bitcoin-dev mailing list. Mike Brooks proposed this feature to reduce transaction sizes, but concerns were raised about incentivizing address reuse and increasing storage requirements for validation. Alternative approaches were suggested, such as optional functionality in the p2p layer and encoding transaction IDs differently to save space.The accuracy of the statement that PubRef is not susceptible to malleability attacks due to the immutability of the blockchain was questioned. It was pointed out that chain tips are not immutable and can be replaced, so data referenced using PubRef can only be accessed if buried under 100 blocks. Concerns about pubkey reuse and the need for additional databases and computational effort to resolve PubRef indices were also raised.In the bitcoin-dev mailing list discussion, Mike Brooks proposed giving scripts the ability to refer to data on the blockchain. However, another participant named Yuval expressed skepticism about the actual utilization of this feature and raised concerns about address reuse, validation costs, and storage requirements. Alternative approaches, such as incorporating the functionality in the p2p layer, were suggested.The proposal to introduce an opcode allowing scripts to reference data on the blockchain was discussed in the bitcoin-dev community. The aim was to reduce transaction sizes and enable miners to include more transactions in blocks. However, concerns were raised about incentivizing address re-use and the impact on fungibility. The proposal also faced challenges in terms of increased validation costs and storage requirements for historical data.In the discussion on the bitcoin-dev mailing list, a proposal was made to give scripts the ability to refer to data on the blockchain, which could reduce transaction sizes and improve block space efficiency. However, concerns were raised about the potential for address re-use and the storage requirements for validating nodes.
Updated on: 2023-08-02T01:06:50.402358+00:00