http://www.ti.com/lit/sg/slyt493/slyt493.pdf

Am I correct that an offline device (payee) which can generate keypairs and is equipped with adequate NFC modules can verify payments sent to those keys (completely offline) by communicating with the payer's online mobile client in a point of sale scenario?

Yes I see your point.  Perhaps you understand my goal is to let merchants accept payments offline all day. Let's try to get there, because I think merchants would like something like this, who run simple stores without connections to the web or computers at all.

The burden of connecting to the bitcoin network is on the payer. What if we suppose the payer has a piece of software that is compatible with the passive offline payee's hardware insomuch as it transmits some sort of proof that a real time blockchain inquiry was made that shows the TX.

I am blanking on how that would be done.  Perhaps it could be the case that if some payer lies, the inconsistency will present itself when the next payer send their proof of inquiry.

 

Something like that could work - as long as the customer is running your code and you could be reasonably certain that verification isn't easily spoofed. Keep in mind that NFC is a (very) limited bandwith connection, typical NFC messages are well below 1kB, usually just a few 100 bytes or even less.

Downloading the full blockchain is not feasible over NFC, but how about just the block headers? If I understand https://en.bitcoin.it/wiki/Protocol_specification#Block_Headers correctly, a block header is 81 bytes. From http://stackoverflow.com/questions/14717007/what-kind-of-bandwidth-does-nfc-provide you can expect a peak transfer rate of 2.5 kB/sec from NFC. Using those numbers, I calculate that it takes 32.4 ms/block to transfer over NFC. The block headers for the entire chain currently take up approximately 22.5 MB.

My idea is to download (over NFC) the new block headers since the last NFC connection. You should be able to trust any blocks that are a certain number of blocks deep after you verify they have the correct difficulty. Does anyone see issues with getting the blocks from customer's devices? If you verify difficulty and check for a certain block depth, then it should be more expensive to feed the POS fake blocks than it is worth.

Is there a practical reason for downloading the blocks over NFC instead of connecting to the Internet yourself? I don't see why a business would have trouble getting Internet access when its customers are able to get access. So then is it for security purposes? It sounds like you want to keep this device offline for security purposes, but doesn't NFC provide similar issues to those of Internet access?

So I don't get if security is the goal, or Internet access is not an option because it just isn't available where the store is located (but is to customers through mobile devices). Also, what type of device would the store have (microcontroller, Android, PC, traditional POS).

In that case, I would say the best bet is to run a SPV client on a computer at the POS. Download the block headers through the customer's mobile phone. Read https://en.bitcoin.it/wiki/Thin_Client_Security. The section "Block Depth as a Transaction Validity Check" explains how the person providing your Internet access can isolate you from the rest of the Bitcoin network. So a double spend is possible, but you would realize it the next time you connect through an honest customer's phone. The risk could be lowered by connecting through multiple phones at the same time (then multiple customers would have to work together to double spend without you realizing).

Sorry it took so long for me to understand what you were asking. I was focused on NFC and thought it was integral to your question.

Regarding the proof of the 0 confirm transaction, the buyer can send a signed transaction via NFC to the shop. The shop can verify that the transaction sends bitcoins to the shop. This is however, not proof that the buyer will broadcast the transaction to the Bitcoin network or that the network will include it in a block (i.e. that there is not a simultaneous double spend).

The right way to do that is indeed for the merchant to tunnel back through the users phone. For instance, most modern phones can support bluetooth tethering quite easily. The merchant would then have to set up a VPN to an endpoint they trust for the purpose, and connect to the P2P network directly.

In practice this sort of arrangement is unlikely to become common. Normally sellers have better internet access than buyers. In that case it's easier: the buyer just gives the tx to the seller and the seller broadcasts.