Just a thought:

Ideally a miner is lurking here with a decent hashpower (lets say minimum finding a block every day) and is willing to facilitate this transaction. Feel free to define your terms and how to hand over the transaction safely.

I am sure there are ways for the miner here to prove his authenticity of hashpower control (e.g. by including a community defined text in one of the coinbase OP_RETURNs of one of his mined blocks and announcing it here before it happens).

There is no need for 100% probability. The miner just has to include the transaction in the candidate block manually and mine along with the other transactions from the mempool just as normal. If he wins, broadcast and it will get confirmations, no danger for the attack any more. If he not wins the block, no problem, just try again with the next block. Just never broadcast the transaction to other nodes mempool until its mined.
I would think a high fee for this semi-manual service (say 1 BTC) might be enough incentive?

Am I missing something here?

Absolutely, thats why I posted it.

In my opinion any other method than "shadow mining" has a too high risk of going wrong:

• Broadcast at low-traffic times: You don't know when the next block will be mined. Could be seconds or minutes away (which would give enough time for the attack).
• Set the "do not RBF": You don't know if the miners will honor this field or not. It also does not help against an attacker simply inserting a double spend transaction.
• Double spend risk: It seems every miner uses its own metric to determine the valid transaction. Based on fee will end up in a bidding war. Based on timestamp can work but you don't know which metric the miner will use.

So just making a "normal" transaction is much too high risk and I think everyone working on this puzzle should be very aware of that and have a solid plan in case of winning the lottery!

From what we know on the "public key sniping" issue so far any my understanding is:

• Revealing the public key in the mempool immeadiately sets of a double spending attack by the sharks - depending on miners rules they might or might not adhere to RBF or first timestamp ordering and might just accept the higher fee -> never reveal the pubkey in the mempool and work out a private deal with a miner to "shadow-mine" this transaction is the only safe way.
• Revealing a signature to prove I own the private key is also unsecure -> communication channel with miner needs to be secure and miner needs to be trusted not to use the same attack vector as the sharks as soon as I send the private transaction to them
  

Under these assumptions, my game plan would be:

1. Create a post here in the forum containing:
- SHA256 hash of the private key along with my target address where I intend to send the coins to.
- SHA256 hash of a message containing a text stating my intention to send the coins to my adress along with the miner name I intend to work with.
Ask the forum to cite this post to avoid edibility and prove of time stamp.

2. Contact the miner and work out a deal to shadow-mine and include the transaction in a block without broadcast. Set an appropriatly high fee depending on the deal. There is trust required here that the miner does not act malicious (possibly via a 3rd party), however the miner name is included in the SHA256 hased message in this forum. I will notify the miner that I will reveal the message for everyone to verify via the hash in case the miner does not stick to the agreement. This is not a safeguard to revert the transaction or anything, but hopefully will prevent the miner from acting malicious in order to preserve reputation.

3. Send the transaction details to the miner.

4. Hope for the best. If everything goes well, no need to reveal the message. The name of the miner is known then anyway.

Makes sense?