Re: NEM partners with major bank, consortium of 5000 businesses, and cloud service
jabo38,
Why did you make a duplicate thread in this forum? That is frowned upon and can be reported to the moderator.
You are obviously an investor and I can't help you if you are determined to lose your money chasing failed concepts. But I can offer my opinion for other speculators to consider.
Private block chains are a big yawn, because they break the trustless property of block chains (if you don't understand that, then you shouldn't be investing in anything until you finish a crypto 101 course):
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.
How to not make an altcoin for the masses:
fuhgeddaboudit.
Not to be rascist but factual. I think you will soon learn why Japanese are not leaders in software evolution.
Why did you make a duplicate thread in this forum? That is frowned upon and can be reported to the moderator.
You are obviously an investor and I can't help you if you are determined to lose your money chasing failed concepts. But I can offer my opinion for other speculators to consider.
Private block chains are a big yawn, because they break the trustless property of block chains (if you don't understand that, then you shouldn't be investing in anything until you finish a crypto 101 course):
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.
How to not make an altcoin for the masses:
Quote from: http://www.nem.io/faq.html
How do I install Java?
Check your java version HERE. If you are using Java Version 8, update 25 or above, you are ready to install the NEM client.
How do I open Port 7890?
Check your java version HERE. If you are using Java Version 8, update 25 or above, you are ready to install the NEM client.
How do I open Port 7890?
fuhgeddaboudit.
Not to be rascist but factual. I think you will soon learn why Japanese are not leaders in software evolution.