16 files changed, 79 insertions, 51 deletions
diff --git a/README.mediawiki b/README.mediawiki
index ca28339..720d4f5 100644
--- a/README.mediawiki
+++ b/README.mediawiki
@@ -398,7 +398,7 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Bustapay :: a practical coinjoin protocol
 | Ryan Havar
 | Informational
-| Proposed
+| Replaced
 |-
 | [[bip-0080.mediawiki|80]]
 |
@@ -546,13 +546,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Thomas Kerin, Mark Friedenbach
 | Standard
 | Final
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0114.mediawiki|114]]
 | Consensus (soft fork)
 | Merkelized Abstract Syntax Tree
 | Johnson Lau
 | Standard
-| Draft
+| Rejected
 |- style="background-color: #ffcfcf"
 | [[bip-0115.mediawiki|115]]
 | Consensus (soft fork)
@@ -616,13 +616,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Eric Lombrozo
 | Process
 | Active
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0124.mediawiki|124]]
 | Applications
 | Hierarchical Deterministic Script Templates
 | Eric Lombrozo, William Swanson
 | Informational
-| Draft
+| Rejected
 |- style="background-color: #ffffcf"
 | [[bip-0125.mediawiki|125]]
 | Applications
@@ -679,13 +679,13 @@ Those proposing changes should consider that ultimately consent may rest with th
 | Tom Zander
 | Standard
 | Rejected
-|-
+|- style="background-color: #ffcfcf"
 | [[bip-0135.mediawiki|135]]
 |
 | Generalized version bits voting
 | Sancho Panza
 | Informational
-| Draft
+| Rejected
 |-
 | [[bip-0136.mediawiki|136]]
 | Applications
diff --git a/bip-0009.mediawiki b/bip-0009.mediawiki
index a68bb80..f90919a 100644
--- a/bip-0009.mediawiki
+++ b/bip-0009.mediawiki
@@ -217,7 +217,7 @@ Soft forks right now are typically treated as booleans: they go from an inactive
 
 The failure timeout allows eventual reuse of bits even if a soft fork was
 never activated, so it's clear that the new use of the bit refers to a
-new BIP.  It's deliberately very course grained, to take into account
+new BIP.  It's deliberately very coarse-grained, to take into account
 reasonable development and deployment delays.  There are unlikely to be
 enough failed proposals to cause a bit shortage.
 
diff --git a/bip-0039.mediawiki b/bip-0039.mediawiki
index 2b95c51..c5ab9bb 100644
--- a/bip-0039.mediawiki
+++ b/bip-0039.mediawiki
@@ -18,7 +18,7 @@
 This BIP describes the implementation of a mnemonic code or mnemonic sentence --
 a group of easy to remember words -- for the generation of deterministic wallets.
 
-It consists of two parts: generating the mnemonic, and converting it into a
+It consists of two parts: generating the mnemonic and converting it into a
 binary seed. This seed can be later used to generate deterministic wallets using
 BIP-0032 or similar methods.
 
@@ -29,7 +29,7 @@ handling of raw binary or hexadecimal representations of a wallet seed. The
 sentence could be written on paper or spoken over the telephone.
 
 This guide is meant to be a way to transport computer-generated randomness with
-a human readable transcription. It's not a way to process user-created
+a human-readable transcription. It's not a way to process user-created
 sentences (also known as brainwallets) into a wallet seed.
 
 ==Generating the mnemonic==
@@ -46,7 +46,7 @@ as an index into a wordlist. Finally, we convert these numbers into words and
 use the joined words as a mnemonic sentence.
 
 The following table describes the relation between the initial entropy
-length (ENT), the checksum length (CS) and the length of the generated mnemonic
+length (ENT), the checksum length (CS), and the length of the generated mnemonic
 sentence (MS) in words.
 
 <pre>
@@ -67,12 +67,12 @@ MS = (ENT + CS) / 11
 An ideal wordlist has the following characteristics:
 
 a) smart selection of words
-   - the wordlist is created in such way that it's enough to type the first four
+   - the wordlist is created in such a way that it's enough to type the first four
      letters to unambiguously identify the word
 
 b) similar words avoided
    - word pairs like "build" and "built", "woman" and "women", or "quick" and "quickly"
-     not only make remembering the sentence difficult, but are also more error
+     not only make remembering the sentence difficult but are also more error
      prone and more difficult to guess
 
 c) sorted wordlists
@@ -97,7 +97,7 @@ This seed can be later used to generate deterministic wallets using BIP-0032 or
 similar methods.
 
 The conversion of the mnemonic sentence to a binary seed is completely independent
-from generating the sentence. This results in rather simple code; there are no
+from generating the sentence. This results in a rather simple code; there are no
 constraints on sentence structure and clients are free to implement their own
 wordlists or even whole sentence generators, allowing for flexibility in wordlists
 for typo detection or other purposes.
@@ -168,7 +168,9 @@ Rust:
 Swift:
 * https://github.com/CikeQiu/CKMnemonic
 * https://github.com/yuzushioh/WalletKit
+* https://github.com/pengpengliu/BIP39
 * https://github.com/matter-labs/web3swift/blob/develop/Sources/web3swift/KeystoreManager/BIP39.swift
+* https://github.com/zcash-hackworks/MnemonicSwift
 
 C++:
 * https://github.com/libbitcoin/libbitcoin-system/blob/master/include/bitcoin/system/wallet/mnemonic.hpp
diff --git a/bip-0039/bip-0039-wordlists.md b/bip-0039/bip-0039-wordlists.md
index 0940f35..589ceab 100644
--- a/bip-0039/bip-0039-wordlists.md
+++ b/bip-0039/bip-0039-wordlists.md
@@ -93,8 +93,8 @@ Words chosen using the following rules:
 1.  Words are 4-8 letters long.
 2.  Words can be uniquely determined typing the first 4 letters.
 3.  Only words containing all letters without diacritical marks. (It was the hardest task, because in one third of all Czech letters has diacritical marks.)
-4.  Only nouns, werbs and adverbs, no other word types. All words are in basic form.
-5.  No personal names or geografical names.
+4.  Only nouns, verbs and adverbs, no other word types. All words are in basic form.
+5.  No personal names or geographical names.
 6.  No very similar words with 1 letter of difference.
 7. Words are sorting according English alphabet (Czech sorting has difference in "ch").
 8.  No words already used in other language mnemonic sets (english, italian, french, spanish). Letters with diacritical marks from these sets are counted as analogous  letters without diacritical marks.
diff --git a/bip-0114.mediawiki b/bip-0114.mediawiki
index 21d0b6c..410e84c 100644
--- a/bip-0114.mediawiki
+++ b/bip-0114.mediawiki
@@ -5,7 +5,7 @@
   Author: Johnson Lau <jl2012@xbt.hk>
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0114
-  Status: Draft
+  Status: Rejected
   Type: Standards Track
   Created: 2016-04-02
   License: PD
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki
index 7a87b24..730ffb9 100644
--- a/bip-0119.mediawiki
+++ b/bip-0119.mediawiki
@@ -266,7 +266,7 @@ segwit transaction in which case it must be only the exact redeemscript. P2SH is
 (unless the P2SH hash is broken) with CHECKTEMPLATEVERIFY because the template hash must commit
 to the  ScriptSig, which must contain the redeemscript, which is a hash cycle.
 
-To prevent succeptibility to malleability when not using a segwit input, we also commit to the
+To prevent malleability when not using a segwit input, we also commit to the
 scriptsig. This makes it possible to use a 2 input CHECKTEMPLATEVERIFY with a legacy pre-signed
 spend, as long as the exact scriptsig for the legacy output is committed. This is more robust than
 simply disallowing any scriptSig to be set with CHECKTEMPLATEVERIFY.
diff --git a/bip-0124.mediawiki b/bip-0124.mediawiki
index a5929ac..69cb134 100644
--- a/bip-0124.mediawiki
+++ b/bip-0124.mediawiki
@@ -6,7 +6,7 @@
           William Swanson <swansontec@gmail.com>
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0124
-  Status: Draft
+  Status: Rejected
   Type: Informational
   Created: 2015-11-20
   License: PD
diff --git a/bip-0135.mediawiki b/bip-0135.mediawiki
index 89d3077..1324746 100644
--- a/bip-0135.mediawiki
+++ b/bip-0135.mediawiki
@@ -5,7 +5,7 @@
   Comments-Summary: No comments yet.
   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0135
                 https://bitco.in/forum/threads/bip9-generalized-version-bits-voting-bip-genvbvoting.1968/
-  Status: Draft
+  Status: Rejected
   Type: Informational
   Created: 2017-03-29
   License: CC0-1.0
diff --git a/bip-0155.mediawiki b/bip-0155.mediawiki
index 1364a3f..71fe3cc 100644
--- a/bip-0155.mediawiki
+++ b/bip-0155.mediawiki
@@ -46,7 +46,7 @@ The <code>addrv2</code> message is defined as a message where <code>pchCommand =
 It is serialized in the standard encoding for P2P messages.
 Its format is similar to the current <code>addr</code> message format
 <ref>[https://bitcoin.org/en/developer-reference#addr Bitcoin Developer Reference: addr message]</ref>, with the difference that the 
-fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the time and services format has been changed to VARINT.
+fixed 16-byte IP address is replaced by a network ID and a variable-length address, and the services format has been changed to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize].
 
 This means that the message contains a serialized <code>std::vector</code> of the following structure:
 
@@ -55,13 +55,13 @@ This means that the message contains a serialized <code>std::vector</code> of th
 !Name
 !Description
 |-
-| <code>VARINT</code> (unsigned)
+| <code>uint32_t</code>
 | <code>time</code>
-| Time that this node was last seen as connected to the network. A time in Unix epoch time format, up to 64 bits wide.
+| Time that this node was last seen as connected to the network. A time in Unix epoch time format.
 |-
-| <code>VARINT</code> (unsigned)
+| <code>CompactSize</code>
 | <code>services</code>
-| Service bits. A 64-wide bit field.
+| Service bits. A bit field that is 64 bits wide, encoded in [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize].
 |-
 | <code>uint8_t</code>
 | <code>networkID</code>
@@ -144,15 +144,13 @@ The reference implementation is available at (to be done)
 
 ==Acknowledgements==
 
-- Jonas Schnelli: change <code>services</code> field to VARINT, to make the message more compact in the likely case instead of always using 8 bytes.
-
-- Luke-Jr: change <code>time</code> field to VARINT, for post-2038 compatibility.
+- Jonas Schnelli: change <code>services</code> field to [https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer CompactSize], to make the message more compact in the likely case instead of always using 8 bytes.
 
 - Gregory Maxwell: various suggestions regarding extensibility
 
 ==Appendix A: Tor v2 address encoding==
 
-The new message introduces a separate network ID for <code>TORV2</code>. 
+The new message introduces a separate network ID for <code>TORV2</code>.
 
 Clients MUST send Tor hidden service addresses with this network ID, with the 80-bit hidden service ID in the address field. This is the same as the representation in the legacy <code>addr</code> message, minus the 6 byte prefix of the OnionCat wrapping.
 
@@ -166,10 +164,11 @@ onion_address = base32(PUBKEY | CHECKSUM | VERSION) + ".onion"
  CHECKSUM = H(".onion checksum" | PUBKEY | VERSION)[:2]
 
  where:
-   - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service.
-   - VERSION is an one byte version field (default value '\x03')
+   - PUBKEY is the 32 bytes ed25519 master pubkey of the hidden service
+   - VERSION is a one byte version field (default value '\x03')
    - ".onion checksum" is a constant string
    - CHECKSUM is truncated to two bytes before inserting it in onion_address
