From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Zac Greenwood <zachgrw@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_RETURN inside TapScript
Date: Fri, 25 Feb 2022 12:48:11 +0000 [thread overview]
Message-ID: <JGiZgKJbF8rNYsQfjHNeqRqRUyfUuGaP0_W7Y9-uyyhDF0odqoF3dPitBwe7uXmhUh8TcwFOYGymzrgMhc2Kgq9NovHQSf_d0jRsDFH3zuk=@protonmail.com> (raw)
In-Reply-To: <CAJ4-pEDAKPFQF-tuzYw+Hc0moViZ4kyoVz91mESkqb-GQZ35aQ@mail.gmail.com>
Good morning Zac,
> Hi ZmnSCPxj,
>
> To me it seems that more space can be saved.
>
> The data-“transaction” need not specify any output. The network could subtract the fee amount of the transaction directly from the specified UTXO.
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. 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).
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’t 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
next prev parent reply other threads:[~2022-02-25 12:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 9:02 vjudeu
2022-02-24 10:08 ` Ruben Somsen
2022-02-24 13:27 ` vjudeu
2022-02-24 14:01 ` Ruben Somsen
2022-02-24 21:40 ` Zac Greenwood
2022-02-25 0:04 ` ZmnSCPxj
2022-02-25 1:12 ` Zac Greenwood
2022-02-25 3:19 ` ZmnSCPxj
2022-02-25 7:15 ` Zac Greenwood
2022-02-25 12:48 ` ZmnSCPxj [this message]
2022-02-25 13:53 ` Zac Greenwood
2022-03-16 18:21 ` Peter Todd
2022-03-19 18:32 ` vjudeu
2022-03-21 11:00 ` Kostas Karasavvas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='JGiZgKJbF8rNYsQfjHNeqRqRUyfUuGaP0_W7Y9-uyyhDF0odqoF3dPitBwe7uXmhUh8TcwFOYGymzrgMhc2Kgq9NovHQSf_d0jRsDFH3zuk=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=zachgrw@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox