Dear Sir,
Regarding your message
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019636.html
Specifically the part
*"Right now, lightning anchor outputs use a 330 sats amount. Each
commitment*
*transaction has two such outputs, and only one of them is spent"*
I was wondering *
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 u
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
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 laun
