Thanks for all of the input and comments - I do now think that the decrementing nSequence relative locktime backup system with kick-off transaction is the way to go, including a fee penalty via CPFP to disincentivise DoS, as suggested. 
I have started a more detailed document specifying the proposed protocol in more detail: https://github.com/commerceblock/mercury/blob/master/statechains.md which includes improvements to the transfer mechanism (and an explanation of how this can be used to transfer/novate positions in DLCs). Always happy to get more feedback or PRs. 

Tom

On Tue, Mar 31, 2020 at 12:41 PM Tom Trevethan <tom@commerceblock.com> wrote:
Hi David,

Just for clarity, I left nChain over 2 years ago (having worked there since 2016). While there, I (along with other researchers) were given free rein to work on any ideas we wanted to. I had been interested in the scaling of Bitcoin off-chain, and this was one of several things I spent time on (including things like sidechains, pegs and threshold signatures). This patent application came out of an idea I had to transfer ownership of UTXOs off-chain that has some similarities to the statechains proposal, which has shown there is interest and demand for this type of system. 

Although I think the existence of this application is something to be mindful of, there are several important things to note:

1. Although there are similarities, the current ideas are significantly different to those in the application. 
2. The key transfer protocol as described in the application is not secure (for several reasons, including as discussed above, by Albert and Bob etc.) - and a different mechanism is required. 
3. Decrementing timelocks (as suggested in the application) are prior art (Decker-Wattenhofer 2015), and in any case any implementation will most likely use an 'invalidation tree' relative locktime backup mechanism for open-ended UTXOs. 
4. The patent application has not been granted (it was made in May 2017) and the international search report rejected it on the grounds of prior art. 

Tom

On Tue, Mar 31, 2020 at 11:36 AM David A. Harding <dave@dtrt.org> wrote:
On Wed, Mar 25, 2020 at 01:52:10PM +0000, Tom Trevethan via bitcoin-dev wrote:
> Hi all,
>
> We are starting to work on an implementation of the statechains concept (
> https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39),
>
> [...]
> There are two main modifications we are looking at:
> [...]
>
> 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE key
> and transitory key) with a single P2(W)PKH output where the public key
> shared between the SE and the current owner. The SE and the current owner
> can then sign with a 2-of-2 ECDSA MPC.

Dr. Trevethan,

Would you be able to explain how your proposal to use statechains with
2P-ECDSA relates to your patent assigned to nChain Holdings for "Secure
off-chain blockchain transactions"?[1] 

    [1] https://patents.google.com/patent/US20200074464A1

Here are some excerpts from the application that caught my attention in
the context of statechains in general and your proposal to this list in
particular:

> an exchange platform that is trusted to implement and operate the
> transaction protocol, without requiring an on-chain transaction. The
> off-chain transactions enable one computer system to generate multiple
> transactions that are recordable to a blockchain in different
> circumstances
>
> [...]
>
> at least some of the off-chain transactions are valid for recording on
> the blockchain even in the event of a catastrophic failure of the
> exchange (e.g., exchange going permanently off-line or loosing key
> shares).
>
> [...]
>
> there may be provided a computer readable storage medium including a
> two-party elliptic curve digital signature algorithm (two-party ECDSA)
> script comprising computer executable instructions which, when
> executed, configure a processor to perform functions of a two-party
> elliptic curve digital signature algorithm described herein.
>
> [...]
>
> In this instance the malicious actor would then also have to collude
> with a previous owner of the funds to recreate the full key. Because
> an attack requires either the simultaneous theft of both exchange and
> depositor keys or collusion with previous legitimate owners of funds,
> the opportunities for a malicious attacker to compromise the exchange
> platform are limited.

Thank you,

-Dave