f

Author: instagibbs

bip-paytoanchor.mediawiki

@@ -27,7 +27,7 @@ When the wallet user is unconcerned by *who* is able to bump the transaction fee
 1. Using an output type with minimal output and spending input footprint saves fees on average
 2. Keyless operation aids in interoperability of services like watchtowers as there is no privileged key material for bumping
 
-with the drawback that selection of this output type could result in griefing if anti-pinning measures are not taken. If unsure, use in conjunction with [bip-0431.mediawiki TRUC transactions].
+with the drawback that selection of this output type could result in griefing if anti-pinning measures are not taken. If unsure, use in conjunction with [https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC transactions].
 
 ===Specification===
 
@@ -51,7 +51,7 @@ There are a number of related but separate historical concepts:
 
 [https://bitcoinops.org/en/topics/ephemeral-anchors/ Ephemeral Anchors]: Historically the union of P2A output type and ephemeral dust. Keyed anchors along with ephemeral dust are also an accepted pattern and as such they remain separate concepts.
 
-[bip-0431.mediawiki TRUC transactions]: TRUC transactions bound the topology including child transaction size, which aids in anti-pinning for the P2A output, as anyone can attach a child transaction including an oversized, low feerate one. There is no ineherent dependency on this concept and P2A.
+[https://github.com/bitcoin/bips/blob/master/bip-0431.mediawiki TRUC transactions]: TRUC transactions bound the topology including child transaction size, which aids in anti-pinning for the P2A output, as anyone can attach a child transaction including an oversized, low feerate one. There is no ineherent dependency on this concept and P2A.
 
 ====Backward Compatibility====