User:Aakselrod/Draft

Proposal Background and Summary

The basic concept of a peer-to-peer payment network which allows nodes to transact off the blockchain has been proposed before. Proponents see multiple advantages such as instant transactions which require no additional confirmations, higher scalability due to individual transactions taking place off the blockchain, and feasibility of widespread micropayments. The proposals use micropayment channels or other multi-signature transaction-based shared property schemes between payers, payees, and intermediaries in order to allow such transactions.

For example, if Alice is a customer and Bob is a merchant, Alice may have a micropayment channel open to Carol, her payment processor, who may have a channel open to Dan, Bob's payment processor, which also has a channel open to Bob. Alice would increment the allocation going to Carol through her channel by the amount she wants to pay Bob, and Carol and Dan would do the same down the line. Bob would then be paid, and none of this would hit the blockchain except as part of aggregate settlement transactions closing the micropayment channels.

This proposal aims to bring closer the realization of such a network by discussing the following solutions:

• Additional scalability of micropayment channel setup transactions by having intermediaries combine them
• Two-phase commit through multiple chained micropayment channels, reducing the risk that an intermediary will accept a payment but not forward it on and enabling two-party escrow transactions through the payment network
• Extraction of routing and reputation information from the blockchain and memory pool as a side effect of the way micropayment channels are opened and closed

The proposal will also discuss possible side effects of its adoption, both positive and negative.

Other potential off-chain transaction solutions have also been proposed using different mechanisms. These potential solutions are out of scope for this proposal, which focuses on chained microtransaction channels between payers, payees and intermediaries. Other types of solutions may have the potential to be combined with the solution detailed in this proposal.

Micropayment Channels

The original concept of the micropayment channel is explained well on the Contracts page in example 7, referenced above. Unlike the concept of shared property, these micropayment channels are unidirectional and must be created in pairs for bidirectional payment flow.

Transaction replacement is used in this scheme to prevent denial of service (locking up money, potentially permanently depending on whether it's for ransom or not) by the receiving side of a micropayment channel. Nodes running 0.8 and above treat non-final transactions as non-standard. This allows the recipient a high degree of confidence that a non-final timelocked transaction won't be stuck in the memory pool of most nodes and a final transaction meant to replace it will be mined first. While this is not the original design for transaction replacement, it should work similarly for many use cases.

To work with the current state of the network, the format of the T2 transaction defined in the scheme above must be changed slightly. The initial version of T2 would still be created the same way (potentially with a longer lifetime than just one day); however, subsequent versions of T2 would not have nLockTime set and would have a sequence number of UINT_MAX. The micropayment channel recipient does not sign or broadcast any intermediate versions of T2 until the channel is ready to be closed.

Two other types of proposals have been suggested to discourage and/or make expensive such denial of service attacks by either side of a micropayment channel: risk deposits and reputation systems. This proposal can use both techniques to help reduce the risk.

Two-Phase Commit

In order to allow two-phase commit for chained transaction, the original scheme for micropayment channels is modified slightly again with a construct similar to the trading across chains scheme. Specifically, the two T2 outputs would be in a format similar to the following:

1. SHA256 Hashm EQUALVERIFY Pubkeysender CHECKSIGVERIFY
2. SHA256 Hashm EQUALVERIFY Pubkeyrecipient CHECKSIGVERIFY

and the input scripts redeeming those outputs would be in a format similar to the following:

1. SIGsender m
2. SIGrecipient m

where m is a number of at least 256 bits agreed to by a payer and payee in a transaction which is chained through multiple micropayment channels. An example follows:

Alice would like to pay Bob 10 mBTC. Alice does not have a micropayment channel to Bob. However, Alice has a micropayment channel to Carol, and Carol has a micropayment channel to Bob.

Bob generates a 256-bit number m and gives its SHA256 hash to Alice. Alice has previously signed and sent to Carol a transaction T2_AC which contains an input from her and Carol's T1_AC and two outputs:

1. 90 BTC to: SHA256 h EQUALVERIFY PubkeyAlice CHECKSIGVERIFY
2. 10 BTC to: SHA256 h EQUALVERIFY PubkeyCarol CHECKSIGVERIFY

where h is a hash from a previous transaction which has gone through a similar process. Similarly, Carol has previously signed and sent to Bob a transaction T2_CB which contains an input from her and Bob's T1_CB and two outputs:

1. 900 BTC to: SHA256 h EQUALVERIFY PubkeyCarol CHECKSIGVERIFY
2. 100 BTC to: SHA256 h EQUALVERIFY PubkeyBob CHECKSIGVERIFY

where, again, h is a hash from a previous transaction, which could be different than the h in T2_AC.

Alice requests for Carol to send 10 mBTC to Bob on her behalf. When she requests this, she also signs and sends to Carol a new version of T2_AC as follows:

1. 89.99 BTC to: SHA256 Hashm EQUALVERIFY PubkeyAlice CHECKSIGVERIFY
2. 10.01 BTC to: SHA256 Hashm EQUALVERIFY PubkeyCarol CHECKSIGVERIFY

Carol will then notify Bob of an incoming payment and signs/sends to Bob a new version of T2_CB as follows:

1. 899.99 BTC to: SHA256 Hashm EQUALVERIFY PubkeyCarol CHECKSIGVERIFY
2. 100.01 BTC to: SHA256 Hashm EQUALVERIFY PubkeyBob CHECKSIGVERIFY

When Bob sees that a payment has come through, he broadcasts m to Alice and Carol, committing the transaction. Bob can't redeem his output without revealing m, so he has no incentive to keep it from the other parties.