Hey all,
@setzeus has passed me the calendar event for the Clarity Working Group, shared the slides, and will share the operating rules shortly. Huge thanks to him — his deck’s last slide lists 35 sessions over the past two years, from his first on May 14, 2024 to today’s, his last before handing off. The community owes him a lot for keeping that rhythm going.
I’m keeping the same slot Setzeus has been running: every 2 weeks on Tuesdays, 9:00–9:30 AM ET. Next session: Tuesday, May 26.
A few things I want to be clear about from day one:
I’m not the owner of the Clarity WG. Everyone in this community is as much an owner of it as I am. I’m simply trusted with the calendar event — showing up reliably, and coordinating/vetting guests.
What this means in practice:
-
Clarity devs are warmly invited to collab. If you want to present, demo something you’re building, or open a topic for discussion, please reach out.
-
Office-hours sessions are fine too. If nobody has prepared anything for a given slot, that’s okay — conversations happen, questions get asked, no pressure.
-
I’ll usually share one or two things from the Clarity code I’m currently working on. But please don’t expect deep dives into topics like Lamport signatures, at least not when I’m starting out. I’m here to learn alongside everyone, not lecture from above.
Thank you for the opportunity. I’ll take it seriously, and honestly I see this as much an opportunity for me to learn from all of you as it is to coordinate the space.
If you have a topic in mind, or want to be slotted in for the May 26 session (or any after), drop a reply here or DM me.
— Rapha
5 Likes
This Tuesday, May 26, the Clarity Working Group meets at 9:00–9:30 AM ET — same calendar event and link @setzeus has been running. It’s a packed 30 minutes with three short topics, and Clarity devs are warmly invited to join, ask questions, and jump into the discussion.
@ECBSJ opens with Bitcoin Staking on L1 — why the staking commitment is locked with a P2WSH script rather than P2SH or P2TR, and the mechanics and UX tradeoffs behind that choice from the Bitcoin Staking whitepaper.
@BowTiedRadone follows with Rendezvous (RV) fuzzing, walking through how version 1.0 does property-based, invariant testing of Clarity contracts, along with the roadmap — a joint announcement with Clarinet is in the works.
If there’s time, I’ll close with Vini.btc’s cross-chain attack on a BTC↔STX swap contract and a second bug that RV fuzzing caught in JingSwap — two hacks avoided before they ever created any havock.
Come by even if you’re just curious — office-hours-style conversation is always welcome. And if you’d like a slot in a future session, or want to demo something you’re building in Clarity, reply here or DM me.
— Rapha
Slides: Jing Swap, Swap big from Bitcoin to USDC on Stacks.
1 Like
Thank you everyone. Stellar pres by @ECBSJ and @BowTiedRadone
Also great share by @setzeus . Please find fireflies notes below!
- Script Choice Justification: P2WSH offers compatibility, simplicity, and deterministic address creation for Bitcoin staking over complex Taproot.
- Hardware Wallet Impact: Taproot’s complex reclaim paths challenge wallet integration; P2WSH avoids exposing sensitive keys.
- Rendezvous v1.0 Enhancements: New tool features flexible testing, auto-saves failures, and enforces property-based tests for mainnet safety.
- Bitcoin Script Advances: Research on OP_CTV focuses on secure covenants and automated Bitcoin vaults to enhance custody security.
- Collaborative Culture: Team values input on Bitcoin staking details and expresses ongoing enthusiasm for knowledge sharing and learning sessions.
Notes
Bitcoin Staking Script Design and Technical Choices
The team clarified why Bitcoin staking on Stacks uses Pay to Witness Script Hash (P2WSH) instead of Pay to Taproot, balancing compatibility and technical constraints.
-
P2WSH chosen for Bitcoin staking due to compatibility and simplicity (01:02)
-
P2WSH uses native Segwit v0, widely supported by wallets and institutions.
-
It allows deterministic creation of addresses from one script commitment, easing user reasoning.
-
Pay to Taproot offers script privacy and multiple spending paths but adds complexity.
-
Pay to Taproot’s complex script tweaking cannot currently be validated in Clarity smart contracts, which lack 256-bit math support.
-
Hardware wallet constraints influenced the script choice (09:14)
-
Ledger and other wallets have difficulty supporting Taproot reclaim paths as required for Bitcoin staking.
-
Stacks Labs avoided requiring users to expose sensitive keys needed for Taproot on Ledger.
-
Bitcoin staking’s use of Clarity to confirm locking scripts further limits Taproot use due to math and validation gaps.
-
Legacy Pay to Script Hash (P2SH) was rejected for inefficiency (05:44)
-
P2SH is less efficient in size and fees compared to P2WSH.
-
Lock times on Pay to Public Key Hash (P2PKH) lack support for script embedding, limiting flexibility.
-
Differences highlighted between SBTC bridge and Stacks Bitcoin staking approaches (06:42)
-
SBTC uses Pay to Taproot with hidden reclaim and sweep paths, visible only when spent.
-
P2WSH scripts expose all conditional paths on spending, making them transparent on-chain.
-
This transparency tradeoff is accepted for better wallet support and clarity integration.
Rendezvous v1.0 Release and Testing Enhancements
Rendezvous v1.0 launched as a production-ready fuzzing tool with improved workflow, AI friendliness, and developer usability.
-
Rendezvous v1.0 integrates simnet environment annotation and config files for flexible testing (15:00)
-
Tests no longer inject into contract source but compile separately for simnet and mainnet.
-
Config files replace complex CLI flags, enabling multiple testing scenarios (e.g., nightly runs, regression).
-
Real mainnet accounts can be included in simnet testing through config-based principal specification.
-
Failures during testing are now automatically saved to disk for regression testing (18:57)
-
Captured failures store seed, dial path, hooks, run counts, and timestamps.
-
Developers can rerun regression tests to catch known bugs efficiently.
-
This automation reduces manual bug tracking and improves test reliability.
-
Breaking change enforces property-based tests and context functions as private (20:30)
-
Prevents accidental inclusion of test functions in mainnet contracts.
-
Adds a safety guard reflecting real-world deployment risks.
-
Users upgrading to v1.0 must modify their tests accordingly to avoid failures.
-
Plans to make Rendezvous AI-friendly aim to lower technical barriers (22:50)
-
Future versions will support AI agents to assist writing invariants and properties.
-
The goal is to help operators find bugs without deep testing knowledge.
-
Possible plugin-based AI integration will maintain platform neutrality and ease of use.
Insights on Bitcoin Script Advancement and Covenants
The discussion covered ongoing research into Bitcoin script opcodes, especially OP_CTV, and their potential impact on script security and vault design.
-
Jesus Najera is actively researching Bitcoin script upgrades including Covenants (28:36)
-
Focus on OP_CTV as a simple, secure covenant opcode proposed since 2020.
-
OP_CTV checks that a spent transaction matches a pre-committed transaction exactly.
-
Covenants enable defining strict spending rules, useful for vaults or multi-party controls.
-
OP_CTV’s potential for secure, automated Bitcoin vaults was highlighted (34:20)
-
It allows locking funds to only move along predefined transaction paths.
-
Example use case: a family vault restricting spending only to trusted addresses.
-
This reduces risk even if keys are compromised, improving Bitcoin custody security.
-
Current testing environments for OP_CTV include Mutiny Net and Bitcoin Inquisition (33:41)
-
Mutiny Net integrates some covenant flavors for experimentation.
-
Bitcoin Inquisition is an experimental client supporting new opcodes for testing.
-
These networks provide practical grounds to tinker with upcoming script features.
-
OP_CTV is considered the simplest and safest covenant flavor with strong community review (32:41)
-
More complex covenant proposals face stronger opposition due to increased risk.
-
OP_CTV’s long standing and simplicity boost its likelihood of adoption.
-
Jesus plans to publish an article detailing covenant design and benefits soon.
Strategic and Operational Perspectives
The team expressed openness to collaboration, shared operational updates, and reflected on the value of recent contributions.
-
Eric Choy encouraged further input from Stacks Labs on Bitcoin staking technical details (13:25)
-
Rapha Sierra shared positive user experience with SBTC bridge reclaim functionality (14:12)
-
The reclaim process worked smoothly, reinforcing confidence in the protocol.
-
This practical insight validates some of the technical choices discussed.
-
Rendezvous bug detection credited for uncovering edge case coding errors (23:10)
-
Team expressed enthusiasm for continued learning and future presentations (35:56)
-
Rapha thanked presenters and expressed interest in further sessions.
-
Jesus Najera offered to discuss Bitcoin script research anytime.
-
The positive tone suggests ongoing collaboration and knowledge sharing ahead.
Action items
Radu Bahmata
- Provide Rapha RSierra with information about the second bug identified in Rendezvous for PR submission (27:21)
Rapha RSierra
- Verify details of the second bug in Rendezvous and submit a PR if applicable (27:43)
Participants at Stacks Labs
- Share further technical details about Bitcoin staking design and script implementations to fill knowledge gaps within the group (13:25)
Jesus Najera
- Prepare and publish an article explaining Covenants and related opcodes such as OP_CTV (32:41)
Anyone interested
- Reach out to Jesus Najera for detailed discussions on Bitcoin Script research and Covenants (37:02)
Clarity Working Group — Tuesday, June 9: New Bitcoin functions in Clarity 6 + secondlayer
This Tuesday, June 9, the Clarity Working Group meets at 9:00–9:30 AM ET — same calendar event and link @setzeus has been running. Two topics this round, and as always Clarity devs are warmly invited to join, ask questions, and jump into the discussion.
@brice opens with the new Bitcoin functions coming in Clarity 6 — the new built-ins that let Clarity contracts read and verify Bitcoin state directly, what they unlock, and how they change what’s possible on-chain.
Ryan Waits follows with secondlayer (secondlayer.tools) — the agent-native data plane for Stacks. The chain emits events; apps and agents need them in any shape. Ryan will walk through how its Streams firehose serves every Stacks event as an immutable, cursor-paginated, reorg-aware log — so you can build indexers and higher-level APIs without ever running a node — plus Index, Subgraphs, Subscriptions, and the curated Foundation Datasets layered on top.
Come by even if you’re just curious — office-hours-style conversation is always welcome. And if you’d like a slot in a future session, or want to demo something you’re building in Clarity, reply here or DM me.
1 Like
