-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
On 10 April 2014 06:44:32 GMT-04:00, Tamas Blummer <ta...@bitsofproof.com> wrote: >Thanks, Peter and you convinced me. I run away with a thought. > >It’d be great to find a spot to deploy payment channels, but I agree >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 and from payors and payees. So long as the person you want to pay is connected to the same hub as you are, or in more advanced versions connected via a ripple style chain, you can push payment to the hub and get proof they did the same for the recipient. Your loss is always limited to the incremental payment amount and payment is essentially instant. Of course, it's got some disadvantages compared to standard bitcoin transactions - its less decentralised - but when compared to other forms of off-chain payment in most situations its a strict improvement, and having the capability available is always a strict improvement. Like fidelity bonded banks the trust required in the hubs is low enough that with some minor 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 hold the tokens for some amount of time to thwart timing analysis, leaving you somewhat vulnerable to theft, but in that case fidelity bonded banking principles can be applied. Other than that case the idea is probably made obsolete by micropayment hubs. Regulatory issues will be interesting... If you wind up with a few central 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 available to law enforcement and tax authorities, not to mention marketing and other data mining. Equally I suspect that if an alternative more decentralised 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 hubs. But all the same, if widely implemented this reduces pressure to raise the 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 correct, for the hub concept as well. Amir: You should think about adding the above to dark wallet. It'd be good if the protocols are implemented in an open and decentralised fashion first, 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 =aC39 -----END PGP SIGNATURE----- ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
