From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 654ABC002B for ; Mon, 13 Feb 2023 12:34:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 405B48148A for ; Mon, 13 Feb 2023 12:34:46 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 405B48148A Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=PEY+/19D X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4BTX-HxOhYM for ; Mon, 13 Feb 2023 12:34:45 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E703281469 Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) by smtp1.osuosl.org (Postfix) with ESMTPS id E703281469 for ; Mon, 13 Feb 2023 12:34:44 +0000 (UTC) Date: Mon, 13 Feb 2023 12:34:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1676291682; x=1676550882; bh=Qu1plM/YcWkrqNsKV/oka9yxGYJeJRg0rXIz9jse77g=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=PEY+/19D/aV5EEkBvvarNHxdaZfWRz4CIw8gBcqlJR+jzVm+poCAIWq16mfEJMjON zR05XDB3Awt30Pg5kxvx9KBQTk6mKRBpFf0hj5iwE+D5uqLUJDUUJP3yBUjcuZ7fkr 4AHRHDG7O3cD0vMUXvAfg+gQhUkcCU8nR+UL5v/N7KnpCd/4YZkLVvsaHMaxrOUsX9 /kSzYxtw0iqi9unS0jYVgx5bTgXoXJw1qV/mGCJJkbxEjlb4yfY6zEpJpAS9AWz0aC QcF2480h0Ua1vrsooI/yI6pgLe8ipkMDYAwV+SrC6nvhf9FDtXr7QMrWETIKkkPy0g OUPBkr/UumM9Q== To: Bitcoin Protocol Discussion From: alicexbt Message-ID: Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 13 Feb 2023 13:08:05 +0000 Subject: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2023 12:34:46 -0000 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.