Re: Zero Click Bitcoin Micropayments using HTTP 402

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 00:26:43 UTC