Weekly Check-in: Week of 2026-03-23

[payjoin-bot]

Weekly standup — each contributor has a thread below with auto-gathered activity.

Reply to your thread by end-of-day Monday (your timezone). Copy the template below and fill it in:

### Shipped
<!-- Add anything the bot missed: design work, specs, conversations, off-GitHub contributions. Correct any mistakes. Skip if the bot covered everything. -->

### Focus
What are you working on this week?

### Bottleneck
What is the single biggest bottleneck in progress toward your greater goal?
Name your goal. Name the constraint. Name who or what can unblock it.

You are encouraged to comment on each other's threads if clarification would help, if you can address a blocker, or otherwise to go a little deeper.

Participated: @DanGould, @spacebear21, @benalleng, @chavic, @zealsham

[payjoin-bot]

DanGould

@DanGould

Shipped

PRs merged:

• Async standup v2

PRs reviewed:

• Document OHTTP relay random selection guidance
• Remove pad plaintext from hpke

Issues opened:

• Harden mailroom against metadata side channels

Auto-detected signals:

• PR has requested changes: Make corepc-node optional in payjoin-test-utils

[DanGould]

The standup doesn't capture the manual integration QA (Cake/BB bug diagnosis), migration spec writing, or LLM research orchestration. Those are arguably the highest-value things I did and make me question some of my process & have suggestions on how to improve this bot & standup further.

Shipped

• local deep research ai orchestration. I've got an adversarial bot pipeline that makes multiple rounds of forward research and then pokes holes in it. That's what found Harden mailroom against metadata side channels #1421. I should probably schedule a study club or post a video of this or writeup. based on strategy in this tweet: https://x.com/systematicls/status/2028814227004395561.
• Our payjoin.org rss feed -> buttondown auto email pipeline. @thebrandonlucas and I sent out the first one.
• Manually tested BB/Cake integration in both directions and handed off an upgrade spec to @benalleng

Focus

• Reporting: Grants need reports. These are outlined now, but they need to be delivered.
• Tax season: I need to spend some time doing and automating Foundation finances. Some will transfer to our BTCPayServer treasury strategy

Bottleneck

• In doing the reporting I realize the integrations are quite behind I think because 1. our ambition is very wide wrt that context of many attempts 2. we're still not at rust-payjoin 1.0 and the api changes and 3. we're context switching w/o singular group focus on one at a time. Need to get aligned with @spacebear21 about the confluence of QA-ing BB/Cake, 1.0, and what our arc going into Q2 is going to look like for this to be a priority
• I just need to spend ~3+ days away from engineering / research this week strictly on Finances & Ops to get that systematized for Q2 before our board meeting. Going to have to rely on serious delegation
• No longer a bottleneck but worth noting: i see lots happening on the research front and in general we are ahead of expectations set out in proposals to other orgs. This became legible in the past few weeks.

Standup coverage gaps

A few things this automation misses that we could address:

1. Direct commits to tx-indexer, research-docs, multiparty-protocol-docs @arminsabouri's biggest outputs this week (cost
   function abstract framework on Mar 22, nSequence/nLockTime fingerprint detection in tx-indexer) don't show up because they're direct pushes, not PRs. Two options: (a) Armin starts using PRs even for solo repos so the bot picks them up, or (b) we and track commits with the scraper. I have a pretty strong preference toward (a) because PRs leave a better paper trail & space for rationale anyway if not just a natural grouping, and it's not a huge behavior change. I don't really care if the PRs actually have written context beyond the commit message or a formal review process beyond Armin hitting Merge. And I don't mind if they have merge commits or rebase / merge or squash / merge. That's Armin's domain and I'm sure the commit messages suffice. I think even an alias / small bash program could chain git commit & some gh commands to make and merge a PR without any ceremony in this type of circumstance. My focus is fixing this pipeline so our bot picks up this good work:

• Cost function abstract framework: payjoin/multiparty-protocol-docs@762f565 on cost-function-abstract branch (Mar 22)
  • payjoin/multiparty-protocol-docs@762f565
• nSequence/nLockTime fingerprint detection: payjoin/tx-indexer@0c840cd (Mar 17)
  • payjoin/tx-indexer@0c840cd
• Example binary: payjoin/tx-indexer@10de709 (Mar 17)
  • payjoin/tx-indexer@10de709

