pull down to refresh
121 sats \ 24 replies \ @Scoresby OP 3h \ parent \ on: Giacomo Zucco on the history of filters in Bitcoin bitcoin
Let's take this list as a statement of his position:
I really only disagree with the top two.
-
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.
-
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.
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
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.
reply
I personally don't think that softforks like LNhance or CTV will increase usage outside of maybe a novelty spike, at least not in the mid-term, but maybe the solutions built on top will after a while, and maybe Giacomo has something in mind. I don't know. It'd surprise me though.
None of the volume spikes were caused by a softfork, except inscriptions following what Giacomo in your upper post calls "the 2021 bug" 1, almost 2 years post-activation. Segwit maybe had a temp spike late 2017 (but IIRC that was a price pump)? That's all.
Spam is something different and doesn't makes sense in the context of Bitcoin transactions.
That's because "spam" is subjective. I think mostly people have a problem with terminology.
valid bitcoin transactions shouldn't be called spam
A miner filling the entire block with fake addresses in a 0.92MB coinbase tx is consensus-valid. What would you call that?
Footnotes
-
This is basically taproot changing the policy which ultimately enabled large inscriptions, afaik this is what was not addressed/covered in ref 9 in BIP-342). Personally I agree with Giacomo that this is the cause of "spam", though I'd not call it a bug, more a design and review error. Hindsight though - I don't recall anyone raising it at design time - but maybe on IRC, or I missed a mailing list item. I myself didn't respond to the BIP at all so I can't criticize anyone. ↩
reply
Inscriptions being caused by a bug in Taproot is an often repeated, but unconvincing narrative. I would agree with "none of the volume spikes were caused by a softfork".
The 2017 spike coincided with a big bullrun to a new ATH. There just was massive trading and transaction volume. While Segwit had been activated, most wallets didn’t support it yet, and most transactions were still non-segwit.
reply
I think that the point isn't that it was impossible before taproot, just more complex.
I'm sure you've noticed how crazy those BRC-20 mints worked, where there is a big race to get as many tx in before everyone else with tons of txs wasted at the tail end. Really poor design.
Would these same people done this if the design was much harder? Can't tell. So it's moot.
reply
Just how terribly designed BRC-20 is from top to bottom really adds insult to injury.
Interesting point about the complexity, needing to create multiple outputs and inputs would have definitely made it more expensive and a bit more complex. So, yeah, Taproot did make it easier, and if it had been harder, the BRC-20 author would have perhaps not created his proof-of-concept design for a laugh. Just how terribly designed BRC-20 is from top to bottom really adds insult to injury.
A miner filling the entire block with fake addresses in a 0.92MB coinbase tx is consensus-valid. What would you call that?
If the miner didn't have much hashrate, I'd call it their choice. If they were a big pool, I'd call it an attack.
Bitcoin is mostly interesting to me because of censorship resistance. Everything else grows out of that. If valid transactions can ruin bitcoin, then we probably need to consider a fork to make such transactions invalid (I'd love to see the Great Consensus Cleanup get forked in post haste).
Miners don't even have to do fake addresses. A big enough pool could prevent others from transacting simply by filling blocks with transactions that sent themselves their own uxtos. This is certainly a vulnerability. The fee market is our only defense against it.
The same is true for "spam." As Betty Hutton1 says, anything little jpeg gremlins can do, a state actor can do better. If spam is a real thing and harmful, a state actor can use it to wreck Bitcoin. We would need to make it something that cannot be done. If this is not achievable, the system had better get used to it -- and if it breaks Bitcoin, I'd like to know as soon as possible.
(I don't think it breaks Bitcoin, which is why I don't think spam is a problem.)
Footnotes
reply
Mind you I'm not saying you're wrong, I'm just exploring the limits.
I think that what Luke argues is that a miner including all these shitty txs is comparable. (Though you can't change it so I take this as an observation, judgement would be pointless)
What makes us think that the bulk of those inscriptions weren't government sponsored or corporate attacks? Or some shitcoiners?
All we know is that it didn't kill bitcoin. The only result it had for me personally was that it was uneconomical to subswap out some sats to L1 after a string of sats earned so I temp swapped to Liquid at the time. Which I don't really wanna but it was more economical to take remote rug risk and use boltz twice, in the end.
reply
I think that what Luke argues is that a miner including all these shitty txs is comparable.
That’s charitable of you, but Luke literally claims that
-datacarrier has always referred to all forms of embedding data, when that is in direct contradiction to the discussion around and documentation of the introduction of -datacarrier. He even unilaterally filed a CVE for that. As far as I am aware, no other Bitcoin Core contributor shares this interpretation.reply
Let's pretend inscriptions are a government sponsored attack: clearly a government that wants to attack bitcoin isn't going to stop because we are trying to filter them out. If filters are that powerful, why are we using a difficulty -adjusted proof-of-work blockchain?
I agree. I delayed a few consolidations, and maybe used boltz or lightning more than I would have previously.
All in all, I think it's good that Bitcoin has had to deal with the inscribers and stampers and such. The more Bitcoin gets tested by people using it in ways we never anticipated, the more likely we find the problems and fix them. I get frustrated with the filter camp because they aren't proposing a solution that actually fixes this problem in the face of a state attacker. Any solution less than that isn't worth pursuing, from my ignorant, non-developer viewpoint.
reply
If filters are that powerful, why are we using a difficulty -adjusted proof-of-work blockchain?
If you can incentivize a pool to mine jpegs rather than real transactions that you can sell at 1+x the cost to mine, why would you need any hashpower at all? This completely removes difficulty adjustments from an attack. Especially if you can literally create jpegs and shitcoins and uninformed people will buy them, gamble with them. It would make a pretty neat psyop. mind you I don't believe this is true, just doing the red-team thing
Governments can print money. It takes time for currencies to devalue against BTC on the open market, unless said printer would be used to directly buy BTC, when they're being printed and initially spent. Also this doesn't have to be done transparently. We don't really know that we can defeat large governments that actively attack Bitcoin. We will probably find out one day when we're in an oversold dip? Hopefully not soon though.
I agree that it's good that this happened, because there's tons more monitoring now and tons more discussion, even though it's very fucking cringe at times. I hate the narratives and personas, though. I personally subscribe to Peter's libre idea much more than to filters, but it's good that that's not the only opinion.
reply
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
reply
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
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
Is his takes the "laughs in" or the original bullet point?
reply
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:
reply
reply
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