P.S. my thanks to languagehasmeaning for sharing some insights into how he processes the information in chess. That may help me in the future. I've filed it away in my repository (reservoir) of datums/models that I draw off for epiphanies and insights. I'll give it some more thought when I have the down time and/or inspiration.
The real world doesn't work that way. Business collaborate one day and compete the next (or even the very same day). Even when collaborating they don't want to share all information, and certainly not with every member of a group. To control access to information once access to the blockchain has been granted at all, privacy features are needed.
...
There are multiple choices for what level of privacy and sharability a permissioned blockchain may have in an actual company. Not in technology terms, but in business process rationale. Certain blockchains may not be accessible by a competing/cooperating company at all, just like you are not giving away the direct access to your database/CRM.
The time will show the corporate blockchain use cases, but I do see your point though. I believe I have to refine what I've been saying. Permissioned blockchains will need the privacy features to define the level of data access for the participants. However, this doesn't have much to do with the zero-trust privacy. This may have more to do with centralized privacy and centrally assigned roles.
Honestly, I haven't given much thought to the potential architecture of such a solution. It may well not be existing, or it might have a semi-centralized form (masternodes, anyone?). However, intuitively I'd say that ringsig is a clumsy option in this case.
There's a brighter side to my original post if you wish: focus on the bigger commercializable issues.
Smooth's post (included what is not quoted above) was astute and resonated with my point that private block chains are like closed source. The end-to-end principle applies again in spades. We all want to leverage the same infrastructure (e.g. TCP/IP) and independently run a myriad of applications on the ends, which is enabled because the intermediary infrastructure is agnostic to our applications. I
mentioned this concept in my recent white paper on DDoS and footnote [8] in that paper. In short, there are virtually unlimited (much more than "multiple choices") degrees-of-freedom when the base infrastructure is agnostic to the use built on top of it.
This is why I believe privacy that can be done by the end applications will trump permissioned block chains. Sorry to James Dimon, IBM, and Blythe Masters. I will relish the day that James Dimon realizes that
his money is a depreciating asset in our Knowledge Age.
However the network layers of the internet are not responsible for maintaining a global unified consistency, but a block chain does. Thus the network layers of the internet have no problem trading off consistency and access of the CAP theorm, in exchange for not losing functionality (that is promised by the network transport layer) during partitioning. Whereas, during partitioning a block chain loses the promised functionality of preventing double-spends globally.
But in reality the internet doesn't function well when partitioned. This why for example popular services (e.g. Google, Facebook) have server nodes all over the globe (which is very evident to me when our trunk line from Philippines is down yet I can still access Facebook and Google and the local inquirer.net but not most other sites). I think it is likely the world will build the same redundancy for block chains. For example one of the designs I've toyed with is that using efficient hash tables we can communicate between partitions the double-spend conflicts without needing to transfer the entire block chain between partitions.
...
Hide Data, Not IP
...
So the government can still identify who is making those transactions and compel you to reveal your private keys or face the gulag, but in the normal use of the public block chain privacy is retained (to the extent it doesn't leak into non-hidden layers but that is the current world situation any way, so no worse).
...
Mix Data, Not Identity
I believe I'd agree with you on the theory. However, I'm still not sure how it may take off in the real world. IMO the discourse is utopian. I'll need some time to think it over.
The reason identity anonymity can't be done end-to-end principle (Zerocash almost does it, but as I pointed out there is
a DDoS weakness incurred), is because our IP address is an identity that we can't easily detach from ourselves. For all other forms of data privacy, the IP address problem is irrelevant.
With homomorphic encryption, we already know how to hide any state changes that rely on addition and multiplication, e.g. Confidential Values hiding the state change of value transfer because the Proof-of-Sum can be proven in Zero Knowledge.
Zerocash is built on the SNARKs technology which in its Pinocchio variant can hide the state changes of any program!!!
For smart contract data, there need not be a global master key. Each contract type could have a different master setup, but the tradeoff might be that perhaps we couldn't mix data types. I will need to spend more time studying these technologies.
So in theory, there is no data we can't hide. It is the meta-data that we can't hide, but that is the same problem corporations face today even with private data stores, so a public block chain with end-to-end data privacy doesn't make it any worse and it enables much greater degrees-of-freedom as compared to permissioned access chains.
I think the Zerocash and Pinocchio folks need to get busy being able to adapt their technologies to this frontier.
If I get my coin rolling, perhaps I'll be trying to fund them and coax them this direction. Hopefully others will pick up on this idea also. Perhaps some are already working on this direction.
