wallet destruction

[bracek]

If i was a bad guy, and saw that it is almost impossible to steal bitcoin,
I would try to destroy other people's bitcoin

by erasing wallets or uninstalling or whatever.

There will be some people that will not make backups of their wallets.

question is :
are those encrypted wallets too big to be written into a block chain ?
Someone attacked would know approximately when he created his wallet
or would have some other reference
to restore that wallet.

Customized tool would scoop wallets in chosen period of time,
and try user provided password on those wallets...
since sending will require 2 passwords soon, coins would not be stolen,
but wallets could be restored

and maybe wallets could be written into namecoins block chain,
since there is merged mining, to let namecoin return the favor...

Or is it possible to store in block chain only some kind of "seed" of a wallet
to reduce storage size ?

[1714796507]

1714796507

[1714796507]

1714796507

[MysteryMiner]

Copy the wallet.dat to yourself, steal coins available and then erase original wallet.dat from target machine for lulz. Or copy the wallet.dat file, wait when lamer recieves more coins in the wallet and then steal the coins. Some users will send more coins to compromised wallet even after the coins are stolen

[DeathAndTaxes]

Or is it possible to store in block chain only some kind of "seed" of a wallet
to reduce storage size ?

Just use a deterministic wallet.  If you have the passphrase you can rebuild the wallet.  Period.

What could be better than that.  Anything stored in block chain "seed" or not would obviously need to be encrypted thus you still need a passphrase.

Not sure what storing an encrypted wallet in the blockchain would gain you over simply using a wallet where your passphrase IS your wallet.

[bracek]

Just use a deterministic wallet. 

tell it to my grandma

Anything stored in block chain "seed" or not would obviously need to be encrypted thus you still need a passphrase.

Not sure what storing an encrypted wallet in the blockchain would gain you over simply using a wallet where your passphrase IS your wallet.

It would allow people to act irresponsible (as usual), without being punished for it.

Most of the people is mentally stuck in 7th grade, basically kids with mustache or boobs...
they often do not have due attention

[bracek]

Copy the wallet.dat to yourself, steal coins available and then erase original wallet.dat from target machine for lulz. Or copy the wallet.dat file, wait when lamer recieves more coins in the wallet and then steal the coins. Some users will send more coins to compromised wallet even after the coins are stolen

on install, encrypted one is created (with 2 factor authentication)
only one of those passwords will be used to recover the wallet from the blockchain
other password would enable spending

and this is protection from destruction, not from (both) passwords being sniffied

[kjj]

If i was a bad guy, and saw that it is almost impossible to steal bitcoin,
I would try to destroy other people's bitcoin

by erasing wallets or uninstalling or whatever.

There will be some people that will not make backups of their wallets.

No one will lose a wallet without a backup twice.

And my hat is off to anyone that can find my long term storage wallet burned to several M*Disc DVDs and erase them all.

[gmaxwell]

If i was a bad guy, and saw that it is almost impossible to steal bitcoin,
I would try to destroy other people's bitcoin

You should sit down and do the math — the value to you in destroy other people's bitcoin is very small unless you happen to own most of the bitcoin, far less value than stealing it.  In fact the attacker is best off living that potential victim alone, because his bitcoins will be worth more if people are not afraid to use bitcoin due to the attacks.


Attempts to destroy your bitcoin can also be foiled with a simple offline backup— a $2 usb key or two is cheap insurance. You're a fool if you don't have an offline backup because dataloss happens even when there are no attackers.

'Backing up' to the blockchain is a horrific idea. It would provide no security (what is the point of 'secret' data which is known to everyone) over just using the password alone— and using a password alone is itself a terrible idea because people are bad at producing strong passwords even when they are trying, it would burden the bitcoin network and prematurely degrade our decenteralization.

[bracek]

No one will lose a wallet without a backup twice.

I am just saying that someone could lose it once

that would bring bad publicity, slower adoption...
uncomfortable and risky use turns people away

