Date: Mon, 13 Feb 2023 12:34:30 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <TG0yVn41L6VFOHFRYqd3iGz7mxHWtjFdaBrz8mlP6Uk8bmog_isDbtq_2QyvdUs9_Q-jStmx7V7l5rAesXDfHlK9Ehft7SkK5EWQ_3mg-eQ=@protonmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
Precedence: list

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 sha=
re 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 K=
nots already has an option to reject transactions that reuse addresses. Wha=
t if such practices become common and some projects that provide easy to us=
e 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 becaus=
e 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 r=
esistance.

- 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 relaye=
d by the connected peers.=20
- 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 co=
nsidered "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 censors=
hip 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.