Address revocation

[gim]

Let's say the FSF's bitcoin private key has just been compromised.
Current funds available at this address will probably be stolen, but that's not the problem discussed here.

Of course FSF will change wallet and public address... but donations to the old public address will keep on.
(Some people have stored the old address in their Address Book, some others will find the old FSF address on bitcoin wiki, etc...)
So, the FSF would also like to revoke their old public address, because they don't wan't to play the "who will spend new credits first" game with the thieves.

The problem is that there is no revocation procedure available in Bitcoin.
Do you think such a feature would be useful?

---
"Half-baked" implementation proposal:
A special revocation transaction containing public keys (and signed with associated private keys) that can be included in a block. Miners understand those transactions and are forced to reject any following transaction that could be unlocked by those keypairs. (Note: this work only for standard tx)

[1715409256]

1715409256

[1715409256]

1715409256

[1715409256]

1715409256

[Stephen Gornick]

(Note: this work only for standard tx)

Right, so I spend to that "revoked" address using an ewallet provider and the coins don't come back to me.

Better to just understand that addresses are not permanent, and when spending to always request the payment address when creating each payment.

[gim]

Right, so I spend to that "revoked" address using an ewallet provider and the coins don't come back to me.

E-wallet providers should check that transactions are validated anyway. So, I'm sure they can bear with that.
(For now, everything is "standard" on the real network)

[davux]

Maybe address revocation could be a special type of transaction, so that it's visible in the blockchain and clients have a mean to check if an address is valid or not when creating a new transaction or relaying an existing one.

[BCEmporium]

Halt!

Too dangerous! That's rubbish, thief claims can be as scams as robberies themselves. Currencies aren't personal data.
If your wallet got compromised it was mostly yourown fault; greedy miners installing "mining boosters", users installing close-source god-knows-what applications.
And if there will be no more than 21m btc, if a wallet gets revoked with 1m in it, roughly 5% of the btc economy vanishes forever.

[Stephen Gornick]

if a wallet gets revoked with 1m in it,

I think the intent was that a stolen wallet could no longer receive payments and I didn't see anything from the OP that had anything to do with keeping previously received funds in a stolen wallet from being spent.

But I agree with your argument that this revocation concept is not really necessary nor desirable (and likely to not work anyway since it only takes one miner to miss or ignore the revocation request and the transaction gets included in a block regardless.)

[patvarilly]

if a wallet gets revoked with 1m in it,

I think the intent was that a stolen wallet could no longer receive payments and I didn't see anything from the OP that had anything to do with keeping previously received funds in a stolen wallet from being spent.

But I agree with your argument that this revocation concept is not really necessary nor desirable (and likely to not work anyway since it only takes one miner to miss or ignore the revocation request and the transaction gets included in a block regardless.)

Not if the revocation request is a transaction that is itself written on the block chain.  A miner can only create new blocks if it knows the hash of the block emitted <~10 min ago, so presumably they have full access to all active revocation transactions.  A miner can honor a revocation request by simply not including transaction with an output to the revoked address.

Ultimately, you'd want miners to reject blocks that have transactions to revoked addresses in them, but you'd have to roll out such a change carefully.  If too few miners change their acceptance rules, then they shoot themselves in the foot by refusing to add their blocks on to the longest chain.  But once >50% of the miners have changed their acceptance rules, then the remaining miners have a very strong incentive to comply (otherwise, blocks that they output including transaction to revoked addresses will wither and die).  So you would need a transition period, during which miners will accept blocks with the old acceptance rules and only issue blocks with the new acceptance rules, and that they agree to start rejecting blocks that don't comply with the new acceptance rules after chain length, say, "currentChainLength + 10000".  That would be an interesting test of the rule that whatever >50% of the bitcoin mining power says goes, goes.

[gim]

Thanks patvarilly, you wrote my answer down for me

[giszmo]

interesting thoughts. definitely worth implementing.

noob question: when/how am i able to spend again coins that fail to get confirmations for a prior transaction? the client immediately charges my balance. is "double-spending" supported in the standard client?

[spetey]

Sorry to revive the old thread, but I'd like to bump this issue back up. (I got directed to this thread googling "revoke bitcoin address", worried about the same thing.) If the software can handle it reasonably - I wouldn't know - it seems wise to be able to revoke addresses. The widely-published donation address that's been compromised is an excellent example, and the objections listed here are not compelling.

It's bad enough that some percentage of the fixed supply of bitcoin will constantly disappear due to lost keys - but still worse if coins keep dropping into such black holes. And assuming that the coming crowd of bitcoin holders will be a tad less savvy about password maintenance than early adopters, this issue will be all the more important.

[kjj]

The payment protocol in the works will take care of some of this.

Addresses themselves can't be revoked.  We could do it, but only at a terrible cost.  I will leave the consequences to your imagination.

[CIYAM]

Another possible approach would be to effectively have a "message" tx that is not mined but is broadcast and any client that picks up the tx and sees that it has previously *sent* a tx to the address in question could display a warning message (or mark the address as *bad* or similar).

[ISAWHIM]

There is no "acceptable" solution for "raw bitcoin transactions".

Revoking is not the "issue" of the "bitcoin network", just as "reversal" is not the "issue" of the bitcoin network.

The "bitcoin network" is a "Method of transferring bitcoin funds from a source to a destination".

If you want "security", beyond "the method of transferring...", you should be using a "Service" which adds "securities you are looking for", on-top of the back-bone of the "bitcoin network".

Just as your ISP is not responsible for "delivering you security", it is there just to "deliver". What you "add to the network" is irrelevant to the delivery-agent. You want safety while using a computer on your ISP, you ADD a firewall, you ADD SSL, you ADD filters, you ADD backup services...

Bitcoin is the same thing.

If you have your wallet stolen, it is YOUR responsibility to see that YOUR SENDERS are not sending to a "hard coded" address. That is your own fault if you tell your customers to use a hard-coded address. It is your customers fault, if they are using a hard-coded address to send to. It is neither the responsibility of the network (us), or the program, to manage your fraud-resolution, theft, or abuse.

There are multiple ways to use bitcoins, with the securities you are asking for, that already exist. Use them... Stop using "RAW BITCOIN TRANSACTIONS", if you are not going to provide the security YOU require, YOURSELF.

The short solution is to have two wallets. One to receive funds, and one that your funds are constantly "moved to" after having been received. The "hand-out" addresses for the wallet should ALL BE UNIQUE per customer, per transaction. Thus, they will NOT BE TEMPTED TO SAVE THE ADDRESSES. (Which you should CLEARLY warn them of, prior to sending.)

Your recipient wallet should be retired every year. (Keeping it "just in case", a transaction comes in.) When you then create a new wallet, with a new passphrase, with new records.

For ultimate security, use an exchange service as your "second wallet", as your transferred bitcoins get instantly turned into "system-credits", for use in the exchanges. Plus, they can be moved from account to account, without "building onto the bitcoin network", adding useless block-transactions to the growing blocks. You can even get-rid of your own wallet, since you can transfer INTO the account from any bitcoin source, and transfer coins out, to any bitcoin source.

Why complicate such a simple thing?