This week’s newsletter summarizes an analysis comparing proposals for ephemeral anchors to SIGHASH_GROUP and relays a request for researchers to investigate how to create proof that an LN async payment was accepted. Also included are our regular sections with summaries of popular questions and answers on the Bitcoin Stack Exchange and descriptions of notable changes to popular Bitcoin infrastructure software.

News

• ● Ephemeral anchors compared to SIGHASH_GROUP: Anthony Towns posted to the Bitcoin-Dev mailing list an analysis comparing the recent ephemeral anchors proposal to an older SIGHASH_GROUP proposal. SIGHASH_GROUP allows an input to specify which outputs it authorizes, with different inputs in a transaction being able to specify different outputs as long as they don’t overlap. This can be especially useful for adding fees to transactions in contract protocols where two or more inputs are used with presigned transactions. The presigned nature of these transactions implies that fees may need to be added later when an appropriate feerate is known, and the existing SIGHASH_ANYONECANPAY and SIGHASH_SINGLE sighash flags aren’t flexible enough for multi-input transactions because they only commit to a single input or output.

  Ephemeral anchors, similar to fee sponsorship, lets anyone CPFP fee bump a transaction. The transaction being fee-bumped is allowed to contain zero fees. Because anyone can fee bump a transaction using ephemeral anchors, this mechanism can also be used to pay fees for the multi-input presigned transactions which are a target for SIGHASH_GROUP.

  SIGHASH_GROUP would still have two advantages: first, it could allow batching multiple unrelated presigned transactions, which could reduce transaction size overhead, reducing user costs and increasing network capacity. Second, it doesn’t require a child transaction, which would further reduce costs and increase capacity.

  Towns concludes by noting that ephemeral anchors, with its dependency on v3 transaction relay, captures most of the benefits of SIGHASH_GROUP and provides the significant advantage of being much easier to get into production than the SIGHASH_GROUP soft fork consensus change.

• ● Request for proof that an async payment was accepted: Valentine Wallace posted to the Lightning-Dev mailing list a request for researchers to investigate how someone making an async payment could receive proof that they paid. For traditional LN payments, the receiver generates a secret which gets digested by a hash function; that digest is given to the spender in a signed invoice; the spender uses an HTLC to pay anyone who discloses the original secret. That disclosed secret proves the spender paid the digest contained in the signed invoice.

  By contrast, async payments are accepted when the receiver is offline, so they can’t reveal a secret, preventing the creation of a proof of payment in the current LN model. Wallace asks researchers to consider investigating how proof of payment for async payments could be obtained, either in LN’s current HTLC-based system or a future upgrade to PTLCs.

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.

• ● Bitcoin Core signing keys were removed from repo. What is the new process? Andrew Chow explains that while the signing keys were removed from the Bitcoin Core repository, there is now a list of keys on the guix.sigs repository which houses guix build attestations.

• ● Why doesn’t signet use a unique bech32 prefix? Casey Rodarmor wonders why both testnet and signet use the tb1 address prefix. Kalle, one of the BIP325 authors, explains that while signet initially used a different address prefix, it was thought using the same prefix would simplify usage of that alternate test network.

• ● Arbitrary data storage in witness? RedGrittyBrick points to one of several recent P2TR transactions containing a large amount of witness data. Other users point out that the Ordinals project provides a service for including arbitrary data, like the image in the transaction above, into a Bitcoin transaction using the witness.

• ● Why is the locktime set at transaction level while the sequence is set at input level? RedGrittyBrick provides early historical context for nSequence and nLockTime while Pieter Wuille goes on to explain the evolution in the meanings of these timelock fields over time.

• ● BLS signatures vs Schnorr Pieter Wuille contrasts the cryptographic assumptions between BLS and schnorr signatures, comments on the verification times, and notes complications around BLS multisignatures and the lack of support for adaptor signatures.

• ● Why exactly would adding further divisibility to bitcoin require a hard fork? Pieter Wuille explains 4 soft fork methods that could enable sub-satoshi divisibility in transactions:

  1. A forced soft fork method with consensus rule changes requiring all new transactions to comply with the new rules
  2. A one-way extension block that separates transactions following the new rules, similar to 1. above, but also allowing for legacy transactions
  3. A two-way extension block, similar to 2. above, but allowing coins following the new side to move back to legacy side
  4. A method that uses current consensus rules but truncates sub-satoshi amounts for old nodes by storing these sub-satoshi amounts elsewhere in the transaction

Notable code and documentation changes

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

• ● Bitcoin Core #26325 improves the results of the scanblocks rpc by removing false positives in a second pass. scanblocks may be used to find blocks containing transactions relevant to a provided set of descriptors. Since scanning against the filters may falsely indicate some blocks that do not actually contain relevant transactions, this PR validates each hit in another pass to see whether blocks actually correspond to the passed descriptors before providing the results to the caller. For performance reasons, the second pass needs to be enabled by calling the RPC with the filter_false_positives option.

• ● Libsecp256k1 #1192 updates the library’s exhaustive tests. By changing the B parameter of the secp256k1 curve from 7 to another number, it is possible to find different curve groups that are compatible with libsecp256k1 but which are much smaller than secp256k1’s order of approximately 2²⁵⁶. On these tiny groups that are useless for secure cryptography, it’s possible to test the libsecp256k1 logic exhaustively on every possible signature. This PR added a group of size 7 in addition to the existing sizes 13 and 199, although cryptographers first had to figure out the peculiar algebraic properties that caused the naive search algorithm for such groups to not always succeed before. Size 13 remains the default.

• ● BIPs #1383 assigns BIP329 to the proposal for a standard wallet label export format. Since the original proposal (see Newsletter #215), the main difference is a switch in data format from CSV to JSON.