Topic: [Pre-Announce] OpenPay, use your bitcoins at any merchant that takes Visa! - page 2. (Read 6511 times)

That would make sense considering it would be much easier to convince a merchant to switch over if you could just say "download X software and you can start getting 0-1% transaction fees on certain transactions".


And it would certainly be useful for consumers by saying "download X software and start converting your dollars to Bitcoins to avoid needing to deal with banks and credit card companies".

Am I misunderstanding or is the end goal here to get bitcoins to the merchant - which several solutions already exist? I would think there is more demand/need for a solution to get dollars to the merchant from a consumers bitcoins using existing debit/credit card infastructure.

In theory...would this allow a merchant to pay 0 fees?

Thanks!  You know that was very helpful information and greatly simplifies the design for this... Assuming i understand it correctly.

Instead of a 0.01BTC broadcast to a constantly changing key that then has to be picked up and processed by the primary wallet.

The merchant gateway is actually a fullblown node.

The gateway would initiate a TxDP, essentially just a note specifying where the money needs to go, but the TxIn field is left blank.
This is then signed with the users semi-private key which was generated by a hash of the card details and PIN.

The signing system (primary wallet or wallet protection service or whatever) sees the TxDP then does some confirmation checking either sending an SMS, or popping a message on an android app, or just checking for the presence of a static PIN and if the confirmation checks out.
Fills out the TxInput fields, then signs it and sends it off to the network.

This makes sense to me, except I don't see how the primary wallet is supposed to know to look for the transaction, but maybe I'm just missing something simple.

Still, I'll keep digging.
 

https://en.bitcoin.it/wiki/BIP_0010

https://en.bitcoin.it/wiki/BIP_0011

It is at dev stage, afaik, but Gavin has done a lot of work/testing on it and he is the lead dev. so it is probably not that far away ...

I haven't taken multisig into account, just two factor.  That's mostly because it's a new concept I'm not sure I fully understand.  Is there a really good explanation of how that would work in the Bitcoin system?  It might be I could incorporate it into this design, or rework the whole concept to leverage it properly.

Multi-sig transactions and/or two-factor authentication can remove most of the risk of a 'Bitcoin card' ... so that the irreversibility is not a problem, except in an infinitesimally small number of cases, an acceptable level of risk.

OK, as long as it can't be done in the comfort of some carder's home or in the back office where an unscrupulous cashier doesn't care how much of his employer's money he wastes.

I think you're confused.  The 0.01BTC spend is used to signal the client to look at the transaction.  It's sent from the merchants account to a disposable address calculated independently by the merchant and your client software.  That address is literally one time use and changes every single second.  Thus it's the merchant's money 0.01BTC that gets wasted in this instance.  I think 3 PIN failures is enough for the merchant to tell granny to stop brute forcing her own pin

The purpose of the network fee is to make brute forcing behavior unpalatable and unrewarding.  Doesn't matter if it's granny brute forcing her own pin, or some pimply faced clerk who is moonlighting as a carder.  The system can't tell the difference.

Yes you're reading it wrong.  It's one time disposable and limited by spending limits you set.  This isn't your primary private key, it's a generated ID used by the merchant to send a message to the client as signal to say "Hey look here!"

Eew, so granny making a mistake will waste money? Is the waste limited in how much? Could it be only a satoshi instead? Or does it have to be the amount of the whole transaction?

The PIN in this case is just a number you tell the OpenPay client or that it tells you.  It's not stored anywhere including the track data.
It's used to generate the static half of the disposable key (an enrollment id) and that's it.  It's purpose is to ensure that you are in fact in possession of the card and also to help you enforce spending limits in the unlikely event of a compromise.

There is no verification on the PIN itself, if the pin makes the key fit the hole that the client is looking for,  then the merchant (or brute force attacker) will see a properly crafted BTC send transaction come their way.  But if it doesn't work, then they just spewed 0.01BTC into the void with each failed attempt.  There is no "PIN_FAILED" message, however a "PIN_REQUIRED" message might be seen if they stumble upon an address that has a listener at that exact second.

To crack a 4 digit PIN it would cost as much as 99.99BTC with no guarantee that the daily spending limit on a 4 digit PIN is greater than 99.99BTC.  I would recommend a PIN length 2 digits more than the daily spending limit for that PIN, just to keep the security level higher.

Which is why I don't see magnetic stripe being useful.  In a pin & chip system (Bitcoin or otherwise) the pin and secret never leave the smartcard.  The pin pad sends pin (hashed to prevent snooping) to the smartcard which verifies it and then performs some action on the secret only providing the output.

For Bitcoin the "secret" would be the private key or possibly deterministic seed for a range of private keys and the "some action" would be generating a signed tx.

Am I reading this wrong?  A pin pad that sends the pin as plain text to the merchant is of no value.  You just gave the merchant everything necessary to spend as the user.

To prevent PIN bruteforcing, it seems to me that it would make sense to require that the PIN be verified against a remote server that has limits on the number of PIN submissions per $time_period. If the PIN can be determined with the use of the track data and some cryptographic brute force, I think the project would be lost before it is started, especially since 10 numerical digits are trivial to bruteforce. However, making the PIN completely unrelated to the track data would make it a bit more secure.

However, I'm not sure how to do this. Especially without a central server, although that might be something that could be implemented as a bridge solution.

No mater what payment method you choose, carders are a risk.  You can't stop every criminal out there all you can do is make it horribly unattractive for them.   

As for reversibility being some sort of protection; in the EU if a transaction is made with a compromised PIN & card the law says it's up to you to prove that you didn't make the transaction, the bank is under no obligation to refund you if you can't prove it was stolen, they may do so as a courtesy but it really is bank policy that dictates this, not network policy.

In the US if you try to dispute a PIN based transaction the bank will generally laugh at you, my bank doesn't allow reversals on PIN based debit transactions at all.  If yours does you're very lucky.  I can't speak for all of them, but I know that of the major banks I've done business with in the past few years, none would reverse PIN debits for any reason even with a police report and newspaper article in hand.  The most they would do is re-issue the card.

You can't have it both ways.  You can't have the irreversibility of bitcoin and the reversibility of Visa, at some point you're going to have to say... Alright this is secure enough for me.

In furtherance of security, the solution includes several safe-guards to make it unattractive to carders & script kiddies.

A 1 time use disposable key generated on the fly to protect your primary wallet.
A tiered set of spending limits (you set) tied to static PINs which you also set.
Multi-factor auth or 1 time use disposable PIN via SMS

Network replay attacks are pointless because the key is disposed of by the client as soon as the request is received.
Brute-force attacks have a significant financial cost.
If someone had the static portion of the key (a carder for instance), the most they could get at is whatever you set your spending limit to for that PIN, for that day, for a single transaction etc.
If a carder were to try a non-pin transaction it would trigger an SMS to you, and it's doubtful they would have both your card and your phone. 

Additionally the carder would have to know that $ome_random_card was actually used on the OpenPay network and not visa/mc or instore credit.  That would require not just a pin pad compromise but a wholly compromised back office.

And if you're really paranoid about the threat of carders, just enroll different card(s) for different merchants and days of the week, a different one each day

The Bitcoin-qt client doesn't support it, but the protocol allows it.  If I remember correctly, older clients used to not relay these transactions where the inputs weren't confirmed but I believe that is no longer an issue.

I raise this issue (one confirmation required between uses) with another type of payment approach where there is a paper (throwaway) wallet:



 - https://bitcointalksearch.org/topic/m.831171

Is it possible with the bitcoin protocol, to transfer some money (for a hotdog) from wallet A to wallet B, then spend the money from (throwaway) wallet B in the same block? Or must the first transaction A->B be on the blockchain first? If possible, one could give the merchant the keys for wallet B together with a signed transaction A->B.
Having to wait ten minutes or more in the shop might be a dealbreaker though.

Ahh, roger that. So this is a unique risk to be addressed.

Which is why credit cards are resversible and have fraud protection.