This week’s newsletter includes the usual dashboard and action items, news about the importance of allowing secure and anonymous responsible disclosure of bugs, a potential new payment protocol that can improve privacy on Bitcoin without any consensus rule changes, shaving one byte off the size of every transaction signature, a new restriction on the P2P network protocol, and lowering the minimum transaction relay fee—plus a few notable commits from the Bitcoin Core, LND, and C-Lightning projects.

Action items

  • ● Check your responsible disclosure process: it’s especially important that researchers be able to report bugs securely (e.g. using PGP) and anonymously (e.g. using Tor). See the News section below for links to details about a previous responsible disclosure of a consensus failure bug in the Bitcoin Cash cryptocurrency that could’ve been used to steal from exchanges—even those that required multiple confirmations for deposit transactions—as well suggested best practices for making disclosures easy.

  • ● Check software using the P2P protocol getblocks or getheaders messages: if you use custom software that requests blocks using either of these messages, ensure they don’t make their requests with more than 101 locators. All popular open source software has already been tested, but if you have internal software that speaks the P2P protocol, you may need to test it. See the News section for details.

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.

  • ● Estimated BTC hash rate briefly touched 60 EH/s on August 10, and has a 7 day average of 48 EH/s.

  • The number of transactions in each block. This metric is vaguely periodic in that it has peaks at around 13:00 to 17:00 UTC each day. The graph below shows a 25-block moving average of the number of transactions. It was sourced from the Optech beta dashboard that we encourage people to try out and provide us feedback about.

Transactions per block, 25-block moving average, July 14, 2018 - August 13, 2018 Transactions per block, 25-block moving average, July 14, 2018 - August 13, 2018, source: Optech dashboard

