Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id C5F69C002B for ; Sat, 18 Feb 2023 00:03:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 99F4960672 for ; Sat, 18 Feb 2023 00:03:23 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 99F4960672 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm1 header.b=thxUpWdd X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSE1YXpXOOI9 for ; Sat, 18 Feb 2023 00:03:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2C098600B3 Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by smtp3.osuosl.org (Postfix) with ESMTPS id 2C098600B3 for ; Sat, 18 Feb 2023 00:03:22 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id CB684320092E; Fri, 17 Feb 2023 19:03:20 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Fri, 17 Feb 2023 19:03:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:date:feedback-id:feedback-id:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; t=1676678600; x=1676765000; bh=f FRN0edri6e20LsHcDGrhln2CEW8G7ee7dtP74fCjDk=; b=thxUpWddY5uJetXi9 CHRz4m6iOu1fneWP+/V5JxXU65USte0QgJci2JP3c1QIrBQ7XFBXQyZgY96Jmmu4 u+PO4VmME0P7S7yBggCACA7G3u8KPsLIyrzVNGaCg18r+F1Gzsrb3P8GO9+M/H1W 1Wc2ZLyh9f5+yNukdQlEnugNMQTzy/JKgwYbsuU2nvF6Vm5w4Zt5x14MwoRe3OBc x8AlR/lCffNp3a2f61wOyhzsNUk9NftjKjJoECVtLtJIIUWplWmWUvZcV1RENvs6 TrGrOc24f9f1d+w2leAJL3aX5Uuqt9tyIii+SMttfhsK1R1LMlAzyY15uRwqYAVw Q+Alw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudejtddgudehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffufggjfhfkgggtgfesthhqmhdttderjeenucfhrhhomheprfgvthgv rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth gvrhhnpefhteeuleffvddujeejteejjefgjeefleeiieejudeiiedvueegffefueeglefg ueenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvg htvgesphgvthgvrhhtohguugdrohhrgh X-ME-Proxy: Feedback-ID: i525146e8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 17 Feb 2023 19:03:19 -0500 (EST) Date: Sat, 18 Feb 2023 02:03:15 +0200 From: Peter Todd To: Andrew Poelstra , Bitcoin Protocol Discussion , Andrew Poelstra via bitcoin-dev , vjudeu@gazeta.pl User-Agent: K-9 Mail for Android In-Reply-To: References: <177016307-23dca06637e70217317077657442d0d8@pmq7v.m5r2.onet> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 00:03:23 -0000 On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev= =20 >You could try statically analyze `` to determine whether the >IF branch could ever be taken=2E For example there is no path through >the "inscription script" that would result in all the crap being dropped >by the end of the script, violating the CLEANSTACK rule=2E > >This sort of filtering, assuming it could be reliably and efficiently >done, would at least force inscription scripts to be "plausible", and >would greatly increase their space cost by e=2Eg=2E requiring OP_DROP to = be >added somewhere hundreds of times=2E "greatly increase their space cost"? Tell me, what is the actual % increase to adding OP_DROPs like you propose= ?