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

From: vjudeu@gazeta•pl
To: "alicexbt <alicexbt@protonmail•com>,
	Bitcoin Protocol Discussion"
	<bitcoin-dev@lists•linuxfoundation.org>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
Date: Fri, 17 Feb 2023 15:56:31 +0100	[thread overview]
Message-ID: <177016307-23dca06637e70217317077657442d0d8@pmq7v.m5r2.onet> (raw)
In-Reply-To: <TG0yVn41L6VFOHFRYqd3iGz7mxHWtjFdaBrz8mlP6Uk8bmog_isDbtq_2QyvdUs9_Q-jStmx7V7l5rAesXDfHlK9Ehft7SkK5EWQ_3mg-eQ=@protonmail.com>

> [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