Published on: 2023-02-22T16:39:04+00:00
In a recent discussion on the bitcoin-dev mailing list, the topic of using static analysis to determine the likelihood of an IF branch being taken in inscription scripts was brought up. Andrew Poelstra suggested that if this filtering could be done reliably and efficiently, it would make inscription scripts more "plausible" but would also increase their space cost by requiring multiple instances of OP_DROP. Peter Todd questioned the actual percentage increase in space cost, with Poelstra estimating a little over 1% according to standardness rules and less than 0.2% according to consensus.The conversation then shifted to the issue of censorship resistance in Bitcoin transactions. There are concerns about certain projects censoring transactions and the potential exploitation of such practices by government agencies. To test if transactions are being relayed by connected peers, two tools were mentioned: counting INV messages and broadcasting transactions to specific nodes using libbtc. A Python script was shared that allows listing peers, broadcasting transactions, and banning peers that do not relay transactions. While the script is primarily for testing purposes, it can be used by anyone who wants to avoid connecting to unhelpful peers. It was noted that there may be some false positives in the results, and the script relies on libbtc.The discussion also touched upon the storage of arbitrary data on-chain and the use of OP_RETURN. The writer argues that commitments should only be stored by nodes that explicitly enable them, as they are additional information that can be skipped if needed. They believe that using OP_RETURN would result in all nodes storing such data, whereas using witness nodes would limit storage to those specifically designed for it. The benefits of inscriptions were also highlighted, including increased interest in running full nodes, trying out bitcoin wallets and lightning, greater adoption of Taproot, and more developers seeking bitcoin development resources.Another email thread focused on spam in Bitcoin transactions. The current standardness rules allow for up to 80-byte pushes, resulting in a little over 1% of spam. By consensus, which allows for 520-byte pushes, the percentage is less than 0.2%. To reduce the number of dropping opcodes, the suggestion is to use "OP_2DROP" instead of "OP_DROP OP_DROP." However, this alone is not enough to reject official alternatives like commitments. The inclusion of spam transactions in the chain is still possible. Pruning unused data blobs in the chain is seen as a solution, but switching from witness to non-witness nodes would require additional validation and invalidate signatures. One proposed solution involves storing the first and last chunk of data and keeping the internal state of SHA-256 before entering the last chunk, allowing for pruning without invalidating signatures. The discussion also mentions the possibility of spammers providing "FALSE" as a separate witness element rather than part of the witnessScript, leading to the use of legitimate "IF ENDIF" cases.In February 2023, Andrew Poelstra suggested using static analysis to determine the likelihood of an IF branch being taken in inscription scripts. This proposal aims to make inscription scripts more "plausible" by requiring the addition of OP_DROP multiple times. The actual percentage increase in space cost was estimated to be a little over 1% according to standardness rules and less than 0.2% according to consensus. The issue of banning specific script fragments was discussed, with concerns raised about spammers using alternative methods to bypass bans. Andrew Poelstra mentioned that spammers could use "IF ENDIF" and provide "FALSE" as a separate witness element, which would also impact legitimate use cases.The topic of spam in Bitcoin transactions was also addressed. The current standardness rules allow for up to 80-byte pushes, resulting in a little over 1% of spam. By consensus, which allows for 520-byte pushes, the percentage is less than 0.2%. To address this issue, suggestions were made to use "OP_2DROP" instead of "OP_DROP OP_DROP" and to prune unused data blobs in the chain. However, switching from witness to non-witness nodes was considered unfeasible due to additional validation requirements and signature invalidation. The idea of storing the first and last chunk of data and preserving the internal state of SHA-256 before entering the last chunk was proposed as a solution for pruning without invalidating signatures.The discussion also touched upon the sentiment expressed in the quote "I disapprove of what you say, but I will defend to the death your right to say it." The author wondered how many Bitcoin developers share this sentiment and raised concerns about censorship and government agencies taking advantage of transaction censorship practices. Testing censorship resistance was deemed important, and an ideal tool for this purpose was suggested. This tool would allow users to construct different types of transactions, broadcast them to specific nodes, verify successful relay or rejection, and ban peers if necessary.
Updated on: 2023-08-02T08:56:50.488864+00:00