This week’s newsletter announces a security disclosure affecting some older releases of Bitcoin Core, describes new developments related to taproot, mentions a potential privacy leak related to the LN payment data format, and describes two proposed changes to the LN specification that are under discussion. Also included is our regular section describing notable changes to popular Bitcoin infrastructure projects.

Action items

None this week.


  • CVE-2017-18350 SOCKS proxy vulnerability: a full disclosure of a vulnerability in Bitcoin Core versions 0.11.0 (Sept 2012) to 0.15.1 (Nov 2017) was published to the Bitcoin-Dev mailing list. The vulnerability only affects users who have configured a SOCKS proxy to use either an untrusted server or to connect over an untrusted network. Almost all affected versions of Bitcoin Core are also affected by previously disclosed vulnerabilities, such as CVE-2016-10724 (see Newsletter #1) and CVE-2018-17144 (see Newsletter #14), so users should have already upgraded to Bitcoin Core 0.16.3 or higher.

  • Possible privacy leak in the LN onion format: as described in BOLT4, LN uses the Sphinx protocol to communicate payment information between LN nodes. Olaoluwa Osuntokun posted to the Lightning-Dev mailing list this week about a recently-published flaw in the original description of Sphinx that may allow a destination node to “deduce a lower bound for the length of the path [back to the source node].” The fix is easy: instead of initializing part of an onion packet with zero bytes, random-value bytes are used instead. Osuntokun created a PR implementing this in the onion library used by LND as well as a documentation PR for the BOLTs repository. Other implementations have also adopted the same change (see the C-Lightning commit below).

  • LN up-front payments: the current LN protocol returns all money to the spender if a payment attempt fails or is rejected by the receiver, so routing nodes only receive income if the payment attempt succeeds. However, some new applications are using this costless failure mechanism to send data over LN without paying for the bandwidth they use. LN designers expected this to happen and have previously spent time thinking about how they could add up-front fees to the network—fees that would be paid to routing nodes whether or not a payment attempt succeeded.

    This week, Rusty Russell started a thread on the Lightning-Dev mailing list to discuss proposals for up-front fees. Russell proposed a mechanism that combines fees and hashcash-style proof-of-work to try to prevent nodes from using the extra up-front payment information to guess the length of the route. Anthony Towns proposed a partial alternative focusing on managing payment amounts using a refund mechanism.

    Joost Jager suggested that up-front payments should only be required as a last resort because even small additional fees could make micropayments uneconomic. He suggested that it should be possible to address bandwidth-wasting network activity using rate limits based on node reputation and, further, that research into up-front payments should focus on first solving liquidity abuse—where an attacker ties up someone’s in-channel funds for period of time—as the solution to that problem may also prevent the abuse of routing node bandwidth.

    Ultimately, no conclusions were reached and discussion about the topic remains ongoing as of this writing.

  • Proposed BOLT for LN offers: Rusty Russell posted draft text for a new BOLT that would allow users to submit offers and receive invoices over the LN routing protocol. For example, Alice could subscribe to a service provided by Bob where each month she would submit an offer to pay Bob, Bob would reply with an invoice, Alice would pay the invoice, and Bob would provide the service.

    Early feedback on the proposal suggested that it might want to use an established language for machine-readable invoices, such as the Universal Business Language (UBL). However, there was a concern that implementing the full UBL specification would be an excessive burden on developers of LN software.

  • New topic index on Optech website: we announced the addition of a topics index to the Optech website that makes it easy for readers to find all the locations on the Optech website where we’ve mentioned a particular topic. The index has been released with an initial set of 40 topics and we hope to increase that to about 100 topics over the next year.

Notable code and documentation changes

Notable changes this week in Bitcoin Core, C-Lightning, Eclair, LND, libsecp256k1, Bitcoin Improvement Proposals (BIPs), and Lightning BOLTs.

  • Bitcoin Core #16110 adds support for building Bitcoin Core (including the GUI) for the Android Native Development Kit (NDK). In contrast to independent projects like Android Bitcoin Core (ABCore) that build their own Bitcoin Core binaries for Android NDK, adding support directly to the Bitcoin Core project may simplify testing. It could also allow future PRs to add the Android builds to the set of deterministically-generated executables that allow users to receive greater assurances that they are running the same well-reviewed code that exists in the code repository.

  • Bitcoin Core #16899 adds a dumptxoutset RPC that will write a copy of the current UTXO set to disk in a serialization format designed for future use with nodes bootstrapped using assumeutxo (see Newsletter #41). Additionally, a script is added to the project’s contributor tools that will rewind the block chain to a specified block height, dump the UTXO set at that point, and then start reprocessing blocks normally again. This can take several seconds per block, so running this script for a height thousands of blocks in the past can take a very long time.

  • Bitcoin Core #17258 updates the listsinceblock RPC to prevent listing any transactions that can’t be confirmed because another transaction spent at least one of the same inputs and was already included in the block chain prior to the blocks being evaluated by the RPC call.

  • C-Lightning #3246 attempts to fix the potential data leak described on the LN mailing list this week (see the news item).

  • LND #3442 makes it possible for a spender to manually construct packets for simple multipath payments—payments that are split into parts and which can be independently routed through different channels. This isn’t meant to be accessed by users but rather to be built upon by subsequent features that add other functions related to multipath payments. For more about multipath payments, see Newsletter #27.

  • BIPs #857 edits BIP157 to increase the maximum number of compact block filters that can be requested at once from 100 to 1,000. This reverts a PR from last year that lowered it from 1,000 to 100.

  • BIPs #849 edits BIP174 to allocate certain data type identifiers in Partially Signed Bitcoin Transactions (PSBTs) for use by non-standardized (proprietary) applications. Additionally, PSBTs are now given a version number to help identify backwards-incompatible changes to PSBTs, with older PSBTs that don’t contain an explicit version number having an implicit version number of 0. Both changes were previously discussed on the Bitcoin-Dev mailing list (see Newsletter #58).

  • BIPs #856 adds BIP179, a proposal that suggests renaming the current term “Bitcoin address” to “Bitcoin invoice address” or simpler variations such as “invoice address” or just “invoice”. This was previously discussed on the Bitcoin-Dev mailing list.

  • BIPs #803 adds BIP325 with a description of the signet protocol for creating testnets based on signed blocks instead of mined blocks, allowing the operators of the signet to control the rate of block production and the frequency and magnitude of block chain reorganizations (see Newsletter #37).

  • BIPs #851 adds BIP330 with a description of the transaction announcements reconciliation method intended to be used as part of the erlay protocol (see Newsletter #66). If this feature is adopted by node software, it will be the first step in significantly reducing the bandwidth overhead of relaying transaction announcements, which may consume over 40% of a typical node’s bandwidth at present.