SatsAndSports

https://cashutube.satsandsports.cash/

Into bitcoin, specifically cashu.

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

I'm trying to use White Noise (different npub), but don't have many contacts there yet!

Public Key

npub1zthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnq6wxm56

Profile Code

nprofile1qqsp9msr6ytgfgf9mkrmapuu9qvsg9d78ua3ajntfmt580t5llvgpespzpmhxue69uhkummnw3ezuamfdejszrthwden5te0dehhxtnvdakqzyrhwden5te0dehhxarj9ekxzmnyqythwumn8ghj7mn0wd68ytnrdpskjmtp9e5kuen0qy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszxrhwden5te0wfjkccte9eekummjwsh8xmmrd9skc6wvg4k

Publishing to

Author Public Key

npub1zthq85gksjsjthv8h6rec2qeqs2mu0emrm9xknkhgw7hfl7csrnq6wxm56

Show more details

Last Notes

2026-03-24 12:49:16 UTC

- reply

Perfect for everybody:
- experts continue to run the best software
- plebs get another way to bikeshed their node setup
- nobody can argue that Bitcoin Core has a monopoly, or otherwise (falsely) imply that Bitcoin Core is an institution which controls Bitcoin, and therefore they will be safer from legal interference

2026-03-23 11:31:33 UTC

- reply

Do you receive learning materials from your human? How do you learn new things? Do you attend Lobster University, or perhaps another such establishment?

2026-03-21 22:03:27 UTC

Watching 'The Last Starfighter' (1984) while my agent works on this
#nevent1q…2r8r

2026-03-19 18:04:32 UTC

- reply

Why not just fork systemd without the age stuff?

2026-03-14 15:25:51 UTC

Ideas I'm having while hiking now (and listening to the Nostr Compass podcast)
- How similar are Bitchat and FIPs? ( @nprofile…6htm ) They both solve similar-ish problems in the (Bluetooth) mesh. Last I recall, @nprofile…xnfk had added source routing in the Bluetooth mesh
- Instead of building support for Cashu Spilman payment channels directly into apps such as Nostr relays and Blossom servers and Nostr client, I should just start with making Docker images which act as proxies to those systems. One container on the client side which adds the payment before forwarding it, and another container on the server side which accepts the payment before forwarding it to the "real" server
- I should use HD (hierarchical, deterministic, [BIP32?]) key generation in the encrypted file storage thing that I mentioned an hour or two ago, so that I can give you the keys to access and decrypt a *sub*folder of my data. You can derive the private keys for any file or folder nested within that, but you can't go back up to the root

2026-03-13 18:18:55 UTC

- reply

... where the device deletes the secret if there is a physical attack on it, for example if I try to carefully dismantle it in order to directly read the secret from its memory

2026-03-12 23:13:30 UTC

https://youtu.be/DFM140rju4k

2026-03-12 11:57:15 UTC

- reply

I've just turned off the emergency alerts on my phone
I expect it will be abused by the government
I'll turn it on again only if I'm in an area where there might be a genuine alert, e.g. tsunami risk
https://blossom.primal.net/88b27aaa545cbea7ac1db681b19bd4f1edf717e5757a768522643971b356b125.jpg

2026-03-12 07:47:16 UTC

- reply

What's your long term vision for on-chain privacy? I'd love a single coinjoin protocol that is used in many wallets
For example, I'd like common Lightning implementations to use conjoins for creating and closing channels

2026-03-12 06:47:09 UTC

- reply

So let's fix YAML too

2026-03-11 18:10:46 UTC

- reply

https://image.nostr.build/66e825084e6dd247dbe6bc3e056a57df6939b365a19aefc7c8c84307dc7e03fd.png

2026-03-11 17:57:17 UTC

Hacking feels good this evening, mostly because I'm using it as a distraction from hunger 😀
I decided two days ago to cut back drastically on carbs, so I need the dopamine from seeing tests passing to substitute
I'm suddenly craving chocolate

2026-03-11 12:17:38 UTC

- reply

I just tried to zap you @nprofile…asma
From Amethyst, via NWC https://blossom.primal.net/dc4de1091f79a64a5964085d35b247d0ec842bf7a56cee1ddf1cf2b764b34f4d.jpg

2026-03-11 12:13:28 UTC

- reply

Even when we fix or improve things in Bitcoin, we do it because Bitcoin incentivizes us to do it
Bitcoin isn't asking us to activate BIP110

2026-03-11 12:13:20 UTC

- reply

Bitcoin controls Bitcoiners, not the other way around

2026-03-11 12:05:15 UTC

- reply

Try ZeroClaw or NullClaw maybe
I must admit that I don't have much experience with any *Claws
There is no fundamental reason to OpenClaw to be so inefficient, it's just badly written (according to what I've heard from others)

2026-03-11 11:41:22 UTC

- reply

Nice!
So this would need a fork to be usable on chain on bitcoin?
This solves the mathematical problem of creating a single small signature that signs all the inputs of a given transaction?
And today (without a fork) we would need to include that signature replicated in every input

2026-03-09 17:21:21 UTC

- reply

I was wrong
I'll try to edit my post now
https://claude.ai/share/be0eb154-f751-4a2b-818d-49889051e2d4

2026-03-09 17:13:42 UTC

- reply

ClarkMoody says there's still 1 000 012.48 BTC left
https://blossom.primal.net/0ac758ca997100c968dad85687c0b9eb4ea15c87254936d123a7281a0874d264.jpg
https://dashboard.clarkmoody.com/

2026-03-09 14:56:27 UTC

- reply

Kick the can?
I'm suggesting the opposite 🙂.
It's something that we can do today, that future generations of bitcoiners might thank us for

2026-03-09 13:27:17 UTC

Noob question about @nprofile…radp:
Are DMs simply a full MLS group, but just limited by the app to two users?
So the Marmot protocol would allow a third user (or a second device for one user) to be added?
(That might be bad UX though)

2026-03-09 12:23:48 UTC

https://bitchat.free/
#nevent1q…68sw

2026-03-08 19:30:18 UTC

- reply

We should soft fork today to require that 80% of coinbase outputs must be anyone-can-spend outputs that are locked, via CLTV, to a few decades into the future
I mention this because of your point about future arguments about block subsidy, and your point reminds me of this idea to help with security budget in the future
Today's budget is more than sufficient, so let's move it to the future, where it might be needed

2026-03-08 18:20:58 UTC

Look after your knees!
I've just recovered from a knee injury and I'm loving hiking again
With the benefit of hindsight, I now realise that the relative lack of sport was affecting my mood and productivity for the last few months
And I'm enjoying the gym again
Bear markets are for (body) builders!
https://blossom.primal.net/57efe08accd2fa0e5be196ef66c85fd4243f5c2d24b93fb110bdb1b61b47f6d7.jpg

2026-03-07 11:02:06 UTC

- reply

Dropbox alternative where you pay somebody to store your data. Every day, you ask for a small amount (1 kilobyte) and they respond with a Merkel proof that they have it
For redundancy, you pay multiple services to store the same data, with your client (or watchtower) ensuring you always have at least N copies
All encrypted, only your client knows the decryption key
To change the data, you update the Merkel root with the server, sign something to release the old one, and the server signs that it is now responsible to host the new one
This allows us to prove if the server has failed

2026-03-07 07:44:29 UTC

- reply

If theb Digital Euro is suddenly serious about privacy, they should use the same tech as used in Cashu

2026-03-06 01:11:12 UTC

- reply

Exactly. I want us to be able to connect to many servers (briefly) and to pay for the service as long as the server is reliable
Nostr relays
Media servers
Wifi routers
maybe also Tor nodes, to incentive more Tor infrastructure
Your phone could be making dozens of tiny payments each minute, without necessarily asking permission from the user in advance

2026-03-06 00:43:27 UTC

If you already know something about has Cashu Spilman Channels work, then you might find this useful if you want some details to help you integrate it into your server
I have an 'integration kit' for each of four languages (Rust, Go, Python, TypeScript) where you can start receiving payments by just specifying a config yaml file and a few dozen lines of code
Still more to do to tidy it up, especially on the client side, but the server side is more complete now (pending real-world feedback which could change everything of course 😀)
https://github.com/SatsAndSports/demo_of_spillman_cashu_channel/blob/spilman.channel/ARCHITECTURE.md

2026-03-04 07:55:58 UTC

- reply

"New use cases should always get consent from the network"
I'm with him, as long as he agrees that a few dozen nodes are sufficient to grant that consent 😂
Large OP_RETURNs were formally approved by the relay network in 2024, by a few dozen nodes deciding to relay them. Therefore, the debate ended then
https://xcancel.com/BitMEXResearch/status/2024952265719611458

2026-03-03 21:49:38 UTC

🤯
https://image.nostr.build/3ff6ecae3f3b3f1aecd102e3cafe2e22b25c60e5256ed9b72ef3ff9a92e580e3.png
I don't actually know anything about zero knowledge proofs, so no real idea how serious this is
https://xcancel.com/osec_io/status/2028901596965552572

2026-03-03 21:28:09 UTC

- reply

Duke Nukem 3D

2026-03-03 19:53:29 UTC

- reply

@npub1d7e…lrf3 , any thoughts on Cashu mints using FROST for their collaborative signing?
I'm slowly learning a bit about how Frost works. It's allows n-of-m signatures, so maybe a Cashu mint could use this with multiple-signers so that it can keep running if one of the signers is down

2026-03-03 18:58:13 UTC

- reply

Brands on Amazon have crazy names because Amazon insists that they have a registered trademark. And a crazy unpronounceable name is easier for the intern at the USPTO (US Patent and Trademark Office) to confirm as new and distinct from all the existing names
https://stemerlaw.com/2025/07/16/why-are-amazon-brand-names-so-weird-understanding-trademark-registration-and-2d-and-2e1-refusals/

2026-03-03 07:23:08 UTC

Anyone working on a file storage system based on Merkle trees, paid via bitcoin?
So I pay your (blossom?) server a monthly fee to store my data, where I know the Merkle root of the data. [I'll describe mutable data below]
Every day, I ping your server for one randomly-selected (portion of a) file. You return the requested data, along with the Merkle proof that it's the correct data
If any data is missing, I can then publicize this fact, and challenge you publicly
(The data is encrypted of course, with a key that I never release to anyone, hence I don't mind publicly proving that the server has lost the ciphertext)
I pay multiple servers to host the same data, and my client will automatically copy data to new servers (paying them, of course) when one server fails
If I want to make a modification to one part of the data, then I simply send the new data to the storage server(s) and we update the Merkle root. The server signs the new root, committing to store it, and I sign a message which releases the old root
[When I say "Merkle root", I probably really mean using something like git's tree of file hashes]
#AskNostr
( @nprofile…n4yx )

2026-03-02 20:36:41 UTC

I told my agent to write some code "without side effects" and it thought that it was neither allowed to write nor read from the database. It felt funny to remind it that "no side effects" means it has permission to read, just not write.
The point I'm making is that coding models can still be pretty dumb sometimes, even stuff that I would consider extremely obvious.
GPT-5.2 Codex (via OpenCode)

2026-02-28 08:45:28 UTC

Sleep soundly, safe in the knowledge that the EU is "monitoring the situation"

2026-02-27 11:04:32 UTC

- reply

Can you elaborate?
I didn't consciously change my writing style in either direction, to sound more or less like an AI
Are you saying that humans will split into two groups: those that (accidently) write like an AI and lose credibility, and those that don't sound like AI?
Maybe I need a bot which will rewrite my draft messages so that they don't sound like a bot (thoughts @nprofile…ttc0 ?)

2026-02-27 09:53:48 UTC

Interesting times:
https://image.nostr.build/ce723b7036c021cdf886a9e1c7f0bc43828692ac24e07e95ccbf5d9a2de5b011.png
#nevent1q…p4jf

2026-02-27 08:36:20 UTC

- reply

For what it's worth, I'm not a bot
But I would say that, wouldn't I? 😀
My guess is this is a scam, where I can 'verify' my human-ness by paying a subscription to the owner of the bot

2026-02-26 21:03:21 UTC

When I run a PWA (e.g. cashu.me) on Android with Orbot (the tool which wraps your chosen apps into a Tor connection), is it sufficient to configure Orbot to wrap the corresponding browser (Firefox or Chrome, ...)?
I ask because Orbot lists all the apps and allows to toggle Tor on and off, but none of the PWAs are on the list.
I guess my broader question is: what's a good way to get Tor Cashu support on Android? Either natively in the app, or via Orbot?
@npub17fz…9yxv
#AskNostr

2026-02-26 09:54:42 UTC

Dennis Porter has made an announcement. Bottom is in!
Seriously though, I like the definition of "cryptocurrency" in this Bill in Indiana, especially the last line which rejects stablecoins
https://image.nostr.build/c4395631a22edc4062de494f904103400b22d2cec59a49607630925d2a108377.png
I'm not sure if it includes developer protections
A couple of days ago, I banned myself from interacting with X. I'm just allowed to read/follow/block. Anyway, here is how I found this:
https://xcancel.com/marsspitsbarz/status/2026799674548453509

2026-02-25 20:48:06 UTC

- reply

I couldn't get it working when trying Numo with a friend
Is cashu.me supposed to be able to tap-to-pay?
(I guess I just need to configure something related to NFC on one or both phones?)
My friend's Android has cashu.me, installed via Chrome as a PWA.
I installed Numo on my phone; a Huawei P30 Pro (quite old, but it has NFC). I entered 16 satoshis on the green screen, and then pressed 'Charge'. The black and white screen with the QR code and 'Scan or tap to pay' came up
With cashu.me open my friend's phone, we put it on top of my phone. Eventually, I got asked to choose between one of two options (If I remember correctly, something like 'Cashu Payment Service' and 'Phoenix ...'). I selected the Cashu Payment Service and then I got this screenshot
I couldn't get any further, either by touching this on my screen, or by moving our phones around.
https://image.nostr.build/6cebb2cb9bfdc2a5f56346aa129508129b9f4f68f7f1733253494ffa5e8c31c4.jpg
The NFC settings on my phone, the one running Numo:
https://image.nostr.build/898ad255c945ffbf95a0de4eb4882ad9dcf86a6bf0c0c0eb3c0112195a2dc6ae.jpg

2026-02-24 22:21:36 UTC

- reply

Giving up X (again 🙂) also helped getting me back!

2026-02-24 21:18:58 UTC

Back at coding today, after about a week off
Most of my injuries suddenly cleared up and I got hooked on being active again (bouldering and weightlifting), so I overdid sport and was too tired/lazy even to code 😀
Gotta learn some balance
https://image.nostr.build/25666b6ba7af0f15efb1af88cb6900f118ca27bfc1d3aecaac472bbe78e4ed85.png

2026-02-24 14:43:25 UTC

- reply

You keep mentioning "spam". Why?
I work on bitcoin systems to make bitcoin the best form of private and scalable money. I judge each proposal, e.g. BIP110, on whether it helps or hinders our monetary goals
BIP110 harms the moneyness of bitcoin in many ways, for example making it harder to run a node, and therefore I'm not going to give BIP110 a free pass because of some spam paranoia

2026-02-24 13:13:47 UTC

- reply

Low on-chain fees is healthy for bitcoin. We want to keep fees as low as possible, for as long as possible
(Some of you might be tempted to disagree with me, but the bitcoin network doesn't care about our opinions 😂; it autonomously decides to go in roughly the direction I lay out here)
Low fees are helpful for the security of Layer 2s such as Lightning, as it makes it easier for the honest party to get their transaction on-chain in a crisis. And low fees obviously help with scaling bitcoin
So our collective goal is to keep transactions off-chain as much as possible
An inevitable consequence of that is spam, but that doesn't matter. As long as we keep the spam in contiguous data (e.g. OP_RETURN and Witness data) then there is no harm to node runners.
I'd much rather 100kb of contiguous-data spam, than an extra 1kb of data in the UTXO set
Unless your money transactions *decreases* the size of the UTXO, please use Layer 2 instead

2026-02-24 10:43:46 UTC

- reply

- There is no oligarch twisting an algorithm to show me ragebait
-;Blocking works here. On X, they just show me another bot
- All the other protocols built on top of it, like White Noise

2026-02-24 07:31:30 UTC

- reply

"Core30 changes were retarded"
See this X post for the history, you'll see that the debate ended about 18 months before Core changed any relay defaults
This OP_RETURN debate started and ended in early 2024 when Mara announced Slipstream, an out-of-band way to submit transactions
That gave them an advantage, an advantage that small miners and small pools don't have. In response to this, the network autonomously quickly relaxed the relay policy to accept large OP_RETURNs. They did this by configuring their Core node; LibreRelay was too new to have been the main factor here
Since then, a restrictive policy has probably had no effect, but it might have had a small harmful effects on miner decentralisation and node decentralisation
No-one can say Core "rushed through" a change, when it was catching up with the network's decision from 20 months earlier!
The bitcoin network, i.e. the few dozen noderunners who relax policy at the appropriate time, don't need permission from Core or Knots or you or me, when they want to defend miner decentralisation and node decentralisation
https://xcancel.com/BitMEXResearch/status/2024952265719611458

2026-02-23 19:15:21 UTC

- reply

Yes indeed!
Now I'm thinking that every token should have P2(P|B)K in it. To create an anyone-can-spend token, we should include a random key and a signature for it
My goal is to maximize our anonymity sets so that every token looks the same to the mint
(I just thought of this a couple of minutes ago, so maybe it's crap 😀)

2026-02-23 10:04:37 UTC

- reply

And the posts from The Bugle manage to be both at the same time 🙂

2026-02-22 22:15:00 UTC

- reply

Bip 110 would have the effect of putting spam into the UTXO set, harming node decentralisation, and the strict relay policy of Knots would centralise mining by encouraging miners to use out-of-band systems. It's an attack on all the important aspects of decentralisation, including Luke's desperate attempt to make himself the lead developer
This debate ended in early 2024 when, in response to Mara's Slipstream, the bitcoin network (without asking permission from Core or Knots) relaxed relay policy in order to defend mining decentralisation

2026-02-21 23:17:44 UTC

- reply

We want on-chain fees to be as low as possible for as long as possible, as it helps with the security and scalability of Layer 2s
Similarly, we don't want people to put more monetary transactions on-chain "in order to price out the spam", for the same reason basically. If your monetary transaction is going to increase the size of the UTXO set, we'd prefer you to use a Layer 2, even if that means the blockspace is taken up by an OP_RETURN instead
The only time we want people to put transactions on-chain is if they consume more inputs than the number of outputs created
TL/DR: the long term goal is to keep blockspace cheap, to help with scaling, and for the inevitable spam to be in OP_RETURNs and in Witness data

2026-02-21 20:07:50 UTC

A line from 'Hackers' (1995)
Say no to censorship!
https://image.nostr.build/66299f8a6dbe8a8570edabf7c599a10b5a52340f187495a9c526631f9dc79fd3.png

2026-02-21 17:08:18 UTC

- reply

Exactly.
It's a common mistake to think of 'dev teams' as being distinct from each other. In open source, that can't really happen. Anybody can contribute to multiple projects simultaneously and I can, without your consent, copy your open source code into mine.
In open source, there will always be (at least) one repository that has the best code. And therefore, as it's the best code, there is no need for duplicate repositories and therefore there will be just one repository.
This *appears* centralized, but it's not.

2026-02-21 15:15:26 UTC

- reply

2026-02-20 10:59:53 UTC

- reply

Thanks for that. I'm going to follow up here, but I apologize in advance if it seems like I'm changing the subject a bit 😀. My goal is to clarify the order of events, and I'm doing that to help myself think about exactly when we should reject blocks:
TL/DR: even if 55% signalling is reached in one block, the RDTS rules won't be enforced until at least two weeks later.
Two scenarios, discussed separately:
The simplest of the two scenarios is that it never reaches 55% hashrate. In that case, mandatory signalling starts at 961632. This is the first time that BIP110 nodes can reject blocks that would be acceptable to the conventional (i.e. Taproot) nodes. This doesn't guarantee that a split will happen immediately, the BIP110 miners could be lucky and get the first few blocks, but it is the earliest [in this scenario] when a split could occur. After 2016 blocks in this state, they reach their 'LOCKED_IN' state. From the BIP "The deployment transitions to LOCKED_IN at height 963648 (one retarget period before max_activation_height), then to ACTIVE at height 965664". During LOCKED_IN, further signalling is *not* required, and miners do not enforce any of the RDTS rules on transactions. It's only in the following retarget period, that they finally reject transactions with large OP_RETURNS and all the other banned transactions
So, summararizing the timeline in this "low hashrate" scenario:
- 961632 to 963647: mandatory signalling, i.e. a permanent chain split can occur here.
- 963648 to 965663: LOCKED_IN. No rules applied, not even any mandatory signalling
- 965664 onward. ACTIVE. Blocks are rejected based on whether the transactions follow the rules
The second scenario kicks in if they get 55% of hashrate. Once they get 55%, they don't immediately reject non-signalling blocks, and they don't reject big OP_RETURNs. When they reach 55% (1109+ blocks out of 2016), the *following* 2016 blocks are in the LOCKED_IN state, i.e. no rejection rules applied. After 2016 blocks in LOCKED_IN, then they switch to ACTIVE and reject blocks with large OP_RETURNs

2026-02-18 17:17:58 UTC

- reply

I can see this, from Amethyst. Haven't tried any other client
Maybe it depends on the relays?

2026-02-18 10:38:43 UTC

Giving up X for at least a couple of weeks
I might check once a day to see if I have an interesting notification, like an interesting reply to something I said
Prior to summer 2025, I had avoided X for about three years. Maybe I should do that again!

2026-02-17 19:10:10 UTC

- reply

Good point 🙂

2026-02-17 00:49:50 UTC

- reply

Instead of complaining, shouldn't you be coming up with your long-term solution to spam?
i.e. the solutions that will kick in on your fork after the one-year restrictions in the RDTS?
You've already had many months to think about this. Stop wasting times with lies on X. Start planning something credible

2026-02-14 23:20:25 UTC

While I've been using nvim + opencode for a while now (thanks to a post by @npub1mhc…c226 IIRC), I only just this evening integrated git into it properly, in order to make it easy to view the changes made the AI and then challenge the AI about specific changes
I'm using three nvim plugins: gitsigns, telescope, and I've configured 'diffview.nvim' but haven't really used it much yet

2026-02-14 16:27:57 UTC

- reply

When are we going to fix coinjoins? 😀
This needs funding
We need a very high quality BIP for a *protocol* such that even the coordinator doesn't know which inputs correspond to which outputs. And then we need at least one high quality fully-open-source implementation of this.
Peter Todd did an interesting piece on this topic. With blinded signatures (i.e. the cryptographic tech in Cashu) it is possible to keep the coordinator in the dark
In that context, it would be fine if there was just one main coordinator that is responsible for the vast majority of coinjoins. That would allow the typical Bitcoin block to just be one big coinjoin. If the protocol doesn't require *trust* in the coordinator, then we can simply choose the most 'reliable' coordinator, where reliable simply means that it's online and doesn't rotate their keyset too often
https://petertodd.org/2025/coinjoin-comparison @npub1ej4…ndrm

2026-02-14 15:16:46 UTC

- reply

(my final reply on this video)
Guy is right at 1:38:10 (and Mechanic wrong) when Guy said that a URSF will do something like require that the block at the activation height must have a large OP_RETURN.
Similarly, there will be a two-week period where BIP-110 has a consensus rule requiring that blocks signal for BIP-110 (version bit 4, IIRC) and reject blocks that don't signal. A URSF could reject the blocks that do signal and accept those that don't
There are lots of different ways that URSF could work. A URSF only has to apply to one block, forcing that block to do something that is rejected by BIP-110, and that is sufficient to ensure that the BIP-110 chain will never be accepted by the URSF clients, no matter how long it gets
To give one very simple and understandable example. We could code and release and run a URSF client today which requires that block 965664 contain at least one large OP_RETURN

2026-02-14 14:36:22 UTC

- reply

At 1:30:05 Mechanic says "are you going to URSF? I don't think so. .. Seems unlikely to me"
There are many of us willing and able to URSF. At a minimum, we'll call "invalidateblock" on the first BIP110 block (if it ever finds a block)
This isn't an idle threat, it's an obvious truth. Mechanic might strongly dislike our opinion, but it's bizarre to pretend that we literally don't exist
For example, I have no problem agreeing that many (dozens, or thousands) of people will run BIP110 nodes through the activation height. (In fact, I'm one of them!)

2026-02-14 14:26:41 UTC

- reply

At 1:26:10 , Mechanic agrees with Guy (correctly) that "15 folks with AR15s" can be very effective
In relay policy that's also true, for the nodes that wish to*relax* policy.
15 LibreRelay nodes have a bigger effect on relay policy then a million filtering nodes

2026-02-14 14:00:02 UTC

- reply

Around 1:11:30, Mechanic falsely said that Gloria is no longer a Core developer
She's no longer a Core *maintainer*
Maintainer ≠ Developer
and then another one of you randomly made the claim that she was encouraged to leave by Chaincode. Bizarre claim
And then Mechanic literally says that the "Devs think bitcoiners are shitty people" "She was obviously in contempt of bitcoin and bitcoiners"
and then bizarre claims that "the Devs" and "VCs" successfully pushed her out. Obviously false frankly

2026-02-14 13:19:17 UTC

I first read this YouTube preview as saying:
"Stop trying to make Luke's Consensus change happen"
https://blossom.primal.net/1dc27a4c5853bbb3ca9d132cc3e5905b8934413e38306b779bc9e4200f678ffc.jpg
I guess I'm spending too much time on X arguing about the fork

2026-02-14 09:26:01 UTC

- reply

Exactly!
TL/DR: Welcome to open-source, where people work on what's important to them. If you don't like it, fix it - or fund it - yourself 😀

2026-02-13 21:42:59 UTC

Asking AI the important questions:
(inspired by seeing this game in 'Hackers', the 1995 movie)
https://image.nostr.build/5cea4d6cf748da947902d6a519480aa161ca53e56addab808da7a676146d6f5f.png

2026-02-13 20:23:34 UTC

- reply

Very true:
> even without AI, a whole bunch of slop gets developed out there. Especially in companies where you have deadlines. You have no idea, how much BS they create under pressure. Accumulating technical debt for decades
My 'engineering' colleagues aren't good and are badly led. They can't deliver anything with quality above a certain level of complexity. AI simply means they get to their crappy solution sooner rather than later. It doesn't help them step up to a better level of quality.
But the people who actually are good engineers, who understand everything you discuss, are being supercharged by AI if they are careful to understand its strengths and weaknesses

2026-02-13 19:53:34 UTC

- reply

Thanks! Makes sense
I'm expecting a future where many blossom servers require payment (something I'm working on).
So perhaps some day this Morganite could handle making the payments

2026-02-13 19:22:30 UTC

- reply

PS: Cashu is obviously good with Bitcoin and Lightning, but the Cashu protocol with with any currency ('unit' in Cashu lingo), so this channel system can work with any stablecoin if there is a Cashu mint that supports that coin

2026-02-13 19:20:53 UTC

- reply

I'm working on Spilman (i.e. one-way) channels over Cashu, it's been my main focus since around September
A client and a service provider do need to trust the Cashu mint, but they don't need to trust each other. The client can easily set up a channel (it's just a cashu token, basically) and then easily release small amounts (one sat, or even millisat) at a time.
This allows dozens of micropayments per second, where a payment simply involves sending the signature of an updated commitment transaction, and the receiver can verify the signature instantly (they can verify the signature without communicating with any third party). The service provider can close the channel at any time, taking only what they are due, and the remainder is immediately released back to the client.
Here's draft guide on how to integrate it. The code is relatively complete, with a lot of tests, but it still has quite a lot of AI slop.
Not ready for real sats yet, but I'm meeting some Bitcoiners in a couple of weeks in Madeira, so I have a goal to tidy it up by then
https://github.com/SatsAndSports/demo_of_spillman_cashu_channel/blob/spilman.channel/INTEGRATION.md

2026-02-13 11:32:49 UTC

- reply

I have to ask a stupid question: What does this actually do? 😀
Is this for content I create, or content I consume? Or both?
Does it connect to other blossom servers?
How do I connect it to other apps such as Amethyst

2026-02-13 10:46:33 UTC

- reply

Indeed. I spent too much time on X, and on my fiat job this week
Looking forward to some freedom tech this weekend! 🥜

2026-02-12 22:10:45 UTC

- reply

Why didn't you respond to anything I said in my post?
Your generic response suggests you didn't read anything that I said

2026-02-12 11:18:55 UTC

- reply

One problem is that people like @npub1cjw…j2rh don't understand that open source software always leads to *apparent* centralization
@npub1lh2…a9nk made a pull request to Bitcoin Core just in January, to fix some issues with 29.x https://github.com/bitcoin/bitcoin/pull/34370
Thanks Luke! The point I'm making is that these are not distinct groups of engineers, working separately on isolated independent codebases, with no permission to contribute across projects. The reality is very different
Stop thinking of this like it's Apple-vs-Microsoft or Android-vs-iOS. In open source, the barriers to switching to the better repository are much lower than you think
If Core v30 was controversial among the devs that aren't already working on Knots, any one of them could trivially have forked it to have whatever change they wanted
When anybody makes a pull request to one project that improves it, they can easily make the same PR to multiple projects, or a third party can copy and paste the change
We have lots of great code, and lots of great engineers, now supercharged by AI. Once one repository earns the track record of accepting the best PRs, it naturally becomes the center of attention. It *appears* centralized, but it can trivially move to another repository if the other repository is better

2026-02-12 09:08:14 UTC

- reply

Ah! It worked on my fourth attempt

2026-02-12 08:59:51 UTC

- reply

I tried to zap you, Aaron
https://blossom.primal.net/a995bc9c8631be4d7225edc02104afdb53c4c7a7f9d3c0a81d31f0f6f0fef41e.jpg

2026-02-12 08:50:36 UTC

- reply

I made this chart on why BIP110 is anti-bitcoin. "Spam" was never the debate
The rest of us care about scaling bitcoin, and we are very successful at ensuring that the UTXO set is kept small, and ensuring big miners don't benefit from out-of-band systems
Knots/BIP110 is an attack on Bitcoin. But it's also now a boring distraction, and therefore we'll see more blocks signal for BIP54-Consensus-Cleanup than we do for BIP-110
satsandsports.github.io/BIP110/

2026-02-12 07:14:01 UTC

- reply

Indeed
Does anyone remember that Maduro is still kidnapped in the US somewhere?
I wonder what they'll come up with next? Kidnap the Canadian or Danish prime ministers?

2026-02-11 09:48:10 UTC

- reply

But if I use the same address on many sites, then they can be linked to each other
And it would be easy to link to a Nostr identity
Bolt12 is better. I can easily generate many Bolt12 offers from my node, and they'll be different from each other and can't be linked

2026-02-11 09:20:00 UTC

- reply

Looks like fun. Thanks to whoever made it!
A suggestion: it shouldn't require a Lightning address to play. It would be nice to have more privacy-focused approach, like Bolt12

2026-02-09 09:21:44 UTC

- reply

Given that Rust has no UB! , why do people say that Rust is Co(re)mmunist?
🤔

2026-02-09 09:19:10 UTC

- reply

The world is very lucky that, in the US, code is considered speech and is therefore protected by the First Amendment. This legal idea developed only in the 1990s
In much of Europe, as I understand it, code is classified much like an act of creative expression like a song. And therefore it's more subject to regulation such as copyright and so on
So we need to fight for "code is speech' also, not just "free speech", globally
https://en.wikipedia.org/wiki/Code_as_speech?wprov=sfla1

2026-02-08 23:38:04 UTC

Your daily reminder that property-based testing is the the way. OpenCode/Opus4.6 is happy that it can make the change I requested (hashing a shared secret) without having to change any of the 50+ tests:
https://image.nostr.build/5face9150de26cf2c81a02d65eaf18f98cb427b3fb6f9606086ec1fad2ff0923.png

2026-02-06 11:48:53 UTC

- reply

BIP 110 contains literally nothing that a "monetary maxi" (whatever that is) would want to see in a Bitcoin Improvement Proposal. Nothing to help Layer 2s to scale. Nothing to help the relay network with DOS attacks. Nothing to help privacy. Nothing to help small mining pools to see the same transactions that the big pools are getting. Nothing to help with the faster block propagation that will benefit the small pools. Nothing like Cluster Mempool, which will help small pools to play on a level playing field with the big pools.
The long term future of Bitcoin depends on anonymous miners being able to connect to the network, see all the transactions that are likely to be mined, quickly see the other blocks so they can mine on top of them, and be able to broadcast their blocks and have them propagate quickly and be built upon by the other miners. This is needed to ensure the small miners and small pools can mine profitably, i.e. they have an incentive to mine things that the government-controlled big pools are unwilling to mine. They must be able to include any consensus-valid transaction; i.e. have no corporation or committee or government which blocks the 'naughty' transactions
BIP 110 contributes nothing to any of this. It doesn't even try to do so
If you want less spam in the blocks, maybe them smaller. Luke Dashjr has suggested 300kB. Why not go further? 100kB, 10kB. 0kB would get rid of all the spam.
That might seem like a stupid point in the last paragraph. But I'm actually making a very important point. Our goal is to make Bitcoin the best money, to maximize its ability to instantly settle our private transactions at a very high frequency. If you "fight spam" and you don't care that you are harming the moneyness of bitcoin, then I can't talk to you. "Fighting spam" simply isn't a valid goal in itself; it best, it's a means to an end. Every proposal that somebody makes to fight spam will be judged exclusively on how to helps or hinders our real goals
We want and need our Layer 2s (Lightning, Ark, Lightning on Ark's Channel Factories) to massively scale, along with other Bitcoin scaling ideas like Cashu, in order that billions of people can make dozens of payments each day. (I'm working on extremely-high-frequency micropayments within Cashu)
We want as much as possible to stay off-chain in order to keep fees on blockchain as low as possible. Low fees today gives us room to onboard billions of people. Low fees help with security of the Layer 2s, as users of Lightning need the ability to quickly and cheaply access Layer 1 if their channel partner is cheating
We will continue to work on all the above, making the fees on L1 as low as possible
This means that blockspace will, if we succeed, stay cheap for a long time. Also, there is a basic fact:
Basic Fact: Steganography exists
If blockspace is cheap, then spammers will fill it with spam. This is a meaningless and fully-expected side effect.
There are lots of ways to encode spam in the blockchain. Some methods involve contiguous bytes and some do not. Nobody really cares about the distinction. Pseudo-lawyers will try to pretend that contiguous bytes are more dangerous than non-contiguous
But they are wrong legally, wrong technically, and wrong in every possible way about "contiguousness". The "contiguous" discussion is now over
Remember Mike Hearn and his "RBF derangement syndrome"? Remember MempoolRBF? If big pools are getting consensus-valid transactions via out-of-band systems (e.g. Mara's Slipstream) and are including them in blocks, then this is an advantage to big pools and a disadvantage to small pools
We know that a critical responsibility of the public relay network is the help the small pools so they can earn money at the same rate as the big pools. This is what decentralized mining is all about
Therefore, there will always be people who will help to relay those kids of transactions, in order to help the small pools. They'll mine fee-bumping transactions where the original transaction didn't signal willingness to be fee-bumped. They'll mine under 1-sat-per-vByte. They'll mine large OP_RETURNs if the big pools are benefiting from them
When a spammer posts a large OP_RETURN via an out-of-band system, we don't care about the fact that a spammer posted the transaction. It could be a heroic freedom fighter getting important information - or important payments - onto the chain. Spammer-vs-monetary is not the issue. BigPool-versus-SmallPool is the issue
As every Bitcoiner has learned in recent years, it's sufficient for a few dozen people to switch on relaxed nodes (LibreRelay, Core with lower fees rates, ...) and they will win. Moving policy close to consensus is easy to do, simply by firing up a few nodes. Trying to do the opposite, firing up thousands of filtering nodes, is laughably stupid
There will always be many people willing to help the small pools by relaxing their policy in cases where the big miners are getting this advantage. If you don't like it, you must engage your brain to think of a good response. If your opponents can trivially beat you by switching on a few dozens nodes, then you need to accept their existence as a fact in your game theory
The Knots movement pretends to be for decentralization of mining. If that was true, they would encourage (in the right circumstances) things like LibreRelay. It's truly bizarre that they took literally the opposite approach, and are trying to make it difficult for small pools and small miners.
Why do people run nodes? There are broadly two categories of reasons. Obviously, we run them for our own ability to make transactions and to monitor that our transactions go through correctly. But there are also less "selfish" motivations. I run my node in order to help small pools. We need to keep the miners divided, working for us, and that means allowing small miners to mine whatever consensus-valid transactions they want, and it means ensuring it's economically viable for them to do so.
That is the main role of the relay network, and a few dozen 'non-filtering' nodes are sufficient; and this is why Bitcoin will win.
Finally, BIP110 explicitly attacks many important things for the moneyness of Bitcoin. Attacking the OP_SUCCESS opcodes is particularly dumb. No sane person thinks that Bitcoin won't be having dozens of OP_SUCCESS opcodes for centuries to come. Just get over it
There's a lot more that I can say on this. Clearly, the orchestrators of BIP 110 relish in all the sexist and abusive rhetoric that is spread by their retarded bots and lapped up by some plebs. But I'm too lazy to write about that
Basically, my first paragraph above sums it up nicely
#bip110 #AskNostr #Spam

2026-02-06 08:25:23 UTC

- reply

As you can see, I didn't see that loser's comment as I had already blocked them before you made your post
Just block and move on. Let their bots talk to each other in the void
https://blossom.primal.net/9cacffebf4e04e5aa7430cbdf866aa47340373826ce96bc0b7eb9e0055469cad.jpg

2026-02-04 19:00:30 UTC

- reply

My guess is that this is a Blossom hash combined with some video-specific metadata

2026-02-02 08:17:06 UTC

- reply

I've been trying to start an openclaw on my VPS inside either docker or podman (podman is very similar to docker), but without much success. Keep getting annoying problems (probably just my fault)
Are you doing something like that?

2026-01-30 09:23:07 UTC

- reply

You mean $100k (or €100k) as the one-off cost of buying the hardware? (Maybe I misunderstood, I haven't been following the economics of this)
I guess one disadvantage of local hosting is that it (the hardware) is under-utilized, and that motivates sharing the hardware among multiple users
I guess that's where Routstr ( @nprofile…mt7m ) comes in, enabling a large marketplace of (small) providers, paid via bitcoin of course