Topic: Making Hot Wallets Impossible to Steal - Now with 5 BTC bounty (Read 4102 times)

Woot, I always though if you have a really long password for Hot Wallet (bitcoin-qt) you are pretty much hack free right since brute force take years?

http://www.bitcointrezor.com/

What about a physical button, that you have to press to access funds.

I know it sounds dumb, and sounded even dumber as I read it!

but is it possible?

i think if some make transaction

you be save walet empty?

this low level actual i think

not posible make walet secure 100%


i lost in my life in practic 4x time my walets lol

this ture i some time realy cry 

I think it maybe simpler (and perhaps equivalent I didnt digest Sergio's post yet maybe we thought of the same thing) to say you only load the hotwallet with timelocked funds, so that they can be spent after the timelock, or undone with a cold wallet key before the timelock.

Now unfortunately bitcoin timelock is not a function but a property of a script, so you cant write "sig cold OR ( timelock > +6 AND sig hot ), but never the less you can do things like that indirectly.  (Also locktime doesnt even work properly in that at some point its implementation was changed so that is the users responsibility to send it after the locktime has passed, otherwise nodes discard it.)

It seems that the simplest way to implement the OR you can do is load the hot wallet with cold key signe, timelock > +6 AND sig hot (where hot is the hot wallets address).  Then the hot wallet private key can spend the timelocked coins to users addresses.

The exchange can post the tx after timelock, but the exchange can also give it to the user now to repost himself, and to show to other users, and create follow-on dependent transactions, eg to spend it before the time lock has passed (the user accepting before locktime has passed is in an analogous situation to 0-confirms - if the coin turns out to be as a result of  a hot-wallet hack, the coin will be undone).

How the coin is undone is the exchange monitors transactions, and if it sees something anomalous it releases a set of transactions sweeping all contested hot wallet spends to a cold address.  It can have the cold-signed sweep-to-cold transaction set pre-prepared even so there is no need to access the cold wallet under pressure.

Doing that does remove the immediate irredeemability from bitcoins though.  eg if the cold transaction is every hour, then the merchants selling online irredeemable virtual goods may lose their goods if an exchange theft results in their payment being undone.  Ie in the event of theft, the person who most likely loses is the merchant that was abused to cash out.  Sounds a bit like credit card situation.

Adam

Actually you can. Pick N nodes, perhaps using proof of stake weighting to avoid Sybil attacks, and do (N/2) / N secret sharing over them. You can then add another operation of "rebalancing" by which the N nodes send the keys to M new nodes without the keys ever coming together (informally, you secret share the secret shares, and when every new node receives a share from each old node it can combine them into a secret share of the original computation).

That's actually a really good idea.

Interesting, this has identical goal to the "Saving Address" feature of Mastercoin.

Informal Proof: As you see, any payment that goes out from Txo MUST go through any TxIn, and then it MUST go thought the corresponding TxOut transaction, which are separated exactly delta time. Since the private keys of Txo(i) are not stored in the hot wallet, there is no other way to redeem the funds.

Also note that by burning the ticks periodically, you prevent both TxIn and TxOut for being published simultaneously.

Note that you MUST also monitor the block-chain for the tick burning transactions, if a tick is missing for too long, then you MUST also follow the theft procedure.

The "Tick" method

Let's say you have X BTC divided in N transaction outputs Txo(i)=(TxHash(i),outN(i)) for 0<=iTo simplify the explanation, let K(output) be the input (hash + outN + signature ) to redeem the output.

Preparation stage

Once a month, you use a secure computer, load cold storage keys and:

1. you create a sequence of transactions TxTick(0)...TxTick(M-1) called "ticks".

Each Tick transaction pays almost the same amount to the following (minus the fees). So TxTick(j).input[0] redeems the funds stored in the output of TxTick(j-1).output[0]. Each ticks uses a different destination address. Also each tick transaction has a nLockTime set at equally spaced deadlines (separation of delta time). (e.g. once a day, or once an hour). The ticks must cover the time for the full month.

2. For each Txo(i) and each TxTick(j) you create two transactions TxIn(i,j) and TxOut(i,j).

TxIn(i,j) has two inputs and one two outputs:
- TxIn(i,j).input[0] = K(Txo(i))
- TxIn(i,j).input[1] = K(TxTick(j).output[0])
- TxIn(i,j).output[0] = new unique address

TxOut(i,j) has two inputs and one output:

- TxOut(i,j).input[0] = K(TxIn(i,j).output[0])                (signature has SIGHASH_NONE flag)
- TxOut(i,j).input[1] = K(TxTick(j+delta).output[0])     (signature has SIGHASH_NONE flag, here delta is the time interval to lock funds)
- TxOut(i,j).output[0] = empty (to be filled at payment time)


All TxIn and TxOut and TxTick transactions go to the hot wallet. All private keys generated during the process go to cold storage (or at least are encrypted and the encryption-key is cold stored)

Normal use

Each tick-interval, you broadcast the corresponding TxTick to be included in the blockchain, so previous tick outputs cannot be reused.

Suppose you want to pay X/K (exactly one Txo, say Txo(i)) to the address DstAddr.

1. Choose TxIn(i,j) and TxOut(i,j), where j is the next tick which has not been spent.
2. Fill the field TxOut(i,j).input[0] with DstAddr.
3. Broadcast TxIn(i,j).
3. Wait one delta interval
4. Broadcast TxOut(i,j), and the payment is done.


Theft

In case that the hot wallet is compromised by an attacker, and the attacker is willing to spend your funds he will be forced to broadcast a TxIn() transaction.

If you're monitoring the block-chain, then you will have a delta interval to open your cold storage keys and immediately re-send all funds stored in unspent Txo AND in the TxIn's recently broadcasted to a newly generated addresses.

Best regards, I hope this helps (as long as I know, it has never been proposed before)

If you wish to send me the bounty, my address is: 17mcFB7Xyymd9hxp2bgNPz1ruWsdoPoCnZ

** Translation from Portuguese BR, helped by google translator.

I am thinking about a solution, but I´m not sure if this is *the ultimate gun against thefts*. Probably only increases the cost of an attack.
But anyway thats my idea:

1. Bitcoind without any coins, in server mode.
2. Another exe program (keyserver) with a bunch of address embedded in source code (let´s say 10 milion address).
   2.1. Address are generated and encrypted before turning part of source code, funds are informed at this moment.
3. This program receive a spent request and wait for some time before acting, perhaps some more security checks could be made too.
3.1 The keyserver selects the keys to spend and then adds this keys to bitcoind, and using rpc create a transaction. The rest of the payment are sent to a external address.
3.2 the keyserver does not manage the balance of keys, it only spents the total funds of every key.
4. The encryption key is requested on two situations:
4.1 On the source code compilation to generate the keys.
4.2 On program start, and at this moment I recommend another layer of encryption to protect from keyloggers and sniffers.
5. Communication between your app and the keyserver could be made using a simple sql table or text files, even unencrypted. But can be signed too, if you you want.

Positive aspects of this solution:

- A thief never have access to the private keys, and need the decryption key to execute the exe. This decryption key never get stored on server.

- Spends could be delayed, and with another levels of verifications if needed.

- Bitcoin in server mode have no coins, therefore thief could see bitcoin.conf without consequences.

- The unencrypted keys are available only on source code, compiled far away from main server.

Possible attacks:
- One feasible attack can be attach a debug on running exe and view the memory space with the current address (on a light speed transition, possible but very expensive).

- Other possible attack could be get the exe, reverse engine the assembly, and brute force the keys,  anyway too much expensive.

- The real risk occurs when starting the exe, when it is possible to use a keylogger or a sniffer to get the secret. But even getting the secret would still be necessary to reverse engineer the exe to get the keys. Work that requires deep knowledge of machine language.

Negative aspects:

- too much complex to implement, need low level language (C).
- the risk is reduced but is not a definitive solution against thefts.

I say it's possible to achieve similar properties with simple methods, but requires periodic access to the cold storage.

I'll post shortly

How's the key encrypted/decrypted? With some piece of information (password/another key/etc.). How do you hide that information? Hint: it's turtles all the way down.
Seriously, enforcement isn't magical. Unless I'm missing something really obvious, your approach isn't going to fly.

Your idea can work, but it's not safe/distributed in the same way that bitcoin is:

Approach 1:
1. Use Shamir's Secret Sharing to split the key into n pieces of which n/2+1 are required to recreate the original key. Send each key to a different peer.
2. When you want to spend your money, you need to contact n/2+1 peers, and request their part of the key. Once you have enough parts, you can recreate it and sign your transaction.

Problems with this approach:
1. If n/2+1 peers collude together, they can get the full key back (and maybe get a cut of your stolen funds by giving it to the guy that stole your money).
2. You can't tell if the people you're sending your parts of the key are actually independent, or they're all run by one attacker (Sybil attack).
3. If enough peers go away, you have lost the ability to spend your funds, ever. And you can't get around that by asking the peers to share their part of the key with others, because that breaks the security.
4. The set of rules under which to allow spending is openly known. So a smart thief will know what conditions to satisfy in order to spend your funds.

So you end up with Approach 2:

1. Use trusted peers that have some reputation to lose, and that you're reasonnably confident will remain online semi-permanently.
2. Give each peer a different full key. Store a copy on paper, to guard against loss.
3. Store money in a "m of n" address, ideally where m is high.

It's safer but not peer-to-peer. In fact it's one of jedunnigan's suggestions.

I don't want to use a peer-to-peer network to hide information.  This parallel blockchain would openly store the 2nd encrypted private keys.  Anyone could look at them, no one would have a clue what the actual private key is due to the encryption.  Importantly, this network enforces your rules as to when this 2nd extra key can be decrypted.  It reaches consensus among a majority of users so someone with a rogue client can't artificially set conditions to reveal the true private key ahead of time.  By the time it finally does decrypt your 2nd private key, it has already forwarded the transaction to the bitcoin blockchain.

The ultimate point is that it allows you to enforce a spend delay on the coins before they even go out of your wallet.  Whenever someone tries to move them you know about it + can do something about it before they're gone for good.

You can't use a peer-to-peer network to hide information, which is what you'd need to actually make this little scheme work.

jedunnigan's suggestions are correct, there's also a variant of the OTP approach that doesn't even require a third party to work.

Coastermonger: Are you flexible as to what security approach can be used? The OTP toolkit is probably the best one in terms of user friendliness, and requiring little to no extra software.

Splitting the key in this manner seems like an odd way to go about it.

Perhaps a slight manipulation of this protocol works better than a 'trusted' peer network?


Or perhaps a two factor wallet with one time password to protect the coins?

You could probably use a CoinCovenant to limit where the funds could be sent. Have the private key of the receive-enabled coins located on a different server or something...

I hear you, but this method above would split control of the address into 2 keys, one of which is on your computer and the other is held in a trustless peer to peer network behind rules which cannot be bent.  In this fashion, a thief could gain complete access to your computer and still be unable to immediately spend your BTC.  You would have every opportunity to thwart the transaction before it is finalized in the Vault Chain and forwarded to the bitcoin Blockchain.  

Hacking your computer would be necessary but no longer be sufficient to stealing your funds, making it much riskier since the payout only possible if you're not paying attention.

Bro, I think the only way to make wallets "unstealeble" (more on that) is to inject all differend codes and private keys of a wallet in all sorts of files.
Like key 1 is stored in wallet.dat, key 2 in a metadata of a .mp3, key 3 in a register of Windows/Linux/not worth noting.

Impossible to steal is a big word and that is why we have offline wallets, becouse every freak can hijack your PC and copy the Wallet.dat and even if you set a password with 30 characters on that file he could usea keylogger which would require you to encrypt the passwords and keep going...

Long story short: Inpossible if you ask me.

Cold storage and hardware wallets are fine, I am not here to knock them. I am looking to improve hot wallet security.

It occurred to me the other day that if I had some way of enforcing a "spend delay" on my bitcoins, they could never be stolen from my hot wallet during that delay.
I would need the ability to store bitcoins with the following rules:

• Specify a delay time: X
• If the last spend attempt is greater than X time ago, send the transaction.
• If not, or if no previous attempt, create a new spend attempt.

These simple but powerful rules (if enforced) would mean I could spend my coins as I please anytime, simply suffering a small delay before they actually start getting sent out. If a thief accessed my private key and tried to spend my BTC they too would suffer the same delay. Yet, as long as I was watching (or had some program to watch for me) I'd be able to redirect the transaction back to a destination of my choice!  In order to avoid a game of endlessly redirecting transactions between myself and a thief, the wallet could also include instructions for a fail-safe address.  

But how on earth could these rules be enforced to the most absolute degree possible? It's not good enough to simply design a wallet with these constraints, because a thief could design another wallet to simply bypass these rules.  How could I make sure that everyone absolutely had to follow them?

Imagine a special wallet program that contributes to and communicates with another kind of blockchain. It does not replace the bitcoin blockchain, but it moves in parallel to it.  It would be a peer to peer decentralized network that stores transaction attempts, private keys, and the specific delays made by their owners. It could ultimately forward to the bitcoin network to create transactions, but only after the specified waiting conditions are satisfied.

Creating an address in a Vault Wallet creates a 2-of-2 multisignature address that requires both private keys to spend. Within minutes it is confirmed and your rules are eternally bound to this address.  
You hold one private key in your wallet, encrypted by a password (similar to the bitcoin-qt).  The other private key is held by the vault chain itself, encrypted until its conditions are satisfied. These are the rules you created at the beginning, and once logged in the vault chain they are buried by consensus blocks and forever granted primacy so no one can supersede or overwrite your instructions.  

When you go to spend your coins, your private key is only the first half of the spend equation. The coins go into limbo in the vault chain as a spend attempt is registered. They must wait there until your X delay is over.  If the destination of the coins changes with another spend attempt then the waiting time reset and overwrite the first attempt.  Once the timer is up and enough confirmation blocks have been created, the Vault chain decrypts the other necessary private key and immediately creates a transaction to spend in the bitcoin blockchain.  A receiving address would see zero activity until this process is completed, so this is not a way to chargeback or revoke payment, only delay the spending of the coins on your end for security purposes.  Once actually sent in the bitcoin blockchain, the transaction is irreversible.  

Since the keys are split up and one of them isn't even on my computer, there is no point in trying to hack my password.
Since the vault-chain is trust-less and decentralized and requires consensus in order to spend the transaction, there is no point in trying to run a rogue client with its own rules that attempts to ignore the delays.  

Try to spend my coins and I'd know about it right away, and I can stop you. I'd fail-safe them right into a paper wallet. Think about that for a second. Imagine being alerted that your coins are being stolen before they're gone for good, and imagine being able to do something about it!

And how is it all supported? With tiny extra transaction fees for those that want the security. There are blocks to be found, transaction attempts to be logged, bitcoins to be earned, and miners to be paid. ASIC miners can contribute to both chains simultaneously, and their power would continue to find blocks in each chain and secure both of these networks.

What I'm imagining requires quite a bit of creative thinking to implement properly, but it results in rules that are very hard to circumvent and a hot wallet with very hard to steal bitcoins. I want to give people the power to put a delayed-fuse on their coins. All of these changes would be user-initiated, optional, and would require zero changes to the bitcoin protocol itself.  A Vault wallet is simply software, no extra hardware or paper required. Please poke holes in this idea, I'd love to heard your feedback.  (I am also aware of Oracles, but they are not quite trust-less enough in my opinion)

I am willing to add a 5BTC bounty to this idea if it can be successfully implemented and a Core-Dev confirms it performs as described.