1. Toc
  2. Topics

[Hyperledger Project TSC] IBM whitepaper

benedikt herudek <benedikt.herudek@...>
 

Hi there

Here an interesting interview, also on permissioned Blockchains in general. Links in some respects to a question (point 2 below) raised below

https://medium.com/institute-for-the-future/bitcoin-is-the-sewer-rat-of-currencies-b89819cdf036?imm_mid=0e1455&cmp=em-na-na-na-newsltr_fintech_20160307#.d9zaflrun

@dear IBMers, maybe missed it, but some remarks to below two reviews of your whitepaper would be great. Actually, it points to a broader issue, question on identity management to secure blockchain, which seems worthwhile discussing.

regards groet gruss

Benedikt

On 23 feb. 2016, at 11:49, benedikt herudek <benedikt.herudek@...> wrote:

ok, get your point ! indeed, without turing complete machines, things
look different.

Two questions:
1. How will you then have binding smart scripts ? You basically 'only
secure' the data on the blockchain, you dont plug together atomic
transactions, like: you switch on some device for me, then blockchain
script sends you currency
2. even if you have no turing complete language on the blockchain,
would see the need of a strong obligatory consensus mechanism. if you
have only identity management, it seems to me (happy to be corrected)
you basically rely on 'disciplining' your well-known members in case
they would introduce forged copies.

Hi Fabian, Hello Benedict, I would hope for an architecture where a blockchain stores more than letters of intent but implements somewhat more binding and automated smart contracts. A "letter of intent" can still execute a smart contract. The smart contract would just not be executed as part of the blockchain protocol but 'outside' of the blockchain. In the end, a turing machine consists of a storage and an executing unit and I propose the executing unit to be outside of the blockchain (which is just for storage). Well, this is just one way to do it and I would rather see the features of the chain be implemented as blockchain protocol. I envision a blockchain that has some reduced (but extendable) set of allowed operations (non turing complete) that enable the implementation of a high-speed and highly scalable blockchain, while turing complete scripting (e.g. the EVM) can be plugged in as an outside protocol, that can be executed by 3rd party but is not part of the blockchain protocol. Agree with the necessity of Identity Management and scalability. Copied in my points below (to have on thread): 1. would see the need of a strong obligatory consensus mechanismus, it seems optional in OBC. 2.An open question to me seems how you want to block malicious code (turing halting problem), if you don't introduce a digitcal currency and hence allow something like the notion of gas in ethereum to stop too long running transactions. With what I proposed above, you don't have that issue since the blockchain doesn't execute any user defined script but only runs those that have been integrated into the blockchain protocol. Cheers -- Fabian regards benedikt --- regards groet gruss benedikt herudek On 23.02.2016 10:29, Fabian Schuh via hyperledger-tsc wrote: &gt; This is an excellent paper to get a rough idea and it is well written. Good job. &gt; &gt; We at Cryptonomex have though about some parts of your design already and agree on most of them: &gt; &gt; * There is a need for an identity management on top of a blockchain. For that reasons, you would like to have customers register an account name (together with public keys)on the blockchain and authenticate every transaction with on of your accounts &gt; * The blockchain mere purpose is to store "letters of intent" from users (e.g. instructions) and they could be anything from "transfers" to sell orders for decentralized order books. &gt; &gt; Now comes the "issue": If you want these instructions to be "executed" as a part of your blockchain protocol (you call them chaincode) such that the blockchain as a database transits into a new "state", then you need to take quite some care about scalability and speed as every instruction has to be executed on every full node if you want to have a trustless system. &gt; &gt; Two strategies exist out of this misery: &gt; a) not every node on your network validates every instruction but only &gt; a set of elected validators do and &gt; they validate each other. &gt; b) you don't execute any instruction at all and let the end users (or &gt; intermediate service) determine the &gt; actual state of the whole (or a part) of the blockchain database. &gt; (We have this implemented already and &gt; call this technology "Plasma" internally). &gt; &gt; Anyway, seeing how you would like this technology to evolve and knowing that we already have parts of it implemented, maybe we should consider a closer partnership between IBM and Cryptonomex. &gt; &gt; Best regards &gt; -- Fabian !!!!!!!!!!!!!! COPIED IN !!!!!!!!!!

benedikt herudek <benedikt.herudek@...>
 

Here an interesting interview, also on permissioned Blockchains in general. Links in some respects to a question (point 2 below) raised below

https://medium.com/institute-for-the-future/bitcoin-is-the-sewer-rat-of-currencies-b89819cdf036?imm_mid=0e1455&cmp=em-na-na-na-newsltr_fintech_20160307#.d9zaflrun

@dear IBMers, maybe missed it, but some remarks to below two reviews of your whitepaper would be great. Actually, it points to a broader issue, question on identity management to secure blockchain, which seems worthwhile discussing.

regards groet gruss

Benedikt

On 23 feb. 2016, at 11:49, benedikt herudek <benedikt.herudek@...> wrote:

ok, get your point ! indeed, without turing complete machines, things
look different.

Two questions:
1. How will you then have binding smart scripts ? You basically 'only
secure' the data on the blockchain, you dont plug together atomic
transactions, like: you switch on some device for me, then blockchain
script sends you currency
2. even if you have no turing complete language on the blockchain,
would see the need of a strong obligatory consensus mechanism. if you
have only identity management, it seems to me (happy to be corrected)
you basically rely on 'disciplining' your well-known members in case
they would introduce forged copies.

Hi Fabian, Hello Benedict, I would hope for an architecture where a blockchain stores more than letters of intent but implements somewhat more binding and automated smart contracts. A "letter of intent" can still execute a smart contract. The smart contract would just not be executed as part of the blockchain protocol but 'outside' of the blockchain. In the end, a turing machine consists of a storage and an executing unit and I propose the executing unit to be outside of the blockchain (which is just for storage). Well, this is just one way to do it and I would rather see the features of the chain be implemented as blockchain protocol. I envision a blockchain that has some reduced (but extendable) set of allowed operations (non turing complete) that enable the implementation of a high-speed and highly scalable blockchain, while turing complete scripting (e.g. the EVM) can be plugged in as an outside protocol, that can be executed by 3rd party but is not part of the blockchain protocol. Agree with the necessity of Identity Management and scalability. Copied in my points below (to have on thread): 1. would see the need of a strong obligatory consensus mechanismus, it seems optional in OBC. 2.An open question to me seems how you want to block malicious code (turing halting problem), if you don't introduce a digitcal currency and hence allow something like the notion of gas in ethereum to stop too long running transactions. With what I proposed above, you don't have that issue since the blockchain doesn't execute any user defined script but only runs those that have been integrated into the blockchain protocol. Cheers -- Fabian regards benedikt --- regards groet gruss benedikt herudek On 23.02.2016 10:29, Fabian Schuh via hyperledger-tsc wrote: &gt; This is an excellent paper to get a rough idea and it is well written. Good job. &gt; &gt; We at Cryptonomex have though about some parts of your design already and agree on most of them: &gt; &gt; * There is a need for an identity management on top of a blockchain. For that reasons, you would like to have customers register an account name (together with public keys)on the blockchain and authenticate every transaction with on of your accounts &gt; * The blockchain mere purpose is to store "letters of intent" from users (e.g. instructions) and they could be anything from "transfers" to sell orders for decentralized order books. &gt; &gt; Now comes the "issue": If you want these instructions to be "executed" as a part of your blockchain protocol (you call them chaincode) such that the blockchain as a database transits into a new "state", then you need to take quite some care about scalability and speed as every instruction has to be executed on every full node if you want to have a trustless system. &gt; &gt; Two strategies exist out of this misery: &gt; a) not every node on your network validates every instruction but only &gt; a set of elected validators do and &gt; they validate each other. &gt; b) you don't execute any instruction at all and let the end users (or &gt; intermediate service) determine the &gt; actual state of the whole (or a part) of the blockchain database. &gt; (We have this implemented already and &gt; call this technology "Plasma" internally). &gt; &gt; Anyway, seeing how you would like this technology to evolve and knowing that we already have parts of it implemented, maybe we should consider a closer partnership between IBM and Cryptonomex. &gt; &gt; Best regards &gt; -- Fabian !!!!!!!!!!!!!! COPIED IN !!!!!!!!!!

Tamas Blummer <tamas@...>
 

Hi Mic,

a joint proposal, that we circulated earlier on this list and will discuss on today's TSC call, attempts to merge a forward-looking technology exploration friendly fabric with an API for higher level application layers and the mature technology of the Bitcoin network. 

Our hlp-candidate that serves as one of the starting points in the proposal and might accommodate some of your uses. We hope on your contribution into the merge process we suggest, so features and design choices you like will be preserved.

Tamas Blummer
Chief Ledger Architect


On 24 Feb 2016, at 23:16, Bowman, Mic via hyperledger-tsc <hyperledger-tsc@...> wrote:

Thanks for putting this together. The white paper is a good starting point. That said, I have some concerns and a few questions. My concerns boil down to two areas: how do we ensure that the architecture/implementation is not limited to the usages we start with (that is, that we do not preclude additional usages) and how do we ensure that the architecture preserves the disintermediation that distinguishes digital ledgers from simple replicated databases.
 
·         In the abstract you reference business to business and business to customers as the two focus areas. While I fully acknowledge the “idiosyncrasies” of Bitcoin, it remains (one of?) the most popular, most active, and most mature of the digital ledgers. In general, sacrificing consumer to consumer usages (of which Bitcoin is one example) before we even begin to explore the architecture seems unfortunate. Clearly we can think of an ordering of usages based on time criticality, business viability, and probability of adoption… however, considering a broad set of usages ensures that decisions made for the most immediate usages don’t preclude other usages that may become the focus later.
·         You’ve provided three usages though there seems to be significant overlap in the requirements driven by those three. If we are going to limit discussion to three or four usages, I would prefer that they stretch thinking about the architecture. I strongly favor moving quickly on what we know (that is, pick one of the usages you propose to focus early implementation), but not if that means sacrificing the flexibility to address in the future the full spectrum of distributed ledger applications. Architectures ossify very quickly with implementation (which is both good and bad). In addition to the ones you provided (which are clearly the most important in the short term) we have a couple additional usages that we use as the basis for our thinking. I’ll publish them in a separate message.
·         The document seems to focus entirely on permissioned ledgers with vetted participants with centrally distributed identities. The architecture has a very strong dependency on what you called the “Membership Service”. I couldn’t find any additional details about that service. From the description it looks like a centralized PKI service. Was that your intention? If so, who runs that? If not, then what is your thinking about the vetting process for participants? I presume there are both a technical and institutional aspects of the solution. How do you imagine multiple providers working together to provide that service? As you are probably aware, Intel is using EPID for enclave attestation in SGX. That provides a way to verify the integrity of computations based on a trusted execution environment without disclosing identity. We would certainly like to consider the role of that capability in the Registration Service.
·         In most of the deployed ledgers we’ve looked (and we found this to be the case for our own tests), there is some way to manage transaction ingress to avoid DOS attacks and manage over-subscription of capacity. I really like the Ripple approach of “burning XRPs” as a way of ensuring that there is some back-pressure on transaction submission (you can easily submit valid transactions but it’s hard to submit enough to perform a DOS attack). Bitcoin miners are free to establish mechanisms to prioritize the transactions selected for a particular block (and there appear to be many such policies). Even in a permissioned ledger, there is a danger of one institution monopolizing a substantial portion of the resources unless there is some decentralized policy for managing resource utilization. As a group, we should think about mechanisms for incentivizing good behavior or constraining (possibly correct but) inappropriate behavior.
·         In the Usage FAQ linked to the white paper the expected performance numbers are 100K tps with 15 validating nodes “running in close proximity”. What does “close proximity” mean in this case? Single data center? Single metropolitan area? Implementations traditional BFT algorithms are hard to get right and are *VERY* difficult to scale to large numbers of participants (where large is 50). Even if we assume that there are some (to be discovered) techniques for scaling that to a few 100’s of replicas, that severely limits the decentralization of the ledger validation service (so we end up with just a replicated database). What are your thought about the organizational/institutional impact of that architecture (e.g. are there hierarchies of consortiums)? Clearly not every organization that would use the ledger would be in a position to participate in the validation of transactions. That means, at best, we have to build some kind of consortium to manage the limited number of validators or, at worst, we end up with a single provider (in which case we aren’t really talking about a distributed ledger any more).
·         And on the performance… again, it seems likely that some form of traditional BFT algorithm is going to be necessary for the financial applications where there are problems with the rollback potential in the proof-of-* blockchain consensus algorithms (including the one I talked about in the review last week). BFT algorithms force us into a small validator pool deployment. However, not all workloads are intolerant of rollback and are amenable to more scalable (where scalable is defined in terms of number and decentralization of validation resources) algorithms.. It seems unlikely that the three usages in the white paper will expose those requirements. I’m fairly certain that the IoT device registries and some other uses like that would help to expand our thinking.
·         One more issue that is probably more implementation than architecture… we have some concerns about the use of containers. The most obvious is the increase in the number of docker exploits that have been documented recently (see for example https://www.oreilly.com/ideas/five-security-concerns-when-using-docker and https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9357). The other concern that that containers limit access to unique HW capabilities like SGX.
 
Again… I really like the architecture for addressing the needs of small groups of vetted organizations with high transaction rate requirements which is the dominant use in FSI. I look forward to working through validation of that claim and to adapting this (or another architecture if appropriate) to a broader set of requirements.
 
--mic
 
C. Mic Bowman
Principal Engineer
Intel Corporation
 
 
From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Christopher B Ferris via hyperledger-tsc
Sent: Thursday, February 18, 2016 8:32 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] IBM whitepaper
 
All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback.
 
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
 
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Mic Bowman
 

Thanks for putting this together. The white paper is a good starting point. That said, I have some concerns and a few questions. My concerns boil down to two areas: how do we ensure that the architecture/implementation is not limited to the usages we start with (that is, that we do not preclude additional usages) and how do we ensure that the architecture preserves the disintermediation that distinguishes digital ledgers from simple replicated databases.

 

·         In the abstract you reference business to business and business to customers as the two focus areas. While I fully acknowledge the “idiosyncrasies” of Bitcoin, it remains (one of?) the most popular, most active, and most mature of the digital ledgers. In general, sacrificing consumer to consumer usages (of which Bitcoin is one example) before we even begin to explore the architecture seems unfortunate. Clearly we can think of an ordering of usages based on time criticality, business viability, and probability of adoption… however, considering a broad set of usages ensures that decisions made for the most immediate usages don’t preclude other usages that may become the focus later.

·         You’ve provided three usages though there seems to be significant overlap in the requirements driven by those three. If we are going to limit discussion to three or four usages, I would prefer that they stretch thinking about the architecture. I strongly favor moving quickly on what we know (that is, pick one of the usages you propose to focus early implementation), but not if that means sacrificing the flexibility to address in the future the full spectrum of distributed ledger applications. Architectures ossify very quickly with implementation (which is both good and bad). In addition to the ones you provided (which are clearly the most important in the short term) we have a couple additional usages that we use as the basis for our thinking. I’ll publish them in a separate message.

·         The document seems to focus entirely on permissioned ledgers with vetted participants with centrally distributed identities. The architecture has a very strong dependency on what you called the “Membership Service”. I couldn’t find any additional details about that service. From the description it looks like a centralized PKI service. Was that your intention? If so, who runs that? If not, then what is your thinking about the vetting process for participants? I presume there are both a technical and institutional aspects of the solution. How do you imagine multiple providers working together to provide that service? As you are probably aware, Intel is using EPID for enclave attestation in SGX. That provides a way to verify the integrity of computations based on a trusted execution environment without disclosing identity. We would certainly like to consider the role of that capability in the Registration Service.

·         In most of the deployed ledgers we’ve looked (and we found this to be the case for our own tests), there is some way to manage transaction ingress to avoid DOS attacks and manage over-subscription of capacity. I really like the Ripple approach of “burning XRPs” as a way of ensuring that there is some back-pressure on transaction submission (you can easily submit valid transactions but it’s hard to submit enough to perform a DOS attack). Bitcoin miners are free to establish mechanisms to prioritize the transactions selected for a particular block (and there appear to be many such policies). Even in a permissioned ledger, there is a danger of one institution monopolizing a substantial portion of the resources unless there is some decentralized policy for managing resource utilization. As a group, we should think about mechanisms for incentivizing good behavior or constraining (possibly correct but) inappropriate behavior.

·         In the Usage FAQ linked to the white paper the expected performance numbers are 100K tps with 15 validating nodes “running in close proximity”. What does “close proximity” mean in this case? Single data center? Single metropolitan area? Implementations traditional BFT algorithms are hard to get right and are *VERY* difficult to scale to large numbers of participants (where large is 50). Even if we assume that there are some (to be discovered) techniques for scaling that to a few 100’s of replicas, that severely limits the decentralization of the ledger validation service (so we end up with just a replicated database). What are your thought about the organizational/institutional impact of that architecture (e.g. are there hierarchies of consortiums)? Clearly not every organization that would use the ledger would be in a position to participate in the validation of transactions. That means, at best, we have to build some kind of consortium to manage the limited number of validators or, at worst, we end up with a single provider (in which case we aren’t really talking about a distributed ledger any more).

·         And on the performance… again, it seems likely that some form of traditional BFT algorithm is going to be necessary for the financial applications where there are problems with the rollback potential in the proof-of-* blockchain consensus algorithms (including the one I talked about in the review last week). BFT algorithms force us into a small validator pool deployment. However, not all workloads are intolerant of rollback and are amenable to more scalable (where scalable is defined in terms of number and decentralization of validation resources) algorithms.. It seems unlikely that the three usages in the white paper will expose those requirements. I’m fairly certain that the IoT device registries and some other uses like that would help to expand our thinking.

·         One more issue that is probably more implementation than architecture… we have some concerns about the use of containers. The most obvious is the increase in the number of docker exploits that have been documented recently (see for example https://www.oreilly.com/ideas/five-security-concerns-when-using-docker and https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-9357). The other concern that that containers limit access to unique HW capabilities like SGX.

 

Again… I really like the architecture for addressing the needs of small groups of vetted organizations with high transaction rate requirements which is the dominant use in FSI. I look forward to working through validation of that claim and to adapting this (or another architecture if appropriate) to a broader set of requirements.

 

--mic

 

C. Mic Bowman

Principal Engineer

Intel Corporation

 

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Christopher B Ferris via hyperledger-tsc
Sent: Thursday, February 18, 2016 8:32 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] IBM whitepaper

 

All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback.

 

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

Fabian Schuh <fabian@...>
 

ok, get your point ! indeed, without turing complete machines, things
look different.

Two questions:
1. How will you then have binding smart scripts ? You basically 'only
secure' the data on the blockchain, you dont plug together atomic
transactions, like: you switch on some device for me, then blockchain
script sends you currency
The blockchain doesn't tell you if a transactions is valid, it only shows you that
it has been authorized by someone.
Executing a contract is a matter of running the ordered transactions through a
finite state machine. Those transactions that are invalid (e.g. double spend) are
ignored. At the end, the finite state machine reaches the new state of the 'database'.
Main difference is that the FSM is not executed as part of the blockchain (consensus)
protocol but as a user-side plugin that merely takes its inputs from the blockchain.
Any smart contract can be run that way as well.

2. even if you have no turing complete language on the blockchain,
would see the need of a strong obligatory consensus mechanism. if you
have only identity management, it seems to me (happy to be corrected)
you basically rely on 'disciplining' your well-known members in case
they would introduce forged copies.
You shouldn't trust anything that is written on this kind of blockchain (unless you can
trust a users reputation) but should run a smart contract on top of the data stored in
the blockchain. Only then will you get a new state for your chain (e.g. set of unspend
outputs).

In essence, you allow a user to put ANY kind of data in the blockchain and filter it out
by validation through a FSM that is pluggin in ontop of the *raw* blockchain data.
Advantage is that you can have turing complete scripting on the user side and even hide you
contracts as they are not stored on the blockchain but only the (potentially encrypted) data
is stored on the common blockchain.

