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

[DanGould]

@DanGould

• Shipped:
  • Async Accountability Experiment: Add async weekly standup automation #1346
    • produced this issue
    • still has probs incl
      • format should be fenced for easy copy/paste
      • I didn't get notified in GH bc technically I'm the author even if a bot did it
      • we're making pollution of closed issues vs issue to discussion conversion
    • h/t armin letting this flow through and being willing to embrace messy iteration
  • Bring Robots deeper into our process
    • Improve AGENTS.md guidance #1344
    • Add treefmt and codespell (CI requirements) to nix dev shells #1334
    • Add AGENTS.md for AI and contributor guidance #1333
  • Readying payjoin-mailroom for Release
    • Drafted a mailroom infrastructure runner info packet. Available upon request.
    • Fix flaky test_prune by using deterministic timestamp manipulation #1338 first totally agentic PR
    • Gate V1 protocol behind runtime feature flag #1336
    • Add GeoIP region filtering and address blocklist #1337
    • Add opt-in access control for infrastructure operators #1330 (push stuff that doesn't work out sometimes)
  • payjoin.org updates
    • Add 501c3 press release in /press payjoin.org#122
    • Donate page payjoin.org#123
    • 501c3 payjoin.org#124 blog post
    • Updated Btrust logo payjoin.org#125
• Focus:
  • By the end of the week I'd like the robots to be working for us in a productive (i.e. we at least learn lessons and don't produce more work than we consume) while I sleep for at least an hour straight two nights in a row. This supersedes other very important work because the whole paradigm of software engineering has shifted and we must stay ahead.
  • Thanks to everyone who tolerated and reviewed my posting slop last week. I took a risk and will continue to do so, so really appreciate the candid feedback like from @spacebear21 "It's definitely way sloppier than your usual code quality 🥲 I reviewed the first four commits and found a lot to be desired." Noted and shifting attempts to using robots for slop cleanup rather than slop production. Asking myself "what if I did the opposite." I have a feeling there's a way to orchestrate better FFI review than what we're doing manually in unfamiliar spaces
  • Mailroom running on our experimental server by EOW
  • Mailroom running on someone else's server by EOW
• Blockers:
  • I need help with the "get mailroom running on someone else's server by EOW" via delegation, @spacebear21 can you help. I know Spacebear is also blocked by this to let us onto solve BBMobile, Boltz bottlenecks. Help wanted.
  • @spacebear21 : are @zealsham 's metrics blocking our ability to have this thing hosted? If so, what's blocking that?
  • Lots of ops demands from me outside of the scope of eng here w.r.t. comms and the website if anyone has capacity to help with our auto mailer while @thebrandonlucas is on leave
  • I have granular, permissioned proton calendar .ics files but don't know how to deliver them to the people. This is much better than discord. If I just have to google, I guess I could but I would rather not. Help.

p.s. to contributors. Your update doesn't have to be this detailed. I like writing. I find it higher leverage for me to spend 30 minutes on this than 30 minutes in a meeting. You may not. If you fill in 3 lines for the bullets that's good!

@chavic

Shipped:

• In rust-payjoin, last week I shipped work across FFI validation Validate FFI primitive inputs + refresh bindings/tests #1263, C# bindings/tooling Add C# language bindings for payjoin-ffi #1318
  , and UniFFI async IO/OHTTP test updates 6c5441f d9cbd21.
• FFI primitive validation + cross-binding test refresh landed in #1263 (merged).
• C# bindings scaffold, generator pinning, workflow, and nuspec landed in #1318 (merged).
• Yesterday’s two commits (6c5441f, d9cbd21) are in #1351 (open): Tokio runtime enablement for UniFFI IO futures and cert-aware OHTTP fetch in C# integration tests.
• In uniffi-bindgen-cs, I worked on UniFFI 0.30 C# gap fixes, and I've moved them to chavic/uniffi-0-30-csharp-gap-fixes locally to start preparing for upstream PR:
  • method-name conflict suffix handling + deep jagged-array allocation fix (e0ecf2ce...)
  • regression fixtures/tests (fc490bae..., including fixtures/regressions/csharp-gap-fixes and TestCsharpGapFixes.cs)
• No additional uniffi-bindgen-cs commits from me on Sunday, Feb 22, 2026.

Focus:

• Settle #1351 through review reworking based on input from @DanGould @spacebear21 .
• Publish chavic/uniffi-0-30-csharp-gap-fixes and open a draft PR upstream with completed uniffi 0.30 upgrades and bug fixes.
• Validate new C# regressions in CI and close remaining UniFFI 0.30 edge cases.
• Support named parameters in generated Dart APIs in Uniffi Dart
• Updating C# tests to validation tests from Validate FFI primitive inputs + refresh bindings/tests #1263
• Getting through Test Gap Tracking issue Test gap tracking issue #1264

Blockers:

• Reviewer bandwidth on cross-language FFI + C# generator/test changes.
• uniffi-bindgen-cs work is currently local-only, so review flow is blocked until branch publish + PR upstream.

@Mshehu5

Shipped:

payjoin/btsim#5
bitcoindevkit/bdk-cli#230 got merged so bitcoindevkit/bdk-cli#242 is ready for review

Focus :
During the mob review session asked Armin about simulator TODO's. He made mention of refactoring of utility functions as priority TODO's currently they are very specific to actions and strategies. He also noted maybe we should minimize for scores and not just maximize

He went through sub transaction model and said we should go through the knapsack mixing paper to better understand this to help in modeling the important parts in to the simulator

Not a focus but I asked if is possible to bring back the research event which was previous held on discord as it will help with better understanding of various new concepts and better understanding of privacy research. Armin noted if we have enough Interest that we can

• Focus is keep reading and understand the paper
• open a PR on refactoring of utility functions

Blockers :
None for now

@zealsham

Focus:

• still implementing the db service, i should have a PR ready by thursday
• adding tower rate-limit once the db services goes in
  Blockers:
• no Blockers

@arminsabouri

Shipped:

• Creating more processes in txindexer repo. Fixed CI + created issues for my self.
• New heuristics UIH - unnecessary Input hueristic tx-indexer#6
• To help track our ongoing research intiatives, I created the research tracking sheet. Hoping to share it this week with the team.
• Spent time with Dan to revise our async / stand up process. Add async weekly standup automation #1346
• Most of last week was spent researching datalayout arch.

Focus:

• Dense Ids + datalayout
• Unfortuantely I may have pre-optimized last week and realizing alot of polymorphizing i did may have been unnecessary. In fact detrimental to the kinds of analysis we want to do. This week i need to re-refactor this so we have a "abstracted" id system. As of writing this not sure what this looks like.
• Produce docs for the datalayout
• Continue to review sim PRs. Keep em coming!
• Cyclical dependencies were a major design consideration when designing the analysis pass pipeline. And we dont really have any tests for this case or docs. I have some concrete examples in mind but these should be convereted to tests after all the dense Id refactors.

Blockers:

• None. There are a lot of refactors going on. Just need to stay focused. If its in a stable place by wed I would like to mob review :)

@benalleng

Shipped:

• Helped review our new Coding overlord contributions.
• Made meaningful progress with [WIP] Payjoin receiver wizardsardine/liana#2011 The CI is still failing but the primary goals of the receiver are complete
• Followed up with some exploration on Discord alternatives. Having seen some other coding libraries I was apart of already jump ship I noted some of their alternatives. Many are the usual suspects but there are a few standouts as they seem better suited for our use. Namely zulip chat for async discussions. there were not many that I saw that also included voice other than the matrix ecosystem

Focus:

• Confirmed that the Bull Bitcoin <-> Cake Wallet Payjoin flow fails and I intend to create a CI that demonstrates the failure. Though I need to do some research for quickly spinning up those applications to test against each other.
• Help refine the Agents files to keep the context that is in them within the MRC (Minimal Relevant Context)

Blockers:

• None. Though I expect the interoperability test between Bull Bitcoin and Cake to be a pain to get working

@spacebear21

Shipped:

• mailroom updates:
  • review and help with access control & related PRs
  • Add payjoin-mailroom to test_local.sh #1339
  • Clarify directory gateway handler #1343
  • Add supported versions to /health response #1348
• FFI updates:
  • review type validation PR
  • review C# bindings PRs
  • Pin wasm-bindgen-cli to 0.2.108 #1349
  • Downstream test bdkdart Uniffi-Dart/uniffi-dart#111

Focus:

• Mailroom: make production ready release. not strictly blocked on anything imo, i think it meets the minimum bar as-is.
• BBMobile: keeping a close eye on replace bdk_flutter with bdk_dart SatoshiPortal/bullbitcoin-mobile#1874. This a) gets uniffi-dart bindings battle-tested in a real flutter app b) will make payjoin dart bindings integration much simpler due to not having to deal with flutter_rust_bridge oddities.
• Make 1.0rc-2 for async persistence inclusion
• What trudge can we automate with AI? Can we have a bot pick up issues labeled with "tech debt"? A bot dedicated to adding test coverage? How much can it help with integrations? etc.

Blockers:

• None

[arminsabouri]

PDK Dev Call Updates – Call notes

Dan

• Published the 501(c) blog post and launched the donation portal.

• Began exploring automation workflows. others are using agents for security-critical and operational tasks effectively.

  • Using the mailroom as a testbed for automation experiments.
  • Target use cases: operational tasks, candidate sourcing, and document generation.

• Gathering feedback from J and others running the mailroom based on the info packet.

• Identified issues with calendar coordination; needs dedicated ownership.

• Noted inefficiencies with compressed context in AI workflows; suggested tighter control loops for managing context windows.

• Reviewed the research overview and timeline; wants a clearer iteration strategy.

• Opened discussion on what qualifies as a “blocker” to improve collaboration.

  • Ben suggested expanding the definition and standardizing it with a reusable template.

Ben

• Handling a large volume of PR reviews generated by AI contributors.

• Following up with additional PRs based on review feedback.

• Completed high-level requirements for the Liana receiver integration.

• Monitoring Discord policy changes; evaluating alternatives like Matrix.

  • Current stance: wait and observe, as Discord is primarily used for calls.

• Investigating interoperability testing between Bull Bitcoin Mobile and Cake Wallet.

  • Identified a reply error when testing BB <-> Cake flows.
  • Goal: automate cross-wallet QA testing.

• Needs coordination with the Cake Wallet team; Dan will help facilitate.

• Current blocker: lack of a standardized mobile test harness.

  • Existing Bull Bitcoin integration tests rely on a simulator.

Chavic

• Continuing work on C# integration and bindings via UniFFI-C#.

• Focused on upstreaming changes rather than maintaining a long-term fork.

  • Plan: open a PR and contact the maintainer early to align on direction.

• Prioritizing parameter handling changes, then addressing Test gap tracking issue #1264.

Shehu

• Working on PRs related to simulation strategies.
• Rebased the BDK persistence PR.
• Currently blocked on reviews from the BDK CLI team.
• Met with Armin for office hours; received paper recommendations and new issues to pick up.
• Requested help from PDK contributors for external PR reviews.
• Team guidance: aggressively tag reviewers when blocked.

Zealsham

• Focused on database metrics tracking.
• Not a blocker for onboarding new mailroom operators, but important for observability.

Spacebear

• Splitting focus across two main areas:

  1. Payjoin Mailroom (combined relay + directory service)
  2. Reviews, including access control and IP-blocking logic

• Reviewing C# bindings.

• Observed that BDK Dart bindings are working via UniFFI-Dart and are already used in Bull Bitcoin Mobile.

  • This provides real-world validation and reduces risk for Payjoin Dart bindings.
  • Flutter requires all calls to be async, influencing binding design.

• Priority question (Dan): if choosing one focus area for release, prioritize the mailroom.

• Current state: most integrations are built off commits on main, not tagged releases.

• High-priority item:

  • replace bdk_flutter with bdk_dart SatoshiPortal/bullbitcoin-mobile#1874
  • Chavic should prioritize this work.

Armin

• The team is not clear and/or has not been convinced why the steps I am taking are the right steps. What is the stopping point for this project ? And how does it fit into the bigger picture or just the simulation ? Some context was provided but still there seesm to be confusion. Written work needs to be produced to explain how this fits into multi party roadmap; however, the first step is to update the research timeline

[arminsabouri]

I am drafting a README for the analysis framework and wanted to share with the hope that it gives other people on the stand up more context on why and what it is that we are building

Qualitative analysis of privacy metrics

We propose an analysis framework for the Bitcoin transaction graph that evaluates the privacy properties of both simulated and real-world privacy protocols but more generally, supports analysis of any transaction graph.

The framework measures the quality of transaction-construction protocols (e.g., CoinJoin and PayJoin) using state-of-the-art wallet clustering techniques and subtransaction-level metrics. Our goal is to deliver a reusable suite of privacy heuristics that researchers and developers can apply to systematically evaluate how well a given construction protocol preserves privacy.

Chain analysis firms likely already rely on similar tooling inside proprietary, closed-source systems. We aim to make these methods open source and accessible to the broader research and development community. Today, no widely available framework --BlockSci comes closest -- supports composable information flows that let analysts combine signals and build progressively more refined heuristics. Recent clustering research also shows how dramatically privacy can degrade once external information gets incorporated into transaction-graph analysis.

Finally, much of the recent CoinJoin literature measures privacy at the single-transaction level and ignores the surrounding transaction (sub)graph. However, intersection-attack research demonstrates that pre- and post-mix activity can significantly erode privacy as shown in work on intersection attacks (e.g., Goldfeder et al.).

The research direction is to treat on-chain privacy as an emergent property of transaction-graph structure, rather than as a per-transaction heuristic, and to analyze that structure using concepts from spectral graph analysis / random graphs. Dense transaction construction (e.g. radix CoinJoins) provides strong local ambiguity, while verifiable randomness in peer and coin selection induces global graph properties that drive rapid mixing and many plausible paths. Entropy captures the size of anonymity sets, but edge-differential-privacy–style parameters capture their robustness to information revelation; the open problem is interpreting these parameters meaningfully when the algorithm and data are fixed and ( \varepsilon ) must be estimated rather than chosen. Key open questions include how fragile large anonymity sets are under realistic edge deletions, how degree sequences evolve over time in the randomized subgraph, and how much information leaks through revealed preferences. Simulations can cover most of the empirical work: generating transaction graphs under different randomized selection rules, estimating degree distributions and path counts, measuring mixing times and stationary distributions, stress-testing edge removals and deanonymization events, and validating whether the resulting graphs behave like expanders / superconcentrators with high probability.