This week’s newsletter notes a spike in estimated transaction fees, describes LN trampoline payments, and publicizes Bitcoin Core’s intent to default its built-in wallet to bech32 receiving addresses in version 0.20 or earlier. Also included are regular sections about bech32 sending support and notable code changes in popular Bitcoin infrastructure projects.

Action items

● Help test Bitcoin Core 0.18.0 RC2: The second Release Candidate (RC) for the next major version of Bitcoin Core has been released. Testing is still needed by organizations and experienced users who plan to run the new version of Bitcoin Core in production. Use this issue for reporting feedback.

Network status

● Fee increases for fast confirmation: after over a year of most Bitcoin transactions confirming rather quickly as long as they paid a feerate above the default minimum relay fee (except during a brief exceptional period), a modest backlog has developed over the previous week and raised the feerates for people who need their transactions to confirm within the next several blocks. Spenders willing to wait a bit longer can still save money. For example, as of this writing, Bitcoin Core’s fee estimator suggests a fee of 0.00059060 BTC per 1,000 vbytes confirmation within 2 blocks but only 0.00002120 for confirmation within 50 blocks—saving over 95% for waiting up to an extra 8 hours. For more information, we recommend Johoe’s mempool statistics and P2SH.info’s fee estimate tracker.

News

● Trampoline payments for LN: Pierre-Marie Padiou started a thread on the Lightning-Dev mailing list suggesting that Alice could send a payment to Zed even if she didn’t know a path to his node by first sending a payment to an intermediate node (Dan) and asking Dan to figure out the route the rest of the way to Zed. This would especially benefit Alice if she ran a lightweight LN node that didn’t attempt to keep track of the entire network. For increased privacy, Alice could use several intermediate nodes rather than just one (each one receiving its own instructions encrypted by Alice). A downside described in the email is that Alice could only make a rough guess about the required fees as she wouldn’t know the actual path, so she’d probably end up paying more in fees than if she chose the route herself.

● Bitcoin Core schedules switch to default bech32 receiving addresses: since version 0.16.0, Bitcoin Core’s built-in wallet has defaulted to generating P2SH-wrapped segwit addresses when users want to receive payments. These addresses are backwards compatible with all widely-used software. As discussed in an issue and the project’s weekly meeting, starting with Bitcoin Core 0.20 (expected about a year from now), Bitcoin Core will default to native segwit addresses (bech32) that provide additional fee savings and other benefits. Currently, many wallets and services already support sending to bech32 addresses, and if the Bitcoin Core project sees enough additional adoption in the next six months to warrant an earlier switch, it will instead default to bech32 receiving addresses in Bitcoin Core 0.19. P2SH-wrapped segwit addresses will continue to be provided if the user requests them in the GUI or by RPC, and anyone who doesn’t want the update will be able to configure their default address type. (Similarly, pioneering users who want to change their default now may set the addresstype=bech32 configuration option in any Bitcoin Core release from 0.16.0 up.)

Bech32 sending support

Week 3 of 24. Until the second anniversary of the segwit soft fork lock-in on 24 August 2019, the Optech Newsletter will contain this weekly section that provides information to help developers and organizations implement bech32 sending support—the ability to pay native segwit addresses. This doesn’t require implementing segwit yourself, but it does allow the people you pay to access all of segwit’s multiple benefits.

In a previous week, we discussed how small the differences are between creating the output for a legacy address versus a native segwit address. In that section we simply pointed you towards the bech32 reference libraries and told you that you’d get two values back. In this week, we walkthrough the exact steps of using the Python reference library so you can see how little work this is. We start by importing the library:

>>> import segwit_addr

Bech32 addresses have a Human-Readable Part (HRP) that indicates what network the address is for. These are the first few characters of the address and are separated from the data part of the address by the delimiter 1 . For example, Bitcoin testnet uses tb and an example testnet address is tb1q3w[…]g7a. We’ll set the Bitcoin mainnet HRP of bc in our code so that we can later ensure that the addresses we parse are for the network we expect.

>>> HRP='bc'

Finally, we have a few addresses we want to check—one that should work and two that should fail. (See BIP173 for a complete set of reference test vectors.)

>>> good_address='bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh' >>> typo_address='bc1qd6h6vp99qwstk3z669md42q0zc44vpwkk824zh' >>> wrong_network_address='tb1q3wrc5yq9c300jxlfeg7ae76tk9gsx044ucyg7a'

Now we can simply attempt to decode each of these addresses

>>> segwit_addr.decode(HRP, good_address) (0, [110, 175, 166, 4, 165, 3, 160, 187, 68, 90, 209, 246, 218, 168, 15, 22, 43, 86, 5, 214]) >>> segwit_addr.decode(HRP, typo_address) (None, None) >>> segwit_addr.decode(HRP, wrong_network_address) (None, None)

If we get back a None for the first value (the witness version), the address is invalid on our chosen network. If that happens, you want to throw an exception up the stack so that whatever process is interfacing with the user can get them to provide you with a correct address. If you actually get a number and an array, the decode succeeded, the checksum was valid, and the length was within the allowed range.

The witness version must be a number between 0 and 16, so you’ll want to check that (e.g. 0 <= x <= 16 ) and then convert it into the corresponding opcodes OP_0 through OP_16 . For OP_0 , this is 0x00; for OP_1 through OP_16 , this is 0x51 through 0x60. You then need to add a push byte for the data depending on its length (0x02 through 0x28 for 2 to 40 bytes), and then append the data as a series of bytes. Pieter Wuille’s code does this quite succinctly:

>>> witver, witprog = segwit_addr.decode(HRP, good_address) >>> bytes([witver + 0x50 if witver else 0, len(witprog)] + witprog).hex() '00146eafa604a503a0bb445ad1f6daa80f162b5605d6'

That’s your entire scriptPubKey. You can use that in the output of a transaction and send it. Note that bech32 scriptPubKeys can vary in size from 4 to 42 vbytes, so you need to consider the actual size of the scriptPubKey in your fee estimation code.

Your code doesn’t need to be written in Python. Reference libraries are also provided for C, C++, Go, Haskell, JavaScript, Ruby, and Rust. Further, BIP173 describes bech32 well enough that any decent programmer should be able to implement it from scratch in their preferred language without requiring anything beyond what most programming languages provide in their builtins and standard library.

Other bech32 sending support updates: BitGo announced that their API now supports sending to bech32 addresses; see their announcement for additional details about bech32 receiving support. The Gemini exchange also apparently added bech32 sending support this week, and users report that Gemini defaults to accepting deposits to bech32 addresses as well.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, LND, C-Lightning, Eclair, libsecp256k1, and Bitcoin Improvement Proposals (BIPs). Note: all merges described for Bitcoin Core are to its master development branch; some may also be backported to the 0.18 branch for the pending 0.18.0 release.