Topic: Extra Security - a wallet that doesn't know its private keys (possible bounty) (Read 1222 times)

I'm not sure, the math escapes me at the moment.  It's got somewhere between 10 and 20 characters, caps, non caps, special characters, and unicode may or may not be thrown in.  Let me know how that goes for you, I'll take my chances.

You make a great point though.  Encrypted private keys do in theory "reduce" security but to levels still tolerable.  Dynamically re-generating the encrypted private keys each time could be useful.


False, the second wallet may be set up to specifically confirm, reject, or redirect a transaction to a failsafe.  Why is this significant?  Say I'm thief who's just tried to withdraw your bitcoin.  This specialty wallet setup would basically be a glorified m of n transaction lock requiring them to have access to multiple unrelated devices simultaneously in order to truly spend your funds.  The failsafe is important because if needed, you can redirect the funds back to a safe destination

BTW, does the epic pass-poem protecting that BIP 38 key have at least 160 bits of true entropy? If not, you've just weakened your security. For future reference, sharing private keys, even encrypted, is not recommended.

>>The second wallet is also completely incapable of generating precursor transactions for itself, requiring input from the first wallet to begin with.

Then funds accidentally sent to the second wallet would be trapped.

I guess I need to follow up with this idea and mention that while I do like the 0038 + Mycelium option for now, it's not as secure as I'd like it to be.  A keylogger on the device could (in theory) capture the password, no matter how complex, and image of the encrypted private key as I try to spend from it.  

I want to design a mechanism to protect your funds even from password disclosure.  The ultimate challenge would be to give you my password and the opportunity to spend my own funds, but yet I've done something so that before the transaction can truly be broadcast, it must go through another approval by me or a time delay in which I can claim it back.

(Side note, this is not a method to do chargebacks with bitcoin.  It would all happen before transactions are seen on the blockchain)

1) yes. it is cool.
2) for that you will need to install a custom android keyboard, configure exotic languages or use the clipboard (less secure, all apps have access to it)
3) in Mycelium, change always flows back to the "biggest contributer" of a transaction. so if you spend from paper wallet, it flows back to paper.
4) this is currently not possible in any wallet, afaik

Okay, I will admit Mycelium + 0038 cold storage spending is pretty darn cool. 

Couple issues: Ideally I like to throw in unicode characters to encrypt the private key.  Couple dozen of those will ruin an attackers day and make it secure enough to store in broad daylight.  I'll have to see if there's an easier way to enter these

How does Mycelium handle change back to a paper wallet?  Does it keep the remaining funds in the paper wallet address and is this any less secure to use the same wallet again? 

I ask this because ideally, I'd have a second wallet that can set up new BIP 0038 each time dynamically, whenever BTC is spent.

1. Install Mycelium on some Android device and start it
2. Click the options button and select Settings and enable Expert Mode -> hit back button
3. Go to Keys tab and click the + button and scan the bitcoin address of your BIP38 paper backup (you now have a read-only address)
4. (optional) In the Keys tab select and delete the key that was automatically generated when the wallet was first started
5. swipe to the balance tab to see the balance of your BIP38 key

Whenever you want to spend:
1. Click the options button and select Cold Storage
2. Scan the BIP38 private key
3. Enter password and go through the spending wizard

Ah very cool, mind explaining briefly how this works and how it might be different from the above idea?

it looks like you are looking for the Mycelium Wallet with watch-only addresses and Bip38 cold storage spending support.

Here's one of my addresses and its private key:

Public: 14941RiJVBLRJNBxbdo2WjUeRwB7REApyu
Private: 6PfT1TzGCoFmB1wCLjfPA1vtQfKuy4RiYoF8QZQ43dxuMkF8ydgurrmyhR

I'm perfectly comfortable with sharing it, as it starts with a numeral '6' designating the BIP 0038 protection.  But I wonder if this simple but powerful security scheme could be even more useful.

Imagine a wallet that's much more resistant to theft because it doesn't know it's own private keys to spend the coins, it only knows the BIP 0038 version of the private key.  It can receive coins anytime by sending to an address there, but when creating a transaction to spend funds it doesn't actually communicate with the blockchain yet.  It requires your regular password1 input, and a sort of precursor transaction is created that gets broadcast "somewhere else."

What's that somewhere else?  It's a repository for the precursor transactions to hang out before being manually approved.  The 2nd half of the wallet, which ideally exists entirely on another device, can be used to enter password2 and truly forward the transaction to be broadcast to the bitcoin blockchain upon input.  The second wallet is also completely incapable of generating precursor transactions for itself, requiring input from the first wallet to begin with.

How is this possibly useful as an anti-theft measure?
1) One of the biggest points is that a spend attempt generates a precursor first.  This is a very vocal way of declaring intention without actually finalizing a transfer of BTC.  The extra checkpoint creates a 2nd layer of security to prevent bitcoins from being stolen.

2) Each half of the wallet represents a necessary but singularly insufficient means to spend bitcoin.  If one is compromised, the other is still needed.   Great care would have to be taken to ensure this.  A benchmark test would be to allow an attacker complete control of password1 or 2 and they should still be unable to successfully spend the coins.

If set up correctly, it would mean a hot wallet that's much harder to steal from and can still spend coins quickly, just with a single extra hurdle to broadcast the transaction.  Please note this is not a method to do chargebacks, no one can or should accept a precursor transaction itself as payment.

Last note, I realize this is similar but slightly different to m-of-n transactions.  They key here is that I think it's useful to know if a transaction is being started but is not yet finalized.  This is invaluable knowledge for the victim of potential theft.

Curious to know your thoughts.