Mr. Mix is a regular commentator at Zero Hedge, an influential financial website. He writes a blog on subjects of interest to him, recently including Bitcoin, a controversial topic.
As a beginner, he wanted to take a good look at the Bitcoin ecosystem for himself with the help of a couple of experts, as well as explore some parts of Bitcoin that beginners do not typically see.
A man of many interests, he is happily married to a wonderful Peruvian-born lady. Mr. Mix has been involved in international business (buying ball bearings and similar products for their company in Peru) for over 20 years.
(first published on Wednesday the 11th of December, 2013)
Bitcoin is thinking BIG. Take a look at this image (*click* on the image to see the smaller details). It’s one of many from bitcoin.org, there apparently is “no official image.”
– Liberty, Equality, Truth: core ethics of the Bitcoin system / community.
– 21,000,000 to infinity: there will be a maximum of 21 million created by approximately 2140, currently there are close to 12 million coins in existence.
– 2009: public release of Bitcoin software and creation of first currency units.
– In cryptography they trust: within the Bitcoin system, financial middlemen are replaced by cryptography.
Bitcoin Mining in Depth
This article is rather technical in nature. I have had two people review this and suggest changes to make (which I did) to make it “easier”. You be the judge.
BTC mining is a complicated process that, at root, has more to do with probability than with fast computing cycles. It differs thus from Phil Zimmerman’s “PGP” (“Pretty Good Privacy,” a formerly free email encryption program, now in the public domain as GnuPG) technology of some 15+ years ago. The core of PGP was that multiplying two LARGE prime numbers together (and calculating their solution, of course) is computationally much easier that starting with one very large product and “backwards deriving” the two primes. This is a simplified example of the two prime numbers method:
12,094,091 – YOU try to guess the two prime multiples of the below number, go ahead, guess…
[Mr. Mix ran a contest on his blog, where the first person to give the correct answer won 0.05 BTC. “Unknown” won the prize for the following answer:]
12094091: 2347 * 5153
Of course in the real world, the primes used in the above would be (say) 60 digits or so each, meaning a huge number. It becomes computationally impossible (last I heard anyway) to break a number like the above that is 100 or 200 digits long… But, a big (fast) enough computer COULD do it in theory (big numbers).
Mining BTC uses a completely different mathematical technique, called a “hashing function.” A hashing function (here anyway) turns an input, by some weirdo math, into a hard-to-reverse, encrypted output.
By complete coincidence I developed my own little “hashing function” a few years ago in SQL (“Structured Query Language,” a database-only language. Oracle and MS Access use SQL) when I wanted a way to encrypt our Customer IDs (an identifying number, kind of like Social Security numbers) yet list the amounts they bought. The intention was to show prospective customers that Ameru [the company Mr. Mix’s owns with his wife] was REAL; that we moved real amounts of bearings.
Here is the heart of my SQL (this is just a clip from the whole encryption function I made up) coding to do that. The below takes an 11 digit Customer ID and completely changes it into a completely different 12 digit number:
((Right(([df_2].RUC),2) Mod 2) + 1) * 10) & (Right(Left((([df_2].RUC) * 599),11),10))
I will not bore you with dissecting the above (fairly complicated) SQL, but I take the Customer ID number (“RUC”), multiply it by 599, then take the second through eleventh digits in that product, but prefixed (fairly randomly) by “10” or “20” (that “Mod 2” you see at the left).
Real Customer ID: 20121941962
Secure Customer ID: 102053043235 <— hard to derive the real Customer ID
Obviously the hashing function with Bitcoin is much more secure and robust than mine, there is real money at stake with BTC!
Proof of Work: Mining by Hashing
Once again I have asked the help of BTC expert “Bitcoin Insider” (“B.I”) to help me better understand the subject so that I can pass it along to you all in terms that even I can understand (smile).
One aspect of the BTC Ecosystem I wanted to gain a little understanding of is the BTC mining process. I had read a lot of somewhat contradictory comments at Zero Hedge re: mining for BTC, and I wanted him to straighten me out. I asked him to explain in simple terms something about the mechanism of encryption used in BTC:
B.I.’s short initial answer:
(List of recent transactions for the next 10 minute block) +
(random number selected by mining computer) =
a hashed number with many leading zeros below a threshold number.
Whichever mining computer finds this low hash number first
creates the block and gets the 25 Bitcoin reward plus transaction fees.
That “leading zeros” I bolded is explained in more detail here from this article by “azotic” that B.I. sent me. It is NOT that hard, I encourage everyone to read it. Key quotations from the article:
“…bitcoin hash outputs need to start with about 14 zeroes at the time of this writing in order to be accepted by the network as a solution.”
“That number of zeroes that the output has to start with is known as the “Difficulty.” Right now, the entire network of miners makes about 30 trillion(!) attempts at this solution every SECOND. You can see the “hash rate” at sites like bitcoincharts.com. A solution (which yields 25 bitcoins to the finder) is found approximately every 10 minutes.”
Note from the above second clip that 30 TRILLION attempts per second are made worldwide to solve the BTC “math problem”.
The Bitcoin hash function is based on the open-source “SHA-256” mechanism, here is a link that will allow any of you to generate your OWN hash functions:
For illustration, here are some results when I went to play with it.
Inputs (I know what the below three things mean even if you do not!):
Outputs (in above order):
Oooh! Look at those lovely outputs! As in PGP’s “two prime number” method of encrypting data, taking the OUTPUT and trying to guess the input is computationally infeasible…
Note that the THIRD one starts with a zero! To solve a BTC [“block”] math problem, your computer would have to stumble upon a correct hashed output that starts with 14 zeros! See first snippet above in red.
Another wrinkle is that even if you have a very powerful “ASIC computer” (or even a “server farm” of 100 of them), that there is no guarantee that you would get a solution, not even in 10 years. It is probability based! Yes, a fast rig (or farm of ’em) is much more likely to find a solution in a reasonable amount of time, but there are no guarantees…
Keep in mind I asked him for a simple explanation, ha ha ha! But, to get this level of understanding is NOT THAT DIFFICULT (even if it is not necessary to understand this to use BTC, although to mine BTC you would need to know this and more). That “25 Bitcoin reward” would now be worth some $20,000, perhaps more by the time you read this… [still $20,000 as of the time of republishing – who said Bitcoin is volatile ;) ]
Elliptic Curve Encryption
There is other math, probably at least as complicated as the above, securing Bitcoin. Apparently Elliptic Curve crptography, where they use equations of the type:
Zero Hedge member “zaphod” posted this comment which I quote in full (minor edits for spelling):
ECDSA (Elliptic Curve Digital Signature Algorithm) is the cryptography that is used to prove ownership of individual bitcoins.
In ECDSA there are 2 keys, a public key and a private key. Basically an address is the public key and the private key is what you keep secret, essentially possession of the private key equals possession of a bitcoin.
[PGP uses a similar cryptographic system for communication, albeit based on primes.]
The way transactions work is you create a public/private key pair and then provide the public key (actually the hash of the public) as the address to “receive” bitcoins. When someone sends you a bitcoin they create a transaction that specifies your address (public key) as the receiver of X bitcoins. Once that transaction is recognized by the network, the only way to release those bitcoins in your address is to sign them with your private key.
Now when you want to send the bitcoin you received, you use your private key to create a unique signature on the previously received coins. The way ECDSA works is anyone with the public key (your address) can verify that the signature is correct, however the only way to create the signature requires the private key.
This is a great walkthrough of ECDSA if you are interested in the concept. Will take a few hours to absorb the concepts/math.
Elliptic curve cryptography, I read, is much more secure than the “two primes” method of PGP.
OK, elliptic curve takes care of ownership of BTC, the SHA-256 hashing method takes care of the mining.
Zero Hedge reader “Prisoners_dilemna” asked about another encryption method: RIPEMD160.
Here is his later explanation of how a “public address” (a BTC wallet) is created, it is a nine step process and it is not easy…
The section on RipeMD160 is pretty… non-existant, so anything I say here has gotta be an improvement :)
All of this was taken from bitcoin.it, stackexchange.com, and wikipedia.org.
A bitcoin public address (what we provide to others so they can pay us BTC) is in fact the hash of an ECDSA public key, computed this way:
Version = 1 byte of 0 (zero); on the test network, this is 1 byte of 111
Key hash = Version concatenated with RIPEMD-160(SHA-256(public key))
Checksum = 1st 4 bytes of SHA-256(SHA-256(Key hash))
Bitcoin Address = Base58Encode(Key hash concatenated with Checksum)
Here’s the same thing in step-wise fashion;
0 – Having a private ECDSA key
1 – Take the corresponding public key generated with it (65 bytes, 1 byte 0x04, 32 bytes corresponding to X coordinate, 32 bytes corresponding to Y coordinate)
2 – Perform SHA-256 hashing on the public key
3 – Perform RIPEMD-160 hashing on the result of SHA-256
4 – Add version byte in front of RIPEMD-160 hash (0x00 for Main Network)
5 – Perform SHA-256 hash on the extended RIPEMD-160 result
6 – Perform SHA-256 hash on the result of the previous SHA-256 hash
7 – Take the first 4 bytes of the second SHA-256 hash. This is the address checksum
8 – Add the 4 checksum bytes from point 7 at the end of extended RIPEMD-160 hash from point 4. This is the 25-byte binary Bitcoin Address.
9 – Convert the result from a byte string into a base58 string using Base58Check encoding. This is the most commonly used Bitcoin Address format
Now in order to unlock the public address above to get the private keys (and spending rights to the BTC), we just need to do these steps in reverse. Eezy Peezy. I’ll be back in 4 centuries when humanity figures out how to do that.
So we see RIPEMD160 used ONLY to generate public addresses. Nowhere else is it used within the BTC protocol.
Why is it used there and only there?
“It is worth noting that Satoshi could’ve used SHA2-256 twice and truncated the second digest to 160 bits. The fact that he didn’t I think is some evidence to show that Satoshi’s decision was a conscious decision to use RIPEMD-160 over the NSA suit of algorithms.” username liamzebedee from stackexchange.com
I tried reaching out to Satoshi for an answer but I had even less luck with that than I have trying to find private keys from public addresses.
I can only speculate and so here it is courtesy of wikipedia;
“RIPEMD-160 is not known to be constrained by any patents.”
My conclusion/opinion is that should SHA256 be broken or have a backdoor, RIPEMD160 would protect private keys while developers swapped out SHA256 for SHA512, or another open source method of encryption.
Finally, Satoshi could’ve written the protocol such that the ECDSA public key doubles as the public address for receiving BTC. However hopefully it is apparent now that while it is nearly impossible to derive an ECDSA private key from its public counterpart, its IMPOSSIBLE^GOOGLEPLEX to derive the ECDSA private key from the completely jumbled hash that we know as the BTC public receiving address.
And a Wikipedia link to RIPEMD160, which was created in Belgium by the academic sector (NOT the NSA like SHA-256 was), and is not patented.
And THAT hereby finishes my article.
Gold Still in the Mail…
I had hoped that I would have word on my purchase of the 0.25 oz Gold Eagle by now. Nope, no word yet. Maybe that will be in my article “Fun With Bitcoin For Beginners: Part Five”.