<div dir="ltr"><div dir="ltr"><div>Hey Antoine, thanks for the feedback.</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 29, 2019 at 6:43 AM Antoine Riard <<a href="mailto:antoine.riard@gmail.com" target="_blank">antoine.riard@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks for working on this, a bunch of interesting ideas!<br><br>I think it could be noted in the motivation, that's having an interoperable<br>watchtower protocol is really cool, because every watchtower you add is<br>a liveness reliability increase (modulo privacy loss), specially if these<br>watchtowers are from different implementations in case of a vuln affecting breach<br>monitoring code of your LN node.<br><br>Some generic remarks, you should define another TCP port than the LN one of 9735<br>because this is client-server relationship and you want to avoid leak of p2p <br>messages to your watchtower.<br></div></blockquote><div><br></div><div>We considered that, but we're unsure about whether that would be the best way to go, or it would be better to add additional messages at a p2p level. Also there's the option of piggybacking information using the current messages, which is the approach followed by lnd at the moment IIRC. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Messages should also use the TLV format, will remove a lot *_len field and each<br>QoS could be a tlv_record in `appointment`.<br></div></blockquote><div><br></div><div>I'll look into the TLV format and redesign it accordingly.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>For the init protocol, I was considering the following scheme.<br><br><br> init<br> ----------------------> <br> <br> version<br> <----------------------<br> Alice Bob<br> payment protocol<br> -----------------------> <br> ...<br><br> appointment hiring<br> -----------------------> <br> ...<br><br> appointment firing <br> -----------------------><br><br>The `init` message would contain a method to establish a secure connection<br>between client and server. Watchtower shouldn't learn LN pubkey of client<br>as it may be a conflict of interest and be leveraged to build more sophisticated<br>attacks. So client should implement identity contingement properly and use<br>the `init` message to start a Noise session or something like BIP324.<br></div></blockquote><div> </div><div>We were thinking on not having any way of linking appointments from the the same user. The only "identity" we were considering is the `auth_token`, that can easily be used as a nonce. It's also possible to use the same for multiple appointments, depending on the user.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>After secure connection establishement, `version` would be the reply with<br>a features field, wider than only QoS like also the payment protocol supported,<br>and maybe an invoice for the payment protocol preferred. In a future, features may<br>extend beyond channel watching, like timing out client HTLC or synchronization<br>server for multi-party channels...<br></div></blockquote><div><br></div><div>Agreed, we were thinking on something similar. The peer discovery has not been defined yet, but it seems reasonable for the tower to advertise the services it offers on the first message. An init approach as you proposed seems to have the problem of how the user finds the tower. On the other hand, if there's a peers discovery (either trough DNS seed or something different) the init/version steps can be simplified.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Client would then execute the one or multiple steps of the payment protocol.<br>This one may be complex, i.e include parameters negotiation like update<br>rate-limiting, feerate for encrypted blob, storage throttling after time X, ...<br>I do think this kind of parameters belong there compare to `appointment_hiring`,<br>as they may cover watching operations of one or more channels and secondly they<br>are DoS protections, and payment scheme and DoS are going to be really tied<br>in watchtowers protocol.<br></div></blockquote><div><br></div><div>Agreed, the user should provide proof of payment in the `appointment_hiring` but all the steps to accomplish that should be done beforehand.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Then `appointment_hiring` with QoS and their parameters, is there reasons for<br>not having them being stable for the lifetime of client-server interaction ?<br></div></blockquote><div><br></div><div>Well, as I was saying we were thinking on avoiding having any link between different appointments from the same user, therefore specifying it appointment-wise.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Finally, some `appointment_firing` to let the client cut its subscription and<br>authorize the server to clean storage.<br></div></blockquote><div><br></div><div>That's the reasoning behind the `end_block`, allowing the tower to clean the data after a certain time.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br>> * `start_block` is further than one block behind the current chain tip.<br>> * `start_block` is further than one block ahead the current chain tip.<br><br>Is a 3 block window enough if the client is a mobile which a lot of latency and weak<br>processing compare to a watchtower's competitive full-node ? I think it's only <br>a block issuance edge case but maybe could be easier if client set start_block to<br>current_seen_block_height+6 and server would reject if height already past..<br></div></blockquote><div><br></div><div>The 3 block window was defined as a way for the tower to learn whether the client was up to date or not. Also a malicious user may try to hire a tower to look for something that's already resolved in the blockchain making the tower do "the heavy lifting" of parsing information from arbitrarily old blocks. 3 is also an arbitrary number, and can be extended. It would also work for the tower to advertise it's tip and for the user to agree on that.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"> <br>> minimum_viable_transaction_size and maximum_viable_transaction_size refer to the minimum/maximum size required to create a valid transaction.<br><br>Couldn't these limits be implictly MAX_STANDARD_TX_WEIGHT and<br>MAX_STANDARD_TX_NONWITNESS_SIZE, current mempool policy limits ?<br></div></blockquote><div><br></div><div>True, but those are not consensus rules (AFAIK at least) so they are subjective to change. I think some sanity checks from the tower side may be worthy. It's also worth noting that this checks only prevent naive attacks, since properly formatted blobs would pass the them. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Also, nothing is specified on disconnection/reconnection, you want to be sure than<br>watchtower as ACK every justice tx sent as every one of them maybe critical. A client<br>doesn't want to assume is channel is covered and finally not due to its network<br>connection being rotten.<br></div></blockquote><div><br></div><div><span style="color:rgb(80,0,80)"><div><br></div></span><div>It may be worth having some kind of ack, but it's also worth mentioning that the user may be offline (since that's one of the main use cases of the towers), so sending and ack may be useful but we shouldn't rely on the assumption that the user will receive it.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><br>> * MUST set `dispute_delta` to the CLTV value specified in the<br>> `commitment_transaction`.<br><br>What's a dispute delta ? You mean the justice-CSV locktime encumbering outputs ?<br>Given this one is fixed at channel opening, it should be fixed also for the channel<br>hiring lifetime. And server should announce a min_dispute_delta at QoS `accountability`<br>announcement.<br></div></blockquote><div><br></div><div>Yes, that's what we meant. Sorry for not using the proper naming. Same reasoning as before, in our proposal the tower has no clue whether two appointments are from the same channel or not. I guess it's worth discussing if this makes sense or if it's better to switch to an approach where they can be linked even if it leaks some information about the channel usage.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>> * MUST set `transaction_size` to the size of the serialized<br>> `justice_transaction`, in bytes.<br><br>I would remove the transaction size, given that all outputs are standardized in LN, that would<br>be a leak on how much payment traffic is going through the client without any channel breach.<br><br>> * MUST set `transaction_fee` to the fee set in the `justice_transaction`,<br>> in satoshis.<br><br>Generally, the idea to provide justice tx with pre-signed fees to a watchtower and expect<br>this one to do is job reliably somewhere in the future seem a weak assumption... Every watchtower<br>following this protocol should handle dynamic fees, that's should be a basic service not even <br>a QoS. It may through CPFP (but won't be reliable until package relay( or RBF'ing the justice<br>tx through usage of SIGHASH_ANYONECANPAY, no need interactivity with the user at broadcast,<br>but you may need a populated input mempool.<br></div></blockquote><div><br></div><div>The original idea of both the fee and size was to allow the tower to decide whether or not it would be able to relay the transaction (specially in the case where the end_time is close to the current time). Thinking about it trough though it seems a pretty weak assumption, since in most of the cases the tower may not be able to predict future fees. I do like the idea of the SIGHASH_ANYONECANPAY approach to allow the tower to bump the fees. I'll need to think more about it. <br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">> While a customer can always fake this values, it should break ToS between the client and the<br>server and, therefore, release the WatchTower of any liability<br><br>I can imagine with machine-readable proofs a bot fetching proofs servers, verifying them<br>on the blockchain and scoring in consequence watchtowers. Good marks could be done via<br>some tagging of justice tx (like setting nLocktime in the past to some value). You would<br>negotiate a different tag for everyone of your watchtower. Removing feerate from the equation<br>would simplify scoring as now you don't have to guess if mempool was congestionned or not for<br>the client-provided fee.<br><br>> On top of that, the onchain bounty allows a network-wise DoS attack for free.<br><br>A good point of the onchain bounty is the user doesn't pay for inefficient watchtower or<br>suppleous watchtower. But seems hard to implement DoS-wise and at the same time keep the<br>requirement of pseudonymous clients. Nevertheless a note maybe said on a LN node implementing<br>some kind of anyone-can-spend on top of its txn and let the vigilant crowd bid with fees<br>and confirm your punishment, that's would be the "watchtowerless watchtower protocol" :p<br></div></blockquote><div><br></div><div>Yep, we agree is not a straightforward problem to solve, so open to ideas!</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>> That would break appointment unlinkability but would ease the data<br>> management for the tower.<br><br>Unlinkability should be far higher in the BOLT design decisions, I think people may don't<br>care about unlinkability in case of all watchtowers servers are running under same<br>organization but they are interested by some building blocks of this spec like tracking ACK<br>or fees management delegation. So we may have multiple formats for the transaction<br>locator/encryption and one of them being the empty one ?<br></div></blockquote><div><br></div><div>I don't follow you here :sweet_smile:<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>> The `customer_signature` could be optional if the client does not care<br>> that much about the worst case. Dicuss whether that makes sense.<br><br>I think you're right it can be skipped as client has provided a signed justice<br>tx as an implicit commitment ?<br><br>Okay that's a lot and it's really IMO, I do think that's important to have a flexible protocol<br>with a lot of room for further privacy/efficiency/services upgrades and circumvent non-seen now<br>complexity. If watchtowers are economically/sociably viable it maybe a layer of its own!<br></div></blockquote><div> </div><div>Agreed, that's one of the reasons why some of the bits haven't been defined yet, since we're unsure what the community thinks about embedding this within the protocol or having something on top of it. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 27 nov. 2019 à 15:20, Sergi Delgado Segura <<a href="mailto:sergi.delgado.s@gmail.com" target="_blank">sergi.delgado.s@gmail.com</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<br><br>Patrick McCorry and I have been working on putting together a BOLT draft for WatchTowers. So far we've seen a couple of implementation of WatchTowers in the wild (lnd and Electrum) based on Tadge's Monitor approach and we are also working on our own one. While all are similar, they differ in some points that may make then non interoperable, so it felt right time to put some effort and try to standardise this. We've borrowed ideas from all implementations as well as from the original approach and added some additional bits to extended with different quality of service. The draft is still rough on the edges and have several open discussion topics at the very end (#FIXME section).<br><br>Best,<br><br># WatchTower protocol specification (BOLT DRAFT)<br><br>## Overview<br><br>All off-chain protocols assume the user remains online and synchronised with the network. To alleviate this assumption, customers can hire a third party watching service (a.k.a WatchTower) to watch the blockchain and respond to channel breaches on their behalf. <br><br>At a high level, 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, meaning that the WatchTower will be able to decrypt the justice transaction only after the corresponding breach is seen on the blockchain. Therefore, the WatchTower does not learn any information about the client's channel unless there is a channel breach (channel-privacy).<br><br>Due to replace-by-revocation Lightning channels, the client should send data to the WatchTower for every new update in the channel, otherwise the WatchTower may not be able to respond to specific breaches. <br><br>Finally, optional QoS can be offered by the WatchTower to provide stronger guarantees to the client, such as a signed receipt for every new job. The rationale for the receipt is to build an _accountable_ WatchTower as the customer can later use it as publicly verifiable evidence if the WatchTower fails to protect them.<br><br>The scope of this document includes: <br><br>- A protocol for client/server communication.<br>- How to build appointments for the WatchTower, including key/locator derivation and data encryption.<br>- A format for the signed receipt. <br><br>The scope of this bolt does not include: <br><br> - A payment protocol between the customer and WatchTower. <br> - WatchTower server discovery.<br> <br>For the rest of this document we will refer to the WatchTower as server, and the user/Lightning node as client.<br><br>## Table of Contents <br>* [WatchTower discovery](#watchtower-discovery)<br>* [WatchTower services](#watchtower-discovery)<br> * [Basic Service](#basic-service)<br> * [Quality of Service](#quality-of-service)<br>* [Sending and receiving appointments](#sending-and-receiving-appointments)<br> * [The `appointment` message](#the-appointment-message)<br> * [The `appointment_accepted` message](#the-appointment_accepted-message)<br> * [The `appointment_rejected` message](#the-appointment_rejected-message)<br>* [Quality of Service data](#quality-of-service-data)<br> * [`accountability`](#accountability)<br>* [Transaction Locator and Encryption Key](#transaction-locator-and-encryption-key)<br>* [Encryption Algorithms and Parameters](#encryption-algorithms-and-parameters)<br>* [Payment Modes](#payment-modes)<br>* [No compression of justice transaction](#no-compression-of-justice-transaction)<br><br>## WatchTower discovery<br><br>We have not defined how a client can find a list of servers to hire yet. We assume the client has found a server and the server is offering a watching service. The service can either be the basic service or an accountable quality of service. To deal with pre-payments (when necessary), the client may have an authentication token that the server can verify when accepting the job (e.g. a blinded token).<br><br>## WatchTower services<br><br>### Basic Service<br>The customer can hire the WatchTower to watch for breaches on the blockchain and relay a justice transaction on their behalf. The customer receives an acknowledgement when the WatchTower has accepted the job, but the hiring protocol does not guarantee the transaction inclusion.<br><br>### Quality of Service<br>Quality of Service (`qos`) builds on top of the basic service provided by a tower and it's optionally provided. Different kinds of QoS can be offered by the tower.<br><br>For now we are defining a single type of `qos`: `accountability`.<br><br>#### `accountability`<br><br>A WatchTower provides a signed receipt to the customer. This is considered reputational accountability as the customer has publicly verifiable cryptographic evidence the WatchTower was hired. The receipt can be used to prove the WatchTower did not relay the justice transaction on their behalf and/or request a refund.<br><br>## Sending and receiving appointments<br><br>Once the client is aware of the services provided by the server, the former can start sending appointments to the latter.<br><br> +-------+ +-------+<br> | A |--(1)--- appointment ---->| B |<br> | |<-(2)--- accepted/rejected -----| |<br> +-------+ +-------+<br> <br> - where node A is 'client' and node B is 'server'<br><br>### The `appointment` message<br><br>This message contains all the information regarding the appointment that the client wants to arrange with the server.<br><br>1. type: ? (`appointment`)<br>2. data:<br> * [`16*byte`:`locator`]<br> * [`u64 `:`start_block`]<br> * [`u64 `:`end_block`]<br> * [`u16`: `encrypted_blob_len`<br> * [`encrypted_blob_len*byte`:`encrypted_blob`]<br> * [`u16`:`cipher`]<br> * [`u16`: `auth_token_len`]<br> * [`auth_token_len*byte`: `auth_token`]<br> * [`u16`: `qos_len`]<br> * [`qos_len*byte`: `qos_data`]<br><br>#### Requirements<br><br>The client:<br><br>* MUST set `locator` as specified in [Transaction Locator and Encryption Key](#transaction-locator-and-encryption-key).<br>* MUST set `start_block` to the current chain tip height.<br>* MUST set `end_block` to the block height at which he requests the server to stop watching for breaches.<br>* MUST set `encrypted_blob` to the encryption of the `justice_transaction` as specified in [Transaction Locator and Encryption Key](#transaction-locator-and-encryption-key).<br>* MUST set `cipher` to the cipher used to create the `encrypted_blob`.<br>* MAY send an empty `auth_token` field.<br>* MUST set `auth_token_len` to the length of `auth_token`.<br>* MAY send an empty `qos_data` field.<br>* if `qos_data` is not empty:<br> * MUST set `qos_data` according to [Quality of Service data](#quality-of-service-data).<br>* MUST set `qos_len` equal to the length of `qos_data`.<br><br>The server:<br><br>* MUST reject the appointment if:<br> * Authentication is required and `auth_token` is not provided.<br> * Authentication is required and `auth_token` is invalid.<br> * `locator` is not a `16-byte` value.<br> * `start_block` is further than one block behind the current chain tip.<br> * `start_block` is further than one block ahead the current chain tip.<br> * `encrypted_blob` has unreasonable size.<br> * `cipher` is not among the ones he implements.<br><br>* SHOULD reject the appointment if`end_block` is too far away in the future.<br><br>* MUST: <br> * truncate the remainder of the package to `qos_len`.<br> * process `qos_data` according to [Quality of Service data](#quality-of-service-data) if `qos_len` is not 0.<br><br>* MAY accept the appointment otherwise.<br><br>#### Rationale<br><br>We define appointment as the way that the WatchTower is hired / requested by a client to do it's watching services.<br><br>WatchTowers may offer their services for free (`altruistic`) or they may require a payment when accepting the job (`non-altruistic`). We have defined `auth_token` as an authentication mechanism between the client and server, so the client can prove they are entitled to the service. The tokens are not required to be linked to any kind of identity (e.g. blinded tokens), but their sole purpose is to confirm the client has already paid for the service.<br><br>The transaction `locator` can be deterministically computed by both the client and the server. Locators of wrong size are therefore invalid.<br><br>`start_block` can be either one block ahead or behind the tower tip due to network delays. A tower must not accept appointments arbitrarily ahead or behind the current tip since it could increase DoS vectors. A `start_block` long behind would force the tower to rescan block data for those appointments instead of watching block by block. On the other hand, a `start_time` long ahead would imply storing information way before it being needed.<br><br>Regarding the `end_block`, too far away is a subjective concept. The further away a tower accepts appointment ends, the higher the potential storage requirements may be, and the easier, and cheaper, it my be to perform DoS.<br><br>The `encrypted_blob` should have been encrypted using `cipher`. Block ciphers have a size multiple of the block length, which depends on the key size. Therefore the `encrypted_blob` have to be at least as big as:<br><br>`cipher_block_size * ceil(minimum_viable_transaction_size / cipher_block_size)`<br><br>and at most as big as:<br><br>`cipher_block_size * ceil(maximum_viable_transaction_size / cipher_block_size`) <br><br>`minimum_viable_transaction_size` and `maximum_viable_transaction_size` refer to the minimum/maximum size required to create a valid transaction. Accepting `encrypted_blob` outside those boundaries will increase DoS attacks on the server.<br><br>The client should have learn about the `ciphers` implemented by the WatchTower and the `qos` that the tower is offering during the peer discovery.<br><br>A tower must not accept appointments using a cipher it does not implement, otherwise the decryption of the `encrypted_blob` will not be possible.<br><br>`qos` is optional and can include multiple services.<br> <br>### The `appointment_accepted` message<br><br>This message contains information about the acceptance of an appointment by the WatchTower.<br><br>1. type: ? (`appointment_accepted `)<br>2. data:<br> * [`16*byte `:`locator`]<br> * [`u16`: `qos_len`]<br> * [`qos_len*byte`: `qos_data`]<br><br>The server:<br><br>* MUST receive `appointment` before sending an `appointment_accepted` message.<br>* MUST set the `locator` to match the one received in `appointment`.<br>* if `qos_data` was requested in `appointment`:<br> * MUST set `qos_data` according to [Quality of Service data](#quality-of-service-data).<br>* MUST set `qos_len` equal to the length of `qos_data`.<br><br>The client:<br><br>* MUST fail the connection if `locator` does not match any of locators the previously sent to the server:<br><br>* if `qos` was requested in `appointment`:<br> * MUST fail the connection if `qos_len` is 0.<br> * MUST process `qos_data` according to [Quality of Service data](#quality-of-service-data).<br><br>### The `appointment_rejected` message<br><br>This message contains information about the rejection of an appointment by the WatchTower.<br><br>1. type: ? (`appointment_rejected `)<br>2. data:<br> * [`16*byte `:`locator`]<br> * [`u16`: `rcode`]<br> * [`u16`: `reason_len`<br> * [`reason_len*byte`: `reason`]<br><br>The server:<br><br>* MUST receive `appointment` before sending an `appointment_rejected` message.<br>* MUST set the `locator` to match the one received in `appointment`.<br>* MUST set `rcode` to the rejection code.<br>* MAY set and empty `reason` field.<br>* MUST set `reason_len` to length of `reason`.<br><br>#### Rationale<br><br>The `appointment_rejected` message follows the approach taken by the `error` message defined in [BOLT#1](<a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#the-error-message" target="_blank">https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#the-error-message</a>): error codes are mandatory, whereas reasons are optional and implementation dependant.<br><br>## Quality of Service data<br><br>`qos_data` is a list where each field specifies they type and associated data of the offered/requested `qos`. The format is defined as follows:<br><br>* [`u16`: `qos_type`]<br>* [`u16`: `data_len`]<br>* [`data_len*byte`: `data`]<br><br>So far, only `accountability` is defined.<br><br>### `accountability`<br><br>The accountability `qos` defines a pair `qos_data` blobs, associated to a pair of messages: The first one is `customer_evidence` and it is provided by the `client` in the `appointment` message. The second one is `tower_evidence`, and is provided by the WatchTower in the `appointment_accepted` message.<br><br>#### `customer_evidence`<br><br>The format for the `customer_evidence` is defined as follows:<br><br>1. type: ? (`customer_evidence`)<br>2. data: <br> * [`u64 `:`dispute_delta`]<br> * [`u64`: `transaction_size`]<br> * [`u64`: `transaction_fee`]<br><br>If `accountability` is being requested, the client:<br> <br>* MUST set `dispute_delta` to the CLTV value specified in the `commitment_transaction`.<br>* MUST set `transaction_size` to the size of the serialized `justice_transaction`, in bytes.<br>* MUST set `transaction_fee` to the fee set in the `justice_transaction`, in satoshis.<br>* MUST set the `customer_signature_algorithm` to one of the signature algorithms supported by the tower.<br>* MUST set `customer_signature` to the signature of the appointment using `op_customer_signature_algorithm`.<br>* MUST set `customer_public_key` to the public key that matches the private key used to create `op_customer_signature`.<br><br>If `accountability` is being offered, the server:<br><br>* MUST compute the `customer_signature` verification using `customer_public_key`.<br>* SHOULD compute the `fee_rate` set in the `justice_tx` using `transaction_size` and `transaction_fee`.<br><br>* MUST reject the appointment if:<br> * Any of the fields is missing.<br> * `transaction_size` is unreasonable.<br> * `customer_signature_algorithm` does not match any of the supported signing algorithms.<br> * `customer_signature` cannot be verified using `customer_public_key`.<br><br>* SHOULD reject the appointment if:<br> * `dispute_delta` is too small.<br> * `fee_rate` is too low.<br><br>If `accountability` is NOT being offered:<br><br>* The server MUST reject the appointment.<br><br>Otherwise:<br><br>* The server SHOULD accept the appointment.<br><br>#### Rationale<br><br>The concept of too small for `dispute_delta` is subjective. The `dispute_delta` defines the time (in blocks) that the tower has in order to respond after a breach is seen. The smaller the value, the more the server risks to fail the appointment.<br><br>`transaction_size` and `transaction_fee` help the WatchTower to decide on the likelihood of an appointment being fulfilled. Appointments with `fee_rate` too low may be rejected by the WatchTower. While a customer can always fake this values, it should break ToS between the client and the server and, therefore, release the WatchTower of any liability.<br><br>By accepting the request, the tower is offering a reputationally accountable watching service. If `accountability` is not offered, then the tower will not accept appointments requesting for it.<br><br>As well, the WatchTower must check the transaction details before deciding whether it will accept it. If the decrypted justice transaction does not satisfy the job details (e.g. too low fee), then the tower is not obliged to fulfil the appointment.<br><br>#### `tower_evidence`<br><br>The format for the `tower_evidence` is defined as follows:<br><br>1. type: ? (`tower_evidence`)<br>2. data: <br> * [`u16 `:`receipt_len`]<br> * [`receipt_len*byte `: `receipt`]<br> * [`u16`: `wt_signature_algorithm`]<br> * [`u16`: `wt_signature_len`<br> * [`wt_signature_len*byte`: `wt_signature`]<br> * [`u16`: `wt_public_key_len`]<br> * [`wt_public_key_len*byte`: `wt_public_key`]<br><br>The server:<br><br>* MUST set `receipt` to a receipt built according to [Receipt-Format](#receipt-format).<br>* MUST set `wt_signature_algorithm` to one of the signature algorithms he has announced.<br>* MUST set `wt_signature` to the signature of the appointment using `wt_signature_algorithm`.<br>* MUST set `wt_public_key` to the public key that matches the private key used to create `wt_signature`.<br><br>The client:<br><br>* MUST compute the `wt_signature` verification using `wt_public_key`.<br><br>* MUST fail the connection if:<br> * Any of the fields is missing.<br> * `receipt` does not matches the format specified at [Receipt-Format](#receipt-format)<br> * `receipt` fields do not match the ones sent in the `appointment` message.<br> * `wt_signature_algorithm` does not match any of the ones offered by the server.<br> * `wt_signature` cannot be verified using `wt_public_key`.<br><br>#### Receipt Format <br><br>The server MUST create the receipt containing the following information:<br><br> txlocator<br> start_block<br> end_block<br> dispute_delta<br> encrypted_blob<br> transaction_size<br> transaction_fee<br> cipher<br> customer_signature<br> wt_public_key<br> <br><br>#### Rationale<br><br>We assume the client has a well-known public key for the WatchTower. <br><br>The receipt contains, mainly, the information provided by the user. The WatchTower will need to sign the receipt to provide evidence of agreement.<br><br>The `customer_signature` is included in the receipt to link both the client request and the server response. Otherwise, the tower could sign a receipt with different data that the one sent by the user, and the user would have no way to prove whether that's true or not. By signing the customer signature there the tower creates evidence of what the user sent, since the tower cannot forge the client's signature.<br><br>#### Receipt serialization and signature<br><br>[FIXME: TBD]<br><br>## Transaction Locator and Encryption Key<br><br>Implementations MUST compute the `locator`, `encryption_key` and `encryption_iv` from the commitment transaction as defined below: <br><br>- `locator`: first half of the commitment transaction id (`commitment_txid(0,16]`)<br>- `master_key`: Hash of the second half of the commitment transaction id (`SHA256(commitment_txid(16,32])`) <br>- `encryption_key`: first half of the master key (`master_key(0,16]`)<br>- `encryption_iv`: second half of the master key (`master_key(16,32]`)<br><br><br>The server relies on both the encryption key and iv to decrypt the justice transaction. Furthermore, the transaction locator helps the WatchTower identify a breach transaction on the blockchain. <br><br>## Encryption Algorithms and Parameters<br><br>All clients and servers MUST use one of the following encryption algorithms: <br><br>- ChaCha20 (<a href="https://tools.ietf.org/html/rfc7539" target="_blank">https://tools.ietf.org/html/rfc7539</a>)<br>- AES-GCM-256 (<a href="https://tools.ietf.org/html/rfc5288" target="_blank">https://tools.ietf.org/html/rfc5288</a>)<br><br>Sample code (python) for the client to prepare the `encrypted_blob`: <br><br> from hashlib import sha256<br> from binascii import hexlify<br> <br> def encrypt(justice_tx, commitment_txid):<br> # master_key = SHA256(commitment_txid(16, 32])<br> master_key = sha256(commitment_txid[16:]).digest()<br> <br> # The 16 MSB of the master key will serve as the AES-GCM-256 secret key. The 16 LSB will serve as the IV.<br> sk = master_key[:16]<br> nonce = master_key[16:]<br> <br> # Encrypt the data<br> aesgcm = AESGCM(sk)<br> encrypted_blob = aesgcm.encrypt(nonce=iv, data=tx, associated_data=None)<br> encrypted_blob = hexlify(encrypted_blob).decode()<br> <br> return encrypted_blob<br> <br>## Payment modes <br><br>Although this BOLT does not enforce any specific payment method to be adopted, it is worth mentioning the three most common ones:<br><br>**On-chain bounty**. An additional output is created in the justice transaction that will reward the WatchTower. <br><br>**Micropayments**. A small payment is sent to the WatchTower for every new job (e.g. over the lightning network)<br><br>**Subscription**. WatchTower is periodically rewarded / paid for their service to the customer. (e.g. over the lightning network or fiat subscription). <br><br>Both micropayments and subscriptions are favourable for a WatchTower. The on-chain bounty approach is not ideal for a watching network, it lets the customer hire many WatchTowers (O(N) storage for each tower) and only one WatchTower will be rewarded upon collecting the bounty. On top of that, the onchain bounty allows a network-wise DoS attack for free.<br><br>## No compression of justice transaction <br><br>The storage requirements for a WatchTower can be reduced (linearly) by implementing [shachain](<a href="https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt" target="_blank">https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt</a>), therefore storing the parts required to build the transaction and the corresponding signing key instead of the full transaction. For now, we have decided to keep the hiring protocol simple. Storage is relatively cheap and we can revisit this standard if it becomes a problem. <br><br>## FIXMES<br><br>- Define a proper tower discovery.<br>- Define authentication mechanism (macaroons maybe?).<br>- None of the message types have been defined (they have been left with ?).<br>- Define receipt serialization format.<br>- `qos_type` can be defined by ranges, in the same way that error messages are. In that way a range of values can belong to a specific `qos`.<br>- Define an optional way of doing batch appointments / appointments in bulk? That would break appointment unlinkability but would ease the data management for the tower.<br>- The `customer_signature` could be optional if the client does not care that much about the worst case. Dicuss whether that makes sense.<br>- Discuss whether to extend it with shachain.<br><br><br>The document can also be found here: <a href="https://github.com/PISAresearch/pisa/blob/master/13-watchtower-API.md" target="_blank">https://github.com/PISAresearch/pisa/blob/master/13-watchtower-API.md</a><br><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Sergi.</div></div></div>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr">Sergi.</div></div></div>