From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Sat, 08 Nov 2025 03:53:54 -0800 Received: from mail-oa1-f61.google.com ([209.85.160.61]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1vHhVx-0002Z9-IB for bitcoindev@gnusha.org; Sat, 08 Nov 2025 03:53:54 -0800 Received: by mail-oa1-f61.google.com with SMTP id 586e51a60fabf-3c96e523b03sf3677864fac.3 for ; Sat, 08 Nov 2025 03:53:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1762602827; x=1763207627; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :from:to:cc:subject:date:message-id:reply-to; bh=o557p97TnukM9AmsGjZTm/vbtfnNhxl4FL9SeQzuD1U=; b=YCWDowVgw0sknzKlSH++Tg0y6WFi4OQIrt1reKy+Ct3ankbD0Bo+bwILUo2ez4hih/ QxoV+3k8AlNJHreUClt3rf6bJKmvNXbWtNvfVfGCEFIzAx4Qxkm7uKqWe5f6nt3+MdRx VQtYf7LIKXt9ne0fggVnPeSvW6jk6edibTxM79qY894NkIfwJeB1XqWaDXtXjzS/+EI2 6P1uphXmUj/zQnjkTeaVKcN6u12rG8AsUyp4EQNray0DTkRPFmVhrSWa8/Ll/Wc3ttGh 6LW/BIgBJdkphTv94GVKdpcoYd9AcZDvDaAhavanK7mzaB+8pSqXvDiyCThZ1s2r0TLm SnBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1762602827; x=1763207627; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:x-original-sender :mime-version:subject:references:in-reply-to:message-id:to:from:date :x-beenthere:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=o557p97TnukM9AmsGjZTm/vbtfnNhxl4FL9SeQzuD1U=; b=wLC8umtq+ja1tS5xOhxUf6efvD/DiMniXH7fDjb6ilUBclgfH2gMyeHIQXy2bnz1vk /eYWX207Q+NBvNfVxRvVWA1LSGoYSckMQdrkquhvjkzZJHVemDwME8KgujU4EBl639w8 P3jbb4gYBt0Ix/lKFC2RUJwlhrIOyEiCwruDWsADu1TnvkiA22aUosMM91QPZPqJa4+E XCemrpBgtM5tyuMVNAGvdIG5DJhveBUQoAajD9K/dV4T9bBPVZ5/z8jCrVf2dEg2cLiL AQwFTFISQLX1Cu0MAGvIq6rkDg7Lb7YBsG6Z/riGwO+baCKeaXQnmVFN825eS6t/3hes h1xA== X-Forwarded-Encrypted: i=1; AJvYcCW/zJYDaTGPV0oJW8gAqqNqUQX9+OW8TxjPz9x9c6UeMudE6JhK+0v94jgQEvu4HM4hSMmGfnLyKHkg@gnusha.org X-Gm-Message-State: AOJu0YwEAL7YWIfLqyRF+haa2h593oC3DLELAsinJKFyVuAotVFwKE5G zVuZWmGQMCGaSPM6oVo/lDTYaWEhPKfV7/2S1NRL0p/AcgOEQC4Tmnnx X-Google-Smtp-Source: AGHT+IF6IIXNE+/pa0t6be8DfMZK8czIOb7evDPIKciCJTbqcceVS4Jo4XmuNSTbN1cpwcT730wunw== X-Received: by 2002:a05:687c:20d2:b0:340:5682:7219 with SMTP id 586e51a60fabf-3e7c286c2b8mr1448141fac.27.1762602826829; Sat, 08 Nov 2025 03:53:46 -0800 (PST) X-BeenThere: bitcoindev@googlegroups.com; h="Ae8XA+bmE5gC/7qvs7gNp7t2yWmXn5Eilj/vt5AWTEw4OpkUJQ==" Received: by 2002:a05:6871:241b:b0:3d5:54c4:3245 with SMTP id 586e51a60fabf-3e2f5274de6ls1813038fac.2.-pod-prod-01-us; Sat, 08 Nov 2025 03:53:43 -0800 (PST) X-Received: by 2002:a05:6808:320f:b0:450:7df:e90b with SMTP id 5614622812f47-4502a44da7cmr1044846b6e.52.1762602823182; Sat, 08 Nov 2025 03:53:43 -0800 (PST) Received: by 2002:a05:690c:55c3:20b0:786:8d90:70d8 with SMTP id 00721157ae682-786a513df0ams7b3; Sat, 8 Nov 2025 01:30:41 -0800 (PST) X-Received: by 2002:a05:690c:7401:b0:786:5620:fae9 with SMTP id 00721157ae682-787d5470b0emr16929747b3.54.1762594239328; Sat, 08 Nov 2025 01:30:39 -0800 (PST) Date: Sat, 8 Nov 2025 01:30:39 -0800 (PST) From: "'Bitcoin Eagle' via Bitcoin Development Mailing List" To: Bitcoin Development Mailing List Message-Id: <6ff66d86-848f-493d-a0dd-4ff8ea42f932n@googlegroups.com> In-Reply-To: References: <7U8YuMopR73k4XRYBA8DjhaGLJkyKPuXpxW9p7vmH45JHEyIj_oE_t4xk99hrNdvMGghpmooAMXOmWGaZ4UkwHPndzrpzIL0SX2SoTf0l3w=@proton.me> <7abf7055-6b85-492f-ada2-e0a517e93cf9n@googlegroups.com> Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_482668_1786765761.1762594239069" X-Original-Sender: hello@bitcoineagle.dev X-Original-From: Bitcoin Eagle Reply-To: Bitcoin Eagle Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -1.0 (-) ------=_Part_482668_1786765761.1762594239069 Content-Type: multipart/alternative; boundary="----=_Part_482669_2017059864.1762594239069" ------=_Part_482669_2017059864.1762594239069 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ad 1) Funds confiscation: as already mentioned by gmaxwell there is a risk= =20 of confiscation of presigned transactions. Lightning like protocols that=20 simulate covenants using n-of-n multisig. Will be confiscated even if UTXO= =20 height is whitelisted On Saturday, November 8, 2025 at 7:58:30=E2=80=AFAM UTC+7 dath...@proton.me= wrote: Hi all - BIP repo maintainers requested=20 that I= =20 update this list before pushing a significant change, so I am doing that=20 now. Please consider this my formal request for the BIP PR to be unlocked so=20 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= =20 temporarily unspendable by this proposal, commenters were concerned that= =20 this would set a precedent of "confiscation". This new draft resolves th= is=20 concern by adding a UTXO height check to make sure *only UTXOs that are= =20 created while the softfork is active will be made temporarily unspendabl= e*.=20 The "OP_IF in Tapscript" and "257-byte control block limit" were the two= =20 main proposed rule changes that caused concern here. 2. "This doesn't block all possible methods of arbitrary data=20 insertion": This was already addressed in the previous draft, but to=20 reiterate: this proposal's goal is not to block *all*=E2=80=8B methods o= f=20 arbitary data insertion, just the most commonly abused ones. 3. "Blocks other softfork upgrades while active": This was also=20 addressed in the original draft, but to reiterate: it's unlikely that an= y=20 softfork upgrades will be ready to activate within one year anyway, so t= his=20 doesn't matter much. But also, the fact that this softfork expires creat= es=20 an opportunity to activate a more permanent and elegant upgrade that tur= ns=20 on what the community wants, while continuing to reject data storage as = a=20 supported use case, after one year. 4. "Reactive deployment risks": These concerns have been addressed by *r= emoving=20 the reactive deployment method entirely*. I still think activating this= =20 softfork is a matter of some urgency, but I think it still achieves its= =20 goals if we move steadily towards activation within a few months. 5. "Missing code": The code is now public here:=20 https://github.com/UASF/bitcoin/tree/29.2.knots20251010%2BBIP444 (please= =20 note that, while there are references to "BIP-444" in the code, that is= =20 just a placeholder and I will update it to whatever number the BIP edito= rs=20 decide). 6. "Temporary expiry risks": "Requires another consensus change before= =20 expiry or rules lapse": Yes, as stated in <3>, the community will have= =20 to come together in a year either to extend these rules (which shouldn't= be=20 difficult), or to activate something more permanent and less blunt. The= =20 expiry will *not* be a hardfork, contrary to some claims I've seen,=20 because opting into this deployment means opting into the expiry as well= ,=20 so old nodes will follow new ones onto the unrestricted chain 7. "Legal/process/conflict-of-interest concerns": all language about=20 legal risks has been stripped from the BIP. I welcome any and all feedback, as I think this proposal or something=20 similar to it stands an excellent chance of gaining consensus and=20 activating, and I think if that happens, it could be curative for the=20 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 = =20 wrote: Case law in the USA regarding illegal content has always rested squarely on= =20 those who: 1 - provide broad public access, in this case a company like OpenSEA (which= =20 has had to block content) 2 - the original author=20 if punishing "relays" was a thing, then every CISCO router, SMTP relay and= =20 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=20 actually wind up in trouble - not the internet providers the bitcoin ledger is neither a browser or web server, nor is it an image= =20 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=20 uncensorable ledger.=20 hopefully it doesn't change because someone launched a meme campaign with= =20 vague threats of legal action if a transaction has /no reasonable expectation of being mined/ (too=20 expensive to validate, too large, too low fees), there's also no reason to= =20 relay it this is probably the best way to set policy --=20 You received this message because you are subscribed to the Google Groups= =20 "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an= =20 email to bitcoindev+...@googlegroups.com. To view this discussion visit=20 https://groups.google.com/d/msgid/bitcoindev/CAJowKgKBBa%2BvD%3D5X0VMV2OFiB= BM23Ok6nmvfoLTr8fia141%3DFQ%40mail.gmail.com . --=20 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 e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/= 6ff66d86-848f-493d-a0dd-4ff8ea42f932n%40googlegroups.com. ------=_Part_482669_2017059864.1762594239069 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ad 1)=C2=A0Funds confiscation: as already mentioned by gmaxwell there is a risk o= f confiscation of presigned transactions. Lightning like protocols that sim= ulate covenants using n-of-n multisig. Will be confiscated even if UTXO hei= ght is whitelisted

On Saturday, No= vember 8, 2025 at 7:58:30=E2=80=AFAM UTC+7 dath...@proton.me wrote:
Hi all -
=

Please consider this my = formal request for the BIP PR to be unlocked so that discussion can resume.=

This update addresses several concer= ns from the previous draft:

  1. "Funds confiscation": due to the presence of UTXOs tha= t would be made temporarily unspendable by this proposal, commenters were c= oncerned that this would set a precedent of "confiscation". This new draft = resolves this concern by adding a UTXO height check to make sure only UT= XOs 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.<= /li>
  2. "This doesn't blo= ck all possible methods of arbitrary data insertion": This was already addr= essed in the previous draft, but to reiterate: this proposal's goal is not = to block all=E2=80=8B methods of arbitary data insertion, just the m= ost commonly abused ones.
  3. "Blocks other softfork upgrades while active": This was als= o 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 thi= s doesn't matter much. But also, the fact that this softfork expires create= s an opportunity to activate a more permanent and elegant upgrade that turn= s 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 sti= ll 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 c= ode": The code is now public here:=C2=A0https://github.com/UASF/bitcoin/tree/29.2.knots= 20251010%2BBIP444=C2=A0(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": "Requ= ires another consensus change before expiry or rules lapse": Yes, as= stated in <3>, the community will have to come together in a year ei= ther to extend these rules (which shouldn't be difficult), or to activate s= omething more permanent and less blunt. The expiry will not be a har= dfork, contrary to some claims I've seen, because opting into this deployme= nt 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":=C2=A0all l= anguage about legal risks has been stripped from the BIP.
I welcome any and all feedback, as I think this proposal or s= omething similar to it stands an excellent chance of gaining consensus and = activating, and I think if that happens, it could be curative for the Bitco= in community.

Thanks again for all of your feedb= ack 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 o= n those who:

1 - provide broad public access, in th= is case a company like OpenSEA (which has had to block content)
2 - t= he original author

if punishing "relays" was a thing, then ever= y 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 da= ta and the publishers that actually wind up in trouble - not the internet p= roviders

the bitcoin ledger is neither a browser or web ser= ver, nor is it an image uploader. there is zero ability to view images bui= lt 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 cam= paign with vague threats of legal action

if a transaction h= as /no reasonable expectation of being mined/ (too expensive to validate, t= oo 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 e= mail to bitcoindev+...@go= oglegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoind= ev/6ff66d86-848f-493d-a0dd-4ff8ea42f932n%40googlegroups.com.
------=_Part_482669_2017059864.1762594239069-- ------=_Part_482668_1786765761.1762594239069--