From abeaa1be10c2447d3c7b461582674a2b698cc50b Mon Sep 17 00:00:00 2001 From: Peter Todd Date: Fri, 13 Nov 2015 12:17:23 -0500 Subject: [PATCH] Use the term "malleability" rather than "mutability" --- bip-0065.mediawiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index c9f78f6a..6563010e 100644 --- a/bip-0065.mediawiki +++ b/bip-0065.mediawiki @@ -89,9 +89,9 @@ requires the co-operation of both parties to spend the output. To ensure the failure of one party does not result in the funds becoming lost, refund transactions are setup in advance using nLockTime. These refund transactions need to be created interactively, and additionaly, are currently vulnerable to -transaction mutability. CHECKLOCKTIMEVERIFY can be used in these protocols, +transaction malleability. CHECKLOCKTIMEVERIFY can be used in these protocols, replacing the interactive setup with a non-interactive setup, and additionally, -making transaction mutability (aka malleability) a non-issue. +making transaction malleability a non-issue. ====Two-factor wallets==== @@ -128,7 +128,7 @@ Jeremy Spilman style payment channels first setup a deposit controlled by the output of tx1 to payor and payee. Prior to publishing tx1 a refund transaction is created, tx3, to ensure that should the payee vanish the payor can get their deposit back. The process by which the refund transaction is -created is currently vulnerable to transaction mutability attacks, and +created is currently vulnerable to transaction malleability attacks, and additionally, requires the payor to store the refund. Using the same scriptPubKey from as in the Two-factor wallets example solves both these issues.