From: onyxcoyote <dev@onyxcoyote.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork
Date: Sun, 9 Nov 2025 12:56:03 -0800 (PST) [thread overview]
Message-ID: <f14ac391-f85f-4af7-be11-d4c94ecc32d6n@googlegroups.com> (raw)
In-Reply-To: <5370ae82-7abe-4790-a1ab-e1a7334ef382@murch.one>
[-- Attachment #1.1: Type: text/plain, Size: 3220 bytes --]
Hi Dathon,
Thanks for posting the updated draft, and the removal of the emergency
activation path.
I have a few questions/comments/suggestions. I'm guessing they fit better
here than on github.
*Rule Changes-*
>it takes pains to avoid causing problems for all known use cases.
Regarding the 7 rule changes, confiscation risks, etc. I am suggesting you
to publish an analysis of each rule (or using a github repo for
collaboration on the same).
I am suggesting this in part because I don't have a deep understanding of
the potential use cases affected by each rule change. Having that
information in one place would be helpful for me and possibly other people
who are looking at this to give input or determine what risks exist.
Some ideas to include in the analysis are:
What percentage of transactions/fees would be made invalid by a rule?
Which major protocols or use cases could be affected by a rule?
Feedback/concerns received on specific rules.
Is there widespread agreement on any specific rules being less risky or
zero risk? Or ones which have more concerns than others?
Is there overlap with other proposals with any rules? Or conflicts with
proposals that might activate during the 1 year period?
*Activation-*
Many of my original comments about activation from github are still
relevant. But to keep it brief, there is one big disconnect I'm seeing on
the email chain here which is that there is an assumption about what
percent of miners/network would activate. I don't think that is a safe
assumption to make, especially with a flag day.
In trying to find a relevant comparison, I found this optech article which
states that mining pools, consisting of over 50% of hash rate, announced
support for taproot 4 months before the activation code was merged.
https://bitcoinops.org/en/newsletters/2020/11/25/?utm_source=chatgpt.com
In other words, it seems before the flag day was set, there was already a
very strong guarantee it would have majority miner support.
With that in mind, it also makes the proposed timeline seem quite short.
Does the timeline provide enough time to communicate, test, gain miner
consensus, etc.
*Reference Implementation-*
Thanks for sharing the reference implementation. I do have one concern...
that individuals might start running the reference code before it is
finalized or with varying start heights. I thought I was being overly
cautious, however, some individuals have already stated they intend to do
an emergency activation regardless of whether this proposal includes it.
I suggest adding a warning on the code, something like "running this code
before it has been finalized / without majority miner support would likely
result in incompatibility with the Bitcoin network and possible loss of
funds".
Thank you,
onyxcoyote
--
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/f14ac391-f85f-4af7-be11-d4c94ecc32d6n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 3735 bytes --]
next prev parent reply other threads:[~2025-11-09 23:35 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
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 [this message]
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=f14ac391-f85f-4af7-be11-d4c94ecc32d6n@googlegroups.com \
--to=dev@onyxcoyote.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