Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9C1F0C0012 for ; Wed, 8 Dec 2021 08:34:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 88ECC4016F for ; Wed, 8 Dec 2021 08:34:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=acinq-fr.20210112.gappssmtp.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF_Z7BZqW8Ak for ; Wed, 8 Dec 2021 08:34:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) by smtp2.osuosl.org (Postfix) with ESMTPS id 612C740147 for ; Wed, 8 Dec 2021 08:34:44 +0000 (UTC) Received: by mail-yb1-xb2f.google.com with SMTP id v138so4146735ybb.8 for ; Wed, 08 Dec 2021 00:34:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=acinq-fr.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UNvSPWvU2+nwAJfcr9r9G/dq9IhzcVPVmqAsZDRKRjQ=; b=B02+p4vhdmIEpzv+io7dqEFy5U9EisoMbkwv86ZUydKMUjBitH8m8LEekrtBPKTkQo zJcX+iPgH6929rBEddJYPioOyLUL9ifxTW3Uja7Scmty6DzWTMMUDBEdC9Lbxv2/S2f4 Rm+zGGXfBqyqriMldNHY+Ubkfip56usYI8A4hwKWlsR0rLpDnqKfBHdAc+g937rXNVVa 34b/MG5Dpmim5FKJJrHJOf3joV5T/bP5MXSv8qaT5+2Fa002iX/YhByGfFK/QvITEUHQ K9TxxdHgPsYjVEhNtXHCZamM78CvC96ugfTkkEAUZUiR0Xy1pCR5gPEjVWjqbcJ4Eb3m qdMA== 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=UNvSPWvU2+nwAJfcr9r9G/dq9IhzcVPVmqAsZDRKRjQ=; b=SAan2LJ29utKfXYVOWTqnQ2X1SQeQ+3Jbpc9YdJ54K4vesSolT+WCsqAY71FKzNrsc 8Fvzx+w0U9hbkkmdVHnB9Il06ytx7RlQ5UrNavWyTBDhXc0ULsb3mPuVV/dNJvWp5jsL ORCU4L3wo2cWu2gaabTdGmgjQ6eO1ljdqG6bzn1zWHrGoDdGtcjj+rvHG2oR1Hm/fNUw EQLdKsr2d592w7EIj/Rm40zgcYX/SvC+0jPdFKUGPfQmqefQyj3zXiSbh40e9BSd+RYo 3GVvPaEY24bV3XBJ6fHiEhJDJzGmvN1vYzg2OWwB8DC8gQp6NaqxxCBPE0iixqoTDDGX Ma2g== X-Gm-Message-State: AOAM530E/MJ4qFyt7rzgKJkNym7Ddu77Wh9xQYEA4tzmDZKQ5w8vo0g0 3ED0NfyVDOD6M5gLLcn3ptWv+wd4qax2BVvefFPzMQ== X-Google-Smtp-Source: ABdhPJwAXp0xz2Th2S/2Jx1OEmdP6TS5KwOJHiIFxN622Rjum4ZIUY/PVkrQ87+l9oLoRy2MQncrL7fTdfuDtuLjzi4= X-Received: by 2002:a25:abe2:: with SMTP id v89mr63172800ybi.521.1638952483306; Wed, 08 Dec 2021 00:34:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Bastien TEINTURIER Date: Wed, 8 Dec 2021 09:34:32 +0100 Message-ID: To: Jeremy , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000924e6005d29e5c43" X-Mailman-Approved-At: Wed, 08 Dec 2021 09:35:25 +0000 Cc: lightning-dev Subject: Re: [bitcoin-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 08:34:47 -0000 --000000000000924e6005d29e5c43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeremy, Right now, lightning anchor outputs use a 330 sats amount. Each commitment transaction has two such outputs, and only one of them is spent to help the transaction get confirmed, so the other stays there and bloats the utxo set= . We allow anyone to spend them after a csv of 16 blocks, in the hope that someone will claim a batch of them when the fees are low and remove them from the utxo set. However, that trick wouldn't work with 0-value outputs, as no-one would ever claim them (doesn't make economical sense). We actually need to have two of them to avoid pinning: each participant is able to spend only one of these outputs while the parent tx is unconfirmed. I believe N-party protocols would likely need N such outputs (not sure). You mention a change to the carve-out rule, can you explain it further? I believe it would be a necessary step, otherwise 0-value outputs for CPFP actually seem worse than low-value ones... Thanks, Bastien Le mer. 8 d=C3=A9c. 2021 =C3=A0 02:29, Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > Bitcoin Devs (+cc lightning-dev), > > Earlier this year I proposed allowing 0 value outputs and that was shot > down for various reasons, see > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-August/01930= 7.html > > I think that there can be a simple carve out now that package relay is > being launched based on my research into covenants from 2017 > https://rubin.io/public/pdfs/multi-txn-contracts.pdf. > > Essentially, if we allow 0 value outputs BUT require as a matter of polic= y > (or consensus, but policy has major advantages) that the output be used a= s > an Intermediate Output (that is, in order for the transaction to be > creating it to be in the mempool it must be spent by another tx) with th= e > additional rule that the parent must have a higher feerate after CPFP'ing > the parent than the parent alone we can both: > > 1) Allow 0 value outputs for things like Anchor Outputs (very good for no= t > getting your eltoo/Decker channels pinned by junk witness data using Anch= or > Inputs, very good for not getting your channels drained by at-dust output= s) > 2) Not allow 0 value utxos to proliferate long > 3) It still being valid for a 0 value that somehow gets created to be > spent by the fee paying txn later > > Just doing this as a mempool policy also has the benefits of not > introducing any new validation rules. Although in general the IUTXO conce= pt > is very attractive, it complicates mempool :( > > I understand this may also be really helpful for CTV based contracts (lik= e > vault continuation hooks) as well as things like spacechains. > > Such a rule -- if it's not clear -- presupposes a fully working package > relay system. > > I believe that this addresses all the issues with allowing 0 value output= s > to be created for the narrow case of immediately spendable outputs. > > Cheers, > > Jeremy > > p.s. why another post today? Thank Greg > https://twitter.com/JeremyRubin/status/1468390561417547780 > > > -- > @JeremyRubin > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000924e6005d29e5c43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeremy,

