W3C home > Mailing lists > Public > public-webpayments@w3.org > December 2014

Re: Zero Click Bitcoin Micropayments using HTTP 402

From: Anders Rundgren <anders.rundgren.net@gmail.com>
Date: Sat, 27 Dec 2014 05:32:13 +0100
Message-ID: <549E364D.4080105@gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>, Mark Leck <markpleck@gmail.com>
CC: Steven rowat <sn0281@uniserve.com>, Web Payments CG <public-webpayments@w3.org>, Eric Martindale <eric@bitpay.com>
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>> 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
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?

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


> 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>> 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 04:32:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:07:37 UTC