salvatoshi

https://twitter.com/salvatoshi

#bitcoin

Public Key

npub157y6gz0l0rfhw220rfwnujeff6q2mec33nzkwz23umkrt6482exq8e60gr

Profile Code

nprofile1qqs20zdyp8lh35mh99835hf7fv55aq9duugce3t8p9g7dmp4a2n4vnqpr4mhxue69uhkummnw3ez6ur4vgh8wetvd3hhyer9wghxuet5kyfs4g

Publishing to

nostr-pub.wellorder.net

Author Public Key

npub157y6gz0l0rfhw220rfwnujeff6q2mec33nzkwz23umkrt6482exq8e60gr

Show more details

Last Notes

2025-04-09 13:52:21 GMT

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 GMT

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

2025-04-03 10:33:22 GMT

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

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

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

2025-04-03 08:29:45 GMT

"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-04-01 12:30:31 GMT

- reply

BIP draft: https://github.com/bitcoin/bips/pull/1793
implementation: https://github.com/bitcoin/bitcoin/pull/32080
Please review!

2025-04-01 12:29:58 GMT

Thanks to bitcoin-core developers for merging the next soft-fork!
https://image.nostr.build/4deda64c5562b44991dec2185c224e114259a6f010bb6a7f7ee482c5916b7558.jpg
Merkle trees can't be stopped.

2025-03-28 16:52:20 GMT

- reply

Anything you'd like to build?

2025-03-28 11:03:48 GMT

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 GMT

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:49:10 GMT

- reply

Past generators I tried struggled to understand binary trees.

2025-03-26 22:47:49 GMT

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

2025-03-17 12:33:05 GMT

Release 2.4.0 of the Ledger Bitcoin app is out.
Codename: "Let the Musig play"
https://www.youtube.com/watch?v=tfFjm-6cbu8
It comes with full MuSig2 support for taproot spending policies (both in the keypath and in scripts).
Note: at this time, only the python client library is updated with MuSig2 support.

2025-03-17 12:13:28 GMT

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 GMT

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

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

- reply

I ended up keeping secp256k1 - death to secp256k1_sys!

2025-03-11 11:45:50 GMT

- reply

You mean to say 2013 wasn't a good time to sell your Bitcoin?

2025-03-11 09:26:13 GMT

- reply

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

2025-03-10 12:23:00 GMT

- reply

I'll write my own Rust implementation with the same API. Doing the same C API is probably harder anyway

2025-03-10 11:01:25 GMT

- reply

I promise, I have a good reason 😅

2025-03-10 11:01:04 GMT

- reply

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

2025-03-10 09:53:51 GMT

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

2025-03-08 19:32:33 GMT

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

2025-01-14 13:30:42 GMT

- reply

I'm mostly interested in Bitcoin use cases, but: yes, you'll be able to build a signer for nostr :)

2025-01-14 13:22:34 GMT

I got various requests over time about supporting certain special Scripts in the Ledger bitcoin app.
It is a delicate topic to support signing arbitrary scripts, and it's not yet clear to me if there's a way that is both generic and secure enough to add to the Ledger bitcoin app. Doing it incorrectly might weaken the security model for existing Scripts.
It is not enough to have enough info in the PSBT to technically sign - the device needs to know what kind of checks needs to be performed on the transaction before signing.
BIP-388 defines a very generic class of Scripts that is still uniform enough to share the same signer's behavior ("you spend from a well-defined account, and change must go back to the same account"), and that's been the focus so far.
Unless a generalization is found that makes sense (and is compatible with BIP-388), custom signing behavior might be better served by separate apps, so that you can have clear signing, a UX that makes sense, and hardened checks for that use case.
I'm working on a solution for that. Please reach out if you have the need for signing certain custom Scripts – it would help to know about your use cases!

2024-12-31 23:52:47 GMT

Happy year 45x45!
Stay laser-focused, and let's make it the best year for Bitcoin, fair and square.

2024-12-24 23:56:39 GMT

Merry Christmas to those who cerebrate — I hope you have some bright thoughts.

2024-12-20 19:36:22 GMT

- reply

The Italian-approved size is 25-30 ml, that's already in the "lungo" realm :P

2024-12-20 14:28:52 GMT

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 23:25:33 GMT

- reply

CCV also has no definite "No", can I have it, too? :P

2024-12-11 15:37:49 GMT

- reply

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

2024-12-11 12:16:34 GMT

- reply

Well, the protest sign was only meant as a joke. Of course, if quantum computers are possible, people should and will build them!
I'm arguing why I think they are indeed not possible.
In maths, you can use proofs by contradiction: you assume that X is true, and then you deduce something that you know it's false (like 1 = 0). That proves that X is false.
Here I'm taking X = "quantum computers exist", and the consequence is Grover's algorithm.
Of course, I don't know for sure that Grover's algorithm is impossible, so this proves nothing.
It's just my hunch.

2024-12-11 11:36:10 GMT

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 GMT

- reply

Does that prove the existence of the multiverse?

2024-12-03 15:51:13 GMT

- reply

It's out now!

2024-12-03 12:41:07 GMT

- 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 16:25:01 GMT

- reply

Thanks a lot for your words!

2024-12-02 13:32:49 GMT

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-30 00:12:25 GMT

- reply

That's where I wanted to go with that :P
Hot keys are going to become hot again thanks to miniscript!
So many possibilities with cosigners, for example.

2024-11-29 23:16:25 GMT

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

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 GMT

- reply

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

2024-11-02 17:52:20 GMT

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

2024-11-02 08:36:27 GMT

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 @nprofile…deau
https://image.nostr.build/8deca23c7c7a020c7852b4c3d7912389959f5efd3e217573fd345d1c6db9fd21.jpg

2024-10-25 03:54:25 GMT

You might be hit by a sjorsnado
#nevent1q…p8fk

2024-10-22 06:38:56 GMT

See you at @nprofile…05sa!

2024-10-16 07:47:29 GMT

- reply

Who gave Skippy a gun??

2024-10-09 13:58:32 GMT

- reply

Yeah, too little memory.
Bringing miniscript to Nano S already required a large amount of tricks that made the code substantially more difficult.
There will be no new features on Nano S, only bugfixes if needed.

2024-10-09 12:08:12 GMT

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-10-04 04:23:58 GMT

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.

2024-09-05 12:45:50 GMT

Spoiler: the solution to good UX in hardware signers is _not_ removing the screen.
I can't even
#nevent1q…2eks

2024-09-05 11:08:52 GMT

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! https://merkle.fun

2024-08-31 11:15:07 GMT

- reply

Totally! I'm really interested in seeing if nostr people succeed in building some sort of decentralized/distributed reputation system that rewards truth. Hard problem, though!

2024-08-29 20:53:34 GMT

- reply

Interesting opinion

2024-08-29 14:16:47 GMT

- reply

Oh, they know about the functionality, I spam their channels regularly 🤣

2024-08-29 14:03:12 GMT

- reply

Are there technical blockers for why
- Phoenix can't reasonably add LNURL support, or alternatively
- why zaps can't be upgraded to also work with bolt12?
My understanding is that Bolt12 in Phoenix allows waking up the phone to receive a payment in background, so it could work reasonably well as long you're not offline for too long.

2024-08-29 13:02:38 GMT

- reply

I will zap them if they do 🤣

2024-08-29 13:02:11 GMT

- reply

Can the devs do something? 🫣

2024-08-29 12:57:08 GMT

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

2024-08-29 12:36:45 GMT

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

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

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

- 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:39:49 GMT

- reply

MuSig2 with multiple hardware signers is going to be challenging, except when it's multiple cosigners coming up online at the same time (so their software wallets can exchange PSBTs in real time).
Forget air-gapped in this context, it won't work.

2024-08-29 08:37:02 GMT

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

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

- reply

Use Liana!

2024-08-29 07:48:19 GMT

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 09:01:17 GMT

- reply

I expect to still use Twitter more, but I'm pleased to see that there are now more technical people on Nostr than the last time I tried!

2024-08-28 08:50:02 GMT

- reply

Thanks, I'll look it up!

2024-08-28 08:46:59 GMT

- reply

I guess I'd be happy with "post to Nostr, and post a short preview to Twitter linking to the note".

2024-08-28 08:45:40 GMT

- reply

I won't when I'm ready not to 🫣

2024-08-28 07:16:56 GMT

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

2024-08-28 06:05:15 GMT

- reply

What's the 1st??

2024-08-28 06:03:09 GMT

- reply

Just helping with testing!

2024-08-27 19:55:25 GMT

- reply

Not necessarily Bitcoin related (but not shitcoin related!)

2024-08-27 19:54:16 GMT

Suppose that you could program your hardware signing device to do anything (and that it was extremely easy).
What would you build?

2024-08-27 19:48:52 GMT

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

2024-08-27 19:47:03 GMT

- reply

'); DROP TABLE Users;--

2024-08-27 12:01:22 GMT

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

2024-07-26 07:39:16 GMT

- reply

Cool, it still works here

2024-07-26 07:38:53 GMT

#bitcoin

2023-12-16 09:05:01 GMT

I posted about an approach to solve the "exit problem" for pooled layer 2 systems using fraud proofs.
Read about it here: https://delvingbitcoin.org/t/aggregate-delegated-exit-for-l2-pools/297

2023-09-05 04:18:21 GMT

No point in talking drivechains, as they are obsolete.
Covenants are bitcoin's native approach to smart contracts.

2023-08-24 10:54:51 GMT

Not sure if it's heresy here, but please join the Space on Twixxer today if you're curious about MATT:
https://x.com/i/spaces/1OwGWwXmkpmGQ

2023-08-12 17:11:36 GMT

With my first answer on StackExchange, I try to explain the core concepts of MATT with as little technicalities as I could.
Not quite an explanation for your grandma yet, unless you have an exceptionally cool grandma.
https://bitcoin.stackexchange.com/questions/119239/what-are-matt-opcodes/119268#119268

2023-08-10 16:12:19 GMT

- reply

Merkleizing all the things: https://merkle.fun

2023-08-10 11:01:42 GMT

- reply

A subset of MATT's utility, with more risks and bigger consensus changes.

2023-07-31 08:00:05 GMT

Build on MATT: lists.linuxfoundation.org/pipermail/bitc…

2023-07-29 13:07:06 GMT

Posting tomorrow about some important MATTers

2023-07-24 21:58:25 GMT

- reply

Oh no it has spread on here, too 🤣

2023-07-05 19:50:17 GMT

The problem with drivechains is that while they enable "everything", we want some of the features on native L1 bitcoin.
For example, vaults.
A powerful enough covenant is better: you can get the programmability of drivechains on layer 2s, but also some useful layer 1 features.

2023-07-05 11:21:32 GMT

Released an early version 2.2.0-alpha of the Ledger Bitcoin Testnet app.
It supports miniscript on taproot.
We're only halfway in #miniscript year!
Have fun! 🥕

2023-06-25 11:28:46 GMT

Is there an easy way of using my Umbrel node with Amethyst for zaps?

2023-06-23 08:30:58 GMT

- reply

#nevent1q…88n9

2023-06-21 14:29:43 GMT

- reply

Don't forget SHE EXISTS 🤔

2023-06-09 19:06:54 GMT

- reply

I didn't ignore it, so I guess test failed

2023-05-31 14:46:05 GMT

- reply

This is glorious!
#nevent1q…rwqa