Hello everybody, figured I'd make a little post so as to not leave everybody in the dark. I've been really busy recently, but I'm still working on the game as much as I can!
(to be clear, nothing in this post is live on proofofwork.gg yet, as everything will come in one major content push):



In addition to lots of bug fixing, I've condensed progress into the following main things:


Address Book and Transaction Fees


The game now has an address book feature that allows you to "generate" and use multiple different addresses, just like the original client did. I was forced to rewrite a little code to make this work, so internally, the foundations for scripting and detailed UTXO simulation have actually been set 

Additionally, block rewards now include transaction fees. Bitcoin's historical fee rates are really interesting to look at, and these trends will definitely be reflected in game. Transaction fees in general aren't really a key focus for me, but I think they'll add some interesting flavour to the gameplay, as you may want to optimise when you broadcast your transactions and the best fee rate for the given transaction (remember to consolidate your outputs, in real life too!  ).



Mining pools
With that done, I'm currently working on mining pools - I found a really neat paper discussing all the popular reward mechanisms that pools use and have used in the past. A big gameplay/story moment is the player's exposure to the first mining pool(s), so I really want to try and get the details right. Expect the ability to pool hop early-game! (until of course, the NPC of the pool you're abusing switches the reward system  )



Tutorial


I've received a lot of feedback regarding this - so the next time you load the game you'll be greeted with a little dialogue, that, if accepted, will guide you through mining your first block, and acquiring your first device. Hopefully this'll make onboarding much smoother!



Progression, Story, and In-Game Forum
I'm using the website http://historyofbitcoin.org for a rough timeline of key story events (like the aforementioned first mining pool launch) as well as the in game market cycles, and everything will hopefully be layered nicely in with the RingNET forum. Writing fake forum posts will take up a lot of time but hopefully I'll be able to get some help from friends and such  . This (alongside mining pools) is really the key thing I want done before I make this version live.

Also, I'll try my best to start writing a sort of overarching narrative that'll see the player getting lore tidbits from the forum, and little side quests and puzzles as I have discussed, though this is definitely on the lower end of the priorities list for now. Same goes for the BIPs and in game "software updates".



Soundtrack and SFX
This is a very long term thing, but a soundtrack is potentially in the works for the game! Once some tracks are done, I'll create a little "Windows Media Player" app where you can turn the tracks on and off, and shuffle through them. The sound effects right now are also rather crude and limited, so expect improvements to this down the line.



Next Steps
For now, I'll continue working towards delivering on all of the above (and more). Once this content release is ready, if there's enough interest in it, I'll work on creating a trailer and a Steam store page, to hopefully try and get more eyes on this project, Bitcoin education, and just Bitcoin in general.

While this started as just a passion project, I’d love to eventually turn it into something sustainable...  I'm thinking after the majority of the game is done (and there is enough content to warrant a price tag), I'll launch it as an "early access" game for maybe around 6-7 USD? (and, naturally, priced fairly according to purchasing power in different regions). For the record, proofofwork.gg isn't going anywhere, and a version of the game will always (to the best of my ability) be freely accessible there, but at some point down the line my content updates will inevitably be more directed to the monetised versions, and the website will stay as more of a "demo" I guess.

Also - a big thank you to whoever sent the ~6,000 sats my way. I didn’t get a message with it, but it really means a lot! 

I think OP probably has good intentions with their project, but maybe hasn't presented or framed it in the best way (gambling issue etc).

At the end of the day, I think trust is the biggest issue, and a game like this is likely (regrettably) better suited to a blockchain with more advanced smart contracting abilities, where management of the pots can be fully trustless and fair.

With regards to the game itself - there is fairly significant input lag that I'm confident is not just me. I'm guessing client inputs are sent to the server and the game is only updated to reflect the server state? You should implement client side prediction and interpolate the client state with the server state, so the player can get immediate feedback for their actions. For such a simple game, it shouldn't be too much of a headache, and it'll make the gameplay feel a lot more smooth 

splitmix32 is just a fast and simple open source 32 bit PRNG. I'm not overly familiar with its inner workings - I do know that 0x9e3779b9 is derived from the golden ratio, e.g., you can derive:

0x9e3779b9 = 2654435769
Φ - 1 ≈ 2654435769 / 2^32

From my understanding, I think the other two constants were chosen empirically to give desirable random properties to the function and don't represent anything in particular.

Still working on the big update - can't really promise a release date for it yet, but hopefully it'll be worth the wait!

But how is this better than a stainless steel or titanium plate? Plates already accomplish what you're attempting to solve and they're significantly simpler and more reliable (especially titanium).
A smaller storage vessel is not necessarily better... The smaller it is, the more fragile it is, and the easier it is to lose.

I think you'll have a hard time convincing people their keys are safer in DNA glass ampoules than they are on a solid piece of metal 

Yep, that function is the core of how "faking" the proof of work hashes is done. Internally, the parameters are essentially bias (the number of leading zeroes), odds, seed. The function will then sample a hash using the seed from a distribution where the expected value of bias is 1/odds. It sounds a little complicated, but you can get a visual idea by using the sample_distribution(bias, odds, n_samples) function that's already in there. For example:



You can see that the number of hashes generated with 10 leading zeroes was 1074/100000, which is roughly 1% (equal to 1/odds) and it has a somewhat realistic/nice overall distribution.  That is what is actually going on when you buy devices and increase your hashrate, the game just tweaks your bias/odds values in such a way that your hashes line up with the hashes you should be generating if you actually had that hashrate.

I haven't tested that, it would take too long  . However, finding a block by it's hash is done by searching downwards from the set of chaintips, meaning if two blocks have the same hash, it'll retrieve the one most recently added to the chain. Theoretically nothing else should actually break since blocks are usually identified by their actual BlockNode object in the JS and not their hash, but I'll have to test it at some point.

Indeed, since the game never allows for more than one coinbase transaction to exist in a block, I didn't place a check to explicitly prevent it. I think it's mostly fine, games like Cookie Clicker are also trivially hackable like this. Cookie Clicker actually has messages that you will see if you open the console, such as the following:


Maybe I'll just add something like that as a light hearted deterrent 

Ah, the genesis coins are unspendable, there was just an off by one error in calculating the block subsidies, e.g. a new coinbase would receive subsidy at height - 1 which caused an extra 50 coins to be created in one of the halvings (I'll add this fix as part of the update later)

I think in an accelerated mini simulation like this, that amount of cumulative chainwork is pretty reasonable. I expect that by its last halving, Bitcoin will probably have an even higher chainwork, so the simulation is probably even a little conservative 

Funny considering the name of the topic 
Jokes aside though, it doesn't have to be an alternative or replacement, I think it's valuable regardless to open the door for more transparency and inclusivity...

I think your idea just circles back to being a one-member one-vote system, except there is disproportionality, some people have plenty of votes and some have very few. I like the idea that this could be a good complementary system alongside merit, making reputation more democratic and giving broader insight from the community (as long as there is some sort of spam control, which I assume Vod has covered when he says it is cheat resistant...), with merit being like a sort of weighted trust from more experienced users.

As much as I love open source software (and I really appreciate your enthusiasm ), I am interested in monetising this game (like on Steam, or through purchase on my website) down the line and so I will keep the code closed source.
That said, you’re totally welcome to peek under the hood, prod through it, read what is there and experiment however you'd like, however, I do respectfully ask that nobody copies, distributes or modifies it.

If I ever decide to open up parts of the project in the future, I’ll be sure to announce it properly.

BIP-42 always makes me laugh every time I read it 
But yeah it won't restart or overflow or do anything funky like that, the code for halvings is pretty simple:

Javascript handles this nicely and block rewards will stay at zero after the last halving. You can verify for yourself by trying it in a JS console:



I'll be releasing a major update sometime soon with more content, alongside that will be saving and other fixes.


Nice! Yeah, it could be good for cheat prevention, my only concern really is overcomplicating my codebase and making it too messy for myself with a bunch of AES blobs and hidden keys. I think you're the only person that is exploring the game to this extent anyway 

I'll give it some thought, but it's probably a future problem.

Yeah fair enough 

Sounds good, I'll have a look once it's ready.

You mentioned sending anonymised traffic to ninjastic, so will board/topic/post reputation scores be visible on his site without needing the extension? Would probably be pretty helpful to mark clearly scam/unhelpful posts that the moderators don't want to remove (for whatever reason). I won't lie, it's pretty silly to me that a place like this doesn't natively have "deMerits" or some sort of downvote feature, so this is pretty cool 

Could you provide instructions (or just a link) for where to find it and how to add it? I can't seem to find it on the chrome extension store.

Would also be good if there's a GitHub where the code can be reviewed and downloaded/added independently (if that's possible).

But there are dozens of these tools that already exist, even ignoring the obvious (Bitcoin Core, Electrum, etc). Generating keys is offline and protocol independent anyway...
Perhaps you could clarify what you mean (are you suggesting making a new wallet software, and not just an HD key generator?), or do a bit more research into this topic 

The first proposal would require some pretty invasive changes to consensus (hard fork), and I'm not sure that the advantages would outweigh the disadvantages. But either way - when block subsidy goes to zero, wouldn't miners be incentivised to fill their blocks? If we assume full or mostly full blocks and a minimum fee rate (e.g. 1 sat/vB), there will still be a baseline predictable block reward.

Sick! But I guess I was wrong about fixing that integer precision bug... The problem is the integers involved in calculating the probability of network finding a block get so big that the fraction loses all precision always equals 0, so basically there is a 0% chance the network can solve a block and progress halts. I've switched it to now use the decimal.js library for high precision fractions, I'll just leave an instance running overnight to check if that fixes it.

Very amusing! Perhaps I should increase the range of seeds to allow for some more creativity. But yes, I do indeed plan on adding functionality to create wallets with mnemonic seed phrases (in-game BIP39 update), brainwallets, stealing funds, all of the above. I really want to emphasise private key storage security as well, e.g., if you click on a strange link, you might get a virus which will steal your keys from storage or memory, so even in the game it's safer to write down your seed phrases in real life, or buy a hardware wallet in the game.


My initial idea, which I temporarily discarded for simplicity, was to have gen_privkey(seed) -> gen_pubkey(privkey), whenever generated, the game will store these keypairs internally. For signatures, I can just write a gen_sig(privkey, data), where in the game's db, each signature is referenced as "belonging" to a private key/data pair.

Since the player is the only entity we need to worry about being able to sign and spend transactions, OP_CHECKSIG could be as simple as "what private key was this signature generated from, is the data correct, and does that private key generate the public key". From an educational/realism standpoint, I think it would fake ECDSA well enough  Cheating isn't really something I'll bother to do anything about right now, it's a singleplayer game and really it's the player's choice if they want to cheat etc. In a multiplayer setting, you would obviously have to use actual cryptography libraries, but I can keep it simpler for now.

That's really strange... no, that is not intentional, if you get it right (and enter it in the SATMiner console) it should show up as legible text, not unicode garbage.
If you get it wrong, it should not output anything, it should throw an error along the lines of an "Operation failure. I guess it depends on what browser you're using - if you maybe want to PM with your browser and the command that you tried, I'll try to see if I can recreate it and find out what the problem is.

Just a heads up though, the first secret is just a stupid in-joke between me and some of my friends  I'll add a lot more actually interesting secrets down the line.

From a mechanical-design standpoint, Bitcoin is almost objectively the most superior store of value asset that has ever existed, and for the majority of people, that is the best use of it.

Unless you actually know what you're doing with trading and all of that, I think the best advice to give a newbie is to treat BTC like an on-the-side "savings account" of sorts... If you can ignore the short term volatility and just DCA (stack those sats), over the long term, basic economics is in your favour, a fundamentally deflationary asset will always beat inflationary currencies. Unless there is a devastating collective loss of trust in bitcoin (watch out for those patoshi coins moving when quantum is a problem), demand will likely continue to grow and this idea will hold.

As many have said, patience is key. It's hard to be patient... but large scale global Bitcoin adoption is an incredibly long term process. Even starting now, if you consistently save and accumulate over the next 10-20 years, I think the prospects are very strong (other SoV capital flows into BTC). Generally speaking as well, stacking sats can make huge price dips a lot easier to ride out, rather than trying to time the market and "double your money" 

Yep, I suppose that's a natural console "exploit" as is tradition with all javascript games  . I figured that since all the other network participants are "fake" I'd just have all coins not mined by the player sent to and kept in a single address, to be used for the exchange and other purposes down the line.

It'd be funny, but I think it would break immersion a little 

Network hash rate (and thus difficulty) doesn't always grow exponentially - it's actually a function of the market price. So, the same way the maximum market price is definitively capped, it crashes, and doesn't grow forever, it's the same deal with NHR, unless I misunderstand what you mean. The difficulty is also adjusted by block time over the adjustment interval, same way as bitcoin, so it can never get "too hard" and make blocks impossible unless there is a gigantic hash rate drop, which should never happen.

Theoretically yes, if it doubled 256 times, but as I addressed above, this will guaranteed never happen in the scope of the game because the hash rate simply cannot reach that high, not even close 

Being explicit is key  The AI can't see inside your brain, so even if something seems super obvious, it is still your job as the prompter to provide clear instructions with as much detail as possible for the best results.

As I mentioned in a previous response, vibe coding projects is not the way to go! Use LLMs to teach you concepts, write pseudocode, and at most, implement helper functions, or functions with well defined purposes. Trust me, you'll generally get nowhere by asking GPT/DS/Claude/etc to create an entire project for you from a single prompt (even with plenty of context), you'll eventually hit a roadblock, or you'll be stuck with a bunch of issues that are a pain in the ass to resolve.

In my humble opinion, AI should be more of a learning tool. The same way we used to use google searches to learn and solve problems, rather than copying chunks of people's code and frankensteining it all together 
AI is like an infinitely better google search, so I would treat it as just that.

This is just a style convention thing, not an error. But ChatGPT has the same problem... My guess is that for simple functions like this, LLMs pick up patterns from older codebases, and since many legacy projects used Hungarian notation, that is what DeepSeek or GPT will use. If, in your prompt, you explicitly specify something along the lines of "always follow Microsoft's C# guidelines", it will not make these types of mistakes.

Yeah there was an integer precision bug before I added the pre mining. If you refresh the page it should be fixed, you can pre mine the same number of blocks or more to verify (or wait, but it's the same thing).