Quote

there is a 0% chance the network can solve a block and progress halts

It seems, that it was not the case. My instance was still running in the background, and successfully reached block number 11762, without your fixes (I guess JavaScript is not reloaded, as long as I won't press F5).

Also, as you can see, I have a minority fork with 11616 blocks. Which means, that there are two chains: one is made by the original network with 371.10 ZH/s, and another one is made only by me, with 7.00 MH/s. It is based on the same Genesis Block, as it was the case in the original Gavin's testnet, before it was changed.

My plan is to see, if the official network can halt. I also wonder, if your chain is compatible with BIP-42: https://github.com/bitcoin/bips/blob/master/bip-0042.mediawiki

Because in the original code, after 64 halvings, the network started again with 50 coins. It was fixed by BIP-42, and I wonder, how your network will behave after 64th halving, and even if it can reach it without halting.

Also, I think some kind of "save" button will be needed, sooner or later, because then, it would be easier to restore the state of the network. Another feature I think about is "pruning". Because currently, everything lives in a memory. And if I could save some blocks on disk, and detach it from RAM, then it could be possible to test thousands of blocks, without killing my browser. Or even: pruning alone, without saving things, is also an option, to test some edge cases, like "no new nodes can join, because nobody has the full history anymore, and everyone switched to pruning".

The current chainwork:

Code:

user@st> block 00000000000000000000a1c6fddb84ce51cda1186b4efe949f72ded94e38c281
{
  "version": 1,
  "hash": "00000000000000000000a1c6fddb84ce51cda1186b4efe949f72ded94e38c281",
  "height": 11762,
  "confirmations": 2,
  "time": 1231186150,
  "prev_hash": "00000000000000000000d3e5efaa387c7c80b2d99b8696c50779e5232cd92878",
  "chain_work": "000000000000000000000000000000000000000014ba9dcdc41f70d3d7b2c841",
  "target": "167c01e4",
  "nonce": 914465626,
  "merkle_root": "67739709a23396660cb932a84d7691ae4a0f17318fadbb2e7b7102fadf33a3d3"
}

And some minor UI things: when the price per coin is around 2.7 million dollars, it is no longer fully visible in charts. Also, charts seems to be in the future, because I have transactions from Jan 5, while I can see Jan 7 on the exchange.

Edit: Custom secrets unlocked:

Code:

await encrypt_aes("<comment>stwenhao: Now I can make my own secrets!</comment>",await sha256('stwenhao'))
Array(75) [ 70, 226, 192, 193, 39, 154, 126, 71, 112, 129, ... ]
SECRETS.push([70,226,192,193,39,154,126,71,112,129,180,132,226,181,21,137,229,145,196,116,207,60,99,201,27,15,156,229,195,221,255,63,152,11,214,145,7,230,61,174,176,26,247,180,212,249,188,143,62,154,81,6,149,67,20,3,206,65,53,12,4,33,55,22,101,172,225,215,174,117,33,23,243,215,97])

And now, I can see this:

Code:

user@st> stwenhao
stwenhao: Now I can make my own secrets!

Which means, that users can also use "encrypt_aes" and "decrypt_aes" for encrypting and decrypting messages. And I guess, as long as everything is single player, you can just use things like that for any kind of encryption, including for example transaction signatures. Also, I guess if you will implement forum and private messages, then such things can be useful, to hide some things from the player, until they will appear in the story.

Edit: Maybe guessing 32-bit seed will be too hard for the beginning. I guess I should port transaction puzzle instead. Let's see, how it could look like:

Code:

+------------+------------+------------------------------------+
| seed_begin | seed_end | address |
+------------+------------+------------------------------------+
| 0x00000001 | 0x00000001 | 1N5ph9XYotdbe8sfN7ReiRetS5bxNXcoGP |
| 0x00000002 | 0x00000003 | 1ZyLAQj2QmX77eV8E6iMj1SbJBqPTQWEPr |
| 0x00000004 | 0x00000007 | 1tyBPPrDRy9hi9NpHJj9A1Ssbkm8R2GHwq |
| 0x00000008 | 0x0000000f | 1rWXov7oBpZKeCRcMfF33Zi3iZw7za5Hn4 |
| 0x00000010 | 0x0000001f | 1JkAcYfowVaDwuVSLMRaZjGeEkWP13cx1U |
| 0x00000020 | 0x0000003f | 1XjB3sq2LSeX1bVoJ9wKaYamvthS2928Ti |
| 0x00000040 | 0x0000007f | 1kBDm7yR84BFBeWij8BfL2PdKJmHCwvL8Z |
| 0x00000080 | 0x000000ff | 1J5y3bkPJEARRJBpTnryyhBj1dwXxDvi9a |
| 0x00000100 | 0x000001ff | 1DJ6SLJfx4qYifQpjMx8BPRBMw6tm1Xzhs |
| 0x00000200 | 0x000003ff | 1H1fCVxu2fdvDjwHmcMMNkWbUf2pcUy3UN |
| 0x00000400 | 0x000007ff | 1BXCT9ci4dF1CAFj2kivAzKQftQpsFALgq |
| 0x00000800 | 0x00000fff | 1SRsoeBP3Ri8ucFLCSt6BW5XGNVx5K52hQ |
| 0x00001000 | 0x00001fff | 1Kx2MoiqwVB2x9o9Gd37CEM7CDcR4kmnT7 |
| 0x00002000 | 0x00003fff | 12xzLssaWbC6M4kN1K5FiDrZ4HwZr3jwwp |
| 0x00004000 | 0x00007fff | 1vG4NpboHxnf35m26Tbtymjf9yYj17nACi |
| 0x00008000 | 0x0000ffff | 17hMrgdaoKaY5uxe1g8nt2McEsW8jNE8MA |
| 0x00010000 | 0x0001ffff | 1otHenypTcx8vVSAwmjcTCnYQxFhM38P95 |
| 0x00020000 | 0x0003ffff | 1kcBgCBzpSJCme3fY38RWM3DLtwKQszfHT |
| 0x00040000 | 0x0007ffff | 17cQRgb8PLFPh6gyiYkwQjwsfx9UCBVjnE |
| 0x00080000 | 0x000fffff | 1zTYApoFF6gEnQjBV6b9UztrHzCGdXMq2K |
| 0x00100000 | 0x001fffff | 1acAk4rwZbE1kQdcTSK55hAKBgYCDP1zLT |
| 0x00200000 | 0x003fffff | 1VptmU7QQppbjEL3LnWR7W54NuXjSRBfzi |
| 0x00400000 | 0x007fffff | 1ZnT2Z8eB3TVgFbbAQHHxuQDAmbD6aPKwv |
| 0x00800000 | 0x00ffffff | 1nAh5FvaEB93CYAQDmjri63ikNH3bggGgY |
| 0x01000000 | 0x01ffffff | 1sb4iLCiF2sezeHicpy2SSJArLP1HCeZ1L |
| 0x02000000 | 0x03ffffff | 1eUvspVKYNe41u8f1D56wRybk98z5DAzxM |
| 0x04000000 | 0x07ffffff | 1z73ewKCxNxPrXqcfNM5b9BReXMXPU7Wm1 |
| 0x08000000 | 0x0fffffff | 1tUzhqwCRZ7WQbe6a359fYVZmpYQjDv3P7 |
| 0x10000000 | 0x1fffffff | 1RXgMtz6hYGYJNrySueYBfZPaUhn4ieMHc |
| 0x20000000 | 0x3fffffff | 1L1wNzycsdKSnZGdB97Ri4YxE7dAeqJNTA |
| 0x40000000 | 0x7fffffff | 1QD852RQMrky4YhSZ8ZYVuHWB1yMC6RQgN |
| 0x80000000 | 0xffffffff | 1uTiu8DSPLvapKe4boQcH3aWJVzJfwRKB4 |
+------------+------------+------------------------------------+

And then, I wonder, what should be done with 1PrgVmwXevXBVbWhwfjeKMEUtxCi3sqLL6, which is generated from zero seed. In ECDSA, valid private keys are in range from 1 to N-1, where N is a 256-bit prime in secp256k1, so here it should be probably some 32-bit prime.