Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 872C4C0012; Wed, 8 Dec 2021 17:19:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 6249681858; Wed, 8 Dec 2021 17:19:05 +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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4kkR8mpEDbAl; Wed, 8 Dec 2021 17:19:04 +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 smtp1.osuosl.org (Postfix) with ESMTPS id 1D03C81010; Wed, 8 Dec 2021 17:19:03 +0000 (UTC) Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 1B8HJ1xG029225 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 8 Dec 2021 12:19:02 -0500 Received: by mail-lf1-f49.google.com with SMTP id bi37so6950179lfb.5; Wed, 08 Dec 2021 09:19:02 -0800 (PST) X-Gm-Message-State: AOAM532ZolmytJkiexsh2DVpYYD7nioJLeTvvz1XKl2vswigwuaavVHI dQgzgtvRvQONWdiOXCdV8uYFbuuDoTS+8rqKHvg= X-Google-Smtp-Source: ABdhPJy3rdkAmX5CCE025YPE2E2gsYesB+17HtLyxKYCsXKQlqs6BZzQFQ1EnrNaFBwiHiNINfhK0qb+hbyUMhOyowk= X-Received: by 2002:a05:6512:1287:: with SMTP id u7mr760662lfs.226.1638983940923; Wed, 08 Dec 2021 09:19:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Wed, 8 Dec 2021 09:18:49 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Bastien TEINTURIER Content-Type: multipart/alternative; boundary="00000000000097683e05d2a5af4f" Cc: Bitcoin Protocol Discussion , 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 17:19:05 -0000 --00000000000097683e05d2a5af4f Content-Type: text/plain; charset="UTF-8" Bastien, The issue is that with Decker Channels you either use SIGHASH_ALL / APO and don't allow adding outs (this protects against certain RBF pinning on the root with bloated wtxid data) and have anchor outputs or you do allow them and then are RBF pinnable (but can have change). Assuming you use anchor outs, then you really can't use dust-threshold outputs as it either breaks the ratcheting update validity (if the specific amount paid to output matters) OR it allows many non-latest updates to fully drain the UTXO of any value. You can get around the needing for N of them by having a congestion-control tree setup in theory; then you only need log(n) data for one bumper, and (say) 1.25x the data if all N want to bump. This can be a nice trade-off between letting everyone bump and not. Since these could be chains of IUTXO, they don't need to carry any weight directly. The carve out would just be to ensure that CPFP 0 values are known how to be spent. -- @JeremyRubin --00000000000097683e05d2a5af4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bastien,=

The issue is that with Decker Channels you either use SIGHASH_ALL / = APO and don't allow adding outs (this protects against certain RBF pinn= ing on the root with bloated wtxid data) and have anchor=C2=A0outputs or yo= u do allow them and then are RBF pinnable (but can have change).

Assu= ming you use anchor outs, then you really can't use dust-threshold outp= uts as it either breaks the ratcheting update validity (if the specific amo= unt paid to output matters) OR it allows many non-latest updates to fully d= rain the UTXO of any value.

You can get around the needing for N of t= hem by having a congestion-control tree setup in theory; then you only need= log(n) data for one bumper, and (say) 1.25x the data if all N want to bump= . This can be a nice trade-off between letting everyone bump and not. Since= these could be chains of IUTXO, they don't need to carry any weight di= rectly.

The carve out would just be to ensure that CPFP 0 values are = known how to be spent.


<= br>


--00000000000097683e05d2a5af4f--