From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 59D44C0011 for ; Fri, 25 Feb 2022 03:19:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 41F9B401AE for ; Fri, 25 Feb 2022 03:19:45 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUSKYUbDpQFA for ; Fri, 25 Feb 2022 03:19:42 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by smtp2.osuosl.org (Postfix) with ESMTPS id A15124010C for ; Fri, 25 Feb 2022 03:19:42 +0000 (UTC) Date: Fri, 25 Feb 2022 03:19:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1645759179; bh=SjNFSpCV4/eiEIlw9DyVjWgbQI0tqQPA/SBaLfQQHOU=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=sWXbWxJIz0jkc9yGCSgCcMkf1rgsERPCS/rWCkcV7cROFm/eYjexpJlSs4teJieTI 6HpIwKk++VlyHCK35p6On7OiooHR/Q3Zkp0Vlpjn/uWq16nyGWfUi+y/o2nPvBWQIy TdICN7VaV/yljNo2ct3b1BgiZurgDPqq5KKtV4oEJzk+IRHiCeN1bN8VUAWALNt9Xb /N1nzkQsyoRj5p6g4EE7MA+iuv0TbMBt5NmTPnM/Ea7JJsSV7tNTV+ZtVT/bWCqTjb vMk+Ox6qSiAA+SP2298arFuwVB6CjkDAFh3ayljQMKBLDBOzdQpFceyNQ4hHR4WhTn wyAl6zqGzk4Pw== To: Zac Greenwood From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <157744394-3dec42994f1798ce65b00e23b21ea656@pmq2v.m5r2.onet> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript 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, 25 Feb 2022 03:19:45 -0000 Good morning Zac, > Hi=C2=A0ZmnSCPxj, > > Any benefits of my proposal depend on my presumption that using a standar= d transaction for storing data must be inefficient. Presumably a transactio= n takes up significantly more on-chain space than the data it carries withi= n its OP_RETURN. Therefore, not requiring a standard transaction for data s= torage should be more efficient. Facilitating data storage within some spec= ialized, more space-efficient data structure at marginally lower fee per pa= yload-byte should enable reducing the footprint of storing data on-chain. > > In case storing data through OP_RETURN embedded within a transaction is o= ptimal in terms of on-chain footprint then my proposal doesn=E2=80=99t seem= useful. You need to have some assurance that, if you pay a fee, this data gets on t= he blockchain. And you also need to pay a fee for the blockchain space. In order to do that, you need to indicate an existing UTXO, and of course y= ou have to provably authorize the spend of that UTXO. But that is already an existing transaction structure, the transaction inpu= t. If you are not going to pay an entire UTXO for it, you need a transaction o= utput as well to store the change. Your signature needs to cover the data being published, and it is more effi= cient to have a single signature that covers the transaction input, the tra= nsaction output, and the data being published. We already have a structure for that, the transaction. So an `OP_RETURN` transaction output is added and you put published data th= ere, and existing constructions make everything Just Work (TM). Now I admit we can shave off some bytes. Pure published data does not need an amount, and using a transaction output= means there is always an amount field. We do not want the `OP_RETURN` opcode itself, though if the data is variabl= e-size we do need an equivalent to the `OP_PUSH` opcode (which has many var= iants depending on the size of the data). But that is not really a lot of bytes, and adding a separate field to the t= ransaction would require a hardfork. We cannot use the SegWit technique of just adding a new field that is not s= erialized for `txid` and `wtxid` calculations, but is committed in a new id= , let us call it `dtxid`, and a new Merkle Tree added to the coinbase. If we *could*, then a separate field for data publication would be softfork= able, but the technique does not apply here. The reason we cannot use that technique is that we want to save bytes by ha= ving the signature cover the data to be published, and signatures need to b= e validated by pre-softfork nodes looking at just the data committed to in = `wtxid`. If you have a separate signature that is in the `dtxid`, then you spend mor= e actual bytes to save a few bytes. Saving a few bytes for an application that is arguably not the "job" of Bit= coin (Bitcoin is supposed to be for value transfer, not data archiving) is = not enough to justify a **hard**fork. And any softfork seems likely to spend more bytes than what it could save. Regards, ZmnSCPxj