Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 53F7DC0011 for ; Thu, 24 Feb 2022 13:27:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 3B43A416BF for ; Thu, 24 Feb 2022 13:27:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 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, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Qks8GH3jGTz for ; Thu, 24 Feb 2022 13:27:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpo104.poczta.onet.pl (smtpo104.poczta.onet.pl [213.180.149.157]) by smtp4.osuosl.org (Postfix) with ESMTPS id 99D044168F for ; Thu, 24 Feb 2022 13:27:27 +0000 (UTC) Received: from pmq8v.m5r2.onet (pmq8v.m5r2.onet [10.174.35.145]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4K4DGc0cj3z1mkZ; Thu, 24 Feb 2022 14:27:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1645709240; bh=Uc+wXJpXbKOe8D1HlDQklzW77F06/BTpC01jNQ86aTQ=; h=From:To:In-Reply-To:Date:Subject:From; b=ZVNPXjt3irUhWSHK1eMTh3Puj83J3FFTr1GwqKIuR8upDDI86GL+XLUTD+RATg8iV mFiQ0Xmq1Dj3Wh6JgFwKLvbIflQ0BMq4k+TiVnPhJdDmj6hDDgaMVf8vM6khQRbhzK 11T2F+2FWt1ai0npvrlZ7pSnPsc5uq5VGMsD5O44= Content-Type: multipart/alternative; boundary="===============0492176150504212196==" MIME-Version: 1.0 Received: from [82.177.167.2] by pmq8v.m5r2.onet via HTTP id ; Thu, 24 Feb 2022 14:27:20 +0100 From: vjudeu@gazeta.pl X-Priority: 3 To: Ruben Somsen , Bitcoin Protocol Discussion In-Reply-To: Date: Thu, 24 Feb 2022 14:27:16 +0100 Message-Id: <132554114-6b0ae655e1150c240f98f8f865924478@pmq8v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;82.177.167.2;PL;2 X-Mailman-Approved-At: Thu, 24 Feb 2022 14:06:43 +0000 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: Thu, 24 Feb 2022 13:27:29 -0000 This is a multi-part message in MIME format. --===============0492176150504212196== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable > Also, tweaking an ECC point (this includes tapscript) in non-deterministi= c ways also makes it harder to recover from backup, because you can't recov= er the key without knowing the full commitment. I don't think so. You can spend coins from taproot by key or by script. If = you spend by key, making backup is simple, we have WIF for that. If you spe= nd by script, you only need a part of the tree. So, you can "recover the ke= y without knowing the full commitment", because you can spend coins "withou= t knowing the full commitment". On-chain, you never reveal your "OP_RETURN = " or "OP_RETURN " or " OP_RE= TURN ". Those additional branches are stored only by those w= ho wants their data to be connected with some key, knowing the full script = is not needed, because it is not needed for on-chain validation. > Furthermore, the scheme is not actually equivalent to op_return, because = it requires the user to communicate out-of-band to reveal the commitment, w= hereas with op_return the data is immediately visible (while not popular, B= IP47 and various colored coin protocols rely on this). Yes, but storing that additional data on-chain is not needed. It is expensi= ve. By paying one satoshi per byte, you would pay 0.01 BTC for pushing 1 MB= of data. That means 1 BTC for 100 MB of data, so 15 BTC for that 1.5 GB fi= le. And in practice it is the absolute minimum, because you have to wrap yo= ur data somehow, you cannot just push 1.5 GB file. By placing that in TapSc= ript, you can use your taproot public key as usual and attach any data into= your key for "free", because it takes zero additional bytes on-chain. On 2022-02-24 11:08:39 user Ruben Somsen wrote: Note this has=C2=A0always been possible, and is not specifically related to= tapscript. As long as you're committing to an ECC point, you can tweak it = to commit data inside it (i.e. pay-to-contract). This includes P2PK and P2P= KH. =C2=A0 Committing to 1.5GB of data has equally been possible with OP_RETURN = , or even an entire merkle tree of hashes, as is the case with Todd's opent= imestamps. =C2=A0 Also, tweaking an ECC point (this includes tapscript)=C2=A0in non-determini= stic ways also makes it harder to recover from backup, because you can't re= cover the key without knowing the full commitment. =C2=A0 Furthermore, the scheme is not actually equivalent to op_return, because it= =C2=A0requires the user to communicate out-of-band to reveal the commitment= , whereas with op_return the data is immediately visible (while not popular= , BIP47 and various colored coin protocols rely on this). =C2=A0 Cheers, Ruben =C2=A0 On Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev wrote: 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? _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --===============0492176150504212196== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable
> Also, tweaking an ECC point (this includes tapscript) in non-dete= rministic ways also makes it harder to recover from backup, because you can= 't recover the key without knowing the full commitment.

I don't = think so. You can spend coins from taproot by key or by script. If you spen= d by key, making backup is simple, we have WIF for that. If you spend by sc= ript, you only need a part of the tree. So, you can "recover the key withou= t knowing the full commitment", because you can spend coins "without knowin= g the full commitment". On-chain, you never reveal your "OP_RETURN <data= >" or "OP_RETURN <hash>" or "<tapbranch> <tapbranch> &= lt;tapbranch> OP_RETURN <chunk_of_data>". Those additional branche= s are stored only by those who wants their data to be connected with some k= ey, knowing the full script is not needed, because it is not needed for on-= chain validation.

> Furthermore, the scheme is not actually e= quivalent to op_return, because it requires the user to communicate out-of-= band to reveal the commitment, whereas with op_return the data is immediate= ly visible (while not popular, BIP47 and various colored coin protocols rel= y on this).

Yes, but storing that additional data on-chain is no= t needed. It is expensive. By paying one satoshi per byte, you would pay 0.= 01 BTC for pushing 1 MB of data. That means 1 BTC for 100 MB of data, so 15= BTC for that 1.5 GB file. And in practice it is the absolute minimum, beca= use you have to wrap your data somehow, you cannot just push 1.5 GB file. B= y placing that in TapScript, you can use your taproot public key as usual a= nd attach any data into your key for "free", because it takes zero addition= al bytes on-chain.

On 2022-02-24 11:08:39 user Ruben Somsen <rsomsen@gmail.com> wro= te:
Note this has always been possible, and is not specif= ically related to tapscript. As long as you're committing to an ECC point, = you can tweak it to commit data inside it (i.e. pay-to-contract). This incl= udes P2PK and P2PKH.
 
Committing to 1.5GB of data has equally been possible with OP_RETURN &= lt;hash>, or even an entire merkle tree of hashes, as is the case with T= odd's opentimestamps.
 
Also, tweaking an ECC point (this includes tapscript) in non-dete= rministic ways also makes it harder to recover from backup, because you can= 't recover the key without knowing the full commitment.
 
Furthermore, the scheme is not actually equivalent to op_return, becau= se it requires the user to communicate out-of-band to reveal the commi= tment, whereas with op_return the data is immediately visible (while not po= pular, BIP47 and various colored coin protocols rely on this).
 
Cheers,
Ruben
 

On Thu, Feb 24, 2022 at 10:19 AM vjud= eu via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wro= te:
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?
_______________________________________________
bitcoin-dev mailing li= st
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/li= stinfo/bitcoin-dev
--===============0492176150504212196==--