Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 67D72C002B for ; Fri, 17 Feb 2023 15:06:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 437D28213D for ; Fri, 17 Feb 2023 15:06:48 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 437D28213D Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=EEizoLlH X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=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 6BIazHXRIjVD for ; Fri, 17 Feb 2023 15:06:46 +0000 (UTC) X-Greylist: delayed 00:10:03 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4E05482131 Received: from smtpo92.poczta.onet.pl (smtpo92.poczta.onet.pl [213.180.149.145]) by smtp1.osuosl.org (Postfix) with ESMTPS id 4E05482131 for ; Fri, 17 Feb 2023 15:06:46 +0000 (UTC) Received: from pmq7v.m5r2.onet (pmq7v.m5r2.onet [10.174.35.192]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4PJFJM0p9jzlk0 for ; Fri, 17 Feb 2023 15:56:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1676645795; bh=2dky6ZjwQRi1Mu6XZPUp4pTaa+wGo+fEHfg9yqbhB8Y=; h=From:To:In-Reply-To:Date:Subject:From; b=EEizoLlHqrBwNfGgvfY2v/4AGiN296Od059ukdrMD+61lqU6rpR5/v1IIgbWNG8HU 5h60Nq7x5tA8bA4idF4T5jYhx7GuS0wAiSu5TqP3YVGuxBm0UKi/ulYZPxnqhczNSI q34EqokZgVM3siyUVU52Fu8DpYjPFgPjEaqziALg= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [82.177.167.2] by pmq7v.m5r2.onet via HTTP id ; Fri, 17 Feb 2023 15:56:35 +0100 From: vjudeu@gazeta.pl X-Priority: 3 To: "alicexbt , Bitcoin Protocol Discussion" , Bitcoin Protocol Discussion In-Reply-To: Date: Fri, 17 Feb 2023 15:56:31 +0100 Message-Id: <177016307-23dca06637e70217317077657442d0d8@pmq7v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;82.177.167.2;PL;1 X-Mailman-Approved-At: Fri, 17 Feb 2023 15:09:55 +0000 Subject: Re: [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: Fri, 17 Feb 2023 15:06:48 -0000 > [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 OP_ENDIF" is effectively the same as "= OP_NOP", and putting NOPs in many places is considered non-standard. The sa= me is true for "OP_TRUE OP_NOTIF OP_ENDIF", and also there are m= any variants, where someone could use "OP_FALSE OP_NOT" instead of "OP_TRUE= ", or check if "2+2=3D=3D4" by using "OP_2 OP_2 OP_ADD OP_4 OP_EQUAL" (inst= ead of putting "OP_TRUE"). There are endless combinations, and even if there will be a rule to evaluat= e constant values on the input stack, and put OP_NOP, where any non-empty s= et of opcodes will evaluate into nothing, then still, there are ways to inc= lude 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 d= ie than stop it, creating some kind of official alternative is needed. I th= ink 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 h= andle 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 co= nverting 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 arbitr= ary amounts of data on-chain if they really want, we might as well just mak= e 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 s= ee witness data, and still remain in the network, I think commitments shoul= d be stored only by nodes that will enable them explicitly. So, from that p= oint of view, commitment is "a witness of a signature", it is additional in= formation that can be skipped if needed. On 2023-02-13 14:08:21 user alicexbt via bitcoin-dev 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 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. = - 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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev