Skip to content

Blockchain and Data Protection – Does the Blockchain technology adequately protect personal data?

17. April 2018

Introduction

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.[1]

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 contain personal 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[2], it is impossible to assess all in one paper. The data protection assessment in this paper is, 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.[3] 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 ledger as 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.[4] 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.[5] It is also possible to generate multiple public addresses, which would make it possible to use a new address for every transaction.

Furthermore, there are “Permissionless Blockchain’s,[6]” “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.[7]

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 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.[8] 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.[9]

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 identify the natural person, 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.[10]

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/46[11] states 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.[12] 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.[13] In that regard, a public address is similar to a dynamic IP address and, therefore, could be seen as personal data.

Kaminsky[14] found a way to map a public address to an IP address directly. Since the CJEU[15] qualifies IP – Addresses as personal data, the anonymity is broken as well.[16]

A more complicated method is the analysis of the ledger, which Reid and Harrigan describe. 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.[17]

These are only a few methods to identify a user.[18] The costs and the amount of time required vary for all these methods but 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.[19]

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 pseudonym as 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.[20] 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.[21] Applying the principles of data protection will justifiably be more flexible than if information on directly identifiable natural persons were processed,[22] but pseudonymisation is not intended to preclude any other measures of data protection.[23]

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 authority is the controller, and multiple authorities are 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.[24] It depends on the specific business model. However, even if personal information only entails reference ID numbers, such identifiers are typically unique to a specific person[25] and, therefore, considered personal data.

 

The Principles of Data Protection Applied to the Blockchain

Lawfulness

The processing is lawful if the user has given consent, and depending on the business model, processing could also be necessary, or the controller could have legitimate interests to process data.[26] 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 gives consent. “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 clear affirmative action, signifies agreement to the processing of personal data relating to him or her.[27]

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.[28]

 

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.[29] Furthermore, a controller could justify data processing as necessary for the performance of a contract.[30] A transaction within a Blockchain needs confirmation 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 obligation[31] or the performance of a task carried out in the public interest.[32] For example, compliance with 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 transaction can be assumed. For more complex Blockchains where more data is processed, a case-by-case evaluation is necessary.

Fairness

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.

 

Transparency

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.

If Blockchain technology processes personal data from those who are not the endpoint of the transaction or participants in the network, transparency must be guaranteed in other ways: e.g., in the context of consent or privacy policy, information obligations and the information are provided by the controller.[33] One way could be to integrate such information into the Blockchain similar to an open source licence, albeit an average user needs to able to obtain such information.

 

Purpose Limitation

A purpose must be specified, explicit, and legitimate.[34] For the most part, the purpose of a Blockchain is specified in 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 transaction at 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.[35]

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[36]. 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 analysis would not be possible. For example, services like Blockchain.info[37] further trust in the Blockchain. Another analysis is 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 consent of its users.

 

Data Minimisation

Only personal data that is necessary to achieve the purpose should be processed.[38] The main purpose is 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.[39]

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 data subject to object. The storage of the same data in multiple places is in line with data minimisation, as pointed out by Marnau,[40] 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.[41]

 

Accuracy and Storage Limitation

Personal data needs to be accurate and up-to-date.[42] The peer-to-peer concept with an immutable ledger is beneficial to keep accurate data. 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.[43] 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 accuracy[44] and storage limitation.[45] The only way to change the ledger retrospectively is if the majority of the participants agree to rewrite all the following blocks which is highly impractical.[46] 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.[47] 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.

 

Accountability

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 authority who is responsible for compliance.[48] Without a central authority, the GDPR framework loses its effectiveness[49] as 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 clear allocation of responsibilities.[50] In practice, a single Miner doesn’t have the means to comply with a request.[51] Fasching identifies the developers as controllers.[52] Developers don’t process data themselves. Therefore, they can’t be a controller under the GDPR.[53] 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,[54] 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.[55] 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 Isler[56] and 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.

 

Conclusion

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[57]. It’s now common practice to do a compliance assessment and obtain approval from Financial Market Supervisory Authority. The developers should take care of data protection compliance in a similar way by applying a Privacy by Design[58] approach and, if necessary, conduct a data protection impact assessment and consult with the Supervisory Authority.[59] 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.[60] 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.[61] A Blockchain could make use of “on chain and off chain storage,” or “Zero-Knowledge-Proof”[62] 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.

 

Bibliography

 

[1] Wikileaks, available at https://shop.wikileaks.org/donate, (accessed 28. November 2017)

[2] Coinmarketcap, available at  https://coinmarketcap.com/all/views/all/ (accessed 28.11.2017)

[3] Collin Thompson, How does the Blockchain Work? (Part 1), available at https://medium.com/Blockchain-review/how-does-the-Blockchain-work-for-dummies-explained-simply-9f94d386e093 (accessed 1. December 2017)

[4] 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.

[5] What Are Addresses on Blockchains? Blockchain Address 101, available at  https://blockgeeks.com/guides/Blockchain-address-101/ (accessed 1. December 2017).

[6] Also called public Blockchain’s

[7] Ayush Varshney, Types of Blockchain — Public, Private and Permissioned, available at  

https://blog.darwinlabs.io/types-of-Blockchain-public-private-and-permissioned-5b14fbfe38d4 (accessed 1. December 2017).

[8] 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.

[9] Article 4 (1) GDPR

[10] cf. Recital 26 GDPR

[11] Similar to Recital 26 GDPR

[12] Case C‑582/14, Breyer v Germany (CJEU, 19. October 2016) ECLI:EU:C:2016:779, para. 41 seq.

[13] cf. Fergal Reid and Martin Harrigan, Chapter 1 – An Analysis of Anonymity in the Bitcoin System, in: arXiv:1107.4524, p. 15.

[14] Dan Kaminksy, available at https://www.slideshare.net/dakami/black-ops-of-tcpip-2011-black-hat-usa-2011 (accessed 1. December 2017).

[15] 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:771 and Case C‑582/14, Breyer v Germany (CJEU, 19. October 2016) ECLI:EU:C:2016:779.

[16] 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

[17] Fergal Reid and Martin Harrigan, Chapter 1 – An Analysis of Anonymity in the Bitcoin System, in: arXiv:1107.4524, p. 15.

[18] 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.

[19] The MtGox case is practical example for this: see Breaking open the MtGox case, part 1, available at http://blog.wizsec.jp/2017/07/breaking-open-mtgox-1.html (accessed 1. December 2017).

[20] cf. Recital 26 GDPR

[21] Recital 28 GDPR

[22] Article 29 Data Protection Working Party, Opinion 4/2007 on the concept of personal data, 20 June 2007, p. 18.

[23] Recital 28 GDPR

[24] cf. Article 3 GDPR

[25] 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.

[26] cf. Article 6 (1) (b-f) GDPR

[27] Article 4 (11) GDPR

[28] 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.

[29] 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.

[30] Article 6 (1) (b) GDPR

[31] Article 6 (1) (c) GDPR

[32] Article 6 (1) (e) GDPR

[33] 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.

[34] Article 29 Data Protection Working Party (WP29) Opinion 03/2013 on purpose limitation, 2. April 2013, p. 11.

[35] 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.

[36] cf. Recital 29 GDPR

[37] http://Blockchain.info

[38] cf. Article 5, 1(c) GDPR

[39] 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.

[40] Ibid.

[41] Ibid.

[42] Article 5.1 (d) GDPR

[43] 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

[44] Article 5.1 (d) GDPR

[45] Article 5.1 (e) GDPR

[46] 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.

[47] Ibid.

[48] cf. Recital 79 GDPR

[49] 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.

[50] 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.

[51] 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.

[52] 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)

[53] Similar view: Michael Isler, Datenschutz auf der Blockchain, in: Jusletter 4. Dezember 2017, p. 13

[54] 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).

[55] 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.

[56] Michael Isler, Datenschutz auf der Blockchain, in: Jusletter 4. Dezember 2017, p. 13

[57] Token Generation Event or Initial Coin Offering (ICO)

[58] Article 25 GDPR

[59] Article 35 et. sqq. GDPR

[60] 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.

[61] Examples are Monero and Zcash

[62] Nagib Aouini, Privacy-preserving techniques using zero knowledge proof in public Ethereum, available at https://www.slideshare.net/nagib2001/privacypreserving-techniques-using-zero-knowledge-proof-in-public-ethereum?trk=v-feed (accessed 15. December 2017).

Schreibe einen Kommentar

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden /  Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden /  Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden /  Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden /  Ändern )

w

Verbinde mit %s

%d Bloggern gefällt das: