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>
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
