Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 54966C0012; Wed, 8 Dec 2021 10:46:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 35E9A41D90; Wed, 8 Dec 2021 10:46:44 +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: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qE8woaRBBKYR; Wed, 8 Dec 2021 10:46:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com [IPv6:2607:f8b0:4864:20::b34]) by smtp4.osuosl.org (Postfix) with ESMTPS id C176141D85; Wed, 8 Dec 2021 10:46:42 +0000 (UTC) Received: by mail-yb1-xb34.google.com with SMTP id e136so4957073ybc.4; Wed, 08 Dec 2021 02:46:42 -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=Hod5rOpUeVt943E7KgTPmIc3dGfYT/VglP7TuknDkh0=; b=fQlrlCuOiu/fP+0OP5h6vbD5pyS6M7qf2Tk7hTo90XdtxdRlz10PtTlY+SzHUji80k 7sP/k4hNedWXf2Mfi/M1rrGz7JVDkcjaaockzGh6k9iADhimPDmQjqcG8hT2QJ2Cz1M0 TTpCwV2SfcNWcB25ueN1wGkdU459i2ouRjTHEKplYEn81DECsYx6Sjoq1NFTvg5xBAIy SsZQPY+VpPIaitefbnBzHtSHJsGQ7exBo07wplCnoOqfvbG+mVpHnY8QqZrmnnehTIsk djVLSX2NedKibV4PPb15S3aNrr2bJjjQ3x0a1QJmpbZrAajyO4LSb/4h+q3aJZaluMO8 BTtg== 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=Hod5rOpUeVt943E7KgTPmIc3dGfYT/VglP7TuknDkh0=; b=lef+mv4pnbCKNK1BSqaYs3opEFLFeeu3t4iGb/Ad/hxm3XaB5tzPFjHSjvs+n25y5/ qN5hJinvLxdCXcd8xaLDPxcJfO7DayMQ6QHipZWyY6Uz5HtRRaHWZx6McsWUuegOylBh RbZk0yJIyy5M4t+jo+NAKFeSI9IVNoXvdKeQRwOZDFbunGKYMx4FDjhZC7mBeB3RBWVV K2odrjwY9EZ7kE+11aESWG8LG6Df+IHKtzNuFHphLHiJfOdK1bAxPybGAsztCMg2BYGs gIee5RrcHXm3MQObMBfHdBViimB7/MfSXXj8mENUWd0AFpiGH7isKdJ90qy3ZXrrKeRd kmPw== X-Gm-Message-State: AOAM533sDdWbmA30A65PJlr0gkF2KPoYpVzGhz1MJYzcxkNM66+B/jw4 YDC4YLqagaJpE2LmTuAArRrVrskwRu8XZfQPsqYsRgI2nTA= X-Google-Smtp-Source: ABdhPJyVxRba86qZsJ/j2pxbDP/96jWglvOgDByg0l9L2dLg+Mu7vfnNizvzob5d7SynFOoolSvR8y7EzQnVawgZS+E= X-Received: by 2002:a25:cc7:: with SMTP id 190mr19266338ybm.540.1638960401541; Wed, 08 Dec 2021 02:46:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ruben Somsen Date: Wed, 8 Dec 2021 11:46:22 +0100 Message-ID: To: Bitcoin Protocol Discussion , lightning-dev Content-Type: multipart/alternative; boundary="00000000000088ee7f05d2a03425" X-Mailman-Approved-At: Wed, 08 Dec 2021 10:47:15 +0000 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 10:46:44 -0000 --00000000000088ee7f05d2a03425 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jeremy, I brought up the exact same thing at coredev, but unfortunately I came up with a way in which the 0 sat output could still enter the UTXO set under those rules: - Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat - Child C1 spends the 0 sat output for a combined feerate of 1 sat per byte and they enter the mempool as a package - Child C2 spends the other output of P1 with a really high feerate and enters the mempool - Fees rise and child C1 falls out of the mempool, leaving the 0 sat output unspent For this to not be a problem, the 0 sat output needs to provably be the only spendable output. As you pointed out to me a few days ago, having a relative timelock on the other outputs would do the trick (and this happens to be true for spacechains), but that will only be provable if all script conditions are visible prior to spending time (ruling out p2sh and taproot, and conflicting with standardness rules for transactions). It's worth noting out that you can't really make a policy rule that says the 0 sat output can't be left unspent (i.e. C1 can't be evicted without also evicting P1), as this would not mirror economically rational behavior for miners (they would get more fees if they evicted C1, so we must assume they will, if the transaction ever reaches them). This last example really points out the tricky situation we're dealing with. In my opinion, we'd only want to relay 0 sat outputs if we can guarantee that it's never economically profitable to mine them without them getting spent in the same block. Finally, here's a timestamped link to a diagram that shows where 0 sat outputs would be helpful for spacechains (otherwise someone would have to pay the dust up front for countless outputs): https://youtu.be/N2ow4Q34Jeg?t=3D2556 Cheers, Ruben On Wed, Dec 8, 2021 at 9:35 AM Bastien TEINTURIER wrote: > Hi Jeremy, > > Right now, lightning anchor outputs use a 330 sats amount. Each commitmen= t > transaction has two such outputs, and only one of them is spent to help t= he > 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 i= s > able to spend only one of these outputs while the parent tx is unconfirme= d. > 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/0193= 07.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 >> policy (or consensus, but policy has major advantages) that the output b= e >> used as 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 t= he >> additional rule that the parent must have a higher feerate after CPFP'in= g >> the parent than the parent alone we can both: >> >> 1) Allow 0 value outputs for things like Anchor Outputs (very good for >> not getting your eltoo/Decker channels pinned by junk witness data using >> Anchor Inputs, very good for not getting your channels drained by at-dus= t >> outputs) >> 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 conc= ept >> is very attractive, it complicates mempool :( >> >> I understand this may also be really helpful for CTV based contracts >> (like 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 >> outputs to be created for the narrow case of immediately spendable outpu= ts. >> >> 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 >> > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > --00000000000088ee7f05d2a03425 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jeremy,

I brought up the exact = same thing at coredev, but unfortunately I came up with a way in which the = 0 sat output could still enter the UTXO set under those rules:

- Parent P1 (0 sat per byte) has 2 outputs, one is 0 sat- Child C1 spends the 0 sat output for a combined feerate of 1 sat per by= te and they enter the mempool as a package
- Child C2 spends the other o= utput of P1 with a really high feerate and enters the mempool
- Fees ris= e and child C1 falls out of the mempool, leaving the 0 sat output unspent

For this to not be a problem, the 0 sat output = needs to provably be the only spendable output. As you pointed out to me a = few days ago,=C2=A0having a relative timelock on the other outputs would do= the trick (and this happens to be true for spacechains), but that will onl= y be provable if all script conditions are visible prior to spending time (= ruling out p2sh and taproot, and conflicting with standardness rules for tr= ansactions).

It's worth noting out that you ca= n't really make a policy rule that says the 0 sat output can't be l= eft unspent (i.e. C1 can't be evicted without also evicting P1), as thi= s would not mirror economically rational behavior for miners (they would ge= t more fees if they evicted C1, so we must assume they will, if the transac= tion ever reaches them).

This last example really = points out the tricky situation we're dealing with. In my opinion, we&#= 39;d only want to relay 0 sat outputs if we can guarantee that it's nev= er economically profitable=C2=A0to mine them without them getting spent in = the same block.

Finally, here's a timestamped = link to a diagram that shows where 0 sat outputs would be helpful for space= chains (otherwise someone would have to pay the dust up front for countless= outputs):

Cheers,<= /div>
Ruben




On Wed, Dec 8, 2021 at 9:35 AM Bastien TEINTURIER <bastien@acinq.fr> wrote:
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 sta= ys there and bloats the utxo set.
We allow anyone to spend them a= fter a csv of 16 blocks, in the hope that
someone will claim a ba= tch of them when the fees are low and remove them
from the utxo s= et. 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: ea= ch participant is
able to spend only one of these outputs while t= he parent tx is unconfirmed.
I believe N-party protocols would li= kely need N such outputs (not sure).

You mention a= change to the carve-out rule, can you explain it further?
I beli= eve it would be a necessary step, otherwise 0-value outputs for
C= PFP actually seem worse than low-value ones...

Tha= nks,
Bastien

Le=C2=A0mer. 8 d=C3=A9c. 2021 =C3=A0=C2=A002:= 29, Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>= ; a =C3=A9crit=C2=A0:
Bitcoin Devs (+c= c lightning-dev),

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

I think that there can be = a simple carve out now that package relay is being launched based on my res= earch into covenants from 2017=C2=A0https://rubin.io/public/pdfs/mu= lti-txn-contracts.pdf.

Essentially, if we allow 0 value out= puts BUT require as a matter of policy (or consensus, but policy has major = advantages) that the output be used as 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) =C2=A0with the additional rule that the parent must h= ave a higher feerate=C2=A0after CPFP'ing the parent than the parent alo= ne we can both:

1) Allow 0 value outputs for things like Anchor= Outputs (very good for not getting your eltoo/Decker channels pinned by ju= nk witness data using Anchor Inputs, very good for not getting your channel= s drained by at-dust outputs)
2) N= ot 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 memp= ool policy also has the benefits of not introducing any new validation rule= s. Although in general the IUTXO=C2=A0concept is very attractive, it compli= cates mempool :(

I understand this may also be really helpful f= or CTV based contracts (like vault continuation hooks) as well as things li= ke spacechains.

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

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

Cheers,

Jeremy

p.s. why another post today? Thank Greg=C2=A0https://twitter.com/JeremyRubin/status/1468390561417547780<= /div>


<= /div>
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/ma= ilman/listinfo/lightning-dev
--00000000000088ee7f05d2a03425--