This week’s newsletter suggests helping test a Bitcoin Core maintenance
release candidate, provides a link to a modern block explorer whose code
has been open sourced, and briefly describes a suggestion for signature
hashes to optionally cover transaction size. Notable code changes made
in the past week to popular infrastructure projects are also described.
Help test Bitcoin Core 0.17.1RC1: the first release candidate for
this maintenance release has been uploaded. Testing by businesses
and individual users of both the daemon and the GUI is greatly
appreciated and helps ensure the highest-quality release.
Modern block explorer open sourced: after recently
announcing a new block explorer website,
Blockstream has announced the open source release of both its backend and frontend code. The code supports
Bitcoin mainnet, Bitcoin testnet, and the Liquid sidechain.
Although block explorers have been a mainstay of Bitcoin web
applications since 2010, we do note that the method used by block
explorers of maintaining multiple indexes over all block chain data
inherently has a poor scalability characteristic—their cost
increases over time as the block chain grows—and so it is
generally inadvisable to build software or services that depend upon
your own block explorer. Trusting someone else’s block explorer
(which is a common cost-cutting measure when indexing data yourself
becomes too expensive) introduces third party trust into Bitcoin
software, increases centralization, and decreases privacy. If at
all possible, it is preferable to build software and services in a
way that doesn’t require the types of fast and arbitrary searches
that block explorers make convenient.
That said, the new open source explorer appears to be quite
efficient compared to earlier open source alternatives such as
BitPay Insight. It also includes modern features (such as bech32
address support) and a very nice default theme.
Sighash options for covering transaction weight: as part of the
signature hashes discussion described in the News section of
newsletter #23, Russell O’Connor has proposed
that there should be an opt-in ability for transaction signatures to
commit to the weight (size) of the transaction. This mitigates a
perceived problem with some advanced scripts where it might be
possible for a counterparty or third party to add extra data to a
transaction, lowering its feerate and likely making it take longer to
LND #2007 adds a new MaxBackoff configuration option that allows
changing the longest amount of time the node will wait before
giving up attempting to reconnect one of its persistent peers.
The same current exponential backoff algorithm will be used up until
the maximum is reached.
LND #2006 makes it easier to use the autopilot recommendation
engine with alternative recommendation engines. The current method
simply returns a list of peers with whom it is recommended to open new
channels. The new method allows specifying what data to consider and
returns a list of nodes scored by the algorithm (higher scores being
better). Alternative recommendation engines can return their own scored
recommendations, and the user (or their software) can decide how to
aggregate or otherwise use the scores to actually decide which nodes
should receive channel open attempts.
C-Lightning #2123 adds a new check RPC that checks whether an
RPC call uses valid parameters without running the call.
C-Lightning #2127 adds a new --plugin-dir configuration option
that will load plugins in the indicated directory. The parameter may
be passed multiple times for different directories. A --plugin
option also allows loading individual plugins.
C-Lightning #2121 allows plugins to add new JSON-RPC methods. To
the user, these will look no different than the built-in methods,
including appearing in the list of supported methods returned by the
C-Lightning #2147 adds a new announce parameter to the
fundchannel RPC that allows marking the channel as private, meaning
it won’t be publicly announced to the network. The default is for
channels to be public.