This week’s newsletter includes the usual dashboard and action items, a link to discussion about generalized Bitcoin contracts over Lightning Network, a brief description of a recently-announced library for scalability-enhancing BLS signatures, and some notable commits from the Bitcoin Core, LND, and C-Lightning projects.

Action items

  • Optech has begun planning its first European workshop, which is set to take place in Paris sometime in November. If any member companies who think they’ll be able to attend have topics they’re interested in discussing, please email Optech. More information on the workshop will be released in a few weeks.

Dashboard items

  • ● Transaction fees remain very low: Anyone who can wait 10 or more blocks for confirmation can reasonably pay the default minimum fee rate. It’s a good time to consolidate UTXOs.

  • Adoption of opt-in RBF remains fairly low, but has materially grown the past year, increasing from 1.5% to 5.7% of transactions. This data was sourced from Optech’s beta dashboard, which we encourage people to try out and provide us feedback!

    Transactions signaling opt-in RBF, August 2017 - August 2018 Transactions signaling opt-in RBF, August 2017 - August 2018, source: Optech dashboard

News

  • ● Discussion of arbitrary contracts over LN: a thread on the Lightning Network (LN) development mailing list last week described the basic principles for performing arbitrary Bitcoin contracts in a payment channel. Instead of an independent contract that resolves to True in order to be a valid transaction, the exact same contract is included in a LN payment and must return true in order for the in-channel payment transaction to be valid. Everything else in the arbitrary contract as well as the LN payment can stay the same, with some specific exceptions discussed in this thread started by knowledgeable pseudonymous researcher ZmnSCPxj.

  • ● Library announced for BLS signatures: well-known developer Bram Cohen announced a “first draft (but fully functional) library for doing BLS signatures based on a construction based on MuSig”. These signatures provide most of the same benefits of Schnorr signatures as described in Newsletter #3’s featured news but also allow non-interactive signature aggregation which can allow for greater scalability by reducing the amount of signature data in the block chain (possibly by a very large percentage) and potentially enhancing privacy by implementing techniques for non-interactive coinjoins such as those described in the Mimblewimble paper.

    BLS signatures do come with three downsides that have lead most Bitcoin protocol developers to focus on Schnorr signatures for the short-term. The first is that there’s no known way to verify them as fast as Schnorr signatures—and signature verification speed is also important for network scalability. Second, to prove that BLS signatures are secure requires making an additional assumption about part of the scheme being secure that isn’t required for proving the security of Bitcoin’s current scheme (ECDSA) or proposed Schnorr-based scheme. Finally, BLS signatures have only been around for about half as long as Schnorr signatures, are even less commonly used, and are not believed to have received the same amount of expert review as Schnorr signatures.

    Still, this open source library gives developers a convenient way to begin experimenting with BLS signatures and even start to use them in applications that don’t need to be as secure as the Bitcoin network.

Notable commits

Notable commits this week in Bitcoin Core, LND, and C-lightning.

  • ● Bitcoin Core #13697: This PR by Pieter Wuille mentioned in Newsletter #5 to add output script descriptors support to the upcoming 0.17 RPC scantxoutset has been merged. These descriptors provide a comprehensive way to describe to software what output scripts you want to find, and it’s expected to be adapted over time to other parts of the Bitcoin Core API such as importprivkey, importaddress, importpubkey, importmulti, and importwallet.

  • ● Bitcoin Core #13799: Prior to the first Optech newsletter, a PR was merged that deliberately caused Bitcoin Core to abort startup if the configuration file or start-up parameters contained an option Bitcoin Core didn’t recognize. This greatly simplified debugging of common errors such as typos—but it also prevented users from putting options in their bitcoin.conf that applied to clients such as bitcoin-cli. This new PR removes the startup abort and simply produces a warning. Probably for a future release, a mechanism for client compatibility will be implemented and the startup abort will be restored.

  • ● LND #1579: This updates the primary backend interfaces (such as bitcoind, btcd, and neutrino SPV) to be compatible with the latest (and hopefully final) version of BIP158 compact block filters as implemented in the btcd full node, btcwallet, and Neutrino light wallet. These filters allow a client to determine whether or a not a block probably contains a transaction that affects their wallet, similar to BIP37 bloom filters but much more efficiently for the server (as they don’t need to rescan old blocks) and with additional privacy for the client as they don’t directly give the server any information about what transactions they’re interested in.

  • ● LND #1543: This PR continues work towards creating LN watchtowers that can assist light clients and other programs that aren’t online by monitoring for attempted channel theft and broadcasting the user’s pre-signed breach remedy transaction. This particular PR adds watchtower version 0 encoding and encryption methods by cryptographer Conner Fromknecht.

  • ● C-lightning 55d450ff: C-lightning refuses to forward payments when the forwarding fee exceeds a certain percentage of the payment. However, when the amount being forwarded is tiny, e.g. buying just a few pixels for 10 nBTC each on Satoshis.Place, this rule was always triggered because the minimum fee floor was always a high percentage (e.g. paying 10 nBTC with a minimum fee of 10 nBTC is a 100% fee). This PR provides a new rule that allows payments with forwarding fees up to 50 nBTC to go through regardless of their fee percentage and adds an option so that users can customize that value.