Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify registration receipts #208

Open
sr-gi opened this issue Mar 24, 2023 · 0 comments
Open

Unify registration receipts #208

sr-gi opened this issue Mar 24, 2023 · 0 comments
Labels
cln-plugin Stuff related to watchtower-plugin

Comments

@sr-gi
Copy link
Member

sr-gi commented Mar 24, 2023

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]

 |------------------|---------------------|
S1s	           S1e                   S2e
         S1		      S2 

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.

@sr-gi sr-gi added the cln-plugin Stuff related to watchtower-plugin label Mar 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cln-plugin Stuff related to watchtower-plugin
Projects
None yet
Development

No branches or pull requests

1 participant