Bitcoin network mining fees rose as high as 643 sats/vbyte for the next block confirmation in May 2023, which is the highest bid required since 2017. This has disrupted the on-chain activity of many users and businesses, forcing companies like Binance, the world’s biggest cryptocurrency exchange, to work on implementing the Lightning Network, Bitcoin’s leading scaling solution. Wasabi Wallet’s implementation of the WabiSabi coinjoin protocol doesn’t integrate with the Lightning Network yet, but what does the  Lightning Network-enabled coinjoin future look like?

Opening payment channels with private coins created from Wasabi is currently done by completing the coinjoin and channel opening individually, creating multiple unnecessary on-chain transactions. A new implementation called Vortex allows for Lightning Network channels to be created directly from the private outputs of a Chaumian coinjoin, but has some caveats. A future potential Lightning Network-enabled WabiSabi coinjoin could fix some of these issues. Lightning Network channel closures are at a different level of complexity, so this article won’t cover them.

Read further to learn more about the details of why the Lightning Network is Bitcoin’s leading scaling solution, why payment channel openings and coinjoins go well together, how to currently open a Lightning Network channel from a Wasabi Wallet private UTXO, how Vortex presently handles the direct opening of channels from coinjoin outputs, and finally, how a future Lightning Network-enabled WabiSabi coinjoin might solve that problem.

The Lightning Network as Bitcoin’s Main Scaling Solution

As of 2023, it’s not a controversial statement to say that the Lightning Network is Bitcoin’s main scaling solution; it’s simply a fact. New technologies might emerge, and research is highly encouraged. Still, the Bitcoin business and developer communities have converged towards working on solutions to make the Lightning Network user experience seamless for many as a top priority.

What is the Lightning Network?

Lightning Network is a decentralized peer-to-peer payment network that allows instant, low-cost bitcoin transactions. Participants open a payment channel, which means they lock funds on the blockchain with another peer to transact with them freely in an off-chain manner. A participant can simply close the payment channel to bring back their funds on-chain. If you want to learn how the Lightning Network works, read here.

The critical part to retain is that the Lightning Network isn’t a magical solution; it requires payment channel openings, closures, and liquidity management. It’s also important to understand that Lightning is a privacy solution per se; it has some complex implications that you can learn about on Lightning Privacy, a research project sponsored by zkSNACKs and the Wasabi Wallet team.

Let’s follow up by looking at how Wasabi can be used today to open Lightning Network channels. Initiating your journey on the Lightning Network with private UTXOs is essential.

Open a Lightning Channel with a Wasabi Wallet Private UTXO

In this section, we will go through all the steps required to achieve the stated goal by using Wasabi Wallet to obtain private UTXOs, sending your funds to a Lightning Network wallet, and opening a payment channel.

Be aware that Wasabi can only provide private UTXOs to open Lightning channels with and can’t guarantee the privacy of transactions made within the Lightning Network.

Using Wasabi Wallet

To obtain private UTXOs, you only need to generate a wallet on Wasabi, back up your seed phrase, receive funds, and wait for the coinjoin magic. Depending on the amount and your settings, this will take a few minutes to a few days.

Once you have a private UTXO, you’re ready to send it to a Lightning Network Wallet, but first, you should choose a wallet.

Choosing and Using a Lightning Network Wallet

To choose a Lightning Network Wallet, you need to consider the level of security, privacy, and sovereignty you wish to have. For example, options like Wallet of Satoshi or Blink (Bitcoin Beach Wallet) are straightforward but fully custodial. This means they have a theft risk, so we don’t recommend custodial solutions.

On the other hand, you could use an LND or Core Lightning server on the command line, and you would have the most control over your funds and your lightning network experience, but this is often reserved for technical users.

Breez and Blixt Wallet are non-custodial solutions, private (implementing block filters, same network privacy as Wasabi), and easy to use. Still, there are also many other good wallets to choose from.

Whichever you decide to use, you will have to install it, generate a wallet, and send an on-chain transaction from Wasabi to this new wallet.

Open a Lightning Network Channel

If you’ve paid attention, we’ve made three transactions so far and still haven’t completed our goal. You must execute a final on-chain transaction by finding a peer and opening a channel on the user interface of your Lightning Network wallet.

It’s evident that it takes a lot of work to go from a non-private UTXO to having private funds on the Lightning Network.

