Subject: [Trans] Putting illegal stuff in an append only ledger

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Mar 2018 23:00:59 +0000

https://www.theguardian.com/technology/2018/mar/20/child-abuse-imagery-bitcoin-blockchain-illegal-content

People quietly talked about this being a problem. Guess the cat is out of the bag now.

Sent from my iPhone

---

From: Tao Effect <[email-masked]>
Date: Tue, 20 Mar 2018 19:12:04 -0400

I don't think it's a real problem, just another week, another social attack on Bitcoin from those who are heavily invested in seeing Bitcoin die.

The reason why it's not a legitimate issue are here:

https://lobste.rs/s/walhsk/child_abuse_imagery_found_within_bitcoin#c_xf6oor <https://lobste.rs/s/walhsk/child_abuse_imagery_found_within_bitcoin#c_xf6oor>

And here:

https://lobste.rs/s/walhsk/child_abuse_imagery_found_within_bitcoin#c_76hm8v

But that will not stop people from pretending it is.

- Greg

--
Please do not email me anything that you are not comfortable also sharing with the NSA.

> On Mar 20, 2018, at 7:00 PM, Paul Wouters <[email-masked]> wrote:
> 
> 
> https://www.theguardian.com/technology/2018/mar/20/child-abuse-imagery-bitcoin-blockchain-illegal-content <https://www.theguardian.com/technology/2018/mar/20/child-abuse-imagery-bitcoin-blockchain-illegal-content>
> 
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 21 Mar 2018 09:46:41 +0000

On Tue 2018-03-20 19:12:04 -0400, Tao Effect wrote:
> I don't think it's a real problem, just another week, another social
> attack on Bitcoin from those who are heavily invested in seeing
> Bitcoin die.
>
> https://lobste.rs/s/walhsk/child_abuse_imagery_found_within_bitcoin#c_xf6oor
>
> And here:
>

IIUC, the webforum comments that these links point to argue that because
there is work required outside the blockchain to assemble the toxic
data, the data in question doesn't *just* reside in the blockchain.  Is
that right, or do you have another interpretation?

I don't see how it follows from this particular situation that there
would be no way to put toxic data in the global append-only ledger that
Bitcoin depends on.  Do you think that there is some principled reason
why the blockchain can avoid ingestion of toxic data of any form,
whether it's (depending on your jurisdiction) CP or "intellectual
property" or blasphemy or hate speech or …?

Does your argument for why the bitcoin blockchain is defended against
this hold for arbitrary global append-only datastructures, or is it
specific to bitcoin?

Regards,

          --dkg

---

From: Tao Effect <[email-masked]>
Date: Wed, 21 Mar 2018 18:22:57 -0400

> that right, or do you have another interpretation?

Yes, I (same person who wrote those comments), am arguing that there is a difference between an image, a video, etc., and scrambled bits of data that need _special instructions_ to *re-assemble* them into an image, video, etc., and that this should be self-evident.

> property" or blasphemy or hate speech or …?

I am arguing that /Bitcoin's/ blockchain is not designed to support such "toxic ingestion" of such content.

> this hold for arbitrary global append-only datastructures, or is it

This is specific to Bitcoin and Bitcoin-like datastructures which simply do not allocate enough room for arbitrary data.

That they can be hacked into getting tiny pieces of arbitrary data to be stored in separate chunks, requiring re-assembly through special knowledge (e.g. a special tool and precise knowledge of which transaction to pass through that special tool), does not mean that these datastructures are somehow the entity to point to as carriers of "toxic data".

If you were to argue that they are, then you can equally argue that the entire Internet is illegal because it can be used, with specialized tools and specialized knowledge, to transport toxic data.

- Greg

> On Mar 21, 2018, at 5:46 AM, Daniel Kahn Gillmor <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 23 Mar 2018 20:40:20 +0000

On Wed 2018-03-21 18:22:57 -0400, Tao Effect wrote:
> This is specific to Bitcoin and Bitcoin-like datastructures which
> simply do not allocate enough room for arbitrary data.

Thanks for clarifying this!  If i understand correctly, your argument
appears to depend on all three of the following assertions:

 a) the chunks of arbitrary data that can be injected in the
    datastructure in question are smaller than some specific size (let's
    call it X bytes).

 b) there is no standard mechanism used for the datastructure in
    question that aggregates multiple pieces of arbitrarily-injected
    data into any larger structure.

 c) there is no toxic data that is X bytes or smaller.

is that right?  I don't know the Bitcoin protocol that well.  What is
the value of X for the Bitcoin blockchain?

Is (a) some sort of general principle that we should try to include in
designs of any append-only globally-distributed datastructures?

how do we ensure that (b) remains the case?  how do we verify that (c)
is true in the jurisdictions that we care about?

   --dkg

---

From: Tim Hollebeek <[email-masked]>
Date: Mon, 26 Mar 2018 16:22:30 +0000

For what it’s worth, for any arbitrary bit string X of length n and illegal content Y of length m, there exists a decompression function (“special instructions”) that converts the string X into Y.

When that function is encryption under a secret key that I will publicly reveal at a later point in time, good luck in detecting that and preventing me from adding it.

-Tim

From: Trans [mailto:[email-masked]] On Behalf Of Tao Effect
Sent: Wednesday, March 21, 2018 6:23 PM
To: Daniel Kahn Gillmor <[email-masked]>
Cc: Paul Wouters <[email-masked]>; [email-masked]
Subject: Re: [Trans] Putting illegal stuff in an append only ledger

- Greg

On Mar 21, 2018, at 5:46 AM, Daniel Kahn Gillmor <[email-masked] <mailto:[email-masked]> > wrote:

And here:

Regards,

         --dkg

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 29 Mar 2018 09:58:21 -0400

> is true in the jurisdictions that we care about?

Note that for Certificate Transparency, neither (a) or (b) necessarily
holds true if we accept arbitrary certificate profiles. For example, the
use of the LogoType extension could allow for such direct encoding in full.

In this regard, there is an operational concern that merely states that CAs
should not do this, and logs are reliant on sanctions against CAs that do
this. For an ecosystem of publicly trusted CAs, the non-technical
considerations - such as risk of distrust, or the existence of the Baseline
Requirements - serve to curtail most forms of abuse, by restricting through
policy or practice what a CA normatively should encode within a certificate.

However, there are exceptions to this. For example, the existence of a
technically-constrained sub-CA is generally a signal of an operational
hand-off - akin to a DNS zone-split - in which key material is no longer
held by the party whose existence is vested in the root key material, but
instead handed off to some third-party. A hostile technically constrained
sub-CA could thus encode arbitrary data within certificates they issue, and
from that, cause sanction to be visited upon the root. Here, again, we have
non-technical forces of sanction - such as contracts between the two
parties - to discourage the use.

In practice, one would expect that should such content be logged, one
possible remedy is for the log to shut down. From an operational
standpoint, clients are being built with a notion of log agility being a
routine practice, although the target seems to be based on annual
refreshes, it does seem possible to account for exceptional situations.
Based on the above considerations, it seems that at a policy level, we have
a number of options already available, and, in an absolute 'worst-case'
doomsday scenario, logs become gatekeepers for certificate profiles (only
accepting conforming certificates), while serving as transparent
attestations of the validated information - rather than their function
today, serving as attestations both of certificate profiles and validated
information.