Nostr notes by SatsAndSports

de-slopifying protocol specs, not de-slopifying code ...

2026-10-05T17:02:36Z

de-slopifying protocol specs, not de-slopifying code

https://github.com/SatsAndSports/MONAD/blob/09d21f7e6fccac4b81219c1f67a7ae4c882f8a4d/docs/control-protocol.md

Can you say more? They don't approve of crypto that depends ...

2026-09-20T14:53:36Z

In reply to nevent1q…k7gy
_________________________

Can you say more?

They don't approve of crypto that depends on inversion?

Or it can't be done in a way what's safe from timing attacks?

Or some other problem that I don't understand? 😂 (Yet)

I want an app where I can swipe left on a reply here and see a ...

2026-09-06T07:49:34Z

In reply to nevent1q…fcqz
_________________________

I want an app where I can swipe left on a reply here and see a few options to block a user

I block a lot when I go into replies. It's tedious to do though; should be much smoother and easier

For those that have their own (local?) hardware for llms, how ...

2026-09-03T16:11:24Z

In reply to nevent1q…a3qj
_________________________

For those that have their own (local?) hardware for llms, how easy is it for them to sell access - via routstr - to their hardware when they themselves aren't using it?

Unfollowed two npubs just now because they turned out to the ...

2026-08-30T09:08:26Z

Unfollowed two npubs just now because they turned out to the generic big-blocker bots that we see so much during attacks on Bitcoin

Why do so many attackers (including BIP110ers) always run out of ideas and just randomly attack Lightning and use emotional MoE arguments?

Makes me more convinced that Lightning is the correct approach 🤣, and that we have the right incentives and game theory for Bitcoin

We're making an asset that nobody wants to spend, and which can be transferred with private instant settlement. This is how you play the long game, making it the world's MoE

I don't want to be rude, but: Bitcoin is following the game ...

2026-08-30T08:30:05Z

In reply to nevent1q…24z9
_________________________

I don't want to be rude, but:

Bitcoin is following the game theory that I described. That's a good thing. That's why we had to win the blocksize war

Do you expect your long piece to convince me to ignore Bitcoin's incentives?

"You cannot build a monetary system by treating the money as ...

2026-08-30T07:32:52Z

In reply to nevent1q…xwky
_________________________

"You cannot build a monetary system by treating the money as too sacred to use"

Well actually, this is the plan for bitcoin, and it's the right plan

It's the most ambitious plan

It's the only way for bitcoin to be the world's MoE

We make an asset that nobody wants to spend and which can be transferred easily and quickly with final settlement (Lightning)

If you think that contradicts the "world's MoE" goal, think about the game theory some more

If you can't go --offline, maybe close channels before ...

2026-08-27T08:22:34Z

In reply to nevent1q…qrny
_________________________

If you can't go --offline, maybe close channels before shutting down?

I guess I was a bit repetitive, and I wrote too much. I'll be ...

2026-08-14T15:30:08Z

In reply to nevent1q…s6c4
_________________________

I guess I was a bit repetitive, and I wrote too much. I'll be shorter:

Did you *want* BIP110 to activate? (Your preference)

Did you think it would get the necessary support? (The preferences of others. Game theory, ...)

I guess your answer is "Yes" to both, but I'm curious which of those two - if any - you would be willing to discuss with me

Hi. I hope you don't mind me replying, but I think you're ...

2026-08-14T07:53:45Z

In reply to nevent1q…fqf4
_________________________

Hi. I hope you don't mind me replying, but I think you're misunderstanding what happened with BIP110

(I enjoy following you, as I feel that you are different from many bitcoiners here on Nostr, and it's useful to follow different perspectives)

The big miners didn't really *reject* BIP110, they simply ignored it. They just kept mining Bitcoin blocks as usual. Dathon Ohm lied when he said the big miners did a "secret hard fork".

Some users configured their nodes to reject Bitcoin blocks, and therefore it's no surprise that they ended up on a different chaintip; sorry if this is uncomfortable to read, but it's true

BIP110 was harmful to Bitcoin's monetary purpose. It would have made it more difficult to run a node, by forcing data into the UTXO set; and that's the worst outcome for node decentralisation

The Knots and filtering movement is harmful to mining decentralisation, as it makes it difficult for small miners to see what's going to be mined. The "Tolerant Minority" fought back, to defend decentralisation, by helping small miners to see all the fee-paying transactions; they did this by relaxing their mempools to relay more transactions

So, it's good that BIP110 was ignored by Bitcoin. And the BIP110 leaders told many lies about "game theory", as well as generally being egotistical maniacs

"attack" The Bitcoin network did literally nothing. It ...

2026-08-11T07:28:11Z

In reply to nevent1q…zpwa
_________________________

"attack"

The Bitcoin network did literally *nothing*. It didn't even notice BIP110

No URSF, no invalidateblock.

Miners didn't make any change to their templates, or their signalling code

Bitcoin didn't defeat BIP110, it ignored it

The second one is indeed safer. But I don't think they'll ...

2026-07-29T15:24:01Z

In reply to nevent1q…fhnu
_________________________

The second one is indeed safer. But I don't think they'll ever get 4032 blocks; I'm not even sure they'll get 4 mandatory signalling blocks

So I think if you want to guarantee that splitting is possible, then - like you said - you need something like this:

1. make a splitting transaction, with a large op_return, and broadcast it at or after the start of mandatory signalling (August 8th/9th), and broadcast it on the "legacy" network
2. If that confirms on both chains, then the "split" has failed, and a BIP110 miner broke the default policy. You haven't lost funds, you just need to start again from the new address.
3. When it confirms on the legacy chain, then you should quickly RBF to spend the funds back to yourself
4. Now you have successfully spilt (unless you're unlucky and reorgs happen!)

.. come to think of it, that's just too messy, I think

Are there tools to download the list of all the songs I've ...

2026-07-28T20:31:56Z

Are there tools to download the list of all the songs I've liked on Spotify or Youtube Music?

I'm not asking for the actual audio itself, just to backup the lists of songs

#AskNostr

Philosophy is cool and all, but if the hashrate falls to very low ...

2026-07-16T12:29:07Z

In reply to nevent1q…d3rg
_________________________

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

That's too vague The wording should be explicit about ...

2026-07-13T15:38:11Z

In reply to nevent1q…5qlv
_________________________

That's too vague

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

Liar

2026-07-13T13:47:05Z

In reply to nevent1q…hx55
_________________________

Liar

The plebs love community so much because they don't know how ...

2026-07-11T14:22:34Z

In reply to nevent1q…6jfa
_________________________

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

I love K2.7. I've used it very heavily for a few weeks. They ...

2026-07-06T14:18:39Z

In reply to nevent1q…3800
_________________________

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

I think both parties need to have a cashu wallet set up (with ...

2026-06-29T07:42:06Z

In reply to nevent1q…ylvf
_________________________

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

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

2026-06-26T22:09:19Z

In reply to nevent1q…qlq7
_________________________

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

.. PS: I should add that this kind of thing might work if you ...

2026-06-26T20:33:37Z

In reply to nevent1q…s4r0
_________________________

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

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

2026-06-26T20:19:04Z

In reply to nevent1q…seyd
_________________________

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

I'm drafting a system I'm calling MONAD. It's kinda ...

2026-06-26T20:17:10Z

In reply to nevent1q…wqk3
_________________________

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 Cashu (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

A 'Senior Principle Engineer' in my fiat job thinks that ...

2026-06-26T15:41:50Z

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

On Twitter, I'm unfollowing/muting people who interact too ...

2026-06-26T08:09:26Z

In reply to nevent1q…mxxf
_________________________

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 🙂

True. But I'm still going to block that account myself, ...

2026-06-24T17:54:27Z

In reply to nevent1q…t8cx
_________________________

True.

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

... and when I ask it to check for updates beyond 12, it says ...

2026-06-23T08:20:20Z

In reply to nevent1q…ud80
_________________________

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

I'm on EMUI 12.0 on my Huawei phone. (I'm not sure if ...

2026-06-23T08:18:12Z

In reply to nevent1q…k9zf
_________________________

I'm on EMUI 12.0 on my Huawei phone.

(I'm not sure if that answers your question though)

The NIPs repo should be forked and given a new name (PINs - ...

2026-06-22T09:36:27Z

In reply to nevent1q…myvf
_________________________

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"

Trying to ban myself from working on freedom tech today, as ...

2026-06-22T09:11:56Z

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

I think others will do one, better than me, before me 🙂 And I ...

2026-06-21T20:08:37Z

In reply to nevent1q…a89f
_________________________

I think others will do one, better than me, before me 🙂

And I have plenty of other stuff to do

The channel factory idea doesn't require any particular ...

2026-06-21T12:19:42Z

In reply to nevent1q…4lst
_________________________

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

I think I finally fully understand Ark, and will try to explain ...

2026-06-21T09:15:57Z

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

The British sense of fun around elections is great. This is a ...

2026-06-19T12:00:15Z

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

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

2026-06-18T19:53:15Z

I ran twice today. 7.5km each time

It's nice to suddenly be addicted to jogging again

I learned about cryptography in uni in the late 1900's Back ...

2026-06-17T13:58:54Z

In reply to nevent1q…9qp2
_________________________

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

Great story #nevent1q…ss3c

2026-06-17T12:44:05Z

Great story

quoting
nevent1q…ss3c
Just started listening to LynAlden (nprofile…2smn)'s The Stolguard Incident.

Can’t recommend it enough (and I can’t even say I read too much from/sci-fi). It’s been a nice break from my typical reading of nonfiction, politics, sociology, macro etc.

And man — walker (nprofile…f8xl) and CARLA (nprofile…8dxy) do a phenomenal job, so fun.

It’s also left me inspired to (at some point!!) get to work on the novel I want to write. Alas, work and fam life is busy right now…but hopefully soon.

I'll go to Bitdevs tomorrow. I missed it the last few months, ...

2026-06-16T22:00:12Z

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!

Adam Smith was pretty smart, but he got a lot of the history ...

2026-06-16T17:54:45Z

In reply to nevent1q…a6vw
_________________________

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 😀

A small comment: I'm not expecting the cashu channels to ...

2026-03-21T13:33:32Z

In reply to nevent1q…fxs6
_________________________

A small comment:

I'm not expecting the cashu channels to become bidirectional (i.e. like LN-Penalty)

Or more precisely, even if someone implements bidirectional (something I've thought about a lot), the unidirectional (i.e. Spilman) variant is still a lot simpler and more efficient.

The unidirectional version doesn't require a round trip per payment

I couldn't get it working when trying Numo with a friend Is ...

2026-02-25T20:48:06Z

In reply to nevent1q…a34k
_________________________

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.

The NFC settings on my phone, the one running Numo:

Many systems (including bitcoind) don't directly have Tor ...

2026-01-27T00:41:15Z

In reply to nevent1q…t96x
_________________________

Many systems (including bitcoind) don't directly have Tor support built in and they instead connect to a local socks5 proxy which is exposed by the Tor instance which is running locally too. So, after a little LLM research, here's what I'm thinking that somebody could do:

- Run the above, but expose the socks5 proxy to the internet. This exposes a socks5 proxy which directly forwards the request into Tor.
- But tweak the sock5 proxy so that it requires cashu spilman payments
- Now, given that we need a custom client which sends the payments, which can also encrypt the connection to socks5:

(but maybe that's exactly what epoxy did 😀)

I think I have an idea for preventing the 'block ...

2026-01-22T20:04:04Z

I think I have an idea for preventing the 'block withholding' attack in Bitcoin, where an individual finds a 'mining share' that is actually a block and they withhold it from the pool operator. The basic idea is to make it such that the individual miner doesn't know if the share is a 'full block'; only the pool operator is able to know. I believe this can be done as a soft fork.

The idea is: when a share is found, the operator of the pool - as the only person that knows the secret key for the coinbase output - will sign the (witness) merkle root. A block will be consensus valid only if the first 3 bytes of the signature are all zeroes, 0x000000.... This means that only 1 in each 16 million shares will actually be a full block

The signature scheme needs to be deterministic,. i.e. for a given message (merkle root) and private key (the coinbase key), there must be only one signature. That means we can't use Schnorr signatures, but apparently BLS signatures work

Upgraded nodes would need to pass this extra signature along with the blocks when they are talking to each other, but skip it when talking to non-upgraded nodes. Miners would need to upgrade, as they need to produce this extra signature

Non-upgraded non-mining nodes would continue to operate as usual, i.e. it's a soft fork. The only thing they would notice is a massive decrease in the conventional measure of difficulty.

This might be relevant for hashpool, vnprc (npub16vz…mhgd) , I've been thinking that block withholding becomes too easy if large hashers don't need to defend a reputation of being able to find blocks

Next step in the Cashu Spilman channel system is to redesign the ...

2026-01-19T17:11:24Z

Next step in the Cashu Spilman channel system is to redesign the backend to make it easier to plug in any storage system that you like, e.g. sqlite, nostr, in-memory.

I want to wrap up the functionality into easy-to-use high level functions, such as 'validate_payment', in order to make it very easy for service providers to start accepting payments via these Cashu channels. Some of those functions will need efficient ways to reach out to state management systems, but I don't want to hardcode one particular system into this library.

The core code will stay in Rust for now, as that can be easily exposed (e.g. via WASM) to other languages. And I'll probably write these "bridges" for TypeScript [for continued use within the Cashutube blossom-server] and Python.

So here's an LLM description of what I'll likely work on this evening, although I expect I'll want to convince the LLM to change some of the details of this plan before executing:

== LLM description: ==

quoting
nevent1q…54qy
I've made this streaming video system where the backend is a blossom server. I have a script which splits the video up into "segments" (I'm using HLS for adaptive bandwidth) to allow easy-ish uploads of video

It requires cashu payments, but in reality this is free as I'm using a test mint which gives tokens for free. So this is easy to use now. Feedback appreciated!

And I'll read the link you sent

https://cashutube.satsandsports.cash/

Streaming video, paid via Cashu micropayments Like Lightning, ...

2025-12-14T22:11:31Z

Streaming video, paid via Cashu micropayments

Like Lightning, many payments can be made per second. Tiny payments - e.g. 1sat per kilobyte - can be made and verified just between the video player and video server, only contacting the Cashu mint when closing the channel

The client-side logic could be put into a browser extension or any Nostr client, allowing the user a single system to manage (micro-)payment channels to Nostr relays and Blossom media servers and (TollGate (npub1zzt…ljrv) ) Wifi routers

I'll post a lot more about all this in coming weeks

The Rust code is exposed via WASM to the browser-based video player, and also to the Python server via PyO3, which should help the server to verify very high volumes of payments

This video system uses HLS, which is smart about bandwidth management and I think it's compatible with Blossom, so I hope that makes it easy to integrate this system - with payments of course - into Blossom

Current draft protocol, very much subject to change: https://github.com/cashubtc/nuts/pull/296/files

I've started lurking on X in recent weeks, to see what the ...

2025-10-12T08:01:27Z

I've started lurking on X in recent weeks, to see what the main Bitcoiners are saying, after a few years of totally ignoring X. Such low quality in the replies

I'm using this a lot:

In this message, I'm not going to try to continue the debate ...

2025-08-20T09:03:12Z

In reply to nevent1q…wv54
_________________________

In this message, I'm not going to try to continue the debate (directly). I just want to say a few high level things that might help. I'm still curious and I want to be able to have an open conversation with anyone, including you, in the future

I'm quite open minded about all of this still, and I haven't ruled anything out. Maybe I'll be Knots's biggest fan in a few weeks. On the other hand, I'm not even sure yet what my ultimate goals are (what is spam? do we want to suppress it? what's the most effective way to suppress it? how does this interact with other important issues such as miner centralisation?)

I had ignored Bitcoin for a few years, and I only got heavily into Bitcoin news again about six weeks ago. So I have had a lot of catching up to do. I've been on vacation for those six weeks, so I had a lot of time to catch up on many articles and podcasts

I finished watching the rest of that Bitcoin Mechanic video. None of the arguments he presented were new to me. Every point he made, even the smallest ones, were points I had heard in recent weeks. I'm not saying they are bad points, I'm just saying that I've already done my homework. I might be wrong in the big picture, but I have been doing my homework on these topics 😃

I look forward to continuing to learn more, from you and others, about the actual goals and incentives and game theory

anyway, Bitcoin Mechanic completely agrees with me 😃 and ...

2025-08-19T21:12:02Z

In reply to nevent1q…g0l9
_________________________

anyway, Bitcoin Mechanic completely agrees with me 😃 and therefore I don't need to watch any more of that video.

From 9m08s to 9m42s he says exactly my point: that the only way to discourage large OP_RETURNs is to punish miners who mine them, and that the only way to punish them is to delay propagation of those blocks.

My suggestion to the small-op_return folks is to put that idea on steroids: refuse to propagate any block with large op_returns, and "hide" that block within the node. That block is only "released" when a small-op_return block is mined on top of it later.

This is the obvious way to maximize the propagation-punishment while staying within consensus. That punishment is the main weapon available, and therefore it should be utilised to the maximum by those who feel strongly.

(As I mentioned elsewhere, I'm not sure I'm strongly against large op_returns; I'm just trying to help think through the options)

Bitcoin Mechanic is talking in bad faith. At 7:40 he says: ...

2025-08-19T20:54:31Z

In reply to nevent1q…fvfs
_________________________

Bitcoin Mechanic is talking in bad faith. At 7:40 he says:

"it's obvious that (people skeptical of the current Knots approach) ... betray an agenda to make Bitcoin more conducive to spammers"

He can't expect to be taken seriously when sharing videos like that, where every opponent "obviously" has a "pro-spam agenda"

(I haven't finished his video yet, but I'm finishing it now)

Some people who advocate for large OP_RETURN limits might be naïve. They might be brainwashed. They might be idiots. But if he says they ALL of them have an evil agenda, then he's not credible

I want a calm, non-paranoid, discussion based on expert understanding of the goals and the trade offs and the game theory

I'm watching the Bitcoin Mechanic video now. I think I'll ...

2025-08-19T20:32:38Z

In reply to nevent1q…7tks
_________________________

I'm watching the Bitcoin Mechanic video now. I think I'll have a few comments to share when I'm finished watching it. It's a bit frustrating because I feel both sides (ignoring those individuals who are acting in bad faith) are closer to each other than they realise

I don't watch the Bitcoin University channel any more. I've watched many of his videos on multiple topics. He rambles emotionally and doesn't appear to really understand the technical details and the game theory

The more I think about this, the more convinced I am by my idea ...

2025-08-19T19:21:09Z

In reply to nevent1q…qxxa
_________________________

The more I think about this, the more convinced I am by my idea to delay propagation 😃. #Knots #Spam

Trying to censor these transactions in the mempool will just delay them a little and will transfer money to the permissive miners. Basically, not much good and a bit harmful.

If the goal really is to minimize large op_returns, I want to see a credible proposal that will *incentivize* miners to keep those transactions out of the block. We can't *realistically* stop the permissive miners from seeing these transactions, so instead we can encourage them to keep then out of the block (via delaying propagation of their block)

If my proposal isn't good, then I'd like to see a better one. But I don't think the current Knots approach is a serious approach

(And also, I'm not even sure that op_return limits, even if everybody enforced them, are really the right approach. I'm more concerned about the size of the UTXO set

Do you have a point?

2025-08-19T16:46:32Z

In reply to nevent1q…v9te
_________________________

Do you have a point?

By that logic, Knots is pointless. (For simplicity, I'm just ...

2025-08-19T14:41:44Z

In reply to nevent1q…d46c
_________________________

By that logic, Knots is pointless.

(For simplicity, I'm just talking about op_return here. I accept that Knots has other features too, but I'll ignore them for now)

The consensus rules aren't going to change, and miners will include large op_returns.

In fact, the only people that gain from (attempted) censorship is the big miners, as they get more fees via their 'dark mempool' approaches . That's why I suspect that some of the support for Knots is coming from spammy miners.

Anyway, good point about Foundry's advantages now

[As I said, I have no objection to large op_returns, I just find this topic very interesting to think about in terms of the game theory]

What percentage of (important) nodes do you think is sufficient ...

2025-08-19T13:47:40Z

In reply to nevent1q…v49f
_________________________

What percentage of (important) nodes do you think is sufficient for Knots to win?

51% clearly isn't enough, as a small number of 'permissive' nodes is sufficient to route the spam around the Knots nodes

If the Knots community is serious about discouraging large ...

2025-08-19T13:44:17Z

In reply to nevent1q…l2ng
_________________________

If the Knots community is serious about discouraging large op_retums ('lops'), their nodes should implement what I call a "treacle-fork". It's not a hard-fork, but it puts maximum pressure on miners who include these 'lops' to encourage them to stop mining lops.

When a Knots node sees a mined block that includes any lops, the node should NOT (immediately) forward the block to other nodes. It should pretend that it didn't see the block.

I know you might think this will cause a hard fork and split the chain. However, to avoid a hard fork, I would allow that whenever a 'lop-free' block is found, Knots will accept and forward that block *and it will also (retrospectively) accept+propagate all the ancestor blocks*, even if those ancestor blocks contain lops.

With this system, Knots still follows the existing consensus rules, but miners will see a propagation delay if they mine lops. Miners who include only small op_returns will see their blocks propagate more quickly and therefore will be rewarding by winning the race more often.

Miners who include lops will see their confirmations stuck temporarily, as if they are stuck in treacle.

As a contingency to avoid falling too far behind, if there are three consecutive blocks containing lops, perhaps Knots could just give up

I should close by saying that I'm not personally strongly against large op_returns, I just find it interesting to think about the best way for nodes to apply pressure against transactions they don't like. It's a fun mental exercise!