Registration receipts were unified on the tower side when a subscription was renewed by the user as long as no gap existed between the original subscription and the renewal (#77). This allows for minimizing the storage of registration receipts while being able to prove misbehavior. However, looks like this was never implemented for the watchtower-plugin, we should fix that.
Rationale
In order to prove misbehavior, a user needs a registration receipt covering a given period (S), and an appointment receipt (A) for a channel breach that was triggered within the subscription period but not responded by the tower, that is:
Given S=[s, e], and A.start_block = t, then
s <= t <= e.
Making it work with subscription renewals
Imagine we have two chained subscriptions such that the end of the first is the beginning of the second: S1=[S1s, S1e] and S2=[S1e, S2e]
We could represent this as S2'=[S1s, S2e] and store a single registration receipt for the whole range and still be able to prove misbehavior. However, this only applies if there is no gap between the subscriptions, otherwise, the client would be able to trick the tower.
|------------------| GAP |---------------------|
S1s S1e S2s S2e
S1 S2
If there is a gap between S1 and S2 and we batch both subscriptions, the user could create an appointment A and send it to the tower during S1, then wait until S1e and trigger A for which the tower will have no data to react to (it was whipped after S1e), later on, it could request a second subscription S2 and claim the tower didn't react to A.
Therefore, the misbehaving proof should include registration receipts from A's start_block to the block the breach was not penalized (without gaps). If the user does not interrupt the subscription, then the tower can simply batch the receipts and both will only need to store a single one.
Registration receipts were unified on the tower side when a subscription was renewed by the user as long as no gap existed between the original subscription and the renewal (#77). This allows for minimizing the storage of registration receipts while being able to prove misbehavior. However, looks like this was never implemented for the
watchtower-plugin, we should fix that.Rationale
In order to prove misbehavior, a user needs a registration receipt covering a given period (
S), and an appointment receipt (A) for a channel breach that was triggered within the subscription period but not responded by the tower, that is:Given
S=[s, e], andA.start_block = t, thens <= t <= e.Making it work with subscription renewals
Imagine we have two chained subscriptions such that the end of the first is the beginning of the second:
S1=[S1s, S1e]andS2=[S1e, S2e]We could represent this as
S2'=[S1s, S2e]and store a single registration receipt for the whole range and still be able to prove misbehavior. However, this only applies if there is no gap between the subscriptions, otherwise, the client would be able to trick the tower.If there is a gap between
S1andS2and we batch both subscriptions, the user could create an appointmentAand send it to the tower duringS1, then wait untilS1eand triggerAfor which the tower will have no data to react to (it was whipped afterS1e), later on, it could request a second subscriptionS2and claim the tower didn't react toA.Therefore, the misbehaving proof should include registration receipts from
A'sstart_blockto the block the breach was not penalized (without gaps). If the user does not interrupt the subscription, then the tower can simply batch the receipts and both will only need to store a single one.