On Friday, January 24, 2014 7:15:40 AM UTC-8, Kumar McMillan wrote: > Since some others have shown interest in bitcoin I wanted to reply inline to > a few questions that dbuc answered for me on IRC. > > > > I had also asked this: what does a web activity provide the web that it > doesn't already have? All these bitcoin providers, like coin base, already > have merchant tools that let you easily embed a bitcoin payment button on a > web page. Example: https://coinbase.com/docs/merchant_tools/payment_iframes > However, they are all provider specific, there's nothing (maybe there is?) > that implements the generic bitcoin protocol. > > > > If we add this web activity, the merchant doesn't have to strike up an > explicit relationship with a bitcoin provider. This is huge. They could > operate independently by exposing just their bitcoin address at which they'd > like to be paid. The web platform would *delegate* the payment process to an > app of the user's choosing. Many apps could become bitcoin payment handlers. > The user would install the one they like the most. I still think there are > some details to work out though... >
Great Kumar, what you've echoed here is correct - and I agree, merchant-provider transfers without an explicit relationship is HUGE, somewhat of a payments holy grail. Let me try to answer/correct the following outstanding items: > I'd still like to see how a bitcoin payment app can help you verify that a > bitcoin address belongs to who you think it does. This is important because > in today's bitcoin pay flow, the user is in direct control of entering the > address (as I understand it). In this new web activity flow, the user has > less control; they must trust that the merchant passed the right address > through the web activity data and that the payment app hasn't been > compromised. > To the point about manual wallet address entry by users: most solutions today do not make users enter anything. Existing payment flows in the crypto-currency realm generally prefill all that data. In the case of provider specific iframes, they have devs put the data in as URL params and prefill from those values. Of course this flow, using web activities, makes that all even easier! The Bitcoin protocol does not have a defined way to attached a real-world ID to a wallet address, but wallet addresses can carry metadata. Because the app itself is responsible for invoking the payment web activity, there is no conceivable reason, short of their app being compromised, that they would send the wrong wallet address to the payment app over the web activity's data object. I would argue worrying about how a developer deals with not getting paid because they had a security hole is a fringe case, that we have little control over. Similarly, on the side of the payment app, if that is compromised a user and that payment app - regardless of if it is Bitcoin, PayPal, or other - has a lot more to worry about than using an incorrect address. TLDR: if either app is fundamentally hacked, there's really not a lot we can do - but that's not a Bitcoin problem, that's an every app problem. > If the app is receiving a post result it has to somehow trust that result. > For a very popular game (let's say it uses a server), a malicious user might > have incentive to root their phone and hack the app's source code to trick > the app into giving them a free or reduced price item. I assume the app can > do the block chain verification server side for added trust. But how does it > trust that the unique string has not been tampered with? When it looks up a > transaction on the block chain does it get back the unique string? It sounds > like the unique string would only be passed as a parameter to postResult() > which means a malicious user can purchase an item for $0.99 and tamper with > the unique string changing the item ID to one of $24.99 (allowing them to get > a better item). How would the app detect that the unique string had been > tampered with? > > I'm still not clear on how a merchant could trust its callback string (named > unique string in this thread). It has to use a callback string to get the > details about the item: price, quantity, etc. Is this metadata built into the > bitcoin transaction and thus part of the verified block chain check? If so, > that would solve my concerns. If it's simply passed as another data item to > postResult() then I don't see how the merchant can reliably trust it. > The reason the app/game can trust the transaction address it receives from the payment app in the onsuccess even, is that it is *verifiable* on the blockchain. As I posted yesterday, the merchant would use any number of free, clientside, blockchain transaction APIs to verify that the purchase is valid, successful, was for the correct amount, etc. All that data is available to be checked, because the blockchain is an *open ledger*. Here's how the merchant checks and verifies these aspects of a transaction: http://blockchain.info/q As you see above, you can near-instantly check: - If the transaction is real - If it was confirmed on the blockchain - How much it was for - When it occurred - How many confirmations it has (confidence interval) The system would work as advertised (though I welcome further peer review), and it puts clientside-only payments in the realm of reality <-- it cannot be overstate how HUGE this is for clientside apps! _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
