From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8DB76C0032 for ; Sun, 6 Aug 2023 20:45:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 3650560B9C for ; Sun, 6 Aug 2023 20:45:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3650560B9C Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=lightco.in header.i=@lightco.in header.a=rsa-sha256 header.s=fm2 header.b=GPRa+4pm; dkim=pass (2048-bit key, unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm3 header.b=SfEvhw0R X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.802 X-Spam-Level: X-Spam-Status: No, score=-2.802 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, 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 q-jPr-jktHrW for ; Sun, 6 Aug 2023 20:45:54 +0000 (UTC) X-Greylist: delayed 573 seconds by postgrey-1.37 at util1.osuosl.org; Sun, 06 Aug 2023 20:45:53 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DECCB60A87 Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by smtp3.osuosl.org (Postfix) with ESMTPS id DECCB60A87 for ; Sun, 6 Aug 2023 20:45:53 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 2F3C132002E2; Sun, 6 Aug 2023 16:36:14 -0400 (EDT) Received: from imap42 ([10.202.2.92]) by compute2.internal (MEProxy); Sun, 06 Aug 2023 16:36:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightco.in; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t=1691354173; x=1691440573; bh=5KAy3b7FJk1Q3DyO9gTfw92SC 0JIWxcmOxbFitGUY/w=; b=GPRa+4pmvQKk9hbKVH5vDw60NFsBjuOWCy/Jb0dei rdtacxKmHMDZ7x1wjQibf4PTbYBGjeiXb1Ui82d/Frn0BKhCNUphLJSeA5PDq0M+ qm2ry2FHgmcpF+H6QarS15va7JiaW2Q3hFRf11J+kj9Pg3gjkasnOhOil2pQiDcv /ftz1zi44FI90517rOOmQUxzWy0kTXGhhQ/j+CKYuSwEPIY94e2jgYui0iFBKoEK CBkKXRLPgFp795Tu87WrUZZGjOMG++H2yTpy+tLjTzc1I9ymV0zaPPIhnj8N4g6+ LjDQpa400K4hlfxWyip7RmLwH472z843WWibQqLYjGrEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1691354173; x=1691440573; bh=5KAy3b7FJk1Q3DyO9gTfw92SC0JIWxcmOxb FitGUY/w=; b=SfEvhw0RwzzA8YAJoE/HIKt4sQQGgtUU6Phdm9Z+Bhc1tiy9TGN bGDVrLrQZIzSspFCY5byWQ0pxFG+cKbkw/e4BohlZ0U2bNHoqs7fO79nO+7JI5SG 3m+JJvcpxc84oEQvMFv1+2U0PWeVVKiet11+tVNLS7GgmHM4oRH3ccAothU5QHDS odlUTJuE3+o9mYGkRCx2h5t4AweHFZjisdp1WdKHrsbPE1KLLOc5G9Zf/I9JDGog dCuD+oVQySnAKEo+qxz+cBGQ78eHPMZkPuoVwJA4gxK1JGArgbBJGKM3NXwEplmS UXorLDLsWDmHSGPu1CFu2jNsYd6eHwaA5Mg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrkeekgdduhedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvvefutgesthdtre dtreertdenucfhrhhomhepfdflohhhnhcunfhighhhthdfuceosghithgtohhinhdquggv vheslhhighhhthgtohdrihhnqeenucggtffrrghtthgvrhhnpeehffekfeffffevvdeuje etfedthfetgeekgfelvdffteeuffdvheffgfdugeefueenucffohhmrghinhepghhithhh uhgsrdgtohhmpdgsihhttghoihhnrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomhepsghithgtohhinhdquggvvheslhhighhhthgtohdr ihhn X-ME-Proxy: Feedback-ID: ic4c14615:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 17A53BC007C; Sun, 6 Aug 2023 16:36:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-624-g7714e4406d-fm-20230801.001-g7714e440 Mime-Version: 1.0 Message-Id: <00feb0f1-ec5a-4fc2-8bff-5acf8616e458@app.fastmail.com> Date: Sun, 06 Aug 2023 16:35:38 -0400 From: "John Light" To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain X-Mailman-Approved-At: Sun, 06 Aug 2023 22:40:22 +0000 Subject: Re: [bitcoin-dev] Pull-req to remove the arbitrary limits on OP_Return outputs 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: Sun, 06 Aug 2023 20:45:55 -0000 Hi Peter, Re: https://github.com/bitcoin/bitcoin/pull/28130 I have a few questions about your proposal and its impact on full node operators: 1. With your proposed policy change removing the OP_RETURN output count and data size limits, is there ever a case where using OP_RETURN to embed data actually results in fewer bytes onchain than embedding the same data using the segwit/taproot witness space e.g. the envelope technique inscriptions use? Robin Linus suggested on your PR there may be a case that "effectively results in a discount for small inscriptions".[1] It would be good to have confirmation on this and specific details about the range of inscription sizes that would receive the discount if this is true. (Robin himself is of course also welcome to answer this question; I have cc'd him directly on this email as an invitation to respond.) 2. Documentation about OP_RETURN says that OP_RETURN outputs are "provably-prunable".[2] A question I had about this was, are there any tools available that a full node operator could use to prune this data from their nodes? While researching this question I found PR #2791 from Pieter Wuille, which implemented pruning of provably-unspendable outputs, which I assume includes OP_RETURN outputs.[3] After looking around some more and not finding definitive answers, I have a few new questions about this: i) Is the unspendable output pruning implemented in PR #2791 on by default or is this a flag that needs to be enabled by full node operators? If it's a flag, what is the flag called and how can it be enabled? If it's on by default, how can it be disabled? ii) If a full node operator does prune OP_RETURN outputs, does that in any way impair their ability to help a new node do IBD to validate the blockchain? And would that answer be any different if we were talking about pruning Taproot witness space (i.e. "envelopes" or "inscriptions") instead of OP_RETURN outputs? Regards, John Light [1] https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1664950834 [2] https://bitcoin.org/en/release/v0.9.0#opreturn-and-data-in-the-block-chain [3] https://github.com/bitcoin/bitcoin/pull/2791