"validateCommonHeader returns err invalid nonce specified in the header" after entering "peer channel join -b channel47.block"

[punkq]

• I followed the steps of QUICK START and built a HFL network based on docker images. Everything seemed fine until I entered peer channel join -b channel47.block at the bft.cli.0 terminal. The client terminal didn't return any errors while the bft.peer.0 terminal output this:

2018-08-28 22:22:44.568 UTC [protoutils] ValidateTransaction -> ERRO 049 validateCommonHeader returns err invalid nonce specified in the header 2018-08-28 22:22:44.568 UTC [committer/txvalidator] validateTx -> ERRO 04a Invalid transaction with index 0

I tried both swarm overlay network and bridge network, but the same error still exists.

• However, when I installed and instantiate chaincode and issued invocations and queries at bft.cli.0, evething goes well. After that, I enter the same command peer channel join -b channel47.block at bft.cli.1, The bft.peer.1 terminal output this:

2018-08-28 22:53:44.159 UTC [ccprovider] ExtractStatedbArtifactsForChaincode -> INFO 03c Error while loading installation package for ccname=%s, ccversion=%s. Err=%s example02 1.0 open /var/hyperledger/production/chaincodes/example02.1.0: no such file or directory

• To some extent, the blockchain can grow while invalid transcation will not be recorded. The log of throughput and latency remains empty. Would you mind give me some suggestion about avoiding problems like this?

[jcs47]

Greetings. This happens because the peer is trying to validate the signature of configuration envelopes created by the ordering nodes, but such signature is not included. This is due to the fact that the envelope structure is generated at correct ordering nodes, but since the structure only supports a single signature, they cannot be included.

However, since this verification is done for audit purposes and the blocks are still correctly signed, they are still appended to the chain. Moreover, this scenario only occurs for reconfiguration transactions, since the ordering nodes need to create a new configuration tree, as well as generate a new envelope containing the updated tree. Since regular transactions do not require the ordering nodes to create their own envelopes, this error does not occur for regular transactions.

Finally, if you want to prevent this error from occurring and are using the version for Fabric v1.2, you can use our own peer image available at bftsmart/fabric-peer:amd64-1.2.0, which avoids performing signature verification for configuration envelopes.