#43 - New release, Climate & Bitcoin, Peeling the onion and much more!

LN Markets

Feb 17, 2022

⚔️ LNM Fam

✨ We have pushed our latest release!

LN Markets @LNMarkets

🚨 New lnmarkets.com release! ⚔️ Connect more easily 🤑 Withdraw more seamlessly 😎 Enjoy our fresh new look

Receiving payments on Lightning can be stressful, when you’re not completely sure whether the payment will succeed or fail. That’s why we have polished the withdrawal experience on LN Markets so that you know exactly what’s happening behind the curtains (scanning, searching for routes, sending payment). You can also connect to LN Markets more easily.

🏆 Parabolic Pancake receives a Degen Award of Excellence for his cold blood and diamond hands:

🏆 And meme award goes to @AndrejCibik 😅

**“CIA leaked this picture of Kim funding his nuclear programme with LNM longs”**

Stay tuned folks, we have other cool stuff coming very soon! (yes, this the pre-announcement of an announcement).

🌍 Climate & Bitcoin

The “Bitcoin is burning the planet” line is not new. However, it is probably going to be pushed harder and harder by Bitcoin critics, for various potential reasons.

A sarcastic mind could think that “Bitcoin is burning the planet” is the new “Bitcoin is funding terrorism”, since the latter is no longer valid (illicit share of all cryptocurrency transactions volume is 0.15% in 2021 according to Chainalysis).

Anyway, it’s clearly a very powerful argument: if you are inclined to think that Bitcoin is useless, then any Joule spent to secure the network is wasted (let alone 0.28% of total energy world consumption). The Financial Stability Board has just published a report highlighting this narrative:

“PoW crypto-assets could thus impair financial sector and create risks for the financial system”

Therefore, education and factual information about Bitcoin mining is more important than ever. The Cambridge Center for Alternative Finance has paved the way gathering useful data about Bitcoin mining worldwide. Arcane Research is carrying the torch with a series of article covering the mining industry on the ground, in various countries with a focus on smaller countries that haven’t been sufficiently covered so far, starting with Georgia.

👉 Get full access to Arcane Research’s post here, and reach out to @jmellerud if you would like to discuss Bitcoin mining with him directly.

🤔 Peeling the Onion - Part 2

This article is the second concerning Onion Routing. Therefore, it is recommended to read the first article before this one.

In a previous article, I went into some details as to how Onion Routing allows payments to be processed across the Lightning Network in a quite privacy preserving manner. More precisely, we saw how the identities of the emitter and the receiver of a payment are hidden via the use of successive layers of encryption in the messages that nodes exchange about a payment. But there are still some blind spots we’ll want to shed some light on. Namely, we don’t know what the messages are exactly and how they refer to HTLCs, nor do we know which keys are used for encryption. I find the latter question particularly interesting: we know the sender can’t use their public key because it would completely undermine the privacy enabled by Onion Routing, but at the same time they need to coordinate with the intermediary nodes and give them some kind of public key. How does one do that? To find out, let’s peel this mysterious onion!

What’s inside the Onion Packets?

The term “Onion Packet” refers to the message that each node in the route sends to the next one, starting from the sender, up to the final recipient of the payment. In this article, we will once again use our 5-nodes example where Alice pays Eve 20,000 sats, and where the payment passes through Bob’s, Carol’s and Daniel’s nodes to finally reach Eve.

The Onion Packet itself is comprised of several parts, and can be brought down to this structure:

a version byte, currently set to 0, which will allow nodes to indicate which version of the protocol they use, should there be new ways to encode and transfer data in Onion Packets in the future,
a session key, which we will cover in more details in the section devoted to the cryptography of Onion Routing. Let’s just say this is this session key that allows cryptographic coordination between Alice and each hop,
the Onion Payload, which contains the useful data for each hop, as well as the encrypted data for the next hops,
a checksum, which allows each hop to check the integrity of the Onion Payload (eg. that the data has not been corrupted or tampered with).

|Version|Session Key|Onion Payload|Checksum|

This section concerns itself with the Onion Payload, what data it contains and how this relates to HTLCs.

Onion Payload for Intermediary Nodes

What does a hop in the route needs to know in order to successfully forward the payment? First, the identity of the node it is supposed to forward the packet to. Second, the amount it must send to this next hop. This seems to be the bare minimum. But there is one additional field, called outgoing_cltv_value, which has to do with the sequential expiration of HTLCs (or PTLCs) along the route. Therefore, the structure of the Onion Payload for an intermediary node is:

short_channel_id: the channel along which to forward the payment
amt_to_forward: the amount to forward in this channel
outgoing_cltv_value: the block height at which the conditional payment should expire

Amount to Forward

The amt_to_forward field is pretty straightforward. The only thing worth mentioning at this point is that it is expressed in millisatoshis (the native currency unit of the Lightning Network). Let’s focus on the two other fields.

Short Channel ID

The short_channel_id is a unique identifier for each channel. Per BOLT 7, it is defined as the concatenation of:

the block height in which the funding transaction was included,
the funding transaction index within the block,
the index of the output of the funding transaction that actually funds the channel.

And structured like:

block_heightxtx_indexxoutput_index

In other words, the short_channel_id uniquely identifies the Bitcoin output corresponding to the channel, which is equivalent to uniquely identifying the channel. For example, a channel which funding transaction was confirmed in block 723,881, while the transaction was the 120th in the block (including the coinbase transaction, which has index 0) and the output actually funding the channel was the second one (eg its index is equal to 1) would have a short_channel_id of 723881x119x1.

Outgoing CLTV Value

The outgoing_cltv_value also needs some explanations. I think it would be worth a whole article to fully explain the role time plays in Lightning, but for now we’ll focus on what we need in order to understand Onion Routing.

