Self destruct/send coins after X failed pass attempts

[pereira4]

The idea is that if someone is constantly failing to enter the correct password to unlock the wallet, the funds would move to an address of choice (which cannot be changed unless you own the password). Another option would be to self destruct the wallet.dat. The point is to avoid people to stop trying to bruteforce the thing. The problem is how to even go about this since someone could just use another client which doesn't have this feature assuming it got added in a Core update. It would at least IMO protect against non sophisticated attackers.

[1714833465]

1714833465

[pooya87]

it is both pointless and harmful to the regular users. a lot of them will end up breaking the thing themselves by entering their passwords with typos! besides if someone is trying to brute force your password through the client, there is a much easier way to prevent them from succeeding: 1. use a stronger password than "123", 2. add a simple fail_counter to add a delay like 30 seconds each 3 times they fail!
otherwise those who actually brute force a password, don't use the  client, they open the file itself and you can't do anything about that.

[gmaxwell]

What you're asking for exactly isn't possible because an attacker could isolate the computer or just use different software.

What would be possible is if the decryption required the help of a third party.   For example, it would be technically possible to construct a scheme where you have two pieces of data and a password,  and a third party has a public/private key.    To decrypt your data you need both the data and the password, plus the assistance of the third party.  And the protocol could be setup so that if you provide the correct password the third party learns nothing about your data or the password, but if you provide an incorrect password, the third party learns only the second piece of data.

Then what you want could work (the second piece of data could be a txn sweeping your funds).  However, the reliance on the third party means that if he got hit by a bus your funds would be lost. The other disadvantage of this idea is that a protocol to do it securely would be very complex and errors in its design or implementation might break your security.

[PrimeNumber7]

The idea is that if someone is constantly failing to enter the correct password to unlock the wallet,<>. Another option would be to self destruct the wallet.dat. The point is to avoid people to stop trying to bruteforce the thing. <>

I think the OP is describing something similar to what happens to an iPhone when someone tries to enter the password incorrectly too many times. It is also a feature on some hardware wallets.

I am not sure about the technical details about how this works. I don’t think this would be possible on a 'per-file' basis, and would need to be a done on a 'entire device' basis. Otherwise someone could just make a copy of the file and try to bruteforce the password with the copy.

[PrimeNumber7]

On second though, it might be applicable on non-jailbreaked with Touch ID/passcode (to enable encryption) iOS devices, even though it could be broke with NAND mirroring attack

It is rumored this is how the FBI was able to hack into an iPhone 5c in 2016, although it is unclear if this is the case. I believe it was said at the time that newer versions of the iPhone were not vulnerable to the specific exploit used in the 2016 case.

It has been claimed that "security" companies can unlock newer iPhone models running the latest version of the iPhone OS. I don’t think there is strong evidence to support this being true.

Based on my reading, a NAND mirroring attack will slow down any attempts to brute force a password to about 45 seconds per 10 password attempts. Although this would not entirely stop a brute force attack, it would make it less appealing if you are not sure of the value of the coin. With an 8 digit numerical PIN, it would take about 17 months to brute force at this rate, and the attacker would need to have continuous access to the device, giving the owner of the device to realize the device is compromised and move the coin with backups.

[gmaxwell]

The idea is that if someone is constantly failing to enter the correct password to unlock the wallet.

Yep, this could also be accomplished with specialized hardware but the security would be limited by the physical security of the device... which is historically kind of dubious.... esp because there is a tradeoff with device robustness.

E.g. if you build a device that self destructs on tamper maybe it also self destructs if you drop it.

[pereira4]

it is both pointless and harmful to the regular users. a lot of them will end up breaking the thing themselves by entering their passwords with typos! besides if someone is trying to brute force your password through the client, there is a much easier way to prevent them from succeeding: 1. use a stronger password than "123", 2. add a simple fail_counter to add a delay like 30 seconds each 3 times they fail!
otherwise those who actually brute force a password, don't use the  client, they open the file itself and you can't do anything about that.

If you were forced at gunpoint to deliver a password, it would be useful to have an alternative that isn't either take a possible beating/end up dead or either hand your hard earned money to said attacker. Right now with wallet.dat we don't have either a way to self destruct or a way to open an alternative empty wallet, or something like that. So I guess people is relying on FDE with hidden volumes? But that has been proven to be demonstrable that the drive contains hidden data. I was wondering if with a contained file like wallet.dat you could hide hidden data. I think Truecrypt volumes are safe when it comes to hidden data but not FDE and you must open the file anyway. I think plausible denniability methods of protection for wallet.dat is worth exploring.

If you have a proper backup setup then entering the password incorrectly by mistake shouldn't be a problem.