From 1636b74fb5655d74d69ae8f265a2ffb1c2c56ab4 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Sat, 12 Feb 2022 15:00:41 +0100 Subject: [PATCH 1/6] Presign all transactions with SIGHASH_ALL, remove ANYONECANPAY mentions There are still too many pinning attacks possible, such that it's not reasonable to deploy with this. In addition, it's certainly not worth the complexity and overhead of managing fee-bumping reserves. This is in theory a reduction in security as the maximum reserve is now a deployment parameter (at what feerate to sign the Cancel txs) where it was previously flexible and left to the discretion of each watchtower. --- messages.md | 15 +++++++-------- transactions.md | 6 ++---- 2 files changed, 9 insertions(+), 12 deletions(-) diff --git a/messages.md b/messages.md index 6142b06..de1a28f 100644 --- a/messages.md +++ b/messages.md @@ -58,16 +58,16 @@ 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", + "pubkeyA": "SIGHASH_ALL Bitcoin ECDSA signature as hex", + "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", @@ -230,8 +230,7 @@ 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 diff --git a/transactions.md b/transactions.md index a730311..3415356 100644 --- a/transactions.md +++ b/transactions.md @@ -126,8 +126,7 @@ 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. @@ -162,8 +161,7 @@ transactions are never meant to be used. Both Emergency transactions are signed at a fixed `75 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. From 9d7f246374fe13fd2588ae2d5ec72ff3524cccfa Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Sun, 13 Feb 2022 11:18:41 +0100 Subject: [PATCH 2/6] messages: typo 'inactive' --- messages.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/messages.md b/messages.md index de1a28f..79b566f 100644 --- a/messages.md +++ b/messages.md @@ -223,7 +223,7 @@ 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. From 7bb40a9f331b5dfcc08698510d99c015b1c6b9a7 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Sun, 13 Feb 2022 17:05:50 +0100 Subject: [PATCH 3/6] messages: share the Cancel with several feerates to the WTs For the coordinator, we can just use the current `sig` message. --- messages.md | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/messages.md b/messages.md index 79b566f..af7ac85 100644 --- a/messages.md +++ b/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 @@ -62,8 +66,13 @@ signature. "pubkeyB": "SIGHASH_ALL Bitcoin ECDSA signature as hex", }, "cancel": { - "pubkeyA": "SIGHASH_ALL Bitcoin ECDSA signature as hex", - "pubkeyB": "SIGHASH_ALL 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": "SIGHASH_ALL Bitcoin ECDSA signature as hex", From bdf88e93ef7527c99d2b048226db1becf2ed2867 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Sun, 13 Feb 2022 17:18:45 +0100 Subject: [PATCH 4/6] transactions: remove the mention of a static presigned feerate for the Cancel --- transactions.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/transactions.md b/transactions.md index 3415356..7a00242 100644 --- a/transactions.md +++ b/transactions.md @@ -128,8 +128,7 @@ pays back to a deposit output (it is therefore another vault deposit transaction 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 From 603f19f44401d603c97491c5d1e35828296b5a12 Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Mon, 14 Feb 2022 09:06:16 +0100 Subject: [PATCH 5/6] transactions: presign the Emergency transaction at 1000sat/vb MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Since we got rid of fee-bumping, we need a feerate such that it is *very* unlikely the next block feerate ever goes above (which'd make the deterrent somewhat moot). On the other hand, choosing something much higher really conditions the deposit size. Especially in case of deposit split. For 8 stakeholders and 3 managers, this makes the deposit be at least 500€ in order for the Emergency to not burn >25% of the funds at this feerate. (Emergency vbytes: 211, BTCEUR: 40k.) --- transactions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/transactions.md b/transactions.md index 7a00242..37bf14e 100644 --- a/transactions.md +++ b/transactions.md @@ -158,7 +158,7 @@ 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` signature hash flag. From a9ecf05d57a1664c0178b7b6bb888104133dda7a Mon Sep 17 00:00:00 2001 From: Antoine Poinsot Date: Tue, 17 May 2022 10:56:30 +0200 Subject: [PATCH 6/6] Update the introduction to mention static fee bumping --- introduction.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/introduction.md b/introduction.md index a352572..25c01ac 100644 --- a/introduction.md +++ b/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.