damian at willtech.com.au [ARCHIVE] on Nostr: 📅 Original date posted:2021-12-09 📝 Original message: Good Afternoon, 'Avoiding ...
📅 Original date posted:2021-12-09
📝 Original message:
Good Afternoon,
'Avoiding a soft-fork' is a political concession. Consensus is none of
that.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
and other projects
earn.com/willtech
linkedin.com/in/damianwilliamson
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this
email if misdelivered.
On 2021-12-08 14:51, Ruben Somsen via bitcoin-dev wrote:
> Hi Jeremy,
>
> Thanks for sharing your thoughts.
>
> To summarize your arguments: the intentionally malicious path to
> getting the 0 sat output confirmed without being spent is uneconomical
> compared to simply creating dust outputs. And even if it does happen,
> the tx spending from the 0 sat output may still be valid (as long as
> none of its inputs get spent elsewhere) and could eventually get
> confirmed.
>
> I think those are good points. I do still see a possibility where a
> user non-maliciously happens to behave in a way that causes all of the
> above to happen, but it does seem somewhat unlikely.
>
> It could happen if all of the following occurs:
> 1. Another output happens to get spent at a higher feerate (e.g.
> because an absolute timelock expires and the output gets used)
> 2. The tx spending the 0 sat output then happens to not make it into
> the block due to the lower fees
> 3. The user then happens to invalidate the tx that was spending from
> the 0 sat output (seems rational at that point)
>
> Assuming this is the only scenario (I am at least not currently aware
> of others), the question then becomes whether the above is acceptable
> in order to avoid a soft fork.
>
> Cheers,
> Ruben
>
> On Wed, Dec 8, 2021 at 6:41 PM Jeremy <jlrubin at mit.edu> wrote:
>
>> IMO this is not a big problem. The problem is not if a 0 value ever
>> enters the mempool, it's if it is never spent. And even if C2/P1
>> goes in, C1 still can be spent. In fact, it increases it's feerate
>> with P1's confirmation so it's somewhat likely it would go in. C2
>> further has to be pretty expensive compared to C1 in order to be
>> mined when C2 would not be, so the user trying to do this has to pay
>> for it.
>>
>> If we're worried it might never be spent again since no incentive,
>> it's rational for miners *and users who care about bloat* to save to
>> disk the transaction spending it to resurrect it. The way this can
>> be broken is if the txn has two inputs and that input gets spent
>> separately.
>>
>> That said, I think if we can say that taking advantage of keeping
>> the 0 value output will cost you more than if you just made it above
>> dust threshold, it shouldn't be economically rational to not just do
>> a dust threshold value output instead.
>>
>> So I'm not sure the extent to which we should bend backwards to make
>> 0 value outputs impossible v.s. making them inconvenient enough to
>> not be popular.
>>
>> -------------------------------------
>> Consensus changes below:
>> -------------------------------------
>>
>> Another possibility is to have a utxo with drop semantics; if UTXO X
>> with some flag on it is not spent in the block it is created, it
>> expires and can never be spent. This is essentially an inverse
>> timelock, but severely limited to one block and mempool evictions
>> can be handled as if a conflict were mined.
>>
>> These types of 0 value outputs could be present just for attaching
>> fee in the mempool but be treated like an op_return otherwise. We
>> could add two cases for this: one bare segwit version (just the
>> number, no data) and one that's equivalent to taproot. This covers
>> OP_TRUE anchors very efficiently and ones that require a signature
>> as well.
>>
>> This is relatively similar to how Transaction Sponsors works, but
>> without full tx graph de-linkage... obviously I think if we'll
>> entertain a consensus change, sponsors makes more sense, but
>> expiring utxos doesn't change as many properties of the tx-graph
>> validation so might be simpler.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
📝 Original message:
Good Afternoon,
'Avoiding a soft-fork' is a political concession. Consensus is none of
that.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
and other projects
earn.com/willtech
linkedin.com/in/damianwilliamson
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this
email if misdelivered.
On 2021-12-08 14:51, Ruben Somsen via bitcoin-dev wrote:
> Hi Jeremy,
>
> Thanks for sharing your thoughts.
>
> To summarize your arguments: the intentionally malicious path to
> getting the 0 sat output confirmed without being spent is uneconomical
> compared to simply creating dust outputs. And even if it does happen,
> the tx spending from the 0 sat output may still be valid (as long as
> none of its inputs get spent elsewhere) and could eventually get
> confirmed.
>
> I think those are good points. I do still see a possibility where a
> user non-maliciously happens to behave in a way that causes all of the
> above to happen, but it does seem somewhat unlikely.
>
> It could happen if all of the following occurs:
> 1. Another output happens to get spent at a higher feerate (e.g.
> because an absolute timelock expires and the output gets used)
> 2. The tx spending the 0 sat output then happens to not make it into
> the block due to the lower fees
> 3. The user then happens to invalidate the tx that was spending from
> the 0 sat output (seems rational at that point)
>
> Assuming this is the only scenario (I am at least not currently aware
> of others), the question then becomes whether the above is acceptable
> in order to avoid a soft fork.
>
> Cheers,
> Ruben
>
> On Wed, Dec 8, 2021 at 6:41 PM Jeremy <jlrubin at mit.edu> wrote:
>
>> IMO this is not a big problem. The problem is not if a 0 value ever
>> enters the mempool, it's if it is never spent. And even if C2/P1
>> goes in, C1 still can be spent. In fact, it increases it's feerate
>> with P1's confirmation so it's somewhat likely it would go in. C2
>> further has to be pretty expensive compared to C1 in order to be
>> mined when C2 would not be, so the user trying to do this has to pay
>> for it.
>>
>> If we're worried it might never be spent again since no incentive,
>> it's rational for miners *and users who care about bloat* to save to
>> disk the transaction spending it to resurrect it. The way this can
>> be broken is if the txn has two inputs and that input gets spent
>> separately.
>>
>> That said, I think if we can say that taking advantage of keeping
>> the 0 value output will cost you more than if you just made it above
>> dust threshold, it shouldn't be economically rational to not just do
>> a dust threshold value output instead.
>>
>> So I'm not sure the extent to which we should bend backwards to make
>> 0 value outputs impossible v.s. making them inconvenient enough to
>> not be popular.
>>
>> -------------------------------------
>> Consensus changes below:
>> -------------------------------------
>>
>> Another possibility is to have a utxo with drop semantics; if UTXO X
>> with some flag on it is not spent in the block it is created, it
>> expires and can never be spent. This is essentially an inverse
>> timelock, but severely limited to one block and mempool evictions
>> can be handled as if a conflict were mined.
>>
>> These types of 0 value outputs could be present just for attaching
>> fee in the mempool but be treated like an op_return otherwise. We
>> could add two cases for this: one bare segwit version (just the
>> number, no data) and one that's equivalent to taproot. This covers
>> OP_TRUE anchors very efficiently and ones that require a signature
>> as well.
>>
>> This is relatively similar to how Transaction Sponsors works, but
>> without full tx graph de-linkage... obviously I think if we'll
>> entertain a consensus change, sponsors makes more sense, but
>> expiring utxos doesn't change as many properties of the tx-graph
>> validation so might be simpler.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev