<unnamed>

Public Key

npub10lrzse62vddqwsscqcmjurmhtxh545zf6q7ez9q25ddlc7p7saeqems9ug

Profile Code

nprofile1qqs8l33gva9xxks8ggvqvdewpam4nt626pyaq0v3zs92xklu0qlgwuspz4mhxue69uhhyetvv9ujumt0wd68ytnsw43qz9rhwden5te0wfjkccte9ejxzmt4wvhxjmcf9qxyh

Publishing to

relay.mostr.pub

relay.damus.io

Last Notes

2026-02-21 09:54:19 UTC

- reply

Core Devs made a massive controversial change to the default node behavior. Sure, it wasn’t a consensus change, but we should tighten consensus rules on Bitcoin to mitigate the problem of non-financial use-cases. If we had already tightened consensus then the recent Core dev recklessness would not have been possible, and they wouldn’t have felt compelled to do it because the Citrea use-cases would have already been forced to not spam the blockchain due to consensus rules. It’s time to re-affirm that Bitcoin is money not arbitrary data storage. Consensus changes are the way to do this correctly.

2026-02-12 10:20:42 UTC

- reply

For those reading the thread (because you obviously already understand this - and that’s why you keep pushing it), 1 BTC for you is far less of a commitment than 1 BTC for many other people.
That’s if the bet makes sense. I’m not sure this bet even makes sense.
I think the issue people are raising is that spam is bad and that we should discourage spam. Your response should also be that spam is bad - but you refuse to say that, so people reasonably conclude that you have a financial interest in spamming the Bitcoin blockchain.
We can define spam as non-monetary use of Bitcoin - then legitimately argue about how to identify that via dust outputs etc…
We should also agree that fighting spam is not really hard (it’s tedious, but not difficult from a technical perspective. Knots has some very simple spam filters Core could adopt - that would need to be periodically updated as spammers change tactics).

2026-02-12 09:50:14 UTC

- reply

Who was claiming that “Bitcoin Core v30 was going to result in a massive node crash / network outage”? It seems like you offered a bet that nobody would reasonably take and now claim it means people were wrong about something vaguely related.
Instead, can you please explain the rationale for the Core v30 changes to OP_RETURN and why they are beneficial for Bitcoin as money? I still have not heard a single rational explanation for that change.

2026-02-12 09:42:02 UTC

- reply

We should not be arguing about this. Spammers say you can’t define “spam”. It’s not that difficult- if you need to attach large amounts of arbitrary data, or hide it in massive amounts of unspendable “dust” outputs, then it’s not a financial transaction, and belongs somewhere else that’s not on the bitcoin blockchain. I agree there’s a bit of a slippery slope here - like how side-chains anchor on the base layer blockchain, and we should periodically reconsider how much arbitrary data is needed for financially adjacent use-cases.

2026-02-12 09:22:04 UTC

- reply

Weird - this seems like we agree on spam being bad, but in the other thread you are advocating “permissionlessness” (I.e. spamming). What am I misunderstanding?

2026-02-12 09:11:05 UTC

- reply

If miners including it is sufficient for it being ok, that’s ignoring the centralization impact of the externalities they impose on nodes. If miners choose to include even more toxic arbitrary data due to the lax Core v30 filters, or massive amounts of non-financial data (even if it’s not toxic) then fewer people will run nodes, and Bitcoin gets more centralized, which increases the risks of (future) censorship.

2026-02-12 08:55:27 UTC

- reply

I think this libertarian view of “permissionless” (without any boundaries whatsoever) is a risk for bitcoin. Yes, the protocol allows it, but that doesn’t make it good for bitcoin, and until Core v30, default node policy discouraged it. We should agree that bitcoin needs to focus on being money and leave the other use-cases to other protocols/platforms. I’m not a fan of BIP-110, but Core really dropped the ball on spam and that’s not good for bitcoin. Are you running a Core v30 node?

2026-02-12 08:37:02 UTC

- reply

Please do the work to understand this issue. If you believe that bitcoin is money, then large amounts of arbitrary data storage is not acceptable because it weakens bitcoin as money (because nodes incur the cost of storing the data while miners extract the value of mining it). Saying that all financial transactions are ok, and that attaching large amounts of non-financial data is not ok, is not *censorship* - it’s common sense. Try depositing a check at your bank and attaching a poster size photo and requiring your bank to archive that photo and make it available to everyone forever - no matter what the photo is of. That’s not a monetary use-case, and has no place in the bitcoin ecosystem.

2025-12-19 03:32:27 UTC

- reply

They took their time - low time preference was their super power. For example, it took 70 years to carve this chapel in an underground salt mine in Poland: https://www.visitwieliczkasaltmine.com/st-kingas-chapel

2025-12-19 03:20:50 UTC

- reply

Wow - would not have guessed that!

2025-12-17 18:33:44 UTC

- reply

Wow! Just confirmed that myself on Google. DuckDuckGo still returns it as the first result.

2025-12-16 05:44:53 UTC

- reply

https://forbestadvice.com/Religion_Spirituality/Images/Jesus_Dionysus_Krishna_Mithra_Horus.jpg

2025-11-26 04:45:27 UTC

- reply

I think I’ve had most success getting people to download a really simple lightning wallet like “Muun” (happy to hear about any recommendations for simpler newbie lightning wallets because Muun has it’s limitations) then send some sats into the wallet over lightning so they see how fast and easy a Bitcoin transaction is for even small amounts of money. They also like getting money for free - so that helps.

2025-11-26 04:30:45 UTC

- reply

I send my family/friends to Strike because the app is easy to use, DCA has no fees, and auto-withdrawal to cold storage also has no fees (when they’re ready to learn about cold storage). Haven’t tried River so can’t compare them, but heard good things about River. For less technical people, who are scared of real Bitcoin, I explain how they can buy FBTC in their Fidelity account if they want exposure to Bitcoin without needing to learn anything new.

2025-11-22 20:10:19 UTC

- reply

Keep up the good work informing people about Knots and BIP 444. You should also meet more Bitcoin Core devs. The ones I’ve met are good people and not enemies of Bitcoin. They just have views about spam that I happen to disagree with.

2025-11-22 18:39:20 UTC

- reply

Nobody can accurately predict Bitcoin cycle tops, so don’t fall into the trap of thinking you did. We don’t really know if this cycle is over yet or if four year cycles are even still a thing.

2025-10-18 00:00:32 UTC

- reply

Duuuuudddeee - learn about this issue. Core v30 opens the floodgates for VC backed startups to store huge amounts of arbitrary data on the Bitcoin blockchain. That’s not what Bitcoin is about. Bitcoin is money - not storage. Knots doesn’t magically fix the spam problem, but they are working on it rather than enabling it.
Do the work to read the Core developer mailing list and GitHub threads. Core rejected this change twice in the past two years because it’s bad for Bitcoin and therefore controversial. In v30 they pushed through unlimited data storage despite there still being a lot of disagreement - AND they are still unable to make a coherent argument for why we need to change this default that’s been working fine since 2014.
https://blossom.primal.net/396ef88d39e55c9a6258e74e2627bd90ee4af8a9d1f92a77671437fd56e5259b.png

2025-10-11 02:39:15 UTC

- reply

That’s interesting - I hadn’t seen that.

2025-10-10 06:29:20 UTC

- reply

There’s a big difference between “expanding its capacity” to say 160 bytes and removing the limit entirely as Core v30 does. I think there would be much less concern if this was an increase to 160 bytes to support some vaguely plausible use-case.

2025-10-10 06:04:51 UTC

- reply

“Spam will continue until consensus changes.” - I completely agree with you.
That doesn’t mean we shouldn’t run nodes to filter it. And yes, I also know spam flows around nodes that filter it.
I see Knots as a signal to the network that Bitcoin is money, and spam is worth fighting. If enough people run Knots, then Core devs and eventually maybe even miners will decide to join the fight against spam. Blocks that mined spam will be relayed slower by filtering nodes than blocks that didn’t mine spam because compact block propagation requires the previously filtered transactions to be re-downloaded by a node to validate the block and this propagation delay provides a small economic incentive for miners.
In a - probably unrealistically ideal - world, a few years from now we might have enough support for some consensus changes to eradicate the main hacks for embedding non-financial data. We’ll only get there if we at least try to combat spam between now and then.

2025-10-10 05:36:15 UTC

- reply

@walker - you owe it to your audience to become better educated about the significant and unnecessary risks that Core v30 poses for Bitcoin and stop trolling the Knots people for fun. Core v30 is indeed a serious risk.
This current debate motivated me to do the work of attending Bitcoin Core developer meetups to understand their personalities and perspectives, read the source code to understand the specific differences between Core policy and Knots policy, read the discussion threads of Core developers to see how they reached this decision, read the “Bitcoin Development Philosophy” book Chaincode Labs funded, and learn the history of the conflicts between Luke and current Core developers/maintainers.
I don’t align with many of Luke’s opinions, but his approach to filtering out non-financial data is valid. Core’s arguments are hand-wavy at best and their “intentions” are secondary to the consequences. For example, v30 opens the floodgates for a new wave of spam from VC-backed startups that will now have “approved” ways to store the large amounts of arbitrary data they want to store (and VCs don’t like the risk that using hacks to embed data could result in their business model being broken by a future release of Core, they don’t want to fund a layer 2 network for their data, and they don’t like the centralization risks and increased costs of needing to collude with miners to bypass node filters). Indeed, the threat of Citrea spamming the network with large amounts data that can never be pruned and permanently damaging efficiency is one of the things motivating the misguided changes in v30. Knots is “proof by existence” that Core could indeed filter at least some of the non-financial data, but they instead chose to reject Luke’s PR because filtering spam doesn’t align with their philosophy of trying to get the whole network of mempools to more accurately reflect exactly what miners choose to mine - including spam. There is technical nuance to their reasoning for this philosophy that makes sense, but it’s misguided when examined in the broader context of the entire Bitcoin network as a complex system of interdependent components. “Systems Thinking” as Saylor likes to call it. Existing spammers are unlikely to start using OP_RETURN to embed their data because they get a 75% Segwit discount by continuing to embed it via the hacks they currently use.
Nick Szabo (unusual background as an OG cryptographer who also attended law school) makes plenty of reasonable points about the legal risks v30 causes for Bitcoin - so I won’t repeat them here.
In a nutshell, v30 doesn’t mitigate existing spam, opens the floodgates to new spammers, increases the legal risks and operational costs for node runners, and increases reputational risks for the whole Bitcoin ecosystem. But on the upside, nodes should validate newly mined blocks a fraction of a second faster and estimate fees a little better. Things the vast majority of Bitcoiners don’t care about.
If you do the work to go down this rabbit-hole, then you too will be concerned about Core v30, and how it could be placing your future financial security in jeopardy (alongside everyone else who relies heavily on Bitcoin).
Every single node operator should run Knots to signal their view that Bitcoin is money and spam is worth fighting. And continue running Knots until the Core dev team joins the fight against non-financial data spam instead of legitimizing it and making spamming even easier.

2025-10-09 04:24:53 UTC

- reply

It’s good that you’re not upgrading yet. Take the time to think through the impact of opening the doors for a new wave of non-financial spam from VC-backed startups that want to use an “officially approved” way to store their data in the blockchain (because a one-time mining fee for permanent storage forever on full-nodes is cheaper than funding their own layer 2 network). The existing hacks spammers use get a 75% Segwit discount compared to using OP_RETURN, so those spammers aren’t going to do extra work so they can pay more. We need to filter what they’re already doing - that’s the battle Knots has taken on and Core has refused to attempt because they are philosophically aligned with miners - “any consensus valid transaction a miner could mine should be relayed and stored by all nodes”.
Long-term, we need a third option that takes the latest Core version and patches in reasonable default filters (that node operators can turn on/off themselves), with no personality-related drama like we currently see between Core and Knots.
Short-term we need to run Knots (which at the moment is essentially Core plus tighter spam filters) to signal to the network that we want Core developers to fight spam instead of worrying about how to enable their buddies at VC-backed startups to spam the network in “approved” ways.

2025-10-06 02:49:03 UTC

- reply

When was that?

2025-10-05 15:44:03 UTC

- reply

- listened in disbelief to Bitcoin Core devs explain v30 change
- read code in policy.cpp in both Core and Knots
- got frustrated that Knots doesn’t make it trivial to review its changes to Core because it includes other stylistic code changes and bug patches that make diff verbose
- did the work anyway to understand the differences
- concluded that the extra policy code in Knots is reasonable
- now running Knots 29.1

2025-10-02 04:56:40 UTC

- reply

I agree that we should listen to people who want to build, and even make conservative changes to accommodate them. Core could start to filter inscriptions by default and engage in the whack-a-mole task of continuing to add filters that prevent and discourage arbitrary data outside OP_RETURN, then simultaneously increase the data carrier size limit so OP_RETURN can carry a little more data - e.g. for some reason Citrea apparently needs 144 bytes, so we could set a new limit a little larger than that. I think Adam Back threw around 160 bytes as a compromise number to resolve the v30 drama. That sounds reasonable to me as long as we also stomp out data embedding everywhere else.

2025-10-02 04:37:40 UTC

- reply

What am I missing in that thread?
Reasonable financial transactions are not as large as this extreme example, so if the node filters out and doesn’t relay excessively large (non-financial) transactions based on size and doesn’t waste any CPU trying to understand what is in those transactions, the DoS problem doesn’t exist, and occasionally the node estimates fees and what will be mined in upcoming blocks poorly because a miner received and mined a giant transaction out of band. I’m obviously not understanding what the concern is and would like to understand it.

2025-10-01 22:00:38 UTC

- reply

Good decision. I decided to diff the policy.cpp code of Core and Knots to understand the key differences - I can recommend that. The code is not difficult to read.

2025-10-01 20:32:59 UTC

- reply

Some types of centralization are good. Would you like people to throw garbage all over the street (including your front lawn - where you need to deal with it) or use “centralized” garbage cans?

2025-10-01 20:16:13 UTC

- reply

That’s kind of like asking big tobacco’s lawyers if smoking is bad for your health. It’s telling that some of them did acknowledge that v30 may increase legal & political risks.

2025-10-01 20:01:08 UTC

- reply

Knots for now.
Unfortunately Core v29 chooses not to filter inscriptions or that would have been my choice.
Would like to see Core adopt the same filters of non-financial data that Knots already has, and make them defaults in v31 so we can all move on from this drama.
If Core doubles-down on the blockchain being for arbitrary data storage in v31, then they’re shitcoiners not bitcoiners and we will need to create a new reference version.

2025-10-01 14:09:03 UTC

- reply

I do think we may need some more experienced devs to take the time to maintain the codebase. Most of the Core devs I met were relatively young. I hope they get a lot of mentoring from the Bitcoin Core OG developers. There’s also a risk that their friends who work at startups that want to embed data in the blockchain are directly or indirectly influencing the perspective of Core devs. I worry there might be a revolving door problem like we see in other industries that could result in Core devs making decisions that benefit startups they then go to work for, or previously worked for. This current OP_RETURN decision by Core seems like it benefits startups and miners and disadvantages node operators by increasing the storage/compute/legal burden on nodes.
Here’s my straw-man. VC investors don’t like the risk that a startup’s hacky way of storing data in the blockchain might at some point get filtered by so many nodes that the startup is forced to pay extra to miners like Marathon to embed the data in the blockchain because the miners could choose to extract a lot of value from the startups. Getting Core to standardize on removing the OP_RETURN limit so it becomes normal and accepted to embed arbitrary amounts of data without needing to pay additional miner fees for something like slipstream is good for startups. Having implementations like Knots that could add a new filter to prevent the startup’s approach to storing data is a risk to the profitability of those startups.
I believe that Bitcoin is money, and if a startup wants to store large amounts of data, then they should fund their own L2 network (like the lightning network where lightning node operators share in the fees) and just use the Bitcoin L1 network via very compact amounts of data (i.e. crypto signatures or hashes of data) that’s sufficient for them to leverage the proof-of-work security of the Bitcoin network. The current startups that want to embed their arbitrary data in Bitcoin are exploiting nodes for permanent data storage where they only need to pay a one-time (currently very cheap - but it won’t always be cheap) mining fee. I see this as an abuse of the nodes.
What are your thoughts on this? Am I overreacting to the current drama?

