summaryrefslogtreecommitdiff
path: root/61/16cb26036b536098860f2087d7a0c8943dd750
blob: cf5d986491b93284b8a9a78cdfd95e8ebb3bc456 (plain)
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
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1WYDHQ-0005o8-UX
	for bitcoin-development@lists.sourceforge.net;
	Thu, 10 Apr 2014 11:36:28 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.149.115 as permitted sender)
	client-ip=62.13.149.115; envelope-from=pete@petertodd.org;
	helo=outmail149115.authsmtp.co.uk; 
Received: from outmail149115.authsmtp.co.uk ([62.13.149.115])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1WYDHP-0006mm-Sb for bitcoin-development@lists.sourceforge.net;
	Thu, 10 Apr 2014 11:36:28 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s3ABaKhQ072500;
	Thu, 10 Apr 2014 12:36:20 +0100 (BST)
Received: from [25.121.248.92] ([24.114.49.14]) (authenticated bits=0)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s3ABaA9J018377
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 10 Apr 2014 12:36:16 +0100 (BST)
User-Agent: K-9 Mail for Android
In-Reply-To: <3DB84423-BAEB-4290-B43C-7A3B07141844@bitsofproof.com>
References: <CA+s+GJCn9U2kmyMH6w3o+m99NCfO0ws=SccvGBYJv07WVuF=eA@mail.gmail.com>
	<0509477C-89F9-47C7-8820-29ACAD4A4A8E@bitsofproof.com>
	<CANEZrP2Q=TG+jejEVFFh5FhjzDDkySHNSTfwtKueLcHu=pB6Kw@mail.gmail.com>
	<CA+s+GJBRvDFgktTgW2sCvAVahrjxcGqfgHw0BVNPvwUupotVrg@mail.gmail.com>
	<534592E2.7040800@gmail.com>
	<CAAS2fgS3q6N9go-NSKdjLwgU_5bFwa8YE88DcjNYHQTwzPCn3Q@mail.gmail.com>
	<5345986C.3040901@gmail.com>
	<CAAS2fgQyXHNnBDKoUMd_=-=1irGJ6cFKwi59enLJvFJiWBv50A@mail.gmail.com>
	<CAJna-Hj1U5cQ22bSXoNB-4ck_urCuS9xCk+iEHsbh+yv17MP7A@mail.gmail.com>
	<CANEZrP2w2b28qnYd7q=fo=VL0FzVE1R15s5Entuy+fK9x+V8Kg@mail.gmail.com>
	<CA+s+GJDcGxa_ARPFAbsd54cFhgBn8WcqNrRs00TZJBrNmvq5jQ@mail.gmail.com>
	<77889B25-03D6-4401-A5FE-432976951F55@bitsofproof.com>
	<CANEZrP1ELraedzEpME6E8s7kXy57RKtr6667_Ke7cvhvcc9W0Q@mail.gmail.com>
	<5EA7E1CA-2673-49D4-A1C4-015117E5133D@bitsofproof.com>
	<CANEZrP3tBnikpE99bTvTshiVDpRNJE8zKM1skPua2k2E7J=gRw@mail.gmail.com>
	<3DB84423-BAEB-4290-B43C-7A3B07141844@bitsofproof.com>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
From: Peter Todd <pete@petertodd.org>
Date: Thu, 10 Apr 2014 07:36:05 -0400
To: Tamas Blummer <tamas@bitsofproof.com>, Mike Hearn <mike@plan99.net>,
	genjix@riseup.net
