<unnamed>

Public Key

npub10lrzse62vddqwsscqcmjurmhtxh545zf6q7ez9q25ddlc7p7saeqems9ug

Profile Code

nprofile1qqs8l33gva9xxks8ggvqvdewpam4nt626pyaq0v3zs92xklu0qlgwuspzemhxue69uhhyetvv9ujuurjd9kkzmpwdejhgqg5waehxw309aex2mrp0yhxgctdw4eju6t0va9sam

Publishing to

relay.primal.net

relay.damus.io

Last Notes

2026-05-03 05:38:14 CEST

- reply

The reason for the initial small deposit is to ensure that the seed was backed up correctly to the steel plate (not writing down the wrong seed) and also that the restore from that backup was for the correct seed (not a mistake when reading the seed or entering it into the new wallet during the restore). Without that deposit, the on-chain balance for the correct wallet and an incorrectly restored wallet would both be zero. The small unique balance makes it easy to confirm the whole workflow of backing up and restoring worked correctly.
Splitting the metal seed backup across multiple geographic locations is good advice because if one location gets compromised, the attacker only gets part of the seed.
The restore is from the metal backup seed to ensure it’s both readable and correct. Your suggestion about taking a PHOTO of the metal seed backup is CRAZY - most people have phones that sync photos to cloud storage where they could be SUBPOENAED or HACKED and the seed and wallet balance STOLEN. Also - (although unlikely for most people) the phone could already be compromised and steal the seed as soon as that photo is taken.

2026-04-30 04:05:48 CEST

- reply

And needing to provide an email address? Generate a token on receipt of the payment in the browser and let people watch without sacrificing their privacy (or needing to create an anonymous email address).

2026-04-09 03:40:37 CEST

- reply

You probably already know this, but do NOT enter the seed phrase into a website that says it will check it for you.
My approach is to deposit a tiny amount of BTC into a newly created hardware wallet then put the seed phrase on virtually indestructible steel and restore from that steel backup onto a second hardware wallet to ensure I stored the correct seed phrase before I start using the wallet.
AFAIK the only way to test a seed phrase is to restore from it.

2026-02-21 10:54:19 CET

- 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-21 10:16:53 CET

- reply

@nprofile…2uzc

2026-02-21 10:16:25 CET

- reply

@ODELL - this sounds like something opensats should fund as an alternative to both Core and Knots.

2026-02-21 10:05:06 CET

- reply

Agreed - Core definitely overstepped with that massive controversial reckless loosening. As a long-term software engineer and manager of software engineering teams, I would have fired them all for that lack of understanding of the unintended consequences and deliberate side-stepping of controls by loosening so much because they don’t want to go back to the community for future loosening. What in your opinion is the “fix” because what I’ve heard from you so far is to run Core v29 and not upgrade, but that’s not really a “fix” to the problem that a very very small number of Core developers made a massive unnecessary high risk change to the default node implementation that a lot of people brainlessly upgrade to. Having lots of nodes switch to Knots is not ideal either because that’s a different concentration risk. Is OpenSats actively funding some other (non-Core) implementations to mitigate this obvious risk to Bitcoin?

2026-02-17 12:19:07 CET

- reply

I’m going to assume you’re trolling. Most spammers don’t use OP_RETURN because they get a 75% discount if they embed their spam using SegWit. OP_RETURN is about VC-backed spammers who want to “comply” with the “mainstream BTC standards” so their investors don’t get spooked. E.g. Citrea that is VC-backed by Lopp.

2026-02-12 11:20:42 CET

- 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 10:50:14 CET

- 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 10:42:02 CET

- 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 10:22:04 CET

- 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 10:11:05 CET

- 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 09:55:27 CET

- 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 09:37:02 CET

- 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 04:32:27 CET

- 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 04:20:50 CET

- reply

Wow - would not have guessed that!

2025-12-17 19:33:44 CET

- reply

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

2025-12-16 06:44:53 CET

- reply

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

2025-11-22 19:39:20 CET

- 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 02:00:32 CEST

- 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 04:39:15 CEST

- reply

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

2025-10-10 08:29:20 CEST

- 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 08:04:51 CEST

- 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-09 06:24:53 CEST

- 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-05 17:44:03 CEST

- 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 06:56:40 CEST

- 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 06:37:40 CEST

- 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-02 00:00:38 CEST

- 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 22:32:59 CEST

- 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 22:16:13 CEST

- 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 22:01:08 CEST

- 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 03:01:56 CEST

- 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-10-01 00:17:33 CEST

- 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 04:16:26 CEST

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