Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
On Sat, Feb 18, 2023 at 01:28:38AM +, Andrew Poelstra wrote: > On Sat, Feb 18, 2023 at 02:03:15AM +0200, Peter Todd wrote: > > On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev > > >You could try statically analyze `` to determine whether the > > >IF branch could ever be taken. For example there is no path through > > >the "inscription script" that would result in all the crap being dropped > > >by the end of the script, violating the CLEANSTACK rule. > > > > > >This sort of filtering, assuming it could be reliably and efficiently > > >done, would at least force inscription scripts to be "plausible", and > > >would greatly increase their space cost by e.g. requiring OP_DROP to be > > >added somewhere hundreds of times. > > > > "greatly increase their space cost"? > > > > Tell me, what is the actual % increase to adding OP_DROPs like you propose? > > > > By standardness rules (where you can have up to 80-byte pushes), a > little over 1%. By consensus (520-byte pushes) less than 0.2%. > > Perhaps "greatly increase" is a stretch :) but if the fee market is > functioning and we're talking about large amounts of data, it's not > trivial either. I would definitely call ~1% trivial. Fees vary more by that on an hour to hour basis. Anyway, it goes to show that protocols relying on data embedded in Bitcoin transactions would do well to have flexible encoding rules, eg by considering all PUSHDATA's with certain characteristics to be data, so that encoders can be adapted on the fly if there are any censorship issues. It's also useful if the rules allow data to be encoded in UTXO outputs, so that censorship of witness data always risks people switching to filling up the UTXO set. A kind of Mutually Assured Destruction threat in a way. FWIW, OpenTimestamps was deliberately designed to have this property. So don't mess with it. :D -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
Hi vjudeu, Before I respond to your email, I would like to share the [python script][0] that could be used to do 3 things: 1) List peers 2) Broadcast a transaction to peers and see if it was relayed 3) Ban peers that did not relay your transaction The primary goal of this script is testing however it can be used by anyone as it does not make sense to waste resources connecting to peers that do not relay your transactions. There is another [solution][1] for users to ensure all transactions get relayed properly. Note: There could be some false positives and it mainly uses libbtc > Yes, I disapprove spamming the blockchain. But because people will rather die > than stop it, creating some kind of official alternative is needed. I think > most of the time it is not needed to store that data on-chain, all that is > needed, is just proving they existed, and that they are connected to a > certain transaction (so, it is about timestamping, not about storage). Why do you think people don't stop and willing to pay for inscribing something on-chain although it could be done for free using BitTorrent? As far as 'spam' is concerned these are bitcoin transactions until you open ordinals explorer or believe in ordinals theory to track the ownership of inscription. There are some bitcoin transactions that I could consider spam and have no interest in keeping them on my disk. However I believe people should be free to do anything with their money and I don't care about the content or intent of any bitcoin transaction as long as its valid, paid fee etc. (except vulnerability) Blocks cannot exceed their limit and I was prepared for a fee market with new limits since segwit got activated. Here's my opinion why people don't stop doing it and we could always disagree: Money or financial transactions have been done differently in countries, cultures, communities etc. across the world. People have done inscriptions on paper money issued by governments for graffiti, political, personal or other reasons. Since years inscriptions have been on different types of [coins][2]. Example: Jahangir issued many gold and silver [coins with poetic verses][3] on them and was the only Mughal emperor to bestow the right of coinage to his royal consort. Some positives of inscriptions that I have observed in last couple of weeks: - More users interested in running full nodes (non-pruned) and trying bitcoin wallets, lightning etc. - Taproot usage increased - More developers interested in learning bitcoin development and looking for libraries, docs etc. - Demand for block space has increased - ~50 BTC paid in fees to miners for creating inscriptions until now It creates more opportunities for bitcoin developers and everyone involved in bitcoin. [0]: https://ordinals.com/content/f39b5f0a9e9af05da03ab0c52a407972b9678e8db80160febd6bd899acebe141i0 [1]: https://github.com/casey/ord/pull/1783 [2]: https://en.wikipedia.org/wiki/Coinage_of_India [3]: https://web.archive.org/web/20180705070913/https://www.mintageworld.com/blog/coins-of-jahangir/ /dev/fd0 floppy disk guy Sent with Proton Mail secure email. --- Original Message --- On Friday, February 17th, 2023 at 8:26 PM, vjudeu via bitcoin-dev wrote: > > I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS. > Because "OP_FALSE OP_IF OP_ENDIF" is effectively the same as > "OP_NOP", and putting NOPs in many places is considered non-standard. The > same is true for "OP_TRUE OP_NOTIF OP_ENDIF", and also there are > many variants, where someone could use "OP_FALSE OP_NOT" instead of > "OP_TRUE", or check if "2+2==4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" > (instead of putting "OP_TRUE"). > > > There are endless combinations, and even if there will be a rule to evaluate > constant values on the input stack, and put OP_NOP, where any non-empty set > of opcodes will evaluate into nothing, then still, there are ways to include > spam on-chain. So, the question is: how strict should those rules be? > > > "I disapprove of what you say, but I will defend to the death your right to > > say it." > > > Yes, I disapprove spamming the blockchain. But because people will rather die > than stop it, creating some kind of official alternative is needed. I think > most of the time it is not needed to store that data on-chain, all that is > needed, is just proving they existed, and that they are connected to a > certain transaction (so, it is about timestamping, not about storage). > > When it comes to the solution, I think a commitment to a signature should > handle all cases. In this way, it can be done for any address type that can > support OP_CHECKSIG. To validate such commitment, all that is needed, is > converting R-value of a signature into the Taproot address, and then checking > if a given commitment matches such key. > > > I agree with Peter that, given that users have found ways to store > > arbitrary amounts
Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
On Sat, Feb 18, 2023 at 5:11 AM vjudeu via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Also, it gives us a hint, that if any Script upgrade will be considered in > the future, we can think about doing it in a way, where unused parts can be > pruned, without invalidating signatures. > FWIW, pruning unused case branches is a core design principle of the Simplicity language I am developing. That being said, even this is not enough to thwart agents that specifically desire to post unused data blobs as part of their programs. This is largely because there are many mathematical expressions for what is equivalently an identity function. Think computing (x ^ 257) mod 257 (see Fermat's little theorem). Even in Simplicity users can write Word **; unit which is roughly equivalent PUSH ** DROP in Script. I don't even bother trying to prevent it. Doing so just adds more consensus complexity, and only raises the bar slightly on how to work around it. Simplicity's pruning is instead meant as a way to (usually) lower costs for users who aren't actively trying to spam the network. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
> By standardness rules (where you can have up to 80-byte pushes), a little > over 1%. By consensus (520-byte pushes) less than 0.2%. Note that instead of "OP_DROP OP_DROP", people can use "OP_2DROP", so the number of dropping opcodes could be halved. > I mean, they'd provide the `FALSE` as a separate witness element rather than > being part of the witnessScript. That means people can still reject an official alternative (for example commitments), so a different approach is needed to fight that spam. Assuming that transactions will be sent directly to the miners, they will be included, that way or another. So, the solution should assume that we will have large NOPs in the chain. And then, if we want to deal with them, some kind of pruning is needed. Switching from witness to non-witness node is not an option, because it would require additional witness validation, and because rules for OP_RETURN can be also lifted. So, how to prune the Script? In a typical hash function, like SHA-256, data are splitted into smaller chunks, and then processed linearly. I think it is possible to store the first and the last chunk, and keep the internal state of SHA-256, before entering the last chunk. In this way, it should be possible to prune those OP_NOPs. Because that solution will also cover raw scripts (people can switch to them if witness will be more restricted than now). Also, it gives us a hint, that if any Script upgrade will be considered in the future, we can think about doing it in a way, where unused parts can be pruned, without invalidating signatures. On 2023-02-18 00:39:16 user Andrew Poelstra wrote: > On Fri, Feb 17, 2023 at 11:35:34PM +, Andrew Poelstra via bitcoin-dev > wrote: > > If you ban any of these specific script fragments then spammers will > just use `IF ENDIF` and provide the `FALSE` as a zero push. > And banning *this* would ban legitimate use cases. > I realize this is confusingly worded. I mean, they'd provide the `FALSE` as a separate witness element rather than being part of the witnessScript. -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
On Sat, Feb 18, 2023 at 02:03:15AM +0200, Peter Todd wrote: > On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev > >You could try statically analyze `` to determine whether the > >IF branch could ever be taken. For example there is no path through > >the "inscription script" that would result in all the crap being dropped > >by the end of the script, violating the CLEANSTACK rule. > > > >This sort of filtering, assuming it could be reliably and efficiently > >done, would at least force inscription scripts to be "plausible", and > >would greatly increase their space cost by e.g. requiring OP_DROP to be > >added somewhere hundreds of times. > > "greatly increase their space cost"? > > Tell me, what is the actual % increase to adding OP_DROPs like you propose? > By standardness rules (where you can have up to 80-byte pushes), a little over 1%. By consensus (520-byte pushes) less than 0.2%. Perhaps "greatly increase" is a stretch :) but if the fee market is functioning and we're talking about large amounts of data, it's not trivial either. -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev >You could try statically analyze `` to determine whether the >IF branch could ever be taken. For example there is no path through >the "inscription script" that would result in all the crap being dropped >by the end of the script, violating the CLEANSTACK rule. > >This sort of filtering, assuming it could be reliably and efficiently >done, would at least force inscription scripts to be "plausible", and >would greatly increase their space cost by e.g. requiring OP_DROP to be >added somewhere hundreds of times. "greatly increase their space cost"? Tell me, what is the actual % increase to adding OP_DROPs like you propose? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
On Fri, Feb 17, 2023 at 11:35:34PM +, Andrew Poelstra via bitcoin-dev wrote: > > If you ban any of these specific script fragments then spammers will > just use `IF ENDIF` and provide the `FALSE` as a zero push. > And banning *this* would ban legitimate use cases. > I realize this is confusingly worded. I mean, they'd provide the `FALSE` as a separate witness element rather than being part of the witnessScript. -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
On Fri, Feb 17, 2023 at 03:56:31PM +0100, vjudeu via bitcoin-dev wrote: > > [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831 > > I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS. > Because "OP_FALSE OP_IF OP_ENDIF" is effectively the same as > "OP_NOP", and putting NOPs in many places is considered non-standard. The > same is true for "OP_TRUE OP_NOTIF OP_ENDIF", and also there are > many variants, where someone could use "OP_FALSE OP_NOT" instead of > "OP_TRUE", or check if "2+2==4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" > (instead of putting "OP_TRUE"). > If you ban any of these specific script fragments then spammers will just use `IF ENDIF` and provide the `FALSE` as a zero push. And banning *this* would ban legitimate use cases. You could try statically analyze `` to determine whether the IF branch could ever be taken. For example there is no path through the "inscription script" that would result in all the crap being dropped by the end of the script, violating the CLEANSTACK rule. This sort of filtering, assuming it could be reliably and efficiently done, would at least force inscription scripts to be "plausible", and would greatly increase their space cost by e.g. requiring OP_DROP to be added somewhere hundreds of times. -- Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
> [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831 I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS. Because "OP_FALSE OP_IF OP_ENDIF" is effectively the same as "OP_NOP", and putting NOPs in many places is considered non-standard. The same is true for "OP_TRUE OP_NOTIF OP_ENDIF", and also there are many variants, where someone could use "OP_FALSE OP_NOT" instead of "OP_TRUE", or check if "2+2==4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" (instead of putting "OP_TRUE"). There are endless combinations, and even if there will be a rule to evaluate constant values on the input stack, and put OP_NOP, where any non-empty set of opcodes will evaluate into nothing, then still, there are ways to include spam on-chain. So, the question is: how strict should those rules be? > "I disapprove of what you say, but I will defend to the death your right to > say it." Yes, I disapprove spamming the blockchain. But because people will rather die than stop it, creating some kind of official alternative is needed. I think most of the time it is not needed to store that data on-chain, all that is needed, is just proving they existed, and that they are connected to a certain transaction (so, it is about timestamping, not about storage). When it comes to the solution, I think a commitment to a signature should handle all cases. In this way, it can be done for any address type that can support OP_CHECKSIG. To validate such commitment, all that is needed, is converting R-value of a signature into the Taproot address, and then checking if a given commitment matches such key. > I agree with Peter that, given that users have found ways to store arbitrary > amounts of data on-chain if they really want, we might as well just make > OP_RETURN a free-for-all. I think we should go in the opposite direction. Using OP_RETURN means that all nodes will store such data. Using witness means that only witness nodes will keep that. So, if it is already possible to have a node that cannot see witness data, and still remain in the network, I think commitments should be stored only by nodes that will enable them explicitly. So, from that point of view, commitment is "a witness of a signature", it is additional information that can be skipped if needed. On 2023-02-13 14:08:21 user alicexbt via bitcoin-dev wrote: > Hi Bitcoin Developers, There is a famous quote attributed to Evelyn Beatrice Hall in her biography of Voltaire: "I disapprove of what you say, but I will defend to the death your right to say it." I'm curious to know how many Bitcoin developers share this sentiment. Recently there was a lot of enthusiasm on social media to run bitcoin core with a [patch][0] that would reject some transactions in mempool. Bitcoin Knots already has an option to reject transactions that reuse addresses. What if such practices become common and some projects that provide easy to use node software start censoring transactions? How would government agencies take advantage of this whole drama? I understand it is difficult to censor different type of transaction because there will be some nodes relaying them and miners including in blocks. It is still important to discuss this and different ways to test censorship resistance. - Peter Todd had written a [blog post][1] in which counting number of INVs (step 5,6,7 and 8) helps in testing if your transactions are getting relayed by the connected peers. - I had tried broadcasting transaction to specific nodes using [libbtc][2]. Based on my understanding it uses GETDATA to confirm your transaction was seen on other nodes after broadcasting. What would an ideal tool for testing censorship resistance look like? - Allows user to construct different types of transactions that might be considered "bad" by some people. Example: OFAC address in output, Inscription, OP_RETURN, Address reuse etc. - Option to broadcast transaction to specific nodes - Verify if the transaction was relayed successfully or rejected - Ban such peers using [setban][3] RPC as it would increase the probability of tx getting propagated to miners There was even some discussion about an [external mempool][4] that could be used for non-standard transactions. It could also help in avoiding censorship in some cases. I welcome your thoughts and feedback on this topic. [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831 [1]: https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf [2]: https://twitter.com/144bytes/status/1574225052240777216 [3]: https://bitcoincore.org/en/doc/24.0.0/rpc/network/setban/ [4]: https://twitter.com/jamesob/status/1623827708168863747 /dev/fd0 floppy disc guy Sent with Proton Mail secure email. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Testing censorship resistance of bitcoin p2p network
Hi Bitcoin Developers, There is a famous quote attributed to Evelyn Beatrice Hall in her biography of Voltaire: "I disapprove of what you say, but I will defend to the death your right to say it." I'm curious to know how many Bitcoin developers share this sentiment. Recently there was a lot of enthusiasm on social media to run bitcoin core with a [patch][0] that would reject some transactions in mempool. Bitcoin Knots already has an option to reject transactions that reuse addresses. What if such practices become common and some projects that provide easy to use node software start censoring transactions? How would government agencies take advantage of this whole drama? I understand it is difficult to censor different type of transaction because there will be some nodes relaying them and miners including in blocks. It is still important to discuss this and different ways to test censorship resistance. - Peter Todd had written a [blog post][1] in which counting number of INVs (step 5,6,7 and 8) helps in testing if your transactions are getting relayed by the connected peers. - I had tried broadcasting transaction to specific nodes using [libbtc][2]. Based on my understanding it uses GETDATA to confirm your transaction was seen on other nodes after broadcasting. What would an ideal tool for testing censorship resistance look like? - Allows user to construct different types of transactions that might be considered "bad" by some people. Example: OFAC address in output, Inscription, OP_RETURN, Address reuse etc. - Option to broadcast transaction to specific nodes - Verify if the transaction was relayed successfully or rejected - Ban such peers using [setban][3] RPC as it would increase the probability of tx getting propagated to miners There was even some discussion about an [external mempool][4] that could be used for non-standard transactions. It could also help in avoiding censorship in some cases. I welcome your thoughts and feedback on this topic. [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831 [1]: https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf [2]: https://twitter.com/144bytes/status/1574225052240777216 [3]: https://bitcoincore.org/en/doc/24.0.0/rpc/network/setban/ [4]: https://twitter.com/jamesob/status/1623827708168863747 /dev/fd0 floppy disc guy Sent with Proton Mail secure email. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
