📅 Original date posted:2013-03-25
📝 Original message:On Fri, Feb 22, 2013 at 11:08:51PM +0000, I wrote:
> What would be really nice is for bitcoin to have a big key compromise
> button, which would automatically transfer all coins to newly
> generated addresses (optionally with a pause between generation and
> transaction - to allow for a new wallet backup). Optionally, too, the
> compromised/retired addresses could be marked with a flag such that if
> someone sends coins to that address bitcoind immediately generates a
> transaction to transfer the coins to address(es) which are good.
On Mon, Feb 25, 2013 at 09:23:53AM -0800, Andrew Poelstra wrote:
> The problem with automatic transactions would be: by repeatedly sending
> money to an address and seeing if it always moves quickly, an attacker
> can identify (a) that an address is in use, (b) which public key it has
> (if this isn't already public), and (c) that the key is believed to be
> compromised.
I realise on reflection that what I really want is not automatic
transmissions, but a means to revoke an address.
The problem is that after transfering the coins from the compromised
addresses to a new, hopefully safe address, what to do about the fact
that third parties might still try to send me coins to an old,
compromised address. So what I think I'm suggesting is that there
should be an address revocation protocol, such that clients will give
an error if their user tries to send coins to a revoked address.
Unless we think that direct payments to addresses will become
completely obsolete once the payment protocol is in use, in which case
(maybe) this functionality belongs in the payment protocol instead -
but I remain unconvinced of that.
I'm not envisaging something as drastic as changing the rules to make
transactions to revoked addresses invalid - just an overlay protocol.
Although to be useful such a protocol would have to be pretty much
universally implemented by clients.
Thoughts?
roy
Roy Badami [ARCHIVE] /
npub1tr…0f95j
2023-06-07 11:42:04
in reply to nevent1q…kmht
Author Public Key
npub1trckpcxmceskq4cykxgwxm63n8ugrjrpu5mk83c90e4upsf7d9gqf0f95jPublished at
2023-06-07 11:42:04Event JSON
{
"id": "2e5439a9df70de53cc7ad7003b59227e948c258e1c617be847fad39f20c564a6",
"pubkey": "58f160e0dbc661605704b190e36f5199f881c861e53763c7057e6bc0c13e6950",
"created_at": 1686138124,
"kind": 1,
"tags": [
[
"e",
"a732e61ef0ab8164631a174daac45de6d7397ab14bcc79ffbd930a7fa0d7a581",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2013-03-25\n📝 Original message:On Fri, Feb 22, 2013 at 11:08:51PM +0000, I wrote:\n\n\u003e What would be really nice is for bitcoin to have a big key compromise\n\u003e button, which would automatically transfer all coins to newly\n\u003e generated addresses (optionally with a pause between generation and\n\u003e transaction - to allow for a new wallet backup). Optionally, too, the\n\u003e compromised/retired addresses could be marked with a flag such that if\n\u003e someone sends coins to that address bitcoind immediately generates a\n\u003e transaction to transfer the coins to address(es) which are good.\n\nOn Mon, Feb 25, 2013 at 09:23:53AM -0800, Andrew Poelstra wrote:\n\n\u003e The problem with automatic transactions would be: by repeatedly sending\n\u003e money to an address and seeing if it always moves quickly, an attacker\n\u003e can identify (a) that an address is in use, (b) which public key it has\n\u003e (if this isn't already public), and (c) that the key is believed to be\n\u003e compromised.\n\nI realise on reflection that what I really want is not automatic\ntransmissions, but a means to revoke an address.\n\nThe problem is that after transfering the coins from the compromised\naddresses to a new, hopefully safe address, what to do about the fact\nthat third parties might still try to send me coins to an old,\ncompromised address. So what I think I'm suggesting is that there\nshould be an address revocation protocol, such that clients will give\nan error if their user tries to send coins to a revoked address.\n\nUnless we think that direct payments to addresses will become\ncompletely obsolete once the payment protocol is in use, in which case\n(maybe) this functionality belongs in the payment protocol instead -\nbut I remain unconvinced of that.\n\nI'm not envisaging something as drastic as changing the rules to make\ntransactions to revoked addresses invalid - just an overlay protocol.\nAlthough to be useful such a protocol would have to be pretty much\nuniversally implemented by clients.\n\nThoughts?\n\nroy",
"sig": "7b76ca019280fff8a94a0872183da5cc5a4b9f0d1b2e4e241d8ad6bff151c221ece8ea736d2e5b9f547b74fbbc1484680691397cf81e40a129a6a065ef38bb65"
}