Delete appointment may introduce DoS attack vectors

[sr-gi]

In the current version of BOLT13, appointment deletion can be requested by the user in order to free slots that may match an already closed channel. Given a user has a single subscription per user_id, deletion allows the user to remove useless data while keeping the useful around.

However, accountable towers need to keep track of deleted appointments, otherwise a user could send an appointment, request a deletion, and trigger a dispute. Afterwards, it could claim the appointment was failed and the tower won't have proof of deletion ₁.

If the tower keeps track of the deletion proofs (locator:user_signature), the user can simply create an appointment, delete and repeat to build up the tower storage for free. Notice this may only affect accountable towers, since normal towers may not keep track of what has been deleted.

A possible workaround may be not allowing the user to reuse the appointment slots straight-away, but give the user a discount in the next subscription proportional to the data that has been deleted (i.e. X deleted appointment gives a Y% discount). A similar approach giving the user tokens for every deleted appointment (or for every N deleted ones) could also make sense. That way an honest user may still be incentivised to delete appointment from closed channels while malicious users would fill the whole subscription by requesting deletions back and forth.

1: Notice providing proof of channel closure as a way to prove to the tower that the data can be safely deleted is not an option, since doing so would link all the appointment to a channel, leaking information about the user.

[sr-gi]

A solution based on tokens and not reusing the same subscription may align with the subscription rotation idea we discussed a while ago @ZmnSCPxj, even though we still don't have a way of dealing with the byte-representation issue.

[ZmnSCPxj]

Zooming out, it seems to me that trustlessness implies deletion is actually an ever-growing data structure.

Consider blockchains: spent UTXOs are deleted from the UTXO set, but a trustless download of the entire blockchain in order to get the most recent UTXO set requires downloading the entire blockchain, including transactions whose outputs have been deleted.

Consider set representations like Bloom filters and similar cryptographic versions of such. You can always add new members to a set but cannot remove it. You can implement deletion by maintaining two sets, a created set and a deleted set. An object exists in the entire structure by being in the created set but not in the deleted set. But the deleted set is ever-growing.

MimbleWimble allows deletion of some data, but there is still unprunable data that needs to be stored for the entire chain.

---

But maybe this is not so difficult to solve.

We can use a rolling set commitment. When an appointment is added, we add it to the commitment. Then both watchtower and client attest that they agree this set representation of the commitment is valid, by both of them signing that commitment appended with a uint64_t that monotonically increases at each update (whether insertion or deletion).

Then if somebody claims "my money waz stole, watchtower y u not protecc???" the watchtower shows the latest such signed commitment and counter, with a proof that the disputed appointment was not in that set (by revealing all live appointments in the subscription). The user can counter this by showing a later signed commitment with a higher counter value, without having to reveal all live appointments (so it stores constant amount of data, just the commitment + counter + sigs); after all, the watchtower is supposed to know the latest state of the subscription, and if it did not reveal the latest state of the subscription, then the watchtower is not working properly anyway and should not be used.