From: Daniel Buchner <danieljb2@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork
Date: Sat, 8 Nov 2025 08:40:25 -0800 (PST) [thread overview]
Message-ID: <c385373b-a307-43b3-b958-fadb5866e3d9n@googlegroups.com> (raw)
In-Reply-To: <CAAS2fgQy+qiRv=wGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3464 bytes --]
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.
[-- Attachment #1.2: Type: text/html, Size: 4067 bytes --]
next prev parent reply other threads:[~2025-11-08 16:43 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 [this message]
2025-11-08 17:55 ` Chris Riley
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=c385373b-a307-43b3-b958-fadb5866e3d9n@googlegroups.com \
--to=danieljb2@gmail.com \
--cc=bitcoindev@googlegroups.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