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?
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.
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!