On a panel with MasterCard and Visa

[BombaUcigasa]

Keep it positive, make Bitcoins community shine, a dedicated community of the smartest 1 percent of the population backing and supporting the cryptocurrency movement; with them all problems can be solved.

ROFL.
The smartest 1 percent?
This community here, at bitcointalk?
ROFL.

It's not funny, why do you laugh?

[NewLiberty]

It is an interesting point.  The Facebook marketing rollout started at Harvard.  Lots of people wanted to know people at Harvard, and initially it was exclusive.

The WWW started at CERN, some pretty smart people there, again university focused.

Bitcoin started with crypto programmers, and systems and security folks cross-bred with monetary philosophy.  Each of these starting groups are fairly elite, with high barriers of intelligence and depth of expertise needed to participate meaningfully.

Are we at the dilution phase, where it is no longer just the smartest?  If so, that suggests rapid growth ahead as we swing up the bell-curve into the "normals".

[gendal]

Chip and Pin doesn't work like that.
The card reader is supplied by the credit card company, and communicates directly to them, not through the retailer.
The retailer enters the amount to be charged, and hands the device to you. You see on the screen how much money will be sent, and choose to enter your Pin or not. You are pushing an amount of money you choose to the retailer, not trusting them to pull the right amount.

Not quite.

The card reader is provided by a merchant acquirer.  This firm may well also have an issuing arm but they are not "the credit card company".  Think about it: does your local retailer have a different device for each of the thousands of different issuers of Visa or Mastercard cards in your country?  Clearly not.

The credit card system works on what's known as the four-party model (although there are really five parties):

* you, the purchaser
* your card issuer (usually a bank, which has usually issued you a card with both their logo and one of the card networks printed on it.  let's assume it's visa for now)
* visa (the switch)
* the merchant acquirer (the firm that "acquires" transactions from the merchant and routes them to the appropriate network)
* the merchant.

In this model, it simply isn't possible for what you said to be true.  The communication is from the merchant, to the merchant acquirer, to the switch and then to the issuer.

Sure, you may well authorise the request and provide a credential (your PIN) that allows the merchant to attest to the fact that you were present and authorised the request.  But it's still a *request*.  And you're trusting all the parties in that chain to present the request to the issuer such that what you authorised matches what is taken.

Now the system does actually work and the checks+balances mean that mistakes are found and customers do get refunds.  But it's a ridiculously complex system, and one that works the way it does (as Mike Hearn suggests a few posts back) because of the multi-decade history of the system and the technical constraints that existed when it was invented.

And I would argue that it's unambiguously a "pull" from the merchant, not a "push" from the purchaser.

[CasinoBit]

Do they all look like dr. evils?

[murraypaul]

Chip and Pin doesn't work like that.
The card reader is supplied by the credit card company, and communicates directly to them, not through the retailer.
The retailer enters the amount to be charged, and hands the device to you. You see on the screen how much money will be sent, and choose to enter your Pin or not. You are pushing an amount of money you choose to the retailer, not trusting them to pull the right amount.

Not quite.

The card reader is provided by a merchant acquirer.

I accept the correction here.

In this model, it simply isn't possible for what you said to be true.  The communication is from the merchant, to the merchant acquirer, to the switch and then to the issuer.

But not here.
The device communicates to the 'merchant acquirer', the merchant is not part of the chain.

Sure, you may well authorise the request and provide a credential (your PIN) that allows the merchant to attest to the fact that you were present and authorised the request.  But it's still a *request*.  And you're trusting all the parties in that chain to present the request to the issuer such that what you authorised matches what is taken.

I'm not trusting the merchant (beyond trust that they have not supplied a hacked device), because their role ended when they entered the purchase amount into the device. I get to see that before entering my PIN to authorise the transaction, and I keep the device until the transaction has completed.

And I would argue that it's unambiguously a "pull" from the merchant, not a "push" from the purchaser.

I think that is ultimately semantics.
The important point is that I am choosing the amount to be transferred, I am not relying on the merchant for that.

[gendal]

I think that is ultimately semantics.
The important point is that I am choosing the amount to be transferred, I am not relying on the merchant for that.

Where I think it gets beyond semantics is when you think of the IT implications.   The data that passes along the communication chain from retailer* to acquirer to switch to issuer is extremely sensitive and so has to be secured.  This has spawned industry standards such as PCI-DSS, which impose huge costs on all parties in the system and represents a very attractive target for bad guys, creating an escalating arms race.

A true "push" approach would not entail the passing of this sensitive data through this back channel from retailer (or acquirer, if you prefer) to issuer... it would rely on the customer initiating a payment *to* the merchant themselves... the attack surface is a lot smaller.  Now, I'm not saying this is perfect....  the question of how the merchant communicates their request to the customer is a difficult one.  The Bitcoin payment protocol work, which currently relies on X.509 certificates, etc., shows how hard this is to do on the internet.   For face-to-face transactions, you have to find a way for the merchant to share their "receipt address" to the customer in a way that can't be spoofed, etc.   The "bitcoin pub" in London does this by displaying a QR code on their POS device, that the customer can scan - but it's not particularly elegant.


(* in many cases, the retailer really does have sight of the card details... the card readers are integrated into POS systems and transactions are routed through branch systems...  it's not the case that all retailers never see the card details).