From: Jeremy <jlrubin@mit•edu>
To: Bastien TEINTURIER <bastien@acinq•fr>
Cc: Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
lightning-dev <lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Take 2: Removing the Dust Limit
Date: Wed, 8 Dec 2021 09:18:49 -0800 [thread overview]
Message-ID: <CAD5xwhggU646dygtaPdtmHbKS6NzdnbVYyXPAUBZYdt+1iRbag@mail.gmail.com> (raw)
In-Reply-To: <CACdvm3Oynv4gWdaGXATxc3SoYDD8kuiPq-d9F2itsmayP0qeZQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1024 bytes --]
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 <https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 2898 bytes --]
next prev parent reply other threads:[~2021-12-08 17:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-08 1:28 Jeremy
2021-12-08 8:34 ` Bastien TEINTURIER
2021-12-08 10:46 ` [bitcoin-dev] [Lightning-dev] " Ruben Somsen
2021-12-08 17:41 ` Jeremy
2021-12-08 22:51 ` Ruben Somsen
2021-12-09 6:27 ` damian
2021-12-08 17:18 ` Jeremy [this message]
2022-01-21 12:16 [bitcoin-dev] " shymaa arafat
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD5xwhggU646dygtaPdtmHbKS6NzdnbVYyXPAUBZYdt+1iRbag@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--cc=bastien@acinq$(echo .)fr \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox