OpenSSL is probably not the best tool.  The issue is there is no parameter for "just give me the raw private key and compressed public key in hex format.

Here is the closest I have found


If you need it output to a file you can use a pipe output like
The prior screen output will be redirected to the file.  You are still going to need to do some parsing but it should be cleaner.  One thing to watch for is there is a leading zero 0x00 before the private key (not it is 66 hex values not 64).

Also I was having some issues verifying output using brainwallet.  It wouldn't accept some keys despite being valid (might be a browser issue) and I don't like how it will replace outputs when you click in an attempt to refresh.  I would recommend using bitaddresses.org instead (use the wallet detail tab).

Thanks for confirming that, I was going off of (flawed) memory.  The clocks in modern microcontrollers are better than I remembered.  I did a similar set of test last night (although I had no pluse generator so I used a second microcontroller as a poor man PG).  I got similar results.  I am confident now that if I can keep loop latency under 50 us that means shooting for an average interval period of 500 us is feasible.  That would require  a source & tube combination capable of ~120K cpm, and would give us ~900 bps of filtered entropy.   At 240k cpm might be able to push that up to ~1600 bps.

I have no reason to believe they are flawed (they have been aproved for use by multiple gaming authorities).  Very cool stuff using single photon emitter to produce entropy quantum, however with solutions starting at $1K and being closed source it doesn't fulfill my goals.

Thank you for clarifying I think a decentralized keyserver for those who wish to avoid the counterparty risk of CAs (not necessarily SSL) is a very good idea.

SSL is very adaptable

Hell you could even put a backup of the private key in your wallet (or use it as an address too).

Ideally the calls would be encapsulated using an interface then support for other crypto libraries would be plug and play (well maybe not plug and play but far easier for developers once wrappers were written).  For example I may want to use a smartcard for signing and currently that requires a whole host of ugly refactoring but if there was an interface I could write against I simply swap the openssl wrapper for the smartcard wrapper and compile.

Well the subtleties do matter. X509 CAN support weak signature algorithms but it can also use require only cryptographically strong algorithms as well.


The support for older weaker algorithms is mostly for backwards legacy support, support which isn't needed for a greenfield implementation.  No reason that a particular users (or any user) would need to support weak signature algorithms.  You can also use MD5 to hash PGP messages as well. 

If both can be implemented without CAs, both can support key servers, both can use a node network for DHT storage of public keys and/or certs then ultimately the only advantage of using PGP over SSL would be that it is more secure.  Sorry you haven't shown that PGP would be more secure than self signed SSL certs.    This isn't an academic debate.  It is almost certain that Bitcoin will support SSL in payment protocol so it doesn't come down to PGP vs SSL it comes down to SSL vs SSL + PGP.  Adding another entire dependency just because weak SSL certs might be weak (and strong ones are cryptographically unbreakable) is well not a very strong argument.

I am not a tax attorney or CPA I don't know all the limits and caveats of the foreign currency rules.  I would imagine there probably are some annual caps to the exemption and if there isn't (because most currents are inflationary so you are just jumping from one sinking ship to another one) then I would imagine Congress would put some limits in quick if people are using it to exempt huge sums of wealth.

On edit:
Well you got me curious so I looked it up.  At the current time there doesn't appear to be an annual cap only a limit of $200 gain per transaction.  It is important to note this is an all or nothing exemption.  If the gain is $200.00 (or less) no taxes are due.  If it is $200.01 or more then taxes are due on the entire $200.01 (not just the portion over $200).  Of course an annual cap or limit could be imposed in the future (Congress is good about doing stuff like that).

This shouldn't be considered financial or legal advice, one should always consult with an attorney or accountant for professional advice.

How would Bitcoin support PGP client public keys?  Whatever the solution replace PGP public key with SSL Client cert.  Not saying SSL is better but not seeing how we gain anything by going to PGP.


Ok now we are talking or at least to the heart of the matter.  Do you have a cite or link where X509 would fail that PGP wouldn't?

If you look in the transaction list do you see any tx which are unconfirmed?  If so check another source (blockr.io or blockchain.info) to determine if the tx is indeed unconfirmed.

