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
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.
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
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.
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.)
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:
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
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.
Bitcoin Core #15620 stops the maxtxfee configuration
parameter from affecting the sendrawtransaction and
testmempoolaccept RPCs. Previously those RPCs would default to
rejecting a transaction paying a fee higher than the configured max.
Now a hardcoded default of 0.1 BTC is used as the acceptable ceiling.
The maxtxfee configuration parameter is still used by Bitcoin Core’s
built-in wallet; it has just been separated from node-specific RPCs.
This change is part of a general cleanup of wallet configuration
options as well as part of separating the node
and wallet (which both used this setting before this change).
Bitcoin Core #15643 changes the Python script Bitcoin Core
developers use to merge commits so that the git merge message includes
a list of which developers approved (ACKed) the version of a PR that
was merged. (This internal project change is perhaps not notable by
itself, but one of the tool’s other features—copying the full PR
description into the merge message—makes it much easier for the
author of this section to write these merge summaries, so he
encourages other Bitcoin projects to investigate the advantages of
using this tool for automatically creating better git-based
documentation, as well as improving their security and auditability.)
Bitcoin Core #15637 modifies the mempool-related RPCs (such as
getrawmempool) to rename the size field to vsize. The previous
value was also the vsize, so the calculation has not changed. This
merged PR simply makes it clear that this is a vsize and not a
stripped size. For backwards compatibility, you can start Bitcoin
Core with the deprecatedrpc=size parameter to continue using the old
field name, although this will be removed in a future release.
LND #2759 lowers the default CLTV delta for all channels from 144
blocks (about 24.0 hours) to 40 blocks (about 6.7 hours). When Alice
wants to pay Zed through a series of routing nodes, she starts by
giving money to Bob under the terms that either Alice can take it back
after (say) 400 blocks or Bob can claim the money before then if he
can provide the preimage for a particular hash (the key that opens a
hashlock). The 400 block delay is enforced onchain if necessary
using OP_CHECKLOCKTIMEVERIFY (CLTV). Bob then sends the money
(minus his routing fee) to Charlie with similar terms except that the
CLTV value is reduced from Alice’s original 400 blocks by the CLTV delta of his channel with Charlie,
reducing the value to 360 blocks. This ensures that if Charlie
waits the maximum time to fulfil his HTLC to Bob and claim his payment
(360 blocks), Bob still has 40 blocks to claim his payment from Alice by
fulfilling the original HTLC. If Bob’s HTLC expiry time with Charlie wasn’t reduced at all and
used a 400 block delay, Bob would be at risk of losing money. Charlie could
delay fulfilling his HTLC until 400 blocks, and Alice could then cancel her
HTLC with Bob before Bob had time to fulfil the HTLC.
Subsequent routers each successively subtract their delta from the value of
the terms they give to the next node in the route. Using a high CLTV delta
therefore reduces the possible number of hops that can be used in a route, and
makes a channel less attractive for use when routing payments.
Eclair #894 replaces the JSON-RPC interface with an HTTP
POST interface. Instead of RPC commands, HTTP endpoints are used
(e.g. the channelstats RPC is now POST
http://localhost:8080/channelstats). Parameters are provided to the
endpoint using named form parameters with the same JSON syntax as
used with RPC parameters. Returned results are identical to before
the change. The old interface is still available using the
configuration parameter eclair.api.use-old-api=true, but it is
expected to be removed in a subsequent release. See the updated API
documentation for details.