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.

Action items

  • 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.

News

  • 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 confirm.

Notable code changes

Notable code changes this week in Bitcoin Core, LND, C-lightning, and libsecp256k1.

  • 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 help RPC.

  • 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.