CLTV stands for “Check Lock Time Verify” and it’s a special kind of Bitcoin OP code providing timelock functionalities. In other words, a Bitcoin transaction output with CLTV cannot be spent until some point in the future, referenced either as a UNIX timestamp or as a block height. In Lightning, conditional payments such as HTLCs or PTLCs have a timelock set using CLTV. If the channel is closed while a payment is still in-flight and the conditional payment commitment transaction gets published on-chain, this will prevent the funds from being spent for some time, allowing their rightful owner to claim them on-chain.

As we saw in the PTLCs article, conditional payments are either fulfilled or expire. Should the latter occur, it is necessary that the conditional payments along a route expire in a precise sequential order, starting from the recipient and moving up the route back to the sender. Else, intermediary nodes could find themselves in a situation where their own conditional payment has been claimed by the next node, but they are unable to claim the conditional payment from the previous node because it has already expired.

To ensure this ordered chain of expirations, when Alice builds the Onion Payload, she ensures that each routing node sets the block height at which its HTLC will expire at a bigger value than the one after them on the route. A simple way to do so would be to fetch the current block height, then tell the last routing node to set the expiration height of its HTLC to current_block_height + 10 (for example), tell the penultimate routing node to set theirs at current_block_height + 20, and so on. But it is the intermediary routing nodes' funds that are at play here, not Alice’s. Therefore, it is appropriate to allow intermediary nodes to set this delay themselves.

This is achieved by having nodes advertise a per channel parameter called Time Lock Delta. If you head over any Lightning explorer (such as 1ml.com or amboss.space for example), you’ll see that each public channel has a Time Lock Delta value, along with base fee, feerate and other parameters. This value can be set by the node owner, although it is often set to the default value of 40 blocks. When she constructs the route, Alice looks for this value for each node, just like she looks for the node’s fees. For example, let’s consider that:

Daniel has a 40 blocks Time Lock Delta on his channel with Eve.
Carol has a 20 blocks Time Lock Delta on her channel with Daniel,
Bob has a 50 blocks Time Lock Delta on his channel with Carol,

Let’s say that Alice tells Daniel to put the CLTV timelock on his conditional payment to Eve at block height H = 723,900. Hence:

because Daniel has a delta of 40 blocks, he expects his incoming conditional payment from Carol to expire at block 723,940 (H + 40),
because Carol has a delta of 20 blocks, she expects her incoming conditional payment from Bob to expire at block 723,960 (H + 40 + 20),
because Bob has a delay of 50 blocks, he expects his incoming conditional payment from Alice to expire at block 724,010 (H + 40 + 20 + 50).

This way, conditional payments expire in the desired order, and node operators can manage their risk themselves by adjusting their Time Lock Delta value at will (just like they’re able to do with their fees).

Onion Payload for the Final Recipient

The Onion Payload for the recipient of the payment (Eve) is a bit different from the one for the intermediary nodes, because she doesn’t need to forward the payment to anyone (and she must at the same time be able to link the payment she receives to the invoice she generated earlier). Eve’s Onion Payload is therefore comprised of 3 fields:

amt_to_forward: the amount of the payment. Despite the name, Eve knows she does not need to forward it
outgoing_cltv_value: at what date will Daniel conditional payment to Eve expire
payment_secret: a secret Eve sent to Alice in the invoice. Not to be confused with the preimage s or its hash r. Only Alice and Eve know this secret.

Notice that the main difference with respect to the payload of intermediary nodes is the absence of a short_channel_id field, as Eve has nowhere to send the payment further. It is “replaced” with the payment_secret field, which helps Eve determine to which invoice this payment corresponds (notably if she has sent several invoices for the same amount around the same time). It also serves the purpose of protecting Eve from probing by intermediary nodes.

Wrap Up

Let’s sum it up a bit. First, we’ll want to put the information available to Alice when she builds the Onion Packet on our diagram (where the base fee is in sats, and the Time Lock Delta in blocks):

Alice then builds the Onion Payload, which acts as instructions for the intermediary nodes:

What about the preimage?

An attentive reader who is already familiar with the inner workings of the Lightning Network may wonder how the payment preimage’s hash r is passed between the nodes in the route, as it doesn’t seem to be included in the Onion Payload.

When Alice sends the Onion Packet to Bob, she actually sends in a message called update_add_htlc. In this message, Alice tells Bob that she’s sending him an HTLC, for a given amount, with a given expiry time, and for a given hash value r. The message actually looks like this:

channel_id: the id of the channel on which Alice sends the HTLC
id: the id of the HTLC, in case there are many (starts at 0)
amount_msat: the amount in the HTLC in millisatoshis
payment_hash: that's the hash r of our preimage. Yaï!
cltv_expiry: block at which the HTLC expires.
onion_routing_packet: that's our Onion Packet.

Bob, who wants to claim this HTLC, then takes a look at the Onion Packet to learn where he must in turn send a HTLC. He can send construct his own update_add_htlc message and send it to the next node in the route, because he learnt all the useful information in the payload. Here is the the message Bob builds, using short_channel_id, amt_to_forward and outgoing_cltv_value from his Onion Payload.

channel_id: short_channel_id
id: set by Bob depending on the presence of other HTLCs in the channel
amount_msat: amt_to_forward
payment_hash: the same as the one Bob received in the message from Alice
cltv_expiry: the cltv_expiry value in Alice message minus outgoing_cltv_value
onion_routing_packet: the new Onion Packet

And so does each node along the route. Now, let’s take a look at how we do all of this, but with privacy!

👉 In our next issue, the last episode of the Onion Routing series - Which Keys does Onion Routing use?

Full Post

By Fanis Michalakis, Bitcoiner & Techno Padawan @LNMarkets