lightningwiki.net - User contributions [en]

Satoshi's Vision

2019-01-14T07:00:24Z

ZmnSCPxj: 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..."

[[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 <code>nSequence</code>.

== Original <code>nSequence</code> ==

Each input of a transaction has an <code>nSequence</code> 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 <code>nSequence</code>.
Then a "final" tranaction could be made by setting <code>nSequence</code> to the maximum value (<code>0xFFFFFFFF</code>), signalling that it would not be replaceable.

=== Intended Micropayment Channel Behavior ===

The intent was that a transaction which used <code>nSequence</code> 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 <code>nSequence = 0</code>.
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 <code>nSequence</code>.
So at the next drink, a new transaction with <code>nSequence = 1</code> 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 <code>nSequence = 0xFFFFFFFF</code>.
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 <code>nSequence</code> ===

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 <code>nSequence</code> 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 <code>nSequence</code> and take whichever version had the highest fee) that lead to modern RBF.
Indeed, modern "opt-in" RBF is signalled by a non-<code>0xFFFFFFFF</code> <code>nSequence</code>, 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 <code>nSequence</code>.
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.

Channel Factory

2019-01-12T03:32:56Z

ZmnSCPxj: Created page with "A Channel Factory is a multiparticipant non-custodial cryptocurrency system that contains channels. == Blockchains as multiparticipant cryptocurrency system == A blo..."

A [[Channel Factory]] is a multiparticipant non-custodial cryptocurrency system that contains [[channels]].

== Blockchains as multiparticipant cryptocurrency system ==

A blockchain manages a state called the "UTXO set". The UTXO set is effectively a multimap from addresses (which may represent singlesig pubkeys or multisig pubkeys) to Bitcoin values. Each transaction deletes some entries in this multimap and creates new entries. For example, suppose ZmnSCPxj owes KEabZAYi 1.0 BTC. Suppose currently the UTXO set contains "ZmnSCPxj: 2.0". ZmnSCPxj can create a transaction and have the blockchain system process it, then the UTXO set then contains "ZmnSCPxj: 1.0, KEabZAYi: 1.0". Each blockchain transaction effectively is an update to the state of the UTXO set.

Blockchains have open membership sets (anyone can participate), but with the drawback that any increase in its processing capacity translates to a decrease in its openness and usability.

== Channels as multiparticipant cryptocurrency systems ==

A channel is a multiparticipant cryptocurrency system which is similar to a blockchain, except with a fixed membership set. It can also only be updated if all participants are online and willing to continue updating (the rules of the channel are imposed by the participants by refusing to participate in invalid updates). Finally, a channel can fall back to a lower-level cryptocurrency system (such as a blockchain) in order to enforce any rules by forcing enforcement to a lower-level system.

For example, suppose ZmnSCPxj and KEabZAYi have a channel originally created by ZmnSCPxj. On the blokchain level, the blockchain sees something like "ZmnSCPxj+KEabZAYi: 2.0". However, inside the channel, both ZmnSCPxj and KEabZAYi have agreed that the state is "ZmnSCPxj: 2.0, KEabZAYi: 0.0". Suppose that ZmnSCPxj owes KEabZAYi 1.0 BTC. Then both of them can agree that new channel state is "ZmnSCPxj: 1.0, KEabZAYi: 1.0". After both of them agree on the update, however, only the channel state is changed; the state of the blockchain is ''not'' changed and there is no transaction made on the blockchain layer. The blockchain layer remains with the state "ZmnSCPxj+KEabZAYi: 2.0".

The security of a channel is dependent on each user looking out for its own interests and refusing to allow updates that it does not intend. For example, even if KEabZAYi proposes to change the state to "ZmnSCPxj: 0.0, KEabZAYi: 2.0" afterwards, if ZmnSCPxj is not intending to pay that, then ZmnSCPxj will simply refuse to sign the new state and the channel state does not change.

Because channel security is based on self-interest rather than trust in some custodian, there is no need for a large membership set (like those required for custodial systems like federated sidechains) in the hope that the majority of the membership set is honest (and without having to hope that the members are not sybils). Instead, simply being able to veto any invalid updates is enough. Thus, channels may safely have as few as 2 participants. In fact, 2 participants is ideal since every participant of the channel must be online in order to update the channel state; it is far more likely that 2 participants are online, than 3 or 4 or more.

== Channel factories as channels within channels ==

Of note is that a channel itself, while needing some other cryptocurrency system to fall back to, imposes nothing else on the lower-layer cryptocurrency system other than the ability to assign money to a multisignature address.

Now suppose we have a channel with three participants, ZmnSCPxj, KEabZAYi, and AoywPQUw. At the blockchain layer, it might be represented as the UTXO "ZmnSCPxj+KEabZAYi+AoywPQUw: 4.0". However, inside this 3-participant channel, it might have the state "ZmnSCPxj: 4.0, KEabZAYi: 0, AoywPQUw: 0".

Now suppose ZmnSCPxj proposes to create two channels ''inside'' the 3-participant channel, and all participants agree that such an operation is valid. So now the 3-participant channel contains the state "ZmnSCPxj+KEabZAYi: 2.0, ZmnSCPxj+AoywPQUw: 1.0, ZmnSCPxj: 1.0, KEabZAYi: 0, AoywPQUw: 0".

The two sub-channels inside the larger 3-participant channels have their own state indepedently of each other and of the 3-participant channel. The ZmnSCPxj+KEabZAYi channel would have the state "ZmnSCPxj: 2, KEabZAYi: 0", while the ZmnSCPxj+AoywPQUw channel would have the state "ZmnSCPxj: 1, AoywPQUw: 0". The 3-participant channel, since it creates factories, is now actually a channel factory.

Suppose AoywPQUw goes offline (for example, went to sleep). In that case, the 3-participant channel (the channel factory) is "locked" and its state cannot change. Now suppose ZmnSCPxj wants to pay KEabZAYi 1 BTC. Since AoywPQUw is offline, ZmnSCPxj '''cannot''' change the state of the 3-participant channel to "ZmnSCPxj+KEabZAYi: 2.0, ZmnSCPxj+AoywPQUw: 1.0, ZmnSCPxj: 0, KEabZAYi: 1.0, AoywPQUw: 0". However, ZmnSCPxj '''can''' change the state of the ZmnSCPxj+KEabZAYi subchannel to "ZmnSCPxj: 1.0, KEabZAYi: 1.0". This is because this sub-channel only requires the participation of ZmnSCPxj and KEabZAYi to update.

Thus, channel factories, by splitting up a multiparticipant channel to multiple 2-participant channels, give the advantage of 2-participant channels (i.e. only need two participants to be online to work).

At the same time, even though there are two channels (the ZmnSCPxj+KEabZAYi channel and the ZmnSCPxj+AoywPQUw channel), at the blockchain layer, only one UTXO is needed ("ZmnSCPxj+KEabZAYi+AoywPQUw: 4.0"). This reduces the capacity used on the blockchain layer.

If a channel factory had even more members, there may be dozens of channels hanging off a single blockchain UTXO, greatly multiplying the capacity of the blockchain for Lightning Network operation.

AMP

2019-01-12T02:55:07Z

ZmnSCPxj: fill in

{{Stub}}

'''Atomic Multipath Payments''' or [[AMP]] involves splitting up a single logical payment into multiple parts, then (possibly) sending each part via a different route.

Below are various proposals for AMP:

* OG AMP (Original AMP) - originally created by Olaoluwa Osuntokun and Conner Fromknecht; preimage is generated by payer, and split up in pieces and sent over each sub-payment. Sacrifices proof-of-payment and requires spontaneous payment.
* High AMP - proposed by ZmnSCPxj jxPCSmnZ; uses BIP32 hierarchical deterministic derivation, with the payee-generated payment point as the seed point and each sub-payment paying to a derived child point, revealing the derivation path to the payee. Revealing any of the derived child scalars also reveals the original payment scalar. Requires switching to points and scalars instead of hashes and preimages, which requires either Schnorr, 2p-ECDSA, or a complicated SCRIPT with 3 <code>OP_CODESEPARATOR</code>s; compatible with payment decorrelation.
* Base AMP - proposed by Antony Towns; just splits up the payment with the same hash in all sub-payments. Economically, the payee is selling the proof-of-payment for the entire payment; the price of the proof-of-payment is the total payment, so the payee is incentivized to take payments only once all pieces have reached it, and thus is "economically-incentivized atomic" instead of "information-theoretic" or "computationally-intractible" atomic.