Gijs Van Dam | Connect the World
How to remotely close channels
This week, in Episode 14, we talk with Lightning Scientist Gijs van Dam who wrote two papers about the Lightning Network. During his research on the balance disclosure attack, he found a way to remotely close down channels between other nodes. A large amount of channels, representing 17% of the entire capacity of the Lightning Network was potentially at risk!
In his second paper he describes a possible solution to mitigate balance disclosure attacks by using extra payments of a random amount to obscure the actual amount.
Of course we also talk about the use of Lightning, the adoption of the Lightning Network in Malaysia and about a possible future in which we trust peer nodes even more than a random node!
Of course you want to know everything about this research! And do you think security is just as important as Gijs does? Then watch or listen to the full interview or start reading below! Enjoy!
Do you also want to know why Peter thinks every Bitcoiner should mine?
Watch or listen to the full interview or start reading below! Enjoy!
Lightning Papers
In your most recent paper you wrote something about ‘the balance discovery attack’, can you explain what this is?
The basic concept of the balance discovery attack is to use payments with a false payment hash to figure out the balance of a channel between two other nodes. (Note: I’ll explain it in more detail during the show)
What does privacy mean in the context of the Lightning Network?
Privacy in the context of Lightning Network has lacked a proper scientific definition for quite long. But most papers nowadays use two basic notions of privacy in LN:
(On-path) Relationship Anonymity: Each intermediate node in a payment path does not learn any more information about the users in the path other than its direct neighbors.
(Off-path) Value Privacy: A corrupted user outside of a payment path can learn no information about the value of the payment, assuming the payment path runs through honest users.
It’s the Off-path value privacy that is attacked with a BDA.
So you have three dimensions of privacy, personal and relational make sense but can you describe what spatial means?
The spatial dimension relates to the broader definition of online privacy. It describes the notion having your virtual space invaded by someone else. For instance, someone shitposting in your comments on your website, or someone shitposting in your timeline on Facebook. It’s about having your personal, online space invaded. It’s an interesting concept, but it doesn’t relate to Lightning Network.
What do you think about all these Lightning communities that exist? Like our telegram group where people connect. What do people be aware of?
They have been very helpful for me. I use them when I have questions, and I scan the messages to see what other people are up to. A great example is LightningNL group. Marnix Kloek had some great info for me that helped me when writing my last paper.
In the paper you wrote in 2020 you disclosed a privacy issue, this issue makes it possible to determine channel balances. Can you tell us how?
It wasn’t a privacy issue, it was a security issue. I found a way to close down channels between other nodes remotely. At that time I estimated I could close down a large amount of channels representing 17% of the entire capacity of the Lightning Network. This was the by-catch of my research on the balance disclosure attack.
One of the possible solutions to this issue is Approximate Differentially Private Payment Channels. Can you tell us more about it?
The idea is to mitigate Balance Disclosure Attacks by using extra payments of a random amount, to obscure the actual amount of a payments.
Can you tell us what noise payments are?
Noise payments are the extra payment (of a random amount) that go back to the payer, so that the payer doesn’t lose the noise payment (apart from the extra transaction costs)
You describe three approaches to achieve the inability to determine the amount of a noise payment. Can elaborate on that?
Well, the noise payment itself has to come back to the payer, otherwise it would be very expensive to add the noise. So you have to find a circular path that comes back to the payer. There are currently two ways of creating such a path: #1 Via another (3rd) node, to create a little multi-hop triangle. #2 Via a 2nd parallel channel with the same node. So the payment goes up through one channel and down through the other. A third approach would be to change the Lightning Network protocol so that it supports the noising of payments natively.
But I am slightly skeptical about the practicality of noising payments, since it requires locking up extra capital for the sole purpose of noise payments. So that makes it less attractive.
Onion routing properties of payments give senders of a transaction a lot of privacy. Why is it that for receivers of a payment it’s totally different?
The way I see it, it is not the onion routing where the receiver’s privacy breaks down. Onion routing provides the same privacy to the sender as to the receiver. In onion routing each hop in a route can only see the hop before it and the hop after it, and can’t tell whether either one of them is the sender or the receiver. But since LN uses source-based routing, so the sender has to know the receiver, because they have to find the route to the receiver, that’s where the privacy for the receiver breaks down.
But Rendezvous routing offers a really nice solution to this, where the privacy for the receiver is restored. Rendez vous routing is a system where the receiver calculates a route from a public node to himself, and adds that route to the invoice. The payer now has to find a route to that public node, and create a onion for that route, and the add the onion from the invoice to their own onion. This way you the sender can’t tell who the receiver is.
What do you think about the solution to never open a channel with your own UTXO? So instead of making more use of for example Lightning Lab’s Loop Out?
I haven’t looked into it that much. Personally I am not that interested in federated sidechains. The federation aspect of it changes the trust assumptions in a way that doesn’t appeal to me. The liquid network relies on the trustworthiness of its functionaries, and what attracted me to Bitcoin and Lightning in the first place was that trustlessness of it. I can see the business side of Liquid Network! I’m not against sidechains. But I find them less interesting from a technological perspective.
When a user opens a channel their node will lock up a Bitcoin Unspent Transaction Output (UTXO). That means to use Lightning you have to make use of an on-chain wallet. Do you see this as a vulnerability when talking about a multi-hop scenario?
I see it as a intrinsic security risk of running a Lightning Node. Lightning uses a hot wallet, and people running a node should be aware of the risks that are associated with hot wallets.
Your first paper is : Improvements of the Balance Discovery Attack on Lightning Network Payment Channels
Your Second paper is : Hiding Payments in LN with Approximate Differentially Private Payment Channels
What will be the subject of your next paper, any ideas ? When will it be released?
My third paper will be again a paper on mitigating Lightning attacks. There’s a group of attacks called griefing attacks, that are essentially DDOS attacks on the Lightning Network. I have some ideas on how to reduce the impact of such attacks, and I think that it also makes it harder to do a Balance Disclosure Attack. So in theory we should hit two birds with one stone. I’m hoping it will be released this summer.
First you show readers the problem and then you offer them a solution. Are you more a scientist or more a developer?
At the moment I am more of a scientist then a developer. Although a lot of development comes with doing my research. But maybe that will change in the future? Who knows.
Support us in our mission
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!
The Lightning Network
You have some personal projects you’re working on and your goal is that in the future loads of people will be contributing to it. Can you tell us more about Boilerplate Paper and Janos?
Boilerplate paper is a tool I created for writing scientific papers and theses. It uses a tool called Pandoc to transform markdown to LaTeX, which is a typesetting system broadly used in the scientific community. This allows me to write my papers in simple markdown files, which I really like.
Janos is a port of a static site generator called Metalsmith. Metalsmith is built in Node and runs on the command line, but Janos is a port of it that runs entirely in the browser, and is fully integrated with Github. So you only need to clone the repo on Github, and you have a website of your own up and running on Github pages in less than 3 minutes. I have a three minute Youtube vid that explains the process.
A half year ago we were at a bitcoin book presentation at a bookshop in Hilversum, it was possible and still is to purchase your books with bitcoin. it’s a libris bookshop, mindbus has made this website…. why can’t we pay with lightning yet?
The payments on that website are being processed by a payment services provider that doesn’t offer Lightning yet. But as a work-around you could buy a (VVV) giftcard at Bitrefill.com and pay at Libris.nl with that giftcard.
Do you run a lightning node and what’s your hardware setup?
Yes, I do, although it is down today. ☹It’s a fanless mini-pc running Ubuntu, and LND.
What lightning implementation do you prefer at the moment?
I run LND, because at the time when setting up my node the documentation for LND was better. But for my research I have run all three major implementations (LND, c-lightning and Éclair) and I grew a liking for c-lightning.
We often discuss that it would be awesome if a major bank would offer a custodial Lightning service. Do you think some privacy issues within the Lightning protocol need to be fixed first?
With all the KYC procedures that banks need to adhere to by law, the privacy issues of LN are the least of your problems. So, no, I don’t think that there are privacy issues inside the Lightning Protocol that are an obstacle. If anything, it’s the other way around. Lightning Network gives too much privacy to make it feasible for major banks to offer it. But El Salvador has proven that this need not be the case, so I would be over the moon if a major bank would start offering something similar to El Salvadorian wallet.
In 1999 you started your own web development company, called Mindbus. It allows Dutch bookstores to compete through e-commerce with large companies like Amazon and Bol.com in the Netherlands.
If banks will offer their own custodial Bitcoin and Lightning services. How important is it to you that people can continue to use non-custodial solutions and have an alternative to fiat banks?
I think it is important that there is a full range of solutions from fully custodial to fully non-custodial. If you want everyone on board, then the UX will have to improve dramatically. I don’t see a non-custodial solution with a UX that is completely idiot proof. So onboarding millions of people to LN requires some sort of partly custodial solution. That being said, I think it is extremely important to have a large enough fraction of non-custodial users. If only to keep the fiat banks in check.
Do you think that for example, our Rings of Fire concept will evolve in an underground Lightning Network where there is more trust between peers instead of trying to do everything trustless? So avoiding the public graph?
I love the idea of the rings of fire concept. I think it will be a huge part of the solution to the liquidity problem. And while it introduces a small amount of trust, it is a level of trust I can live with. When someone breaks the trust in a ring of fire, worst case you have opened up a channel, and didn’t get inbound liquidity in return.
And there is something to be said for trusting your pears more than a random node. The researcher Rene Pickhardt proposed the idea of sharing more data with the nodes on step away from you. He called them friends-of-friends. You could see a system where you share the balances with them, to make routing and rebalancing easier.
But you could also think about making Rings of Fire work in a trustless environment as well.
So I could see it develop in both ways. Making rings of fire more trustless on one end, and trusting your peers *more* on the other end.
Security on lightning network is at the moment one of the biggest topics at the moment. What are at the moment the biggest issues?
I think the biggest issue is people not being aware of the risks. When running your own node you have real money inside your house. Without the proper precautions, it’s not dissimilar to having a lot of money under your mattress. So you should really make the effort and learn how to protect your assets. I think a good start is the Casa’s Wealth Security Protocol, even if you don’t use their products and services. It’s a comprehensive document explaining the risks and the necessary precautions.
Would you like to see a cold wallet integrate instead of the hot wallet we use at the moment for the onchain funds. Do you think it is technically possible or do you have anotha solution in your mind?
Running a Lightning node that doesn’t have access to your keys seems highly impractical. You would have to sit next to your node with your Ledger or Trezor 24/7. But being aware of the risks, and offloading Bitcoin from your hot wallet into cold storage is currently the best solution.
What developments are still needed on the Lightning Network to make it more future proof?
What is the most important thing to get fixed before we can say lightning succeeded ?
Depending on your measure of success you could say it already is a success. Over 30.000 nodes, 3.5k BTC capacity. It’s by no means a small feat. With El Salvadore accepting Bitcoin as legal tender, and a wallet based on the Lightning Network protocol. That’s huge!
But real mainstream adoption is still missing. To achieve that I think two things have to happen. On the user side it’s paramount ot have a seamless UX. Something where you don’t even have to know that your are paying through the Lightning Network, something that can outperform Paypal, Alipay or Ideal in the Netherlands from a UX perspective. On the vendor side we need to have PSP’s that offer Lightning as a payment option. Jack Dorseay’s Cash app will roll out Lightning support this year. So that’s 36 million people on-boarding to the Lightning Network this year. And with the Square payments platform you can accept Cash app payments. So it’s interesting to see what happens there. But Dutch darling Adyen came out as recently as last year saying that had no interest in offering crypto payment options.
How is the Lightning/ Bitcoin adoption in Malaysia?
Terrible. ☹ I think this is mainly because of Singapore, the city state on the southern tip of the Malaysian peninsula. Singapore is the Switzerland of South-East Asia. So all the banking innovation and the research has moved there.
Can you use the LN in your daily life ? If you want to buy something in a store, pub ….
You can, but it is cumbersome. I tried it a few weeks ago, because I was curious. So I bought a giftcard at bitrefill. And you have giftcards for all sorts of businesses: restaurants, Grab (like Uber), supermarkets, etc. But using giftcards for all your payments is a hassle, and the exchange rates on bitrefill for Malaysian giftcards is horrible. Way worse than for Dutch giftcards. I don’t know why that is.
What aspects of the Lightning Network need to be addressed in the near term to increase adoption and for Lightning to reach critical mass?
Three things: UX, UX, UX.
Extra
Do you think the second layer will be a solution/problem to laundry coins?
It’s a theoretic and interesting possibility. It is also a possibility to achieve more privacy, which isn’t necessarily a thing that only criminals want.
What was your first experience with the lightning network and do you still know what you did/saw at that moment?
When I moved to Malaysia I joined the Blockchain Developers Malaysia Meetup. During one of the meetups in 2017 someone explained the concept behind Lightning Network.
What do you think about the liquid network?
I haven’t looked into it that much. Personally I am not that interested in federated sidechains. The federation aspect of it changes the trust assumptions in a way that doesn’t appeal to me. The liquid network relies on the trustworthiness of its functionaries, and what attracted me to Bitcoin and Lightning in the first place was that trustlessness of it. I can see the business side of Liquid Network! I’m not against sidechains. But I find them less interesting from a technological perspective.
On what Bitcoin layer will the most “smart contracts” be built?
Well, on what layer is Lightning Network built? In the end it’s always built on the first layer, since you have always the option available to you to broadcast the “smart contract” to the blockchain. The trick of Lightning Network is that you don’t have to broadcast each transaction, knowing that you can at any moment. And that “trick” transfers well to smart contracts as well. I think it’s an added benefit to not having to broadcast your smart contracts. From a privacy perspective as well as from a cost perspective.
What could be a solution to coordinate different developers with different ideas, timelines, roadmaps, business models in a more structured way.
That’s the one billion dollar question. I don’t have experience with running big open source projects. I do have experience in running a development company, because that’s what I have been doing in the past twenty years. But that’s completely different than coordinating unpaid developers dispersed over the entire world. Paying your employees a decent amount of money by the end of the month tends to make it easier to have them aligned. Although it is still by no means easy.
Do you use tools like amboss, lnnodeinsight or others to make your analyses?
No, I have not. I use my node for research purposes mainly. So I haven’t been running it like I should have, if I wanted to use it as a routing node. But it is still one my todo list to setup a decent routing node, and tools like lnnodeinsight would definitely be of use then.
Do you see a future in layer 2 solutions for Bitcoin-like RSK which brings the functionality of Ethereum Smart Contracts to the Bitcoin blockchain?
Yes. I am very interested in what is happening right now after the Taproot update. Because we can now use Schnorr signatures, we can have adaptor signatures which allow for some really cool tricks like Discreet Log Contracts. A DLC allows for setting up contracts between two parties directly on the Bitcoin blockchain using an oracle to determine the contract outcome. So at least part of what Ethereum Smart Contracts can do seems to come to Bitcoin as well.
Your project Janos integrates with Github and Github Pages. What are your thoughts about a decentralized alternative for Github? For example the peer-to-peer alternative Radicle?
And does Bitcoin and Lightning need to stay decentralized in the future?
I would love to see a decentralized Github. In the past I have looked at the Interplanetary Filesystem (IPFS) which is a a distributed system for storing and accessing files. But that doesn’t really integrate with Git well, since it doesn’t properly allow for updates. I haven’t looked into Radicle much, but it seems like a Napster for your repos. I like the idea of it, but then again, I don’t really feel locked in with Github. I have all the repo’s on my local machine as well, so if I want to pack up my shit and go to Gitlab, nobody is stopping me. So I’m not sure there’s a huge need for a decentralized Github.
But Bitcoin and Lightning *need* to stay decentralized. Centralized Bitcoin isn’t Bitcoin.
Do you have any advice for beginners who start building a fresh node? Perhaps some points of attention regarding privacy?
Obviously watch the Satoshi Radio tutorial on setting up your own node with Umbrel. 😉If I could give one piece of advice is to first set up a node running on testnet, instead of mainnet. And then just play around with it, without the risk of losing real Bitcoin. Or, something I have done in the past, setting up a local network of three or more nodes, running on regtest. You can use tools like Polar (https://github.com/jamaljsr/polar) and Simverse (https://github.com/darwin/simverse) to spin up multiple Docker containers that form a little LN. You can spin up all the three main clients, and see which one you like most. And it allows you to make all the dumb errors, without costing you dear money.
Laptopman
LNcapital, node management for professionals | Henrik Skogstrøm
9 April 2023
No Comments
Read More »
