Nostr notes by salvatoshi

Don't worry, it was just a silly joke on the term "Data ...

2026-05-13T19:01:51Z

In reply to nevent1q…r5zm
_________________________

Don't worry, it was just a silly joke on the term "Data Availability Layer' that is popular in blockchain research... Sorry to interject on a much more serious topic!

Ah, the famous Data Availability Lawyer

2026-05-13T15:58:57Z

In reply to nevent1q…dclx
_________________________

Ah, the famous Data Availability Lawyer

Nostr event nevent1qqsq5797gmsss7rjrmsjhprnd4ar24teka2jp56s7lpk7n4xj3c8dvszyzncnfqflaudxaeffud960jt998gpt08zxxv2ecf28nwcd025atyce3vegp

2025-12-19T22:46:48Z

It's CCV o'clock! I opened a draft PR to ...

2025-12-13T18:31:40Z

It's CCV o'clock!

I opened a draft PR to bitcoin-inquisition to activate OP_CHECKCONTRACTVERIFY (BIP-443).

https://github.com/bitcoin-inquisition/bitcoin/pull/102

Please help by reviewing, if you can!

Bitcoin doesn't work without entropy. But entropy implies ...

2025-11-12T13:05:18Z

In reply to nevent1q…f0w6
_________________________

Bitcoin doesn't work without entropy.
But entropy implies information content.

It's from my TABConf (nprofile…4q0e) 2024 talk "Entropy, miniscript and hardware signers", exploring what entropy means for the UX of signing devices.

Full video here: https://youtu.be/IYOswKz5QAo

This slide summarizes the fundamental reason why forbidding data ...

2025-11-12T13:04:14Z

This slide summarizes the fundamental reason why forbidding data embeddings on-chain either:
- fails miserably, or
- destroys Bitcoin.

I guess I'll start running v31 today ...

2025-10-14T22:20:17Z

I guess I'll start running v31 today

Fiat money runs on Poof of Work. You worked, you got paid... and ...

2025-08-29T15:51:03Z

Fiat money runs on Poof of Work.

You worked, you got paid... and poof, it's gone.

Users should (mostly) not see them, either. Although, that's ...

2025-08-20T11:03:22Z

In reply to nevent1q…yl9x
_________________________

Users should (mostly) not see them, either.

Although, that's not yet possible as they need to be able to inspect them during wallet creation/registration.

Although, I think that only covers single-sig?

2025-08-20T09:24:07Z

In reply to nevent1q…sg2z
_________________________

Although, I think that only covers single-sig?

Great, thanks for sharing! We'll have a separate discussion ...

2025-08-20T09:22:03Z

In reply to nevent1q…57rl
_________________________

Great, thanks for sharing!

We'll have a separate discussion about getting rid of addresses, but that requires more infrastructure before it's feasible :)

I think it indeed works in many cases, although adding some ...

2025-08-20T08:59:37Z

In reply to nevent1q…4dyt
_________________________

I think it indeed works in many cases, although adding some attribute that suggest an action (like 'draft', 'unfinished', etc.) might be useful to guide into the next step.

Unpopular (?) opinion: banish the term 'PSBT' from the UI ...

2025-08-20T08:20:25Z

Unpopular (?) opinion: banish the term 'PSBT' from the UI of software wallets (and hardware signers).

It's just a file format. Image-editing tools don't tell you "load JPEG/PNG/..." – it's "Load image".

'Transaction draft'? 'Unfinished transaction'? Just 'transaction'?

All roads lead to CCV. Or at least this one does. ...

2025-08-11T13:36:37Z

All roads lead to CCV.
Or at least this one does.

https://github.com/bitcoin/bips/blob/master/bip-0443.mediawiki

I bought an RTX 5090. What are the coolest self-hosted AI things ...

2025-07-30T22:38:40Z

I bought an RTX 5090.

What are the coolest self-hosted AI things you guys are doing?

This guy's good – Guinness world record of first merged PRs ...

2025-07-11T10:45:37Z

This guy's good – Guinness world record of first merged PRs

I agree it has a lot in common. I think it will need orders of ...

2025-07-06T09:21:34Z

In reply to nevent1q…c7qm
_________________________

I agree it has a lot in common. I think it will need orders of magnitude more economic activity in order to bring the same market dynamics that made the early internet work.

It might succeed.

I fixed the typo for my amethyst friends. Now that's a type ...

2025-07-06T09:16:28Z

In reply to nevent1q…hhuw
_________________________

I fixed the typo for my amethyst friends.
Now that's a type of chaos for sure!

(also, how to bring an 'edit' feature to nostr, so I can ...

2025-07-06T07:28:31Z

In reply to nevent1q…fnen
_________________________

(also, how to bring an 'edit' feature to nostr, so I can fix typos 😅)

Internet up the early 2000s was about finding order in chaos. ...

2025-07-06T07:27:01Z

Internet up the early 2000s was about finding order in chaos. Lots of energy was bottom-up. Search engines and aggregators would just help you find it; and finding the good content did sometimes feel like uncovering a secret treasure.

How to bring back the chaos?

quoting
nevent1q…f5ma
I remember a more whimsical Internet.

Just a misunderstanding ...

2025-07-01T12:53:28Z

In reply to nevent1q…7lq0
_________________________

Just a misunderstanding

Seen in ₿ali ...

2025-06-29T10:36:35Z

Seen in ₿ali

Brits' reply: "Blocking out the what?!"

2025-06-27T15:19:37Z

In reply to nevent1q…2em9
_________________________

Brits' reply: "Blocking out the what?!"

Primal hands down had the most fun booth at BtcPrague ...

2025-06-22T12:39:52Z

Primal hands down had the most fun booth at BtcPrague

quoting
nevent1q…jm0c
Hang for sats! Earn 21 sats per second BTCPrague (npub167n…zu3r)

Vanadium will make programming apps to run on hardware signing ...

2025-06-22T07:23:58Z

Vanadium will make programming apps to run on hardware signing devices almost as easy as programming on your desktop.

https://github.com/LedgerHQ/vanadium

Here are the slides for my talk at BTCPrague (nprofile…py4c)
/dev/hack/day:

https://docs.google.com/presentation/u/1/d/1WcV0cLzpJHJY5cJbJncAi8EjXoI5HAh2g6-KQNpE6qc

It's a change of paradigm: you will no longer need to wait for the vendor to implement a missing feature before it's possible to use it with your hardware signer. You can build it yourself!

Honored to sit right next to @nprofile…mpq9 on the scoreboard! ...

2025-06-19T21:25:58Z

Honored to sit right next to Sirius (nprofile…mpq9) on the scoreboard! I'll try again tomorrow :)

quoting
nevent1q…d44n
BEAST MODE Sirius (npub1g53…drvk)

The Script Army Knife OP_CHECKCONTRACTVERIFY OP_CAT ...

2025-05-30T01:43:18Z

The Script Army Knife

OP_CHECKCONTRACTVERIFY
OP_CAT
OP_CHECKSIGFROMSTACK
OP_AMOUNT
OP_CHECKTEMPLATEVERIFY

This is a minimal set of opcodes that can implement virtually any of the interesting constructions that I've seen discussed and researched in the last few years.

In fact, I'd challenge anyone to find a compelling construction that cannot be implemented with these opcodes.

The exception is of course some extremely complex operation that cannot fit in a block (or is impractically large) without a custom opcode. Examples are Snark verifiers, BLS signatures, quantum-resistant signatures, other advanced crypto, etc.).

However, for those advanced use cases, MATT fraud proofs (enabled by CCV+CAT) might be a viable substitute for many applications, allowing to get the benefits of those constructions on layer 2 without exposing layer 1 to cryptography that is considered too novel.

Each of these opcodes is simple, has at least a draft implementation, and they are all very composable with each other, and with any possible future Script updates.

What happens in Vegas, hopefully doesn't stay in Vegas. See ...

2025-05-28T05:42:18Z

What happens in Vegas,
hopefully doesn't stay in Vegas.

See you on Thursday!

EUR people wondering why is everyone talking about ATH ...

2025-05-22T09:38:44Z

EUR people wondering why is everyone talking about ATH

My talk at @nprofile…lf72 is Thursday 29th May 1:30pm in the ...

2025-05-21T14:38:08Z

My talk at thebitcoinconf (nprofile…lf72) is Thursday 29th May 1:30pm in the Developer Zone.

Let's chat about useful opcodes.

OP_CHECKCONTRACTVERIFY is BIP-443. When I presented MATT at the ...

2025-05-09T21:42:28Z

OP_CHECKCONTRACTVERIFY is BIP-443.

When I presented MATT at the first @btcazores
in September 2022, it was just a concept: a minimal covenant with maximal power. While the covenant was straightforward, what a good implementation would look like was far from clear.

Then came James O'Beirne's OP_VAULT proposal - a narrower, practical use case for a covenant. And yet, it resonated: the underlying need was the same as in MATT. Both required a way for coins to carry state (data) from input to output.
If two very different problems point to the same technical tool, maybe that tool is a solid foundation.

CCV implements that foundation.

CCV is not made for vaults, but it enables them (alone, or supercharged with CHECKTEMPLATEVERIFY).

CCV is not "MATT's opcode", but it's the main building block.

CCV is also what bridges like BitVMs are simulating with workarounds like Lamport Signatures: updating the state. It makes large part of their on-chain footprint redundant, and greatly simplifies their design.
There's no more for cabooses, CatVMs, ColliderVMs. Script will finally have an expressive primitive for carrying state in UTXOs.

---

There is still a lot of work to do. The implementation needs to be reviewed and improved, ideally to be made ready for signet. More tooling needs to be developed. More work is necessary to assess what combinations of opcodes work best for a soft-fork.

CCV has no sponsors and no funding.

Can you help?
Find me at thebitcoinconf (nprofile…lf72) in Vegas and let's keep the ball rolling.

Yes, of you provide a chain code yourself and it has enough ...

2025-05-02T21:47:11Z

In reply to nevent1q…p2j3
_________________________

Yes, of you provide a chain code yourself and it has enough entropy, then it works somewhat. But it's not better than a 2-of-2 between the device and the software wallet in terms of security model, and I think the latter is easier to analyze.

I'm gonna shill this blog post I wrote some time back: ...

2025-05-02T21:21:57Z

In reply to nevent1q…ysxc
_________________________

I'm gonna shill this blog post I wrote some time back: https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript

If you don't trust a signing device, it's really hard to meaningfully use it without additional devices - I don't think creative paths can help much. For example, a device could lie about the xpubs you ask.

> Just trying to think about how you can Guarantee that ...

2025-05-02T20:33:15Z

In reply to nevent1q…qm5f
_________________________

> Just trying to think about how you can Guarantee that neither the manufacturer or yourself knows the private key

What for? I see footguns in this scheme, but I don't quite see the benefits.

In general, I think that both cosigners and blind signers are unlikely to make much much sense in multisig setups - much more useful in miniscript wallets, where you can do more 'experimental' stuff with the primary spending path, while keeping recovery paths straightforward.

The derivation paths doesn't really change anything in the ...

2025-05-02T19:57:18Z

In reply to nevent1q…pece
_________________________

The derivation paths doesn't really change anything in the meaning of the policy, so as long as it's a path you can export from your signer, everything will work.

(some devices might have path restrictions for xpubs they export, though - so using standard patterns maximizes compatibility)

What is your goal?

YOU TAKE THAT BACK

2025-05-02T19:50:16Z

In reply to nevent1q…m38h
_________________________

YOU TAKE THAT BACK

Oh no, you merkelized.

2025-05-02T19:49:30Z

In reply to nevent1q…un6h
_________________________

Oh no, you merkelized.

How many hours long is the talk? 🤣

2025-05-02T17:39:36Z

In reply to nevent1q…vmsn
_________________________

How many hours long is the talk? 🤣

Nostr event nevent1qqsw72pm0yzf9ndxkslnpr4rwvluvdkkdz8sq2kt49kfsd35t3nswkqzyzncnfqflaudxaeffud960jt998gpt08zxxv2ecf28nwcd025atyc0felr0

2025-05-02T10:01:02Z

In reply to nevent1q…8w5h
_________________________

I will be at @nprofile…5m55 in Vegas with a session on ...

2025-05-02T09:44:19Z

I will be at thebitcoinconf (nprofile…5m55) in Vegas with a session on `OP_CHECKCONTRACTVERIFY`.

What should I talk about?

Security/privacy ⇒ Entropy Entropy ⇒ Information content

2025-04-29T11:15:35Z

Security/privacy ⇒ Entropy
Entropy ⇒ Information content

I'm not sure. I think the fact that the recovery paths can be ...

2025-04-26T21:09:39Z

In reply to nevent1q…82he
_________________________

I'm not sure. I think the fact that the recovery paths can be a completely different set of keys (and spending conditions) is very useful in practice, and you can't do it with FROST.

Also, I don't think moving to MuSig2/FROST for deep cold storage is that compelling, as the added interactivity (multiple rounds) is likely a dealbreaker.

Normies will be fine with 1 cold key + 1 (invisible) cosigner, plus recovery paths to protect from loss. The cherry on top would be OP_VAULT- (or OP_CHECKCONTRACTVERIFY-)based recovery paths, as that would almost entirely remove the learning curve about 'recovery paths' and refreshing timelocks, which is what confuses normies using liana.

But maybe we figure how to get a good enough approximation with cosigners...

There are two failure modes for the cosigner: - it stops signing. ...

2025-04-26T14:31:44Z

In reply to nevent1q…z4zr
_________________________

There are two failure modes for the cosigner:
- it stops signing. Then your primary spending path is frozen, but if you're in a liana-like setup, that's no big deal.
- it signs things it shouldn't sign. Then you basically fall back to the security model you'd have without the cosigner - for example a single-sig with you hardware wallet.

Unlike on-chain usage of moon math like ZKPs (roll ups, bridges, etc.), where failure is catastrophic, here you'd just fallback to a weaker security model.

Also, I think the fact that all the complexity can be handled in the software wallets (without needing any new features from hardware signers) makes it a lot more likely to happen. It's not easy to build, but once built, it's basically a library that can be used as a black box by software wallets. Bullish!

Yep, you can definitely have multiple invisible cosigners! For ...

2025-04-26T08:35:16Z

In reply to nevent1q…h4uf
_________________________

Yep, you can definitely have multiple invisible cosigners!

For example, one could be self-hosted if you have an always-online machine.

Of course, since MuSig2 is an AND of all the cosigners, having more increases the chance of at least one of them failing, so in practice I expect a single cosigner managed by a professional entity to be a very popular option. In that direction, an interesting thing to explore is: how private can this be? It should be possible to combine MuSig2 with Schnorr blind signing, so that the cosigner doesn't necessarily have to learn about your transactions, while still being able to check predicates in them (this paper does it for single-sig: https://eprint.iacr.org/2022/1676 but smarter people tell me it should be generalizable for MuSig/FROST).

"MuSig2 is the cherry on top of the taproot cake" I'm ...

2025-04-25T21:21:07Z

"MuSig2 is the cherry on top of the taproot cake"

I'm somewhat of a poet myself.

Read about Ledger Bitcoin app's support of MuSig2 in this blog post - written with the legend Yannick Seurin in person.

https://www.ledger.com/blog-musig2-ledger-bitcoin-app

Zaps are all custodial over here 🥲

2025-04-22T22:44:57Z

In reply to nevent1q…9h8d
_________________________

Zaps are all custodial over here 🥲

Then the evil bitcoin-core developers removed it to keep all the ...

2025-04-17T13:36:13Z

In reply to nevent1q…7qu6
_________________________

Then the evil bitcoin-core developers removed it to keep all the coins for themselves 🤬

If you use any wallet that is not single-signature (multisig, ...

2025-04-16T13:02:23Z

If you use any wallet that is not single-signature (multisig, miniscript, etc.), it is important to have a backup of the descriptor/wallet policy.
But we have no standard on how to do it.

How should we do it? Here's my attempt at an ideal approach: https://delvingbitcoin.org/t/a-simple-backup-scheme-for-wallet-accounts/1607

The approach I propose tries to achieve a number of desirable properties:

- Encrypted: so you can outsource its storage;
- Easy to implement: really, it's very simple;
- Vendor-independent: it should work with any signing device;
- Deterministic: the backup should be repeatable.

In the post, I try to give motivation on the approach, and come with a scheme that tries to be pragmatic, and easy to adopt.
Of course, variations, more features, etc. are possible, but I believe this scheme is good for the use cases of the typical user.

And certainly, good enough is better than the status quo where most wallets just tell the user "you should have a backup" 🙃
What do you think?

Atomize All The Things!

2025-04-15T20:47:26Z

In reply to nevent1q…6k7j
_________________________

Atomize All The Things!

Not sure why people think Merkle trees are hard. ...

2025-04-15T20:23:48Z

Not sure why people think Merkle trees are hard.

New polymarket just dropped ...

2025-04-13T18:49:06Z

New polymarket just dropped

When Ruben Somsen writes a gist, you know it's going to be ...

2025-04-09T13:52:21Z

When Ruben Somsen writes a gist, you know it's going to be good:

https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd

On improving IBD time.

What would be needed in order to make zaps work with ...

2025-04-04T20:00:43Z

What would be needed in order to make zaps work with bolt12-supporting wallets like Phoenix?

quoting
nevent1q…66tv
Phoenix has bolt 12, we need to make zaps work for it.

I have Phoenix wallet in the phone, and an @nprofile…jjxr node ...

2025-04-03T10:33:22Z

In reply to nevent1q…flgs
_________________________

I have Phoenix wallet in the phone, and an umbrel (nprofile…jjxr) node at home - it feels like this should be a solvable problem!

I shall not be zappable until I figure how to do it ...

2025-04-03T09:26:57Z

In reply to nevent1q…ayve
_________________________

I shall not be zappable until I figure how to do it self-custodially, but I've been lazy 😅

Self-custody can't be evil. Minimize evil in bitcoin by ...

2025-04-03T08:40:14Z

Self-custody can't be evil.

Minimize evil in bitcoin by holding the keys.

quoting
nevent1q…tq2d
"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.

"Don't be evil", as Google taught us, is not a viable ...

2025-04-03T08:29:45Z

"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.

Anything you'd like to build?

2025-03-28T16:52:20Z

In reply to nevent1q…vzgw
_________________________

Anything you'd like to build?

What should a nostr app for signing devices be able to do? I need ...

2025-03-28T11:03:48Z

What should a nostr app for signing devices be able to do? I need requirements - writing it is easy.

quoting
nevent1q…q2nz
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();
}
```

Writing apps for hardware signing devices is about to get this ...

2025-03-28T10:59:31Z

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<u8> {
msg.to_vec()
}

pub fn main() {
sdk::App::new(process_message).run();
}
```

Nostr event nevent1qqs99xwz6j537kkd3z9pp8zp4vd0s3x9jjzdeh4g42dg8zh2s04vncszyzncnfqflaudxaeffud960jt998gpt08zxxv2ecf28nwcd025atyck8msvv

2025-03-26T22:47:49Z

Fun

Some updates on OP_CHECKCONTRACTVERIFY: - BIP draft: ...

2025-03-17T12:13:28Z

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 ...

2025-03-12T08:41:44Z

In reply to nevent1q…agkg
_________________________

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 ...

2025-03-12T08:26:38Z

In reply to nevent1q…02v0
_________________________

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!

2025-03-11T23:02:03Z

In reply to nevent1q…myhz
_________________________

I ended up keeping secp256k1 - death to secp256k1_sys!

Oh, I will! But you might not like what I replace it with 🤣

2025-03-11T09:26:13Z

In reply to nevent1q…hz0h
_________________________

Oh, I will! But you might not like what I replace it with 🤣

I promise, I have a good reason 😅

2025-03-10T11:01:25Z

In reply to nevent1q…tux9
_________________________

I promise, I have a good reason 😅

How would I roll my own crypto otherwise, duh??

2025-03-10T11:01:04Z

In reply to nevent1q…vdee
_________________________

How would I roll my own crypto otherwise, duh??

GM, I'm trying to compile rust-bitcoin without ...

2025-03-10T09:53:51Z

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 ...

2025-03-08T19:32:33Z

You can't prevent governments from buying bitcoin, but you should strive to make sure governments can't prevent you.

My comments on the proposed opcodes in the "Covenants ...

2024-12-20T14:28:52Z

My comments on the proposed opcodes in the "Covenants support" page:

https://gist.github.com/bigspider/2b0892da45884d26eb7f4c9cb2395a7d

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

I look forward to the Church-Turing thesis staying valid for many ...

2024-12-11T15:37:49Z

In reply to nevent1q…wph3
_________________________

I look forward to the Church-Turing thesis staying valid for many million years, not gonna lie 😅

To me, quantum computing is an attempt to cheat nature. I think ...

2024-12-11T11:36:10Z

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?

2024-12-10T11:30:48Z

In reply to nevent1q…pa98
_________________________

Does that prove the existence of the multiverse?

It's out now!

2024-12-03T15:51:13Z

In reply to nevent1q…3flq
_________________________

It's out now!

New version of the musig app coming today, fixing some bugs that ...

2024-12-03T12:41:07Z

In reply to nevent1q…7fr7
_________________________

New version of the musig app coming today, fixing some bugs that you'd hit with more complex policies.

Also, it makes Round 1 no longer require user confirmation, so that it can be done in background instead of asking confirmation twice.

At TABConf 6, I gave a talk on the UX challenges of hardware ...

2024-12-02T13:32:49Z

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 ...

2024-11-29T23:16:25Z

In reply to nevent1q…7du4
_________________________

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.

At @nprofile…5flv in Austin this May, I presented the pymatt ...

2024-11-29T23:09:25Z

At btcplusplus (nprofile…5flv) 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: https://youtube.com/watch?v=BvXI1IOargk&t=67s
- Vaults: https://youtube.com/watch?v=BvXI1IOargk&t=898s
- Vault demo: https://youtube.com/watch?v=BvXI1IOargk&t=1573s
- Code in pymatt: https://youtube.com/watch?v=BvXI1IOargk&t=1898s

Sorry for preannouncing the announcement, but it's too much ...

2024-11-02T17:55:25Z

In reply to nevent1q…rg46
_________________________

Sorry for preannouncing the announcement, but it's too much fun 😅

V for V _ n _ _ _ _ _ Coming in 2025. ...

2024-11-02T17:52:20Z

V for V _ n _ _ _ _ _

Coming in 2025.

You might be hit by a sjorsnado #nevent1q…p8fk

2024-10-25T03:54:25Z

You might be hit by a sjorsnado

quoting
nevent1q…p8fk
Please don't run Bitcoin Core v0.19.2 or older... #TABConf

If you're working on a MuSig implementation and you have a ...

2024-10-09T12:08:12Z

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.

https://github.com/LedgerHQ/moosig

Interesting opinion

2024-08-29T20:53:34Z

In reply to nevent1q…rh3f
_________________________

Interesting opinion

I will zap them if they do 🤣

2024-08-29T13:02:38Z

In reply to nevent1q…3auz
_________________________

I will zap them if they do 🤣

Can the devs do something? 🫣

2024-08-29T13:02:11Z

In reply to nevent1q…fkll
_________________________

Can the devs do something? 🫣

I use Amethyst and Phoenix. Can I use it to receive zaps? If ...

2024-08-29T12:57:08Z

I use Amethyst and Phoenix. Can I use it to receive zaps? If not... why not?

I have Amethyst and Phoenix, I seem to be too dumb to make it ...

2024-08-29T12:36:45Z

In reply to nevent1q…hsne
_________________________

I have Amethyst and Phoenix, I seem to be too dumb to make it work (or can it work?)

If you give it another try and have any questions, feel free to ...

2024-08-29T12:35:05Z

In reply to nevent1q…er3d
_________________________

If you give it another try and have any questions, feel free to ask!

(I'm not part of Liana's team, but I'm a fanboy ;))

Fair! Although you're never really "forced" to do an ...

2024-08-29T09:40:08Z

In reply to nevent1q…egs5
_________________________

Fair! Although you're never really "forced" to do an on-chain transaction; you can create schemes where your recovery path is still pretty safe, so you're not in a rush when the timeout expires.

For example, the recovery path could be a multisig 2of2 between a recovery buddy and a hot key (you backup the xpriv of the hot key together with the descriptor).

If using taproot, the recovery buddy can't even see your UTXOs if you don't tell them the descriptor!

So if fees are high when the timeout expires, maybe you're not scared of waiting some time.

(Of course, I wouldn't recommend such setup to beginners at this time)

I think Liana can just add a "sign by endpoint" feature, ...

2024-08-29T08:43:36Z

In reply to nevent1q…9eph
_________________________

I think Liana can just add a "sign by endpoint" feature, meaning that there is a webserver somewhere that expects your PSBTs and returns then signed (if they respect whichever conditions you it's programmed for) for one of the xpubs in the wallet policy.

The cosigner could be a third-party service, or a simple webservice running in your umbrel node (or your friend's node), etc.

Memes apart, support and integration of hot/automatically signing ...

2024-08-29T08:37:02Z

In reply to nevent1q…z789
_________________________

Memes apart, support and integration of hot/automatically signing keys should probably come before MuSig2.

(That's what I want to use MuSig2 with!)

In a multisig/MuSig2 with a hot/online key, you can give the user the singlesig user experience, and the programmability/UX benefits of hot keys.

Currently on Ledger, BitBox02, Jade and Coldcard (on the test ...

2024-08-29T08:14:05Z

In reply to nevent1q…ecat
_________________________

Currently on Ledger, BitBox02, Jade and Coldcard (on the test firmware because NVK (nprofile…7dju) is a miniscript hater :P)

Taproot miniscript still only with Ledger and Coldcard (edge) - harass your vendor if not in the list! :D

Use Liana!

2024-08-29T07:54:48Z

In reply to nevent1q…fh3x
_________________________

Use Liana!

Nostr needs more #miniscript discussions. Have you tried Liana? ...

2024-08-29T07:48:19Z

Nostr needs more #miniscript discussions.

Have you tried Liana?

==> https://wizardsardine.com/liana

If you did but you still don't use it: why not?

Nostr event nevent1qqsxhfgnla7xhjzdspzrnfrqxv9svkl3jfttwhysx99mcxx050e7aqczyzncnfqflaudxaeffud960jt998gpt08zxxv2ecf28nwcd025atyczvyaap

2024-08-28T07:16:56Z

Is there any tool to automate posting on both Nostr and Twitter?

I hope y'alls like Merkle trees! #nevent1q…7krl

2024-08-27T19:48:52Z

I hope y'alls like Merkle trees!

quoting
nevent1q…7krl
How many people read me on Nostr? Should I post here more often?

'); DROP TABLE Users;--

2024-08-27T19:47:03Z

In reply to nevent1q…nqu9
_________________________

'); DROP TABLE Users;--

Nostr event nevent1qqs9hxprgc7qd24p4pu9pd3fm8dg6avdctf5he7t7992c8x7j2jqtmczyzncnfqflaudxaeffud960jt998gpt08zxxv2ecf28nwcd025atyctlmzfh

2024-08-27T12:01:22Z

How many people read me on Nostr? Should I post here more often?

Nostr event nevent1qqspgtmquhm0dp85gw6mgsmnvpakq20j3zvua47y53evwasue0vu4zczyzncnfqflaudxaeffud960jt998gpt08zxxv2ecf28nwcd025atycpl5d43

2024-07-26T07:38:53Z

#bitcoin