Topic: Sanitising bad data inserted into Bitcoin: Redacting in Bitcoin blockchain (Read 353 times)

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.

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.


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.

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).


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.


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
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:
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.

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. There is active legal research going on that is trying to interpret GDPR like laws for permissionless systems like Bitcoin. One of many such active efforts can be found here . Only after court rulings from different  jurisdictions will we know a clear picture of how these laws affect Bitcoin like systems.



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, 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.


We wish to clarify that we do not intend to give an interpretation for the GDPR laws or for the cited paper. Our intention in citing the paper was to show just how unclear it is for the permissionless setting and what our solution offers in case the interpretations for the permissionless setting are along similar lines to that of the permissioned setting.


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).


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?

Many thanks for the feedback.

Cheers!

Hi,

please do read the paper when you have time, in our opinion it is an easy read and the intuitions are explained in a fairly detailed manner (both for a generic blockchain protocol and specifically for Bitcoin).

One of our major contributions is the accountability of the edit operation. Miners have the right to vote on a redact request, who have invested quite a lot in the system and therefore can be expected to behave rationally. In our proposal, since the voting periods are reasonably long (eg., 2 weeks in the existing Bitcoin blockchain), all the users observing the chain can scrutinise (1) the merit of the edit request and (2) whether the miners are voting on merit or not.

In the case you mentioned (which we discuss in our paper at length) about financial data being edited: (1) such an edit request is publicly known and scrutinised during the voting phase before any edit operation is performed, (2) editing the financial data increases skepticism in the system among the people willing to use the chain for monetary purposes, and (3) finally, the 'victim' of this financial edit can always make his claim publicly letting everyone (users in the network and anyone outside) of his victimhood thus affecting the trust of the system. Since the miners can be safely assumed to behave rationally, it is expected that they wouldn't perform edit operations that affect the trust of the system. We would like to emphasise that there is no trapdoor in the system. Data redaction happens simply by dropping the data albeit with countermeasures for consensus, accountability and chain integrity.

Whether it is 100% hack proof? We do provide sound mathematical security guarantees and the choice of parameters for the edit 'policy'. We believe our solution is easily integrable into existing systems and can be communicated to the average user in a fairly simple manner.

Many thanks for your feedback, please let us know if you need more clarification or anything related for that matter.

Cheers!

Sorry, I didn't read the paper, so my conclusions my be incorrect, however, I see 2 possible problems:

One problem I see is the voting on deletions. I think that giving the miners even more power would be harmful on the long term for such a blockchain.

Another thing is the trust. A blockchain that allows editing information has imho a backdoor in it. Today to may delete a comment, tomorrow you may edit some financial data.
I don't say it's like that. Most probably it can be done to not allow that. But will the average Joe understand and trust that? Will this be 100% hack proof?

TL;DR:
GDPR laws don't apply to "true", "decentralized" blockchains.
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.
Centralized, permissioned "blockchains" like Ethereum, might profit from your approach.
The RWTH paper from a year ago was, and still is, rubbish.

To be honest, I knew where this was headed* from the very beginning, so just let me clarify here:

A "true", "permissionless" blockchain like the Bitcoin blockchain lies outside the legal scope of the GDPR.
Making it redactable in any way would shift the burden of compliance to GDPR to a "data controller" (which does not exist in a decentralized blockchain) or "data processor".
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've had this discussion for quite some time now, even before the notorious, infamous RWTH-paper (which is sound science regarding the computer science parts, but utter rubbish in the legalese).


You're wrong.
That paper does not contain a general interpretation of how the GDPR applies to blockchains, but rather the special case of applicability of the GDPR to permissioned, that is, centralized blockchains.

In fact, it explicitly says so in the paper itself:
I've called that paper rubbish before and I'll continue to do so as long as I'm proven incorrect
There's quite a few things wrong (or rather: odd) with the science itself, but mostly it's the legal assumptions or premises underlying the paper that are just plain wrong or at the very least, extremely far-fetched.
If it is in fact peer-reviewed, that doesn't speak well for the peers.
I honestly doubt that, though.
Most likely, it's been superficially checked for spelling errors and the references might have been cross-checked.
Again, the science itself is sound (or better: not inconclusive), but the legalese is just plain wrong (which shouldn't surprise you, since law isn't an exact science, after all).

There's one basic problem (or, in lack of a better word: oddity) with the science:
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).
I.e. unless you tell me beforehand how to interpret the data on the blockchain, I have no way of seeing it.
In other words: information in the blockchain is not to be interpreted by special programs that can decode pictures, hypertext links or anything from the data stream, but by a program that's specifically designed to interpret transaction & scripts within the scope of the definitions of the blockchain (i.e. a wallet).
If you use special software to "transmit" pictures, you're basically "piggy-backing" a stream of data that's not designed for that data.

I've commented on this in the past with undeniable proof that Donald Trump declared his love to Hillary Clinton in his tweets, by simply publishing a "decryption program" (a simple Perl one-liner, AFAIR) that turned "covfefe" into "I love Hillary".
I could have made him publish child porn as well, of course.

Now, to apply this legally to the miners of a blockchain, one has to come to the conclusion that the transmission of steganographically encoded information is equivalent to "publication" in a legal sense. That is at the very least far-far-far-fetched, or better: outright wrong.


No.
If anything, your redactable blockchain solution is useful for permissioned blockchains (which are not blockchains in the common sense of the word anyway).

For those centralized "blockchains", your approach would offer the centralized authority a way out of the dilemma of being a "data controller" and shift the burden towards the "data processors" and / or the users.
This might be interesting financially to those who consider snakeoil a viable business model, but has no use in the scope of the applicability of "true" blockchains.

E.g. the Ethereum Foundation, a completely centralized, private organization, which might be forced by GDPR laws to enforce claims by legal entities for the deletion of specific data, could shift the burden of deletion onto the miners and/or its users, thus saving a lot of work and, more important: money.

Hi,


Its the miners who mine blocks can vote for a redaction request.


Yes. To vote or not vote is left to the judgement of the miner. However, we rely on the rationality of the miners before they decide on their vote. Given the voting periods are reasonably long, it is possible for the entire network and all outside players to observe how the voting progresses. If the miner does not vote for a redaction that quite obviously redacts 'illegal' content, then the miner stands to potentially harm the system (with legal non-compliance) that he is invested in, and vice versa. This rationality heavily discourages miners from adopting any 'default' voting strategy and strongly encourages to vote for what is "legally healthy" for the system.

Cheers!

Hi,


Of course, if a malicious user wishes to maintain local copies of the potentially harmful data points he is free to do so. The point of our work is, honest (or otherwise innocent) users need not store or broadcast such data points for the purposes of integrity of the blockchain. This plays a major role given the new GDPR laws in the EU and many more in other countries. An interpretation of how the GDPR laws pay with blockchain systems can be found here. Although these laws are yet to interpreted and enforced on a serious level on existing blockchain systems, with our redactable blockchain protocol, the blockchain and the users storing and maintaining it can be rest assured that they are not required to store or broadcast harmful content (potentially illegal if the laws interpret them that way).


Several academic and non-academic works on the existence of harmful contents in the Bitcoin blockchain can be found. We refer to the peer reviewed work of  Matzutt et al., where they point to the existence of clearly objectionable content (pictures, links, documents, secret keys, etc.) in Bitcoin. As I explained above, the significance of enforcing the GDPR laws on blockchains (which is actively worked upon) could potentially make storing and broadcasting the above found contents illegal. Moreover, the above mentioned work analysis only the Bitcoin blockchain. If similar data insertions are possible and such harmful content exist in other "public" blockchains, it could seriously hinder the adoption and usage of such blockchains across nations in the advent of these laws.

Our redactable blockchain solution is precisely to solve this problem in Bitcoin and other public (permissionless) blockchains.

Cheers!

Okay, so if I were to (e.g. inadvertently) post sensitive data onto a public blockchain, I could "delete" it, so that it's no longer distributed by the internal distribution mechanisms of said blockchain.
Of course, that doesn't necessarily delete that information if it's stored / archived someplace else.
In my eyes, that's the same as taking down a post on an internet message board and leaving the copy at archive.org untouched.


That's basically what I understood from your paper in the first place.
And that brings me back to my question "what is it good for?".
I somehow fail to see any "real" use for it.
That only makes sense based on the assumption that there is something as "harmful content" in the first place.
For the Bitcoin blockchain, this has been claimed in the past (concerning child pornography etc.) but never held up to scrutiny.
Claims of legally problematic "publication" of illegal content fail at the definition of "publication" in the legal sense.

Whether there's harmful content in the form of e.g. "malicious code", on the other hand, is something that should be tackled in the client software.


All in all, your proposal is an interesting concept, no doubt there.
I just wish there were some application I could think of that I would find to be really useful.
But maybe there is or will be. There's smarter people out there than me.

Hi, thanks for your interest and your question. Let me try to clarify.


In our redactable blockchain protocol, one does not need to store/broadcast the redacted information at all. This is while still maintaining the integrity of the chain.

In an immutable chain, even if you have superseding information (that supersedes some information in some previous block), one needs to store and broadcast the superseded information for the purposes of chain integrity and validation.

For instance, if the superseded information is some malicious data point (like sensitive links/pictures/videos, etc.), in our redactable blockchain protocol this information is completely redacted and no user in the network needs to store or broadcast this data. Any new user entering the system gets the redacted chain and validate the chain by himself. Specifically, he precisely knows where the redaction has taken place and if it was approved simply from the information that's on the chain. However, in case of the immutable chain, the malicious data point still needs to be stored and broadcast (despite some superseding information in a later block) for the new user to verify the integrity and validity of the chain.


With our redactable blockchain protocol, the chain and its users have the means to be free from storing and broadcasting potentially harmful data bytes that get onto the chain. In a way the chain through consensus can cleanse itself off of these harmful content.

Interesting paper. I can't do the math, though
Assuming the math is correct and everything works out, and assuming I understand what you're talking about (which is much less likely), I only have one real question, though:
what is it good for?
What are the benefits of a redactable blockchain over a blockchain where information in a new block could simply supersede information from a previous block, keeping all previous information intact?

Hello all,

greetings from Dominic Deuber (Friedrich Alexander University, Germany), Bernardo Magri (Aarhus University, Denmark) and myself, Sri Aravinda Krishnan Thyagarajan (Friedrich Alexander University, Germany). Our recent research work on Redactable Blochchain in the Permissionless Setting has been accepted and will be presented at the 40th Symposium on IEEE Security & Privacy 2019, Oakland (https://www.ieee-security.org/TC/SP2019/program-papers.html).

The problem of harmful data insertion into the Bitcoin blockchain is well motivated and poses a huge challenge for law enforcement agencies like Interpol (Tziakouris, IEEE S&P'18). In a step towards addressing this issue, in 2017 Ateniese et al. proposed the first Redactable blockchain protocol albeit in the permissioned setting. Their motivation was to redact (potentially harmful) contents from the chain and they achieved this by the use of Chameleon Hash functions. Their protocol works with finesse in the permissioned setting while proving to be impractical in case of a permissionless system like Bitcoin. Apart from the performance issues of doing a secret sharing among several thousand nodes in the P2P network of Bitcoin, they do not guarantee any notion of accountability for who/what/when some data point was redacted from the chain which we consider as violating the fundamental characteristic of the Bitcoin blockchain's public verifiability.

In our work we propose the first efficient redactable blockchain for the permissionless setting that is easily integrable into Bitcoin, and that does not rely on heavy cryptographic tools or trust assumptions (apart from the ones already required by Bitcoin). Our protocol uses a consensus-based voting and is parameterised by a policy that dictates the requirements and constraints for the redactions; if a redaction gathers enough votes the operation is performed on the chain.

Our protocol offers public verifiability and accountability for the redacted chain. It is possible for the users in the network to actively scrutinise a redaction before it gets approved. After a redaction happens, any user can verify (1) where the redaction was performed (2) if it was approved by policy of the network and (3) if both the original (un-redacted) and redacted chains were/are indeed valid. Moreover, post a redaction, our protocol guarantees protection against any user who makes a 'false victim' claim.

We provide formal security definitions and proofs showing that our protocol is secure against redactions that were not agreed by consensus. Additionally, we show the viability of our approach with a proof-of-concept implementation in Python that shows only a tiny overhead (of less than 3%) in the chain validation of our protocol when compared to an immutable one.

You may find the full version of the paper here. We would be glad to hear your feedback and suggestions on our work. Talk to us if you're interested in collaborating for a future work!