From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] [BIP Proposal] Reduced Data Temporary Softfork
Date: Wed, 29 Oct 2025 17:31:09 -0700 (PDT) [thread overview]
Message-ID: <f07bc89c-fcf0-4e3c-85ab-593a509c1265n@googlegroups.com> (raw)
In-Reply-To: <XFyaw5Bf4-4bAO3wBt3Wk2aSclxSGQ8n-uT4BR6ga864yMCf5Fe-xFQ8VnlYHH6bQ3s5jSQrfs02E-MNJbAXVmq3_vlQpgNcsOmiYTFwmcg=@proton.me>
[-- 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 --]
next prev parent reply other threads:[~2025-10-30 0:46 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 [this message]
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
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=f07bc89c-fcf0-4e3c-85ab-593a509c1265n@googlegroups.com \
--to=antoine.riard@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