Topic: Design for cheap (<$2) Bitcoin tipjar using NFC tags (Read 3094 times)
The point of NFC is it requires very close contact to trigger (a few centimeters). The NFC radio is off when the screen is off, so it's hard to invoke an NFC interaction accidentally.
The app puts a notification icon in the users notification bar, makes a sound, vibrates etc but does not request any confirmation. Instead the transaction is kept around for 10 minutes or so and if the user doesn't explicitly cancel it, broadcasts it at that time. The user can also adjust the value being sent to the new private key if they aren't happy with the default suggested amount. Even once the transaction is broadcast, it can still be revoked until the next step, which is why it's safe to just have the act of touching trigger payment - the user can undo unexpected payments easily.
I like the overall design.However, the idea of my bitcoin wallet creating transactions without any manual confirmation action does make feel a bit uneasy. It's very possible to miss a notification if you're not paying attention to your phone (and it can accidentally wake up, in your pocket, for example, so that's not really a security measure either).
How does the application "know" that the user is actually trying to touch a tag instead of receiving a (malicious, random spammed) payment request over the air, or from something he passes? Or do you need to explicitly start the application for it to work?
Then again, I guess that'd be easily solved by adding a setting to the app so that it does ask for confirmation, for the more paranoid among us :-)
This could work great, and I don't see the problem with the money trail, who cares if people can see what that specific address has collected in tips before. A restaurant owner could have 10 of them but 100 employees, each shift an employee gets one, at the end of the shift the employee turns it in and the manager would then take the balance on that address and transfer it to the employees own address.
It's a bad idea to build systems that leak private data unexpectedly. Just because this system can be used for tips doesn't mean that's going to be the only way it gets used. You really don't want to have to give every user a lecture in what information people might or might not learn about them by using it, that's just way too complicated.
Why not use the NFC tag that has write protection?
http://www.amazon.com/PREFORMATTED-Mifare-Ultralight-NFC-Tags/dp/B006RJTXZQ/ref=pd_sbs_misc_4
And why the 4k model? Why would you need 4000 characters, go with the 192byte model with write protection. Sure some hacker could still change it with write protection and steal, but some thief could just as easily stick his hand in a real tip jar/collection plate and steal fiat money, or walk around a restaurant taking the cash tip off of tables. The point is, very few people would attempt to change it if it was a "tip" and even fewer of those people would go to the trouble of hacking the write protection.
This could work great, and I don't see the problem with the money trail, who cares if people can see what that specific address has collected in tips before. A restaurant owner could have 10 of them but 100 employees, each shift an employee gets one, at the end of the shift the employee turns it in and the manager would then take the balance on that address and transfer it to the employees own address.
You could even do fun things like have a rasberrypi badge on them showing how many tips they got that night, or a manager could see real time statistics of how much tips each waitress was getting. This would be slow to integration until more people got NFC devices and bitcoin, but I could see a bar with cute chicks getting customers to do this. They could offer to sell customers bitcoins to tip they're favorite girls, guys at a bar with cute bartenders would definitely go for this, sex appeal sells.
http://www.amazon.com/PREFORMATTED-Mifare-Ultralight-NFC-Tags/dp/B006RJTXZQ/ref=pd_sbs_misc_4
And why the 4k model? Why would you need 4000 characters, go with the 192byte model with write protection. Sure some hacker could still change it with write protection and steal, but some thief could just as easily stick his hand in a real tip jar/collection plate and steal fiat money, or walk around a restaurant taking the cash tip off of tables. The point is, very few people would attempt to change it if it was a "tip" and even fewer of those people would go to the trouble of hacking the write protection.
This could work great, and I don't see the problem with the money trail, who cares if people can see what that specific address has collected in tips before. A restaurant owner could have 10 of them but 100 employees, each shift an employee gets one, at the end of the shift the employee turns it in and the manager would then take the balance on that address and transfer it to the employees own address.
You could even do fun things like have a rasberrypi badge on them showing how many tips they got that night, or a manager could see real time statistics of how much tips each waitress was getting. This would be slow to integration until more people got NFC devices and bitcoin, but I could see a bar with cute chicks getting customers to do this. They could offer to sell customers bitcoins to tip they're favorite girls, guys at a bar with cute bartenders would definitely go for this, sex appeal sells.
Yeah I realised that within minutes of posting.
Not sure how sophisticated the technology is, like can one modify any part of the recorded info in the jar or only either zap it empty or write onto the end of what is already there, whether ambient info in the place this all takes place could be chatting away with the instances of the app in its vicinity all the time while people are there and on like that. (The local ambient wifi for example could be constantly updated about all the tips by the tipping app, each time it talks to a jar it could announce to the room at large what was in the jar before and after, etc...)
-MarkM-
Not sure how sophisticated the technology is, like can one modify any part of the recorded info in the jar or only either zap it empty or write onto the end of what is already there, whether ambient info in the place this all takes place could be chatting away with the instances of the app in its vicinity all the time while people are there and on like that. (The local ambient wifi for example could be constantly updated about all the tips by the tipping app, each time it talks to a jar it could announce to the room at large what was in the jar before and after, etc...)
-MarkM-
The app could by default exclaim in surprise if the jar is empty, so that the performer puts a penny in it before passing it around the crowd so that the next tipper after the thief will notice the theft.
-MarkM-
-MarkM-
The thief could also put a penny in the fraudulent jar...
The app could by default exclaim in surprise if the jar is empty, so that the performer puts a penny in it before passing it around the crowd so that the next tipper after the thief will notice the theft.
-MarkM-
-MarkM-
I'd really rather avoid the signing solution if possible. The goal of this is to be
a) Very cheap
b) Very easy
because I want to find a way for people to quickly create and use tip jars. Tipees probably aren't going to go through complicated ID verification schemes and tippers probably won't want to check.
I can see two other ways to deal with this.
The first is to shrug and say, well, so what. If somebody rewrites the tag then they still have to get it back after a while and empty it. If somebody is passing the tag around a crowd, for example, that's probably impractical. If somebody is watching the tag then the attacker has to come and tip once then come back some hours later and "tip" again (empty the jar). That's a bit suspicious, especially when you notice that the jar does not contain tips you saw happening.
In other words, there may be situational or social solutions.
A second solution is to have two tags, laid out side by side. One is small but write-protected and contains the key, label and suggested amount. The second is the read/write 4k tag. The software expects to see the data be separated. Instead of touching once to tip, you "tap and slide". There'd be an arrow printed on top of this contraption telling you how to slide your phone over the surface. The first tag would tell the software where to pay. The second would receive the payment. Now an attacker can't rewrite the first tag and the second isn't allowed to contain the header.
It might be worth playing around to see how much more expensive using two tags + a bit of backing material makes the jar.
a) Very cheap
b) Very easy
because I want to find a way for people to quickly create and use tip jars. Tipees probably aren't going to go through complicated ID verification schemes and tippers probably won't want to check.
I can see two other ways to deal with this.
The first is to shrug and say, well, so what. If somebody rewrites the tag then they still have to get it back after a while and empty it. If somebody is passing the tag around a crowd, for example, that's probably impractical. If somebody is watching the tag then the attacker has to come and tip once then come back some hours later and "tip" again (empty the jar). That's a bit suspicious, especially when you notice that the jar does not contain tips you saw happening.
In other words, there may be situational or social solutions.
A second solution is to have two tags, laid out side by side. One is small but write-protected and contains the key, label and suggested amount. The second is the read/write 4k tag. The software expects to see the data be separated. Instead of touching once to tip, you "tap and slide". There'd be an arrow printed on top of this contraption telling you how to slide your phone over the surface. The first tag would tell the software where to pay. The second would receive the payment. Now an attacker can't rewrite the first tag and the second isn't allowed to contain the header.
It might be worth playing around to see how much more expensive using two tags + a bit of backing material makes the jar.
The problem of using NFC tag for payments as you correctly pointed out at the end of your post, is the possibility to swap out tags or even to stick a pirate tag on top of a legit tag.
Therefore the tags must be signed with a certificate that is recognized by the reader's mobile app.
The mobile app must tell the customer whether the NFC tag is legit or not before she pays.
Therefore the tags must be signed with a certificate that is recognized by the reader's mobile app.
The mobile app must tell the customer whether the NFC tag is legit or not before she pays.
From my post:
So yes, encrypting the private keys under the public key is already a part of the proposal.
You don't really want public keys in the tag for the aforementioned privacy reasons. Even with deterministic generation it means you can see all donations both before and after you touch your phone to the tag.
Quote
When the user wakes up their phone and touches it to the tag, it reads the header packet and inserts a new private key into the wallet. It crafts a transaction that spends the suggested amount of Bitcoin to the newly created private key and stashes it away for later. The private key is then encrypted under the public key found in the tags header and written to the part of the tag indicated by the offset counter.
So yes, encrypting the private keys under the public key is already a part of the proposal.
You don't really want public keys in the tag for the aforementioned privacy reasons. Even with deterministic generation it means you can see all donations both before and after you touch your phone to the tag.
Is it possible to communicate encrypted privet key using blockchain?
From my post:
So yes, encrypting the private keys under the public key is already a part of the proposal.
You don't really want public keys in the tag for the aforementioned privacy reasons. Even with deterministic generation it means you can see all donations both before and after you touch your phone to the tag.
Quote
When the user wakes up their phone and touches it to the tag, it reads the header packet and inserts a new private key into the wallet. It crafts a transaction that spends the suggested amount of Bitcoin to the newly created private key and stashes it away for later. The private key is then encrypted under the public key found in the tags header and written to the part of the tag indicated by the offset counter.
So yes, encrypting the private keys under the public key is already a part of the proposal.
You don't really want public keys in the tag for the aforementioned privacy reasons. Even with deterministic generation it means you can see all donations both before and after you touch your phone to the tag.
What if part of the mini wallet container contained a public key, with which all added private keys were added? This way, only the intended recipient could retreive the funds, though others could still destroy them
I also wonder about using a branch of a heirarchal deterministic wallet for normal Bitcoin payments. The tipper would read the most recent public key from the tag, generate the next one in the sequence, send Bitcoins, and then either append that address to the list, or just replace the previous one.
I also wonder about using a branch of a heirarchal deterministic wallet for normal Bitcoin payments. The tipper would read the most recent public key from the tag, generate the next one in the sequence, send Bitcoins, and then either append that address to the list, or just replace the previous one.
Yes, as I said at the start you can just embed a Bitcoin URI or something else that will trigger a payment protocol. You can do that but it makes you dependent on a third party to run the payment protocol (vend addresses) for you. That means you need use some payment processing company or run the server yourself (but that involves a lot of work, you're not going to get street performers doing that).
Running a payment protocol is cheap, so it may be the case that it'll never be an issue and sites that vend addresses on your behalf will end up being so plentiful that they're free, kind of like pastebin-style sites are today. If they do end up being a free service provided out of generosity then they could be integrated with the tag writer app and you're done.
If you don't want to rely on a third party to help you collect payments, I think this approach is still the better one. Generally we want to avoid middlemen in Bitcoin, that's kind of the point of the system.
A tipped person could indeed break the privacy of the system by collecting them all under one key. Ideally wallet software would be written so that never happens by accident and there's no reason to do it explicitly.
Running a payment protocol is cheap, so it may be the case that it'll never be an issue and sites that vend addresses on your behalf will end up being so plentiful that they're free, kind of like pastebin-style sites are today. If they do end up being a free service provided out of generosity then they could be integrated with the tag writer app and you're done.
If you don't want to rely on a third party to help you collect payments, I think this approach is still the better one. Generally we want to avoid middlemen in Bitcoin, that's kind of the point of the system.
A tipped person could indeed break the privacy of the system by collecting them all under one key. Ideally wallet software would be written so that never happens by accident and there's no reason to do it explicitly.
For bitcoin to work, both sides do need eventual internet connectivity. So why not put a string like "bitcoin+http://www.example.com/tipjar?amount=0.1&message=Thanks+for+tipping+Tipsy+the+Clown" into the tag (or QR-code)? The tipping-app will then learn the amount, a message to display, and a URL where to eventually get a bitcoin address to send the payment to.
Yes, one still has to trust the tipjar to generate fresh addresses, however nothing prevents a tipped person from directly sending all tips to a vanity address either.
Yes, one still has to trust the tipjar to generate fresh addresses, however nothing prevents a tipped person from directly sending all tips to a vanity address either.
What are NFC tags?
Writable NFC tags like the Mifare 4k are interesting because they are cheap, approximately the thickness of a credit card and offer unpowered read/write data storage. This makes them ideal for building a super cheap Bitcoin "tip jar" that offers good privacy for the tipee and can be integrated into a poster or drinks mat, just with some sticky tape. The user would tip by simply touching their phone to the NFC tag ... and that's it. No further interaction is necessary. It would be as easy to send money this way as putting coins into a charity box is today.
The problem
NFC tags have no battery and no CPU. We can embed a bitcoin URI into a tag such that it'll open up your Android wallet app very easily, nothing special is required for that (there are tag writer apps in the Play Store). The problem is that you can only embed one public key/address into the tag, which means you lose a lot of privacy - anyone can see how much you've received and when, also they can see when you move the funds and so on. All the same problems that putting an address into your forum sig has, so does this.
I think we have consensus that we need to move the Bitcoin world away from just throwing up static addresses globally linkable to users identities. It inevitably can cause surprising and unintuitive privacy leaks. I've been pushing the idea of an HTTP based payment protocol for a long time now, it's an obvious idea and Pieters discussion of it at the conference is a great next step.
Unfortunately because NFC tags are just dumb storage, you can't have them take part in a payment protocol. It appears you can choose between private and cheap - pick one.
The solution
Fortunately we can improve things in the following way. Write to the NFC tag a header packet containing a public key and an offset counter, which is initialized to a random number. The header can also contain other data you might find in a payment URI like a message and a suggested amount. Now fill the rest of the tags storage with random numbers too.
When the user wakes up their phone and touches it to the tag, it reads the header packet and inserts a new private key into the wallet. It crafts a transaction that spends the suggested amount of Bitcoin to the newly created private key and stashes it away for later. The private key is then encrypted under the public key found in the tags header and written to the part of the tag indicated by the offset counter. The offset counter is then itself incremented and if necessary, wrapped around to zero.
The app puts a notification icon in the users notification bar, makes a sound, vibrates etc but does not request any confirmation. Instead the transaction is kept around for 10 minutes or so and if the user doesn't explicitly cancel it, broadcasts it at that time. The user can also adjust the value being sent to the new private key if they aren't happy with the default suggested amount. Even once the transaction is broadcast, it can still be revoked until the next step, which is why it's safe to just have the act of touching trigger payment - the user can undo unexpected payments easily.
Every so often the tip collector comes past with a dedicated app running on his phone and touches the tag. This loads all the private keys that were written to the tag, decrypts them and inserts them into a fresh wallet that is then synced with the chain. The app then proceeds to spend each donation to a newly generated key (per donation) thus preventing the user from reclaiming it and locking in the payment.
This scheme has the following useful features:
Example applications
Other notes
You might wonder why I'm focusing on tips and donations here. The reason is the revocability - to get the one-touch experience you have to allow the user to undo it for a short while afterwards. Also, nothing stops somebody from erasing the contents of the card or otherwise screwing with it, so there needs to be a bit of pre-existing trust for it to work.
There's one other attack that can cause problems - an evil person could swap out the legit tag for their own, or just rewrite the existing tag. Because tags don't have any kind of verified identity you could end up donating to the wrong person by mistake. If people wanted protection from that, a lightweight kind of certificate authority setup could be made. The header would include a signature from a trusted authority over the public key/suggested amount and message. The authority would only sign if the message wasn't confusing and matched the identity of the tipee they are verifying. It's probably not required for v1.
Writable NFC tags like the Mifare 4k are interesting because they are cheap, approximately the thickness of a credit card and offer unpowered read/write data storage. This makes them ideal for building a super cheap Bitcoin "tip jar" that offers good privacy for the tipee and can be integrated into a poster or drinks mat, just with some sticky tape. The user would tip by simply touching their phone to the NFC tag ... and that's it. No further interaction is necessary. It would be as easy to send money this way as putting coins into a charity box is today.
The problem
NFC tags have no battery and no CPU. We can embed a bitcoin URI into a tag such that it'll open up your Android wallet app very easily, nothing special is required for that (there are tag writer apps in the Play Store). The problem is that you can only embed one public key/address into the tag, which means you lose a lot of privacy - anyone can see how much you've received and when, also they can see when you move the funds and so on. All the same problems that putting an address into your forum sig has, so does this.
I think we have consensus that we need to move the Bitcoin world away from just throwing up static addresses globally linkable to users identities. It inevitably can cause surprising and unintuitive privacy leaks. I've been pushing the idea of an HTTP based payment protocol for a long time now, it's an obvious idea and Pieters discussion of it at the conference is a great next step.
Unfortunately because NFC tags are just dumb storage, you can't have them take part in a payment protocol. It appears you can choose between private and cheap - pick one.
The solution
Fortunately we can improve things in the following way. Write to the NFC tag a header packet containing a public key and an offset counter, which is initialized to a random number. The header can also contain other data you might find in a payment URI like a message and a suggested amount. Now fill the rest of the tags storage with random numbers too.
When the user wakes up their phone and touches it to the tag, it reads the header packet and inserts a new private key into the wallet. It crafts a transaction that spends the suggested amount of Bitcoin to the newly created private key and stashes it away for later. The private key is then encrypted under the public key found in the tags header and written to the part of the tag indicated by the offset counter. The offset counter is then itself incremented and if necessary, wrapped around to zero.
The app puts a notification icon in the users notification bar, makes a sound, vibrates etc but does not request any confirmation. Instead the transaction is kept around for 10 minutes or so and if the user doesn't explicitly cancel it, broadcasts it at that time. The user can also adjust the value being sent to the new private key if they aren't happy with the default suggested amount. Even once the transaction is broadcast, it can still be revoked until the next step, which is why it's safe to just have the act of touching trigger payment - the user can undo unexpected payments easily.
Every so often the tip collector comes past with a dedicated app running on his phone and touches the tag. This loads all the private keys that were written to the tag, decrypts them and inserts them into a fresh wallet that is then synced with the chain. The app then proceeds to spend each donation to a newly generated key (per donation) thus preventing the user from reclaiming it and locking in the payment.
This scheme has the following useful features:
- Users who touch the tag cannot find out how many donations there were/when they were made/how big they were, because the offset counter was initialized to a random value and wraps around, so the value is meaningless.
- They can't read the data to figure out how many keys there are because encrypted private keys are just random numbers too so you can't tell the difference.
- Because the transaction isn't actually committed until some time after the touch, the act of tipping can be just switching on the phones screen with the hardware button and then touching it to the tag. It's a 3 second job. If the user donates accidentally they can just undo the action.
- The only expensive part of this is the smartphones, which many people have already. Because NFC tags are so cheap and the software would be free, absolutely anyone could use this scheme without any technical knowledge being required. They'd just have to "empty the jar" every so often.
Example applications
- Sticky-tape a few tags to the back of a project poster at a fair and then print suggested tip amounts over them, so you donate by touching the phone to the part of the poster that has the amount you want to tip.
- Whilst doing a live show/speech/whatever give out a smartcard that contains an NFC tag. The crowd can pass it around and put money in whilst you're performing. You collect it and empty it at the end.
- At a restaurant or bar the waitress can put their personal tipping card on the table when they first come over and collect it at the end. This is probably simpler than trying to integrate tipping directly with the payment for the meal itself.
Other notes
You might wonder why I'm focusing on tips and donations here. The reason is the revocability - to get the one-touch experience you have to allow the user to undo it for a short while afterwards. Also, nothing stops somebody from erasing the contents of the card or otherwise screwing with it, so there needs to be a bit of pre-existing trust for it to work.
There's one other attack that can cause problems - an evil person could swap out the legit tag for their own, or just rewrite the existing tag. Because tags don't have any kind of verified identity you could end up donating to the wrong person by mistake. If people wanted protection from that, a lightweight kind of certificate authority setup could be made. The header would include a signature from a trusted authority over the public key/suggested amount and message. The authority would only sign if the message wasn't confusing and matched the identity of the tipee they are verifying. It's probably not required for v1.
Jump to: