public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: alicexbt <alicexbt@protonmail•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network
Date: Mon, 13 Feb 2023 12:34:30 +0000	[thread overview]
Message-ID: <TG0yVn41L6VFOHFRYqd3iGz7mxHWtjFdaBrz8mlP6Uk8bmog_isDbtq_2QyvdUs9_Q-jStmx7V7l5rAesXDfHlK9Ehft7SkK5EWQ_3mg-eQ=@protonmail.com> (raw)

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.


             reply	other threads:[~2023-02-13 12:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13 12:34 alicexbt [this message]
2023-02-17 14:56 ` vjudeu
2023-02-17 23:35   ` Andrew Poelstra
2023-02-17 23:39     ` Andrew Poelstra
2023-02-18  9:48       ` vjudeu
2023-02-18 18:03         ` Russell O'Connor
2023-02-18  0:03     ` Peter Todd
2023-02-18  1:28       ` Andrew Poelstra
2023-02-22 16:39         ` Peter Todd
2023-02-19  0:33   ` alicexbt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='TG0yVn41L6VFOHFRYqd3iGz7mxHWtjFdaBrz8mlP6Uk8bmog_isDbtq_2QyvdUs9_Q-jStmx7V7l5rAesXDfHlK9Ehft7SkK5EWQ_3mg-eQ=@protonmail.com' \
    --to=alicexbt@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox