Thanks for working on this, a bunch of interesting ideas!
I think it could be noted in the motivation, that's having an interoperable
watchtower protocol is really cool, because every watchtower you add is
a liveness reliability increase (modulo privacy loss), specially if these
watchtowers are from different implementations in case of a vuln affecting
breach
monitoring code of your LN node.
Some generic remarks, you should define another TCP port than the LN one of
9735
because this is client-server relationship and you want to avoid leak of
p2p
messages to your watchtower.
Messages should also use the TLV format, will remove a lot *_len field and
each
QoS could be a tlv_record in `appointment`.
For the init protocol, I was considering the following scheme.
init
-->
version
<--
Alice Bob
payment protocol
--->
...
appointment hiring
--->
...
appointment firing
--->
The `init` message would contain a method to establish a secure connection
between client and server. Watchtower shouldn't learn LN pubkey of client
as it may be a conflict of interest and be leveraged to build more
sophisticated
attacks. So client should implement identity contingement properly and use
the `init` message to start a Noise session or something like BIP324.
After secure connection establishement, `version` would be the reply with
a features field, wider than only QoS like also the payment protocol
supported,
and maybe an invoice for the payment protocol preferred. In a future,
features may
extend beyond channel watching, like timing out client HTLC or
synchronization
server for multi-party channels...
Client would then execute the one or multiple steps of the payment protocol.
This one may be complex, i.e include parameters negotiation like update
rate-limiting, feerate for encrypted blob, storage throttling after time X,
...
I do think this kind of parameters belong there compare to
`appointment_hiring`,
as they may cover watching operations of one or more channels and secondly
they
are DoS protections, and payment scheme and DoS are going to be really tied
in watchtowers protocol.
Then `appointment_hiring` with QoS and their parameters, is there reasons
for
not having them being stable for the lifetime of client-server interaction ?
Finally, some `appointment_firing` to let the client cut its subscription
and
authorize the server to clean storage.
> * `start_block` is further than one block behind the current chain tip.
> * `start_block` is further than one block ahead the current chain tip.
Is a 3 block window enough if the client is a mobile which a lot of latency
and weak
processing compare to a watchtower's competitive full-node ? I think it's
only
a block issuance edge case but maybe could be easier if client set
start_block to
current_seen_block_height+6 and server would reject if height already past..
> minimum_viable_transaction_size and maximum_viable_transaction_size refer
to the minimum/maximum size required to create a valid transaction.
Couldn't these limits be implictly MAX_STANDARD_TX_WEIGHT and
MAX_STANDARD_TX_NONWITNESS_SIZE, current mempool policy limits ?
Also, nothing is specified on disconnection/reconnection, you want to be
sure than
watchtower as ACK every justice tx sent as every one of them maybe
critical. A client
doesn't want to assume is channel is covered and finally not due to its
network
connection being rotten.
> * MUST set `dispute_delta` to the CLTV value specified in the
> `commitment_transaction`.
What's a dispute delta ? You mean the justice-CSV locktime encumbering
outputs ?
Given this one is fixed at channel opening, it should be fixed also for the
channel
hiring lifetime. And server should announce a min_dispute_delta at QoS
`accountability`
announcement.
> * MUST set `transaction_size` to the size of the serialized
> `justice_transaction`, in bytes.
I would remove the transaction size, given that all outputs are
standardized in LN, that would
be a leak on how much payment traffic is going through the client without
any channel breach.
> * MUST set `transaction_fee` to the fee set in the `justice_transaction`,
> in satoshis.
Generally, the idea to provide justice tx with pre-signed fees to a
watchtower and expect
this one to do is job reliably somewhere in the future seem a weak
assumption... Every watchtower
following this protocol should handle dynamic fees, that's should be a
basic service not even
a QoS. It may through CPFP (but won't be reliable until package relay( or
RBF'ing the justice
tx through usage of SIGHASH_ANYONECANPAY, no need interactivity with the
user at broadcast,
but you m
