From 45a3de0977c523e0a6520f87267415e36a00f07f Mon Sep 17 00:00:00 2001 From: Code Orange Devs Date: Tue, 29 Sep 2026 12:20:15 +0800 Subject: [PATCH] Accuracy cleanup: remove person claims, Shroud and unverifiable numbers - Issue pool replaced with live good-first-issue searches plus a day-of checklist; no hand-picked 'LIVE' list that goes stale - Session plans: no contributor name-drops (one said '4 contributors' and named three); dated PR references marked 'as of September 2026' - Cohort READMEs: drop registrant/graduate/completion numbers, 'flagship', and partnership claims that aren't publicly verifiable - Lab text: vectors claim limited to what's verifiable Co-Authored-By: Claude Opus 5.5 --- CONTRIBUTING.md | 14 +- README.md | 4 +- bitcoin-dojo/README.md | 25 +-- bitcoin-dojo/week-07/exercises/capstone.md | 4 +- decoding-bitcoin/README.md | 6 +- privacy-track/FACILITATOR_GUIDE.md | 6 +- privacy-track/ISSUE_POOL.md | 154 +++++++----------- privacy-track/PR_CHECKLIST.md | 6 +- privacy-track/README.md | 10 +- privacy-track/SESSIONS.md | 34 ++-- privacy-track/labs/network-privacy/README.md | 2 +- privacy-track/labs/payjoin/README.md | 2 +- privacy-track/labs/silent-payments/README.md | 4 +- .../labs/silent-payments/run_vectors.py | 8 +- privacy-track/labs/silent-payments/send.py | 2 +- privacy-track/resources/glossary.md | 2 +- rawbit/README.md | 2 +- sovereign-bitcoiner/README.md | 2 +- 18 files changed, 114 insertions(+), 173 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 8643a39..6b45644 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -20,17 +20,17 @@ → No technical background needed ### "I understand Bitcoin but haven't coded on it" -→ Join the **Bitcoin Dojo** (7 weeks, Chaincode BOSS Challenge) -→ Or join **rawBit** (10 weeks, elliptic curves to Taproot) +→ Join the **Bitcoin Dojo** (7 weeks, Programming Bitcoin) +→ Or join **rawBit** (10 weeks, raw transactions from P2PKH to Taproot) → You'll write your first Bitcoin scripts and understand the protocol ### "I can code and want to contribute to Bitcoin" → Join **Decoding Bitcoin** (8 weeks, transaction deep dive) -→ Or jump into the **Privacy Track** (24 sessions, chain analysis through CoinSwap) +→ Or drop into the **Privacy Track** (12 biweekly sessions, Silent Payments through ecash) → You'll submit your first PR to a real Bitcoin project ### "I'm already contributing and want funding" -→ Apply for a **Developer Fellowship** ($500/mo, 6 months) +→ Apply for a **Developer Fellowship** ($512/mo, 6 months) → Pick a project, get a mentor, ship code: fellowship@codeorange.dev → Details: https://github.com/code-orange-dev/fellowships @@ -72,18 +72,18 @@ All our curriculum is CC0-licensed. You can use, adapt, and improve it. ## Your First Bitcoin Open-Source PR -Not sure where to start contributing to Bitcoin itself? Here are beginner-friendly projects our community contributes to: +Not sure where to start contributing to Bitcoin itself? Here are some projects that label beginner-friendly issues: | Project | Language | Good First Issues | |---------|----------|-------------------| | [rust-bitcoin](https://github.com/rust-bitcoin/rust-bitcoin) | Rust | Documentation, tests, small fixes | | [BDK](https://github.com/bitcoindevkit/bdk) | Rust | Wallet tooling, tests | -| [Floresta](https://github.com/Davidson-Souza/Floresta) | Rust | Light client node, good first issues labeled | +| [Floresta](https://github.com/getfloresta/Floresta) | Rust | Light client node, good first issues labeled | | [BlueWallet](https://github.com/BlueWallet/BlueWallet) | React Native | Translations, UI improvements | | [BTCPay Server](https://github.com/btcpayserver/btcpayserver) | C# | Merchant payments, documentation | | [peer-observer](https://github.com/peer-observer/peer-observer) | Rust | P2P network monitoring | -**Pro tip**: Start by reading the project's CONTRIBUTING.md, then look for issues labeled `good first issue` or `help wanted`. Our Discord has a #contribution-help channel where you can ask questions. +**Pro tip**: Start by reading the project's CONTRIBUTING.md, then look for issues labeled `good first issue` or `help wanted`. You can also ask in the Code Orange Discord. --- diff --git a/README.md b/README.md index b823434..fa189b6 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ ## About This Repository -This is the master curriculum repository for [Code Orange Dev School](https://codeorange.dev) - Asia's Bitcoin Developer Pipeline. It contains everything an educator needs to fork this repo and run their own Bitcoin developer cohort, anywhere in the world, in any language. +This is the master curriculum repository for [Code Orange Dev School](https://codeorange.dev), a Bitcoin-only developer education program. It contains everything an educator needs to fork this repo and run their own Bitcoin developer cohort, anywhere in the world, in any language. All materials are released under **CC0 1.0 Universal (Public Domain)** - use them, adapt them, translate them, teach with them. No permission needed. @@ -128,7 +128,7 @@ curriculum/ ## Upstream Resources -This curriculum builds on world-class open-source Bitcoin education: +This curriculum builds on these open-source Bitcoin education resources: - [Chaincode Labs Bitcoin Curriculum](https://github.com/chaincodelabs/bitcoin-curriculum) - Protocol development study groups - [Bitcoin Dev Project](https://bitcoindevs.xyz/) - Developer onboarding and learning paths diff --git a/bitcoin-dojo/README.md b/bitcoin-dojo/README.md index b25cfad..64df372 100644 --- a/bitcoin-dojo/README.md +++ b/bitcoin-dojo/README.md @@ -8,12 +8,10 @@ ## Overview -Bitcoin Dojo is a 7-week study cohort run in partnership with [Chaincode Labs](https://chaincode.com/) as part of the [BOSS Challenge](https://learning.chaincode.com/) (Building Open Source Software). Participants build Bitcoin's cryptographic primitives from scratch using Jimmy Song's [Programming Bitcoin](https://github.com/jimmysong/programmingbitcoin) - covering finite fields, elliptic curves, ECDSA, key generation, address encoding, and transaction construction. +Bitcoin Dojo is a 7-week study cohort. Participants build Bitcoin's cryptographic primitives from scratch using Jimmy Song's [Programming Bitcoin](https://github.com/jimmysong/programmingbitcoin) - covering finite fields, elliptic curves, ECDSA, key generation, address encoding, and transaction construction. This is not a lecture course. Participants study independently, then defend their understanding in weekly group calls where they explain answers to assigned questions. The goal: turn developers into Bitcoiners who are ready to contribute to open-source projects. -**Our first cohort had 49 registrants and produced 21 graduates**, many of whom are now pursuing Good First Issues across Bitcoin Core, rust-bitcoin, BDK, and other projects. - ## Prerequisites - Comfortable writing code in Python (the exercises use Python) @@ -28,9 +26,7 @@ This is not a lecture course. Participants study independently, then defend thei | **Time commitment** | 6-10 hours per week (self-study + calls) | | **Weekly calls** | Mondays 11:00 UTC via Discord | | **Textbook** | [Programming Bitcoin](https://github.com/jimmysong/programmingbitcoin) by Jimmy Song | -| **Partner** | [Chaincode Labs](https://chaincode.com/) BOSS Challenge | -| **Registrants (Cohort 1)** | 49 | -| **Graduates (Cohort 1)** | 21 | +| **Related program** | Chaincode Labs' [BOSS Challenge](https://learning.chaincode.com/) (separate, run by Chaincode) | ## How It Works @@ -233,8 +229,7 @@ Each participant presents: ### Before the Cohort -- [ ] Confirm partnership with Chaincode Labs / BOSS Challenge (if applicable) -- [ ] Open registration (target: 40-50 registrants, expect ~50% completion rate) +- [ ] Open registration - [ ] Set up Discord channel with weekly topic threads - [ ] Ensure all participants have Python 3 installed - [ ] Clone Jimmy Song's [programmingbitcoin repo](https://github.com/jimmysong/programmingbitcoin) @@ -258,20 +253,6 @@ Each participant presents: --- -## Outcomes (Cohort 1: Feb-Apr 2026) - -| Metric | Value | -|--------|-------| -| Registrants | 49 | -| Graduates | 21 | -| Completion rate | ~43% | -| Partner | Chaincode Labs (BOSS Challenge) | -| Graduates pursuing Good First Issues | Multiple | -| Graduates joining rawBit cohort | In progress | -| Graduates joining Code Orange workshops | In progress | - ---- - ## License CC0 1.0 Universal. Public domain. Fork it, translate it, teach with it. diff --git a/bitcoin-dojo/week-07/exercises/capstone.md b/bitcoin-dojo/week-07/exercises/capstone.md index 99e62b7..5dc4c7d 100644 --- a/bitcoin-dojo/week-07/exercises/capstone.md +++ b/bitcoin-dojo/week-07/exercises/capstone.md @@ -29,6 +29,6 @@ If every signature verifies, you have independently validated a real Bitcoin tra ## 4. Next step: pick one -- **Keep building on these exact skills:** the [Privacy Track](../../../privacy-track/) Silent Payments lab uses the same curve math, tagged hashes and taproot keys. It's graded against the official BIP352 test vectors, and it's where many Code Orange contributors started +- **Keep building on these exact skills:** the [Privacy Track](../../../privacy-track/) Silent Payments lab uses the same curve math, tagged hashes and taproot keys. It's graded against the official BIP352 test vectors. - **Go deeper on transactions:** [rawBit](../../../rawbit/) or [Decoding Bitcoin](../../../decoding-bitcoin/) -- **Contribute:** pick an issue from the Privacy Track's [curated issue pool](../../../privacy-track/ISSUE_POOL.md) and run the [PR checklist](../../../privacy-track/PR_CHECKLIST.md) before submitting +- **Contribute:** find a current beginner issue with the Privacy Track's [live searches](../../../privacy-track/ISSUE_POOL.md) and run the [PR checklist](../../../privacy-track/PR_CHECKLIST.md) before submitting diff --git a/decoding-bitcoin/README.md b/decoding-bitcoin/README.md index 6540264..f7d1055 100644 --- a/decoding-bitcoin/README.md +++ b/decoding-bitcoin/README.md @@ -8,9 +8,7 @@ ## Overview -Decoding Bitcoin is Code Orange Dev School's flagship developer program. Over 8 weeks, participants self-study Bitcoin protocol fundamentals - transactions, Script, Taproot, PSBTs - and learn how to contribute to Bitcoin open-source software through structured peer-learning sessions with experienced mentors. - -**Our 2nd cohort produced 12 graduates who are now actively contributing to Bitcoin open-source projects** - with merged and approved PRs across Bitcoin Core, rust-bitcoin, BDK, rust-payjoin, peer-observer, LDK, and BlueWallet. +Decoding Bitcoin is an 8-week developer study cohort. Over 8 weeks, participants self-study Bitcoin protocol fundamentals - transactions, Script, Taproot, PSBTs - and learn how to contribute to Bitcoin open-source software through structured peer-learning sessions with experienced mentors. ## Prerequisites @@ -28,7 +26,7 @@ Decoding Bitcoin is Code Orange Dev School's flagship developer program. Over 8 | **Weekly sessions** | 2x per week - group discussion + TA office hours | | **Group size** | 10-20 participants, split into study groups of 4-5 | | **Assessments** | 2 technical questions per week + final contribution project | -| **Mentors** | Experienced Bitcoin developers and Code Orange alumni | +| **Mentors** | Volunteer mentors and teaching assistants | ## How It Works diff --git a/privacy-track/FACILITATOR_GUIDE.md b/privacy-track/FACILITATOR_GUIDE.md index 7d82727..1396ec1 100644 --- a/privacy-track/FACILITATOR_GUIDE.md +++ b/privacy-track/FACILITATOR_GUIDE.md @@ -12,7 +12,7 @@ You're a host, not a professor. You need to be one session ahead of the room, ha - [ ] Do the session's hands-on end to end on a clean machine. Write down every gotcha - [ ] Pick 1-2 live PRs for the Review Circle. Good picks are small, privacy-relevant, active in the last month, and have a clear "how would you test this?" angle. For S3 (Review Club), announce the PR a week ahead and ask people to build it -- [ ] Pull 3-5 targets from [ISSUE_POOL.md](./ISSUE_POOL.md) for the Proof-of-Work Board +- [ ] Use the live searches in [ISSUE_POOL.md](./ISSUE_POOL.md) to find 3-5 targets for the Proof-of-Work Board, and check each one the morning of the session - [ ] Post the session announcement with: the topic, what to install, the lab link, and "drop-ins welcome" ## The morning of @@ -56,7 +56,7 @@ These come from the program's [Review Club playbook](https://github.com/code-ora **"My build failed."** Keep a pre-built binary or a shared regtest box around. Setup pain belongs in a breakout room, and afterwards it makes a great docs PR. -**"I can't find anything to contribute."** A test report on an open PR is a contribution. So are docs. So is a reproduction of an open bug. The [pool](./ISSUE_POOL.md) is curated for exactly this. +**"I can't find anything to contribute."** A test report on an open PR is a contribution. So are docs. So is a reproduction of an open bug. [ISSUE_POOL.md](./ISSUE_POOL.md) links live searches and test targets for every session. **"Bitcoin Core is intimidating."** Start with the SP lab, which uses the exact vectors in `src/test/data/bip352_send_and_receive_vectors.json`. Then read `src/common/bip352.cpp`, which is short. That's a much gentler entry to Core than most. @@ -80,7 +80,7 @@ Builders working on this season's topics. Invite one per month. Offer 30 minutes ## After the season - Run S12 as a sprint, then hold a retro: which sessions produced proof of work, which labs broke, and which PRs got reviewed -- Update [ISSUE_POOL.md](./ISSUE_POOL.md) and move merged/closed entries to the log +- Record what people actually shipped (with links) in the program's tracking - Invite repeat contributors into the Review Club and the [fellowship](https://github.com/code-orange-dev/fellowships) pipeline - Measure retention at 3, 6 and 12 months, per the program's [MEASUREMENT.md](https://github.com/code-orange-dev/code-orange-dev/blob/main/privacy-contributor-program/MEASUREMENT.md) diff --git a/privacy-track/ISSUE_POOL.md b/privacy-track/ISSUE_POOL.md index 904abad..47843fc 100644 --- a/privacy-track/ISSUE_POOL.md +++ b/privacy-track/ISSUE_POOL.md @@ -1,125 +1,87 @@ -# Curated Issue Pool +# Finding a Contribution Target -**The source of contribution targets for the Privacy Sessions.** Participants pick from here instead of hunting randomly across GitHub. That's the guardrail that keeps us useful to maintainers rather than noisy. +This page deliberately lists **no specific issues**. A hand-picked list goes stale within days as issues get closed, claimed or fixed, and a stale list sends people at work that no longer exists. Instead, each session links to live searches, and a facilitator confirms a target the morning of the session. -> **Rule:** if an issue isn't in this file (or a curator hasn't just verified it), it isn't a session target. +## Before anyone starts work on an issue -**Last full verification: 2026-09-26.** Re-verify weekly and on the morning of any session. +Check all of these on the day, not from memory: ---- +1. **Still open**, and no linked or cross-referenced PR is already fixing it (read the issue's timeline) +2. **Unassigned**, and nobody has said "I'll take this" in the comments recently +3. **Still wanted**: labelled `good first issue` / `help wanted`, or a maintainer has said so +4. **Small enough** to make real progress on in or shortly after a session +5. You've read the repo's CONTRIBUTING file, and you **comment on the issue before starting** -## Two kinds of target +If a search comes back empty, that's normal: pick a **test target** instead (below), or ask in the project's chat what kind of help is useful right now. -- **BUILD**: an open issue with no active PR. You can claim it (comment first) and work on it -- **TEST**: an issue that already has an open PR. Don't open a competing PR. Build the PR, run it, and post a useful test report if one's missing. For newcomers this is often the *better* contribution +## Test targets (often the better first contribution) -## How an issue earns a spot +Building an open PR, running it on your machine and posting a precise test report is useful to maintainers and doesn't compete with anyone. Use the "open PRs" links below, read the thread first, and follow the report format in [PR_CHECKLIST.md](./PR_CHECKLIST.md). Only post if your report adds something the thread doesn't already have. -1. **Open**, verified within the last 7 days -2. **Wanted**: labeled `good first issue` / `help wanted`, or confirmed welcome by a maintainer -3. **Scoped**: plausible to finish in or shortly after a session -4. **Not claimed**: for BUILD, no assignee and no open PR. Otherwise it goes in as TEST +## Live searches by session -Stale entries get marked `RETIRED` (don't delete them; the history is useful). Aim for 3-6 live entries per repo. +Issue searches are filtered to open, unassigned `good first issue` items. They can still be claimed in the comments, so check. ---- -## Live pool +### S1-S3 · Silent Payments -### Silent Payments (S1-S3) +| Project | Issues | Review / test | +|---|---|---| +| [rust-silentpayments](https://github.com/cygnet3/rust-silentpayments) | [good first issue](https://github.com/cygnet3/rust-silentpayments/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/cygnet3/rust-silentpayments/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | +| [bdk-sp](https://github.com/bitcoindevkit/bdk-sp) | [good first issue](https://github.com/bitcoindevkit/bdk-sp/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/bitcoindevkit/bdk-sp/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | +| [BlindBit Oracle](https://github.com/setavenger/blindbit-oracle) | [good first issue](https://github.com/setavenger/blindbit-oracle/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/setavenger/blindbit-oracle/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | +| [Dana wallet](https://github.com/cygnet3/danawallet) | [good first issue](https://github.com/cygnet3/danawallet/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/cygnet3/danawallet/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | -| Issue | Type | Why it fits | Status | -|---|---|---|---| -| [shroud#132](https://github.com/CypherCommons/shroud/issues/132) Unit tests for the Rust BIP-352 scanner | BUILD | The SP lab teaches exactly what to test, and the official vectors are the test data. A previous attempt (#133) was closed, so read why first | LIVE | -| [shroud#156](https://github.com/CypherCommons/shroud/issues/156) SP UTXOs spent elsewhere never detected | BUILD | A real wallet bug; reproduce it on signet first. Community project (Chaitika) | LIVE | -| [bdk-sp#55](https://github.com/bitcoindevkit/bdk-sp/issues/55) False "bad tweak" when intermediate key sum hits zero | BUILD | This is lab vector 27, and the BIP fix already landed ([bips#2142](https://github.com/bitcoin/bips/pull/2142)) | LIVE | -| [rust-silentpayments#32](https://github.com/cygnet3/rust-silentpayments/issues/32) Add reference to code examples | BUILD | Docs, a gentle first PR | LIVE | -| [rust-silentpayments#109](https://github.com/cygnet3/rust-silentpayments/issues/109) Duplicate `calculate_ecdh_shared_secret()` | BUILD | Small refactor; ask the maintainer which copy should stay | LIVE | -| [danawallet#434](https://github.com/cygnet3/danawallet/issues/434) Button overlap in 3-button navigation | BUILD | Labeled `quick win`, Flutter UI | LIVE | -| [danawallet#403](https://github.com/cygnet3/danawallet/issues/403) Padding when keyboard is open | BUILD | Flutter UI, small | LIVE | -| [danawallet#466](https://github.com/cygnet3/danawallet/issues/466) Output-ambiguity recognition | BUILD (advanced) | Research + code. Only for people who finished the labels stretch | LIVE | -| [blindbit-oracle#58](https://github.com/setavenger/blindbit-oracle/issues/58) GetFullBlock drops outpoints | TEST | Open fix in [#60](https://github.com/setavenger/blindbit-oracle/pull/60): build it and test against signet | LIVE | -| [blindbit-oracle#36](https://github.com/setavenger/blindbit-oracle/issues/36) Add debug info endpoint | BUILD | Go, self-contained | LIVE | -| [bitcoin#36338](https://github.com/bitcoin/bitcoin/pull/36338) P2PKH pubkey extraction from malleated scriptSig | TEST / review | S1's Review Circle PR. Build it, run `bip352_tests` | LIVE | +### S4-S5 · Wallet behaviour and coin selection -### Coin selection & wallet (S4-S5) +| Project | Issues | Review / test | +|---|---|---| +| [bdk_wallet](https://github.com/bitcoindevkit/bdk_wallet) | [good first issue](https://github.com/bitcoindevkit/bdk_wallet/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/bitcoindevkit/bdk_wallet/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | +| [rust-bitcoin](https://github.com/rust-bitcoin/rust-bitcoin) | [good first issue](https://github.com/rust-bitcoin/rust-bitcoin/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/rust-bitcoin/rust-bitcoin/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | -| Issue | Type | Why it fits | Status | -|---|---|---|---| -| [bdk_wallet#543](https://github.com/bitcoindevkit/bdk_wallet/issues/543) Missing MAX_STANDARD_TX_WEIGHT check | TEST | Fix open in [#544](https://github.com/bitcoindevkit/bdk_wallet/pull/544) | LIVE | -| [bdk_wallet#46](https://github.com/bitcoindevkit/bdk_wallet/issues/46) Network consistency between genesis and descriptors | TEST | Fix open in [#520](https://github.com/bitcoindevkit/bdk_wallet/pull/520) | LIVE | -| [bdk_wallet#187](https://github.com/bitcoindevkit/bdk_wallet/issues/187) Return feerate from tx construction | TEST | Fix open in [#380](https://github.com/bitcoindevkit/bdk_wallet/pull/380) | LIVE | +### S6 · Payjoin -### Payjoin (S6) +| Project | Issues | Review / test | +|---|---|---| +| [rust-payjoin](https://github.com/payjoin/rust-payjoin) | [good first issue](https://github.com/payjoin/rust-payjoin/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/payjoin/rust-payjoin/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | -| Issue | Type | Why it fits | Status | -|---|---|---|---| -| [rust-payjoin#865](https://github.com/payjoin/rust-payjoin/issues/865) `cargo doc` improvements (tracking) | BUILD | Many small doc items; claim one item in a comment | LIVE | -| [rust-payjoin#551](https://github.com/payjoin/rust-payjoin/issues/551) Preserve privacy for >2-output txs | BUILD (advanced) | Real privacy logic. A previous attempt (#1837) closed, so read it first | LIVE | -| [rust-payjoin#1300](https://github.com/payjoin/rust-payjoin/issues/1300) .gitignore organization | - | A PR exists on a fork; check with the maintainers before touching it | CHECK | +### S7 · Light clients and nodes -### Light clients & nodes (S7) +| Project | Issues | Review / test | +|---|---|---| +| [Floresta](https://github.com/getfloresta/Floresta) | [good first issue](https://github.com/getfloresta/Floresta/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/getfloresta/Floresta/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | +| [Kyoto](https://github.com/2140-dev/kyoto) | [good first issue](https://github.com/2140-dev/kyoto/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/2140-dev/kyoto/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | -| Issue | Type | Why it fits | Status | -|---|---|---|---| -| [Floresta#799](https://github.com/getfloresta/Floresta/issues/799) Document all floresta-cli RPC endpoints | BUILD | Tracking issue with several merged PRs; pick an endpoint that's still undocumented | LIVE | -| [Floresta#1014](https://github.com/getfloresta/Floresta/issues/1014) Deny dangerous `as` casts | BUILD | Rust hygiene, split into small PRs | LIVE | -| [Floresta#1308](https://github.com/getfloresta/Floresta/issues/1308) config.toml parsed three times | - | A fork PR exists; ask before starting | CHECK | -| [kyoto](https://github.com/2140-dev/kyoto/issues) | - | No beginner-labeled issues right now. Use Kyoto for reading and testing, and ask a maintainer (sourcing playbook below) | SOURCING | +### S8 · Network privacy -### Network privacy (S8) +| Project | Issues | Review / test | +|---|---|---| +| [peer-observer](https://github.com/peer-observer/peer-observer) | [good first issue](https://github.com/peer-observer/peer-observer/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/peer-observer/peer-observer/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | -| Issue | Type | Why it fits | Status | -|---|---|---|---| -| [peer-observer#182](https://github.com/peer-observer/peer-observer/issues/182) Metric for unsolicited/unannounced txs | BUILD | `good first issue`, a clear spec | LIVE | -| [peer-observer#336](https://github.com/peer-observer/peer-observer/issues/336) log-extractor: parse debug.log | BUILD | `help wanted`, bigger but well-bounded | LIVE | -| [peer-observer#396](https://github.com/peer-observer/peer-observer/issues/396) Sequence diagrams in websocket-tool | BUILD | Front-end-ish, visual | LIVE | -| Bitcoin Core private-broadcast follow-ups ([#34322](https://github.com/bitcoin/bitcoin/pull/34322), [#34533](https://github.com/bitcoin/bitcoin/pull/34533), [#36330](https://github.com/bitcoin/bitcoin/pull/36330)) | TEST / review | Test with Tor/I2P on your platform, report exact steps | LIVE | +### S9 · CoinJoin and swaps -### CoinJoin, swaps, Lightning, ecash (S9-S11) +| Project | Issues | Review / test | +|---|---|---| +| [JoinMarket](https://github.com/JoinMarket-Org/joinmarket-clientserver) | [good first issue](https://github.com/JoinMarket-Org/joinmarket-clientserver/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/JoinMarket-Org/joinmarket-clientserver/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | +| [openswap](https://github.com/citadel-foss/openswap) | [good first issue](https://github.com/citadel-foss/openswap/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/citadel-foss/openswap/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | -| Issue | Type | Why it fits | Status | -|---|---|---|---| -| [joinmarket-clientserver good first issues](https://github.com/JoinMarket-Org/joinmarket-clientserver/issues?q=is%3Aopen+label%3A%22good+first+issue%22) | BUILD | 20+ labeled, but many are years old. Confirm an issue is still wanted before starting | SOURCING | -| [openswap#1021](https://github.com/citadel-foss/openswap/issues/1021) Derive minimum swap amount instead of hardcoding | BUILD | Scoped; confirm with maintainers | CHECK | -| [openswap#1037](https://github.com/citadel-foss/openswap/issues/1037) Human-readable maker names | BUILD | Scoped UX feature | CHECK | -| LDK / ldk-node / Core Lightning offers, cdk, Fedimint | - | No verified beginner targets yet. Source via maintainers before S10/S11 | SOURCING | +### S10 · Lightning ---- +| Project | Issues | Review / test | +|---|---|---| +| [ldk-node](https://github.com/lightningdevkit/ldk-node) | [good first issue](https://github.com/lightningdevkit/ldk-node/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/lightningdevkit/ldk-node/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | +| [LDK](https://github.com/lightningdevkit/rust-lightning) | [good first issue](https://github.com/lightningdevkit/rust-lightning/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/lightningdevkit/rust-lightning/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | +| [Core Lightning](https://github.com/ElementsProject/lightning) | [good first issue](https://github.com/ElementsProject/lightning/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/ElementsProject/lightning/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | -## The maintainer-DM sourcing playbook +### S11 · Ecash -This is how "we know a few maintainers" becomes a warm issue pipeline, and it's Code Orange's real long-term asset. +| Project | Issues | Review / test | +|---|---|---| +| [cdk](https://github.com/cashubtc/cdk) | [good first issue](https://github.com/cashubtc/cdk/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/cashubtc/cdk/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | +| [Fedimint](https://github.com/fedimint/fedimint) | [good first issue](https://github.com/fedimint/fedimint/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22+no%3Aassignee) | [open PRs](https://github.com/fedimint/fedimint/pulls?q=is%3Aopen+is%3Apr+-is%3Adraft) | -**The goal:** a handful of maintainers who think of Code Orange as *"the program that sends me prepared contributors"* and occasionally point us at work they'd actually like help with. +Bitcoin Core doesn't use a beginner label. For Core, reviewing and testing PRs is the way in: see [Bitcoin Core PR Review Club](https://bitcoincore.reviews). -**The opening DM (adapt it per person):** -> Hey [name] - I help run Code Orange's Bitcoin Privacy Sessions. We teach [topic] hands-on, and participants build and test real PRs before they ever open their own (they run a build/test/CONTRIBUTING checklist first - we're careful not to add noise). Are there a few issues, or PRs that need testing, where outside help would genuinely be welcome? We'll only point people at things you actually want touched. +## Recording outcomes -**Why it works:** it leads with respect for their time, signals that we have a quality floor, and asks them to *pull* work toward us instead of us pushing PRs at them. Offering *testing* is often the most welcome thing we can offer. - -**After the first merge or useful test report:** send a short thank-you and ask "anything else in this vein?" That loop is the whole game. - -**Priority for this season:** Silent Payments (cygnet3, setavenger, nymius, the Shroud team), Kyoto, openswap, and the LN/ecash repos for S10-S11. - -**Per-repo checklist:** -- [ ] Identify 1-2 active maintainers (recent commits / reviews) -- [ ] Send the opening DM and log the response below -- [ ] Link their CONTRIBUTING.md in the table -- [ ] Watch their `good first issue` / `help wanted` labels - -### Maintainer contact log - -| Date | Repo | Maintainer | Response / issues flagged | -|---|---|---|---| -| | | | | - ---- - -## Outcomes log - -Record everything here: merged PRs, useful test reports, reproduced bugs. It's how we report proof of work and spot which repos are working for us. - -| Date | Repo | Link | Contributor | Type (PR / test / review / repro) | Outcome | -|---|---|---|---|---|---| -| | | | | | | +After a session, record what people actually did (tests posted, reviews, PRs opened or merged) with links, in the program's tracking, not on this page. Only list something as an outcome once it has happened and can be linked. diff --git a/privacy-track/PR_CHECKLIST.md b/privacy-track/PR_CHECKLIST.md index e53897a..89226ee 100644 --- a/privacy-track/PR_CHECKLIST.md +++ b/privacy-track/PR_CHECKLIST.md @@ -2,13 +2,13 @@ **Run this before every pull request goes upstream. No exceptions.** -This is the ten-minute step that turns a maybe-PR into a merge, and it's the reason maintainers welcome Code Orange instead of muting it. A facilitator should make sure every participant runs it before hitting "Create pull request" or "Comment". +This is the ten-minute step that makes a PR worth a maintainer's time. A facilitator should make sure every participant runs it before hitting "Create pull request" or "Comment". --- ## Before you start coding -- [ ] The issue is from [`ISSUE_POOL.md`](./ISSUE_POOL.md), marked LIVE and type BUILD (not random, not already claimed). +- [ ] You checked the issue today with the steps in [`ISSUE_POOL.md`](./ISSUE_POOL.md): still open, no PR already fixing it, unassigned, still wanted. - [ ] You commented on the issue (or checked it's unassigned) so two people don't do the same work. - [ ] You read the repo's **CONTRIBUTING.md**. Each repo has its own rules - follow theirs over any general habit. @@ -26,7 +26,7 @@ This is the ten-minute step that turns a maybe-PR into a merge, and it's the rea - [ ] Watch for review comments and respond promptly and politely. - [ ] Expect change requests - that's normal and is part of contributing, not a rejection. -- [ ] When it merges (or closes), log it in the ISSUE_POOL outcomes log. +- [ ] When it merges (or closes), record the outcome with its link in the program's tracking. --- diff --git a/privacy-track/README.md b/privacy-track/README.md index 69548b0..43dffb4 100644 --- a/privacy-track/README.md +++ b/privacy-track/README.md @@ -21,14 +21,14 @@ This track teaches those problems one at a time, with the code open on screen, a ## Why start with Silent Payments -Because it's landing right now. Bitcoin Core merged the BIP352 core logic in September 2026 ([#35301](https://github.com/bitcoin/bitcoin/pull/35301)), libsecp256k1 v0.8.0 ships a `silentpayments` module, and wallets like Dana, Cake, BlueWallet, Sparrow and our own community's [Shroud](https://github.com/CypherCommons/shroud) are shipping support. Sending and receiving in Core are in review. Participants can build the protocol from scratch (S1-S2) and then review the real implementation while it's still open (S3). +Because it's landing right now. As of September 2026, Bitcoin Core has merged the BIP352 core logic ([#35301](https://github.com/bitcoin/bitcoin/pull/35301)), libsecp256k1 v0.8.0 ships a `silentpayments` module, and several wallets already support sending or receiving (see [Optech's Silent Payments topic](https://bitcoinops.org/en/topics/silent-payments/) for the current list). Sending and receiving in Core are in review. Participants can build the protocol from scratch (S1-S2) and then review the real implementation while it's still open (S3). ## How it works - **Online, global, drop-in.** Every session stands alone. You'll never be lost because you missed last time - **Hands-on every time.** You build or run something on your own machine: a Silent Payments sender graded against the official BIP352 vectors, a node, a payjoin, a swap - **Review-first.** Every session reads a real open PR together. We learn to build, test and explain other people's work, which is how contributors earn trust -- **Proof of work, not attendance.** You leave with a concrete next step: a finished lab, a tested PR, a reproduced bug, a doc fix, or a PR from the [curated pool](./ISSUE_POOL.md) +- **Proof of work, not attendance.** You leave with a concrete next step: a finished lab, a tested PR, a reproduced bug, a doc fix, or a PR on an issue you've checked is still open ([how to find one](./ISSUE_POOL.md)) ## Where it fits @@ -66,7 +66,7 @@ python3 run_vectors.py send 1. **Do the hands-on yourself first.** Every session in [SESSIONS.md](./SESSIONS.md) has a prep line. If you can do it, you can host it 2. **Teach the why, then show where it lives in code.** The repo's own docs handle the how -3. **Protect the relationship with maintainers.** Contributions come from the [curated pool](./ISSUE_POOL.md) and pass the [PR checklist](./PR_CHECKLIST.md). Review comments go upstream only when they're genuinely useful. The privacy world is small, and a reputation for noise closes doors for everyone after us +3. **Protect the relationship with maintainers.** Every target is checked on the day ([how](./ISSUE_POOL.md)) and every PR passes the [PR checklist](./PR_CHECKLIST.md). Review comments go upstream only when they're genuinely useful. The privacy world is small, and a reputation for noise closes doors for everyone after us Full guide: [FACILITATOR_GUIDE.md](./FACILITATOR_GUIDE.md). @@ -77,7 +77,7 @@ Enter at any rung. There's no pressure to climb. 1. **Engage:** build a repo, read the code, join its chat 2. **Test:** build someone's PR, run it, report exactly what you did and saw 3. **Fix:** docs, error messages, small clarity improvements -4. **Cover:** add tests. Maintainers love it, and it teaches you the code +4. **Cover:** add tests. It's useful to maintainers, and it teaches you the code 5. **Review:** explain a PR, challenge an assumption, find an edge case 6. **Build:** fix a real bug or implement a scoped feature, then see it through review 7. **Lead:** curate the pool, host a session, mentor newcomers @@ -97,7 +97,7 @@ In the order that matters (details in the program's [MEASUREMENT.md](https://git |---|---| | [SESSIONS.md](./SESSIONS.md) | The 12 sessions: beats, prep, hands-on, PRs, follow-ups | | [FACILITATOR_GUIDE.md](./FACILITATOR_GUIDE.md) | Running a session: checklist, Review Circle rules, troubleshooting | -| [ISSUE_POOL.md](./ISSUE_POOL.md) | Verified contribution targets, mapped to sessions | +| [ISSUE_POOL.md](./ISSUE_POOL.md) | How to find a current contribution target: live searches per session | | [PR_CHECKLIST.md](./PR_CHECKLIST.md) | Run before anything goes upstream | | [resources/](./resources/) | Glossary and per-session reading list | | [CONTRIBUTING.md](./CONTRIBUTING.md) | Improving this track | diff --git a/privacy-track/SESSIONS.md b/privacy-track/SESSIONS.md index 5dd882d..775e6f5 100644 --- a/privacy-track/SESSIONS.md +++ b/privacy-track/SESSIONS.md @@ -6,7 +6,7 @@ - Every session: use or build a real privacy tool, then study a real open PR together - Drop in any session. Each one re-teaches what it needs. Signet, testnet or regtest only, cameras optional -We open with Silent Payments because it's happening now. Bitcoin Core merged the BIP352 core logic in September 2026 ([#35301](https://github.com/bitcoin/bitcoin/pull/35301)), libsecp256k1 shipped a `silentpayments` module in v0.8.0, and sending ([#35302](https://github.com/bitcoin/bitcoin/pull/35302)) and receiving ([#32966](https://github.com/bitcoin/bitcoin/pull/32966)) are in review. Participants can learn the protocol, build it, and review it while the work is still going on. +We open with Silent Payments because it's happening now. As of September 2026: Bitcoin Core merged the BIP352 core logic ([#35301](https://github.com/bitcoin/bitcoin/pull/35301)), libsecp256k1 shipped a `silentpayments` module in v0.8.0, and sending ([#35302](https://github.com/bitcoin/bitcoin/pull/35302)) and receiving ([#32966](https://github.com/bitcoin/bitcoin/pull/32966)) are in review. Participants can learn the protocol, build it, and review it while the work is still going on. ## Season One Schedule @@ -59,9 +59,9 @@ We open with Silent Payments because it's happening now. Bitcoin Core merged the - Walk through: `B_scan` / `B_spend`, sum of input keys, input hash (why paying the same person twice gives two different addresses), `t_k`, the x-only taproot output - The catch, which is S2's topic: the receiver has to *scan* - 🛠 **BUILD THE SENDER** ([send.py](./labs/silent-payments/send.py)): 5 small functions, graded against the 28 official vectors. Pair people up, and let the room race to 28/28. Anyone who finishes early reads `txin.py` and explains to the room why P2WSH multisig inputs don't count -- 🔍 [bitcoin/bitcoin#36338](https://github.com/bitcoin/bitcoin/pull/36338) *BIP-352: fix P2PKH pubkey extraction from malleated scriptSig*. It's small, it's live, and it maps directly onto lab vector 21. Questions for the room: what did the old code do, and what would happen to a payment if sender and receiver disagreed here? +- 🔍 [bitcoin/bitcoin#36338](https://github.com/bitcoin/bitcoin/pull/36338) *BIP-352: fix P2PKH pubkey extraction from malleated scriptSig* (open as of September 2026; check before the session). It's small and it maps directly onto lab vector 21. Questions for the room: what did the old code do, and what would happen to a payment if sender and receiver disagreed here? - 📜 BIP352 "Motivation". Read it like scripture, argue about it like heretics: does SP make the reuse problem go away, or just move it somewhere else? -- 🎯 Finish the lab to 28/28 · or test Dana/Shroud on signet and file one well-documented bug or UX issue · or read [bdk-sp#55](https://github.com/bitcoindevkit/bdk-sp/issues/55) and check whether vector 27 covers it +- 🎯 Finish the lab to 28/28 · or test an SP wallet on signet (e.g. Dana) and file one well-documented bug or UX issue after checking it isn't already reported ## S2 · Silent Payments II: "Finding Your Money" @@ -71,14 +71,14 @@ We open with Silent Payments because it's happening now. Bitcoin Core merged the - 🩸 "Your phone has to do *what*?" Receiving SP means checking every eligible transaction on the chain. Run the benchmark live, then scale it: a year offline equals X hours of catch-up - 🕳 Three ways to scan, each with its own privacy trade-off: 1. **Your own full node** (Bitcoin Core receiving PR, kernel-node): private, but heavy - 2. **Download tweaks** from an indexer (BlindBit Oracle, Shroud's indexer, Dana): the server only learns that you're an SP user, and you do the ECDH yourself. Pair this with BIP158 filters so you don't reveal which outputs matched (bridge to S7) + 2. **Download tweaks** from an indexer (e.g. BlindBit Oracle, used by Dana): the server only learns that you're an SP user, and you do the ECDH yourself. Pair this with BIP158 filters so you don't reveal which outputs matched (bridge to S7) 3. **Hand your scan key to a server** (Frigate, with ephemeral keys held in RAM): fast and GPU-accelerated, but the server can see your incoming payments - **Analogy:** (1) you sort all the mail at the post office yourself; (2) the post office gives you a stamp for each letter and you test them at home; (3) you give the postman a key that opens only your letters, which saves time, and he can read them - Labels: one wallet, many distinguishable addresses, still one scan - 🛠 **BUILD THE SCANNER** ([receive.py](./labs/silent-payments/receive.py)): tweak, scan loop, then labels and spend keys as stretch goals. The grader catches the two classic bugs (checking outputs by position, stopping after the first match). Finish with `scan_benchmark.py` and compare laptops -- 🔍 [bitcoin-core/secp256k1#1912](https://github.com/bitcoin-core/secp256k1/pull/1912) *silentpayments: add light client API*. Which of our three models is this API for? Or, from our own community: [Shroud](https://github.com/CypherCommons/shroud) (Chaitika's wallet) and [kernel-node#50](https://github.com/kernel-node/kernel-node/pull/50) (Peter's SP scanning, merged) +- 🔍 [bitcoin-core/secp256k1#1912](https://github.com/bitcoin-core/secp256k1/pull/1912) *silentpayments: add light client API* (open as of September 2026; if it has merged, read the merged diff and its review thread). Which of our three models is this API for? - 📜 Satoshi, whitepaper §10 "Privacy": "keeping public keys anonymous." How far did we drift, and does SP bring us back? -- 🎯 [shroud#132](https://github.com/CypherCommons/shroud/issues/132): unit tests for its Rust BIP-352 scanner (you just learned what to test) · or run BlindBit Oracle on signet and write up the setup · or take on [danawallet#466](https://github.com/cygnet3/danawallet/issues/466) (the output-ambiguity research issue) if you finished the labels stretch +- 🎯 Run BlindBit Oracle on signet and write up the setup · or pick a scanning-related `good first issue` in an SP library such as [rust-silentpayments](https://github.com/cygnet3/rust-silentpayments/issues) or [bdk-sp](https://github.com/bitcoindevkit/bdk-sp/issues), after checking it's still open and unclaimed ## S3 · Silent Payments III: Review Club, "Silent Payments Land in Core" @@ -114,9 +114,9 @@ This session replaces the usual beats with the Review Club format: - 🩸 An exchange freezes a user because of where their coins were 3 hops ago - 🕳 UTXOs are coins with memories, and coin selection chooses which past life to reveal. Algorithms (largest-first, BnB, random) trade fees against privacy. Changeless transactions, labels as self-defense, BIP329 label export - 🛠 **BREAK IT ON PURPOSE:** label every UTXO, freeze one, force selections. Then merge two labeled identities and watch the damage. Then run the [coin-selection lab](./labs/coin-selection/) and try to beat BnB on privacy without losing on fees -- 🔍 BDK coin-selection PRs. Show [Muhammad's merged audit fixes](https://github.com/bitcoindevkit/bdk_wallet/pull/471): normal people do this +- 🔍 BDK coin-selection PRs. Show a small merged fix such as [bdk_wallet#471](https://github.com/bitcoindevkit/bdk_wallet/pull/471): contributions like this are within reach - 📜 Hal Finney on privacy expectations -- 🎯 A BDK beginner issue from the [pool](./ISSUE_POOL.md) · or a test report on an open coin-selection PR +- 🎯 A BDK beginner issue ([how to find one](./ISSUE_POOL.md)) · or a test report on an open coin-selection PR ## S6 · Payjoin: "Paying Together" @@ -126,9 +126,9 @@ This session replaces the usual beats with the Review Club format: - 🩸 The analyst's crown jewel (all inputs belong to one owner) and the transaction type that poisons it for everyone, including people who never use it - 🕳 BIP78 (sync, the receiver runs a server) vs BIP77 (async, via an untrusted directory with OHTTP). **Analogy:** both people put cash on the restaurant table. Where it ships today: [payjoin.org](https://payjoin.org) lists wallets - 🛠 **PAYJOIN IN PAIRS** ([payjoin lab](./labs/payjoin/)): one person sends, one receives, then swap roles. Then play analyst: trace each input back to its wallet and point at the lie the transaction tells -- 🔍 The friendliest repo we know: 4 Code Orange contributors have merged here (Arowolo, Vaan, Mwihoti). Swarm-review one PR +- 🔍 Swarm-review one open rust-payjoin PR together - 📜 Adam Back: privacy has to be default and boring to win -- 🎯 A rust-payjoin beginner issue from the [pool](./ISSUE_POOL.md). Docs count ([#865 `cargo doc` improvements](https://github.com/payjoin/rust-payjoin/issues/865)) +- 🎯 A rust-payjoin [`good first issue`](https://github.com/payjoin/rust-payjoin/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) that's still open and unclaimed. Docs count ## S7 · Light Clients & Your Own Node: "Don't Trust, Verify, Privately" @@ -140,7 +140,7 @@ This session replaces the usual beats with the Review Club format: - 🛠 **NODE RACE:** build and run Floresta live, and the first to sync wins sats. Connect a wallet to YOUR node. Faster finishers: the filters lab - 🔍 Floresta: welcoming maintainers and a real good-first-issue culture - 📜 "Don't trust, verify": what it actually asks of us -- 🎯 A Floresta beginner issue ([#799 RPC docs](https://github.com/getfloresta/Floresta/issues/799) is ideal after tonight) · or turn tonight's setup pain into a docs PR +- 🎯 A Floresta [`good first issue`](https://github.com/getfloresta/Floresta/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22) that's still open and unclaimed · or turn tonight's setup pain into a docs PR ## S8 · The Network Sees You: "Tor, BIP324, Private Broadcast, ASmap" @@ -153,7 +153,7 @@ This session replaces the usual beats with the Review Club format: - **`-privatebroadcast`** (Core 31): transactions submitted with `sendrawtransaction` go out only via short-lived Tor/I2P connections, one tx per connection. Wallet sends aren't covered yet; open follow-ups like [#34533](https://github.com/bitcoin/bitcoin/pull/34533) work on that - **`-asmap=1`** (Core 31, embedded map, off by default): spread your peers across networks so no single operator surrounds you. **Analogy:** never send all your messengers out the same gate - 🛠 **WIRETAP YOURSELF** ([network lab](./labs/network-privacy/)): Wireshark plaintext v1 vs BIP324. Enable `-privatebroadcast`, build a signet tx in the wallet and broadcast it with `sendrawtransaction` (in Core 31, wallet sends don't use private broadcast), then watch `getprivatebroadcastinfo`. Count peers sharing one AS, enable `-asmap=1`, compare diversity -- 🔍 peer-observer: our own Razor has 4 merged PRs here, so review with "what does this detect?" glasses. Or an open private-broadcast follow-up in Core (e.g. [#34322](https://github.com/bitcoin/bitcoin/pull/34322), [#34533](https://github.com/bitcoin/bitcoin/pull/34533)) +- 🔍 A peer-observer PR, reviewed with "what does this detect?" glasses. Or a private-broadcast follow-up in Core (open as of September 2026: [#34322](https://github.com/bitcoin/bitcoin/pull/34322), [#34533](https://github.com/bitcoin/bitcoin/pull/34533)) - 📜 May, *The Crypto Anarchist Manifesto* (1988). Debate: "the network layer is Bitcoin's soft underbelly." Overblown or underrated? - 🎯 A peer-observer beginner issue · or publish your AS-diversity check as a guide · or a tested-on-platform report on a private-broadcast PR @@ -177,7 +177,7 @@ This session replaces the usual beats with the Review Club format: - 🩸 "Just use Lightning for privacy." Then show balance probing and a traced payment - 🕳 What it hides: amounts from the chain. What it leaks: channels are public UTXOs, balances can be probed, invoices link identities, and your node pubkey is a fingerprint. Fixes in progress: BOLT12 offers, blinded paths, unannounced channels, splicing - 🛠 **LEAK COMPARISON:** pay a BOLT11 invoice and list what each hop learned. Then pay a BOLT12 offer with a blinded path and compare line by line -- 🔍 ldk-node BOLT12 interop tests or Core Lightning offers (Gradale's territory) +- 🔍 An ldk-node or Core Lightning PR about BOLT12 offers or blinded paths - 📜 Debate: "Layer 2 inherits layer 1's sins" - 🎯 An LDK/CLN docs or test issue on offers/blinded paths @@ -196,10 +196,10 @@ This session replaces the usual beats with the Review Club format: ## S12 · Contribution Sprint: "Ship It" **You leave with:** something real submitted upstream tonight, whether that's code, a test report or a review that passed the checklist. -**Prep:** the season scoreboard (reviews, test reports, issues and PRs, with names on screen if people opted in) · a curated board of verified-open issues from the [pool](./ISSUE_POOL.md) · sats budget · the Hughes closing quote +**Prep:** the season scoreboard (reviews, test reports, issues and PRs, with names on screen if people opted in) · a board of issues found via [ISSUE_POOL.md](./ISSUE_POOL.md) and checked that morning · sats budget · the Hughes closing quote - 🩸 The scoreboard: everything the room shipped this season, including the reviews and test reports, not just PRs -- 🛠 **THE SPRINT (60 min):** pick from the board (SP scanner tests for Shroud, rust-payjoin, Floresta, Kyoto, BDK, peer-observer, JoinMarket, openswap, cdk), pair up, and ship it live. Facilitators float and sats flow +- 🛠 **THE SPRINT (60 min):** pick from the board (rust-payjoin, Floresta, Kyoto, BDK, peer-observer, JoinMarket, openswap, cdk), pair up, and ship it live. Facilitators float and sats flow - 🔍 Everyone reviews someone else's draft against the [PR checklist](./PR_CHECKLIST.md) before it goes upstream - 📜 Hughes' closing lines, read AFTER the sprint: "Cypherpunks write code" - 🎯 Vote on Season Two topics. Strong contributors: talk to us about the [Review Club and fellowship](https://github.com/code-orange-dev/fellowships) @@ -208,7 +208,7 @@ This session replaces the usual beats with the Review Club format: ## Season Two candidates (the room votes at S12) -- BIP324 deep-dive: build a v2 transport handshake (Razor's [bip324-mitm](https://github.com/RazorBest/bip324-mitm) as a reference) +- BIP324 deep-dive: build a v2 transport handshake - BIP375/BIP374: Silent Payments with PSBTs and hardware wallets (DLEQ proofs) - Stratum V2 and miner privacy - Mempool privacy, RBF and fee fingerprinting @@ -221,6 +221,6 @@ This session replaces the usual beats with the Review Club format: ## Why these repos -Newcomers see our own people's merged code in almost every repo. rust-payjoin (4 CO contributors merged) · Shroud (Chaitika) · kernel-node and Bitcoin Core SP (Peter) · peer-observer (Razor, 4 merged) · BDK (Vaan, Muhammad) · LDK and Core Lightning (Gradale, Psychemist) · Floresta · Kyoto · openswap · JoinMarket · cdk. Anything that goes upstream passes the [PR checklist](./PR_CHECKLIST.md). Live targets are in the [issue pool](./ISSUE_POOL.md). +They're actively maintained, privacy-relevant, and have beginner-labelled issues or reviewable PRs: rust-payjoin · Floresta · Kyoto · BDK · peer-observer · LDK and Core Lightning · openswap · JoinMarket · cdk · Silent Payments libraries. Anything that goes upstream passes the [PR checklist](./PR_CHECKLIST.md). How to find a current target: [ISSUE_POOL.md](./ISSUE_POOL.md). *Privacy isn't something you wait for. It's something you ship.* 🟠 diff --git a/privacy-track/labs/network-privacy/README.md b/privacy-track/labs/network-privacy/README.md index 2b7776f..5ba59ec 100644 --- a/privacy-track/labs/network-privacy/README.md +++ b/privacy-track/labs/network-privacy/README.md @@ -93,7 +93,7 @@ With asmap on, Core buckets peers by AS instead of by IP range, and `getpeerinfo ## Proof of work (pick one) - Write up your AS-diversity numbers from before and after, as a short guide for your community -- Test an open private-broadcast follow-up PR on your platform and post a precise test report (see the [issue pool](../../ISSUE_POOL.md) and [PR checklist](../../PR_CHECKLIST.md)) +- Test an open private-broadcast follow-up PR on your platform and post a precise test report (see [how to find one](../../ISSUE_POOL.md) and the [PR checklist](../../PR_CHECKLIST.md)) - Take a [peer-observer](https://github.com/peer-observer/peer-observer) beginner issue ## References diff --git a/privacy-track/labs/payjoin/README.md b/privacy-track/labs/payjoin/README.md index 035fe2f..d4f2b2d 100644 --- a/privacy-track/labs/payjoin/README.md +++ b/privacy-track/labs/payjoin/README.md @@ -51,7 +51,7 @@ Feed this transaction's shape into your `apply_cioh` and `detect_change_output` ## Proof of work (pick one) -- A rust-payjoin beginner issue from the [issue pool](../../ISSUE_POOL.md). Docs count +- A rust-payjoin beginner issue ([how to find one](../../ISSUE_POOL.md)). Docs count - Something in the quick start confused you? Fix the docs upstream, following the [PR checklist](../../PR_CHECKLIST.md) - Test an open rust-payjoin PR on your platform and post a precise test report diff --git a/privacy-track/labs/silent-payments/README.md b/privacy-track/labs/silent-payments/README.md index b101a17..4939c61 100644 --- a/privacy-track/labs/silent-payments/README.md +++ b/privacy-track/labs/silent-payments/README.md @@ -1,6 +1,6 @@ # Silent Payments Lab (BIP352) -Build a working Silent Payments sender and scanner in plain Python, then check it against the **official BIP352 test vectors**: the same 28 cases Bitcoin Core, libsecp256k1, rust-silentpayments, BDK and every SP wallet test against. When your code passes all of them, it's compatible with real wallets. +Build a working Silent Payments sender and scanner in plain Python, then check it against the **official BIP352 test vectors**: the cases published with the BIP (Bitcoin Core, for example, includes them in its unit tests). When your code passes all of them, it follows the spec on every case they cover. No dependencies. Python 3.8+. Works offline. @@ -56,5 +56,5 @@ This is teaching code: slow and not constant-time. **Never paste real keys into - [BIP352](https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki) and its [reference.py](https://github.com/bitcoin/bips/blob/master/bip-0352/reference.py): compare your code line by line - [libsecp256k1 `silentpayments` module](https://github.com/bitcoin-core/secp256k1) (merged July 2026, PR #1765) and the light-client API follow-up (#1912) - [Bitcoin Core tracking issue #28536](https://github.com/bitcoin/bitcoin/issues/28536): BIP352 core logic merged in #35301; sending (#35302) and receiving (#32966) in review -- [rust-silentpayments](https://github.com/cygnet3/rust-silentpayments), [bdk-sp](https://github.com/bitcoindevkit/bdk-sp), [BlindBit Oracle](https://github.com/setavenger/blindbit-oracle), [Frigate](https://github.com/sparrowwallet/frigate), [Dana wallet](https://github.com/cygnet3/danawallet), [Shroud](https://github.com/CypherCommons/shroud) +- [rust-silentpayments](https://github.com/cygnet3/rust-silentpayments), [bdk-sp](https://github.com/bitcoindevkit/bdk-sp), [BlindBit Oracle](https://github.com/setavenger/blindbit-oracle), [Frigate](https://github.com/sparrowwallet/frigate), [Dana wallet](https://github.com/cygnet3/danawallet) - [Bitcoin Optech: Silent Payments](https://bitcoinops.org/en/topics/silent-payments/): history and news diff --git a/privacy-track/labs/silent-payments/run_vectors.py b/privacy-track/labs/silent-payments/run_vectors.py index 6020235..7624168 100644 --- a/privacy-track/labs/silent-payments/run_vectors.py +++ b/privacy-track/labs/silent-payments/run_vectors.py @@ -7,9 +7,9 @@ python3 run_vectors.py send --solution # run the reference solution instead python3 run_vectors.py send -v # show got/expected on failure -The vectors are the ones Bitcoin Core, libsecp256k1, rust-silentpayments and -every other implementation test against. Passing them all means your code -interoperates with real wallets. +The vectors are the official ones published with BIP352 (Bitcoin Core, for +example, includes them in its unit tests). Passing them all means your code +follows the spec on every case they cover. """ import argparse @@ -188,7 +188,7 @@ def main(): total = passed + failed + todo print(f"\n{passed}/{total} vectors passing ({time.time() - start:.1f}s)") if passed == total: - print("All green. Your code agrees with every BIP352 implementation. 🟠") + print("All green: your code passes every official BIP352 test vector. 🟠") sys.exit(0 if failed == 0 and todo == 0 else 1) diff --git a/privacy-track/labs/silent-payments/send.py b/privacy-track/labs/silent-payments/send.py index 4ed1083..c1a22a6 100644 --- a/privacy-track/labs/silent-payments/send.py +++ b/privacy-track/labs/silent-payments/send.py @@ -2,7 +2,7 @@ Session 1 lab - build a Silent Payments SENDER (BIP352) Fill in the five functions below, then grade yourself against the official -BIP352 test vectors (the same ones Bitcoin Core and every wallet use): +BIP352 test vectors (the official ones published with the BIP): python3 run_vectors.py send diff --git a/privacy-track/resources/glossary.md b/privacy-track/resources/glossary.md index e8fb948..8276525 100644 --- a/privacy-track/resources/glossary.md +++ b/privacy-track/resources/glossary.md @@ -40,7 +40,7 @@ **Eligible input:** An input whose public key BIP352 can read from the spending transaction (P2TR key path or non-NUMS script path, P2WPKH, P2SH-P2WPKH, P2PKH with a compressed key). Only eligible inputs are summed into `A_sum`; sender and receiver must agree exactly on this set. -**Tweak indexer / index server:** A server that computes tweak data for every block so SP light clients don't have to fetch every transaction's prevouts. Examples: BlindBit Oracle, Shroud's indexer. A *remote scanner* (e.g. Frigate) instead receives the user's scan key and scans for them - faster, but the server sees incoming payments. +**Tweak indexer / index server:** A server that computes tweak data for every block so SP light clients don't have to fetch every transaction's prevouts. Example: BlindBit Oracle. A *remote scanner* (e.g. Frigate) instead receives the user's scan key and scans for them - faster, but the server sees incoming payments. **Tagged hash:** A domain-separated hash function defined in BIP340: `SHA256(SHA256(tag) || SHA256(tag) || data)`. Used throughout Silent Payments to prevent cross-protocol attacks. The tags "BIP0352/Inputs" and "BIP0352/SharedSecret" are used for input hashing and tweak derivation respectively. diff --git a/rawbit/README.md b/rawbit/README.md index e727039..c0e6ff6 100644 --- a/rawbit/README.md +++ b/rawbit/README.md @@ -267,7 +267,7 @@ Graduates are ready to: - **rawBit tool**: [rawBit.io](https://github.com/rawBit-io/rawbit) - Visual Bitcoin TX builder & Script debugger - **Upstream textbook**: [Programming Bitcoin](https://github.com/jimmysong/programmingbitcoin) by Jimmy Song -- **Partner**: Code Orange Dev School in collaboration with rawBit +- **Built on**: rawBit's open-source lessons ([rawBit-io/rawbit](https://github.com/rawBit-io/rawbit)), run as a study cohort by Code Orange Dev School --- diff --git a/sovereign-bitcoiner/README.md b/sovereign-bitcoiner/README.md index 6d76814..9d06081 100644 --- a/sovereign-bitcoiner/README.md +++ b/sovereign-bitcoiner/README.md @@ -8,7 +8,7 @@ ## Overview -The Sovereign Bitcoiner Crash Course takes curious Bitcoiners and transforms them into fully self-sovereign node operators, miners, and privacy advocates. Every graduate leaves with deployed, working systems - a running full node, a BTCPay server, a multisig inheritance plan, and the knowledge to defend their Bitcoin stack against both digital and physical threats. +The Sovereign Bitcoiner Crash Course is a hands-on course for Bitcoiners who want to run their own stack. Participants work towards setting up a full node, a BTCPay server and a multisig inheritance plan, and learn how to defend their setup against digital and physical threats. ## Prerequisites