alicexbt [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-13 🗒️ Summary of this message: Bitcoin ...
📅 Original date posted:2023-02-13
🗒️ Summary of this message: Bitcoin developers discuss the potential for censorship of transactions and the need for tools to test censorship resistance, including an external mempool.
📝 Original message: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.
🗒️ Summary of this message: Bitcoin developers discuss the potential for censorship of transactions and the need for tools to test censorship resistance, including an external mempool.
📝 Original message: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.