From: Nathan Cook <nathan.cook@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: [Bitcoin-development] Bi-directional micropayment channels with CHECKLOCKTIMEVERIFY
Date: Fri, 9 Jan 2015 13:40:53 +0200 [thread overview]
Message-ID: <CAGNXQMSSCtgiyFEGHS2ufuc-RZcAtpEJyFpQMDmNKd1qEDq5qA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 5467 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 6160 bytes --]
next reply other threads:[~2015-01-09 11:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 11:40 Nathan Cook [this message]
2015-01-09 13:20 ` Mike Hearn
2015-01-09 13:22 ` Jeff Garzik
2015-01-09 13:42 ` Mike Hearn
2015-01-09 14:50 ` Gregory Maxwell
2015-01-11 18:56 ` Mike Hearn
2015-01-11 9:16 ` odinn
2015-01-09 13:26 ` Gregory Maxwell
2015-01-11 22:24 ` Peter Todd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGNXQMSSCtgiyFEGHS2ufuc-RZcAtpEJyFpQMDmNKd1qEDq5qA@mail.gmail.com \
--to=nathan.cook@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox