Sigbash update: Passkeys, Price Feeds, and PSBT introspection!
Original beta announcement Xitter thread here:
X (formerly Twitter)
arbed_out (@arbedout) on X
Techie mumbo jumbo: when a user requests an xpub, Sigbash sends one to the client browser, and then on the client the WebCrypto API is used to choo...
Six weeks of beta testing and I can separate out the feedback I've gotten into two broad categories:
1) The oracle is useless (because I don't really need it)
and
2) The oracle is useless (because it doesn't do what I really need)
For 1) - I definitely didn't appreciate how many users just wanted to submit a form to get an xpub / have an xpub signed without any conditions. That's great! But also Sigbash v1 was kind of terrible for that - without any conditions, every xpub is effectively an xprv, since you can just present it to the signing server and we'll happily assume that your ownership of the key is enough proof that we should sign for you. Since everyone in your multisig quorum can theoretically see your xpub, that means everyone has your xprv. Not ideal!
I thought about this for a bit and settled on implementing passkey authorization - now you can associate a passkey with an xpub when you first request it, and we'll only sign for that xpub if the passkey is presented at signing time. Givs your xpub to whoever you like; we won't sign requests for it unless you present your Apple FaceID, or fingerprint TouchID, or Yubikey, etc.
(Side note: This is the first Bitcoin-y thing I've built that I've had my mom test on her phone. Wild feeling watching her authenticate with her FaceID to make a signing request.)
For 2): The original oracle could only check three conditions - the bitcoin network hashrate, or the balance of a given Bitcoin address, or the BTC/USD exchange rate. All conditions were evaluatedaft signing time.
I got a *ton* of requests for new conditions to commit to, so many that I refactored the entire oracle UI and backend. Now you can restrict Sigbash from signing a request for an xpub based on:
*the price of 170+ fiat currencies, precious metals, or crude oil;
*Treasury yields, SOFR or the Fed Funds rate;
*hashrate for a given mining pool or the entire network;
*daily Bitcoin transaction fees in USD;
*the balance of a Bitcoin address
Instead of just checking the value for the condition at the time a signing request is submitted, you can now specify values for a given date - e.g. "Sign if Luxor's hashrate on May 6 is greater than 100 EH/s" or "Sign if the exchange rate of Bulgarian Lev to USD on April 27 is above $.010/USD". This radically changes the value proposition of the oracle; you can now build incredibly complex conditional contracts from these basic building blocks.
Finally, and also to address 2) - I added PSBT introspection, which is a fancy way of saying you can restrict an xpub to only sign for a request if the sum of the inputs, outputs or transaction fees in the PSBT you submit for signing are above or below a certain value in satoshis.
The combination of these features - being able to build addresses with spending conditions dependent on price feeds, or hashrate, or the value of a given Bitcoin address, or the inputs and outputs of the spending transaction - are what I'm hoping will be available to Bitcoin users when there's widespread adoption and support for discreet log contracts and a soft fork that enables some form of covenants. Since we aren't there yet, my hope is that we can start building and testing the UX out for that future and progressively upgrade the Sigbash backend to provide users more sovereignty as new soft forks are activated and DLC oracles get better tooling and wallet support.
(And if covenants are never activated and DLCs never get much traction? We'll still have this imperfect-but-good-enough implementation to get the job done.)
Give it a spin at
https://www.sigbash.com, use code BETATEST to grab an xpub, and again please remember this could break at any time until we're out of beta. Thanks y'all, onward!
