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; 
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>
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for
	SPV	wallets
Precedence: list

-----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-----