So I did a little informal study of this on IRC with a little test page, and it was basically impossible convince people that their personal information wasn't being "connected" to their account in some way.  (and to some extent it is: someone who had their credentials recovered would have a harder time denying them).   This is least recovers from the saltlessness problem, though it leaves the door open for targeted attacks against passwords which are almost never strong enough... but I can't figure out how to get the user past the "personal information" problem.

Well, that was intentional. I might be corrected, but I don't think Gavin has ever considered the feature particularly important. He isn't opposed to it, and its supported by other core developers but Gavin has been pretty insistent on someone doing a robust test plan for it (and I agree)— which no one has ever done.

Most of the discussion on it has been on bitcoin-development, ... there has been hundreds of messages on it. The complexity is generally self contained. As I mentioned above, I don't personally care _that_ much about it, but I don't think it's problematic in the slightest.

Taking some time to describe all the things you'd normally do with coin control, what you expect the outcome to be, and then walking through them on testnet, and documenting the result and reporting any weirdness would help increase confidence that we could safely merge it.  The concern is that some bad outcome like "I selected less coins than my send value... and it sent all my coin to dev null!" happens for some rare mixture of behaviors. It's good that lots of people have been using it, but usually when someone documents what they're doing it will make some of the less tested interactions more obvious.

uhh. You're aware that the reference client is an open source project, right? The Bitcoin foundation is a organization primarily oriented in promoting Bitcoin on behalf of businesses and professionals, who are super eager for the payment protocol stuff.  The foundation doesn't control what goes into the reference client, and if it did that would be a pretty concerning event.

No one who has any interest in coin control spent any time on the payment protocol as far as I know. So is this your real motivation, you're out to attack features you don't care about in a misguided effort to boost the ones you do? As an aside, I do see that you appear to have contributed nothing to coin control, including any testing reports or help with test plans. Throwing mud at other features will do nothing to get the feature you want in, but stepping up to help out with testing absolutely will.

Pretty trivially when almost everyone is on a SPV node because a full node requires gigabits of network connectivity, and when everyone who isn't would have to accept the invalid blocks or otherwise be left behind by the economic supermajority of people who are.   (this is all in some fantasy world where Bitcoin is widely used enough for a seriously funded attack, right?)

If you think this is interesting, your mind is going to be blown when you start looking a bit deeper.

You shouldn't be surprised most of the altcoins are just copies with bitcoin with only very very minor changes.

A bunch of people use the same keys on multiple bitcoin clone chains.  E.g. Petertodd's ltc bounty payment stuff was setup that way.

No you didn't.

This sounds like someone who is trying to move leveldb files between architectures.

I think thats silly, unenforceable, and doesn't actually change anything in any case.  A payment protocol payment can communicate as little as a pay to address can. ... and if you want to hypothesize about required communications, you could just as well assume that only transactions containing certain data would be legal,  which would be a lot more enforceable if in the future mining is like it is today: controlled by a hand full of super large mining entities.

You do realize that all this mining stuff has nothing to do with processing transactions, and that instead of running Bitcoin nodes that can process transactions practically all of these miners are just getting paid by pools to do outsourced sha256 calculations, and they never see transactions or even the blockchain at all, and as a result don't contribute much to improving Bitcoin's security— ... and that we're even in a worst state than we were a year ago,  now kidnapping or hacking _two_ people is enough to freely perform transaction reversals...

You realize this, right?

Yup, exactly.

Maybe. I mean, if the key was "password" then okay sure.  But if you threw three cpu months at it and the key was found as the product of some increasingly powerful analysis that you performed, some product of you and the victim being on a similar mental wavelength... it may reasonably be the case the the only people in the world who know the key are you and the victim.  But you don't know that.

Rather than stressing about it then, I suggest anyone considering doing this think ahead.

Besides, do you go around jiggling the neighbors doors and trying their windows? Why not? How is this different— beyond the possibility of getting caught being substantially reduced?

Because the game has a player you can user an interactive protocol. There is no need for a trusted device.

The house discloses a commitment for their seed, e.g. H(seed),  the user picks a random value and tells the house. The game uses H(seed||user random) as the CSPRNG start for the game.

How do you actually know that it is running the open source firmware and not a modified version installed by the manufacturer or replaced in transit?

Generally if your computing device is compromised you're kind of doomed, but in this case not so much... because the behavior of the device is sufficiently narrow and all communication mediated via the host, it should be possible to be a little more confident here.


