bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-06-30 12:42:43 +00:00
Code Issues Releases Wiki Activity

Use the term "malleability" rather than "mutability"

Browse Source
This commit is contained in:
Peter Todd 2015-11-13 12:17:23 -05:00
parent f6a5bf2c5e
commit abeaa1be10
No known key found for this signature in database
GPG Key ID: C085F21CE7F4B9DC
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
bip-0065.mediawiki
View File

@ -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 failure of one party does not result in the funds becoming lost, refund
transactions are setup in advance using nLockTime. These refund transactions transactions are setup in advance using nLockTime. These refund transactions
need to be created interactively, and additionaly, are currently vulnerable to 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, 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==== ====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 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 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 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 additionally, requires the payor to store the refund. Using the same
scriptPubKey from as in the Two-factor wallets example solves both these issues. scriptPubKey from as in the Two-factor wallets example solves both these issues.