Martin A transaction that uses collections leaks information about the involved parties in 3 ways: 1) the creator; 2) the collection name and 3) endorsements. Point 1 can be addressed by using idemix.

#fabric

You must consider adversarial behaviour: if an adversary may compromise a peer, and that peer is sufficient to produce a valid endorsement for a chaincode, then the adversary can bypass the chaincode

Hi The issue is being addressed by the new lifecycle work: a preview of this work has been showed in the 2.0 alpha release and the feature is scheduled for release in the 2.0 version in the upcoming m

The limitation is intrinsic to the old lifecycle, that only supports so-called "dictatorial" networks, where chaincode metadata (incl. the endorsement policy) is chosen by a single org in the system.

Cathy This is one of the reasons behind the work we've put into the new chaincode lifecycle. We have released a preview of it in the 2.0 alpha version https://hyperledger-fabric.readthedocs.io/en/late

Igor Thanks for reporting this bug - may I ask you to pls create a JIRA bug describing the issue, adding logs and steps to reproduce, and I'll look into it asap. Thx! Ale

#fabric

qs meng The paper describes fabcoin, which was just created as a benchmarking instrument for fabric. At a high level, the two approaches are not dissimilar, since they both follow a UTXO paradigm. The

Hi Guillaume Let me draw your attention to the fact that the 2.0 release is going away from the LSCC-based chaincode lifecycle towards a new, more secure (and hopefully usable) lifecycle -- see the re

#fabric #fabric-questions

Nik Have you looked at https://hyperledger-fabric.readthedocs.io/en/release-1.4/operations_service.html ? Hope it helps. Cheers, Ale

#fabric-questions

Hi The scenario you describe works as expected: a chaincode invocation doesn't actually write to the ledger; instead, the proposed ledger changes are captured in the "read-write set" artefact. The rea

Hi Vignesh You may also want to encrypt the query result, in the same way in which your chaincode encrypts state updates. You would obviously have to add a round of decryption in your client applicati

<fabric> <fabric-ca> <thirdparty> are only placeholders, which you are supposed to replace. So instead of executing curl -sSL http://bit.ly/2ysbOFE | bash -s <fabric> <fabric-ca> <thirdparty> you have

Don Thanks for reporting this issue. May I ask you to try the following: remove all your docker images, remove fabric-samples if you have it and just run the bootstrap.sh script curl -sSL http://bit.l

The short answer is that there is no security control enabled by default that ensures that ordering nodes do not inspect the content of transactions they order. As part of your risk assessment you'll

No need for so much red tape: all you really need for the playback session is to prepare to give a ~30' presentation (with some slide support). You can create a draft JIRA with a short description of

Personally I'd like to learn more about this project: have you considered a playback (https://wiki.hyperledger.org/projects/fabric/playbacks) to let the community know more about it and start a discus

As I said, an endorsement policy requiring the signature of an MSP principal with the attributes "client" or "admin" would have little meaning and would not be satisfiable in practice. Cheers, Ale

Sunil You are right to highlight the fact that an endorsement policy requiring the signature of a client would have little meaning in most cases. Still - MSP principals are used in fabric to formulate

Don Have you looked into the token management work that's ongoing and targeted for 2.0? Here's the design doc https://docs.google.com/document/d/1fzxoQYARFPTTIM-eIw8zs6tYkg6t6uRVI6fmnCQJz9I/edit and h

Hi Jonathan Correct Oh yes, let me correct my statement: have as many peers *from the owning organisation* as possible listen for events and perform the upload/update. Cheers, Ale

#fabric #database