From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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: <0509477C-89F9-47C7-8820-29ACAD4A4A8E@bitsofproof.com> <534592E2.7040800@gmail.com> <5345986C.3040901@gmail.com> <77889B25-03D6-4401-A5FE-432976951F55@bitsofproof.com> <5EA7E1CA-2673-49D4-A1C4-015117E5133D@bitsofproof.com> <3DB84423-BAEB-4290-B43C-7A3B07141844@bitsofproof.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Thu, 10 Apr 2014 07:36:05 -0400 To: Tamas Blummer , Mike Hearn , 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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-----