Watchtowers may not work in Plasma (Cash)


#1

I recently realized that the kind of watchtowers supported in Lightning may not be fully possible in Plasma Cash. (I believe this is true of classic Plasma and Plasma MVP as well; this fact may be well-known in those contexts, so apologies if this is trivial).

Watchtowers are entities to which a user can outsource the task of watching the chain and challenging invalid attempted withdrawals.

While Plasma Cash would support watchtowers that challenge attempted withdrawals of spent coins—since, if the user is cooperating with them, they will be aware of subsequent state that invalidates the prior state—they cannot always challenge attempted withdrawals of coins with invalid histories (as can occur if a Plasma Cash chain operator is malicious). If they tried, a Plasma Cash chain operator and user could collaborate to defraud the watchtower (by withholding blocks to prevent the watchtower from determining whether the attempted withdrawal is valid or not).

Watchtowers can still ping users to notify them that there is an attempted withdrawal. However, this still requires the user to be online. Additionally, there is no way to prove that such a notification was or was not sent, so there is no way to punish the watchtower for misbehavior.

The best solution I can see would be to require the watchtower to effectively bear the risk of operator misbehavior, by promising to challenge any invalid withdrawals (and therefore relying on the Plasma Cash operator not to misbehave).


#2

The user could contract with the watchtower to challenge with specific coins. Then if the specific coins become invalid challenges, the watchtower doesn’t get penalized


#3

You can’t update your on-chain contract with them every tx, though. Otherwise the Plasma chain gives you no scalability advantage. And I think it’s at least difficult, maybe impossible, to atomically update your off-chain watchtower contract with your plasma coin in a way that doesn’t give the watchtower any power over when and how you can spend.


#4

Your contract with them should be in a state channel so there’s no onchain transaction to update it


#5

The latency bounds on that state channel might cause a problem, though… right? What if the watchtower ceases to respond to me? Am I blocked from safely transacting on the Plasma Cash chain until I close that state channel?

That’s not necessarily that bad (it doesn’t let the watchtower do anything to me that the Plasma Cash chain operator can’t do already). And maybe you can set up the state channel so it isn’t a problem…


#6

I’m actually not sure exactly how lightning watchtowers work…what recourse do users have if all watchtowers try their hardest not to interact with a user?

Am I blocked from safely transacting on the Plasma Cash chain until I close that state channel?

It seems to me that it is always safe to transact, but if you can’t get access to watchtower-type services then it is no longer safe to log off (ie stop monitoring the chain for a period longer than the plasma dispute timeout). If you do need to log off, in the worst case you can withdraw your coins.

Here are two (very suboptimal) schemes that analyze the related question “am I blocked from safely logging off while keeping my coins on the plasma chain” in different ways. In both schemes, a plasma chain user opens state channels with multiple watchtower service providers (WSP), and for concreteness, exits do not put up any bond/deposit, and we use the leftmost unspent CFCR. Depending on how exit deposits are constructed other schemes are possible, but I will not discuss those.

Scheme 1: A user normally has no contract with any WSP, but right before logging off, he tries to enter a contract with every WSP. The contract specifies c, which is the coin the user claims is the latest coin. The WSP puts up a bond which can be returned after some specified amount of time. While the bond is in effect, however, the contract allows the user to claim the bond by showing that all the following happened:

  1. a coin c' with was exited
  2. c' and c have the same coin id
  3. c' has a higher block number than c
  4. the exit did not have a challenge from c

note that in the event that some attempted exit satisfying (1)-(3) happens, the WSP can keep his bond safe just be challenging it with c, even if that challenge fails. Call these contracts type 1 contracts.

Scheme 2: Same as scheme 1, but the user has an additional existing contract with the WSPs (set up long ago) that the WSP must enter type 1 contracts.

Analysis

In scheme 1, the user can log off without exiting if at least one WSP enters a contract. If all WSPs don’t enter into a contract, the user cannot do so.

In scheme 2, the user can log off without exiting if at least one WSP enters a contract. If all WSPs don’t enter into a contract, the user has to enforce his right to enter type 1 contracts on-chain, which requires paying transaction fees and waiting out the state channel timeout period.