pull down to refresh

I don't agree with Zucco's opinion about spam, but I think he has been an interesting voice in the debate -- also the thread to which he is replying is pretty interesting: Adam Back and Luke Jr discussing filters
Satoshi added many mempool filters himself, also mentioning spam explicitly (famous Lady Gaga discussion with Andresen). Virtually all Core developers for years agreed with and built on this approach, including current champions of the removal path (you can find mentions in this sense of Sipa, Gmax, Achow), often mentioning spam explicitly, with the main exception of Todd, who for many years argued for a mempool=blocks fee-rate-based approach, now culminating in the LibreRelay fork. To some degree, full-RBF was an instance of this debate (while not spam-related) where most devs (including Luke-jr actually agreed with Todd. Slowly, more people moved on Todd side (the only explicit reference I've seen so far about the change of heart is the tweet from Achow about "growing up").
In 2021, an unintentional bug shipped with Taproot (but not connected with Taproot itself) defused one such filter (datacarriersize) for some txs. In 2023, shitcoin scammers abused the witness discount to create a 4Mb block (impossible to create with non-spam txs), using txs that would have bypassed the filters thanks to the bug if broadcast (but it's noteworthy that the spam was not broadcast, it was sent directly to a colluding mining pool, paid offband, so even non-broken filters wouldn't have stopped it). After that, it seems like an important priority for the current Core mantainers is to move Core towards a more LibreBitcoin-style. Personally, as an illiterate pleb who listens to podcasts, I consider the technical arguments in this sense legit and overall directionally sound, even if they don't justify the prioritization/rush, especially considered the widespread opposition by many power-users, builders, entrepreneurs, advocates/activists.
Some people, including myself, are under the impression the the rush/priority is more driven by ego struggles, social dynamics and power games which have little to do with technical mempool policy debates: avoiding (inevitably-painful) self-reflection on the 2021 bug, justifying social proximity by many current contributors to the shitcoin scammers involved in this kind of spam (eg: Rijndael), not hurting feelings of colluding mining pools currently funding Core development but also monetizing OoB payments for spam (eg: Mara), regulating old grudges with maverick/outcast/contrarian devs (eg: Luke-jr, especially after the conflict with him escalated since the FBI hinted at a Core meetup as the origin of a nasty cybercrime at Luke's expenses), venting envy by many contributors that said maverick/outcast/contrarian devs received investment money (eg: many of them wrote to Dorsey publicly to try to convince him to remove his support to Luke-jr efforts towards mining decentralization), overall political devides (including a Bitcoin version of the overall "DEI" and "woke" related cultural wars).
Regardless of my (and other people's) interpretation (cf last paragraph) of the reasons mempool policy tweaking is considered a priority (I have to add there are two weak but not-irrelevant arguments for that: Todd made a case a mempool=blocks approach is safer for L2 unilateral exits, some devs made the case that because of the current spam attack we should actively engage with harm-reduction by opening up the less damaging attack surfaces like op_return to hijack some pressure from the more damaging ones like UTxOset), the effect of the conflict was also a very bad management of the GitHub repo, with obviously good-faith, balanced, nuanced, polite and insightful comments hidden as "spam" (ironic), disagreeing parties with lots of skin in the game banned from the repo, contentious PRs closed only to be insta-reopened to let some ACK from friends sneak in and close them again, etc. That also escalated further the conflict.
There are some things happening off-line as well which escalated things: for example some fairly neutral but not "aligned" developers have been excluded from in-person Core meetups, after having been criticized for not taking a strong enough position in this debate. Some of us get to know about these things from personal conversations, but the involved parties often ask not to publish details, in order to avoid further retribution. So we end up with some public outspoken figures (including for example Mechanics) raising red flags about an overall Core problem, but most viewers not being able to verify any details. Then it becomes a religious/tribal choice of "camps": every argument on one side is a "lie". On my personal account, I can say that some philosophical issue (people claiming absurd things about the nature of spam or censorship) triggered me more than the policy debate itself. I could have kept more cool if less people called filtering "censorship" (utter self-contradictory nonsense) or spam "impossible when valid/expensive (utter self-contradictory nonsense).
123 sats \ 15 replies \ @optimism 2h
Thanks for sharing.
What element from Giacomo's take on spam do you disagree with?
reply
Let's take this list as a statement of his position:
  • "if a message is valid wrt a protocol it can't be spam" (laugh in SMTP)
  • "if a message entailed any cost to send once it can't be spam" (laugh in call-center setup investment)
  • "spam isn't even possible to define in the first place" (laugh in 40 years of common sense)
  • "refusing to download and relay some information to/from your node is censorship thus against Bitcoin ethos" (laugh in consensus rules)
  • "Bitcoin Core never used mempool policies to filter unwanted transactions" (laugh in about 12 years of Core history starting from Satoshi)
  • "Mempool filters never managed to increase the cost of spam" (laugh in logical consistency with the statement below)
  • "By incentivizing OoB payments or UTxOset bloat, mempool filters are actually harming the network" (laugh in logical consistency with the statement above)
  • "Bitcoin Core developers are always necessarily well-meaning and questioning that is in itself evil" (laugh in adversarial thinking)
  • "Whoever doesn't unconditionally agree with all the statement above must necessarily be an ignorant noob misled by evil Twitter influencers"
I really only disagree with the top two.
  1. Valid messages aren't spam In my mind, spam is DOS-attack Lite. If there was no spam filtration in email, our inboxes would be obliterated and it would be very difficult to use email. In the case of Bitcoin, valid transactions involve a certain amount of proof of work: they must use a UTXO, which means the person sending them must have a UTXO. This is different starting point than SMTP. Also in the case of Bitcoin, blockspace is limited. Presumably, Bitcoin is designed to function with full blocks. I don't see the argument that an empty block is better than a block full of garbage non monetary transactions. In the analogy of email, it might make sense (empty inbox is better than spam-ful inbox) but in the case of the bitcoin chain, where people pay to produce blocks, and those blocks are capped in size, empty blocks seem like a waste.
  2. Costs limit spam Obviously email spam, telemarketing spam, junk mail all have costs. The difference in bitcoin is that blockspace is limited and a fee market exists for this limited space. Spammers are not preventing me from getting my transaction confirmed. If we say they are a problem because it makes my transaction cost more, this is also true of other people bidding to get their monetary transactions confirmed. Complaining that someone else is willing to outbid you in the market is nonsensical.
I really appreciate his takes because he has managed to avoid being pushed into either one of the camps (something I appreciate because I've often been a fan of alternate implementations of Bitcoin but have never particularly liked Knots). And most of Zucco's other points are spot on.
reply
Hmm.
For email, it's clear that spam isn't based on whether the message is valid protocol or whether the sender paid a cost. It's clear that email spam is based on whether the receiver wanted to receive the message or not.
In that sense, I'm not sure if email analogies are very helpful for bitcoin. Bitcoin is a public ledger. The financial transactions may be peer-to-peer, but the data is public, and thus not very much like email.
reply
I think slop responses on SN would make a better comparison.
reply
100 sats \ 1 reply \ @Scoresby OP 26m
Slop responses on SN are closer to the email analogy than to "spam" transactions on Bitcoin.
There is no (meaningful) upper bound to the amount of slop responses that could be posted on SN. There is a block size limit. The primary reason I should care about the number of "spam" transactions in blocks is that they make it more expensive for my transaction to get confirmed.
There is a secondary reason that I might care whether "spam" transactions are in blocks: it is that it makes it more difficult for me to run a node (IBD takes longer, I need more disk space, the compute on blocks gets more intense and older machines might struggle). However, these are all problems I will encounter if Bitcoin blocks are full of monetary transactions. I don't understand why I should be outraged in one case and not in the other. If full blocks is a problem, this is a problem that Bitcoin needs to solve at the consensus level.
reply
102 sats \ 0 replies \ @optimism 17m
There is no (meaningful) upper bound to the amount of slop responses that could be posted on SN
Sure there is. When SN gets tired of wasting a couple BTC a month on hosting due to slop, and the beloved team proclaims "screw you guys we're going home", that limit was reached. It's just that some things were foreseen early on with Bitcoin, which makes sense for a p2p system, and a limit was built in and later enlarged, and there are limits you can set to upload for example, to deal with this.
Ultimately the non-filter solution that we use on SN (downzap = we spend money to keep it clean-ish and disincentivize spam) is possible on Bitcoin too; it has been the top boost for a while now: #1077925
reply
102 sats \ 2 replies \ @optimism 59m
Hmm but this is his critique of some Core strawman, i.e. he's answering the question "what's the Core position that you disagree with"? He disagrees with all of these.
The tweet underneath does something similar for "Team filters":
From the "team filters", instead, I'd go with the following:
  • "Bitcoin can't survive spam"
  • "Mempool filters are the most important and structural way to fight spam"
  • "Mempool filtering has absolutely zero cost or trade-off in terms of OoB incentivization, block relay delay, fee estimation"
I.e. these are the narratives he thinks are false? So his opinion is the opposite? I'm quite sure it was Giacomo that went on stage at either or all of PlanB/BTCPrague/Honeybadger a few years ago when this all started and asserted: "Ordinals are fucking retarded" and then defended that for an hour.
reply
100 sats \ 1 reply \ @Scoresby OP 33m
Right, so perhaps I should say that I disagree with his opinion of these arguments about spam.
This is probably a better summary of his position:
I'm skeptical of filters as a long term sustainable solution for spam attacks, where the attacker is well-funded enough to bribe miners into behaving maliciously. I think the only structural and long-term solution can only be increasing economic density of L2s, to fight L1 censorship and spam with fee pressure. I believe covenant SFs in general and LNHance in particular would greatly help towards such goal. But I don't tolerate the above lies. And sadly the LNHance campaign is not deeply entangled with promoting them.
Honestly, I agree with this (although I'm not knowledgeable enough to have a worthwhile opinion about which soft fork proposal to pursue), but his "I don't tolerate the above lies" bit is where I come into conflict. I am of the persuasion that valid bitcoin transactions shouldn't be called spam. Spam is something different and doesn't makes sense in the context of Bitcoin transactions.
Is his takes the "laughs in" or the original bullet point?
reply
100 sats \ 1 reply \ @Scoresby OP 1h
I believe his takes are "laughs in". I probably should have chosen a different summary, but I thought the way he put it there was artful.
This tweet has perhaps a better explanation:
102 sats \ 2 replies \ @sudonaka 21m
For what technical reason do you dislike knots?
reply
just never seemed better than core?
I'm interested in an alternate implementation like libbitcoin because it makes different trade-offs and has different assumptions about Bitcoin. I think knots is similar enough to Core that it's not really an alternate implementation.
reply
Yes knots is only a fork of bcore with extra mempool controls and options.
I think we should have a lot of Bitcoin software options. That way no single dev team has too much pressure on them.
reply
202 sats \ 1 reply \ @petertodd 25m
In 2021, an unintentional bug shipped with Taproot (but not connected with Taproot itself) defused one such filter (datacarriersize) for some txs.
This is fundamentally wrong.
I posted a separate article explaining why: #1196553
tl;dr: -datacarriersize was never intended to stop all types of data containing transactions. It was obviously impossible to do that. And in the same release — years prior to taproot even existing — we added that option, we made it possible to embed data in scriptSig: essentially the exact same way inscriptions embedded data.
Leave Taproot out of this.
reply
Fair, it is a casualty of trying to talk about a different point (are valid transactions spam). I probably should have been more selective about what I quoted.
reply
Very interesting that there are a lot of elements to this "debate" that are not being carried out in public fora like twitter
reply
21 sats \ 4 replies \ @ek 6h
twitter is not a public forum
reply
how do you mean?
reply
121 sats \ 2 replies \ @ek 5h
you need to be logged in to view replies
reply
77 sats \ 1 reply \ @optimism 2h
Not if you click the link your bot provides! It's how I get to read replies. For which thanks <3
reply
0 sats \ 0 replies \ @ek 2h
<3
reply
More info like that at https://wtfhappenedinfeb2023.com/
reply