Bitcoin Optech @bitcoinoptech@x0f.org
bitcoinops.org
Joined Jan 2021
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.
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.
https://bitcoinops.org/en/newsletters/2021/10/13/#bitcoin-core-pr-review-club
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.
https://bitcoinops.org/en/newsletters/2021/10/13/#multiple-proposed-ln-improvements
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...
https://bitcoinops.org/en/newsletters/2021/10/13/#ln-spend-to-fees-cve
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?
After taproot activates, users will begin receiving payments to P2TR outputs. Later, they’ll spend those outputs. In some cases, they’ll make payments to non-P2TR outputs but will still return their change to themselves using a P2TR change output.
It’s easy for an expert or an algorithm observing such a transaction to reasonably infer that the P2TR output is the user’s own change output, making the other output the payment output.
https://bitcoinops.org/en/newsletters/2021/10/06/#preparing-for-taproot-16-output-linking
A post by pseudonymous developer John Law was submitted to the Bitcoin-Dev and Lightning-Dev mailing lists. Law proposed a soft fork to add Inherited Identifiers (IIDs) which would allow referencing the txid of a transaction’s ancestor and the position of the outputs leading to the current input. For example, `0123...cdef:0:1` indicates the current transaction input is spending the second child of the first output of txid `0123...cdef`.
https://bitcoinops.org/en/newsletters/2021/10/06/#proposal-for-transaction-heritage-identifiers
Bitcoin Optech newsletter #169 is here:
- summarizes a proposal to add transaction heritage identifiers to Bitcoin
- continues the 'how to prepare for taproot' series: output linking
- LND 0.13.3-beta release
Bitcoin Optech newsletter #168 is here:
- summarizes a proposal to implement breaking changes in the DLC specification
- examines options for allowing recovery of closed LN channels using just a BIP32 seed
- describes an idea to generate stateless LN invoices
- includes popular questions and answers from the Bitcoin Stack Exchange
- continues the 'how to prepare for taproot' series: signmessage protocol still needed
Bitcoin Optech newsletter #167 is here:
- describes a proposed modification to the BIP process
- summarizes a plan to add support for package relay to Bitcoin Core
- links to a discussion about adding LN node information to DNS
- notes changes to services and client software
- continues the 'how to prepare for taproot' series: testing on signet
Bitcoin Optech newsletter #166 is here:
- describes a new proposal for a covenant opcode
- summarizes a request for feedback on implementing regular reorgs on signet
- continues the 'how to prepare for taproot' series: Backup and security schemes
Bitcoin Optech newsletter #165 is here:
- describes a proposal for Bitcoin-related MIME types
- summarizes a paper about a design for a new decentralized mining pool
- recaps the 'Use legacy relaying to download blocks in blocks-only mode' Bitcoin Core PR Review Club meeting
- continues the 'how to prepare for taproot' series: Vaults with taproot
Bitcoin Optech newsletter #164 is here:
- describes a new web-based tool for decoding and modifying PSBTs
- links to a blog post and proof-of-concept implementation of an eltoo-based LN payment channel
- continues the 'how to prepare for taproot' series: LN with taproot
Bitcoin Optech newsletter #163 is here:
- summarizes a discussion about setting LN channel base fees to zero
- includes our regular sections with the best questions and answers of the past month from the Bitcoin Stack Exchange
- continues the 'how to prepare for taproot' series: PTLCs
- announces Rust-Lightning 0.0.100, Bitcoin Core 22.0rc2, Bitcoin Core 0.21.2rc1
Bitcoin Optech newsletter #162 is here:
- summarizes a discussion about the dust limit
- describes changes to services and client software
- continues the 'how to prepare for taproot' series: signature adaptors
- notes the Bitcoin Core 22.0rc2, Bitcoin Core 0.21.2rc1 release candidates
Bitcoin Optech newsletter #161 is here:
- follows up on a previous description about fidelity bonds in JoinMarket
- summarizes the 'Prefer to use txindex if available for GetTransaction' Bitcoin Core PR Review Club meeting
- continues the 'how to prepare for taproot' series: multisignature nonces
- announces C-Lightning 0.10.1, Bitcoin Core 22.0rc2
Bitcoin Optech newsletter #160 is here:
- continues the 'how to prepare for taproot' series: multisignatures
- announces C-Lightning 0.10.1rc2
- notes changes to popular Bitcoin infrastructure projects
Bitcoin Optech newsletter #159 is here:
- includes our regular sections with the best questions and answers of the past month from the Bitcoin Stack Exchange
- continues the 'how to prepare for taproot' series: learn taproot by using it (Optech Workshop)
- announces Rust Bitcoin 0.27.0, C-Lightning 0.10.1rc1
Bitcoin Optech newsletter #158 is here:
- describes recent changes to services and client software
- continues the 'how to prepare for taproot' series: why wallets should wait before generating taproot addresses, lists
- announces LND 0.13.1-beta, Rust-Lightning 0.0.99, Eclair 0.6.1
Bitcoin Optech newsletter #157 is here:
- summarizes a discussion about a proposed new opcode
- links to an updated wiki page for tracking bech32m support
- highlights from the 'Use script_util helpers for creating P2{PKH,SH,WPKH,WSH} scripts' Bitcoin Core PR Review Club meeting
- continues the 'how to prepare for taproot' series: from P2WPKH to single-sig P2TR
bitcoinops.org
Joined Jan 2021
