Topic: theft protection by introducing "safe" accounts - page 2. (Read 2301 times)

I doubt it will be done soon. It's a big change and its usefulness will be limited by the advent of multi-signature transactions, which can be used for much better security than the current standards.

The main reason for most hacks we hear about is either malice or negligence, not lack of technical means.

Perfect, this would be sufficient for me. Any plans to introduce this?
... I am sure the community would love this and trust more services that claim to have introduced this mechanism.

Something like this was discussed, and the bottom line is that in principle this can work, if you replace "aborted" with "redirected to a predetermined address". The predetermined address could be for example where the coins came from, or maybe something with EC math, etc. .

Let's say the safe address A is associated with a fallback address B. A transaction spending from A is only considered confirmed after 144 blocks. If there are not yet 144 blocks, and there is a transaction double-spending this with B (but no other address) as the target, it takes priority over the previous transaction.

So you could keep A in a cold wallet and B in a frozen wallet which is essentially never used. If you need to spend the coins from A you'll have to wait a day; but if someone steals your key and tries to spend the coins, you have a day to notice this and broadcast a transaction that overrides it and redirects the coin to the still secure address B.

1. ok

2. ... so what ? it is better to make bitcoins worthless than to give it to the hacker ... they will be worthless if the dispute is not resolved. by sending them back to the previous owners at least the community will profit ... also, imagine, this is a 'forex' exchange ... there would be ways to negotiate with the original owners terms of returning the coins.

3. ok

4. ?

1)  You can already attempt to do this.  Your suggestion does not make this work any better.

2)  No one would take any transaction from an account that could be disputed making those coins worthless if this system was instituted. 

3) The way bitcoin works, this would not be possible.

1. one can try to trace the bitcoin client that executes the unauthorized transactions
2. as a way to resolve the dispute ... all transactions to the disputed account could be reversed

[3. one could assign to the safe address pools of preferred IP addresses prior to the theft]
[4. one could assign an additional address[/signature] that is needed for resolving the dispute ... the service owner would have to make sure it is stored in a different place ... this could be the (central or independent) authority ... but the address owner has the a priori choice "whom" to choose]

This can not work.   If the intruder has control over the wallet, the abort signal would only bring it back to the same wallet that the original owner and the intruder both have the keys to.  Then it is just a race.   

Any plan like this involves a central authority to control what happens in a dispute and therefore goes against the spirit of bitcoin. 

It seems like a common threat to many BTC based services that intruders obtain access to a wallet and send the available bitcoins to a new address they control.

One way to protect the wallet against it would be to assign to the address (all in fact) in the wallet a restriction that all transaction initiated from this address require a (let's say) 1 day confirmation delay, within which the transaction can be reverted by the originating address. The whole network would of course need to accept this additional requirement assigned to the address and reject transactions with the transferred bitcoins if they have been executed too early. The requirement assigned to the account by the account owner would be not reversible (alternatively it would be reversible after the delay period).

Instead of assigning the additional requirement one could just select a set of addresses for which this requirement always holds ... for example all addresses starting with 111... (it would be the obligation of the service administrator to use only these for BTC transacitons). These addresses would be regarded as "safer/slower" addresses.

This mechanism would enable a service provider to scan all transactions originating from his addresses for unauthorized ones and would give him an option to stop the service if unauthorized transactions are detected and reclaim the temporarily lost bitcoins.

Was something like this already discussed (maybe planned) ?