Topic: A reusable paper wallet (Read 956 times)
Here's the beauty, with that seed, you can fund at time of purchase vs making store pay for books up front
Use hd wallets to make generating and loading wallet easy. The seed could be the wallet guid
Perfect I will read up on Bip32 and see how it works. Quickl scan looks like the tree function idea is perfect for this implementation. Looks like I can make a sub key Book of coins and each book has a separate Bip38 password so that I can send transactions to each sub address over a period of time and each Field Worker can Manage the books in their group. So we can collect all the of the sub addresses under single public key for funding of that initiative and then manage the entire thing under a single wallet.
........................................................Wallet for Campaign Seed
............................Field Worker A ............................................Field Worker B
..............Group A1................Group A2..............................Group B1..........Group B2
...Book 1A1..Book 2A1.....BOOK 1A2.Book 2A2..........Book 1B1..Book 2B1.....Book 1B2..Book 2B2
Easy do it like currency. Sell a book of 100 satoshis, they tear out what they need.
The more I think about your idea @Bitpop the more I like it. I have lots of books of coins and a QR code and a scratch off password on the front of each book. The person distributing books scans QR code on front of Book and every page in the book receives coins. The coins are BIP38 protected by the scratch off password so the consumer knows no one knows their password. When they run out they go back to the person distributing the book and get another book.
REALLY LOW TECH IDEA, LOVE IT
Use hd wallets to make generating and loading wallet easy. The seed could be the wallet guid
Easy do it like currency. Sell a book of 100 satoshis, they tear out what they need.
The more I think about your idea @Bitpop the more I like it. I have lots of books of coins and a QR code and a scratch off password on the front of each book. The person distributing books scans QR code on front of Book and every page in the book receives coins over a period of time (1 gets activated each week). The coins are BIP38 protected by the scratch off password so the consumer knows no one knows their password. When they run out they go back to the person distributing the book and get another book.
REALLY LOW TECH IDEA, LOVE IT
I like the idea of the book of coins but not sure how to top up remotely when they run out.
What I am really looking for is something like a coinkite solution but on the cheap. https://coinkite.com/faq/security They use chip and pin with proprietary terminals so it makes the entire process to expensive for what I am trying to achieve. Think I will fuss with the split key / proprietary client idea more.
Maybe if the second half of key is on a central server so the central server processes the transaction. Mobile phone sends consumers public public key / Half of consumers private key / Comsumers password / receivers public key. We can at least validate the receiver address has the right to receive the funds (Is a registered receiver of bitcoins and user of the specific client) so if it gets abused stop in future.
What I am really looking for is something like a coinkite solution but on the cheap. https://coinkite.com/faq/security They use chip and pin with proprietary terminals so it makes the entire process to expensive for what I am trying to achieve. Think I will fuss with the split key / proprietary client idea more.
Maybe if the second half of key is on a central server so the central server processes the transaction. Mobile phone sends consumers public public key / Half of consumers private key / Comsumers password / receivers public key. We can at least validate the receiver address has the right to receive the funds (Is a registered receiver of bitcoins and user of the specific client) so if it gets abused stop in future.
Easy do it like currency. Sell a book of 100 satoshis, they tear out what they need.
This is not a good approach. There is need to expose the private key ever.
I'd give you a suggestion but know you, I'm exploring a similar business idea myself...
I'd give you a suggestion but know you, I'm exploring a similar business idea myself...
Yes custom software with 2 factor but then they need a VeriSign token. Wait that requires a server so you'd have to store the private key though that can be bip38.
Plus you said the password is visible? That store will save them all then sell it to the merchants. No key logger needed.
You need a wallet with an lcd and pin pad. Which can be cheap at volume.
Plus you said the password is visible? That store will save them all then sell it to the merchants. No key logger needed.
You need a wallet with an lcd and pin pad. Which can be cheap at volume.
I've thought about this too but I don't see a solution other than selling stacks of 100 paper foldable wallets, which are 1 time use.
You really need a new priv key for every spend tx, there is no way around that.
Maybe a 2factor auth, replacing the priv key by a standard timestamped code, like google authenticator. But you push the problem from having your own wallet to having your own authenticator.
You really need a new priv key for every spend tx, there is no way around that.
Maybe a 2factor auth, replacing the priv key by a standard timestamped code, like google authenticator. But you push the problem from having your own wallet to having your own authenticator.
In that case, wouldn't it be guaranteed where they use it would be compromised?
Thats the obvious question. If it is BIP38 and only the consumer who types the password in knows the password would that compromise the security of the card to the point where it is unusable for low value transactions.
I wish I can think of something. But bip38 wouldn't protect against guaranteed key loggers on all point of sales.
In that case, wouldn't it be guaranteed where they use it would be compromised?
Thats the obvious question. If it is BIP38 and only the consumer who types the password in knows the password would that compromise the security of the card to the point where it is unusable for low value transactions.
In that case, wouldn't it be guaranteed where they use it would be compromised?
I believe the common use case scenario is only the place where they spend the coins would likely have an android phone. We have millions of people in the world who unfortunately don't even have access to food so the probability the individuals who need help have a mobile phone and a cell phone contract for internet access, electricity to charge the phone while not having the basic necessities of life would be slim.
Peter
http://www.againsthunger.org
Peter
http://www.againsthunger.org
My thought is if they have an android why a card?
I am trying to come up with a method of providing a re-suable paper wallet that can be topped up and used over and over again using Bitcoin transfers. The wallet is for people who are un-banked where only the merchants would have access to mobile phones but people will need a way to securely hold their bitcoin for the purpose of spending it.
My logic was to use a BIP38 encrypted plastic card (prototype below) that has a private key that is concealed with scratch tape ( like you have on phone cards) and they are also provided with a 5 digit alphanumeric password in a pull tab. When the person receives the plastic wallet with scratch tape and seperate password in tact they know it has not been tampered with. The process memorize the password and scratch off private key. The card is shipped with no balance and the initial request for funds is made by the person distributing the cards.
The challenge I have is once you have spent money by exposing the private key we have reduced the level of security. Is the password that would be entered into the phone sufficient. Key loggers etc could grab the password or a pool of fast computers could hash out a 5 digit password in a few days. The balance would be < 10mBit so does make sense to hash out the password but the key log threat I believe is real.
Does anyone have a low cost way to provide bitcoins to people that they can spend over and over again without being compromised. I had considered split private key and a unique android client that has the second half of the key so it could only ever work with this android app but interested in other ideas.
http://againsthunger.org/files/4313/9256/4888/photo_2.JPG
Peter
http://www.againsthunger.org
My logic was to use a BIP38 encrypted plastic card (prototype below) that has a private key that is concealed with scratch tape ( like you have on phone cards) and they are also provided with a 5 digit alphanumeric password in a pull tab. When the person receives the plastic wallet with scratch tape and seperate password in tact they know it has not been tampered with. The process memorize the password and scratch off private key. The card is shipped with no balance and the initial request for funds is made by the person distributing the cards.
The challenge I have is once you have spent money by exposing the private key we have reduced the level of security. Is the password that would be entered into the phone sufficient. Key loggers etc could grab the password or a pool of fast computers could hash out a 5 digit password in a few days. The balance would be < 10mBit so does make sense to hash out the password but the key log threat I believe is real.
Does anyone have a low cost way to provide bitcoins to people that they can spend over and over again without being compromised. I had considered split private key and a unique android client that has the second half of the key so it could only ever work with this android app but interested in other ideas.
http://againsthunger.org/files/4313/9256/4888/photo_2.JPG
Peter
http://www.againsthunger.org
Jump to: