- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Sat, 27 Dec 2014 10:48:59 +0100
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- CC: Mark Leck <markpleck@gmail.com>, Steven rowat <sn0281@uniserve.com>, Web Payments CG <public-webpayments@w3.org>, Eric Martindale <eric@bitpay.com>
- Message-ID: <549E808B.20808@gmail.com>
On 2014-12-27 09:27, Melvin Carvalho wrote: > > > On 27 December 2014 at 08:51, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote: > > On 2014-12-27 07:30, Melvin Carvalho wrote: > > > > On 27 December 2014 at 05:32, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com> <mailto:anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>>> wrote: > > On 2014-12-27 01:40, Melvin Carvalho wrote: > > > > On 27 December 2014 at 01:33, Mark Leck <markpleck@gmail.com <mailto:markpleck@gmail.com> <mailto:markpleck@gmail.com <mailto:markpleck@gmail.com>> <mailto:markpleck@gmail.com <mailto:markpleck@gmail.com> <mailto:markpleck@gmail.com <mailto:markpleck@gmail.com>>>> wrote: > > If its not on the ledger, then I can safely say....It didn't happen. > > Many bitcoin transactions happen off block today (exchanges, poker, tipping etc.). That's the only way to scale. Consider intelligent personal assistants that may need to do 1000s of tx per second vial algorithms, not all of these can make it to the block chain, only an aggregation of them. > > I intend to implement bitcoin transactions using HTTP 402 over AJAX with a client side X.509 certificate for strong security, making every browser a wallet. > > > This sounds a bit strange in my ears. Since there has been hacks > http://www.forbes.com/sites/andygreenberg/2014/02/25/bitcoins-price-plummets-as-mt-gox-goes-dark-with-massive-hack-rumored/ > it seems that BTCs depend on secure storage as much as any other payment mechanism, right? Is the X.509 certificate used for authenticating to a BTC server-wallet where you keep your BTCs? > > > Yes > > > Good. > > > If this is correct I still don't understand how you intend to supply the AJAX-code etc. when being at a merchant site unless we are talking about something that is actually a part of the browser like a plugin (which *still* is the #1 pain-point we are dealing with). > > > Send a request over https or wss or regular http with a signature. The first 2 are built into the browser, the last would need some JS code. I'll be using (1) but have done (3) in the past. > > > Here you lost me. You mean that the stuff needed is already built into the browser? > > > Yes > > The folks behind the demo you sent a link to do not seem to agree on that. > > > Why? They base their concept on a Chrome plugin extension. > > HTTP 402 can work with either client side wallets or server side wallets, or both! As I said there's probably 1000+ ways to implement it. The video in used an extension -- great idea. Ripple uses local storage and/or server side vaults -- works very well. I'm using X.509 client side certificates. It's all good. The difference is that the extension [presumably] either holds the URL to the server-wallet or holds the wallet itself which makes a huge difference from a UI perspective. > > Another implementer may use Web Crypto API, but from what you have told us, it may be so restrictive as to not be useful for decentralized payments. The Web Payment IG seems unconvinced that there is a problem :-) Anders > > Anders > > > If a 402 comes back, display a dialogue box to the user. They then need to top up their wallet (there's probably 1000+ ways of doing this, so I wont mandate any one) -- I'd look at the implementations in this video or by ripple for inspiration. I also envisage a system where your balance increases as you surf the web e.g. and view adverts. > > After the balance is topped up you can view premium content and the AJAX request will return (200) and display the content either inline or via a redirect. Many ways. > > > Anders > > Most of these tx will be off block but allow deposits / withdrawal on the block chain. > > On 27 Dec 2014 00:28, "Steven Rowat" <sn0281@uniserve.com <mailto:sn0281@uniserve.com> <mailto:sn0281@uniserve.com <mailto:sn0281@uniserve.com>> <mailto:sn0281@uniserve.com <mailto:sn0281@uniserve.com> <mailto:sn0281@uniserve.com <mailto:sn0281@uniserve.com>>>> wrote: > > On 12/22/14 11:35 AM, Eric Martindale wrote: > > Security of this type of scheme is pegged to the security of the > Bitcoin network – the cost of forging / capturing a specific private > key is the baseline for tools utilizing this technology. > > As for this implementation of zero-click, this is great work – but > certainly only a basic prototype. A more complete solution would be > based on a Payment Channel, a specific type of “Smart" Contract built > in Bitcoin. The developer of this implementation agrees > <https://www.reddit.com/r/Bitcoin/comments/2pyhnd/demo_video_of_working_zero_click_bitcoin/cn1qyd2?context=1>. > > The construction of a Payment Channel “Smart” Contract, using the > Bitcoin Protocol: > > 1. Client creates a public key (K1), collects public key from server (K2) > 2. Create and sign (but do not broadcast) the “maximum amount” > transaction (T1), requiring both the server and client’s signature > to be spent. > 3. Create a fallback refund transaction (T2) that spends the output > of T1 back the the client (a refund) – set a lock time (contract > duration), and supply this transaction, *unsigned*, to the server. > 4. The server signs T2 with its private key, K1’, and returns the > signature to the client. > 5. The client verifies the server’s signature from its previously > asserted K1. > 6. The client signs T1 and gives the signature to the server – which > broadcasts the transaction, locking in the “smart contract”. > 7. The client creates a new transaction, T3, with an input of T1, and > two outputs – K1 and K2. It starts with all value going to the K1 > output, or “zero value transacted”. > 8. The server verifies the output is in fact allocated to K2, and the > signature matches the client’s (K1). > 9. When a micro-transaction occurs, the client simply updates T3 with > a small increase in output to K2, resigns the transaction, and > provides the updated copy to the server. > > > Eric, I think I 'understand' Bitcoin at a very abstract level (only) -- how multiple network nodes, each with a time-stamped copy of the identical transaction, ensures no double-spending because there's a mathematically provable speed that the network will spread these identical records. Or something like that. :-) . And so far that's enough for me to be able to participate in what's going on. > > But this list of steps for the "Payment Channel 'Smart' Contract, using the Bitcoin Protocol" has stumped me. I can grasp parts of it but not the overview of what's being added here. Is there a way you can reduced this to a plain-language list of steps about how it works (and how it's superior to the Zero Click implementation?) > > I ask this on behalf of the hundreds of millions of people on the net who don't know what a 'client' is, how it's different from a 'server', and in addition don't care. And yet, they have money to spend, and want to do so safely and efficiently. How could this protocol be explained to them? > > I've read it two or three times, and I'll take a stab (which is inaccurate, I'm certain of that :-) ), but I mean something like: > > The customer authorizes a Total of money that is designated to be paid in bitcoin at the end of a set time period; but the customer, and the merchant, also authorize a refund to the customer of the Total amount. The customer then proceeds to accrue Charges from the merchant for incremental amounts that add up to less than that Total. When the time period is up, the collected amount of Charges is launched in the bitcoin network's ledger, and the rest (Total minus Charges) is 'refunded'; this remainder is internal to the relationship between the customer and merchant, and in fact never entered the bitcoin ledger. > > ?? > > Steven Rowat > > > > > > > > > >
Received on Saturday, 27 December 2014 09:49:30 UTC