Hi, From what I have read so far there is not a clear, quantifiable, agreed-upon set of criteria defining what constitutes “spam.” Some describe it as a "large non-monetary data embedded in transactions" but what counts as large? Are lightning HTLCs (etc.) "monetary" or are they merely monetary adjacent? What specifically defines "non-monetary"? I've also seen things like “undesirable extra load” or “not following best practices” but again what qualifies as "undesirable" and what is "best practices"? Ideally, I'd like to see something that says: "a transaction is spam if it meets criteria X, Y, and Z." In my view, the inability to create a precise, objective definition makes such rules essentially impossible to specify or enforce consistently, leading to endless whack-a-mole changes. That in turn highlights why this proposal seems problematic: any attempt to codify “spam” without a rigorous definition risks both social and technical fragmentation — continual revisions under external pressures, and a probable fork if implemented. Have a nice weekend, Chris On Sat, Nov 8, 2025 at 11:43 AM Daniel Buchner wrote: > I agree with Greg, 0 quantification of what defines success has been > provided for the generally expressed intention of reducing spam. If one > admits any decentralized system that allows user-derived public keys / > hashes fundamentally includes the ability to embed spurious data in place > of those values, eliminating the spamming of those values is effectively > impossible. That leaves us with the question: given the goal is simply > 'reduction of spam', what defines success and what are the limiting > principles? If success is 'reduce spam as much as possible', that would > implicitly mean one should remove virtually all OP codes and leave Bitcoin > with only basic send/receive that utilizes as few public keys and hashes as > possible. Through this rational, empirical lens, I just don't see how this > PR's seemingly arbitrary modifications of Bitcoin's protocol rules 1) > actually reduce spam (likely will just result in spammers using different > constructions), and 2) achieve mitigation of the hazy legal concerns that > were a primary driver of this initiative. > > Can you please quantify what amounts/measurables you are targeting, and > explain why this PR will achieve reductions to those level, such that they > deliver on desired outcomes? Please connect whatever realistically > achievable level reductions you believe will occur to the real world > effects you believe they will deliver, such as "If we can just ensure no > block can contain more than X bytes of spam, the Three-Letter Agency Y will > not come after us because Z rule/limit/law/regulation says so". I am just > providing an example of linking action to outcome delivery, so if you don't > like that one, please provide whatever you feel best conveys it. > > Would you then agree that this proposal will fail at its stated purpose, > particularly with respect to concerns about potentially 'unlawful' > material? As that concern as expressed has a threshold of "any at all" and > could just as well be performed via a "less commonly abused" path? Would > you also agree the same for essentially all other forms-- that they'd > simply made a few line of code changes and then evade these restrictions? > > In light of that, how would the very real and significant reductions in > intentional functionality (such as efficient "few of dozens" multisigs or > other such constructs) be justified? How could the confiscation risk be > justified? How could the deployment costs be justified? How could the > "policy risk" be justified? (E.g. that bitcoin could be driven or forced in > to an endless sequences of 'update' blocking actions, each carrying its own > risk and disruptions) > > Although your description of changes is vague and it's not possible to > tell for sure without seeing the actual updates-- I don't think your > suggested revisions will move your proposal off from having essentially > zero risk of adoption, and if it were adopted (which I think is unlikely) I > think it's a certainty that there would be a countering fork to continue a > Bitcoin without these poorly justified (even essentially useless) > restrictions. > > -- > You received this message because you are subscribed to the Google Groups > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/c385373b-a307-43b3-b958-fadb5866e3d9n%40googlegroups.com > > . > -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAL5BAw054-GONdLcRWN3Fpv24WeYV%2BOKUiWhVsyArqznO-yZ7A%40mail.gmail.com.