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... On Jan 23, 2014, at 7:02 PM, Kumar McMillan <[email protected]> wrote: > > On Jan 23, 2014, at 6:03 PM, Daniel Buchner <[email protected]> wrote: > >> On Thursday, January 23, 2014 11:51:59 AM UTC-8, Kumar McMillan wrote: >>> On Jan 23, 2014, at 1:03 PM, Daniel Buchner <[email protected]> wrote: >>> >>> >>> >>>> This is a non-issue. While any app can declare as a handler for a web >>>> activity, the user must explicitly select the app they want to use to >>>> complete the activity. The Bitcoin wallet apps in question are a lot like >>>> a user's banking app, let me use this similar banking example to >>>> illustrate two major reasons why this concern is unwarranted: >>> >>>> >>> >>>> 1) The user has a bank account for their fiat dealings - let's assume they >>>> bank with Wells Fargo. It's highly unlikely a user would install any app >>>> besides Wells Fargo to do their banking. This fact implicitly eliminates >>>> much of the concern. >>> >>>> >>> >>>> 2) But let's assume for some reason they install Evil Bank's app. Evil >>>> Bank's app declares a web activity handler, and now appears in the user's >>>> list of apps for that activity. Still, this is meaningless. Remember, not >>>> only must the user select a malicious app, but also have *funds already in >>>> it*. The latter is incredibly unlikely, and faces an untenable chicken and >>>> egg problem: the user must be fooled into first putting funds into Evil >>>> Bank, before Evil Bank could possibly "send funds to the wrong person". >>> >>>> >>> >>> >>> >>> I might be missing some details to fully understand this. Let's say a user >>> installs their trusted bitcoin payment app. Let's say a game calls the web >>> activity to start a payment using their wallet ID (which is only valid with >>> one of a few instant payment processors, correct?). When the user selects >>> their payment app from the picker, what would the payment flow look like? >>> Does the user need to manually enter the bitcoin address of the recipient? >>> How do they know they are entering the right address? Does something in >>> chrome pass the wallet ID securely to the app handling the payment? >>> >> >> 1) The game would offer up its own wallet ID when asking for payment, >> correct. This wallet ID does not need to be affiliated with a payment >> processor to get near-instant processing and confirmation. > > Ahh, ok. So how is this wallet ID different than a bitcoin address? Who > controls wallet IDs? I was confused about how a wallet ID might be associated > with Coinbase or BitPay. I was mistaken here. A "wallet ID" is just a standard bitcoin address according to protocol. > >> Here's how that works: >> >> - The game sends its wallet ID, plus an unique string as the message portion >> of the payload, to whatever payment app the user chooses. >> >> - The payment app prompts the user to sends the game's wallet the desired >> amount, this amount and the wallet ID are included in the web activity's >> data object and do not need to be entered by the user. > > When the user is bounced to the payment app, what do they see? Do they see a > scrambled string of text (the recipient's wallet ID) or does it say "you are > about to pay Game X" ? How can the user trust/verify that they are really > about to pay Game X? 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. > >> >> - The payment app completes the transaction to the game's supplied wallet >> ID, having encoded within its message value the unique string supplied by >> the game. >> >> - The payment app sends back the success event via the postResult() method, >> this message contains the transaction ID generated by the blockchain that >> corresponds to this transfer. >> >> - The game receives this success message and can use the transaction ID to >> confirm with the blockchain itself that the transaction occurred and the >> correct amount was paid. Depending in the app/game's desired number of block >> confirmations (confidence level), the confirmation can be very quick. Here's >> the API to do this all from the client: >> http://blockchain.info/api/blockchain_api > > I see. How long would it typically take to gain a good level of confidence > that the payment went through? dbuc said one could reach a basic level of verification in 10-15 seconds. That still seems a little slow to me but it might be usable. > >> >> Using web activities, and the flow outlined above, the app/game need not run >> any server to accept and confirm successful payments. > > That's pretty cool. > >> >>> >>> I'm still curious as to what a receipt would look like because I think that >>> part is important. How would a merchant be able to instantly verify that >>> the payment went through when they get the onsuccess callback? If a wallet >>> ID is something specific to Coinbase or BitPay, how do they know to verify >>> the transaction? >>> >> >> The receipt is a combination of a completed transaction ID and any meta data >> passed by the game they need to identify what was purchased. All of this can >> be found via the blockchain API located here: >> http://blockchain.info/api/blockchain_api. Regardless of what service the >> user leverages for their wallet, it does not need to know to verify >> anything, it simply needs to invoke postResult() when it has completed its >> flow. The verification is between the app/game and the block chain. > > 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. -Kumar > Thanks for all the details. This is interesting. > > > -Kumar > >> _______________________________________________ >> 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
