Bitcoin Optech newsletter #170 is here:
- describes a vulnerability recently fixed in several LN implementations - summarizes a proposal providing multiple benefits for upgrading the LN protocol to take advantage of features in taproot
- recaps the "Extract RBF logic into policy/rbf" Bitcoin Core PR Review Club meeting
- continues the 'how to prepare for taproot' series: is cooperation always an option?
Antoine Riard posted CVEs for multiple programs to the Lightning-Dev list.
LN allows users to send small, uneconomical-onchain amounts. The paying or routing node overpays the fee for the commitment tx by the amount, effectively donating to miners if the commitment tx gets published.
LN softwares allow uneconomical limits to be 20%+ of a channel’s value, so 5 or fewer payments could spend all of a channel’s value to miners.
Mitigations are described in Riard’s email...
Anthony Towns posted to the Lightning-Dev mailing list a detailed proposal, with example code, describing how to reduce payment latency, improve backup resiliency, and allow receiving LN payments while signing keys are offline. The proposal provides some of the same benefits of eltoo but without requiring SIGHASH_ANYPREVOUT or any other consensus changes beyond taproot. As such, it could be deployed as soon as it was implemented and tested by LN developers.
Preparing for taproot #17: is cooperation always an option?
The argument against always providing a keypath is the cases when all the signers acting together don’t trust themselves. They instead trust others— full nodes—to enforce restrictions on the signers which the signers are unwilling to enforce themselves.
The counterpoint is that you can create a keypath spend between the regular signers and all those economic full node operators to obtain the same security.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!