This week’s newsletter announces the release of LND 0.9.0-beta, asks for
help testing a release candidate for a Bitcoin Core maintenance release,
describes a proposal to break the linkability between UTXOs and
unannounced LN channels, and summarizes a modification to the proposed
SIGHASH_ANYPREVOUTANYSCRIPT signature hash that may simplify
management of payments in eltoo-based payment channels. Also included
are our regular sections for popular Bitcoin StackExchange Q&A and
notable changes to popular Bitcoin infrastructure and documentation
● Upgrade to LND 0.9.0-beta: this new major version release brings improvements to the access control list mechanism (“macaroons”), support for receiving multipath payments, the ability to send additional data in an encrypted onion message (see Newsletter #81), native rebalancing support (see Newsletter #74), support for requesting channel close outputs pay a specified address (e.g. your hardware wallet; see Newsletter #76), and many other features and bug fixes.
● Layered commitments with eltoo: Anthony Towns described a potential modification to his previous anyprevout proposal (a variation of SIGHASH_NOINPUT) that could simplify eltoo-based LN channels. As currently proposed, eltoo-based LN implementations would need to ensure they don’t accept a payment whose refund timeout occurs before the payment’s unilateral-close delay, otherwise a paying node will be able to reclaim its payment before the receiving node has a chance to use its adaptor signature (“point lock”) to legitimately claim the payment. This differs from current-style LN payments where the timeout and the delay may be chosen independently.
To allow eltoo to achieve a similar independence of timeout and delay parameters, Towns proposes removing the BIP341 commitment to the value of the inputs (
sha_amounts) from signatures created using the
SIGHASH_ANYPREVOUTANYSCRIPTsignature hash (sighash) flag. This also requires changes to the script used in eltoo, including making use of tapscript’s variation of the
Selected Q&A from Bitcoin StackExchange
Bitcoin StackExchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.
● How is OP_CHECKTEMPLATEVERIFY a scaling solution? Confused_Coder explains ways in which the proposed new opcode,
OP_CHECKTEMPLATEVERIFY, could help delay the use of block space until fees are cheaper by encapsulating multiple payments into a single output which can later be expanded to multiple outputs.
● Why was the BIP32 fingerprint used for BIP174 psbt? Andrew Chow describes why the BIP32 fingerprint was chosen for use throughout the BIP174 PSBT specification instead of the full hash, namely the impracticality of getting the full pubkey hash160 from hardware wallets.
● How is the size of a bitcoin transaction calculated? User Septem151 provides a detailed outline, broken out by each field, of how the weight units (vbytes) are calculated for both segwit and non-segwit transactions.
Notable code and documentation changes
● Bitcoin Core #17492 causes Bitcoin Core GUI to place a Partially-Signed Bitcoin Transaction (PSBT) in the clipboard if the user attempts to fee bump a transaction in a watch-only wallet. The user can then paste the PSBT into another program (such as HWI) for signing.
● C-Lightning #3376 adds retry logic to handle a temporary situation in which the spender and receiver disagree on the block height. There is discussion in the PR over whether the specification should be modified to simplify implementations, but it is pointed out that the specification change that led to this situation closes a privacy leak.
● LND #3809 adds a
forceparameter to the
BumpFeeRPC so that it can include uneconomical UTXOs in the transactions it creates, extending the change described in Newsletter #79. Uneconomical UTXOs are UTXOs that cost more to spend than they contain in value—it’s important that LND be able to spend these if the proposed anchor outputs fee bumping method is adopted into the LN protocol.
● BIPs #875 assigns BIP119 to the
OP_CHECKTEMPLATEVERIFYproposal. If the proposal is adopted, users will be able to create UTXOs that can only be spent by a specific transaction or set of transactions, providing a type of covenant. This is useful in protocols that temporarily keep payments offchain but which need to assure the ultimate receiver that there’s no practical way to revoke or change the output paying them.
● BIP340 is assigned to “Schnorr Signatures for secp256k1,” which describes a signature scheme compatible with the secp256k1 elliptic curve used by Bitcoin. The signatures are compatible with batch verification and with key and signature aggregation schemes such as MuSig. Schnorr signatures are made available for use in the following two BIPs (341 and 342). For more information, see the BIP or schnorr signatures.
● BIP341 is assigned to “Taproot: SegWit version 1 spending rules,” which describes part of a soft fork proposal for allowing users to pay schnorr-style public keys that can be spent either using a schnorr-style signature or proof that the key committed to a particular script via a merkle tree (along with proof that the script’s conditions were fulfilled). For details, see the BIP or taproot.
● BIP342 is assigned to “Validation of Taproot Scripts”, which describes the rules for evaluating a script used in combination with taproot (a tapscript). Almost all operations in tapscript are the same as legacy Bitcoin Script, but a few are different. For existing users upgrading to tapscript, the most significant change is that all signature-checking opcodes (e.g.
OP_CHECKSIG) use schnorr public keys and signatures; also noteworthy is that
OP_CHECKMULTISIGhas been removed; script authors can instead use a new
OP_CHECKSIGADDopcode or otherwise redesign their scripts. A few other new rules affect users or rarely-used features. Additionally, tapscript includes several new features designed to make future soft fork upgrades of its scripting language easier. For details, see the BIP or tapscript.
Many merges to the BIPs repository include contributions from several different people, but this merge had more contributors than any we’ve seen before: it included content and edits from 28 different people in 163 commits and its credits thank several other named contributors, the authors of previous work it builds upon, and the many “participants of the structured reviews.”
● BOLTs #697 modifies the sphinx packet construction described in BOLT4 to fix a privacy leak that may allow a destination node to discover the length of the path back to the source node. See Newsletter #72 for details about the leak. All three implementations tracked by Optech have also updated their code to fix the leak: C-Lightning, Eclair, and the LND-Onion library.
● BOLTs #705 allocates BOLT1 message types 32768–65535 for experimental and application-specific messages. It also suggests guidelines for implementers, including requesting that anyone allocating themselves a message type from that range post the numbers they’re using to BOLTs issue #716 to prevent conflicts.