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; 
Date: Sat, 13 Dec 2014 02:34:58 +0000
From: Peter Todd <pete@petertodd.org>
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)
Subject: [Bitcoin-development] Near-zero fee transactions with hub-and-spoke
	micropayments
Precedence: list


--/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
        <timeout> CHECKLOCKTIMEVERIFY OP_DROP
    ELSE
        <payee> CHECKSIGVERIFY
    ENDIF
    <payor> 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--