On Jan 24, 2014, at 11:10 AM, Daniel Buchner <[email protected]> wrote:
> 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. That makes sense. So I guess the payment app will just show the bitcoin address hash and the price when you pay for the item. I'd like to see it in action but maybe it's acceptable to users since they are used to such obfuscated identifiers. > > >> 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! I understand that an app can verify a *transaction* using the bitcoin APIs but your original proposal ( https://gist.github.com/csuwildcat/8582556 ) didn't show how an app can safely pass metadata. It starts an activity like this : var activity = new MozActivity({ name: "crypto-payment", data: { type: "bitcoin", price: "0.50", currency: "USD", wallet: "1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj", callback: "https://somegame.com/reciepts.html"; } }); but I think it also needs some custom data like a local transaction ID so the merchant can look up metadata about the payment: var activity = new MozActivity({ name: "crypto-payment", data: { localTransId: "1234", ... } }); How can the merchant receive localTransId in the receipt object in a trusted way? Is there a way to get arbitrary metadata for a transaction back from the block chain API? http://blockchain.info/api/blockchain_api In mozPay we do this by signing the merchant's metadata with a shared key. The merchant can verify the signature with their copy of the key so they know the values have not been tampered with. > > > _______________________________________________ > dev-webapps mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
