diff options
| author | MeshCollider <dobsonsa68@gmail.com> | 2017-08-24 23:50:20 +1200 |
|---|---|---|
| committer | Luke Dashjr <luke-jr+git@utopios.org> | 2017-09-16 03:12:13 +0000 |
| commit | 6295c1a095a1fa33f38d334227fa4222d8e0a523 (patch) | |
| tree | f59b8d69f3865b383526ac42ee61cf8d8b3146d2 /bip-0140.mediawiki | |
| parent | b501de4d2cb5fd7d813780cbebfd1be027ba2acd (diff) | |
| download | bips-6295c1a095a1fa33f38d334227fa4222d8e0a523.tar.xz | |
Fixing spelling in multiple BIPs
Diffstat (limited to 'bip-0140.mediawiki')
| -rw-r--r-- | bip-0140.mediawiki | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/bip-0140.mediawiki b/bip-0140.mediawiki index ea5061f..9fb52b4 100644 --- a/bip-0140.mediawiki +++ b/bip-0140.mediawiki @@ -83,7 +83,7 @@ There are a number of advantages to using normalized transaction IDs: Scalable Off-Chain Instant Payments]]</ref> in which several parties sign a transaction. Without normalized transaction IDs it is trivial for one party to re-sign a transaction, hence changing the transaction hash and invalidating any transaction built on top of its outputs. Normalized transaction IDs force the ID not to change, even if a party replaces its signature. * Many higher level protocols build structures of transactions on top of multisig outputs that are not completely signed. This is currently not possible without one party holding a fully signed transaction and then calculating the ID. It is desirable to be able to build successive transactions without one party collecting all signatures, and thus possibly lock in funds unilaterally. Normalized transaction IDs allow the use of transaction templates, i.e., completely unsigned transactions upon which further transactions can be built, and only once every party is assured the structure matches its expectations it signs the template, thus validating the template. -The only occurence in which transactions can still be modified unilaterally is in the case <code>SIGHASH_NONE</code>, <code>SIGHASH_SINGLE</code> or <code>SIGHASH_ANYONECANPAY</code> is used. This however is not problematic since in these cases the creator of the transaction explicitly allows modification. +The only occurrence in which transactions can still be modified unilaterally is in the case <code>SIGHASH_NONE</code>, <code>SIGHASH_SINGLE</code> or <code>SIGHASH_ANYONECANPAY</code> is used. This however is not problematic since in these cases the creator of the transaction explicitly allows modification. In case of a transaction becoming invalid due to one of the inputs being malleated it is necessary to modify the spending transaction to reference the modified transaction ID. However, the signatures, which only use the normalized IDs, remain valid as long as the semantics of the funding transaction remain unchanged. An observer in the network may fix the transaction and reinject a corrected version. |