Sergi Delgado Segura [ARCHIVE] / is on Nostr

Last Notes

2023-06-09 13:12:55

- reply

📅 Original date posted:2023-03-24
🗒️ Summary of this message: Sergi has written a draft on how to handle data deletion for accountable watchtowers using accumulators to reduce data storage requirements.
📝 Original message:
Hi all,
Some time ago I was discussing with ZmnSCPxj about how to handle data
deletion for accountable watchtowers such that the tower doesn't have to
store raw proof of deletion for every single deleted item. The gist is
pretty simple, if I send you data and you hand me proof of reception of
such data, if I ask you to delete the data, now you need to keep proof of
deletion, otherwise, I could claim you are not storing the data we agreed
on initially.
This, unsurprisingly, has led to using accumulators (as ZmnSCPxj originally
suggested) to reduce the data storage requirements (especially on the user
side) while being able to prove additions/deletions.
After chatting with Salvatore Ingala and Calvin Kim about it, I've come to
a point where I think this may be solvable in a rather elegant way, so I
have written a draft of what this may look like wrt watchtowers going,
briefly, from what towers are (and what we mean by accountable) to how
accumulators may help with this issue.
If you're curious about either or both, please give it a look :D
https://gist.github.com/sr-gi/f91f007fc8d871ea96ead9b27feec3d5
--
Sergi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230324/dfb16909/attachment.html>

2023-06-09 13:08:22

- reply

📅 Original date posted:2023-03-24
📝 Original message:
Hi all,
Some time ago I was discussing with ZmnSCPxj about how to handle data
deletion for accountable watchtowers such that the tower doesn't have to
store raw proof of deletion for every single deleted item. The gist is
pretty simple, if I send you data and you hand me proof of reception of
such data, if I ask you to delete the data, now you need to keep proof of
deletion, otherwise, I could claim you are not storing the data we agreed
on initially.
This, unsurprisingly, has led to using accumulators (as ZmnSCPxj originally
suggested) to reduce the data storage requirements (especially on the user
side) while being able to prove additions/deletions.
After chatting with Salvatore Ingala and Calvin Kim about it, I've come to
a point where I think this may be solvable in a rather elegant way, so I
have written a draft of what this may look like wrt watchtowers going,
briefly, from what towers are (and what we mean by accountable) to how
accumulators may help with this issue.
If you're curious about either or both, please give it a look :D
https://gist.github.com/sr-gi/f91f007fc8d871ea96ead9b27feec3d5
--
Sergi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230324/dfb16909/attachment.html>

2023-06-09 13:05:34

- reply

📅 Original date posted:2022-03-11
📝 Original message:
Hello list,
After some months working on this, today I'm releasing the alpha for
rust-teos, the rust version of The Eye of Satoshi (a lightning watchtower).
The project is a port of the original Python's codebase I was working on
last year, with an improved design, way less boilerplate code, and improved
performance. This is partly thanks to Rust itself, but also to LDK. The
older codebase was built on top of Core, while the new one leverages some
of the heavy lifting to the dev kit.
The current functionality is at a similar stage (if not the same) where the
Python's codebase was left. An HTTP API is offered for the interaction with
the user and the tower, and the internal interface is built using gRPC. The
code also includes a CLI for the tower admin to interact with the backend.
Currently there's no client for this, the old c-lightning's watchtower
plugin needs to be updated to work with the new tower, which I'll be
working on next, so if you were using the old tower do not switch yet!
The codebase will benefit from some additional reviews, as well as some
contributors. Hi you, dev looking for a FOSS project to contribute to :D.
In any case, if anyone is interested in giving it a look, the code can be
found at: https://github.com/talaia-labs/rust-teos (there's also an
architecture diagram at https://github.com/talaia-labs/rust-teos/issues/30).
Best,
--
Sergi Delgado.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220311/4f2612f8/attachment.html>

2023-06-09 12:59:15

- reply

