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