Sorry, Nicolas, you did not really store the whitepaper in the MWC blockchain. Instead you almost randomly scattered the thousands of bits in the whitepaper over the MWC blockchain, losing much of their structure in the process.
Then, to enable someone to put all these bits back together in the right order, you provided this huge list of kernels which is MUCH larger than the whitepaper itself.
It’s like spreading a millions coins, each engraved with a few bits, over the world’s oceans, and saying you stored the data in the ocean. While providing a multi megabyte file containing the GPS coordinates of each coin in order to retrieve the data.
Note that this is exactly the point (#3) I made in this post arguing that Grin is the most spam resistent blockchain. You clearly demonstrated how the cost of retrieval can easily exceed the amount of data retrieved.
PS: you could almost just as easily have stored the data in the kernel commitments themselves instead of in their timelock. It’s just like creating vanity addresses. All you need to do is compute xG for about ln(2^21)*2^21< 2^25 x’s and you can expect to have the least significant 21-bits in the xG commitments to assume all 2^21 possible values. That’s why Grin allowing 21 bits of arbitrary data in lockheight is not something to be overly concerned about.