Allowing unconfirmed transactions to be malleable (one can say don't rely on tx id however the tx id could have been constructed to be immutable from day 0).
Using the use of uncompressed public keys (no advantage over compressed keys and given how critical space in the blockchain is it bloats the resource requirements).
Using 160 bit for PubKeyHash while PubKey only has 128 bit security (to benefit from 160 bit PubKeyHash would require 320 bit ECDA).
Having early coinbase tx payout to pubkeyhash instead of address (just adds needless complexity and now is a legacy cost).

All these vulnerabilities
https://en.bitcoin.it/wiki/Weaknesses#Security_Vulnerabilities_and_bugs

None of this should be an attack against Satoshi, he was brilliant, did what many considered impossible, and solve/prevented entire categories of exploits but he wasn't omnipotent.

That is a valid point although SSL does support client certs.  Bitcoin would be extended to expose that support making it identical to PGP in that respect.


All of that can be done with SSL self signed SSL certs as well.  I guess my point is you seem to be indicating that CA = bad therefore don't use SSL.  SSL can be used in a self signed fashion.  You could have SSL self signed key servers, you could load them into the network DHT style essentially replace public key in your example with SSL cert and the same thing applies.

Same place as all prior versions
https://en.bitcoin.it/wiki/Data_directory

Final on any version of Bitcoin simply distinguished between that and the release candidate.

i.e. 0.9.0 RC1, 0.9.0 RC2, <insert as many Release Candidates as necessary to resolve outstanding issues)>,  0.9.0 Final.

Version 0.9 is final it will never be updated.  Case in point the next release was v0.9.1

