Implementing a system for revoking compromised Bitcoin addresses

[Blazr]

Recently Bitstamp had a large number of Bitcoin addresses compromised. These addresses were used by their clients to make deposits, and many clients had been reusing these addresses.

I have been thinking that maybe it might be a good idea to implement a system for revoking a compromised Bitcoin address.

The idea would be that once a Bitcoin address is compromised, the owner would broadcast a signed message revoking the address. Whenever someone tries to send funds to this address, a message would appear in their client letting them know the address has been revoked by the owner and ask them to confirm if they would still like to send the funds.

A revoked Bitcoin address would function as normal, it would still be able to send/receive funds, however clients would display a message indicating it has been revoked whenever someone tries to send funds to it.

This would be useful for many reasons, including revoking poorly generated addresses such ones that have been generated using bugged RNG's or weak brainwallet passphrases and of course hacked wallets.

What do you guys think of this idea? Is this something thats worth looking in to?

[DannyHamilton]

Recently Bitstamp had a large number of Bitcoin addresses compromised. These addresses were used by their clients to make deposits, and many clients had been reusing these addresses.

I have been thinking that maybe it might be a good idea to implement a system for revoking a compromised Bitcoin address.

The idea would be that once a Bitcoin address is compromised, the owner would broadcast a signed message revoking the address. Whenever someone tries to send funds to this address, a message would appear in their client letting them know the address has been revoked by the owner and ask them to confirm if they would still like to send the funds.

A revoked Bitcoin address would function as normal, it would still be able to send/receive funds, however clients would display a message indicating it has been revoked whenever someone tries to send funds to it.

This would be useful for many reasons, including revoking poorly generated addresses such ones that have been generated using bugged RNG's or weak brainwallet passphrases and of course hacked wallets.

What do you guys think of this idea? Is this something thats worth looking in to?

You'll want to take the time to really think through the implementation of your concept.

For example,  how do you plan to handle it if a malicious user decides to generate addresses as fast as they can and send out "revoke" messages for every address that they generate.  Won't this quickly flood the network with peers relaying "revoke" messages, and won't it quickly eat up all the disk space on every full node as the fill their databases with addresses that have never been used and will never be used?

[p2pbucks]

I just thinking to create a 2-2 multisig deposit address ( users and platform ) with nlocktime to let users & platform can revoke their transactions within a certain amount of time . Users keep their privkey locally . If the platform privkey is compromised , then they still have time to revoke the transactions .
Is that feasible ?

[DannyHamilton]

I just thinking to create a 2-2 multisig deposit address ( users and platform ) with nlocktime to let users & platform can revoke their transactions within a certain amount of time . Users keep their privkey locally . If the platform privkey is compromised , then they still have time to revoke the transactions .
Is that feasible ?

No.

Peers (and miners) currently do not store transactions with a nlocktime.  Therefore, it would be up to the sender (or receiver) to hold on to the transaction until after the nlocktime expired and transmit the transaction then.

Meanwhile, if the private key is compromised, then the attacker can create and send their own transaction without needing access to the nlocktime transaction.  Therefore, it doesn't provide any additional security at all.

[coinits]

Eliminate exchanges and eliminate the problem.

[Blazr]

Yes, DoS is something I have thought about and I'm not sure of the best way to prevent this because ideally you should be able to revoke unused addresses.

One solution is we could stuff a revoke message into a transaction. The transaction does not necessarily have to spend/send coins to the revoked address or even move coins at all. The fee/KB system we currently have to prevent tx spam will mitigate DoS. This does have the downside of needing to have some coins to spend in order to revoke your addresses, but it would probably be the easiest way to implement something like this as it would not require any changes to the Bitcoin protocol, only the clients.

Eliminate exchanges and eliminate the problem.

Don't forget blockchain.info's recent RNG issue. There are many valid reasons for such a system. What if your wallet is hacked and you are expecting a large payment to one of your addresses very soon, such a system could quickly halt any future payments.

[Sukrim]

As it would be purely informal anyways, it would be enough to publish (signed) "revoke" messages somewhere. Website, DHT, Bitmessage... then your client(s) could check for messages that relate to their addresses via bloom filters (so no wallets get leaked), verify and display them.

I'm not sure that this really would need to go into the mainline client, having a sort of protocol for it would be nice though.

[dabura667]

Without an efficient way of looking up "revoked" addresses, it will end up in nodes being required to store a "revoked address database" similar to the utxo database.

Seeing as, unlike utxos, revoked addresses would never go away... this has the possibility to grow immensely.

There would need to be a high incentive to NOT revoke addresses unless absolutely necessary. For instance, the minimum fees required for a transaction with a revoking output is decided by the number of revoking outputs in the previous blocks.

If 0 revokes in the last 100 blocks, then there is no special requirement. (besides normal transaction fees)

As number of revoking outs in the last 100 blocks approaches 100 (one per block) is rises slowly from a few bits all the way up to 5 * normal tx fee... then after that it just shoots up a ton.



But then of course, the best way to discourage it (aka, if it's something that must be so ferociously discouraged) is to not implement it at all.

[Sukrim]

All in all it is just an informational annotation to an address, probably signed by the private key that belongs to it as proof. You don't need to store this decentralized, this could be a centalized service for convenience too.