1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
|
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 <pete@petertodd.org>) 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 <bitcoin-development@lists.sourceforge.net>;
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 <bitcoin-development@lists.sourceforge.net>;
Sat, 13 Dec 2014 02:35:00 GMT
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)
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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
<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--
|
