Clocks and Watchtowers: March 31, 2019 Snippets
By: Snippets, Social Capital
Tags: Snippets, Cryptocurrency, Bitcoin, Lightning Network

Welcome back to our Snippets series on the Lightning Network — what is it, why does it matter, and how does it work? Last week we covered the general idea of user-established payment channels that sit on top of an already established cryptocurrency like Bitcoin. But one thing we didn’t talk about is security: how can we guarantee the same degree of robustness we like about the main Bitcoin network, if we’re dispensing with the expensive but necessary Proof of Work mechanism that makes Bitcoin so secure? (If you want a catch-up reminder on what all this means, check out this explainer I wrote, just for you.)

One of the most common questions I hear when I explain Bitcoin to people is actually a very smart one: “It sounds like the big problem with peer to peer currency boils down to the fact that you can’t prevent people double-spending their own coins. Why can’t you just resolve the question by saying, “whichever transaction happened first is the real one, and anything else gets ignored?” This is a good question! The answer is that it’s very hard to conclusively establish what “first” means on a P2P network. There are all kinds of ways by which clever bad actors could mess with timing by telling one version of information to one node and another version to other nodes, leaving it totally unclear what “first” really means. So relying on temporal order does not pass the Byzantine Fault Tolerance test: if bad actors can abuse it, then it doesn’t pass the test of “you can trust messages even if you don’t trust the people sending them.”

So how does Bitcoin solve this? If you’re well-steeped in how the Bitcoin protocol works, you’ll hopefully appreciate that in one sense, the Bitcoin network is acting like a clock with a second hand that ticks in discrete chunks. Instead of treating time as continuous, it treats time as something that starts and stops, synchronizing with each block. Each time someone successfully solves the proof of work challenge and mines a block, it’s like time freezes; we get to all look together to make sure the block is valid; once we agree and commit to begin the next block, time starts back up again. As a bad actor, you can’t play time shenanigans because a) all of the transactions in a block are handled simultaneously, and b) any block buried in the past will be out of reach, because the nature of the proof of work challenge establishes a “time gap” between the blocks. It turns the record of the past (which has to exist in the present) actually behave like the past, in that it’ll be effectively out of reach to anyone in the present; we can observe it, but we can’t change it.

What about in a Lightning channel? In a lightning channel between two people, there’s no Blockchain. There’s no proof of work. There’s no mechanism to “entomb” time that happened in the past, because it’s just a ledger between two people. It’s pretty straightforward to keep track of time when it’s just one balance being passed back and forth between two parties. The problem arises when it’s come time to close the channel: what’s to stop either one of us from posting a past balance, that has since been overwritten, to our illegal benefit? If you broadcast some past state to the main blockchain, and then it gets settled on the main network irreversibly, then you’ve successfully cheated me out of money.

With regular Bitcoin, this would be analogous to holding up a past block and claiming, “this is the present balance”. But no one will believe you, because it won’t be the longest chain. The only balance that anybody cares about is the balance that’s stated on the longest chain of blocks. In a lightning channel, there is no such mechanism to prevent against time shenanigans. The information inside a channel is private; the main network can’t go back and check. Furthermore, the whole point of settling all of these transactions off-chain was so that the main network doesn’t have to safeguard against fraud in every single transaction. So what can we do?

So there’s one straightforward way to guard against this that will work most of the time. Stamp every transaction with a unique hash signature that is like a kind of “serial number”, where each serial number can be irreversibly linked to all previous serial numbers generated in the transaction history. (Cryptographically, there are many ways to do this: one would be to keep hashing the same serial number over and over again in order to generate new ones. If you give me the serial number of transaction 100, and then provide me with a second serial number in question (say number 97), I can prove to a sufficiently high probability whether or not any second serial number does or does not belong to the transaction history in 1 through 99. Conversely, I can prove the opposite as well: whether or not Serial Number 100 is a valid descendent of Serial Number 97.) Any time somebody closes the Lightning Channel, the transaction is frozen for a period of time, giving the other party a chance to review and make sure that the serial number of the final balance being posted is genuinely the last one that was ever generated, and not something from the past. If the serial number is illegitimate, then impose a harsh penalty: give the offended party the opportunity to create a new transaction that deposits them the entire Bitcoin balance from the channel. In other words: if you try to cheat by posting an earlier balance, you can easily get caught (so long as the other person is watching), and if you get caught you’ll lose the entire balance. Not worth it.

Unlike on the Bitcoin main network, where conclusively establishing an order to the transactions is effectively impossible (the ‘clock problem’ from earlier), with two people this isn’t as hard. So our solution should work most of the time. But can anybody spot one big problem? The problem is that you have to be online all the time in order to guard against being cheated. Otherwise, your trading partner would wait until you’re offline for any reason, then quickly post an illegitimate balance and steal your money while you’re not looking. Some people, by the nature of where their lightning node is located, may be online 99% or more of the time. But that’s not something we can count on for everybody. So, as is, this isn’t very safe system design.

How about we incentivize other people to keep watch for us? Paying for someone to professionally keep watch for fraudulent transactions sounds like something I’d be willing to pay for, as a Lightning user! You can imagine a digital node called a “Watchtower” (which is what they’re called on the Lightning Network) whose job is solely to monitor all balances that are getting cleared on the main Blockchain for any signs of misbehaviour. If they ever catch something, have them be authorized to execute the penalty transaction on behalf of the injured party, sending them the BTC balance while keeping some percentage as a bounty fee. (Alternately, you could have a bounty-less business model by simply paying for watchfulness-as-a-service. Plenty of ways to pay for this.)

The challenge, though, is how do we do this in a way that doesn’t a) massively slow everything back down to the speed of the regular blockchain, by having every transaction get checked by others ever time, and also b) reveal the contents of your Lightning Channels, which are private? The answer lies in our serial numbers. If I am a Lightning Network user, I can subscribe to a Watchtower service and then, every time I make a transaction in my private channel, send the Watchtower a copy of the serial number for safekeeping. This way, the Watchtower has a way of knowing whether a transaction is up-to-date or not without knowing what the transactions actually say. Their job becomes a lot more straightforward: scan the serial number of every Lightning settlement on the main Bitcoin network, and look for any that match serial numbers in your archive which aren’t the most up-to-date serial number for that channel. Each serial number isn’t very big: it’s tweet-sized, so storing hundreds of millions or billions of them is totally achievable even for a small operation. From time to time, you can also clear out old serial numbers — whenever a lightning channel gets closed successfully, you can flush out all of its old serial numbers and delete them. Furthermore, this is a great way of making decentralized security scalable: not every Watchtower needs to watch every transaction, or every node!

Ultimately, the Lightning Network deals with the problem of “time cheating” in a very different way from the main Bitcoin network. The main Bitcoin network does so in a way that makes old blocks and old balances irrelevant: anyone can attempt to broadcast old balances if they want to, but no one will care. This is a very robust way to solve the problem: don’t police it; make it irrelevant through system design. The Lightning Network doesn’t have that luxury — not without bringing Bitcoin’s expensive proof of work process to every channel, which would defeat the whole point of the process. So instead, we have to rely on something that’s less ironclad: relying on policing and watchfulness rather than system design is certainly less preferable, but that doesn’t mean it can’t work. The trick will be in making sure that damage can get contained, like in water compartments of a ship’s hull: if something goes wrong on one Channel for whatever reason, don’t let it affect others.

Next week, we’ll talk about how Lightning channels aren’t just for direct transactions — they can also get linked together into a mesh P2P network for payment routing.