About (not) dying on the dynamic feebumping hill

introduction.md

@@ -118,10 +118,15 @@ The use of BIP32 unhardened derivation introduces even more reliance on the sign
 
 ### Transaction Fee Risk
 
-A fundamental issue arises with pre-signed transactions commiting to the feerate well in advance of the time of broadcast. The required feerate is unpredictable and a transaction with a low feerate may not be included in a block in time.
+A fundamental issue arises with pre-signed transactions committing to the feerate well in advance of the time of broadcast. The required feerate is unpredictable and a transaction with a low feerate may not be included in a block in time.
 
-[Pinning attacks](https://bitcoinops.org/en/topics/transaction-pinning/) are possible when using either RBF or CPFP to dynamically allocate fees to transactions. These attacks exploit vulnerabilities that can cause transactions to become "stuck" in the mempool for long times. For protocols like Revault which require timely transaction confirmation, these attacks can be used to defeat theft-mitigation features (e.g. pinning a Cancel TX for longer than the Unvault TX's time-lock, and stealing funds).
+[Pinning attacks](https://bitcoinops.org/en/topics/transaction-pinning/) are possible when using either RBF or CPFP to dynamically allocate fees to transactions. These attacks exploit vulnerabilities that can cause transactions to become "stuck" in the Bitcoin network nodes mempools for long times. For protocols like Revault which require timely transaction confirmation, these attacks can be used to defeat theft-mitigation features (e.g. pinning a Cancel TX for longer than the Unvault TX's time-lock, and stealing funds).
 
-The Unvault TXs have an additional output that allows dynamically allocating fees through child-pays-for-parent (CPFP). This feature helps managers optimise withdrawal times. The possibility of pinning Unvault TXs doesn't impact the theft-mitigation features of Revault but can be used as a denial-of-service attack by comrpomised managers. This is acceptable since managers already have multiple ways to launch denial-of-service attacks. For the Cancel, Emergency and Unvault Emergency TXs it is critical to avoid transaction pinning attacks. Unfortunately, we are not aware of a method to dynamically allocate fees to these transactions without the risk of pinning attacks (at least, without any soft-forks to Bitcoin). A more detailed discussion can be found [here](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019614.html).
+The Unvault TXs have an additional output that allows dynamically allocating fees through child-pays-for-parent (CPFP). This feature helps managers optimise withdrawal times. The possibility of pinning Unvault TXs doesn't impact the theft-mitigation features of Revault but can be used as a denial-of-service attack by comrpomised managers. This is acceptable since managers already have multiple ways to launch denial-of-service attacks. For the Cancel, Emergency and Unvault Emergency TXs it is critical to avoid transaction pinning attacks. Unfortunately, we are not aware of a method to dynamically allocate fees to these transactions without the risk of pinning attacks. A more detailed discussion can be found [here](https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-November/019614.html). [This pull request](https://github.com/revault/practical-revault/pull/119) also contains rationale and references for not using dynamic fee bumping.
 
 Emergency and Unvault Emergency TXs are simply pre-signed with exorbitant fees as they are intended as a deterrent, and not a regular expense.
+
+Since Cancel TXs may (or may not) occur frequently, it is important to minimise their feerates while
+still ensuring timely confirmation. The best solution currently is to prepare multiple variants of
+the same Cancel TX with a broad distribution of feerates, from typical to extreme and with several
+in-between. At the time of broadcast, the one with the appropriate fee should be selected.

messages.md

@@ -50,6 +50,10 @@ with (one of) its watchtower(s).
 It must wait for a positive response from the watchtower before sharing the Unvault transaction
 signature.
 
+The Cancel transaction signature is shared at various feerates. This is for the watchtowers to be
+able to adapt the Cancel transaction to the fee market, short of having a decent fee-bumping
+technique.  
+
 #### Request
 
 ```json
@@ -58,16 +62,21 @@ signature.
     "params": {
         "signatures": {
           "emergency": {
-              "pubkeyA": "ALL|ANYONECANPAY Bitcoin ECDSA signature as hex",
-              "pubkeyB": "ALL|ANYONECANPAY Bitcoin ECDSA signature as hex",
+              "pubkeyA": "SIGHASH_ALL Bitcoin ECDSA signature as hex",
+              "pubkeyB": "SIGHASH_ALL Bitcoin ECDSA signature as hex",
           },
           "cancel": {
-              "pubkeyA": "ALL|ANYONECANPAY Bitcoin ECDSA signature as hex",
-              "pubkeyB": "ALL|ANYONECANPAY Bitcoin ECDSA signature as hex",
+              "feerate A (sat/vb)": {
+                  "pubkeyA": "SIGHASH_ALL Bitcoin ECDSA signature as hex",
+                  "pubkeyC": "SIGHASH_ALL Bitcoin ECDSA signature as hex",
+              },
+              "feerate D (sat/vb)": {
+                  "pubkeyB": "SIGHASH_ALL Bitcoin ECDSA signature as hex",
+              }
           }
           "unvault_emergency": {
-              "pubkeyA": "ALL|ANYONECANPAY Bitcoin ECDSA signature as hex",
-              "pubkeyB": "ALL|ANYONECANPAY Bitcoin ECDSA signature as hex",
+              "pubkeyA": "SIGHASH_ALL Bitcoin ECDSA signature as hex",
+              "pubkeyB": "SIGHASH_ALL Bitcoin ECDSA signature as hex",
           }
         },
         "deposit_outpoint": "deposit utxo outpoint",
@@ -223,15 +232,14 @@ the `cancel` and `emergency` transactions and its watchtower to have verified an
 the signature before possibly sharing its signature for the unvault transaction.
 
 A wallet is not bound to share its signature for the unvault transaction. This flexibility
-allows "unactive vaults": a multisig which is not spendable by default but still guarded
+allows "inactive vaults": a multisig which is not spendable by default but still guarded
 by the emergency transaction deterrent.  
 A wallet must share its signature for the `cancel` and the unvault `emergency`
 transactions nonetheless.  
 An inactive vault may later become active by sharing signatures for the `unvault`
 transaction.  
 
-Revocation transactions (`cancel` and `emergency`s) are signed with the `ALL|ANYONECANPAY`
-flag.
+Revocation transactions (`cancel` and `emergency`s) are signed with `SIGHASH_ALL`.
 
 
 #### Request

transactions.md

@@ -126,11 +126,9 @@ The CPFP output value is adjusted depending on the actual transaction size.
 The transaction which spends the [`unvault_tx`](#unvault_tx) `output[0]` using the N-of-N path and 
 pays back to a deposit output (it is therefore another vault deposit transaction).
 
-The Cancel transaction is signed using the `ALL | ANYONECANPAY` signature hash flag, to
-allow watchtowers (or anyone else) to attach fee-bumping inputs.
+The Cancel transaction is signed using the `ALL` signature hash flag.
 
-The Cancel transaction is signed at a fixed `22 sat/WU` feerate. This is in order to
-reduce the funds burden on *each* of the watchtowers.
+The Cancel transaction is signed at various feerates, defined by a deployment's parameters.
 
 - version: 2
 - locktime: 0
@@ -160,10 +158,9 @@ funds. They lock coins to what we call an EDV (Emergency Deep Vault): a script c
 by the participants and kept obfuscated by the properties of P2WSH, as the emergency
 transactions are never meant to be used.
 
-Both Emergency transactions are signed at a fixed `75 sat/WU` feerate.
+Both Emergency transactions are signed at a fixed `250 sat/WU` feerate.
 
-Both Emergency transaction are signed using the `ALL | ANYONECANPAY` signature hash flag,
-to allow watchtowers (or anyone else) to attach fee-bumping inputs.
+Both Emergency transaction are signed using the `ALL` signature hash flag.
 
 The Emergency `scriptPubKey` is not known to the managers.