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 Stack Exchange Q&A and notable changes to popular Bitcoin infrastructure and documentation projects.

Action items

• ● 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.

• ● Help test Bitcoin Core 0.19.1rc1: this upcoming maintenance release includes several bug fixes. Experienced users are encouraged to help test for any regressions or other unexpected behavior.

News

• ● Breaking the link between UTXOs and unannounced channels: Bastien Teinturier posted to the Lightning-Dev mailing list about changing what data is added to a BOLT11 invoice for payments sent to unannounced channels—channels that aren’t advertised to the LN network and which usually don’t route payments for other users. The proposed change would remove information from an invoice that could be used to identify the channel’s deposit UTXO, replacing it with a one-time per-invoice keypair and a secret that’s derived from the keypair and routed as part of the onion-encrypted payment. This would require special support from both the spender and the peer who’s able to route to the unannounced channel, but other nodes along the routing path would not need to change their implementation. Teinturier requested feedback on the proposal, including any suggestions for how to eliminate the need to include an encrypted secret in the payment.

• ● 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_ANYPREVOUTANYSCRIPT signature hash (sighash) flag. This also requires changes to the script used in eltoo, including making use of tapscript’s variation of the OP_CODESEPARATOR opcode.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange 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

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, libsecp256k1, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

• ● 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 force parameter to the BumpFee RPC 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_CHECKTEMPLATEVERIFY proposal. 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.

• ● BIPs #876 assigns three BIPs, one to each part of the schnorr-taproot-tapscript proposal:

  • ● 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_CHECKMULTISIG has been removed; script authors can instead use a new OP_CHECKSIGADD opcode 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.