Right now, lightning anchor = outputs use a 330 sats amount. Each commitment
transaction has tw= o such outputs, and only one of them is spent to help the
transac= tion get confirmed, so the other stays there and bloats the utxo set.
=
We allow anyone to spend them after a csv of 16 blocks, in the hope th= at
someone will claim a batch of them when the fees are low and r= emove them
from the utxo set. However, that trick wouldn't wo= rk with 0-value outputs, as
no-one would ever claim them (doesn&#= 39;t make economical sense).

We actually need to h= ave two of them to avoid pinning: each participant is
able to spe= nd only one of these outputs while the parent tx is unconfirmed.
= I believe N-party protocols would likely need N such outputs (not sure).

You mention a change to the carve-out rule, can you = explain it further?
I believe it would be a necessary step, other= wise 0-value outputs for
CPFP actually seem worse than low-value = ones...

Thanks,
Bastien

<= div class=3D"gmail_quote">
Le=C2=A0mer= . 8 d=C3=A9c. 2021 =C3=A0=C2=A002:29, Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfound= ation.org> a =C3=A9crit=C2=A0:
Bitcoin Devs (+cc lightning-dev),

Earlier this year I propose= d allowing 0 value outputs and that was shot down for various=C2=A0reasons,= see=C2=A0https://lists.linuxfoundation.= org/pipermail/bitcoin-dev/2021-August/019307.html

I think t= hat there can be a simple carve out now that package relay is being launche= d based on my research into covenants from 2017=C2=A0https://rubin.= io/public/pdfs/multi-txn-contracts.pdf.

Essentially, if we = allow 0 value outputs BUT require as a matter of policy (or consensus, but = policy has major advantages) that the output be used as an Intermediate Out= put (that is, in order for the transaction to be creating it to be in the m= empool it must be spent by another tx) =C2=A0with the additional rule that = the parent must have a higher feerate=C2=A0after CPFP'ing the parent th= an the parent alone we can both:
<= br>
1) Allow 0 value outputs for t= hings like Anchor Outputs (very good for not getting your eltoo/Decker chan= nels pinned by junk witness data using Anchor Inputs, very good for not get= ting your channels drained by at-dust outputs)
2) Not allow 0 value utxos to proliferate long
3) It still being valid for a 0 value that someho= w gets created to be spent by the fee paying txn later

Just doi= ng this as a mempool policy also has the benefits of not introducing any ne= w validation rules. Although in general the IUTXO=C2=A0concept is very attr= active, it complicates mempool :(

I understand this may also = be really helpful for CTV based contracts (like vault continuation hooks) a= s well as things like spacechains.

Such a rule -- if it's = not clear -- presupposes a fully working package relay system.

I believe that this addresses all the issues with allowing 0 value output= s to be created for the narrow case of immediately spendable outputs.
=

Cheers,

Jeremy

p.s. why another post today= ? Thank Greg=C2=A0https://twitter.com/JeremyRubin/status/1468= 390561417547780


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000924e6005d29e5c43--