theft protection by introducing "safe" accounts

[tytus]

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) ?

[1715690751]

1715690751

[1715690751]

1715690751

[1715690751]

1715690751

[Littleshop]

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. 

[tytus]

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]

[Littleshop]

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]

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.

[tytus]

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. ?

[Meni Rosenfeld]

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.

[tytus]

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.

[Meni Rosenfeld]

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.

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.

[tytus]

Can You require now that bitcoins in one account require also the signature of another [or 2 signatures] to be sent ?
[this would also help if 2 wallets are needed to send BTC].

[Meni Rosenfeld]

Can You require now that bitcoins in one account require also the signature of another [or 2 signatures] to be sent ?
[this would also help if 2 wallets are needed to send BTC].

Yes, you can have an address that requires signatures from two separate keys. But it's not fully supported in current software.

[tytus]

but they have to be stored in one wallet, right ? ... the required solution is to have two wallets .

Also the option of rolling back transactions has advantage because You detect intrusion attempts. The two keys requirement will most likely prevent the detection if the intrusion (compromise of one key).

[etotheipi]

There's plenty of theft-protection that is already available, and will be available if users are willing to put in the time to use it.  It prevents theft in the first place, rather than recovering from successful theft.

(1) Cold storage (see my sig).  Online threats become nil once you have your private keys offline, then only physical access can compromise the keys
(2) Multi-sig:  all funds can be setup to require 2 or 3 signatures, which can be kept in geographically separate places, or one of the keys can be based on a passphrase. 

With both in place, only the select few that are supposed to have access will be able to use it.  Cold-storage by itself is a 99% fantastic solution that many of these services are not leveraging, either enough, or at all.

[tytus]

There's plenty of theft-protection that is already available, and will be available if users are willing to put in the time to use it.  It prevents theft in the first place, rather than recovering from successful theft.

(1) Cold storage (see my sig).  Online threats become nil once you have your private keys offline, then only physical access can compromise the keys

but the service must be able to do the transaction automatically.

(2) Multi-sig:  all funds can be setup to require 2 or 3 signatures, which can be kept in geographically separate places, or one of the keys can be based on a passphrase. 

With both in place, only the select few that are supposed to have access will be able to use it.  Cold-storage by itself is a 99% fantastic solution that many of these services are not leveraging, either enough, or at all.

It is a sufficient solution for me if I need 2 separate computers that do NOT communicate with each other to confirm / initiate the transaction. But if the transaction is conducted in one place by inserting two keys in one wallet, or by confirming the transaction with a passphares ... this is not safe enough.

I don't really care if most of the thefts occur due to ignorance of the service provider. A popular service (like mtgox) is probably the target of many intrusion attempts and after some time people will break in.

... in any case I will read more about the dual signatures ...

[etotheipi]

There's plenty of theft-protection that is already available, and will be available if users are willing to put in the time to use it.  It prevents theft in the first place, rather than recovering from successful theft.

(1) Cold storage (see my sig).  Online threats become nil once you have your private keys offline, then only physical access can compromise the keys

but the service must be able to do the transaction automatically.

Most online services will need some degree of automatic transactions, but that usually accounts for only a fraction of the total holdings of that company.  Probably 90% of their funds can and should be kept in cold storage.  Transferred manually when needed.

Additionally, the business owner can keep the keys in a safe-deposit box or even at home.  If the "hot wallet" is running low, he can manually refill it from cold storage when he goes home for the night.

[tytus]

This concept is clear and this are basic safety elements of a service. Still imagine a single person that has the single key to most mtgox bitcoins. if he goes nuts the whole network will loose faith in the system. Also building larger, more reliable project will be problematic if all funds can just disappear due to a "malfunction" of one individual. This will not happen in real world as there, transactions can be reverted. In the current bitcoin network it is not the case and any claim that a service is reliable is exaggerated due to human errors.

If we want to make the system more reliable we have to introduce additional safety. Having the option to require 3 signatures from 3 (out of 3+x) people to confirm a transaction enables me to setup a system where a single person will not take off with substantial amount of other peoples money. If there is one administrator, he can have an accident and forget the passphrase :-) ... it is pointless of course to give more examples ... You know all this. But to be able to build something like a bitcoin bank that can not just evaporate due to a glitch the network needs to provide mechanisms that give at least the option to add safety.

- fallback account is great ... provides tools to identify malicious attempts and tools to defend it
- independent multiparty sign off of transactions needed for special accounts is also some solution that I could live with

Of course one can try to decentralize large services like forex exchanges but it is difficult to decentralize the interfaces between bitcoin and the real world unless we convince banks to accept interactions with the bitcoin network.

[DeathAndTaxes]

You seem to have difficulty reading what other people are writing.

