diff options
| author | Gigi <109058+dergigi@users.noreply.github.com> | 2019-04-21 19:17:41 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2019-04-21 19:17:41 -0500 |
| commit | 0cb0d361a57f90b3cad39527347360cb206bf9e3 (patch) | |
| tree | dc52d49cdd7633ba42c6ec63ee12cc2ce20cb2a0 | |
| parent | 111e427d206caba009a37fc456e6c9f9e41bba99 (diff) | |
[Trivial] Fix word repetition
* changes modifies -> modifies
* index of of -> index of
| -rw-r--r-- | bip-0069.mediawiki | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/bip-0069.mediawiki b/bip-0069.mediawiki index e9f9245..3aa9463 100644 --- a/bip-0069.mediawiki +++ b/bip-0069.mediawiki @@ -78,7 +78,7 @@ N.B. All comparisons do not need to operate in constant time since they are not ===Transaction Inputs=== -Transaction inputs are defined by the hash of a previous transaction, the output index of of a UTXO from that previous transaction, the size of an unlocking script, the unlocking script, and a sequence number. [3] +Transaction inputs are defined by the hash of a previous transaction, the output index of a UTXO from that previous transaction, the size of an unlocking script, the unlocking script, and a sequence number. [3] For sorting inputs, the hash of the previous transaction and the output index within that transaction are sufficient for sorting purposes; each transaction hash has an extremely high probability of being unique in the blockchain — this is enforced for coinbase transactions by BIP30 — and output indices within a transaction are unique. For the sake of efficiency, transaction hashes should be compared first before output indices, since output indices from different transactions are often equivalent, while all bytes of the transaction hash are effectively random variables. @@ -87,7 +87,7 @@ In the event of two matching transaction hashes, the respective previous output If the previous output indices match, the inputs are considered equal. Transaction malleability will not negatively impact the correctness of this process. -Even if a wallet client follows this process using unconfirmed UTXOs as inputs and an attacker changes modifies the blockchain’s record of the hash of the previous transaction, the wallet client will include the invalidated previous transaction hash in its input data, and will still correctly sort with respect to that invalidated hash. +Even if a wallet client follows this process using unconfirmed UTXOs as inputs and an attacker modifies the blockchain’s record of the hash of the previous transaction, the wallet client will include the invalidated previous transaction hash in its input data, and will still correctly sort with respect to that invalidated hash. ===Transaction Outputs=== |