For the past few months, I’ve been working with Clara Shikhelman at Chaincode Labs on the issue of jamming attacks in the Lightning Network.

Lightning is currently source-routed. This means that each sender does a local route search on the full network graph. This may become unsustainable as Lightning grows grows. Naively outsourcing route discovery to dedicated servers harms privacy: the servers know who is paying whom. The LightPIR paper proposes a solution. The authors combine private information retrieval with all-pairs-shortest-path pre-computation with hub labeling, optimized for real LN topology. In this post, I summarize the LightPIR protocol and outline the potential first steps to turn it from a research prototype to a real-world implementation.

In this post, we summarize our paper on channel balance probing in the Lightning network. It supersedes our earlier work on this topic. A video presentation based on this post (a longer version is also available):

First, we briefly introduce the Lightning network (LN) and the channel balance probing attack. Then, we propose an enhanced probing technique that allows an attacker to extract more private information faster. We run simulations based on real-world data and conclude that the proposed probing method is indeed better than prior art. Finally, we discuss potential countermeasures and their trade-offs.

For the significant portion of 2018, as part of my PhD studies in CryptoLUX group at the University of Luxembourg, I’ve been working on network-level privacy attack on Bitcoin and other cryptocurrencies with professor Alex Biryukov. This blog post summarizes our findings, which have been published in 2019 (“Deanonymization and linkability of cryptocurrency transactions based on network analysis”). You can watch my presentation at EuroS&P 2019 in Stockholm (press CC for subtitles; slides are also available):

You though it was enough to use mixers or privacy-focused altcoins to preserve the privacy of your cryptocurrency transactions? Think again…

This August, Berlin was the global center of all things decentralized. Thousands of blockchain enthusiasts gathered for the Berlin Blockchain Week – a series of conferences, meetups, and a hackathon. In this post, I’ll share my thoughts on Web3, which was the primary topic of the the first major event of the week – Web3 Summit. [¹]

Continuing the journey through layer-two technologies, here is a summary of the paper “eltoo: A Simple Layer2 Protocol for Bitcoin” by Christian Decker et al (see also: a summary in the Blockstream blog). Eltoo proposes a new construction for payment channels.[¹] It is not a fully-fledged protocol, rather, it only describes one crucial building block – state revocation mechanism. As you might remember from my summary of “SoK: Off the chain transactions”, the crucial challenge in L2 protocol design is old state invalidation. Lightning uses replace by revocation (in the SoK paper terms) which works in practice but has its drawbacks. The construction is rather complex, and the intermediate states held by the two parties are different. This inherent asymmetry prevents easily extending the protocol to support multi-party channels. Eltoo suggest another, symmetric state revocation mechanism, which is arguably better modulo one crucial limitation: it depends on a non-existent SIGHASH_NOINPUT signature flag. The good news is, this change can be implemented relatively easily via a soft fork and doesn’t seem to be very contentions. If that happens, it would be possible to replace state revocation mechanism in the live Lightning network to Eltoo while preserving all other aspects (channel synchronization vis HTLCs, routing algorithms, etc).

Here is papers I’ve been waiting for for quite a while. Thinking about it, I’d be happy to have (co-)written it, had I directed my research into this topic a bit earlier. Today’s summary is based on a systematization of knowledge (SoK) paper by Lewis Gudgeon et al entitled “SoK: Off the chain transactions”. The readers of this blog must be familiar with some of the challenges in layer-two protocols which I outlined in previous paper summaries. But as in any rapidly developing field, information is dispersed across various media and is getting outdated quickly. The authors summarize and systematize the challenges faced by the developers of layer-two protocols and compare the existing solutions. I definitely gained at least some of the mental clarity essential for digging deeper and contributing to the field. Read the whole thing to get general view of what problems are out there and how various proposals are tackling them. And the 136 references will fill your “read later” folder with papers for months to come!

Let’s continue our journey though recent paper which suggest ways to optimize routing in payment channel networks. In previous posts, we looked an SilentWhispers and SpeedyMurmurs. Both approaches emphasized privacy as an important goal, but employed different constructions: landmark-based routing (SW) and embedding-based routing (SM). Today let’s look into a paper entitled “Routing cryptocurrency with the Spider network” (2018) by Sivaraman et al.

In a previous post, I discussed SilentWhispers – a routing algorithm for credit networks. Today I’ll dive into a follow-up paper by a partially intersecting group of authors, entitled “Settling payments fast and private: decentralized routing for path-based transactions”, which presents a routing algorithm called SpeedyMurmurs.

As I stated previously, payment channel networks (PCNs) are cool. One of their distinguishing features, which separates them from the underlying layer-1 blockchains, is the importance of routing. A sender of a layer-1 transaction only assumes that that a miner will receive it in a reasonable amount of time. Any transaction with a sufficient fee will be confirmed. Its random route through the gossip network is not important.

Payment channel networks (PCNs) are a promising technology to overcome scalability challenges of open blockchains by moving the majority of transactions off-chain. At the time of writing, the only PCN working in production on at least some scale is the Lightning network (LN) for Bitcoin. I haven’t yet written the planned second and other parts of the series on how LN works (see part 1 and stay tuned). Today I present you the summary of a paper by Giulio Malavolta et al. entitled “Concurrency and Privacy with Payment-Channel Networks” (CCS 2017). It describes and formalizes the privacy and security of PCNs, and propose two PCN constructions which improve over LN, exploring the inherent privacy vs concurrency trade-off.

This the first post in a series about the Lightning network.

The best way to learn something is to teach it. From now on, I will write summaries of noteworthy papers I read, talks I watch, etc. That was one of the main purposes for starting this blog, after all.

In December 2018, I attended a Winter school on blockchain and cryptocurrencies in the Hebrew university of Jerusalem. This was one of the best events of this kind I have ever attended. The level of talks was consistently high, and the coffee break discussions were tremendously insightful. I’ve been making lots of notes during the lectures, and dedicated a whole episode of my Russian-language podcast to summarizing them.

Hi, I’m Sergei. I’m doing blockchain security research in the University of Luxembourg. Read more on the About page.