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 payments which require no additional confirmations, higher scalability due to individual payments 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 instantly, 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 escrowed payments 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 payment solutions have also been proposed using different mechanisms. These potential solutions are out of scope for this proposal, which focuses on chained micropayment 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 micropayment channels, the original scheme for 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 payment which is chained through multiple micropayment channels. Hashm is then called the commit hash for the off-chain payment which goes through this chain of 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, the commit hash for the payment, 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 payment 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 payment, 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, the preimage of the payment's commit hash, to Alice and Carol, committing the payment. Bob can't redeem his output without revealing m, so he has incentive not to keep it from the other parties. Risk deposits can be structured in such a way that the incentive to broadcast m in a successful transaction should outweigh the incentive not to broadcast.

Additional applications can be considered as well. For an escrow transaction, as an example, Bob can generate a signed invoice for Alice to pay and its hash is h. Alice would generate a cryptographically strong random number r. Alice would then concatenate the two, m = h . r, and hash m. Then Hashm is the commit hash for the transaction which Alice would give to Bob so he knows what payment to expect for the invoice. Alice can send the payment's first phase, which would lock in funds through a chain of micropayment channels, wait for Bob to deliver the goods, and give Bob r. In this way, the payment is linked to the invoice.

For a gambling transaction similar to SatoshiDice, where Bob is a SatoshiDice-like gambling site, Alice can create a cryptographically strong random r, which is the preimage to the commit hash. Alice would send a payment to Bob and immediately commits it by broadcasting r. Bob would then concatenate w . r, where w is the hash/string/etc. for the time period during which the transaction occurs, and hash it to get the number used to determine whether the play wins or not.

The preimage to the commit hash can be used to carry all sorts of varied information; however, in the event of large amounts of data, the preimage should itself be a hash of that data, potentially concatenated with a random number as above. This reduces the amount of data to transmit across the payment channel and the amount of data potentially committed to the block chain should one of the recipients in the chain of micropayment channels decide to settle the channel with that commit hash.

Alice, Bob and Carol are nodes in a directional graph, while the micropayment channels between them are edges. It's easy to see how to extend such a chain to more than two micropayment channels by adding more intermediaries. Regardless of the number of intermediaries between the payer and payee, the payment can be proposed and committed almost instantly with no impact on the block chain and no possibility of double spend.

Fees could be charged for two separate actions: establishment of a micropayment channel, in order to offset the transaction fees for getting the contract in the block chain, and each payment, in order to offset operating costs and cost of capital to lock up money in a payment flow until it's committed or rolled back.

One can also imagine a long chain in which, for some reason (possibly malice), a payment is committed and an intermediary node X doesn't receive the broadcast of the preimage of that payment's commitment hash. If that occurs and another node Y broadcasts a T2_Y transaction with that payment's commitment hash in an output to the Bitcoin network, node X can immediately broadcast its T2_X transaction with the same commitment hash. Then, when node Y or the peer node for its micropayment channel redeems their output from the T2_Y transaction, or X's peer node redeems its output from the T2_X transaction, X can redeem its output.

Routing and Reputation in the Block Chain

In the micropayment channel scheme, T1 is broadcast and committed to the block chain to create the channel. In this proposal's modified scheme, T2, which redeems T1's only output, is not broadcast until the channel is to be closed and settled. Thus, routing and reputation information exists on the block chain. It is prunable as all transaction outputs are redeemable and should be redeemed; however, intermediate nodes which need to route payments through the network should keep the entire block chain in order to be able to extract routing and especially reputation information from it.

There would exist a set of participant public keys which have participated in micropayment channels before. Any transactions in the format of T1 that are not yet redeemed by a transaction of format T2 may be considered open channels. In most cases, the directionality of the micropayment channel should be identifiable by the amounts contributed by each key: the key which contributes more is likely to be the sender, and the key which contributes less is likely to be the recipient. This should be the case even when risk deposits are used between sender and recipient.

In addition, T1 transactions whose outputs haven't been redeemed for too long, or T2 transactions committed to the block chain whose outputs haven't been redeemed could be considered negative reputation information. Successful transactions can be considered positive reputation information. A PageRank-style iterative convergence algorithm can establish both a web of trust and a routing graph showing trust/channel relationships between various intermediaries.

When deciding to find a new peer with which to maintain open micropayment channels, various strategies can be considered based on both the reputation and routing information presented in the block chain. A node could choose to peer with more central intermediaries to make it cheap to send funds through that node; a node could also choose to peer with underserved parts of the graph (detectable by frequency of establishment/closure of channels to that part of the graph) in order to make money by making transmission to that part more efficient.

Using the block chain for extracting routing and reputation information does not preclude using external sources of routing and reputation information or using other methods of storing/extracting such information from the block chain.

Potential Optimizations and Side Effects

It is possible to make most users' nodes on such a peer-to-peer network function similarly to SPV nodes on the main Bitcoin network. The end user nodes would manually decide to establish a channel with a small set of intermediaries. There would be no or minimal trust involved due to the structure of the micropayment channel and the ability to withhold commitment of a payment until the payer is sure it has been routed correctly to the payee. Such users would benefit from having an SPV-style connection to the peer-to-peer network in order to open and close micropayment channels with the manually chosen set of intermediary nodes.

Intermediary nodes could be run by hobbyists/enthusiasts who want to make money by supporting the network, as well as businesses which desire reduced transaction costs on their own inbound and outbound payments and profit from processing others' payment flow. Such intermediaries would be well-served by running full nodes on the Bitcoin network in order to keep up-to-date track of routing information, as well as to have access to all historical information for optimization and reputation purposes.

Intermediaries on the receiving side can combine T1 transactions from multiple micropayment channels' senders in order to reduce transaction fees. For example, if Alice and multiple parties like her would each like to establish a micropayment channel to Carol, each would use one of her unspent transaction outputs to sign an output using SIGHASH_SINGLE | SIGHASH_ANYONECANPAY. Alice's output would be the value of Alice's input PLUS the value of whatever risk deposit Carol is willing to put in. Carol would then combine all of the inputs and outputs, add her own inputs to make up the value of the risk deposits plus fees to get the transaction included in a block, and broadcast it. Once the transaction has enough confirmations, Carol can begin allowing payments to flow through the newly established channels.

A functioning network would serve to balance costs, efficiency and decentralization. The longer a chain of micropayment channels a payment must go through, the more funds it locks up on its way temporarily and the more fees it would need to pay. For escrow transactions where the funds are locked up for a longer time, it may be more cost-effective to perform the transaction on the block chain, depending on the transaction fees. However, longer micropayment channel chains mean more decentralization. One can imagine a network graph with well-capitalized, well-connected nodes run by large corporations providing cheaper, more centralized payment flow while niche and local nodes provide less centralized payment flow which trades cost or distant node reachability for decentralization and privacy.

A network such as this may encourage intermediaries and businesses to run full nodes on the Bitcoin network, and allows them to collect fees for processing payments without having to mine. This may help fund full nodes on the Bitcoin network by allowing them to charge off-chain clearing fees, whereas miners charge settlement fees for committing transactions to the block chain.

A network such as this may increase the exchange rate of bitcoins against other currencies as it would lock up bitcoins in micropayment channels in order to provide payment flow, thus reducing the number of available bitcoins to sell for other currencies. Early adopters can additionally profit by using their bitcoin capital to provide payment flow. Merchants using existing transaction processors would be able to benefit from the network without needing to make any changes, as long as the transaction processors establish a connection to the network.

As proposed by cjp, path splitting is a viable option to make more efficient use of micropayment channels that are too narrow to allow large payments through them. However, this may increase Bitcoin transaction fees for intermediary micropayment channel re-establishment, making large payments more economical to send using Bitcoin directly. The decision should be made by the payer and payee based on cost and whether instant payment is required or waiting for confirmations is acceptable.

Widespread use of a network such as this would reduce, but not eliminate, the need to increase the Bitcoin block size. For example, assume a billion users of such a network, being paid directly on the block chain bi-weekly, each of whom immediately commits the entire payment to a micropayment channel to their preferred, centralized intermediate node. Each year, there would be 26 billion outputs added to the block chain for payroll, 26 billion T1 outputs and 52 billion T2 outputs for the micropayment channels. That's 104 billion outputs per year, or on average 1,978,691 outputs per block, or 3,298 transactions per second, not counting setup and teardown of intermediary micropayment channels and the uneven time distribution of payroll transactions.

Privacy and Centralized Control

One can imagine a future in which Bitcoin is widely adopted and a network based on this proposal to be widely used for clearing instant payments. It's possible that a governmental entity could regulate part of a network by mandating the following whitelist conditions:

1. Merchants, end users and intermediaries within the jurisdiction MUST use a key signed by the government's CA, providing identifying information for such a signature
2. Merchants, end users and intermediaries within the jurisdiction MUST establish micropayment channels with ONLY other nodes using keys signed by the government's CA
3. Merchants and intermediaries within the jurisdiction MUST track the initial source, final destination and possibly entire path of payment flow

One can also imagine a somewhat separate but similar network, where:

1. Most nodes live on Tor or in jurisdictions friendly to financial freedom and privacy.
2. Many end users and local/niche businesses run intermediary nodes for the benefit of their friends, family and community with a commitment not to log information.
3. All or some keys on the network are ephemeral, and each time a micropayment channel closes and settles on the block chain, the output of the settlement transaction is sent at least once through a network providing 3-party mixing transactions. This may necessitate additional routing information outside the block chain as well as additional anti-DoS risk management solutions. This also provides for the potential of intermediaries having multiple keys at the same time, allowing them to create "hidden" links in micropayment channel chains and further improving privacy.

It would be difficult to move bitcoins directly between the two networks without being tracked; however, one can imagine that a market would develop in helping to facilitate and hide such movement. The fact that such a market would develop and be difficult if not impossible to stop would hopefully prevent most governments from attempting to establish rules such as above. In a worst-case scenario, "free" bitcoins will be worth more than "government-controlled" bitcoins and the market would be mostly one-way, laundering "government-controlled" bitcoins into the free network until the values equalize.

Conclusions

This proposal details the synthesis of several ideas described by hashcoin, Meni Rosenfeld, Mike Hearn, cjp, retep, and additional individuals into a mechanism for two-phase commits across chains of micropayment channels, allowing for instant clearing and settlement on the block chain. A decentralized peer-to-peer micropayment network utilizing the side effect of routing and reputation information stored in the block chain is also described. Its scaling properties in the real world may make it viable for micropayments currently, and with increased block size, may make it viable for wide-scale everyday use in retail commerce. Potential points of control and monitoring, as well as countermeasures thereto, are briefly explored. Potential side effects on the Bitcoin network are also explored.