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

Re: Zero Click Bitcoin Micropayments using HTTP 402

From: Eric Martindale <eric@bitpay.com>
Date: Mon, 22 Dec 2014 14:35:35 -0500
Cc: public-webpayments@w3.org
Message-Id: <AADF7078-B318-4A33-A1B8-7DA51BFC6F44@bitpay.com>
To: Steven rowat <sn0281@uniserve.com>
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.

The construction of a Payment Channel “Smart” Contract, using the Bitcoin Protocol:
Client creates a public key (K1), collects public key from server (K2)
Create and sign (but do not broadcast) the “maximum amount” transaction (T1), requiring both the server and client’s signature to be spent.
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.
The server signs T2 with its private key, K1’, and returns the signature to the client.
The client verifies the server’s signature from its previously asserted K1.
The client signs T1 and gives the signature to the server – which broadcasts the transaction, locking in the “smart contract”.
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”.
The server verifies the output is in fact allocated to K2, and the signature matches the client’s (K1).
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.
To close the contract, the server (or client) simply broadcasts the latest T3, which locks in the transacted amount and produces new spendable outputs.

These types of contracts would be established for the duration of a “session”, for example, a 24-hour access that increments T3 based on kilobytes transferred, or in this case, articles viewed.  This scheme allows for an instantaneous micro-update of a contract, without having to rely on confirmation for subsequent updates.

More details here:  https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party

Sincerely,

Eric Martindale
Developer Evangelist, BitPay
+1 (919) 374-2020

On Dec 20, 2014, at 11:32 AM, Steven rowat <sn0281@uniserve.com> wrote:

> On 2014-12-20, at 7:36 AM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:
> 
>> On 2014-12-20 15:36, Melvin Carvalho wrote:
>>> http://challengepost.com/software/zero-click-bitcoin-micropayments
>> 
>> Hi Melvin,
>> You mentioned the HTTP 402 thing before and I didn't got it.
>> Now I do, but this solution is really a service dealing with HTTP 402.
>> 
>> They didn't provide much details on how it works but I guess that's obvious for you bitconiers :-)
>> The question is if their protocol would stand a security review, my guess is that it would not.
> 
> Looks so beautiful and simple. There must be a problem -- security, browser buy-in, wait times for bitcoin confirmation. If not, I'm ready to start using it anytime. :-)
> 
> Here's a discussion by bitcoin people of this idea from two years ago, including some detail about all those issues, especially security. It's not exhaustive but for me at least it was good background.
> 
> https://bitcointalk.org/index.php?topic=3895.0
> 
> 
> Steven Rowat
> 
> 
> 
> 


Received on Monday, 22 December 2014 19:36:13 UTC

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