From damian at willtech.com.au Thu Dec 9 06:27:04 2021 From: damian at willtech.com.au (damian at willtech.com.au) Date: Wed, 08 Dec 2021 22:27:04 -0800 Subject: [Lightning-dev] [bitcoin-dev] Take 2: Removing the Dust Limit In-Reply-To: <CAPv7TjYTK=xrOxMbpD1JKQ1vTpiWWoOeGt86erFGBOP5grFYNA@mail.gmail.com> References: <CAD5xwhid2OH0GzXPvqWgsMag4J9zidsewEquT-JoOweVD5pxZg@mail.gmail.com> <CACdvm3Oynv4gWdaGXATxc3SoYDD8kuiPq-d9F2itsmayP0qeZQ@mail.gmail.com> <CAPv7TjZBU2v2Nfw2_8Qz33rUWKJ=uJ7u+_5tFxjM94mk=RnmOA@mail.gmail.com> <CAD5xwhiSEoBxw=NVUHnZ+s22nTZhMoWYoDrC=aQfPyvwgtLrTQ@mail.gmail.com> <CAPv7TjYTK=xrOxMbpD1JKQ1vTpiWWoOeGt86erFGBOP5grFYNA@mail.gmail.com> Message-ID: <32e6a20882fa13da03aa6238f5dfff69@willtech.com.au> 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