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...
Bitcoin Core PR Review Club's "Extract RBF logic into policy/rbf" is a PR by Gloria Zhao to extract Bitcoin Core’s Replace By Fee logic into separate utility functions.
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!