If you're not familiar with extended public keys, multi-signature setups, or Partially Signed Bitcoin Transactions, then Sigbash may seem a bit intimidating at first.

Extended Public Keys (xpubs) allow Bitcoin wallets to generate a sequence of public keys without revealing the private keys, enhancing security and privacy. You can use your extended public keys as one key, the extended public keys of a friend, relative or counterparty as a second key, and a Sigbash blinded extended public key as a third key in a 2-of-3 multisig setup.

Multi-signature (multisig) setup refers to requiring multiple keys to authorize a Bitcoin transaction, rather than a single signature from one key. This setup increases security by distributing the risk among multiple devices or parties.

Partially Signed Bitcoin Transactions (PSBTs) are a standard format for transactions that are not fully signed. Multiple parties can sign a transaction by passing a PSBT file back and forth between each other.

Because Sigbash will only sign under certain conditions, a 2-of-3 multisignature address that makes use of Sigbash can have funds locked up until either two parties agree to spend funds, or until a condition attached to the Sigbash xpub is met. These conditions include:

Signing time restrictions such as only signing a transaction:

• after a certain date or block height has been reached
• or if a passkey (such as a a FaceID, fingerprint or NFC key) has been presented

• the price of Bitcoin (or any of 170+ fiat currencies, or commodities like crude oil, gold or copper) is above or below a specified amount of dollars on a specified date
• or if the rate of Treasury yields or SOFR is above or below a certain percentage on a specified date
• or if the hashrate for the entire Bitcoin network, or a given mining pool is above or a below a given amount of EH/s
• or if the balance of a given Bitcoin address is above or below a certain amount on a certain date

• the total value of the inputs
• the total value of the outputs
• the total value of transaction fees

There are broadly speaking two conditions where both oracles and key agents can fail to live up to user's expectations:

1. Signing a transaction that shouldn't be signed: e.g. if the conditions associated with the xpub in a PSBT submitted to Sigbash haven't been met.


2. Not signing a transaction that should be signed. e.g. if the conditions associated with the xpub in a PSBT submitted have been met, or there are no conditions at all.

To safeguard against these scenarios, when an xpub is first purchased we provide a receipt that includes a SHA256 hash of the xpub (because we never see the actual xpub - read 'What sort of privacy does Sigbash offer?' for more details), along with the date it was purchased as well as any conditions that were associated with the xpub. We then sign that receipt with our GPG key (Key ID: 601993EC97CE3A71) and provide the signed receipt as well as a signed OpenTimestamps .ots file for the GPG-signed receipt, proving that the receipt was signed on or before the date the xpub was issued.

• Reach out to support at sigbashsupport [at] proton [dot] me This is most likely a bug (Sigbash is still beta software!) Provide us with the signed receipt and the PSBT you're trying to sign, and we'll either manually intervene to sign the request or confirm that the conditions to sign haven't been met. If you feel this is in error, you can always share your signed receipt and PSBT publicly; this won't get your request signed, but if the signing request was valid it will effectively take Sigbash offline - in the sense that no user should ever trust a key agent that was proven to refuse to sign a valid request even once.

  To further protect against this scenario we'd recommend either having the other members of the quorum sign your PSBT and/or building a timelock into your PSBT to allow you to recover any locked funds after a certain amount of time.

• Assuming at least a 2-of-3 threshold multisignature, this would require at a minimum one member of the multisig quorum to be malicious. In the event that Sigbash signs a request whose conditions aren't valid, again: publicly share the signed receipt along with the transaction that includes the xpub provided by Sigbash. Your transaction can't be reversed, but the first time this ever happens Sigbash becomes an untrustworthy third party.

Sigbash does not require an account, a username, an email, a driver's license, a Social Security Number, or any contact information. You don't need any personal identifying information to use Sigbash.

Sigbash is available over Tor. If you connect to our Tor .onion domain at 5dsaboekmamlwfhbrqd5d6jk6vbx7hun6ftyie2cskcl63zbnkqmdpyd.onion , you will not reveal your IP address to us.

Sigbash implements blinded xpubs, based on the blind xpubs scheme implemented in the buidl-python library). Our servers send your browser an xpub, and in your browser session, we securely generate a series of random numbers. We then use those random numbers to choose an arbitrary BIP32 derivation path for the xpub we've provided, and send back the sha256 hash of the xpub to our servers. This means that from the time an xpub is first issued until a request is signed, we have no visibility into who is using it or what funds it is protecting.

Adapted from the blind-xpub documentation:

If a bad actor gets unauthorized access to the Sigbash seed, they learn nothing about what it protects. This scheme enables 1 (or more) semi-trusted collaborative custodians to hold an emergency recovery key in your multisig quorum with zero knowledge of what they're protecting, which can make it far easier to achieve geographic, jurisdictional, and/or organizational diversity.

At the time of key generation up until revealing the xpub you would like us to sign for (with secret BIP32 path), Sigbash is unable to learn anything about the Bitcoins being protected, including:

• Transaction history (including any spent UTXOs) & balance
• Quorum information

If Sigbash were malicious (or compelled by a government), they would not be able to reveal any identifying information. Also, because this is built on top of existing BIP32 path standards, it is already compatible with many existing Hardware Wallets and Coordinator libraries (read 'What Software Can I use with Sigbash blinded xpubs?' ).

Consider the following scenarios:

Scenario 1: You use Sigbash from your home Internet connection to purchase an xpub, and use that xpub in a multisig quorum. If you ask Sigbash to sign, we'll be aware of the IP address that purchased the xpub, the IP address that requested the PSBT to be signed, and at signing time, the xpubs of the other members of the multisig quorum, quorum information (e.g. 2-of-3), and the transaction history and balance of any funds coming into the multisig address as well as the amount and destination of any funds being spent from the address.

Scenario 2: You purchase an xpub from Sigbash over Tor, a VPN, or a public WiFi access point, and use that xpub in a multisig quorum. If you ask Sigbash to sign, the IP address that purchased the xpub and asked for the xpub to be signed will be unavailable to us (if using Tor) or not usable as identitfying information (if using VPN or public WiFi). At signing time, we'll know the xpubs of the other members of the multisig quorum, quorum information (e.g. 2-of-3), and the transaction history and balance of any funds coming into the multisig address as well as the amount and destination of any funds being spent from the address.

Scenario 3: You purchase an xpub using Sigbash over Tor, and use that xpub in a multisig quorum. The other members of the quorum use xpubs that have also been blinded (using the buidl-python library), and all UTXOs going into the multisig address are mixed beforehand and mixed again after being sent to the destination address. If you ask Sigbash to sign, the IP address that purchased the xpub and asked for the xpub to be signed will be unavailable to us (if using Tor) or not usable as identifying information (if using VPN or public WiFi). At signing time, the transaction history, quorum information (e.g. 2-of-3) and balance of any funds coming into the multisig address as well as the amount and destination of any funds being spent from the address are known, but the information cannot be used to identify users if the funds going into and being spent from the address have been properly mixed.

Scenario 4: You purchase an xpub using Sigbash over Tor, and use that xpub in a multisig quorum. Instead of submitting a PSBT to Sigbash to sign, you reveal your Sigbash GPG-signed receipt with OpenTimestamps attestation to the other members of the quorum, or you can just reveal the Sigpash xpub and ask the other members of the quorum to verify the conditions If you reveal to them either the Sigbash receipt or the Sigbash xpub to verify on our site (see the 'Verify xpub' tab), and they choose not to reveal the PSBT to Sigbash and instead sign themselves, we will not be able to identify the transaction spending these funds or any related addresses or transactions by scanning the Bitcoin blockchain.

Adapted from the blind-xpub documentation:

What's amazing about blinded xpubs is that because they takes advantage of existing standards (BIP32 and output descriptors) they already work on the bitcoin network! Adding support is usually a matter of just eliminating restrictions on BIP32 paths, not adding any new functionality.

Signers

Under regular use, Coldcard cannot import enhanced-privacy multisig wallets for address validation, nor co-sign a transaction using regular/unblinded paths (unless you disable essential safety checks: Settings > Multisig Wallets > Skip Checks).

Beta status: Sigbash is currently beta software. You should expect multiple unexpected things to break in strange frustrating ways.

Single use: Each Sigbash xpub can only be signed for once; after a PSBT is signed we will mark the xpub as having been redeemed and refuse to sign any future PSBTs with that xpub. If you need a multi-use xpub, reach out to support at protonmail.com and we'll discuss terms with you, but please be advised that re-using the same blinded xpub multiple times will degrade the privacy model considerably. You are almost certainly better off purchasing multiple single-use xpubs than you are re-using an xpub multiple times.

Lack Of Warranty: Sigbash's services are offered "as-is". There are no warranties offered, expressed or implied. Services are available on an "as is" and "as available" basis. There is no warranty of operation without errors. The user bears sole risk for use. Sigbash cannot be held liable for specific types of damages related to the construction, finalization or broadcasting of PSBTs. The maximum amount of liability for which Sigbash can be held liable is the price paid for a single-use xpub. It is entirely possible to use Sigbash xpubs in ways that lose massive amounts of funds or incur legal liability for users funding multisig addresses created using those xpubs, spending funds from said addresses, or broadcasting PSBTs with those addresses. The sole responsibility for the responsible creation and usage of addresses and transations that make use of Sigbash xpubs resides with the user.