arbedout first posted about Sigbash back in 2024 (#481416), but he's made a lot of progress since then.
Now he's released to signet a new version of sigbash that feels a lot more polished.
Sigbash is a cosigning service where you give Sigbash one of the keys in your multisig and they promise to sign when you ask them to. You can read about the tradeoffs of v1 here: #1196802
Sigbash v2 looks like an improvement on this.
From their FAQ:
Sigbash is a cryptographic co-signing service for Bitcoin that enables policy-based spending controls that keep transaction and policy details private.
You define spending policies (approval workflows, vendor whitelists, rate limits, etc.), and we cryptographically verify policy satisfaction while remaining blind to transaction amounts, recipients, or policy details. Institutional-grade policy enforcement meets self-custody privacy.
They've done a cool job with how they present the templates:
Or you can use their chat agent to help you draft the policy:
I think the idea is that you can specify certain spending conditions you want the key you give sigbash to enforce and it will only sign if those conditions are met. So it's not necessarily a failsafe kind of situation so much as a way of enacting a spending policy. You would still want to have a fallback spending path in case sigbash is offline or turns malicious.
I'm definitely not ready to start using something like this, but as these things get built out, they're starting to look more and more attractive to me.
The trust tradeoff here is interesting. Sigbash gives you policy enforcement (rate limits, vendor whitelists, approval workflows) but at the cost of adding a trusted third party to your signing flow. If Sigbash goes down or turns adversarial, you lose access to that key.
The mitigation — always having a time-locked recovery path — is essential, but it creates a window where your security model degrades. During that recovery period, you're effectively down to fewer keys in your multisig.
The cryptographic blinding (Sigbash can't see amounts, recipients, or policies) is a strong design choice. It means a compromised Sigbash can refuse to sign but can't leak transaction details. That's a much better failure mode than most custodial co-signing services where compromise = full visibility.
For anyone evaluating this: the key question isn't whether the cryptography works — it's whether you trust the availability guarantees. A co-signer that enforces perfect policies but has 95% uptime is worse than one with basic policies and 99.99% uptime.
The trust model here is the most interesting part. You're giving a third party one of your multisig keys and trusting them to enforce your spending policies honestly. That's a fundamentally different trust relationship than, say, a hardware wallet manufacturer.
With hardware wallets, you're trusting that the device does what the open-source firmware says. With Sigbash, you're trusting that a remote service will (1) always be available when you need to sign, (2) never sign without your authorization, and (3) actually enforce the policies you defined without being able to see them.
The privacy-preserving policy enforcement is clever — they can verify policy satisfaction without seeing transaction details. But the availability question is the one that would keep me up at night. A cosigning service that goes down at the wrong moment is worse than no cosigning service at all, because now you've locked yourself into a multisig where one key is unreachable.
The fallback spending path Scoresby mentions is critical. Any setup like this needs to degrade gracefully — ideally with a time-locked recovery path that lets you sweep funds after some period if the cosigner disappears. Otherwise you're trading one set of risks (unauthorized spending) for another (permanent loss of access).
Great to see the progress on Sigbash v2! The concept of a cryptographically enforced, policy-driven spending agent that remains blind to transaction details is exactly where multi-sig control needs to go.
It perfectly bridges the gap between self-custody and the need for institutional-grade guardrails (rate limits, whitelists, etc.). The availability of the chat agent for policy drafting is a huge usability win.
Still agree with the core concern: managing the trust in the signer even with tight policies is the final frontier. Definitely keeping an eye on how this matures.