Regards
-- Fabian

Hi Fabian, Hello Benedict, I would hope for an architecture where a blockchain stores more than letters of intent but implements somewhat more binding and automated smart contracts. A "letter of intent" can still execute a smart contract. The smart contract would just not be executed as part of the blockchain protocol but 'outside' of the blockchain. In the end, a turing machine consists of a storage and an executing unit and I propose the executing unit to be outside of the blockchain (which is just for storage). Well, this is just one way to do it and I would rather see the features of the chain be implemented as blockchain protocol. I envision a blockchain that has some reduced (but extendable) set of allowed operations (non turing complete) that enable the implementation of a high-speed and highly scalable blockchain, while turing complete scripting (e.g. the EVM) can be plugged in as an outside protocol, that can be executed by 3rd party but is not part of the blockchain protocol. Agree with the necessity of Identity Management and scalability. Copied in my points below (to have on thread): 1. would see the need of a strong obligatory consensus mechanismus, it seems optional in OBC. 2.An open question to me seems how you want to block malicious code (turing halting problem), if you don't introduce a digitcal currency and hence allow something like the notion of gas in ethereum to stop too long running transactions. With what I proposed above, you don't have that issue since the blockchain doesn't execute any user defined script but only runs those that have been integrated into the blockchain protocol. Cheers -- Fabian regards benedikt --- regards groet gruss benedikt herudek On 23.02.2016 10:29, Fabian Schuh via hyperledger-tsc wrote: &gt; This is an excellent paper to get a rough idea and it is well written. Good job. &gt; &gt; We at Cryptonomex have though about some parts of your design already and agree on most of them: &gt; &gt; * There is a need for an identity management on top of a blockchain. For that reasons, you would like to have customers register an account name (together with public keys)on the blockchain and authenticate every transaction with on of your accounts &gt; * The blockchain mere purpose is to store "letters of intent" from users (e.g. instructions) and they could be anything from "transfers" to sell orders for decentralized order books. &gt; &gt; Now comes the "issue": If you want these instructions to be "executed" as a part of your blockchain protocol (you call them chaincode) such that the blockchain as a database transits into a new "state", then you need to take quite some care about scalability and speed as every instruction has to be executed on every full node if you want to have a trustless system. &gt; &gt; Two strategies exist out of this misery: &gt; a) not every node on your network validates every instruction but only &gt; a set of elected validators do and &gt; they validate each other. &gt; b) you don't execute any instruction at all and let the end users (or &gt; intermediate service) determine the &gt; actual state of the whole (or a part) of the blockchain database. &gt; (We have this implemented already and &gt; call this technology "Plasma" internally). &gt; &gt; Anyway, seeing how you would like this technology to evolve and knowing that we already have parts of it implemented, maybe we should consider a closer partnership between IBM and Cryptonomex. &gt; &gt; Best regards &gt; -- Fabian !!!!!!!!!!!!!! COPIED IN !!!!!!!!!!
--

*Fabian Schuh* / Business Developer, Technical Consultant
fabian@... <mailto:fabian@...>


CRYPTONOMEX, INC.

2020 Kraft Dr Suite 3040
Blacksburg, VA 24060
www.cryptonomex.com <https://www.cryptonomex.com>

<https://www.linkedin.com/company/cryptonomex-inc-> <https://github.com/cryptonomex> <https://twitter.com/cryptonomex> <https://www.facebook.com/cryptonomex>

Cryptonomex is a leading supplier of advanced block chain technology. That can range from simple advice, to deployment of your application on one of our public block chains, to creating your own private chain

benedikt herudek <benedikt.herudek@...>
 

ok, get your point ! indeed, without turing complete machines, things
look different.

Two questions:
1. How will you then have binding smart scripts ? You basically 'only
secure' the data on the blockchain, you dont plug together atomic
transactions, like: you switch on some device for me, then blockchain
script sends you currency
2. even if you have no turing complete language on the blockchain,
would see the need of a strong obligatory consensus mechanism. if you
have only identity management, it seems to me (happy to be corrected)
you basically rely on 'disciplining' your well-known members in case
they would introduce forged copies.

Hi Fabian, Hello Benedict, I would hope for an architecture where a blockchain stores more than letters of intent but implements somewhat more binding and automated smart contracts. A "letter of intent" can still execute a smart contract. The smart contract would just not be executed as part of the blockchain protocol but 'outside' of the blockchain. In the end, a turing machine consists of a storage and an executing unit and I propose the executing unit to be outside of the blockchain (which is just for storage). Well, this is just one way to do it and I would rather see the features of the chain be implemented as blockchain protocol. I envision a blockchain that has some reduced (but extendable) set of allowed operations (non turing complete) that enable the implementation of a high-speed and highly scalable blockchain, while turing complete scripting (e.g. the EVM) can be plugged in as an outside protocol, that can be executed by 3rd party but is not part of the blockchain protocol. Agree with the necessity of Identity Management and scalability. Copied in my points below (to have on thread): 1. would see the need of a strong obligatory consensus mechanismus, it seems optional in OBC. 2.An open question to me seems how you want to block malicious code (turing halting problem), if you don't introduce a digitcal currency and hence allow something like the notion of gas in ethereum to stop too long running transactions. With what I proposed above, you don't have that issue since the blockchain doesn't execute any user defined script but only runs those that have been integrated into the blockchain protocol. Cheers -- Fabian regards benedikt --- regards groet gruss benedikt herudek On 23.02.2016 10:29, Fabian Schuh via hyperledger-tsc wrote: &gt; This is an excellent paper to get a rough idea and it is well written. Good job. &gt; &gt; We at Cryptonomex have though about some parts of your design already and agree on most of them: &gt; &gt; * There is a need for an identity management on top of a blockchain. For that reasons, you would like to have customers register an account name (together with public keys)on the blockchain and authenticate every transaction with on of your accounts &gt; * The blockchain mere purpose is to store "letters of intent" from users (e.g. instructions) and they could be anything from "transfers" to sell orders for decentralized order books. &gt; &gt; Now comes the "issue": If you want these instructions to be "executed" as a part of your blockchain protocol (you call them chaincode) such that the blockchain as a database transits into a new "state", then you need to take quite some care about scalability and speed as every instruction has to be executed on every full node if you want to have a trustless system. &gt; &gt; Two strategies exist out of this misery: &gt; a) not every node on your network validates every instruction but only &gt; a set of elected validators do and &gt; they validate each other. &gt; b) you don't execute any instruction at all and let the end users (or &gt; intermediate service) determine the &gt; actual state of the whole (or a part) of the blockchain database. &gt; (We have this implemented already and &gt; call this technology "Plasma" internally). &gt; &gt; Anyway, seeing how you would like this technology to evolve and knowing that we already have parts of it implemented, maybe we should consider a closer partnership between IBM and Cryptonomex. &gt; &gt; Best regards &gt; -- Fabian !!!!!!!!!!!!!! COPIED IN !!!!!!!!!!

Fabian Schuh <fabian@...>
 

Hi Fabian,
Hello Benedict,

I would hope for an architecture where a blockchain stores more than letters of intent but implements somewhat more binding and automated smart contracts.
A "letter of intent" can still execute a smart contract. The smart contract would just not be executed as part of the blockchain protocol
but 'outside' of the blockchain. In the end, a turing machine consists of a storage and an executing unit and I propose the executing unit
to be outside of the blockchain (which is just for storage). Well, this is just one way to do it and I would rather see the features of the
chain be implemented as blockchain protocol.
I envision a blockchain that has some reduced (but extendable) set of allowed operations (non turing complete) that enable the implementation
of a high-speed and highly scalable blockchain, while turing complete scripting (e.g. the EVM) can be plugged in as an outside protocol, that
can be executed by 3rd party but is not part of the blockchain protocol.

Agree with the necessity of Identity Management and scalability.

Copied in my points below (to have on thread):
1. would see the need of a strong obligatory consensus mechanismus, it seems optional in OBC.
2.An open question to me seems how you want to block malicious code (turing halting problem), if you don't introduce a digitcal currency and hence allow something like the notion of gas in ethereum to stop too long running transactions.
With what I proposed above, you don't have that issue since the blockchain doesn't execute any user defined script but only runs those that have
been integrated into the blockchain protocol.

Cheers
-- Fabian

regards

benedikt

---
regards groet gruss

benedikt herudek

On 23.02.2016 10:29, Fabian Schuh via hyperledger-tsc wrote:
This is an excellent paper to get a rough idea and it is well written. Good job.

We at Cryptonomex have though about some parts of your design already and agree on most of them:

* There is a need for an identity management on top of a blockchain. For that reasons, you would like to have customers register an account name (together with public keys)on the blockchain and authenticate every transaction with on of your accounts
* The blockchain mere purpose is to store "letters of intent" from users (e.g. instructions) and they could be anything from "transfers" to sell orders for decentralized order books.

Now comes the "issue": If you want these instructions to be "executed" as a part of your blockchain protocol (you call them chaincode) such that the blockchain as a database transits into a new "state", then you need to take quite some care about scalability and speed as every instruction has to be executed on every full node if you want to have a trustless system.

Two strategies exist out of this misery:
a) not every node on your network validates every instruction but only
a set of elected validators do and
they validate each other.
b) you don't execute any instruction at all and let the end users (or
intermediate service) determine the
actual state of the whole (or a part) of the blockchain database.
(We have this implemented already and
call this technology "Plasma" internally).

Anyway, seeing how you would like this technology to evolve and knowing that we already have parts of it implemented, maybe we should consider a closer partnership between IBM and Cryptonomex.

Best regards
-- Fabian
!!!!!!!!!!!!!! COPIED IN !!!!!!!!!!

-------- Original Message --------
Subject: Re: [Hyperledger Project TSC] IBM whitepaper
Date: 20.02.2016 16:15
From: benedikt herudek <benedikt.herudek@...>
To: hyperledger-tsc@...

Hi Chris,

excellent paper !

Below two remarks / questions around Identity Management vs Consensus and one suggestion concerning data privacy on permissioned blockchains.

Interested in anyone's view.

regards

benedikt


1st remark: Chain Language, Turing halting problem & native currency:

Understand, you don't introduce a native OBC currency. It seems you might introduce a native OBC language in the future. But at the moment, you support existing languages like go. https://github.com/openblockchain/obc-docs/blob/master/FAQ/chaincode_FAQ.md

Without a native currency, but with a full turing complete language, how will you address someone introducing mailicious code running through endless loops and eating up ressources ? Ethereum wants to address this with the notion of gas, so transactions running too long and not having the ressources will just get halted and rolled back. That is inherently connected to having participants pay for transactions. Hence, having a native cryptocurrency as part of a blockchain seems to offer a good mechanism to block such attacks.

Is the implicit assumption here that enterprise permissioned blockchains have a lesser risk of such intruders and hence, if we establish identity of blockchain participants and have auditors over the network, we would get on top of such intruders anyways ?

2nd remark: Trusted Ledger: Identity Management & Consensus Mechanism:

The OBC you suggests offers participants to plug in their own consenus mechanism. It seems one could even use the OBC architecture without a consensus mechanism:https://github.com/openblockchain/obc-docs/blob/master/FAQ/consensus_FAQ.md

In that case it might be (see 1st remark) the implicit assumption is we establish identity of participants in blockchains to restrict access and audit members and with ensuring this, we have eventually only trusted members (we dont let others in or remove them) in the network. The need for 'unbreakable' consensus mechanisms like bitcoin proof of work for a permissionless network (everyone can plugin) might become lesser of a concern.

One might think Identity Management introduces a notion of centralization (you also address this point here: https://github.com/openblockchain/obc-docs/blob/master/FAQ/identity_management_FAQ.md) into a blockchain. But for enterprise transactions, having identity management is just indispensable.

My concern would however be to overstress Identity Management compared to consensus as the underlying mechanism to ensure we have trusted data in a shared ledger. Having Consensus optional and Identity Management mandatory might allow 'abuses' of the architecture as a simple 'inter - enterprise - B2B - platform'. Maybe it could be useful to default a minimal consensus mechanism and give (minimal) criteria to replace the default consensus mechanism you suggest. Having a consensus mechanism enforced, it could also be useful having a lightweight or no-identity management option as part of the OBC for 'bitcoin like' usecases, where participants might not want to reveal their identity.

A Suggestion for Data Privacy on (permissioned) Blockchains

Placing certain data on a shared ledger will be a hard sell too many, who dont sleep well over hearing concepts like 'distrubuted shared ledger' and 'health and financial data' in one sentence. It will be difficult to overcome such concerns with a treatise on the strength of cryptography and frankly, there are ongoing discussions how secure crypto is and will be with more (quantum) computing power in the future.

A pragmatic solution could be placing 'really sensitive data' outside the blockchain, link the data and keep only e.g. a (partial) fingerprint on the blockchain. You mention someting similar in a different context and purpose for files.

https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md (section Architecture / Blockchain) : Large files (documents, etc.) are stored in off-chain storage, not on the Ledger. Their hashes can be stored on-chain as part of the transactions, which is required to maintain the integrity of files

This could be a general and optional feature: One should be able choosing to have 'really sensitive' data in a permissioned database in one's regular enterprise network. The Blockchain transaction (cryptograhically secured) would contain:

A Link / Url / security tokens (indicating whoever knows this, was 'inside' that blockchain transaction) that allow access to several external System, typically within the enterprise network of participants of the transaction. These networks would use whatever authentication and security regulation authorities and enterprises deem necessary and revoke them when this might seem appropriate.
A 'as good as possible proof' of the contents linked data. This is obviously vague, the idea is that the data is not readable (it's at best partially there) on the blockchain, even if cryptograhpy is 'broken'. Then however, if participants in a transaction have a disput over the content of a transaction, such a 'partial fingerprint' of the data on the blockchain can at least help ruling out 'offbeat' claims from transaction partcipants, which in reality have forged their local data copy.

This feature would represent a trade off between the need for privacy (at your own terms) and the traceability of transactions to settle disputes. One would give up some traceability of the contents of a transaction but gain privacy, in the sense that you control the sensitive data yourself with whatever mechanisms your enterprise (and not the blockchain) considers necessary. For some usecases, this might just be what is needed and integrating this as an optional feature in a enterprise blockchain could enable a number of interesting usecases.








---
regards groet gruss

benedikt herudek


!!!!!!!!!!!!!COPIED IN !!!!!!!!!!!!!!!


On 02/18/2016 05:31 PM, Christopher B Ferris via hyperledger-tsc wrote:
All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback.
https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402



_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--

*Fabian Schuh* / Business Developer, Technical Consultant
fabian@... <mailto:fabian@...>


CRYPTONOMEX, INC.

2020 Kraft Dr Suite 3040
Blacksburg, VA 24060
www.cryptonomex.com <https://www.cryptonomex.com>

<https://www.linkedin.com/company/cryptonomex-inc->
<https://github.com/cryptonomex> <https://twitter.com/cryptonomex>
<https://www.facebook.com/cryptonomex>

Cryptonomex is a leading supplier of advanced block chain technology.
That can range from simple advice, to deployment of your application
on one of our public block chains, to creating your own private chain

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--

*Fabian Schuh* / Business Developer, Technical Consultant
fabian@... <mailto:fabian@...>


CRYPTONOMEX, INC.

2020 Kraft Dr Suite 3040
Blacksburg, VA 24060
www.cryptonomex.com <https://www.cryptonomex.com>

<https://www.linkedin.com/company/cryptonomex-inc-> <https://github.com/cryptonomex> <https://twitter.com/cryptonomex> <https://www.facebook.com/cryptonomex>

Cryptonomex is a leading supplier of advanced block chain technology. That can range from simple advice, to deployment of your application on one of our public block chains, to creating your own private chain

benedikt herudek <benedikt.herudek@...>
  

Hi Fabian,

I would hope for an architecture where a blockchain stores more than letters of intent but implements somewhat more binding and automated smart contracts. 

Agree with the necessity of Identity Management and scalability.

Copied in my points below (to have on thread):  
1. would see the need of a strong obligatory consensus mechanismus, it seems optional in OBC. 
2.An  open question to me seems how you want to block malicious code (turing halting problem), if you don't introduce a digitcal currency and hence allow something like the notion of gas in ethereum to stop too long running transactions.

regards

benedikt

---
regards groet gruss

benedikt herudek

On 23.02.2016 10:29, Fabian Schuh via hyperledger-tsc wrote:
> This is an excellent paper to get a rough idea and it is well written. Good job.
> 
> We at Cryptonomex have though about some parts of your design already and agree on most of them:
> 
> * There is a need for an identity management on top of a blockchain. For that reasons, you would like to have customers register an account name (together with public keys)on the blockchain and authenticate  every transaction with on of your accounts
>

* The blockchain mere purpose is to store "letters of intent" from users (e.g. instructions) and they could be anything from "transfers" to sell orders for decentralized order books. > > Now comes the "issue": If you want these instructions to be "executed" as a part of your blockchain protocol (you call them chaincode) such that the blockchain as a database transits into a new "state", then you need to take quite some care about scalability and speed as every instruction has to be executed on every full node if you want to have a trustless system. > > Two strategies exist out of this misery: > a) not every node on your network validates every instruction but only > a set of elected validators do and > they validate each other. > b) you don't execute any instruction at all and let the end users (or > intermediate service) determine the > actual state of the whole (or a part) of the blockchain database. > (We have this implemented already and > call this technology "Plasma" internally). > > Anyway, seeing how you would like this technology to evolve and knowing that we already have parts of it implemented, maybe we should consider a closer partnership between IBM and Cryptonomex. > > Best regards > -- Fabian !!!!!!!!!!!!!! COPIED IN !!!!!!!!!! -------- Original Message -------- Subject: Re: [Hyperledger Project TSC] IBM whitepaper Date: 20.02.2016 16:15 From: benedikt herudek <benedikt.herudek@...> To: hyperledger-tsc@... Hi Chris, excellent paper ! Below two remarks / questions around Identity Management vs Consensus and one suggestion concerning data privacy on permissioned blockchains. Interested in anyone's view. regards benedikt 1st remark: Chain Language, Turing halting problem & native currency: Understand, you don't introduce a native OBC currency. It seems you might introduce a native OBC language in the future. But at the moment, you support existing languages like go. https://github.com/openblockchain/obc-docs/blob/master/FAQ/chaincode_FAQ.md Without a native currency, but with a full turing complete language, how will you address someone introducing mailicious code running through endless loops and eating up ressources ? Ethereum wants to address this with the notion of gas, so transactions running too long and not having the ressources will just get halted and rolled back. That is inherently connected to having participants pay for transactions. Hence, having a native cryptocurrency as part of a blockchain seems to offer a good mechanism to block such attacks. Is the implicit assumption here that enterprise permissioned blockchains have a lesser risk of such intruders and hence, if we establish identity of blockchain participants and have auditors over the network, we would get on top of such intruders anyways ? 2nd remark: Trusted Ledger: Identity Management & Consensus Mechanism: The OBC you suggests offers participants to plug in their own consenus mechanism. It seems one could even use the OBC architecture without a consensus mechanism:https://github.com/openblockchain/obc-docs/blob/master/FAQ/consensus_FAQ.md In that case it might be (see 1st remark) the implicit assumption is we establish identity of participants in blockchains to restrict access and audit members and with ensuring this, we have eventually only trusted members (we dont let others in or remove them) in the network. The need for 'unbreakable' consensus mechanisms like bitcoin proof of work for a permissionless network (everyone can plugin) might become lesser of a concern. One might think Identity Management introduces a notion of centralization (you also address this point here: https://github.com/openblockchain/obc-docs/blob/master/FAQ/identity_management_FAQ.md) into a blockchain. But for enterprise transactions, having identity management is just indispensable. My concern would however be to overstress Identity Management compared to consensus as the underlying mechanism to ensure we have trusted data in a shared ledger. Having Consensus optional and Identity Management mandatory might allow 'abuses' of the architecture as a simple 'inter - enterprise - B2B - platform'. Maybe it could be useful to default a minimal consensus mechanism and give (minimal) criteria to replace the default consensus mechanism you suggest. Having a consensus mechanism enforced, it could also be useful having a lightweight or no-identity management option as part of the OBC for 'bitcoin like' usecases, where participants might not want to reveal their identity. A Suggestion for Data Privacy on (permissioned) Blockchains Placing certain data on a shared ledger will be a hard sell too many, who dont sleep well over hearing concepts like 'distrubuted shared ledger' and 'health and financial data' in one sentence. It will be difficult to overcome such concerns with a treatise on the strength of cryptography and frankly, there are ongoing discussions how secure crypto is and will be with more (quantum) computing power in the future. A pragmatic solution could be placing 'really sensitive data' outside the blockchain, link the data and keep only e.g. a (partial) fingerprint on the blockchain. You mention someting similar in a different context and purpose for files. https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md (section Architecture / Blockchain) : Large files (documents, etc.) are stored in off-chain storage, not on the Ledger. Their hashes can be stored on-chain as part of the transactions, which is required to maintain the integrity of files This could be a general and optional feature: One should be able choosing to have 'really sensitive' data in a permissioned database in one's regular enterprise network. The Blockchain transaction (cryptograhically secured) would contain: A Link / Url / security tokens (indicating whoever knows this, was 'inside' that blockchain transaction) that allow access to several external System, typically within the enterprise network of participants of the transaction. These networks would use whatever authentication and security regulation authorities and enterprises deem necessary and revoke them when this might seem appropriate. A 'as good as possible proof' of the contents linked data. This is obviously vague, the idea is that the data is not readable (it's at best partially there) on the blockchain, even if cryptograhpy is 'broken'. Then however, if participants in a transaction have a disput over the content of a transaction, such a 'partial fingerprint' of the data on the blockchain can at least help ruling out 'offbeat' claims from transaction partcipants, which in reality have forged their local data copy. This feature would represent a trade off between the need for privacy (at your own terms) and the traceability of transactions to settle disputes. One would give up some traceability of the contents of a transaction but gain privacy, in the sense that you control the sensitive data yourself with whatever mechanisms your enterprise (and not the blockchain) considers necessary. For some usecases, this might just be what is needed and integrating this as an optional feature in a enterprise blockchain could enable a number of interesting usecases. --- regards groet gruss benedikt herudek !!!!!!!!!!!!!COPIED IN !!!!!!!!!!!!!!! > > On 02/18/2016 05:31 PM, Christopher B Ferris via hyperledger-tsc wrote: >> All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback. >> https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md >> Cheers, >> >> Christopher Ferris >> IBM Distinguished Engineer, CTO Open Technology >> IBM Cloud, Open Technologies >> email: chrisfer@... >> twitter: @christo4ferris >> blog: https://developer.ibm.com/opentech/author/chrisfer/ >> phone: +1 508 667 0402 >> >> >> >> _______________________________________________ >> hyperledger-tsc mailing list >> hyperledger-tsc@... >> https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc > > -- > > *Fabian Schuh* / Business Developer, Technical Consultant > fabian@... <mailto:fabian@...> > > > CRYPTONOMEX, INC. > > 2020 Kraft Dr Suite 3040 > Blacksburg, VA 24060 > www.cryptonomex.com <https://www.cryptonomex.com> > > <https://www.linkedin.com/company/cryptonomex-inc-> > <https://github.com/cryptonomex> <https://twitter.com/cryptonomex> > <https://www.facebook.com/cryptonomex> > > Cryptonomex is a leading supplier of advanced block chain technology. > That can range from simple advice, to deployment of your application > on one of our public block chains, to creating your own private chain > > _______________________________________________ > hyperledger-tsc mailing list > hyperledger-tsc@... > https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

Fabian Schuh <fabian@...>
 

This is an excellent paper to get a rough idea and it is well written. Good job.

We at Cryptonomex have though about some parts of your design already and agree on most of them:

* There is a need for an identity management on top of a blockchain. For that reasons, you would like to
have customers register an account name (together with public keys) on the blockchain and authenticate
every transaction with on of your accounts
* The blockchain mere purpose is to store "letters of intent" from users (e.g. instructions) and they could
be anything from "transfers" to sell orders for decentralized order books.

Now comes the "issue": If you want these instructions to be "executed" as a part of your blockchain protocol
(you call them chaincode) such that the blockchain as a database transits into a new "state", then you need
to take quite some care about scalability and speed as every instruction has to be executed on every full node
if you want to have a trustless system.

Two strategies exist out of this misery:
a) not every node on your network validates every instruction but only a set of elected validators do and
they validate each other.
b) you don't execute any instruction at all and let the end users (or intermediate service) determine the
actual state of the whole (or a part) of the blockchain database. (We have this implemented already and
call this technology "Plasma" internally).

Anyway, seeing how you would like this technology to evolve and knowing that we already have parts of it
implemented, maybe we should consider a closer partnership between IBM and Cryptonomex.

Best regards
-- Fabian

On 02/18/2016 05:31 PM, Christopher B Ferris via hyperledger-tsc wrote:
All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback.
https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402



_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
--

*Fabian Schuh* / Business Developer, Technical Consultant
fabian@... <mailto:fabian@...>


CRYPTONOMEX, INC.

2020 Kraft Dr Suite 3040
Blacksburg, VA 24060
www.cryptonomex.com <https://www.cryptonomex.com>

<https://www.linkedin.com/company/cryptonomex-inc-> <https://github.com/cryptonomex> <https://twitter.com/cryptonomex> <https://www.facebook.com/cryptonomex>

Cryptonomex is a leading supplier of advanced block chain technology. That can range from simple advice, to deployment of your application on one of our public block chains, to creating your own private chain

benedikt herudek <benedikt.herudek@...>
 

Hi Chris,

excellent paper !

Below two remarks / questions around Identity Management vs Consensus and one suggestion concerning data privacy on permissioned blockchains.

Interested in anyone's view.

regards

benedikt


1st remark: Chain Language, Turing halting problem & native currency:

Understand, you don't introduce a native OBC currency. It seems you might introduce a native OBC language in the future. But at the moment, you support existing languages like go. https://github.com/openblockchain/obc-docs/blob/master/FAQ/chaincode_FAQ.md

Without a native currency, but with a full turing complete language, how will you address someone introducing mailicious code running through endless loops and eating up ressources ? Ethereum wants to address this with the notion of gas, so transactions running too long and not having the ressources will just get halted and rolled back. That is inherently connected to having participants pay for transactions. Hence, having a native cryptocurrency as part of a blockchain seems to offer a good mechanism to block such attacks.

Is the implicit assumption here that enterprise permissioned blockchains have a lesser risk of such intruders and hence, if we establish identity of blockchain participants and have auditors over the network, we would get on top of such intruders anyways ?

2nd remark: Trusted Ledger: Identity Management & Consensus Mechanism:

The OBC you suggests offers participants to plug in their own consenus mechanism. It seems one could even use the OBC architecture without a consensus mechanism:https://github.com/openblockchain/obc-docs/blob/master/FAQ/consensus_FAQ.md

In that case it might be (see 1st remark) the implicit assumption is we establish identity of participants in blockchains to restrict access and audit members and with ensuring this, we have eventually only trusted members (we dont let others in or remove them) in the network. The need for 'unbreakable' consensus mechanisms like bitcoin proof of work for a permissionless network (everyone can plugin) might become lesser of a concern.

One might think Identity Management introduces a notion of centralization (you also address this point here: https://github.com/openblockchain/obc-docs/blob/master/FAQ/identity_management_FAQ.md) into a blockchain. But for enterprise transactions, having identity management is just indispensable.

My concern would however be to overstress Identity Management compared to consensus as the underlying mechanism to ensure we have trusted data in a shared ledger. Having Consensus optional and Identity Management mandatory might allow 'abuses' of the architecture as a simple 'inter - enterprise - B2B - platform'. Maybe it could be useful to default a minimal consensus mechanism and give (minimal) criteria to replace the default consensus mechanism you suggest. Having a consensus mechanism enforced, it could also be useful having a lightweight or no-identity management option as part of the OBC for 'bitcoin like' usecases, where participants might not want to reveal their identity.

A Suggestion for Data Privacy on (permissioned) Blockchains

Placing certain data on a shared ledger will be a hard sell too many, who dont sleep well over hearing concepts like 'distrubuted shared ledger' and 'health and financial data' in one sentence. It will be difficult to overcome such concerns with a treatise on the strength of cryptography and frankly, there are ongoing discussions how secure crypto is and will be with more (quantum) computing power in the future.

A pragmatic solution could be placing 'really sensitive data' outside the blockchain, link the data and keep only e.g. a (partial) fingerprint  on the blockchain. You mention someting similar in a different context and purpose for files.

https://github.com/openblockchain/obc-docs/blob/master/whitepaper.md (section Architecture / Blockchain) : Large files (documents, etc.) are stored in off-chain storage, not on the Ledger. Their hashes can be stored on-chain as part of the transactions, which is required to maintain the integrity of files

This could be a general and optional feature: One should be able choosing to have 'really sensitive' data in a permissioned database in one's regular enterprise network. The Blockchain transaction (cryptograhically secured) would contain:
  1. A Link / Url / security tokens (indicating whoever knows this, was 'inside' that blockchain transaction) that allow access to several external System, typically within the enterprise network of participants of the transaction. These networks would use whatever authentication and security regulation authorities and enterprises deem necessary and revoke them when this might seem appropriate.
  2. A 'as good as possible proof' of the contents linked data. This is obviously vague, the idea is that the data is not readable (it's at best partially there) on the blockchain, even if cryptograhpy is 'broken'. Then however, if participants in a transaction have a disput over the content of a transaction, such a 'partial fingerprint' of the data on the blockchain can at least help ruling out 'offbeat' claims from transaction partcipants, which in reality have forged their local data copy.
This feature would represent a trade off between the need for privacy (at your own terms) and the traceability of transactions to settle disputes. One would give up some traceability of the contents of a transaction but gain privacy, in the sense that you control the sensitive data yourself with whatever mechanisms your enterprise (and not the blockchain) considers necessary. For some usecases, this might just be what is needed and integrating this as an optional feature in a enterprise blockchain could enable a number of interesting usecases. 








---
regards groet gruss

benedikt herudek

On 18.02.2016 18:55, Duc Trinh via hyperledger-tsc wrote:

Chris,

This is a very well thought-out paper!  Two very minor suggested mods for clarity:

 

"As the shared ledger concept gains tracking traction in the business world, blockchain's added feature – smart contract – is also getting a lot of attention from the industry."

 

"We believe that one of the fundamental requirements for any blockchain fabric is that the identity and patterns of behavior of any party on a network must be impossible can be protected from unauthorized parties to ascertain by inspecting the ledger."

 

Cheers,

Duc

 

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Christopher B Ferris via hyperledger-tsc
Sent: Thursday, February 18, 2016 10:32 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] IBM whitepaper

 

All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback.

 

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 


_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc

Christopher B Ferris <chrisfer@...>
 

Thanks!
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402
 
 

----- Original message -----
From: Duc Trinh via hyperledger-tsc <hyperledger-tsc@...>
Sent by: hyperledger-tsc-bounces@...
To: <hyperledger-tsc@...>
Cc:
Subject: Re: [Hyperledger Project TSC] IBM whitepaper
Date: Thu, Feb 18, 2016 12:55 PM
 

Chris,

This is a very well thought-out paper!  Two very minor suggested mods for clarity:

 

“As the shared ledger concept gains tracking traction in the business world, blockchain’s added feature – smart contract – is also getting a lot of attention from the industry.”

 

“We believe that one of the fundamental requirements for any blockchain fabric is that the identity and patterns of behavior of any party on a network must be impossible can be protected from unauthorized parties to ascertain by inspecting the ledger.”

 

Cheers,

Duc

 

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Christopher B Ferris via hyperledger-tsc
Sent: Thursday, February 18, 2016 10:32 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] IBM whitepaper

 

All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback.

 

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc
 

Duc.M.Trinh@...
 

Chris,

This is a very well thought-out paper!  Two very minor suggested mods for clarity:

 

“As the shared ledger concept gains tracking traction in the business world, blockchain’s added feature – smart contract – is also getting a lot of attention from the industry.”

 

“We believe that one of the fundamental requirements for any blockchain fabric is that the identity and patterns of behavior of any party on a network must be impossible can be protected from unauthorized parties to ascertain by inspecting the ledger.”

 

Cheers,

Duc

 

 

From: hyperledger-tsc-bounces@... [mailto:hyperledger-tsc-bounces@...] On Behalf Of Christopher B Ferris via hyperledger-tsc
Sent: Thursday, February 18, 2016 10:32 AM
To: hyperledger-tsc@...
Subject: [Hyperledger Project TSC] IBM whitepaper

 

All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback.

 

 

Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

 

Christopher B Ferris <chrisfer@...>
 

All, as we discussed on the TSC call, here's a link to the IBM blockchain whitepaper that we published with the open blockchain repos earlier this week. We welcome any and all feedback.
 
 
Cheers,

Christopher Ferris
IBM Distinguished Engineer, CTO Open Technology
IBM Cloud, Open Technologies
email: chrisfer@...
twitter: @christo4ferris
blog: https://developer.ibm.com/opentech/author/chrisfer/
phone: +1 508 667 0402

1 - 13 of 13