This week’s newsletter suggests an update for C-Lightning users, describes a discussion about BIP69 deterministic input/output ordering on the mailing list, notes public overt ASICBoost support is available for miners using Antminer S9, and provides links to resources about both Square’s open sourced Subzero HSM-based multisig cold storage solution and the recent Lightning Network Residency and Hackday in New York City. Also included are selected recent Q&A from Bitcoin Stack Exchange and descriptions of notable code changes in popular Bitcoin infrastructure projects.

Action items

  • ● Update to C-Lightning 0.6.2: fixes a bug where the node would send an excessive number of update announcements to its peers about dead channels.

News

  • ● BIP69 discussion: this BIP from 2015 adopted by several notable wallets specifies an optional method for deterministically ordering inputs and outputs within a transaction based on the public contents of the transaction. However, other wallets have not adopted it (or even rejected it as unsuitable for adoption), leading perhaps to a “worst of both worlds” situation where wallets using BIP69 can be fairly easily identified and so wallets not using BIP69 may also be easier to identify by negation.

    In this thread to the Bitcoin-Dev mailing list, Ryan Havar suggests that one reason wallet authors like BIP69 is that its deterministic ordering makes it easy and fast for their tests to ensure that they haven’t leaked any information about the source of their inputs or the destination of their outputs (e.g. in some old wallets, the fist output always went to the recipient and the second output was always change—making coin tracking trivial). Havar then suggests an alternative deterministic ordering based on private information that would be available to the test suite but not exposed by production wallets, allowing developers who want to thwart block chain analysis—but also have simple and fast tests—to migrate away from BIP69.

  • ● Overt ASICBoost support for S9 miners: support for this efficiency-improving feature was announced by both Bitmain and Braiins this week. ASICBoost takes advantage of the fact that the SHA256 algorithm used in Bitcoin mining first splits the 80 byte block header into 64 byte chunks. If a miner can find multiple proposed block headers where the first chunk of 64 bytes are different but start of the next chunk of 64 bytes are the same, then they can try different combinations of the first chunk and second chunk to reduce the total number of hashing operations they need to carry out to find a valid block. Early estimates indicate an improvement of 10% (or perhaps more) on existing Antminer S9 hardware.

    The overt form of ASICBoost alters the versionbits field in the block header, which can cause programs such as Bitcoin Core to display a warning such as “13 of last 100 blocks have unexpected version”. Some ASICBoost miners have voluntarily restricted their altered versionbits range to that defined by BIP320, giving future programs the option to ignore those bits for upgrade signaling.

  • ● Open sourced HSM-based multisig cold storage solution: Square has released code and documentation for the cold storage solution they’ve implemented to protect customer deposits, as well as a CLI tool for auditing HD wallet balances at arbitrary points in time. Optech has not evaluated their solution, but we can recommend interested parties read Square’s excellent blog post and visit the repositories for the Subzero cold storage solution and Beancounter auditing tool.

  • ● Lightning Residency and Hackday: last week Chaincode Labs hosted a five-day Lightning Network Residency program to help onboard developers to the fledgling protocol. Following this, Fulmo organized their fourth Lightning Network Hackday (actually two days) also in New York City with a few speeches, many demos, and lots of hacking.

    Pierre Rochard has written summaries of all the presentations given at the residency program (day 1, day 2, day 3, day 4) and videos of the presentations are expected to be posted soon. Videos of the hackday are available now: day 1, day 2.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange 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.

  • ● Does using pruning make initial node sync faster? Pruning blocks after they’ve been processed can reduce disk space requirements by over 97% at present, but do they also speed up sync? Bitcoin Core developer Gregory Maxwell answers.

  • ● Can someone steal from you by closing their Lightning Network payment channel in a certain way? Several different ways to close a Lightning Network payment channel are described, and C-Lightning developer Christian Decker explains how a program following the LN protocol will protect your money in each case.

  • ● How much energy does it take to create one block? Nate Eldredge provides a simple formula and set of links to data that anyone can use to estimate the average amount of energy it would take to generate a block at the current difficulty level. For the present difficulty using only Antminer S9s without ASICBoost, an average block consumes 841,629 kilowatt hours (kWh). At a common estimate of $0.04/kWh, this is about $34,000 of electricity—well below the current block subsidy of about $80,000—but using AJ Towns’s recent estimate of $0.16/kWh that includes costs beyond electricity and attempts to factor in risk premiums, the estimated block cost is about $135,000.

Notable merges

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

  • ● Bitcoin Core #14451 allows optionally building Bitcoin-Qt without support for the BIP70 payment protocol and adds a deprecation warning indicating the default support may be removed in a future release. The CEO of BitPay, which is the largest user of BIP70 (but which wants to use a different version of the protocol), indicated that they supported Bitcoin Core removing BIP70. Developers seem to be in favor of removing the protocol for security reasons and because it’s seeing declining use. The BIP70 dependency on OpenSSL resulted in the emergency release of Bitcoin Core 0.9.1 in 2014 as a result of the heartbleed vulnerability, and it is expected that removing it will eliminate the risk of future similar vulnerabilities.

  • ● Bitcoin Core #14296 removes the deprecated addwitnessaddress RPC. This RPC was added in version 0.13.0 to enable testing segwit on regtest and testnet before it was activated on mainnet and built into the wallet. Since version 0.16.0, Bitcoin Core’s wallet has supported getting addresses directly using the regular getnewaddress mechanism.

  • ● Bitcoin Core #14468 deprecates the generate RPC. This method generates new blocks in regtest mode but it requires getting new addresses from Bitcoin Core’s built-in wallet in order to pay them the mining block reward. A replacement method, generatetoaddress was introduced in version 0.13.0, which allows any regtest wallet to generate an address that will be paid the block reward. This is part of an ongoing effort to allow as many RPCs as possible to function without the wallet in order to improve test coverage of non-wallet nodes as well as to ease a future possible transition to fully separating the wallet from the node.

  • ● Bitcoin Core #14150 adds key origin support to output script descriptors. Besides allowing you to pass an additional argument to the scantxoutset RPC, this doesn’t currently add any features to Bitcoin Core—but it will enable using key origin with BIP174 PSBTs and watch-only wallets when those parts of the software have been updated to use descriptors. See Newsletters #5, #7, #9, #12, and #17 for previous discussion of output script descriptors. Key origin support makes it possible to use extended pubkeys that have been exported from an HD wallet that uses BIP32 hardened derivation for protecting ancestor private keys, which helps make output script descriptors compatible with most hardware wallets.

  • ● LND #1981 ensures that LND doesn’t leak information about any of its peers that aren’t advertising themselves as public nodes.

  • LND #1535 and #1512 adds the server-side communication protocol for watchtowers along with many tests verifying its proper operation. Correct use of the LN protocol requires regular monitoring of which transactions get added to the block chain, so watchtowers are servers designed to help defend the payment channels of users who expect to be offline for an extended period of time. As such, watchtowers are considered to be a key feature for enabling wider adoption of LN by less advanced users. However, a standard specification for watchtowers has not been agreed upon by the multiple implementations of LN, so LND is only putting this feature out for initial testing and is restricting its use to testnet.