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!

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,

With regards to storing harmful and potentially illegal data in the bitcoin blockchain, do check out our work on Redactability in public blockchains that's explained in this thread.

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!

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.

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!