diff --git a/docs/.vuepress/components/IRCWRAPPER.vue b/docs/.vuepress/components/IRCWRAPPER.vue
new file mode 100644
index 0000000000..ab7ccd76e7
--- /dev/null
+++ b/docs/.vuepress/components/IRCWRAPPER.vue
@@ -0,0 +1,125 @@
+<template>
+  <div class="irc-logs" v-html="logs"></div>
+</template>
+
+<script>
+import he from 'he';
+
+export default {
+  name: 'IRCWRAPPER',
+  data() {
+    return {
+      logs: "",
+    }
+  },  
+  methods: {
+    parseLogs(content) {
+
+      const URI_SCHEMES = ['http', 'https'];
+      const TRAILING = /[^\/[:^punct:]]+$/;
+      const HH_MM = /^([0-1][0-9]|[2][0-3]):[0-5][0-9] .*/;
+      const IRC_NICK = /^(?:\s*)(<.+?>)/;
+      const LT_GT = /[<>]/g;
+      const LINE_DIGITS = 3;
+      const TIME_SIZE = 'HH:MM'.length;
+      const TIME_SIZE_PLUS_1 = TIME_SIZE + 1;
+      const NON_BREAKING_SPACE = '&nbsp;';
+      const COLORS = ['brown', 'goldenrod', 'cadetblue', 'chocolate', 'cornflowerblue', 'coral', 'crimson', 'forestgreen', 'darkblue', 'firebrick', 'blue', 'green', 'grey', 'hotpink', 'indianred', 'indigo', 'blueviolet', 'maroon', 'mediumblue', 'mediumpurple', 'mediumseagreen', 'navy', 'fuchsia', 'olive', 'orchid', 'purple', 'red', 'seagreen', 'sienna', 'orange', 'slateblue', 'peru', 'salmon', 'teal', 'magenta', 'steelblue', 'rebeccapurple', 'tomato', 'violet', 'darkcyan'];
+      const NUM_COLORS = COLORS.length;
+
+      let lines = content.split("\n");
+      let outputHtml = "";
+      let colors = {};
+      let colorIndex = 0;
+
+      for (let i = 0; i < lines.length; i++) {
+        if ( lines[i].length == 0 ) {
+          break;
+        }
+        const lineno = `${NON_BREAKING_SPACE.repeat(LINE_DIGITS - i.toString().length)}${i}`;
+        const time = lines[i].slice(0, TIME_SIZE);
+        const nameMatch = lines[i].slice(TIME_SIZE_PLUS_1).match(IRC_NICK);
+        const name = nameMatch ? nameMatch[0] : '';
+        let nick = name.replaceAll(LT_GT, '').trim();
+        const color = colors[nick] || ((colorIndex += 1) % NUM_COLORS, colors[nick] = COLORS[colorIndex]);
+        nick = nick === '' ? nick : `&lt;${nick}&gt;`;
+        let message = he.escape(lines[i].slice(TIME_SIZE_PLUS_1 + name.length));
+  
+        let urls = message.match(URI_SCHEMES);
+        if (urls != null) {
+          urls.forEach((uri) => {
+            const link = uri.replace(TRAILING, '');
+            message = message.replace(link, `<a href='${link}' target='blank'>${link}</a>`);
+          });
+        }
+  
+        outputHtml += `<table class='log-line' id='l-${i}'>
+                  <tr class='log-row'>
+                    <td class='log-lineno'><a class="lineno" href='#l-${i}'>${lineno}</a></td>
+                    <td class='log-time'>${time}</td>
+                    <td>
+                      <span class='log-nick' style='color:${color}'>${nick}</span>
+                      <span class='log-msg'>${message}</span>
+                    </td>
+                  </tr>
+                </table>`;
+      }
+
+      return outputHtml;
+
+    }
+  },
+  mounted() {
+    let content = this.$slots.default[0].children[0].text;
+    let parsedLogs = this.parseLogs(content);
+    this.logs = parsedLogs;
+  }
+};
+</script>
+
+<style scoped>
+.log-time{
+  color: #0000f0;
+  padding-left: 6px;
+  padding-right: 6px;
+}
+
+.log-nick {
+  font-weight: bold;
+  color: green;
+}
+
+.log-msg {
+  padding-left: 0px;
+  white-space: pre-wrap;
+}
+
+.log-line {
+  margin-block-start: 0px;
+  margin-block-end: 0px;
+  font-family: monospace;
+  border-spacing: 0px;
+}
+  
+.log-row {
+  vertical-align: top;
+}
+
+td.log-lineno {
+  background-color: #f0f0f0;
+}
+
+th, td {
+  border: none;
+  padding: 0px;
+}
+
+table.log-line {
+  border-collapse: separate;
+}
+
+a.lineno {
+  text-decoration: none;
+}
+  
+</style>
\ No newline at end of file
diff --git a/docs/.vuepress/components/ReviewClubHeader.vue b/docs/.vuepress/components/ReviewClubHeader.vue
new file mode 100644
index 0000000000..4b2748a5a7
--- /dev/null
+++ b/docs/.vuepress/components/ReviewClubHeader.vue
@@ -0,0 +1,58 @@
+<template>
+    <header>
+        <div class="logo">
+            <a href="/review-club">BitcoinDevKit PR Review Club</a>
+        </div>
+        <nav>
+            |<span v-for="nav in navs">
+            <a :href="nav.link" class="nav-link">
+                {{ nav.name }}
+            </a> |</span>
+        </nav>
+    </header>
+</template>
+
+
+<script>
+export default {
+    name: "ReviewClubHeader",
+    data() {
+        return {
+            navs: [{name: "ReviewClub Home", link: "/review-club/"}, {name: "BitcoinDevKit Home", link: "/"}, {name: "Meetings", link: "/review-club/meetings/"}, {name: "Code of Conduct", link: "/review-club/code-of-conduct/"}, {name: "Hosting", link: "/review-club/hosting/"}],
+        }
+    }
+}
+</script>
+
+<style scoped>
+header {
+    font-family: "Helvetica",sans-serif;
+    line-height: 1.5;
+}
+
+.logo {
+    text-decoration: none;
+    font-weight: bold;
+    font-size: 48px;
+}
+
+.logo a:link, .logo a:visited {
+    color: #000;
+
+}
+
+a.nav-link {
+    display: inline-block;
+    margin-left: 5px;
+    color: #0000f0;
+    text-decoration: underline;
+}
+
+a.nav-link:visited {
+    color: #551b8c;
+}
+
+a.nav-link:hover {
+    color: #fcc603;
+}
+</style>
\ No newline at end of file
diff --git a/docs/.vuepress/components/ReviewClubLayout.vue b/docs/.vuepress/components/ReviewClubLayout.vue
new file mode 100644
index 0000000000..e514afd640
--- /dev/null
+++ b/docs/.vuepress/components/ReviewClubLayout.vue
@@ -0,0 +1,84 @@
+<template>
+  <div class="container">
+    <div class="header-container">
+      <ReviewClubHeader />
+    </div>
+    <div class="body-container">
+      <Content/>
+    </div>
+  </div>
+</template>
+
+<script>
+import ReviewClubHeader from "./ReviewClubHeader.vue";
+
+export default {
+  data() {
+    return {
+
+    }
+  },
+  components: {
+    ReviewClubHeader
+  },
+}
+</script>
+
+<style scoped>
+.body-container {
+  color: #000;
+  box-sizing: border-box;
+  display: flex;
+  margin-left: 10%;
+  margin-right: 10%;
+  font-family: "Helvetica",sans-serif;
+  line-height: 1.5;
+}
+
+.header-container {
+  color: #000;
+  box-sizing: border-box;
+  display: flex;
+  margin-left: 10%;
+  margin-right: 10%;
+  font-family: "Helvetica",sans-serif;
+  line-height: 1.5;
+}
+
+.body-container .question {
+  font-weight: bold;
+  
+}
+
+.body-container a:link {
+  color: #0000f0;
+}
+
+.body-container a:visited {
+  color: #551b8c;
+}
+
+.body-container a {
+  text-decoration: underline;
+}
+
+.meeting-list-container .meeting-list {
+    list-style-type: none;
+}
+
+#meeting-link {
+    color: #0000f0;
+}
+
+#meeting-link:hover {
+    color: #fcc603;
+}
+
+#meeting-link:visited {
+    color: #551b8c;
+}
+
+#text-separator {
+    font-weight: bold;
+}
+</style>
\ No newline at end of file
diff --git a/docs/.vuepress/components/ReviewClubMeetingHeader.vue b/docs/.vuepress/components/ReviewClubMeetingHeader.vue
new file mode 100644
index 0000000000..0431f88876
--- /dev/null
+++ b/docs/.vuepress/components/ReviewClubMeetingHeader.vue
@@ -0,0 +1,31 @@
+<template>
+    <div class="meeting-header">
+        <p class="date">{{ date| formatDate }}</p>
+        <p class="pr"><a :href="pr">{{ pr }}</a></p>
+        <div class="people-container">
+            <span class="host">Host: {{ host }} <a :href="`https://github.com/${host}`"><i class="fab fa-github"></i></a></span> -
+            <span class="authors">PR Authors: <span class="author" v-for="author in authors">{{ author }} <a :href="`https://github.com/${author}`"><i class="fab fa-github"></i></a></span></span>
+        </div>
+        <p>The PR branch HEAD was <a :href="commitLink">{{ commit }}</a> at the time of this review club meeting.</p>
+    </div>
+</template>
+
+
+<script>
+export default {
+    name: "ReviewClubMeetingHeader",
+    props: {
+        host: String,
+        authors: Array,
+        pr: String,
+        date: String,
+        commit: String,
+        commitLink: String
+    },
+
+}
+</script>
+
+<style>
+@import 'https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.3/css/all.min.css';
+</style>
\ No newline at end of file
diff --git a/docs/.vuepress/components/ReviewClubMeetingLayout.vue b/docs/.vuepress/components/ReviewClubMeetingLayout.vue
new file mode 100644
index 0000000000..21b39f34c7
--- /dev/null
+++ b/docs/.vuepress/components/ReviewClubMeetingLayout.vue
@@ -0,0 +1,64 @@
+<template>
+  <div class="container">
+    <div class="header-container">
+      <ReviewClubHeader />
+    </div>
+    <div class="body-container">
+      <Content/>
+    </div>
+  </div>
+</template>
+
+<script>
+import ReviewClubHeader from "./ReviewClubHeader.vue";
+
+export default {
+  data() {
+    return {
+
+    }
+  },
+  components: {
+    ReviewClubHeader
+  },
+}
+</script>
+
+<style scoped>
+.body-container {
+  color: #000;
+  box-sizing: border-box;
+  display: flex;
+  margin-left: 10%;
+  margin-right: 10%;
+  font-family: "Helvetica",sans-serif;
+  line-height: 1.5;
+}
+
+.header-container {
+  color: #000;
+  box-sizing: border-box;
+  display: flex;
+  margin-left: 10%;
+  margin-right: 10%;
+  font-family: "Helvetica",sans-serif;
+  line-height: 1.5;
+}
+
+.body-container .question {
+  font-weight: bold;
+  
+}
+
+.body-container a:link {
+  color: #0000f0;
+}
+
+.body-container a:visited {
+  color: #551b8c;
+}
+
+.body-container a {
+  text-decoration: underline;
+}
+</style>
\ No newline at end of file
diff --git a/docs/.vuepress/config.js b/docs/.vuepress/config.js
index ac44442906..224f2c5089 100644
--- a/docs/.vuepress/config.js
+++ b/docs/.vuepress/config.js
@@ -106,6 +106,10 @@ module.exports = {
         text: 'Blog',
         link: '/blog/'
       },
