I might be able to, if your billion fold hardening was the addition operator or if you were calculating the 'billion fold' vs a memcpy, then I absolutely could (and of course the amount of 'salt' is irrelevant in such a statement). But that was never my contention.

My contention was instead that a system that attempted to work this way would be insecure _in practice_ due to human factors, and/or weaknesses in the strengthening system (which is not provably strong— e.g. it could actually by like my 'addition' example, and so it becomes an large additional assumption).


You can't win this sub-argument.  People forget passwords all the time— what if you get sick or hit on the head and lose a few chunks of your memory?  And you could remember an electrum seed sequence and make your memory your only backup if you want, at lest if you're the kind of person who would have any hope of remembering a secure password otherwise.

The difference there being the failure mode: Assuming the user would do something poorly, it's more secure if he leaves his backups carelessly laying around than if he uses a low entropy password (like "e352e8bceb", "8W3G7Pds9712++", or "7XiBKeJe5ochSqVW") that someone could simply bruteforce.   Sloppy backups, or especially sloppy backups plus a weak password, is simply more secure than a weak password.

And what if he emails it to himself? He can still be protected by passphrase. How is that less secure then any seed information not existing at all?   Even if you assume that he might use a somewhat weaker pass-phrase due to the existence of the stored entropy an attacker would still have to compromise his email account. Do you really think the false-confidence-induced entropy loss is going to be more harm than have-to-also-find-and-crack-his-email is a gain?

I'm responding mostly out of mathmatical interest and because I'd gone through the trouble of writing this post before I saw that you'd persisted in your yelling.


They aren't randomly distributed, people like to #@$@ on some dates more than others resulting in more births on some days than others.

The FCC ham radio callsign database is the only thing I have handy with a lot of birth dates in it.. With 723624 entries, it is a pretty good sample.


But the actual entropy is greater than I expected: 8.513275 bits,  8.510952 dropping the leap-day.

But this doesn't matter— say you get your 14.58 bits of DOB salt (the entropy from the FCC database for the full DOB), then an attacker going after only a million users simultaneously still enjoys a 40x speedup over a scalar attacker.

If they are chosen randomly. Which almost always they won't be if you allow the user to do it.

40 bit searches aren't that hard either— I did a bigger search that 40 bits to find the signature at the bottom of this post.  You can argue that your strengthening makes that impossible but the security of strengthening is pretty squishy.  


Preventing accidental collision just hides the actual insecurity of the system. If there was any risk of accidental collision then the risk of compromise by a savvy attacker with a good probability model is much greater.


If you don't let the user choose, you have what I suggested in my original post except without enough entropy.  The scheme electrum  uses only 12 words taken from a dictionary that uses words which are distinct and easily memorable and provides 128 bits of entropy.

If you offer the [generate new] you lose at least log2(average clicks) of entropy from the clicking, but probably more because users will just click until they hit a password with usually low markov entropy, e.g. they'll self-select insecure sequences because those ones are more memorable and it's exactly that process the attacker will model.

If the dictionary is well chosen you can have acceptable machine generated seeds which users can reasonably memorize without compromising on entropy.


Please, stop conflating 'deterministic' with shit-in-your-memory. They are not the same. A wallet which was based on a cryptographic PRNG with two megabytes of starting state would absolutely be deterministic but could never be memorized.  (also— please don't yell, it's not polite)

If you add the qualification, "while in the hands of a large collection of actual users", which of course is the goal of anyone writing software worth discussing here,  then it absolutely is true, at least if you're going to insist that purely random electrum seeds aren't easy to memorize.

(I think the memorability of electrum seeds is debatable. The kind of user who might have a fighting chance of using a pure password scheme securely will have no trouble memorizing an electrum seed. Joe-blow not so much. The difference here is that in a password only scheme joe-blow— who happens to work at mtgox— would get owned, lose 100,000 of other people's bitcoins and send our reputation into the trash,  while in the electrum/armory like scheme he'd take the require 30 seconds to make a backup and everything would stay secure)

That isn't "salt" by anyone's definition,  it's additional structured very low entropy passphrase material— which might do enough to keep the horrible insecurity of the system from casually being discovered (much in the same way as the debian breakage of openssl still leaving the PID as a source of randomness preventing that flaw from being discovered for years) but it wouldn't actually make the system acceptably secure.

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.


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.


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.
 

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.

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)

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.

You can't tell if a txn involves you in the checkmultisig case, either, fwiw.   If clients start tracking and showing users every transaction that mentions an address they have people will just start spamming the network with 2-of-3's where one of the users is a random person.

But more significantly, thats not the case where this P2SH matters most— P2SH style transactions have two most important qualities— they move the storage from output scripts, which are more expensive to store, to input scripts which are less expensive because they are always prunable,  and they allow a recipient of funds to specify their own payment rules in a compact address (and take the fee burden related to complicated payout rules themselves).   This means I can have a multi-agent trust for my organization or a multi-device escrow for my own wallet without having to burden everyone that sends me funds.

Absolutely.

I'm not superkeen on the weird salt string. We really don't need any more mystic Satoshi worship around here. Just make it something boring like "pbkdf2minikey".

The iteration count function should also not allow stupidly small values 2^((n>>2)+13) would be more reasonable.  This should speed up generation for most sane cases, as it will avoid values tuning up to be too weak to be usable.

OMG! is that why it's called Diablo miner???


Indeed, I probably had two dozen "oh heck yea, this breaks it! ... oh wait" moments while learning about it, reading the papers, reading the source, etc. I had the good sense, however, to not go all high and mighty on the forums until I had at least half a clue.  Listen before you speak is reasonable standard of behavior, and it's not wrong to hold people to it via an occasional bit of mockery when it results in a mock-worthy event.
FWIW, it's also good to point out testnet.  The OP claimed hesitance in attacking bitcoin proper: Thats a good thing, since it's a system many people use. But we have testnet mode specifically for this purpose.  You can test on testnet without fear of upsetting/hurting anyone and without losing much of value if you end up burning coins.   Bitcoin can be started in testnet mode with the -testnet parameter.

I believe in current code the upper bound on the fee with default settings is 0.05 BTC— above that the transaction would have to be bigger then the client is willing to generate. (it would take a great number of ins/outs to hit that but I'm not sure how many— but since it depends on inputs too it's hard to give you a simple function)

I'm fairly doubtful that code is going to get released— he was looking for investors, presumably to fund a private farm with that design. So unless you're planning on duplicating the work yourself (with substantial effort since he appeared to be carefully non-specific about the solutions to the problems he's encountered) don't be counting on running anything based on a three ring design anytime soon.

No.
The parent post is borderline-gibberish that betrays fundamental misunderstandings of Bitcoin on several levels.
Yes, using editing tools you can make your wallet display crazy stuff. No, the crazy stuff has no influence on the outside world.  No, it's not a "security issue"— if you don't want your software displaying crazy stuff don't use recovery tools to twiddle with the non-user-serviceable parts. It's actually unlikely that the crazy values can will actually cause the loss of bitcoin, but not impossible (e.g. if you delete the private keys).
Any negative numbers are meaningless in the context of the whole system Bitcoin tracks coins (transactions) not balances, and it certainly doesn't track bitcoind _account_ balanaces which are a purely local book-keeping function.
As far as the rest goes— Yes, you can remove coins from Bitcoin forever but you don't need his elaborate series of steps. Just send coins to a wallet which has no backups and destroy the wallet data and the coins are lost.  Yippie! more scarcity for everyone else.

Interesting, but how do you plan on reconciling the hyperspatial hash-cascades, especially in the face of multiphasic avalanche? I would expect the Kullback-Leibler divergence in any such system would tend to infinity. The result would indubitably carry a non-trivial risk of oedipal collision with the motherbase-prime and, accordingly, an attacker employing Pollard's less popular kangaroo vis-à-vis your euclidean multi-metric could identify vari-wallet Nash-distinguishers against the lineage in constant time (assuming a tradeoff with a very modest log n quantum pre-computation step and n-th Ackermann order storage), certainly no one here needs any explanation as to why this would be a terrible outcome.

I recently read of a system described in an IEEE journal which could potentially be profitably incorporated into a mining system for such a multigenerational token architecture as you describe which might address some of these challenges, or alternatively, applied by an attacker in order to achieve negative time compromises. If combined with a retroencabulator, the potential for cross-chain synergy would be unprecedented.

Perhaps you should consider it.

I don't think I even heard about it for several days later, are you sure about that?

And what I posted about wasn't even the attack that actually happened. Though I'd love to take credit realizing that lots of inputs would gum up the wallet, which is so obvious in retrospect,  what I was pointing out was that the fees were out of wack.  Moreover, I was interested in finding out if it was easier to influence chain fee policy in a chain which was mostly solomined (as ltc was at the time).    At the time the attack irritated me as much as anyone else— it screwed up my mining psychology experiment by providing a non-selfish motivation for changing the fee schedule.

Here is the thread for anyone interested https://bitcointalk.org/index.php?topic=51915.0.  I don't think I ever saw any of the posts in it after the first until just now. I knew about the attacks from IRC (and from seeing my own blockchain copies grow).

Unlikely Luke I don't think Litecoin is a scam. It may be ultimately pointless, as Art convinced me when I suggested scrypt POW in #bitcoin-dev a long time before litecoin— the cpu pow really means that only criminals can mine it profitably (perhaps ultimately a fate for Bitcoin too), and the increased block rate makes it actually 4x less lite than bitcoin when you have a pruning node.  But I've never had anything against worse than those reservations against it, and have defended it against people trying to spread "dark pool fud" here.

Well you came in blablah about coiledcoin, it was trolling as far as I could tell.   I'm not very active in #eligius but luke wasn't around at the time.   I got a talking to as a result of that kick— he's a lot more tolerant of casual trolling than I am, and I wasn't aware that he'd been hanging out in your channel.  Sorry about that.

I had nothing to do with the litecoin dustspam attack, except for potentially forseeing part of it as a consequence of the anti-dos rules being unchanged from bitcoin and totally out of wack with the low currency value and fast chain speed (though the fact that the attacker would send to pre-existing addresses in order to slow down wallets wasn't even something I'd guessed would happen), and I posted patches to correct it ahead of the attack.

I'd appreciate it if you edited your message to retract this claim, as well as any other places where you've made it.

Thanks.

Because the sync disk IO is important to avoid losing database updates or corrupting the database when the power goes out during a write—  which matters a lot for the wallet but not everything else.  However, it currently uses the same database setup (though different files) for all things.

So an update on this— After having some people test the RC builds on lower performing windows boxes (e.g. random spinning disk systems with only 1GB ram) they're still seeing 18 hour syncs, so at least on those systems this particular doesn't make as big of a difference as it does on fast/linux/ssd system.   I'm still working on finding additional improvements for all systems.

If you'd like to benchmark it on your own system(s), you should add logtimestamps=1  to your bitcoin.conf so your debug.log file will get a timestamp for every entry. Then you can start it up and check later to see how long it took (this is how I generated the graphs used on this page).

There are RC builds with this fix (as well as some of the recent deadlock fixes), made by Matt Corallo <matt@bluematt.me> using the reproducible build process:
http://dl.dropbox.com/u/29653426/bitcoin-0.5.2rc1.tar.bz2
http://dl.dropbox.com/u/29653426/bitcoin-0.5.2rc1-win32.tar.bz2

(though, er, personally I wouldn't run binaries from dropbox urls, except for the fact that I knew Matt posted them)

If you do try out the RC builds please let me know (either here, in #bitcoin-dev on irc, or in PM) as getting a few more people trying them out is the only thing delaying their official release right now. Always make sure to backup your wallet before trying new software (and periodically even if you're on old software!).

It was probably okay, sendmany's look weird in the transaction history (they look like multiple transactions).

Thanks for supporting p2pool!

It's nice to see the forum being abused for referral spam.