Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit

From: damian@willtech•com.au
To: Ruben Somsen <rsomsen@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev]  Take 2: Removing the Dust Limit
Date: Wed, 08 Dec 2021 22:27:04 -0800	[thread overview]
Message-ID: <32e6a20882fa13da03aa6238f5dfff69@willtech.com.au> (raw)
In-Reply-To: <CAPv7TjYTK=xrOxMbpD1JKQ1vTpiWWoOeGt86erFGBOP5grFYNA@mail.gmail.com>

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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev