salvatoshi

#bitcoin

Public Key

npub157y6gz0l0rfhw220rfwnujeff6q2mec33nzkwz23umkrt6482exq8e60gr

Profile Code

nprofile1qqs20zdyp8lh35mh99835hf7fv55aq9duugce3t8p9g7dmp4a2n4vnqpydmhxw309a6k6cnjv4kz6vfww3skjmrzx9nrxdeww3ejumn9wsargwp58qq3gamnwvaz7tmwdaehgu3wdau8gu3wv3jhv3g2j52

Publishing to

umbrel-1.tailb1f37.ts.net:4848

nostr.oxtr.dev

Author Public Key

npub157y6gz0l0rfhw220rfwnujeff6q2mec33nzkwz23umkrt6482exq8e60gr

Show more details

Last Notes

2026-05-13 19:01:51 UTC

- reply

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!

2026-05-13 15:58:57 UTC

- reply

Ah, the famous Data Availability Lawyer

2025-12-19 22:46:48 UTC

https://blossom.primal.net/e81859a1b3b6b0f73993b4bcad3e950607ea24531c8d7b318cb31de71beb639e.jpg

2025-12-13 18:31:40 UTC

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!
https://blossom.primal.net/4cdff7661c557842b39619d759ae51bf3b48c5aa5218fece20291a1dd6c2b5bd.jpg

2025-11-12 13:05:18 UTC

- reply

Bitcoin doesn't work without entropy.
But entropy implies information content.
It's from my @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

2025-11-12 13:04:14 UTC

This slide summarizes the fundamental reason why forbidding data embeddings on-chain either:
- fails miserably, or
- destroys Bitcoin.
https://blossom.primal.net/9d5ccd3e0b3bcc7e14497316751caab68be45bf12a1219d74a71484823be0687.png

2025-10-14 22:20:17 UTC

I guess I'll start running v31 today
https://blossom.primal.net/358353b8c80384d76c20957c7d63c5d0c60a3904c3863cd2ec48bf8eee9534fb.png

2025-08-29 15:51:03 UTC

Fiat money runs on Poof of Work.
You worked, you got paid... and poof, it's gone.

2025-08-20 11:03:22 UTC

- reply

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.

2025-08-20 09:24:07 UTC

- reply

Although, I think that only covers single-sig?

2025-08-20 09:22:03 UTC

- reply

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

2025-08-20 08:59:37 UTC

- reply

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.

2025-08-20 08:20:25 UTC

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'?

2025-08-11 13:36:37 UTC

All roads lead to CCV.
Or at least this one does.
https://github.com/bitcoin/bips/blob/master/bip-0443.mediawiki
https://blossom.primal.net/4420a48e37adf83129bcba20a4accbda5c54876c47c82b012befa1e2772e81c5.jpg

2025-07-30 22:38:40 UTC

I bought an RTX 5090.
What are the coolest self-hosted AI things you guys are doing?

2025-07-11 10:45:37 UTC

This guy's good – Guinness world record of first merged PRs
https://blossom.primal.net/1dcf5dec93f5e37a9f39e138a95a0f83b239b2379ca6d68b241ddcb2ca5d095c.mp4

2025-07-06 09:21:34 UTC

- reply

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.

2025-07-06 09:16:28 UTC

- reply

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

2025-07-06 07:28:31 UTC

- reply

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

2025-07-06 07:27:01 UTC

- reply

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?
#nevent1q…f5ma

2025-07-01 12:53:28 UTC

- reply

Just a misunderstanding
https://blossom.primal.net/8640a1514ea639051a39abd0387518644260fc7df65c378ab6fdabf8575240db.jpg

2025-06-29 10:36:35 UTC

Seen in ₿ali
https://image.nostr.build/5cc514f598ce1c87c25da0b8c06380cf6143164a6d3303fca074e29c65b780bf.jpg

2025-06-27 15:19:37 UTC

- reply

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

2025-06-22 12:39:52 UTC

- reply

Primal hands down had the most fun booth at BtcPrague
#nevent1q…jm0c

2025-06-22 07:23:58 UTC

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 @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!

2025-06-19 21:25:58 UTC

- reply

Honored to sit right next to @nprofile…mpq9 on the scoreboard! I'll try again tomorrow :)
#nevent1q…d44n

2025-05-30 01:43:18 UTC

The Script Army Knife
OP_CHECKCONTRACTVERIFY
OP_CAT
OP_CHECKSIGFROMSTACK
OP_AMOUNT
OP_CHECKTEMPLATEVERIFY
https://image.nostr.build/05d0b8fae735c33d466a49d4f6c16d38b7e1b2571efb7b6e93cb4583f4b7b644.jpg
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.

2025-05-28 05:42:18 UTC

What happens in Vegas,
hopefully doesn't stay in Vegas.
See you on Thursday!
https://image.nostr.build/3c07e6c6c6cd7a5c347de6e92263e6362ec0cb1aee707d4f08a52dfa59b0ef2a.jpg

2025-05-22 09:38:44 UTC

EUR people wondering why is everyone talking about ATH
https://image.nostr.build/21be5df342906e6937fd475c8325e6b0c42cae3700c3c90d417cfbe39e62b6a4.gif

2025-05-21 14:38:08 UTC

My talk at @nprofile…lf72 is Thursday 29th May 1:30pm in the Developer Zone.
Let's chat about useful opcodes.
https://image.nostr.build/c632d7fe6e3bfaa98a95c0225b9333fdfb2868332673b03283315163d8509cfa.jpg

2025-05-09 21:42:28 UTC

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 @nprofile…lf72 in Vegas and let's keep the ball rolling.

2025-05-02 21:47:11 UTC

- reply

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.

2025-05-02 21:21:57 UTC

- reply

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.

2025-05-02 20:33:15 UTC

- reply

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

2025-05-02 19:57:18 UTC

- reply

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?

2025-05-02 19:50:16 UTC

- reply

YOU TAKE THAT BACK

2025-05-02 19:49:30 UTC

- reply

Oh no, you merkelized.

2025-05-02 17:39:36 UTC

- reply

How many hours long is the talk? 🤣

2025-05-02 10:01:02 UTC

- reply

https://image.nostr.build/03daacead0cd6d4bd1dad93cea8c1bf90d9aa50d54b0b2c03c8d7515cfbf2c6a.jpg

2025-05-02 09:44:19 UTC

I will be at @nprofile…5m55 in Vegas with a session on `OP_CHECKCONTRACTVERIFY`.
What should I talk about?

2025-04-29 11:15:35 UTC

Security/privacy ⇒ Entropy
Entropy ⇒ Information content

2025-04-26 21:09:39 UTC

- reply

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

2025-04-26 14:31:44 UTC

- reply

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!

2025-04-26 08:35:16 UTC

- reply

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

2025-04-25 21:21:07 UTC

"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://image.nostr.build/35b3c88b9fe426da75def37c5069fd1a34093aee7c621d8592fb44139b2b5991.jpg
https://www.ledger.com/blog-musig2-ledger-bitcoin-app

2025-04-22 22:44:57 UTC

- reply

Zaps are all custodial over here 🥲

2025-04-17 13:36:13 UTC

- reply

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

2025-04-16 13:02:23 UTC

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?

2025-04-15 20:47:26 UTC

- reply

Atomize All The Things!

2025-04-15 20:23:48 UTC

Not sure why people think Merkle trees are hard.
https://image.nostr.build/a66983a8c1ae9406c2686d4332cb7ba2ed13d592d4eaa9419017f66f6d97bf38.jpg

2025-04-13 18:49:06 UTC

New polymarket just dropped https://image.nostr.build/9ea77f2567d8e50f8a7a98f7f76e32b48e0e5a684ee66a91eb6b154a08020522.jpg

2025-04-09 13:52:21 UTC

When Ruben Somsen writes a gist, you know it's going to be good:
https://gist.github.com/RubenSomsen/a61a37d14182ccd78760e477c78133cd
On improving IBD time.

2025-04-04 20:00:43 UTC

- reply

What would be needed in order to make zaps work with bolt12-supporting wallets like Phoenix?
#nevent1q…66tv

2025-04-03 10:33:22 UTC

- reply

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

2025-04-03 09:26:57 UTC

- reply

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

2025-04-03 08:40:14 UTC

- reply

Self-custody can't be evil.
Minimize evil in bitcoin by holding the keys.
#nevent1q…tq2d

2025-04-03 08:29:45 UTC

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

2025-03-28 16:52:20 UTC

- reply

Anything you'd like to build?

2025-03-28 11:03:48 UTC

- reply

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

2025-03-28 10:59:31 UTC

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();
}
```

2025-03-26 22:47:49 UTC

Fun https://image.nostr.build/6cac5d7f657772843e401d5e3f23f0ba10328152cf795a394c1816758611c0c7.jpg https://image.nostr.build/6cac5d7f657772843e401d5e3f23f0ba10328152cf795a394c1816758611c0c7.jpg

2025-03-17 12:13:28 UTC

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.

2025-03-12 08:41:44 UTC

- reply

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.

2025-03-12 08:26:38 UTC

- reply

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!

2025-03-11 23:02:03 UTC

- reply

I ended up keeping secp256k1 - death to secp256k1_sys!

2025-03-11 09:26:13 UTC

- reply

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

2025-03-10 11:01:25 UTC

- reply

I promise, I have a good reason 😅

2025-03-10 11:01:04 UTC

- reply

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

2025-03-10 09:53:51 UTC

GM, I'm trying to compile rust-bitcoin without rust-secp256k1. How's your day?

2025-03-08 19:32:33 UTC

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

2024-12-20 14:28:52 UTC

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

2024-12-11 15:37:49 UTC

- reply

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

2024-12-11 11:36:10 UTC

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!
https://image.nostr.build/04e3ec1ef33e3849111cd66f017e3e5f8a4d3feaf98f22f206290a3f8f519a22.jpg
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
https://image.nostr.build/37dce9a78ac337ab35b41624e6366f43e3f5628409d4a9690de7d4ad2c129033.jpg

2024-12-10 11:30:48 UTC

- reply

Does that prove the existence of the multiverse?

2024-12-03 15:51:13 UTC

- reply

It's out now!

2024-12-03 12:41:07 UTC

- reply

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.

2024-12-02 13:32:49 UTC

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!
https://image.nostr.build/571b12574aea753a39b5a354281abc9ecdff4563a06993c9c1dc439dbf3dc30d.jpg
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.
https://image.nostr.build/4a8584aff11c5f86e639c10fc1d3b7d48e8571fd9002f3b214472131a940ca77.jpg
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
https://image.nostr.build/faf7e352fd439b0eb91bb38bed1ba5b8dfe589b4bbcc8e0920ec1648b9de9dea.jpg
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:
https://image.nostr.build/ce96ce40ce38a543575c07c5b5d80f7db61c683acc2c29d49795ce4b932ab183.jpg
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.

2024-11-29 23:16:25 UTC

- reply

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.

2024-11-29 23:09:25 UTC

At @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

2024-11-02 17:55:25 UTC

- reply

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

2024-11-02 17:52:20 UTC

V for V _ n _ _ _ _ _
Coming in 2025.
https://image.nostr.build/24869d77a5c2feba95b15a14ab0b5638ee9be8091091f96b8d8ea0ac51b04575.jpg

2024-10-25 03:54:25 UTC

- reply

You might be hit by a sjorsnado
#nevent1q…p8fk

2024-10-09 12:08:12 UTC

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

2024-08-29 20:53:34 UTC

- reply

Interesting opinion

2024-08-29 13:02:38 UTC

- reply

I will zap them if they do 🤣

2024-08-29 13:02:11 UTC

- reply

Can the devs do something? 🫣

2024-08-29 12:57:08 UTC

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

2024-08-29 12:36:45 UTC

- reply

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

2024-08-29 12:35:05 UTC

- reply

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 ;))

2024-08-29 09:40:08 UTC

- reply

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)

2024-08-29 08:43:36 UTC

- reply

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.

2024-08-29 08:37:02 UTC

- reply

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.

2024-08-29 08:14:05 UTC

- reply

Currently on Ledger, BitBox02, Jade and Coldcard (on the test firmware because @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

2024-08-29 07:54:48 UTC

- reply

Use Liana!

2024-08-29 07:48:19 UTC

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?

2024-08-28 07:16:56 UTC

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

2024-08-27 19:48:52 UTC

- reply

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

2024-08-27 19:47:03 UTC

- reply

'); DROP TABLE Users;--

2024-08-27 12:01:22 UTC

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

2024-07-26 07:38:53 UTC

#bitcoin