From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XzcY0-0006Mc-Rr for bitcoin-development@lists.sourceforge.net; Sat, 13 Dec 2014 02:35:08 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.161 as permitted sender) client-ip=62.13.148.161; envelope-from=pete@petertodd.org; helo=outmail148161.authsmtp.com; Received: from outmail148161.authsmtp.com ([62.13.148.161]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XzcXy-0002M0-US for bitcoin-development@lists.sourceforge.net; Sat, 13 Dec 2014 02:35:08 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBD2Z0Yd040153 for ; Sat, 13 Dec 2014 02:35:00 GMT Received: from muck (185.24.122.211.bcube.co.uk [185.24.122.211] (may be forged)) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id sBD2YwvA087533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sat, 13 Dec 2014 02:35:00 GMT Date: Sat, 13 Dec 2014 02:34:58 +0000 From: Peter Todd To: bitcoin-development@lists.sourceforge.net Message-ID: <20141213023458.GA961@muck> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="/9DWx/yDrRhgMJTb" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: a285ce14-8270-11e4-9f74-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgZ1 JB0aXVBSFQF4AR4L BRsUUhk8dg1DZnx0 e0dgXG5ZXUVlcE56 XU8aVh9yZw4nLhEf WEdddAAaeQtIdlEU aFh6ByYMZXgPZH1g WlZqMmx0bDsAdGEN GltQfAobGB1WEmUq YR0LB3A9EFcCDys+ IlQ6MFcaB08aLkQ1 N0BpRlMEM1cSFwcb FkdBRTRBIFoMDy8q BhldRUcPFTBbXTw0 X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 185.24.122.211/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1XzcXy-0002M0-US Subject: [Bitcoin-development] Near-zero fee transactions with hub-and-spoke micropayments 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: Sat, 13 Dec 2014 02:35:08 -0000 --/9DWx/yDrRhgMJTb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable =46rom the So-Obvious-No-one-Has-Bothered-to-Write-It-Down-Department: tl;dr: Micropayment channels can be extended to arbitrary numbers of parties using a nearly completley untrusted hub, greatly decreasing transaction fees and greatly increasing the maximum number of financial transactions per second that Bitcoin can support. So a micropayment channel enables a payor to incrementally pay a payee by first locking a deposit of Bitcoins in a scriptPubKey of the following form: IF CHECKLOCKTIMEVERIFY OP_DROP ELSE CHECKSIGVERIFY ENDIF CHECKSIGVERIFY (obviously many other forms are possible, e.g. multisig) Once the funds are confirmed, creating txout1, the payor creates transactions spending txout1 sending some fraction of the txout value to the payee and gives that half-signed transaction to the payee. Each time the payor wants to send more money to the payee they sign a new half-signed transaction double-spending the previous one. When the payee is satisfied they can close the channel by signing the most recent, highest value, tx with their key, thus making it valid. If the payee vanishes the payor can get all the funds back once the timeout is reached using just their key. Since confirmation is controlled by the payee once the initial deposit confirms subsequent increases in funds sent happen instantly in that the payor can not double-spend the input until the timeout is reached. (there's another formulation from Jeremy Spilman that can be almost implemented right now using a signed refund transaction, however it is vulnerable to transaction mutability) Hub-and-Spoke Payments =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Using a nearly completely untrusted hub we can allow any number of parties to mutually send and receive Bitcoins instantly with near-zero transaction fees. Each participant creates one or two micropayment channels with the hub; for Alice to send Bob some funds Alice first sends the funds to the hub in some small increment, the hub sends the funds to Bob, and finally the hub gives proof of that send to Alice. The incremental amount of Bitcoins sent can be set arbitrarily low, limited only by bandwidth and CPU time, and Bob does not necessarily need to actually be online. The worst that the hub can do is leave user's funds locked until the timeout expires. Multiple Hubs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Of course, hubs can in turn send to each other, again in a trustless manner; multiple hops could act as a onion-style privacy scheme. The micropayments could also use an additional chaum token layer for privacy, although note that the k-anonymity set involves a trade-off between privacy and total # of Bitcoins that could be stolen by the hub. Of course, in general the micropayment hub breaks the linkage between payor and payee, with respect to the data available from the blockchain. Capital Requirements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A business disadvantage with a hub-and-spoke system is that it ties up capital, creating a tradeoff between fees saved and Bitcoins tied up. How exactly to handle this is a business decision - for instance opening the micropayment channel could involve a small initial payment to account fo rthe time-value-of-money. Embedded consensus/Colored coins =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Note how many embedded consensus schemes like colored coins are compatible with micropayment channels. (though have fun figuring out who deserves the dividends!) --=20 'peter'[:-1]@petertodd.org 000000000000000012367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622 --/9DWx/yDrRhgMJTb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJUi6XOAAoJECSBQD2l8JH71/gIAIFKbZNitV/w9glxxC7ekQ0C kFz097WpJYAiQRG6nHq9+ZmNqth/kVur+IhJF3qpWbVG6IqNgBGfiMj54cASVhAx ouLD4Ce8j/IqGHnkLIukSd6GwvGU0nxOrRBS1SCVXE4IDiHUsNGqkOTZDPOqNHQJ ClxWlxz/fy99axIG5DwsykgGvxGgdSrTEicNYF2sEoutrAOwhFE6ua6U3tYfFWPp r7iLSud6QhMi5xE6GHBG0JLnIiyPX6nf8Co7ufwzpC3NBFu2/biHEUg0qRgMXPEx B47wbWx+rivgwd5PwF5CaHXmhL4HNZu92uq3hLila8vnZ84jUc459knuBl1VWfs= =RICL -----END PGP SIGNATURE----- --/9DWx/yDrRhgMJTb--