Please consider adding support for standard USB NFC readers to invoke transactions. I'd like to use the PC has an ad-hoc point of sales device, and the NFC scanner is essential.
Hardware is inexpensive and readily available: http://www.acs.com.hk/index.php?pid=product&id=ACR122U
This is a good idea, but
I don't have the hardware, and won't buy it just for implementing a feature. Not only that, but I also have one of those rare Samsung S2's without the optional NFC support so I wouldn't be able to test it either way :/
Getting this to work in a platform-independent way is probably hell (though there are some smartcard libraries these days, it's not really an obscure thing anymore)
Andreas Schildbach's Android wallet ( https://code.google.com/p/bitcoin-wallet/ ) has support for NFC, why don't you use that?
I'm sure we (the community) can chip in, or I personally can organise a device for you to test with (a valuable investment for the whole community). I can't do anything about a supported phone though... perhaps you have a friend with a nexus or s3?
There are relatively standard smartcard libraries available, and it's possible to write the basic code to get the device initialised/communicating with just any transport/membership card or something of that sort. It probably wouldn't take a lot of time with a friends device to produce the actual communication after that.
NFC is quickly becoming the standard/preferred means of performing bitcoin transactions, and it would be really nice to see the reference client support it. I think it would help to assert NFC as a standard/expected feature, and encourage all other clients to follow suit. I also think a lot of people have the most trust in the reference client, and NFC on PC clients is certainly useful in business situations.
How does NFC work? Is there a BIP describing the protocol?
@turkeyman: you seem to know a lot about it; why not take a shot at implementing it yourself? @luke-jr: as I understand it, it simply sends bitcoin: URIs as standard URIs over NFC, instead of through QR codes
Edit: But I'm not entirely sure, there may be some extensions. If so, there should be a BIP first. Here is the code relating to NFC from the android app:
Utility functions:
Ui:
This certainly needs more discussion, but as a general comment, I'd very much prefer it if any future NFC protocol did not just request a URI and then broadcast the signed transaction, but at least allowed specifying that the constructed transaction is intended to be sent back to the requester via NFC.
I'd love to, but I really don't have any time outside work to take on another side project at the moment >_<
@sipa This is part of my reasoning why this should be tackled in the reference client; everyone is rolling their own. If the reference client implements a thought-through protocol, then I suspect all clients would adopt support for the same protocol.
Another important consideration for the protocol is clients like Electrum.
Most important thing to start with is to get the use-cases clear.
Is there any reason for broadcasting back a signed transaction? I'm not against it, but what does such a shortcut add?
I'd think it is enough to transmit the bitcoin: URL in one direction. The receiver can then accept this payment (or not), and broadcast it as normally through the network. The vendor side will see for itself through the bitcoin network that the payment has been made.
I imagine the shortcut allows for wallets without cellular data.
@laanwj I think it's very important. One-direction URL is okay for phones, but consider:
I think it should be possible for any phone/smartcard to run an electrum client, and the NFC/smartcard protocol should support that transaction style. In the case of a chip based smartcard, the POS would need to prompt the user to enter a PIN I imagine too.
That obviously doesn't need to be done immediately, but I think the protocol should define and support it.
One other communication for the protocol would be a balance request. If the phone has no network connection, the client app will still want to show the users balance, at which point the device will have to request the balance from the POS terminal.
@laanwj: I consider the fact that the Bitcoin's most common way of submitting transactions is to use the slow, unreliable and expensive P2P network (as opposed to directly submitting them to the receiver; payment protocol)) a flaw. I see absolutely no reason to do the same in the NFC case, especially because at that point you are most certainly already communicating with the merchant anyway. @TurkeyMan: Bitcoin internally has no concept of balances, and I'm strongly against defining something like that. Balances are a wallet's responsability (especially since just the balance isn't enough; you need the transactions ids, amount, and txout scripts of the transactions crediting you anyway to construct a payment). Also, I certainly don't want our NFC protocol to be a proxy for a client device to connect to the internet. If it needs that, it should do so by itself.
@sipa: Concern about attack surface and "internet proxy" behavior were exactly my reason to be skeptical of a return channel. But supporting devices without their own internet connection is a good reason. I still want the protocol to be as minimal as possible, so vendors can mess up the implementation in as few ways as possible that allow for fraud.
(and expose as little as possible in case someone succeeds in sniffing or MITMing the radio transmission)
@sipa I can see your point, but in a retail situation where you are making a payment with an offline device, perhaps providing an internet proxy would be useful. That said, a full internet proxy seems overkill, since the only thing the user wants is the transaction history for their addresses of interest, and a full bitcoin client will already have this data locally (no?). They don't need to start updating their facebook or twitter posts.
Am I misunderstanding the transaction history? I can imagine a query to provide the transaction history for an address back to a particular point (the last record the device has I guess) would be a simple thing to serve, and allow the device to keep its user-facing record of the current balance accurate.
That opens all kinds of trust issues (client to vendor, vendor to client, etc), and will have to be thought about really carefully.
IMO someone with some knowledge of NFC should write a very minimal BIP for the basic payment protocol (if remotely possible, compatible with Andreas' work), that allows for future extensibility.
@laanwj /agree, it makes it more complicated than just the URL, but the only significant trust issue I see is requesting a PIN number from the POS device, and this is equally an unsolved issue with modern credit card POS terminals and ATM's. At least the security risk is familiar, and to make malicious use of collected PIN numbers, you need to acquire the users wallet card. Offline phones can enter their own pin on the screen, it's just a basic Electrum payment.
I would approach it like this (if I had time to offer):
Starting point, no security concern:
Then much lower priority:
I think the correct solution is the development of a generic payment protocol which supports several transport mechanisms, NFC being one of them.
Regarding PIN identification: no opinion, but I don't see why you can't just ask for the PIN (or other authentication info) on your own device.
Regarding requesting a balance: please don't. A device can manage its own wallet just fine, even if offline. If it needs to contact a third party to know its coins, that is its own responsibility. No need to offload that to a communication channel with the merchant.
@sipa Sure, I would imagine the protocol to apply to whatever communication channel is used. I would design it as a stateless, instantaneous, single request+response transaction like HTTP.
PIN (or whatever) on the device is fine, IF the device is a device. If it is just a smartcard, then the POS needs to provide pin entry. I can imagine many people; tech-phobes, elderly, my mum, will prefer to have a bitcoin wallet that looks and feels like a credit card, rather than an app on her 10 yr old Nokia. The only difference technically is how to enter a PIN.
Closing this. It is not planned for the Bitcoin Core wallet, and if someone was going to work on this it would be better to implement this as part of the SPV wallets that people actually use.