diff options
| author | Ruben Somsen <rsomsen@gmail.com> | 2021-12-08 23:51:50 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2021-12-08 22:52:03 +0000 |
| commit | b11a4e1e37b629cdfccb4ad97cf7b2aac14c1c18 (patch) | |
| tree | e763b355be5b7194601e596faead295ef7888292 | |
| parent | bfa2f8816c4b285a897b40a93f116c4ae6698a51 (diff) | |
| download | pi-bitcoindev-b11a4e1e37b629cdfccb4ad97cf7b2aac14c1c18.tar.gz pi-bitcoindev-b11a4e1e37b629cdfccb4ad97cf7b2aac14c1c18.zip | |
Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit
| -rw-r--r-- | fb/ec9e111f71d7a9cedb113aa0ba3f9e7ff6a661 | 281 |
1 files changed, 281 insertions, 0 deletions
diff --git a/fb/ec9e111f71d7a9cedb113aa0ba3f9e7ff6a661 b/fb/ec9e111f71d7a9cedb113aa0ba3f9e7ff6a661 new file mode 100644 index 000000000..2850de034 --- /dev/null +++ b/fb/ec9e111f71d7a9cedb113aa0ba3f9e7ff6a661 @@ -0,0 +1,281 @@ +Return-Path: <rsomsen@gmail.com> +Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 77FB6C0012; + Wed, 8 Dec 2021 22:52:03 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp1.osuosl.org (Postfix) with ESMTP id 5FA45824A4; + Wed, 8 Dec 2021 22:52:03 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.098 +X-Spam-Level: +X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, + SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp1.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=gmail.com +Received: from smtp1.osuosl.org ([127.0.0.1]) + by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 5G4bxysubxxQ; Wed, 8 Dec 2021 22:52:02 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.8.0 +X-Greylist: whitelisted by SQLgrey-1.8.0 +Received: from mail-yb1-xb29.google.com (mail-yb1-xb29.google.com + [IPv6:2607:f8b0:4864:20::b29]) + by smtp1.osuosl.org (Postfix) with ESMTPS id 1EC168246F; + Wed, 8 Dec 2021 22:52:02 +0000 (UTC) +Received: by mail-yb1-xb29.google.com with SMTP id g17so9423372ybe.13; + Wed, 08 Dec 2021 14:52:02 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=l5W1OSZM+yo3/Mg7/r0bMkeeC/3IUyx7jtVXZP4vPrg=; + b=JJgFQGHMApyVcum7Wjzg3wcjbFWHIXOxAN1iTB9A7jaw67p4IVnLHFrH26itawIDVd + IfijNkxl6JFxURcQkNgRa3TV3T8SWdIZ+QCUQoy0+ynGh8wBTWmS/d06sE2U7sF+XDJ5 + iKxU9/Z9XEzPvNxzI8JTdgzddu8hFdU5hJaNM8J7kJTCptRz30XMSz4d7SXtPyDpqU2l + PVC1Nl/pA2CLMZ6aK854cg7EoP+ZlDEdK0x6zIbcpaIQJfT7cWu0dXaFFfxxTudXyqAq + sJpFoV4esBIbCLmCXtfx6dAIZ35x+QgUTujZ5IwfBd1eVW17SRq7KcgHwqcy6ROpwQXz + qJEg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20210112; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=l5W1OSZM+yo3/Mg7/r0bMkeeC/3IUyx7jtVXZP4vPrg=; + b=HE4t6zb2trXEHuznxUJ+JA65PCiiwHRkVkLlf2S8vbSQN1g/RylteUnkPG0YjEUEfh + GiGOW4YMo9Q/vzwCuY5HDyAbO2IGLLPyjSnrezMQTlwz9DdLwgqsjEtjSs/OQK4S1Lal + Sy2Qp3wDwbf2Krqjk0UyTZaCSJv20z1Mg5Llqf8NxL/I50TYQqyu6GFTzrDqHPwTOqTk + JKVqu34oweJtoERbw0kQW0fX7pac8lpMCf/WVFco20pKiKy7b4l1I4CHcIMufgFQQwTu + hPJUO9ZzfrRpESxZ/MHxXnoBVeHetCsih3W2gQv0bKXDAY7Ol3fnZEPOASexw838J0LQ + xYfw== +X-Gm-Message-State: AOAM5304Ibh21VvKyiI5dE6WJPmKgvvSvNFh3Yr8wG35z2dJ+sOzfBcj + ZBJSlsqDW6wzRsojl3drr1fKOtLK4JqKuPaRNuE= +X-Google-Smtp-Source: ABdhPJwDWWZSGQbgSwdYFS36J9K0cZgHvuHG++NMtZrZ1q6i+oNE3kFNVd6wmrqsG7+pjYo6LlvV/2PCGXD4iGSZ/YA= +X-Received: by 2002:a25:94f:: with SMTP id u15mr1894884ybm.407.1639003921044; + Wed, 08 Dec 2021 14:52:01 -0800 (PST) +MIME-Version: 1.0 +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> +In-Reply-To: <CAD5xwhiSEoBxw=NVUHnZ+s22nTZhMoWYoDrC=aQfPyvwgtLrTQ@mail.gmail.com> +From: Ruben Somsen <rsomsen@gmail.com> +Date: Wed, 8 Dec 2021 23:51:50 +0100 +Message-ID: <CAPv7TjYTK=xrOxMbpD1JKQ1vTpiWWoOeGt86erFGBOP5grFYNA@mail.gmail.com> +To: Jeremy <jlrubin@mit.edu> +Content-Type: multipart/alternative; boundary="0000000000007fd9e305d2aa5684" +X-Mailman-Approved-At: Wed, 08 Dec 2021 22:52:54 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>, + lightning-dev <lightning-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] [Lightning-dev] Take 2: Removing the Dust Limit +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 08 Dec 2021 22:52:03 -0000 + +--0000000000007fd9e305d2aa5684 +Content-Type: text/plain; charset="UTF-8" + +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. +> +> +> +> +> + +--0000000000007fd9e305d2aa5684 +Content-Type: text/html; charset="UTF-8" +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi Jeremy,<div><br></div><div>Thanks for sharing your thou= +ghts.<div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-= +serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-family:ar= +ial,helvetica,sans-serif">To summarize your arguments: t</span><span style= +=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">he intentional= +ly malicious path to getting the 0 sat output confirmed without being spent= + is uneconomical compared to simply creating dust outputs.=C2=A0</span><spa= +n style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">And eve= +n if it does happen, the tx spending from the 0 sat output may still be val= +id (as long as none of its=C2=A0inputs get spent elsewhere) and could event= +ually get confirmed.</span></div><div><span style=3D"color:rgb(0,0,0);font-= +family:arial,helvetica,sans-serif"><br></span></div><div><font color=3D"#00= +0000" face=3D"arial, helvetica, sans-serif">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.</font></div><div><font color=3D"#000000" face=3D"arial, helvetic= +a, sans-serif"><br></font></div><div><font color=3D"#000000" face=3D"arial,= + helvetica, sans-serif">It could happen if all of the following occurs:</fo= +nt></div><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"= +>1. Another output happens to get spent at a higher feerate (e.g. because a= +n absolute timelock expires and the output gets used)</font></div><div><fon= +t color=3D"#000000" face=3D"arial, helvetica, sans-serif">2. The tx spendin= +g the 0 sat output then happens to not make it into the block due to the lo= +wer fees</font></div><div><font color=3D"#000000" face=3D"arial, helvetica,= + sans-serif">3. The user then happens to invalidate the tx that was spendin= +g from the 0 sat output (seems rational at that point)=C2=A0</font></div><d= +iv><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"></font></d= +iv><div><font color=3D"#000000" face=3D"arial, helvetica, sans-serif"><br><= +/font></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetic= +a,sans-serif">Assuming this is the only scenario (I am at least not current= +ly aware of others), the question then becomes whether the above is accepta= +ble in order to avoid a soft fork.</span></div><div><span style=3D"color:rg= +b(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><div><spa= +n style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">Cheers,= +</span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helveti= +ca,sans-serif">Ruben</span></div><div><span style=3D"color:rgb(0,0,0);font-= +family:arial,helvetica,sans-serif"><br></span></div></div></div><br><div cl= +ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 8, 20= +21 at 6:41 PM Jeremy <<a href=3D"mailto:jlrubin@mit.edu">jlrubin@mit.edu= +</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:= +0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">= +<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he= +lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">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 compa= +red to C1 in order to be mined when C2 would not be, so the user trying to = +do this has to pay for it.</div><div class=3D"gmail_default" style=3D"font-= +family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d= +iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s= +erif;font-size:small;color:rgb(0,0,0)">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 resurr= +ect it. The way this can be broken is if the txn has two inputs and that in= +put gets spent separately.</div><div class=3D"gmail_default" style=3D"font-= +family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></d= +iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s= +erif;font-size:small;color:rgb(0,0,0)">That said, I think if we can say tha= +t 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 ra= +tional to not just do a dust threshold value output instead.</div><div clas= +s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si= +ze:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"= +font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">So= + I'm not sure the extent to which we should bend backwards to make 0 va= +lue outputs impossible v.s. making them inconvenient enough to not be popul= +ar.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,= +sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_= +default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co= +lor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family= +:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di= +v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f= +ont-size:small;color:rgb(0,0,0)">-------------------------------------</div= +><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser= +if;font-size:small;color:rgb(0,0,0)">Consensus changes below:</div><div cla= +ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s= +ize:small;color:rgb(0,0,0)">-------------------------------------</div><div= + class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl= +e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0= +)">Another possibility is to have a utxo with drop semantics; if UTXO X wit= +h some flag on it is not spent in the block it is created, it expires and c= +an never be spent. This is essentially an inverse timelock, but severely li= +mited to one block and mempool evictions can be handled as if a conflict we= +re mined.</div><div class=3D"gmail_default" style=3D"font-family:arial,helv= +etica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"= +gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm= +all;color:rgb(0,0,0)">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 an= +chors very efficiently and ones that require a signature as well.</div><div= + class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo= +nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl= +e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0= +)">This is relatively similar to how Transaction Sponsors works, but withou= +t full tx graph de-linkage... obviously I think if we'll entertain a co= +nsensus change, sponsors makes more sense, but expiring utxos doesn't c= +hange as many properties of the tx-graph validation so might be simpler.</d= +iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s= +erif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_defaul= +t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg= +b(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial= +,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div clas= +s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si= +ze:small;color:rgb(0,0,0)"><br></div></div> +</blockquote></div> + +--0000000000007fd9e305d2aa5684-- + |