extra_
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
-| 1+ || service_count || [[Protocol_specification#Variable_length_integer|var_int]] || Number of extra services
+| 1+ || service_count || [[Protocol_specification#variable-length-integer|var_int]] || Number of extra services
|-
| ? || service_list || service[] || List of service definitions
|}
@@ -34,11 +34,11 @@ The service definitions service[] are given in the following format
{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
-| ? || service_name || [[#Variable length string|var_str]] || Unique service identifier
+| ? || service_name || [[#variable-length-string|var_str]] || Unique service identifier
|-
| 4 || service_version || uint32_t || Identifies service version being used by the node
|-
-| ? || service_data || [[#Variable length string|var_str]] || Additional service-specific data
+| ? || service_data || [[#variable-length-string|var_str]] || Additional service-specific data
|}
A node MUST NOT announce two services with the same service_name. If a remote node sends such a version message the client MAY disconnect.
diff --git a/bip-0046.mediawiki b/bip-0046.mediawiki
index 98558be574..55ac345b78 100644
--- a/bip-0046.mediawiki
+++ b/bip-0046.mediawiki
@@ -76,7 +76,7 @@ For index, addresses are numbered from 0 in a sequentially increasing m
=== Timelock derivation ===
-The timelock used in the time-locked address is derived from the index. The timelock is a unix time. It is always at the start of the first second at the beginning of the month (see [[#Test vectors|Test vectors]]). The index counts upwards the months from January 2020, ending in December 2099. At 12 months per year for 80 years this totals 960 timelocks. Note that care must be taken with the year 2038 problem on 32-bit systems.
+The timelock used in the time-locked address is derived from the index. The timelock is a unix time. It is always at the start of the first second at the beginning of the month (see [[#test-vectors|Test vectors]]). The index counts upwards the months from January 2020, ending in December 2099. At 12 months per year for 80 years this totals 960 timelocks. Note that care must be taken with the year 2038 problem on 32-bit systems.
year = 2020 + index // 12
diff --git a/bip-0054.md b/bip-0054.md
index d278f58a7e..fbc1dc1657 100644
--- a/bip-0054.md
+++ b/bip-0054.md
@@ -225,7 +225,7 @@ notably of Bitcoin Core but also of all other implementations the authors are aw
[BIP16 specs]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki#specification
[SE timewarp]: https://bitcoin.stackexchange.com/questions/75831/what-is-time-warp-attack-and-how-does-it-work-in-general/75834#75834
[Delving Murch-Zawy]: https://delvingbitcoin.org/t/zawy-s-alternating-timestamp-attack/1062#variant-on-zawys-attack-2
-[BIP94 timewarp]: https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#user-content-Time_Warp_Fix
+[BIP94 timewarp]: https://github.com/bitcoin/bips/blob/master/bip-0094.mediawiki#time-warp-fix
[Sjors grace period]: https://delvingbitcoin.org/t/timewarp-attack-600-second-grace-period/1326
[grace period debate summary]: https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710/66
[O'Connor OP_CODESEPARATOR]: https://gnusha.org/pi/bitcoindev/CAMZUoKneArC+YZ36YFwxNTKsDtJhEz5P2cosXKxJS8Rf_3Nyuw@mail.gmail.com
diff --git a/bip-0075.mediawiki b/bip-0075.mediawiki
index 0d9479ac97..0a2b35c826 100644
--- a/bip-0075.mediawiki
+++ b/bip-0075.mediawiki
@@ -125,13 +125,13 @@ message InvoiceRequest {
|-
| memo || Human-readable description of invoice request for the receiver
|-
-| notification_url || Secure (usually TLS-protected HTTP) location where an [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] SHOULD be sent when ready
+| notification_url || Secure (usually TLS-protected HTTP) location where an [[#encryptedprotocolmessage|EncryptedProtocolMessage]] SHOULD be sent when ready
|-
| signature || PKI-dependent signature
|}
===ProtocolMessageType Enum===
-This enum is used in the newly defined [[#ProtocolMessage|ProtocolMessage]] and [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages to define the serialized message type. The '''ProtocolMessageType''' enum is defined in an extensible way to allow for new message type additions to the Payment Protocol.
+This enum is used in the newly defined [[#protocolmessage|ProtocolMessage]] and [[#encryptedprotocolmessage|EncryptedProtocolMessage]] messages to define the serialized message type. The '''ProtocolMessageType''' enum is defined in an extensible way to allow for new message type additions to the Payment Protocol.
enum ProtocolMessageType {
UNKNOWN_MESSAGE_TYPE = 0;
@@ -219,12 +219,12 @@ message EncryptedProtocolMessage {
==Payment Protocol Process with InvoiceRequests==
The full process overview for using '''InvoiceRequests''' in the Payment Protocol is defined below.
-All Payment Protocol messages MUST be encapsulated in either a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]]. Once the process begins using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#EncryptedProtocolMessage|EncryptedProtocolMessages]].
+All Payment Protocol messages MUST be encapsulated in either a [[#protocolmessage|ProtocolMessage]] or [[#encryptedprotocolmessage|EncryptedProtocolMessage]]. Once the process begins using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] messages, all subsequent communications MUST use [[#encryptedprotocolmessage|EncryptedProtocolMessages]].
-All Payment Protocol messages SHOULD be communicated using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#InvoiceRequest|InvoiceRequest]] MAY be communicated using the [[#ProtocolMessage|ProtocolMessage]] if the receiver's public key is unknown.
+All Payment Protocol messages SHOULD be communicated using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] encapsulating messages with the exception that an [[#invoicerequest|InvoiceRequest]] MAY be communicated using the [[#protocolmessage|ProtocolMessage]] if the receiver's public key is unknown.
-The process of creating encrypted Payment Protocol messages is enumerated in [[#Sending_Encrypted_Payment_Protocol_Messages_using_EncryptedProtocolMessages|Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages]], and the process of decrypting encrypted messages can be found under [[#Validating_and_Decrypting_Payment_Protocol_Messages_using_EncryptedProtocolMessages|Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages]].
+The process of creating encrypted Payment Protocol messages is enumerated in [[#sending-encrypted-payment-protocol-messages-using-encryptedprotocolmessages|Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages]], and the process of decrypting encrypted messages can be found under [[#validating-and-decrypting-payment-protocol-messages-using-encryptedprotocolmessages|Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages]].
A standard exchange from start to finish would look like the following:
@@ -238,7 +238,7 @@ A standard exchange from start to finish would look like the following:
# Sender validates PaymentRequest retrieved from the EncryptedProtocolMessage
# The PaymentRequest is processed according to [[bip-0070.mediawiki|BIP70]], including optional Payment and PaymentACK messages encapsulated in EncryptedProtocolMessage messages.
-'''NOTE:''' See [[#Initial_Public_Key_Retrieval_for_InvoiceRequest_Encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] for possible options to retrieve Receiver's public key.
+'''NOTE:''' See [[#initial-public-key-retrieval-for-invoicerequest-encryption|Initial Public Key Retrieval for InvoiceRequest Encryption]] for possible options to retrieve Receiver's public key.
@@ -257,7 +257,7 @@ When communicated via '''HTTP''', the listed messages MUST be transmitted via TL
===Payment Protocol Status Communication===
-Every [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately.
+Every [[#protocolmessage|ProtocolMessage]] or [[#encryptedprotocolmessage|EncryptedProtocolMessage]] MUST include a status code which conveys information about the last message received, if any (for the first message sent, use a status of 1 "OK" even though there was no previous message). In the case of an error that causes the Payment Protocol process to be stopped or requires that message be retried, a ProtocolMessage or EncryptedProtocolMessage SHOULD be returned by the party generating the error. The content of the message MUST contain the same '''serialized_message''' or '''encrypted_message''' and identifier (if present) and MUST have the status_code set appropriately.
The status_message value SHOULD be set with a human readable explanation of the status code.
@@ -311,27 +311,27 @@ For the following we assume the Sender already knows the Receiver's public key,
'''nonce''' MUST be set to a non-repeating number '''and''' MUST be chosen by the encryptor. The current epoch time in microseconds SHOULD be used, unless the creating device doesn't have access to a RTC (in the case of a smart card, for example). The service receiving the message containing the '''nonce''' MAY use whatever method to make sure that the '''nonce''' is never repeated.
===InvoiceRequest Message Creation===
-* Create an [[#InvoiceRequest|InvoiceRequest]] message
+* Create an [[#invoicerequest|InvoiceRequest]] message
* '''sender_public_key''' MUST be set to the public key of an EC keypair
-* '''amount''' is optional. If the amount is not specified by the [[#InvoiceRequest|InvoiceRequest]], the Receiver MAY specify the amount in the returned PaymentRequest. If an amount is specified by the [[#InvoiceRequest|InvoiceRequest]] and a PaymentRequest cannot be generated for that amount, the [[#InvoiceRequest|InvoiceRequest]] SHOULD return the same [[#InvoiceRequest|InvoiceRequest]] in a [[#ProtocolMessage|ProtocolMessage]] or [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] with the status_code and status_message fields set appropriately.
+* '''amount''' is optional. If the amount is not specified by the [[#invoicerequest|InvoiceRequest]], the Receiver MAY specify the amount in the returned PaymentRequest. If an amount is specified by the [[#invoicerequest|InvoiceRequest]] and a PaymentRequest cannot be generated for that amount, the [[#invoicerequest|InvoiceRequest]] SHOULD return the same [[#invoicerequest|InvoiceRequest]] in a [[#protocolmessage|ProtocolMessage]] or [[#encryptedprotocolmessage|EncryptedProtocolMessage]] with the status_code and status_message fields set appropriately.
* '''memo''' is optional. This MAY be set to a human readable description of the InvoiceRequest
-* Set '''notification_url''' to URL that the Receiver will submit completed PaymentRequest (encapsulated in an [[#EncryptedProtocolMessage|EncryptedProtocolMessage]]) to
+* Set '''notification_url''' to URL that the Receiver will submit completed PaymentRequest (encapsulated in an [[#encryptedprotocolmessage|EncryptedProtocolMessage]]) to
* If NOT including certificate, set '''pki_type''' to "none"
* If including certificate:
** Set '''pki_type''' to "x509+sha256"
** Set '''pki_data''' as it would be set in BIP-0070 ([https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki#Certificates Certificates])
-** Sign [[#InvoiceRequest|InvoiceRequest]] with signature = "" using the X509 Certificate's private key
+** Sign [[#invoicerequest|InvoiceRequest]] with signature = "" using the X509 Certificate's private key
** Set '''signature''' value to the computed signature
===InvoiceRequest Validation===
* Validate '''sender_public_key''' is a valid EC public key
* Validate '''notification_url''', if set, contains characters deemed valid for a URL (avoiding XSS related characters, etc).
-* If '''pki_type''' is None, [[#InvoiceRequest|InvoiceRequest]] is VALID
-* If '''pki_type''' is x509+sha256 and '''signature''' is valid for the serialized [[#InvoiceRequest|InvoiceRequest]] where signature is set to "", [[#InvoiceRequest|InvoiceRequest]] is VALID
+* If '''pki_type''' is None, [[#invoicerequest|InvoiceRequest]] is VALID
+* If '''pki_type''' is x509+sha256 and '''signature''' is valid for the serialized [[#invoicerequest|InvoiceRequest]] where signature is set to "", [[#invoicerequest|InvoiceRequest]] is VALID
===Sending Encrypted Payment Protocol Messages using EncryptedProtocolMessages===
-* Encrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ECDH_Point_Generation_and_AES256_GCM_Mode_Setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]
-* Create [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] message
+* Encrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ecdh-point-generation-and-aes256-gcm-mode-setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]
+* Create [[#encryptedprotocolmessage|EncryptedProtocolMessage]] message
* Set '''encrypted_message''' to be the encrypted value of the Payment Protocol message
* '''version''' SHOULD be set to the highest version number the client understands (currently 1)
* '''sender_public_key''' MUST be set to the public key of the Sender's EC keypair
@@ -339,14 +339,14 @@ For the following we assume the Sender already knows the Receiver's public key,
* '''nonce''' MUST be set to the nonce used in the AES-256-GCM encryption operation
* Set '''identifier''' to the identifier value received in the originating InvoiceRequest's ProtocolMessage or EncryptedProtocolMessage wrapper message
* Set '''signature''' to ""
-* Sign the serialized [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] message with the communicating party's EC public key
+* Sign the serialized [[#encryptedprotocolmessage|EncryptedProtocolMessage]] message with the communicating party's EC public key
* Set '''signature''' to the result of the signature operation above
-'''SIGNATURE NOTE:''' [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] messages are signed with the public keys of the party transmitting the message. This allows a Store & Forward server or other transmission system to prevent spam or other abuses. For those who are privacy conscious and don't want the server to track the interactions between two public keys, the Sender can generate a new public key for each interaction to keep their identity anonymous.
+'''SIGNATURE NOTE:''' [[#encryptedprotocolmessage|EncryptedProtocolMessage]] messages are signed with the public keys of the party transmitting the message. This allows a Store & Forward server or other transmission system to prevent spam or other abuses. For those who are privacy conscious and don't want the server to track the interactions between two public keys, the Sender can generate a new public key for each interaction to keep their identity anonymous.
===Validating and Decrypting Payment Protocol Messages using EncryptedProtocolMessages===
-* The '''nonce''' MUST not be repeated. The service receiving the [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] MAY use whatever method to make sure that the nonce is never repeated.
-* Decrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ECDH_Point_Generation_and_AES256_GCM_Mode_Setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]
+* The '''nonce''' MUST not be repeated. The service receiving the [[#encryptedprotocolmessage|EncryptedProtocolMessage]] MAY use whatever method to make sure that the nonce is never repeated.
+* Decrypt the serialized Payment Protocol message using AES-256-GCM setup as described in [[#ecdh-point-generation-and-aes256-gcm-mode-setup|ECDH Point Generation and AES-256 (GCM Mode) Setup]]
* Deserialize the serialized Payment Protocol message
===ECDH Point Generation and AES-256 (GCM Mode) Setup===
@@ -369,7 +369,7 @@ The 16 byte authentication tag resulting from the AES-GCM encrypt operation MUST
When either '''status_code''' OR '''status_message''' are present, the AES-256 GCM authenticated data used in both the encrypt and decrypt operations MUST be: STRING(status_code) || status_message. Otherwise, there is no additional authenticated data. This provides that, while not encrypted, the status_code and status_message are authenticated.
===Initial Public Key Retrieval for InvoiceRequest Encryption===
-Initial public key retrieval for [[#InvoiceRequest|InvoiceRequest]] encryption via [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following:
+Initial public key retrieval for [[#invoicerequest|InvoiceRequest]] encryption via [[#encryptedprotocolmessage|EncryptedProtocolMessage]] encapsulation can be done in a number of ways including, but not limited to, the following:
# Wallet Name public key asset type resolution - DNSSEC-validated name resolution returns Base64 encoded DER-formatted EC public key via TXT Record [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
# Key Server lookup - Key Server lookup (similar to PGP's pgp.mit.edu) based on key server identifier (i.e., e-mail address) returns Base64 encoded DER-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
# QR Code - Use of QR-code to encode SEC-formatted EC public key [https://www.ietf.org/rfc/rfc5480.txt RFC 5480]
@@ -408,12 +408,12 @@ The following flowchart is borrowed from [[bip-0070.mediawiki|BIP70]] and expand
==Mobile to Mobile Examples==
===Full Payment Protocol===
-The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use of an InvoiceRequest, a Store & Forward server, PaymentRequest, Payment and PaymentACK. In this case, the PaymentRequest, Payment and PaymentACK messages are encrypted using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] '''and''' the Receiver submits the transaction to the Bitcoin network.
+The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client with the use of an InvoiceRequest, a Store & Forward server, PaymentRequest, Payment and PaymentACK. In this case, the PaymentRequest, Payment and PaymentACK messages are encrypted using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] '''and''' the Receiver submits the transaction to the Bitcoin network.
===Encrypting Initial InvoiceRequest via EncryptedProtocolMessage===
-The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client using an [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] to transmit the InvoiceRequest using encryption, Store & Forward server, and PaymentRequest. In this case, all Payment Protocol messages are encrypting using [[#EncryptedProtocolMessage|EncryptedProtocolMessage]] '''and''' the Sender submits the transaction to the Bitcoin network.
+The following diagram shows a sample flow in which one mobile client is sending value to a second mobile client using an [[#encryptedprotocolmessage|EncryptedProtocolMessage]] to transmit the InvoiceRequest using encryption, Store & Forward server, and PaymentRequest. In this case, all Payment Protocol messages are encrypting using [[#encryptedprotocolmessage|EncryptedProtocolMessage]] '''and''' the Sender submits the transaction to the Bitcoin network.
diff --git a/bip-0090.mediawiki b/bip-0090.mediawiki
index 3503835034..3b31e84e0a 100644
--- a/bip-0090.mediawiki
+++ b/bip-0090.mediawiki
@@ -21,7 +21,7 @@ BIPs 34, 65 and 66 were deployed on mainnet using miner signaling using block ve
# 75% rule: If 750 of the prior 1000 blocks are version N+1 or higher, then blocks with version N+1 or higher must correctly enforce the new consensus rule.
# 95% rule: If 950 of the prior 1000 blocks are version N+1 or higher, then blocks with version less than N+1 are invalid.
-Please see those [[#References|BIPs]] for more details.
+Please see those [[#references|BIPs]] for more details.
Note that this trigger mechanism is dependent on the chain history. To validate a block, we must test whether the trigger was met by looking at the previous 1000 blocks in the chain before it, which can be inefficient.
diff --git a/bip-0129.mediawiki b/bip-0129.mediawiki
index 2e19c9fb18..e8b38fd5b3 100644
--- a/bip-0129.mediawiki
+++ b/bip-0129.mediawiki
@@ -70,7 +70,7 @@ The Signer is any software or hardware that controls the private keys and can si
* The Coordinator creates a new multisig wallet creation session. The Coordinator constructs the multisig script and its policy parameters, such as the required number of signatures and the total number of Signers (M and N).
* The session should expire after some time period determined by the Coordinator, e.g., 24 hours. The timeout allows the encryption key to have lower entropy.
-* If encryption is enabled, the Coordinator distributes a secret TOKEN to each Signer over a secure channel. The Signer can use the TOKEN to derive an ENCRYPTION_KEY. Refer to the [[#Encryption]] section below for details on the TOKEN, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common TOKEN for all Signers, or to have one per Signer.
+* If encryption is enabled, the Coordinator distributes a secret TOKEN to each Signer over a secure channel. The Signer can use the TOKEN to derive an ENCRYPTION_KEY. Refer to the [[#encryption]] section below for details on the TOKEN, the key derivation function and the encryption scheme. Depending on the use case, the Coordinator can decide whether to share one common TOKEN for all Signers, or to have one per Signer.
* If encryption is disabled, the TOKEN is set to 0x00, and all the encryption/decryption steps below can be skipped.
=====Signer=====
@@ -188,7 +188,7 @@ Also refer to [https://github.com/BlockchainCommons/Research/blob/master/papers/
==Compatibility==
This specification is not backwards compatible with existing multisig implementations.
-BSMS is opt-in, meaning existing multisig implementations can continue working as-is, with the caveat that they are likely to have various pitfalls. Some of the problems with existing solutions have been described in the [[#Motivation]] section.
+BSMS is opt-in, meaning existing multisig implementations can continue working as-is, with the caveat that they are likely to have various pitfalls. Some of the problems with existing solutions have been described in the [[#motivation]] section.
To comply with this standard, a Signer must be able to persist the descriptor record in its storage.
diff --git a/bip-0145.mediawiki b/bip-0145.mediawiki
index ca99ad6eb6..eec525005a 100644
--- a/bip-0145.mediawiki
+++ b/bip-0145.mediawiki
@@ -47,19 +47,19 @@ The Objects listed in the response's "transactions" key is revised to include th
| hash || String || reversed hash of complete transaction (with witness data included) encoded in hexadecimal
|}
-Transactions with witness data may only be included if the template's "rules" list (see [[bip-0009.mediawiki#getblocktemplate_changes|BIP 9]]) includes "segwit".
+Transactions with witness data may only be included if the template's "rules" list (see [[bip-0009.mediawiki#getblocktemplate-changes|BIP 9]]) includes "segwit".
===Sigops===
-For templates with "segwit" enabled as a rule, the "sigoplimit" and "sigops" keys must use the new values as calculated in [[bip-0141.mediawiki#Sigops|BIP 141]].
+For templates with "segwit" enabled as a rule, the "sigoplimit" and "sigops" keys must use the new values as calculated in [[bip-0141.mediawiki#sigops|BIP 141]].
===Block Assembly with Witness Transactions===
When block assembly is done without witness transactions, no changes are made by this BIP, and it should be assembled as previously.
-When witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' "txid" field instead of "hash". A secondary merkle root MUST be calculated as per [[bip-0141.mediawiki#Commitment_structure|BIP 141's commitment structure specification]] to be inserted into the generation (coinbase) transaction.
+When witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' "txid" field instead of "hash". A secondary merkle root MUST be calculated as per [[bip-0141.mediawiki#commitment-structure|BIP 141's commitment structure specification]] to be inserted into the generation (coinbase) transaction.
-Servers MUST NOT include a commitment in the "coinbasetxn" key on the template. Clients MUST insert the commitment as an additional output at the end of the final generation (coinbase) transaction. Only if the template includes a "mutable" key (see [[bip-0023.mediawiki#Mutations|BIP 23 Mutations]]) including "generation", the client MAY in that case place the commitment output in any position it chooses, provided that no later output matches the commitment pattern.
+Servers MUST NOT include a commitment in the "coinbasetxn" key on the template. Clients MUST insert the commitment as an additional output at the end of the final generation (coinbase) transaction. Only if the template includes a "mutable" key (see [[bip-0023.mediawiki#mutations|BIP 23 Mutations]]) including "generation", the client MAY in that case place the commitment output in any position it chooses, provided that no later output matches the commitment pattern.
==Motivation==
diff --git a/bip-0152.mediawiki b/bip-0152.mediawiki
index 0977b9c821..ee098e0147 100644
--- a/bip-0152.mediawiki
+++ b/bip-0152.mediawiki
@@ -30,7 +30,7 @@ While the goal of this work is explicitly not to reduce block transfer latency,
===Intended Protocol Flow===
-The protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed [[#Implementation_Notes|later]]. The "high-bandwidth" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a sendcmpct message. In this mode, peers send new block announcements with the short transaction IDs already (via a cmpctblock message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage.
+The protocol is intended to be used in two ways, depending on the peers and bandwidth available, as discussed [[#implementation-notes|later]]. The "high-bandwidth" mode, which nodes may only enable for a few of their peers, is enabled by setting the first boolean to 1 in a sendcmpct message. In this mode, peers send new block announcements with the short transaction IDs already (via a cmpctblock message), possibly even before fully validating the block (as indicated by the grey box in the image above). In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual immediately. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the best-case latency to the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage.
The "low-bandwidth" mode is enabled by setting the first boolean to 0 in a sendcmpct message. In this mode, peers send new block announcements with the usual inv/headers announcements (as per BIP130, and after fully validating the block). The receiving peer may then request the block using a MSG_CMPCT_BLOCK getdata request, which will receive a response of the header and short transaction IDs. In some cases no further round-trip is needed, and the receiver can reconstruct the block and process it as usual, taking the same 1.5*RTT minimum time that nodes take today, though with significantly less bandwidth usage. When some transactions were not available from local sources (ie mempool), a getblocktxn/blocktxn roundtrip is necessary, bringing the latency to at least 2.5*RTT in this case, again with significantly less bandwidth usage than today. Because TCP often exhibits worse transfer latency for larger data sizes (as a multiple of RTT), total latency is expected to be reduced even when the full 2.5*RTT transfer mechanism is used.
diff --git a/bip-0321.mediawiki b/bip-0321.mediawiki
index 52837b3803..74a8689fda 100644
--- a/bip-0321.mediawiki
+++ b/bip-0321.mediawiki
@@ -69,7 +69,7 @@ The bitcoinaddress body MUST be either a base58 P2SH or P2PKH address, bech32 Se
The following keys are defined generally and apply to any URI regardless of payment instructions:
*label: Label for the recipient (e.g. name of receiver)
-*message: message that describes the transaction to the user ([[#Examples|see examples below]])
+*message: message that describes the transaction to the user ([[#examples|see examples below]])
*pop: a URI which the Bitcoin Wallet may return to in order to provide the application which initiated the payment with proof that a payment was completed.
The following keys are currently defined for payment instructions of various forms:
diff --git a/bip-0327.mediawiki b/bip-0327.mediawiki
index 93ed9a9a07..2ed08ba744 100644
--- a/bip-0327.mediawiki
+++ b/bip-0327.mediawiki
@@ -652,7 +652,7 @@ Algorithm ''ApplyXonlyTweak(P, t)'':
=== Negation Of The Secret Key When Signing ===
-In order to produce a partial signature for an X-only aggregate public key that is an aggregate of ''u'' individual public keys and tweaked ''v'' times (X-only or plain), the ''[[#Sign negation|Sign]]'' algorithm may need to negate the secret key during the signing process.
+In order to produce a partial signature for an X-only aggregate public key that is an aggregate of ''u'' individual public keys and tweaked ''v'' times (X-only or plain), the ''[[#sign-negation|Sign]]'' algorithm may need to negate the secret key during the signing process.
The following elliptic curve points arise as intermediate steps when creating a signature:
@@ -710,7 +710,7 @@ Then we have
= sumi=1..u(gv⋅gaccv⋅ai⋅di')*G''.
-Intuitively, ''gacci'' tracks accumulated sign flipping and ''tacci'' tracks the accumulated tweak value after applying the first ''i'' individual tweaks. Additionally, ''gv'' indicates whether ''Qv'' needed to be negated to produce the final X-only result. Thus, signer ''i'' multiplies its secret key ''di' '' with ''gv⋅gaccv'' in the ''[[#Sign negation|Sign]]'' algorithm.
+Intuitively, ''gacci'' tracks accumulated sign flipping and ''tacci'' tracks the accumulated tweak value after applying the first ''i'' individual tweaks. Additionally, ''gv'' indicates whether ''Qv'' needed to be negated to produce the final X-only result. Thus, signer ''i'' multiplies its secret key ''di' '' with ''gv⋅gaccv'' in the ''[[#sign-negation|Sign]]'' algorithm.
==== Negation Of The Individual Public Key When Partially Verifying ====
@@ -721,7 +721,7 @@ when producing a partial signature to ensure that the aggregate signature will c
-The ''[[#SigVerify negation|PartialSigVerifyInternal]]'' algorithm is supposed to check
+The ''[[#sigverify-negation|PartialSigVerifyInternal]]'' algorithm is supposed to check
''s⋅G = Re⁎ + e⋅a⋅d⋅G''.
diff --git a/bip-0345.mediawiki b/bip-0345.mediawiki
index 0bf4c10401..7eed90c212 100644
--- a/bip-0345.mediawiki
+++ b/bip-0345.mediawiki
@@ -270,7 +270,7 @@ where
After the stack is parsed, the following validation checks are performed:
-* Decrement the per-script sigops budget (see [https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#user-content-Resource_limits BIP-0342]) by 60['''Why is the sigops cost for OP_VAULT set to 60?''' To determine the validity of a trigger output, OP_VAULT must perform an EC multiplication and hashing proportional to the length of the control block in order to generate the output's expected TapTweak. This has been measured to have a cost in the worst case (max length control block) of roughly twice a Schnorr verification. Because the hashing cost could be mitigated by caching midstate, the cost is 60 and not 100.]; if the budget is brought below zero, script execution MUST fail and terminate immediately.
+* Decrement the per-script sigops budget (see [https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki#resource-limits BIP-0342]) by 60['''Why is the sigops cost for OP_VAULT set to 60?''' To determine the validity of a trigger output, OP_VAULT must perform an EC multiplication and hashing proportional to the length of the control block in order to generate the output's expected TapTweak. This has been measured to have a cost in the worst case (max length control block) of roughly twice a Schnorr verification. Because the hashing cost could be mitigated by caching midstate, the cost is 60 and not 100.]; if the budget is brought below zero, script execution MUST fail and terminate immediately.
* Let the output designated by
tr(KEY, TREE) takes a key expression as the first argument, and a tree expression as the second argument and produces a P2TR output script which has a script path.
-The keys produced by the first key expression are used as the internal key as specified by [[bip-0341.mediawiki#Constructing_and_spending_Taproot_outputs|BIP 341]].
+The keys produced by the first key expression are used as the internal key as specified by [[bip-0341.mediawiki#constructing-and-spending-taproot-outputs|BIP 341]].
The Tree expression becomes the Taproot script tree as described in BIP 341.
A merkle root is computed from this tree and combined with the internal key to create the Taproot output key.