Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5FA07C0011 for ; Thu, 24 Feb 2022 14:02:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 3F06A82C1E for ; Thu, 24 Feb 2022 14:02:13 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 LNp2I8ThXN26 for ; Thu, 24 Feb 2022 14:02:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com [IPv6:2607:f8b0:4864:20::1132]) by smtp1.osuosl.org (Postfix) with ESMTPS id 3AD4E83381 for ; Thu, 24 Feb 2022 14:02:12 +0000 (UTC) Received: by mail-yw1-x1132.google.com with SMTP id 00721157ae682-2d646fffcc2so26355967b3.4 for ; Thu, 24 Feb 2022 06:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mc4eEIvtGsTYPTINRO47QWaC7WnfowMYFhA8yImO1LE=; b=l2EsDn2neL0jfVQjZHcGVoXT35LqOZnVVGkUz44nTVQv8xAk92r37jpo7/z95Q7Cmo y2BMP4+Km0dSs5XwH9knot/v8tLn+bSGcIJQ2O+cQ7erUQyzIMuBNH/EZB8uSQfmHwBF wD35LDXYEpUM3iISu1Pc5BlgCx6hYmMtrpfbyfSSs6XUcxf1O/9UqzBKNYswsCwyrxT9 I31J6/Y+i7ePZ3seUwpaYnPFGndj0onMcNuhZuzFJ92jKMsMQHMpfIGX6AzG23FCJSBm DVlOlAILY6B735nfZ7u/sFk6Yw0JIMi53y/yhcR6Etqwl/Yo4P/ZC1IN0N7lZcNq14RA q6OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mc4eEIvtGsTYPTINRO47QWaC7WnfowMYFhA8yImO1LE=; b=1HhpIiyDIljko4sf5PROzPZb42VyRr29qmz/01KxrOAmCB9hOatpZBX2zyeXXf5hHF +YQ1p7HI9cCLe2HQCPaXymJThlx4P5i89RNXuN+Wto4p+cLgEH014b5kGbaCCtJBPYzw sf1ZtJ4YgHs08HNA3Gtg5Qa0QzYMTD67evJm+Il4YJ9mEigFnD3vVCbP2cpdopGFtG6v Nrdx9c8A5bMHqLXbGsT/Tct4spi+yZ2oV/1R5rMg5PEEYDFADiRA3WCyE7qyujTMywQ6 PiaQmHjZ0zIVAfZxZwFCTp30LKUQ8Y8Txeb9pBfiS1JKQkpxwCm41TOwt23gcGzYdK/s hvjA== X-Gm-Message-State: AOAM530E+sI5oQd70etezrshkBrLzV5PMk/pyRR0yH9im511YlZ+/ofD tgdjFcKFxZy37rQ+OKtFbS+b2enxszsWSJsGyhjjMPuB X-Google-Smtp-Source: ABdhPJzF8P7Kq4hn6X2BkQcZfcjn0CUAXSqxT/C3RecxitusCoUJ0wLRB9jK3DNcZZYAK9nl/8O/JgYUTrv835c5zaU= X-Received: by 2002:a81:7094:0:b0:2d1:9e5:1288 with SMTP id l142-20020a817094000000b002d109e51288mr2467252ywc.283.1645711331129; Thu, 24 Feb 2022 06:02:11 -0800 (PST) MIME-Version: 1.0 References: <132554114-6b0ae655e1150c240f98f8f865924478@pmq8v.m5r2.onet> In-Reply-To: <132554114-6b0ae655e1150c240f98f8f865924478@pmq8v.m5r2.onet> From: Ruben Somsen Date: Thu, 24 Feb 2022 15:01:58 +0100 Message-ID: To: vjudeu Content-Type: multipart/alternative; boundary="0000000000004b7b0a05d8c4077f" X-Mailman-Approved-At: Thu, 24 Feb 2022 14:06:43 +0000 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: Thu, 24 Feb 2022 14:02:13 -0000 --0000000000004b7b0a05d8c4077f Content-Type: text/plain; charset="UTF-8" In Q = P + hash(P||commitment)G you cannot spend from Q without knowing both the private key of P as well as the commitment (i.e. 32 bytes, assuming the commitment itself is another hash). This is generally not a problem for tapscript, as the scripts are deterministically generated (i.e. backing up the policy once is sufficient), but what you are suggesting is not deterministic. Hope that clarifies things. On Thu, Feb 24, 2022 at 2:27 PM wrote: > > Also, tweaking an ECC point (this includes tapscript) in > non-deterministic 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 spend by key, making backup is simple, we have WIF for that. If you > spend by script, you only need a part of the tree. So, you can "recover the > key without knowing the full commitment", because you can spend coins > "without knowing the full commitment". On-chain, you never reveal your > "OP_RETURN " or "OP_RETURN " or " > OP_RETURN ". Those additional branches are > stored only by those who 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, > whereas with op_return the data is immediately visible (while not popular, > BIP47 and various colored coin protocols rely on this). > > Yes, but storing that additional data on-chain is not 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, because you > have to wrap your data somehow, you cannot just push 1.5 GB file. By > placing that in TapScript, 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 always 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 > P2PKH. > > 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 > opentimestamps. > > Also, tweaking an ECC point (this includes tapscript) in non-deterministic > 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, because > it requires 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). > > Cheers, > Ruben > > > On Thu, Feb 24, 2022 at 10:19 AM vjudeu via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org > > > wrote: > >> Since Taproot was activated, we no longer need separate OP_RETURN outputs >> to be pushed on-chain. If we want to attach any data to a transaction, we >> can 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 >> 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 with our >> taproot address. >> >> Currently in Bitcoin Core we have "data" field in "createrawtransaction". >> 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 list >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --0000000000004b7b0a05d8c4077f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In Q =3D P=C2=A0+ hash(P||commitment)G you cannot spend fr= om Q without knowing both the private key of P as well as the commitment (i= .e. 32 bytes, assuming the commitment itself is another hash). This is gene= rally not a problem for tapscript, as the scripts are deterministically gen= erated (i.e. backing up the policy once is sufficient), but what you are su= ggesting is not deterministic. Hope that clarifies things.

On Thu, Feb 24, 2= 022 at 2:27 PM <vjudeu@gazeta.pl= > wrote:
> Also, tweaking an ECC point (this includes tapscript) in non-determin= istic 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 w= ithout knowing the full commitment", because you can spend coins "= ;without knowing the full commitment". On-chain, you never reveal your= "OP_RETURN <data>" or "OP_RETURN <hash>" o= r "<tapbranch> <tapbranch> <tapbranch> OP_RETURN <= ;chunk_of_data>". Those additional branches are stored only by thos= e who wants their data to be connected with some key, knowing the full scri= pt is not needed, because it is not needed for on-chain validation.

= > Furthermore, the scheme is not actually equivalent to op_return, becau= se it requires 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).

Yes, but s= toring that additional data on-chain is not needed. It is expensive. By pay= ing 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, because you have to wrap your data so= mehow, you cannot just push 1.5 GB file. By placing that in TapScript, 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.
<= br>
On 2022-02-24 11:08:39 user Ruben Somsen <rsomsen@gmail.com> wrote:
Note this has=C2=A0always been possible, and is not specif= ically related to tapscript. As long as you're committing to an ECC poi= nt, you can tweak it to commit data inside it (i.e. pay-to-contract). This = includes P2PK and P2PKH.
=C2=A0
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.
=C2=A0
Also, tweaking an ECC point (this includes tapscript)=C2=A0in non-dete= rministic ways also makes it harder to recover from backup, because you can= 't recover the key without knowing the full commitment.
=C2=A0
Furthermore, the scheme is not actually equivalent to op_return, becau= se it=C2=A0requires 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).
=C2=A0
Cheers,
Ruben
=C2=A0

On Thu, Feb 24, 2022 at 10:19 AM vjud= eu via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org&g= t; wrote:
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 Tap= Script. In this way, we can store that data off-chain and we can always pro= ve that they are connected with some taproot address, that was pushed on-ch= ain. 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. Tha= t means we can use "OP_RETURN <1.5 GB of data>", create som= e address having that taproot branch, and later prove to anyone that such &= quot;1.5 GB of data" is connected with our taproot address.
=C2=A0
Currently in Bitcoin Core we have "data" field in "crea= terawtransaction". 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 list=
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/list= info/bitcoin-dev
--0000000000004b7b0a05d8c4077f--