Lightning VS Raiden #2: can we solve privacy and scalability problems of watchtowers and monitoring services?
In this article we will discuss different methods to scale watchtowers and ameliorate privacy of LN and RDN.
Lightning and Raiden series:
- Differences between LN watchtowers and RDN monitoring services.
- Solutions to scaling problems and their trade-offs (current).
- Accountability and viable business models.
Other languages: 简体中文
Disclosure: I own BTC, ETH, BCH, RDN 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 the community, because this time people were open to a discussion, and the previous article was shown on the front pages of 4 subreddits with a few nice discussions. Really appreciate that!
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, if you’re new to a concept of watchtowers, then I’d suggest to read the previous article in which we’ve discussed why watchtowers are essential for off-chain scaling, how they operate, what the differences are between LN and RDN implementations, described two main categories of watchtowers, their operating (and capital) costs, and outlined major scaling challenges.
Fourthly, we will use terms:
- business-oriented to refer to watchtowers that can link together all state updates made by the same channel or account
- privacy-oriented to refer to watchtowers that cannot link together state updates made by the same channel or account
For more details about these models, see the previous article.
Side note: some people have asked why the wording is “business VS privacy”. Well, businesses try to increase their revenues and survive the competition. Watchtowers that don’t care about privacy have more ways to increase their incomes and decrease expenses, which makes them more viable.
Problems
There are 3 major problems of watchtowers that community has to solve before wide adoption:
- Privacy
- Scalability
- Accountability
In this article, we will take a look at different solutions to privacy and scalability problems, and discuss their drawbacks.
As always, you don’t have to agree with everything written here, while still benefit from reading this article, and please feel free to participate in the discussion if you have something to say.
Privacy
I strongly believe that watchtowers are a bottleneck of Lightning and Raiden networks’ privacy, because if watchtowers will be able to link transactions together, then there is very little value in any other privacy features.
The common argument is that off-chain is still faster, cheaper and more private than on-chain. It’s hard to achieve a global adoption with this kind of mindset, because the actual question should be “is it better than Visa, AliPay, WeChat, PayTM, or will it ever be and when?”
Additionally, off-chain transactions are arguably not more private, because a user can use a new on-chain address for each on-chain transaction, which is a default feature of many wallets and services like LocalCryptos, while off-chain transactions will be linked to just one on-chain address/channel.
Let’s look at some possible workarounds to slightly improve privacy.
1. Fuzz transaction time
Suits: LN & RDN
A user can obfuscate transaction’s time by introducing some random delay (e.g. few seconds or minutes) before sending a state update to a watchtower. That will increase a cost of a traffic analysis.
However, this won’t work if a user’s counter-party sends channel updates to his watchtower without any delay, because most likely there will be big network of obedient watchtowers that will participate in a massive financial surveillance in order to comply with local and international laws, same like banks and other financial institutions have to reveal all the details about their clients to authorities. Forcing a certain delay on a protocol level might help mitigate this issue, but it will be quite a bizarre move.
Reminder: in business-oriented designs, watchtowers know which channel they are watching, so they know all parties of each channel.
Here is an illustration of Bob sending his state updates without a delay, while Alice is trying to obfuscate a transaction time:
Additionally, delaying state update by longer time (e.g. few hours) is a very poor UX, because in order to secure the transaction, a user has to stay online until state update is sent and a user receives a confirmation. As a result, it will still be fairly easy to determine a user’s timezone, and identify a user if he has a unique fingerprint or often changes a timezone.
Side note: fuzzing a transaction time can increase privacy of privacy-oriented watchtowers that cannot link together state updates made by the same channel or account. However, it’s still unclear if privacy-oriented watchtowers can scale due to ever growing operating requirements and limited monetization mechanisms.
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.
2. Rotate state updates between different watchtowers
Suits: LN
A user can rotate multiple watchtowers by randomly sending his new states updates to one of them after each off-chain transaction.
In general, it’s a nice feature, but it won’t significantly increase privacy in the modern world, because we should treat multiple watchtowers as one big entity that watches all network activities.
As already mentioned above, there most likely be a big network of obedient watchtowers that will participate in a massive financial surveillance, as banks do. Some watchtowers can start as independent entities, but will eventually comply, as it recently happened to ShapeShift and other crypto exchanges.
Additionally, a watchtowers rotation decreases UX, because user has to find and somehow pay to multiple watchtowers. Most laymen will use just one popular watchtower for convenience, so a rotation is a tool for a small percentage of geeks, because default settings matter.
We can force using multiple watchtowers on a protocol level, but then big watchtowers will just provide a service to fake a usage of multiple watchtowers.
Note that this solution won’t work in current RDN’s design because users send state updates to all registered monitoring services via public chat room.
There are other approaches that also use multiple watchtowers (like Celer Network), but we will talk about them a bit later.
3. Bundle together state updates from different users
Suits: LN (if eltoo, then limited benefits) & RDN (limited benefits)
Another approach is to utilize the concept of coin-join services.
CoinJoin is a trustless method for combining multiple Bitcoin payments from multiple spenders into a single transaction to make it more difficult for outside parties to determine which spender paid which recipient or recipients. (wiki)
Similar to coin-join services, state updates from different users can be theoretically bundled together in a trustless way and then be sent to a watchtower in one chunk of data.
Challenges:
- It’s not clear how a trustless implementation can look like. Most likely a user will still have to trust some other party, which can be coerced to collude.
- The implementation might have a poor UX if a user will have to stay online until he gets a confirmation that a state update was successfully received by a watchtower.
- This feature should be a default setting, otherwise laymen won’t use it.
- In business-oriented designs (e.g., current RDN’s approach), only transaction time will be obfuscated, but not the owner of the state update.
4. Routing of state updates
Suits: LN (if eltoo, then limited benefits) & RDN (limited benefits)
Another very interesting approach is to send state updates to watchtowers via hops similar to how routing works.
However, there are many challenges:
- Alice should be able to send an encrypted package through Bob and Carol to a watchtower (using Tor will mask only IP, so it’s not enough). Ideally, all state updates should look like they belong to the last hop (Carol).
- Carol should somehow be able to pay for a watchtower’s service on behalf of Alice for the Alice’s state update, if watchtowers will charge for stored or received state updates (more about business models in the next article).
- Bob and Carol should be able to receive certain fees for transferring Alice’s data in order to incentivize them to provide these services.
- Alice should get a confirmation that the state update has been received by a watchtower.
- This kind of routing should be trustless, so implementation is very unclear.
- This feature should be a default setting, otherwise laymen won’t use it.
- Even if implemented properly, it will decrease UX, increase attack vectors, and add more middle-men that charge fees.
- Business-oriented watchtowers that know which exact channel is being monitored (e.g., current RDN’s approach) will still know the real owner of the state update, so only transaction time will be obfuscated.
5. Create lots of noise (fake routing)
Suits: LN & RDN (without PFS)
User can try to disguise his real transactions by sending lots of fake penny transactions or by sending fake state updates to watchtowers, imitating high economic activity or routing.
Problems:
- Even more state updates to be stored by privacy-oriented watchtowers, so scaling is in question. Watchtowers can try to charge users for stored state updates with some privacy-oriented method (which one?), but then laymen won’t use this privacy feature, because it’ll cost extra money.
- Creating lots of fake transactions will significantly increase a bandwidth burden so scaling is in question.
- If a counter-party uses path-finding service (PFS), then there is no sense in faking transactions, because PFS will know which transactions were real.
So are there any real use-cases?
Well, privacy of business-oriented watchtowers (RDN or eltoo) can be improved by forcing users to send small-amount noise-transactions on a protocol level, without a significant growth of data storage requirements, because watchtowers will be able to store only the latest state updates. Bandwidth burden is still an issue though, and a usage of path-finding services by a counter-party will eliminate any benefits of creating a noise.
Thoughts on privacy features
These is no ultimate solution so far, and all methods described above have their drawbacks and act more as bonus features to improve privacy, if we already have a high level of privacy on a base level. However, if on a base level watchtowers will be able to link together all state updates made by the same channel or account, then there is not much we can do to significantly improve privacy.
Scalability
If LN won’t become a highly centralized hub-and-spoke network, then each transaction will have multiple hops, so multiple nodes will send state updates to watchtowers for each single transaction.
The amount of stored data will increase quadratically for privacy-oriented watchtowers that cannot link together state updates made by the same channel or account.
Let’s look at different solutions and their trade-offs.
1. Store only the latest state updates (business-oriented model)
Suits: LN (eltoo) & RDN (current implementation)
The simplest solution is to link together all state updates that were made by the same channel or account and store only the latest updates (balance proofs). We called it “business-oriented approach” and you can read about it in more details in the previous article.
Things might change down the road, but current design of RDN monitoring services follows this approach, and LN watchtowers will be financially incentivized to switch to this model 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.
A business-oriented model is easier to scale, because it allows watchtowers to get rid of huge databases and focus on increasing bandwidth capacity. Additionally, watchtowers will be able to introduce an account-based system, which is the most viable business model.
Unfortunately, this approach implies a very low level of privacy, because watchtowers will be able to associate all transactions with certain channels, addresses, paid accounts, etc. Basically, that’s similar to how most fiat-based centralized payment systems operate.
2. Don’t send state updates that allocate most funds to a user
Suits: LN & RDN
A user doesn’t need to send to a watchtower state updates that allocate all or most funds to himself because his counter-party either won’t be able to steal any money from a user with these states, or a counter-party will have a very bad risk/reward ratio of cheating, e.g. risk $90 to get $10, so it’s too expensive for a user to pay to a watchtower for storing these state updates, since a risk of losing any money is very low.
This approach will help trim databases of stored states updates by 5–20%, but it will introduce certain security risks and over-complexify UX, since a user should be able to adjust the settings for security reasons. Additionally, laymen might mess up the settings in order to save money, while seriously decreasing security.
Extra: each user still has to send to a watchtower at least some state updates that allocate most funds to himself to prevent situations where cheating success is close to 100%, since nobody cares about state updates that allocate most funds to themselves (game theory).
3. Delete states updates after a certain period of time (e.g. 1 year)
Suits: LN (not eltoo)
Even after a channel has been closed, privacy-oriented watchtowers still have to store all state updates received from the owner of that channel, which is completely impractical.
One of the solutions is that watchtowers will delete old state updates (e.g., older than 1 year), and clients will be responsible for resending updates for channels that are still open.
Unfortunately, this solution will delete only state updates of channels that were already closed, so it won’t significantly decrease the database, because most channels will rarely be closed, unless there will be some strong financial incentives to do that. Keep in mind that any incentives to close old “heavy” channels will increase on-chain pressure and most likely will involve subscription-based systems with a low privacy.
As the main trade-off, this solution will decrease UX, because users will have to store old states and resend them after an expiration date. Additionally, this approach will introduce different scenarios for mass-cheating, e.g.:
Bob lost his phone (or got into jail/coma/etc.). He still can recover his on-chain funds with a recovery seed, but he doesn’t have the latest states to close his channels, so he has to wait until his counter-parties will close all the channels unilaterally, knowing that watchtowers will prevent any cheating attempts. Unfortunately, after 1 year all his state updates will be deleted from a watchtower’s database, so big hubs can wait and then cheat-close inactive channels (more than 1 year) with very good risk/reward ratio, e.g. risk $10 to get $100. Of course, Bob can try to retrieve his previous states from a watchtower and resend them again after some time, but retrieving state updates implies some sort of account-based system with a low privacy. Bob can also back up all his state updates to a cloud after each off-chain transaction, but there are many concerns about privacy as well.
4. Delete old states with user’s requests
Suits: LN (not eltoo)
Another solution could be that after closing a channel, a user will send a request to a watchtower with a list of previous state updates that can be safely deleted. He can even split all keys into multiple requests over a period of time and route them through Tor for more privacy.
This approach can help watchtowers to slightly trim their databases, but there are still many problems:
- Users have to be financially incentivized to close old “heavy” channels and to send requests to delete old state updates, so there will be a complex account-based low-privacy monetization system that will charge users periodical fees depending on how many states they store. E.g., users can delete most of their tweets from years ago that didn’t get any exposure and don’t have much value anymore, but most users don’t do that. Why? Because they are not financially incentivized to do so.
- Let’s assume that a user has to pay some periodical fees for all stored state updates. What if a user lost his device with all previous states? He can definitely recover his funds from a recovery seed (if he backed up his 12–24 words), but he will not be able to construct a request to a watchtower to delete previous states even if all his channels will be eventually closed by his counter-parties. So he has to move to another watchtower or create a new account at the same watchtower, but since he cannot close channels by himself, he still has to pay full fees for the old watchtower’s account until all his channels will be closed by counter-parties, which might take a long time.
- Even if implemented properly, it will not solve all the problems, because only state updates of closed channels will be deleted, so watchtowers will still have to store all state updates for all open channels.
- Additionally, this feature will increase an on-chain pressure, because users will close and open their channels more often.
5. Technological progress
At this point, one might think that privacy-oriented watchtowers are doomed to fail, but we shouldn’t forget about technological progress.
Technology can offset the law of diminishing returns by providing more efficient hardware/software for the same price, and hence decrease operating costs. However, a quadratic growth of operating requirements should be replaced with a linear growth, otherwise the innovation might not keep pace with constantly growing operating requirements.
Unfortunately, to do that a privacy-oriented watchtower will have to limit its user base by introducing an account-based system with a very low privacy, so we are kind of stuck in a loop.
Let’s sum it up:
- Watchtower can introduce an account-based system
- Limit its user base (e.g. maximum 100,000 users)
- Data storage requirements will increase linearly
- Upgrade hardware (e.g. annually) to keep operating costs low
- Occasionally there will be software upgrades to decrease operating costs
But then what’s the point of a privacy-oriented approach of managing state updates if there will be an account-based system with a low privacy?
So is everything that bad or are there better solutions?
Hybrid models
Let’s look at some hybrid models, which combine different approaches together.
1. Limiting an amount of received state updates
Suits: LN
Above we’ve discussed that a privacy-oriented watchtower can replace a quadratic growth of operating requirements with a linear growth by limiting its user base via introducing an account-based system with a low privacy.
However, there is another, more privacy-oriented, way of limiting the ever growing data storage requirements, which is simply to not receive any more state updates from any user or set a daily/monthly limit for all the clients.
There might be at least two different implementations:
- either a user pings a watchtower for each new state update
- or a user initiates a session and books multiple ‘slots’ that he can later fill with state updates
If a watchtower refuses to receive anymore state updates, then a user tries to send his state updates to another watchtower.
This is an interesting approach that will give watchtowers an ability to limit their operating costs, but there are problems with accountability, UX and monetization, because account-based system is the most viable model, which we will talk about in the next article.
This hybrid model can be expanded with extra features like:
- A user can send a request to delete old states updates that belong to closed channels (already described above).
- A user doesn’t need to send those states that allocated all or most funds to a user (already described above).
Extra: limiting an amount of received state updates will give individual watchtowers an ability to limit the growth of their operating costs, but it will not solve the problem of quadratic growth of the storage capacity for the whole system, i.e., other watchtowers will share the burden.
2. Save button
Suits: LN & RDN (limited benefits)
A user can make multiple off-chain transactions without syncing with his watchtower, and then send only the latest state update, assuming that a watchtower needs to store only the latest state update in order to stop a potential adversary from cheating (RDN’s or eltoo’s approaches).
State updates might be sent to a watchtower:
- When a user presses a “save/sync” button
- Periodically (e.g., daily or hourly if there were any transactions)
- Auto-sync before a user goes offline
This way business-oriented watchtowers will have much less information about user’s economic activity such as the timing and the total amount of transactions, so there will be a certain degree of privacy. And data storage requirements won’t be a bottleneck for scaling either, because watchtowers will store only the latest state updates. Additionally, there will be less bandwidth burden, since not all state updates will be sent to watchtowers.
Problems:
- The biggest issue is UX, since users will have to manually “save” states.
- It’s also less secure, because auto-sync might fail to save states right before a user loses his data or device.
- An auto-syncing will reveal a user’s online schedule.
- In a RDN’ current design, this approach will mask only the timing of transactions, since the total amount of transactions will still be visible to a RDN monitoring service, because each package will contain a nonce that indicates a total number of all transactions in the channel.
- It should be a default setting, otherwise laymen won’t use it.
3. Privacy-oriented model with user’s requests to delete old states
Suits: LN (eltoo)
After eltoo is implemented, even privacy-oriented watchtowers will be able to store only the latest state updates that belong to a certain channel, but how can they determine which state updates are old? Reminder: privacy-oriented watchtowers cannot link together all state updates that were made by the same channel or account.
The solution is to financially incentivize users to send requests to watchtowers to delete old states. Users can do that via Tor with a certain delay after a new transaction in order to presume privacy.
This approach combines together:
- A privacy-oriented design
- An ability to store only the latest state update (eltoo)
- Delays
- User’s requests to delete old states
In my opinion, this is the most balanced approach in terms of privacy and scalability. However, it’s not clear how to incentivize users to proactively send requests to delete old states without giving up their privacy. We will try to research that in the next article about viable business models.
Conclusion
There are many different solutions to privacy and scalability problems, but all of them have certain trade-offs. The future of off-chain scaling is still very unclear, so it’s crucial to discuss pros and cons of different designs, look at incentives models, and brainstorm together new approaches and solutions to the problems.
In the next article we will look at solutions to an accountability problem and discuss different watchtowers’ business models and how they can monetize their services, because there things will get a bit messy again.
If you want to see more candid articles about watchtowers, hubs, and off-chain scaling solutions in general, please share this article or donate here, that will definitely speed up the process.
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 really care about privacy & security, then consider reading an article that explains in details how Hong Kong activists keep their identities private while actively participating in the protests.
- 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.
