Re: Zero Click Bitcoin Micropayments using HTTP 402

On 27 December 2014 at 05:32, Anders Rundgren <anders.rundgren.net@gmail.com
> wrote:

> 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
> http://www.forbes.com/sites/andygreenberg/2014/02/25/
> bitcoins-price-plummets-as-mt-gox-goes-dark-with-massive-hack-rumored/
> 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?
>

Yes


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

Send a request over https or wss or regular http with a signature.  The
first 2 are built into the browser, the last would need some JS code.  I'll
be using (1) but have done (3) in the past.

If a 402 comes back, display a dialogue box to the user.  They then need to
top up their wallet (there's probably 1000+ ways of doing this, so I wont
mandate any one) -- I'd look at the implementations in this video or by
ripple for inspiration.  I also envisage a system where your balance
increases as you surf the web e.g. and view adverts.

After the balance is topped up you can view premium content and the AJAX
request will return (200) and display the content either inline or via a
redirect.  Many ways.


>
> Anders
>
>  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
>>
>>
>>
>>
>>
>>
>>
>