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
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.
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
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.
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
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
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
C-Lightning #2816 adds support for testing on the signet network
(see signet description in the news section above).
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>
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.
Multiply the size of scriptSigs that value by 0.75 to get vbytes