<unnamed>

Public Key

npub1zthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnq6wxm56

Profile Code

nprofile1qqsp9msr6ytgfgf9mkrmapuu9qvsg9d78ua3ajntfmt580t5llvgpesppamhxue69uhkummnw3ezumt0d5q3uamnwvaz7tmnv4shycmg9ehx7um5wfshycmgd9mx2uewvdhk6qgkwaehxw309aek2ctjvd5zumn0wvh8gmmyv9usz8rhwden5te0dehhxarj9e3xjarrda5kuetj9eek7cmfv9kqzyrhwden5te0dehhxarj9emkjmn9qyxhwumn8ghj7mn0wvhxcmmvew4sr5

Publishing to

nostr.mom

search.nostrarchives.com

search.nos.today

nostr.bitcoiner.social

nostr.wine

nos.lol

Last Notes

2026-10-26 18:00:54 UTC

It's not really a camping holiday on a tropical island if you don't get caught in a tropical storm at least once, right?

2026-10-17 15:59:58 UTC

I've been thinking about post quantum for Cashu. @nprofile…8aw4 There's been progress on PQ signature schemes, but *blind* signatures might be a harder problem.
Personally, I'm not worried about quantum computing. Maybe 100 years from now quantum computers still won't be able to factor a 3-digit number. But let's imagine elliptic curves are broken, whether by quantum computers or a classical attack.
Inflation rather than blindness is the problem for Cashu. An attacker could recover the mint's private keys and forge unlimited ecash. But I think the blindness of the signatures would remain intact; I don't see how solving the discrete logarithm problem would allow them to unblind
If Bitcoin hasn't adopted PQ signatures, Cashu is dead anyway. And if we have practical PQ blind signatures, we can just use those. Apparently, the lattice-based schemes might allow blind signing
So the interesting scenario is where Bitcoin has adopted PQ signatures but Cashu hasn't.
Suppose elliptic-curve private keys can be recovered within a month. Cashu could continue using elliptic curves, but keysets would have to expire after perhaps a week. Not just rotate to new active keysets: old ecash would become worthless.
Every user would have to come online weekly to refresh their entire balance, or lose it.
My prediction is that people simply wouldn't do that, and everyone would use on-chain Bitcoin, Lightning, or something else
As I said, I'm optimistic that elliptic curves will be fine for another century. If not, then chaumian ecash needs a quantum-safe blind signing scheme; there are no workarounds to keep elliptic curve blind signing in operation

2026-09-14 23:25:01 UTC

Finally using Astra a bit more. It's good and all, but still a bit sloppy in its own way. When it writes a massive plan with lots of stuff, I really need to read carefully to suggest adjustments. It wants to add too many new things
Not really a criticism of Astra. Just an observation that, while AI has changed dramatically and models will continue to be much better than the previous models, some things kinda stay the same. The 'weaknesses' persist, but perhaps they just move to a different level of complexity

2026-06-21 09:15:57 UTC

I think I finally fully understand Ark, and will try to explain it here:
(The swapping from the old round to the new round was what I didn't fully understand until I asked AI a few questions this morning)
Lightning already shows how two users can share one UTXO; both parties have a pre-signed transaction that they can broadcast at any time to spend the onchain 2-of-2 UTXO. That transaction spends that one UTXO and creates two new UTXOs which give each party their balance.
In Ark, it's basically the same, but with any number of users. The onchain UTXO is an n-of-n multisig instead of just 2-of-2. All parties have the necessary transactions which they can broadcast at any time. So every user has 'unilateral exit', they can broadcast these transactions at any time and get a single onchain UTXO with their balance belonging just the them.
These are the VTXOs (Virtual UTXOs). You can exercise your unilateral exit at any time by broadcasting your VTXOs.
(Pedantic detail that you don't really need to know: if there are 5 users, it's not a single transactions that spends the 5-of-5 *directly* to five different UTXOS, one for each of the five users. There is a tree of transactions, and each user has a copy of the *chain* of transactions that are necessary to get their balance out to a single UTXO under their control)
It's possible to receive payments at any time from another Ark user. But it requires a bit of trust (because the Ark Service Provider [ASP] and the sender could collude to take payment money that they sent to you) and therefore I won't discuss it in detail. Ark doesn't use the cool Lightning tech for instant settlement with commitment transactions. Therefore, I'll ignore this slightly-trusted part of Ark, and I will focus on the fully trustless parts, i.e. where Ark users have unilateral exit
If you already have 1000 sats locked up safely in one 'round' onchain, and you receive another 500 sats and you want those to be locked up safely, then you will need to take part in another round. This is where things get really interesting, and this is the bit I only just fully understood today ...
The ASP creates a new 'round', i.e. a new multsig output onchain that includes all the users who wish to take part. In this round, you will be assigned 1500 sats. i.e. you now have unilateral exit allowing you to take 1500 sats
But you still have the VTXOs from the first round, and so it seems like you could implement both exits and thereby claim 1000+1500 = 2500 sats, stealing 1000 sats from the Ark Service Provider
The solution is a 'forfeit' transaction. The ASP won't include the 1000 sats in the new round unless you first sign a 'forfeit' transaction and give that signature to the ASP. This gives control of your original 1000 sats to the ASP; if you broadcast the original VTXOs, then the ASP can use the forfeit to claim those 1000 sats for itself. There is a timelock in the VTXOs, in order to give the ASP sufficient time to broadcast the forfeit transaction
The forfeit therefore protects the ASP, because it stops the user from 'double exiting'. There can then be multiple on chain 'rounds', and you have a balance in all of them, but you are practically able to access only one of them [the latest one]. 'Your' money in the older round UTXOs isn't really yours any more.
But we must also protect the user! You, the user, don't want to forfeit your balance in the 'old' onchain UTXOs before the new 'round' is confirmed on chain. The solution here is 'connector outputs'; the forfeit transaction depends on outputs created in the new round and therefore the forfeit is ineffective until the new round is confirmed.
So now both the user and the ASP are protected. The user has a balance on-chain in the 'old' round, with full unilateral exit via their VTXOs, and they can trustlessly and atomically 'move' that into a 'new' onchain round. It's not instant, because the new rounds need to be confirmed on chain, but it is unilateral exit
So Ark is great at scalability, but it has a few downsides for the various parties:
It's not private
If you insist on full sovereignty, i.e. you don't trust the ASP, then Ark is slow like on-chain. If you want instant trustless final settlement, then Lightning is still the only option
From the ASP's point of view, they have to lock up a lot of liquidity. If a given user has a balance of 21,000 sats and there are five rounds with that balance, then the ASP actually has to lock up 105,000 sats on chain. Each round therefore has an expiry time built in, where all the funds go back to the ASP after that expiry time; this motivates all users to take part in a new round - or exit or otherwise spend their funds - before the expiry.
This sounds like I'm being quite critical of Ark. It sounds like I'm saying that it's as slow and as non-private as on-chain, and the only advantage is scale because many users can share a single UTXO.
However, this is where Lightning comes in again. Lightning shows how you can take a slow and transparent system, and then build private instant settlement on top of it
In the vision of 'Ark as a channel factory for Lightning' that René Pickhardt and others have been talking about for a couple of years, everyone can have a full Lightning node. They haven't channels with other people, doing (blind) routing over the Lightning network. They'll be paying for preimages in the usual way. They'll be sending 'commit transactions' over and back in the usual way. Fully Lightning in every way, no compromises. In this vision, everyone gets private instant settlment because they directly use Lightning
The subtlety in this approach is that, instead of Lightning channels being backed by conventional already-confirmed on-chain funding transactions, the funding transaction that backs the Lightning channel is instead an Ark VTXO. You and I can set up a Lightning channel without broadcasting that funding transaction; we are both satisfied that either of us can - at any time - broadcast the Ark VTXOs to get the funding transaction on chain. This allows us to do all the Lightning stuff *as if* the funding transaction is already on chain.
In this context, you would have to 'exit' twice in order to get your funds. The first 'exit' is the Ark exit, where you broadcast the VTXOs in order to create the 2-of-2 funding transaction for the Lightning channel, and then the second exit is where you broadcast your latest Lightning commitment transaction in order to split the the 2-of-2 into the final on chain balance for you and for your channel partner
In the 'channel factory', Lightning is still the Layer 2. All payments fully go through Lightning, giving us private instant settlement. Ark is like 'Layer 1.1', offering a wrapper over Layer 1 that is still slow and somewhat transparent, but which allows us to scale up the number of users that can fit on chain

2025-11-03 22:52:43 UTC

Reading "The Bitcoin Standard" now. I can't take it very seriously. Gross oversimplification, and no nuance
Then this kind of childishness as a pathetic way to take a dig at Keynes 🙂
I'm so glad that I read Lyn Alden's "Broken Money" first, to show me that thoughtful and well-read bitcoiners exist!
https://blossom.primal.net/426c630de46a82b5f46cf663ff721717e697571a62d2e56591ad6ed7bd6c8094.jpg

2025-10-07 07:37:00 UTC

- reply

Nice! Great progress recently, but I have a basic question:
In the medium term, how do we make this work practically? Every device (or just every router?) will have a mini DNS server, which verifies that the DNS cert for npubXYZ.npub was signed by the corresponding nsec?