Combining the privacy benefits of a coinjoin with the scalability of the Lightning Network is essential for a promising bitcoin future. Let’s look at how these two technologies go so well together.

Why Coinjoin and Lightning Network Channel Opens Go Well Together

To understand why a coinjoin is a perfect place to open a Lightning channel, let’s go back to the basics and the exact definition of a coinjoin:

A distributed task that requires every participant to be online and reactive at the same time so they can follow a protocol to build and then sign a transaction together within a specified timeframe.

But wait… This exact definition also applies to a Lightning Network channel opening! That’s why these processes blend so nicely together.

The only real difficulty is to settle the Lightning Network channel negotiation within 10 minutes, which is the time frame. All the processes between channel negotiations until the broadcast of the coinjoin must happen within 10 minutes.

Constructing a coinjoin with many participants can be much more time-consuming than opening a channel. As a result, it might be easy to pass this limit, resulting in one party revoking the channel opening.

However, since the coordinator decides on the timeframe for each phase, making the process less than 10 minutes is perfectly possible, assuming that channel negotiation between nodes happens at the end of the input registration phase.

The flowgraph above shows the two protocols mixed together to open a channel by sending the funding transaction using a coinjoin output.

Let’s follow up by examining how this is implemented on Vortex’s released solution and how it could work on Wasabi Wallet or another Wabisabi coordinator.

Open a Lightning Channel Directly from a Coinjoin

Vortex’s Case

Vortex is an open-source tool that you can use on top of Core Lightning, LND, or simply Bitcoin Core.  It allows you to execute taproot-enabled collaborative transactions, such as coinjoins, that can open directly a Lightning Network channel. This software is still in the alpha stage of development, but a transaction demo has been completed on the Bitcoin network. It’s based on the Zerolink protocol.

Vortex’s developer, Ben Carman, announced in December 2022 that even though the goal of opening a Lightning Network channel directly from a coinjoin transaction had been achieved with Vortex, it’s not optimal to use it with Core Lightning and LND but instead only with LDK, because privacy on Lightning lacks elsewhere.

He’s currently developing Mutiny Wallet, which is expected to implement Vortex lightning network channel open-enabled coinjoins.

Caveats of Vortex’s Implementation

Vortex’s Lightning Network-enabled coinjoin implementation has some caveats, most inherent to the ZeroLink protocol.

First, outputs must be registered during input registration (blinded outputs), the first phase of the coinjoin. As a result, channels must be negotiated at this time, which augments the time restraint. This is different from Wasabi Wallet’s current coinjoin implementation.

Then, Vortex inherits the toxic change problem from the ZeroLink protocol since the size of the private output is chosen by the coordinator server.

Finally, a challenge that Vortex is facing is liquidity. It’s already hard for a coinjoin coordinator to gather enough inputs interested in participating in a coinjoin. Therefore it’s even more complicated if we need every one of these participants to want to open a lightning channel specifically and even more challenging if we also need all these channels to be funded with the same amount.

To fix this last problem, Vortex uses an extra round before the inputs registration phase to gather enough inputs until a certain threshold is reached (2 is enough to break deterministic links). The same technique was used in Wasabi Wallet 1.0.

Now that we’ve explored Vortex’s caveats, let’s look at how the Lightning Network channel openings in WabiSabi could work differently.

Wasabi Wallet’s Future Potential Case

For the initial problem, the WabiSabi protocol makes it possible to begin negotiation right before the output registration phase, much closer to when the transaction will be broadcasted. This doesn’t fix the time restraint in an absolute manner, but it makes it an easier problem to fix.

The main advantage of using WabiSabi is that change from the Lightning Network channel openings is also coinjoined into private UTXOs in most cases. This allows the entire amount owned by each peer to be made private, not just the UTXO created for the Lightning channel. Consolidating these private UTXOs can still be problematic, so spending the whole wallet balance in one transaction should be avoided to ensure a payment can’t be recalculated to match the value of a specific coinjoin input.

We also saw that one of the issues of Vortex is to gather liquidity. This problem would be worse using WabiSabi because this protocol works best with many inputs. For example, the zkSNACKs coordinator requires 150 inputs to proceed with a coinjoin round.

