I think that is one of the novel pieces of functionality that needs to be created. The soon to be dead man looks like any other miner to the network and submits what appears to be valid work, but he is secretly poisoning the work going to release his secret, and of course he has to be the only one capable of doing that. Maybe later on the network realizes the work it was doing was poisoned and rolls back the poison change and resumes processing. Every time a poison pill is introduced the network must do some amount of work to determine that that the pill must be discarded and that amount is tunable by the soon to be dead man.

"What stops the parties from ignoring the messages I send, thus recovering my secret by simply pretending I died?" They would have to control enough of the network and know who you are and how you are interfacing with the network to stop you. If the network has an incentive like bitcoin mining this could be infeasible for many adversaries.

Tampering is a problem with real dead man's switches as well such as a script that you have to ping or an associate.

I think big computational networks with incentives unlock some interesting doors. If you can assume that the computational majority of the network is playing ball you can ask it to do some interesting things if you have the right private key.

""What stops the parties from ignoring the messages I send, thus recovering my secret by simply pretending I died?" They would have to control enough of the network and know who you are and how you are interfacing with the network to stop you."

OK, but if the assumption is that out of the n parties in the network no more than k parties are malicious, why not just use a k+1 out of n secret sharing scheme? You broadcast a signed message once per month, and if the message does not arrive for some number of months the parties all broadcast their shares and recover the secret.

At best, the role of "proof of work" systems here is in combating sybil attacks, which is only relevant if you want to remove the requirement that I know the people I am issuing shares to. If that is truly advantageous, the system might look like this: first, I broadcast a public key for some non-malleable encryption scheme. Each party willing to participate will then use that key to encrypt a randomly generated ID string that they keep secret. Once I have received the IDs, I broadcast a random string, and each party will use their chosen ID and the random string as a "starting point" in a proof-of-work scheme. The output of the proof of work is then used as the seed to generate a keypair for a symmetric cipher (using an appropriate key derivation function). The parties encrypt the proof-of-work outputs and send the ciphertext to me; I check the proofs and generate the keys locally. Then I encrypt each party's share using the party's symmetric key and send the encrypted share. Then I proceed as before, sending a periodic message.

I suspect, though, that such a construction is overkill; also I have not really evaluated the security of it.

"I think big computational networks with incentives unlock some interesting doors"

Maybe so, but right now I see a solution in search of a problem.

"If you can assume that the computational majority"

Why should I need to assume anything about the computational resources about the participants? We can have threshold secret sharing with unconditional security, and we only need to trust one of the parties for the switch to be secure regardless of the computing power of the rest of the parties.

"At best, the role of "proof of work" systems here is in combating sybil attacks, which is only relevant if you want to remove the requirement that I know the people I am issuing shares to."

That seems pretty fundamental to making the mechanism accessible. If are talking about switches as a service if there is a "fixed" pool of switches and an exploit is found that allows you to compromise each switch component you are out of luck because you didn't actually make materializing the secret difficult.

By requiring actual work to be done and allowing the difficulty of the work to be tuned based on the capacity of the network you make an adversary go up against the math instead of against the people.

"If are talking about switches as a service if there is a "fixed" pool of switches and an exploit is found that allows you to compromise each switch component you are out of luck because you didn't actually make materializing the secret difficult."

If an exploit is found that allows you to compromise each component, then the adversary can just have the components ignore your messages and open your secret. It makes no difference how the system is structured at that point.

"By requiring actual work to be done and allowing the difficulty of the work to be tuned based on the capacity of the network you make an adversary go up against the math instead of against the people."

By using a threshold secret sharing scheme, you ensure that the adversary cannot get the secret regardless of the their own computing resources. You also avoid wasting electricity for the sake of your switch. You also have the advantage of having a well-defined security model that can actually be analyzed formally.

The only reason you would ever want to burn through some CPU cycles is to thwart sybil attacks. Unlike Bitcoin, you do not need to keep doing proofs of work after that, because once the shares are distributed, there is nothing more to do. If the adversary increases his computing power after that, he gains nothing by it, because he will not be given any more shares. Hence the suggestion in my previous post: have the proof of work be coupled to the generation of a public key, and just have the public keys be generated when someone needs to set up a switch.

Your proposal is no better than the 3 letter server farm working alone. If the poisoner is not inside the wealthy attacker, then the attacker knowing this scheme is better off not cooperating with anyone, including you.

Even if that were not the case, your scheme relies on your identity being a secret, which essentially is "security through obscurity".

We have to assume that a dedicated attacker knows no greater incentive than breaking the encryption. Anything else is foolish, IMHO.

Edit: clarification

"Your proposal is no better than the 3 letter server farm working alone. If the poisoner is not inside the wealthy attacker, then the attacker knowing this scheme is better off not cooperating with anyone, including you."

Having the attacker be better off alone is the point.

First of all your assuming that the 3 letter server farm is your adversary. This approach has utility even if some adversaries (which don't happen to be yours) might have enough compute power. The approach has utility if it can ratchet up the difficulty enough that the adversary you care about can't trigger early release. It also means you don't have to maintain any infrastructure that is traceable to you. If an attacker can find and disable the switch before it triggers what good does it do you?

Another advantage of this approach is that you can ratchet up the difficulty to the point that the 3 letter server farm can't complete the task in a reasonable amount of time. I suppose there is hard upper bound in the sense that the network is only going to be a few orders of magnitude more powerful than the 3 letter server farm.

Another assumption is that an adversary finding out the secret and releasing it is the worst case. It really depends which adversary right? One thing you are trying to influence is public distribution, and the people with the incentive to apply the compute power may not be the people with an incentive to act on the information by distributing it publicly. The secret is just going to be an encryption key for decrypting the payload you have put out through other means. It's not black and white whether the utility is zero.

In summation, it's a dead man's switch, and the important part is that it fires if you don't do your thing. There are a lot of other desirable attributes, but real world dead man's switches share many of the same flaws.

"Even if that were not the case, your scheme relies on your identity being a secret, which essentially is "security through obscurity"

I don't actually follow why anonymity is necessary. Dead man's switches are usually because you fear you are not or may not remain anonymous. Anonymity is of course a desirable attribute for a lot of reasons, but if it is blown this approach would still work. Only the person possessing the secret key can generate the poison pills that delay the release of the secret.

Tor is an example of ways to attempt anonymity while participating in a network. I view that as a separate problem space.

I think the real competitor would be a switch that actively monitors a piece of state that has plausible deniability, but that runs afoul of the whole running infrastructure traceable to you thing.