Altoidnerd (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 30, 2013, 07:38:37 AM |
|
http://www.ti.com/lit/sg/slyt493/slyt493.pdfAm 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?
|
|
|
|
StarfishPrime
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 30, 2013, 08:10:08 AM |
|
Interesting question. Existing NFC POS applications (Visa, Google Wallet, etc) tend to use conventional online POS terminals and do not require the customer to be online.
Sounds like you're suggesting the reverse scenario, where the merchant (recipient/payee) would be completely offline, yet be able to verify a transaction? It's difficult to see how that could be done without it being an entirely trust-based exchange - you'd be relying on the payor (customer) to communicate to you somehow (via NFC) that a tx was broadcast to the network, or alternatively pass you a private key that you'd have to trust was worth what the customer claimed. Not sure what you had in mind...
|
¦ ¦ ¦¦¦ ¦¦ ¦¦¦¦ ¦¦ ¦¦¦¦ ¦ ¦¦ ¦¦¦¦ ¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦ ¦¦¦¦¦¦ ¦¦¦ ¦¦¦¦¦¦ ¦ ¦¦¦¦¦¦ ¦¦ ¦ ¦¦¦¦ ¦¦ ¦¦¦¦ ¦¦ ¦ ¦¦¦¦ ¦¦¦ ¦ ¦¦¦¦¦ ¦¦¦¦ ¦ ¦¦¦¦¦¦¦¦ ¦¦¦¦¦ ¦ ¦¦ ¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦ ¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦¦ ¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦ ¦ ¦ ¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦ ¦¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦¦ ¦¦ ¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦ ¦¦ ¦¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦¦ ¦ ¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦ ¦ ¦¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦ ¦¦ ¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦ ¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦ ¦¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦ ¦¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦ ¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦ ¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦
| . TorCoin.....
| ¦ ¦ ¦ ¦ | Fully Anonymous TOR-integrated Crypto ¦ Windows ¦ Linux ¦ GitHub ¦ macOS
| ¦ ¦ ¦ ¦ | . ANN THREAD | ¦ ¦ ¦ ¦ |
[/center]
|
|
|
Altoidnerd (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 30, 2013, 08:45:45 AM Last edit: December 30, 2013, 09:12:32 AM by Altoidnerd |
|
Interesting question. Existing NFC POS applications (Visa, Google Wallet, etc) tend to use conventional online POS terminals and do not require the customer to be online.
Sounds like you're suggesting the reverse scenario, where the merchant (recipient/payee) would be completely offline, yet be able to verify a transaction? It's difficult to see how that could be done without it being an entirely trust-based exchange - you'd be relying on the payor (customer) to communicate to you somehow (via NFC) that a tx was broadcast to the network, or alternatively pass you a private key that you'd have to trust was worth what the customer claimed. Not sure what you had in mind...
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.
|
|
|
|
Altoidnerd (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 30, 2013, 08:59:57 AM Last edit: December 30, 2013, 12:24:14 PM by Altoidnerd |
|
you'd be relying on the payor (customer) to communicate to you somehow (via NFC) that a tx was broadcast to the network
Alternatively, a continuous high power RF transmission representing the network state could provide such proof, as was kicked around here. https://bitcointalk.org/index.php?topic=370457.0
|
|
|
|
StarfishPrime
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 30, 2013, 09:01:53 AM |
|
Interesting question. Existing NFC POS applications (Visa, Google Wallet, etc) tend to use conventional online POS terminals and do not require the customer to be online.
Sounds like you're suggesting the reverse scenario, where the merchant (recipient/payee) would be completely offline, yet be able to verify a transaction? It's difficult to see how that could be done without it being an entirely trust-based exchange - you'd be relying on the payor (customer) to communicate to you somehow (via NFC) that a tx was broadcast to the network, or alternatively pass you a private key that you'd have to trust was worth what the customer claimed. Not sure what you had in mind...
Yes I see your point. I am also glad that I think 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. It could be the case that if payer 1 lies, their transmission will not be congruent with (previous or subsequent) payers' 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.
|
¦ ¦ ¦¦¦ ¦¦ ¦¦¦¦ ¦¦ ¦¦¦¦ ¦ ¦¦ ¦¦¦¦ ¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦ ¦¦¦¦¦¦ ¦¦¦ ¦¦¦¦¦¦ ¦ ¦¦¦¦¦¦ ¦¦ ¦ ¦¦¦¦ ¦¦ ¦¦¦¦ ¦¦ ¦ ¦¦¦¦ ¦¦¦ ¦ ¦¦¦¦¦ ¦¦¦¦ ¦ ¦¦¦¦¦¦¦¦ ¦¦¦¦¦ ¦ ¦¦ ¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦ ¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦¦ ¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦ ¦ ¦ ¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦ ¦¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦¦ ¦¦ ¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦ ¦¦ ¦¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦¦ ¦ ¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦ ¦ ¦¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦ ¦¦ ¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦ ¦ ¦ ¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦ ¦¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦ ¦ ¦¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦ ¦ ¦¦ ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦ ¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦ ¦¦
| . TorCoin.....
| ¦ ¦ ¦ ¦ | Fully Anonymous TOR-integrated Crypto ¦ Windows ¦ Linux ¦ GitHub ¦ macOS
| ¦ ¦ ¦ ¦ | . ANN THREAD | ¦ ¦ ¦ ¦ |
[/center]
|
|
|
Altoidnerd (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2013, 02:37:25 AM |
|
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.
Tough problem, but what if that signal isn't sent by software but by hardware. Suppose when its time to pay the customer is handed a little transmitter peripheral that fits into the 1/8" headphone jack or other port on the mobile device. The peripheral is owned by the payee (merchant) and so its behavior is known to the merchant to be legitimate. That peripheral, being connected to the payer's device, IS on the network and "knows" if a tx is real or not. It "listens" to the blockchain and communicates to the merchant. The peripheral could do other tests to determine the payer paid. Whatever it does to verify the tx, it draws power from the payer, gets internet from the payer, and transmits "yay" or "nay" to the merchant. How does that sound?
|
|
|
|
jbis1
Newbie
Offline
Activity: 50
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2013, 02:50:44 AM |
|
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).
|
|
|
|
Altoidnerd (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2013, 03:03:54 AM Last edit: December 31, 2013, 03:17:54 AM by Altoidnerd |
|
trusting the payer's software is not desirable. It may be possible, but its risks are clear.
>>Is there a practical reason for downloading the blocks over NFC instead of connecting to the Internet yourself?
I'm not insisting anyone downloads blocks over near field. I'm asking for less than that. I am asking for a proof that the buyer made a 0 confirm TX.
Bitcoin without internet is good. The internet is not necessary for everything that happens in the bitcoin economy. If the merchant can stay offline, they can accept bitcoin almost as easily as they accept cash, and with decisively less overhead than using something like VISA. Not only will the merchant's "bitcoin machine" be simple and inexpensive, but the merchant is not paying for internet, or paying recurring service fees.
>>Also, what type of device would the store have (microcontroller, Android, PC, traditional POS).
Doesn't matter. It's logical to make the goal the simplest merchant device imaginable, like a paper wallet and an RF coil.
|
|
|
|
jbis1
Newbie
Offline
Activity: 50
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2013, 03:17:43 AM |
|
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).
|
|
|
|
Altoidnerd (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2013, 03:20:56 AM |
|
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). Cool, thank you for pointing me to the resource.
|
|
|
|
jbis1
Newbie
Offline
Activity: 50
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2013, 03:47:29 AM |
|
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).
|
|
|
|
Altoidnerd (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2013, 03:01:59 PM Last edit: January 01, 2014, 09:05:02 PM by Altoidnerd |
|
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).
I feel like we just backpedaled here. You understood me right...don't let my potential misuse of terminology on confirmations mislead you We do want proof that the buyer broadcast to nodes. I am not thinking of >>The shop can verify that the transaction sends bitcoins to the shop. I'm not totally sure what this would mean. I have been presuming the payer is going to make an honest TX with his/her mobile client over 4G or something. How does the payer prove to a merchant that he has done so?I want the payer to broadcast the TX and for the shop owner to have proof that occurred despite having passive technology or perhaps only an RFID interrogator, or something with very limited closed circuit transmit capabilities. >>This is however, not proof that the buyer will broadcast the transaction to the Bitcoin networkI thought the path to this was the payers transmitting a self consistent series of block headers to the payee, as you mentioned. I seek a solution in the scenario the payer has perfect bitcoin network connectivity and the merchant has none.
|
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1129
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2014, 07:21:05 PM |
|
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.
|
|
|
|
jbis1
Newbie
Offline
Activity: 50
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2014, 04:53:49 AM |
|
You can prove that the transaction was made by seeing that it was included in a block. Of course that requires you to wait until the transaction is included in a block, which is probably not feasible.
When I said that the shop can verify that the transaction sends bitcoins to the shop, I meant that the shop can watch the Bitcoin network for a transaction that sends bitcoins to the shop's address. That doesn't mean the transaction will be included in a block, but that is the best you can do without waiting for inclusion in a block.
|
|
|
|
|