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 EEB16C0032 for ; Tue, 8 Aug 2023 01:42:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id B5BDB60C11 for ; Tue, 8 Aug 2023 01:42:56 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B5BDB60C11 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=cFtM2egE X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.298 X-Spam-Level: X-Spam-Status: No, score=0.298 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_DNSWL_NONE=-0.0001, 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 784avSGvf_dH for ; Tue, 8 Aug 2023 01:42:56 +0000 (UTC) X-Greylist: delayed 459 seconds by postgrey-1.37 at util1.osuosl.org; Tue, 08 Aug 2023 01:42:55 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org F300360C05 Received: from mail-4321.protonmail.ch (mail-4321.protonmail.ch [185.70.43.21]) by smtp3.osuosl.org (Postfix) with ESMTPS id F300360C05 for ; Tue, 8 Aug 2023 01:42:55 +0000 (UTC) Date: Tue, 08 Aug 2023 01:34:56 +0000 Authentication-Results: mail-4321.protonmail.ch; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.b="cFtM2egE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1691458504; x=1691717704; bh=9kYDuYBSWMv1t2r6Aef4WTH6g89567/8qIr3BAHbGHQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=cFtM2egExAASZc6sEcti9K2SUrz2CmPEg2xUnIg97dSKIpn2JspVBMybEUZp0BejO 9sFdMOBb/eTK9c07LRAv+XKJl9KPODsU3UB7Nm3jymEwcD6IO0oxX/dxhPSHOHZJDl +lxeqowgWT70ke9i2pX/Zfm/uRmA54DCtMy+XbCki3R7+wcTbbKh7BMsh7qLcoTfL9 Uc4DgtV6P6GF/po3NaHXd+GffYms87VgYYiMsW5u3a8IzH9219rBqI8HSUiKgHIqfb gERlvdhsvOCRvAJVlt8pf7e9z3j3RnJofbp48Brq2Nq/eALpF4Mdf0jroqtpSvE+zu zQ47HYP6BBVvg== To: John Light From: ZmnSCPxj Message-ID: In-Reply-To: <00feb0f1-ec5a-4fc2-8bff-5acf8616e458@app.fastmail.com> References: <00feb0f1-ec5a-4fc2-8bff-5acf8616e458@app.fastmail.com> Feedback-ID: 2872618:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: bitcoin-dev@lists.linuxfoundation.org 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: Tue, 08 Aug 2023 01:42:57 -0000 Good morning John Light, > 2. Documentation about OP_RETURN says that OP_RETURN outputs are "provabl= y-prunable".[2] A question I had about this was, are there any tools availa= ble that a full node operator could use to prune this data from their nodes= ? As I understand it, `OP_RETURN` outputs are already pruned, in the sense th= at they are never put in the UTXO database in the first place. Indeed, as I understand it, "pruning" in this context is about removing (or= not inserting at all, in the case of `OP_RETURN`) from the UTXO database. UTXO database is best to keep small to reduce lookups of UTXOs being spent,= as that impacts speed of validation. Archival nodes still retain the raw `OP_RETURN` data as part of the raw blo= ck data, as it is necessary to prove that those transactions are (1) valid = transactions and (2) part of (i.e. in the Merkle tree of) a valid block on = the block header chain. Block-pruning nodes also still retain this data, as they can at least serve= recent blocks with the same requirement of proving that transactions conta= ining `OP_RETURN` are valid transactions in a valid block on the block head= er chain. If you want to prove that a block is valid, you need to present even `OP_RE= TURN` data, as you need to be able to show the actual transaction containin= g it, so that the verifier can see that the transaction is correctly format= ted and its txid matches the supposed location in the Merkle tree. Block relay requires that the node relaying a block prove that that block i= s indeed valid, thus you need to retain the `OP_RETURN` data. Thus, in this context "pruning" refers to not keeping `OP_RETURN` TXOs in t= he UTXO database. Regards, ZmnSCPxj