Message-ID: <139aeadf-e58a-4852-b96b-a1c30780eb9c@email.android.com>
X-Server-Quench: 54e81e99-c0a4-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	bgdMdwIUGUUGAgsB AmIbWlZeU1t7WGs7 aQ5PbARZfE5HQQRu
	T0xPR01TWkZrcG5Q dxdkUhh6dAJBNnx1 ZkNiEHVfCUx7IE90
	Xx1URGkbZGY1a30W VBYJagNUcgZDfk5E aVUrVz1vNG8XDQg5
	AwQ0PjZ0MThBJSBS WgQAK04nCWwKAjU7 RhYOWDQpWEcMTCY8
	NRs7LFJUGUEdPw08 NkFpYmomUgAbDglT A1ol
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 24.114.49.14/465
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by punt18.authsmtp.com id
	s3ABaKhQ072500
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: 1WYDHP-0006mm-Sb
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for
	SPV	wallets
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: Thu, 10 Apr 2014 11:36:29 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 10 April 2014 06:44:32 GMT-04:00, Tamas Blummer <tamas@bitsofproof.com=
> wrote:
>Thanks, Peter and you convinced me. I run away with a thought.
>
>It=E2=80=99d be great to find a spot to deploy payment channels, but I a=
gree
>this is not it.

No problem!

I'm sure we'll see payment channels implemented sooner or later
the form of "hub and spoke" payment networks. The idea there is you have =
one or more centralised hubs who in turn have payment channels setup to a=
nd from payors and payees. So long as the person you want to pay is conne=
cted to the same hub as you are, or in more advanced versions connected v=
ia a ripple style chain, you can push payment to the hub and get proof th=
ey did the same for the recipient. Your loss is always limited to the inc=
remental payment amount and payment is essentially instant.

Of course, it's got some disadvantages compared to standard bitcoin trans=
actions - its less decentralised - but when compared to other forms of of=
f-chain payment in most situations its a strict improvement, and having t=
he capability available is always a strict improvement. Like fidelity bon=
ded banks the trust required in the hubs is low enough that with some min=
or effort applied to anti-DoS you could probably get away with using even=
 hubs run by anonymous actors, making the centralisation less important. =
(hubs are essentially interchangeable) Unlike pure fidelity bonded banks =
the effort required to build this is relatively minor!

You can even combine it with chaum tokens for anonymity. You'll want to h=
old the tokens for some amount of time to thwart timing analysis, leaving=
 you somewhat vulnerable to theft, but in that case fidelity bonded banki=
ng principles can be applied. Other than that case the idea is probably m=
ade obsolete by micropayment hubs.

Regulatory issues will be interesting... If you wind up with a few centra=
l payment hubs, without chaum tokens, those hubs learn all details about =
every transaction made. Obviously if a big actor like BitPay implemented =
this there would be a lot of pressure on them to make those records avail=
able to law enforcement and tax authorities, not to mention marketing and=
 other data mining. Equally I suspect that if an alternative more decentr=
alised version was implemented there would be strong government pressure =
for those approved hubs to not interoperate with the decentralised hubs, =
and equally for merchants to not accept payment from the decentralised hu=
bs.

But all the same, if widely implemented this reduces pressure to raise th=
e block size enormously, keeping the underlying system decentralised. So =
the net effect is probably positive regardless.

Oh yeah, credit goes to Mike Hearn for the payment channels, and if I'm c=
orrect, for the hub concept as well.

Amir: You should think about adding the above to dark wallet. It'd be goo=
d if the protocols are implemented in an open and decentralised fashion f=
irst, prior to vendor lock in.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQFQBAEBCgA6BQJTRoIlMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhW26B/9A9OtYjoSHo620XZzF
VqfnnVFCPr3DpD/HuT3JYhF1kkL2vTt5wkRIHmHmfJ29Sduj8St7EFiLOyUg2mvt
q9heZgzCnqxLJm9zMiiQnb3Y/plvhTLfaONnHI+OPSfrABL6DA04nEe8OBPuFfv/
NowJ74DP/65YBq3EqbqG0dJExKm1BhdrEpWNq0v5YoCVuEYkWgFHL8SdRHnfFyxA
XTkP8avzlG82r98k55IrV0O/6VQNHjE0+xF4EHjEYBacy6OwlpEYeLrqx/VDAQ5R
RufXeAltNZI0tzLQ8nY0aMBH3YFxF0+14/sbmOAtmnD6EW49gEcV9MnSJc5ct4m7
Szq5
=3DaC39
-----END PGP SIGNATURE-----