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.)
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.
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.
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.