This week’s newsletter includes a reminder to please help test the
release candidate for Bitcoin Core’s next version, information about the
development of Optech’s new public dashboard, summaries of two
discussions on the Bitcoin-Dev mailing list, and notable commits from
Bitcoin infrastructure projects.
Allocate time to test Bitcoin Core 0.17RC2: Bitcoin Core has
uploaded binaries for 0.17 Release Candidate (RC) 2.
Testing is greatly appreciated and can help ensure the quality of the
Optech dashboard: a blog post by Marcin
Jachymiak introduces the live dashboard he developed for Optech during
his internship this summer, providing not only an overview of what
information the dashboard makes available to you but a description of
how he built it for anyone who wants to independently replicate the
data or otherwise extend the dashboard using their own full node.
The rest of the Optech team thanks Marcin for his dedicated work and
keen insight, and we wish him all the best in the upcoming year.
Discussion of resetting testnet: Bitcoin’s first public testnet was
introduced in late 2010; a few months later it was reset to testnet2;
and reset again to the current testnet3 in mid-2012. Today testnet3
has over 1.4 million blocks and consumes over 20 GB of disk space on
archival nodes. A discussion was started on the
Bitcoin-Dev mailing list about resetting testnet again to provide a
smaller chain for experimentation. In addition to discussion about
whether or not it’s good to have a large test chain for
experimentation, it was also suggested that a future
testnet might want to use signed blocks instead of proof of work to
allow the chain to operate more predictably than the current testnet3,
which is prone to wild hash rate oscillations. This would also allow
the easy management of testnet disaster drills such as large chain
Proposed sighash updates: before signing a transaction, a Bitcoin
wallet creates a cryptographic hash of the the unsigned transaction
and some other data. Then, instead of signing the transaction
directly, the wallet signs that hash. Since the original 0.1 implementation
of Bitcoin, wallets have been allowed to remove certain parts of the
unsigned transaction from the hash before signing it, which allows those
parts of the transaction to be changed by other people such as
other participants in a multiparty contract.
In BIP143, segwit preserved all of the original Bitcoin 0.1
signature hash (sighash) flags but made some minor (but useful)
changes to what data wallets include in the hash that made it harder
for miners to DoS attack other miners and which made it easier for
underpowered devices such as hardware wallets to protect users
funds. This week, BIP143 co-author Johnson Lau posted some suggested changes to sighash flags, including new
flags, that could be implemented as a soft fork using the witness
script update mechanism provided as part of segwit.
If the changes are adopted, some of the notable advantages include:
making it easier for hardware wallets to securely participate in
CoinJoin-style transactions as well as other smart
contracts, potentially easier fee bumping by any individual
party in a multiparty transaction, and preventing counter
parties and third parties to sophisticated smart contracts from
bloating the size of multiparty transactions in a DoS attack that
lowers a transaction’s fee priority.
Notable commits this week in Bitcoin Core, LND, and C-lightning. Reminder: new merges to
Bitcoin Core are made to its master development branch and are unlikely
to become part of the upcoming 0.17 release—you’ll probably have to
wait until version 0.18 in about six months from now.
Bitcoin Core #12952: after being deprecated for several major
release and disabled by default in the upcoming 0.17 release, the
built-in accounts system in Bitcoin Core has been removed from the
master development branch. The accounts system was added in late 2010
to allow an early Bitcoin exchange to manage their user accounts in
Bitcoin Core, but it lacked many of the features desirable for true
production systems (like atomic database updates) and it often
confused users, so removing it gracefully has been a goal for several
Bitcoin Core #13987: when Bitcoin Core receives a transaction
whose fee per vbyte is below its minimum feerate, it ignores that
transaction. BIP133 (implemented in Bitcoin Core 0.13.0) allows a
node to tell its peers what its minimum feerate is so that those peers
to don’t waste bandwidth by sending transactions that will be ignored.
This PR now provides that information for each peer in the
getpeerinfo RPC using the new minfeefilter value,
allowing you to easily discover the minimum feerates being used by
C-Lightning now allows you to ask lightningd to calculate a feerate
target for your on-chain transactions by passing the either “urgent”,
“normal”, or “slow” to the feerate parameter. Alternatively, you
may use this parameter to manually specify a particular feerate you
want to use.