Self-custody can't be evil.
Minimize evil in bitcoin by holding the keys.
"Don't be evil", as Google taught us, is not a viable long-term strategy for businesses working with content.
"Can't be evil" is the way.
Writing apps for hardware signing devices is about to get this easy
```
#![cfg_attr(target_arch = "riscv32", no_std, no_main)]
extern crate alloc;
use alloc::vec::Vec;
sdk::bootstrap!();
fn process_message(_app: &mut sdk::App, msg: &[u8]) -> Vec
msg.to_vec()
}
pub fn main() {
sdk::App::new(process_message).run();
}
```
Some updates on OP_CHECKCONTRACTVERIFY:
- BIP draft: https://github.com/bitcoin/bips/pull/1793
- bitcoin-core concept implementation: https://github.com/bitcoin/bitcoin/pull/32080
- Delving post: https://delvingbitcoin.org/t/op-checkcontractverify-and-its-amount-semantic/1527
In the new post on delving, I delve into the amount logic of CCV, something that has somewhat evolved since the initial posts.
I argue that while scriptPubKey checks are just equality checks this transaction-wide logic is preferable, and it's difficult to replicate it otherwise.
However, while the amount logic is not difficult, transaction-wide checks present some implementation challenges, because of multi-threaded Script validation in core.
Solving this seems to be necessary for several possible soft forks (CCV, VAULT, TXHASH, CISA), but even just to implement batch validation for Schnorr signatures, which is an optimization available today.
More details in the PR.
As usual, you'll find all the links at https://merkle.fun.
I look forward to your comment and ideas.
The end goal is to be able to use rust-bitcoin but 'hijack' anything crypto.
In theory, you should be able to just patch the upstream crates doing crypto, but I think that would be much more work than just having my local forks of rust-bitcoin and rust-secp256k1
The con is that backporting updates will be painful every time.
Yup, and chopped off a bunch of features of secp256k1 I don't need
https://github.com/LedgerHQ/vanadium/pull/77
Most implementations are still `todo!()`, but... it compiles!
I ended up keeping secp256k1 - death to secp256k1_sys!
I promise, I have a good reason 😅
GM, I'm trying to compile rust-bitcoin without rust-secp256k1. How's your day?
You can't prevent governments from buying bitcoin, but you should strive to make sure governments can't prevent you.
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
Does that prove the existence of the multiverse?
At TABConf 6, I gave a talk on the UX challenges of hardware signing devices.
Video: https://youtu.be/IYOswKz5QAo
Slides: https://docs.google.com/presentation/d/17Tmwmi93ICXnFb_MTEspoE4TfiLFx6NUKARW5MJsp_M/edit?usp=sharing
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.
https://x.com/mononautical/status/1796939795127500996
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.
There are some possible footguns: for example if you replace your single-sig with a 2-of-2, then if you don't have a backup of the hotkey (maybe a compromised nostr client tricked you into backup up the wrong key...), you might get locked out of your funds.
Feels a lot safer in a taproot keypath, if you have recovery paths without the hot key.
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.
I use Amethyst and Phoenix. Can I use it to receive zaps? If not... why not?