From: Chris Riley <criley@gmail.com>
To: Daniel Buchner <danieljb2@gmail.com>, Greg Maxwell <gmaxwell@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork
Date: Sat, 8 Nov 2025 12:55:01 -0500 [thread overview]
Message-ID: <CAL5BAw054-GONdLcRWN3Fpv24WeYV+OKUiWhVsyArqznO-yZ7A@mail.gmail.com> (raw)
In-Reply-To: <c385373b-a307-43b3-b958-fadb5866e3d9n@googlegroups.com>
[-- Attachment #1: Type: text/plain, Size: 5338 bytes --]
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 <danieljb2@gmail.com> 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
> <https://groups.google.com/d/msgid/bitcoindev/c385373b-a307-43b3-b958-fadb5866e3d9n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
--
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.
[-- Attachment #2: Type: text/html, Size: 6612 bytes --]
next prev parent reply other threads:[~2025-11-08 17:56 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-25 20:43 dathonohm via Bitcoin Development Mailing List
2025-10-26 20:47 ` Jameson Lopp
2025-10-27 4:22 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 12:14 ` Jameson Lopp
2025-10-27 16:35 ` TheWrlck
2025-10-26 22:27 ` Peter Todd
2025-10-27 3:41 ` Jal Toorey
2025-10-27 17:27 ` Max
2025-10-27 4:08 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 18:29 ` Kyle Stout
2025-10-27 19:56 ` Greg Maxwell
2025-10-28 5:13 ` dathonohm via Bitcoin Development Mailing List
2025-10-30 0:31 ` Antoine Riard
2025-10-30 2:43 ` Erik Aronesty
2025-11-08 0:51 ` dathonohm via Bitcoin Development Mailing List
2025-11-08 3:43 ` Edil Guimarães de Medeiros
2025-11-08 9:30 ` 'Bitcoin Eagle' via Bitcoin Development Mailing List
2025-11-08 15:38 ` Greg Maxwell
2025-11-08 16:40 ` Daniel Buchner
2025-11-08 17:55 ` Chris Riley [this message]
2025-11-08 21:02 ` dathonohm via Bitcoin Development Mailing List
2025-11-08 21:39 ` Greg Maxwell
2025-11-09 20:07 ` dathonohm via Bitcoin Development Mailing List
2025-11-11 7:43 ` 'Bitcoin Eagle' via Bitcoin Development Mailing List
2025-11-11 16:23 ` Greg Maxwell
2025-11-09 1:21 ` Murch
2025-11-09 20:56 ` onyxcoyote
2025-11-09 21:34 ` Peter Todd
2025-11-10 19:46 ` Lucas Barbosa
2025-10-28 9:16 ` /dev /fd0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAL5BAw054-GONdLcRWN3Fpv24WeYV+OKUiWhVsyArqznO-yZ7A@mail.gmail.com \
--to=criley@gmail.com \
--cc=bitcoindev@googlegroups.com \
--cc=danieljb2@gmail.com \
--cc=gmaxwell@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox