Make link title more specific #1652

1. 
   OrfeasLitos commented at 10:06 am on July 24, 2024: contributor
2. in bip-0143.mediawiki:34 in 01f7de3267 outdated

   30@@ -31,7 +31,7 @@ A new transaction digest algorithm is defined, but only applicable to sigops in
   31      1. nVersion of the transaction (4-byte little endian)
   32      2. hashPrevouts (32-byte hash)
   33      3. hashSequence (32-byte hash)
   34-     4. outpoint (32-byte hash + 4-byte little endian) 
   35+     4. outpoint (32-byte hash + 4-byte little endian)
   

   ---

   ---

   

   jonatack commented at 6:53 pm on July 24, 2024:

   BIP 143 is final, and there are many other extra EOL spaces in the same document, like in line 621. Suggest dropping this commit.

   ---

   

   OrfeasLitos commented at 10:32 am on July 25, 2024:

   What’s the rule regarding edits to final BIPs? If it allows fixing typos, I suggest trimming all trailing whitespace instead.

   ---

   

   jonatack commented at 2:13 pm on July 25, 2024:

   That would probably be fine; perhaps propose that larger change as a separate PR? The changes to BIPs 143 and 341 here are unrelated.
3. in bip-0341.mediawiki:44 in 01f7de3267 outdated

   40@@ -41,7 +41,7 @@ As a result we choose this combination of technologies:
   41 * '''Taproot''' on top of that lets us merge the traditionally separate pay-to-pubkey and pay-to-scripthash policies, making all outputs spendable by either a key or (optionally) a script, and indistinguishable from each other. As long as the key-based spending path is used for spending, it is not revealed whether a script path was permitted as well, resulting in space savings and an increase in scripting privacy at spending time.
   42 * Taproot's advantages become apparent under the assumption that most applications involve outputs that could be spent by all parties agreeing. That's where '''Schnorr''' signatures come in, as they permit [https://eprint.iacr.org/2018/068 key aggregation]: a public key can be constructed from multiple participant public keys, and which requires cooperation between all participants to sign for. Such multi-party public keys and signatures are indistinguishable from their single-party equivalents. This means that with taproot most applications can use the key-based spending path, which is both efficient and private. This can be generalized to arbitrary M-of-N policies, as Schnorr signatures support threshold signing, at the cost of more complex setup protocols.
   43 * As Schnorr signatures also permit '''batch validation''', allowing multiple signatures to be validated together more efficiently than validating each one independently, we make sure all parts of the design are compatible with this.
   44-* Where unused bits appear as a result of the above changes, they are reserved for mechanisms for '''future extensions'''. As a result, every script in the Merkle tree has an associated version such that new script versions can be introduced with a soft fork while remaining compatible with BIP 341. Additionally, future soft forks can make use of the currently unused <code>annex</code> in the witness (see [[bip-0341.mediawiki#Rationale|BIP341]]).
   45+* Where unused bits appear as a result of the above changes, they are reserved for mechanisms for '''future extensions'''. As a result, every script in the Merkle tree has an associated version such that new script versions can be introduced with a soft fork while remaining compatible with BIP 341. Additionally, future soft forks can make use of the currently unused <code>annex</code> in the witness (see [[bip-0341.mediawiki#Rationale|Rationale]]).
   

   ---

   ---

   

   jonatack commented at 6:54 pm on July 24, 2024:

   nit, while touching this link

   0* Where unused bits appear as a result of the above changes, they are reserved for mechanisms for '''future extensions'''. As a result, every script in the Merkle tree has an associated version such that new script versions can be introduced with a soft fork while remaining compatible with BIP 341. Additionally, future soft forks can make use of the currently unused <code>annex</code> in the witness (see [[bip-0341.mediawiki#rationale|Rationale]]).
   

4. OrfeasLitos force-pushed on Jul 25, 2024
5. Replace "BIP341" with more specific "Rationale" 6dda74e5d1
6. Use lowercase in link 11f3d60a04
7. OrfeasLitos force-pushed on Jul 25, 2024
8. OrfeasLitos renamed this:
   Fix whitespace typo and make link title more specific
   Make link title more specific
   on Jul 25, 2024
9. 
   OrfeasLitos commented at 3:37 pm on July 25, 2024: contributor

   I kept only the link clarification in this PR and opened #1653 which removes all trailing whitespace from all BIPs.
10. 
    jonatack commented at 6:49 pm on July 25, 2024: contributor

    ACK – link text is clearer, and verified the rationale section that it links to contains the relevant information.
11. jonatack merged this on Jul 25, 2024
12. jonatack closed this on Jul 25, 2024

    ---

Contributors
OrfeasLitos jonatack