diff options
Diffstat (limited to 'bip-0065.mediawiki')
| -rw-r--r-- | bip-0065.mediawiki | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/bip-0065.mediawiki b/bip-0065.mediawiki index c9f78f6..6563010 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. |