SatsAndSports

Into bitcoin, specifically cashu.

When I'm not working in the fiat mines, I'm into cycling and camping

Public Key

npub1zthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnq6wxm56

Profile Code

nprofile1qqsp9msr6ytgfgf9mkrmapuu9qvsg9d78ua3ajntfmt580t5llvgpespp4mhxue69uhkummn9ekx7mqpz3mhxue69uhhyetvv9ujuerpd46hxtnfduq3wamnwvaz7tmwdaehgu3wvd5xz6tdvyhxjmnxduq3qamnwvaz7tmwdaehgu3wd3skueqpr3mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmqpz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qxsh8lw

Publishing to

nostr.bitcoiner.social

relay.mostr.pub

Author Public Key

npub1zthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnq6wxm56

Show more details

Last Notes

2026-07-23 00:16:05 CEST

- reply

Such a strange hill for you to end your Bitcoin career on

2026-07-22 18:37:33 CEST

The number theorists keep talking about Jacobins
Are they anything like the Fabians that are attacking Bitcoin right now?

2026-07-21 03:11:34 CEST

- reply

they're probably a bot. I blocked them a while ago, and I double-checked some of their content
I think they're spamming follow notifications deliberately

2026-07-19 13:08:40 CEST

- reply

This was never "Core Vs Knots"; the BIP110ers will never learn if we keep to that false framing
Core and Knots were on the same side, keeping filters that were harmful to small miners, and which were making it hard to run a node (fake pubkeys)
The Tolerant Minority are the winners; we stepped in and relaxed the de facto relay policy months before Core30
We saved Bitcoin, and we didn't ask permission from Core or Knots to do it

2026-07-19 12:56:14 CEST

- reply

You mention "control'. The Tolerant Minority are in control of relay policy. Core don't make those decisions any more; see subsat fees, and fullRBF, and now large op_returns
If anyone wants to argue about this topic, they should argue with the Tolerant Minority, and stop arguing with another group (Core) that aren't in control

2026-07-19 12:25:02 CEST

- reply

"Filters don't work, but they send a message"
The default filters became harmful - not "ineffective" - over the summer of 2025. They harmed the small miners. Are you aware of this, and are you happy to harm small miners because you'd prefer to "send a (meaningless) message?
Months before Core30 was released, many folks (including me) configured our nodes to accept large op-returns.
Therefore, Core didn't remove any limit on what could be relayed and mined on the Bitcoin Network. The Bitcoin Network had already made its own autonomous decision, months before Core30 was released, to allow this. We didn't wait for permission from Core or Knots to do this. We didn't wait for "technical consensus"
In that context, the default policy in Core had only one effect: harming small miners, by making it difficult for them to earn fees
The heroes and winners of this are the Tolerant Minority. We take action to help small miners, and we take action to keep fake pubkeys out of the UTXO. We are successful and unstoppable, and we don't care about your "message"
----
Luke is smart enough to know all this. He has told dozens of lies, deliberately fooling people. He knows that the effect of his policies is harmful to Bitcoin

2026-07-16 14:29:07 CEST

- reply

