Aakselrod at 17:18, 12 March 2013

2013-03-12T17:18:30Z

Aakselrod at 21:03, 11 March 2013

2013-03-11T21:03:08Z

@@ Line 1: / Line 1: @@
 == 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<ref>https://bitcointalk.org/index.php?topic=91732.0</ref>.  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 [[Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|micropayment channels]] between payers, payees, and intermediaries in order to allow such transactions.
+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 [[Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|micropayment channels]]<ref>https://bitcointalk.org/index.php?topic=91732.0</ref> or other multi-signature transaction-based shared property<ref>https://bitcointalk.org/index.php?topic=94674.0</ref> 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.
@@ Line 8: / Line 8: @@
 * Additional scalability of micropayment channel setup transactions by having intermediaries combine them
-* Two-step 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
+* 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 open and closed
+* 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.
 == Micropayment Channels ==
-The original concept of the micropayment channel is explained well on the [[Contracts]] page.  One issue for current attempts at implementation of these proposal is that transaction replacement is not currently enabled on the Bitcoin network.  This makes it more difficult to prevent denial of service (locking up money, potentially permanently depending on whether it's for ransom or not) by an intermediary or a party to a 2-of-2 escrow transaction.
+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.
-This proposal is designed to work around the current lack of transaction replacement on the network.  It can likely be made simpler and more effective against such DoS attacks when transaction replacement is enabled.  A future version of this proposal may include the changes that would be necessary to improve the design by the use of transaction replacement.
+. 899.99 BTC to: SHA256 Hash<sub>m</sub> EQUALVERIFY Pubkey<sub>Carol</sub> CHECKSIGVERIFY
-Two types of proposals have been suggested to discourage and/or make expensive denial of service attacks:  risk deposits<ref>https://bitcointalk.org/index.php?topic=118418.msg1271858#msg1271858</ref> and reputation systems<ref>https://bitcointalk.org/index.php?topic=134827.0</ref>.  This proposal uses both techniques to help reduce the risk.
+When Bob sees that a payment has come through, he broadcasts <code>m</code> to Alice and Carol, committing the transaction.  Bob can't redeem his output without revealing <code>m</code>, so he has no incentive to keep it from the other parties.
-Risk deposits are designed to make it unprofitable to blackmail or ransom a micropayment channel peer to pay
+== References ==
 <references/>

Aakselrod: Draft proposal of a decentralized, peer-to-peer payment clearing network which uses Bitcoin for settlement and bitcoins as a unit of account

2013-02-02T05:22:01Z

Draft proposal of a decentralized, peer-to-peer payment clearing network which uses Bitcoin for settlement and bitcoins as a unit of account

New page

== 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<ref>https://bitcointalk.org/index.php?topic=91732.0</ref>. 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 [[Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party|micropayment channels]] 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-step 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 open and closed

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

== Micropayment Channels ==

The original concept of the micropayment channel is explained well on the [[Contracts]] page. One issue for current attempts at implementation of these proposal is that transaction replacement is not currently enabled on the Bitcoin network. This makes it more difficult to prevent denial of service (locking up money, potentially permanently depending on whether it's for ransom or not) by an intermediary or a party to a 2-of-2 escrow transaction.

This proposal is designed to work around the current lack of transaction replacement on the network. It can likely be made simpler and more effective against such DoS attacks when transaction replacement is enabled. A future version of this proposal may include the changes that would be necessary to improve the design by the use of transaction replacement.

Two types of proposals have been suggested to discourage and/or make expensive denial of service attacks: risk deposits<ref>https://bitcointalk.org/index.php?topic=118418.msg1271858#msg1271858</ref> and reputation systems<ref>https://bitcointalk.org/index.php?topic=134827.0</ref>. This proposal uses both techniques to help reduce the risk.

Risk deposits are designed to make it unprofitable to blackmail or ransom a micropayment channel peer to pay
<references/>

User:Aakselrod/Draft - Revision history

Aakselrod at 17:18, 12 March 2013

Aakselrod at 21:03, 11 March 2013

Aakselrod: Draft proposal of a decentralized, peer-to-peer payment clearing network which uses Bitcoin for settlement and bitcoins as a unit of account