From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 34C5BC002B for ; Sat, 18 Feb 2023 09:48:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 0372C80DAD for ; Sat, 18 Feb 2023 09:48:17 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0372C80DAD 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=pjAQ8+D0 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 xFFneTQPgIKM for ; Sat, 18 Feb 2023 09:48:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6DEA0812A1 Received: from smtpo90.poczta.onet.pl (smtpo90.poczta.onet.pl [213.180.149.143]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6DEA0812A1 for ; Sat, 18 Feb 2023 09:48:15 +0000 (UTC) Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4PJkPy0W0Gz2K24x5; Sat, 18 Feb 2023 10:48:05 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1676713686; bh=1W9G7gr/Xg5q3ejIwJ+WsmH4Fz207DP8EVYbdLFsf64=; h=From:To:In-Reply-To:Date:Subject:From; b=pjAQ8+D0rbfAn5hIUS7yXOvn29wyR5Cf9wi6TXd+ZQqF1kDHu/rHGf7usSPZCgGOG fKYnriOUApvBswfbMm759BS/V/ApY1c8kyVoclnjoFQAFN+p0B5tXU5isxgPWyGhzD smqZzrVfiDVUo/M7IEw2vguaxXQjSXaTZex/N/hw= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.232.145] by pmq3v.m5r2.onet via HTTP id ; Sat, 18 Feb 2023 10:48:05 +0100 From: vjudeu@gazeta.pl X-Priority: 3 To: Andrew Poelstra , Bitcoin Protocol Discussion In-Reply-To: Date: Sat, 18 Feb 2023 10:48:02 +0100 Message-Id: <177848612-ad2b15230d78bcd732bbe8621af89a1e@pmq3v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.232.145;PL;2 X-Mailman-Approved-At: Sat, 18 Feb 2023 10:11:53 +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: Sat, 18 Feb 2023 09:48:17 -0000 > By standardness rules (where you can have up to 80-byte pushes), a little= over 1%. By consensus (520-byte pushes) less than 0.2%. Note that instead of "OP_DROP OP_DROP", people can use "OP_2DROP", so the n= umber of dropping opcodes could be halved. > I mean, they'd provide the `FALSE` as a separate witness element rather t= han being part of the witnessScript. That means people can still reject an official alternative (for example com= mitments), so a different approach is needed to fight that spam. Assuming t= hat transactions will be sent directly to the miners, they will be included= , that way or another. So, the solution should assume that we will have lar= ge NOPs in the chain. And then, if we want to deal with them, some kind of = pruning is needed. Switching from witness to non-witness node is not an opt= ion, because it would require additional witness validation, and because ru= les for OP_RETURN can be also lifted. So, how to prune the Script? In a typical hash function, like SHA-256, data= are splitted into smaller chunks, and then processed linearly. I think it = is possible to store the first and the last chunk, and keep the internal st= ate of SHA-256, before entering the last chunk. In this way, it should be p= ossible to prune those OP_NOPs. Because that solution will also cover raw s= cripts (people can switch to them if witness will be more restricted than n= ow). Also, it gives us a hint, that if any Script upgrade will be considered in = the future, we can think about doing it in a way, where unused parts can be= pruned, without invalidating signatures. On 2023-02-18 00:39:16 user Andrew Poelstra wrot= e: > On Fri, Feb 17, 2023 at 11:35:34PM +0000, Andrew Poelstra via bitcoin-dev= wrote: > = > If you ban any of these specific script fragments then spammers will > just use `IF ENDIF` and provide the `FALSE` as a zero push. > And banning *this* would ban legitimate use cases. > I realize this is confusingly worded. I mean, they'd provide the `FALSE` as a separate witness element rather than being part of the witnessScript. -- = Andrew Poelstra Director of Research, Blockstream Email: apoelstra at wpsoftware.net Web: https://www.wpsoftware.net/andrew The sun is always shining in space -Justin Lewis-Webster