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.