One of the easiest ways to solve this problem is by using the zkSNACKs coordinator along with users of other services (Wasabi Wallet, Trezor, BTCPayServer…) to open the Lightning channels. Even if the other participants are not opening channels, coinjoining with them would be extremely helpful to make it hard to know who opened the channel (especially considering that it could be various inputs with dual-funded channels).

The implementation is also fully open-source, reasonably light (complexity is on the client side rather than the backend), and built to intentionally reduce the number of privacy leaks to the coordinator as much as possible. As a result, the coordinator has almost the same amount of information as any observer of the chain and can’t deanonymize users.

Remaining Issues with WabiSabi’s Implementation

Blame Rounds

Some issues remain, and the most tricky one is failed rounds. A round fails if some users register inputs but do not provide a signature for those inputs once the entire transaction has been assembled by the coinjoin coordinator. The next round is known as the “blame round”, where only inputs successfully signed in the initial round can register. These restricted rounds are recursively retried until all signatures are successfully collected or until there are not enough whitelisted inputs left.

Round failures can lead to friction with the current implementation of the Lightning protocol: A channel opening can’t be canceled; it can only fail if the transaction is not broadcasted after the allowed window (10 minutes by default).

But if a round fails, the commitment transaction previously created is not valid anymore, and the channel opening negotiation has to be started again, which is only possible once the first 10-minute window has ended.

So the whole coordinator must wait to accommodate the 10-minute timeframe for Lightning users, but waiting is terrible in coinjoins because it exponentially increases the probability of some clients becoming not responsive and disconnecting.

The simplest solution is to never participate in blame rounds if the intention is to open a Lightning channel. This solution is great, but it would take a lot more time to open channels because each attempt takes 10 minutes and has only a 15% success rate (based on data measured with zkSNACKs’ coordinator parameters), so it would take about 1 hour to broadcast the funding transaction.

Unpredictability

With WabiSabi, you can’t know upfront how much anonymity you will get from the round. Sometimes you will gain a lot of privacy; sometimes, you will gain almost nothing.

This is not an issue for normal Wasabi users because they can just participate in new rounds with their outputs if their anonymity gained is not as good as expected. But outputs used to open channels can’t be remixed, and therefore we must be sure that enough anonymity is reached in one shot.

There is no easy fix for that without changes to the WabiSabi protocol, or at least to its implementation (an example of a change would be for users to declare the denominations of the outputs they’d like to receive before the round). However, clients can just make a round fail if they see that they won’t gain enough anonymity, but this would be considered a DoS attack, and they’d be banned temporarily from future coinjoin rounds by the coordinator.

Conclusion

This article introduced the definition and direction of the Lightning Network, how Wasabi Wallet can be used today to open private payment channels, why Lightning Network-enabled coinjoin transactions is a powerful idea that is already possible with Vortex, and how a future WabiSabi implementation combining both technologies could differ and solve some caveats.

The post What Lightning Network-Enabled Wabisabi Coinjoins Might Look Like appeared first on Wasabi Wallet - Blog.

Bitcoin uses what’s known as the blockchain to record the history of bitcoin transactions. A copy of this blockchain is stored on the nodes which make up the bitcoin network. When a new transaction occurs and has been broadcasted to the network, nodes and miners reference the blockchain to confirm the validity of the transaction to confirm that it is a valid coin, spent by the actual owner, and has not been double-spent. If it is a valid transaction, the nodes will propagate it across the network and a miner will include it in a new block of transactions which is then appended to the blockchain. Any new blocks are also confirmed by the nodes.

Dimensions, State Machines, and Time

Think of the bitcoin network as a state machine. A state machine is something that enforces the laws, hosts and stores the status or the state of something at any given time. Multiple states chained together form a timeline. A dimension is a state or timeline which is hosted on the state machine.

In the bitcoin dimension, the state machine is the bitcoin network made up of physical computers called nodes. In bitcoin, the present state is the ownership of bitcoins and balances, determined by the record of transactions. The state is also known as a block and this chain of states together, the timeline, is known as the blockchain. Whenever there is a new transaction, that transaction is included in the next block and is then appended to the blockchain. Each block added to the blockchain is a bundle of new transactions. The history of each transaction, its timeline, is the chain of blocks relevant to that specific transaction and is unique.

state machine = bitcoin network

state = blocks

timeline (chain of states) = blockchain

dimension = layer

