Yep, this could be an interesting optimization. I’d be very curious to see what kind of participation checkpoints have! My guess was we’d actually see pretty limited participation.
I be interested in learning how you sync up those delay periods. As we have developed offline mobile payment solutions based on Raiden, though like any development works, it’s forever improving and problem solving.
I think there is a slight change in assumptions. With Plasma MVP, the user can delegate the task of watching the chain and initiating withdrawals to someone else, so the user does not actually have to be online regularly. The delegate could grief the user by initiating unnecessary withdrawals, or could fail to do their job, but could not steal the user’s coins.
In Plasma XT, it seems like a user could not delegate the checkpointing task while they are offline to an untrusted entity, because they would have to provide their private key to that entity for the purpose of signing off on checkpoints.
Do you see a solution that would enable checkpoints to be made while the user is offline, or would they just have to allow the coin history to grow and then make a new checkpoint when they do eventually come online?
I would agree that there is a change of assumptions w.r.t Plasma MVP. I don’t believe that this changes any assumptions w.r.t Plasma Cash, particularly because of the discussion here: Watchtowers may not work in Plasma (Cash).
Although I think it’s probably fine for a first implementation if users have to be online, it would definitely be very useful for users to be able to outsource this. I haven’t thought about it a lot - one solution off the top of my head would be for users to make an on-chain transaction that somehow specifies a third party that can sign off on the checkpoint instead. This would basically look like a 2of2 multisig with a special key (for the third party) that can sign off alone. The third party could then be sure that they haven’t signed off and challenge whenever they see a false positive.
Of course, this means that the third party could temporarily grief the user by refusing to sign the signature. Maybe this isn’t the worst thing if users can easily submit another transaction changing their third party provider.
If the user is able to unilaterally change their checkpointer on the Plasma chain, I don’t think the checkpointer can safely challenge a checkpoint, since the user could have maliciously changed their checkpointer (assuming as we always do that the operator is working against them and making data unavailable). So you need to give the checkpointer the ability to veto (though you could still retain sole authority to withdraw the coin).
Also, note that what you’re describing is a solution for outsourcing challenging of checkpoints, rather than outsourcing of checkpointing. I agree that the former is more important (because checkpointing is optional and if you have some time you could always do it before you plan to spend the coin, in order to reduce the proof you have to transfer). I’m not really sure the latter is possible, because for them to sign off on an unavailable checkpoint would be an unattributable fault.