From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Y9XwQ-0006rm-UE for bitcoin-development@lists.sourceforge.net; Fri, 09 Jan 2015 11:41:22 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.180 as permitted sender) client-ip=74.125.82.180; envelope-from=nathan.cook@gmail.com; helo=mail-we0-f180.google.com; Received: from mail-we0-f180.google.com ([74.125.82.180]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Y9XwO-0000MR-7J for bitcoin-development@lists.sourceforge.net; Fri, 09 Jan 2015 11:41:22 +0000 Received: by mail-we0-f180.google.com with SMTP id w62so7483201wes.11 for ; Fri, 09 Jan 2015 03:41:14 -0800 (PST) X-Received: by 10.194.108.9 with SMTP id hg9mr30790935wjb.68.1420803674163; Fri, 09 Jan 2015 03:41:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.216.151.65 with HTTP; Fri, 9 Jan 2015 03:40:53 -0800 (PST) From: Nathan Cook Date: Fri, 9 Jan 2015 13:40:53 +0200 Message-ID: To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=047d7bf10b1c4b501f050c36a2eb X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (nathan.cook[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1Y9XwO-0000MR-7J Subject: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 11:41:23 -0000 --047d7bf10b1c4b501f050c36a2eb Content-Type: text/plain; charset=UTF-8 A limitation on most existing micropayment channel ideas is that payments can only flow in one direction. This is because the payment receiver can sign -any- transaction you send them, not just the most recent one, and so it's possible to just sign the transaction transferring the largest amount into their control. This is easily remedied by opening a second payment channel in the opposite direction, but now both parties have to deposit funds over the lifetime of the two channels. If one party doesn't know ahead of time whether or not the other party will go into credit, having only one channel may save the use of a deposit. I propose a way of using CHECKLOCKTIMEVERIFY to allow a reversible payment channel, introducing at most one additional broadcast transaction, with a waiting period before the payment receiver can access deposited funds. The extra transaction and waiting period apply only when the depositor doesn't co-operate with the receiver. In this protocol, the setup is identical, with a deposit made to a P2SH address matching a script allowing either single-party+CHECKLOCKTIME or 2-of-2. In this case, however, payments made by the depositor occur in the form of unbroadcast transactions to special -holding addresses-. These holding addresses are themselves P2SH addresses, with scripts known to both parties. Each script may be redeemed in one of two ways: by the payment receiver, using their signature with a CHECKLOCKTIME restriction that expires some period of time after the restriction on the depositor's refund transaction, or by the depositor, using their own signature, together with a hashlock. In the second case, we actually use a double hashlock, i.e. the depositor must provide a value which when SHA256-hashed twice produces the value in the script. The receiver generates these values according to the following algorithm: Beginning with a secret S_0, they double hash S_0 to make the hashlock value for the first payment, D_0 =H(H(S_0)). Then to make S_i+1 given S_i, they create a public nonce, N_i, and let S_i+1 = H(N_i | H(S_i)), where a|b denotes the string a followed by the string b. The hashlock values D_i are not secret, and can be disclosed in advance or as part of the process of receiving the associated payment. When the receiver wants to refund some amount to the depositor, the receiver finds the last payment which left the depositor with a balance -greater- than the desired balance, and negotiates a rewind of the payment sequence to that point, with an additional payment of the remainder by the depositor. Suppose the last payment that will remain valid was the i-th payment, counting from zero. The receiver creates a new nonce, N'_i, creates the associated new secret value S'_i+1 by S'_i+1 = H(N'_i | H(S_i)), and sends D'_i+1 to the depositor with a request for payment of the right amount. This amount will be greater than that associated to D_i, but less than that associated to D_i+1, so the depositor does not need to trust the receiver in order to honour the request. The payment chain is now forked at D_i, with a branch D_i+1, D_i+2... and a branch that only has D'_i+1. The receiver now unwinds the old branch, back to D_i, by revealing S_i+1 to the depositor. The depositor can now generate - and check - the secrets S_i+1, S_i+2..., and so knows that if the receiver attempts to sign and broadcast a transaction to an address using one of those secrets, the depositor can take back all their funds before the receiver is able to put their own (CHECKLOCKTIME restricted) transaction from that address on the blockchain. Now the best usable payment to the receiver is the one associated to D'_i+1. When the two parties want to close the payment channel, one party signs a transaction from the deposit address to whatever addresses are desired, and sends the transaction to the other party to add their own signature and publish. This avoids either party having to wait for CHECKLOCKTIME restrictions to expire. If either party abandons the protocol at this point, the other can use the CHECKLOCKTIME restrictions to ensure they get at least as much as they would if both cooperated. Note that the holding addresses are only used on the blockchain when the protocol is abandoned. This protocol does not deal with the case of malicious attacks on a party's network connection, which could keep them offline until CHECKLOCKTIME has expired. This is something that each party should consider when choosing how long the restrictions should be in place for. The protocol improves on blueadept's use of a new nLockTime for each reverse payment[1], by keeping the wait time independent of the number of payments, and not requiring either party to predict ahead of time how many payments will occur. A note on generating hashlock secrets: the protocol works perfectly well without generating them deterministically. Using an HMAC-style derivation is more of a convenience than anything else - it saves storing and transmitting all the secrets when a chain needs to be invalidated - but it does encode the fact that the addresses form a chain into the addresses' scripts, which is a nice property to have. [1] https://bitcointalk.org/index.php?topic=814770.msg9185225#msg9185225 I first posted this at https://bitcointalk.org/index.php?topic=918018.0 and have edited it slightly for posting on this list. Thanks to Peter Todd for the suggestion to submit it here for review. Nathan Cook --047d7bf10b1c4b501f050c36a2eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A limitation on most existing micropayment channel id= eas is that payments can only flow in one direction. This is because the pa= yment receiver can sign -any- transaction you send them, not just the most = recent one, and so it's possible to just sign the transaction transferr= ing the largest amount into their control. This is easily remedied by openi= ng a second payment channel in the opposite direction, but now both parties= have to deposit funds over the lifetime of the two channels. If one party = doesn't know ahead of time whether or not the other party will go into = credit, having only one channel may save the use of a deposit.

I propose a way of using CHECKLOCKTIMEVERIFY to allow= a reversible payment channel, introducing at most one additional broadcast= transaction, with a waiting period before the payment receiver can access = deposited funds. The extra transaction and waiting period apply only when t= he depositor doesn't co-operate with the receiver.

=
In this protocol, the setup is identical, with a deposit made to a P2S= H address matching a script allowing either single-party+CHECKLOCKTIME or 2= -of-2. In this case, however, payments made by the depositor occur in the f= orm of unbroadcast transactions to special -holding addresses-.
<= br>
These holding addresses are themselves P2SH addresses, with s= cripts known to both parties. Each script may be redeemed in one of two way= s:
by the payment re= ceiver, using their signature with a CHECKLOCKTIME restriction that expires= some period of time after the restriction on the depositor's refund tr= ansaction, or
by the= depositor, using their own signature, together with a hashlock.
=
In the second case, we actually use a double hashlock, i.e. = the depositor must provide a value which when SHA256-hashed twice produces = the value in the script.

The receiver generates th= ese values according to the following algorithm: Beginning with a secret S_= 0, they double hash S_0 to make the hashlock value for the first payment, D= _0 =3DH(H(S_0)). Then to make S_i+1 given S_i, they create a public nonce, = N_i, and let S_i+1 =3D H(N_i | H(S_i)), where a|b denotes the string a foll= owed by the string b. The hashlock values D_i are not secret, and can be di= sclosed in advance or as part of the process of receiving the associated pa= yment.

When the receiver wants to refund some amou= nt to the depositor, the receiver finds the last payment which left the dep= ositor with a balance -greater- than the desired balance, and negotiates a = rewind of the payment sequence to that point, with an additional payment of= the remainder by the depositor. Suppose the last payment that will remain = valid was the i-th payment, counting from zero. The receiver creates a new = nonce, N'_i, creates the associated new secret value S'_i+1 by S= 9;_i+1 =3D H(N'_i | H(S_i)), and sends D'_i+1 to the depositor with= a request for payment of the right amount. This amount will be greater tha= n that associated to D_i, but less than that associated to D_i+1, so the de= positor does not need to trust the receiver in order to honour the request.= The payment chain is now forked at D_i, with a branch D_i+1, D_i+2... and = a branch that only has D'_i+1. The receiver now unwinds the old branch,= back to D_i, by revealing S_i+1 to the depositor. The depositor can now ge= nerate - and check - the secrets S_i+1, S_i+2..., and so knows that if the = receiver attempts to sign and broadcast a transaction to an address using o= ne of those secrets, the depositor can take back all their funds before the= receiver is able to put their own (CHECKLOCKTIME restricted) transaction f= rom that address on the blockchain. Now the best usable payment to the rece= iver is the one associated to D'_i+1.

When the= two parties want to close the payment channel, one party signs a transacti= on from the deposit address to whatever addresses are desired, and sends th= e transaction to the other party to add their own signature and publish. Th= is avoids either party having to wait for CHECKLOCKTIME restrictions to exp= ire. If either party abandons the protocol at this point, the other can use= the CHECKLOCKTIME restrictions to ensure they get at least as much as they= would if both cooperated. Note that the holding addresses are only used on= the blockchain when the protocol is abandoned.

Th= is protocol does not deal with the case of malicious attacks on a party'= ;s network connection, which could keep them offline until CHECKLOCKTIME ha= s expired. This is something that each party should consider when choosing = how long the restrictions should be in place for. The protocol improves on = blueadept's use of a new nLockTime for each reverse payment[1], by keep= ing the wait time independent of the number of payments, and not requiring = either party to predict ahead of time how many payments will occur.

A note on generating hashlock secrets: the protocol works= perfectly well without generating them deterministically. Using an HMAC-st= yle derivation is more of a convenience than anything else - it saves stori= ng and transmitting all the secrets when a chain needs to be invalidated - = but it does encode the fact that the addresses form a chain into the addres= ses' scripts, which is a nice property to have.

[1] https://bitcointalk.org/index.php?topic=3D8= 14770.msg9185225#msg9185225


Nathan Cook
--047d7bf10b1c4b501f050c36a2eb--