From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sun, 09 Nov 2025 15:35:57 -0800 Received: from mail-oa1-f60.google.com ([209.85.160.60]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vIEwu-0007u8-OI for bitcoindev@gnusha.org; Sun, 09 Nov 2025 15:35:57 -0800 Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-3c97be590afsf1262645fac.1 for ; Sun, 09 Nov 2025 15:35:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762731351; x=1763336151; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=TnMtG3nMhGar1Ldqj9soYHa4PasbdQoFOG/q7+ZU3b0=; b=Rd827MPKaggxmKGUIpzITmOnW+tJSbzJu+tXDVxXuT/tU/vFmbZ2F0Iw+Tkumg3Xcq psPFapAeEek6jJZSZwWNX4in34RIFKvuDZnVoUg5wVj18ya9njnXeeXJnJ+haSzOTCex 8cEuTNlonCnQLLR3ITNxbBCbiAISFPp5ITSCPwWnmxf729tBZ9cJ+PHAPepb6EnpWygH AjYgUdkjoK1XT1KP5ErD6mW5oGVguDZPs/B9wITYSL7p4Et8fiPqhR4X3OcjrIAy2US2 Ckkv/wXklGgFAjo4ni8Lp3jq2moteKGPLtDRXyT4p7Y8BW+gUK5/dXa7ZTWgBTtNzHwH Ttmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762731351; x=1763336151; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=TnMtG3nMhGar1Ldqj9soYHa4PasbdQoFOG/q7+ZU3b0=; b=NR1WYmwiMekXyheZdWch5uaxiggyRMl4Qy4Pn0l2cKeVqxdKVf2iKSE4AZw5y6phZI uIE7VJAwZzVi0DiTwy88nS8+dStTew/2o8CVSR2IwOpagmjCXnB508Ixz1g+WoE/+sWz Xzxpci0dbG6RhTsdWLSfcqJYZStZxrFlXFAJX/JA6Tt8kPxDMeF+31FhjdqwEMZeAqCC 5DAxss7279ehtKdx2iiBAeZylhN41NxtglSJJnHn+oTmxOuBwf+BiqaZ1AF+goVXvAxM XrG5VeLhCGdf3KJ83Zu2Y9Za3hdyUPQHmfiSwAYH6PjPJNUzc92XXtAO1kqdKr0QwP0q X7FQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCXWZlMxyTPHh3yLjRnEjh5jBMTr3ngsWDGEjHBaHlGIHhzJAJG7DiW05p6TPe19b0fZ8bNR1WNtbB/k@gnusha.org X-Gm-Message-State: AOJu0YxaVTm9hGqIi0648fAMFDTwxA/ka3yFYu4d2ZCeA0VxZ9qxnEOV KZzQA5kcAsIL/Ot/h+ILsOiHLU82Kx2kvFbc1Fw0BGZLpZJVvb7XObYi X-Google-Smtp-Source: AGHT+IGGFT8cTaTaSDrydSH6dNnVNQV56nMu/PAbrkiqsGbXl3xOnCpxT9hU+ev94y4lIL0qEY9Rgg== X-Received: by 2002:a05:6870:450c:b0:399:58c2:2e5b with SMTP id 586e51a60fabf-3e7c2c20376mr4205151fac.51.1762731350590; Sun, 09 Nov 2025 15:35:50 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+YtgXFcjz18ia2PtzMT+UkGl3CjUTJfpr4YKEFQwH95ew==" Received: by 2002:a05:6871:230f:b0:363:4ae7:c37f with SMTP id 586e51a60fabf-3e2f281d3b4ls1824623fac.0.-pod-prod-05-us; Sun, 09 Nov 2025 15:35:46 -0800 (PST) X-Received: by 2002:a05:6808:1649:b0:44f:e548:973d with SMTP id 5614622812f47-4502a1b2ad7mr3303549b6e.20.1762731346269; Sun, 09 Nov 2025 15:35:46 -0800 (PST) Received: by 2002:a05:690c:5c16:b0:780:f7eb:fdf with SMTP id 00721157ae682-786a51170c0ms7b3; Sun, 9 Nov 2025 12:56:07 -0800 (PST) X-Received: by 2002:a53:d008:0:b0:640:dd53:71aa with SMTP id 956f58d0204a3-640dd5375d6mr3107454d50.46.1762721764362; Sun, 09 Nov 2025 12:56:04 -0800 (PST) Date: Sun, 9 Nov 2025 12:56:03 -0800 (PST) From: onyxcoyote To: Bitcoin Development Mailing List Message-Id: In-Reply-To: <5370ae82-7abe-4790-a1ab-e1a7334ef382@murch.one> References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> <5370ae82-7abe-4790-a1ab-e1a7334ef382@murch.one> Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_150226_2064144251.1762721763855" X-Original-Sender: dev@onyxcoyote.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.7 (/) ------=_Part_150226_2064144251.1762721763855 Content-Type: multipart/alternative; boundary="----=_Part_150227_931651294.1762721763855" ------=_Part_150227_931651294.1762721763855 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_150227_931651294.1762721763855 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dathon,

Thanks for posting the updated draft, and the removal= of the emergency activation path.

I have a few questions/commen= ts/suggestions. I'm guessing they fit better here than on github.

Rule Changes-
>it takes pains to avoid causing problems fo= r all known use cases.
Regarding the 7 rule changes, confiscation risk= s, 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 thi= s in part because I don't have a deep understanding of the potential use ca= ses affected by each rule change. Having that information in one place woul= d be helpful for me and possibly other people who are looking at this to gi= ve input or determine what risks exist.

Some ideas to include in= the analysis are:
=C2=A0 =C2=A0 What percentage of transactions/fees = would be made invalid by a rule?
=C2=A0 =C2=A0 Which major protocols o= r use cases could be affected by a rule?
=C2=A0 =C2=A0 Feedback/concer= ns received on specific rules.
=C2=A0 =C2=A0 Is there widespread agree= ment on any specific rules being less risky or zero risk? Or ones which hav= e more concerns than others?
=C2=A0 =C2=A0 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 t= he 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 relevan= t comparison, I found this optech article which states that mining pools, c= onsisting of over 50% of hash rate, announced support for taproot 4 months = before the activation code was merged.
https://bitcoinops.org/en/newsl= etters/2020/11/25/?utm_source=3Dchatgpt.com

In other words, it s= eems before the flag day was set, there was already a very strong guarantee= it would have majority miner support.

With that in mind, it als= o makes the proposed timeline seem quite short. Does the timeline provide e= nough time to communicate, test, gain miner consensus, etc.

=C2= =A0 =C2=A0
Reference Implementation-
Thanks for sharing t= he reference implementation. I do have one concern... that individuals migh= t start running the reference code before it is finalized or with varying s= tart heights. I thought I was being overly cautious, however, some individu= als have already stated they intend to do an emergency activation regardles= s of whether this proposal includes it.

I suggest adding a warni= ng on the code, something like "running this code before it has been finali= zed / without majority miner support would likely result in incompatibility= with the Bitcoin network and possible loss of funds".


=C2= =A0 =C2=A0
Thank you,
onyxcoyote

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/f14ac391-f85f-4af7-be11-d4c94ecc32d6n%40googlegroups.com.
------=_Part_150227_931651294.1762721763855-- ------=_Part_150226_2064144251.1762721763855--