Blockchain and data protection - Does the Blockchain technology adequately protect personal data?
For the first time, Bitcoin received a lot of attention was in connection with Silk Road, which was basically an eBay for illegal goods. Bitcoin was used as the primary payment method supposedly because of its anonymity. To this day, many believe that Bitcoin transactions or other Blockchain transactions are anonymous and, therefore, assume the Blockchain technology would guarantee data protection. Wikileaks introduced Bitcoin as a secure and anonymous way to donate.
In 2017. Bitcoin became more popular and with it, the underlying technology of the so-called Blockchain. Blockchain technology cannot only be applied to financial transactions, but it has also been adapted for many other cases, although most projects admittedly are still in the prototype stage. A Blockchain is now used for identity management, for sharing health data, IP – Management, notary services, to name just a few. In many cases, there’s personal data involved. However, most legal scholars and regulators still focus on financial regulations; the question of personal information arises only in the context of Anti-Money-Laundering (AML) or Know-Your-Customer (KYC). A Blockchain contains the entire transaction history, and every user can gain access to it on a distributed ledger without special permission. Since many Blockchain applications containpersonal data, it’s important not to forget data protection.
Because of the random alphanumeric addresses, many people assume that a transaction is still anonymous and no personal data is processed, despite the fact that a Blockchain is public. However, the data protection law has a high bar when in it comes to anonymisation, hence it is necessary to take a closer look to determine if a Blockchain can adequately protect personal data.
This paper focuses on an EU (European Union) perspective and on the new EU General Data Protection Regulation (GDPR); under other data protection regulations, the Blockchain could be viewed differently. For readers who are unfamiliar with Blockchain technology, a brief explanation is given before the legal analysis.
First, a review is necessary regarding the question of anonymity. Second, the Blockchain is examined in regard to data protection principles. The paper concludes with some ideas on how data protection could be improved in a Blockchain.
As there are already more than 1,320 different coins or “Blockchains” listed on coinmarketcap, it is impossible to assess all in one paper. The data protection assessment in this paper, therefore, based on the fundamental principles of a Blockchain and Bitcoin.
Blockchain Technology Basics
A Blockchain is a distributed ledger technology or a decentralised database which keeps continuous records of every transaction.It enables users to transact digitally without the use of an intermediary or a central entity because the distributed ledger solves the double-spending problem. You can picture the ledgers big book in which every new transaction is recorded, but instead of just having one accountant, the book is controlled by many. When and only when the majority of the accountants (nodes) agree is another page with new transactions (block) added to the book. Every page is immutably stapled together with all the other pages (cryptographic hash function). As a result, the transaction can’t be changed. Additionally, every interested party (peer-to-peer) can get a complete copy of the book, and current copies of the book are distributed all over the internet. The immutability of the ledger makes it easy to confirm the rightful owner of some data / digital asset (e.g.,cryptocurrency), and a double-spending attempt would be recognised by the accountants, halted and not validated. Creating a double-spending situation would only be possible by rewriting all the transactions.
To prevent the theft of digital assets, the owner has a public and a private key. The Blockchain is asymmetrically encrypted and requires private and public keys to effect transactions.From a public key, a public address can be derived to be used to make a transaction. A sender only needs to know the receiver's address but not his real name.It is also possible to generate multiple public addresses, which would make it possibleto use a new address for every transaction.
Furthermore, there are “Permissionless Blockchain’s,” “Permissioned Blockchain’s,” and “Private Blockchain’s.” Bitcoin, for instance, is a Permissionless Blockchain, which means everyone can participate; it’s entirely open source and accessible. A Permissioned Blockchain provides a hybrid between the ‘low-trust’ provided by a Public Blockchain and the ‘single highly-trusted entity’ model of a Private Blockchain. Popularly called a Consortium Blockchain [Permissioned Blockchain], it is one where instead of allowing any person with an internet connection to participate in the verification of the transaction process or allowing a single company to have full control, a few selected nodes are predetermined. For example — imagine a consortium of 10 companies, each of which operates a device connected to the Blockchain network. If company ‘2’ only trades and shares its invoices with ‘3’, ‘4’ and ‘5’, there is no need for the other companies to be given permission to read the shared data.
A “Permissioned Blockchain” and Private Blockchains are controlled by a controller. The focus of this paper is on Permissionless Blockchains, where there is no noticeable controller.
Is a Blockchain anonymous?
As previously mentioned, because of the interchangeable addresses, many see a Blockchain transaction as anonymous, which would mean no personal data is processed. However, the GDPR has a very high threshold to perceive data as anonymised. It needs to be kept in mind that the requirements are not written in stone. Some nations have different ideas about anonymity. For instance, the United States gauges anonymisation slightly different than the EU regulations.The GDPR first determines if the data stored on a Blockchain is perceived as anonymous data or as personal under the definition of Article 4 (1) GDPR. Since generic addresses are used, there’s no direct identification.
According to Article 4 (1) GDPR, if the data relates to an identifiable natural person, it is still considered personal data. An identifiable natural person is one who can be identified, directly or indirectly, by reference to an identifier, such as a name, an identification number, location data, an online identifier, or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural, or social identity of that natural person.
To determine whether a natural person is identifiable, all the means reasonably likely to be used should be considered, such as singling out, either by the controller or by another person to identify the natural person directly or indirectly. To ascertain whether means are reasonably likely to be used to identifythe naturalperson, account should be taken of all objective factors, such as the costs of and the amount of time required for identification taking into consideration the available technology and technological developments at the time of the processing.
Subsequently, some methods will be described on how to identify a data subject on a Blockchain indirectly.
The public address could already constitute personal data if a third party can link it to a data subject. The use by the EU legislature of the word “indirectly” suggests that, to treat information as personal data, it is not necessary that that information alone allows the data subject to be identified. Furthermore, recital 26 of Directive 95/46states that, to determine whether a person is identifiable, account should be taken of all the means likely reasonably to be used either by the controller or by any other person to identify the said person.Third-party services - especially exchanges, wallet-services, and online shops - would have the means to identify the person behind an address and create a profile of a data subject by following the transactions on the ledger network.In that regard, a public address is similar to a dynamic IP address and, therefore, could be seen as personal data.
A more complicated method is the analysis of the ledger, which Reidand Harrigandescribe. There are several ways in which the user network can be used to deduce information about Bitcoin users. Global network properties can be used, such as degree distribution, to identify outliers. Local network properties can be used to examine the context in which a user operates by observing the user with which he or she interacts either directly or indirectly. The dynamic nature of the user network also enables flow and temporal analyses to be performed.
These are only a few methods to identify a user.The costs and the amount of time required vary for all these methodsbut are nonetheless reasonably likely to be used.
The opportunity to change a public address for every transaction certainly makes it harder to determine a data subject but not impossible. Besides, not every user is aware of this possibility, and if the address is generated on a third-party service, the address is still known to the service. Even if the user creates the address by himself for every transaction, identification through data-mining is always possible.
As a result, user data is not anonymous, and the GDPR does apply. Therefore, the data should be seen as pseudonymous data. Then again Article 4 (5) GDPR requires the necessary additional information to be kept separately, which is only the case of the user-generated addresses. However, if you take into account that the public ledger could be enough to identify a person, one could even argue the data is not a pseudonymas this information is not kept separate. In my opinion, the use of hashed public addresses should be enough to recognise a Blockchain as pseudonymous data. Ultimately the principles of data protection apply in either case.Thus, the application of pseudonymisation of personal data can reduce the risks to the data subjects concerned and help controllers and processors to meet their data-protection obligations.Applyingthe principles of data protection will justifiably be more flexible than if information on directly identifiable natural persons were processed,but pseudonymisation is not intended to preclude any other measures of data protection.
Permissioned Blockchain’s, on the other hand, are controlled by one or multiple central authorities (e.g.,Banks providing a payment system for their customers). The access is controlled by a central authority; therefore, the data is pseudonymous, and the GDPR is applicable. From a data protection perspective, the central authorityis the controller, and multiple authoritiesare joint controllers. The controller is responsible for compliance with data protection laws.
As a consequence, the GDPR applies to a Blockchain if personal data of data subjects who are in the Union is processed or the controller is established in the EU.It depends on the specific business model. However, even if personal information only entails reference ID numbers, such identifiers are typically unique to a specificpersonand, therefore, considered personaldata.
The Principles of Data Protection Applied to the Blockchain
The processing is lawful if the user has given consent, and depending on the business model, processing could also be necessary, orthe controller could have legitimate interests to process data.However, the safest way is to obtain consent, which is problematic on Permissionless Blockchain’s as it is unclear who the controller is, therefore, to whom a user givesconsent. “Consent” of the data subject means any freely given, specific, informed, and unambiguous indication of the data subject's wishes by which he or she, by a statement or by a clearaffirmative action, signifies agreement to the processing of personal data relating to him or her.
Unilateral affirmative consent could be a way to get consent, even without an explicit controller.
[..] In the case of Bitcoin and other financial transactions, consent can be assumed for data processing under Art. 6 (1) GDPR, since the recipient is a participant in the network thereby has a financial advantage from the transaction, nonetheless, this assessment cannot be generalised for cases where additional personal data or data from non-participants of the network is transmitted.
Affirmative consent can only be assumed if the user is:
- aware that the transaction happens within a Blockchain;
- freely and willing transacts via Blockchain;
- informed about data processing.
An affirmative consent would only include the transaction but no further processing.Furthermore, a controller could justify data processing as necessary for the performance of a contract.A transaction within a Blockchain needsconfirmation and written on a block in the ledger; therefore, it is necessary to process data. Otherwise, the Blockchain system would not work. A fallback argument for a potential controller is the necessity to process data for compliance with a legal obligationor the performance of a task carried out in the public interest.For example, compliancewith the respective financial regulation is compulsory in the Blockchain space.
As a result, if the data subject is aware of the Blockchain transaction, consent for a simple transactioncan be assumed. For more complex Blockchains where more data is processed, a case-by-case evaluation is necessary.
For a Permissionless Blockchain, fairness should not be problematic as the system is an open source which means an interested party can check the functionality before using a specific Blockchain. It would be problematic in Permissioned Blockchain as a controller could change or manipulate the Blockchain. A similar problem could potentially occur in Permissionless Blockchains if the majority of the Miners decide to make changes, though, in both cases, a data subject could just stop using the Blockchain.
It can be assumed that the Blockchain is transparent as it is inherent that an interested party can access or copy the ledger and comprehend historic transactions. It is expected that direct participants of a Blockchain are aware of the data processing. However, to inform the data subjects in compliance with Article 12 GDPR could pose a problem.
A purpose must be specified, explicit, and legitimate.For the most part, the purposeof a Blockchain isspecifiedin the code. The code defines how and what can be put on a Blockchain, for example, smart contracts. Additionally, users have some control over what kind of data they put on a Blockchain and for which purposes it is used.
The core purpose of a Blockchain is to transact securely and to store a transaction on an immutable database. Only if the digital asset/information is stored on the Blockchain, can it be subjected to a transactionat a later date without the fear of a manipulation by a bad actor.Hence, the long-time storage of the data is a given purpose. As long as a user is aware that the transaction happens on a Blockchain the two purposes (secure transaction and immutable storage) could be seen as specified, explicit, and legitimate. However, due to the public availability of the database, data subjects are particularly exposed to the risk of further processing by third parties.
Further analysis of pseudonymised data is possible within the same controller if the controller has taken technical and organisational measures and if additional information for attributing the personal data to a specific data subject is kept separately. General analysis for governance or to improve a Blockchain should be allowed even for third parties; otherwise,in a decentralised network with no real controller, further essential analysiswould not be possible. For example, services like Blockchain.infofurther trust in the Blockchain. Another analysisis problematic, although challenging, to control on a public ledger. If a third-party service is doing further analysis, it has to be disclosed, and it needs consentof its users.
Only personal data that is necessary to achieve the purpose should be processed.The mainpurposeis to facilitate a secure transaction. As every participant transacts with a pseudonym, one tool for data minimisation is already part of the system. However, a Blockchain allows adding additional information to each transaction, which will then become part of the immutable ledger. If a Blockchain automatically includes some personal information in a transaction(e.g.,number plate of a car), it could be problematic in regard to data minimisation. Whenever possible, this should be considered by the creators of a Blockchain and disclosed transparently. As well, the originator of a transaction can often add more personal data and, in that case, the originator is responsible for amending it lawfully.
The peer-to-peer network allows everyone to make a copy of the data. Therefore, data is stored in multiple places without the possibility of a datasubject to object. The storage of the same data in multipleplacesis in line with data minimisation, as pointed out by Marnau,the principle of data minisimation refers to the minisimation of the information and data points, to reduce the danger of profiling, and not to keep redundant information.
Accuracy and Storage Limitation
Personal data needs to be accurate and up-to-date.The peer-to-peer concept with an immutable ledger is beneficial to keep accuratedata. However, it only shows all the transactions, but it can’t guarantee that the additional data was correct in the first place or that it was updated.The block building and block hashing make it virtually impossible to change an entry retrospectively. The immutable ledger and potentially infinite storage of the data are what makes a Blockchain so attractive, but is problematic regarding data protection. It is not feasible to erase or update personal data on the Blockchain. Hence, the Blockchain counteracts the principle rights of accuracyand storage limitation.The only way to change the ledger retrospectively is if the majority of the participants agree to rewrite all the following blocks which ishighly impractical.A controller also could not comply with the right to be forgotten or rectify an entry. The same problems appear in Permissioned Blockchains where the controller is known. Therefore, this is an even bigger problem for Permissioned Blockchains and their controller.
Without going into further detail, one proposed solution by Marnau would be a redactable Blockchain.With this method, it is possible to delete a block which, at the same time, opens up a Blockchain for manipulation. This is not a practical solution, as an essential property of the Blockchain would be lost. At the current state of the technology, it must be accepted that the fact that a Blockchain cannot adequately protect personal data regarding adequacy and data limitation.
A Permissionless Blockchain is, by design, without any central authority, which poses a problem as the GDPR does not recognise data processing without a controller. The EU data protection relies on a central authoritywho is responsible for compliance.Without a central authority, the GDPR framework loses its effectivenessas the individual’s rights are based on the presence of a controller. Unfortunately, the Blockchain, as a peer-to-peer network, operates directly within this gap of the GDPR framework. The discussion is still controversial, and some legal scholars seem desperate to find a controller. The first possibility that comes to mind is the Miner. However, a Miner can’t control the Blockchain alone and only with a majority can Miners jointly determine the purposes and means of processing. Even a concept of joint control responsibilities would remain opaque and fail to meet the standards of Article 26(1) GDPR, which require transparent and clearallocation of responsibilities.In practice,a single Miner doesn’t have the means to comply with a request.Fasching identifies the developers as controllers.Developers don’t process data themselves. Therefore, they can’t be a controller under the GDPR.However, the developers could be obliged to use a Privacy by Design approach in the development stage. A third option is to consider all the users as controllers,but it needs to be kept in mind that as soon as a user puts a transaction on the Blockchain, the user’s control is lost.It might be correct as a theoretical approach, but in practice, it does not yield a benefit for the data subject.
As a consequence, it is impossible to determine a controller within a Permissionless Blockchain. This is undoubtedly a significant drawback of the Blockchain regarding data protection. I wouldn’t go as far as Islerand call a Blockchain a legal black hole in terms of data protection, however, complete data protection compliance on a Permissionless Blockchain without a controller is not achievable.
The GDPR and Blockchain have an ambivalent relationship. At first glance, a Blockchain looks privacy-friendly. Though, on second look, the core technology prohibits a full GDPR compliance. Undoubtedly, the Blockchain has some valuable properties, for instance, pseudonymisation, peer-to-peer transactions, and the integrity of a Blockchain. Then again, the complete decentralisation, openness, and immutability also create problems as potentially everyone can access the data of a ledger, and this leaves the pseudonymisation open for a de-anonymisation attack. The lack of a central control leaves data subjects and supervisory authorities without a way to enforce their rights.
Without destroying the advantage of a Blockchain, a full data protection compliance will not be possible. This is why a user needs to be made aware if a Blockchain is used. It can be assumed that the early adopters were aware of this. However, if the Blockchain becomes like TCP/IP, the average user will no longer be aware of it, and the service provider must inform their users in a transparent way. Furthermore, a Permissioned (or private) Blockchain is preferable if it involves a lot of personal data.
Contrary to the first cryptocurrency, Bitcoin, most new Blockchain projects start with the release of a whitepaper and a TGE. It’s now common practice to do a compliance assessment and obtain approval from the Financial Market Supervisory Authority. The developers should take care of data protection compliance in a similar way by applying a Privacy by Designapproach and, if necessary, conduct a data protection impact assessment and consult with the Supervisory Authority.In the development stage, the code can be changed much easier. It would make more sense to a Supervisory Authority to get involved at this stage rather than after the deployment of the Blockchain.
If the identification of the data subject is not one of the purposes of the processing, it is necessary to use technical measures to prevent identification.This could mean to implement more privacy enhancement technologies. For instance, a Blockchain could add “noise” to each transaction to make data-mining through a ledger much more complicated.A Blockchain could make use of “on chainand off chain storage,” or “Zero-Knowledge-Proof”could be implemented. However, some techniques could lead to a conflict with AML, KYC or other laws, which also needs to be considered.
As a result, a Permissionless Blockchain can’t be entirely in compliance with the GDPR; nevertheless, there are some ways to enhance the protection of personal data without losing the advantages of a Blockchain.
Collin Thompson, How does the Blockchain Work? (Part 1), available athttps://medium.com/Blockchain-review/how-does-the-Blockchain-work-for-dummies-explained-simply-9f94d386e093(accessed 1. December 2017)
Matthias Berberich and Malgorzata Steiner, Blockchain Technology and the GDPR - How to Reconcile Privacy and Distributed Ledgers, 2 Eur. Data Prot. L. Rev. pp. 422 – 426 (2016), p. 422.
What Are Addresses on Blockchains? Blockchain Address 101,available at https://blockgeeks.com/guides/Blockchain-address-101/(accessed 1. December 2017).
Also called public Blockchain’s
Ayush Varshney, Types of Blockchain — Public, Private and Permissioned,available at
https://blog.darwinlabs.io/types-of-Blockchain-public-private-and-permissioned-5b14fbfe38d4(accessed1. December 2017).
see Chris Achatz and Susan Hubbard, US VS. Eu Guidelines for De-identification, Anonymization and Pseudonymization, in: Journal of Internet Law; New York Vol. 20, Iss. 11, (May 2017): 1, pp.7-10.
Article 4 (1) GDPR
cf. Recital 26 GDPR
Similar to Recital 26 GDPR
Case C‑582/14, Breyer v Germany (CJEU, 19. October 2016) ECLI:EU:C:2016:779, para. 41 seq.
cf. Fergal Reid and Martin Harrigan, Chapter 1 - An Analysis of Anonymity in the Bitcoin System, in: arXiv:1107.4524, p. 15.
Dan Kaminksy,available athttps://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011(accessed 1. December 2017).
Case C-70/10, Scarlet Extended SA v Société belge des auteurs, compositeurs et éditeurs SCRL (CJEU, 24. November 2011), ECLI:EU:C:2011:771and Case C‑582/14, Breyer v Germany (CJEU, 19. October 2016) ECLI:EU:C:2016:779.
Similar view Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1028
Fergal Reid and Martin Harrigan, Chapter 1 - An Analysis of Anonymity in the Bitcoin System, in: arXiv:1107.4524, p. 15.
More detailed information on different methods can be found in: Fergal Reid and Martin Harrigan, Chapter 1 - An Analysis of Anonymity in the Bitcoin System, in: arXiv:1107.4524; Sarah Azoouvim, Mustafa Al-Bassam and Sarah Meiklejohn, Who Am I? Secure Identity Registration on Distributed Ledgers, in: J. Garcia-Alfaro et. al. (Eds.): DPM/CBT 2017, LNCS 10436, pp. 373 – 389, 2017; Jonas David Nick, Data-Driven De-Anonymization in Bitcoin, Master Thesis ETH, 9. August 2015.
The MtGox case is practical example for this: see Breaking open the MtGox case, part 1, available athttp://blog.wizsec.jp/2017/07/breaking-open-mtgox-1.html(accessed 1. December 2017).
cf. Recital 26 GDPR
Recital 28 GDPR
Article 29 Data Protection Working Party, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 18.
Recital 28 GDPR
cf. Article 3 GDPR
Matthias Berberich and Malgorzata Steiner, Blockchain Technology and the GDPR - How to Reconcile Privacy and Distributed Ledgers, 2 Eur. Data Prot. L. Rev. pp. 422 – 426 (2016), p. 423.
cf. Article 6 (1) (b-f) GDPR
Article 4 (11) GDPR
cf. Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1033.
cf. Rainer Böhme and Paulina Pesch, Technische Grundlagen und datenschutzrechtliche Fragen der Blockchain-Technologie, in: Datenschutz und Datensicherheit, 8/2017, pp. 473 – 481, p.479.
Article 6 (1) (b) GDPR
Article 6 (1) (c) GDPR
Article 6 (1) (e) GDPR
Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, p. 1025 – 1036, pp. 1028.
Article 29 Data Protection Working Party (WP29) Opinion 03/2013 on purpose limitation, 2. April 2013, p. 11.
Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1028.
cf. Recital 29 GDPR
cf. Article 5, 1(c) GDPR
Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1029.
Article 5.1 (d) GDPR
cf. Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1029
Article 5.1 (d) GDPR
Article 5.1 (e) GDPR
Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1030.
cf. Recital 79 GDPR
cf. Matthias Berberich and Malgorzata Steiner, Blockchain Technology and the GDPR - How to Reconcile Privacy and Distributed Ledgers, 2 Eur. Data Prot. L. Rev. pp. 422 – 426 (2016), p.424.
Matthias Berberich; Malgorzata Steiner, Blockchain Technology and the GDPR - How to Reconcile Privacy and Distributed Ledgers, 2 Eur. Data Prot. L. Rev. 422 – 426 (2016), p.424.
Jacek Czarnecki, Blockains and Personal Data Protection Regulations Explained, available at https://www.coindesk.com/Blockchains-personal-data-protection-regulations-explained/(accessed 05. December 2017); similar Rainer Böhme and Paulina Pesch, Technische Grundlagen und datenschutzrechtliche Fragen der Blockchain-Technologie, in: Datenschutz und Datensicherheit, 8/2017, p. 473 – 481, p.479; Matthias Berberich; Malgorzata Steiner, Blockchain Technology and the GDPR - How to Reconcile Privacy and Distributed Ledgers, 2 Eur. Data Prot. L. Rev. 422 – 426 (2016), p.424; Michael Isler, Datenschutz auf der Blockchain, in: Jusletter 4. Dezember 2017, p. 13.: Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, p. 1025 – 1036, p. 1033.
Joachim Galileo Fasching, Anwendungsbereiche und ausgewählte Rechtsfragen der Blockchain-Technologie, Masterthesis, Wien 2017, 9, http://www.it-law.at/publikation/anwendungsbereiche-und-ausgewaehlte- rechtsfragen-der-Blockchain-technologie/ (accessed 05. December 17)
Similar view: Michael Isler, Datenschutz auf der Blockchain, in: Jusletter 4. Dezember 2017, p. 13
Dóra Petrányi / Marton Domokos, Hungary: Data Protection Aspects of Blockchain, 17. August 2017, available at http://www.cms-lawnow.com/ealerts/2017/08/hungary-data-protection-aspects-of-Blockchain(accessed 05. December 17); Hungarian National Authority for Data Protection and Freedom of Information, A Nemzeti Adatvédelmi és Információszabadság Hatóság állásfoglalása a blokklánc („blockchain”) technológia adatvédelmi összefüggéseivel kapcsolatban,available at http://naih.hu/files/Adatved_allasfoglalas_naih-2017-3495-2-V.pdf(original guideline, accessed 05.12.17); a similar view has Carmen Tang, EU Regime: When Blockchain meets GDPR, in: Asian Legal Business, 1. November 2017, available at http://www.legalbusinessonline.com/news/sponsored-eu-regime-when-Blockchain-meets-gdpr/75053(accessed 05. December 17).
cf. Ninja Marnau, Die Blockchain im Spannungsfeld der Grundsätze der Datenschutzgrundverordnung, in: INFORMATIK 2017 – Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, 2017, pp. 1025 – 1036, p. 1033.
Michael Isler, Datenschutz auf der Blockchain, in: Jusletter 4. Dezember 2017, p. 13
Token Generation Event or Initial Coin Offering (ICO)
Article 25 GDPR
Article 35 et. sqq. GDPR
cf. Luca Bolognini and Camilla Bistolfi, Pseudonymization and impacts of Big (personal/anonymous) Data processing in the transition from the Directive 95/46/EC to the new EU General Data Protection Regulation, in: Computer Law & Security Review 33 (2017), 171 – 181, p. 175.
Examples are Monero and Zcash
Nagib Aouini, Privacy-preserving techniques using zero knowledge proof in public Ethereum, available at