Lightning VS Raiden #1: can watchtowers and monitoring services scale?
Lightning and Raiden series:
- Differences between LN watchtowers and RDN monitoring services.
- Solutions to scaling problems and their trade-offs.
- Accountability and viable business models.
Disclosure: I own BTC, ETH, BCH, and other coins, but my portfolio is heavily diversified, so I don’t have financial incentives to shill for any particular coin. I hope to see many projects with different scaling solutions that will compete with each other, while users will have a freedom to use a payment solution of their choice. If you belong to a different camp, that’s fine, I have nothing personal against you and we can still collaborate. This article is brought to you by a privacy-oriented peer-to-peer marketplace LocalCryptos.
Intro
Firstly, I’d like to say big thanks to LN developers: Christian “Snyke” Decker and Conner “bitconner” Fromknecht, and to Raiden team, especially to Lefteris “LefterisJP“ Karapetsas, Christian Bader, and Dominik1999 for answering my daily questions about watchtowers and monitoring services (LN thread, RDN thread, RDN github issue). Without their help, this article would be less detailed.
Secondly, Raiden’s “monitoring services” is not the final name, and it can be changed in the future, so in this article we will use a word “watchtowers” to refer to both Lightning’s and Raiden’s implementations, unless specified otherwise (e.g., “LN watchtowers” or “RDN monitoring services”).
Thirdly, watchtowers are a huge topic, so I’ve decided to split it into a series of articles. In the first article, we will discuss why watchtowers are essential for scaling, how they operate, what the differences are between LN and RDN implementations. We’ll talk about two main categories of watchtowers, their operating (and capital) costs, look at scaling problems, and slightly touch a few solutions and their trade-offs.
Fourthly, you don’t have to agree with everything written here, while still benefit from reading this article, like I’m often disagree with conclusions made by StopAndDecrypt, but I find his analyses interesting and useful.
Lastly, why did I keep silent for more than 6 months after previous article?
Well, I didn’t have much motivation, because the LN community was sensitive to healthy criticism, so I got exposure mostly among on-chain scaling fans, but they are less interested in off-chain scaling solutions at the moment.
Look at The Tor Project for a great example. Despite being so good Tor yells at users that using Tor is not enough.
The Tor project is indeed a good example of a mature community. Authors of Tor manual often say that using Tor won’t guarantee 100% anonymity, and they refer to papers that describe different attacks that can de-anonymize users. Hopefully, off-chain scaling community will also embrace critics and white hackers.
Default settings matter
You can achieve a high level of privacy by using products such as Protonmail, Tails, Whonix, VPN, Tor, I2P, etc. But how many people actually use all these tools in their daily life? Less than 1% of all internet users? So what makes you think that people will use tools for private transactions, unless they are set by default? Most people will prefer convenience and cash-backs over privacy.
E.g., Ethereum wallets that don’t have to deal with tokens or smart contracts can generate unique addresses for each new ETH transaction, but most of them don’t, because that’s not a default behavior. On the Bitcoin it’s a default setting, which improves privacy.
BTW, LocalCryptos generates new ETH address for each trade, unless user chooses to recycle addresses.
I believe that cryptocurrencies should provide a high level or security, privacy, and good UX out of the box, because most laymen will just buy cryptos with credit cards via centralized platforms, use mobile SPV wallets, connect to one big “free” hub, route all their transactions via that hub, and use most popular watchtower available.
No scaling without watchtowers
At the current state, Lightning and Raiden networks cannot scale beyond tech-savvy crypto enthusiasts, because going offline introduces security risks of losing money (i.e. if a counter-party decides to cheat by closing an off-chain payment channel with invalid state).
A solution like “ask your techy friend to watch for your channels” won’t work on a global scale because LN and RDN are competing with other altcoins and existing centralized payment solutions with instant transactions, often zero fees, and occasional cash-backs (Visa, Alipay, WeChat, PayTM, etc.).
The proposed solution is to outsource to dedicated 3rd party watchtowers an ability to watch the blockchain 24/7 on behalf of their clients, and broadcast penalty transactions if needed.
How watchtowers operate
Lightning Network implementation
When Alice’s payment channel state gets updated (Bob transfers 0.1 BTC to Alice), Alice sends to a LN watchtower encrypted signatures authorizing the movement of all channel’s funds back to Alice. The package sent by Alice has no info about state’s balances, so Alice’s privacy should be safe (disputable), unless the channel will be closed unilaterally.
Basically, Alice is pre-signing a transaction of all channel’s funds back to her, so she can be offline at the time the breach happens. Each sent package also contains a “hint” about how to find potential breaching on-chain transaction, so the LN watchtower constantly watches blockchain by checking all new transactions against its hash table of “hints”.
Bob decides to cheat Alice by closing LN channel unilaterally with old state (i.e. a state before he sent 0.1 BTC to Alice). When the LN watchtower spots the breaching transaction, it’s able to decrypt the signatures from Alice’s package and reconstruct the penalty transaction which moves all funds back to Alice.
Since a channel was closed unilaterally, there is a time-lock on funds, so LN watchtower has some time to react, before Bob would be able to spend the “stolen” funds.
Raiden implementation
RDN (Raiden Network) monitoring services is still a research area, so let’s look at the latest proposed design.
Alice deposits some tokens to a smart contract, which can be retrieved by a RDN monitoring service in case of successful defeat of Bob’s attack.
When Alice’s payment channel state gets updated (Bob transfers 0.1 ETH to Alice), Alice publishes balance proofs including the token network, channel ID, a nonce and a hash of transferred amount into a public chat room. The sent message has no information about state’s balances (only a hash), so Alice’s privacy should be preserved (very disputable).
Since each sent message contains a channel ID, monitoring services can listen to ‘channel close’ events regarding this particular channel.
Bob decided to cheat Alice by closing the RDN channel unilaterally with old state, in which he didn’t send 0.1 ETH to Alice. Once the channel is set to be closed (within the challenge period), the RDN monitoring service will stop a settlement because the balance proof it holds for Alice is different from the one that Bob used for closing a channel (i.e., Bob’s balance proof has a lower nonce).
Alice comes back online and closes a channel with the latest balance proof.
Key differences of Raiden’s approach:
- Alice has to deposit some tokens to a smart contract, which can later be used to pay for the RDN monitoring service.
- RDM monitoring service knows which exact channel it watches and can link together all state updates made by the same user (on-chain address).
- RDN monitoring services cannot reconstruct penalty transactions, so Alice has to come online to close the channel with the latest balance proof.
- Cheater is not risking to lose any additional funds as a penalty.
Challenges:
Even though Lightning’s and Raiden’s implementations have slightly different designs, they face similar challenges:
- Watchtowers have to cover operating costs, which most likely will increase quadratically for privacy-oriented implementations (read below).
- How much users should pay for watchtower’s services, and how will payments be made?
- How to preserve privacy while paying somebody to watch all your economic activities?
- How to keep watchtowers accountable without damaging privacy or UX?
In this article we will focus on operating costs and slightly touch a few other topics. Let’s start with describing two main categories of watchtowers, because they will have very different operating costs.
Side note: when a company needs more storage for its data, it can either invest in new data storage devices (capital expense or CAPEX) or lease space in a data center (operational expense or OPEX), so for simplicity we will refer to both operational and capital expenses as “operating costs”.
This article is brought to you by a privacy-oriented peer-to-peer self-custodial end-to-end encrypted marketplace LocalCryptos, where you can buy & sell cryptocurrencies for fiat money. To start trading, create a new password-protected account or log in with your favorite wallet such as Ledger, MetaMask, or mobile apps like imToken.
Business VS Privacy
There are different designs and things might change down the road, but most proposed implementations fall into two main categories: let’s call them Business-oriented and Privacy-oriented.
Lightning’s current implementation leans towards the privacy-oriented model, while proposed Raiden’s design follows the business-oriented model.
1. Business-oriented model
The business-oriented model implies that a watchtower can link state updates made by the same person (channel, account, KYC, etc.).
There are two different scenarios:
- Either a watchtower knows which exactly channel it watches, so it can link all received state updates to that particular channel/account, e.g.:
- Otherwise a watchtower doesn’t know which particular channel it watches, but it can link together all state updates that belong to the same channel or account, e.g.:
Hence it can potentially discover which channel it was watching in case of an unilateral close, and thus link all previous states updates to that channel.
The business-oriented model allows watchtowers to significantly reduce operating costs by truncating their databases of state updates, which is a deal-breaker when it comes to surviving as a business (see problems of privacy-oriented models below).
Additionally, the ability to link state updates to a certain channel or person will allow watchtowers to introduce account-based system to monetize their services, which is the most viable business model, but we will talk about that later in the dedicated article about watchtower’s business models.
Watchtowers will be able to truncate databases with different methods.
1.) RDN monitoring services are required to store only latest state updates, so they can delete all old state updates.
2.) LN watchtowers will be able to store only latest state updates for each channel after eltoo will be implemented, which requires BIP 118 activation, which might be deployed together with schnorr, since both require a seguito script bump, according to Christian Decker.
Eltoo allows users to only store the latest state and prove that it’s the later state without providing the entire state history, so LN watchtowers can delete all previous state updates, but only if they know that those state updates belong to the same channel.
Side note: BIP 118 (SIGHHASH_NOINPUT) won’t directly damage privacy, but it will allow eltoo, which will financially incentivize watchtowers to link state updates together and shrink their ever growing databases by deleting old states, because that’s a more viable business modal. There still be privacy-oriented watchtowers that won’t link state updates together, but most laymen will use cheapest watchtowers with low privacy, which store only latest state updates. So I would double-think if eltoo is that “uncontroversial” as most people say. We should always think about long-term economic effects of each protocol change.
Downsides
The problem with business-oriented model is that it opens a door to massive financial surveillance, even though watchtowers won’t know exact balances of updated states. Here are a few examples of how watchtowers can use all the collected data against their users:
- Collaborate with other watchtowers, financial institutions, and merchants to perform traffic analysis to determine a final destination of a transaction, even if it was routed with multiple hops.
- Analyze transaction frequency to determine user’s economic activity and wherever they are an end node or a routing node.
- Analyze the timing of each transaction (most laymen will be end nodes) to determine user’s approximate location, his habits/time-schedule, and potentially identify a user if he has a very unique fingerprint, or often changes his timezone (changing a timezone just 2–3 times will be enough to identify a user, if he uses his ID for traveling: airplanes, trains, hotels, crossing borders, etc.).
- And, of course, link all previous state updates to a certain channel in Raiden’s implementation, or in case of a unilateral close in Lightning’s implementation.
- Raiden’s pathfinding helpers with a current view of channel capacity coupled with business-oriented watchtowers will allow global adversaries to determine exact values and destinations of most transactions.
It’s possible to improve privacy with features like fuzz transaction time or rotate state updates between different watchtowers, but they come with certain trade-offs, which we will discuss in the next article.
2. Privacy-oriented model
Lightning’s approach might change after eltoo, but the current design of LN watchtowers has a privacy-oriented approach, meaning that watchtowers cannot link all previous state updates together (until they try to monetize their services with account-based system).
E.g., a watchtower can get 10 new state updates from 1 channel, but it will not know whether those 10 state updates came from 1 channel or from 10 different channels.
Even if there was unilateral close and watchtower was able to decrypt the received package, it will only know the exact channel (two on-chain addresses) to which the latest state belongs, but watchtower will not know to which channel/account other 9 state updates belong to.
So far so good, right?
Not so fast! Firstly, the inability to link state updates to a certain account or channel will make the monetization process much harder, because an account-based system is the most viable business model for watchtowers, however we will talk about that in the dedicated article about watchtower’s business models.
Secondly, the inability to link state updates together to truncate the database will force a watchtower to store all previous state updates that it has ever received, except for those that have been closed unilaterally (a tiny amount), and that’s what we are going to talk about now.
Side note: there are some workarounds to delete old states, but they all have serious issues, which we will discuss in the next article.
Operating costs
Privacy-oriented watchtowers have to be online 24/7 with a decant bandwidth, store lots of data, and perform computations — insert new state updates into databases and check all on-chain transactions against their databases of previous state updates, in order to find a breaching transaction.
Daniel Larimer (known for EOS, Steemit, BitShares) discussing scalability with Satoshi Nakamoto in 2010:
I am convinced that bandwidth, disk space, and computation time necessary to distribute and “finalize” a transaction will be prohibitively expensive for micro-payments.
8 years later we still didn’t find any good solution to this problem, so many communities decided not to “distribute” transactions across the whole network (LN on BTC, Raiden and Sharding on ETH, NANO, etc.).
However, the same problem still apply to privacy-oriented watchtowers, because they will have a quadratic growth of operating requirements.
Operating requirements
Let’s brake our problem down:
- bandwidth (receive new state updates)
- disk space (store all state updates)
- computation time (check new on-chain blocks for breaching transactions)
Bandwidth
Bandwidth requirements will be fairly low, because watchtowers don’t need to serve the received data (state updates) back to clients, nor distribute across the network of other watchtowers/nodes.
Here is a nice article (if you can stand aggressive narrative style) by StopAndDecrypt explaining that bandwidth growth rates are slower than Moore’s Law suggests, so low bandwidth requirements are good news for watchtowers.
Side note: in certain implementations watchtowers might send some data back to users for accountability reasons, thus increasing bandwidth burden.
Computation time
Watchtowers have to insert all received “hints” into hash table and check all transactions in new on-chain blocks against that hash table in order to find a breaching transaction and punish the cheater by reconstructing and broadcasting a penalty transaction.
According to Conner Fromknecht:
Hash lookups are O(1) regardless of the map’s size, and can be done on commodity hardware. Really large datasets can shard the keyspace on multiple machines.
In simple words, O(1) means that the time to access something is independent of the number of items in the collection, and you will spend a constant amount of time to find a matching hash in a table of 1 million or 1 billion hashes, so computation burden shouldn’t be a bottleneck.
Sounds a bit weird for non-techy person, but think about the library catalogs, which you can use to easily find a necessary book regardless of library’s size.
Another problem is inserting new data, because some collections can be O(1) to access, but O(n) to insert. According to Conner Fromknecht, it’s neither a problem:
Insertion is O(1) amortized, just like an in-memory hash table. Doesn’t need to be ordered, just bucketed by key.
I don’t have enough competence to argue with that, so I’ll take it as granted. If you disagree, feel free to participate in this thread and I will edit the article accordingly.
Disk space
Watchtowers have to store all received data (state updates) in order to check new on-chain blocks for breaching transactions, and here things will become a bit messy.
1. Quadratic growth problem
Let’s look at an example to better understand the problem.
Eve decided to become a privacy-oriented watchtower. Let’s assume that Eve will get 10 new users in the beginning of each day, and economic activity of average user will be 10 transactions per day.
Here are the results at the end of each day:
Day 1: 10 users, 100 daily TXs, and 100 state updates stored (0+100).
Day 2: 20 users, 200 daily TXs, and 300 state updates stored (100+200).
Day 3: 30 users, 300 daily TXs, and 600 state updates stored (300+300).
Day 4: 40 users, 400 daily TXs, and 1,000 state updates stored (600+400).
Day 5: 50 users, 500 daily TXs, and 1,500 state updates stored (1K+500).
Even though Eve’s user base and daily transactions (bandwidth) were increasing linearly, the amount of stored states updates (disk space) was increasing quadratically. Of course, the amount of stored data needed is tiny, but quadratic growth can become messy very fast.
Conner Fromknecht argued that:
Clients prepay the tower for a certain number of updates. If usage is exponential then so is the tower’s revenue.
That’s correct; storing lots of data is not a big problem for a business that monetizes its service. However, it will require a complex subscription-based system with low privacy and other issues, which we will talk about in the dedicated article about different business models.
Here I will remind once again that the current LN protocol cannot scale beyond tech-savvy crypto enthusiasts without 3rd party watchtowers, so quadratic growth has to be solved before off-chain scaling via payment channels can be globally adopted.
In the end of the day, the rapid growth of a block size was the reason for a chain split, and for LN to be pushed as a main scaling solution in opposite to on-chain scaling via block size increase.
2. Linear growth problem
Good news is that, unlike nodes on ETH/BCH chains, individual privacy-oriented watchtowers will actually have an option to replace a quadratic growth with linear growth by limiting the maximum amount of its clients, but that will introduce new problems.
First of all, this solution requires account-based system, which destroys the whole purpose of privacy-oriented approach, since watchtowers will be able to associate transactions with certain accounts.
Secondly, even though the growth will be linear, watchtower’s operating costs will constantly increase, while income will stay at the same level, unless they will charge their clients more and more money.
Side note: another approach I can think of, is to limit daily incoming data, so users have to ping all watchtowers, until they find the one that is capable of receiving the new state update. This approach is more privacy-friendly, but I can’t imagine any viable business model without serious trade-offs. Anyway, this approach will also face a problem of constantly increasing operating costs.
E.g., Watchtower Eve limited user base to 10,000.
Let’s assume that economic activity will stay at the same level of 10 TXs/user per day, so the bandwidth requirements will stay at the same level of 100,000 TXs per day.
As we can see, 100,000 new transactions each day will constantly increase disk space requirements, because watchtower will need to store more state updates.
The problem of limiting user base is that operating costs of privacy-oriented watchtower Eve will still constantly increase, while the user base will stay at the same level of 10,000 users, so watchtower will have to charge more money from each user to cover its growing operating costs.
I will remind that Lightning Network is a scaling solution, so if LN will be widely adopted, the biggest privacy-oriented watchtowers will have hundreds of millions of users, billions of daily transactions, and trillions of state updates in databases.
Some real numbers
Let’s throw some numbers, using Lightning’s privacy-oriented implementation of watchtowers as an example. The blobs in the initial version are the size of a tweet, but watchtowers should have at least 1–2 backups, since it’s not just kitten photos, so let’s assume that one state update will require 1kB of storage capacity. One billion of state updates is 1TB of data, and one trillion is 1PB.
- Daily state updates per user:
How many daily state updates there will be per user? This is a tough question, but I would estimate it at around 10 to 100 daily state updates, without streaming money, because high-frequency micro-transactions would hardly work with privacy-oriented watchtower’s designs.
It’s important to remember that each LN transaction has two parties: sender and receiver, so each transaction will require at least 2 packages to be sent to watchtowers.
In a very centralized hub-and-spoke network, most payments will be routed via big hubs, so there will be ~2-4 packages per each transaction, depending on whether hubs will use watchtowers’ services, or their own solutions.
In a very decentralized network with many small routing hubs and a high number of average hops, there might be more than 20 packages per each transaction.
Let’s sum it up. User has to send to a watchtower 1 state update after receiving a payment, 2 state updates after routing a payment, and 1 state update after sending a payment, so now you understand, why the average number of state updates per user can go to as high as 100 per day in a decentralized network.
Side note: after implementing Atomic Multi-Path Payments on LN and Multiple Pending Transfers on Raiden, the average number of state updates per user might increase even higher, since some big payments will be routed through multiple routing nodes and thus generate even more state updates and more packages sent to watchtowers.
- Watchtower’s average user base:
How many users will average watchtower have? That’s a very hard question as well, but since Lightning Network is a scaling solution, we have to talk big numbers. I would say that even an average watchtower will have at least tens of millions of users and store hundreds of billions of state updates, if there will be a wide-spread adoption.
Businesses tend to monopolize and centralize, while average users often choose most popular options, so top social media platforms have billions of users, even though there are dozens of other solutions with more privacy, better security, and less or even no ads. It would be fair to assume that the most popular LN watchtowers will have at least hundreds of millions of users, or even billions.
- A few examples:
10 million of users with 10 daily state updates is 36TB of data annually.
100 million of users with 100 daily state updates is 3.6PB of data annually.
Looks not so bad. That’s a reasonable amount of data, and most social media apps store much more data, right? Yes, but they also spy on you and serve you ads to cover operating costs, which we don’t want watchtowers to do.
Don’t get me wrong, businesses can handle these amounts of data (and don’t forget Moore’s Law), but running a watchtower will be much more expensive, than e.g. running a full node, and operating costs will constantly increase, so watchtowers will have to monetize their services with a good business model, and that’s what we will talk about in the third article, trying to understand if it’s possible to preserve privacy, while paying to somebody for monitoring all your economic activities, and at the same time keep a balance between UX, accountability, and security.
Big side note about other companies
What other companies do, when their operating costs constantly increase, while user base stays at the same level?
Let’s take Facebook as an example, which has already hit a ceiling in some regions, so inflow of new users is very low, while operating costs are constantly increasing, because the company has to pay for huge data centers to store more and more gigabytes of data from each user, and to fulfill an ever growing demand for new features, which constantly increases a codebase and makes it more expensive to maintain.
The company can try to limit its operating costs by not developing new features, or by deleting old videos, photos, chat logs, but then users will move to other social media platforms, so the company has to increase its revenue to survive on the market.
Here are a few things that social media platforms can do to increase revenue:
- insert ads in any empty space of your screen,
- change algorithm to insert ads right into your feed,
- push individual users to pay money for exposure of their posts,
- increase ads costs, forcing companies to spend more money on marketing, so end users will eventually pay more for the same products they buy,
- collect and sell your data to 3rd parties,
- introduce paid subscriptions.
Now you understand why using Facebook in 2018 is much more “expensive”, than it was in 2008.
Did you ever think why some modern social media apps intentionally don’t store old content, or most file-storage apps and email service providers limit the maximum capacity of your stored data? Unfortunately, that won’t work with privacy-oriented watchtowers, because your counter-party can cheat with any of previous invalid states, so watchtowers have to store all of them.
Or are there any ways to overcome this problem?
…
In the second article we will take a look at different solutions to delete old state updates and improve privacy for both business-oriented and privacy-oriented watchtowers, as well as their trade-offs. We will also talk about complex hybrid models that try to combine business & privacy approaches, and see how viable they are.
In the third article we will talk about accountability and viable watchtowers’ business models and how they will monetize their services, because there things will get a bit messy.
TL;DR
- Watchtowers and monitoring services are essential for LN and RDN scaling, because they secure user’s funds when user is offline.
- Watchtowers and monitoring services will have operating costs, which they’ll need to cover.
- Two different categories of WTs: business-oriented and privacy-oriented.
- Raiden monitoring services’ design leans to business-oriented approach.
- Business-oriented WTs can link state updates to a certain channel/person, which is a major privacy issue.
- Business-oriented WTs are more viable and can scale easier.
- Lightning watchtowers currently fit into privacy-oriented category.
- Privacy-oriented WTs cannot link state updates to a certain channel, or account, unless there was an unilateral close, so privacy is preserved.
- Even in case of unilateral close, privacy-oriented WTs will be able to link only one state update to a certain channel.
- Privacy-oriented WTs will have higher operating costs and less options to monetize their services, so scaling is in question.
- Bandwidth and computational burden should not become a bottleneck.
- Storage capacity requirements will increase quadratically for privacy-oriented watchtowers.
- It’s possible to replace quadratic growth with linear growth by limiting the maximum amount of clients.
- Limiting user base requires account-based system with low privacy.
- Social media apps are good at scaling, but they spy on users and serve ads.
Challenge
If you’d like to see more candid articles about watchtowers, hubs, Lightning and Raiden networks, please share this article or donate here, that will surely speed up the process. I’ll share results in the next article, so we will see which community is more interested in supporting a research about off-chain scaling solutions.
Here are some stats for the previous LN article:
- Donations: $7 in BCH tips with a highest donation from mrcrypto2
- Post on /r/Bitcoin (off-chain scaling) was downvoted, so got 0 points
- Post on /r/btc (on-chain scaling) got 44 points with 80% upvotes
- @bitcoin (on-chain scaling) shared the article and got 105 retweets
One can argue that the previous LN article got more exposure among on-chain scaling supporters because it fit into their agenda. That’s true, however, article had lots of useful information that could help in Lightning Network development.
Here is a good example how NEO community responded with 96% upvotes to a very critical post, which eventually got 618 points. I hope off-chain scaling community will also start to appreciate criticism, because neglecting problems is not a good way to succeed.
Disclaimer: I am not a licensed financial advisor, and this article is not a financial advice. The information presented here is for educational purpose only, it represents my personal opinion, and is not purported to be fact. Cryptocurrencies are very volatile and can move quickly in any direction. I’m not responsible, directly or indirectly, for any damage or loss caused or alleged to be caused by or in connection with the use of or reliance on any content, goods, services or companies mentioned in this article. Seek a duly licensed professional for an investment advice.
If you’ve decided to invest in crypto assets, consider reading this article to avoid most common mistakes that amateur investors make.
- Help inform people about LN watchtowers and RDN monitoring services by 👏 (you can clap up to 50 times).
- I only write quality content about cryptocurrencies and blockchain. Follow me on medium, twitter, or mastodon, and you won’t regret that. 👍
- Send me a direct message on twitter or linkedin if you want me to help improve your project, white paper, website; or sponsor my next articles.
- Use the most secure, private and intuitive way to swap cryptos with others for your local currency — LocalCryptos.
