People: add people from latest newsletter

kouloumos · kouloumos · commit 6fe43026f72e · 2023-05-25T10:56:45.000+03:00
showcase the feature based on the names mentioned in the latest newsletter
diff --git a/_people/en/ZmnSCPxj.md b/_people/en/ZmnSCPxj.md
@@ -0,0 +1,3 @@
+---
+title: ZmnSCPxj
+---
diff --git a/_people/en/bastien-teinturier.md b/_people/en/bastien-teinturier.md
@@ -0,0 +1,3 @@
+---
+title: Bastien Teinturier
+---
diff --git a/_people/en/carla-kirk-cohen.md b/_people/en/carla-kirk-cohen.md
@@ -0,0 +1,3 @@
+---
+title: Carla Kirk-Cohen
+---
diff --git a/_people/en/clara-shikhelman.md b/_people/en/clara-shikhelman.md
@@ -0,0 +1,3 @@
+---
+title: Clara Shikhelman
+---
diff --git a/_people/en/dan-gould.md b/_people/en/dan-gould.md
@@ -0,0 +1,3 @@
+---
+title: Dan Gould
+---
diff --git a/_posts/en/newsletters/2018-08-07-newsletter.md b/_posts/en/newsletters/2018-08-07-newsletter.md
@@ -49,7 +49,7 @@ Bitcoin Core, LND, and C-Lightning projects.
   order for the in-channel payment transaction to be valid.  Everything
   else in the arbitrary contract as well as the LN payment can stay the
   same, with some specific exceptions discussed in this thread started
-  by knowledgeable pseudonymous researcher ZmnSCPxj.
+  by knowledgeable pseudonymous researcher [[ZmnSCPxj]].
 
 - **Library announced for BLS signatures:** well-known developer Bram
   Cohen [announced][bls announce] a "first draft (but fully functional)
diff --git a/_posts/en/newsletters/2019-01-08-newsletter.md b/_posts/en/newsletters/2019-01-08-newsletter.md
@@ -44,7 +44,7 @@ Bitcoin infrastructure projects are also provided.
     it in future Script versions, you should comment on the thread.
 
 - **Cross-chain LN as an options contract:** pseudonymous LN
-  contributor ZmnSCPxj started a thread on the Lightning-Dev mailing
+  contributor [[ZmnSCPxj]] started a thread on the Lightning-Dev mailing
   list pointing out that users could abuse payments that cross
   currencies to create almost free [short-term options contracts][] by
   delaying payment settlement.  A [previous thread][cjp risk] by Corné
diff --git a/_posts/en/newsletters/2019-07-10-newsletter.md b/_posts/en/newsletters/2019-07-10-newsletter.md
@@ -40,7 +40,7 @@ notable code changes in popular Bitcoin infrastructure projects.
   attackers could exploit.
 
     In a new [post][zmn jit] to the Lightning-Dev mailing list,
-    pseudonymous LN developer ZmnSCPxj describes two situations in which
+    pseudonymous LN developer [[ZmnSCPxj]] describes two situations in which
     other profit-maximizing nodes might allow free rebalances.  The
     first case is the observation that the next hop in the route
     will receive its own routing fee paid
