There's some sort of grandiose story associated with the release of the MimbleWimble whitepaper (i.e., there was an individual that wrote the whitepaper then simply "released" it into a Bitcoin chat / IRC).
That story sounds like they were possibly attempting to be mysterious like Satoshi was - perhaps (maybe they felt that this was the 'correct' way to produce such a release in lieu of Satoshi's presence and status in the blockchain space).
There's also the possibility that this individual felt that their anonymity only made sense within the greater context of them providing a privacy-focused solution for blockchain.
Digging Into the Whitepaper
Shaky Introductory Premise
The author begins the whitepaper by stating:
Someonewho sishes to check [the blockchain] must download the whole thing and basically replay each transaction, check each on as they go.
This narrative is far from the entire truth of how of how verification (not validation) works on the blockchain.
Breaking Down the Actual Functionality of Bitcoin: Transactions
Let's place ourselves at a starting spot that dictates that we have a Bitcoin wallet with approximately $25 worth of Bitcoin stuffed in said address.
In other words, those funds ($25) are known by the protocol to be unspent.
Transactions Are Stateless
This means that one does not need to be online in order to:
Create wallet addresses
Craft a transaction (one will need to log in online / access the internet in order to actually relay the transaction over the Bitcoin network - however) .
Implications of This Setup
Whether or not a user has satisfied the necessary requirements to spend a transaction is something that is adjudicated by the 'script' (forthright language that everyone speaks of that uses the C programming langauge in order bake op_codes to provide on-the-fly authentication schemes on the protocol).
Once Your Transcation is Relayed
Let's say that you decide to relay you transaction.
You broadcast it to the network
Nodes on the network that have your relayed transaction propagated to them decide whether or not they wish to allow it to exist in their mempools (per protocol / consensus rules as well as related node configuration options that operators can further figure to give them an even more granular means of discriminating which TX addresses they wish to relay / not realy).
Assuming the attached fee is sufficient and the transaction itself is valid (i.e., not a double spend) - a miner should eventually include the transaction in their block template (perhaps multiple miners will include it in their block templates as they attmept to find the corect 'nonce' in order to win the accompanying block reward + the collective fees of all those that sent transactions on the protocol).
^^ Everything that was just described above - illustrated below:
Assuming Your Transaction is Included in the Block That Gets Relayed
Joe Blow (or you / whoever), will more than likely check their wallet or a block explorer periodically if they are anticipating the arrival of the funds in the near future.
Addressing the "Replay Each Transaction" Idea
The idea that each transaction must be individually reviewed (at least in the manner implied by the writer) is unequivocally false.
Lest we forget, a classic Bitcoin transaction is verified (not validated) by checking the signature.
To be entirely honest, we're not sure what the author means here in their assertion that one must "replay the transaction" (what would that entail?).
Again, just to be clear:
Transactions on Bitcoin are stateless (i.e., not contingent on a server / internet connectivity)
This Was Even Stated Directly in the Bitcoin Whitepaper
This may seem like nitpicking to a certain extent, but distinguishing how transactions are verified is a meaningful distinction to make.
Those re-visiting the whitepaper for reference will find Satoshi's comments on signature verification below:
SHA256 Hash Function Mitigates Computational Overhead Significantly On Modern Hardware
Computers fulfill thousands of cryptographic operations on a regular basis (outside of Bitcoin).
Hash functions in specific are useful for a number of different purposes outside security / creating a PKI system / blockchain.
For instance, hash tables can be a really useful means of quickly indexing a large directory of information in a very short amount of time due to the 'one-way' nature of most hash algorithms (i.e., SHA256); which all-but guarantee that each hash generated will be a uniquely different one than any other hash that has been assigned (i.e., no collisions).