Happy year 45x45!
Stay laser-focused, and let's make it the best year for Bitcoin, fair and square.
salvatoshi
npub157y6...60gr
#bitcoin
Merry Christmas to those who cerebrate — I hope you have some bright thoughts.
My comments on the proposed opcodes in the "Covenants support" page:
I think it's not very meaningful to "support" specific opcodes: most opcodes are not very good in isolation, but might be good in the right combination.
A soft-fork can enable multiple opcodes, and it should be a coherent set of changes that does one or a few things well.
Therefore, I think it's more important to identify and discuss the "primitives" that the opcodes (and packages of opcodes) can enable.
I identify the following tentative list of primitives enabled (one way or another) by the various proposals:
- commitments to transactions
- signing a message
- vector commitments
- concatenation
- state-carrying UTXOs
- multi-step transactions
- generic introspection
I argue that if some opcodes poorly enable a valuable primitive, then other opcodes that implement that primitive _well_ should be enabled together.
Otherwise, we're shooting ourselves in the foot with the bloat that will inevitably come.
I discuss my opinion on whether or not it might be dangerous to enable new primitives in Script.
Finally, I suggest a potential minimal package of opcodes that would enable _all_ the identified primitives pretty well, while each is fairly simple and self-contained:
- OP_CTV
- OP_CAT
- OP_CCV
- OP_CSFS
- OP_AMOUNT
Gist
Opcodes Zoo
Opcodes Zoo. GitHub Gist: instantly share code, notes, and snippets.
To me, quantum computing is an attempt to cheat nature. I think (and hope) that it won't work. I like the Church-Turing thesis, and I'd like the model of "what computation is" to be something that the human brain can understand without a PhD in physics.
Grover's algorithm, for me, is not a "result" of quantum computing. It is the counterexample. You mean to say that you can find a specific object among a random collection of N objects in just sqrt(N) work? Give me a break!
My bet is that something that is not yet understood will physically prevent scaling quantum computers. You want reliable quantum computation with n bit? Then the cost of running this machine will grow exponentially in n.
Join the Church-Turing maxis, say #NoToQuantumComputers
My bet is that something that is not yet understood will physically prevent scaling quantum computers. You want reliable quantum computation with n bit? Then the cost of running this machine will grow exponentially in n.
Join the Church-Turing maxis, say #NoToQuantumComputers
At TABConf 6, I gave a talk on the UX challenges of hardware signing devices.
Video:
Slides: 
I talk about why it's hard (but not unsolvable!) to provide a good and secure UX for complex spending policies.
Then, I discuss about the biggest offender: addresses.
TL;DR:
Today's UX of signing devices is centered around low-level objects of the bitcoin protocol: addresses, and transactions.
My claim is that a good UX can only be built by redesigning it around two much more familiar concepts:
accounts and identity
Working on secure support for descriptors & #miniscript, my initial focus has been to provide a secure flow with a good enough UX to be usable in practice.
And if you tried #Liana, you know it is!
But registration is certainly not yet optimal.
When you register a new miniscript policy, you teach your device to recognize all present and future addresses of the account described by that policy.
Once registration is finished, you have a UX that is not more complicated than your typical single-sig transaction.
Thanks to this registration of BIP-388 wallet policies (https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki), any additional complexity coming from the fancy scripts is limited to a one-time event.
While not ideal, that's acceptable; it takes just a few minutes to go through the entire registration flow.
But that's hardly the end of the story.
Our brain is just bad at processing addresses, and this makes people lose money.
The key observation is that while accounts solve the UX problems for the internal UTXOs in a transaction (that is, the inputs you're spending, and also the change outputs), we're still offloading to the user the responsibility of checking the address of the external outputs.
But the user doesn't care about the address where the money is going.
The user only cares about who owns the address. If the signing device can guarantee that you
Send 0.1 ₿ to Bob
than that's all the the users really cares to check. Bob's address is Bob's business.
Therefore, what we want in payment instructions is not just addresses, but rather authenticated addresses: information that is given to wallets and signers must be enough to guarantee the provenance of the address.
So, how can we authenticate addresses?
That's the hard part. Not because it's difficult, but because there's no one-size-fits-all solution, and the best way depends on the specific situation.
But there are several promising approaches.
In same cases, we could use the account information! After all, if we're sending to another of your accounts, or your partner's account, or maybe the account of some other business unit of your company, then the receiver might be happy to share the BIP-388 wallet policy with you.
Today, we're only using the account info to authenticate the inputs and the change address.
If that info is added to the PSBT for external outputs, we could show:
Send 0.1 ₿ to your wife's account
which would surely be a better UX!
Something that clicked for me recently is the following:
Silent Payments (BIP-352) are just another type of account! They can fit perfectly well in this account-based UX flow.
They are inherently tied to an identity, and they allow you to generate authenticated addresses.
Finally, if knowledge of the receiving account isn't possible, there's still something that we can do: have the owner sign the address.
If we have a guarantee that the key signing the address belongs to the expected receiver, then we can spare the user from checking the address.
You could exchange keys in person if that's feasible; or approaches like BIP-353 (https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki) using DNS might be practical in many situations - for example, for public entities like companies and exchanges.
Identity would also help in further improving the UX of account registration: the xpub of your cosigners could also be authenticated in the same way, simplifying the registration flow:
I hope to inspire more people to think about this problem.
There is still a lot to do, for example:
- What is the best way to present the spending policy of a complex miniscript-based account to the user?
- How to encode the 'account' information in the PSBT?
- What support should hardware signers provide to support identity and authentication of addresses/xpubs?
There is nothing inherently difficult in tackling this. No fancy cryptography or moon math is required.
Just good standards to properly define and implement across vendors and wallets.
Google Docs
Entropy, miniscript and hardware signers
Entropy, miniscript and hardware signers Salvatore Ingala @salvatoshi
But registration is certainly not yet optimal.
When you register a new miniscript policy, you teach your device to recognize all present and future addresses of the account described by that policy.
Once registration is finished, you have a UX that is not more complicated than your typical single-sig transaction.
Thanks to this registration of BIP-388 wallet policies (https://github.com/bitcoin/bips/blob/master/bip-0388.mediawiki), any additional complexity coming from the fancy scripts is limited to a one-time event.
While not ideal, that's acceptable; it takes just a few minutes to go through the entire registration flow.
But that's hardly the end of the story.
Our brain is just bad at processing addresses, and this makes people lose money.
X (formerly Twitter)
mononaut (@mononautical) on X
Did you spot it?
Yep, the stolen funds were sent to an address that matches the first 5 and last 2 characters of the address DMM routinely uses to...
The key observation is that while accounts solve the UX problems for the internal UTXOs in a transaction (that is, the inputs you're spending, and also the change outputs), we're still offloading to the user the responsibility of checking the address of the external outputs.
But the user doesn't care about the address where the money is going.
The user only cares about who owns the address. If the signing device can guarantee that you
Send 0.1 ₿ to Bob
than that's all the the users really cares to check. Bob's address is Bob's business.
Therefore, what we want in payment instructions is not just addresses, but rather authenticated addresses: information that is given to wallets and signers must be enough to guarantee the provenance of the address.
So, how can we authenticate addresses?
That's the hard part. Not because it's difficult, but because there's no one-size-fits-all solution, and the best way depends on the specific situation.
But there are several promising approaches.
In same cases, we could use the account information! After all, if we're sending to another of your accounts, or your partner's account, or maybe the account of some other business unit of your company, then the receiver might be happy to share the BIP-388 wallet policy with you.
Today, we're only using the account info to authenticate the inputs and the change address.
If that info is added to the PSBT for external outputs, we could show:
Send 0.1 ₿ to your wife's account
which would surely be a better UX!
Something that clicked for me recently is the following:
Silent Payments (BIP-352) are just another type of account! They can fit perfectly well in this account-based UX flow.
They are inherently tied to an identity, and they allow you to generate authenticated addresses.
Finally, if knowledge of the receiving account isn't possible, there's still something that we can do: have the owner sign the address.
If we have a guarantee that the key signing the address belongs to the expected receiver, then we can spare the user from checking the address.
You could exchange keys in person if that's feasible; or approaches like BIP-353 (https://github.com/bitcoin/bips/blob/master/bip-0353.mediawiki) using DNS might be practical in many situations - for example, for public entities like companies and exchanges.
Identity would also help in further improving the UX of account registration: the xpub of your cosigners could also be authenticated in the same way, simplifying the registration flow:
I hope to inspire more people to think about this problem.
There is still a lot to do, for example:
- What is the best way to present the spending policy of a complex miniscript-based account to the user?
- How to encode the 'account' information in the PSBT?
- What support should hardware signers provide to support identity and authentication of addresses/xpubs?
There is nothing inherently difficult in tackling this. No fancy cryptography or moon math is required.
Just good standards to properly define and implement across vendors and wallets.
At @btcplusplus in Austin this May, I presented the pymatt Python framework, showing how to use it to implement vaults that are comparable to OP_VAULT using OP_CHECKCONTRACTVERIFY + OP_CTV.
Timestamps:
- Intro to MATT:
- Vaults:
- Vault demo:
- Code in pymatt:
V for V _ n _ _ _ _ _
Coming in 2025.
Amethyst could maybe add a "call to action" when this happens: what can the user do to fix the situation? Nothing happens when I tap it.
cc @Vitor Pamplona
See you at @TABConf 8 - Oct 12-15, 2026 ATL!
If you're working on a MuSig implementation and you have a Ledger device (except Nano S), feel free to test the "Bitcoin Test Musig" app!
Instructions on this repo; you'll be able to sign testnet transactions using musig (both in the keypath, or the script path) in 5 mins.
GitHub
GitHub - LedgerHQ/moosig: Fun with MuSig2 and Ledger devices 🎵
Fun with MuSig2 and Ledger devices 🎵. Contribute to LedgerHQ/moosig development by creating an account on GitHub.
If you often use regtest, you often need to manually mine blocks to test things.
If you're on linux, add this to ~/.bashrc:
```
mine() {
if [ "$#" -eq 0 ]; then
bitcoin-cli -regtest -generate 1
else
bitcoin-cli -regtest -generate "$1"
fi
}
alias mine=mine
```
Now you can write:
```
$ mine
```
to mine a block, or:
```
$ mine 100
```
to mine 100 blocks and make your Liana timelocks expire.
Another useful alias for .bashrc:
```
alias lastblock='bitcoin-cli -regtest getblock $(bitcoin-cli -regtest getbestblockhash) 2'
```
So you can just write 'lastblock' on the terminal to see all the transactions in the last block.
Please reply below with your best regtest aliases and scripts.
I'm excited to be coming to TabConf in Atlanta in October 23-26th.
My talk will revolve around the UX of hardware signers. It's a technical take on why we failed to build a good UX, and what we can do about it.
Also, please find me if you want to talk about MATT!
matt
MATT (Merkleize All The Things)
The revolution will be merkleized
I use Amethyst and Phoenix. Can I use it to receive zaps? If not... why not?