Next scheduled rescrape ... never
Version 2
Last scraped
Edited on 13/05/2025, 07:05:40 UTC
If that 5x increase were 'free' then sure, but you get that only after maybe doubling the amount of data needed to relay txn/blocks, doubling the validation costs, doubling the size of addresses,  and radically handicapping the utility of Bitcoin.
This spam resistance is free in Mimblewimble chains, where amounts are hidden inside Pedersen commitments and their nonnegativity, as well as knowledge of blinding factor, is proved with a rangeproof, while all spent outputs are automatically pruned along with their rangeproof.

Quote
Had Satoshi thought that way payment channels likely wouldn't have been possible
Payment channels are perfectly possible on Mimblewimble despite lacking any scripts, thanks to the magic of scriptless scripts.

I wonder if even on chains like Grin it was possible to store (much) more data than in this experiment
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.

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

[1] https://github.com/NicolasFlamel1/MimbleWimble-Coin-Arbitrary-Data-Storage/blob/master/main.py
Version 1
Scraped on 13/05/2025, 06:40:26 UTC
I wonder if even on chains like Grin it was possible to store (much) more data than in this experiment
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 itextraction 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
Original archived Re: Removing OP_return limits seems like a huge mistake
Scraped on 13/05/2025, 06:35:26 UTC
I wonder if even on chains like Grin it was possible to store (much) more data than in this experiment
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