Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 172A7C001A for ; Fri, 25 Feb 2022 13:54:11 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id E4F66401D5 for ; Fri, 25 Feb 2022 13:54:10 +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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 hNfJLBLALoDg for ; Fri, 25 Feb 2022 13:54:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) by smtp2.osuosl.org (Postfix) with ESMTPS id A54374000B for ; Fri, 25 Feb 2022 13:54:09 +0000 (UTC) Received: by mail-io1-xd2d.google.com with SMTP id d19so6531982ioc.8 for ; Fri, 25 Feb 2022 05:54:09 -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=TFokXaE9xmC+Lng3V2x8Gwvnu0prM5q5WRnCJDckPZQ=; b=e9DaKE40tKGb8YZ70Wmv3p1SrXRyQnwzSJq/2BMsY5BRgxLJjoaBekXoParMdUhqSH pI0SGeiWxVMWY2GZwD94Lt4As1aw56uyak5Ymh4GfxON5ZWJhT0dkqNxYRfH8qAzU4/h k+SWa3Yz7Kxw2NltVTnPFXdbfCVvDEgoXYbNAi92ZDp1irzOJq1s7YZ4eVFCqImS7qIA s7i13HW7c8QLq6+qPp2/27QfsD2fbEWNoMZtOnKmm1I06UX5ot97uCcFZSwG+UWg5Geu bz6Ri/DDSYHQwt4uuyv1XREWXluc3rmjSJvx2eP2MC213WQQ9UgxQUzQl284fjAK3xFW iu2A== 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=TFokXaE9xmC+Lng3V2x8Gwvnu0prM5q5WRnCJDckPZQ=; b=KyK33ZmEz1oAtzjjLAEvFYjEAbGNgfcc97CDcBAYoEGNqEcaCIjWhBF4mBY3nFV2ov 1yGQ5w5gga8w87ciFkJAgI5UqpM63iI8+idrhMLao9BJEr/zNYXby0+IbGf/Iqou0Mrt wTosh/9NF5OFu6Vvg5h56ClusxJbtkXOsnPXDgK8SNquLHQ4zVLY+aDYJJjH0QB+02xK J9QhKTLmXLKpdNjYfr7d+FP6tIOXd9SOPpB1XAw7REkGejKBxlLSk+Bsx3RWY9HbwQP6 5UAEWPX1qP0WYB1JCAiqSH1ENL5Cr43XllGQ+dsRk5IfsTWVwRDMdTuKyxleEHpn+SAt UtfA== X-Gm-Message-State: AOAM531wu7FMWt4LTFz4XRmVwN9U3GFER5+oklspMPaKEjtQdEG+v1AC lOobPUYNoaZMjX4zXIKhVVKXUr0DaB8y83hZAi/I8R8g X-Google-Smtp-Source: ABdhPJx0Z17KRAUX49nVMZRpXeQVu6PiPh02pX/RSgUX37RfbLDQkaZugsilBwY9dg34WDNRHJI4i9ZVkt+TmvTm1TM= X-Received: by 2002:a05:6638:d52:b0:314:d4d9:f8e4 with SMTP id d18-20020a0566380d5200b00314d4d9f8e4mr5889817jak.139.1645797248654; Fri, 25 Feb 2022 05:54:08 -0800 (PST) MIME-Version: 1.0 References: <157744394-3dec42994f1798ce65b00e23b21ea656@pmq2v.m5r2.onet> In-Reply-To: From: Zac Greenwood Date: Fri, 25 Feb 2022 14:53:57 +0100 Message-ID: To: ZmnSCPxj Content-Type: multipart/alternative; boundary="00000000000060df3505d8d808d5" X-Mailman-Approved-At: Fri, 25 Feb 2022 14:20:40 +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 13:54:11 -0000 --00000000000060df3505d8d808d5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi ZmnSCPxj, > Either you consume the entire UTXO (take away the "U" from the "UTXO") completely and in full, or you do not touch the UTXO Ok, so enabling spending a UTXO partly would be a significant departure from the systems=E2=80=99 design philosophy. I have been unclear about the fee part. In my proposal there=E2=80=99s only= one input and zero outputs, so normally there would be no way to set any fee. One could add a fee field although that would be slightly wasteful =E2=80= =94 it may be sufficient to just specify the fee *rate*, for instance 0-255 sat/payload_byte, requiring only one byte for the fee. The calculation of the actual fee can be performed by both the network and the sender. The fee equals payload_size*feerate + an-amount-calculated-by-preset-rules-such-that-it-raises-the-cost-of-the-tr= ansaction-to-only-marginally-less-than-what-it would-have-cost-to-store-the-same-amount-of-data-using-one-or-more-OP_RETUR= N-transactions. However explicitly specifying the fee amount is probably preferable for the sake of transparency. I wonder if this proposal could technically work. I fully recognize though that even if it would, it has close to zero chances becoming reality as it breaks the core design based on *U*TXOs (and likely also a lot of existing software) =E2=80=94 thank you for pointing that out and for your helpful fe= edback. Zac On Fri, 25 Feb 2022 at 13:48, ZmnSCPxj wrote: > Good morning Zac, > > > 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= network could > subtract the fee amount of the transaction directly from the specified UT= XO. > > That is not how UTXO systems like Bitcoin work. > Either you consume the entire UTXO (take away the "U" from the "UTXO") > completely and in full, or you do not touch the UTXO (and cannot get fees > from it). > > > A fee also need not to be specified. > > Fees are never explicit in Bitcoin; it is always the difference between > total input amount minus the total output amount. > > > It can be calculated in advance both by the network and the transaction > sender based on the size of the data. > > It is already implicitly calculated by the difference between the total > input amount minus the total output amount. > > You seem to misunderstand as well. > Fee rate is computed from the fee (computed from total input minus total > output) divided by the transaction weight. > Nodes do not compute fees from feerate and weight. > > > The calculation of the fee should be such that it only marginally > cheaper to use this new construct over using one or more transactions. Fo= r > 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). > > Do you want to change weight calculations? > *reducing* weight calculations is a hardfork, increasing it is a softfork= . > > > 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 = hardfork, > sadly. > > See above note, if you want to somehow reduce the weight of the data so a= s > to reduce the cost of data relative to `OP_RETURN`, that is a hardfork. > > Regards, > ZmnSCPxj > --00000000000060df3505d8d808d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj,

