[ANN] Mobile Checkout is now active for ALL Bit-Pay Merchants

[BitPay Business Solutions]

If you've seen the video of our Mobile Checkout:

https://bit-pay.com/aboutMobile.html

we have now enabled Mobile Checkout for ALL Bit-Pay Merchants.

Login to your Bit-Pay account, and the URL for your mobile checkout will appear under your Merchant Profile page.  You can customize your app to show additional currency options and setup email or server:server notification.

Visit your URL from your mobile phone's browser and bookmark it.  If you have an account with us, login and try it now!

This works on all iPhones and Android phones.  For some reason it does not work on Blackberry, and I don't know anyone with a Windows Mobile device that can test it.

With the Mobile Checkout, you can request a specific amount in any currency, and present the customer with a QR code to scan and pay.  When the payment is received, you get an on screen alert.  You don't have to know anything about bitcoins to be able to take peoples money use this.  

[koin]

so how does your service handle the situation where the customer attempts to defraud using a race attack (spending two transactions simultaneously -- one valid one to the merchant, and a second attempt to spend the funds a second time to the attacker's own address)?
   

[BitPay Business Solutions]

Well since you are physically in the restaurant while you are making this purchase, and doing it from your own mobile phone, I assume the restaurant will handle the situation just as if you tried to pass off a $3 bill or a Nigerian credit card. 

That is to say, you could be:

1.  taken out the back door and promptly beaten by the staff
2.  kindly asked to pay another way
3.  told never to come back again

or probably all of the above.

[notme]

Well since you are physically in the restaurant while you are making this purchase, and doing it from your own mobile phone, I assume the restaurant will handle the situation just as if you tried to pass off a $3 bill or a Nigerian credit card. 

That is to say, you could be:

1.  taken out the back door and promptly beaten by the staff
2.  kindly asked to pay another way
3.  told never to come back again

or probably all of the above.

In that order too... beat first, ask questions later.

[Matthew N. Wright]

Nice.

[Meni Rosenfeld]

Well since you are physically in the restaurant while you are making this purchase, and doing it from your own mobile phone, I assume the restaurant will handle the situation just as if you tried to pass off a $3 bill or a Nigerian credit card. 

That is to say, you could be:

1.  taken out the back door and promptly beaten by the staff
2.  kindly asked to pay another way
3.  told never to come back again

or probably all of the above.

The restaurant can do all these things, but only if it knows you attempted a double-spend. Is the app able to detect double-spend attempts and inform the server of them?

[BitPay Business Solutions]

Well since you are physically in the restaurant while you are making this purchase, and doing it from your own mobile phone, I assume the restaurant will handle the situation just as if you tried to pass off a $3 bill or a Nigerian credit card. 

That is to say, you could be:

1.  taken out the back door and promptly beaten by the staff
2.  kindly asked to pay another way
3.  told never to come back again

or probably all of the above.

The restaurant can do all these things, but only if it knows you attempted a double-spend. Is the app able to detect double-spend attempts and inform the server of them?

Successfully executing a double-spend from a mobile wallet, while you are face-to-face with the other party, is very difficult, but I suppose people will try.  But we can monitor the network to watch transactions propagate.  Merchants can choose to wait for 1 block or 6 blocks if they prefer, but for a low-risk in-person transaction, this is not really necessary.

[Meni Rosenfeld]

Well since you are physically in the restaurant while you are making this purchase, and doing it from your own mobile phone, I assume the restaurant will handle the situation just as if you tried to pass off a $3 bill or a Nigerian credit card. 

That is to say, you could be:

1.  taken out the back door and promptly beaten by the staff
2.  kindly asked to pay another way
3.  told never to come back again

or probably all of the above.

The restaurant can do all these things, but only if it knows you attempted a double-spend. Is the app able to detect double-spend attempts and inform the server of them?

Successfully executing a double-spend from a mobile wallet, while you are face-to-face with the other party, is very difficult, but I suppose people will try.  But we can monitor the network to watch transactions propagate.  Merchants can choose to wait for 1 block or 6 blocks if they prefer, but for a low-risk in-person transaction, this is not really necessary.

Yeah, I don't think it's a very big risk, but we can't write it off entirely. People can use a modified mobile wallet app which automatically tries to double spend, so even looking exactly at what they do you wouldn't know it. It takes only a few seconds to detect on the receiving end, but I think it's important (maybe not with v1 of the software, but eventually) that the detection is performed, so that when there is a double spend the app flashes "The customer double-spent! Get him!"

[Steve]

The way I think about a bitcoin transaction is that at t0 (time zero) the risk of a double spend is fairly high…after just a few seconds, the risk drops off substantially and over time the risk approaches zero.  While we aren't doing it today, our plans are to use transaction radar (probably modified a bit to incorporate other risk assessment factors) and then immediately guarantee payment for the merchant for transactions up to a certain value that aren't showing any signs of being risky after a couple seconds.  Right now, we only guarantee that the merchant will get paid after a full six confirmations.  That can take up to an hour and in a few cases, many hours.  The merchant can decide whether the act immediately or wait on 1 or more confirmations.  We've yet to have a single instance of a double spend, but that doesn't mean there isn't a risk of it.

The only reason we haven't yet implemented these things is that we're still working on building other features that are more urgent. 

[CombustibleLemon]

Watching the video I was curious how this might work in a fast-paced restaurant on a busy friday night.

One feature I would love to see, is if there could be a number of slave accounts/phones that all paid into the same wallet, but could not spend from that wallet.  In this scenario the restaurant might have multiple mobile devices that they pay for, or the employees might even be able to use their own device.

Another feature would be if this same app could handle two wallets; then the server could have tips sent to a separate wallet, while the main payment was still sent to the restaurants wallet.  Otherwise the server just has to trust that their manager will pay yhem later without skimming off the top or tip sharing at all.

Daydreaming aside though...this looks incredible.  Very easy from the video, and I can just use my Mt Gox wallet to pay without issue.

[Meni Rosenfeld]

The way I think about a bitcoin transaction is that at t0 (time zero) the risk of a double spend is fairly high…after just a few seconds, the risk drops off substantially and over time the risk approaches zero.  While we aren't doing it today, our plans are to use transaction radar (probably modified a bit to incorporate other risk assessment factors) and then immediately guarantee payment for the merchant for transactions up to a certain value that aren't showing any signs of being risky after a couple seconds.  Right now, we only guarantee that the merchant will get paid after a full six confirmations.  That can take up to an hour and in a few cases, many hours.  The merchant can decide whether the act immediately or wait on 1 or more confirmations.  We've yet to have a single instance of a double spend, but that doesn't mean there isn't a risk of it.

The only reason we haven't yet implemented these things is that we're still working on building other features that are more urgent. 

Sure, what I'm trying to say is that you can get a better experience with a hybrid solution. Instead of having the customer wait 10 seconds until the risk you have a double spend is 0.01%, have him wait 1 second until the risk is 1%, and maintain the option to alert the merchant in case a double-spend is later detected - so he can sort it out with the customer.

I agree completely that this kind of thing isn't a high priority right now.

[Steve]

The way I think about a bitcoin transaction is that at t0 (time zero) the risk of a double spend is fairly high…after just a few seconds, the risk drops off substantially and over time the risk approaches zero.  While we aren't doing it today, our plans are to use transaction radar (probably modified a bit to incorporate other risk assessment factors) and then immediately guarantee payment for the merchant for transactions up to a certain value that aren't showing any signs of being risky after a couple seconds.  Right now, we only guarantee that the merchant will get paid after a full six confirmations.  That can take up to an hour and in a few cases, many hours.  The merchant can decide whether the act immediately or wait on 1 or more confirmations.  We've yet to have a single instance of a double spend, but that doesn't mean there isn't a risk of it.

The only reason we haven't yet implemented these things is that we're still working on building other features that are more urgent. 

Sure, what I'm trying to say is that you can get a better experience with a hybrid solution. Instead of having the customer wait 10 seconds until the risk you have a double spend is 0.01%, have him wait 1 second until the risk is 1%, and maintain the option to alert the merchant in case a double-spend is later detected - so he can sort it out with the customer.

I agree completely that this kind of thing isn't a high priority right now.

In the bitcoin network (and the bitcoin client software), there's nothing that tells you "this transaction is a double spend"…until there's a block that contains transactions that conflict with yours, you don't know for sure…you're just dealing with probabilities until then.  If a significant number of peers aren't reporting a transaction, it's an indicator that they might consider the transaction invalid.  There are other things you can look at to assess risk outside of the bitcoin network itself (perhaps it's a customer you've transacted with many times before…that would be another risk mitigator).  What you describe is basically what we do today…the merchant has the option to accept a transaction immediately and we will alert him if we later determine a transaction to be invalid.  It just that the merchant's risk doesn't go to zero until after 6 confirmations and we would like to dramatically shorten that timeframe in the future (such that for 99% of all transactions, the merchant's risk goes to zero in 3 seconds or less).

[Meni Rosenfeld]

The way I think about a bitcoin transaction is that at t0 (time zero) the risk of a double spend is fairly high…after just a few seconds, the risk drops off substantially and over time the risk approaches zero.  While we aren't doing it today, our plans are to use transaction radar (probably modified a bit to incorporate other risk assessment factors) and then immediately guarantee payment for the merchant for transactions up to a certain value that aren't showing any signs of being risky after a couple seconds.  Right now, we only guarantee that the merchant will get paid after a full six confirmations.  That can take up to an hour and in a few cases, many hours.  The merchant can decide whether the act immediately or wait on 1 or more confirmations.  We've yet to have a single instance of a double spend, but that doesn't mean there isn't a risk of it.

The only reason we haven't yet implemented these things is that we're still working on building other features that are more urgent. 

Sure, what I'm trying to say is that you can get a better experience with a hybrid solution. Instead of having the customer wait 10 seconds until the risk you have a double spend is 0.01%, have him wait 1 second until the risk is 1%, and maintain the option to alert the merchant in case a double-spend is later detected - so he can sort it out with the customer.

I agree completely that this kind of thing isn't a high priority right now.

In the bitcoin network (and the bitcoin client software), there's nothing that tells you "this transaction is a double spend"…until there's a block that contains transactions that conflict with yours, you don't know for sure…you're just dealing with probabilities until then.  If a significant number of peers aren't reporting a transaction, it's an indicator that they might consider the transaction invalid.  There are other things you can look at to assess risk outside of the bitcoin network itself (perhaps it's a customer you've transacted with many times before…that would be another risk mitigator).  What you describe is basically what we do today…the merchant has the option to accept a transaction immediately and we will alert him if we later determine a transaction to be invalid.  It just that the merchant's risk doesn't go to zero until after 6 confirmations and we would like to dramatically shorten that timeframe in the future (such that for 99% of all transactions, the merchant's risk goes to zero in 3 seconds or less).

Maybe not in the Bitcoin software (and that should be fixed), but certainly in the Bitcoin network - if there are two transactions claiming the same output (and they're not replacements or some other valid thing), that's a double spend attempt. It doesn't matter which of the two transactions end up in a block, the fact remains that the customer tried to scam you and should be held up for questioning.

You don't need to passively wait to see if your peers are reporting a transaction - you can (again, maybe not with current software) proactively query, "hey, do you know of any transaction conflicting with this transaction I have here?". If anyone says yes you know there's a double spend attempt. If after some seconds everyone says no there's a very good chance there's no such attempt. There's no need to wait 10 minutes for a block (though that of course can reduce the risk even further).

[BitcoinBug]

Maybe not in the Bitcoin software (and that should be fixed), but certainly in the Bitcoin network - if there are two transactions claiming the same output (and they're not replacements or some other valid thing), that's a double spend attempt. It doesn't matter which of the two transactions end up in a block, the fact remains that the customer tried to scam you and should be held up for questioning.

You don't need to passively wait to see if your peers are reporting a transaction - you can (again, maybe not with current software) proactively query, "hey, do you know of any transaction conflicting with this transaction I have here?". If anyone says yes you know there's a double spend attempt. If after some seconds everyone says no there's a very good chance there's no such attempt. There's no need to wait 10 minutes for a block (though that of course can reduce the risk even further).

If double spend transaction is published, you can try these techniques. That's why double spend transactions will have higher success rate if it's not public at all. Double spender could form a private relationship with a pool with 10% hashing power and send double spend transaction through an alternate channel. He could effectively have 10% bitcoins back on average on all 0-confirmation spends. Am I right?

[Meni Rosenfeld]

Maybe not in the Bitcoin software (and that should be fixed), but certainly in the Bitcoin network - if there are two transactions claiming the same output (and they're not replacements or some other valid thing), that's a double spend attempt. It doesn't matter which of the two transactions end up in a block, the fact remains that the customer tried to scam you and should be held up for questioning.

You don't need to passively wait to see if your peers are reporting a transaction - you can (again, maybe not with current software) proactively query, "hey, do you know of any transaction conflicting with this transaction I have here?". If anyone says yes you know there's a double spend attempt. If after some seconds everyone says no there's a very good chance there's no such attempt. There's no need to wait 10 minutes for a block (though that of course can reduce the risk even further).

If double spend transaction is published, you can try these techniques. That's why double spend transactions will have higher success rate if it's not public at all. Double spender could form a private relationship with a pool with 10% hashing power and send double spend transaction through an alternate channel. He could effectively have 10% bitcoins back on average on all 0-confirmation spends. Am I right?

Sounds about right. But a pool who does this will be quickly exposed, and in the future pools will probably not have the power to decide what goes in a block.

[Stephen Gornick]

This works on all iPhones and Android phones.

Does it work on iPad?

Is there a way to print a receipt?

[BitPay Business Solutions]

This works on all iPhones and Android phones.

Does it work on iPad?

Is there a way to print a receipt?

It works on an iPad but it is designed for fat fingers.  Open this link on your iPad to see it as an example

https://bit-pay.com/m/457631/checkout.html

If you can print from your iPad you can print the receipt on the screen. I have not figured this out personally, but it is possible.