[pull] master from bitcoin:master

bip-0174.mediawiki

@@ -511,7 +511,7 @@ Or, for participants performing fA(psbt) and fB(psbt): Combine(fA(psbt), fB(psbt
 ===Input Finalizer===
 
 The Input Finalizer must only accept a PSBT.
-For each input, the Input Finalizer determines if the input has enough data to pass validation. If it does, it must construct the <tt>0x07</tt> Finalized scriptSig and <tt>0x08</tt> Finalized scriptWitness and place them into the input key-value map.
+For each input, the Input Finalizer determines if the input has enough data to pass validation. If it does, it must construct the <tt>0x07</tt> Finalized scriptSig and <tt>0x08</tt> Finalized scriptWitness and place them into the input key-value map. If the input has a <tt>PSBT_IN_SIGHASH_TYPE</tt> field, the Input Finalizer must fail to finalize that input if any signature does not match the specified sighash type.
 If scriptSig is empty for an input, <tt>0x07</tt> should remain unset rather than assigned an empty array.
 Likewise, if no scriptWitness exists for an input, <tt>0x08</tt> should remain unset rather than assigned an empty array.
 All other data except the UTXO and unknown fields in the input key-value map should be cleared from the PSBT. The UTXO should be kept to allow Transaction Extractors to verify the final network serialized transaction.

bip-0434.md

@@ -127,16 +127,26 @@ The payload of the `feature` message contains exactly the following data:
 
 The `featureid` is encoded in the usual way, that is, as a `CompactSize`
 specifying the string length, followed by that many bytes. The string
-length MUST be between 4 and 80, inclusive. The string SHOULD include
-only printable ASCII characters (ie, each byte should have a value
-between 32 and 126, inclusive).
+length MUST be between 4[^feature-id-min] and 80[^feature-payload-max],
+inclusive. The string SHOULD include only printable ASCII characters
+(ie, each byte should have a value between 32 and 126, inclusive).
 
 Likewise, `featuredata` is encoded as a `CompactSize` specifying the
 byte-vector size, followed by that many bytes. How these bytes are
-interpreted is part of the feature's specification. The byte-vector size
-MUST NOT be more than 512 bytes. Note that the `featuredata` field is not
-optional, so if no data is required, an empty vector should be provided,
-ie serialized as `CompactSize` of 0.
+interpreted is part of the feature's specification. The byte-vector
+size MUST NOT be more than 512 bytes[^feature-payload-max]. Note that
+the `featuredata` field is not optional, so if no data is required,
+an empty vector should be provided, ie serialized as `CompactSize` of 0.
+
+The `featureid` MUST be a globally unique identifier for the feature.
+
+For features published as a BIP, the `featureid` SHOULD be the assigned
+BIP number, eg "BIP434", or be based on the BIP number (eg, "BIP434v2"
+where the "v2" suffix covers versioning, or "BIP434.3" where the ".3"
+suffix covers part 3 of the BIP). For experimental features that do not
+(yet) have a BIP number assigned, some other unique identifier MUST be
+chosen, such as a URL to the repository where development is taking
+place, or the sha256 digest of some longer reference.
 
 Nodes implementing this BIP MUST ignore `feature` messages specifying a
 `featureid` they do not support, so long as the payload conforms to the
@@ -147,15 +157,6 @@ messages where the `feature` message's payload cannot be correctly
 parsed (including having missing or additional data), even if they do
 not recognise the `featureid`.
 
-The `featureid` MUST be a globally unique identifier for the feature.
-For features published as a BIP, the `featureid` SHOULD be the assigned
-BIP number, eg "BIP434", or be based on the BIP number (eg, "BIP434v2"
-where the "v2" suffix covers versioning, or "BIP434.3" where the ".3"
-suffix covers part 3 of the BIP). For experimental features that do not
-(yet) have a BIP number assigned, some other unique identifier MUST be
-chosen, such as a URL to the repository where development is taking place,
-or the sha256 digest of some longer reference.
-
 #### `feature` message 1-byte identifier
 
 Nodes implementing both this BIP and [BIP 324 (v2 P2P encrypted
@@ -269,7 +270,8 @@ pairs). It was chosen because:
 
 A mild disadvantage compared to using a `verack` payload is that this
 approach allows the possibility of interactive feature negotiation prior
-to `verack`. However interactive feature negotiation is always possible
+to `verack`, which would make negotiation more complex and increase
+latency. However interactive feature negotiation is always possible
 simply by having the initiating peer disconnect and reconnect after
 discovering the listening peer's supported features.
 
@@ -304,6 +306,16 @@ negotiation][suhas-draft].
 
 This BIP is licensed under the 2-clause BSD license.
 
+[^feature-id-min]: The minimum `featureid` length of 4 characters
+corresponds with a "BIPx" string for BIPs in the range 1-9. Longer
+identifiers than this will almost always be needed in order to meet the
+"globally unique" requirement.
+
+[^feature-payload-max]: The maximum values for the `featureid` and
+`featuredata` lengths serve only to bound the volume of the feature
+message payload, particularly as this data will be automatically
+advertised even to peers that do not support the features in question.
+
 [BIP130]: https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki
 [BIP133]: https://github.com/bitcoin/bips/blob/master/bip-0133.mediawiki
 [BIP152]: https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki