Script is smart, keys are dumbScript is smart, keys are dumb
In Bitcoin, we tend to think of keys as being dumb. Bitcoin script expresses the rules of a wallet, the key (or keys) simply show up and sign off on the thing.
For example, a typical 2 of 3 multisig wallet has a script that checks to see if at least two of the three listed keys signed the transaction. The keys just show up, they don't express anything about the threshold or even that other keys are required.
While Bitcoin script is notoriously limited and difficult to reason about, there are cool things like Miniscript that help developers build wallets that can do complicated things like decaying multisigs.
Exporting logic to your keyExporting logic to your key
There's another way to do things, though: you may have heard of Shamir's secret shares. This is a process where you break a key up into pieces with the property that anyone with access to a certain threshold of the shares can reassemble the whole key. You could make a multisig this way, too.
For instance, you could make 2 of 2 out of a key by splitting it into two shares. This seems like a pretty risky thing to do but you could further split each of the 2 original shares into 2 of 5 shares and now you actually have a somewhat durable system where the Bitcoin key can be reassembled as long as you can find two of the shares for each group of shares.
Depending on how you store the shares, you can create a number of interesting constructions. Unfortunately, you still have to recreate the original key when it comes time for signing. But as far as the Bitcoin script for this transaction goes, it's pretty simple: it just looks like a single key signed a basic transaction. This is because all the logic of the multisig is shifted to how the key was stored.
"AND is a multisig, OR is a shared secret""AND is a multisig, OR is a shared secret"
Now, some people have come up with a new scheme called "Boolean circuit Logic Integrated into the Single Key (BLISK)." This is a way of using how you generate your key to create the rules for how it gets spent.
So what if we justโฆ composed them?
- ๐ -of- ๐ multisignatures naturally implement an AND gate: all participants must contribute for a signature to be valid. That's literally what "and" means
- key agreement protocols implement OR: in a key agreement (like Diffie-Hellman), any single participant can derive the shared secret. That's literally what "or" means
The BLISK idea is to use two different ways of generating a key as primitives to encode a kind of logic into a Bitcoin key. It's actually pretty surprising how many different constructions you can make with just with "AND" and "OR."
For instance, imagine you have a company where large transactions need to be signed off by the CEO and at least one member of a 5 person board.
In traditional script-based multisig, this would be complicated. Using Tapscript it gets a little easier (I think...but to be honest, I'm not so great at script).
Using the key generation technique outlined by BLISK, such a wallet would be fairly easy to construct and onchain would not look any larger than a single-sig signature.
This sounds a little like MuSIg2 and FROST. I'm not entirely clear on the trade-offs between the two. But it seems like all three (BLISK, MuSIg2, and FROST) are ways of shifting the logic of your spending rules to the key generation process.
Trade-offsTrade-offs
- CNF Blowup: Converting arbitrary formulas to CNF can exponentially increase size. In practice, most real policies are manageable, but be aware.
- Monotone Only: No negations. You can't express "NOT Alice."
- Proof System Choice: OR gates require zero-knowledge proofs to make a resolution publicly verifiable. Your choice of proof system (SNARKs, Bulletproofs, etc.) affects setup assumptions and verification costs. In our reference example it's Bulletproofs.
- Liveness: Like any multisig, if required participants go offline, you can't sign. BLISK doesn't solve the coordination problem; it just makes the authorization problem more expressive.
BLISK is still a bit of an experiment, but it seems like something worth paying attention to.
@0xbitcoiner posted about this a few days ago here: #1420637
just to be a bit more explicit about this... it's not the wallet that has the script. you may have used a piece of software that helped you construct the address in a way you could sign for, but it's the UTXO which contains the rules about whether you can spend it to somebody else.
wallets aren't real, manwallets aren't real, man
when you received the bitcoin into that multisig situation, you computed an address for the sender to direct it to... and then the nodes determined to include a valid transaction in the chain.
in order to spend that UTXO which was sent to you, you must be able to calculate a signature which any node will perceive as being a valid signature to include in a block. and since your multisig software situation will not be available to the validators, the UTXO contains the necessary details for a validator to determine if the signature is valid.
that's not to say there aren't things that seem like walletsthat's not to say there aren't things that seem like wallets
wallets are a useful abstraction, but it's important to remember that the only thing that matters are the keys. wallet software gets used to construct keys, and when We go around talking to people about "wallets" the noobs can get confused about what is going on... that's why it's often such a delightful experience to put your xpub into a new piece of software and be able to 'see your coins' just sitting there. it feels like magic because the abstraction we have taught ourselves doesn't match the reality.
I'm pretty sure modern wallet software (especially any wallet software that can make multisigs) mostly uses descriptors. When you make a backup in something like Sparrow or Nunchuk or Liana, it will do so as a descriptor. I think it's okay to tell people that a wallet = a descriptor.
If you have a multisig, this is not true. Without some idea of how to compose the keys, having the keys won't help you when it comes time for spending. You need to have the descriptor.
Sure, as far as validators go, they just want to see a locking script and an unlocking script, but if they are your coins, and you want to succesfully generate an unlocking script, you need a bit more information than just a quorum of keys. You have to know how to create the signature.
Finally, I wanted an easy way to distinguish between a spending policy and the keys which may be required by the spending policy. Wallet software pretty much follows the rule of one spending policy = one wallet.
For instance, in Sparrow, you might create two different spending policies: one that is a multisig and another that is a single sig. It's even possible that the key you use in the single sig is also part of the quorum for the multisig. Sparrow will show these two you as two separate wallets. I think this is a good way to do things.
Wallet software ties one and only one specific spending policy to a wallet. I've never yet used a wallet that let you have multiple spending policies within a single wallet.
I totally flubbed that explanation, by using wrong word.
s/keys/signatures
if you can't sign, u can't spend. only thing that matters is the signatures
that's true. the descriptor points to the private sig, same way it points to the public address
yah, because the sig construction follows the same pattern as the address construction.
... and 0 sats received! ahahah
thanks!
It's funny how some of these slip through the cracks.