In the bitcoin reality, the blockchain is the 1st dimension also known as layer 1. There are higher up and parallel 2nd dimensions that utilize the 1st dimension as its host. State machines inside of state machines. Dimensions inside of dimensions. There may eventually even be layer 3 dimensions as more development continues.

Smart Contracts

When a node verifies it was “spent by the actual owner” of that coin, that is just a very simple explanation. To be a valid transaction, the coins being spent actually need to satisfy the predefined rules and conditions of the bitcoin address that they are coming from. Many transactions are simply being sent from one person to another and just need to satisfy the condition of having a valid signature of the sender. However, a transaction can have many more spending conditions that open up many possibilities, thanks to Bitcoin’s smart contract language called Script. A smart contract is a contract in the form of computer code that self executes and is self-enforced to carry out a predefined action when predefined conditions are met.

Layer 1 and Layer 2

With developments that have been applied to bitcoin building on top of the capabilities of smart contracts, the blockchain has come to be known as Layer 1. Smart contracts have enabled transactions to take place on higher up layers outside of the blockchain, yet still be enforced or settled by the blockchain as necessary. The ability to facilitate transactions outside of the blockchain has enabled the ability to transact off-chain with high transaction volume, cheap or no transaction fees, fast or instant transactions, and high privacy. All without sacrificing the security or decentralization that layer 1 offers. It is layer 1 which higher up layers are built upon and used as their foundation. With higher up layers, layer 1 the blockchain is optionally used as a store of value and settlement layer. A blockchain is a very inefficient database, as it stores a historical copy of every single transaction that is shared with every node. This inefficient design is what enables decentralized auditing and verification of transactions. But to remain decentralized the blockchain must be kept as small as possible and not grow exponentially in size. Otherwise, it would be impossible for nodes to download, share, and audit the entire blockchain from the genesis block to the current block. And so it makes sense to have a majority of transactions take place off-chain if possible. Higher up layers enable this possibility.

There are multiple layer 2 solutions that exist, and even more which will be developed over time. Here are various layer 2 solutions for bitcoin transactions.

Lightning Network

The Lightning Network is a decentralized mesh network of computers (including mobile devices) that have lightning channels open with each other to relay transactions amongst each other off-chain. A lightning channel is a bitcoin smart contract where some bitcoin funds are locked up between the two owners of that channel. A lightning channel can be opened with bitcoin funds contributed by either side of the channel, or funds can be contributed by both sides in what is known as dual funded channels. When someone opens up a channel to the lightning network, a virtually unlimited number of bitcoin transactions can take place within the lifespan of that channel until either side of the channel closes it. When a lightning channel is closed, the smart contract will settle the balance of the latest transaction between the two computers. And because the computer on either side of the lightning channel may have more than one connection with the rest of the lightning network, transactions are able to travel across the connected meshnet of lightning nodes from the source to its intended destination. The lighting network truly makes Bitcoin the “internet of money”. In this way, a significant number of transactions can take place off-chain within the footprint of just two on-chain transactions. One bitcoin transaction to send bitcoin funds into a smart contract upon opening a lightning channel. Then a second transaction to close the lightning channel (if it ever is closed) and send the final settled bitcoin balance to each side. The lightning network uses onion routing to transfer bitcoin payments across the lightning network so that no single computer along the route knows the complete path of the source and destination. This gives a privacy advantage to payments done on the lightning network.

Side Chains, (Liquid)

A side chain is a layer 2 blockchain, where bitcoin funds can enter from layer 1 (main Bitcoin blockchain) into the side chain via a peg-in. Whenever bitcoin enters back into layer 1 from layer 2 this is called a peg-out. There can be more than one side chain, but I will discuss one that currently exists which is known as the Liquid sidechain by Blockstream.

On the Liquid blockchain, instead of the consensus being controlled by miners via hash rate and proof-of-work, Liquid is controlled by a federation of members. Members of the federation take turn proposing new blocks. Right now the Liquid Federation is made up of 15 members each of whom has a key. The Liquid side chain is secured by an 11-of-15 multisig setup. Because of this setup, in order for the Liquid side chain to act dishonestly, over two-thirds of the federation would have to collude. It is possible the number of federation members with control over Liquid may increase from 15 in a future upgrade.

On Liquid, the block times occur on an average of 1 minute apart, with 2 confirmations being considered safe for transactions. Liquid also features confidential transactions, which conceal the balances being sent, making chain analysis significantly harder to trace the flow of funds.

Physical Transactions

Layer 2 bitcoin transactions can also be in physical form. Specialized devices can be used for physical off-chain bitcoin transfers. Devices that currently exist to serve this function are OpenDimes. OpenDimes are tiny circuit boards with the form factor of and act as a USB drive. When plugged into a computer the bitcoin address and balance of the device can be viewed. These devices contain a security chip that generates a private key and keeps it concealed within the chip. OpenDime does not expose the private key contained within the security chip until it is unsealed. So long as the device remains sealed, the device can be passed around to different owners with confidence that only the one who has physical possession of the OpenDime, has possession of the bitcoin balance loaded onto it. No physical transaction using such devices touches the blockchain. Another advantage to physical transactions is that they can be done with no internet connection, so long as each party in the transaction has a copy of the blockchain. Another similar device that will enable physical off-chain transactions is called SatsCards, which are cards that interface with devices through NFC.

State Chains

A state chain acts similarly to physical transactions, in which the ownership of the UTXO (unconfirmed transaction output) containing funds is what’s transferred. Except instead of the transfer of the UTXO being sent physically, it is sent digitally. Think of a statechain as like a digital OpenDime.

A State Chain is defined as:

“A Bitcoin second-layer protocol in which instead of spending an old UTXO and creating a new UTXO as in a base layer transaction, ownership of coins can be transferred by directly handing over the information necessary to spend a UTXO through some other communication channel, while ensuring that the sender becomes unable to spend the UTXO themselves once the transfer is complete. Thus transferring value on Bitcoin without an on-chain transaction for every transfer of ownership.” [1]

In a state chain, the ownership of the state itself is what’s transferred between owners. A current state chain implementation is Mercury Wallet which also supports CoinSwaps to increase the privacy of bitcoins.

Summary

Higher-up layers built on top of Bitcoin enable high transaction volume without sacrificing security or scalability. Layer 2 solutions also offer privacy benefits along with transaction speeds and costs. While the Lightning Network is the primary used layer 2 at this time, there are other layer 2 solutions that complement and continue to improve bitcoin’s capabilities. Bitcoin is surely the most advanced, most secure, most decentralized digital money. Technological progression is layered, and bitcoin’s blockchain is a solid foundation for other layers built upon it.

References:
[1] https://blog.commerceblock.com/introducing-mercury-statechain-bb06c6064746

The post A Comparison of Bitcoin Layer 2 Solutions appeared first on Wasabi Wallet - Blog.

This is great because it fixes the two greatest pain points of Bitcoin: portability and fungibility. It puts Bitcoin on the path to becoming an anonymous, instant and free e-cash; the holy grail of cypherpunks: an ideal money.

If this would truly be the case we would not need to offer this grant, but unfortunately reality is more nuanced than this. Although there are things to be said about long term portability aspects of LN, much more work needs to be done on its privacy properties as was highlighted by numerous research papers [1, 2, 3, 4, 5, 6].

Grant Design & Schedule

1.11 BTC will be distributed during MAGIC Grants Lightning Network Privacy Research Grants (0.555 BTC each). This grant is made possible by pledges from zkSNACKs Ltd. (Wasabi Wallet; 1 BTC), Dan Gershony (0.1 BTC), and the Wasabi Wallet crew (0.01 BTC).

We’re looking for researchers and teams of researchers to design, (not implement), the best possible privacy-focused Lightning Network light client. The scope of research is narrowed by the assumptions explained later in this article. Applicants may apply with a team or individually. Selected individuals will be formed into another research team.

Researchers are encouraged to apply by March 14th, 2022. The Lightning Network Privacy Committee will select the researchers by March 31st, 2022. Research teams will have until the end of the year to submit their research papers.

Both teams will receive 20% of the grant value (0.111 BTC each) up-front and 80% (0.444 BTC each) after the research paper has been reviewed and accepted by the committee.

In your application, you don’t have to write your or your team’s ideas because that task is for the research period. We want to hear about your exploration plans, experience and credentials instead. If you are interested, send your application to [email protected] by March 14th, 2022.

Narrowing The Research Space

We are not going to give an overview of Lightning Network privacy. Rather, we will describe already existing solutions, narrowing down the problem space for the researchers.

Technological Advancements

We’re building software for the future and not for the past. Therefore, we should assume certain technological advancements. For example, we can assume that in the future, computers will rarely be turned off (always on) and everyone will have a reliable and unlimited Internet connection (always online).

Network And Blockchain-Level Privacy

Let’s start with an ideal on-chain privacy setup. We assume Tor [7] for communication (notably for transaction broadcasting), full nodes or client side filtering for acquiring wallet state [8] and WabiSabi [9] CoinJoins to fix on-chain privacy issues. This is so far the setup for Wasabi Wallet 2.0 [10]. Furthermore, we’ll also assume Taproot [11] utilization so LN operations won’t be immediately noticeable on the blockchain.
Although we could assume LN operations with coinjoins and indeed that’s possible with Wasabi 2.0, we won’t because we’ll solely focus on privacy and the assumption that LN operations happen before and after coinjoins will suffice. LN operations inside coinjoins are efficiency improvements.
Finally we can also omit talking about trivial things like how to use Tor circuits properly, not sending unnecessary information to trusted third parties and why not use LN node ID, an alias that is leaking information about your setup or your real world identity. Privacy developers eat such problems for breakfast, assuming they aren’t doing intermittent fasting of course.

References

• [0] How Does the Lightning Network Affect Users Privacy?
• [1] An Empirical Analysis of Privacy in the Lightning Network
• [2] A Quantitative Analysis of Security, Anonymity and Scalability for the Lightning Network
• [3] A Cryptoeconomic Traffic Analysis of Bitcoin’s Lightning Network
• [4] Security and Privacy of Lightning Network Payments with Uncertain Channel Balances
• [5] Security and Privacy of the Lightning Network
• [6] Privacy Guarantees of the Bitcoin Lightning Network
• [7] Tor Project
• [8] Network Level Privacy
• [9] WabiSabi
• [10] Wasabi Wallet 2.0 In The Finish Line — Introduction & Demo By The Lead Developers
• [11] Privacy and Scale — Everything you need to know about Bitcoin’s Taproot

The post 1.11 BTC Grant: Design a Privacy-Focused Lightning Network Wallet appeared first on Wasabi Wallet - Blog.

The conversation focused on developing the next generation of a more privacy-focused Lightning network with Istvan Seres, a researcher based in Budapest working on Wasabi as well as completing very groundbreaking research and education in the privacy aspects of the Bitcoin Lightning Network.

Here are a few things we learned from this podcast :

What is the Lightning Network

“Lightning is the one and only scalable solution for Bitcoin, which is non-custodial. So this is a super important property. So we want to scale Bitcoin in a non-custodial way, but also even maybe even more importantly at the end of the day, we want to preserve privacy. So, lightning is a layer on top of Bitcoin, which presumably provides both of these properties. So scalability and privacy and security.” ~ István Seres

Types of transactions on the bitcoin blockchain

“Lightning is a layer on top of Bitcoin. So, whenever we talk about privacy, obviously we need to see these two layers simultaneously because it just doesn’t make sense. I mean, an adversary will be present on both layers, for sure. So, you can think of your favorite three-letter agency: KGB, NSA, whatever.

So, obviously lightning requires two on-chain transactions. First, you need to open a payment channel with your peer or peers. That’s an opening channel transaction that happens on-chain. It has an on-chain footprint that costs an on chain transaction.

Once the payment channel is open, then you can send transactions back and forth between you and your peer. If this channel is depleted or your  business relationship is over, then you can say, “Okay, I had enough ice cream, I had enough pizza, I want to close this payment channel.

Also this channel closing transaction goes to the Bitcoin main net. You can have as many transactions as you want, but still, two transactions will be visible on the Bitcoin main net. But even so, whenever we talk about privacy,  I cannot stress enough that we need to consider an adversary that is present on both layers. The adversary will surely do some transaction graph analysis in the first place to assess and  see where the channel was opened and closed, as well as how it was closed. And then, the adversary is surely present also on lightning. That’s the reason why this argumentation is completely flawed, that we move off-chain so the transactions are not visible on the public ledger, on the blockchain, thus we are fine.

This is not the case because this is a permissionless financial network. Obviously, anyone can just fire up a lightning node and just listen to what’s going on, and record everything that they hear on the gossip layer, on the public channel layer. “~ István Seres

Potential attackers we should defend against

