Ah, that makes more sense. Could cache every 4000th hash, and the next 4000 hashes, so you don’t have to recalculate all 5M hashes everytime you run out of cached hashes. Would only be ~20k hashes (640kB) to cache even for the 1000 year case then, and you could save them to disk or precalculate at compile-time.
Yeah, gotta have a marketing plan to build up lots of drama/excitement if you want attention in the NFT/memecoin space. As far as I’m aware, it never even got mentioned in any of the tech spaces I follow (eg bitcoin-dev, optech). OTOH, I expect I would have ignored anything I did see though, since that was around the time of the inv-to-send issue. Shame.
Two things that would probably be interesting, but also perhaps much harder than what you did: a spacechain that includes actual new programming features (simplicity? EVM like RSK? confidential txs? multiple fungible assets? utreexo commitments?), and/or a spacechain with a currency that’s pegged against sBTC in some way (even a boring trusted third-party way like RKS’s or liquid’s multisig federation or whatever WBTC does), so the chain could theoretically help with “overflow txs” during fee spikes. But those are probably hard to do, and it’s better to be simple but implemented than fancy but imaginary.
Maybe utreexo commitments could be interesting for NFTs – you could have short proofs that you “own” your profile picture NFT; though having the proof potentially change every block might be too awkward in practice… I guess you’d need some way to link the things you mint to some other data though; atm I think soma just lets you create a token that’s tradeable but has no link to anything else? Reverse commitments, where the data links to the token (instead of the token containing/committing to the data) might work fine with soma as-is though, though then you’d also need to add an O(n_transfers)
-size proof that your utxo matches the token… a spacechain with a chia-esque coin-set model instead of a utxo model could let you avoid that, though…
How reliable spacechains are in adversarial environments is a big question to me; will people actually fully validate spacechains, or is there a risk that you can just pay to mine lots of “invalid” spacechain blocks and that will be accepted anyway? How easy/disruptive are reorgs – if you can reorg some blocks, doublespend one transaction, but nobody else loses out (because there’s no coinbase fees), will anyone try to prevent the reorg, or is the person being doublespent on their own? Could be fun to explore that sort of thing with a real implementation.
That’s probably similar to the actual usage of the powcoins script, fwiw. Also comparable to bitcoin itself, really; ignoring coinbase txs, there were only 93 txs in its first 3 months (10570 blocks). Sometimes you just have to give these things time.
Yeah, “Nothing Up My Sleeve” – ie, “it’s completely/cryptographically infeasible for me to possibly have a private key/preimage/etc corresponding to this”.
Sounds a bit complicated for an experiment tbh; though I see you setup a thing to auto pay people’s invoices for them anyway. I think I can see how you could plausibly build up a reputation as a trustworthy miner for people to be willing to go through that process with non-fake coins. Neat.
If you do, I’d suggest trying to make something that you can just leave running unattended for ages, and ideally that automatically includes some spacechain content occassionally, even if it’s trivial. Automatically dumping the block data into a github repo once a week might be workable? If the explorer could make static html pages that could also go into the github repo that would maybe be nice, as a low overhead way of making it still explorable even if you don’t want to keep actually maintaining/running the servers?