It depends on how it is used.   In the US currency gains of less than $200 on transactions involving the purchase of goods or service by an individual (sorry for profit businesses this doesn't apply) are exempt from any taxes.

This is why if you go on vacation to Mexico for example and exchange $100 for pesos, and before you buy a beer the next day, it doesn't matter if the exchange rate rises slightly.  If the pesos you now spend are worth $101.20 you don't have to keep a record of each transaction, amount, time, corresponding exchange rate, and then load all that into your tax software to compute a currency gain of $1.20.  For exempt transactions, it is considered a de-minimis gain and you are not required to report it or pay taxes on it.  

As an example lets look at a consumer who buys 4 BTC from coinbase at $500 ea and later spending those to buy a $1,500 computer from tigerdirect for 2.9 BTC ($517 exchange rate).  Today under IRS guidance there is a $49.30 gain and it would need to be reported as a capital gain tax.  The problem isn't so much the tax but all the complex of the recording and computing of that tax.  The time, exchange rate, and amount of each purchase and spend needs to be recorded and the capital gain schedule filed out, the gains have to be categorized as long vs short and the applicable rates applied.  If it was treated as a currency then the transaction would simple be exempt.  Not only does the taxpayer pay nothing they don't need to file anything. 

Of course right now Bitcoin is appreciating (or at least has the potential to appreciate) and the gains may be more than $200 so it may not make much difference, however in a decade or two if/when Bitcoin is much larger and the growth rate much slower it would be much simpler for most average user of the currency if it was treated as a currency. 

Regardless of it one wants it to be treated as property, there is no logical reason for it:
* You exchange $100 for pesos and spend them.  Treated as a currency (and in most cases is exempt).
* You exchange $100 for euros and spend them.  Treated as a currency (and in most cases is exempt).
* You exchange $100 for pounds and spend them.  Treated as a currency (and in most cases is exempt).
* You exchange $100 for yuan and spend them.  Treated as a currency (and in most cases is exempt).
* You exchange $100 for yean and spend them.  Treated as a currency (and in most cases is exempt).
* You exchange $100 for Bitcoin and spend them.  Magically it is "property" and capital gains need to be computed. WTF?



Think about it for a second.  Have you ever traveled overseas on vacation or business?  If so did you exchange USD for foreign currency and use it to pay for goods or services?  Did you then track the exchange rate at the time of the exchange and at the time of each purchase, record all that in a log, and compute the total gain if any ad at the end of the year take that log plus the logs for all other trips and add it to your tax return?  I am guessing not.

Not trying to flame gweedo but what would we gain from using PGP over say self signed SSL cert?  SSL doesn't need to mean that CA are used.

http://filippo.io/Heartbleed/#blockchain.info

The site is not vulnerable at the current time however this tool can't determine if it was ever vulnerable.  Only the site operator can advise that.  Since there is a chance passwords could have been compromised it may be a good idea to change them.  Although for any site which has real time access to Bitcoins I have to imagine if your password was compromised your coins would already be gone.

No problem.  Entropy (and randomness in general) is a hard thing for most people to grasp so if you get it, you are already ahead of the pack.  The entropy of truly random passwords is just a straightforward equation.  For human chosen passwords it gets a lot fuzzier.  Honestly humans are so bad at choosing strong passwords, most methods for estimating them are probably too optimistic.  Most human passwords can be easily broken unless per record salt and key stretching is used.  The bad news for users of a website for example is you have no idea how the site is storing passwords.  MtGox for example stored passwords using MD5 hash and no per record salt.  This site IIRC uses SHA-256 but doesn't employ any key stretching.  If users had a strong assurance how the password was used they could actually use shorter random passwords with confidence.  Also if the password is already compromised (and there are dictionaries of tens of millions of previously compromised passwords) the entropy is essentially zero.


I am not sure why 12 words from 1,626 was chosen but I am sure there is a reason.  At first glance it would seem a larger wordlist could have easily been used.


So 12 words is probably using a shorter list than necessary but it only adds one or two words to the length of the key.
11 or 10 words is a good starting point if someone was developing a new system (could take out the ~600 least common words from diceware).
9 words might be possible but with 19,113 words needed you are looking at ~200KB in storage and probably going to need some less commonly known words.
8 or less is probably a poor design choice as to save one or two words you end up needing to use a dictionary with less common words like "jargogle" or "apricity".



The english language has grown significantly in the last century.

Well since each word is random and there are 7776 possible outcomes that means each word has Log(7776) = 12.925 bits of entropy each.   The entropy of the password would be # of words * entropy of each word.

5 words = ~64 bits    <- sufficient for low security applications*
6 words = ~78 bits
7 words = ~90 bits    <- sufficient for medium security applications*
8 words = ~102 bits   <- sufficient for high security applications* which rely on an additional factor (i.e. bitcoin wallet requires passphrase AND the actual wallet.dat)
9 words = ~116 bits   
10 words = ~130 bits  <- beyond brute force of nation states both today and into the conceivable future

* This assumes the passwords are stored securely using a key derivation function (strong hash, thousands of rounds, per record salt)

DISCLAIMER: I strongly recommend against using a brain wallet for any reason but if someone is going to use them they should have a realistic understanding of what level of entropy is necessary to prevent compromise.

Brain wallets require no second factor so the only security is a sequence which simply can't be brute forced by anything possible today (even by nation states) or for the foreseeable future.  >128 bits of password strength is considered beyond brute force due to the sheer energy requirements necessary to search that keyspace.  Remember with a brain wallet attacker(s) can simply precompute all probable keys (and that would include shorter diceware sequences).  They can continue forever and slowly expand the database of know addresses.  So the only real security would be a passphrase which is beyond brute force, anything else could have already been broken before you ever used it, or could be broken at any point in the future. 

So for RANDOM passphrases we are talking about:

Dicewords (7,776 words) = 10 symbols (words)
All keyboard symbols (95 unique printable symbols on standard US keyboard) = 20 symbols
Case sensitive alphanumeric (a-z, A-Z, 0-9) = 22 symbols
Case insensitive alphanumeric (a-z, 0–9) = 26 symbols
Case insensitive Latin alphabet (a-z) = 28 symbols
Arabic numerals (0–9) = 40 symbols

So of these sequences I know which one is the easiest for me to memorize
chive edt oat puffy crust kiss long omaha lucky bank
2q4$7hG33d$EAV$gsaR4
NSQPYAFSNTAKNPMVZDRRKWXXACVW
TU9MQW97U99D42Y7TS4J6EGGKN
3363486927993949454245366885937555332592

Remember this only applies to truly random sequences.  Human "random" passwords, ones based on symbol substitution (p@ssw0rd!), or taken from a book/move/song have significantly less entropy.  For most of those it is only a matter of time until they are precomputed by attackers.

There are no small stable markets anywhere in the world.  They simply don't exist.  The exchange rate between the USD and EUR isn't magically stable it is backed by $3T in annual trading.  Bitcoin gets big (much much much bigger) or it never becomes stable.  It is that simple.

It actually will as long as they are RANDOM words.  The random is the hard part.  Humans are actually very bad at coming up with random values.  If you ask people to pick a random number between one and ten a significant portion (usually 20% to 50%) will randomly pick seven and very few will pick one or ten.

Using a true random source like rolling dice is a good method to generate a secure passphrase.  Here is an example:
http://world.std.com/~reinhold/diceware.html

These were rolled randomly
chive eat oat puffy crust kiss = 63 bits of entropy (probably better than 99% of the non-random passwords used on this site right now)
chive eat oat puffy crust kiss long = ~80 bits of entropy (strong enough for most applications, roughly the equivalent of 12 digit random alphanumeric (Y22N^56a%$98)
chive edt oat puffy crust kiss long omaha lucky bank = ~128 bits of entropy (considered beyond brute force regardless of the computing power of the attacker)

I don't think any insurance company is going to write a policy for "losing" coins which can never be definitively proven as lost.

This isn't a "computer glitch" it is a fundamental characteristic of how ALL public key cryptographic systems work.  SSL, TLS, PGP/GPG, DSA, etc they all work on the concept that creating a duplicate private key is infeasible (but not theoretically impossible).