Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 940DAC0011 for ; Thu, 24 Feb 2022 09:02:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 83F248305A for ; Thu, 24 Feb 2022 09:02:19 +0000 (UTC) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl 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 KGMmijhRfPu0 for ; Thu, 24 Feb 2022 09:02:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpo91.poczta.onet.pl (smtpo91.poczta.onet.pl [213.180.149.144]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5782D83033 for ; Thu, 24 Feb 2022 09:02:18 +0000 (UTC) Received: from pmq2v.m5r2.onet (pmq2v.m5r2.onet [10.174.32.68]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4K46Nf1WLyzlj1p7 for ; Thu, 24 Feb 2022 10:02:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1645693330; bh=UjzvI+RPdgOAJ09zo55eod+lFA+0K74HFezk1ksK5c4=; h=From:To:Date:Subject:From; b=kvKbxwYNoyhANpnhexmb/YThPiVR0JjxYYyjXye9ztE6x0TdlTucdzrZQwN0iG7+v 4mHfH5erjOpymax1VclZTKYG32IyAfBKqJL6RXhEW7uMvM130kE7HyABuw8qqLknH9 1u+ofm6ytGYY6SHuz6D9YtZ0yRkUkdVepB6wnxu0= Content-Type: multipart/alternative; boundary="===============8474703993444243669==" MIME-Version: 1.0 Received: from [82.177.167.2] by pmq2v.m5r2.onet via HTTP id ; Thu, 24 Feb 2022 10:02:10 +0100 From: vjudeu@gazeta.pl X-Priority: 3 To: "bitcoin-dev@lists.linuxfoundation.org" Date: Thu, 24 Feb 2022 10:02:08 +0100 Message-Id: <157744394-3dec42994f1798ce65b00e23b21ea656@pmq2v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;82.177.167.2;PL;1 X-Mailman-Approved-At: Thu, 24 Feb 2022 09:18:52 +0000 Subject: [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: Thu, 24 Feb 2022 09:02:19 -0000 This is a multi-part message in MIME format. --===============8474703993444243669== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Since Taproot was activated, we no longer need separate OP_RETURN outputs t= o be pushed on-chain. If we want to attach any data to a transaction, we ca= n create "OP_RETURN " as a branch in the TapScript. In this way, = we can store that data off-chain and we can always prove that they are conn= ected with some taproot address, that was pushed on-chain. Also, we can sto= re more than 80 bytes for "free", because no such taproot branch will be ev= er pushed on-chain and used as an input. That means we can use "OP_RETURN <= 1.5 GB of data>", create some address having that taproot branch, and later= prove to anyone that such "1.5 GB of data" is connected with our taproot a= ddress. =C2=A0 Currently in Bitcoin Core we have "data" field in "createrawtransaction". S= hould the implementation be changed to place that data in a TapScript inste= ad of creating separate OP_RETURN output? What do you think? --===============8474703993444243669== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
Since Taproot was activated, we no longer need separate OP_RETURN outp= uts to be pushed on-chain. If we want to attach any data to a transaction, = we can create "OP_RETURN <anything>" as a branch in the TapScript. In= this way, we can store that data off-chain and we can always prove that th= ey are connected with some taproot address, that was pushed on-chain. Also,= we can store more than 80 bytes for "free", because no such taproot branch= will be ever pushed on-chain and used as an input. That means we can use "= OP_RETURN <1.5 GB of data>", create some address having that taproot = branch, and later prove to anyone that such "1.5 GB of data" is connected w= ith our taproot address.
 
Currently in Bitcoin Core we have "data" field in "createrawtransactio= n". Should the implementation be changed to place that data in a TapScript = instead of creating separate OP_RETURN output? What do you think?
--===============8474703993444243669==--