From: "'Bitcoin Eagle' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork
Date: Sat, 8 Nov 2025 01:30:39 -0800 (PST) [thread overview]
Message-ID: <6ff66d86-848f-493d-a0dd-4ff8ea42f932n@googlegroups.com> (raw)
In-Reply-To: <bJL7UshcsXUpiQiC85dQeafQrRvtovH1aRcUxggjD1S09Md9qWHi9GpJOBdcPGq2NNQMK2XK-REMVlWjHLkh3aKUIktnYQccUWqg0DHgNXc=@proton.me>
[-- 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 --]
next prev parent reply other threads:[~2025-11-08 11:53 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-25 20:43 dathonohm via Bitcoin Development Mailing List
2025-10-26 20:47 ` Jameson Lopp
2025-10-27 4:22 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 12:14 ` Jameson Lopp
2025-10-27 16:35 ` TheWrlck
2025-10-26 22:27 ` Peter Todd
2025-10-27 3:41 ` Jal Toorey
2025-10-27 17:27 ` Max
2025-10-27 4:08 ` dathonohm via Bitcoin Development Mailing List
2025-10-27 18:29 ` Kyle Stout
2025-10-27 19:56 ` Greg Maxwell
2025-10-28 5:13 ` dathonohm via Bitcoin Development Mailing List
2025-10-30 0:31 ` Antoine Riard
2025-10-30 2:43 ` Erik Aronesty
2025-11-08 0:51 ` dathonohm via Bitcoin Development Mailing List
2025-11-08 3:43 ` Edil Guimarães de Medeiros
2025-11-08 9:30 ` 'Bitcoin Eagle' via Bitcoin Development Mailing List [this message]
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=6ff66d86-848f-493d-a0dd-4ff8ea42f932n@googlegroups.com \
--to=bitcoindev@googlegroups.com \
--cc=hello@bitcoineagle.dev \
/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