This is an interesting idea. There are some similarities with the secondary-key, time-locked "Vault" proposal for handling key-theft of Möser, Eyal, Sirer:
(There's also a slight similarity to the 'Fomo3D' blockchain game, where someone who can manage to be 'last to act' can win a large pot.)
Practically, the need to stay aware of challenges, and answer them, introduces some new costs & risks. For example:
* A user might want to have a bit of sentinel software watching-for & responding to challenges, to lower the burden on their attention/time. But then that sentinel itself becomes a regularly-online, potentially-compromisable key location. And, an attacker who can force a sentinel-outage may be able to sneak away with funds via a timely challenge.
* A user who has a secure, offline key might nonetheless have their online systems temporarily compromised by an attacker. A challenge procedure could then prompt the target to move their offline key onto a compromised system, to answer the challenge, but then lose funds that otherwise were not at risk.
That said, there might still be situations where these concerns are acceptable, perhaps in combination with further refinements (along the lines of the `Vault` idea or other tuned tradeoffs between things like amounts, timing, and number of involved keys).
A bit more darkly, I know you've more-or-less ruled out security against physical attack as a goal, but it strikes me that this system may offer an edge to attackers who can precisely time their ability to kidnap/incapacitate/kill a target. By knowing first, and exactly when, a target won't be able to respond to a challenge, the attacker can be first to claim the unprotected funds. This timing-based aspect has some similarities to the old idea of "assassination markets", where being able to precisely time a death is what lets an anonymous perpetrator collect a bounty. See:
http://hackingdistributed.com/2016/02/26/how-to-implement-se...
(There's also a slight similarity to the 'Fomo3D' blockchain game, where someone who can manage to be 'last to act' can win a large pot.)
Practically, the need to stay aware of challenges, and answer them, introduces some new costs & risks. For example:
* A user might want to have a bit of sentinel software watching-for & responding to challenges, to lower the burden on their attention/time. But then that sentinel itself becomes a regularly-online, potentially-compromisable key location. And, an attacker who can force a sentinel-outage may be able to sneak away with funds via a timely challenge.
* A user who has a secure, offline key might nonetheless have their online systems temporarily compromised by an attacker. A challenge procedure could then prompt the target to move their offline key onto a compromised system, to answer the challenge, but then lose funds that otherwise were not at risk.
That said, there might still be situations where these concerns are acceptable, perhaps in combination with further refinements (along the lines of the `Vault` idea or other tuned tradeoffs between things like amounts, timing, and number of involved keys).
A bit more darkly, I know you've more-or-less ruled out security against physical attack as a goal, but it strikes me that this system may offer an edge to attackers who can precisely time their ability to kidnap/incapacitate/kill a target. By knowing first, and exactly when, a target won't be able to respond to a challenge, the attacker can be first to claim the unprotected funds. This timing-based aspect has some similarities to the old idea of "assassination markets", where being able to precisely time a death is what lets an anonymous perpetrator collect a bounty. See:
https://en.wikipedia.org/wiki/Assassination_market