2025-10-01 04:30:07 UTC

- reply

Had a similar experience talking with Bitcoin Core devs over drinks a couple of weeks ago. Great bunch of smart talented people, but their religious belief in fees being the ultimate spam filter is where we disagree.
There is some data that everyone should work hard to filter out because of the legal/ethical/moral risk that data poses for the Bitcoin ecosystem.
Knots attempts to filter out the non-financial data that Core refused to filter, and gives node runners options about what to filter. I’m upgrading to Knots so it will signal my disapproval of Core v30 to the network, and I will never run Core v30.
You should look at the Peter McCormack interview with Gloria Zhao to understand Gloria’s misguided perspective that Core should not try to filter anything that passes consensus rules - and that cat and wizard JPEGs are fine as long as they pay fees and are in a consensus-valid transaction. IIRC it was Gloria who rejected Luke’s PR to filter inscriptions when they started.
The OG Bitcoin view is that Bitcoin is money and anything else is an attack on Bitcoin. Embedding large amounts of arbitrary data is absolutely an attack worth defending against, but Core has refused to defend against it over the past few years and with v30 is throwing in the towel and making it even easier to embed large amounts of arbitrary data.

2025-10-01 01:01:56 UTC

- reply

Almost - I thought that too. Then I looked at the Knots and Core transaction filter code on GitHub. Knots filters out runes, inscriptions, and some other spam that Core refuses to filter. I wasn’t pro-Knots before this drama inspired me to actually look at the code. Core could easily have accepted Luke’s PR to filter this non-monetary garbage but philosophically they don’t believe that Bitcoin should only be money - as you saw in that video with one of the Core maintainers talking about cat videos and wizard JPEGs being fine in the blockchain.

2025-09-30 22:17:33 UTC

- reply

Run the node that aligns best with your personal values, and be fully aware of what you are choosing.
TLDR; the core issue behind the Knots vs. Core v30 debate, excluding the personal attacks, can be summarized as Knots = “Bitcoin is only money” whereas Core v30 = “The Bitcoin blockchain is free data storage, and Bitcoin is also money”.
The main consideration is whether you want your node to relay only financial transactions or also arbitrary data that will be recorded on the blockchain. Knots focuses on relaying financial transactions, filtering out as much spam as reasonably possible - but it cannot block all spam. In contrast, the new Core v30 will relay the existing spam currently encountered by the network (like older Core versions already relay) and introduces a new way for spammers - such as VC-funded startups - to exploit nodes for free data storage without paying additional miner fees to bypass node filters.
Relaying and storing arbitrary data also increases legal risks for node operators compared to channeling that data through the large miners’ choke-points (e.g. via slipstream). Those large mining companies can be held accountable for the arbitrary data they choose to include in the blockchain that nodes refused to relay, creating an incentive for them to avoid mining the most awful content.

2025-09-29 02:16:26 UTC

- reply

Hi Daniel - this v30 drama would be a great topic to cover (again) at PubKey now that it’s heating up more. It would be great to see something like a moderated debate between Kratter & Antoine. Or better yet, Luke or Mechanic vs. Antoine.