Re: Zero Click Bitcoin Micropayments using HTTP 402

If its not on the ledger, then I can safely say....It didn't happen.
On 27 Dec 2014 00:28, "Steven Rowat" <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
>
>
>
>
>
>