Zac Greenwood [ARCHIVE] on Nostr: đź“… Original date posted:2022-02-25 đź“ť Original message:Hi ZmnSCPxj, > Either you ...
đź“… Original date posted:2022-02-25
đź“ť Original message: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’ design philosophy.
I have been unclear about the fee part. In my proposal there’s 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 — 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-transaction-to-only-marginally-less-than-what-it
would-have-cost-to-store-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 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) — thank you for pointing that out and for your helpful feedback.
Zac
On Fri, 25 Feb 2022 at 13:48, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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 part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220225/f60e1849/attachment.html>;
đź“ť Original message: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’ design philosophy.
I have been unclear about the fee part. In my proposal there’s 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 — 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-transaction-to-only-marginally-less-than-what-it
would-have-cost-to-store-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 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) — thank you for pointing that out and for your helpful feedback.
Zac
On Fri, 25 Feb 2022 at 13:48, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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 part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220225/f60e1849/attachment.html>;