<unnamed>

Public Key

npub1art8cs66ffvnqns5zs5qa9fwlctmusj5lj38j94lv0ulw0j54wjqhpm0w5

Profile Code

nprofile1qqsw34nugddy5kfsfc2pg2qwj5h0u9a7gf20egnez6lk870h8e22hfqpp4mhxue69uhkummn9ekx7mqppamhxue69uhkztnwdaejumr0dsq3gamnwvaz7tmjv4kxz7fwv3sk6atn9e5k7qgcwaehxw309ajhxur9d35x7tn8d9exjmn09ehhyecppamhxue69uhkummnw3ezumt0d5q3samnwvaz7tmjv4kxz7fwwdhx7un59eek7cmfv9kqqv3art

Publishing to

Last Notes

2026-02-27 19:18:45 CET

https://knotslies.com/

2026-02-25 07:16:53 CET

- reply

Bitcoin Core developers have explicitly said users are free to run different software: https://bitcoincore.org/en/2025/06/06/relay-statement/
What people like myself are sick of are the lies and deceptive rhetoric around all of this, and the toxic environment it creates.
https://image.nostr.build/8efdfa24cd99d27503dcc1f4b90d64cf9e15a6d01c8c0ab64ae6efddd155ede1.jpg

2026-02-24 21:01:36 CET

- reply

You didn't address @nprofile…tqyx's point-- instead you just got triggered by the word "censoring".

2026-02-24 14:48:47 CET

- reply

Keep digging that hole buddy you're doing great.

2026-02-21 16:39:03 CET

- reply

Judging by all this recent drama — which they indeed rightfully ignored in favour of sound technical engineering -- it would probably be many of the current Core devs.

2026-02-21 11:31:17 CET

- reply

The day Bitcoin Core developers bend to the pressure of a misguided Twitter mob riled up by populist social media influencers, instead of merging code based on their best technical judgement, is the day the codebase should be forked to re-establish sound engineering practices.

2026-02-20 21:14:05 CET

- reply

Liar.

2026-02-20 15:53:35 CET

- reply

>I don't know of a good way to estimate that.
Fork futures.

2026-02-20 10:36:23 CET

- reply

Core 30

2026-02-19 09:38:47 CET

Luke-jr moving through the Bitcoin space.
https://image.nostr.build/5979694561f31f2f302384b34752c998875e531f8e3eb6c65f170f3067d79989.jpg

2026-02-17 18:34:42 CET

- reply

I doubt it would represent a significant loss, and in fact I suspect that adopting BIP110 would harm the value of bitcoin more than losing these people would. But without fork futures markets --which I'm very much in favour of!-- it's anyone's guess unless and until there actually is a split.
(That's another argument for a URSF btw, it would enable a very well defined fork futures market.)

2026-02-17 18:22:11 CET

- reply

Last I checked BIP110 will have a mandatory signaling window in August, so if miners don’t signal, BIP110 nodes will in fact fork themselves off the network.
Your scenario could still happen if miners do signal (which non-BIP110 won’t care about one way or the other). That’s why IMO it’s still good to pay attention to signaling, and if there is any it’s probably time to start considering a URSF.
The worst case scenario is if miners don’t signal until very shortly before the mandatory signaling period starts. (Or even when it’s already started.) In that case I suppose the rejectblock command can still offer a solution, but it’d be a bit of a last-minute scramble…

2026-02-17 18:00:26 CET

- reply

No miners are currently signaling support for BIP110, so investing time and effort in developing a URSF client seems like a waste of time and effort at this time (to me, anyways).
Much easier to just use the rejectblock command post-fork if a BIP110 block that forks the chain is ever mined.

2026-02-17 16:22:21 CET

- reply

Devs can't do that.
They can only release free and open source software that users can then voluntarily decide to run-- or not.

2026-02-17 14:33:36 CET

- reply

Yes most OG Bitcoiners are against arbitrary data storage on Bitcoin. That’s why we fought to keep blocks small. F(r)ee market economics should do the rest in an open, permissionless and censorship resistant system.

2026-02-17 07:44:39 CET

- reply

Name one prominent small blocker from the block size war era besides Luke who's now in favour of BIP110?

2026-02-13 09:43:25 CET

- reply

Not unless you mean it in a “voting with your feet” kind of way.
Everyone can just use whatever software they want. Including software that is incompatible with the Bitcoin protocol.

2026-02-12 20:53:35 CET

- reply

Rather, it splinters it.

2026-02-12 11:19:49 CET

- reply

Question for the taco plebs: which dev team is more centralized, Bitcoin Core or Bitcoin Knots?
#nevent1q…tj9e

2026-02-12 10:06:11 CET

- reply

Thanks :) Not sure what’s up with that, it usually works. (Including earlier today…)

2026-02-11 16:36:53 CET

