This is fuckin hilarious. 🤣

@jb55 this is for you.

😂😂🤣

... but also a masterful work, piece of art!

lmfao, not a fan of filters but this is well made super

Fucking epic! View quoted note →

thanks! To be clear, it's only a joke, not to be taken as serious criticism of anyone or any position

Relevant:

@npub1luz2...ee93 you need to see this

... It's Bailey though, right? It's gotta be Bailey.

It's an amalgam of opinions I've heard from several people, among whom, in alphabetical order, are: - Antoine Poinsot (he says filter fans are morons and larpers) - Calle (he says Knots only has one developer, and ridicules filters) - Hunter Beast (he says it's good to use bitcoin as a text dump) - Jameson Lopp (he is a bitcoin core dev with a financial interest in using bitcoin as a text dump, as an investor in Citrea) - MrHodl and Post Capone (the stuff on economic nodes is inspired by them) - Shinobi (he says plebs have no expertise to judge these matters) The video, however, is only a joke, and is not meant to attribute an opinion to any particular person or criticize anyone or any opinion in particular

Based.

This was so hilarious and clever

EDIT: I take back the statement that Antoine calls filterers morons; that is Shinobi (https://x.com/brian_trollz/status/1950547963002118196)

EDIT: I take back the statement that Antoine calls filterers morons; that is Shinobi (https://x.com/brian_trollz/status/1950547963002118196)

Yeah but I’d be offended if it were the other way round. Nobody gets to call me a knotsie. I just RUN knots, see?

I thought about having him say "If there's one thing I can't stand, it's a knotzi" -- which would have been ironic but a bit too on the nose

Good times 😂

Good Night nostr View quoted note →

Bitcoin is going to survive this attack, purge the Judas’, and become a stronger, more decentralized monetary network. A sincere thanks to any Core grafters for over-playing their hand and exposing their own corruption.

Watching this video was arguably the highlight of my day. Life is good.

As long as Knots supports covenants they're just as guilty... ... but the meme is excellent.

Good news for you my friend, knots has zero built in support for covenants (except if you consider n of n multisigs a type of covenant, as I do)

But [they] are *supportive* of at least CTV

Imagine when Knot buddies realize that they can't reject a single block full of Ordinals if were validated by the network previously... View quoted note →

Pretty funny, still wouldn’t touch Luke’s software project with your node.

Fucking love this!!

So anyone actually done the math on how much the orphan rate might go up - f.e. as a function of x% of relay network not having y% of transactions in a block in their mempool or somesuch?

♥

und Stalin -> and stall them 🤣

Perfetto 🤌 I can taste the salty tears off all corupt pricks that support data dumps.

"Ah, the beauty of diverse perspectives! It's fascinating how passion can spark such spirited conversations. Here’s to finding common ground amidst the saltiness! 🌊✨"

Not really. CTV advocates hate filterers and vice versa.

😆😂🤣💀 View quoted note →

Love this 🤭

I hope my ideological opponents laugh at the joke rather than cry. It is not intended as a serious portrayal of their opinions.

Some of us are CTV advocates *and* filterers. Myself and @Chris Guida for example.

hahah, i fucking love when people make memes using this scene from Downfall.

They might laugh at your jokes but it wont help them stomach knots NGU.

Lol, you already need Hitler to bring gillible people to knots? What about the downsides of knots? Why dies no one work on those? Knots stands on a single Person. (A bit too centralized in my Mind) Knots forces you to update your node. (Really, this is what you promote?) Running knots has literally zero impact as you See there will always be "spam" as long there is a market and they pay. Everyone who is capable installing knots can also simply adjust the op_return limit in core. Lets see how far knots can make it until it crashes from bugs. The good thing is that it showed me how many people who can be manipulated that easily without even a single argument are in #Bitcoin...

> you already need Hitler to bring gillible people to knots? It's not to bring anyone to knots, it's to make people laugh > What about the downsides of knots? Why dies no one work on those? Lots of people work on them. As an example from one of the downsides you brought up, here are people working on it:

GitHub

Rework Software Expiry by pithosian · Pull Request #134 · bitcoinknots/bitcoin

As an alternative to #124. Add a warning on startup within 4 weeks of expiry to bitcoind and bitcoin-qt. Add a note on how to override in the exis...

> Knots stands on a single Person. (A bit too centralized in my Mind) At least 10 people work on knots. > Knots forces you to update your node. (Really, this is what you promote?) It can't force you to do anything. It is software, you choose whether or not you want to run it, and if you opt to run it, you opt into the consequences. If you don't like them, don't run it. I recommend checking out Bitcoin Core for a different set of consequences. > Running knots has literally zero impact as you See I don't see that. It has consequences on you; it has consequences on your peers; it has consequences on block propagation; and, according to you, it forces you to update your node, along with potentially other less specified dangers. > there will always be "spam" as long there is a market and they pay True. Also true: if more people fight it there may be less of it > Everyone who is capable installing knots can also simply adjust the op_return limit in core Partially. But not fully. E.g. you can't reject transactions with multiple op_returns. > Lets see how far knots can make it until it crashes from bugs. Yes, let's.

Fair, I should have said “most”.

this is a well known meme you retard

he is not a retard, he just disagrees with us on something

Excellent work, loved the they dont hate you oart LOL

love it, amazing 🤣👏

Talking about sybil attack, have you seen what number count that the newest knots version is at on moody dashboard

I see it. We jumped almost 3% in one day, and over 1000 knots nodes came online today. I do not think they are all real. However, there was also a noticeable drop in Core nodes today, and that is harder to fake. I'm not sure what's going on, but right now my working hypothesis is: on the Core side, a bunch of people are dropping out; on the Knots side, a mix of sybils and newcomers from Core are bulging the Knots numbers.

Fake core nodes running out of vps credits

Yeah but is the same bullshit argument like wearing a mask to "protect" the others... Why do you want to force me to wear it if you already wear it and you feel "protected"... wear it and STFU, leave me alone.

@Matthew Kratter I think you’ll enjoy this.

Jamison Lopp is the guy in the brown jacket. Prior to the meeting he was dumping amphetamines down his throat and jacking off to manga .jpgs. He'll go down along with Casa Sh*tcoin Bitcoin Affinity Scam Wallet.

But Lo, I'm launching Satancore 1.0 net week ... it's a direct copy of Knots only with OP-RETURN fixed at 0 bytes. And then week after week I'll launch more Satancore versions with various levels of OP_RETURN bytes capped at 40 bytes. All donations to SatanCore will be doubled and sent directly to Luke Dash Jr. and then doubled again and sent to 529 college savings plans at Fidelity for his 11 kids. My project will conclude with Jamison Lopp and Peter Todd sharing Russ Ulbrect's old Federal Prison cell where they can spend an eternity sodomizing each other. I'm already contacting various three letter agencies. The Trump Cabinet is balls deep into Bitcoin and mining. Jailing paedofiles will be great campaign lit for Bobby Jr. and Tulsi who will run as a husband and wife team. (My sources tell me she rides him harder than her surf board).

That may give some clarity. (not exact calculations but I think its quite on the point)

Knots at 22%... LFGGGG

HILARIOUS ⭐ ⭐ ⭐ ⭐ ⭐ I love these Hitler rants! I created this recently. Klaus Schwab finds out about Nostr: PS: I will follow you just in the case you post new Hitler rants...

This meme explains really well what's going on with shitcoin core and how bitcoin is being attacked by some bad actors and commie core devs but it's funny that this meme hasn't been shared by some well known Bitcoin influencers on Nostr (including @ODELL) which just showed how Nostr is still echo chamber of special interest group. It also tells you that @npub10pen...n34f do not want to acknowledge the mistake of funding commie core devs YET. Let's see if they acknowledge their mistake and stop funding these commie corrupt devs once knots hit at 50%. It's already got past to 20%. If @ODELL and @gladstein still fund the commie core devs then they are either delusional (at best) or compromised (at worst) at this point. If it's latter then plebs may not want to donate any sats to @npub10pen...n34f or @npub1zhqc...h0dw. #RunKnots #ObliterateCore View quoted note →

Retard? So, where is your Argument against the statement of this meme? It is so crazy how the blocksize war was an success with so many people who fall even for the silliest shit.

Archived, it made me laught😄✌️ The good side of this discussion is that More people will run a node, More people will inform themselves about node implementation. But also i See a little danger, that newbes will geht distracted and confused from this pointless fights within Bitcoin and what many knots user will wake up to a quite big mess. It will probably be hard to recover for knots users to See that this time you are (maybe again) on the wrong side as at the time of the blocksize war.

Totally agree. Dont fight unnecessary fights, focus on the real Mission!

Luke himself had CTV on his roadmap post the other day. The fight is fake, Core vs. Knots is a psyop for Jack's money vs. Jack's money. Swap-fee based fake-L2's are driving development priorities in both cases. Active development is cover for activist development.

I wrote off Guida as a serious person after his flailing virtue-signaling defense of Bolt12 I'll reel you in on covenants disrespect eventually, but hopefully not after the damage has been done.

I acknowledge the first sentence as true. It doesn’t move the needle for CTV any faster, because sandwiches hate Luke and most filterers are against any rushed changes and lean more in the ossification camp. I’ve spoken with many of them over the past 2.5 years and only a small number of them are convinced we need CTV. The rest of your claims are kinda comical.

What's comical is you can't see past the fake fight. Sheep to the slaughter. Doesn't matter if sammiches like Luke or not, they're on the SAME TEAM., the take money from Fake-L2 team. Fake L2's want CTV because filters won't matter at all if they get it. Fake L2's are what fund active development, because they have a monetization model, swap fees. Both Knots and Core want Bitcoin poisoned, it'll look like this unless active development is rejected wholesale.

Why not ask @Luke Dashjr?

No res on X, but I hope he'll acknowledge this in a manner consistent with his concerns about Bitcoin's ethereumification.

im talking about the hitler meme, to be clear

now u accepted the if i say "knots is bullshit" u cannot block me but u still decided to move X to nostr - good move

Thanks, I think

LMAO 😂

fck this is funny

24% 🚀🚀🚀

And here was Jamison Lopp of Casa wallet with dreams of pulling his yacht aside Michael Saylor's ..... all hopes Dashed !

25% 🚀🚀🚀

I just wonder what can be the endgame here? Filterers want to stop transactions they don't like, but no penetration of filters can prevent a small fraction of nodes to relay non-standard transactions and miners to directly accept them. Ocean is gathering hashrate. When hard fork?

Ocean may be gathering hashrate, but not every miner in Ocean filter transactions, though.

> what can be the endgame here? When you run the default relay policies in Knots you get one benefit immediately: less spam in your mempool You also get two more subtle benefits: (1) you're not responsible for relaying most spam to miners (2) you slow down the propagation of spam-filled blocks The latter benefit also gives spam-free blocks a relative speed boost

Awesome. I wasn't paying attention to the novel and with this meme I have a full summary. 👌

Less valid transactions in my mempool will make my node unreliable in predicting the next block and estimate fees, especially in extreme cases where it could be critical. Not relaying is the same as not running that node for those transactions, does't stop anyone else. The filtering node slows down it's own to verify blocks - will be later to reach the tip, will waste hashrate in that time if mining. Only the fastest route counts so even a supermajority would not be signficant.

> Less valid transactions in my mempool will make my node unreliable in predicting the next block and estimate fees, especially in extreme cases where it could be critical I do not understand this criticism. Neither Knots nor Core looks *only* at the mempool to estimate fees. Partly as a result of this, the scenario where a wallet based on Knots would give a fee estimate that "wouldn't work" seems absurd: (1) the total weight of spam transactions in the mempool would have to *suddenly* increase (2) without a corresponding, similar increase in competition from "normal" (non-spammy) transactions (3) to a point where the non-spammy transactions only show fees at level X (4) but the real feerate is actually at level Y (5) and Y is so much larger than X that X won't work. But even that's not enough, for the following reason: As an example of a wallet with a critical need to get a transaction confirmed in a certain time frame, consider a lightning node. These have to be prepared to use RBF or CPFP to bump their transactions if a justice transaction is called for, because they must "go through" in a certain time frame. (E.g. see here: https://docs.lightning.engineering/lightning-network-tools/lnd/sweeper). Since Knots and Core both look at "recent blocks" to figure out what the current feerates are, and not just the mempool, this means the above scenario -- with the sudden increase in spam fees with several other conditions attached -- will only cause the wallet to fail to get its transaction confirmed if the scenario *repeats* as each subsequent block comes out, such that the additional fee information provided by block K+1 is already out of date when Knots tries to estimate fees again at the prompting of whatever wallet wants to use RBF or CPFP to get its transaction confirmed. Given the absurdity of such a situation playing out in the real world, it seems equally absurd to use this as a legitimate criticism of Knots. Even in critical applications, your fee estimator does not need a *precisely accurate* mempool. If bitcoin required that, it would be a broken system, because the mempool is intentionally not consensus critical.

This is excellent, Super! Best dude arpund.

Thanks for clarifying. I understand that the fee estimation uses past block data and there is an ability to self-correct with RBF/CPFP. If the concern is not about the initial estimate failing there is still a worse reaction time. If a node is blind to a large segment of the real mempool, wouldn't it be slower to detect a sudden spike in the fee market, potentially causing it to fall behind in a fee-bumping war? On the other points we are also left with the problem that the network communication is breaking down because more nodes are rejecting the very transactions that miners are confirming in blocks. Here is the problem visualized: "In early June we were requesting less than 10kB per block were we needed to request something (about 40-50% of blocks) on average. Currently, we are requesting close to 800kB of transactions on average for 70% (30% of the blocks need no requests) of the blocks." from this research thread:

Delving Bitcoin

Stats on compact block reconstructions

An interactive/modifiable version of all the data and plots are in a jupyter notebook here: https://davidgumberg.github.io/logkicker/lab/index.html...

> If a node is blind to a large segment of the real mempool, wouldn't it be slower to detect a sudden spike in the fee market, potentially causing it to fall behind in a fee-bumping war? A fee-bumping war? I think I need more context. I am not aware of any real-world software that requires users to competitively bump their fees. Are you saying there *is* such a protocol? Are you perhaps referring to the LN attack where the perp repeatedly RBF's an input to a tx that creates old state? Even there, the would-be victim doesn't have to repeatedly RBF anything. Instead, he is expected to repeatedly modify his justice tx to use the txid of whatever transaction the perp creates after *he* (the perp) performs an RBF. The victim *does* have to set feerate each time, but his feerate does not compete with his opponent's, as his opponent is RBF'ing the input to the justice transaction's *parent,* whereas the victim simply sets the feerate of the justice transaction *itself,* and he is expected to simply set it to whatever the going rates are. Moreover, as mentioned above, I think it's absurd to expect a real-world scenario where Knots reports a too-low feerate for 2016 blocks in a row, despite getting information about the current rates from each of those blocks *as well as* its mempool. For that to happen, spam transactions would have to be broadcast at a completely absurd, constantly-increasing rate, for 2016 blocks in a row, with bursts of *yet further* increased speed right after each block gets mined (otherwise the fee estimator would know the new rate because it shows up in the most recent block), and the mempool would *also* have to go practically unused by anything else (otherwise the fee estimator would know the new rate when it shows up in the non-spam transactions that compete for blockspace with the spam transactions). > On the other points we are also left with the problem that the network communication is breaking down because more nodes are rejecting the very transactions that miners are confirming in blocks. This communication problem can be summarized as, "compact blocks are delayed when users have to download more transactions." I think driving down that delay is a worthwhile goal, but Core's strategy to achieve that goal is, I think, worse than the disease: Core's users opt to relay spam transactions as if they were normal transactions, that way they don't have to download them when they show up in blocks. If you want to do that, have at it, but it looks to me like a huge number of former Core users are saying "This isn't worth it," and they are opting for software that simply doesn't do that. I expect this trend to continue.

BitcoinKnots myself. Great interview btw the other day on @Guy Swann show

This is hilarious, regardless of which Bitcoin implementation one thinks is best.

Fair point regarding the fee estimation and appreciate the detailed breakdown. I gladly accept that the fee estimation is robust enough even with a partial view of the mempool. > Core's strategy to achieve that goal is, I think, worse than the disease: Core's users opt to relay spam transactions as if they were normal transactions, that way they don't have to download them when they show up in blocks. The choice isn't between a cure and a disease (purity vs. efficiency), but about upholding network neutrality. The Core policy relays any valid transaction that pays the fee, without making a value judgment. The alternative - active filtering - is a strategic dead end for a few reasons: - It turns node runners into network police, forcing them to constantly define and redefine what constitutes "spam." - This leads to an unwinnable arms race. As we've seen throughout Bitcoin's history, the definition of "spam" is a moving target. Data-embedding techniques will simply evolve to bypass the latest filters. - The logical endgame defeats the purpose. The ultimate incentive for those embedding data is to make their transactions technically indistinguishable from "normal" financial ones, rendering the entire filtering effort futile.

> It turns node runners into network police It doesn't turn them into "network police" because they aren't policing "the network" (other people's computers) but only their own. I run spam filters because I don't want spam in *my* mempool. If other people want it, great, their computer is *their* responsibility. > constantly define and redefine what constitutes spam It doesn't constantly need redefinition. Spam is a transaction on the blockchain containing data such as literature, pictures, audio, or video. A tx on the blockchain is not spam if, in as few bytes as possible, it does one of only two things, and nothing else: (1) transfers value on L1 or (2) sweeps funds from an HTLC created while trying to transfer value on an L2. By "value" I mean the "value" field in L1 BTC utxos, and by "transferring" it I mean reducing the amount in that field in the sender's utxos and increasing it in the recipient's utxos. > Data-embedding techniques will simply evolve to bypass the latest filters And filters will simply evolve to neutralize the latest bypass. They cannot withdraw this race if the filtered are more diligent than the spammers. > [What if they] make their transactions technically indistinguishable from "normal" financial ones Then we win, because data which is technically indecipherable cannot be used in a metaprotocol. The spammers lose if their software clients cannot automatically decipher the spam. If the spammers develop some technique for embedding spam that can be automatically deciphered, we add that method to our filters, and now they cannot use that technique in the filtering mempools. If they make a two-stage technique where they have to publish a deciphering key, then they either have to publish that key on chain -- which allows us to detect and filter it -- or they have to publish it off-chain, which is precisely what we want: now their protocol requires an off-chain database, and all of their incentives call for using that database to store more and more data.

I appreciate the detailed response, but in these points we are in disagreement: 1. Policing your node vs. "the network": Framing this as only policing your own node overlooks the network externalities. Your filtering directly impacts the efficiency of block propagation for your peers. It turns an individual policy choice into a network-wide cost. 2. Your definition on what transactions should be allowed: The proposed definition of "spam" is not a filtering policy; it's an argument for a hard fork. The current Bitcoin consensus explicitly allows these transactions, and has for years. To enforce your narrow definition network-wide, you would need to change the fundamental rules of the protocol. This brittle definition would not only freeze Bitcoin's capabilities but would also classify many existing financial tools from multisig to timelocks and covenants as invalid. The arbitrary exception for L2 HTLCs only proves the point: you're not defining spam, you're just green-lighting your preferred use cases. 3. The arms race is asymmetric: This isn't a battle of diligence; it's a battle of economic incentives. There's a powerful financial motive to embed data, but only a weak, ideological one to filter it. 4. You're underestimating steganography: You're focused on overt data, but the real challenge is data hidden within what looks like a perfectly valid financial transaction. A filter cannot distinguish intent. To block it, you'd have to block entire classes of legitimate transactions that are valid under today's consensus, which is a non-starter.

> Framing this as only policing your own node overlooks the network externalities If I set up a fence around my house, that has neighborhood externalities. My neighbors can't see one another by looking across my lawn, for instance. But framing "anything with externalities" as "policing" the people it has an effect on is problematic. Just as it is not my responsibility to ensure that my two neighbors can see one another across my lawn, it is also not my responsibility to ensure that miners get their blocks to my peers quickly. I may decide to help some or all of them do that; but even if I do make such a decision, it is not as if that puts me in some position of responsibility where I cannot now apply filters to transactions that I *don't* want in my mempool and *don't* want to assist with. > Your definition on what transactions should be allowed...is not a filtering policy; it's an argument for a hard fork. Those things are not incompatible. One could theoretically propose something as a mempool filter *and* as a hard fork; the nice thing about mempools is, they do not require consensus to modify, so you can just do it. Whereas a hard fork is very hard precisely because unless you get a whole bunch of people to agree with you (i.e. get consensus) you end up just creating an independent network (not that there's anything wrong with that, unless you start scamming people with it) If I *did* propose this for a fork, it would be a soft fork, not a hard one, as it would require *tightening* the rules, not loosening them. But it would have some of the same *effects* as a hard fork if it was contentious, because contentious softforks (theoretically) split the network into incompatible branches just like hard forks do. That said, while I don't want to entirely close the door on a soft fork, I think it is wise, for the aforesaid reasons, to just do it in my own mempool, and tell other interested people (if any) how to do it in theirs -- because I don't need consensus for that and I get all the benefits I seek as a result and I also make less people mad. > The current Bitcoin consensus explicitly allows these transactions, and has for years. To enforce your narrow definition network-wide, you would need to change the fundamental rules of the protocol. Nice that I don't *want* to enforce my definition network-wide, then. But we've been over similar ground moments ago; perhaps you think that slightly slowing block propagation speed among my peers counts as "enforcing my definition network-wide." If so, I disagree, and I'd particularly like to highlight that this slowdown doesn't even affect how fast my *peers* receive a block unless *my* connection with a given peer would otherwise be their fastest available connection. (If they've got peers A, B, and Me, and peer A is faster than me anyway, then it doesn't matter that I have to download some transactions before serving them a block -- they were gonna get the block faster from peer A anyway.) And, in my personal case, I very much doubt that I am anyone's fastest connection, as I personally operate on pretty bad wifi that I find in hostels and airbnbs. > This brittle definition would not only freeze Bitcoin's capabilities but would also classify many existing financial tools from multisig to timelocks and covenants as invalid If applied as a fork, yes, but that's not what I want to do. I only want to apply it in my own mempool, by not speeding along transactions that I find stupid. Good point about multisigs and timelocks, though; if I ever get around to implementing my preferred filter I will try to ensure it allows those, as I do want to help relay such transactions around on the network. > The arbitrary exception for L2 HTLCs only proves the point: you're not defining spam, you're just green-lighting your preferred use cases Greenlighting use cases that I "prefer" -- as in, want to see more widely adopted -- is precisely what I want to do in my own mempool. I don't want to help people spam the network; I want to help them adopt layer 2s and sometimes use L1 as money. So I want a filter that supports the latter things -- the things I like and want in my mempool -- and locally blocks the other things -- the things I don't like and don't want in my mempool. > The arms race is asymmetric: This isn't a battle of diligence; it's a battle of economic incentives. There's a powerful financial motive to embed data, but only a weak, ideological one to filter it. I suppose a similar thing is true of email spam: the motive to get email spam in front of many eyeballs is more powerful than my motive to block it from my inbox. Nonetheless, email filters are powerful enough to largely compensate for that asymmetry, and I'd like to help design mempool filters that offer similar compensation. > You're underestimating steganography: You're focused on overt data, but the real challenge is data hidden within what looks like a perfectly valid financial transaction. A filter cannot distinguish intent. To block it, you'd have to block entire classes of legitimate transactions that are valid under today's consensus, which is a non-starter Filtering entire classes of transactions that are valid under today's consensus is what this entire debate is about. I am enthusiastically in favor of doing so in my local mempool, and sharing what works with others who may have similar interests.

It's so great!!

Too good. 🔥

😂 lmfao Funniest shit. I haven’t seen the of this meme in so many years.

@MrHodl only wants the forked coins

Smashed it 🔥🔥👊🏻

Nailed it, had a good laugh! Now lets get back to work plebs :D