Appreciate odolvlobo,


Agree. GDPR is an old law that doesn't fit the reality behind new advances in technology and even breaks other rules like AML [1]. in other discussion with a good lawyer, have mentioned a subtle conflict among Article 16 of GDPR – Right to rectification - [2] and AML, because this section demands: "the controller has to edit data without undue delay", which means I could fabricate an identity, break the law and ask for rectification! at least blockchain never ever let you change anything and by removing data your fingerprint remains that one day you ask for removing something - on the historical blocks.

so just offered there should be a 7-days of "data preserve guaranty" just like 7-days of "money back guaranty" we have in e-commerce!
in other world, just think if we look better to the concept and behavior of the system, blockchains are more GDPR compliance than other centralized databases.

[1] https://en.wikipedia.org/wiki/Money_laundering
[2] https://gdpr-info.eu/art-16-gdpr/

Appreciate LoyceV,


I just try to look at the GDPR from other point of views. when article 17 published it was targeting facebook and other social medias to make them abide by the rights of their users - there was no intention in banning blockchain project like bitcoin. what happened in continue that is more amazing could be about spreading the importance of being and living decentralized, so GDPR is confronting blockchains based on quick development of technology. therefore, this is something good - I think, and this is why just try to consider it as a puzzle or a scientific problem and try to solve it as a research to respect the curiosity of my own mind - not being GDPR compliance.


this is exactly what I try to assess in this post. the possibility of removing a certain record without re-creating 50'000 blocks! the best way to understand it is work with examples:

so imagine we have a blockchain that ONLY holds people's EMAIL address in its block's payload. and I've been an employee in organization X for the last 5 years but now I'm going to work in organization Y, so I have to change my email address in that blockchain and somehow for some unknown "abuse-preventing" reasons no body should see my previous email address anymore. in this case I could add my new address to the new incoming block, but have to remove the old one. therefore, this is not about change a record, this is totally impossible and need to re-create those 50'000 blocks as you mentioned above.

as you could see a blockchian for emails doesn't need to verify user's balance and her historical transactions, so could simply remove the pure text under its hash on merkle tree. in this scenario, your blockchain just acts as a static repository - so no need to re-create all those 50'000 blocks before my old email address.

but things could get more complex in blockchains like bitcoin that work with numeric data and their balances based on historical transactions to verify. in these types of blockchains using a ZKP layer to find a solution is inevitable - but I'm not going to discuss it in this post at all.

appreciate etf! your are always here available for help.


1. when you decide to perform an analysis among some local databases and a full node, afraid GDPR applies.

2. true. just pointing to the FORK in confronting GDPR is because of its classic definition where we say if you have problem with the main root of a blockchain, fork it and begin your own root. so when you say: "I want my records between 2010-2015 get forgotten in a blockchain X", this could get called as a very special micro-fork within a chain. therefore, its "reorg" should now be a special one too, which have called it "reorg_gdpr"..

you know how lawmakers think! they say there could be an encrypted database in a firm that holds the equivalent of some bitcoin addresses to personal data of its customers for KYC, and one day this could get broken and publish in the internet! but please also consider that the GDPR is not just for anonymous blockchains, there may be a blockchain (permissioned) which uses people's SSN as address and their published records should be erasure by the article 17..

no way to flee - garlonicon  


this could be practical in some cases. for example if one company that analysis some personal data / activity of customers with its own bitcoin full node and needs to be GDPR compliance, so enables those features and could continue under EU regulation. but still broadcasting such requests to the entire network could be useful that makes every nodes informed around the globe about a personal GDPR-compliance request - despite of they approve it or not. this could show its impact on crypto price, etc..

once before just suggested here there would be an "oxidation fee" on coins which remain untouched for many years. so the whole consensus / security providers of Bitcoin blockchain (miners) that keep safe these coins for an account could get paid by the account owner..

this was just an example for the importance of having more tiers of fee structure - big like!

appreciate garlonicon,


some lawyers aren't agree with this, part of them say this could get broken by advances in cryptanalysis and processing power, other part of them express that just because people reveal their addresses in social media, their businesses or exhcnages, this is going to make trouble with GDPR compliance policy. I know this is too strict, but arises disputes.


True, working on GDPR in mempool-level is important. but as you see the article 17 is going to affect the whole blockchian from the genesis block to the last confirmed. so the question here is, when we should code our nodes to run the suggested "reorg_gdpr" command for old record on confirmed blocks? while the request is still in mempool or after write it down in the new block?


while this is not a classic fork situation, I hope each node could handle it as a queued series of local maintenance jobs whithin their idle time.


unfortunately this is exactly what GDPR needs to do - they need the initial blockchain be forgotten-able. but by running a "reorg_gdpr" command, in fact the original data of a specific record in a confirmed block will remove but its reflected tx hash value still remains for getting fully verified. we know this makes trouble with blockchains like bitcoin with numeric balances and needs more jobs to do but could be a solution for other blockchains that hold general data.

Hi there

being GDPR compliance in EU privacy law [1] is going to make trouble with decentralized systems based on blockchain and all suggested solutions till now just could mitigate the scope of problem [2]. but it seems there could be a concrete solution that we need to discuss it first:

Just talking about a new command in messaging protocol across peer-to-peer network of nodes, as a subset of "reorg" situation. in other words, when we are talking about Article 17 of the GDPR [3] - the right to erasure - when a user decides to be forgotten, in fact a very special fork is happening in the platform that calls the nodes they should "reorg". now if we label the new fork situation by command "reorg_gdpr", then our upgraded nodes should remove the targeted data under its mentioned hash value of an old tx, that exists as a new request in the mempool, and as you could see, nothing with the integrity of ex-blocks changes and the whole blockchain remains trusted in continue..

however blockchains that contain numeric values and their balances (like bitcoin) need more jobs to do, but blockchains with general data could simply cover it. all you need is a request from the owner of an old tx value, that has the same sign (hold the same private key) and asks the nodes to run a "reorg_gdpr" command on a specific tx record. so we save the users "reorg_gdpr" request in new block and erase the data that belongs to its tx value in the targeted old block.

any feedback welcome.


[1] https://gdpr-info.eu/
[2] https://cointelegraph.com/innovation-circle/zkp-could-help-resolve-blockchain-tensions-with-gdpr
[3] https://gdpr-info.eu/art-17-gdpr/

just afraid I didn't express the data flow of shadow-coin very well.

the second layer of PoW in shadow-coin processing just affects the block header of the main coin, so verifying transactions in detail will follow the principles of the main coin. RandomX or any other suggested algorithms only work with small amount of data same as Simplified Payment Verification (SPV) [1] needs to get done..

I suggest RandomX just because it enforces to provide CPU which is necessary to spread high quality nodes along a peer-to-peer networks. We need an economy running in that layer and this may increase the bitgold layer cap of any coin that equips by shadow-coin mechanism.


References:
[1] https://bitcoin.org/bitcoin.pdf / page 5

True.. it seems this could be something beyond a weakness and severity of such fake-nodes could be a problem for shadow-coin. so after a little modeling and reading current accepted weaknesses in peer-2-peer networks [1]:


I ask myself while we are dealing with such problems in current technology, this would be good idea to improve them all together:


and while fake-nodes are going to steal the processing power of other nodes, scoring is good idea and fits the situation of shadow-coin..

when a full node goes to act as a mining-pool for other incoming nodes, you should provide a db to write valid shares of each incoming node for any possible winning shadow-coin and pay them via lightning e.g. in future.[2] and as there is no guaranty for a miner to have her revenue back in mining world but connecting to famous and trusted pools around the Internet, after a while anonymous full nodes could get identified by their behavior in two groups of trusted and untrusted categories - but this time the trusted one preserves herself by second layer of PoW..

and still thinking..  

References:
[1] https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks
[2] https://en.wikipedia.org/wiki/Lightning_Network

this feasibility study really needs such questions to see if it is worthy enough - thank you Pooya..


making it harder to perform a sybil / DoS attack [1] against nodes [2] in a blockchain system should be the main reason of such suggestion. in other hand, while we could limit the number of incoming / outgoing peers - this may look useless to have extra protection layer for classic attacks as we face in web servers e.g. but in our project, we have some master nodes among other full nodes, so I always had this problem to find a rational way to have a routing system among peers to balance loads and mitigate some shapes of attacks mentioned above..

