From: "Edil Guimarães de Medeiros" <jose.edil@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork
Date: Sat, 8 Nov 2025 00:43:59 -0300 [thread overview]
Message-ID: <CANJiN3Li9c29_7DRjf6s10=prn7HP6g9MPG5UMvq2HN1N1izTA@mail.gmail.com> (raw)
In-Reply-To: <bJL7UshcsXUpiQiC85dQeafQrRvtovH1aRcUxggjD1S09Md9qWHi9GpJOBdcPGq2NNQMK2XK-REMVlWjHLkh3aKUIktnYQccUWqg0DHgNXc=@proton.me>
[-- 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 --]
next prev parent reply other threads:[~2025-11-08 6:25 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-25 20:43 dathonohm via Bitcoin Development Mailing List
2025-10-26 20:47 ` Jameson Lopp
2025-10-27 4:22 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 12:14 ` Jameson Lopp
2025-10-27 16:35 ` TheWrlck
2025-10-26 22:27 ` Peter Todd
2025-10-27 3:41 ` Jal Toorey
2025-10-27 17:27 ` Max
2025-10-27 4:08 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 18:29 ` Kyle Stout
2025-10-27 19:56 ` Greg Maxwell
2025-10-28 5:13 ` dathonohm via Bitcoin Development Mailing List
2025-10-30 0:31 ` Antoine Riard
2025-10-30 2:43 ` Erik Aronesty
2025-11-08 0:51 ` dathonohm via Bitcoin Development Mailing List
2025-11-08 3:43 ` Edil Guimarães de Medeiros [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANJiN3Li9c29_7DRjf6s10=prn7HP6g9MPG5UMvq2HN1N1izTA@mail.gmail.com' \
--to=jose.edil@gmail.com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox