* [Bitcoin-development] [ANN] Micropayment Channel Implementation
@ 2013-06-27 12:29 bitcoin-list
0 siblings, 0 replies; only message in thread
From: bitcoin-list @ 2013-06-27 12:29 UTC (permalink / raw)
To: bitcoinj, bitcoin-development
As of today, a full implementation of micropayment channels has been merged
onto bitcoinj's master branch (to be released in the next version). It is\rdesigned to make it easy for users to create payment channel servers and\rclients based on the design at\rPI-LINK-6c499aa2adefaed9ea649252cbaa3968f2bb2b5f,\rby creating a simple TCP socket and exchanging protobufs to initialize and\rmake payments.
It supports various levels of abstractions, allowing users to drive the\rstate machines which do basic channel init/verification themselves, allow\rbitcoinj to handle all the complexity of channel management/expiry/etc and\rsimply exchange protobufs over whatever whatever connection they wish to\rmake with the server, or let bitcoinj handle opening a TCP socket and do\rall the work. See\rPI-LINK-4b8ede03029716d56ef3df5b1586482eeaf7049f for\rdetails on how to use the implementation in bitcoinj.
A more full protocol description will be written up in the form of a BIP as\rthe code matures a bit more (with the hope that other implementations can\rappear), but, generally:
1. Client and server exchange version handshake, and client may\roptionally request that an existing channel be reopened (the channels last\rfor 24 hours by default, so if the connection gets killed, reopening an\rexisting channel is useful).
2. The protocol described on the wiki is followed, exchanging\r(canonical!) signatures and transactions until a multisignature contract is\restablished and broadcast which locks money into the channel, and a refund\rtransaction is created and signed which allows the client to spend the\rentire multisignature transaction to wherever they want\r(SIGHASH_NONE|SIGHASH_ANYONECANPAY) after some lock time (by default, 24\rhours). Both client and server store a copy of the channel in their wallet\rso that if the app itself crashes the refund transaction can still be\rbroadcast/the channel can still be resumed. At this point either the whole wallet should be backed up or the total value in payment channels at any\rgiven time should be kept reasonably low (because payment channels are\rdesigned to combine micropayments into confirmable payments, this shouldn't be an issue)
3. The client increments payments by sending the server new signatures\rspending the multisig contract partially back to themselves and allowing\rthe server to do what they want with the rest\r(SIGHASH_SINGLE|SIGHASH_ANYONECANPAY).
4. When the client sends a CLOSE message or the channel approaches the\rrefund transaction unlock time, the server adds any necessary fees to the\rlatest payment transaction and broadcasts it, closing the channel, disconnecting the client if the connection is still open and removing the stored channel state from its wallet.
See https://code.google.com/p/bitcoinj/source/browse/core/src/paymentchannel.proto for the protobuf/protocol description.
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2013-06-27 12:47 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-27 12:29 [Bitcoin-development] [ANN] Micropayment Channel Implementation bitcoin-list
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox