A Message to Humans: An Alien’s Guide to Lightning Network Watchtower Limitations and Beyond
Greetings Human,
We have been watching you closely and would soon like to welcome you into our Intergalactic Federation. Your civilization has finally accomplished a fair and decentralized means of storing and transacting value. However your technology is currently still too primitive and requires a few supporting upgrades to realize its full potential.
Please see the following transmission and quickly adapt your technologies as needed. We have strived to use simplified explanations and analogies so that even the underdeveloped intelligence of your species can understand it.
BACKGROUND
To provide a complete and linear foundation for our central ideas, we first provide some background on the structure of Bitcoin transactions and how that influenced the network’s history and development.
The first three sections dive deeper into the underlying technology than the rest of this transmission. We have included TLDRs for these sections and recommend readers wishing to skip them to start from The Block Size War.
Lifecycle of a Bitcoin Transaction
TLDR: Bitcoin transactions take locked Inputs, provide the necessary data to unlock them, and then create new locked Outputs describing what data is needed to unlock them.
A Bitcoin transaction consists of Inputs and Outputs.
An Output is an amount of coins along with a set of instructions to unlock the coins for spending. We call this set of instructions a Script PubKey. Most Script PubKeys require one or more digital signatures to unlock the coins.
Digital signatures allow for anyone to verify that a specific piece of data has been signed by a given private key. A cryptographically secure digital signature means that it is infeasible for anyone to find another piece of data that produces the same signature.
For Bitcoin transactions, we will defer discussion on what exact data is being signed to a later section. For now, just understand that at a high level, by default, a signature applies to the entire transaction. What this means is that a transaction (its Inputs and Outputs) cannot be modified without invalidating its signature(s).
An Input refers to an Output of another transaction along with some data to give to that Output’s Script PubKey. We call this data the Script Sig. The right Script Sig will unlock an Output and allow it to be used as a transaction’s Input. Each Output is only allowed to be spent once.
In order for a Bitcoin transaction to be considered valid, all of its Inputs must be Unspent Transaction Outputs (UTXOs) with Script Sigs that satisfy their Outputs’ Script PubKeys. The only exception is coinbase transactions where miners are allowed to generate new coins as incentive to secure the network.
The sum of a transaction’s Outputs must also be less than the sum of its Inputs. The difference between them is used as a fee for the miners. Except for mining, no coins are created or destroyed.
After a Bitcoin transaction is signed, the user then sends it to other nodes throughout the network. These peer nodes then validate the transaction, store it in a mempool of pending transactions, and continue to share the transaction with other nodes. A miner node will then eventually include it into a mined block for finalization into the blockchain. Miners are incentivized to prioritize and include transactions into the 1MB block based on a transactions size and fee.
So what does it mean for you to own Bitcoin then?
It means that you possess information — usually a private key to produce a signature — which can unlock and spend UTXOs. A Bitcoin wallet is software that keeps track of those UTXOs.
Multi Signature and Partially Signed Transactions
TLDR: Bitcoin gives us the flexibility to only allow coins to be spent if multiple people approve. We can also create partially approved transactions for others to finish approving.
The reason why we call it a Script PubKey and a Script Sig is that Bitcoin has its own programming/scripting language to allow for many different types of requirements to unlock an Output.
One useful type is Multi-Signature, where digital signatures from multiple keys are required in the Script Sig to unlock and spend the coins.
For these multi-sig transactions, because an Input’s Script Sig is just a list of data, it is possible to create partially signed transactions that do not have all required signatures. While these partially signed transactions cannot be broadcasted on chain, they can be given to others to finish signing and then broadcast.
Segregated Witness
TLDR: Segregated Witness allows us to create transactions which use the Outputs of a transaction that has not been signed or broadcasted yet. Of course, before we can use broadcast it, the transaction it refers to must also be signed and broadcast.
We have described Inputs as Outputs from another transaction, but have not described how it refers to these Outputs. Inside a transaction, Outputs are in a list so we can just say something like: the 2nd Output of <tx ID>. A transaction’s ID is simply the hash of the transaction.
A hash takes data of variable length to create data of a fixed length. Anyone with the same data will always produce the same hash. Like digital signatures, a cryptographically secure hash means that it is infeasible for anyone to find another piece of data which produces the same hash. This makes hashes useful to refer to a piece of data without needing to reveal that data until later.
So far our understanding is that when we provide a digital signature in a Script Sig to unlock an Output for spending, we are signing the entire transaction we want to make. This means we sign data which incorporates all of the Inputs and all of the Outputs. However, because the Script Sig field is part of an Input, we have to omit the Script Sig field in our signed data or else the signature would be self referential.
Notice that there is a difference between the data that gets hashed to create the Transaction ID and the data used for signing. The hash includes the Script Sigs while the digital signatures do not.
This created the issue of Transaction Malleability. By modifying the Script Sig fields, one can change a transaction’s hash/ID without invalidating a transaction’s signatures. For example, this could be done by appending extra unneeded data in the Script Sig, or in a 2 out of 3 multi-signature by using different signature pairs.
Ideally we also want to be able to talk about a transaction using its ID without it being fully signed and able to be broadcasted. We need this for Lightning Network which we will discuss in a later section.
To solve these issues, a change known as Segregated Witness (SegWit) was introduced with BIP 141. SegWit transactions move all of the data out of the Script Sig field and into a separate (segregated) section called the Witness.
By moving the data out of the Script Sig section and leaving it blank, this means that a transaction’s hash/ID will be the same regardless of whether or not it has been signed. For backwards compatibility, SegWit requires that their Script Pubkey declare SegWit usage. This solved the issue of Transaction Malleability.
You’ll notice in the provided visuals that the non-SegWit transaction has an ID of B’ while the SegWit transaction of B.
B = the hash of (Input sources+ <BLANK> + Outputs)
B’ = the hash of (Input sources+ <Alice’s Signature> + Outputs)
SegWit also counts SegWit transactions as 1/4 the size of normal transactions, effectively increasing the block size from 1MB to 4MB. There are a few other details which keep track of Witness data to make sure it doesn’t change. SegWit should also not be confused with SegWit2x which proposed activating SegWit and doubling the block size.
During the Block Size War, the activation of SegWit was controversial and a major point of contention. Although names in a decentralized hard-forking network can be confusing, the network that is most accepted as “Bitcoin” with the most hashpower and most value under the symbol BTC implements SegWit.
The Block Size War
Bitcoin’s limited block size of 1MB and “slow” average block times of 10 minutes were the primary ideological schisms during the Block Size Wars, as these parameters did not allow for a large volume of transactions to be processed.
Many felt that the hardcoded limits stopped Bitcoin from reaching its full potential. Miners generally liked the idea of larger and faster blocks. They were well connected to capital and would have no problem handling larger/faster blocks to collect more transaction fees. The costs of processing these additional transactions were nothing compared to the costs of mining.
Others felt that the limited block size was necessary to achieve world wide decentralization to enable Bitcoin to become the new monetary standard. Although the limitations meant less number of transactions, it meant that older and underpowered hardware could run nodes and validate blocks. Without the ability to run your own node, you have to ask and trust another node to keep track of your money. In creating the most trust-less, decentralized, and secure network of value, we want everyone to be able to run a node and verify their own transactions.
It should be noted that the cost of a transaction is the same regardless of how much value is being sent. While the Bitcoin network cannot handle a large number of small transactions, it is an extremely secure and efficient way of sending a large amount of value. Even during the early days of Bitcoin, people hypothesized that eventually Bitcoin would primarily be used as the gross settlement layer of value, perhaps as reserves by private banks, while everyday transactions would be conducted through other more lightweight networks, such as Layer 2s and sidechains.
Sidechains
A sidechain is another network which allows users to “move” mainchain coins in and out of it. Every sidechain can have their own set of consensus rules and their own set of tradeoffs when it comes to decentralization, scalability, and security, the so-called “Blockchain Trilemma”. Some might offer additional features such as privacy functions and smart contracts.
Most function by having the sidechain operators/validators control a multi-signature wallet on the main chain. When users send coins to that wallet, the sidechain operators create/mint a tokenized version of it on the sidechain. When you want to cash out to the mainchain, you “burn” the tokenized version (make it unspendable) so that the sidechain operators’ multi-sig wallet on the mainchain can then pay you. While tokenized coins on the sidechain may normally trade for roughly the same value, the trust model is different.
Lightning Network
The activation of SegWit allowed for users to create valid transactions that referred to the outputs of transactions that were not yet fully signed or broadcasted to the blockchain. This was a key requirement for the implementation of the Lightning Network, sometimes just referred to as Lightning. The Lightning Network is a L2 scaling solution using off-chain payment channels.
We will not provide a full technical breakdown of the Lightning Network in this transmission. However we will make some accessible analogies and comments on the technology when it is important.
Lightning works by first funding a multi-signature Output and then keeping track of transactions within that account privately off chain. We call this a Layer 2, rather than a sidechain, because the transactions are real Bitcoin transactions that can be posted to the network at anytime. There is no need to trust another network’s operators to properly cash you out.
Let’s use an analogy.
Alice and Bob do business together and make a lot of transactions between them. In order for Alice to send a transaction, the bank requires Alice to provide a signature in person. All money is stored safely in the bank’s vault. When the bank receives a valid signed order, it will organize the money to reflect any ownership changes.
Maybe the lines at the teller are getting too long, and Alice does not want to wait every single time. Or maybe the fees that the bank charges to execute a transaction are getting too high. So she and Bob come up with a plan to make sending transactions back and forth to each other easier.
They are thinking about opening up a special joint account at the bank for the both of them. They can fund the new account however they want, with Alice putting in some money, and Bob putting in a different amount or none at all. Once opened, the account cannot accept new funds and the funds inside cannot be distributed without an order with the signatures from both Alice and Bob.
Bob sometimes goes on a bender and Alice is worried that after she funds the joint account, that Bob will simply disappear leaving her money locked in the account.
So even before they open up this special account, she makes Bob sign an order which tells the bank to close the account and return all the money based on how it was originally funded. She creates a similar order for herself, signs it, and gives it to Bob. Now if Bob does disappear, she can provide the second signature to what she made Bob sign and safely get her money back. (This is what we needed SegWit for.)
Alice and Bob then realize that they can sign different account closing distribution orders to represent transactions between them. For example, let’s say they Alice and Bob both fund the account with 10 coins. Then in order to pay Bob 1 coin, Alice and Bob can create and exchange partially signed distribution orders where Alice gets 9 coins and Bob gets 11 coins. Then let’s say that Bob pays Alice 5 coins so they create and sign an order where Alice gets 14 coins and Bob gets 6.
There’s one issue though. What about all the old orders? After creating and signing an order where Alice has 14 and Bob has 6, what is stopping Bob from taking an older signed order to the bank so that he can get 10 or even 11 coins?
This is where our analogy doesn’t fully fit. In our real world example, Alice and Bob could use a method like writing VOID on the old orders or shredding them. In the digital world of Bitcoin, once a transaction has all of its signatures, there is no way to stop someone from posting it unless its Inputs have already been spent on the public ledger.
For the sake of our analogy, let’s say there is no way for Alice and Bob to verify that the other person has destroyed an older valid signed order. How should we proceed?
Alice and Bob can write in some extra rules into their distribution orders. They instruct the bank so that when one party closes the account, they have to wait a few days before they can take the coins. During that time period, if the other party is able to show that there is fraud, then the bank will penalize the party which closed the account and give all the coins to the damaged party.
If Alice and Bob are smart, they will have numbered the distribution orders kept between them or used a timestamp. In this case, one can just use a newer signed order to show that the old one is fraudulent.
Lightning Network works roughly the same way as our analogy. The entire Bitcoin network acts as the bank, and a multi-signature Output acts as the special joint account, which we will call a payment channel. In our analogy, Alice and Bob both sign account closing distribution orders. In Lightning Network, Alice and Bob exchange partially signed transactions using the multi-signature Output as a transaction Input.
So what have we accomplished? Instead of needing to visit the bank every time Alice or Bob want to make a transaction with each other, they can simply update their payment channel between just the two of them. While the bank can process transactions only as fast as the teller can, they can update their relative balances in the channel as fast as they can exchange signed orders. And because they are exchanging valid bank orders, these privately held orders are as good as money in the bank. (So long as they don’t lose them. See BONUS for more)
The only limitation is that they are restricted to transacting with the funds that were used to initially fund the payment channel. If the transactions are mostly in one direction, or they need to transact back and forth in larger amounts, they will need to open up another payment channel. They could close the old one or continue to use it alongside any new ones.
We will just make a technical comment about Bitcoin that is not crucial to understanding Lightning at a high level. Do not worry if the following doesn’t make sense.
Bitcoin transactions are not numbered (remember its ID is its hash) and their timestamps are not reliable. Although Bitcoin provides a concept of time-locking coins, there is no native concept of a “fraud dispute” period. Instead, Outputs have cleverly constructed Script PubKeys where there are multiple valid ways to unlock and spend the coins. Specifically for Lightning, parties generate a private key for each transaction which is then revealed to the other party as a way to “void” that transaction. For a full understanding, we recommend looking into other resources such as the official Lightning Network white paper.
Lightning Network also describes how one can send a payment across multiple channels as long as there is a path with enough liquidity in it. In this transmission we will primarily focus on the issues that arise from even a single payment channel.
Fraud Proofs
In our bank analogy of the Lightning Network we describe how Alice and Bob can easily present a newer signed order to prove that someone posting an older signed order is acting fraudulently.
We will generalize the concept: a “fraud proof” is information which can show that a user has acted in error or fraudulently. Fraud proof = proof of fraud.
As in real life, fraud proofs can vary in conclusiveness. In the court system, DNA evidence usually is much more definitive than eye witness testimony. When it comes to cryptography, different cryptographic protocols may be easier than to attack than others.
Fraud proofs can also rely on specific information vs general knowledge. For example “you couldn’t have been at the office, because I saw you at the beach” vs “you couldn’t have been at the office, because it was closed that day”.
Watchtowers
For Lightning Network, the introduction of a dispute period for payment channel closes before the coins can be spent allows for users to to know that they can stop their counter-party from reaping the rewards of posting an older fraudulent transaction.
There is a tradeoff here between safety and usability. The longer the dispute period is, the more time there is to catch fraud, but the longer users have to wait before they can spend their coins.
It also introduces a new problem. In order to safely use Lightning Network without trust, one must stay vigilant and never stop watching the blockchain, as long as you have open payment channels.
A Watchtower is a piece of software that is does exactly this. A watchtower stores your fraud proofs for payment channels, constantly monitors the blockchain for fraudulent payment channel closes with older states, and acts on your behalf to take the disputed coins before the attacker can.
At a technical level for Lightning Network transactions, Watchtowers must be explicitly written into the Outputs’ Script PubKeys, adding additional complexity.
THE PROBLEM
Delegated Watching
While running your own watchtower to monitor the blockchain for fraudulent transactions is great for those who can operate and afford it, what about those that cannot?
For most users, maintaining a Highly Available server infrastructure to safely use payment channels may even cost more than if they had just submitted their transactions on-chain.
Many of those who can benefit the most from off-chain payments channels may only own a mobile phone. Even when all mobile phones are powerful enough to verify and watch the blockchain, what happens when the battery is dead or connectivity is lost for an extended period of time?
The proposed solutions so far have been inadequate.
The primary suggestion has been delegated watchtowers. You pay another party who will store your fraud proofs, watch the blockchain, and then dispute fraudulent transactions on your behalf.
We run into a few issues immediately. How should we pay them? We will not consider using fiat methods or other networks for obvious reasons. Do we make payments directly on-chain? Making many payments on-chain for delegated watchtowers so that you can take advantage of off-chain payment channels doesn’t exactly make sense. So at best, we will open up a payment channel with the watchtower and need to lock up some liquidity in it.
However even if you pay them, there is no guarantee that a watchtower will fulfill its duty when necessary. Even if they do not act maliciously, what if they experience downtime, which an attacker then tries to take advantage of? Perhaps you could find and pay a few watchtowers for redundancy. But the essential issue of introducing complexity and placing trust in a few parties to safeguard your payment channels is not resolved. Even if a watchtower stops fraud and takes the coins before the attacker can, it is still up to them to return the coins to you.
The main incentive for a watchtower to fulfill its duties would be maintaining its reputation to continue collecting watching fees. Keep in mind that the fees the watchtower collects cannot be too high as that would invalidate one of the main reasons for using off-chain payment channels in the first place.
Depending on what privacy technologies exist, attackers may be able to see your on-chain payment relationship to watchtowers and know which ones to bribe/attack. A user who pays a watchtower so that they do not need to be vigilant themselves, may not even be aware of a successful attack on them for quite a while until they finally check for themselves.
Maybe delegated watchtowers could be bonded and post collateral in escrow. However this is external to the network and and requires external arbitration systems that might be operating within existing legal frameworks.
There is also the issue of complacency. If payment channels are ubiquitous and the existence of delegated watchtowers is sufficient enough to prevent most fraudulent transaction from being broadcasted, then the watchtowers may find it more profitable to cut corners and later deal with anything that slips through the cracks if it is even noticed. In this case, watchtowers become like insurance companies, where users must engage in a costly claims process.
In any case, delegated watchtowers are unsuitable as a scaling solution for the most decentralized and trust-less monetary system in the world, especially for those who need off-chain payment channels the most. Paying a watchtower to monitor for fraudulent transactions on your behalf provides no guarantees, is non-standard, and almost always still requires trust. We need a protocol.
Designing A Solution
Let’s design a trust-less decentralized network which can make payment channels usable for everyone, including those who cannot run their own watchtower servers.
We first need a base layer Consensus mechanism with incentives to provide transaction ordering and enforcement of the network’s rules.
Now to address the core issue.
Recall that for Lightning Network, payment channel closes must be included in the blockchain before they can be disputed. Watchtowers must monitor the blockchain for transactions that have already been finalized in the public ledger. Only then does the watchtower have a limited window to provide a fraud proof.
This introduces a form of attack where the cost to defend against a fraudulent transaction is the cost of making another transaction. If the attacker posts a high value fraudulent transaction during a time of high network activity and high transaction fees, a user may not even be able to afford to post a fraud proof to the network. By the time fees are affordable again, the dispute window may have already ended.
Ideally we want a system where old channel states do not not even make it into the public ledger. If we could do this, then we wouldn’t even need to have a dispute period!
Our first approach might consider stopping the transaction in the mempool where it is waiting to be included in a block. We won’t focus on it here, but it is an interesting thought experiment for those who want to consider using Bitcoin’s Replace-By-Fee (RBF) mechanism to stop fraudulent transactions in the mempool, and why that is not a workable solution.
In any case, once a transaction is in the mempool, at any point in time a miner can include it in the next block. At least once it is on-chain, we know how many blocks we have to dispute it.
So what if we flip the script? Instead of watching for transactions after they have been included in the public ledger or in the pending transaction mempool, why don’t we require an approval phase for all transactions before it even gets there?
Let’s introduce incentives into the network to create a transaction Approval layer and create a network rule that every transaction must be approved before going to the consensus layer.
To keep the approvers accountable, we can add a few more details and network rules.
Let’s first require the approvers to post and lock collateral. To be safe, let’s require signs offs from multiple pseudorandom approvers: in case the fraudulent transaction poster gets assigned his own approver or if one approver makes a mistake.
Let’s also chain these approvals together so the network has a trail of accountability. If an approver makes a mistake or acts fraudulently, then the next approver down the line can post a fraud proof, stopping the fraudulent transaction and collecting the previous approvers’ collateral.
To prevent an attacker from sending a fraudulent transaction to only compromised Approval nodes that they control, the sequence of required approvals should be deterministic yet pseudorandom. An Approval node should not be able to choose the next node and it should not be possible for the attacker to know what sequence of nodes is needed when broadcasting a transaction.
For resilience against Approval node downtime, it may be possible that the Approval layer maintains its own memory pool of unapproved transactions with a way to handle offline nodes, so that no transaction is dropped.
We could even add a mechanism where if a fraudulent transaction does make it past all approvers to the consensus layer, the damaged party can act as their own watchtower on a longer time horizon and reclaim the locked collateral from all of the approvers. In this case, a user still has recourse despite not having a dispute period which delays the transaction.
With high enough collateral requirement and a decentralized approval layer, it would be extremely unlikely or costly for an approver to be negligent or assist in fraud.
There’s just one missing detail: how do approvers know if a transaction is fraudulent or not? Where does it get the fraud proofs?
By definition, we use payment channels to conduct off-chain transactions. Yet here we are requiring the use of off-chain fraud proof data to determine if a transaction should go to the consensus layer.
This is exactly the Oracle problem: how do we achieve a decentralized source of truth regarding off-chain data and make it available to the network?
So let’s add incentives for an Oracle layer to our network.
The Oracle layer will be responsible for keeping track of fraud proofs for disputing fraudulent payment channel closes. Any time a pair of users transact through a payment channel, both users will provide any new fraud proofs to the Oracle layer.
When a payment channel closure is sent through to the consensus layer, the Approval layer can instruct the Oracle layer that it is free to delete any fraud proofs associated with that payment channel. To minimize storage requirements, ideally a single fraud proof can work on all previous states so that Oracles only need to store a constant amount of data for each payment channel.
One good way to do this would be to use the transaction’s ID/hash as the fraud proof. When Alice and Bob conduct an off-chain transaction they will simply both provide the latest hash to the Oracle layer. If Alice or Bob post a transaction to close the channel, the Approval node will ask the Oracle layer for the latest known transaction id in the channel to see if it matches.
So far when we have been adding layers to our network, we haven’t discussed what kind of incentives are needed/appropriate. Because we have the rule that all transactions need to go through the approval layer before going to the consensus layer, Consensus nodes and Approval nodes should share the incentives such as coinbase transactions which keep the network running.
Generally Oracles are incentivized by providing rewards for answering questions. The nodes who give the most popular answer split the rewards. For numerical questions, nodes which fall into a range near the average/median may be given rewards. These answers are usually weighted according to stake to prevent sybil attacks (creating many oracles to try and report a false answer as the most popular). As long as the Oracles are decentralized, the most profitable way to get the incentives is to provide a truthful answer since it will be difficult to collude around a false answer.
The Oracle layer so far is only needed for storing and reporting payment channel states. Because the usefulness of this to the network is determined by the usage of payment channels vs base layer payments, the incentives for Oracles should be more market driven based on usage when compared to the incentives for Consensus and Approval.
In addition, the Oracle layer could be extended for other purposes beyond storing fraud proofs for payment channels.
For example, regarding the network itself, we may want Consensus and Approval nodes to not only post collateral but also maintain a high level of uptime. Uptime statistics are off-chain data which could be measured by the Oracle nodes and then presented to the consensus mechanism to determine if any poorly performing nodes should have collateral slashed.
With the right incentives, any off-chain data from weather, sports, financial markets, etc could be hosted and served through the oracle layer.
Hypothetical Examples
Let’s walk through how our network could possibly function with some example transactions. Although the high level architecture of Consensus, Approval, and Oracle is needed, certain details that we may assume here could be different in a real implementation.
If Alice wants to send Bob some coins directly on-chain it is fairly straightforward.
Alice will create and sign a transaction and then send it to an Approval Node. The Approval node will notice that is a simple transaction so that it only needs to verify that Alice can spend the coins and that the signature is valid. The Approval node then signs the transaction and passes it off to another Approval node who verifies the transaction validity and the signature of the last approval. This process repeats until the transaction has enough approvals as required by the network rules. The last Approval node then sends the fully approved transaction to one (or a few) consensus node(s) to be included in the next consensus round.
How about if Alice wants to use a payment channel with Bob?
As with Lightning Network, at some point in time, Alice and Bob will have to setup a multi signature address and fund the payment channel. To transact with each other, they will exchange partially signed transactions along with any necessary fraud proofs to each other. They will also share these fraud proofs to the Oracle layer.
If Alice wants to close the channel she will take the latest partially signed channel state, sign it, and broadcast it to an Approval node. The approver will notice that the transaction is multi-sig and possibly represents a payment channel close. Before it can sign off on the transaction and hand it to the next approver in the sequence, it must contact the Oracle layer to ensure that the transaction is not fraudulent.
Each Approval node in the sequence will independently query the Oracle layer for any fraud proofs relevant to the transaction. If all Approval nodes agree that there is no attempted fraud, then the last Approval node will send the fully approved transaction to the consensus layer as before.
Depending on what privacy features are available, the Approval node may not even be able to tell if the transaction is simple or a multi-sig/payment channel. In this case, the Approval nodes will consult the Oracle layer regarding every transaction.
Now let’s examine a case of attempted fraud.
Alice has a payment channel with Bob. She wants to close the channel with an older state where she has more coins. She asks her friend Eve who operates an Approval node to help her cheat.
Alice has not been throwing away the old partially signed channel states and signs one where she has more coins. If the required sequence of Approval nodes is pseudorandom and hard to determine, it will be difficult for Eve to assist her. However let’s assume that somehow Alice’s transaction first goes to Eve’s Approval node. Eve will most likely not even consult with the Oracle layer for any fraud proofs and sign off on the transaction.
If Eve tries to send the transaction now to the Consensus layer, the Consensus layer will reject it because it does not have the required sequence of Approvals. Eve sends the transaction along to the next Approval node. This Approval node is honest and contacts the Oracle layer which signs information which shows that Alice is trying to close the channel with an older fraudulent state.
This honest Approval node then broadcasts together the fraudulent approval chain and the oracles’ signed fraud proof to the Consensus layer. The Consensus layer verifies that Eve was either negligent or malicious in her actions and revokes Eve’s node’s status as an approver and and gives the honest Approval node her collateral.
If Eve understands the network, she will most likely refuse Alice’s request to assist in cheating as she is likely to get caught with severe financial penalties.
One thing to note from this example is that we have not described any penalties to Alice for attempting to post a fraudulent transaction. Without this, Alice may be able to keep trying to post the fraudulent transaction until she gets a sequence of Approval nodes which are all compromised. A direct financial penalty may not be possible unless we require all users to maintain collateral. In addition to any additional dispute mechanisms for settled on-chain transactions, the best we can do may be a reputation system would could either be recorded on-chain or in the Oracle layer. If an entity has very bad reputation, the consensus layer can possibly reject any transaction coming from it.
SUMMARY
We have analyzed the lifecycle of Bitcoin transactions and how it led to the development of the Lightning Network. We also examined how the issue of watchtowers limits the truly decentralized usage of the Lightning Network, especially for those which could benefit from it the most. We addressed these limitations directly and ended up with a high level network architecture of 3 layers: Consensus, Approval, and Oracle, while still leaving room for many critical architectural decisions such as consensus mechanisms and incentives.
BONUS
The topics in this section do not directly result from creating a protocol to solve the issue of delegated watchtower accountability. However we will examine a few other issues related to the Lightning Network and how we may be able to address them in our hypothetical network. The ideas are exploratory (not as well thought out) and may not be feasible or require more background than presented here.
Payment Channel State Storage
Payment channels require the users to store their latest channel states and fraud proofs offline. This naturally raises concerns about backing this data up. On the mainchain, all that one needs to recover funds is the seed-phrase. If you lose your payment channel information and fraud proofs, you are vulnerable to payment channel closure fraud.
We described how the Oracle layer can store a hash of the transaction as a fraud proof for the whole channel. In theory the user does not need to store it themselves anymore because they can always get it from the Oracle layer. Can we have the Oracle layer store the channel state itself?
Yes. And this acts as a fraud proof in just the same way that the hash does. When the Approval node queries the Oracle layer, it will make sure that the transaction the user is closing the channel with is the exact same transaction in the Oracle layer. There is no hashing step now. And if the user loses their offline copy of latest channel state, the user can ask the Oracle layer and recover them.
However, this means that the fraud proofs are now dynamic in size and there are privacy concerns. Anyone can now see the state of your payment channels by querying the Oracle layer.
What if we used the encrypted channel state as the fraud proof? When a user attempts to close a channel, the Approval layer will encrypt the transaction and then compare it to what it queries from the Oracle layer. The issue here, unlike with unencrypted channel state, is that the the fraud proofs from the two sides of a payment channel are not the same. The Oracle layer would not know that the two encrypted channel states are really for the same state.
We could have the Oracle store both the hash of the transaction for the and the two encrypted channel states. If the user lost their offline data, but still had the key. They could ask the Oracle layer and decrypt their channel states.
As we incorporate more functionality into the Oracle layer and continue to increase the variability and amount of data they need to store, it may make sense to add incentives into our network for a Storage layer and off-load that from the Oracle layer.
Routing & Liquidity Lending
We briefly mentioned that Lightning allowed for users to make payments through a series of intermediary payment channels as long as there is enough liquidity in the right direction. Because payment channels are interactive and require the receiver to provide a signature, we ideally want our intermediaries to be stable and have high uptimes.
Approval nodes could possibly use part of their collateral to open up payment channels with the other Approval nodes, forming the backbone for routed payments. For intermediaries in routed payment networks, the number of coins you receive in one channel is the same as the number of coins you send in another. What this means is that the Approval node collateral remains constant and the node is never under-collateralized.
In order to provide exit liquidity to a non Approval node or when one intermediary needs to settle to the main chain (e.g. a counter party goes down), an Approval node could provide its latest channel states to other Approval nodes, which then query the Oracle layer to confirm that the node maintains the required collateral in payment channels, which would allow the consensus layer to approve the exit liquidity, either as a direct payment or opening a payment channel.
Off-chain Conditional Payments
The flexibility of our transaction scripting language could allow us to create Outputs which are conditionally spendable based on Oracle answers. In the case of dispute, the Approval node could, as always, consult the Oracle layer. For those wishing to learn more about this area, Discreet Log Contracts are a good starting point.
FIN
As of this transmission, we have not yet observed that your human civilization has created the necessary technology. We are waiting. Your future is bright.
To find your way, look to the stars.
Puzzle: 62c018beac044f39bffa3161cf33511f938d713ce392676e10ef352aba56a087
