Author: Antoine Riard 2019-11-29 05:43:32
Published on: 2019-11-29T05:43:32+00:00
The Lightning Network has released a proposal for a WatchTower protocol. The protocol aims to standardize the interoperable watchtower protocol used for hiring a third-party watching service to monitor the blockchain and respond to channel breaches on behalf of a client. The proposal sets requirements for both clients and servers in building appointments for the WatchTower, a format for the signed receipt, among others. To ensure channel privacy, the client sends an encrypted justice transaction alongside a transaction locator to the WatchTower. Both the encryption key and the transaction locator are derived from the breach transaction id. The WatchTower will be able to decrypt the justice transaction only after the corresponding breach is seen on the blockchain. The client should send data to the WatchTower for every new update in the channel to ensure replace-by-revocation Lightning channels. The WatchTower protocol offers optional Quality of Service (QoS) to provide stronger guarantees to the client, such as a signed receipt for every new job. The protocol includes the appointment hiring and firing process, which involves defining another TCP port than the LN one of 9735 as it is a client-server relationship. The `init` message would contain a method to establish a secure connection between client and server. For the payment protocol, parameters negotiation like update rate-limiting, feerate for encrypted blob, storage throttling after time X, etc., should be included as they may cover watching operations of one or more channels and secondly they are DoS protections.The WatchTower protocol does not include a payment protocol between the customer and the WatchTower or WatchTower server discovery. The proposal states that clients will send appointments to the WatchTower, which will either accept or reject them based on certain requirements. If qos_data was requested in the appointment, the server must set qos_data according to Quality of Service data and set qos_len equal to the length of qos_data. Similarly, if qos was requested in the appointment, the client must fail the connection if the locator does not match any of the locators previously sent to the server. Quality of Service data is a list where each field specifies the type and associated data of the offered/requested qos. Only accountability is defined so far. Accountability qos defines a pair qos_data blobs, associated with a pair of messages: customer_evidence and tower_evidence. If accountability is being requested, the client must set dispute_delta to the CLTV value specified in the commitment_transaction, transaction_size to the size of the serialized justice_transaction in bytes, transaction_fee to the fee set in the justice_transaction in satoshis, customer_signature_algorithm to one of the signature algorithms supported by the tower, customer_signature to the signature of the appointment using op_customer_signature_algorithm, and customer_public_key to the public key that matches the private key used to create op_customer_signature. The tower_evidence format is defined as follows: receipt_len, receipt, wt_signature_algorithm, wt_signature_len, wt_signature, and wt_public_key_len. The server must set receipt to a receipt built according to Receipt-Format and set wt_signature_algorithm to one of the signature algorithms he has announced. The client must compute the wt_signature verification using wt_public_key. Although this BOLT does not enforce any specific payment method to be adopted, it is worth mentioning the three most common ones: On-chain bounty, Micropayments, and Subscription. Both micropayments and subscriptions are favourable for a WatchTower. Lastly, the document mentions several FIXMES that need attention in defining a proper tower discovery, authentication mechanism, message types, receipt serialization format, and optional ways of doing batch appointments/appointments in bulk, among others.
Updated on: 2023-06-02T22:04:18.661983+00:00