https://eprint.iacr.org/2021/967.pdf shows that 2330 logical qubits suffice.

I don't see why the fee rate would be high. Payment channel settlement transactions just pay nominal fees, no matter whether they result from a handful of txs, or thousand of txs. This is not a case of packaging a bunch of txs into a batch that preserves all their fees, but of one final settlement tx obsoleting all earlier ones.

Finite supply is overrated [1].

Fiat is a bad example, since unlike most cryptocurrencies, it's not even disinflationary.

[1] https://tromp.github.io/blog/2020/12/20/soft-supply

Basic ring signatures take up space proportional to ring size which makes them rather inefficient.
Newer designs [1] get by with logarithmic size which support large ring sizes much more efficiently.

But in either case the real efficiency problem is the impact on UTXO size. Since one can never tell which is the real input and which are the decoys, no output can be known to be definitely spent. So the UTXO set balloons to the entire TXO set, with very detrimental impact on node efficiency. It's not so noticeable on Monero yet because daily tx volumes are about 15x smaller than Bitcoin.
Zcash suffers from the same problem, but with only 10% of Monero's tx volume, it's even less noticeable there.

[1] https://eprint.iacr.org/2024/921

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.

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.

That experiment effectively stored a NEGATIVE amount of data in Mimblewimble transactions. In order to locate each 2.5 bytes of data, the program for extracting it 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.

This shows the huge challenge of storing data on a Mimblewimble chain that destroys all ordering information of all outputs and kernels in a block.

[1] https://github.com/NicolasFlamel1/MimbleWimble-Coin-Arbitrary-Data-Storage/blob/master/main.py

A quantum computer only has a quadratic advantage in cracking the hashing based wallet security.

In any case the seed phrase of your wallet should not be your main worry. A scalable quantum computer will be used to drain all utxo with known public keys, which will collapse the bitcoin price and make your wallet nearly worthless even if its specific keys are not yet cracked.

The reordering of tx outputs and signatures is one reason for spam resistance (item 3. in [1]), but not the main one. Which is the fact that there's very little room for spam to begin with (items 1.,2.,4.)

[1]
https://forum.grin.mw/t/ordinals-on-grin/10336/2

If you mean that some output bits can be set by grinding, then it would be not a little bit less, but MUCH less. What other way is there to store data in fake outputs?

The demand for bitcoin is expressed exclusively through the fees paid per byte. If jpeg encoding transactions pay more fees, then they WILL clutter the blockchain, since profit driven miners will include them. You can only slow them down slightly by making them jump through hoops like sending them directly to willing miners.

Wrong; a solution attempt is exactly one iteration of this loop in GenerateBlock [1]:


which computes a single ten_hash, just as verification does. The only thing potentially exponential is doing it max_tries times.

[1] https://github.com/nf-dj/robocoin/blob/main/src/rpc/mining.cpp#L146-L151

In other words, this is not a new Proof-of-work algorithm.

It's still the Hashcash POW used in Bitcoin, that computes a deterministic value for any given block header using some hash function, and compares it against a target value that's inversely proportional to difficulty.

The difference is in the hash function used for Hashcash. Instead of Bitcoin's SHA256d, this proposal uses a tensor (i.e. matrix multiplication) based hash function.

It's not an asymmetric PoW like Cuckoo Cycle or Equihash, where verification differs from (and is WAY faster than) a solution attempt.

What is the cumulative work achieved by GRP up till today? How long would it take all bitcoin miners to achieve that amount of cumulative work?

So we've gone from
to there's one other that may still be alive, which for lack of explorers cannot be publicly verified.

According to https://bitcointalk.org/index.php?topic=56675.0

> 10 CLC reward per block initially, halving every 525000 blocks (nominally 2 years) until it reaches 1 CLC where it will remain forever.

So the top of your head is not very trustworthy:-(
Please tell me one coin that you know for certain (as in, verified) had a fixed reward from launch on forever.

I don't know of any besides Grin.

With the default assumeValid, it's not fully verifying from scratch, since it only verifies historical scripts and signatures of the last few years. You're trusting the developers' claim that all earlier scripts are valid too.

When you say "from scratch", do you mean that you changed assumeValid to be 0 (instead of defaultAssumeValid) ?