Date   

Re: upgrade not working

Park, Jungil
 

Hi Team,

 

Can anyone help with this?

Does anyone experience a similar issue like this?

 

Met vriendelijke groet / Kind regards

Jungil Park

ABN AMRO | ABN AMRO CLEARING

Gustav Mahlerlaan 10 | 1082 PP Amsterdam | The Netherlands
Mob +31 (0)6 14667692
Email jungil.park@...
Internet
www.abnamro.com
Save a tree! Print this message only if it's absolutely necessary

 

From: jungil.park@... <jungil.park@...>
Sent: 30 March 2020 14:09
To: 'enyeart@...' <enyeart@...>; 'fabric@...' <fabric@...>
Subject: [External] [Hyperledger Fabric] upgrade not working

 

 

 

Hi Team,

 

I am using 1.4.0 with couchdb and tried to upgrade to 2.0.

I use the following commands.

 

1.               command

docker run --rm -v /opt/hyperledger/production/peer0org1:/var/hyperledger/production/ \

            -v /opt/hfabric.v1x/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp/ \

            --name peer0.org1.example.com \

            --env CORE_LEDGER_STATE_STATEDATABASE=CouchDB  \

            hyperledger/fabric-peer:2.0 peer node upgrade-dbs

2.               ouput

 

2020-03-30 11:29:56.778 UTC [kvledger] UpgradeDBs -> INFO 001 Ledger data folder from config = [/var/hyperledger/production/ledgersData]

2020-03-30 11:29:56.783 UTC [kvledger] dropStateLevelDB -> INFO 002 Dropping StateLevelDB at location [/var/hyperledger/production/ledgersData/stateLeveldb] ...if present

2020-03-30 11:29:56.783 UTC [kvledger] dropConfigHistoryDB -> INFO 003 Dropping ConfigHistoryDB at location [/var/hyperledger/production/ledgersData/configHistory]

2020-03-30 11:29:56.784 UTC [kvledger] dropBookkeeperDB -> INFO 004 Dropping BookkeeperDB at location [/var/hyperledger/production/ledgersData/bookkeeper]

2020-03-30 11:29:56.784 UTC [kvledger] dropHistoryDB -> INFO 005 Dropping HistoryDB at location [/var/hyperledger/production/ledgersData/historyLeveldb] ...if present

2020-03-30 11:29:56.784 UTC [fsblkstorage] DeleteBlockStoreIndex -> INFO 006 Dropping the index dir [/var/hyperledger/production/ledgersData/chains/index]... if present

 

 

 

 

3.               second command

docker run --rm -v /opt/hyperledger/production/peer0org1:/var/hyperledger/production/ \

            -v /opt/hfabric.v1x/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp/ \

            --name peer0.org1.example.com \

            hyperledger/fabric-peer:2.0 peer node start

 

 

 

4.               ouput :

5.  2020-03-30 09:00:24.383 UTC [nodeCmd] serve -> INFO 001 Starting peer:

6.   Version: 2.0.0

7.   Commit SHA: 0432c3e

8.   Go version: go1.13.4

9.   OS/Arch: linux/amd64

10.  Chaincode:

11.   Base Docker Namespace: hyperledger

12.   Base Docker Label: org.hyperledger.fabric

13.   Docker Namespace: hyperledger

14. 2020-03-30 09:00:24.384 UTC [peer] getLocalAddress -> INFO 002 Auto-detected peer address: 172.17.0.2:7051

15. 2020-03-30 09:00:24.384 UTC [peer] getLocalAddress -> INFO 003 Host is 0.0.0.0 , falling back to auto-detected address: 172.17.0.2:7051

16. 2020-03-30 09:00:24.414 UTC [gossip.service] New -> INFO 004 Initialize gossip with endpoint 172.17.0.2:7051

17. 2020-03-30 09:00:24.416 UTC [gossip.gossip] New -> INFO 005 Creating gossip service with self membership of Endpoint: , InternalEndpoint: 172.17.0.2:7051, PKI-ID: 65dfd2f8791c19aacad25b10a94d2db1219f7be324344483be4bdf8aee89bd3b, Metadata:

18. 2020-03-30 09:00:24.416 UTC [gossip.gossip] New -> WARN 006 External endpoint is empty, peer will not be accessible outside of its organization

19. 2020-03-30 09:00:24.416 UTC [gossip.gossip] start -> INFO 007 Gossip instance 172.17.0.2:7051 started

20. 2020-03-30 09:00:24.417 UTC [ledgermgmt] NewLedgerMgr -> INFO 008 Initializing LedgerMgr

21. 2020-03-30 09:00:24.456 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 009 DB is empty Setting db format as 2.0

22. 2020-03-30 09:00:24.483 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 00a DB is empty Setting db format as 2.0

23. 2020-03-30 09:00:24.484 UTC [ledgermgmt] NewLedgerMgr -> INFO 00b Initialized LedgerMgr

24. 2020-03-30 09:00:24.484 UTC [lifecycle] InitializeLocalChaincodes -> INFO 00c Initialized lifecycle cache with 0 already installed chaincodes

25. 2020-03-30 09:00:24.485 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00d Entering computeChaincodeEndpoint with peerHostname: 172.17.0.2

26. 2020-03-30 09:00:24.485 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00e Exit with ccEndpoint: 172.17.0.2:7052

27. 2020-03-30 09:00:24.485 UTC [nodeCmd] createChaincodeServer -> WARN 00f peer.chaincodeListenAddress is not set, using 172.17.0.2:7052

28. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 010 deploying system chaincode 'lscc'

29. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 011 deploying system chaincode 'cscc'

30. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 012 deploying system chaincode 'qscc'

31. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 013 deploying system chaincode '_lifecycle'

32. 2020-03-30 09:00:24.490 UTC [nodeCmd] serve -> INFO 014 Deployed system chaincodes

33. 2020-03-30 09:00:24.490 UTC [peer] Initialize -> INFO 015 Loading chain mychannel

34. 2020-03-30 09:00:24.490 UTC [ledgermgmt] OpenLedger -> INFO 016 Opening ledger with id = mychannel

35. 2020-03-30 09:00:24.491 UTC [fsblkstorage] newBlockfileMgr -> INFO 017 Getting block information from block storage

36. 2020-03-30 09:00:24.540 UTC [fsblkstorage] syncIndex -> INFO 018 Start building index from block [0] to last block [35356]

37. 2020-03-30 09:00:24.542 UTC [fsblkstorage] syncIndex -> INFO 019 Indexed block number [0]

38. 2020-03-30 09:00:35.837 UTC [fsblkstorage] syncIndex -> INFO 01a Indexed block number [10000]

39. 2020-03-30 09:00:47.392 UTC [fsblkstorage] syncIndex -> INFO 01b Indexed block number [20000]

40. 2020-03-30 09:01:00.008 UTC [fsblkstorage] syncIndex -> INFO 01c Indexed block number [30000]

41. 2020-03-30 09:01:06.764 UTC [fsblkstorage] syncIndex -> INFO 01d Finished building index. Last block indexed [35356]

42. 2020-03-30 09:01:06.764 UTC [kvledger] recommitLostBlocks -> INFO 01e Recommitting lost blocks - firstBlockNum=0, lastBlockNum=35356, recoverables=[]kvledger.recoverable{(*lockbasedtxmgr.LockBasedTxMgr)(0xc00021cfa0), (*history.DB)(0xc005fda980)}

43. 2020-03-30 09:01:06.765 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 01f Recommitting block [0] to state database

44. 2020-03-30 09:01:06.766 UTC [history] CommitLostBlock -> INFO 020 Recommitting block [0] to history database

45. 2020-03-30 09:01:06.772 UTC [cceventmgmt] HandleStateUpdates -> INFO 021 Channel [mychannel]: Handling deploy or update of chaincode [chaincode]

46. 2020-03-30 09:01:06.778 UTC [valimpl] preprocessProtoBlock -> WARN 022 Channel [mychannel]: Block [4] Transaction index [0] TxId [b5199e1b5d1f4522eca11680757652ae2882ebce5b66d4b534e5a5ccfcd3562d] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]

47. 2020-03-30 09:01:09.088 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 023 Recommitting block [1000] to state database

48. 2020-03-30 09:01:09.090 UTC [history] CommitLostBlock -> INFO 024 Recommitting block [1000] to history database

49. 2020-03-30 09:01:11.437 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 025 Recommitting block [2000] to state database

50. 2020-03-30 09:01:11.438 UTC [history] CommitLostBlock -> INFO 026 Recommitting block [2000] to history database

51. 2020-03-30 09:01:13.755 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 027 Recommitting block [3000] to state database

52. 2020-03-30 09:01:13.756 UTC [history] CommitLostBlock -> INFO 028 Recommitting block [3000] to history database

53. 2020-03-30 09:01:16.122 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 029 Recommitting block [4000] to state database

54. 2020-03-30 09:01:16.123 UTC [history] CommitLostBlock -> INFO 02a Recommitting block [4000] to history database

55. 2020-03-30 09:01:16.836 UTC [valimpl] preprocessProtoBlock -> WARN 02b Channel [mychannel]: Block [4297] Transaction index [2] TxId [8a17e87c38c6c8f99e59166695feae179cf5ca99494a6167fe23e7ff23c104e9] marked as invalid by committer. Reason code [MVCC_READ_CONFLICT]

56. 2020-03-30 09:01:16.836 UTC [valimpl] preprocessProtoBlock -> WARN 02c Channel [mychannel]: Block [4297] Transaction index [3] TxId [c78daa54b1c61f6c54d330af34649137d719374bf43a7a8189ae5d09dc1f31ad] marked as invalid by committer. Reason code [MVCC_READ_CONFLICT]

 

 

 

 

 

After this, still I got error below

 

2020-03-30 11:33:03.108 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 00a DB is empty Setting db format as 2.0

2020-03-30 11:33:03.195 UTC [kvledger] func1 -> ERRO 00b Please execute the 'peer node upgrade-dbs' command to upgrade the database format: unexpected format. db info = [CouchDB for state database], data format = [], expected format = [2.0]

2020-03-30 11:33:03.195 UTC [gossip.gossip] Stop -> INFO 00c Stopping gossip

2020-03-30 11:33:03.195 UTC [gossip.discovery] Stop -> INFO 00d Stopping

2020-03-30 11:33:03.195 UTC [gossip.discovery] Stop -> INFO 00e Stopped

2020-03-30 11:33:03.195 UTC [gossip.comm] Stop -> INFO 00f Stopping

2020-03-30 11:33:03.195 UTC [gossip.comm] Stop -> INFO 010 Stopped

panic: Error in instantiating ledger provider: unexpected format. db info = [CouchDB for state database], data format = [], expected format = [2.0]

goroutine 1 [running]:

 

 

 

 

Does anyone any idea what happen here?

 

 

Thanks,

Jungil.

 

 

 

 

 

This message has been sent by ABN AMRO Bank N.V., which has its seat at Gustav Mahlerlaan 10 (1082 PP) Amsterdam, the Netherlands, and is registered in the Commercial Register of Amsterdam under number 34334259.

This message has been sent by ABN AMRO Bank N.V., which has its seat at Gustav Mahlerlaan 10 (1082 PP) Amsterdam, the Netherlands, and is registered in the Commercial Register of Amsterdam under number 34334259.


Next Hyperledger Fabric Application Developer Community call (with revised agenda link) - this Thursday, 2nd April @ 3pm UTC time (4pm UK (+1), 11am ET (-5 hrs), 8am PT(-8 hrs)

Paul O'Mahoney <mahoney@...>
 


dear Fabric Application Developer,


the next  Fabric Application Developer community call is scheduled for this  Thursday 2nd April  @ 3pm UTC  - 4pm UK time (+1), 11am ET (-5 hrs), 8am PT(-8 hrs)  - see time zones here.   It lasts approx 30-60 mins FYI.

The agenda is  here -> https://wiki.hyperledger.org/display/fabric/Agendas%3A+Fabric+Application+Developer+Community+Call+Meetings  

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts,  developing application clients, using the SDKs, tutorials/demos etc -  NodeJS/TypeScript, Java, Go etc etc) 
- helping App developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric. 
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and 
- approx length of your pitch in minutes


The Zoom webconference ID is https://zoom.us/my/hyperledger.community   

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1

mahoney@...


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


Next Hyperledger Fabric Application Developer Community call - this Thursday, 2nd April @ 3pm UTC time (4pm UK (+1), 11am ET (-5 hrs), 8am PT(-8 hrs)

Paul O'Mahoney <mahoney@...>
 

dear Fabric Application Developer,


the next  Fabric Application Developer community call is scheduled for this  Thursday 2nd April  @ 3pm UTC  - 4pm UK time (+1), 11am ET (-5 hrs), 8am PT(-8 hrs)  - see time zones here.   It lasts approx 30-60 mins FYI.

The agenda will be posted here -> https://wiki.hyperledger.org/display/fabric/Meeting+Agendas%3A+Fabric+Application+Developer+Community+Call

This community call is held bi-weekly via Zoom webconference and is aimed at :

- helping the worldwide Hyperledger Fabric Application Developer community grow (eg. developing applications, smart contracts,  developing application clients, using the SDKs, tutorials/demos etc -  NodeJS/TypeScript, Java, Go etc etc) 
- helping App developers understand / hear more about exciting new things in Fabric, eg. features upcoming or work in progress - ie things that appeal to the developer
- foster more interest, best practices etc in developing applications (eg developing solutions, use cases) with Hyperledger Fabric. 
- opportunity to ask questions of the Fabric team eg. you may have feedback/questions on your experiences developing solutions with Fabric
- to share stuff you've done with the community, eg sample code / sample use cases that others may be interested in

If you wish to share content on a call, just let me know via email direct or DM me on Rocketchat (ID: mahoney1) and I'll put an item on the agenda. Provide the following:
- the topic (state whether its presentation, or demo etc)
- the full name of the presenter, and 
- approx length of your pitch in minutes


The Zoom webconference ID is https://zoom.us/my/hyperledger.community   

More information can be found on the community page -> https://wiki.hyperledger.org/display/fabric/Fabric+Application+Developer+Community+Calls

You can get calendar invites (eg iCal) here

many thanks for your time - feel free to forward this email if you think it is of interest to a colleague.

Paul O'Mahony
Community Lead - Hyperledger Fabric Developer Community
RocketChat:  mahoney1

mahoney@...


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


upgrade not working

Park, Jungil
 

 

Hi Team,

 

I am using 1.4.0 with couchdb and tried to upgrade to 2.0.

I use the following commands.

 

1.               command

docker run --rm -v /opt/hyperledger/production/peer0org1:/var/hyperledger/production/ \

            -v /opt/hfabric.v1x/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp/ \

            --name peer0.org1.example.com \

            --env CORE_LEDGER_STATE_STATEDATABASE=CouchDB  \

            hyperledger/fabric-peer:2.0 peer node upgrade-dbs

2.               ouput

 

2020-03-30 11:29:56.778 UTC [kvledger] UpgradeDBs -> INFO 001 Ledger data folder from config = [/var/hyperledger/production/ledgersData]

2020-03-30 11:29:56.783 UTC [kvledger] dropStateLevelDB -> INFO 002 Dropping StateLevelDB at location [/var/hyperledger/production/ledgersData/stateLeveldb] ...if present

2020-03-30 11:29:56.783 UTC [kvledger] dropConfigHistoryDB -> INFO 003 Dropping ConfigHistoryDB at location [/var/hyperledger/production/ledgersData/configHistory]

2020-03-30 11:29:56.784 UTC [kvledger] dropBookkeeperDB -> INFO 004 Dropping BookkeeperDB at location [/var/hyperledger/production/ledgersData/bookkeeper]

2020-03-30 11:29:56.784 UTC [kvledger] dropHistoryDB -> INFO 005 Dropping HistoryDB at location [/var/hyperledger/production/ledgersData/historyLeveldb] ...if present

2020-03-30 11:29:56.784 UTC [fsblkstorage] DeleteBlockStoreIndex -> INFO 006 Dropping the index dir [/var/hyperledger/production/ledgersData/chains/index]... if present

 

 

 

 

3.               second command

docker run --rm -v /opt/hyperledger/production/peer0org1:/var/hyperledger/production/ \

            -v /opt/hfabric.v1x/crypto-config/peerOrganizations/org1.example.com/peers/peer0.org1.example.com/msp:/etc/hyperledger/fabric/msp/ \

            --name peer0.org1.example.com \

            hyperledger/fabric-peer:2.0 peer node start

 

 

 

4.               ouput :

5.  2020-03-30 09:00:24.383 UTC [nodeCmd] serve -> INFO 001 Starting peer:

6.   Version: 2.0.0

7.   Commit SHA: 0432c3e

8.   Go version: go1.13.4

9.   OS/Arch: linux/amd64

10.  Chaincode:

11.   Base Docker Namespace: hyperledger

12.   Base Docker Label: org.hyperledger.fabric

13.   Docker Namespace: hyperledger

14. 2020-03-30 09:00:24.384 UTC [peer] getLocalAddress -> INFO 002 Auto-detected peer address: 172.17.0.2:7051

15. 2020-03-30 09:00:24.384 UTC [peer] getLocalAddress -> INFO 003 Host is 0.0.0.0 , falling back to auto-detected address: 172.17.0.2:7051

16. 2020-03-30 09:00:24.414 UTC [gossip.service] New -> INFO 004 Initialize gossip with endpoint 172.17.0.2:7051

17. 2020-03-30 09:00:24.416 UTC [gossip.gossip] New -> INFO 005 Creating gossip service with self membership of Endpoint: , InternalEndpoint: 172.17.0.2:7051, PKI-ID: 65dfd2f8791c19aacad25b10a94d2db1219f7be324344483be4bdf8aee89bd3b, Metadata:

18. 2020-03-30 09:00:24.416 UTC [gossip.gossip] New -> WARN 006 External endpoint is empty, peer will not be accessible outside of its organization

19. 2020-03-30 09:00:24.416 UTC [gossip.gossip] start -> INFO 007 Gossip instance 172.17.0.2:7051 started

20. 2020-03-30 09:00:24.417 UTC [ledgermgmt] NewLedgerMgr -> INFO 008 Initializing LedgerMgr

21. 2020-03-30 09:00:24.456 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 009 DB is empty Setting db format as 2.0

22. 2020-03-30 09:00:24.483 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 00a DB is empty Setting db format as 2.0

23. 2020-03-30 09:00:24.484 UTC [ledgermgmt] NewLedgerMgr -> INFO 00b Initialized LedgerMgr

24. 2020-03-30 09:00:24.484 UTC [lifecycle] InitializeLocalChaincodes -> INFO 00c Initialized lifecycle cache with 0 already installed chaincodes

25. 2020-03-30 09:00:24.485 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00d Entering computeChaincodeEndpoint with peerHostname: 172.17.0.2

26. 2020-03-30 09:00:24.485 UTC [nodeCmd] computeChaincodeEndpoint -> INFO 00e Exit with ccEndpoint: 172.17.0.2:7052

27. 2020-03-30 09:00:24.485 UTC [nodeCmd] createChaincodeServer -> WARN 00f peer.chaincodeListenAddress is not set, using 172.17.0.2:7052

28. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 010 deploying system chaincode 'lscc'

29. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 011 deploying system chaincode 'cscc'

30. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 012 deploying system chaincode 'qscc'

31. 2020-03-30 09:00:24.490 UTC [sccapi] DeploySysCC -> INFO 013 deploying system chaincode '_lifecycle'

32. 2020-03-30 09:00:24.490 UTC [nodeCmd] serve -> INFO 014 Deployed system chaincodes

33. 2020-03-30 09:00:24.490 UTC [peer] Initialize -> INFO 015 Loading chain mychannel

34. 2020-03-30 09:00:24.490 UTC [ledgermgmt] OpenLedger -> INFO 016 Opening ledger with id = mychannel

35. 2020-03-30 09:00:24.491 UTC [fsblkstorage] newBlockfileMgr -> INFO 017 Getting block information from block storage

36. 2020-03-30 09:00:24.540 UTC [fsblkstorage] syncIndex -> INFO 018 Start building index from block [0] to last block [35356]

37. 2020-03-30 09:00:24.542 UTC [fsblkstorage] syncIndex -> INFO 019 Indexed block number [0]

38. 2020-03-30 09:00:35.837 UTC [fsblkstorage] syncIndex -> INFO 01a Indexed block number [10000]

39. 2020-03-30 09:00:47.392 UTC [fsblkstorage] syncIndex -> INFO 01b Indexed block number [20000]

40. 2020-03-30 09:01:00.008 UTC [fsblkstorage] syncIndex -> INFO 01c Indexed block number [30000]

41. 2020-03-30 09:01:06.764 UTC [fsblkstorage] syncIndex -> INFO 01d Finished building index. Last block indexed [35356]

42. 2020-03-30 09:01:06.764 UTC [kvledger] recommitLostBlocks -> INFO 01e Recommitting lost blocks - firstBlockNum=0, lastBlockNum=35356, recoverables=[]kvledger.recoverable{(*lockbasedtxmgr.LockBasedTxMgr)(0xc00021cfa0), (*history.DB)(0xc005fda980)}

43. 2020-03-30 09:01:06.765 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 01f Recommitting block [0] to state database

44. 2020-03-30 09:01:06.766 UTC [history] CommitLostBlock -> INFO 020 Recommitting block [0] to history database

45. 2020-03-30 09:01:06.772 UTC [cceventmgmt] HandleStateUpdates -> INFO 021 Channel [mychannel]: Handling deploy or update of chaincode [chaincode]

46. 2020-03-30 09:01:06.778 UTC [valimpl] preprocessProtoBlock -> WARN 022 Channel [mychannel]: Block [4] Transaction index [0] TxId [b5199e1b5d1f4522eca11680757652ae2882ebce5b66d4b534e5a5ccfcd3562d] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]

47. 2020-03-30 09:01:09.088 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 023 Recommitting block [1000] to state database

48. 2020-03-30 09:01:09.090 UTC [history] CommitLostBlock -> INFO 024 Recommitting block [1000] to history database

49. 2020-03-30 09:01:11.437 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 025 Recommitting block [2000] to state database

50. 2020-03-30 09:01:11.438 UTC [history] CommitLostBlock -> INFO 026 Recommitting block [2000] to history database

51. 2020-03-30 09:01:13.755 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 027 Recommitting block [3000] to state database

52. 2020-03-30 09:01:13.756 UTC [history] CommitLostBlock -> INFO 028 Recommitting block [3000] to history database

53. 2020-03-30 09:01:16.122 UTC [lockbasedtxmgr] CommitLostBlock -> INFO 029 Recommitting block [4000] to state database

54. 2020-03-30 09:01:16.123 UTC [history] CommitLostBlock -> INFO 02a Recommitting block [4000] to history database

55. 2020-03-30 09:01:16.836 UTC [valimpl] preprocessProtoBlock -> WARN 02b Channel [mychannel]: Block [4297] Transaction index [2] TxId [8a17e87c38c6c8f99e59166695feae179cf5ca99494a6167fe23e7ff23c104e9] marked as invalid by committer. Reason code [MVCC_READ_CONFLICT]

56. 2020-03-30 09:01:16.836 UTC [valimpl] preprocessProtoBlock -> WARN 02c Channel [mychannel]: Block [4297] Transaction index [3] TxId [c78daa54b1c61f6c54d330af34649137d719374bf43a7a8189ae5d09dc1f31ad] marked as invalid by committer. Reason code [MVCC_READ_CONFLICT]

 

 

 

 

 

After this, still I got error below

 

2020-03-30 11:33:03.108 UTC [leveldbhelper] openDBAndCheckFormat -> INFO 00a DB is empty Setting db format as 2.0

2020-03-30 11:33:03.195 UTC [kvledger] func1 -> ERRO 00b Please execute the 'peer node upgrade-dbs' command to upgrade the database format: unexpected format. db info = [CouchDB for state database], data format = [], expected format = [2.0]

2020-03-30 11:33:03.195 UTC [gossip.gossip] Stop -> INFO 00c Stopping gossip

2020-03-30 11:33:03.195 UTC [gossip.discovery] Stop -> INFO 00d Stopping

2020-03-30 11:33:03.195 UTC [gossip.discovery] Stop -> INFO 00e Stopped

2020-03-30 11:33:03.195 UTC [gossip.comm] Stop -> INFO 00f Stopping

2020-03-30 11:33:03.195 UTC [gossip.comm] Stop -> INFO 010 Stopped

panic: Error in instantiating ledger provider: unexpected format. db info = [CouchDB for state database], data format = [], expected format = [2.0]

goroutine 1 [running]:

 

 

 

 

Does anyone any idea what happen here?

 

 

Thanks,

Jungil.

 

 

 

 

 

This message has been sent by ABN AMRO Bank N.V., which has its seat at Gustav Mahlerlaan 10 (1082 PP) Amsterdam, the Netherlands, and is registered in the Commercial Register of Amsterdam under number 34334259.


Re: Change genesis block to another specified block number #fabric #fabric-questions

David Enyeart
 

Hi, that is exactly the point of the checkpoint feature https://jira.hyperledger.org/browse/FAB-106, which is currently being investigated so that a RFC proposal can be submitted to the community.


Dave Enyeart

susheeldighade---03/28/2020 04:23:44 AM---Hello, I am wondering if there is any possible solution to point the genesis block to any decided bl

From: susheeldighade@...
To: fabric@...
Date: 03/28/2020 04:23 AM
Subject: [EXTERNAL] [Hyperledger Fabric] Change genesis block to another specified block number #fabric #fabric-questions
Sent by: fabric@...





Hello,

I am wondering if there is any possible solution to point the genesis block to any decided block number. While working with certain use-case which involves storing of large number of transactions into ledger, it is observed that after sometime the disk space gets filled up and there is no other way rather than to bootstrap the network (i.e clean the data and build the network again). So is there a way where we can point out the genesis block to some other block number eg. block no: 5000, so that every peer in the network will consider this as the starting block and the data of first 5000 blocks can be stored safely in an external disk decoupled from the blockchain network.
Please let me know any possible approaches.




connection problem

music prime
 

2020-03-29 11:05:22.389 UTC [main] InitCmd -> WARN 001 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
2020-03-29 11:05:22.394 UTC [main] SetOrdererEnv -> WARN 002 CORE_LOGGING_LEVEL is no longer supported, please use the FABRIC_LOGGING_SPEC environment variable
Error: error getting endorser client for channel: endorser client failed to connect to peer0.fruit.model.com:12051: failed to create new connection: connection error: desc = "transport: error while dialing: dial tcp 192.168.16.2:12051: connect: connection refused"


facing this problem kindly help.


Promoting Hyperledger Community and O'Reilly Media Online Training

Chainsaw <mark.morris@...>
 

Hello My Dear Hyperledger Friends & Community,

I hope you are well, this crisis has not been too hard on you and your loved ones, and you or loved ones are finding the support you may need during this trying time.

You are in my prayers and thoughts.

I would like to inform you I’m developing and conducting a Live Online Training course on Hyperledger Fabric for O’Reilly Media. I will be promoting all of the wonderful work the Hyperledger community is doing, and encourage support for and participation in Hyperledger community, in addition to the primary topic, Hyperledger Fabric development.

Also, Hyperledger Austin will be holding virtual meetups until it is safe to resume our live in-person meetups at Capital Factory, located in Austin, Texas.

Hopefully, by May we will begin to see the light at the end of this dark tunnel.

O'REILLY LIVE ONLINE TRAINING with Mark Anthony Morris: 90-minutes to Hyperledger Fabric -- Crafting blockchain technology solutions https://lnkd.in/eKwJjKh

Stay safe, we will get through this. Summer is coming :)

Sincerely,
Mark Anthony Morris
Founder Hempchain™ a Supply Chain Platform & Marketplace for Industrial Hemp, build on Hyperledger Fabric & Sawtooth
Hyperledger Austin Meetup (est. 2016, 740+ members) 
Austin Blockchain Technology Meetup (est. 2015, 2,200+ members)



Re: Raft orderers not able to elect a leader #raft #consensus

Shantharam, Manu
 

Hi,

Please find the following logs attached:

2-orderer-logs-leader-stopped: logs of the two online orderers
working-orderer-logs: partial logs of all the orderers

Note: I have two hosts and one of them has two orderers.

Thanks,
Manu


Re: hyperledger doubt

Brett T Logan <brett.t.logan@...>
 

Are you doing a `docker ps -a` presumably its crashed, `docker ps` only shows running containers
 
Brett Logan
Software Engineer, IBM Blockchain
Phone: 1-984-242-6890
 
 
 

----- Original message -----
From: "music prime" <as040228@...>
Sent by: fabric@...
To: fabric@...
Cc:
Subject: [EXTERNAL] [Hyperledger Fabric] hyperledger doubt
Date: Sat, Mar 28, 2020 2:55 PM
 
i am making a network but the orderer container is not showing in the docker ps command.
kindly provide help.
files have been attached.
 


hyperledger doubt

music prime
 

i am making a network but the orderer container is not showing in the docker ps command.
kindly provide help.
files have been attached.


Re: Limiting dissemination of hashes of private collection keys and values?

Yacov
 

Regarding the "same salt for all keys":
What if you have a special key that stores the salt, per collection:  "salt" ---> salt
and when you want to access the other keys you always read from this "salt" key to get salt and then use it to access the other keys?

Regarding:

>  (2) still allows an attacker to see that two keys are equal, two values are equal, or a key is equal to a value.
If you use the collection name inside the hash ( hash(collection || key || salt) ) then two keys in different collections are not equal.
You can also make the values be: hash(collection || key || value || salt) and then the key place a role in the hash computation of a value, so two values that are the same but in different keys, do not look the same.



From:        Victor Dods <victor.dods@...>
To:        Yacov Manevich <YACOVM@...>
Cc:        fabric@...
Date:        03/28/2020 02:38 AM
Subject:        [EXTERNAL] Re: [Hyperledger Fabric] Limiting dissemination of hashes of private collection keys and values?




Thanks for the reply, Yacov!

Appending a salt to the plaintext of each key* means that I need to retain and supply that salt in order to use GetPrivateData, which further means that I need to know which keys I'll be accessing in advance of the transaction proposal so I can send the appropriate salt(s) in the transient data field.  This represents (1) a significant architectural burden, (2) broken encapsulation of the chaincode call (the caller can't and shouldn't be expected to know all the keys that the chaincode will use in advance).

Perhaps it would be useful to elaborate on a more essential version of my suggestion.  Forget the part about the HMAC.  Add a modified version of PutPrivateData to ChaincodeStubInterface:
- PutPrivateDataWithNonces(collection string, key string, keyNonce []byte, value []byte, valueNonce []byte) error
When this is called, it stores the quadruple (key, keyNonce, value, valueNonce) in the Private State, and it stores (hash(keyNonce+key), hash(valueNonce+value)) in the Channel State.  Here, the chaincode author is responsible for generating those nonces.  Then the hash scheme is exactly as you say, except that now the nonces don't interfere with the keys and values, and I can use GetPrivateData and other related functions just as I would if I didn't have to worry about nonces (i.e. GetPrivateData etc are backward-compatible).  The concerns are now separate.
- PutPrivateData doesn't change, and internally it just uses empty byte arrays for keyNonce and valNonce, so the behavior of the hash scheme is still compatible with the existing Fabric protocol.