diff --git a/_posts/en/newsletters/2019-07-24-newsletter.md b/_posts/en/newsletters/2019-07-24-newsletter.md
@@ -48,7 +48,7 @@ projects.
 
 - **Additional Just-In-Time (JIT) LN routing discussion:** in the JIT
   discussion described in the [newsletter][Newsletter #54] two weeks ago,
-  contributor ZmnSCPxj explained why routing nodes needed zero-fee
+  contributor [[ZmnSCPxj]] explained why routing nodes needed zero-fee
   rebalance operations in many cases for JIT routing to be incentive
   compatible.  This week he [posted][jit with fee] a suggestion to the C-Lightning
   mailing list on how nodes could be less incentive compatible but still
diff --git a/_posts/en/newsletters/2019-08-07-newsletter.md b/_posts/en/newsletters/2019-08-07-newsletter.md
@@ -50,7 +50,7 @@ developments.
       proposed.  Mailing list discussion seems to favor using the same
       CompactSize unsigned integers used in the Bitcoin protocol.
 
-- **Trampoline payments:** Bastien Teinturier opened a [PR][trampoline
+- **Trampoline payments:** [[Bastien Teinturier]] opened a [PR][trampoline
   pr] in the BOLTs repository and started a [discussion][trampoline
   discussion] on the Lightning-Dev mailing list about adding support to
   the protocol for the trampoline payments described in [Newsletter
diff --git a/_posts/en/newsletters/2019-09-18-newsletter.md b/_posts/en/newsletters/2019-09-18-newsletter.md
@@ -105,7 +105,7 @@ both novel and interesting:
     payment amounts, and sharding in both the form of federated block
     chains (available now) and other models that are more speculative.
 
-- [Lightning network topology][kc topology] by Carla Kirk-Cohen
+- [Lightning network topology][kc topology] by [[Carla Kirk-Cohen]]
   describes the public topology of channels between LN nodes at present,
   what factors influenced that shape, and what we might be able to do to
   reshape it.  She starts by noting the existence of private channels
diff --git a/_posts/en/newsletters/2019-10-09-newsletter.md b/_posts/en/newsletters/2019-10-09-newsletter.md
@@ -44,7 +44,7 @@ changes to popular Bitcoin infrastructure projects.
   tagging?  (Respondents seemed opposed, some strongly.)
 
     In response to the question about output tagging, C-Lightning
-    contributor ZmnSCPxj [proposed][zmn internal tagging] an alternative
+    contributor [[ZmnSCPxj]] [proposed][zmn internal tagging] an alternative
     tagging mechanism that would put the tag inside the taproot
     commitment, making it invisible unless a script-path spend was used.
     This could allow a spender who was worried about noinput to ensure
diff --git a/_posts/en/newsletters/2019-10-16-newsletter.md b/_posts/en/newsletters/2019-10-16-newsletter.md
@@ -86,7 +86,7 @@ notable changes to popular Bitcoin infrastructure projects.
     | $100   |  0.02c      |  5.05c      |
     | $1000  |  0.11c      |  50.05c     |
 
-    Fellow C-Lightning maintainer ZmnSCPxj and Eclair maintainer
+    Fellow C-Lightning maintainer [[ZmnSCPxj]] and Eclair maintainer
     Pierre-Marie Padiou indicated support for the proposal.  LND
     maintainer Olaoluwa Osuntokun believed the reasoning behind the
     proposal had several flaws and advocated instead to "educate
diff --git a/_posts/en/newsletters/2019-12-04-newsletter.md b/_posts/en/newsletters/2019-12-04-newsletter.md
@@ -53,7 +53,7 @@ infrastructure projects.
     tapscript.
 
     {:#composable-musig}
-    In a separate schnorr-related topic, ZmnSCPxj wrote a [post][zmn
+    In a separate schnorr-related topic, [[ZmnSCPxj]] wrote a [post][zmn
     composable musig] about the challenges of safely using the [MuSig][]
     signature aggregation protocol with sub-groups.  For example,
     ZmnSCPxj's [nodelets proposal][] suggests Alice and Bob
diff --git a/_posts/en/newsletters/2019-12-18-newsletter.md b/_posts/en/newsletters/2019-12-18-newsletter.md
@@ -125,7 +125,7 @@ Stack Exchange questions and answers.
   it does expire.
 
     Both Riard's post and replies from [Matt Corallo][corallo eclipse]
-    and [ZmnSCPxj][zmn eclipse] discuss past and present work to make
+    and [[[ZmnSCPxj]]][zmn eclipse] discuss past and present work to make
     full nodes and lightweight clients more resistant to eclipse
     attacks.  Readers interested in learning more about eclipse attacks
     and their mitigations are also strongly encouraged to read the Bitcoin
diff --git a/_posts/en/newsletters/2020-01-08-newsletter.md b/_posts/en/newsletters/2020-01-08-newsletter.md
@@ -35,7 +35,7 @@ projects.
   presentation he gave summarizing progress, including text indicating
   he thought the proposal was "nearly ready".  Wuille also proposed a
   [minor change][wuille suggestion] to the tapleaf versioning.  Also
-  briefly mentioned was the [discussion][zmn post] started by ZmnSCPxj
+  briefly mentioned was the [discussion][zmn post] started by [[ZmnSCPxj]]
   on the Lightning-Dev mailing list about how precisely taproot could be
   integrated with LN to provide improved privacy and scalability.
 
diff --git a/_posts/en/newsletters/2020-01-22-newsletter.md b/_posts/en/newsletters/2020-01-22-newsletter.md
@@ -28,7 +28,7 @@ infrastructure projects.
   *Wormhole*, a method developed during a [Wasabi design discussion][]
   for sending payments as part of a chaumian coinjoin.  The protocol
   prevents even the spender from learning the receiver's Bitcoin address
-  (within the limits of the anonymity set).  Developer ZmnSCPxj
+  (within the limits of the anonymity set).  Developer [[ZmnSCPxj]]
   [notes][zmn note] that the technique is similar to [tumblebit][], which
   provides a trustless chaumian payment service.  Hillebrand is
   requesting feedback on the design in the hopes of seeing it
diff --git a/_posts/en/newsletters/2020-01-29-newsletter.md b/_posts/en/newsletters/2020-01-29-newsletter.md
@@ -36,8 +36,8 @@ projects.
 
 ## News
 
-- **Breaking the link between UTXOs and unannounced channels:** Bastien
-  Teinturier [posted][teinturier post] to the Lightning-Dev mailing list about changing
+- **Breaking the link between UTXOs and unannounced channels:**
+  [[Bastien Teinturier]] [posted][teinturier post] to the Lightning-Dev mailing list about changing
   what data is added to a [BOLT11][] invoice for payments sent to
   unannounced channels---channels that aren't advertised to the LN
   network and which usually don't route payments for other users.  The
diff --git a/_posts/en/newsletters/2020-02-19-newsletter.md b/_posts/en/newsletters/2020-02-19-newsletter.md
@@ -165,8 +165,8 @@ popular services, client software, and infrastructure projects.
     JoinMarket's use of PoDLE and suggested how LN developers might want
     to use different tradeoffs for LN's own unique constraints.
 
-- **Decoy nodes and lightweight rendez-vous routing:** Bastien
-  Teinturier previously [posted][teinturier delink] about breaking the
+- **Decoy nodes and lightweight rendez-vous routing:**
+  [[Bastien Teinturier]] previously [posted][teinturier delink] about breaking the
   link between what data is included in a [BOLT11][] invoice and the
   funding transaction of the channel that will receive the payment (see
   [Newsletter #82][news82 unannounced]).  After further discussion and
diff --git a/_posts/en/newsletters/2020-02-26-newsletter.md b/_posts/en/newsletters/2020-02-26-newsletter.md
@@ -56,7 +56,7 @@ been moved to its own [section][release rc section].*
   that might be easier to build upon (such as for the *offers* idea
   described in [Newsletter #72][news72 offers]).  Russell's proposal
   originally specified using the same there-and-back onion routing used
-  for LN payments (HTLCs), but developer ZmnSCPxj [proposed][zmn circular] having the
+  for LN payments (HTLCs), but developer [[ZmnSCPxj]] [proposed][zmn circular] having the
   message sender specify the full path from their node to the message
   recipient and back to the sender.  For example, if Alice wants to
   communicate with Carol, she might choose the following path:
diff --git a/_posts/en/newsletters/2020-05-27-newsletter.md b/_posts/en/newsletters/2020-05-27-newsletter.md
@@ -42,7 +42,7 @@ Voegtlin agrees) -->
 
     After describing the motivation for the current relay rule, Sanders
     [asks][sanders 64] whether the rule can be simplified to only forbid
-    transactions whose stripped size is exactly 64 bytes.  ZmnSCPxj
+    transactions whose stripped size is exactly 64 bytes.  [[ZmnSCPxj]]
     [replies][zmn padding] that anything under 64 bytes could still be
     vulnerable, but that the 65-bytes-or-greater rule seems fine.
 
diff --git a/_posts/en/newsletters/2020-06-24-newsletter.md b/_posts/en/newsletters/2020-06-24-newsletter.md
@@ -68,7 +68,7 @@ week, and notable changes to popular Bitcoin infrastructure projects.
     ideas are mentioned, but Pickhardt asks readers to contemplate the
     problem and suggest any other possible solutions.
 
-- **Continued discussion about LN atomicity attack:** Bastien Teinturier
+- **Continued discussion about LN atomicity attack:** [[Bastien Teinturier]]
   [posted][teinturier post] to the Lightning-Dev mailing list with a
   link to a [detailed description][teinturier gist] of the LN commitment
   protocol, its weaknesses, and proposals to address those weaknesses.
diff --git a/_posts/en/newsletters/2020-07-01-newsletter.md b/_posts/en/newsletters/2020-07-01-newsletter.md
@@ -59,7 +59,7 @@ infrastructure projects.
     MAD-HTLCs might have their own problems with theft when the
     bonded user's counterparty is a miner (e.g. Alice is a miner).
 
-    ZmnSCPxj [noted][zmnscpxj scorched earth] that a mechanism already
+    [[ZmnSCPxj]] [noted][zmnscpxj scorched earth] that a mechanism already
     exists to allow Alice to discourage Bob from attempting his
     theft: Alice can enact a [scorched earth][] policy where she spends
     all of her legitimate funds to fees in order to prevent Bob from
diff --git a/_posts/en/newsletters/2020-07-29-newsletter.md b/_posts/en/newsletters/2020-07-29-newsletter.md
@@ -35,13 +35,13 @@ projects.
   format going forward.
 
     All discussion participants seemed to support the basic idea.
-    Bastien Teinturier [suggested][teinturier simple] that
+    [[Bastien Teinturier]] [suggested][teinturier simple] that
     it would be simplest to only allow switching commitment formats when
     channels had no pending payments (HTLCs)---implying nodes would
     need to pause sending or relaying payments in a particular channel
     in order to upgrade it.
 
-    ZmnSCPxj [noted][zmnscpxj re-funding] that the same basic idea could
+    [[ZmnSCPxj]] [noted][zmnscpxj re-funding] that the same basic idea could
     be used to essentially update the funding transaction offchain, such
     as the case where [taproot][topic taproot]
     and [SIGHASH_ANYPREVOUT][topic sighash_anyprevout] are implemented,
diff --git a/_posts/en/newsletters/2020-08-12-newsletter.md b/_posts/en/newsletters/2020-08-12-newsletter.md
@@ -26,8 +26,8 @@ and notable changes to popular Bitcoin infrastructure projects.
   diagram of how its two [signature hash][] (sighash) types would be used
   within [eltoo][topic eltoo].  He also asked several questions about
   minimizing the number of network round trips needed to create eltoo
-  state updates.  These questions received [answers from
-  ZmnSCPxj][zmnscpxj reply] but also sparked a [second
+  state updates.  These questions [received answers][zmnscpxj reply] from
+  [[ZmnSCPxj]] but also sparked a [second
   discussion][corallo relay] about attacks against LN payment atomicity
   within the context of eltoo.
 
diff --git a/_posts/en/newsletters/2020-10-14-newsletter.md b/_posts/en/newsletters/2020-10-14-newsletter.md
@@ -42,7 +42,7 @@ changes to popular Bitcoin infrastructure software.
     [discussion][teinturier dynamic] about a proposed minor protocol
     change transformed into a conversation about upfront fees:
 
-    - *Incremental routing:* ZmnSCPxj [described][zmnscpxj tunneling]
+    - *Incremental routing:* [[ZmnSCPxj]] [described][zmnscpxj tunneling]
       a nested encrypted tunneling protocol where routes would be
       built incrementally, with the spender being able to pay each
       successive routing hop independently.  This would ensure routing
diff --git a/_posts/en/newsletters/2020-11-04-newsletter.md b/_posts/en/newsletters/2020-11-04-newsletter.md
@@ -20,7 +20,7 @@ are our regular sections with updates about various projects.
 
 - **Bi-directional upfront fees for LN:** continuing a previous
   Lightning-Dev mailing list thread about upfront fees (see [Newsletter
-  #120][news120 upfront]), Bastien Teinturier [posted][teinturier bidir]
+  #120][news120 upfront]), [[Bastien Teinturier]] [posted][teinturier bidir]
   a proposal to have both the party offering an [HTLC][topic htlc] and
   the party receiving it each pay fees to the other---although the
   receiving party receives a refund on their fees if the payment is
diff --git a/_posts/en/newsletters/2020-12-23-newsletter.md b/_posts/en/newsletters/2020-12-23-newsletter.md
@@ -539,7 +539,7 @@ disclosed later.  The notable vulnerabilities included:
   the spending user could bribe miners to release the secret data but
   not confirm the transaction containing it, allowing the timelock to
   expire so that the spender would get their money back but still learn
-  the secret.  Developer ZmnSCPxj reminded the researchers of a
+  the secret.  Developer [[ZmnSCPxj]] reminded the researchers of a
   well known mechanism that should prevent such problems, a mechanism he
   helped [implement][cl3870] in C-Lightning.  Although the idea
   works in theory, using it will cost users money, so research into
diff --git a/_posts/en/newsletters/2021-01-06-newsletter.md b/_posts/en/newsletters/2021-01-06-newsletter.md
@@ -28,7 +28,7 @@ infrastructure software.
   the wallet can return "inconclusive" and maybe direct the user to a
   more comprehensive verification tool.
 
-- **Trampoline routing:** Bastien Teinturier [posted][teinturier post]
+- **Trampoline routing:** [[Bastien Teinturier]] [posted][teinturier post]
   to the Lightning-Dev mailing list a new [specification][tramp spec]
   for [trampoline routing][topic trampoline payments] that allows a
   spender to pay a receiver without calculating a route between their
diff --git a/_posts/en/newsletters/2021-02-17-newsletter.md b/_posts/en/newsletters/2021-02-17-newsletter.md
@@ -104,7 +104,7 @@ software.
   Lightning-Dev mailing over a year ago about creating non-custodial
   onchain escrows for LN saw [renewed discussion][aragoneses escrow]
   this past week.  A particular standout in the discussion was a
-  [post][zmn escrow2] by ZmnSCPxj that uses one of [De Morgan's laws][]
+  [post][zmn escrow2] by [[ZmnSCPxj]] that uses one of [De Morgan's laws][]
   for boolean statements to greatly simplify the construction of
   escrows---and [possibly][kohen escrow] many other LN-based
   contracts---with the tradeoff of requiring a seller to post a bond
@@ -265,7 +265,7 @@ BOLTs][bolts repo].*
   [proposed specification update][bolts #834] introduces the warning
   message type that can allow for a more flexible response.  Anyone
   interested may also wish to read a [post][kirk-cohen post] to the
-  Lightning-Dev mailing list this week by Carla Kirk-Cohen about
+  Lightning-Dev mailing list this week by [[Carla Kirk-Cohen]] about
   extended error message descriptions, a topic she described as
   "related, but not directly relevant to a soft warning error."
 
diff --git a/_posts/en/newsletters/2021-06-02-newsletter.md b/_posts/en/newsletters/2021-06-02-newsletter.md
@@ -18,7 +18,7 @@ Bitcoin infrastructure software.
 
 - **Candidate Set Based (CSB) block template construction:** Mark
   Erhardt [posted][erhardt post] to the Bitcoin-Dev mailing list about
-  an [analysis][es analysis] he and Clara Shikhelman performed on an
+  an [analysis][es analysis] he and [[Clara Shikhelman]] performed on an
   alternative transaction selection algorithm for miners.  Bitcoin's
   consensus rules enforce that no transaction can be included in a block
   unless all of its unconfirmed ancestors are also included earlier in
diff --git a/_posts/en/newsletters/2021-06-09-newsletter.md b/_posts/en/newsletters/2021-06-09-newsletter.md
@@ -17,7 +17,7 @@ infrastructure software.
 ## News
 
 - **Receiving LN payments with a mostly offline private key:** in 2019,
-  developer ZmnSCPxj [proposed][zmn ff] an alternative way to
+  developer [[ZmnSCPxj]] [proposed][zmn ff] an alternative way to
   encapsulate pending LN payments ([HTLCs][topic htlc]) that would
   reduce the amount of network bandwidth and latency required to accept
   a payment.  More recently, Lloyd Fournier suggested the idea could
diff --git a/_posts/en/newsletters/2021-10-13-newsletter.md b/_posts/en/newsletters/2021-10-13-newsletter.md
@@ -69,7 +69,7 @@ software.
       underlying links between LN nodes.  Refunding a payment in case of
       failure would be slower, but not slower than before this change.
       This feature is an extension of ideas previously proposed by
-      developer ZmnSCPxj (see [Newsletter #152][news152 ff]), who also
+      developer [[ZmnSCPxj]] (see [Newsletter #152][news152 ff]), who also
       [wrote][zmnscpxj name drop] a related post this week based on some
       of his out of band discussions with Towns.
 
@@ -89,7 +89,7 @@ software.
     - **Receiving payments with an offline key:** an online (hot) key is
       fundamentally required to send or route a payment in LN, but the
       current protocol also requires an online key in order to receive a
-      payment.  Based on an adaptation of ZmnSCPxj's previously
+      payment.  Based on an adaptation of [[ZmnSCPxj]]'s previously
       mentioned idea by Lloyd Fournier (also covered in [Newsletter
       #152][news152 ff]), it would be possible for a receiving node to
       only need to bring its keys online in order to open a channel,
diff --git a/_posts/en/newsletters/2021-10-20-newsletter.md b/_posts/en/newsletters/2021-10-20-newsletter.md
@@ -29,7 +29,7 @@ infrastructure software.
   that could be deployed even before PTLC support is added.
 
 - **Lowering the cost of probing to make attacks more expensive:** a few weeks apart, developers
-  ZmnSCPxj and Joost Jager each made [substantially][zmn prop] similar
+  [[ZmnSCPxj]] and Joost Jager each made [substantially][zmn prop] similar
   [proposals][jager prop] for eliminating the requirement to lock up
   capital in order to probe a payment path.  Both proposals suggest this
   as a first step towards adding upfront routing fees to the
diff --git a/_posts/en/newsletters/2021-11-03-newsletter.md b/_posts/en/newsletters/2021-11-03-newsletter.md
@@ -63,7 +63,7 @@ to popular Bitcoin infrastructure projects.
     - **Miner anonymity:** with 50,000 or more nodes currently all
       relaying transactions, it's easy for miners to receive all the
       information they need by quietly operating one of those nodes.
-      Pseudonymous developer ZmnSCPxj [suggested][zmnscpxj relay] that
+      Pseudonymous developer [[ZmnSCPxj]] [suggested][zmnscpxj relay] that
       forcing miners to maintain a persistent identity, even one on an
       anonymity network like Tor, would make it easier to
       identify miners and coerce them into censoring some transactions.
diff --git a/_posts/en/newsletters/2021-12-15-newsletter.md b/_posts/en/newsletters/2021-12-15-newsletter.md
@@ -38,7 +38,7 @@ notable changes to popular Bitcoin infrastructure software.
     No clear conclusion was reached in the discussion as of this
     writing.
 
-- **Preparing LN for PTLCs:** Bastien Teinturier started a
+- **Preparing LN for PTLCs:** [[Bastien Teinturier]] started a
   [thread][teinturier post] on the Lightning-Dev mailing list about
   making the minimal [set of changes][ln docs 16] to the LN
   communication protocol necessary to allow nodes to begin upgrading to
diff --git a/_posts/en/newsletters/2022-01-12-newsletter.md b/_posts/en/newsletters/2022-01-12-newsletter.md
@@ -165,7 +165,7 @@ repo], [Hardware Wallet Interface (HWI)][hwi repo],
   unnecessary channel closure. This is the first step toward more
   standardized and enriched errors. More discussion can be found at
   [BOLTs #834][] and in
-  [Carla Kirk-Cohen's post][Error Codes for LN] to the Lightning-dev
+  [[Carla Kirk-Cohen]]'s [post][Error Codes for LN] to the Lightning-dev
   mailing list (see [Newsletter #136][news136 warning post]).
 
 {% include references.md %}
diff --git a/_posts/en/newsletters/2022-03-02-newsletter.md b/_posts/en/newsletters/2022-03-02-newsletter.md
@@ -15,7 +15,7 @@ software.
 ## News
 
 - **Proposed opcode to simplify shared UTXO ownership:** developer
-  ZmnSCPxj [posted][zmnscpxj op_evict] to the Bitcoin-Dev mailing list a
+  [[ZmnSCPxj]] [posted][zmnscpxj op_evict] to the Bitcoin-Dev mailing list a
   proposal for an `OP_EVICT` opcode as an alternative to the
   [previously proposed][news166 tluv] `OP_TAPLEAF_UPDATE_VERIFY` (TLUV)
   opcode.  Like TLUV, `OP_EVICT` is focused on use cases where more than
diff --git a/_posts/en/newsletters/2022-03-09-newsletter.md b/_posts/en/newsletters/2022-03-09-newsletter.md
@@ -66,7 +66,7 @@ of notable changes to popular Bitcoin infrastructure projects.
       DoS vectors as well as result in programmers creating unoptimized
       scripts that use more node resources than necessary.
 
-    - *Introduction of turing completeness:* developer ZmnSCPxj
+    - *Introduction of turing completeness:* developer [[ZmnSCPxj]]
       [criticized][zmn turing] the addition of opcodes that allow the
       creation of *deliberate* recursive covenants as also allowing the
       *accidental* creation of recursive covenants.  Money paid into
diff --git a/_posts/en/newsletters/2022-03-16-newsletter.md b/_posts/en/newsletters/2022-03-16-newsletter.md
diff --git a/_posts/en/newsletters/2022-05-04-newsletter.md b/_posts/en/newsletters/2022-05-04-newsletter.md
diff --git a/_posts/en/newsletters/2022-05-18-newsletter.md b/_posts/en/newsletters/2022-05-18-newsletter.md
diff --git a/_posts/en/newsletters/2022-05-25-newsletter.md b/_posts/en/newsletters/2022-05-25-newsletter.md
diff --git a/_posts/en/newsletters/2022-06-15-newsletter.md b/_posts/en/newsletters/2022-06-15-newsletter.md
diff --git a/_posts/en/newsletters/2022-06-22-newsletter.md b/_posts/en/newsletters/2022-06-22-newsletter.md
diff --git a/_posts/en/newsletters/2022-07-06-newsletter.md b/_posts/en/newsletters/2022-07-06-newsletter.md
diff --git a/_posts/en/newsletters/2022-07-20-newsletter.md b/_posts/en/newsletters/2022-07-20-newsletter.md
diff --git a/_posts/en/newsletters/2022-09-28-newsletter.md b/_posts/en/newsletters/2022-09-28-newsletter.md
diff --git a/_posts/en/newsletters/2022-10-05-newsletter.md b/_posts/en/newsletters/2022-10-05-newsletter.md
diff --git a/_posts/en/newsletters/2022-11-02-newsletter.md b/_posts/en/newsletters/2022-11-02-newsletter.md
diff --git a/_posts/en/newsletters/2022-11-16-newsletter.md b/_posts/en/newsletters/2022-11-16-newsletter.md
diff --git a/_posts/en/newsletters/2022-11-30-newsletter.md b/_posts/en/newsletters/2022-11-30-newsletter.md
diff --git a/_posts/en/newsletters/2023-01-11-newsletter.md b/_posts/en/newsletters/2023-01-11-newsletter.md
diff --git a/_posts/en/newsletters/2023-02-01-newsletter.md b/_posts/en/newsletters/2023-02-01-newsletter.md
diff --git a/_posts/en/newsletters/2023-02-08-newsletter.md b/_posts/en/newsletters/2023-02-08-newsletter.md
diff --git a/_posts/en/newsletters/2023-02-22-newsletter.md b/_posts/en/newsletters/2023-02-22-newsletter.md
diff --git a/_posts/en/newsletters/2023-04-12-newsletter.md b/_posts/en/newsletters/2023-04-12-newsletter.md
diff --git a/_posts/en/newsletters/2023-05-17-newsletter.md b/_posts/en/newsletters/2023-05-17-newsletter.md

Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+---`
	`2`	`+title: Bastien Teinturier`
	`3`	`+---`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+---`
	`2`	`+title: Carla Kirk-Cohen`
	`3`	`+---`
Original file line number	Diff line number	Diff line change
`@@ -0,0 +1,3 @@`
	`1`	`+---`
	`2`	`+title: Clara Shikhelman`
	`3`	`+---`