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.


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

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 2256. 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.