Mimblewimble explained with analogies

INTRODUCTION

In any monetary system, when someone wants to transfer value to another person, there are some rules that must be enforced in order for the system to work:

Value should not be created or vanished only transferred
this implies that:
1.1. The amount of value that someone wants transfer (output) in a transaction, must be backed up for the same amount of value (input). In other words, the sum of the amounts of outputs must be equal to sum of the amount of inputs ( or sum of the amounts of inputs - sum of the amounts of outputs = 0).
1.2 The amount of value that back up a transaction, must not be used in a previous transaction. (double spending).
1.3 The monetary system must be auditable by anyone to verify that value has not been created (or vanished).

Transactions can only be initiated by the person that holds the value.

TRANSACTION

The transaction for this scenario is as follows:

Inputs	Outputs
A bill Alice received for 15 tokens	A bill for 23 tokens to Bob
A bill Alice received for 22 tokens	A bill for 14 tokens back to Alice as change
-----------------------------------------------	----------------------------------------------------------
37 Total	37 Total

Inputs

Outputs

A bill Alice received for 15 tokens

A bill for 23 tokens to Bob

A bill Alice received for 22 tokens

A bill for 14 tokens back to Alice as change

-----------------------------------------------

----------------------------------------------------------

37 Total

Inputs = Outputs or The sum of all inputs 37 - the sum of all outputs 37 = 0.

In this monetary system imagine that you could have bills for any amount denomination. Probably the term "check" would be more appropriate, but in the case of the return change, Alice should write a check for herself and this doesn't sound as real life. Anyways you can imagine that they are bills of any denomination or checks.

A process for changing those input bills (15 and 22) to the output bills (23 and 14) Alice requires to perform the transaction is required.

THE BITCOIN WAY

The Bitcoin way of doing this is by linking the inputs to previous outputs in a public ledger, but instead of using names it uses account numbers.
In this process the only way privacy is archived is if you cannot be linked to your account, as soon as your account number is disclosed that belongs to you, at that moment privacy is lost.

Let's imagine that Alice's account is named A, Bob's account as B, Charlie account as C and Diana account as D. Adding more transactions to our scenario let's imagine that after Alice sent 23 tokens to Bob account, Alice sends 3 tokens to Diana and Bob sends 5 tokens to Charlie.

Bitcoin is going to link each input to an unspent output as follows:

...── 15-A ┐ │┐ ...── 22-A ┘│ │┌── 14-A ┐ └│ ├── 11-A ──... │ └── 3-D ──... └── 23-B ┐ ├── 18-B ──... └── 5-C ──...

Although name are not disclosed, amounts, sending and receiving accounts are.

HIDING AMOUNTS IN MIMBLEWIMBLE

Alice doesn't want the disclosure of the fact that she has 23 tokens to spend and that she sent 23 tokens to Bob. Alice would like to encrypt the amount but anyone should be able to audit that new tokens were not created in the transaction. Let's imagine that when Alice received her 15 and 22 tokens, he provided a box with a lock (public key) that can only be opened with a key only she holds (private key). One person put the 15 tokens in one of Alice's boxes and locked, another person put the 22 tokens in the other Alice's box and locked the box, Alice is the only one that could open those boxes because she possesses the keys to unlock them.