My expectation is that you'd make your master key  some H(device randomness || user or initial host randomness).  You need a way to export the master key data for backup purposes, so with an addition that also lets the user obtain the contributing randomness after obtaining the device master key.  Effectively this means the the device cannot undetectable cheat in the way you suggest.

(now, any particular user may fail to detect it— but it changes the risk model for someone substituting the firmware, since after already committing itself to some behavior and signing transactions on behalf of the user the user could then demand it provide the device randomness and they could fully repeat the output)

Perhaps deterministic signatures could be a user configurable option, allowing expert users to "pick their poison".
[/quote]I prefer fewer options to more... but indeed.

There is a lot of additional documentation for BIP32 in addition to the BIP itself:

For example, http://www.youtube.com/watch?v=WcnMjkc31Fs

I'm disappointed that this is the first time I've heard your complaints.  It has now been independently implemented by at least four parties.  Your feedback sounds good though, do you have any proposed revised text? (And indeed, your understanding is correct).

The motivation there is that the ECC homomorphism based public derivation has that highly surprising backwards enumeration property.  In some use-cases it could easily cause a total loss.  E.g. I export a private key from my wallet and give it to you, and you already have the extended key for that chain for auditing... oops now you have all the coins on that chain.

The text on that is a bit weaker because we added it later... we'd hoped for a while that there would be a way to remove that property but couldn't find one.  The auditing behavior still exists, but works only in publicly derived chains.

Some client software may choose to only use public derivation, thus facilitating auditing. If they do they should probably avoid offering key export function for single private keys, simply because it has turned out to be really hard to educate users about the exposure.

Please don't crap up the utxo set keeping around more of these junk outputs.

When you redeem these things, send them to an OP_RETURN txout with a value of 0.  This will convert the output into fees and prevent a new output from being created in the txout set.

oh... if were true ...

But it's not.  The assumption that it is already true is probably a major reason that it isn't: a catch 22.

People have been very loudly told not to do this and many people don't— sadly, many other people smugly think they are smart enough to do it safely (I would even bet that most posters in this thread are among them). People have been stolen from, those who needed that to learn already learned— many others just blame the victims "Oh, I wouldn't use a key that stupid", ... yes, yes you would.

In any case, you misunderstand my advice there.  I wasn't making that suggestion for the benefit of the victims— they're already doomed through their ignorance and actions.  I was making that suggestion for the benefit of Sothh. There is no good team here.  Once you embark down this path you potentially find keys and have to choose between becoming a thief yourself or sitting passively while some other thief takes the coin. If you don't want to find yourself in that situation, for sake of your own personal ethics, then you shouldn't be trying— you should instead work on educating people to behave more safely... and compromising bad coins appears to be ineffective, due to the aforementioned victim blaming.

They exist because of brainwallet.org. Amusingly, the site's creator started down his path much as you have, but then decided that "password derived" keys were useful so he setup a website.

Humans are unconditionally a terrible source of entropy. Many people using keys they sincerely believed were secure have been robbed. Often complicated "schemes", and even common password advice produce worse passwords instead of better ones.  This baddness is multiplied by the face that using JS tools make the performance of reasonable KDFs unacceptable and because the application prevents the use of effective salting, so the attacker gets an enormous simultaneous attack multiplier.

But there is really nothing that can be done except to keep telling people: Do Not Use Human Derived "entropy" for private keys.

It may be worth pointing out to you that a prudent person doesn't try doing this:  What happens if you find a key with 1000 BTC and can't determine the owner?  Your choice will be to rob them yourself or to leave it be and hope they move the coin before someone else robs them. If you don't want to potentially be in that situation you shouldn't be attempting to crack other people's ignorantly produced keys.

Those estimates are usually worthless.

The encryption in bitcoin-qt's wallet uses powerful strengthening— on your own system it won't be able to test more than 10 attempts per second... even with a powerful GPU farm things will be limited.

(as compared to BC.i wallets, for example, which has gpu cracking tools that do millions of attempts per second)

That isn't to say that having a good key is important— it is... but for many people the strengthening is enough that the bigger risk is losing/forgetting the keys.

You have my complete agreement there. In the future we should use an updater program (e.g. "gitian updater") which checks the signature for the users, so at least once users have one good copy they should be okay on future ones.