+   - H() is the SHA3-256 cryptographic hash function
 </pre>
 
 Tor v3 addresses MUST be sent with the <code>TORV3</code> network ID, with the 32-byte PUBKEY part in the address field. As VERSION will always be '\x03' in the case of v3 addresses, this is enough to reconstruct the onion address.
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 65fa9a9..c424c5d 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -200,25 +200,25 @@ The currently defined per-input types are defined as follows:
 ** Value: The UTF-8 encoded commitment message string for the proof-of-reserves.  See [[bip-0127.mediawiki|BIP 127]] for more information.
 *** <tt>{porCommitment}</tt>
 
-* Type: RIPEMD160 preimage <tt>PSBT_RIPEMD160 = 0x0a</tt>
+* Type: RIPEMD160 preimage <tt>PSBT_IN_RIPEMD160 = 0x0a</tt>
 ** Key: The resulting hash of the preimage
 *** <tt>{0x0a}|{20-byte hash}</tt>
 ** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `RIPEMD160` algorithm
 *** <tt>{preimage}</tt>
 
-* Type: SHA256 preimage <tt>PSBT_SHA256 = 0x0b</tt>
+* Type: SHA256 preimage <tt>PSBT_IN_SHA256 = 0x0b</tt>
 ** Key: The resulting hash of the preimage
 *** <tt>{0x0b}|{32-byte hash}</tt>
 ** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm
 *** <tt>{preimage}</tt>
 
-* Type: HASH160 preimage <tt>PSBT_HASH160 = 0x0c</tt>
+* Type: HASH160 preimage <tt>PSBT_IN_HASH160 = 0x0c</tt>
 ** Key: The resulting hash of the preimage
 *** <tt>{0x0c}|{20-byte hash}</tt>
 ** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm followed by the `RIPEMD160` algorithm
 *** <tt>{preimage}</tt>
 
-* Type: HASH256 preimage <tt>PSBT_HASH256 = 0x0d</tt>
+* Type: HASH256 preimage <tt>PSBT_IN_HASH256 = 0x0d</tt>
 ** Key: The resulting hash of the preimage
 *** <tt>{0x0d}|{32-byte hash}</tt>
 ** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm twice
@@ -350,9 +350,9 @@ It is useful when there are additional data that they need attached to a PSBT bu
 The proprietary use type is not to be used by any public specification and there is no expectation that any publicly available software be able to understand any specific meanings of it and the subtypes.
 This type must be used for internal processes only.
 
-==Responsibilities==
+==Roles==
 
-Using the transaction format involves many different responsibilities. Multiple responsibilities can be handled by a single entity, but each responsibility is specialized in what it should be capable of doing.
+Using the transaction format involves many different roles. Multiple roles can be handled by a single entity, but each role is specialized in what it should be capable of doing.
 
 ===Creator===
 
@@ -373,7 +373,7 @@ The Signer must only accept a PSBT.
 The Signer must only use the UTXOs provided in the PSBT to produce signatures for inputs.
 Before signing a non-witness input, the Signer must verify that the TXID of the non-witness UTXO matches the TXID specified in the unsigned transaction.
 Before signing a witness input, the Signer must verify that the witnessScript (if provided) matches the hash specified in the UTXO or the redeemScript, and the redeemScript (if provided) matches the hash in the UTXO.
-The Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. <ref>'''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 173 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in <tt>PSBT_IN_WITNESS_UTXO<tt> of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) be provided to ensure that the amounts of other inputs are not being tampered with.</ref>
+The Signer may choose to fail to sign a segwit input if a non-witness UTXO is not provided. <ref>'''Why would non-witness UTXOs be provided for segwit inputs?''' The sighash algorithm for Segwit specified in BIP 173 is known to have an issue where an attacker could trick a user to sending Bitcoin to fees if they are able to convince the user to sign a malicious transaction multiple times. This is possible because the amounts in <tt>PSBT_IN_WITNESS_UTXO</tt> of other segwit inputs can be modified without effecting the signature for a particular input. In order to prevent this kind of attack, many wallets are requiring that the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) be provided to ensure that the amounts of other inputs are not being tampered with.</ref>
 The Signer should not need any additional data sources, as all necessary information is provided in the PSBT format.
 The Signer must only add data to a PSBT.
 Any signatures created by the Signer must be added as a "Partial Signature" key-value pair for the respective input it relates to.
@@ -839,6 +839,26 @@ Any data types, their associated scope and BIP number must be defined here
 | [[bip-0127.mediawiki|BIP 127]]
 |-
 | Input
+| 10
+| PSBT_IN_RIPEMD160
+| BIP 174
+|-
+| Input
+| 11
+| PSBT_IN_SHA256
+| BIP 174
+|-
+| Input
+| 12
+| PSBT_IN_HASH160
+| BIP 174
+|-
+| Input
+| 13
+| PSBT_IN_HASH256
+| BIP 174
+|-
+| Input
 | 252
 | PSBT_IN_PROPRIETARY
 | BIP 174
diff --git a/bip-0325.mediawiki b/bip-0325.mediawiki
index 30a7b6e..066c3f2 100644
--- a/bip-0325.mediawiki
+++ b/bip-0325.mediawiki
@@ -21,19 +21,20 @@ Testnet is a great place to try out new things without risking real money, but i
 
 A new type of test network would be more suitable for integration testing by organizations such as exchanges, or testing of next generation Layer-2 protocols like Eltoo or sidechain pegs. The goal is not to be perfectly reliable but rather to have a predictable amount of unreliability. You want a test network to behave like mainnet (i.e. no thousands of block reorgs) while also making it easier to trigger expected but rare events like a 6-block reorg. Regtest is not suitable for longer-term scenarios involving multiple independent parties because creating blocks costs nothing, so any party can completely control the test network.
 
-
 == Specification ==
 
 A new type of network ("signet"), which takes an additional consensus parameter called the challenge (scriptPubKey). The challenge can be a simple pubkey (P2PKH style), or a k-of-n multisig, or any other script you would want.
 
-The witness commitment of the coinbase transaction is extended to include a secondary commitment (the signature/solution) of either:
+Signet requires all blocks to have a BIP 141 commitment in the coinbase transaction. In order to provide a non-empty solution to the block challenge the block's BIP 141 commitment's optional data must include an additional commitment of the signature/solution for the block:
 
     1-5 bytes - Push the following (4 + x + y) bytes
     4 bytes - Signet header (0xecc7daa2)
     x bytes - scriptSig
     y bytes - scriptWitness
 
-The scriptSig is serialized by first encoding its length as CompactSize. If the scriptWitness is empty, it is encoded as 0 bytes, otherwise it is encoded in the usual way (see BIP 141 "witness" encoding).
+In the special case where an empty solution is valid (ie scriptSig and scriptWitness are both empty) this additional commitment can optionally be left out. This special case is to allow non-signet-aware block generation code to be used to test a custom signet chain where the challenge is trivially true.
+
+The scriptSig is serialized by first encoding its length as CompactSize. The scriptWitness stack is serialized as described in BIP 141.
 
 Any push operations that do not start with the 4 byte Signet header are ignored. Multiple push operations with the 4 byte Signet header are ignored except for the first instance of the header.
 
@@ -79,11 +80,12 @@ The genesis block is the same for all signet networks, whereas the message start
 
 === Genesis Block ===
 
-* Time stamp: 1534313275
-* Nonce: 100123
-* Difficulty: 1e2adc28
+* Time stamp: 1598918400
+* Nonce: 52613770
+* Difficulty: 0x1e0377ae
+* Version: 1
 
-The resulting genesis block hash is 0000032d7f67af9ec7b7152aea0fe7c95b9804ff973265e252f245e0ae61799d, and the block hex is 0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a3bc3735b28dc2a1e1b8701000101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000.
+The resulting genesis block hash is 00000008819873e925422c1ff0f99f7cc9bbb232af63a077a480a3633bee1ef6, and the block hex is 0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a008f4d5fae77031e8ad222030101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff4d04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73ffffffff0100f2052a01000000434104678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5fac00000000.
 
 === Message Start ===
 
diff --git a/bip-0340.mediawiki b/bip-0340.mediawiki
index 9502a69..f22194f 100644
--- a/bip-0340.mediawiki
+++ b/bip-0340.mediawiki
@@ -110,7 +110,7 @@ The following conventions are used, with constants as defined for [https://www.s
 ** The function ''bytes(x)'', where ''x'' is an integer, returns the 32-byte encoding of ''x'', most significant byte first.
 ** The function ''bytes(P)'', where ''P'' is a point, returns ''bytes(x(P))''.
 ** The function ''int(x)'', where ''x'' is a 32-byte array, returns the 256-bit unsigned integer whose most significant byte first encoding is ''x''.
-** The function ''has_even_y(P)'', where ''P'' is a point, returns ''y(P) mod 2 = 0''.
+** The function ''has_even_y(P)'', where ''P'' is a point for which ''not is_infinite(P)'', returns ''y(P) mod 2 = 0''.
 ** The function ''lift_x(x)'', where ''x'' is an integer in range ''0..p-1'', returns the point ''P'' for which ''x(P) = x''<ref>
     Given a candidate X coordinate ''x'' in the range ''0..p-1'', there exist either exactly two or exactly zero valid Y coordinates. If no valid Y coordinate exists, then ''x'' is not a valid X coordinate either, i.e., no point ''P'' exists for which ''x(P) = x''. The valid Y coordinates for a given candidate ''x'' are the square roots of ''c = x<sup>3</sup> + 7 mod p'' and they can be computed as ''y = &plusmn;c<sup>(p+1)/4</sup> mod p'' (see [https://en.wikipedia.org/wiki/Quadratic_residue#Prime_or_prime_power_modulus Quadratic residue]) if they exist, which can be checked by squaring and comparing with ''c''.</ref> and ''has_even_y(P)'', or fails if no such point exists. The function ''lift_x(x)'' is equivalent to the following pseudocode:
 *** Let ''c = x<sup>3</sup> + 7 mod p''.
@@ -184,7 +184,9 @@ The algorithm ''Verify(pk, m, sig)'' is defined as:
 * Let ''s = int(sig[32:64])''; fail if ''s &ge; n''.
 * Let ''e = int(hash<sub>BIP0340/challenge</sub>(bytes(r) || bytes(P) || m)) mod n''.
 * Let ''R = s⋅G - e⋅P''.
-* Fail if ''not has_even_y(R)'' or ''x(R) &ne; r''.
+* Fail if ''is_infinite(R)''.
+* Fail if ''not has_even_y(R)''.
+* Fail if ''x(R) &ne; r''.
 * Return success iff no failure occurred before reaching this point.
 
 For every valid secret key ''sk'' and message ''m'', ''Verify(PubKey(sk),m,Sign(sk,m))'' will succeed.
diff --git a/bip-0340/reference.py b/bip-0340/reference.py
index 5d17db5..5b38c0a 100644
--- a/bip-0340/reference.py
+++ b/bip-0340/reference.py
@@ -26,13 +26,15 @@ def tagged_hash(tag: str, msg: bytes) -> bytes:
     tag_hash = hashlib.sha256(tag.encode()).digest()
     return hashlib.sha256(tag_hash + tag_hash + msg).digest()
 
-def is_infinity(P: Optional[Point]) -> bool:
+def is_infinite(P: Optional[Point]) -> bool:
     return P is None
 
 def x(P: Point) -> int:
+    assert not is_infinite(P)
     return P[0]
 
 def y(P: Point) -> int:
+    assert not is_infinite(P)
     return P[1]
 
 def point_add(P1: Optional[Point], P2: Optional[Point]) -> Optional[Point]:
@@ -83,6 +85,7 @@ def hash_sha256(b: bytes) -> bytes:
     return hashlib.sha256(b).digest()
 
 def has_even_y(P: Point) -> bool:
+    assert not is_infinite(P)
     return y(P) % 2 == 0
 
 def pubkey_gen(seckey: bytes) -> bytes:
diff --git a/bip-0340/test-vectors.py b/bip-0340/test-vectors.py
index e5b8847..d1bf6b2 100644
--- a/bip-0340/test-vectors.py
+++ b/bip-0340/test-vectors.py
@@ -6,7 +6,7 @@ def is_square(x):
 
 def has_square_y(P):
     """Determine if P has a square Y coordinate. Used in an earlier draft of BIP340."""
-    assert not is_infinity(P)
+    assert not is_infinite(P)
     return is_square(P[1])
 
 def vector0():
diff --git a/bip-0341.mediawiki b/bip-0341.mediawiki
index 7ac5bf8..0f8d32a 100644
--- a/bip-0341.mediawiki
+++ b/bip-0341.mediawiki
@@ -193,7 +193,7 @@ def taproot_tweak_seckey(seckey0, h):
 </source>
 
 The following function, <code>taproot_output_script</code>, returns a byte array with the scriptPubKey (see [[bip-0141.mediawiki|BIP141]]).
-<code>ser_script</code> refers to a function that prefixes its input with a CCompactSize-encoded length.
+<code>ser_script</code> refers to a function that prefixes its input with a CompactSize-encoded length.
 
 <source lang="python">
 def taproot_tree_helper(script_tree):
diff --git a/bip-0342.mediawiki b/bip-0342.mediawiki
index 3cf87a3..7e00a2e 100644
--- a/bip-0342.mediawiki
+++ b/bip-0342.mediawiki
@@ -125,7 +125,7 @@ In summary, the semantics of signature validation is identical to BIP340, except
 In addition to changing the semantics of a number of opcodes, there are also some changes to the resource limitations:
 * '''Script size limit''' The maximum script size of 10000 bytes does not apply. Their size is only implicitly bounded by the block weight limit.<ref>'''Why is a limit on script size no longer needed?''' Since there is no <code>scriptCode</code> directly included in the signature hash (only indirectly through a precomputable tapleaf hash), the CPU time spent on a signature check is no longer proportional to the size of the script being executed.</ref>
 * '''Non-push opcodes limit''' The maximum non-push opcodes limit of 201 per script does not apply.<ref>'''Why is a limit on the number of opcodes no longer needed?''' An opcode limit only helps to the extent that it can prevent data structures from growing unboundedly during execution (both because of memory usage, and because of time that may grow in proportion to the size of those structures). The size of stack and altstack is already independently limited. By using O(1) logic for <code>OP_IF</code>, <code>OP_NOTIF</code>, <code>OP_ELSE</code>, and <code>OP_ENDIF</code> as suggested [https://bitslog.com/2017/04/17/new-quadratic-delays-in-bitcoin-scripts/ here] and implemented [https://github.com/bitcoin/bitcoin/pull/16902 here], the only other instance can be avoided as well.</ref>
-* '''Sigops limit''' The sigops in tapscripts do not count towards the block-wide limit of 80000 (weighted). Instead, there is a per-script sigops ''budget''. The budget equals 50 + the total serialized size in bytes of the transaction input's witness (including the <code>CCompactSize</code> prefix). Executing a signature opcode (<code>OP_CHECKSIG</code>, <code>OP_CHECKSIGVERIFY</code>, or <code>OP_CHECKSIGADD</code>) with a non-empty signature decrements the budget by 50. If that brings the budget below zero, the script fails immediately. Signature opcodes with unknown public key type and non-empty signature are also counted.<ref>'''The tapscript sigop limit''' The signature opcode limit protects against scripts which are slow to verify due to excessively many signature operations. In tapscript the number of signature opcodes does not count towards the BIP141 or legacy sigop limit. The old sigop limit makes transaction selection in block construction unnecessarily difficult because it is a second constraint in addition to weight. Instead, the number of tapscript signature opcodes is limited by witness weight. Additionally, the limit applies to the transaction input instead of the block and only actually executed signature opcodes are counted. Tapscript execution allows one signature opcode per 50 witness weight units plus one free signature opcode.</ref><ref>'''Parameter choice of the sigop limit''' Regular witnesses are unaffected by the limit as their weight is composed of public key and (<code>SIGHASH_ALL</code>) signature pairs with ''33 + 65'' weight units each (which includes a 1 weight unit <code>CCompactSize</code> tag). This is also the case if public keys are reused in the script because a signature's weight alone is 65 or 66 weight units. However, the limit increases the fees of abnormal scripts with duplicate signatures (and public keys) by requiring additional weight. The weight per sigop factor 50 corresponds to the ratio of BIP141 block limits: 4 mega weight units divided by 80,000 sigops. The "free" signature opcode permitted by the limit exists to account for the weight of the non-witness parts of the transaction input.</ref><ref>'''Why are only signature opcodes counted toward the budget, and not for example hashing opcodes or other expensive operations?''' It turns out that the CPU cost per witness byte for verification of a script consisting of the maximum density of signature checking opcodes (taking the 50 WU/sigop limit into account) is already very close to that of scripts packed with other opcodes, including hashing opcodes (taking the 520 byte stack element limit into account) and <code>OP_ROLL</code> (taking the 1000 stack element limit into account). That said, the construction is very flexible, and allows adding new signature opcodes like <code>CHECKSIGFROMSTACK</code> to count towards the limit through a soft fork. Even if in the future new opcodes are introduced which change normal script cost there is no need to stuff the witness with meaningless data. Instead, the taproot annex can be used to add weight to the witness without increasing the actual witness size.</ref>.
+* '''Sigops limit''' The sigops in tapscripts do not count towards the block-wide limit of 80000 (weighted). Instead, there is a per-script sigops ''budget''. The budget equals 50 + the total serialized size in bytes of the transaction input's witness (including the <code>CompactSize</code> prefix). Executing a signature opcode (<code>OP_CHECKSIG</code>, <code>OP_CHECKSIGVERIFY</code>, or <code>OP_CHECKSIGADD</code>) with a non-empty signature decrements the budget by 50. If that brings the budget below zero, the script fails immediately. Signature opcodes with unknown public key type and non-empty signature are also counted.<ref>'''The tapscript sigop limit''' The signature opcode limit protects against scripts which are slow to verify due to excessively many signature operations. In tapscript the number of signature opcodes does not count towards the BIP141 or legacy sigop limit. The old sigop limit makes transaction selection in block construction unnecessarily difficult because it is a second constraint in addition to weight. Instead, the number of tapscript signature opcodes is limited by witness weight. Additionally, the limit applies to the transaction input instead of the block and only actually executed signature opcodes are counted. Tapscript execution allows one signature opcode per 50 witness weight units plus one free signature opcode.</ref><ref>'''Parameter choice of the sigop limit''' Regular witnesses are unaffected by the limit as their weight is composed of public key and (<code>SIGHASH_ALL</code>) signature pairs with ''33 + 65'' weight units each (which includes a 1 weight unit <code>CompactSize</code> tag). This is also the case if public keys are reused in the script because a signature's weight alone is 65 or 66 weight units. However, the limit increases the fees of abnormal scripts with duplicate signatures (and public keys) by requiring additional weight. The weight per sigop factor 50 corresponds to the ratio of BIP141 block limits: 4 mega weight units divided by 80,000 sigops. The "free" signature opcode permitted by the limit exists to account for the weight of the non-witness parts of the transaction input.</ref><ref>'''Why are only signature opcodes counted toward the budget, and not for example hashing opcodes or other expensive operations?''' It turns out that the CPU cost per witness byte for verification of a script consisting of the maximum density of signature checking opcodes (taking the 50 WU/sigop limit into account) is already very close to that of scripts packed with other opcodes, including hashing opcodes (taking the 520 byte stack element limit into account) and <code>OP_ROLL</code> (taking the 1000 stack element limit into account). That said, the construction is very flexible, and allows adding new signature opcodes like <code>CHECKSIGFROMSTACK</code> to count towards the limit through a soft fork. Even if in the future new opcodes are introduced which change normal script cost there is no need to stuff the witness with meaningless data. Instead, the taproot annex can be used to add weight to the witness without increasing the actual witness size.</ref>.
 * '''Stack + altstack element count limit''' The existing limit of 1000 elements in the stack and altstack together after every executed opcode remains. It is extended to also apply to the size of initial stack.
 * '''Stack element size limit''' The existing limit of maximum 520 bytes per stack element remains, both in the initial stack and in push opcodes.