📅 Original date posted:2020-03-09
📝 Original message:
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 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 penalty transaction on their behalf
and/or request a refund.
## User authentication and subscriptions
Upon establishing the first connection with the tower, the client needs to
register a public key. The registration aims to give the user access to the
tower's services:
+-------+ +-------+
| A |--(1)-- register ---->| B |
| |<-(2)--- subscription_details -----| |
+-------+ +-------+
- where node A is 'client' and node B is 'server'
### The `register_top_up` message
The `register_top_up` message contains the information required to start
the registration of a new public key with the tower, or to top up an
existing one.
1. type: ? (`register_top_up`)
2. data:
* [`point`:`public_key`]
* [`u32`: `appointment_slots`]
* [`u32`: `subscription_period`]
#### Rationale
We define appointment (in a lack of a better word) as how the Watchtower is
hired by a client for its watching services. Every a client updates the
state of one of his channels, he will send an appointment containing
information related to the update. Check [Sending appointments to the
tower](#sending-appointments-to-the-tower) for more on this.
#### Requirements
The client:
- MUST set `public_key` to the public key he wants to register or top up.
- MUST set `appointment_slots` to the appointment slots he is requesting.
- MUST set `subscription_period` to the number of blocks he is asking the
tower to watch for channel breaches.
Upon receiving a `register_top_up` message, the server:
- MUST reply with a `subscription_details` message.
### The `subscription_details` message
The `subscription_details` message contains information regarding the
subscription the tower is offering to the client, including the
subscription payment request if necessary.
1. type: ? (`subscription_details`)
2. data:
* [`u16`: `appointment_max_size`]
* [`u32`: `amount_msat`]
3. tlvs: `wt_subscription_tlvs`
4. types:
1. type: 1 (`subscription_invoice`)
2. data:
* [`tu16*byte`: `invoice`]
#### Requirements
The server:
* MUST receive a `register_top_up` message before sending
`subscription_details`.
* MUST set `appointment_max_size` to the maximum size allowed for a single
appointment.
* MUST set `amount_msat` to the amount to be paid by the user for the
service.
* MAY include `subscription_invoice` if it is offering a non-altruistic
service. If so:
* MUST set `invoice` to a [BOLT11](
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md)
invoice.
The user:
* MUST have sent `register_top_up` before receiving a
`subscription_details` message.
If `subscription_invoice` is set:
* MAY pay the [BOLT11](
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md)
`invoice`.
#### Rationale
User authentication with the tower is required to allow interaction with
the tower beyond simply sending channel updates (like requesting, updating
or deleting channel updates). Authentication is also required to account
for the amount of data the client is sending to the tower, so subscriptions
models can be properly defined.
The mechanism used to authenticate users by the tower is based on message
signing and public key recovery. During the registration phase the user
will request a public key registration with the tower (`public_key`).
`appointment_slots` and `subscription_period` are requested by the user to
reduce the number of messages exchanged by the two parties whilst allowing
for high customisation. Otherwise the tower will need to inform the user of
what type of services he can apply for.
`appointment_max_size` defines what is the maximum size of an appointment.
The tower is effectively charging for storage over time, so if an
appointment exceeds `appointment_max_size` it will be counted as
`ceil(len(appointment)/appointment_max_size)`.
Once the user is registered, the tower will be able to identify him by
doing EC recovery on his signed requests. Message signing and EC recover is
performed using the current approach followed by [lnd and
c-lightning](#data-serialisation-and-signing).
If a user has filled all his appointment slots, or need to keep the data in
the tower for longer than the `subscription_period`, he may need to top up
his subscription.
For now we have only defined `subscription_invoice` as payment method.
Other payment methods can be defined as tlv in the future.
## Sending appointments to the tower
Once the client is registered, he can start sending appointments to the
tower:
+-------+ +-------+
| A |--(1)--- add_update_appointment ---->| B |
| |<-(2)--- accepted/rejected -----| |
+-------+ +-------+
- where node A is 'client' and node B is 'server'
### The `add_update_appointment` message
This message contains all the information regarding an appointment between
the client and the server.
1. type: ? (`add_update_appointment`)
2. data:
* [`16*byte`:`locator`]
* [`u16`: `encrypted_blob_len`]
* [`encrypted_blob_len*byte`:`encrypted_blob`]
* [`u16`: `signature_len`]
* [`signature_len*byte`: `user_signature`]
3. tlvs: `wt_accountability_tlvs`
4. types:
1. type: 1 (`user_evidence`)
2. data:
* [`u64 `:`to_self_delay`]
#### Requirements
The client:
* MUST set `locator` as specified in [Transaction Locator and Encryption
Key](#transaction-locator-and-encryption-key).
* MUST set `encrypted_blob` to the encryption of the `penalty_transaction`
as specified in [Transaction Locator and Encryption
Key](#transaction-locator-and-encryption-key).
* MUST set `encrypted_blob_len` to the length of `encrypted_blob`.
* MUST set `user_signature ` to the appointment signature.
* MUST set `signature_len` to the length of `user_signature`.
* MAY set `to_self_delay` to the `to_self_delay` requested by the client to
its peer.
The server:
* MUST compute `public_key` by performing EC recover.
* MUST reject the appointment if the recovered `public_key` does not match
with any of the registered ones.
* MAY reject the appointment if `encrypted_blob` has unreasonable size.
If `accountability` is being offered and `to_self_delay` can be found in
`add_update_appointment`:
* MUST reject the appointment if `to_self_delay` is too small.
* MAY accept the appointment otherwise.
If the server accepts the appointment:
* MUST send an `appointment_accepted` message.
If the server rejects the appointment:
* MUST send an `appointment_rejected` message.
#### Signing appointment requests
Appointment request must be arranged as follows while serialised for
signing:
locator | encrypted_blob | to_self_delay
`to_self_delay` will only be included if it is also included in the
request.
The signature must be performed following [Data serialisation and
signing](#data-serialisation-and-signing).
#### Rationale
Users must have preregistered before they can hire the Watchtower, as
discussed in [User authentication](#user-authentication-and-subscriptions).
Appointments from non-registered users are therefore rejected.
A client may need to update an appointment after having sent it to the
tower (for instance to update the fee, change the outputs, etc). The same
message can be used to add new appointments or to update existing ones. If
two appointments from the same user share a `locator`, the tower should
interpret that as an update and override the oldest. `locators` are
`128-bit` values so unintended collisions within the same user should be
negligible.
The `encrypted_blob` size depends on the encrypted commitment transaction
size and the block size of the chosen cipher. Arbitrarily small/big
transaction are invalid, meaning that arbitrarily small/big
`encrypted_blob`s will, therefore, also be invalid.
The `encrypted_blob` have to be larger than (or equal to):
`cipher_block_size * ceil(minimum_viable_transaction_size /
cipher_block_size)`
and smaller than (or equal to):
`cipher_block_size * ceil(maximum_viable_transaction_size /
cipher_block_size`)
`minimum_viable_transaction_size` and `maximum_viable_transaction_size`
refer to the minimum/maximum size required to create a valid transaction.
`encrypted_blob`s outside those boundaries cannot contain valid
transactions, so they should be rejected.
A tower should broadcast the penalty transaction right after a breach is
seen, but should be also able to bump the fee if necessary. If
`to_self_delay` is smaller than expected, then it can lead the tower to
fail.
### The `appointment_accepted` message
This message contains information about the acceptance of an appointment by
the Watchtower.
1. type: ? (`appointment_accepted `)
2. data:
* [`16*byte `:`locator`]
* [`u32`: `start_block`]
3. tlvs: `wt_accountability_tlvs`
4. types:
1. type: 2 (`receipt_signature`)
2. data:
* [`tu16*byte`: `tower_signature`]
The server:
* MUST receive `add_update_appointment` before sending an
`appointment_accepted` message.
* MUST set the `locator` to match the one received in
`add_update_appointment`.
* MUST set `start_block` to the block height where the tower will start
looking for breaches.
If `accountability` is being offered and `add_update_appointment` contained
`to_self_delay`:
* MUST create a receipt of the appointment.
* MUST set `tower_signature` to the signature of the receipt as defined in
[Data serialisation and signing](#data-serialisation-and-signing).
The client:
* MUST fail the connection if `locator` does not match any of locators the
previously sent to the server.
#### Appointment receipt format
Data must be arranged in the following order to create the receipt:
locator | encrypted_blob | to_self_delay | user_signature | start_block
The receipt must be signed following [Data serialisation and
signing](#data-serialisation-and-signing).
#### Rationale
`start_block` is set by the tower so the user knows when the channel update
will be covered.
We assume the tower has a well-known public key and the user is aware of
it. The receipt contains, mainly, the information provided by the user. The
Watchtower will need to sign the receipt to provide evidence of agreement.
The `user_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 the tower creates evidence of what the user sent, since the tower
cannot forge the client's signature.
### The `appointment_rejected` message
This message contains information about the rejection of an appointment by
the Watchtower.
1. type: ? (`appointment_rejected `)
2. data:
* [`16*byte `:`locator`]
* [`u16`: `rcode`]
* [`u16`: `reason_len`
* [`reason_len*byte`: `reason`]
The server:
* MUST receive `add_update_appointment` before sending an
`appointment_rejected` message.
* MUST set the `locator` to match the one received in
`add_update_appointment`.
* MUST set `rcode` to the rejection code.
* MAY set an empty `reason` field.
* MUST set `reason_len` to length of `reason`.
#### Rationale
The `appointment_rejected` message follows the approach taken by the
`error` message defined in [BOLT#1](
https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#the-error-message):
error codes are mandatory, whereas reasons are optional and implementation
dependant.
## Deleting appointments
A client may want to delete appointments from the tower after a breach, or
closing a channel:
+-------+ +-------+
| A |--(1)--- delete_appointment ---->| B |
| |<-(2)--- accepted/rejected -----| |
+-------+ +-------+
- where node A is 'client' and node B is 'server'
### The `delete_appointment` message
1. type: ? (`delete_appointment`)
2. data:
* [`16*byte `:`locator`]
* [`u16`: `signature_len`]
* [`signature_len*byte`: `user_signature`]
The user:
* MUST set `locator` as specified in [Transaction Locator and Encryption
Key](#transaction-locator-and-encryption-key).
* MUST set `user_signature` to the signature of the deletion request.
* MUST set `signature_len` to the length of `user_signature`.
The server:
* MUST compute `public_key` by performing EC recover.
* If the recovered `public_key` has an associated appointment with locator
matching `locator`:
* MUST delete the appointment and send `deletion_accepted`.
* Otherwise:
* MUST reject the deletion request and send `deletion_rejected`.
#### Signing deletion requests
Deletion requests must contain a signature of the following message:
"Delete appointment <locator>"
where `<locator>` MUST match `locator`.
The signature must be performed following [Data serialisation and
signing](#data-serialisation-and-signing).
#### Rationale
Freeing expired appointment from the tower (after a channel clousure or
breach) should be beneficial for both parties. From the tower side, it
allows to reduce the load and free space, for the user side, it recovers
space that was used by expired appointments, so it can be used to back up
new channel updates.
### The `deletion_accepted` message
This message contains information about the acceptance of an appointment
deletion by the Watchtower.
1. type: ? (`deletion_accepted`)
2. data:
* [`16*byte `:`locator`]
3. tlvs: `wt_accountability_tlvs`
4. types:
1. type: 2 (`receipt_signature`)
2. data:
* [`tu16*byte`: `tower_signature`]
The server:
* MUST receive `delete_appointment` before sending an `deletion_accepted`
message.
* MUST set the `locator` to match the one received in `delete_appointment`.
If `accountability` is being offered it was requested for the appointment
appointment:
* MUST set `tower_signature` to the signature of `user_signature` as
specified following [Data serialisation and
signing](#data-serialisation-and-signing).
The client:
* MUST fail the connection if `locator` does not match the `locator` from
`delete_appointment`.
### The `deletion_rejected` message
This message contains information about the rejection of an appointment
deletion by the Watchtower.
1. type: ? (`deletion_rejected`)
2. data:
* [`16*byte `:`locator`]
* [`u16`: `rcode`]
* [`u16`: `reason_len`
* [`reason_len*byte`: `reason`]
The server:
* MUST receive `delete_appointment` before sending an `deletion_rejected`
message.
* MUST set the `locator` to match the one received in `delete_appointment`.
* MUST set `rcode` to the rejection code.
* MAY set and empty `reason` field.
* MUST set `reason_len` to length of `reason`.
#### Rationale
Deletion rejection should include cases like the appointment cannot be
found for the requesting user (either because it never existed, or because
it was already deleted).
The same approach as for `appointment_rejected` error messages is followed
here.
## Transaction Locator and Encryption Key
Implementations MUST compute the `locator`, `encryption_key` and
`encryption_iv` from the commitment transaction as defined below:
- `locator`: first half of the commitment transaction id
(`commitment_txid(0,16]`)
- `encryption_key `: Hash of the commitment transaction id
(`SHA256(commitment_txid)`)
- `encryption_iv`: A 12-byte long 0
(`'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'`)
The server relies on both the encryption key and iv to decrypt the penalty
transaction. Furthermore, the transaction locator helps the Watchtower
identify a breach transaction on the blockchain.
## Encryption Algorithms and Parameters
Users and servers MUST use [ChaCha20-Poly1305](
https://tools.ietf.org/html/rfc7539) to encrypt / decrypt blobs.
Sample code (python) for the client to prepare the `encrypted_blob`:
from hashlib import sha256
from binascii import hexlify
from cryptography.hazmat.primitives.ciphers.aead import ChaCha20Poly1305
def encrypt(penalty_tx, commitment_txid):
# The SHA256 of the commitment txid is used as secret key, and 0 (12-byte
long) as nonce.
sk = sha256(commitment_txid).digest()
nonce = bytearray(12)
# Encrypt the data
cipher = ChaCha20Poly1305(sk)
encrypted_blob = cipher.encrypt(nonce=nonce, data=penalty_tx,
associated_data=None)
encrypted_blob = hexlify(encrypted_blob).decode("utf8")
return encrypted_blob
## Payment modes
The three most common ways of paying a tower are:
**On-chain bounty**. An additional output is created in the penalty
transaction that will reward the Watchtower.
**Micropayments**. A small payment is sent to the Watchtower for every new
job (e.g. over the lightning network).
**Subscription**. Watchtower is periodically rewarded / paid for their
service to the customer. (e.g. over the lightning network or fiat
subscription).
The bounty approach has the benefit of paying the tower only if the job is
done, but lets the customer hire many Watchtowers and only one Watchtower
will be rewarded upon collecting the bounty (O(N) storage for each tower).
On top of that, the onchain bounty allows a network-wise DoS attack for
free. However, it also has the benefit of allowing fee-bumping via CPFP by
including an output dedicated to the tower.
The micropayment approach can be achieved using the same method as the
subscription approach but setting the `appointment_slots` to one. Both
micropayments and subscriptions are favourable for a Watchtower.
The ideal approach could be something in between. The tower is paid via a
subscription to cover the storage costs and making DoS attacks having a
financial cost. On top of that, the penalty transactions can include an
output for the tower so
the tower is encouraged to watch for beaches whilst allowing fee-bumping.
## Data serialisation and signing
Request and receipts are serialised in big-endian, concatenating their
values in the given order if they contain more than one value (as is the
case of the appointment receipt). The signature algorithm follows the
approach developed by lnd and currently implemented by both lnd and
c-lightning [#specinatweet](
https://twitter.com/rusty_twit/status/1182102005914800128):
Signatures are [zbase32 encoded](
https://philzimmermann.com/docs/human-oriented-base-32-encoding.txt) and
are performed over the sha256d of the message prefixed by `"Lightning
Signed Message:"`, that is:
zbase32(SigRec(SHA256(SHA256("Lightning Signed Message:" +
serialised_data))))
For example, for a deletion request of appointment identified by locator
`4a5e1e4baab89f3a32518a88c3bc87f6`, the structure will be:
zbase32(SigRec(SHA256(SHA256("Lightning Signed Message:Delete appointment
4a5e1e4baab89f3a32518a88c3bc87f6))))
## No compression of penalty transaction
The storage requirements for a Watchtower can be reduced (linearly) by
implementing [shachain](
https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt),
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.
## Attacks on towers
There are three main factors that define how easy is, for a malicious user,
to attack a tower: the `cost` of hiring the tower, the level of user
`privacy` achieved by the service, and who has `access` to the tower's
services.
The most vulnerable Watchtower will, therefore, be a cheap, public, and
completely privacy preserving tower. Privacy being our mail goal, we've
defined parts of this BOLT to prevent cheap attacks, such as favouring
subscriptions over single appointments. Here's an example of what
subscriptions try to protect from:
### Locator reuse attack
Given a locator `l`, a tower that provides a per-appointment hiring service
(appointments can be bought one by one), and complete privacy (no
registration), a malicious user could:
* Send `n` appointments to the tower, all identified by `l`
* Trigger a breach by sending a single old commitment (`txfee`)
The tower will need to store all appointments, since it has no clue which
of them is the valid one (if any). On the other hand, the cost for the
attacker will only be `n * appointment_cost + txfee`.
Upon detection a breach, the tower will need to decrypt and analyse `n`
transactions and left with the decision of what of them to broadcast (if
any).
Using subscriptions, the tower will only store a single appointment, since
all appointments with the same `l` will be seen as updates. An attacker
will need `n` different subscriptions to attempt the same attack. Assuming
a subscription has a minimum size of `m` appointments (`m >> 1`), the cost
for the attacker will be `n * m * appointment_cost + txfee`.
Check [Trustless WatchTowers?](
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/001203.html)
for more on this.
[ADD MORE ATTACKS]
## FIXMES
- Define a proper tower discovery.
- None of the message types have been defined (they have been left with ?).
- Define errors (transient vs permanently).
- Extend attacks on towers
## DISCUSS
- The tower may also need to reply with `appointment_slots` during the
registration phase so a minimum amount of appointments are paid for. Check
[Attacks on towers](#attacks-on-towers). Therefore hiring the tower for a
single appointment may be problematic.
- Signature on the deletion acceptance by the server may not be necessary.
- Appointment deletion can be performed in bulk, by allowing sending more
than one appointment at a time. That could result in a privacy leak though,
since the tower will be able to link what appointments belonged to the same
channel.
- Recognition codes, by ZmnSCPxj, may help here.
- Separate register and top up so proofs can be used for top ups, in a
similar way to [Dead Men's Button](
https://github.com/joostjager/deadmensbutton)
--
Sergi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200309/574d66d1/attachment-0001.html>

2023-06-09 12:57:36

- reply

📅 Original date posted:2019-12-05
📝 Original message:
Hi Rusty, thanks for the feedback!
On Tue, Dec 3, 2019 at 1:26 AM Rusty Russell <rusty at rustcorp.com.au> wrote:
> Hi Sergi!
>
> Great to see progress on this! Detailed comments below.
>
> Sergi Delgado Segura <sergi.delgado.s at gmail.com> 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:
> * MUST send `accepted`
> * Otherwise:
> * MUST send `rejected`
>
OK
>
> > #### Rationale
> >
> > We define appointment as the way that the WatchTower is hired / requested
> > by a client to do it's watching services.
> >
> > 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.
> >
> > The transaction `locator` can be deterministically computed by both the
> > client and the server. Locators of wrong size are therefore invalid.
> >
> > `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.
>
> I think the watchtower should respond with the start_time, instead, so
> the caller knows how much work they have to do. And perhaps the
> end_time, but to be honest I'd add that later.
>
This looks like a good solution for the start time. That way the user knows
what the tower considers "current time". There could also be a default end
time that is picked if the tower and the user haven't agreed on something
else during the payment (or whatever we end up choosing).
> `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.
>
> These values need to be defined. If the user is paying for storage, the
> watchtower doesn't care.
>
Agreed, it depends on the mode of operation from the tower though. For
example, a bounty approach should care about this since some sizes may be
impossible for a transaction to be relayed. On the other hand, if the user
is paying for a certain amount of storage beforehand the tower may not care.
> ### The `appointment_accepted` message
> >
> > This message contains information about the acceptance of an appointment
> by
> > the WatchTower.
> >
> > 1. type: ? (`appointment_accepted `)
> > 2. data:
> > * [`16*byte `:`locator`]
> > * [`u16`: `qos_len`]
> > * [`qos_len*byte`: `qos_data`]
> >
> > The server:
> >
> > * MUST receive `appointment` before sending an `appointment_accepted`
> > message.
> > * MUST set the `locator` to match the one received in `appointment`.
> > * if `qos_data` was requested in `appointment`:
> > * 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`.
> >
> > The client:
> >
> > * MUST fail the connection if `locator` does not match any of locators
> the
> > previously sent to the server:
> >
> > * if `qos` was requested in `appointment`:
> > * MUST fail the connection if `qos_len` is 0.
> > * MUST process `qos_data` according to [Quality of Service
> > data](#quality-of-service-data).
> >
> > ### The `appointment_rejected` message
> >
> > This message contains information about the rejection of an appointment
> by
> > the WatchTower.
> >
> > 1. type: ? (`appointment_rejected `)
> > 2. data:
> > * [`16*byte `:`locator`]
> > * [`u16`: `rcode`]
> > * [`u16`: `reason_len`
> > * [`reason_len*byte`: `reason`]
> >
> > The server:
> >
> > * MUST receive `appointment` before sending an `appointment_rejected`
> > message.
> > * MUST set the `locator` to match the one received in `appointment`.
> > * MUST set `rcode` to the rejection code.
> > * MAY set and empty `reason` field.
> > * MUST set `reason_len` to length of `reason`.
>
> `rcode` needs to be defined. In practice, that's a very difficult
> task. You may just want to define transient vs permanently errors?
>
Can you elaborate on this? I'm not used to error definition at this level
so I could use some help.
>
> > #### Rationale
> >
> > The `appointment_rejected` message follows the approach taken by the
> > `error` message defined in [BOLT#1](
> >
> https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#the-error-message
> ):
> > error codes are mandatory, whereas reasons are optional and
> implementation
> > dependant.
> >
> > ## Quality of Service data
> >
> > `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:
> >
> > * [`u16`: `qos_type`]
> > * [`u16`: `data_len`]
> > * [`data_len*byte`: `data`]
> >
> > So far, only `accountability` is defined.
> >
> > ### `accountability`
> >
> > 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.
> >
> > #### `customer_evidence`
> >
> > The format for the `customer_evidence` is defined as follows:
> >
> > 1. type: ? (`customer_evidence`)
> > 2. data:
> > * [`u64 `:`dispute_delta`]
> > * [`u64`: `transaction_size`]
> > * [`u64`: `transaction_fee`]
> >
> > If `accountability` is being requested, the client:
> >
> > * MUST set `dispute_delta` to the CLTV value specified in the
> > `commitment_transaction`.
>
> I don't understand this field. I assume you're talking about the
> `to_self_delay` the customer requested of its peer. But I don't
> understand why the tower would care: isn't it just going to broadcast
> the tx as soon as it sees the violation?
>
Yes it is, but depending on the approach followed it may be useful. For
instance, if the tower has a dedicated output to top up the fee it may be
worth knowing beforehand what's the to_self_delay so the tower can have a
better strategy (not overpaying fees). The tower will learn that once
decrypted, so it may not be necessary at this level.
> * MUST set `transaction_size` to the size of the serialized
> > `justice_transaction`, in bytes.
> > * MUST set `transaction_fee` to the fee set in the `justice_transaction`,
> > in satoshis.
>
> Just use chacha20, then the size of the transaction is well-defined.
>
> But I don't understand why the fee matters. Neither the watchtower nor
> the customer knows what fee will be needed in the future: all the
> watchtower can do is broadcast what it's given. Unless there's some
> agreement on an output for the watchtower to CPFP (which, IMHO is best
> left to a future extension), but the fee here still doesn't really
> matter.
>
Noted, I'll think about how to fit it in an extension.
> > * MUST set the `customer_signature_algorithm` to one of the signature
> > algorithms supported by the tower.
> > * MUST set `customer_signature` to the signature of the appointment using
> > `op_customer_signature_algorithm`.
> > * MUST set `customer_public_key` to the public key that matches the
> private
> > key used to create `op_customer_signature`.
>
> These aren't defined above (and again, don't define multiple signature
> algorithms.
>
Noted. I'll simplify it to use chacha20 throughout the BOLT.
> You should define here exactly what fields are signed, since this
> message is inside the `appointment`. But it's not clear what purpose
> this signature serves?
>
The signature is to provide an explicit agreement between the user and the
tower (part of the accountability extension). The client side may not be
necessary (as Antoine was mentioning) since the user is already providing a
signed transaction, so that could do. I'll review that.
> > If `accountability` is being offered, the server:
> >
> > * MUST compute the `customer_signature` verification using
> > `customer_public_key`.
> > * SHOULD compute the `fee_rate` set in the `justice_tx` using
> > `transaction_size` and `transaction_fee`.
> >
> > * MUST reject the appointment if:
> > * Any of the fields is missing.
> > * `transaction_size` is unreasonable.
> > * `customer_signature_algorithm` does not match any of the supported
> > signing algorithms.
> > * `customer_signature` cannot be verified using `customer_public_key`.
> >
> > * SHOULD reject the appointment if:
> > * `dispute_delta` is too small.
> > * `fee_rate` is too low.
> >
> > If `accountability` is NOT being offered:
> >
> > * The server MUST reject the appointment.
> >
> > Otherwise:
> >
> > * The server SHOULD accept the appointment.
> >
> > #### Rationale
> >
> > 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.
> >
> > `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.
> >
> > 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.
> >
> > 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.
> >
> > #### `tower_evidence`
> >
> > The format for the `tower_evidence` is defined as follows:
> >
> > 1. type: ? (`tower_evidence`)
> > 2. data:
> > * [`u16 `:`receipt_len`]
> > * [`receipt_len*byte `: `receipt`]
> > * [`u16`: `wt_signature_algorithm`]
> > * [`u16`: `wt_signature_len`
> > * [`wt_signature_len*byte`: `wt_signature`]
> > * [`u16`: `wt_public_key_len`]
> > * [`wt_public_key_len*byte`: `wt_public_key`]
> >
> > The server:
> >
> > * MUST set `receipt` to a receipt built according to
> > [Receipt-Format](#receipt-format).
> > * MUST set `wt_signature_algorithm` to one of the signature algorithms he
> > has announced.
> > * MUST set `wt_signature` to the signature of the appointment using
> > `wt_signature_algorithm`.
> > * MUST set `wt_public_key` to the public key that matches the private key
> > used to create `wt_signature`.
>
> What good is a proof if the watchtower can set a random public key?
>
> Presumably you want the watchtower to sign the txlocator, start_block
> and encrypted blob with a known key. Then you have a proof that it has
> accepted it.
>
True, but the tower could have long-lasting and well known public keys. If
that's the case the key won't be required there.
>
> > The client:
> >
> > * MUST compute the `wt_signature` verification using `wt_public_key`.
> >
> > * MUST fail the connection if:
> > * Any of the fields is missing.
> > * `receipt` does not matches the format specified at
> > [Receipt-Format](#receipt-format)
> > * `receipt` fields do not match the ones sent in the `appointment`
> message.
> > * `wt_signature_algorithm` does not match any of the ones offered by the
> > server.
> > * `wt_signature` cannot be verified using `wt_public_key`.
> >
> > #### Receipt Format
> >
> > The server MUST create the receipt containing the following information:
> >
> > txlocator
> > start_block
> > end_block
> > dispute_delta
> > encrypted_blob
> > transaction_size
> > transaction_fee
> > cipher
> > customer_signature
> > wt_public_key
> >
> >
> > #### Rationale
> >
> > We assume the client has a well-known public key for the WatchTower.
> >
> > The receipt contains, mainly, the information provided by the user. The
> > WatchTower will need to sign the receipt to provide evidence of
> agreement.
> >
> > 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.
> >
> > #### Receipt serialization and signature
> >
> > [FIXME: TBD]
> >
> > ## Transaction Locator and Encryption Key
> >
> > Implementations MUST compute the `locator`, `encryption_key` and
> > `encryption_iv` from the commitment transaction as defined below:
> >
> > - `locator`: first half of the commitment transaction id
> > (`commitment_txid(0,16]`)
> > - `master_key`: Hash of the second half of the commitment transaction id
> > (`SHA256(commitment_txid(16,32])`)
> > - `encryption_key`: first half of the master key (`master_key(0,16]`)
> > - `encryption_iv`: second half of the master key (`master_key(16,32]`)
> >
> >
> > 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.
>
> The SHA256 step here is crypto cargo-culting AFAICT. If the watchtower
> can guess the txid, it does nothing. If it can't, it does nothing.
>
> Setting both the IV and the key is similarly weird. Use an IV of 0 and
> simply use the second half of the commit txid as key.
>
I actually realised that the proposed sizes are wrong from this comment
(they come from defining it with AES-GCM-128 originally). chacha20 needs
32-byte keys, so we'll need to do something like:
locator = commitment_txid(0,16]
key = sha256(commitment_txid)
iv = 0 (12-byte)
Since we're not using the second half of the txid we could define the
locator to be the txid, but having half reduces the storage requirements of
the tower. I think it's worth discussing this.
> > ## Encryption Algorithms and Parameters
> >
> > All clients and servers MUST use one of the following encryption
> > algorithms:
> >
> > - ChaCha20 (https://tools.ietf.org/html/rfc7539)
> > - AES-GCM-256 (https://tools.ietf.org/html/rfc5288)
>
> This would be the first use of AES, and you need to implement chacha20
> to speak to other peers. Drop this.
>
Done.
>
> > Sample code (python) for the client to prepare the `encrypted_blob`:
> >
> > from hashlib import sha256
> > from binascii import hexlify
> >
> > def encrypt(justice_tx, commitment_txid):
> > # master_key = SHA256(commitment_txid(16, 32])
> > master_key = sha256(commitment_txid[16:]).digest()
> >
> > # The 16 MSB of the master key will serve as the AES-GCM-256 secret
> key.
> > The 16 LSB will serve as the IV.
> > sk = master_key[:16]
> > nonce = master_key[16:]
> >
> > # Encrypt the data
> > aesgcm = AESGCM(sk)
> > encrypted_blob = aesgcm.encrypt(nonce=iv, data=tx,
> associated_data=None)
> > encrypted_blob = hexlify(encrypted_blob).decode()
> >
> > return encrypted_blob
>
> > ## Payment modes
> >
> > 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**. An additional output is created in the justice
> > transaction that will reward the WatchTower.
>
> This has the advantage of allowing (and incentivizing!) the WatchTower
> to CPFP. However, it has to be defined (how does client know what addr
> to pay to?), so I'd leave it for later.
>
Agreed.
>
> > **Micropayments**. A small payment is sent to the WatchTower for every
> new
> > job (e.g. over the lightning network)
> >
> > **Subscription**. WatchTower is periodically rewarded / paid for their
> > service to the customer. (e.g. over the lightning network or fiat
> > subscription).
> >
> > 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.
>
> > ## No compression of justice transaction
> >
> > The storage requirements for a WatchTower can be reduced (linearly) by
> > implementing [shachain](
> >
> https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt
> ),
> > 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.
>
> Agreed.
>
> Cheers,
> Rusty.
>
--
Sergi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191205/13928de1/attachment-0001.html>

2023-06-09 12:57:35

- reply

📅 Original date posted:2019-12-05
📝 Original message:
Hey Antoine, thanks for the feedback.
On Fri, Nov 29, 2019 at 6:43 AM Antoine Riard <antoine.riard at gmail.com>
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 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.
>
> > 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 ?
>
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.
>
> 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.
>
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.
>
>
> > * 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.
>
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.
>
> > * 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 may need a populated input mempool.
>
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.
> 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
>
> I can imagine with machine-readable proofs a bot fetching proofs servers,
> verifying them
> on the blockchain and scoring in consequence watchtowers. Good marks could
> be done via
> some tagging of justice tx (like setting nLocktime in the past to some
> value). You would
> negotiate a different tag for everyone of your watchtower. Removing
> feerate from the equation
> would simplify scoring as now you don't have to guess if mempool was
> congestionned or not for
> the client-provided fee.
>
> > On top of that, the onchain bounty allows a network-wise DoS attack for
> free.
>
> A good point of the onchain bounty is the user doesn't pay for inefficient
> watchtower or
> suppleous watchtower. But seems hard to implement DoS-wise and at the same
> time keep the
> requirement of pseudonymous clients. Nevertheless a note maybe said on a
> LN node implementing
> some kind of anyone-can-spend on top of its txn and let the vigilant crowd
> bid with fees
> and confirm your punishment, that's would be the "watchtowerless
> watchtower protocol" :p
>
Yep, we agree is not a straightforward problem to solve, so open to ideas!
>
> > That would break appointment unlinkability but would ease the data
> > management for the tower.
>
> Unlinkability should be far higher in the BOLT design decisions, I think
> people may don't
> care about unlinkability in case of all watchtowers servers are running
> under same
> organization but they are interested by some building blocks of this spec
> like tracking ACK
> or fees management delegation. So we may have multiple formats for the
> transaction
> locator/encryption and one of them being the empty one ?
>
I don't follow you here :sweet_smile:
>
> > The `customer_signature` could be optional if the client does not care
> > that much about the worst case. Dicuss whether that makes sense.
>
> I think you're right it can be skipped as client has provided a signed
> justice
> tx as an implicit commitment ?
>
> Okay that's a lot and it's really IMO, I do think that's important to have
> a flexible protocol
> with a lot of room for further privacy/efficiency/services upgrades and
> circumvent non-seen now
> complexity. If watchtowers are economically/sociably viable it maybe a
> layer of its own!
>
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.
>
> Le mer. 27 nov. 2019 à 15:20, Sergi Delgado Segura <
> sergi.delgado.s at gmail.com> a écrit :
>
>> Hi all,
>>
>> 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).
>>
>> Best,
>>
>> # WatchTower protocol specification (BOLT DRAFT)
>>
>> ## 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, 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).
>>
>> 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.
>>
>> 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.
>>
>> The scope of this document includes:
>>
>> - A protocol for client/server communication.
>> - 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:
>>
>> - A payment protocol between the customer and WatchTower.
>> - WatchTower server discovery.
>>
>> For the rest of this document we will refer to the WatchTower as server,
>> and the user/Lightning node as client.
>>
>> ## Table of Contents
>> * [WatchTower discovery](#watchtower-discovery)
>> * [WatchTower services](#watchtower-discovery)
>> * [Basic Service](#basic-service)
>> * [Quality of Service](#quality-of-service)
>> * [Sending and receiving
>> appointments](#sending-and-receiving-appointments)
>> * [The `appointment` message](#the-appointment-message)
>> * [The `appointment_accepted`
>> message](#the-appointment_accepted-message)
>> * [The `appointment_rejected`
>> message](#the-appointment_rejected-message)
>> * [Quality of Service data](#quality-of-service-data)
>> * [`accountability`](#accountability)
>> * [Transaction Locator and Encryption
>> Key](#transaction-locator-and-encryption-key)
>> * [Encryption Algorithms and
>> Parameters](#encryption-algorithms-and-parameters)
>> * [Payment Modes](#payment-modes)
>> * [No compression of justice
>> transaction](#no-compression-of-justice-transaction)
>>
>> ## 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. 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).
>>
>> ## WatchTower services
>>
>> ### Basic Service
>> 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.
>>
>> ### Quality of Service
>> 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.
>>
>> For now we are defining a single type of `qos`: `accountability`.
>>
>> #### `accountability`
>>
>> 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.
>>
>> ## 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`]
>> * [`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.
>> * MUST set `end_block` to the block height at which he requests the
>> server to stop watching for breaches.
>> * MUST set `encrypted_blob` to the encryption of the
>> `justice_transaction` as specified in [Transaction Locator and Encryption
>> Key](#transaction-locator-and-encryption-key).
>> * MUST set `cipher` to the cipher used to create the `encrypted_blob`.
>> * MAY send an empty `auth_token` field.
>> * MUST set `auth_token_len` to the length of `auth_token`.
>> * 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`.
>>
>> 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.
>> * `start_block` is further than one block behind the current chain tip.
>> * `start_block` is further than one block ahead the current chain tip.
>> * `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.
>>
>> * 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.
>>
>> #### Rationale
>>
>> We define appointment as the way that the WatchTower is hired / requested
>> by a client to do it's watching services.
>>
>> 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.
>>
>> The transaction `locator` can be deterministically computed by both the
>> client and the server. Locators of wrong size are therefore invalid.
>>
>> `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.
>>
>> 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.
>>
>> 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:
>>
>> `cipher_block_size * ceil(minimum_viable_transaction_size /
>> cipher_block_size)`
>>
>> and at most as big as:
>>
>> `cipher_block_size * ceil(maximum_viable_transaction_size /
>> cipher_block_size`)
>>
>> `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.
>>
>> The client should have learn about the `ciphers` implemented by the
>> WatchTower and the `qos` that the tower is offering during the peer
>> discovery.
>>
>> A tower must not accept appointments using a cipher it does not
>> implement, otherwise the decryption of the `encrypted_blob` will not be
>> possible.
>>
>> `qos` is optional and can include multiple services.
>>
>> ### The `appointment_accepted` message
>>
>> This message contains information about the acceptance of an appointment
>> by the WatchTower.
>>
>> 1. type: ? (`appointment_accepted `)
>> 2. data:
>> * [`16*byte `:`locator`]
>> * [`u16`: `qos_len`]
>> * [`qos_len*byte`: `qos_data`]
>>
>> The server:
>>
>> * MUST receive `appointment` before sending an `appointment_accepted`
>> message.
>> * MUST set the `locator` to match the one received in `appointment`.
>> * if `qos_data` was requested in `appointment`:
>> * 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`.
>>
>> The client:
>>
>> * MUST fail the connection if `locator` does not match any of locators
>> the previously sent to the server:
>>
>> * if `qos` was requested in `appointment`:
>> * MUST fail the connection if `qos_len` is 0.
>> * MUST process `qos_data` according to [Quality of Service
>> data](#quality-of-service-data).
>>
>> ### The `appointment_rejected` message
>>
>> This message contains information about the rejection of an appointment
>> by the WatchTower.
>>
>> 1. type: ? (`appointment_rejected `)
>> 2. data:
>> * [`16*byte `:`locator`]
>> * [`u16`: `rcode`]
>> * [`u16`: `reason_len`
>> * [`reason_len*byte`: `reason`]
>>
>> The server:
>>
>> * MUST receive `appointment` before sending an `appointment_rejected`
>> message.
>> * MUST set the `locator` to match the one received in `appointment`.
>> * MUST set `rcode` to the rejection code.
>> * MAY set and empty `reason` field.
>> * MUST set `reason_len` to length of `reason`.
>>
>> #### Rationale
>>
>> The `appointment_rejected` message follows the approach taken by the
>> `error` message defined in [BOLT#1](
>> https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#the-error-message):
>> error codes are mandatory, whereas reasons are optional and implementation
>> dependant.
>>
>> ## Quality of Service data
>>
>> `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:
>>
>> * [`u16`: `qos_type`]
>> * [`u16`: `data_len`]
>> * [`data_len*byte`: `data`]
>>
>> So far, only `accountability` is defined.
>>
>> ### `accountability`
>>
>> 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.
>>
>> #### `customer_evidence`
>>
>> The format for the `customer_evidence` is defined as follows:
>>
>> 1. type: ? (`customer_evidence`)
>> 2. data:
>> * [`u64 `:`dispute_delta`]
>> * [`u64`: `transaction_size`]
>> * [`u64`: `transaction_fee`]
>>
>> If `accountability` is being requested, the client:
>>
>> * MUST set `dispute_delta` to the CLTV value specified in the
>> `commitment_transaction`.
>> * MUST set `transaction_size` to the size of the serialized
>> `justice_transaction`, in bytes.
>> * MUST set `transaction_fee` to the fee set in the `justice_transaction`,
>> in satoshis.
>> * MUST set the `customer_signature_algorithm` to one of the signature
>> algorithms supported by the tower.
>> * MUST set `customer_signature` to the signature of the appointment using
>> `op_customer_signature_algorithm`.
>> * MUST set `customer_public_key` to the public key that matches the
>> private key used to create `op_customer_signature`.
>>
>> If `accountability` is being offered, the server:
>>
>> * MUST compute the `customer_signature` verification using
>> `customer_public_key`.
>> * SHOULD compute the `fee_rate` set in the `justice_tx` using
>> `transaction_size` and `transaction_fee`.
>>
>> * MUST reject the appointment if:
>> * Any of the fields is missing.
>> * `transaction_size` is unreasonable.
>> * `customer_signature_algorithm` does not match any of the supported
>> signing algorithms.
>> * `customer_signature` cannot be verified using `customer_public_key`.
>>
>> * SHOULD reject the appointment if:
>> * `dispute_delta` is too small.
>> * `fee_rate` is too low.
>>
>> If `accountability` is NOT being offered:
>>
>> * The server MUST reject the appointment.
>>
>> Otherwise:
>>
>> * The server SHOULD accept the appointment.
>>
>> #### Rationale
>>
>> 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.
>>
>> `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.
>>
>> 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.
>>
>> 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.
>>
>> #### `tower_evidence`
>>
>> The format for the `tower_evidence` is defined as follows:
>>
>> 1. type: ? (`tower_evidence`)
>> 2. data:
>> * [`u16 `:`receipt_len`]
>> * [`receipt_len*byte `: `receipt`]
>> * [`u16`: `wt_signature_algorithm`]
>> * [`u16`: `wt_signature_len`
>> * [`wt_signature_len*byte`: `wt_signature`]
>> * [`u16`: `wt_public_key_len`]
>> * [`wt_public_key_len*byte`: `wt_public_key`]
>>
>> The server:
>>
>> * MUST set `receipt` to a receipt built according to
>> [Receipt-Format](#receipt-format).
>> * MUST set `wt_signature_algorithm` to one of the signature algorithms he
>> has announced.
>> * MUST set `wt_signature` to the signature of the appointment using
>> `wt_signature_algorithm`.
>> * MUST set `wt_public_key` to the public key that matches the private key
>> used to create `wt_signature`.
>>
>> The client:
>>
>> * MUST compute the `wt_signature` verification using `wt_public_key`.
>>
>> * MUST fail the connection if:
>> * Any of the fields is missing.
>> * `receipt` does not matches the format specified at
>> [Receipt-Format](#receipt-format)
>> * `receipt` fields do not match the ones sent in the `appointment`
>> message.
>> * `wt_signature_algorithm` does not match any of the ones offered by the
>> server.
>> * `wt_signature` cannot be verified using `wt_public_key`.
>>
>> #### Receipt Format
>>
>> The server MUST create the receipt containing the following information:
>>
>> txlocator
>> start_block
>> end_block
>> dispute_delta
>> encrypted_blob
>> transaction_size
>> transaction_fee
>> cipher
>> customer_signature
>> wt_public_key
>>
>>
>> #### Rationale
>>
>> We assume the client has a well-known public key for the WatchTower.
>>
>> The receipt contains, mainly, the information provided by the user. The
>> WatchTower will need to sign the receipt to provide evidence of agreement.
>>
>> 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.
>>
>> #### Receipt serialization and signature
>>
>> [FIXME: TBD]
>>
>> ## Transaction Locator and Encryption Key
>>
>> Implementations MUST compute the `locator`, `encryption_key` and
>> `encryption_iv` from the commitment transaction as defined below:
>>
>> - `locator`: first half of the commitment transaction id
>> (`commitment_txid(0,16]`)
>> - `master_key`: Hash of the second half of the commitment transaction id
>> (`SHA256(commitment_txid(16,32])`)
>> - `encryption_key`: first half of the master key (`master_key(0,16]`)
>> - `encryption_iv`: second half of the master key (`master_key(16,32]`)
>>
>>
>> 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.
>>
>> ## Encryption Algorithms and Parameters
>>
>> All clients and servers MUST use one of the following encryption
>> algorithms:
>>
>> - ChaCha20 (https://tools.ietf.org/html/rfc7539)
>> - AES-GCM-256 (https://tools.ietf.org/html/rfc5288)
>>
>> Sample code (python) for the client to prepare the `encrypted_blob`:
>>
>> from hashlib import sha256
>> from binascii import hexlify
>>
>> def encrypt(justice_tx, commitment_txid):
>> # master_key = SHA256(commitment_txid(16, 32])
>> master_key = sha256(commitment_txid[16:]).digest()
>>
>> # The 16 MSB of the master key will serve as the AES-GCM-256 secret
>> key. The 16 LSB will serve as the IV.
>> sk = master_key[:16]
>> nonce = master_key[16:]
>>
>> # Encrypt the data
>> aesgcm = AESGCM(sk)
>> encrypted_blob = aesgcm.encrypt(nonce=iv, data=tx,
>> associated_data=None)
>> encrypted_blob = hexlify(encrypted_blob).decode()
>>
>> return encrypted_blob
>>
>> ## Payment modes
>>
>> 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**. An additional output is created in the justice
>> transaction that will reward the WatchTower.
>>
>> **Micropayments**. A small payment is sent to the WatchTower for every
>> new job (e.g. over the lightning network)
>>
>> **Subscription**. WatchTower is periodically rewarded / paid for their
>> service to the customer. (e.g. over the lightning network or fiat
>> subscription).
>>
>> 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.
>>
>> ## No compression of justice transaction
>>
>> The storage requirements for a WatchTower can be reduced (linearly) by
>> implementing [shachain](
>> https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt),
>> 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.
>>
>> ## FIXMES
>>
>> - Define a proper tower discovery.
>> - Define authentication mechanism (macaroons maybe?).
>> - None of the message types have been defined (they have been left with
>> ?).
>> - Define receipt serialization format.
>> - `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`.
>> - 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.
>> - The `customer_signature` could be optional if the client does not care
>> that much about the worst case. Dicuss whether that makes sense.
>> - Discuss whether to extend it with shachain.
>>
>>
>> The document can also be found here:
>> https://github.com/PISAresearch/pisa/blob/master/13-watchtower-API.md
>>
>> --
>> Sergi.
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
--
Sergi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191205/ca448e0e/attachment-0001.html>

2023-06-09 12:57:29

- reply

📅 Original date posted:2019-11-27
📝 Original message:
Hi all,
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).
Best,
# WatchTower protocol specification (BOLT DRAFT)
## 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, 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).
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.
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.
The scope of this document includes:
- A protocol for client/server communication.
- 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:
- A payment protocol between the customer and WatchTower.
- WatchTower server discovery.
For the rest of this document we will refer to the WatchTower as server,
and the user/Lightning node as client.
## Table of Contents
* [WatchTower discovery](#watchtower-discovery)
* [WatchTower services](#watchtower-discovery)
* [Basic Service](#basic-service)
* [Quality of Service](#quality-of-service)
* [Sending and receiving appointments](#sending-and-receiving-appointments)
* [The `appointment` message](#the-appointment-message)
* [The `appointment_accepted` message](#the-appointment_accepted-message)
* [The `appointment_rejected` message](#the-appointment_rejected-message)
* [Quality of Service data](#quality-of-service-data)
* [`accountability`](#accountability)
* [Transaction Locator and Encryption
Key](#transaction-locator-and-encryption-key)
* [Encryption Algorithms and
Parameters](#encryption-algorithms-and-parameters)
* [Payment Modes](#payment-modes)
* [No compression of justice
transaction](#no-compression-of-justice-transaction)
## 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. 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).
## WatchTower services
### Basic Service
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.
### Quality of Service
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.
For now we are defining a single type of `qos`: `accountability`.
#### `accountability`
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.
## 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`]
* [`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.
* MUST set `end_block` to the block height at which he requests the server
to stop watching for breaches.
* MUST set `encrypted_blob` to the encryption of the `justice_transaction`
as specified in [Transaction Locator and Encryption
Key](#transaction-locator-and-encryption-key).
* MUST set `cipher` to the cipher used to create the `encrypted_blob`.
* MAY send an empty `auth_token` field.
* MUST set `auth_token_len` to the length of `auth_token`.
* 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`.
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.
* `start_block` is further than one block behind the current chain tip.
* `start_block` is further than one block ahead the current chain tip.
* `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.
* 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.
#### Rationale
We define appointment as the way that the WatchTower is hired / requested
by a client to do it's watching services.
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.
The transaction `locator` can be deterministically computed by both the
client and the server. Locators of wrong size are therefore invalid.
`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.
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.
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:
`cipher_block_size * ceil(minimum_viable_transaction_size /
cipher_block_size)`
and at most as big as:
`cipher_block_size * ceil(maximum_viable_transaction_size /
cipher_block_size`)
`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.
The client should have learn about the `ciphers` implemented by the
WatchTower and the `qos` that the tower is offering during the peer
discovery.
A tower must not accept appointments using a cipher it does not implement,
otherwise the decryption of the `encrypted_blob` will not be possible.
`qos` is optional and can include multiple services.
### The `appointment_accepted` message
This message contains information about the acceptance of an appointment by
the WatchTower.
1. type: ? (`appointment_accepted `)
2. data:
* [`16*byte `:`locator`]
* [`u16`: `qos_len`]
* [`qos_len*byte`: `qos_data`]
The server:
* MUST receive `appointment` before sending an `appointment_accepted`
message.
* MUST set the `locator` to match the one received in `appointment`.
* if `qos_data` was requested in `appointment`:
* 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`.
The client:
* MUST fail the connection if `locator` does not match any of locators the
previously sent to the server:
* if `qos` was requested in `appointment`:
* MUST fail the connection if `qos_len` is 0.
* MUST process `qos_data` according to [Quality of Service
data](#quality-of-service-data).
### The `appointment_rejected` message
This message contains information about the rejection of an appointment by
the WatchTower.
1. type: ? (`appointment_rejected `)
2. data:
* [`16*byte `:`locator`]
* [`u16`: `rcode`]
* [`u16`: `reason_len`
* [`reason_len*byte`: `reason`]
The server:
* MUST receive `appointment` before sending an `appointment_rejected`
message.
* MUST set the `locator` to match the one received in `appointment`.
* MUST set `rcode` to the rejection code.
* MAY set and empty `reason` field.
* MUST set `reason_len` to length of `reason`.
#### Rationale
The `appointment_rejected` message follows the approach taken by the
`error` message defined in [BOLT#1](
https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#the-error-message):
error codes are mandatory, whereas reasons are optional and implementation
dependant.
## Quality of Service data
`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:
* [`u16`: `qos_type`]
* [`u16`: `data_len`]
* [`data_len*byte`: `data`]
So far, only `accountability` is defined.
### `accountability`
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.
#### `customer_evidence`
The format for the `customer_evidence` is defined as follows:
1. type: ? (`customer_evidence`)
2. data:
* [`u64 `:`dispute_delta`]
* [`u64`: `transaction_size`]
* [`u64`: `transaction_fee`]
If `accountability` is being requested, the client:
* MUST set `dispute_delta` to the CLTV value specified in the
`commitment_transaction`.
* MUST set `transaction_size` to the size of the serialized
`justice_transaction`, in bytes.
* MUST set `transaction_fee` to the fee set in the `justice_transaction`,
in satoshis.
* MUST set the `customer_signature_algorithm` to one of the signature
algorithms supported by the tower.
* MUST set `customer_signature` to the signature of the appointment using
`op_customer_signature_algorithm`.
* MUST set `customer_public_key` to the public key that matches the private
key used to create `op_customer_signature`.
If `accountability` is being offered, the server:
* MUST compute the `customer_signature` verification using
`customer_public_key`.
* SHOULD compute the `fee_rate` set in the `justice_tx` using
`transaction_size` and `transaction_fee`.
* MUST reject the appointment if:
* Any of the fields is missing.
* `transaction_size` is unreasonable.
* `customer_signature_algorithm` does not match any of the supported
signing algorithms.
* `customer_signature` cannot be verified using `customer_public_key`.
* SHOULD reject the appointment if:
* `dispute_delta` is too small.
* `fee_rate` is too low.
If `accountability` is NOT being offered:
* The server MUST reject the appointment.
Otherwise:
* The server SHOULD accept the appointment.
#### Rationale
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.
`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.
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.
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.
#### `tower_evidence`
The format for the `tower_evidence` is defined as follows:
1. type: ? (`tower_evidence`)
2. data:
* [`u16 `:`receipt_len`]
* [`receipt_len*byte `: `receipt`]
* [`u16`: `wt_signature_algorithm`]
* [`u16`: `wt_signature_len`
* [`wt_signature_len*byte`: `wt_signature`]
* [`u16`: `wt_public_key_len`]
* [`wt_public_key_len*byte`: `wt_public_key`]
The server:
* MUST set `receipt` to a receipt built according to
[Receipt-Format](#receipt-format).
* MUST set `wt_signature_algorithm` to one of the signature algorithms he
has announced.
* MUST set `wt_signature` to the signature of the appointment using
`wt_signature_algorithm`.
* MUST set `wt_public_key` to the public key that matches the private key
used to create `wt_signature`.
The client:
* MUST compute the `wt_signature` verification using `wt_public_key`.
* MUST fail the connection if:
* Any of the fields is missing.
* `receipt` does not matches the format specified at
[Receipt-Format](#receipt-format)
* `receipt` fields do not match the ones sent in the `appointment` message.
* `wt_signature_algorithm` does not match any of the ones offered by the
server.
* `wt_signature` cannot be verified using `wt_public_key`.
#### Receipt Format
The server MUST create the receipt containing the following information:
txlocator
start_block
end_block
dispute_delta
encrypted_blob
transaction_size
transaction_fee
cipher
customer_signature
wt_public_key
#### Rationale
We assume the client has a well-known public key for the WatchTower.
The receipt contains, mainly, the information provided by the user. The
WatchTower will need to sign the receipt to provide evidence of agreement.
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.
#### Receipt serialization and signature
[FIXME: TBD]
## Transaction Locator and Encryption Key
Implementations MUST compute the `locator`, `encryption_key` and
`encryption_iv` from the commitment transaction as defined below:
- `locator`: first half of the commitment transaction id
(`commitment_txid(0,16]`)
- `master_key`: Hash of the second half of the commitment transaction id
(`SHA256(commitment_txid(16,32])`)
- `encryption_key`: first half of the master key (`master_key(0,16]`)
- `encryption_iv`: second half of the master key (`master_key(16,32]`)
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.
## Encryption Algorithms and Parameters
All clients and servers MUST use one of the following encryption
algorithms:
- ChaCha20 (https://tools.ietf.org/html/rfc7539)
- AES-GCM-256 (https://tools.ietf.org/html/rfc5288)
Sample code (python) for the client to prepare the `encrypted_blob`:
from hashlib import sha256
from binascii import hexlify
def encrypt(justice_tx, commitment_txid):
# master_key = SHA256(commitment_txid(16, 32])
master_key = sha256(commitment_txid[16:]).digest()
# The 16 MSB of the master key will serve as the AES-GCM-256 secret key.
The 16 LSB will serve as the IV.
sk = master_key[:16]
nonce = master_key[16:]
# Encrypt the data
aesgcm = AESGCM(sk)
encrypted_blob = aesgcm.encrypt(nonce=iv, data=tx, associated_data=None)
encrypted_blob = hexlify(encrypted_blob).decode()
return encrypted_blob
## Payment modes
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**. An additional output is created in the justice
transaction that will reward the WatchTower.
**Micropayments**. A small payment is sent to the WatchTower for every new
job (e.g. over the lightning network)
**Subscription**. WatchTower is periodically rewarded / paid for their
service to the customer. (e.g. over the lightning network or fiat
subscription).
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.
## No compression of justice transaction
The storage requirements for a WatchTower can be reduced (linearly) by
implementing [shachain](
https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt),
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.
## FIXMES
- Define a proper tower discovery.
- Define authentication mechanism (macaroons maybe?).
- None of the message types have been defined (they have been left with ?).
- Define receipt serialization format.
- `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`.
- 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.
- The `customer_signature` could be optional if the client does not care
that much about the worst case. Dicuss whether that makes sense.
- Discuss whether to extend it with shachain.
The document can also be found here:
https://github.com/PISAresearch/pisa/blob/master/13-watchtower-API.md
--
Sergi.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191127/2215f4f5/attachment-0001.html>