The "balance transfer" example demonstrate use of JSON webtoken, you can download the samples from http://hyperledger-fabric.readthedocs.io/en/release-1.1/samples.html

To correct my previous reply - Dave reminded me of what we wanted to achieve here and the purpose of passing the block in this function at the first place. So, this is a bug and thanks Dave for

Some thoughts ... Blockchain sub-networks get attached to larger business networks, which themselves probably include an IoT sub-network (brokers, devices, gateways, and such) and are interconnected

Somehow, hit the ‘reply’ instead of reply all... ---------- Forwarded message ---------- From: Manish Sethi <manish.sethi@...> Date: Wed, May 16, 2018 at 11:56 AM Subject: Re: [Hyperledger Fabric]

Only users from the orderer organization is authorized to read from the orderer system channel. Be sure that you have configured your CORE_PEER_LOCALMSPID to be "OrdererOrg" and

any chance of also getting a tcpdump logon both ends (peer and orderer) ? :) From: "Yash" <yashgt@...> To: Gari Singh <garis@...> Cc:

Hi Gari, I have attached the log that shows messages from the deliveryClient module in peer. It shows that after every 15 min, the connection is terminated by the Peer and a reattempt is made. This

recently, i asked if there was any rationale for, rather than creating another channel within an existing fabric network, just creating an entirely new network, whereupon christopher ferris replied:

Hi Yash - gRPC keepalives should work with nghttpx (we've used it in the past as a reverse proxy as well). Can you share your settings (keep alive settings for the peer as well as the various

Hello Guys, I want to use passport-jwt as part of authentication for composer rest api. I followed https://github.com/hyperledger/composer/issues/2038#issuecomment-340540726 and do the same thing

Hi, The Peer to Orderer connection needs to be kept alive so that whenever there are new transactions, the orderer can send them to the peer for committing. The Peer already uses a TCP keepAlive to

func (s *idStore) createLedgerID(ledgerID string, gb *common.Block) error { key := s.encodeLedgerKey(ledgerID) var val []byte var err error if val, err = proto.Marshal(gb); err != nil { return

Hi Baohua, thank you for the link. Maybe, kafka is good at detecting crash failure while bft is good at detecting malicous failure. best regards, qs meng 在 2018-05-15 21:06:23，"Baohua Yang"

Hello team, I am trying to create a Hyperledger fabric environment with Multiple organizations across multiple VM's. I took hyperledger/fabric-sample/first-network as reference and separated

Hello Vineet, Thanks a lot for the reply, but is it mandatory to give 7051 as listen port for peer and if yes then why. Because if I try using any port apart from 7051 I can’t connect to that

Hi, I am somewhat confused as to the state of Java Chaincode. Is there any way to write Java Smart Contracts at the moment? Or is Java currently disabled? Thanks, js

Hi Dmitriy, thanks for the link to StackOverflow. @AdnanC is doing couchDB scalability and performance work and does see similar symptoms. He communicates on the fabric-quality channel.. Thanks,

This is Fabric's standard mode of operation. One ordering network (or in the case of 'Solo', one orderer) may serve an arbitrary number of channels, created dynamically over time. For an

qs Here might give some explanation. https://www.quora.com/What-is-the-difference-between-Crash-Faults-and-Byzantine-Faults Besides, the maillist has removed all "hyperledger-" prefix, hence we can

Depends how you provisioned the network, but basically, if you want a fresh start, re-create the network. Chris