[bracek]

You should sit down and do the math — the value to you in destroy other people's bitcoin is very small unless you happen to own most of the bitcoin, far less value than stealing it.  In fact the attacker is best off living that potential victim alone, because his bitcoins will be worth more if people are not afraid to use bitcoin due to the attacks.

and if motivation is political or psychotic ?
simply to destroy or disrupt

Attempts to destroy your bitcoin can also be foiled with a simple offline backup— a $2 usb key or two is cheap insurance. You're a fool if you don't have an offline backup because dataloss happens even when there are no attackers.

'Backing up' to the blockchain is a horrific idea. It would provide no security (what is the point of 'secret' data which is known to everyone) over just using the password alone— and using a password alone is itself a terrible idea because people are bad at producing strong passwords even when they are trying, it would burden the bitcoin network and prematurely degrade our decenteralization.

I suggest writing it somewhere automatically,
block chain is a suggestion because it is always there, unlike USB stick

in near future 2 passwords will be required to send/steal coins
so if there is encrypted wallet online, it could be brute forced once,
but that would not be enough, if it requires confirmation via SMS or some other method to send coins

thief could find all wallets and look at balances, but not steal
if they require additional confirmation

[DeathAndTaxes]

Just use a deterministic wallet.

tell it to my grandma

I would a deterministic wallet is even EASIER to use than one that requires backups (automatic or not).

Anything stored in block chain "seed" or not would obviously need to be encrypted thus you still need a passphrase.
Not sure what storing an encrypted wallet in the blockchain would gain you over simply using a wallet where your passphrase IS your wallet.

It would allow people to act irresponsible (as usual), without being punished for it.

Most of the people is mentally stuck in 7th grade, basically kids with mustache or boobs...
they often do not have due attention

You still haven't explained why one is easier than the other:

ENCRYPTED WALLET
1. You create wallet.
2. You backup wallet
3. If wallet is lost you need to use passphrase AND redownload wallet (which may be difficult or confusing for user)

I would also point out if user's passphrase is weak having them in the block chain allows attacks remotely.  The user's machine doesn't need to be compromised an attack can simply brute force all backed up wallets hoping for a hit.

DETERMINISTIC WALLET
1. To create a wallet you ... enter a passphrase.
2. To access wallet you ... enter same passphrase.
3. To restore a corrupted/deleted/stolen wallet you ... enter same passphrase.

So I will ask again what exactly does backing up an encrypted wallet into block chain accomplish that a deterministic wallet doesn't?

[vuce]

I really hope the official client will also have the option of creating a deterministic wallet one day...

[etotheipi]

I really hope the official client will also have the option of creating a deterministic wallet one day...

Doesn't sound like the devs want to go that direction yet, though I have seen Gavin mention that it's the right direction to go.... eventually...

For now, you can simply wait for Armory, which should be officially released (alpha) next week.  It not only has deterministic wallets, but paper backup print option (see the screenshot on the thread).  Digital backups are great and all, but you never know if that USB key sitting in your safe will still work when you plug it in for the first time in a year... paper backups are forever!

[gmaxwell]

I would a deterministic wallet is even EASIER to use than one that requires backups (automatic or not).

You should take care to not describe a deterministic wallet as requiring no backup at all, ever.  I'm completely confident that the official client will _never_ implement a deterministic wallet that has no known-random component. Moreover, you should not use any client which implements such a thing because its developers obviously have a poor grasp on security.

Instead, what you would have is a deterministic wallet with a random component with at least 128 bits of real entropy. Perhaps it can convert it into a special list of words that you can memorize if you really want (e.g. electrum does this) plus whatever pass-phrase you use,  you'd backup this random data _once_.  Then you don't have to back it up anymore.  (it's, in fact, arguably better to actually leave the password out of the generation and only use it to decrypt the stored seed— so that its possible for you to change the password if you worry that someone might have seen you type it in)

[DeathAndTaxes]

I would a deterministic wallet is even EASIER to use than one that requires backups (automatic or not).

You should take care to not describe a deterministic wallet as requiring no backup at all, ever.  I'm completely confident that the official client will _never_ implement a deterministic wallet that has no known-random component. Moreover, you should not use any client which implements such a thing because its developers obviously have a poor grasp on security.

Instead, what you would have is a deterministic wallet with a random component with at least 128 bits of real entropy. Perhaps it can convert it into a special list of words that you can memorize if you really want (e.g. electrum does this) plus whatever pass-phrase you use,  you'd backup this random data _once_.  Then you don't have to back it up anymore.  (it's, in fact, arguably better to actually leave the password out of the generation and only use it to decrypt the stored seed— so that its possible for you to change the password if you worry that someone might have seen you type it in)

Where is your analysis that 128 bits of entropy is required?
Also why is deterministic wallet held to higher standard than an encrypted wallet?
Why doesn't the mainline client then reject any passphrase without 128 bits of entropy.

Since wallet generation is relatively rare event, key hardening function like PBKDF2 can be used with quadrillions of rounds on an Open CL capable machine.  The seed generation function could be very slow taking 2, 5, hell even 30+ minutes since the event is rare unlike a website login which is dealing w/ thousands or millions of logins per day and thus must limit PBKDF2 execution time to a fraction of a second.  A long execution time combined with salt would make a passphrase with even 30 bits of entropy impossible to brute force.

Example of high security deterministic wallet:
passphrase w/ 40 bits of entropy (for example 5 randomly chosen words from dictionary)
SHA-256 key hardening w/ 20 billion rounds.
sequential throughput of wallet generation machine 10 MH/s
hashing power of attacker 1 TH

Wallet generation time: ~30 minutes
Attacker throughput @ 1 TH: a mere 50 passphrases per second (due to need for 20 billions hashes per attempted passphrase)
50% time to break 40 bit entropy passphrase @ 50 pps: 697 years

[etotheipi]

The issue is not breaking the passphrase.  It's that a purely-deterministic wallet without extra entropy will lead to many users, using keys that are identical, and then they'll end up sharing wallets -- which obviously will lead to one person taking the other person's money.  Then you'll have determined people creating wallets based on a common passphrases, and it will be very successful, because they will get to attack ALL such users at once.  They can just keep trying common passphrases until they find one that generates a wallet with money, then keep going.

That would be an utter disaster for Bitcoin.  There must be extra entropy added to ensure that no two users end up with the same deterministic chain of addresses.

[DeathAndTaxes]

The issue is not breaking the passphrase.  It's that a purely-deterministic wallet without extra entropy will lead to many users, using keys that are identical, and then they'll end up sharing wallets -- which obviously will lead to one person taking the other person's money.  Then you'll have determined people creating wallets based on a common passphrases, and it will be very successful, because they will get to attack ALL such users at once.  They can just keep trying common passphrases until they find one that generates a wallet with money, then keep going.

That would be an utter disaster for Bitcoin.  There must be extra entropy added to ensure that no two users end up with the same deterministic chain of addresses.

You are aware that problem was solved roughly 3 decades ago.... SALT

[etotheipi]

So you are memorizing the salt in addition to your passphrase?

You wrote in your post that you don't need a recovery plan for your deterministic wallet, because it's all in your head.  If you've added salt, it's not really in your head. You will need a backup.

[DeathAndTaxes]

So you are memorizing the salt in addition to your passphrase?

You wrote in your post that you don't need a recovery plan for your deterministic wallet, because it's all in your head.  If you've added salt, it's not really in your head. You will need a backup.

Um salt doesn't need to be complex and it doesn't need to be a secret.

What is your birthdate?
What city were you born in?
What is your email address?

Hash those three values and that is your salt.

For wallet recreation simply ask the user those questions again and rehash to re generate the salt.

Unless you think there are enough people who have same birthdate, place of birth, and email address that also happen to use the same passphrase.

On second thought I don't like email address question because it could change.  Just find 3 or 4 highly deterministic questions to generate the salt like father's name, place of birth, etc.

[DeathAndTaxes]

I guess I may need to prove it by making a private key based on key hardened passphrase consisting of 5 dictionary words, provide the salt, and the public address and say if it is so easy to crack my Bitcoins are yours.

[gmaxwell]

Where is your analysis that 128 bits of entropy is required?

128 bits isn't an absolute requirement, it's a comfortable rule of thumb.  You can arrive at basically this number by making conservative estimates about the energy requirements of brute force (e.g. assuming an optimal classical computer, incrementing a counter, requires about 240 million tons of tnt energy equivalent to increment from 0 to 2^128-1, which is clearly secure against whatever threat model or algorithmic speedups you wish to suppose)

This, plus the fact that 128 bits of security is almost always very cheap to have has resulted in the conventional wisdom that cryptosystems with less security than that are snake oil.    You can probably drop a couple bits and wave claims of strengthening at it and pass the smell test, but not much more than that.

The whole bitcoin system was designed to provide at least 128 bits of security for this reason.

Also why is deterministic wallet held to higher standard than an encrypted wallet?  Why doesn't the mainline client then reject any passphrase without 128 bits of entropy.

Because most attackers will not have the encrypted wallet. Your security is passphrase PLUS wallet, which is an enormously higher standard than just passphrase. Belt and suspenders.  And what I'm describing for deterministic wallets is effectively the same:  Something you have (the random seed) and something you know (the passphrase).

Moreover, you can't actually measure entropy. You can make guesses based on assumed source models,  but you don't really know it unless you generated it.  Rejecting passwords by some simplistic model actually reduces entropy.

That combined with salt would make even a 30 bits or 40 bits of entropy impossible to brute force.

Whoa whoa whoa.  Full stop.  Salt?  Where does this 'salt' come from?  If you make the 'salt' at least 128 bits and store it you have _exactly_ what I've described.  And that's a fine thing: so long as there is enough entropy from strongly random sources to make blind attacks infeasible then its all good.  But you still have to record that salt someplace.
(and if you're strengthening you also need to store the strengthening amount, unless you always strengthen to the least common denominator)

It's pretty hard to reason about strengthening, because you can't generally prove that there isn't a way to shortcut it. In fact, if you assume quantum computation you get a minimum speedup of sqrt(n) for any possible strengthening scheme.  Strengthening has practical value and should be used whenever weak passwords might be used, but it's not a replacement for real entropy.
 

Example of high security deterministic wallet:

You're assuming that the passphrase has 40 bits of entropy, this is a fundamental error.  Multiple studies have shown that its basically impossible to get high entropy passphrases from humans, even if you give them excellent advice.  People on this forum have frequently bragged about their oh so secure schemes, which actually provide fairly little entropy.   This isn't because they're bad or stupid, or because they deserved to get robbed— being random is something that humans are just not good at.

(The 30 minutes assumption is insane too— almost all users would choose a less secure alternative over waiting 30 minutes—  but whatever, taking off a factor of 100 isn't what breaks your argument)

Moreover, even if the user is bad and stupid and deserves to get robbed— when they _do_ get robbed the reputation of the whole system is called into question. Responsible security conscious developers build systems which remain secure even in the face of user stupidity— ones which only fail in the face of unstoppable heroic stupidity whos stupidity would be obvious to even the most unsophisticated observers.

Even the most intelligent users will sometimes make boneheaded moves, so even if you're confident that you're better than the typical user— you still should strongly prefer software that isn't gratuitously vulnerable to operator error. Any developer who isn't assuming that their users will make mistakes, will choose passwords with less entropy then they think they have, will leak partial passwords to shoulder surfers, etc. just hasn't studied the problem space hard enough.