This breaks down the difference between account-based transactions (which Ethereum uses) and the UTXO-based transactions that Bitcoin, Litecoin, Bitcoin Cash and many others use.
While both protocols are Proof of Work (at the time of writing), this difference in assessing / accounting for transactions dramatically alters the way that transactions are confirmed on each distinct protocol type.
First Step: Confirming the Exact Cryptographic Operations
We need either documentation or an extensive resource - this is not information we want to extract from a run-of-the-mill crypto site that you find on Google.
Found a Reliable Source: https://www.oreilly.com/library/view/mastering-ethereum/9781491971932/ch04.html [Mastering Ethereum]
This resource is verbose because it goes through the additional trouble of breaking down cryptography (waste of time at this point - if you're new to these concepts, then you won't be able to grasp the importance of the actual cryptographic primitives that are used to generate an Ethereum address - at least not at this point).
But We Found Out
A) Ethereum uses the same elliptic curve that Bitcoin uses (secp256k1 ; Koblitz Curve on a 256-bit prime)
(this needs to be cross-referenced with specific parameters for the generation of an Ethereum wallet, as provided by Ethereum developers because their implementation of the Keccak algorithm is different than what modern cryptographic libraries [i.e., OpenSSL or any other library that would be used to create such a wallet address would use]).
Their implementation of the Koblitz curve, however is standardized - so that's not an issue.
The 'Mastering Ethereum' book simply reiterates what we already know from the parameter standards published by SECG (https://www.secg.org/sec2-v2.pdf), but below is a picture from the M.E. (Mastering Ethereum abbreviated - we'll use that from here out):
As the book acknowledges, modern cryptographic libraries (just about any on planet earth) possess this algoritihm:
To be clear, however, the library in question for this specific use case (client-side, in-browser cryptographic operations) - would be the 'WebCrypto API' (based on Mozilla's crypto library [NSS] or the crypto modules that Chrome uses).
Both have possessed the capability to perform this type of operation within the browser for quite some time - we're not worried about this at all (our website certificate uses elliptic curve cryptography & was generated manually with a higher bit strength than secp256k1 ; our SCT pinning will soon be of a higher bit-size too [although we'd prefer ed25519 / ed448 key generation in place of these NIST-curves ; but that's another story for another day]).
Ethereum's Hashing Algorithm Choice
The fact that Ethereum opted or Keccak-256 (SHA3) vs. SHA256 (which Bitcoin uses) is already widely known information and there is no problem with this choice.
In fact, its probably a superior option - and not for the idea of an inherent security boost (although that's always a plus ; SHA256 is considered sufficiently secure though) or to mitigate malleability (although this was still an issue that needed to be separately addressed at a later point) ; its primary benefit is increased efficiency for x64 architecture (which virtually everything, even ARM devices, use these days).
More to the point though, this excerpt below is the most 'concerning' point here:
Adding in the tidbit about Edward Snowden is entirely irrelevant and there is nothing noble about Ethereum's refusal to swap out Keccak for the updated parameters provided by the NIST.
The NSA, which works closely in concert with the NIST, has used the NIST as an instrument to include backdoors in published cryprographic algorithms before. This was not revealed by Snowden but rather cryptanalysis by external, independent cryptographers (https://www.schneier.com/essays/archives/2007/11/did_nsa_put_a_secret.html ; long before news of the NSA Program, 'Bullrun' was leaked out - essentially confirming what cryptographers knew to be the truth years prior).
Why the Hash Function is Important
One notable feature of blockchain is that the resulting public keys (addresses ; public-facing alphanumeric identifiers used to mark recipients), is that they require a hash function during the creation phase.
Difference From PGP
The most similar cryptographic system around that mirrors Bitcoin is PGP (GPG; whatever).
The way PGP works is widely known & should be familiar to those that at least understand Bitcoin but aren't familiar with PGP.
For that reason, we won't waste time climbing into that rabbit hole - but one thing must be brought up (to understand how all of this ties together).
PGP restricts hashing to the signing / authenticating of messages in their cryptographic system (see below):
[source: https://users.ece.cmu.edu/~adrian/630-f04/PGP-intro.html#p9 ; site will give you an SSL warning in your browser - its just old, nothing can happen to you because you're just reading html / plain-text [pro-tip: *no site that you visit on the 'darkweb' via Tor Browser has an authenticated certificate, barring some rare exceptions']].
Specification for Bitcoin Wallet Generation
This is technical, but put in simple enough terms to be understood if you sit down and read it (versus skimming it like a social media status):
(source: https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addresses)
Notice that there is a hash operation that is performed immediately after the ECDSA operation (secp256k1; derived from the random seed phrase).
You can ignore the RipeMD-160 as that was used primarily to shorten the output (length) of SHA256's hash function in order to make Bitcoin compatible with x32 architectures (which was a smart, reasonable decision back in 2007/2008 when Bitcoin as being designed & developed by Satoshi Nakamoto).
Specification for Ethereum Wallet Generation
There are some major differences in this process for Ethereum vs. Bitcoin.
Most of these differences derive from the fact that Ethereum's blockchain relies on 'account-based' balance verification vs. Bitcoin's 'UTXO-based' method.
The main difference here is that the user is accounted or in Ethereum, whereas in Bitcoin, there is no concept of a "user" ; rather, Bitcoin is simply interested in ensuring compliance with protocol rules - namely the biggest one, which is avoidance of double spending (not counterfeiting ; that's already addressed off-chain, offline through the 'SCRIPT' language & C++ programming-like op-code functions used to evaluate whether the necessary conditions for spending unspent funds been fulfilled).
Unfortunately, the best source of information on this process is the Ethereum Yellow Paper.
The reason why the word 'unfortunately' is used is because it is extremely dense in the language that's used. We don't think that it needs to be dense as it is (this is not to 'dumb it down', but simply to make the writing more fluid & intelligible ; but we'll dig into prose conversations later).
See the first relevant excerpt below:
(source: Ethereum Yellow Paper ; its located all over the place, so access it from someone / somewhere you trust)
Attempting to Crawl Through the 'Thick' of the Ethereum Yellow Paper
The excerpt above outlines an important reality of Ethereum.
Since they use an account-based means of accounting for spent vs. unspent currency, they must rely on a different means of authentication.
To be clear, this is different than validation (the Proof of Work mining process). That is the method used to ensure that nobody cheated the process.
What we're referring to is the process those miners are validating in the first process (hence the term, 'authentication').
State 'Nonce' Value
Bitcoin 'stamps' transactions via block generation in a way that allows users on the network to quickly access the validity of spend attempts by simply polling which blockchain possesses the greatest Proof of Work.
The limit here, however, is that the most up-to-date view of the blockchain is restricted to whichever chain has the greatest Proof of Work. And that Proof of Work total is only updated every 10 minutes (or so). Thus, anything that happens between updates (i.e., new blocks being published) is in limbo.
There's no telling when a block will be created.
For Ethereum, the 'limbo' is mitigated significantly (but the throughput is still limited ; that's a different conversation).
In order to 'update' the blockchain, the blockchain maintains the 'state' value of each "account" by mandating an eternally increasing 'nonce' to delineate the blockchain's state at any given time.
How the 'Nonce' Works
Each time that an Ethereum account sends a transaction or performs an operation, the 'nonce' value increases (by just one integer).
See below for a super simplified, super quick breakdown of how that works:
Account A sends 1st Transaction: Nonce state = 1
Account A sends 2nd Transaction: Nonce state = 2
Account A makes a call on some random contract: Nonce state = 3
... (etc)
As one can tell from what we showed above, the nonce state is an infinitely, ever-increasing value that is referenced in order to ensure that nodes on the chain are not accepting blockchain versions with competing 'versions' of how these nonce epochs played out.
Benefit
The biggest benefit here is that this adds an additional layer of verification (on top of just using Proof of Work) and this is needed given the contract functionalities that are on Ethereum.
(let's leave this here and move on with it).
Check Out the Explainer Below From a Wonderful Medium Article That Digs Into Ethereum Blockchain Nonce Values
(source: https://medium.com/swlh/ethereum-series-understanding-nonce-3858194b39bf)
This brings us all the way to the trouble with Ethereum wallet apps (and why you don't really see a ton of them in the same way that you do with Bitcoin).
Why Ethereum Wallet Apps are Almost Forced to be Insecure By Design
This except below tells us all:
The example that was given above was merely a simplified way to explain this nonce concept.
But in practice (for Ethereum) that increasing nonce value is determined, in part, by the state of the entire blockchain
MyEtherWallet Does Not Need to Account for 'Nonce' Total for Wallet Generation Though
In specific, this increasing 'nonce' total is only relevant for trasactions.
Conceptual Understanding of Wallets
Even though we speak of wallets in terms of some concrete, tangible concept or item that can be manifested or created - the blockchain doesn't account for what addresses "exist" or not.
In reality, the total number of addresses in existence is always equal to the total number of addresses that could be in existence.
The blockchain accounts for this ridiculously large sample space (impossible to create an array for) by only tracking addresses that have been identified in a transaction on the blockchain.
What That Means
When you create a Bitcoin / Ethereum wallet address, the blockchain has no clue this happened.
In fact, that address is as good as "invisible" / nothing until it is involved in a transaction - and at that point, its only significance derives from the fact that it will forever play a role in the accounting of legitimately spent / unspent funds going forward.
This is also the reason for why the blockchain does not need to 'care' about what wallets exist and don't.
Digging Back into the Keccak Hash Function Used During Wallet Creation or Ethereum
We don't need the Ethereum Yellow Paper for this one (fortunately).
Let's take a look at how an Ethereum wallet address is created (per 'FreeCodeCamp' ; see below):
Yes, its that simple.
Top comments (0)