* [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork @ 2025-10-25 20:43 dathonohm via Bitcoin Development Mailing List 2025-10-26 20:47 ` Jameson Lopp 2025-10-26 22:27 ` Peter Todd 0 siblings, 2 replies; 30+ messages in thread From: dathonohm via Bitcoin Development Mailing List @ 2025-10-25 20:43 UTC (permalink / raw) To: bitcoindev [-- Attachment #1: Type: text/plain, Size: 1484 bytes --] Hi list - Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on [luke-jr's ML proposal](https://github.com/bitcoin/bips/pull/2017) to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections: https://github.com/bitcoin/bips/pull/2017 The idea is to strongly re-affirm in consensus that bitcoin is money, not data storage. It is implemented as a temporary softfork that can activate in one of two different ways: proactive, or reactive. After a year, the soft fork expires, giving us time to come up with a more permanent solution. The timeline is a bit tight, but I think everyone has incentives to support a quick and orderly activation. Please feel free to leave a comment on the PR or reach out to me over email with any feedback. There is much work still to do, so if you have some technical skills and would like to join in the effort with dev/testing, please reach out as well. Bitcoin is money. Sincerely, Dathon Ohm -- 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/AWiF9dIo9yjUF9RAs_NLwYdGK11BF8C8oEArR6Cys-rbcZ8_qs3RoJURqK3CqwCCWM_zwGFn5n3RECW_j5hGS01ntGzPLptqcOyOejunYsU%3D%40proton.me. [-- Attachment #2: Type: text/html, Size: 2890 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-10-25 20:43 [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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-26 22:27 ` Peter Todd 1 sibling, 1 reply; 30+ messages in thread From: Jameson Lopp @ 2025-10-26 20:47 UTC (permalink / raw) To: dathonohm; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 2657 bytes --] It's quite clear from the PR discussion that there are a multitude of contentious issues at play with this proposal. Even aside from all of the technical concerns, the underlying implication of using legal coercion to require miners and other network participants to comply with arbitrary legal and moral frameworks makes it a non-starter in my opinion. On Sun, Oct 26, 2025 at 3:43 PM dathonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote: > Hi list - > > Due to Bitcoin Core v30 gaining in popularity, it has become necessary to > move forward on luke-jr's ML proposal > <https://github.com/bitcoin/bips/pull/2017> to temporarily limit > arbitrary data at the consensus level, which so far has 3 weeks with no > objections: > https://github.com/bitcoin/bips/pull/2017 > > The idea is to strongly re-affirm in consensus that bitcoin is money, not > data storage. It is implemented as a temporary softfork that can activate > in one of two different ways: proactive, or reactive. > > After a year, the soft fork expires, giving us time to come up with a more > permanent solution. > > The timeline is a bit tight, but I think everyone has incentives to > support a quick and orderly activation. > > Please feel free to leave a comment on the PR or reach out to me over > email with any feedback. > > There is much work still to do, so if you have some technical skills and > would like to join in the effort with dev/testing, please reach out as well. > > Bitcoin is money. > > Sincerely, > > Dathon Ohm > > -- > 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/AWiF9dIo9yjUF9RAs_NLwYdGK11BF8C8oEArR6Cys-rbcZ8_qs3RoJURqK3CqwCCWM_zwGFn5n3RECW_j5hGS01ntGzPLptqcOyOejunYsU%3D%40proton.me > <https://groups.google.com/d/msgid/bitcoindev/AWiF9dIo9yjUF9RAs_NLwYdGK11BF8C8oEArR6Cys-rbcZ8_qs3RoJURqK3CqwCCWM_zwGFn5n3RECW_j5hGS01ntGzPLptqcOyOejunYsU%3D%40proton.me?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/CADL_X_caKFvypdDa2k-Hhy1QCMJgnb6Rc8i0vBRW9%3Dyoq4h2ZA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 4384 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 0 siblings, 2 replies; 30+ messages in thread From: dathonohm via Bitcoin Development Mailing List @ 2025-10-27 4:22 UTC (permalink / raw) To: Jameson Lopp; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 3644 bytes --] Jameson - You mention "technical concerns" but don't give any examples. Would you mind sharing one? You also mention "the underlying implication of using legal coercion to require miners and other network participants to comply with arbitrary legal and moral frameworks", but I don't think the BIP implies this at all. The BIP merely highlights a legal risk Bitcoin Core 30 has created for node operators for no good reason, and attempts to eliminate it. No "coercion" is implied. You and anyone else who are fine shouldering this risk are free to stay on the old data-friendly chain. I doubt you will have much company, though. Best, Dathon On Sunday, October 26th, 2025 at 2:49 PM, Jameson Lopp <jameson.lopp@gmail.com> wrote: > It's quite clear from the PR discussion that there are a multitude of contentious issues at play with this proposal. > > Even aside from all of the technical concerns, the underlying implication of using legal coercion to require miners and other network participants to comply with arbitrary legal and moral frameworks makes it a non-starter in my opinion. > > On Sun, Oct 26, 2025 at 3:43 PM dathonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote: > >> Hi list - >> >> Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on [luke-jr's ML proposal](https://github.com/bitcoin/bips/pull/2017) to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections: >> >> https://github.com/bitcoin/bips/pull/2017 >> >> The idea is to strongly re-affirm in consensus that bitcoin is money, not data storage. It is implemented as a temporary softfork that can activate in one of two different ways: proactive, or reactive. >> >> After a year, the soft fork expires, giving us time to come up with a more permanent solution. >> >> The timeline is a bit tight, but I think everyone has incentives to support a quick and orderly activation. >> >> Please feel free to leave a comment on the PR or reach out to me over email with any feedback. >> >> There is much work still to do, so if you have some technical skills and would like to join in the effort with dev/testing, please reach out as well. >> >> Bitcoin is money. >> >> Sincerely, >> >> Dathon Ohm >> >> -- >> 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/AWiF9dIo9yjUF9RAs_NLwYdGK11BF8C8oEArR6Cys-rbcZ8_qs3RoJURqK3CqwCCWM_zwGFn5n3RECW_j5hGS01ntGzPLptqcOyOejunYsU%3D%40proton.me. > > -- > 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/CADL_X_caKFvypdDa2k-Hhy1QCMJgnb6Rc8i0vBRW9%3Dyoq4h2ZA%40mail.gmail.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/eA2pBkwTzLHJAgRkYfvxwK13TW-wpY7r_pP1qpEauxuZuvNflEMj4sQvbtu4tgZ6Xdfu2BnxX_3EjK4TRzKc0R5gt1eWXvXb6nH9NW2CeGs%3D%40proton.me. [-- Attachment #2: Type: text/html, Size: 7549 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-10-27 4:22 ` dathonohm via Bitcoin Development Mailing List @ 2025-10-27 12:14 ` Jameson Lopp 2025-10-27 16:35 ` TheWrlck 1 sibling, 0 replies; 30+ messages in thread From: Jameson Lopp @ 2025-10-27 12:14 UTC (permalink / raw) To: dathonohm; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 4342 bytes --] On Mon, Oct 27, 2025 at 12:22 AM <dathonohm@proton.me> wrote: > Jameson - > > You mention "technical concerns" but don't give any examples. Would you > mind sharing one? > > Two of the biggest technical concerns are that the proposed changes are confiscatory for certain scripts and the fact that the reactive chain reorganization logic actually makes it possible for anyone to trivially double spend their coins by triggering a reorganization. > You also mention "the underlying implication of using legal coercion to > require miners and other network participants to comply with arbitrary > legal and moral frameworks", but I don't think the BIP implies this at all. > I quote the BIP: "rejecting this softfork may subject you to legal or moral consequences" This vague, hand waving fear mongering is the underlying implication of legal coercion to which I referred. It's not appropriate for a technical specification. > The BIP merely highlights a legal risk Bitcoin Core 30 has created for > node operators for no good reason, and attempts to eliminate it. No > "coercion" is implied. You and anyone else who are fine shouldering this > risk are free to stay on the old data-friendly chain. I doubt you will have > much company, though. > > Best, > > Dathon > > On Sunday, October 26th, 2025 at 2:49 PM, Jameson Lopp < > jameson.lopp@gmail.com> wrote: > > It's quite clear from the PR discussion that there are a multitude of > contentious issues at play with this proposal. > > Even aside from all of the technical concerns, the underlying implication > of using legal coercion to require miners and other network participants to > comply with arbitrary legal and moral frameworks makes it a non-starter in > my opinion. > > On Sun, Oct 26, 2025 at 3:43 PM dathonohm via Bitcoin Development Mailing > List <bitcoindev@googlegroups.com> wrote: > >> Hi list - >> >> Due to Bitcoin Core v30 gaining in popularity, it has become necessary to >> move forward on luke-jr's ML proposal >> <https://github.com/bitcoin/bips/pull/2017> to temporarily limit >> arbitrary data at the consensus level, which so far has 3 weeks with no >> objections: >> https://github.com/bitcoin/bips/pull/2017 >> >> The idea is to strongly re-affirm in consensus that bitcoin is money, not >> data storage. It is implemented as a temporary softfork that can activate >> in one of two different ways: proactive, or reactive. >> >> After a year, the soft fork expires, giving us time to come up with a >> more permanent solution. >> >> The timeline is a bit tight, but I think everyone has incentives to >> support a quick and orderly activation. >> >> Please feel free to leave a comment on the PR or reach out to me over >> email with any feedback. >> >> There is much work still to do, so if you have some technical skills and >> would like to join in the effort with dev/testing, please reach out as well. >> >> Bitcoin is money. >> >> Sincerely, >> >> Dathon Ohm >> >> -- >> 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/AWiF9dIo9yjUF9RAs_NLwYdGK11BF8C8oEArR6Cys-rbcZ8_qs3RoJURqK3CqwCCWM_zwGFn5n3RECW_j5hGS01ntGzPLptqcOyOejunYsU%3D%40proton.me >> . >> > -- > 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/CADL_X_caKFvypdDa2k-Hhy1QCMJgnb6Rc8i0vBRW9%3Dyoq4h2ZA%40mail.gmail.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/CADL_X_dLfJCai%3Dj9m3ARPitqmePd1mXqVLekqEprJ%3DYfYBdptA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 8802 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-10-27 4:22 ` dathonohm via Bitcoin Development Mailing List 2025-10-27 12:14 ` Jameson Lopp @ 2025-10-27 16:35 ` TheWrlck 1 sibling, 0 replies; 30+ messages in thread From: TheWrlck @ 2025-10-27 16:35 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 4422 bytes --] I’m not convinced that restricting or discouraging non-transactional data is the right approach. While limiting data size may reduce certain abuses, it also constrains legitimate use cases that leverage Bitcoin’s data-carrying capabilities (e.g. commitments, metadata, or novel protocols). From a consensus-layer perspective, Bitcoin should remain neutral about how data is interpreted or used, as long as it follows the defined rules and pays the required fees. Imposing normative judgments about "spam" risks introducing subjective policy where objective validation should suffice. Il giorno lunedì 27 ottobre 2025 alle 06:36:37 UTC+1 dath...@proton.me ha scritto: > Jameson - > > You mention "technical concerns" but don't give any examples. Would you > mind sharing one? > > You also mention "the underlying implication of using legal coercion to > require miners and other network participants to comply with arbitrary > legal and moral frameworks", but I don't think the BIP implies this at all. > > The BIP merely highlights a legal risk Bitcoin Core 30 has created for > node operators for no good reason, and attempts to eliminate it. No > "coercion" is implied. You and anyone else who are fine shouldering this > risk are free to stay on the old data-friendly chain. I doubt you will have > much company, though. > > Best, > > Dathon > > On Sunday, October 26th, 2025 at 2:49 PM, Jameson Lopp < > jameso...@gmail.com> wrote: > > It's quite clear from the PR discussion that there are a multitude of > contentious issues at play with this proposal. > > Even aside from all of the technical concerns, the underlying implication > of using legal coercion to require miners and other network participants to > comply with arbitrary legal and moral frameworks makes it a non-starter in > my opinion. > > On Sun, Oct 26, 2025 at 3:43 PM dathonohm via Bitcoin Development Mailing > List <bitco...@googlegroups.com> wrote: > >> Hi list - >> >> Due to Bitcoin Core v30 gaining in popularity, it has become necessary to >> move forward on luke-jr's ML proposal >> <https://github.com/bitcoin/bips/pull/2017> to temporarily limit >> arbitrary data at the consensus level, which so far has 3 weeks with no >> objections: >> https://github.com/bitcoin/bips/pull/2017 >> >> The idea is to strongly re-affirm in consensus that bitcoin is money, not >> data storage. It is implemented as a temporary softfork that can activate >> in one of two different ways: proactive, or reactive. >> >> After a year, the soft fork expires, giving us time to come up with a >> more permanent solution. >> >> The timeline is a bit tight, but I think everyone has incentives to >> support a quick and orderly activation. >> >> Please feel free to leave a comment on the PR or reach out to me over >> email with any feedback. >> >> There is much work still to do, so if you have some technical skills and >> would like to join in the effort with dev/testing, please reach out as well. >> >> Bitcoin is money. >> >> Sincerely, >> >> Dathon Ohm >> >> -- >> 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+...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/AWiF9dIo9yjUF9RAs_NLwYdGK11BF8C8oEArR6Cys-rbcZ8_qs3RoJURqK3CqwCCWM_zwGFn5n3RECW_j5hGS01ntGzPLptqcOyOejunYsU%3D%40proton.me >> . >> > -- > 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+...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CADL_X_caKFvypdDa2k-Hhy1QCMJgnb6Rc8i0vBRW9%3Dyoq4h2ZA%40mail.gmail.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/c81c7dc0-d96e-4d29-bbeb-6c06aba21ef7n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 9092 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-10-25 20:43 [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork dathonohm via Bitcoin Development Mailing List 2025-10-26 20:47 ` Jameson Lopp @ 2025-10-26 22:27 ` Peter Todd 2025-10-27 3:41 ` Jal Toorey 2025-10-27 4:08 ` dathonohm via Bitcoin Development Mailing List 1 sibling, 2 replies; 30+ messages in thread From: Peter Todd @ 2025-10-26 22:27 UTC (permalink / raw) To: dathonohm; +Cc: bitcoindev [-- Attachment #1: Type: text/plain, Size: 1184 bytes --] On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin Development Mailing List wrote: > Hi list - > > Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on [luke-jr's ML proposal](https://github.com/bitcoin/bips/pull/2017) to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections: > > https://github.com/bitcoin/bips/pull/2017 Transaction 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c contains the full text of this BIP as of writing(1), while simultaneously being compliant with that BIP. Clearly, this approach is ineffective. 1) https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki -- https://petertodd.org 'peter'[:-1]@petertodd.org -- 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/aP6gYSnte7J86g0p%40petertodd.org. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 1 sibling, 1 reply; 30+ messages in thread From: Jal Toorey @ 2025-10-27 3:41 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 1784 bytes --] "bitcoin is money" The definition of what is money is extremely subjective. The history of it shows this (not the history saifedean paints). Trying to direct the development to capture a definition of money opens a huge attack vector. It's not different than trying to decide what is spam. Also what is the difference between the bashers slogan that bitcoin is p2p money and "bitcoin is money" They seem like the same thing? On Sunday, October 26, 2025 at 3:43:26 PM UTC-7 Peter Todd wrote: > On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin > Development Mailing List wrote: > > Hi list - > > > > Due to Bitcoin Core v30 gaining in popularity, it has become necessary > to move forward on [luke-jr's ML proposal]( > https://github.com/bitcoin/bips/pull/2017) to temporarily limit arbitrary > data at the consensus level, which so far has 3 weeks with no objections: > > > > https://github.com/bitcoin/bips/pull/2017 > > Transaction > 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c > contains the full text of this BIP as of writing(1), while simultaneously > being > compliant with that BIP. > > Clearly, this approach is ineffective. > > 1) > https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > -- 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/5ddcfb0f-665e-4f0e-987e-80b9bb77ff5bn%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 3751 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-10-27 3:41 ` Jal Toorey @ 2025-10-27 17:27 ` Max 0 siblings, 0 replies; 30+ messages in thread From: Max @ 2025-10-27 17:27 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 3596 bytes --] Why don't we just quickly soft fork to disallow large OP_RETURN outputs (i.e. keep them capped to 80 bytes) only, with forward-looking activation (no retroactive block invalidation)? This would give the market a clear and simple way to decide whether such transactions are acceptable or not. It wouldn't have any of the issues mentioned so far in the discussion like creating an incentive to put CSAM or other illegal content to attempt a reorg double spend due to the complex deployment mechanism proposed in BIP-444 or like putting in jeopardy existing Taproot functionality by touching other primitives. We don't actually need to remove all the mechanisms that can be used for embedding data (which has been demonstrated to be impossible). Rather what we need is to give users the opportunity to signal whether arbitrary data is welcome or not. If the legal concerns are compelling enough to warrant consensus changes, miners should support a clean soft fork immediately. If the market quickly adopts the new consensus-level OP_RETURN restrictions it would announce sufficiently clearly to the world that arbitrary data is not welcome and deter future attempts to bring that to Bitcoin by showing the network's readiness to resist such efforts. I believe that this PR is too dramatic and needlessly complicated for what we need: letting the market decide whether to accept or reject the explicit invitation for arbitrary data storage that Core v30 has created. Technical changes should be limited to this question only and simple enough for people to make a decision without being distracted or overwhelmed by adjacent issues. On Monday, October 27, 2025 at 10:53:31 AM UTC-6 Jal Toorey wrote: > "bitcoin is money" > > The definition of what is money is extremely subjective. The history of > it shows this (not the history saifedean paints). Trying to direct the > development to capture a definition of money opens a huge attack vector. > It's not different than trying to decide what is spam. > > Also what is the difference between the bashers slogan that bitcoin is p2p > money and "bitcoin is money" They seem like the same thing? > On Sunday, October 26, 2025 at 3:43:26 PM UTC-7 Peter Todd wrote: > >> On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin >> Development Mailing List wrote: >> > Hi list - >> > >> > Due to Bitcoin Core v30 gaining in popularity, it has become necessary >> to move forward on [luke-jr's ML proposal]( >> https://github.com/bitcoin/bips/pull/2017) to temporarily limit >> arbitrary data at the consensus level, which so far has 3 weeks with no >> objections: >> > >> > https://github.com/bitcoin/bips/pull/2017 >> >> Transaction >> 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c >> contains the full text of this BIP as of writing(1), while simultaneously >> being >> compliant with that BIP. >> >> Clearly, this approach is ineffective. >> >> 1) >> https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki >> >> -- >> https://petertodd.org 'peter'[:-1]@petertodd.org >> > -- 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/2774a0b5-fd65-494b-ac23-f3726754eda7n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 5688 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-10-26 22:27 ` Peter Todd 2025-10-27 3:41 ` Jal Toorey @ 2025-10-27 4:08 ` dathonohm via Bitcoin Development Mailing List 2025-10-27 18:29 ` Kyle Stout 1 sibling, 1 reply; 30+ messages in thread From: dathonohm via Bitcoin Development Mailing List @ 2025-10-27 4:08 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoindev Peter - Thank you for demonstrating what non-contiguous data looks like. I trust you when you say that you can parse the BIP's contents from this transaction, but all it looks like to me (and the Bitcoin network) is a UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-length OP_RETURN, sending all ~100 USD in fees to the miner. Since legally hazardous content can be generated from any input data, including your 30-input consolidation transaction (as long as the correct third-party program is used), it would not make sense to hold node operators legally responsible for storing and distributing such input data. However, if Bitcoin provides an officially supported method of storing arbitrary data (i.e., OP_RETURN), and the capacity of that method is large enough to store hazardous content in a contiguous format (an increase to 100kB is currently underway as Bitcoin Core 30 gains adoption), then one does not need to misinterpret the data in order to view the content. In that case, node operators could conceivably be held responsible for possession and distribution. Since arbitrary data storage does nothing to benefit Bitcoin as permissionless money, there is no good reason to force this additional legal risk on node operators, who already face enough challenges as it is. Best, Dathon On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd <pete@petertodd.org> wrote: > On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin Development Mailing List wrote: > > > Hi list - > > > > Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on luke-jr's ML proposal to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections: > > > > https://github.com/bitcoin/bips/pull/2017 > > > Transaction 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c > contains the full text of this BIP as of writing(1), while simultaneously being > compliant with that BIP. > > Clearly, this approach is ineffective. > > 1) https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > > -- > 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/aP6gYSnte7J86g0p%40petertodd.org. -- 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/7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w%3D%40proton.me. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 0 siblings, 1 reply; 30+ messages in thread From: Kyle Stout @ 2025-10-27 18:29 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 5303 bytes --] Dathon, > if Bitcoin provides an officially supported method of storing arbitrary data (i.e., OP_RETURN), and the capacity of that method is large enough to store hazardous content in a contiguous format (an increase to 100kB is currently underway as Bitcoin Core 30 gains adoption), then one does not need to misinterpret the data in order to view the content. This seems to be the crux of your argument. I believe it is misleading and technically unsound. It's technical theater that creates a distinction without any meaningful difference. First, Bitcoin has no concept of a file viewer. To interpret *any* embedded data other to validate it against Bitcoin's rules, you must use a third party tool. Practically speaking, the differences are negligible in terms of technical difficulty, as humorously demonstrated here: https://x.com/rot13maxi/status/1963318690759192622 . Contiguous or not, you're file carving. Second, by definition, you're misinterpreting the data vis-a-vis Bitcoin since it has no native concept of 'image', 'video', etc. Arbitrary bytes are meaningless. The purpose of having OP_RETURN as a standard output is to protect the UTXO set from being abused. It isn't some kind of 'blessing' to store files. That's absurd. As you admit, it's impossible to stop people from writing arbitrary bytes to the blockchain, so this is damage mitigation, not an invitation. Third, contiguity is not a legally meaningful predicate. "Your honor, we tried to limit the contiguous bytes!" is simply not going to fly. The bytes exist either way, and they must be interpreted by third party software either way. If anything, this path is going to represent a voluntary self-policing that will result in more culpability. Right now, arbitrary bytes don't mean anything in Bitcoin. If it's valid, it's valid. Nodes relay opaque protocol data. If you insist on only accepting 'approved' arbitrary bytes, you're opening the door to a knowledge/intent accusation. Regards, Kyle On Monday, October 27, 2025 at 1:36:33 AM UTC-4 dath...@proton.me wrote: > Peter - > > Thank you for demonstrating what non-contiguous data looks like. > > I trust you when you say that you can parse the BIP's contents from this > transaction, but all it looks like to me (and the Bitcoin network) is a > UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-length > OP_RETURN, sending all ~100 USD in fees to the miner. > > Since legally hazardous content can be generated from any input data, > including your 30-input consolidation transaction (as long as the correct > third-party program is used), it would not make sense to hold node > operators legally responsible for storing and distributing such input data. > > However, if Bitcoin provides an officially supported method of storing > arbitrary data (i.e., OP_RETURN), and the capacity of that method is large > enough to store hazardous content in a contiguous format (an increase to > 100kB is currently underway as Bitcoin Core 30 gains adoption), then one > does not need to misinterpret the data in order to view the content. In > that case, node operators could conceivably be held responsible for > possession and distribution. > > Since arbitrary data storage does nothing to benefit Bitcoin as > permissionless money, there is no good reason to force this additional > legal risk on node operators, who already face enough challenges as it is. > > Best, > > Dathon > > > On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd <pe...@petertodd.org> > wrote: > > > On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin > Development Mailing List wrote: > > > > > Hi list - > > > > > > Due to Bitcoin Core v30 gaining in popularity, it has become necessary > to move forward on luke-jr's ML proposal to temporarily limit arbitrary > data at the consensus level, which so far has 3 weeks with no objections: > > > > > > https://github.com/bitcoin/bips/pull/2017 > > > > > > Transaction > 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c > > contains the full text of this BIP as of writing(1), while > simultaneously being > > compliant with that BIP. > > > > Clearly, this approach is ineffective. > > > > 1) > https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki > > > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > > > -- > > 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+...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40petertodd.org > . > -- 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/7abf7055-6b85-492f-ada2-e0a517e93cf9n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 7611 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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-28 9:16 ` /dev /fd0 0 siblings, 2 replies; 30+ messages in thread From: Greg Maxwell @ 2025-10-27 19:56 UTC (permalink / raw) To: Kyle Stout; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 7334 bytes --] The only consensus normative data encoding in Bitcoin is the order data goes into hashes. The representations in memory, rpc, in the p2p network, etc. are already different and could be made arbitrarily different without any consensus change. Case in point: the data is now normally encrypted on disk and in P2P. There are also proposals such as BIP 337: https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki none of these things are consensus changes-- many aren't even bippable because they don't have interoperability considerations (e.g. representations on disk/memory). Forget for a moment the (un)likelyhood that the concerns being discussed are meaningfully modulated by exactly how data is represented in p2p, memory, rpc, disk, etc.. for assumption just assume they are. If so, the correct move would be to change those encodings rather than any consensus rule change--- particularly because any consensus rule method will simply be evaded, and can't provide the level of swizzling that changing the encoding can accomplish. Encoding changes are also substantially non-coercive: people who think they're valuable can adopt them and leave other people alone. Good news for everyone except those who consider coercing others to be a terminal goal. On Mon, Oct 27, 2025 at 6:35 PM Kyle Stout <kylestout85@gmail.com> wrote: > Dathon, > > > if Bitcoin provides an officially supported method of storing arbitrary > data (i.e., OP_RETURN), and the capacity of that method is large enough to > store hazardous content in a contiguous format (an increase to 100kB is > currently underway as Bitcoin Core 30 gains adoption), then one does not > need to misinterpret the data in order to view the content. > > This seems to be the crux of your argument. I believe it is misleading and > technically unsound. It's technical theater that creates a distinction > without any meaningful difference. > > First, Bitcoin has no concept of a file viewer. To interpret *any* > embedded data other to validate it against Bitcoin's rules, you must use a > third party tool. Practically speaking, the differences are negligible in > terms of technical difficulty, as humorously demonstrated here: > https://x.com/rot13maxi/status/1963318690759192622 . Contiguous or not, > you're file carving. > > Second, by definition, you're misinterpreting the data vis-a-vis Bitcoin > since it has no native concept of 'image', 'video', etc. Arbitrary bytes > are meaningless. The purpose of having OP_RETURN as a standard output is to > protect the UTXO set from being abused. It isn't some kind of 'blessing' to > store files. That's absurd. As you admit, it's impossible to stop people > from writing arbitrary bytes to the blockchain, so this is damage > mitigation, not an invitation. > > Third, contiguity is not a legally meaningful predicate. "Your honor, we > tried to limit the contiguous bytes!" is simply not going to fly. The bytes > exist either way, and they must be interpreted by third party software > either way. If anything, this path is going to represent a voluntary > self-policing that will result in more culpability. Right now, arbitrary > bytes don't mean anything in Bitcoin. If it's valid, it's valid. Nodes > relay opaque protocol data. If you insist on only accepting 'approved' > arbitrary bytes, you're opening the door to a knowledge/intent accusation. > > Regards, > > Kyle > > > > On Monday, October 27, 2025 at 1:36:33 AM UTC-4 dath...@proton.me wrote: > >> Peter - >> >> Thank you for demonstrating what non-contiguous data looks like. >> >> I trust you when you say that you can parse the BIP's contents from this >> transaction, but all it looks like to me (and the Bitcoin network) is a >> UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-length >> OP_RETURN, sending all ~100 USD in fees to the miner. >> >> Since legally hazardous content can be generated from any input data, >> including your 30-input consolidation transaction (as long as the correct >> third-party program is used), it would not make sense to hold node >> operators legally responsible for storing and distributing such input data. >> >> However, if Bitcoin provides an officially supported method of storing >> arbitrary data (i.e., OP_RETURN), and the capacity of that method is large >> enough to store hazardous content in a contiguous format (an increase to >> 100kB is currently underway as Bitcoin Core 30 gains adoption), then one >> does not need to misinterpret the data in order to view the content. In >> that case, node operators could conceivably be held responsible for >> possession and distribution. >> >> Since arbitrary data storage does nothing to benefit Bitcoin as >> permissionless money, there is no good reason to force this additional >> legal risk on node operators, who already face enough challenges as it is. >> >> Best, >> >> Dathon >> >> >> On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd <pe...@petertodd.org> >> wrote: >> >> > On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin >> Development Mailing List wrote: >> > >> > > Hi list - >> > > >> > > Due to Bitcoin Core v30 gaining in popularity, it has become >> necessary to move forward on luke-jr's ML proposal to temporarily limit >> arbitrary data at the consensus level, which so far has 3 weeks with no >> objections: >> > > >> > > https://github.com/bitcoin/bips/pull/2017 >> > >> > >> > Transaction >> 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c >> > contains the full text of this BIP as of writing(1), while >> simultaneously being >> > compliant with that BIP. >> > >> > Clearly, this approach is ineffective. >> > >> > 1) >> https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki >> > >> > -- >> > https://petertodd.org 'peter'[:-1]@petertodd.org >> > >> > -- >> > 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+...@googlegroups.com. >> > To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40petertodd.org. >> >> > -- > 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/7abf7055-6b85-492f-ada2-e0a517e93cf9n%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/7abf7055-6b85-492f-ada2-e0a517e93cf9n%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/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 9347 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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-28 9:16 ` /dev /fd0 1 sibling, 1 reply; 30+ messages in thread From: dathonohm via Bitcoin Development Mailing List @ 2025-10-28 5:13 UTC (permalink / raw) To: Greg Maxwell; +Cc: Kyle Stout, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 7880 bytes --] Hi list - Thanks for all of the feedback everyone! I am working on a new draft of the BIP that will hopefully address everyone's concerns and avoid the misunderstandings that have arisen. I apologize for not being able to respond to all of you, but know that I did indeed read your messages. Best, Dathon On Monday, October 27th, 2025 at 1:58 PM, Greg Maxwell <gmaxwell@gmail.com> wrote: > The only consensus normative data encoding in Bitcoin is the order data goes into hashes. The representations in memory, rpc, in the p2p network, etc. are already different and could be made arbitrarily different without any consensus change. Case in point: the data is now normally encrypted on disk and in P2P. There are also proposals such as BIP 337: https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki none of these things are consensus changes-- many aren't even bippable because they don't have interoperability considerations (e.g. representations on disk/memory). > > Forget for a moment the (un)likelyhood that the concerns being discussed are meaningfully modulated by exactly how data is represented in p2p, memory, rpc, disk, etc.. for assumption just assume they are. > > If so, the correct move would be to change those encodings rather than any consensus rule change--- particularly because any consensus rule method will simply be evaded, and can't provide the level of swizzling that changing the encoding can accomplish. Encoding changes are also substantially non-coercive: people who think they're valuable can adopt them and leave other people alone. > > Good news for everyone except those who consider coercing others to be a terminal goal. > > On Mon, Oct 27, 2025 at 6:35 PM Kyle Stout <kylestout85@gmail.com> wrote: > >> Dathon, >> >>> if Bitcoin provides an officially supported method of storing arbitrary data (i.e., OP_RETURN), and the capacity of that method is large enough to store hazardous content in a contiguous format (an increase to 100kB is currently underway as Bitcoin Core 30 gains adoption), then one does not need to misinterpret the data in order to view the content. >> >> This seems to be the crux of your argument. I believe it is misleading and technically unsound. It's technical theater that creates a distinction without any meaningful difference. >> >> First, Bitcoin has no concept of a file viewer. To interpret any embedded data other to validate it against Bitcoin's rules, you must use a third party tool. Practically speaking, the differences are negligible in terms of technical difficulty, as humorously demonstrated here: https://x.com/rot13maxi/status/1963318690759192622 . Contiguous or not, you're file carving. >> >> Second, by definition, you're misinterpreting the data vis-a-vis Bitcoin since it has no native concept of 'image', 'video', etc. Arbitrary bytes are meaningless. The purpose of having OP_RETURN as a standard output is to protect the UTXO set from being abused. It isn't some kind of 'blessing' to store files. That's absurd. As you admit, it's impossible to stop people from writing arbitrary bytes to the blockchain, so this is damage mitigation, not an invitation. >> >> Third, contiguity is not a legally meaningful predicate. "Your honor, we tried to limit the contiguous bytes!" is simply not going to fly. The bytes exist either way, and they must be interpreted by third party software either way. If anything, this path is going to represent a voluntary self-policing that will result in more culpability. Right now, arbitrary bytes don't mean anything in Bitcoin. If it's valid, it's valid. Nodes relay opaque protocol data. If you insist on only accepting 'approved' arbitrary bytes, you're opening the door to a knowledge/intent accusation. >> >> Regards, >> >> Kyle >> >> On Monday, October 27, 2025 at 1:36:33 AM UTC-4 dath...@proton.me wrote: >> >>> Peter - >>> >>> Thank you for demonstrating what non-contiguous data looks like. >>> >>> I trust you when you say that you can parse the BIP's contents from this transaction, but all it looks like to me (and the Bitcoin network) is a UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-length OP_RETURN, sending all ~100 USD in fees to the miner. >>> >>> Since legally hazardous content can be generated from any input data, including your 30-input consolidation transaction (as long as the correct third-party program is used), it would not make sense to hold node operators legally responsible for storing and distributing such input data. >>> >>> However, if Bitcoin provides an officially supported method of storing arbitrary data (i.e., OP_RETURN), and the capacity of that method is large enough to store hazardous content in a contiguous format (an increase to 100kB is currently underway as Bitcoin Core 30 gains adoption), then one does not need to misinterpret the data in order to view the content. In that case, node operators could conceivably be held responsible for possession and distribution. >>> >>> Since arbitrary data storage does nothing to benefit Bitcoin as permissionless money, there is no good reason to force this additional legal risk on node operators, who already face enough challenges as it is. >>> >>> Best, >>> >>> Dathon >>> >>> On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd <pe...@petertodd.org> wrote: >>> >>>> On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin Development Mailing List wrote: >>>> >>>> > Hi list - >>>> > >>>> > Due to Bitcoin Core v30 gaining in popularity, it has become necessary to move forward on luke-jr's ML proposal to temporarily limit arbitrary data at the consensus level, which so far has 3 weeks with no objections: >>>> > >>>> > https://github.com/bitcoin/bips/pull/2017 >>>> >>>> >>>> Transaction 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c >>>> contains the full text of this BIP as of writing(1), while simultaneously being >>>> compliant with that BIP. >>>> >>>> Clearly, this approach is ineffective. >>>> >>>> 1) https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki >>>> >>>> -- >>>> https://petertodd.org 'peter'[:-1]@petertodd.org >>>> >>>> -- >>>> 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+...@googlegroups.com. >>>> To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40petertodd.org. >> >> -- >> 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/7abf7055-6b85-492f-ada2-e0a517e93cf9n%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/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.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/XFyaw5Bf4-4bAO3wBt3Wk2aSclxSGQ8n-uT4BR6ga864yMCf5Fe-xFQ8VnlYHH6bQ3s5jSQrfs02E-MNJbAXVmq3_vlQpgNcsOmiYTFwmcg%3D%40proton.me. [-- Attachment #2: Type: text/html, Size: 12243 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 0 siblings, 1 reply; 30+ messages in thread From: Antoine Riard @ 2025-10-30 0:31 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 12245 bytes --] Hi Dathon Ohm, I did a cursory review of your BIP proposal, not on the technical matter as there is no reference implementation available, but I did one on the legalities raised in the text (grep'ing the word "legal" one can find 15 references versus only 2 references to the word "technical"). Under European law, there is a clearly established line of jurisprudences exonerating internet service providers or hosting operators to have to install a system for filtering all electronic communications passing via its services which would apply indiscriminately to all its users for any kind of content (CJUE, 24-11-2011, aff C-70/10 Scarlet Extended SA c/ SABAM, CJUE, 16-02-2012, aff C-260/10 SABAM c/ Netlog). Rather to engage in generic filtering on the burden of services providers, courts have generally yielded decisions asking for fine-grained deletion of a specific content, as a safeguard of other interest at stake, notably users's right to privacy [0]. Further, in the eventuality of an extended filtering system would have to be put in place by a service provider, and if said filtering system design would be unable to dissociate between legal content and illegal content, the introduction of this filtering system would consistute an infringement of the freedom of expression and information (CJUE, 26-04-2022, aff C‑401/19). Those judicial decisions are litteraly encompassing peer-to-peer softwares in their scope, as somehow before Bitcoin, they was something called Bittorent. Moreover, this line of jurisprudence underlights that any interference with one's fundamental right of expression should be lay down under clear and precise rules governing the scope of the interference. This is not a mere formality, as again and again too restrictives measures are strike down (CEDH, 02-02-2016, Index.hu/Hungary, aff. n° 22947/13). As far as I know, I'm not aware of any European continental country that has made a legislation on how one is allowed to use his right to the freedom of expression in the context of publishing stuff in a Bitcoin block. Under the US law, I won't risk making legal comment for now, as for anyone who is following the work of the Electronic Frontier Foundation from times to times, there is a pending case in front of the US Supreme Court, Cox Communications, Inc vs. Sony Music Entertainment specifically on the liability of Internet service providers. But culturally the US are even more protective on the freedom of expression, which puts an even higher legal bar for any restriction of it. I concur with Gregory Maxwell. There is zero need to change the consensus rules. In the idea one would like to limit one's responsability arising from how bitcoin consensus data can be encoded or decoded to "obviously" "illegal" content (as strictly defined by a specific national legislation) [1], fuzzy encoders and decoders for end-to-end or point-to-point communication could be formalized as BIP documents, that would put an asymmetric cost on the decoders, with the upper bound being the impossibility of decoding. Fuzzy algorithms is not sci-fi tech it's actually what is used for Minisketch. Best, Antoine OTS hash: f0e10776d4e4d32873ca319daf3b76c8e645a0d510a6bb803bb8685292c119d4 [0] "Those addresses are protected personal data because they allow those users to be precisely identified" [1] This is not a mere technicality, under information theory, one could come up with a alphanumeric encoding algorithm that could certainly yield text-based religious blaspheme in a lot of countries in the world from years-old un-reorgable historical blockchain data. We're all used to "The Times 03 Jan..." in the genesis block, but it's just picking hex as a decoding algorithm... Le mardi 28 octobre 2025 à 05:14:47 UTC, dath...@proton.me a écrit : > Hi list - > > Thanks for all of the feedback everyone! > > I am working on a new draft of the BIP that will hopefully address > everyone's concerns and avoid the misunderstandings that have arisen. > > I apologize for not being able to respond to all of you, but know that I > did indeed read your messages. > > Best, > > Dathon > On Monday, October 27th, 2025 at 1:58 PM, Greg Maxwell <gmax...@gmail.com> > wrote: > > The only consensus normative data encoding in Bitcoin is the order data > goes into hashes. The representations in memory, rpc, in the p2p network, > etc. are already different and could be made arbitrarily different without > any consensus change. Case in point: the data is now normally encrypted on > disk and in P2P. There are also proposals such as BIP 337: > https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki none of > these things are consensus changes-- many aren't even bippable because they > don't have interoperability considerations (e.g. representations on > disk/memory). > > Forget for a moment the (un)likelyhood that the concerns being discussed > are meaningfully modulated by exactly how data is represented in p2p, > memory, rpc, disk, etc.. for assumption just assume they are. > > If so, the correct move would be to change those encodings rather than any > consensus rule change--- particularly because any consensus rule method > will simply be evaded, and can't provide the level of swizzling that > changing the encoding can accomplish. Encoding changes are also > substantially non-coercive: people who think they're valuable can adopt > them and leave other people alone. > > Good news for everyone except those who consider coercing others to be a > terminal goal. > > > > On Mon, Oct 27, 2025 at 6:35 PM Kyle Stout <kyles...@gmail.com> wrote: > >> Dathon, >> >> > if Bitcoin provides an officially supported method of storing arbitrary >> data (i.e., OP_RETURN), and the capacity of that method is large enough to >> store hazardous content in a contiguous format (an increase to 100kB is >> currently underway as Bitcoin Core 30 gains adoption), then one does not >> need to misinterpret the data in order to view the content. >> >> This seems to be the crux of your argument. I believe it is misleading >> and technically unsound. It's technical theater that creates a distinction >> without any meaningful difference. >> >> First, Bitcoin has no concept of a file viewer. To interpret *any* >> embedded data other to validate it against Bitcoin's rules, you must use a >> third party tool. Practically speaking, the differences are negligible in >> terms of technical difficulty, as humorously demonstrated here: >> https://x.com/rot13maxi/status/1963318690759192622 . Contiguous or not, >> you're file carving. >> >> Second, by definition, you're misinterpreting the data vis-a-vis Bitcoin >> since it has no native concept of 'image', 'video', etc. Arbitrary bytes >> are meaningless. The purpose of having OP_RETURN as a standard output is to >> protect the UTXO set from being abused. It isn't some kind of 'blessing' to >> store files. That's absurd. As you admit, it's impossible to stop people >> from writing arbitrary bytes to the blockchain, so this is damage >> mitigation, not an invitation. >> >> Third, contiguity is not a legally meaningful predicate. "Your honor, we >> tried to limit the contiguous bytes!" is simply not going to fly. The bytes >> exist either way, and they must be interpreted by third party software >> either way. If anything, this path is going to represent a voluntary >> self-policing that will result in more culpability. Right now, arbitrary >> bytes don't mean anything in Bitcoin. If it's valid, it's valid. Nodes >> relay opaque protocol data. If you insist on only accepting 'approved' >> arbitrary bytes, you're opening the door to a knowledge/intent accusation. >> >> Regards, >> >> Kyle >> >> >> >> On Monday, October 27, 2025 at 1:36:33 AM UTC-4 dath...@proton.me wrote: >> >>> Peter - >>> >>> Thank you for demonstrating what non-contiguous data looks like. >>> >>> I trust you when you say that you can parse the BIP's contents from this >>> transaction, but all it looks like to me (and the Bitcoin network) is a >>> UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-length >>> OP_RETURN, sending all ~100 USD in fees to the miner. >>> >>> Since legally hazardous content can be generated from any input data, >>> including your 30-input consolidation transaction (as long as the correct >>> third-party program is used), it would not make sense to hold node >>> operators legally responsible for storing and distributing such input data. >>> >>> However, if Bitcoin provides an officially supported method of storing >>> arbitrary data (i.e., OP_RETURN), and the capacity of that method is large >>> enough to store hazardous content in a contiguous format (an increase to >>> 100kB is currently underway as Bitcoin Core 30 gains adoption), then one >>> does not need to misinterpret the data in order to view the content. In >>> that case, node operators could conceivably be held responsible for >>> possession and distribution. >>> >>> Since arbitrary data storage does nothing to benefit Bitcoin as >>> permissionless money, there is no good reason to force this additional >>> legal risk on node operators, who already face enough challenges as it is. >>> >>> Best, >>> >>> Dathon >>> >>> >>> On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd < >>> pe...@petertodd.org> wrote: >>> >>> > On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin >>> Development Mailing List wrote: >>> > >>> > > Hi list - >>> > > >>> > > Due to Bitcoin Core v30 gaining in popularity, it has become >>> necessary to move forward on luke-jr's ML proposal to temporarily limit >>> arbitrary data at the consensus level, which so far has 3 weeks with no >>> objections: >>> > > >>> > > https://github.com/bitcoin/bips/pull/2017 >>> > >>> > >>> > Transaction >>> 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c >>> > contains the full text of this BIP as of writing(1), while >>> simultaneously being >>> > compliant with that BIP. >>> > >>> > Clearly, this approach is ineffective. >>> > >>> > 1) >>> https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki >>> > >>> > -- >>> > https://petertodd.org 'peter'[:-1]@petertodd.org >>> > >>> > -- >>> > 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+...@googlegroups.com. >>> > To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40petertodd.org. >>> >>> >> -- >> 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+...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/7abf7055-6b85-492f-ada2-e0a517e93cf9n%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+...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.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/f07bc89c-fcf0-4e3c-85ab-593a509c1265n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 18233 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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-10 19:46 ` Lucas Barbosa 0 siblings, 2 replies; 30+ messages in thread From: Erik Aronesty @ 2025-10-30 2:43 UTC (permalink / raw) To: Antoine Riard; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 1449 bytes --] > > > Case law in the USA regarding illegal content has always rested squarely > on those who: 1 - provide broad public access, in this case a company like OpenSEA (which has had to block content) 2 - the original author if punishing "relays" was a thing, then every CISCO router, SMTP relay and DISCORD server that provided access would be in court all day long instead, it's the users of the illegal data and the publishers that actually wind up in trouble - not the internet providers the bitcoin ledger is neither a browser or web server, nor is it an image uploader. there is zero ability to view images built into the system and even if it was the purpose of this software is to be a distributed and effectively uncensorable ledger. hopefully it doesn't change because someone launched a meme campaign with vague threats of legal action if a transaction has /no reasonable expectation of being mined/ (too expensive to validate, too large, too low fees), there's also no reason to relay it this is probably the best way to set policy -- 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/CAJowKgKBBa%2BvD%3D5X0VMV2OFiBBM23Ok6nmvfoLTr8fia141%3DFQ%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 2082 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 ` (3 more replies) 2025-11-10 19:46 ` Lucas Barbosa 1 sibling, 4 replies; 30+ messages in thread From: dathonohm via Bitcoin Development Mailing List @ 2025-11-08 0:51 UTC (permalink / raw) To: Erik Aronesty; +Cc: Antoine Riard, Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 5122 bytes --] Hi all - BIP repo maintainers [requested](https://github.com/bitcoin/bips/pull/2017#issuecomment-3462134337) that I update this list before pushing a significant change, so I am doing that now. Please consider this my formal request for the BIP PR to be unlocked so that discussion can resume. This update addresses several concerns from the previous draft: - "Funds confiscation": due to the presence of UTXOs that would be made temporarily unspendable by this proposal, commenters were concerned that this would set a precedent of "confiscation". This new draft resolves this concern by adding a UTXO height check to make sure only UTXOs that are created while the softfork is active will be made temporarily unspendable. The "OP_IF in Tapscript" and "257-byte control block limit" were the two main proposed rule changes that caused concern here. - "This doesn't block all possible methods of arbitrary data insertion": This was already addressed in the previous draft, but to reiterate: this proposal's goal is not to block all methods of arbitary data insertion, just the most commonly abused ones. - "Blocks other softfork upgrades while active": This was also addressed in the original draft, but to reiterate: it's unlikely that any softfork upgrades will be ready to activate within one year anyway, so this doesn't matter much. But also, the fact that this softfork expires creates an opportunity to activate a more permanent and elegant upgrade that turns on what the community wants, while continuing to reject data storage as a supported use case, after one year. - "Reactive deployment risks": These concerns have been addressed by removing the reactive deployment method entirely. I still think activating this softfork is a matter of some urgency, but I think it still achieves its goals if we move steadily towards activation within a few months. - "Missing code": The code is now public here: https://github.com/UASF/bitcoin/tree/29.2.knots20251010%2BBIP444 (please note that, while there are references to "BIP-444" in the code, that is just a placeholder and I will update it to whatever number the BIP editors decide). - "Temporary expiry risks": "Requires another consensus change before expiry or rules lapse": Yes, as stated in <3>, the community will have to come together in a year either to extend these rules (which shouldn't be difficult), or to activate something more permanent and less blunt. The expiry will not be a hardfork, contrary to some claims I've seen, because opting into this deployment means opting into the expiry as well, so old nodes will follow new ones onto the unrestricted chain - "Legal/process/conflict-of-interest concerns": all language about legal risks has been stripped from the BIP. I welcome any and all feedback, as I think this proposal or something similar to it stands an excellent chance of gaining consensus and activating, and I think if that happens, it could be curative for the Bitcoin community. Thanks again for all of your feedback and support, it means a lot. Sincerely, Dathon On Wednesday, October 29th, 2025 at 8:57 PM, Erik Aronesty <erik@q32.com> wrote: >> Case law in the USA regarding illegal content has always rested squarely on those who: > > 1 - provide broad public access, in this case a company like OpenSEA (which has had to block content) > 2 - the original author > > if punishing "relays" was a thing, then every CISCO router, SMTP relay and DISCORD server that provided access would be in court all day long > > instead, it's the users of the illegal data and the publishers that actually wind up in trouble - not the internet providers > > the bitcoin ledger is neither a browser or web server, nor is it an image uploader. there is zero ability to view images built into the system > > and even if it was > > the purpose of this software is to be a distributed and effectively uncensorable ledger. > > hopefully it doesn't change because someone launched a meme campaign with vague threats of legal action > > if a transaction has /no reasonable expectation of being mined/ (too expensive to validate, too large, too low fees), there's also no reason to relay it > > this is probably the best way to set policy > > -- > 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/CAJowKgKBBa%2BvD%3D5X0VMV2OFiBBM23Ok6nmvfoLTr8fia141%3DFQ%40mail.gmail.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/bJL7UshcsXUpiQiC85dQeafQrRvtovH1aRcUxggjD1S09Md9qWHi9GpJOBdcPGq2NNQMK2XK-REMVlWjHLkh3aKUIktnYQccUWqg0DHgNXc%3D%40proton.me. [-- Attachment #1.2: Type: text/html, Size: 8190 bytes --] [-- Attachment #2: bip-????.mediawiki --] [-- Type: application/octet-stream, Size: 16887 bytes --] <pre> BIP: ? Layer: Consensus (soft fork) Title: Reduced Data Temporary Softfork Author: Dathon Ohm <dathonohm+bip@proton.me> Comments-Summary: No comments yet. Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-? Status: Draft Type: Standards Track Created: 2025-10-24 License: BSD-3-Clause Post-History: https://gnusha.org/pi/bitcoindev/aN_u-xB2ogn2D834@erisian.com.au/T/#mb71350c5dfb119efeb92c5ee738b6c8225bf15b6 </pre> ==Abstract== Temporarily limit the size of data fields at the consensus level. ==Copyright== This document is licensed under the 3-clause BSD license. ==Specification== Blocks with a height from 934864 until and including 987424 are checked with these additional rules: # New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid. # OP_PUSHDATA* with payloads larger than 256 bytes are invalid, except for the redeemScript push in BIP16 scriptSigs. # Spending undefined witness (or Tapleaf) versions (ie, not Witness v0/BIP 141 nor Taproot/BIP 341) is invalid. # Witness stacks with a Taproot annex are invalid. # Taproot control blocks larger than 257 bytes (a merkle tree with 128 script leaves) are invalid. # Tapscripts including OP_SUCCESS* opcodes anywhere (even unexecuted) are invalid. # Tapscripts executing the OP_IF or OP_NOTIF instruction (regardless of result) are invalid. Inputs spending UTXOs that were created before the activation height are exempt from the new rules. Once the softfork expires, UTXOs of all heights are once again unrestricted. ==Motivation== To reduce arbitrary data stored on nodes, and to reject the standardization of data storage as a supported use case at the consensus level. ==Rationale== ===Specification nuance=== '''Why limit scriptPubKeys to 34 bytes?''' scriptPubKeys must be stored indefinitely in quick-access memory (often RAM) by all fully validating nodes. It generally cannot be pruned. It is also a direct cost to the sender rather than the receiver. For these reasons, modern usage is all 34 bytes or smaller in practice: actual spending conditions have been moved to the witness, and the scriptPubKey simply commits to them in advance with a hash. '''What about OP_RETURN? Why not get rid of it entirely?''' OP_RETURN outputs are provably unspendable, and nodes do not need to store them in the UTXO set. Historically, up to 83 bytes have been tolerated only to avoid unprovably unspendable spam in other output scripts, and no legitimate uses have ever been found. With the advent of pay-to-contract and Taproot, it is now also possible to commit to external data in the Taptree, making even hypothetical use of OP_RETURN deprecated. However, to avoid breaking legacy protocols that still include such outputs, this proposal allows these outputs. '''Why limit other data to 256/257 bytes?''' With modern compression, it is plausible to represent images in as few as 300-400 bytes. Images are likely the most harmful use case for data storage, as they have huge demand and supporting them can engender high fees and UTXO-set bloat, as well as content that a large majority of node operators might object to. 256 bytes (2048 bits) is also more than sufficient for reasonably large numbers that might be potentially needed in legitimate cryptography, reinforcing Bitcoin's intended purpose as a monetary network. '''Won't spammers just spread their data over multiple fields?''' While it is impossible to fully prevent steganography, limiting data sizes ensures such abuses are non-contiguous and obfuscated within another intended meaning (script code, structure, etc). As far as Bitcoin is concerned, the data has some meaning other than the spammers' misinterpretation, and any external code to "reassemble" the unintended data is responsible for producing it (it is possible to write code that transforms *any* data into any other data - what matters is that Bitcoin has a well-defined meaning that is distinct from the unsupported one). This proposal also sends a clear message that data storage abuses in general are unwelcome rather than sanctioned or supported. '''Why is there an exception for BIP16 redeemScripts?''' The content of redeemScripts are another script, which is then executed. Its contents are then also subject to the same OP_PUSHDATA* restrictions. Restricting it is not only unnecessary, but would reduce the ability to make use of the intended script capabilities, and could impact legitimate real-world usage. '''Why make spending undefined witness/Tapleaf versions invalid?''' Since they are undefined, witness stacks spending these versions are completely unlimited currently to allow maximum flexibility in future upgrades. Any future upgrade, however, would need more than a year of coordination, so this softfork will not actually restrict it, and only safeguards against abuse in the meantime. '''Why not make it invalid to send to undefined witness versions?''' This would require the senders of transactions to check the witness version prior to sending, and require additional coordination when a new witness version is intended to become used. '''Why not allow spending undefined witness versions with an empty witness?''' This has no use case, but would require nodes to track these UTXOs in case of potential spending. By making spending invalid, it is possible for nodes to store them instead in slow memory not needed until this softfork expires. (With proper planning, it also makes it possible for a future softfork making use of these witness versions to allow users to receive with an upgraded wallet even prior to activation of the upgrade.) '''Why make the Taproot annex invalid?''' The annex is currently undefined data with unlimited size. It exists for future upgrades, but has no legitimate usage today. Any future upgrade, however, would need more than a year of coordination, so this softfork will not actually restrict it, and only safeguards against abuse in the meantime. '''Why is the Taproot control block limited to 257 bytes instead of 256?''' The control block is a series of hashes proving the Tapscript is part of the Taptree, plus a single byte with the leaf version and parity bit. See BIP 341 for details. '''Why make OP_SUCCESS* invalid?''' OP_SUCCESS* is meant for future upgrades. See above regarding undefined witness versions. '''Why make OP_IF/OP_NOTIF invalid?''' OP_IF/OP_NOTIF originated in pre-Taproot Bitcoin script language as a way to execute different subscripts based on a condition. With Taproot, the conditions can instead be evaluated off-chain, revealing only the intended verification execution path. Furthermore, when the conditions are met, the intent is that the keypath spend path should be used instead, avoiding publishing any scripts at all. OP_IF is not only redundant for Tapscript, it is also commonly abused today to inject spam that gets skipped at execution. While it is impossible to fully prevent steganography, closing this gap eliminates one common abuse today basically for free, and sends a message that such abuses are not welcome. '''Why is the proposal so simple?''' A more complicated proposal could be envisioned that better balances innovation with safety, but implementing this properly would require extensive refactoring and review, delaying deployment when there is already no time to wait. The rules proposed herein have been intentionally kept very simple to minimise review time and avoid unnecessary risks of overlooking unexpected side effects. '''Why is this softfork temporary?''' The impact of these restrictions would severely constrain future upgrades, potentially forcing them to be designed as a hardfork instead of a softfork. Some restrictions are also not ideal, but an improved limit would be more complicated to develop and test - by deploying these simpler restrictions now, we avoid making the perfect the enemy of the good enough, while still allowing for upgrading the limits to better variants in the future. Over the next year, interested developers can implement and propose a longer-term solution to address the needs of the protocol without the tradeoffs or blunt/simplified changes. ===Tradeoffs=== '''Are there any tradeoffs?''' Yes: # Limiting Taproot control blocks to 257 bytes directly constrains the size of the on-chain, consensus-enforced script tree. This could complicate or possibly even impede advanced smart contracting like BitVM, which relies on a large number of executable scripts. In the worst case scenario, these use cases may just need to wait until this softfork expires. As they are still in early development, testnet and sidechains should be sufficient for the next year while a more scalable rule is implemented. # Upgrade hooks are not available for other softforks. As softforks need at least a year to activate, this shouldn't be a practical issue. # Some wallet software such as Miniscript habitually create Tapleaves containing OP_IF. To mitigate the risk of freezing these funds for a year, this proposal exempts inputs that spend outputs that were created before activation. '''Isn't the limit on Taproot control blocks too restrictive?''' Possibly. The previous limit allows for 340,282,366,920,938,463,463,374,607,431,768,211,456 scripts, which is obviously way more than anyone could ever need. 257 bytes allows for 128 scripts, which is sufficient for modern and complex transactions. However, it may prove too limiting for advanced off-chain functionality such as used by BitVM. This is an unfortunate tradeoff that (if this softfork is accepted) we have chosen to accept in the short-term for the immediate benefits of this softfork. The intent is to relax this restriction later, when this softfork expires, with a new approach allowing larger trees, yet to be developed. Do note that non-script (or non-Bitcoin-L1 scripts) usage of the taptree does not have this same limitation: just a single of the 128 leaves could very well be an extension of the merkle tree to greater depths than enforced by this softfork. '''Aren't Taptrees intended to be unbalanced?''' While it is true that optimal use of Taptrees may often be unbalanced to favour more-likely-executed scripts, this is optional, and the full capacity (in this case, 128 scripts) can still be used if needed. Additionally, in ideal/ordinary circumstances, neither the Taptree nor a merkle branch through it is ever published: all counterparties ought to evaluate the conditions for spending off-chain and rebroadcast the transaction using the keypath spending. Tapscripts are intended to only be used when one or more parties is unreachable or uncooperative; their existence mainly only serves to deter intentional non-cooperation by making it pointless. ===Alternatives / Alsos=== '''Why not let the fee market manage data storage?''' The fee market is designed to prioritize transactions based on economic urgency. However, the market for data storage on the blockchain is a completely different market from the market for payments, with completely different incentives. Specifically, the fee for a monetary transaction incentivises a miner to include the transaction in a block, representing a one-time transfer of one or more UTXOs. The miner thus provides the one-time service of securing a payment, for a one-time fee. Once the payment is secured, the payor does not receive any additional benefit from the Bitcoin network, besides the integrity of Bitcoin's transaction history (a service to which all node operators are happy to contribute, because Bitcoin would not function as money otherwise). Conversely, the fee for a data storage transaction still goes only to the miner who includes the data in a block, but the burden of storing the data falls on all node operators, who never received even a part of the fee, yet are forced to continue downloading, storing, and serving the data forever. In this case, the miner accepts a one-time fee, and in exchange, the priceless service of highly-available, uncensorable data storage is provided in perpetuity ''for free'' by node operators. The problem becomes even worse when the data is objectionable to node operators, as this represents an even larger, unexpected cost for them. '''How about OP_RETURN2/"blobspace" making the data optional for nodes?''' This has been attempted multiple times in the past. There is perhaps no harm in trying yet again, and this proposal does not prevent doing so, but ultimately these schemes depend on the cooperation of the sender, who usually wants to explicitly force the content on non-consenting node operators (or they would be using other existing distribution methods already). These other ideas also do not solve the problem of objectionable content. '''Shouldn't spam be fought in policy? Does this proposal affirm that policy is ineffective?''' It remains true that policy is still the best place to fight spam. However, it is also true that policy cannot guarantee 100% effectiveness, particularly against bad actors who are mining. This softfork minimises the impact of such malicious miners, closing the worst-case risks. '''Does this proposal solve spam completely?''' No. It is impossible to solve spam completely, and typically spam is best fought with policy/filters, not consensus. What this softfork does is require users wanting to store large unencrypted files in the blockchain to disguise the data as financial data and/or break it up into multiple data pushes. Obviously doing so is considered an abuse of bitcoin and should be avoided, but if it does happen, this BIP strengthens the argument that data storage is not a supported use case. '''Why doesn't this proposal address non-Bitcoin tokens?''' There are a wide variety of non-Bitcoin tokens, mostly scams, that a significant portion of the community considers spam. However, these schemes are best countered in policy rather than consensus, and besides, this proposal does not aim to eliminate spam entirely. '''Is this a slippery slope? If we make rules against data today, will we start banning use cases we don't like tomorrow?''' No. These rules may be new at the consensus level, but they are merely enshrining long-standing principles of Bitcoin, as necessary to address a threat to the decentralization of the network and its usability for monetary purposes. This softfork does not attempt to impose restrictions on monetary activity or the validity of monetary transactions themselves. By restricting the data storage use case as much as possible, this proposal reinforces Bitcoin's guarantee of sound, permissionless money for the long-term. This clear distinction between mitigating a systemic risk from non-monetary data abuse and interfering with actual monetary use cases provides a strong barrier against future overreach. The explicitly temporary nature of the softfork further reinforces that this is a targeted intervention to mitigate a specific crisis, not a commitment or proposal of a new direction of development. If no further action is taken by you, it will expire in a year. Even if a followup softfork is proposed for that time, you retain the right to reject it. '''Why not reduce the block weight/size limit too?''' It is possible this softfork may activate before miners have fully upgraded. To ensure continuity of Bitcoin through a potentially low-hashrate period, we must assume there's a possibility of each block taking 10 times as long as intended (ie, ~2 hours per block), which would mean 4 MWU per block would be a mere 333 kWU per 10 minutes. If there is community support for reducing block sizes, it should therefore be done separately and calmly, after the network has settled down. '''Why not activate CTV at the same time?''' CTV is still controversial with a minority of the community, and bundling it with this softfork could be seen as an attempt to trick/force it on the network. However, this softfork does "set the stage" for a followup softfork in a year, which would be an ideal stage to include CTV if the community deems it appropriate. ==Backwards compatibility== Any UTXOs confirmed before activation will be spendable while this deployment is active; only outputs that are created ''during'' the deployment will have to wait until it expires in order to be spendable. ==Reference implementation== https://github.com/bitcoinknots/bitcoin/compare/29.x-knots...UASF:bitcoin:29.2.knots20251010+BIP444?expand=1 ==Deployment== We propose a flag day startheight of 934864 (2026-02-01), with mandatory signaling leading up to activation. This implies an expiry day stopheight of 987424 (2027-02-01). These heights were extrapolated from block 920464 which occurred near 00:00 UTC on 2025-10-24. ==Credits== Original draft and advice: Luke-Jr ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 ` (2 subsequent siblings) 3 siblings, 0 replies; 30+ messages in thread From: Edil Guimarães de Medeiros @ 2025-11-08 3:43 UTC (permalink / raw) Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 7252 bytes --] > > > 1. "Missing code": The code is now public here: > https://github.com/UASF/bitcoin/tree/29.2.knots20251010%2BBIP444 (please > note that, while there are references to "BIP-444" in the code, that is > just a placeholder and I will update it to whatever number the BIP editors > decide). > > Wanted to have a glimpse at the code, but it looks like this repo doesn't build on top of eeb9cc1120661d0e9fd28ddb6fef2c04992a4666 <https://github.com/bitcoinknots/bitcoin/commit/eeb9cc1120661d0e9fd28ddb6fef2c04992a4666> which I understand is the knots release <https://github.com/bitcoinknots/bitcoin/releases/tag/v29.2.knots20251010> in which this is supposed to be based considering the name of the branch. So, I have no idea how one can review this (under the assumption that they reviewed or trusts the Knots release). BTW, I only noted now that commits on the Knots repo (and thus this) have no signatures other than Core devs' or Datonohm's (an account that was created 2 weeks ago?). Em sex., 7 de nov. de 2025 às 21:58, dathonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> escreveu: > Hi all - > > BIP repo maintainers requested > <https://github.com/bitcoin/bips/pull/2017#issuecomment-3462134337> that > I update this list before pushing a significant change, so I am doing that > now. > > Please consider this my formal request for the BIP PR to be unlocked so > that discussion can resume. > > This update addresses several concerns from the previous draft: > > > 1. "Funds confiscation": due to the presence of UTXOs that would be > made temporarily unspendable by this proposal, commenters were concerned > that this would set a precedent of "confiscation". This new draft resolves > this concern by adding a UTXO height check to make sure *only UTXOs > that are created while the softfork is active will be made temporarily > unspendable*. The "OP_IF in Tapscript" and "257-byte control block > limit" were the two main proposed rule changes that caused concern here. > 2. "This doesn't block all possible methods of arbitrary data > insertion": This was already addressed in the previous draft, but to > reiterate: this proposal's goal is not to block *all* methods of > arbitary data insertion, just the most commonly abused ones. > 3. "Blocks other softfork upgrades while active": This was also > addressed in the original draft, but to reiterate: it's unlikely that any > softfork upgrades will be ready to activate within one year anyway, so this > doesn't matter much. But also, the fact that this softfork expires creates > an opportunity to activate a more permanent and elegant upgrade that turns > on what the community wants, while continuing to reject data storage as a > supported use case, after one year. > 4. "Reactive deployment risks": These concerns have been addressed by *removing > the reactive deployment method entirely*. I still think activating > this softfork is a matter of some urgency, but I think it still achieves > its goals if we move steadily towards activation within a few months. > 5. "Missing code": The code is now public here: > https://github.com/UASF/bitcoin/tree/29.2.knots20251010%2BBIP444 (please > note that, while there are references to "BIP-444" in the code, that is > just a placeholder and I will update it to whatever number the BIP editors > decide). > 6. "Temporary expiry risks": "Requires another consensus change before > expiry or rules lapse": Yes, as stated in <3>, the community will have > to come together in a year either to extend these rules (which shouldn't be > difficult), or to activate something more permanent and less blunt. The > expiry will *not* be a hardfork, contrary to some claims I've seen, > because opting into this deployment means opting into the expiry as well, > so old nodes will follow new ones onto the unrestricted chain > 7. "Legal/process/conflict-of-interest concerns": all language about > legal risks has been stripped from the BIP. > > > I welcome any and all feedback, as I think this proposal or something > similar to it stands an excellent chance of gaining consensus and > activating, and I think if that happens, it could be curative for the > Bitcoin community. > > Thanks again for all of your feedback and support, it means a lot. > > Sincerely, > > Dathon > On Wednesday, October 29th, 2025 at 8:57 PM, Erik Aronesty <erik@q32.com> > wrote: > > >> Case law in the USA regarding illegal content has always rested squarely >> on those who: > > > 1 - provide broad public access, in this case a company like OpenSEA > (which has had to block content) > 2 - the original author > > if punishing "relays" was a thing, then every CISCO router, SMTP relay and > DISCORD server that provided access would be in court all day long > > instead, it's the users of the illegal data and the publishers that > actually wind up in trouble - not the internet providers > > the bitcoin ledger is neither a browser or web server, nor is it an image > uploader. there is zero ability to view images built into the system > > and even if it was > > the purpose of this software is to be a distributed and effectively > uncensorable ledger. > > hopefully it doesn't change because someone launched a meme campaign with > vague threats of legal action > > if a transaction has /no reasonable expectation of being mined/ (too > expensive to validate, too large, too low fees), there's also no reason to > relay it > > this is probably the best way to set policy > > -- > 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/CAJowKgKBBa%2BvD%3D5X0VMV2OFiBBM23Ok6nmvfoLTr8fia141%3DFQ%40mail.gmail.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/bJL7UshcsXUpiQiC85dQeafQrRvtovH1aRcUxggjD1S09Md9qWHi9GpJOBdcPGq2NNQMK2XK-REMVlWjHLkh3aKUIktnYQccUWqg0DHgNXc%3D%40proton.me > <https://groups.google.com/d/msgid/bitcoindev/bJL7UshcsXUpiQiC85dQeafQrRvtovH1aRcUxggjD1S09Md9qWHi9GpJOBdcPGq2NNQMK2XK-REMVlWjHLkh3aKUIktnYQccUWqg0DHgNXc%3D%40proton.me?utm_medium=email&utm_source=footer> > . > -- Edil -- 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/CANJiN3Li9c29_7DRjf6s10%3Dprn7HP6g9MPG5UMvq2HN1N1izTA%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 11308 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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-09 21:34 ` Peter Todd 3 siblings, 0 replies; 30+ messages in thread From: 'Bitcoin Eagle' via Bitcoin Development Mailing List @ 2025-11-08 9:30 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 5579 bytes --] ad 1) Funds confiscation: as already mentioned by gmaxwell there is a risk of confiscation of presigned transactions. Lightning like protocols that simulate covenants using n-of-n multisig. Will be confiscated even if UTXO height is whitelisted On Saturday, November 8, 2025 at 7:58:30 AM UTC+7 dath...@proton.me wrote: Hi all - BIP repo maintainers requested <https://github.com/bitcoin/bips/pull/2017#issuecomment-3462134337> that I update this list before pushing a significant change, so I am doing that now. Please consider this my formal request for the BIP PR to be unlocked so that discussion can resume. This update addresses several concerns from the previous draft: 1. "Funds confiscation": due to the presence of UTXOs that would be made temporarily unspendable by this proposal, commenters were concerned that this would set a precedent of "confiscation". This new draft resolves this concern by adding a UTXO height check to make sure *only UTXOs that are created while the softfork is active will be made temporarily unspendable*. The "OP_IF in Tapscript" and "257-byte control block limit" were the two main proposed rule changes that caused concern here. 2. "This doesn't block all possible methods of arbitrary data insertion": This was already addressed in the previous draft, but to reiterate: this proposal's goal is not to block *all* methods of arbitary data insertion, just the most commonly abused ones. 3. "Blocks other softfork upgrades while active": This was also addressed in the original draft, but to reiterate: it's unlikely that any softfork upgrades will be ready to activate within one year anyway, so this doesn't matter much. But also, the fact that this softfork expires creates an opportunity to activate a more permanent and elegant upgrade that turns on what the community wants, while continuing to reject data storage as a supported use case, after one year. 4. "Reactive deployment risks": These concerns have been addressed by *removing the reactive deployment method entirely*. I still think activating this softfork is a matter of some urgency, but I think it still achieves its goals if we move steadily towards activation within a few months. 5. "Missing code": The code is now public here: https://github.com/UASF/bitcoin/tree/29.2.knots20251010%2BBIP444 (please note that, while there are references to "BIP-444" in the code, that is just a placeholder and I will update it to whatever number the BIP editors decide). 6. "Temporary expiry risks": "Requires another consensus change before expiry or rules lapse": Yes, as stated in <3>, the community will have to come together in a year either to extend these rules (which shouldn't be difficult), or to activate something more permanent and less blunt. The expiry will *not* be a hardfork, contrary to some claims I've seen, because opting into this deployment means opting into the expiry as well, so old nodes will follow new ones onto the unrestricted chain 7. "Legal/process/conflict-of-interest concerns": all language about legal risks has been stripped from the BIP. I welcome any and all feedback, as I think this proposal or something similar to it stands an excellent chance of gaining consensus and activating, and I think if that happens, it could be curative for the Bitcoin community. Thanks again for all of your feedback and support, it means a lot. Sincerely, Dathon On Wednesday, October 29th, 2025 at 8:57 PM, Erik Aronesty <er...@q32.com> wrote: Case law in the USA regarding illegal content has always rested squarely on those who: 1 - provide broad public access, in this case a company like OpenSEA (which has had to block content) 2 - the original author if punishing "relays" was a thing, then every CISCO router, SMTP relay and DISCORD server that provided access would be in court all day long instead, it's the users of the illegal data and the publishers that actually wind up in trouble - not the internet providers the bitcoin ledger is neither a browser or web server, nor is it an image uploader. there is zero ability to view images built into the system and even if it was the purpose of this software is to be a distributed and effectively uncensorable ledger. hopefully it doesn't change because someone launched a meme campaign with vague threats of legal action if a transaction has /no reasonable expectation of being mined/ (too expensive to validate, too large, too low fees), there's also no reason to relay it this is probably the best way to set policy -- 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+...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAJowKgKBBa%2BvD%3D5X0VMV2OFiBBM23Ok6nmvfoLTr8fia141%3DFQ%40mail.gmail.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/6ff66d86-848f-493d-a0dd-4ff8ea42f932n%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 8616 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 21:02 ` dathonohm via Bitcoin Development Mailing List 2025-11-09 21:34 ` Peter Todd 3 siblings, 2 replies; 30+ messages in thread From: Greg Maxwell @ 2025-11-08 15:38 UTC (permalink / raw) To: dathonohm; +Cc: Erik Aronesty, Antoine Riard, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 3676 bytes --] On Sat, Nov 8, 2025 at 12:58 AM dathonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote: > > 1. "Funds confiscation": due to the presence of UTXOs that would be > made temporarily unspendable by this proposal, commenters were concerned > that this would set a precedent of "confiscation". This new draft resolves > this concern by adding a UTXO height check to make sure *only UTXOs > that are created while the softfork is active will be made temporarily > unspendable*. The "OP_IF in Tapscript" and "257-byte control block > limit" were the two main proposed rule changes that caused concern here. > > That doesn't address the confiscation problem (although any reduction in the restriction does reduce it), as there likely exist chains of not yet confirmed (and potentially timelocked) transactions that involve violations of this rule. Those would appear to the network to be outputs created at a later time, although they really weren't. It's unclear to me why you haven't yet understood this point. I don't think this concern was in any way limited to the control block of op_if components either, essentially every aspect of the proposal has confiscation issues. Another issue raised which you have not mentioned is that prior to you making this proposal I received minutes from a meeting which noted that Ocean Mining was the true author of this proposal and would be presenting it under a false identity in order to conceal their involvement. Will you be correcting the record on the true authorship of this work and on whose behalf its being performed? > "This doesn't block all possible methods of arbitrary data insertion": This was already addressed in the previous draft, but to reiterate: this proposal's goal is not to block *all* methods of arbitary data insertion, just the most commonly abused ones. 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/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 4937 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 1 sibling, 1 reply; 30+ messages in thread From: Daniel Buchner @ 2025-11-08 16:40 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-11-08 16:40 ` Daniel Buchner @ 2025-11-08 17:55 ` Chris Riley 0 siblings, 0 replies; 30+ messages in thread From: Chris Riley @ 2025-11-08 17:55 UTC (permalink / raw) To: Daniel Buchner, Greg Maxwell; +Cc: Bitcoin Development Mailing List [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-11-08 15:38 ` Greg Maxwell 2025-11-08 16:40 ` Daniel Buchner @ 2025-11-08 21:02 ` dathonohm via Bitcoin Development Mailing List 2025-11-08 21:39 ` Greg Maxwell 2025-11-09 1:21 ` Murch 1 sibling, 2 replies; 30+ messages in thread From: dathonohm via Bitcoin Development Mailing List @ 2025-11-08 21:02 UTC (permalink / raw) To: Greg Maxwell Cc: Erik Aronesty, Antoine Riard, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 10392 bytes --] Hi Greg - >That doesn't address the confiscation problem (although any reduction in the restriction does reduce it), as there likely exist chains of not yet confirmed (and potentially timelocked) transactions that involve violations of this rule. Those would appear to the network to be outputs created at a later time, although they really weren't. It's unclear to me why you haven't yet understood this point. While I completely agree that "confiscation" is a precedent we must avoid setting, I think my proposal neither confiscates funds nor sets a bad precedent, as it takes pains to avoid causing problems for all known use cases. I don't think it is reasonable never to create problems for all unknown use cases, as this would necessarily imply permanent ossification. To illustrate the point: it is possible to design off-chain systems that "use" any given feature of the Bitcoin protocol, including, for example, OP_NOPs. Funds locked in such UTXOs would be "confiscated" by the softfork proposal that redefines the OP_NOP. That is, anyone could intentionally lock funds into a pathological construction in order to obstruct any given softfork. Thus, if taken to the extreme, the argument that no one should ever have funds "confiscated", or even temporarily frozen, means that we can never upgrade Bitcoin again. So, in the interest of avoiding permanent ossification, it seems wise for us to compromise somewhere in the middle. I think my proposal strikes a good balance. Of course, if people are reporting that there are known, non-pathological use cases with significant funds locked into pre-signed transactions, then of course I will modify the proposal to accommodate them. >Another issue raised which you have not mentioned is that prior to you making this proposal I received minutes from a meeting which noted that Ocean Mining was the true author of this proposal and would be presenting it under a false identity in order to conceal their involvement. Will you be correcting the record on the true authorship of this work and on whose behalf its being performed? It sounds like you have fallen victim to some false rumors. I already attempted to correct the record on this, both here on this mailing list and on the BIP PR, but both times my messages were suppressed by moderators. I humbly request that moderators let the public see my response this time, otherwise I'm not sure how the record will ever be corrected: Though I am in direct communication with some Ocean employees (and the BIP was originally drafted by one of them), I am not affiliated with Ocean in any way. I am just a Bitcoin dev who is concerned about the implications of Core 30 having been released and gaining adoption. I am acting solely on my own behalf and on the behalf of the Bitcoin community, because I and most Bitcoiners I know are concerned about Bitcoin's future if it embraces data storage as a supported use case. This proposal is also a significant departure from the original BIP draft. >Would you then agree that this proposal will fail at its stated purpose, particularly with respect to concerns about potentially 'unlawful' material? No, I think this proposal is the best way to achieve its stated purpose, which is to reject the standardization of data storage as a supported use case, at the consensus level. It sounds like you haven't read the new version of the BIP, nor my summary above. I attached the document in my previous email message if you are interested. It removes all references to legal risks. For those who prefer viewing the proposal in a browser, I have pushed a copy of it to a non-PR branch, since the PR is still locked: https://github.com/dathonohm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.mediawiki >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? Again, this is no longer applicable to the proposal. The new draft makes significant changes. >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) I don't see this softfork as an "update-blocking action"; on the contrary, I see it as an update-enabling one. As I stated previously, attempting to never disrupt any use cases, no matter how pathological, is the fastest path to ossification. Indeed, Bitcoin has failed to make any consensus upgrades at all since Taproot in 2021. The community has been going in circles now for two years because of pathological use cases introduced by that fork, and this proposal allows Bitcoiners to say "enough is enough", re-affirm that Bitcoin is money rather than data storage by disabling all the most popular methods of data abuse, and move on to more exciting things. We could have new upgrades in one year if Bitcoiners focus on building them over the following months. I honestly don't see a better way out of this morass, but please let me know your reasoning if you disagree. Inaction is not going to solve this. >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 don't see much reason not to adopt it, besides fear of softforks in general, but I'm listening. >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. I don't see why anyone in their right mind would choose to bet on the old fork where Bitcoin is filled with spam and confused about whether it might want to just be a database, over the new one where Bitcoin is money. Best regards, Dathon On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell <gmaxwell@gmail.com> wrote: > On Sat, Nov 8, 2025 at 12:58 AM dathonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote: > >> - "Funds confiscation": due to the presence of UTXOs that would be made temporarily unspendable by this proposal, commenters were concerned that this would set a precedent of "confiscation". This new draft resolves this concern by adding a UTXO height check to make sure only UTXOs that are created while the softfork is active will be made temporarily unspendable. The "OP_IF in Tapscript" and "257-byte control block limit" were the two main proposed rule changes that caused concern here. > > That doesn't address the confiscation problem (although any reduction in the restriction does reduce it), as there likely exist chains of not yet confirmed (and potentially timelocked) transactions that involve violations of this rule. Those would appear to the network to be outputs created at a later time, although they really weren't. It's unclear to me why you haven't yet understood this point. > > I don't think this concern was in any way limited to the control block of op_if components either, essentially every aspect of the proposal has confiscation issues. > > Another issue raised which you have not mentioned is that prior to you making this proposal I received minutes from a meeting which noted that Ocean Mining was the true author of this proposal and would be presenting it under a false identity in order to conceal their involvement. Will you be correcting the record on the true authorship of this work and on whose behalf its being performed? > >> "This doesn't block all possible methods of arbitrary data insertion": This was already addressed in the previous draft, but to reiterate: this proposal's goal is not to block all methods of arbitary data insertion, just the most commonly abused ones. > > 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/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.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/MQv8-Ejvo7ZUcCOQkmtFo8hOATgSrKWvtG25JqUgWXKNGYHbCkVc-IawuPcRN_BebLTLQr3QtTTaA1iWrWgs0fFwI45jnQFi5_ORnAbsP_k%3D%40proton.me. [-- Attachment #2: Type: text/html, Size: 19592 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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-09 1:21 ` Murch 1 sibling, 1 reply; 30+ messages in thread From: Greg Maxwell @ 2025-11-08 21:39 UTC (permalink / raw) To: dathonohm; +Cc: Erik Aronesty, Antoine Riard, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 13116 bytes --] It's not speculative-- nlocktime is a day one feature which *is* used in Bitcoin. Sure someone could footgun themselves by intentionally using a transaction field which is expressly intended for forward compatibility and get themselves burned-- but they'd have to be trying, not just doing a boring and unconcerning thing because those fields don't do anything so the only reason to use them would be an outright error or intentionally trying to break themselves. This is also not a new concern being raised for your proposal, every softfork post P2SH has been analyzed under this lens so it's quite concerning to see the proposal here simply ignore the concern. Even the intentional forward compat features have caused some lack of comfort in the past in this respect, which is why tapscript OP_SUCCESS works the way it does: so that any script that prematurely uses a 'success' opcode would be inherently completely insecure-- an important improvement in upgradability that your proposal permanently destroys without you even understanding why it existed in the first place. And indeed I haven't read a new version because your prior message provided no reference to it-- it said you were requested to update the list and then you only provided a summary. I was responding to the summary. Now looking at it, I see that you are still limiting scriptpubkey sizes strictly-- this will absolutely confiscate funds as was pointed out and not responded to even before your proposal. (because luke-jr proposed just that limit first-- actually a more relaxed version, then simply dishonestly insisted there was no opposition to it, even though opposition was immediately raised on the list). I think your proposal continues to have no serious prospect of activation, and should it activate in any form it will just be forked against and its authors will likely find themselves mired in litigation by people harmed by it. I think you'll find that almost every significant bitcoin developer will stand against such a change and will not work on a fork that adopts them, I also doubt the market would value your fork with such significant limitations very highly. On Sat, Nov 8, 2025 at 9:02 PM <dathonohm@proton.me> wrote: > Hi Greg - > > >That doesn't address the confiscation problem (although any reduction in > the restriction does reduce it), as there likely exist chains of not yet > confirmed (and potentially timelocked) transactions that involve violations > of this rule. Those would appear to the network to be outputs created at a > later time, although they really weren't. It's unclear to me why you > haven't yet understood this point. > > While I completely agree that "confiscation" is a precedent we must avoid > setting, I think my proposal neither confiscates funds nor sets a bad > precedent, as it takes pains to avoid causing problems for all known use > cases. I don't think it is reasonable never to create problems for all > *unknown* use cases, as this would necessarily imply permanent > ossification. > > To illustrate the point: it is possible to design off-chain systems that > "use" any given feature of the Bitcoin protocol, including, for example, > OP_NOPs. Funds locked in such UTXOs would be "confiscated" by the softfork > proposal that redefines the OP_NOP. That is, anyone could intentionally > lock funds into a pathological construction in order to obstruct any given > softfork. > > Thus, if taken to the extreme, the argument that no one should ever have > funds "confiscated", or even temporarily frozen, means that we can never > upgrade Bitcoin again. So, in the interest of avoiding permanent > ossification, it seems wise for us to compromise somewhere in the middle. I > think my proposal strikes a good balance. > > Of course, if people are reporting that there are known, non-pathological > use cases with significant funds locked into pre-signed transactions, then > of course I will modify the proposal to accommodate them. > > >Another issue raised which you have not mentioned is that prior to you > making this proposal I received minutes from a meeting which noted that > Ocean Mining was the true author of this proposal and would be presenting > it under a false identity in order to conceal their involvement. Will you > be correcting the record on the true authorship of this work and on whose > behalf its being performed? > > It sounds like you have fallen victim to some false rumors. > > I already attempted to correct the record on this, both here on this > mailing list and on the BIP PR, but both times my messages were suppressed > by moderators. > > I humbly request that moderators let the public see my response this time, > otherwise I'm not sure how the record will ever be corrected: > > Though I am in direct communication with some Ocean employees (and the BIP > was originally drafted by one of them), *I am not affiliated with Ocean > in any way*. I am just a Bitcoin dev who is concerned about the > implications of Core 30 having been released and gaining adoption. > > *I am acting solely on my own behalf and on the behalf of the Bitcoin > community*, because I and most Bitcoiners I know are concerned about > Bitcoin's future if it embraces data storage as a supported use case. > > This proposal is also a significant departure from the original BIP draft. > > >Would you then agree that this proposal will fail at its stated purpose, > particularly with respect to concerns about potentially 'unlawful' material? > > No, I think this proposal is the best way to achieve its stated purpose, > which is to reject the standardization of data storage as a supported use > case, at the consensus level. > > It sounds like you haven't read the new version of the BIP, nor my summary > above. I attached the document in my previous email message if you are > interested. It removes all references to legal risks. > > For those who prefer viewing the proposal in a browser, I have pushed a > copy of it to a non-PR branch, since the PR is still locked: > https://github.com/dathonohm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.mediawiki > > >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? > > Again, this is no longer applicable to the proposal. The new draft makes > significant changes. > > >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) > > I don't see this softfork as an "update-blocking action"; on the contrary, > I see it as an update-enabling one. As I stated previously, attempting to > never disrupt any use cases, no matter how pathological, is the fastest > path to ossification. > > Indeed, Bitcoin has failed to make any consensus upgrades at all since > Taproot in 2021. The community has been going in circles now for two years > because of pathological use cases introduced by that fork, and this > proposal allows Bitcoiners to say "enough is enough", re-affirm that > Bitcoin is *money* rather than *data storage* by disabling all the most > popular methods of data abuse, and move on to more exciting things. We > could have new upgrades in one year if Bitcoiners focus on building them > over the following months. > > I honestly don't see a better way out of this morass, but please let me > know your reasoning if you disagree. Inaction is not going to solve this. > > >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 don't see much reason *not* to adopt it, besides fear of softforks in > general, but I'm listening. > > >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. > > I don't see why anyone in their right mind would choose to bet on the old > fork where Bitcoin is filled with spam and confused about whether it might > want to just be a database, over the new one where Bitcoin is money. > > Best regards, > > Dathon > On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell < > gmaxwell@gmail.com> wrote: > > On Sat, Nov 8, 2025 at 12:58 AM dathonohm via Bitcoin Development Mailing > List <bitcoindev@googlegroups.com> wrote: > >> >> 1. "Funds confiscation": due to the presence of UTXOs that would be >> made temporarily unspendable by this proposal, commenters were concerned >> that this would set a precedent of "confiscation". This new draft resolves >> this concern by adding a UTXO height check to make sure *only UTXOs >> that are created while the softfork is active will be made temporarily >> unspendable*. The "OP_IF in Tapscript" and "257-byte control block >> limit" were the two main proposed rule changes that caused concern here. >> >> > That doesn't address the confiscation problem (although any reduction in > the restriction does reduce it), as there likely exist chains of not yet > confirmed (and potentially timelocked) transactions that involve violations > of this rule. Those would appear to the network to be outputs created at a > later time, although they really weren't. It's unclear to me why you > haven't yet understood this point. > > I don't think this concern was in any way limited to the control block of > op_if components either, essentially every aspect of the proposal has > confiscation issues. > > Another issue raised which you have not mentioned is that prior to you > making this proposal I received minutes from a meeting which noted that > Ocean Mining was the true author of this proposal and would be presenting > it under a false identity in order to conceal their involvement. Will you > be correcting the record on the true authorship of this work and on whose > behalf its being performed? > > > "This doesn't block all possible methods of arbitrary data insertion": > This was already addressed in the previous draft, but to reiterate: this > proposal's goal is not to block *all* methods of arbitary data insertion, > just the most commonly abused ones. > > 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/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.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/CAAS2fgTCFx2yvvUu9YWwcm-SSojT530Uwzi0b3sOG0%2BVZEcaAw%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 21818 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 0 siblings, 1 reply; 30+ messages in thread From: dathonohm via Bitcoin Development Mailing List @ 2025-11-09 20:07 UTC (permalink / raw) To: Greg Maxwell Cc: Erik Aronesty, Antoine Riard, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 17874 bytes --] Hi Greg - >It's not speculative-- nlocktime is a day one feature which *is* used in Bitcoin. Correct, I have not claimed otherwise. >Sure someone could footgun themselves by intentionally using a transaction field which is expressly intended for forward compatibility and get themselves burned-- but they'd have to be trying, not just doing a boring and unconcerning thing because those fields don't do anything so the only reason to use them would be an outright error or intentionally trying to break themselves. Okay, if you or anyone can show me an example of a "boring and unconcerning thing" that involves pre-signed transactions that use deep/OP_IF-containing Taptrees and timelocks, which predates the original softfork proposal, I will be happy to update the BIP. Saying "someone might be doing this" is simply frivolous obstructionism which, again, could be used to stop any attempt to change the consensus rules. >This is also not a new concern being raised for your proposal, every softfork post P2SH has been analyzed under this lens so it's quite concerning to see the proposal here simply ignore the concern. I believe the utility of the strategy of "don't break any use cases, no matter how pathological" has finally worn out. The longer we continue down this path, the more likely it is that Bitcoin will become entirely pathological use cases. Accordingly, this BIP intentionally disrupts all of the most harmful use cases, because they are making Bitcoin worse money and the problem is accelerating. But as stated before, the proposal also takes great pains not to disrupt any non-pathological use cases, and again I'm open to revising the spec if a concrete example that would be harmed by this softfork is found. >And indeed I haven't read a new version because your prior message provided no reference to it It is attached as a file to my email. Does your email client not support attachments? I'll be sure to include a browser-friendly link next time if that's the case. >I was responding to the summary. The summary mentioned that I had removed all references to legal risks. >Now looking at it, I see that you are still limiting scriptpubkey sizes strictly-- this will absolutely confiscate funds as was pointed out and not responded to even before your proposal. (because luke-jr proposed just that limit first-- actually a more relaxed version, then simply dishonestly insisted there was no opposition to it, even though opposition was immediately raised on the list). If you're referring to [Andrew Poelstra's message here](https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs/m/4KvpvYNEAgAJ), that doesn't strike me as "opposition", and besides, note that this proposal implements a very similar mitigation suggestion, which was: >In any case, if confiscation is a worry, as always we can exempt the current UTXO set from the rule -- if you are only spending outputs that existed prior to the new rule, your new UTXOs are allowed to be large. The current proposal exempts inputs that spend from the current UTXO set, but does not allow such transactions to create outputs that violate the new rules. This should be fine, since the funds can just be sent to a different wallet, (assuming there is actually wallet software somewhere that habitually creates outputs with scriptPubKeys larger than 34 bytes). Please let me know if this is not the "opposition" you were referring to; I searched for a while but it's possible I missed something. Again, I am eager to address all valid technical objections to this proposal, and so far I haven't seen any. >I think your proposal continues to have no serious prospect of activation I disagree. I think Bitcoin users are fed up with data spam and ready to coordinate to say "enough is enough". >should it activate in any form it will just be forked against That would be incredibly risky, but of course people are welcome to run whatever software they choose. >and its authors will likely find themselves mired in litigation by people harmed by it Just to clarify, are you saying that anyone who doesn't support the URSF will face legal risks? >I think you'll find that almost every significant bitcoin developer will stand against such a change and will not work on a fork that adopts them, I also doubt the market would value your fork with such significant limitations very highly. I think you are mistaken. The Bitcoin community wants Bitcoin to be money, not data storage. Best, Dathon On Saturday, November 8th, 2025 at 3:58 PM, Greg Maxwell <gmaxwell@gmail.com> wrote: > It's not speculative-- nlocktime is a day one feature which *is* used in Bitcoin. > > Sure someone could footgun themselves by intentionally using a transaction field which is expressly intended for forward compatibility and get themselves burned-- but they'd have to be trying, not just doing a boring and unconcerning thing because those fields don't do anything so the only reason to use them would be an outright error or intentionally trying to break themselves. > > This is also not a new concern being raised for your proposal, every softfork post P2SH has been analyzed under this lens so it's quite concerning to see the proposal here simply ignore the concern. > Even the intentional forward compat features have caused some lack of comfort in the past in this respect, which is why tapscript OP_SUCCESS works the way it does: so that any script that prematurely uses a 'success' opcode would be inherently completely insecure-- an important improvement in upgradability that your proposal permanently destroys without you even understanding why it existed in the first place. > > And indeed I haven't read a new version because your prior message provided no reference to it-- it said you were requested to update the list and then you only provided a summary. I was responding to the summary. > > Now looking at it, I see that you are still limiting scriptpubkey sizes strictly-- this will absolutely confiscate funds as was pointed out and not responded to even before your proposal. (because luke-jr proposed just that limit first-- actually a more relaxed version, then simply dishonestly insisted there was no opposition to it, even though opposition was immediately raised on the list). > > I think your proposal continues to have no serious prospect of activation, and should it activate in any form it will just be forked against and its authors will likely find themselves mired in litigation by people harmed by it. I think you'll find that almost every significant bitcoin developer will stand against such a change and will not work on a fork that adopts them, I also doubt the market would value your fork with such significant limitations very highly. > > On Sat, Nov 8, 2025 at 9:02 PM <dathonohm@proton.me> wrote: > >> Hi Greg - >> >>>That doesn't address the confiscation problem (although any reduction in the restriction does reduce it), as there likely exist chains of not yet confirmed (and potentially timelocked) transactions that involve violations of this rule. Those would appear to the network to be outputs created at a later time, although they really weren't. It's unclear to me why you haven't yet understood this point. >> >> While I completely agree that "confiscation" is a precedent we must avoid setting, I think my proposal neither confiscates funds nor sets a bad precedent, as it takes pains to avoid causing problems for all known use cases. I don't think it is reasonable never to create problems for all unknown use cases, as this would necessarily imply permanent ossification. >> >> To illustrate the point: it is possible to design off-chain systems that "use" any given feature of the Bitcoin protocol, including, for example, OP_NOPs. Funds locked in such UTXOs would be "confiscated" by the softfork proposal that redefines the OP_NOP. That is, anyone could intentionally lock funds into a pathological construction in order to obstruct any given softfork. >> >> Thus, if taken to the extreme, the argument that no one should ever have funds "confiscated", or even temporarily frozen, means that we can never upgrade Bitcoin again. So, in the interest of avoiding permanent ossification, it seems wise for us to compromise somewhere in the middle. I think my proposal strikes a good balance. >> >> Of course, if people are reporting that there are known, non-pathological use cases with significant funds locked into pre-signed transactions, then of course I will modify the proposal to accommodate them. >> >>>Another issue raised which you have not mentioned is that prior to you making this proposal I received minutes from a meeting which noted that Ocean Mining was the true author of this proposal and would be presenting it under a false identity in order to conceal their involvement. Will you be correcting the record on the true authorship of this work and on whose behalf its being performed? >> >> It sounds like you have fallen victim to some false rumors. >> >> I already attempted to correct the record on this, both here on this mailing list and on the BIP PR, but both times my messages were suppressed by moderators. >> >> I humbly request that moderators let the public see my response this time, otherwise I'm not sure how the record will ever be corrected: >> >> Though I am in direct communication with some Ocean employees (and the BIP was originally drafted by one of them), I am not affiliated with Ocean in any way. I am just a Bitcoin dev who is concerned about the implications of Core 30 having been released and gaining adoption. >> >> I am acting solely on my own behalf and on the behalf of the Bitcoin community, because I and most Bitcoiners I know are concerned about Bitcoin's future if it embraces data storage as a supported use case. >> >> This proposal is also a significant departure from the original BIP draft. >> >>>Would you then agree that this proposal will fail at its stated purpose, particularly with respect to concerns about potentially 'unlawful' material? >> >> No, I think this proposal is the best way to achieve its stated purpose, which is to reject the standardization of data storage as a supported use case, at the consensus level. >> >> It sounds like you haven't read the new version of the BIP, nor my summary above. I attached the document in my previous email message if you are interested. It removes all references to legal risks. >> >> For those who prefer viewing the proposal in a browser, I have pushed a copy of it to a non-PR branch, since the PR is still locked: https://github.com/dathonohm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.mediawiki >> >>>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? >> >> Again, this is no longer applicable to the proposal. The new draft makes significant changes. >> >>>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) >> >> I don't see this softfork as an "update-blocking action"; on the contrary, I see it as an update-enabling one. As I stated previously, attempting to never disrupt any use cases, no matter how pathological, is the fastest path to ossification. >> >> Indeed, Bitcoin has failed to make any consensus upgrades at all since Taproot in 2021. The community has been going in circles now for two years because of pathological use cases introduced by that fork, and this proposal allows Bitcoiners to say "enough is enough", re-affirm that Bitcoin is money rather than data storage by disabling all the most popular methods of data abuse, and move on to more exciting things. We could have new upgrades in one year if Bitcoiners focus on building them over the following months. >> >> I honestly don't see a better way out of this morass, but please let me know your reasoning if you disagree. Inaction is not going to solve this. >> >>>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 don't see much reason not to adopt it, besides fear of softforks in general, but I'm listening. >> >>>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. >> >> I don't see why anyone in their right mind would choose to bet on the old fork where Bitcoin is filled with spam and confused about whether it might want to just be a database, over the new one where Bitcoin is money. >> >> Best regards, >> >> Dathon >> On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell <gmaxwell@gmail.com> wrote: >> >>> On Sat, Nov 8, 2025 at 12:58 AM dathonohm via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote: >>> >>>> - "Funds confiscation": due to the presence of UTXOs that would be made temporarily unspendable by this proposal, commenters were concerned that this would set a precedent of "confiscation". This new draft resolves this concern by adding a UTXO height check to make sure only UTXOs that are created while the softfork is active will be made temporarily unspendable. The "OP_IF in Tapscript" and "257-byte control block limit" were the two main proposed rule changes that caused concern here. >>> >>> That doesn't address the confiscation problem (although any reduction in the restriction does reduce it), as there likely exist chains of not yet confirmed (and potentially timelocked) transactions that involve violations of this rule. Those would appear to the network to be outputs created at a later time, although they really weren't. It's unclear to me why you haven't yet understood this point. >>> >>> I don't think this concern was in any way limited to the control block of op_if components either, essentially every aspect of the proposal has confiscation issues. >>> >>> Another issue raised which you have not mentioned is that prior to you making this proposal I received minutes from a meeting which noted that Ocean Mining was the true author of this proposal and would be presenting it under a false identity in order to conceal their involvement. Will you be correcting the record on the true authorship of this work and on whose behalf its being performed? >>> >>>> "This doesn't block all possible methods of arbitrary data insertion": This was already addressed in the previous draft, but to reiterate: this proposal's goal is not to block all methods of arbitary data insertion, just the most commonly abused ones. >>> >>> 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/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.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/CAAS2fgTCFx2yvvUu9YWwcm-SSojT530Uwzi0b3sOG0%2BVZEcaAw%40mail.gmail.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/4LP7J-1Vq3jwrB8i7nBZPo7KBwS0Dc-RfmBxAT5JNqM3vG45RS3SxLYhws88ezXAMCT17blNOQSQRnuxLXquQci12-9uiPPqte4XOqoE8OY%3D%40proton.me. [-- Attachment #2: Type: text/html, Size: 33909 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 0 siblings, 1 reply; 30+ messages in thread From: 'Bitcoin Eagle' via Bitcoin Development Mailing List @ 2025-11-11 7:43 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- Attachment #1.1: Type: text/plain, Size: 19997 bytes --] "Okay, if you or anyone can show me an example of a "boring and unconcerning thing" that involves pre-signed transactions that use deep/OP_IF-containing Taptrees and timelocks, which predates the original softfork proposal, I will be happy to update the BIP. Saying "someone might be doing this" is simply frivolous obstructionism which, again, could be used to stop any attempt to change the consensus rules." If we skip the pontential strawman of presigned transaction let's describe realistic problem. 1. You have sensible multisig wallet which breaks one of the OP_IF or merklepath restrictions. And you don't even know how it works inside. 2. To avoid confiscation you need to create a new wallet which is designed in compliance with BIP444. Is there new miniscript compiler available in time? 3. Migrate all UTXOs to new wallet 4. The real risk of confiscation are change addresses. After activation spending will work thanks to one time whitelist. But it creates a change which will be new UTXO unspendable On Monday, November 10, 2025 at 6:34:39 AM UTC+7 dath...@proton.me wrote: > Hi Greg - > > >It's not speculative-- nlocktime is a day one feature which *is* used in > Bitcoin. > > Correct, I have not claimed otherwise. > > >Sure someone could footgun themselves by intentionally using a > transaction field which is expressly intended for forward compatibility and > get themselves burned-- but they'd have to be trying, not just doing a > boring and unconcerning thing because those fields don't do anything so the > only reason to use them would be an outright error or intentionally trying > to break themselves. > > Okay, if you or anyone can show me an example of a "boring and > unconcerning thing" that involves pre-signed transactions that use > deep/OP_IF-containing Taptrees and timelocks, which predates the original > softfork proposal, I will be happy to update the BIP. Saying "someone > might be doing this" is simply frivolous obstructionism which, again, could > be used to stop any attempt to change the consensus rules. > > >This is also not a new concern being raised for your proposal, every > softfork post P2SH has been analyzed under this lens so it's quite > concerning to see the proposal here simply ignore the concern. > > I believe the utility of the strategy of "don't break any use cases, no > matter how pathological" has finally worn out. The longer we continue down > this path, the more likely it is that Bitcoin will become *entirely* > pathological use cases. > > Accordingly, this BIP *intentionally* disrupts all of the most harmful > use cases, because they are making Bitcoin worse money and the problem is > accelerating. But as stated before, the proposal also takes great pains not > to disrupt any non-pathological use cases, and again I'm open to revising > the spec if a concrete example that would be harmed by this softfork is > found. > > >And indeed I haven't read a new version because your prior message > provided no reference to it > > It is attached as a file to my email. Does your email client not support > attachments? I'll be sure to include a browser-friendly link next time if > that's the case. > > >I was responding to the summary. > > The summary mentioned that I had removed all references to legal risks. > > >Now looking at it, I see that you are still limiting scriptpubkey sizes > strictly-- this will absolutely confiscate funds as was pointed out and not > responded to even before your proposal. (because luke-jr proposed just that > limit first-- actually a more relaxed version, then simply dishonestly > insisted there was no opposition to it, even though opposition was > immediately raised on the list). > > If you're referring to Andrew Poelstra's message here > <https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs/m/4KvpvYNEAgAJ>, > that doesn't strike me as "opposition", and besides, note that this > proposal implements a very similar mitigation suggestion, which was: > > >In any case, if confiscation is a worry, as always we can exempt the > current UTXO set from the rule -- if you are only spending outputs that > existed prior to the new rule, your new UTXOs are allowed to be large. > > The current proposal exempts *inputs* that spend from the current UTXO > set, but does not allow such transactions to create outputs that violate > the new rules. This should be fine, since the funds can just be sent to a > different wallet, (assuming there is actually wallet software somewhere > that habitually creates outputs with scriptPubKeys larger than 34 bytes). > > Please let me know if this is not the "opposition" you were referring to; > I searched for a while but it's possible I missed something. Again, I am > eager to address all valid technical objections to this proposal, and so > far I haven't seen any. > > >I think your proposal continues to have no serious prospect of activation > > I disagree. I think Bitcoin users are fed up with data spam and ready to > coordinate to say "enough is enough". > > >should it activate in any form it will just be forked against > > That would be incredibly risky, but of course people are welcome to run > whatever software they choose. > > >and its authors will likely find themselves mired in litigation by people > harmed by it > > Just to clarify, are you saying that anyone who doesn't support the URSF > will face legal risks? > > >I think you'll find that almost every significant bitcoin developer will > stand against such a change and will not work on a fork that adopts them, I > also doubt the market would value your fork with such significant > limitations very highly. > > I think you are mistaken. The Bitcoin community wants Bitcoin to be money, > not data storage. > > Best, > > Dathon > On Saturday, November 8th, 2025 at 3:58 PM, Greg Maxwell < > gmax...@gmail.com> wrote: > > It's not speculative-- nlocktime is a day one feature which *is* used in > Bitcoin. > > Sure someone could footgun themselves by intentionally using a transaction > field which is expressly intended for forward compatibility and get > themselves burned-- but they'd have to be trying, not just doing a boring > and unconcerning thing because those fields don't do anything so the only > reason to use them would be an outright error or intentionally trying to > break themselves. > > This is also not a new concern being raised for your proposal, every > softfork post P2SH has been analyzed under this lens so it's quite > concerning to see the proposal here simply ignore the concern. > > Even the intentional forward compat features have caused some lack of > comfort in the past in this respect, which is why tapscript OP_SUCCESS > works the way it does: so that any script that prematurely uses a 'success' > opcode would be inherently completely insecure-- an important improvement > in upgradability that your proposal permanently destroys without you even > understanding why it existed in the first place. > > And indeed I haven't read a new version because your prior message > provided no reference to it-- it said you were requested to update the list > and then you only provided a summary. I was responding to the summary. > > Now looking at it, I see that you are still limiting scriptpubkey sizes > strictly-- this will absolutely confiscate funds as was pointed out and not > responded to even before your proposal. (because luke-jr proposed just that > limit first-- actually a more relaxed version, then simply dishonestly > insisted there was no opposition to it, even though opposition was > immediately raised on the list). > > I think your proposal continues to have no serious prospect of activation, > and should it activate in any form it will just be forked against and its > authors will likely find themselves mired in litigation by people harmed by > it. I think you'll find that almost every significant bitcoin developer > will stand against such a change and will not work on a fork that adopts > them, I also doubt the market would value your fork with such significant > limitations very highly. > > > On Sat, Nov 8, 2025 at 9:02 PM <dath...@proton.me> wrote: > >> Hi Greg - >> >> >That doesn't address the confiscation problem (although any reduction in >> the restriction does reduce it), as there likely exist chains of not yet >> confirmed (and potentially timelocked) transactions that involve violations >> of this rule. Those would appear to the network to be outputs created at a >> later time, although they really weren't. It's unclear to me why you >> haven't yet understood this point. >> >> While I completely agree that "confiscation" is a precedent we must avoid >> setting, I think my proposal neither confiscates funds nor sets a bad >> precedent, as it takes pains to avoid causing problems for all known use >> cases. I don't think it is reasonable never to create problems for all >> *unknown* use cases, as this would necessarily imply permanent >> ossification. >> >> To illustrate the point: it is possible to design off-chain systems that >> "use" any given feature of the Bitcoin protocol, including, for example, >> OP_NOPs. Funds locked in such UTXOs would be "confiscated" by the softfork >> proposal that redefines the OP_NOP. That is, anyone could intentionally >> lock funds into a pathological construction in order to obstruct any given >> softfork. >> >> Thus, if taken to the extreme, the argument that no one should ever have >> funds "confiscated", or even temporarily frozen, means that we can never >> upgrade Bitcoin again. So, in the interest of avoiding permanent >> ossification, it seems wise for us to compromise somewhere in the middle. I >> think my proposal strikes a good balance. >> >> Of course, if people are reporting that there are known, non-pathological >> use cases with significant funds locked into pre-signed transactions, then >> of course I will modify the proposal to accommodate them. >> >> >Another issue raised which you have not mentioned is that prior to you >> making this proposal I received minutes from a meeting which noted that >> Ocean Mining was the true author of this proposal and would be presenting >> it under a false identity in order to conceal their involvement. Will you >> be correcting the record on the true authorship of this work and on whose >> behalf its being performed? >> >> It sounds like you have fallen victim to some false rumors. >> >> I already attempted to correct the record on this, both here on this >> mailing list and on the BIP PR, but both times my messages were suppressed >> by moderators. >> >> I humbly request that moderators let the public see my response this >> time, otherwise I'm not sure how the record will ever be corrected: >> >> Though I am in direct communication with some Ocean employees (and the >> BIP was originally drafted by one of them), *I am not affiliated with >> Ocean in any way*. I am just a Bitcoin dev who is concerned about the >> implications of Core 30 having been released and gaining adoption. >> >> *I am acting solely on my own behalf and on the behalf of the Bitcoin >> community*, because I and most Bitcoiners I know are concerned about >> Bitcoin's future if it embraces data storage as a supported use case. >> >> This proposal is also a significant departure from the original BIP draft. >> >> >Would you then agree that this proposal will fail at its stated purpose, >> particularly with respect to concerns about potentially 'unlawful' material? >> >> No, I think this proposal is the best way to achieve its stated purpose, >> which is to reject the standardization of data storage as a supported use >> case, at the consensus level. >> >> It sounds like you haven't read the new version of the BIP, nor my >> summary above. I attached the document in my previous email message if you >> are interested. It removes all references to legal risks. >> >> For those who prefer viewing the proposal in a browser, I have pushed a >> copy of it to a non-PR branch, since the PR is still locked: >> https://github.com/dathonohm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.mediawiki >> >> >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? >> >> Again, this is no longer applicable to the proposal. The new draft makes >> significant changes. >> >> >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) >> >> I don't see this softfork as an "update-blocking action"; on the >> contrary, I see it as an update-enabling one. As I stated previously, >> attempting to never disrupt any use cases, no matter how pathological, is >> the fastest path to ossification. >> >> Indeed, Bitcoin has failed to make any consensus upgrades at all since >> Taproot in 2021. The community has been going in circles now for two years >> because of pathological use cases introduced by that fork, and this >> proposal allows Bitcoiners to say "enough is enough", re-affirm that >> Bitcoin is *money* rather than *data storage* by disabling all the most >> popular methods of data abuse, and move on to more exciting things. We >> could have new upgrades in one year if Bitcoiners focus on building them >> over the following months. >> >> I honestly don't see a better way out of this morass, but please let me >> know your reasoning if you disagree. Inaction is not going to solve this. >> >> >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 don't see much reason *not* to adopt it, besides fear of softforks in >> general, but I'm listening. >> >> >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. >> >> I don't see why anyone in their right mind would choose to bet on the old >> fork where Bitcoin is filled with spam and confused about whether it might >> want to just be a database, over the new one where Bitcoin is money. >> >> Best regards, >> >> Dathon >> On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell < >> gmax...@gmail.com> wrote: >> >> On Sat, Nov 8, 2025 at 12:58 AM dathonohm via Bitcoin Development Mailing >> List <bitco...@googlegroups.com> wrote: >> >>> >>> 1. "Funds confiscation": due to the presence of UTXOs that would be >>> made temporarily unspendable by this proposal, commenters were concerned >>> that this would set a precedent of "confiscation". This new draft resolves >>> this concern by adding a UTXO height check to make sure *only UTXOs >>> that are created while the softfork is active will be made temporarily >>> unspendable*. The "OP_IF in Tapscript" and "257-byte control block >>> limit" were the two main proposed rule changes that caused concern here. >>> >>> >> That doesn't address the confiscation problem (although any reduction in >> the restriction does reduce it), as there likely exist chains of not yet >> confirmed (and potentially timelocked) transactions that involve violations >> of this rule. Those would appear to the network to be outputs created at a >> later time, although they really weren't. It's unclear to me why you >> haven't yet understood this point. >> >> I don't think this concern was in any way limited to the control block of >> op_if components either, essentially every aspect of the proposal has >> confiscation issues. >> >> Another issue raised which you have not mentioned is that prior to you >> making this proposal I received minutes from a meeting which noted that >> Ocean Mining was the true author of this proposal and would be presenting >> it under a false identity in order to conceal their involvement. Will you >> be correcting the record on the true authorship of this work and on whose >> behalf its being performed? >> >> > "This doesn't block all possible methods of arbitrary data insertion": >> This was already addressed in the previous draft, but to reiterate: this >> proposal's goal is not to block *all* methods of arbitary data >> insertion, just the most commonly abused ones. >> >> 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+...@googlegroups.com. >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.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+...@googlegroups.com. > > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTCFx2yvvUu9YWwcm-SSojT530Uwzi0b3sOG0%2BVZEcaAw%40mail.gmail.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/86d11552-36d8-46d7-998c-ed6875a5a84bn%40googlegroups.com. [-- Attachment #1.2: Type: text/html, Size: 36323 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-11-11 7:43 ` 'Bitcoin Eagle' via Bitcoin Development Mailing List @ 2025-11-11 16:23 ` Greg Maxwell 0 siblings, 0 replies; 30+ messages in thread From: Greg Maxwell @ 2025-11-11 16:23 UTC (permalink / raw) To: Bitcoin Eagle; +Cc: Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 22622 bytes --] Presigned transactions are quite real and are used by people, e.g. for inheritance so you can allow your inheritors (or you) to recover your coins in the future via a more accessible file, while securing the wallet that can immediately spend to a level that might otherwise cause accidental funds loss. They're more flexible than having to stick a recovery alternative in script and though a relative locktime would be more reliable, unfortunately they can't be set much into the future under current consensus rules. Not everyone is luke-jr whose security practices are to keep a copy of his 'offline' wallet on an online system with a copy of the passphrase for it just stored in a file next to it. Had that file had presigned transactions set a couple years out, he probably wouldn't have turned into an involuntary nocoiner more interested in getting his way that preserving Bitcoin's value and stability and we wouldn't need to debate a proposal that lobotomizes Bitcoin's functionality and will seize users funds just to further his vanity project. Not everyone is eager to go into details about their own assets and security practices, potentially compromising their privacy and safety. -- and likely most impacted people have no idea of the risk it has for them, especially when the schemes author is online outright lying about its properties: https://x.com/LukeDashjr/status/1987267143612703150 (He could debate the degree of confiscation risk,-- though I know for a fact that it's a certainty-- but saying there is *none* is just a toxic lie that should cause us to reject his proposal on the principle that the proposals true creator is outright deceiving the public about it) On Tue, Nov 11, 2025 at 8:28 AM 'Bitcoin Eagle' via Bitcoin Development Mailing List <bitcoindev@googlegroups.com> wrote: > "Okay, if you or anyone can show me an example of a "boring and > unconcerning thing" that involves pre-signed transactions that use > deep/OP_IF-containing Taptrees and timelocks, which predates the original > softfork proposal, I will be happy to update the BIP. Saying "someone might > be doing this" is simply frivolous obstructionism which, again, could be > used to stop any attempt to change the consensus rules." > > If we skip the pontential strawman of presigned transaction let's describe > realistic problem. > > 1. You have sensible multisig wallet which breaks one of the OP_IF or > merklepath restrictions. And you don't even know how it works inside. > 2. To avoid confiscation you need to create a new wallet which is > designed in compliance with BIP444. Is there new miniscript compiler > available in time? > 3. Migrate all UTXOs to new wallet > 4. The real risk of confiscation are change addresses. After > activation spending will work thanks to one time whitelist. But it creates > a change which will be new UTXO unspendable > > > On Monday, November 10, 2025 at 6:34:39 AM UTC+7 dath...@proton.me wrote: > >> Hi Greg - >> >> >It's not speculative-- nlocktime is a day one feature which *is* used in >> Bitcoin. >> >> Correct, I have not claimed otherwise. >> >> >Sure someone could footgun themselves by intentionally using a >> transaction field which is expressly intended for forward compatibility and >> get themselves burned-- but they'd have to be trying, not just doing a >> boring and unconcerning thing because those fields don't do anything so the >> only reason to use them would be an outright error or intentionally trying >> to break themselves. >> >> Okay, if you or anyone can show me an example of a "boring and >> unconcerning thing" that involves pre-signed transactions that use >> deep/OP_IF-containing Taptrees and timelocks, which predates the >> original softfork proposal, I will be happy to update the BIP. Saying >> "someone might be doing this" is simply frivolous obstructionism which, >> again, could be used to stop any attempt to change the consensus rules. >> >> >This is also not a new concern being raised for your proposal, every >> softfork post P2SH has been analyzed under this lens so it's quite >> concerning to see the proposal here simply ignore the concern. >> >> I believe the utility of the strategy of "don't break any use cases, no >> matter how pathological" has finally worn out. The longer we continue down >> this path, the more likely it is that Bitcoin will become *entirely* >> pathological use cases. >> >> Accordingly, this BIP *intentionally* disrupts all of the most harmful >> use cases, because they are making Bitcoin worse money and the problem is >> accelerating. But as stated before, the proposal also takes great pains not >> to disrupt any non-pathological use cases, and again I'm open to revising >> the spec if a concrete example that would be harmed by this softfork is >> found. >> >> >And indeed I haven't read a new version because your prior message >> provided no reference to it >> >> It is attached as a file to my email. Does your email client not support >> attachments? I'll be sure to include a browser-friendly link next time if >> that's the case. >> >> >I was responding to the summary. >> >> The summary mentioned that I had removed all references to legal risks. >> >> >Now looking at it, I see that you are still limiting scriptpubkey sizes >> strictly-- this will absolutely confiscate funds as was pointed out and not >> responded to even before your proposal. (because luke-jr proposed just that >> limit first-- actually a more relaxed version, then simply dishonestly >> insisted there was no opposition to it, even though opposition was >> immediately raised on the list). >> >> If you're referring to Andrew Poelstra's message here >> <https://groups.google.com/g/bitcoindev/c/YO8ZwnG_ISs/m/4KvpvYNEAgAJ>, >> that doesn't strike me as "opposition", and besides, note that this >> proposal implements a very similar mitigation suggestion, which was: >> >> >In any case, if confiscation is a worry, as always we can exempt the >> current UTXO set from the rule -- if you are only spending outputs that >> existed prior to the new rule, your new UTXOs are allowed to be large. >> >> The current proposal exempts *inputs* that spend from the current UTXO >> set, but does not allow such transactions to create outputs that violate >> the new rules. This should be fine, since the funds can just be sent to a >> different wallet, (assuming there is actually wallet software somewhere >> that habitually creates outputs with scriptPubKeys larger than 34 bytes). >> >> Please let me know if this is not the "opposition" you were referring to; >> I searched for a while but it's possible I missed something. Again, I am >> eager to address all valid technical objections to this proposal, and so >> far I haven't seen any. >> >> >I think your proposal continues to have no serious prospect of activation >> >> I disagree. I think Bitcoin users are fed up with data spam and ready to >> coordinate to say "enough is enough". >> >> >should it activate in any form it will just be forked against >> >> That would be incredibly risky, but of course people are welcome to run >> whatever software they choose. >> >> >and its authors will likely find themselves mired in litigation by >> people harmed by it >> >> Just to clarify, are you saying that anyone who doesn't support the URSF >> will face legal risks? >> >> >I think you'll find that almost every significant bitcoin developer will >> stand against such a change and will not work on a fork that adopts them, I >> also doubt the market would value your fork with such significant >> limitations very highly. >> >> I think you are mistaken. The Bitcoin community wants Bitcoin to be >> money, not data storage. >> >> Best, >> >> Dathon >> On Saturday, November 8th, 2025 at 3:58 PM, Greg Maxwell < >> gmax...@gmail.com> wrote: >> >> It's not speculative-- nlocktime is a day one feature which *is* used in >> Bitcoin. >> >> Sure someone could footgun themselves by intentionally using a >> transaction field which is expressly intended for forward compatibility and >> get themselves burned-- but they'd have to be trying, not just doing a >> boring and unconcerning thing because those fields don't do anything so the >> only reason to use them would be an outright error or intentionally trying >> to break themselves. >> >> This is also not a new concern being raised for your proposal, every >> softfork post P2SH has been analyzed under this lens so it's quite >> concerning to see the proposal here simply ignore the concern. >> >> Even the intentional forward compat features have caused some lack of >> comfort in the past in this respect, which is why tapscript OP_SUCCESS >> works the way it does: so that any script that prematurely uses a 'success' >> opcode would be inherently completely insecure-- an important improvement >> in upgradability that your proposal permanently destroys without you even >> understanding why it existed in the first place. >> >> And indeed I haven't read a new version because your prior message >> provided no reference to it-- it said you were requested to update the list >> and then you only provided a summary. I was responding to the summary. >> >> Now looking at it, I see that you are still limiting scriptpubkey sizes >> strictly-- this will absolutely confiscate funds as was pointed out and not >> responded to even before your proposal. (because luke-jr proposed just that >> limit first-- actually a more relaxed version, then simply dishonestly >> insisted there was no opposition to it, even though opposition was >> immediately raised on the list). >> >> I think your proposal continues to have no serious prospect of >> activation, and should it activate in any form it will just be forked >> against and its authors will likely find themselves mired in litigation by >> people harmed by it. I think you'll find that almost every significant >> bitcoin developer will stand against such a change and will not work on a >> fork that adopts them, I also doubt the market would value your fork with >> such significant limitations very highly. >> >> >> On Sat, Nov 8, 2025 at 9:02 PM <dath...@proton.me> wrote: >> >>> Hi Greg - >>> >>> >That doesn't address the confiscation problem (although any reduction >>> in the restriction does reduce it), as there likely exist chains of not yet >>> confirmed (and potentially timelocked) transactions that involve violations >>> of this rule. Those would appear to the network to be outputs created at a >>> later time, although they really weren't. It's unclear to me why you >>> haven't yet understood this point. >>> >>> While I completely agree that "confiscation" is a precedent we must >>> avoid setting, I think my proposal neither confiscates funds nor sets a bad >>> precedent, as it takes pains to avoid causing problems for all known use >>> cases. I don't think it is reasonable never to create problems for all >>> *unknown* use cases, as this would necessarily imply permanent >>> ossification. >>> >>> To illustrate the point: it is possible to design off-chain systems that >>> "use" any given feature of the Bitcoin protocol, including, for example, >>> OP_NOPs. Funds locked in such UTXOs would be "confiscated" by the softfork >>> proposal that redefines the OP_NOP. That is, anyone could intentionally >>> lock funds into a pathological construction in order to obstruct any given >>> softfork. >>> >>> Thus, if taken to the extreme, the argument that no one should ever have >>> funds "confiscated", or even temporarily frozen, means that we can never >>> upgrade Bitcoin again. So, in the interest of avoiding permanent >>> ossification, it seems wise for us to compromise somewhere in the middle. I >>> think my proposal strikes a good balance. >>> >>> Of course, if people are reporting that there are known, >>> non-pathological use cases with significant funds locked into pre-signed >>> transactions, then of course I will modify the proposal to accommodate them. >>> >>> >Another issue raised which you have not mentioned is that prior to you >>> making this proposal I received minutes from a meeting which noted that >>> Ocean Mining was the true author of this proposal and would be presenting >>> it under a false identity in order to conceal their involvement. Will you >>> be correcting the record on the true authorship of this work and on whose >>> behalf its being performed? >>> >>> It sounds like you have fallen victim to some false rumors. >>> >>> I already attempted to correct the record on this, both here on this >>> mailing list and on the BIP PR, but both times my messages were suppressed >>> by moderators. >>> >>> I humbly request that moderators let the public see my response this >>> time, otherwise I'm not sure how the record will ever be corrected: >>> >>> Though I am in direct communication with some Ocean employees (and the >>> BIP was originally drafted by one of them), *I am not affiliated with >>> Ocean in any way*. I am just a Bitcoin dev who is concerned about the >>> implications of Core 30 having been released and gaining adoption. >>> >>> *I am acting solely on my own behalf and on the behalf of the Bitcoin >>> community*, because I and most Bitcoiners I know are concerned about >>> Bitcoin's future if it embraces data storage as a supported use case. >>> >>> This proposal is also a significant departure from the original BIP >>> draft. >>> >>> >Would you then agree that this proposal will fail at its stated >>> purpose, particularly with respect to concerns about potentially 'unlawful' >>> material? >>> >>> No, I think this proposal is the best way to achieve its stated purpose, >>> which is to reject the standardization of data storage as a supported use >>> case, at the consensus level. >>> >>> It sounds like you haven't read the new version of the BIP, nor my >>> summary above. I attached the document in my previous email message if you >>> are interested. It removes all references to legal risks. >>> >>> For those who prefer viewing the proposal in a browser, I have pushed a >>> copy of it to a non-PR branch, since the PR is still locked: >>> https://github.com/dathonohm/bips/blob/reduced-data-v2/bip-%3F%3F%3F%3F.mediawiki >>> >>> >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? >>> >>> Again, this is no longer applicable to the proposal. The new draft makes >>> significant changes. >>> >>> >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) >>> >>> I don't see this softfork as an "update-blocking action"; on the >>> contrary, I see it as an update-enabling one. As I stated previously, >>> attempting to never disrupt any use cases, no matter how pathological, is >>> the fastest path to ossification. >>> >>> Indeed, Bitcoin has failed to make any consensus upgrades at all since >>> Taproot in 2021. The community has been going in circles now for two years >>> because of pathological use cases introduced by that fork, and this >>> proposal allows Bitcoiners to say "enough is enough", re-affirm that >>> Bitcoin is *money* rather than *data storage* by disabling all the most >>> popular methods of data abuse, and move on to more exciting things. We >>> could have new upgrades in one year if Bitcoiners focus on building them >>> over the following months. >>> >>> I honestly don't see a better way out of this morass, but please let me >>> know your reasoning if you disagree. Inaction is not going to solve this. >>> >>> >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 don't see much reason *not* to adopt it, besides fear of softforks in >>> general, but I'm listening. >>> >>> >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. >>> >>> I don't see why anyone in their right mind would choose to bet on the >>> old fork where Bitcoin is filled with spam and confused about whether it >>> might want to just be a database, over the new one where Bitcoin is money. >>> >>> Best regards, >>> >>> Dathon >>> On Saturday, November 8th, 2025 at 9:48 AM, Greg Maxwell < >>> gmax...@gmail.com> wrote: >>> >>> On Sat, Nov 8, 2025 at 12:58 AM dathonohm via Bitcoin Development >>> Mailing List <bitco...@googlegroups.com> wrote: >>> >>>> >>>> 1. "Funds confiscation": due to the presence of UTXOs that would be >>>> made temporarily unspendable by this proposal, commenters were concerned >>>> that this would set a precedent of "confiscation". This new draft resolves >>>> this concern by adding a UTXO height check to make sure *only UTXOs >>>> that are created while the softfork is active will be made temporarily >>>> unspendable*. The "OP_IF in Tapscript" and "257-byte control block >>>> limit" were the two main proposed rule changes that caused concern here. >>>> >>>> >>> That doesn't address the confiscation problem (although any reduction in >>> the restriction does reduce it), as there likely exist chains of not yet >>> confirmed (and potentially timelocked) transactions that involve violations >>> of this rule. Those would appear to the network to be outputs created at a >>> later time, although they really weren't. It's unclear to me why you >>> haven't yet understood this point. >>> >>> I don't think this concern was in any way limited to the control block >>> of op_if components either, essentially every aspect of the proposal has >>> confiscation issues. >>> >>> Another issue raised which you have not mentioned is that prior to you >>> making this proposal I received minutes from a meeting which noted that >>> Ocean Mining was the true author of this proposal and would be presenting >>> it under a false identity in order to conceal their involvement. Will you >>> be correcting the record on the true authorship of this work and on whose >>> behalf its being performed? >>> >>> > "This doesn't block all possible methods of arbitrary data >>> insertion": This was already addressed in the previous draft, but to >>> reiterate: this proposal's goal is not to block *all* methods of >>> arbitary data insertion, just the most commonly abused ones. >>> >>> 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+...@googlegroups.com. >>> To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQy%2BqiRv%3DwGHB5_5Hgxmj9kbJiT9PXpd1VbiUFPwATg-g%40mail.gmail.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+...@googlegroups.com. >> >> To view this discussion visit >> https://groups.google.com/d/msgid/bitcoindev/CAAS2fgTCFx2yvvUu9YWwcm-SSojT530Uwzi0b3sOG0%2BVZEcaAw%40mail.gmail.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/86d11552-36d8-46d7-998c-ed6875a5a84bn%40googlegroups.com > <https://groups.google.com/d/msgid/bitcoindev/86d11552-36d8-46d7-998c-ed6875a5a84bn%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/CAAS2fgR7wKyV3vgwTrqidhyDz6CAU%3D4aGCT%3D6jr8fDM6UMQbrw%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 38339 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-11-08 21:02 ` dathonohm via Bitcoin Development Mailing List 2025-11-08 21:39 ` Greg Maxwell @ 2025-11-09 1:21 ` Murch 2025-11-09 20:56 ` onyxcoyote 1 sibling, 1 reply; 30+ messages in thread From: Murch @ 2025-11-09 1:21 UTC (permalink / raw) To: bitcoindev Hello Dathon, On 2025-11-08 13:02, dathonohm via Bitcoin Development Mailing List wrote: > For those who prefer viewing the proposal in a browser, I have pushed a > copy of it to a non-PR branch, since the PR is still locked: https:// > github.com/dathonohm/bips/blob/reduced-data-v2/bip- > %3F%3F%3F%3F.mediawiki <https://github.com/dathonohm/bips/blob/reduced- > data-v2/bip-%3F%3F%3F%3F.mediawiki> You may have missed that the pull request “BIP draft: Reduced Data Temporary Softfork #2017” was unlocked¹ at 2025-11-08T13:22Z, almost exactly 12h ago at the time of writing. The accompanying comment² that pointed this out, notified you explicitly by mention of your username. Murch ¹ https://github.com/bitcoin/bips/pull/2017#event-20807801629 ² https://github.com/bitcoin/bips/pull/2017#issuecomment-3506542546 -- 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/5370ae82-7abe-4790-a1ab-e1a7334ef382%40murch.one. ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-11-09 1:21 ` Murch @ 2025-11-09 20:56 ` onyxcoyote 0 siblings, 0 replies; 30+ messages in thread From: onyxcoyote @ 2025-11-09 20:56 UTC (permalink / raw) To: Bitcoin Development Mailing List [-- 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 --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-11-08 0:51 ` dathonohm via Bitcoin Development Mailing List ` (2 preceding siblings ...) 2025-11-08 15:38 ` Greg Maxwell @ 2025-11-09 21:34 ` Peter Todd 3 siblings, 0 replies; 30+ messages in thread From: Peter Todd @ 2025-11-09 21:34 UTC (permalink / raw) To: dathonohm; +Cc: Erik Aronesty, Antoine Riard, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 3377 bytes --] On Sat, Nov 08, 2025 at 12:51:49AM +0000, dathonohm via Bitcoin Development Mailing List wrote: > Hi all - > > BIP repo maintainers [requested](https://github.com/bitcoin/bips/pull/2017#issuecomment-3462134337) that I update this list before pushing a significant change, so I am doing that now. > > Please consider this my formal request for the BIP PR to be unlocked so that discussion can resume. I see that a block-height-based activation date has been proposed, approximately Feb 1st 2026 depending on how fast blocks are mined. Your BIP does not discuss the fact that such a UASF activation is highly likely to lead to two different coins, the unmodified chain accepted by the majority of hash power, and the minority hash power fork. If you thought you could get supermajority hashpower support, you would have simply proposed a hash-power activation, e.g. the 95% treshold used by my own BIP-65 soft-fork, CheckLockTimeVerify. Clearly you do not believe you can get supermajority hashpower support. Even without commenting on the desirability of such a fork, you need to openly discuss it in your BIP and explain how the community will be able to deal with it. For example, how wallets can safely "split" coins between either side of the fork, and how you intend to modify Bitcoin addresses so people don't accidentally send coins to the wrong side. Of course - again without commenting on the desirability of this fork - I personally believe that such a short timeframe is utterly absurd for a UASF with no miner activation mechanism at all. > This update addresses several concerns from the previous draft: The BIP continues to fail to answer obvious questions. For example the very first paragraph in your technical rational states: > ''Why limit scriptPubKeys to 34 bytes?''' > > scriptPubKeys must be stored indefinitely in quick-access memory (often RAM) by all fully validating nodes. > It generally cannot be pruned. > It is also a direct cost to the sender rather than the receiver. For these reasons, modern usage is all 34 bytes or smaller in practice: > actual spending conditions have been moved to the witness, and the scriptPubKey simply commits to them in advance with a hash. Obviously, entities that actually need to publish data in scriptPubKey's will simply use more of them instead of OP_Return. You write this section as though your argument is an actual rationale. But clearly, this rational is simply bogus. You're actual rationale appears to be simply a moral one: you want to put restrictions on transactions to send a *message* that use of Bitcoin for data publishing is wrong. Even though otherwise you appear to admit that this BIP will not in fact provide any real technical obstacle to publishing data in Bitcoin (as me publishing the previous draft in the chain itself proved). Unless you have an actual technical justification, arguments such as the above are highly dishonest and need to be removed from your BIP. -- https://petertodd.org 'peter'[:-1]@petertodd.org -- 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/aREI6ZdvJmsZ-J6U%40petertodd.org. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-10-30 2:43 ` Erik Aronesty 2025-11-08 0:51 ` dathonohm via Bitcoin Development Mailing List @ 2025-11-10 19:46 ` Lucas Barbosa 1 sibling, 0 replies; 30+ messages in thread From: Lucas Barbosa @ 2025-11-10 19:46 UTC (permalink / raw) To: Erik Aronesty; +Cc: Antoine Riard, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 2759 bytes --] >Okay, if you or anyone can show me an example of a "boring and unconcerning thing" that involves pre-signed transactions that use deep/OP_IF-containing Taptrees and timelocks, which predates the original softfork proposal, I will be happy to update the BIP. Saying "someone might be doing this" is simply frivolous obstructionism which, again, could be used to stop any attempt to change the consensus rules. Hello Dathon The responsibility to demonstrate this is yours, it is you who is hastily proposing an emergency change. the more information you can bring, the easier it will be for you to get what you want Em qua., 29 de out. de 2025, 23:57, Erik Aronesty <erik@q32.com> escreveu: > >> Case law in the USA regarding illegal content has always rested squarely >> on those who: > > > 1 - provide broad public access, in this case a company like OpenSEA > (which has had to block content) > 2 - the original author > > if punishing "relays" was a thing, then every CISCO router, SMTP relay and > DISCORD server that provided access would be in court all day long > > instead, it's the users of the illegal data and the publishers that > actually wind up in trouble - not the internet providers > > the bitcoin ledger is neither a browser or web server, nor is it an image > uploader. there is zero ability to view images built into the system > > and even if it was > > the purpose of this software is to be a distributed and effectively > uncensorable ledger. > > hopefully it doesn't change because someone launched a meme campaign with > vague threats of legal action > > if a transaction has /no reasonable expectation of being mined/ (too > expensive to validate, too large, too low fees), there's also no reason to > relay it > > this is probably the best way to set policy > > -- > 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/CAJowKgKBBa%2BvD%3D5X0VMV2OFiBBM23Ok6nmvfoLTr8fia141%3DFQ%40mail.gmail.com > <https://groups.google.com/d/msgid/bitcoindev/CAJowKgKBBa%2BvD%3D5X0VMV2OFiBBM23Ok6nmvfoLTr8fia141%3DFQ%40mail.gmail.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/CAPbyeOFpVf9kWPzRZA9CZ--vpFZkKdroHf5nuMFV%3D_hse44i_g%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 3875 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 2025-10-27 19:56 ` Greg Maxwell 2025-10-28 5:13 ` dathonohm via Bitcoin Development Mailing List @ 2025-10-28 9:16 ` /dev /fd0 1 sibling, 0 replies; 30+ messages in thread From: /dev /fd0 @ 2025-10-28 9:16 UTC (permalink / raw) To: Greg Maxwell; +Cc: Kyle Stout, Bitcoin Development Mailing List [-- Attachment #1: Type: text/plain, Size: 9718 bytes --] Hi Greg, > There are also proposals such as BIP 337: https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki none of these things are consensus changes-- many aren't even bippable because they don't have interoperability considerations (e.g. representations on disk/memory). [Compression][0] of raw transactions is interesting although it won't be helpful in this case. I had reviewed the pull request that implemented BIP 337 in bitcoin core and was closed. Maybe we can add it in knots. > Forget for a moment the (un)likelyhood that the concerns being discussed are meaningfully modulated by exactly how data is represented in p2p, memory, rpc, disk, etc.. for assumption just assume they are. > If so, the correct move would be to change those encodings rather than any consensus rule change--- particularly because any consensus rule method will simply be evaded, and can't provide the level of swizzling that changing the encoding can accomplish. Encoding changes are also substantially non-coercive: people who think they're valuable can adopt them and leave other people alone. I am not sure if encoding or encryption would be the right approach but this is worth trying. I have opened an [issue][1] in knots repository to discuss these ideas and also created a web [page][2] that shows the binary for OP_RETURN in a transaction. [0[: https://github.com/bitcoin/bitcoin/pull/29134 [1]: https://github.com/bitcoinknots/bitcoin/issues/229 [2]: https://opreturn01.github.io/ /dev/fd0 floppy disk guy On Tue, Oct 28, 2025 at 1:28 AM Greg Maxwell <gmaxwell@gmail.com> wrote: > The only consensus normative data encoding in Bitcoin is the order data > goes into hashes. The representations in memory, rpc, in the p2p network, > etc. are already different and could be made arbitrarily different without > any consensus change. Case in point: the data is now normally encrypted > on disk and in P2P. There are also proposals such as BIP 337: > https://github.com/bitcoin/bips/blob/master/bip-0337.mediawiki none of > these things are consensus changes-- many aren't even bippable because they > don't have interoperability considerations (e.g. representations on > disk/memory). > > Forget for a moment the (un)likelyhood that the concerns being discussed > are meaningfully modulated by exactly how data is represented in p2p, > memory, rpc, disk, etc.. for assumption just assume they are. > > If so, the correct move would be to change those encodings rather than any > consensus rule change--- particularly because any consensus rule method > will simply be evaded, and can't provide the level of swizzling that > changing the encoding can accomplish. Encoding changes are also > substantially non-coercive: people who think they're valuable can adopt > them and leave other people alone. > > Good news for everyone except those who consider coercing others to be a > terminal goal. > > > > On Mon, Oct 27, 2025 at 6:35 PM Kyle Stout <kylestout85@gmail.com> wrote: > >> Dathon, >> >> > if Bitcoin provides an officially supported method of storing arbitrary >> data (i.e., OP_RETURN), and the capacity of that method is large enough to >> store hazardous content in a contiguous format (an increase to 100kB is >> currently underway as Bitcoin Core 30 gains adoption), then one does not >> need to misinterpret the data in order to view the content. >> >> This seems to be the crux of your argument. I believe it is misleading >> and technically unsound. It's technical theater that creates a distinction >> without any meaningful difference. >> >> First, Bitcoin has no concept of a file viewer. To interpret *any* >> embedded data other to validate it against Bitcoin's rules, you must use a >> third party tool. Practically speaking, the differences are negligible in >> terms of technical difficulty, as humorously demonstrated here: >> https://x.com/rot13maxi/status/1963318690759192622 . Contiguous or not, >> you're file carving. >> >> Second, by definition, you're misinterpreting the data vis-a-vis Bitcoin >> since it has no native concept of 'image', 'video', etc. Arbitrary bytes >> are meaningless. The purpose of having OP_RETURN as a standard output is to >> protect the UTXO set from being abused. It isn't some kind of 'blessing' to >> store files. That's absurd. As you admit, it's impossible to stop people >> from writing arbitrary bytes to the blockchain, so this is damage >> mitigation, not an invitation. >> >> Third, contiguity is not a legally meaningful predicate. "Your honor, we >> tried to limit the contiguous bytes!" is simply not going to fly. The bytes >> exist either way, and they must be interpreted by third party software >> either way. If anything, this path is going to represent a voluntary >> self-policing that will result in more culpability. Right now, arbitrary >> bytes don't mean anything in Bitcoin. If it's valid, it's valid. Nodes >> relay opaque protocol data. If you insist on only accepting 'approved' >> arbitrary bytes, you're opening the door to a knowledge/intent accusation. >> >> Regards, >> >> Kyle >> >> >> >> On Monday, October 27, 2025 at 1:36:33 AM UTC-4 dath...@proton.me wrote: >> >>> Peter - >>> >>> Thank you for demonstrating what non-contiguous data looks like. >>> >>> I trust you when you say that you can parse the BIP's contents from this >>> transaction, but all it looks like to me (and the Bitcoin network) is a >>> UTXO broken into 31 pieces then (mostly) re-consolidated into a 0-length >>> OP_RETURN, sending all ~100 USD in fees to the miner. >>> >>> Since legally hazardous content can be generated from any input data, >>> including your 30-input consolidation transaction (as long as the correct >>> third-party program is used), it would not make sense to hold node >>> operators legally responsible for storing and distributing such input data. >>> >>> However, if Bitcoin provides an officially supported method of storing >>> arbitrary data (i.e., OP_RETURN), and the capacity of that method is large >>> enough to store hazardous content in a contiguous format (an increase to >>> 100kB is currently underway as Bitcoin Core 30 gains adoption), then one >>> does not need to misinterpret the data in order to view the content. In >>> that case, node operators could conceivably be held responsible for >>> possession and distribution. >>> >>> Since arbitrary data storage does nothing to benefit Bitcoin as >>> permissionless money, there is no good reason to force this additional >>> legal risk on node operators, who already face enough challenges as it is. >>> >>> Best, >>> >>> Dathon >>> >>> >>> On Sunday, October 26th, 2025 at 4:43 PM, Peter Todd < >>> pe...@petertodd.org> wrote: >>> >>> > On Sat, Oct 25, 2025 at 08:43:11PM +0000, dathonohm via Bitcoin >>> Development Mailing List wrote: >>> > >>> > > Hi list - >>> > > >>> > > Due to Bitcoin Core v30 gaining in popularity, it has become >>> necessary to move forward on luke-jr's ML proposal to temporarily limit >>> arbitrary data at the consensus level, which so far has 3 weeks with no >>> objections: >>> > > >>> > > https://github.com/bitcoin/bips/pull/2017 >>> > >>> > >>> > Transaction >>> 8e2ee13d2a19951c2777bb3a54f0cb69a2f76dae8baa954cd86149ed1138cb6c >>> > contains the full text of this BIP as of writing(1), while >>> simultaneously being >>> > compliant with that BIP. >>> > >>> > Clearly, this approach is ineffective. >>> > >>> > 1) >>> https://github.com/bitcoin/bips/blob/3c718237072c107ced8c3531a487354fbdae55df/bip-%3F%3F%3F%3F.mediawiki >>> > >>> > -- >>> > https://petertodd.org 'peter'[:-1]@petertodd.org >>> > >>> > -- >>> > 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+...@googlegroups.com. >>> > To view this discussion visit >>> https://groups.google.com/d/msgid/bitcoindev/aP6gYSnte7J86g0p%40petertodd.org. >>> >>> >> -- >> 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/7abf7055-6b85-492f-ada2-e0a517e93cf9n%40googlegroups.com >> <https://groups.google.com/d/msgid/bitcoindev/7abf7055-6b85-492f-ada2-e0a517e93cf9n%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/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.com > <https://groups.google.com/d/msgid/bitcoindev/CAAS2fgQRQWwX76o8QHjt8FoLxJiq1B-FgP%2BpehOL8PYhWgewbg%40mail.gmail.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/CALiT-ZrT%2BR7ApsQJOtKM5h5xTThGL-WMyCRDwt29sXmt4AA%2BRg%40mail.gmail.com. [-- Attachment #2: Type: text/html, Size: 12349 bytes --] ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2025-11-11 17:33 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2025-10-25 20:43 [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork 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 2025-11-09 21:34 ` Peter Todd 2025-11-10 19:46 ` Lucas Barbosa 2025-10-28 9:16 ` /dev /fd0
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox