extended the history of payment channels and sorted out the order of things: unidirectional channels, ultra server, meni rosenfelds trusted network of channels and bitcoin-dev list of reactivating nsequence. text complete WIP and a stub
@ -30,11 +30,38 @@ The `nSequence` was intended to allow users to transmit updated versions of a t
Such a payment channel would then be valid as long as the transaction was not mined.
Satoshi Nakamoto envisioned this construction for the case of high frequency trading.(ref)
There were however some weaknesses in this initial formulation, which limited its potential. Firstly, the 'payment channel' would only be open until the transaction was mined by the miners, either limiting the duration the payment channel or handing control of the payment channel to the miners. Secondly, there was no economic incentive for miners to respect the `nSequence` number, making this mechanism effectivley useless.
There were however some weaknesses in this initial formulation, which limited its potential. Firstly, the payment channel would only be open until the transaction was mined by the miners, either limiting the duration the payment channel or handing control of the payment channel to the miners. Secondly, there was no economic incentive for miners to respect the `nSequence` number, making this mechanism effectivley useless.
The revocable Sequence maturity contracts which form the payment channels in the first version of the Lightning Network have taken part of their name from their property of fixing the nSequence field and making the latest version of the sequence of updates in the payment channel enforcable.
The Revocable Sequence Maturity Contracts (RSMC) which form the payment channels in the first version of the Lightning Network have taken part of their name from their property of fixing the nSequence field.
This is achieved by creating an economic incentive via a penalty mechanism if not the most recent transaction in thepayment channel is published to the Bitcoin network.
Effectively the most recent update of the payment channel (encoded as a bitcoin transaction) becomes enforcable in this way.
// find / add sources for some of the claimes
Already in July 2011 pseudonomous user hashcoin proposed on bitcointalk the usage of Timelocks via `nLockTime` to solve the custody problem of exchanges.
The idea was to be able to quickly trade / sell Bitcoin without the necessity to send all the bitcoins to the exchange in the first place.
Hashcoin effectively proposed what we would today call a unidirectional payment channel.
With this mechanism a user A could fund a multisig wallet between A and another user B together with a timelocked transaction sending all Bitcoin Back to A.
The funding tx would not be signed and broadcasted by A before B provided a signature for the spend.
Hashcoin imagined user B to be an exchange.
Whenever user A wanted to send Bitcoin to user B user A could create a newer spend of the funding transaction which would send less Bitcoin back to A and more bitcoin to B.
This transaction could not be mined without a signature from B so user A would send it to B and B would sign it but keep it private.
Keeping it private was crucial in case A wanted to send some Bitcoin again to B.
Since A never has both signatures for a spend of the multisignature wallet besides the timelocked refund transaction the and B would have no interest in publishing an old state since a newer state would send more money to B.
Before the Timelock expired A would not be able to have the refund transaction being mined into a block.
This would give B the security to receive more updates as long as the channel would be `open`.
This mechanism would allow two users to engage into several smaller transactions which all happened outside of the Bitcoin network.
While this construction of the unidirectional payment channel would have solved the custody problem of exchanges it was nevery widely implemented.
We can only speculate for reasons and guess that the overhead communication would have had to be standardized - as it is nowadays in the Lightning Network specification - which might have been too much overhead in the early days of Bitcoin.
Also as a payment channel this system was not too useful as the channel could only at total send the total amount of provided Bitcoin in the funding transaction.
Once the timelock was over or all Bitcoin were sent to B the channel would have to be closed.
The obvious idea of opening two channels one from A to B and one from B to A would not have helped as each of those channels would have to be closed and reestablished once it ran dry.
The core breakthrough for the Lightning Network to become a reallity was the ability to create payment channels which technically can live forever and can send money back and forth as often as the peers wish to in combination with routing payments among several channels.
Surprisingly both properties took quite some while until the community figured them out.
Technically speaking the unidirictional payment channel has all the important ingreedients (funding transaction to a 2-2 multisignature wallet, a transaction spending from the wallet encoding the balance, a timelock to allow refunding if the other side becomes unresponsive, off chain communication and the fact that no additional trust other than the one in the bitcoin network) of modern payment channels which are used in the Lightning Network.
Despite being rather useless in todays world we will study the unidirectional payment channel in more depth in this book as it is an easy to understand educational example to approach the construction of todays payment channels.
This setup hat one safety issue as transactions have been malleable without the segwit upgrade.
A problem that needed to be solved for any payment channel construction that we know up till today and which has been fixed in August 2017.
During the first couple of years, the Bitcoin network was growing and the focus of many enthusiasts was on adoption, rather than the blocksize and scaling. However, in 2012 Gavin Andresen proposed the Ultra Transaction server on his blog.
The Ultra Transaction server was proposed to be a trusted partner of a 2-2 multisig wallet that could not steal funds but allowed signing transactions from a 2-2 multisig wallet.
@ -43,10 +70,26 @@ Andresen noted that there might be a better construction which would require les
Andresen's work led to many discussions on Bitcointalk forum, and later on the bitcoin-development mailing list. These discussions resulted in the first construction of the first unidirectional payment channels.
** 2012 http://web.archive.org/web/20190730234737/http://gavintech.blogspot.com/web/20150510204329/http://gavintech.blogspot.com/2012/07/off-chain-transactions.html[[Blogpost by Gavin Andresen]]
** (Mike Hearn, Jeremy Spilman 2013 - http://web.archive.org/web/20190501234757/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
to sum this up: Andresen used a similar construction as the unidirectional channel.
They key difference was that a trusted party would have co-signed the spend of the funding transaction.
The Ultra Server was not able to steal Bitcoin.
Shortly later Meni Rosenfeld discussed how these ideas could have been combined.
As Hashed Timelocked Contracts have neither been invented nor seen to solve the issue of trustless routing Rosenfeld imagined trusted routing nodes.
Without mentioning the term network or routing of payments the idea of connecting payment channels and being able to send funds from anyone to anyone else even if there was no direct channel was born.
In Rosenfelds solution payment providers would be the ultraservers and they would among themselves settle the transactions based on trust.
It took us another 3 years until the lightning network whitepaper emerged which had solved all the bits and bolts necessary to get rid of the trust in Rosenfelds solution.
It was in 2013 that Bitcoin developer Mike Hearn refered to Meni Rosenfelds proposal and stated that he knew from Satoshi that the `nSequence` field was supposed to be used for high frequency trading.
Hearn suggested to reactivate the `nSequence` field which Satoshi preiviously had deactivated.
Also Hearn refered to a section on the contracts article talking about the case of micropayment channels with the help of `nSequence`
Rene Pickhardt
5 years ago