Satoshi's Vision

From lightningwiki.net
Revision as of 07:00, 14 January 2019 by ZmnSCPxj (talk | contribs) (Created page with "Satoshi's Vision is often quoted. Aside from the fact this phrase is based on a blind religious following of some kind of "one true way", it is helpful to realize that the...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Satoshi's Vision is often quoted. Aside from the fact this phrase is based on a blind religious following of some kind of "one true way", it is helpful to realize that the original Satoshi client included an insecure implementation of update systems.

Today, update systems (Poon-Dryja, Decker-Wattenhofer, and Decker-Russell-Osuntokun) are used as the basis of Lightning Network payment channels. While the original Satoshi whitepaper did not include a description of any kind of transaction update system, the original Satoshi client included such a system in nSequence.

Original nSequence

Each input of a transaction has an nSequence field. In modern Bitcoin, this field is now used to impose a relative time, measured from the block confirmation of the output being spent by the specific input, as well as to signal RBF.

However, in original Satoshi client, the intent of this field was different. The mempool was programmed such that if a new transaction arrived that consumed the same inputs as an existing transaction, the client would only accept the new transaction (and remove the old transaction) if the new transaction had every conflicting input with a higher nSequence. Then a "final" tranaction could be made by setting nSequence to the maximum value (0xFFFFFFFF), signalling that it would not be replaceable.

Intended Micropayment Channel Behavior

The intent was that a transaction which used nSequence would "open a tab", which would be closed when the transaction was finalized, or when the transaction was confirmed.

For instance, suppose some customer wanted to pay for drinks at a bar. The customer would create a transaction spending some of their coins, but with nSequence = 0. The customer would then transmit it over the network and the bartender would then release the drink to the customer.

On the next drink, instead of the customer spending from the change output of the previous transaction to create a new transaction, the customer would re-issue a new transaction spending the same coins (plus possibly new coins if the previous coins in total could not cover the total money) with a higher nSequence. So at the next drink, a new transaction with nSequence = 1 would be created, giving more money to the bartender.

This would continue until the latest transaction got confirmed, or the customer decided to go home. If the customer wanted to "close the tab" it would simply reissue the last transaction with nSequence = 0xFFFFFFFF. Since that is the largest number possible, the bartender knew that there would never be future transactions and would simply keep the final transaction alive in the mempool until it got confirmed.

Such a construction is very similar to modern micropayment channels. Thus, at the very start of Bitcoin, a system to support a "layer 2" payment system was already part of the client. This means that the idea of moving payments offchain and batching multiple small payments into a single large onchain payment, were already part of the intended Bitcoin system.

Insecurity of original nSequence

Although the above was the intended behavior, incentives at the miner level did not have this behavior. In particular, once a transaction is confirmed, fullnodes cannot "reverse" the transaction if it turns out that a transaction with higher nSequence exists. Miners were instead incentivized to accept transactions with higher fees (either explicitly on the transaction, or via a direct payment elsewhere). It was this realization (that miners would prefer to ignore nSequence and take whichever version had the highest fee) that lead to modern RBF. Indeed, modern "opt-in" RBF is signalled by a non-0xFFFFFFFF nSequence, indicating that the transaction could be replaced.

In particular, before the tab is closed, the customer could bribe the miner to confirm an older version of the transaction with lower nSequence. Because of this misalignment of incentives, the above construction could not be safely used at all.

However, this same insecurity lead to research for actually secure micropayment channels. That research has culminated in modern Lightning Network, which is a non-custodial secure micropayment channel protocol including support for inter-channel payment forwarding.