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

BitPay Business Solutions

hero member

Activity: 742

Merit: 500

Quote from: Stephen Gornick on March 21, 2012, 09:54:19 PM

Quote from: BitPay Business Solutions on January 21, 2012, 10:31:51 PM

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.

Stephen Gornick

legendary

Activity: 2506

Merit: 1010

Quote from: BitPay Business Solutions on January 21, 2012, 10:31:51 PM

This works on all iPhones and Android phones.

Does it work on iPad?

Is there a way to print a receipt?

Meni Rosenfeld

donator

Activity: 2058

Merit: 1054

Quote from: BitcoinBug on January 22, 2012, 02:07:35 PM

Quote from: Meni Rosenfeld on January 22, 2012, 01:39:55 PM

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.

BitcoinBug

full member

Activity: 196

Merit: 100

Quote from: Meni Rosenfeld on January 22, 2012, 01:39:55 PM

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

donator

Activity: 2058

Merit: 1054

Quote from: Steve on January 22, 2012, 01:06:43 PM

Quote from: Meni Rosenfeld on January 22, 2012, 12:32:34 PM

Quote from: Steve on January 22, 2012, 10:16:08 AM

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

Steve

hero member

Activity: 868

Merit: 1008

Quote from: Meni Rosenfeld on January 22, 2012, 12:32:34 PM

Quote from: Steve on January 22, 2012, 10:16:08 AM

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

donator

Activity: 2058

Merit: 1054

Quote from: Steve on January 22, 2012, 10:16:08 AM

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.

CombustibleLemon

newbie

Activity: 34

Merit: 0

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.

Steve

hero member

Activity: 868

Merit: 1008

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.

Meni Rosenfeld

donator

Activity: 2058

Merit: 1054

Quote from: BitPay Business Solutions on January 22, 2012, 08:46:35 AM

Quote from: Meni Rosenfeld on January 22, 2012, 05:38:05 AM

Quote from: BitPay Business Solutions on January 22, 2012, 01:18:21 AM

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!"

BitPay Business Solutions

hero member

Activity: 742

Merit: 500

Quote from: Meni Rosenfeld on January 22, 2012, 05:38:05 AM

Quote from: BitPay Business Solutions on January 22, 2012, 01:18:21 AM

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

donator

Activity: 2058

Merit: 1054

Quote from: BitPay Business Solutions on January 22, 2012, 01:18:21 AM

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?

Matthew N. Wright

hero member

Activity: 588

Merit: 500

Hero VIP ultra official trusted super staff puppet

Nice.

notme

legendary

Activity: 1904

Merit: 1002

Quote from: BitPay Business Solutions on January 22, 2012, 01:18:21 AM

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.

BitPay Business Solutions

hero member

Activity: 742

Merit: 500

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.

koin

legendary

Activity: 873

Merit: 1000

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

hero member

Activity: 742

Merit: 500

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.

Topic: [ANN] Mobile Checkout is now active for ALL Bit-Pay Merchants (Read 1747 times)