diff --git a/_layouts/person.html b/_layouts/person.html
new file mode 100644
index 000000000..8180c4cd1
--- /dev/null
+++ b/_layouts/person.html
@@ -0,0 +1,95 @@
+---
+layout: post
+---
+{% capture newline %}
+{% endcapture %}
+{% capture /dev/null %}
+
+ {% assign people_list = site.people | natural_sort: "title" %}
+ {% capture first_link %}[{{people_list[0].title}}]({{people_list[0].url}}){% endcapture %}
+ {% capture last_link %}[{{people_list[-1].title}}]({{people_list[-1].url}}){% endcapture %}
+ {% for entry in people_list %}
+ {% capture entry_link %}[{{entry.title}}]({{entry.url}}){% endcapture %}
+ {% if prev_link %}
+ {% assign next_link = entry_link %}
+ {% break %}
+ {% endif %}
+ {% if entry.url == page.url %}
+ {% assign prev_link = prev_entry | default: last_link %}
+ {% endif %}
+ {% assign prev_entry = entry_link %}
+ {% endfor %}
+
+
+ {% for source in page.primary_sources %}
+ {%- if source.link contains 'http://' or source.link contains 'https://' -%}
+ {% capture reference %}[{{source.title}}]({{source.link}}){% endcapture %}
+ {%- else -%}
+ {% capture reference %}[{{source.title}}][{{source.link}}]{% endcapture %}
+ {%- endif -%}
+ {% capture primary_sources %}{{primary_sources}}{{newline}}- {{reference}}{% endcapture %}
+ {% endfor %}
+
+
+
+ {% for source in page.see_also %}
+ {%- if source.link contains 'http://' or source.link contains 'https://' -%}
+ {% capture reference %}[{{source.title}}]({{source.link}}){% endcapture %}
+ {%- else -%}
+ {% capture reference %}[{{source.title}}][{{source.link}}]{% endcapture %}
+ {%- endif -%}
+ {% capture see_also %}{{see_also}}{{newline}}- {{reference}}{% endcapture %}
+ {% endfor %}
+
+
+ {% capture gh_base %}https://github.com/{{site.github_username}}/{{site.repository_name}}{% endcapture %}
+
+{% endcapture %}
+
+
+{% capture content %}
+ {% include references.md %}
+ {{aliases}}
+
+ {{page.excerpt}}
+
+ {{page.content}}
+
+ {{notices | default: newline}}
+
+ {%- if page.podcast_mentions.size > 0 -%}
+ ## Optech podcast appearances
+
+ {%- for mention in page.podcast_mentions -%}
+ {{newline}}- [{{mention.title}}]({{mention.url}})
+ {%- endfor -%}
+ {% endif %}{{newline}}{{newline}}
+
+ {%- if page.optech_mentions and page.optech_mentions != '' -%}
+ ## Optech newsletter mentions
+
+ {% assign sorted_references = page.optech_mentions | sort_by_newsletter_number | reverse %}
+ {%- for reference in sorted_references -%}
+ {%- assign current_ref_year = reference.year -%}
+ {%- if current_ref_year != last_ref_year -%}
+ {{newline}}{{newline}}**{{current_ref_year}}**
+ {%- endif -%}
+ {{newline}}{% include optech-mention.html %}
+ {%- assign last_ref_year = current_ref_year -%}
+ {%- endfor -%}
+ {% endif %}{{newline}}{{newline}}
+
+ {%- if page.see_also and page.see_also != '' -%}
+ ## See also
+
+ {{see_also}}
+ {% endif %}
+
+ {{newline}}{{newline}}
+**Previous Person:** {{prev_link}}
+**Next Person:** {{next_link | default: first_link }}
+
+ {:.center}
+ [Edit page]({{gh_base}}/edit/master/{{page.path}})
+ [Report Issue]({{gh_base}}/issues/new?body={{'Source file: ' | append: page.path | url_escape }})
+{% endcapture %}{{ content | markdownify }}
diff --git a/_people/en/ZmnSCPxj.md b/_people/en/ZmnSCPxj.md
new file mode 100644
index 000000000..edb2a70e9
--- /dev/null
+++ 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
new file mode 100644
index 000000000..de19371f0
--- /dev/null
+++ 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
new file mode 100644
index 000000000..73be9abcb
--- /dev/null
+++ 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
new file mode 100644
index 000000000..39198e4c0
--- /dev/null
+++ 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
new file mode 100644
index 000000000..cd348770c
--- /dev/null
+++ b/_people/en/dan-gould.md
@@ -0,0 +1,3 @@
+---
+title: Dan Gould
+---
diff --git a/_people/en/larry-ruane.md b/_people/en/larry-ruane.md
new file mode 100644
index 000000000..e0660cd56
--- /dev/null
+++ b/_people/en/larry-ruane.md
@@ -0,0 +1,3 @@
+---
+title: Larry Ruane
+---
diff --git a/_plugins/auto-anchor.rb b/_plugins/auto-anchor.rb
index 9d51dc21c..2c078c1ab 100644
--- a/_plugins/auto-anchor.rb
+++ b/_plugins/auto-anchor.rb
@@ -7,6 +7,11 @@
# - [Summary][]: Details
# - [Summary](URL): Details
+def generate_anchor_list_link(anchor_link)
+ # custom clickable bullet linking to an anchor
+ "●"
+end
+
def auto_anchor(content)
content.gsub!(/^ *- .*/) do |string|
## Find shortest match for **bold**, *italics*, or [markdown][links]
@@ -17,7 +22,7 @@ def auto_anchor(content)
string
else
slug = generate_slug(title)
- id_prefix = "- {:#{slug} .anchor-list} ●"
+ id_prefix = "- {:#{slug} .anchor-list} #{generate_anchor_list_link(slug)}"
string.sub!(/-/, id_prefix)
end
end
@@ -49,3 +54,19 @@ def render(context)
Liquid::Template.register_tag('auto_anchor', Jekyll::RenderAutoAnchor)
+module TextFilter
+ # This is a custom filter used in `optech-mentions.html`
+ # to add anchor links to each backlink snippet
+ def link_to_anchor(text, url)
+ id_prefix = generate_anchor_list_link(url)
+ if text.start_with?("-")
+ # snippet is already a list item
+ text.sub!(/-/, id_prefix)
+ else
+ text.prepend("#{id_prefix} ")
+ end
+ text
+ end
+end
+
+Liquid::Template.register_filter(TextFilter)
diff --git a/_plugins/bidirectional_links_generator.rb b/_plugins/bidirectional_links_generator.rb
new file mode 100644
index 000000000..003c52049
--- /dev/null
+++ b/_plugins/bidirectional_links_generator.rb
@@ -0,0 +1,332 @@
+# frozen_string_literal: true
+# This file is based on code from https://github.com/maximevaillancourt/digital-garden-jekyll-template
+# Generators run after Jekyll has made an inventory of the existing content,
+# and before the site is generated.
+
+# Newsletter mentions of a topic were historically manually added to each
+# topic's page under `optech_mentions`. This enchances the exisiting logic
+# by allowing for automatic mentions using the double-bracket link syntax.
+class BidirectionalLinksGenerator < Jekyll::Generator
+ def generate(site)
+ # This is only supported for english
+ lang = "en"
+ all_pages = site.documents.select { |doc| doc.url.start_with?("/#{lang}/") }
+ # pages that contain the double-bracket link syntax `[[]]` are only a subset
+ # of all the pages
+ pages_with_link_syntax = all_pages.select { |page| page.content.match(/\[\[.*?\]\]/) }
+ # indexed pages are the only pages that newsletters might mention
+ indexed_pages = site.collections["topics"].docs + site.collections["people"].docs
+
+ # Convert all Wiki/Roam-style double-bracket link syntax to plain HTML
+ # anchor tag elements ()
+ pages_with_link_syntax.each do |current_page|
+ indexed_pages.each do |page_potentially_linked_to|
+ page_title_regexp_pattern = Regexp.escape(
+ File.basename(
+ page_potentially_linked_to.basename,
+ File.extname(page_potentially_linked_to.basename)
+ )
+ ).gsub('\_', '[ _]').gsub('\-', '[ -]').capitalize
+
+ title_from_data = title_from_data_escaped = page_potentially_linked_to.data['title']
+ if title_from_data
+ title_from_data_escaped = Regexp.escape(title_from_data)
+ end
+
+ new_href = "#{site.baseurl}#{page_potentially_linked_to.url}"
+ title_anchor_tag = "#{title_from_data}"
+ anchor_tag = "\\1"
+
+
+ # Replace double-bracketed links that use topic's title with the given label
+ # [[coin selection|this is a link to coin selection]] => [this is a link to coin selection](/topics/coin-selection)
+ current_page.content.gsub!(
+ /\[\[#{page_title_regexp_pattern}\|(.+?)(?=\])\]\]/i,
+ anchor_tag
+ )
+
+ # Replace double-bracketed links that use topic's filename with the given label
+ # [[coin-seletion|this is a link to coin selection]] => [this is a link to coin selection](/topics/coin-selection)
+ current_page.content.gsub!(
+ /\[\[#{title_from_data_escaped}\|(.+?)(?=\])\]\]/i,
+ anchor_tag
+ )
+
+ # Replace double-bracketed links that use topic's title
+ # [[coin selection]] => [coin selection](/topics/coin-selection)
+ # [[Coin selection]] => [Coin selection](/topics/coin-selection)
+ current_page.content.gsub!(
+ /\[\[(#{title_from_data_escaped})\]\]/i,
+ anchor_tag
+ )
+
+ # Replace double-bracketed links that use topic's filename with topic's title
+ # [[bnb]] => [Branch and Bound (BnB)](/topics/bnb)
+ current_page.content.gsub!(
+ /\[\[(#{page_title_regexp_pattern})\]\]/i,
+ title_anchor_tag
+ )
+ end
+
+ # At this point, all remaining double-bracket-wrapped words are
+ # pointing to non-existing pages, so let's turn them into disabled
+ # links by greying them out and changing the cursor
+ current_page.content = current_page.content.gsub(
+ /\[\[([^\]]+)\]\]/i, # match on the remaining double-bracket links
+ <<~HTML.delete("\n") # replace with this HTML (\\1 is what was inside the brackets)
+
+ [[
+ \\1
+ ]]
+ HTML
+ )
+ end
+
+ # we need the topic links for manual substitutions of links later on
+ @topics_links = site.collections["topics"].map do |topic|
+ ["topic #{topic.data["shortname"] || topic.data["title"]}", topic.url]
+ end
+
+ # Newsletter mentions
+ # =====================
+ newsletter_pages = pages_with_link_syntax.select { |doc| doc.url.start_with?("/#{lang}/newsletters/") }
+ # Identify page backlinks and add them to each page
+ indexed_pages.each do |current_page|
+ target_page_href = "href='#{current_page.url}'"
+
+ # Iterate over all pages to find mentions of the current page
+ newsletter_pages.each do |page_in_question|
+ # Check if the current page is mentioned in the content of the page in question
+ if page_in_question.content.include?(target_page_href)
+ # The page_in_question mentions the current page, we now need to
+ # find the specific mentions.
+ mentions = get_mentions_of(page_in_question, target_page_href, current_page.collection.label)
+ current_page.data["optech_mentions"] ||= [] # Initialize if not already present
+ # Add the calculated mentions to `optech_mentions`
+ # Note: a page might mentioning another page more than once
+ mentions.each do |mention|
+ current_page.data["optech_mentions"] << mention
+ end
+ end
+ end
+ end
+
+ # Podcast appearances
+ # =====================
+ podcast_pages = pages_with_link_syntax.select { |doc| doc.url.start_with?("/#{lang}/podcast/") }.reverse
+ people_pages = site.collections["people"].docs
+
+ people_pages.each do |person|
+ podcast_mentions = []
+ # Iterate over podcast pages to find mentions of people
+ podcast_pages.each do |podcast|
+ podcast_intro = podcast.content.each_line.first.chomp
+ if podcast_intro.include?("href='#{person.url}'")
+ podcast_mentions << {"title"=> podcast.title, "url"=> podcast.url}
+ # the excerpt of pages is calculated by Jekyll before generators run
+ # therefore we need to override the excerpt to remove [[]]
+ podcast.excerpt.content = podcast_intro
+ end
+ end
+ person.data["podcast_mentions"] = podcast_mentions
+ end
+ end
+
+ def liquify(content, date)
+ context = Liquid::Context.new({}, {}, { site: Jekyll.sites.first })
+ context['page'] = { 'date' => date } # needed to identify deprecated_links
+ template = Liquid::Template.parse(content)
+ content_parsed = template.render(context)
+ end
+
+ def get_external_links(page)
+ # this assumes that a "{% include {references, linkers/issues}.md %}" line
+ # exists at the end of the documents and external links are declared after it
+
+ # get all the references after the {% include _ %} line
+ regex_for_first_include = /\{% include (?:references\.md|linkers\/issues\.md).*?%\}/
+ references = page.content.split(regex_for_first_include, 2).last.strip
+ references.prepend("{% include references.md %}\n")
+
+ # manually trigger the replacement of the {% include %} tags in order to
+ # have all the required links ([key]:url) needed for the matching snippets
+ references_parsed = liquify(references, page.date)
+
+ # Search for all occurrences of the pattern "[key]: url"
+ # and return them in an array
+ references_parsed.scan(/\[([^\]]+?)\]\s*:\s*(\S+)/i)
+ end
+
+ def find_title(string)
+ title = capture_group = ""
+ ## Find shortest match for **bold**, *italics*, or [markdown][links]
+ title_match = string.match($title_pattern)
+ title_match&.named_captures&.compact&.each do |key, value|
+ capture_group = key # one of {bold, italics, markdown_link}
+ title = value
+ end
+
+ if title.empty?
+ {}
+ else
+ {"title"=> title, "capture_group"=> capture_group}
+ end
+ end
+
+ def sanitize_title(title_hierarchy)
+ # This is needed because for this plugin's logic, we use the same
+ # matching pattern for the title as in `auto-anchor.rb` in order to be
+ # able to reproduce the slugs/anchors and therefore point to them.
+ # This pattern matches the title of the paragraph by finding the shortest
+ # match for **bold**, *italics*, or [markdown][links], but the matched
+ # **bold** or *italics* might have nested [markdown][links].
+ #
+ # Note that the nested [markdown][links] actually become part of the slug
+ # for example in /en/newsletter/2018-06-08/ the title
+ # "**[BIP174][BIP174] discussion and review ongoing:**" becomes
+ # "#bip174-bip174-discussion-and-review-ongoing"
+ #
+ # In the case of `auto-anchor.rb` this doesn't matter because the title
+ # will "markdownify" and transform into a link. But here, we extract the
+ # title therefore we need to remove the second part
+ #
+ # We call unsanitized title, a title that has those nested
+ # [markdown][links]. The logic here, finds the pattern "[text][text]"
+ # or "[text](text)" and remove the second part
+ title_hierarchy.each do |title|
+ title.gsub!(/\[(.*?)\][(\[].*?[)\]]/, '\1')
+ end
+ end
+
+ def extract_slug_from_manual_anchor(text)
+ # sometimes the liquid anchor syntax is used to create anchors in the document
+ # our extracted backlink snippets include those, therefore we need to
+ # - remove liquid anchor syntax from the result
+ # - extract slug to use it on the generated anchor list link
+ # example of this pattern can be seen in `en/newsletter/2019-06-12-newsletter.md`
+ match = text.match(/\{:#([\w-]+)\}/)
+ if match
+ slug = "##{match[1]}" # extract slug
+ text.sub!(/#{match[0]}/, "") # Remove the matched {:#slug} syntax
+ slug
+ else
+ nil
+ end
+ end
+
+ # This method searches the content for paragraphs that link to the
+ # the target page and returns these mentions
+ def get_mentions_of(page, target_page_url, collection)
+ # This is called only when we know that a match exists
+ # The logic here assumes that:
+ # - paragraphs have headers
+ # - each block of text (paragraph) is seperated by an empty line
+ # - primary titles are enclosed in **bold**
+ # - secondary (nested) titles are enclosed in *italics*
+
+ content = page.content
+ external_links = collection == "people" ?
+ get_external_links(page).reverse + @topics_links : [] # people-index specific
+
+ # Split the content into paragraphs
+ paragraphs = content.split(/\n\n+/)
+ # Find all the headers in the content
+ headers = content.scan(/^#+\s+(.*)$/).flatten
+
+ # Create an array of hashes containing:
+ # - the paragraph text
+ # - the associated header
+ # - the associated url
+ # - the associated title (when is not part of the paragraph)
+ matching_paragraphs = []
+ current_header = 0
+ current_title = []
+
+ # Iterate over all paragraphs to find those that match the given url
+ paragraphs.each do |p|
+ # a title might have multiple paragraphs associated with it
+ # an isolated paragraph snippet cannot access the title therefore
+ # we keep this information to be used in backlinks
+ title = find_title(p)
+ if !title.empty?
+ # paragraph has title
+ if title["capture_group"] == "bold" or title["capture_group"] == "markdown_link"
+ # when a new primary title is found, we reset the current_title array
+ current_title = [title["title"]]
+ elsif title["capture_group"] == "italics"
+ # title is a nested title, we assign it as the 2nd element of the array
+ # in order to keep the titles' hierarchy
+ # [**primary title**, *secondary title*]
+ current_title[1] = title["title"]
+ end
+ else
+ # paragraph has no title, switch back to the last primary title
+ # this covers the case when you have a nested secondary paragraph
+ # but the mention is in a later paragraph (still nested under primary)
+ # that has no title, therefore we need to default back to the last
+ # primary title, otherwise the title of the mention would also include
+ # the secondary title which might be irrelevant
+ current_title = [current_title[0]]
+ end
+
+ # If the current paragraph contains the URL, add it to the matching paragraphs
+ if p.include?(target_page_url)
+ if collection == "people"
+ # Loop through the array of [key]:url_replace matches and replace
+ # - the occurrences of "[key][]" with "[key](url_replace)"
+ # - the occurrences of "[something][key]" with "[something](url_replace)"
+ external_links.each do |match|
+ key_pattern = match[0].gsub(/\s/, '\s+') # to work with multiline keys
+ p.gsub!(/\[(#{key_pattern})\]\[\]/im, "[\\1](#{match[1]})")
+ p.gsub!(/\[(.+?)\]\[(#{key_pattern})\]/im, "[\\1](#{match[1]})")
+ end
+ # manually replace common liquid variables in paragraph
+ p.gsub!(/#{Regexp.escape("{{bse}}")}/,"https://bitcoin.stackexchange.com/a/")
+ end
+
+ # generate slug for matching paragraph
+ slug = extract_slug_from_manual_anchor(p)
+ if slug.nil?
+ # no manual anchor has been defined, so generate slug from title
+ slug = generate_slug(current_title.last)
+ # after generating the title-based slug we must sanitize the title,
+ # this must be done after generating the title-based slug because
+ # slugs are historically generated based on the unsanitize title
+ sanitize_title(current_title)
+ end
+ matching_paragraph = {
+ # resulting title for the mention is "primary title: secondary title"
+ "title"=> current_title.join(": "),
+ "url" => "#{page.url}#{slug}"
+ }
+ if collection == "people"
+ # People index has verbosed mentions
+ matching_paragraph.merge!({
+ "paragraph"=> p.lstrip,
+ "header"=> headers[current_header],
+ "newsletter_number" => page.title.sub("Bitcoin Optech Newsletter #", "").to_i,
+ "year" => File.basename(page.path)[0, 4]
+ })
+
+ if !title.empty?
+ # paragraph has title
+ # for the verbosed mentions we display the paragraph that contains
+ # the mention (see `optech-mentions.html`), therefore we do not
+ # need to repeat the title
+ current_title.pop # this way we keep the parent title
+ matching_paragraph["title"] = current_title[0]
+ end
+ end
+ matching_paragraphs << matching_paragraph
+ end
+
+ # update to the next header when parse through it
+ if p.sub(/^#+\s*/, "") == headers[(current_header + 1) % headers.length()]
+ current_header += 1
+ end
+ end
+
+ # Return the matching paragraphs
+ matching_paragraphs
+ end
+ end
diff --git a/_plugins/common_utils.rb b/_plugins/common_utils.rb
index 67adf0680..2a4d6291f 100644
--- a/_plugins/common_utils.rb
+++ b/_plugins/common_utils.rb
@@ -1,3 +1,10 @@
+# Regex pattern to match list items and capture their title which
+# is either in **bold**, *italics*, or [markdown][links]
+$bold = /\*\*(?.*?):?\*\*/
+$italics = /\*(?.*?):?\*/
+$markdown_link = /\[(?.*?):?\][(\[]/
+$title_pattern = /^ *- .*?(?:#{$bold}|#{$italics}|#{$markdown_link})/
+
def generate_slug(title)
## Remove double-quotes from titles before attempting to slugify
title.gsub!('"', '')
@@ -7,4 +14,15 @@ def generate_slug(title)
# An empty context is used here because we only need to parse the liquid
# string and don't require any additional variables or data.
slug.render(Liquid::Context.new)
-end
\ No newline at end of file
+end
+
+# this is a custom filter used in `person.html` to help with ordering
+module Jekyll
+ module OptechMentionsSortFilter
+ def sort_by_newsletter_number(array)
+ array.sort_by { |item| item['newsletter_number'] }
+ end
+ end
+end
+
+Liquid::Template.register_filter(Jekyll::OptechMentionsSortFilter)
\ No newline at end of file
diff --git a/_plugins/recap_references_generator.rb b/_plugins/recap_references_generator.rb
index a08f2b650..16f6d67ad 100644
--- a/_plugins/recap_references_generator.rb
+++ b/_plugins/recap_references_generator.rb
@@ -6,6 +6,7 @@
# Create the podcast recap references by parsing the referenced newsletter for
# podcast reference marks (timestamps)
class RecapReferencesGenerator < Jekyll::Generator
+ priority :high
def generate(site)
podcast_pages = site.documents.select { |doc| doc.data["type"] == "podcast"}
podcast_pages.each do |podcast|
diff --git a/_posts/en/newsletters/2018-08-07-newsletter.md b/_posts/en/newsletters/2018-08-07-newsletter.md
index 33555351b..977c8a85c 100644
--- 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
index 327870105..ce4115e98 100644
--- 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
index c27e6a787..f80046898 100644
--- 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
index 5ba29e650..f4ab9f6cd 100644
--- 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
index 5bc44081d..a8f026531 100644
--- 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
index 06ce60827..f9dd8edad 100644
--- 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
index 706a6d193..e834b4c5d 100644
--- 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
index 72f237ece..e0c9225b0 100644
--- 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
index 07a988bca..fd59d489a 100644
--- 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
index 6630348a9..3c693718e 100644
--- 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
index 850cfd293..cf20754da 100644
--- 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
index be48fbca1..728f2d0b1 100644
--- 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
index 37edcb28f..72ccf4dcc 100644
--- 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
index 0509b6e42..372210f46 100644
--- 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
index 97e1a8a50..e0702439e 100644
--- 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
index beab2e9f3..e74ed7c15 100644
--- 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
index ba2c9f49e..ea4aade75 100644
--- 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
index 6b39d141d..50df077b1 100644
--- 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
index 649d13dec..83515cc4c 100644
--- 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
index b12366bee..6cceb33a0 100644
--- 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
index ea75cf074..d0c2e935a 100644
--- 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
index 86e6a9f2b..3b800335a 100644
--- 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
index cf90175cb..3f2126d45 100644
--- 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
index 0e9ad9b88..1e6c96187 100644
--- 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
index 690307bc0..1d69bd3c4 100644
--- 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
index efcfee986..92ef9900e 100644
--- 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
index 57a44e9a6..d0ce879d4 100644
--- 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
index a0d9ca672..540cbf531 100644
--- 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
index 1a233d697..7eeef5f28 100644
--- 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
index db92d31ce..d802bcfa0 100644
--- 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
index c2ea34daf..6712a0b13 100644
--- 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
index dfd849227..ce9835e21 100644
--- 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
index e1547d567..f9c9f40d7 100644
--- 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
index b36bf64ae..8476324ca 100644
--- 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
index 439aa9e91..b5d323df4 100644
--- a/_posts/en/newsletters/2022-03-16-newsletter.md
+++ b/_posts/en/newsletters/2022-03-16-newsletter.md
@@ -21,7 +21,7 @@ to popular Bitcoin infrastructure projects.
those receiving bitcoins use to specify how they'll later prove they
authorized any spending of those bitcoins.
- - *Looping (folding):* developer ZmnSCPxj [described][zmnscpxj fold]
+ - *Looping (folding):* developer [[ZmnSCPxj]] [described][zmnscpxj fold]
a proposed `OP_FOLD` opcode as a way to allow loop-like behavior
in Bitcoin Script. He described a series of constraints that
could be placed on the looping to ensure they didn't use any more
diff --git a/_posts/en/newsletters/2022-03-30-newsletter.md b/_posts/en/newsletters/2022-03-30-newsletter.md
index d1bfd7c70..b13846b1b 100644
--- a/_posts/en/newsletters/2022-03-30-newsletter.md
+++ b/_posts/en/newsletters/2022-03-30-newsletter.md
@@ -17,7 +17,7 @@ projects.
## News
-- **Transaction witness replacement:** Larry Ruane [asked][ruane witrep]
+- **Transaction witness replacement:** [[Larry Ruane]] [asked][ruane witrep]
the Bitcoin-Dev mailing list for information and opinions about
allowing a transaction to be replaced by the same transaction with the
same txid but a smaller witness (and, thus, a different wtxid). Ruane
diff --git a/_posts/en/newsletters/2022-05-04-newsletter.md b/_posts/en/newsletters/2022-05-04-newsletter.md
index 602e5775a..e7ad201a4 100644
--- a/_posts/en/newsletters/2022-05-04-newsletter.md
+++ b/_posts/en/newsletters/2022-05-04-newsletter.md
@@ -74,7 +74,7 @@ infrastructure projects.
discussion participants when it came to informing their decisions about
changing Bitcoin's consensus rules.
-- **LN anchor outputs security issue:** Bastien Teinturier
+- **LN anchor outputs security issue:** [[Bastien Teinturier]]
[posted][teinturier security] to the Lightning-Dev mailing list the
announcement of a security issue he had previously responsibly
disclosed to LN implementation maintainers. The issue affected older
diff --git a/_posts/en/newsletters/2022-05-18-newsletter.md b/_posts/en/newsletters/2022-05-18-newsletter.md
index e4dbb4f56..60cdc5974 100644
--- a/_posts/en/newsletters/2022-05-18-newsletter.md
+++ b/_posts/en/newsletters/2022-05-18-newsletter.md
@@ -304,7 +304,7 @@ regular newsletter.
- **When would enabling `OP_CAT` allow recursive covenants?** in a
discussion on the Bitcoin-Dev mailing list about re-adding the
[OP_CAT][op_cat] opcode removed from Bitcoin in 2010, developer
- ZmnSCPxj [claimed][zmnscpxj cat1] `OP_CAT` needed to be combined with
+ [[ZmnSCPxj]] [claimed][zmnscpxj cat1] `OP_CAT` needed to be combined with
proposed opcodes `OP_TX` (see [Newsletter #187][news187 op_tx]),
[OP_CHECKSIGFROMSTACK][topic op_checksigfromstack] (CSFS), or a
similar feature in order for it to enable inescapable recursive
diff --git a/_posts/en/newsletters/2022-05-25-newsletter.md b/_posts/en/newsletters/2022-05-25-newsletter.md
index 301f3691a..930681360 100644
--- a/_posts/en/newsletters/2022-05-25-newsletter.md
+++ b/_posts/en/newsletters/2022-05-25-newsletter.md
@@ -127,7 +127,7 @@ software.
design.
Replying to /dev/fd0's summary for the mailing list, developer
- ZmnSCPxj suggested that we only adopt mechanisms that encourage
+ [[ZmnSCPxj]] suggested that we only adopt mechanisms that encourage
protocols designed for maximum onchain privacy. That privacy would
deny miners the information necessary to perform MEV. As of the
writing of this newsletter, no further comments had been received on
diff --git a/_posts/en/newsletters/2022-06-15-newsletter.md b/_posts/en/newsletters/2022-06-15-newsletter.md
index 97f80a5cf..264ca8e34 100644
--- a/_posts/en/newsletters/2022-06-15-newsletter.md
+++ b/_posts/en/newsletters/2022-06-15-newsletter.md
@@ -185,7 +185,7 @@ changes to popular Bitcoin infrastructure software.
discussed how the two protocols could be made compatible with each other so
that nodes could use either or both of them.
-- **Using routing fees to signal liquidity:** developer ZmnSCPxj
+- **Using routing fees to signal liquidity:** developer [[ZmnSCPxj]]
[posted][zmnscpxj hilolohi] to the Lightning-Dev mailing list an
argument for how optimally cheap and reliable payments could be
obtained through game theoretic behavior between spenders and routing
diff --git a/_posts/en/newsletters/2022-06-22-newsletter.md b/_posts/en/newsletters/2022-06-22-newsletter.md
index 186876669..bd89b168d 100644
--- a/_posts/en/newsletters/2022-06-22-newsletter.md
+++ b/_posts/en/newsletters/2022-06-22-newsletter.md
@@ -164,7 +164,7 @@ infrastructure software.
guarantees. If protecting the location of the real signing utxo is a
matter of life and death, on no account use a system like this!"
- On the Lightning-Dev mailing list, developer ZmnSCPxj
+ On the Lightning-Dev mailing list, developer [[ZmnSCPxj]]
[suggested][zmnscpxj riddle] RIDDLE might be an option for separating
LN's anti-sybil mechanism from UTXO-based channel identifiers which,
in the era of [taproot][topic taproot] and [signature
diff --git a/_posts/en/newsletters/2022-07-06-newsletter.md b/_posts/en/newsletters/2022-07-06-newsletter.md
index 1eeefd36b..962fb81db 100644
--- a/_posts/en/newsletters/2022-07-06-newsletter.md
+++ b/_posts/en/newsletters/2022-07-06-newsletter.md
@@ -87,7 +87,7 @@ infrastructure software.
summary was being written.
- **Fundamental fee-collection strategies for LN forwarding nodes:**
- developer ZmnSCPxj [summarized][zmnscpxj forwarding] three strategies
+ developer [[ZmnSCPxj]] [summarized][zmnscpxj forwarding] three strategies
LN forwarding nodes can use in collecting fees for routing payments
(including the strategy of not collecting fees). ZmnSCPxj then
analyzes possible outcomes of the different strategies. This seems
@@ -96,7 +96,7 @@ infrastructure software.
which also received significant [additional commentary][towns fee
signal] in the past week from Anthony Towns.
-- **Onion message rate limiting:** Bastien Teinturier
+- **Onion message rate limiting:** [[Bastien Teinturier]]
[posted][teinturier rate limit] a summary of an idea he attributes to
Rusty Russell for rate limiting [onion messages][topic onion
messages]. The proposal has each node store just an extra 32 bytes of
diff --git a/_posts/en/newsletters/2022-07-20-newsletter.md b/_posts/en/newsletters/2022-07-20-newsletter.md
index 62e068458..583596071 100644
--- a/_posts/en/newsletters/2022-07-20-newsletter.md
+++ b/_posts/en/newsletters/2022-07-20-newsletter.md
@@ -78,7 +78,7 @@ summaries of notable changes to popular Bitcoin infrastructure software.
hadn't moved for, say, 120 years---well past the expected
lifetime of the original owner and their heirs.
- - *Censorship resistance:* developer ZmnSCPxj [expanded][zmnscpxj cr] an
+ - *Censorship resistance:* developer [[ZmnSCPxj]] [expanded][zmnscpxj cr] an
[argument][voskuil cr] by Eric Voskuil that transaction fees enhance
Bitcoin's censorship resistance. For example, if 90% of the
block reward comes from subsidy and 10% from transaction fees,
diff --git a/_posts/en/newsletters/2022-09-28-newsletter.md b/_posts/en/newsletters/2022-09-28-newsletter.md
index 0c3df3df2..c5c70343a 100644
--- a/_posts/en/newsletters/2022-09-28-newsletter.md
+++ b/_posts/en/newsletters/2022-09-28-newsletter.md
@@ -25,7 +25,7 @@ popular Bitcoin infrastructure software.
would need to pay proportionally more than a payment which leaves 75%
of its outbound capacity available.
- Developer ZmnSCPxj [described][zmnscpxj ratecards] a simple way to
+ Developer [[ZmnSCPxj]] [described][zmnscpxj ratecards] a simple way to
use ratecards, "you can model a rate card as four separate channels
between the same two nodes, with different costs each. If the path
at the lowest cost fails, you just try another route that may
diff --git a/_posts/en/newsletters/2022-10-05-newsletter.md b/_posts/en/newsletters/2022-10-05-newsletter.md
index d69b65d20..f350a7867 100644
--- a/_posts/en/newsletters/2022-10-05-newsletter.md
+++ b/_posts/en/newsletters/2022-10-05-newsletter.md
@@ -94,7 +94,7 @@ projects.
several challenges with the original ratecards idea that wouldn't be
problems for flow control based on adjusting `htlc_maximum_msat`.
- ZmnSCPxj [criticized][zmnscpxj valve] several aspects of the idea, including
+ [[ZmnSCPxj]] [criticized][zmnscpxj valve] several aspects of the idea, including
noting that spenders could still send the same amount of value
through a lower-max rate channel, resulting in it again becoming
unbalanced, just by splitting an overall payment into additional
diff --git a/_posts/en/newsletters/2022-11-02-newsletter.md b/_posts/en/newsletters/2022-11-02-newsletter.md
index 35d10e89f..9f79d2858 100644
--- a/_posts/en/newsletters/2022-11-02-newsletter.md
+++ b/_posts/en/newsletters/2022-11-02-newsletter.md
@@ -130,7 +130,7 @@ software.
identify which hop the payment failed at by comparing how many
satoshis it sent to how many satoshis it received back.
-- **Anchor outputs workaround:** Bastien Teinturier [posted][teinturier
+- **Anchor outputs workaround:** [[Bastien Teinturier]] [posted][teinturier
fees] to the Lightning-Dev mailing list a [proposal][bolts #1036] for using
[anchor outputs][topic anchor outputs] with multiple presigned
versions of each [HTLC][topic htlc] at different feerates. Anchor
diff --git a/_posts/en/newsletters/2022-11-16-newsletter.md b/_posts/en/newsletters/2022-11-16-newsletter.md
index 13603d5e4..08c419c75 100644
--- a/_posts/en/newsletters/2022-11-16-newsletter.md
+++ b/_posts/en/newsletters/2022-11-16-newsletter.md
@@ -34,7 +34,7 @@ to popular Bitcoin infrastructure software.
joinpools], optimistic rollups (see [Newsletter #222][news222
rollup]), and other stateful constructions.
-- **Paper about channel jamming attacks:** Clara Shikhelman and Sergei
+- **Paper about channel jamming attacks:** [[Clara Shikhelman]] and Sergei
Tikhomirov [posted][st unjam post] to the Lightning-Dev mailing list
the summary of a [paper][st unjam paper] they've written about
solutions to [channel jamming attacks][topic channel jamming attacks].
diff --git a/_posts/en/newsletters/2022-11-30-newsletter.md b/_posts/en/newsletters/2022-11-30-newsletter.md
index e21793501..99f465c6b 100644
--- a/_posts/en/newsletters/2022-11-30-newsletter.md
+++ b/_posts/en/newsletters/2022-11-30-newsletter.md
@@ -58,7 +58,7 @@ infrastructure software.
forwarding node chooses for itself how to distribute its
credential tokens.
- Clara Shikhelman, whose own co-authored proposal partly based on
+ [[Clara Shikhelman]], whose own co-authored proposal partly based on
local reputation was described in [Newsletter #226][news226 jam],
replied to [ask][shikelman credentials] whether credential tokens
were transferable between users and whether that could lead to the
diff --git a/_posts/en/newsletters/2023-01-11-newsletter.md b/_posts/en/newsletters/2023-01-11-newsletter.md
index 86b8522ae..ef381f827 100644
--- a/_posts/en/newsletters/2023-01-11-newsletter.md
+++ b/_posts/en/newsletters/2023-01-11-newsletter.md
@@ -15,7 +15,7 @@ notable changes to popular Bitcoin infrastructure software.
## News
-- **Non-interactive LN channel open commitments:** developers ZmnSCPxj
+- **Non-interactive LN channel open commitments:** developers [[ZmnSCPxj]]
and Jesse Posner [posted][zp potentiam] to the Lightning-Dev mailing
list a proposal for a new technique for opening LN channels, which
they call *swap-in-potentiam*. The existing methods for opening an LN
diff --git a/_posts/en/newsletters/2023-02-01-newsletter.md b/_posts/en/newsletters/2023-02-01-newsletter.md
index 90ca8fe74..a0cfb6590 100644
--- a/_posts/en/newsletters/2023-02-01-newsletter.md
+++ b/_posts/en/newsletters/2023-02-01-newsletter.md
@@ -14,7 +14,7 @@ changes to popular Bitcoin infrastructure software.
## News
-- **Serverless payjoin proposal:** Dan Gould [posted][gould payjoin] to
+- **Serverless payjoin proposal:** [[Dan Gould]] [posted][gould payjoin] to
the Bitcoin-Dev mailing list a proposal and [proof of concept
implementation][payjoin impl] for a serverless version of [BIP78][],
the [payjoin][topic payjoin] protocol.
diff --git a/_posts/en/newsletters/2023-02-08-newsletter.md b/_posts/en/newsletters/2023-02-08-newsletter.md
index 64a9a577a..a03556492 100644
--- a/_posts/en/newsletters/2023-02-08-newsletter.md
+++ b/_posts/en/newsletters/2023-02-08-newsletter.md
@@ -36,8 +36,8 @@ Bitcoin infrastructure software.
As of this writing, there was vigorous ongoing discussion about the
topic. We'll provide an update in next week's newsletter.
-- **Summary of call about mitigating LN jamming:** Carla Kirk-Cohen and
- Clara Shikhelman [posted][ckccs jamming] to the Lightning-Dev mailing
+- **Summary of call about mitigating LN jamming:** [[Carla Kirk-Cohen]] and
+ [[Clara Shikhelman]] [posted][ckccs jamming] to the Lightning-Dev mailing
list a summary of a recent video conversation about attempts to
address [channel jamming attacks][topic channel jamming attacks].
Topics discussed included upgrade mechanism tradeoffs, a simple
diff --git a/_posts/en/newsletters/2023-02-22-newsletter.md b/_posts/en/newsletters/2023-02-22-newsletter.md
index 9f49a3697..43993baf7 100644
--- a/_posts/en/newsletters/2023-02-22-newsletter.md
+++ b/_posts/en/newsletters/2023-02-22-newsletter.md
@@ -63,8 +63,8 @@ of notable changes to popular Bitcoin infrastructure software.
approach is building a mechanism that prevents receivers from
keeping any overpayment that arrives. {% assign timestamp="4:15" %}
-- **Feedback requested on LN good neighbor scoring:** Carla Kirk-Cohen
- and Clara Shikhelman [posted][ckc-cs reputation] to the Lightning-Dev
+- **Feedback requested on LN good neighbor scoring:** [[Carla Kirk-Cohen]]
+ and [[Clara Shikhelman]] [posted][ckc-cs reputation] to the Lightning-Dev
mailing list to request feedback on the recommend parameters for how a
node should judge whether its channel counterparties are a good source of
forwarded payments. They suggest several criteria to judge by and
@@ -176,7 +176,7 @@ answers posted since our last update.*
{% assign timestamp="50:07" %}
- [Why doesn't the protocol allow unconfirmed transactions to expire at a given height?]({{bse}}116926)
- Larry Ruane references Satoshi on why it wouldn't be prudent for
+ [[Larry Ruane]] references Satoshi on why it wouldn't be prudent for
transactions to have the seemingly useful ability to specify an
expiration height, that is, a height after which the transaction,
if not yet mined, is no longer valid (and therefore can't be mined). {% assign timestamp="51:00" %}
diff --git a/_posts/en/newsletters/2023-04-12-newsletter.md b/_posts/en/newsletters/2023-04-12-newsletter.md
index 9f55158b3..44e466b88 100644
--- a/_posts/en/newsletters/2023-04-12-newsletter.md
+++ b/_posts/en/newsletters/2023-04-12-newsletter.md
@@ -66,7 +66,7 @@ software.
After that, they can return to operating on a single commitment
transaction.
- - *Relative amounts and zero-conf splices:* Bastien Teinturier
+ - *Relative amounts and zero-conf splices:* [[Bastien Teinturier]]
[posted][teinturier splice] about several proposed specification
updates. In addition to the aforementioned commitment signatures
change, he also recommends that splice proposals use relative
diff --git a/_posts/en/newsletters/2023-05-17-newsletter.md b/_posts/en/newsletters/2023-05-17-newsletter.md
index ed4d38173..f93ca5cf5 100644
--- a/_posts/en/newsletters/2023-05-17-newsletter.md
+++ b/_posts/en/newsletters/2023-05-17-newsletter.md
@@ -21,10 +21,10 @@ describing notable changes to popular Bitcoin infrastructure software.
## News
-- **Testing HTLC endorsement:** several weeks ago, Carla Kirk-Cohen and
- Clara Shikhelman [posted][kcs endorsement] to the Lightning-Dev mailing list about
+- **Testing HTLC endorsement:** several weeks ago, [[Carla Kirk-Cohen]] and
+ [[Clara Shikhelman]] [posted][kcs endorsement] to the Lightning-Dev mailing list about
the next steps they and others planned to take to test the idea of
- [HTLC][topic htlc] endorsement (see [Newsletter #239][news239
+ [[HTLC]] endorsement (see [Newsletter #239][news239
endorsement]) as part of a mitigation for [channel jamming
attacks][topic channel jamming attacks]. Most notably, they provided a
short [proposed specification][bolts #1071] that could be deployed
@@ -57,15 +57,15 @@ describing notable changes to popular Bitcoin infrastructure software.
transaction that will anchor the channel onchain when it is confirmed
(making it into a regular channel).
- In a [reply][zmnscpxj lsp], developer ZmnSCPxj wrote in favor of open specifications
+ In a [reply][zmnscpxj lsp], developer [[ZmnSCPxj]] wrote in favor of open specifications
for LSPs. He noted that they make it easy for a client to connect
to multiple LSPs, which will prevent vendor lock-in and improve
privacy.
-- **Challenges with zero-conf channels when dual funding:** Bastien
- Teinturier [posted][teinturier 0conf] to the Lightning-Dev mailing list about the
- challenges of allowing [zero-conf channels][topic zero-conf channels] when using the
- [dual-funding protocol][topic dual funding]. Zero-conf channels can be used even before the
+- **Challenges with zero-conf channels when dual funding:**
+ [[Bastien Teinturier]] [posted][teinturier 0conf] to the Lightning-Dev mailing list about the
+ challenges of allowing [[zero-conf channels]] when using the
+ [[dual-funding|dual-funding protocol]]. Zero-conf channels can be used even before the
channel open transaction is confirmed; this is trustless in some
cases. Dual-funded channels are channels that were created using the
dual-funding protocol, which may include channels where the open
@@ -86,7 +86,7 @@ describing notable changes to popular Bitcoin infrastructure software.
were discussed, although none seemed satisfying to participants as
of this writing.
-- **Advanced payjoin applications:** Dan Gould [posted][gould payjoin] to the
+- **Advanced payjoin applications:** [[Dan Gould]] [posted][gould payjoin] to the
Bitcoin-Dev mailing list several suggestions for using the
[payjoin][topic payjoin] protocol to do more than just send or receive
a simple payment. Two of the suggestions we found most interesting
@@ -99,13 +99,13 @@ describing notable changes to popular Bitcoin infrastructure software.
- *Batched payment forwarding:* rather than Alice paying Bob, Alice
instead pays several people Bob owes money (or wants to establish
- a credit with). Gould's example considers an exchange that has a
+ a credit with). Gould's example [[payment batching|batching]] considers an exchange that has a
steady stream of deposits and withdrawals; payjoin allows withdrawals
to be paid for by new deposits when possible.
Both of these techniques allow reducing what would be at least two
transactions into a single transaction, saving a considerable amount
- of block space. When [batching][topic payment batching] is used,
+ of block space. When is used,
the space savings may be even larger. Even better from the
perspective of the original receiver (e.g. Bob),
the original spender (e.g. Alice) may pay all or some of the
@@ -200,7 +200,7 @@ Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], and
continue trying to download the block from peers that claim to have it
until one of the received blocks has been written to disk.
-- [LDK #2286][] allows creating and signing [PSBTs][topic psbt] for
+- [LDK #2286][] allows creating and signing [[psbt|PSBTs]] for
outputs controlled by the local wallet.
- [LDK #1794][] begins adding support for [dual funding][topic dual
diff --git a/_posts/en/podcast/2023-05-11-newsletter-recap.md b/_posts/en/podcast/2023-05-11-newsletter-recap.md
index 324db4293..2a4e259ba 100644
--- a/_posts/en/podcast/2023-05-11-newsletter-recap.md
+++ b/_posts/en/podcast/2023-05-11-newsletter-recap.md
@@ -8,7 +8,7 @@ type: podcast
layout: podcast-episode
lang: en
---
-Mark "Murch" Erhardt and Mike Schmidt are joined by Larry Ruane and Thomas Hartman to discuss [Newsletter #250]({{page.reference}}).
+Mark "Murch" Erhardt and Mike Schmidt are joined by [[Larry Ruane]] and Thomas Hartman to discuss [Newsletter #250]({{page.reference}}).
{% include functions/podcast-links.md %}
diff --git a/_topics/en/dual-funding.md b/_topics/en/dual-funding.md
index bded0fe93..4462c7c3a 100644
--- a/_topics/en/dual-funding.md
+++ b/_topics/en/dual-funding.md
@@ -104,9 +104,6 @@ optech_mentions:
- title: "Eclair #2596 limits the number of RBF fee bumps in a dual funded channel open"
url: /en/newsletters/2023/02/22/#eclair-2596
- - title: "Challenges with zero-conf channels when dual funding"
- url: /en/newsletters/2023/05/17/#challenges-with-zero-conf-channels-when-dual-funding
-
- title: "LDK #1794 begins adding support for dual funding"
url: /en/newsletters/2023/05/17/#ldk-1794
diff --git a/_topics/en/zero-conf-channels.md b/_topics/en/zero-conf-channels.md
index 4ecd63436..aaf1158aa 100644
--- a/_topics/en/zero-conf-channels.md
+++ b/_topics/en/zero-conf-channels.md
@@ -53,8 +53,6 @@ optech_mentions:
- title: "2022 year-in-review: zero-conf channels"
url: /en/newsletters/2022/12/21/#zero-conf-channels
- - title: "Challenges with zero-conf channels when dual funding"
- url: /en/newsletters/2023/05/17/#challenges-with-zero-conf-channels-when-dual-funding
## Optional. Same format as "primary_sources" above
# see_also:
diff --git a/assets/css/main.scss b/assets/css/main.scss
index 7fddfa026..57586ddd8 100644
--- a/assets/css/main.scss
+++ b/assets/css/main.scss
@@ -324,4 +324,27 @@ div.podcast .anchor-list {
width: 32px;
margin: 2px;
display: inline;
+}
+
+/* Backlinks */
+
+.backlink-box {
+ position: relative;
+ font-size: 0.9em;
+ background: #f5f5f5;
+ border-radius: 4px;
+ padding-left: 3em;
+ padding-top: 1.7em;
+ padding-right: 0.6em;
+ p {
+ padding-bottom: 0.4em;
+ }
+}
+
+.backlink-header {
+ position: absolute;
+ top: 0.3em;
+ left: 0.7em;
+ font-size: 0.85em;
+ color: #828282;
}
\ No newline at end of file
diff --git a/en/people.md b/en/people.md
new file mode 100644
index 000000000..568c5d97a
--- /dev/null
+++ b/en/people.md
@@ -0,0 +1,36 @@
+---
+title: People
+permalink: /en/people/
+layout: page
+---
+{% capture raw_people_list %}
+{%- for person in site.people -%}
+ [{{person.title}}]({{person.url}})ENDTOPIC
+{%- endfor -%}
+{% endcapture %}
+
+{% assign people_list = raw_people_list | split: 'ENDTOPIC' | sort_natural %}
+{% assign number_of_people = site.people | size %}
+
+