diff options
Diffstat (limited to 'bip-0119.mediawiki')
| -rw-r--r-- | bip-0119.mediawiki | 10 |
1 files changed, 5 insertions, 5 deletions
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki index d661f4c..be1f70c 100644 --- a/bip-0119.mediawiki +++ b/bip-0119.mediawiki @@ -193,7 +193,7 @@ Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial. The Bitcoin Core reference implementation includes the below parameters, configured to match Speedy Trial, as that is the current activation mechanism implemented in Bitcoin Core. Should another method become favored by the wider -Bitcoin comminity, that might be used instead. +Bitcoin community, that might be used instead. The start time and bit in the implementation are currently set to bit 5 and NEVER_ACTIVE/NO_TIMEOUT, but this is subject to change while the BIP is a draft. @@ -314,7 +314,7 @@ We treat the number of inputs as a `uint32_t` because Bitcoin's consensus decodi to `MAX_SIZE=33554432` and that is larger than `uint16_t` and smaller than `uint32_t`. 32 bits is also friendly for manipulation using Bitcoin's current math opcodes, should `OP_CAT` be added. Note that the max inputs in a block is further restricted by the block size to around 25,000, which would fit -into a `uint16_t`, but that is an uneccessary abstraction leak. +into a `uint16_t`, but that is an unnecessary abstraction leak. =====Committing to the Sequences Hash===== @@ -362,7 +362,7 @@ scripts cannot be spent at the same index, which implies that they cannot be spe This makes it safer to design wallet vault contracts without half-spend vulnerabilities. Committing to the current index doesn't prevent one from expressing a CHECKTEMPLATEVERIFY which can -be spent at multiple indicies. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped +be spent at multiple indices. In current script, the CHECKTEMPLATEVERIFY operation can be wrapped in an OP_IF for each index (or Tapscript branches in the future). If OP_CAT or OP_SHA256STREAM are added to Bitcoin, the index may simply be passed in by the witness before hashing. @@ -476,7 +476,7 @@ An example of a script that could experience an DoS issue without caching is: <H> CTV CTV CTV... CTV -Such a script would cause the intepreter to compute hashes (supposing N CTV's) over O(N*T) data. +Such a script would cause the interpreter to compute hashes (supposing N CTV's) over O(N*T) data. If the scriptSigs non-nullity is not cached, then the O(T) transaction could be scanned over O(N) times as well (although cheaper than hashing, still a DoS). As such, CTV caches hashes and computations over all variable length fields in a transaction. @@ -616,7 +616,7 @@ sponsors might be considered. An opcode which verifies the exact amount that is being spent in the transaction, the amount paid as fees, or made available in a given output could -be used to make safer OP_CHECKTEMPLATEVERIFY addressses. For instance, if the +be used to make safer OP_CHECKTEMPLATEVERIFY addresses. For instance, if the OP_CHECKTEMPLATEVERIFY program P expects exactly S satoshis, sending S-1 satoshis would result in a frozen UTXO and sending S+n satoshis would result in n satoshis being paid to fee. A range check could restrict the program to only |