<div dir="ltr"><div dir="ltr">Hi Rusty, thanks for the feedback!<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Dec 3, 2019 at 1:26 AM Rusty Russell <<a href="mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Sergi!<br>
<br>
Great to see progress on this! Detailed comments below.<br>
<br>
Sergi Delgado Segura <<a href="mailto:sergi.delgado.s@gmail.com" target="_blank">sergi.delgado.s@gmail.com</a>> writes:<br>
> ## Sending and receiving appointments<br>
><br>
> Once the client is aware of the services provided by the server, the former<br>
> can start sending appointments to the latter.<br>
><br>
> +-------+ +-------+<br>
> | A |--(1)--- appointment ---->| B |<br>
> | |<-(2)--- accepted/rejected -----| |<br>
> +-------+ +-------+<br>
><br>
> - where node A is 'client' and node B is 'server'<br>
><br>
> ### The `appointment` message<br>
><br>
> This message contains all the information regarding the appointment that<br>
> the client wants to arrange with the server.<br>
><br>
> 1. type: ? (`appointment`)<br>
> 2. data:<br>
> * [`16*byte`:`locator`]<br>
> * [`u64 `:`start_block`]<br>
> * [`u64 `:`end_block`]<br>
<br>
u32 is sufficient for start_block, fwiw.<br></blockquote><div><br></div><div>OK</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * [`u16`: `encrypted_blob_len`<br>
> * [`encrypted_blob_len*byte`:`encrypted_blob`]<br>
> * [`u16`:`cipher`]<br>
> * [`u16`: `auth_token_len`]<br>
> * [`auth_token_len*byte`: `auth_token`]<br>
> * [`u16`: `qos_len`]<br>
> * [`qos_len*byte`: `qos_data`]<br>
><br>
> #### Requirements<br>
><br>
> The client:<br>
><br>
> * MUST set `locator` as specified in [Transaction Locator and Encryption<br>
> Key](#transaction-locator-and-encryption-key).<br>
> * MUST set `start_block` to the current chain tip height.<br>
<br>
What is the purpose of this field? Presumably the watcher knows the<br>
current block number.<br>
<br>
I suggest you want this to be "the first possible block in which the<br>
transction can occur"?<br></blockquote><div><br></div><div>Indeed<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * MUST set `end_block` to the block height at which he requests the server<br>
> to stop watching for breaches.<br>
<br>
I don't know how you would set that. I think you need this to be<br>
separate: either as part of the payment layer (I will watch for a year),<br>
or an explicit "stop watching" message (assuming that you pay for<br>
certain capacity).<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * MUST set `encrypted_blob` to the encryption of the `justice_transaction`<br>
> as specified in [Transaction Locator and Encryption<br>
> Key](#transaction-locator-and-encryption-key).<br>
<br>
The phrase used in the spec is penalty transaction, BTW. Especially<br>
since its use is generally an injustice :)<br></blockquote><div><br></div><div>Sorry about that >.<</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * MUST set `cipher` to the cipher used to create the `encrypted_blob`.<br>
<br>
Don't do this. Pick a cipher already used elsewhere in the protocol.<br>
chacha20 is a good choice.<br></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * MAY send an empty `auth_token` field.<br>
> * MUST set `auth_token_len` to the length of `auth_token`.<br>
<br>
The latter is already written in the spec. But these days, optional<br>
fields are implemented as TLV data, so perhaps use that instead.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * MAY send an empty `qos_data` field.<br>
> * if `qos_data` is not empty:<br>
> * MUST set `qos_data` according to [Quality of Service<br>
> data](#quality-of-service-data).<br>
> * MUST set `qos_len` equal to the length of `qos_data`.<br>
<br>
I would drop the idea of "qos", and again use TLV data, defining<br>
accountability. Others can be added later.<br></blockquote><div><br></div><div>OK, I'll give it a look.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The server:<br>
><br>
> * MUST reject the appointment if:<br>
> * Authentication is required and `auth_token` is not provided.<br>
> * Authentication is required and `auth_token` is invalid.<br>
<br>
> * `locator` is not a `16-byte` value.<br>
<br>
This cannot happen, so eliminate it.<br></blockquote><div><br></div><div>Noted</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * `start_block` is further than one block behind the current chain tip.<br>
> * `start_block` is further than one block ahead the current chain tip.<br>
<br>
I'm still not sure what start_block is for. It just seems to make<br>
things fragile if blocks arrive quickly.<br></blockquote><div><br></div><div>The rationale is to prevent users to ask the tower to look for passed events.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * `encrypted_blob` has unreasonable size.<br>
> * `cipher` is not among the ones he implements.<br>
><br>
> * SHOULD reject the appointment if`end_block` is too far away in the future.<br>
<br>
This is a problem, since in practice we'll have to define what that is.<br></blockquote><div><br></div><div>Agreed. As mentioned before it seems reasonable to do it during hiring. Open to other ideas too though.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * MUST:<br>
> * truncate the remainder of the package to `qos_len`.<br>
> * process `qos_data` according to [Quality of Service<br>
> data](#quality-of-service-data) if `qos_len` is not 0.<br>
><br>
> * MAY accept the appointment otherwise.<br>
<br>
I would suggest:<br>
<br>
* If it accepts the appointment:<br>
* MUST send `accepted`<br>
* Otherwise:<br>
* MUST send `rejected`<br></blockquote><div><br></div><div>OK</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> #### Rationale<br>
><br>
> We define appointment as the way that the WatchTower is hired / requested<br>
> by a client to do it's watching services.<br>
><br>
> WatchTowers may offer their services for free (`altruistic`) or they may<br>
> require a payment when accepting the job (`non-altruistic`). We have<br>
> defined `auth_token` as an authentication mechanism between the client and<br>
> server, so the client can prove they are entitled to the service. The<br>
> tokens are not required to be linked to any kind of identity (e.g. blinded<br>
> tokens), but their sole purpose is to confirm the client has already paid<br>
> for the service.<br>
><br>
> The transaction `locator` can be deterministically computed by both the<br>
> client and the server. Locators of wrong size are therefore invalid.<br>
><br>
> `start_block` can be either one block ahead or behind the tower tip due to<br>
> network delays. A tower must not accept appointments arbitrarily ahead or<br>
> behind the current tip since it could increase DoS vectors. A `start_block`<br>
> long behind would force the tower to rescan block data for those<br>
> appointments instead of watching block by block. On the other hand, a<br>
> `start_time` long ahead would imply storing information way before it being<br>
> needed.<br>
<br>
I think the watchtower should respond with the start_time, instead, so<br>
the caller knows how much work they have to do. And perhaps the<br>
end_time, but to be honest I'd add that later.<br></blockquote><div><br></div><div>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).</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> `minimum_viable_transaction_size` and `maximum_viable_transaction_size`<br>
> refer to the minimum/maximum size required to create a valid transaction.<br>
> Accepting `encrypted_blob` outside those boundaries will increase DoS<br>
> attacks on the server.<br>
<br>
These values need to be defined. If the user is paying for storage, the<br>
watchtower doesn't care.<br></blockquote><div><br></div><div>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.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> ### The `appointment_accepted` message<br>
><br>
> This message contains information about the acceptance of an appointment by<br>
> the WatchTower.<br>
><br>
> 1. type: ? (`appointment_accepted `)<br>
> 2. data:<br>
> * [`16*byte `:`locator`]<br>
> * [`u16`: `qos_len`]<br>
> * [`qos_len*byte`: `qos_data`]<br>
><br>
> The server:<br>
><br>
> * MUST receive `appointment` before sending an `appointment_accepted`<br>
> message.<br>
> * MUST set the `locator` to match the one received in `appointment`.<br>
> * if `qos_data` was requested in `appointment`:<br>
> * MUST set `qos_data` according to [Quality of Service<br>
> data](#quality-of-service-data).<br>
> * MUST set `qos_len` equal to the length of `qos_data`.<br>
><br>
> The client:<br>
><br>
> * MUST fail the connection if `locator` does not match any of locators the<br>
> previously sent to the server:<br>
><br>
> * if `qos` was requested in `appointment`:<br>
> * MUST fail the connection if `qos_len` is 0.<br>
> * MUST process `qos_data` according to [Quality of Service<br>
> data](#quality-of-service-data).<br>
><br>
> ### The `appointment_rejected` message<br>
><br>
> This message contains information about the rejection of an appointment by<br>
> the WatchTower.<br>
><br>
> 1. type: ? (`appointment_rejected `)<br>
> 2. data:<br>
> * [`16*byte `:`locator`]<br>
> * [`u16`: `rcode`]<br>
> * [`u16`: `reason_len`<br>
> * [`reason_len*byte`: `reason`]<br>
><br>
> The server:<br>
><br>
> * MUST receive `appointment` before sending an `appointment_rejected`<br>
> message.<br>
> * MUST set the `locator` to match the one received in `appointment`.<br>
> * MUST set `rcode` to the rejection code.<br>
> * MAY set and empty `reason` field.<br>
> * MUST set `reason_len` to length of `reason`.<br>
<br>
`rcode` needs to be defined. In practice, that's a very difficult<br>
task. You may just want to define transient vs permanently errors?<br></blockquote><div><br></div><div>Can you elaborate on this? I'm not used to error definition at this level so I could use some help.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> #### Rationale<br>
><br>
> The `appointment_rejected` message follows the approach taken by the<br>
> `error` message defined in [BOLT#1](<br>
> <a href="https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#the-error-message" rel="noreferrer" target="_blank">https://github.com/lightningnetwork/lightning-rfc/blob/master/01-messaging.md#the-error-message</a>):<br>
> error codes are mandatory, whereas reasons are optional and implementation<br>
> dependant.<br>
><br>
> ## Quality of Service data<br>
><br>
> `qos_data` is a list where each field specifies they type and associated<br>
> data of the offered/requested `qos`. The format is defined as follows:<br>
><br>
> * [`u16`: `qos_type`]<br>
> * [`u16`: `data_len`]<br>
> * [`data_len*byte`: `data`]<br>
><br>
> So far, only `accountability` is defined.<br>
><br>
> ### `accountability`<br>
><br>
> The accountability `qos` defines a pair `qos_data` blobs, associated to a<br>
> pair of messages: The first one is `customer_evidence` and it is provided<br>
> by the `client` in the `appointment` message. The second one is<br>
> `tower_evidence`, and is provided by the WatchTower in the<br>
> `appointment_accepted` message.<br>
><br>
> #### `customer_evidence`<br>
><br>
> The format for the `customer_evidence` is defined as follows:<br>
><br>
> 1. type: ? (`customer_evidence`)<br>
> 2. data:<br>
> * [`u64 `:`dispute_delta`]<br>
> * [`u64`: `transaction_size`]<br>
> * [`u64`: `transaction_fee`]<br>
><br>
> If `accountability` is being requested, the client:<br>
><br>
> * MUST set `dispute_delta` to the CLTV value specified in the<br>
> `commitment_transaction`.<br>
<br>
I don't understand this field. I assume you're talking about the<br>
`to_self_delay` the customer requested of its peer. But I don't<br>
understand why the tower would care: isn't it just going to broadcast<br>
the tx as soon as it sees the violation?<br></blockquote><div><br></div><div>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.</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> * MUST set `transaction_size` to the size of the serialized<br>
> `justice_transaction`, in bytes.<br>
> * MUST set `transaction_fee` to the fee set in the `justice_transaction`,<br>
> in satoshis.<br>
<br>
Just use chacha20, then the size of the transaction is well-defined.<br>
<br>
But I don't understand why the fee matters. Neither the watchtower nor<br>
the customer knows what fee will be needed in the future: all the<br>
watchtower can do is broadcast what it's given. Unless there's some<br>
agreement on an output for the watchtower to CPFP (which, IMHO is best<br>
left to a future extension), but the fee here still doesn't really<br>
matter.<br></blockquote><div><br></div><div>Noted, I'll think about how to fit it in an extension.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> * MUST set the `customer_signature_algorithm` to one of the signature<br>
> algorithms supported by the tower.<br>
> * MUST set `customer_signature` to the signature of the appointment using<br>
> `op_customer_signature_algorithm`.<br>
> * MUST set `customer_public_key` to the public key that matches the private<br>
> key used to create `op_customer_signature`.<br>
<br>
These aren't defined above (and again, don't define multiple signature<br>
algorithms.<br></blockquote><div><br></div><div>Noted. I'll simplify it to use chacha20 throughout the BOLT. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You should define here exactly what fields are signed, since this<br>
message is inside the `appointment`. But it's not clear what purpose<br>
this signature serves?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> If `accountability` is being offered, the server:<br>
><br>
> * MUST compute the `customer_signature` verification using<br>
> `customer_public_key`.<br>
> * SHOULD compute the `fee_rate` set in the `justice_tx` using<br>
> `transaction_size` and `transaction_fee`.<br>
><br>
> * MUST reject the appointment if:<br>
> * Any of the fields is missing.<br>
> * `transaction_size` is unreasonable.<br>
> * `customer_signature_algorithm` does not match any of the supported<br>
> signing algorithms.<br>
> * `customer_signature` cannot be verified using `customer_public_key`.<br>
><br>
> * SHOULD reject the appointment if:<br>
> * `dispute_delta` is too small.<br>
> * `fee_rate` is too low.<br>
><br>
> If `accountability` is NOT being offered:<br>
><br>
> * The server MUST reject the appointment.<br>
><br>
> Otherwise:<br>
><br>
> * The server SHOULD accept the appointment.<br>
><br>
> #### Rationale<br>
><br>
> The concept of too small for `dispute_delta` is subjective. The<br>
> `dispute_delta` defines the time (in blocks) that the tower has in order to<br>
> respond after a breach is seen. The smaller the value, the more the server<br>
> risks to fail the appointment.<br>
><br>
> `transaction_size` and `transaction_fee` help the WatchTower to decide on<br>
> the likelihood of an appointment being fulfilled. Appointments with<br>
> `fee_rate` too low may be rejected by the WatchTower. While a customer can<br>
> always fake this values, it should break ToS between the client and the<br>
> server and, therefore, release the WatchTower of any liability.<br>
><br>
> By accepting the request, the tower is offering a reputationally<br>
> accountable watching service. If `accountability` is not offered, then the<br>
> tower will not accept appointments requesting for it.<br>
><br>
> As well, the WatchTower must check the transaction details before deciding<br>
> whether it will accept it. If the decrypted justice transaction does not<br>
> satisfy the job details (e.g. too low fee), then the tower is not obliged<br>
> to fulfil the appointment.<br>
><br>
> #### `tower_evidence`<br>
><br>
> The format for the `tower_evidence` is defined as follows:<br>
><br>
> 1. type: ? (`tower_evidence`)<br>
> 2. data:<br>
> * [`u16 `:`receipt_len`]<br>
> * [`receipt_len*byte `: `receipt`]<br>
> * [`u16`: `wt_signature_algorithm`]<br>
> * [`u16`: `wt_signature_len`<br>
> * [`wt_signature_len*byte`: `wt_signature`]<br>
> * [`u16`: `wt_public_key_len`]<br>
> * [`wt_public_key_len*byte`: `wt_public_key`]<br>
><br>
> The server:<br>
><br>
> * MUST set `receipt` to a receipt built according to<br>
> [Receipt-Format](#receipt-format).<br>
> * MUST set `wt_signature_algorithm` to one of the signature algorithms he<br>
> has announced.<br>
> * MUST set `wt_signature` to the signature of the appointment using<br>
> `wt_signature_algorithm`.<br>
> * MUST set `wt_public_key` to the public key that matches the private key<br>
> used to create `wt_signature`.<br>
<br>
What good is a proof if the watchtower can set a random public key?<br>
<br>
Presumably you want the watchtower to sign the txlocator, start_block<br>
and encrypted blob with a known key. Then you have a proof that it has<br>
accepted it.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The client:<br>
><br>
> * MUST compute the `wt_signature` verification using `wt_public_key`.<br>
><br>
> * MUST fail the connection if:<br>
> * Any of the fields is missing.<br>
> * `receipt` does not matches the format specified at<br>
> [Receipt-Format](#receipt-format)<br>
> * `receipt` fields do not match the ones sent in the `appointment` message.<br>
> * `wt_signature_algorithm` does not match any of the ones offered by the<br>
> server.<br>
> * `wt_signature` cannot be verified using `wt_public_key`.<br>
><br>
> #### Receipt Format<br>
><br>
> The server MUST create the receipt containing the following information:<br>
><br>
> txlocator<br>
> start_block<br>
> end_block<br>
> dispute_delta<br>
> encrypted_blob<br>
> transaction_size<br>
> transaction_fee<br>
> cipher<br>
> customer_signature<br>
> wt_public_key<br>
><br>
><br>
> #### Rationale<br>
><br>
> We assume the client has a well-known public key for the WatchTower.<br>
><br>
> The receipt contains, mainly, the information provided by the user. The<br>
> WatchTower will need to sign the receipt to provide evidence of agreement.<br>
><br>
> The `customer_signature` is included in the receipt to link both the client<br>
> request and the server response. Otherwise, the tower could sign a receipt<br>
> with different data that the one sent by the user, and the user would have<br>
> no way to prove whether that's true or not. By signing the customer<br>
> signature there the tower creates evidence of what the user sent, since the<br>
> tower cannot forge the client's signature.<br>
><br>
> #### Receipt serialization and signature<br>
><br>
> [FIXME: TBD]<br>
><br>
> ## Transaction Locator and Encryption Key<br>
><br>
> Implementations MUST compute the `locator`, `encryption_key` and<br>
> `encryption_iv` from the commitment transaction as defined below:<br>
><br>
> - `locator`: first half of the commitment transaction id<br>
> (`commitment_txid(0,16]`)<br>
> - `master_key`: Hash of the second half of the commitment transaction id<br>
> (`SHA256(commitment_txid(16,32])`)<br>
> - `encryption_key`: first half of the master key (`master_key(0,16]`)<br>
> - `encryption_iv`: second half of the master key (`master_key(16,32]`)<br>
><br>
><br>
> The server relies on both the encryption key and iv to decrypt the justice<br>
> transaction. Furthermore, the transaction locator helps the WatchTower<br>
> identify a breach transaction on the blockchain.<br>
<br>
The SHA256 step here is crypto cargo-culting AFAICT. If the watchtower<br>
can guess the txid, it does nothing. If it can't, it does nothing.<br>
<br>
Setting both the IV and the key is similarly weird. Use an IV of 0 and<br>
simply use the second half of the commit txid as key.<br></blockquote><div><br></div><div>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:</div><div><br></div><div>locator = commitment_txid(0,16]</div><div>key = sha256(commitment_txid)</div><div>iv = 0 (12-byte)</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> ## Encryption Algorithms and Parameters<br>
><br>
> All clients and servers MUST use one of the following encryption<br>
> algorithms:<br>
><br>
> - ChaCha20 (<a href="https://tools.ietf.org/html/rfc7539" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc7539</a>)<br>
> - AES-GCM-256 (<a href="https://tools.ietf.org/html/rfc5288" rel="noreferrer" target="_blank">https://tools.ietf.org/html/rfc5288</a>)<br>
<br>
This would be the first use of AES, and you need to implement chacha20<br>
to speak to other peers. Drop this.<br></blockquote><div><br></div><div>Done.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> Sample code (python) for the client to prepare the `encrypted_blob`:<br>
><br>
> from hashlib import sha256<br>
> from binascii import hexlify<br>
><br>
> def encrypt(justice_tx, commitment_txid):<br>
> # master_key = SHA256(commitment_txid(16, 32])<br>
> master_key = sha256(commitment_txid[16:]).digest()<br>
><br>
> # The 16 MSB of the master key will serve as the AES-GCM-256 secret key.<br>
> The 16 LSB will serve as the IV.<br>
> sk = master_key[:16]<br>
> nonce = master_key[16:]<br>
><br>
> # Encrypt the data<br>
> aesgcm = AESGCM(sk)<br>
> encrypted_blob = aesgcm.encrypt(nonce=iv, data=tx, associated_data=None)<br>
> encrypted_blob = hexlify(encrypted_blob).decode()<br>
><br>
> return encrypted_blob<br>
<br>
> ## Payment modes<br>
><br>
> Although this BOLT does not enforce any specific payment method to be<br>
> adopted, it is worth mentioning the three most common ones:<br>
><br>
> **On-chain bounty**. An additional output is created in the justice<br>
> transaction that will reward the WatchTower.<br>
<br>
This has the advantage of allowing (and incentivizing!) the WatchTower<br>
to CPFP. However, it has to be defined (how does client know what addr<br>
to pay to?), so I'd leave it for later.<br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> **Micropayments**. A small payment is sent to the WatchTower for every new<br>
> job (e.g. over the lightning network)<br>
><br>
> **Subscription**. WatchTower is periodically rewarded / paid for their<br>
> service to the customer. (e.g. over the lightning network or fiat<br>
> subscription).<br>
><br>
> Both micropayments and subscriptions are favourable for a WatchTower. The<br>
> on-chain bounty approach is not ideal for a watching network, it lets the<br>
> customer hire many WatchTowers (O(N) storage for each tower) and only one<br>
> WatchTower will be rewarded upon collecting the bounty. On top of that, the<br>
> onchain bounty allows a network-wise DoS attack for free.<br>
<br>
> ## No compression of justice transaction<br>
><br>
> The storage requirements for a WatchTower can be reduced (linearly) by<br>
> implementing [shachain](<br>
> <a href="https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt" rel="noreferrer" target="_blank">https://github.com/rustyrussell/ccan/blob/master/ccan/crypto/shachain/design.txt</a>),<br>
> therefore storing the parts required to build the transaction and the<br>
> corresponding signing key instead of the full transaction. For now, we have<br>
> decided to keep the hiring protocol simple. Storage is relatively cheap and<br>
> we can revisit this standard if it becomes a problem.<br>
<br>
Agreed.<br>
<br>
Cheers,<br>
Rusty.<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Sergi.</div></div></div>