Dave, Yacov, and Alex Seems that the general response to this scenario is “this is an application design problem and should be solved by chaincode” But my argument here is that chaincode design

Sorry, I misunderstood the question, giving wrong response.

Hi, This is a tricky thing. I had the same issue and it took me a while to figure out the issue. This is definitely not mandatory to provide the root certificate and the private key to the CA because

That is what I was also thinking but did not know for sure as well. But when I read your previous post stating:I admit I had hope ;)

Hi All, I am using Fabric-CA to generate enrollment and TLS certificates. I am using below command to start the Fabric-CA: fabric-ca-server start -b admin:adminpw --port 7054 I am not providing any

I am not 100% sure. But I think configtxgen cannot be replaced, with sdk.

Setting V1_4_3 capability to true implicitly sets the prior capabilities to true as well. You can leave as-is. I've pushed a clarification to the file as well:

according to this link: https://hyperledger-fabric.readthedocs.io/en/release-1.4/msp.html but when i look at https://github.com/hyperledger/fabric-samples/blob/release-1.4/first-network/configtx.yaml

Your second point is not specific to private data. Agreement on input data needs to be part of the application design, regardless of whether it is a private data scenario or not. For example the smart

Hi Alexandre, Yacov Thanks for your reply and I appreciate the discussion. my hands are tight now so I will give my full response later today: Yes, my point is private data design maybe flawed in two

Hey Ivan, Correct me if I'm wrong, but it seems you are thinking that the private data as implemented is flawed, and that the requirement to salt the data to secure it defeats the purpose of having

Without setting NodeOU, fabric only support classification of admin and member role. Please correct me if anyone think I am wrong. Best Regards, David Liu 发件人: Nicholas Zanutim

Thanks man, I got it to work. What I changed was the orgs policies rule from admin, peer and client to member "OR('ExampleMSP.member')" Writers: Type: Signature

I guess you could carefully compare your entire configtx.yaml withhttps://github.com/hyperledger/fabric/blob/release-1.4/sampleconfig/configtx.yaml Another possibility is there is legacy crypto

Hey guys, I'm having trouble invoking a transaction on a network and getting an error that I can't find anyone else having. got query for channel channel from 192.168.6.33:33132 but it isn't eligible:

I know the cryptogen tool is not needed. I was just making a comparison between the two of them because I found the way to get rid of cryptogen but not configtxgen. Do you have an example or a link

CA SDK can mostly replace cryptogen, except the CA admin registration. The creation of genesis block can be done by SDK, along with the use of Fabric CA. No need for cryptogen tool at all.

Range queries use a variant of a sorted B-tree and the underlying data files will be in system cache, therefore it will be extremely performant to get the lowest/highest key in a range. Dave

there are all kinds of auction types....English auction, Dutch auction, etc. - you need first to specify exactlythe use case and only afterwards ask how you do it with Fabric From: "Mr.Phuwanai

Hi everyone, I am Suzana Joel from IBC Media. Currently, we’re organizing Genesis DevCon - a blockchain developer conference on 24th & 25th of November at IISc in Bengaluru. The objective of genesis