The difference between this and my original suggestion is that Fabric would be:
- generating those nonces for you (so no repetitive boilerplate for chaincode authors)
- automatically (so all chaincode authors benefit without additional work on their part)
- using a well-defined, tested scheme (so each chaincode author isn't burdened with having to implement it correctly themselves).

*You might suggest that you could just use a single salt for all keys, but (1) that still imposes a burden to manage that salt outside of the chaincode and (2) still allows an attacker to see that two keys are equal, two values are equal, or a key is equal to a value.

Victor Dods
Chief Software Architect
LedgerDomain


On Fri, Mar 27, 2020 at 1:43 PM Yacov Manevich <YACOVM@...> wrote:
why do you need a MAC? What's wrong with just appending a salt to the plaintext? You're not protecting against any length extension attacks or doing any kind of authentication.



From:        
"Victor Dods" <victor.dods@...>
To:        
fabric@...
Date:        
03/27/2020 05:28 AM
Subject:        
[EXTERNAL] [Hyperledger Fabric] Limiting dissemination of hashes of private collection keys and values?
Sent by:        
fabric@...




Hi all, I'm wondering if there's a mechanism for specifying that the hashes of private collection keys and values should not be disseminated beyond the peers of that private collection.  Basically my use case is such that I know that a particular private collection's data will never be used outside of the peers of that collection, and the issue regarding having to put nonces into private values and KEYS in particular is a total pain.  Because I don't need this extra-collection verification, I don't want the overhead that comes along with that.

Or failing that, what is a reasonable scheme for putting nonces into the keys of a private collection?  It can't be truly random, otherwise there's no way to recover the nonced key (e.g. "abc@...%00<random-nonce>") from the "bare" key (e.g. "abc@...").  One could make it deterministic by making the nonce a the hashed value of the bare key, but then if an attacker knows which hash function you're using, they could brute force the key in smaller spaces (phone numbers, email addresses, etc).  You could use an HMAC with a specified key, but then you (1) have to manage that HMAC key, (2) have to tie the lifetime of that HMAC key to the lifetime of the key/value pair, and (3) have to use the same HMAC key for all key/value pairs OR have some scheme for using multiple HMAC keys and mapping them to the key/value pairs.  Basically the problem of having to manually embed the nonces in the keys and values really gets in the way.

One thing that comes to mind is using truly random nonces for the keys, and then doing a GetPrivateDataByPartialCompositeKey using the bare key to deal with not knowing the nonce, but then you're in the situation where you've done a range-based query, and are then subject to the limitations detailed here: https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data-arch.html#querying-private-datawhich is a total pain.

Anyway, I'd generally like to hear about how people have been dealing with this issue.

As a side comment for the Fabric maintainers -- I've brought this issue up in the past, and so have others -- why not have Fabric do this sort of nonce bookkeeping automatically?  If everyone is responsible for manually implementing it themselves, how many people are (1) going to do it at all and (2) going to do it correctly?

An idea for how this could work:
- If a transaction is going to write any private data, require a RNG seed be set using a new SeedRNG method in the chaincode stub (otherwise the transaction fails with error).  This RNG seed would be passed into the endorsing peer via the transient data field.  Potentially the name of the HMAC scheme should be a channel configuration value.
- When a private data write is done, generate a pair of HMAC keys from the seeded RNG, one for the key and one for the value, and keep them in parallel with the key and value.  Thus the diagram in this section https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data/private-data.html#what-is-a-private-data-collectionwould have a quadruple (k1, k1HMACkey, secret-value, secret-value-HMACkey) for Private State.
- Then instead of hash(k1) and hash(secret-value) being stored in the Channel State, it's HMAC(k1, k1HMACkey) and HMAC(secret-value, secret-value-HMACkey), which can be verified just as easily as before.
- Finally, all the stub's Get/Put/Del methods for private data operate on the "bare" key/value pairs as expected and ideally desired, and there's no interference from the details of the HMAC scheme, and all is well in the world again.

I'd be curious to hear thoughts on this from Fabric maintainers and other interested people.

PS: Thanks to Mike Lodder for educating me on HMACs and other security mechanisms.



Re: Raft orderers not able to elect a leader #raft #consensus

Yacov
 

Can you supply logs of all orderers?



From:        mshantharam@...
To:        fabric@...
Date:        03/28/2020 07:52 AM
Subject:        [EXTERNAL] [Hyperledger Fabric] Raft orderers not able to elect a leader #raft #consensus
Sent by:        fabric@...




Hi,

I have a hyperledger network (1.4.3) with 3 orderers in raft configuration and 3 peers. This works fine when all component are up and running. However when one orderer, the leader, is stopped, I see logs related to the election process in both the orderers, but the leader selection doesn't seem to happen even after 15-20 mins (I see the election process logs being output continuously). How much time does it take to elect a leader? Is there a configuration that would break any tie (in terms of vote) quickly?

Thanks,
Manu    




Change genesis block to another specified block number #fabric #fabric-questions

susheeldighade@...
 

Hello,

I am wondering if there is any possible solution to point the genesis block to any decided block number. While working with certain use-case which involves storing of large number of transactions into ledger, it is observed that after sometime the disk space gets filled up and there is no other way rather than to bootstrap the network (i.e clean the data and build the network again). So is there a way where we can point out the genesis block to some other block number eg. block no: 5000, so that every peer in the network will consider this as the starting block and the data of first 5000 blocks can be stored safely in an external disk decoupled from the blockchain network.
Please let me know any possible approaches.


Raft orderers not able to elect a leader #raft #consensus

Shantharam, Manu
 

Hi,

I have a hyperledger network (1.4.3) with 3 orderers in raft configuration and 3 peers. This works fine when all component are up and running. However when one orderer, the leader, is stopped, I see logs related to the election process in both the orderers, but the leader selection doesn't seem to happen even after 15-20 mins (I see the election process logs being output continuously). How much time does it take to elect a leader? Is there a configuration that would break any tie (in terms of vote) quickly?

Thanks,
Manu    


Re: Limiting dissemination of hashes of private collection keys and values?

Victor Dods
 

Thanks for the reply, Yacov!

Appending a salt to the plaintext of each key* means that I need to retain and supply that salt in order to use GetPrivateData, which further means that I need to know which keys I'll be accessing in advance of the transaction proposal so I can send the appropriate salt(s) in the transient data field.  This represents (1) a significant architectural burden, (2) broken encapsulation of the chaincode call (the caller can't and shouldn't be expected to know all the keys that the chaincode will use in advance).

Perhaps it would be useful to elaborate on a more essential version of my suggestion.  Forget the part about the HMAC.  Add a modified version of PutPrivateData to ChaincodeStubInterface:
- PutPrivateDataWithNonces(collection string, key string, keyNonce []byte, value []byte, valueNonce []byte) error
When this is called, it stores the quadruple (key, keyNonce, value, valueNonce) in the Private State, and it stores (hash(keyNonce+key), hash(valueNonce+value)) in the Channel State.  Here, the chaincode author is responsible for generating those nonces.  Then the hash scheme is exactly as you say, except that now the nonces don't interfere with the keys and values, and I can use GetPrivateData and other related functions just as I would if I didn't have to worry about nonces (i.e. GetPrivateData etc are backward-compatible).  The concerns are now separate.
- PutPrivateData doesn't change, and internally it just uses empty byte arrays for keyNonce and valNonce, so the behavior of the hash scheme is still compatible with the existing Fabric protocol.

The difference between this and my original suggestion is that Fabric would be:
- generating those nonces for you (so no repetitive boilerplate for chaincode authors)
- automatically (so all chaincode authors benefit without additional work on their part)
- using a well-defined, tested scheme (so each chaincode author isn't burdened with having to implement it correctly themselves).

*You might suggest that you could just use a single salt for all keys, but (1) that still imposes a burden to manage that salt outside of the chaincode and (2) still allows an attacker to see that two keys are equal, two values are equal, or a key is equal to a value.

Victor Dods
Chief Software Architect
LedgerDomain


On Fri, Mar 27, 2020 at 1:43 PM Yacov Manevich <YACOVM@...> wrote:
why do you need a MAC? What's wrong with just appending a salt to the plaintext? You're not protecting against any length extension attacks or doing any kind of authentication.



From:        "Victor Dods" <victor.dods@...>
To:        fabric@...
Date:        03/27/2020 05:28 AM
Subject:        [EXTERNAL] [Hyperledger Fabric] Limiting dissemination of hashes of private collection keys and values?
Sent by:        fabric@...




Hi all, I'm wondering if there's a mechanism for specifying that the hashes of private collection keys and values should not be disseminated beyond the peers of that private collection.  Basically my use case is such that I know that a particular private collection's data will never be used outside of the peers of that collection, and the issue regarding having to put nonces into private values and KEYS in particular is a total pain.  Because I don't need this extra-collection verification, I don't want the overhead that comes along with that.

Or failing that, what is a reasonable scheme for putting nonces into the keys of a private collection?  It can't be truly random, otherwise there's no way to recover the nonced key (e.g. "abc@...%00<random-nonce>") from the "bare" key (e.g. "abc@...").  One could make it deterministic by making the nonce a the hashed value of the bare key, but then if an attacker knows which hash function you're using, they could brute force the key in smaller spaces (phone numbers, email addresses, etc).  You could use an HMAC with a specified key, but then you (1) have to manage that HMAC key, (2) have to tie the lifetime of that HMAC key to the lifetime of the key/value pair, and (3) have to use the same HMAC key for all key/value pairs OR have some scheme for using multiple HMAC keys and mapping them to the key/value pairs.  Basically the problem of having to manually embed the nonces in the keys and values really gets in the way.

One thing that comes to mind is using truly random nonces for the keys, and then doing a GetPrivateDataByPartialCompositeKey using the bare key to deal with not knowing the nonce, but then you're in the situation where you've done a range-based query, and are then subject to the limitations detailed here: https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data-arch.html#querying-private-datawhich is a total pain.

Anyway, I'd generally like to hear about how people have been dealing with this issue.

As a side comment for the Fabric maintainers -- I've brought this issue up in the past, and so have others -- why not have Fabric do this sort of nonce bookkeeping automatically?  If everyone is responsible for manually implementing it themselves, how many people are (1) going to do it at all and (2) going to do it correctly?

An idea for how this could work:
- If a transaction is going to write any private data, require a RNG seed be set using a new SeedRNG method in the chaincode stub (otherwise the transaction fails with error).  This RNG seed would be passed into the endorsing peer via the transient data field.  Potentially the name of the HMAC scheme should be a channel configuration value.
- When a private data write is done, generate a pair of HMAC keys from the seeded RNG, one for the key and one for the value, and keep them in parallel with the key and value.  Thus the diagram in this section https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data/private-data.html#what-is-a-private-data-collectionwould have a quadruple (k1, k1HMACkey, secret-value, secret-value-HMACkey) for Private State.
- Then instead of hash(k1) and hash(secret-value) being stored in the Channel State, it's HMAC(k1, k1HMACkey) and HMAC(secret-value, secret-value-HMACkey), which can be verified just as easily as before.
- Finally, all the stub's Get/Put/Del methods for private data operate on the "bare" key/value pairs as expected and ideally desired, and there's no interference from the details of the HMAC scheme, and all is well in the world again.

I'd be curious to hear thoughts on this from Fabric maintainers and other interested people.

PS: Thanks to Mike Lodder for educating me on HMACs and other security mechanisms.




Re: Limiting dissemination of hashes of private collection keys and values?

Yacov
 

why do you need a MAC? What's wrong with just appending a salt to the plaintext? You're not protecting against any length extension attacks or doing any kind of authentication.



From:        "Victor Dods" <victor.dods@...>
To:        fabric@...
Date:        03/27/2020 05:28 AM
Subject:        [EXTERNAL] [Hyperledger Fabric] Limiting dissemination of hashes of private collection keys and values?
Sent by:        fabric@...




Hi all, I'm wondering if there's a mechanism for specifying that the hashes of private collection keys and values should not be disseminated beyond the peers of that private collection.  Basically my use case is such that I know that a particular private collection's data will never be used outside of the peers of that collection, and the issue regarding having to put nonces into private values and KEYS in particular is a total pain.  Because I don't need this extra-collection verification, I don't want the overhead that comes along with that.

Or failing that, what is a reasonable scheme for putting nonces into the keys of a private collection?  It can't be truly random, otherwise there's no way to recover the nonced key (e.g. "abc@...%00<random-nonce>") from the "bare" key (e.g. "abc@...").  One could make it deterministic by making the nonce a the hashed value of the bare key, but then if an attacker knows which hash function you're using, they could brute force the key in smaller spaces (phone numbers, email addresses, etc).  You could use an HMAC with a specified key, but then you (1) have to manage that HMAC key, (2) have to tie the lifetime of that HMAC key to the lifetime of the key/value pair, and (3) have to use the same HMAC key for all key/value pairs OR have some scheme for using multiple HMAC keys and mapping them to the key/value pairs.  Basically the problem of having to manually embed the nonces in the keys and values really gets in the way.

One thing that comes to mind is using truly random nonces for the keys, and then doing a GetPrivateDataByPartialCompositeKey using the bare key to deal with not knowing the nonce, but then you're in the situation where you've done a range-based query, and are then subject to the limitations detailed here: https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data-arch.html#querying-private-datawhich is a total pain.

Anyway, I'd generally like to hear about how people have been dealing with this issue.

As a side comment for the Fabric maintainers -- I've brought this issue up in the past, and so have others -- why not have Fabric do this sort of nonce bookkeeping automatically?  If everyone is responsible for manually implementing it themselves, how many people are (1) going to do it at all and (2) going to do it correctly?

An idea for how this could work:
- If a transaction is going to write any private data, require a RNG seed be set using a new SeedRNG method in the chaincode stub (otherwise the transaction fails with error).  This RNG seed would be passed into the endorsing peer via the transient data field.  Potentially the name of the HMAC scheme should be a channel configuration value.
- When a private data write is done, generate a pair of HMAC keys from the seeded RNG, one for the key and one for the value, and keep them in parallel with the key and value.  Thus the diagram in this section https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data/private-data.html#what-is-a-private-data-collectionwould have a quadruple (k1, k1HMACkey, secret-value, secret-value-HMACkey) for Private State.
- Then instead of hash(k1) and hash(secret-value) being stored in the Channel State, it's HMAC(k1, k1HMACkey) and HMAC(secret-value, secret-value-HMACkey), which can be verified just as easily as before.
- Finally, all the stub's Get/Put/Del methods for private data operate on the "bare" key/value pairs as expected and ideally desired, and there's no interference from the details of the HMAC scheme, and all is well in the world again.

I'd be curious to hear thoughts on this from Fabric maintainers and other interested people.

PS: Thanks to Mike Lodder for educating me on HMACs and other security mechanisms.




Re: #fabric Impossible instantiate chaincode due to PANIC ERROR on peer: unexpected Previous block hash #fabric

Magno Alves Cavalcante
 

I opened a request at "https://stackoverflow.com/questions/60890884/hyperledger-fabric-how-to-clear-out-the-dev-environment-after-each-blockchain" to detail the problems with this situation.
If somebody may help, I appreciate.

Thanks!


Re: #fabric Impossible instantiate chaincode due to PANIC ERROR on peer: unexpected Previous block hash #fabric

Magno Alves Cavalcante
 

1) Is there any documented procedure or checklist to verify if there are no artifacts from prior trials?

2) Could I start ORDERER without any information about channel and genesis block in orderer.yaml, and create after using "peer channel" command?

For example, adding # before parameters to remove tem?
#- ORDERER_GENERAL_GENESISFILE=/etc/hyperledger/fabric/configtx/genesis.block
#- ORDERER_GENERAL_GENESISPROFILE=OrgOrdererGenesis


Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 03/27/2020 #cal-notice

fabric@lists.hyperledger.org Calendar <noreply@...>
 

Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When:
Friday, 27 March 2020
4:00pm to 5:00pm
(GMT+00:00) Europe/London

Where:
https://zoom.us/j/6223336701

Organizer:
a_o-dowd@... +441962816761

Description:
Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group


Upcoming Event: Hyperledger Fabric Documentation Workgroup call - Western hemisphere - Fri, 03/27/2020 4:00pm-5:00pm #cal-reminder

fabric@lists.hyperledger.org Calendar <fabric@...>
 

Reminder: Hyperledger Fabric Documentation Workgroup call - Western hemisphere

When: Friday, 27 March 2020, 4:00pm to 5:00pm, (GMT+00:00) Europe/London

Where:https://zoom.us/j/6223336701

View Event

Organizer: Anthony O'Dowd a_o-dowd@... +441962816761

Description: Documentation workgroup call.
Agenda, minutes and recordings :https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group