From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id EC060C0012; Wed, 8 Dec 2021 01:28:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id DAE2D41C10; Wed, 8 Dec 2021 01:28:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PSRWwGWNIIOV; Wed, 8 Dec 2021 01:28:57 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp4.osuosl.org (Postfix) with ESMTPS id BB54041C17; Wed, 8 Dec 2021 01:28:56 +0000 (UTC) Received: from mail-lf1-f48.google.com (mail-lf1-f48.google.com [209.85.167.48]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1B81SrgH017779 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 7 Dec 2021 20:28:55 -0500 Received: by mail-lf1-f48.google.com with SMTP id n12so2417040lfe.1; Tue, 07 Dec 2021 17:28:54 -0800 (PST) X-Gm-Message-State: AOAM531nJS8MYldN+0w70P3VcsDoez8FGJzqIP0t2VmSH1HVQhjltR5C ZY5CpQW9OdQVg8MSRqj/jrlZhKNJDfqJOLLT4+s= X-Google-Smtp-Source: ABdhPJzZBVYTaEDW3M8MtrB0dJJt6mGH57VfsOxVsDTUhRHVCnYPCc4YbxZem/Lbg0S0SGXeFy/Go1RUqMOGDqknYn4= X-Received: by 2002:a05:6512:c17:: with SMTP id z23mr44041722lfu.175.1638926933486; Tue, 07 Dec 2021 17:28:53 -0800 (PST) MIME-Version: 1.0 From: Jeremy Date: Tue, 7 Dec 2021 17:28:42 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list Content-Type: multipart/alternative; boundary="000000000000aef3d505d2986982" Cc: lightning-dev Subject: [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 01:28:58 -0000 --000000000000aef3d505d2986982 Content-Type: text/plain; charset="UTF-8" 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/019307.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 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) with the 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 not getting your eltoo/Decker channels pinned by junk witness data using Anchor Inputs, very good for not getting 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 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 concept 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 outputs. Cheers, Jeremy p.s. why another post today? Thank Greg https://twitter.com/JeremyRubin/status/1468390561417547780 -- @JeremyRubin --000000000000aef3d505d2986982 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bitcoin Devs (+cc lightni= ng-dev),

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

I think that there can be a simple carve out now that package rela= y is being launched 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 Output (t= hat 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 pa= rent must have a higher feerate=C2=A0after CPFP'ing the parent than the= parent alone we can both:

=
1) Allow 0 value outputs for things like A= nchor Outputs (very good for not getting your eltoo/Decker channels pinned = by junk witness data using Anchor Inputs, very good for not getting your ch= annels drained by at-dust 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 po= licy also has the benefits of not introducing any new validation rules. Alt= hough in general the IUTXO=C2=A0concept 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 spacechai= ns.

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

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

Cheers,

Jeremy

p.s. why another p= ost today? Thank Greg=C2=A0https://twitter.com/JeremyRubin/status/1468390561417= 547780


--000000000000aef3d505d2986982--