“In the on-chain case, usually we consider an ‘adversary’ who has access to the distributed ledger, to the blockchain, so obviously sees every transaction, in addition, in a more evolved case, we also assume that the adversary can hear what’s going on on the network layer. Thus, you can imagine that it’s already pretty devastating if the adversary can link, if you don’t use. For example, Tor,  then they can link your IP address with the Bitcoin transaction you just broadcasted.

This is the on-chain adversarial model so, the adversary hears everything on the network layer and also sees the public ledger. In the lightning case, we assume that the adversary is inside the network. Meaning, the adversary who wants to deanonymize us has many open payment channels with many other nodes in the network. It’s well embedded into the lightning graph and has many payment channels open with many other peers. Most likely whenever you want to route a payment, so Alice wants to route a payment to Bob then they will route it through Cecil, Dave, Eve, Frederic and so on. We can assume that some of these intermediaries are controlled by the adversary so the adversary will log that I needed to route some payments here and there.

That’s the model. Lightning Network if we think of an adversary then we think that the adversary has many open payment channels with other peers and they log every public information. The most important is that the adversary can have open payment channels with lots of nodes and has a lot of capacity.” ~István Seres

The goal of the Lightning Network

“One of the papers which recently came out and was presented in the Financial Cryptography Conference 2021 one or two weeks ago. It’s work by George Kappos, Ania Piotrowska and others  from UCL and Cornell and they identify basically four main privacy guarantees we want to achieve in the lightning network. First obviously, if you have a private channel, then in lightning, you can have public channels and private channels. So to exemplify, if Alice and Bob open a public channel, then it’s fine because all the networks can use this channel for routing payments. But if they decide not to disclose the details of this payment channel, then this is classified as a private channel and then no one else should be able to use this payment channel for routing unless they know the existence of this private payment channel. Some people say that approximately even 30% of the channels on the lightning network currently are private channels.

Therefore, the first privacy guarantee we want is that, if we have a private channel between Alice and Bob, then Alison, Bob wants this private channel to be secret. So, not even the existence of this private channel should be known to anyone.

The second privacy guarantee we want is third party balance secrecy.
In the lightning network, each payment channel’s capacity is public knowledge. Hence, we cannot hide that. If there’s a payment channel between Alice and Bob, then the capacity of it is known. The capacity of the payment channel is basically the sum of the individual balances of Alice and Bob, of the two parties corresponding to the payment channel and obviously, this information is known to Alice and Bob. But this privacy requirement dictates or this is at least our desire, that we want the individual balances themselves to be hidden. In short, Alice and Bob know their individual balances in the payment channel, but we want this information to be hidden from other parties.

The third Privacy property we achieve on the lightning network is on path relationship anonymity. Suppose Alice sends some payment to Bob and they route this payment through many intermediary nodes like Carol, Dave, Eve, Fred, whatever. What we want is, for example, if we just pick a random intermediary, Dave, then Dave should not be able to tell who is the sender and the receiver of this payment, right? That would be pretty devastating. With that, Dave should not be able to tell whether Carol is the sender of this transaction or Alice or one of Carol’s neighbors and similarly, also Dave should not be able to tell whether Eve is the recipient of the payment or Bob.

Lightning uses onion routing. Every routing node only knows the predecessor and the subsequent nodes where they need to route the payment to. Obviously if there’s one hop then we cannot really do anything because then it’s already obvious who is the sender and that receiver. But also the length of the payment path is unknown to intermediaries. Even if the payment has just one hop the payment router cannot know whether the payment has one or two or three hops, whether he or she the only routing. This is on, on path relationship anonymity.

And the fourth and the last one, according to this paper, is off-path payment privacy. For instance, let’s say I am an observer. I have many payment channels to my friends, and I should not be able to tell what’s going on along payments that do not involve me as an intermediary. If Alice sends a payment to Bob okay, there are some intermediaries, Carol, Dave and all, all these nice guys. But still, I should not be able to tell how much money went through along those payment routes, or even just the existence that the payment occurred along some routes. Again, these are the four privacy guarantees according to this paper so hiding private channels, second, third party balance secrecy, third anonymity, fourth payments, privacy.”~István Seres

Of course, the guys delved deeper into this topic and discussed each of these aspects in tandem, but you’d have to listen to the entire podcast to learn more about the lightning network. Don’t just take my word for it.

Listen to the full episode here:

The post Podcast Review: The Privacy Guarantees of the Lightning Network appeared first on Wasabi Wallet - Blog.