This week’s newsletter includes information about the first published
release candidate for Bitcoin Core, news about BIP151 P2P protocol
encryption and a potential future soft fork, top questions and answers
from Bitcoin StackExchange, and some notable merges in popular Bitcoin
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
PR opened for initial BIP151 support: Jonas Schnelli opened a pull
request to Bitcoin Core providing an initial implementation of BIP151 encryption for the peer-to-peer network
protocol. He also has an updated draft of the BIP151
specification that incorporates changes he’s made in the development
of the implementation. If accepted, this will allow both full nodes
and lightweight clients to communicate blocks, transactions, and
control messages without ISPs being able to eavesdrop on the
connections, which can make it harder to determine which program
originated a transaction (especially in combination with Bitcoin
Core’s existing transaction origin protection or future proposals such
as the Dandelion protocol).
Schnelli is also working with other developers to implement and test
the NewHope key exchange protocol which is believed to be
resistant to attacks by quantum computers so that an eavesdropper who
records communication between two peers today won’t be able to
decrypt that data in a future where they posses a fast quantum
Requests for soft fork solutions to the time warp attack: Bitcoin
blocks include the time the block was supposedly created by a miner.
These timestamps are used to adjust the difficulty of mining blocks so
that a block is produced on average every 10 minutes. However, the
time warp attack allows miners representing a large fraction of the
network hash rate to consistently lie about when blocks were created
over a long period of time in order to lower difficulty even as blocks
are being produced more frequently than once every 10 minutes.
Gregory Maxwell has asked the Bitcoin protocol
development mailing list for proposed soft fork solutions to the
attack before he proposes his own solution. So far, Johnson Lau has
proposed one technique.
Note: anyone monitoring the block chain for this type of attack
would have at least one month’s notice before any significant damage
was done. For that reason and because there are multiple known
methods of countering the attack (with varying tradeoffs), fixing
the time warp attack has never been considered urgent. However, if
the attack risk can be mitigated fully or partly by a
non-controversial soft fork, that would certainly be nice.
Selected Q&A from Bitcoin StackExchange
Bitcoin StackExchange is one of the first places Optech
contributors look for answers to their questions—or when we have a
few spare moments of time to help answer other people’s questions. In
this monthly feature, we highlight some of the top voted questions and
answers made since our last update.
Can you pay 0 bitcoins? Andrew Chow explains that not
only can you pay a zero-value amount to an address or other script,
you can also spend from a zero-value output—but only if you find a
miner who doesn’t use the default settings in Bitcoin Core.
Can you create an SPV proof of the absence of a transaction?
Simplified Payment Verification (SPV) uses a merkle tree to prove a
transaction exists in a block that itself belongs to the best block
chain—the block chain with the most proof of work. But could you
create the reverse? Could you prove that a transaction is not in a
particular block or in any block on the best block chain?
Gregory Maxwell explains that it’s possible, and it would also
involve using merkle trees, but that it would likely require
computationally expensive (but bandwidth efficient) zero-knowledge
Can you convert a P2PKH address to P2SH or segwit?Don’t do this.
Pieter Wuille explains why this is a very bad idea and likely to
result in lost money. Note: this is an older answer that saw
increased attention this month after some users attempted to convert
other people’s addresses to segwit and lost money as a result.
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 #12254 adds the functions necessary to allow Bitcoin
Core to generate BIP158 compact block filters. This code isn’t
currently used by Bitcoin Core, but future work is expect to use these
functions to provide two features:
BIP157 support for sending filters to light clients over the
peer-to-peer (P2P) network protocol. This can allow P2P
lightweight wallets to find blocks with transactions that affect
their wallet much more privately than currently possible with
BIP37 bloom filters.
Faster rescans for Bitcoin Core’s built-in wallet.
Occasionally users of Bitcoin Core need to rescan the block
chain to see if any historic transactions affected their
wallet—for example, when they import a new private key, public
key, or address. This currently takes over an hour even on
modern desktops, but users with local BIP157 filters will be able
to perform the rescan much faster and still with information
theoretic perfect privacy (which lightweight clients don’t
Bitcoin Core #12676 adds a field to the getrawmempool,
getmempoolentry, getmempoolancestors, and getmempooldescendants
RPC results to display whether or not a transaction opts-in to
signaling its spender wants it to be replaced by a transaction
spending any of the same inputs with a higher fee as described by
C-Lightning tagged its first release candidate for version 0.16.1.
C-Lightning reduced the number of places where it refers to 1,000
weight units as “sipa” and began calling them by the more widely
accepted term “kiloweights” (kw).
C-Lightning made multiple improvements to how it handles fees,
both for on-chain transactions to open and close channels where
C-Lightning outsources fee estimation to Bitcoin Core, and also for
fees in payment channels.
C-Lightning implemented additional parts of BOLT2, particularly
related to the option_data_loss_protect field, to improve handling
of cases where your node appears to have lost essential data—a
commitment value—or the remote node is sending invalid commitment
data and possibly deliberately lying.