Philosophy is cool and all, but if the hashrate falls to very low values in the future, we're going to have to be pragmatic about the security budget
I love the idea of Ark as a 'Channel Factory', allowing billions to have fully sovereign Lightning nodes. However, if Ark is *too* efficient in this case, then a typical block might have only one transaction!
(By the way, that's partly why I'm currently against CTV; I want Ark, but I don't want it to be *too* scalable; I want many medium-sized Arks, not one mega-Ark)
On balance, I think it'll all be fine and there won't be a problem with the security budget. But there could be a problem, and that problem could eventually be fatal. So I like to think about it
The article discusses Runes, but I think it dismisses them too quickly. The Lightning network could be extended to fully support Runes (no soft fork required), and it's possible (but admittedly, very unlikely) that one of the Runes becomes very valuable. As many Runes 'currencies' have tail emissions, it's possible that they could provide the right incentives to miners
Anyway, there's always 'demurrage', a soft fork to apply a tax on old UTXOs, which would motivate people to move their coins more often and create. The rule could be that, when spending a UTXO older than X years, at least Y% of the outputs must be anyone-can-spend outputs that are locked to a few years in the future. Such outputs are equivalent to the block subsidy in practice

2026-07-16 04:04:11 CEST

I'd be inclined to support this, if it was applied to everybody regardless of age
What do you think?
https://blossom.primal.net/3a1cc8c99f39de34c9285cfdc7ec8bb6c4bd3d91774650991a266eb2c84e519a.jpg

2026-07-13 22:07:22 CEST

- reply

I don't think I've ever used GLM. I mostly just stuck with the big three (Opus, GPT, Gemini) and only tried a few others when they were discussed a lot on Twitter
I can access GLM via one of the API keys I have, so I should try it out sometime

2026-07-13 17:38:11 CEST

- reply

That's too vague
The wording should be explicit about calculations, e.g. the hash rate in a 2016-block difficulty-adjustment window

2026-07-13 15:47:05 CEST

- reply

Liar

2026-07-11 16:22:34 CEST

- reply

The plebs love community so much because they don't know how to form their own opinion, they need a leader to tell them

2026-07-06 16:18:39 CEST

- reply

I love K2.7. I've used it very heavily for a few weeks. They only reason I don't use it exclusively is that I have my GPT subscription and hence no marginal cost of using GPT
Kimi seems better than other models at noticing opportunities for reusing code
When I've done work in Kimi, I like asking GPT to review. And vice versa
TLDR: I love Kimi
I haven't used Opus 4.8 so much, due to the cost. The last Opus that I used heavily was 4.6, because I was able to use it within OpenCode

2026-06-29 09:42:06 CEST

- reply

I think both parties need to have a cashu wallet set up (with compatible mints?)
Then, when you press the zap button in Amethyst, you can choose to send by cashu or lightning
Worked for me to nutzap Vitor
https://blossom.primal.net/7157af01a4823718df26f39fdf61354c49c61b4eca566d6a8798e25830b42712.jpg
https://blossom.primal.net/804582ca10d57393bf8fdba5e8ee355addcb2a5b69c4520c74db6264ec058f83.jpg

2026-06-27 00:09:19 CEST

- reply

I just sent my first nutzap. Great to see it working

2026-06-26 22:33:37 CEST

- reply

.. PS: I should add that this kind of thing might work if you have some expert humans in the loop somewhere, for example to fix or rewrite the spec. But this person is proposing just giving exclusive responsibility to the AI for everything, to maintain existing crappy and complex systems

2026-06-26 22:19:04 CEST

- reply

Yes indeed, I agree. I love it and am looking forward to it gradually being adopted

2026-06-26 22:17:10 CEST

- reply

I'm drafting a system I'm calling MONAD. It's kinda like Tor, where you select relays and route your traffic through them using 'onion routing'.
Anybody can run a relay, and the users pay the relay operators for their service. The payments are bitcoin micropayments using cashu, using our @npub17fz…9yxv 'spilman channel' system for very efficient payments.
This repo is quite out of date; I hope to push my latest code in a couple of weeks when it's ready
https://github.com/SatsAndSports/MONAD

2026-06-26 17:41:50 CEST

A 'Senior Principle Engineer' in my fiat job thinks that the role of AI is to infer the spec from our existing codebases (they are unmaintainable, underspecified, untested, human slop), so that every time a new 'vastly superior' model appears we should ask it to rewrite the code from scratch using this inferred spec as the guide
#NGMI
"... extract a spec (product, engineering) from an existing codebase, force an isolated AI agent to rebuild it from scratch, and measure the divergence. The goal is to discover the minimal codebase practices we must adopt today so that when vastly superior models release tomorrow, we can confidently hit “re-generate” on entirely AI-generated codebases and guarantee the output is strictly better."

2026-06-26 10:09:26 CEST

- reply

On Twitter, I'm unfollowing/muting people who interact too much with BIP110, no matter which side of the argument they're in
While I agree with you, I might have to temporarily unfollow you too, for giving it too much oxygen 🙂

2026-06-24 19:54:27 CEST

- reply

True.
But I'm still going to block that account myself, removing it from my feed, because it's retarded

2026-06-23 10:20:20 CEST

- reply

... and when I ask it to check for updates beyond 12, it says "your software is up to date"

2026-06-23 10:18:12 CEST

- reply

I'm on EMUI 12.0 on my Huawei phone.
(I'm not sure if that answers your question though)

2026-06-22 11:36:27 CEST

- reply

The NIPs repo should be forked and given a new name (PINs - Proposals to Improve Nostr) and new maintainers.
They should follow the same process as used in the BIPs repo; in particular copying the role of the "BIP Editors"

2026-06-22 11:11:56 CEST

Trying to ban myself from working on freedom tech today, as I've been neglecting my fiat-mining obligations
I've been obsessed by my open source stuff, because it's much more fun and important, but I need to do other boring stuff to pay the bills

2026-06-21 22:08:37 CEST

- reply

I think others will do one, better than me, before me 🙂
And I have plenty of other stuff to do

2026-06-21 14:19:42 CEST

- reply

The channel factory idea doesn't require any particular extension to Ark. It's something that could - in theory - be done today
I think most of the code changes would be needed in Lightning, not in Arm
My guess is that we'll need to see more confidence that "basic Ark" works well, and that we have robust libraries and implementations and then the channel factory idea will catch on

2026-06-21 11:15:57 CEST

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

2026-06-20 20:25:16 CEST

- reply

That's fair. I just decided to be obsessive about this yesterday, no exceptions (for now) 😀
I can see you're engaging positively with the one or two names in this space that might actually be curious enough that they might be able to make progress

2026-06-20 19:42:26 CEST

- reply

Same with @npub17u5…t4tp and reardencode today. I love their content on Twitter generally, but engagement with BIP-110 is too tedious. Unfollowing for now

2026-06-19 14:00:15 CEST

The British sense of fun around elections is great. This is a genuine photo from last night of the UK's likely next prime minister with other candidates for the seat that he has just won. In every election, fun candidates run against the high profile politicians
https://blossom.primal.net/0f8990ffc844791f1b2a2c079b59d57c115659575c3868357b387e9af1f265f9.jpg

2026-06-18 21:53:15 CEST

I ran twice today. 7.5km each time
It's nice to suddenly be addicted to jogging again

2026-06-18 16:40:21 CEST

I really want to buy some STRC now, it's just $86. Partly to troll the maxis, just buy a small amount for fun
But I bought too much BTC already this month and can't afford it!

2026-06-18 12:20:02 CEST

On Twitter, I'm starting to unfollow people that give too much attention to BIP-110
I generally enjoy the content of folks like @npub1xap…cnde and @npub1qg8…24kw , but BIP-110 is now so boring to me that I unfollow them until this is all over and until they stop giving oxygen to BIP-110 and to unrealistic relay policy generally
The "debate" died long ago, and we (the tolerant minority) have won
Even the Bugle @npub1563…c9n6 are running out of funny things to say about it; surely a sign that this topic is long dead
I first got properly into Bitcoin only last summer, and I had great fun arguing with Knotzis as I learned more about the topic. But there is nothing to be gained any more. Shinobi, it's time to accept that you won't get any satisfaction from Hodlonaut
I'm not sure if I'll engage with any replies; but of course I'll engage in good faith if I have met you in person and know that you're in good faith

2026-06-17 15:58:54 CEST

- reply

I learned about cryptography in uni in the late 1900's
Back in my day, RSA and MD5 were good enough for public key crypto and hashing respectively

2026-06-17 14:44:05 CEST

Great story
#nevent1q…ss3c

2026-06-17 00:00:12 CEST

I'll go to Bitdevs tomorrow. I missed it the last few months, sometimes from laziness and sometimes because I was out of town
Looking forward to it!

2026-06-16 19:54:45 CEST

- reply

Adam Smith was pretty smart, but he got a lot of the history wrong.
He was wrong to say that barter was typical. He didn't have access to the modern anthropological research.
He was writing in the late 1800's and was therefore, understandably, speculating on what seemed reasonable to him as he didn't have any good data to go on.
Of course, my point doesn't really address your point; you make a good point I guess. I'm just taking this opportunity to go a little off topic and ask everybody (not you, specifically) to be more nuanced in their research. Saifedean Ammous also makes embarrassing historical errors in his The Bitcoin Standard, and he doesn't have the same ignorance excuse that Smith had 😀

2026-06-16 17:11:10 CEST

The next interesting step for MONAD (Tor/VPN, funded by Cashu Spilman channels) is adding a nice management API; then I hope to have a nice dashboard web-app (maybe a PWA) to monitor and manage the wallet and the client and the relay.
I've been adding a lot of smaller things recently, like blinded paths and more stress testing and other little improvements. But it's time to wrap this up into something easy to use, like a Docker container with easy configuration and monitoring. Then I can start asking people to do some testing
#nevent1q…7ajz

2026-06-16 16:19:58 CEST

Stop pretending that the UK's problems around internet freedom are because it's "left wing" or "communist" or "woke"
The current UK Labour party are famously quite right wing compared to previous Labour governments, and the UK generally is a bit more right wing than many European countries such as France
This isn't a left versus right issue. It's a mixture of (Epstein) evil, and incompetence
The manipulators want you to think that it's a left versus right issue, so that they can distract you with culture war crap. Engage your brain, and keep your eye on our real goals

2026-06-15 13:12:27 CEST

- reply

You mean to skip the need for the receiver to be online to receive?
If I remember correctly, the bArk folks wrote a paper on how to do that, using hashes instead of signatures in something complex

2026-06-14 22:21:42 CEST

I keep trying to do my fiat job, but I keep getting drawn into freedom tech instead
-----
I've been busy with MONAD (cashu-funded Tor) in recent weeks. Various protocol improvements, and general stress testing under hundreds of simultaneous connections and hammering the payment channels
I started using KImiK2.7 and I like it so far. I'll use it for at least a few more days before trying to make a final judgement on it
https://blossom.primal.net/84b830ebd29f7f0dc7d768fdee61bd991787b6d54750b7ee79890a859256c402.gif

2026-06-14 12:52:45 CEST

- reply

Not sure yet. That's just from the intro. I'll try to remember to reply again when I've read more of the essays themselves!
I'm reading a translation written in 1877. I understand it, but it's interesting how much English has changed since then.
I kinda understand a little French; maybe someday I'll be able to read the original in French

2026-06-14 01:14:32 CEST

reading Montaigne's essays

2026-06-13 22:48:27 CEST

- reply

The CLARITY Act is expected to have some new legislation to protect developers of any cryptocurrency. So that would be nice, regardless of the rest of any bill

2026-06-13 14:41:16 CEST

- reply

and big corporations too. Perhaps even more important, in certain respects

2026-06-13 08:59:18 CEST

- reply

This is a bit fake. I suspect Anthropic ask for these decisions to be made
It all fits into the marketing pitch

2026-06-13 00:18:57 CEST

A longer-term idea to minimize prompt injection:
Hopefully, the future will be all open models and they'll all be running on commodity server farms (using something like @nprofile…gs7e to buy and sell)
I know there is randomness when predicting tokens, but we should make it deterministic, i.e. pseudorandom
Each server should sign every response. We should send a small fraction of our requests to two servers simultaneously.
If two servers give a different response to the same request, then it's likely one has cheated. With the signatures, we can then prove which server farm misled us
I guess this is a bit complex, but it's a fun problem to think about
#nevent1q…efya

2026-06-13 00:04:45 CEST

Good read, on how Liquid keeps amounts private, while also being immune to the kind of issue that affected zcash recently
(Not very much technical detail though; I should follow the references here to learn more)
#nevent1q…ta6j

2026-06-12 23:01:28 CEST

BTC Yield will continue until morale improves
#nevent1q…dc87

2026-06-12 23:00:18 CEST

- reply

Some people understand the Bitcoin protocol
Some people understand finance and economics
Very few understand both, and therefore the folks that attack Strategy ("Ponzi") will continue while the haters of bitcoin ("boiling the oceans") will continue

2026-06-12 22:36:38 CEST

- reply

X is funding them, to try to discredit Nostr

2026-06-11 22:09:39 CEST

I'm reading a Culture novel again now, for the first time since getting properly into Bitcoin and AI
There is a lot of AI in those stories, so it's interesting to read it now that it seems more realistic
And they're always pointing out that the Culture isn't so "organized"; no hierarchies and laws and so on. I guess it's what some anarchists would hope is possible
(They still have extraordinarily powerful armed forces though)

2026-06-10 18:38:42 CEST

"Just transitory"
@nprofile…ymg0 , monitoring the STRC de-peg

2026-06-10 14:56:33 CEST

I enjoyed this much more than I expected I would.
I love Steve Keen's work, he's excellent on economics and it's history, especially on how fiat works.
I was a bit worried that Peter McCormack would be too ideological, but he was willing to learn and you can see that they both enjoyed this discussion.
Keen isn't a bitcoiner (yet); they didn't really discuss bitcoin here. We need a way to combine his expertise with the facts about the world today (e.g. the existence of bitcoin)
https://youtu.be/6LPpih9-hwE

2026-06-07 23:37:20 CEST

- reply

PS: After watching the entire debate, I must admit that much of it was kinda boring
Gammon brought more facts, so it was nice to see someone who has done their research on monetary history. But the signal-to-noise ratio could have been better (and would have been had I been there 😀)

2026-06-07 23:04:31 CEST

- reply

I've never heard of this fuckstr character; gving them a follow now
(But might unfollow soon, I haven't checked any of their content yet)

2026-06-07 22:35:44 CEST

This debate is interesting, about economics during and after hyperbitcoinization. Some good points, but I also wish I was there to intervene and point out some historical facts that they might not be aware of
Around 36:30, Gammon is pointing out that, after hyperbitcoinization, people will want to borrow Bitcoin and generally that there will be some demand for credit creation and fractional reserve banking. While that's true, it's misses the point that credit creation is difficult when inflation is low.
Today, I wouldn't want to borrow a bitcoin. Even if I didn't have to pay interest on it, I know it would be very difficult to repay the bitcoin in a year from now (unless, of course, I just sat on it). When an asset (like Bitcoin) is going up in value - and also when it finally settles to its final value - then it's difficult to borrow it because it's difficult for the two parties (the lender and the borrower) to agree on a positive number as the interest rate.
In the opening minutes, Gammon points out that the US money supply increased as much in the late 1800's - when the US was on a gold standard - as it did between 2003 and 2023. While the discussion on that was interesting, they didn't point out that the late 1800's was a period when gold mining was increasing the supply of gold at a very fast rate, thanks to improvements in mining technology. So basically, the economy did well during that period because of the inflation that was introduced by the gold standard.
Economies can sometimes do very well when the money supply ('raw' money, and/or credit) is increasing quickly (late 1800's), and also when there is good regulation of the financial system (US from around 1940 to 1970).
Bitcoin's instant private cash settlement of the hardest possible asset will have dramatic impacts on the financial system, many of them bad. On *average*, I have some optimistism that the pros will outweigh the cons, but it will still have some of the harmful effects due to its deflationary effects
https://www.youtube.com/watch?v=zECVTxmb-DI

2026-06-07 19:19:40 CEST

Fun prediction:
Strategy has been hammering STRC this week, causing the price to de-peg to $93, and using the proceeds to buy a lot of BTC
https://image.nostr.build/285caedc576a2d8a8580c6c7ef372f866ff6e44b1b44322fa150e1d507dbbb96.png

2026-06-06 00:28:34 CEST

- reply

To confirm that the event_id at the link matches the nevent in the screenshot:
$ nak encode nevent cce3ad3583968ccba5e47ed92296343aa2c9aaf7f8267455986f616358679fbe

2026-06-05 16:32:15 CEST

- reply

Not sure if legally relevant, but I'm curious:
What exactly does njump do? Is there browser-side code that queries the relays directly? Or do the njump servers query the relays and then forward the response to the browser?

2026-06-05 13:47:08 CEST

- reply

Exactly
Which is why I'm excited by the "Ark as channel factory" idea that René Pickhardt has been pushing
Ark doesn't really improve privacy, or settlement speed, compared to L1. It helps a *lot* with scaling though
So we build Lightning on top of Ark. Ark is Layer 1.5, and is much more scalable. Then we build Lightning directly on top of Ark, to get privacy and another big multiple of scalability
https://youtu.be/hqKQ4Rky3tY

2026-06-05 13:34:53 CEST

- reply

I have a lot to say 🙂.
I kinda agree, but calling it a problem of "the left" isn't helpful. Left vs right is losing more and more meaning, and some of the most "left" people I know (woke, trans activist, anti climate change warriors, supporters of public healthcare and public transport...) are also experts on money and the financial system and understand price signals and so on
And some of the biggest (financial) idiots I know are the "right wing" bitcoiners, who never studied economics in any way before bitcoin and who don't study anything outside the Bitcoin bubble. Pure pleb slop
I think you're trying to say that, even in an optimistic Star Trek post-scarcity future, there will still be limits on usage and energy use. Do we build indoor ski resorts everywhere? Do we Terraform Mars? Do we build a Space Elevator?
Individuals will de facto have an energy budget, and you rightly point out that money is the only sane way to both distribute resources (not necessarily "fairly") and to give price signals which encourage efficiency.

2026-06-05 13:23:05 CEST

- reply

I generally unfollow people who give too much attention to those fools
MrHodl has a good signal-to-noise recently, so I won't unfollow you any time soon 😃
I briefly had to unfollow Adam Back on Twitter for that reason

2026-06-05 13:12:33 CEST

- reply

Since just before the first BIP110 client was released, I've been tracking daily the version of every Tor node known to my node
IIRC, less than 50 pre-Core30 nodes have switched to Knots or BIP110

2026-06-05 09:03:54 CEST

- reply

I first started my Raspberry Pi node in August. It was Core v26
Literally the first thing I did was increase datacarriersize to 1MB and lower the fee rate
So don't assume the pre-30 nodes have any problem with v30

2026-06-04 22:49:53 CEST

- reply

I would encourage encryption more broadly, to make it easier for blossom servers to just randomly host any data
You might worry this would lead to repetition of data. But one idea is to encrypt the data with an encryption key that is derived from the hash of the *cleartext* data. This would give us many of the benefits of encryption, but wouldn't encourage duplication

2026-06-04 21:02:04 CEST

- reply

Sorry. I just made it up, that's kinda what I want
But actually, there is a BUD: https://github.com/hzrd149/blossom/blob/master/buds/10.md
Unfortunately, it doesn't mention encryption
When I paste an image into my nostr client, I believe it should encrypt the data before pushing and then include the decryption key in the URL somehow (best to do this after a hash, as we do not want that to be sent to the blossom server)

2026-06-04 18:58:39 CEST

- reply

blossom:<sha256>#<optional_decryption_key><optional_relay_hints>

2026-06-03 23:33:54 CEST

- reply

https://image.nostr.build/26a90706c9120430c90b282bf9a97612362ef8be4f48c5f68b8c5ddcb1647982.png

2026-06-03 22:32:19 CEST

- reply

> Is the coinbase a secret from the miners?
No, I'm not proposing that
It's just an observation that the secret key behind the coinbase output (for simplicity, I'm assuming just one coinbase output) is something that the mining pool will not want to share with the hashers, as that would allow the hashers to steal the funds
And because this secret key is secret, we can require the pool to provide a signature that the hashers can't create, and this means that the miner (not the hasher) will be the first to learn if a given block is a winning block
In general though, I think I agree with you. But if it becomes a problem, it might be difficult to get consensus to activate

2026-06-03 16:16:19 CEST

- reply

I remember reading Meditations as a teenager, then I gradually forgot about it
But it, and stoicism, keep coming up. Including on some podcasts that I listen to
(Also, I'm going through mild caffeine withdrawal now, so I need to be stoic about the pain 🙂)

2026-06-03 07:10:08 CEST

- reply

I find the opposite actually. I've always loved coding, and I love it more than ever thanks to AI
> yet this makes the act of building software less fun for people who actually enjoy writing code
Any time I realize I've designed an interface badly, or otherwise the code needs some sort of redesign, the AI can update it all for me quickly and quite reliably. And if it fails, I kinda like intervening and breaking the task down into multiple steps so that we can do it correctly
I'm able to think more clearly than every in terms of the interfaces and architecture and so on.

2026-06-02 16:56:57 CEST

Mostly focussing on stress testing of MONAD, especially of the networking, in recent days.
Turns out that my little laptop can't take 250,000 TCP connections attempting to connect to the same ip_addr:port at the same time 😀. So I'll bind lots of listeners across 127.x.y.z
#nevent1q…vl4x

2026-06-02 15:02:19 CEST

- reply

I don't really mind that "attack" is possible. The problem is that the attack is more valuable to big miners than it is to small miners
And in Bitcoin, it's important to help the small miners, relative to the big miners
A small notary/miner could burn 10 sats and charge 11 sats, taking 1 sat as the fee
A large miner could do a fake burn where they really spend only 7 sats, but they can notarize it as 10 sats. They could charge 9 sats for this notarization
The large miner can then undercut the small miner and make a bigger profit. The mitigation is to either send the funds to an OP_RETURN or send it to the very far future

2026-06-01 22:10:24 CEST

- reply

I'm hoping that people will be incentivized to run more relays, due to the cashu payments, and therefore it'll be fast
I think bandwidth won't be a problem, but latency might be when this is deployed across various devices spread across the internet (and across the FIPS mesh)
I think I can keep the number of round trips down to a minimum, to enable faster establishment of connections. But we'll see what happens when I finally fully implement, and test, it

2026-06-01 21:33:30 CEST

- reply

All Cashu devs have been very proactive in being transparent about the rug risk
It is - as you say - "obvious"
In any walk of live, repetition is boring. Do you really think that you were the first person to ever ask this?
Ask new and interesting questions, don't repeat the same questions that have been asked *and transparently answered* a hundred times already

2026-06-01 21:27:12 CEST

I've worked out how to add Tor-style hidden services (.onion) to MONAD, and have coded some of the logic already
A more useful evening than following Nostr drama 😂
#nevent1q…6vzw

2026-06-01 17:42:08 CEST

- reply

Whether it's 21 sats or 21,000,000 sats doesn't matter
Noobs will sweep them to an exchange, or link them with their cold storage, or otherwise spend them in an anti-private way
For noobs, we should have sane default behaviour. Cashu is king for zaps and ease of use

2026-06-01 17:27:41 CEST

- reply

This doesn't seem like much of a conspiracy
Some people are donating *their own money* to freedom tech in a way that you think is non-optimal
So what?

2026-06-01 17:12:52 CEST

- reply

If the burn sats went directly to the miner within the same block, i.e. they were burned by giving them away as miner fees, then there is an attack that any miner - large or small - can easily do
(Given that this problem exists, the notarization proposal uses a different approach)
Any miner, in the naive system, could trivially do a "fake burn", by paying sats to themselves
As discussed, a mitigation is to delay them until the future
If the burn sats are moved a small amount into the future, then large miners have an advantage over small miners, as the large miners can still do a (small) fake burn because they know some of the "burned" sats will come back to themselves;
If a mining pool has 40% of hashrate, they can announce a service where you give them 10 sats and they will "fake burn" 15 says. They'll get 6 of those sats back
That's why a few of us have advocated from the start that it should be sent decades into the future, using CLTV

2026-06-01 01:43:20 CEST

Getting hooked on coding freedom tech again is cool and all. But now it's well after midnight and I'm too excited to sleep

2026-05-30 19:38:43 CEST

I'm enjoying using state machines. Old state goes in with an Event (e.g. payment received), and a new State and a list of Effects (e.g. update balance) comes out.
I really feel that AI is improving the quality, not just the quantity, of my work. When I realize The Right Way™ to do something, my agent can just do the refactor easily.
All the quality things that some devs ignore (testing, documentation, specs, ...) are also really good at educating the agent about how to write good code
https://image.nostr.build/3716b17ca8e8a8ac5ada534bcfbb734caeb31a09fdd95e61580c3b231448780c.png
#nevent1q…h9pr

2026-05-29 22:15:50 CEST

- reply

Really nice talk.
It has lots of interesting analogies to link technical details with interesting ideas, and I think a less technical audience can still find it equally thought-provoking even if they are fuzzy on the technical details

2026-05-29 19:15:05 CEST

- reply

It's a great idea, and I hope it catches on
It's important that the sats are either burned in a conventional way, like an OP_RETURN, or sent to miners *in the future* via anyone-can-spend outputs that are timelocked for a long time
Last time I checked, Thomas's implementation does the long-term lockup, but I'm not sure of the status of the paper.
The reason we can't burn them by giving them *immediately* to today's miners is that the miner could simply advertize a notarization service that says "give me 10 sats and I'll do 'fake notarization' for 1 million sats" where the miner just pays fees to themselves

2026-05-29 18:24:25 CEST

- reply

> So please redirect your private-key-sharing rage to the authors of BIP352 who introduced the concept in the first place.
This is not a valid complaint Tim. You can't blame the authors of BIP352 for this
In the conventional usage of BIP352, the recipient generates both keys separately. They *might* choose to share *one* of those keys with a third party scanning service
That's cool. It simplifies things for the recipient, by allowing the third party to see all the transactions
The problem with your proposal is that, if the scan key is shared with a third-party scanning service, that service can also steal the funds
Your proposal has certain pros and cons, like every proposal. And that's fine, you are free to promote your idea. But it's not appropriate for you to deflect by blaming the authors of BIP352 for flaws introduced by you

2026-05-29 17:59:00 CEST

- reply

This is an extraordinarily long. It could be rewritten to be much more concise. There is considerable repetition
_"Private fund control: only the holder of the matching private spend path can sweep or spend the detected outputs."_
This sentence is misleading. You should warn that - in your scheme - anyone that knows the private *scan* key is able to immediately compute this private *spend* key and therefore they can steal the funds
You could rewrite your entire proposal into about five sentences, and that would be enough to fully explain the system, including this serious issue about how the *private scan key* must not be shared with any third-party scanning service

2026-05-29 17:48:19 CEST

- reply

Make on-chain payments by making a Lightning payment to a swap provider such as Boltz so they make the on-chain payment for you
With this, none of your on-chain UTXOs are involved in the payment
(There are fully trustless variants of this, where the swap operator can't take your lightning payment without giving you the same preimage that you can then use to cause the on chain payment to happen)

2026-05-29 17:41:05 CEST

- reply

Hi Tim,
For people that can't run their own Frigate server and who are determined to receive via SP, it can make sense for them to share the private *scan* key to a trusted operator that can scan on their behalf
But we must ensure that the users don't use any scheme (for example, your scheme) which will allow the scanner to derive the private *spend* key (and nostr identity nsec) from that private *scan* key
Hzrd's system might be workable instead of yours, because his scheme requires the recipient to advertise an SP address on nostr
Lots of tradeoffs here, but their are some schemes that are simply not credible

2026-05-29 14:06:36 CEST

A random update on what I've been doing. This project isn't quite ready, but I'm very happy with my progress since I got back into this about ten days ago. I hope to ask for testers soon:
MONAD is a system with some similarities to Tor, and also to the everyday usage of the word "VPN", a system to allow you to access websites and systems while obfuscating your location, e.g. access Netflix from another country. I started it as a demo for @nprofile…0yke and now I'm going to try to get a usable system out
It's funded by Cashu, specifically by the Spilman channels, so that you can easily pay tiny amounts (one sat, or even one millisat) as needed to keep the stream alive. This helps privacy because it makes it easier to use a different payment for each session, so that the relay operator can't easily link your sessions together
Like Tor, you can select multiple relays in a chain for extra privacy, and you pay each one separately. It's onion routing, with sessions nested inside each other
Lots of encryption of course, using secp256k1. And blinded paths already implemented as an option, in order that the client doesn't know the IP address (or FIPS address) of every relay @nprofile…the5
A few days out of date, I'll update it fully when it's ready for some testing:
https://github.com/SatsAndSports/MONAD
@nprofile…8aw4

2026-05-29 12:00:56 CEST

- reply

Among my technical pre-coiner friends, the vast majority are French. So I look forward to orange-pilling (bacon-pilling?) them with this slide
https://image.nostr.build/fd2a5f7e870f7a5adaf4512fcf95114b9252c1490c1eb7136f100a939b46079f.png

2026-05-28 23:56:19 CEST

- reply

Best I can do on the stoicism is binge listen to Alex O'Connor's philosophy podcasts
He has broad interests, and I listen to most of his discussions. Stoicism and other ancient philosophies are discussed every now and then
https://fountain.fm/episode/8TApRhXcaGuyFdcxNvBy

2026-05-28 19:09:47 CEST

- reply

Mining decentralization isn't about giving power to small miners. It's about removing power from all miners
And we, the tolerant minority, will ensure it stays that way

2026-05-28 15:10:43 CEST

- reply

I know thanks. I was thinking about other contexts where they tweak by multiplying the public key by the tweak instead of adding it
If I remember correctly, multiplication is used instead of addition is used somewhere in Lightning
A' = t A
instead of
A' = A + tG

2026-05-28 14:36:48 CEST

- reply

Thanks for the write-up of that, semisol. Makes sense
I was thinking of multiplication in a different context, where it is sometimes a bit better than addition, but you're right that it doesn't help here

2026-05-27 12:21:53 CEST

- reply

How would this work with unreliable relays?
If I can't find the event that you reference, is it because you've fabricated a reference, or because I simply don't have access to your earlier event?

2026-05-27 10:49:09 CEST

- reply

"I'm only here to save the people ..."
Why does your tone make me think you're a BIP110 fan? 🤔

2026-05-27 08:45:26 CEST

- reply

Love the great work you're doing! And the transparency

2026-05-27 08:39:10 CEST

- reply

Nice!
Is there a way to fully integrate nut-zaps into Amethyst? So that a brand new user - where a third party already knows their npub - can open a Nostr app for the first time and already see some Cashu tokens that have already been sent to them by that third party via some sort of DM
I don't know enough about NUT60/61, but it would be cool to have something like that work - with zero setup - for new users

2026-05-27 08:16:35 CEST

- reply

The game theory on this is against BIP110, not for it.
If necessary, the opponents will run a URSF; this is also a user-rejected soft fork and it will oppose BIP110
I'm in the Telegram group to plan the URSF. We already know our approach, it's very simple
Our URSF will - if necessary - reject certain blocks to ensure BIP110 never activates; we'll block "at the last minute", e.g. the block that would achieve 55%
The URSF has one huge advantage: the non-BIP110 miners today (99.9% of the hashrate) are already following the rules of our URSF. They don't need to do anything to be compatible; they already make the blocks that will be accepted by the URSF
As long as some miners continue to do nothing, then our URSF guarantees that there will be a non-BIP110 chain tip
The telegram group is very quiet however, because we know BIP110 is a failure and therefore there is nothing for us to do
Mechanic isn't very technical. He is deliberately careless and inaccurate, for example his bizarre insistence that STRC is a stablecoin which is recorded on the Blockchain