If you break one though be careful when redeeming it, there are bots set up to pounce and steal the coins when they are transacted because the reduced entropy makes that possible. You need to submit the transaction to a mining pool that will not broadcast it until it is mined.
thats a poorly implemented reward script, if it leaves you exposed to the mining pool with this gentleman's agreement.
the script could have been designed 2 phase, so one first submits a hash of the solution & submitter address, so even if miners front-run the submitter, they just helpfully pay the transaction fee!
I've recently been working on this exact problem due to my desire to create puzzle challenges for Simplicity, the smart contract programming environment that I work on for my job.
Since Simplicity runs on Bitcoin-like blockchains, someone can swipe the witness data from the legitimate winner's proposed transaction, and create a new transaction (perhaps with a higher fee) using the same claim data and sending the prize to a different address.
Anyway, I ended up implementing a two-phase commit mechanism in which you pay a deposit to temporarily lock the prize so that it can only be paid out to your address. If you then make a valid claim, the prize can be paid to you; if you don't, you forfeit your deposit.
(I think this was suggested by Russell O'Connor, the inventor of Simplicity, but it may have been a widespread idea in the smart contracts world. I don't know whether there's a straightforward way to implement it with Bitcoin Script, which is what this older prize would have needed.)
I don't claim to know the nuance of what you're trying to address with this.
Wouldn't it be simpler to simply protect a bitcoin private key with the encryption that you are challenging people to break?
Off the top of my head, the only downside I can see is that someone could drain the wallet without publishing the key, but people like to brag, so it seems unlikely to be a problem in practice.
That would work if you were only demonstrating encryption or creating challenges related to encryption, but some challenges don't map very easily to a cipher (though you might be able to get them to map to a cipher key).
In Simplicity (and in a sense in Bitcoin Script) there's a broader concept of "if you show you know information X, you're entitled to this money", but it has this specific issue that if the information or the entitlement to receive money for knowing it isn't unique to a specific recipient, there will automatically be a witness swiping or front-running risk for architectural reasons.
I guess it would be "trivial" to have a bounty on each of the future numbers, since you could encrypt a bitcoin private key with it (it would probably make sense to do RSA -> AES key that encodes the BTC private key)