>=C2=A0Either you consume the entire UTXO (ta= ke away the "U" from the "UTXO") completely and in full= , or you do not touch the UTXO

Ok, so enablin= g spending a UTXO partly would be a significant departure from the systems= =E2=80=99 design philosophy.

I have been unclear about t= he fee part. In my proposal there=E2=80=99s only one input and zero outputs= , so normally there would be no way to set any fee. One could add a fee fie= ld although that would be slightly wasteful =E2=80=94 it may be sufficient = to just specify the fee *rate*, for instance 0-255 sat/payload_byte, requir= ing only one byte for the fee. The calculation of the actual fee can be per= formed by both the network and the sender. The fee equals payload_size*feer= ate + an-amount-calculated-by-preset-rules-such-that-it-raises-the-cost-of-= the-transaction-to-only-marginally-less-than-what-it would-have-cost-to-sto= re-the-same-amount-of-data-using-one-or-more-OP_RETURN-transactions.=

= However explicitly specifying the fee amount is probably preferable for the= sake of transparency.

I wond= er if this proposal could technically work. I fully recognize though that e= ven if it would, it has close to zero chances becoming reality as it breaks= the core design based on *U*TXOs (and likely also a lot of existing softwa= re) =E2=80=94 thank you for pointing that out and for your helpful feedback= .

Zac


On Fri, 25 Feb 2022 at 13:48= , ZmnSCPxj <ZmnSCPxj@protonma= il.com> wrote:
Good morning Zac,

> 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. Th= e network could subtract the fee amount of the transaction directly from th= e specified UTXO.

That is not how UTXO systems like Bitcoin work.
Either you consume the entire UTXO (take away the "U" from the &q= uot;UTXO") completely and in full, or you do not touch the UTXO (and c= annot get fees from it).

> A fee also need not to be specified.

Fees are never explicit in Bitcoin; it is always the difference between tot= al input amount minus the total output amount.

> It can be calculated in advance both by the network and the transactio= n sender based on the size of the data.

It is already implicitly calculated by the difference between the total inp= ut amount minus the total output amount.

You seem to misunderstand as well.
Fee rate is computed from the fee (computed from total input minus total ou= tput) divided by the transaction weight.
Nodes do not compute fees from feerate and weight.

> The calculation of the fee should be such that it only marginally chea= per to use this new construct over using one or more transactions. For inst= ance, sending 81 bytes should cost as much as two OP_RETURN transactions (m= inus some marginal discount to incentivize the use of this more efficient w= ay to store data).

Do you want to change weight calculations?
*reducing* weight calculations is a hardfork, increasing it is a softfork.<= br>
> If the balance of the selected UTXO is insufficient to pay for the dat= a then the transaction will be invalid.
>
> I can=E2=80=99t judge whether this particular approach would require a= hardfork, sadly.

See above note, if you want to somehow reduce the weight of the data so as = to reduce the cost of data relative to `OP_RETURN`, that is a hardfork.

Regards,
ZmnSCPxj
--00000000000060df3505d8d808d5--