now, here we are! master nodes (or any other nodes based on many reasons behind their experiences in running a full node) could define their own policy to ask an incoming connection for a higher or lower difficulty to solve. a full node could write extra policies for its outbound connections too. for example, pick a node with high difficulty after every 100 low difficulty outbound connections.


people could turn it off or connect to nodes with zero difficulty, but we all know accessing to pure information costs. and actually this is why this new layer of PoW should end to a shadow-coin to encourage people to pay and buy good hardwares to run more reliable full nodes.  


it was about distinguish incoming/outgoing connections of peers. sorry for misinformation..  


true. I hope I have explained it a little more above..
but despite of encouraging people to run a full node, there is always doubts/dispute over those full/mining(Block-Producing) nodes that they do not completely verify new block's information [3][4][5].. so with this suggested feature, we know there will be another layer of PoW that makes them more money if they verify new blocks with more accuracy.. at least people could could stop doubting them..


I think I have a solution. first of all, the shadow-coin relies on the same merkle-root-hash of the main coin and this makes fake/semi-fake nodes useless. so, by a simple change in block version and add rows like shadow-address, shadow-nBits and shadow-nonce to the header, we could merge shadow-coin to the main network.. but handling this needs a trick. the shadow-coin in block header could refer to 10 blocks (or more) back in the chain (somehow passes enough block confirmation for the main coin) and aim at preventing unwanted delays in new block generation, some blocks could contain two or more rows of shadow-coins while some blocks contain no shadow-coin.

and there is also a raw idea here and I ask for evaluating it please: "while generation of shadow-coin takes place by contribution of all full nodes, with some proper changes in codes, reorg process by the main coin could get banned after broadcasting a block with shadow-coin in its header.. so I could see some good effects on disappointing selfish-miners and making it really harder to perform a 51% attacks.."

this also could answer pro Anti-ASIC bitcoiners [6] that abide by decentralized soul of cryptocurrencies..

References:
[1] https://en.bitcoin.it/wiki/Weaknesses#Denial_of_Service_.28DoS.29_attacks
[2] https://www.zdnet.com/article/researcher-kept-a-major-bitcoin-bug-secret-for-two-years-to-prevent-attacks/
[3] https://medium.com/nervosnetwork/dont-trust-verify-7c866ad1ed5b
[4] https://bitcoin.stackexchange.com/questions/80808/does-a-transaction-always-get-verified-processed-by-all-full-nodes-in-the-networ
[5] https://bitcoin.stackexchange.com/questions/81872/how-many-nodes-need-to-validate-a-newly-created-block
[6] https://bitcointalk.org/index.php?topic=5095048.0

Hi there..

due to coding our CORE in Azim Block Chain project [1], we did find out there could be an opportunity to set a tiny version of PoW during handshaking stage among nodes. In this workflow, server nodes send a challenge like job to client nodes and ask for solving a difficulty thingy. With this method:

1- We may meet a safer communication among nodes.
2- We could issue a shadow-coin under the main coin that encourages people to install more and more perfect nodes with same incentives that main PoW does to the entire network.

In Bitcoin, while we have sha256 algorithm in main coin, RandomX could be a good candidate for the shadow-coin as second layer of PoW..

any feedback welcome..


References:
[1] https://bitcointalk.org/index.php?topic=5089384.0

today I have received this link about the cost of Progpow and ASIC design and could give us more useful ideas for further discuss:

https://medium.com/@ifdefelse/the-cost-of-asic-design-a44f9a065b72

"Introduction

The speculation about hardware design and development costs as it pertains to both ProgPoW and Ethash are usually followed by a statement of authority: trust the author, because they have previous experience in <field>. Sometimes, it is cryptocurrency-ASIC production, other times, it is integrated-circuit design.

For the audience who is more familiar with code rather than fan-out and rise-times, a level of perspective on why this statement of authority does not apply to ProgPoW may be helpful."

My best candidate / suggestion for this concern is EXCHANGE CENTERS..



OK
just added your comments to the documents of PoCo.. thank you.

you just post a real concern in this topic.. and this is what I have done in PoCo Project [1], a hardware wallet that will be fully open source.. even the PCB, bill of material and drawing of the box will be available for everyone:

http://mixoftix.net/knowledge_base/blockchain/poco_wallet_prototype.jpg

an important note regarding to the PoCo Wallet is that, I try to provide a very different method for signing and save the private security value in this specific project, and this simply lets me to work with a very small (and cheap) AVR micro-controller, and I am not sure if the same AVR could do heavy process of bitcoin security model too (however there are sort of projects online that could handle asymmetric encryption by an AVR). anyways, simple micro-controllers better suit your real concerns about the necessity of an open source hardware project..

[1] https://bitcointalk.org/index.php?topic=5066624.0

wrong analysis..

the first ASIC emerged in bitcoin in 2011 [1][2] but ASICs widely got used in 2014 [3] and your first graph shows how harmful are ASICs. your graph of 2019 is decentralized because of crash in market and price level of bitcoin, so industrial mining farms shut down their facilities. the next increment in price level changes the distribution of process again.. ASICs role as Sword of Damocles.


[1] https://thenextweb.com/hardfork/2018/02/02/a-brief-history-of-bitcoin-mining-hardware/
[2] https://en.bitcoin.it/wiki/List_of_Bitcoin_mining_ASICs
[3] http://blog.zorinaq.com/bitcoin-electricity-consumption/

of course we replace bank with blockchain here..

in fact a payment with crypto matches the "remittance money flow" in classic payment models which payer A "initiates" the flow by submitting the transfer order to bank A and bank A relays the order to bank B that sends an indication message to recipient B (in blockchain version, payer A submits her raw transaction to a node and after insertion into a block, the amount of confirmation that recipient B observes enrolls as indication message from bank B). and this model obviously causes DELAY in check-out step.

now look at the money flow in check-or-credit-like payment model. in these cases, the payer A submits her payment directly to recipient B. then recipient B sends the payment capture to bank B. then bank B invite bank A in a "settlement" process. this is why I basically suggest you follow the check-or-credit-like payment model, because I think payer A could submit her raw transaction to recipient B and let him to submit it to a node and let adding the transaction to the blockchain happen in a settlement like process. in this model you need to know your customer very well.

but the "debit order" model is totally a new field for research to fit in crypto world. in this model the recipient B is the initiator of payment and submits his debit order to bank B and bank A transfer in continue, but also sends an indication to payer A and listen to any protest from payer A. in a post that entitled "Dead man's switch" we had good comments/codes about reversible transactions in bitcoin:

https://bitcointalk.org/index.php?topic=5069728.0

totally true, BUT a centralized system like banking system could simply publish an announcement about abandoning e-signs (for a while) and ask its customers for get back to the traditional paper-based methods. I mean they that several alternatives, but a crypto only could survive in virtual world.

I could suggest 2 characteristics for such printable things:

- call it check (cheque in British) instead of coupons or cash
- consider the principles of direct debit [1] and forget any kinds of fast processing

and for having an advanced approach to the solution:

- include principles of zero-knowledge proof to the process [2]


[1] https://en.wikipedia.org/wiki/Direct_debit
[2] https://en.wikipedia.org/wiki/Zero-knowledge_proof

as ETFBitcon mentioned above, the Banking system is centralized and roll-backing transactions are very legitimate procedures that could take place based on identified circumstances. imagine a credit card owner that gets hurt by a QC, then its owner could call her bank and report the problem and ask for roll-back.
AND centralized systems:

1. could simply equip by 2-factor authentication flows
2. do not let their routines be available for brute-forcing

we all know that an internet banking system only allows e.g. 3 or 5 unsuccessful try for login routine, otherwise they block a user account. such routines couldn't implement in decentralized architectures. attacking the HTTPS protocol will be trivial too, because the 2-factor auths that utilize advanced OTP generators could prevent any kinds of MITM attacks.

then may I have your (and other skilled contributors) opinion and reply with the idea of flash-back-pinning:

https://bitcointalk.org/index.php?topic=5089384.0

I think such improvement could lead us to another stage of co-existing with ASICs and mitigate the threat.