multi-sig IS part of the Bitcoin protocol the implementation is CURRENTLY (as in today but not forever) incomplete.  The current (incomplete) implementation requires both keys in multi-sig tx to be in the same wallet.  In the future that won't be required.

Still even multi-sig doesn't remove the need for cold storage.  Even real world banks use the concept of cold storage.  A bank which has $1,000,000 on hand doesn't have $100,000 sitting in the teller's drawer.  Given that in any reasonable amount of time a teller's cash needs a less each teller only has access to a small fraction of the banks total cash holdings.

[etotheipi]

This concept is clear and this are basic safety elements of a service. Still imagine a single person that has the single key to most mtgox bitcoins. if he goes nuts the whole network will loose faith in the system. Also building larger, more reliable project will be problematic if all funds can just disappear due to a "malfunction" of one individual. This will not happen in real world as there, transactions can be reverted. In the current bitcoin network it is not the case and any claim that a service is reliable is exaggerated due to human errors.

If we want to make the system more reliable we have to introduce additional safety. Having the option to require 3 signatures from 3 (out of 3+x) people to confirm a transaction enables me to setup a system where a single person will not take off with substantial amount of other peoples money. If there is one administrator, he can have an accident and forget the passphrase :-) ... it is pointless of course to give more examples ... You know all this. But to be able to build something like a bitcoin bank that can not just evaporate due to a glitch the network needs to provide mechanisms that give at least the option to add safety.

- fallback account is great ... provides tools to identify malicious attempts and tools to defend it
- independent multiparty sign off of transactions needed for special accounts is also some solution that I could live with

Of course one can try to decentralize large services like forex exchanges but it is difficult to decentralize the interfaces between bitcoin and the real world unless we convince banks to accept interactions with the bitcoin network.

We're in agreement.  I'm just making sure you understand what tools exist, currently, for avoiding theft (as is the title of this thread).  If I was managing a multi-million dollar cashflow, you'd be using combinations of things.

3 people, in different place, with three different offline wallets.  Need 2-of-3 or 3-of-3 signatures to unlock any funds.  And as D&T pointed out, this is part of the network already, it's just not entirely accessible yet.  However, Armory provides a fairly convenient cold storage capability, and it won't be long before someone (Armory, too?) will get some useful multi-sig interfaces.  Then these kinds of ideas can actually thrive.

And many business owners still won't use them and will still lose people's money.  But we can't force it on them... we can only offer them the right tools...

[tytus]

Cool, than I only need to wait for the completion of the introduction if these measures. I believe it would be good not to delay this too much.

In the era of upcoming ASICs many bitcoin miners may switch to an alternative currency. One of the fields of competitions between currencies can be their safety. The safety is probably an important concern for the small shops that accept bitcoins. They must use other services to convert the bitcoins to the currency they pay with. These shops have not too many resources to maintain safety but these shops are responsible for the valuation of bitcoins against other currencies. investment in safety will pay off :-)

[Insu Dra]

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.

I kinda like the idea of a slow address, but the reverting is a big nono. I would just permanently mark a address as a slow address, when a transaction is started it is broad-casted to the network and accepted but not confirmed as a transfer till 24 hours have passed, In that 24 hour there is a cancel option for both sender and receiver, if one of them cancels the transaction does not get confirmed.

People dealing with incoming transactions from such a address can see it has been instantiated but don't get conformation so they know they can't count on it being a valid payment till the 24 hours have passed. People owning such a address have 24 hours to notice btc was moved without there permission and to cancel that transaction. Even if the thieve has the same cancel power after obtaining a wallet it ends up in a game where the most persistent person wins and at the very least it dramatically decreases the appeal to steal such wallets. To me this seems like a valid and good way to add a extra layer of protection on personal saving addresses and/or any cold storage.

As for hot wallets on servers, it's less useful for those; as said we need multi sig to be completed asap.

[tytus]

I was thinking about the problem instead of reading :-( but if I remember correctly the bitcoin network offers much more flexibility in designing and handling transactions than in handling accounts. Thus I wonder if a different solution would be possible with current implementation:

Instead of keeping the bitcoins in an account I keep it in a TRANSACTION.

The transaction is set up in a way that it goes from my hot storage account to a fallback account but let's say 3 CONTROL-accounts, defined a priori in the transaction, have the power to modify the transaction within a predefined period [1 day] from the initiation of the transaction or the last modification. Any of the 3 CONTROL-accounts have also the power to drop the controlling power for all CONTROL-accounts simultaneously.

The service will use the 3 CONTROL-accounts to extend the transaction forever wiring back to the hot storage account some bitcoins from time to time [it can be also defined that this is the only possible modification of the transaction].

Would something like this work ?