This week’s newsletter describes a proposal to extend PSBTs with fields for spending outputs constructed using a pay-to-contract protocol and includes our regular sections with summaries of top posts from the Bitcoin Stack Exchange and notable changes to popular Bitcoin infrastructure projects.

News

  • ● PSBT extension for P2C fields: Maxim Orlovsky proposed a new BIP to add optional fields to PSBTs for spending from an output created using a Pay-to-Contract (P2C) protocol, as previously mentioned in Newsletter #37. P2C allows a spender and a receiver to agree on the text of a contract (or anything else) and then create a public key that commits to that text. The spender can then later demonstrate that the payment committed to that text and that it would’ve been computationally infeasible for that commitment to have been made without the cooperation of the receiver. In short, the spender can prove to a court or the public what they paid for.

    However, in order for the receiver to subsequently construct a signature spending their received funds, they need the hash of the contract in addition to the key they used (that key usually being part of an HD keychain). Orlovsky’s proposal allows that hash to be added to a PSBT so that a signing wallet or hardware device can produce a valid signature.

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.

  • ● Is it possible to convert a taproot address into a v0 native segwit address? After an exchange changed a user’s P2TR (native segwit v1) taproot withdrawal address into a P2WSH (native segwit v0) address due to lack of taproot support, the user asks if there is a way to claim the bitcoins in the resulting v0 output. Pieter Wuille notes that those bitcoins are not retrievable since the user would need to find a script that hashes to the public key in the P2TR address, a computationally infeasible operation.

  • ● Was Bitcoin 0.3.7 actually a hard fork? User BA20D731B5806B1D wonders what about Bitcoin’s 0.3.7 release caused it to be classified as a hard fork. Antoine Poinsot gives example scriptPubKey and scriptSig values to illustrate that a previously invalid signature could be valid after 0.3.7’s bugfix to separate scriptSig + scriptPubKey evaluations.

  • ● What is signature grinding? Murch explains that ECDSA signature grinding is the process of repeatedly signing until you get a signature whose r-value is in the lower half of the range, resulting in a signature that is 1 byte smaller (32 bytes vs 33 bytes) based on the serialization format Bitcoin uses for ECSDA. This smaller signature results in lower fees and the fact that the signature is a known 32 byte size helps with more accurate fee estimation.

  • ● How is network conflict avoided between chains? Murch explains how nodes use magic numbers, as specified in the P2P message structure, in order to identify if they are connected to a peer that is on the same network (mainnet, testnet, signet).

  • ● How many BIPs were adopted in the standard client in 2021? Pieter Wuille links to Bitcoin Core’s BIPs documentation that keeps track of BIPs that are implemented in Bitcoin Core.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • ● Eclair #2134 enables anchor outputs by default, allowing a commitment transaction to be fee bumped should its feerate be too low at broadcast time. Since anchor outputs-style fee bumping works via CPFP, users will need to keep UTXOs available in their bitcoind wallet.

  • ● Eclair #2113 adds automatic management of fee bumping. This includes classifying transactions by the importance of confirming them on time, re-evaluating transactions after each block to determine whether it’s appropriate to fee bump them, also re-evaluating current network feerates in case the transaction’s feerate needs to be increased, and adding additional inputs to transactions if necessary to increase the transaction’s feerate. The PR description also makes an appeal for improvements to Bitcoin Core’s wallet API that could reduce the amount of add-on wallet management required by external programs like Eclair.

  • ● Eclair #2133 begins relaying onion messages by default. The rate limits mentioned in Newsletter #181 are used to prevent problems from any abuse of this experimental part of the LN protocol.

  • ● BTCPay Server #3083 allows administrators to log into a BTCPay instance using LNURL authentication (which can also be implemented in non-LN software).

  • ● BIPs #1270 clarifies the PSBT specification in regard to acceptable values for signature fields. After a recent update to Rust Bitcoin introduced stricter parsing of signature fields, a discussion ensued whether a signature field in a PSBT may hold a placeholder, or only valid signatures were permissible. It was determined that PSBTs should only ever contain valid signatures.

  • ● BOLTs #917 extends the init message defined by BOLT1 with the ability for a node to tell a connecting peer what IPv4 or IPv6 address that peer is using. Since peers behind NAT can’t see their own IP address, this allows the peer to update the IP address it announces to the network when that address changes.