- reply

Absolutely. Somehow I didn’t become magnetic, go figure.

2026-02-11 14:21:10 CET

- reply

#note13wl…4ewj

2026-02-11 14:20:27 CET

As I already alluded to earlier today, unless and until any of these guys are willing to take this offer I really think they’re best ignored.
No need to invite them on your podcast, or hoist them onto your conference stage for yet another debate, or write a BIP110 explainer as if it’s at all serious.
All bark, no bite.
#note1ejs…0gqu

2026-02-11 13:46:49 CET

- reply

Ik zeg ook niet dat experts altijd gelijk hebben.
Maar een daadwerkelijke “independent mind” is in staat de uitzonderingen te vinden — en dat zullen vrijwel per definitie inderdaad uitzonderingen zijn, niet de regel.

2026-02-11 11:25:11 CET

If you always find yourself on the opposite end of expert consensus you don’t have an independent mind— you’re a brainless contrarian.
#note1awr…pvnw

2026-02-11 07:29:31 CET

- reply

Thanks for the reminder :D

2026-02-11 07:15:32 CET

I received a few requests to write an article or record a podcast on BIP110, but frankly I don’t see the point right now.
Until someone is willing to put their money (no one has taken on @npub1emd…c9aw’s fork futures offer) or hash power (not even Ocean is signaling support) where their mouth is, it’s little more than a DOS-attack on our attention and time.

2026-02-08 21:20:29 CET

- reply

I don't think these people are very interested in facts.
Having said that, yeah maybe I'd be up for that at some point. Maybe.

2026-02-08 06:48:32 CET

- reply

Non-upgraded nodes just follow the longest chain, whether that’s the UASF or the URSF/checkpoint chain. They’re both soft forks.
But you can believe what you want to believe.

2026-02-08 05:54:04 CET

- reply

The same is true for BIP110 so by your own logic that would be a hard fork too.
(Of course neither are hard forks; both are soft forks.)

2026-02-07 19:35:05 CET

- reply

I’d been encouraging Bcashers to fork off for probably over a year before they finally did it, because I and many others were tired of hearing their dumb Bitcoin Core/Blockstream conspiracy nonsense. Sounds familiar yet?

2026-02-07 05:24:45 CET

- reply

That we agree on.

2026-02-07 05:08:34 CET

- reply

See, the error in your thinking is that you think "hard fork" means "chain split", and "soft fork" means "no chain split".

2026-02-06 21:34:30 CET

- reply

It's not essentially a hard fork-- it's a soft fork. And it doesn't necessarily have to be done by Core. (Nor do I think their reputation is deteriorated in the eyes of serious people.)

2026-02-06 20:53:21 CET

- reply

Nope. And BIP110 doesn’t stop that.

2026-02-06 20:29:19 CET

- reply

https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8

2026-02-06 20:23:36 CET

- reply

Cool go for it and we’ll see who’s right.

2026-02-06 20:19:50 CET

- reply

Little incentive to invest time and effort in creating a URSF client when there’s ~no support for a UASF in the first place.
Post-fork, in the unlikely scenario that a re-org becomes even a even slightly feasible risk, a simple checkpoint suffices.

2026-02-06 20:12:04 CET

- reply

Yes it is.

2026-02-06 12:40:54 CET

- reply

There probably won’t be a re-org either because BIP110 never gets a majority of hash power, or because a re-org is simply prevented with a URSF/checkpoint/whatever. (Or both.)

2026-02-06 11:59:37 CET

- reply

That’s what the block size limit is for.

2026-02-06 09:27:48 CET

- reply

Done, thanks for pointing out that I can just do that on Nostr as well. (TIL!)

2026-02-06 09:11:20 CET

- reply

Fork off loser.

2026-02-06 07:54:14 CET

The Knots crowd has become toxic enough that I do in fact hope they fork off. I’ll happily sell my BIP110 coins back to them—assuming there will be enough blocks on this chain for these transactions to confirm—and they can go their Bcash way.

2025-11-12 09:22:19 CET

- reply

The Genesis Book is also for sale in bitcoin: https://store.bitcoinmagazine.com/products/the-genesis-book?srsltid=AfmBOopMQMCWMFx99bhUwvY6c_Hn-0FKbx7Lb8gISEJzuhJpjklvri_R

2025-11-12 09:19:56 CET

- reply

Yes, my labour.
I've been getting paid almost exclusively in bitcoin for about a decade now.

2025-11-12 07:01:09 CET

- reply

These are the projects pushing this vision forward.
Not these "anti-spam" LARPers.
#nevent1q…3meu

2025-11-11 12:30:17 CET

- reply

It does. Rules without rulers.

2025-11-09 08:24:20 CET

- reply

Wait a minute…
@npub1lh2…a9nk @npub1lh2…a9nk what gives?
https://x.com/LukeDashjr/status/1986552777913303125
https://image.nostr.build/b45ef982e296a8229831816e0e16c566f8c04cd2153597ee12aa118614ed945d.jpg

2025-11-08 17:33:06 CET

In case anyone is wondering, for BIP444 @npub1lh2…a9nk @npub1lh2…a9nk is willing to throw BIP8 soft fork activation overboard in favour of a flag day activation with no miner signaling.
https://image.nostr.build/57cb51c7702a3429c057c1209caa4bcab3b75edeeb160fb5631aad9e6e2461fd.jpg
https://image.nostr.build/f0c862ba598763af6982ad21e61a6129222ef99de027dc1008c3932bbb98fb15.png

2025-11-07 19:42:15 CET

- reply

no u

2025-11-07 10:23:44 CET

- reply

This is a troll who's been posting that screenshot all over the place like it's some kind of gotcha.
It was part of a good back-and-forth I had with @nprofile…e6sl (IMO), you can read that back here if you're interested:
#nevent1q…56cq
#nevent1q…56cq

2025-11-07 05:55:36 CET

- reply

I said several times, explicitly, if an owner/admin/mod wants me to stop talking and asking questions, they can just ask me to stop and I will.
Instead I was banned without any prior warning…

2025-11-07 05:34:40 CET

- reply

How did I not behave like a normal person? (Feel free to share a screenshot of whatever it is you think warranted a ban.)

2025-11-06 20:14:58 CET

- reply

I'm also banned.
@nprofile…vw43 @nprofile…566r care to explain why? Despite disagreements I don't believe I was rude or trollish or anything of that nature.
#nevent1q…jj48

2025-11-06 18:41:31 CET

So @npub1lh2…a9nk @npub1lh2…a9nk wants to roll back the chain and activate a soft fork if CSAM is included in an OP_RETURN.
However he does not want to tell anyone how we’d even know it if that were to be the case…
https://image.nostr.build/3a4a0598d908f460ef6e236d746f45b6140c5b0a708077e2fecb8948de494c81.jpg
https://image.nostr.build/87c875f6321e9185f7463ab4a4ecb9ddbe254fdd8b4ebb0f4d9a9985370bf8d1.jpg

2025-11-06 16:18:05 CET

- reply

Ok I think we’ve probably made it to the end of our argument tree: the “agree to disagree stage”!
I’ll post my responses; feel free to rebut them if you feel like you can and want to— or not. Up to you :)
1. Since both you and me run a node primarily for our own benefit, I think it’s reasonable to extrapolate that to other users as well. Since data in OP_RETURN would not discourage you or me from running a node (versus data in other parts of a transaction) I don’t think increasing the OP_RETURN relay default will have a centralizing effect.
2. I think over time monetary transactions will be outbid by other monetary transactions— spam will barely enter the equation, if at all. (Maybe if it’s very compact, Open Timestamps style, in which case it’s also not a big problem.) Also see: #nevent1q…5vw9

2025-11-06 14:46:56 CET

A new Bitcoin, Explained episode appeared!
On Bitcoin Core 30, the non-drama edition.
With @npub1s6z…wk4c.
https://podcastindex.org/podcast/3307835?episode=44789004081

2025-11-04 14:04:50 CET

- reply

1. I tried to earnestly understand and explore @npub1lh2…a9nk @npub1lh2…a9nk and @npub1yxp…399s’s arguments.
With Luke I just have to say “agree to disagree” when he argues that CSAM is _only_ illegal/immoral when it’s in an OP_RETURN up ‘till 100kb post-September 2025— everything else is “non-CSAM” in his view even if they’re the exact same bytes.
Super Testnet meanwhile seems to have gotten stuck on this question: #nevent1q…jxqn  2. It was never about Citrea specifically; Citrea just showed that there is demand for >80 bytes of data, and if such use cases can’t use OP_RETURN they’ll just use fake pubkeys which NO ONE should want.  3. Not a technical argument. But I’d say if anyone uses nasty triggers it’s Luke et al claiming (and this is a real quote) “Bitcoin Core is trying to force everyone who uses Bitcoin to distribute child porn”— not to mention the shit you’re throwing at the wall here yourself.

2025-10-31 18:58:27 CET

https://youtu.be/Sh-vbNnnwWw

2025-10-30 19:49:29 CET

- reply

I’m not sure how to read this. Is this total resource consumption of a transaction before or after it’s included in a block?

2025-10-30 19:35:12 CET

- reply

Who does that?

2025-10-29 11:41:20 CET

Censorship resistant transactions in the hardest money ever invented will be in high demand, and will out-price other forms of data storage.
If that assumption is wrong, Bitcoin’s design is fundamentally flawed, and those of us who do want electronic cash should go back to the drawing board.
(I don’t believe the assumption is wrong.)