This week’s newsletter describes a proposed modification to the BIP process, summarizes a plan to add support for package relay to Bitcoin Core, and links to a discussion about adding LN node information to DNS. Also included are our regular sections with descriptions of changes to services and client software, how you can prepare for taproot, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

News

  • ● BIP extensions: Karl-Johan Alm posted to the Bitcoin-Dev mailing list a proposal that BIPs which have achieved a certain stability no longer be modifiable except for small fixes. Any modification of the terms of a stable BIP would need to be made through a new BIP which extends the earlier document.

    Anthony Towns argued against the idea and suggested several alternative tweaks to the current process, including a Drafts folder in the BIPs repository and removing the ability of the BIPs maintainers to choose which numbers to give particular proposals.

  • ● Package mempool acceptance and package RBF: Gloria Zhao posted to the Bitcoin-Dev mailing list about a design for the package relay of multiple related transactions that would enhance the flexibility and reliability of both CPFP and RBF fee bumping. An initial implementation only allows packages to be submitted via Bitcoin Core’s RPC interface, but the ultimate goal is to make the feature available over the P2P network. Zhao succinctly summarizes her proposed changes to Bitcoin Core’s transaction acceptance rules:

    • Packages may contain already-in-mempool transactions.
    • Packages are two generations, multi-parent-one-child.
    • Fee-related checks use the package feerate. This means that wallets can create a package that utilizes CPFP.
    • Parents are allowed to RBF mempool transactions with a set of rules similar to BIP125. This enables a combination of CPFP and RBF, where a transaction’s descendant fees pay for replacing mempool conflicts.

    The email requests feedback on the proposal from developers who expect to use the features or who think they might be affected by the changes.

  • ● DNS records for LN nodes: Andy Schroder posted to the Lightning-Dev mailing list a suggestion to standardize the use of a set of DNS records for resolving a domain name to an LN node IP address and public key. The idea was still being discussed at the time of this writing.

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

  • ● Lightning Address identifiers announced: André Neves announced the Lightning Address protocol which wraps LNURL-pay flows into familiar email-like addresses.

  • ● ZEBEDEE releases LN wallet browser extension: ZEBEDEE announces Chrome and Firefox extensions which integrate with its gaming-focused wallet.

  • ● Specter v1.6.0 supports single-key taproot: Specter’s v1.6.0 release includes support for both regtest and signet taproot addresses.

  • ● Impervious releases LN P2P data API: the Impervious framework, built on LND, allows developers to build P2P data streaming applications over the Lightning Network.

  • ● Fully Noded v0.2.26 released: Fully Noded, a Bitcoin and Lightning wallet for macOS/iOS, adds support for taproot, BIP86, and signet.

Preparing for taproot #14: testing on signet

A weekly series about how developers and service providers can prepare for the upcoming activation of taproot at block height 709,632.

Although you can’t safely use taproot before block 709,632 on mainnet, you can use taproot today with either testnet or signet. Compared to creating a local test network with Bitcoin Core’s regtest mode, as done in the Optech taproot workbooks, using testnet or signet makes it easier to test how your wallet interacts with other people’s wallets.

In this post, we’ll receive and spend a taproot transaction using Bitcoin Core’s built-in wallet on signet. You should be able to adapt these instructions for testing receives and spends between your own wallet and Bitcoin Core.

Although it’s technically possible to receive and spend taproot transactions using the built-in wallet in Bitcoin Core 22.0, we recommend that you instead build Bitcoin Core pull request #22364, which makes taproot the default for descriptor wallets. Once built, start signet:

$ bitcoind -signet -daemon

If this is your first time using signet, you’ll need to sync its block chain. That currently includes less than 200 MB of data and can finish syncing in as little as a minute. You can monitor sync progress using the getblockchaininfo RPC. After syncing, create a descriptor wallet:

$ bitcoin-cli -signet -named createwallet wallet_name=p4tr descriptors=true load_on_startup=true
{
  "name": "p4tr",
  "warning": "Wallet is an experimental descriptor wallet"
}

Now you can create a bech32m address:

