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!
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.
https://community.simplicity-lang.org/t/running-prize-contes...
(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.)
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>
With taproot (P2TR), scripts are optional, and outputs can be based solely on Schnorr signatures.
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)