MimbleWimble Whitepaper Analysis: Part 2


4 min read
MimbleWimble Whitepaper Analysis: Part 2

It may seem like we took a major detour in the dissection of this whitepaper, but we didn't.

The truth is that the initial set of statements made by the author in this paper were so grossly inaccurate that they needed ot be corrected.

And this desire to correct the author does not stem from the idea that we think they're stupid.

In fact, quite the opposite. Whomever came up with this whitepaper (ans specification) is probably a very intelligent individual.

However, their characterization of how the Bitcoin protocol functions is lazy and wholly inaccurate. Therefore, it must be corrected because, if not, then the reader loses what could have been a potent means of reference to compare the proposed 'solution' / enhancement to the already existing architecture of blockchain.

The Author Uses Their Misconception of Bitcoin to Further Establish Their Position

In the second paragaph, the author goes on to argue:

At the time of writing, there were nearly 150 million transactions committed in the blockchain, which must be replayed to produce a set of only 4 million unpsent outputs.

Again, this is wholly untrue - but perhaps for another reason(s) than what was described in the previous section.

Debunking the Myth of 'Replaying Transactions' (Again)

*To be clear:

There is no such thing as 'replaying transcations'.

Transaction verification is done via linking the transactions together

Grasping 'UTXOs'

Additionally, it appears that the author is blissfully unaware of the fact that Bitcoin was designed to link transactions together rather than just provide a ledger of sender and reciver.

That's the true reason for why a 'ledger' is a practical scheme in the first place for such a system (and for most).

Revealed in the Signature Process

Typically, when one spends Bitcoins that were assigned to a wallet that they possess the adequate credentials for (i.e., private key).

Barring you being the recipient of an exotic bitcoin transaction that was crafted with uniquely strange op_codes, all of your transactions will involve the authentication of your signature.

How Transaction Signing Works

For nearly all transactions on the Bitcoin protocol (yes, even Segregated Witness - which we won't climb into now at this point in time) - verification / authentication of anything on the Bitcoin protocol is done via signing.

Especially Important Fact RE: Bitcoin

One is typically required to hash all of the inputs in a transaction (as well as the outputs).

In fact, in most cases, everything will be signed except for the actual signature itself.

What This Means

Much in the same way that Bitcoin is able to enforce Proof of Work by mandating that the hash of the previous block header be hashed (in addition to all of the TXs being included in the block + header data) in order to establish a linkage between blocks (hence, the concept of a "chain").

Similarly, transcations (which typically require that all inputs are to be signed along with the designated outputs), are 'linked' through the inclusion of said links.

Merkle Trees and Othe Cryptographic 'Compression' Schemes Lighten the Load of Authentication SUbstantially

Once again - this was a concept that was actually addressed by Satoshi Nakamoto directly in the Bitcoin whitepaper itself!

One must also remember that the "average" user at that time probably had the additional expectation to contribute to the protocol via mining.

More Inaccurate Statements About the Functionality of Bitcoin Are Laden Throughout the Paper

Moving forward from where we just were (the first two paragraphs of the Mimble Wimble whitepaper), the author goes on to state that:

It would be better if an auditor needed only to check data on the outputs themselves, but this is impossible because they are valid if and only if the output is at the end of a chain of previous outputsk, each signs the text.

This Assertion Could Not Be Further From the Truth

The idea of an unspent transaction refers to the state of the funds. Lest we forget, Bitcoin is an asynchronous protocol. Also, there is a finite number of coins that will ever be generated (some number above 21 million; cookies to the person that knows this number off the top of their heads).

Going back to the $25 dollar example used at the beginning of this whitepaper analysis - if I (the author) were to spend those funds (by giving them to a friend) - then the coins assigned to the P2SH / P2PWPKH / mechanisms (etc.) are deemed to be spent / unspent based on their status relative to how they are spent.

Visual Aids

The following visual dissection of the path of Bitcoin should help any readers that are having as much trouble as the author of the MimbleWimble whitepaper did in discerning how transcations are crafted on the blockchain.

The Fallacious Idea That Bitcoin Should be Private

To be clear, Bitcoin - by design - is meant to be as public and transparent as possible.

Obviously, this was a purposeful design goal for Satoshi Nakamoto because - anything that didn't meet that bar would  surely be cast away as a scam / non-innovation / hustle etc.

The author, however, remains blissfully unaware of this fact (despite apparently being so motivated by the 'ills' of what they preceive to)

**Bitcoin is Designed to Facilitate Authentication, Not Encryption

Satoshi Nakamoto was not opposed to the idea of encryption and spoke about it on several different occasions with various members of the Bitcoin community during its nascent phases - particularly those that began to see the potential in Satoshi's design concept that had anticipated some issues in the future regarding the "public knowledge" of Bitcoin usage.

GO TOP