Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7FD13C001A for ; Fri, 25 Feb 2022 07:15:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 687AF83774 for ; Fri, 25 Feb 2022 07:15:19 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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 uqQySzvsHty4 for ; Fri, 25 Feb 2022 07:15:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) by smtp1.osuosl.org (Postfix) with ESMTPS id 22A7E83490 for ; Fri, 25 Feb 2022 07:15:18 +0000 (UTC) Received: by mail-io1-xd2f.google.com with SMTP id s1so5505453iob.9 for ; Thu, 24 Feb 2022 23:15:18 -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=SJGwQaJ8X0hx1EQgj2MSvGbAFU0n3iqHMoqoEyd8COk=; b=AMF8Y3uL6CFMSvjFBPmUDZwj4D4RvhJbfly9dMWZ0rUeOSZP9SnxIGOHya9/sXbOS9 DwtGWeEFtOxV05frMCEiiEg1HTRmq935j0cfIPevYr90EF+lKApmrtqjH98hKoUcO38k +tjjMv9YRvHHLEI91o96o/GT4OT8xIFAUi11Z+Zuqgj26GIPzZwzH3O4S+YDq7+TxsnE fEZ2EOYyHbgdVEVQ+1tJUqkwbVgJUh5wQT+mMMp2JEnlrwVTfszg/dYIZK6Km29Hj7Cb 3TNnZmCq53S7HMVVX/jnfg9+kGDaJNRTiCanucBDM2nJiccA3Z7IjArwZDsZFDaIBsFj 4qoA== 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=SJGwQaJ8X0hx1EQgj2MSvGbAFU0n3iqHMoqoEyd8COk=; b=n+60RtPoi6s/fa0+BISweGfpmI0i9CAy5eyHPHt1RC2TN3rn2oa/g0MU6ZHiyl2dTA Ir2IngZ/w61GF7jlWP8o0DFtn9G5S3hLhWCz3hHnsYIz3dJkummLCMxM+2b0gAl/o0h5 rERXd/3Z2xd9/cK9JWrhvvu1IiYM5/k6ZHeTf2otzY5iUrcONhb6XaCFH2V1cs+nKiCt WKqWJYXbjvR6iYbjLNTVoWkSPCHLqV3NrSqIzeXjGcZu+gk216rfzIMnGZC7wqT9/EcW MJBO/aygtCxu1V5rYrWTIcGJsawD5MxocaZkqFuag+pKDLGpoDOMWpgqbPxk4+EEMNps hQ9A== X-Gm-Message-State: AOAM5323Z/vlhnBvYFLYyMJhMC6rrLxgAWKcoEMdduE2FIKMOn5u18tG g6a+aSMydHjTOUYGQJ1KEhfdSnPJPOuUaGvqRG4= X-Google-Smtp-Source: ABdhPJx+F55zs51s+SeA2vKe0zUYCNMZ5a70gKhU8m5fJhDQ5Wo+1av3D0R2ddcNItn9XKuZTmQncJgAaeRfeo72kzk= X-Received: by 2002:a5d:8b06:0:b0:642:1ca5:9551 with SMTP id k6-20020a5d8b06000000b006421ca59551mr1863335ion.141.1645773317296; Thu, 24 Feb 2022 23:15:17 -0800 (PST) MIME-Version: 1.0 References: <157744394-3dec42994f1798ce65b00e23b21ea656@pmq2v.m5r2.onet> In-Reply-To: From: Zac Greenwood Date: Fri, 25 Feb 2022 08:15:06 +0100 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="000000000000f5564d05d8d275d0" X-Mailman-Approved-At: Fri, 25 Feb 2022 08:47:56 +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: Fri, 25 Feb 2022 07:15:19 -0000 --000000000000f5564d05d8d275d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi ZmnSCPxj, To me it seems that more space can be saved. The data-=E2=80=9Ctransaction=E2=80=9D need not specify any output. The net= work could subtract the fee amount of the transaction directly from the specified UTXO. A fee also need not to be specified. It can be calculated in advance both by the network and the transaction sender based on the size of the data. The calculation of the fee should be such that it only marginally cheaper to use this new construct over using one or more transactions. For instance, sending 81 bytes should cost as much as two OP_RETURN transactions (minus some marginal discount to incentivize the use of this more efficient way to store data). If the balance of the selected UTXO is insufficient to pay for the data then the transaction will be invalid. I can=E2=80=99t judge whether this particular approach would require a hard= fork, sadly. Zac On Fri, 25 Feb 2022 at 04:19, ZmnSCPxj wrote: > Good morning Zac, > > > Hi ZmnSCPxj, > > > > Any benefits of my proposal depend on my presumption that using a > standard transaction for storing data must be inefficient. Presumably a > transaction takes up significantly more on-chain space than the data it > carries within its OP_RETURN. Therefore, not requiring a standard > transaction for data storage should be more efficient. Facilitating data > storage within some specialized, more space-efficient data structure at > marginally lower fee per payload-byte should enable reducing the footprin= t > of storing data on-chain. > > > > In case storing data through OP_RETURN embedded within a transaction is > optimal in terms of on-chain footprint then my proposal doesn=E2=80=99t s= eem useful. > > You need to have some assurance that, if you pay a fee, this data gets on > the 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 > you have to provably authorize the spend of that UTXO. > But that is already an existing transaction structure, the transaction > input. > If you are not going to pay an entire UTXO for it, you need a transaction > output as well to store the change. > > Your signature needs to cover the data being published, and it is more > efficient to have a single signature that covers the transaction input, t= he > transaction 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 > there, 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 > variable-size we do need an equivalent to the `OP_PUSH` opcode (which has > many variants depending on the size of the data). > > But that is not really a lot of bytes, and adding a separate field to the > transaction would require a hardfork. > We cannot use the SegWit technique of just adding a new field that is not > serialized 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 > softforkable, but the technique does not apply here. > The reason we cannot use that technique is that we want to save bytes by > having the signature cover the data to be published, and signatures need = to > be 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 > more actual bytes to save a few bytes. > > Saving a few bytes for an application that is arguably not the "job" of > Bitcoin (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 > --000000000000f5564d05d8d275d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0ZmnSCPxj,

To me it seems that more s= pace can be saved.

The data-=E2=80=9Ctransaction=E2=80=9D need not specify any outpu= t. The network could subtract the fee amount of the transaction directly fr= om the specified UTXO. A fee also need not to be specified. It can be calcu= lated in advance both by the network and the transaction sender based on th= e size of the data.

The calculation of the fee should be such that it o= nly marginally cheaper to use this new construct over using one or more tra= nsactions. For instance, sending 81 bytes should cost as much as two OP_RET= URN transactions (minus some marginal discount to incentivize the use of th= is more efficient way to store data).

If the balance of the selected U= TXO is insufficient to pay for the data then the transaction will be invali= d.

I can=E2=80=99t judge whether this particular approach would require = a hardfork, sadly.

<= /div>
Zac


On Fri, 25 Feb 2022 at 04:19, ZmnSCPxj <= ZmnSCPxj@protonmail.com> = wrote:
Good morning Zac,

> Hi=C2=A0ZmnSCPxj,
>
> Any benefits of my proposal depend on my presumption that using a stan= dard transaction for storing data must be inefficient. Presumably a transac= tion takes up significantly more on-chain space than the data it carries wi= thin its OP_RETURN. Therefore, not requiring a standard transaction for dat= a storage should be more efficient. Facilitating data storage within some s= pecialized, more space-efficient data structure at marginally lower fee per= payload-byte should enable reducing the footprint of storing data on-chain= .
>
> In case storing data through OP_RETURN embedded within a transaction i= s optimal in terms of on-chain footprint then my proposal doesn=E2=80=99t s= eem 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&qu= ot; of Bitcoin (Bitcoin is supposed to be for value transfer, not data arch= iving) is not enough to justify a **hard**fork.
And any softfork seems likely to spend more bytes than what it could save.<= br>
Regards,
ZmnSCPxj
--000000000000f5564d05d8d275d0--