News

  • ● How to help security researchers: Bitcoin Core developer and Digital Currency Initiative (DCI) member Cory Fields revealed that he was the anonymous source behind the disclosure of a potentially consensus-breaking bug in the Bitcoin Cash cryptocurrency. After a frustrating experience trying to report the bug, he requested cryptocurrency-related projects make it easier for security researchers to submit secure anonymous vulnerability reports to projects, and fellow DCI member Neha Narula followed this up with some recommendations particularly targeted at cryptocurrency maintainers but possibly also useful for organizations using cryptocurrencies.

    Optech encourages our member companies (and any others reading this newsletter) to consider how easy it would be for an anonymous researcher to report a critical bug to your staff. An easy way to test your process could be tasking one of your team members to install Tor and actually attempt to securely submit a report using no information about your operation other than what they can easily find on your website. If you provide bug bounties, you may also wish to make clear that you will provide the same levels of reward to anyone who initially reports a PGP-signed disclosure, subject to you later collecting any information from them you may need for legal compliance.

  • ● Pay-to-End-Point (P2EP) idea proposed: blog posts by Adam Ficsor (nopara73) of zkSNACKs and Matthew Haywood of Blockstream describe a new idea for improving privacy for Bitcoin users without making any changes to the consensus protocol. The basic idea is that spenders contact a server controlled by the receiver when attempting to make a payment (similar to the BIP70 payment protocol), provide a normal signed transaction as proof that they’re willing to pay, and then receive the information necessary to perform multiple CoinJoin-style transactions with the receiver. If one of the CoinJoin-style transactions is used, this can confuse block chain analysis companies into thinking an input added to the transaction by the receiver was an input that belonged to the spender, or (if P2EP is widely used) just making block chain analysis less reliable in general.

    If discussions continue positively and a specific proposal is agreed upon, several privacy focused wallets are considering adding support for P2EP spending and BTCPay Server is considering adding support for P2EP receiving.

  • ● Bitcoin Core wallet to begin only creating low-R signatures: the DER format used to encode Bitcoin signatures requires adding an entire extra byte to a signature just to indicate when the signature’s R value is on the top-half of the elliptical curve used for Bitcoin. The R value is randomly derived, so half of all signatures have this extra byte.

    Merged this week, Bitcoin Core PR #13666 generates multiple signatures for each transaction (if necessary) using an incremental nonce until a signature is found that has a low-R value that doesn’t require this extra byte. By doing so, Bitcoin Core transactions will save one byte per every two signatures (on average). If all wallets did this, it could save up to several thousand bytes (or up to a couple thousand vbytes) per typical full block, increasing block chain capacity by up to a few thousand transactions a day. The cost is that it will take Bitcoin Core twice as long to generate an average signature and that it reduces the entropy (randomness) of the generated signatures by 1 bit, neither of which is significant. It may also make transactions created by Bitcoin Core somewhat easier to identify if no other wallets adopt this change.

    Note that this change does not affect other software in any way (except for other wallets being able to use the extra block chain capacity). It’s purely a feature built into the Bitcoin Core wallet and not something that will be enforced by the protocol.

  • ● Lowering minimum relay fees in two steps: as mentioned in Newsletter #3, Bitcoin Core developers are considering lowering the minimum relay fee for transactions. Because this change affects wallets, relay nodes, and miners all at the same time—but because they don’t all update on the same schedule—evaluating and testing the change has turned out to be harder than one might expect for just changing a few variables.

    The currently-discussed plan is to lower the default fee for relay nodes and miners first, wait to see if it receives sufficient adoption for what are currently sub-default fee transactions to get mined, and then lower the minimum fee the wallet uses in a later release. We will post future updates in this newsletter about how your organization can help use and encourage the adoption of lower minimum relay fees.

  • ● P2P protocol change to restrict locators: the getblocks and getheaders messages allow a node to request information about blocks it hasn’t seen by sending a list of blocks it has seen to another node. The receiving node uses the list to find the last block the two nodes have in common and sends information about subsequent blocks.

    According to an email posted to the bitcoin-dev mailing list by Gregory Maxwell, Bitcoin Talk user Coinr8d was concerned that the requesting node could send up to 32 MiB of block hashes to the receiving node, causing the receiving node to spend a lot of I/O looking for blocks it didn’t have. However, Maxwell’s tests didn’t find this to be a significant problem. Still, Maxwell proposed limiting the number of allowed locators in these messages. Libbitcoin developer Eric Voskuil said his software was already enforcing a limit and that he was aware of a program (BitcoinJ) that slightly exceeded the limit proposed by Maxwell.

    The subsequently merged PR Bitcoin Core #13907 by Maxwell set the limit to equal to the maximum requested by BitcoinJ. If you are aware of software requesting more than 101 elements using the getblocks or getheaders P2P messages, please post to the bitcoin-dev mailing list or contact someone from Optech.

  • ● Schnorr BIP discussion: a discussion between experts about the algorithm for generating Schnorr signatures last week on the bitcoin-dev mailing list was resolved without any need for changes to the proposed BIP. This may increase confidence that the proposed BIP’s parameters were wisely chosen.

Notable commits

Notable commits this week in Bitcoin Core, LND, and C-lightning. Does not include Bitcoin Core #13907 or #13666 described above. Note: the bulk of the changes to all three projects this week seemed to be improvements to their automated testing code; we aren’t describing those in this newsletter, but we’re sure users and developers highly appreciate that work.

  • ● Bitcoin Core #13925: increases the maximum number of file descriptors Bitcoin Core’s internal database can use, which can allow more file descriptors to be used for network connections. If you’ve modified Bitcoin Core to accept more than 117 incoming connections, you may see an additional increase in the number of connections after upgrading past this merge. (Note: we don’t recommend increasing the default unless you have a special need.)

  • ● LND #1644: fees entered by the user in satoshis per vbyte are now automatically converted to the use of satoshis per kiloweight (1,000 vbytes) as defined in the protocol.

  • C-Lightning: a paying node will no longer send an HTLC commitment (payment) to another node unless it’s heard from that node within the past 30 seconds. If necessary, it’ll ping the recipient node before sending the commitment. This helps the paying node abort a payment earlier in the process if that payment was destined to fail anyway because of a network interruption.

  • C-Lightning: various moderate improvements to the code for reconnecting to disconnected peers, including exponential backoff and reconnection time fuzzing.