In this Episode they talk about Chaincode Labs, which employs around a dozen people who either work on Bitcoin Core or study more fundamental research problems. And he shares his vision about the developments on the Lightning Network and the importance of Bitcoin and Lightning education.
He shares his take on the energy transition towards renewables and about the importance of liquidity and how the community comes to the aid with excess inbound. Severin Bühler from LnRouter.app taught him the tricks he needed to make his Lightning Node even more future proof!
What was your first experience with the lightning network and do you still know what you did/saw at that moment?
I learned about LN “theoretically” long before trying this out. I don’t remember the exact moment, it was some time in 2017. In December 2017, I gave a talk about LN at a meetup in Moscow, with like 10 people attending 🙂 Later on I installed various LN wallets to play with / pay for beer of coffee at conferences but to be honest I don’t have a genuine use case for LN myself yet.
Do you run a Lightning Node and if so what is your strategy with it? Or is it only for educational purposes?
Not really 🙂 I launched a node for some probing experiments, I’ve used a few mobile wallets just to try them out, but I’m not a regular LN user.
What can be improved on the LN so it can provide better quality service while discouraging monopolies ?
That’s the key question! At least, we should ensure that “small players” can join the network as routing nodes relatively easily. The protocol should not rely on central nodes too much, although it’s natural to node to want to connect to already well-connected nodes. It’s important that even if LN is monopolized, users can close their channel at any time and take their money out. In that sense, LN is less prone to vendor lock-in compared to a bank, for example. Still, the cost of exit is non-zero, especially under high on-chain fees…
In what way can a Lightning Node evolve in the future and also have some other purposes than only to make payment transactions?
People have been talking about implementing a messaging system on top of Lightning P2P network, but it doesn’t look like a good idea to me. LN is designed to forward payments, other use cases are in some sense abusing the protocol, or at least not using it for its intended purpose. Hopefully, such “secondary” use cases would naturally be priced out as payment-based use cases are willing to pay higher fees. If LN “only” does payments well, already that would be great.
We have at the moment 2 models “value-for-value model” & “pay-per-use model” that triggers the incentive to use of the Lightning Network. What other type of model could be used / implemented in LN ?
I haven’t been thinking about business models much to be honest. For me both existing models are good and not mutually exclusive. One thing that I’m not sure I want to see is financialization of any action online, where every click triggers a payment (via LN or other means), putting too much mental burden on users.
What does it take to get more attention to work in the Bitcoin and Lightning space? Do we need more use cases for Lightning for example?
It’s hard to judge for me because I’m already convinced that Bitcoin is very important… I’m mostly focused on the protocol issues (jamming in particular) and don’t pay close attention to use cases. I’m not convinced micro-payments are feasible long-term because LN security is based on potential on-chain dispute resolution, which requires on-chain fee. But what LN can offer in any case is nearly-instant settlement, which I think is very cool. Finally, we can implement the “electronic P2P cash” as Satoshi outlined, without making users wait for 10+ minutes until a transaction settles.
How do you view adoption among the mainstream in your role as a researcher and educator? So for the mainstream to use Lightning on a daily basis?
In the long term, it would be nice to see literally billions of people use Lightning, but I’m not holding my breath yet if we’re talking about the next 3-5 years. I’m not a fan of growth for the sake of growth – I want people to use LN / Bitcoin when / if they have a genuine need for it, and when they do, I want the protocol to be ready to accommodate them. If it’s 1 bn people – good, if “only” 100m – also not bad.
Do you have plans on building a startup one day? And if yes, what kind of product would you like to make?
Maybe, but the more I learn about modern startup building, the more I see that much of the business model is dependent on cheap investments and growth at all costs (fueled at least in part by that same money printer that Bitcoiners despise). I may start an independent business some day, perhaps something around my Russian-language podcast Basic Block Radio, but I wouldn’t be prioritizing exponential growth above all else, like Silicon Valley startups do.
The layer-two fee economics looks different from layer-one.
LN makes fees great dependent on the transaction value again.
Like In traditional finance, it’s common to charge fees as a percentage of the transaction value. Layer-two re-introduces the value semantics into protocols: relaying a payment requires liquidity, and intermediary nodes pay more in opportunity costs of locked capital when transferring a million dollars as opposed to one dollar.
Do you think routing will be a profitable business in the future like how mining is now?
I hope it will! This would make LN incentives well-aligned. If nodes can monetize via fees, they don’t have a strong incentive to monetize via other means, such as collecting users’ private data and selling it.
There are a lot of developments in using the Lightning Network as a multi-asset network. There is Taro for example, an open protocol (made possible by taproot) for transferring non-bitcoin tokens in Bitcoin transactions and LN payments. Do you think these developments are very important for the Lightning Network to grow further?
I have mixed feelings about multi-asset use cases. On the one hand, introducing another assets like stablecoins is genuinely useful for many people. On the other hand, it enables speculation (a-la DeFi on Ethereum), which in turn leads to blockchain congestion and high fees. I think Bitcoin / Lightning should primarily be money for common people to pay for things, not a speculation vehicle. But if speculation use cases bring more funds and attention to the space, this may be good in the long run for the money use-case too.
As LN grows, it may become infeasible for each node to store a full network snapshot.
Although the current LN size doesn’t sound like a lot by modern hardware standards, if we expect Lightning to grow by orders of magnitude, source routing may become challenging.
We want Lightning to work even on an IoT device with a tiny battery, little storage, and sporadic Internet connection. Is lightPIR an example of a possible algoritm for alternative efficient route discovery?
The graph growth problem is not the most urgent right now, but it may be potentially. There are multiple approaches to it, and the general idea is to outsource part of route construction to some specialized nodes. The question, of course, is whether we must trust them, and how to make this scheme work while requiring as little trust as possible towards this special nodes. LightPIR is a recent paper I read and summarized in my blog. The authors leverage a cryptographic construction called “private information retrieval” (hence PIR) for privacy preserving route construction. This is an interesting approach but there are many practical roadblocks to implementing it in the LN.
Do you like this article and our other content? Donate and support us in our mission to create a worldwide distributed Lightning Network by connecting countries around the world and bringing The Lightning News to you first!
Follow The Daily Moon also on Telegram and Twitter!
What is your role within Chaincode Labs, besides the research you do?
My role is entitled “postdoctoral researcher”, so research is most of what I do. That involves reading recent relevant papers, coming up with our own models and solutions, discussing things with colleagues and Bitcoiners outside of Chaincode.
You’re a postdoctoral researcher at Chaincode Labs. What is Chaincode Labs exactly and how did you end up there?
Chaincode Labs is an organization set up to support research and development of Bitcoin and related technologies, such as LN. It employs around a dozen people who either work on Bitcoin Core or study more fundamental research problems (like I do). I applied for a position of a postdoctoral researcher at Chaincode while I was at the University of Luxembourg, and I’m happy they offered me the position.
This year I attended the Chaincode Labs Lightning Seminar. This was a great experience for me and also for all other participants! In week 4 and 5 we covered all limitations of Lightning and the future with the developments of Eltoo. It again became clear to me that there is a lot of work to do still on the Lightning Network, but also that the developments are going very fast!
Is there enough new growth of developers to continue to enhance the Lightning Network in the near future? Or do we need some extra patience…?
Patience never hurts 🙂 Bitcoin’s design philosophy prioritizes doing things right rather than fast (as they do in startups and many alternative blockchains). We do need extra developers of course! Chaincode does a great job at onboarding new developers, helping run programs like Summer of Bitcoin and Qala, as well as online seminars you mentioned. However, many of LN potential improvements depend on soft-forks in Bitcoin Core (like Eltoo depends on sighash_noinput), and Bitcoin soft-forks may take years to prepare and roll out. Although even in the current state of Bitcoin, we’ve got lots to work on in Lightning, including liquidity issues, probing, jamming, PLTCs…
You’re researching the security and privacy of Bitcoin with a focus on the Lightning Network. You work together with Alex Biryukov and Gleb Naumenko on this research. The title is Analysis and Probing of Parallel Channels in the Lightning Network. Can you explain what it’s about and what the goal is of your research?
We studied the problem of probing. Probing is a technique allowing an LN node to learn the balance (that is, the distribution of coins) in any remote forwarding channel. Balances are private information, but it turns out that using make payments (probes), the attacker can measure with high precision how many coins some node has. In our paper, we introduced a new model for probing. Previous models couldn’t handle the case where the target hop has multiple channels (such channels are called parallel). We described exactly what the attacker learns in this case, calculated the limits of the attacker’s knowledge, and described an improvement of the attack that allows probing previously unavailable balances.
In your recent paper with the title: A Quantitative Analysis of Security, Anonymity and Scalability for the Lightning Network, you discuss the limitations and security issues of the Lightning Network. Can you elaborate a little bit about the outcome of this paper?
We analyzed three attacks previously described in the literature and measured how likely they are depending on which nodes are compromised. Without going into too much detail, the general observation is that LN topology is indeed quite centralized, which means that “central” nodes that route most of the payments, can carry out such attacks much more successfully. I don’t think this is a show-stopper though; we should design the protocol in such a way that even if the topology is centralized (we can’t fight it if it’s economically advantageous), even then users’ privacy is protected. Apart from that, in the paper we quantified the so-called HTLC limit problem. Each LN channel state is a valid Bitcoin transaction, and transactions have limits on the number of outputs. This means that a channel can hold only up to a certain number of in-flight payments. This limit is exploited in another attack, jamming, which I’m researching now.
In 2020 you asked yourself ethical/ideological questions, for example: “Is it ethical to work for a “blockchain” under the control of a centralized development team? Or work for a blockchain analytics company that helps deanonymize users?” And are these questions still difficult for someone to start working in this industry?
They are, although I try not to see the world as black-and-white. Bitcoin, among other things, is attractive to be because of its humanistic appeal, but who am I to blame people who work on other blockchains etc. Something good may come out of their work too, I just see Bitcoin as the most straightforward way to come up with a better and more fair financial system, that’s why I’m working on it. My attitude to blockchain analytics companies is a bit worse, but the core reason why they exist are regulations demanding KYC/AML compliance. If the laws were not that strict, the business of helping exchanges etc comply with them wouldn’t be so lucrative in the first place.
Rene Pickhardt opened an issue on bolts github about the possibility of probing both directions of a channel as soon as he receives a channel announcement message. Becaused initially the entire balance of a channel would be on one side and that node would then be the initiator.
In your abstract of your research you talk about several countermeasures. One of them was unannounced channels. Is the issue Rene points to a problem that is also part of the research?
What Rene points out is a special case: apparently, it’s easier to probe a new channel because the attacker can reasonably assume that all capacity is initially on one side. However, rebalancing doesn’t solve the problem: the rebalanced channel can also be probed. Rebalancing may be thought of as a countermeasure, but it’s not very effective (At least in the setup described in the PR). A more generic rebalancing protocol, just-in-time routing, also invented by Rene, is much more helpful here. If a node can change the balance while it is being probed, the attacker would have to start probing from scratch.
You identified with experiments that channel balances cannot be considered private data. And that privacy-efficiency is a big trade-off, because hidden balances hinder routing efficiency. How do you envision a solution for this in the future? What research still needs to be done?
From the efficiency standpoint, multi-part payments may help (they already work): if we split a payment into pieces, it’s more likely to succeed (if we split in a smart way). We may envision an opt-in protocol feature where nodes willingly share their balance for better reliability (and give up their privacy). I don’t see a fundamental solution yet (maybe some fancy cryptography can help, like zero-knowledge proofs? You’d have to ask a cryptographer, I’m not one). Although I believe we may iteratively arrive to a protocol that works well enough in both privacy and reliability metrics.
Is a distributed, privacy-preserving credit network (protocol) possible on top of layer 2 in the future, that does not require any ledger to protect the integrity of transactions?
(this doesn’t look to relevant too) Credit networks are somewhat similar to PCNs but require trust. I don’t think they are too interesting, as we already have a trust-based financial system. Technically, we could build a Lightning-resembling credit protocol of course.
The initial code published by Satoshi was not of enterprise quality and was probably too “strict”. For example, transactions must commit to outputs they are spending. Seems logical, until someone explores the protocol deeply enough to realize that we can remove this restriction and enable new functionality without sacrificing exiting security guarantees. Eltoo and segwit are cleverly designed protocols and an interesting example of blockchain protocol design evolution.
What else can we strip from the protocol to enable new use cases without weakening the security model?
don’t have a good answer TBH) Let’s implement the ideas we’ve had so far first! 🙂 Segwit is 5 years old and not used by all wallets yet. Taproot / Schnorr activated in November 2021, and we’re only starting to see its potential use cases implemented. One of them is Taro you mentioned earlier. Another is PTLCs – another type of conditional payments that LN is based on, an alternative to currencly used HTLCs. And no-input softfork enabling Eltoo is not even rolled out yet…
Spider is a routing solution that “packetizes” transactions and uses a multi-path transport protocol to achieve high-throughput routing in PCNs (Payment channel networks). Packetization allows Spider to complete even large transactions on low-capacity payment channels over time, while the multi-path congestion control protocol ensures balanced utilization of channels and fairness across flows.
Could this be a solution to use the liquidity on LN in more efficient way ?
This may be part of the solution but we need to think more about how to adapt this idea to actual LN protocol. LN already uses MPP (at least some implementations do); Spider is a way to “price-in” rebalancing costs to maintain the network in a “balanced” condition.
This was a time just before Covid broke loose. Are you happy with the career choice you made in that period?
Absolutely. Chaincode is the ideal place for me to continue doing Lightning research. It’s a unique place that brings brilliant bitcoiners together, and I’m thankful for the opportunity to work alongside them.
What do you think about the liquid network?
Not very interesting for me, but if they find their market niche and satisfy someone’s demand, good for them! Basically, you lock your coins in a multisig and can move them back and forth “off-chain” quickly (and with “confidential transactions”), but of course you have to trust 11/15 signatories to give you your money back when you want to exit. LN doesn’t require such trust: you can close a channel at any time without anyone’s cooperation.
You’re a co-host in a deeply technical Russian-language podcast. It’s called Basic Block Radio. What do you discuss in it? And what are the backgrounds of the people listening to it?
I started this podcast in 2017 with the idea of bringing high-quality, no-bullshit blockchain information to the Russian speaking audience. At the time I’ve just started my PhD in Luxembourg, I was searching for a topic and was reading various papers about Ethereum, privacy coins, and other stuff. Since then, three of my friends joined as co-hosts. We interview developers and founders of well-known projects, many of whom speak Russian. We’ve had guests representing Ethereum foundation, 1inch, Zerion, Solana, Aave, etc. We discuss Ethereum and DeFi quite a lot, other blockchains too. Our listeners are developers, entrepreneurs in the space, and just technical people interested in how stuff works. Our main focus is tech, we try to dig deep and explain how everything works under the hood. We never discuss prices, never give investment advice, etc. I think this helped create a healthy atmosphere and a lively community around the podcast. In the latest episode, I share my impressions of the Bitcoin conference in Miami in April 2022. I give a summary of nearly all talks on the Open-source stage, explain the latest progress in Bitcoin and related protocols, so we do have quite some Bitcoin coverage too.
More adoption is necessary for a lot of reasons. It gives developers more information and it means that there are more use cases for the use of the Lightning Network.
What is the most important to focus on in the short term to grow the adoption? For example more user friendly, more PoS solutions, better security, etc.
I’m biased because I’m thinking about protocol details much more than about business models and use cases, but I’d say we have to set up the protocol right and then scale. Attracting too many users when the protocol is not ready may be dangerous. For example, jamming (blocking) channels is very cheap, and we’re lucky this hasn’t been done on scale yet. If billions of people rely on LN for their daily expenses, and then it suddenly stops working, this may ruin the confidence in Bitcoin. Being user friendly is important of course, but I’m focused mostly on relatively low-level security / reliability questions, I see them as more fundamental.