Re: [Lightning-dev] [DRAFT] BOLT 13(?): WatchTower protocol
Hi all, I've been working on a revision to BOLT13's proposal with the comments received over the list (h/t Rusty and Antoine), and from conversations with different people from the community at Advancing Bitcoin and over email this last weeks. This revision includes user accounts, payment methods, and message signing, as well as improvements over the original proposal. On top of that, there are a few things I'd love to add in a future revision: - Proofs of storage for subscription renewals in s similar fashion to Dead Men's Button (h/t Joost Jager). - Recognition codes for a more private approach to subscriptions (thanks ZmnSCPxj for the extensive discussion over the last week). As the last time, there's a list discussion topics at the end, with things I'd love to hear your opinion on. Best, PS: The documents can also be found at https://github.com/sr-gi/bolt13 # Watchtower protocol specification (BOLT DRAFT REV.1) ## Overview 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. At a high level, every time there is a new transfer in the client's lightning channel, the client sends the Watchtower an encrypted penalty transaction and a transaction locator. Internally, the Watchtower maps the transaction locator to the encrypted penalty transaction. If there is a breach in the lightning channel, the Watchtower can identify it with the locator, and use the commitment transaction ID to compute the decryption key. With the decryption key, the tower decrypt the encrypted penalty transaction and broadcast it to the network. Therefore, the Watchtower does not learn any information about the client's channel unless there is a channel breach (channel-privacy). 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 cannot respond to all potential breaches. Finally, optional extensions 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. The scope of this document includes: - A protocol for client/server communication. - A payment protocol between the customer and Watchtower. - How to build appointments for the Watchtower, including key/locator derivation and data encryption. - A format for the signed receipt. The scope of this bolt does not include: - Watchtower server discovery. For the rest of this document we will use server/tower and client/Lightning node indistinguishably. ## Table of Contents * [Watchtower discovery](#watchtower-discovery) * [Watchtower services](#watchtower-discovery) * [Basic Service](#basic-service) * [Extensions](#extensions) * [User authentication](#user-authentication-and-subscriptions) * [The `register_top_up` message](#the-register_top_up-message) * [The `subscription_details` message](#the-subscription_details-message) * [Sending appointments to the tower](#sending-appointments-to-the-tower) * [The `add_update_appointment` message](#the-add_update_appointment-message) * [The `appointment_accepted` message](#the-appointment_accepted-message) * [The `appointment_rejected` message](#the-appointment_rejected-message) * [Deleting appointments](#deleting-appointments) * [The `delete_appointment` message](#the-delete_appointment-message) * [The `deletion_accepted` message](#the-deletion_accepted-message) * [The `deletion_rejected` message](#the-deletion_rejected-message) * [Transaction Locator and Encryption Key](#transaction-locator-and-encryption-key) * [Encryption Algorithms and Parameters](#encryption-algorithms-and-parameters) * [Payment Modes](#payment-modes) * [Data serialisation and signing](#data-serialisation-and-signing) * [No compression of penalty transaction](#no-compression-of-penalty-transaction) * [Attacks on towers](#attacks-on-towers) ## Watchtower discovery 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. ## Watchtower services ### Basic Service The customer can hire the Watchtower to watch for breaches on the blockchain and relay a penalty 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. ### Extensions Extensions build on top of the basic service and are optionally provided by the tower. Different extensions can be offered by the tower. For now we are defining a single type of extension: `accountability`. `accountability` A Watchtower provides
Re: [Lightning-dev] [DRAFT] BOLT 13(?): WatchTower protocol
Hi Rusty, thanks for the feedback! On Tue, Dec 3, 2019 at 1:26 AM Rusty Russell wrote: > Hi Sergi! > > Great to see progress on this! Detailed comments below. > > Sergi Delgado Segura writes: > > ## Sending and receiving appointments > > > > Once the client is aware of the services provided by the server, the > former > > can start sending appointments to the latter. > > > > +---++---+ > > | A |--(1)--- appointment >| B | > > | |<-(2)--- accepted/rejected -| | > > +---++---+ > > > > - where node A is 'client' and node B is 'server' > > > > ### The `appointment` message > > > > This message contains all the information regarding the appointment that > > the client wants to arrange with the server. > > > > 1. type: ? (`appointment`) > > 2. data: > >* [`16*byte`:`locator`] > >* [`u64 `:`start_block`] > >* [`u64 `:`end_block`] > > u32 is sufficient for start_block, fwiw. > OK > > >* [`u16`: `encrypted_blob_len` > >* [`encrypted_blob_len*byte`:`encrypted_blob`] > >* [`u16`:`cipher`] > >* [`u16`: `auth_token_len`] > >* [`auth_token_len*byte`: `auth_token`] > >* [`u16`: `qos_len`] > >* [`qos_len*byte`: `qos_data`] > > > > Requirements > > > > The client: > > > > * MUST set `locator` as specified in [Transaction Locator and Encryption > > Key](#transaction-locator-and-encryption-key). > > * MUST set `start_block` to the current chain tip height. > > What is the purpose of this field? Presumably the watcher knows the > current block number. > > I suggest you want this to be "the first possible block in which the > transction can occur"? > Indeed > > > * MUST set `end_block` to the block height at which he requests the > server > > to stop watching for breaches. > > I don't know how you would set that. I think you need this to be > separate: either as part of the payment layer (I will watch for a year), > or an explicit "stop watching" message (assuming that you pay for > certain capacity). > I think it makes sense to do it in the payment layer. A "stop watching" command seems tricky though, how would you price it properly? It seems that the user could be able to game it, specially if the "bounty" approach. > > > * MUST set `encrypted_blob` to the encryption of the > `justice_transaction` > > as specified in [Transaction Locator and Encryption > > Key](#transaction-locator-and-encryption-key). > > The phrase used in the spec is penalty transaction, BTW. Especially > since its use is generally an injustice :) > Sorry about that >.< > > > * MUST set `cipher` to the cipher used to create the `encrypted_blob`. > > Don't do this. Pick a cipher already used elsewhere in the protocol. > chacha20 is a good choice. > Ok, We were thinking on having a certain level of configuration to avoid broken things in the future. It makes the protocol unnecessarily complicated though, so we'll change it to chacha20 only. > > > * MAY send an empty `auth_token` field. > > * MUST set `auth_token_len` to the length of `auth_token`. > > The latter is already written in the spec. But these days, optional > fields are implemented as TLV data, so perhaps use that instead. > > * MAY send an empty `qos_data` field. > > * if `qos_data` is not empty: > > * MUST set `qos_data` according to [Quality of Service > > data](#quality-of-service-data). > > * MUST set `qos_len` equal to the length of `qos_data`. > > I would drop the idea of "qos", and again use TLV data, defining > accountability. Others can be added later. > OK, I'll give it a look. > > > The server: > > > > * MUST reject the appointment if: > > * Authentication is required and `auth_token` is not provided. > > * Authentication is required and `auth_token` is invalid. > > > * `locator` is not a `16-byte` value. > > This cannot happen, so eliminate it. > Noted > > > * `start_block` is further than one block behind the current chain tip. > > * `start_block` is further than one block ahead the current chain tip. > > I'm still not sure what start_block is for. It just seems to make > things fragile if blocks arrive quickly. > The rationale is to prevent users to ask the tower to look for passed events. > > > * `encrypted_blob` has unreasonable size. > > * `cipher` is not among the ones he implements. > > > > * SHOULD reject the appointment if`end_block` is too far away in the > future. > > This is a problem, since in practice we'll have to define what that is. > Agreed. As mentioned before it seems reasonable to do it during hiring. Open to other ideas too though. > > > * MUST: > > * truncate the remainder of the package to `qos_len`. > > * process `qos_data` according to [Quality of Service > > data](#quality-of-service-data) if `qos_len` is not 0. > > > > * MAY accept the appointment otherwise. > > I would suggest: > > * If it accepts the appointment: >
Re: [Lightning-dev] [DRAFT] BOLT 13(?): WatchTower protocol
Hey Antoine, thanks for the feedback. On Fri, Nov 29, 2019 at 6:43 AM Antoine Riard wrote: > 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. > 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. > Messages should also use the TLV format, will remove a lot *_len field and > each > QoS could be a tlv_record in `appointment`. > I'll look into the TLV format and redesign it accordingly. > > 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. > 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. > > 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... > 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. > > 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. > Agreed, the user should provide proof of payment in the `appointment_hiring` but all the steps to accomplish that should be done beforehand. > > Then `appointment_hiring` with QoS and their parameters, is there reasons > for > not having them being stable for the lifetime of client-server interaction > ? > 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. > > Finally, some `appointment_firing` to let the client cut its subscription > and > authorize the server to clean storage. > That's the reasoning behind the `end_block`, allowing the tower to clean the data after a certain time. > > > > * `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.. > The 3 block window was defined as a way