+      {
+        text: 'Review Club',
+        link: '/review-club/'
+      },
       {
         text: 'Discord',
         link: discordUrl
diff --git a/docs/.vuepress/enhanceApp.js b/docs/.vuepress/enhanceApp.js
new file mode 100644
index 0000000000..07a11804d1
--- /dev/null
+++ b/docs/.vuepress/enhanceApp.js
@@ -0,0 +1,38 @@
+export default ({ Vue }) => {
+    Vue.filter('formatDate', dateString => {
+        const date = new Date(dateString);
+        const options = { day: '2-digit', month: 'short', year: 'numeric' };
+        return date.toLocaleDateString('en-US', options);
+    });
+
+    // Create a mixin
+    const customPropertyMixin = {
+        created() {
+            this.$meetingTime = "13:00 UTC";
+            this.$meetingDay = "Thursday";
+            this.$meetingPlace = 'https://discord.gg/dstn4dQ';
+        },
+    };
+  
+    // Apply the mixin globally
+    Vue.mixin(customPropertyMixin);
+
+    // Create a mixin
+    const customMethodMixin = {
+        methods: {
+            $getLastFourMeetings(pages) {
+                let pastMeetings = pages.filter(page => page.frontmatter.status === 'past' && page.frontmatter.layout === 'ReviewClubMeetingLayout');
+                pastMeetings.sort((a, b) => {
+                    const dateA = new Date(a.frontmatter.date);
+                    const dateB = new Date(b.frontmatter.date);
+                    return dateB - dateA;
+                });
+                return pastMeetings.length > 4? pastMeetings.slice(0, 4) : pastMeetings;
+            },
+        },
+    };
+  
+    // Apply the mixin globally
+    Vue.mixin(customMethodMixin);
+
+};
\ No newline at end of file
diff --git a/docs/review-club/README.md b/docs/review-club/README.md
new file mode 100644
index 0000000000..197aefdc50
--- /dev/null
+++ b/docs/review-club/README.md
@@ -0,0 +1,94 @@
+---
+layout: ReviewClubLayout
+title: BDK Weekly PR review club
+---
+
+### A review club for BitcoinDevKit(BDK) PRs
+
+<span class="question">What is this?</span> &nbsp;A review club for BitcoinDevKit (BDK) PRs at **{{ $meetingTime }} on {{ $meetingDay }}s** in the #review-club-meeting channel on
+<a :href="$meetingPlace">Discord</a>. Sessions are organized on 
+a need Basis (Follow the #review-club-org channel for those conversations) 
+
+<span class="question">What's it for?</span> &nbsp;To help newer contributors
+learn about the BDK review process. The review club is *not* primarily
+intended to help open PRs get merged.
+
+<span class="question">Who should take part?</span> &nbsp;Anyone who wants to
+learn about contributing to BDK. All are welcome to come and ask
+questions!
+
+<span class="question">How do I take part?</span> Just show up on IRC! See
+[Attending your first PR Review Club](/review-club/your-first-meeting/) for more tips
+on how to participate. To stay up to date on newly announced review clubs,
+you can follow us on <a href="https://twitter.com/bitcoindevkit">Twitter</a>.
+
+<span class="question">Who runs this?</span> &nbsp;Upcoming meetings are
+scheduled by {{ "site.coordinator" }}.
+The meetings are hosted by a variety of BDK contributors. See
+some of our [previous hosts](/meetings-hosts/).
+
+## Upcoming Meetings
+
+<div class="meeting-list-container">
+    <h2>Meetings</h2>
+    <div class="meetings-container">
+        <ul class="meeting-list">
+            <template v-for="page in $site.pages">
+                <li v-if="page.frontmatter.layout === 'ReviewClubMeetingLayout' && page.frontmatter.status != 'past'">
+                    {{ page.frontmatter.date | formatDate }}
+                    <span id="text-separator">»</span>
+                        <a id="meeting-link" :href="page.path">#{{ page.frontmatter.pr.split("/").pop() }} {{ page.frontmatter.title }}</a>
+                </li>
+            </template>
+        </ul>
+    </div>
+</div>
+
+We're always looking for interesting PRs to discuss in the review club and for
+volunteer hosts to lead the discussion:
+
+- If there's a PR that you'd like to discuss in a future meeting, feel free to suggest it in the IRC channel.
+- If you'd like to host a meeting, look at the [information for meeting
+  hosts](/review-club/hosting/) and contact us on  [Discord](https://discord.gg/dstn4dQ).
+
+
+
+## Recent Meetings
+
+<div class="meeting-list-container">
+    <h2>Meetings</h2>
+    <div class="meetings-container">
+        <ul class="meeting-list">
+            <template v-for="page in this.$getLastFourMeetings($site.pages)">
+                <li>
+                    {{ page.frontmatter.date | formatDate }}
+                    <span id="text-separator">»</span>
+                        <a id="meeting-link" :href="page.path">#{{ page.frontmatter.pr.split("/").pop() }} {{ page.frontmatter.title }}</a>
+                </li>
+            </template>
+        </ul>
+    </div>
+</div>
+
+See all [meetings](/review-club/meetings/).
+
+## Other Resources for New Contributors
+
+- Read the [Contributing to BDK
+  Guide](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md). This
+  will help you understand the process and some of the terminology we use in BDK.
+- Look at the [Good First
+  Issues](https://github.com/bitcoin/bitcoin/issues?q=is%3aissue+is%3aopen+label%3a%22good+first+issue%22)
+  and [Up For
+  Grabs](https://github.com/bitcoin/bitcoin/issues?utf8=%e2%9c%93&q=label%3a%22up+for+grabs%22)
+  list.
+- Brush up on your Rust. There are [many primers and reference manuals
+  available](https://github.com/rust-unofficial/awesome-rust#resources) plus the [Book](https://doc.rust-lang.org/book/).
+- There are some excellent blog posts on how to start contributing to Bitcoin:
+    - [Contributing to Bitcoin (Daniela Brozzoni)](https://danielabrozzoni.com/posts/contributing_to_oss/)
+    - [A Gentle Introduction to Bitcoin Core Development (Jimmy Song)](https://bitcointechtalk.com/a-gentle-introduction-to-bitcoin-core-development-fdc95eaee6b8)
+    - [Contributing to Bitcoin Core - a Personal Account (John Newbery)](https://bitcointechtalk.com/contributing-to-bitcoin-core-a-personal-account-35f3a594340b)
+    - [Onboarding to Bitcoin Core (Amiti Uttarwar)](https://medium.com/@amitiu/onboarding-to-bitcoin-core-7c1a83b20365)
+    - [How to Review Pull Requests in Bitcoin Core (Jon Atack)](https://jonatack.github.io/articles/how-to-review-pull-requests-in-bitcoin-core)
+
+
diff --git a/docs/review-club/code-of-conduct.md b/docs/review-club/code-of-conduct.md
new file mode 100644
index 0000000000..8d0fc548d1
--- /dev/null
+++ b/docs/review-club/code-of-conduct.md
@@ -0,0 +1,86 @@
+---
+layout: ReviewClubLayout
+title: Code Of Conduct
+---
+
+# Code of Conduct
+
+The PR Review Club is designed to be a safe, respectful, and productive
+environment for everyone. We are dedicated to providing a harassment-free
+experience for all participants regardless of race, gender, age, sexual
+orientation, disability, physical appearance, national origin, ethnicity, or
+religion. This code of conduct is a guide for the behavior we support and don't
+support at our club meetings. 
+
+#### Conduct
+
+Examples of behavior that contribute to a positive environment include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+- [Harassment](#harassment)
+- Public promotional activities 
+- Questioning or challenging someone’s stated self-identity or chosen labels
+- Making general statements about groups you do not belong to
+- Incitement of violence towards any individual
+- Unauthorized publication of private information or communication
+- Unwelcome comments regarding a person’s lifestyle choices and practices,
+  including those related to food, health, parenting, relationships, drugs, and
+  employment
+- Gratuitous or off-topic sexual images or behaviour 
+
+#### Harassment
+
+Harrassment can take many forms. Examples include, but are not limited to:
+
+- Threats of violence
+- Deliberate intimidation
+- Stalking or following
+- Unwanted recording, including logging online activity for harassment purposes
+- Sustained disruption of discussion
+- Unwelcome sexual attention
+- Pattern of inappropriate social contact, such as requesting/assuming
+  inappropriate levels of intimacy with others
+- Continued one-on-one communication after requests to cease
+- Offensive comments or personal questions relating to gender, gender identity
+  and expression, sexual orientation, disability, mental illness,
+  neuro(a)typicality, physical appearance, body size, age, race, national origin,
+  ethnic origin, nationality, immigration status, language, religion or lack
+  thereof, or other identity marker
+
+#### If you see a violation
+
+1. Notify the participant they are in violation of the code of conduct and ask
+   them to stop their behavior. That participant should comply immediately.
+
+2. If the participant does not correct the issue or if you’re uncomfortable
+   speaking up, contact the administrator. When reporting, please include any
+   relevant details, links, screenshots, context that may be used to better
+   understand and resolve the situation. 
+
+3. As soon as available, an administrator will join, identify themselves, and
+   take further action. These actions could include:
+
+    - A warning
+    - Removal from the club’s channel for the duration of that week’s meeting  
+    - Being banned from all future club meetings 
+
+We reserve the right to reject any report we believe to have been made in bad
+faith. Reports intended to silence legitimate criticism may be deleted without
+response.
+
+We will respect confidentiality requests for the purpose of protecting victims
+of abuse. At our discretion, we may publicly name a person about whom we’ve
+received harassment complaints, or privately warn third parties about them, if
+we believe that doing so will increase the safety of The PR Review Club or the
+general public. We will not name harassment victims without their affirmative
+consent.
+
+Thank you for your help in keeping our club welcoming, respectful, and friendly
+to all participants.
diff --git a/docs/review-club/hosting.md b/docs/review-club/hosting.md
new file mode 100644
index 0000000000..19ee680e6f
--- /dev/null
+++ b/docs/review-club/hosting.md
@@ -0,0 +1,213 @@
+---
+layout: ReviewClubLayout
+title: Hosting Review Club
+---
+
+# Hosting a BDK Review Club Meeting
+
+## How to Choose a PR
+
+- The purpose of PR Review Club is to help new contributors learn about the
+  BDK codebase and the process of contributing to the project. Select a PR
+  that is likely to be instructive or interesting. Don't select a PR just because
+  you want it to be merged soon! You may even select a PR that is already merged.
+
+- The PRs discussed at review club should span a range of complexity
+  and difficulty levels, in order to cater to attendees with a variety of
+  different experience levels. Some attendees have only just cloned the BDK repo for the first time, and some have been contributing for months or
+  years. Having some meetings on basic PRs and others on more complex PRs ensures
+  that there's something for everyone.
+
+- Generally, try to pick PRs that don't require a very high level of contextual
+  knowledge, since it's difficult to introduce a lot of concepts in a one hour
+  meeting.
+
+- The appropriate amount of code change to discuss depends on the complexity of
+  the code. It might be fine to discuss 10-20 lines of code if the change is
+  very subtle or has complex interactions. If the change is more straightforward,
+  then it might be fine to discuss 100+ lines of code change. If the PR seems too
+  large to cover in a meeting, consider only discussing a subset of the commits,
+  or breaking up the discussion over multiple meetings.
+
+- It's fine to discuss a PR that you opened yourself. After all, you probably
+  know more about it than anyone else!
+
+## Before the Meeting
+
+- Consider contacting the PR author to let them know that you're going to
+  talk about their PR in the review club. They'll probably be happy that you're
+  interested in their PR and may be prepared to answer questions and give
+  you more context. They may even want to join the meeting themselves.
+
+- Post an announcement for your PR as soon as you can - preferably 2 weeks
+  before the meeting on the **#review-club-org**.  See the [Making a New Post](#making-a-new-post) section
+  below for how to make an announcement post.
+
+- Post notes and questions on the Friday the week before the meeting.
+  That gives attendees time to review the PR and prepare for the meeting. Please
+  open your PR by that Thursday to allow time for maintainers to review and
+  merge it before the weekend.
+
+- Prepare a range of questions from basic to advanced. The review club is a way
+  to help new developers learn. There should be something for everyone.
+
+- In the notes and meeting, don't just talk about the mechanical code changes.
+  Other important aspects to consider are:
+
+  - The motivation for the PR.
+  - The historical context of the PR (why things in the code are the way they
+    are currently, and what PRs have touched that part of the code base in the past).
+  - How to review and test the changes.
+  - Advantages and disadvantages of this approach compared to alternative approaches.
+  - Potential bugs reviewers might want to look out for.
+  - Fun Rust things.
+
+- If you refer to yourself in the notes, use third person narrative
+  (e.g. your name or GitHub profile) rather than first person ("I").
+
+- Don't spoon-feed the attendees. Give them pointers for
+  where to look in the codebase/GitHub/documentation, and let them do their
+  own research from there.
+
+- When linking to code, use stable links that won't break later:
+
+  - for links to code in the master branch, link to a recent commit hash in
+    the master branch of bitcoindevkit/bdk, e.g.
+    [https://github.com/bitcoindevkit/bdk/blob/49632405/crates/chain/src/chain_oracle.rs#L9](https://github.com/bitcoindevkit/bdk/blob/49632405/crates/chain/src/chain_oracle.rs#L9).
+    You can use a short (8 character) commit id.
+
+    **REASON**: linking directly to master
+    isn't stable because line numbers/files change over time.
+
+- Thorough preparation will really pay off. Taking the time to deeply
+  understand the PR will make you feel more relaxed during the meeting.
+
+- If you find yourself struggling with writing the notes and questions, having
+  them ready by Friday, or choosing what areas to focus on, ask the review club
+  maintainers for help.
+
+- It can be useful to write out some anticipated answers/links/references
+  before the meeting so you don't have to type them in the moment.
+
+#### Making a New Post
+
+[Fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks) the website repository [located on GitHub](https://github.com/bitcoindevkit/bitcoindevkit.org).
+
+To make a new post, run the following command from the website directory (replace YYYY-MM-DD with next meeting data and PR_NUMBER with the number of the PR being reviewed):
+
+```shell
+cd ./docs/review-club/meetings && touch YYYY-MM-DD-PR_NUMBER.md
+```
+
+The above command will create a markdown file in the 
+`./docs/review-club/meetings` directory of the website repository
+
+At the top of that file. Add the following frontmatter content and 
+change the different properties to match your post. `commitLink` refers to the commit head of the PR.
+
+```
+---
+layout: ReviewClubMeetingLayout
+date: 2023-03-22
+title: "Sample Meeting"
+pr: https://github.com/bitcoindevkit/bdk/pull/1004
+authors: [dergoegge]
+components: ["p2p", "validation"]
+host: vladimirfomene
+status: past
+commit: 1429da5078c436f04203213133736605f907cb15
+commitLink: https://github.com/danielabrozzoni/bdk/commit/1429da5078c436f04203213133736605f907cb15
+---
+```
+
+Inspire yourself from the previous meetings markdown document structure to 
+structure your meeting notes.
+
+## In the Meeting
+
+- Come with the mindset that the attendees are people who are as smart as you,
+  but don't have the context that you do in BDK or
+  the BDK codebase.
+
+- Start the meeting with `#startmeeting` and "hi" from everyone so you know
+  who's at their keyboard and paying attention.
+
+- It's nice to remind people of some of our meeting conventions at the start:
+
+  - Attendees don't have to ask to ask a question (e.g. "I have a question
+    about x but I don't know if it's on-topic?"). They should just go ahead and
+    ask. If it's off-topic, the host will say so.
+
+  - The host is there to help moderate, not to lead. Attendees don't need to wait
+    for the host to ask a specific question — they can just jump in at any point.
+
+- A quick poll at the start ("Did everyone get a chance to review the PR? How
+  about a quick y/n from everyone") establishes who will probably be
+  asking/answering the more interesting questions.
+
+- Move quickly at the start of the meeting to get to the interesting parts of
+  the PR as soon as possible — preferably within 2 or 3 minutes.
+
+- Don't worry if people haven't had a chance to review the PR yet. This
+  is a voluntary meeting and most people have a lot of other commitments.
+
+- Very open questions to the group (e.g. "Does everyone know how tx gossip works
+  in Bitcoin?") don't get a good response because all the attendees are waiting for
+  someone else to answer. Instead try to make the questions focused on the
+  PR or change set that is being reviewed (e.g. "how does commit X change the
+  way bitcoind gossips transactions?"). Try to phrase questions positively
+  ("please describe how X works") rather than negatively ("Does anyone not know
+  how X works?").
+
+- Once the meeting has reached the challenging questions,
+  it sometimes feels like there are long stretches of silence and no one
+  is out there. Be patient. It takes people a bit of time to formulate their
+  thoughts and type them out.
+
+- Be encouraging! For many people, asking questions or volunteering an answer
+  can be intimidating, even in the pseudonymous comfort of IRC. People are
+  there to learn. Try to create an environment where they feel safe to ask any
+  questions and where they can attempt to answer without fear.
+
+- Keep an eye on the clock, and try to wrap up the session with `#endmeeting` at the end of the
+  hour. Even if you're happy to continue beyond the hour, some of the attendees
+  might have hard stops.
+
+- Have fun, and pat yourself on the back 🚀
+
+## After the Meeting
+
+Let one of the review club maintainers know that the meeting is over. They'll
+take care of updating the website.
+
+#### Adding logs to the review club Page
+
+_This process is done by the review club maintainers_
+
+- Uncomment the `## Meeting Log` markup in the meeting post and copy-paste the
+  meeting log into it. Meeting logs should be copied exactly, but an `##
+  Erratum` section can be added to correct factual errors.
+
+  - To sanitize logs exported from IRCCloud (ensure UTC timezone is selected
+    during export), use the following command on the unzipped .txt file:
+    ```sh
+    cat \#bdk-pr-reviews.txt \
+      | sed -n '/#startmeeting/h;//!H;$!d;x;//p' \
+      | sed '/#endmeeting/q' \
+      | sed '/[⇐→]/d' \
+      | cut -c 13-17,22- \
+      > sanitized_log.txt
+    ```
+
+- Change the `status` of the meeting post from `upcoming` to `past`.
+  ```diff
+  -status: upcoming
+  +status: past
+  ```
+
+- Add the first 7 characters of the PR commit hash at HEAD to the meeting post.
+  This adds a link to the tagged branch on the review club repo.
+  ```diff
+  -commit:
+  +commit: eebaca7
+  ```
diff --git a/docs/review-club/meetings/2023-06-08-10.md b/docs/review-club/meetings/2023-06-08-10.md
new file mode 100644
index 0000000000..249e28a36a
--- /dev/null
+++ b/docs/review-club/meetings/2023-06-08-10.md
@@ -0,0 +1,254 @@
+---
+layout: ReviewClubMeetingLayout
+date: 2023-03-22
+title: "Sample Meeting"
+pr: https://github.com/bitcoindevkit/bdk/pull/1004
+authors: [dergoegge]
+components: ["p2p", "validation"]
+host: vladimirfomene
+status: past
+commit: 1429da5
+commitLink: https://github.com/danielabrozzoni/bdk/commit/1429da5078c436f04203213133736605f907cb15
+---
+
+<ReviewClubMeetingHeader :date="$page.frontmatter.date" :pr="$page.frontmatter.pr" :authors="$page.frontmatter.authors" :host="$page.frontmatter.host" :commit="$page.frontmatter.commit" :commitLink="$page.frontmatter.commitLink"/>
+
+## Notes
+
+- [BIP 141
+  (SegWit)](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki)
+  introduced a new structure called a `witness` to each transaction.
+  Transactions' witnesses are commited to blocks separately from the
+  transaction merkle tree. Witnesses contain data required to check transaction
+  validity, but not required to determine transaction effects (output
+  consumption/creation). In other words, witnesses are used to validate the
+  blockchain state, not to determine what that state is.
+
+  - Witnesses are commited to by placing the root of the *witness merkle tree* in
+    the block's coinbase transaction. By doing so, the witnesses are also commited to
+    in the transaction merkle tree through the coinbase transaction. Nesting the
+    witness commitment in the coinbase transaction was done to make SegWit
+    soft-fork compatible.
+
+- `Assume-valid` is a node setting that makes the node skip some transaction
+  validity checks (signature and script checks) prior to a pre-determined
+  "known to be good" block (assume-valid point). The default assume-valid point
+  is set by the developers and is updated every release, but users have the
+  ability to set their own assume-valid point through the `-assumevalid`
+  setting.
+
+  - The assume-valid feature does not significantly change Bitcoin's security
+    assumptions. If developers (and everyone reviewing the code changes) were
+    to conspire with miners to build a more-work chain with invalid signatures
+    (and go undetected for weeks), and then include it as the default
+    assume-valid point, they could get the network to accept an invalid chain.
+    However, those same people already have that power by just changing the
+    code - which would be much less obvious.
+    ([quoted](https://bitcoin.stackexchange.com/questions/59940/what-are-the-trust-assumptions-in-assumed-valid-in-bitcoin-core-0-14))
+    Additionally, as long as the full chain history remains available for
+    auditing it would be hard for such an attack to go unnoticed.
+
+  - It is also important to note that the configured assume-valid point does not
+    dictate which chain a node follows. The node still does
+    Proof of Work checks, meaning that a large reorg would be able
+    to orphan (parts of) the assumed-valid chain.
+
+- Nodes in prune mode (enabled by the `-prune` setting) fully download and
+  validate the chain history to build a UTXO set enabling them to fully
+  validate any new transaction, but only store a (configurable) portion of the
+  recent history.
+
+- [PR #27050](https://github.com/bitcoin/bitcoin/pull/27050) proposes to skip
+  downloading the witnesses for blocks prior to the configured assume-valid
+  point, for nodes running in prune mode. The rationale for this change is that
+  pruned nodes currently download witnesses but then (prior to the assume-valid
+  point) don't validate them and delete them shortly after. So why not skip
+  downloading those witnesses and save some bandwidth?
+
+## Questions
+
+1. Did you review the PR? [Concept ACK, approach ACK, tested ACK, or
+   NACK](https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#peer-review)?
+   What was your review approach?
+
+2. How much bandwidth is saved, i.e.,
+   what is the cumulative size of all witness data up to block
+   `0000000000000000000013a20dcc8577282e1eabd430592bb8afdd5fe544c05a`? (Hint:
+   the `getblock` RPC returns the `size` and `strippedsize` (size excluding
+   witnesses) for each block).
+
+3. The end goal of the PR can be achieved with very few changes to the code
+   (ignoring edge case scenarios). It essentially only requires two changes,
+   one to the block request logic and one to block validation. Can you (in your
+   own words) describe these two changes in more detail?
+
+4. Without this PR, script validation is skipped under assume-valid, but other
+   checks that involve witness data are not skipped. What other witness related
+   checks exist as part of validation on master?
+
+5. With this PR, all additional witness related checks (Q4) will be skipped for
+   assumed-valid blocks. Is it ok to skip these additional checks? Why or why not?
+
+6. The PR does not include an explicit code change for skipping all the extra
+   checks from Q4. Why does that work out?
+
+7. [Peter Todd left a
+   comment](https://github.com/bitcoin/bitcoin/pull/27050#issuecomment-1423474935)
+   concerning a reduction in security with the changes made in the PR. Can you
+   in your own words summarize his concerns? Do you agree/disagree with them?
+
+## Meeting Log
+
+<IRCWRAPPER>
+<pre>
+12:59 < afig> sup yall
+13:00 < jb55> yo
+13:00 < jnewbery> hi
+13:00 < pinheadmz> hi
+13:00 < Lightlike> hello
+13:00 < merehap> hi
+13:00 < amiti> hi
+13:00 < b10c> hi
+13:01 < jonatack> Hi
+13:01 < jnewbery> Hi folks! Thanks for joining PR review club today.
+13:01 < jnewbery> Before we start talking about #15834, I wanted to poll for feedback on these meetings. Is there any way we could make them more useful?
+13:02 < jnewbery> I'm also taking suggestions for PRs to cover in future weeks. We don't have anything on the agenda yet.
+13:02 < JulioBarros> I think the chat interface is interesting but wonder if an audio or video format would be helpful.
+13:03 < peevsie> hi
+13:03 < Lightlike> just a small thing, could you update the old gist page (with the old agenda) to link to the new page, for the people who have bookmarked that.
+13:03 < aj> heyo
+13:04 < jnewbery> The reason I chose IRC is that it makes it easier for people who don't have somewhere to take a video/audio call to join, and for people who want to just dip in and out
+13:04 < merehap> I definitely prefer IRC over audio/video. Easier to reference the code for a few minutes without falling too far behind in the conversation.
+13:04 < jnewbery> also means we have a text log for people who can't join in real time
+13:05 < jnewbery> ok, I don't want to take too long on this. If you think of anything, please raise it here or just message me directly
+13:05 < jnewbery> OK, onto #15834 - Fix NOTFOUND bug and expire getdata requests for transactions. As usual, I'll give a quick summary before we open up for questions.
+13:05 < jb55> my only suggestion is that it might be neat to have a site where people can propose reviews and have people signup to them, with a calendar and everything
+13:05 < jb55> perhaps when this gets more popular...
+13:06 < jnewbery> jb55: until then, feel free to propose reviews in this channel
+13:06 < jnewbery> This PR is for changes to the "Net Processing" layer. That layer sits between "Net" (which manages connections to peers and is responsible for reading/writing bytes off the wire) and "Validation" (which is responsible for our node's view of the state of the blockchain and mempool).
+13:06 < jnewbery> "Net Processing" receives application level messages from peers, which can either be data messages (eg tx and block inventory) or control messages (eg gossiping addresses of peers or establishing new connections). The developer reference here: https://btcinformation.org/en/developer-reference#p2p-network is probably the best place for documentation on p2p messages.
+13:07 < jnewbery> Data messages are parsed and then passed up to validation for consideration for us to update mempool/chainstate.
+13:07 < jnewbery> This change is in the handling of the INV/GETDATA/TX message exchange, and is an attempt to fix a bug introduced in #14897 where our node could potentially stop asking peers to send us new transactions.
+13:08 < jnewbery> As it says in the PR description, this is a smaller alternative to https://github.com/bitcoin/bitcoin/pull/15776 , who's author is in this chat
+13:08 < jnewbery> aj was actually the first person to report the bug a couple of months ago
+13:09 < jnewbery> as a result of that, we reverted #14897 in the 0.18 release, but kept it in master with the aim of fixing the bug while still keeping the good things about 14897
+13:09 < jnewbery> I'll shut up now. Any questions?
+13:09 < iiiiiiiiiii> >a bug introduced in #14897 https://github.com/bitcoin/bitcoin/pull/14897
+13:09 < jb55> how would you find a bug like this? is there tracing diagnostics you can turn on to see these messages?
+13:10 < jnewbery> aj: do you want to comment on how you found the bug?
+13:10 < aj> so what happened is i ran "getmempoolinfo" and noticed that it was empty -- figured something weird was going on and mentioned it on irc
+13:10 < aj> at which point people said "no, nothing weird is going on, your node is just having problems" or something similar
+13:11 < aj> so i tried working out what was going on at that point, because my mempool had just like 12 tx's and wasn't getting any more
+13:11 < aj> eventually figured out how to turn net message debugging on to the live system, bitcoin-cli logging '["net"]' or similar
+13:12 < jnewbery> It's a bit scary that this was only discovered by chance. I think there's more testing we could be doing to increase our chances of catching things like this earlier on.
+13:12 < aj> that then showed that i was getting lots of INV messages from peers, telling me that new tx's were around, but i was never actually sending the GETDATA back to get the details of those transactions
+13:12 < jnewbery> that's a good tip. We have different categories of logging that can be enabled and disabled at run time. Use the `logging` RPC.
+13:12 < aj> i then tried staring at code to figure out what was wrong, and made guesses. also tried attaching gdb to the running process, but that caused it to crash, and when i restarted everything was fine
+13:13 < aj> talking about it on irc, people were wondering if i was connected to hostile peers that were deliberately attacking me; so i checked against gmaxwell's banlist, but didn't get any matches, and noted down the peers i was connected to
+13:13 < aj> (i run my node behind NAT and not on tor, so i've only got 8 outgoing peers, no incoming peers)
+13:14 < aj> once it restarted and was working fine, i manually reconnected to the peers that didn't work before, to check they did work now, and they did so i took that to mean it wasn't a case of hostile peers, but a bug on my end
+13:14 < jonatack> aj, did the custom logging you mentioned in your PR shine light too? https://github.com/bitcoin/bitcoin/pull/15776#issuecomment-483916240
+13:14 < Lightlike> In 15776, there is a rather special situation, with the parent of the tx already expired from the relay set, leading to NOTFOUND msg being sent. But wouldn't you need to have 100 different children tx, each with expired parents to reach MAX_PEER_IN_FLIGHT, multiplied by the number of peers (8) to be cut off completely. Is that not extremely unlikely?
+13:14 < aj> in the log of #15776 i think you can see some of my guesses and corrections to that
+13:15 < aj> Lightlike: it's cumulative, so you use up 1 slot with one tx, then it happens against and you use up another slot
+13:16 < aj> Lightlike: and it's not that the parent expires from the relay set, it's that you receive a child you don't have a parent for (because you've just restarted your node after being down for a while, eg), and then you ask the peer for the parent even though they never told you they had the parent, so it's not in the collection of tx's they'll relay to you even though it's in the mempool
+13:16 < merehap> Beyond more testing, is there something like using better concurrency primitives or better code structuring to reduce the likelihood of concurrency problems like these? I feel like I've seen several different concurrency bugs file against core. Since concurrency bugs are so difficult to discover and debug, it seems scary if there isn't a more systematic approach to preventing them.
+13:17 < merehap> filed* against
+13:17 < aj> Lightlike: (also, if the parent isn't in the mempool, but is in your utxo set, but the first two outputs from the transaction have already been spent, then you'll redundantly ask for the tx and get a notfound back)
+13:18 < jnewbery> Good context to know is that if a peer asks you for a tx with GETDATA, you'll only send that tx if it's in a data structure called MapRelay. You won't fish the tx out of the mempool if it's not in MapRelay
+13:18 < aj> jnewbery: (except you will if you're working with an SPV peer doing bloom filters)
+13:19 < jnewbery> ah, yes. Thanks!
+13:19 < aj> jnewbery: (there's always an exception. except when there isn't...)
+13:19 < jnewbery> merehap: I wouldn't really categorise this as a concurrency bug. This is more like a resource leak (where the resource is txs in flight from a peer)
+13:20 < MarcoFalke> Yeah, it is a logic bug. The code was written under the wrong assumptions (missing some "edge" cases)
+13:21 < pinheadmz> so the story is: INV(tx)-->    <--GETDATA(tx)   (tx is dropped from relayset)   NOTFOUND(tx)-->      ?
+13:21 < jnewbery> pinheadmz: yes
+13:21 < pinheadmz> all three, the same tx - not GETDATA(parent of tx)
+13:21 < jnewbery> (although of course we can't rely on the peer sending a NOTFOUND)
+13:22 < aj> INV(tx) GETDATA(tx) TX(txdata) is normal
+13:22 < pinheadmz> so is the tx not really in the maprealy from thebeginning? or is it actually dropped in the time between INV and GETDATA ?
+13:23 < aj> INV(tx) GETDATA(tx) TX(txdata) GETDATA(tx.parent) NOTFOUND is common though, because our side thinks "if they have tx, they must have the parent" and their side, running the same software, thinks "i didn't INV tx.parent, so i won't send it"
+13:23 < jnewbery> INV(tx_child) --->
+13:23 < jnewbery> <--- GETDATA(tx_child)
+13:23 < jnewbery> TX(tx_child) --->
+13:23 < jnewbery>                   I don't have this child's parents!
+13:23 < jnewbery> INV(tx_parent) --->
+13:23 < jnewbery> <--- GETDATA(tx_parent)
+13:23 < jnewbery> TX(tx_parent) --->
+13:23 < aj> jnewbery: the special logging mostly proved the guesses i was making was wrong, fwiw
+13:24 < jb55> I found reading the struct TxDownloadState comment helpful for anyone new to this part of the codebase
+13:24 < jnewbery> oh sorry, that second INV shouldn't be there
+13:24 < jnewbery> correction:
+13:24 < jnewbery> INV(tx_child) --->
+13:24 < jnewbery> <--- GETDATA(tx_child)
+13:24 < jnewbery> TX(tx_child) --->
+13:24 < jnewbery>                   I don't have this child's parents!
+13:24 < jnewbery> <--- GETDATA(tx_parent)
+13:24 < jnewbery> TX(tx_parent) --->
+13:25 < jnewbery> that last TX should actually be a NOTFOUND
+13:25 < pinheadmz> thanks! visual aids are so helpful :-)
+13:25 < pinheadmz> and why wouldnt the first node have the parent? bc it jsut expired? time-wise?
+13:25 < jnewbery> expired from the MapRelay but still in the mempool, or cofirmed in a block
+13:26 < Lightlike> but if it was confirmed in a block, wouldn't we know about this and not request it?
+13:27 < aj> so one thing i wonder is about sdaftuar's question, "switch the uses of GetTimeMicros() in the logic to GetTime() so that we can mock it"; it doesn't seem to make a lot of sense to measure timeouts in the seconds-minutes range with microseconds; but using non-mocktime for "peer has been idle" in general (see #9606) certainly makes sense i think
+13:27 < jnewbery> Lightlike: The peer might have it confirmed in a block, but we don't have the block yet? Not sure
+13:28 < aj> Lightlike: there's a bug in the handling of missing parents. when actually testing the transaction the logic is done right (in AcceptToMempool), but when that fails, it doesn't say what tx's exactly are missing
+13:29 < b10c> jnewbery: and the "expired from the MapRelay but still in the mempool" was introduced in #14897?
+13:29 < aj> Lightlike: so when the net_processing code works that out to try to ask for the parents (which generally won't work anyway) it tests to see if the parent is in the mempool, or txid:0 or txid:1 are in the UTXO set
+13:29 < aj> Lightlike: but if the output we're looking for is txid:3 and txid:0 and txid:1 are spent, we'll get a false positive
+13:30 < jnewbery> b10c: no, I believe that's been normal behaviour since earlier than that
+13:30 < aj> i think the tx's in maprelay are kept around so even if the tx expires from the mempool (by being mined, or because the mempool is full) it's still able to be relayed for the 15m's since being INV announced
+13:31 < jnewbery> the problem introduced by 14897 is adding txs to the node's m_tx_in_flight and then there being edge-cases where they're never removed
+13:32 < b10c> jnewbery: ah I see
+13:33 < aj> so previously, it would've just been "we sent a GETDATA and got a NOTFOUND? not big deal, moving on". but now it means a data structure doesn't get cleared, and eventually a limit gets hit, and behaviour changes
+13:34 < jb55> p2p code is scary
+13:34 < jnewbery> jb55: yes!
+13:34 < jb55> so much state
+13:34 < jonatack> can you expand on the missing testing and mocktime?
+13:35 < jnewbery> we talk a lot about consensus code being subtle and difficult, but problems in p2p code can be just as dangerous
+13:35  * jb55 considering spending more time looking at p2p PRs
+13:36 < jnewbery> luckily, I think there are more parallels between p2p code and other software domains (eg networking, telecoms), so for people with experience in those areas then p2p might be somewhere you want to look at more.
+13:37 < jonatack> * jb55: there are todos in https://github.com/bitcoin/bitcoin/pull/9606/files
+13:37 < jnewbery> jonatack: there are various calls for getting the current time used by bitcoind. GetTime() can be overridden by setmocktime but GetTimeMicros() always uses your system time
+13:38 < jnewbery> I *think* that's just historic. I can't think of any good reason for it
+13:38 < jnewbery> but it does mean that code that uses GetTimeMicros() can't be tested using mocktime
+13:39 < aj> jnewbery: i think if you used mocktime for everything you might get a bug where "setup test, connect peers. mocktime += 1 hour. oh all the peers have been non-responsive for an hour, mass disconnect. tests fail"
+13:39 < aj> jnewbery: GetTimeMicros() is used in bunches of places for "here's how long this piece of code took to run" logs, which is pretty reasonable too
+13:39 < jonatack> thanks! wdyt about sdaftuar's last comment/question
+13:40 < jonatack> could this be tested in compacted mocktime
+13:41 < Lightlike> A question concerning the fix in #15834: Now we clear m_tx_inflight_it after our peer first sends an INV(tx), but is totally unresponsive after GETDATA(tx) (not even NOTFOUND). At the same time we accept other transactions from this peer. is there a legit reason for our peer to behave like this besides censoring certain transactions (so that we don't disconnect instead)?
+13:42 < aj> i think it'd make sense to switch it to mockable GetTime,interested in what other people think, or if anyone sees any problems with that
+13:42 < jnewbery> on the face of it, it seems reasonable. I can't immediately think of any reason that it'd be a problem
+13:44 < aj> Lightlike: legit reasons: could be buggy, or maybe there's bugs in our logic where we're taking much longer to send the GETDATA than we think and it's actually totally reasonable for it to have expired, could be others
+13:44 < jnewbery> Lightlike: unreliable connection?
+13:45 < aj> jnewbery: unreliable with the bounds TCP/tor provides?
+13:45 < jnewbery> In general, I think we want to be careful about introducing behaviour that could turn a relatively small bug into something that causes a bunch of peers to disconnect
+13:45 < aj> yeah, that^^^
+13:47 < Lightlike> yes, that makes sense :-)
+13:49 < jnewbery> aj: yeah TCP/tor should give us reliable messages
+13:49 < jnewbery> jonatack: I hope it can be tested with mocktime, or in some way that doesn't require very long-running tests. The problem with long-running tests is that no-one ever runs them
+13:50 < jnewbery> (and we explicitly disable them from our Travis CI because they'd cause the run to time out)
+13:50 < jonatack> jnewbery: this
+13:51 < jnewbery> A few other random thoughts I had about this PR: I liked aj's update to the getpeerinfo RPC here: https://github.com/bitcoin/bitcoin/pull/15776/files#diff-618d3a4f4fc0dc851ec29218c445c148R109
+13:52 < jnewbery> Because I like monitoring in general
+13:53 < jnewbery> I'd also love to see more work on stuff like https://forkmonitor.info/nodes/btc to provide live monitoring of the network
+13:53 < jnewbery> I know that james o'beirne is planning to do some work on that, so if it's something that interests anyone here, please reach out to him
+13:54 < jnewbery> Another thing that I'd like to see is more stress testing. Resource leaks like this are really difficult to catch in deterministic, short-running tests
+13:55 < jnewbery> Any final questions?
+13:55 < aj> https://github.com/ajtowns/bitcoin/commits/201904-reduce-notfounds  -- is a branch i was playing with to reduce the underlying cause for getting notfounds btw. i haven't opened a PR for it yet, but it might be interesting to look at
+13:55 < jnewbery> aj: cool, thanks!
+13:56 < jnewbery> ok, seems like there aren't any more questions
+13:56 < jnewbery> This was quite a step up from the previous two weeks in terms of complexity - I'd be interested in what people thought about reviewing.
+13:57 < jnewbery> Net Processing is a tricky area. Probably second only to Validation in terms of subtlety and complexity. It'd be great if we had more eyes on it.
+13:58 < jnewbery> ok, thanks everyone, and thanks especially to aj!
+13:58 < jonatack> Good choice of PR -- I'm learning with these forays into new (for me) places in the codebase
+13:58 < Lightlike> I found this very interesting (the p2p code was new to me), but also definitely harder to understand than the one last week. Thanks!
+13:58 < merehap> jnewbery, aj: Thanks!
+13:58 < jonatack> Thanks aj and jnewbery!
+13:59 < aj> the p2p code was new to me too when trying to debug this :)
+13:59 < jnewbery> let's wrap it up there. As always, feel free to ping me if you have any thoughts about these.
+13:59 < pinheadmz> jnewbery: thank you! this is great, informative, fun
+13:59 < pinheadmz> to the moon!
+</pre>
+</IRCWRAPPER>
+
diff --git a/docs/review-club/meetings/2023-06-15-976.md b/docs/review-club/meetings/2023-06-15-976.md
new file mode 100644
index 0000000000..4213100afe
--- /dev/null
+++ b/docs/review-club/meetings/2023-06-15-976.md
@@ -0,0 +1,33 @@
+---
+layout: ReviewClubMeetingLayout
+date: 2023-06-15
+title: "Reimplement Wallet, ElectrumExt and Esplora{Async}Ext with redesigned structures"
+pr: https://github.com/bitcoindevkit/bdk/pull/976
+authors: [evanlinjin]
+components: []
+host: evanlinjin
+status: past
+commit: 75f8b81
+commitLink: https://github.com/evanlinjin/bdk/tree/75f8b81d58a985669ce7302fe235ad68eddc0d47
+---
+
+<ReviewClubMeetingHeader :date="$page.frontmatter.date" :pr="$page.frontmatter.pr" :authors="$page.frontmatter.authors" :host="$page.frontmatter.host" :commit="$page.frontmatter.commit" :commitLink="$page.frontmatter.commitLink"/>
+
+## Notes
+
+- The `bdk_chain` module has been redesigned, as specified in [`issue#895`](https://github.com/bitcoindevkit/bdk/issues/895). This PR uses these redesigned structures to reimplement `bdk::Wallet` and the electrum/esplora examples.
+- The redesigned structures includes `TxGraph`, `IndexedTxGraph` and `ChainOracle`. `TxGraph` is changed to include anchors and last_seen for transactions. `IndexedTxGraph` combines `TxGraph` with an indexer and it provides a convenient way of adding data into `TxGraph` and indexing the data atomically. The `bdk_chain` module contains both the `SpkTxOutIndex` and `KeychainTxOutIndex` indexers. `ChainOracle` determines whether an anchor exists under a given tip.
+
+## Questions
+
+1. What is the [`Anchor`](https://github.com/evanlinjin/bdk/blob/75f8b81d58a985669ce7302fe235ad68eddc0d47/crates/chain/src/tx_data_traits.rs#L39-L56) trait?
+2. For `ElectrumExt::scan` and `EsploraExt::scan`, what are each of the inputs used for?
+3. For `ElectrumExt::scan`, how does [`populate_with_outpoints()`](https://github.com/evanlinjin/bdk/blob/75f8b81d58a985669ce7302fe235ad68eddc0d47/crates/electrum/src/electrum_ext.rs#L346-L406) work? Why is it so complicated?
+4. For `ElectrumExt::scan` and `EsploraExt::scan`, we first loop through the `local_chain` backwards. What is the purpose of this loop?
+    * For electrum: [`prepare_chain_update()`](https://github.com/evanlinjin/bdk/blob/75f8b81d58a985669ce7302fe235ad68eddc0d47/crates/electrum/src/electrum_ext.rs#L272-L307) (which is called by `scan`).
+    * For esplora: [`scan()`](https://github.com/evanlinjin/bdk/blob/75f8b81d58a985669ce7302fe235ad68eddc0d47/crates/esplora/src/blocking_ext.rs#L80-L105).
+4. In the old API, we had the `ChainGraph::inflate_update()` method for updates from electrum. What is the purpose of this? What is the replacement of this in the new API?
+5. Why is the redesign a ***better API***? What are the trade-offs?
+
+## Meeting Log
+
diff --git a/docs/review-club/meetings/README.md b/docs/review-club/meetings/README.md
new file mode 100644
index 0000000000..ee299f7ad5
--- /dev/null
+++ b/docs/review-club/meetings/README.md
@@ -0,0 +1,19 @@
+---
+layout: ReviewClubLayout
+title: Meeting Notes
+---
+
+<div class="meeting-list-container">
+    <h2>Meetings</h2>
+    <div class="meetings-container">
+        <ul class="meeting-list">
+            <template v-for="page in $site.pages">
+                <li v-if="page.frontmatter.layout === 'ReviewClubMeetingLayout'">
+                    {{ page.frontmatter.date | formatDate }}
+                    <span id="text-separator">»</span>
+                        <a id="meeting-link" :href="page.path">#{{ page.frontmatter.pr.split("/").pop() }} {{ page.frontmatter.title }}</a>
+                </li>
+            </template>
+        </ul>
+    </div>
+</div>
diff --git a/docs/review-club/your-first-meeting.md b/docs/review-club/your-first-meeting.md
new file mode 100644
index 0000000000..63b00ad9ef
--- /dev/null
+++ b/docs/review-club/your-first-meeting.md
@@ -0,0 +1,40 @@
+---
+layout: ReviewClubLayout
+title: Attending your first PR Review Club
+---
+
+## Attending your first PR Review Club
+
+If you’re thinking about attending PR Review Club, welcome! We love new
+participants. Below is information to help you get started as a first-timer.
+
+The club meets on {{ $meetingDay }}s at {{ $meetingTime }} in
+<a :href="$meetingPlace">Discord</a>. During the session, a BDK
+developer will host a 60-minute discussion on a BDK pull request. [The
+code of conduct](/review-club/code-of-conduct) details the
+behavior we expect from all participants.
+
+You’ll get the most out of Review Club if you’ve reviewed the PR going into the
+meeting, but it’s definitely not mandatory in order to attend. You can always
+show up as an observer. If you're worried (don't be!), read the meeting log of a
+[past PR Review Club](/review-club/meetings/). You'll see it's
+very casual.
+
+If you’d like to more actively participate, you should clone the [BDK
+repository](https://github.com/bitcoindevkit/bdk). You should also check out and
+build the PR branch locally and run all tests. Take time to review the code changes and
+read the comments on the PR.
+
+There are also notes and questions you can review and prepare. Make a note
+of any questions you want to ask.
+
+The meeting will begin with a “hi” from that week’s host. Feel free to respond with “hi” 
+so people know you’re at your keyboard and participating. The host will poll everyone on
+whether they've reviewed the PR (y/n). Don't feel embarrassed to say "n".
+
+Questions may be asked at any time. If you’d like to ask a question, 
+there's no need to ask permission. If the question is off-topic, the host will kindly
+let you know. The host will end the session at the end of the hour. 
+Thanking the host at the end of the meeting is always appreciated!
+
+**We look forward to having you at the next PR Review Club!**
\ No newline at end of file
diff --git a/package-lock.json b/package-lock.json
index 2e0ce795d4..322da91608 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -11,6 +11,7 @@
       "devDependencies": {
         "@spiralbtc/vuepress-devkit-theme": "^0.5.0",
         "broken-link-checker": "0.7.8",
+        "he": "^1.2.0",
         "serve": "14.2.0",
         "start-server-and-test": "2.0.0",
         "vue": "2.7.14",
@@ -11661,12 +11662,6 @@
         "javascript-stringify": "^1.6.0"
       }
     },
-    "node_modules/markdown-it-container": {
-      "version": "2.0.0",
-      "resolved": "https://registry.npmjs.org/markdown-it-container/-/markdown-it-container-2.0.0.tgz",
-      "integrity": "sha512-IxPOaq2LzrGuFGyYq80zaorXReh2ZHGFOB1/Hen429EJL1XkPI3FJTpx9TsJeua+j2qTru4h3W1TiCRdeivMmA==",
-      "dev": true
-    },
     "node_modules/markdown-it-emoji": {
       "version": "1.4.0",
       "resolved": "https://registry.npmjs.org/markdown-it-emoji/-/markdown-it-emoji-1.4.0.tgz",
@@ -18977,6 +18972,12 @@
         "markdown-it-container": "^2.0.0"
       }
     },
+    "node_modules/vuepress-plugin-container/node_modules/markdown-it-container": {
+      "version": "2.0.0",
+      "resolved": "https://registry.npmjs.org/markdown-it-container/-/markdown-it-container-2.0.0.tgz",
+      "integrity": "sha512-IxPOaq2LzrGuFGyYq80zaorXReh2ZHGFOB1/Hen429EJL1XkPI3FJTpx9TsJeua+j2qTru4h3W1TiCRdeivMmA==",
+      "dev": true
+    },
     "node_modules/vuepress-plugin-disqus": {
       "version": "0.2.0",
       "resolved": "https://registry.npmjs.org/vuepress-plugin-disqus/-/vuepress-plugin-disqus-0.2.0.tgz",
@@ -29714,12 +29715,6 @@
         }
       }
     },
-    "markdown-it-container": {
-      "version": "2.0.0",
-      "resolved": "https://registry.npmjs.org/markdown-it-container/-/markdown-it-container-2.0.0.tgz",
-      "integrity": "sha512-IxPOaq2LzrGuFGyYq80zaorXReh2ZHGFOB1/Hen429EJL1XkPI3FJTpx9TsJeua+j2qTru4h3W1TiCRdeivMmA==",
-      "dev": true
-    },
     "markdown-it-emoji": {
       "version": "1.4.0",
       "resolved": "https://registry.npmjs.org/markdown-it-emoji/-/markdown-it-emoji-1.4.0.tgz",
@@ -35653,6 +35648,14 @@
       "requires": {
         "@vuepress/shared-utils": "^1.2.0",
         "markdown-it-container": "^2.0.0"
+      },
+      "dependencies": {
+        "markdown-it-container": {
+          "version": "2.0.0",
+          "resolved": "https://registry.npmjs.org/markdown-it-container/-/markdown-it-container-2.0.0.tgz",
+          "integrity": "sha512-IxPOaq2LzrGuFGyYq80zaorXReh2ZHGFOB1/Hen429EJL1XkPI3FJTpx9TsJeua+j2qTru4h3W1TiCRdeivMmA==",
+          "dev": true
+        }
       }
     },
     "vuepress-plugin-disqus": {
diff --git a/package.json b/package.json
index 23bbc94781..8fd84e45c7 100644
--- a/package.json
+++ b/package.json
@@ -31,6 +31,7 @@
   "devDependencies": {
     "@spiralbtc/vuepress-devkit-theme": "^0.5.0",
     "broken-link-checker": "0.7.8",
+    "he": "^1.2.0",
     "serve": "14.2.0",
     "start-server-and-test": "2.0.0",
     "vue": "2.7.14",