[bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[alicexbt]

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/1440000bytes/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.

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[vjudeu]

> [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 <anything> 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 <anything> 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 <bitcoin-dev@lists.linuxfoundation.org> 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/1440000bytes/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

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

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 <anything> 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 <anything> 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 <anything> ENDIF` and provide the `FALSE` as a zero push.
And banning *this* would ban legitimate use cases.

You could try statically analyze `<anything>` 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

On Fri, Feb 17, 2023 at 11:35:34PM +0000, Andrew Poelstra via bitcoin-dev wrote:
> 
> If you ban any of these specific script fragments then spammers will
> just use `IF <anything> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[Peter Todd]

On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev 
>You could try statically analyze `<anything>` 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?

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

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 `<anything>` 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[vjudeu]

> 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 <apoelstra@wpsoftware.net> wrote:
> On Fri, Feb 17, 2023 at 11:35:34PM +0000, Andrew Poelstra via bitcoin-dev wrote:
> 
> If you ban any of these specific script fragments then spammers will
> just use `IF <anything> 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

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

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 *<some data blob>*; unit which is
roughly equivalent PUSH *<data blob>* 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.

[-- Attachment #2: Type: text/html, Size: 1662 bytes --]

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

[alicexbt]

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 <bitcoin-dev@lists.linuxfoundation.org> wrote:


> 
> I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS. Because "OP_FALSE OP_IF <anything> 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 <anything> 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 bitcoin-dev@lists.linuxfoundation.org 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 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/1440000bytes/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 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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1991 bytes --]

On Sat, Feb 18, 2023 at 01:28:38AM +0000, 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 `<anything>` 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]