In this appendix we analyze the transmission overhead of three smart contract systems for paying incentives to mobile mesh nodes for successful message delivery. This analysis focuses on the communication overhead to update channel states and close channels. We assume the channel setup overhead is roughly similar for all three. We also assume the same simplifying optimizations have been made to all three systems to minimize communication overhead. For each system we analyze the total communication overhead needed to update the payment channels of an example three hop message delivery. We also examine the amount of data that must be communicated to the internet to close all three channels.
The three smart contract systems are based on the following protocols:
- Poon-Dryja state revocation (with ECDSA signatures)
- eltoo state revocation (with Schnorr MuSig multi-signatures)
- eltoo state revocation (with BLS non-interactive signature aggregation)
The Poon-Dryja state revocation protocol requires multiple communication phases for both the sender and receiver of a payment to exchange commitments to the new state and revoke the previous state. The eltoo state revocation protocol uses transaction replacement and only requires the payment sender to commit to a new channel state. In the eltoo/Schnorr variant all nodes involved in the message delivery only sign two transactions to update their channels along the route. In the eltoo/BLS variant each node signs a transaction to update their channel with the next node in the route.
The MuSig[18] signing scheme requires three rounds of communication for a set of nodes to collaboratively generate a multi-signature for a transaction. For each multi-signature, a node must exchange with each other signing node a 32 byte nonce commitment, a 32 byte nonce and a 32 byte partial signature. A valid multi-signature is composed of a 32 byte combined nonce and 32 byte combined partial signature.
This means that two nodes transmit 96 bytes to each other, and then either node can transmit a single 64 bytes of signature information to the blockchain. In total they transmit 256 bytes for a single signing session.
Without multi-signatures, each node needs to transmit their complete 64 byte signature to the other node, and two 64 byte signatures to the blockchain for a total of 256 bytes.
The total is the same, but the ratio of local transmission versus final signature size is different.
Assume four nodes create setup transactions for three channels (A <> B <> C <> D) with their neighbors. Each channel setup transaction requires two signatures. Also assume transactions must be relayed over 3 hops to be settled via an internet gateway node.
If we create one multi-signature with two signers per channel, then we must transmit 2 * 96 bytes (nonce commitment, nonce, partial signature) per channel to create one 64 byte multi-signature. The total transmitted to sign setup transactions for each of the three channels is 3 * 2 * 96 = 576 bytes. To transmit the multi-signature for a single channel three hops to a gateway requires transmitting 64 * 3 hops = 192 bytes, or an additional 576 bytes for three channels. The total transmitted is thus 576 + 576 = 1152 bytes.
Without multi-signatures, each pair of nodes would exchange a 64 byte signature with their channel partner, or 64 * 2 * 3 channels = 384 bytes of information. Each of the three channels will also need to send 64 * 2 = 128 bytes of signature information to the blockchain over three hops for a total of 128 * 3 * 3 hops = 1152 bytes of transmission. The total data transmitted would be 384 + 1152 = 1536 bytes.
Each BLS signature is 48 bytes and can be non-interactively aggregated with other {message, signature} pairs. Signing three channels would require transmitting 48 * 2 * 3 = 288 bytes of signature data to create an aggregate signature of 48 bytes for each channel. The total data transmitted would be 288 + 48 * 3 * 3 hops = 720 bytes.
There are also additional optimizations that can be made that would reduce this number further such as only transmitting a single signature to sign all three setup transactions.
This analysis only focuses on signature data, which is the largest but not the only information that must be transmitted between nodes and between nodes and the internet via gateways.
While BLS signatures are by far the most space saving option, we can achieve a substantial improvement over current ECDSA multisig signing using MuSig and Schnorr signatures. Not only would this technique reduce overall signature transmission overhead by 50%, but it would reduce the amount of signature data that must be transmitted via relays to a gateway by 50%.
Importantly, Schnorr based MuSig multi-signatures are likely to be supported by Bitcoin in the foreseeable future, whereas BLS signatures are not currently supported by any widely used distributed ledgers.
We assume all three systems use the following simplifications and optimizations to reduce the bandwidth required to update their channel state.
- Each node has a short 2-byte node ID.
- The extended public key for each node ID is pre-shared.
- New public keys are deterministically derived from the extended public key for each transaction.
- A route of relays nodes from the sender to a destination node are computed by the sender and communicated in clear text (no onion routing).
- Transactions, including script details and defaults, can be inferred from a 1 byte type ID.
- The destination node signs a hash of the message to confirm receipt and unlock channel updates between nodes.
For this analysis, the following data structures are used to compute the overhead of simplified versions of the protocol messages described in “Bolt #2 : Peer Protocol For Channel Management.” using the current Lightning Network’s Poon-Dryja update scheme, or a proposed Lot49 scheme based on the eltoo update scheme.
The channel update phase (described in the Normal Operation section of Bolt #2) requires the update proposer to send the update_add_htlc message, and then both the sender and receiver to commit to a new channel state and revoke the previous channel state.
| Original Size (bytes) | Simplified Size (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 128 (update_add_htlc) |
| channel_id | 32 | - | inferred from destination node |
| id | 8 | 2 | ID to refer to this new HTLC |
| amount_msat | 8 | 2 | smaller max payment range |
| payment_hash | 32 | - | inferred from message data |
| cltv_expiry | 4 | - | use standard value |
| onion_routing_packet | 1366 | 12 | up to 6 clear text hops, one 2 byte node ID per hop |
| Total | 17 |
| LN Size (bytes) | Simplified Size (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 132 (commitment_signed) |
| channel_id | 32 | - | inferred from destination node |
| signature | 64 | 64 | sign remote commitment |
| num_htlcs | 2 | - | assume single htlc signature |
| htlc_signature | num_htlcs*64 | 64 | commit to previous HTLC payments |
| Total | 129 |
| LN Size (bytes) | Simplified Size (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 132 (commitment_signed) |
| channel_id | 32 | - | inferred from destination node |
| per_commitment_secret | 32 | 32 | revoke last commitment |
| next_per_commitment_point | 33 | 33 | new commitment point |
| Total | 66 |
To update three channels requires transmitting the update_add_htlc message once per channel and the commit_signed and revoke_and_ack messages six times.
Unfortunately a Schnorr multi-signatures can not be used to reduce the overall amount of data transmitted between nodes to update a channel. Signatures are only included in the commitment_signed messages and nodes only update their own signature; the signatures from both sender and receiver are not transmitted together during a channel update. Both parties signatures are only combined when a channel is closed cooperatively by signing a partially signed closing transaction or uncooperatively by signing an unrevoked HTLC transaction
| Message Type | Simplified Size (bytes) | Total data transmitted by both sender and receiver (bytes) |
|---|---|---|
|
Update three channels ECDSA or Schnorr |
||
| update_add_htlc* | 17 | 51 |
| commitment_signed | 129 | 774 |
| revoke_and_ack | 66 | 396 |
| Total: | 1221 |
The setup phase for a new payment channel (described in the Channel Establishment section of Bolt #2) requires sending the following messages: the funding node sends ‘open_channel’, the receiving node sends back ‘accept_channel’, the funding node sends ‘funding_created’, the receiving node sends back ‘funding_signed’, the funding node sends ‘funding_locked’ and finally the receiving node replies with its own ‘funding_locked’ message.
For the simplified versions of these messages it is assumed that we can use defaults for many of the parameters exchanged to open a channel, and that information about the funding pubkey is transmitted, but the ‘basepoint’ information can be inferred. For example, using BIP-32 extended public keys, and agree (either in the protocol spec or in the protocol messages) on which BIP-32 child key derivation paths (child paths) to use.
| LN Size (bytes) | Simplified Size (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 32 (open_channel) |
| chain_hash | 32 | Use defaults | |
| temporary_channel_id | 32 | 2 | inferred from destination node |
| funding_satoshis | 8 | - | use defaults |
| push_msat | 8 | - | use defaults |
| dust_limit_satoshis | 8 | - | use defaults |
| max_htlc_value_in_flight_msat | 8 | - | use defaults |
| channel_reserve_satoshis | 8 | - | use defaults |
| htlc_minimum_msat | 8 | - | use defaults |
| feerate_per_kw | 4 | - | use defaults |
| to_self_delay | 2 | - | use defaults |
| max_accepted_htlcs | 2 | - | use defaults |
| funding_pubkey | 33 | 33 | DER Encoded secp256k1, half of 2:2 multisig |
| revocation_basepoint | 33 | - | inferred ? |
| payment_basepoint | 33 | - | inferred ? |
| delayed_payment_basepoint | 33 | - | inferred ? |
| htlc_basepoint | 33 | - | inferred ? |
| first_per_commitment_point | 33 | - | inferred ? |
| channel_flags | 1 | - | not used |
| shutdown_len | 2 | - | not used |
| shutdown_scriptpubkey | shutdown_len | - | not used |
| Total | 36 |
| LN Size (bytes) | Simplified Size (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 33 (accept_channel) |
| temporary_channel_id | 32 | 2 | inferred from destination node |
| dust_limit_satoshis | 8 | - | use defaults |
| max_htlc_value_in_flight_msat | 8 | - | use defaults |
| channel_reserve_satoshis | 8 | - | use defaults |
| htlc_minimum_msat | 8 | - | use defaults |
| minimum_depth | 4 | - | use defaults |
| to_self_delay | 2 | - | use defaults |
| max_accepted_htlcs | 2 | - | use defaults |
| funding_pubkey | 33 | 33 | DER Encoded secp256k1, half of 2:2 multisig |
| revocation_basepoint | 33 | inferred ? | |
| payment_basepoint | 33 | inferred ? | |
| delayed_payment_basepoint | 33 | inferred ? | |
| htlc_basepoint | 33 | inferred ? | |
| first_per_commitment_point | 33 | inferred ? | |
| shutdown_len | 2 | - | not used |
| shutdown_scriptpubkey | shutdown_len | - | not used |
| Total | 36 |
| LN Size (bytes) | Simplified Size (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 34 (funding_created) |
| temporary_channel_id | 32 | 2 | inferred from destination node |
| funding_txid | 32 | - | inferred |
| funding_output_index | 2 | - | inferred |
| signature | 64 | 64 | 96 for MuSig interactive signing |
| Total | 67 |
| LN Size (bytes) | Simplified Size (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 35 (funding_signed) |
| channel_id | 32 | 2 | inferred from destination node |
| signature | 64 | 64 | 96 for MuSig interactive signing |
| Total | 67 |
| LN Size (bytes) | Simplified Size (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 36 (funding_locked) |
| channel_id | 32 | 2 | inferred from destination node |
| next_per_commitment_point | 33 | - | inferred ? |
| Total | 3 |
To setup three channels requires transmitting the above messages once per channel and the ‘funding_locked’ message twice per channel. Using Schnorr multi-signatures requires each signer send an addition 32 bytes as part of the interactive signing protocol.
| Message Type | Simplified Size (bytes) | Total data transmitted by both sender and receiver (bytes) | |
|---|---|---|---|
|
Setup three channels ECDSA or Schnorr |
Setup three channels with Schnorr Multi-Signature | ||
| open_channel | 36 | 108 | 108 |
| accept_channel | 36 | 108 | 108 |
| funding_created | 67 | 201 | 297 |
| funding_signed | 67 | 201 | 297 |
| funding_locked*2 | 6 | 18 | 18 |
| Total: | 636 | 828 |
| LN Size (bytes) | Simplified Size (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 39 (closing_signed) |
| channel_id | 32 | - | inferred from destination node |
| fee_satoshis | 8 | 2 | smaller max amount |
| signature | 64 | 64 | 96 for MuSig interactive signing |
| Total | 67 |
Both parties exchange close messages to settle immediately with the current channel balances. Using Schnorr multi-signatures requires each signer send an addition 32 bytes as part of the interactive signing protocol.
| Message Type | Size Schnorr (bytes) | Total data transmitted by both sender and receiver (bytes) | |
|---|---|---|---|
|
Close three channels ECDSA or Schnorr |
Close three channels with Schnorr Multi-Signature | ||
| closing_signed | 67 | 402 | 594 |
| Total: | 402 | 594 |
The Lot49 proposal uses the eltoo scheme to update channel states. There is no revocation phase in this update protocol which reduces the amount of data transmitted. It also means that nodes that are part of the same transaction chain can cooperatively sign a single combined transaction to update their respective channel states. In our example the transaction chain includes the transactions that update the three channel states between the message sender and destination node. If an out-of-date update is committed by one of the nodes, it will not result in a penalty and can be replaced by any of the nodes by committing a more recent update within the timelock period.
| Size Schnorr (bytes) | Size BLS (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 2 (Negotiate_1) |
| channel_id | - | - | inferred from destination node |
| id | - | - | ID of the sender is included in the normal mesh routing header |
| prepaid_tokens (amount_msat) | 1 | 1 | sat amount committed by message sender |
| payment_hash | - | - | inferred from message data |
| cltv_expiry | - | - | use standard value |
| relay_path (onion_routing_packet) | 12 | 12 | up to 6 clear text hops, one 2 byte node ID per hop; also used to reconstruct the complete transaction chain |
| agg_signature | 64 | 48 | commit to new transaction chain |
| Total | 78 | 62 |
All of the nodes along the relay path collaboratively sign a single transaction (with Schnorr) or set of transactions (BLS). This involves each node modifying the update message to aggregate their signature with the agg_signature field data they received before retransmitting it to the next relay node. To update all three channels requires transmitting the update message three times.
A Schnorr multisignature or BLS aggregate signature is used to reduce the total amount of data transmitted between nodes. If using Schnorr signatures, each node aggregates their signature to commit to spend from a single setup transaction that must be signed by all of the involved relay nodes. If using BLS signatures, each node aggregates their signature to commit to spend from a setup transaction established with the next relay node along the route.
For each update, nodes do not need to revoke the previous channel state. This reduces the amount of signature information that must be transmitted. If at any point a relay becomes unresponsive, a single transaction signed with the last complete multisignature (Schnorr) or aggregate signature (BLS) can be committed to settle all of the channels involved.
| Message Type | Size Schnorr (bytes) | Size BLS (bytes) | Total data transmitted by both sender and receiver (bytes) | |
|---|---|---|---|---|
| Update three channels | ||||
| Schnorr | BLS | |||
| update | 78 | 62 | 234 | 189 |
| Total: | 234 | 189 |
The setup phase for a new payment channel starts with a nearby node proposing a transaction to refund the setup transaction. The receiving node that is funding the channel can hold that transaction until they need it because they have the 2nd signature.
| Size Schnorr (bytes) | Size BLS (bytes) | Note | |
|---|---|---|---|
| type | 1 | 1 | 1 (Setup_2) or 7 (Close_1) |
| channel_id | - | - | inferred from destination node |
| id | - | - | ID of the sender is included in the normal mesh routing header |
| prepaid_tokens (amount_msat) | 1 | 1 | msat committed by message sender |
| payment_hash | - | - | inferred from message data |
| cltv_expiry | - | - | use standard value |
| relay_path (onion_routing_packet) | 12 | 12 | up to 6 clear text hops, one 2 byte node ID per hop; also used to reconstruct the complete transaction chain |
| agg_signature | 64 | 48 | commit to new transaction chain; 96 bytes for Schnorr if MuSig signing used |
| Total | 79 | 62 |
| Message Type | Size Schnorr (bytes) | Size BLS (bytes) | Total data transmitted by both sender and receiver (bytes) | |||
|---|---|---|---|---|---|---|
| Setup / Close three channels | Data transmitted to a gateway | |||||
| Schnorr | BLS | Schnorr | BLS | |||
| Setup / Close | 79 | 62 | 474 | 372 | 234 | 62 |
| Total: | 474 | 372 | 234 | 62 |
For an example three hop message delivery, the eltoo revocation system would require transmitting 1/5 as much data to update channels (234 vs 1221 bytes) compared to the current update mechanism used by the Lightning Network. BLS signature aggregation could reduce the amount of data that must be transmitted to an internet gateway to setup and close channels by 2/3 of that required when each channel is independently setup or closed (62 vs 234 bytes). The reduction in transmission overhead from using eltoo and signature aggregation increases linearly for longer relay paths.