Lightning This Week #660,375
Lightning This Week #660,375
UTXO stake certificates, Lightning Network time machines, and just too much gossip
Saluton my fellow Lightning enthusiasts!
Another week, another set of Lightning Network updates fresh from the interweb feeds. One topic of discussion that has seemed to pick up a lot of unnecessary attention on Twitter this last week was the recent discussion around sats vs bits when denominating values in Bitcoin.
Let me settle this tough one for you real quick: Sats are the standard.
Now that we got that out of the way, onto more interesting technical topics.
UTXO Stake Certificates
Channel-jamming attacks are network attacks where a malicious user/node finds a way to lock large amounts of bitcoin in a series of channels, effectively creating a `jam` in the routing of HTLCs. This is usually done by delaying the acceptance or rejection of the routed payment, so none of the previous nodes in the routed path will get paid / reveal pre-images. We’ve known about these possible attack vectors/scenarios since as early as 2015, and some similar `flooding` approaches have also been presented more recently.
Until the payment eventually times out, each channel used to route the payment is unable to use those funds to route other user’s payments. Since a route may cross more than a dozen channels, that means every bitcoin controlled by the attacker can prevent more than a dozen bitcoins belonging to honest nodes from being used for honest routing.
With the intention of solving these channel-jamming attacks, Gleb Naumenko and Antoine Riard recently released a post to the Lightning-Dev mailing list explaining their proposal supporting the use of Stake Certificates.
Post: Mitigating Channel Jamming with Stake Certificates
The main idea behind the Stake Certificates proposal is for each payment to include a form of cryptographic proof that proves its spender controls some amount of bitcoin onchain (UTXO ownership proofs, a.k.a. fidelity bonds). This would allow routing nodes to have different policies and requirements based on the availability of certificates in the encrypted onion payload — how much value can be routed given how much proof of a certain stake of bitcoin is shown.
For example, Alice’s node could announce that it would route payments up to 0.01 BTC from anyone who could prove they controlled at least 1.00 BTC onchain. This would allow someone to route a payment through Alice’s node but limit how much of her capital they could tie up.
While this is an exciting approach to solving channel-jamming attacks (one that isn’t mainly comprised of different upfront channel fees), the team does note it is early days of development and there are quite large hurdles ahead — primarily the creation of such privacy-preserving cryptographic proofs.
You can also read the original post on the BitMex blog here.
Gossip Gets Throttled
Maintaining a network graph of the Lightning Network topology is a computationally-intensive task for the node software, and reducing the overall networking traffic can generally improve the stability of the network. There have been ongoing efforts by the Lightning Labs team to reduce the overall noise of graph messages that LND nodes send and receive. To further these improvements, LND will now default to throttling graph updates more strictly than in the past.
PR 4810 adds a new protocol configuration option to allow the enabling/disabling of gossip messaging throttling for each new node/channel. While the default is to enable the throttling functionality, operators are always able to deactivate it.
PR: https://github.com/lightningnetwork/lnd/pull/4810
Lightning Network Time Machine
Christian Decker or Blockstream/C-Lightning has released a CLI tool that is able to reconstruct the topology of the Lightning Network given a node’s stored gossip messages.
In Christian’s own words:
“We can replay the gossip messages in order and reconstruct the network as it would have looked like at a specific time in the past. This tool does just that, including the 2-weeks passive pruning logic (if a channel hasn't seen an update in the last two weeks they are considered dead).”
This is quite a nifty tool that would allow an operator to emulate the network topology from their own node’s viewpoint given a specific timestamp in the past. Because communication between Lightning nodes happen over gossip messages, by essentially replaying all of the messages one-by-one in chronological order, an operator can technically reconstruct the network state at any given time in the past — a Lightning Network time machine.
Source Code: https://github.com/lnresearch/topology/pull/1
Things I Would Share This Week
Lightning Decoder v0.6.0 Release — If you’re a developer working with the Lightning Network, decoding and understanding BOLT11s and LNURLs is core to your development workflow. The latest release v0.6.0 of Lightning Decoder addresses some bugfixes and introduces support for automatically fetching and rendering LNURL Pay and Withdraw metadata.
Bitcoin Magazine Podcast interviews the MintGox crew — Learn about the MintGox Bitcoin ESports Gaming series and the future of human commerce in gaming environments and worlds, powered entirely by Bitcoin and Lightning.
4.20% of all bitcoins in the network are currently held in corporate treasuries.
That's all for Lightning This Week. See you all in ~1,000 blocks.
Note: If I have misrepresented you or your company/project please reach out.