Hi Tom,
Blind signatures are certainly a nice feature, great to see that you're considering it.
>So each new owner of a UTXO must receive, store and verify the full sequence of previous owner backup transactions to make sure that no previous owner has asked the SE to sign a transaction that could be used to steal the UTXO. This may end up making wallets more bloated and clunky, given that ownership of a UTXO could change hands thousands of times off-chain.
Users would have to validate the history of the chain regardless, even if it wasn't blind, to verify whether the statechain entity hasn't been cheating, so the main difference would be in unblinding the data.
One of my original ideas was to use the transitory key to derive the secrets that blind the signatures (basically like an HD wallet). The statechain entity would then store and serve blind signatures, and any new owner would download and unblind/verify them using the transitory key (no extensive peer-to-peer transfer needed). It's possible to make the off-chain transactions themselves deterministic, so they can just be generated by the client without any additional data transfer. The only potentially unique thing in a transaction is the refund address, but this can be the same key as the ownership key on the statechain, tweaked with the transitory key via Diffie-Hellman (to ensure it's not linkable if it goes on-chain).
The general downside of this method is that all transactions are exposed to anyone who learns the transitory key -- not just for the current transactions (which can always be leaked no matter what you do), but also all future transactions in that particular statechain. However, I should note there doesn't actually seem to be much to learn, because the history of each statechain is actually quite uninformative. The money just goes from one pseudonymous owner to the next.
Of course you now have scheme that changes the transitory key with each step, so I instead suggest you introduce a secondary "blinding key" to achieve what I described.
I'm not sure whether this can also apply to 2P-ECDSA, but with Schnorr the statechain entity wouldn't even learn the address for the funding transaction, so it wouldn't be able to tell which UTXO it controls by watching the blockchain. Ideally, this functionality would be preserved to ensure the statechain entity can't be aware of the funds it's holding.
Another thing to note is that you won't know when a statechain has been pegged out, so pruning will be impossible. You may wish to consider some kind of liveness rule where one statechain transaction needs to be made per year. If they miss the deadline, they're just forced on-chain, which is not terrible, in any case.
Hope this helps!
Cheers,
Ruben