Topic: Gold collapsing. Bitcoin UP. - page 610. (Read 2032266 times)

i find this fascinating.  so you're saying that even with a perfect RNG, which is software based afaik, unless it has an excellent source of randomness (such as mouse movement, static off embedded chips, etc) it won't generate truly random privkeys?

how does Armory then create secure deterministic wallets then?  how would one generate the required entropy from the old offline pc's used to install such a program?  the usual method is to just install Armory and go right to wallet creation.

The problem is that human thoughts and actions are invariably patterned, not random.  Even when someone attempts to be random, they often revert back to patterned thoughts and actions.  RNGs are unfortunately programmed by humans and therefore subject to possibly being patterned in some way.  For large sums of money, it is still advisable to use multiple sources of objective external entropy such as die rolls combined with mouse movements.

Or you can just use dark wallet (also somewhat experimental though).

The RIGHT way to do it would be Stealth Addresses.
This way you can publish a permanent address and it is not tracked to the address in the block chain by anyone except its owner, and the addresses in the block chain is not reused, preventing a Johoe grab.
It solves both problems simultaneously, but the address bigger (so the QR takes smaller squares, etc).

Monero does it automatically from the start, with all transactions, it is not really possible to NOT use a stealth address, all wallets use them. 
In Bitcoin, it is sort of possible to do stealth addresses, but it is not user friendly at all, and so it is considered experimental.

Here is how:
http://sx.dyne.org/stealth.html

HD wallets reuse addresses when people send multiple payments to them. I think that is a weakness. Isn't there another bitcoin payment for where this is not possible, like multisig?

What does multisig have to do with address reuse?

If you create a HD wallet that ONLY creates multisig transactions, would that prevent addresses from being reused?

It seems like there is a market for a device which will generate 256 bits of entropy once and save it forever.

256 bits of entropy should be enough to last a lifetime (except if any of it gets compromised).

Exactly, to make this method secure you'd have to randomly select 75.29379857239479209348238048023740720340% of the way to 2^256, which is the same as just banging out 256 bits of entropy on your keyboard (which may not even be that random depending on how you type, dice would be much better)


The issue with HD wallet seed key generation is even though it happens once, EVERYTHING rests on having true entropy during it's generation, especially for a wallet that may live for decades (which many HD wallets will). However at the same time generating HD seeds or private keys can be done when a machine and wallet software first start when there is the LEAST amount of entropy in a given machine.

For example lets assume someone decides to use a Ubuntu 14.4 VM image pre-configured to run bitcoind automatically. That person starts the VM, logs into a ssh shell, and then issues a bitcoind command to create a new wallet. This a logical user flow, but it also means the system has very little entropy. In this case everything about the system configuration is known ahead of time (it is a pre-configured VM image with known virtual hardware) and the user inputted a minimal amount of new information to capture (even the bitcoind command is known and can be easily guessed). About the only random information the user adds is their personal id/pw, but those might be quite weak because the user figures they are running on a secure home network. In this situation that machine has very little true entropy to use in private key or HD wallet generation. At the same time that key might have a lifetime of decades, during which an attacker can try combinations.

That is why it is important that the random number generator captures as much entropy from as many sources as possible. However most rnd functions do not do so by default and the cryptographically secure methods can vary from OS, i.e. a developer has to find the right function calls for linux, windows, etc.

This is why some people roll dice to generate the seed key for their core wallets, since it is the only way to be absolutely sure. I am positive that right now there probably are several individuals trying combinations on known (to them) weak setups trying to guess HD seeds or private keys.

I picked up a bunch of these hexadecimal dice back when they were still being made.
They were a hit at the Bitcoin conventions and meetups.
Still have some even.

Not necessarily. Generation of private keys is a rare event, especially with HD wallets. You need a k value for each tranasction.


Nothing, although that's sort like of a brain wallet, and subject to the same flaws. If someone searches through the list of clever but simple methods of picking a key, they will find yours.

what is somewhat circular for me is that, for a given computer, if you have a problem generating enough entropy for RNG for k values, then you probably have an equally hard problem generating enough entropy for privkeys, as i assume their source of entropy is equivalent.  therefore the HMAC of the message + privkey is also insecure.

btw, perhaps someone can clarify for me.  the privkey is simply a random number btwn 1 and 2²⁵⁶.  what's to stop me from self declaring that i will pick the number 75% of the way to 2²⁵⁶ as my privkey?  the chances of a pure RNG generating that same # is infinitesimal.  therefore, it should be safe.

it is certainly a trend.  Trezor has it implemented.

Was not aware of RFC6979, thank you for sharing. Has any wallet software started to move in this direction or implemented this approach?

It seems this will work well for an existing HD wallet, where no new private keys need to be generated. However most wallet software needs to be able to create new wallets and still require the ability to generate cryptographically random numbers in order to create new private keys or a new HD seed. So the problem of wallet software requiring true random numbers still exists.

It could even be argued that RFC6979 might make wallet developers less aware on how to obtain true random numbers since RFC6979 "fixed" the problem, and as a result generate weak HD seeds. I remember for Armory there was a discussion last summer that resulted in more entropy being added to HD seed generation, I am sure most wallet software is not as paranoid and could still be weak here even with RFC6979. Weak HD seed generation is much more of an issue than moderately weak k value generation IMHO.

BTW, Not sure if the need for RFC6979 in general is more of a statement on how hard it is to produce true random numbers, or if this is more of a statement on the state of software engineering today.

It isn't quite as clear cut as all that though. Here in the UK we have QE, too. The BOE bought government bonds, GILTS, and basically own the market and allows ZIRP to continue happily. Last time I checked they owned more than a third of the entire British national debt. The bonds owned by the BOE are paid an annual interest payment (coupon) by the UK government. It is simply handed straight back. The bonds will be held until they expire. Apart from the initial emission via the deficit in the form of inflation the newly created debt has no effect in the long term to the balance sheet of the UK. It is illusory.

It is similar in the US. It is total banana republic stuff and I expect there will be a tipping point where there may be a sudden flight from a Western currency, say when a certain % (50?) of national debt is owned by the central bank. But this can be gamed and obfuscated for a long time. Other central banks can print money out of thin air and use it to buy different nations bonds, or even buy stocks lol.

Central banks crossed a line in 2008. They now control all markets. They have dislocated the markets in such a way that it is impossible to measure the true value of any stock or commodity or even gold.

Bitcoin is necessary as it cannot be inflated outwith its algorithmic schedule.

At least Japan and Germany are not as bad as the US over the past couple of years. With QE3 the US printed $85b/m for $1.02T/year, that's trillion. The US's deficit was less than a trillion recently (although not by much), so the FED was not just monetizing 100% of the deficit but also buying down additional outstanding debt as well. I'd like to believe it can't get any uglier than that, but I'm sure they'll find a way to surprise me.

Edit: This is also why the FED has over a trillion in mortgage debt on it's balance sheet, and not only government debt as it should only have. Because the FED was printing more than 100% of the deficit, there wan't enough US gov debt to buy, so the FED had to resort to buying non-US gov assets as well. This is outright printing no matter how they try to spin it.

Yes, though if merely issuing 256 transactions, one of which being validated would be enough, then getting the order right for each TX would be gravy.

Is that necessarily true? If they were numerically sequential, it might be. But since they all "look" random,  then it seems a predictive table would be quite handy.  

germany should know better

With only 256 possible RNs, predicting them would be hardly even necessary.