$ bitcoin-cli -named -signet getnewaddress address_type=bech32m
tb1p6h5fuzmnvpdthf5shf0qqjzwy7wsqc5rhmgq2ks9xrak4ry6mtrscsqvzp

With this address, you can request funds from the signet faucet. You’ll then need to wait for a confirmation, which will take the same variable amount of time you’d expect on mainnet (typically up to 30 minutes, but sometimes longer). If you look at the transaction, you’ll notice the P2TR script you created.

$ bitcoin-cli -signet getrawtransaction 688f8c792a7b3d9cb46b95bfa5b10fe458617b758fe4100c5a1b9536bedae4cd true | jq .vout[0]
{
  "value": 0.001,
  "n": 0,
  "scriptPubKey": {
    "asm": "1 d5e89e0b73605abba690ba5e00484e279d006283bed0055a0530fb6a8c9adac7",
    "hex": "5120d5e89e0b73605abba690ba5e00484e279d006283bed0055a0530fb6a8c9adac7",
    "address": "tb1p6h5fuzmnvpdthf5shf0qqjzwy7wsqc5rhmgq2ks9xrak4ry6mtrscsqvzp",
    "type": "witness_v1_taproot"
  }
}

You can then create a second bech32m address and send the funds there to test spending.

$ bitcoin-cli -named -signet getnewaddress address_type=bech32m
tb1p53qvqxja52ge4a7dlcng6qsqggdd85fydxs4f5s3s4ndd2yrn6ns0r6uhx
$ bitcoin-cli -named -signet sendtoaddress address=tb1p53qvqxja52ge4a7dlcng6qsqggdd85fydxs4f5s3s4ndd2yrn6ns0r6uhx amount=0.00099
24083fdac05edc9dbe0bb836272601c8893e705a2b046f97193550a30d880a0c

For this spend, we can look at one of the inputs and see that its witness contains nothing but a single 64-byte signature. That’s smaller in vbytes than the witness which would’ve been required if this was a P2WPKH spend or any other type of older Bitcoin spend.

$ bitcoin-cli -signet getrawtransaction 24083fdac05edc9dbe0bb836272601c8893e705a2b046f97193550a30d880a0c true | jq .vin[0]
{
  "txid": "bd6dbd2271a95bce8a806288a751a33fc4cf2c336e52a5b98a5ded432229b6f8",
  "vout": 0,
  "scriptSig": {
    "asm": "",
    "hex": ""
  },
  "txinwitness": [
    "2a926abbc29fba46e0ba9bca45e1e747486dec748df1e07ee8d887e2532eb48e0b0bff511005eeccfe770c0c1bf880d0d06cb42861212832c5f01f7e6c40c3ce"
  ],
  "sequence": 4294967294
}

By playing around with the above commands, you should find it easy to receive and spend money using taproot with any wallet that supports signet.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

  • ● Bitcoin Core 0.21.2rc2 is a release candidate for a maintenance version of Bitcoin Core. It contains several bug fixes and small improvements.

Notable code and documentation changes

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

  • ● Eclair #1932 implements the revised anchor outputs protocol specified in BOLTs #824, where all presigned HTLC spends use zero fee, so no fees can be stolen. See Newsletter #165 for details.

  • ● LND #5405 extends the updatechanpolicy RPC so that it reports any channels that are currently unusable due to the current policy (or because of other issues, such as the channel funding transaction still being unconfirmed).

  • ● LND #5304 enables LND to create and validate macaroons with external permissions unknown to LND itself. This change enables tools such as Lightning Terminal to use a single macaroon to authenticate across multiple daemons that all talk to the same LND.

  • ● Rust Bitcoin #628 adds support for Pay to Taproot’s sighash construction and tidies up storage of the sighash cache for legacy, segwit and taproot inputs.

  • ● Rust Bitcoin #580 adds support for the P2P network messages defined in the BIP37 specification for transaction bloom filtering.

  • ● Rust Bitcoin #626 adds functions to get the stripped size of a block (a block with all its segwit data removed) and the vbyte size of a transaction.

  • ● Rust-Lightning #1034 adds a function that can be used to retrieve the complete list of channel balances, including for channels that are currently in the process of closing. This allows end-user software to display a consistent user balance even when some funds are still waiting for confirmation before they can be used again.