Topic: Reducing the need for cold storage through self-blacklisting (Read 1155 times)

A single transaction would both unblacklist and transfer the coins. Either both happen or neither happens. There would not be any time between the unblacklisting and the transfer so the attacker could not steal your coins by running a script like you described.





This is the most serious criticism I think. If all unblacklisting triggers a notification, then there could easily be too much noise and the theft goes unnoticed. It may be necessary for the 3rd-party service to analyze the transactions to look for suspicious ones. For example, you could set it up to only notify you if more than X BTC is unblacklisted in a 24-hour period. A clever attacker might be able to steal a bit at a time, but you'd probably prevent him from stealing everything. This is about the same as the current hot/cold wallet approach. A hacker who just steals a bit out of your hot wallet may go unnoticed for a while and be able to steal a bit, but eventually you will notice and he won't have been able to steal everything.





I guess it remains to be seen whether the risk/reward of my suggestion is better than this alternative. I would personally opt for cold storage rather than your suggestion. Locking down a computer system is very hard and it isn't a one-time affair. It requires on-going maintenance. I suspect that the cost of taking coins in/out of cold storage would be lower than the cost of sufficiently securing a system like the one you described.




Thanks everyone for the feedback.

An alternative to your suggestion (which needs protocol level changes and is only useful to very few people) would be to have a very locked down system running an application which implements your requirements. Only your application is accessible over the network.

You could configure a lock-down time in the application and your "main" web application could send transaction requests to the system. When the system receives a transaction request the transaction would be executed after n (2) days you get notified (by e-mail?) and can interfere before that happens.
The key here is of course to have the system locked down as much as possible as it will have programmatic access to the private keys with your funds. Blocking all incoming ports and denying all incoming and outgoing traffic except that for your application  (possibly on a hardware firewall and on your system) and making your application secure enough shouldn't be that much of a challenge.
You could optionally run bitcoind on the system however that's a fairly complex bit of software performs many operations which could go wrong so it's probably better to not do that and to broadcast the signed transactions to the network in some other way (your outside application could poll it and then insert it into the network when it's appropiate).

Your locked down application therefore would need the following API functionality available over network:
- Create Transaction
- Cancel Transaction (you probably want to be able to do that over network)
- Poll created transactions

yeah no one issue with this is

"to instantly unblacklist all the coins, transfer all the coins"

the attacker just has a script ruining all the time trying to transfer your coins, as soon as you "un blacklist" he transfer, your left with nothing.

All you have done is made your coins useless to you.

I am going to restate what I think you want as an addition to transaction scripts.

This is a transaction output (scriptPubKey) that can be spent (used by a transaction input) in one of two ways with different keys for each way.  One key could be used in an input (scriptSig) immediately as we normally expect, this key would be held in cold storage.  The other key would require a special transaction be committed to the blockchain some number of blocks ago before it would be accepted (unblock transaction).  This special earlier transaction could be signed by the same key used in the later transaction.  In this case blacklisting is just a particular transaction output (scriptPubKey).

This could be done by adding an script op that would check for the special transaction already committed to the blockchain, or possibly require a certain special input in the spending transaction.  Both are predicated on information outside scriptSig and scriptPubKey unlike all existing ops.

The waiting period is not an insignificant impediment.  Other parties would have to wait the full unblacklist time before they could trust anything you send them.

I think this is plausible but I question if this is better than alternative options to protect against theft.

For this to be effective some system must be online monitoring the unblacklist transaction.  This system should differentiate between good and bad unblacklisting.  If the attacker compromised the private keys could they compromise the monitoring system?  If its a 3rd party service you still have to communicate the good unblacklisting likely requiring some authentication that could be compromised with the key.  Anything like passwords protecting access to the monitoring system could also just be used to protect the keys.

If the monitoring system doesn't differentiate between good and bad and notifies you about everything, wouldn't it be better to queue up the pending transactions and approve all the transactions periodically on some secure system like a trezor, offline computer or a 3rd party service.

I'm by no means an expert on bitcoin, so I don't know how practical this would be to implement, but this sounds like a really good idea to me.

The point is that unless you are hacked, you won't need to bother with getting a key out of cold storage. The X day waiting period could be preferable to some people than the need to get coins out of cold storage on a regular basis. For example, offline storage always requires human involvement. With the scheme I have suggested, as long as you can wait X days before spending the bitcoin, the whole process can be automated.

If you are going to automate bitcoin transactions, you need to keep a private key on an Internet-accessible computer. There is no way around that; (please correct me if I'm wrong). Once you put your private key into cold storage, you lose all ability to automate transactions.

By having 2 private keys, you can keep one online and the other in cold storage. The self-invoked penalty gives you some time to respond in the case of a compromise of your online private key.

In short, my proposal doesn't eliminate the need for cold storage. However, it does reduce the frequency with which you need to access the cold storage.


Please tell me what the "other problems" with my proposal are. I'm not so naive to think that I'll have gotten this right on my first try (or at all).

Disregarding all other problems with your proposal, you're just passing the buck to your "secondary" private key.

If you're so careful with your "secondary" private key, then why wouldn't you just be that careful with your "primary" private key? Why play it so loose at all?

Why would you wait out some arbitrary self-invoked penalty on your business transactions when you can sign them with your offline super secure "secondary" key and broadcast them immediately?

In other words, this sounds like indirection that leads right back to the same fatal crux you started with: securing a private key.

I had an idea today, and I wanted some feedback on it.

Today, best practice for a business (or individual) holding significant amounts of bitcoin is cold storage. I.e. no private keys online. I'd like to know if anyone agrees that the scheme below might be an alternative that is more convenient without sacrificing any significant security.


First, the protocol/miners would need to be updated to support what I'm calling a self-blacklist. This isn't a trust-based blacklist where clients need a list of blacklisted coins from some trusted authorities. Instead, anyone with an address's private key could blacklist some or all of the coins held by that address. When blacklisting coins, you would set the amount of time it will take before the coins are unblacklisted, for example, 7 days. While the coins are blacklisted, no miner would accept any transaction involving those coins. At some later date, the address's private key can then be used to unblacklist the coins. However, there will be a delay (7 days in the example above) before the unblacklisting will take effect.

Just doing the above doesn't really provide any value other than delaying an attacker. However, each address would get a 2nd private key. This 2nd private key would be able to transfer and instantly unblacklist the coins. The 2nd private key would not be required for any transactions involving coins not blacklisted. The 2nd private key would always be kept in cold storage (or paper storage) unless there were a compromise.

Here is what I imagine might be a typical scenario:

• I blacklist all the coins that today I would have kept in cold storage. The private key is available online. This allows me to programatically access this coins as I run my business.
• I set my blacklist time to be 2 days because I watch my systems closely. I think I can respond to any attempt to unblacklist and steal my coins within that period of time. If I had to make a big payment, it would be delayed by 2 days, but it could still be done programatically. If I didn't watch this business very closely, I might set it to 30 or 60 days so I'd have a lot more time to investigate in the case of an attack.
• I keep my 2nd private key in cold storage with all the precautions used today for cold storage (redundant, secure, etc.).
• My server is compromised. The attacker steals everything in my "hot wallet," which isn't much. He then steals my private key for the blacklisted coins and unblacklists them. This starts my 2-day count down before the coins are actually unblacklisted.
• I have previously set up an independent system to watch for when my coins are unblacklisted. I get an email alert.
• I immediately re-blacklist the coins, probably with a longer blacklist time, such as 30-90 days or possibly indefinitely.
• I investigate why the coins were unblacklisted.
• Once I determine it was a hacker, I set up a new address and use my "2nd private key" (which I have taken out of cold storage) to instantly unblacklist all the coins, transfer all the coins to the new wallet, and reblacklist all the coins (again with a 2-day count down). These three things would all happen within a single transaction so there is no opportunity for the attacker to steal the coins between when I instantly unblacklist them and when they are moved to the new address.
• I fix the security breach. Then my service is back up-and-running.

I'm not seeing any flaws in the plan? Please tell me where I am wrong.