Re: Zero Click Bitcoin Micropayments using HTTP 402

On 27 December 2014 at 01:33, Mark Leck <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.  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> 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
>>
>>
>>
>>
>>
>>