This week’s newsletter describes progress on signet and an idea for just-in-time routing on LN. Also included are our regular sections about bech32 sending support and notable changes to popular Bitcoin infrastructure projects.

Action items

  • ● Help test Bitcoin Core 0.18.1 release candidates: this upcoming maintenance release fixes several bugs that affected some RPC commands and caused unnecessarily high CPU use in certain cases. Production users are encouraged to test the current release candidate to ensure that it operates as expected.

News

  • ● Progress on signet: signet is a testnet alternative where valid blocks are signed by a trusted authority. The authority generally produces a regular series of blocks but may occasionally produce forks leading to block chain reorganizations. This avoids commonly-encountered problems on testnet such as too-fast block production, too-slow block production, and reorganizations involving thousands of blocks. Subsequent to our earlier report on signet in Newsletter #37, its author has created an implementation, documented it on a wiki page, opened a PR proposing to add support for signet to Bitcoin Core, and posted a draft BIP to the Bitcoin-Dev mailing list. The proposed implementation also makes it easy for teams to create their own independent signets for specialized group testing, e.g. signet author Kalle Alm reports that “someone is already working on a signet with bip-taproot patched on top of it.” Signet has the potential to make it much easier for developers to test their applications in a multi-user environment, so we encourage all current testnet users and anyone else interested in signet to review the above code and documentation to ensure signet will fulfill your needs.

  • ● Additional Just-In-Time (JIT) LN routing discussion: in the JIT discussion described in the newsletter two weeks ago, contributor ZmnSCPxj explained why routing nodes needed zero-fee rebalance operations in many cases for JIT routing to be incentive compatible. This week he posted a suggestion to the C-Lightning mailing list on how nodes could be less incentive compatible but still prevent abuse when performing paid rebalancing for JIT routing. Nodes would keep track of how much routing fee they had earned from each channel and spend up to that amount on rebalancing. This would ensure that a dishonest channel counterparty couldn’t steal any more than it had already allowed its honest peers to claim in routing fees.

Bech32 sending support

Week 19 of 24 in a series about allowing the people you pay to access all of segwit’s benefits.

As of this writing, the price of bitcoin in national currencies has been rapidly increasing over the past few months. Significant changes to the bitcoin price are notable in the context of bech32 because transaction fees are paid in bitcoin terms rather than dollar terms. That means the real cost to send a transaction is expected to increase in correspondence with bitcoin prices even if feerates stay the same.

We’ve previously discussed how much users and services can save by switching to native segwit (bech32) addresses, but we’ve only described that in terms of vbyte and percentage savings. In this bech32 sending support section, we look at the savings in real terms.

The lowest practical fee is 0.00000001 BTC/vbyte. The highest typical fees seen to date were around 0.00001000 BTC/vbyte in December 2017 and January 2018. For that range, the following charts show the amount of money that may be saved for users of two common transaction templates, single-sig and 2-of-3 multisig:

Single-sig legacy P2PKH versus segwit P2WPKH

2-of-3 multisig legacy P2SH versus segwit P2WSH

For users of legacy transactions with other transaction templates, you may be able to learn roughly how much you will save in percentage terms by pasting in the txid of a typical transaction you sent into information sites such as an Esplora block explorer like Blockstream.info. You can multiply that percentage by the vbyte size of your transaction to see how many vbytes you’d save. Note that using a third-party service reveals to them that you have an interest in that transaction, possibly significantly reducing your privacy. You can privately get the approximate vbyte savings by examining a typical transaction of yours.1 When you know how many vbytes you’ll save, you can calculate the amount of your savings in another currency by multiplying the saved vbytes by your expected feerate in BTC/vbyte and your expected price per bitcoin, e.g. saved_vbytes * feerate * price.

If users of native segwit begin to save tens or hundreds of dollars per transaction, we expect there to be increased competitive pressure for high-frequency spenders such as exchanges to migrate to only accepting deposits using bech32 addresses. Given that a very large percentage of daily Bitcoin transactions are deposits to exchanges, we would then expect wallets and services that don’t provide bech32 sending support to quickly fall out of favor with users.

Notable code and documentation changes

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

  • ● Bitcoin Core #15891 changes the node defaults when using regtest mode to enforce the same standard transaction rules used on mainnet. Those rules determine which transactions nodes relay and accept into the mempool. This change should make it easier for developers to test their custom transactions against the default policy. Anyone who needs the old behavior of relaying and accepting any consensus-valid transaction may use the acceptnonstdtxn configuration parameter.

  • ● Bitcoin Core #16152 disables BIP37 bloom filter support by default. This feature allowed lightweight wallets to create a bloom filter from a list of their addresses, send that filter to a node, ask the node to scan historic blocks or new incoming transactions, and receive back only those transactions that matched the filter. This allowed the lightweight client to only receive the transactions it was interested in (plus maybe a few extra false-positive matches), reducing its bandwidth requirements. However, it also meant that clients could require full nodes to scan and rescan through the entire historic block chain over and over at no cost to the client—creating the vector for a DoS attack.

    For that reason and others (including privacy concerns) a number of Bitcoin Core contributors have wanted to disable the feature for several years now. Early efforts to that end included adding a BIP111 services flag to indicate whether or not a node supports bloom filters so that clients can find supporting nodes, and a peerbloomfilters configuration option that allows node users to disable bloom filters in case they’re worried about the DoS attack. Additionally, bloom filter support was never updated for checking the contents of the new witness field after segwit was activated, making it less useful than it could be for segwit wallets.

    With this PR #16152, the bloom filter configuration option is now set by default to off. Users who still want to serve bloom filters can re-enable it. More notably, many nodes continue to run old versions for years after newer versions have become available, so it’s expected that developers of wallets using bloom filters will have some time after the release of Bitcoin Core 0.19 (estimated late 2019) to find a replacement source of data.

  • ● Bitcoin Core #15681 adds an exception to Bitcoin Core’s package limitation rules used to prevent CPU- and memory-wasting DoS attacks. Previously, if a transaction in the mempool had 25 descendants, or it and all of its descendants were over 101,000 vbytes, any newly-received transaction that was also a descendant would be ignored. Now, one extra descendant will be allowed provided it is an immediate descendant (child) and the child’s size is 10,000 vbytes or less. This makes it possible for two-party contract protocols such as LN to give each participant an output they can spend immediately for Child-Pays-For-Parent (CPFP) fee bumping without allowing one malicious participant to fill the entire package and thus prevent the other participant from spending their output. This proposal was previously discussed on the Bitcoin-Dev mailing list (see Newsletter #24).

  • ● C-Lightning #2816 adds support for testing on the signet network (see signet description in the news section above).

Footnotes

    1. Use a tool to parse the transaction. Bitcoin Core comes bundled with a tool called bitcoin-tx that can do this for you. Run bitcoin-tx -json <hex_serialized_tx>

    2. Add up the total size of all scriptSigs. bitcoin-tx outputs the hex of each scriptSig. Halve the length of this hex string to get the size of the scriptSig.

    3. Multiply the size of scriptSigs that value by 0.75 to get vbytes saved.

    ↩