2. Cross-org repos — uniffi-dart (Uniffi-Dart org) had 2 merged PRs this week including a bugfix from a new external contributor.
   The bot only watches payjoin/*. We should add Uniffi-Dart/uniffi-dart to the scrape list. Any other repos missing?

3. QA / manual testing work @benalleng's most important work right now (Cake/BB migration execution) doesn't produce GitHub
   events until a PR lands. Same for my integration testing. The Shipped template is left blank so we add this, but I also wonder if a habit of pushing some of this markdown stuff / doing more comms on GitHub here is something I can lead by example that makes the automation and our discussion here easier.

4. I like "Auto-detected signals" is actually good — e.g @zealsham's PR Sanitize shortid when storing metrics #1434 showing as a signal "shipped" means we track when stuff is in progress but only celebrate when it actually lands. I think that's the right priority. Don't say PRs reviewed if only thumbed up react. BOT: look at the review date pls. A thumb up is not a notif. Whoever solves this needs to figure out what makes a review and what not.

5. I like that this is a discussion with comments and threads a whole lot more.

6. maybe some distinction from the bot's auto-detected signal text for draft vs open PR. I don't usually treat drafts as "awaiting review" but right now our bot does.

7. It'd be cool if ~anyone not on the list could opt in with their own thread comment here or elsewhere to trigger the bot to do a summary of their activity if they felt so inclined without making them feel compelled.

8. cool to make compile notify in discord / our general pop chat

9. Somehow link this week's check-in to last week's check-in. Maybe the compile bot could cross-check?

[DanGould]

• @arminsabouri said he will make PRs
• @chavic please add yaml Cross-org repos — uniffi-dart
• Ben's gonna do a draft PR
• Dan NEEDS to schedule AI orchestration mob programming after April 7

[payjoin-bot]

spacebear21

@spacebear21

Shipped

PRs reviewed:

• Fingerprinting edits
• Make corepc-node optional in payjoin-test-utils
• Cover missing C# FFI validation paths
• Add wallet fingerprinting blog
• Add fingerprinting blog
• Unpin the nix crane dip from a specific commit
• Add db entry metrics
• Request size limiter
• Remove pad plaintext from hpke

Issues opened:

• Be specific about error handling for methods that don't return state transitions

[spacebear21]

Shipped

• BOSS payjoin showcase with @benalleng

Focus

• Publish non-rc rust-payjoin release. In hindsight 1.0rc was a mistake, the result is that it's been 8 months since the last payjoin release. 0.24 is fairly outdated, and 1.0.0-rc.2 is not easily discoverable. Q: Do we make this release 0.25 and keep bumping minor releases while getting stricter about not breaking things, OR bite the bullet and ship an imperfect 1.0.0 and start observing semver appropriately. I lean towards the latter.
• Async-compatible state transitions API FFI callback traits force non async #1389
  • note this would be an potential 1.1.0 feature if we go with a 1.0 release.
• Mailroom metrics

Bottleneck

• PR Review is taking up a lot of my time. If you are waiting for my review, please consider reviewing pending PRs from other contributors to help distribute the load. @chavic @zealsham
• Bull Bitcoin Mobile plans to merge bdk-dart in the next sprint. payjoin-dart will follow after that.

[DanGould]

• Re: 1.0, does this list still stand? We probably could have set a calendar item or used the strict milestone as a review period https://github.com/payjoin/rust-payjoin/milestone/1. I think me doing my planned monthly writeup could catch this in theory, too. RC was me cargo culting BDK even though I'm not sure that 1.0 process was examplary. I have. BDK 1.0 2023 shirt when I think it actually landed in 2025, and then 2.0 came out mere months later. The other issue with 1.0 is making sure we're on LTS rust-bitcoin, which I think is 0.32.
• PR review overload is probably insufficient automation, missing documentation, or a trust/delegation gap. Which one of these is most likely?

[DanGould]

• we know 1.0 is still quite rekt and people shouldn't rely on stability until milestone 1.0 so minor release first to unstuck
• ohttp.achow101.com vs payjoin.achow101.com? @benalleng will QA
• API 1.0 stuff in mob review
• LDKNode review is gonna be our next one

[payjoin-bot]

arminsabouri

@arminsabouri

Shipped

PRs merged:

• Add wallet fingerprinting blog

PRs reviewed:

• Async client bitcoind network parsing
• Split resume session relays
• Async standup v2
• lock inputs via strategies and unlock early due to payment anxiety
• Add coalition formation abstract protocol.

Auto-detected signals:

• PR has requested changes: Add semi-honest overview
• PR has requested changes: Look up RK instead of looping

[arminsabouri]

• Still doing too much. Attempting to multi task. End up losing context.
• Spent most of sat reading about Fuzzy message detection FMD. Results are inconclusive but will post notes soon
• Making edits to the fingerprinting blog -- Making this main priority for today.
• Pairing with Yuval on cost functoin write up
• Co spend proposal scaffolding in the simulator

[DanGould]

• Silent Payments receiver scanning in a mobile wallet i.e. Blindbit is the threshold before we revisit SilentPayjoins

[DanGould]

• Simulations co-spend proposal scaffolding is the focus precedent over everything else. One thing to ship this week <- impl these ideas into sim.
  • easiest thing to achieve is co-spend evaluated against cost function -> satoshi amount. Literally running this function is the goal

[payjoin-bot]

benalleng

@benalleng

Shipped

PRs reviewed:

• chore: update flake.lock
• Document OHTTP relay random selection guidance

[benalleng]

Shipped

• Found a critical bug in bitcoind-async-client and made a fix to allow using the payjoin-cli in testnet3 and mainnet here
• Merged Unpin the nix crane dip from a specific commit #1419 early today to allow nix crane to no longer be pinned.

Focus

• Met with Dan to sync on the Cake wallet BB mobile QA progress. I managed to create an internal script that can successfully run a BB mobile sender w/ payjoin-cli receiver but I need to clean it up to create perhaps a weekly github action to do this check regularly to check for regressions.
• Afterwards I need to move on to sync with Konstantine on some actionable tasks to get Cake working as it cannot do a payjoin with either BB mobile or payjoin-cli. Dan sent me his theory on why it is not working at the end of the week last week but I am not sure this is right.

Blockers

• Are we concerned there will need to be a lot of reengineering with these integrations both using payjoin-flutter instead of more modern bindings?
• A direct contact with Konstantin other than making a bunch of issues in Cake wallet

[DanGould]

• Suggests opening bbmobile<>payjoin-cli QA pipeline as draft
• Integration issues with cake if not doc'd with cake, doc on the integration tracker
• Won't dump more than 90 more minutes into payjoin-flutter related problems on BB mobile, will focus upgrade to BB mobile w/ payjoin ~1.0
• Dan promises to share his draft on top of spacebear's with bbmobile update

[payjoin-bot]

chavic

@chavic

Shipped

PRs merged:

• Cover missing C# FFI validation paths

PRs reviewed:

• Refactor OhttpKeysClient

Auto-detected signals:

• PR awaiting review: Expose Receiver Modification Errors
• PR awaiting review: Expose Sender Input Index
• PR awaiting review: Expose V2 Transport Error Kinds
• PR awaiting review: Expose Retryability Metadata
• PR awaiting review: Preserve Persisted Error Classification
• PR awaiting review: Expose Receiver Error Kinds
• PR awaiting review: Expose JSON reply accessors

[DanGould]

• Perhaps consider opening Mass AI drafts (is that what these are?) on your personal fork first so they don't land here. That's what I've been doing and even then I feel like I'm pushing some slop here unnecessarily.

[chavic]

They're the items on #1264 that I wanted to get out of the way, since I kept pushing the list. I was pushing it in terms of how fast I could get with codex, will give them a second look

[chavic]

But the extra layer of quality is the right step; I'll adopt that approach too

[DanGould]

def balance between posting early & posting too much. this Zigzag from not posting before to posting too much now is progress & growth 👍

[DanGould]

Please post notes to integrations tracker, seems like written comms about internal status / approach is the blocker actually.

[payjoin-bot]

zealsham

@zealsham

Shipped

No activity found.

Auto-detected signals:

• PR awaiting review: Sanitize shortid when storing metrics
• PR has requested changes: Request size limiter
• PR has requested changes: Demonstrate failure handling with fallback TX broadcast
• PR has requested changes: Add config saving to payjoin-cli

[zealsham]

Focus

• still working on the cardinality count for shortids using hyperloglog
• Revisit Payjoin-cli should cache ohttp-keys for re-use #1035 and complete implementation on review changes
• any further changes on open Pr's

Bottleneck

• Request size limiter #1410 needs review from @spacebear21
• Add db entry metrics #1412 needs an approval from another other person other than spacebear
• a few gaps in my understanding of hyperloglog to figure out if a custom implementation or using https://crates.io/crates/hyperloglog is more ideal
• Also how to integrate it with opentelemetry (a draft PR would be push latest wednesday)

[payjoin-bot]

Mshehu5

@Mshehu5

Shipped

No activity found.

Auto-detected signals:

• PR has requested changes: lock inputs via strategies and unlock early due to payment anxiety

[DanGould]

Also working on BDK-CLI changes. Definitely just post ASAP to repond to tvpeter so that you know what his opinion is on what NEEDS to get done vs what can wait.

[payjoin-bot]

0xZaddyy

@0xZaddyy

Shipped

PRs reviewed:

• lock inputs via strategies and unlock early due to payment anxiety

Auto-detected signals:

• PR has requested changes: Implement fee savings and privacy metrics for payjoin outcomes