summaryrefslogtreecommitdiff
path: root/bip-vaults.mediawiki
diff options
context:
space:
mode:
authorJames O'Beirne <wild-github@au92.org>2023-03-02 09:35:01 -0500
committerJames O'Beirne <james.obeirne@pm.me>2023-03-23 13:24:17 -0400
commit997e4f4f0e92ccbc5f5cdf34c265c7e5e41fa4bc (patch)
treee018a9ae0addff37f015ae425cb706cd6f010305 /bip-vaults.mediawiki
parentf30fb52bbb165982823f8af131c8ff6ffb56eba6 (diff)
downloadbips-997e4f4f0e92ccbc5f5cdf34c265c7e5e41fa4bc.tar.xz
Update bip-vaults.mediawiki
Co-authored-by: kallewoof <kalle.alm@gmail.com>
Diffstat (limited to 'bip-vaults.mediawiki')
-rw-r--r--bip-vaults.mediawiki6
1 files changed, 3 insertions, 3 deletions
diff --git a/bip-vaults.mediawiki b/bip-vaults.mediawiki
index 1ac8de9..3f56d01 100644
--- a/bip-vaults.mediawiki
+++ b/bip-vaults.mediawiki
@@ -476,9 +476,9 @@ If the above conditions do not fail, a single true value (<code>0x01</code>) is
In order to prevent possible pinning attacks, recovery transactions must be replaceable.
-* When validating an <code>OP_VAULT</code>/<code>OP_UNVAULT</code> input being spent towards a recovery, the script must FAIL (by policy, not consensus) and terminate immediately if neither<ref>'''Why are recovery transactions required to be replaceable?''' In the case of unauthorized recoveries, an attacker may attempt to pin recovery transactions by broadcasting a "rebundled" version with a low fee rate. Vault owners must be able to overcome this with replacement. In the case of authorized recovery, if an attacker steals the recovery authorization key, the attacker may try to pin the recovery transaction during theft. Requiring replaceability ensures that the owner can always raise the fee rate of the recovery transaction, even if they are RBF rule #3 griefed in the process.</ref>
-*# the input is marked as opt-in replaceable by having an nSequence number less than <code>0xffffffff - 1</code>, per [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP-0125], nor
-*# the version of the recovery transaction has an nVersion equal to 3.
+* When validating an <code>OP_VAULT</code>/<code>OP_UNVAULT</code> input being spent towards a recovery, the script must FAIL (by policy, not consensus) and terminate immediately if both<ref>'''Why are recovery transactions required to be replaceable?''' In the case of unauthorized recoveries, an attacker may attempt to pin recovery transactions by broadcasting a "rebundled" version with a low fee rate. Vault owners must be able to overcome this with replacement. In the case of authorized recovery, if an attacker steals the recovery authorization key, the attacker may try to pin the recovery transaction during theft. Requiring replaceability ensures that the owner can always raise the fee rate of the recovery transaction, even if they are RBF rule #3 griefed in the process.</ref>
+*# the input is not marked as opt-in replaceable by having an nSequence number less than <code>0xffffffff - 1</code>, per [https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki BIP-0125], and
+*# the version of the recovery transaction has an nVersion other than 3.
In order to prevent pinning attacks in the case of unauthorized recovery, the output structure of unauthorized recovery
transaction is limited.