Post
Topic
Board Development & Technical Discussion
Merits 2 from 1 user
Re: Removing OP_return limits seems like a huge mistake
by
tromp
on 13/05/2025, 20:35:21 UTC
⭐ Merited by d5000 (2)
That experiment effectively stored a NEGATIVE amount of data in Mimblewimble transactions. In order to locate each 2.5 bytes of data, the extraction needs to know the ID of every kernel in which data was stored, and their correct order. The data extracting program [1] uses 70 bytes of source code to locate each 2.5 bytes of data.
Yes, I knew about that. That's why I'd be interested if there were attempts which were successful in the sense that non-negative storage was achieved, even if it was expensive.
Not only have there been no successful attempts that I know of, I'm having trouble thinking of a good way to do so. But I am curious to see if other people can come up with one.

As a way of encouragement, let me offer a $100 reward for any scheme to store (10KB + X) of arbitrary data on a pure Mimblewimble chain using at most 100KB of total transaction size + X extraction data size, with extraction running fast and not revealing keys that allow the pruning of stored data. This corresponds to a >= 10% storage utilization rate.

The reason for quantifying extraction data is to make sure the scheme can scale up by chaining, for instance to storing (100KB + X) of arbitrary data by using at most 1000KB of total tx size (the basis for calculating fees) plus the same X extraction data size.

I'll double the reward for an actual demonstration on Grin testnet or mainnet.

Quote
I wonder however: couldn't be the same techniques to use for "scriptless scripts" also work for data storage?
There's several ingredients to make scripts scriptless. One is adaptor signatures, which relate on-chain signature scalars to off-chain signature scalars. With 3rd parties having no access to the latter, I fail to see how this can provide for any on-chain storage. Another ingredient is kernel locktimes, which provide around 24 bits of storage for chosing arbitrary lock times in the past. Which is only about 3% of the kernel size, so still rather limited.