An application of your approach to a decentralized blockchain like Bitcoin could potentially put that blockchain within the scope of the GDPR, thus rendering them useless.
Although it is argued that permissioned blockchains both public and private can comply with GDPR to the letter, it is not yet clear how the permissionless systems interplay with the GDPR (and other criminal laws of different jurisdictions concerting the data points stored and broadcast in the chain). It certainly cannot be ruled that these systems do not fall under the scope of GDPR.
That's very much consistent with my understanding of the legal status.
Speculation: politics / jurisdiction wants to apply GDPR laws to Bitcoin.
Unfortunately, lacking a "defendant", there's no-one to hold responsible.
I.e., I consider it unlikely that GDPR laws will ever apply to Bitcoin in a
meaningful way.
Only after court rulings from different jurisdictions will we know a clear picture of how these laws affect Bitcoin like systems.
That's where I beg to differ.
Lacking a "defendant", there won't be lawsuits, hence no court rulings.
The only rulings I could imagine would be against member states of the EU to ratify GDPR applying to Bitcoin.
But again, this will not lead to applicability of those laws in a meaningful way.
A miner might be considered a data processor, but it's probably unlikely that a judge would actually see it that way.
If anything, a miner is most likely to be considered a carrier who's also basically exempt from the requirements of GDPR, at least concerning transmitted data.
We understand that this is an ongoing debate both here and in the legal offices across different jurisdictions. We are not taking sides on this
You needn't take sides on this, but you might at least want to point out in publications of your works more clearly that the infamous RWTH paper is only one (odd) way to see it.
but what we offer is a solution for the scenario when some jurisdictions (could potentially in the future) deem the compliance to such laws mandatory for the miners and hold them responsible for the objectionable data that is being circulated.
And the proposed solution seems technically sound (though I still can't do the math).
I disagree, though, that implementing such a mechanism into the Bitcoin blockchain would actually help the miners.
If anything, it would make it more likely for GDPR laws to apply to them.
Therefore, considering Bitcoin, I would strongly advise against implementing your technology.
As for (de facto centralized, and thereby GDPR-prone) Blockchains like Ethereum, I consider your approach to be useful from the perspective of the central authority (in that case, the Ethereum Foundation).
I've called that paper rubbish before and I'll continue to do so as long as I'm proven incorrect Wink
[...]
We clearly state that the content found on the chain as shown in the Matzut et al. paper is harmful (or objectionable). We do not offer interpretations for the broadcast and download of such data as 'illegal'. We at best say that it could be potentially be illegal depending on how criminal laws of different jurisdictions interpret it (like
this proposal).
This is outside the scope of your research, obviously.
I therefore advise you to at least clearly point out that the RWTH's research is highly controversial.
I stand by my reasoning that the so-called "storage" or "transfer" of illegal content on the blockchain is done via a special form of steganography.
Therefore, not the data on the blockchain is to be considered the illegal content, but rather the decoding software for it.
But of course, a judge may see that differently.
Given a widely accepted software, one might also argue that it's a de facto standard, of course.
E.g. in the case of an mpeg stream, one might also assert that the moving pictures are not the potentially illegal content, but rather the mpeg-decoder software. But that would obviously be nonsense.
For the moment, it stands to reason, though, that the distribution of illegal content over the blockchain is
not done via a generally accepted, standardized interface or software.
the so-called "storage" of "malicious content" in the blockchain is not performed via the methods of the blockchain itself, but rather by a special case of steganography, where the key to the steganographically hidden information is published via a secondary channel (e.g. in the form of the distribution of a decoding software).
The raw data is actually stored in an encoded form (0's and 1's). Does it mean that broadcasting 0's and 1's of child porn is not illegal until the user is 'made' aware of how to decode and reconstruct the actual content? Even if the encoding and the decoding processes are universally known but not part of the methods used in Bitcoin?
That's precisely what I'm saying, unless it becomes a de facto standard.
Which it obviously isn't at the moment.
E.g. the very first instance of data "on the blockchain" was Satoshi's famous hidden message
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
in the genesis block. Emphasis: hidden.
You'll have to use a hex editor or more specific tools to see that message.
At no time
before the publication of the message was there a standard to decode it.
Hence, the message was not
published in a meaningful way without the publication of the additional information of how to read it.
Now, I'm talking of publication here, which is also somewhat different (legally) from storage, so it's more difficult than that.
Today, there might be several "standards" for encoding messages, I'll just mention the "classical" cryptograffiti approach as an example:
Protocol Specification
Each Bitcoin transaction contains a number of output addresses. Normally we see these addresses in their Base58 format. However, in essence they are all just 20-byte binary strings. To save a file on the block chain, it should be divided into 20-byte chunks (adding zeroes to the end of the last chunk if needed). Then, to indicate the end-of-file, one must append the RIPEMD-160 hash of the original file to the list of file chunks. Optionally, one could append a textual comment to the block chain file (right after the hash). The comment should be in UTF-8 encoding and similarly to the file, the comment should be divided into 20-byte chunks. However, the comment does not have to end with its hash. We then concatenate the file chunks, file hash and comment chunks into one array. All of the chunks must then be converted to Base58 format. Finally, a normal Bitcoin transaction has to be made, sending the smallest possible amount of bitcoins to each of the Bitcoin addresses in that array.
I must say that this does not in any way resemble a "typical"
encoding for data.
And honestly, by the standards of this "protocol", it's easy for me to "distribute" child porn via SEPA or SWIFT transfers as well.
In the end, judges will decide, but for the moment, I cannot for the life of me imagine a normally prudent expert to consider such a "protocol" anything but steganography.
