This week’s newsletter requests testing on RCs for both LND and C-Lightning, describes using ECDH for uncoordinated LN payments, summarizes a proposal to add information about delays to LN routing replies, and includes summaries of some interesting talks from the recent ‘Breaking Bitcoin’ conference in Amsterdam. Also included are our regular sections on bech32 sending support and notable changes in popular Bitcoin infrastructure projects.

Action items

● Help test C-Lightning and LND RCs: both C-Lightning and LND are in the process of testing Release Candidates (RC) for their next releases. Experienced users of either program are encouraged to help test the RCs so that any remaining bugs can be identified and fixed before final release.

News

● Using ECDH for uncoordinated LN payments: Stephan Snigirev sent two ideas to the LN development mailing list in a single post. The first idea involves reusing an existing part of the protocol to enable spontaneous payments, a payment that Alice sends to Bob without her needing to request an invoice from Bob. As described in Newsletter #30, these are currently proposed for LND by having Alice select a pre-image, encrypt it to Bob’s key, and put it into an otherwise-unused part of an LN routing packet when Alice pays the hash of the pre-image. When Bob receives the encrypted pre-image, he decrypts it and releases it to claim the payment. Snigirev’s idea eliminates the need to route the encrypted pre-image. He notes that the routing of a payment from Alice to Bob already requires them to have a common shared secret (derived using Elliptic Curve Diffie-Hellman (ECDH). This secret can be hashed once to produce a unique pre-image known to both of them, and that pre-image can be hashed again to be the payment hash. To use this system, whenever Bob receives a payment to a hash that he didn’t create an invoice for, he simply generates the double hash of that session’s shared secret and sees if it matches. If so, he generates the single hash and claims the payment. C-Lightning developer Christian Decker has written a proof of concept patch and plugin for C-Lightning that implements this. Snigirev’s second idea allows an offline device, such as a vending machine, to generate a unique LN invoice that can be paid by an online user to another online node that knows how to produce the pre-image and claim the payment on behalf of the offline device. This results in the payer receiving the pre-image as a proof of payment. The payer can then show this proof to the offline device to receive the promised good or service, such as food from a vending machine. Again, this uses a shared secret derived using ECDH—but in this case the secret is shared between the offline device that generates the invoice and the online node that ultimately receives the payment. See Snigirev’s post for the protocol details.

● Authenticating messages about LN delays: when a payment fails in LN, it’s often possible for the node attempting the payment to receive an authenticated message from one of the two nodes involved in the payment failure. This allows the paying node to mark the channel between those two nodes as unreliable and choose other channels for future payments. But LND developer Joost Jager notes on the LN development mailing list that “non-ideal payment attempts [can also be] successful payments for which it took a long time to receive the [success] message.” He proposes that each node relaying a message back to the paying node add two timestamps to the message, one timestamp when the node offered to route a payment and one timestamp when it learned either that the payment had failed or that it succeeded. This would allow the paying node to determine where delays occurred during the routing of the payment and avoid those channels in the future. To prevent some nodes along the path from lying about other nodes, he propose the error messages and timestamps be protected by a message authentication code. This could also prevent intermediate nodes from corrupting encrypted error messages from endpoint nodes. Jager’s proposal also discusses how this type of system could be implemented in the current routing protocol and how it could address concerns related to routing privacy. The proposal has received a moderate amount of positive discussion on the mailing list so far.

Breaking Bitcoin

Breaking Bitcoin was a Bitcoin technology conference that took place in Amsterdam last weekend. It was well attended by both Bitcoin protocol developers and applications engineers. Videos of the Saturday and Sunday are available, as are several transcripts by Bitcoin developer Bryan Bishop (kanzure).

The following talks may be of particular interest to readers of the Bitcoin Optech newsletter:

Bech32 sending support

Week 14 of 24 in a series about allowing the people you pay to access all of segwit’s benefits.

There’s a class of multisig users who not only save on fees by using bech32 addresses but who also receive improved security against a potential type of attack called a hash collision. This class of users includes many exchanges and other business users.

To provide some background, all common single-sig addresses on Bitcoin today are the result of a pubkey being turned into a 160-bit RIPEMD160 hash digest. It’s theoretically possible for an attacker to generate a second pubkey that they control, hash it, and produce the same address. However, if we assume that the hash function produces perfectly unpredictable output, then the chance of this happening with a 160-bit hash function like RIPEMD160 is 1-in-2160 for each pubkey the attacker tries.

For comparison, Bitcoin miners perform 280 hashing operations roughly every 5 hours as of this writing. The SHA256d hashing operation miners perform isn’t the same as used in this RIPEMD160 collision attack, so their equipment can’t be repurposed for that use, but we can use this as a reference rate for the number of brute force operations a real-world system can perform today (at great expense). At that rate, an attack that performed the 2159 operations necessary to have a 50% chance of succeess would take about 25 million times the estimated age of the universe so far.

However, when multisig addresses are being used, the attacker may be one of the parties involved in generation of the address and so may be able to manipulate what address is finally chosen. For example, Bob sends his pubkey to Mallory expecting that Mallory will send her pubkey back. Then he expects they’ll each put the pubkeys into a multisig script template, hash it into an address, and someone will deposit money into that address.

Mallory instead takes the script template and Bob’s pubkey, inserts one of her pubkeys without telling Bob about it, and hashes it into an address. This allows her to see the address Bob will accept before Mallory has committed to using that pubkey. Mallory can then compare this address to a database of addresses generated from scripts that pay only her. If there’s a match (collision) between two of the addresses, she sends the pubkey back to Bob, waits for money to be deposited into the address, and then uses the script from her database to steal the money. If there’s not a match, Mallory can try again with a different pubkey over and over until she succeeds (if we assume she has unlimited time and resources).

Although this seems like the same brute force attack described earlier with a 1-in-2160 chance of success per attempt, we have to consider the size of Mallory’s database. If we imagine the database has 100 addresses, then each different pubkey she tries has a 100-in-2160 chance of success because it succeeds if it matches any one of the addresses in Mallory’s database.

This type of attack is called a collision attack. There are several algorithms with different CPU/memory tradeoffs for collision attacks, but the general rule security researchers follow is that a collision attack against a perfect hash function reduces its security to the square root of its number of combinations, i.e. it halves its size in bits. That means we can roughly assume that RIPEMD160’s security is reduced to 80 bits—which is the same number of operations we mentioned Bitcoin miners perform every 5 hours today using currently-existing technology. Again Bitcoin mining equipment can’t be used for this attack, and for an attacker to design and build enough custom equipment to find a collision in five hours might cost them billions of dollars—but it’s a theoretically possible attack that should concern those storing large values in P2SH, especially as custom hardware gets faster and cheaper. It’s also possible that there are variations on the collision attack that are easier and cheaper to execute because of weaknesses in the RIPEMD160 function.

It is possible to design multisig setup protocols so that they don’t have this problem and so that their collision resistance remains at 160 bits. However, the developers of segwit believed it was better to use a slightly longer hash function for segwit’s P2SH analog—P2WSH—so that users didn’t need to worry about these cryptographic particulars. For that reason segwit P2WSH uses the same SHA256d function used elsewhere in Bitcoin that provides 256-bit security for single-party cases and 128-bit worst-case security in multi-party use cases. To to continue our rough comparison, if we consider 80 bits to be equivalent to five hours of Bitcoin mining, 128 bits is equivalent to 160 billion years of mining.

Before we conclude this section, we do want to ensure a few things are clear:

We think it’s unlikely that anyone today has the ability to execute the attack described (but we can’t rule it out as a risk). The attack can only be used at the time addresses are being created (although the actual theft could occur a long time afterwards). The attack only applies to multi-party multisig addresses. If you’re a single party using P2SH multisig with only your own trusted devices or you’re using P2SH-P2WPKH (single-sig addresses), there’s no risk to you from this attack. The attack applies to P2SH-wrapped segwit P2WSH addresses as well as regular P2SH addresses. To eliminate the risk, you have to use native segwit (bech32) addresses or a secure key exchange protocol.

To summarize, users of multi-party multisig who want the utmost in security should be migrating to bech32 P2WSH addresses to take advantage of their extra collision resistance. As users make that migration, it’ll become even more important for services to ensure they implement bech32 sending support so that they can send payments to those security-conscious users.

Notable code and documentation changes

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