markparz (Thu, 02 Feb 2017 23:32:10 GMT):
Technical aspects of the Fabric ledger.
donjohnny (Thu, 02 Feb 2017 23:40:31 GMT):
Has joined the channel.
nickgaski (Thu, 02 Feb 2017 23:48:53 GMT):
Has joined the channel.
C0rWin (Fri, 03 Feb 2017 00:10:55 GMT):
Has joined the channel.
dave.enyeart (Fri, 03 Feb 2017 00:26:17 GMT):
Has joined the channel.
mastersingh24 (Fri, 03 Feb 2017 00:50:05 GMT):
Has joined the channel.
salmanbaset (Fri, 03 Feb 2017 01:19:32 GMT):
Has joined the channel.
JonathanTan (Fri, 03 Feb 2017 01:52:59 GMT):
Has joined the channel.
grapebaba (Fri, 03 Feb 2017 02:25:06 GMT):
Has joined the channel.
tuand (Fri, 03 Feb 2017 02:30:43 GMT):
Has joined the channel.
timblankers (Fri, 03 Feb 2017 02:42:53 GMT):
Has joined the channel.
Ratnakar (Fri, 03 Feb 2017 02:52:09 GMT):
Has joined the channel.
didnotgetagoodname (Fri, 03 Feb 2017 03:57:33 GMT):
Has joined the channel.
frbrkoala (Fri, 03 Feb 2017 07:01:37 GMT):
Has joined the channel.
nvlasov (Fri, 03 Feb 2017 07:13:17 GMT):
Has joined the channel.
ryokawajp (Fri, 03 Feb 2017 07:52:47 GMT):
Has joined the channel.
cca88 (Fri, 03 Feb 2017 08:21:23 GMT):
Has joined the channel.
jdockter (Fri, 03 Feb 2017 11:39:02 GMT):
Has joined the channel.
silliman (Fri, 03 Feb 2017 13:57:08 GMT):
Has joined the channel.
gormand (Fri, 03 Feb 2017 14:43:05 GMT):
Has joined the channel.
kletkeman (Fri, 03 Feb 2017 15:19:54 GMT):
Has joined the channel.
Nishi (Fri, 03 Feb 2017 18:30:34 GMT):
Has joined the channel.
fz (Fri, 03 Feb 2017 19:28:02 GMT):
Has joined the channel.
karkal (Fri, 03 Feb 2017 19:52:43 GMT):
Has joined the channel.
dividovi2 (Fri, 03 Feb 2017 20:25:59 GMT):
Has joined the channel.
ericmvaughn (Fri, 03 Feb 2017 22:45:18 GMT):
Has joined the channel.
jiangyaoguo (Sat, 04 Feb 2017 01:33:55 GMT):
Has joined the channel.
genggjh (Sat, 04 Feb 2017 03:44:25 GMT):
Has joined the channel.
yacovm (Sat, 04 Feb 2017 04:52:44 GMT):
Has joined the channel.
bfuentes@fr.ibm.com (Sat, 04 Feb 2017 09:20:16 GMT):
Has joined the channel.
muralisr (Sat, 04 Feb 2017 14:48:39 GMT):
Has joined the channel.
sword_linux (Sat, 04 Feb 2017 15:24:18 GMT):
Has joined the channel.
MadhavaReddy (Sat, 04 Feb 2017 18:13:20 GMT):
Has joined the channel.
sstone1 (Sat, 04 Feb 2017 19:24:53 GMT):
Has joined the channel.
matanyahu (Sat, 04 Feb 2017 19:28:21 GMT):
Has joined the channel.
matanyahu (Sat, 04 Feb 2017 19:29:42 GMT):
Hi, I was curious if you could redirect me to a detailed description about following topics related to Fabric storage
matanyahu (Sat, 04 Feb 2017 19:30:30 GMT):
1) interaction between chaincode output and underlying database (how is chaincode output committed to the local ledger as a part of a newly created block)
matanyahu (Sat, 04 Feb 2017 19:31:29 GMT):
2) how newly committed blocks are added to the local ledger used by a VP before being sent out to other peers as part of consensus protocol
matanyahu (Sat, 04 Feb 2017 19:32:13 GMT):
3) is there a way I can discover underlying database structure without querying it via a chaincode
matanyahu (Sat, 04 Feb 2017 19:33:04 GMT):
The reason I am asking is to understand better to what extent a given KV-style DB should be prepared to become blockchain-ready
matanyahu (Sat, 04 Feb 2017 19:33:34 GMT):
any materials to diagrams showing Fabric DB architecture and interaction would also be greatly apprecaited
takemiyamakoto (Sat, 04 Feb 2017 20:56:31 GMT):
Has joined the channel.
dave.enyeart (Sat, 04 Feb 2017 21:04:08 GMT):
@matanyahu Focus has shifted to v1, I'd recommend you start by reviewing the data architecture charts attached in jira at: https://jira.hyperledger.org/browse/FAB-758
dave.enyeart (Sat, 04 Feb 2017 21:06:40 GMT):
Starting in v1 there is a state database interface that enables plugging in new KV or document style DBs. Check out the interface here: https://gerrit.hyperledger.org/r/gitweb?p=fabric.git;a=blob;f=core/ledger/kvledger/txmgmt/statedb/statedb.go;h=fe09c82cc164ad6a94692c15d43731d69047eb2d;hb=refs/heads/master
dave.enyeart (Sat, 04 Feb 2017 21:07:37 GMT):
At the same location you will see a KV impl (leveldb) and a document DB impl (couchdb)
dave.enyeart (Sat, 04 Feb 2017 21:07:37 GMT):
At the same location you will see a subdirectory for a KV impl (leveldb) and a document DB impl (couchdb)
matanyahu (Sat, 04 Feb 2017 22:14:29 GMT):
thanks for all references
guruprasath (Sun, 05 Feb 2017 06:16:28 GMT):
Has joined the channel.
dayubian (Sun, 05 Feb 2017 10:49:33 GMT):
Has joined the channel.
rascal-3 (Sun, 05 Feb 2017 14:44:29 GMT):
Has joined the channel.
schwentker2 (Sun, 05 Feb 2017 15:48:17 GMT):
Has joined the channel.
kkpatel (Sun, 05 Feb 2017 18:03:29 GMT):
Has joined the channel.
openspylin (Sun, 05 Feb 2017 21:44:06 GMT):
Has joined the channel.
openspylin (Sun, 05 Feb 2017 21:45:06 GMT):
One thing I found odd about the hyperledger/...devenv doc. It requires logging into the Docker image (not stated/ref.) as one of your options. Then you can run chaincode commands. What is an efficient way to transfer from the windows to image VM environment, Since I want to create my own chaincode programs and test them; any advise?
openspylin (Sun, 05 Feb 2017 21:45:28 GMT):
Attempting my own setup of Hyperledger on Ubuntu 16.04, I've noticed the chaincode build fails due to a missing package of GO ->"context", must this be installed separately after the main GO installation?
Honglei (Sun, 05 Feb 2017 23:55:05 GMT):
Has joined the channel.
xixuejia (Mon, 06 Feb 2017 00:58:53 GMT):
Has joined the channel.
hanhzf (Mon, 06 Feb 2017 03:36:29 GMT):
Has joined the channel.
bryanhuang (Mon, 06 Feb 2017 04:34:11 GMT):
Has joined the channel.
MadhavaReddy (Mon, 06 Feb 2017 05:07:24 GMT):
Hi All, When i try to run a chain code am getting below error
MadhavaReddy (Mon, 06 Feb 2017 05:07:26 GMT):
2017/02/06 05:06:29 setting Number of procs to -1, was 1
2017/02/06 05:06:29 Failed deploying [%s] open /var/hyperledger/production/crypto/client/jim/ks/raw/eca.cert.chain: no such file or directory
2017/02/06 05:06:29 Failed initiliazing NVP [%s] open /var/hyperledger/production/crypto/client/jim/ks/raw/eca.cert.chain: no such file or directory
MadhavaReddy (Mon, 06 Feb 2017 05:07:41 GMT):
could you please help me to fix the issue
david.peyronnin (Mon, 06 Feb 2017 09:52:37 GMT):
Has joined the channel.
mastersingh24 (Mon, 06 Feb 2017 13:04:24 GMT):
@dave.enyeart - https://jira.hyperledger.org/browse/FAB-2045 - I assume this is due to the fact that we don't support "read your own writes" anymore?
dave.enyeart (Mon, 06 Feb 2017 14:22:14 GMT):
right, I've commented in the Jira item
mastersingh24 (Mon, 06 Feb 2017 14:24:14 GMT):
thanks @dave.enyeart . wanted to make sure that I was not off-base in my response ;)
dave.enyeart (Mon, 06 Feb 2017 14:24:29 GMT):
right, we'll get that into docs
sstone1 (Mon, 06 Feb 2017 14:25:00 GMT):
:+1: thanks for taking a look guys
harrijk (Mon, 06 Feb 2017 15:14:15 GMT):
Has joined the channel.
nhrishi (Mon, 06 Feb 2017 15:14:53 GMT):
Has joined the channel.
klorenz (Mon, 06 Feb 2017 16:06:16 GMT):
Has joined the channel.
mbwhite (Mon, 06 Feb 2017 16:49:34 GMT):
Has joined the channel.
yuki-kon (Mon, 06 Feb 2017 16:53:10 GMT):
Has joined the channel.
pschnap (Mon, 06 Feb 2017 18:54:03 GMT):
Has joined the channel.
weeds (Mon, 06 Feb 2017 20:25:09 GMT):
Has joined the channel.
crazybit (Tue, 07 Feb 2017 05:31:16 GMT):
Has joined the channel.
mbaizan (Tue, 07 Feb 2017 07:44:06 GMT):
Has joined the channel.
vitaly.ilinykh (Tue, 07 Feb 2017 08:41:22 GMT):
Has joined the channel.
gatakka (Tue, 07 Feb 2017 09:28:49 GMT):
Has joined the channel.
Rymd (Tue, 07 Feb 2017 09:30:41 GMT):
Has joined the channel.
passkit (Tue, 07 Feb 2017 10:16:17 GMT):
Has joined the channel.
brianeno (Tue, 07 Feb 2017 10:49:51 GMT):
Has joined the channel.
bart.cant@gmail.com (Tue, 07 Feb 2017 12:13:55 GMT):
Has joined the channel.
XavierLepretre (Tue, 07 Feb 2017 14:30:47 GMT):
Has joined the channel.
kenzhang (Tue, 07 Feb 2017 14:41:35 GMT):
Has joined the channel.
MartinMateev (Tue, 07 Feb 2017 15:09:33 GMT):
Has joined the channel.
cbf (Tue, 07 Feb 2017 15:14:06 GMT):
Has joined the channel.
Tetiana (Tue, 07 Feb 2017 15:18:26 GMT):
Has joined the channel.
mpage (Tue, 07 Feb 2017 15:21:09 GMT):
Has joined the channel.
umasuthan (Tue, 07 Feb 2017 16:04:29 GMT):
Has joined the channel.
cyrax (Tue, 07 Feb 2017 16:07:51 GMT):
Has joined the channel.
troyronda (Tue, 07 Feb 2017 16:32:34 GMT):
Has joined the channel.
nickmelis (Tue, 07 Feb 2017 17:14:10 GMT):
Has joined the channel.
rahulhegde (Tue, 07 Feb 2017 20:44:44 GMT):
Has joined the channel.
beauson45 (Tue, 07 Feb 2017 20:58:05 GMT):
Has joined the channel.
mwall (Tue, 07 Feb 2017 21:16:07 GMT):
Has joined the channel.
thomasmarckx (Tue, 07 Feb 2017 21:53:18 GMT):
Has joined the channel.
mgk (Tue, 07 Feb 2017 22:04:23 GMT):
Has joined the channel.
kongakong (Wed, 08 Feb 2017 01:06:11 GMT):
Has joined the channel.
patchpon (Wed, 08 Feb 2017 01:16:53 GMT):
Has joined the channel.
johnm (Wed, 08 Feb 2017 02:09:34 GMT):
Has joined the channel.
peter (Wed, 08 Feb 2017 02:11:19 GMT):
Has joined the channel.
haidong (Wed, 08 Feb 2017 04:02:57 GMT):
Has joined the channel.
vigneswaran.r (Wed, 08 Feb 2017 04:26:00 GMT):
Has joined the channel.
manish-sethi (Wed, 08 Feb 2017 04:36:19 GMT):
Has joined the channel.
padmaja (Wed, 08 Feb 2017 07:12:08 GMT):
Has joined the channel.
niteshsolanki (Wed, 08 Feb 2017 08:56:20 GMT):
Has joined the channel.
oiakovlev (Wed, 08 Feb 2017 09:06:10 GMT):
Has joined the channel.
jvsteiner (Wed, 08 Feb 2017 11:01:35 GMT):
Has joined the channel.
manish-sethi (Wed, 08 Feb 2017 11:15:56 GMT):
@sstone1, @dave.enyeart, @mastersingh24 - just submitted the CR for fixing the doc. Please have a look - https://gerrit.hyperledger.org/r/#/c/5707/
mastersingh24 (Wed, 08 Feb 2017 11:25:36 GMT):
thx @manish-sethi - reviewing now
cdutra (Wed, 08 Feb 2017 11:30:34 GMT):
Has joined the channel.
Percival Lucena (Wed, 08 Feb 2017 11:39:49 GMT):
Has joined the channel.
dave.enyeart (Wed, 08 Feb 2017 12:01:41 GMT):
@manish-sethi @mastersingh24 there is discussion of re-introducing RYW, let's allow that discussion to play out first
dave.enyeart (Wed, 08 Feb 2017 12:01:41 GMT):
@manish-sethi @mastersingh24 there is discussion of re-introducing RYW for key-based queries, let's allow that discussion to play out first
mastersingh24 (Wed, 08 Feb 2017 12:18:46 GMT):
@dave.enyeart - where's that discussion taking place?
dave.enyeart (Wed, 08 Feb 2017 13:01:15 GMT):
@mastersingh24 Composer team email - Re: FAB-2045 read your own write support
mastersingh24 (Wed, 08 Feb 2017 13:01:49 GMT):
got it - we might want to move the discussion here tho ;)
niteshthakrar (Wed, 08 Feb 2017 14:27:04 GMT):
Has joined the channel.
frank.felhoffer (Wed, 08 Feb 2017 14:34:02 GMT):
Has joined the channel.
chris.elder (Wed, 08 Feb 2017 14:34:11 GMT):
Has joined the channel.
StevenLanders (Wed, 08 Feb 2017 19:15:20 GMT):
Has joined the channel.
warong (Thu, 09 Feb 2017 02:54:31 GMT):
Has joined the channel.
xiejunxi (Thu, 09 Feb 2017 03:28:33 GMT):
Has joined the channel.
bravera (Thu, 09 Feb 2017 10:53:35 GMT):
Has joined the channel.
bravera (Thu, 09 Feb 2017 11:01:39 GMT):
Apologies if this is not the right place to ask this question, but given that each channel has its own ledger, how do you ensure the sequence of transactions that affects the state of an asset that is manipulated in different channels is correct? Is there some overall sequencing that is operating across all channels in the network? (not even sure network is the right term here!)
passkit (Thu, 09 Feb 2017 11:19:19 GMT):
@bravera - I am also interested in this and how one would prove integrity of the ledger (E.g. to an auditor or regulator) in such cases
mastersingh24 (Thu, 09 Feb 2017 11:33:52 GMT):
@bravera @passkit - everything is scoped at the channel level - so the orderer orders transactions and blocks on a per channel basis. The peer has an individual file ledger for each channel (the "hash chain") and state is scoped per channel as well. So the record of an "asset" will only be in a single channel.
passkit (Thu, 09 Feb 2017 11:34:24 GMT):
Great - thanks
bravera (Thu, 09 Feb 2017 11:37:29 GMT):
@mastersingh24 thanks for the response. That surprises me though - if I want to track an asset through a business process where for some transactions I want to have restricted access to the information about the transaction, but elsewhere it is open to a wider group of parties, how do I do that?
bravera (Thu, 09 Feb 2017 11:38:25 GMT):
Instead of 'elsewhere' I should have said 'for other transactions involving the same asset'
jonreid (Thu, 09 Feb 2017 11:44:49 GMT):
Has joined the channel.
mastersingh24 (Thu, 09 Feb 2017 11:48:01 GMT):
@bravera - couple of points:
1) I think we can agree that the existence of an asset (as well as any transactions about/for that asset) must be known to all parties who may transfer / modify the asset
2) This means that the record of the asset MUST only exist in a single ledger (channel)
3) Not sure what type of access control / visibility you are looking for, but there are a few options:
- access control for chaincode methods which change certain attributes of the asset
- perhaps there are only some parties who are allows to update the asset at all - so you could leverage endorsement policies to restrict who is allowed / required to endorse a transaction (others would just commit it)
4) We won't likely allow chaincode to invoke chaincode initially across channels, but it would be possible to use this method to have the asset on one channel but have certain transactions details in another channel
Ch3ck (Thu, 09 Feb 2017 12:46:18 GMT):
Has joined the channel.
bravera (Thu, 09 Feb 2017 13:24:38 GMT):
@mastersingh24 not sure I agree on 1). In the widely 'car lease' example, the original manufacturer of the car does not need to be party to the sales agreement between a dealer and a leasing company, and any subsequent disposal deals the leasing company makes to sell or scrap the car are of no concern of the dealer. This isn't a brilliant example but in any supply chain you would expect that the transactions involving the tracked asset would have numerous different 'interest groups' for all sorts of reasons, not least business sensitivity.
bravera (Thu, 09 Feb 2017 13:24:53 GMT):
I thought this was one of the key reasons for the channel concept
mastersingh24 (Thu, 09 Feb 2017 13:26:33 GMT):
@bravera - there is still only 1 car
mastersingh24 (Thu, 09 Feb 2017 13:26:48 GMT):
you can't have multiple records of the same car
mastersingh24 (Thu, 09 Feb 2017 13:26:56 GMT):
that's the whole point of the blockchain
bravera (Thu, 09 Feb 2017 13:27:24 GMT):
right - but you need to be able to perform multiple different transactions on that 1 car
mastersingh24 (Thu, 09 Feb 2017 13:28:36 GMT):
sure - but channels were not designed to have multiple representations of the car
mastersingh24 (Thu, 09 Feb 2017 13:30:06 GMT):
now you can have the car on a "public" channel. Now you can do transactions about the car on different channels and then you'd use the output of those as input to change the state on the car in the "public" channel. But you can also use a single channel and do things they way you did them in v0.6 as well
bravera (Thu, 09 Feb 2017 13:41:08 GMT):
so that tells me that the asset is represented separately in each channel and is logically linked somehow (CC calling CC, or via external application logic)
juslee (Thu, 09 Feb 2017 14:34:28 GMT):
Has joined the channel.
ruslan.kryukov (Thu, 09 Feb 2017 15:14:01 GMT):
Has joined the channel.
mastersingh24 (Thu, 09 Feb 2017 15:34:24 GMT):
the record is still on a single channel but you can be clever in your chaincode on other channels in terms of agreeing on changes and then (someday) passing that decision via cc to cc invoke or in the interim using the output of that as the input to a transaction against the asset on the channel where it exists
dave.enyeart (Thu, 09 Feb 2017 18:28:45 GMT):
@binhn and I have talked about renaming the various chaincode Getter APIs, to make it more clear that they are in fact Getters. Now is our last chance to update API names which we'll have to live with forever after v1. The proposed changes are:
binhn (Thu, 09 Feb 2017 18:28:45 GMT):
Has joined the channel.
dave.enyeart (Thu, 09 Feb 2017 18:28:55 GMT):
GetState()
RangeQueryState() ==> GetByRange()
PartialCompositeKeyQuery() ==> GetByPartialCompositeKey() …this one is a more usable api for range queries
GetQueryResult() … this one is for the new rich query
dave.enyeart (Thu, 09 Feb 2017 18:32:06 GMT):
@muralisr @mastersingh24 ^^^^^
mastersingh24 (Thu, 09 Feb 2017 19:10:30 GMT):
new names seem ok to me
MikeMayori (Thu, 09 Feb 2017 19:44:20 GMT):
Has joined the channel.
muralisr (Thu, 09 Feb 2017 20:20:06 GMT):
@dave.enyeart `RangeQueryState() ==> GetStateByRange()` better ?
muralisr (Thu, 09 Feb 2017 20:20:13 GMT):
or not ? :-)
dave.enyeart (Thu, 09 Feb 2017 20:42:57 GMT):
I like it @muralisr , that would leave us with:
dave.enyeart (Thu, 09 Feb 2017 20:43:32 GMT):
`GetState()`
`RangeQueryState()` ==> `GetStateByRange()`
`PartialCompositeKeyQuery()` ==> `GetStateByPartialCompositeKey()` …this one is a more usable api for range queries
`GetQueryResult()` … this one is for the new rich query
dave.enyeart (Thu, 09 Feb 2017 20:48:01 GMT):
and very soon I'll also be adding:
dave.enyeart (Thu, 09 Feb 2017 20:48:22 GMT):
`GetHistoryForKey()` ...returns the history of values for a key
mastersingh24 (Thu, 09 Feb 2017 21:01:57 GMT):
GetHistoryForKey returns the historical values for a key? ;)
mastersingh24 (Thu, 09 Feb 2017 21:02:08 GMT):
who would have known?
gregnotso (Thu, 09 Feb 2017 21:47:27 GMT):
Has joined the channel.
dave.enyeart (Thu, 09 Feb 2017 21:50:44 GMT):
@mastersingh24 we finally got one right the first time.
kenzhang (Fri, 10 Feb 2017 00:34:28 GMT):
@dave.enyeart wouldn't `GetHistoryForKey()` ===> `GetHistorybyKey()` give us a more consistent naming?
kenzhang (Fri, 10 Feb 2017 00:34:28 GMT):
@dave.enyeart wouldn't `GetHistoryForKey()` ===> `GetHistoryByKey()` give us a more consistent naming?
dave.enyeart (Fri, 10 Feb 2017 00:37:33 GMT):
In the prior examples 'By' could return multiple keys. I thought 'For' made it more clear that the history API is for exactly one key. I'm open to other votes though.
NIKESHGOGIA (Fri, 10 Feb 2017 07:15:26 GMT):
Has joined the channel.
anandkarwa13 (Fri, 10 Feb 2017 07:23:27 GMT):
Has joined the channel.
nickmelis (Fri, 10 Feb 2017 14:50:00 GMT):
any idea why when querying the keyvaluestore by range, the number of results returned is always capped to 100 maximum? Is there a way to bypass it or configure this limit?
Basug (Fri, 10 Feb 2017 17:17:16 GMT):
Has joined the channel.
UshKrish (Fri, 10 Feb 2017 19:14:23 GMT):
Has joined the channel.
xixuejia (Sat, 11 Feb 2017 01:45:04 GMT):
@fz I guess that might be related to https://gerrit.hyperledger.org/r/#/c/3593/
xixuejia (Sat, 11 Feb 2017 01:49:47 GMT):
@dave.enyeart David, could you do a code review for this change set? Added you to the reviewer list
surabhi (Sat, 11 Feb 2017 18:00:31 GMT):
Has joined the channel.
frankylu (Sun, 12 Feb 2017 00:08:55 GMT):
Has joined the channel.
Shroog AlSaquabi (Sun, 12 Feb 2017 21:53:03 GMT):
Has joined the channel.
eheads (Mon, 13 Feb 2017 05:56:10 GMT):
Has joined the channel.
AdnanC (Mon, 13 Feb 2017 15:25:15 GMT):
Has joined the channel.
s.narayanan (Mon, 13 Feb 2017 15:48:32 GMT):
Has joined the channel.
mastersingh24 (Mon, 13 Feb 2017 17:21:14 GMT):
@dave.enyeart - for the APIs which return a block or transaction, do we actually validate the block or transaction prior to returning it? For example, do we actually check that it is properly linked to the previous block? and in the case of a transactions, I suppose something similar?
dave.enyeart (Mon, 13 Feb 2017 17:43:05 GMT):
@mastersingh24 No verification per se beyond making sure it deserializes into proto successfully
mastersingh24 (Mon, 13 Feb 2017 18:02:56 GMT):
hmm - we might want to add a new requirement for that - not saying we need to do it right away, but seems that we should probably check to make sure we are actually returning a valid block ;)
AdnanC (Mon, 13 Feb 2017 23:13:45 GMT):
I think this channel would be more helpful for these specific questions @rahulhegde . @dave.enyeart maybe you can take a look?
Had couple of questions on the Couch DB Interface looking at the ` fabric / examples/chaincode/go/marbles02/marbles_chaincode.go `
1. Should the composite key created using stub.CreateCompositeKey interface need to be stored on the world state ledger? I see every time a new marble is created a new composite key gets created and stored using stub.PutState.
If this is must - what is significance of storing?
2. What is the use of calling ` CreateCompositeKey ` whenever a new marble is created, shouldn't the previously created index be re-used?
3. Code documents - to avoid Phantom read use RangeQuery instead of Rich Queries. This means Rich Queries as said must be used only for Read-Only operation?
AdnanC (Mon, 13 Feb 2017 23:13:45 GMT):
I think this channel would be more helpful for these specific questions @rahulhegde. @dave.enyeart maybe you can take a look?
Had couple of questions on the Couch DB Interface looking at the ` fabric / examples/chaincode/go/marbles02/marbles_chaincode.go `
1. Should the composite key created using stub.CreateCompositeKey interface need to be stored on the world state ledger? I see every time a new marble is created a new composite key gets created and stored using stub.PutState.
If this is must - what is significance of storing?
2. What is the use of calling ` CreateCompositeKey ` whenever a new marble is created, shouldn't the previously created index be re-used?
3. Code documents - to avoid Phantom read use RangeQuery instead of Rich Queries. This means Rich Queries as said must be used only for Read-Only operation?
dave.enyeart (Mon, 13 Feb 2017 23:24:50 GMT):
@rahulhegde
Answers for 1 and 2: The composite key of "color~name" is only needed if you intend to query based on color. See transferMarblesBasedOnColor() to see how the 'index' is utilized. There is one entry in state for the marble itself which can be queried by marble "name" (single key), and there is one entry in state for the "color~name" index which can be queried by "color~name" or "color" (composite key). Under the covers, key range queries are utilized to find entries starting with "color".
3: That is correct. Rich query is only appropriate for use in read-write transactions if the application can ensure stable result set between simulation time and commit time. That is, no marbles inserted/updated/deleted that would impact the result set. If your application cannot ensure this, then stick with the partial composite key or range query pattern mentioned in #1.
Please read all the code comments in marbles02 chaincode for more details.
rahulhegde (Tue, 14 Feb 2017 01:17:46 GMT):
@dave.enyeart - appreciate the code comments added to the marbles-02
So if the user-chain code fails to add composite-key to the state ledger for few marbles then RangeQuery will effectively not work or If the 'color' of the marble changes (not in this application) then we will have to create a new composite-key and also delete the previous one to make the RangeQuery work correctly?
Wouldn't it have be advisable the update/delete/insert of this composite-key by the peer and at the time of ledger commit rather at user-chain code space which could be error-prone?
Regarding Point 3 -
Does Phantom Read always bother application/user-chaincode using Rich Query? For Example: I may have application which performs a cut-off say on number of bids by changing it's state to accepted (via self-endorsing peer) and there could be more bids added by the time, the same transaction reaches to peer VSCC module. I hope this transaction should ideally be accepted on the Ledger?
rahulhegde (Tue, 14 Feb 2017 01:17:46 GMT):
@dave.enyeart - appreciate the code comments added to the marbles-02
So if the user-chain code fails to add composite-key to the state ledger for few marbles then RangeQuery will effectively not work or If the 'color' of the marble changes (not in this application) then we will have to create a new composite-key and also delete the previous one to make the RangeQuery work correctly?
Wouldn't it have be advisable the update/delete/insert of this composite-key done by the peer and at the time of ledger commit rather at user-chain code space which could be error-prone?
Regarding Point 3 -
Does Phantom Read always bother application/user-chaincode using Rich Query? For Example: I may have application which performs a cut-off say on number of bids by changing it's state to accepted (via self-endorsing peer) and there could be more bids added by the time, the same transaction reaches to peer VSCC module. I hope this transaction should ideally be accepted on the Ledger?
dave.enyeart (Tue, 14 Feb 2017 01:20:21 GMT):
Yes, if 'color' changed, then you would have to 're-index' it (delete the old color~name entry and put the new color~name entry)
dave.enyeart (Tue, 14 Feb 2017 01:21:53 GMT):
The peer doesn't know what combination of fields your chaincode will want to query on, and therefore the chaincode has to maintain its own records for query.
dave.enyeart (Tue, 14 Feb 2017 01:23:10 GMT):
Perhaps chaincode generators would be a future idea, to generate the appropriate chaincode based on a template
dave.enyeart (Tue, 14 Feb 2017 01:27:43 GMT):
On point three, maybe an example will help. At simulation time your rich query may have returned 5 items and you update state of all five items. Between simulation time and commit time, there was another transaction in flight that creates an item that would have been the 6th item in the result set. But the committer doesn't detect this 6th item and only the initial 5 items are updated. The transaction succeeds, but we have missed one. This is a phantom. If the application retries, then the next time it will find the remaining item and update it.
dave.enyeart (Tue, 14 Feb 2017 01:28:47 GMT):
So, either the application has to ensure that no phantoms arrive, or the application has to make multiple attempts to ensure everything is accounted for
dave.enyeart (Tue, 14 Feb 2017 01:31:02 GMT):
Will your application continuously process, and therefore this is not a concern for you?
dave.enyeart (Tue, 14 Feb 2017 01:31:46 GMT):
Would be nice to understand your scenario in more detail. Feel free to ping directly if you prefer.
rahulhegde (Tue, 14 Feb 2017 02:14:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=SSq2BX7MHLNEudFJk) @dave.enyeart
rahulhegde (Tue, 14 Feb 2017 02:14:02 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=SSq2BX7MHLNEudFJk) @dave.enyeart
Right - i need to map how can i use it. Sure - I will reach out in case of more detail.
rahulhegde (Tue, 14 Feb 2017 02:25:43 GMT):
GetQueryResult - are we planning to add index information to this API, that will provide couchDB endpoint to use the appropriate index during rich query execution.
dave.enyeart (Tue, 14 Feb 2017 02:31:36 GMT):
good idea. are you planning to contribute that to v1?
dave.enyeart (Tue, 14 Feb 2017 02:33:09 GMT):
sorry, i read that wrong, i thought you were saying you were planning to add that
dave.enyeart (Tue, 14 Feb 2017 02:33:40 GMT):
design for index creation and exploitation is still todo
rahulhegde (Tue, 14 Feb 2017 02:38:07 GMT):
BTW - we are going to use couch-db as our state ledger.
MadhavaReddy (Tue, 14 Feb 2017 04:13:49 GMT):
Have use case which i got as requirement from team "Record current transactions in a Blockchain as an additional layer, on top of the original database transactions, for Audit and Tracing purposes."
would like hear comments on the design that am going to propose
1) since usecase is only to store transactions in Fabric for audit and tracking purpose, i can write simple chain code for write and query
2) will use table API to store all transactions in table for now its RockDB but later Level DB
3) In the table along with data which i get from application will create couple of column to store block height, hash and timestamp
Please suggest whether this is the right approach or is there any better design, also please help me on below queries
1) I Can get block height, hash and timestamp only when transaction written into blockchain platform so how would i update these details to corresponding records which already inserted into the table
2) Do i need to create separate table to maintain block height, hash and timestamp along with transaction id from original transaction
Appreciate your response, right now am using 0.6 Fabric, please suggest whether can use 0.6 for this use case implementation or 1.0
surabhi (Tue, 14 Feb 2017 06:40:31 GMT):
Hello, how to view data via CouchDB Web interface? As of now I see the values are hashed. Is there a way to see the transaction data?
bluebird88 (Tue, 14 Feb 2017 10:18:07 GMT):
Has joined the channel.
rahulhegde (Tue, 14 Feb 2017 14:58:10 GMT):
@surabhi - If the values are stored as JSON values, use the _utils web interface. Go to 'Run a Query with Mango" ==> "Run Query". This should list down all values.
rahulhegde (Tue, 14 Feb 2017 14:59:18 GMT):
or else use
curl -H "Content-Type:application/json" -X POST http://
rahulhegde (Tue, 14 Feb 2017 14:59:18 GMT):
or else use
curl -H "Content-Type:application/json" -X POST http://
rahulhegde (Tue, 14 Feb 2017 15:24:34 GMT):
@dave.enyeart ` design for index creation and exploitation is still todo `
Do we have list of items that' going to come as part of post- v1.0 Alpha release that will exploit Couch DB functionality (like views)?
dave.enyeart (Tue, 14 Feb 2017 15:28:59 GMT):
First couch release focuses on function. Next set of items include docker image, security lockdown, performance (including indexes).
rahulhegde (Tue, 14 Feb 2017 15:47:36 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=NiLmhtA9ZhKhxXa7m) @dave.enyeart
Can you please share the JIRA Ticket?
rahulhegde (Tue, 14 Feb 2017 15:53:24 GMT):
Other question related to composite-key, we have ` color~name ` as our ObjectType of Composite Key and store composite key alike ' color~name3Red7marble1 ' in state ledger. In order to fetch the Marble JSON, we make use of the composite-key ID and fetch the Index = 1 value i.e. marble1.
Is this the only way to reach to the ` marble1 ` JSON information?
joshhus (Tue, 14 Feb 2017 18:14:08 GMT):
Has joined the channel.
eddie.allen (Tue, 14 Feb 2017 18:35:50 GMT):
Has joined the channel.
dave.enyeart (Tue, 14 Feb 2017 18:45:42 GMT):
@rahulhegde Not completely following the question. In general there are three types of query available: 1) key-based query, 2) key range query (partial composite key query pattern leverages this under the covers), and 3) rich query on data content. #1 and #2 are available with either the default leveldb or couchdb. #3 is only available if you use couchdb.
rahulhegde (Tue, 14 Feb 2017 19:27:05 GMT):
Ok my previous question is on #2.
```
Other question related to composite-key, we have ` color~name ` as our ObjectType of Composite Key and store composite key alike ' color~name3Red7marble1 ' in state ledger. In order to fetch the Marble JSON, we make use of the composite-key ID and fetch the Index = 1 value i.e. marble1.
Is this the only way to reach to the ` marble1 ` JSON information?
```
Following is code written in Marble-02 chaincode to fetch list of all Marbles having Color = Blue ` peer chaincode invoke -C myc1 -n marbles -c '{"Args":["transferMarblesBasedOnColor","blue","jerry"]}' `
Function - transferMarblesBasedOnColor
1. coloredMarbleResultsIterator, err := stub.PartialCompositeKeyQuery("color~name", []string{color})
This will give Iterator to all composite keys starting with "color~name4blueXXXXX..." where XXXX => is the name of the Marble.
2. objectType, compositeKeyParts, err := stub.SplitCompositeKey(colorNameKey)
This splits the composite key into two parts - index = 0 is color which is blue and index = 1 is marble name. This is how we created the composite key using CreateCompositeKey.
3. Now index = 1 = marble_name and is also the key which stores the Marble related meta-data like color, owner, etc sent as part of initMarble Method.
So is it mandatory to make key (in this case marble name) as part of the composite key (marble name, marble color) in order to use key range query OR
Is there a way from the composite-key value to directly point to the marble-meta data (I see following in the composite-key JSON value ` {
"_id": "mycc\u0000color~name\u001f4\u001fcyan\u001f7\u001fmarble5",
"_rev": "1-25e6561da9de20e29564ac15bd5e06fa",
"chaincodeid": "mycc",
"version": "16:1",
"_attachments": {
"valueBytes": {
"content_type": "application/octet-stream",
"revpos": 1,
"digest": "md5-39d1Vgjcpz9ZAAMV2yCR/w==",
"length": 5,
"stub": true
}
}
}` ?
rahulhegde (Tue, 14 Feb 2017 19:27:05 GMT):
Ok my previous question is on #2.
```
Other question related to composite-key, we have ` color~name ` as our ObjectType of Composite Key and store composite key alike ' color~name3Red7marble1 ' in state ledger. In order to fetch the Marble JSON, we make use of the composite-key ID and fetch the Index = 1 value i.e. marble1.
Is this the only way to reach to the ` marble1 ` JSON information?
```
Following is code written in Marble-02 chaincode to fetch list of all Marbles having Color = Blue ` peer chaincode invoke -C myc1 -n marbles -c '{"Args":["transferMarblesBasedOnColor","blue","jerry"]}' `
Function - transferMarblesBasedOnColor
1. coloredMarbleResultsIterator, err := stub.PartialCompositeKeyQuery("color~name", []string{color})
This will give Iterator to all composite keys starting with "color~name4blueXXXXX..." where XXXX => is the name of the Marble.
2. objectType, compositeKeyParts, err := stub.SplitCompositeKey(colorNameKey)
This splits the composite key into two parts - index = 0 is color which is blue and index = 1 is marble name. This is how we created the composite key using CreateCompositeKey.
3. Now index = 1 = marble_name and is also the key which stores the Marble related meta-data like color, owner, etc sent as part of initMarble Method.
So is it mandatory to make key (in this case marble name) as part of the composite key (marble name, marble color) in order to use key range query OR
Is there a way from the composite-key value to directly point to the marble-meta data (I see following in the composite-key JSON value
``` {
"_id": "mycc\u0000color~name\u001f4\u001fcyan\u001f7\u001fmarble5",
"_rev": "1-25e6561da9de20e29564ac15bd5e06fa",
"chaincodeid": "mycc",
"version": "16:1",
"_attachments": {
"valueBytes": {
"content_type": "application/octet-stream",
"revpos": 1,
"digest": "md5-39d1Vgjcpz9ZAAMV2yCR/w==",
"length": 5,
"stub": true
}
}
}
``` ?
rahulhegde (Tue, 14 Feb 2017 19:27:05 GMT):
Ok my previous question is on #2.
```
Other question related to composite-key, we have ` color~name ` as our ObjectType of Composite Key and store composite key alike ' color~name3Red7marble1 ' in state ledger. In order to fetch the Marble JSON, we make use of the composite-key ID and fetch the Index = 1 value i.e. marble1.
Is this the only way to reach to the ` marble1 ` JSON information?
```
Following is code written in Marble-02 chaincode to fetch list of all Marbles having Color = Blue ` peer chaincode invoke -C myc1 -n marbles -c '{"Args":["transferMarblesBasedOnColor","blue","jerry"]}' `
Function - transferMarblesBasedOnColor
1. coloredMarbleResultsIterator, err := stub.PartialCompositeKeyQuery("color~name", []string{color})
This will give Iterator to all composite keys starting with "color~name4blueXXXXX..." where XXXX => is the name of the Marble.
2. objectType, compositeKeyParts, err := stub.SplitCompositeKey(colorNameKey)
This splits the composite key into two parts - index = 0 is color which is blue and index = 1 is marble name. This is how we created the composite key using CreateCompositeKey.
3. Now index = 1 = marble_name and is also the key which stores the Marble related meta-data like color, owner, etc sent as part of initMarble Method.
So is it mandatory to make key (in this case marble name) as part of the composite key (marble name, marble color) in order to use key range query OR
Is there a way from the composite-key value to directly point to the marble-meta data? (I see following in the composite-key JSON value)
``` {
"_id": "mycc\u0000color~name\u001f4\u001fcyan\u001f7\u001fmarble5",
"_rev": "1-25e6561da9de20e29564ac15bd5e06fa",
"chaincodeid": "mycc",
"version": "16:1",
"_attachments": {
"valueBytes": {
"content_type": "application/octet-stream",
"revpos": 1,
"digest": "md5-39d1Vgjcpz9ZAAMV2yCR/w==",
"length": 5,
"stub": true
}
}
}
```
silliman (Tue, 14 Feb 2017 22:31:19 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=FRBnENadZNFwEvCBv) @dave.enyeart Re (3) rich query - would best practice be for chaincode to query an environment variable or by some other means determine whether or not the state database supports rich query, if the goal of chaincode was to support any state database implementation?
dave.enyeart (Tue, 14 Feb 2017 22:35:33 GMT):
In almost every case the chaincode author will know the capabilities for their target environment. If not, then you can attempt a rich query and handle the error if it is not implemented... that is as efficient as readying some other property.
dave.enyeart (Tue, 14 Feb 2017 22:35:33 GMT):
In almost every case the chaincode author will know the capabilities for their target environment. If not, then you can attempt a rich query and handle the error if it is not implemented... that is as efficient as reading some other property.
dave.enyeart (Tue, 14 Feb 2017 22:43:03 GMT):
@rahulhegde It is not mandatory to embed the primary key in the 'index' composite key. There are various options and the best approach depends on the solution requirements - you could embed the primary key in the 'index' composite key, you could have the key in the 'index' record's value, or you could put the actual data that you need there
rnsastry (Wed, 15 Feb 2017 04:33:09 GMT):
Has joined the channel.
gatakka (Wed, 15 Feb 2017 07:19:40 GMT):
Hello,
I have a question about behavior of HL (v.1, not 0.6) when concurrent invocations of chain-code update same state. Simple scenario can be described like this:
In the ledger we have state for 3 parties (A,B,C) and every one of them has 100 tokens. There is a request (using nodejs sdk) to transfer 10 tokens from A to B. If at same time, while this invocation is endorsed, send to orderer and committed to the ledger, there is another request to transfer tokens from A to C, both invocations return success but second transfer is not stored in the ledger.
At the end of this scenario party A will have 90 tokens, party B will have 110, party C will have 100. But invocation for transferring from A to C finish with success.
I understand why this is happening, second invocation read the state of the ledger before first invocation finishes and later when read/write set is send from orderer it is discarded because the state of the ledger is different. But this behavior require application developer to put synchronization logic in layer above HL to track current invocations and parties that are involved so that no two or more invocations that share state are executed concurrently.
This is variation of classical double spending problem but are there any "tools" or "best practices" in HL that can handle this situation, or developer must take care of this?
Is this expected behavior that will be in final production ready version 1, or there are some plans to address this.
Thank you!
dave.enyeart (Wed, 15 Feb 2017 12:36:55 GMT):
This is expected behavior.... client will need to handle transaction invalidations and do error or retry logic. Please post on fabric-sdk channel asking how client gets alerted to invalidations.
gatakka (Wed, 15 Feb 2017 13:43:02 GMT):
@dave.enyeart thank you!
o.o. (Wed, 15 Feb 2017 15:10:20 GMT):
Has joined the channel.
Jonas.Hedin (Wed, 15 Feb 2017 15:15:50 GMT):
Has joined the channel.
murrekatt (Wed, 15 Feb 2017 15:16:16 GMT):
Has joined the channel.
o.o. (Wed, 15 Feb 2017 15:28:30 GMT):
[ nickgaski pointed me here from #fabric ](https://chat.hyperledger.org/channel/fabric?msg=XaXHT4dXnFaSdCHZR)
We had a bit of discussion in the #fabric channel (there are a lot of them!) regarding the purpose of allowing invalid transactions to be stored on the peer ledgers, and why orderers would allow this to happen.
Yacovm explained that it is not the orderers place to validate the business logic results, since this would make them more expensive than they need to be.
I suppose my confusion came from the different kinds of ways transactions can be invalid, and where the _readset_ version correctness would get checked (is in committing).
o.o. (Wed, 15 Feb 2017 15:28:30 GMT):
[ From #fabric ](https://chat.hyperledger.org/channel/fabric?msg=XaXHT4dXnFaSdCHZR)
We had a bit of discussion in the #fabric channel (there are a lot of them!) regarding the purpose of allowing invalid transactions to be stored on the peer ledgers, and why orderers would allow this to happen.
Yacovm explained that it is not the orderers place to validate the business logic results, since this would make them more expensive than they need to be.
I suppose my confusion came from the different kinds of ways transactions can be invalid, and where the _readset_ version correctness would get checked (is in committing).
datajerk (Wed, 15 Feb 2017 17:45:54 GMT):
Has joined the channel.
stanliberman (Wed, 15 Feb 2017 18:12:13 GMT):
Has joined the channel.
sstone1 (Wed, 15 Feb 2017 19:06:35 GMT):
I've got a problem with PartialCompositeKeyQuery; if I add a key using CreateCompositeKey("Vehicle", []string{"VIN_1234"}) and another key using CreateCompositeKey("VehicleListing", []string{"LIST_1234"}), then PartialCompositeKeyQuery("Vehicle", []string{}) returns both of those keys. It should only return the "Vehicle" + "VIN_1234" key right?
salmanbaset (Wed, 15 Feb 2017 22:55:30 GMT):
each peer participating in a channel has its respective ledger. must these peers be under the 'administrative control' of the entities these peers represent, e.g., buyer and seller?
salmanbaset (Wed, 15 Feb 2017 22:58:52 GMT):
or can one entity manage both peers and their ledgers
salmanbaset (Wed, 15 Feb 2017 22:58:52 GMT):
or can one entity manage both peers and their ledgers?
salmanbaset (Wed, 15 Feb 2017 23:08:53 GMT):
my concern is the following: if both buyer peer and seller peer are managed by the same 'administrative entity', then the ledgers can be manipulated
salmanbaset (Wed, 15 Feb 2017 23:08:53 GMT):
my concern is the following: if both buyer peer and seller peer are managed by the same 'administrative entity', then their ledgers can be manipulated
dave.enyeart (Thu, 16 Feb 2017 01:29:47 GMT):
@salmanbaset There would be more assurance if the peers are managed by different entities. Not sure what type of ledger manipulation you are talking about, if you have a specific concern around ledger manipulation please post that to fabric-crypto where the security experts hang out.
dave.enyeart (Thu, 16 Feb 2017 02:13:29 GMT):
@sstone1 I believe you are on a prior build, this has been fixed in later builds. I've added a test case to make sure. See: https://gerrit.hyperledger.org/r/#/c/6080/
dave.enyeart (Thu, 16 Feb 2017 02:13:29 GMT):
@sstone1 I believe you are on a prior build, this has been fixed in later builds. I've added a test case with your example data to make sure. See: https://gerrit.hyperledger.org/r/#/c/6080/
dave.enyeart (Thu, 16 Feb 2017 02:14:25 GMT):
Also note the API name changes in https://gerrit.hyperledger.org/r/#/c/5815/
dave.enyeart (Thu, 16 Feb 2017 02:18:47 GMT):
@o.o. All validation logic is performed on committing peer. The content of the block is not changed if the tran is invalidated, since we want the block hash to be consistent across orderer blocks and peer blocks. The invalid transaction is tagged in a non-hashed part of the block on the committer side, so that later queries for the transaction can indicate that the tran has been invalidated.
dave.enyeart (Thu, 16 Feb 2017 02:20:28 GMT):
There is intent at a later time to add a 'checkpoint' feature that can optionally prune out old blocks and/or invalid trans, which would leave you with a 'validated ledger' only.
bobbiejc (Thu, 16 Feb 2017 03:41:00 GMT):
Has joined the channel.
dave.enyeart (Thu, 16 Feb 2017 04:58:59 GMT):
@vukolic @mastersingh24 @manish-sethi We've all been using the term MVCC for the v1 validation check since I joined the project, but as we document v1 I want to make sure we're using the correct terms. It seems the v1 concurrency model would more accurately be described as Optimistic Concurrency Control (OCC) rather than Multi-version concurrency control (MVCC). Is there a specific reason why the term MVCC was used in the NCAP document? Or do you agree we should use the term Optimistic Concurrency Control in v1 documentation and going forward? For reference:
https://en.wikipedia.org/wiki/Multiversion_concurrency_control
https://en.wikipedia.org/wiki/Optimistic_concurrency_control
vukolic (Thu, 16 Feb 2017 04:58:59 GMT):
Has joined the channel.
mastersingh24 (Thu, 16 Feb 2017 05:09:22 GMT):
@dave.enyeart - I believe that MVCC would be the correct term for v1. I could be wrong here, but I believe that MVCC is actually optimistic concurrency control which may involved 1 or more objects (keys) whereas OCC in and of itself typically deals with a single object / key
dave.enyeart (Thu, 16 Feb 2017 05:21:31 GMT):
@mastersingh24 I have seen that definition of MVCC in some places (and that would surely apply to v1), but most of the literature talks about MVCC in terms of multiple versions of an object in the database that are visible to different clients depending on transaction lifecycle/snapshots, which we really dont have in v1 - the state db makes available a single version at any given point in time.
dave.enyeart (Thu, 16 Feb 2017 05:21:31 GMT):
@mastersingh24 I have seen that definition of MVCC in some places (and that would surely apply to v1), but most of the literature talks about MVCC in terms of multiple versions of an object in the database that are visible to different clients clients depending on transaction lifecycle/snapshots, which we really dont have in v1 - the state db makes available a single version at any given point in time.
dave.enyeart (Thu, 16 Feb 2017 05:21:31 GMT):
@mastersingh24 I have seen that definition of MVCC in some places (and that would surely apply to v1), but most of the literature talks about MVCC in terms of multiple versions of an object in the database that are visible to different clients concurrently depending on transaction lifecycle/snapshots, which we really dont have in v1 - the state db makes available a single version at any given point in time.
mastersingh24 (Thu, 16 Feb 2017 05:23:13 GMT):
so we aren't quite MVCC and we are "stronger" than OCC
dave.enyeart (Thu, 16 Feb 2017 05:27:03 GMT):
let's invent a term for it :)
manish-sethi (Thu, 16 Feb 2017 06:01:30 GMT):
@mastersingh24 @dave.enyeart OCC is not limited to a single item. The basic difference is that MVCC allows certain transaction schedules which would have been not been valid in single versioned DB - because, MVCC maintains multiple versions.
I was thinking of maintaining multiple versions for a consistent snapshot for read queries at least, assuming we implement snapshot isolation based on height based versioning...
About the term for our purpose - OCC is a more generic term and can work with or without multiple versions. At the same time there are lock based protocol for MVCC... so we are kind of in the middle :-)
manish-sethi (Thu, 16 Feb 2017 06:01:30 GMT):
@mastersingh24 @dave.enyeart OCC is not limited to a single item. The basic difference is that MVCC allows certain transaction schedules which would have not been valid in single versioned DB - because, MVCC maintains multiple versions.
I was thinking of maintaining multiple versions for a consistent snapshot for read queries at least, assuming we implement snapshot isolation based on height based versioning...
About the term for our purpose - OCC is a more generic term and can work with or without multiple versions. At the same time there are lock based protocol for MVCC... so we are kind of in the middle :-)
manish-sethi (Thu, 16 Feb 2017 06:15:36 GMT):
To take a concrete example.. in a single db consider the following sequences of two concurrent transactions
`Tx1Read(x) Tx1Write(x) Tx2Read(x) Tx2Write(y) Tx1Read(y) Tx1Write(z) Tx1commit Tx2commit`
Now, there no possible serializable history (i.e. whether Tx1 happened before Tx2 or other way around).
However, if the db is multi-versioned and in the fifth step the db would have returned the previous version for item `y`, the serializable schedule could be equivalent to as if Tx1 happened before Tx2.
manish-sethi (Thu, 16 Feb 2017 06:15:36 GMT):
To take a concrete example.. in a single db, consider the following sequences of two concurrent transactions
`Tx1Read(x) Tx1Write(x) Tx2Read(x) Tx2Write(y) Tx1Read(y) Tx1Write(z) Tx1commit Tx2commit`
Now, there no possible serializable history (i.e. whether Tx1 happened before Tx2 or other way around).
However, if the db is multi-versioned and in the fifth step the db would have returned the previous version for item `y`, the serializable schedule could be equivalent to as if Tx1 happened before Tx2.
manish-sethi (Thu, 16 Feb 2017 06:15:36 GMT):
To take a concrete example.. in a single db, consider the following sequences of two concurrent transactions
`Tx1Read(x) Tx1Write(x) Tx2Read(x) Tx2Write(y) Tx1Read(y) Tx1Write(z) Tx1commit Tx2commit`
Now, there no possible serializable history (i.e. whether Tx1 happened before Tx2 or other way around).
However, if the db is multi-versioned and in the fifth step, the db would have returned the previous version for item `y`, the serializable schedule could be equivalent to as if Tx1 happened before Tx2.
manish-sethi (Thu, 16 Feb 2017 06:15:36 GMT):
To take a concrete example.. in a single db, consider the following sequences of two concurrent transactions
`Tx1Read(x) Tx1Write(x) Tx2Read(x) Tx2Write(y) Tx1Read(y) Tx1Write(z) Tx1commit Tx2commit`
Now, there is no possible serializable history (i.e. whether Tx1 happened before Tx2 or other way around).
However, if the db is multi-versioned and in the fifth step, the db would have returned the previous version for item `y`, the serializable schedule could be equivalent to as if Tx1 happened before Tx2.
manish-sethi (Thu, 16 Feb 2017 06:15:36 GMT):
To take a concrete example.. in a single db, consider the following sequences of two concurrent transactions
`Tx1Read(x) Tx1Write(x) Tx2Read(x) Tx2Write(y) Tx1Read(y) Tx1Write(z) Tx1commit Tx2commit`
Now, there is no possible serializable history in the case of single versioned db (i.e. whether Tx1 happened before Tx2 or other way around).
However, if the db is multi-versioned and in the fifth step, the db would have returned the previous version for item `y`, the serializable schedule could be equivalent to as if Tx1 happened before Tx2.
manish-sethi (Thu, 16 Feb 2017 06:15:36 GMT):
To take a concrete example.. in a single db, consider the following sequences of two concurrent transactions
`Tx1Read(x) Tx1Write(x) Tx2Read(x) Tx2Write(y) Tx1Read(y) Tx1Write(z) Tx1commit Tx2commit`
Now, there is no possible serializable history in the case of single versioned db (i.e. whether Tx1 happened before Tx2 or other way around).
However, if the db is multi-versioned and in the fifth step, the db would have returned the previous version for item `y` (i.e., the previous latest value before Tx2 wrote the newer version in step 4), the serializable schedule could be equivalent to as if Tx1 happened before Tx2.
manish-sethi (Thu, 16 Feb 2017 06:20:52 GMT):
So, in our context we could extend our validation to have this MVCC variation of serialization... but requires more thinking and experimentation for pro/cons.. because there is a cost of maintaining multiple versions (the need to be recycled when no transaction could be using them any more).
manish-sethi (Thu, 16 Feb 2017 06:20:52 GMT):
So, in our context we could extend our validation to have this MVCC variation of serialization... but requires more thinking and experimentation for pro/cons.. because there is a cost of maintaining multiple versions (they need to be recycled when no transaction could be using them any more).
manish-sethi (Thu, 16 Feb 2017 06:20:52 GMT):
So, in our context we could extend our validation to have this MVCC variation of serialization... but requires more thinking and experimentation for pro/cons.. because there is a cost of maintaining multiple versions (they need to be recycled when no transaction could be using them any more - similar to garbage collection).
manish-sethi (Thu, 16 Feb 2017 06:22:40 GMT):
@mastersingh24 @dave.enyeart ^^^^
sstone1 (Thu, 16 Feb 2017 08:12:18 GMT):
@dave.enyeart thanks, I did wonder if that was the case. I am trying to get up and running on the latest Docker images.
manish-sethi (Thu, 16 Feb 2017 08:20:37 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=fusbekfd23GxNZ6cA) @dave.enyeart, @rahulhegde - I would recommend to include your primary key in the composite key as the last part. As Dave pointed out, this is not a requirement but at the same time, requirement is that the composite key should be unique and adding the primary key would fulfill that requirement.
manish-sethi (Thu, 16 Feb 2017 08:22:30 GMT):
@sstone1 can you confirm with your test on the latest build. What surprises me is that as far as I recall, in none of the builds this behavior should have been present... unless I am missing something.
manish-sethi (Thu, 16 Feb 2017 08:22:30 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=c5vnNH9pKL5AMi9XK) @sstone1 can you confirm with your test on the latest build. What surprises me is that as far as I recall, in none of the builds this behavior should have been present... unless I am missing something.
manish-sethi (Thu, 16 Feb 2017 08:38:55 GMT):
@sstone1, @dave.enyeart - sorry for the confusion. Just looked at the older code. Yes, this would have happened with the immediate previous version in this special case where only objectType is being used for searching.
sstone1 (Thu, 16 Feb 2017 09:15:45 GMT):
@manish-sethi just tried on the latest build, it is working OK now, thanks!
wutongtree (Thu, 16 Feb 2017 09:53:04 GMT):
Has joined the channel.
alviontaran (Thu, 16 Feb 2017 16:19:57 GMT):
Has joined the channel.
rahulhegde (Thu, 16 Feb 2017 18:21:48 GMT):
@dave.enyeart
Q: Rich query Interface (GetQueryResult) will result in sending a selector query to the Couch DB. This will return a result-set (say 10 entries). Will this result-set be part of the ReadSet directly (10 entries) or is when the chain-code calls the resultsIterator.Next API, that is the time call-by-call it will be added to the read-set?
dave.enyeart (Thu, 16 Feb 2017 18:25:44 GMT):
@rahulhegde Currently all the results get added to readset, but we are investigating ways to scope it to the results actually read by chaincode
dave.enyeart (Thu, 16 Feb 2017 18:26:05 GMT):
Do you have a strong preference for the latter?
rahulhegde (Thu, 16 Feb 2017 18:28:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=kTvGcjBzMSzxWt5Za) @dave.enyeart
rahulhegde (Thu, 16 Feb 2017 18:28:43 GMT):
[ ](https://chat.hyperledger.org/ nt/fabric-ledger?msg=kTvGcjBzMSzxWt5Za) @dave.enyeart not exactly at this point of time, this just came as all resultset may not really required to be under mvcc check.
rahulhegde (Thu, 16 Feb 2017 18:28:43 GMT):
[ ](https://chat.hyperledger.org/ nt/fabric-ledger?msg=kTvGcjBzMSzxWt5Za) @dave.enyeart not exactly at this point of time, this just came in as all resultset may not really required to be under mvcc check.
dave.enyeart (Thu, 16 Feb 2017 18:34:49 GMT):
right
bobbiejc (Thu, 16 Feb 2017 20:14:14 GMT):
@AdnanC thought I would post my problems here for benefit of all..
bobbiejc (Thu, 16 Feb 2017 20:14:16 GMT):
bobbiejc 10:48 PM
I am trying to enable couchdb option with the hackfest images with channels. I'm following these instructions : http://hyperledger-fabric.readthedocs.io/en/latest/gettingstarted
I am trying to use the modified docker_couchdb.yml file from here: https://jira.hyperledger.org/browse/FAB-1953
I see this error in the log.txt file on cli
>>> 2017-02-16 02:55:58.727 UTC [msp] Sign -> DEBU 028 Sign: digest: 388510939AF7C1A93D771D5D9CFE49F3B3C928B97006E4
7E0C9DD0B591253C6C
Error: proposal failed (err: rpc error: code = 2 desc = Get http://couchdb0:5984/myc1: dial tcp 172.19.0.3:5984: getso
ckopt: connection refused)
Usage:
peer channel join [flags]
bobbiejc 10:59 PM
i would attach my docker compose files, but I can't seem to share files using rocketchat?
ylsGit (Fri, 17 Feb 2017 02:28:55 GMT):
Has joined the channel.
zhangzhen (Fri, 17 Feb 2017 03:09:09 GMT):
Has joined the channel.
RajkumarNatarajan (Fri, 17 Feb 2017 03:58:03 GMT):
Has joined the channel.
kostas (Fri, 17 Feb 2017 16:20:06 GMT):
Has joined the channel.
farhan3 (Fri, 17 Feb 2017 16:21:18 GMT):
Has joined the channel.
farhan3 (Fri, 17 Feb 2017 16:21:35 GMT):
Hi - From the peer yaml file, I can see that the state is stored in a database, e.g. CouchDB. Is the ledger also stored in the same database?
mwall (Fri, 17 Feb 2017 16:53:51 GMT):
Hello! How can I handle this `panic: Own checkpoint for seqNo 30 (CAsSQIpPFvKebFWy+m2TAdP7aTd81EC3AJo6sSU5TgG4xq3+bH74yJxkYDZzHQmQEpyl9hTrtl6Uqa004oFNTZtFG0AaQMcwvg2v92PjvmzVXH3KoPBNvGnPJAeBbivC6EKWSWQIVfTcJUAf1v+AkBxX77MQetWpLWTvx7riohEPPuhOOHk=) different from weak checkpoint certificate (CAsSQAlFXxAlQbHSQicJBptYJQTa2pgfTRuP5cPMbPY8hmNAlIMDj9kRgouWRddx7AAryuf92OD4QoC/gAxnlsxnx+MaQOYL4z+XcjXGbTCxcmAcd2XPFOK1sQHDTm1FJinLjmIeWEt+xlTspwUXhUGrG5AhzmXBsW39rDBqmouHoYfg84o=)`?
dave.enyeart (Fri, 17 Feb 2017 16:59:58 GMT):
@farhan3 Please see the ledger charts in https://jira.hyperledger.org/browse/FAB-758 to understand the ledger data structure
kostas (Fri, 17 Feb 2017 17:01:03 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=waC5vyQdqjc6sPfkH) @mwall (I'm on this in #fabric)
farhan3 (Fri, 17 Feb 2017 17:10:10 GMT):
@dave.enyeart Thanks! So from slide 3, it mentions File system/LevelDB would be used. If the number of blocks gets really large, won't the peer system's available space be a limiting factor?
farhan3 (Fri, 17 Feb 2017 17:10:10 GMT):
@dave.enyeart Thanks! So from slide 3, it mentions File system/LevelDB would be used. If the number of blocks gets really large, won't the peer system's available disk space be a limiting factor?
mcoblenz (Fri, 17 Feb 2017 18:43:07 GMT):
Has joined the channel.
mcoblenz (Fri, 17 Feb 2017 18:44:03 GMT):
Is there support in 1.0 for cross-chaincode transactions? The architecture document says no, but Go example 5 suggests yes.
mcoblenz (Fri, 17 Feb 2017 18:45:29 GMT):
(I'm referring to this; is it up to date? https://github.com/hyperledger/fabric/blob/master/proposals/r1/Next-Consensus-Architecture-Proposal.md)
MadhavaReddy (Fri, 17 Feb 2017 19:40:22 GMT):
Hi All, how would i see the complete ledger for a chain code in 1.0, i tested example 02 chain code with multiple invokes now want to see complete ledger for this chain code
MadhavaReddy (Fri, 17 Feb 2017 19:40:40 GMT):
am in peero "/var/hyperledger/production/ledgersData/historyLeveldb" path
MadhavaReddy (Fri, 17 Feb 2017 19:41:02 GMT):
but don't see any data please help me see the completed ledger
bobbiejc (Sat, 18 Feb 2017 01:16:55 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=hqZbRsbEb8NbMvSNA) @mcoblenz I am curious too
jsong1230 (Sat, 18 Feb 2017 08:29:01 GMT):
Has joined the channel.
mastersingh24 (Sat, 18 Feb 2017 09:56:18 GMT):
@mcoblenz @bobbiejc - you can only do read-only cc to cc communications
ecb (Sat, 18 Feb 2017 12:27:25 GMT):
Has joined the channel.
dave.enyeart (Sat, 18 Feb 2017 15:43:59 GMT):
@farhan3 if you need more disk capacity than can fit in the server then you'd likely move up to Direct Attached Storage (DAS) solutions that can handle massive data. Note that there is intent to provide a prune capability in the future, to prune out blocks older than a certain threshold.
Vadim (Sat, 18 Feb 2017 16:31:25 GMT):
Has joined the channel.
rahulhegde (Sun, 19 Feb 2017 23:18:35 GMT):
@dave.enyeart - Can you confirm recently added GetHistoryForKey API is not meant to detect any version changes to the key between simulation and committing time?
vdods (Sun, 19 Feb 2017 23:47:16 GMT):
Has joined the channel.
dave.enyeart (Mon, 20 Feb 2017 00:34:00 GMT):
@rahulhegde Fabric does not check for changes to the history between simulation and commit time. GetHistoryForKey was intended for read-only information. Do you need to use historical information as part of update transactions?
rahulhegde (Mon, 20 Feb 2017 03:02:15 GMT):
@dave.enyeart - 2 parts - ` Do you need to use historical information as part of update transactions ` - Yes, but will be handling it in a different way by pausing the transaction at the client side thus preventing update on key until we get block-trasaction from Fabric.
2nd part - since we were not sure how various version would be available, thanks for providing GetHistoryForKey now. We are currently planning to store at single version so it would be available always on first version.
Can we please get (JIRA) what is going to be added to shim for convenient access to state ledger.
rahulhegde (Mon, 20 Feb 2017 03:02:15 GMT):
@dave.enyeart
1. I had question on use of GetStateByPartialCompositeKey, can use marble02 as user chaincode for understanding my question
If I have composite-key with pattern ` color~size~name ` and want to retrieve marbles with size = X, how do I write my GetStateByPartialCompositeKey key call (` GetStateByPartialCompositeKey (indexName, [] string {size} ` ) or I need to create a new composite key with say 'size~name'?
2. Is using ~ a best practice as a separator for index name?
3. Is there a limitation on the size of the value part that gets created during Composite Key call (` CreateCompositeKey() `). I see from the couch DB _utils interface, length parameter gets added
dave.enyeart (Mon, 20 Feb 2017 03:34:41 GMT):
@rahulhegde I don't know of anything else that will be going into golang shim. v1 data patterns are demonstrated in marbles02 chaincode example. If you are asking about Java shim, it lags behind golang shim but same function is intended as golang shim. Maybe I'm not understanding the question though.
Vadim (Mon, 20 Feb 2017 09:11:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=3JK8yzq6SWes8RjFz) Hi @dave.enyeart, are there any plans to change this behavior? I see that it would be hard to process transactions because they became invalid. I could imagine a case when there are a lot of transactions that modify some account balance. Currently, only one such transaction will be valid per block and as I understand you, the other transactions will need to be submitted over and over again. This congests the client application and slows down the processing significantly.
mastersingh24 (Mon, 20 Feb 2017 12:53:34 GMT):
(https://chat.hyperledger.org/channel/fabric?msg=kpEJbN99adyRqTP5n) @dave.enyeart @manish-sethi @thojest
mastersingh24 (Mon, 20 Feb 2017 12:53:34 GMT):
[any issues with floating point numbers being stored in the ledger?](https://chat.hyperledger.org/channel/fabric?msg=kpEJbN99adyRqTP5n) @dave.enyeart @manish-sethi @thojest
thojest (Mon, 20 Feb 2017 12:53:34 GMT):
Has joined the channel.
thojest (Mon, 20 Feb 2017 12:54:50 GMT):
@mastersingh24 i was asking this question, because having a look at the column definitions it seems that they only support integers
mastersingh24 (Mon, 20 Feb 2017 12:55:57 GMT):
ah - well in the PutState case, values are encoded as bytes so I don't think there should be an issue
mastersingh24 (Mon, 20 Feb 2017 12:56:47 GMT):
but @manish-sethi can surely tell us the reality ;)
manish-sethi (Mon, 20 Feb 2017 13:01:46 GMT):
@thojest
- if you use leveldb, the value is a []byte that one can put any custom encoding (int/float/json etc.).
- If you use couchdb, the value can be a json and in that I think that couch supports floats as field value.... @dave.enyeart can confirm on restriction on couch or you may like to check couchdb documentation.
- If you use, compositeKeyApis (that works on top of both of these dbs), you would have to store numbers (ints/floats) as utf strings (e.g., "5", "2.7").
thojest (Mon, 20 Feb 2017 13:06:38 GMT):
@mastersingh24 @manish-sethi thx alot!
dave.enyeart (Mon, 20 Feb 2017 17:18:10 GMT):
@thejost yes when using couchdb you can have floats or integers in your json
dave.enyeart (Mon, 20 Feb 2017 17:18:10 GMT):
@thejest yes when using couchdb you can have floats or integers in your json
dave.enyeart (Mon, 20 Feb 2017 17:18:10 GMT):
@thojest jest yes when using couchdb you can have floats or integers in your json
dave.enyeart (Mon, 20 Feb 2017 17:18:10 GMT):
@thojest yes when using couchdb you can have floats or integers in your json
dave.enyeart (Mon, 20 Feb 2017 17:24:51 GMT):
@Vadim conflict detection/invalidation must be enforced by the fabric, otherwise you would have no data integrity (e.g. double spends). In 0.6 all transactions were executed sequentially. In v1 transactions can be executed (simulated) in parallel although conflicts will get invalidated. This results in net higher throughput. The application needs to be designed such that conflicts are minimized however.
dave.enyeart (Mon, 20 Feb 2017 17:28:54 GMT):
This is just one type of invalidation. There are other types of invalidation as well (e.g. endorsement policy not met, dup tx id), therefore all application clients will need to be designed to handle errors/retries.
Senthil1 (Tue, 21 Feb 2017 05:22:11 GMT):
Has joined the channel.
openspylin (Tue, 21 Feb 2017 20:49:05 GMT):
I have noticed that when I code and use REST API, my init & invoke functions( with loops to insert/retrieve an array of JSON objects using the putstate/getstate commands) produce a panic error "index out of range". What symptom of a problem am I seeing?
rahulhegde (Tue, 21 Feb 2017 21:21:39 GMT):
@dave.enyeart
1. I had question on use of GetStateByPartialCompositeKey, can use marble02 as user chaincode for understanding my question
If I have composite-key with pattern ` color~size~name ` and want to retrieve marbles with size = X, how do I write my GetStateByPartialCompositeKey key call (` GetStateByPartialCompositeKey (indexName, [] string {size} ` ) or I need to create a new composite key with say 'size~name'?
2. Is using ~ a best practice as a separator for index name?
3. Is there a limitation on the size of the value part that gets created during Composite Key call (` CreateCompositeKey() `). I see from the couch DB _utils interface, length parameter gets added
dave.enyeart (Tue, 21 Feb 2017 22:10:53 GMT):
@rahulhegde
1) You would need a new composite key like size~name
2) Index name can be anything that is unique relative to other objectTypes/indexNames (and most not contain null character). For demonstration purpose it was just helpful to have indexName match composite key with a visual separator like ~
3) No limit on size of key as far as I can tell. Size of value in CouchDB is based on couch config option max_document_size
4) Right... if you have the entire key, you should simply do GetState(), not GetStateByPartialCompositeKey()
dave.enyeart (Tue, 21 Feb 2017 22:10:53 GMT):
@rahulhegde
1) You would need a new composite key like size~name
2) Index name can be anything that is unique relative to other objectTypes/indexNames (and must not contain null character). For demonstration purpose it was just helpful to have indexName match composite key with a visual separator like ~
3) No limit on size of key as far as I can tell. Size of value in CouchDB is based on couch config option max_document_size
4) Right... if you have the entire key, you should simply do GetState(), not GetStateByPartialCompositeKey()
dave.enyeart (Tue, 21 Feb 2017 22:10:53 GMT):
@rahulhegde
1) You would need a new composite key like size~name
2) Index name can be anything that is unique relative to other objectTypes/indexNames (and must not contain null character). For demonstration purpose it was just helpful to have indexName match composite key with a visual separator like ~
3) No limit on size of key as far as I can tell. Size of value in CouchDB is based on couch config option max_document_size
4) Right... if you have the entire key, you should simply do GetState(), not GetStateByPartialCompositeKey(). You can still use CreateCompositeKey() to create the key to be used in GetState()
dave.enyeart (Tue, 21 Feb 2017 22:11:34 GMT):
Note that the composite key encoding has changed a little bit from what you pasted in 3, but that is transparent to the user
rahulhegde (Wed, 22 Feb 2017 00:35:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=mAqPN3bQ5jQdWBQcq) @dave.enyeart Thank you.
psa (Wed, 22 Feb 2017 13:06:26 GMT):
Has joined the channel.
openspylin (Wed, 22 Feb 2017 15:24:08 GMT):
In the Marbles chaincode, how is the marbleindexstr variable being used as an index, how is it organizing entries?
openspylin (Wed, 22 Feb 2017 15:25:39 GMT):
Has anyone attempted a search efficiency analysis of the blockchain and what about search times within transactions records?
dave.enyeart (Wed, 22 Feb 2017 18:02:24 GMT):
@openspylin The ledger state database uses a B-Tree to store keys/values (this is true for both leveldb and couchdb). These are the same data structures used in many traditional database indexes. Performance will therefore be similar to a traditional database index - very efficient for range queries and partial composite key queries (which use range queries against the B-Tree under the covers)
dave.enyeart (Wed, 22 Feb 2017 23:24:37 GMT):
@mastersingh24 @binhn @muralisr I've spoken to @cca88 and @manish-sethi - we concluded that terms such as MVCC and OCC (optimistic concurrency control) are both not exactly correct for fabric, and are overloaded themselves. Therefore they are just as likely to be misleading as helpful. Therefore in docs we'll simply describe the fabric concurrency control approach without using terms such as MVCC. Just FYI for your customer interactions and external facing charts.
dave.enyeart (Wed, 22 Feb 2017 23:24:37 GMT):
@mastersingh24 @binhn @muralisr I've spoken to @cca88 and @manish-sethi - we concluded that terms such as MVCC and OCC (optimistic concurrency control) are both not exactly correct for fabric, and are overloaded themselves. Therefore they are just as likely to be misleading as helpful. Therefore in docs we'll simply describe the fabric concurrency control approach without using terms such as MVCC. Just FYI for your community interactions and external facing charts.
dave.enyeart (Wed, 22 Feb 2017 23:24:55 GMT):
I've given doc team the following description, we can fine tune as needed:
dave.enyeart (Wed, 22 Feb 2017 23:24:59 GMT):
Hyperledger fabric has concurrency control whereby transactions execute in parallel (by endorsers) to increase throughput, and upon commit (by all peers) each transaction is verified to ensure that no other transaction has modified data it has read. In other words, it ensures that the data that was read during chaincode execution has not changed since execution (endorsement) time, and therefore the execution results are still valid and can be committed to the ledger. If the data that was read has changed then the transaction in the block is marked as invalid and is not applied to the ledger state database.
dave.enyeart (Wed, 22 Feb 2017 23:24:59 GMT):
```Hyperledger fabric has concurrency control whereby transactions execute in parallel (by endorsers) to increase throughput, and upon commit (by all peers) each transaction is verified to ensure that no other transaction has modified data it has read. In other words, it ensures that the data that was read during chaincode execution has not changed since execution (endorsement) time, and therefore the execution results are still valid and can be committed to the ledger. If the data that was read has changed then the transaction in the block is marked as invalid and is not applied to the ledger state database.```
cca88 (Thu, 23 Feb 2017 07:48:43 GMT):
OK, good. I would change from
"then the transaction in the block is marked as invalid and is not applied"
to
"then the transaction in the block is **aborted and ** not applied"
because this is more in line with database terminology. and "invalid" might mean other things in blockchain context, where "validation" is a key concept but not for this.
dave.enyeart (Thu, 23 Feb 2017 13:46:06 GMT):
Hi Christian, for the target audience I think the term abort would be too harsh, as that is often associated with a process panic/termination, whereas in this case the transaction actually gets posted to the chain, it's simply marked as being invalidated.
cca88 (Thu, 23 Feb 2017 14:17:01 GMT):
... well i'd still say "aborted due to a conflict" just like its cousin transaction in a database. the essence is the same of course, "it is not applied"
aambati (Thu, 23 Feb 2017 15:17:04 GMT):
Has joined the channel.
vukolic (Fri, 24 Feb 2017 00:08:00 GMT):
I tend to lead on the invalid here (my 2c)
vukolic (Fri, 24 Feb 2017 00:08:00 GMT):
I tend to lean on the invalid here (my 2c
vukolic (Fri, 24 Feb 2017 00:08:00 GMT):
I tend to lean on the invalid here (my 2c)
vukolic (Fri, 24 Feb 2017 00:08:36 GMT):
just for legacy - I am not sure we ever said abort so far - anywhere
vukolic (Fri, 24 Feb 2017 00:09:33 GMT):
abort would indeed be the right DB parlance
vukolic (Fri, 24 Feb 2017 00:20:57 GMT):
thnking more about it
vukolic (Fri, 24 Feb 2017 00:21:19 GMT):
ordered tx can fail (be invalid) for two reasons
vukolic (Fri, 24 Feb 2017 00:21:34 GMT):
MVCC or endorsement validation
vukolic (Fri, 24 Feb 2017 00:21:41 GMT):
maybe we need two names for those
vukolic (Fri, 24 Feb 2017 00:21:54 GMT):
these would be then be "abort" and "invalid", respectively
vukolic (Fri, 24 Feb 2017 00:22:42 GMT):
if we just say invalid - one cannot easily tell is this due to version numbers or endorsement policy
CarlXK (Fri, 24 Feb 2017 02:05:26 GMT):
Has joined the channel.
cca88 (Fri, 24 Feb 2017 08:23:06 GMT):
or "conflicted and filtered out" is the term we use in the V1-arch doc
slender (Sat, 25 Feb 2017 00:44:20 GMT):
Has joined the channel.
PushpalathaHiremath (Mon, 27 Feb 2017 06:39:13 GMT):
Has joined the channel.
MadhavaReddy (Mon, 27 Feb 2017 13:30:33 GMT):
Hi, in 0.6 i used to see blocks information using the restAPI which is running on 7050 port, in v1.0 can use same port to see the blocks information or is this has been changed, could you please clarify?
weeds (Mon, 27 Feb 2017 13:36:39 GMT):
@varadatibm Varad can you help @MadhavaReddy since I know you were looking for same thing, yes?
varadatibm (Mon, 27 Feb 2017 13:36:39 GMT):
Has joined the channel.
MadhavaReddy (Mon, 27 Feb 2017 13:37:30 GMT):
Thanks @weeds will connect Varad
dave.enyeart (Mon, 27 Feb 2017 16:50:43 GMT):
@MadhavaReddy In v1 there is no REST API on peer. Access is via more secured SDK now. There is Query System Chaincode where your client can use normal chaincode invoke approach get access functions like GetChainInfo() and GetBlockByNumber(). These are also being wrapped by SDK as client-friendly SDK functions, which I think is what Varad is using.
dave.enyeart (Mon, 27 Feb 2017 16:50:43 GMT):
@MadhavaReddy In v1 there is no REST API on peer. Access is via more secured SDK now. There is Query System Chaincode where your client can use normal chaincode invoke approach to access functions like GetChainInfo() and GetBlockByNumber(). These are also being wrapped by SDK as client-friendly SDK functions, which I think is what Varad is using.
MadhavaReddy (Mon, 27 Feb 2017 19:26:05 GMT):
Thanks you @dave.enyeart, is there any built in function which will return block information as soon as the transaction is committed into ledger?
dave.enyeart (Mon, 27 Feb 2017 19:29:26 GMT):
There is an event generated for every block. @pmullaney where can we point people to understand the block and tran events?
pmullaney (Mon, 27 Feb 2017 19:29:26 GMT):
Has joined the channel.
s.narayanan (Mon, 27 Feb 2017 20:15:08 GMT):
A question on the ledger architecture described in https://jira.hyperledger.org/browse/FAB-758. As per Slide #3, Blockchain transaction log is stored as a file and state database can be LevelDB or CouchDB. Does the state database store both the current state and historical record of transactions (that exist in the Blockchain)? In addition, the diagram refers to history index and block index. Appreciate clarification on what these indices mean and how the data in State database links to the Blockchain transaction log. Thanks.
dave.enyeart (Mon, 27 Feb 2017 21:26:25 GMT):
@s.narayanan State database does not store historical values, only current state per key. The history index in LevelDB stores the block/tran index for each key update, to support GetHistoryForKey() API. The block index in LevelDB has block storage location per block/tran, to support APIs such as GetBlockByNumber() and GetTransactionById() without having to scan the blockchain.
s.narayanan (Mon, 27 Feb 2017 23:19:03 GMT):
@dave.enyeart Thanks. To clarify then, associated with each key is an history index that stores the block/tran that caused the key update. Iterating through this history index one can retrieve the history for the key. Going through the code (and I may be looking in the wrong place), I noticed mention of history db. Is there an option to maintain a history database in addition to the state database?
dave.enyeart (Mon, 27 Feb 2017 23:20:41 GMT):
no option to store history of values in a db. that is a potential future direction. GetHistoryForKey() will return the history of values.
dave.enyeart (Mon, 27 Feb 2017 23:21:11 GMT):
what is the use case? i assume you are interested in querying against all historic values?
s.narayanan (Mon, 27 Feb 2017 23:26:34 GMT):
yes, provenance is the main requirement which should be satisfied by GetHistoryForKey() ...
rahulhegde (Tue, 28 Feb 2017 00:10:34 GMT):
@dave.enyeart
Our chaincode unit test cases has used MockStub however now for rich queries functionality, we see there is no stub available (https://github.com/hyperledger/fabric/blob/306aa7d86c180de6876b95169048926c28537269/core/chaincode/shim/mockstub.go#L200). Does it mean that we will have to now launch Fabric Image to test the flow that uses Rich Queries?
rahulhegde (Tue, 28 Feb 2017 00:10:34 GMT):
@dave.enyeart
Our chaincode unit test cases uses MockStub however now for rich queries functionality, we see there is no stub available (https://github.com/hyperledger/fabric/blob/306aa7d86c180de6876b95169048926c28537269/core/chaincode/shim/mockstub.go#L200). Does it mean that we will have to now launch Fabric Image to test the flow that uses Rich Queries? Thanks.
bh4rtp (Tue, 28 Feb 2017 00:23:13 GMT):
Has joined the channel.
Rweb2 (Tue, 28 Feb 2017 01:07:53 GMT):
Has joined the channel.
dave.enyeart (Tue, 28 Feb 2017 01:55:22 GMT):
@rahulhegde That's right, the rich query requires the query engine from CouchDB.
rahulhegde (Tue, 28 Feb 2017 03:12:43 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=QcB7odvbfEuoWdXcJ) @dave.enyeart Is there a way we can still test this w/o launching the Fabric Images; its like automation of unit test done so far done using MockStub, will now be in question or moved to manual test due to use of rich query in between our flow.
PushpalathaHiremath (Tue, 28 Feb 2017 06:18:57 GMT):
Hi All, Can anyone please help me understand the use of these different handlers?
openchainDB.BlockchainCF = cfHandlers[1]
openchainDB.StateCF = cfHandlers[2]
openchainDB.StateDeltaCF = cfHandlers[3]
openchainDB.IndexesCF = cfHandlers[4]
openchainDB.PersistCF = cfHandlers[5]
And, Is there a way that using these handlers, we store data to the peer local and which is not shared across ledger?
manish-sethi (Tue, 28 Feb 2017 06:30:19 GMT):
@PushpalathaHiremath the code snippet is from v0.6. I would suggest you to move to v1.0.
Also, it is not possible as yet to store data as part of a transaction that is not shared across. But something in these lines is in plan post V1. I would suggest you to detail out your scenario for this need so that we may be able to take that into account during design decisions...
PushpalathaHiremath (Tue, 28 Feb 2017 06:39:00 GMT):
@manish-sethi : Thank you for the info.
Considering the business scenarios , there can be some data which should be peer specific. Eg : Node specific Users.
I think with the current version also we can create a new rocksdb in diff path and use it for this. Will that be valid?
manish-sethi (Tue, 28 Feb 2017 08:45:05 GMT):
If you do not need the data (either directly or some representation of it - e.g., hashes of the data) on blockchain then you can keep any additional data on your own in a separate storage (managed by a separate process) on your node... But again a business scenario would be helpful to understand what relation this data carries with the data on blockchain.
manish-sethi (Tue, 28 Feb 2017 08:45:05 GMT):
If you do not need the data (either directly or some representation of it - e.g., hashes of the data) on blockchain then you can keep any additional data on your own in a separate storage (managed by a separate process) on your node... But again, a business scenario would be helpful to understand what relation this data carries with the data on blockchain.
crmiles (Tue, 28 Feb 2017 17:46:16 GMT):
Has joined the channel.
DrTES (Tue, 28 Feb 2017 18:29:57 GMT):
Has joined the channel.
l1nux (Tue, 28 Feb 2017 22:43:23 GMT):
Has joined the channel.
snehas (Wed, 01 Mar 2017 06:13:46 GMT):
Has joined the channel.
snehas (Wed, 01 Mar 2017 06:15:26 GMT):
Hi,
I am facing issue related to GetQueryResult API. In our chaincode we are calling GetQueryResult API of shim but it does not return expected response. Using sfhackfest images with version 1.0.
Below is the query used in GetQueryResult API
{"selector":{"docTypeId":3,"oriRe":"SMP","ctB":"CTB","valDt":"1990-12-24","orB":"YYY","tD":"TD","cuVoB":52,"cuIoBu":"AA","cuSt":"NA"}}
Query internally constructucted with data wrapper:(got from peer logs) {"selector":{"data.cuIoBu":"AA","data.cuVoB":52,"data.data.ctB":"CTB","data.data.cuSt":"NA","data.docTypeId":3,"data.oriRe":"SMP","data.orB":"YYY","data.tD":"TD","data.valDt":"1990-12-24"}}
If you see this query with data wrapper, for ctB and cuSt fields data.data is being appended instead of data and because of this it doesnot fetch record even though its present in ledger.
However if we remove one of the field from the query then it returns response and in this case data.data is not getting appended to fields.
Please find below query which returns response:-
original query:-
{"selector":{"docTypeId":3,"oriRe":"SMP","ctB":"CTB","valDt":"1990-12-24","orB":"YYY","tD":"TD","cuVoB":52,"cuIoBu":"AA"}}
query with data wrapper: {"selector":{"data.ctB":"CTB","data.cuIoBu":"AA","data.cuVoB":52,"data.docTypeId":3,"data.oriRe":"SMP","data.orB":"YYY","data.tD":"TD","data.valDt":"1990-12-24"}}
Please provide your inputs.
snehas (Wed, 01 Mar 2017 06:15:26 GMT):
Hi,
I am facing issue related to GetQueryResult API. In our chaincode we are calling GetQueryResult API of shim but it does not return expected response. Using sfhackfest images with version 1.0.
Below is the query used in GetQueryResult API
{"selector":{"docTypeId":3,"oriRe":"SMP","ctB":"CTB","valDt":"1990-12-24","orB":"YYY","tD":"TD","cuVoB":52,"cuIoBu":"AA","cuSt":"NA"}}
Query internally constructucted with data wrapper:(got from peer logs) {"selector":{"data.cuIoBu":"AA","data.cuVoB":52,"data.data.ctB":"CTB","data.data.cuSt":"NA","data.docTypeId":3,"data.oriRe":"SMP","data.orB":"YYY","data.tD":"TD","data.valDt":"1990-12-24"}}
If you see this query with data wrapper, for ctB and cuSt fields data.data is being appended instead of data and because of this it doesnot fetch record even though its present in ledger.
However if we remove one of the field from the query then it returns response and in this case data.data is not getting appended to fields.
Please find below query which returns response:-
original query:-
{"selector":{"docTypeId":3,"oriRe":"SMP","ctB":"CTB","valDt":"1990-12-24","orB":"YYY","tD":"TD","cuVoB":52,"cuIoBu":"AA"}}
query with data wrapper: {"selector":{"data.ctB":"CTB","data.cuIoBu":"AA","data.cuVoB":52,"data.docTypeId":3,"data.oriRe":"SMP","data.orB":"YYY","data.tD":"TD","data.valDt":"1990-12-24"}}
Please provide your inputs.
snehas (Wed, 01 Mar 2017 06:16:38 GMT):
@dave.enyeart
Hi,
I am facing issue related to GetQueryResult API. In our chaincode we are calling GetQueryResult API of shim but it does not return expected response. Using sfhackfest images with version 1.0.
Below is the query used in GetQueryResult API
{"selector":{"docTypeId":3,"oriRe":"SMP","ctB":"CTB","valDt":"1990-12-24","orB":"YYY","tD":"TD","cuVoB":52,"cuIoBu":"AA","cuSt":"NA"}}
Query internally constructucted with data wrapper:(got from peer logs) {"selector":{"data.cuIoBu":"AA","data.cuVoB":52,"data.data.ctB":"CTB","data.data.cuSt":"NA","data.docTypeId":3,"data.oriRe":"SMP","data.orB":"YYY","data.tD":"TD","data.valDt":"1990-12-24"}}
If you see this query with data wrapper, for ctB and cuSt fields data.data is being appended instead of data and because of this it doesnot fetch record even though its present in ledger.
However if we remove one of the field from the query then it returns response and in this case data.data is not getting appended to fields.
Please find below query which returns response:-
original query:-
{"selector":{"docTypeId":3,"oriRe":"SMP","ctB":"CTB","valDt":"1990-12-24","orB":"YYY","tD":"TD","cuVoB":52,"cuIoBu":"AA"}}
query with data wrapper: {"selector":{"data.ctB":"CTB","data.cuIoBu":"AA","data.cuVoB":52,"data.docTypeId":3,"data.oriRe":"SMP","data.orB":"YYY","data.tD":"TD","data.valDt":"1990-12-24"}}
Please provide your inputs.
dave.enyeart (Wed, 01 Mar 2017 06:56:49 GMT):
@snehas I see the same issue, I've created a defect to fix this: https://jira.hyperledger.org/browse/FAB-2560
dave.enyeart (Wed, 01 Mar 2017 06:58:25 GMT):
Please delete one of the two postings here
jansony1 (Wed, 01 Mar 2017 07:14:58 GMT):
Has joined the channel.
snehas (Wed, 01 Mar 2017 07:35:47 GMT):
@dave.enyeart
Thanks for your response. I have deleted duplicate post.
Thomas_Domingos (Wed, 01 Mar 2017 09:51:10 GMT):
Has joined the channel.
DuongNguyen1 (Wed, 01 Mar 2017 09:54:39 GMT):
Has joined the channel.
antitoine (Wed, 01 Mar 2017 10:39:14 GMT):
Has joined the channel.
SyneBlockChainTeam (Wed, 01 Mar 2017 11:41:57 GMT):
Has joined the channel.
kostas (Wed, 01 Mar 2017 17:52:32 GMT):
@manish-sethi @dave.enyeart: I am reviewing this https://gerrit.hyperledger.org/r/#/c/5929/ and would like some more info on the `blkstorage.IndexConfig` struct. How do I pick which attributes to index, and how does this affect me practically? (Assume I know nothing about LevelDB other than what's written here: http://dailyjs.com/post/leveldb-and-node-1 Feel free to point me to a resource that answers my question though.)
dave.enyeart (Wed, 01 Mar 2017 17:56:25 GMT):
@kostas The indexes are there to support queries. If you know which queries Orderer will need, I can help you pick the correct corresponding indexes:
dave.enyeart (Wed, 01 Mar 2017 17:56:28 GMT):
RetrieveBlocks(startNum uint64) (ledger.ResultsIterator, error)
RetrieveBlockByHash(blockHash []byte) (*common.Block, error)
RetrieveBlockByNumber(blockNum uint64) (*common.Block, error) // blockNum of math.MaxUint64 will return last block
RetrieveTxByID(txID string) (*common.Envelope, error)
RetrieveTxByBlockNumTranNum(blockNum uint64, tranNum uint64) (*common.Envelope, error)
RetrieveBlockByTxID(txID string) (*common.Block, error)
RetrieveTxValidationCodeByTxID(txID string) (peer.TxValidationCode, error)
kostas (Wed, 01 Mar 2017 17:58:10 GMT):
Ah, I see. Luis has picked `IndexableAttrBlockNum` which seems like a sensible choice given that we look-up by block number.
kostas (Wed, 01 Mar 2017 17:58:42 GMT):
Out of curiosity, if I were to provide an empty `IndexConfig` struct, what would I get?
kostas (Wed, 01 Mar 2017 17:58:51 GMT):
A data store that cannot be queried I guess?
dave.enyeart (Wed, 01 Mar 2017 18:01:50 GMT):
Yeah, I was going to recommend IndexableAttrBlockNum for you
dave.enyeart (Wed, 01 Mar 2017 18:02:23 GMT):
Right, I believe the queries return error if the corresponding index is not in place
kostas (Wed, 01 Mar 2017 18:03:57 GMT):
Roger, thank you.
bkvellanki (Wed, 01 Mar 2017 20:15:57 GMT):
Has joined the channel.
Donald Liu (Thu, 02 Mar 2017 01:22:33 GMT):
Has joined the channel.
Liew.SC (Thu, 02 Mar 2017 02:59:29 GMT):
Has joined the channel.
sameerreddy13 (Thu, 02 Mar 2017 03:13:50 GMT):
Has joined the channel.
kostas (Thu, 02 Mar 2017 16:12:38 GMT):
@dave.enyeart: Doing some debugging on the ledger integration. Unless I'm mistaken, every ledger is stored as a dir inside a `blocks` dir.
kostas (Thu, 02 Mar 2017 16:12:38 GMT):
@dave.enyeart, @manish-sethi: Doing some debugging on the ledger integration. Unless I'm mistaken, every ledger is stored as a dir inside a `blocks` dir.
kostas (Thu, 02 Mar 2017 16:13:04 GMT):
Two questions/observations:
kostas (Thu, 02 Mar 2017 16:14:50 GMT):
1. Semantically speaking, does it make sense to find a ledger dir inside the blocks dir?
kostas (Thu, 02 Mar 2017 16:14:50 GMT):
1. Semantically speaking, does it make sense to find a ledger dir inside the blocks dir? I would expect to find the _blocks_ of a ledger inside a directory named "blocks".
kostas (Thu, 02 Mar 2017 16:15:09 GMT):
I would expect to find the blocks of a ledger inside the `blocks` dir.
kostas (Thu, 02 Mar 2017 16:16:34 GMT):
2. If we must stick with the "blocks" dir for this, can we have it as an exported constant? https://github.com/hyperledger/fabric/blob/master/common/ledger/blkstorage/fsblkstorage/config.go#L45
kostas (Thu, 02 Mar 2017 16:16:34 GMT):
2. Whatever name we end up settling on for this parent directory, can we have it exported as a constant? For now it is hard-coded as a string that I cannot access programmatically: https://github.com/hyperledger/fabric/blob/master/common/ledger/blkstorage/fsblkstorage/config.go#L45
dave.enyeart (Thu, 02 Mar 2017 16:25:28 GMT):
1. Agreed, I think it would make more sense to call it 'chains' than 'blocks', since it contains N chains.
dave.enyeart (Thu, 02 Mar 2017 16:25:38 GMT):
2. Agreed, we could have a constant for the anme
dave.enyeart (Thu, 02 Mar 2017 16:25:38 GMT):
2. Agreed, we could have a constant for the name
kostas (Thu, 02 Mar 2017 16:27:21 GMT):
Cool. Do you want me to go ahead with a CR or do you got this? I got a series of changesets depending on this, and I'd like to be done with the ledger integration ASAP so that I can go back to fixing defects :slight_smile:
kostas (Thu, 02 Mar 2017 16:27:51 GMT):
(orderer defects, that is)
dave.enyeart (Thu, 02 Mar 2017 16:27:57 GMT):
whatever is easier... if it is easier for you to just do it in your CR so that there are no dependencies, go ahead
kostas (Thu, 02 Mar 2017 17:48:58 GMT):
https://gerrit.hyperledger.org/r/#/c/6749/
kostas (Thu, 02 Mar 2017 17:49:11 GMT):
Let me know if something looks wrong. (All unit-tests pass locally.)
dave.enyeart (Thu, 02 Mar 2017 18:45:33 GMT):
+1
balaji.viswanathan (Fri, 03 Mar 2017 05:56:57 GMT):
Has joined the channel.
kostas (Fri, 03 Mar 2017 16:23:58 GMT):
Do we have any thoughts on what the permissions for the `chains` folder should be?
dave.enyeart (Fri, 03 Mar 2017 17:25:00 GMT):
@kostas Ledger implicitly creates the directories it needs, using ioutil.go CreateDirIfMission()
dave.enyeart (Fri, 03 Mar 2017 17:25:00 GMT):
@kostas Ledger implicitly creates the directories it needs, using ioutil.go CreateDirIfMissing()
dave.enyeart (Fri, 03 Mar 2017 17:25:17 GMT):
in there, it does: err := os.MkdirAll(path.Dir(dirPath), 0755)
dave.enyeart (Fri, 03 Mar 2017 17:25:17 GMT):
in there, it does: `err := os.MkdirAll(path.Dir(dirPath), 0755)`
dave.enyeart (Fri, 03 Mar 2017 17:25:17 GMT):
in there, it does: err := os.MkdirAll(path.Dir(dirPath), 0755)
yoshtec (Fri, 03 Mar 2017 19:08:49 GMT):
Has joined the channel.
MartinMateev (Mon, 06 Mar 2017 13:00:44 GMT):
@dave.enyeart how is the ledger stuff implemented in the fabric-composer project ?
MartinMateev (Mon, 06 Mar 2017 13:02:29 GMT):
I'm having a hard time figuring out how the fabric-composer relates to the existing stack
Vadim (Mon, 06 Mar 2017 13:09:24 GMT):
@MartinMateev fabric composer is build on top of the fabric. It has a javascript-runtime which is deployed as a chaincode, that runtime executes the business networks you are building by means of fabric-composer tools. So you define your assets, participants, ACLs and transaction processors using simple modelling language and javascript, and then this whole thing is deployed on top of fabric.
Vadim (Mon, 06 Mar 2017 13:10:21 GMT):
it has also APIs for nodejs to interact with your business networks, so you can easily integrate with them
Vadim (Mon, 06 Mar 2017 13:11:43 GMT):
btw, there is a #fabric-composer channel
MartinMateev (Mon, 06 Mar 2017 13:12:43 GMT):
@Vadim awesome, thanks!
MartinMateev (Mon, 06 Mar 2017 13:13:09 GMT):
I'm in that channel so I will ping the guys in there
dave.enyeart (Mon, 06 Mar 2017 17:27:49 GMT):
@manish-sethi - @kostas raised a good question in this snippet:
dave.enyeart (Mon, 06 Mar 2017 17:27:58 GMT):
```2017-03-06 11:50:25.476 EST [kvledger] newBlockfileStream -> DEBU 227f7 newBlockfileStream(): filePath=[/var/folders/19/48hn5bmn077clhhk9zj8w3bc0000gn/T/hyperledger-fabric-ordererledger031710899/chains/testchainid/blockfile_000000], startOffset=[67101560]
2017-03-06 11:50:25.476 EST [kvledger] nextBlockBytesAndPlacementInfo -> DEBU 227f8 Remaining bytes=[2847], Going to peek [8] bytes
2017-03-06 11:50:25.476 EST [kvledger] nextBlockBytesAndPlacementInfo -> DEBU 227f9 Returning blockbytes - length=[2845], placementInfo={fileNum=[0], startOffset=[67101560], bytesOffset=[67101562]}
2017-03-06 11:50:25.477 EST [kvledger] indexBlock -> DEBU 227fa Indexing block [blockNum=23546, blockHash=[]byte{0x3, 0x16, 0x43, 0x2a, 0xd8, 0x18, 0x3c, 0x2f, 0xe, 0x10, 0x80, 0xc8, 0x47, 0x26, 0xb9, 0x63, 0xfc, 0x6a, 0x7a, 0xcd, 0x5a, 0xf5, 0x56, 0x4d, 0x93, 0x9f, 0x9e, 0x4e, 0x81, 0x1f, 0x6f, 0xce} txOffsets=
txId= locPointer=offset=72, bytesLength=69
txId= locPointer=offset=141, bytesLength=69
txId= locPointer=offset=210, bytesLength=69
txId= locPointer=offset=279, bytesLength=69
txId= locPointer=offset=348, bytesLength=69
txId= locPointer=offset=417, bytesLength=68
txId= locPointer=offset=485, bytesLength=69
txId= locPointer=offset=554, bytesLength=69
txId= locPointer=offset=623, bytesLength=69
txId= locPointer=offset=692, bytesLength=69
]
2017-03-06 11:50:25.477 EST [kvledger] updateCheckpoint -> DEBU 227fb Broadcasting about update checkpointInfo: latestFileChunkSuffixNum=[0], latestFileChunksize=[67107259], isChainEmpty=[false], lastBlockNumber=[23546]
2017-03-06 11:50:25.478 EST [kvledger] retrieveBlockByNumber -> DEBU 227fc retrieveBlockByNumber() - blockNum = [23546]
2017-03-06 11:50:25.478 EST [kvledger] newBlockfileStream -> DEBU 227fd newBlockfileStream(): filePath=[/var/folders/19/48hn5bmn077clhhk9zj8w3bc0000gn/T/hyperledger-fabric-ordererledger031710899/chains/testchainid/blockfile_000000], startOffset=[67104407]
2017-03-06 11:50:25.478 EST [kvledger] nextBlockBytesAndPlacementInfo -> DEBU 227fe Remaining bytes=[2852], Going to peek [8] bytes```
dave.enyeart (Mon, 06 Mar 2017 17:28:18 GMT):
Why is remaining bytes increasing? Seems like it should be decreasing.
dave.enyeart (Mon, 06 Mar 2017 17:28:31 GMT):
2847 at the top and 2852 at the bottom
dave.enyeart (Mon, 06 Mar 2017 17:35:45 GMT):
actually i think i see it: remainingBytes := fileInfo.Size() - s.currentOffset
dave.enyeart (Mon, 06 Mar 2017 17:35:45 GMT):
actually i think i see it: `remainingBytes := fileInfo.Size() - s.currentOffset`
manish-sethi (Mon, 06 Mar 2017 17:36:08 GMT):
@dave.enyeart, @kostas : from the logs it appears that there are two streams opened to the block file. The latter one starting at a previous block
dave.enyeart (Mon, 06 Mar 2017 17:36:13 GMT):
both file size and current offset are increasing
manish-sethi (Mon, 06 Mar 2017 17:36:45 GMT):
Look for `newBlockfileStream`
dave.enyeart (Mon, 06 Mar 2017 17:37:33 GMT):
i guess we need @kostas to explain what he's doing
manish-sethi (Mon, 06 Mar 2017 17:37:43 GMT):
in the logs in the snippet, the first one is opened at offset 67101560 and the second one at the offset 67104407
kostas (Mon, 06 Mar 2017 17:38:24 GMT):
Just broadcasting messages to the orderer from a single client, the `broadcast_timestamp` sample clients in `orderer/sample_clients`.
kostas (Mon, 06 Mar 2017 17:39:16 GMT):
Not sure I follow your observations above. Are you suggesting there may be an implementation issue?
dave.enyeart (Mon, 06 Mar 2017 17:39:55 GMT):
we mentioned to Luis that he should iterate through the stream, rather than retrieveBlockByNumber for each block
manish-sethi (Mon, 06 Mar 2017 17:40:50 GMT):
No, I'm just trying to understand the usage pattern... let me look at the `orderer/sample_clients`. Is it in the master?
kostas (Mon, 06 Mar 2017 17:41:13 GMT):
@manish-sethi: Yes.
kostas (Mon, 06 Mar 2017 17:41:37 GMT):
And I have a branch I can point you to in a few minutes, so that you can try out the ledger integration in action, just let me know.
kostas (Mon, 06 Mar 2017 17:41:46 GMT):
@dave.enyeart: I believe you refer to this. https://gerrit.hyperledger.org/r/#/c/5929/10/orderer/ledger/file/fileledger.go@50
dave.enyeart (Mon, 06 Mar 2017 17:42:46 GMT):
right
kostas (Mon, 06 Mar 2017 17:42:53 GMT):
If this is merely an optimization issue, I am fine with improving in later changesets. If however this approach is wrong, let me know why and let's take care of it.
manish-sethi (Mon, 06 Mar 2017 17:43:28 GMT):
no, it's not wrong
manish-sethi (Mon, 06 Mar 2017 17:43:38 GMT):
it's an optimization
dave.enyeart (Mon, 06 Mar 2017 17:44:14 GMT):
right
manish-sethi (Mon, 06 Mar 2017 17:46:01 GMT):
This 'Remaining bytes=...' in the logs could increase for two reasons. 1) the new iterator is opened at some previous block or 2) more blocks got added to the file between opening of first iterator and the second iterator.
dave.enyeart (Mon, 06 Mar 2017 17:46:46 GMT):
There is a indexBlock() in the trace, therefore blocks are getting added
manish-sethi (Mon, 06 Mar 2017 17:46:51 GMT):
Do you want me to look at some particular file in `orderer/sample_clients` to see the usage pattern of iterator?
dave.enyeart (Mon, 06 Mar 2017 17:47:09 GMT):
that is just the client side... we are interested in the orderer server side
kostas (Mon, 06 Mar 2017 17:47:10 GMT):
Ah, I see.
dave.enyeart (Mon, 06 Mar 2017 17:47:28 GMT):
and i think we are good... they are getting block by number now, and will use the stream in the future
kostas (Mon, 06 Mar 2017 17:47:59 GMT):
It seems like we are good indeed.
kostas (Mon, 06 Mar 2017 17:48:02 GMT):
Thanks guys.
kostas (Mon, 06 Mar 2017 17:48:12 GMT):
I'll push the final changeset in a few.
WeDoIoE (Tue, 07 Mar 2017 00:16:58 GMT):
Has joined the channel.
SyneBlockChainTeam (Tue, 07 Mar 2017 07:38:07 GMT):
Earlier we have been using hyperledger fabric v0.5 and v0.6 with vagrant and successfully developed various sample applications. Now we want to switch to v1.0. Though we are following the steps given on "http://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/devenv.html", but somehow we are facing issues while setting up development environment. Is membersrvc.yaml file replaced with fabric-cop? Thanks in advance.
codewinguagua (Tue, 07 Mar 2017 08:33:36 GMT):
Has joined the channel.
MartinMateev (Tue, 07 Mar 2017 09:10:44 GMT):
guys, if a network is encrypting transaction payload - how is the payload then stored into something like CouchDB?
muralisr (Tue, 07 Mar 2017 12:41:21 GMT):
@SyneBlockChainTeam could you ask that question in fabric-crypto/fabric-ca please ? Just don't want it to get buried here without a response
muralisr (Tue, 07 Mar 2017 12:41:21 GMT):
@SyneBlockChainTeam could you ask that question in fabric-crypto please ? Just don't want it to get buried here without a response
muralisr (Tue, 07 Mar 2017 12:42:49 GMT):
but the short answer is `fabric-ca` is the loose equivalent of the old membership service in 0.6...."loose equivalent" because many of the flows with it are different
SyneBlockChainTeam (Tue, 07 Mar 2017 13:05:08 GMT):
@muralisr - Done.
dave.enyeart (Tue, 07 Mar 2017 15:35:44 GMT):
@SyneBlockChainTeam please take that question to #fabric-dev-env
dave.enyeart (Tue, 07 Mar 2017 15:39:02 GMT):
@MartinMateev if data payload is binary (or encrypted), then it makes no sense to use CouchDB. Only makes sense to use CouchDB if the data payload is JSON. In some cases there is a mixed workload of JSON and binary, and in those cases you can use CouchDB. The binary data will simply be stored in CouchDB as a binary attachment, and can only be queried by id (GetState).
dave.enyeart (Tue, 07 Mar 2017 15:40:02 GMT):
In other cases you may only want to encrypt sensitive fields in the JSON. In that case those fields can be base64 encoded, and it would still make sense to use CouchDB so that the other JSON fields could be queried.
MartinMateev (Tue, 07 Mar 2017 16:45:02 GMT):
@dave.enyeart that's a great idea
MartinMateev (Tue, 07 Mar 2017 16:45:39 GMT):
I can use the encrypted for sensitive and plan-text for query params
MartinMateev (Tue, 07 Mar 2017 16:46:09 GMT):
I wish I can see an example node-sdk web JS app for the CouchDB marble example (end to end)
MartinMateev (Tue, 07 Mar 2017 16:46:39 GMT):
i.e deploy a chain code, register a user, save JSON in CouchDB and query - all via the Node SDK
dave.enyeart (Tue, 07 Mar 2017 17:19:09 GMT):
@jimthematrix @jeffgarratt Note that there has been a lot of interest in an end-to-end example using /examples/chaincode/go/marbles02. Like example02, marbles02 has some trivial functions to test HelloWorld type scenarios. Unlike example02, marbles02 also has additional functions to illustrate recommended data chaincode patterns. It works on leveldb and couchdb (of course, the rich query functions would require couchdb, but the simple examples dont have to exercise that). I would recommend bdd, samples, demos, etc utilize marbles02 going forward, due to the additional value.
jeffgarratt (Tue, 07 Mar 2017 17:19:09 GMT):
Has joined the channel.
jimthematrix (Tue, 07 Mar 2017 17:19:09 GMT):
Has joined the channel.
kostas (Tue, 07 Mar 2017 17:26:21 GMT):
(Out of curiosity, is there any reason why is this marbles02 instead of plain marbles?)
kostas (Tue, 07 Mar 2017 17:26:21 GMT):
(Out of curiosity, is there any reason why this is marbles02 instead of plain marbles?)
dave.enyeart (Tue, 07 Mar 2017 17:45:32 GMT):
@kostas There are two versions of marbles. 'marbles' is the bluemix sample with UI and doesn't showcase recommended chaincode/data patterns. 'marbles02' is intended to be a replacement for example02 and it showcases recommended chaincode/data patterns.
dave.enyeart (Tue, 07 Mar 2017 17:45:32 GMT):
@kostas There are two versions of marbles. 'marbles' is the bluemix sample with UI and doesn't showcase recommended chaincode/data patterns. 'marbles02' is intended to be a replacement for example02 as a good HelloWorld example, and it also showcases recommended chaincode/data patterns.
dave.enyeart (Tue, 07 Mar 2017 17:45:44 GMT):
There is intent to converge the marbles, but until that happens, we have 'marbles02'
Percival Lucena (Tue, 07 Mar 2017 18:30:25 GMT):
Is there a tutorial or some documentation for loopback-connector-composer ?
StevenLanders (Tue, 07 Mar 2017 22:00:07 GMT):
Other than couchbase and leveldb, are there other databases being considered? It would be nice if it was fairly easy to add an adapter.
dave.enyeart (Tue, 07 Mar 2017 22:28:42 GMT):
@StevenLanders No other databases planned. The state database is defined by an interface, therefore other (key-value type) state database implementations can be coded up
berserkr (Wed, 08 Mar 2017 06:15:59 GMT):
Has joined the channel.
AbhilekhSingh (Wed, 08 Mar 2017 13:52:23 GMT):
Has joined the channel.
AbhilekhSingh (Wed, 08 Mar 2017 13:52:37 GMT):
How can I see ledger blocks data store on peer?
I don't see any option in peer cli
I see blockchain explorer but it only supports 0.6
MartinMateev (Wed, 08 Mar 2017 14:02:36 GMT):
@AbhilekhSingh yeah good question
MartinMateev (Wed, 08 Mar 2017 14:02:58 GMT):
Blockchain explorer does not support latest version?
Suma (Wed, 08 Mar 2017 15:43:33 GMT):
Has joined the channel.
dave.enyeart (Wed, 08 Mar 2017 16:44:04 GMT):
No blockchain explorer support for v1. There are APIs on the peer via Query System Chaincode such as:
dave.enyeart (Wed, 08 Mar 2017 16:44:11 GMT):
```peer chaincode query -o 127.0.0.1:7050 -C "" -n qscc -c '{"Args":["GetChainInfo","myc1"]}'
peer chaincode query -o 127.0.0.1:7050 -C "" -n qscc -c '{"Args":["GetBlockByNumber","myc1","3"]}' ```
dave.enyeart (Wed, 08 Mar 2017 16:45:18 GMT):
However these return protobuf binary structures. It is recommended to use SDK APIs which wrap these peer APIs
berserkr (Wed, 08 Mar 2017 23:59:06 GMT):
Hi Guys, the verbiage in the architecture text is a bit misleading. For instance, here is the first chunk: Ledger is kept at all peers and, optionally, at a subset of orderers. In the context of an orderer we refer to the Ledger as to OrdererLedger, whereas in the context of a peer we refer to the ledger as to PeerLedger...
berserkr (Wed, 08 Mar 2017 23:59:40 GMT):
Then later on: Orderers maintain OrdererLedger for fault-tolerance and availability (of the PeerLedger) and may decide to prune it at anytime, provided that properties of the ordering service (see Sec. 1.3.3) are maintained
berserkr (Thu, 09 Mar 2017 00:00:17 GMT):
so, does this mean that orderers do indeed maintain the ordered ledger? And it is not optional? I am confused because the text says that the orderer service maintains the orderedledger
berserkr (Thu, 09 Mar 2017 01:19:21 GMT):
Guys/Gals, quick question. Does the ledger have at-rest-encryption?
berserkr (Thu, 09 Mar 2017 01:19:50 GMT):
Could someone tamper with the data and mark txs valid/invalid (flip the bit)?
berserkr (Thu, 09 Mar 2017 01:20:21 GMT):
or is that bit included when computing the hash of a block?
berserkr (Thu, 09 Mar 2017 01:26:12 GMT):
is there documentation that describes how blocks are chained together? I'm familiar with the bitcoin blockchain, however, so far everything i have read is how transactions are handled down to how the ledger is updates, but everyting is at the tx level
rahulhegde (Thu, 09 Mar 2017 01:59:05 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ci?msg=hX8yz5DuSSNniHFRJ) @dave.enyeart
http://docs.couchdb.org/en/2.0.0/api/database/find.html#db-index
...
{
"ddoc": "_design/ddoc",
"name": "indexOwnerdesc",
"type": "json",
"def": {
"fields": [{
*"data.size": "desc"*
}]
}
}, {
"ddoc": "_design/ddocasc",
"name": "indexOwnerasc",
"type": "json",
"def": {
"fields": [{
*"data.size": "asc"*
}]
}
}
...
I created 2 index on marble's property size, one using asc and other desc sort as shown. I was expecting this will be the order of arranging the entries on B-Tree. However a selector/rich query on size gt 0 created the same resultset in same order when either asc or desc index was used. Not able to get what's the use of this sort field?
dave.enyeart (Thu, 09 Mar 2017 02:25:02 GMT):
@rahulhegde I believe you can traverse a b-tree forwards or backwards. The sort order will be driven by the query sort specification, not the index sort specification.
dave.enyeart (Thu, 09 Mar 2017 02:25:02 GMT):
@rahulhegde I believe you can traverse a b-tree forwards or backwards. The sort order will be driven by the query sort specification, not the index sort specification. Not sure of the significance of sort on the index, perhaps there is a small performance improvement with forward traversal
rahulhegde (Thu, 09 Mar 2017 03:11:45 GMT):
@dave.enyeart - I am addressing this to you as I didn't get any response on #fabric
I ran chaincode-2-chaincode query interface test using example02, example04 on Fabric-CI Images - 4th March. 1 thing I noticed and as per https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/interfaces.go#L57 - Invoke operation containing PutState will not be recorded to the ledger (irrespective if chaincode is running on the same or different channel of the same peer). And this is what I see as expected.
However looking at the go test written for example04 at https://github.com/hyperledger/fabric/blob/master/examples/chaincode/go/chaincode_example04/chaincode_example04_test.go#L109, the invoke operation containing PutState (transfer 10 unit from A -> B ) gets registered/committed in mock-stub implementation. This need to be corrected.
lenin.mehedy (Thu, 09 Mar 2017 04:05:41 GMT):
Has joined the channel.
berserkr (Thu, 09 Mar 2017 05:06:51 GMT):
Invoke operations do get recorded
berserkr (Thu, 09 Mar 2017 05:06:56 GMT):
query do not as far as I know
berserkr (Thu, 09 Mar 2017 05:10:44 GMT):
the difference is what gets called from what i see
berserkr (Thu, 09 Mar 2017 05:10:56 GMT):
for instance, define f := "invoke", it will modify the state
berserkr (Thu, 09 Mar 2017 05:11:36 GMT):
InvokeChaincode is only interface to invoke a chaincode, but the function defines the type
berserkr (Thu, 09 Mar 2017 05:11:43 GMT):
query will not modify the state, invoke will
rikmoedt (Thu, 09 Mar 2017 11:11:40 GMT):
Has joined the channel.
aberfou (Thu, 09 Mar 2017 13:48:17 GMT):
Has joined the channel.
rahulhegde (Thu, 09 Mar 2017 15:19:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=dyCazM93EyCcb7rum) @berserkr https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/interfaces.go#L57 - Comments say InvokeChaincode calling function which has Shim.PutState will have no effect on ledger. This needs to be considered in the Mock-Stub implementation which currently has a effect on ledger.
rahulhegde (Thu, 09 Mar 2017 15:19:23 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=dyCazM93EyCcb7rum) @berserkr https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/interfaces.go#L57 - Comments say InvokeChaincode calling function which has Shim.PutState will have no effect on ledger. This needs to be considered in the Mock-Stub implementation which currently has a effect on mocked-ledger.
kuangchao (Fri, 10 Mar 2017 01:58:52 GMT):
Has joined the channel.
berserkr (Fri, 10 Mar 2017 06:35:23 GMT):
Hi Guys, is there any locking at the db level when executing chaincode?
berserkr (Fri, 10 Mar 2017 06:35:54 GMT):
I know that the endorsers will generate the read/write sets, right? They also execute chaincode and do the simulation. But is the db locked during this step?
manish-sethi (Fri, 10 Mar 2017 06:50:55 GMT):
@berserkr yes, the simulation and commit is synchronized by a read-write lock. Simulations happen under the read locks and the commit of block happens under the write lock.
berserkr (Fri, 10 Mar 2017 06:51:44 GMT):
interesting, I suspected as much. So, at what levels are locks enforced?
berserkr (Fri, 10 Mar 2017 06:52:08 GMT):
can peers read/write to the same db in parallel?
berserkr (Fri, 10 Mar 2017 06:52:42 GMT):
and when will the locks be released?
berserkr (Fri, 10 Mar 2017 06:53:04 GMT):
reason I ask is what if you have a chaincode that takes up a lot of time (long running job)
berserkr (Fri, 10 Mar 2017 06:53:15 GMT):
it could starve others
manish-sethi (Fri, 10 Mar 2017 06:53:23 GMT):
As a usual read-write lock works... all simulations can go in parallel but not when commit is underway
berserkr (Fri, 10 Mar 2017 06:53:56 GMT):
ahh ok
berserkr (Fri, 10 Mar 2017 06:54:25 GMT):
for reading, there are no locks right? bc simulation reads directly from db
manish-sethi (Fri, 10 Mar 2017 06:54:35 GMT):
In the situation you posed, a long running chaincode tran won't starve others but commit would have to wait till the chaincode simulation finishes
berserkr (Fri, 10 Mar 2017 06:55:09 GMT):
so if i have a bug in my code with an infinite loop, it won't affect others
berserkr (Fri, 10 Mar 2017 06:55:12 GMT):
just my code
manish-sethi (Fri, 10 Mar 2017 06:56:18 GMT):
it would affect the commit process. Commit of new block has to wait till chaincode runtime times out your chaincode...
manish-sethi (Fri, 10 Mar 2017 06:56:55 GMT):
but yes, not the other chaincodes simulations...
berserkr (Fri, 10 Mar 2017 06:57:11 GMT):
ahhh, interesting, there is a time out in there
berserkr (Fri, 10 Mar 2017 06:57:33 GMT):
is that something in the configuration that determines what that timeout is?
manish-sethi (Fri, 10 Mar 2017 06:57:35 GMT):
I think so but not sure... @muralisr can confirm on this
manish-sethi (Fri, 10 Mar 2017 06:58:21 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=DKAnAvo9MLkGr5iDB) @berserkr No, simulation happends under the read-lock
berserkr (Fri, 10 Mar 2017 06:58:38 GMT):
alright, will confirm with @muralisr , thank you @manish-sethi !
berserkr (Fri, 10 Mar 2017 07:16:35 GMT):
is there a guide that shows how to install/connect the fabric with couchdb instead of leveldb for the state?
berserkr (Fri, 10 Mar 2017 07:17:12 GMT):
or other way around?
MartinMateev (Fri, 10 Mar 2017 12:45:10 GMT):
@bere
MartinMateev (Fri, 10 Mar 2017 12:45:44 GMT):
@berserkr as far as I know at this stage it's a matter of specifying the key-value store in a core config file
MartinMateev (Fri, 10 Mar 2017 12:46:03 GMT):
as to an actual example - I only found a GO sample app that deals with CouchDB
MartinMateev (Fri, 10 Mar 2017 12:47:26 GMT):
it should also be possible to achieve the same with the JS SDK but sample apps are practically non-existing so I'm looking at the JS tests to see sample usage: https://github.com/hyperledger/fabric-sdk-node
MartinMateev (Fri, 10 Mar 2017 12:49:12 GMT):
it looks like the v1 JS SDK specs are still pretty much work in progress
MartinMateev (Fri, 10 Mar 2017 12:54:12 GMT):
@berserkr https://github.com/hyperledger/fabric-sdk-node/tree/master/examples/balance-transfer
dave.enyeart (Fri, 10 Mar 2017 12:57:24 GMT):
http://hyperledger-fabric.readthedocs.io/en/latest/ledger.html says "To enable CouchDB as the state database, configure the /fabric/peer/core.yaml stateDatabase section."
dave.enyeart (Fri, 10 Mar 2017 12:57:40 GMT):
flipping between goleveldb and CouchDB is a single config option in there
dave.enyeart (Fri, 10 Mar 2017 12:58:01 GMT):
of course, you have to have a CouchDB environment available-
dave.enyeart (Fri, 10 Mar 2017 12:58:18 GMT):
For vagrant env you can `make couchdb` and then `couchdb start`
dave.enyeart (Fri, 10 Mar 2017 12:58:40 GMT):
For docker, instructions are coming together here: https://gerrit.hyperledger.org/r/#/c/7097
dave.enyeart (Fri, 10 Mar 2017 13:00:01 GMT):
Instead of in core.yaml, you can also pass the config via environment variable: `CORE_LEDGER_STATE_STATEDATABASE=CouchDB peer node start`
dave.enyeart (Fri, 10 Mar 2017 13:02:30 GMT):
/fabric/examples/chaincode/go/marbles02 chaincode demonstrates use of the additional CouchDB functionality
ruslan.kryukov (Fri, 10 Mar 2017 13:05:28 GMT):
As for couchDB, recently we have made stress test, which included invoke requests to fabric, a lot of them, 1000reqs with 50 threads.. so couchdb just hanged when we were doing test, finally we turned off couchdb and currently we use embdedd levelDB
ruslan.kryukov (Fri, 10 Mar 2017 13:06:45 GMT):
also currently we have 4 peers, 4 orderers, 2 kafka and 1 zookeeper, our speed is 280-350 reqs per second
Vadim (Fri, 10 Mar 2017 13:08:53 GMT):
@ruslan.kryukov is it for invocation or for querying?
ruslan.kryukov (Fri, 10 Mar 2017 13:09:05 GMT):
invocation
Vadim (Fri, 10 Mar 2017 13:09:23 GMT):
and what is the latency?
Vadim (Fri, 10 Mar 2017 13:09:37 GMT):
i.e. how long it takes for a request to be completed?
ruslan.kryukov (Fri, 10 Mar 2017 13:09:41 GMT):
all machines are in same local network
ruslan.kryukov (Fri, 10 Mar 2017 13:10:24 GMT):
All tasks finished!
### Benchmark Result ###
Peers: 1
Orderers: 1
Thread count: 120
Task count: 36000
Result time: 104.455 sec
Performance: 344req/sec
### Invoke status ###
Success: 36000
IBM Corp. 2017 All Rights Reserved
Vadim (Fri, 10 Mar 2017 13:11:13 GMT):
yes, but how long it takes between sending invoke to endorsers and receiving confirmation from orderer on average per transaction? Don't know how to call it... Transaction execution time, maybe?
ruslan.kryukov (Fri, 10 Mar 2017 13:11:53 GMT):
I didn't check that time
Vadim (Fri, 10 Mar 2017 13:12:51 GMT):
so far I only tried with one orderer, so it takes 5 seconds or so, I was wondering how it changes if you have 4 orderers
dave.enyeart (Fri, 10 Mar 2017 13:14:57 GMT):
Thanks Ruslan. Have you been able to identify specific bottlenecks?
dave.enyeart (Fri, 10 Mar 2017 13:15:48 GMT):
As far CouchDB, it has not yet gone through optimization, performance, stress test. That will be done under https://jira.hyperledger.org/browse/FAB-2725
dave.enyeart (Fri, 10 Mar 2017 13:15:48 GMT):
As far as CouchDB, it has not yet gone through optimization, performance, stress test. That will be done under https://jira.hyperledger.org/browse/FAB-2725
ruslan.kryukov (Fri, 10 Mar 2017 13:17:07 GMT):
@Vadim hm we tested only throughput, but when I getting transaction response from `CompletableFuture
Vadim (Fri, 10 Mar 2017 13:17:19 GMT):
ok, thanks
yury (Fri, 10 Mar 2017 13:17:29 GMT):
Has joined the channel.
ruslan.kryukov (Fri, 10 Mar 2017 13:18:06 GMT):
@dave.enyeart I turned on profiling and found that peer is doing a lot of operations with cryptography
ruslan.kryukov (Fri, 10 Mar 2017 13:19:37 GMT):
but in general, I didn't investigate in details yet
ruslan.kryukov (Fri, 10 Mar 2017 13:19:37 GMT):
but in general, I didn't investigate it in details yet
ruslan.kryukov (Fri, 10 Mar 2017 13:26:06 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=jXRbfogxijr5NJz2r) @dave.enyeart good, also what if someone bad guy has changed some values in couchdb? How fabric reacts to that changes?
dave.enyeart (Fri, 10 Mar 2017 13:31:59 GMT):
Future endorsements on the tampered data will fail since it is different across peers, and the bad peer will be found out. At any time, the state db can be rebuilt from the trusted chain data.
dave.enyeart (Fri, 10 Mar 2017 13:31:59 GMT):
@ruslan.kryukov Future endorsements on the tampered data will fail since it is different across peers, and the bad peer will be found out. At any time, the state db can be rebuilt from the trusted chain data.
ruslan.kryukov (Fri, 10 Mar 2017 13:43:44 GMT):
oh, well
rahulhegde (Fri, 10 Mar 2017 15:19:05 GMT):
GM @dave.enyeart
I am running Fabric-Images (4th March) with klaemo/couchDB. Using the Peer CLI - got a successful Endorsement Proposal response however I am not able to see the JSON node in the couch DB (after it sending it to the orderer).
1. Checked using fauzton and http _find for _id > null = returns me only 2 nodes lccc
rahulhegde (Fri, 10 Mar 2017 15:19:05 GMT):
GM @dave.enyeart
I am running Fabric-Images (4th March) with klaemo/couchDB. Using the Peer CLI - got a successful Endorsement Proposal response however I am not able to see the JSON node in the couch DB (after it sending it to the orderer).
1. Checked using fauzton and http _find for _id > null = returns me only 2 nodes lccc
dave.enyeart (Fri, 10 Mar 2017 15:29:52 GMT):
tran invalidation would show up as a Warning in peer logs. you can see exactly what is happening with block commit and state db commit if you enable additional debug. i'd recommend getting familiar with the debug, at least the last part around block commit, it isnt too intimidating:
dave.enyeart (Fri, 10 Mar 2017 15:29:52 GMT):
@rahulhegde tran invalidation would show up as a Warning in peer logs. you can see exactly what is happening with block commit and state db commit if you enable additional debug. i'd recommend getting familiar with the debug, at least the last part around block commit, it isnt too intimidating:
dave.enyeart (Fri, 10 Mar 2017 15:29:56 GMT):
`CORE_LOGGING_LEVEL=DEBUG peer node start`
rahulhegde (Fri, 10 Mar 2017 15:42:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=hcb9GE4w3wsy4fhAa) @dave.enyeart Is it possible to disable the GOSSIP Logs, its rolling-rolling even at info level.
rahulhegde (Fri, 10 Mar 2017 15:42:47 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=hcb9GE4w3wsy4fhAa) @dave.enyeart Is it possible to disable the peer GOSSIP Logs, its rolling-rolling even at info level.
MartinMateev (Fri, 10 Mar 2017 15:43:32 GMT):
@rahulhegde were you following a specific guide to get to the point of "running Fabric-Images (4th March) with klaemo/couchDB" ?
JatinderBali (Fri, 10 Mar 2017 15:44:31 GMT):
Has joined the channel.
dave.enyeart (Fri, 10 Mar 2017 15:45:40 GMT):
@rahulhegde gossip logging has been reduced recently. you can silence it for now with:
dave.enyeart (Fri, 10 Mar 2017 15:45:45 GMT):
```peer logging setlevel gossip/comm#-1 ERROR
peer logging setlevel gossip/discovery#0.0.0.0:7051 ERROR
peer logging setlevel gossip/gossip#0.0.0.0:7051 ERROR```
dave.enyeart (Fri, 10 Mar 2017 15:46:00 GMT):
your port may be different
dave.enyeart (Fri, 10 Mar 2017 15:46:16 GMT):
copy/paste the whole line... the formatting was not intentional
rahulhegde (Fri, 10 Mar 2017 15:47:13 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=sATurdktScSQ9emCv) @MartinMateev used - https://gerrit.hyperledger.org/r/#/c/6947/
dave.enyeart (Fri, 10 Mar 2017 15:49:46 GMT):
Actually, latest CouchDB docker instructions are here now: https://gerrit.hyperledger.org/r/#/c/7097/
MartinMateev (Fri, 10 Mar 2017 15:52:35 GMT):
I'm getting completely lost
MartinMateev (Fri, 10 Mar 2017 15:53:00 GMT):
@dave.enyeart I set-up my environment by using the hackfest workplace as described here: http://hyperledger-fabric.readthedocs.io/en/latest/asset_setup.html#
MartinMateev (Fri, 10 Mar 2017 15:53:31 GMT):
how would I enable CouchDB so I can try playing around with the marble chaincode (https://github.com/hyperledger/fabric/blob/938b5dc41f15e2ce5e2daeaa1133c65ceeb0fb14/examples/chaincode/go/marbles02/marbles_chaincode.go)
dave.enyeart (Fri, 10 Mar 2017 16:02:00 GMT):
the docker images and cleaned up instructions will be made available in a week or so. For now use docker image klaemo/couchDB and check out instructions here: https://gerrit.hyperledger.org/r/#/c/7097.
dave.enyeart (Fri, 10 Mar 2017 16:02:00 GMT):
the docker images and cleaned up instructions will be made available in a week or so. For now use docker image klaemo/couchDB and check out the work in progress instructions here: https://gerrit.hyperledger.org/r/#/c/7097.
dave.enyeart (Fri, 10 Mar 2017 16:02:19 GMT):
@AdnanC may be able to help answer specific questions
rahulhegde (Fri, 10 Mar 2017 16:17:20 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=E6v8eQPWQW5PvLXpe) @dave.enyeart
thanks for the steps, it has silenced peer0 completely. I will move peer in DEBUG from INFO mode now. Sorry on call, will catch up.
binhn (Fri, 10 Mar 2017 16:27:48 GMT):
@dave.enyeart @manish-sethi I want to bring up the protobuf deterministic issue again as we're talking about making wr-set protobuf. Ref https://groups.google.com/forum/#!topic/protobuf/7do1mgl-5LM. That ref points to 2 things Maps and Unknown fields. The discussion only mentioned languages but not platforms, which I am concerned about, especially EBCDIC vs ASCII. Would a rw-set created and marshaled on EBCDIC computer different from ASCII computer?
samirsadeghi (Fri, 10 Mar 2017 16:52:53 GMT):
Has joined the channel.
berserkr (Fri, 10 Mar 2017 18:04:29 GMT):
@MartinMateev thank you!
manish-sethi (Fri, 10 Mar 2017 18:31:18 GMT):
@binhn protobuf encoding is not platform dependent. For all the int numeric variations/bool etc. it uses varint encoding and for fixed length numeric ints/floats etc. it uses little-endian byte order.
However, for strings, it expects valid utf-8 strings. For instance, in golang string literals are always utf-8 and I guess that protobuf would simply use it as is without verifying.
Still, a golang string type is hardy any different from []byte (except that a string is immutable) and hence could actually be any arbitrary bytes and so, it's users responsibility to make sure that it uses utf-8 strings.
Similarly, in java the default string encoding is utf-16 and I believe that protobuf java impl would convert that to utf-8 during serialization.
Also, as you said if one is not using map and unknown fields, the serialization is pretty much deterministic however, reverse is not true.
For instance, if you are using protobuf default implementation, it would always put the bytes of the fields based on their tag number (e.g., bytes of field marked as 1 would precede the bytes for field marked as 2 in the proto definition).
However, even if they appear in reverse order (by some other impl), the encoder is expected to parse those. In other words, it's not deterministic as the spec level but default impl is as long as one does not uses map and unknown fields.
manish-sethi (Fri, 10 Mar 2017 18:31:18 GMT):
@binhn protobuf encoding is not platform dependent. For all the int numeric variations/bool etc. it uses varint encoding and for fixed length numeric ints/floats etc. it uses little-endian byte order.
However, for strings, it expects valid utf-8 strings. For instance, in golang, string literals are always utf-8 and I guess that protobuf would simply use it as is without verifying. Still, a golang string type is hardy any different from []byte (except that a string is immutable) and hence could actually be any arbitrary bytes and so, it's users responsibility to make sure that it uses utf-8 strings. Similarly, in java, the default string encoding is utf-16 and I believe that protobuf java impl would convert that to utf-8 during serialization.
Also, as you said if one is not using map and unknown fields, the serialization is pretty much deterministic however, reverse is not true. For instance, if you are using protobuf default implementation, it would always put the bytes of the fields based on their tag number (e.g., bytes of field marked as 1 would precede the bytes for field marked as 2 in the proto definition). However, even if they appear in reverse order (by some other impl), the encoder is expected to parse those. In other words, it's not deterministic as the spec level but default impl is as long as one does not uses map and unknown fields.
manish-sethi (Fri, 10 Mar 2017 18:31:18 GMT):
@binhn protobuf encoding is not platform dependent. For all the int numeric variations/bool etc. it uses varint encoding and for fixed length numeric ints/floats etc. it uses little-endian byte order.
However, for strings, it expects valid utf-8 strings. For instance, in golang, string literals are always utf-8 and I guess that protobuf would simply use it as is without verifying. Still, a golang string type is hardy any different from []byte (except that a string is immutable) and hence could actually be any arbitrary bytes and so, it's users responsibility to make sure that it uses utf-8 strings. Similarly, in java, the default string encoding is utf-16 and I believe that protobuf java impl would convert that to utf-8 during serialization.
Also, as you said if one is not using map and unknown fields, the serialization is pretty much deterministic however, reverse is not true. For instance, if you are using protobuf default implementation, it would always put the bytes of the fields based on their tag number (e.g., bytes of field marked as 1 would precede the bytes for field marked as 2 in the proto definition). However, even if they appear in reverse order (by some other impl), the encoder is expected to parse those. In other words, it's not deterministic at the spec level but default impl is as long as one does not uses map and unknown fields.
manish-sethi (Fri, 10 Mar 2017 18:31:18 GMT):
@binhn protobuf encoding is not platform dependent. For all the int numeric variations/bool etc. it uses varint encoding and for fixed length numeric ints/floats etc. it uses little-endian byte order.
However, for strings, it expects valid utf-8 strings. For instance, in golang, string literals are always utf-8 and I guess that protobuf would simply use it as is without verifying. Still, a golang string type is hardy any different from []byte (except that a string is immutable) and hence could actually be any arbitrary bytes and so, it's users responsibility to make sure that it uses utf-8 strings. Similarly, in java, the default string encoding is utf-16 and I believe that protobuf java impl would convert that to utf-8 during serialization.
Also, as you said if one is not using map and unknown fields, the serialization is pretty much deterministic however, reverse is not true. For instance, if you are using protobuf default implementation, it would always put the bytes of the fields based on their tag number (e.g., bytes of field marked as 1 would precede the bytes for field marked as 2 in the proto definition). However, even if they appear in reverse order (by some other impl), the encoder is expected to parse those. In other words, it's not deterministic at the spec level but default impl is - as long as one does not uses map and unknown fields.
MartinMateev (Fri, 10 Mar 2017 19:17:54 GMT):
@dave.enyeart I'm looking at the end-2-end example: https://gerrit.hyperledger.org/r/gitweb?p=fabric.git;a=blob;f=examples/e2e_cli/end-to-end.rst;h=bba24dc0ed171adb48e275fb20ac48dc7002091c;hb=b98ee1f23f6e3b6bfabc4ce23a2a6d7871ae1bfa
MartinMateev (Fri, 10 Mar 2017 19:18:34 GMT):
why is vagrant still part of the set-up when it seems like we're moving away from it
AdnanC (Fri, 10 Mar 2017 19:20:07 GMT):
@MartinMateev the document contains non-vagrant directions, in addition to vagrant directions
MartinMateev (Fri, 10 Mar 2017 19:24:32 GMT):
@AdnanC ok thanks - will try to figure it out
rahulhegde (Fri, 10 Mar 2017 20:07:37 GMT):
@dave.enyeart
To set this log level - I went to the peer0 container and then executed ` peer logging getlevel gossip/discovery#172.19.0.4:7051 `. This is going in a loop and then peer0 becomes a bad container for which I need to do a force stop.
rahulhegde (Fri, 10 Mar 2017 20:07:37 GMT):
@dave.enyeart
To set this log level - I went to the peer0 container and then executed ` peer logging getlevel gossip/discovery#172.19.0.4:7051 `. This is going in a loop and then peer0 becomes a bad container for which I need to do a force stop.
I hope there is nothing that I need execute those statement in the order - it is logger-name that identifies the stream.
rahulhegde (Fri, 10 Mar 2017 20:10:46 GMT):
I manager to execute ` gossip/comm#-1 ERROR ` but i was still able to see logs reported for logger = gossip/comm#-1 ERROR
rahulhegde (Fri, 10 Mar 2017 20:10:46 GMT):
I manager to execute ` gossip/comm#-1 ERROR ` but i was still able to see logs reported for logger = gossip/comm#-1
rahulhegde (Fri, 10 Mar 2017 20:10:46 GMT):
I manage to execute ` gossip/comm#-1 ERROR ` but i was still able to see logs reported for logger = gossip/comm#-1
rahulhegde (Fri, 10 Mar 2017 20:27:44 GMT):
Is there a way I can control it during start of peer - runtime looks like it goes in some lock.
AdnanC (Fri, 10 Mar 2017 20:29:04 GMT):
@rahulhegde hmm, I haven't tried that. If you are blocked, maybe we can ask someone in the fabric-gossip channel on how to reduce the gossip logs
AdnanC (Fri, 10 Mar 2017 20:31:13 GMT):
@rahulhegde I asked there and tagged you
rahulhegde (Fri, 10 Mar 2017 20:38:26 GMT):
Yes - I am blocked right now. I need to know if my transaction is getting rejected or if there is any fabric issue.
rahulhegde (Fri, 10 Mar 2017 20:38:26 GMT):
Yes - I am blocked right now. I need to know if my transaction is getting rejected or if there is any fabric issue. I can see successfully endorsed JSON document in the couch-db.
rahulhegde (Fri, 10 Mar 2017 20:38:26 GMT):
Yes - I am blocked right now. I need to know if my transaction is getting rejected (less-chances) or if there is any fabric issue. I can't see successfully endorsed JSON document in the couch-db.
rahulhegde (Fri, 10 Mar 2017 20:38:26 GMT):
Yes - I am blocked right now. I need to know if my transaction is getting rejected (less-chances) or if there is any fabric issue. I can't see the JSON document represented via a successfully endorsed proposal
rahulhegde (Fri, 10 Mar 2017 20:38:26 GMT):
Yes - I am blocked right now. I need to know if my transaction is getting rejected (less-chances) or if there is any fabric issue. I can't see the JSON document represented via a successfully endorsed proposal
I am running Fabric-Images (4th March) with klaemo/couchDB. Using the Peer CLI - got a successful Endorsement Proposal response however I am not able to see the JSON node in the couch DB (after it sending it to the orderer).
1. Checked using fauzton and http _find for _id > null = returns me only 2 nodes lccc
MartinMateev (Fri, 10 Mar 2017 20:47:54 GMT):
root@6f5135770b0c:/opt/gopath/src/github.com/hyperledger/fabric/peer# CONFIGTX_ORDERER_BATCHTIMEOUT=2s peer channel create -o orderer:7050 -c mychannel -f crypto/orderer/channel.tx
2017-03-10 20:45:30.736 UTC [msp] Sign -> DEBU 008 Sign: plaintext: 0ADD070A1508021A0608EAA08CC60522...00120D1A0B08FFFFFFFFFFFFFFFFFF01
2017-03-10 20:45:30.737 UTC [msp] Sign -> DEBU 009 Sign: digest: FA3020DA3BA085097206176273031DCA2710C515471AFCA1D50C4C1D64601AB1
Got status &{FORBIDDEN}
Error receiving: EOF
Error: EOF
MartinMateev (Fri, 10 Mar 2017 20:48:35 GMT):
I'm trying to follow the end-to-end.rst example
AdnanC (Fri, 10 Mar 2017 20:52:34 GMT):
@MartinMateev are you running the example in current fabric, or from changeset 7097?
AdnanC (Fri, 10 Mar 2017 20:52:34 GMT):
@MartinMateev are you running the example in current abric, or from changeset 7097?
MartinMateev (Fri, 10 Mar 2017 20:53:27 GMT):
7097
AdnanC (Fri, 10 Mar 2017 20:54:05 GMT):
Did it work ok with the current-fabric example?
AdnanC (Fri, 10 Mar 2017 20:54:05 GMT):
Did it work ok with the current-fabric example? @MartinMateev
MartinMateev (Fri, 10 Mar 2017 20:55:49 GMT):
trying now ...
MartinMateev (Fri, 10 Mar 2017 20:58:34 GMT):
the complexity of the fabric project is mind boggling : )
MartinMateev (Fri, 10 Mar 2017 21:01:21 GMT):
btw - is there a reason why blockchain explorer support hasn't been planned for ver.1.0 ?
MartinMateev (Fri, 10 Mar 2017 21:01:58 GMT):
I think it's very educational to be able to quickly spin up a blockchain explorer and figure out what's going on
AdnanC (Fri, 10 Mar 2017 21:07:23 GMT):
@MartinMateev you can try the directions given in "All in one", you can spin up a network and run end-to-end test in 4 commands (clone fabic repo, do couple of makes, and run the script)
rahulhegde (Fri, 10 Mar 2017 21:27:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=TZGRso93xEvLiczgN) @rahulhegde @dave.enyeart @AdnanC
I think I got the problem ==> I did not specify the endorsing policy at instantiation and hence successfully endorsed proposal gets rejected at the Peer committer level.
separate question: Shouldn't fabric-transaction have beed accepted by the ledger?
rahulhegde (Fri, 10 Mar 2017 21:27:39 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=TZGRso93xEvLiczgN) @rahulhegde @dave.enyeart @AdnanC @muralisr
I think I got the problem ==> I did not specify the endorsing policy at instantiation and hence successfully endorsed proposal gets rejected at the Peer committer level.
Separate Question: Shouldn't fabric-transaction have been accepted by the ledger since no endorsement policy was defined for the chaincode or should -P option on the peer CLI made mandatory during instantiation?
muralisr (Sat, 11 Mar 2017 01:37:39 GMT):
@rahulhegde the default is at least one signature from any of the principals ( @aso )
aso (Sat, 11 Mar 2017 01:37:39 GMT):
Has joined the channel.
rahulhegde (Sat, 11 Mar 2017 01:44:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=vsuJ3tXnNxRjhXrc3) @muralisr so above described scenario is the above described scenario
rahulhegde (Sat, 11 Mar 2017 01:44:10 GMT):
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=vsuJ3tXnNxRjhXrc3) @muralisr so the above described scenario is a defect, as it was endorsed by a organization member but not committed? What log I must monitor to understand a transaction is rejected by committer?
zakir2k (Sat, 11 Mar 2017 06:54:02 GMT):
Has joined the channel.
amilazzo (Mon, 13 Mar 2017 15:57:23 GMT):
Has joined the channel.
antoniovassell (Mon, 13 Mar 2017 16:25:07 GMT):
Has joined the channel.
dave.enyeart (Mon, 13 Mar 2017 17:01:25 GMT):
@rahulhegde The peer log will tell you if a tran gets invalidated, using the default logging. If you want more details, enable peer debug: `CORE_LOGGING_LEVEL=DEBUG peer node start`
NiharDalal (Tue, 14 Mar 2017 00:01:18 GMT):
Has joined the channel.
NiharDalal (Tue, 14 Mar 2017 00:04:13 GMT):
Hey guys! I'm trying to create a new blockchain with my own block structure. I would like to be able to store different types of data on the block. What file should I edit to be able to modify the block structure? Thanks
CarlXK (Tue, 14 Mar 2017 09:09:51 GMT):
how to implement the data separation in the same channel , fabric provide the feature or we need to implement it ourself?
gatakka (Tue, 14 Mar 2017 09:10:52 GMT):
@CarlXK channels are the main way for data separation. You can have as many channels as you wish.
gatakka (Tue, 14 Mar 2017 09:10:52 GMT):
@CarlXK channels are the main way for data separation. You can have as many channels as you wish joined by same peers.
CarlXK (Tue, 14 Mar 2017 09:13:20 GMT):
could we share data between two channels?
CarlXK (Tue, 14 Mar 2017 09:14:29 GMT):
@gatakka
CarlXK (Tue, 14 Mar 2017 09:15:26 GMT):
just like in the two processes, also could share data or invoke method
gatakka (Tue, 14 Mar 2017 09:17:30 GMT):
@CarlXK it is in design of fabric, but not sure is it implemented at this point in time and what will be the limitations.
gatakka (Tue, 14 Mar 2017 09:19:19 GMT):
You can always separate data in one channel using some simple logic as key prefix/suffix and write chaincode in such a way that separate data. In terms of the actual ledger it stores bytes, it is not conserned about data itself. This is responsability of chaincode
CarlXK (Tue, 14 Mar 2017 09:25:48 GMT):
the data in channel are transparent for peers who joined the channel, peers could deploy a chaincode to get all data, right?
CarlXK (Tue, 14 Mar 2017 09:26:07 GMT):
@gatakka
gatakka (Tue, 14 Mar 2017 09:27:44 GMT):
exactly, one peer can be in multiple channels and one channel can have multiple chaincodes. In this every chaincode in the channel can access same data, but because are different chaincodes you can add different policies who can execute operation on this chaincode
gatakka (Tue, 14 Mar 2017 09:27:44 GMT):
exactly, one peer can be in multiple channels and one channel can have multiple chaincodes. In this case every chaincode in the channel can access same data, but because are different chaincodes you can add different policies who can execute operation on this chaincode
CarlXK (Tue, 14 Mar 2017 09:30:08 GMT):
Got it , many thanks~
gatakka (Tue, 14 Mar 2017 09:30:43 GMT):
np
bh4rtp (Tue, 14 Mar 2017 15:15:24 GMT):
@AdnanC hi, i am testing marbles02 using e2e_cli docker images. the install step is passed. how to write instantiate command?
bh4rtp (Tue, 14 Mar 2017 15:16:04 GMT):
peer chaincode instantiate -o orderer0:7050 -C eprich1 -n mycc -v 1.0 -c '{"Args":["Init","marble1","red","50","tom"]}' -P "OR('Org0MSP.member','Org1MSP.member')"
bh4rtp (Tue, 14 Mar 2017 15:16:47 GMT):
an error message prints:
bh4rtp (Tue, 14 Mar 2017 15:16:51 GMT):
Error: Error endorsing chaincode: rpc error: code = 2 desc = Transaction returned with failure: Incorrect number of arguments. Expecting 4
Vadim (Tue, 14 Mar 2017 15:20:05 GMT):
@bh4rtp are you sure that you called your marbles chaincode "mycc" when you installed it?
bh4rtp (Tue, 14 Mar 2017 15:21:51 GMT):
@Vadim yes. I installed marbles02 using the name of mycc.
Vadim (Tue, 14 Mar 2017 15:22:43 GMT):
this message: "Incorrect number of arguments. Expecting 4" comes from the chaincode, but the marbles02 chaincode does not have this message in the code (https://github.com/hyperledger/fabric/edit/master/examples/chaincode/go/marbles02/marbles_chaincode.go)
Vadim (Tue, 14 Mar 2017 15:23:01 GMT):
so you are trying to instantiate some other chaincode
bh4rtp (Tue, 14 Mar 2017 15:23:31 GMT):
ok. let me check it.
Vadim (Tue, 14 Mar 2017 15:23:52 GMT):
could it be that you installed chaincode_example02 with the name mycc already before?
bh4rtp (Tue, 14 Mar 2017 15:28:46 GMT):
@Vadim you are absolutely right! i have installed chaincode_example02 named mycc. :blush:
ruslan.kryukov (Tue, 14 Mar 2017 15:44:21 GMT):
also you should pass -o orderer-ip:orderer-port
ruslan.kryukov (Tue, 14 Mar 2017 15:44:35 GMT):
ok
ruslan.kryukov (Tue, 14 Mar 2017 15:44:37 GMT):
)
bh4rtp (Tue, 14 Mar 2017 15:48:07 GMT):
@Vadim hi Vadim. i am confused. in the docker-compose-no-tls.yaml, there is a line '- ./examples/:/opt/gopath/src/github.com/hyperledger/fabric/examples/' in volumes. why cannot i find examples directory in the cli container, while i succeed in installing marble02 chaincode?
Vadim (Tue, 14 Mar 2017 15:48:57 GMT):
there is nothing on the path /opt/gopath/src/github.com/hyperledger/fabric/examples?
Vadim (Tue, 14 Mar 2017 15:49:11 GMT):
within the container?
bh4rtp (Tue, 14 Mar 2017 15:50:38 GMT):
root@c6eca5d0977a:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer chaincode query -o orderer0:7050 -C eprich1 -n marble -v 1.0 -c '{"Args":["readMarble","marble3"]}'
2017-03-14 15:50:11.084 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'chaincode'
2017-03-14 15:50:11.087 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-03-14 15:50:11.087 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
2017-03-14 15:50:11.088 UTC [msp] Sign -> DEBU 004 Sign: plaintext: 0A94050A5E0803220765707269636831...644D6172626C650A076D6172626C6533
2017-03-14 15:50:11.088 UTC [msp] Sign -> DEBU 005 Sign: digest: E90905BB8CD8180130C2D3AB406C299364AE47AA4125F84394CD73BA2FF1D115
Query Result: {"docType":"marble","name":"marble3","color":"blue","size":55,"owner":"allen"}
2017-03-14 15:50:11.092 UTC [main] main -> INFO 006 Exiting.....
root@c6eca5d0977a:/opt/gopath/src/github.com/hyperledger/fabric/peer# ls
crypto eprich1.block scripts
root@c6eca5d0977a:/opt/gopath/src/github.com/hyperledger/fabric/peer#
bh4rtp (Tue, 14 Mar 2017 15:51:50 GMT):
above are the output of my operations of chaincode query and ls.
Vadim (Tue, 14 Mar 2017 15:54:09 GMT):
is something incorrect there?
Vadim (Tue, 14 Mar 2017 15:54:35 GMT):
`Query Result: {"docType":"marble","name":"marble3","color":"blue","size":55,"owner":"allen"}`
Vadim (Tue, 14 Mar 2017 15:54:50 GMT):
looks like the query is successful
bh4rtp (Tue, 14 Mar 2017 16:07:41 GMT):
i have successfully tested initMarble, readMarble, transferMarler except couch supported functions.
bh4rtp (Tue, 14 Mar 2017 16:07:41 GMT):
i have successfully tested initMarble, readMarble, transferMarle except couch supported functions.
bh4rtp (Tue, 14 Mar 2017 16:07:41 GMT):
i have successfully tested initMarble, readMarble, transferMarle and other functions except couchdb supported functions.
bh4rtp (Tue, 14 Mar 2017 16:08:38 GMT):
so i don't know how the marble02 chaincode is installed from cli to peer0.
Vadim (Tue, 14 Mar 2017 16:13:06 GMT):
install instructs the peer0 to copy it to the local dir, it should end up somewhere in the /var/hyperledger/production/chaincodes
Vadim (Tue, 14 Mar 2017 16:13:06 GMT):
install instructs the peer0 to copy it to its local dir, it should end up somewhere in the /var/hyperledger/production/chaincodes
bh4rtp (Tue, 14 Mar 2017 16:21:55 GMT):
yes. peer0 has chaincode marble.
bh4rtp (Tue, 14 Mar 2017 16:21:59 GMT):
root@f2c1b0db231e:/var/hyperledger/production/chaincodes# ls
marble.1.0 mycc.1.0
bh4rtp (Tue, 14 Mar 2017 16:28:06 GMT):
i think marbles02 should be copy from cli:/opt/gopath/src/github.com/hyperledger/fabric/peer/examples/chaincode/go/marble02 to peer0:/var/hyperledger/production/chaincodes. but there is no /opt/gopath/src/github.com/hyperledger/fabric/peer/examples directory.
bh4rtp (Tue, 14 Mar 2017 16:28:06 GMT):
i think marbles02 should be copied from cli:/opt/gopath/src/github.com/hyperledger/fabric/peer/examples/chaincode/go/marble02 to peer0:/var/hyperledger/production/chaincodes. but there is no /opt/gopath/src/github.com/hyperledger/fabric/peer/examples directory.
bh4rtp (Tue, 14 Mar 2017 16:28:06 GMT):
i think marbles02 should be copied from cli:/opt/gopath/src/github.com/hyperledger/fabric/peer/examples/chaincode/go/marble02 to peer0:/var/hyperledger/production/chaincodes. but there is no /opt/gopath/src/github.com/hyperledger/fabric/peer/examples directory in cli container.
bh4rtp (Tue, 14 Mar 2017 16:28:06 GMT):
i think marbles02 should be copied from cli:/opt/gopath/src/github.com/hyperledger/fabric/peer/examples/chaincode/go/marble02 to peer0:/var/hyperledger/production/chaincodes as executing install command. but there is no /opt/gopath/src/github.com/hyperledger/fabric/peer/examples directory in cli container.
bh4rtp (Tue, 14 Mar 2017 16:28:22 GMT):
is this correct?
AdnanC (Tue, 14 Mar 2017 16:31:17 GMT):
I think, by default the cli does not have the full fabric repo, so it has to get the chaincode from somewhere, and the mounting does that
Vadim (Tue, 14 Mar 2017 16:32:42 GMT):
@bh4rtp it should be there, as I understand
bh4rtp (Tue, 14 Mar 2017 16:33:14 GMT):
@AdnanC yes. maybe examples is a mounting.
Vadim (Tue, 14 Mar 2017 16:34:12 GMT):
so if you bash to the cli container and then do ls /opt/gopath/src/github.com/hyperledger/fabric/peer/examples, you get an error?
Vadim (Tue, 14 Mar 2017 16:34:12 GMT):
so if you bash to the cli container and then do `ls /opt/gopath/src/github.com/hyperledger/fabric/peer/examples`, you get an error?
bh4rtp (Tue, 14 Mar 2017 16:34:39 GMT):
@Vadim let me have a try.
AdnanC (Tue, 14 Mar 2017 16:34:42 GMT):
@Vadim without the mounting, I think there will be an error
Vadim (Tue, 14 Mar 2017 16:34:50 GMT):
well t
Vadim (Tue, 14 Mar 2017 16:34:50 GMT):
well it mounts in in the image
Vadim (Tue, 14 Mar 2017 16:35:07 GMT):
in the composer yaml
Vadim (Tue, 14 Mar 2017 16:35:07 GMT):
in the compose yaml
bh4rtp (Tue, 14 Mar 2017 16:35:13 GMT):
yes. ls: cannot access 'examples': No such file or directory
Vadim (Tue, 14 Mar 2017 16:35:53 GMT):
https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/docker-compose-no-tls.yaml#L123
Vadim (Tue, 14 Mar 2017 16:37:42 GMT):
and if you do `find / -name marble02` within the container?
bh4rtp (Tue, 14 Mar 2017 16:38:32 GMT):
root@c6eca5d0977a:/# find / -name marbles02
/opt/gopath/src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02
Vadim (Tue, 14 Mar 2017 16:38:46 GMT):
so it's there?
bh4rtp (Tue, 14 Mar 2017 16:38:51 GMT):
that's interesting. docker is awesome.
AdnanC (Tue, 14 Mar 2017 16:39:11 GMT):
@bh4rtp [ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ntA5YG485uSxdSikr) @bh4rtp you cannot `ls` the directory with the docker compose as is? or you tried with mount lines removed?
AdnanC (Tue, 14 Mar 2017 16:39:11 GMT):
@bh4rtp [ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ntA5YG485uSxdSikr) @bh4rtp you cannot `ls` the directory with the docker compose as is? or you tried with mount lines remove?
bh4rtp (Tue, 14 Mar 2017 16:41:05 GMT):
i am sorry. i have mistaken examples is subfolder of peer. wasting time :innocent:
bh4rtp (Tue, 14 Mar 2017 16:41:05 GMT):
i am sorry. i have mistaken examples is subfolder of fabric/peer. wasting time :innocent:
bh4rtp (Tue, 14 Mar 2017 16:41:05 GMT):
i am sorry. i have mistaken examples is a subfolder of fabric/peer. wasting time :innocent:
Vadim (Tue, 14 Mar 2017 16:41:12 GMT):
:D
bh4rtp (Tue, 14 Mar 2017 16:42:53 GMT):
anyway. thank you very much! no confusion now. @AdnanC @Vadim
lignyxg (Tue, 14 Mar 2017 17:25:24 GMT):
Has joined the channel.
karysto (Tue, 14 Mar 2017 20:47:57 GMT):
Has joined the channel.
dhuseby (Tue, 14 Mar 2017 22:56:14 GMT):
Has joined the channel.
bh4rtp (Wed, 15 Mar 2017 01:21:13 GMT):
@Vadim @AdnanC how to replace leveldb with couchdb? queryMarblesByOwner and queryMarbles are only supported by couchdb.
AdnanC (Wed, 15 Mar 2017 03:24:19 GMT):
@bh4rtp You can use the docker-compose here https://gerrit.hyperledger.org/r/#/c/7097/ there is also a readme attached. But please note that it is not merged yet and may change
bh4rtp (Wed, 15 Mar 2017 03:27:39 GMT):
thanks
bh4rtp (Wed, 15 Mar 2017 03:41:35 GMT):
i have done marbles02 with couchdb support. but transferMarble seems no function.
bh4rtp (Wed, 15 Mar 2017 03:41:35 GMT):
i have done marbles02 with couchdb support. but transferMarble seems no functioning.
bh4rtp (Wed, 15 Mar 2017 03:41:46 GMT):
2017-03-15 03:39:00.517 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-03-15 03:39:00.517 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
2017-03-15 03:39:00.518 UTC [msp] Sign -> DEBU 004 Sign: plaintext: 0A94050A5E0803220765707269636831...0A076D6172626C65320A056A65727279
2017-03-15 03:39:00.518 UTC [msp] Sign -> DEBU 005 Sign: digest: 05A8A82CC320D64E6F7FA3D1513C09281FDC5433AF6E60F567660DAAB6BA38CF
Query Result:
2017-03-15 03:39:00.550 UTC [main] main -> INFO 006 Exiting.....
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer chaincode query -o orderer0:7050 -C eprich1 -n marble -v 1.0 -c '{"Args":["queryMarblesByOwner","jerry"]}'
2017-03-15 03:39:07.301 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'chaincode'
2017-03-15 03:39:07.310 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-03-15 03:39:07.310 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
2017-03-15 03:39:07.311 UTC [msp] Sign -> DEBU 004 Sign: plaintext: 0A94050A5E0803220765707269636831...657342794F776E65720A056A65727279
2017-03-15 03:39:07.311 UTC [msp] Sign -> DEBU 005 Sign: digest: 55F728E401202438876F184EC922C158CFDB0669554CBC5A10EBA32FD8D9E415
Query Result: []
2017-03-15 03:39:07.369 UTC [main] main -> INFO 006 Exiting.....
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer#
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer#
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer#
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer# clear
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer chaincode query -o orderer0:7050 -C eprich1 -n marble -v 1.0 -c '{"Args":["readMarble","marble2"]}'
2017-03-15 03:40:56.275 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'chaincode'
2017-03-15 03:40:56.277 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-03-15 03:40:56.277 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
2017-03-15 03:40:56.278 UTC [msp] Sign -> DEBU 004 Sign: plaintext: 0A94050A5E0803220765707269636831...644D6172626C650A076D6172626C6532
2017-03-15 03:40:56.278 UTC [msp] Sign -> DEBU 005 Sign: digest: AA85C67A4162D6C20D2A937CD4D44E0F653782DDB63977783C4848F5E0CDD8BA
Query Result: {"color":"blue","docType":"marble","name":"marble2","owner":"tom","size":35}
2017-03-15 03:40:56.289 UTC [main] main -> INFO 006 Exiting.....
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer chaincode query -o orderer0:7050 -C eprich1 -n marble -v 1.0 -c '{"Args":["transferMarble","marble2", "jerry"]}'
2017-03-15 03:41:10.622 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'chaincode'
2017-03-15 03:41:10.625 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-03-15 03:41:10.626 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
2017-03-15 03:41:10.626 UTC [msp] Sign -> DEBU 004 Sign: plaintext: 0A94050A5E0803220765707269636831...0A076D6172626C65320A056A65727279
2017-03-15 03:41:10.627 UTC [msp] Sign -> DEBU 005 Sign: digest: B05D8A9A869BAB2A3CA689602673963A8DA6373C4EB2081BA8BADA36D41F7ED9
Query Result:
2017-03-15 03:41:10.637 UTC [main] main -> INFO 006 Exiting.....
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer chaincode query -o orderer0:7050 -C eprich1 -n marble -v 1.0 -c '{"Args":["queryMarblesByOwner","jerry"]}'
2017-03-15 03:41:20.930 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'chaincode'
2017-03-15 03:41:20.933 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-03-15 03:41:20.933 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
2017-03-15 03:41:20.934 UTC [msp] Sign -> DEBU 004 Sign: plaintext: 0A94050A5E0803220765707269636831...657342794F776E65720A056A65727279
2017-03-15 03:41:20.934 UTC [msp] Sign -> DEBU 005 Sign: digest: 1DB8FA9DC1CFDBE9337DF9A092D08A108B71BFBFC32F164ABC93422CEE202775
Query Result: []
2017-03-15 03:41:20.974 UTC [main] main -> INFO 006 Exiting.....
bh4rtp (Wed, 15 Mar 2017 03:41:46 GMT):
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer chaincode query -o orderer0:7050 -C eprich1 -n marble -v 1.0 -c '{"Args":["readMarble","marble2"]}'
2017-03-15 03:40:56.275 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'chaincode'
2017-03-15 03:40:56.277 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-03-15 03:40:56.277 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
2017-03-15 03:40:56.278 UTC [msp] Sign -> DEBU 004 Sign: plaintext: 0A94050A5E0803220765707269636831...644D6172626C650A076D6172626C6532
2017-03-15 03:40:56.278 UTC [msp] Sign -> DEBU 005 Sign: digest: AA85C67A4162D6C20D2A937CD4D44E0F653782DDB63977783C4848F5E0CDD8BA
Query Result: {"color":"blue","docType":"marble","name":"marble2","owner":"tom","size":35}
2017-03-15 03:40:56.289 UTC [main] main -> INFO 006 Exiting.....
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer chaincode query -o orderer0:7050 -C eprich1 -n marble -v 1.0 -c '{"Args":["transferMarble","marble2", "jerry"]}'
2017-03-15 03:41:10.622 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'chaincode'
2017-03-15 03:41:10.625 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-03-15 03:41:10.626 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
2017-03-15 03:41:10.626 UTC [msp] Sign -> DEBU 004 Sign: plaintext: 0A94050A5E0803220765707269636831...0A076D6172626C65320A056A65727279
2017-03-15 03:41:10.627 UTC [msp] Sign -> DEBU 005 Sign: digest: B05D8A9A869BAB2A3CA689602673963A8DA6373C4EB2081BA8BADA36D41F7ED9
Query Result:
2017-03-15 03:41:10.637 UTC [main] main -> INFO 006 Exiting.....
root@e1d72b265aad:/opt/gopath/src/github.com/hyperledger/fabric/peer# peer chaincode query -o orderer0:7050 -C eprich1 -n marble -v 1.0 -c '{"Args":["queryMarblesByOwner","jerry"]}'
2017-03-15 03:41:20.930 UTC [logging] InitFromViper -> DEBU 001 Setting default logging level to DEBUG for command 'chaincode'
2017-03-15 03:41:20.933 UTC [msp] GetLocalMSP -> DEBU 002 Returning existing local MSP
2017-03-15 03:41:20.933 UTC [msp] GetDefaultSigningIdentity -> DEBU 003 Obtaining default signing identity
2017-03-15 03:41:20.934 UTC [msp] Sign -> DEBU 004 Sign: plaintext: 0A94050A5E0803220765707269636831...657342794F776E65720A056A65727279
2017-03-15 03:41:20.934 UTC [msp] Sign -> DEBU 005 Sign: digest: 1DB8FA9DC1CFDBE9337DF9A092D08A108B71BFBFC32F164ABC93422CEE202775
Query Result: []
2017-03-15 03:41:20.974 UTC [main] main -> INFO 006 Exiting.....
bh4rtp (Wed, 15 Mar 2017 07:08:33 GMT):
i found the reason. invoke should be used for transferMarble, but not query.
bh4rtp (Wed, 15 Mar 2017 07:08:50 GMT):
peer chaincode invoke -o orderer0:7050 -C eprich1 -n marble -v 1.0 -c '{"Args":["transferMarble","marble2", "jerry"]}'
jansony1 (Wed, 15 Mar 2017 10:45:17 GMT):
Hi ,
Does anyone know the difference between order ledger and peer ledger? Or what exactly the order ledger is ?
dave.enyeart (Wed, 15 Mar 2017 11:48:02 GMT):
@bh4rtp - Yes, the sample command in marbles02 for transfer is 'invoke'. For queries the tran does not get submitted for ordering/commit. For invokes the tran gets submitted for ordering/commit.
dave.enyeart (Wed, 15 Mar 2017 11:51:22 GMT):
@jansony1 OrdererLedger is a subset of PeerLedger. OrdererLedger has block storage only, it persistently stores the blocks for Ordering service in case other peers ask for the blocks later. PeerLedger has block storage plus state database plus history index. These extra components are needed for transactions and queries on peer. The Ordering service does not process transactions or queries and therefore these components are left out of OrdererLedger.
Vadim (Wed, 15 Mar 2017 11:53:09 GMT):
@dave.enyeart does each channel has it's own blockchain?
Vadim (Wed, 15 Mar 2017 11:53:09 GMT):
@dave.enyeart does each channel has its own blockchain?
dave.enyeart (Wed, 15 Mar 2017 11:54:28 GMT):
yes, here's a slide to explain:
dave.enyeart (Wed, 15 Mar 2017 11:54:35 GMT):
Message Attachments
mychewcents (Wed, 15 Mar 2017 12:29:15 GMT):
Has joined the channel.
balashevich (Wed, 15 Mar 2017 12:35:46 GMT):
Has joined the channel.
bh4rtp (Wed, 15 Mar 2017 13:02:26 GMT):
@dave.enyeart is this slide from fabric 1.0 online doc?
bh4rtp (Wed, 15 Mar 2017 13:05:02 GMT):
@Vadim every channel has its own blockchain. the channel and its genesis block are generated simultaneously using configtxgen tool.
dave.enyeart (Wed, 15 Mar 2017 13:14:17 GMT):
I am giving the slide to doc team... not sure if it will get included in doc as-is, likely some form of it will get into doc though.
jansony1 (Wed, 15 Mar 2017 14:26:19 GMT):
@dave.enyeart Thanks for your input,and little more deep dive. Whether the orderledger will keep the prehash and metadata things just like peerledger, which keeps it immutablely
dave.enyeart (Wed, 15 Mar 2017 14:28:31 GMT):
yes, block hashes are the same across OrdererLedger and PeerLedger, so that when the next block arrives from ordering all the hashes match up. The metadata is actually not included in the hash.
jansony1 (Wed, 15 Mar 2017 14:34:09 GMT):
@dave.enyeart thanks so much ！！ And I wonder where i could get those design docs in more detail？
dave.enyeart (Wed, 15 Mar 2017 14:34:56 GMT):
https://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html
jansony1 (Wed, 15 Mar 2017 14:35:54 GMT):
@dave.enyeart thanks
bkvellanki (Wed, 15 Mar 2017 15:39:21 GMT):
@dave.enyeart as per the diagram the replication happens only for the peers of the same org. What is shared or replicated across different banks (A,B,C) if they are on the same channel..
Vadim (Wed, 15 Mar 2017 15:40:25 GMT):
@bkvellanki I guess they have blockchains for all channels they are participants of
bkvellanki (Wed, 15 Mar 2017 15:41:23 GMT):
But as per the slide it says Bank A cannot see the trasactions of B and C
Vadim (Wed, 15 Mar 2017 15:41:28 GMT):
and actually the case you are asking about is on the diagram
Vadim (Wed, 15 Mar 2017 15:41:59 GMT):
yes, because it's not on the BC channel
Vadim (Wed, 15 Mar 2017 15:42:09 GMT):
it's on AB and AC channels
bkvellanki (Wed, 15 Mar 2017 15:42:42 GMT):
ooh ook..
bkvellanki (Wed, 15 Mar 2017 15:42:47 GMT):
got it..thanks
berserkr (Wed, 15 Mar 2017 15:43:47 GMT):
is there a reason why we use channels and cannot share data across chaincode?
berserkr (Wed, 15 Mar 2017 15:44:33 GMT):
the state for chaincode is unique to each chain code as far as I know, so to me, the introduction of channels is simply for increased throughput?
berserkr (Wed, 15 Mar 2017 15:45:25 GMT):
or is it because you want isolation of transactions as well as world state? maybe the latter, but could you guys give me a quick explanation
berserkr (Wed, 15 Mar 2017 15:45:58 GMT):
also, have the fabric built outside of vagrant, I can run the bddtests, though some of them are failing
berserkr (Wed, 15 Mar 2017 15:46:08 GMT):
is there a way for me to stress test the dbs?
Vadim (Wed, 15 Mar 2017 15:49:02 GMT):
@berserkr its for data isolation
Vadim (Wed, 15 Mar 2017 15:49:02 GMT):
@berserkr channels are for data isolation
dave.enyeart (Wed, 15 Mar 2017 15:49:49 GMT):
right, data isolation/privacy is the main reason for channels. additional throughput is a side benefit.
Vadim (Wed, 15 Mar 2017 15:50:14 GMT):
probably, also some storage savings on peers
berserkr (Wed, 15 Mar 2017 17:25:49 GMT):
data isolation in terms of what? world state is isolated, each chain code has access to its own state
berserkr (Wed, 15 Mar 2017 17:26:03 GMT):
do you mean isolation wrt what is in the tx parameters?
dave.enyeart (Wed, 15 Mar 2017 18:12:01 GMT):
see the chart pasted above to illustrate the data isolation. e.g BankA cannot see transactions between BankB-BankC.
berserkr (Wed, 15 Mar 2017 20:48:01 GMT):
@dave.enyeart , for v1, is leveldb used at all? or is couchdb used for everything?
dave.enyeart (Wed, 15 Mar 2017 22:17:37 GMT):
leveldb is the default state database. couchdb is an alternate option. please review the ledger charts where all this is explained:
dave.enyeart (Wed, 15 Mar 2017 22:17:45 GMT):
@berserkr https://jira.hyperledger.org/browse/FAB-758
berserkr (Wed, 15 Mar 2017 22:36:26 GMT):
got it, thank you!
bkvellanki (Wed, 15 Mar 2017 23:23:39 GMT):
@dave.enyeart Is there a document that shows how to setup and configure a new Org, Peer..I think it starts with MSP first
dave.enyeart (Wed, 15 Mar 2017 23:55:41 GMT):
i'd suggest to start with these instructions: https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst
bkvellanki (Thu, 16 Mar 2017 00:21:14 GMT):
I have that functional with my chaincode installed and tested..
bh4rtp (Thu, 16 Mar 2017 00:31:15 GMT):
@dave.enyeart the documentation of examples/e2e_cli/end_to_end.rst is very nice! :thumbsup:
jansony1 (Thu, 16 Mar 2017 12:00:09 GMT):
HI
I think the gensis block of a channel would define acl and other things, and all the chaincode deployed on this channel would build on this gensis block as the first block. From the ACL of the gensis block, we could know who could join this channel. While what if a new member would join this channel, based on the ACL list already defined in the first gensis block and could not be modified
muralisr (Thu, 16 Mar 2017 12:06:17 GMT):
@jansony1 there will be support for "configuration update" where you can refresh the configuration
jansony1 (Thu, 16 Mar 2017 12:41:03 GMT):
@muralisr thanks. And may I know if got the right understanding about the flow?
muralisr (Thu, 16 Mar 2017 12:43:17 GMT):
@jansony1 it sounded close enough but I'm sure some thoughts can be refined. For example `and all the chaincode deployed on this channel would build on this gensis block as the first block` is not the way I'd have looked at it myslef
muralisr (Thu, 16 Mar 2017 12:43:40 GMT):
there are two types of transactions "configuration" and "endorsement"
muralisr (Thu, 16 Mar 2017 12:43:56 GMT):
chaincodes participate in the endorsement flows
muralisr (Thu, 16 Mar 2017 12:46:46 GMT):
the access control (for example who can send "invoke" to chaincode on a channel) depends upon "Configuration" transcation and the config is stored on the blockchain. The genesis block obviously would have to be such a config transaction (obtained when the peer joins the channel) but we could send config updates to alter it future where it'll end up as an updated configuraton tx in a block in the blockchain
muralisr (Thu, 16 Mar 2017 12:47:47 GMT):
the "orderer" participates intimately in such configuaration transactions... I'd suggest for more question on such flows do check in fabric-consensus too
muralisr (Thu, 16 Mar 2017 12:50:15 GMT):
also would check in fabric-crypto
jansony1 (Thu, 16 Mar 2017 13:08:54 GMT):
@muralisr, what about the join things? I mean peer join -channel , where set the limitation on who could join the peer, or there is no such limitation?
jansony1 (Thu, 16 Mar 2017 13:11:30 GMT):
sorry, i mean who could join channel
muralisr (Thu, 16 Mar 2017 13:11:44 GMT):
@jansony1 you'd specificy orgs in a channel at the time of channel create
jansony1 (Thu, 16 Mar 2017 13:12:30 GMT):
And store those things on genesis block(configuration block), is that right?
muralisr (Thu, 16 Mar 2017 13:12:48 GMT):
correct
jansony1 (Thu, 16 Mar 2017 13:12:56 GMT):
bingo~!
jansony1 (Thu, 16 Mar 2017 13:13:16 GMT):
Finally i got the overall flow~~~~Really appreciate it..
muralisr (Thu, 16 Mar 2017 13:14:33 GMT):
again do capture when you have a chance in fabric-consensus as (1) we can refine it further and (2) it could be useful for others
muralisr (Thu, 16 Mar 2017 13:15:04 GMT):
or "fabric"
jansony1 (Thu, 16 Mar 2017 13:16:24 GMT):
Actually, i am not sure where to ask this question. Cause v1's consensus quit different from v0.6, and not sure whether it belong to there..
muralisr (Thu, 16 Mar 2017 13:17:20 GMT):
the "orderer" in 1.0 (consensus) plays a central role in configuration
muralisr (Thu, 16 Mar 2017 13:17:25 GMT):
hence my suggestion
muralisr (Thu, 16 Mar 2017 13:17:41 GMT):
however "fabric" would work as well
muralisr (Thu, 16 Mar 2017 13:18:21 GMT):
some people might miss looking for it in fabric-ledger... entirely upto you of course!
jansony1 (Thu, 16 Mar 2017 13:19:09 GMT):
@muralisr thanks, I would refine my question to make it more clear and ask again. THanks again
muralisr (Thu, 16 Mar 2017 13:20:00 GMT):
absolutely! to be clear, I think you have already flushed out the central ideas ... my suggestion is about further details
jansony1 (Thu, 16 Mar 2017 13:20:32 GMT):
yep ! thats what a engineer should do :grinning:
muralisr (Thu, 16 Mar 2017 13:22:02 GMT):
:-)
bh4rtp (Thu, 16 Mar 2017 13:28:12 GMT):
hi, does e2e_cli only demonstrate the grpc calling between cli <-> peers and cli <-> orderer? are there new blocks generated therefore? if yes, how to print the new blocks?
apspeical (Fri, 17 Mar 2017 01:43:32 GMT):
Has joined the channel.
xixuejia (Fri, 17 Mar 2017 03:41:46 GMT):
@bh4rtp there are new blocks generated. you could use block-listener to print the new blocks
bh4rtp (Fri, 17 Mar 2017 03:47:30 GMT):
@xixuejia thanks. it is preferred to find a demo using block-listener. :blush:
xixuejia (Fri, 17 Mar 2017 03:49:19 GMT):
@bh4rtp Please refer to examples/events/block-listener/block-listener.go. Is this what you are looking for?
bh4rtp (Fri, 17 Mar 2017 03:57:12 GMT):
@xixuejia thanks again!
RahulBagaria (Fri, 17 Mar 2017 04:01:58 GMT):
Has joined the channel.
andyxf1029 (Fri, 17 Mar 2017 06:09:04 GMT):
Has joined the channel.
bh4rtp (Fri, 17 Mar 2017 06:48:23 GMT):
@xixuejia i have got blocks printed successfully. as for peer0 in the marble02 example, peer channel join, peer chaincode install, peer chaincode instantiate, 4 peer chaincode invoke and other peer chaincode query commands were run. while block-listener received 6 blocks in total. the first block is very long with many many certificates. i think it would be the genesis block. the other 5 blocks are much shorter. i think the last 4 blocks will be generated by 4 peer chaincode invoke commands. which command was the second block generated by?
bh4rtp (Fri, 17 Mar 2017 06:48:23 GMT):
@xixuejia i have got blocks printed successfully. as for peer0 in the marble02 example, peer channel join, peer chaincode install, peer chaincode instantiate, 4 peer chaincode invoke and other peer chaincode query commands were run. the block-listener received 6 blocks in total. the first block is very long with many certificates. i think it would be the genesis block. the other 5 blocks are much shorter. i think the last 4 blocks will be generated by 4 peer chaincode invoke commands. which command was the second block generated by?
zhouer (Fri, 17 Mar 2017 06:53:16 GMT):
Has joined the channel.
xixuejia (Fri, 17 Mar 2017 07:05:45 GMT):
@bh4rtp It should be generated by `instantiate`
bh4rtp (Fri, 17 Mar 2017 07:10:47 GMT):
@xixuejia yes, i just verified that the second one is generated by instantiate. why is the genesis block so long and does't install generate a new block?
Vadim (Fri, 17 Mar 2017 07:58:32 GMT):
@bh4rtp peer chaincode install only copies the chaincode to the file system of peer, the chaincode ends up somewhere in /var/hyperledger/production/chaincodes or something like that
bh4rtp (Fri, 17 Mar 2017 08:06:24 GMT):
@Vadim thanks. i am trying to analysis the block info. it is really obscure. :grinning:
Vadim (Fri, 17 Mar 2017 08:06:44 GMT):
did you check the proto files?
bh4rtp (Fri, 17 Mar 2017 08:07:29 GMT):
peer chaincode invoke -o orderer0:7050 -C eprich1 -n marble -v 1.0 -c '{"Args":["transferMarble","marble1", "allen"]}'
Received block
--------------
Received transaction from channel eprich1:
[header:
bh4rtp (Fri, 17 Mar 2017 08:08:01 GMT):
i paste the block info here. maybe someone can interpret it.
Vadim (Fri, 17 Mar 2017 08:08:04 GMT):
I think you should check the proto files, it will be easier to map it then to that output
bh4rtp (Fri, 17 Mar 2017 08:08:31 GMT):
@Vadim ok. it is a good idea. thanks.
Vadim (Fri, 17 Mar 2017 08:10:25 GMT):
@bh4rtp it's in https://github.com/hyperledger/fabric/blob/master/protos/common/common.proto
bh4rtp (Fri, 17 Mar 2017 08:11:26 GMT):
@Vadim trying to check it byte by byte. :blush:
Vadim (Fri, 17 Mar 2017 08:11:38 GMT):
:D
MartinMateev (Fri, 17 Mar 2017 10:09:57 GMT):
any update on the couchDB docker image and e2e tests ?
nickmelis (Fri, 17 Mar 2017 10:18:46 GMT):
@MartinMateev I've only googled it but it looks like docker images that include couchdb are out there already
nickmelis (Fri, 17 Mar 2017 10:18:57 GMT):
if you know more I'm also interested
bh4rtp (Fri, 17 Mar 2017 11:31:30 GMT): bh4rtp (Fri, 17 Mar 2017 11:31:34 GMT): Vadim (Fri, 17 Mar 2017 11:34:16 GMT): bh4rtp (Fri, 17 Mar 2017 11:35:58 GMT): Vadim (Fri, 17 Mar 2017 11:36:38 GMT): bh4rtp (Fri, 17 Mar 2017 11:42:00 GMT): dave.enyeart (Fri, 17 Mar 2017 11:45:55 GMT): dave.enyeart (Fri, 17 Mar 2017 11:46:33 GMT): donjohnny (Fri, 17 Mar 2017 13:00:59 GMT): Vadim (Fri, 17 Mar 2017 13:13:57 GMT): ryokawajp (Fri, 17 Mar 2017 15:46:59 GMT): ryokawajp (Fri, 17 Mar 2017 15:47:46 GMT): ryokawajp (Fri, 17 Mar 2017 15:49:09 GMT): ryokawajp (Fri, 17 Mar 2017 15:50:34 GMT): ryokawajp (Fri, 17 Mar 2017 15:50:53 GMT): ryokawajp (Fri, 17 Mar 2017 15:52:13 GMT): ryokawajp (Fri, 17 Mar 2017 15:52:59 GMT): ryokawajp (Fri, 17 Mar 2017 15:53:50 GMT): ryokawajp (Fri, 17 Mar 2017 15:54:51 GMT): ryokawajp (Fri, 17 Mar 2017 15:56:55 GMT): dave.enyeart (Fri, 17 Mar 2017 17:30:06 GMT): karysto (Fri, 17 Mar 2017 19:05:44 GMT): karysto (Fri, 17 Mar 2017 19:06:14 GMT): karysto (Fri, 17 Mar 2017 19:06:51 GMT): karysto (Fri, 17 Mar 2017 19:07:06 GMT): karysto (Fri, 17 Mar 2017 19:07:37 GMT): karysto (Fri, 17 Mar 2017 19:07:41 GMT): karysto (Fri, 17 Mar 2017 19:07:41 GMT): karysto (Fri, 17 Mar 2017 19:08:10 GMT): karysto (Fri, 17 Mar 2017 19:08:29 GMT): karysto (Fri, 17 Mar 2017 19:09:03 GMT): karysto (Fri, 17 Mar 2017 19:09:14 GMT): karysto (Fri, 17 Mar 2017 19:09:58 GMT): karysto (Fri, 17 Mar 2017 19:10:35 GMT): karysto (Fri, 17 Mar 2017 19:11:32 GMT): karysto (Fri, 17 Mar 2017 19:13:21 GMT): bh4rtp (Sat, 18 Mar 2017 02:43:14 GMT): ryokawajp (Sat, 18 Mar 2017 07:40:03 GMT): ryokawajp (Sat, 18 Mar 2017 07:40:03 GMT): ruslan.kryukov (Sat, 18 Mar 2017 12:10:27 GMT): dave.enyeart (Sat, 18 Mar 2017 12:52:09 GMT): ruslan.kryukov (Sat, 18 Mar 2017 13:05:37 GMT): passkit (Sun, 19 Mar 2017 12:23:20 GMT): hycind (Sun, 19 Mar 2017 19:51:23 GMT): jansony1 (Mon, 20 Mar 2017 02:59:48 GMT): GeorgeSamman (Mon, 20 Mar 2017 03:50:57 GMT): passkit (Mon, 20 Mar 2017 04:28:44 GMT): jansony1 (Mon, 20 Mar 2017 04:54:22 GMT): yahtoo (Mon, 20 Mar 2017 10:12:42 GMT): dorrakhribi (Mon, 20 Mar 2017 10:24:14 GMT): K Sai Anirudh (Mon, 20 Mar 2017 11:53:33 GMT): K Sai Anirudh (Mon, 20 Mar 2017 11:55:24 GMT): ruslan.kryukov (Mon, 20 Mar 2017 14:10:21 GMT): ruslan.kryukov (Mon, 20 Mar 2017 14:10:46 GMT): ruslan.kryukov (Mon, 20 Mar 2017 14:11:15 GMT): openspylin (Mon, 20 Mar 2017 15:13:04 GMT): openspylin (Mon, 20 Mar 2017 16:11:38 GMT): dave.enyeart (Mon, 20 Mar 2017 16:33:10 GMT): ruslan.kryukov (Mon, 20 Mar 2017 16:51:55 GMT): ruslan.kryukov (Mon, 20 Mar 2017 16:51:55 GMT): ruslan.kryukov (Mon, 20 Mar 2017 16:51:55 GMT): ruslan.kryukov (Mon, 20 Mar 2017 16:51:55 GMT): ruslan.kryukov (Mon, 20 Mar 2017 16:51:55 GMT): ruslan.kryukov (Mon, 20 Mar 2017 17:14:52 GMT): openspylin (Tue, 21 Mar 2017 00:35:27 GMT): jansony1 (Tue, 21 Mar 2017 01:56:26 GMT): jansony1 (Tue, 21 Mar 2017 02:48:14 GMT): SyneBlockChainTeam (Tue, 21 Mar 2017 12:36:42 GMT): dave.enyeart (Tue, 21 Mar 2017 15:01:16 GMT): bkvellanki (Tue, 21 Mar 2017 15:45:27 GMT): bkvellanki (Tue, 21 Mar 2017 15:46:20 GMT): AdnanC (Tue, 21 Mar 2017 15:48:41 GMT): AdnanC (Tue, 21 Mar 2017 15:48:41 GMT): bkvellanki (Tue, 21 Mar 2017 15:48:48 GMT): AdnanC (Tue, 21 Mar 2017 15:49:19 GMT): bkvellanki (Tue, 21 Mar 2017 15:50:41 GMT): bkvellanki (Tue, 21 Mar 2017 15:51:21 GMT): AdnanC (Tue, 21 Mar 2017 15:52:59 GMT): AdnanC (Tue, 21 Mar 2017 15:53:34 GMT): rahulhegde (Tue, 21 Mar 2017 16:05:24 GMT): rahulhegde (Tue, 21 Mar 2017 16:05:24 GMT): rahulhegde (Tue, 21 Mar 2017 16:05:24 GMT): rahulhegde (Tue, 21 Mar 2017 16:05:24 GMT): rahulhegde (Tue, 21 Mar 2017 16:05:24 GMT): rahulhegde (Tue, 21 Mar 2017 16:05:24 GMT): raj (Tue, 21 Mar 2017 17:30:18 GMT): shanlusun (Wed, 22 Mar 2017 01:40:36 GMT): pd93 (Wed, 22 Mar 2017 09:32:36 GMT): pd93 (Wed, 22 Mar 2017 09:43:24 GMT): rahulhegde (Wed, 22 Mar 2017 10:42:29 GMT): Vadim (Wed, 22 Mar 2017 10:46:07 GMT): agaragiola (Wed, 22 Mar 2017 13:02:48 GMT): PushpalathaHiremath (Thu, 23 Mar 2017 04:38:44 GMT): pd93 (Thu, 23 Mar 2017 08:54:29 GMT): pd93 (Thu, 23 Mar 2017 08:54:47 GMT): pd93 (Thu, 23 Mar 2017 08:54:47 GMT): pd93 (Thu, 23 Mar 2017 08:55:38 GMT): PushpalathaHiremath (Thu, 23 Mar 2017 08:55:58 GMT): PushpalathaHiremath (Thu, 23 Mar 2017 08:56:50 GMT): pd93 (Thu, 23 Mar 2017 08:57:12 GMT): pd93 (Thu, 23 Mar 2017 08:57:12 GMT): pd93 (Thu, 23 Mar 2017 08:57:12 GMT): pd93 (Thu, 23 Mar 2017 08:58:52 GMT): PushpalathaHiremath (Thu, 23 Mar 2017 08:58:53 GMT): pd93 (Thu, 23 Mar 2017 08:59:07 GMT): pd93 (Thu, 23 Mar 2017 09:00:00 GMT): pd93 (Thu, 23 Mar 2017 09:00:00 GMT): pd93 (Thu, 23 Mar 2017 09:00:00 GMT): pd93 (Thu, 23 Mar 2017 09:00:00 GMT): PushpalathaHiremath (Thu, 23 Mar 2017 09:02:11 GMT): PushpalathaHiremath (Thu, 23 Mar 2017 09:03:19 GMT): PushpalathaHiremath (Thu, 23 Mar 2017 09:03:19 GMT): pd93 (Thu, 23 Mar 2017 09:06:08 GMT): PushpalathaHiremath (Thu, 23 Mar 2017 09:08:40 GMT): pd93 (Thu, 23 Mar 2017 09:09:34 GMT): pd93 (Thu, 23 Mar 2017 09:11:19 GMT): pd93 (Thu, 23 Mar 2017 09:11:19 GMT): pd93 (Thu, 23 Mar 2017 09:12:28 GMT): PushpalathaHiremath (Thu, 23 Mar 2017 09:38:19 GMT): PushpalathaHiremath (Thu, 23 Mar 2017 09:38:44 GMT): RahulAgrawal (Thu, 23 Mar 2017 10:19:10 GMT): passkit (Thu, 23 Mar 2017 10:50:42 GMT): passkit (Thu, 23 Mar 2017 10:51:07 GMT): pd93 (Thu, 23 Mar 2017 11:08:16 GMT): pd93 (Thu, 23 Mar 2017 11:09:19 GMT): subbu165 (Thu, 23 Mar 2017 15:39:15 GMT): farhan3 (Thu, 23 Mar 2017 15:43:58 GMT): farhan3 (Thu, 23 Mar 2017 15:44:32 GMT): farhan3 (Thu, 23 Mar 2017 15:48:19 GMT): passkit (Thu, 23 Mar 2017 16:37:55 GMT): passkit (Thu, 23 Mar 2017 16:38:45 GMT): passkit (Thu, 23 Mar 2017 16:38:45 GMT): passkit (Thu, 23 Mar 2017 16:43:38 GMT): dave.enyeart (Thu, 23 Mar 2017 17:11:35 GMT): dave.enyeart (Thu, 23 Mar 2017 17:12:18 GMT): nickgaski (Thu, 23 Mar 2017 17:12:49 GMT): farhan3 (Thu, 23 Mar 2017 17:13:17 GMT): farhan3 (Thu, 23 Mar 2017 18:00:04 GMT): cgrecu (Thu, 23 Mar 2017 18:07:45 GMT): Wenyang Liu (Thu, 23 Mar 2017 18:08:45 GMT): pd93 (Thu, 23 Mar 2017 18:27:32 GMT): AdnanC (Thu, 23 Mar 2017 18:46:48 GMT): pd93 (Thu, 23 Mar 2017 18:51:27 GMT): pd93 (Thu, 23 Mar 2017 18:51:42 GMT): AdnanC (Thu, 23 Mar 2017 18:54:18 GMT): AdnanC (Thu, 23 Mar 2017 18:54:18 GMT): AdnanC (Thu, 23 Mar 2017 18:54:18 GMT): pd93 (Thu, 23 Mar 2017 18:54:49 GMT): AdnanC (Thu, 23 Mar 2017 18:56:01 GMT): pd93 (Thu, 23 Mar 2017 18:56:16 GMT): AdnanC (Thu, 23 Mar 2017 18:56:41 GMT): pd93 (Thu, 23 Mar 2017 18:56:52 GMT): pd93 (Thu, 23 Mar 2017 19:18:37 GMT): AdnanC (Thu, 23 Mar 2017 20:19:06 GMT): pd93 (Thu, 23 Mar 2017 20:23:23 GMT): pd93 (Thu, 23 Mar 2017 20:23:23 GMT): pd93 (Thu, 23 Mar 2017 20:23:23 GMT): AdnanC (Thu, 23 Mar 2017 20:24:41 GMT): AdnanC (Thu, 23 Mar 2017 20:24:41 GMT): pd93 (Thu, 23 Mar 2017 20:25:11 GMT): pd93 (Thu, 23 Mar 2017 20:35:25 GMT): AdnanC (Thu, 23 Mar 2017 20:51:45 GMT): pd93 (Thu, 23 Mar 2017 20:55:52 GMT): pd93 (Thu, 23 Mar 2017 20:56:05 GMT): pd93 (Thu, 23 Mar 2017 20:56:19 GMT): AdnanC (Thu, 23 Mar 2017 20:59:36 GMT): pd93 (Thu, 23 Mar 2017 21:00:44 GMT): AdnanC (Thu, 23 Mar 2017 21:10:46 GMT): AdnanC (Thu, 23 Mar 2017 21:10:46 GMT): AdnanC (Thu, 23 Mar 2017 21:11:10 GMT): AdnanC (Thu, 23 Mar 2017 21:11:10 GMT): pd93 (Thu, 23 Mar 2017 21:24:24 GMT): AdnanC (Thu, 23 Mar 2017 21:25:18 GMT): AdnanC (Thu, 23 Mar 2017 21:25:18 GMT): AdnanC (Thu, 23 Mar 2017 21:25:18 GMT): bobbiejc (Fri, 24 Mar 2017 01:32:49 GMT): pd93 (Fri, 24 Mar 2017 08:53:24 GMT): ruslan.kryukov (Fri, 24 Mar 2017 11:41:05 GMT): ruslan.kryukov (Fri, 24 Mar 2017 11:41:21 GMT): ruslan.kryukov (Fri, 24 Mar 2017 11:43:10 GMT): ruslan.kryukov (Fri, 24 Mar 2017 11:45:29 GMT): dhwang (Fri, 24 Mar 2017 13:22:00 GMT): joe-alewine (Fri, 24 Mar 2017 13:58:29 GMT): passkit (Sat, 25 Mar 2017 00:05:32 GMT): passkit (Sat, 25 Mar 2017 00:05:32 GMT): passkit (Sat, 25 Mar 2017 00:12:02 GMT): passkit (Sat, 25 Mar 2017 00:12:02 GMT): passkit (Sat, 25 Mar 2017 00:12:44 GMT): passkit (Sat, 25 Mar 2017 00:56:22 GMT): ruslan.kryukov (Sat, 25 Mar 2017 03:41:32 GMT): matanyahu (Sat, 25 Mar 2017 06:45:37 GMT): matanyahu (Sat, 25 Mar 2017 06:46:22 GMT): ruslan.kryukov (Sat, 25 Mar 2017 09:00:55 GMT): dave.enyeart (Sat, 25 Mar 2017 14:49:06 GMT): mastersingh24 (Sun, 26 Mar 2017 13:16:27 GMT): dave.enyeart (Sun, 26 Mar 2017 14:36:37 GMT): mastersingh24 (Sun, 26 Mar 2017 14:37:12 GMT): mastersingh24 (Sun, 26 Mar 2017 14:39:33 GMT): dave.enyeart (Sun, 26 Mar 2017 14:41:08 GMT): dave.enyeart (Sun, 26 Mar 2017 14:41:08 GMT): mastersingh24 (Sun, 26 Mar 2017 14:43:22 GMT): yacovm (Sun, 26 Mar 2017 16:17:52 GMT): yacovm (Sun, 26 Mar 2017 16:17:52 GMT): DG0011 (Sun, 26 Mar 2017 16:52:54 GMT): DG0011 (Sun, 26 Mar 2017 16:56:03 GMT): bh4rtp (Mon, 27 Mar 2017 02:15:21 GMT): bh4rtp (Mon, 27 Mar 2017 02:15:27 GMT): bh4rtp (Mon, 27 Mar 2017 02:16:32 GMT): dave.enyeart (Mon, 27 Mar 2017 08:18:05 GMT): DG0011 (Mon, 27 Mar 2017 23:51:41 GMT): berserkr (Tue, 28 Mar 2017 06:09:01 GMT): berserkr (Tue, 28 Mar 2017 06:09:11 GMT): berserkr (Tue, 28 Mar 2017 06:09:32 GMT): berserkr (Tue, 28 Mar 2017 06:10:02 GMT): berserkr (Tue, 28 Mar 2017 06:10:29 GMT): jansony1 (Tue, 28 Mar 2017 06:47:43 GMT): RahulAgrawal (Tue, 28 Mar 2017 06:54:42 GMT): xixuejia (Tue, 28 Mar 2017 08:08:59 GMT): jansony1 (Tue, 28 Mar 2017 08:10:28 GMT): xixuejia (Tue, 28 Mar 2017 08:11:03 GMT): xixuejia (Tue, 28 Mar 2017 08:13:17 GMT): RahulAgrawal (Tue, 28 Mar 2017 08:18:54 GMT): RahulAgrawal (Tue, 28 Mar 2017 08:18:54 GMT): xixuejia (Tue, 28 Mar 2017 08:23:31 GMT): xixuejia (Tue, 28 Mar 2017 08:23:50 GMT): Vadim (Tue, 28 Mar 2017 08:24:53 GMT): xixuejia (Tue, 28 Mar 2017 08:25:54 GMT): RahulAgrawal (Tue, 28 Mar 2017 08:37:16 GMT): Vadim (Tue, 28 Mar 2017 08:37:53 GMT): jansony1 (Tue, 28 Mar 2017 08:38:22 GMT): RahulAgrawal (Tue, 28 Mar 2017 08:41:05 GMT): Vadim (Tue, 28 Mar 2017 08:42:47 GMT): Vadim (Tue, 28 Mar 2017 08:42:47 GMT): Vadim (Tue, 28 Mar 2017 08:43:52 GMT): jansony1 (Tue, 28 Mar 2017 08:52:32 GMT): Vadim (Tue, 28 Mar 2017 08:53:13 GMT): RahulAgrawal (Tue, 28 Mar 2017 08:53:54 GMT): jansony1 (Tue, 28 Mar 2017 08:54:00 GMT): Vadim (Tue, 28 Mar 2017 08:54:17 GMT): Vadim (Tue, 28 Mar 2017 08:55:27 GMT): RahulAgrawal (Tue, 28 Mar 2017 08:58:26 GMT): Vadim (Tue, 28 Mar 2017 08:59:53 GMT): PushpalathaHiremath (Tue, 28 Mar 2017 11:25:55 GMT): dave.enyeart (Tue, 28 Mar 2017 11:44:35 GMT): dave.enyeart (Tue, 28 Mar 2017 11:44:55 GMT): dave.enyeart (Tue, 28 Mar 2017 11:45:41 GMT): dave.enyeart (Tue, 28 Mar 2017 11:45:41 GMT): dave.enyeart (Tue, 28 Mar 2017 11:47:00 GMT): dave.enyeart (Tue, 28 Mar 2017 11:47:32 GMT): dave.enyeart (Tue, 28 Mar 2017 11:48:24 GMT): PushpalathaHiremath (Tue, 28 Mar 2017 12:05:41 GMT): berserkr (Tue, 28 Mar 2017 12:37:20 GMT): jaemin.lim (Tue, 28 Mar 2017 16:56:28 GMT): rahulhegde (Tue, 28 Mar 2017 18:20:19 GMT): rahulhegde (Tue, 28 Mar 2017 18:20:19 GMT): rahulhegde (Tue, 28 Mar 2017 18:20:19 GMT): rahulhegde (Tue, 28 Mar 2017 18:20:19 GMT): rahulhegde (Tue, 28 Mar 2017 18:20:19 GMT): dave.enyeart (Tue, 28 Mar 2017 18:22:23 GMT): dave.enyeart (Tue, 28 Mar 2017 18:57:25 GMT): dave.enyeart (Tue, 28 Mar 2017 18:57:25 GMT): dorrakhribi (Tue, 28 Mar 2017 21:06:24 GMT): farhan3 (Tue, 28 Mar 2017 21:30:44 GMT): dorrakhribi (Wed, 29 Mar 2017 09:23:43 GMT): Vadim (Wed, 29 Mar 2017 09:24:29 GMT): dorrakhribi (Wed, 29 Mar 2017 09:43:06 GMT): Vadim (Wed, 29 Mar 2017 09:44:57 GMT): Vadim (Wed, 29 Mar 2017 09:45:39 GMT): dorrakhribi (Wed, 29 Mar 2017 09:50:23 GMT): Vadim (Wed, 29 Mar 2017 09:50:51 GMT): dorrakhribi (Wed, 29 Mar 2017 09:52:17 GMT): dorrakhribi (Wed, 29 Mar 2017 09:53:40 GMT): Vadim (Wed, 29 Mar 2017 09:54:00 GMT): dorrakhribi (Wed, 29 Mar 2017 09:56:43 GMT): Vadim (Wed, 29 Mar 2017 09:58:13 GMT): dorrakhribi (Wed, 29 Mar 2017 10:03:33 GMT): dorrakhribi (Wed, 29 Mar 2017 10:04:03 GMT): dorrakhribi (Wed, 29 Mar 2017 10:04:44 GMT): dorrakhribi (Wed, 29 Mar 2017 10:04:46 GMT): Vadim (Wed, 29 Mar 2017 10:40:56 GMT): dorrakhribi (Wed, 29 Mar 2017 10:41:41 GMT): dorrakhribi (Wed, 29 Mar 2017 10:41:54 GMT): Vadim (Wed, 29 Mar 2017 10:44:50 GMT): dorrakhribi (Wed, 29 Mar 2017 11:40:45 GMT): FenglianXu (Wed, 29 Mar 2017 15:25:16 GMT): MrMoneyChanger (Wed, 29 Mar 2017 18:19:19 GMT): bkvellanki (Wed, 29 Mar 2017 18:19:24 GMT): bkvellanki (Wed, 29 Mar 2017 18:21:11 GMT): MrMoneyChanger (Wed, 29 Mar 2017 18:26:18 GMT): MrMoneyChanger (Wed, 29 Mar 2017 18:26:52 GMT): MrMoneyChanger (Wed, 29 Mar 2017 18:27:43 GMT): MrMoneyChanger (Wed, 29 Mar 2017 18:28:20 GMT): dave.enyeart (Thu, 30 Mar 2017 02:36:28 GMT): passkit (Thu, 30 Mar 2017 03:07:46 GMT): dave.enyeart (Thu, 30 Mar 2017 10:58:46 GMT): dorrakhribi (Thu, 30 Mar 2017 22:43:02 GMT): berserkr (Fri, 31 Mar 2017 03:42:17 GMT): berserkr (Fri, 31 Mar 2017 03:42:46 GMT): berserkr (Fri, 31 Mar 2017 03:44:20 GMT): akashmar (Fri, 31 Mar 2017 13:48:00 GMT): openspylin (Sun, 02 Apr 2017 12:38:38 GMT): aybekbuka (Sun, 02 Apr 2017 15:13:50 GMT): mastersingh24 (Mon, 03 Apr 2017 12:23:05 GMT): bobbiejc (Mon, 03 Apr 2017 21:48:59 GMT): AdnanC (Mon, 03 Apr 2017 21:52:21 GMT): AdnanC (Mon, 03 Apr 2017 21:52:21 GMT): bobbiejc (Mon, 03 Apr 2017 21:53:45 GMT): bobbiejc (Mon, 03 Apr 2017 21:53:54 GMT): AdnanC (Mon, 03 Apr 2017 21:54:14 GMT): bobbiejc (Mon, 03 Apr 2017 21:54:39 GMT): bobbiejc (Mon, 03 Apr 2017 21:56:11 GMT): bobbiejc (Mon, 03 Apr 2017 21:56:16 GMT): AdnanC (Mon, 03 Apr 2017 21:56:28 GMT): dave.enyeart (Tue, 04 Apr 2017 00:26:03 GMT): dave.enyeart (Tue, 04 Apr 2017 00:27:33 GMT): bobbiejc (Tue, 04 Apr 2017 00:32:13 GMT): bobbiejc (Tue, 04 Apr 2017 00:32:37 GMT): bobbiejc (Tue, 04 Apr 2017 00:32:53 GMT): bobbiejc (Tue, 04 Apr 2017 00:33:09 GMT): bobbiejc (Tue, 04 Apr 2017 00:33:26 GMT): tiennv (Tue, 04 Apr 2017 16:01:27 GMT): AmberZhang (Wed, 05 Apr 2017 09:41:38 GMT): crazybit (Thu, 06 Apr 2017 01:38:22 GMT): crazybit (Thu, 06 Apr 2017 01:38:22 GMT): crazybit (Thu, 06 Apr 2017 01:42:15 GMT): C0rWin (Thu, 06 Apr 2017 02:06:19 GMT): lizhih (Thu, 06 Apr 2017 09:46:51 GMT): passkit (Thu, 06 Apr 2017 11:14:58 GMT): manish-sethi (Thu, 06 Apr 2017 11:17:18 GMT): passkit (Thu, 06 Apr 2017 11:17:42 GMT): manish-sethi (Thu, 06 Apr 2017 11:19:10 GMT): passkit (Thu, 06 Apr 2017 11:45:58 GMT): manish-sethi (Thu, 06 Apr 2017 11:47:20 GMT): dave.enyeart (Thu, 06 Apr 2017 11:53:23 GMT): dave.enyeart (Thu, 06 Apr 2017 11:53:54 GMT): manish-sethi (Thu, 06 Apr 2017 11:58:20 GMT): dave.enyeart (Thu, 06 Apr 2017 12:01:55 GMT): dave.enyeart (Thu, 06 Apr 2017 12:02:20 GMT): dave.enyeart (Thu, 06 Apr 2017 12:02:20 GMT): dave.enyeart (Thu, 06 Apr 2017 12:03:17 GMT): manish-sethi (Thu, 06 Apr 2017 12:10:48 GMT): dave.enyeart (Thu, 06 Apr 2017 12:12:05 GMT): dave.enyeart (Thu, 06 Apr 2017 12:12:49 GMT): dave.enyeart (Thu, 06 Apr 2017 12:13:31 GMT): manish-sethi (Thu, 06 Apr 2017 12:14:52 GMT): manish-sethi (Thu, 06 Apr 2017 12:15:38 GMT): manish-sethi (Thu, 06 Apr 2017 12:16:48 GMT): dave.enyeart (Thu, 06 Apr 2017 12:16:57 GMT): manish-sethi (Thu, 06 Apr 2017 12:18:40 GMT): dave.enyeart (Thu, 06 Apr 2017 12:19:39 GMT): manish-sethi (Thu, 06 Apr 2017 12:19:52 GMT): passkit (Thu, 06 Apr 2017 12:20:02 GMT): dave.enyeart (Thu, 06 Apr 2017 12:21:56 GMT): dave.enyeart (Thu, 06 Apr 2017 12:23:07 GMT): manish-sethi (Thu, 06 Apr 2017 12:23:29 GMT): manish-sethi (Thu, 06 Apr 2017 12:24:58 GMT): dave.enyeart (Thu, 06 Apr 2017 12:27:38 GMT): manish-sethi (Thu, 06 Apr 2017 12:27:39 GMT): manish-sethi (Thu, 06 Apr 2017 12:28:21 GMT): manish-sethi (Thu, 06 Apr 2017 12:28:30 GMT): dave.enyeart (Thu, 06 Apr 2017 12:28:35 GMT): dave.enyeart (Thu, 06 Apr 2017 12:29:08 GMT): manish-sethi (Thu, 06 Apr 2017 12:29:24 GMT): dave.enyeart (Thu, 06 Apr 2017 12:29:42 GMT): muralisr (Thu, 06 Apr 2017 20:52:52 GMT): muralisr (Thu, 06 Apr 2017 20:53:14 GMT): dave.enyeart (Thu, 06 Apr 2017 20:57:28 GMT): dave.enyeart (Thu, 06 Apr 2017 20:57:28 GMT): rahulhegde (Thu, 06 Apr 2017 20:59:37 GMT): rahulhegde (Thu, 06 Apr 2017 20:59:37 GMT): dave.enyeart (Thu, 06 Apr 2017 21:00:00 GMT): rahulhegde (Thu, 06 Apr 2017 21:00:22 GMT): Claude-ZHENG (Fri, 07 Apr 2017 00:22:43 GMT): Claude-ZHENG (Fri, 07 Apr 2017 00:28:33 GMT): passkit (Fri, 07 Apr 2017 03:46:29 GMT): passkit (Fri, 07 Apr 2017 03:48:18 GMT): passkit (Fri, 07 Apr 2017 03:48:18 GMT): passkit (Fri, 07 Apr 2017 03:50:42 GMT): passkit (Fri, 07 Apr 2017 04:01:20 GMT): passkit (Fri, 07 Apr 2017 04:22:37 GMT): passkit (Fri, 07 Apr 2017 04:24:21 GMT): passkit (Fri, 07 Apr 2017 04:24:21 GMT): passkit (Fri, 07 Apr 2017 04:24:21 GMT): Vadim (Fri, 07 Apr 2017 06:09:43 GMT): passkit (Fri, 07 Apr 2017 06:10:42 GMT): Vadim (Fri, 07 Apr 2017 06:12:08 GMT): Vadim (Fri, 07 Apr 2017 06:12:23 GMT): mychewcents (Fri, 07 Apr 2017 06:14:54 GMT): passkit (Fri, 07 Apr 2017 06:19:56 GMT): passkit (Fri, 07 Apr 2017 06:19:58 GMT): passkit (Fri, 07 Apr 2017 06:20:24 GMT): passkit (Fri, 07 Apr 2017 06:21:59 GMT): passkit (Fri, 07 Apr 2017 06:21:59 GMT): Vadim (Fri, 07 Apr 2017 06:25:52 GMT): Vadim (Fri, 07 Apr 2017 06:26:06 GMT): Vadim (Fri, 07 Apr 2017 06:26:06 GMT): passkit (Fri, 07 Apr 2017 06:26:16 GMT): Vadim (Fri, 07 Apr 2017 06:26:29 GMT): passkit (Fri, 07 Apr 2017 06:26:30 GMT): Vadim (Fri, 07 Apr 2017 06:26:52 GMT): passkit (Fri, 07 Apr 2017 06:27:22 GMT): Vadim (Fri, 07 Apr 2017 06:27:34 GMT): Vadim (Fri, 07 Apr 2017 06:27:46 GMT): Vadim (Fri, 07 Apr 2017 06:28:11 GMT): Vadim (Fri, 07 Apr 2017 06:28:11 GMT): Vadim (Fri, 07 Apr 2017 06:28:44 GMT): passkit (Fri, 07 Apr 2017 06:28:45 GMT): Vadim (Fri, 07 Apr 2017 06:28:57 GMT): Vadim (Fri, 07 Apr 2017 06:29:08 GMT): Vadim (Fri, 07 Apr 2017 06:29:08 GMT): Vadim (Fri, 07 Apr 2017 06:30:12 GMT): passkit (Fri, 07 Apr 2017 06:31:48 GMT): passkit (Fri, 07 Apr 2017 06:32:15 GMT): Vadim (Fri, 07 Apr 2017 06:32:30 GMT): passkit (Fri, 07 Apr 2017 06:32:30 GMT): Vadim (Fri, 07 Apr 2017 06:32:46 GMT): passkit (Fri, 07 Apr 2017 06:33:51 GMT): passkit (Fri, 07 Apr 2017 06:33:51 GMT): Vadim (Fri, 07 Apr 2017 06:35:21 GMT): passkit (Fri, 07 Apr 2017 06:35:28 GMT): Vadim (Fri, 07 Apr 2017 06:35:38 GMT): passkit (Fri, 07 Apr 2017 06:35:46 GMT): Vadim (Fri, 07 Apr 2017 06:35:52 GMT): Vadim (Fri, 07 Apr 2017 06:36:03 GMT): passkit (Fri, 07 Apr 2017 06:36:18 GMT): Vadim (Fri, 07 Apr 2017 06:36:30 GMT): passkit (Fri, 07 Apr 2017 06:39:28 GMT): passkit (Fri, 07 Apr 2017 06:47:16 GMT): passkit (Fri, 07 Apr 2017 06:48:00 GMT): Vadim (Fri, 07 Apr 2017 06:51:30 GMT): Vadim (Fri, 07 Apr 2017 06:53:28 GMT): Vadim (Fri, 07 Apr 2017 06:53:41 GMT): passkit (Fri, 07 Apr 2017 06:54:16 GMT): passkit (Fri, 07 Apr 2017 06:57:43 GMT): Vadim (Fri, 07 Apr 2017 06:57:55 GMT): Vadim (Fri, 07 Apr 2017 06:58:39 GMT): passkit (Fri, 07 Apr 2017 06:58:42 GMT): Vadim (Fri, 07 Apr 2017 06:59:03 GMT): passkit (Fri, 07 Apr 2017 06:59:32 GMT): passkit (Fri, 07 Apr 2017 06:59:32 GMT): passkit (Fri, 07 Apr 2017 07:00:05 GMT): Vadim (Fri, 07 Apr 2017 07:00:39 GMT): Vadim (Fri, 07 Apr 2017 07:00:55 GMT): Vadim (Fri, 07 Apr 2017 07:01:02 GMT): passkit (Fri, 07 Apr 2017 07:01:23 GMT): Vadim (Fri, 07 Apr 2017 07:01:41 GMT): passkit (Fri, 07 Apr 2017 07:03:22 GMT): passkit (Fri, 07 Apr 2017 07:03:44 GMT): Vadim (Fri, 07 Apr 2017 07:04:08 GMT): passkit (Fri, 07 Apr 2017 07:04:51 GMT): passkit (Fri, 07 Apr 2017 07:06:39 GMT): passkit (Fri, 07 Apr 2017 07:07:01 GMT): Vadim (Fri, 07 Apr 2017 07:11:27 GMT): Vadim (Fri, 07 Apr 2017 07:11:36 GMT): passkit (Fri, 07 Apr 2017 07:34:31 GMT): passkit (Fri, 07 Apr 2017 07:34:52 GMT): passkit (Fri, 07 Apr 2017 07:36:57 GMT): passkit (Fri, 07 Apr 2017 08:11:56 GMT): passkit (Fri, 07 Apr 2017 08:12:43 GMT): Vadim (Fri, 07 Apr 2017 08:12:54 GMT): passkit (Fri, 07 Apr 2017 08:13:37 GMT): Vadim (Fri, 07 Apr 2017 08:14:23 GMT): Vadim (Fri, 07 Apr 2017 08:15:07 GMT): passkit (Fri, 07 Apr 2017 08:15:25 GMT): Vadim (Fri, 07 Apr 2017 08:16:15 GMT): passkit (Fri, 07 Apr 2017 08:16:19 GMT): passkit (Fri, 07 Apr 2017 08:17:00 GMT): Vadim (Fri, 07 Apr 2017 08:17:13 GMT): Vadim (Fri, 07 Apr 2017 08:18:52 GMT): Vadim (Fri, 07 Apr 2017 08:19:20 GMT): passkit (Fri, 07 Apr 2017 08:27:38 GMT): Vadim (Fri, 07 Apr 2017 08:29:26 GMT): pd93 (Fri, 07 Apr 2017 11:30:37 GMT): chris.elder (Fri, 07 Apr 2017 13:29:24 GMT): chris.elder (Fri, 07 Apr 2017 13:33:38 GMT): Honglei (Mon, 10 Apr 2017 00:28:38 GMT): nhrishi (Mon, 10 Apr 2017 09:46:36 GMT): bh4rtp (Mon, 10 Apr 2017 09:57:12 GMT): pd93 (Mon, 10 Apr 2017 10:47:44 GMT): chris.elder (Mon, 10 Apr 2017 10:48:31 GMT): chris.elder (Mon, 10 Apr 2017 10:48:46 GMT): StuartWilloughby (Mon, 10 Apr 2017 10:50:44 GMT): zian (Mon, 10 Apr 2017 13:59:10 GMT): s.narayanan (Mon, 10 Apr 2017 18:04:12 GMT): jeroiraz (Mon, 10 Apr 2017 18:40:46 GMT): jdockter (Tue, 11 Apr 2017 14:41:44 GMT): dave.enyeart (Tue, 11 Apr 2017 14:44:37 GMT): dave.enyeart (Tue, 11 Apr 2017 14:45:38 GMT): jdockter (Tue, 11 Apr 2017 14:51:36 GMT): dave.enyeart (Tue, 11 Apr 2017 14:52:52 GMT): jdockter (Tue, 11 Apr 2017 14:52:52 GMT): dave.enyeart (Tue, 11 Apr 2017 14:53:23 GMT): jdockter (Tue, 11 Apr 2017 14:53:48 GMT): dave.enyeart (Tue, 11 Apr 2017 14:55:54 GMT): jdockter (Tue, 11 Apr 2017 14:59:31 GMT): dave.enyeart (Tue, 11 Apr 2017 15:01:04 GMT): dave.enyeart (Tue, 11 Apr 2017 15:03:13 GMT): dave.enyeart (Tue, 11 Apr 2017 15:03:14 GMT): nhrishi (Tue, 11 Apr 2017 15:10:22 GMT): dave.enyeart (Tue, 11 Apr 2017 15:17:48 GMT): dave.enyeart (Tue, 11 Apr 2017 15:18:57 GMT): nhrishi (Tue, 11 Apr 2017 15:20:59 GMT): bkvellanki (Tue, 11 Apr 2017 16:49:30 GMT): Lin-YiTang (Tue, 11 Apr 2017 21:19:37 GMT): leungjob (Wed, 12 Apr 2017 03:56:05 GMT): subbu165 (Wed, 12 Apr 2017 06:50:30 GMT): dave.enyeart (Wed, 12 Apr 2017 10:38:33 GMT): C0rWin (Wed, 12 Apr 2017 11:48:00 GMT): subbu165 (Wed, 12 Apr 2017 12:45:12 GMT): C0rWin (Wed, 12 Apr 2017 12:45:40 GMT): msoumeit (Wed, 12 Apr 2017 17:09:09 GMT): PushpalathaHiremath (Wed, 12 Apr 2017 18:29:59 GMT): dave.enyeart (Thu, 13 Apr 2017 07:07:12 GMT): dave.enyeart (Thu, 13 Apr 2017 07:07:12 GMT): epal (Thu, 13 Apr 2017 07:32:34 GMT): epal (Thu, 13 Apr 2017 07:41:37 GMT): epal (Thu, 13 Apr 2017 07:54:21 GMT): somashekarn (Thu, 13 Apr 2017 09:17:19 GMT): gdhh (Thu, 13 Apr 2017 14:30:39 GMT): feronti (Thu, 13 Apr 2017 18:02:19 GMT): rahulhegde (Sat, 15 Apr 2017 17:06:04 GMT): rahulhegde (Sat, 15 Apr 2017 17:06:04 GMT): rahulhegde (Sat, 15 Apr 2017 17:06:04 GMT): rahulhegde (Sat, 15 Apr 2017 17:06:04 GMT): PushpalathaHiremath (Mon, 17 Apr 2017 08:48:57 GMT): muralisr (Mon, 17 Apr 2017 08:52:09 GMT): PushpalathaHiremath (Mon, 17 Apr 2017 08:54:12 GMT): muralisr (Mon, 17 Apr 2017 08:55:21 GMT): PushpalathaHiremath (Mon, 17 Apr 2017 10:00:37 GMT): muralisr (Mon, 17 Apr 2017 10:06:35 GMT): epal (Tue, 18 Apr 2017 07:36:07 GMT): epal (Tue, 18 Apr 2017 07:38:48 GMT): dave.enyeart (Tue, 18 Apr 2017 13:18:19 GMT): epal (Tue, 18 Apr 2017 13:19:55 GMT): jdockter (Tue, 18 Apr 2017 14:20:59 GMT): SotirisAlfonsos (Wed, 19 Apr 2017 10:37:39 GMT): dave.enyeart (Wed, 19 Apr 2017 11:02:38 GMT): manish-sethi (Wed, 19 Apr 2017 12:00:53 GMT): manish-sethi (Wed, 19 Apr 2017 12:00:53 GMT): epal (Wed, 19 Apr 2017 12:11:37 GMT): manish-sethi (Wed, 19 Apr 2017 12:22:24 GMT): epal (Wed, 19 Apr 2017 12:23:57 GMT): epal (Wed, 19 Apr 2017 12:25:08 GMT): epal (Wed, 19 Apr 2017 12:25:53 GMT): manish-sethi (Wed, 19 Apr 2017 12:27:02 GMT): manish-sethi (Wed, 19 Apr 2017 12:27:02 GMT): epal (Wed, 19 Apr 2017 12:29:18 GMT): manish-sethi (Wed, 19 Apr 2017 12:29:37 GMT): farhan3 (Wed, 19 Apr 2017 15:55:22 GMT): dave.enyeart (Thu, 20 Apr 2017 12:01:59 GMT): dorrakhribi (Thu, 20 Apr 2017 13:38:41 GMT): kostas (Thu, 20 Apr 2017 13:47:02 GMT): farhan3 (Thu, 20 Apr 2017 15:25:32 GMT): kostas (Thu, 20 Apr 2017 15:37:19 GMT): farhan3 (Thu, 20 Apr 2017 15:41:34 GMT): mastersingh24 (Thu, 20 Apr 2017 18:22:29 GMT): dave.enyeart (Thu, 20 Apr 2017 18:29:52 GMT): dave.enyeart (Thu, 20 Apr 2017 18:29:52 GMT): mastersingh24 (Thu, 20 Apr 2017 18:30:21 GMT): mastersingh24 (Thu, 20 Apr 2017 18:30:21 GMT): johnsacco (Thu, 20 Apr 2017 21:33:58 GMT): Xoccam (Fri, 21 Apr 2017 08:42:24 GMT): bkvellanki (Fri, 21 Apr 2017 15:07:20 GMT): dave.enyeart (Fri, 21 Apr 2017 15:56:56 GMT): bkvellanki (Fri, 21 Apr 2017 16:05:34 GMT): bkvellanki (Fri, 21 Apr 2017 16:10:58 GMT): dave.enyeart (Fri, 21 Apr 2017 16:16:43 GMT): bkvellanki (Fri, 21 Apr 2017 16:17:38 GMT): vdods (Mon, 24 Apr 2017 21:43:11 GMT): vdods (Mon, 24 Apr 2017 21:43:27 GMT): tennenjl (Tue, 25 Apr 2017 14:51:41 GMT): tennenjl (Tue, 25 Apr 2017 15:12:43 GMT): dave.enyeart (Tue, 25 Apr 2017 18:43:01 GMT): tennenjl (Tue, 25 Apr 2017 18:44:50 GMT): matanyahu (Tue, 25 Apr 2017 19:03:10 GMT): dave.enyeart (Tue, 25 Apr 2017 19:49:54 GMT): matanyahu (Tue, 25 Apr 2017 19:51:53 GMT): dave.enyeart (Tue, 25 Apr 2017 20:56:29 GMT): rangak (Wed, 26 Apr 2017 04:07:09 GMT): matanyahu (Wed, 26 Apr 2017 08:52:50 GMT): matanyahu (Wed, 26 Apr 2017 08:53:15 GMT): matanyahu (Wed, 26 Apr 2017 08:53:23 GMT): dorrakhribi (Wed, 26 Apr 2017 10:25:49 GMT): hayato (Wed, 26 Apr 2017 10:44:22 GMT): pd93 (Wed, 26 Apr 2017 11:30:07 GMT): dave.enyeart (Wed, 26 Apr 2017 12:05:01 GMT): pd93 (Wed, 26 Apr 2017 12:24:13 GMT): dave.enyeart (Wed, 26 Apr 2017 13:01:54 GMT): pd93 (Wed, 26 Apr 2017 13:03:59 GMT): pd93 (Wed, 26 Apr 2017 14:34:17 GMT): dave.enyeart (Wed, 26 Apr 2017 14:42:13 GMT): dave.enyeart (Wed, 26 Apr 2017 14:42:13 GMT): pd93 (Wed, 26 Apr 2017 14:44:10 GMT): pd93 (Wed, 26 Apr 2017 14:44:10 GMT): dave.enyeart (Wed, 26 Apr 2017 14:44:57 GMT): dave.enyeart (Wed, 26 Apr 2017 14:45:12 GMT): dave.enyeart (Wed, 26 Apr 2017 14:45:32 GMT): pd93 (Wed, 26 Apr 2017 14:45:40 GMT): pd93 (Wed, 26 Apr 2017 14:45:57 GMT): dave.enyeart (Wed, 26 Apr 2017 14:46:02 GMT): pd93 (Wed, 26 Apr 2017 17:28:07 GMT): dave.enyeart (Wed, 26 Apr 2017 17:36:49 GMT): dave.enyeart (Wed, 26 Apr 2017 17:36:49 GMT): pd93 (Wed, 26 Apr 2017 17:39:20 GMT): nhrishi (Wed, 26 Apr 2017 19:26:39 GMT): dave.enyeart (Wed, 26 Apr 2017 21:03:42 GMT): C0rWin (Wed, 26 Apr 2017 21:07:53 GMT): dave.enyeart (Wed, 26 Apr 2017 21:09:46 GMT): C0rWin (Wed, 26 Apr 2017 21:11:43 GMT): dave.enyeart (Wed, 26 Apr 2017 21:12:30 GMT): C0rWin (Wed, 26 Apr 2017 21:13:49 GMT): binhn (Wed, 26 Apr 2017 21:43:46 GMT): nhrishi (Thu, 27 Apr 2017 01:59:27 GMT): LoveshHarchandani (Thu, 27 Apr 2017 06:45:08 GMT): dave.enyeart (Thu, 27 Apr 2017 11:01:48 GMT): C0rWin (Thu, 27 Apr 2017 11:04:04 GMT): C0rWin (Thu, 27 Apr 2017 11:04:42 GMT): nhrishi (Thu, 27 Apr 2017 13:30:47 GMT): nhrishi (Thu, 27 Apr 2017 13:32:17 GMT): nhrishi (Thu, 27 Apr 2017 13:32:39 GMT): wsh_bob (Fri, 28 Apr 2017 08:10:08 GMT): dorrakhribi (Fri, 28 Apr 2017 08:37:12 GMT): dave.enyeart (Fri, 28 Apr 2017 11:22:59 GMT): vugranam (Fri, 28 Apr 2017 12:14:20 GMT): mffrench (Fri, 28 Apr 2017 13:38:56 GMT): mffrench (Fri, 28 Apr 2017 13:39:40 GMT): mffrench (Fri, 28 Apr 2017 13:40:03 GMT): npnjuguna (Sat, 29 Apr 2017 05:02:31 GMT): anistark (Sat, 29 Apr 2017 18:22:30 GMT): passkit (Sun, 30 Apr 2017 10:37:36 GMT): passkit (Sun, 30 Apr 2017 10:38:45 GMT): passkit (Sun, 30 Apr 2017 12:33:07 GMT): passkit (Sun, 30 Apr 2017 13:40:25 GMT): yacovm (Sun, 30 Apr 2017 14:38:24 GMT): passkit (Sun, 30 Apr 2017 16:34:28 GMT): Lakshmipadmaja (Tue, 02 May 2017 05:00:06 GMT): FenglianXu (Tue, 02 May 2017 16:18:41 GMT): berserkr (Tue, 02 May 2017 17:14:18 GMT): berserkr (Tue, 02 May 2017 17:14:22 GMT): berserkr (Tue, 02 May 2017 17:14:32 GMT): berserkr (Tue, 02 May 2017 18:12:22 GMT): FenglianXu (Tue, 02 May 2017 21:39:32 GMT): rahulhegde (Tue, 02 May 2017 22:13:15 GMT): dave.enyeart (Wed, 03 May 2017 22:29:33 GMT): rahulhegde (Thu, 04 May 2017 00:17:36 GMT): himansri (Thu, 04 May 2017 11:28:08 GMT): William.Z (Thu, 04 May 2017 13:04:31 GMT): FengChen_1982 (Fri, 05 May 2017 09:54:29 GMT): FengChen_1982 (Fri, 05 May 2017 09:57:24 GMT): smithbk (Fri, 05 May 2017 12:57:26 GMT): dave.enyeart (Fri, 05 May 2017 13:04:26 GMT): FengChen_1982 (Fri, 05 May 2017 13:08:34 GMT): FengChen_1982 (Fri, 05 May 2017 13:08:59 GMT): FengChen_1982 (Fri, 05 May 2017 13:25:25 GMT): FenglianXu (Fri, 05 May 2017 14:05:46 GMT): vijaygopal (Sat, 06 May 2017 17:13:48 GMT): vijaygopal (Sat, 06 May 2017 17:14:10 GMT): vijaygopal (Sat, 06 May 2017 17:14:22 GMT): vijaygopal (Sat, 06 May 2017 17:15:07 GMT): stu2 (Sun, 07 May 2017 21:54:25 GMT): FenglianXu (Mon, 08 May 2017 15:28:21 GMT): FenglianXu (Mon, 08 May 2017 15:29:17 GMT): dave.enyeart (Mon, 08 May 2017 15:29:23 GMT): FenglianXu (Mon, 08 May 2017 15:29:51 GMT): dave.enyeart (Mon, 08 May 2017 15:30:37 GMT): d8bhatta (Mon, 08 May 2017 16:39:08 GMT): d8bhatta (Mon, 08 May 2017 16:39:39 GMT): amber-zhang (Tue, 09 May 2017 00:52:48 GMT): mutexing (Tue, 09 May 2017 04:36:12 GMT): jchenibm (Tue, 09 May 2017 13:41:01 GMT): dave.enyeart (Tue, 09 May 2017 15:32:39 GMT): d8bhatta (Tue, 09 May 2017 15:33:32 GMT): bkvellanki (Tue, 09 May 2017 16:33:32 GMT): RanjanBanerjee (Tue, 09 May 2017 17:10:34 GMT): jordipainan (Wed, 10 May 2017 08:12:51 GMT): FenglianXu (Wed, 10 May 2017 14:39:12 GMT): FenglianXu (Wed, 10 May 2017 14:43:42 GMT): FenglianXu (Wed, 10 May 2017 14:45:18 GMT): dave.enyeart (Wed, 10 May 2017 16:40:56 GMT): dave.enyeart (Wed, 10 May 2017 16:40:59 GMT): FenglianXu (Wed, 10 May 2017 16:41:47 GMT): FenglianXu (Wed, 10 May 2017 16:42:35 GMT): KentLandholm (Wed, 10 May 2017 19:13:12 GMT): FenglianXu (Wed, 10 May 2017 21:58:42 GMT): FenglianXu (Wed, 10 May 2017 21:58:45 GMT): dave.enyeart (Thu, 11 May 2017 03:17:14 GMT): dave.enyeart (Thu, 11 May 2017 03:17:41 GMT): muralisr (Thu, 11 May 2017 12:08:54 GMT): dave.enyeart (Thu, 11 May 2017 13:37:48 GMT): kelvinzhong (Thu, 11 May 2017 13:37:48 GMT): bkvellanki (Thu, 11 May 2017 14:29:46 GMT): webdaford (Thu, 11 May 2017 18:57:26 GMT): l1nux (Thu, 11 May 2017 19:35:37 GMT): dave.enyeart (Thu, 11 May 2017 19:37:21 GMT): dave.enyeart (Thu, 11 May 2017 19:38:06 GMT): dave.enyeart (Thu, 11 May 2017 19:38:40 GMT): dave.enyeart (Thu, 11 May 2017 19:39:19 GMT): dave.enyeart (Thu, 11 May 2017 19:39:19 GMT): dave.enyeart (Thu, 11 May 2017 19:39:19 GMT): l1nux (Thu, 11 May 2017 19:43:49 GMT): dave.enyeart (Thu, 11 May 2017 19:48:25 GMT): dave.enyeart (Thu, 11 May 2017 19:48:28 GMT): l1nux (Thu, 11 May 2017 20:01:45 GMT): bkvellanki (Thu, 11 May 2017 20:08:49 GMT): dave.enyeart (Thu, 11 May 2017 20:51:13 GMT): kelvinzhong (Fri, 12 May 2017 02:10:57 GMT): kelvinzhong (Fri, 12 May 2017 02:36:01 GMT): kelvinzhong (Fri, 12 May 2017 02:36:06 GMT): dave.enyeart (Fri, 12 May 2017 02:47:53 GMT): kelvinzhong (Fri, 12 May 2017 03:05:42 GMT): kelvinzhong (Fri, 12 May 2017 03:19:57 GMT): dave.enyeart (Fri, 12 May 2017 10:39:41 GMT): dave.enyeart (Fri, 12 May 2017 10:39:41 GMT): MohammadObaid (Fri, 12 May 2017 13:26:12 GMT): kelvinzhong (Fri, 12 May 2017 14:48:12 GMT): kelvinzhong (Fri, 12 May 2017 15:11:46 GMT): kelvinzhong (Fri, 12 May 2017 15:13:57 GMT): dave.enyeart (Fri, 12 May 2017 15:31:51 GMT): kelvinzhong (Fri, 12 May 2017 15:37:13 GMT): cauep (Fri, 12 May 2017 19:47:02 GMT): berserkr (Mon, 15 May 2017 00:40:06 GMT): berserkr (Mon, 15 May 2017 00:40:11 GMT): berserkr (Mon, 15 May 2017 00:40:22 GMT): xixuejia (Mon, 15 May 2017 07:03:56 GMT): bkvellanki (Mon, 15 May 2017 20:55:06 GMT): bkvellanki (Mon, 15 May 2017 20:55:06 GMT): yacovm (Mon, 15 May 2017 21:15:03 GMT): vdods (Mon, 15 May 2017 21:16:44 GMT): bkvellanki (Mon, 15 May 2017 21:19:04 GMT): yacovm (Mon, 15 May 2017 21:20:37 GMT): yacovm (Mon, 15 May 2017 21:24:05 GMT): vdods (Mon, 15 May 2017 22:10:42 GMT): vdods (Mon, 15 May 2017 22:12:55 GMT): vdods (Mon, 15 May 2017 22:21:33 GMT): dave.enyeart (Tue, 16 May 2017 01:26:14 GMT): dave.enyeart (Tue, 16 May 2017 01:27:28 GMT): dave.enyeart (Tue, 16 May 2017 01:29:39 GMT): dave.enyeart (Tue, 16 May 2017 01:30:33 GMT): dave.enyeart (Tue, 16 May 2017 01:31:15 GMT): dave.enyeart (Tue, 16 May 2017 01:33:05 GMT): zhouhuangjing (Tue, 16 May 2017 02:35:40 GMT): zhouhuangjing (Tue, 16 May 2017 02:47:41 GMT): kelvinzhong (Tue, 16 May 2017 03:32:44 GMT): rangak (Tue, 16 May 2017 06:08:59 GMT): oooo (Tue, 16 May 2017 08:49:06 GMT): zhouhuangjing (Tue, 16 May 2017 09:10:12 GMT): kelvinzhong (Tue, 16 May 2017 09:10:54 GMT): vdods (Tue, 16 May 2017 16:41:12 GMT): MohammadObaid (Tue, 16 May 2017 19:34:34 GMT): MohammadObaid (Tue, 16 May 2017 19:34:34 GMT): MohammadObaid (Tue, 16 May 2017 19:35:34 GMT): kelvinzhong (Wed, 17 May 2017 01:55:10 GMT): zhouhuangjing (Wed, 17 May 2017 03:20:49 GMT): kesavannb (Wed, 17 May 2017 06:18:44 GMT): kesavannb (Wed, 17 May 2017 06:31:15 GMT): srss (Wed, 17 May 2017 15:06:40 GMT): FengChen_1982 (Thu, 18 May 2017 03:41:29 GMT): dave.enyeart (Thu, 18 May 2017 12:25:18 GMT): MartinMateev (Thu, 18 May 2017 12:49:59 GMT): MartinMateev (Thu, 18 May 2017 12:50:30 GMT): kelvinzhong (Fri, 19 May 2017 02:24:47 GMT): kelvinzhong (Fri, 19 May 2017 02:24:47 GMT): dave.enyeart (Fri, 19 May 2017 10:30:59 GMT): greg2git (Fri, 19 May 2017 14:37:42 GMT): philT (Sun, 21 May 2017 12:04:59 GMT): tmath (Sun, 21 May 2017 18:10:14 GMT): tmath (Sun, 21 May 2017 18:13:29 GMT): tmath (Sun, 21 May 2017 18:15:33 GMT): MohammadObaid (Sun, 21 May 2017 19:17:58 GMT): MohammadObaid (Sun, 21 May 2017 19:18:35 GMT): MohammadObaid (Sun, 21 May 2017 19:59:52 GMT): dave.enyeart (Mon, 22 May 2017 00:11:03 GMT): MohammadObaid (Mon, 22 May 2017 04:17:33 GMT): MohammadObaid (Mon, 22 May 2017 04:23:25 GMT): Jay (Mon, 22 May 2017 10:30:55 GMT): dave.enyeart (Mon, 22 May 2017 12:16:25 GMT): dave.enyeart (Mon, 22 May 2017 12:18:20 GMT): MohammadObaid (Mon, 22 May 2017 12:23:40 GMT): dave.enyeart (Mon, 22 May 2017 12:26:12 GMT): dave.enyeart (Mon, 22 May 2017 12:26:12 GMT): dave.enyeart (Mon, 22 May 2017 12:26:12 GMT): dave.enyeart (Mon, 22 May 2017 12:26:21 GMT): dave.enyeart (Mon, 22 May 2017 12:26:21 GMT): MohammadObaid (Mon, 22 May 2017 12:30:01 GMT): pmontagn (Mon, 22 May 2017 12:45:15 GMT): MohammadObaid (Mon, 22 May 2017 15:52:31 GMT): hendry19901990 (Mon, 22 May 2017 16:38:17 GMT): dave.enyeart (Mon, 22 May 2017 17:33:11 GMT): dave.enyeart (Mon, 22 May 2017 17:33:11 GMT): bh4rtp (Tue, 23 May 2017 07:04:34 GMT): dave.enyeart (Tue, 23 May 2017 10:37:32 GMT): anik (Tue, 23 May 2017 11:51:31 GMT): tmath (Tue, 23 May 2017 12:02:35 GMT): tmath (Tue, 23 May 2017 12:02:35 GMT): FenglianXu (Tue, 23 May 2017 14:01:07 GMT): FenglianXu (Tue, 23 May 2017 14:02:22 GMT): FenglianXu (Tue, 23 May 2017 16:28:13 GMT): FenglianXu (Tue, 23 May 2017 16:29:12 GMT): FenglianXu (Tue, 23 May 2017 16:29:43 GMT): berserkr (Tue, 23 May 2017 18:59:27 GMT): FenglianXu (Tue, 23 May 2017 20:00:06 GMT): FenglianXu (Tue, 23 May 2017 20:00:08 GMT): FenglianXu (Tue, 23 May 2017 20:07:21 GMT): berserkr (Tue, 23 May 2017 22:51:48 GMT): berserkr (Tue, 23 May 2017 22:54:24 GMT): berserkr (Tue, 23 May 2017 22:54:31 GMT): berserkr (Tue, 23 May 2017 22:54:55 GMT): toddinpal (Tue, 23 May 2017 23:54:38 GMT): toddinpal (Tue, 23 May 2017 23:54:55 GMT): jordipainan (Wed, 24 May 2017 00:18:32 GMT): bh4rtp (Wed, 24 May 2017 03:24:50 GMT): bh4rtp (Wed, 24 May 2017 03:34:19 GMT): SahilKapoor (Wed, 24 May 2017 04:44:23 GMT): dave.enyeart (Wed, 24 May 2017 04:45:24 GMT): SahilKapoor (Wed, 24 May 2017 04:46:00 GMT): SahilKapoor (Wed, 24 May 2017 04:46:08 GMT): SahilKapoor (Wed, 24 May 2017 04:47:12 GMT): dave.enyeart (Wed, 24 May 2017 04:49:22 GMT): bh4rtp (Wed, 24 May 2017 06:33:02 GMT): bh4rtp (Wed, 24 May 2017 06:33:02 GMT): bh4rtp (Wed, 24 May 2017 06:33:02 GMT): bh4rtp (Wed, 24 May 2017 06:33:02 GMT): SotirisAlfonsos (Wed, 24 May 2017 14:50:05 GMT): C0rWin (Wed, 24 May 2017 15:09:13 GMT): C0rWin (Wed, 24 May 2017 15:10:15 GMT): C0rWin (Wed, 24 May 2017 15:10:42 GMT): C0rWin (Wed, 24 May 2017 15:13:07 GMT): C0rWin (Wed, 24 May 2017 15:13:26 GMT): SotirisAlfonsos (Wed, 24 May 2017 15:56:15 GMT): C0rWin (Wed, 24 May 2017 15:56:38 GMT): SotirisAlfonsos (Wed, 24 May 2017 15:56:48 GMT): AdnanC (Wed, 24 May 2017 18:58:49 GMT): AdnanC (Wed, 24 May 2017 18:59:01 GMT): rfu2k (Wed, 24 May 2017 18:59:02 GMT): rfu2k (Wed, 24 May 2017 19:08:56 GMT): rfu2k (Wed, 24 May 2017 19:08:56 GMT): dave.enyeart (Wed, 24 May 2017 19:22:10 GMT): dave.enyeart (Wed, 24 May 2017 19:22:33 GMT): dave.enyeart (Wed, 24 May 2017 19:24:27 GMT): rfu2k (Wed, 24 May 2017 19:25:54 GMT): rfu2k (Wed, 24 May 2017 19:30:10 GMT): rfu2k (Wed, 24 May 2017 19:30:10 GMT): rmohta (Thu, 25 May 2017 01:44:32 GMT): rmohta (Thu, 25 May 2017 01:51:24 GMT): prashiyn (Thu, 25 May 2017 09:52:29 GMT): bmkor (Fri, 26 May 2017 01:04:16 GMT): pd93 (Fri, 26 May 2017 09:54:25 GMT): pd93 (Fri, 26 May 2017 09:54:25 GMT): pd93 (Fri, 26 May 2017 09:54:25 GMT): akash42145 (Fri, 26 May 2017 13:30:15 GMT): akash42145 (Fri, 26 May 2017 13:30:51 GMT): akash42145 (Fri, 26 May 2017 13:34:51 GMT): AdnanC (Fri, 26 May 2017 14:14:42 GMT): AdnanC (Fri, 26 May 2017 14:14:42 GMT): dave.enyeart (Fri, 26 May 2017 14:20:41 GMT): pd93 (Fri, 26 May 2017 14:21:10 GMT): AdnanC (Fri, 26 May 2017 14:22:24 GMT): pd93 (Fri, 26 May 2017 14:23:27 GMT): pd93 (Fri, 26 May 2017 14:23:47 GMT): AdnanC (Fri, 26 May 2017 14:24:26 GMT): pd93 (Fri, 26 May 2017 14:28:08 GMT): AdnanC (Fri, 26 May 2017 14:30:36 GMT): pd93 (Fri, 26 May 2017 14:30:58 GMT): pd93 (Fri, 26 May 2017 14:30:58 GMT): AdnanC (Fri, 26 May 2017 14:31:08 GMT): pd93 (Fri, 26 May 2017 15:01:34 GMT): AdnanC (Fri, 26 May 2017 15:04:37 GMT): pd93 (Fri, 26 May 2017 15:05:28 GMT): AdnanC (Fri, 26 May 2017 15:06:22 GMT): pd93 (Fri, 26 May 2017 15:07:02 GMT): AdnanC (Fri, 26 May 2017 15:07:31 GMT): pd93 (Fri, 26 May 2017 15:07:43 GMT): pd93 (Fri, 26 May 2017 15:09:50 GMT): pd93 (Fri, 26 May 2017 15:10:04 GMT): pd93 (Fri, 26 May 2017 15:11:36 GMT): AdnanC (Fri, 26 May 2017 15:13:00 GMT): AdnanC (Fri, 26 May 2017 15:13:00 GMT): pd93 (Fri, 26 May 2017 15:14:22 GMT): AdnanC (Fri, 26 May 2017 15:39:11 GMT): AdnanC (Fri, 26 May 2017 15:39:11 GMT): pd93 (Fri, 26 May 2017 15:59:34 GMT): pd93 (Fri, 26 May 2017 15:59:34 GMT): AdnanC (Fri, 26 May 2017 16:01:13 GMT): pd93 (Fri, 26 May 2017 16:02:28 GMT): AdnanC (Fri, 26 May 2017 16:02:37 GMT): BhavishaDawda (Fri, 26 May 2017 18:48:58 GMT): MohammadObaid (Sat, 27 May 2017 07:29:22 GMT): MohammadObaid (Sat, 27 May 2017 07:29:22 GMT): dave.enyeart (Sat, 27 May 2017 12:13:58 GMT): dave.enyeart (Sat, 27 May 2017 12:14:18 GMT): dave.enyeart (Sat, 27 May 2017 12:14:18 GMT): dave.enyeart (Sat, 27 May 2017 12:14:44 GMT): dave.enyeart (Sat, 27 May 2017 12:15:04 GMT): dave.enyeart (Sat, 27 May 2017 12:17:32 GMT): dave.enyeart (Sat, 27 May 2017 12:19:32 GMT): dave.enyeart (Sat, 27 May 2017 12:19:32 GMT): dave.enyeart (Sat, 27 May 2017 12:19:32 GMT): dave.enyeart (Sat, 27 May 2017 12:21:20 GMT): muralisr (Sat, 27 May 2017 13:11:58 GMT): muralisr (Sat, 27 May 2017 13:13:14 GMT): muralisr (Sat, 27 May 2017 13:16:55 GMT): muralisr (Sat, 27 May 2017 13:17:23 GMT): MohammadObaid (Sat, 27 May 2017 14:17:03 GMT): MohammadObaid (Sat, 27 May 2017 14:42:30 GMT): MohammadObaid (Sat, 27 May 2017 14:42:30 GMT): bmalavan (Sat, 27 May 2017 15:41:00 GMT): dave.enyeart (Sat, 27 May 2017 15:44:23 GMT): dave.enyeart (Sat, 27 May 2017 15:45:22 GMT): jiangyaoguo (Sat, 27 May 2017 16:02:19 GMT): muralisr (Sat, 27 May 2017 17:32:38 GMT): jimouris (Mon, 29 May 2017 11:37:09 GMT): rajeev20 (Mon, 29 May 2017 14:46:58 GMT): FenglianXu (Tue, 30 May 2017 13:21:52 GMT): dave.enyeart (Tue, 30 May 2017 14:37:53 GMT): hmchen (Tue, 30 May 2017 18:49:12 GMT): tylerdmace (Wed, 31 May 2017 02:34:53 GMT): anik (Wed, 31 May 2017 10:10:03 GMT): dave.enyeart (Wed, 31 May 2017 12:30:51 GMT): dave.enyeart (Wed, 31 May 2017 12:31:27 GMT): prash.aggarwal (Thu, 01 Jun 2017 02:41:59 GMT): anik (Thu, 01 Jun 2017 04:19:32 GMT): bh4rtp (Fri, 02 Jun 2017 00:45:24 GMT): vdods (Fri, 02 Jun 2017 00:48:25 GMT): vdods (Fri, 02 Jun 2017 00:49:00 GMT): bh4rtp (Fri, 02 Jun 2017 00:52:22 GMT): jun (Mon, 05 Jun 2017 08:57:53 GMT): Amjadnz (Mon, 05 Jun 2017 13:18:22 GMT): Amjadnz (Mon, 05 Jun 2017 13:18:34 GMT): Amjadnz (Mon, 05 Jun 2017 13:20:36 GMT): dave.enyeart (Mon, 05 Jun 2017 13:34:08 GMT): dave.enyeart (Mon, 05 Jun 2017 13:34:30 GMT): dave.enyeart (Mon, 05 Jun 2017 13:35:01 GMT): Amjadnz (Mon, 05 Jun 2017 13:36:47 GMT): FenglianXu (Mon, 05 Jun 2017 14:35:34 GMT): FenglianXu (Mon, 05 Jun 2017 14:36:12 GMT): muralisr (Mon, 05 Jun 2017 16:57:40 GMT): PushpalathaHiremath (Tue, 06 Jun 2017 03:29:00 GMT): dave.enyeart (Tue, 06 Jun 2017 07:59:54 GMT): guruce (Tue, 06 Jun 2017 17:00:04 GMT): Amjadnz (Tue, 06 Jun 2017 20:16:15 GMT): Amjadnz (Tue, 06 Jun 2017 20:17:07 GMT): Amjadnz (Tue, 06 Jun 2017 20:18:26 GMT): Amjadnz (Tue, 06 Jun 2017 20:18:37 GMT): Amjadnz (Tue, 06 Jun 2017 20:48:47 GMT): Amjadnz (Tue, 06 Jun 2017 20:49:18 GMT): Amjadnz (Tue, 06 Jun 2017 20:49:36 GMT): Amjadnz (Tue, 06 Jun 2017 20:51:48 GMT): Amjadnz (Tue, 06 Jun 2017 20:52:38 GMT): Amjadnz (Tue, 06 Jun 2017 20:53:07 GMT): bh4rtp (Wed, 07 Jun 2017 01:27:05 GMT): bh4rtp (Wed, 07 Jun 2017 01:27:05 GMT): dave.enyeart (Wed, 07 Jun 2017 02:51:33 GMT): dave.enyeart (Wed, 07 Jun 2017 02:52:20 GMT): dave.enyeart (Wed, 07 Jun 2017 02:52:37 GMT): dave.enyeart (Wed, 07 Jun 2017 02:52:55 GMT): dave.enyeart (Wed, 07 Jun 2017 02:53:10 GMT): dave.enyeart (Wed, 07 Jun 2017 02:53:36 GMT): dave.enyeart (Wed, 07 Jun 2017 02:55:05 GMT): mastersingh24 (Wed, 07 Jun 2017 08:45:30 GMT): dave.enyeart (Wed, 07 Jun 2017 11:08:23 GMT): dave.enyeart (Wed, 07 Jun 2017 11:08:56 GMT): dave.enyeart (Wed, 07 Jun 2017 11:09:18 GMT): dave.enyeart (Wed, 07 Jun 2017 11:09:32 GMT): dave.enyeart (Wed, 07 Jun 2017 11:09:32 GMT): dave.enyeart (Wed, 07 Jun 2017 11:09:45 GMT): dave.enyeart (Wed, 07 Jun 2017 11:09:45 GMT): dave.enyeart (Wed, 07 Jun 2017 11:09:45 GMT): dave.enyeart (Wed, 07 Jun 2017 11:14:50 GMT): dave.enyeart (Wed, 07 Jun 2017 11:16:13 GMT): dave.enyeart (Wed, 07 Jun 2017 11:41:44 GMT): Amjadnz (Wed, 07 Jun 2017 12:05:59 GMT): chris.elder (Wed, 07 Jun 2017 13:13:13 GMT): bh4rtp (Wed, 07 Jun 2017 14:10:01 GMT): chris.elder (Wed, 07 Jun 2017 14:14:56 GMT): chris.elder (Wed, 07 Jun 2017 14:14:58 GMT): bh4rtp (Wed, 07 Jun 2017 14:17:08 GMT): chris.elder (Wed, 07 Jun 2017 14:22:56 GMT): bh4rtp (Wed, 07 Jun 2017 14:23:20 GMT): bh4rtp (Wed, 07 Jun 2017 14:35:46 GMT): chris.elder (Wed, 07 Jun 2017 14:39:42 GMT): bh4rtp (Wed, 07 Jun 2017 14:41:35 GMT): bh4rtp (Wed, 07 Jun 2017 14:49:48 GMT): bh4rtp (Wed, 07 Jun 2017 14:49:48 GMT): chris.elder (Wed, 07 Jun 2017 14:53:00 GMT): d8bhatta (Wed, 07 Jun 2017 15:35:07 GMT): smithbk (Wed, 07 Jun 2017 15:46:37 GMT): JonathanLevi (Thu, 08 Jun 2017 02:59:26 GMT): jeangui (Thu, 08 Jun 2017 06:41:49 GMT): butch.g (Fri, 09 Jun 2017 02:06:19 GMT): rezamt (Fri, 09 Jun 2017 10:19:44 GMT): bh4rtp (Sun, 11 Jun 2017 11:11:24 GMT): muralisr (Sun, 11 Jun 2017 13:56:31 GMT): bh4rtp (Mon, 12 Jun 2017 00:37:00 GMT): muralisr (Mon, 12 Jun 2017 00:39:23 GMT): bh4rtp (Mon, 12 Jun 2017 00:40:26 GMT): Mnorberto (Mon, 12 Jun 2017 04:16:59 GMT): anik (Mon, 12 Jun 2017 11:40:51 GMT): anik (Mon, 12 Jun 2017 11:59:33 GMT): anik (Mon, 12 Jun 2017 12:00:13 GMT): dave.enyeart (Mon, 12 Jun 2017 13:01:48 GMT): pd93 (Mon, 12 Jun 2017 13:44:48 GMT): dave.enyeart (Mon, 12 Jun 2017 14:05:11 GMT): anik (Mon, 12 Jun 2017 14:11:46 GMT): anik (Mon, 12 Jun 2017 14:19:50 GMT): rogeriofza (Sun, 18 Jun 2017 19:24:06 GMT): sfukazu (Mon, 19 Jun 2017 06:35:26 GMT): roj (Mon, 19 Jun 2017 10:41:48 GMT): akdj (Mon, 19 Jun 2017 14:21:01 GMT): terrypst (Mon, 19 Jun 2017 15:41:51 GMT): terrypst (Mon, 19 Jun 2017 15:42:42 GMT): terrypst (Mon, 19 Jun 2017 15:42:42 GMT): terrypst (Mon, 19 Jun 2017 15:42:42 GMT): joedayz (Mon, 19 Jun 2017 23:16:46 GMT): joedayz (Mon, 19 Jun 2017 23:17:57 GMT): berserkr (Tue, 20 Jun 2017 00:46:53 GMT): bh4rtp (Tue, 20 Jun 2017 03:48:56 GMT): mm-hl (Tue, 20 Jun 2017 04:33:08 GMT): dongqi (Tue, 20 Jun 2017 08:36:46 GMT): arner (Tue, 20 Jun 2017 13:37:08 GMT): arner (Tue, 20 Jun 2017 13:38:24 GMT): arner (Tue, 20 Jun 2017 13:41:30 GMT): bh4rtp (Tue, 20 Jun 2017 14:37:26 GMT): bh4rtp (Tue, 20 Jun 2017 14:41:46 GMT): bh4rtp (Wed, 21 Jun 2017 00:28:15 GMT): bh4rtp (Wed, 21 Jun 2017 00:28:15 GMT): bh4rtp (Thu, 22 Jun 2017 03:06:58 GMT): bh4rtp (Thu, 22 Jun 2017 03:06:58 GMT): bh4rtp (Thu, 22 Jun 2017 03:06:58 GMT): dave.enyeart (Thu, 22 Jun 2017 11:46:00 GMT): sidrmsh (Thu, 22 Jun 2017 17:20:10 GMT): sidney803 (Fri, 23 Jun 2017 02:20:03 GMT): chenxuan (Mon, 26 Jun 2017 02:45:55 GMT): chenxuan (Mon, 26 Jun 2017 02:46:22 GMT): chenxuan (Mon, 26 Jun 2017 02:46:31 GMT): chenxuan (Mon, 26 Jun 2017 02:46:31 GMT): yacovm (Mon, 26 Jun 2017 10:15:42 GMT): chenxuan (Mon, 26 Jun 2017 10:29:51 GMT): chenxuan (Mon, 26 Jun 2017 10:30:13 GMT): chenxuan (Mon, 26 Jun 2017 10:30:23 GMT): gdinhof (Tue, 27 Jun 2017 07:55:17 GMT): rezamt (Tue, 27 Jun 2017 12:01:21 GMT): dave.enyeart (Tue, 27 Jun 2017 12:09:16 GMT): rezamt (Tue, 27 Jun 2017 12:09:47 GMT): peterkn (Wed, 28 Jun 2017 02:56:03 GMT): nehalshah50 (Thu, 29 Jun 2017 20:12:49 GMT): toddinpal (Thu, 29 Jun 2017 21:30:59 GMT): muralisr (Fri, 30 Jun 2017 00:09:09 GMT): toddinpal (Fri, 30 Jun 2017 00:11:06 GMT): toddinpal (Fri, 30 Jun 2017 00:11:26 GMT): muralisr (Fri, 30 Jun 2017 00:11:50 GMT): muralisr (Fri, 30 Jun 2017 00:12:45 GMT): toddinpal (Fri, 30 Jun 2017 00:13:19 GMT): muralisr (Fri, 30 Jun 2017 00:13:44 GMT): toddinpal (Fri, 30 Jun 2017 00:14:33 GMT): toddinpal (Fri, 30 Jun 2017 00:14:58 GMT): muralisr (Fri, 30 Jun 2017 00:15:55 GMT): toddinpal (Fri, 30 Jun 2017 00:16:34 GMT): muralisr (Fri, 30 Jun 2017 00:17:47 GMT): toddinpal (Fri, 30 Jun 2017 00:18:44 GMT): muralisr (Fri, 30 Jun 2017 00:18:51 GMT): muralisr (Fri, 30 Jun 2017 00:20:12 GMT): toddinpal (Fri, 30 Jun 2017 00:22:17 GMT): mffrench (Fri, 30 Jun 2017 09:53:52 GMT): mffrench (Fri, 30 Jun 2017 09:54:08 GMT): mffrench (Fri, 30 Jun 2017 09:54:19 GMT): mffrench (Fri, 30 Jun 2017 09:55:09 GMT): mffrench (Fri, 30 Jun 2017 10:01:15 GMT): mffrench (Fri, 30 Jun 2017 10:01:15 GMT): mffrench (Fri, 30 Jun 2017 10:03:01 GMT): mffrench (Fri, 30 Jun 2017 10:05:25 GMT): mffrench (Fri, 30 Jun 2017 10:05:25 GMT): mffrench (Fri, 30 Jun 2017 10:09:08 GMT): mffrench (Fri, 30 Jun 2017 10:10:43 GMT): yacovm (Fri, 30 Jun 2017 10:19:17 GMT): yacovm (Fri, 30 Jun 2017 10:20:43 GMT): yacovm (Fri, 30 Jun 2017 10:20:46 GMT): Asara (Fri, 30 Jun 2017 13:26:17 GMT): jrosmith (Fri, 30 Jun 2017 13:28:11 GMT): gen_el (Fri, 30 Jun 2017 14:25:21 GMT): gen_el (Fri, 30 Jun 2017 14:27:19 GMT): manish-sethi (Fri, 30 Jun 2017 14:30:14 GMT): gen_el (Fri, 30 Jun 2017 14:32:00 GMT): manish-sethi (Fri, 30 Jun 2017 14:33:28 GMT): manish-sethi (Fri, 30 Jun 2017 14:35:41 GMT): manish-sethi (Fri, 30 Jun 2017 14:35:41 GMT): manish-sethi (Fri, 30 Jun 2017 14:36:25 GMT): rfrabasile (Fri, 30 Jun 2017 14:38:44 GMT): gen_el (Fri, 30 Jun 2017 14:48:26 GMT): dashengSun (Fri, 30 Jun 2017 14:48:34 GMT): awa (Sun, 02 Jul 2017 10:53:07 GMT): yacovm (Sun, 02 Jul 2017 22:11:59 GMT): yacovm (Sun, 02 Jul 2017 22:12:53 GMT): yacovm (Sun, 02 Jul 2017 22:14:14 GMT): awattez (Mon, 03 Jul 2017 16:03:48 GMT): VishalBatra (Wed, 05 Jul 2017 07:23:34 GMT): elrond (Wed, 05 Jul 2017 11:59:15 GMT): elrond (Wed, 05 Jul 2017 12:00:49 GMT): yacovm (Wed, 05 Jul 2017 12:17:51 GMT): akashmar (Wed, 05 Jul 2017 13:20:59 GMT): manish-sethi (Wed, 05 Jul 2017 13:36:04 GMT): manish-sethi (Wed, 05 Jul 2017 13:37:00 GMT): elrond (Wed, 05 Jul 2017 13:37:33 GMT): akashmar (Wed, 05 Jul 2017 13:44:38 GMT): manish-sethi (Wed, 05 Jul 2017 13:52:33 GMT): manish-sethi (Wed, 05 Jul 2017 13:52:33 GMT): akashmar (Wed, 05 Jul 2017 13:54:16 GMT): qizhang (Wed, 05 Jul 2017 14:59:10 GMT): qizhang (Wed, 05 Jul 2017 15:02:34 GMT): manish-sethi (Thu, 06 Jul 2017 02:56:32 GMT): manish-sethi (Thu, 06 Jul 2017 02:58:11 GMT): HuangLijun (Thu, 06 Jul 2017 06:53:30 GMT): qizhang (Thu, 06 Jul 2017 14:28:47 GMT): manish-sethi (Thu, 06 Jul 2017 14:33:17 GMT): manish-sethi (Thu, 06 Jul 2017 14:33:17 GMT): qizhang (Thu, 06 Jul 2017 14:48:07 GMT): yacovm (Thu, 06 Jul 2017 15:13:50 GMT): manish-sethi (Thu, 06 Jul 2017 15:16:10 GMT): yacovm (Thu, 06 Jul 2017 15:16:26 GMT): yacovm (Thu, 06 Jul 2017 15:16:32 GMT): manish-sethi (Thu, 06 Jul 2017 15:18:43 GMT): qizhang (Thu, 06 Jul 2017 15:28:11 GMT): DannyWong (Sat, 08 Jul 2017 03:27:47 GMT): DannyWong (Sat, 08 Jul 2017 03:32:27 GMT): DannyWong (Sat, 08 Jul 2017 03:32:27 GMT): bh4rtp (Mon, 10 Jul 2017 01:25:05 GMT): akdj (Tue, 11 Jul 2017 12:02:19 GMT): C0rWin (Tue, 11 Jul 2017 12:07:22 GMT): C0rWin (Tue, 11 Jul 2017 12:07:34 GMT): C0rWin (Tue, 11 Jul 2017 12:07:47 GMT): C0rWin (Tue, 11 Jul 2017 12:08:08 GMT): C0rWin (Tue, 11 Jul 2017 12:09:19 GMT): C0rWin (Tue, 11 Jul 2017 12:09:23 GMT): wlahti (Tue, 11 Jul 2017 12:11:27 GMT): trygvevang (Tue, 11 Jul 2017 12:12:16 GMT): akdj (Tue, 11 Jul 2017 12:12:45 GMT): akdj (Tue, 11 Jul 2017 12:12:58 GMT): mtxset (Tue, 11 Jul 2017 12:13:08 GMT): akdj (Tue, 11 Jul 2017 12:14:34 GMT): C0rWin (Tue, 11 Jul 2017 12:17:12 GMT): akdj (Tue, 11 Jul 2017 12:22:23 GMT): akdj (Tue, 11 Jul 2017 12:22:23 GMT): kustrun (Tue, 11 Jul 2017 12:22:31 GMT): C0rWin (Tue, 11 Jul 2017 12:25:39 GMT): dave.enyeart (Tue, 11 Jul 2017 12:41:26 GMT): shimos (Tue, 11 Jul 2017 17:02:11 GMT): qizhang (Tue, 11 Jul 2017 18:18:31 GMT): manish-sethi (Tue, 11 Jul 2017 18:22:36 GMT): manish-sethi (Tue, 11 Jul 2017 18:22:36 GMT): qizhang (Tue, 11 Jul 2017 18:25:00 GMT): manish-sethi (Tue, 11 Jul 2017 18:29:45 GMT): qizhang (Tue, 11 Jul 2017 18:33:44 GMT): qizhang (Tue, 11 Jul 2017 18:34:26 GMT): manish-sethi (Tue, 11 Jul 2017 18:37:22 GMT): qizhang (Tue, 11 Jul 2017 18:38:39 GMT): manish-sethi (Tue, 11 Jul 2017 18:39:30 GMT): qizhang (Tue, 11 Jul 2017 18:39:44 GMT): qizhang (Tue, 11 Jul 2017 18:45:13 GMT): qizhang (Tue, 11 Jul 2017 18:45:22 GMT): manish-sethi (Tue, 11 Jul 2017 18:46:23 GMT): qizhang (Tue, 11 Jul 2017 18:51:24 GMT): Mattasher (Tue, 11 Jul 2017 21:02:47 GMT): msmarcal (Tue, 11 Jul 2017 21:19:44 GMT): Senthil1 (Tue, 11 Jul 2017 22:55:18 GMT): Senthil1 (Tue, 11 Jul 2017 22:56:14 GMT): camdenT (Wed, 12 Jul 2017 00:56:23 GMT): qizhang (Wed, 12 Jul 2017 01:38:30 GMT): manish-sethi (Wed, 12 Jul 2017 02:45:37 GMT): qizhang (Wed, 12 Jul 2017 03:39:51 GMT): SriramaSharma (Wed, 12 Jul 2017 04:22:26 GMT): SriramaSharma (Wed, 12 Jul 2017 04:22:40 GMT): Senthil1 (Wed, 12 Jul 2017 05:57:54 GMT): Senthil1 (Wed, 12 Jul 2017 05:58:29 GMT): Senthil1 (Wed, 12 Jul 2017 05:58:38 GMT): Senthil1 (Wed, 12 Jul 2017 05:59:16 GMT): Senthil1 (Wed, 12 Jul 2017 05:59:43 GMT): paapighoda (Wed, 12 Jul 2017 06:04:57 GMT): apolikamixitos (Wed, 12 Jul 2017 07:24:38 GMT): jarroyer (Wed, 12 Jul 2017 14:48:35 GMT): jarroyer (Wed, 12 Jul 2017 14:50:57 GMT): jrosmith (Wed, 12 Jul 2017 15:01:00 GMT): jrosmith (Wed, 12 Jul 2017 15:01:21 GMT): dave.enyeart (Wed, 12 Jul 2017 15:01:32 GMT): jrosmith (Wed, 12 Jul 2017 15:01:52 GMT): jrosmith (Wed, 12 Jul 2017 15:02:26 GMT): jarroyer (Wed, 12 Jul 2017 15:02:37 GMT): dave.enyeart (Wed, 12 Jul 2017 15:03:40 GMT): jarroyer (Wed, 12 Jul 2017 15:04:20 GMT): jarroyer (Wed, 12 Jul 2017 15:07:26 GMT): dave.enyeart (Wed, 12 Jul 2017 15:08:58 GMT): jarroyer (Wed, 12 Jul 2017 15:10:20 GMT): jarroyer (Wed, 12 Jul 2017 15:10:35 GMT): qizhang (Wed, 12 Jul 2017 15:10:48 GMT): dave.enyeart (Wed, 12 Jul 2017 15:11:02 GMT): jarroyer (Wed, 12 Jul 2017 15:11:39 GMT): dave.enyeart (Wed, 12 Jul 2017 15:12:05 GMT): dave.enyeart (Wed, 12 Jul 2017 15:12:05 GMT): dave.enyeart (Wed, 12 Jul 2017 15:12:20 GMT): jarroyer (Wed, 12 Jul 2017 15:12:40 GMT): qizhang (Wed, 12 Jul 2017 15:12:45 GMT): dave.enyeart (Wed, 12 Jul 2017 15:13:32 GMT): dave.enyeart (Wed, 12 Jul 2017 15:13:32 GMT): qizhang (Wed, 12 Jul 2017 16:09:27 GMT): n91 (Wed, 12 Jul 2017 16:24:37 GMT): Senthil1 (Wed, 12 Jul 2017 23:56:20 GMT): Senthil1 (Wed, 12 Jul 2017 23:58:02 GMT): qizhang (Thu, 13 Jul 2017 00:27:56 GMT): Senthil1 (Thu, 13 Jul 2017 00:40:37 GMT): paapighoda (Thu, 13 Jul 2017 09:39:21 GMT): paapighoda (Thu, 13 Jul 2017 09:41:14 GMT): paapighoda (Thu, 13 Jul 2017 09:41:32 GMT): dave.enyeart (Thu, 13 Jul 2017 11:35:28 GMT): dave.enyeart (Thu, 13 Jul 2017 11:35:42 GMT): dave.enyeart (Thu, 13 Jul 2017 11:35:51 GMT): dave.enyeart (Thu, 13 Jul 2017 11:35:51 GMT): dave.enyeart (Thu, 13 Jul 2017 11:36:16 GMT): dave.enyeart (Thu, 13 Jul 2017 11:36:16 GMT): dave.enyeart (Thu, 13 Jul 2017 11:36:49 GMT): gormand (Thu, 13 Jul 2017 14:54:08 GMT): C0rWin (Thu, 13 Jul 2017 14:57:41 GMT): C0rWin (Thu, 13 Jul 2017 14:58:07 GMT): C0rWin (Thu, 13 Jul 2017 14:58:56 GMT): gormand (Thu, 13 Jul 2017 14:59:23 GMT): dave.enyeart (Thu, 13 Jul 2017 18:57:18 GMT): dave.enyeart (Thu, 13 Jul 2017 18:57:40 GMT): dave.enyeart (Thu, 13 Jul 2017 18:57:48 GMT): dave.enyeart (Thu, 13 Jul 2017 18:59:08 GMT): paapighoda (Fri, 14 Jul 2017 08:47:10 GMT): dave.enyeart (Fri, 14 Jul 2017 12:09:59 GMT): cre8bidio (Mon, 17 Jul 2017 00:47:01 GMT): paapighoda (Mon, 17 Jul 2017 05:31:18 GMT): Sania 2 (Tue, 18 Jul 2017 01:04:19 GMT): Rachitga (Tue, 18 Jul 2017 15:11:54 GMT): chenxuan (Wed, 19 Jul 2017 06:38:59 GMT): chenxuan (Wed, 19 Jul 2017 06:38:59 GMT): sstone1 (Wed, 19 Jul 2017 07:29:48 GMT): chenxuan (Wed, 19 Jul 2017 07:36:26 GMT): chenxuan (Wed, 19 Jul 2017 07:36:48 GMT): chenxuan (Wed, 19 Jul 2017 07:37:00 GMT): chenxuan (Wed, 19 Jul 2017 07:37:04 GMT): chenxuan (Wed, 19 Jul 2017 07:37:54 GMT): chenxuan (Wed, 19 Jul 2017 07:53:11 GMT): chenxuan (Wed, 19 Jul 2017 07:53:46 GMT): chenxuan (Wed, 19 Jul 2017 08:35:31 GMT): chenxuan (Wed, 19 Jul 2017 08:35:33 GMT): chenxuan (Wed, 19 Jul 2017 08:35:41 GMT): sstone1 (Wed, 19 Jul 2017 08:40:13 GMT): sstone1 (Wed, 19 Jul 2017 08:40:36 GMT): chenxuan (Wed, 19 Jul 2017 08:57:40 GMT): chenxuan (Wed, 19 Jul 2017 09:21:07 GMT): chenxuan (Wed, 19 Jul 2017 09:21:13 GMT): chenxuan (Wed, 19 Jul 2017 09:21:21 GMT): chenxuan (Wed, 19 Jul 2017 09:21:33 GMT): chenxuan (Wed, 19 Jul 2017 09:22:15 GMT): chenxuan (Wed, 19 Jul 2017 09:22:40 GMT): chenxuan (Wed, 19 Jul 2017 09:22:50 GMT): sstone1 (Wed, 19 Jul 2017 10:44:26 GMT): chenxuan (Wed, 19 Jul 2017 11:25:37 GMT): chenxuan (Wed, 19 Jul 2017 11:33:57 GMT): dave.enyeart (Wed, 19 Jul 2017 15:01:52 GMT): gauthampamu (Thu, 20 Jul 2017 21:18:55 GMT): gauthampamu (Thu, 20 Jul 2017 21:22:10 GMT): gauthampamu (Thu, 20 Jul 2017 21:23:51 GMT): KrisVishwanathan (Thu, 20 Jul 2017 23:36:57 GMT): atomti (Fri, 21 Jul 2017 05:46:41 GMT): chenxuan (Fri, 21 Jul 2017 06:03:34 GMT): chenxuan (Fri, 21 Jul 2017 06:03:39 GMT): indirajith (Fri, 21 Jul 2017 10:21:40 GMT): dave.enyeart (Fri, 21 Jul 2017 13:41:11 GMT): dave.enyeart (Fri, 21 Jul 2017 13:42:17 GMT): dave.enyeart (Fri, 21 Jul 2017 13:44:19 GMT): nhrishi (Fri, 21 Jul 2017 16:38:12 GMT): jeffgarratt (Fri, 21 Jul 2017 18:28:35 GMT): jeffgarratt (Fri, 21 Jul 2017 18:30:02 GMT): jeffgarratt (Fri, 21 Jul 2017 18:30:02 GMT): jeffgarratt (Fri, 21 Jul 2017 18:31:30 GMT): nhrishi (Fri, 21 Jul 2017 18:34:25 GMT): qizhang (Tue, 25 Jul 2017 14:43:22 GMT): qizhang (Tue, 25 Jul 2017 19:54:06 GMT): dave.enyeart (Tue, 25 Jul 2017 20:54:13 GMT): qizhang (Wed, 26 Jul 2017 00:50:23 GMT): howardhou (Wed, 26 Jul 2017 06:15:16 GMT): howardhou (Wed, 26 Jul 2017 09:10:33 GMT): Vadim (Wed, 26 Jul 2017 09:31:32 GMT): howardhou (Wed, 26 Jul 2017 09:45:26 GMT): Vadim (Wed, 26 Jul 2017 09:46:12 GMT): howardhou (Wed, 26 Jul 2017 09:49:08 GMT): Vadim (Wed, 26 Jul 2017 09:50:39 GMT): howardhou (Wed, 26 Jul 2017 09:55:23 GMT): sajeevkhan (Wed, 26 Jul 2017 10:59:14 GMT): sajeevkhan (Wed, 26 Jul 2017 10:59:55 GMT): dave.enyeart (Wed, 26 Jul 2017 11:10:47 GMT): neocoin (Wed, 26 Jul 2017 12:25:27 GMT): qizhang (Wed, 26 Jul 2017 14:02:19 GMT): Senthil1 (Wed, 26 Jul 2017 14:35:58 GMT): qizhang (Wed, 26 Jul 2017 14:37:01 GMT): Senthil1 (Wed, 26 Jul 2017 14:38:43 GMT): Senthil1 (Wed, 26 Jul 2017 14:39:46 GMT): Senthil1 (Wed, 26 Jul 2017 14:39:46 GMT): qizhang (Wed, 26 Jul 2017 14:43:08 GMT): qizhang (Wed, 26 Jul 2017 14:43:08 GMT): Senthil1 (Wed, 26 Jul 2017 14:45:46 GMT): Senthil1 (Wed, 26 Jul 2017 14:45:46 GMT): Senthil1 (Wed, 26 Jul 2017 14:45:46 GMT): Senthil1 (Wed, 26 Jul 2017 14:46:13 GMT): qizhang (Wed, 26 Jul 2017 14:50:55 GMT): Senthil1 (Wed, 26 Jul 2017 14:51:19 GMT): qizhang (Wed, 26 Jul 2017 18:04:47 GMT): qizhang (Wed, 26 Jul 2017 18:04:55 GMT): qizhang (Wed, 26 Jul 2017 18:05:54 GMT): qizhang (Wed, 26 Jul 2017 18:07:41 GMT): qizhang (Wed, 26 Jul 2017 20:06:20 GMT): dave.enyeart (Thu, 27 Jul 2017 01:15:17 GMT): dave.enyeart (Thu, 27 Jul 2017 01:15:58 GMT): qizhang (Thu, 27 Jul 2017 01:50:12 GMT): dave.enyeart (Thu, 27 Jul 2017 01:57:53 GMT): dave.enyeart (Thu, 27 Jul 2017 01:57:53 GMT): dave.enyeart (Thu, 27 Jul 2017 01:57:53 GMT): qizhang (Thu, 27 Jul 2017 02:13:23 GMT): dave.enyeart (Thu, 27 Jul 2017 02:18:04 GMT): qizhang (Thu, 27 Jul 2017 02:24:04 GMT): dave.enyeart (Thu, 27 Jul 2017 02:25:18 GMT): qizhang (Thu, 27 Jul 2017 02:45:37 GMT): dave.enyeart (Thu, 27 Jul 2017 02:46:29 GMT): manish-sethi (Thu, 27 Jul 2017 02:50:49 GMT): manish-sethi (Thu, 27 Jul 2017 02:52:14 GMT): dave.enyeart (Thu, 27 Jul 2017 02:53:44 GMT): manish-sethi (Thu, 27 Jul 2017 02:55:29 GMT): dave.enyeart (Thu, 27 Jul 2017 02:56:19 GMT): manish-sethi (Thu, 27 Jul 2017 02:56:50 GMT): dave.enyeart (Thu, 27 Jul 2017 02:57:21 GMT): manish-sethi (Thu, 27 Jul 2017 02:57:59 GMT): manish-sethi (Thu, 27 Jul 2017 02:57:59 GMT): qizhang (Thu, 27 Jul 2017 02:58:04 GMT): manish-sethi (Thu, 27 Jul 2017 02:59:43 GMT): manish-sethi (Thu, 27 Jul 2017 02:59:43 GMT): qizhang (Thu, 27 Jul 2017 03:00:41 GMT): qizhang (Thu, 27 Jul 2017 03:02:10 GMT): manish-sethi (Thu, 27 Jul 2017 03:03:38 GMT): qizhang (Thu, 27 Jul 2017 03:06:02 GMT): manish-sethi (Thu, 27 Jul 2017 03:07:07 GMT): qizhang (Thu, 27 Jul 2017 03:07:36 GMT): Bilings_s (Thu, 27 Jul 2017 09:31:55 GMT): Senthil1 (Thu, 27 Jul 2017 14:16:29 GMT): Senthil1 (Thu, 27 Jul 2017 14:16:29 GMT): Senthil1 (Thu, 27 Jul 2017 14:16:29 GMT): Senthil1 (Thu, 27 Jul 2017 14:16:29 GMT): qizhang (Thu, 27 Jul 2017 21:43:03 GMT): qizhang (Thu, 27 Jul 2017 21:44:51 GMT): C0rWin (Thu, 27 Jul 2017 22:58:46 GMT): C0rWin (Thu, 27 Jul 2017 22:59:04 GMT): C0rWin (Thu, 27 Jul 2017 22:59:23 GMT): C0rWin (Thu, 27 Jul 2017 22:59:25 GMT): C0rWin (Thu, 27 Jul 2017 22:59:55 GMT): C0rWin (Thu, 27 Jul 2017 23:02:33 GMT): simsc (Fri, 28 Jul 2017 15:40:00 GMT): rsherwood (Fri, 28 Jul 2017 15:46:29 GMT): rsherwood (Fri, 28 Jul 2017 15:50:13 GMT): bgaisford (Fri, 28 Jul 2017 16:44:11 GMT): dave.enyeart (Fri, 28 Jul 2017 18:04:29 GMT): dave.enyeart (Fri, 28 Jul 2017 18:07:06 GMT): qizhang (Fri, 28 Jul 2017 18:13:08 GMT): qizhang (Fri, 28 Jul 2017 18:13:25 GMT): qizhang (Fri, 28 Jul 2017 20:47:00 GMT): qizhang (Fri, 28 Jul 2017 20:47:12 GMT): Senthil1 (Sat, 29 Jul 2017 04:20:33 GMT): manish-sethi (Sat, 29 Jul 2017 14:05:58 GMT): qizhang (Sun, 30 Jul 2017 21:34:36 GMT): peterkn (Mon, 31 Jul 2017 06:08:40 GMT): rsherwood (Mon, 31 Jul 2017 07:56:04 GMT): vigneswaran.r (Mon, 31 Jul 2017 08:50:21 GMT): paapighoda (Mon, 31 Jul 2017 09:13:00 GMT): dave.enyeart (Mon, 31 Jul 2017 09:26:03 GMT): prempatidar (Mon, 31 Jul 2017 10:03:58 GMT): rsherwood (Mon, 31 Jul 2017 13:09:36 GMT): rsherwood (Mon, 31 Jul 2017 13:17:07 GMT): rsherwood (Mon, 31 Jul 2017 13:30:03 GMT): dave.enyeart (Mon, 31 Jul 2017 13:59:33 GMT): dave.enyeart (Mon, 31 Jul 2017 14:00:55 GMT): rsherwood (Mon, 31 Jul 2017 16:33:17 GMT): dave.enyeart (Mon, 31 Jul 2017 16:36:08 GMT): qizhang (Tue, 01 Aug 2017 19:19:37 GMT): qizhang (Tue, 01 Aug 2017 19:19:37 GMT): gary_zhan (Wed, 02 Aug 2017 07:07:22 GMT): rsherwood (Wed, 02 Aug 2017 08:23:05 GMT): dave.enyeart (Wed, 02 Aug 2017 10:46:34 GMT): dave.enyeart (Wed, 02 Aug 2017 10:50:40 GMT): chenxuan (Wed, 02 Aug 2017 14:43:02 GMT): chenxuan (Wed, 02 Aug 2017 14:43:03 GMT): dave.enyeart (Wed, 02 Aug 2017 14:59:02 GMT): chenxuan (Wed, 02 Aug 2017 14:59:22 GMT): chenxuan (Wed, 02 Aug 2017 14:59:31 GMT): chenxuan (Wed, 02 Aug 2017 14:59:38 GMT): chenxuan (Wed, 02 Aug 2017 14:59:55 GMT): chenxuan (Wed, 02 Aug 2017 15:00:32 GMT): chenxuan (Wed, 02 Aug 2017 15:00:52 GMT): chenxuan (Wed, 02 Aug 2017 15:00:58 GMT): chenxuan (Wed, 02 Aug 2017 15:01:58 GMT): chenxuan (Wed, 02 Aug 2017 15:02:12 GMT): chenxuan (Wed, 02 Aug 2017 15:02:18 GMT): dave.enyeart (Wed, 02 Aug 2017 15:14:24 GMT): dave.enyeart (Wed, 02 Aug 2017 15:14:24 GMT): manish-sethi (Wed, 02 Aug 2017 15:26:25 GMT): dave.enyeart (Wed, 02 Aug 2017 15:27:02 GMT): manish-sethi (Wed, 02 Aug 2017 15:34:57 GMT): dave.enyeart (Wed, 02 Aug 2017 15:36:30 GMT): chenxuan (Wed, 02 Aug 2017 15:38:31 GMT): chenxuan (Wed, 02 Aug 2017 15:38:41 GMT): chenxuan (Wed, 02 Aug 2017 15:38:55 GMT): chenxuan (Wed, 02 Aug 2017 15:39:05 GMT): chenxuan (Wed, 02 Aug 2017 15:39:17 GMT): chenxuan (Wed, 02 Aug 2017 15:39:35 GMT): chenxuan (Wed, 02 Aug 2017 15:39:49 GMT): chenxuan (Wed, 02 Aug 2017 15:39:53 GMT): dave.enyeart (Wed, 02 Aug 2017 15:51:13 GMT): dave.enyeart (Wed, 02 Aug 2017 15:51:13 GMT): chenxuan (Wed, 02 Aug 2017 15:54:04 GMT): chenxuan (Wed, 02 Aug 2017 15:54:19 GMT): chenxuan (Wed, 02 Aug 2017 15:54:27 GMT): chenxuan (Wed, 02 Aug 2017 15:54:36 GMT): chenxuan (Wed, 02 Aug 2017 15:54:47 GMT): chenxuan (Wed, 02 Aug 2017 15:56:26 GMT): chenxuan (Wed, 02 Aug 2017 15:57:13 GMT): dave.enyeart (Wed, 02 Aug 2017 16:03:18 GMT): dave.enyeart (Wed, 02 Aug 2017 16:03:18 GMT): chenxuan (Thu, 03 Aug 2017 01:51:54 GMT): chenxuan (Thu, 03 Aug 2017 01:52:00 GMT): chenxuan (Thu, 03 Aug 2017 01:53:04 GMT): dave.enyeart (Thu, 03 Aug 2017 03:06:36 GMT): chenxuan (Thu, 03 Aug 2017 03:13:15 GMT): chenxuan (Thu, 03 Aug 2017 03:13:25 GMT): JohnCallahan (Thu, 03 Aug 2017 11:55:37 GMT): gauthampamu (Thu, 03 Aug 2017 16:39:49 GMT): gauthampamu (Thu, 03 Aug 2017 16:41:10 GMT): Senthil1 (Thu, 03 Aug 2017 17:09:11 GMT): Senthil1 (Thu, 03 Aug 2017 17:09:11 GMT): Senthil1 (Thu, 03 Aug 2017 17:09:11 GMT): Senthil1 (Thu, 03 Aug 2017 17:09:11 GMT): Senthil1 (Thu, 03 Aug 2017 17:09:11 GMT): gauthampamu (Thu, 03 Aug 2017 17:10:40 GMT): eacoeytaux (Fri, 04 Aug 2017 19:54:14 GMT): smcambria22 (Mon, 07 Aug 2017 19:55:19 GMT): niteshsolanki (Tue, 08 Aug 2017 12:27:54 GMT): dave.enyeart (Tue, 08 Aug 2017 12:56:11 GMT): dave.enyeart (Tue, 08 Aug 2017 12:56:11 GMT): niteshsolanki (Tue, 08 Aug 2017 14:23:45 GMT): dave.enyeart (Tue, 08 Aug 2017 14:43:45 GMT): dave.enyeart (Tue, 08 Aug 2017 14:43:45 GMT): niteshsolanki (Tue, 08 Aug 2017 14:47:24 GMT): dave.enyeart (Tue, 08 Aug 2017 14:48:56 GMT): niteshsolanki (Tue, 08 Aug 2017 14:51:28 GMT): dave.enyeart (Tue, 08 Aug 2017 14:52:26 GMT): niteshsolanki (Tue, 08 Aug 2017 14:53:25 GMT): dave.enyeart (Tue, 08 Aug 2017 14:54:00 GMT): dave.enyeart (Tue, 08 Aug 2017 14:54:00 GMT): dave.enyeart (Tue, 08 Aug 2017 14:54:00 GMT): dave.enyeart (Tue, 08 Aug 2017 14:55:28 GMT): niteshsolanki (Tue, 08 Aug 2017 15:03:34 GMT): gauthampamu (Tue, 08 Aug 2017 20:09:22 GMT): gauthampamu (Tue, 08 Aug 2017 20:15:43 GMT): C0rWin (Wed, 09 Aug 2017 07:27:27 GMT): MeenakshiSingh (Wed, 09 Aug 2017 08:59:24 GMT): dave.enyeart (Wed, 09 Aug 2017 10:18:41 GMT): MeenakshiSingh (Wed, 09 Aug 2017 12:35:02 GMT): dave.enyeart (Wed, 09 Aug 2017 13:07:39 GMT): MeenakshiSingh (Wed, 09 Aug 2017 15:52:27 GMT): dave.enyeart (Wed, 09 Aug 2017 16:09:56 GMT): dave.enyeart (Wed, 09 Aug 2017 16:10:35 GMT): dave.enyeart (Wed, 09 Aug 2017 16:11:20 GMT): dave.enyeart (Wed, 09 Aug 2017 16:12:17 GMT): jslee99a (Thu, 10 Aug 2017 01:49:46 GMT): sampath06 (Thu, 10 Aug 2017 03:23:17 GMT): Glen (Thu, 10 Aug 2017 05:17:00 GMT): qsmen (Fri, 11 Aug 2017 06:59:24 GMT): berserkr (Sat, 12 Aug 2017 04:58:05 GMT): berserkr (Sat, 12 Aug 2017 04:58:34 GMT): silliman (Sat, 12 Aug 2017 18:52:32 GMT): dave.enyeart (Sun, 13 Aug 2017 03:40:42 GMT): berserkr (Sun, 13 Aug 2017 05:20:09 GMT): lenin.mehedy (Sun, 13 Aug 2017 05:50:49 GMT): lenin.mehedy (Sun, 13 Aug 2017 05:51:56 GMT): lenin.mehedy (Sun, 13 Aug 2017 05:54:05 GMT): ydk210999 (Sun, 13 Aug 2017 07:23:53 GMT): silliman (Sun, 13 Aug 2017 12:36:03 GMT): lenin.mehedy (Sun, 13 Aug 2017 13:29:43 GMT): MeenakshiSingh (Sun, 13 Aug 2017 14:28:05 GMT): MeenakshiSingh (Sun, 13 Aug 2017 14:28:05 GMT): dave.enyeart (Mon, 14 Aug 2017 11:55:25 GMT): chenxuan (Mon, 14 Aug 2017 11:58:52 GMT): chenxuan (Mon, 14 Aug 2017 11:58:57 GMT): chenxuan (Mon, 14 Aug 2017 11:59:02 GMT): chenxuan (Mon, 14 Aug 2017 11:59:12 GMT): chenxuan (Mon, 14 Aug 2017 11:59:13 GMT): chenxuan (Mon, 14 Aug 2017 11:59:19 GMT): chenxuan (Mon, 14 Aug 2017 11:59:20 GMT): dave.enyeart (Mon, 14 Aug 2017 12:16:47 GMT): chenxuan (Mon, 14 Aug 2017 12:17:55 GMT): chenxuan (Mon, 14 Aug 2017 12:18:12 GMT): chenxuan (Mon, 14 Aug 2017 12:18:14 GMT): chenxuan (Mon, 14 Aug 2017 12:18:23 GMT): chenxuan (Mon, 14 Aug 2017 12:18:52 GMT): chenxuan (Mon, 14 Aug 2017 12:19:01 GMT): chenxuan (Mon, 14 Aug 2017 12:19:18 GMT): chenxuan (Mon, 14 Aug 2017 12:19:26 GMT): chenxuan (Mon, 14 Aug 2017 12:19:32 GMT): chenxuan (Mon, 14 Aug 2017 12:19:38 GMT): chenxuan (Mon, 14 Aug 2017 12:19:56 GMT): chenxuan (Mon, 14 Aug 2017 12:20:05 GMT): chenxuan (Mon, 14 Aug 2017 12:20:23 GMT): chenxuan (Mon, 14 Aug 2017 12:20:29 GMT): chenxuan (Mon, 14 Aug 2017 12:20:54 GMT): chenxuan (Mon, 14 Aug 2017 12:20:56 GMT): chenxuan (Mon, 14 Aug 2017 12:21:07 GMT): chenxuan (Mon, 14 Aug 2017 12:24:44 GMT): berserkr (Mon, 14 Aug 2017 18:43:38 GMT): dave.enyeart (Mon, 14 Aug 2017 18:54:18 GMT): dave.enyeart (Mon, 14 Aug 2017 18:56:13 GMT): berserkr (Mon, 14 Aug 2017 20:47:40 GMT): Jonny (Tue, 15 Aug 2017 14:10:46 GMT): movee2005 (Tue, 15 Aug 2017 19:32:26 GMT): movee2005 (Tue, 15 Aug 2017 19:33:18 GMT): movee2005 (Tue, 15 Aug 2017 19:33:45 GMT): movee2005 (Tue, 15 Aug 2017 19:34:07 GMT): dave.enyeart (Tue, 15 Aug 2017 20:48:40 GMT): Sandeep (Tue, 15 Aug 2017 21:12:57 GMT): sampath06 (Wed, 16 Aug 2017 07:42:55 GMT): msandig (Wed, 16 Aug 2017 08:42:15 GMT): msandig (Wed, 16 Aug 2017 08:46:25 GMT): Zarf (Wed, 16 Aug 2017 13:46:34 GMT): dave.enyeart (Wed, 16 Aug 2017 13:52:03 GMT): dave.enyeart (Wed, 16 Aug 2017 13:53:42 GMT): sampath06 (Wed, 16 Aug 2017 13:54:45 GMT): ArnabChatterjee (Thu, 17 Aug 2017 04:02:50 GMT): rahulhegde (Thu, 17 Aug 2017 14:20:43 GMT): dave.enyeart (Thu, 17 Aug 2017 14:22:48 GMT): dave.enyeart (Thu, 17 Aug 2017 14:23:14 GMT): dave.enyeart (Thu, 17 Aug 2017 14:23:30 GMT): dave.enyeart (Thu, 17 Aug 2017 14:23:30 GMT): rahulhegde (Thu, 17 Aug 2017 14:26:45 GMT): rahulhegde (Thu, 17 Aug 2017 14:26:45 GMT): dave.enyeart (Thu, 17 Aug 2017 14:27:45 GMT): dave.enyeart (Thu, 17 Aug 2017 14:27:59 GMT): dave.enyeart (Thu, 17 Aug 2017 14:28:15 GMT): rahulhegde (Thu, 17 Aug 2017 14:38:37 GMT): dave.enyeart (Thu, 17 Aug 2017 14:39:20 GMT): rahulhegde (Thu, 17 Aug 2017 15:49:23 GMT): rahulhegde (Thu, 17 Aug 2017 15:49:23 GMT): dave.enyeart (Thu, 17 Aug 2017 15:53:51 GMT): rahulhegde (Thu, 17 Aug 2017 15:55:06 GMT): rahulhegde (Thu, 17 Aug 2017 15:55:06 GMT): dave.enyeart (Thu, 17 Aug 2017 15:56:03 GMT): dave.enyeart (Thu, 17 Aug 2017 15:56:18 GMT): nickgaski (Thu, 17 Aug 2017 16:01:13 GMT): dave.enyeart (Thu, 17 Aug 2017 16:52:31 GMT): sansha (Thu, 17 Aug 2017 18:36:12 GMT): sansha (Thu, 17 Aug 2017 18:36:25 GMT): sansha (Thu, 17 Aug 2017 18:36:43 GMT): sansha (Thu, 17 Aug 2017 18:38:01 GMT): sansha (Thu, 17 Aug 2017 18:39:15 GMT): manish-sethi (Thu, 17 Aug 2017 18:39:35 GMT): manish-sethi (Thu, 17 Aug 2017 18:39:54 GMT): sansha (Thu, 17 Aug 2017 18:40:26 GMT): manish-sethi (Thu, 17 Aug 2017 18:40:29 GMT): manish-sethi (Thu, 17 Aug 2017 18:40:47 GMT): manish-sethi (Thu, 17 Aug 2017 18:41:09 GMT): manish-sethi (Thu, 17 Aug 2017 18:41:41 GMT): manish-sethi (Thu, 17 Aug 2017 18:42:06 GMT): sansha (Thu, 17 Aug 2017 18:43:00 GMT): manish-sethi (Thu, 17 Aug 2017 18:43:17 GMT): sansha (Thu, 17 Aug 2017 18:45:08 GMT): manish-sethi (Thu, 17 Aug 2017 18:45:30 GMT): sansha (Thu, 17 Aug 2017 18:47:02 GMT): sansha (Thu, 17 Aug 2017 18:47:23 GMT): sansha (Thu, 17 Aug 2017 18:47:46 GMT): manish-sethi (Thu, 17 Aug 2017 18:49:40 GMT): manish-sethi (Thu, 17 Aug 2017 18:50:55 GMT): sansha (Thu, 17 Aug 2017 18:53:58 GMT): manish-sethi (Thu, 17 Aug 2017 18:54:15 GMT): sansha (Thu, 17 Aug 2017 19:19:40 GMT): manish-sethi (Thu, 17 Aug 2017 19:20:51 GMT): manish-sethi (Thu, 17 Aug 2017 19:21:21 GMT): manish-sethi (Thu, 17 Aug 2017 19:22:11 GMT): sansha (Thu, 17 Aug 2017 19:22:48 GMT): sansha (Thu, 17 Aug 2017 19:22:56 GMT): ArnabChatterjee (Fri, 18 Aug 2017 02:25:44 GMT): dave.enyeart (Fri, 18 Aug 2017 02:27:46 GMT): ArnabChatterjee (Fri, 18 Aug 2017 02:28:11 GMT): dave.enyeart (Fri, 18 Aug 2017 02:29:11 GMT): ArnabChatterjee (Fri, 18 Aug 2017 02:31:22 GMT): dave.enyeart (Fri, 18 Aug 2017 02:34:57 GMT): dave.enyeart (Fri, 18 Aug 2017 02:39:08 GMT): dave.enyeart (Fri, 18 Aug 2017 02:39:09 GMT): ArnabChatterjee (Fri, 18 Aug 2017 02:40:11 GMT): mdnoorishah (Fri, 18 Aug 2017 15:48:05 GMT): mdnoorishah (Fri, 18 Aug 2017 15:48:19 GMT): mdnoorishah (Fri, 18 Aug 2017 15:48:26 GMT): mdnoorishah (Fri, 18 Aug 2017 15:48:30 GMT): mdnoorishah (Fri, 18 Aug 2017 15:48:46 GMT): mdnoorishah (Fri, 18 Aug 2017 15:48:53 GMT): mdnoorishah (Fri, 18 Aug 2017 15:49:44 GMT): mdnoorishah (Fri, 18 Aug 2017 15:50:07 GMT): AdnanC (Fri, 18 Aug 2017 15:50:51 GMT): AdnanC (Fri, 18 Aug 2017 15:50:51 GMT): AdnanC (Fri, 18 Aug 2017 15:50:51 GMT): vdods (Fri, 18 Aug 2017 15:57:07 GMT): chenxuan (Sat, 19 Aug 2017 13:47:04 GMT): chenxuan (Sat, 19 Aug 2017 13:47:05 GMT): dave.enyeart (Sat, 19 Aug 2017 16:13:51 GMT): dave.enyeart (Sat, 19 Aug 2017 16:13:51 GMT): chenxuan (Sun, 20 Aug 2017 02:15:39 GMT): chenxuan (Sun, 20 Aug 2017 02:15:55 GMT): chenxuan (Sun, 20 Aug 2017 08:05:05 GMT): jyellick (Sun, 20 Aug 2017 08:05:05 GMT): dave.enyeart (Sun, 20 Aug 2017 15:22:15 GMT): dave.enyeart (Sun, 20 Aug 2017 15:23:47 GMT): chenxuan (Sun, 20 Aug 2017 15:24:59 GMT): chenxuan (Sun, 20 Aug 2017 15:25:20 GMT): chenxuan (Sun, 20 Aug 2017 15:25:42 GMT): chenxuan (Sun, 20 Aug 2017 15:26:01 GMT): chenxuan (Sun, 20 Aug 2017 15:26:18 GMT): chenxuan (Sun, 20 Aug 2017 15:26:45 GMT): chenxuan (Sun, 20 Aug 2017 15:51:44 GMT): chenxuan (Sun, 20 Aug 2017 15:51:51 GMT): chenxuan (Sun, 20 Aug 2017 15:53:17 GMT): chenxuan (Sun, 20 Aug 2017 15:53:18 GMT): dave.enyeart (Sun, 20 Aug 2017 19:16:58 GMT): dave.enyeart (Sun, 20 Aug 2017 19:16:58 GMT): chenxuan (Mon, 21 Aug 2017 01:19:24 GMT): kelvinzhong (Mon, 21 Aug 2017 03:43:22 GMT): dave.enyeart (Mon, 21 Aug 2017 03:48:28 GMT): chenxuan (Mon, 21 Aug 2017 11:58:14 GMT): chenxuan (Mon, 21 Aug 2017 11:58:38 GMT): chenxuan (Mon, 21 Aug 2017 11:58:39 GMT): chenxuan (Mon, 21 Aug 2017 11:58:49 GMT): kelvinzhong (Mon, 21 Aug 2017 14:33:19 GMT): asaningmaxchain (Tue, 22 Aug 2017 06:04:17 GMT): Hai-XuCheng (Wed, 23 Aug 2017 08:43:14 GMT): kustrun (Wed, 23 Aug 2017 13:42:52 GMT): kustrun (Wed, 23 Aug 2017 13:42:52 GMT): kustrun (Wed, 23 Aug 2017 13:42:52 GMT): Vadim (Wed, 23 Aug 2017 13:44:21 GMT): kustrun (Wed, 23 Aug 2017 13:46:00 GMT): Vadim (Wed, 23 Aug 2017 13:46:07 GMT): kustrun (Wed, 23 Aug 2017 13:46:38 GMT): Vadim (Wed, 23 Aug 2017 13:48:08 GMT): Vadim (Wed, 23 Aug 2017 13:48:57 GMT): kustrun (Wed, 23 Aug 2017 13:51:01 GMT): qizhang (Wed, 23 Aug 2017 19:17:58 GMT): qizhang (Wed, 23 Aug 2017 19:17:58 GMT): qizhang (Wed, 23 Aug 2017 19:17:58 GMT): toddinpal (Wed, 23 Aug 2017 20:03:58 GMT): qizhang (Wed, 23 Aug 2017 20:04:41 GMT): toddinpal (Wed, 23 Aug 2017 20:06:00 GMT): Vrai1127 (Wed, 23 Aug 2017 21:38:16 GMT): Vrai1127 (Wed, 23 Aug 2017 21:38:24 GMT): dave.enyeart (Thu, 24 Aug 2017 11:52:36 GMT): dave.enyeart (Thu, 24 Aug 2017 11:58:57 GMT): dave.enyeart (Thu, 24 Aug 2017 11:58:57 GMT): toddinpal (Thu, 24 Aug 2017 12:00:48 GMT): qizhang (Thu, 24 Aug 2017 18:05:58 GMT): dave.enyeart (Thu, 24 Aug 2017 19:05:06 GMT): kustrun (Fri, 25 Aug 2017 10:10:54 GMT): kustrun (Fri, 25 Aug 2017 10:10:54 GMT): qizhang (Fri, 25 Aug 2017 14:40:32 GMT): qizhang (Fri, 25 Aug 2017 14:40:32 GMT): asaningmaxchain (Fri, 25 Aug 2017 15:52:02 GMT): toddinpal (Fri, 25 Aug 2017 15:58:05 GMT): toddinpal (Fri, 25 Aug 2017 15:58:33 GMT): qizhang (Fri, 25 Aug 2017 16:00:32 GMT): qizhang (Fri, 25 Aug 2017 16:00:32 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:05:06 GMT): toddinpal (Fri, 25 Aug 2017 16:05:36 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:05:52 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:06:06 GMT): toddinpal (Fri, 25 Aug 2017 16:06:41 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:07:23 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:07:37 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:08:27 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:08:30 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:08:31 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:08:43 GMT): toddinpal (Fri, 25 Aug 2017 16:09:31 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:13:41 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:13:45 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:22:13 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:22:35 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:22:50 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:22:55 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:23:01 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:23:01 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:31:19 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:32:29 GMT): toddinpal (Fri, 25 Aug 2017 16:34:27 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:34:41 GMT): toddinpal (Fri, 25 Aug 2017 16:37:44 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:46:57 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:46:57 GMT): asaningmaxchain (Fri, 25 Aug 2017 16:47:07 GMT): toddinpal (Fri, 25 Aug 2017 17:22:34 GMT): JosephChang (Sun, 27 Aug 2017 02:12:47 GMT): ArnabChatterjee (Mon, 28 Aug 2017 04:54:22 GMT): evader1337 (Mon, 28 Aug 2017 09:13:19 GMT): toddinpal (Mon, 28 Aug 2017 13:16:09 GMT): ArnabChatterjee (Mon, 28 Aug 2017 23:29:54 GMT): toddinpal (Mon, 28 Aug 2017 23:32:10 GMT): toddinpal (Mon, 28 Aug 2017 23:42:19 GMT): ArnabChatterjee (Tue, 29 Aug 2017 00:44:55 GMT): ArnabChatterjee (Tue, 29 Aug 2017 06:35:40 GMT): ArnabChatterjee (Tue, 29 Aug 2017 06:39:00 GMT): ArnabChatterjee (Tue, 29 Aug 2017 06:40:52 GMT): asaningmaxchain (Tue, 29 Aug 2017 11:07:46 GMT): asaningmaxchain (Tue, 29 Aug 2017 11:08:19 GMT): asaningmaxchain (Tue, 29 Aug 2017 11:08:39 GMT): asaningmaxchain (Tue, 29 Aug 2017 11:08:48 GMT): dave.enyeart (Tue, 29 Aug 2017 11:38:43 GMT): dave.enyeart (Tue, 29 Aug 2017 11:40:15 GMT): asaningmaxchain (Tue, 29 Aug 2017 11:41:32 GMT): asaningmaxchain (Tue, 29 Aug 2017 11:41:40 GMT): asaningmaxchain (Tue, 29 Aug 2017 11:45:44 GMT): asaningmaxchain (Tue, 29 Aug 2017 11:45:45 GMT): ArnabChatterjee (Wed, 30 Aug 2017 04:09:53 GMT): ArnabChatterjee (Wed, 30 Aug 2017 08:43:41 GMT): ArnabChatterjee (Wed, 30 Aug 2017 08:45:36 GMT): ArnabChatterjee (Wed, 30 Aug 2017 08:50:37 GMT): sajeevkhan (Wed, 30 Aug 2017 10:07:25 GMT): asaningmaxchain (Wed, 30 Aug 2017 10:13:05 GMT): anishman (Wed, 30 Aug 2017 14:22:30 GMT): qizhang (Wed, 30 Aug 2017 14:23:00 GMT): qizhang (Wed, 30 Aug 2017 14:40:22 GMT): asaningmaxchain (Wed, 30 Aug 2017 14:40:58 GMT): qizhang (Wed, 30 Aug 2017 14:41:32 GMT): asaningmaxchain (Wed, 30 Aug 2017 14:42:10 GMT): asaningmaxchain (Wed, 30 Aug 2017 14:42:26 GMT): asaningmaxchain (Wed, 30 Aug 2017 14:43:25 GMT): asaningmaxchain (Wed, 30 Aug 2017 14:43:25 GMT): qizhang (Wed, 30 Aug 2017 14:44:43 GMT): qizhang (Wed, 30 Aug 2017 18:03:27 GMT): asaningmaxchain (Thu, 31 Aug 2017 01:08:32 GMT): glenlau (Sat, 02 Sep 2017 13:11:22 GMT): MeenakshiSingh (Tue, 05 Sep 2017 11:12:38 GMT): MeenakshiSingh (Tue, 05 Sep 2017 11:12:51 GMT): asaningmaxchain (Tue, 05 Sep 2017 11:44:36 GMT): asaningmaxchain (Tue, 05 Sep 2017 11:44:53 GMT): MeenakshiSingh (Tue, 05 Sep 2017 12:57:52 GMT): dave.enyeart (Tue, 05 Sep 2017 17:56:07 GMT): henryhs (Wed, 06 Sep 2017 03:03:04 GMT): nickgaski (Wed, 06 Sep 2017 15:40:08 GMT): Glen (Thu, 07 Sep 2017 01:05:35 GMT): dave.enyeart (Thu, 07 Sep 2017 11:58:16 GMT): dave.enyeart (Thu, 07 Sep 2017 11:58:16 GMT): asaningmaxchain (Thu, 07 Sep 2017 11:59:21 GMT): asaningmaxchain (Thu, 07 Sep 2017 11:59:21 GMT): dave.enyeart (Thu, 07 Sep 2017 12:01:14 GMT): asaningmaxchain (Thu, 07 Sep 2017 12:01:56 GMT): dave.enyeart (Thu, 07 Sep 2017 12:02:08 GMT): dave.enyeart (Thu, 07 Sep 2017 12:03:47 GMT): asaningmaxchain (Thu, 07 Sep 2017 12:03:52 GMT): dave.enyeart (Thu, 07 Sep 2017 12:04:18 GMT): asaningmaxchain (Thu, 07 Sep 2017 12:05:45 GMT): dave.enyeart (Thu, 07 Sep 2017 12:06:02 GMT): dave.enyeart (Thu, 07 Sep 2017 12:06:15 GMT): asaningmaxchain (Thu, 07 Sep 2017 12:06:17 GMT): dave.enyeart (Thu, 07 Sep 2017 12:07:19 GMT): asaningmaxchain (Thu, 07 Sep 2017 12:09:18 GMT): asaningmaxchain (Thu, 07 Sep 2017 12:09:18 GMT): dave.enyeart (Thu, 07 Sep 2017 12:09:41 GMT): asaningmaxchain (Thu, 07 Sep 2017 12:12:35 GMT): asaningmaxchain (Thu, 07 Sep 2017 12:13:50 GMT): Glen (Fri, 08 Sep 2017 00:05:29 GMT): Glen (Fri, 08 Sep 2017 00:05:29 GMT): Glen (Fri, 08 Sep 2017 02:31:16 GMT): Glen (Fri, 08 Sep 2017 02:35:21 GMT): Glen (Fri, 08 Sep 2017 03:07:02 GMT): jgabuya (Fri, 08 Sep 2017 08:25:50 GMT): zzying (Fri, 08 Sep 2017 08:49:29 GMT): Sarminb (Fri, 08 Sep 2017 09:50:00 GMT): Sarminb (Fri, 08 Sep 2017 09:50:25 GMT): Sarminb (Fri, 08 Sep 2017 09:51:11 GMT): Sarminb (Fri, 08 Sep 2017 09:51:32 GMT): kostas (Fri, 08 Sep 2017 20:17:56 GMT): bmalavan (Fri, 08 Sep 2017 23:16:39 GMT): kostas (Sat, 09 Sep 2017 20:51:27 GMT): kostas (Sat, 09 Sep 2017 20:51:46 GMT): kostas (Sat, 09 Sep 2017 20:51:51 GMT): Glen (Sun, 10 Sep 2017 01:38:43 GMT): Glen (Sun, 10 Sep 2017 01:40:46 GMT): kostas (Sun, 10 Sep 2017 22:13:50 GMT): kostas (Sun, 10 Sep 2017 22:14:22 GMT): manish-sethi (Mon, 11 Sep 2017 03:01:51 GMT): kostas (Mon, 11 Sep 2017 03:06:36 GMT): guoger (Mon, 11 Sep 2017 03:31:57 GMT): MeenakshiSingh (Mon, 11 Sep 2017 09:30:40 GMT): sanchezl (Mon, 11 Sep 2017 17:14:22 GMT): sanchezl (Mon, 11 Sep 2017 18:12:20 GMT): JonathanLevi (Mon, 11 Sep 2017 19:40:00 GMT): JonathanLevi (Mon, 11 Sep 2017 19:40:12 GMT): skbodwell (Mon, 11 Sep 2017 20:46:47 GMT): MeenakshiSingh (Tue, 12 Sep 2017 05:36:52 GMT): JonathanLevi (Tue, 12 Sep 2017 05:39:54 GMT): MeenakshiSingh (Tue, 12 Sep 2017 06:23:47 GMT): rsherwood (Tue, 12 Sep 2017 08:42:01 GMT): sonnykui (Tue, 12 Sep 2017 15:16:45 GMT): fred0071 (Tue, 12 Sep 2017 17:48:15 GMT): dave.enyeart (Tue, 12 Sep 2017 18:23:36 GMT): asaningmaxchain (Wed, 13 Sep 2017 01:01:49 GMT): asaningmaxchain (Wed, 13 Sep 2017 01:01:57 GMT): dave.enyeart (Wed, 13 Sep 2017 09:36:34 GMT): dave.enyeart (Wed, 13 Sep 2017 09:36:34 GMT): asaningmaxchain (Wed, 13 Sep 2017 10:51:49 GMT): asaningmaxchain (Wed, 13 Sep 2017 10:52:54 GMT): Richardpanf (Wed, 13 Sep 2017 10:53:30 GMT): dave.enyeart (Wed, 13 Sep 2017 10:53:45 GMT): asaningmaxchain (Wed, 13 Sep 2017 10:54:06 GMT): asaningmaxchain (Wed, 13 Sep 2017 10:54:21 GMT): asaningmaxchain (Wed, 13 Sep 2017 10:54:42 GMT): asaningmaxchain (Wed, 13 Sep 2017 10:54:42 GMT): dave.enyeart (Wed, 13 Sep 2017 10:55:45 GMT): asaningmaxchain (Wed, 13 Sep 2017 10:56:21 GMT): asaningmaxchain (Wed, 13 Sep 2017 10:56:22 GMT): dave.enyeart (Wed, 13 Sep 2017 10:57:41 GMT): asaningmaxchain (Wed, 13 Sep 2017 10:58:10 GMT): dave.enyeart (Wed, 13 Sep 2017 10:58:15 GMT): asaningmaxchain (Wed, 13 Sep 2017 11:00:30 GMT): asaningmaxchain (Wed, 13 Sep 2017 11:00:32 GMT): dave.enyeart (Wed, 13 Sep 2017 11:02:46 GMT): asaningmaxchain (Wed, 13 Sep 2017 11:03:33 GMT): MeenakshiSingh (Wed, 13 Sep 2017 14:20:27 GMT): dave.enyeart (Wed, 13 Sep 2017 14:23:41 GMT): dave.enyeart (Wed, 13 Sep 2017 14:23:41 GMT): FenglianXu (Wed, 13 Sep 2017 15:04:08 GMT): qizhang (Wed, 13 Sep 2017 19:29:45 GMT): qizhang (Wed, 13 Sep 2017 19:29:45 GMT): asaningmaxchain (Thu, 14 Sep 2017 01:06:11 GMT): gauthampamu (Thu, 14 Sep 2017 01:56:46 GMT): gauthampamu (Thu, 14 Sep 2017 01:57:31 GMT): gauthampamu (Thu, 14 Sep 2017 01:57:32 GMT): dave.enyeart (Thu, 14 Sep 2017 01:57:52 GMT): dave.enyeart (Thu, 14 Sep 2017 01:58:26 GMT): dave.enyeart (Thu, 14 Sep 2017 01:59:20 GMT): gauthampamu (Thu, 14 Sep 2017 02:02:59 GMT): gauthampamu (Thu, 14 Sep 2017 02:04:43 GMT): dave.enyeart (Thu, 14 Sep 2017 02:09:26 GMT): qizhang (Thu, 14 Sep 2017 02:13:45 GMT): dave.enyeart (Thu, 14 Sep 2017 02:18:25 GMT): dave.enyeart (Thu, 14 Sep 2017 02:18:25 GMT): qizhang (Thu, 14 Sep 2017 02:20:32 GMT): dave.enyeart (Thu, 14 Sep 2017 02:21:49 GMT): qizhang (Thu, 14 Sep 2017 02:24:36 GMT): qizhang (Thu, 14 Sep 2017 02:24:36 GMT): dave.enyeart (Thu, 14 Sep 2017 02:27:36 GMT): qizhang (Thu, 14 Sep 2017 02:28:49 GMT): dave.enyeart (Thu, 14 Sep 2017 02:30:16 GMT): qizhang (Thu, 14 Sep 2017 02:30:36 GMT): qizhang (Thu, 14 Sep 2017 02:33:05 GMT): dave.enyeart (Thu, 14 Sep 2017 02:36:59 GMT): qizhang (Thu, 14 Sep 2017 02:43:04 GMT): jon_s (Thu, 14 Sep 2017 15:44:50 GMT): ArnabChatterjee (Fri, 15 Sep 2017 02:25:51 GMT): FenglianXu (Fri, 15 Sep 2017 07:38:40 GMT): dave.enyeart (Fri, 15 Sep 2017 09:37:03 GMT): dave.enyeart (Fri, 15 Sep 2017 10:27:57 GMT): dave.enyeart (Fri, 15 Sep 2017 10:28:47 GMT): kostas (Sat, 16 Sep 2017 20:33:36 GMT): lenin.mehedy (Mon, 18 Sep 2017 00:07:07 GMT): pd93 (Mon, 18 Sep 2017 12:28:42 GMT): jrosmith (Mon, 18 Sep 2017 14:16:06 GMT): jrosmith (Mon, 18 Sep 2017 14:16:50 GMT): jrosmith (Mon, 18 Sep 2017 14:17:25 GMT): pd93 (Mon, 18 Sep 2017 14:18:36 GMT): jrosmith (Mon, 18 Sep 2017 14:18:53 GMT): pd93 (Mon, 18 Sep 2017 14:19:23 GMT): pd93 (Mon, 18 Sep 2017 14:35:12 GMT): asaningmaxchain (Tue, 19 Sep 2017 02:28:19 GMT): asaningmaxchain (Tue, 19 Sep 2017 02:28:48 GMT): dave.enyeart (Tue, 19 Sep 2017 02:33:14 GMT): dave.enyeart (Tue, 19 Sep 2017 02:33:14 GMT): dave.enyeart (Tue, 19 Sep 2017 02:33:14 GMT): asaningmaxchain (Tue, 19 Sep 2017 02:36:48 GMT): asaningmaxchain (Tue, 19 Sep 2017 02:36:49 GMT): asaningmaxchain (Tue, 19 Sep 2017 02:37:11 GMT): asaningmaxchain (Tue, 19 Sep 2017 02:37:12 GMT): dave.enyeart (Tue, 19 Sep 2017 02:39:31 GMT): asaningmaxchain (Tue, 19 Sep 2017 02:41:23 GMT): dave.enyeart (Tue, 19 Sep 2017 02:48:47 GMT): ArnabChatterjee (Tue, 19 Sep 2017 07:39:53 GMT): ArnabChatterjee (Tue, 19 Sep 2017 09:28:53 GMT): pd93 (Tue, 19 Sep 2017 10:23:21 GMT): pd93 (Tue, 19 Sep 2017 10:23:21 GMT): pd93 (Tue, 19 Sep 2017 10:23:21 GMT): pd93 (Tue, 19 Sep 2017 10:23:21 GMT): dave.enyeart (Tue, 19 Sep 2017 10:57:01 GMT): ArnabChatterjee (Tue, 19 Sep 2017 10:58:35 GMT): dave.enyeart (Tue, 19 Sep 2017 10:58:47 GMT): dave.enyeart (Tue, 19 Sep 2017 10:58:47 GMT): ArnabChatterjee (Tue, 19 Sep 2017 11:00:03 GMT): dave.enyeart (Tue, 19 Sep 2017 11:06:23 GMT): dave.enyeart (Tue, 19 Sep 2017 11:06:23 GMT): kesavannb (Tue, 19 Sep 2017 14:54:54 GMT): ArnabChatterjee (Tue, 19 Sep 2017 23:51:28 GMT): dave.enyeart (Wed, 20 Sep 2017 00:42:57 GMT): dave.enyeart (Wed, 20 Sep 2017 01:10:32 GMT): dave.enyeart (Wed, 20 Sep 2017 01:16:43 GMT): leminhy89 (Wed, 20 Sep 2017 10:48:08 GMT): tiennv (Thu, 21 Sep 2017 17:49:52 GMT): tiennv (Thu, 21 Sep 2017 17:50:11 GMT): asaningmaxchain (Fri, 22 Sep 2017 05:27:49 GMT): asaningmaxchain (Fri, 22 Sep 2017 05:28:00 GMT): asaningmaxchain (Fri, 22 Sep 2017 05:28:21 GMT): lenin.mehedy (Fri, 22 Sep 2017 07:51:31 GMT): dave.enyeart (Fri, 22 Sep 2017 10:50:47 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:51:43 GMT): dave.enyeart (Fri, 22 Sep 2017 10:51:45 GMT): dave.enyeart (Fri, 22 Sep 2017 10:52:19 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:53:25 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:53:25 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:53:25 GMT): dave.enyeart (Fri, 22 Sep 2017 10:54:38 GMT): dave.enyeart (Fri, 22 Sep 2017 10:55:00 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:55:45 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:55:50 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:56:06 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:56:28 GMT): dave.enyeart (Fri, 22 Sep 2017 10:56:46 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:57:00 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:59:33 GMT): asaningmaxchain (Fri, 22 Sep 2017 10:59:36 GMT): dave.enyeart (Fri, 22 Sep 2017 10:59:44 GMT): qizhang (Fri, 22 Sep 2017 19:53:59 GMT): dave.enyeart (Sat, 23 Sep 2017 04:06:01 GMT): yacovm (Sat, 23 Sep 2017 07:32:29 GMT): C0rWin (Sat, 23 Sep 2017 08:16:44 GMT): avi-nyc (Sun, 24 Sep 2017 00:03:33 GMT): ArnabChatterjee (Sun, 24 Sep 2017 23:38:04 GMT): asaningmaxchain (Mon, 25 Sep 2017 01:04:22 GMT): FengChen_1982 (Mon, 25 Sep 2017 03:02:37 GMT): jon_s (Mon, 25 Sep 2017 05:57:53 GMT): ArnabChatterjee (Mon, 25 Sep 2017 08:40:30 GMT): toriaezunama (Mon, 25 Sep 2017 12:17:39 GMT): qizhang (Mon, 25 Sep 2017 14:19:46 GMT): asaningmaxchain (Mon, 25 Sep 2017 14:29:41 GMT): Vadim (Mon, 25 Sep 2017 14:33:27 GMT): qizhang (Mon, 25 Sep 2017 14:35:15 GMT): qizhang (Mon, 25 Sep 2017 15:25:30 GMT): qizhang (Mon, 25 Sep 2017 15:25:30 GMT): qizhang (Mon, 25 Sep 2017 15:25:30 GMT): qizhang (Mon, 25 Sep 2017 15:25:30 GMT): qizhang (Mon, 25 Sep 2017 15:25:55 GMT): jon_s (Mon, 25 Sep 2017 16:24:40 GMT): dave.enyeart (Mon, 25 Sep 2017 16:29:45 GMT): dave.enyeart (Mon, 25 Sep 2017 16:30:05 GMT): qizhang (Tue, 26 Sep 2017 01:59:07 GMT): yushan (Tue, 26 Sep 2017 09:15:56 GMT): qizhang (Tue, 26 Sep 2017 15:35:42 GMT): AnthonyMiclet (Tue, 26 Sep 2017 16:09:40 GMT): jrosmith (Tue, 26 Sep 2017 16:36:06 GMT): dave.enyeart (Wed, 27 Sep 2017 02:18:21 GMT): dave.enyeart (Wed, 27 Sep 2017 02:18:27 GMT): dave.enyeart (Wed, 27 Sep 2017 02:22:52 GMT): dave.enyeart (Wed, 27 Sep 2017 02:25:48 GMT): qizhang (Wed, 27 Sep 2017 02:43:13 GMT): asaningmaxchain (Wed, 27 Sep 2017 03:16:22 GMT): asaningmaxchain (Wed, 27 Sep 2017 03:16:23 GMT): dave.enyeart (Wed, 27 Sep 2017 03:46:06 GMT): dave.enyeart (Wed, 27 Sep 2017 03:47:01 GMT): asaningmaxchain (Wed, 27 Sep 2017 03:47:16 GMT): asaningmaxchain (Wed, 27 Sep 2017 03:47:31 GMT): dave.enyeart (Wed, 27 Sep 2017 03:47:47 GMT): asaningmaxchain (Wed, 27 Sep 2017 03:48:33 GMT): dave.enyeart (Wed, 27 Sep 2017 03:48:55 GMT): asaningmaxchain (Wed, 27 Sep 2017 03:49:20 GMT): dave.enyeart (Wed, 27 Sep 2017 03:49:33 GMT): asaningmaxchain (Wed, 27 Sep 2017 03:50:39 GMT): asaningmaxchain (Wed, 27 Sep 2017 03:50:39 GMT): qizhang (Wed, 27 Sep 2017 04:31:02 GMT): grapebaba (Wed, 27 Sep 2017 06:20:11 GMT): asaningmaxchain (Wed, 27 Sep 2017 09:46:22 GMT): asaningmaxchain (Wed, 27 Sep 2017 09:46:33 GMT): asaningmaxchain (Wed, 27 Sep 2017 09:46:33 GMT): asaningmaxchain (Wed, 27 Sep 2017 09:46:33 GMT): asaningmaxchain (Wed, 27 Sep 2017 09:47:34 GMT): asaningmaxchain (Wed, 27 Sep 2017 09:47:34 GMT): dave.enyeart (Wed, 27 Sep 2017 12:18:33 GMT): dave.enyeart (Wed, 27 Sep 2017 12:18:33 GMT): dave.enyeart (Wed, 27 Sep 2017 12:19:53 GMT): dave.enyeart (Wed, 27 Sep 2017 12:21:33 GMT): dave.enyeart (Wed, 27 Sep 2017 12:23:46 GMT): asaningmaxchain (Wed, 27 Sep 2017 12:35:15 GMT): asaningmaxchain (Wed, 27 Sep 2017 12:35:16 GMT): manish-sethi (Wed, 27 Sep 2017 13:00:47 GMT): dave.enyeart (Wed, 27 Sep 2017 13:08:18 GMT): asaningmaxchain (Wed, 27 Sep 2017 13:56:11 GMT): asaningmaxchain (Wed, 27 Sep 2017 13:56:51 GMT): asaningmaxchain (Wed, 27 Sep 2017 13:56:59 GMT): asaningmaxchain (Wed, 27 Sep 2017 13:56:59 GMT): asaningmaxchain (Wed, 27 Sep 2017 13:56:59 GMT): asaningmaxchain (Wed, 27 Sep 2017 14:05:20 GMT): asaningmaxchain (Wed, 27 Sep 2017 14:06:01 GMT): manish-sethi (Wed, 27 Sep 2017 14:37:32 GMT): ArnabChatterjee (Thu, 28 Sep 2017 07:46:32 GMT): ArnabChatterjee (Thu, 28 Sep 2017 07:46:32 GMT): grapebaba (Thu, 28 Sep 2017 08:37:43 GMT): Vadim (Thu, 28 Sep 2017 08:39:36 GMT): Vadim (Thu, 28 Sep 2017 08:40:06 GMT): ArnabChatterjee (Thu, 28 Sep 2017 08:41:21 GMT): Vadim (Thu, 28 Sep 2017 08:43:38 GMT): rakmoh (Thu, 28 Sep 2017 14:19:38 GMT): antitoine (Fri, 29 Sep 2017 14:19:07 GMT): dave.enyeart (Fri, 29 Sep 2017 15:09:50 GMT): antitoine (Fri, 29 Sep 2017 15:11:49 GMT): clempo (Fri, 29 Sep 2017 15:12:33 GMT): clempo (Fri, 29 Sep 2017 15:24:22 GMT): clempo (Fri, 29 Sep 2017 19:12:41 GMT): mastersingh24 (Fri, 29 Sep 2017 22:33:24 GMT): mastersingh24 (Fri, 29 Sep 2017 22:33:45 GMT): dave.enyeart (Sat, 30 Sep 2017 00:08:35 GMT): dave.enyeart (Sat, 30 Sep 2017 00:08:35 GMT): dave.enyeart (Sat, 30 Sep 2017 00:08:35 GMT): dave.enyeart (Sat, 30 Sep 2017 00:08:42 GMT): dave.enyeart (Sat, 30 Sep 2017 00:08:59 GMT): mastersingh24 (Sat, 30 Sep 2017 09:11:17 GMT): mastersingh24 (Sat, 30 Sep 2017 09:11:17 GMT): asaningmaxchain (Sun, 01 Oct 2017 03:46:53 GMT): dave.enyeart (Sun, 01 Oct 2017 12:47:09 GMT): BernardLin (Sun, 01 Oct 2017 18:28:34 GMT): sampath06 (Mon, 02 Oct 2017 03:06:00 GMT): wy (Tue, 03 Oct 2017 02:59:54 GMT): wy (Tue, 03 Oct 2017 03:01:33 GMT): asaningmaxchain (Tue, 03 Oct 2017 03:39:51 GMT): dave.enyeart (Tue, 03 Oct 2017 11:36:39 GMT): asaningmaxchain (Tue, 03 Oct 2017 11:38:07 GMT): lovesh (Tue, 03 Oct 2017 14:05:08 GMT): jrosmith (Tue, 03 Oct 2017 14:40:04 GMT): ganbold (Tue, 03 Oct 2017 14:55:03 GMT): jrosmith (Tue, 03 Oct 2017 15:40:05 GMT): jrosmith (Tue, 03 Oct 2017 17:29:09 GMT): AlekNS (Wed, 04 Oct 2017 05:14:20 GMT): AnhDinh (Wed, 04 Oct 2017 06:45:37 GMT): AnhDinh (Wed, 04 Oct 2017 06:47:08 GMT): AnhDinh (Wed, 04 Oct 2017 06:47:34 GMT): tennenjl (Wed, 04 Oct 2017 12:14:35 GMT): carlosfaria (Wed, 04 Oct 2017 12:48:49 GMT): rbochenski (Wed, 04 Oct 2017 12:56:45 GMT): manish-sethi (Thu, 05 Oct 2017 02:04:30 GMT): manish-sethi (Thu, 05 Oct 2017 02:08:11 GMT): qizhang (Thu, 05 Oct 2017 14:32:46 GMT): manish-sethi (Thu, 05 Oct 2017 14:38:33 GMT): manish-sethi (Thu, 05 Oct 2017 14:39:52 GMT): manish-sethi (Thu, 05 Oct 2017 14:39:52 GMT): wy (Thu, 05 Oct 2017 15:39:53 GMT): dave.enyeart (Thu, 05 Oct 2017 17:23:24 GMT): abhisamant (Thu, 05 Oct 2017 17:33:12 GMT): george.hant (Thu, 05 Oct 2017 18:19:14 GMT): jrosmith (Thu, 05 Oct 2017 20:24:28 GMT): manish-sethi (Thu, 05 Oct 2017 20:25:31 GMT): manish-sethi (Thu, 05 Oct 2017 20:27:44 GMT): jrosmith (Thu, 05 Oct 2017 20:46:32 GMT): wy (Fri, 06 Oct 2017 01:25:21 GMT): dave.enyeart (Fri, 06 Oct 2017 02:00:10 GMT): wy (Fri, 06 Oct 2017 02:28:46 GMT): dave.enyeart (Fri, 06 Oct 2017 02:29:57 GMT): wy (Fri, 06 Oct 2017 02:30:28 GMT): wy (Fri, 06 Oct 2017 02:30:53 GMT): dave.enyeart (Fri, 06 Oct 2017 02:31:34 GMT): wy (Fri, 06 Oct 2017 02:31:52 GMT): wy (Fri, 06 Oct 2017 02:32:12 GMT): dave.enyeart (Fri, 06 Oct 2017 02:32:49 GMT): wy (Fri, 06 Oct 2017 02:34:09 GMT): manish-sethi (Fri, 06 Oct 2017 02:40:34 GMT): manish-sethi (Fri, 06 Oct 2017 02:41:12 GMT): manish-sethi (Fri, 06 Oct 2017 02:41:51 GMT): wy (Fri, 06 Oct 2017 02:42:14 GMT): manish-sethi (Fri, 06 Oct 2017 02:43:45 GMT): wy (Fri, 06 Oct 2017 02:44:03 GMT): wy (Fri, 06 Oct 2017 02:46:00 GMT): manish-sethi (Fri, 06 Oct 2017 02:46:40 GMT): manish-sethi (Fri, 06 Oct 2017 02:47:12 GMT): manish-sethi (Fri, 06 Oct 2017 02:47:29 GMT): wy (Fri, 06 Oct 2017 02:47:51 GMT): wy (Fri, 06 Oct 2017 02:47:51 GMT): dave.enyeart (Fri, 06 Oct 2017 02:48:34 GMT): manish-sethi (Fri, 06 Oct 2017 02:49:40 GMT): dave.enyeart (Fri, 06 Oct 2017 02:49:46 GMT): manish-sethi (Fri, 06 Oct 2017 02:50:10 GMT): manish-sethi (Fri, 06 Oct 2017 02:50:10 GMT): wy (Fri, 06 Oct 2017 02:50:46 GMT): manish-sethi (Fri, 06 Oct 2017 02:50:55 GMT): wy (Fri, 06 Oct 2017 02:51:08 GMT): manish-sethi (Fri, 06 Oct 2017 02:52:04 GMT): wy (Fri, 06 Oct 2017 02:52:44 GMT): manish-sethi (Fri, 06 Oct 2017 02:56:07 GMT): dave.enyeart (Fri, 06 Oct 2017 02:56:23 GMT): wy (Fri, 06 Oct 2017 02:57:38 GMT): wy (Fri, 06 Oct 2017 02:58:14 GMT): dave.enyeart (Fri, 06 Oct 2017 02:58:57 GMT): wy (Fri, 06 Oct 2017 02:59:41 GMT): wy (Fri, 06 Oct 2017 03:00:14 GMT): wy (Fri, 06 Oct 2017 03:00:38 GMT): dave.enyeart (Fri, 06 Oct 2017 03:00:55 GMT): wy (Fri, 06 Oct 2017 03:01:47 GMT): dave.enyeart (Fri, 06 Oct 2017 03:02:08 GMT): wy (Fri, 06 Oct 2017 03:02:54 GMT): wy (Fri, 06 Oct 2017 03:03:11 GMT): dave.enyeart (Fri, 06 Oct 2017 03:03:16 GMT): wy (Fri, 06 Oct 2017 03:03:45 GMT): dave.enyeart (Fri, 06 Oct 2017 03:05:45 GMT): wy (Fri, 06 Oct 2017 03:09:54 GMT): dave.enyeart (Fri, 06 Oct 2017 03:10:18 GMT): wy (Fri, 06 Oct 2017 03:10:33 GMT): dave.enyeart (Fri, 06 Oct 2017 03:14:06 GMT): dave.enyeart (Fri, 06 Oct 2017 03:14:08 GMT): dave.enyeart (Fri, 06 Oct 2017 03:15:02 GMT): dave.enyeart (Fri, 06 Oct 2017 03:15:09 GMT): wy (Fri, 06 Oct 2017 03:15:58 GMT): wy (Fri, 06 Oct 2017 03:16:07 GMT): dave.enyeart (Fri, 06 Oct 2017 03:16:14 GMT): wy (Fri, 06 Oct 2017 03:26:26 GMT): wy (Fri, 06 Oct 2017 03:26:33 GMT): dave.enyeart (Fri, 06 Oct 2017 03:27:18 GMT): dave.enyeart (Fri, 06 Oct 2017 03:27:34 GMT): dave.enyeart (Fri, 06 Oct 2017 03:38:21 GMT): dave.enyeart (Fri, 06 Oct 2017 03:38:42 GMT): wy (Fri, 06 Oct 2017 03:39:22 GMT): dave.enyeart (Fri, 06 Oct 2017 03:39:33 GMT): dave.enyeart (Fri, 06 Oct 2017 03:39:33 GMT): wy (Fri, 06 Oct 2017 03:39:42 GMT): dave.enyeart (Fri, 06 Oct 2017 03:39:50 GMT): wy (Fri, 06 Oct 2017 03:40:06 GMT): dave.enyeart (Fri, 06 Oct 2017 03:41:42 GMT): dave.enyeart (Fri, 06 Oct 2017 03:41:42 GMT): dave.enyeart (Fri, 06 Oct 2017 03:43:04 GMT): dave.enyeart (Fri, 06 Oct 2017 03:47:07 GMT): manish-sethi (Fri, 06 Oct 2017 03:47:36 GMT): dave.enyeart (Fri, 06 Oct 2017 03:47:38 GMT): wy (Fri, 06 Oct 2017 03:53:29 GMT): wy (Fri, 06 Oct 2017 03:53:34 GMT): wy (Fri, 06 Oct 2017 03:53:43 GMT): dave.enyeart (Fri, 06 Oct 2017 03:54:16 GMT): dave.enyeart (Fri, 06 Oct 2017 03:54:17 GMT): wy (Fri, 06 Oct 2017 03:55:17 GMT): dave.enyeart (Fri, 06 Oct 2017 03:55:24 GMT): wy (Fri, 06 Oct 2017 03:55:33 GMT): wy (Fri, 06 Oct 2017 03:55:42 GMT): wy (Fri, 06 Oct 2017 03:55:48 GMT): dave.enyeart (Fri, 06 Oct 2017 03:56:10 GMT): Rick (Fri, 06 Oct 2017 04:00:38 GMT): manish-sethi (Fri, 06 Oct 2017 04:04:05 GMT): manish-sethi (Fri, 06 Oct 2017 04:04:05 GMT): wy (Fri, 06 Oct 2017 04:11:50 GMT): wy (Fri, 06 Oct 2017 04:11:50 GMT): manish-sethi (Fri, 06 Oct 2017 04:18:53 GMT): manish-sethi (Fri, 06 Oct 2017 04:19:27 GMT): wy (Fri, 06 Oct 2017 04:22:19 GMT): wy (Fri, 06 Oct 2017 04:22:54 GMT): manish-sethi (Fri, 06 Oct 2017 04:25:43 GMT): manish-sethi (Fri, 06 Oct 2017 04:26:13 GMT): wy (Fri, 06 Oct 2017 04:31:02 GMT): wy (Fri, 06 Oct 2017 04:31:02 GMT): wy (Fri, 06 Oct 2017 04:32:38 GMT): ArnabChatterjee (Fri, 06 Oct 2017 04:55:41 GMT): wy (Fri, 06 Oct 2017 05:24:38 GMT): ArnabChatterjee (Fri, 06 Oct 2017 05:25:33 GMT): ArnabChatterjee (Fri, 06 Oct 2017 05:25:41 GMT): ArnabChatterjee (Fri, 06 Oct 2017 05:26:13 GMT): ArnabChatterjee (Fri, 06 Oct 2017 05:35:34 GMT): wy (Fri, 06 Oct 2017 05:37:04 GMT): ArnabChatterjee (Fri, 06 Oct 2017 05:38:20 GMT): wy (Fri, 06 Oct 2017 05:38:28 GMT): wy (Fri, 06 Oct 2017 05:39:05 GMT): ArnabChatterjee (Fri, 06 Oct 2017 05:40:53 GMT): wy (Fri, 06 Oct 2017 08:00:59 GMT): wy (Fri, 06 Oct 2017 08:00:59 GMT): wy (Fri, 06 Oct 2017 08:01:42 GMT): dave.enyeart (Fri, 06 Oct 2017 11:16:31 GMT): dave.enyeart (Fri, 06 Oct 2017 11:16:31 GMT): dave.enyeart (Fri, 06 Oct 2017 11:16:48 GMT): dave.enyeart (Fri, 06 Oct 2017 11:17:07 GMT): wy (Fri, 06 Oct 2017 12:36:40 GMT): wy (Fri, 06 Oct 2017 12:36:40 GMT): Vadim (Fri, 06 Oct 2017 12:37:58 GMT): wy (Fri, 06 Oct 2017 12:42:20 GMT): whoselife (Sat, 07 Oct 2017 15:35:37 GMT): ArnabChatterjee (Sun, 08 Oct 2017 08:22:55 GMT): asaningmaxchain (Mon, 09 Oct 2017 05:57:32 GMT): asaningmaxchain (Mon, 09 Oct 2017 05:57:32 GMT): asaningmaxchain (Mon, 09 Oct 2017 05:58:35 GMT): asaningmaxchain (Mon, 09 Oct 2017 05:58:35 GMT): dave.enyeart (Mon, 09 Oct 2017 09:01:32 GMT): asaningmaxchain (Mon, 09 Oct 2017 09:10:48 GMT): dave.enyeart (Mon, 09 Oct 2017 09:11:28 GMT): dave.enyeart (Mon, 09 Oct 2017 09:11:28 GMT): dave.enyeart (Mon, 09 Oct 2017 09:12:53 GMT): dave.enyeart (Mon, 09 Oct 2017 09:12:53 GMT): dave.enyeart (Mon, 09 Oct 2017 09:12:53 GMT): asaningmaxchain (Mon, 09 Oct 2017 09:15:58 GMT): dave.enyeart (Mon, 09 Oct 2017 09:17:35 GMT): dave.enyeart (Mon, 09 Oct 2017 09:17:35 GMT): dave.enyeart (Mon, 09 Oct 2017 09:17:42 GMT): jichen (Mon, 09 Oct 2017 09:17:42 GMT): muralisr (Mon, 09 Oct 2017 11:04:13 GMT): muralisr (Mon, 09 Oct 2017 11:05:55 GMT): ArnabChatterjee (Mon, 09 Oct 2017 14:07:19 GMT): lmars (Tue, 10 Oct 2017 15:51:03 GMT): jimthematrix (Tue, 10 Oct 2017 19:10:15 GMT): jimthematrix (Tue, 10 Oct 2017 19:10:15 GMT): davidkel (Tue, 10 Oct 2017 19:10:15 GMT): dave.enyeart (Tue, 10 Oct 2017 19:38:30 GMT): dave.enyeart (Tue, 10 Oct 2017 19:38:30 GMT): jrosmith (Tue, 10 Oct 2017 19:49:54 GMT): jimthematrix (Wed, 11 Oct 2017 02:22:41 GMT): tennenjl (Wed, 11 Oct 2017 02:42:22 GMT): tennenjl (Wed, 11 Oct 2017 02:42:22 GMT): amolpednekar (Wed, 11 Oct 2017 05:16:51 GMT): manish-sethi (Wed, 11 Oct 2017 12:34:43 GMT): manish-sethi (Wed, 11 Oct 2017 12:34:43 GMT): tennenjl (Wed, 11 Oct 2017 13:46:25 GMT): tennenjl (Wed, 11 Oct 2017 13:46:25 GMT): dave.enyeart (Wed, 11 Oct 2017 14:18:05 GMT): dave.enyeart (Wed, 11 Oct 2017 14:18:05 GMT): dave.enyeart (Wed, 11 Oct 2017 14:18:05 GMT): dave.enyeart (Wed, 11 Oct 2017 14:18:05 GMT): dave.enyeart (Wed, 11 Oct 2017 14:18:05 GMT): tennenjl (Wed, 11 Oct 2017 14:32:37 GMT): dave.enyeart (Wed, 11 Oct 2017 14:33:07 GMT): dave.enyeart (Wed, 11 Oct 2017 14:33:07 GMT): tennenjl (Wed, 11 Oct 2017 14:36:32 GMT): qizhang (Wed, 11 Oct 2017 16:09:59 GMT): qizhang (Wed, 11 Oct 2017 16:10:28 GMT): Asara (Wed, 11 Oct 2017 18:27:31 GMT): yacovm (Wed, 11 Oct 2017 20:20:08 GMT): baramustafa (Wed, 11 Oct 2017 22:30:20 GMT): dave.enyeart (Wed, 11 Oct 2017 22:47:10 GMT): SanketPanchamia (Thu, 12 Oct 2017 06:13:59 GMT): SanketPanchamia (Thu, 12 Oct 2017 06:15:40 GMT): dave.enyeart (Thu, 12 Oct 2017 09:03:06 GMT): dave.enyeart (Thu, 12 Oct 2017 09:03:46 GMT): SanketPanchamia (Thu, 12 Oct 2017 09:04:55 GMT): cs-wang (Thu, 12 Oct 2017 11:05:18 GMT): cs-wang (Thu, 12 Oct 2017 11:09:42 GMT): minollo (Fri, 13 Oct 2017 01:57:08 GMT): changrui (Fri, 13 Oct 2017 03:44:44 GMT): changrui (Fri, 13 Oct 2017 03:51:58 GMT): dave.enyeart (Fri, 13 Oct 2017 10:50:50 GMT): Jonny (Mon, 16 Oct 2017 10:00:29 GMT): dave.enyeart (Mon, 16 Oct 2017 10:22:03 GMT): dave.enyeart (Mon, 16 Oct 2017 10:22:03 GMT): Jonny (Mon, 16 Oct 2017 10:50:15 GMT): Jonny (Mon, 16 Oct 2017 10:52:52 GMT): Jonny (Mon, 16 Oct 2017 10:53:11 GMT): dave.enyeart (Mon, 16 Oct 2017 10:57:28 GMT): dave.enyeart (Mon, 16 Oct 2017 10:57:41 GMT): dave.enyeart (Mon, 16 Oct 2017 10:58:06 GMT): Jonny (Mon, 16 Oct 2017 10:59:58 GMT): Jonny (Mon, 16 Oct 2017 11:00:27 GMT): Jonny (Mon, 16 Oct 2017 11:00:27 GMT): Jonny (Mon, 16 Oct 2017 11:10:46 GMT): dave.enyeart (Mon, 16 Oct 2017 11:39:20 GMT): Jonny (Mon, 16 Oct 2017 11:46:27 GMT): dave.enyeart (Mon, 16 Oct 2017 13:00:56 GMT): thakkarparth007 (Mon, 16 Oct 2017 19:34:07 GMT): manish-sethi (Mon, 16 Oct 2017 19:56:18 GMT): rohitadivi (Mon, 16 Oct 2017 21:43:20 GMT): bh4rtp (Wed, 18 Oct 2017 08:06:15 GMT): shanlusun (Wed, 18 Oct 2017 09:55:08 GMT): shanlusun (Wed, 18 Oct 2017 09:56:29 GMT): Vadim (Wed, 18 Oct 2017 09:58:09 GMT): shanlusun (Wed, 18 Oct 2017 09:59:46 GMT): Vadim (Wed, 18 Oct 2017 10:00:30 GMT): Vadim (Wed, 18 Oct 2017 10:01:03 GMT): shanlusun (Wed, 18 Oct 2017 10:01:36 GMT): shanlusun (Wed, 18 Oct 2017 10:02:07 GMT): Vadim (Wed, 18 Oct 2017 10:02:35 GMT): shanlusun (Wed, 18 Oct 2017 10:04:20 GMT): Vadim (Wed, 18 Oct 2017 10:16:36 GMT): Vadim (Wed, 18 Oct 2017 10:16:36 GMT): Vadim (Wed, 18 Oct 2017 10:16:43 GMT): bh4rtp (Wed, 18 Oct 2017 10:17:15 GMT): Vadim (Wed, 18 Oct 2017 10:17:49 GMT): bh4rtp (Wed, 18 Oct 2017 10:19:04 GMT): shanlusun (Wed, 18 Oct 2017 10:19:38 GMT): Vadim (Wed, 18 Oct 2017 10:19:45 GMT): bh4rtp (Wed, 18 Oct 2017 10:20:46 GMT): shanlusun (Wed, 18 Oct 2017 10:20:55 GMT): shanlusun (Wed, 18 Oct 2017 10:21:38 GMT): Vadim (Wed, 18 Oct 2017 10:21:47 GMT): Vadim (Wed, 18 Oct 2017 10:22:00 GMT): shanlusun (Wed, 18 Oct 2017 10:22:00 GMT): Vadim (Wed, 18 Oct 2017 10:22:38 GMT): shanlusun (Wed, 18 Oct 2017 10:24:05 GMT): bh4rtp (Wed, 18 Oct 2017 10:24:44 GMT): Vadim (Wed, 18 Oct 2017 10:24:53 GMT): qizhang (Wed, 18 Oct 2017 15:12:01 GMT): Vadim (Wed, 18 Oct 2017 15:13:42 GMT): dave.enyeart (Wed, 18 Oct 2017 15:14:11 GMT): qizhang (Wed, 18 Oct 2017 15:14:52 GMT): dave.enyeart (Wed, 18 Oct 2017 15:15:08 GMT): dave.enyeart (Wed, 18 Oct 2017 15:15:12 GMT): qizhang (Wed, 18 Oct 2017 15:15:49 GMT): qizhang (Wed, 18 Oct 2017 18:54:07 GMT): qizhang (Wed, 18 Oct 2017 18:54:07 GMT): bamboo (Thu, 19 Oct 2017 12:16:20 GMT): kostas (Thu, 19 Oct 2017 14:31:50 GMT): kostas (Thu, 19 Oct 2017 14:35:57 GMT): kostas (Thu, 19 Oct 2017 14:36:52 GMT): kostas (Thu, 19 Oct 2017 14:37:06 GMT): manish-sethi (Thu, 19 Oct 2017 14:39:37 GMT): kostas (Thu, 19 Oct 2017 14:39:48 GMT): bh4rtp (Fri, 20 Oct 2017 01:14:08 GMT): bh4rtp (Fri, 20 Oct 2017 01:14:08 GMT): bh4rtp (Fri, 20 Oct 2017 02:44:02 GMT): gen_el (Fri, 20 Oct 2017 12:04:44 GMT): kostas (Fri, 20 Oct 2017 12:07:46 GMT): kostas (Fri, 20 Oct 2017 12:07:46 GMT): bh4rtp (Sat, 21 Oct 2017 00:14:30 GMT): bh4rtp (Sat, 21 Oct 2017 03:19:51 GMT): thakkarparth007 (Sat, 21 Oct 2017 08:04:41 GMT): bh4rtp (Sat, 21 Oct 2017 09:26:33 GMT): bh4rtp (Sat, 21 Oct 2017 10:06:19 GMT): thakkarparth007 (Sat, 21 Oct 2017 10:15:48 GMT): thakkarparth007 (Sat, 21 Oct 2017 10:16:08 GMT): qizhang (Mon, 23 Oct 2017 19:22:15 GMT): qizhang (Mon, 23 Oct 2017 19:22:31 GMT): dave.enyeart (Mon, 23 Oct 2017 19:36:16 GMT): minollo (Tue, 24 Oct 2017 16:31:21 GMT): ConConCop (Tue, 24 Oct 2017 17:12:30 GMT): dave.enyeart (Tue, 24 Oct 2017 17:12:32 GMT): ConConCop (Tue, 24 Oct 2017 17:20:31 GMT): manish-sethi (Tue, 24 Oct 2017 19:29:32 GMT): dave.enyeart (Tue, 24 Oct 2017 20:25:44 GMT): dave.enyeart (Tue, 24 Oct 2017 20:25:44 GMT): dave.enyeart (Tue, 24 Oct 2017 20:25:44 GMT): dave.enyeart (Tue, 24 Oct 2017 20:28:23 GMT): minollo (Tue, 24 Oct 2017 22:31:07 GMT): minollo (Tue, 24 Oct 2017 22:31:58 GMT): ConConCop (Wed, 25 Oct 2017 00:31:31 GMT): dave.enyeart (Wed, 25 Oct 2017 00:33:42 GMT): dave.enyeart (Wed, 25 Oct 2017 00:35:15 GMT): ConConCop (Wed, 25 Oct 2017 03:02:14 GMT): indira.kalagara (Wed, 25 Oct 2017 13:06:28 GMT): manish-sethi (Wed, 25 Oct 2017 14:28:30 GMT): minollo (Wed, 25 Oct 2017 14:35:21 GMT): grapebaba (Thu, 26 Oct 2017 04:40:24 GMT): minollo (Thu, 26 Oct 2017 04:42:30 GMT): grapebaba (Thu, 26 Oct 2017 04:45:03 GMT): bh4rtp (Thu, 26 Oct 2017 06:38:16 GMT): bh4rtp (Thu, 26 Oct 2017 06:38:16 GMT): dave.enyeart (Thu, 26 Oct 2017 12:06:58 GMT): dave.enyeart (Thu, 26 Oct 2017 12:06:58 GMT): bh4rtp (Thu, 26 Oct 2017 15:00:42 GMT): nate94305 (Fri, 27 Oct 2017 01:09:17 GMT): nate94305 (Fri, 27 Oct 2017 01:11:20 GMT): qizhang (Fri, 27 Oct 2017 02:12:29 GMT): qizhang (Fri, 27 Oct 2017 02:12:29 GMT): Vadim (Fri, 27 Oct 2017 05:45:56 GMT): Jonny (Fri, 27 Oct 2017 08:20:17 GMT): knagware9 (Sat, 28 Oct 2017 10:46:58 GMT): kostas (Sun, 29 Oct 2017 16:41:37 GMT): niteshsolanki (Tue, 31 Oct 2017 12:51:41 GMT): dave.enyeart (Tue, 31 Oct 2017 13:02:58 GMT): dave.enyeart (Tue, 31 Oct 2017 13:03:58 GMT): niteshsolanki (Tue, 31 Oct 2017 13:16:14 GMT): asaningmaxchain (Wed, 01 Nov 2017 04:44:04 GMT): asaningmaxchain (Wed, 01 Nov 2017 04:44:12 GMT): asaningmaxchain (Wed, 01 Nov 2017 04:44:14 GMT): asaningmaxchain (Wed, 01 Nov 2017 04:44:29 GMT): asaningmaxchain (Wed, 01 Nov 2017 04:44:39 GMT): bh4rtp (Wed, 01 Nov 2017 08:50:50 GMT): Vadim (Wed, 01 Nov 2017 08:52:14 GMT): bh4rtp (Wed, 01 Nov 2017 08:54:18 GMT): Vadim (Wed, 01 Nov 2017 08:55:51 GMT): Vadim (Wed, 01 Nov 2017 08:56:27 GMT): bh4rtp (Wed, 01 Nov 2017 08:59:05 GMT): dave.enyeart (Wed, 01 Nov 2017 09:09:59 GMT): dave.enyeart (Wed, 01 Nov 2017 09:09:59 GMT): dave.enyeart (Wed, 01 Nov 2017 09:09:59 GMT): dave.enyeart (Wed, 01 Nov 2017 09:10:02 GMT): dave.enyeart (Wed, 01 Nov 2017 09:10:02 GMT): asaningmaxchain (Wed, 01 Nov 2017 09:11:33 GMT): asaningmaxchain (Wed, 01 Nov 2017 09:12:25 GMT): dave.enyeart (Wed, 01 Nov 2017 09:17:56 GMT): dave.enyeart (Wed, 01 Nov 2017 09:18:07 GMT): asaningmaxchain (Wed, 01 Nov 2017 09:52:22 GMT): kayadhami (Wed, 01 Nov 2017 16:00:58 GMT): bh4rtp (Thu, 02 Nov 2017 15:31:49 GMT): bh4rtp (Thu, 02 Nov 2017 15:35:25 GMT): dave.enyeart (Thu, 02 Nov 2017 15:39:05 GMT): qizhang (Thu, 02 Nov 2017 15:39:55 GMT): bh4rtp (Thu, 02 Nov 2017 15:40:23 GMT): dave.enyeart (Thu, 02 Nov 2017 15:42:22 GMT): qizhang (Thu, 02 Nov 2017 15:43:27 GMT): dave.enyeart (Thu, 02 Nov 2017 15:43:33 GMT): qizhang (Thu, 02 Nov 2017 15:44:25 GMT): dave.enyeart (Thu, 02 Nov 2017 15:45:04 GMT): dave.enyeart (Thu, 02 Nov 2017 15:45:49 GMT): qizhang (Thu, 02 Nov 2017 15:45:53 GMT): dave.enyeart (Thu, 02 Nov 2017 15:46:28 GMT): qizhang (Thu, 02 Nov 2017 15:46:52 GMT): kiranarshakota (Fri, 03 Nov 2017 00:55:28 GMT): bh4rtp (Fri, 03 Nov 2017 03:01:48 GMT): niteshsolanki (Fri, 03 Nov 2017 10:29:41 GMT): dave.enyeart (Fri, 03 Nov 2017 10:33:24 GMT): dave.enyeart (Fri, 03 Nov 2017 10:34:04 GMT): niteshsolanki (Fri, 03 Nov 2017 10:35:28 GMT): minollo (Fri, 03 Nov 2017 12:25:01 GMT): manish-sethi (Fri, 03 Nov 2017 13:16:04 GMT): minollo (Fri, 03 Nov 2017 13:16:48 GMT): manish-sethi (Fri, 03 Nov 2017 13:18:19 GMT): manish-sethi (Fri, 03 Nov 2017 13:19:14 GMT): minollo (Fri, 03 Nov 2017 13:20:42 GMT): minollo (Fri, 03 Nov 2017 13:20:42 GMT): minollo (Fri, 03 Nov 2017 13:20:42 GMT): manish-sethi (Fri, 03 Nov 2017 13:22:47 GMT): minollo (Fri, 03 Nov 2017 13:24:57 GMT): manish-sethi (Fri, 03 Nov 2017 13:26:30 GMT): bennettneale (Fri, 03 Nov 2017 16:24:10 GMT): bh4rtp (Sat, 04 Nov 2017 00:25:33 GMT): bh4rtp (Sat, 04 Nov 2017 00:25:33 GMT): falix (Sat, 04 Nov 2017 02:13:44 GMT): Luke_Chen (Mon, 06 Nov 2017 03:31:06 GMT): hasegawa (Mon, 06 Nov 2017 09:58:09 GMT): swapnilpatil (Wed, 08 Nov 2017 16:07:05 GMT): shiyj93 (Thu, 09 Nov 2017 12:03:42 GMT): rajasekharpippalla (Thu, 09 Nov 2017 12:20:10 GMT): rajasekharpippalla (Thu, 09 Nov 2017 12:20:59 GMT): rajasekharpippalla (Thu, 09 Nov 2017 12:21:10 GMT): rajasekharpippalla (Thu, 09 Nov 2017 12:21:28 GMT): kostas (Thu, 09 Nov 2017 12:44:10 GMT): dave.enyeart (Thu, 09 Nov 2017 13:35:49 GMT): rajasekharpippalla (Thu, 09 Nov 2017 13:36:54 GMT): dave.enyeart (Thu, 09 Nov 2017 13:59:32 GMT): dave.enyeart (Thu, 09 Nov 2017 13:59:32 GMT): qizhang (Thu, 09 Nov 2017 14:01:00 GMT): mtxset (Thu, 09 Nov 2017 15:07:46 GMT): C0rWin (Thu, 09 Nov 2017 19:59:25 GMT): C0rWin (Thu, 09 Nov 2017 20:00:14 GMT): C0rWin (Thu, 09 Nov 2017 20:00:49 GMT): qizhang (Thu, 09 Nov 2017 20:01:04 GMT): jskaqua (Thu, 09 Nov 2017 21:32:53 GMT): qizhang (Thu, 09 Nov 2017 21:35:29 GMT): qizhang (Thu, 09 Nov 2017 21:35:29 GMT): yoheiueda (Fri, 10 Nov 2017 08:12:01 GMT): C0rWin (Fri, 10 Nov 2017 16:47:01 GMT): rojanjose (Mon, 13 Nov 2017 04:09:46 GMT): rajasekharpippalla (Tue, 14 Nov 2017 05:41:53 GMT): rajasekharpippalla (Tue, 14 Nov 2017 05:53:36 GMT): C0rWin (Tue, 14 Nov 2017 07:36:17 GMT): qizhang (Tue, 14 Nov 2017 16:52:37 GMT): qizhang (Tue, 14 Nov 2017 16:52:37 GMT): qizhang (Tue, 14 Nov 2017 16:52:37 GMT): manish-sethi (Tue, 14 Nov 2017 18:55:51 GMT): bh4rtp (Tue, 14 Nov 2017 22:59:13 GMT): niteshsolanki (Wed, 15 Nov 2017 06:28:12 GMT): niteshsolanki (Wed, 15 Nov 2017 06:28:12 GMT): asaningmaxchain (Wed, 15 Nov 2017 07:20:54 GMT): asaningmaxchain (Wed, 15 Nov 2017 07:22:18 GMT): yacovm (Wed, 15 Nov 2017 09:34:07 GMT): yacovm (Wed, 15 Nov 2017 09:34:07 GMT): adc (Wed, 15 Nov 2017 09:34:08 GMT): shubhamvrkr (Wed, 15 Nov 2017 09:56:27 GMT): dave.enyeart (Wed, 15 Nov 2017 11:58:35 GMT): dave.enyeart (Wed, 15 Nov 2017 11:59:06 GMT): yacovm (Wed, 15 Nov 2017 12:17:00 GMT): yacovm (Wed, 15 Nov 2017 12:17:13 GMT): yacovm (Wed, 15 Nov 2017 12:18:23 GMT): rajasekharpippalla (Wed, 15 Nov 2017 12:55:24 GMT): minollo (Wed, 15 Nov 2017 16:38:10 GMT): dave.enyeart (Wed, 15 Nov 2017 16:46:02 GMT): minollo (Wed, 15 Nov 2017 16:46:55 GMT): yunxi.zhang (Thu, 16 Nov 2017 15:24:29 GMT): yunxi.zhang (Thu, 16 Nov 2017 15:25:18 GMT): yunxi.zhang (Thu, 16 Nov 2017 16:23:32 GMT): dave.enyeart (Thu, 16 Nov 2017 22:12:54 GMT): yunxi.zhang (Thu, 16 Nov 2017 22:12:54 GMT): laroque (Fri, 17 Nov 2017 01:20:26 GMT): qizhang (Fri, 17 Nov 2017 03:48:00 GMT): qizhang (Fri, 17 Nov 2017 03:48:00 GMT): qizhang (Fri, 17 Nov 2017 03:49:33 GMT): yunxi.zhang (Fri, 17 Nov 2017 09:27:15 GMT): yunxi.zhang (Fri, 17 Nov 2017 09:27:43 GMT): jarvis26 (Mon, 20 Nov 2017 12:01:10 GMT): jarvis26 (Mon, 20 Nov 2017 12:01:32 GMT): jarvis26 (Mon, 20 Nov 2017 12:01:41 GMT): jarvis26 (Mon, 20 Nov 2017 12:01:52 GMT): jarvis26 (Mon, 20 Nov 2017 12:01:52 GMT): jarvis26 (Mon, 20 Nov 2017 12:01:52 GMT): jarvis26 (Mon, 20 Nov 2017 12:15:47 GMT): C0rWin (Mon, 20 Nov 2017 12:18:18 GMT): jarvis26 (Mon, 20 Nov 2017 12:18:49 GMT): C0rWin (Mon, 20 Nov 2017 12:19:28 GMT): jarvis26 (Mon, 20 Nov 2017 12:19:32 GMT): C0rWin (Mon, 20 Nov 2017 12:20:04 GMT): jarvis26 (Mon, 20 Nov 2017 12:20:11 GMT): yacovm (Mon, 20 Nov 2017 12:20:17 GMT): yacovm (Mon, 20 Nov 2017 12:20:24 GMT): jarvis26 (Mon, 20 Nov 2017 12:20:31 GMT): C0rWin (Mon, 20 Nov 2017 12:22:25 GMT): C0rWin (Mon, 20 Nov 2017 12:22:37 GMT): jarvis26 (Mon, 20 Nov 2017 12:23:10 GMT): jarvis26 (Mon, 20 Nov 2017 12:24:24 GMT): yacovm (Mon, 20 Nov 2017 12:24:41 GMT): yacovm (Mon, 20 Nov 2017 12:24:48 GMT): yacovm (Mon, 20 Nov 2017 12:24:52 GMT): yacovm (Mon, 20 Nov 2017 12:24:54 GMT): yacovm (Mon, 20 Nov 2017 12:24:59 GMT): jarvis26 (Mon, 20 Nov 2017 12:25:03 GMT): yacovm (Mon, 20 Nov 2017 12:25:21 GMT): jarvis26 (Mon, 20 Nov 2017 12:25:29 GMT): yacovm (Mon, 20 Nov 2017 12:25:31 GMT): jarvis26 (Mon, 20 Nov 2017 12:28:19 GMT): yacovm (Mon, 20 Nov 2017 12:29:12 GMT): yacovm (Mon, 20 Nov 2017 12:29:16 GMT): yacovm (Mon, 20 Nov 2017 12:29:19 GMT): jarvis26 (Mon, 20 Nov 2017 12:29:53 GMT): yacovm (Mon, 20 Nov 2017 12:31:00 GMT): yacovm (Mon, 20 Nov 2017 12:31:04 GMT): yacovm (Mon, 20 Nov 2017 12:31:09 GMT): jarvis26 (Mon, 20 Nov 2017 12:31:19 GMT): jarvis26 (Mon, 20 Nov 2017 12:31:39 GMT): yacovm (Mon, 20 Nov 2017 12:32:00 GMT): yacovm (Mon, 20 Nov 2017 12:32:36 GMT): yacovm (Mon, 20 Nov 2017 12:33:01 GMT): jarvis26 (Mon, 20 Nov 2017 12:35:12 GMT): dave.enyeart (Mon, 20 Nov 2017 12:38:59 GMT): dave.enyeart (Mon, 20 Nov 2017 12:39:07 GMT): dave.enyeart (Mon, 20 Nov 2017 12:40:20 GMT): jarvis26 (Mon, 20 Nov 2017 12:47:59 GMT): yacovm (Mon, 20 Nov 2017 12:48:18 GMT): jarvis26 (Mon, 20 Nov 2017 12:49:58 GMT): jarvis26 (Mon, 20 Nov 2017 12:50:08 GMT): yacovm (Mon, 20 Nov 2017 12:51:18 GMT): dave.enyeart (Mon, 20 Nov 2017 12:53:00 GMT): dave.enyeart (Mon, 20 Nov 2017 12:53:20 GMT): jarvis26 (Mon, 20 Nov 2017 13:02:48 GMT): jarvis26 (Mon, 20 Nov 2017 13:03:06 GMT): hpurmann (Mon, 20 Nov 2017 15:34:39 GMT): MadhavaReddy (Tue, 21 Nov 2017 20:16:23 GMT): MadhavaReddy (Tue, 21 Nov 2017 20:17:27 GMT): MadhavaReddy (Wed, 22 Nov 2017 03:24:40 GMT): levinkwong (Wed, 22 Nov 2017 03:42:23 GMT): asamk (Wed, 22 Nov 2017 15:48:31 GMT): dave.enyeart (Wed, 22 Nov 2017 18:21:46 GMT): dave.enyeart (Wed, 22 Nov 2017 18:22:35 GMT): dave.enyeart (Wed, 22 Nov 2017 18:22:35 GMT): MadhavaReddy (Wed, 22 Nov 2017 18:24:03 GMT): MadhavaReddy (Wed, 22 Nov 2017 18:29:37 GMT): dave.enyeart (Wed, 22 Nov 2017 18:58:42 GMT): MadhavaReddy (Wed, 22 Nov 2017 18:59:37 GMT): BasanthVerma (Thu, 23 Nov 2017 10:36:34 GMT): jackeyliliang (Fri, 24 Nov 2017 02:59:26 GMT): hpurmann (Fri, 24 Nov 2017 15:10:03 GMT): hpurmann (Fri, 24 Nov 2017 15:10:03 GMT): hpurmann (Fri, 24 Nov 2017 15:11:32 GMT): Vadim (Fri, 24 Nov 2017 15:16:02 GMT): hpurmann (Fri, 24 Nov 2017 15:16:34 GMT): muasif80 (Tue, 28 Nov 2017 03:20:01 GMT): qizhang (Tue, 28 Nov 2017 20:53:56 GMT): qizhang (Tue, 28 Nov 2017 20:53:56 GMT): qizhang (Tue, 28 Nov 2017 20:53:56 GMT): egeek (Wed, 29 Nov 2017 11:16:31 GMT): Gulsharnsingh (Wed, 29 Nov 2017 14:09:13 GMT): Gulsharnsingh (Wed, 29 Nov 2017 14:10:27 GMT): dave.enyeart (Wed, 29 Nov 2017 15:27:07 GMT): rahulhegde (Wed, 29 Nov 2017 16:15:11 GMT): dave.enyeart (Wed, 29 Nov 2017 16:23:45 GMT): rahulhegde (Wed, 29 Nov 2017 16:36:56 GMT): rahulhegde (Wed, 29 Nov 2017 16:36:56 GMT): rahulhegde (Wed, 29 Nov 2017 16:37:45 GMT): rahulhegde (Wed, 29 Nov 2017 16:38:30 GMT): dave.enyeart (Wed, 29 Nov 2017 16:41:59 GMT): rahulhegde (Wed, 29 Nov 2017 16:42:56 GMT): dave.enyeart (Wed, 29 Nov 2017 16:43:53 GMT): rahulhegde (Wed, 29 Nov 2017 16:45:17 GMT): rahulhegde (Wed, 29 Nov 2017 16:45:31 GMT): rahulhegde (Wed, 29 Nov 2017 16:45:31 GMT): dave.enyeart (Wed, 29 Nov 2017 16:46:29 GMT): rahulhegde (Wed, 29 Nov 2017 16:58:41 GMT): rahulhegde (Wed, 29 Nov 2017 17:00:24 GMT): rahulhegde (Wed, 29 Nov 2017 17:01:20 GMT): dave.enyeart (Wed, 29 Nov 2017 17:22:34 GMT): dave.enyeart (Wed, 29 Nov 2017 17:23:19 GMT): rahulhegde (Wed, 29 Nov 2017 18:59:32 GMT): rahulhegde (Wed, 29 Nov 2017 18:59:32 GMT): rahulhegde (Wed, 29 Nov 2017 20:39:30 GMT): qizhang (Wed, 29 Nov 2017 22:47:27 GMT): Russell-Columbia (Wed, 29 Nov 2017 22:59:31 GMT): waaagh (Thu, 30 Nov 2017 00:52:26 GMT): ArnabChatterjee (Thu, 30 Nov 2017 14:17:49 GMT): Vlore (Sat, 02 Dec 2017 14:02:42 GMT): SanjivBhatia (Sun, 03 Dec 2017 14:02:13 GMT): alvaradojl (Sun, 03 Dec 2017 18:53:19 GMT): gauthampamu (Mon, 04 Dec 2017 09:54:49 GMT): dave.enyeart (Mon, 04 Dec 2017 12:11:34 GMT): dave.enyeart (Mon, 04 Dec 2017 12:12:57 GMT): jrosmith (Mon, 04 Dec 2017 19:09:35 GMT): jrosmith (Mon, 04 Dec 2017 19:10:11 GMT): jrosmith (Mon, 04 Dec 2017 20:01:41 GMT): dave.enyeart (Tue, 05 Dec 2017 11:39:58 GMT): dave.enyeart (Tue, 05 Dec 2017 11:40:35 GMT): jrosmith (Tue, 05 Dec 2017 14:47:31 GMT): jrosmith (Tue, 05 Dec 2017 15:28:41 GMT): dave.enyeart (Tue, 05 Dec 2017 15:50:09 GMT): minollo (Tue, 05 Dec 2017 18:11:27 GMT): dave.enyeart (Tue, 05 Dec 2017 18:24:12 GMT): dave.enyeart (Tue, 05 Dec 2017 18:24:12 GMT): dave.enyeart (Tue, 05 Dec 2017 18:24:14 GMT): minollo (Tue, 05 Dec 2017 18:30:01 GMT): dave.enyeart (Tue, 05 Dec 2017 18:32:08 GMT): dave.enyeart (Tue, 05 Dec 2017 18:32:08 GMT): muasif80 (Wed, 06 Dec 2017 12:21:17 GMT): Vadim (Wed, 06 Dec 2017 12:21:57 GMT): Vadim (Wed, 06 Dec 2017 12:21:57 GMT): MohammadObaid (Wed, 06 Dec 2017 17:52:28 GMT): muasif80 (Thu, 07 Dec 2017 10:55:42 GMT): naveenv (Fri, 08 Dec 2017 05:09:33 GMT): jrosmith (Fri, 08 Dec 2017 15:04:54 GMT): Vadim (Fri, 08 Dec 2017 15:23:44 GMT): jrosmith (Fri, 08 Dec 2017 15:25:17 GMT): Vadim (Fri, 08 Dec 2017 15:25:53 GMT): Vadim (Fri, 08 Dec 2017 15:25:53 GMT): jrosmith (Fri, 08 Dec 2017 15:26:06 GMT): dave.enyeart (Fri, 08 Dec 2017 16:55:49 GMT): gdinhof (Fri, 08 Dec 2017 17:02:28 GMT): jrosmith (Fri, 08 Dec 2017 17:33:18 GMT): muasif80 (Fri, 08 Dec 2017 21:48:31 GMT): muasif80 (Fri, 08 Dec 2017 21:50:56 GMT): eclairamb (Fri, 08 Dec 2017 22:30:11 GMT): silliman (Fri, 08 Dec 2017 22:32:55 GMT): muasif80 (Sat, 09 Dec 2017 05:31:46 GMT): elie (Mon, 11 Dec 2017 10:42:54 GMT): alexandra_g (Mon, 11 Dec 2017 18:29:13 GMT): guolidong (Tue, 12 Dec 2017 05:59:14 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 09:33:51 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 09:33:51 GMT): Vadim (Tue, 12 Dec 2017 09:34:15 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 09:36:28 GMT): Vadim (Tue, 12 Dec 2017 09:37:17 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 09:37:42 GMT): Vadim (Tue, 12 Dec 2017 09:38:22 GMT): Vadim (Tue, 12 Dec 2017 09:38:22 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 09:39:43 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 10:02:34 GMT): Vadim (Tue, 12 Dec 2017 10:03:25 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 10:10:18 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 10:10:18 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 10:10:18 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 10:10:18 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 10:25:38 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 10:26:35 GMT): Vadim (Tue, 12 Dec 2017 10:28:00 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 11:32:55 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 11:32:55 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 11:32:55 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 11:32:55 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 11:32:55 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 11:32:55 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 11:32:55 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 11:32:55 GMT): Vadim (Tue, 12 Dec 2017 11:49:14 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 12:27:18 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 12:27:18 GMT): Vadim (Tue, 12 Dec 2017 12:27:59 GMT): Vadim (Tue, 12 Dec 2017 12:28:21 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 12:30:28 GMT): Vadim (Tue, 12 Dec 2017 12:31:01 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 12:31:58 GMT): Vadim (Tue, 12 Dec 2017 12:35:39 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 12:37:03 GMT): Vadim (Tue, 12 Dec 2017 12:37:35 GMT): SyneBlockChainTeam (Tue, 12 Dec 2017 12:59:30 GMT): Vadim (Tue, 12 Dec 2017 13:04:23 GMT): Vadim (Tue, 12 Dec 2017 13:04:23 GMT): Vadim (Tue, 12 Dec 2017 13:19:58 GMT): PetrVlasekCA (Tue, 12 Dec 2017 16:50:06 GMT): frankz (Wed, 13 Dec 2017 12:37:51 GMT): Khaled.MH (Wed, 13 Dec 2017 14:57:41 GMT): bruteforced (Sun, 17 Dec 2017 14:59:15 GMT): qingsongGuo (Tue, 19 Dec 2017 02:46:19 GMT): jon_s (Tue, 19 Dec 2017 04:54:48 GMT): zhishui (Tue, 19 Dec 2017 08:11:10 GMT): ArnabChatterjee (Tue, 19 Dec 2017 11:06:20 GMT): ArnabChatterjee (Tue, 19 Dec 2017 11:06:20 GMT): ArnabChatterjee (Tue, 19 Dec 2017 11:06:20 GMT): tennenjl (Tue, 19 Dec 2017 17:58:40 GMT): dave.enyeart (Tue, 19 Dec 2017 18:01:37 GMT): tennenjl (Tue, 19 Dec 2017 18:03:41 GMT): dave.enyeart (Tue, 19 Dec 2017 18:04:10 GMT): tennenjl (Tue, 19 Dec 2017 18:05:03 GMT): dave.enyeart (Tue, 19 Dec 2017 18:06:30 GMT): tennenjl (Tue, 19 Dec 2017 18:07:20 GMT): dave.enyeart (Tue, 19 Dec 2017 18:15:09 GMT): tennenjl (Tue, 19 Dec 2017 18:16:41 GMT): dave.enyeart (Tue, 19 Dec 2017 18:17:56 GMT): dave.enyeart (Tue, 19 Dec 2017 18:17:56 GMT): dave.enyeart (Tue, 19 Dec 2017 18:17:56 GMT): dave.enyeart (Tue, 19 Dec 2017 18:17:56 GMT): dave.enyeart (Tue, 19 Dec 2017 18:18:06 GMT): tennenjl (Tue, 19 Dec 2017 18:25:43 GMT): dave.enyeart (Tue, 19 Dec 2017 18:27:11 GMT): dave.enyeart (Tue, 19 Dec 2017 18:27:38 GMT): tennenjl (Tue, 19 Dec 2017 18:29:26 GMT): DRSK (Wed, 20 Dec 2017 04:55:19 GMT): DRSK (Wed, 20 Dec 2017 04:56:16 GMT): Vadim (Wed, 20 Dec 2017 08:22:50 GMT): ynkumar143 (Wed, 20 Dec 2017 08:55:53 GMT): pb (Wed, 20 Dec 2017 10:14:45 GMT): pb (Wed, 20 Dec 2017 10:20:33 GMT): Vadim (Wed, 20 Dec 2017 10:21:11 GMT): pb (Wed, 20 Dec 2017 10:21:25 GMT): pb (Wed, 20 Dec 2017 10:49:35 GMT): pb (Wed, 20 Dec 2017 10:50:55 GMT): Vadim (Wed, 20 Dec 2017 10:51:33 GMT): Vadim (Wed, 20 Dec 2017 10:51:33 GMT): pb (Wed, 20 Dec 2017 10:51:54 GMT): Vadim (Wed, 20 Dec 2017 10:53:12 GMT): DRSK (Wed, 20 Dec 2017 10:59:48 GMT): Vadim (Wed, 20 Dec 2017 11:01:55 GMT): pb (Wed, 20 Dec 2017 11:05:22 GMT): Vadim (Wed, 20 Dec 2017 11:05:43 GMT): pb (Wed, 20 Dec 2017 11:08:30 GMT): dave.enyeart (Wed, 20 Dec 2017 11:37:56 GMT): dave.enyeart (Wed, 20 Dec 2017 11:38:03 GMT): dave.enyeart (Wed, 20 Dec 2017 11:38:07 GMT): dave.enyeart (Wed, 20 Dec 2017 11:38:30 GMT): dave.enyeart (Wed, 20 Dec 2017 11:42:01 GMT): dave.enyeart (Wed, 20 Dec 2017 11:42:24 GMT): DRSK (Wed, 20 Dec 2017 11:52:02 GMT): dave.enyeart (Wed, 20 Dec 2017 11:55:29 GMT): dave.enyeart (Wed, 20 Dec 2017 11:56:29 GMT): DRSK (Wed, 20 Dec 2017 12:06:45 GMT): DRSK (Wed, 20 Dec 2017 12:06:45 GMT): dave.enyeart (Wed, 20 Dec 2017 12:13:00 GMT): MR (Wed, 20 Dec 2017 13:26:49 GMT): jrosmith (Wed, 20 Dec 2017 20:32:15 GMT): dave.enyeart (Wed, 20 Dec 2017 22:06:07 GMT): muralisr (Wed, 20 Dec 2017 22:08:44 GMT): yacovm (Wed, 20 Dec 2017 22:09:53 GMT): yacovm (Wed, 20 Dec 2017 22:09:59 GMT): muralisr (Wed, 20 Dec 2017 22:11:35 GMT): muralisr (Wed, 20 Dec 2017 22:11:41 GMT): yacovm (Wed, 20 Dec 2017 22:11:48 GMT): yacovm (Wed, 20 Dec 2017 22:11:59 GMT): C0rWin (Wed, 20 Dec 2017 22:12:05 GMT): muralisr (Wed, 20 Dec 2017 22:12:07 GMT): yacovm (Wed, 20 Dec 2017 22:12:10 GMT): C0rWin (Wed, 20 Dec 2017 22:12:14 GMT): yacovm (Wed, 20 Dec 2017 22:12:15 GMT): yacovm (Wed, 20 Dec 2017 22:12:25 GMT): muralisr (Wed, 20 Dec 2017 22:12:28 GMT): yacovm (Wed, 20 Dec 2017 22:12:34 GMT): yacovm (Wed, 20 Dec 2017 22:12:37 GMT): C0rWin (Wed, 20 Dec 2017 22:12:43 GMT): muralisr (Wed, 20 Dec 2017 22:12:49 GMT): C0rWin (Wed, 20 Dec 2017 22:12:50 GMT): yacovm (Wed, 20 Dec 2017 22:13:07 GMT): yacovm (Wed, 20 Dec 2017 22:13:12 GMT): C0rWin (Wed, 20 Dec 2017 22:13:47 GMT): yacovm (Wed, 20 Dec 2017 22:13:51 GMT): C0rWin (Wed, 20 Dec 2017 22:14:03 GMT): C0rWin (Wed, 20 Dec 2017 22:14:37 GMT): yacovm (Wed, 20 Dec 2017 22:14:54 GMT): muralisr (Wed, 20 Dec 2017 22:14:57 GMT): yacovm (Wed, 20 Dec 2017 22:15:03 GMT): C0rWin (Wed, 20 Dec 2017 22:15:06 GMT): C0rWin (Wed, 20 Dec 2017 22:15:14 GMT): muralisr (Wed, 20 Dec 2017 22:15:15 GMT): muralisr (Wed, 20 Dec 2017 22:16:04 GMT): muralisr (Wed, 20 Dec 2017 22:16:18 GMT): yacovm (Wed, 20 Dec 2017 22:16:21 GMT): muralisr (Wed, 20 Dec 2017 22:16:25 GMT): muralisr (Wed, 20 Dec 2017 22:16:44 GMT): yacovm (Wed, 20 Dec 2017 22:16:48 GMT): muralisr (Wed, 20 Dec 2017 22:17:08 GMT): yacovm (Wed, 20 Dec 2017 22:17:31 GMT): muralisr (Wed, 20 Dec 2017 22:17:40 GMT): C0rWin (Wed, 20 Dec 2017 22:18:34 GMT): yacovm (Wed, 20 Dec 2017 22:18:42 GMT): muralisr (Wed, 20 Dec 2017 22:18:46 GMT): muralisr (Wed, 20 Dec 2017 22:18:56 GMT): yacovm (Wed, 20 Dec 2017 22:19:01 GMT): C0rWin (Wed, 20 Dec 2017 22:19:02 GMT): C0rWin (Wed, 20 Dec 2017 22:19:22 GMT): muralisr (Wed, 20 Dec 2017 22:19:23 GMT): yacovm (Wed, 20 Dec 2017 22:20:31 GMT): yacovm (Wed, 20 Dec 2017 22:20:40 GMT): yacovm (Wed, 20 Dec 2017 22:20:56 GMT): yacovm (Wed, 20 Dec 2017 22:21:05 GMT): yacovm (Wed, 20 Dec 2017 22:21:19 GMT): muralisr (Wed, 20 Dec 2017 22:21:39 GMT): muralisr (Wed, 20 Dec 2017 22:21:43 GMT): C0rWin (Wed, 20 Dec 2017 22:21:53 GMT): C0rWin (Wed, 20 Dec 2017 22:21:59 GMT): muralisr (Wed, 20 Dec 2017 22:21:59 GMT): yacovm (Wed, 20 Dec 2017 22:22:01 GMT): yacovm (Wed, 20 Dec 2017 22:22:05 GMT): muralisr (Wed, 20 Dec 2017 22:22:10 GMT): yacovm (Wed, 20 Dec 2017 22:22:11 GMT): muralisr (Wed, 20 Dec 2017 22:24:05 GMT): muralisr (Wed, 20 Dec 2017 22:24:20 GMT): muralisr (Wed, 20 Dec 2017 22:24:28 GMT): yacovm (Wed, 20 Dec 2017 22:24:58 GMT): yacovm (Wed, 20 Dec 2017 22:25:04 GMT): yacovm (Wed, 20 Dec 2017 22:25:14 GMT): muralisr (Wed, 20 Dec 2017 22:25:50 GMT): C0rWin (Wed, 20 Dec 2017 22:26:30 GMT): C0rWin (Wed, 20 Dec 2017 22:26:43 GMT): muralisr (Wed, 20 Dec 2017 22:26:48 GMT): muralisr (Wed, 20 Dec 2017 22:27:18 GMT): muralisr (Wed, 20 Dec 2017 22:28:21 GMT): C0rWin (Wed, 20 Dec 2017 22:31:29 GMT): C0rWin (Wed, 20 Dec 2017 22:31:36 GMT): yacovm (Wed, 20 Dec 2017 22:31:41 GMT): C0rWin (Wed, 20 Dec 2017 22:31:49 GMT): ArnabChatterjee (Mon, 25 Dec 2017 06:17:59 GMT): Cavan2477 (Tue, 26 Dec 2017 01:58:24 GMT): jrosmith (Tue, 26 Dec 2017 13:54:44 GMT): yacovm (Tue, 26 Dec 2017 13:55:24 GMT): jrosmith (Tue, 26 Dec 2017 14:04:14 GMT): yacovm (Tue, 26 Dec 2017 14:04:46 GMT): jrosmith (Tue, 26 Dec 2017 14:15:58 GMT): jrosmith (Tue, 26 Dec 2017 14:17:17 GMT): yacovm (Tue, 26 Dec 2017 14:19:26 GMT): yacovm (Tue, 26 Dec 2017 14:19:50 GMT): yacovm (Tue, 26 Dec 2017 14:20:14 GMT): yacovm (Tue, 26 Dec 2017 14:20:18 GMT): yacovm (Tue, 26 Dec 2017 14:20:25 GMT): yacovm (Tue, 26 Dec 2017 14:20:35 GMT): muralisr (Tue, 26 Dec 2017 15:08:16 GMT): jrosmith (Tue, 26 Dec 2017 15:12:32 GMT): jrosmith (Tue, 26 Dec 2017 15:12:32 GMT): yacovm (Tue, 26 Dec 2017 15:13:07 GMT): yacovm (Tue, 26 Dec 2017 15:13:13 GMT): jrosmith (Tue, 26 Dec 2017 15:21:41 GMT): yacovm (Tue, 26 Dec 2017 15:23:50 GMT): jrosmith (Tue, 26 Dec 2017 15:28:55 GMT): yacovm (Tue, 26 Dec 2017 15:45:27 GMT): muralisr (Tue, 26 Dec 2017 15:50:18 GMT): muralisr (Tue, 26 Dec 2017 15:52:44 GMT): jrosmith (Tue, 26 Dec 2017 15:54:03 GMT): jrosmith (Tue, 26 Dec 2017 15:54:03 GMT): DannyWong (Wed, 27 Dec 2017 02:17:37 GMT): pb (Wed, 27 Dec 2017 06:16:17 GMT): varuna82 (Wed, 27 Dec 2017 10:26:50 GMT): dave.enyeart (Wed, 27 Dec 2017 13:13:49 GMT): pb (Thu, 28 Dec 2017 03:43:44 GMT): pb (Thu, 28 Dec 2017 10:27:52 GMT): dave.enyeart (Thu, 28 Dec 2017 13:49:01 GMT): dave.enyeart (Thu, 28 Dec 2017 13:51:29 GMT): dave.enyeart (Thu, 28 Dec 2017 13:51:29 GMT): pb (Fri, 29 Dec 2017 04:20:06 GMT): pb (Fri, 29 Dec 2017 06:43:18 GMT): dave.enyeart (Fri, 29 Dec 2017 15:22:41 GMT): dave.enyeart (Fri, 29 Dec 2017 15:23:50 GMT): elias_p (Tue, 02 Jan 2018 22:57:44 GMT): songyuanjie (Wed, 03 Jan 2018 00:31:43 GMT): dijun (Wed, 03 Jan 2018 01:53:00 GMT): pb (Wed, 03 Jan 2018 03:07:52 GMT): pb (Wed, 03 Jan 2018 03:08:31 GMT): songyuanjie (Wed, 03 Jan 2018 06:04:49 GMT): songyuanjie (Wed, 03 Jan 2018 06:05:09 GMT): DRSK (Wed, 03 Jan 2018 11:56:09 GMT): yacovm (Wed, 03 Jan 2018 12:04:37 GMT): gurel (Wed, 03 Jan 2018 17:44:19 GMT): voutasaurus (Thu, 04 Jan 2018 03:43:58 GMT): DRSK (Thu, 04 Jan 2018 09:27:55 GMT): DRSK (Thu, 04 Jan 2018 09:27:55 GMT): DRSK (Thu, 04 Jan 2018 09:28:35 GMT): guoger (Thu, 04 Jan 2018 09:38:10 GMT): C0rWin (Thu, 04 Jan 2018 09:38:14 GMT): C0rWin (Thu, 04 Jan 2018 09:40:21 GMT): pb (Thu, 04 Jan 2018 09:40:26 GMT): DRSK (Thu, 04 Jan 2018 09:44:49 GMT): DRSK (Thu, 04 Jan 2018 09:59:17 GMT): allonblocks21 (Thu, 04 Jan 2018 11:09:19 GMT): asaningmaxchain (Thu, 04 Jan 2018 13:25:34 GMT): asaningmaxchain (Thu, 04 Jan 2018 13:25:37 GMT): niteshsolanki (Fri, 05 Jan 2018 12:50:24 GMT): dave.enyeart (Fri, 05 Jan 2018 12:50:47 GMT): niteshsolanki (Fri, 05 Jan 2018 12:51:07 GMT): dave.enyeart (Fri, 05 Jan 2018 12:51:19 GMT): niteshsolanki (Fri, 05 Jan 2018 12:52:25 GMT): dave.enyeart (Fri, 05 Jan 2018 12:57:11 GMT): niteshsolanki (Fri, 05 Jan 2018 13:00:40 GMT): dave.enyeart (Fri, 05 Jan 2018 13:02:48 GMT): niteshsolanki (Fri, 05 Jan 2018 13:03:12 GMT): asaningmaxchain (Mon, 08 Jan 2018 15:29:35 GMT): asaningmaxchain (Mon, 08 Jan 2018 15:29:35 GMT): asaningmaxchain (Mon, 08 Jan 2018 15:29:35 GMT): asaningmaxchain (Mon, 08 Jan 2018 15:29:35 GMT): dave.enyeart (Mon, 08 Jan 2018 16:15:45 GMT): asaningmaxchain (Mon, 08 Jan 2018 16:16:45 GMT): dave.enyeart (Mon, 08 Jan 2018 16:17:27 GMT): asaningmaxchain (Mon, 08 Jan 2018 16:33:26 GMT): asaningmaxchain (Mon, 08 Jan 2018 16:33:39 GMT): dave.enyeart (Mon, 08 Jan 2018 16:37:52 GMT): dave.enyeart (Mon, 08 Jan 2018 16:37:52 GMT): ArnabChatterjee (Tue, 09 Jan 2018 02:57:32 GMT): ArnabChatterjee (Tue, 09 Jan 2018 02:57:32 GMT): SjirNijssen (Tue, 09 Jan 2018 13:37:04 GMT): cchalc (Tue, 09 Jan 2018 20:45:14 GMT): luomin (Wed, 10 Jan 2018 09:14:22 GMT): singh.amitkumar (Thu, 11 Jan 2018 17:37:49 GMT): asaningmaxchain (Fri, 12 Jan 2018 14:39:12 GMT): manish-sethi (Fri, 12 Jan 2018 15:01:23 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:03:09 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:03:38 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:03:38 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:04:32 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:04:32 GMT): manish-sethi (Fri, 12 Jan 2018 15:06:15 GMT): manish-sethi (Fri, 12 Jan 2018 15:06:25 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:07:02 GMT): manish-sethi (Fri, 12 Jan 2018 15:07:49 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:08:11 GMT): manish-sethi (Fri, 12 Jan 2018 15:08:47 GMT): manish-sethi (Fri, 12 Jan 2018 15:09:29 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:09:35 GMT): manish-sethi (Fri, 12 Jan 2018 15:09:44 GMT): manish-sethi (Fri, 12 Jan 2018 15:09:52 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:12:37 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:12:37 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:12:42 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:13:17 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:13:17 GMT): manish-sethi (Fri, 12 Jan 2018 15:14:47 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:16:16 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:16:54 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:17:10 GMT): manish-sethi (Fri, 12 Jan 2018 15:18:40 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:19:52 GMT): manish-sethi (Fri, 12 Jan 2018 15:22:35 GMT): manish-sethi (Fri, 12 Jan 2018 15:22:35 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:34:34 GMT): asaningmaxchain (Fri, 12 Jan 2018 15:38:55 GMT): manish-sethi (Fri, 12 Jan 2018 15:53:39 GMT): manish-sethi (Fri, 12 Jan 2018 15:54:35 GMT): asaningmaxchain (Fri, 12 Jan 2018 16:00:10 GMT): manish-sethi (Fri, 12 Jan 2018 16:03:36 GMT): manish-sethi (Fri, 12 Jan 2018 16:04:16 GMT): asaningmaxchain (Fri, 12 Jan 2018 16:22:54 GMT): asaningmaxchain (Fri, 12 Jan 2018 16:22:54 GMT): asaningmaxchain (Fri, 12 Jan 2018 16:22:54 GMT): asaningmaxchain (Fri, 12 Jan 2018 16:22:54 GMT): asaningmaxchain (Fri, 12 Jan 2018 16:24:30 GMT): manish-sethi (Fri, 12 Jan 2018 16:24:48 GMT): asaningmaxchain (Fri, 12 Jan 2018 16:27:08 GMT): asaningmaxchain (Fri, 12 Jan 2018 16:27:08 GMT): asaningmaxchain (Fri, 12 Jan 2018 16:27:08 GMT): manish-sethi (Fri, 12 Jan 2018 17:04:20 GMT): manish-sethi (Fri, 12 Jan 2018 17:04:48 GMT): manish-sethi (Fri, 12 Jan 2018 17:05:08 GMT): manish-sethi (Fri, 12 Jan 2018 17:06:05 GMT): asaningmaxchain (Fri, 12 Jan 2018 17:15:10 GMT): manish-sethi (Fri, 12 Jan 2018 17:19:50 GMT): asaningmaxchain (Fri, 12 Jan 2018 17:21:05 GMT): asaningmaxchain (Fri, 12 Jan 2018 17:21:05 GMT): asaningmaxchain (Fri, 12 Jan 2018 17:21:05 GMT): bjwswang (Mon, 15 Jan 2018 07:56:22 GMT): udaykhambadkone (Mon, 15 Jan 2018 14:50:48 GMT): jdockter (Mon, 15 Jan 2018 14:59:46 GMT): udaykhambadkone (Mon, 15 Jan 2018 15:59:04 GMT): dave.enyeart (Tue, 16 Jan 2018 12:24:55 GMT): dave.enyeart (Tue, 16 Jan 2018 12:25:37 GMT): dave.enyeart (Tue, 16 Jan 2018 12:26:07 GMT): dave.enyeart (Tue, 16 Jan 2018 12:26:39 GMT): dave.enyeart (Tue, 16 Jan 2018 12:29:36 GMT): udaykhambadkone (Tue, 16 Jan 2018 14:10:00 GMT): udaykhambadkone (Tue, 16 Jan 2018 14:13:54 GMT): dave.enyeart (Tue, 16 Jan 2018 14:14:41 GMT): jdockter (Tue, 16 Jan 2018 14:21:21 GMT): asaningmaxchain (Tue, 16 Jan 2018 14:43:31 GMT): asaningmaxchain (Tue, 16 Jan 2018 14:43:31 GMT): niteshsolanki (Tue, 16 Jan 2018 15:02:28 GMT): niteshsolanki (Tue, 16 Jan 2018 15:02:28 GMT): udaykhambadkone (Tue, 16 Jan 2018 15:13:51 GMT): asaningmaxchain (Tue, 16 Jan 2018 15:14:26 GMT): dave.enyeart (Tue, 16 Jan 2018 15:32:58 GMT): niteshsolanki (Tue, 16 Jan 2018 15:37:29 GMT): asaningmaxchain (Tue, 16 Jan 2018 15:47:26 GMT): asaningmaxchain (Tue, 16 Jan 2018 15:48:10 GMT): asaningmaxchain (Tue, 16 Jan 2018 15:49:00 GMT): asaningmaxchain (Tue, 16 Jan 2018 15:50:09 GMT): bingimanasa (Wed, 17 Jan 2018 10:38:52 GMT): bingimanasa (Wed, 17 Jan 2018 10:39:47 GMT): Devender_Singh (Thu, 18 Jan 2018 05:12:38 GMT): jks3462 (Thu, 18 Jan 2018 11:32:25 GMT): udaykhambadkone (Thu, 18 Jan 2018 14:43:14 GMT): udaykhambadkone (Thu, 18 Jan 2018 14:43:14 GMT): udaykhambadkone (Thu, 18 Jan 2018 14:53:41 GMT): qizhang (Thu, 18 Jan 2018 21:33:13 GMT): qizhang (Thu, 18 Jan 2018 21:33:13 GMT): mogamboizer (Thu, 18 Jan 2018 21:37:28 GMT): yacovm (Thu, 18 Jan 2018 22:47:05 GMT): qizhang (Fri, 19 Jan 2018 00:20:11 GMT): asaningmaxchain (Fri, 19 Jan 2018 01:45:43 GMT): bingimanasa (Fri, 19 Jan 2018 04:23:02 GMT): asaningmaxchain (Fri, 19 Jan 2018 07:46:27 GMT): yacovm (Fri, 19 Jan 2018 08:05:07 GMT): dave.enyeart (Fri, 19 Jan 2018 12:39:28 GMT): dave.enyeart (Fri, 19 Jan 2018 12:40:18 GMT): dave.enyeart (Fri, 19 Jan 2018 12:42:32 GMT): dave.enyeart (Fri, 19 Jan 2018 12:43:03 GMT): asaningmaxchain (Fri, 19 Jan 2018 12:43:42 GMT): asaningmaxchain (Fri, 19 Jan 2018 12:43:42 GMT): udaykhambadkone (Fri, 19 Jan 2018 14:39:01 GMT): Brucepark (Sat, 20 Jan 2018 06:15:11 GMT): MartinStepien (Sat, 20 Jan 2018 18:56:16 GMT): IngoRammer (Sun, 21 Jan 2018 09:08:08 GMT): toddinpal (Sun, 21 Jan 2018 14:08:15 GMT): yacovm (Sun, 21 Jan 2018 14:56:27 GMT): Devender_Singh (Mon, 22 Jan 2018 15:56:42 GMT): kapilAtrey (Tue, 23 Jan 2018 05:06:30 GMT): sampath06 (Tue, 23 Jan 2018 14:25:54 GMT): Vadim (Tue, 23 Jan 2018 14:31:57 GMT): sampath06 (Tue, 23 Jan 2018 14:34:05 GMT): dave.enyeart (Tue, 23 Jan 2018 14:39:17 GMT): dave.enyeart (Tue, 23 Jan 2018 14:39:17 GMT): dave.enyeart (Tue, 23 Jan 2018 14:39:17 GMT): asaningmaxchain (Tue, 23 Jan 2018 14:41:03 GMT): asaningmaxchain (Tue, 23 Jan 2018 14:41:03 GMT): asaningmaxchain (Tue, 23 Jan 2018 14:43:10 GMT): sampath06 (Tue, 23 Jan 2018 14:44:32 GMT): Vadim (Tue, 23 Jan 2018 14:46:12 GMT): asaningmaxchain (Tue, 23 Jan 2018 14:51:25 GMT): Vadim (Tue, 23 Jan 2018 15:04:51 GMT): Vadim (Tue, 23 Jan 2018 15:04:51 GMT): asaningmaxchain (Tue, 23 Jan 2018 15:13:07 GMT): asaningmaxchain (Tue, 23 Jan 2018 15:13:07 GMT): asaningmaxchain (Tue, 23 Jan 2018 15:13:07 GMT): StevenXu (Wed, 24 Jan 2018 01:21:05 GMT): bamboo (Wed, 24 Jan 2018 04:23:44 GMT): Ammu (Wed, 24 Jan 2018 11:06:18 GMT): Ammu (Wed, 24 Jan 2018 11:08:05 GMT): bingimanasa (Wed, 24 Jan 2018 12:20:10 GMT): kerokhin (Thu, 25 Jan 2018 21:00:00 GMT): george.skrbic (Thu, 25 Jan 2018 21:24:50 GMT): ArnabChatterjee (Fri, 26 Jan 2018 09:10:41 GMT): manish-sethi (Fri, 26 Jan 2018 15:33:27 GMT): manish-sethi (Fri, 26 Jan 2018 15:35:16 GMT): ArnabChatterjee (Fri, 26 Jan 2018 15:37:58 GMT): manish-sethi (Fri, 26 Jan 2018 15:39:50 GMT): ArnabChatterjee (Fri, 26 Jan 2018 15:46:19 GMT): ArnabChatterjee (Fri, 26 Jan 2018 15:46:19 GMT): ArnabChatterjee (Fri, 26 Jan 2018 15:48:28 GMT): manish-sethi (Fri, 26 Jan 2018 15:50:13 GMT): ArnabChatterjee (Fri, 26 Jan 2018 15:50:23 GMT): manish-sethi (Fri, 26 Jan 2018 15:51:58 GMT): manish-sethi (Fri, 26 Jan 2018 15:53:06 GMT): ArnabChatterjee (Fri, 26 Jan 2018 15:55:44 GMT): manish-sethi (Fri, 26 Jan 2018 16:00:48 GMT): ArnabChatterjee (Fri, 26 Jan 2018 16:09:52 GMT): yacovm (Fri, 26 Jan 2018 16:30:16 GMT): Ammu (Sat, 27 Jan 2018 05:16:09 GMT): ArnabChatterjee (Sat, 27 Jan 2018 10:52:03 GMT): titasp (Sat, 27 Jan 2018 18:25:50 GMT): titasp (Sat, 27 Jan 2018 18:25:54 GMT): Amjadnz (Sun, 28 Jan 2018 16:33:23 GMT): Amjadnz (Sun, 28 Jan 2018 16:33:23 GMT): Amjadnz (Sun, 28 Jan 2018 16:33:52 GMT): Amjadnz (Sun, 28 Jan 2018 16:33:52 GMT): Amjadnz (Sun, 28 Jan 2018 16:33:52 GMT): Amjadnz (Sun, 28 Jan 2018 16:33:52 GMT): Amjadnz (Sun, 28 Jan 2018 16:33:52 GMT): Amjadnz (Sun, 28 Jan 2018 16:33:52 GMT): Amjadnz (Sun, 28 Jan 2018 16:35:01 GMT): Amjadnz (Sun, 28 Jan 2018 16:41:19 GMT): Amjadnz (Sun, 28 Jan 2018 16:42:07 GMT): Amjadnz (Sun, 28 Jan 2018 16:51:51 GMT): Amjadnz (Sun, 28 Jan 2018 16:52:16 GMT): Amjadnz (Sun, 28 Jan 2018 17:03:21 GMT): HarryZhu (Mon, 29 Jan 2018 00:13:33 GMT): fengfengs (Mon, 29 Jan 2018 05:06:24 GMT): jdockter (Mon, 29 Jan 2018 18:00:02 GMT): jdockter (Mon, 29 Jan 2018 18:02:36 GMT): jdockter (Mon, 29 Jan 2018 18:02:36 GMT): nkl199 (Mon, 29 Jan 2018 18:04:19 GMT): HarryZhu (Tue, 30 Jan 2018 05:30:23 GMT): ArnabChatterjee (Tue, 30 Jan 2018 07:51:49 GMT): jrosmith (Tue, 30 Jan 2018 13:57:37 GMT): dave.enyeart (Tue, 30 Jan 2018 15:44:52 GMT): dave.enyeart (Tue, 30 Jan 2018 15:48:20 GMT): dave.enyeart (Tue, 30 Jan 2018 15:50:06 GMT): manish-sethi (Tue, 30 Jan 2018 19:36:28 GMT): manish-sethi (Tue, 30 Jan 2018 19:36:28 GMT): jdockter (Tue, 30 Jan 2018 21:10:57 GMT): HarryZhu (Tue, 30 Jan 2018 21:52:03 GMT): jrosmith (Tue, 30 Jan 2018 22:01:36 GMT): HarryZhu (Tue, 30 Jan 2018 22:05:00 GMT): vchengsong (Thu, 01 Feb 2018 03:49:16 GMT): chandg12 (Thu, 01 Feb 2018 05:53:20 GMT): adarshsaraf123 (Thu, 01 Feb 2018 06:22:38 GMT): jmcnevin (Fri, 02 Feb 2018 19:34:54 GMT): KnightTuring (Sat, 03 Feb 2018 10:35:29 GMT): MohammadObaid (Sun, 04 Feb 2018 18:29:20 GMT): silliman (Sun, 04 Feb 2018 18:39:25 GMT): ajithjosek (Sun, 04 Feb 2018 20:18:19 GMT): MohammadObaid (Mon, 05 Feb 2018 12:51:39 GMT): ahmedsajid (Mon, 05 Feb 2018 16:45:46 GMT): qizhang (Tue, 06 Feb 2018 02:27:21 GMT): qizhang (Tue, 06 Feb 2018 02:27:21 GMT): qizhang (Tue, 06 Feb 2018 02:27:21 GMT): qizhang (Tue, 06 Feb 2018 02:27:21 GMT): qizhang (Tue, 06 Feb 2018 02:27:21 GMT): arunkarri (Tue, 06 Feb 2018 15:38:03 GMT): arunkarri (Tue, 06 Feb 2018 15:38:12 GMT): bamboo (Wed, 07 Feb 2018 03:57:54 GMT): Amir (Wed, 07 Feb 2018 21:38:53 GMT): bburger (Wed, 07 Feb 2018 22:14:49 GMT): PyiTheinKyaw (Thu, 08 Feb 2018 05:17:57 GMT): PyiTheinKyaw (Thu, 08 Feb 2018 05:22:42 GMT): bburger (Thu, 08 Feb 2018 07:07:48 GMT): PyiTheinKyaw (Thu, 08 Feb 2018 08:41:50 GMT): PyiTheinKyaw (Thu, 08 Feb 2018 08:41:50 GMT): dave.enyeart (Thu, 08 Feb 2018 13:19:48 GMT): dave.enyeart (Thu, 08 Feb 2018 13:22:27 GMT): dave.enyeart (Thu, 08 Feb 2018 13:22:30 GMT): Bchainer (Fri, 09 Feb 2018 01:43:18 GMT): malama (Fri, 09 Feb 2018 09:39:01 GMT): malama (Fri, 09 Feb 2018 09:41:57 GMT): C0rWin (Fri, 09 Feb 2018 13:04:57 GMT): dave.enyeart (Fri, 09 Feb 2018 13:34:56 GMT): dave.enyeart (Fri, 09 Feb 2018 13:34:57 GMT): dave.enyeart (Fri, 09 Feb 2018 13:35:04 GMT): ohmeraka (Mon, 12 Feb 2018 16:24:07 GMT): jasonpayne12 (Mon, 12 Feb 2018 20:35:43 GMT): PyiTheinKyaw (Tue, 13 Feb 2018 07:33:44 GMT): dave.enyeart (Tue, 13 Feb 2018 09:24:19 GMT): dave.enyeart (Tue, 13 Feb 2018 09:24:25 GMT): dave.enyeart (Tue, 13 Feb 2018 09:24:25 GMT): dave.enyeart (Tue, 13 Feb 2018 09:25:34 GMT): Ryan2 (Tue, 13 Feb 2018 14:45:14 GMT): melwindmello (Thu, 15 Feb 2018 09:59:03 GMT): DRSK (Fri, 16 Feb 2018 09:46:43 GMT): DRSK (Fri, 16 Feb 2018 09:46:43 GMT): DRSK (Fri, 16 Feb 2018 09:46:43 GMT): foxtrot9 (Sun, 18 Feb 2018 10:39:34 GMT): iamdm (Tue, 20 Feb 2018 09:59:44 GMT): RajanGupta (Tue, 20 Feb 2018 14:25:13 GMT): ArnabChatterjee (Wed, 21 Feb 2018 02:16:44 GMT): Wangrj (Thu, 22 Feb 2018 08:21:12 GMT): Wangrj (Thu, 22 Feb 2018 08:21:54 GMT): Senthil1 (Thu, 22 Feb 2018 08:54:35 GMT): sampath06 (Thu, 22 Feb 2018 14:09:20 GMT): yacovm (Thu, 22 Feb 2018 14:16:38 GMT): yacovm (Thu, 22 Feb 2018 14:16:48 GMT): yacovm (Thu, 22 Feb 2018 14:16:58 GMT): sampath06 (Thu, 22 Feb 2018 14:17:09 GMT): yacovm (Thu, 22 Feb 2018 14:17:51 GMT): claude.mamo (Sun, 25 Feb 2018 17:53:46 GMT): Ammu (Tue, 27 Feb 2018 05:24:55 GMT): debutinfotech (Tue, 27 Feb 2018 06:02:13 GMT): pd93 (Tue, 27 Feb 2018 15:15:19 GMT): pd93 (Tue, 27 Feb 2018 15:15:19 GMT): pd93 (Tue, 27 Feb 2018 15:15:19 GMT): minollo (Tue, 27 Feb 2018 15:27:27 GMT): dave.enyeart (Tue, 27 Feb 2018 15:29:08 GMT): dave.enyeart (Tue, 27 Feb 2018 15:29:39 GMT): dave.enyeart (Tue, 27 Feb 2018 15:30:17 GMT): pd93 (Tue, 27 Feb 2018 15:31:43 GMT): dave.enyeart (Tue, 27 Feb 2018 15:33:54 GMT): pd93 (Tue, 27 Feb 2018 15:34:28 GMT): kostas (Tue, 27 Feb 2018 15:35:21 GMT): minollo (Tue, 27 Feb 2018 15:36:17 GMT): minollo (Tue, 27 Feb 2018 15:36:42 GMT): kostas (Tue, 27 Feb 2018 15:38:40 GMT): kostas (Tue, 27 Feb 2018 15:38:40 GMT): minollo (Tue, 27 Feb 2018 15:40:24 GMT): minollo (Tue, 27 Feb 2018 15:40:45 GMT): dave.enyeart (Tue, 27 Feb 2018 15:41:58 GMT): minollo (Tue, 27 Feb 2018 15:42:06 GMT): minollo (Tue, 27 Feb 2018 15:42:42 GMT): kostas (Tue, 27 Feb 2018 15:43:08 GMT): kostas (Tue, 27 Feb 2018 15:43:08 GMT): kostas (Tue, 27 Feb 2018 15:43:50 GMT): minollo (Tue, 27 Feb 2018 15:44:21 GMT): minollo (Tue, 27 Feb 2018 15:44:34 GMT): kostas (Tue, 27 Feb 2018 15:47:01 GMT): manish-sethi (Tue, 27 Feb 2018 15:47:41 GMT): kostas (Tue, 27 Feb 2018 15:47:49 GMT): minollo (Tue, 27 Feb 2018 15:49:09 GMT): kostas (Tue, 27 Feb 2018 15:50:20 GMT): minollo (Tue, 27 Feb 2018 15:52:11 GMT): minollo (Tue, 27 Feb 2018 15:52:11 GMT): minollo (Tue, 27 Feb 2018 15:52:11 GMT): minollo (Tue, 27 Feb 2018 16:25:40 GMT): manish-sethi (Tue, 27 Feb 2018 16:25:59 GMT): VikasJakhar (Tue, 27 Feb 2018 20:10:13 GMT): debutinfotech (Wed, 28 Feb 2018 06:17:30 GMT): AlanPalmer (Wed, 28 Feb 2018 13:35:57 GMT): AlanPalmer (Wed, 28 Feb 2018 13:36:17 GMT): AlanPalmer (Wed, 28 Feb 2018 13:36:38 GMT): jrosmith (Wed, 28 Feb 2018 13:57:26 GMT): dampuero (Wed, 28 Feb 2018 15:06:17 GMT): JayJong (Thu, 01 Mar 2018 10:55:44 GMT): Nabilel 1 (Thu, 01 Mar 2018 13:54:19 GMT): Nabilel 1 (Thu, 01 Mar 2018 13:58:43 GMT): AndrewRy 1 (Thu, 01 Mar 2018 16:28:06 GMT): sakoula (Fri, 02 Mar 2018 10:35:06 GMT): pd93 (Mon, 05 Mar 2018 16:22:33 GMT): pd93 (Mon, 05 Mar 2018 16:22:33 GMT): pd93 (Mon, 05 Mar 2018 16:22:33 GMT): pd93 (Mon, 05 Mar 2018 16:22:33 GMT): dave.enyeart (Mon, 05 Mar 2018 16:24:36 GMT): pd93 (Mon, 05 Mar 2018 16:24:45 GMT): dave.enyeart (Mon, 05 Mar 2018 16:24:54 GMT): pd93 (Mon, 05 Mar 2018 16:25:50 GMT): pd93 (Mon, 05 Mar 2018 16:26:26 GMT): dave.enyeart (Mon, 05 Mar 2018 16:26:37 GMT): pd93 (Mon, 05 Mar 2018 16:26:57 GMT): pd93 (Mon, 05 Mar 2018 16:27:03 GMT): pd93 (Mon, 05 Mar 2018 16:31:49 GMT): gauthampamu (Tue, 06 Mar 2018 10:22:06 GMT): dave.enyeart (Tue, 06 Mar 2018 12:32:39 GMT): aatkddny (Tue, 06 Mar 2018 16:20:07 GMT): rjones (Tue, 06 Mar 2018 18:14:06 GMT): rjones (Tue, 06 Mar 2018 18:14:15 GMT): dave.enyeart (Tue, 06 Mar 2018 19:56:24 GMT): dave.enyeart (Tue, 06 Mar 2018 19:56:33 GMT): neharprodduturi (Thu, 08 Mar 2018 00:42:09 GMT): cheukchan (Thu, 08 Mar 2018 05:25:40 GMT): Rosan (Thu, 08 Mar 2018 08:38:21 GMT): kiranarshakota (Thu, 08 Mar 2018 11:03:39 GMT): dave.enyeart (Thu, 08 Mar 2018 11:44:34 GMT): gbolarhan (Fri, 09 Mar 2018 05:03:08 GMT): creativemonk (Sat, 10 Mar 2018 13:41:14 GMT): MoulaliMvg (Mon, 12 Mar 2018 05:22:55 GMT): javrevasandeep (Mon, 12 Mar 2018 15:30:18 GMT): jspark84 (Tue, 13 Mar 2018 13:15:40 GMT): antitoine (Tue, 13 Mar 2018 13:23:57 GMT): guruce (Wed, 14 Mar 2018 02:40:58 GMT): dave.enyeart (Wed, 14 Mar 2018 04:30:25 GMT): neharprodduturi (Wed, 14 Mar 2018 05:13:59 GMT): wlahti (Wed, 14 Mar 2018 12:46:59 GMT): brian038 (Wed, 14 Mar 2018 15:30:27 GMT): neharprodduturi (Wed, 14 Mar 2018 17:54:32 GMT): papegaaij (Thu, 15 Mar 2018 10:24:16 GMT): papegaaij (Thu, 15 Mar 2018 10:25:42 GMT): papegaaij (Thu, 15 Mar 2018 10:25:43 GMT): papegaaij (Thu, 15 Mar 2018 10:26:06 GMT): papegaaij (Thu, 15 Mar 2018 10:26:06 GMT): papegaaij (Thu, 15 Mar 2018 10:27:51 GMT): dave.enyeart (Thu, 15 Mar 2018 10:41:10 GMT): papegaaij (Thu, 15 Mar 2018 10:43:35 GMT): luomin (Thu, 15 Mar 2018 11:18:52 GMT): dave.enyeart (Thu, 15 Mar 2018 11:21:44 GMT): dave.enyeart (Thu, 15 Mar 2018 11:21:44 GMT): dave.enyeart (Thu, 15 Mar 2018 11:21:44 GMT): sakoula (Thu, 15 Mar 2018 14:15:49 GMT): blockgeek (Thu, 15 Mar 2018 18:31:27 GMT): yopep (Fri, 16 Mar 2018 05:58:51 GMT): chenjun-bj (Sat, 17 Mar 2018 00:59:09 GMT): VinayChaudhary (Sat, 17 Mar 2018 15:45:07 GMT): Senthil1 (Sat, 17 Mar 2018 16:37:31 GMT): dave.enyeart (Sat, 17 Mar 2018 16:58:38 GMT): luomin (Sun, 18 Mar 2018 23:34:22 GMT): robinrob (Mon, 19 Mar 2018 22:20:47 GMT): greg2git (Mon, 19 Mar 2018 23:39:52 GMT): wjzheng (Tue, 20 Mar 2018 19:06:58 GMT): ShikarSharma (Tue, 20 Mar 2018 22:43:34 GMT): bzeyben (Wed, 21 Mar 2018 11:05:47 GMT): tennenjl (Wed, 21 Mar 2018 19:55:31 GMT): dave.enyeart (Wed, 21 Mar 2018 21:07:44 GMT): dave.enyeart (Wed, 21 Mar 2018 21:08:52 GMT): tennenjl (Wed, 21 Mar 2018 21:09:35 GMT): tennenjl (Wed, 21 Mar 2018 22:06:17 GMT): dave.enyeart (Wed, 21 Mar 2018 22:06:48 GMT): dave.enyeart (Wed, 21 Mar 2018 22:06:48 GMT): tennenjl (Wed, 21 Mar 2018 22:13:07 GMT): dave.enyeart (Wed, 21 Mar 2018 22:18:41 GMT): tennenjl (Wed, 21 Mar 2018 22:33:12 GMT): DRSK (Thu, 22 Mar 2018 05:20:15 GMT): AlbertCL (Thu, 22 Mar 2018 10:47:11 GMT): dave.enyeart (Thu, 22 Mar 2018 12:08:09 GMT): yacovm (Thu, 22 Mar 2018 12:09:18 GMT): yacovm (Thu, 22 Mar 2018 12:09:22 GMT): yacovm (Thu, 22 Mar 2018 12:09:44 GMT): yacovm (Thu, 22 Mar 2018 12:10:02 GMT): yacovm (Thu, 22 Mar 2018 12:10:12 GMT): yacovm (Thu, 22 Mar 2018 12:10:20 GMT): dave.enyeart (Thu, 22 Mar 2018 12:10:44 GMT): yacovm (Thu, 22 Mar 2018 12:11:04 GMT): yacovm (Thu, 22 Mar 2018 12:13:59 GMT): yacovm (Thu, 22 Mar 2018 12:14:11 GMT): dave.enyeart (Thu, 22 Mar 2018 12:14:23 GMT): mastersingh24 (Thu, 22 Mar 2018 12:15:15 GMT): kostas (Thu, 22 Mar 2018 13:09:37 GMT): kostas (Thu, 22 Mar 2018 13:09:37 GMT): kostas (Thu, 22 Mar 2018 13:09:37 GMT): kostas (Thu, 22 Mar 2018 13:09:37 GMT): DRSK (Fri, 23 Mar 2018 03:13:40 GMT): pankajcheema (Fri, 23 Mar 2018 07:10:19 GMT): pankajcheema (Fri, 23 Mar 2018 07:10:32 GMT): pankajcheema (Fri, 23 Mar 2018 07:10:54 GMT): pankajcheema (Fri, 23 Mar 2018 07:11:04 GMT): pankajcheema (Fri, 23 Mar 2018 07:11:11 GMT): pankajcheema (Fri, 23 Mar 2018 07:24:02 GMT): mikykey (Fri, 23 Mar 2018 07:24:03 GMT): TobiasN (Fri, 23 Mar 2018 07:24:03 GMT): mikykey (Fri, 23 Mar 2018 07:29:25 GMT): pankajcheema (Fri, 23 Mar 2018 07:34:13 GMT): pankajcheema (Fri, 23 Mar 2018 07:34:21 GMT): pankajcheema (Fri, 23 Mar 2018 07:34:43 GMT): pankajcheema (Fri, 23 Mar 2018 07:35:03 GMT): pankajcheema (Fri, 23 Mar 2018 07:37:36 GMT): DarshanBc (Fri, 23 Mar 2018 07:37:38 GMT): mikykey (Fri, 23 Mar 2018 07:41:10 GMT): pankajcheema (Fri, 23 Mar 2018 07:43:44 GMT): pankajcheema (Fri, 23 Mar 2018 07:43:53 GMT): TobiasN (Fri, 23 Mar 2018 08:19:34 GMT): TobiasN (Fri, 23 Mar 2018 08:39:11 GMT): mikykey (Fri, 23 Mar 2018 09:05:38 GMT): tennenjl (Fri, 23 Mar 2018 12:22:38 GMT): dave.enyeart (Sat, 24 Mar 2018 12:00:14 GMT): hantzaras (Sun, 25 Mar 2018 14:21:10 GMT): UjwalTamminedi (Sun, 25 Mar 2018 14:23:51 GMT): amy_xu22 (Tue, 27 Mar 2018 02:02:45 GMT): shivaganesh01 (Tue, 27 Mar 2018 03:52:04 GMT): shivaganesh01 (Tue, 27 Mar 2018 03:52:40 GMT): BilalAhmad (Tue, 27 Mar 2018 06:30:47 GMT): dave.enyeart (Tue, 27 Mar 2018 12:53:48 GMT): shivaganesh01 (Wed, 28 Mar 2018 05:14:57 GMT): kingofsevens (Wed, 28 Mar 2018 06:11:43 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 06:35:18 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 06:36:18 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 06:37:48 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 06:39:04 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 06:39:52 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 06:39:53 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 07:27:43 GMT): KGiou (Wed, 28 Mar 2018 08:33:32 GMT): dave.enyeart (Wed, 28 Mar 2018 11:32:02 GMT): manish-sethi (Wed, 28 Mar 2018 13:18:10 GMT): manish-sethi (Wed, 28 Mar 2018 13:28:22 GMT): manish-sethi (Wed, 28 Mar 2018 13:28:22 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:36:51 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:36:51 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:37:54 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:39:17 GMT): manish-sethi (Wed, 28 Mar 2018 14:39:20 GMT): manish-sethi (Wed, 28 Mar 2018 14:40:21 GMT): manish-sethi (Wed, 28 Mar 2018 14:41:16 GMT): manish-sethi (Wed, 28 Mar 2018 14:41:16 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:41:34 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:41:34 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:41:34 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:43:05 GMT): manish-sethi (Wed, 28 Mar 2018 14:45:57 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:46:29 GMT): manish-sethi (Wed, 28 Mar 2018 14:46:48 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:47:21 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:47:21 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:47:21 GMT): manish-sethi (Wed, 28 Mar 2018 14:50:53 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:51:33 GMT): manish-sethi (Wed, 28 Mar 2018 14:52:36 GMT): manish-sethi (Wed, 28 Mar 2018 14:52:36 GMT): manish-sethi (Wed, 28 Mar 2018 14:53:56 GMT): asaningmaxchain123 (Wed, 28 Mar 2018 14:54:57 GMT): Guid0 (Thu, 29 Mar 2018 09:33:43 GMT): thalisson (Sun, 01 Apr 2018 02:45:09 GMT): richzhao (Sun, 01 Apr 2018 15:19:33 GMT): Rumeel_Hussain (Tue, 03 Apr 2018 15:11:33 GMT): wbhagan (Tue, 03 Apr 2018 15:30:30 GMT): magicianx25 (Tue, 03 Apr 2018 15:33:18 GMT): wbhagan (Tue, 03 Apr 2018 15:47:27 GMT): wbhagan (Tue, 03 Apr 2018 21:10:43 GMT): dave.enyeart (Tue, 03 Apr 2018 21:14:00 GMT): wbhagan (Tue, 03 Apr 2018 21:40:49 GMT): dave.enyeart (Tue, 03 Apr 2018 21:52:55 GMT): wbhagan (Tue, 03 Apr 2018 22:04:30 GMT): wbhagan (Tue, 03 Apr 2018 22:04:30 GMT): david636 (Wed, 04 Apr 2018 00:00:50 GMT): dave.enyeart (Wed, 04 Apr 2018 02:43:51 GMT): kostas (Wed, 04 Apr 2018 03:54:25 GMT): magicianx25 (Wed, 04 Apr 2018 07:12:55 GMT): magicianx25 (Wed, 04 Apr 2018 07:13:02 GMT): magicianx25 (Wed, 04 Apr 2018 07:13:49 GMT): magicianx25 (Wed, 04 Apr 2018 07:32:33 GMT): magicianx25 (Wed, 04 Apr 2018 07:34:42 GMT): jyellick (Wed, 04 Apr 2018 13:51:24 GMT): magicianx25 (Wed, 04 Apr 2018 15:08:49 GMT): wbhagan (Wed, 04 Apr 2018 15:57:19 GMT): jyellick (Wed, 04 Apr 2018 16:29:03 GMT): jyellick (Wed, 04 Apr 2018 16:29:31 GMT): magicianx25 (Thu, 05 Apr 2018 08:54:55 GMT): Ammu (Thu, 05 Apr 2018 10:18:22 GMT): magicianx25 (Thu, 05 Apr 2018 12:37:04 GMT): pankajcheema (Thu, 05 Apr 2018 17:58:15 GMT): bh4rtp (Fri, 06 Apr 2018 12:51:34 GMT): pankajcheema (Fri, 06 Apr 2018 12:54:34 GMT): pankajcheema (Fri, 06 Apr 2018 12:55:03 GMT): bh4rtp (Fri, 06 Apr 2018 13:00:32 GMT): asaningmaxchain123 (Sat, 07 Apr 2018 03:06:14 GMT): asaningmaxchain123 (Sat, 07 Apr 2018 03:06:14 GMT): terby (Mon, 09 Apr 2018 05:18:45 GMT): dayubian (Mon, 09 Apr 2018 11:39:00 GMT): manish-sethi (Mon, 09 Apr 2018 13:43:54 GMT): asaningmaxchain123 (Mon, 09 Apr 2018 15:15:18 GMT): asaningmaxchain123 (Mon, 09 Apr 2018 15:15:18 GMT): asaningmaxchain123 (Mon, 09 Apr 2018 15:15:18 GMT): manish-sethi (Mon, 09 Apr 2018 15:15:59 GMT): asaningmaxchain123 (Mon, 09 Apr 2018 15:17:02 GMT): asaningmaxchain123 (Mon, 09 Apr 2018 15:17:02 GMT): manish-sethi (Mon, 09 Apr 2018 17:28:58 GMT): manish-sethi (Mon, 09 Apr 2018 17:29:14 GMT): jrosmith (Mon, 09 Apr 2018 18:10:49 GMT): BertCatsburg (Tue, 10 Apr 2018 16:43:42 GMT): balaji.viswanathan (Wed, 11 Apr 2018 04:26:50 GMT): balaji.viswanathan (Wed, 11 Apr 2018 04:26:50 GMT): dsl (Wed, 11 Apr 2018 04:58:47 GMT): anzalbeg (Wed, 11 Apr 2018 05:58:32 GMT): sayan.hlf (Wed, 11 Apr 2018 10:29:39 GMT): sayan.hlf (Wed, 11 Apr 2018 13:55:00 GMT): asaningmaxchain123 (Wed, 11 Apr 2018 15:24:59 GMT): asaningmaxchain123 (Wed, 11 Apr 2018 15:24:59 GMT): manish-sethi (Wed, 11 Apr 2018 15:26:26 GMT): asaningmaxchain123 (Wed, 11 Apr 2018 15:27:57 GMT): manish-sethi (Wed, 11 Apr 2018 15:28:33 GMT): manish-sethi (Wed, 11 Apr 2018 15:28:33 GMT): asaningmaxchain123 (Wed, 11 Apr 2018 15:30:23 GMT): asaningmaxchain123 (Wed, 11 Apr 2018 15:30:23 GMT): asaningmaxchain123 (Wed, 11 Apr 2018 15:30:23 GMT): asaningmaxchain123 (Wed, 11 Apr 2018 15:30:23 GMT): AdnanC (Wed, 11 Apr 2018 20:02:11 GMT): jrosmith (Wed, 11 Apr 2018 20:43:27 GMT): dave.enyeart (Wed, 11 Apr 2018 20:45:56 GMT): dave.enyeart (Wed, 11 Apr 2018 20:46:20 GMT): dave.enyeart (Wed, 11 Apr 2018 20:46:47 GMT): AdnanC (Wed, 11 Apr 2018 20:46:58 GMT): dave.enyeart (Wed, 11 Apr 2018 20:47:20 GMT): manish-sethi (Thu, 12 Apr 2018 03:01:07 GMT): davidgsmits (Thu, 12 Apr 2018 13:49:28 GMT): SmartContract2018 (Thu, 12 Apr 2018 21:17:37 GMT): SmartContract2018 (Thu, 12 Apr 2018 21:22:53 GMT): SmartContract2018 (Thu, 12 Apr 2018 21:23:59 GMT): magicianx25 (Fri, 13 Apr 2018 07:39:16 GMT): magicianx25 (Fri, 13 Apr 2018 07:39:55 GMT): magicianx25 (Fri, 13 Apr 2018 07:40:18 GMT): dave.enyeart (Fri, 13 Apr 2018 12:25:41 GMT): dave.enyeart (Fri, 13 Apr 2018 12:25:55 GMT): dave.enyeart (Fri, 13 Apr 2018 12:27:06 GMT): mozkarakoc (Fri, 13 Apr 2018 16:26:18 GMT): mozkarakoc (Fri, 13 Apr 2018 16:49:06 GMT): mozkarakoc (Fri, 13 Apr 2018 16:49:25 GMT): jyellick (Fri, 13 Apr 2018 17:39:18 GMT): mozkarakoc (Fri, 13 Apr 2018 17:54:40 GMT): mozkarakoc (Fri, 13 Apr 2018 18:28:24 GMT): jyellick (Fri, 13 Apr 2018 18:43:54 GMT): mozkarakoc (Fri, 13 Apr 2018 19:05:13 GMT): jyellick (Fri, 13 Apr 2018 19:21:17 GMT): jyellick (Fri, 13 Apr 2018 19:21:17 GMT): SmartContract2018 (Fri, 13 Apr 2018 19:26:16 GMT): mozkarakoc (Fri, 13 Apr 2018 19:29:09 GMT): SmartContract2018 (Fri, 13 Apr 2018 19:32:35 GMT): dave.enyeart (Fri, 13 Apr 2018 19:37:36 GMT): dave.enyeart (Fri, 13 Apr 2018 19:39:29 GMT): dave.enyeart (Fri, 13 Apr 2018 19:39:29 GMT): dave.enyeart (Fri, 13 Apr 2018 19:55:27 GMT): dave.enyeart (Fri, 13 Apr 2018 19:55:42 GMT): mozkarakoc (Fri, 13 Apr 2018 19:56:43 GMT): mozkarakoc (Fri, 13 Apr 2018 19:59:13 GMT): dave.enyeart (Fri, 13 Apr 2018 20:02:59 GMT): SmartContract2018 (Fri, 13 Apr 2018 20:24:30 GMT): dave.enyeart (Fri, 13 Apr 2018 20:26:04 GMT): SmartContract2018 (Fri, 13 Apr 2018 20:29:27 GMT): muralisr (Fri, 13 Apr 2018 20:47:13 GMT): muralisr (Fri, 13 Apr 2018 20:54:25 GMT): muralisr (Fri, 13 Apr 2018 20:54:25 GMT): dave.enyeart (Fri, 13 Apr 2018 20:56:00 GMT): muralisr (Fri, 13 Apr 2018 20:56:53 GMT): muralisr (Fri, 13 Apr 2018 20:57:05 GMT): dave.enyeart (Fri, 13 Apr 2018 20:58:58 GMT): muralisr (Fri, 13 Apr 2018 20:59:55 GMT): muralisr (Fri, 13 Apr 2018 21:02:24 GMT): dave.enyeart (Fri, 13 Apr 2018 21:04:38 GMT): jyellick (Fri, 13 Apr 2018 21:09:43 GMT): jyellick (Fri, 13 Apr 2018 21:10:05 GMT): muralisr (Fri, 13 Apr 2018 21:10:45 GMT): muralisr (Fri, 13 Apr 2018 21:10:45 GMT): jyellick (Fri, 13 Apr 2018 21:11:21 GMT): muralisr (Fri, 13 Apr 2018 21:11:39 GMT): jyellick (Fri, 13 Apr 2018 21:11:44 GMT): muralisr (Fri, 13 Apr 2018 21:11:57 GMT): jyellick (Fri, 13 Apr 2018 21:12:29 GMT): muralisr (Fri, 13 Apr 2018 21:12:58 GMT): muralisr (Fri, 13 Apr 2018 21:13:52 GMT): mozkarakoc (Fri, 13 Apr 2018 21:22:43 GMT): mozkarakoc (Fri, 13 Apr 2018 21:25:39 GMT): SmartContract2018 (Fri, 13 Apr 2018 21:30:37 GMT): SmartContract2018 (Fri, 13 Apr 2018 21:31:14 GMT): muralisr (Fri, 13 Apr 2018 21:34:48 GMT): muralisr (Fri, 13 Apr 2018 21:36:30 GMT): SmartContract2018 (Fri, 13 Apr 2018 22:33:03 GMT): pb (Mon, 16 Apr 2018 03:14:39 GMT): Ammu (Tue, 17 Apr 2018 10:25:45 GMT): pb (Tue, 17 Apr 2018 10:42:58 GMT): pb (Tue, 17 Apr 2018 10:42:58 GMT): Gh0stR0ck (Tue, 17 Apr 2018 12:58:58 GMT): dave.enyeart (Tue, 17 Apr 2018 13:27:12 GMT): dave.enyeart (Tue, 17 Apr 2018 13:27:33 GMT): dave.enyeart (Tue, 17 Apr 2018 13:27:33 GMT): dave.enyeart (Tue, 17 Apr 2018 13:27:51 GMT): tushad (Tue, 17 Apr 2018 17:36:19 GMT): manish-sethi (Wed, 18 Apr 2018 00:36:36 GMT): pb (Wed, 18 Apr 2018 03:07:58 GMT): pb (Wed, 18 Apr 2018 03:08:56 GMT): amolpednekar (Wed, 18 Apr 2018 05:06:48 GMT): amolpednekar (Wed, 18 Apr 2018 05:06:48 GMT): amolpednekar (Wed, 18 Apr 2018 05:06:48 GMT): dave.enyeart (Wed, 18 Apr 2018 10:35:45 GMT): amolpednekar (Wed, 18 Apr 2018 10:48:08 GMT): pjjp (Wed, 18 Apr 2018 12:51:39 GMT): manish-sethi (Wed, 18 Apr 2018 13:53:58 GMT): manish-sethi (Wed, 18 Apr 2018 13:53:58 GMT): pb (Thu, 19 Apr 2018 06:25:01 GMT): Mihai.A (Thu, 19 Apr 2018 13:53:38 GMT): manish-sethi (Thu, 19 Apr 2018 14:57:44 GMT): manish-sethi (Thu, 19 Apr 2018 14:57:44 GMT): manish-sethi (Thu, 19 Apr 2018 14:57:44 GMT): remmeier (Fri, 20 Apr 2018 06:34:38 GMT): pb (Fri, 20 Apr 2018 11:13:43 GMT): manish-sethi (Fri, 20 Apr 2018 20:02:03 GMT): manish-sethi (Fri, 20 Apr 2018 20:02:03 GMT): minollo (Sat, 21 Apr 2018 03:40:34 GMT): manish-sethi (Sat, 21 Apr 2018 13:48:44 GMT): minollo (Sat, 21 Apr 2018 13:49:21 GMT): toesterdahl (Sun, 22 Apr 2018 20:39:27 GMT): pb (Mon, 23 Apr 2018 03:42:18 GMT): labcoinpoc (Mon, 23 Apr 2018 04:14:13 GMT): pankajcheema (Mon, 23 Apr 2018 08:53:07 GMT): hrt031293 (Mon, 23 Apr 2018 11:44:01 GMT): manish-sethi (Mon, 23 Apr 2018 13:57:48 GMT): pankajcheema (Mon, 23 Apr 2018 13:59:36 GMT): pankajcheema (Mon, 23 Apr 2018 13:59:36 GMT): manish-sethi (Mon, 23 Apr 2018 14:41:31 GMT): pankajcheema (Mon, 23 Apr 2018 14:44:24 GMT): pankajcheema (Mon, 23 Apr 2018 17:15:35 GMT): manish-sethi (Mon, 23 Apr 2018 18:54:15 GMT): minollo (Tue, 24 Apr 2018 07:22:58 GMT): tsnyder (Tue, 24 Apr 2018 10:54:42 GMT): tsnyder (Tue, 24 Apr 2018 10:57:11 GMT): minollo (Tue, 24 Apr 2018 11:42:05 GMT): tsnyder (Tue, 24 Apr 2018 11:44:52 GMT): minollo (Tue, 24 Apr 2018 11:46:28 GMT): tsnyder (Tue, 24 Apr 2018 11:53:35 GMT): minollo (Tue, 24 Apr 2018 11:54:05 GMT): tsnyder (Tue, 24 Apr 2018 11:54:16 GMT): manish-sethi (Tue, 24 Apr 2018 16:15:27 GMT): minollo (Tue, 24 Apr 2018 18:43:38 GMT): manish-sethi (Tue, 24 Apr 2018 18:59:31 GMT): minollo (Tue, 24 Apr 2018 19:02:04 GMT): qsmen (Wed, 25 Apr 2018 06:03:44 GMT): qsmen (Wed, 25 Apr 2018 07:07:54 GMT): gauthampamu (Wed, 25 Apr 2018 13:23:22 GMT): gauthampamu (Wed, 25 Apr 2018 13:23:22 GMT): gauthampamu (Wed, 25 Apr 2018 13:23:22 GMT): qsmen (Thu, 26 Apr 2018 02:39:46 GMT): qsmen (Thu, 26 Apr 2018 03:31:10 GMT): qsmen (Thu, 26 Apr 2018 03:31:10 GMT): qsmen (Thu, 26 Apr 2018 03:31:10 GMT): qsmen (Thu, 26 Apr 2018 03:31:10 GMT): qsmen (Thu, 26 Apr 2018 03:41:54 GMT): SmartContract2018 (Thu, 26 Apr 2018 13:27:44 GMT): SmartContract2018 (Thu, 26 Apr 2018 15:40:03 GMT): gauthampamu (Thu, 26 Apr 2018 16:56:25 GMT): gauthampamu (Thu, 26 Apr 2018 17:02:50 GMT): gauthampamu (Thu, 26 Apr 2018 17:06:01 GMT): gauthampamu (Thu, 26 Apr 2018 17:07:24 GMT): pankajcheema (Thu, 26 Apr 2018 17:58:39 GMT): dave.enyeart (Thu, 26 Apr 2018 19:59:04 GMT): dave.enyeart (Thu, 26 Apr 2018 20:01:51 GMT): gauthampamu (Thu, 26 Apr 2018 21:23:24 GMT): gauthampamu (Thu, 26 Apr 2018 21:25:19 GMT): toddinpal (Thu, 26 Apr 2018 21:31:13 GMT): toddinpal (Thu, 26 Apr 2018 21:31:32 GMT): eabiodun (Thu, 26 Apr 2018 21:33:32 GMT): toddinpal (Thu, 26 Apr 2018 21:36:57 GMT): eabiodun (Thu, 26 Apr 2018 21:38:04 GMT): SmartContract2018 (Thu, 26 Apr 2018 21:45:27 GMT): SmartContract2018 (Thu, 26 Apr 2018 21:51:51 GMT): eabiodun (Thu, 26 Apr 2018 21:53:52 GMT): SmartContract2018 (Thu, 26 Apr 2018 21:58:50 GMT): eabiodun (Thu, 26 Apr 2018 22:05:55 GMT): eabiodun (Thu, 26 Apr 2018 22:10:32 GMT): srujana_k (Fri, 27 Apr 2018 10:00:06 GMT): dave.enyeart (Fri, 27 Apr 2018 15:31:39 GMT): dave.enyeart (Fri, 27 Apr 2018 15:31:41 GMT): dave.enyeart (Fri, 27 Apr 2018 15:32:41 GMT): dave.enyeart (Fri, 27 Apr 2018 15:33:57 GMT): dave.enyeart (Fri, 27 Apr 2018 15:34:00 GMT): dave.enyeart (Fri, 27 Apr 2018 15:35:29 GMT): toddinpal (Fri, 27 Apr 2018 15:35:56 GMT): dave.enyeart (Fri, 27 Apr 2018 15:36:30 GMT): dave.enyeart (Fri, 27 Apr 2018 15:36:58 GMT): dave.enyeart (Fri, 27 Apr 2018 15:37:20 GMT): toddinpal (Fri, 27 Apr 2018 15:37:58 GMT): dave.enyeart (Fri, 27 Apr 2018 15:38:07 GMT): dave.enyeart (Fri, 27 Apr 2018 15:38:48 GMT): toddinpal (Fri, 27 Apr 2018 15:40:12 GMT): toddinpal (Fri, 27 Apr 2018 15:41:15 GMT): dave.enyeart (Fri, 27 Apr 2018 15:42:51 GMT): toddinpal (Fri, 27 Apr 2018 15:43:09 GMT): toddinpal (Fri, 27 Apr 2018 15:43:59 GMT): dave.enyeart (Fri, 27 Apr 2018 15:44:24 GMT): toddinpal (Fri, 27 Apr 2018 15:44:28 GMT): dave.enyeart (Fri, 27 Apr 2018 15:46:33 GMT): toddinpal (Fri, 27 Apr 2018 15:46:56 GMT): dave.enyeart (Fri, 27 Apr 2018 15:47:28 GMT): chainsaw (Fri, 27 Apr 2018 15:52:28 GMT): gauthampamu (Fri, 27 Apr 2018 16:37:28 GMT): gauthampamu (Fri, 27 Apr 2018 16:39:55 GMT): gauthampamu (Fri, 27 Apr 2018 16:39:59 GMT): gauthampamu (Fri, 27 Apr 2018 16:52:23 GMT): gauthampamu (Fri, 27 Apr 2018 16:52:24 GMT): dave.enyeart (Fri, 27 Apr 2018 19:22:12 GMT): dave.enyeart (Fri, 27 Apr 2018 19:22:14 GMT): gauthampamu (Fri, 27 Apr 2018 20:08:03 GMT): dave.enyeart (Fri, 27 Apr 2018 21:02:59 GMT): kostas (Fri, 27 Apr 2018 21:58:41 GMT): naveen_saravanan (Sun, 29 Apr 2018 03:45:04 GMT): naveen_saravanan (Sun, 29 Apr 2018 03:45:35 GMT): dave.enyeart (Sun, 29 Apr 2018 13:52:44 GMT): dave.enyeart (Sun, 29 Apr 2018 13:52:44 GMT): naveen_saravanan (Mon, 30 Apr 2018 00:44:02 GMT): dave.enyeart (Mon, 30 Apr 2018 01:22:12 GMT): dave.enyeart (Mon, 30 Apr 2018 01:23:33 GMT): naveen_saravanan (Mon, 30 Apr 2018 06:17:04 GMT): naveen_saravanan (Mon, 30 Apr 2018 06:17:04 GMT): naveen_saravanan (Mon, 30 Apr 2018 06:17:04 GMT): dave.enyeart (Mon, 30 Apr 2018 08:13:22 GMT): gauthampamu (Mon, 30 Apr 2018 14:42:58 GMT): dave.enyeart (Mon, 30 Apr 2018 14:59:38 GMT): gauthampamu (Mon, 30 Apr 2018 16:23:52 GMT): MeenakshiSingh (Mon, 30 Apr 2018 16:28:40 GMT): dave.enyeart (Mon, 30 Apr 2018 17:10:50 GMT): dave.enyeart (Mon, 30 Apr 2018 17:29:05 GMT): acbellini (Tue, 01 May 2018 21:10:13 GMT): clydedacruz (Wed, 02 May 2018 06:54:59 GMT): clydedacruz (Wed, 02 May 2018 06:55:51 GMT): clydedacruz (Wed, 02 May 2018 06:55:51 GMT): clydedacruz (Wed, 02 May 2018 06:55:51 GMT): clydedacruz (Wed, 02 May 2018 07:15:16 GMT): dave.enyeart (Wed, 02 May 2018 10:36:18 GMT): dave.enyeart (Wed, 02 May 2018 10:38:05 GMT): clydedacruz (Wed, 02 May 2018 11:10:55 GMT): dave.enyeart (Wed, 02 May 2018 11:12:43 GMT): clydedacruz (Wed, 02 May 2018 11:14:04 GMT): papegaaij (Wed, 02 May 2018 12:28:34 GMT): papegaaij (Wed, 02 May 2018 12:28:57 GMT): youssefg (Wed, 02 May 2018 18:24:23 GMT): kevin-s-wang (Thu, 03 May 2018 02:36:19 GMT): naveen_saravanan (Thu, 03 May 2018 04:21:44 GMT): acbellini (Thu, 03 May 2018 11:21:43 GMT): downTheFallLine (Thu, 03 May 2018 18:54:01 GMT): downTheFallLine (Thu, 03 May 2018 18:54:34 GMT): wlahti (Thu, 03 May 2018 18:58:31 GMT): wlahti (Thu, 03 May 2018 18:58:31 GMT): wlahti (Thu, 03 May 2018 18:58:31 GMT): JackStrohm (Thu, 03 May 2018 19:05:14 GMT): downTheFallLine (Thu, 03 May 2018 19:17:02 GMT): downTheFallLine (Thu, 03 May 2018 19:18:53 GMT): jrosmith (Thu, 03 May 2018 19:59:23 GMT): jrosmith (Thu, 03 May 2018 19:59:23 GMT): jrosmith (Thu, 03 May 2018 19:59:23 GMT): jrosmith (Thu, 03 May 2018 19:59:32 GMT): downTheFallLine (Thu, 03 May 2018 20:18:36 GMT): jrosmith (Thu, 03 May 2018 20:31:12 GMT): jrosmith (Thu, 03 May 2018 20:31:12 GMT): titog (Thu, 03 May 2018 20:31:53 GMT): songyuanjie (Fri, 04 May 2018 02:11:37 GMT): dave.enyeart (Sat, 05 May 2018 14:07:00 GMT): sheehan (Sat, 05 May 2018 14:07:02 GMT): C0rWin (Sat, 05 May 2018 14:14:53 GMT): C0rWin (Sat, 05 May 2018 14:14:53 GMT): sheehan (Sat, 05 May 2018 14:18:01 GMT): C0rWin (Sat, 05 May 2018 14:40:53 GMT): sheehan (Sat, 05 May 2018 14:42:55 GMT): C0rWin (Sat, 05 May 2018 15:02:58 GMT): dave.enyeart (Sat, 05 May 2018 16:16:28 GMT): lclclc (Sun, 06 May 2018 06:21:39 GMT): lclclc (Sun, 06 May 2018 06:27:34 GMT): ShrutiSinha (Mon, 07 May 2018 08:25:32 GMT): sheehan (Mon, 07 May 2018 15:48:29 GMT): sheehan (Mon, 07 May 2018 16:01:56 GMT): lclclc (Tue, 08 May 2018 05:52:00 GMT): lclclc (Tue, 08 May 2018 05:52:00 GMT): hrt031293 (Wed, 09 May 2018 11:57:24 GMT): SmartContract2018 (Wed, 09 May 2018 21:25:44 GMT): Amjadnz (Thu, 10 May 2018 06:22:29 GMT): Amjadnz (Thu, 10 May 2018 06:22:40 GMT): Amjadnz (Thu, 10 May 2018 06:24:23 GMT): Amjadnz (Thu, 10 May 2018 06:25:07 GMT): Amjadnz (Thu, 10 May 2018 22:53:32 GMT): Amjadnz (Thu, 10 May 2018 22:53:55 GMT): Amjadnz (Thu, 10 May 2018 22:54:56 GMT): Amjadnz (Thu, 10 May 2018 22:54:56 GMT): Amjadnz (Fri, 11 May 2018 00:15:53 GMT): Amjadnz (Fri, 11 May 2018 00:16:05 GMT): Amjadnz (Fri, 11 May 2018 00:17:11 GMT): Amjadnz (Fri, 11 May 2018 00:17:11 GMT): Amjadnz (Fri, 11 May 2018 00:17:11 GMT): Amjadnz (Fri, 11 May 2018 00:17:22 GMT): Amjadnz (Fri, 11 May 2018 00:19:42 GMT): Amjadnz (Fri, 11 May 2018 00:19:42 GMT): Amjadnz (Fri, 11 May 2018 00:20:39 GMT): Amjadnz (Fri, 11 May 2018 13:26:35 GMT): dave.enyeart (Fri, 11 May 2018 15:17:33 GMT): Amjadnz (Fri, 11 May 2018 15:22:07 GMT): Amjadnz (Fri, 11 May 2018 15:22:20 GMT): Amjadnz (Fri, 11 May 2018 15:22:36 GMT): dave.enyeart (Fri, 11 May 2018 15:26:05 GMT): Amjadnz (Fri, 11 May 2018 15:40:48 GMT): Amjadnz (Fri, 11 May 2018 15:41:08 GMT): Amjadnz (Fri, 11 May 2018 15:41:13 GMT): Amjadnz (Fri, 11 May 2018 15:41:13 GMT): Amjadnz (Fri, 11 May 2018 15:41:26 GMT): Amjadnz (Fri, 11 May 2018 15:42:12 GMT): Amjadnz (Fri, 11 May 2018 15:43:25 GMT): Amjadnz (Fri, 11 May 2018 15:53:46 GMT): Amjadnz (Sat, 12 May 2018 09:28:59 GMT): Amjadnz (Sat, 12 May 2018 09:29:06 GMT): bh4rtp (Sat, 12 May 2018 15:52:32 GMT): dave.enyeart (Sat, 12 May 2018 16:45:48 GMT): bh4rtp (Sun, 13 May 2018 02:18:29 GMT): bh4rtp (Sun, 13 May 2018 02:19:46 GMT): dave.enyeart (Sun, 13 May 2018 10:12:05 GMT): sykesm (Sun, 13 May 2018 10:12:05 GMT): muralisr (Sun, 13 May 2018 15:23:48 GMT): bh4rtp (Mon, 14 May 2018 00:50:33 GMT): muralisr (Mon, 14 May 2018 00:57:37 GMT): bh4rtp (Mon, 14 May 2018 00:58:15 GMT): muralisr (Mon, 14 May 2018 01:10:35 GMT): bh4rtp (Mon, 14 May 2018 02:46:47 GMT): bh4rtp (Mon, 14 May 2018 03:20:19 GMT): bh4rtp (Mon, 14 May 2018 03:45:13 GMT): versus (Mon, 14 May 2018 09:06:38 GMT): muralisr (Mon, 14 May 2018 13:12:51 GMT): umapm113 (Wed, 16 May 2018 07:19:33 GMT): asaningmaxchain123 (Wed, 16 May 2018 14:42:03 GMT): asaningmaxchain123 (Wed, 16 May 2018 15:09:29 GMT): dave.enyeart (Wed, 16 May 2018 15:15:19 GMT): dave.enyeart (Wed, 16 May 2018 15:15:21 GMT): dave.enyeart (Wed, 16 May 2018 15:15:21 GMT): gauthampamu (Wed, 16 May 2018 22:37:43 GMT): bh4rtp (Thu, 17 May 2018 01:53:39 GMT): dave.enyeart (Thu, 17 May 2018 04:03:45 GMT): dave.enyeart (Thu, 17 May 2018 04:03:45 GMT): dave.enyeart (Thu, 17 May 2018 04:04:55 GMT): dave.enyeart (Thu, 17 May 2018 04:06:56 GMT): asaningmaxchain123 (Thu, 17 May 2018 11:15:25 GMT): dave.enyeart (Thu, 17 May 2018 12:51:56 GMT): asaningmaxchain123 (Thu, 17 May 2018 13:23:24 GMT): gauthampamu (Mon, 21 May 2018 20:33:23 GMT): dave.enyeart (Tue, 22 May 2018 03:06:04 GMT): pankajcheema (Wed, 23 May 2018 06:00:41 GMT): pankajcheema (Wed, 23 May 2018 06:01:17 GMT): pankajcheema (Wed, 23 May 2018 06:01:25 GMT): pankajcheema (Wed, 23 May 2018 06:01:36 GMT): pankajcheema (Wed, 23 May 2018 06:02:18 GMT): pankajcheema (Wed, 23 May 2018 06:02:20 GMT): AnkitSingh5 (Thu, 24 May 2018 06:22:03 GMT): AnkitSingh5 (Thu, 24 May 2018 06:22:17 GMT): AnkitSingh5 (Thu, 24 May 2018 06:22:17 GMT): AnkitSingh5 (Thu, 24 May 2018 06:22:17 GMT): AnkitSingh5 (Thu, 24 May 2018 06:22:17 GMT): AnkitSingh5 (Thu, 24 May 2018 06:49:45 GMT): DivyaAgrawal (Fri, 25 May 2018 11:42:40 GMT): amolpednekar (Sun, 27 May 2018 14:49:59 GMT): amolpednekar (Sun, 27 May 2018 14:50:14 GMT): aatkddny (Tue, 29 May 2018 12:14:00 GMT): asaningmaxchain123 (Tue, 29 May 2018 14:36:05 GMT): header340 (Tue, 29 May 2018 17:17:37 GMT): RocMax (Tue, 29 May 2018 23:46:13 GMT): IgorSim (Wed, 30 May 2018 10:12:00 GMT): AnilOner (Wed, 30 May 2018 12:26:02 GMT): vdelbar (Wed, 30 May 2018 15:34:25 GMT): jyellick (Wed, 30 May 2018 17:31:10 GMT): jyellick (Wed, 30 May 2018 17:31:52 GMT): sarapara (Wed, 30 May 2018 17:31:52 GMT): dave.enyeart (Wed, 30 May 2018 17:35:00 GMT): dave.enyeart (Wed, 30 May 2018 17:39:33 GMT): rbole (Wed, 30 May 2018 17:51:53 GMT): sarapara (Wed, 30 May 2018 18:33:24 GMT): sarapara (Wed, 30 May 2018 18:33:24 GMT): dave.enyeart (Wed, 30 May 2018 19:05:17 GMT): dave.enyeart (Wed, 30 May 2018 19:05:33 GMT): rogerwilcos (Wed, 30 May 2018 23:14:24 GMT): amolpednekar (Fri, 01 Jun 2018 04:35:54 GMT): jrosmith (Fri, 01 Jun 2018 04:38:06 GMT): amolpednekar (Fri, 01 Jun 2018 04:47:28 GMT): jrosmith (Fri, 01 Jun 2018 04:55:27 GMT): amolpednekar (Fri, 01 Jun 2018 04:57:15 GMT): amolpednekar (Fri, 01 Jun 2018 04:57:15 GMT): amolpednekar (Fri, 01 Jun 2018 04:57:15 GMT): jrosmith (Fri, 01 Jun 2018 04:59:59 GMT): Kyroy (Fri, 01 Jun 2018 10:38:08 GMT): Kyroy (Fri, 01 Jun 2018 10:39:27 GMT): Kyroy (Fri, 01 Jun 2018 10:40:53 GMT): demonkm (Sun, 03 Jun 2018 02:27:38 GMT): niteshsolanki (Mon, 04 Jun 2018 16:00:11 GMT): niteshsolanki (Mon, 04 Jun 2018 16:00:11 GMT): dave.enyeart (Mon, 04 Jun 2018 17:22:10 GMT): sarapara (Mon, 04 Jun 2018 19:37:04 GMT): jrosmith (Tue, 05 Jun 2018 03:50:46 GMT): amolpednekar (Tue, 05 Jun 2018 09:46:32 GMT): gauthampamu (Tue, 05 Jun 2018 12:34:26 GMT): dave.enyeart (Tue, 05 Jun 2018 13:25:24 GMT): gauthampamu (Tue, 05 Jun 2018 21:22:12 GMT): gauthampamu (Tue, 05 Jun 2018 21:22:12 GMT): bh4rtp (Wed, 06 Jun 2018 00:39:28 GMT): bh4rtp (Wed, 06 Jun 2018 00:39:28 GMT): bh4rtp (Wed, 06 Jun 2018 00:39:28 GMT): bh4rtp (Wed, 06 Jun 2018 06:08:36 GMT): bh4rtp (Wed, 06 Jun 2018 06:54:13 GMT): bh4rtp (Wed, 06 Jun 2018 06:54:13 GMT): bh4rtp (Wed, 06 Jun 2018 06:54:13 GMT): bh4rtp (Wed, 06 Jun 2018 06:55:27 GMT): bh4rtp (Wed, 06 Jun 2018 06:55:27 GMT): wangdong (Wed, 06 Jun 2018 07:04:42 GMT): gauthampamu (Wed, 06 Jun 2018 11:50:33 GMT): rake66 (Wed, 06 Jun 2018 15:16:33 GMT): rake66 (Wed, 06 Jun 2018 15:19:38 GMT): rake66 (Wed, 06 Jun 2018 15:21:28 GMT): rake66 (Wed, 06 Jun 2018 15:22:19 GMT): rake66 (Wed, 06 Jun 2018 15:23:02 GMT): vish146 (Wed, 06 Jun 2018 18:14:07 GMT): bh4rtp (Thu, 07 Jun 2018 03:00:26 GMT): muralisr (Thu, 07 Jun 2018 03:01:25 GMT): muralisr (Thu, 07 Jun 2018 03:01:40 GMT): dave.enyeart (Thu, 07 Jun 2018 04:59:32 GMT): dave.enyeart (Thu, 07 Jun 2018 05:00:16 GMT): header340 (Thu, 07 Jun 2018 17:03:59 GMT): header340 (Thu, 07 Jun 2018 17:16:12 GMT): PawelD (Thu, 07 Jun 2018 19:33:45 GMT): abraham (Fri, 08 Jun 2018 05:41:28 GMT): AbhijeetPal (Fri, 08 Jun 2018 10:17:35 GMT): AbhijeetPal (Fri, 08 Jun 2018 10:17:52 GMT): AbhijeetPal (Fri, 08 Jun 2018 10:19:25 GMT): AbhijeetPal (Fri, 08 Jun 2018 10:19:25 GMT): aatkddny (Fri, 08 Jun 2018 12:55:55 GMT): header340 (Fri, 08 Jun 2018 13:27:17 GMT): header340 (Fri, 08 Jun 2018 13:28:35 GMT): aatkddny (Fri, 08 Jun 2018 14:24:57 GMT): header340 (Fri, 08 Jun 2018 14:29:48 GMT): bh4rtp (Sat, 09 Jun 2018 12:25:38 GMT): bh4rtp (Sat, 09 Jun 2018 12:25:38 GMT): bh4rtp (Sat, 09 Jun 2018 12:25:38 GMT): dave.enyeart (Sun, 10 Jun 2018 09:45:29 GMT): dave.enyeart (Sun, 10 Jun 2018 09:46:48 GMT): dave.enyeart (Sun, 10 Jun 2018 09:47:59 GMT): YashGanthe (Mon, 11 Jun 2018 08:47:53 GMT): AbhijeetPal (Mon, 11 Jun 2018 08:59:34 GMT): aatkddny (Mon, 11 Jun 2018 13:38:17 GMT): aatkddny (Mon, 11 Jun 2018 13:38:17 GMT): aatkddny (Mon, 11 Jun 2018 13:38:17 GMT): rake66 (Mon, 11 Jun 2018 16:09:58 GMT): aatkddny (Mon, 11 Jun 2018 17:18:48 GMT): Ryan2 (Tue, 12 Jun 2018 07:54:19 GMT): rake66 (Tue, 12 Jun 2018 14:14:39 GMT): aatkddny (Tue, 12 Jun 2018 14:19:38 GMT): l1nux (Tue, 12 Jun 2018 17:01:31 GMT): jrosmith (Tue, 12 Jun 2018 18:08:25 GMT): jrosmith (Tue, 12 Jun 2018 18:11:56 GMT): jrosmith (Tue, 12 Jun 2018 18:12:44 GMT): jrosmith (Tue, 12 Jun 2018 18:14:07 GMT): l1nux (Tue, 12 Jun 2018 18:15:39 GMT): jrosmith (Tue, 12 Jun 2018 18:16:43 GMT): yacovm (Tue, 12 Jun 2018 18:18:36 GMT): yacovm (Tue, 12 Jun 2018 18:19:06 GMT): yacovm (Tue, 12 Jun 2018 18:19:17 GMT): aatkddny (Tue, 12 Jun 2018 22:53:08 GMT): Ryan2 (Wed, 13 Jun 2018 01:12:19 GMT): Ryan2 (Wed, 13 Jun 2018 01:12:19 GMT): bh4rtp (Wed, 13 Jun 2018 01:23:22 GMT): manish-sethi (Wed, 13 Jun 2018 03:36:39 GMT): manish-sethi (Wed, 13 Jun 2018 03:36:39 GMT): dave.enyeart (Wed, 13 Jun 2018 04:57:19 GMT): bh4rtp (Wed, 13 Jun 2018 07:35:12 GMT): bh4rtp (Wed, 13 Jun 2018 07:52:22 GMT): Ryan2 (Wed, 13 Jun 2018 08:00:27 GMT): Ryan2 (Wed, 13 Jun 2018 08:00:27 GMT): manish-sethi (Wed, 13 Jun 2018 08:29:13 GMT): Ryan2 (Wed, 13 Jun 2018 08:33:21 GMT): sarapara (Thu, 14 Jun 2018 05:26:48 GMT): Kyroy (Thu, 14 Jun 2018 13:37:08 GMT): jrosmith (Thu, 14 Jun 2018 15:51:45 GMT): dave.enyeart (Thu, 14 Jun 2018 16:58:59 GMT): jrosmith (Thu, 14 Jun 2018 16:59:22 GMT): dave.enyeart (Thu, 14 Jun 2018 16:59:49 GMT): dave.enyeart (Thu, 14 Jun 2018 17:02:53 GMT): gauthampamu (Thu, 14 Jun 2018 21:22:22 GMT): gauthampamu (Thu, 14 Jun 2018 21:22:22 GMT): AnkitSingh5 (Fri, 15 Jun 2018 06:46:58 GMT): paulananth (Fri, 15 Jun 2018 12:19:38 GMT): knagware9 (Fri, 15 Jun 2018 15:44:37 GMT): rsherwood (Fri, 15 Jun 2018 17:08:27 GMT): dave.enyeart (Fri, 15 Jun 2018 18:09:17 GMT): dave.enyeart (Fri, 15 Jun 2018 18:10:53 GMT): bh4rtp (Sat, 16 Jun 2018 13:05:02 GMT): bh4rtp (Sat, 16 Jun 2018 13:05:02 GMT): bh4rtp (Sat, 16 Jun 2018 13:05:02 GMT): bh4rtp (Sat, 16 Jun 2018 13:05:02 GMT): bh4rtp (Sat, 16 Jun 2018 13:05:02 GMT): DuncanMuhoro (Sun, 17 Jun 2018 11:01:27 GMT): nfrunza (Mon, 18 Jun 2018 13:56:16 GMT): Aswath8687 (Mon, 18 Jun 2018 19:18:47 GMT): IgorSim (Tue, 19 Jun 2018 06:49:28 GMT): divyank (Wed, 20 Jun 2018 01:16:27 GMT): hnadim (Wed, 20 Jun 2018 18:39:14 GMT): JackStrohm (Thu, 21 Jun 2018 02:27:51 GMT): tennenjl (Thu, 21 Jun 2018 21:18:02 GMT): nvxtien (Fri, 22 Jun 2018 11:26:50 GMT): DavidPark (Tue, 26 Jun 2018 23:05:00 GMT): alain2sf (Wed, 27 Jun 2018 13:37:11 GMT): adave (Thu, 28 Jun 2018 07:19:20 GMT): mondraymond (Thu, 28 Jun 2018 16:37:30 GMT): sigma67 (Sun, 01 Jul 2018 19:51:01 GMT): aatkddny (Mon, 02 Jul 2018 14:35:08 GMT): aatkddny (Mon, 02 Jul 2018 14:35:08 GMT): yacovm (Mon, 02 Jul 2018 15:30:01 GMT): yacovm (Mon, 02 Jul 2018 15:30:12 GMT): yacovm (Mon, 02 Jul 2018 15:30:20 GMT): knagware9 (Tue, 03 Jul 2018 12:57:33 GMT): suchith.arodi (Tue, 03 Jul 2018 18:24:49 GMT): BabuPallam (Wed, 04 Jul 2018 22:21:00 GMT): aatkddny (Thu, 05 Jul 2018 11:29:06 GMT): yacovm (Thu, 05 Jul 2018 11:30:09 GMT): yacovm (Thu, 05 Jul 2018 11:30:19 GMT): yacovm (Thu, 05 Jul 2018 11:30:36 GMT): aatkddny (Thu, 05 Jul 2018 11:34:04 GMT): aatkddny (Thu, 05 Jul 2018 11:34:42 GMT): yacovm (Thu, 05 Jul 2018 11:34:48 GMT): yacovm (Thu, 05 Jul 2018 11:35:03 GMT): aatkddny (Thu, 05 Jul 2018 11:35:16 GMT): aatkddny (Thu, 05 Jul 2018 11:35:21 GMT): yacovm (Thu, 05 Jul 2018 11:35:24 GMT): aatkddny (Thu, 05 Jul 2018 11:35:55 GMT): yacovm (Thu, 05 Jul 2018 11:36:11 GMT): yacovm (Thu, 05 Jul 2018 11:36:21 GMT): yacovm (Thu, 05 Jul 2018 11:36:37 GMT): aatkddny (Thu, 05 Jul 2018 11:37:21 GMT): yacovm (Thu, 05 Jul 2018 11:37:41 GMT): yacovm (Thu, 05 Jul 2018 11:37:53 GMT): yacovm (Thu, 05 Jul 2018 11:38:07 GMT): aatkddny (Thu, 05 Jul 2018 11:40:45 GMT): aatkddny (Thu, 05 Jul 2018 11:40:45 GMT): yacovm (Thu, 05 Jul 2018 11:41:29 GMT): aatkddny (Thu, 05 Jul 2018 11:41:37 GMT): aatkddny (Thu, 05 Jul 2018 11:41:43 GMT): elciusferreira (Thu, 05 Jul 2018 19:04:20 GMT): ltt1st (Fri, 06 Jul 2018 06:35:20 GMT): adc (Fri, 06 Jul 2018 12:55:33 GMT): sheehan (Fri, 06 Jul 2018 14:21:10 GMT): dave.enyeart (Fri, 06 Jul 2018 14:40:08 GMT): PyiTheinKyaw (Mon, 09 Jul 2018 04:13:45 GMT): PyiTheinKyaw (Mon, 09 Jul 2018 04:14:03 GMT): PyiTheinKyaw (Mon, 09 Jul 2018 04:14:15 GMT): rajivgandhi2010 (Mon, 09 Jul 2018 07:07:57 GMT): adc (Mon, 09 Jul 2018 07:08:47 GMT): yacovm (Mon, 09 Jul 2018 07:43:49 GMT): yacovm (Mon, 09 Jul 2018 07:50:50 GMT): rajivgandhi2010 (Mon, 09 Jul 2018 09:02:07 GMT): dave.enyeart (Mon, 09 Jul 2018 10:34:35 GMT): rajivgandhi2010 (Mon, 09 Jul 2018 10:59:53 GMT): josiebhai (Mon, 09 Jul 2018 13:07:59 GMT): sheehan (Mon, 09 Jul 2018 13:43:02 GMT): xue35 (Wed, 11 Jul 2018 03:30:19 GMT): xue35 (Wed, 11 Jul 2018 03:31:00 GMT): NoLimitHoldem (Wed, 11 Jul 2018 06:17:58 GMT): jayeshjawale95 (Wed, 11 Jul 2018 07:32:27 GMT): adc (Wed, 11 Jul 2018 13:14:23 GMT): WadeLu (Thu, 12 Jul 2018 07:34:34 GMT): ChanderGovindarajan (Fri, 13 Jul 2018 05:31:12 GMT): rsherwood (Tue, 17 Jul 2018 10:46:33 GMT): rsherwood (Tue, 17 Jul 2018 11:31:27 GMT): dave.enyeart (Tue, 17 Jul 2018 12:11:07 GMT): louisliu2048 (Wed, 18 Jul 2018 02:21:14 GMT): madhushreee (Wed, 18 Jul 2018 07:08:50 GMT): samir.tata (Thu, 19 Jul 2018 03:55:49 GMT): rajivgandhi2010 (Thu, 19 Jul 2018 11:40:55 GMT): dave.enyeart (Thu, 19 Jul 2018 11:59:19 GMT): rajivgandhi2010 (Thu, 19 Jul 2018 12:05:58 GMT): richzhao (Thu, 19 Jul 2018 15:05:54 GMT): mwenyan (Thu, 19 Jul 2018 17:25:22 GMT): raccoonrat (Fri, 20 Jul 2018 07:12:36 GMT): SjirNijssen (Fri, 20 Jul 2018 07:44:07 GMT): dave.enyeart (Fri, 20 Jul 2018 11:48:19 GMT): dave.enyeart (Fri, 20 Jul 2018 11:51:12 GMT): richzhao (Fri, 20 Jul 2018 13:11:11 GMT): SjirNijssen (Sat, 21 Jul 2018 19:48:34 GMT): mastreips (Sun, 22 Jul 2018 13:51:51 GMT): anzalbeg (Mon, 23 Jul 2018 10:52:28 GMT): dave.enyeart (Mon, 23 Jul 2018 11:55:53 GMT): Kyroy (Mon, 23 Jul 2018 12:50:09 GMT): Kyroy (Mon, 23 Jul 2018 12:57:27 GMT): sykesm (Mon, 23 Jul 2018 19:29:06 GMT): sykesm (Mon, 23 Jul 2018 19:56:00 GMT): Wilsonli (Tue, 24 Jul 2018 13:47:53 GMT): javrevasandeep (Tue, 24 Jul 2018 14:59:39 GMT): javrevasandeep (Tue, 24 Jul 2018 14:59:39 GMT): fabiomolinar (Tue, 24 Jul 2018 18:12:41 GMT): asaningmaxchain123 (Tue, 24 Jul 2018 18:23:04 GMT): asaningmaxchain123 (Tue, 24 Jul 2018 18:23:04 GMT): asaningmaxchain123 (Tue, 24 Jul 2018 18:23:51 GMT): muralisr (Tue, 24 Jul 2018 18:39:32 GMT): muralisr (Tue, 24 Jul 2018 18:43:14 GMT): muralisr (Tue, 24 Jul 2018 18:43:14 GMT): anarodrigues (Tue, 24 Jul 2018 18:53:26 GMT): anzalbeg (Wed, 25 Jul 2018 06:12:56 GMT): anzalbeg (Wed, 25 Jul 2018 06:13:19 GMT): anzalbeg (Wed, 25 Jul 2018 06:13:20 GMT): anzalbeg (Wed, 25 Jul 2018 06:13:43 GMT): pankajcheema (Wed, 25 Jul 2018 08:41:23 GMT): pankajcheema (Wed, 25 Jul 2018 08:42:10 GMT): pankajcheema (Wed, 25 Jul 2018 08:42:27 GMT): pankajcheema (Wed, 25 Jul 2018 08:42:39 GMT): pankajcheema (Wed, 25 Jul 2018 08:43:00 GMT): pankajcheema (Wed, 25 Jul 2018 08:43:14 GMT): pankajcheema (Wed, 25 Jul 2018 08:43:17 GMT): pankajcheema (Wed, 25 Jul 2018 08:47:36 GMT): pankajcheema (Wed, 25 Jul 2018 08:48:08 GMT): pankajcheema (Wed, 25 Jul 2018 08:48:50 GMT): pankajcheema (Wed, 25 Jul 2018 08:49:50 GMT): pankajcheema (Wed, 25 Jul 2018 08:50:37 GMT): pankajcheema (Wed, 25 Jul 2018 08:51:04 GMT): pankajcheema (Wed, 25 Jul 2018 08:51:04 GMT): pankajcheema (Wed, 25 Jul 2018 08:51:49 GMT): pankajcheema (Wed, 25 Jul 2018 08:55:53 GMT): pankajcheema (Wed, 25 Jul 2018 08:57:18 GMT): pankajcheema (Wed, 25 Jul 2018 08:57:40 GMT): pankajcheema (Wed, 25 Jul 2018 09:10:38 GMT): souvik (Wed, 25 Jul 2018 11:48:24 GMT): rsherwood (Thu, 26 Jul 2018 08:06:07 GMT): naviat (Thu, 26 Jul 2018 09:02:07 GMT): aatkddny (Thu, 26 Jul 2018 11:20:03 GMT): dave.enyeart (Thu, 26 Jul 2018 12:35:09 GMT): rsherwood (Thu, 26 Jul 2018 14:33:39 GMT): dave.enyeart (Thu, 26 Jul 2018 14:35:23 GMT): dave.enyeart (Thu, 26 Jul 2018 14:35:23 GMT): minollo (Thu, 26 Jul 2018 15:40:50 GMT): manish-sethi (Thu, 26 Jul 2018 15:57:27 GMT): minollo (Thu, 26 Jul 2018 16:00:54 GMT): manish-sethi (Thu, 26 Jul 2018 16:05:12 GMT): minollo (Thu, 26 Jul 2018 16:05:46 GMT): manish-sethi (Thu, 26 Jul 2018 16:06:45 GMT): minollo (Thu, 26 Jul 2018 16:07:47 GMT): manish-sethi (Thu, 26 Jul 2018 16:07:56 GMT): minollo (Thu, 26 Jul 2018 16:08:29 GMT): minollo (Thu, 26 Jul 2018 16:08:44 GMT): manish-sethi (Thu, 26 Jul 2018 16:09:25 GMT): minollo (Thu, 26 Jul 2018 16:10:36 GMT): minollo (Thu, 26 Jul 2018 16:10:48 GMT): manish-sethi (Thu, 26 Jul 2018 16:11:06 GMT): minollo (Thu, 26 Jul 2018 16:11:49 GMT): manish-sethi (Thu, 26 Jul 2018 16:12:00 GMT): jakereps (Thu, 26 Jul 2018 18:54:01 GMT): Kyroy (Fri, 27 Jul 2018 17:54:58 GMT): jrosmith (Mon, 30 Jul 2018 14:28:06 GMT): dave.enyeart (Mon, 30 Jul 2018 14:53:47 GMT): dave.enyeart (Mon, 30 Jul 2018 14:54:27 GMT): dave.enyeart (Mon, 30 Jul 2018 14:54:41 GMT): jrosmith (Mon, 30 Jul 2018 14:58:05 GMT): jrosmith (Mon, 30 Jul 2018 14:59:32 GMT): dave.enyeart (Mon, 30 Jul 2018 14:59:40 GMT): dave.enyeart (Mon, 30 Jul 2018 15:00:49 GMT): dave.enyeart (Mon, 30 Jul 2018 15:00:54 GMT): jrosmith (Mon, 30 Jul 2018 15:01:10 GMT): dave.enyeart (Mon, 30 Jul 2018 15:01:13 GMT): pankajcheema (Tue, 31 Jul 2018 16:04:56 GMT): dave.enyeart (Tue, 31 Jul 2018 16:49:39 GMT): dave.enyeart (Tue, 31 Jul 2018 16:49:39 GMT): dave.enyeart (Tue, 31 Jul 2018 16:49:39 GMT): jrosmith (Tue, 31 Jul 2018 19:29:38 GMT): jrosmith (Tue, 31 Jul 2018 19:29:38 GMT): jrosmith (Tue, 31 Jul 2018 19:29:38 GMT): jrosmith (Tue, 31 Jul 2018 19:29:38 GMT): jrosmith (Tue, 31 Jul 2018 19:29:38 GMT): BoBoGithub (Thu, 02 Aug 2018 02:03:31 GMT): username343 (Thu, 02 Aug 2018 03:55:35 GMT): username343 (Thu, 02 Aug 2018 03:55:55 GMT): username343 (Thu, 02 Aug 2018 03:55:55 GMT): username343 (Thu, 02 Aug 2018 03:55:55 GMT): username343 (Thu, 02 Aug 2018 03:55:57 GMT): Ryan2 (Thu, 02 Aug 2018 07:53:07 GMT): dave.enyeart (Thu, 02 Aug 2018 10:59:27 GMT): Ryan2 (Thu, 02 Aug 2018 13:19:42 GMT): dave.enyeart (Thu, 02 Aug 2018 13:28:52 GMT): dave.enyeart (Thu, 02 Aug 2018 16:58:40 GMT): jrosmith (Thu, 02 Aug 2018 19:41:49 GMT): bh4rtp (Fri, 03 Aug 2018 00:47:23 GMT): username343 (Fri, 03 Aug 2018 05:21:03 GMT): username343 (Fri, 03 Aug 2018 05:21:39 GMT): username343 (Fri, 03 Aug 2018 05:22:36 GMT): username343 (Fri, 03 Aug 2018 05:22:38 GMT): username343 (Fri, 03 Aug 2018 05:22:38 GMT): username343 (Fri, 03 Aug 2018 05:24:51 GMT): username343 (Fri, 03 Aug 2018 05:24:56 GMT): pankajcheema (Fri, 03 Aug 2018 09:10:12 GMT): pankajcheema (Fri, 03 Aug 2018 09:11:02 GMT): pankajcheema (Fri, 03 Aug 2018 09:11:19 GMT): pankajcheema (Fri, 03 Aug 2018 09:11:29 GMT): pankajcheema (Fri, 03 Aug 2018 09:11:42 GMT): pankajcheema (Fri, 03 Aug 2018 09:12:00 GMT): pankajcheema (Fri, 03 Aug 2018 09:12:01 GMT): pankajcheema (Fri, 03 Aug 2018 09:12:29 GMT): pankajcheema (Fri, 03 Aug 2018 09:12:36 GMT): pankajcheema (Fri, 03 Aug 2018 09:13:14 GMT): pankajcheema (Fri, 03 Aug 2018 09:15:23 GMT): Gaurav6794 (Fri, 03 Aug 2018 11:49:06 GMT): Gaurav6794 (Fri, 03 Aug 2018 11:49:23 GMT): Gaurav6794 (Fri, 03 Aug 2018 11:49:23 GMT): Gaurav6794 (Fri, 03 Aug 2018 11:49:23 GMT): Gaurav6794 (Fri, 03 Aug 2018 11:49:23 GMT): Gaurav6794 (Fri, 03 Aug 2018 11:49:23 GMT): Gaurav6794 (Fri, 03 Aug 2018 11:49:23 GMT): Gaurav6794 (Fri, 03 Aug 2018 11:49:23 GMT): Gaurav6794 (Fri, 03 Aug 2018 11:49:23 GMT): thakurnikk (Fri, 03 Aug 2018 12:06:31 GMT): manish-sethi (Fri, 03 Aug 2018 13:38:35 GMT): manish-sethi (Fri, 03 Aug 2018 13:46:31 GMT): dave.enyeart (Fri, 03 Aug 2018 15:10:00 GMT): dave.enyeart (Fri, 03 Aug 2018 15:10:00 GMT): dave.enyeart (Fri, 03 Aug 2018 15:10:09 GMT): zmaro (Fri, 03 Aug 2018 15:21:29 GMT): pankajcheema (Fri, 03 Aug 2018 16:22:08 GMT): pankajcheema (Fri, 03 Aug 2018 16:25:45 GMT): dave.enyeart (Fri, 03 Aug 2018 16:53:21 GMT): nfrunza (Fri, 03 Aug 2018 21:07:36 GMT): akshay.sood (Sat, 04 Aug 2018 06:47:45 GMT): pankajcheema (Sat, 04 Aug 2018 15:25:01 GMT): MeghaGupta (Sat, 04 Aug 2018 15:25:01 GMT): pankajcheema (Sat, 04 Aug 2018 15:40:23 GMT): pankajcheema (Sat, 04 Aug 2018 19:15:11 GMT): pankajcheema (Sat, 04 Aug 2018 19:15:39 GMT): pankajcheema (Sat, 04 Aug 2018 19:15:44 GMT): dave.enyeart (Sat, 04 Aug 2018 21:01:36 GMT): dave.enyeart (Sat, 04 Aug 2018 21:02:29 GMT): pankajcheema (Sun, 05 Aug 2018 07:10:55 GMT): dave.enyeart (Sun, 05 Aug 2018 12:17:42 GMT): bh4rtp (Sun, 05 Aug 2018 12:39:26 GMT): dave.enyeart (Sun, 05 Aug 2018 12:40:58 GMT): guoger (Mon, 06 Aug 2018 02:19:40 GMT): manish-sethi (Mon, 06 Aug 2018 02:20:31 GMT): rahulhegde (Mon, 06 Aug 2018 02:58:45 GMT): rahulhegde (Mon, 06 Aug 2018 02:58:45 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:23:26 GMT): dave.enyeart (Mon, 06 Aug 2018 13:25:02 GMT): dave.enyeart (Mon, 06 Aug 2018 13:25:38 GMT): dave.enyeart (Mon, 06 Aug 2018 13:25:38 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:28:41 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:29:39 GMT): dave.enyeart (Mon, 06 Aug 2018 13:30:19 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:31:13 GMT): dave.enyeart (Mon, 06 Aug 2018 13:31:56 GMT): dave.enyeart (Mon, 06 Aug 2018 13:32:45 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:35:22 GMT): dave.enyeart (Mon, 06 Aug 2018 13:38:21 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:42:16 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:43:02 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:43:17 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:44:18 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:44:26 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:44:49 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:45:18 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:45:21 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:46:39 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:46:44 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:46:54 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:47:31 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:55:17 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:55:27 GMT): dave.enyeart (Mon, 06 Aug 2018 13:59:07 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 13:59:56 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 14:00:50 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 14:01:13 GMT): manish-sethi (Mon, 06 Aug 2018 14:12:39 GMT): asaningmaxchain123 (Mon, 06 Aug 2018 16:17:03 GMT): rahulhegde (Mon, 06 Aug 2018 18:45:18 GMT): rahulhegde (Mon, 06 Aug 2018 18:45:18 GMT): dave.enyeart (Mon, 06 Aug 2018 18:56:05 GMT): dave.enyeart (Mon, 06 Aug 2018 18:56:05 GMT): rahulhegde (Tue, 07 Aug 2018 03:11:01 GMT): username343 (Tue, 07 Aug 2018 10:22:56 GMT): username343 (Wed, 08 Aug 2018 05:04:03 GMT): username343 (Wed, 08 Aug 2018 05:04:20 GMT): username343 (Wed, 08 Aug 2018 05:04:25 GMT): username343 (Wed, 08 Aug 2018 05:04:36 GMT): username343 (Wed, 08 Aug 2018 05:04:42 GMT): username343 (Wed, 08 Aug 2018 05:04:46 GMT): username343 (Wed, 08 Aug 2018 05:05:04 GMT): dave.enyeart (Wed, 08 Aug 2018 10:46:04 GMT): username343 (Wed, 08 Aug 2018 12:39:11 GMT): alek (Thu, 09 Aug 2018 08:11:22 GMT): rajivgandhi2010 (Thu, 09 Aug 2018 12:46:46 GMT): rajivgandhi2010 (Thu, 09 Aug 2018 12:51:09 GMT): C0rWin (Thu, 09 Aug 2018 14:20:01 GMT): rajivgandhi2010 (Fri, 10 Aug 2018 05:33:15 GMT): C0rWin (Sun, 12 Aug 2018 13:14:02 GMT): pankaj9310 (Mon, 13 Aug 2018 14:48:08 GMT): VipinB (Mon, 13 Aug 2018 21:18:09 GMT): asaningmaxchain123 (Wed, 15 Aug 2018 13:51:52 GMT): dileban (Thu, 16 Aug 2018 23:26:16 GMT): dileban (Thu, 16 Aug 2018 23:31:46 GMT): yacovm (Thu, 16 Aug 2018 23:34:02 GMT): dileban (Thu, 16 Aug 2018 23:36:01 GMT): dileban (Thu, 16 Aug 2018 23:36:01 GMT): dileban (Thu, 16 Aug 2018 23:36:01 GMT): yacovm (Thu, 16 Aug 2018 23:40:15 GMT): dileban (Thu, 16 Aug 2018 23:47:15 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:39:30 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:39:30 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:39:30 GMT): dave.enyeart (Fri, 17 Aug 2018 15:40:37 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:41:12 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:41:30 GMT): dave.enyeart (Fri, 17 Aug 2018 15:41:39 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:42:28 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:43:21 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:43:23 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:43:33 GMT): dave.enyeart (Fri, 17 Aug 2018 15:45:08 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:45:36 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:46:03 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:46:14 GMT): dave.enyeart (Fri, 17 Aug 2018 15:46:29 GMT): dave.enyeart (Fri, 17 Aug 2018 15:46:29 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:46:57 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:47:13 GMT): dave.enyeart (Fri, 17 Aug 2018 15:49:15 GMT): dave.enyeart (Fri, 17 Aug 2018 15:49:19 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:49:28 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:49:37 GMT): dave.enyeart (Fri, 17 Aug 2018 15:49:40 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:50:05 GMT): dave.enyeart (Fri, 17 Aug 2018 15:51:00 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:51:48 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:51:48 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:53:16 GMT): dave.enyeart (Fri, 17 Aug 2018 15:53:41 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:54:17 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:54:17 GMT): dave.enyeart (Fri, 17 Aug 2018 15:54:42 GMT): dave.enyeart (Fri, 17 Aug 2018 15:55:21 GMT): asaningmaxchain123 (Fri, 17 Aug 2018 15:56:35 GMT): dave.enyeart (Fri, 17 Aug 2018 15:57:01 GMT): minollo (Sat, 18 Aug 2018 00:53:51 GMT): rsherwood (Mon, 20 Aug 2018 09:10:46 GMT): dave.enyeart (Mon, 20 Aug 2018 11:22:17 GMT): manish-sethi (Mon, 20 Aug 2018 12:49:55 GMT): OviiyaDominic (Tue, 21 Aug 2018 09:22:17 GMT): bdjidi (Tue, 21 Aug 2018 22:48:28 GMT): Akash-digiledge (Thu, 23 Aug 2018 07:41:07 GMT): Akash-digiledge (Thu, 23 Aug 2018 07:42:15 GMT): dave.enyeart (Thu, 23 Aug 2018 09:49:28 GMT): tom.appleyard (Thu, 23 Aug 2018 17:50:50 GMT): tom.appleyard (Thu, 23 Aug 2018 17:52:02 GMT): tom.appleyard (Thu, 23 Aug 2018 17:52:02 GMT): tom.appleyard (Thu, 23 Aug 2018 17:53:07 GMT): tom.appleyard (Thu, 23 Aug 2018 17:53:14 GMT): dave.enyeart (Thu, 23 Aug 2018 18:32:17 GMT): ErmyasTeshome (Fri, 24 Aug 2018 00:55:50 GMT): tom.appleyard (Fri, 24 Aug 2018 09:14:47 GMT): tom.appleyard (Fri, 24 Aug 2018 09:15:34 GMT): tom.appleyard (Fri, 24 Aug 2018 09:25:16 GMT): tom.appleyard (Fri, 24 Aug 2018 09:25:16 GMT): tom.appleyard (Fri, 24 Aug 2018 09:25:16 GMT): tom.appleyard (Fri, 24 Aug 2018 09:25:16 GMT): tom.appleyard (Fri, 24 Aug 2018 09:25:16 GMT): tom.appleyard (Fri, 24 Aug 2018 09:25:23 GMT): tom.appleyard (Fri, 24 Aug 2018 09:25:23 GMT): tom.appleyard (Fri, 24 Aug 2018 09:25:23 GMT): tom.appleyard (Fri, 24 Aug 2018 09:27:04 GMT): tom.appleyard (Fri, 24 Aug 2018 09:27:12 GMT): tom.appleyard (Fri, 24 Aug 2018 09:27:19 GMT): dave.enyeart (Fri, 24 Aug 2018 11:15:07 GMT): SarahM (Sat, 25 Aug 2018 17:45:53 GMT): yacovm (Sun, 26 Aug 2018 20:17:12 GMT): yacovm (Sun, 26 Aug 2018 20:17:29 GMT): yacovm (Sun, 26 Aug 2018 20:18:35 GMT): yacovm (Sun, 26 Aug 2018 20:19:11 GMT): yacovm (Sun, 26 Aug 2018 20:19:11 GMT): FaizulHassan (Mon, 27 Aug 2018 09:11:39 GMT): FaizulHassan (Mon, 27 Aug 2018 09:15:41 GMT): dave.enyeart (Mon, 27 Aug 2018 09:32:58 GMT): FaizulHassan (Mon, 27 Aug 2018 09:43:42 GMT): FaizulHassan (Mon, 27 Aug 2018 09:43:42 GMT): nicolas.alfonso (Mon, 27 Aug 2018 22:48:33 GMT): nicolas.alfonso (Mon, 27 Aug 2018 22:48:46 GMT): qiangjiyi (Tue, 28 Aug 2018 02:11:09 GMT): jdfigure (Thu, 30 Aug 2018 17:48:37 GMT): Akash-digiledge (Fri, 31 Aug 2018 07:14:37 GMT): dave.enyeart (Fri, 31 Aug 2018 09:10:00 GMT): nfrunza (Fri, 31 Aug 2018 16:24:27 GMT): sureshtedla (Fri, 31 Aug 2018 16:24:42 GMT): Akash-digiledge (Mon, 03 Sep 2018 09:10:40 GMT): demonkm (Mon, 03 Sep 2018 09:22:01 GMT): FaizulHassan (Wed, 05 Sep 2018 06:23:52 GMT): adarshsaraf123 (Wed, 05 Sep 2018 08:31:27 GMT): FaizulHassan (Wed, 05 Sep 2018 09:01:55 GMT): aatkddny (Wed, 05 Sep 2018 15:53:10 GMT): aatkddny (Wed, 05 Sep 2018 15:53:10 GMT): aatkddny (Wed, 05 Sep 2018 15:53:10 GMT): asaningmaxchain123 (Thu, 06 Sep 2018 15:18:18 GMT): asaningmaxchain123 (Thu, 06 Sep 2018 15:18:25 GMT): asaningmaxchain123 (Thu, 06 Sep 2018 16:20:51 GMT): asaningmaxchain123 (Thu, 06 Sep 2018 16:20:51 GMT): dave.enyeart (Thu, 06 Sep 2018 16:51:36 GMT): dave.enyeart (Thu, 06 Sep 2018 16:54:23 GMT): jyellick (Thu, 06 Sep 2018 18:24:50 GMT): jyellick (Thu, 06 Sep 2018 18:25:26 GMT): asaningmaxchain123 (Thu, 06 Sep 2018 23:33:24 GMT): asaningmaxchain123 (Thu, 06 Sep 2018 23:33:27 GMT): yousaf (Sat, 08 Sep 2018 14:30:42 GMT): raviyelleni (Sun, 09 Sep 2018 04:45:13 GMT): Larisaa (Tue, 11 Sep 2018 07:24:40 GMT): tennenjl (Wed, 12 Sep 2018 14:40:51 GMT): dave.enyeart (Wed, 12 Sep 2018 15:33:53 GMT): tennenjl (Thu, 13 Sep 2018 01:28:14 GMT): JaydipMakadia (Thu, 13 Sep 2018 13:11:35 GMT): Jgnuid (Sat, 15 Sep 2018 19:38:48 GMT): Jgnuid (Sat, 15 Sep 2018 19:38:54 GMT): Jgnuid (Sat, 15 Sep 2018 19:39:03 GMT): Jgnuid (Sat, 15 Sep 2018 19:40:06 GMT): Jgnuid (Sat, 15 Sep 2018 19:40:46 GMT): Jgnuid (Sat, 15 Sep 2018 19:41:25 GMT): Jgnuid (Sat, 15 Sep 2018 19:41:51 GMT): Jgnuid (Sat, 15 Sep 2018 19:42:15 GMT): Jgnuid (Sat, 15 Sep 2018 19:42:41 GMT): Jgnuid (Sat, 15 Sep 2018 19:42:59 GMT): Jgnuid (Sat, 15 Sep 2018 19:43:26 GMT): yacovm (Sat, 15 Sep 2018 19:53:39 GMT): Jgnuid (Sat, 15 Sep 2018 19:56:02 GMT): Jgnuid (Sat, 15 Sep 2018 19:56:28 GMT): Jgnuid (Sat, 15 Sep 2018 19:56:38 GMT): yacovm (Sat, 15 Sep 2018 19:56:53 GMT): yacovm (Sat, 15 Sep 2018 19:57:11 GMT): Jgnuid (Sat, 15 Sep 2018 19:57:14 GMT): yacovm (Sat, 15 Sep 2018 19:57:15 GMT): Jgnuid (Sat, 15 Sep 2018 19:57:38 GMT): Jgnuid (Sat, 15 Sep 2018 19:57:46 GMT): yacovm (Sat, 15 Sep 2018 19:57:54 GMT): yacovm (Sat, 15 Sep 2018 19:58:01 GMT): yacovm (Sat, 15 Sep 2018 19:58:14 GMT): yacovm (Sat, 15 Sep 2018 19:58:29 GMT): yacovm (Sat, 15 Sep 2018 19:58:38 GMT): Jgnuid (Sat, 15 Sep 2018 20:00:00 GMT): yacovm (Sat, 15 Sep 2018 20:00:14 GMT): Jgnuid (Sat, 15 Sep 2018 20:00:53 GMT): Jgnuid (Sat, 15 Sep 2018 20:01:00 GMT): yacovm (Sat, 15 Sep 2018 20:01:15 GMT): Jgnuid (Sat, 15 Sep 2018 20:01:54 GMT): yacovm (Sat, 15 Sep 2018 20:01:55 GMT): yacovm (Sat, 15 Sep 2018 20:02:04 GMT): yacovm (Sat, 15 Sep 2018 20:02:15 GMT): yacovm (Sat, 15 Sep 2018 20:02:24 GMT): yacovm (Sat, 15 Sep 2018 20:02:48 GMT): Jgnuid (Sat, 15 Sep 2018 20:03:43 GMT): yacovm (Sat, 15 Sep 2018 20:03:49 GMT): yacovm (Sat, 15 Sep 2018 20:03:58 GMT): yacovm (Sat, 15 Sep 2018 20:04:22 GMT): yacovm (Sat, 15 Sep 2018 20:04:29 GMT): yacovm (Sat, 15 Sep 2018 20:04:35 GMT): yacovm (Sat, 15 Sep 2018 20:04:45 GMT): yacovm (Sat, 15 Sep 2018 20:04:51 GMT): Jgnuid (Sat, 15 Sep 2018 20:05:08 GMT): yacovm (Sat, 15 Sep 2018 20:05:09 GMT): yacovm (Sat, 15 Sep 2018 20:05:24 GMT): Jgnuid (Sat, 15 Sep 2018 20:05:46 GMT): yacovm (Sat, 15 Sep 2018 20:05:57 GMT): Jgnuid (Sat, 15 Sep 2018 20:06:20 GMT): Jgnuid (Sat, 15 Sep 2018 20:06:40 GMT): yacovm (Sat, 15 Sep 2018 20:07:01 GMT): Jgnuid (Sat, 15 Sep 2018 20:07:30 GMT): yacovm (Sat, 15 Sep 2018 20:07:35 GMT): Jgnuid (Sat, 15 Sep 2018 20:08:24 GMT): yacovm (Sat, 15 Sep 2018 20:08:51 GMT): yacovm (Sat, 15 Sep 2018 20:09:06 GMT): Jgnuid (Sat, 15 Sep 2018 20:09:11 GMT): Jgnuid (Sat, 15 Sep 2018 20:09:28 GMT): Jgnuid (Sat, 15 Sep 2018 20:09:54 GMT): Jgnuid (Sat, 15 Sep 2018 20:10:29 GMT): Jgnuid (Sat, 15 Sep 2018 20:10:40 GMT): Jgnuid (Sat, 15 Sep 2018 20:10:57 GMT): Jgnuid (Sat, 15 Sep 2018 20:11:26 GMT): Jgnuid (Sat, 15 Sep 2018 20:12:50 GMT): dave.enyeart (Sun, 16 Sep 2018 14:45:08 GMT): Jgnuid (Sun, 16 Sep 2018 15:28:00 GMT): dave.enyeart (Sun, 16 Sep 2018 15:38:17 GMT): dave.enyeart (Sun, 16 Sep 2018 15:38:17 GMT): Jgnuid (Sun, 16 Sep 2018 15:42:22 GMT): Jgnuid (Sun, 16 Sep 2018 15:47:03 GMT): Jgnuid (Sun, 16 Sep 2018 15:47:18 GMT): Jgnuid (Sun, 16 Sep 2018 15:48:25 GMT): Jgnuid (Sun, 16 Sep 2018 15:48:25 GMT): Jgnuid (Sun, 16 Sep 2018 15:49:44 GMT): Jgnuid (Sun, 16 Sep 2018 15:49:44 GMT): aatkddny (Mon, 17 Sep 2018 17:19:29 GMT): waxer (Mon, 17 Sep 2018 17:20:35 GMT): Jgnuid (Mon, 17 Sep 2018 17:24:36 GMT): Jgnuid (Mon, 17 Sep 2018 17:24:36 GMT): dave.enyeart (Mon, 17 Sep 2018 21:28:30 GMT): aatkddny (Tue, 18 Sep 2018 01:23:03 GMT): Jgnuid (Tue, 18 Sep 2018 01:33:32 GMT): Jgnuid (Tue, 18 Sep 2018 01:34:47 GMT): Jgnuid (Tue, 18 Sep 2018 01:35:16 GMT): Jgnuid (Tue, 18 Sep 2018 01:35:46 GMT): Jgnuid (Tue, 18 Sep 2018 01:37:43 GMT): manish-sethi (Tue, 18 Sep 2018 01:42:56 GMT): Jgnuid (Tue, 18 Sep 2018 01:44:56 GMT): manish-sethi (Tue, 18 Sep 2018 01:46:32 GMT): aatkddny (Tue, 18 Sep 2018 14:31:23 GMT): aatkddny (Tue, 18 Sep 2018 14:31:44 GMT): aatkddny (Tue, 18 Sep 2018 14:32:02 GMT): aatkddny (Tue, 18 Sep 2018 14:32:14 GMT): dave.enyeart (Tue, 18 Sep 2018 14:54:52 GMT): dave.enyeart (Tue, 18 Sep 2018 14:55:00 GMT): aatkddny (Tue, 18 Sep 2018 14:55:06 GMT): aatkddny (Tue, 18 Sep 2018 14:55:17 GMT): dave.enyeart (Tue, 18 Sep 2018 14:55:33 GMT): dave.enyeart (Tue, 18 Sep 2018 14:56:07 GMT): aatkddny (Tue, 18 Sep 2018 14:56:41 GMT): dave.enyeart (Tue, 18 Sep 2018 14:57:15 GMT): aatkddny (Tue, 18 Sep 2018 14:57:26 GMT): aatkddny (Tue, 18 Sep 2018 14:58:23 GMT): aatkddny (Tue, 18 Sep 2018 14:58:23 GMT): rickr (Tue, 18 Sep 2018 15:01:30 GMT): rickr (Tue, 18 Sep 2018 15:02:16 GMT): aatkddny (Tue, 18 Sep 2018 15:03:31 GMT): aatkddny (Tue, 18 Sep 2018 15:10:37 GMT): dave.enyeart (Tue, 18 Sep 2018 15:10:40 GMT): dave.enyeart (Tue, 18 Sep 2018 15:10:40 GMT): rickr (Tue, 18 Sep 2018 15:11:27 GMT): aatkddny (Tue, 18 Sep 2018 15:12:43 GMT): aatkddny (Wed, 19 Sep 2018 00:33:40 GMT): dave.enyeart (Wed, 19 Sep 2018 00:37:00 GMT): aatkddny (Wed, 19 Sep 2018 00:42:34 GMT): aatkddny (Wed, 19 Sep 2018 00:42:34 GMT): aatkddny (Wed, 19 Sep 2018 00:42:34 GMT): aatkddny (Wed, 19 Sep 2018 00:42:34 GMT): dave.enyeart (Wed, 19 Sep 2018 00:43:50 GMT): yousaf (Wed, 19 Sep 2018 18:46:08 GMT): dave.enyeart (Wed, 19 Sep 2018 19:11:25 GMT): dave.enyeart (Wed, 19 Sep 2018 23:58:30 GMT): plato (Wed, 19 Sep 2018 23:58:30 GMT): dave.enyeart (Thu, 20 Sep 2018 00:02:36 GMT): plato (Thu, 20 Sep 2018 00:02:47 GMT): dave.enyeart (Thu, 20 Sep 2018 00:04:33 GMT): plato (Thu, 20 Sep 2018 00:04:50 GMT): dave.enyeart (Thu, 20 Sep 2018 00:09:52 GMT): dave.enyeart (Thu, 20 Sep 2018 00:11:03 GMT): plato (Thu, 20 Sep 2018 00:14:29 GMT): dave.enyeart (Thu, 20 Sep 2018 00:18:34 GMT): plato (Thu, 20 Sep 2018 00:24:46 GMT): dave.enyeart (Thu, 20 Sep 2018 01:43:57 GMT): dave.enyeart (Thu, 20 Sep 2018 01:44:24 GMT): Shyam_Pratap_Singh (Thu, 20 Sep 2018 06:26:13 GMT): yousaf (Thu, 20 Sep 2018 11:41:40 GMT): GuillaumeTong (Fri, 21 Sep 2018 01:22:14 GMT): GuillaumeTong (Fri, 21 Sep 2018 01:26:39 GMT): GuillaumeTong (Fri, 21 Sep 2018 01:26:39 GMT): GuillaumeTong (Fri, 21 Sep 2018 01:28:39 GMT): GuillaumeTong (Fri, 21 Sep 2018 08:10:45 GMT): manish-sethi (Fri, 21 Sep 2018 16:55:48 GMT): dave.enyeart (Fri, 21 Sep 2018 17:27:33 GMT): dave.enyeart (Fri, 21 Sep 2018 17:29:02 GMT): dave.enyeart (Fri, 21 Sep 2018 17:34:31 GMT): yousaf (Sat, 22 Sep 2018 08:12:04 GMT): Wizzy123 (Sun, 23 Sep 2018 13:46:46 GMT): Wizzy123 (Sun, 23 Sep 2018 13:47:49 GMT): dave.enyeart (Sun, 23 Sep 2018 16:16:47 GMT): GuillaumeTong (Mon, 24 Sep 2018 01:15:39 GMT): GuillaumeTong (Mon, 24 Sep 2018 01:17:43 GMT): manish-sethi (Mon, 24 Sep 2018 02:46:01 GMT): dave.enyeart (Mon, 24 Sep 2018 02:50:43 GMT): GuillaumeTong (Mon, 24 Sep 2018 03:05:36 GMT): GuillaumeTong (Mon, 24 Sep 2018 04:53:15 GMT): manish-sethi (Mon, 24 Sep 2018 04:54:34 GMT): GuillaumeTong (Mon, 24 Sep 2018 04:55:11 GMT): manish-sethi (Mon, 24 Sep 2018 04:56:19 GMT): yousaf (Mon, 24 Sep 2018 07:38:45 GMT): waxer (Mon, 24 Sep 2018 19:29:17 GMT): waxer (Mon, 24 Sep 2018 19:29:55 GMT): waxer (Mon, 24 Sep 2018 19:32:15 GMT): yacovm (Mon, 24 Sep 2018 20:05:47 GMT): yacovm (Mon, 24 Sep 2018 20:06:21 GMT): yacovm (Mon, 24 Sep 2018 20:06:21 GMT): waxer (Mon, 24 Sep 2018 20:07:28 GMT): yacovm (Mon, 24 Sep 2018 20:16:04 GMT): waxer (Mon, 24 Sep 2018 20:18:32 GMT): yacovm (Mon, 24 Sep 2018 20:18:53 GMT): yacovm (Mon, 24 Sep 2018 20:19:00 GMT): yacovm (Mon, 24 Sep 2018 20:19:24 GMT): yacovm (Mon, 24 Sep 2018 20:19:53 GMT): yacovm (Mon, 24 Sep 2018 20:20:09 GMT): yacovm (Mon, 24 Sep 2018 20:20:21 GMT): waxer (Mon, 24 Sep 2018 20:22:27 GMT): waxer (Mon, 24 Sep 2018 20:22:44 GMT): yacovm (Mon, 24 Sep 2018 20:23:15 GMT): waxer (Mon, 24 Sep 2018 20:23:20 GMT): yacovm (Mon, 24 Sep 2018 20:23:46 GMT): yacovm (Mon, 24 Sep 2018 20:24:03 GMT): waxer (Mon, 24 Sep 2018 20:24:28 GMT): yacovm (Mon, 24 Sep 2018 20:24:45 GMT): waxer (Mon, 24 Sep 2018 20:25:07 GMT): waxer (Mon, 24 Sep 2018 20:25:25 GMT): yacovm (Mon, 24 Sep 2018 20:25:29 GMT): yacovm (Mon, 24 Sep 2018 20:25:29 GMT): yacovm (Mon, 24 Sep 2018 20:26:37 GMT): waxer (Mon, 24 Sep 2018 20:27:38 GMT): waxer (Mon, 24 Sep 2018 20:27:47 GMT): waxer (Mon, 24 Sep 2018 20:27:53 GMT): yacovm (Mon, 24 Sep 2018 20:28:07 GMT): waxer (Mon, 24 Sep 2018 20:29:16 GMT): waxer (Mon, 24 Sep 2018 20:29:22 GMT): yacovm (Mon, 24 Sep 2018 20:29:44 GMT): waxer (Mon, 24 Sep 2018 20:30:13 GMT): yacovm (Mon, 24 Sep 2018 20:30:30 GMT): yacovm (Mon, 24 Sep 2018 20:30:45 GMT): waxer (Mon, 24 Sep 2018 20:32:05 GMT): waxer (Mon, 24 Sep 2018 20:33:45 GMT): yacovm (Mon, 24 Sep 2018 20:33:46 GMT): yacovm (Mon, 24 Sep 2018 20:34:07 GMT): yacovm (Mon, 24 Sep 2018 20:34:42 GMT): waxer (Mon, 24 Sep 2018 20:35:38 GMT): waxer (Mon, 24 Sep 2018 20:35:52 GMT): yacovm (Mon, 24 Sep 2018 20:37:18 GMT): yacovm (Mon, 24 Sep 2018 20:37:47 GMT): yacovm (Mon, 24 Sep 2018 20:37:55 GMT): waxer (Mon, 24 Sep 2018 20:38:17 GMT): yacovm (Mon, 24 Sep 2018 20:38:52 GMT): waxer (Mon, 24 Sep 2018 20:39:52 GMT): waxer (Mon, 24 Sep 2018 20:40:06 GMT): waxer (Mon, 24 Sep 2018 20:40:19 GMT): waxer (Mon, 24 Sep 2018 20:41:23 GMT): yacovm (Mon, 24 Sep 2018 20:44:10 GMT): yacovm (Mon, 24 Sep 2018 20:44:37 GMT): yacovm (Mon, 24 Sep 2018 20:44:53 GMT): yacovm (Mon, 24 Sep 2018 20:45:48 GMT): waxer (Mon, 24 Sep 2018 20:49:47 GMT): yacovm (Mon, 24 Sep 2018 21:12:29 GMT): yacovm (Mon, 24 Sep 2018 21:13:46 GMT): waxer (Mon, 24 Sep 2018 21:17:42 GMT): aatkddny (Tue, 25 Sep 2018 00:32:33 GMT): Ferrymania (Tue, 25 Sep 2018 02:48:14 GMT): Ferrymania (Tue, 25 Sep 2018 02:50:42 GMT): MikeyGarcia (Tue, 25 Sep 2018 13:17:39 GMT): qsmen (Wed, 26 Sep 2018 03:05:25 GMT): NoLimitHoldem (Fri, 28 Sep 2018 09:40:44 GMT): NoLimitHoldem (Fri, 28 Sep 2018 09:40:51 GMT): NoLimitHoldem (Fri, 28 Sep 2018 09:40:51 GMT): BlackMesa (Fri, 28 Sep 2018 17:23:33 GMT): zacpl (Fri, 28 Sep 2018 18:37:57 GMT): MeenakshiSingh (Fri, 28 Sep 2018 18:47:43 GMT): jrosmith (Fri, 28 Sep 2018 20:26:12 GMT): HoneyShah (Tue, 02 Oct 2018 09:26:22 GMT): HoneyShah (Tue, 02 Oct 2018 09:27:07 GMT): dave.enyeart (Tue, 02 Oct 2018 11:37:04 GMT): dave.enyeart (Tue, 02 Oct 2018 11:37:14 GMT): dave.enyeart (Tue, 02 Oct 2018 11:37:40 GMT): tennenjl (Wed, 03 Oct 2018 02:26:21 GMT): dave.enyeart (Wed, 03 Oct 2018 02:54:34 GMT): dave.enyeart (Wed, 03 Oct 2018 02:56:38 GMT): dave.enyeart (Wed, 03 Oct 2018 02:56:38 GMT): tennenjl (Wed, 03 Oct 2018 03:30:54 GMT): MaddaliPadmaja (Wed, 03 Oct 2018 07:14:48 GMT): mrjdomingus (Thu, 04 Oct 2018 08:13:03 GMT): asaningmaxchain123 (Fri, 05 Oct 2018 09:33:24 GMT): asaningmaxchain123 (Fri, 05 Oct 2018 09:33:52 GMT): asaningmaxchain123 (Fri, 05 Oct 2018 10:05:20 GMT): asaningmaxchain123 (Fri, 05 Oct 2018 10:05:20 GMT): asaningmaxchain123 (Fri, 05 Oct 2018 10:05:20 GMT): asaningmaxchain123 (Fri, 05 Oct 2018 10:05:42 GMT): asaningmaxchain123 (Fri, 05 Oct 2018 10:07:43 GMT): tennenjl (Fri, 05 Oct 2018 13:33:41 GMT): Barry_CPF (Fri, 05 Oct 2018 16:14:47 GMT): asaningmaxchain123 (Sat, 06 Oct 2018 04:42:22 GMT): asaningmaxchain123 (Sat, 06 Oct 2018 04:42:27 GMT): dave.enyeart (Sat, 06 Oct 2018 22:11:34 GMT): dave.enyeart (Sat, 06 Oct 2018 22:11:34 GMT): dave.enyeart (Sat, 06 Oct 2018 22:11:34 GMT): dave.enyeart (Sat, 06 Oct 2018 22:11:52 GMT): asaningmaxchain123 (Sun, 07 Oct 2018 00:58:51 GMT): rahulhegde (Sun, 07 Oct 2018 21:30:47 GMT): HoneyShah (Mon, 08 Oct 2018 05:47:57 GMT): HoneyShah (Mon, 08 Oct 2018 05:47:57 GMT): dave.enyeart (Mon, 08 Oct 2018 11:29:16 GMT): dave.enyeart (Mon, 08 Oct 2018 11:31:42 GMT): rahulhegde (Mon, 08 Oct 2018 11:59:21 GMT): dave.enyeart (Mon, 08 Oct 2018 12:02:17 GMT): dave.enyeart (Mon, 08 Oct 2018 12:02:17 GMT): dave.enyeart (Mon, 08 Oct 2018 12:02:17 GMT): rahulhegde (Mon, 08 Oct 2018 12:17:05 GMT): dave.enyeart (Mon, 08 Oct 2018 12:27:43 GMT): waxer (Tue, 09 Oct 2018 11:27:35 GMT): waxer (Tue, 09 Oct 2018 11:28:40 GMT): Barry_CPF (Tue, 09 Oct 2018 15:25:02 GMT): Barry_CPF (Tue, 09 Oct 2018 15:25:55 GMT): asaningmaxchain123 (Tue, 09 Oct 2018 16:33:27 GMT): asaningmaxchain123 (Tue, 09 Oct 2018 16:33:27 GMT): Barry_CPF (Tue, 09 Oct 2018 17:55:39 GMT): dave.enyeart (Tue, 09 Oct 2018 21:27:39 GMT): waxer (Tue, 09 Oct 2018 22:08:59 GMT): Barry_CPF (Wed, 10 Oct 2018 03:50:40 GMT): HoneyShah (Wed, 10 Oct 2018 10:57:50 GMT): aatkddny (Wed, 10 Oct 2018 12:05:05 GMT): HoneyShah (Wed, 10 Oct 2018 12:20:12 GMT): aatkddny (Wed, 10 Oct 2018 12:36:42 GMT): ColeBoudreau (Wed, 10 Oct 2018 16:42:50 GMT): ColeBoudreau (Wed, 10 Oct 2018 16:46:19 GMT): asaningmaxchain123 (Thu, 11 Oct 2018 17:49:07 GMT): dave.enyeart (Thu, 11 Oct 2018 17:57:30 GMT): dave.enyeart (Thu, 11 Oct 2018 17:58:23 GMT): dave.enyeart (Thu, 11 Oct 2018 18:01:39 GMT): asaningmaxchain123 (Thu, 11 Oct 2018 18:03:31 GMT): dave.enyeart (Thu, 11 Oct 2018 18:03:56 GMT): dave.enyeart (Thu, 11 Oct 2018 18:04:23 GMT): asaningmaxchain123 (Thu, 11 Oct 2018 18:06:56 GMT): asaningmaxchain123 (Thu, 11 Oct 2018 18:07:02 GMT): asaningmaxchain123 (Thu, 11 Oct 2018 18:11:11 GMT): dave.enyeart (Thu, 11 Oct 2018 18:14:35 GMT): asaningmaxchain123 (Thu, 11 Oct 2018 18:16:40 GMT): asaningmaxchain123 (Thu, 11 Oct 2018 18:49:51 GMT): asaningmaxchain123 (Thu, 11 Oct 2018 18:49:53 GMT): waxer (Thu, 11 Oct 2018 19:25:46 GMT): asaningmaxchain123 (Thu, 11 Oct 2018 23:29:59 GMT): asaningmaxchain123 (Thu, 11 Oct 2018 23:30:07 GMT): asaningmaxchain123 (Fri, 12 Oct 2018 14:26:43 GMT): dave.enyeart (Fri, 12 Oct 2018 14:54:34 GMT): asaningmaxchain123 (Fri, 12 Oct 2018 15:52:20 GMT): asaningmaxchain123 (Fri, 12 Oct 2018 15:52:20 GMT): dave.enyeart (Fri, 12 Oct 2018 16:02:09 GMT): dave.enyeart (Fri, 12 Oct 2018 16:02:09 GMT): dave.enyeart (Fri, 12 Oct 2018 16:02:31 GMT): asaningmaxchain123 (Fri, 12 Oct 2018 16:14:31 GMT): asaningmaxchain123 (Fri, 12 Oct 2018 16:14:31 GMT): asaningmaxchain123 (Fri, 12 Oct 2018 16:15:30 GMT): waxer (Fri, 12 Oct 2018 16:38:39 GMT): yousaf (Sat, 13 Oct 2018 22:31:29 GMT): yacovm (Sat, 13 Oct 2018 22:38:45 GMT): yacovm (Sat, 13 Oct 2018 22:38:54 GMT): yousaf (Sat, 13 Oct 2018 23:31:01 GMT): waxer (Tue, 16 Oct 2018 00:31:05 GMT): waxer (Tue, 16 Oct 2018 00:32:16 GMT): waxer (Tue, 16 Oct 2018 00:32:38 GMT): dave.enyeart (Tue, 16 Oct 2018 03:00:19 GMT): waxer (Tue, 16 Oct 2018 11:03:38 GMT): dave.enyeart (Tue, 16 Oct 2018 12:11:47 GMT): yacovm (Tue, 16 Oct 2018 12:12:43 GMT): yacovm (Tue, 16 Oct 2018 12:12:51 GMT): yacovm (Tue, 16 Oct 2018 12:13:14 GMT): yacovm (Tue, 16 Oct 2018 12:13:50 GMT): yacovm (Tue, 16 Oct 2018 12:14:08 GMT): dave.enyeart (Tue, 16 Oct 2018 12:14:19 GMT): yacovm (Tue, 16 Oct 2018 12:15:19 GMT): yacovm (Tue, 16 Oct 2018 12:15:32 GMT): yacovm (Tue, 16 Oct 2018 12:16:06 GMT): yacovm (Tue, 16 Oct 2018 12:16:19 GMT): dave.enyeart (Tue, 16 Oct 2018 12:16:26 GMT): yacovm (Tue, 16 Oct 2018 12:18:11 GMT): yacovm (Tue, 16 Oct 2018 12:18:31 GMT): yacovm (Tue, 16 Oct 2018 12:18:34 GMT): yacovm (Tue, 16 Oct 2018 12:18:53 GMT): yacovm (Tue, 16 Oct 2018 12:19:26 GMT): yacovm (Tue, 16 Oct 2018 12:19:38 GMT): yacovm (Tue, 16 Oct 2018 12:19:59 GMT): dave.enyeart (Tue, 16 Oct 2018 12:20:15 GMT): yacovm (Tue, 16 Oct 2018 12:20:23 GMT): yacovm (Tue, 16 Oct 2018 12:20:47 GMT): dave.enyeart (Tue, 16 Oct 2018 12:21:12 GMT): dave.enyeart (Tue, 16 Oct 2018 12:21:12 GMT): dave.enyeart (Tue, 16 Oct 2018 12:21:12 GMT): waxer (Tue, 16 Oct 2018 12:43:14 GMT): yacovm (Tue, 16 Oct 2018 12:45:38 GMT): yacovm (Tue, 16 Oct 2018 12:45:54 GMT): yacovm (Tue, 16 Oct 2018 12:45:59 GMT): yacovm (Tue, 16 Oct 2018 12:46:07 GMT): yacovm (Tue, 16 Oct 2018 12:46:22 GMT): waxer (Tue, 16 Oct 2018 13:12:05 GMT): yacovm (Tue, 16 Oct 2018 13:13:29 GMT): waxer (Tue, 16 Oct 2018 13:14:22 GMT): yacovm (Tue, 16 Oct 2018 13:15:14 GMT): yacovm (Tue, 16 Oct 2018 13:15:31 GMT): waxer (Tue, 16 Oct 2018 13:16:05 GMT): waxer (Tue, 16 Oct 2018 13:18:06 GMT): krabradosty (Tue, 16 Oct 2018 17:33:49 GMT): krabradosty (Tue, 16 Oct 2018 17:34:01 GMT): krabradosty (Tue, 16 Oct 2018 17:34:01 GMT): dave.enyeart (Tue, 16 Oct 2018 17:51:47 GMT): dave.enyeart (Tue, 16 Oct 2018 17:52:15 GMT): dave.enyeart (Tue, 16 Oct 2018 17:52:15 GMT): ataul443 (Wed, 17 Oct 2018 18:23:02 GMT): kh.nguyen (Fri, 19 Oct 2018 00:21:28 GMT): waxer (Fri, 19 Oct 2018 01:58:06 GMT): waxer (Fri, 19 Oct 2018 01:59:33 GMT): AndrewNRise (Fri, 19 Oct 2018 08:20:59 GMT): toddinpal (Fri, 19 Oct 2018 16:49:16 GMT): toddinpal (Fri, 19 Oct 2018 17:04:31 GMT): dave.enyeart (Fri, 19 Oct 2018 17:06:07 GMT): toddinpal (Fri, 19 Oct 2018 17:13:09 GMT): dave.enyeart (Fri, 19 Oct 2018 17:19:33 GMT): leura (Sat, 20 Oct 2018 09:37:16 GMT): toddinpal (Sat, 20 Oct 2018 14:42:18 GMT): dave.enyeart (Sat, 20 Oct 2018 15:01:45 GMT): dave.enyeart (Sat, 20 Oct 2018 15:03:22 GMT): dave.enyeart (Sat, 20 Oct 2018 15:03:22 GMT): toddinpal (Sat, 20 Oct 2018 15:43:24 GMT): dave.enyeart (Sat, 20 Oct 2018 15:52:03 GMT): rahulhegde (Tue, 23 Oct 2018 22:30:14 GMT): dave.enyeart (Wed, 24 Oct 2018 00:35:01 GMT): dave.enyeart (Wed, 24 Oct 2018 00:36:17 GMT): rahulhegde (Wed, 24 Oct 2018 02:19:10 GMT): rahulhegde (Wed, 24 Oct 2018 02:19:10 GMT): dave.enyeart (Wed, 24 Oct 2018 02:32:52 GMT): dave.enyeart (Wed, 24 Oct 2018 02:34:06 GMT): dave.enyeart (Wed, 24 Oct 2018 02:34:23 GMT): dave.enyeart (Wed, 24 Oct 2018 02:35:08 GMT): rahulhegde (Wed, 24 Oct 2018 02:36:58 GMT): rahulhegde (Wed, 24 Oct 2018 02:39:35 GMT): dave.enyeart (Wed, 24 Oct 2018 02:55:54 GMT): Nabilel 1 (Wed, 24 Oct 2018 09:08:32 GMT): dave.enyeart (Wed, 24 Oct 2018 09:36:33 GMT): Nabilel 1 (Wed, 24 Oct 2018 11:41:21 GMT): Nabilel 1 (Wed, 24 Oct 2018 11:41:30 GMT): EricPetruzzelli (Wed, 24 Oct 2018 12:53:18 GMT): zimabry (Wed, 24 Oct 2018 20:48:22 GMT): waxer (Wed, 24 Oct 2018 22:01:27 GMT): rahulhegde (Thu, 25 Oct 2018 01:18:35 GMT): cagdast (Thu, 25 Oct 2018 07:48:42 GMT): parags (Wed, 31 Oct 2018 15:53:45 GMT): AzfaarQureshi (Wed, 31 Oct 2018 17:14:25 GMT): MohammadObaid (Fri, 02 Nov 2018 09:46:48 GMT): awes0menessInc (Tue, 06 Nov 2018 03:37:45 GMT): enriquebusti (Wed, 07 Nov 2018 12:01:30 GMT): javrevasandeep (Tue, 13 Nov 2018 16:08:58 GMT): javrevasandeep (Tue, 13 Nov 2018 16:08:58 GMT): dave.enyeart (Tue, 13 Nov 2018 19:33:30 GMT): dave.enyeart (Tue, 13 Nov 2018 19:33:30 GMT): dave.enyeart (Tue, 13 Nov 2018 19:35:33 GMT): javrevasandeep (Wed, 14 Nov 2018 05:18:48 GMT): javrevasandeep (Wed, 14 Nov 2018 05:18:48 GMT): dave.enyeart (Wed, 14 Nov 2018 12:24:45 GMT): javrevasandeep (Wed, 14 Nov 2018 12:37:57 GMT): dave.enyeart (Wed, 14 Nov 2018 13:49:25 GMT): dave.enyeart (Wed, 14 Nov 2018 13:49:29 GMT): dave.enyeart (Wed, 14 Nov 2018 13:50:18 GMT): dave.enyeart (Wed, 14 Nov 2018 13:51:09 GMT): javrevasandeep (Wed, 14 Nov 2018 14:02:48 GMT): dave.enyeart (Wed, 14 Nov 2018 14:10:39 GMT): dave.enyeart (Wed, 14 Nov 2018 14:11:18 GMT): javrevasandeep (Wed, 14 Nov 2018 16:30:33 GMT): dave.enyeart (Wed, 14 Nov 2018 16:44:13 GMT): HoneyShah (Fri, 16 Nov 2018 08:19:59 GMT): qsmen (Fri, 16 Nov 2018 08:38:25 GMT): qsmen (Fri, 16 Nov 2018 09:16:13 GMT): dave.enyeart (Fri, 16 Nov 2018 11:26:55 GMT): dave.enyeart (Fri, 16 Nov 2018 11:26:58 GMT): HoneyShah (Fri, 16 Nov 2018 11:43:56 GMT): dave.enyeart (Fri, 16 Nov 2018 11:52:57 GMT): BellaAdams (Sat, 17 Nov 2018 00:46:01 GMT): huxiangdong (Tue, 20 Nov 2018 00:33:17 GMT): qsmen (Tue, 20 Nov 2018 06:29:07 GMT): asaningmaxchain123 (Tue, 20 Nov 2018 14:04:16 GMT): asaningmaxchain123 (Tue, 20 Nov 2018 14:44:10 GMT): dave.enyeart (Tue, 20 Nov 2018 14:45:05 GMT): dave.enyeart (Tue, 20 Nov 2018 14:45:05 GMT): ivanovv (Thu, 22 Nov 2018 10:51:59 GMT): ivanovv (Thu, 22 Nov 2018 12:51:04 GMT): ivanovv (Thu, 22 Nov 2018 12:51:04 GMT): ivanovv (Thu, 22 Nov 2018 12:51:04 GMT): dave.enyeart (Thu, 22 Nov 2018 13:09:17 GMT): ivanovv (Thu, 22 Nov 2018 13:45:37 GMT): ivanovv (Thu, 22 Nov 2018 13:45:37 GMT): ivanovv (Thu, 22 Nov 2018 13:48:06 GMT): ivanovv (Thu, 22 Nov 2018 17:32:50 GMT): aKesav (Sat, 24 Nov 2018 08:16:24 GMT): MaheshBalan_Pravici (Sat, 24 Nov 2018 22:22:44 GMT): MaheshBalan_Pravici (Sat, 24 Nov 2018 22:23:09 GMT): dave.enyeart (Sun, 25 Nov 2018 03:40:19 GMT): MaheshBalan_Pravici (Sun, 25 Nov 2018 19:16:08 GMT): MaheshBalan_Pravici (Sun, 25 Nov 2018 19:17:35 GMT): MaheshBalan_Pravici (Sun, 25 Nov 2018 19:21:58 GMT): dave.enyeart (Sun, 25 Nov 2018 23:04:11 GMT): dave.enyeart (Sun, 25 Nov 2018 23:04:14 GMT): MaheshBalan_Pravici (Mon, 26 Nov 2018 20:40:09 GMT): minollo (Tue, 27 Nov 2018 23:22:07 GMT): manish-sethi (Tue, 27 Nov 2018 23:26:54 GMT): manish-sethi (Tue, 27 Nov 2018 23:26:54 GMT): manish-sethi (Tue, 27 Nov 2018 23:28:34 GMT): minollo (Wed, 28 Nov 2018 00:05:36 GMT): melwindmello (Wed, 28 Nov 2018 06:54:58 GMT): melwindmello (Wed, 28 Nov 2018 06:55:24 GMT): theezenaku (Wed, 28 Nov 2018 22:52:25 GMT): waxer (Thu, 29 Nov 2018 02:14:31 GMT): haggis (Thu, 29 Nov 2018 08:08:07 GMT): melwindmello (Thu, 29 Nov 2018 10:37:46 GMT): melwindmello (Thu, 29 Nov 2018 10:43:33 GMT): melwindmello (Thu, 29 Nov 2018 10:43:33 GMT): waxer (Thu, 29 Nov 2018 11:27:40 GMT): waxer (Thu, 29 Nov 2018 11:28:58 GMT): haggis (Thu, 29 Nov 2018 11:47:15 GMT): giacomo.minighin (Thu, 29 Nov 2018 11:55:43 GMT): eabiodun (Thu, 29 Nov 2018 20:13:53 GMT): guoger (Fri, 30 Nov 2018 07:18:14 GMT): manish-sethi (Fri, 30 Nov 2018 14:20:56 GMT): guoger (Sat, 01 Dec 2018 06:27:01 GMT): guoger (Sat, 01 Dec 2018 06:32:05 GMT): giacomo.minighin (Mon, 03 Dec 2018 15:18:10 GMT): dave.enyeart (Mon, 03 Dec 2018 16:28:53 GMT): nRyDevOps (Mon, 03 Dec 2018 16:28:54 GMT): nRyDevOps (Mon, 03 Dec 2018 16:43:22 GMT): mallikarjunasai995 (Tue, 04 Dec 2018 05:02:05 GMT): FLASHJr (Tue, 04 Dec 2018 10:49:39 GMT): mallikarjunasai995 (Tue, 04 Dec 2018 14:47:00 GMT): arjitkhullar (Wed, 05 Dec 2018 00:03:51 GMT): dileban (Wed, 05 Dec 2018 02:18:10 GMT): dave.enyeart (Wed, 05 Dec 2018 06:15:36 GMT): dave.enyeart (Wed, 05 Dec 2018 06:22:09 GMT): dave.enyeart (Wed, 05 Dec 2018 06:22:09 GMT): mallikarjunasai995 (Wed, 05 Dec 2018 06:37:44 GMT): mallikarjunasai995 (Thu, 06 Dec 2018 05:51:35 GMT): knagware9 (Thu, 06 Dec 2018 05:54:38 GMT): mallikarjunasai995 (Thu, 06 Dec 2018 05:56:59 GMT): knagware9 (Thu, 06 Dec 2018 05:58:32 GMT): mallikarjunasai995 (Thu, 06 Dec 2018 05:59:52 GMT): knagware9 (Thu, 06 Dec 2018 06:03:40 GMT): mallikarjunasai995 (Thu, 06 Dec 2018 06:05:24 GMT): knagware9 (Thu, 06 Dec 2018 06:08:03 GMT): mallikarjunasai995 (Thu, 06 Dec 2018 06:09:02 GMT): mallikarjunasai995 (Thu, 06 Dec 2018 13:43:49 GMT): dileban (Fri, 07 Dec 2018 05:14:13 GMT): mallikarjunasai995 (Fri, 07 Dec 2018 05:57:26 GMT): dave.enyeart (Fri, 07 Dec 2018 12:26:30 GMT): dave.enyeart (Fri, 07 Dec 2018 12:26:30 GMT): dave.enyeart (Fri, 07 Dec 2018 12:26:30 GMT): dave.enyeart (Fri, 07 Dec 2018 12:29:30 GMT): mbanerjee (Fri, 07 Dec 2018 21:46:06 GMT): mikd (Fri, 07 Dec 2018 21:51:56 GMT): mbanerjee (Fri, 07 Dec 2018 21:55:37 GMT): qizhang (Mon, 10 Dec 2018 15:23:00 GMT): manish-sethi (Mon, 10 Dec 2018 18:41:22 GMT): qizhang (Mon, 10 Dec 2018 20:45:55 GMT): manish-sethi (Mon, 10 Dec 2018 21:26:37 GMT): qizhang (Mon, 10 Dec 2018 22:26:53 GMT): qizhang (Mon, 10 Dec 2018 22:26:53 GMT): YashParihar (Tue, 11 Dec 2018 04:22:53 GMT): NilsP 1 (Thu, 13 Dec 2018 10:28:52 GMT): NilsP 1 (Thu, 13 Dec 2018 10:29:40 GMT): dave.enyeart (Thu, 13 Dec 2018 12:56:43 GMT): varubasi77 (Thu, 13 Dec 2018 14:48:59 GMT): Shyam_Pratap_Singh (Sun, 16 Dec 2018 11:40:52 GMT): nikospaz (Mon, 17 Dec 2018 09:38:19 GMT): nikospaz (Mon, 17 Dec 2018 09:39:27 GMT): nikospaz (Mon, 17 Dec 2018 09:47:23 GMT): nikospaz (Mon, 17 Dec 2018 09:47:35 GMT): nikospaz (Mon, 17 Dec 2018 09:48:03 GMT): GuillaumeTong (Mon, 17 Dec 2018 10:39:15 GMT): lfeagan (Tue, 18 Dec 2018 03:47:13 GMT): zacpl (Tue, 18 Dec 2018 15:39:13 GMT): aso (Wed, 19 Dec 2018 08:24:43 GMT): aso (Wed, 19 Dec 2018 08:25:13 GMT): aso (Wed, 19 Dec 2018 08:26:08 GMT): qsmen (Wed, 19 Dec 2018 09:31:10 GMT): zacpl (Wed, 19 Dec 2018 10:30:20 GMT): aso (Wed, 19 Dec 2018 11:25:19 GMT): dave.enyeart (Wed, 19 Dec 2018 13:01:54 GMT): aso (Wed, 19 Dec 2018 13:53:56 GMT): chuda (Thu, 20 Dec 2018 13:02:59 GMT): chuda (Thu, 20 Dec 2018 13:03:57 GMT): chuda (Thu, 20 Dec 2018 13:04:46 GMT): manish-sethi (Thu, 20 Dec 2018 14:36:13 GMT): qsmen (Fri, 21 Dec 2018 01:49:02 GMT): MayukhGhosh (Fri, 21 Dec 2018 10:08:30 GMT): chuda (Fri, 21 Dec 2018 13:42:17 GMT): dave.enyeart (Fri, 21 Dec 2018 14:51:00 GMT): merq (Sat, 22 Dec 2018 03:45:35 GMT): chuda (Sat, 22 Dec 2018 05:13:59 GMT): mbwhite (Sat, 22 Dec 2018 09:07:18 GMT): dave.enyeart (Sat, 22 Dec 2018 12:45:36 GMT): chuda (Sat, 22 Dec 2018 13:25:43 GMT): dave.enyeart (Sat, 22 Dec 2018 13:37:33 GMT): dave.enyeart (Sat, 22 Dec 2018 13:38:07 GMT): dave.enyeart (Sat, 22 Dec 2018 13:40:10 GMT): FLASHJr (Mon, 24 Dec 2018 11:27:22 GMT): knagware9 (Mon, 24 Dec 2018 12:56:13 GMT): FLASHJr (Mon, 24 Dec 2018 12:57:09 GMT): knagware9 (Mon, 24 Dec 2018 12:58:31 GMT): knagware9 (Mon, 24 Dec 2018 13:03:30 GMT): mefy-pushpendu (Wed, 26 Dec 2018 05:25:01 GMT): mefy-pushpendu (Wed, 26 Dec 2018 05:57:54 GMT): mefy-pushpendu (Wed, 26 Dec 2018 05:58:06 GMT): dave.enyeart (Thu, 27 Dec 2018 15:29:57 GMT): dave.enyeart (Thu, 27 Dec 2018 15:29:59 GMT): dave.enyeart (Thu, 27 Dec 2018 15:30:31 GMT): dave.enyeart (Thu, 27 Dec 2018 16:27:01 GMT): mefy-pushpendu (Fri, 28 Dec 2018 01:22:18 GMT): dave.enyeart (Fri, 28 Dec 2018 03:49:13 GMT): nRyDevOps (Fri, 28 Dec 2018 08:18:46 GMT): knagware9 (Fri, 28 Dec 2018 10:07:14 GMT): chuda (Fri, 28 Dec 2018 13:26:17 GMT): nRyDevOps (Fri, 28 Dec 2018 17:31:38 GMT): nRyDevOps (Sat, 29 Dec 2018 05:46:34 GMT): nRyDevOps (Sat, 29 Dec 2018 05:46:35 GMT): yousaf (Sat, 29 Dec 2018 10:30:26 GMT): nRyDevOps (Mon, 31 Dec 2018 00:34:59 GMT): nRyDevOps (Mon, 31 Dec 2018 00:35:01 GMT): nRyDevOps (Mon, 31 Dec 2018 00:35:43 GMT): knagware9 (Wed, 02 Jan 2019 06:57:25 GMT): ShajiThiyarathodi (Wed, 02 Jan 2019 19:32:33 GMT): xaviarias (Thu, 03 Jan 2019 11:03:11 GMT): npc0405 (Thu, 03 Jan 2019 14:26:01 GMT): npc0405 (Thu, 03 Jan 2019 14:26:05 GMT): npc0405 (Thu, 03 Jan 2019 14:26:46 GMT): npc0405 (Thu, 03 Jan 2019 14:27:22 GMT): dave.enyeart (Thu, 03 Jan 2019 14:27:34 GMT): dave.enyeart (Thu, 03 Jan 2019 14:27:59 GMT): dave.enyeart (Thu, 03 Jan 2019 14:27:59 GMT): jrosmith (Thu, 03 Jan 2019 15:16:25 GMT): dave.enyeart (Thu, 03 Jan 2019 15:30:04 GMT): dave.enyeart (Thu, 03 Jan 2019 15:30:22 GMT): dave.enyeart (Thu, 03 Jan 2019 15:30:28 GMT): jrosmith (Thu, 03 Jan 2019 15:33:17 GMT): hhlee (Mon, 07 Jan 2019 02:56:31 GMT): asaningmaxchain123 (Mon, 07 Jan 2019 10:10:18 GMT): asaningmaxchain123 (Mon, 07 Jan 2019 10:10:21 GMT): asaningmaxchain123 (Mon, 07 Jan 2019 10:10:29 GMT): asaningmaxchain123 (Mon, 07 Jan 2019 10:16:11 GMT): dave.enyeart (Mon, 07 Jan 2019 12:54:08 GMT): mbanerjee (Wed, 09 Jan 2019 03:26:46 GMT): wangdong (Wed, 09 Jan 2019 05:49:49 GMT): wangdong (Wed, 09 Jan 2019 05:50:07 GMT): wangdong (Wed, 09 Jan 2019 05:50:55 GMT): wangdong (Wed, 09 Jan 2019 05:51:01 GMT): wangdong (Wed, 09 Jan 2019 05:51:22 GMT): wangdong (Wed, 09 Jan 2019 05:51:29 GMT): wangdong (Wed, 09 Jan 2019 06:09:06 GMT): raviranjan14 (Wed, 09 Jan 2019 13:01:59 GMT): chuda (Thu, 10 Jan 2019 12:20:23 GMT): spacemandev (Fri, 11 Jan 2019 12:12:10 GMT): plato (Tue, 15 Jan 2019 00:30:16 GMT): pankajcheema (Tue, 15 Jan 2019 10:47:28 GMT): jrosmith (Tue, 15 Jan 2019 13:27:10 GMT): wangdong (Wed, 16 Jan 2019 03:34:17 GMT): JayJong (Wed, 16 Jan 2019 08:06:17 GMT): JayJong (Wed, 16 Jan 2019 08:06:17 GMT): JayJong (Wed, 16 Jan 2019 08:06:17 GMT): JayJong (Wed, 16 Jan 2019 08:06:17 GMT): pankajcheema (Wed, 16 Jan 2019 08:40:20 GMT): pankajcheema (Wed, 16 Jan 2019 08:40:25 GMT): pankajcheema (Wed, 16 Jan 2019 08:41:56 GMT): dave.enyeart (Wed, 16 Jan 2019 12:51:11 GMT): plato (Wed, 16 Jan 2019 18:03:13 GMT): chuda (Fri, 18 Jan 2019 08:04:32 GMT): jrosmith (Fri, 18 Jan 2019 13:37:05 GMT): chuda (Fri, 18 Jan 2019 17:41:28 GMT): chuda (Sun, 20 Jan 2019 08:09:01 GMT): AbhishekDudhrejia (Mon, 21 Jan 2019 05:35:09 GMT): ycarmel (Tue, 22 Jan 2019 08:45:29 GMT): Jamie (Tue, 22 Jan 2019 17:08:59 GMT): incarose (Wed, 23 Jan 2019 00:23:33 GMT): AbhishekDudhrejia (Wed, 23 Jan 2019 10:44:41 GMT): dave.enyeart (Wed, 23 Jan 2019 16:48:55 GMT): dave.enyeart (Wed, 23 Jan 2019 16:48:55 GMT): HoneyShah (Thu, 24 Jan 2019 08:39:41 GMT): alek (Fri, 25 Jan 2019 13:55:02 GMT): dave.enyeart (Fri, 25 Jan 2019 14:16:19 GMT): dave.enyeart (Fri, 25 Jan 2019 14:16:19 GMT): dave.enyeart (Fri, 25 Jan 2019 14:16:51 GMT): dave.enyeart (Fri, 25 Jan 2019 14:22:31 GMT): toddinpal (Fri, 25 Jan 2019 18:31:44 GMT): Pradeep_Pentakota (Sat, 26 Jan 2019 13:42:15 GMT): binhn (Sat, 26 Jan 2019 16:49:54 GMT): lip-inagora (Mon, 28 Jan 2019 00:22:28 GMT): alek (Mon, 28 Jan 2019 09:22:36 GMT): edisinovcic (Mon, 28 Jan 2019 13:15:59 GMT): pankajcheema (Mon, 28 Jan 2019 16:44:40 GMT): toddinpal (Mon, 28 Jan 2019 20:10:41 GMT): dave.enyeart (Mon, 28 Jan 2019 20:48:40 GMT): HoneyShah (Tue, 29 Jan 2019 09:00:11 GMT): dave.enyeart (Tue, 29 Jan 2019 09:07:55 GMT): HoneyShah (Tue, 29 Jan 2019 09:12:01 GMT): HoneyShah (Tue, 29 Jan 2019 09:12:01 GMT): mbwhite (Tue, 29 Jan 2019 12:40:50 GMT): mbwhite (Tue, 29 Jan 2019 12:41:52 GMT): Daca 5 (Tue, 29 Jan 2019 13:03:22 GMT): mbwhite (Tue, 29 Jan 2019 14:17:58 GMT): plato (Tue, 29 Jan 2019 23:32:24 GMT): dave.enyeart (Tue, 29 Jan 2019 23:36:11 GMT): RyanGriffiths (Wed, 30 Jan 2019 11:21:00 GMT): plato (Wed, 30 Jan 2019 21:20:19 GMT): dave.enyeart (Wed, 30 Jan 2019 23:49:43 GMT): Siva_vignesh (Fri, 01 Feb 2019 08:44:31 GMT): pasimoes (Sat, 02 Feb 2019 00:58:54 GMT): prabu3192 (Mon, 04 Feb 2019 06:02:02 GMT): sayan.hlf (Tue, 05 Feb 2019 09:15:21 GMT): dave.enyeart (Tue, 05 Feb 2019 11:55:49 GMT): sayan.hlf (Tue, 05 Feb 2019 12:51:58 GMT): knagware9 (Wed, 06 Feb 2019 06:45:01 GMT): waxer (Sat, 09 Feb 2019 03:09:46 GMT): dave.enyeart (Sat, 09 Feb 2019 13:27:42 GMT): dave.enyeart (Sat, 09 Feb 2019 13:30:49 GMT): waxer (Mon, 11 Feb 2019 02:07:27 GMT): cenyongh (Tue, 12 Feb 2019 05:14:55 GMT): eddie.allen (Tue, 12 Feb 2019 14:44:19 GMT): waxer (Sat, 16 Feb 2019 22:26:19 GMT): yacovm (Sat, 16 Feb 2019 22:50:30 GMT): waxer (Sun, 17 Feb 2019 03:58:38 GMT): Miguel-A (Mon, 18 Feb 2019 11:57:03 GMT): aatkddny (Tue, 19 Feb 2019 13:38:29 GMT): dave.enyeart (Tue, 19 Feb 2019 14:47:32 GMT): dave.enyeart (Tue, 19 Feb 2019 14:52:13 GMT): dave.enyeart (Tue, 19 Feb 2019 14:52:13 GMT): dave.enyeart (Tue, 19 Feb 2019 14:52:13 GMT): aatkddny (Tue, 19 Feb 2019 15:07:22 GMT): aatkddny (Tue, 19 Feb 2019 15:07:22 GMT): aatkddny (Tue, 19 Feb 2019 15:07:22 GMT): dave.enyeart (Tue, 19 Feb 2019 15:38:29 GMT): dave.enyeart (Tue, 19 Feb 2019 15:38:29 GMT): dave.enyeart (Tue, 19 Feb 2019 15:38:29 GMT): aatkddny (Tue, 19 Feb 2019 15:54:39 GMT): aatkddny (Tue, 19 Feb 2019 15:54:39 GMT): aatkddny (Tue, 19 Feb 2019 15:54:39 GMT): Jgnuid (Sat, 23 Feb 2019 15:41:41 GMT): Jgnuid (Sat, 23 Feb 2019 15:41:41 GMT): Jgnuid (Sat, 23 Feb 2019 15:53:54 GMT): suryalanka (Sat, 23 Feb 2019 16:43:33 GMT): suryalanka (Sat, 23 Feb 2019 16:59:19 GMT): suryalanka (Sat, 23 Feb 2019 17:01:02 GMT): suryalanka (Sat, 23 Feb 2019 17:01:02 GMT): suryalanka (Sat, 23 Feb 2019 17:04:04 GMT): Jgnuid (Sat, 23 Feb 2019 18:20:35 GMT): suryalanka (Sat, 23 Feb 2019 19:25:16 GMT): Jgnuid (Sat, 23 Feb 2019 19:26:48 GMT): Jgnuid (Sat, 23 Feb 2019 19:27:19 GMT): suryalanka (Sat, 23 Feb 2019 19:27:36 GMT): plato (Tue, 26 Feb 2019 00:54:49 GMT): plato (Tue, 26 Feb 2019 00:55:31 GMT): plato (Tue, 26 Feb 2019 00:55:32 GMT): dave.enyeart (Tue, 26 Feb 2019 02:19:40 GMT): plato (Tue, 26 Feb 2019 19:22:53 GMT): Estebanrestrepo (Fri, 01 Mar 2019 19:40:02 GMT): keshavrajput (Sat, 02 Mar 2019 07:58:53 GMT): braduf (Tue, 05 Mar 2019 00:06:22 GMT): javrevasandeep (Mon, 11 Mar 2019 06:51:20 GMT): javrevasandeep (Mon, 11 Mar 2019 06:51:37 GMT): javrevasandeep (Mon, 11 Mar 2019 06:51:37 GMT): dave.enyeart (Mon, 11 Mar 2019 11:12:32 GMT): dave.enyeart (Mon, 11 Mar 2019 11:12:40 GMT): dave.enyeart (Mon, 11 Mar 2019 11:12:42 GMT): dave.enyeart (Mon, 11 Mar 2019 11:13:56 GMT): KyunghoKim (Tue, 12 Mar 2019 03:09:34 GMT): HoneyShah (Tue, 12 Mar 2019 10:05:28 GMT): plato (Tue, 12 Mar 2019 17:24:39 GMT): plato (Tue, 12 Mar 2019 17:24:39 GMT): plato (Tue, 12 Mar 2019 17:24:39 GMT): plato (Tue, 12 Mar 2019 17:24:39 GMT): plato (Tue, 12 Mar 2019 17:24:39 GMT): plato (Tue, 12 Mar 2019 17:24:39 GMT): plato (Tue, 12 Mar 2019 17:24:39 GMT): plato (Tue, 12 Mar 2019 17:28:04 GMT): plato (Tue, 12 Mar 2019 17:28:38 GMT): plato (Tue, 12 Mar 2019 17:30:48 GMT): plato (Tue, 12 Mar 2019 17:30:48 GMT): plato (Tue, 12 Mar 2019 17:30:56 GMT): jlcs (Wed, 13 Mar 2019 14:13:30 GMT): npc0405 (Mon, 18 Mar 2019 09:38:56 GMT): mallikarjunasai995 (Mon, 18 Mar 2019 14:11:29 GMT): dave.enyeart (Mon, 18 Mar 2019 18:46:32 GMT): dave.enyeart (Mon, 18 Mar 2019 18:48:39 GMT): npc0405 (Tue, 19 Mar 2019 02:00:39 GMT): npc0405 (Tue, 19 Mar 2019 05:52:31 GMT): mallikarjunasai995 (Tue, 19 Mar 2019 06:32:35 GMT): dave.enyeart (Tue, 19 Mar 2019 08:05:10 GMT): dave.enyeart (Tue, 19 Mar 2019 08:05:40 GMT): npc0405 (Tue, 19 Mar 2019 10:08:53 GMT): npc0405 (Tue, 19 Mar 2019 10:10:21 GMT): npc0405 (Tue, 19 Mar 2019 10:10:24 GMT): dave.enyeart (Tue, 19 Mar 2019 11:33:06 GMT): dave.enyeart (Tue, 19 Mar 2019 11:33:06 GMT): yanli133 (Mon, 25 Mar 2019 06:54:33 GMT): Stacker (Thu, 28 Mar 2019 11:13:10 GMT): HoneyShah (Thu, 28 Mar 2019 11:42:49 GMT): HoneyShah (Thu, 28 Mar 2019 11:42:49 GMT): sunit.versatile (Mon, 01 Apr 2019 08:32:08 GMT): AliciaDominic (Wed, 03 Apr 2019 04:47:41 GMT): KGiou (Wed, 03 Apr 2019 12:44:40 GMT): qsmen (Tue, 16 Apr 2019 01:05:16 GMT): qsmen (Wed, 17 Apr 2019 00:50:39 GMT): qsmen (Wed, 17 Apr 2019 00:51:34 GMT): qsmen (Wed, 17 Apr 2019 01:04:29 GMT): mwenyan (Wed, 17 Apr 2019 22:09:26 GMT): dave.enyeart (Thu, 18 Apr 2019 13:39:26 GMT): qsmen (Fri, 19 Apr 2019 05:44:08 GMT): qsmen (Fri, 19 Apr 2019 05:44:08 GMT): qsmen (Fri, 19 Apr 2019 05:44:08 GMT): minollo (Fri, 19 Apr 2019 19:33:50 GMT): manish-sethi (Fri, 19 Apr 2019 19:37:42 GMT): minollo (Fri, 19 Apr 2019 19:38:55 GMT): minollo (Fri, 19 Apr 2019 19:39:59 GMT): manish-sethi (Fri, 19 Apr 2019 19:40:11 GMT): minollo (Fri, 19 Apr 2019 19:40:29 GMT): manish-sethi (Fri, 19 Apr 2019 19:41:10 GMT): minollo (Fri, 19 Apr 2019 19:41:58 GMT): mbanerjee (Wed, 24 Apr 2019 22:08:17 GMT): knagware9 (Thu, 25 Apr 2019 08:45:18 GMT): sgaddam (Thu, 25 Apr 2019 11:33:35 GMT): sgaddam (Thu, 25 Apr 2019 11:49:27 GMT): sgaddam (Thu, 25 Apr 2019 11:49:42 GMT): Fias (Fri, 26 Apr 2019 06:57:02 GMT): dave.enyeart (Fri, 26 Apr 2019 16:15:43 GMT): yerganat (Fri, 03 May 2019 05:15:16 GMT): bh4rtp (Mon, 13 May 2019 06:47:09 GMT): circlespainter (Sat, 18 May 2019 07:35:18 GMT): IgorSim (Tue, 21 May 2019 09:00:05 GMT): IgorSim (Tue, 21 May 2019 09:00:05 GMT): krabradosty (Tue, 21 May 2019 18:03:02 GMT): horse (Tue, 21 May 2019 21:56:27 GMT): knagware9 (Wed, 22 May 2019 10:33:12 GMT): dave.enyeart (Wed, 22 May 2019 10:51:19 GMT): dave.enyeart (Wed, 22 May 2019 11:46:04 GMT): IgorSim (Wed, 22 May 2019 11:56:58 GMT): spacemandev (Wed, 22 May 2019 19:08:00 GMT): kn3118 (Thu, 23 May 2019 16:41:47 GMT): javrevasandeep (Thu, 30 May 2019 05:48:46 GMT): sgaddam (Thu, 30 May 2019 05:51:49 GMT): anand.fast (Tue, 04 Jun 2019 01:31:34 GMT): mbanerjee (Tue, 11 Jun 2019 00:49:33 GMT): dave.enyeart (Tue, 11 Jun 2019 10:05:42 GMT): scottz (Mon, 17 Jun 2019 13:39:09 GMT): hanubc7743 (Wed, 19 Jun 2019 20:57:18 GMT): hanubc7743 (Wed, 19 Jun 2019 20:57:48 GMT): wangdong (Thu, 20 Jun 2019 06:15:48 GMT): aviralwal (Fri, 21 Jun 2019 13:57:51 GMT): mastersingh24 (Mon, 24 Jun 2019 20:44:06 GMT): richardmurillo (Mon, 24 Jun 2019 21:00:06 GMT): gregnotso (Thu, 27 Jun 2019 23:58:25 GMT): HoneyShah (Mon, 08 Jul 2019 03:58:43 GMT): pankajcheema (Wed, 17 Jul 2019 10:32:56 GMT): xixuejia (Thu, 18 Jul 2019 01:40:37 GMT): toddinpal (Thu, 18 Jul 2019 15:47:37 GMT): SanketPanchamia (Tue, 23 Jul 2019 07:51:42 GMT): dave.enyeart (Wed, 24 Jul 2019 05:02:20 GMT): SanketPanchamia (Wed, 24 Jul 2019 05:50:02 GMT): qsmen (Mon, 29 Jul 2019 09:49:09 GMT): qsmen (Mon, 29 Jul 2019 09:49:09 GMT): dave.enyeart (Mon, 29 Jul 2019 13:20:06 GMT): dave.enyeart (Mon, 29 Jul 2019 13:20:06 GMT): qsmen (Tue, 30 Jul 2019 00:55:59 GMT): qsmen (Tue, 30 Jul 2019 00:55:59 GMT): aatkddny (Tue, 06 Aug 2019 00:35:26 GMT): huxd (Tue, 06 Aug 2019 05:46:34 GMT): qsmen (Fri, 09 Aug 2019 07:13:54 GMT): qsmen (Fri, 09 Aug 2019 07:13:54 GMT): rahulhegde (Fri, 09 Aug 2019 16:37:05 GMT): rahulhegde (Fri, 09 Aug 2019 16:37:05 GMT): rahulhegde (Fri, 09 Aug 2019 17:01:32 GMT): rahulhegde (Fri, 09 Aug 2019 18:43:20 GMT): rahulhegde (Fri, 09 Aug 2019 18:43:48 GMT): dave.enyeart (Fri, 09 Aug 2019 18:47:36 GMT): dave.enyeart (Fri, 09 Aug 2019 19:18:46 GMT): rahulhegde (Fri, 09 Aug 2019 19:26:36 GMT): rahulhegde (Fri, 09 Aug 2019 19:31:52 GMT): qsmen (Mon, 12 Aug 2019 00:47:22 GMT): SatheeshNehru (Mon, 12 Aug 2019 05:19:20 GMT): rodolfoleal (Thu, 15 Aug 2019 16:40:41 GMT): sarapaul (Sun, 25 Aug 2019 22:11:14 GMT): smita_narvekar (Thu, 29 Aug 2019 06:19:20 GMT): smita_narvekar (Thu, 29 Aug 2019 06:19:54 GMT): toddinpal (Thu, 29 Aug 2019 16:50:18 GMT): aatkddny (Fri, 30 Aug 2019 12:48:53 GMT): aatkddny (Fri, 30 Aug 2019 12:48:53 GMT): aatkddny (Fri, 30 Aug 2019 12:48:53 GMT): aatkddny (Fri, 30 Aug 2019 12:48:53 GMT): aatkddny (Fri, 30 Aug 2019 12:48:53 GMT): mbanerjee (Wed, 04 Sep 2019 21:37:55 GMT): mastersingh24 (Fri, 06 Sep 2019 12:06:10 GMT): sgaddam (Mon, 09 Sep 2019 09:59:11 GMT): dave.enyeart (Mon, 09 Sep 2019 16:40:40 GMT): dave.enyeart (Mon, 09 Sep 2019 16:41:05 GMT): dave.enyeart (Mon, 09 Sep 2019 16:41:22 GMT): sgaddam (Mon, 09 Sep 2019 18:25:12 GMT): rahulhegde (Tue, 10 Sep 2019 19:53:16 GMT): rahulhegde (Tue, 10 Sep 2019 19:53:16 GMT): rahulhegde (Tue, 10 Sep 2019 20:16:56 GMT): rahulhegde (Tue, 10 Sep 2019 20:16:56 GMT): jyellick (Tue, 10 Sep 2019 20:17:54 GMT): jyellick (Tue, 10 Sep 2019 20:17:54 GMT): jyellick (Tue, 10 Sep 2019 20:17:54 GMT): yacovm (Tue, 10 Sep 2019 20:18:42 GMT): yacovm (Tue, 10 Sep 2019 20:19:27 GMT): rahulhegde (Tue, 10 Sep 2019 20:24:46 GMT): yacovm (Tue, 10 Sep 2019 20:33:22 GMT): rahulhegde (Tue, 10 Sep 2019 20:37:22 GMT): rahulhegde (Tue, 10 Sep 2019 20:37:22 GMT): yacovm (Tue, 10 Sep 2019 20:46:41 GMT): rahulhegde (Tue, 10 Sep 2019 20:51:41 GMT): rahulhegde (Tue, 10 Sep 2019 21:21:41 GMT): rahulhegde (Tue, 10 Sep 2019 21:21:41 GMT): rahulhegde (Tue, 10 Sep 2019 21:21:54 GMT): rahulhegde (Tue, 10 Sep 2019 21:21:54 GMT): rahulhegde (Tue, 10 Sep 2019 21:21:54 GMT): yacovm (Tue, 10 Sep 2019 22:04:33 GMT): rahulhegde (Thu, 12 Sep 2019 13:59:12 GMT): rahulhegde (Thu, 12 Sep 2019 13:59:52 GMT): yacovm (Thu, 12 Sep 2019 14:00:42 GMT): yacovm (Thu, 12 Sep 2019 14:01:12 GMT): yacovm (Thu, 12 Sep 2019 14:01:20 GMT): rahulhegde (Thu, 12 Sep 2019 14:02:49 GMT): rahulhegde (Thu, 12 Sep 2019 14:02:49 GMT): rahulhegde (Thu, 12 Sep 2019 14:05:36 GMT): rahulhegde (Thu, 12 Sep 2019 14:06:04 GMT): rahulhegde (Thu, 12 Sep 2019 14:08:10 GMT): rahulhegde (Thu, 12 Sep 2019 14:09:46 GMT): rahulhegde (Thu, 12 Sep 2019 14:10:19 GMT): rahulhegde (Thu, 12 Sep 2019 14:10:45 GMT): rahulhegde (Thu, 12 Sep 2019 14:11:07 GMT): rahulhegde (Thu, 12 Sep 2019 14:11:07 GMT): rahulhegde (Thu, 12 Sep 2019 14:15:24 GMT): rahulhegde (Thu, 12 Sep 2019 14:15:24 GMT): yacovm (Thu, 12 Sep 2019 14:30:11 GMT): yacovm (Thu, 12 Sep 2019 14:30:45 GMT): yacovm (Thu, 12 Sep 2019 14:31:38 GMT): yacovm (Thu, 12 Sep 2019 14:31:53 GMT): yacovm (Thu, 12 Sep 2019 14:32:03 GMT): yacovm (Thu, 12 Sep 2019 14:34:52 GMT): rahulhegde (Thu, 12 Sep 2019 14:35:04 GMT): yacovm (Thu, 12 Sep 2019 14:35:11 GMT): rahulhegde (Thu, 12 Sep 2019 14:35:11 GMT): yacovm (Thu, 12 Sep 2019 14:35:18 GMT): rahulhegde (Thu, 12 Sep 2019 14:36:59 GMT): rahulhegde (Thu, 12 Sep 2019 14:37:20 GMT): rahulhegde (Thu, 12 Sep 2019 14:37:20 GMT): rahulhegde (Thu, 12 Sep 2019 14:37:42 GMT): yacovm (Thu, 12 Sep 2019 14:44:03 GMT): yacovm (Thu, 12 Sep 2019 14:44:15 GMT): yacovm (Thu, 12 Sep 2019 14:44:20 GMT): yacovm (Thu, 12 Sep 2019 14:45:18 GMT): yacovm (Thu, 12 Sep 2019 14:45:25 GMT): yacovm (Thu, 12 Sep 2019 14:50:30 GMT): rahulhegde (Thu, 12 Sep 2019 14:51:00 GMT): yacovm (Thu, 12 Sep 2019 14:51:02 GMT): yacovm (Thu, 12 Sep 2019 14:51:21 GMT): yacovm (Thu, 12 Sep 2019 14:51:25 GMT): yacovm (Thu, 12 Sep 2019 14:51:29 GMT): yacovm (Thu, 12 Sep 2019 14:51:33 GMT): rahulhegde (Thu, 12 Sep 2019 14:51:54 GMT): rahulhegde (Thu, 12 Sep 2019 14:52:08 GMT): rahulhegde (Thu, 12 Sep 2019 14:52:44 GMT): rahulhegde (Thu, 12 Sep 2019 14:58:33 GMT): rahulhegde (Thu, 12 Sep 2019 14:59:16 GMT): rahulhegde (Thu, 12 Sep 2019 15:47:35 GMT): rahulhegde (Thu, 12 Sep 2019 15:55:52 GMT): rahulhegde (Thu, 12 Sep 2019 15:58:28 GMT): rahulhegde (Thu, 12 Sep 2019 15:59:12 GMT): rahulhegde (Thu, 12 Sep 2019 15:59:12 GMT): jyellick (Thu, 12 Sep 2019 16:01:42 GMT): yacovm (Thu, 12 Sep 2019 17:18:08 GMT): yacovm (Thu, 12 Sep 2019 17:18:13 GMT): yacovm (Thu, 12 Sep 2019 17:18:26 GMT): yacovm (Thu, 12 Sep 2019 17:18:36 GMT): yacovm (Thu, 12 Sep 2019 17:21:37 GMT): jyellick (Thu, 12 Sep 2019 17:21:49 GMT): yacovm (Thu, 12 Sep 2019 17:22:14 GMT): jyellick (Thu, 12 Sep 2019 17:22:24 GMT): yacovm (Thu, 12 Sep 2019 17:22:40 GMT): rahulhegde (Thu, 12 Sep 2019 17:45:55 GMT): rahulhegde (Thu, 12 Sep 2019 17:46:14 GMT): yacovm (Thu, 12 Sep 2019 17:52:40 GMT): jyellick (Thu, 12 Sep 2019 17:52:54 GMT): yacovm (Thu, 12 Sep 2019 17:53:06 GMT): yacovm (Thu, 12 Sep 2019 17:53:08 GMT): yacovm (Thu, 12 Sep 2019 17:53:20 GMT): rahulhegde (Thu, 12 Sep 2019 17:54:55 GMT): rahulhegde (Thu, 12 Sep 2019 17:54:55 GMT): yacovm (Thu, 12 Sep 2019 17:56:25 GMT): jyellick (Thu, 12 Sep 2019 17:57:47 GMT): yacovm (Thu, 12 Sep 2019 17:57:55 GMT): rahulhegde (Thu, 12 Sep 2019 17:58:19 GMT): yacovm (Thu, 12 Sep 2019 17:58:24 GMT): rahulhegde (Thu, 12 Sep 2019 18:00:06 GMT): rahulhegde (Thu, 12 Sep 2019 18:00:06 GMT): jyellick (Thu, 12 Sep 2019 18:01:38 GMT): yacovm (Thu, 12 Sep 2019 18:02:53 GMT): yacovm (Thu, 12 Sep 2019 18:02:56 GMT): rahulhegde (Thu, 12 Sep 2019 18:07:06 GMT): rahulhegde (Thu, 12 Sep 2019 18:07:06 GMT): yacovm (Thu, 12 Sep 2019 18:08:07 GMT): yacovm (Thu, 12 Sep 2019 18:08:26 GMT): rahulhegde (Thu, 12 Sep 2019 18:09:04 GMT): yacovm (Thu, 12 Sep 2019 18:10:08 GMT): yacovm (Thu, 12 Sep 2019 18:10:18 GMT): yacovm (Thu, 12 Sep 2019 18:10:28 GMT): yacovm (Thu, 12 Sep 2019 18:11:52 GMT): rahulhegde (Thu, 12 Sep 2019 18:22:51 GMT): rahulhegde (Thu, 12 Sep 2019 18:23:36 GMT): rahulhegde (Thu, 12 Sep 2019 18:25:10 GMT): rahulhegde (Thu, 12 Sep 2019 18:26:05 GMT): yacovm (Thu, 12 Sep 2019 18:44:04 GMT): rahulhegde (Thu, 12 Sep 2019 19:21:33 GMT): yacovm (Thu, 12 Sep 2019 19:22:48 GMT): yacovm (Thu, 12 Sep 2019 19:22:58 GMT): yacovm (Thu, 12 Sep 2019 19:23:10 GMT): rahulhegde (Thu, 12 Sep 2019 19:27:12 GMT): rahulhegde (Thu, 12 Sep 2019 19:27:12 GMT): rahulhegde (Thu, 12 Sep 2019 19:27:12 GMT): rahulhegde (Thu, 12 Sep 2019 19:27:12 GMT): rahulhegde (Thu, 12 Sep 2019 19:28:29 GMT): rahulhegde (Thu, 12 Sep 2019 21:45:44 GMT): rahulhegde (Thu, 12 Sep 2019 21:45:44 GMT): yacovm (Thu, 12 Sep 2019 21:47:13 GMT): yacovm (Thu, 12 Sep 2019 21:47:30 GMT): rahulhegde (Thu, 12 Sep 2019 22:00:12 GMT): rahulhegde (Thu, 12 Sep 2019 22:00:12 GMT): yacovm (Thu, 12 Sep 2019 22:03:10 GMT): yacovm (Thu, 12 Sep 2019 22:03:39 GMT): yacovm (Thu, 12 Sep 2019 22:03:45 GMT): yacovm (Thu, 12 Sep 2019 22:04:20 GMT): yacovm (Thu, 12 Sep 2019 22:04:32 GMT): yacovm (Thu, 12 Sep 2019 22:04:43 GMT): yacovm (Thu, 12 Sep 2019 22:04:55 GMT): yacovm (Thu, 12 Sep 2019 22:05:03 GMT): yacovm (Thu, 12 Sep 2019 22:05:21 GMT): yacovm (Thu, 12 Sep 2019 22:06:01 GMT): yacovm (Thu, 12 Sep 2019 22:06:35 GMT): yacovm (Thu, 12 Sep 2019 22:07:16 GMT): yacovm (Thu, 12 Sep 2019 22:07:16 GMT): rahulhegde (Thu, 12 Sep 2019 22:35:13 GMT): rahulhegde (Thu, 12 Sep 2019 22:35:13 GMT): aymanmt (Fri, 13 Sep 2019 17:35:47 GMT): aymanmt (Fri, 13 Sep 2019 17:38:18 GMT): aymanmt (Fri, 13 Sep 2019 17:38:26 GMT): aymanmt (Fri, 13 Sep 2019 17:38:51 GMT): aymanmt (Fri, 13 Sep 2019 17:39:05 GMT): aymanmt (Fri, 13 Sep 2019 17:39:12 GMT): aymanmt (Fri, 13 Sep 2019 17:39:54 GMT): aymanmt (Fri, 13 Sep 2019 17:40:26 GMT): soumyanayak (Sat, 14 Sep 2019 13:03:07 GMT): HLFPOC (Mon, 16 Sep 2019 04:02:03 GMT): Bentipe (Thu, 19 Sep 2019 14:40:09 GMT): aatkddny (Wed, 16 Oct 2019 15:49:43 GMT): aatkddny (Wed, 16 Oct 2019 15:49:43 GMT): aatkddny (Wed, 16 Oct 2019 15:49:43 GMT): adineshreddy1 (Thu, 24 Oct 2019 14:52:19 GMT): saanvijay (Thu, 24 Oct 2019 14:52:59 GMT): rmscott (Thu, 24 Oct 2019 15:40:28 GMT): hawkinggg (Mon, 04 Nov 2019 07:15:41 GMT): DilipManjunatha (Wed, 13 Nov 2019 13:07:59 GMT): jyxie2007 (Mon, 18 Nov 2019 03:58:54 GMT): silliman (Fri, 22 Nov 2019 23:00:04 GMT): Ammu (Tue, 26 Nov 2019 08:38:33 GMT): konda.kalyan (Thu, 26 Dec 2019 06:00:03 GMT): andreevym (Sun, 29 Dec 2019 10:48:38 GMT): SanketPanchamia (Wed, 08 Jan 2020 13:07:18 GMT): SanketPanchamia (Wed, 08 Jan 2020 13:08:05 GMT): SanketPanchamia (Wed, 08 Jan 2020 13:09:55 GMT): SanketPanchamia (Wed, 08 Jan 2020 13:10:19 GMT): SanketPanchamia (Wed, 08 Jan 2020 13:52:30 GMT): dave.enyeart (Wed, 08 Jan 2020 22:07:48 GMT): SanketPanchamia (Thu, 09 Jan 2020 02:41:06 GMT): indirajith (Fri, 10 Jan 2020 14:31:22 GMT): indirajith (Fri, 10 Jan 2020 14:31:22 GMT): dave.enyeart (Fri, 10 Jan 2020 16:19:11 GMT): dave.enyeart (Fri, 10 Jan 2020 16:19:11 GMT): indirajith (Fri, 10 Jan 2020 17:14:12 GMT): dave.enyeart (Fri, 10 Jan 2020 19:54:45 GMT): kelvinzhong (Mon, 13 Jan 2020 09:06:04 GMT): SanketPanchamia (Tue, 14 Jan 2020 03:21:59 GMT): dineshthemacho1 (Wed, 22 Jan 2020 06:05:53 GMT): tennenjl (Fri, 24 Jan 2020 16:29:34 GMT): dave.enyeart (Fri, 24 Jan 2020 20:24:48 GMT): tennenjl (Fri, 24 Jan 2020 20:26:03 GMT): lzaouche (Tue, 28 Jan 2020 09:17:40 GMT): Khaled.MH (Tue, 28 Jan 2020 17:03:29 GMT): dave.enyeart (Tue, 28 Jan 2020 19:40:38 GMT): dave.enyeart (Tue, 28 Jan 2020 19:41:03 GMT): Khaled.MH (Wed, 29 Jan 2020 09:07:21 GMT): dave.enyeart (Wed, 29 Jan 2020 11:29:23 GMT): Khaled.MH (Wed, 29 Jan 2020 17:13:35 GMT): Abhishekkishor (Thu, 12 Mar 2020 19:24:21 GMT): aberwag (Tue, 24 Mar 2020 08:08:51 GMT): levanto (Sun, 29 Mar 2020 12:15:31 GMT): matanyahu (Mon, 06 Apr 2020 17:49:41 GMT): Adhavpavan (Tue, 07 Apr 2020 15:36:53 GMT): ivanovv (Fri, 24 Apr 2020 18:13:03 GMT): dave.enyeart (Fri, 24 Apr 2020 21:05:46 GMT): mbanerjee (Tue, 28 Apr 2020 21:03:55 GMT): dave.enyeart (Wed, 29 Apr 2020 12:53:02 GMT): Koushik (Wed, 29 Apr 2020 20:30:29 GMT): KoushKilla (Thu, 30 Apr 2020 11:22:01 GMT): KoushKilla (Thu, 30 Apr 2020 11:42:31 GMT): KoushKilla (Thu, 30 Apr 2020 11:43:23 GMT): HarisC (Wed, 20 May 2020 08:57:15 GMT): nonmadden (Mon, 29 Jun 2020 13:15:02 GMT): nekia (Thu, 02 Jul 2020 05:16:39 GMT): xachen (Tue, 21 Jul 2020 01:20:30 GMT): xachen (Tue, 21 Jul 2020 01:26:32 GMT): xachen (Tue, 21 Jul 2020 01:26:40 GMT): xachen (Tue, 21 Jul 2020 01:26:40 GMT): dave.enyeart (Tue, 21 Jul 2020 21:51:25 GMT): FarhanShafiq (Wed, 22 Jul 2020 08:30:55 GMT): FarhanShafiq (Wed, 22 Jul 2020 08:30:58 GMT): grapebaba (Thu, 30 Jul 2020 02:46:08 GMT): grapebaba (Thu, 30 Jul 2020 02:56:49 GMT): grapebaba (Thu, 30 Jul 2020 02:57:08 GMT): FarhanShafiq (Tue, 11 Aug 2020 12:37:26 GMT): FarhanShafiq (Tue, 11 Aug 2020 12:37:26 GMT): nkl199 (Tue, 01 Sep 2020 09:54:39 GMT): czar0 (Fri, 09 Oct 2020 11:10:18 GMT): troyronda (Wed, 28 Oct 2020 17:46:08 GMT): heena066 (Mon, 02 Nov 2020 09:32:13 GMT): husnain (Tue, 03 Nov 2020 11:44:24 GMT): cynicalsnail (Wed, 18 Nov 2020 07:01:48 GMT): nmarco (Sat, 20 Mar 2021 00:15:10 GMT): nmarco (Sat, 20 Mar 2021 13:16:51 GMT): manish-sethi (Wed, 24 Mar 2021 20:07:13 GMT): lukeledet (Thu, 08 Apr 2021 20:00:36 GMT): konda.kalyan (Sat, 22 May 2021 07:40:42 GMT): konda.kalyan (Sat, 22 May 2021 07:45:12 GMT): lcvalves (Mon, 31 May 2021 01:33:12 GMT): dave.enyeart (Fri, 04 Jun 2021 19:45:38 GMT): Maginaro (Wed, 21 Jul 2021 10:04:47 GMT): jos61404 (Sun, 29 Aug 2021 10:13:20 GMT): npc0405 (Thu, 16 Sep 2021 00:24:01 GMT): npc0405 (Thu, 16 Sep 2021 00:25:54 GMT): npc0405 (Thu, 16 Sep 2021 00:31:04 GMT): asaningmaxchain123 (Fri, 10 Dec 2021 09:21:42 GMT): asaningmaxchain123 (Fri, 10 Dec 2021 09:21:42 GMT): asaningmaxchain123 (Fri, 10 Dec 2021 09:21:50 GMT): asaningmaxchain123 (Fri, 10 Dec 2021 09:25:03 GMT): asaningmaxchain123 (Fri, 10 Dec 2021 09:46:31 GMT): asaningmaxchain123 (Fri, 10 Dec 2021 09:47:00 GMT): asaningmaxchain123 (Fri, 10 Dec 2021 09:58:47 GMT): skbalahere (Tue, 21 Dec 2021 16:53:40 GMT): Bert (Sat, 22 Jan 2022 09:25:55 GMT): rjones (Wed, 23 Mar 2022 17:35:21 GMT): rjones (Wed, 23 Mar 2022 17:35:21 GMT): rjones (Wed, 23 Mar 2022 17:35:21 GMT):
@Vadim how to interpret the first byte of channel_head [header:
enum HeaderType {
MESSAGE = 0; // Used for messages which are signed but opaque
CONFIG = 1; // Used for messages which express the channel config
CONFIG_UPDATE = 2; // Used for transactions which update the channel config
ENDORSER_TRANSACTION = 3; // Used by the SDK to submit endorser based transactions
ORDERER_TRANSACTION = 4; // Used internally by the orderer for management
DELIVER_SEEK_INFO = 5; // Used as the type for Envelope messages submitted to instruct the Deliver API to seek
}
message Header {
bytes channel_header = 1;
bytes signature_header = 2;
}
// Header is a generic replay prevention and identity message to include in a signed payload
message ChannelHeader {
int32 type = 1; // Header types 0-10000 are reserved and defined by HeaderType
// Version indicates message protocol version
int32 version = 2;
@bh4rtp are you trying to figure out how gprc/protobuf encoding is working?
@Vadim i am interesting in communication protocol. :grinning:
I guess you can start then with reading the grpc docs here: http://www.grpc.io/
@Vadim yes. the docs will help me dive in grpc. i wonder why wireshark doesn't support grpc protocol.
@MartinMateev Concerning the couchdb question - it is ready for trials. There is a fabric-couchdb docker image as well as instructions in the e2e example: https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst
Note that the instructions have some incorrect command calls, you can see the fixes here: https://gerrit.hyperledger.org/r/#/c/7251/
Is there any benchmarking being done on fabric? How are the results?
@donjohnny I suggest you ask/search on #fabric-quality
Hi
https://jira.hyperledger.org/browse/FAB-2788
I have experienced a performance problem in Fabric v0.6 when there are many (more than 10K ) records and do a query for a small number of records.
The response time become slower by 2x-6x in this case and it tooks almost 20 seconds to query 10 items in our system.
And I often observed crashes of peers in this situation.
Manish kindly told us to use 'trie' instead of 'buckettree' in config.yaml, and the performance problem is being solved now.
However, I still do not know the cause of the crashes when a transaction response is slow.
I thought this problem is similar to https://jira.hyperledger.org/browse/FAB-1163
where it is pointed out that the crash is caused by a timeout. My question is that, is there any known timeout which happens when a transaction takes too much time?
Any information is appreciated.
There was a 30s timeout that is now configurable in v1, maybe it is the same in 0.6? See the v1 fix here: https://jira.hyperledger.org/browse/FAB-2767
I am using the following repo from the Marbles v3, because I want to use the new Fabric 1.0, and I'm running into the following issue.
I'm able to start the network using `docker-compose up` from that repo, it starts fine. The problem comes with joining a channel after creating it
After that I run a `docker exec -it fabric-peer0 /bin/bash` to get into the peer node
I create a channel as so: `root@peer0:/go/src/github.com/hyperledger/fabric/peer# peer channel create -c mainchain`
and in the docker logs, this occurs, telling me it was created just fine
```
fabric-peer0 | 2017-03-17 18:28:03.288 UTC [peer] CreateChainFromBlock -> ERRO 056 Unable to get genesis block committed into the ledger, chainID mainchain
fabric-peer0 | 2017-03-17 18:27:54.382 UTC [ledgermgmt] CreateLedger -> INFO 04a Creating leadger with id = mainchain
fabric-peer0 | 2017-03-17 18:27:54.447 UTC [ledgermgmt] CreateLedger -> INFO 04b Created leadger with id = mainchain
fabric-peer0 | 2017-03-17 18:27:54.481 UTC [kvledger] Commit -> INFO 04c Channel [mainchain]: Created block [0] with 1 transaction(s)
fabric-peer0 | 2017-03-17 18:27:54.483 UTC [gossip/state] NewGossipStateProvider -> INFO 04d Updating node metadata information, current ledger sequence is at = 0, next expected block is = 1
fabric-peer0 | 2017-03-17 18:27:54.484 UTC [chaincode] Init -> INFO 04e Init CSCC
fabric-peer0 | 2017-03-17 18:27:54.484 UTC [sysccapi] deploySysCC -> INFO 04f system chaincode cscc/mainchain(github.com/hyperledger/fabric/core/scc/cscc) deployed
```
```
fabric-peer0 | 2017-03-17 18:27:54.382 UTC [ledgermgmt] CreateLedger -> INFO 04a Creating leadger with id = mainchain
fabric-peer0 | 2017-03-17 18:27:54.447 UTC [ledgermgmt] CreateLedger -> INFO 04b Created leadger with id = mainchain
fabric-peer0 | 2017-03-17 18:27:54.481 UTC [kvledger] Commit -> INFO 04c Channel [mainchain]: Created block [0] with 1 transaction(s)
fabric-peer0 | 2017-03-17 18:27:54.483 UTC [gossip/state] NewGossipStateProvider -> INFO 04d Updating node metadata information, current ledger sequence is at = 0, next expected block is = 1
fabric-peer0 | 2017-03-17 18:27:54.484 UTC [chaincode] Init -> INFO 04e Init CSCC
fabric-peer0 | 2017-03-17 18:27:54.484 UTC [sysccapi] deploySysCC -> INFO 04f system chaincode cscc/mainchain(github.com/hyperledger/fabric/core/scc/cscc) deployed
```
The problem comes with joining the channel
Running this command to join `root@peer0:/go/src/github.com/hyperledger/fabric/peer# peer channel join -b mainchain.block`
Instead of a 200 result, I get an empty result in the terminal
```
Join Result:
2017-03-17 18:39:27.786 UTC [main] main -> INFO 001 Exiting.....
```
and the corresponding logs
```
fabric-peer0 | 2017-03-17 19:09:41.489 UTC [peer] CreateChainFromBlock -> ERRO 06e Unable to get genesis block committed into the ledger, chainID mainchain
```
I've searched around, can't seem to find much on this error aside from where it is in the source
Has anyone run into this issue before? Trying to debug through it
This is the repo I'm using for the setup https://github.com/IBM-Blockchain/marbles/tree/v3.0/chaincode/src/marbles
@karysto i am testing marbles3.0. it seems to use its own specified docker images and not completely compatible with fabric 1.0.0.
@dave.enyeart Thank you! I suppose that it is fixed in v0.6. It is a good news that it becomes configurable in 1.0.
@dave.enyeart Thank you! I suppose that it is also a static value in v0.6. It is a good news that it becomes configurable in 1.0.
Howto add new organisation to existing channel?
@ruslan.kryukov Please ask in #fabric-consensus ... the configuration experts hang out over there...
Oh, okay well
Does the peer CLI support TLS - I receive `Error: grpc: no transport security set (use grpc.WithInsecure() explicitly or set credentials)` when trying to connect to my orderers.
Has joined the channel.
HI
When i try to use couchDB follow end-to-end instruction and uncomment all the # related to couchdb. And then boot up the docker-compose file, it return me below errors, any idea?
ERROR: yaml.parser.ParserError: while parsing a block collection
in "./docker-compose.yaml", line 84, column 7
expected
Has joined the channel.
Can you post lines 82 thru 96?
I got it.. it caused by indentation
Has joined the channel.
Has joined the channel.
Has joined the channel.
hello,
In the v0.6 are the actual transaction stored in the blockchain or only the Merkle root is stored? If only Merkle root is stored can I access previous transactions?
maybe it's bug, maybe not:
```
[statevalidator] validateKVRead -> DEBU 15d0 Version mismatch for key [lccc:###CHAINCODE_NAME###]. Committed version = [&{%!s(uint64=1) %!s(uint64=1)}], Version in readSet [%!s(*version.Height=
code 11 is MVCC_READ_CONFLICT
version.AreSame(committedVersion, kvRead.Version) is false
I have noticed that RangeQueryState is a member or stub (shim) but I the functions GetStateByRange or HasNext are not recognized/defined?
Any advise or examples on getQueryState and related functions, the API doc give min details?
@openspylin in v1 RangeQueryState has been renamed GetStateByRange. The best examples of the ledger data APIs are in the marbles02 example: https://github.com/hyperledger/fabric/blob/master/examples/chaincode/go/marbles02/marbles_chaincode.go
Assume 2 chaincodes (A and B) are linked to 2 channels. Is it secured that chaincode A can call chaincode B and query data from his ledger?
Assume 2 chaincodes (A and В) are linked to 2 channels. Is it secured that chaincode A can call chaincode B and query data from his ledger?
Assume there are 2 chaincodes (A and В) are linked to 2 channels. Is it secured that chaincode A can call chaincode B and query data from his ledger?
Assume we have 2 chaincodes (A and В) are linked to 2 channels. Is it secured that chaincode A can call chaincode B and query data from his ledger?
Assume we have 2 chaincodes (A and В) are linked to 2 channels. Is it secure that chaincode A can call chaincode B and query data from his ledger?
I thought that multichain was created for privacy...
Thank you dave.enyeart
hi
I wonder if there is a doc which tell detailed about what items will include orderer.block. And what is the difference between orderer.block and channel.tx ?
I thinks there is somewhere to define reader and writer things, while I have not found them in configtx.yaml file
While referring video "V1 Chaincode install and instentiate" from "https://www.youtube.com/watch?v=itn2Ps8sarE", all worked fine but we are facing one issue during the following "query" command:
CORE_PEER_ADDRESS=peer0:7051 peer chaincode query -C myc -n mycc -v v0 -c '{"Args":["query ","a"]}' -o orderer:5005
Error: "Error endorsing query: rpc error: code = 2 desc = failed to obtain cds for mycc - transaction not found mycc/myc"
Any clue please?
Thanks.
I suspect there was a hiccup during install/instantiate. I'd suggest follow the step-by-step instructions on latest v1 alpha code, they are known to work: https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst
If there four peers on the network and lets say all them are on a channel, does each peer need to install chaincode on the each peer?
Does the CC node not get propagated/replicated as they are on the same channel.
@bkvellanki it does not get propagated, whoever uses the CC needs to install it
@bkvellanki it does not get propagated, whoever used the CC needs to install it
If that is the way it is intended to be, that is fine. If not, by following the end-end.rst manually we have to install cc manually.
Thats right
Any reasoning behind that? As they are on the same channel it should propagate right?
Just thinking logically from the implementation or solution perspective
Probably due to performance reasons.
for a more detailed reasoning behind this, maybe #fabric-questions would be helpful
@dave.enyeart
chaincode-2-chaincode access gives an interface to specify channel-name, chaincode and the arguments. This means chaincode could be running on a different channel for that peer.
Could you please let know how do we specify the channel information for the MockStub Implementation - for example say example04 is running on channel say ex04channel and example02 chaincode is running on ex02channel.
@dave.enyeart
chaincode-2-chaincode access gives an interface to specify channel-name, chaincode-name and the arguments. This means chaincode could be running on a different channel for that peer.
Could you please let know how do we specify the channel information for the MockStub Implementation - for example say example04 is running on channel ex04channel and example02 chaincode is running on ex02channel.
@AdnanC - could you please check this with Dave as there will exist an impact if this is not available.
@dave.enyeart
chaincode-2-chaincode access gives an interface to specify channel-name, chaincode and the arguments. This means chaincode could be running on a different channel for that peer.
Could you please let know how do we specify the channel information for the MockStub Implementation - for example say example04 is running on channel say ex04channel and example02 chaincode is running on ex02channel.
@AdnanC - could you please check this with Dave.
@dave.enyeart
chaincode-2-chaincode access gives an interface to specify channel-name, chaincode and the arguments. This means chaincode could be running on a different channel for that peer.
Could you please let know how do we specify the channel information for the MockStub Implementation - for example say example04 is running on channel say ex04channel and example02 chaincode is running on ex02channel.
@AdnanC - could you please check this with Dave as there will exist an impact on our to-go production code if this support is not available.
@dave.enyeart
chaincode-2-chaincode access gives an interface to specify channel-name, chaincode and the arguments. This means chaincode could be running on a different channel for that peer.
Could you please let know how do we specify the channel information for the MockStub Implementation - for example say example04 is running on channel say ex04channel and example02 chaincode is running on ex02channel.
@AdnanC - could you please check this with Dave as there will exist an impact if this is not available.
@dave.enyeart
chaincode-2-chaincode access gives an interface to specify channel-name, chaincode-name and the arguments. This means chaincode could be running on a different channel for that peer.
Could you please let know how do we specify the channel information for the MockStub Implementation - for example say example04 is running on channel say ex04channel and example02 chaincode is running on ex02channel.
@AdnanC - could you please check this with Dave as there will exist an impact if this is not available.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hey, every time I start up my couchdb container, it throws a load of errors into my docker logs until I set it up as a single node via Fauxton. Is there a way to automate this process?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=9tBDRqjLipY6ozuXW) @dave.enyeart @AdnanC
I checked the MockStub code and found following changes to be done to utilize the channel functionality. During NewMockStub, MockPeerChaincode API call --> pass "chain-code-name/channel-name" as the invokableChaincodeName.
Please acknowledge.
@rahulhegde I can confirm that you need to pass the chaincode name in that format (I'm writing tests for my own chaincodes)
Has joined the channel.
Hi All, recently started migrating to v1.0 . Trying to use couchDb for state store. But unable to pull image for it.
image: hyperledger/fabric-couchdb:latest
it says ,
Pulling couchdb0 (hyperledger/fabric-couchdb:latest)...
ERROR: manifest for hyperledger/fabric-couchdb:latest not found
Does the sfhackfest.tar.gz contains the image ? do we need to provide something similar to what we did for peer,
eg: image: sfhackfest22017/fabric-peer:x86_64-0.7.0-snapshot-c7b3fe0
Anyone please suggest.
@PushpalathaHiremath please check which tags are available. There is no latest tag for any of the v1.0.0-alpha images
https://hub.docker.com/r/hyperledger/fabric-couchdb/tags/
You need something like this: `docker pull hyperledger/fabric-baseimage:
You need something like this: `docker pull hyperledger/fabric-baseimage:x86_64-1.0.0-alpha`
make sure you use the tag that corresponds to whichever platform you're using
oh i see... okay.. Let me try.. Thank you.
and one more thing, what is the way to bring all components up separately Eg : peer, cli, orderer, ca for dev env?
`docker compose up -d [service_name`]
`docker compose up -d [service_name]`
`docker-compose up -d [service_name]`
Oh and if you want to use the latest tag still.. you can retag your docker image like this:
`docker tag [container]:[tag] [new_container_name]:[new_tag]`
this will use the images is it?
It will use each service in your docker-compose
so if I do `docker compose -d peer0` only peer0 will come up.. but still with the config in the compose
if you want to run the image "as-is" without any of you docker-compose config.. you can just run `docker run [image_name]`
so if I do `docker compose -d peer0` only peer0 will come up.. but still with the config in the compose file
if you want to run the image "as-is" without any of your docker-compose config.. you can just run `docker run [image_name]`
so if I do `docker-compose -d peer0` only peer0 will come up.. but still with the config in the compose file
if you want to run the image "as-is" without any of your docker-compose config.. you can just run `docker run [image_name]`
so if I do `docker-compose -d peer0` only peer0 will come up.. but still with the config in the compose file
if you want to run the image "as-is" without any of your docker-compose config.. you can just run `docker run [image_name]:[tag]`
this way it creates container only for each service is it?
earlier there was no container created for dev mode
earlier no containers used to get created for dev mode, when we make member service and peer up separately
I'm not sure I understand what you're asking
docker-compose up -d [service_name] is like bringing up the services selectively. What i am looking for is, how do we bring the services up using commands. Eg: 'peer node start --peer-defaultchain=false' which doesn't create any containers...
Ahh I'm with you now sorry. You need to build the binaries natively. It's not something I've done before, but my understanding is that there is a make command for it
Take a look at the makefile in the fabric root. looks like the command is just `make peer`
@PushpalathaHiremath Take a look at the makefile in the fabric root. looks like the command is just `make peer`
Quote from the Makefile: `make native` - ensures all native binaries are available
okay will try that...
Before that when i try to build the code, i get compilation issues...
../vendor/github.com/miekg/pkcs11/pkcs11.go:29:10: fatal error: 'ltdl.h' file not found
#include
Has joined the channel.
When trying to join a channel I am receiving the following error:
```2017-03-23 10:40:09.898 UTC [configtx/tool/localconfig] Load -> CRIT 004 Could not find profile SampleInsecureSolo
panic: Could not find profile SampleInsecureSolo```
Prior to that debug dumps my config which does not contain the SampleInsecureSolo profile
How to issue the command so that my custom profile is picked up?
@PushpalathaHiremath completely missed your message. You need to install `libltdl-dev`
@passkit Are you using the configtxgen tool?
Has joined the channel.
> Raw transaction records are permanently stored in the ledger. While the contents of non-confidential transactions are open to all participants, the contents of confidential transactions are encrypted with secret keys known only to their originators, validators, and authorized auditors. Only holders of the secret keys can interpret transaction contents.
http://hyperledger-fabric.readthedocs.io/en/latest/FAQ/confidentiality_FAQ.html
Can any elaborate as to how these confidential transactions are achieved?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=TwaXp2EMukfojAg3S) @pd93 FYI, on RHEL based Linux, the pkg is `libtool-ltdl-devel`
@pd93 - no. I was just trying to get my peer to create a channel
`peer channel create -c mych1 -o example.com:7050
`peer channel create -c mych1 -o example.com:7050`
```2017-03-23 10:40:09.889 UTC [configtx/tool/localconfig] Load -> INFO 001 Checking for configtx.yaml at:
2017-03-23 10:40:09.889 UTC [configtx/tool/localconfig] Load -> INFO 002 Checking for configtx.yaml at: /etc/hyperledger/peer
2017-03-23 10:40:09.894 UTC [viperutil] EnhancedExactUnmarshal -> INFO 003 map[organizations:.... correct data from configtx.yaml]
2017-03-23 10:40:09.898 UTC [configtx/tool/localconfig] Load -> CRIT 004 Could not find profile SampleInsecureSolo
panic: Could not find profile SampleInsecureSolo
goroutine 1 [running]:
github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panicf(0xc4201ee720, 0xcb07e5, 0x19, 0xc420331a20, 0x1, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:194 +0x11e
github.com/hyperledger/fabric/common/configtx/tool/localconfig.Load(0xca9afe, 0x12, 0x1288b40)
/go/src/github.com/hyperledger/fabric/common/configtx/tool/localconfig/config.go:207 +0xb28
github.com/hyperledger/fabric/common/configtx/test.OrdererTemplate(0x20, 0xbebea0)
/go/src/github.com/hyperledger/fabric/common/configtx/test/helper.go:93 +0x36
github.com/hyperledger/fabric/common/configtx/test.CompositeTemplate(0x0, 0x0)
/go/src/github.com/hyperledger/fabric/common/configtx/test/helper.go:121 +0x26
github.com/hyperledger/fabric/peer/channel.createChannelFromDefaults(0xc42027b6d0, 0xc4200163f0, 0x5, 0x7fc2a165e000)
/go/src/github.com/hyperledger/fabric/peer/channel/create.go:63 +0x34
github.com/hyperledger/fabric/peer/channel.sendCreateChainTransaction(0xc42027b6d0, 0x0, 0x0)
/go/src/github.com/hyperledger/fabric/peer/channel/create.go:122 +0x159
github.com/hyperledger/fabric/peer/channel.executeCreate(0xc42027b6d0, 0xc42027b6d0, 0x0)
/go/src/github.com/hyperledger/fabric/peer/channel/create.go:141 +0x2f
github.com/hyperledger/fabric/peer/channel.create(0xc42021e6c0, 0xc4202114c0, 0x0, 0x4, 0x0, 0x7, 0x7)
/go/src/github.com/hyperledger/fabric/peer/channel/create.go:178 +0x40
github.com/hyperledger/fabric/peer/channel.createCmd.func1(0xc42021e6c0, 0xc4202114c0, 0x0, 0x4, 0x0, 0x0)
/go/src/github.com/hyperledger/fabric/peer/channel/create.go:55 +0x52
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0xc42021e6c0, 0xc420211480, 0x4, 0x4, 0xc42021e6c0, 0xc420211480)
/go/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x3e9
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x12719c0, 0xf, 0xc4201e5a98, 0x7)
/go/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x339
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x12719c0, 0x21, 0xc4201e5a98)
/go/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b
main.main()
/go/src/github.com/hyperledger/fabric/peer/main.go:111 +0x634```
@farhan3 http://hyperledger-fabric.readthedocs.io/en/latest/FAQ/confidentiality_FAQ.html is an outdated topic and not relevant to v1, please ignore it. @nickgaski can this topic be removed?
there is some discussion of v1 confidentiality here: http://hyperledger-fabric.readthedocs.io/en/latest/FAQ/architecture_FAQ.html#security-access-control
I will send it to the chopping block
@dave.enyeart Thanks!
@dave.enyeart Since there are no "confidential transactions". Is Chaincode A not allowed to access the ledger information of Chaincode B?
Has joined the channel.
Has joined the channel.
Does anyone know if there are there instructions for setting up couchdb outside vagrant?
@pd93 this may be useful, couchdb instuctions are near the bottom https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst
@AdnanC Thanks, I hadn't seen that before. I've actually already done everything that is suggested there, but the database for my channel is not there and I have to go through the setup each time I bring up the container
Not sure what I've missed here :/
Were you able to run the end-to-end test successfully?
you mean the database gets deleted when you rig down the container? you jhave to mount some container folder into host folder for that.
you mean the database gets deleted when you rig down the container? you have to mount some container folder into host folder for that.
No, the database is never created when I bring it up
Were you able to run the end-to-end test successfully?
Yes, but that was a while ago now. I think before couchdb was added
You may want to run the end-to-end with Couchdb
I'll give it a try
@AdnanC Hey thanks, Turns out I'd made a stupid error in the docker-compose file :upside_down:
It's creating the channel database now as expected, but I'm still getting a lot of repeating output from the docker logs
```
couchdb0 |
couchdb0 | [notice] 2017-03-23T19:17:09.086791Z nonode@nohost <0.323.0> -------- chttpd_auth_cache changes listener died database_does_not_exist at mem3_shards:load_shards_from_db/6(line:327) <= mem3_shards:load_shards_from_disk/1(line:315) <= mem3_shards:load_shards_from_disk/2(line:331) <= mem3_shards:for_docid/3(line:87) <= fabric_doc_open:go/3(line:38) <= chttpd_auth_cache:ensure_auth_ddoc_exists/2(line:187) <= chttpd_auth_cache:listen_for_changes/1(line:134)
couchdb0 | [error] 2017-03-23T19:17:09.086863Z nonode@nohost emulator -------- Error in process <0.1760.0> with exit value:
couchdb0 | {database_does_not_exist,[{mem3_shards,load_shards_from_db,"_users",[{file,"src/mem3_shards.erl"},{line,327}]},{mem3_shards,load_shards_from_disk,1,[{file,"src/mem3_shards.erl"},{line,315}]},{mem3_shards,load_shards_from_disk,2,[{file,"src/mem3_shards.erl"},{line,331}]},{mem3_shards,for_docid,3,[{file,"src/mem3_shards.erl"},{line,87}]},{fabric_doc_open,go,3,[{file,"src/fabric_doc_open.erl"},{line,38}]},{chttpd_auth_cache,ensure_auth_ddoc_exists,2,[{file,"src/chttpd_auth_cache.erl"},{line,187}]},{chttpd_auth_cache,listen_for_changes,1,[{file,"src/chttpd_auth_cache.erl"},{line,134}]}]}
couchdb0 |
```
if you are talking about couch logs, this is a couchdb thing, these do not indicate error, just the fact that no database has been created (yet) @pd93
@AdnanC Yeah that makes sense. This guide: http://docs.couchdb.org/en/2.0.0/install/index.html#single-node-setup indicates that we should be running the following commands to create the system databases:
```
curl -X PUT http://127.0.0.1:5984/_users
curl -X PUT http://127.0.0.1:5984/_replicator
curl -X PUT http://127.0.0.1:5984/_global_changes
```
Is this something that needs to be done? The containers do not have the curl command and the equivalent wget commands have been failing with a 401 unauthorised
@AdnanC Yeah that makes sense. This guide: http://docs.couchdb.org/en/2.0.0/install/index.html#single-node-setup indicates that we should be running the following commands to create the system databases:
```
curl -X PUT http://127.0.0.1:5984/_users
curl -X PUT http://127.0.0.1:5984/_replicator
curl -X PUT http://127.0.0.1:5984/_global_changes
```
Is this something that needs to be done? The containers do not have the curl command and when I run the equivalent wget commands, they've been failing with a 401 - Unauthorised
@AdnanC Yeah that makes sense. This guide: http://docs.couchdb.org/en/2.0.0/install/index.html#single-node-setup indicates that we should be running the following commands to create the system databases:
```
curl -X PUT http://127.0.0.1:5984/_users
curl -X PUT http://127.0.0.1:5984/_replicator
curl -X PUT http://127.0.0.1:5984/_global_changes
```
Is this something that needs to be done? The containers do not have the curl command and when I run the equivalent wget commands, they've been failing with a 401 unauthorised
for ledger funtionality, these are not needed
for ledger funtionality, running these are not needed
Ok, good to know. Thank you
@AdnanC CouchDB now appears to work, but I'm now getting: `Error endorsing invoke: rpc error: code = 2 desc = Unknown error` in the logs for my invoke command
hmm, endorsing errors, please check to see if the endorsement policies are set up correctly, and also you dont have any chaincode images from prior runs @pd93
@AdnanC Where should I be checking exactly? I have `-P "OR ('$CORE_PEER_LOCALMSPID.member')"` in my instantiate command
None of my other commands have anything to do with policies in them
That environment variable is definitely set correctly
If you are running the e2e_cli, try `-P "OR ('Org0MSP.member','Org1MSP.member')"`
I've set up my own single org with the configtxgen tool
Hmm, I would take that question to #fabric-questions, and in the meantime, if you have only 1 org, try it without any `-P`.
Hmm, I would take that question to #fabric-questions, and in the meantime, if you have only 1 org, try it without any `-P`. @pd93
What images/commit level you atre using?
What images/commit level are you using?
@AdnanC If I can't get it working I'll post over there thanks :)
I'm using the alpha images, but I'm on master. Is this a problem?
That should not be an issue, thanks
That should not be an problem, thanks @pd93
That should not be an issue, thanks @pd93
@pd93 I'm also trying to get e2e_cli working with couch... my questions are in #fabric-questions
@bobbiejc My couch set up works fine now (as far as I can tell). It's simply an endorser error that I'm getting now
@passkit you should create Configuration transaction file before, and pass it with flag -f.
you can create it with configtxgen tool
SampleInsecureProfile = "SampleInsecureSolo"
SampleSingleMSPSoloProfile = "SampleSingleMSPSolo"
this sample profiles are hardcoded and you should supply them in your configtx.yaml, otherwise you get an error.
configtx.yaml should be placed in proper folders, configtx scans this three folders: $PEER_CFG_PATH, $ORDERER_CFG_PATH and project folder (in your log this folder is /etc/hyperledger/peer)
Has joined the channel.
Has joined the channel.
@ruslan.kryukov does this mean that generating channels on the fly is impossible if you are not using the sample profiles?
@ruslan.kryukov I can see how having defaults hard coded in helps speed development and testing - but they are not at all helpful for documentation or production deployment. For example `CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer:7050 peer channel create -c myc2` from the getting started documentation only works because it is heavily dependent upon hard coded defaults.
Is there a Jira issue to address the hard coding of the sample channels. I can foresee all sorts of problems if samples are required to be left configtx.yaml. As with my example - the peer would try to register a channel with the sample profile which would not be the expected behaviour.
Is there a Jira issue to address the hard coding of the sample channels. I can foresee all sorts of problems if samples are required to be left in configtx.yaml. As with my example - the peer would try to register a channel with the sample profile which would not be the expected behaviour.
At the very least, it should be possible to specify a profile when creating from the CLI
Is it therefore that the example, `CORE_PEER_COMMITTER_LEDGER_ORDERER=orderer:7050 peer channel create -c myc2` from the getting started documentation would not be possible in a production environment because the peer is hardcoded to execute this with a sample profile?
@passkit you can add your own third profile and use it in orderer config, you can even add new channels on the fly with sdk or special file 'config transactioanal file' which can be generated by configtxgen tool and passed by cli.
Hello - do you know how can I query ledger state at a particular moment of its existence (i.e. at block x instead of the last produced block)?
I use example02 and I did a series of token exchanges between users and now I want to see how balances of both a and b were changing over time
@matanyahu check org.hyperledger.fabric.sdk.Chain#query methods from fabric java sdk. Also you can call some methods directly by peer cli. Start with core/scc/qscc/query.go
You want GetHistoryForKey. An upcoming change will add the timestamp of the tran that updated the key: https://gerrit.hyperledger.org/r/#/c/7221/
@dave.enyeart - https://gerrit.hyperledger.org/r/#/c/6795/ does not seem to be working / passing for me. it has failed in CI (my latest change was rebased on this) - https://jenkins.hyperledger.org/job/fabric-verify-x86_64/8879/console - and I get the same error when running the unit tests locally against master
I pushed a fix: https://gerrit.hyperledger.org/r/#/c/7449/
cool
thanks @dave.enyeart - I think I was almost there myself ;) in any case, I got to play around with couch ;)
this was due to a old changeset... other changes broke it between time of push and merge. i guess we should reverify before merging old changesets
@mastersingh24 this was due to a old changeset... other changes broke it between time of push and merge. i guess we should reverify before merging old changesets
yeah as this is not the first time something like this has happened
Usually things break due to compilation when old change sets are rebased, not at the unit test phase
Usually things break due to compilation when old change sets are merged, not at the unit test phase
Has joined the channel.
Hi, I am wondering what is the state of CouchDB support in Fabric v1.0? Can CouchDB be effectively used to store ledger and state of the world?
does system chaincode configurable? i see chaincodetest.yaml has the following lines.
# system chaincodes whitelist. To add system chaincode "myscc" to the
# whitelist, add "myscc: enable" to the list
system:
cscc: enable
lccc: enable
escc: enable
vscc: enable
it seems myscc can also become a system chaincode. and what is system chaincodes whitelist?
@DG0011 CouchDB is offered as a beta in v1. It can be used to store and query state information. See explanation here http://hyperledger-fabric.readthedocs.io/en/latest/ledger.html and sample usage here: https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst
@dave.enyeart Thanks!
@dave.enyeart do I need to install couchdb separately and add username/pw to it?
or will everything be done for me through yaml?
I would need to make peer again after modifying the yaml right?
If I wanted to replace couchdb and add another db instead, do you have any steps I would need to follow?
also, do you guys have any docs on how to stress test the db layer?
hi anyone know where the block data stored in the file system?
Can a node read ledger and world state data stored in its local system or is it encrypted ?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Q7kqvT8mT3LSmz5xH) @jansony1 It's stored in /var/hyperledger/production/ledgersData/chains/chains/{channelName} by default for a peer, /tmp/hyperledger-fabric-ordererledger{random-number}/ for orderer node by default
@xixuejia thanks huluwa~
:grin:
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=bWJh2SDpz4JoeGbhz) @RahulAgrawal you could read the state ledger at least with fauxton for CouchDB for now
@xixuejia I meant is it possible to read chaincode's(which are permission restricted ) state variables and their values from local system of a node as every node has its own copy of world state.
@xixuejia I meant is it possible to read chaincode's(which are permission restricted ) state variables and their values from local system of a node as every node has its own copy of world state in v0.6.
Message Attachments
@RahulAgrawal are you asking these state variables?
@RahulAgrawal nothing is encrypted, so you can read it
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=jRNviGyG7NKzGb35C) @berserkr Yes, you need an instance of CouchDB, you can make a couchdb docker image. You won't need rebuild peer after changing core.yml
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=EtdX9y8KP79SQzL6Y) @Vadim That means if a third party attacker manages to access a peer node's local storage, they can read the worldstate and even potentially alter some state variables.
if they alter the state, the results will not be consistent across peers and it will be detected
@RahulAgrawal . If some one could hack into your data center, its a big problem.
@Vadim @jansony1 but even reading the data which belongs to someone else can cause some damage to their business.
@RahulAgrawal
1) to isolate data between peers you can use channels
2) to guarantee confidentiality also on orderer levels, you can use application-level encryption
3) you should properly secure your VMs where you run fabric, just like in any other non-blockchain related use case
@RahulAgrawal
1) to isolate data between peers you can use channels
2) to guarantee confidentiality also on orderer level, you can use application-level encryption
3) you should properly secure your VMs where you run fabric, just like in any other non-blockchain related use case
also, read https://github.com/hyperledger/fabric/blob/master/docs/source/FAQ/architecture_FAQ.rst
@Vadim frankly speaking. In v1, peer belong to a specific org, so that this org could control the data and channel on this peer. In contrast, in v0.6, as long as the org enrolled in the network, it could use whichever peer it wants. With, this comparsion, I was wondering in V1, each org should would have to have its own peer.
@jansony1 that's correct
@Vadim Thank you for your response . Also is it possible to isolate data between peers in V0.6?
While this may cause some company with rare funding to join this flow ~~.
@RahulAgrawal only if you encrypt it
@jansony1 well, I would say that companies usually run their own web server, databases, etc. and don't share it with other companies. So fabric peer is also the service like that.
@Vadim how is a channel different from maintaining different blockchains? Can we selectively share some common data between them?
a channel is a different blockchain. I think it's possible to call from a chaincode in one channel another chaincode in different channel to read the data, writing won't work.
HI All, I am new to fabric 1.0. Can anyone help me to understand this error.
n/%s"}
error: [Peer.js]: GRPC client got an error response from the peer. Error: Failed to deserialize creator identity, err MSP DEFAULT is unknown
at /Users/Pushpalatha/go/FABRIC_V1.0/hackfest/node_modules/grpc/src/node/src/client.js:434:17
error: [Chain.js]: Chain-sendPeersProposal - Promise is rejected: Error: Error: Failed to deserialize creator identity, err MSP DEFAULT is unknown
at Object.callback (/Users/Pushpalatha/go/FABRIC_V1.0/hackfest/node_modules/fabric-client/lib/Peer.js:191:13)
@berserkr CouchDB enablement instructions can be found in the 'Using CouchDB' section of this document: https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst
Those instructions show that you can override core.yaml settings with docker env variables
you dont need to make peer again, for config changes to take effect
you dont need to make peer again, for config changes to take effect. these are runtime config options, they dont get compiled in. you do have to restart peer for them to take effect though.
if you wanted a different state database than goleveldb (the default) or couchdb, you would have to add a new implementation of statedb.go VersionedDB
You could follow the stateleveldb or statecouchdb packages as examples of how to do that
In terms of stress testing the data layer, there is a test harness here that will likely get merged soon: https://gerrit.hyperledger.org/r/#/c/6793/
Can you please help me with this error:
{"send_metadata":true,"send_message":true,"client_close":true,"metadata":{},"read":null,"status":{"code":2,"details":"Failed to deploy chaincode spec(Error creating image: %!s(
great, thank you @dave.enyeart !
Has joined the channel.
@dave.enyeart @mastersingh24
There is defect in https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L144
*Steps to Reproduce*
1. Install marbles02 using CouchDB
2. for instantiate ==> -c '{"Args":["init"]}'
3. for creating a marble asset ==> -c '{"Args":["initMarble","marble1","blue","1000009","tom"]}'
4. for transferring the marble asset ==> -c '{"Args":["transferMarble","marble2","jerry"]}'
Step 4 fails with
```
2017-03-28 10:51:35.662 UTC [msp] Sign -> DEBU 005 Sign: digest: E8E5581A81BEF35E104FAD041A8E81AD549C517FCFE7612B50FDE5E78505AC97
Error: Error endoatrsing invoke: rpc error: code = 2 desc = json: cannot unmarshal number 1.000009e+06 into Go value of type int
Usage:
```
Note: This doesn't get reproduced on Level-DB
*Root Cause*
statecouchdb.go for unwrapping the data namespace (removeDataWrapper) uses the generic interface representation and causes the golang JSON package API to retain the floating point representation. A integer size >= is represented with E notation internally by JSON package and this field upon un-marshalling result in the above error.
*Fix in Peer Code*
Need to replace the following line https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L147 to use json package NewDecoder API with UseNumber call.
```
decoder := json.NewDecoder(bytes.NewBuffer([]byte(myJSON)))
decoder.UseNumber()
err := decoder.Decode(&jsonResult); decoder.Decode(&jsonResult);
```
I will open a Fabric JIRA for this tracking. Can i contribute to commit?
@dave.enyeart @mastersingh24
There is defect in https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L144
*Steps to Reproduce*
1. Install marbles02 using CouchDB
2. for instantiate ==> -c '{"Args":["init"]}'
3. for creating a marble asset ==> -c '{"Args":["initMarble","marble1","blue","1000009","tom"]}'
4. for transferring the marble asset ==> -c '{"Args":["transferMarble","marble2","jerry"]}'
Step 4 fails with
```
2017-03-28 10:51:35.662 UTC [msp] Sign -> DEBU 005 Sign: digest: E8E5581A81BEF35E104FAD041A8E81AD549C517FCFE7612B50FDE5E78505AC97
Error: Error endoatrsing invoke: rpc error: code = 2 desc = json: cannot unmarshal number 1.000009e+06 into Go value of type int
Usage:
```
Note: This doesn't get reproduced on Level-DB
*Root Cause*
statecouchdb.go for unwrapping the data namespace (removeDataWrapper) uses the generic interface representation and causes the golang JSON package API to retain the floating point representation. A integer size >= is represented with E notation internally by JSON package and this field upon un-marshalling result in the above error.
*Fix in Peer Code*
Need to replace the following line https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L147 to use json package NewDecoder API with UseNumber call.
```
decoder := json.NewDecoder(bytes.NewBuffer([]byte(myJSON)))
decoder.UseNumber()
err := decoder.Decode(&jsonResult); decoder.Decode(&jsonResult);
```
http://stackoverflow.com/questions/16946306/preserve-int64-values-when-parsing-json-in-go
I will open a Fabric JIRA for this tracking. Can i contribute to commit?
@dave.enyeart @mastersingh24
There is defect in https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L144
*Steps to Reproduce*
1. Install marbles02 using CouchDB
2. for instantiate ==> -c '{"Args":["init"]}'
3. for creating a marble asset ==> -c '{"Args":["initMarble","marble1","blue","1000009","tom"]}'
4. for transferring the marble asset ==> -c '{"Args":["transferMarble","marble2","jerry"]}'
Step 4 fails with
```
2017-03-28 10:51:35.662 UTC [msp] Sign -> DEBU 005 Sign: digest: E8E5581A81BEF35E104FAD041A8E81AD549C517FCFE7612B50FDE5E78505AC97
Error: Error endoatrsing invoke: rpc error: code = 2 desc = json: cannot unmarshal number 1.000009e+06 into Go value of type int
Usage:
```
Note: This doesn't get reproduced on Level-DB
*Root Cause*
statecouchdb.go for unwrapping the data namespace (removeDataWrapper) uses the generic interface representation and causes the golang JSON package API to retain the floating point representation. A integer size >= 7 is represented with E notation internally by JSON package and this field upon un-marshalling result in the above error.
*Fix in Peer Code*
Need to replace the following line https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L147 to use json package NewDecoder API with UseNumber call.
```
decoder := json.NewDecoder(bytes.NewBuffer([]byte(myJSON)))
decoder.UseNumber()
err := decoder.Decode(&jsonResult); decoder.Decode(&jsonResult);
```
http://stackoverflow.com/questions/16946306/preserve-int64-values-when-parsing-json-in-go
I will open a Fabric JIRA for this tracking. Can i contribute to commit?
@dave.enyeart @mastersingh24
There is defect in https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L144
*Steps to Reproduce*
1. Install marbles02 using CouchDB
2. for instantiate ==> -c '{"Args":["init"]}'
3. for creating a marble asset ==> -c '{"Args":["initMarble","marble1","blue","1000009","tom"]}'
4. for transferring the marble asset ==> -c '{"Args":["transferMarble","marble2","jerry"]}'
Step 4 fails with
```
2017-03-28 10:51:35.662 UTC [msp] Sign -> DEBU 005 Sign: digest: E8E5581A81BEF35E104FAD041A8E81AD549C517FCFE7612B50FDE5E78505AC97
Error: Error endoatrsing invoke: rpc error: code = 2 desc = json: cannot unmarshal number 1.000009e+06 into Go value of type int
Usage:
```
Note: This doesn't get reproduced on Level-DB
*Root Cause*
statecouchdb.go for unwrapping the data namespace (removeDataWrapper) uses the generic interface representation and causes the golang JSON package API to retain the floating point representation. A integer size >= 7 is represented with E notation internally by JSON package and this field upon un-marshalling result in the above error.
*Fix in Peer Code*
Need to replace the following line https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L147 to use json package NewDecoder API with UseNumber call.
```
decoder := json.NewDecoder(bytes.NewBuffer([]byte(myJSON)))
decoder.UseNumber()
err := decoder.Decode(&jsonResult);
```
http://stackoverflow.com/questions/16946306/preserve-int64-values-when-parsing-json-in-go
I will open a Fabric JIRA for this tracking. Can i contribute to commit?
@dave.enyeart @mastersingh24
There is defect in https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L144
*Steps to Reproduce*
1. Install marbles02 using CouchDB
2. for instantiate ==> -c '{"Args":["init"]}'
3. for creating a marble asset ==> -c '{"Args":["initMarble","marble1","blue","1000009","tom"]}'
4. for transferring the marble asset ==> -c '{"Args":["transferMarble","marble2","jerry"]}'
Step 4 fails with
```
2017-03-28 10:51:35.662 UTC [msp] Sign -> DEBU 005 Sign: digest: E8E5581A81BEF35E104FAD041A8E81AD549C517FCFE7612B50FDE5E78505AC97
Error: Error endoatrsing invoke: rpc error: code = 2 desc = json: cannot unmarshal number 1.000009e+06 into Go value of type int
Usage:
```
Note: This doesn't get reproduced on Level-DB
*Root Cause*
statecouchdb.go for unwrapping the data namespace (removeDataWrapper) uses the generic interface representation and causes the golang JSON package API to retain the floating point representation. A integer size >= 7 is represented with E notation internally by JSON package and this field upon un-marshalling result in the above error.
*Fix in Peer Code*
Need to replace the following line https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go#L147 to use json package NewDecoder API with UseNumber call.
```
decoder := json.NewDecoder(bytes.NewBuffer(wrappedValue))
decoder.UseNumber()
err := decoder.Decode(&jsonResult);
```
http://stackoverflow.com/questions/16946306/preserve-int64-values-when-parsing-json-in-go
I will open a Fabric JIRA for this tracking. Can i contribute to commit?
@rahulhegde Please do open a Jira bug and yes, you may go ahead and assign it to yourself and start working on it
@rahulhegde there are more than a dozen places in core/ledger and examples/chaincode where json.Unmarshal() or json.NewDecoder() are utilized. I think most of them would benefit from the same fix. Could you grep for them and fix everywhere consistently? @chris.elder
@rahulhegde there are more than a dozen places in /fabric/core/ledger and /fabric/examples/chaincode where json.Unmarshal() or json.NewDecoder() are utilized. I think most of them would benefit from the same fix. Could you grep for them and fix everywhere consistently? @chris.elder
how can i get the history of my blockchain network(transactions and transactors) ? i was thinking of having a local database but i want to benefit from the blockchain to display the different trasactions executed ?
@dorrakhribi You can enable state history here: https://github.com/hyperledger/fabric/blob/master/peer/core.yaml#L392 . And according to the Node.js SDK docs, you can use Chain#queryBlock(blockNumber) https://fabric-sdk-node.github.io/Chain.html#queryBlock to get blocks.
thank you @farhan3 for the answer, and the queryBlock function i guess will return an encrypted result, do you have any idea about hwa to decrypt data stored in the blocks? i was working with the rest api and i could display the different blocks but they were encrypted.
@dorrakhribi the data/blocks are not encrypted
yes you're right @Vadim, well i have to develop a java application that should be working on blockchain, so i need to set a "real" network, i mean i have 3 pcs and i have to make hyperledger work on these hosts, i don't know if i can work with docker-compose or not. the idea that i have is that docker-compose sets a virtual network, i have tried one time to set a network of 2 hosts, mine and another. it worked but i still do net get the idea that i'm working on vms, can't i run hyperledger nativelly on hosts?
@dorrakhribi you can run it natively, but it will be the same as using docker-compose. Docker-compose is just easier to manage.
"The same" in a sense that it will be indistinguishable from your java app perspective, whether it runs on docker or not
the native way is to use vagrant @Vadim ?
you can build it on your laptop and run it from command line, if you want
ok , nom i want to know the use of core.yaml, it defines a configuration for a peer and i guess it is the same as configuring a peer from docker-compose ?
now*
it has some default config, so if you want to change something, you can either edit it directly there or use environment variables, like you see in docker-compose files
ok, but as i can see it defines the configuration of one peer , so how to associate this configuration to specific peer in the docker-compose file ? is it by giving the location of the core.yaml in the volumes field ??
no, each docker image contains its own copy of core.yaml, and properties from there get overridden by environment variables in docker-compose files
thank you very much @Vadim, now i want to ask about a detail that concerns the logic layer of my application, if i want to transfer amounts, documents between 2 users, how does this process work ? i'm using fabric v0.6 and i've heard that it does not support security enabled, i want t know how does this transfer really works?
is it related to peers communication or what ?
because i suppose that a user is not necessarly an identity of a per
peer*
@dorrakhribi I don't know v0.6
how does it happen in general ?
i mean in an application based on a blockchain
@dorrakhribi that's a very broad question... You write a smart contract which stores assets and their ownership, then you write function to transfer the asset, where you do all necessary checks (like that the caller owns the asset and so on), then from the app layer you invoke that function when you need to transfer asset
ok @Vadim thanks a lot
Has joined the channel.
Has joined the channel.
can one peer be on multiple channel
If so, does it mean that one peer has a copy/replication of data of both the channels on the same peer.
working on an issue in fabric 0.6.....retrieving more than 100 records from the ledger at one time causes chaincode to crash
found this online - https://jira.hyperledger.org/browse/FAB-860
updated my code to match the fix them mentioned....except for one thing.....they want to assemble an array of Row pointers.....[]*shim.Row.......I just assembled an array of Rows......[]shim.Row
my code doesn't work........anyone encounter this issue before?
@bkvellanki Yes a peer can be a member of multiple channels. For each channel membership, the peer will maintain a copy of the respective chain.
`Failed to generate platform-specific docker build: Error creating container: no such image`. Does Docker and the cc image need to be available on the Peer? I tried with the Docker image pulled down to the machine hosting the peer, but get the same message when trying to instantiate cc
@passkit You'll probably have more success with that question on #fabric-peer-endorser-committer channel. That's where the peer/chaincode experts hang out.
hi, how can i start a non validating peer in a network
Hi Guys, when building couchdb, do any of you have issues with dependencies not being downloaded?
I had to modify my Docker file to add rebar get-deps to get couch do build
If anyone has seen the issue with the latest image, i can open a ticket, and upload a fix
Has joined the channel.
I've been working on understanding the marbles v2 example, I've found it requires the libtool library, I'm compiling first in a windows environment, so I need some guidance in proper library linking to my system path/hyperledger project (so I must build key files from the library, must they be present in the project folder its self)?
Has joined the channel.
@openspylin - so you are trying to build / test / run your chaincode locally on a Windows system?
@dave.enyeart do you have to do anything to enable the historical queries in the couchdb on the peer?
Hmm, I can't think of anything other than setting "historyDatabase: true" in the config file core.yaml @bobbiejc if I may interject
Hmm, I can't think of anything other than setting "historyDatabase: true" in the config file core.yaml @bobbiejc
thank you
where is core.yaml file
fabric/peer/core.yaml
thanks...
it is enabled
so it sh ould be neabled by default
yes
@bobbiejc also note that the history 'index' is stored in leveldb. it has nothing to do with the couchdb state database.
upon GetHistoryForKey(), it will consult the history 'index' for the block locations of prior key/value updates and then pull the value from the block storage
ah -- that is what we were seeing
ok... hmm... we were wondering about
a) asking you to support the creation of couchdb views for query
b) writing some of those views to enable the historical query and analytics...
i now remember that is what you were doing...
Has joined the channel.
Has joined the channel.
what is the difference of ledger implementation under /core and /orderer?
what is the difference of ledger implementation between /core/ledger and /orderer/ledger?
and also find ledger implementation under /common/ledger, a bit confusing
@crazybit /core/ledger is used to represent ledger on the peers, while /orderer/ledger is for ordering service. the folder under common used for protobuf structures
Has joined the channel.
Do the ledger changes in 4e0f96ba689 break any existing ledgers that were joined with a genesis block?
```2017-04-06 10:44:17.787 UTC [peer] Initialize -> INFO 02e Loading chain esting
2017-04-06 10:44:17.787 UTC [ledgermgmt] OpenLedger -> INFO 02f Opening ledger with id = esting
2017-04-06 10:44:17.787 UTC [peer] Initialize -> WARN 030 Failed to load ledger esting(LedgerID does not exist)
```
All of the ledgers ID have had their first character cut in the logs - this ledger ID was 'testing'.
@passkit - yes, this would cause the issue that you are noticing...
Ok - would be nice to have a note in the commit if a change will be breaking
Agreed. the situation of existing ledgers did not occur to me. Thanks for pointing this out. Will keep an eye for future updates.
Is there currently any method to backup and restore a ledger?
Is your question in general or in the context of above issue?
It should be assumed that every commit is incompatible with existing data. There is no implied backward data compatibility with prior builds. Only after v1.0 GA does that become a concern.
That being said, what caused initial character to go missing?
now, since we store the state (for underconstruction ledger) in the same db where we store ledger ids, I prefix a char 'l' before ledger name to avoid the name conflict with the state key. In general, it's good to prefix so as to be flexible to allow different type of keys in the future for unforeseen functionalities.
Manish, would you agree with this statement concerning backup and restore of ledger:
The ledger directory, by default /var/hyperledger/production/ledgersData/, can be backed up and restored. If the blockchain has progressed while the peer was down and rebuilt, state transfer will resume at the backup point when the peer comes up. It is even possible to copy the ledger data between peers.
The ledger directory, by default /var/hyperledger/production/ledgersData/, can be backed up and restored. If the blockchain has progressed while the peer was down and rebuilt, state transfer will resume at the backup point when the peer comes up. It is even possible to copy the ledger data between peers when adding a new peer to the network.
It is not required to backup data, since state transfer will build it if ledger gets truncated. But backing up peer data will ensure quicker recovery from a point.
Yes, this is correct. However, just to add - if one wants to be self reliant then the bare minimum requirement for backing up is the block files in subdirs under ledgersData. The indexes etc should be built when peer is started. Just explicitly mentioned about 'self reliant' because, network should not get into a situation where peers are dependent on each other and hence no one backs up :-) - Though, even in that scenario peers can rely upon ordering service.
ok, surely this can be done while peer is down. Next question - could ledger directory backup be done while peer is actively committing blocks?
i believe only requirement is that block storage is 'ahead' of block index and state db
we also need to consider ledgerProvider
I assume in a regular setup, folks would be using some kind of filesystem level backup service. Yes, it should be OK to perform incremental backup on block files while blocks getting added. Because, in the worst case, the last block may be partially written and we handle that case during start up..
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=NLH9HiaPfK39yngWn) yes, that will always be there.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=PQHCrisFRkAtJAxz8) @dave.enyeart good point.. we would need to think a bit more on this. Because, this is stored in db and backup may not be reliable unless the db is stopped
/chains and /ledgerProvider need to be backed up in sync?
I think that this should be ok in the case of ledgerProvider, since we perform sync writes..
backup program minimally needs to backup /chains and /ledgerProvider directories right?
Yes
@manish-sethi Yes my question was in the context of breaking changes - appreciate that we are on the very bleeding edge, but also working to make applications available when the GA release finally comes. More frustrating than anything else to have to reset and rebuild a ledger.
perhaps we should put /chains and /ledgerProvider directories under a common directory (apart from state db and history db), to simplify backup procedure to a single directory
@passkit you should reset your data upon each build you take
@passkit - I agree. But need to make a balance between overall better choice v/s backward data compatibility between builds.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=a6jqC7o5CoauWahsq) @dave.enyeart Yes, it should make sense. However, I feel better would be that we allow users to just backup the /chains and have some command to populate /ledgerProvider from chains data...
how about a savepoint approach in ledgerProvider, similar to the other dbs, to make recovery automatic
I just need to think whether in a corner case this could happen that chain got created but /ledgerProvider db flush didn't hit the disk yet...
ledgerProvider is not that big it simply stores the names of the chains...
it can be rebuilt...
right, but i'm just trying to avoid manual step of a command
potentially there will be drop chain in the future
sure. let me think of this corner case first... whether it could happen or not...
ok thanks. dropping off for now...
https://chat.hyperledger.org/channel/fabric?msg=fMDvk3b74oRfDd8s4
@dave.enyeart ...can you help with the above please ^^^
@rahulhegde Request-1 will get invalidated at commit time due to state validation (expecting nothing in state but found key1 from t2
@rahulhegde Request-1 will get invalidated at commit time due to state validation (expecting nothing in state but found key1 from t2)
Another question - In a single Endorsement Request, there are more than 1 ==> Shim.PutState calls. Is the last call to Shim.PutState be effective on Ledger?
Another question - In a single Endorsement Request, there are more than 1 ==> Shim.PutState calls to the same Key. Is the last call to Shim.PutState be effective on Ledger?
yes
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Amoqe6DpWHomTyPmL) @dave.enyeart Thank you.
Has joined the channel.
i've used a 150k long string as an argument when i invoke a chaincode. i'd like to store it in the state as a value. but i got an error said that argument is too long. anybody know this limitation? how could we break it?
Started an orderer with a genesis block, trying to join the peer with the same genesis block and receive the following errors:
```
CORE_PEER_GOSSIP_SKIPHANDSHAKE=true CORE_PEER_ADDRESS=us-east-example.com:7051 peer channel join -c passkit -b $PEER_CFG_PATH/genesis.block -o $CORE_PEER_COMMITTER_LEDGER_ORDERER
Peer joined the channel!
```
```
2017-04-07 03:41:52.018 UTC [protoutils] ValidateTransaction -> ERRO 032 validateCommonHeader returns err invalid header type ORDERER_TRANSACTION
2017-04-07 03:41:52.018 UTC [txvalidator] Validate -> ERRO 033 Invalid transaction with index 0, error %!s(
Using latest 56193e9
Using latest snapshot 56193e9
Subsequent channels created and joined with a block have no issues
Also, creating a channel returns an `EOF` error, although the channel creates successfully
```CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/fabric/msp/passkit CORE_PEER_LOCALMSPID="PASSKIT" peer channel create -o $CORE_PEER_COMMITTER_LEDGER_ORDERER -f $PEER_CFG_PATH/channels/testing.channel.tx -c testing --tls true --cafile /etc/hyperledger/fabric/ssl/ca-chain.cert.pem
Got status &{NOT_FOUND}
Error receiving: EOF
Error: EOF```
Instantiating Chaincode also no longer works
```
CORE_PEER_ADDRESS=us-east-2a.blockchain.passkit.com:7051 peer chaincode instantiate -o $CORE_PEER_COMMITTER_LEDGER_ORDERER -C testing -n testcc -v 0 -c '{"Args":["init","a", "1000", "b","2000"]}' --tls true --cafile /etc/hyperledger/fabric/ssl/ca-chain.cert.pem
```
Instantiating Chaincode also no longer works
```
CORE_PEER_ADDRESS=us-east-2a.example.com:7051 peer chaincode instantiate -o $CORE_PEER_COMMITTER_LEDGER_ORDERER -C testing -n testcc -v 0 -c '{"Args":["init","a", "1000", "b","2000"]}' --tls true --cafile /etc/hyperledger/fabric/ssl/ca-chain.cert.pem
2017-04-07 04:20:42.961 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2017-04-07 04:20:42.961 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: Error endorsing chaincode: rpc error: code = 2 desc = Transaction returned with failure: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
```
```
2017-04-07 04:20:42.228 UTC [chaincode] processStream -> ERRO 081 Got error: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
```
Instantiating Chaincode also no longer works
```
CORE_PEER_ADDRESS=us-east-2a.example.com:7051 peer chaincode instantiate -o $CORE_PEER_COMMITTER_LEDGER_ORDERER -C testing -n testcc -v 0 -c '{"Args":["init","a", "1000", "b","2000"]}' --tls true --cafile /etc/hyperledger/fabric/ssl/ca-chain.cert.pem
2017-04-07 04:20:42.961 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2017-04-07 04:20:42.961 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: Error endorsing chaincode: rpc error: code = 2 desc = Transaction returned with failure: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
```
Peer log:
```
2017-04-07 04:20:42.228 UTC [chaincode] processStream -> ERRO 081 Got error: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
```
Instantiating Chaincode also no longer works
```
CORE_PEER_ADDRESS=us-east-2a.example.com:7051 peer chaincode instantiate -o $CORE_PEER_COMMITTER_LEDGER_ORDERER -C testing -n testcc -v 0 -c '{"Args":["init","a", "1000", "b","2000"]}' --tls true --cafile /etc/hyperledger/fabric/ssl/ca-chain.cert.pem
2017-04-07 04:20:42.961 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2017-04-07 04:20:42.961 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: Error endorsing chaincode: rpc error: code = 2 desc = Transaction returned with failure: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
```
Peer log:
```
2017-04-07 04:20:42.228 UTC [chaincode] processStream -> ERRO 081 Got error: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
```
Above was for go example02, but is same for all other CC
@passkit you should use the channel config tx to join the channel, not the orderer genesis block
Can you point me to the syntax required - I have tried to use the channel.tx files but it would always fail
so you should generate two files - orderer.block and channel.tx, orderer.block you set over ORDERER_GENERAL_GENESISFILE variable when starting the orderer, channel.tx you should use in peer channel create/join calls
see the e2e_cli example for more info
Has left the channel.
e2e_cli joins with the block
`peer channel join -b $CHANNEL_NAME.block >&log.txt`
Line 54: scripts/script.sh
Creating channels with the tx and joining with the block works. What doesn't woek for me is joining the channel that the orderer was bootstrapped with
@vadim Creating channels with the tx and joining with the block works. What doesn't woek for me is joining the channel that the orderer was bootstrapped with
this is not the same block as the orderer block
this is result of peer channel create command
this is the result of peer channel create command
i understand that
then what are you trying to do?
My issue is how to join a peer to a bootstrapped channel
you cannot use orderer block to join the channel, this is what I understood you are trying to do
So - the orderer is bootstrapped with a block. How can I join that channel?
orderer block is a different thing
it does not describe a peer channel
ok, lemme try the other way. Have you run peer channel create?
ok, lemme try the other way. Have you run `peer channel create`?
can you post the command here?
No - have created locally with configgentx
you still need to run it, that's the thing
peerorg1peer1
https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/scripts/script.sh#L43
when you run the peer channel create you will get a DIFFERENT block, which you should use in peer channel join, get it?
`CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/fabric/msp/passkit CORE_PEER_LOCALMSPID="PASSKIT" peer channel create -o $CORE_PEER_COMMITTER_LEDGER_ORDERER -f $PEER_CFG_PATH/channel.tx -c passkit --tls true --cafile /etc/hyperledger/fabric/ssl/ca-chain.cert.pem`
the channel.tx here is from the orderer bootstrap block
what happens if you run it?
But running that gives me `Error: Got unexpected status: BAD_REQUEST`
well see the orderer logs for details
`2017-04-07 06:30:49.922 UTC [orderer/common/broadcast] Handle -> WARN 120 Rejecting CONFIG_UPDATE because: Error validating DeltaSet: Attempt to set key [Values] /Channel/OrdererAddresses to version 0, but key is at version 0
2017-04-07 06:30:50.127 UTC [orderer/common/deliver] Handle -> WARN 121 Error reading from stream: stream error: code = 1 desc = "context canceled"
`
```2017-04-07 06:30:49.922 UTC [orderer/common/broadcast] Handle -> WARN 120 Rejecting CONFIG_UPDATE because: Error validating DeltaSet: Attempt to set key [Values] /Channel/OrdererAddresses to version 0, but key is at version 0
2017-04-07 06:30:50.127 UTC [orderer/common/deliver] Handle -> WARN 121 Error reading from stream: stream error: code = 1 desc = "context canceled"
`
are you trying to do the e2e cli example by hand?
Yes
seems that orderer is not correctly configured
Everything was working correctly before the last build
you still running in docker-compose?
I'd say you've got some mixed state
not via docker-compose. Let me check if something else has been added.
you need to make sure that the peers/orderers start with fresh chains
Was trying on a flushed chain. But will reset and try again.
I don't receive any errors on the orderer when creating other channels - although as mentioned above, the value returned to the CLI peer is `EOF`
```
CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/fabric/msp/passkit CORE_PEER_LOCALMSPID="PASSKIT" peer channel create -o $CORE_PEER_COMMITTER_LEDGER_ORDERER -f $PEER_CFG_PATH/channels/testing.channel.tx -c testing --tls true --cafile /etc/hyperledger/fabric/ssl/ca-chain.cert.pem
Got status &{NOT_FOUND}
Error receiving: EOF
Error: EOF
```
Just re-ran on a flushed chain and have the same error for the bootstrap block. This block was generated exactly the same as the other channels
so the actual error here is Got status &{NOT_FOUND}, and you don't see anything on the orderer? I suppose it's run with DEBUG log level?
also, where do you run this command? in the cli?
@passkit
Running command in CLI and orderer is running debug logs
I can successfully join FWIW, my orderer is a Kafka orderer
what's FWIW?
also, what do you mean "I don't receive any errors on the orderer when creating other channels"? How is this channel different from other channels?
For what it is worth - means For information
ah, I thought it's some special channel you have ;)
So - Orderer bootstrap channel -> Orderer log errors -> CLI failure -> Channel create Failure
So - Orderer bootstrap channel -> Orderer log errors -> CLI &{BAD_REQUEST} -> Channel create Failure
Any other channel -> No Orderer log errors -> CLI &{NOT FOUND} -> Channel create Success
I don't get what in your terminology is "orderer bootstrap channel"
anyway, have you tried with script.sh?
does it also fail?
The channel in the Orderer genesis block
yes, which you set over config and which you don't explicitly join
Are you saying that the peer will automatically join the channel in the orderer genesis block?
Pfr_20117
The orderer channel is for orderers, not for peers, so peers don't need to join it
Ok - that makes sense - was not clear from the documentation.
Thanks a lot for your patience clearing that up.
So I am left with two problems - the &{NOT_FOUND} error when creating peer channels (although this seems benign as the channels are created), and the more pressing matter that Chaincode will no longer instantiate.
```
CORE_PEER_ADDRESS=us-east-2a.example.com:7051 peer chaincode instantiate -o $CORE_PEER_COMMITTER_LEDGER_ORDERER -C testing -n testcc -v 0 -c '{"Args":["init","a", "1000", "b","2000"]}' --tls true --cafile /etc/hyperledger/fabric/ssl/ca-chain.cert.pem
2017-04-07 04:20:42.961 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 001 Using default escc
2017-04-07 04:20:42.961 UTC [chaincodeCmd] checkChaincodeCmdParams -> INFO 002 Using default vscc
Error: Error endorsing chaincode: rpc error: code = 2 desc = Transaction returned with failure: Failed extracting proposal fields. [Could not extract the channel header from the proposal: UnmarshalChannelHeader failed, err proto: bad wiretype for field common.ChannelHeader.Type: got wiretype 2, want 0]
```
so the chaincode won't instatntiate because the channel is not created
so you have to solve that issue first
But even I get a message, the channel is created.
CLI:
```
CORE_PEER_MSPCONFIGPATH=/etc/hyperledger/fabric/msp/passkit CORE_PEER_LOCALMSPID="PASSKIT" peer channel create -o $CORE_PEER_COMMITTER_LEDGER_ORDERER -f $PEER_CFG_PATH/channels/testing.channel.tx -c testing --tls true --cafile /etc/hyperledger/fabric/ssl/ca-chain.cert.pem
Got status &{NOT_FOUND}
Error receiving: EOF
Error: EOF
```
Will post orderer log as a file
Message Attachments
And the peer can join the channel with no problem:
```
2017-04-07 07:35:32.200 UTC [ledgermgmt] CreateWithGenesisBlock -> INFO 023 Creating ledger [testing] with genesis block
2017-04-07 07:35:32.493 UTC [kvledger] Commit -> INFO 024 Channel [testing]: Created block [0] with 1 transaction(s)
2017-04-07 07:35:32.557 UTC [ledgermgmt] CreateWithGenesisBlock -> INFO 025 Created ledger [testing] with genesis block
2017-04-07 07:35:32.561 UTC [gossip/gossip#peer-us-east-2a.blockchain.passkit.com:7051] learnAnchorPeers -> INFO 026 Anchor peer with same endpoint, skipping connecting to myself
2017-04-07 07:35:32.563 UTC [gossip/state] NewGossipStateProvider -> INFO 027 Updating node metadata information, current ledger sequence is at = 0, next expected block is = 1
```
Ok - so channels are being created and have fixed the instantiation - looks like it was because one peer had an outfated fabric-ccenv
Thanks very much @Vadim for taking time to help. I still have the &{NOT_FOUND} error, but can live with that for now
no problem
I have another issue though. If I try to commit 3 transactions to three separate peers quickly, at least one transaction fails with `Block [7] Transaction index [1] TxId [1574d12897b597c12d92b4cf4bdece14d7b269822e5bad9efdbd8a48cb66334d] marked as invalid by state validator. Reason code [11]`
@passkit if you modify the same state in this transactions, then the orderer will not allow that
this is considered to be a double-spending case
Ok - but how to handle high volumes? There could be many simultaneous transactions acting on the balance of an account.
you can record the balance changes and settle them periodically
I am thinking earning and burning of loyalty points. Even across a small department store there could be 2 or more transactions simultaneously increasing or reducing the organisations loyalty liability.
Is it unreasonable to expect Kafka to manage this atomically?
no, it's about RW sets that peers deliver
e.g. balance of A is 100, then you send 3 transactions each transfers 10 units to somewhere. These transactions end up in the same block. FOr the first transaction the peer will calculate 100-10 = 90, for the second again 100-10=90 and for the third 100-10 = 90, so first will be valid, the other two not
so you either dont concurrently modify the state or monitor which transactions invalid and repeat them
Got it, although I can foresee problems across many applications with this design principle. Particularly in investment banking high volume structured products and algorithmic trading scenarios where the delays would grow exponentially.
I can't really comment this design principle as I'm not in the team, it's just the way it is and it is coming from the fact that chaincode simulation happens on one node, and consensus on the other node.
Been trying to use the 'sort' field in one of my couchdb queries, but am getting: `no_usable_index,missing_sort_index`. I'm new to couchdb and I never used mongodb either. How would I go about creating a sort index?
Currently there is no provision for automatically creating indexes in fabric. Indexes to support sorting in couchdb queries must be created externally.
There are two options for creating indexes.
1. Use the fauxton interface to create the index.
Visual guide for fauxton is found here:
http://couchdb.apache.org/fauxton-visual-guide/
2. Create the index using curl to define the index.
CouchDB documentation for creating indexes using REST can be
found here:
http://docs.couchdb.org/en/2.0.0/api/database/find.html
under 10.3.5. /db/_index
Also, there are examples for creating and using indexes in the
header information in the marbles02.go example located here:
/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go
@dave.enyeart Could you help review https://gerrit.hyperledger.org/r/#/c/7605/? Thanks.
Hi, I've few questions on V1- 1) does fabric V1 has global ledger/chain as it is in Fabric (v0.6) 2) in V1, can two different chaincodes on different channel invoke /query each other?
does fabric support kafka now?
@chris.elder Thanks for the info. Only just saw this
Will there be options in the future to create these indexes via the CLI/SDK? This would be really handy.
There has been some discussion, but I am not sure if that will make the cut for 1.0
I agree, those would be very good additions
Has joined the channel.
Has joined the channel.
Is there any documentation on how the ledger (i.e. blocks) are stored on the file system. By ledger I mean the hashchain of blocks and not the world state. Currently I see they are in /var/hyperledger/production/ledgersData. The ledger appears to be in ledgersData/chains/. There is also index folder here - what does this contain? In addition, what is stored within /ledgersData/historyLeveldb and /ledgersData/ledgerProvider?
Has joined the channel.
@dave.enyeart when using CouchDB for world state, is there any concept of schemas or is everything dumped to only one collection of key/id and value/json document? Also, when using CouchDB what is the default security, if any, that is used?
@jdockter couchdb doesnt have a concept of schemas/collections, if i understand your question
by default couchdb does not enable user security, but we'll show you how to enable it: https://gerrit.hyperledger.org/r/#/c/7099/11/images/couchdb/local.ini
@dave.enyeart as the db grows, ie thousands or millions of rows, is there any concept of indexes to some how improve performance?
yes, you can create indexes in couchdb
sorry if this is all covered in some documents, just getting back up to speed with all the HLF v1 changes
we may enable creating indexes from peer in future, for now you have to create those indexes manually against couchdb
is there a place I can reset of what has been developed and committed related to CouchDB to the current alpha code base?
not much change since alpha in terms of function. you'd have to look at the change history, for example: https://github.com/hyperledger/fabric/commits/master/core/ledger/util/couchdb/couchdb.go
sorry, should have been more clear, looking for documentation
@nhrishi there is no global chain. only channels. There is a chaincode API InvokeChaincode() where you can pass a different channel name. This can be used to query another chaincode on another channel, but will not update the remote channel
@jdockter this example chaincode demonstrates usage of couchdb for storing/querying json, as well as some index examples:
https://github.com/hyperledger/fabric/blob/master/examples/chaincode/go/marbles02/marbles_chaincode.go
@dave.enyeart thanks. Just to confirm, are we saying invokeChaincode() can be used to only to query other chaincode from different channel and not for invoke ?
everything is an chaincode invoke in v1. so technically you do 'invoke' and will get back the chaincode response (which is typically populated with query results from that chaincode). but if the called chaincode on the remote channel did any Puts(), these will be ignored... the remote chain is not updated.
a common scenario is to have a public channel with reference information, and private channels for transactions.
okay. but there would be scenarios where we'll need 2 chaincodes on 2 different private channels invoke each other.
@here Is there an c sdk/api all to find out all the smartcontracts installed on a channel for a user?
Has joined the channel.
Has joined the channel.
Hi, when I run the docker-compose up, I keep getting these messages:
peer0 | 2017-04-07 06:03:47.725 UTC [gossip/discovery#172.18.0.3:7051] handleAliveMessage -> ERRO 01b Bad configuration detected: Received AliveMessage from a peer with the same PKI-ID as myself: tag:EMPTY alive_msg:
@subbu165 Please post in #fabric-gossip channel
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=bp6gmTJkKMQGK92rv) @subbu165 This message warns that you have configured two peers using same certificate, you just need to fix it and have two peers using separate certificates.
@C0rWin thanks for the reply. Actually once I remove the peer configuration 'CORE_PEER_GOSSIP_BOOTSTRAP=peer0:7051' from other peers in the docker compose yaml, this error is gone. May be its because of the same reason you are talking about.
peers simply stopped to try build gossip network
Has joined the channel.
Hi All, I have a doubt.
I am setting some cache in init method and trying to use it in invoke(query). In the dev mode i'm able to work with this. But in prod mode i see some weird behaviour.
1. The cache set in deploy(init function) is not available to invoke methods
2. But the cache set under invoke is available during multiple calls to invoke.
3. I see after the deploy(init function) there is no container created. But after invoke the container gets created and which will have only the invoke logs, init method logs are not seen here.
4. But any PutState we do in deploy(init function) is available to invoke function.
For cache storage i'm using https://github.com/patrickmn/go-cache
Can you please help me to understand this.
@PushpalathaHiremath There is no cross-transaction caching supported, transactions should only share data via state variables. There are no guarantees around life cycle of a container.
@PushpalathaHiremath There is no cross-transaction caching supported, transactions should only share data via state variables. There are no guarantees around life cycle of a chaincode container.
Has joined the channel.
I'm currently engaged in implementing a schema for blockchain transaction pruning in Hyperledger v0.6. I've been reading the source code that manages state transfers, blocks, states, etc. and want to make sure that I've understood the state synchronization procedure properly, so I can be confident about the properties of the system, and how my changes affect those properties. From what I have been able to discern to far, each peer keeps a ledger. The ledger consists of a blockchain and a state, which is essentially whatever aggregate data structure is chosen to represent the result of evaluating all blockchain transactions. The state is divided into tree primary elements, which are (1) the actual database, (2) a collection of state deltas, and (3) a currently evaluated transaction. When querying the ledger state, the choice must be made whether to first look in (3) and then (2), or to look directly in (1). My question is, what is the correspondence between the blockchain and the state deltas? Are the state deltas exclusively representing transactions not yet represented by a blockchain block, or could there be uncommitted blocks in the blockchain? Thank you.
*tree=three
Has joined the channel.
Has joined the channel.
Has joined the channel.
On V1-0; for chain-code 2 chain-code query access ( ` stub.InvokeChaincode ` ), we are seeing a request timed-out. Few request worked fine however it failed after some time. Anyone has seen this case or potential reason?
@muralisr @dave.enyeart
On V1-0; for chain-code 2 chain-code query access ( ` stub.InvokeChaincode ` ), we are seeing a request timed-out. Few request worked fine however it failed after some time. Anyone has seen this case or potential reason?
@muralisr @dave.enyeart
On V1-0; for chain-code 2 chain-code query access ( ` stub.InvokeChaincode ` ), we are seeing a request timed-out. Few request worked fine however it failed after some time. Anyone has seen this case or potential reason?
CC: @Ratnakar
@muralisr @dave.enyeart
On V1-0; for chain-code 2 chain-code query access ( ` stub.InvokeChaincode ` ), we are seeing a request timed-out. Few request worked fine however it failed after some time. Anyone has seen this case or potential reason?
CC: @Ratnakar #fabric
Hi All,
As in fabric 0.6 version hfc we had build-chaincode where the chain code used to get copied , where will it be in v1.0?
I'm using some static configuration files in my chain code, so i want to know the chiaincode's path.
@PushpalathaHiremath in 1.0 you cannot copy user config files as part of the package (esp. after https://gerrit.hyperledger.org/r/#/c/6991/ gets merged)
@muralisr : oh.. okay.. So what is the way to use static config files now? Any suggestions?
one way certainly would be send the data with init and store it on the ledger
@muralisr : We do have very large and frequently changing config files.. That's why we used static files instead storing into ledger.. Anyways, if we do not have any other option may be we need to store into ledger / store into off block / may be we need to have it in application layer only ..
if you have frequently changing config files how do you update them ?
@here Is none able to give me any directions or suggestions regarding the relation between blockchain blocks, state and state deltas? Thank you.
In particular, I'm curious about the relationship between state deltas and the blockchain blocks. Are the state deltas and the state together holding a state equivalent to the aggregate of all blockchain blocks? Is there a concept of pending or uncommitted blocks in the blockchain? What determines the amount of state deltas?
@epal I think the lack of response is due to the fact that most of the community has moved on to v1. The 0.6 design and questions do not apply to v1.
Alright. Thanks. I'm understanding more and more from reading the source code, so I guess I'll be able to manage in the end. It would, however, be nice to get some kind of confirmation that my understanding is correct.
@dave.enyeart for v1, if I have two peers on the same channel, would each peer have it's own ledger (world state + transaction log)? If so, when I use couchdb I would then assume I would want each peer to be configured in the yaml file to reference couchdb, thus getting two extra containers for each instance of couchdb? Or do I have that wrong?
Has joined the channel.
@jdockter Each peer has its own chain per channel, and statedb per channel. In CouchDB, this is implemented as the peer having one CouchDB instance/container, partitioned into N databases for the N channels. The N databases all run within a single CouchDB process.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=cYe8CPLvfpsrTpmNW) @epal As @dave.enyeart pointed out, the question belongs to the version v0.6. The state-delta is the change-set that is caused by the transactions in the corresponding block. There is one-to-one relation between state-delta and it's block. The main use of state-deltas are for state transfer when a peer wants to catch up with the network. Instead of executing the transactions in the block, the state deltas are applied to the world-state and new state-hash is computed and matched with the what is present in the block.
In v1.0, these state-deltas are part of block it self (in the form of write-set) and the granularity of deltas is at the transaction level (instead of block level).
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=cYe8CPLvfpsrTpmNW) @epal As @dave.enyeart pointed out, the question belongs to the version v0.6. The state-delta is the change-set that is caused by the transactions in the corresponding block. There is one-to-one relation between state-delta and it's block. The main use of state-deltas are for state transfer when a peer wants to catch up with the network. Instead of executing the transactions in the block, the state deltas are applied to the world-state and new state-hash is computed and matched with the what is present in the block.
In v1.0, these state-deltas are part of block itself (in the form of write-set) and the granularity of deltas is at the transaction level (instead of block level).
@manish-sethi Perfect answer! That was just what I was looking for. This confirms my understanding from reading the source code. Thank you for pointing out the difference in 1.0.
@epal - to your question about "What determines the amount of state deltas?" It's a configurable thing. By default, the state deltas are maintained for last 500 blocks and they are completely optional and hence not required to interpret the world-state as such. The world-state data structure is always up to date with block height. I am not sure what are you intending to do with v0.6 codebase but I would recommend to move on to v1.0 codebase as the previous version is no longer going to be maintained actively.
I'm creating a Proof-of-Concept for my Master's thesis. The topic of the thesis is blockchain transaction pruning.
The idea is basically identifying transactions that are not historically interesting and removing them from history, while not preventing the operation of the consensus algorithm in any way.
There are, of course, lots of problems with removing history, but the point is not that you should remove transactions, but what happens if you do.
cool, this is going to be relevant for v1.0 as well soon. But agreed that it would be easier with v0.6 because each blocks contain the world state hash
cool, this is going to be relevant for v1.0 as well soon. But agreed that it would be easier with v0.6 because each block contains the world state hash
Thank you again for your feedback. I might drop a link to my thesis once it is completed and scrutinised here. ;)
sure. All the best :-)
Hi - is there a way to add additional peers to a channel after the channel's initial creation? I've read that you would send another config transaction, but is this API exposed through the commandline?
@kostas Could you take a look at farhan3's question?
hi everyone, how can i decrypt the transaction content using the users certificates ?
@farhan3: This is indeed possible via a properly constructed + signed config transaction that adds another peer org (from the same consortium) the Application group of that channel. This functionality however is not yet exposed via a command-line tool, such as configtxgen.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=JGNWSLFnw3NKHRrF9) @kostas Thanks! Are there plans to expose this in v1.0? Or an ETA
@farhan3: I'm skeptical as to how useful `configtxgen` will actually be in this, or in any workflow where multiple signatures are required for that matter. Your best bet for this functionality is the SDK (node.js or Java), so I'd turn to the respective chatrooms here for ETAs.
Ok, will check there
can someone take a look at this CI failure: https://jenkins.hyperledger.org/job/fabric-verify-x86_64/9949/console ? @dave.enyeart
@mastersingh24 @chris.elder I have seen that locally after the 20s timeout was put in place. It is intermittent. This is the first I have seen it in CI. Basically a create db request to CouchDB took 27s here. I timed out after 20s and then upon retry we get an error due to conflict (presumably because another thread in CouchDB just created the DB). We are taking a deeper look and will work with the CouchDB experts to understand why it may take > 20s sometimes, even though it is almost always subsecond at other times.
@mastersingh24 @chris.elder I have seen that locally after the 20s timeout was put in place. It is intermittent. This is the first I have seen it in CI. Basically a create db request to CouchDB took 27s here. It timed out after 20s and then upon retry we get an error due to conflict (presumably because another thread in CouchDB just created the DB). We are taking a deeper look and will work with the CouchDB experts to understand why it may take > 20s sometimes, even though it is almost always subsecond at other times.
cool - I figured it was something like that but wanted to make sure
thx @dave.enyeart - cool - I figured it was something like that but wanted to make sure
Has joined the channel.
Has joined the channel.
@here Lets say an org want to need to migrate from one version of fabric (alpha) to another (prod or beta). Is there any document that explains all the items to be backed up.. that we need to backed up..I can definitely see smart contracts, DB, tx, orderer, block..I trying to see if there is any atrifact that explains a smooth transition
@bkvellanki there is not runtime compatibility between various development builds. you should keep your client app source code and chaincode source code (changes there have mostly been additions). but you should not move runtime data across development builds.
@dave.enyeart thanks. I will try and keep you posted.
@dave.enyeart It would also help to create an artifact that has the steps for upgrade process. This not only for alpha to beta but for future upgrades as well
agreed. please create a Jira item or post in #fabric-documentation
@dave.enyeart sure will do
I've got a question about the configuration transaction -- is putting cryto material in the config tx intended to facilitate usage of arbitrary CA, instead of a specific one? In other words, where the relevant certs are already in the blockchain as first-class data, and whatever CA is being used can start from that?
Are there other intents behind that design as well?
Has joined the channel.
My apologies if this has already been asked before, if a bad actor modifies the state of an asset in levelDB or couchDB, and a query is later done against that asset, is there anything that is done to detect tampering? I get that it would be detected if we were doing a transaction, but what about queries? Thanks!
@tennenjl You would have to do what we call a 'strong query', which means query multiple peers and ensure you get the same results from each. There has been talk of adding explicit verification function in the future, for example re-calculating the hashes and ensure they still sync up and that the chain data is still in sync with state db data.
@dave.enyeart awesome, we were wondering about the multiple query approach. Guessing that the explicit verification function could be an option where performance is a determining factor
I hope that I am asking at a right channel. If not, please redirect me to a right place: I was curious if anyone tested a query of historical data from block 1 until the world state from, let's say, a ledger composed of hundreds of thousands of blocks. This would be a typical task of an auditor, and a very frequent one. Is the historical state of an asset written into the ledger queried block per block, straight from a ledger copy or are there any other methods to do so? I am curious if this operation is read-intensive so that it would have to be off-loaded to an external (i.e. non-blockchain) repository, such as a ledger replica on a conventional DB.
@matanyahu Which APIs specifically are you asking about? Most of the queries hit efficient indexes rather than scanning all blocks. For example GetHistoryForKey() internally hits an index to find which blocks have updated a certain key. And then only those blocks are parsed to return the historical values.
@dave.enyeart : thanks for this tip. So I assume GetHistoryForKey() would only be available through HFC SDK?
APIs like GetHistoryForKey() are available to call in chaincode. The chaincode would be called via standard proposal invoke from an application client (likely using an SDK).
Has joined the channel.
I would like to know if there are any ways to migrate data from an existing ledger to another ledger, both being absolutely unrelated to each other?
let's say, I started on a Blockchain on Bluemix instance (0.6) and I set up an instance in my local datacentre
and I do not want to start from scratch
hello everybody, is there a way to decrypt the transactions stored in the ledger ?
Has joined the channel.
I have some init methods in my chaincode that create users/assets on the ledger. These methods have checks that make sure an asset cannot be assigned to a user that does not exist. My issue is that even though my user is created before the asset is assigned, I receive an error telling me that the user is not found. This same method works later when called from the SDK. Is this by design?
@pd93 yes this is by design. Reads always come from committed state. If you write previously in the same tran it is not committed and therefore not read.
@dave.enyeart Thanks. I suspected this was the case, so I tried removing those methods from my `Init()` and running them separately. Each with their own invoke call. Unfortunately, this still didn't work. Does the above also hold true for transactions in the same block?
@pd93 Yes it does, if two trans are in the same block then by definition the first won't be committed. A block gets committed as a unit. Even if the first tran is in prior block it doesn't guarantee it... blocks may take some time (seconds) to get committed across the network. If you are setting the users during init, then you obviously know the users already and can perform your validation check in chaincode rather than reading from state.
@dave.enyeart Ok great :) thanks. That makes a lot of sense now. So I basically have to disable my validation checks when setting everything up initially
@dave.enyeart Hey, I've worked around my previous issue by adding a `validate` flag to my 'constructors'. The only place I'm still seeing this error is in my cron job. I've used the go cron library to update a certain state on the ledger every minute. However, the function (job) is still returning `User does not exist` as if it were being run during `Init()`. Do you foresee any issues with the cron library? or is this likely something to do with my code
@pd93 assuming the cron is outside of the chaincode (invokes the chaincode), i see no problem with that design. just be aware if a cron tran and a regular tran read the same data and overlap in time, that whoever gets ordered later will get invalidated
@pd93 assuming the cron is outside of the chaincode (invokes the chaincode), i see no problem with that design. just be aware if a cron tran and a regular tran read the same data and overlap in time, that whoever gets ordered later will get invalidated upon validate/commit phase
I was actually trying to use the go cron library and vendor it within my chaincode (so it's not invoked at all, but rather runs by itself) - is this possible? (it seems to run the cron job just fine... it's just that it seems to think that the user doesn't exist - when it does) see go cron here: https://godoc.org/gopkg.in/robfig/cron.v2
I was actually trying to use the go cron library and vendor it within my chaincode (so it's not invoked at all, but rather runs by itself) - is this possible? (it seems to run the cron job just fine... it's just that it seems to think that the user doesn't exist - when it does). See go cron here: https://godoc.org/gopkg.in/robfig/cron.v2
if it is run within the chaincode then it would be in the same tran context and you would see the issue
chaincode execution should not be long running
there are timeouts and locking that would nullify that design
Ahhh ok. So cron inside the chaincode is a bad idea. Got it
Thanks again
np
@dave.enyeart I've fixed this issue now, but just out of curiosity. Would it be feasible to have a second chaincode that just runs the cron code and calls back to the first chaincode to update the ledger state?
no - chaincode2chaincode still acts like a normal (short lived) transaction. it's just that the there will be two RWSets that get verified/committed
@pd93 no - chaincode2chaincode still acts like a normal (short lived) transaction. it's just that the there will be two RWSets that get verified/committed
@dave.enyeart Hmm ok. That's a shame. It'd be nice if there was a way to run scheduled/maintenance tasks from within the chaincode in the future. I like the idea of that sort of thing being self contained rather than an external app/cli having to invoke it.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=JnGmRmB9Za9SsqdNQ) @dave.enyeart Dave, Sorry going back to Global Ledger question. Just wanted to understand what is the rational behind not having global ledger similar to what Quorum has. Global Ledger would allow public and private transaction. Private transactions can be only visible to participants to the transaction and rest can see only hash. With current private channel and ledger, if two participants are hosting 2 nodes and one node goes down, why would it trust ledger residing on other node.
@binhn Can you refresh us on why there is no 'global channel'. Is it possible to include 'all members' on a channel, which would essentially be the same as a global channel?
I guess because you do not want to disclose a single evidence of transactions between certain parties. @dave.enyeart
right, that is the main motivation for channels. But a default public 'global channel' was considered and decided against. I assume this was because a regular channel with all members could serve the same purpose just as easily.
you might be referring to the identity channel?
that is the orderer 'global channel'? there was also a peer 'global channel' considered
for what purpose?
@dave.enyeart right, we decided not to create a default global channel and leave that to the application as some use-cases, members don't want to be known by all others
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ttSHGjdPYS5QbDoBc) @binhn Thanks. But Global channel ledger would not include private transactions from channel shared by 2 parties. Correct? Lets say this private transaction is done between 2 parties A & B on their private channel and the party A loses ledger (node crash), party B can say the transaction didn't exist. Having this transaction on the global ledger (with hash of the payload), all other parties has record of transaction and hence party B can't deny existance of the transaction.All other parties can see the transaction happened between party A and B but are not aware of what was the transaction about.
Has joined the channel.
@nhrishi With fabric design you can optionally create a 'global channel' and optionally post such hash to global channel. But it is not compulsory - in some scenarios you dont want everybody to know existence of the tran, in some scenarios you do.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=dkx6Hz7EXx4nffYWo) @nhrishi Assuming that in permissioned setup ordering service is the core of trust, you will still have a copy of the transaction in the ordering service.
and therefore party B would be able to deny
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=dwvTskrf4bDcEbMYj) @dave.enyeart Okay. That's great. Completely agree, it should be optional. And good to hear that private transaction can be posted to global channel with hash.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=bMRNGteXu4mooe8qi) @C0rWin Yes, that's another option as well.
Thanks @dave.enyeart @binhn @C0rWin for clarifications.
Has joined the channel.
hello, i'm trying to run the fabric sdk but i keep getting the following error:"failed to get a new tcert" can ony one help me please ?
I'd suggest post a fabric sdk question to #fabric-sdk :)
Has joined the channel.
Has joined the channel.
Hi,
```
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x10 pc=0xaadd06]
goroutine 1 [running]:
panic(0xc70aa0, 0xc420010060)
/opt/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchInstance).handleRequest(0xc4201319a0, 0xd53b79, 0x3, 0xc420226480, 0x17, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:1265 +0xad6
github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchInstance).VerifyConnection(0xc4201319a0, 0x0, 0x0, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:337 +0x15d
github.com/hyperledger/fabric/core/ledger/util/couchdb.CreateCouchInstance(0xc42000c06f, 0xf, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xc4201ce9f0, ...)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdbutil.go:44 +0x245
github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.NewVersionedDBProvider(0xc4201ce9f0, 0xc4202064d0, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:59 +0xc1
github.com/hyperledger/fabric/core/ledger/kvledger.NewProvider(0xc689e0, 0x0, 0xc42021f4d0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/kv_ledger_provider.go:90 +0x2bf
github.com/hyperledger/fabric/core/ledger/ledgermgmt.initialize()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:59 +0x14e
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize.func1()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:49 +0x14
sync.(*Once).Do(0x13b4dd0, 0xdd76a8)
/opt/go/src/sync/once.go:44 +0xdb
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize()
/opt/gopath/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:50 +0x39
github.com/hyperledger/fabric/peer/node.serve(0xc4202366c0, 0x0, 0x1, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:95 +0x74
github.com/hyperledger/fabric/peer/node.glob..func1(0x135d900, 0xc4202366c0, 0x0, 0x1, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/peer/node/start.go:83 +0x3f
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x135d900, 0xc4202366a0, 0x1, 0x1, 0x135d900, 0xc4202366a0)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:599 +0x234
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x135e180, 0xf, 0xc4200120f5, 0x4)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:689 +0x367
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x135e180, 0x2b, 0xc4200120f5)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:648 +0x2b
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/peer/main.go:110 +0x545
```
I just catched some SIGSEGV from peer (git rev `b2a2b3b11481438639bf27ed10b99e490dd23b8c`) with CouchDB connection.
Would like to know if you were already aware of this issue (and if yes if there is some correction on some other revision) or if I need to raise some bug on Jira ?
Has joined the channel.
Has joined the channel.
Trying to join a channel on the latest build but getting the following error on the orderer:
`Rejecting CONFIG_UPDATE because: Config update for channel creation does not set application group version to 1, was 0`
I know that there have been lots of changes in the config over the past few days, but I cannot see what I could be missing.
Worked my way through the above which was caused by a corrupt config file.
Now I have an issue creating a channel. I am following the e2e example formats as best I can (the links to the tar bundle in the docs are broken). Here the orderer channel has a key 'consortiums:' with an array of consortiums and organisations. The peer channel has a key of 'consortium:' which refers to an item created on the orderer. However, when I try to create a peer channel, I get this panic because it appears to be looking for an array:
```
2017-04-30 13:36:38.947 UTC [orderer/configupdate] Process -> DEBU 0d6 Processing channel creation request for channel testing
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x8ca1f5]
goroutine 57 [running]:
github.com/hyperledger/fabric/common/config.(*ConsortiumsGroup).Consortiums(0x0, 0x1110700)
@passkit this looks like an issue for #fabric-consensus , not this channel
@yacovm thanks - I have got it working now from working through the new e2e scripts - but still unable to deploy chaincode.
Has joined the channel.
Is any updated doc or tutorial to use CouchDB?
You can look at the marbles example
it shows you how to use couch
e2e also has something along the lines
@FenglianXu Take a look at https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst towards the bottom it explains how to use couchdb
Thank you, I will try this one tomorrow. Will look for some help from you during my test
Question:
1. If I want to persist file-system of the orderer across restart; do I need to volume mount only /var/hyperledger/production?
2. I am using e2e cli from fabric repository and even after setting ` ORDERER_LEDGER_TYPE=file ` in the docker composer file, I see print of ramledger. How can I set use fileledger?
I don't see anything in confgtx.yaml that can set the ledger-type however orderer.yaml is set to ram. Does it mean since I don't set in genesis block; it takes default form orderer.yaml and the docker-environment variable is not referred (just a guess?)
@rahulhegde I think the folks over on #fabric-consensus could help, could you post over there?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=3n4Y6tYXgZPnD6pin) @dave.enyeart yup got a response from kostas on thr said channel, working with him.
Has joined the channel.
Has joined the channel.
Has joined the channel.
What is recommended way to store structure data in the ledger like {A: {k1: 2, k2: 3, k3: {time: 1928, status: 123}}}? Should I serialize the whole data part into a json string and then bytes and deserailize them whenever I need to some k1, k2 of it?
Has joined the channel.
@FengChen_1982 For structured data we recommend JSON format. As an added benefit this will also enable query when using couchdb statedb. For a sample please see https://github.com/hyperledger/fabric/blob/master/examples/chaincode/go/marbles02/marbles_chaincode.go
OK, that's really great!
And what is a "composite key"?
I cannot find a precise defination
Has anyone seen this issue? ERROR: The Compose file './docker-compose.yml' is invalid because:
Unsupported config option for services.peer0: 'couchdb1'
Has joined the channel.
Error: proposal failed (err: rpc error: code = 2 desc = Block number should have been 3 but was 0)
Has anyone faced this issue ?
I am trying to setup Hyperledger Fabric network using this tutorial http://hyperledger-fabric.readthedocs.io/en/latest/getting_started.html?cm_mc_uid=10430795090714934358737&cm_mc_sid_50200000=1494087517
Has joined the channel.
@dave.enyeart here are examples of using peer and curl to query data from couchDB
peer chaincode query -C myc1 -n marbles -c '{"Args":["queryMarblesByOwner","tom"]}'
marbles02 has sample queries
With above example, I have an issue to run peer command
example command line statements in Using CouchDB section: https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst
Has joined the channel.
I have curiosity how blockchain stores information. Lets take anexample of supply chain of dimond, diamond extractor extract diamonds, and go through several wholesalers and retailers, finally on customer hand. if somebody wants to track this supply chain procedure, is blockchain capable to store extractor, wholesalers, retailers information, his price in blockchain hyperledegr? If yes, how such information gets stored in hyperledger fabric?
Has joined the channel.
Has joined the channel.
Has joined the channel.
@d8bhatta It is up to the chaincode how exactly to model the data. You could model each diamond as a key with associated parameters (e.g. json) such as diamond attributes, current ownerid, last transaction price, etc. Then chaincode transactions would alter the state of the key (diamond) to indicate current owner and transaction price. Finally, it would be possible to query current state and history of states using chaincode apis such as GetHistoryForKey().
Thank @dave.enyeart
@here Where can we define the blocksize, blockheight,..etc..Also, is there any example that shows sample policies (SignedPolicy,Implicit) and how and where to configure..
Has joined the channel.
Has joined the channel.
@dave.enyeart I am using curl to query a data using selector, but it does not give me the expected. Below is an example, is anything missing here?
curl -H 'Content-Type: application/json' -X GET http://127.0.0.1:5984/mychannel -d '{"selector" : {"doc.data.email.": "fenglian"}, "fields":["doc.chaincodeid", "doc.data.email", "_id", "_rev"}'
{"db_name":"mychannel","update_seq":"73-g1AAAAEzeJzLYWBg4MhgTmHgzcvPy09JdcjLz8gvLskBCjMlMiTJ____PyuRFYeCJAUgmWQPVsOOS40DSE08WA0nLjUJIDX1YDXcONTksQBJhgYgBVQ2n5C6BRB1-3G7C6LuAETd_axEHrzqHkDUgdyXBQCrtGM_","sizes":{"file":378336,"external":65007,"active":76963},"purge_seq":0,"other":{"data_size":65007},"doc_del_count":0,"doc_count":70,"disk_size":378336,"disk_format_version":6,"data_size":76963,"compact_running":false,"instance_start_time":"0"}
why do I get an encoded data with additional information?
@FenglianXu You are doing GET /db. You need to do POST /db/_find
http://docs.couchdb.org/en/2.0.0/api/database/find.html
@dave.enyeart Thanks and I have just noticed that as well
it turns out I need POST with /db/_find command
Has joined the channel.
@dave.enyeart What is the command for query in a peer docker? what's issue with below peer command for a general query?
peer chaincode query -C mychannel -n vehicle-lifecycle-network -c '{"Args":["query","{\"selector\":{\"data.owner\":\"resource:org.acme.vehicle.lifecycle.PrivateOwner#dan\"}}"]}'
Error: Error endorsing query: rpc error: code = 2 desc = Error: Could not determine the participant for identity 'peerOrg1Peer1'. The identity may be invalid or may have been revoked.
Usage:
peer chaincode query [flags]
@FenglianXu The command looks ok, I expect it is the crypto setup. I would recommend following the getting started example exactly to ensure your crypto setup and env are good: https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst
If the issue remains the folks over on #fabric-crypto could likely help
https://chat.hyperledger.org/channel/fabric-maintainers?msg=Q9WpaStPRvbe2Pueo
@kelvinzhong what exactly do you want to query? if you want to query current state data, then you can do that within chaincode. there is GetStateByRange() and you can add a key range or leave it open-ended if you want to retrieve all keys.
Has joined the channel.
@here Do we have a function in the shim to get the user attributes like similar to getUserAffiliates() in 0.6. The key reason for this is to restrict the user to perform only reads or writes based on the Role. Is see that we have them hfc sdk (getAffiliates, getSigningEntity, etc) and i think HFC fabric communicates with the Fabric CA to get the details. Is there any way to restrict the user in the chaincode to perforn only certian operations
Has joined the channel.
Hi very basic few questions :
1. I know there are multi channels in v1.0, question is how many chain can be created in a channel?
2. Is the client defined key/value store tied or associate to a chain or channel?
3. How many client key/value store can be defined in a chain/channel?
@bkvellanki I posted your question to #fabric-crypto
@l1nux You can think of channel and chain as the same thing. There is one chain per channel.
The channel gets initiated with the chain's genesis block
The number of keys/values is only bound by physical resources
The number of keys/values in a chain is only bound by physical resources
The number of keys/values in a chain is only bound by physical resources (disk space)
@DE let me clarify my question regarding the key/value store, I didn't mean the total size of the key/value data, I meant how many 'store' for a channel. So far I have dealt with just one store, but my colleague told me to define another store in an existing channel hence I wanted to double check.
Not sure what you mean by 'store'. For each channel there is one 'ledger' which consists of one 'chain' and one 'state database'. I suggest review the ledger overview material here:
Ledger Overview charts attached to https://jira.hyperledger.org/browse/FAB-758
Ledger Overview doc https://hyperledger-fabric.readthedocs.io/en/latest/ledger.html
@DE I meant the KeyValuStore interface to store application persistence data defined in the fabric sdk , again question is how many such store one can have for a channel?
@thanks dave
@l1nux ah, since you were posting on fabric-ledger I assumed you were talking about ledger key/value store where chaincode keys are stored. For questions about the sdk KeyValueStore to store user credentials, please post your question to #fabric-sdk
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=WedvyHXYJymDasvAB) @dave.enyeart well, to use getStateByRange indeed i could retrieve all keys, but it could not done in incremental, i need to scan whole state database to make sure all keys are checked if there is an update, but to query the block i could keep the block height and retrieve the new blocks then i could maintain all keys are checked.
i have create a New Feature in JIRA, hope it could be done XD
https://jira.hyperledger.org/browse/FAB-3884
@kelvinzhong Could you clarify a few things in the Jira item Description. Are you querying only current state or also historical state? If you query blocks I assume you are interested in the transaction write sets to see which keys were written? When you look at the block write sets how do you intend to detect if the prior written key is still valid or outdated? If you do incremental scans against state database, isnt there a chance you will miss some data that gets added between increments? Please be precise in defining exactly what you'd like the solution to provide. It sounds like you want to query current state outside of chaincode, but not sure.
@dave.enyeart In one scenario we currently have done, we would like to scan whole datas and cache it in like mongodb to provide more query features or analysis the data, so we need to know all states include the historical state, for example, if a value is store a contract between A and B, if the contract is changed, it must be outlined, and both A and B have the right to view the history contract. Also in real practice, we might not only store the data in fabric as no one could guarantee the reliability, so might store a copy in mysql or else, then keep compare the total record nums whether is the same.
“If you do incremental scans against state database, isnt there a chance you will miss some data that gets added between increments?” i'm not scan the state database but the ledger
@kelvinzhong Ok, In FAB-3884 description I understand the 1st and 3rd paragraph. But I can't make sense of the 2nd paragraph yet. Could you clarify that paragraph. I think I understand your intent now. You need to scan through all block transactions and look at all write sets, and perhaps build an external database from the results. But doing it one block at a time is too inefficient. So again, what exactly are you looking for? Perhaps a way to get a range of blocks to make it more efficient? For example get blocks 1-100, then 101-200, etc?
@kelvinzhong Ok, In FAB-3884 description I understand the 1st and 3rd paragraph. But I can't make sense of the 2nd paragraph yet. Could you clarify that paragraph. I think I understand your intent now. You need to scan through all block transactions and look at all write sets, and perhaps build an external database from the results. But doing it one block at a time is too inefficient. So again, what exactly are you looking for? Perhaps a way to get a range of blocks in batches to make it more efficient? For example get blocks 1-100, then 101-200, etc?
Has joined the channel.
yes, get blocks 1-100, the api likes chain.getBlocksByRange(long startHeight, long endHeight)
the 2nd paragraph says,if we have key A1and A3 in the state database, and range query by the chaincode to retrieve those two key and cache in mongodb. Now we put a new key A2 into the state database, we still need to range query and retrieve all three keys to know there is a new key A2 is updated into the state database, as we not always could get the event to know new keys is set into the state database, the event is not strong reliability. on the other hand, if we query to the ledger, first time we retrieve two blocks from the ledger to get A1 and A3, then we could save the current retrieved block height is 2, now the block height increase to 3, we only need to query the third block to get A2 and update the current retrieved block height to 3
the idea is simple, but seems not so easy to clarify it by words, hope you could understand my example @dave.enyeart
@kelvinzhong I've clarified the jira item accordingly. good idea.
lol, okay thx
Has joined the channel.
does anyone know if CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS is used anywhere within the fabric code?
I am unable to find where it is being used
just in the yaml files
@berserkr https://github.com/hyperledger/fabric/blob/master/core/ledger/util/couchdb/config.go#L38
can we call one chaincode from another..Lets say there is a billing department and accounting department, accounting department can have reference to billing department. Can we have two CC's separate where one cc can query another an get the values. In this case billing and accounting
@here can we call one chaincode from another..Lets say there is a billing department and accounting department, accounting department can have reference to billing department. Can we have two CC's separate where one cc can query another an get the values. In this case billing and accounting
@bkvellanki yeah there are CC2CC calls
via ChaincodeStubInterface.InvokeChaincode ? The comment on this method talks about certain caveats that would make this effectively a read-only operation. Is there a different way to do it?
@yacovm i hope if it is only on the same channel
Dont forget that these calls are on the same peer
https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/interfaces.go#L52-L58
Is it possible to invoke a transaction from chaincode on another channel on the same peer? One use case being two channels: 1) supply chain tracking, and 2) finance tracking, where the peer has access to both channels
Also, unrelated question: I'm looking to port my v0.6 chaincode that used the deprecated tables interface to v1.0, presumably using the new CouchDB rich-query system. What is a reasonable way to replace tables? Storing each table entry as a separate ledger state entry, say with some namespaced scheme? Or is storing the whole table as JSON in a single ledger state entry somehow not grossly inefficient (in terms of scaling up to millions+ of elements)?
Hmm.. looks like there's an example of this in mockstub_test.go -- using stub.CreateCompositeKey and stub.SplitCompositeKey. It's rather unfortunate that stub.GetStateByPartialCompositeKey can only specify the prefix of a key, instead of arbitrary, non-consecutive entries of a key (say you wanted to only match on the last key of a composite key)
@vdods InvokeChaincode() does indeed enable CC2CC calls, on the same channel or different channel. The code comment is saying that if the called chaincode is on a different channel, then any Puts on the called chaincode will not be persisted to the ledger (because it is not possible to ensure cross-channel data integrity since the channel's chains are updated independently).
You can indeed namespace your keys within a chaincode by using CreateCompositeKey
If you want to query based on the last part of the composite key, you will have to create a separate key that starts with the last part and query on that. This is because LevelDB only supports range queries (same restriction as 0.6 table api).
There is a good example of all of this: https://github.com/hyperledger/fabric/blob/master/examples/chaincode/go/marbles02/marbles_chaincode.go
The comments in that example describe the techniques
Alternatively you can use CouchDB and model the JSON to have the values that you want to query on. But read the marbles02 comments to understand potential gotchas related to phantom reads, if you are using the queries to drive subsequent updates.
Has joined the channel.
Hi, folks, I have a concern on Concurrency on commitment on ledger, looks like we have to ensure the readset not changed before committing, while sometimes we don't care whether data changed or not , for example, I just want to add 10$ to my account, I don't care someone with permission changes my balance during the process, as long as the system ensures the synchronization, do we have a benchmark on how many transactions on changing the same state? thanks
u might need to handle this situation in ur application level, like adding a queue for the operation to the same account
Hacked up a little utility to help a bit in identifying significant events in orderer and peer logfiles. It is a simplistic algorithm. Welcome pointer to alternatives out there and/or improvements. https://github.com/Rangak/loglights
Has joined the channel.
@kelvinzhong thanks, sounds nice
that's ok
@zhouhuangjing @kelvinzhong I could be totally missing something here, but isn't that the whole point of the orderer? To resolve those sorts of conflicts? I sure hope that responsibility doesn't fall to the application.
When I am instantiating marblechaincode in peer0 I am getting following error `Error: Error endorsing chaincode: rpc error: code = 2 desc = Error starting container: Failed to generate platform-specific docker build: Error returned from build: 2 "# github.com/hyperledger/fabric/examples/chaincode/go/marbles02
chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:370: assignment count mismatch: 2 = 3
chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:428: assignment count mismatch: 2 = 3
chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:538: assignment count mismatch: 2 = 3
chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:586: assignment count mismatch: 2 = 3
"
` I couldnt find a way to fix this error nor I edited chaincode . If anyone know how to fix this please let me know. I am stuck in for 2 days. Everytime I tried to instantiate I am getting the same eror.
When I am instantiating marblechaincode in peer0 I am getting following error ```Error: Error endorsing chaincode: rpc error: code = 2 desc = Error starting container: Failed to generate platform-specific docker build: Error returned from build: 2 "# github.com/hyperledger/fabric/examples/chaincode/go/marbles02
chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:370: assignment count mismatch: 2 = 3
chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:428: assignment count mismatch: 2 = 3
chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:538: assignment count mismatch: 2 = 3
chaincode/input/src/github.com/hyperledger/fabric/examples/chaincode/go/marbles02/marbles_chaincode.go:586: assignment count mismatch: 2 = 3
"
``` I couldnt find a way to fix this error nor I edited chaincode . If anyone know how to fix this please let me know. I am stuck in for 2 days. Everytime I tried to instantiate I am getting the same eror.
I am running couchdb instead of leveldb
@vdods u might need look into the design of fabric v1 architecture http://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html
@vdods and this doc :joy:http://hyperledger-fabric.readthedocs.io/en/latest/readwrite.html
especially the Example part, you will see some transactions failed, which are my concern
Has joined the channel.
Hi ,
I'm trying to make the permissioned ledger in the hyperledger fabric 0.6 version.
While deploying the chain code. I have passed the registered user with in the network based on the membersrvc.yml file , But trying to query the record based on the user i'm not getting.
If you have any idea or updates can u please let me know ?
Has joined the channel.
Hello everyone, after I have invoke a ChainCode on a peer node using just "peer chaincode invoke....", I should be able to get a proposal, but how I can extract the proposal from the response in command line and then send it to the orderer? Can it be done using just the cli "peer" command?
@FengChen_1982 cli sends to an endorser, gets the proposal response, and then submits to orderer for you. if you want to do this in separate steps, you will need to use an SDK
hello
@dave.enyeart do you have 10 mins for a quick skype chat - I'm here with a collegue and we're not clear on how the world state is interfacing with the rest of the blockchain
@MartinMateev hi, i you got the answer, might you could share here
@MartinMateev hi, if you got the answer, might you could share here
@MartinMateev sorry juggling multiple things and difficult to get on a skype. Please leave your question here and I'll answer when I can.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Anyone know how to get the hash of a block in the chaincode?
looks like you can do `block.Header.Hash` but I can't figure out how to access a block
When I am executing this query `peer chaincode query -C $CHANNEL_NAME -n marbles -c '{"Args":["getHistoryForMarble","marble1"]}'` I am not getting merkel hash. Is there a quey that we can also get merkel hash of block
Message Attachments
?
@MohammadObaid You dont need to go through chaincode to retrieve a block (which includes the hash). There is a query system chaincode and corresponding SDK APIs to retrieve a block, without having to write application chaincode. Maybe explain your end goal, so that we know the context of what you are trying to achieve.
@dave.enyeart My endgoal is simple . I want to retrieve everything about a block which should include its txid,merkelhash, ,timestamp,digitalsignature(verification) and all relevant data regarding that block. For example if any external user view my blockchain and he wish to retrieve any single block let say block 11 then result should he get are TXid, merkelhash , timestamp, digitalsignature(for verification) and data just like in bitcoin .
My second question is if someone want to verify our data stored in blockchain how can he do that?. As far as I understand things he must have public keys and digital signature of endorsing nodes and the peers that invoke queries.
Has joined the channel.
@MohammadObaid If you want to retrieve the block, you would not use application chaincode. There is a pre-deployed query system chaincode that allows you to retrieve blocks. It has functions like GetBlockByNumber() and GetBlockByTxID(). SDK has corresponding functions to retrieve and interrogate the returned blocks.
It depends what you mean by 'verify', but your application can parse the returned blocks and verify that the data and the hashes align. You would need to understand some of the impl details from the fabric however. There is intent to provide verify functions out of the box in the future.
@dave.enyeart Thanks :) This is the doc I got for system chaincode https://github.com/hyperledger/fabric/blob/master/proposals/r1/System-Chaincode-Specification.md. So basically there are two type of chaincode user chaincode which runs on peer container and system chaincode to query right? Any good article your refer me to implement system chaincode?
You don't have to implement system chaincode. These block query functions are already implement in query system chaincode (qscc). So you just have to invoke them, e.g.:
You don't have to implement system chaincode. These block query functions are already implemented in query system chaincode (qscc). So you just have to invoke them, e.g.:
You don't have to implement system chaincode. These block query functions are already implemented in query system chaincode (qscc), which is automatically pre-deployed on each peer. So you just have to invoke them, e.g.:
`peer chaincode query -C "" -n qscc -c '{"Args":["GetBlockByNumber","mychannel","1"]}'
`peer chaincode query -C "" -n qscc -c '{"Args":["GetBlockByNumber","mychannel","1"]}' `
Oh. I thought I have to implement it separately. Thanks a lot :)
Has joined the channel.
@dave.enyeart Is there any documentation available which list down all functions regarding systemchaincode?
Has joined the channel.
@MohammadObaid you can find the functions available in: https://github.com/hyperledger/fabric/blob/master/core/scc/qscc/query.go
@MohammadObaid you can find the query system chaincode functions available in: https://github.com/hyperledger/fabric/blob/master/core/scc/qscc/query.go
@here how to define the boundary between chaincode and enterprise database? because chaincode accesses the state database, and enterprise database stores the business data. need we transport all the data which are related with ledger to chaincode by invoking operations?
@bh4rtp Some solutions add enterprise data to the chaincode data, while other solutions prefer to hash enterprise data and simply put the hash in the chaincode data. It depends whether there is an alternate way to share the data and if you just need evidence of the data on blockchain rather than the data (for example for privacy reasons or to keep blockchain data to a minimum).
Has joined the channel.
Could anyone show me how to get the has value of a transaction from the chaincode?
Could anyone show me how to get the hash value of a transaction from the chaincode?
Is this a known issue? panic: TypeError: undefined not constructable
goroutine 32 [running]:
panic(0xa2c7c0, 0xc420171220)
/opt/go/src/runtime/panic.go:500 +0x1a1
I am running this on Fabric alpha V1
@berserkr Can you help to look at my issue please?
TypeError:undefined not constructable does not give me enough information
is anyway I can debug go programming inside a docker image?
@FenglianXu do you have a full stack trace?
@berserkr here is the full stack trace:
2017-05-23 19:55:59.018 UTC [shim] afterResponse -> DEBU 02b [1b406db0]Received RESPONSE, communicated (state:ready)
2017-05-23 19:55:59.018 UTC [shim] handlePutState -> DEBU 02c [1b406db0]Received RESPONSE. Successfully updated state
panic: TypeError: undefined not constructable
goroutine 10 [running]:
panic(0xa2c960, 0xc420143540)
/opt/go/src/runtime/panic.go:500 +0x1a1
main.NewQueryService(0xc420138120, 0xc42018c630, 0x12469e0, 0xc420148d00, 0xc4201b7520)
/chaincode/input/src/composer/queryservice.go:38 +0x57e
main.NewContext(0xc420138120, 0xc420138130, 0x12469e0, 0xc420148d00, 0xc42018c630)
/chaincode/input/src/composer/context.go:46 +0x383
main.(*Composer).Init(0xc420146f80, 0x12469e0, 0xc420148d00, 0xc420135e90, 0x4, 0xc420147590, 0x1, 0x1, 0x0, 0x0, ...)
/chaincode/input/src/composer/composer.go:122 +0x2d1
main.(*Chaincode).Init(0xc420162160, 0x12469e0, 0xc420148d00, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
/chaincode/input/src/composer/chaincode.go:96 +0x590
github.com/hyperledger/fabric/core/chaincode/shim.(*Handler).handleInit.func1(0xc42000e690, 0xc42014b270)
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/handler.go:236 +0x827
created by github.com/hyperledger/fabric/core/chaincode/shim.(*Handler).handleInit
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/shim/handler.go:257 +0x49
@berserkr is this stack enough?
@FenglianXu this looks like a composer issue? perhaps asking it in #composer would help you resolve it
@FenglianXu what I do is start the service in verbose mode (do not pass in the -d flag to composer)
docker-compose I mean
if you are using the composer-cli then it is a different story, you can usually see the output in the terminal when you start it
Has joined the channel.
When writing blocks, does the peer wait for the I/O to complete before generating the transaction committed event?
Hi, i dont understant all the process to set up an environment. In my case Im trying to build an asset (Car) and a network with 3 participants, this 3 participants are able to sell the car and the ownership of this car will change. So what is the process to do that? Set up a network with 3 peers? Develop the asset ? Develop the transaction as chaincode? Or what parts i should use ? Thank you for answers
@dave.enyeart thanks. that sounds reasonable.
@dave.enyeart for cross-enterprise applications, it is difficult to share the data. so add enterprise data to the chaincode data is a feasible solution. but the chaincode data is stored in the ledger database, i.e. couchdb. can i replace couchdb by commercial database such as oracle or mysql?
Has joined the channel.
@bh4rtp v1.0 is based on a key/value architecture, where value can be binary or semi-structured data such as JSON. There is a statedb interface to allow implementation of other DBs that support key/value or JSON data structure. SQL-based would require much more work, an alternate programming model and interfaces would have to be developed, likely all the way up to chaincode interface.
@dave.enyeart Nickgaski in fabric-question channel asked me to talk with you regarding my use case.
My use case is that only part of the asset needs to be secret. Example . Party A n Party B do some trade . Trade has two components i.e some public and some private. Now when the trade is done , private data remains private between Party A n B but the public data should be visible to Party C.
So in all some part of the trade i.e asset is private and some public.
He suggested to use side db. Is there any other kind of implementation as side is also provided by quorum and with fabric we need to build everything out from scratch
Your options on 1.0 are to use multiple transactions on multiple channels or encrypt some of the data and share the keys out of band. For next releases you could help us validate side db design: see FAB-1151 and embedded design links
@here is there a document demonstrates an example block and shows completely decoded details?
@here is there a document demonstrates an example block and shows its completely decoded details?
@here is there a document demonstrates an example 1.0 block and shows its completely decoded details?
@here is there a document demonstrates an example 1.0 block data structure in completely decoded details?
Hi, I was playing with network delays and package loss on my dockers and managed to get my peers have different states.
Then i tried to pass a transaction asking for endorsement from the peers that still had the old state ( they should see the transaction as valid, although according to the current state is wasn't ). The transaction was endorsed.
And then i got this
`[statevalidator] ValidateAndPrepareBatch -> WARN 058 Block [15] Transaction index [0] TxId [18fcb6c9d36c263ed9d1583a60819fd68a45eddf74f23f668723c7c16e52d0d0] marked as invalid by state validator. Reason code [11]`
My question is who is the statevalidator and what did he check against to know that the transaction was invalid?
@SotirisAlfonsos https://github.com/hyperledger/fabric/blob/2a3ad9d406ab66d2934e9214f7f87e3007b52bd4/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go#L141
It has logic to validate various aspects, in your particular case it failed MVCC check
`TxValidationCode_MVCC_READ_CONFLICT TxValidationCode = 11`
https://github.com/hyperledger/fabric/blob/master/protos/peer/transaction.pb.go#L18
list of possible validation codes
@C0rWin so the validation process takes place in every peer and it is the last step of the transaction flow when they receive the block from the orderer. And the validator checks if the state ( or readset and writeset ) changed in the meantime. Did i understand correctly?
yes
thank you very much
https://chat.hyperledger.org/channel/fabric?msg=XxdXSBnBvGdsDNmxe
@rfu2k
Has joined the channel.
Thanks @AdnanC I hadn't realised there was a fabric-ledger channel :) I'm keen to learn if there is a way to view the data on the ledger using leveldb, I have found some overview instructions with CouchDB but am trying not to touch anything in my setup (cos everytime I touch it I jinx it, and I have to give a demo in the morning). I have been using Fabric Composer but I'm trying to understand how things are stored at the state db level.
Thanks @AdnanC I hadn't realised there was a fabric-ledger channel :) I'm keen to learn if there is a way to view the data on the ledger using leveldb, I have found some overview instructions with CouchDB but am trying not to touch anything in my setup (cos everytime I touch it I jinx it, and I have to give a demo in the morning).
@rfu2k goleveldb can only be opened by a single process (the peer process), therefore the only way you can 'view' the data in goleveldb is to query the keys from chaincode. for example you could do an open-ended range query in order to retrieve all keys/values.
couchdb is indeed a good option, if you want to 'view' the data in statedb during iterative development
but in production environment it is recommended to not make the couchdb port available outside the docker environment, in order to eliminate risk of data tampering
thanks @dave.enyeart I did see that about port mapping, when I get time on my side I'll look into setting up couchdb perhaps it's not as involved as i fear :)
@dave.enyeart @SahilKapoor btw I think the sidedb will be a real win. As you may know, there is an issue open at https://github.com/hyperledger/composer/issues/1043 around this situation, currently labelled as architectural enhancement. Multiple channels pattern can protect the underlying data but does lose the beauty/provenance of a single chain which is a shame. One of the evaluation benefits that Corda seems to have in comparison to Fabric is that all transactions have the point to point privacy but also are held within that single vault, whereas with the multi channel privacy approach there is a reconcilliation required on client side to pull all parts of the history together. From what I understand with the goals of sidedb it should be possible to have it all on the one chain but keep the confidential data out of the ledger and state, that'll rock.
@dave.enyeart @SahilKapoor btw I think the sidedb will be a real win. As you may know, there is an issue open at https://github.com/hyperledger/composer/issues/1043 around this situation, currently labelled as architectural enhancement. Multiple channels pattern can protect the underlying data but does lose the beauty/provenance of a single chain which is a shame. One of the evaluation benefits that Corda seems to have in comparison to Fabric is that all transactions have the point to point privacy but also are held within that single vault, whereas with the multi channel privacy approach there is a reconcilliation required on client side to link the pieces and pull all parts of the history together. From what I understand with the goals of sidedb it should be possible to have it all on the one chain but keep the confidential data out of the ledger and state, that'll rock.
Has joined the channel.
@here which one is better to have in terms of ledger and privacy? a peer being part of multiple channels (and each channel has only one consortium) or a peer part of multiple consortium (in a single channel).
Has joined the channel.
Has joined the channel.
My couchdb container seems to exit immediately after launching my network and I can't work out why. These are the container logs. Any help is appreciated
```
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,couch,{{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,auth_cache,{{badmatch,{error,eacces}},[{couch_auth_cache,ensure_users_db_exists,2,[{file,\"src/couch_auth_cache.erl\"},{line,456}]},{couch_auth_cache,open_auth_db,0,[{file,\"src/couch_auth_cache.erl\"},{line,428}]},{couch_auth_cache,reinit_cache,1,[{file,\"src/couch_auth_cache.erl\"},{line,290}]},{couch_auth_cache,init,1,[{file,\"src/couch_auth_cache.erl\"},{line,166}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,240}]}]}}}}},{couch_app,start,[normal,[]]}}}"}
```
My couchdb container seems to exit immediately after launching my network and I can't work out why. These are the container logs. Any help is appreciated
```
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,couch,{{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,auth_cache,{{badmatch,{error,eacces}},[{couch_auth_cache,ensure_users_db_exists,2,[{file,\"src/couch_auth_cache.erl\"},{line,456}]},{couch_auth_cache,open_auth_db,0,[{file,\"src/couch_auth_cache.erl\"},{line,428}]},{couch_auth_cache,reinit_cache,1,[{file,\"src/couch_auth_cache.erl\"},{line,290}]},{couch_auth_cache,init,1,[{file,\"src/couch_auth_cache.erl\"},{line,166}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,240}]}]}}}}},{couch_app,start,[normal,[]]}}}"}
```
Also, while I'm here, is there any way to enabled more verbose logging for couchdb?
My couchdb container seems to exit immediately after launching my network and I can't work out why. These are the container logs. Any help is appreciated
```
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,couch,{{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,auth_cache,{{badmatch,{error,eacces}},[{couch_auth_cache,ensure_users_db_exists,2,[{file,\"src/couch_auth_cache.erl\"},{line,456}]},{couch_auth_cache,open_auth_db,0,[{file,\"src/couch_auth_cache.erl\"},{line,428}]},{couch_auth_cache,reinit_cache,1,[{file,\"src/couch_auth_cache.erl\"},{line,290}]},{couch_auth_cache,init,1,[{file,\"src/couch_auth_cache.erl\"},{line,166}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,240}]}]}}}}},{couch_app,start,[normal,[]]}}}"}
```
Also, while I'm here, is there any way to enable more verbose logging for couchdb?
Has joined the channel.
Hello All,
I have a question regarding ledger design best practice, what is recommanded one ledger per channel or one channel can have multiple ledger.
@pd93 what happens if you bring up the couchdb on its own (without a fabric network)? It still exits immediately?
@pd93 what happens if you bring up the couchdb on its own (without a fabric network)?
@akash42145 There is one ledger per channel. This is not a best practice, but a fundamental truth.
@AdnanC Hey, it loads up fine when I run `docker run hyperledger/fabric-couchdb`
and it does not exit immediately? ok
Yeah, to clarify a couple of things.. This is coming from a custom script I have that worked with v1 (pre-alpha)
All the other containers come up fine, with the exception of the peers (that fail because it can't dial couchdb)
I'm now on alpha2 and trying to get everything running again
ok
@AdnanC I get `couchdb0 exited with code 140` but nothing online seems to indicate what the status code actually means
and who gives that message?
Docker outputs that when it exits this container
Docker outputs that when it exits the container
ok
Still can't work out why fabric is causing it to exit.. :/ This makes no sense to me
It might be a docker issue, from the top of my head , can't rememember anything in fabric that can cause the Couch to exit
Hmm I've tried a docker restart and my system too. Thanks anyway. I'll post back if I ever resolve this
just checking, so even if you start the couch , and wait, and then start the network, the couch exits at that moment?
Haven't tried actually. Just been using the docker-compose
that may actually help to isolate the problem area
Shall give it a go now
Ermm.. okay.. `docker-compose up couchdb0` also exits immediately
So it's not fabric that's causing it to exit
My logs consist of the usual couchdb 'admin party' warning message, the following two messages and the error I previously reported above
```
couchdb0 | [os_mon] memory supervisor port (memsup): Erlang has closed
couchdb0 | [os_mon] cpu supervisor port (cpu_sup): Erlang has closed
```
from what I read, these are caused by some virtualized environments, and people have reported that couch continues after spewing this message
from what I read, these are caused by somevirtualized environments, and people have reported that couch continues after spewing this message
Hmm okay. Unfortunately mine is still exiting xD Is there a way to increase logging verbosity?
@pd93 are you building the couchdb image? if yes, you can add the following lines to local.ini and build:
```
[log]
level = debug
```
are you building the couchdb image? if yes, you can add the following lines to local.ini and build:
```
[log]
level = debug
```
Sorry, been away for a bit. At the moment I'm just using the published docker images. You sure there's no environment variable for it? Seems like there should be
@AdnanC Sorry, been away for a bit. At the moment I'm just using the published docker images. Are you sure there's no environment variable for it? Seems like there should be
If not I'll build it over the weekend sometime. 5pm on a bank holiday weekend here in the UK. I'm going home :P
there is a way to change it via a CURL put, but that still needs a running couch
Ahh ok, no problem. I'll give this a go soon and let you know if I have a breakthrough :)
Thanks, have a good weekend
you too!
Has joined the channel.
To get blockchain info I am running this query `peer chaincode Invoke -C mychannel -c '{"Args":["GetChainInfo","marbles"]}'
` as function `GetChaininfo` is defined here https://github.com/hyperledger/fabric/blob/master/core/scc/qscc/query.go but I am getting error `unknown function` . Anyone can help me how to get chaininfo or execute functions defined in the link?
To get blockchain info I am running this query `peer chaincode Invoke -C mychannel -c '{"Args":["GetChainInfo","marbles"]}'` as function `GetChaininfo` is defined here https://github.com/hyperledger/fabric/blob/master/core/scc/qscc/query.go but I am getting error `unknown function` . Anyone can help me how to get chaininfo or execute functions defined in the link?
@MohammadObaid here's an example: `peer chaincode query -C "" -n qscc -c '{"Args":["GetChainInfo","myc1"]}' `
qscc is the system chaincode where GetChainInfo is defined
qscc is the system chaincode where GetChainInfo function is defined
system chaincodes are channel-less ("")
then you pass the channel name into the function (not the chaincode name)
@muralisr @binhn ^^^^ I dont recall if qscc is documented, and how to invoke/query. I'll create a doc bug unless you can point us to existing doc...
although, doing these queries is somewhat pointless from current cli, since the response back is a byte array that would need to be parsed. Is there any future intent to have cli parse these, or we suggest people use sdk to call qscc functions?
although, doing these queries is somewhat pointless from current cli, since the response back is a byte array that would need to be parsed. Is there any future intent to have cli parse these, or we suggest people use sdk to call qscc functions? (I believe there are corresponding sdk functions to make this simple from sdk client)
although, doing these queries is somewhat pointless from current cli, since the response back is a byte array that would need to be parsed, and therefore maybe it is not documented on purpose. Is there any future intent to have cli parse these, or we suggest people use sdk to call qscc functions? (I believe there are corresponding sdk functions to make this simple from sdk client)
what do you suggest in terms of doc?
@dave.enyeart `system chaincodes are channel-less ("")` perhaps better written as `system chaincodes can be invoked without a channel`
about documenting calls to system chaincodes, you are right... as the CLI interfaces don't do special processing for chaincodes like qscc, hard to doc for them
@jiangyaoguo has taken an interesting approach by introducting a "list" command to list chaincode and under the covers querying qscc (see CR https://gerrit.hyperledger.org/r/#/c/9347/).. perhaps we should generalize it that CR to query qscc (`peer chaincode qscc` instead of `peer chaincode list`) to process all qscc commands one shot. That would be easy to doc too
what do you think @dave.enyeart @jiangyaoguo ?
@dave.enyeart thanks :)
@dave.enyeart Can we also call these function define here `https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/chaincode.go`
@dave.enyeart Can we also call these function define here `https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/chaincode.go` like GetState function etc or just the function defined on query.go?
Has joined the channel.
@MohammadObaid your user chaincode calls the functions defined in /shim/chaincode.go. and then your client calls your user chaincode.
qscc (query.go) is just a special pre-deployed 'system' chaincode that the client can call
@muralisr qscc are ledger query functions, which is different from lscc(`peer chaincode list`calls). Maybe we can have a `peer chain get
Right was wondering if we should have "wrapper" calls for some of these system cc calls like you did with the list @jiangyaoguo ...that way we can present the response properly
Has joined the channel.
Has joined the channel.
Does rich query work for a system data in alpha 1?
i'm not sure what you mean by 'system data', but yes rich query against couchdb works against chaincode data in both alpha1 and alpha2
Has joined the channel.
Has joined the channel.
How can we start multiple node using only binary (without using docker) ? would like to know what i should set before running "peer node start" --peer-defaultchain=false again so there is no conflict
@anik This is a better question for #fabric-peer-endorser-committer . That being said, I've gone ahead and created a Jira item that may help you: https://jira.hyperledger.org/browse/FAB-4259
please ask further questions in #fabric-peer-endorser-committer or jira
Has joined the channel.
@dave.enyeart thanks
@here i am coding my chaincode. to generate a unique key using sha-256 and ripemd-160, which one is better in collision resistance?
in principle, sha-256, since it's generating into a larger state space. that's assuming that they're equally good hash functions
but presumably they don't use the same algorithm
@vdods thanks!
Has joined the channel.
Has joined the channel.
This is regards to `stub.GetStateByPartialCompositeKey`
`objIndexKey, err := stub.CreateCompositeKey(indexName, []string{obj.UniqueId, obj.SmartContractId, obj.PartnerId})`
The array in the second arg is a list of columns that are part of the index
Now If I have to search by the SmartContractId alone - how would I do it.
`objIterator, err2 = stub.GetStateByPartialCompositeKey(indexName, []string{smartCodeId})`
or `objIterator, err2 = stub.GetStateByPartialCompositeKey(indexName, []string{"",smartCodeId,""})`
Both of them do not return any result. As the first key of the index is not there. Else do I have to make it as first key index to search?
So in short - how can we query a composite key with less number of args in the index.
The partial composite key query has to be a subset of the columns where the leftmost columns are required. If you want to query on SmartContractId alone, you would need a second 'index' with SmartContractId leftmost. This is the approach that the marbles02 chaincode example takes.
The limitation is due to the underlying LevelDB database only supporting range queries
If you want 'rich' query capability where you can query on any field, then you would need to model the chaincode data as JSON and utilize CouchDB queries.
Yes - got that. Clear. Thanks for this clarification man.
Does any see this error before in alpha1: 2017-06-05 13:20:43.723 UTC [chaincode] ExecuteChaincode -> ERRO 05c Error executing chaincode: Failed to execute transaction (Timeout expired while executing transaction)
panic: runtime error: invalid memory address or nil pointer dereference
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x30 pc=0x67b15e]
goroutine 22257 [running]:
panic(0xc2c3a0, 0xc420016050)
/opt/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/core/chaincode.(*Handler).handleQueryStateClose.func1.1(0xc42266e680, 0xc42475d270, 0xc426b34f18)
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:893 +0x4e
panic(0xc2c3a0, 0xc420016050)
/opt/go/src/runtime/panic.go:458 +0x243
github.com/hyperledger/fabric/core/chaincode.(*Handler).getQueryIterator(0xc42266e680, 0x0, 0xc4227841b0, 0x24, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:229 +0x79
github.com/hyperledger/fabric/core/chaincode.(*Handler).handleQueryStateClose.func1(0xc42266e680, 0xc42475d270)
Timeout is a faked error message it was because peer1 was closed after a while
@FenglianXu do you know what level of code you are on (git log --oneline) ?
Hi All,
I have a question. In real scenario we expect the smart contract update. So, when we update the smart contract ,
1. Do we have any option to continue with the same previous ledger? Instead of creating a new genesis block, can we continue appending new blocks from where we left with the previous chain code?
2. Or is there any way to copy all the data from previous ledger to this chain code's ledger?
3. Or do we need to store the chain code id's of the previous smart contract to access the previous data stored?
4. Or Do we need to have two smart contract, one for the storage and retrieval of data to and from the ledger ( which is more stable )
And other smart contract which will have the business logic, which can get changed.
Which is the best option. Any help / suggestion really appreciated. Thank you
In v1.0 when you update chaincode, you keep the chaincode id the same and increment the version. You can add data to ledger with chaincode v1 and then query that data with chaincode v2. When you invoke or query chaincode, you provide the chaincode id but not the version. The latest version of chaincode will always be invoked. The chaincode author needs to ensure that the new chaincode is backward compatible in terms of data structure. There is no new genesis block when you upgrade chaincode, new data will be written to the same chain as before upgrade.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=D77dtbiwCcwfpR9Te) @dave.enyeart - Based on the your suggestion I have started to look into the CouchDB option for rich query support and marbles02 is helping there a lot.
A question though - I use peer node in dev mode and to connect to couch db we used "COUCHDB" params. The same are applicable in dev mode too right?
So dev machine has couch db database setup and is listening on port 8081 - I set up two params `CORE_LEDGER_STATE_STATEDATABASE=CouchDB` and `CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=couchdb0:8081`
Is this sufficient? or I have to do some more config changes?
I could find the following settings in the code base `blob/master/core/ledger/util/couchdb/config.go`
```couchDBAddress := viper.GetString("ledger.state.couchDBConfig.couchDBAddress")
username := viper.GetString("ledger.state.couchDBConfig.username")
password := viper.GetString("ledger.state.couchDBConfig.password")
maxRetries := viper.GetInt("ledger.state.couchDBConfig.maxRetries")
maxRetriesOnStartup := viper.GetInt("ledger.state.couchDBConfig.maxRetriesOnStartup")
requestTimeout := viper.GetDuration("ledger.state.couchDBConfig.requestTimeout")```
So I setup the USERNAME and PASSWORD too. then I get the following error when peer is starting
```2017-06-07 00:51:21.636 GST [ledgermgmt] initialize -> INFO 003 Initializing ledger mgmt
2017-06-07 00:51:21.636 GST [kvledger] NewProvider -> INFO 004 Initializing ledger provider
2017-06-07 00:51:21.642 GST [couchdb] CreateSystemDatabasesIfNotExist -> ERRO 005 Error during CouchDB CreateDatabaseIfNotExist() for system dbName: _global_changes error: Couch DB Error:illegal_database_name, Status Code:400, Reason:Name: '_global_changes'. Only lowercase characters (a-z), digits (0-9), and any of the characters _, $, (, ), +, -, and / are allowed. Must begin with a letter.
2017-06-07 00:51:21.642 GST [couchdb] VerifyCouchConfig -> ERRO 006 Unable to connect to CouchDB, error: Couch DB Error:illegal_database_name, Status Code:400, Reason:Name: '_global_changes'. Only lowercase characters (a-z), digits (0-9), and any of the characters _, $, (, ), +, -, and / are allowed. Must begin with a letter. Check the admin username and password.
panic: Error in instantiating ledger provider: Unable to connect to CouchDB, error: Couch DB Error:illegal_database_name, Status Code:400, Reason:Name: '_global_changes'. Only lowercase characters (a-z), digits (0-9), and any of the characters _, $, (, ), +, -, and / are allowed. Must begin with a letter. Check the admin username and password.```
I've enabled the admin username and password in the local.ini file too and the same is getting passed as ENV variables
```export CORE_LEDGER_STATE_STATEDATABASE=CouchDB
export CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS=127.0.0.1:5984
export CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME=admin
export CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD=UUUUUUUU```
@here does state key-value have limited size (couchdb is used)?
@here does state key & value have limited size (couchdb is used)?
@Amjadnz The easiest way to configure the couch admin username/password is to expose port 5984 and then use Fauxton UI http://localhost:5984/_utils/ to set the username/password in the Admin Party section.
This ends up as a local.ini entry. Production systems would likely update local.ini directly, but you can try it via the UI the first time to understand what gets configured
there is guidance in the starter local.ini file: https://github.com/hyperledger/fabric/blob/master/images/couchdb/local.ini
and full couchdb reference: http://docs.couchdb.org/en/2.0.0/config-ref.html
http://docs.couchdb.org/en/2.0.0/config/auth.html#admins
Then you pass the username and password to the peer as you demonstrated above
@bh4rtp You can also look at local.ini and the couchdb reference. Look for the max_document_size.
[moving this to #fabric-ledger ](https://chat.hyperledger.org/channel/fabric-maintainers?msg=5uYXJBKmgg75TiqSm) @kelvinzhong
@kelvinzhong There are two aspects of this - chaincode container shim to peer interaction, and peer to database interaction.
*Chaincode container shim to peer interaction*: The results are actually implicitly batched. Say there are 100,000 results to the query. Only 100 results will get returned to the chaincode container shim. The chaincode will next() through the results. If the chaincode tries to next() to the 101st item, then the next batch of 100 will get returned, and so on. The chaincode can decide if it wants to stop at some application limit, or next() through the entire result set.
*Peer to database interaction*: This depends on the database.
If using the default in-process *LevelDB* database, then LevelDB only returns an iterator (pointer) to the keys, not the full result set. Peer will next() through the key results 100 at a time and LevelDB will cursor through them. Each set of 100 are returned to chaincode container shim, depending on how far the chaincode traverses the result set.
If using the default in-process *LevelDB* database, then LevelDB only returns an iterator (pointer) to the keys, not the full result set. Peer will next() through the key results 100 at a time (as needed by chaincode shim) and LevelDB will cursor through them. Each set of 100 are returned to chaincode container shim, depending on how far the chaincode traverses the result set.
If using *CouchDB*, then the database is in a separate process. Peer will ask CouchDB for the entire result set, and then feed results to chaincode 100 at a time. In order to mitigate very large requests (either accidental or malicous), there is a configurable cap on the number of results that CouchDB will return. It is configured in peer via ledger.state.queryLimit property (core.yaml or passed to peer as env variable), with default of 10000. This is sufficient for initial release, but there is intent to improve upon it in subsequent releases, so that very large result sets are never passed between peer and CouchDB.
If using *CouchDB*, then the database is in a separate process. Peer will ask CouchDB for the entire result set, and then feed results to chaincode 100 at a time (as requested by chaincode shim). In order to mitigate very large requests (either accidental or malicous), there is a configurable cap on the number of results that CouchDB will return. It is configured in peer via ledger.state.queryLimit property (core.yaml or passed to peer as env variable), with default of 10000. This is sufficient for initial release, but there is intent to improve upon it in subsequent releases, so that very large result sets are never passed between peer and CouchDB.
If using *CouchDB*, then the database is in a separate process. Peer will ask CouchDB for the entire result set, and then feed results to chaincode 100 at a time (as requested by chaincode shim). In order to mitigate very large requests (either accidental or malicous), there is a configurable cap on the number of results that CouchDB will return. It is configured in peer via ledger.state.queryLimit property (core.yaml or passed to peer as env variable), with default of 10000. This is sufficient for initial release, but there is intent to improve upon it in subsequent releases, so that very large result sets are never passed between peer and CouchDB (FAB-2809).
Since queryLimit applies only to CouchDB now (it used to apply to both), it should probably be moved to ledger.state.couchDBConfig.queryLimit now.
@chris.elder @manish-sethi What do you think? I could open a defect as such and we could fix after the next release milestone
@kelvinzhong also, I believe both leveldb and couchdb return results in key lexicographical order. Let us know if you see otherwise.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=BmvpLR3BuhKuWEWvS) @dave.enyeart - I would try that. Thanks.
I would agree with moving queryLimit back under the couchDBConfig section
@here how to query object using `GetQueryResult`with OR logic? for example, `name = x OR desc = x`
This the syntax for constructing a OR query:
{selector":{"$or":[{"name":{"$eq":"x"}},{"desc": {"$eq": "x"}}]}}
@chris.elder great, thanks. :v:
{"selector":{"$or":[{"name":{"$eq":"x"}},{"desc": {"$eq": "x"}}]}}, missed a quote in the earlier
ok. thanks again.
@chris.elder how to cope with nested struct in query string? for example `someEntityObj.Naming.name = x OR someEntityObj.Naming.desc = x`
for name: {"naming":{"name":{"$eq":"x"}}}, is this correct?
{"someEntityObj.Naming.name":{"$eq":"x"}}
@chris.elder that is smart!
@chris.elder and how about (doc = x && (name = y || desc = y))?
`{"selector":{"$and":[{"doc":{"$eq":"y"},{"$or":[{"name":{"$eq":"x"}},{"desc": {"$eq": "x"}}]}]}}`
correct?
@chris.elder and how about (doc = y && (name = x || desc = x))?
`{"selector":{"$and":[{"doc":{"$eq":"y"},{"$or":[{"name":{"$eq":"x"}},{"desc": {"$eq": "x"}}]}]}}`
correct?
yes, that is correct
Hello, we need a trainer for hyperledger fabric and node js sdk. Is here anybody with good experience with such technology?
Has left the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
can i call another chaincode in the domain of current chaincode?
@bh4rtp you mean call another chaincode in the same channel as the calling chaincode ? yes.
@muralisr yes, in the same channel. when the chaincode is instantiated, a docker chaincode image will be created. i wonder if a channel has two chaincodes, i.e. `SimpleChaincode1` and `SimpleChaincode2`, need to install and instantiate these chaincodes for each? if yes, there will be two docker chaincode images created. and then, how to call `SimpleChinacode2` from `SimpleChaincode1`?
@bh4rtp install and and instantiate the called chaincode and then call it
ok. thanks.
Has joined the channel.
how can we start couchdb outside docker container ?
Message Attachments
i m running in HV1.0 alpha 2
@anik You can go to couchdb website, download couchdb 2.0, and run it locally. The fabric-couchdb image has no functional changes, just some configured optimizations which are not needed for trial environments.
@dave.enyeart To clarify your comment above.. Does this mean you recommend not using a local couchdb in production?
We recommend running the fabric docker containers in production, just mentioning that it is possible to download and run couchdb local, if you prefer.
@dave.enyeart actually i m getting hash mismatch error while running make couchdb command.Is it dependent on any binary before it pull the docker image ?
@dave.enyeart somehow running the make docker clean fixed the problem for me
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hi guys,
I'm trying to incorporate couchdb to the Todo-list hyperledger fabric project, in order to make rich queries.
Hi guys,
I'm trying to incorporate couchdb to the Todo-list hyperledger fabric project, in order to make rich queries.
Hi guys,
I'm trying to incorporate couchdb to the Todo-list hyperledger fabric project, in order to make rich queries.
What are the steps to switch from levelDB to couchDB ?
I just have to modify the docker-compose file, adding couchdb peers, and add corresponding dependances to fabric-peer ?
Has joined the channel.
Hi guys, Here in my company we are starting a new project related with blockchain. I am this taks: install hyperledger-fabric in one server, but I have another server for install another node. Where I can get it information?
@joedayz If you need instructions on how to install, I suggest you start here: https://github.com/hyperledger/fabric/blob/master/examples/e2e_cli/end-to-end.rst
hi, install chaincode failed with below error.
`Error: Error getting chaincode code chaincode: Error getting chaincode package bytes: Error obtaining imports: go list: failed with error: "exec: not started"`
how to fix this problem?
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hi @bh4rtp this happens when you try to install chaincode from the peer container (because golang is not installed in there). Use the `fabric-tools` as base to install chaincode (the cli container in the example)
Other question: when I install and instantiate chaincode from one peer and then try to install the same code and query from another peer, I get the following error: ```
Error: Error endorsing query: rpc error: code = Unknown desc = Error executing chaincode: Could not get deployment transaction from LSCC for mycc:1.0 - Get ChaincodeDeploymentSpec for mycc/mychannel from LSCC error: chaincode fingerprint mismatch data mismatch -
@arner yes, it is also because PATH has not include $GOROOT/bin.
i usually use `docker logs PEER_CONTAINER_ID ` to find the reason.
@terrypst you can learn from e2e_cli example, which supports couchdb specified by command arguments to load `docker-composer-couchdb.yaml` or not.
@terrypst you can learn from e2e_cli example, which supports couchdb specified by command arguments to load `docker-compose-couchdb.yaml` or not.
hi, i am inspecting e2e_cli ledgers on orderer0, peer0~3. and find that the size of my chain storage file (blockfile_000000) is different listed as below.
order0: 149452 bytes
peer0: 149480 bytes
peer1~peer3: same as peer0
why is the orderer ledger size 28 bytes less than peer0~3?
hi, i am inspecting e2e_cli ledgers on orderer0, peer0~3. and find that the size of my chain storage file (blockfile_000000) is different. the file sizes are listed as below.
order0: 149452 bytes
peer0: 149480 bytes
peer1~peer3: same as peer0
why is the orderer ledger size 28 bytes less than peer0~3?
hi, i am inspecting e2e_cli ledgers on orderer0, peer0~3. and find that the size of my chain storage file (blockfile_000000) is different. the file sizes are listed as below.
orderer0: 149452 bytes
peer0: 149480 bytes
peer1~peer3: same as peer0
why is the orderer ledger size 28 bytes less than peer0~3?
@bh4rtp Peer adds some additional metadata into the non-hashed portion of the block, specifically an indicator of whether transactions were validated or invalidated at commit time. Orderer is not aware of this and doesn't record this.
Has joined the channel.
Has joined the channel.
Has joined the channel.
2017-06-26 10:20:07,481:INFO http-nio-8080-exec-2 (Util.java:39) - Created channel channel
2017-06-26 10:20:07,621:INFO http-nio-8080-exec-2 (Channel.java:413) - Peer peer1.org1.example.com joined into channel channel
2017-06-26 10:20:07,622:INFO http-nio-8080-exec-2 (Util.java:39) - Peer peer1.org1.example.com joined channle channel
2017-06-26 10:20:07,648:ERROR http-nio-8080-exec-2 (Channel.java:2138) - Sending proposal to peer0.org1.example.com failed because of gRPC failure=Status{code=UNKNOWN, description=chaincode error (status: 500, message: Cannot create ledger from genesis block, due to LedgerID already exists), cause=null}
java.lang.Exception: io.grpc.StatusRuntimeException: UNKNOWN: chaincode error (status: 500, message: Cannot create ledger from genesis block, due to LedgerID already exists)
anyone occur the error
?
you tried to join channel twice?
no
the peer0.org1.example.com join the channel
the peer1.org1.example.com join the channel
Has joined the channel.
Hi guys, I have a question regarding to the user accounts admin1 and user1 in fabric crypto-config.
a) Why do we need o create them ?
b) Is there any role / definition of permission between these two user accounts?
c) How can I use them ? the application of them.
@rezamt I've posted your question to the #fabric-crypto channel
@dave.enyeart thanks. I wasn't sure to post it here or somewhere else.
Has joined the channel.
Has joined the channel.
From what I can tell, it doesn't appear chaincode source doesn't end up in the ledger. Is that really the case? Seems like that would be extremely valuable. Only the hash of the source code is persisted?
@toddinpal the code is not on the ledger. the lifcycle system chaincode "lscc" maintains records of instantiations on the ledger
@muralisr Is there a specific reason the source code isn't saved on the ledger? Without it, it would be difficult to completely recover using just the ledger. As well I would think there would be regulatory situations where you might need to prove your chaincode behaved the way you claimed it did.
The only way to prove that would be to have the source code.
so the lscc does maintain the fingerprint of the code
for regulatory purposes we can compare the fingerprint with the code.
right... Is there a reason to only maintain the hash?
The flipside of having the code in the ledger would be that it'll be available to everyone on the channel... having it outside gives you the option of controlling who "owns" the code (ie, those that can endorse)
yeah, but that seems like a privacy issue...
hmmm maybe not
it basically gives you more flexibility as to who can have the code
OK, so it "protects" the code from the non-endorsing peers on the channel
right, that and in general only those that need the code have it.
Although the source could be encrypted before being placed on the ledger...
sure
but then we have to solve problems as to who can decrypt etc, but yes, that's another approach.
yup... ok, many thanks! :-)
Hi
I'm currently facing an issue with orderer and ledger (file mode)
is this channel the good place to speak about it ?
let me know if I need to move the problem description in another channel
here's my issue :
*1)* I start the fabric env (one app, one peer, one chaincode, one orderer, one ca) through a `docker-compose up -d`. Ledger in orderer is configured as file.
*2)* Then I stop and remove all (`docker-compose stop && docker-compose rm -f`).
*NOTE:* I configured all containers to store files like conf and ledger files in the host. So when removing containers I dont remove the existing data and conf.
*3)* Then I restart (`docker-compose up -d`). And I finally get following error :
```
2017-06-30 10:00:21.127 UTC [orderer/main] main -> INFO 001 Starting orderer with TLS enabled
2017-06-30 10:00:21.210 UTC [msp] getMspConfig -> INFO 002 MSP configuration file not found at [/etc/hyperledger/fabric/orderer/msp/config.yaml]: [stat /etc/hyperledger/fabric/orderer/msp/config.yaml: no such file or directory]
2017-06-30 10:00:21.276 UTC [orderer/main] main -> INFO 003 Not bootstrapping because of existing chains
2017-06-30 10:00:21.294 UTC [orderer/multichain] newLedgerResources -> CRIT 004 Error creating configtx manager and handlers: Bad envelope: Not a tx of type CONFIG
panic: Error creating configtx manager and handlers: Bad envelope: Not a tx of type CONFIG
goroutine 1 [running]:
panic(0xb035e0, 0xc420349420)
/opt/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panicf(0xc4201b98c0, 0xc3a748, 0x30, 0xc420349370, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:194 +0x127
github.com/hyperledger/fabric/orderer/multichain.(*multiLedger).newLedgerResources(0xc420338000, 0xc420257440, 0xc420257440)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/multichain/manager.go:159 +0x393
github.com/hyperledger/fabric/orderer/multichain.NewManagerImpl(0x11b03c0, 0xc420358220, 0xc4202565a0, 0x11adbc0, 0x11f4980, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/multichain/manager.go:109 +0x23b
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/main.go:174 +0x179d
```
here's my issue :
*1)* I start the fabric env (one app, one peer, one chaincode, one orderer, one ca) through a `docker-compose up -d`. Ledger in orderer is configured as file.
*2)* Then I stop and remove all ( `docker-compose stop && docker-compose rm -f` ).
*NOTE:* I configured all containers to store files like conf and ledger files in the host. So when removing containers I dont remove the existing data and conf.
*3)* Then I restart ( `docker-compose up -d` ). And I finally get following error :
```
2017-06-30 10:00:21.127 UTC [orderer/main] main -> INFO 001 Starting orderer with TLS enabled
2017-06-30 10:00:21.210 UTC [msp] getMspConfig -> INFO 002 MSP configuration file not found at [/etc/hyperledger/fabric/orderer/msp/config.yaml]: [stat /etc/hyperledger/fabric/orderer/msp/config.yaml: no such file or directory]
2017-06-30 10:00:21.276 UTC [orderer/main] main -> INFO 003 Not bootstrapping because of existing chains
2017-06-30 10:00:21.294 UTC [orderer/multichain] newLedgerResources -> CRIT 004 Error creating configtx manager and handlers: Bad envelope: Not a tx of type CONFIG
panic: Error creating configtx manager and handlers: Bad envelope: Not a tx of type CONFIG
goroutine 1 [running]:
panic(0xb035e0, 0xc420349420)
/opt/go/src/runtime/panic.go:500 +0x1a1
github.com/hyperledger/fabric/vendor/github.com/op/go-logging.(*Logger).Panicf(0xc4201b98c0, 0xc3a748, 0x30, 0xc420349370, 0x1, 0x1)
/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/op/go-logging/logger.go:194 +0x127
github.com/hyperledger/fabric/orderer/multichain.(*multiLedger).newLedgerResources(0xc420338000, 0xc420257440, 0xc420257440)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/multichain/manager.go:159 +0x393
github.com/hyperledger/fabric/orderer/multichain.NewManagerImpl(0x11b03c0, 0xc420358220, 0xc4202565a0, 0x11adbc0, 0x11f4980, 0x0, 0x0)
/opt/gopath/src/github.com/hyperledger/fabric/orderer/multichain/manager.go:109 +0x23b
main.main()
/opt/gopath/src/github.com/hyperledger/fabric/orderer/main.go:174 +0x179d
```
uhm just saw this `MSP configuration file not found at [/etc/hyperledger/fabric/orderer/msp/config.yaml]: [stat /etc/hyperledger/fabric/orderer/msp/config.yaml: no such file or directory]`
not sure this is related with the rest
not sure there is link with the panic error
I think this is not linked as when I'm starting from scratch the orderer log same and is starting fine :
```
2017-06-30 10:07:05.700 UTC [orderer/main] main -> INFO 001 Starting orderer with TLS enabled
2017-06-30 10:07:05.910 UTC [msp] getMspConfig -> INFO 002 MSP configuration file not found at [/etc/hyperledger/fabric/orderer/msp/config.yaml]: [stat /etc/hyperledger/fabric/orderer/msp/config.yaml: no such file or directory]
2017-06-30 10:07:06.077 UTC [orderer/multichain] NewManagerImpl -> INFO 003 Starting with system channel testchainid and orderer type solo
2017-06-30 10:07:06.077 UTC [orderer/main] NewServer -> INFO 004 Starting orderer
2017-06-30 10:07:06.078 UTC [orderer/main] main -> INFO 005 Beginning to serve requests
```
if you have any idea on how I can solve this issue please share ;)
There isn't a link
can you upload you docker-compose files?
to pastebin, etc.
Has joined the channel.
Has joined the channel.
Has joined the channel.
How do i create an asset that can not be updated? Its an asset that exists as long a channel exists.
@gen_el - you will have to put this logic in your chaincode.
@manish-sethi And there is no other way?
No, what other way you have in mind?
by design, fabric-ledger manages state without know the application context and it provides all create/update/delete operations on state elements.
by design, fabric-ledger manages state without knowledge of the application context and it provides all create/update/delete operations on state elements.
App (chaincode) manages it's logic of manipulating the state
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=TRjFdgd6wcoBwvHfR) @manish-sethi Ok. I see
Has joined the channel.
Has joined the channel.
https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/interfaces.go#L229-L235
@dave.enyeart , @muralisr what does this do? can we get rid of it?
It embeds an existing interface so I don't see the point of having it, or am I missing something?
The GetHistoryForKey and GetQueryResult aren't implemented in the mockstub, but I don't see why it's related
Has joined the channel.
Has joined the channel.
Has joined the channel.
hey guys, can anyone tell me if one could use a custom key for the putState and getState in the fabric? for instance the "err = stub.PutState(A, []byte(strconv.Itoa(Aval)))"; can we instead of the "A" being a string representing the key here, can "A" be a custom defined object?
@muralisr ^
@here I have a question about object storage in ledger when it comes to searching. Is there a way to create a ledger entry with multiple keys? For example, I have a Contract object that has an id, a consumer, and a provider. I want to store these contract and be able to search for them by consumer, provider, or id.
@elrond the key has to be a string. However, you can build a composite key that can be constructed from multiple independent attributes. You can look for the further details on this in the documentation. Also, if you use couch db, you can perform search queries on anyattribute(s) of the `value` as well.
@akashmar the above answer is applicable to your query as well
yes, iv seen it in the marbles example, very interesting and straight forward. thanks
What kind of queries can I perform on the default db? Is there an example somewhere? The marbles example says the queries are only supported by a state database that supports rich queries like couchdb.
@akashmar - there are two dbs that are supported as yet. Leveldb and couchdb - the default is leveldb. In both of these dbs, point queries (lookup by key) and key range queries are supported. In addition, you can use couch query language if you are using couchdb underneath. However, a caveat with couch queries would be that the full serializable isolation level is not supported if transactions use this (For the key lookup and range queries) it is supported. So, ideally, couch rich query you may want to limit to read only transactions - unless you are very sure of your application semantics - e.g., I am fine even if my transactions observe phantoms and hence do not care of serializable isolation level.
@akashmar - there are two dbs that are supported as yet. Leveldb and couchdb - the default is leveldb. In both of these dbs, point queries (lookup by key) and key range queries are supported. In addition, you can use couch query language if you are using couchdb underneath. However, a caveat with couch queries would be that the full serializable isolation level is not supported if transactions use this (For the key lookup and range queries, it is supported). So, ideally, couch rich query - you may want to limit to read only transactions - unless you are very sure of your application semantics - e.g., I am fine even if my transactions observe phantoms and hence do not care of serializable isolation level.
Got it. Thanks!
Has joined the channel.
Hi everyone. I have a question about how a peer maintains its ledger. In Fabric, each peer maintains a full copy of the ledger/blockchain (let's assume there is only one channel). What will happen if a peer lost one of its blocks in the blockchain (e.g. another process on the peer accidentally wiped out the disk area that stores the block)? Will this peer be able to detect that this block is missing? If yes, how will the peer detect it and how is it going to repair? It will also be helpful if some clue from the source code can be provided. Thanks!
@qizhang the blocks are maintained in the block files (64MB each). Whenever the ledger would try the get blocks from the affected area of the file (that you mentioned in your scenario), it would detect the error and a panic is expected. Scanning the blocks within a block range (e.g., retrieve blocks between 10 and 100) is one such function - In other words, the ledger would detect the error only when it uses the file.
Ledger would not automatically fix the error and a restoration of the corrupted file is expected from the admin - either from a back up (if any) or from a peer that you trust. In the worst case, one can delete all the upwards files (the corrupted file and the files afterwards based on the numbering and the block indexes). Now, upon restart, the peer would be able to get the blocks again from the network)
For the code reference, you may like to explore this package https://github.com/hyperledger/fabric/tree/master/common/ledger/blkstorage
In particular - you may like to go through this file https://github.com/hyperledger/fabric/blob/master/common/ledger/blkstorage/fsblkstorage/block_stream.go
Has joined the channel.
@manish-sethi Thanks! When a ledger is going to use the file that stores a block whose height is far less than that of the block head? Does a peer need to go over all the related historical transactions in the ledger in order to validate a newly arrived transaction? If yes, that could be a scenario that an older block needs to be accessed.
No. Validation of newly arrived transactions is performed against statedb. The statedb maintains the latest state - which represent the net-effect of all the previous transactions. Going though actual blocks for validation will result in much poorer performance - which would further keep degrading as the time passes
No. Validation of newly arrived transactions is performed against statedb. The statedb maintains the latest state - which represents the net-effect of all the previous transactions. Going though actual blocks for validation will result in much poorer performance - which would further keep degrading as the time passes
@manish-sethi you mentioned that "Scanning the blocks within a block range (e.g., retrieve blocks between 10 and 100) is one such function - In other words, the ledger would detect the error only when it uses the file.". I am checking the block_stream.go, but still wondering in what scenario "scanning the blocks within a block range" will happen. Please advise.
@manish-sethi what do you mean by 64MB each? a block can be less than 64MB no?
@yacovm yes, a block a far less than 64MB. But a file is used in an append only mode for appending many blocks till the size crosses 64MB and at that instance a new file is created for next series of blocks
ah, got it
thanks
@qizhang - the usual scenarios where the block files are touched are - some other peer asking for blocks (e.g., a newly joined peer or a peer trying to catch up) and rebuilding statedb/historydb from scrach.
@manish-sethi I see. Thanks!
Has joined the channel.
Interesting conversation, above thread improved my understanding too! thanks guy
s
hi, how does auditing work at the three level: system level, user level and contract level?
hello, I learned that It does not matter about if the transaction is signed by respecting the endorsement policy or not, it wiil be sent as block to peers by orderer service, then peers will check the valididate of this transaction block, if it is validated, if will take effect in the transactions story. And in both cases , this block wiil be store in the ledger.
But can anyone tell me how to differentiate a valid transaction block, and an invalid transaction block? only by checking signatures?
I used the nodejs sdk function channel.queryblock() to get block information of a valided transaction and an invalided one, however, I cannot see the difference between these two blocks' information, is there a target/label which indicate if this block is valided or not...?
@akdj block has a metadata field, which includes an array of transaction statuses
```// This is finalized block structure to be shared among the orderer and peer
// Note that the BlockHeader chains to the previous BlockHeader, and the BlockData hash is embedded
// in the BlockHeader. This makes it natural and obvious that the Data is included in the hash, but
// the Metadata is not.
type Block struct {
Header *BlockHeader `protobuf:"bytes,1,opt,name=header" json:"header,omitempty"`
Data *BlockData `protobuf:"bytes,2,opt,name=data" json:"data,omitempty"`
Metadata *BlockMetadata `protobuf:"bytes,3,opt,name=metadata" json:"metadata,omitempty"`
}```
```type BlockMetadata struct {
Metadata [][]byte `protobuf:"bytes,1,rep,name=metadata,proto3" json:"metadata,omitempty"`
}```
`BlockMetadataIndex_TRANSACTIONS_FILTER BlockMetadataIndex = 2`
here is the list of possible reasons
```const (
TxValidationCode_VALID TxValidationCode = 0
TxValidationCode_NIL_ENVELOPE TxValidationCode = 1
TxValidationCode_BAD_PAYLOAD TxValidationCode = 2
TxValidationCode_BAD_COMMON_HEADER TxValidationCode = 3
TxValidationCode_BAD_CREATOR_SIGNATURE TxValidationCode = 4
TxValidationCode_INVALID_ENDORSER_TRANSACTION TxValidationCode = 5
TxValidationCode_INVALID_CONFIG_TRANSACTION TxValidationCode = 6
TxValidationCode_UNSUPPORTED_TX_PAYLOAD TxValidationCode = 7
TxValidationCode_BAD_PROPOSAL_TXID TxValidationCode = 8
TxValidationCode_DUPLICATE_TXID TxValidationCode = 9
TxValidationCode_ENDORSEMENT_POLICY_FAILURE TxValidationCode = 10
TxValidationCode_MVCC_READ_CONFLICT TxValidationCode = 11
TxValidationCode_PHANTOM_READ_CONFLICT TxValidationCode = 12
TxValidationCode_UNKNOWN_TX_TYPE TxValidationCode = 13
TxValidationCode_TARGET_CHAIN_NOT_FOUND TxValidationCode = 14
TxValidationCode_MARSHAL_TX_ERROR TxValidationCode = 15
TxValidationCode_NIL_TXACTION TxValidationCode = 16
TxValidationCode_EXPIRED_CHAINCODE TxValidationCode = 17
TxValidationCode_CHAINCODE_VERSION_CONFLICT TxValidationCode = 18
TxValidationCode_BAD_HEADER_EXTENSION TxValidationCode = 19
TxValidationCode_BAD_CHANNEL_HEADER TxValidationCode = 20
TxValidationCode_BAD_RESPONSE_PAYLOAD TxValidationCode = 21
TxValidationCode_BAD_RWSET TxValidationCode = 22
TxValidationCode_ILLEGAL_WRITESET TxValidationCode = 23
TxValidationCode_INVALID_OTHER_REASON TxValidationCode = 255
)```
Has joined the channel.
Has joined the channel.
@C0rWin thank you, I noticed the "metadata" in the json form of the blocks, and I guess it should be in "value" of "metadata" that is indicated the TxValidationCode
however, I have nothing in the "value"..
Has joined the channel.
```
"metadata": {
"metadata": [
{
"value": "",
"signatures": [
{
"signature_header": {
"creator": {
"Mspid": "OrdererMSP",
"IdBytes": "-----BEGIN -----\nMIICTDCCAfKgAwIBAgIQZCxnb7X/qEqddnBqcO94mzAKBggqhkjOPQQDAjBpMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEUMBIGA1UEChMLZXhhbXBsZS5jb20xFzAVBgNVBAMTDmNhLmV4YW1w\nbGUuY29tMB4XDTE3MDcwNDA4Mzg0OVoXDTI3MDcwMjA4Mzg0OVowWDELMAkGA1UE\nBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lz\nY28xHDAaBgNVBAMTE29yZGVyZXIuZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAAQoI6c8cco5bVSr4475r/SBOaD/C/RmzhIh+kN2i/MFr98VgCzC\n6c3Roalji0+etsRuzNi4oLv8/DKrJyuGJw5to4GMMIGJMA4GA1UdDwEB/wQEAwIF\noDATBgNVHSUEDDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMCsGA1UdIwQkMCKA\nIKhmv1Izr4AUsVlRvfCaOa336C4cJlnM5NNR14s+k6yoMCcGA1UdEQQgMB6CE29y\nZGVyZXIuZXhhbXBsZS5jb22CB29yZGVyZXIwCgYIKoZIzj0EAwIDSAAwRQIhALeX\nJj96TJzgQKONKQfVnEZqdZE7ev5BUAIN5uaOmEqPAiBs8hK2Nm3tojA+UxHOYtHC\nnqtkPxBlEY/42kyJYNB6xw==\n-----END -----\n"
},
"nonce": {
"type": "Buffer",
"data": [.... ]
}
},
"signature": {
"type": "Buffer",
"data": [..... ]
}
}
]
},
{
"value": {
"index": {
"low": 0,
"high": 0,
"unsigned": true
}
},
"signatures": [
{
"signature_header": {
"creator": {
"Mspid": "OrdererMSP",
"IdBytes": "-----BEGIN -----\nMIICTDCCAfKgAwIBAgIQZCxnb7X/qEqddnBqcO94mzAKBggqhkjOPQQDAjBpMQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEUMBIGA1UEChMLZXhhbXBsZS5jb20xFzAVBgNVBAMTDmNhLmV4YW1w\nbGUuY29tMB4XDTE3MDcwNDA4Mzg0OVoXDTI3MDcwMjA4Mzg0OVowWDELMAkGA1UE\nBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBGcmFuY2lz\nY28xHDAaBgNVBAMTE29yZGVyZXIuZXhhbXBsZS5jb20wWTATBgcqhkjOPQIBBggq\nhkjOPQMBBwNCAAQoI6c8cco5bVSr4475r/SBOaD/C/RmzhIh+kN2i/MFr98VgCzC\n6c3Roalji0+etsRuzNi4oLv8/DKrJyuGJw5to4GMMIGJMA4GA1UdDwEB/wQEAwIF\noDATBgNVHSUEDDAKBggrBgEFBQcDATAMBgNVHRMBAf8EAjAAMCsGA1UdIwQkMCKA\nIKhmv1Izr4AUsVlRvfCaOa336C4cJlnM5NNR14s+k6yoMCcGA1UdEQQgMB6CE29y\nZGVyZXIuZXhhbXBsZS5jb22CB29yZGVyZXIwCgYIKoZIzj0EAwIDSAAwRQIhALeX\nJj96TJzgQKONKQfVnEZqdZE7ev5BUAIN5uaOmEqPAiBs8hK2Nm3tojA+UxHOYtHC\nnqtkPxBlEY/42kyJYNB6xw==\n-----END -----\n"
},
"nonce": {
"type": "Buffer",
"data": [..... ]
}
},
"signature": {
"type": "Buffer",
"data": [.....]
}
}
]
},
[]
]
}
```
it looks like configuration block rather the block with regular transactions
and how to get the regular transaction block? i'm using this method https://fabric-sdk-node.github.io/Channel.html#queryBlock__anchor with last block id 4 as the id, because when I tried 5, it said that there is not block with id 5
@C0rWin how to get the regular transaction block? i'm using this method https://fabric-sdk-node.github.io/Channel.html#queryBlock__anchor with last block id 4 as the id, because when I tried 5, it said that there is not block with id 5
Has joined the channel.
I'm not fairly familiar with NodeSDK, so try to ask @jimthematrix to see how you can access metadata related to transactions state
right, i believe SDK has a function to retrieve valid/invalid state of a tran. Check on #fabric-sdk-node
Has joined the channel.
@manish-sethi Is there any document describing the design of the fabric-ledger in detail?
@qizhang unfortunately, not in a consolidated form that covers a whole lot of details.... as of now, the docs focus is more on the user documents. So, for now the best bet would be to look at the code or discuss on this channel...
@qizhang unfortunately, not in a consolidated form that covers a whole lot of details.... as of now, the docs focus is more on the user documents. So, for now, the best bet would be to look at the code or discuss on this channel...
@manish-sethi I see, thanks! I did some profiling on Fabric v1.0.0-rc1, and found that in each peer, the fsblkstorate.(*blockIndex).IndexBlock takes 50% of the CPU time, any idea of what could be the reason?
That would a surprising thing... as compared to other pieces of fabric, nothing cpu intensive tasks happen in this function. Are you doing this profiling in isolation of some ledger only code? or end-to-end transaction execution on a peer?
@manish-sethi I am using this benchmark https://github.com/dongmingh/v1performance. I think it is end-to-end transaction execution
Message Attachments
Why do I see only ledger/blkstorage entries in these traces... did you enabled profiling only for this package?
Actually, I enabled the profiling for all the packages, this is only part of the results.
OK, can you upload your profiling file here... I'll take a look later
yes, I am getting it
Message Attachments
@manish-sethi here it is
Sure, will have a look sometime later... and will let you know if I find anything conclusive.
thanks @manish-sethi
Has joined the channel.
Has joined the channel.
@manish-sethi @qizhang In our study, we see that fsblkstorate.(*blockIndex).IndexBlock takes only 0.12%
commitBlock() from gossip to committer itself takes only 10%
Has joined the channel.
@Senthil1 that's interesting！Can you let me know more details of your experiments? Such as the setup, the workload, and how to get the results? Thanks!
@Senthil1 - yes that appears to be a more reasonable numbers
@manish-sethi @Senthil1 I agree. Expecting to find out the reason why I got the numbers that I have. I am using the pprof tool the get the function runtime statistics from each peer.
Has joined the channel.
state ledger
@qizhang we have 8 peer setup each running on a VM and 1 orderer and 1 kafka-zookeeper on two differernt VMs.
Irrespective of the load on peer, the time taken by the commitBlock and IndexBlock is too low.
chaincode is executing a tx which just writes a
we aren't using PTE however.
Can you explain your setup?
@manish-sethi yes. We get such numbers consistently.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Possible bug: Let's pretend I have a global variable I set to zero in the Init function of my chaincode. Every time a peer calls the single invoke function I have, it increments the variable. However, when an invoke call is first made by a peer, the variable gets reset to zero. Is this desired behavior that I'm supposed to code around?
@jarroyer are you expecting that variable to be shared among the chaincodes?
each peer installs the chaincode, but they instantiate their own instance of it
@jarroyer I'm not following "when an invoke call is first made by a peer, the variable gets reset to zero". Please expand on that statement with your expected behavior and your observed behavior.
the global variable will be accessed within that specific built instance, but its not shared between the peers
it's not that the variable is reset, when that docker container with the chaincode comes up its intialized at 0
@dave.enyeart rather the first invoke call that a peer makes resets it to zero.
again, clarify what the chaincode is doing, what the expected behavior would be, and what the observed behavior is
@jrosmith that makes sense. The weird part is that after a peer makes its first call, it will "receive" the value for the variable and match the other peers that have called it already
@dave.enyeart without too much detail, I'm using the variable to increment the key for the
Peer has no ability to define blocks or which blocks get stored. Blocks are cut by ordering service and disseminated to all peers in same order.
Yes but the original question was more so asking about the global variables in the chaincode and if they were supposed to be shared or not.
Might've been simpler to just ask it that way :)
@Senthil1 I have a network with 1 orderer, 2 CAs, 2 orgs, and each org has two peers. Each component (such as order, CA, peer) is running on a docker container, and all the containers are running on a single machine.
Define what you mean by global variable. There is only one type of variable, and it is at channel/chaincode scope
A Golang global variable, declared in the scope of the chaincode outside of a function.
It is not legal to use golang global variables across chaincode invocations
It is not legal to use golang global variables across chaincode invocations, since containers may come and go
you must only use chaincode keys/values to store state
Yeah that's what I was asking. Thanks!!
@Senthil1 I am using the v1performance benchmark. The client generates requests at the rate of 1req/ms to the anchor peers in both orgs. Each request write a
ok right, if you attempt to use golang global variables then your results are indeterminate
ok right, if you attempt to use golang global variables then your results are indeterminate, don't do it!
anyone knows how to turn on and off the "security" feature in Fabric?
Has joined the channel.
@qizhang use flame graph to get a global view of all call stack. Then, you can search on the flame graph for indexBlock to see the time it takes.
We can only enabled/disable TLS but signature/verification are integral part of fabric (as they enable non-repudiability property in blockchain).
@Senthil1 Can you let me know what is the throughput (trans/sec) you get when you enable and disable the TLS respectively?
don't have that number. anyway, TLS is expected to add a constant overhead per communication..
I've got a question on db persistence. I am following the byfn tutorial, and turned on dbPersistence. Then I restarted the VM.
Obviously the containers were all destroyed by the time I stepped back into the VM. With the containers gone, there is no more peer0/1 etc, so I set about recreating these. But in the peer channel create step, the cli container stops me saying "Bad request" - which means that the channel I'm trying to create already exists.
What do I do?
If you persist the container data on the host, the next time the containers start they will pick up where they left off in terms of ledger state. The channel from the prior run would already exist, as well as any chaincode data that was created.
In docker-compose-cli.yaml, you can comment out the line:
`command: /bin/bash -c './scripts/script.sh ${CHANNEL_NAME}; sleep $TIMEOUT'
`command: /bin/bash -c './scripts/script.sh ${CHANNEL_NAME}; sleep $TIMEOUT'`
That will prevent the script that creates the data and sends transactions from executing
That will prevent the script that creates the channel and sends transactions from executing automatically
then you can follow the manual instructions to do whatever you like (install/instantiate a different chaincode, send transactions, queries, etc)
Hi - Is cross channel query from the chaincode supported in V1 please? This story suggests it was not part of V1: https://jira.hyperledger.org/browse/FAB-2490
```
// InvokeChaincode locally calls the specified chaincode `Invoke` using the
// same transaction context; that is, chaincode calling chaincode doesn't
// create a new transaction message.
// If the called chaincode is on the same channel, it simply adds the called
// chaincode read set and write set to the calling transaction.
// If the called chaincode is on a different channel,
// only the Response is returned to the calling chaincode; any PutState calls
// from the called chaincode will not have any effect on the ledger; that is,
// the called chaincode on a different channel will not have its read set
// and write set applied to the transaction. Only the calling chaincode's
// read set and write set will be applied to the transaction. Effectively
// the called chaincode on a different channel is a `Query`, which does not
// participate in state validation checks in subsequent commit phase.
// If `channel` is empty, the caller's channel is assumed.
InvokeChaincode(chaincodeName string, args [][]byte, channel string) pb.Response```
@gormand ^^^ `InvokeChaincode` API is already available
you can take a look on the example here: https://github.com/hyperledger/fabric/blob/master/examples/chaincode/go/chaincode_example04/chaincode_example04.go#L88
Brilliant, thanks @C0rWin
@gormand @C0rWin There are two different concepts.
1) chaincode2chaincode queries (which may be on different channels). This is in 1.0 as @C0rWin demonstrated.
2) non-key queries against a chaincode that spans all channels that you are a member of. e.g. show me all trades over one million dollars irregardless of the channel. This is an idea for the future captured in FAB-2490.
currently, if you had N channels you would have to make N channel-scoped queries. the idea is that you could send one query to your peer and it would execute the query across all channels.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=pNRzqSvDJTGxmH4KP) @dave.enyeart Thanks, but that is where my problem lies. I looked up the containers - they were destroyed. They I ran the byfn script to bring up the framework (with the scripts.sh commented out), but my CLI container doesn't get started.
Data persistence should not impact whether CLI container comes up. Is there an error upon CLI container start?
Has joined the channel.
The CLI container does come up. But the chaincodes seem to be all gone. I cannot query the nodes any more from within the CLI container.
Has joined the channel.
Has joined the channel.
the couchdb doesn't support limit skip
?
@chenxuan I found this bug yesterday: https://jira.hyperledger.org/browse/FAB-5369
i take a look
it's wrapper by data
it's ok
you can take a look the couchdb
or https://github.com/hyperledger/fabric/blob/release/examples/chaincode/go/marbles02/marbles_chaincode.go
@sstone1 yes
https://jira.hyperledger.org/browse/FAB-2809
queryString, err := ApplyQueryWrapper(namespace, query, queryLimit, 0)
@sstone1
the skip is set 0
yep
and then the code i linked to in the bug always sets limit and skip, even if the user specified them in the CouchDB query string
so the limit and skip doesn't work
the limit is set 1w how to modify
@sstone1
i see the code
queryLimit := viper.GetInt("ledger.state.couchDBConfig.queryLimit")
i am not unfamiliar with the go
it get the env var ledger.state.couchDBConfig.queryLimit if so
where can i modify
@chenxuan i'm not a fabric developer, i just spotted the bug
@manish-sethi
@dave.enyeart
@sstone1 @chenxuan we did intend to revisit how 'paging' works, balancing function, performance, and mitigation of malicious user requests. FAB-2809 is part of that. We'll also consider FAB-5369 during that assessment. Will get back to you. @chris.elder
Has joined the channel.
Hello Everyone, I have questions on scalability of Fabric Ledger, how should we handle the ledger state when the data grows after a year. Is there is option to archive so that peers in the network can archive data older than 1 year.
I meant will there be an option to archive or should we just do capacity planning for peer to keep the transaction data forever. It does not sound right ? so I wanted to get your thought how we should handle it.
Has joined the channel.
Has joined the channel.
@dave.enyeart do you test the performance about the couchdb
use for ledger
Has joined the channel.
@chenxuan Performance is indeed faster when using goleveldb vs couchdb. Some work is underway to quantify it. Also some work is underway to do bulk validation/commits against couchdb, which should raise performance to the point where there is not a material difference between using fabric with goleveldb vs couchdb.
The work item for the couchdb bulk processing is https://jira.hyperledger.org/browse/FAB-2725
@gauthampamu In the 'classic' blockchain data is preserved forever. However there is acknowledgement that some networks will want to archive old unneeded data. There is intent to provide such capability in the future. The work item is https://jira.hyperledger.org/browse/FAB-106
Hi, Quick question. In other DLTs (e.g Quorum), there is a concept of Global Synchronization Log (GSL) where all private transactions (hashes) are maintained by the ledger across all the nodes in the network but the private state is only maintained by peers that are part of the transactions. IF we have to do this in Fabric, Can we do it by creating a Global Channel with all nodes are part of and chaincodes only installed and instantiated on the required peers and with appropriate visibility setting (future build) such as data hash in the transactions ?
[ ](https://chat.hyperledger.org/channel/fabric?msg=imHLHy2msAJEcodZT) @nhrishi moving to this channel as I think folks here can point you to the specific issue
@nhrishi https://jira.hyperledger.org/browse/FAB-4287
@nhrishi https://jira.hyperledger.org/browse/FAB-1151 https://jira.hyperledger.org/browse/FAB-4287
@nhrishi the first link I think is the main one, and you can verify if it is the concept you had in mind
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ZyTcg5HD6uZfxb7iT) @jeffgarratt Thanks. WIll check this out.
Hi everyone, how does fabric detect when a block was hacked into and changed? Thanks!
Hi everyone, if an old block in the blockchain get hacked into and changed, how Fabric is going to detect it? Thanks!
@qizhang If ledger data has been altered or corrupted it will be detected the next time the data is accessed.
Transactions require N endorsers, the transaction results (reads and writes) across these endorsers must match. If ledger data had been altered or corrupted on a peer then the transaction results would be inconsistent across endorsing peers, the 'bad' peer will be found out, and the application client can throw out the results from the bad peer before submitting the transaction for ordering/commit. If client application tries to submit a transaction with inconsistent endorsement regardless, this will be detected and the transaction will be invalidated by all peers at commit time.
If you are doing read-only queries rather than update transactions, then you can similarly query multiple endorsing peers and verify the results from each are consistent.
Ultimately the chain is the hash-chained source of truth. If there is doubt about state database integrity, the state database can be deleted and it will automatically get regenerated from the chain. If there is doubt about the chain integrity itself, it too can be dropped and it will be state transferred from another peer.
There is intent to provide a Verify function in the future that would proactively traverse the entire chain, recompute hashes, and therefore verify the chain integrity. The work item and sample code can be found at https://jira.hyperledger.org/browse/FAB-609. In the meantime, a client could be written to get the blocks and do similar verification.
Thanks @dave.enyeart . I think a transaction will only access the world state DB, can you explain how a transaction is going to access the data in the block, especially a block committed a long time ago? Since I am interested in the case that a past block in the ledger, which was committed months ago, get hacked into and changed.
Has joined the channel.
why does the fabric need consensus(like PBFT) since it has endorsement policy? for example, if all peers required to endorse the transaction endorse the transaction, that means, I think, they have reach the consensus, so why do fabric need consensus algor
@howardhou consensus is for orderers to agree on the transactions order
@Vadim
Thanks. is that the functionality the consensus algorithm play in Ethereum ?
@howardhou yes, though in Ethereum a node combines orderer and peer in one process, so it is a bit different
@Vadim
Ok, Let me conclusion, Consensus algorithm is used to order the transactions in Fabric and Ethereum, right?
@howardhou it Ethereum it also to make sure that the state is consistent across nodes, in Fabric this is achieved by a combination of endorsement policies, commit block MVCC checks, orderer consensus. I might have missed something.
@Vadim
Get it. Thanks very much.
Has joined the channel.
How can we get the Channel which was previously created
@qizhang In order to re-verify an old block you would have to run a validator against it. As mentioned above, a built in validator utility is intended. Until then you would have to write your own validator client which could check block hashes and orderer signature.
Has joined the channel.
@dave.enyeart I see. But is there any case, in current Fabric, that a transaction needs to access some data in a historical block in the blockchain?
@qizhang stateDB has current state of all keys. If one needs to look at past values of a key, GetHistoryForKey() can be used.
@Senthil1 But stateDB and ledger are different things, and the blocks are stored in the ledger, is the right?
we have
(i) block storage in a file system(chain of block)
(ii) stateDB (contains current value of all keys)
(iii) historyDB (an index into block storage. index is on chaincodename~key~blockNum~txNum)
here, we can say block storage as the ledger.. stateDB is used so that chaincode can get/put state efficiently. Otherwise, going through block data would be slow..
here, we can take block storage as the ledger.. stateDB is used so that chaincode can get/put state efficiently. Otherwise, going through block data would be slow..
Yes, that's clear. So for a transaction, it is only going to access the stateDB, but not the block storage or the historyDB, right?
@Senthil1 Yes, that's clear. So for a transaction, it is only going to access the stateDB, but not the block storage or the historyDB, right?
A transaction (chaincode invoke) can use GetHistoryForKey() to access past value of a key stored in a deep block.. However, we do not add this read to readSet. If some other peer node had modified that block, the same transaction would read a wrong value.
A transaction (chaincode invoke) can use GetHistoryForKey() to access past value of a key stored in a deep block.. However, we do not add this read to readSet and the exact value. If some other peer node had modified that block, the same transaction would read a wrong value. Anyway, it can detected via difference in the writeset.
A transaction (chaincode invoke) can use GetHistoryForKey() to access past value of a key stored in a deep block.. However, we do not add this read to readSet. If some other peer node had modified that block, the same transaction would read a wrong value. Anyway, it can detected via difference in the writeset.
Hence, we suggest not to use GetHistoryForKey() in a transaction. Same goes for GetQueryResult()
@Senthil1 So it seems that the current values of all keys are stored in stateDB, and the past values of all keys are stored in the block? I am not quite clear with this design, please advise.
Yes, you are correct.
Hi everyone, I have a question about the following description in the figure, the figure is a screen shot from https://jira.hyperledger.org/browse/FAB-1721
Message Attachments
The question is why the peer can recover from the modification of a past block, but crash due to the change in the latest block?
My understanding is that there is no fundamental difference between the latest block and a past block, since both of them have been successfully submitted into the ledger. If a peer can recover from a changed past block, why can't it recover from the change in the latest block? Please advise, thanks!
Has anyone been able to try the code here? https://jira.hyperledger.org/browse/FAB-609
@qizhang Those test results do not look correct to me, can you identify the author so that we can ask them to double check?
FAB-609 had CR https://gerrit.hyperledger.org/r/#/c/4061/ which was tested at the time
@dave.enyeart Sure. But what is the correct test result then? I checked this link you sent, it is mostly talking about the code.
Block is never revisited after it is committed
Block is never updated after it is committed
Block is never updated or re-hashed after it is committed
@dave.enyeart Is there any chance that a committed block gets hacked into and changed? Then we will need some mechanism to recover that block.
You could write a verification utility that checks all the block hashes and signatures. If you discover the blocks are corrupted or tampered with I'd suggest rebuild the peer and upon startup state transfer will get the blocks from another peer.
@dave.enyeart Yes, I agree. Is the "VerifyChain()" function in leger_mmgt.go suppose to do the block verification? But yes, it is definitely not a tool for users yet.
yes, that code does block verification but it is probably stale now and needs a revisit
@dave.enyeart . There is leger_mmgt.go in the source code of Fabric-v1.0.0, but no "VerifyChain()" function in it.
right, it was deferred, that's why i called it a future intent
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=NmCNf3ysSkzAdHpfN) @qizhang If you talk about a hacking kind of scenario everything is possible. What if someone hacks the code that does verification? The whole idea is that one org is sharing the ledger of transactions with other orgs and still the other orgs cannot mess around with the copy of my ledger as long as I have my IT policies intact within my IT boundaries.
If I have hackers within my org they can anyway blow away my whole data even in the traditional IT systems... that's not the problem blockchain is meant to solve I believe
right, but unlike traditional IT systems with blockchain it is feasible to detect tampering and rebuild your data. i still think the verify function would be useful for this purpose.
I am talking about a hacking scenario. If the verify function says that the data is intact, can one trust on that results? Because, that code might have been hacked. We are talking here of a scenario where filesystem has been hacked
then perhaps the verify function is better as a client app that reads the blocks, rather than built into peer
I mean what guarantees can we provide under the assumption that a filesystem has been hacked...
file system could be hacked but it would be valuable to be able to detect that
Ultimately, its the code that you rely upon to detect... that also reside on filesystem
Ultimately, its the code that you rely upon to detect... that also resides on filesystem
@manish-sethi @dave.enyeart I agree with both of you. We will not be able to guarantee the blockchain is 100% safe, but having a tool to detect and recover from data tampering at least makes it safer
This is whole domain of trusted computing... folks try to achieve at an entire different level of hardware
This is whole domain of trusted computing... folks try to achieve at an entirely different level of hardware
In current design, I think a peer will not be able to detect if a block deep in the chain gets corrupted, unless the peer restarts, or the peer needs to access some data (old values) on that block
Although chances are that a corrupted block deep in the chain will probably not affect the correct execution of a peer.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=uRf8Ldv66LsbB7p2i) @qizhang yes, unless the same corruption has been introduced at majority of the peers, the future transactions won't get enough endorsements
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Hu98FbnH5E7wgSTTE) I think even if the same corruption has been introduced at majority of the peers, it could still NOT introduce any trouble, especially if the block was submitted long time ago, since the recent transaction will probably access only the latest version of the
yes, but even those could have been hacked... and the transactions get operated on wrong data
yes
Has joined the channel.
@qizhang Blockchain only provides immutability and non-repudiation. Any body can hack into a peer and make any modifications. During auditability, such hacking can be identified by just verifying orderer signature and the block content. No one can fake a transaction (its occurrence or nonoccurrence) when multiple parties are involved. One faulty peer cannot impact another faulty peer (anyway, it depends on how strong the endorsement policy is). Admin of a peer can lie to his org about any transaction if he is a hacker. However, he cannot trick other org peers.
@qizhang Blockchain only provides immutability and non-repudiation. Any body can hack into a peer and make any modifications. During auditability, such hacking can be identified by just verifying orderer signature which present in the block metadata and the block content. No one can fake a transaction (its occurrence or nonoccurrence) when multiple parties are involved. One faulty peer cannot impact another faulty peer (anyway, it depends on how strong the endorsement policy is). Admin of a peer can lie to his org about any transaction if he is a hacker. However, he cannot trick other org peers.
@qizhang Blockchain only provides immutability and non-repudiation. Any body can hack into a peer and make any modifications. During auditability, such hacking can be identified by just verifying orderer signature which present in the block metadata and the block content. No one can fake a transaction (its occurrence or nonoccurrence) when multiple parties are involved. One faulty peer cannot impact another faulty peer (anyway, it depends on how strong the endorsement policy is). Admin of a peer can lie to his org about any transaction if the admin is a hacker. However, he cannot trick other org peers.
@qizhang Blockchain only provides immutability and non-repudiation. Any body can hack into a peer and make any modifications. During auditability, such hacking can be identified by just verifying orderer signature which present in the block metadata and the block content. No one can fake a transaction (its occurrence or nonoccurrence). One faulty peer cannot impact another faulty peer (anyway, it depends on how strong the endorsement policy is). Admin of a peer can lie to his org about any transaction if the admin is a hacker. However, he cannot trick other org peers.
thanks @Senthil1
Is there any fabric function that can get the number of blocks in a ledger?
```// Ledger captures the methods that are common across the 'PeerLedger', 'OrdererLedger', and 'ValidatedLedger'
type Ledger interface {
// GetBlockchainInfo returns basic info about blockchain
GetBlockchainInfo() (*common.BlockchainInfo, error)
// GetBlockByNumber returns block at a given height
// blockNumber of math.MaxUint64 will return last block
GetBlockByNumber(blockNumber uint64) (*common.Block, error)
// GetBlocksIterator returns an iterator that starts from `startBlockNumber`(inclusive).
// The iterator is a blocking iterator i.e., it blocks till the next block gets available in the ledger
// ResultsIterator contains type BlockHolder
GetBlocksIterator(startBlockNumber uint64) (ResultsIterator, error)
// Close closes the ledger
Close()
// Commit adds a new block
Commit(block *common.Block) error
}```
@qizhang you need `GetBlockchainInfo()`
which returns
```// Contains information about the blockchain ledger such as height, current
// block hash, and previous block hash.
type BlockchainInfo struct {
Height uint64 `protobuf:"varint,1,opt,name=height" json:"height,omitempty"`
CurrentBlockHash []byte `protobuf:"bytes,2,opt,name=currentBlockHash,proto3" json:"currentBlockHash,omitempty"`
PreviousBlockHash []byte `protobuf:"bytes,3,opt,name=previousBlockHash,proto3" json:"previousBlockHash,omitempty"`
}
```
so height is the number of blocks in the ledger
in QSCC there is `GetChainInfo` which will return marshaled `BlockchainInfo` structure
Has joined the channel.
Has joined the channel.
For CouchDb how can we set up or configuration to give our testers / l3 support read onlly access to the key value pairs in the couchdb ? The only thing I've see so far is a recommendation not to couchdb outside the docker swarm. This would cut off any access even to or L3 / operators.
Has joined the channel.
@rsherwood There is no out of the box support for such authorization rules. You would need to setup peer to utilize an admin user for interacting with CouchDB, create regular users for read/write access per database, and then add a validation function via design doc to each database specifying that regular users cannot create/update documents.
For more details see https://stackoverflow.com/questions/10713437/couchdb-wide-read-only-access-rights
Message Attachments
The "prevBlock.Header.Number = 1" and "blockChainInfo.Height = 2", but then the code blocked at iter.Next(). Any suggestion? Thanks!
The above problem can be solved by adding more blocks to the chain. But I am still not clear about why the above code can be blocked when there are only 2 blocks in the chain. Any comment will be appreciated :-)
What is the function that a peer uses the get a missing block from other peers?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=wbER5NwMa8d3xcx7X) @qizhang Whenever gossip receives a block, it checks the current ledger height and received block number. If there is a mismatch, it initiates state transfer (to fetch all missing blocks). For more details, you can ask in #fabric-gossip channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ofbWjNt43sawX4rD4) @qizhang The basic behaviour of this iterator is such that it keeps iterating till the blocks are available. After exhausting the currently available blocks, it blocks till the next block is committed (in your program, in a separate gorouting, you can submit new trans to play around if you like). However, you can close the iterator anytime in your program.
Thanks @Senthil1 @manish-sethi
Has left the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Af2rpEjHvQ8cv5h8u) @dave.enyeart Thanks for your answer Dave. You said "You would need to setup peer to utilize an admin user for interacting with CouchDB". What sort of user does a peer use by default ? I had assumed it would need to be a "system admin" user as its required to created databases is that correct ?
Has left the channel.
Has left the channel.
@rsherwood That's correct, the peer user needs to be a system admin. Out of the box there is no user setup in CouchDB. You can set the admin user/password in the couchdb container and the matching user/password in the peer container. See example of setting these via docker-compose environment variables here: https://gerrit.hyperledger.org/r/#/c/11905/1/first-network/docker-compose-couch.yaml
Has joined the channel.
The readthedocs says "e. log.retention.ms = -1. Until the ordering service adds support for pruning of the Kafka logs, you should disable time-based retention and prevent segments from expiring. (Size-based retention – see log.retention.bytes – is disabled by default in Kafka at the time of this writing, so there’s no need to set it explicitly.)" . Can I please check is this the case in the current ledger that the Order expects that kafka maintains a full set of messages.
Is it safe to backup a ledger while it is being written to on Linux? Can we be assured that the Fabric will ensure that an entire fabric block is always going to be available, or is there any possibility that the backup manages to backup only half of the last fabric block if the fabric spanned multiple disk blocks. Alternatively would Fabric recognize a partial last block and be able to recover despite this.
One last question I hope. For the fabric supplied kafka and zookeeper nodes are the container mount points that need to be made persistent /kafka/logs and /var/zookeeper respectively ?
@rsherwood Please ask the orderer/kafka questions over on #fabric-consensus
Concerning the ledger backup, the block storage files can be backed up while peer is up. Data is written a block at a time. There is indeed recovery logic that ensures ledger is consistent when peer comes up, and before making ledger available for transaction processing.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=sXFgERFSgCBhw4yZc) @dave.enyeart Thanks Dave, when backing up a running system, does it matter if the couchDB is backed up before the ledger, or would it be safer to do the reverse. Ie on startup will a fabric peer cope with the couchdb being at an earlier state than the ledger , without just throwing away the couchdb and replaying everything, or is it reverse better ?
@rsherwood You can do it either way. Upon peer startup recovery code will detect if state database (leveldb or couchdb) is empty or behind in block number. If so, it will replay blocks to bring the state database up to the current block number, before making the peer available for new transactions.
Hi, is the "PayloadsBuffer" a peer local buffer that stores the blocks before committing them to the ledger? Do these blocks include those received from either the orderer or the other peers? Thanks!
Hi, is the "PayloadsBuffer" a peer local buffer that stores the blocks before committing them to the ledger? Do these blocks include those received from either the orderer or the other peers? Thanks!
Has joined the channel.
Hi, is there any error conditions whereby a fabric peer decides to rebuild the couchdb to ensure consistency. In this case I assume that any changes added to the schema manually (such as adding read only users and validation functions) would be lost is this correct ?
@rsherwood There are no conditions that cause automatic rebuild of state database. If there is a problem with state database, then the administrator could manually drop the state database and upon next peer start the content of the state database would be rebuilt by automatically replaying the block content.
@qizhang "PayloadsBuffer" is a gossip artifact, I've re-posted your question in #fabric-gossip
the data structure ResultsIterator QueryResult occur repeat
?
@chenxuan Please provide context and your full question
ok
i see the fabric source code
when i see the ledger
i find the folder common/ledger and core/ledger
in the common/ledger/ledger_interface file
it define the ResultsIterator
and QueryResult
but when i see the core/ledger/kvledger/txmgmt/statedb/statedb file
it define the ResultsIterator and QueryResult
too
@manish-sethi Would it make sense for the statedb to reference common/ledger ResultsIterator and QueryResult rather than re-define it's own?
@manish-sethi Would it make sense for statedb to reference common/ledger ResultsIterator and QueryResult rather than re-define it's own?
Yes, we should be able to reuse the `ResultsIterator` and `QueryResult` from common/ledger package.
@manish-sethi and would you recommend it?
Yes, I think that it would improve the code readability.
@chenxuan Feel free to submit a changeset with the enhancement
i think it's a simple problem so i mention at here
not new a issue in the jira
i have a another question
i see the ledger
use the leveldb to store the history
it will support the couchdb
later
？
@chenxuan In Fabric v1.0 you have a choice of using leveldb (default embedded) or couchdb (queryable external db) for state database. More details at https://hyperledger-fabric.readthedocs.io/en/latest/ledger.html
@chenxuan In Fabric v1.0 you have a choice of using leveldb (default embedded db) or couchdb (queryable external db) for state database. More details at https://hyperledger-fabric.readthedocs.io/en/latest/ledger.html
@dave.enyeart thx
another question is the performance
i see the test just the function
or aim to the performance
not aim to the performance
so i wonder weather the performance test come in the v1.1?
my english is bad so i only use the simple word to express my mind
There is performance test in progress. We do know that leveldb is faster than couchdb and are working to improve performance using couchdb in 1.1 timeframe
@chenxuan There is performance test in progress. We do know that leveldb is faster than couchdb and are working to improve performance using couchdb in 1.1 timeframe
@dave.enyeart i know the ledger provide the leveldb/couchdb to user but for history it provider only leveldb
type HistoryDBProvider struct {
dbProvider *leveldbhelper.Provider
}
as you see the dbProvider *leveldbhelper.Provier is infrastructure to operate the leveldb
@chenxuan That's correct, the only API available for history is GetHistoryForKey() which is well supported by embedded leveldb
the lockbased_query_executer which locate at fabric/core/ledger/kvledger/txmgmt/txmgr/lockbasedtxmgr folder should rename to lockbased_query_executor.go
just a advise
Has joined the channel.
If you have multiple chaincode installed and instantiated on the same channel. The data stored by one chaincode, it is not accessible to other chaincode right. Also if you upgrade the chaincode, can you still access the data persisted in the world state by the old chaincode.
Also can you say...because we support multiple channels..that we have multiple chains. So it almost single chain per channel. Even if you have multiple chaincode on the same channel.
@gauthampamu Only using chaincode calling chaincode functionality, one chaincode can read other chaincode's data (no updates allowed though via c2c). You can refer to `InvokeChaincode()` shim API.
Yes, even if we upgrade the chaincode, it can access the already persisted data. When a chaincode write a
@gauthampamu Only using chaincode calling chaincode functionality, one chaincode can read other chaincode's data (no updates allowed though). You can refer to `InvokeChaincode()` shim API.
Yes, even if we upgrade the chaincode, it can access the already persisted data. When a chaincode write a
@gauthampamu Only using chaincode calling chaincode functionality, one chaincode can read other chaincode's data (no updates allowed though). You can refer to `InvokeChaincode()` shim API -- https://github.com/hyperledger/fabric/blob/release/core/chaincode/shim/interfaces.go#L66.
Yes, even if we upgrade the chaincode, it can access the already persisted data. When a chaincode write a
@gauthampamu Only using chaincode calling chaincode functionality, one chaincode can read other chaincode's data (no updates allowed though). You can refer to `InvokeChaincode()` shim API -- https://github.com/hyperledger/fabric/blob/release/core/chaincode/shim/interfaces.go#L66.
Yes, the upgraded chaincode can access the already persisted data. When a chaincode write a
@gauthampamu Only using chaincode calling chaincode functionality, one chaincode can read other chaincode's data (no updates allowed though). You can refer to `InvokeChaincode()` shim API -- https://github.com/hyperledger/fabric/blob/release/core/chaincode/shim/interfaces.go#L66.
Yes, the upgraded chaincode can access the already persisted data. When a chaincode writes a
Thanks @Senthil1
Has joined the channel.
Has joined the channel.
How is the GetHistoryForKey() actually implemented ? is there an separate database maintained by the peer ?
@niteshsolanki There is a separate 'index' in leveldb that tracks the key changes and associates with the respective transactions that caused the key change. Then GetHistoryForKey() will query this index and pull out the actual data from the corresponding transaction in the chain
@niteshsolanki There is a separate 'index' in leveldb that tracks the key changes and associates with the respective transactions that caused the key change. Then GetHistoryForKey() will query this index and pull out the actual historical value from the corresponding transaction in the chain
Ohh.. @dave.enyeart So is this the feature built by fabric or leveldb maintain it inherently?
@niteshsolanki Fabric 'maintains' these indexes during transaction commit. It is not an inherit leveldb capability per se, but fabric utilizes leveldb key/value storage and range query capability to implement the 'index' and the associated queries
@niteshsolanki Fabric 'maintains' these indexes during transaction commit. It is not an inherit leveldb capability per se, but fabric utilizes leveldb key/value storage and range query capability to implement the historical 'index' and the associated queries
okay thanks @dave.enyeart . A quick question on upgrade chiacode. When a CC is upgraded with the new version does it creates a new Docker container as well image for that?How state migration actually happening behind the scenes?
yes, there will be a new container for the new chaincode version (but same chaincode id). no data migration is necessary, the peer maintains the state scoped to chaincode id, rather than id-version.
so when we say abt state of a CC, each container is running an instance of leveldb ? How is isolation property tied to it?
state data (leveldb) is maintained on peer container, not chaincode container. so chaincode1-v1 and chaincode1-v2 both access peer for the chaincode1 data
Ohh. So each channel will represent a database here?
yes, there is a logical database per channel
yes, there is a logical state database per channel
yes, there is a logical state database per channel/chaincode
the mapping of logical database to physical database is an implementation detail that varies across different database types
@dave.enyeart just noticed that for couchDB each channel will be a new database with each putState will be a new document into it. how is the mapping done wen using level DB?
Is it possible to delete a channel after it is create ? Is it not because we should not be deleting the channel ? Is it possible to remove a peer or organization from the channel so that they cannot get access it.
I have a question on upgrading chaincode. Lets say we have two peers that belong to different organization and both are on the same channel. Now if you installed the new chaincode on one peer but not on the other peer. Can still submit the upgrade transaction on the chaincode ? Will the upgrade chaincode fail because we did not install the new chaincode on all the endorsing peers.
https://chat.hyperledger.org/channel/fabric-gossip?msg=SbPmiF4D38MqtmvXo
Has joined the channel.
The peer should be the only thing that modifies state database. If you attempt to tamper with the data, it will be detected the next time that data is touched. For example if the tampered peer participates in endorsement with bad state data, the endorsement results will not match the endorsement results from other peers, the client will therefore detect the bad data and will remove that peer from the set of endorsement results. If a bad client attempts to submit the transaction with bad endorsement, that transaction will get invalidated regardless.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=DjrBStJG77ReqGzH5) @dave.enyeart ok...can any namespace/meta information be stored in couch db which are not part of the transactions?
Peer does store some meta information in state db along with the transactions, for example a savepoint that indicates the block height that the state data represents.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=4xGCLw7aZoNFYm68m) @dave.enyeart By namespace, I meant metadata wrt lets say, an organization, which would help in logically grouping the retrieved transaction. What exactly do we mean by state db? 1.0 supports MySQL as well right. Is this possible using that. If not, how to achieve this?
state db persists current state of all chaincode variables. there is not a 1:1 mapping of transactions to chaincode variables. if you want transaction history by submitting organization, that is certainly a reasonable requirement which could be addressed in the fabric by a new 'index' or 'metadata' as you say, but that would not be in state db per se, but rather in a new index alongside block storage. Feel free to open a Jira enhancement for that request.
for state db there are currently two supported options, embedded leveldb or couchdb.
these work well with the chaincode programming model since they are key/value or key/document database.
MySQL is not currently supported, and would require more fundamental changes if you wanted to leverage the relational structure
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
@dave.enyeart does the fabric wait untill all txs for a given block are validated before committing a block?
what happens if a tx is invalid? does it just get marked as invalid? but block still commited right?
@berserkr At the peers, there is a bitmap for each block that is used to mark invalid transactions. The block is committed regardless of how many of its transactions are valid or invalid.
Correct, the whole block is committed to the chain, there is a byte array that indicates which transactions were valid/invalid, and only the valid transactions are applied to state database.
Got it, thank you!
can anyone confirm that stub.getTimestamp() can be used to retrieve a timestamp and can be used to set a field like 'updatedAt' for the data model?
I understand that time.Now() should not be used in chaincode since that may cause non-deterministic behaviour.
sorry for the typo. The actual method is like this: stub.GetTxTimestamp()
Has joined the channel.
@lenin.mehedy your understanding about not using time.Now() is correct, and your understanding about stub.GetTxTimestamp() is also correct- GetTxTimestamp() will return the time the transaction was created and will be the same value at all endorsing peers.
Thanks @silliman :)
I have a few doubts...1. does 1.0 provide a way to find out which transactions failed in consensus or did not meet endorsement policy? 2. If a set of transactions fail due to network issues, is there a mechanism to retry them?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=78jyFZcLX53qEpP3D) @dave.enyeart Thanks. I did raise a jira enhancement for this request. `https://jira.hyperledger.org/browse/FAB-5703` I have a few doubts...1. does 1.0 provide a way to find out which transactions failed in consensus or did not meet endorsement policy? 2. If a set of transactions fail due to network issues, is there a mechanism to retry them?
@MeenakshiSingh yes the client can be notified if transactions fail and can retry those transactions. Post to #fabric-sdk-node or #fabric-sdk-java to understand the exact mechanics, depending on the client sdk you'd like to use.
@dave.enyeart can you explain the the doc statedb_savepoint
when i use the couchdb
to store the ledger data
and wrapper the data
?
what's the propose
?
@chenxuan it is an internal impl detail... consumers dont need to understand it. it essentially tells us what the latest block was that processed successfully in state database. it is used upon recovery to ensure block storage and state database are in sync.
ok
i see the peer node start
process
when a peer start
it execute ledgermgmt.Initialize()
and provider
and provide the grpc service
like eventhub server
adminserver
endorser server
take a example
the adminserver let me the peer status
i can use the peer status
to know the peer status
i also want to communicate with the endorser server
use the cli
but i found nothing
that means the sdk (java,node) must impl the client ?
@dave.enyeart do you know of any examples that do chaincode invokation within chaincode? for those scenarios, is the endorser policy checked for botch chaincodes or just the main chaincode doing the execution?
example04 and example05 demonstrate invokeChaincode(): https://github.com/hyperledger/fabric/tree/release/examples/chaincode/go
Endorsement policy is only checked for the main chaincode. It is assumed the chaincode author is aware of chaincode calling chaincode and models endorsement policy accordingly.
got it, thank you!
Has joined the channel.
Has joined the channel.
@dave.enyeart Hello Dave .. quick question. Is there a plan to have chaincode APIs to create views on couchDB
we want to optimize queries and felt that Views provide the more optimal solution
This is Mohan
@movee2005 Hi Mohan, CouchDB index support for rich query find API is currently tagged for Fabric 1.1 (https://jira.hyperledger.org/browse/FAB-2877), while CouchDB custom view support is currently tagged for Fabric 1.2 (https://jira.hyperledger.org/browse/FAB-5528). Of course, the tags are not commitments and community support is required. I'd invite anyone to vote for and make use case comments on the respective jira items.
Has joined the channel.
How can find which user has initiated a change to the ledger?
Has joined the channel.
Hey guys :) I've got a question / problem.... I try to init a peer container with an couchdb. This works fine, but I want to add admin credentials for the couchdb. I set environment variables for both containers, but the peer doesn't connect to the couchdb? Can anyone help? Or I am in the wrong channel?
Has joined the channel.
@sampath06 assuming you are interested in who updated a certain key, you can do GetHistoryForKey() to find the transactions that updated the key. Then you can get those transactions and look into the 'creator' field.
@msandig You can see an example of how to enable couchdb and associated peer credentials here: https://gerrit.hyperledger.org/r/#/c/11905/
@dave.enyeart Thanks
Has joined the channel.
@dave.enyeart
1. We are planning to add authentication by adding user for couch-db access. My understanding the current default mode/setup is Admin Party. Is that we would require to create a server admin (not a database admin)?
2. I will have to update the plain-text password in the docker-composer file for peer service, have we used any approach (working on fabric seup) to encrypt this password in composer file?
3. Can we create user which only has read-access to couch, link on the internet suggest to use validate function, is this the only approach available?
1. You can see example of user credentials here: https://gerrit.hyperledger.org/r/#/c/11905/1/basic-network/docker-compose.yml
2. I believe you can use Docker secrets to encrypt passwords, although I haven't tried that myself.
3. Yes, to create a read-only user you would have to add a validate function
3. Yes, to create a read-only user you would have to add a validate function. You could do that yourself today. There is a future enhancement to make that available out of the box: https://jira.hyperledger.org/browse/FAB-1308
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=GWurDSy4yCsZ9d2WN) @dave.enyeart
I just your response (to almost same question). So setting the user variable in couch service (docker-composer) - will automatically provision Server Admin user?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=GWurDSy4yCsZ9d2WN) @dave.enyeart
I just saw your response (to almost same question). So setting the user variable in couch service (docker-composer) - will automatically provision Server Admin user?
yes, upon couchdb container creation it will utilize that username/password and turn off Admin Party
and peer will use the same username/password to connect
must be an admin username/password so that peer can create databases for new channels
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=zJwp95F2MRDopbGMt) @dave.enyeart
Thanks.
For read-only access, if we have to put ourself - a check would be like userCtx.Name == COUCHDB_USER in the validate function. There wouldn't be any new json element added explicitly to json document. Is this correct?
correct
@dave.enyeart - we have seen couch db file-system growing like for 50MB raw store, it consumed 1G space. We found that - a compaction needs to be run across databases (even for system databases). Limiting the document version count didn't help much post re-compaction.
Is this problem discussed in community or u have noticed it.?
@dave.enyeart - we have seen couch db file-system growing like for 50MB raw store, it consumed 1G space. We found that - a compaction needs to be run across databases (even for system databases). Limiting the document version count didn't help much post re-compaction.
Is this problem discussed in community or u noticed it?
yes, this is in our plan: https://jira.hyperledger.org/browse/FAB-5665
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=kZusCvf5zeTqiHkzp) @dave.enyeart
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=kZusCvf5zeTqiHkzp) @dave.enyeart
:), sure - i will add the above note for now.
any legwork you or others could do would help get it in quicker
share as much in the comments as you can please
Is there a method in SDK to query the transaction history of a specific user. Or is it limited to the data structures defined in the state DB. I am proxying this question for another user, but it has arisen a few times so I'm curious as well
@nickgaski That is not possible currently, but does sound reasonable. There is a Jira feature for it that people can add comments to and vote on: https://jira.hyperledger.org/browse/FAB-5703
Has joined the channel.
hi. What is the need for a file system based block store?
I see we are storing indexing information in leveldb
I am not able to understand the code in fabric/common/ledger/blkstorage
I was expecting the blocks to be stored in leveldb itself. it looks like we are storing some indexing information alone and not the actual blocks
@sansha the actual blocks are stored on the file system and some attributes about the blocks (and trans) are indexed
No, the actual blocks do not reside in the leveldb
Why can't we store them in leveldb itself?
The level db is just used as an index. You can delete this and it would be rebuilt on peer start
performance
The block chain by nature is an append only structure
The append operation on a file is the maximum write throughput you can get
You may like to read about write-amplification in kv-store
this helps. leveldb's write amplication is a performance bottleneck as I am understand
yes
thank you Manish. I will read about it
Sure, no problem.
is there any other reason other than performance? Like when a new node comes up, does storing in file system offer any advantages?
like for example, node synchronisation
Is there some documentation that explains the ledger architecture design?
Though the performance was the initial consideration but yes it may offer additional flexibility if we want to perform state transfer using just the files
No, unfortunately documentation does not cover lower level design decisions ...
thank you Manish
Sure, no problems
Why are there two ledger directories? I see one in common/ledger and core/ledger?
Common/ledger is used across both orderer (for storing blocks on the orderer machine) and peer (for storing blocks on a peer)
core/ledger contains additional ledger code that is required only on the peer
You may like to have a look at the ledger_interface.go in core/ledger... The peerledger interface extends from the commonledger
thank you
will take a look
@here - Hi people. I have been trying hard to put data in couch db and viewing them in Fauxton GUI. I managed to put them using my go CC but I am unable to see any data inside "data" field inside my document. I have tried the marbles_02 example and running that shows data using the Fauxton GUI. Any ideas where I might be going wrong. (I have tried with raw as well as Json documents, but no success till now) :(
@ArnabChatterjee please don't spam the channel with at-here unless it is a channel announcement
okay.
Assuming your marbles02 JSON data is visible in Couch UI, but not your own chaincode's, then most likely your chaincode is not producing valid JSON. Valid JSON will be stored in CouchDB as JSON, anything else will be stored in CouchDB as an 'attachment'
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Yg2ZN8mWZEmJLnAXL) @dave.enyeart Thanks. I was trying to have a look at my JSON by using ChaincodeLogger Interface as well as fmt.Println but unable to find them in the logs. I hardly could find them in docker logs of CC container/peer container.
In marbles02 fmt.Println() is used for logging. The log statements appear in the chaincode container docker logs, rather than the peer docker logs.
Here is the function that is used to determine if your bytes are JSON or not. You could do same thing in your chaincode to test the bytes.
https://github.com/hyperledger/fabric/blob/release/core/ledger/util/couchdb/couchdb.go#L1393
Thanks dave. I finally figured it out. I wasn't using init caps for my fields inside my struct. Silly me. :) Thanks again. :)
Has joined the channel.
Hi New to block chain
trying to explore IBM blumix
https://composer-playground.mybluemix.net/test
could not get much on the coding
any tutorial / guide
I could not able to relate which what I studied
just wanted to understand how the Architecture defined on Distributed system
@mdnoorishah this is a channel for a fabric component (Ledger). A more suitable place would be #fabric or #fabric-questions channel
@mdnoorishah this is a channel for a fabric component (Ledger). A more suitable place for your questiomns would be #fabric or #fabric-questions channel
@mdnoorishah this is a channel for a fabric component (Ledger). A more suitable place for your questions would be #fabric or #fabric-questions channel
Has left the channel.
@AdnanC can you explain the difference between the orderer ledger and peer ledger
?
@chenxuan They both store the blocks that orderer cuts on the file system. The peer ledger has some additional indexes to support peer queries into the block storage (e.g. GetTransactionById), as well as the state database of current key values to support chaincode.
@chenxuan They both store the blocks that orderer cuts on the file system, this code is common between orderer and peer. The peer ledger has some additional indexes to support peer queries into the block storage (e.g. GetTransactionById), as well as the state database of current key values to support chaincode.
@dave.enyeart in the production env we should mount the /var/hyperledger/production folder in the master host
in avoid the data is lose
@jyellick how can i to view a struct in a json format like block,envelope,payload
Has joined the channel.
@chenxuan yes, for more about docker data persistence to host see: https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence
If you want to see the block data in json format I suggest you utilize node SDK, see https://fabric-sdk-node.github.io/
thx @dave.enyeart
because the fabric provide many different data structure
so i want to see the content in the data structure
@jyellick provide the configtxlator tool to view the content
but i want to see the content in the anyway
because i could debug the orderer/peer
@dave.enyeart in the fabric v1.0.2 the limit/skip seems still doesn't work i see the query_wrapper.go file
//Add limit
jsonQueryMap[jsonQueryLimit] = queryLimit
//Add skip
jsonQueryMap[jsonQuerySkip] = querySkip
so i modify to
if _, ok := jsonQueryMap[jsonQueryLimit]; !ok {
//Add limit
jsonQueryMap[jsonQueryLimit] = queryLimit
}
if _, ok := jsonQueryMap[jsonQuerySkip]; !ok {
//Add skip
jsonQueryMap[jsonQuerySkip] = querySkip
}
@chenxuan You can do that as a short-term workaround, but we will not put that into Fabric as we don't want an individual chaincode to request millions of records from couchdb, exceeding the queryLimit threshold that the administrator has configured in peer (default 10000). The real solution will come with FAB-2809 where we introduce paging between peer and couchdb so that large number of documents can be supported.
@chenxuan You can do that as a short-term workaround, but we will not put that into Fabric as we don't want an individual chaincode to request millions of records from couchdb, exceeding the safe queryLimit threshold that the administrator has configured in peer (default 10000). The real solution will come with FAB-2809 where we introduce paging between peer and couchdb so that large number of documents can be supported.
@dave.enyeart ok
@dave.enyeart hi, FAB-3884 this is the similar problem relate to this, would it be solved? it's been a long time....
@kelvinzhong It is not in 1.1 plan, although if somebody from community wants to help implement that would be nice
@jyellick i debug the orderer module i find the genesisBlock = provisional.New(genesisconfig.Load(conf.General.GenesisProfile)).GenesisBlock() is hard to understand because it produce the configtx
can you explain the
type bootstrapper struct {
channelGroups []*cb.ConfigGroup
ordererGroups []*cb.ConfigGroup
applicationGroups []*cb.ConfigGroup
consortiumsGroups []*cb.ConfigGroup
}
there are no comment
@chenxuan try to go through this first http://hyperledger-fabric.readthedocs.io/en/latest/configtx.html
Has joined the channel.
Has joined the channel.
Hi! I have created custom network with 1 ordered and 2 organizations and each organization has 2 peers. Then I have created channel and succesfully joined all peers to that channel. Next I have installed chaincode on peer0.org1 and succesfully instantiate it and invoke functions. But when I try to call invoke function on any other peer I get error message:
Hi! I have created custom network with 1 ordered and 2 organizations and each organization has 2 peers. Then I have created channel and succesfully joined all peers to that channel. Next I have installed chaincode on peer0.org1 and succesfully instantiate it and invoke functions. But when I try to call invoke function on any other peer I get error message:
'''
Error: Error endorsing invoke: rpc error: code = Unknown desc = cannot retrieve package for chaincode
'''
Hi! I have created custom network with 1 ordered and 2 organizations and each organization has 2 peers. Then I have created channel and succesfully joined all peers to that channel. Next I have installed chaincode on peer0.org1 and succesfully instantiate it and invoke functions. But when I try to call invoke function on any other peer I get error message:
Error: Error endorsing invoke: rpc error: code = Unknown desc = cannot retrieve package for chaincode
@kustrun you need to install that chaincode on the other peer too
So if I want to run chaincode on every peer I have to install it on every node manually?[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=kyZSqDPWW936o4f52) @Vadim
yes
Is there no mechanism like in Ethereum where you deploy Smart Contract once and use it everywhere?[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=BN8rzKaSWccYjAxJf) @Vadim
you need to install it manually, that was done deliberately, read https://jira.hyperledger.org/browse/FAB-2859
mainly, it's `The new installation model provides the opportunity to properly associate ownership of chaincodes as part of the “install” of the chaincode. `
Thanks!
Hi everyone, is the ledger stored in Leveldb or filesystem?
Hi everyone, since for each
Hi everyone, since for each
@qizhang they are both in the blocks (inside the RWsets of the transctions), and maintained in a history database kept in LevelDB
@toddinpal so the blocks are stored in the LevelDB, not file system?
no, the blocks are stored in the file system. There is a separate LevelDB database that maintains the history, just like there is an index database maintained in LevelDB that tracks where transactions are located in those blocks (along with other information in the index database)
Has joined the channel.
All, I have a design question: 1) In most of the use cases, the participants of the network will have data which they would really like to keep confidential (for e.g. how much amount one invested) among select few peers.I understand channel is an option for peers to transact privately. But does that mean for all practical purposes, we will end up with multiple channels irrespective of how big or small a usecase is and then on the application side( front end) we will have to orchestrate to get data from all the channels and present to the user based on access level? 2) is there a mechanism to control access level for a peer on a channel so as it could access only specific data? Please help
@Vrai1127 Various privacy enhancements are in progress, please take a look: https://jira.hyperledger.org/browse/FAB-3621
https://jira.hyperledger.org/browse/FAB-4207
https://jira.hyperledger.org/browse/FAB-1151
https://jira.hyperledger.org/browse/FAB-5481
https://jira.hyperledger.org/browse/FAB-5695
@qizhang @toddinpal To clarify one thing... the past key values are embedded in the transactions that wrote them, persisted in the block store on file system. In LevelDB there are various indexes into block storage to support various query APIs, including the history index which indicates for a given key which block/tran contains the historical written value. The historical value is not persisted in this LevelDB index, it's just a pointer to the block/tran to support the GetHistoryForKey() API, which will retrieve the historical values from the respective blocks/trans when called, as well as return the tran id, so that your client can retrieve the tran by id in case it wants the full details of the transactions that wrote the historical values.
@qizhang @toddinpal To clarify one thing... the past key values are embedded in the transactions that wrote them, persisted in the block store on file system. In LevelDB there are various indexes into block storage to support various query APIs, including the history index which indicates for a given key which block/tran contains the historical written value. The historical value is not persisted in this LevelDB index, it's just a pointer to the block/tran to support the GetHistoryForKey() API, which will retrieve the historical values from the respective blocks/trans when called, as well as return the tran ids, so that your client can retrieve the trans by id in case it wants the full details of the transactions that wrote the historical values.
yeah, I guess I wasn't all that clear...
@dave.enyeart I see, so the LevelDB only stores index, the block data is still in file system.
Correct. In addition to the block data on file system and LevelDB indexes into block storage, there is also the state database, which utilizes (a different) LevelDB or CouchDB database. The state database contains the latest values of all chaincode variables - think of it as persisted state for the chaincode.
Hi! I have a cluster with docker swarm - on one computer I have 1 orderer node and 1 peer, on other computer I have 1 peer. If I instantiate chaincode on computer with 1 peer everything works prefectly, when I try to instantiate it with peer and orderer on the same computer I get following error: `Error: Error endorsing chaincode: rpc error: code = Unknown desc = Timeout expired while starting chaincode` Help please
Hi! I have a cluster with docker swarm - on one computer I have 1 orderer node and 1 peer, on other computer I have 1 peer. If I instantiate chaincode on computer with 1 peer everything works prefectly, when I try to instantiate it with peer and orderer on the same computer I get following error: `Error: Error endorsing chaincode: rpc error: code = Unknown desc = Timeout expired while starting chaincode` Anyone got the same error?
@dave.enyeart Since the blocks are stored in the file system of the containers, will that goes away when the container shutdown?
@dave.enyeart Since the blocks are stored in the file system of the containers, will that go away when the container shutdown?
@qizhang yes
@qizhang Well that depends... If the container's portion of the file system containing the LevelDB databases is mapped to the host's file system via a volume, then it will persist as long as the host's file system persists.
Ooops, make that the blocks, although the same is true for LevelDB files as well.
Yes, I agree.
Yes, I agree. @toddinpal @asaningmaxchain
@toddinpal but if i want to start the fabric ,it will fail
@asaningmaxchain not sure I'm following
you can try it
it will report the ledger data has exists
What will report that? A peer? I've done this, so I'm not sure what you're referring to
wait a moment
i try it and show you the error
volumes:
- /var/hyperledger/peer0:/var/hyperledger/production
@toddinpal ok
?
for each peer and orderer and i use the e2e for example
Are you using the same volume mapping for each peer? Each peer needs to map to a different part of the hosts file system
i show you my config
wait a moment
- /var/hyperledger/peer0.org1:/var/hyperledger/production
the peer0.org1.example.com
- /var/hyperledger/peer1.org1:/var/hyperledger/production
the peer1.org1.example.com
it's ok
?
Message Attachments
as you see all the data locate my host
that looks right... what error are you getting?
Message Attachments
So I'm not following exactly the sequence of what you're doing... I would expect you're starting the e2e example with the mapped volumes. Then stop the containers, and then start the containers and see that the network is still there.
my mistake
my mistake @toddinpal
it's ok
ok, good to hear.
Has joined the channel.
Hi all. Can you please tell me how we can configure multiple orderer peers across multiple organizations?
Has joined the channel.
@ArnabChatterjee AFAIK you can only do that if you share a common Kafka cluster. Is that really what you want?
@toddinpal - yes. Can you please let me know the details of the implementation? Thanks.
@ArnabChatterjee Have you looked at how the Kafka based ordering service is configured? https://hyperledger-fabric.readthedocs.io/en/latest/kafka.html
checkout the orderer.yaml file in the source repository under .../fabric/examples/cluster/config
Thanks @toddinpal . :) I will check.
Hi All,
Are the peers fault tolerant in Fabric Network? That means, If any peer node crashes, does the App go down or does it use other peers to continue transactions? I am using balance transfer example and to test the scenario, I have stopped the docker container of a peer from org1 and I got an error in the Node SDK logs.
`error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: Connect Failed
at /home/ubuntu/go/src/sdk/node_modules/grpc/src/node/src/client.js:434:17
[2017-08-29 06:25:39.431] [ERROR] invoke-chaincode - transaction proposal was bad
[2017-08-29 06:25:39.432] [ERROR] invoke-chaincode - transaction proposal was bad
[2017-08-29 06:25:39.432] [ERROR] invoke-chaincode - Failed to send Proposal or receive valid response. Response null or status is not 200. exiting...
[2017-08-29 06:25:39.432] [ERROR] invoke-chaincode - Failed to order the transaction. Error code: undefined
[2017-08-29 06:25:39.432] [DEBUG] Helper - [FileKeyValueStore.js]: FileKeyValueStore.js - constructor`
@toddinpal when i add the volumes:
- /var/hyperledger/couchdb0:/opt/couchdb/data
@toddinpal when i add the ```volumes:
- /var/hyperledger/couchdb0:/opt/couchdb/data``` for each couchdb
the couchdb doesn't start up successfully
```[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,couch,{{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,auth_cache,{{badmatch,{error,eacces}},[{couch_auth_cache,ensure_users_db_exists,2,[{file,\"src/couch_auth_cache.erl\"},{line,456}]},{couch_auth_cache,open_auth_db,0,[{file,\"src/couch_auth_cache.erl\"},{line,428}]},{couch_auth_cache,reinit_cache,1,[{file,\"src/couch_auth_cache.erl\"},{line,290}]},{couch_auth_cache,init,1,[{file,\"src/couch_auth_cache.erl\"},{line,166}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,240}]}]}}}}},{couch_app,start,[normal,[]]}}}"}
```
@asaningmaxchain Please see Jira issue about permission issue: https://jira.hyperledger.org/browse/FAB-4905
@ArnabChatterjee The app client needs to talk to multiple peers to get multiple endorsements and ensure fault tolerance if a peer goes down. For questions on how to do this in a node js app please post to #fabric-sdk-node
chown -R couchdb:couchdb /opt/couchdb
in the host
@dave.enyeart that means i should modify the /opt/couchdb permission to couchdb:couchdb
?
@dave.enyeart Thanks. Actually I cannot access FAB-4905. I require a login for that.
Hi All,
I was going through the link: https://hyperledger-fabric.readthedocs.io/en/latest/msp.html#msp-setup-on-the-peer-orderer-side and really having a hard time understanding the role of each type of certificates that are used in here. Can anyone provide any simpler explanation about MSP and certificates?
Is there any kind of diagram that depicts the whole flow of the fabric operations using the different certificates?
Hi,
We are using configtxgen version 1.0.1 to generate the channel.tx file. On trying to create a channel, we get the following error message:
It would be great if someone can help to let us know what’s going on behind the scenes.
/Channel/Application/Org2MSP
orderer.example.com | 2017-08-30 04:30:02.689 UTC [common/configtx] addToMap -> DEBU 1a3 Adding to config map: [Policy] /Channel/Application/Admins
orderer.example.com | 2017-08-30 04:30:02.689 UTC [common/configtx] addToMap -> DEBU 1a4 Adding to config map: [Policy] /Channel/Application/Writers
orderer.example.com | 2017-08-30 04:30:02.689 UTC [common/configtx] addToMap -> DEBU 1a5 Adding to config map: [Policy] /Channel/Application/Readers
orderer.example.com | 2017-08-30 04:30:02.689 UTC [common/configtx] addToMap -> DEBU 1a6 Adding to config map: [Values] /Channel/Consortium
orderer.example.com | 2017-08-30 04:30:02.690 UTC [orderer/common/broadcast] Handle -> WARN 1a7 Rejecting CONFIG_UPDATE because: Error authorizing update: Error validating DeltaSet: invalid mod_policy for element [Policy] /Channel/Application/Writers: mod_policy not set
orderer.example.com | 2017-08-30 04:30:02.691 UTC [orderer/main] func1 -> DEBU 1a8 Closing Broadcast stream
that mean you don't have right to modify the config
Has joined the channel.
In Fabric source code, which function is used by the peer to commit a block to its ledger?
A peer will send out an event to the event hub after it commits a block, can anyone tell me which function in the Fabric source code sends such an event? Thanks!
in the folder events
Thanks, but can you be more specific?
the peer provide the event grpc service
when the peer start
you can take a look the peer/node/start
you will get more information
OK, thanks!
If I change something in Fabric/events/consumer/consumer.go, which container shall I rebuild to let my change take effect?
you can use the make docker to build the new images
Has joined the channel.
Hi...I am using binary implementation to start the peers in my fabric network. I want to configure couch db as state database. The documentation only specifies updating `CORE_LEDGER_STATE_STATEDATABASE=CouchDB` as an env variable or in core.yaml. Upon doing this I am not able to configure couch db and I am getting the error in the attached screenshot. I suppose couchdb is not packaged with fabric binaries, how should this be achieved?
Message Attachments
do you start the couchdb?
you can use the docker to start the couchdb
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=8EmnLTLukj4YwH9xY) @asaningmaxchain How to do that?
https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#using-couchdb shows an example of configuring and starting couchdb container in your docker enivornment
Has joined the channel.
https://chat.hyperledger.org/channel/fabric-ca?msg=mgWJZsikmdbTTrtzK - @ArnabChatterjee , see if this post from Keith helps. I'm happy to help you with this though. We really should add some more content to the docs. The important pieces are really the Admin certs, TLS certs and signing certs
Who can help explain what the directories under /var/hyperledger/production/ledgersData on peer are used for? i know they are are leveldb files used for block storage. i want to know more about the database organisation on peer. why are there directories historyLeveldb ledgerProvider stateLeveldb besides chains?
@Glen Content of
@Glen Content of
@dave.enyeart can you give some data about the performance about the couchdb read/write performance
@dave.enyeart can you give some data about the performance about the couchdb read/write
There are no published metrics, but tests have shown that couchdb is slower than leveldb, but not so much that it would slow down the overall system throughput.
can you provide some data to support
Especially true after couchdb performance improvements planned for 1.1
There is testing underway to get actual performance data. The studies so far have focused on bottleneck identification
but the leveldb doesn't support the complex query
correct, complex query is the primary reason people would want to use couchdb
but the couchdb can't get count of the data
what do you mean by count?
aggregate queries?
the sum of the data
there is intent to add support for couchdb views for this, see https://jira.hyperledger.org/browse/FAB-5528
plan to support map/reduce
?
yes, any couchdb view could be created, including map/reduce
ok
thx
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=2cDKzroAkRd9HpoH9) @dave.enyeart ok thanks
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=2cDKzroAkRd9HpoH9) @dave.enyeart
one more question, as i find different chains use the same DB instance to write to leveldb, will leveldb do the isolation for us or we write the data to different tables, I'm not sure leveldb has a similar concept like RDB
Provider enables to use a single leveldb as multiple logical leveldbs
type Provider struct {
db *DB
dbHandles map[string]*DBHandle
mux sync.Mutex
}
Ok i got it, different chains make different ledger directories
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hi everyone
I need help adding new user in HL fabric
I am new to hyperledger
Has left the channel.
is there resource/document/example on how ot write unit test for Rich Query in side HLF?
Has joined the channel.
Is this indicative of running out of disk space?
```2017-09-09 20:48:56.938 UTC [fsblkstorage] nextBlockBytesAndPlacementInfo -> DEBU 25ee At least [13482] bytes expected. Remaining bytes = [2]. Returning with error [unexpected end of blockfile]
2017-09-09 20:48:56.939 UTC [fsblkstorage] nextBlockBytesAndPlacementInfo -> DEBU 25f0 current file [0] length of blockbytes [0]. Err:unexpected end of blockfile```
@kostas yes, from the code, the expected length block size and length exceeds the remaining length of the block file will get this error
ErrUnexpectedEndOfBlockfile error used to indicate an unexpected end of a file segment
this can happen mainly if a crash occurs during appening a block and partial block contents
get written towards the end of the file
@Glen: Based on your description it sounds as if this may _not_ be indicative of running out of disk space. Rather it can be an issue of not closing the file properly. Am I misinterpreting this?
(@manish-sethi @dave.enyeart Thoughts?)
@kostas yes, The most likely cause of this could have been a crash during writing to a block file.
However, on next peer start (at the time of ledger open), the partial written block is expected to be cleaned up and the ledger is expected to behave as if the last block was never written.
Does this matches with what you observe in addition to above logs? If not then - can you paste more logs around these logs and any additional info about the behavior that you see...
@manish-sethi: Gotcha. This (versus the disk filling up) is a reasonable explanation for what is probably happening - I see threads exiting abruptly. Thanks for letting me know.
Has joined the channel.
How deep can the world state db go in terms of transactions stored? And can we get all the versions/different values of the keys from couch db.
Has joined the channel.
Has left the channel.
Hello @MeenakshiSingh - everything is stored, from the "genesis" block.
Yes, you can retrieve it all.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=fLNfSnLYEoE2i3byn) @JonathanLevi How would we retrieve it all. Also, is it possible to do a selective retrieval of the data?
It's easier in CouchDB, but even with level db, this is the interface:
https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/interfaces.go
Hi...After initiating a couple of transactions on the chaincode, I modified and added/saved a couple of objects on the existing channel document using couchdb interface. I, then re-executed the invoke and query commands over the channel. I expected them to fail, as I manually altered the state db. However, the transactions are going through fine. Is this the expected behaviour?
I was reading that in V1.1 the concepts of private data and mixer identities are to be introduced. If I wanted to set up a single ledger on v1.1 where multiple parties trade between them does it allow for the data to be kept private between pairs of members but also the identity of transaction to be unlinkable? To do this the submitter , endorsers but also the "private data groups" (assuming that private data are shared between party pairs) would all have to be "unlikable" from the ledger.
Has joined the channel.
Has joined the channel.
@MeenakshiSingh Yes that's expected behavior. Data may get corrupted for a variety of reasons, which will cause endorsements on next transaction simulations to not be correct. The protection factor comes from a transaction requiring multiple matching endorsements. If the endorsement on your corrupted peer does not match the endorsements from the 'good' peers, then the transaction from the 'bad' peer will be invalidated. You need to get N matching endorsements for a transaction to get validated before the distributed ledger is updated, where N is based on the endorsement policy.
@dave.enyeart if i delete the ledger data which locate the peer,and then i query
what's the condition
If you delete state database, then upon peer start it will recognize that state database is behind block storage height and it will automatically rebuild state database based on block storage. The peer will not be initialized for invokes/queries until the state database is brought up to the block storage height. If you delete entire ledger data directory then you will need to rebuild peer, rejoin channels, and the block storage will be state transferred from another peer and state database rebuilt automatically.
@asaningmaxchain If you delete state database, then upon peer start it will recognize that state database is behind block storage height and it will automatically rebuild state database based on block storage. The peer will not be initialized for invokes/queries until the state database is brought up to the block storage height. If you delete entire ledger data directory then you will need to rebuild peer, rejoin channels, and the block storage will be state transferred from another peer and state database rebuilt automatically.
@dave.enyeart thx
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=mm3BWt8M3gqLQ6XiG) @dave.enyeart the state database is couchdb? if i use the couchdb to store the data,
Has joined the channel.
By default the state database is goleveldb. You can alternatively configure it to be couchdb.
If you delete entire ledger data directory then you will need to rebuild peer, rejoin channels, and the block storage will be state transferred from another peer and state database rebuilt automatically. i understand
but another i don't understand
if i delete the state database
if i delete the state database and then i make a query from the peer
you would get an error since the database would be unreachable
i can copy the state data from another peer to the peer
？
not recommended, better to let peer build it's state database from it's block storage to ensure the data is trusted
so restart the peer?
yes
so whatever i delete the state database or ledger data, if i want to recover,i should restart the peer,let the peer rebuild the data automatically
?
yes
ok,thx a lot
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=8yNdZijSoDPP9Ti7d) @dave.enyeart ok. so I have only 2 peers transacting on a channel and I have set the the EP as `“OR(‘Org1MSP.member’,’Org2MSP.member’)”`. So, if i corrupt the data at both the peers, would they be able to transact?
yes they would... if your endorsement policy only requires one endorsement then you open yourself to problems like this. You would never do that in a production system.
@FenglianXu Please review the thoughts around skip and limit described in this work item: https://jira.hyperledger.org/browse/FAB-2809
Hi Dave -- Have the following features been supported by Hyperledger Fabric yet? 1. SKIP 2. LIMIT 3. ORDER?
Hi everyone, are there multiple threads in a peer committing the blocks or there is just one? Thanks!
@dave.enyeart Hi, are there multiple threads in a peer committing the blocks or there is just one? Thanks!
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=MmMmTnrB6xgZZWWpn) @FenglianXu the orderer support,the skip and limit you should modify the source code and make docker to build the peer
If are using the CouchDB, how do you configure the couchdb database so that it writes the data to particular folder on the host machine.
If you look the sample configuration in the samples, they don't mount any directories
couchdb1:
container_name: couchdb1
image: hyperledger/fabric-couchdb
# Populate the COUCHDB_USER and COUCHDB_PASSWORD to set an admin user and password
# for CouchDB. This will prevent CouchDB from operating in an "Admin Party" mode.
environment:
- COUCHDB_USER=
- COUCHDB_PASSWORD=
# Comment/Uncomment the port mapping if you want to hide/expose the CouchDB service,
# for example map it to utilize Fauxton User Interface in dev environments.
ports:
- "6984:5984"
networks:
- byfn
@FenglianXu Please review the thoughts around skip and limit in this work item: https://jira.hyperledger.org/browse/FAB-2809
Would appreciate your feedback in that item's comments
@gauthampamu Please see: http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=38XNDQH3TYpGi4DR3) @dave.enyeart Thanks. I have read this before and I forgot about it. Thanks for sharing the link.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=nkRzdLjFHvhahKspi) @dave.enyeart Thanks. I have read this before and I forgot about it. Thanks for sharing the link.
@qizhang Block transactions are processed in serial by a thread (per channel). Based on recent performance bottleneck analysis, some aspects of committer validation will be shifting to multi-threaded to parallel process transactions which don't have dependencies...this will improve performance, especially in cases of a single channel where there were previously cycles available.
Thanks @dave.enyeart . You mean even if there are multiple peers, as long as they belong the same channel, their blocks are committed to the ledger by a single thread?
No, I mean for a given peer, there will one thread doing the block validation/commit work per channel. And going forward, multi-threading will be used even within a single channel for some of the areas where it makes the most sense.
@qizhang No, I mean for a given peer, there will one thread doing the block validation/commit work per channel. And going forward, multi-threading will be used even within a single channel for some of the areas where it makes the most sense.
@dave.enyeart I see. When multi-threading is used, does it mean that for a peer, a block can be committed before all its previous blocks have been committed?
No, blocks will continue to be committed in order. But within a block the N transactions could be validated in parallel, where there are not dependencies between them.
@dave.enyeart make sense. For each single block, what is the ratio of time spent on validating the transactions and writing the block to the ledger? I suspect the writing part could take longer time since it is doing disk I/O.
@dave.enyeart make sense. For each single block, what is the ratio between the time spent on validating the transactions and the time spent on writing the block to the ledger? I suspect the writing part could take longer time since it is doing disk I/O.
Actually the validation has been more expensive due to all the checks including checking signatures and checking consistent state since simulation time.
I see, do you think it is useful to measure the ratio between the time spent on validating the transactions and the time spent on writing the block to the ledger for each single block?
Yes, that is valuable, some people have already done it, I suggest you ping @Senthil1 for details.
Sure, will do. Thanks!
@dave.enyeart I was told there is a global lock that each peer uses to commit the block, do you know more details about it?
That is probably in reference to the RW lock that ensures that simulations see consistent results, that is, they don't see some data pre-commit and some data post-commit from other transactions. There are some thoughts on how to preserve the behavior in more efficient ways, you can ping manish-sethi for some specifics.
sure thanks!
Has joined the channel.
Hello team. I am using couchDB with Go chaincode and Node SDK. Is there any example where I can encrypt the data in the chaincode itself with public and private key encryption mechanism, so that it can only be read from the chaincode and not from the Fauxton UI? Thanks.
@dave.enyeart thank you for the link. When will the V1.2 be released?
@FenglianXu The rough timing is 1.1 for Q4, 1.2 for Q1. Could you add a comment in FAB-2809 about your use case and whether what's described would be sufficient for you?
@ArnabChatterjee There is an example of encrypting chaincode data here: https://gerrit.hyperledger.org/r/#/c/12811/
Note that couchdb query capability will be reduced if the data is encrypted.
Has left the channel.
Is there a way to do 'pagination' (satisfying query parameters) with the range query at the chaincode level? Say, I have 1000 records and I would like to retrieve 'page 2' (based on the query parameters) where each page may contain a maximum of 100 records.
Hey, In couchdb.. how do I build an index for a query that has an `"$or"` statement in it? Can I put the `"$or"` in the index? or do I just specify the fields normally?
I can't find much in the way of documentation for indexes in a Hyperledger context other than the comments in the marbles chaincode :/
@pd93 heres a good reference for how to build those selectors: http://docs.couchdb.org/en/2.0.0/api/database/find.html#find-selectors
and heres an example of the string in golang: `"{ \"selector\": { \"$or\": [ {\"status\": 0}, {\"status\": 1}, {\"status\": 2} ] } }"`
the statuses are of type int32
@jrosmith Thanks, but I already have the selector query with the or statements. My questions is how I build an *index* to speed this query up
ohhhh my mistake
np. Thanks anyway :P
Also curious whether the replication feature in Fauxton works? If I have a local chain and a remote chain.. can I use the replication tab to backup/restore data?
@dave.enyeart i use the PTE tools to test the performance,when i find the couchdb is slower then the level db
and the otherwise the query is very slow than the write
That's correct, leveldb in-process database is faster than the remote couchdb database option. This is most important in validation and commit phase, since that is where there are serial paths that can impact throughput. In latest master, enhancements have been made to perform validation and commit in bulk in couchdb. With these improvements, there may not be a noticeable difference for end to end transaction throughput.
@asaningmaxchain That's correct, leveldb in-process database is faster than the remote couchdb database option. This is most important in validation and commit phase, since that is where there are serial paths that can impact throughput. In latest master, enhancements have been made to perform validation and commit in bulk in couchdb. With these improvements, there may not be a noticeable difference for end to end transaction throughput.
@asaningmaxchain That's correct, leveldb in-process database is faster than the remote couchdb database option. This is most important in validation and commit phase, since that is where there are serial paths that can impact throughput. In latest master, enhancements have been made to perform validation and commit in bulk in couchdb. With these improvements, there may not be a noticeable difference for end to end transaction throughput between leveldb and couchdb.
so in the v1.1 the performance will get a good promotion
?
whatever the state db use couchdb/leveldb
?
Correct, in 1.1 the end-to-end throughput with couchdb should get closer to end-to-end throughput seen with leveldb.
i got it
@pd93 Each peer should have a dedicated couchdb that stays in sync with the peer's ledgers. Therefore you should not attempt CouchDB replication. State in CouchDB (or leveldb) is a shadow of the chain. State in CouchDB is rebuilt automatically to be in sync with chain, if upon peer restart the state database is not found or is found to be at lower height than the peer's chains. High Availability is achieved with multiple peers rather than multiple state database replicas. In this deployment scheme, replication is not needed.
Hi, I was writing chaincodes with Golang and couchdb. I am badly stuck in fetching data with nested queries or joins. Example: `select user.user_id from user where user.company_id in (select company.company_id where company.zipcode = "123456")`. I know this question does not belong here. But any help or pointers would be appreciated. Thank you all. :)
@dave.enyeart - Any clues dave? Thanks.
@dave.enyeart That's great thanks :) Makes sense. I was mainly curious from a backup point of view rather than availability.
I'm now trying to get data persistence to work though instead and I'm getting `eaccess` errors on the couchdb container.
All I've done is mounted the volumes for the peers and couchdb container like [the tutorials](http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence) say to.
Full error: ```
[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,couch,{{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,auth_cache,{{badmatch,{error,eacces}},[{couch_auth_cache,ensure_users_db_exists,2,[{file,\"src/couch_auth_cache.erl\"},{line,456}]},{couch_auth_cache,open_auth_db,0,[{file,\"src/couch_auth_cache.erl\"},{line,428}]},{couch_auth_cache,reinit_cache,1,[{file,\"src/couch_auth_cache.erl\"},{line,290}]},{couch_auth_cache,init,1,[{file,\"src/couch_auth_cache.erl\"},{line,166}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,240}]}]}}}}},{couch_app,start,[normal,[]]}}}"}
```
@dave.enyeart That's great thanks :) Makes sense. I was mainly curious from a backup point of view rather than availability.
I'm now trying to get data persistence to work though instead and I'm getting `eaccess` errors on the couchdb container.
All I've done is mounted the volumes for the peers and couchdb container like [the tutorials](http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence) say to.
Full error:
```[os_mon] memory supervisor port (memsup): Erlang has closed
[os_mon] cpu supervisor port (cpu_sup): Erlang has closed
{"Kernel pid terminated",application_controller,"{application_start_failure,couch,{{shutdown,{failed_to_start_child,couch_secondary_services,{shutdown,{failed_to_start_child,auth_cache,{{badmatch,{error,eacces}},[{couch_auth_cache,ensure_users_db_exists,2,[{file,\"src/couch_auth_cache.erl\"},{line,456}]},{couch_auth_cache,open_auth_db,0,[{file,\"src/couch_auth_cache.erl\"},{line,428}]},{couch_auth_cache,reinit_cache,1,[{file,\"src/couch_auth_cache.erl\"},{line,290}]},{couch_auth_cache,init,1,[{file,\"src/couch_auth_cache.erl\"},{line,166}]},{gen_server,init_it,6,[{file,\"gen_server.erl\"},{line,328}]},{proc_lib,init_p_do_apply,3,[{file,\"proc_lib.erl\"},{line,240}]}]}}}}},{couch_app,start,[normal,[]]}}}"}
```
@dave.enyeart That's great thanks :) Makes sense. I was mainly curious from a backup point of view rather than availability.
I'm now trying to get data persistence to work though instead and I'm getting `eaccess` errors on the couchdb container.
All I've done is mounted the volumes for the peers and couchdb container like [the tutorials](http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence) say to.
*--edit--:* Fixed the above issue by doing a `chown` on the persistence directory on my host (docker had set its ownership to `root` - hence couchdb couldn't write to it)
@dave.enyeart That's great thanks :) Makes sense. I was mainly curious from a backup point of view rather than availability.
I'm now trying to get data persistence to work though instead and I'm getting `eaccess` errors on the couchdb container.
All I've done is mounted the volumes for the peers and couchdb container like [the tutorials](http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence) say to.
*--edit--* Fixed the above issue by doing a `chown` on the persistence directory on my host (docker had set its ownership to `root` - hence couchdb couldn't write to it)
@ArnabChatterjee CouchDB does not support SQL. There is intent to support CouchDB views in the future, take a look at CouchDB map/reduce to see what is possible there. In the interim you would have to model your chaincode data in a way to directly support the queries, for example add the company zip code directly to a user key/value, and then you would be able to query users by zip code.
@dave.enyeart Thanks. Is map/reduce currently supported in the couchDB implementation inside Fabric?
There is intent to support CouchDB views in the future
No, there is intent to support CouchDB views in the future
okay. So, in a crude way to implement it, can I fetch the result of the 1st subquery as a string and pass it on to the main query?
There could be many results to the subquery and therefore that may not work well. Blockchain is not intended to be a traditional application database, the data should support the intent of the chaincode, in this case if there is legit reason to do that query in chaincode then I could model the company zip in the user key/value to directly support the query.
There could be many results to the subquery and therefore that may not work well. Blockchain is not intended to be a traditional application database, the data should support the intent of the chaincode, in this case if there is legit reason to do that query in chaincode then you could model the company zip in the user key/value to directly support the query.
Hi Folks,
I have created a blog for Emerging Technology for Beginners , Also i added the setting up for Hyperledger fabric V 0.6 and V 1.0 on that.
Kindly review and let me know your queries.
Blog name : kesavannb.wordpress.com
@dave.enyeart - thanks dave. But, I am still in doubt that for every such join requirement, I need to maintain separate mappings as key value pairs. Won't doing this incur extra overhead of maintaining these mappings and leave it prone for more bugs? Can you refer me to any example that demonstrates how data could be stored as key/value. Examples like marbles02 are too simplistic to map to any real world scenario. Thanks.
@ArnabChatterjee I'll say it again - for queries more complex than couchdb selector (_find api) can support, couchdb views with map/reduce would be required. There is intent to add such support.
@ArnabChatterjee I'll say it again - for queries more complex than couchdb selector (_find api) can support, couchdb views with map/reduce would be required. There is intent to add such support. There are examples online for how to do relational-like queries using map/reduce, e.g.: https://danielwertheim.se/couchdb-many-to-many-relations/
and in the couchdb docs: http://docs.couchdb.org/en/latest/ddocs/views/joins.html
Has joined the channel.
Hi,
Can we add a ledger peer dynamically?
@dave.enyeart how the peer to validate the tx is valid,i see the `common/ledger` use the leveldb to store the block,but not validates the tx
can you tell me the peer how to validate the tx
and tell me the peer validate the data is invalid
Any idea how I can silence/fix the ERROR logged by mocklogger in MockStub?
```
2017-09-22 17:47:00.027 AEST [mock] HasNext -> ERRO 041 HasNext() couldn't get Current
2017-09-22 17:47:00.027 AEST [mock] HasNext -> ERRO 042 HasNext() couldn't get Current
2017-09-22 17:47:00.027 AEST [mock] HasNext -> ERRO 043 HasNext() couldn't get Current
2017-09-22 17:47:00.027 AEST [mock] HasNext -> ERRO 044 HasNext() couldn't get Current
2017-09-22 17:47:00.031 AEST [mock] HasNext -> ERRO 045 HasNext() couldn't get Current
2017-09-22 17:47:00.031 AEST [mock] HasNext -> ERRO 046 HasNext() couldn't get Current
```
@asaningmaxchain There are many validation checks prior to commit. There is general tran and endorsement policy validation (validation system chaincode) here: https://github.com/hyperledger/fabric/blob/release/core/committer/txvalidator/validator.go
@dave.enyeart do you test the performance about the peer
and there is ledger validation to ensure that state hasn't changed since simulation time here: https://github.com/hyperledger/fabric/blob/release/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go
I personally don't, but there are people that have been testing and profiling performance to identify bottlenecks
the orderer i know it provide the tool 'broadcast_msg' to get the performance params
i know the ordererit provide the tool 'broadcast_msg' to get the performance params
i know the ordererit provide the tool `broadcast_msg` to get the performance params
there is ledger specific performance test framework here: https://github.com/hyperledger/fabric-test/tree/master/tools/LTE
and end to end performance test framework here: https://github.com/hyperledger/fabric-test/tree/master/tools/PTE
i use the tool `PTE` to test the performance
it's ok
but i want to use the tool to test the peer performance
especially when i use the couchdb
then you probably want https://github.com/hyperledger/fabric-test/tree/master/tools/LTE
and i send innumerable data to the peer
thx
@dave.enyeart
no problem
For each peer, the blocks arrive in an arbitrary order, however, the committing routine cannot commit a block into the ledger before all its previous blocks have been committed. I am wondering how the committing routine decides the order of the blocks it is committing.
@yacovm can you answer qizhang's question?
We have an object called a payload buffer. The comtting routine fetches from that, and it reorders the blocks
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=4hzr57uQC3iuyJztX) @qizhang just to elaborate on @yacovm answer, the buffer keep track on current ledger height and allows to pop from it only blocks with next sequence number, hence commits of the blocks appears in proper order.
Has joined the channel.
Hi, I had an error in my chaincode and it did not propagate to a exception in the promise of my SDK. Although I got the following stacktrace in console
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: chaincode error (status: 500, message: unexpected end of JSON input)
at /home/ubuntu/app-network/app-server/node_modules/grpc/src/node/src/client.js:434:17
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: chaincode error (status: 500, message: unexpected end of JSON input)
at /home/ubuntu/app-network/app-server/node_modules/grpc/src/node/src/client.js:434:17
Thanks :)
@ArnabChatterjee if you use the node please ask in #fabric-sdk-node
Has left the channel.
When i pull down and start the server again the data is getting removed. How to start the server with existing data.
@asaningmaxchain - Thanks. I already did it before I reposted here. Btw, ant clues on the same?
Has joined the channel.
Can anyone point me to the Fabric function that prevents the "double-spend" problem among transactions in a single block? Thanks!
@qizhang you should take a look the fabric how to validate the block
@qizhang I guess its MVCC check you want and its in https://github.com/hyperledger/fabric/blob/d9c320297bd2a4eff2eb253ce84dc431ef860972/core/ledger/kvledger/txmgmt/validator/statebasedval/state_based_validator.go#L194
Thanks @Vadim , I think that is the one
we have `lc.validator.Validate(block)` in the following function, which is used to commit a block into the ledger. Then, inside function 'lc.ledger.Commit(block)', there is another block validation function named `l.txtmgmt.ValidateAndPrepare(block, true)`. I am wondering what are the differences between `lc.validator.Validate(block)` and `l.txtmgmt.ValidateAndPrepare(block, true)`.
we have `lc.validator.Validate(block)` in the following block commit function. Then, inside function 'lc.ledger.Commit(block)', there is another block validation function named `l.txtmgmt.ValidateAndPrepare(block, true)`. I am wondering what are the differences between `lc.validator.Validate(block)` and `l.txtmgmt.ValidateAndPrepare(block, true)`.
we have `lc.validator.Validate(block)` in the following block commit function. Then, inside function `lc.ledger.Commit(block)`, there is another block validation function named `l.txtmgmt.ValidateAndPrepare(block, true)`. I am wondering what are the differences between `lc.validator.Validate(block)` and `l.txtmgmt.ValidateAndPrepare(block, true)`.
we have `lc.validator.Validate(block)` as a block validation function in the following block commit function. Then, inside function `lc.ledger.Commit(block)`, there is another block validation function named `l.txtmgmt.ValidateAndPrepare(block, true)`. I am wondering what are the differences between `lc.validator.Validate(block)` and `l.txtmgmt.ValidateAndPrepare(block, true)`.
```// Commit commits block to into the ledger
// Note, it is important that this always be called serially
func (lc *LedgerCommitter) Commit(block *common.Block) error {
// Validate and mark invalid transactions
logger.Debug("Validating block")
if err := lc.validator.Validate(block); err != nil {
return err
}
// Updating CSCC with new configuration block
if utils.IsConfigBlock(block) {
logger.Debug("Received configuration update, calling CSCC ConfigUpdate")
if err := lc.eventer(block); err != nil {
return fmt.Errorf("Could not update CSCC with new configuration update due to %s", err)
}
}
if err := lc.ledger.Commit(block); err != nil {
return err
}
// send block event *after* the block has been committed
if err := producer.SendProducerBlockEvent(block); err != nil {
logger.Errorf("Error publishing block %d, because: %v", block.Header.Number, err)
}
return nil
}```
how to i update composer to 0.13
0|composer | Connection fails: Error: Error trying to ping. Error: Composer runtime (0.12.1) is not compatible with client (0.13.0)
0|composer | It will be retried for the next request.
0|composer | Exception: Error: Error trying to ping. Error: Composer runtime (0.12.1) is not compatible with client (0.13.0)
@jon_s For data persistence, see https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence
For Composer questions, please post to #composer
I am reading this doc http://hyperledger-fabric.readthedocs.io/en/latest/readwrite.html?highlight=read%20write%20set, and have a few questions: 1. If one of the transactions in the block is invalid, does Fabric abort the whole block? 2. The document mentioned that "Transactions with multiple read-write sets are not yet supported.", can you give an example of a transaction with "multiple read-write sets" (Similar to the one given in this doc)? Thanks!
Has joined the channel.
Does the committer update the world state database after validating and committing all the transactions in a block, or the world state database will be updated right after each transaction has been validated?
Has joined the channel.
@qizhang a good overview of transaction flow can be found here: http://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
@qizhang 1) If one of the transactions in the block is invalid, only that transaction is marked invalid, all the other transactions in the block are marked valid. For all the valid transactions, the state database will be updated per the valid writesets. 2) It may be valuable to have a client invoke one chaincode/function, and then invoke a second chaincode/function, and include both endorsed proposal responses in a single transaction that gets atomically validated or invalidated. This use case is not yet supported in the peer, although the transaction protobuf message can technically support it since it can contain N TransactionActions:
```message Transaction {
// The payload is an array of TransactionAction. An array is necessary to
// accommodate multiple actions per transaction
repeated TransactionAction actions = 1;
}```
Concerning your last question... as the transactions in the block get validated, the valid writeset keys get added to a batch structure in memory. Once all the transactions have gone through validation cycle, then the block is committed to block storage and the block's batch of state updates get committed to state database. It is done in a batch for the block's updates for performance reasons, rather than key by key or tran by tran.
Note that if peer crashes during this process, upon next startup it will detect that it did not finish the commits and will ensure commit consistency before allowing further simulation or block processing. Therefore, the commits can be considered atomic from client perspective.
Thanks @dave.enyeart . There is a rule to check whether two transactions are conflict (e.g. transaction T2 reads some data that has been written by a transaction T1), will T1 and T2 still be considered as conflict even if they are in different blocks?
@dave.enyeart the peer connect couchdb by using short connection
？
@qizhang If transaction readset versions have been incremented in state db since simulation time, the transaction is invalidated. This is true whether the transactions are in the same block or different blocks
@asaningmaxchain what do you mean by short connection?
the peer connect to the couchdb
i use the couchdb to store the state db
peer uses http to connect to couchdb
i think should use the connection pool
yes it does
in the v1.0.0 it use the connection pool for peer?
http connection is reused
but i use the PTE to test the performance, i see the peer can't connect the couchdb dut to the connections is TIME_WAIT
but i use the PTE to test the performance, i see the peer can't connect the couchdb dut to the connections is too much and the state is TIME_WAIT
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=RnjjkxkyGTrykxcGW) @dave.enyeart I this case, if the block validation runs in parallel with the endorsing (i.e. transaction simulation), they may interference with each other. For example, many transactions in the block can be invalidated by the transactions that are being simulated. Any approach to avoid or reduce such interference? Another question, if a transaction (say Ta) in some block has been marked as validate, but right before its write set has been committed to the world state db, another transaction (say Tb) being simulated may make Ta invalidate. How the block validation routine and the endorsing routine collaborate with each other to solve such issue? Thanks!
@dave.enyeart @manish-sethi Rocksdb license change back to Apache 2.0, shall we consider reintroduce Rocksdb?
@dave.enyeart i use the java sdk to test the performance,i use the couchdb to store the db state,and then i send the tx
byt get the following error
byt get the following error `2017-09-27 17:44:11,857:ERROR XNIO-2 task-65 (Channel.java:2241) - Sending proposal to peer0.org1.example.com failed because of: gRPC failure=Status{code=UNKNOWN, description=transaction not found Get http://couchdb0:5984/mychannel/lscc%00cc?attachments=true: dial tcp 172.18.0.2:5984: connect: cannot assign requested address - make sure the chaincode cc has been successfully instantiated and try again, cause=null}
java.lang.Exception: io.grpc.StatusRuntimeException: UNKNOWN: transaction not found Get http://couchdb0:5984/mychannel/lscc%00cc?attachments=true: dial tcp 172.18.0.2:5984: connect: cannot assign requested address - make sure the chaincode cc has been successfully instantiated and try again
`
byt get the following error ```2017-09-27 17:44:11,857:ERROR XNIO-2 task-65 (Channel.java:2241) - Sending proposal to peer0.org1.example.com failed because of: gRPC failure=Status{code=UNKNOWN, description=transaction not found Get http://couchdb0:5984/mychannel/lscc%00cc?attachments=true: dial tcp 172.18.0.2:5984: connect: cannot assign requested address - make sure the chaincode cc has been successfully instantiated and try again, cause=null}
java.lang.Exception: io.grpc.StatusRuntimeException: UNKNOWN: transaction not found Get http://couchdb0:5984/mychannel/lscc%00cc?attachments=true: dial tcp 172.18.0.2:5984: connect: cannot assign requested address - make sure the chaincode cc has been successfully instantiated and try again```
`
the couchdb startup successfully
the couchdb and chaincode run well
@qizhang You have it backwards... a simulation can never invalidate something in validation/commit phase. Blocks/transactions are validated in serial based on valid committed transactions in previous blocks and valid transactions coming before in the same block.
@qizhang You have it backwards... a simulation can never invalidate something in validation/commit phase. Blocks/transactions are validated in serial order based on valid committed transactions in previous blocks and valid transactions coming before in the same block.
But transactions that get validated/committed can indeed invalidate transactions that are still in-flight (either in endorsement phase, ordering phase, or in blocks waiting to get validated at peer)
@grapebaba LevelDB has met all objectives for 1.0 and therefore there is no work queued up to switch to RocksDB. If we find scenarios in the future that are better served by RocksDB then we could re-visit at that time.
@asaningmaxchain You would need to provide more context
@dave.enyeart are you there
?
@grapebaba - It would certainly be good from performance point of view on two accounts.
1) rocks is generally faster because of c++
2) It had a feature that allowed us to skip writing to WAL...
If you are keen on taking this up, I think that best would be if we can support rocks in addition to ongoing support for goleveldb (via core.yaml config) - So we can measure the performance diff between the two. @dave.enyeart - do you know who can give us more about green flag from licensing perspective.
@manish-sethi We would need to look into legal team contacts again. But, I thought we concluded that leveldb vs rocksdb performance would have insignificant impact on overall end-to-end system performance. That is, better to focus investment on the performance improvements that we know will significantly improve end-to-end system performance.
@dave.enyeart i start the orderer and then i use the broadcast_msg tool to send the message to the orderer,i see the block file in my host(i map the data to my host)
```-rw-r----- 1 root root 64M 9月 27 17:14 blockfile_000000
-rw-r----- 1 root root 64M 9月 27 17:14 blockfile_000001```
the block file is 64M
the block file is 64M while i set the config is `BatchTimeout:2s`
the block file is 64M while i set the config is `BatchTimeout:2s` and `MaxMessageCount:10`
the config seems doesn't work
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=yK8zfe2fYiEaeBJw5) @dave.enyeart wait a moment, i will provide more detail by using pastebin
@dave.enyeart - Yes, you are right that for now ledger is not the bottleneck in the overall system performance. But I won't be averse if @grapebaba or someone else wants to experiment with rocksdb separately. My gut feel is that it would increase ledger performance significantly. At a later point in time, we can look into taking the change if sounds promising.
Hi,
Hi,
Can anyone provide me any example of using the GetCreator() function inside go chaincode?
Thanks
@manish-sethi @dave.enyeart got it.
@ArnabChatterjee https://chat.hyperledger.org/channel/fabric?msg=Nuoic4ENgH8TeJWTT
@ArnabChatterjee [ ](https://chat.hyperledger.org/channel/fabric?msg=bk6QLcju5A8T6A4Mj)
@Vadim - Thank you. :) I just found the post incidentally and saw that there was a query regarding fetching the role of the user as well. Any updates on that?
@ArnabChatterjee https://jira.hyperledger.org/browse/FAB-5346
Has joined the channel.
Hi, I'm trying to do a complex query using CouchDB on a peer. Everything works great when I apply rules on data attributes. But when I want to make a condition on the document ID, I have nothing. On Fauxton, the query works, but not in the Chaincode (no result). There is some kind of extra structure for the Document ID like the `data` envelopment?
The query:
```
{
"selector": {
"_id": {
"$regex": "event_.*"
}
}
}
```
@antitoine couchdb selector works against the document content, not against the header fields like _id. You would need to push the id into the document content if you want to include it in selector queries. And remember, in the chaincode query do not include the 'data' wrapper in your field names.
@dave.enyeart Thanks! ;)
Has joined the channel.
I'm calling ChaincodeStubInterface.GetHistoryForKey() in chaincode. It returns from most ancient to newest. I think it should return from newest to oldest (at least optionally) because that's the side that's always changing. Also imagine the key was changed millions of times. It would be nice to query with some constraints so we could call the chaincode and get batches without always running the whole history iteration to get the next chunk.
chaincode-dev sent me here, is this the right forum to discuss the shim?
@dave.enyeart - I'm going to check in a fix for https://jira.hyperledger.org/browse/FAB-4905 - don't think anyone else is working on it yet?
I have the fix locally - going to do a few more tests and then submit it
@mastersingh24 I looked into it a bit as well, my take was that the changes to Dockerfile.in and docker-entrypoint.sh from this CR should be reverted: https://gerrit.hyperledger.org/r/#/c/7507
@mastersingh24 I looked into it a bit as well, my take was that the changes to Dockerfile.in and docker-entrypoint.sh from this CR should be reverted: https://gerrit.hyperledger.org/r/#/c/7507. That would take it back to the way it was when we got it.
@mastersingh24 I looked into it a bit as well, my take was that the changes to Dockerfile.in and docker-entrypoint.sh from this CR should be reverted: https://gerrit.hyperledger.org/r/#/c/7507. That would take it back to the way it was when we got it, running as root rather than couchdb.
Did you conclude the same?
Go ahead and take it, and thanks!
Actually - my change will allows you to run as couchdb ;)
Actually - my change will allow you to run as couchdb ;)
@dave.enyeart in the fabric source code,in the `common/ledger` folder,it just use the leveldb to store the index
@asaningmaxchain That's correct, block storage is on file system, indexes into block storage uses leveldb (supports queries such as GetTransactionById), and state database uses either leveldb or couchdb. If you want to understand ledger architecture better, please see charts attached to https://jira.hyperledger.org/browse/FAB-758.
Has joined the channel.
Any performance numbers available for fabric?
Has joined the channel.
Hi guys, anyone know if we can use multiline strings for rich couchdb queries when using `GetQueryResult`?
@dave.enyeart thx,can you explain how the fabric to index the block
@asaningmaxchain upon commit to block storage, 'indexes' are also built in leveldb. These are simply key/value pairs to support queries into block storage. For example GetTransactionById is supported by an 'index' that uses txid as key and file location in block storage as value.
@dave.enyeart thx
Has joined the channel.
@sampath06 how do you mean? really can't get an performance numbers without a use case
Has joined the channel.
@mastersingh24 i'm trying to enable full text searching with couchdb, should i be building couchdb from scratch with mango or just use couchdb-lucene?
woop, nevermind. looks like i just had an extra whitespace character near an escaped quote...
Has joined the channel.
Has joined the channel.
folks, trying to understand why bucket tree was removed from v1.0. Appreciate any pointers
what'd happen to the world state (changed by PutState?)
Hi, if a committing (non endorsing) peer's ledger data has been altered or isn't up-to-date, and it receives a new block from the ordering service, and it detects an inconsistency, is the transaction marked invalid for just that peer or for all peers. Is there some mechanism where the peer marks itself as bad and then checks with other peers? I am thinking about if there is one bad committing peer, how is that handled? Thanks!
Has joined the channel.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=p4zyKfrZCrenmDPBv) @AnhDinh The overall model of consensus and transaction processing in version 0.6 (that employed bucket tree) is quite different from the version 1.0.
In version 0.6, at each block the hash of entire world state would go in the block which is not the case in version 1.0. When you need to compute state hash as frequently as every block, some structure (such as bucket tree) helps in making the compute of the order of the delta change as opposed to the order of entire state.
In 1.0, going forward, the hash of entire state would be computed and consented upon only on certain coarse grained intervals (say every 100,000 blocks) so that previous blocks can be pruned.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=v2qBFYthBNEHcFGLo) @tennenjl Marking the transaction (valid or invalid) is performed locally at each peer independently - pretty much like a bitcoin node would perform validation of a transaction/block independently. A bad peer cannot influence other peers decision.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=v2qBFYthBNEHcFGLo) If a historical block has been altered or is not up-do-date, the peer will not be able to detect it upon the receiving of a new block, isn't it? @manish-sethi
@qizhang yes you are right. local tempering would only be detected by verifying the hashes of the block and comparing (top most hash) with other peers.
Assuming the code that does the above is not tempered with :-)
Assuming that the code that does the above is not tempered with :-)
hi, when i am getting the transaction history using the transaction id, i see the block number with fields `low` and `high` what do these fields mean?
@wy where are you looking? Can you provide a screenshot of what you are talking about?
Has joined the channel.
Has joined the channel.
hey all, trying to execute a number of transactions in parellel, getting `MVCC_READ_CONFLICT`, any insight into what this means?
They all must be reading and modifying the same data items.
`MVCC_READ_CONFLICT` means that during validation of the transaction, it was found that the part of the state that the transaction read during simulation phase has changed (by some other tran that got committed before this tran)
@manish-sethi thank you! that makes sense based on the chaincode logic i have set up, i'll have to rethink some things
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=qmqmETnuvQ9JvFYyb) @dave.enyeart Here is a snippet ```"version":{"block_num":{"low":53,"high":0,"unsigned":true},"tx_num":{"low":0,"high":0,"unsigned":true}}},{"key":"org2id","version":{"block_num":{"low":51,"high":0,"unsigned":true},"tx_num":{"low":0,"high":0,"unsigned":true}}},{"key":"org1id","version":{"block_num":{"low":54,"high":0,"unsigned":true},"tx_num":{"low":0,"high":0,"unsigned":true}}}],"range_queries_info":[],"writes":[{"key":"507cae7eeae02a085a84165f26ff34e8a69d0261df5548eed47f769fa745d2af","is_delete":false,"value":"{\"docType\":\"completedtx\",\"refID\":\"507cae7eeae02a085a84165f26ff34e8a69d0261df5548eed47f769fa745d2af\",\"sender\":\"org2id\",\"receiver\":\"org1id\",\"priority\":0,\"amount\":200000,\"currency\":\"dollar\",\"status\":\"SETTLED\",\"createTime\":\"2017-10-05T16:06:54.946Z\",\"updateTime\":\"2017-10-05T16:07:27.082Z\"}"}]}},{"namespace":"lscc","rwset":{"reads":[{"key":"chaincode","version":{"block_num":{"low":1,"high":0,"unsigned":true},"tx_num":{"low":0,"high":0,"unsigned":true}}}],"range_queries_info":[],"writes":[]}}]},"events":{"chaincode_id":"","tx_id":"","event_name":"","payload":{"type":"Buffer","data":[]}},"response":{"status":200,"message":"","payload":"{\"nettableTxList\":[\"507cae7eeae02a085a84165f26ff34e8a69d0261df5548eed47f769fa745d2af\"],\"wentToLoop\":true}"}}}```
@wy Is that from node js sdk?
@dave.enyeart yes it is
It looks like a two byte number, where 53 is in the low byte and 0 is in the high byte, so block num is 53. But I don't know why node js sdk would return it in that format. please ask over in #fabric-sdk-node
its the output from queryTransaction
im just curious why there are different block numbers associated with each transaction
blocks are cut every two seconds by default. if you send them at a quicker rate you would see two trans in one block
but this is a single transaction
it should technically be in the same block shouldnt it? or am i understanding this wrongly
sorry i don't know the fabric-sdk-node interactions, please ask over in #fabric-sdk-node
alright, sure. thanks!
@wy @dave.enyeart - it seems that javascript does not have native support for int64 and protobuf impl for js breaks into high/low int32 form - https://github.com/dcodeIO/protobuf.js/issues/53
Also, the different versions you see in the message are the read-set of different keys in a single tran
Still, as Dave suggested better to confirm with #fabric-sdk-node folks about low/high stuff
@manish-sethi so how can i validate that the transaction is actually committed into a block?
The only way is to look for the validation flags in the block. If this tran is marked as valid, it got committed else invalidated (and hence aborted)
which block will this transaction appear in since there is like 3 different numbers there (53, 51, 54)?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=AJKzYSZdgENhc3QP3) @manish-sethi so does this mean that even if the transaction is invalid, it will still appear in the block?
51 and 54 are the versions in the read-set for keys `org2id` and `org1id` respectively... so surly your tran is in higher block than 54.
Yes, even the invalid trans will appear in the block.
How did you retrieve this protobuf that you pasted?
i got it from the queryTransaction function from node js
i got it from the `queryTransaction` function from node js
For some things node js sdk returns the raw protobuf
Perhaps, you did not paste the entire response here. It starts with 'version'...
Manish, I think our get transaction API only returns the data envelope. Would probably be better to return some metadata as well, such whether the tran was marked as invalid/valid and which block num it is in. What do you think?
yes @dave.enyeart. Makes sense
yes @dave.enyeart Makes sense
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Re9CHCMjf9QqZpgBt) @manish-sethi yes, the entire response is too long to be pasted haha
:-)
do you want to see the rest of the response?
No, as Dave pointed out, we do not include the information such as blocknum and the valid/invalid status in the response - you won;t see that info anyway
so actually, the reason why i am asking about this is because on the surface it seems like my transaction went through successfully, all logs indicate a successful transaction. However when i query the state, it seems like it has not been changed at all
That should not happen... unless there is a serious bug
Did you look at peer logs as well? I suspect the tran got invalidated...
@dave.enyeart under what conditions will the transaction get invalidated?
it passed the endorsement and ordering process though
many potential reasons, the most common are not meeting endorsement policy and state changing for read key between endorsement and commit time. the peer log should provide an indication.
so i actually have multiple orgs on multiple channels
i am currently firing transactions in quick succession to each channel (calling the same function)
the thing is the most of the transaction is valid except only 1
if you are doing trans in quick succession on same keys then it is likely a state validation issue
but i dont see how this will affect the states as these are all different channels
right, it would have to be two trans in the same channel conflicting
the only thing that is constant is that the peers may reside in more than 1 channel
but that shouldnt affect the end result right?
right
the odd thing is that when i fire the requests one by one manually, every transaction went through and managed to change the state successfully
well we know you've got at least 54 transactions in this channel, so my bet is still on an invalidation due to conflicting transactions
so to check this i have to look at the docker logs for the peers in the channel that failed?
right
what can i expect to see if the transaction is invalidated?
this is the message you'll get in peer log:
logger.Warningf("Block [%d] Transaction index [%d] TxId [%s] marked as invalid by state validator. Reason code [%s]",
block.Num, tx.IndexInBlock, tx.ID, validationCode.String())
you can do something like this:
```docker logs peer1.org2.example.com 2>&1 | grep -i -a invalid```
@dave.enyeart awesome, will try that out
thanks!
no problem
@dave.enyeart im seeing some lines that look like this `2017-10-06 02:10:36.318 UTC [statevalidator] ValidateAndPrepareBatch -> WARN 6ead7 Block [540] Transaction index [0] marked as invalid by committer. Reason code [10]`
any idea what is reason code 10?
ENDORSEMENT_POLICY_FAILURE
I will open a defect to print the string rather than the code
@manish-sethi @wy I see that queryTransaction returns a ProcessedTransaction which includes the transaction data envelope as well as the validationCode
So I think if @wy provided the full json message we would have seen the validationCode
```{"validationCode":0,"transactionEnvelope":{"signature":{"type":"Buffer","data":[48,69,2,33,0,229,102,162,41,130,164,119,48,128,187,121,122,103,126,234,74,72,149,26,40,244,143,64,67,68,224,107,246,16,0,176,55,2,32,77,103,2,194,105,13,14,234,34,97,22,147,99,107,10,50,235,54,170,58,52,127,119,58,151,160,129,114,204,115,6,109]},"payload":{"header":{"channel_header":{"type":"ENDORSER_TRANSACTION","version":3,"timestamp":"Thu Oct 05 2017 16:07:27 GMT+0000 (UTC)","channel_id":"org1org2channel","tx_id":"d2bfb1ccff47a4ec08a2706c9a8f63da1105fcb55d0ddf0a148df189d198c29b","epoch":0,"extension":{"type":"Buffer","data":[18,21,18,19,98,105,108,97,116,101,114,97,108,99,104,97,110,110,101,108,95,99,99]}},"signature_header":{"creator":{"Mspid":"org0MSP","IdBytes":"-----BEGIN CERTIFICATE-----\nMIIB7zCCAZagAwIBAgIUbm2+X9kt26GlhqlIo3HYIs24rjQwCgYIKoZIzj0EAwIw\nczELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNh\nbiBGcmFuY2lzY28xGTAXBgNVBAoTEG1hc3IuZXhhbXBsZS5jb20xHDAaBgNVBAMT\nE2NhLm1hc3IuZXhhbXBsZS5jb20wHhcNMTcxMDA1MDMxODAwWhcNMTgxMDA1MDMx\nODAwWjAPMQ0wCwYDVQQDEwRNQVNSMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE\nxMuK8haZ9TCBVLLvO9+AwKewvTyIRKTZyS9awjvHGO624+fRrGCCWHaYmUtyPKtO\nEO4NNHKhL6OiI5lN1i3/36NsMGowDgYDVR0PAQH/BAQDAgeAMAwGA1UdEwEB/wQC\nMAAwHQYDVR0OBBYEFLyyVUKNxOCUYvNt8S3FTYnw2MEbMCsGA1UdIwQkMCKAIG6U\na6iL7TPitJxXas+osebY7S7o+FLTdfUaGqm/SH4JMAoGCCqGSM49BAMCA0cAMEQC\nIBX3AU0SSR7Rd02RJ8McT3H0H9GiqMMnfHe8UIPDAlSkAiA4EnFXqG9YECkyRQaf\nGbLcIk0lJ9wBrR8rU1OzowtcHQ==\n-----END CERTIFICATE-----\n"},"nonce":{"type":"Buffer","data":[170,1,194,195,55,203,216,126,17,51,120,150,116,111,112,249,208,175,81,120,73,162,146,39]}}},"data":{.....```
0 means success
0 means valid
means it is committed?
yes, committed as valid
so the state should have changed?
does the write in the transactionEnvelope look correct? In the prior json it says there was a write for key 507cae7eeae02a085a84165f26ff34e8a69d0261df5548eed47f769fa745d2af
Yes. Does the write in the transactionEnvelope look correct? In the prior json it says there was a write for key 507cae7eeae02a085a84165f26ff34e8a69d0261df5548eed47f769fa745d2af
Upon commit, that key should get updated in state.
@manish-sethi I stand corrected on the prior comment... PeerLedger.GetTransactionByID() does in fact wrap the transaction data envelope to also include validation code.
OK, cool
I was looking at the lower level api earlier
@dave.enyeart i tried the scenario again and got this
```2017-10-06 03:52:17.446 UTC [statevalidator] ValidateAndPrepareBatch -> WARN 91827 Block [144] Transaction index [1] TxId [64182f325cd43c8fe50e87c349bbf31cad237df4c669dcc9e27457a9bd340adf] marked as invalid by state validator. Reason code [11]
2017-10-06 03:52:17.498 UTC [historyleveldb] Commit -> DEBU 91897 Channel [scbcschannel]: Skipping history write for invalid transaction number 1```
what is reason code 11?
that is MVCC_READ_CONFLICT that I was predicting
https://github.com/hyperledger/fabric/blob/v1.0.0/protos/peer/transaction.proto#L125
does that mean that there are 2 conflicting transactions that affect the same state?
correct
thats really odd...
i am only calling once per channel
there shouldnt be a conflict in state
tran a reads a variable, and that variable has been updated by tran b before tran a validates/commits.
Has joined the channel.
@wy - i guess that you need to look again at your workload. Your logs say... 'Block [144]' was it 143 before you ran the latest run? or started from scrach?
@wy - i guess that you need to look again at your workload. Your logs say... 'Block [144]' was it 143 before you ran the latest run? or started from scratch?
@manish-sethi how do i check the latest block number? so that i can make a note before my next run
@manish-sethi how do i check the latest block number? so that i can take note before my next run
haven't used sdk myself... but there should be a function in node sdk for getting the current height.
https://fabric-sdk-node.github.io/Channel.html#queryInfo
so just to confirm, the flow for every transaction will be like this
1) propose/endorse
2) ordering
3) another validation?
or is the 2nd validation done during ordering?
not sure what you mean by second validation...
propose endorse / ordering / validation + commit
so this validation + commit is done on the peer level?
@manish-sethi so this validation + commit is done on the peer level?
sorry for the confusion, i was considering the endorsement as the "first validation"
Hello everyone. I am using Go chaincodes and want to read files from chaincode. Can anyone let me know how to mount volumes (where files would be placed) in chaincode docker container?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=JERiTMiPotWvfNjeq) @ArnabChatterjee set volumes in the docker compose config
@wy - I did that already under every peer image
It does not work that way
even the files and volumes are getting mounted in each peer container, but the chaincode doesn't seem to read it
@wy - any clues?
i havent tried reading files in my chaincodes, but is it possible for you to put the files you need to read in your chaincode folder to see if it works?
@wy - That is exactly what I tried in the first place. But since the deployment didn't upload the files to the chaincode container/peer container, then I tried volume mapping
anyway try asking in #chaincode-dev
but when you did volume mapping, is your chaincode referring to the path in your container?
@wy - no its not referring to the path in the peer container. Although the files are correctly uploaded/mapped in the peer container. Btw, Is there any way I can map volumes inside the chaincode container instead of the peer container?
@dave.enyeart @manish-sethi what may be the reasons that can cause Reason Code 10 `ENDORSEMENT_POLICY_FAILURE`?
@dave.enyeart @manish-sethi what may be the reasons that can cause Reason Code 10 `ENDORSEMENT_POLICY_FAILURE` during validation/commit?
it passed endorsement but failed during validation
@wy If you get ENDORSEMENT_POLICY_FAILURE during validation/commit phase then you did not get enough endorsements per the endorsement policy, or the endorsements were based on different chaincode results (which may happen if the peers are at different block heights and they've read keys at different versions).
@wy If you get ENDORSEMENT_POLICY_FAILURE during validation/commit phase then you did not get enough endorsements per the endorsement policy, or the endorsements were based on different chaincode results (which may happen if the peers are at different block heights at simulation time and they've read keys at different versions).
The peer logs should contain additional information
At least if debug level is on
@dave.enyeart its weird though, when i did a `compareProposalResponseResults` prior to submitting the proposal to the orderer, it returns a `true` value which
@dave.enyeart its weird though, when i did a `compareProposalResponseResults` prior to submitting the proposal to the orderer, it returns a `true` value
@wy it does not check the results against the endrosement policy as far as I know, only that results are the same
im pretty sure that the endorsement policy matches as my endorsement policy is just AND(org1, org2)
Has joined the channel.
Hello everyone. I am using Go chaincodes and want to read files from chaincode. Can anyone let me know how to mount volumes (where files would be placed) in chaincode docker container? Any ideas? Thanks. :)
@dave.enyeart @manish-sethi i see the `orderer/common/ledger`
@dave.enyeart @manish-sethi i see the `orderer/common/ledger` and https://gist.github.com/asaningmaxchain/b70085bac719f865c22875170ad4f683
where i get is the orderer node just store the blockNum index
where i get is the orderer node just store the blockNum index?
@asaningmaxchain Orderer ledger has to be able to retrieve block by number. Whereas Peer ledger also has other requirements such as retrieve transaction by id. Therefore Orderer ledger has a subset of the common ledger functions and supporting indexes, and Peer ledger has superset of ledger functions and supporting indexes. It wasn't clear what your questions was though, hopefully that answered it.
@dave.enyeart thx,i just want to know how the orderer store the block
Orderer stores the block in the same block storage that peer ledger uses
Orderer stores the block in the same block storage data structure that peer ledger uses
Orderer just has fewer supported queries and underlying apis
Orderer ledger just has fewer supported queries and underlying apis
Orderer ledger just has fewer supported queries and underlying indexes
@dave.enyeart thx, i am seeing the orderer ledger
@muralisr, can you provide thoughts on this one?
@muralisr, can you provide thoughts on the following question from @ArnabChatterjee? Is it safe for chaincode to read things from disk?
>Hello everyone. I am using Go chaincodes and want to read files from chaincode. Can anyone let me know how to mount volumes (where files would be placed) in chaincode docker container? Any ideas? Thanks. :)
Has joined the channel.
@dave.enyeart @ArnabChatterjee that would be an antipattern in general (an alternate persistent state to the ledger, potential global data leakage across channels, etc).... better approach would be to store data as state
but if you do want to break those rules for good reasons, fabric samples have many examples of mounting volumes (e.g., yaml files under examples/e2e_cli)
@muralisr @dave.enyeart - Thanks for pointing that out. I will consider that. But I was trying to mount the volumes using the examples in e2e_cli but that works in dev mode where the chaincode is running directly from the OS volume. Is there any alternative where the chaincode would run in a separate docker container (as in fabric-samples/balance-transfer example) ? Thanks for your support. :)
Has joined the channel.
@dave.enyeart @mastersingh24 I had a chat with @manish-sethi about the following pairs of shim APIs:
- CreateCompositeKey()
- GetStateByPartialCompositeKey()
he was suggesting that these are not providing enough value over having the app construct the keys directly and use GetStateByRange() to query, and suggest removing them. Now regardless of what we should do with v1.1 golang shim, I think we should consider not offering these APIs in node.js chaincode shim. can I get you guys to weigh in on this? @sstone1 @davidkel what's your opinion from Composer's point of view?
@dave.enyeart @mastersingh24 I had a chat with @manish-sethi about the following pairs of shim APIs:
- CreateCompositeKey()
- GetStateByPartialCompositeKey()
he was suggesting that these are not providing enough value over having the app construct the keys directly and use GetStateByRange() to query, and suggest removing them. Now regardless of what we should do with v1.1 golang shim, I think we should consider not offering these APIs in node.js chaincode shim (they have been implemented already). can I get you guys to weigh in on this? @sstone1 @davidkel what's your opinion from Composer's point of view?
Has joined the channel.
@jimthematrix @manish-sethi It is true that strictly speaking applications could do this on their own with GetStateByRange(). CreateCompositeKey() and GetStateByPartialCompositeKey() are simply utility methods to make this pattern simple for applications. Getting the separator characters correct so that you receive the exact expected results back from the range query is not trivial however. For example when querying for Jim's marbles ensuring that you don't also get back Jimmy's marbles. It took us a few tries to get this exactly correct. I'm not seeing a reason to remove these utility APIs and pushing that burden onto applications. I've advised many people how to use these APIs to solve their query use cases - it is a common query pattern. That advise would be an order of magnitude more complex if we didn't have these utility APIs.
@jimthematrix @manish-sethi It is true that strictly speaking applications could do this on their own with GetStateByRange(). CreateCompositeKey() and GetStateByPartialCompositeKey() are simply utility methods to make this pattern simple for applications. Getting the separator characters correct so that you receive the exact expected results back from the range query is not trivial however. For example when querying for Jim's marbles ensuring that you don't also get back Jimmy's marbles, and ensuring that you don't have collisions across simple and composite namespaces. It took us a few tries to get this exactly correct. I'm not seeing a reason to remove these utility APIs and pushing that burden onto applications. I've advised many people how to use these APIs to solve their query use cases - it is a common query pattern. That advise would be an order of magnitude more complex if we didn't have these utility APIs.
i know i'm not a part of this conversation but from a developer perspective i definitely found value in using composite keys while writing chaincode in go and would like them to be kept as utility functions in the shim in v1.1
@dave.enyeart thanks for the input, will keep them then. writing API doc for the node.js chaincode APIs. will ask you (and @manish-sethi ) for review once they get uploaded to CR
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=foZRxJ4j9PPhQzKvT) @manish-sethi @qizhang , Thank you both for the response. So with each node doing their own validation, if for some reason the blocks are not up-to-date, is there some recommended action to get the ledger-up-to-date, or is there something within the fabric itself which helps keep nodes which sporadically go offline in -sync? I'm thinking in this case where you may have a node which loses network connectivity for a period of time or perhaps there is a DDOS attack. Thanks again!
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=foZRxJ4j9PPhQzKvT) @manish-sethi @qizhang , Thank you both for the response. So with each node doing their own validation, if for some reason the blocks are not up-to-date, is there some recommended action to get the ledger-up-to-date, or is there something within the fabric itself which helps keep nodes which may go offline in -sync? I'm thinking in this case where you may have a node which loses network connectivity for a period of time or perhaps there is a DDOS attack. Thanks again!
Has joined the channel.
@tennenjl I did not understand your scenario well. A peer validates and commits block number `n` only on top of `n+1`. It's a sequential processing of blocks.
@tennenjl I did not understand your scenario well. A peer validates and commits block number `n` only on top of `n-1`. It's a sequential processing of blocks.
@manish-sethi , Thanks, so if a peer is off line, when block number n is broadcast to the peer, when it comes on line, how does the gossip protocol receive block number n before receiving n+1? Is it a pull or push? Thanks!
@manish-sethi , Thanks, so if a peer is off line, when block number n is broadcast to the peer, when it comes on line, It does a sync by pulling the latest blocks using gossip? Thanks!
yes, peers are always trying to get the next blocks in sequence. it may pull from ordering service or by state transfer from other peers.
yes, peers are always trying to get the next blocks in sequence. it may pull from ordering service or from other peers.
yes, peers are always trying to get the next blocks in sequence. it may pull blocks from ordering service or from other peers.
yes, a peer is always trying to get the next blocks in sequence, regardless of how long it was done. it may pull blocks from ordering service or from other peers.
yes, a peer is always trying to get the next blocks in sequence, regardless of how long it was down. it may pull blocks from ordering service or from other peers.
@dave.enyeart Many thanks. Does only the leader peer pull blocks from the ordering service and is the leader peer randomly selected?
for this next level of detail you'd have to ask in #fabric-gossip
i believe so, but for this next level of detail you'd have to ask the experts in #fabric-gossip
@dave.enyeart Thank you!
Hi, I ran into the following error when creating a Fabric network with Kafka, please advise. Thanks!
```[2017-10-11 16:06:26,228] ERROR [Replica Manager on Broker 0]: Error processing append operation on partition [testchainid,0] (kafka.server.ReplicaManager)
kafka.common.NotEnoughReplicasException: Number of insync replicas for partition [testchainid,0] is [1], below required minimum [2]
at kafka.cluster.Partition$$anonfun$9.apply(Partition.scala:438)
at kafka.cluster.Partition$$anonfun$9.apply(Partition.scala:428)
at kafka.utils.CoreUtils$.inLock(CoreUtils.scala:262)
at kafka.utils.CoreUtils$.inReadLock(CoreUtils.scala:268)
at kafka.cluster.Partition.appendMessagesToLeader(Partition.scala:428)
at kafka.server.ReplicaManager$$anonfun$appendToLocalLog$2.apply(ReplicaManager.scala:401)
at kafka.server.ReplicaManager$$anonfun$appendToLocalLog$2.apply(ReplicaManager.scala:386)
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245)
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245)
at scala.collection.mutable.HashMap$$anonfun$foreach$1.apply(HashMap.scala:99)
at scala.collection.mutable.HashMap$$anonfun$foreach$1.apply(HashMap.scala:99)
at scala.collection.mutable.HashTable$class.foreachEntry(HashTable.scala:230)
at scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:40)
at scala.collection.mutable.HashMap.foreach(HashMap.scala:99)
at scala.collection.TraversableLike$class.map(TraversableLike.scala:245)
at scala.collection.AbstractTraversable.map(Traversable.scala:104)
at kafka.server.ReplicaManager.appendToLocalLog(ReplicaManager.scala:386)
at kafka.server.ReplicaManager.appendMessages(ReplicaManager.scala:322)
at kafka.server.KafkaApis.handleProducerRequest(KafkaApis.scala:365)
at kafka.server.KafkaApis.handle(KafkaApis.scala:68)
at kafka.server.KafkaRequestHandler.run(KafkaRequestHandler.scala:60)
at java.lang.Thread.run(Thread.java:785)```
Hey all, is the network ID used for anything other than logging?
@Asara yeah it's used to name the chaincode container
Has joined the channel.
@qizhang Please post kafka questions over on #fabric-orderer , the folks that hang out over there should know
Has joined the channel.
I have a question on couchDB. I am using the node sdk app for using the HL fabric and want to ask if there is a way to protect the couchdb instances with a username and password. I tried using environment variables COUCHDB_USER and COUCHDB_PASSWORD but then my peer service didnt . Any help will e appreciated.
@SanketPanchamia If you set the couchdb user and password, you also have to tell the peer what the user and password are. Instructions can be found here: https://hyperledger-fabric.readthedocs.io/en/latest/ledger.html#couchdb-configuration
and example here: https://github.com/hyperledger/fabric-samples/blob/release/first-network/docker-compose-couch.yaml#L34
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=R97Qm4mEhEbDWFSEB) @dave.enyeart Thanks Dave. Will have a look and see.
Has joined the channel.
error_of_config_update.txt
Has joined the channel.
Has joined the channel.
Hi all, I'm a freshman about fabric. I have a question: Since we can use couchDB as state database, can we also add mysql(or other rdbms) as state database easily?
@changrui At this point not easily since the existing chaincode programming model is based on key/value store with APIs like PutState() and GetState(). But there are some people looking into a SQL based programming model which would then enable relational data stores as state database. Nothing in the core architecture prevents this.
Hi guys, if I want to get list of transaction history for each of particular wallet. how can I achieve this?
See chaincode API GetHistoryForKey(): https://github.com/hyperledger/fabric/blob/release/core/chaincode/shim/interfaces.go#L152-L164
@Jonny See chaincode API GetHistoryForKey(): https://github.com/hyperledger/fabric/blob/release/core/chaincode/shim/interfaces.go#L152-L164
thanks @dave.enyeart. I will try to understand the method.
@dave.enyeart can I safely say that key here is the id for the particular wallet/user that I want to get the transaction history?
If that so, how can I handle the pagination the result?
@Jonny It all depends on how your chaincode is designed. Assuming your chaincode is designed such that a state key is a particular waller/user, then yes, GetHistoryForKey() will return the history of transactions and values for that wallet/user.
You can next() through those results, see example at https://github.com/hyperledger/fabric/blob/release/examples/chaincode/go/marbles02/marbles_chaincode.go#L574-L621
You can return a paged list in your chaincode if you like
Thank you very much @dave.enyeart. It's clear for me now.
Really appreciate you help!
Really appreciate your help!
@dave.enyeart Sorry, I just notice that resultsIterator.Next() is looping thru the result. How about the result is too big. Is there any way to get only first 20 for example. then I call again to get next 20 for proper pagination.
@Jonny No paging support within the internal API at this time. There is intent to add in the future. For now you can do paging at the chaincode level so that you return paged results to the client.
I have no clue how to implement it at the chaincode level. Can you show me how can I achieve this?
In the example at https://github.com/hyperledger/fabric/blob/release/examples/chaincode/go/marbles02/marbles_chaincode.go#L574-L621 all history records are returned. You could have a similar chaincode function that takes a page number and page count as input, and returns a corresponding subset of the history records.
Has joined the channel.
@minollo moving your discussion to this channel.. which is more relevant
https://chat.hyperledger.org/channel/fabric-peer-endorser-committer?msg=KkuEaEE6MxwA6Qcnp
To summarize the discussion, your observation is absolutely correct that long running simulation can block the commit for a long time and which in turn could increase the transaction invalidation rate during future commits. However, as @muralisr pointed out most of the workload is expected to be of fairly short-lived simulation.
Having said that, as I stated earlier, we intend to work on snapshot based isolation for simulation(s) and commit.
In between, if you are having a practical application in mind that requires a long running simulations and you want to share the details of that or you have any empirical observations on performance in the context of long running simulations that you want to share, it would certainly be helpful.
Has joined the channel.
hi, can i use protobuf in the chaincode?
@bh4rtp Yes, you can. you need to improve the fabric-ccenv image to include protobuf:
`1.docker pull hyperledger/fabric-ccenv:x86_64-1.0.2
2.docker run -it
If you like, I already did this for `fabric-ccenv:x86_64-1.0.2` , you can: docker pull sunnys/fabric-ccenv:x86_64-1.0.2
@shanlusun won't vendoring the protobuf lib be an easier solution?
@Vadim No, because the chaincode is built inside fabric-ccenv
yes, but you can add the protobuf to vendor folder and then you will have protobuf support in your chaincode, no?
since it's copied along with the chaincode, it will end up in the ccenv container
That depends on how fabric install chaincode for peer,right ?
For my understanding the vendor folder will not go with chaincode when we install chaincode to peer.
@shanlusun it does go
So where we put the vendor folder when we install chaincode ?
@shanlusun it's in the chaincode/vendor
@shanlusun it's in the your_chaincode_folder/vendor
standard golang vendoring
@shanlusun yes, @Vadim is right. i just found protobuf in `/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/golang`. and `protoc` can be used in fabric-ccenv container.
@bh4rtp ccenv does not contain it, but you can include it yourself
@Vadim it does contain protobuf in version 1.1.0. :slight_smile:
@bh4rtp Yes, I did quick check, protobuf is in `/opt/gopath/src/github.com/hyperledger/fabric/vendor/github.com/golang`
ok, but you might need some other libraries and you can include them using vendoring
protoc can be used in container ccenv.
@Vadim this helps, will try next time, I think I should put vendor folder under the same path with chaincode.go, right ?
So the path(has both chaincode.go and vendor) will be used to install chaincode later
so you have yourchaincode/chaincode.go, you put some external lib which is not in ccenv in yourchaincode/vendor/lib
you can also use govendor to manage dependencies
Got it
also, https://www.youtube.com/watch?v=-mlUaJbFHcM
@Vadim Thanks a lot~ :)
@Vadim Thanks a lot too
no problem
Hi everyone, I got some problem with changing the block size, please advise. When I increase the `MaxMessageCount` from 10 to 100, I can see the block size increases also from 10 tx/block to 100 tx/block. However, when I further increase the `MaxMessageCount` from 100 to 200, the block size only increases to 104 tx/block, and it stays the same even when I increase the `BatchTimeout` from 2s to 5s. BTW, I am using a client that sends 600 tx/sec to the Fabric, so I think the tx rate from the client should be high enough to create blocks with 200 tx/block.
@qizhang I thought BatchSize is responsible for block size
Perhaps AbsoluteMaxBytes or PreferredMaxBytes are having an influence
```# Batch Timeout: The amount of time to wait before creating a batch
BatchTimeout: 4s
# Batch Size: Controls the number of messages batched into a block
BatchSize:
# Max Message Count: The maximum number of messages to permit in a batch
MaxMessageCount: 200
# Absolute Max Bytes: The absolute maximum number of bytes allowed for
# the serialized messages in a batch.
AbsoluteMaxBytes: 99 MB
# Preferred Max Bytes: The preferred maximum number of bytes allowed for
# the serialized messages in a batch. A message larger than the preferred
# max bytes will result in a batch larger than preferred max bytes.
PreferredMaxBytes: 512 KB```
Please move discussion to #fabric-orderer
that is where blocks are cut
Sure, thanks @dave.enyeart
Anyone has tried the master version of Fabric? I can no longer see the message `Channel [%s]: Created block [%d] with %d transaction(s)` from the peer log, why is that?
Anyone has tried the master version of Fabric? I can no longer see the message `Channel [%s]: Created block [%d] with %d transaction(s)` from the peer log, why is that? I was able to see it in Fabric v1.0.3
Has joined the channel.
Has joined the channel.
Before I suggest this as a solution to someone: my own very rough and quick testing shows that you can remove the "index" directory that hosts the LevelDB index and it will be rebuilt when you restart the orderer binary. Is that indeed the case? Anything that I'm missing, or any reasons not to do that?
(For context: a user is experiencing an issue where a hacky solution would be to have them delete all blocks from the orderer ledger directory for their channel besides the first one. But if they were to do that, the LevelDB index would be off.)
^^ @manish-sethi @dave.enyeart
@kostas, yes your observation is correct. You can drop the index and it get rebuilt on next start.
Awesome, thanks @manish-sethi
@Vadim i do vendoring as you instructed, put `github.com/golang/protobuf/proto` to mychaincode/vendor. and got this error:
```container_linux.go:247: starting container process caused "exec: \"chaincode\": executable file not found in $PATH"```
@Vadim i do vendoring as you instructed, put `github.com/golang/protobuf/proto` to mychaincode/vendor. and got this error when instantiating chaincode:
```container_linux.go:247: starting container process caused "exec: \"chaincode\": executable file not found in $PATH"```
i found the reason, chaincode package not defined with `main`.
Hi. I need to know if there is a way to share some data (key->value pair kind) across channels?
Without adopting weird and costly workarounds
^ Let's delete this now please since it was posted and answered in #fabric ?
^ Let's delete this now since it was posted and answered in #fabric ?
hi, must i store json string as value into couchdb? can i replace it with protobuf bytes?
i found `chaincode` occupied 52.3% memory. does it mean chaincode has memory leak?
@bh4rtp not an authoritative answer, but I don't think you have that restriction. Non JSON data gets stored as attachments in couchdb [ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=wYAEizHSPktJ8WMXR) @bh4rtp
@thakkarparth007 but selector can not be used.
how to fix this error?
```error executing chaincode: failed to execute transaction: timeout expired while executing transaction```
there is no error log from chaincode container side.
http://hyperledger-fabric.readthedocs.io/en/latest/logging-control.html
"CORE_VM_DOCKER_ATTACHSTDOUT=true"
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=pukReFBaF8ybFpCmw) @bh4rtp
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=unvjh7jWTF6cPedsQ) @bh4rtp Not very familiar with this part.
Hi everyone, I got following messages from peer log, what could go wrong?
```peer1.org7.example.com | 2017-10-23 19:14:48.555 UTC [gossip/state] queueNewMessage -> WARN 461 Failed adding payload: Ledger height is at 628, cannot enqueue block with sequence of 1289
peer1.org7.example.com | 2017-10-23 19:14:48.555 UTC [gossip/state] queueNewMessage -> WARN 462 Failed adding payload: Ledger height is at 628, cannot enqueue block with sequence of 1288
peer1.org7.example.com | 2017-10-23 19:14:48.555 UTC [gossip/state] queueNewMessage -> WARN 463 Failed adding payload: Ledger height is at 628, cannot enqueue block with sequence of 1287
peer1.org7.example.com | 2017-10-23 19:14:48.556 UTC [gossip/state] queueNewMessage -> WARN 464 Failed adding payload: Ledger height is at 628, cannot enqueue block with sequence of 1290
peer0.org2.example.com | 2017-10-23 19:14:48.607 UTC [gossip/state] queueNewMessage -> WARN 44b Failed adding payload: Ledger height is at 696, cannot enqueue block with sequence of 1302
peer0.org2.example.com | 2017-10-23 19:14:48.609 UTC [gossip/state] queueNewMessage -> WARN 44c Failed adding payload: Ledger height is at 696, cannot enqueue block with sequence of 1304
peer0.org2.example.com | 2017-10-23 19:14:48.609 UTC [gossip/state] queueNewMessage -> WARN 44d Failed adding payload: Ledger height is at 696, cannot enqueue block with sequence of 1303```
@qizhang As those messages are from gossip, please post to #fabric-gossip
I'm planning to work on creating a "non locking transaction manager" implementation of txmgr.TxMgr (as opposed to the lock based one currently available) for experimenting storing the state on a database which supports transactions (and snapshot isolation level); has there been/is there any work in that area? Or am I just starting from scratch?
Has joined the channel.
@minollo Nothing exists yet, but I know that @manish-sethi has been thinking about design options. I'd suggest pass your ideas by Manish.
Can I use MongoDB or Mysql store state database instead of CouchDB, LevelDB ?
@minollo - unless you have any specific implementation in mind, I would encourage if you can implement this by leveraging the snapshot feature of leveldb and measure the initial performance benefits.
@ConConCop Chaincode programming model is based on key/value data model, therefore the state database needs to be key/value (or key/document where the 'document' can be considered the 'value). You can plug in other implementations for the key/value statedb interface, mongodb would be a good choice.
@ConConCop Chaincode programming model is based on key/value data model, therefore the state database needs to be key/value (or key/document where the 'document' can be considered the 'value). You can plug in other implementations for the key/value statedb interface, mongodb would be a good choice and look very similar to the couchdb impl.
@ConConCop Chaincode programming model is based on key/value data model, therefore the state database needs to be key/value (or key/document where the 'document' can be considered the 'value). You can plug in other implementations for the key/value statedb interface, mongodb would be a good choice and would look very similar to the couchdb impl.
Relational would require a SQL-based programming model. There is no support for this, but it would be possible in the future to add a SQL-based model. The transaction 'results' in the block would be different, but the general architecture, block structure, consensus model, etc would not change.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=YjvtXkNZb3au6if9D) @dave.enyeart There are ways to model key/value pairs in a relational database; it may (will) be less efficient than using a native key/value store, but it's surely possible to do it even keeping the current approach.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=dStEK6fGG9cSNyk24) @manish-sethi I think I will actually use Berkeley DB - which I also expect to be faster than LevelDB in general; and it does support transactions and snapshot isolation levels.
Thank @dave.enyeart , can you direct basic me how to implement mongoDB ?
@ConConCop You would follow the precedent of state couchdb: https://github.com/hyperledger/fabric/tree/master/core/ledger/kvledger/txmgmt/statedb/statecouchdb
which implements the VersionedDB (state db) interface: https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/statedb/statedb.go
ok, thank you :relaxed:
Has joined the channel.
@minollo yes, sure - as you feel comfortable. As a first step, you may like to integrate BDB under the current transaction manager (which should be simpler I believe and will iron out the integration issues for you). Then you can implement snapshot based approach using DBD's snapshots - This would also give us an apple to apple comparison of locking vs snapshotting benefits.
One of the decisions you would have to make is whether we should have a separate db for each channel or a shared db across channel. While the former approach has immense benefits (if possible with DBD), it was not easy to have 1000s of separate leveldbs because of combined resource requirements - primarily memory demand and number of open files etc.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ckXz5BDB7Wp9Whq2n) @manish-sethi Thanks; all good hints.
@minollo have you created a JIRA task for that?
@grapebaba No; mostly experimenting and POC-ing around at this point. But I'll report back my findings.
k
hi, the `json` value state retrieved from `couchdb` is sorted by alphabetic order according to json keys. how to avoid the sorting?
hi, the `json` value state retrieved from `couchdb` is sorted in alphabetic order according to json keys. how to avoid the sorting?
what type of query are you doing?
@bh4rtp what type of query are you doing?
@dave.enyeart i am using `stub.getState(key)`.
Has joined the channel.
I have a question regarding data hash. 1) is it the state data hash? 2) if so, how the data hash is calculated? is it a tree hash calculation, such as merkel tree as in bit coin?
Hi everyone, any thought on how to fix this error? `[gossip/state] commitBlock -> ERRO 16b Got error while committing(write /var/hyperledger/production/ledgersData/pvtdataStore/000001.log: no space left on device`
Hi everyone, any thought on how to fix this error?
`[gossip/state] commitBlock -> ERRO 16b Got error while committing(write /var/hyperledger/production/ledgersData/pvtdataStore/000001.log: no space left on device`
@qizhang seems like your host run out of disk space?
hi all, for `ORDERER_GENERAL_TLS_PRIVATEKEY=/etc/hyperledger/crypto/orderer/tls/server.key` and `ORDERER_GENERAL_TLS_CERTIFICATE=/etc/hyperledger/crypto/orderer/tls/server.crt` I can simply create a selfsigned ssl certificate for this and mount the specified volume directly, am I right?
Has joined the channel.
Has left the channel.
Hi,: Can we restrict clients from querying ledged-level apis? such as getTransactionInfo() and so on ?
@niteshsolanki within chaincode you can add any access control logic as needed
if you are talking about peer APIs in general, for the channel there is a reader and writer policy in 1.0, and there is work underway to make these policies more fine grained (down to specific APIs) in https://jira.hyperledger.org/browse/FAB-3621
Thanks @dave.enyeart
@dave.enyeart when i start the orderer by using ```go run orderer/main.go```
it show me the log
https://gist.github.com/asaningmaxchain/944dd98f98ac52f2b0c3ad28d2d340d1
in previous,it doesn't exists
it's ok?
can i debug my chaincode step by step? now i am using log to find the bugs, it is very slow.
@bh4rtp you can write tests and then use some IDE like IntelliJ to do the debugging
@Vadim thanks. is there any document describe how to build the test environments?
these are standard golang tests, you don't need any environments. As for example, check https://github.com/hyperledger/fabric/blob/master/examples/chaincode/go/chaincode_example02/chaincode_example02_test.go
you write the test file in a form "
ok. that's convenient. i used to run and stop frequently the network and watch the log...:blush:
@asaningmaxchain Those messages are ok, but I've opened a defect to suppress them:
@asaningmaxchain Those messages are ok, but I've opened a defect to suppress them: https://jira.hyperledger.org/browse/FAB-6853
@asaningmaxchain Those messages are ok in your scenario, I've opened a defect to suppress them when everything is ok, so that it doesn't confuse people: https://jira.hyperledger.org/browse/FAB-6853
Ledger index recovery messages were recently added to provide information when ledger index recovery process starts. Unfortunately these messages also show up in a new orderer with no data, since the index cannot be found for the system channel. These messages also show up each time a new channel is created in orderer. The messages are benign but confusing.
Ledger index recovery messages were recently added to provide information when ledger index recovery process starts. Unfortunately these messages also show up in a new orderer with no data, since the index cannot be found for the system channel. These messages also show up each time a new channel is created in orderer. The messages are benign but confusing and should be suppressed in these scenarios.
so this message shouldn't display?
@dave.enyeart can you provide some docs about the ledger how to build the index for each block
@asaningmaxchain those messages should be suppressed in this scenario (when everything is ok)
how to build index for each block: https://github.com/hyperledger/fabric/blob/release/common/ledger/blkstorage/fsblkstorage/blockindex.go#L92
@dave.enyeart thx
Has joined the channel.
hi, current block has a `previous_hash` field. does the previous block has a field which value is same as `previous_hash` of current block?
or if i want to check the hash of previous block is equal to `previous_hash` of current block, must i calculate the hash of previous block and then compare these two hashes?
@bh4rtp you must calculate hash of previous block
Does the peer use sync IO or async IO to commit blocks?
@dave.enyeart thanks. someone told me the previous block has the hash value, and i just tried to find it but could not. comfirmed! :blush:
@qizhang fsync is done upon block commit
@dave.enyeart fsync is done for every block commit?
yes
The purpose of doing this is for crash recovery?
yes, there are some investigations ongoing to determine if parts could safely be async and if that would help performance
there is block, block index, and state db that needs to remain in sync, so it becomes complex
Yeah, I am also interested in looking at this, can you point me to where the fsync is in the code?
please reach out to manish-sethi, he works on those details
Cool, thanks!
Has joined the channel.
@dave.enyeart does fabric also build transactions into a merkle tree like bitcoin? if yes, which field is the merkleroot hash?
@dave.enyeart What is the default value of grpc.max_send_message_length and grpc.max_receive_message_length for orderer and peers ?
@bh4rtp The Fabric use case does not require merkle hash. Rather the transactions from the BlockData are serialized all together and hashed to form the BlockHeader data_hash. Then the BlockHeader is hashed and is referenced in the next block's BlockHeader previous_hash
@niteshsolanki If I recall correctly it is 100MB in the code, and I think there is a work item to make them configurable
@dave.enyeart thanks
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ckXz5BDB7Wp9Whq2n) Hi @manish-sethi; is there a (set of) specific performance test(s) you would recommend for comparing a Berkeley DB State DB implementation against the LevelDB one?
@minollo - yes, there is a perf test suit that you can run to observe the performance at the ledger layer.
You can find this here https://github.com/hyperledger/fabric/tree/release/test/tools/LTE
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=bxrFdRqTSp8cME3v4) @manish-sethi OK, thanks.
Have you done the basic integration under the current tx mgr and want to see the diff between Level and Berkeley?
@minollo ^^^
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=yJowwLanC5BrDkJqA) @manish-sethi Almost; still working on some cleaning up a few things; but I'm getting close to the point where I will want to compare things, yes.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=yJowwLanC5BrDkJqA) @manish-sethi Almost; still working on some cleaning up a few things; but I'm getting close to the point where I will want to compare things, yes.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=yJowwLanC5BrDkJqA) @manish-sethi Almost; still working on cleaning up a few things; but I'm getting close to the point where I will want to compare things, yes.
@minollo - Cool, it would be interesting to see the results. So, did you chose to have a single BerkeleyDB for all the channels or separate instance for each channel?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=k9o6xw2iFXXReB5m4) @manish-sethi BDB supports the ability of having multiple databases mapped to a single file; so, I went down the path of associating an individual BDB database to each channel. I was actually wondering if it wouldn't be worth having one database per chaincode/namespace - I really dislike the idea of handling composite keys build with namespace+keyname; but that's not important for where I am now.
@minollo - OK, sure.
Has joined the channel.
i use go test to debug my chaincode. and it will tell `not implemented` when the chaincode calls `stub.GetQueryResult`. does this means `mock` can only simulate part of the shim?
i use go test to debug my chaincode. and it will tell `not implemented` when the chaincode calls `stub.GetQueryResult`. does this means `MockStub` can only simulate part of the `shim.ChaincodeStubInterface`?
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
anyone worked on combination of nodejs and couchdb?
i am trying to work marbles02 example in fabric-samples
1. in balance-transfer I have replaced chaincode with marbles02
2. changed docker-compose file with couchdb configuration
3. changed testAPIs.sh file with args
4. when i am running join peer request some times it's giving Error:file_exists, Status Code:412, Reason:The database could not be created, the file already exists
4.1. running the below commands to check DB , but it's not showning any database
docker run -p 5984:5984 -d couchdb
http://localhost:5984/_utils
4.2. I am unable to run invoke request's. It's saying like "message":"'peers' field is missing or Invalid in the request"
pls help me if u have any idea about that
Has joined the channel.
@rajasekharpippalla your last message is from the balance transfer sdk application. you cant mix sdk app for balance transfer with chaincode for marbles02
@dave.enyeart but I am getting issues
@rajasekharpippalla I think I know what could cause the couchdb error, I've opened a bug to protect against that: https://jira.hyperledger.org/browse/FAB-6938
@rajasekharpippalla I think I know what could cause the couchdb error, I've opened a bug to protect against that: https://jira.hyperledger.org/browse/FAB-6938 . Question, what is your environment? We've seen strange delays in couchdb when running on multiple layers of virtualization.
I use `requestBlocksInRange(1, 1)` to retrieve the starting block from another peer (let's assume the other peers' ledgers are correct for now). It seems that `requestBlocksInRange()` only retrieves a block, but not commit it. Thus we still need to do some work to write this block to the ledger. Is that correct?
Has left the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Wnait3tc8k2qHLPqg) @qizhang How you can use this function? E.g. this is a private method of the StateProvider...
@qizhang and yes this function only retrieves block, while it's being committed in separate go routine
@qizhang since this is gossip related topic I'd suggest to move discussion into #fabric-gossip
@C0rWin Sure, thanks!
Has joined the channel.
A block is usually committed with `private data`. Do you know what is `private data`?
A block is usually committed with `private data`. What is `private data` used for?
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=zm6AESha6RpJETEsa) @qizhang please take a look on FAB-1151 it explains about private data
Has joined the channel.
how we can implement privacy through channels?
Oracle ---->>> verification module
JPMorgan ---->>> verification module
1. Oracle as well as JPMorgan has done transactions with verfication module.
2. Now verification module can have information for both Oracle and JPMorgan.
3. Oracle should not have access for JPMorgan data and vice-versa.
How can we implement this kind of requirement? Can we implement this by using channels and how we can implement if we have any chances?
@rajasekharpippalla no need to repeat your question in parallel in separate channels, please avoid spamming
Do peers in the same ledger have exactly the same ledger file, in terms of each byte?
Do peers in the same ledger have exactly the same ledger file, in terms of each single byte?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ZvM6zZP8bWAw9rvDj) What if there is only 1 orderer?
@qizhang - I think that you meant "Do peers in the same channel...". Yes, they have same ledger file.
@manish-sethi do you mean fabric will not occur block chain branch like bitcoin?
Hi @dave.enyeart quick question: Is there any notion of batches in the peer code when it receives query ? I mean, will the peer maintain a queue of query requests before making a query to the leveldb ?
Hi @dave.enyeart quick question: Is there any notion of batches in the peer code when it receives query ? I mean, will the peer maintain a queue of query requests before making a query to the leveldb ? I noticed that when i make 2000 query requests per second, the difference between the first and last response is 0.3s. and if i make 100 query requests per second, the the difference between the first and last response is 30s.
@manish-sethi @dave.enyeart https://gist.github.com/asaningmaxchain/60dcbce2269e13baa35d91a25879098e can you take a look? when i want to test the stability about the peer
the couchdb seems reject the connection
@manish-sethi @qizhang - I don't think that's 100% correct.
The ordering service uses ECDSA signatures which are non-deterministic.
Which means, if you got your block from `nodeA` the blocks is different than if you got it from `nodeB`.
@adc @aso please feel free to correct me.
@manish-sethi @qizhang - I don't think that's 100% correct.
The ordering service uses ECDSA signatures which are non-deterministic.
Which means, if you got your block from `orderer0` the blocks is different than if you got it from `orderer1`.
@adc @aso please feel free to correct me.
Has joined the channel.
Has joined the channel.
@niteshsolanki That doesn't make sense to me. @muralisr could you explain the behavior when an endorser gets more proposals than it can process? What would constrain the concurrency?
@asaningmaxchain Please don't spam the same question to multiple channels.
that is weird indeed that he only does queries since the ledger obtains a read lock for simulations IIRC
are you sure you're doing only queries @asaningmaxchain ?
Perhaps you have also commits at the same time? Golang RWLock is very write-oriented and blocks pending readers as long as a writer is waiting for a lock
@dave.enyeart I am working on Ubuntu OS. Thanks for your Jira bug
@manish-sethi is CouchDB for State still supported as "beta" at this point, or has it moved beyond that?
@minollo We are not labeling it as a beta, but there are some important couchdb updates coming in 1.1 that I think any serious consumer would want to have (e.g. index support and performance).
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=3RvqwnniZEJgxShfJ) @dave.enyeart Got it; I was wondering when indexing would be exposed - considering you are exposing queries. Thanks!
Has joined the channel.
Hi All, I'm using an AWS Ubuntu 16.04 LTS following Hyperledger Fabric readthedocs tutorial. I followed steps in "Writing Your First Applications". When I ran "node enrollAdmin.js", a eCert and key material is expected to be generated in a hfc-key-store directory, but nothing is generated in this folder, which means the folder is still empty after running the command. I looked into the code in this js file, in lines 54-55, only two arguments are provided, but from the API from this link:https://jimthematrix.github.io/FabricCAClient.html#enroll__anchor, the fabric_ca_client.enroll function should receive three arguments, which means the third argument 'csr' is not given in the js file. Strangely, no error information is shown after running the command, and the only information i got from the terminal is "store path: $mypath/hfc-key-store".
Any one knows what the problem occurs?Thanks
Has left the channel.
@yunxi.zhang Please post in #fabric-sdk-node , that is where the node.js sdk experts familiar with the sample hang out
Has joined the channel.
Has joined the channel.
I have a network with 2 peers, I got the following error when I try `requestBlocksInRange(0,0)` on one peer to get the block 0 from another peer, please advise. Thanks!
```Error verifying block with sequence number 0, due to Failed to reach implicit threshold of 1 sub-policies, required 1 remaining```
I have a network with 2 peers in the same channel (peer0 nad peer1), I got the following error when I try `requestBlocksInRange(0,0)` on one peer to get the block 0 from another peer, please advise. Thanks!
```Error verifying block with sequence number 0, due to Failed to reach implicit threshold of 1 sub-policies, required 1 remaining```
I am thinking the block 0 on peer0 should be the same as the block 0 in peer1, thus when peer0 gets block0 from peer1, it should be able to pass all the verifications, but why it failed here?
@dave.enyeart, thanks for the response, have post this question in #fabric-sdk-node
Has left the channel.
Has joined the channel.
Hi..I wanted to check if my peer crashes then how much time does it take to sync with the other peers. To do that I stopped one of my peer and then deleted the `production` directory and the channel records entry from couch db. After restarting my peer, when I queried my chaincode, I get this:
Clipboard - November 20, 2017 5:31 PM
I am able to query the same asset in my other peer
I am able to query the same asset in my other peer. Could anybody please help. Thanks
I am able to query the same asset in my other peer. Could anybody please help. Thanks.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=FSwFMovnRaqEtiMh9) @dave.enyeart Could you please help.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=nkr5LPTo52wo3aFzu) @jarvis26 have you re-joined peer back to the channel?
yes
I mean the `peer channel join ...` command
yes
is this the only peer in the network?
I started the peer, joined the peer to the channel, installed the chaincode again and the issued the query commnd
you need somehow to delete the chain from the disk along with the DB
as I told you in #fabric
No this is not the only peer in the network
Clipboard - November 20, 2017 2:22 PM
this message is it part of your chaincode logic?
Yes, it will throw this when it is not able to fetch the asset .
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=xkgNoNj4KMRcAb7Ky) @yacovm yes, but as I mentioned I wanted to check a practical scenario that what happens if the peer actually crashes. How does it sync back up again? I am confused on the "somehow to delete the chain from the disk along with the DB"
let me ensure something
`/var/hyperledger/production`
this directory is deleted?
completely?
and after that you restarted the peer?
yes
hmm, and how many blocks did you have in the chain before that?
305
what do the peer logs say?
peerlogs posted here: `https://pastebin.com/551PNyQC`
ah I see
so... upgrade to v1.0.4
and you should be fine
oh...ok..i see
hmm, but -
try to restart the peer anyway
it should sync up
so this was a version specific error.
oh..ok..will try
I think you're experiencing https://gerrit.hyperledger.org/r/#/c/12495/
it is solved in 1.0.2
so either restart the peer or upgrade the version (which, involves too - restarting the peer)
ok..let me check by restarting the peer
If you just want to delete the ledger, then just remove /var/hyperledger/production/ledgersData/
Otherwise you'll also delete the installed chaincode
Upon bringing the peer up, do a re-join and it should then start pulling and processing blocks until it is caught up again
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=crokw7Ssp23JaGDqB) @yacovm I restarted the peer, still some records are recovered, others aren't
can you show the new logs?
yes, here: https://pastebin.com/Mmsn5nVb
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=As5JK5kRvTFMGNW3D) @dave.enyeart Ok.
@C0rWin , @dave.enyeart ideas? His blocks are synced now but still stuff are missing..
I've tested the same and the chaincode state recovers fine for me
Would need peer with CORE_LOGGING_LEVEL=DEBUG to see the state db commits
Changed the logging level to DEBUG
here are the peerlogs: https://pastebin.com/wYZvs3US
Has joined the channel.
Hi All, in the block details is there any attribute which tell how many transactions proposed
also am not able find current hash in any of the blocks, can you please help to understand why this is not present
Hi All, in the block details is there any attribute which tell how many transactions proposed
also am not able find current hash in any of the blocks, can you please help to understand why this is not present
Has joined the channel.
Has joined the channel.
@MadhavaReddy A block's hash is implicit - it is the hash of the block header. There is no need to make it an explicit field. If you need to verify the chain then you would want to derive the hash rather than trust a separate field.
The block data is an array of transactions. To determine how many transactions are in the block you would simply look at the length of the block data array.
The block data is an array of transactions. To determine how many transactions are in the block you would simply look at the size of the block data array.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=pwiQHEe8zi5Taikcn) @dave.enyeart Thank you, yes with the length.data was able to find number of transactions in a block
also i see a proposed hash in block data object, is this going to be the previous hash in next block, would like to know when this proposed hash going to converted into confirmed hash
@MadhavaReddy some context would help...where are you looking?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Pga6cfMyLq9yojZ4G) @dave.enyeart stopped the network, will share the block payload as soon as bring the network up
Has joined the channel.
Has joined the channel.
Hey! Is it correct that each peer needs an own couchdb instance?
1) Hey! Is it correct that each peer needs an own couchdb instance?
2) What is the best practice to join multiple peers to the same channel? Are you mounting the directory where where the mychannel.block is created to the host and using it for the other peers?
@hpurmann 1) yes 2) for development, I'd use whatever is convenient to do, for prod, I'd fetch the block from the orderer
You're the best, @Vadim! Always so quick and helpful. Thank you!
Has joined the channel.
How can I access BlockStore in gossip/state/state.go?
How can I access the functions in 'BlockStore interface' from gossip/state/state.go?
How can I access the functions in `BlockStore interface` from gossip/state/state.go?
Has joined the channel.
Has joined the channel.
Hi, please can someone explain how a transaction is send from one party and how other registered peer approve it and how a ledger is created from this ?
@Gulsharnsingh I'd suggest read https://hyperledger-fabric.readthedocs.io/en/release/txflow.html
Moved to #fabric-ledger
@dave.enyeart @mastersingh24 @muralisr
we are seeing a mismatch in the JSON document count on couch db. Our test involved restarting couch-db container few times during which Peer Container too went down at the time of commit operation.
This is on the fabric-v1.0.4 release.
I have the peer logs captured and would like to know if there is any additional information that may be required for analysis of this issue.
@rahulhegde I added next steps in your jira item: https://jira.hyperledger.org/browse/FAB-7156
I have added the statedb_savepoint detail in the JIRA, I have used node1/node2 to make it anonymous.
I have added the statedb_savepoint detail in the JIRA, I have used node1/node2 to make it anonymous.
We can talk on RC instead of JIRA and can capture the discussion in JIRA finally.
@dave.enyeart /\ /\
i'll free up later this afternoon. dump as much as you can in the jira and then i'll take a look when i free up
We are also trying to setup FTP access from CLS so u can receive this logs/information.
i'm trying to teach you how to review the debug by searching for the keys, and then summarize findings in the jira
Sure. If you want we can directly work on my webex in the afternoon.
and directly on that box - where we having this issue.
and directly on that box - where we are having this issue.
my day is greatly timesliced, which is why i recommend you pull together the debug findings before we talk
Okay - I will collect this information. Q - u mentioned that to take a diff between database - do u have any approach. I am planning to put down all keys-in files and find out the missing document.
However the statement `look in the Peer Logs ` - peer was run in INFO mode
How is that going to be helpful?
@rahulhegde you will need to re-run peer with debug mode if you want to understand how a certain state got that way.
I don't have an automated way to diff CouchDB databases yet, but it would be possible to write a REST client that steps through and compares the documents.
BTW - I think I found the block by using my approach.
@dave.enyeart
BTW - I think I found the block by using my approach.
@dave.enyeart please refer to the responses added to the FAB-7156
I got this error when trying to join a peer to a channel, how shall I fix it? Thanks!
`panic: Error while trying to open DB: resource temporarily unavailable`
Has joined the channel.
Has joined the channel.
I had a query about storing data in WS. As I have seen in Fauxton Console, the Keys are stored with CCNAME\0KEYNAME format. If I try to put the data programatically using the same Key format, can I read it from my chaincode? If No, then how is it secured? Can you explain? Any ideas @dave.enyeart ? Thanks.
Has joined the channel.
Has joined the channel.
Has joined the channel.
I have a question on the transaction data in transaction log history. In Fabric, the transaction data in each block is it just encoded or is it encrypted with digital signatures ?
@gauthampamu Fabric doesn't encrypt the transaction data by default, but as part of the app/chaincode you can decide if you want the data encrypted. v1.1.0-preview added chaincode APIs to make this easier for solutions. See http://hyperledger-fabric.readthedocs.io/en/v1.1.0-preview/chaincode4ade.html#chaincode-encryption
@ArnabChatterjee You cannot edit CouchDB data directly. If you did, your peer's chaincode execution would result in different results than other peers, and the transaction would be rejected.
hey all, working on testing out large volumes of transactions. currently trying to send 1500 transactions at a rate or 3 per/s to a chaincode, and getting the following error:
```2017-12-04 18:58:45.587 UTC [shim] handleGetQueryResult -> ERRO a898 [0477506d]Received ERROR
2017-12-04 18:58:45.587 UTC [volumeCC] Errorf -> ERRO a89a Failed: Post http://127.0.0.1:5984/volumeCC/_find: dial tcp 127.0.0.1:5984: socket: too many open files
```
not sure how to go about debugging this
it looks like it can't communicate with the couchDB instance because theres too many interactions with the db?
in the chaincode container i see this:
```2017-12-04 20:00:30.305 UTC [volumeCC] Errorf -> ERRO a116 Error adding factoring to ledger: [308bc16f]No ledger context for PUT_STATE. Sending ERROR
```
@jrosmith First, make sure that the queries have corresponding indexes, see https://github.com/hyperledger/fabric/blob/release/examples/chaincode/go/marbles02/marbles_chaincode.go#L39
Also check ulimit settings to handle "too many open files"
@dave.enyeart thank you! will look into this
@dave.enyeart as a follow up, do i need to increase the ulimit of the docker container since the chaincode is the one executing the query?
if the error is coming from couchdb side, then it needs to be resolved on couchdb side only
@dave.enyeart Why has https://jira.hyperledger.org/browse/FAB-2877 been rejected? It seems to be a sensible approach to expose statedb index management programmatically to the chaincode. If I understand it correctly, it looks like we are moving to configuration files taking care of that? (https://jira.hyperledger.org/browse/FAB-3067). Thanks.
@minollo I've added comments to FAB-3067:
@minollo I've added comments to FAB-2877:
Index creation is not a data transaction that needs to be ordered and recorded on chain. Rather it is a configuration that should be agreed to as part of the chaincode package, and applied once chaincode is installed and configured on a channel. Therefore indexes will be managed as part of chaincode lifecycle (FAB-3067) rather than as a data transaction. For some databases the indexes must be applied manually, which again is more aligned with chaincode lifecycle than a sequenced data transaction.
@dave.enyeart Hm; it looks like in general having some "DDL" side to a chaincode would be desirable; and I understand if that's detached from the code handling data. Still, if one day I have a statedb which supports SQL, the last thing I would want to do is to express indexes in a property file differently from the language that I (or my developers) already know how to use (SQL)... I also have the impression that at some point, similarly to how we want to let users control indexes, we will also want them to be able to (even if not being compelled to) declare types associated to keys used by chaincode; plenty of benefit in doing that... Anyway. thanks for the clarification.
@minollo I agree, if using a relational database the index definition in the chaincode install package would be in the form of a SQL DDL statement.
@minollo I agree, if using a relational database the index definition in the chaincode install package would be in the form of SQL DDL statements.
What does this error mean? Promise is rejected: Error: Failed to deserialize creator identity, err the supplied identity is not valid: x509: certificate signed by unknown authority
it means that the network does not have the CA which signed the identity among it's trusted roots in the config block
it means that the network does not have the CA which signed the identity among its trusted roots in the config block
Hi all . When new peer join an existing channel , I think they need to install chaincode . So when I try to install chaincode from peer terminal `peer chaincode install -n firstchaincode -v 1.0 -p firtchaincode` I am getting error ```Error: Error getting chaincode code chaincode:
@Vadim Ok thanks. I don't know what wrong i did but I could only resolve it by downloading fabric-samples fresh and then running the example.
Has joined the channel.
hey all, is there any way view the read/write sets for a given block? i've asked #fabric-peer-endorser-committer and #fabric-sdk-node and have been bumped here. i know i can't explicitly see it in the peer logs, and i've looked through the block events that get emitted and have not been able to access them. anything i can potentially do with couchDB to get this visibility?
@jrosmith I think you can use e.g. node-sdk to retrieve the block, it returns you a json where you can see rwsets
@Vadim that block is also emitted if i have a handler for block events, right? i stepped through that json for an invoke and found the property `ns_rwset` but it was an array of length 0
maybe try with channel.queryBlock if you see rwsets
maybe try with channel.queryBlock() if you see rwsets there
will do, thank you!
@jrosmith block events do nil out the rwset, but i believe from node sdk you can ask for a block and it will give you the full block including rwset. i'm sorry to bounce you around again but I think the folks in #fabric-sdk-node could explain how to get the rwset. Concerning CouchDB state db, it only keeps the CURRENT values for keys, while the block's rwsets have all historical writes recorded.
Has left the channel.
@dave.enyeart all good, i've set up a block explorer so i'll start stepping through the information there. thank you so much for your help!
Clipboard - December 9, 2017 2:48 AM
In the attached image above, I have run the first-network example. It launched the four peers and the orderer.
I cant understand the containers whose names are started with `dev` why they are launched as separate containers? i think they are for the chain codes but why separate containers than the original peer nodes?
Has joined the channel.
@muasif80 A separate Docker container is created for each version of a chaincode per peer. The *dev* in the name is the name of your Hyperledger Fabric network, which defaults to *dev*. Also, remember that you are not required to run your peer in a Docker container, you could run it as a native process on your OS. But chaincode always runs in a Docker container, unless you are in chaincode dev mode
@silliman Ok thanks.
Has joined the channel.
Has joined the channel.
Has joined the channel.
When we deploy a chain-code and perform some invokes (i.e. transactions), it stores some STATES and TRANSACTION-DATA on underlying distributed ledger.
Now if we modify the source code of the same chain-code and deploy it again, all the previously stored STATES and DATA are gone.
Please suggest us a way so that we can keep Chaincode separate from STATES and ledger DATA , so that any redeployment of Chaincode would not affect STATES and ledger DATA.
Any help would be
Best Regards.
When we deploy a chain-code and perform some invokes (i.e. transactions), it stores some STATES and TRANSACTION-DATA on underlying distributed ledger.
Now if we modify the source code of the same chain-code and deploy it again, all the previously stored STATES and DATA are gone.
Please suggest us a way so that we can keep Chaincode separate from STATES and ledger DATA , so that any redeployment of Chaincode would not affect STATES and ledger DATA.
We appreciate any help, clue.
Best Regards.
@SyneBlockChainTeam you need to upgrade the chaincode
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=wNXETdCAEBk7Bbozs) @Vadim
When we say upgradation of chaincode, does this mean.... redeployment of chaincode after some modification in its source code (the .go file).
If so, we loose out previous STATES and DATA whenever we redeploy it.
@SyneBlockChainTeam I mean if you want to preserve the state, you should use `peer chaincode upgrade` instead of `peer chaincode instantiate`
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=btHKEsLffqEXacB6j) @Vadim
great!!
thanks Vadim
@SyneBlockChainTeam the new chaincode should have the same name as the already deployed one, but different version
@SyneBlockChainTeam the new chaincode should have the same name as the already deployed one, but different version
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=4YGj4kWQCLgMiaXB6) @Vadim
oh I see, we will follow this approach. and this will save a big efforts... Thanks!!
@Vadim, there is one small query...
Can we share DATA between multiple channels ?
@SyneBlockChainTeam you can read data from one channel in one tx and write it to another channel in another tx
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=tiBYfeSqfcGsKYYfg) @Vadim
That means, if we are executing an API of a chaincode ( on Channel 1 ), from within that API we can not call another API of different chaincode ( Of Channel 2 )
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=tiBYfeSqfcGsKYYfg) @Vadim
That means, if we are executing an API of a chaincode ( on Channel 1 ), from within that API we can not call another API of different chaincode ( Of Channel 2 )
Here is a sample diagram of our scenario... (Please find attached)
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=tiBYfeSqfcGsKYYfg) @Vadim
That means, if we are executing an API of a chaincode ( on Channel 1 ), from within that API we can not call another API of different chaincode ( Of Channel 2 )
Here is a sample diagram of our scenario... (Please refer below attachment)
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=tiBYfeSqfcGsKYYfg) @Vadim
That means, if we are executing an API of a chaincode ( on Channel 1 ), from within that API we can not call another API of different chaincode ( Of Channel 2 )
Here is a sample diagram of our scenario... (Please refer attached image)
2 Channels with Multiple Orgs (Data Sharing).png
2 Channels with Multiple Orgs (Data Sharing).png
@SyneBlockChainTeam you can execute cross-channel queries, but not transactions that write data
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HrXPsbfe63Bxnopqo) @Vadim
oh, is there some standard way to achieve following scenario
CHANNEL1:
Buyer and Banker chaincode exists on CHANNEL1.
Buyer creates Loan record with *REQUESTED* status.
Banker reads this loan record and approves it, generate loan offer with *APPROVED* status.
CHANNEL2:
"Legal Person" chaincode exists on CHANNEL2.
Legal person should read the same loan from CHANNEL1, do some Inspection and verification. And finally change the status of loan as *TRANSFERRED* on CHANNEL1.
Please give some clue to achieve this scenario.
Thanks.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HrXPsbfe63Bxnopqo) @Vadim
oh, is there some standard way to achieve following scenario
CHANNEL1:
Buyer and Banker chaincode exists on CHANNEL1.
Buyer creates Loan record with *REQUESTED* status.
Banker reads this loan record and approves it, generates loan offer with *APPROVED* status.
CHANNEL2:
"Legal Person" chaincode exists on CHANNEL2.
Legal person should read the same loan from CHANNEL1, do some Inspection and verification. And finally change the status of loan as *TRANSFERRED* on CHANNEL1.
Please give some clue to achieve this scenario.
Thanks.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HrXPsbfe63Bxnopqo) @Vadim
oh, is there some standard way to achieve following scenario
CHANNEL1:
Buyer and Banker chaincode exists on CHANNEL1.
Buyer creates Loan record with *REQUESTED* status.
Banker reads this loan record and approves it, generates loan offer with *APPROVED* status.
CHANNEL2:
"Legal Person" chaincode exists on CHANNEL2.
Legal person should read the same loan from CHANNEL1, do some Inspection and verification. And finally change the status of loan as *TRANSFERRED* on CHANNEL1.
(This scenario is depicted in above diagram)
Please give some clue to achieve this scenario.
Thanks.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HrXPsbfe63Bxnopqo) @Vadim
oh, is there some standard way to achieve following scenario
CHANNEL1:
Buyer and Banker chaincode exists on CHANNEL1.
Buyer creates Loan record (e.g. LOAN0001) with *REQUESTED* status.
Banker reads this loan record LOAN0001 and approves it, generates loan offer with *APPROVED* status.
CHANNEL2:
"Legal Person" chaincode exists on CHANNEL2.
Legal person should read the same loan record LOAN0001 from CHANNEL1, do some Inspection and verification. And finally change the status of loan as *TRANSFERRED* on CHANNEL1.
(This scenario is depicted in above diagram)
Please give some clue to achieve this scenario.
Thanks.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HrXPsbfe63Bxnopqo) @Vadim
oh, is there some standard way to achieve following scenario
*CHANNEL1*:
Buyer and Banker chaincode exists on CHANNEL1.
Buyer creates Loan record (e.g. LOAN0001) with *REQUESTED* status.
Banker reads this loan record LOAN0001 and approves it, generates loan offer with *APPROVED* status.
*CHANNEL2*:
"Legal Person" chaincode exists on CHANNEL2.
Legal person should read the same loan record LOAN0001 from CHANNEL1, do some Inspection and verification. And finally change the status of loan as *TRANSFERRED* on CHANNEL1.
(This scenario is depicted in above diagram)
Please give some clue to achieve this scenario.
Thanks.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HrXPsbfe63Bxnopqo) @Vadim
oh, is there some standard way to achieve following scenario
*CHANNEL1*:
Buyer and Banker chaincode exists on CHANNEL1.
Buyer creates Loan record (e.g. LOAN0001) with *REQUESTED* status.
Banker reads this loan record LOAN0001 and approves it, generates loan offer with *APPROVED* status.
*CHANNEL2*:
"Legal Person" chaincode exists on CHANNEL2.
Legal person should read the same loan record LOAN0001 from CHANNEL1, do some Inspection and verification. And finally change the status of loan as *TRANSFERRED* on CHANNEL1.
(_This scenario is depicted in above diagram_)
Please give some clue to achieve this scenario.
Thanks.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HrXPsbfe63Bxnopqo) @Vadim
oh, is there some standard way to achieve following scenario
*CHANNEL1*:
Buyer and Banker chaincode exists on CHANNEL1.
Buyer creates Loan record (e.g. LOAN0001) with *REQUESTED* status.
Banker reads this loan record LOAN0001 and approves it, generates loan offer with *APPROVED* status.
*CHANNEL2*:
"Legal Person" chaincode exists on CHANNEL2.
Legal person should read the same loan record LOAN0001 from CHANNEL1, do some Inspection and verification. And finally change the status of loan as *TRANSFERRED* on CHANNEL1.
_This scenario is depicted in above diagram_
Please give some clue to achieve this scenario.
Thanks.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HrXPsbfe63Bxnopqo) @Vadim
oh, is there some standard way to achieve following scenario
*CHANNEL1*:
Buyer and Banker chaincode exists on CHANNEL1.
Buyer creates Loan record (e.g. LOAN0001) with *REQUESTED* status.
Banker reads this loan record LOAN0001 and approves it, generates loan offer with *APPROVED* status.
*CHANNEL2*:
"Legal Person" chaincode exists on CHANNEL2.
Legal person should read the same loan record LOAN0001 from CHANNEL1, do some Inspection and verification. And finally change the status of loan as *TRANSFERRED* on CHANNEL1.
( _This scenario is depicted in above diagram_ )
Please give some clue to achieve this scenario.
Thanks.
@SyneBlockChainTeam why do you need several channels in this scenario?
I [ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Hw6gbPEE8jGbuyGBC) @Vadim
To achieve the privatization of the data the legal should not see the Bank and Buyer loan data but can see the data specific to legal from the loan data.
I [ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Hw6gbPEE8jGbuyGBC) @Vadim
To achieve the privatization of the data the legal should not see the Bank and Buyer loan data but can see the data specific to legal from the loan data. But legal also need to modify loan data .
@SyneBlockChainTeam you said that the legal read the loan
this means that the legal is a part of channel1
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=YngipgEfyX24mHtFC) @Vadim legal is part of channel 2 and only have part of the data not whole loan
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ZJ3EFqADXhahcp96p) how does he read the loan from channel1 then?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=eA8SzPcrXf656voSc) @Vadim he can do through cross-channel queries
@SyneBlockChainTeam to be able to do cross-channel queries, he needs to be a part of both channels
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=aoNJDpkiKzWFERahG) @Vadim yes thats true in above case buyer is common in both channel
legal too if he reads from channel1
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=nwHKugYTtdYMeMWbR) @Vadim how to do privatization data ? if legal is part of the channel 1 he can see all the loan data
@SyneBlockChainTeam fabric is good with managed inter-org privacy, but what you want is hard to achieve using chancode-only, so you probably need to orchestrate the process from the client application... If you want a pure blockchain solution, I'd look towards Corda.
@SyneBlockChainTeam fabric is good with managing inter-org privacy, but what you want is hard to achieve using chancode-only, so you probably need to orchestrate the process from the client application... If you want a pure blockchain solution, I'd look towards Corda.
@SyneBlockChainTeam also, the sidedb feature of fabric might help you, but it's not available yet (should be in 1.1)
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has left the channel.
Has joined the channel.
Hi people. I am getting an error while sending concurrent invoke transactions in the peer container ``` 94805:2017-12-19 07:24:12.542 UTC [lscc] Invoke -> ERRO 1713c error getting chaincode mycc on channel: mychannel(err:transaction not found [f52ad62b]No ledger context for GetState. Sending ERROR) ```. I am using fabric v1.0 images with node SDK for v1.0. Any Ideas ? Thanks :)
Hi people. I am getting an error while sending concurrent invoke transactions in the peer container ``` 94805:2017-12-19 07:24:12.542 UTC [lscc] Invoke -> ERRO 1713c error getting chaincode mycc on channel: mychannel(err:transaction not found [f52ad62b]No ledger context for GetState. Sending ERROR) ```. I am using fabric v1.0 images with node SDK for v1.0. Any Ideas ? Thanks :) @Vadim
Hi people. I am getting an error while sending concurrent invoke transactions in the peer container ``` 94805:2017-12-19 07:24:12.542 UTC [lscc] Invoke -> ERRO 1713c error getting chaincode mycc on channel: mychannel(err:transaction not found [f52ad62b]No ledger context for GetState. Sending ERROR) ```. I am using fabric v1.0 images with node SDK for v1.0. Any Ideas @Vadim ? Thanks :)
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=DjrBStJG77ReqGzH5) @dave.enyeart Hi Dave, many thanks. So, the client code could review the endorsement results and detect any inconsistencies. If the client code does not check and submits the transaction with the bad endorsement, how do the committing peers determine that there is a bad endorsement. I was looking at the code here: https://github.com/hyperledger/fabric/blob/2cab745abf031d8ff5d3e8f4fa7a5e5af8907fad/core/common/validation/msgvalidation.go Thanks!!
@tennenjl At validation time, all peers check the N endorsement signatures against the endorsement data, and again, would detect if an endorsing peer's signature didn't match and would therefore invalidate the transaction.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=YCzshcZrb88wHaraM) @dave.enyeart Thanks, I was thinking about a scenario where the state db was tampered with for a specific peer, the peer doesn't know the data has been tampered with. It signs the request. The client doesn't check and then sends the signed response to the orderers.
yep, this will still be detected on all peers at validation time before the commit
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=bgAn9CpaN9dxqCscw) @dave.enyeart How does it detect that the write set is wrong?
the RW set is part of the endorsement data that is signed over, and per my prior comment each of the endorsing peer signatures would be checked. If one of the peers signed over different RW set, that is detected upon validation prior to commit.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=htuqqhgiLY3aXMedR) @dave.enyeart Thanks, just trying to determine where and how.
@tennenjl The N endorser signatures are checked here: https://github.com/hyperledger/fabric/blob/2cab745abf031d8ff5d3e8f4fa7a5e5af8907fad/core/scc/vscc/validator_onevalidsignature.go#L142-L148
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=iBnyKeG2hXhC7wZpm) @dave.enyeart If I understand that correctly it will check the number of signatures, which is a little different then what I am asking
It checks EACH of the signatures
It validates EACH of the signatures
It validates EACH of the signatures against the proposal response payload
It validates EACH of the endorser signatures against the proposal response payload
not just the number
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ZFDNopM7znk39FHAZ) @dave.enyeart Thank you so much, is there any specific lines I should look at. I can drill down a bit, but thanks a bunch for any pointers.
drill into deduplicateIdentity() function. you'll see that it builds a SignedData object for EACH of the endorsers
each of the SignedDatas will get evaluated in Evaluate()
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=odS7kCPQvFQuwayjY) @dave.enyeart Thanks!!! I will take a look. :beer:
Has joined the channel.
Hi, Could anyone please tell me whether the fabcar sample has implementation for the ledger(worldstate) also.Because at present whatever transactions i make like changing the car owner affects the couchdb only.So when is it getting validated and committed in ledger(the so called immutable storage)?
@DRSK what do you expect it should affect? The couchdb represents the world state, the ledger is the history of tx which is stored on the filesystem, in other words, history of changes to the world state. You have a possibility to check how the state identified by a certain key has been changing over time with stub.GetHistoryForKey()
Has joined the channel.
Has joined the channel.
@Vadim Hi,I have been going through the fabric documentation.It mentions about a stateDB to which all the transactions uncommitted transactions are stored temporarily. So how it is implemented in fabcar?
where did you see that statement?
@DRSK I have the same doubt.
@Vadim sorry i found it in edx hyperledger fabric tutorial.
here is the link to course page:
https://courses.edx.org/courses/course-v1:LinuxFoundationX+LFS171x+3T2017/courseware/f0db5224eb0e4bbb8cc1e93a6819012c/5ebddaca983d4d6d952e83f95ea9e281/?child=first
there is a state db with fabcar (or any other cc) uses, but it's not temporary. Perhaps there it's some implementation detail that they mentioned in that tutorial that I'm not aware of.
there is a state db which fabcar (or any other cc) uses, but it's not temporary. Perhaps there it's some implementation detail that they mentioned in that tutorial that I'm not aware of.
Here is the content and statements that confused me:
The current state data represents the latest values for all assets in the ledger. Since the current state represents all the committed transactions on the channel, it is sometimes referred to as world state.
Chaincode invocations execute transactions against the current state data. To make these chaincode interactions extremely efficient, the latest key/value pairs for each asset are stored in a state database. The state database is simply an indexed view into the chain’s committed transactions. It can therefore be regenerated from the chain at any time. The state database will automatically get recovered (or generated, if needed) upon peer startup, before new transactions are accepted. The default state database, LevelDB, can be replaced with CouchDB.
LevelDB is the default key/value state database for Hyperledger Fabric, and simply stores key/value pairs.
CouchDB is an alternative to LevelDB. Unlike LevelDB, CouchDB stores JSON objects. CouchDB is unique in that it supports keyed, composite, key range, and full data-rich queries.
Hyperledger Fabric’s LevelDB and CouchDB are very similar in their structure and function. Both LevelDB and CouchDB support core chaincode operations, such as getting and setting key assets, and querying based on these keys. With both, keys can be queried by range, and composite keys can be modeled to enable equivalence queries against multiple parameters. But, as a JSON document store, CouchDB additionally enables rich query against the chaincode data, when chaincode values (e.g. assets) are modeled as JSON data.
so where is the statement about " a stateDB to which all the transactions uncommitted transactions are stored temporarily. "?
@Vadim So, u mean there is just 2 things,
1) A *db* where data( committed / uncommitted until rollback) is stored,which can be a couch/level db
2) and a *ledger* ,ie just a log file to which all history of so far happened transactions are recorded?
Ledger is what that implements the main feature of block chain, i.e *immutability*?
1) yes, but there all data is always committed
2) I would not call it "just a log file" as it heavily oversimplified, but this is the blockchain data itself and immutability is a property of a blockchain.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=kHdYSPix8WDtBAcfB) @Vadim
so could you please tell how this ledger is actually implemented and made immutable in fabcar sample?
fabcar sample does not implement any ledger
so where can i find implementation for ledger.Because without it, isn't the sample meaningless as it doesn't exhibit the property of a block chain?
Fabric itself provides the ledger, not the chaincode or application layer. Every time you submit a transaction it gets added to the ledger.
For implementation, you can find it here:
https://github.com/hyperledger/fabric/blob/release/common/ledger/ledger_interface.go
https://github.com/hyperledger/fabric/blob/release/core/ledger/ledger_interface.go
'Common' ledger is shared between ordering service and peers
'Core' ledger extends it for peer-specific functions, for example to support chaincode operations.
So the endorsed transactions get added to which ledger: common / core / both ? Also, is it possible to view the ledger?
Both. Transactions that get submitted to ordering service get added to it's 'common' ledger, and then when peers receive the blocks from ordering service they are added to it's 'core' ledger.
The blockchain is a binary data structure on disk, there is a blockchain explorer to view the data: https://github.com/hyperledger/blockchain-explorer
@dave.enyeart Thanks a lot for such a descriptive response. I am very new to this and hence so many doubts which might be silly....
The document also says that once the ordering service sends blocks to peers they again does a re-validation. So it might be after that validation it gets added to the core ledger right? Just in case the validation fails, what will happen to the transactions already added to the common ledger?
Thanks a lot for such a descriptive response. I am very new to this and hence so many doubts which might be silly....
The document also says that once the ordering service sends blocks to peers they again does a re-validation. So it might be after that validation it gets added to the core ledger right? Just in case the validation fails, what will happen to the transactions already added to the common ledger?
Transactions that get invalidated remain on both orderer ledger and peer ledger, it's just that on the peer ledger there is also an indicator of which transactions got invalidated. The invalid transactions do not get applied to state database though, so they have no effect. You can read more details here: http://hyperledger-fabric.readthedocs.io/en/release/ledger.html
Has joined the channel.
not sure if this is the right place to bring this up or not, but i ran into an error while executing concurrent read-only queries against the statedb.
in my chaincode i have a function that first performs a `GetState` to check the status of an item in the stateDB, and if a condition is true it executes a more complex rich query with `GetQueryResult`. there are multiple status checks so instead of doing all of the checks synchronously in series i made a worker pool that immediately has a worker do the complex rich query when required and the other `GetState` checks can proceed.
in the case where more than one `GetQueryResult` task was dispatched to the pool i kept getting a `channel exists` error. i traced it down to https://github.com/hyperledger/fabric/blob/master/core/chaincode/shim/handler.go#L108. it looks like a specific transaction can only support one connection to the stateDB at a given time. this makes sense to me for actions that get inserted into the read/write set, but why can't we have concurrent connections to the stateDB for read only interactions?
@muralisr What do you think about jrosmith's question above?
@jrosmith if I understood correctly, you are attempting to optimize queries by executing several "GetXX" queries concurrently from the chaincode. This is not allowed (at least currently) stub.apicall(...) access has to be serial
Didn't we have that batch GetXX @muralisr ?
I heard someone added that
not sure @yacovm ... such a "batch" query would have to be relayed and executed directly in the ledger, Id think. From the CC Pov. it'll still be 1 GetXXX call
is that what you mean ?
I thought there was a change set
that supported several keys in the Get()
there was a JIRA proposal
ok
I saw a change set once
while I haven't seen someone implemented it
not sure if it was merged or not
it's not hard to implement, right? ;)
yep. Sounds like a relayed query
no, it's not a relayed
it's a batch
not saying it's hard
in the chaincode shim you mean
just saying it's not in the master
https://gerrit.hyperledger.org/r/#/c/13493/
here it is ^
Clipboard - December 21, 2017 12:13 AM
I know
looks like orphaned CR
Clipboard - December 21, 2017 12:14 AM
I can't see this tiny font
`ress, err := txContext.txsimulator.GetStateMultipleKeys(chaincodeID, keys)`
can you enlarge it please?
:joy:
zoom it
one set of keys is passed to the ledger....the compute is done there
Clipboard - December 20, 2017 5:16 PM
small enough for ya ? ;-)
OK all I am trying to say that it would make sense to have this ability, because currently - the `GetState(), wait for the state to get back to you` ping pong is unnecesserily slow.
sure
if we are doing multiple keys... AND know the keys apriori
and @jrosmith can use this ability
maybe
we usually know the keys apriori when we use getState, and when we don't, we use a ranged query, is that not so?
but definitely makes sense to include it ... seems the ledger supports multiple keys
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=2pXwQF9CfdEsnYqQD) @yacovm unless you have conditions in the code
right
right that's what I was thinkibg of
even so, its worth including
if you getState once and then the next GetState depends on the first, that doesn't work
yeap
but still it's good to have such capability
especially if some of the intelligence can be packed in the query
I also never understood the putState deal, @muralisr
why do we need to wait for putstate?
we can't read our writes
in the ledger's simulator
we can just send a put-state to the peer and continue the computation no?
we may want to know if putstte succeed or not
before proceeding
but you are not writing to DB
why would it fail?
good to be cautious in the CC
right...
exactly
who knows
you are just putting it in a buffer
if we remove putstate returning error from the ledger call, then sure, we canm think about that
as long as it can return errors we are bound to check
and percolate all the way upwards
it doesn't go to the ledger just yet
it just puts it into a map
or a slice
I meant the "ledger" compomnent call `err = txContext.txsimulator.SetState(chaincodeID, putState.Key, putState.Value)`
need to check out what is the error path there
it could be just an artifact
could be
still i like the simpliciy of serial request response ...enough confusion as is :-)
and then there is the the SetPrivateData ... which could be a different ball game ..but from the CC PoV is just another "set"
well, probably worth asking that guy whenever he minds to rebase his change set
looks pretty valuable one
I commented in the CR....
good
Hi. Is there any way I can visualize the blocks of the system chain? Thanks :)
Has joined the channel.
@yacovm @muralisr i apologizefor the lateness of my reply, busy holiday season for me.
so being able to get the state of multiple keys with `GetState()` would definitely speed up the process for me, but the real issue is trying to concurrently use `GetQueryResult()` for a query string using an index. for the workflow I am using `GetState()` either returns a value or returns nil, and if it returns nil I do not have to do the in depth indexed search with `GetQueryResult()`
Does "busy holiday season" mean busy with holiday or busy in working at holidays? :thinking:
@yacovm bit of both haha
so I don't understand what you're trying to say
i mean at the end of the day the workflow is less important than the fact that I want to be able to concurrently perform read only actions against the chaincode and thats currently not allowed
as I understand it a call to `GetQueryResult()` does not go into the read/write set, so if there's no risk of mutating the set I'm not sure why I can't perform more than one at once
because the chaindoe is written in a way that you can't do 2 things in the same time
the chaincode container processes only a single transaction in a given time
the chaincode container sends a peer a request to obtain data
and then waits for the result
and only afterwards, continues
@muralisr correct me if I'm wrong, of course
@jrosmith you can send concurrent requests TO the chaincode and but each state query (like GetState, PutState) for each of those requests FROM the chaincode have to be serial. This may be relaxed in future
@muralisr as i understand it `GetState` and `PutState` have to be serial because they're part of the read write set. is this correct? if so i guess i don't understand why `GetQueryResult()` has to abide by the same state query rules
@muralisr as i understand it `GetState` and `PutState` have to be serial because they're part of the read/write set. is this correct? if so i guess i don't understand why `GetQueryResult()` has to abide by the same state query rules
It doesn't have to be serial actually
since you don't read your own writes
they have to respectively serial though, right?
what do you mean
all GetState calls have to be serial with other GetStates, and all PutStates must be serial with other PutStates. but a GetState call does not need to be serial with a PutState call
what do you mean has to be serial with ?
@jrosmith since you are not reading your own updates but only saved state from previous commits, Gets will get the same value no matter what the order of execution is (assuming new commits haven't come in of course but that is a different conversaion). If you want to keep track of updated values, you have to do keep track of in the chaincode yourself. In that sense these calls could be made concurrent.
However, keeping the chaincode model simple and discouraging concurrency within the chaincode logic, goroutines etc have its own value IMO. In general we assume chaincodes to be lean and mean with not too many complications
@yacovm one GetState at a time with respect to other GetState calls, one PutState at a time with respect to other PutState calls. but since we do not read our own writes there is not specific order enforced for GetState calls with respect to PutState calls or vice versa.
@muralisr this makes sense, thank you
@yacovm one GetState at a time with respect to other GetState calls, one PutState at a time with respect to other PutState calls. but since we do not read our own writes there is no specific order enforced for GetState calls with respect to PutState calls or vice versa.
@muralisr this makes sense, thank you
Has left the channel.
I was trying the fabcar sample application of hyperledger fabric. But can anyone explain me the relevance of blockchain concept in this application context?
Has joined the channel.
@pb In Hyperledger Fabric you can model any asset in chaincode to track things like ownership and authenticity and provenance. In the fabcar example cars are modeled as assets and saved on the blockchain ledger (as 'tokens'). The example could just have easily been bonds or diamonds or artwork. The point is that with a blockchain the participants have a shared version of the truth that is indisputable. For example if the car in the real world was stolen and there is a dispute about ownership, the blockchain can be referenced to identify the true owner and lineage of prior owners. Or if there was a recall on cars created from a certain manufacturing plant, you could know with certainty which dealers or owners are impacted.
@dave.enyeart Thanks alot for such a descriptive reply.
But how to reference the blockchain to identify true owner and lineage of prior owners?
Genesis block:
"header": {
"number": {
"low": 0,
"high": 0,
"unsigned": true
},
"previous_hash": "",
"data_hash": "71a06e3f717210bc914be8de60f4994c45f11e21875433565895f165501282ee"
}..............
Next Block:
"header": {
"number": {
"low": 1,
"high": 0,
"unsigned": true
},
"previous_hash": "af2f6ff4cf91d3ca08d5d2d65682ad252b1e960e94d034191d8f97e62119b9d7",
"data_hash": "ee1267f9f94bd9b4faf7365f40cb1556425fb42497629e2ec59198b863cd3794"
}
This is from the output of running balance transfer example. Isn't the "previous_hash" of the block after genesis should have the same value as the data_hash of the genisis block??? Please clarify. Any help woulfd be of real help. Thanks.
@pb You can reference current owner and past owners by querying the ledger, there are chaincode APIs like GetState() and GetHistoryForKey() to do this.
The data hash is the hash of the data transactions in a block. It is added to the block header and then the header is hashed. This is the block hash that is referenced in the next block's previous_hash.
The data hash is the hash of the data transactions in a block. It is added to the block header and then the header is hashed. This is the block hash and is not visible when printed out. It is referenced in the next block's previous_hash.
@dave.enyeart Thanks a lot.... Now the doubt on Hash got cleared. Is there any means to do a trial for tampering history and prove block chain cannot be tampered. Mainly with the purpose of demonstrating the block chain core property.
Have anyone used getBlockByNumber?
@pb To clarify your question... the blockchain data on a single node can be tampered (e.g. if you are the admin on the machine you can alter the bytes on disk), the point is that the tampering would break the hash chain and therefore this node could not convince other nodes of the alternate history. A client can verify the integrity of the blockchain by checking the hashes. An example of such validation can be found here: https://gerrit.hyperledger.org/r/#/c/14545/
Many people have used GetBlockByNumber. I would suggest to use an SDK which makes the results straightforward. For example see https://fabric-sdk-node.github.io/Channel.html#queryBlock which calls GetBlockByNumber internally.
Has joined the channel.
Has joined the channel.
Has joined the channel.
@dave Thanks .I tried using queryBlock but the import
"github.com/hyperledger/fabric-sdk-go/third_party/github.com/hyperledger/fabric/protos/common"
Unable to do the above import.Package not found error is encountered.
Clipboard - 2018年1月3日下午1点03分
Bad Request
This is the part of output of query block function of fabcar sample. can anyone please say what these numbers stands for in the "data"?
"signature": {
"type": "Buffer",
"data": [48, 69, 2, 33, 0, 156, 104, 218, 222, 3, 33, 72, 128, 228, 248, 18, 82, 34, 196, 23, 13, 58, 248, 224, 41, 112, 29, 109, 117, 171, 189, 22, 40, 154, 210, 154, 147, 2, 32, 13, 135, 220, 196, 147, 164, 239, 117, 190, 120, 127, 30, 11, 66, 24, 85, 150, 121, 86, 192, 39, 240, 51, 104, 188, 211, 22, 207, 16, 180, 180, 239]
}
I believe it's a buffer in UTF-8 encoding
Has joined the channel.
Has joined the channel.
how multiple peers can be added to a single channel?
@here how multiple peers can be added to a single channel?
@yacovm Ok, shall check about that. Thanks
@DRSK you join those peers to a channel
@DRSK please avoid using "here" tag as there is no need to alert everyone in this channel. To your question, you just need to join those peers into the channel by using `peer channel join` command for each one of them.
in fact you can use something like: `CORE_PEER_ADDRESS=X.X.X.X:7051 peer channel join`, where you need to replace the X.X.X.X with proper IP address/hostname of the peer you would like to add to the channel
@guoger @C0rWin Thanks
@guoger @C0rWin Could spot that now in the sample. Thanks
In a committing peer, whether there is a separate chaincode for describing validation condition? How is validation implemented in fabric sample, say fabcar?
Has joined the channel.
@dave.enyeart when i use the PTE to test the performance i use the couchdb,i start the 50 thread to query,it tell the following error
```info: [PTE 0 main]: stderr: error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: make sure the chaincode sample_cc_ch1 has been successfully instantiated and try again: transaction not found Get http://couchdb2:5984/testorgschannel1/lscc%00sample_cc_ch1?attachments=true: dial tcp 172.22.0.5:5984: connect: cannot assign requested address```
Hi @dave.enyeart . Is there any limit on max. number of Chaincodes that can be deployed in the network ?
no
ok. any limit on max. no channel a peer can be part of ?
no
ok. when a Chaincode container is started, does tht run on some port ?
i'm not seeing any ports used by my chaincode docker containers
how does the peer communicates with the CC container ?
i'd suggest ask on one of the general channels, i'm not an expert in that area, i was answering from ledger perspective
ok. thanks @dave.enyeart
@dave.enyeart the ledger data compress?
@dave.enyeart the ledger data compress?and How much data is stored at most each time
@dave.enyeart the ledger data compress and How much data is stored at most each time
@dave.enyeart the ledger uses data compress and How much data is stored at most each time
@asaningmaxchain Ledger stores the data in a binary form but not compressed. You can compress at the file system level if you like. How much data depends entirely on your transactions. Number of transactions per block is configurable using orderer BatchTimeout and BatchSize.
so the fabric ledger module just save data in the fs?
It is described in docs here: https://hyperledger-fabric.readthedocs.io/en/release/ledger.html
@dave.enyeart the ledger support the pagination?
https://jira.hyperledger.org/browse/FAB-2809
For range queries, you can read as many results as you like before returning back to client, and then do another range query where the first left off. For CouchDB paging support is being added in https://jira.hyperledger.org/browse/FAB-2809.
For range queries, you can read as many results as you like before returning back to client, and then do another range query where the first left off. For CouchDB queries paging support is being added in https://jira.hyperledger.org/browse/FAB-2809.
Hi, I am not sure this is the right channel to ask this question. Please forward it to the apt channel if its inappropriate here.
I was https://github.com/hyperledger/fabric/blob/release/sampleconfig/configtx.yaml and I am not sure what is the significance of each field in this document. Is there any documentation that can clarify the use cases and functionalities of the configuration fields. For example :
1. In what cases should/can I omit creating a consortium
2. What are the differences between Orderer Org and consortium?
3. What is the significance of AdminPrincipal? ( I know its used in Endorsement Policy, but how is an Admin MSP superior that a Member)
Thank you very much.
Hi, I am not sure this is the right channel to ask this question. Please forward it to the apt channel if its inappropriate here.
I was going through https://github.com/hyperledger/fabric/blob/release/sampleconfig/configtx.yaml and I am not sure what is the significance of each field in this document. Is there any documentation that can clarify the use cases and functionalities of the configuration fields. For example :
1. In what cases should/can I omit creating a consortium
2. What are the differences between Orderer Org and consortium?
3. What is the significance of AdminPrincipal? ( I know its used in Endorsement Policy, but how is an Admin MSP superior that a Member)
Thank you very much.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
@dave.enyeart can you tell why has the history db?
@asaningmaxchain history db is used for storing the history of a particular key. For a key, it allows you to query for an ordered list of transactions that modified this key.
@manish-sethi let me take example , key1 -> value1,and modify key1 -> value2,so in the history db it contains the k1->(value1,value2)
so when i want to get the history for key1 it return the value1,value2
so when i want to get the history for key1 it return the value1,value2?
but the history db is very little,so i think it's just record the data index
but the history db is very little,so i think it's just record the data index for particular key
No, directly the end values are not stored in the history db.... a key in the history db is of the form of chaincodename_key_blknum_txNum and the value is actually nil
yes, you are right
the end value stored in the state db
Yes, but that for transaction processing, nothing to do historydb as such
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=BK8pDAA6Zhg6pPGhi) @manish-sethi when i modify the data,the txNum is modiy how do record the history
that would cause and additional entry into historydb
for each key/tx combination, there would be an entry in the historydb
so when i get the history for the key,it get all the like key in the historydb
yes
via a range scan
another question what's the content of the block
another question what's the content of the block,i know it store the transaction, so what's the content of the transaction
chaincodeAction?
lscc
[key: "mycc"
version {
block_num: 1
}
]
[]
mycc
[key: "a"
version {
block_num: 4
}
, key: "b"
version {
block_num: 4
}
]
[key: "a"
value: "60"
, key: "b"
value: "240"
]
```lscc
[key: "mycc"
version {
block_num: 1
}
]
[]
mycc
[key: "a"```
version {
block_num: 4
}
, key: "b"
version {
block_num: 4
}
]
[key: "a"
value: "60"
, key: "b"
value: "240"
]
Block has a whole lot of stuff... encourage you to look at proto structure for block/transaction
```message Block {
BlockHeader header = 1;
BlockData data = 2;
BlockMetadata metadata = 3;
}
// BlockHeader is the element of the block which forms the block chain
// The block header is hashed using the configured chain hashing algorithm
// over the ASN.1 encoding of the BlockHeader
message BlockHeader {
uint64 number = 1; // The position in the blockchain
bytes previous_hash = 2; // The hash of the previous block header
bytes data_hash = 3; // The hash of the BlockData, by MerkleTree
}
message BlockData {
repeated bytes data = 1;
}
message BlockMetadata {
repeated bytes metadata = 1;
}
```
it doesn't give the `BlockData` comment
@dave.enyeart @manish-sethi
yes, many places a comment should have been there.... I guess, for now, one way you can learn about this would be to follow a function that prepares a block / reads a block
you are right, i try it
Here is how we prepare basic block for ledger unit tests...https://github.com/hyperledger/fabric/blob/master/common/ledger/testutil/test_helper.go
Here is how we prepare basic block for ledger unit tests... https://github.com/hyperledger/fabric/blob/master/common/ledger/testutil/test_helper.go
@manish-sethi thx,i take a look
@manish-sethi @dave.enyeart i know it's envelope and i parse payload from it,so what's the content of the payload?
it's ChaincodeAction...
You may like to look at this function in the ledger code that we execute during block validation and commit...
this may answer some of your questions...
https://github.com/hyperledger/fabric/blob/master/core/ledger/kvledger/txmgmt/validator/valimpl/helper.go#L91
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=bkMmQG4CQPGRMaMeA) @manish-sethi no,it's signedTransaction
yes, i though that you were asking about the payload inside transaction...
If you follow the above function, you should be able to get the details of each layer...
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=d6Gzaa8r7E8u3FtCu) @manish-sethi you are right,so in the end,the block store the chaincodeAction
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=d6Gzaa8r7E8u3FtCu) @manish-sethi you are right,so in the end,the block store the chaincodeAction?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=d6Gzaa8r7E8u3FtCu) @manish-sethi you are right,so in the end,the block store the chaincodeAction?accurate say is TxRwSet
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=d6Gzaa8r7E8u3FtCu) @manish-sethi you are right,so in the end,the block store the chaincodeAction?more step is TxRwSet
```b.Txs = append(b.Txs, &valinternal.Transaction{IndexInBlock: txIndex, ID: chdr.TxId, RWSet: txRWSet})```
yes, from ledger point of view, this is the data of interest...
another question is when the client send tx to peer for endorsement,it simulate the chaincode,the statedb data takes effect,so when the peer commit the tx,find it invalid,how to do it?
another question is when the client send tx to peer for endorsement,it simulate the chaincode,the statedb data takes effect,so when the peer commit the tx,find it invalid,how to do it? @manish-sethi @dave.enyeart
another question is when the client send tx to peer for endorsement,it simulate the chaincode,the statedb data takes effect,so when the peer commit the tx,find it invalid,how to do it? what's the condition of the statedb @manish-sethi @dave.enyeart
the version of the data read during simulation should not have been changed by other committed transaction
Already committed transaction, could be in the same block...
preceding the transaction being validated
You may like to read a bit on "optimistic concurrency control" protocol for transaction processing...
i know the db exists the Optimistic Concurrency Control and Pessimistic Concurrency Control
the validation logic in OCC is what we follow here for marking a transaction valid/invalid
ok
ok,i got it
ok,i got it,you are so nice
Has joined the channel.
Has joined the channel.
@dave.enyeart I understand that Fabric 1.1 will have CouchDB performance improvements, is there an easy way to see what those will be and which, if any, were already included in the tech preview?
Can I manually edit the blockfile_000000 which holds the ledger data? I am testing a scenario where a hacker has gotten into one of the peer nodes and has messed the data. Can the block on that peer node recover when the next transaction/chaincode is executed on a good node.
@jdockter There are two main perf improvements for couchdb in 1.1:
1) bulk processing of transactions in the block. included in 1.1.0-preview.
2) ability to specify indexes that support queries, as part of chaincode metadata. recently added, will be documented in the next week.
Your mileage may vary, but you can expect an order of magnitude perf improvements with these
@udaykhambadkone If you tamper with a peer's block data, it will not be auto-fixed. You would need start the peer from fresh so that it can rebuild the blockchain from other peers. The point is, the tampered peer would not be able to convince other peers of the integrity of its data, therefore the network as a whole can not be compromised.
@dave.enyeart thanks for the explanation. I noticed that when I messed the blockfile_000000 which I believe is the genesis block, I could not restart that peer. using the docker command. It had to rebuild the blockchain by creating a genesis block first as you mentioned.
@dave.enyeart one more thing, where is the ledger stored on the peer node container? I could only locate the blockfile_000000. Is that also the ledger data. My setup has couchDB containers. What data is stored on the couchDB conatiners?
this topic will help set the context: https://hyperledger-fabric.readthedocs.io/en/release/ledger.html
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=9tgQKjA6gecYATr5o) @dave.enyeart Thanks!
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=JZmtd2At5hiiS4hxw) @dave.enyeart if one peer data is not complete,i can delete the ledger,and then i start peer,the peer will get the data from other peer
You would need start the peer from fresh so that it can rebuild the blockchain from other peers. The point is, the tampered peer would not be able to convince other peers of the integrity of its data, therefore the network as a whole can not be compromised.
Hi. Quick question: In C-C read call, is the key being read from callee chaincode part of Read set?
Hi. Quick question: In C-C read call, is the key being read from called chaincode part of Read set?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ZM5EMHvzhz9B7Loi4) @asaningmaxchain where is the ledger stored on the peer node container?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=cfDzvvNxHthBqrdCa) @udaykhambadkone you can find it in the sampleconfig/core.yaml
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=9YE3QD9raTtxrjZ3s) @niteshsolanki If it is C-C call on a single channel, yes. If it is C-C query across channels, no. This is because transactionality is scoped to a certain channel.
Ohk. Thanks @dave.enyeart for the response
If you tamper with a peer's block data, it will not be auto-fixed. You would need start the peer from fresh so that it can rebuild the blockchain from other peers. The point is, the tampered peer would not be able to convince other peers of the integrity of its data, therefore the network as a whole can not be compromised.
@dave.enyeart can you describe it more detail,starting with `The point is`
`the tampered peer would not be able to convince other peers of the integrity of its data, therefore the network as a whole can not be compromised.`
`the tampered peer would not be able to convince other peers of the integrity of its data` means the tampered peer doesn't believe the other peer ledger data?
Has joined the channel.
hello all im new to hyperledger,i want to store text document to couchdb and retreive hash code of that document using chaincode please help to me acheive that.
Has joined the channel.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=6Yaubx7PNfeeqdAAD) @asaningmaxchain This is what I have seen on my network and need help understanding as to how it is all working., Whenever I invoke a chaincode through the cli on a peer node. I can see the docker logs for that peer node writing data on its historyleveldb and pvtdataStore files. I am assuming this is part of the ledger data. In my test I made a local copy of those files. I then sent another invoke chaincode command to the same peer which changed the file size of the local files under *bold* /var/hyperledger/production/ledgersData/historyleveldb and /var/hyperledger/production/ledgersData/pvtdataStore *bold* I then copied over the earlier files from my local machine to the peer folders. Basically putting in stale copies of data. I then ran a 3rd invoke chaincode command as init (to add) and a 4th to read that data with no issues. Got results successfully. However I see that those files under the two folders in the peer node have stopped growing in size. Can you please explain? Thanks!
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=6Yaubx7PNfeeqdAAD) @asaningmaxchain This is what I have seen on my network and need help understanding as to how it is all working., Whenever I invoke a chaincode through the cli on a peer node. I can see the docker logs for that peer node writing data on its historyleveldb and pvtdataStore files. I am assuming this is part of the ledger data. In my test I made a local copy of those files. I then sent another invoke chaincode command to the same peer which changed the file size of the local files under * /var/hyperledger/production/ledgersData/historyleveldb and /var/hyperledger/production/ledgersData/pvtdataStore * I then copied over the earlier files from my local machine to the peer folders. Basically putting in stale copies of data. I then ran a 3rd invoke chaincode command as init (to add) and a 4th to read that data with no issues. Got results successfully. However I see that those files under the two folders in the peer node have stopped growing in size. Can you please explain? Thanks!
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=46P4yWr8LPtB6Zx6d) @asaningmaxchain I couldn't find the core.yaml. What is the exact location of it?
Does a peer check the integrity of its ledger when it restarts?
If a peer detects a broken ledger when it starts, will the peer crash or it will repair the ledger?
Has joined the channel.
depends how badly broken it is, but it will likely crash
Thanks @yacovm , another thing that I am wondering: if the client requests a transaction from a block, but the transaction is not available since the block is broken, how will Fabric behave?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=wfYpf5wxDxKM9jZGp) @udaykhambadkone https://github.com/hyperledger/fabric/blob/78e18d179c29e5182594a0fa27dc8d5accdb8ead/sampleconfig/core.yaml#L224
hello everyone please anyone help me to store an text document into database using chaincode.
@dave.enyeart what's the relationship between the ledger data and the couchdb,if i use the couchdb to store the world state
@qizhang i don't know, and I don't think this is an interesting question.
@qizhang Peer does not proactively check for corrupt/tampered blocks in its old history. Verification utilities can do that, and somebody has submitted such a utility that can be run within peer (https://gerrit.hyperledger.org/r/#/c/14545/). But if a client requests information from a block that is corrupt/tampered, peer will try to fetch that block and will hit an error reading the data and panic peer.
@asaningmaxchain relationship between ledger and state database is described here: https://hyperledger-fabric.readthedocs.io/en/release/ledger.html
@bingimanasa If you are using couchdb, then I assume your document is JSON. https://github.com/hyperledger/fabric/blob/release/examples/chaincode/go/marbles02/marbles_chaincode.go shows an example of storing JSON documents in chaincode to couchdb
If you are storing binary documents or only a hash of a document, then you are better off using the embedded leveldb.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=jARrS6KfZfXK5NXwC) @dave.enyeart The ledger is comprised of a blockchain (‘chain’) to store the immutable, sequenced record in blocks, as well as a state database to maintain current state.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=jARrS6KfZfXK5NXwC) @dave.enyeart The ledger is comprised of a blockchain (‘chain’) to store the immutable, sequenced record in blocks, as well as a state database to maintain current state. thx
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=atmCjT8RA4tuHh7i3) @asaningmaxchain Thank you
Has joined the channel.
Has joined the channel.
Has joined the channel.
AFAIK there is no mechanism to delete/remove chaincode or a channel. FAB-1149 addresses removing chaincode, but I'm not seeing a similar issue for removing/deleting a channel.
You are correct, @toddinpal .
It can be implemented, of course. However - Since Fabric is distributed this isn't very easy to implement, and there are many corner-cases
Hi,
I want to customize the response which I am receiving from Fabric invoke API after adding an asset to the ledger. DO we have any SDK available in the node which can help me returning a customize response in version1.1?
Has joined the channel.
How do we simulate delete of assets in fabric? Do we just keep a flag for deleted objects and check that when querying the couch db database?
@sampath06 `stub.DelState()`?
@Vadim that should work. Does using this mean that GetState will not return the instance and we lose the complete history of the object?
DelState() will delete it from state db. GetState() therefore won't return it anymore. But the history is still on the blockchain, and can be retrieved via GetHistoryForKey().
DelState() will delete it from state db. GetState() therefore won't return it anymore. But the full history of changes to the key is still on the blockchain, and can be retrieved via GetHistoryForKey().
DelState() will delete it from state db. GetState() therefore won't return it anymore. But the full history of changes to the key (including the delete transaction) is still on the blockchain, and can be retrieved via GetHistoryForKey().
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=JZmtd2At5hiiS4hxw) @dave.enyeart can you give more detail
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=JZmtd2At5hiiS4hxw) @dave.enyeart can you give more detail about it
the tampered peer how to know the data from other peer is believable
Perfect. Thanks.
@asaningmaxchain I guess the idea is that the client app will detect that the results from one peer differ from other peers, so the admin of that peer will be informed and will reset the peer, bringing it into the correct state
the admin of the peer how to get the information about it? in the client app how to do it?
@asaningmaxchain it's all happens out-of-band as I imagine
@asaningmaxchain it all happens out-of-band as I imagine
@dave.enyeart the couchdb support the pagination?
@dave.enyeart the couchdb support the pagination?and i see the http://docs.couchdb.org/en/2.0.0/couchapp/views/pagination.html#paging-alternate-method.
@dave.enyeart the couchdb support the pagination?and i see the http://docs.couchdb.org/en/2.0.0/couchapp/views/pagination.html#paging-alternate-method.so the current ledger support the `view`
Has joined the channel.
i am setting network for test, i set up 1 orderer and 3 peers, but, only one peer run, some body can help me?
Has joined the channel.
how to set primary key and foreign key in couch db?
hello, iam running marbles demo in my localhost ,iam adding marbles to an user they are showing in UI but they are not storing in database. How can i store to database. Please anyone help
Has joined the channel.
Has joined the channel.
Hello All, I was doing a load test on my application with Node SDK as the front end and CouchDB as World state. While doing it, I found that the getState takes about 10~15 times (approx) more than the putState operation. Although it is in milliseconds, I am still curious to know why is there such a big difference. I took the difference in times in the logs in the peer logs to obtain the result. Thank you. 🙂
@ArnabChatterjee yes, this is expected - because, `GetState` retrieves the data from couchdb which in turn accesses the disk (most likely, if not found in cache). On the other hand `PutState` keeps the data in peer memory (does not even go to couch) as the data is not yet committed and will be committed after serializing through orderer.
BTW, it will be helpful if you can publish your perf number along with the environment and chaincode details here, when you have these.
@manish-sethi - Thanks. And Sure. What kind of figures do you think would be helpful? TPS and Response times?
Yes, these two would be most important. In addition, if you are already collecting the resource usages (primarily, cpu, memory and disk io), they may give further hint of some bottlenecks.
Sure. Will post the figures shortly.
One of the preliminary and primary observations is, increasing the number of endorsement requests added to the degradation in performance. More the number of endorsement signatures required, slower is the transaction rate, although peer processes were underutilized. However, I was able to cope it up with by doubling the number of node processes and getting a better throughput (~1.5 - 1.7 times) and higher peer CPU utilization percentages.
Sure. Will post the figures shortly.
One of the preliminary and primary observations is, increasing the number of endorsement requests added to the degradation in performance. More the number of endorsement signatures required, slower is the transaction rate, although peer processes' CPU were underutilized. However, I was able to cope it up with by doubling the number of node processes and getting a better throughput (~1.5 - 1.7 times) and higher peer CPU utilization percentages.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=S9eY7fyf6HMjLEyMN) @manish-sethi - BTW can you explain to me about world state data caching? What kind of policies are used?
Are you referring to the cache that I mentioned in the context of `GetState` or keeping the data in memory during `PutState`?
Yes
There is no caching for GetState that we explicitly do on the peer side. I was referring to the caching on the couchdn side - filesystem cache to be more specific.
For PutState, caching would be a wrong word... all the data is just stored in a separate workspace for the transaction as it cannot be committed during endorsement.
Yes, Right, you only track it for preparing write-sets. BTW, any plans to implement caching later? As I found out, switching to either Couch or Level, doesn't make any significant difference in `GetState` times.
Ideally, there should be a measurable difference when you do `GetState` with level vs couch - unless, the higher layer (chaincode shim to peer communication layer) is bottleneck.
Okay. Any reason why leveldb is faster than Couch?
It's embedded and couchDB is a DB that uses an HTTP interface
i had done with marbles, output also perfect . Is it possible that i can link with my front end application with marbles?
@yacovm - Thanks. :)
Has joined the channel.
Hello, could someone give me hints on how to decode processed transaction envelope payload ?
Can someone help with a query of mine?
Dev Mode: Issuing the following command:
`peer chaincode invoke`
Can someone help with a query of mine?
Dev Mode: Issuing the following command:
`peer chaincode invoke` to add a new object using PUTSTATE
Result:
```2018-01-28 20:29:12.063 GST [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-01-28 20:29:12.063 GST [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-01-28 20:29:12.064 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2018-01-28 20:29:12.064 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2018-01-28 20:29:12.064 GST [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0A8E070A7A08031A0B08D8F4B7D30510...1A0E0A097175657279427949640A0131
2018-01-28 20:29:12.064 GST [msp/identity] Sign -> DEBU 006 Sign: digest: 5698229C083204D1BFFEAE5D3C4A4BD246AA99CC63E6F12C2DE178C50CD07F9D
2018-01-28 20:29:12.072 GST [msp/identity] Sign -> DEBU 007 Sign: plaintext: 0A8E070A7A08031A0B08D8F4B7D30510...B2720031A5B697752AE7652037641F57
2018-01-28 20:29:12.072 GST [msp/identity] Sign -> DEBU 008 Sign: digest: BA5B51709E04A537D27707B1E7997C86131E09D5EE0D64490BF27D30A01341C0
2018-01-28 20:29:12.073 GST [chaincodeCmd] chaincodeInvokeOrQuery -> DEBU 009 ESCC invoke result: version:1 response:
Result:
```CORE_PEER_MSPCONFIGPATH=/tts/official/src/tts/ubn/test/sampleconfig/peerOrganizations/adx.ubn.ae/users/Admin\@adx.ubn.ae/msp/ CORE_PEER_ADDRESS=peer0.adx.ubn.ae:7051 CORE_PEER_LOCALMSPID="AdxOrg" peer chaincode invoke -n AccountTransaction -v 0 -c '{"Args":["addNewItem","1","Admin@adx.ubn.ae","1","2018","1","20180128121212","XXYXX","YYXYY","AssetY","123456","100","1","1","1","0","0","First Trasnfer","0","0","First Hist Tr","First Hist Action"]}' -o 127.0.0.1:7050 -C adx-agm-channel
2018-01-28 20:28:20.704 GST [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-01-28 20:28:20.704 GST [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-01-28 20:28:20.705 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2018-01-28 20:28:20.705 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2018-01-28 20:28:20.705 GST [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0A8F070A7B08031A0C08A4F4B7D30510...69727374204869737420416374696F6E
2018-01-28 20:28:20.705 GST [msp/identity] Sign -> DEBU 006 Sign: digest: B6181CB87946DB6DE90E1A4630C94F5AD53C9AECDBBD94A296198CFF62910F51
2018-01-28 20:28:20.713 GST [msp/identity] Sign -> DEBU 007 Sign: plaintext: 0A8F070A7B08031A0C08A4F4B7D30510...3CF965940A997D8C3D73685EB41488D4
2018-01-28 20:28:20.713 GST [msp/identity] Sign -> DEBU 008 Sign: digest: C8E9A3B119AF79D3F652ED17A97513DF6B712AAB6517AB70293CB50CBE21BCEE
2018-01-28 20:28:20.714 GST [chaincodeCmd] chaincodeInvokeOrQuery -> DEBU 009 ESCC invoke result: version:1 response:
Result:
```CORE_PEER_MSPCONFIGPATH=/tts/official/src/tts/ubn/test/sampleconfig/peerOrganizations/adx.ubn.ae/users/Admin\@adx.ubn.ae/msp/ CORE_PEER_ADDRESS=peer0.adx.ubn.ae:7051 CORE_PEER_LOCALMSPID="AdxOrg" peer chaincode invoke -n AccountTransaction -v 0 -c '{"Args":["addNewItem","1","Admin@adx.ubn.ae","1","2018","1","20180128121212","XXYXX","YYXYY","AssetY","123456","100","1","1","1","0","0","First Trasnfer","0","0","First Hist Tr","First Hist Action"]}' -o 127.0.0.1:7050 -C adx-agm-channel```
And the result
```2018-01-28 20:28:20.704 GST [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-01-28 20:28:20.704 GST [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-01-28 20:28:20.705 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2018-01-28 20:28:20.705 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2018-01-28 20:28:20.705 GST [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0A8F070A7B08031A0C08A4F4B7D30510...69727374204869737420416374696F6E
2018-01-28 20:28:20.705 GST [msp/identity] Sign -> DEBU 006 Sign: digest: B6181CB87946DB6DE90E1A4630C94F5AD53C9AECDBBD94A296198CFF62910F51
2018-01-28 20:28:20.713 GST [msp/identity] Sign -> DEBU 007 Sign: plaintext: 0A8F070A7B08031A0C08A4F4B7D30510...3CF965940A997D8C3D73685EB41488D4
2018-01-28 20:28:20.713 GST [msp/identity] Sign -> DEBU 008 Sign: digest: C8E9A3B119AF79D3F652ED17A97513DF6B712AAB6517AB70293CB50CBE21BCEE
2018-01-28 20:28:20.714 GST [chaincodeCmd] chaincodeInvokeOrQuery -> DEBU 009 ESCC invoke result: version:1 response:
Result:
```CORE_PEER_MSPCONFIGPATH=/tts/official/src/tts/ubn/test/sampleconfig/peerOrganizations/adx.ubn.ae/users/Admin\@adx.ubn.ae/msp/ CORE_PEER_ADDRESS=peer0.adx.ubn.ae:7051 CORE_PEER_LOCALMSPID="AdxOrg" peer chaincode invoke -n AccountTransaction -v 0 -c '{"Args":["addNewItem","1","Admin@adx.ubn.ae","1","2018","1","20180128121212","XXYXX","YYXYY","AssetY","123456","100","1","1","1","0","0","First Trasnfer","0","0","First Hist Tr","First Hist Action"]}' -o 127.0.0.1:7050 -C adx-agm-channel```
And the result
```2018-01-28 20:28:20.704 GST [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-01-28 20:28:20.704 GST [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-01-28 20:28:20.705 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2018-01-28 20:28:20.705 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2018-01-28 20:28:20.705 GST [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0A8F070A7B08031A0C08A4F4B7D30510...69727374204869737420416374696F6E
2018-01-28 20:28:20.705 GST [msp/identity] Sign -> DEBU 006 Sign: digest: B6181CB87946DB6DE90E1A4630C94F5AD53C9AECDBBD94A296198CFF62910F51
2018-01-28 20:28:20.713 GST [msp/identity] Sign -> DEBU 007 Sign: plaintext: 0A8F070A7B08031A0C08A4F4B7D30510...3CF965940A997D8C3D73685EB41488D4
2018-01-28 20:28:20.713 GST [msp/identity] Sign -> DEBU 008 Sign: digest: C8E9A3B119AF79D3F652ED17A97513DF6B712AAB6517AB70293CB50CBE21BCEE
2018-01-28 20:28:20.714 GST [chaincodeCmd] chaincodeInvokeOrQuery -> DEBU 009 ESCC invoke result: version:1 response:
Result:
```CORE_PEER_MSPCONFIGPATH=/tts/official/src/tts/ubn/test/sampleconfig/peerOrganizations/adx.ubn.ae/users/Admin\@adx.ubn.ae/msp/ CORE_PEER_ADDRESS=peer0.adx.ubn.ae:7051 CORE_PEER_LOCALMSPID="AdxOrg" peer chaincode invoke -n AccountTransaction -v 0 -c '{"Args":["addNewItem","1","Admin@adx.ubn.ae","1","2018","1","20180128121212","XXYXX","YYXYY","AssetY","123456","100","1","1","1","0","0","First Trasnfer","0","0","First Hist Tr","First Hist Action"]}' -o 127.0.0.1:7050 -C adx-agm-channel```
```2018-01-28 20:28:20.704 GST [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-01-28 20:28:20.704 GST [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-01-28 20:28:20.705 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2018-01-28 20:28:20.705 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2018-01-28 20:28:20.705 GST [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0A8F070A7B08031A0C08A4F4B7D30510...69727374204869737420416374696F6E
2018-01-28 20:28:20.705 GST [msp/identity] Sign -> DEBU 006 Sign: digest: B6181CB87946DB6DE90E1A4630C94F5AD53C9AECDBBD94A296198CFF62910F51
2018-01-28 20:28:20.713 GST [msp/identity] Sign -> DEBU 007 Sign: plaintext: 0A8F070A7B08031A0C08A4F4B7D30510...3CF965940A997D8C3D73685EB41488D4
2018-01-28 20:28:20.713 GST [msp/identity] Sign -> DEBU 008 Sign: digest: C8E9A3B119AF79D3F652ED17A97513DF6B712AAB6517AB70293CB50CBE21BCEE
2018-01-28 20:28:20.714 GST [chaincodeCmd] chaincodeInvokeOrQuery -> DEBU 009 ESCC invoke result: version:1 response:
Result:
```CORE_PEER_MSPCONFIGPATH=/tts/official/src/tts/ubn/test/sampleconfig/peerOrganizations/adx.ubn.ae/users/Admin\@adx.ubn.ae/msp/ CORE_PEER_ADDRESS=peer0.adx.ubn.ae:7051 CORE_PEER_LOCALMSPID="AdxOrg" peer chaincode invoke -n AccountTransaction -v 0 -c '{"Args":["addNewItem","1","Admin@adx.ubn.ae","1","2018","1","20180128121212","XXYXX","YYXYY","AssetY","123456","100","1","1","1","0","0","First Trasnfer","0","0","First Hist Tr","First Hist Action"]}' -o 127.0.0.1:7050 -C adx-agm-channel
2018-01-28 20:28:20.704 GST [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-01-28 20:28:20.704 GST [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-01-28 20:28:20.705 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2018-01-28 20:28:20.705 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2018-01-28 20:28:20.705 GST [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0A8F070A7B08031A0C08A4F4B7D30510...69727374204869737420416374696F6E
2018-01-28 20:28:20.705 GST [msp/identity] Sign -> DEBU 006 Sign: digest: B6181CB87946DB6DE90E1A4630C94F5AD53C9AECDBBD94A296198CFF62910F51
2018-01-28 20:28:20.713 GST [msp/identity] Sign -> DEBU 007 Sign: plaintext: 0A8F070A7B08031A0C08A4F4B7D30510...3CF965940A997D8C3D73685EB41488D4
2018-01-28 20:28:20.713 GST [msp/identity] Sign -> DEBU 008 Sign: digest: C8E9A3B119AF79D3F652ED17A97513DF6B712AAB6517AB70293CB50CBE21BCEE
2018-01-28 20:28:20.714 GST [chaincodeCmd] chaincodeInvokeOrQuery -> DEBU 009 ESCC invoke result: version:1 response:
the code to read is to query the unique Id and give me the results:
`peer chaincode query`
```2018-01-28 20:29:27.687 GST [msp] GetLocalMSP -> DEBU 001 Returning existing local MSP
2018-01-28 20:29:27.687 GST [msp] GetDefaultSigningIdentity -> DEBU 002 Obtaining default signing identity
2018-01-28 20:29:27.687 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 003 Using default escc
2018-01-28 20:29:27.687 GST [chaincodeCmd] checkChaincodeCmdParams -> INFO 004 Using default vscc
2018-01-28 20:29:27.687 GST [msp/identity] Sign -> DEBU 005 Sign: plaintext: 0A8F070A7B08031A0C08E7F4B7D30510...1A0E0A097175657279427949640A0131
2018-01-28 20:29:27.687 GST [msp/identity] Sign -> DEBU 006 Sign: digest: A4EC1C1E8ED9FAC9260638316FCC08AA5A68F71F10D3DF0A47A1A1FF474EFFFB
Query Result: {"Message":"Not able to retrive Object Details...","Status":"ERROR","Contracts":null,"Size":"\u0000"}
2018-01-28 20:29:27.695 GST [main] main -> INFO 007 Exiting.....```
Is the ledger recoding my data? I am using couchdb as by state db. It also does not have any rows depicting this transaction.
So I doubt my ledger entries are not going through - I have an endorsement policy with either of 2 orgs (OR). And the user under which principal this is running is properly belonging to one of the orgs.
Log at my dev peer looks a bit fishy:
```2018-01-28 20:48:26.466 GST [vscc] deduplicateIdentity -> DEBU 16a3 Signature set is of size 1 out of 1 endorsement(s)
2018-01-28 20:48:26.466 GST [vscc] Invoke -> WARN 16a4 Endorsement policy failure for transaction txid=20381efa7ca0816f25e84630aeebb9cbe994e18c337ce9412b019954ab7ea381, err: Failed to authenticate policy```
It seems my endorsement policy is failing
Ok Resolved - the issue was with the endorsement policies. Once I corrected the right ORG and Members - all is fine now.
Has joined the channel.
Has joined the channel.
@dave.enyeart I'm using Fabric 1.1 preview and Composer configured with CouchDB...I've manually added CouchDB indexes for the asset I've modeled in Composer and that helps on queries for that asset....BUT after adding that index to CouchDB it seems to be effecting a query I have to a transaction registry (transaction defined via Composer) in the same CouchDB instance. With the index on it returns no data, with the index removed it returns data. Thoughts?
@dave.enyeart also...I see in the logs I see limit is set to 10000 and skip is set to 0, will we be able to override that in 1.1 GA?
@dave.enyeart also...I see in the logs that limit is set to 10000 and skip is set to 0, will we be able to override that in 1.1 GA?
Has joined the channel.
@here hey guys, anybody has the knowledge what's the best practise to build a currency (or something similar, I am actually looking for `awarding points` ) in fabric? I learnt from FAQ that MSP is needed to design digital tokens, and UTXO or account model is needed. But not sure where and how to start? Any sample network I can use? Thanks :)
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=LdC8h3vQfPfguWKtB) With reference to the mentioned post, I also found out that the broadcast from the orderer to the committing peers is relatively slow. The rate of creation of blocks in the orderer is not at par with the creation of blocks on the committing peers. I tried increasing the batchtimeout and maxmessages per transaction, but the gap does not seem to zero in. As as result, I am ending up with increasing the batch timeout, hampering my overall performance. Any pointers on this Fabric Experts? Thanks. @manish-sethi @mastersingh24
@HarryZhu please do not use [at]here, you are pinging the entire channel and sending an alert to every member across every time zone.
fabric is a private, permissioned blockchain. you can design an asset similar to a token if you'd like, but there are no coins required. there is no mining and no proof of work. i'd recommend taking a look at how transactions work in fabric here: https://hyperledger-fabric.readthedocs.io/en/latest/txflow.html
@jdockter I would not expect the existence of a couchdb index to negatively impact what gets returned in the query. At first glance it sounds like a CouchDB bug. Please document the minimal steps to reproduce the issue (ideally without fabric / composer dependencies so that it can be worked by CouchDB), and open a defect. I'd suggest to open against both CouchDB https://github.com/apache/couchdb/issues and Fabric https://jira.hyperledger.org/secure/Dashboard.jspa so that we can track it.
Concerning the query limit, it can be configured from the peer with CORE_LEDGER_STATE_COUCHDBCONFIG_QUERYLIMIT. There is also a Jira item in progress to add explicit paging control https://jira.hyperledger.org/browse/FAB-2809 , it is currently targeted for 1.2.
`skip` is not recommended or supported, as it results in iterating through all prior records in the database. Instead, CouchDB 2.1.1 has added efficient paging via `bookmark`. Fabric has just moved up to CouchDB 2.1.1, and this is intended to be used for the explicit paging.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=XyXYPA7qLZZG8Lonv) @ArnabChatterjee If you feel the order is the bottleneck in your set up, and want to get advice on different configurations to try out, I would suggest you posting the details on the channel `fabric-orderer`.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=XyXYPA7qLZZG8Lonv) @ArnabChatterjee If you feel that the order is the bottleneck in your set up, and want to get advice on different configurations to try out, I would suggest you posting the details on the channel `fabric-orderer`.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=LcYpdM8yFidnbggdD) @dave.enyeart thanks Dave
@jrosmith ahh.. sorry the alert from downunder:sweat_smile: sure, will pay special attential to that. Thanks for your answer, yeah, i don't need coin, but a token system. Just not sure what's the best practice to design that... This seems the only example i can goole out ATM: https://github.com/hyperledger-archives/fabric/tree/master/examples/chaincode/go/utxo :thinking:
@HarryZhu so when you say token system are you just trying to directly mimic bitcoin? or do you mean in the manner of PersonA has X tokens and transfers Y to PersonB who previously had 0. Now PersonA has X-Y tokens and PersonB has Y tokens?
@jrosmith not bitcoin, just like a points awarding system, you can either purchase points or accrue points via some events from a vendor, and use the points to purchase some services from the vendor later. Probably you also can transfer the points to somebody else.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Does transaction log and state data in fabric ledger uses seperate database like leveldb or couchdb ?
@MohammadObaid The transaction logs are stored in flat files on the peer file system. The World State uses either leveldb by default, or, optionally, CouchDB. There are also supporting indexes and databases to aid chaincode functions such as GetHistoryByKey that are stored in leveldb.
Has joined the channel.
Alright
Has joined the channel.
There is a channel named `channel1` in my network, but why `chains.list["channel1"]` data structure in `fabric/core/peer/peer.go` is `nil` ?
```
var chains = struct {
sync.RWMutex
list map[string]*chain
}{list: make(map[string]*chain)}
```
There is a channel named `channel1` in my network, but why `chains.list["channel1"]` data structure in `fabric/core/peer/peer.go` is `nil` ?
```var chains = struct {
sync.RWMutex
list map[string]*chain
}{list: make(map[string]*chain)}
```
@dave.enyeart @manish-sethi There is a channel named `channel1` in my network, but why `chains.list["channel1"]` data structure in `fabric/core/peer/peer.go` is `nil` ?
```var chains = struct {
sync.RWMutex
list map[string]*chain
}{list: make(map[string]*chain)}
```
@dave.enyeart @manish-sethi I started a Fabric network and ran some benchmarks, but it seems that the `func serve(args []string) error` in `core/peer/peer.go`has never been invoked. Can you please advise how this function is used? Thanks!
@dave.enyeart @manish-sethi I started a Fabric network and ran some benchmarks, but it seems that the `func serve(args []string) error` in `core/peer/node/start.go`has never been invoked. Can you please advise how this function is used? Thanks!
Has joined the channel.
we are looking to create a custom historian which shows all the details related to the transactions based on a particular assetId. Can someone help how can we do that. we have the api which shows just generic info in the history.
Hello, how to i can config system chaincode when build fabric?
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hello Everyone!
I would like to ask some question for my blockchain network.
I have some issues to clear data in blockchain.
Now, My network configuration is
1 orderer, 4 Kafaka and 1 zookeeper and 4 peers.
In peers, use the couchdb as state db.
I tried to clear block in blockchain (Becuase of a lot of testing data block).
Allow me to briefly steps to clean block (But It does not work).
1. Stop All peer.
2. I cleaned the file and folder under "/var/hyperledger/production/" of peer and
delete all file from couchDB (Run with docker, remove all files which linked folder with docker).
3. Then start again the peer service, there are still block and can query the old data.
But I does not work.
Am I miss something ?
Would all of you please help me ?
Hello, does anyone know how Fabric handles a blockchain growing very large in size? Is there a way to archive old, not actively needed blocks, e.g. moving the blockchain forward like a snake?
Hello Members,
May I confirm about one more thing.
According to my knowledge, (May wrong)
For a channel, ledger maintains the following three components:
Block Storage
- hash linked tamper-proof logs of ordered transactions
State Database
- current state of all keys
History Database
- past state of all keys
I am clear for "Block storage", and "State Database"
But, where is history database and how could i check it.
The SDK for hyperledger fabric also supprot the following API.
`GetHistoryForKey(namespace string, key string) (commonledger.ResultsIterator, error)`
Hello Members,
May I confirm about one more thing.
According to my knowledge, (May wrong)
For a channel, ledger maintains the following three components:
Block Storage
- hash linked tamper-proof logs of ordered transactions
State Database
- current state of all keys
History Database
- past state of all keys
I am clear for "Block storage", and "State Database"
But, where is history database and how could i check it.
The SDK for hyperledger fabric also supprot the following API.
`GetHistoryForKey(namespace string, key string) (commonledger.ResultsIterator, error)`
I would like to know the physical location of that History DB.
>Ref : https://blockchain-fabric.blogspot.com/2017/09/three-component-maintained-by-ledger-in.html
@PyiTheinKyaw Concerning your prior question, the orderer also stores blocks, you will need to clear blocks from orderer as well.
On the latter question, History Database is simply a leveldb index, storing the block height each time a key is modified. The actual historical value is persisted in the blockchain transaction writeset, not in the history database. Here are the contents of the ledger directories:
Content of
Has joined the channel.
Has joined the channel.
I was wondering if there was a possibility for participants in a channel to be limited to execute ONLY specific parts of the chaincode?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=PnoaPDyMe6FCvDj5K) @malama no, if this is the case you might need consider to split your chaincode
@malama within the chaincode you can check the submitters identity and make access control decisions, restricting them to certain actions/parts of the chaincode. For more details see:
http://hyperledger-fabric-ca.readthedocs.io/en/latest/users-guide.html#attribute-based-access-control
https://github.com/hyperledger/fabric/tree/master/core/chaincode/lib/cid
Has joined the channel.
Has joined the channel.
Hello Guys @here,
In my all of peers apper following logs,
What I was wrong.
I think data could not able to sync over "Gossip" protocol.
```
2018-02-13 08:27:39.437 MMT [gossip/state] queueNewMessage -> WARN 315 Failed adding payload: Ledger height is at 5704, cannot enqueue block with sequence of 200
2018-02-13 08:27:39.437 MMT [gossip/state] queueNewMessage -> WARN 316 Failed adding payload: Ledger height is at 5704, cannot enqueue block with sequence of 236
2018-02-13 08:27:39.437 MMT [gossip/state] queueNewMessage -> WARN 317 Failed adding payload: Ledger height is at 5704, cannot enqueue block with sequence of 189
2018-02-13 08:27:39.437 MMT [gossip/state] queueNewMessage -> WARN 318 Failed adding payload: Ledger height is at 5704, cannot enqueue block with sequence of 261
```
How could I able to solve it.
Any Idea ?
@PyiTheinKyaw Please do not use at-here, it is reserved for channel announcements.
I suggest you take post the gossip question on #fabric-gossip .
I suggest you post the gossip question on #fabric-gossip .
I see your same question on other channels as well, please do not post the same question on multiple channels.
Has joined the channel.
Has joined the channel.
@dave.enyeart Can you please help me out to backup and restore ledger data in case of failure?
Can anyone please help me out to backup ad restore ledger data in case of failure?
Can anyone please help me out to backup and restore ledger data in case of failure?
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hello Experts. Thanks for your support.
I wish to allow only read access to a given channel in the network. I think this can be done by setting the Channel's writer's policy. But I cannot find any specific procedure/examples to achieve this. Any ideas? Thanks. :)
Has joined the channel.
Hi, I checked the Fabric-FAQ.html of the document. Regarding Security & Access Control, it wrote that 'If you do not want the data to go through the orderers at all, and you are only concerned about the input data, then you can use visibility settings. The visibility setting will determine whether input and output chaincode data is included in the submitted transaction, versus just output data. ' Could anyone tell me where I can find the visibility settings?
@Wangrj There is something called transientMap in the proposal request. Whatever goes in the transientMap is invisible to orderer. For java SDK, here is an example -- https://jira.hyperledger.org/secure/attachment/14563/MultiDomainSampleV10.java Search for "Now do move of 100 units" to go directly to transientMap usage in this java file.
I am trying to setup up peers on different servers. How do they discover each other? Any bootstrapping needs to be done?
@sampath06 correct
but please ask the question in #fabric-gossip
your question is not relevant to ledger
Sure. Sorry about that
np
Has joined the channel.
https://sstone1.github.io/composer/tutorials/deploy-to-fabric-multi-org.html
https://hyperledger-fabric.readthedocs.io/en/release/build_network.html
which link shall i follow for setup?
Has joined the channel.
Does couchdb support `skip` and `limit` values? I noticed that there are a bunch of improvement in CouchDB, but this doesn't appear to have made it in :(
I'm getting RPC errors because the message size returned is too large. I only want it to return around 50 documents at a time, but it's try to send back all 175,000 of them...… This is massively inconvenient and I can't seem to find any way around it right now. Any help would be appreciated. Thanks
Does couchdb support `skip` and `limit` values? I noticed that there are a bunch of improvement in CouchDB in v1.1, but this doesn't appear to have made it in :(
I'm getting RPC errors because the message size returned is too large. I only want it to return around 50 documents at a time, but it's try to send back all 175,000 of them...… This is massively inconvenient and I can't seem to find any way around it right now. Any help would be appreciated. Thanks
Does couchdb support `skip` and `limit` values? I noticed that there are a bunch of improvement in CouchDB in v1.1, but this doesn't appear to have made it in :(
I'm getting RPC errors because the message size returned is too large. I only want it to return around 50 documents at a time, but it's trying to send back all 175,000 of them...… This is massively inconvenient and I can't seem to find any way around it right now. Any help would be appreciated. Thanks
I asked this question originally on #fabric-orderer, and I was asked to summarize it here - as it ended up being more of a ledger question. The original question was: "Is there ever a situation where I may end up with duplicates of the same txnId in the same or even different blocks - maybe as the result of submitting the same transaction twice through the same OSN, or at the same time through multiple OSNs?"; @kostas replies that "yes, that's indeed possible, and only the first validated instance of the same txnId would have a chance of being valid, the others would be marked as invalid" (which I personally find a bit odd, but, OK). The follow up question I asked @kostas and @manish-sethi was "then, how does the block index behave? What does getTransactionById(txnId) return if txnId was submitted multiple times?". @manish-sethi confirmed that subsequent submissions of the same txnId would be marked as invalid, but he was not sure about the behavior of the block index/getTransactionById() in that scenario; maybe it returns the last submission of the same txnId? (which I would think is the worst of all possible scenarios).
@minollo you are correct, this needs to be looked into. I suggest please open a Jira item. @manish-sethi could you look into it?
@pd93 `skip` is not an efficient way to do paging. couchdb 2.1.1 added an efficient approach to paging. fabric has recently moved up to couchdb 2.1.1 and will be exploiting the new paging capability. tagged for 1.2 currently: https://jira.hyperledger.org/browse/FAB-2809
in the meantime, the peer queryLimit config option is used to limit the number of results requested from couchdb.
@dave.enyeart Okay, thanks. This is definitely a priority feature for me.
presumably this has a corresponding env var I can use in my compose config?
yes, all of the core.yaml config options can be overridden with env variables: CORE_LEDGER_STATE_COUCHDBCONFIG_QUERYLIMIT
@dave.enyeart Thank you. Looking forward to 1.2 in the future
> (which I personally find a bit odd, but, OK)
@minollo: What makes this odd exactly?
I would expect the commit submission of a duplicate txnId to be rejected immediately - never even processed by the peer(s) for validation
It has no chances to ever be valid
I don't know the peer handles validation (and whether it exits early when it sees a duplicate tx), but I don't see anything in the original statement that excludes that possibility?
I don't know how the peer handles validation (and whether it exits early when it sees a duplicate tx), but I don't see anything in the original statement that excludes that possibility?
what I'm saying is that I wouldn't expect the duplicate txnId to even ever be propagated to the peers; the OSN knows whether the same txnId is already in Kafka pending commit or already committed, and it could return an immediate error, without going through the whole txn handling process
I suppose I'm also implying that I would like to never see duplicate txnIds in blocks
the OSN does not know if the original transaction got validated or invalidated
it doesn't matter
it knows it came first; subsequent ones will never be valid - based on logic and what @manish-sethi said
Why can't the first txid `foo` be invalid and the second one `valid`?
Why can't the first txid `foo` be invalid and the second one valid?
I'm assuming that I'm reusing the transaction identifier but, say, I didn't include all the endorsements the first time.
oh, different content, same txnId... really ugly
I suppose that's another good reason for *never* allowing a duplicate txnId to be accepted
...and now you've opened the door to a DoS attack.
@minollo - while I look into the code for this, as @dave.enyeart suggested, can you please open a jira and tag us there (or copy the jira link here).
@minollo: Assume you're sending txid `foo` to my endorsing peer. Before I send you my endorsement, I send another tx with the same txid to the ordering service. Now you're unable to send this transaction to the ordering service.
@kostas, yes, that's a legitimate concern.
We're working on those things (replay attacks, etc.) but the devil is in the details.
@kostas, yep, I understand. Still, I think that ending up with duplicate txnIds in the same channel at this point is more fundamentally dangerous.
@kostas, yep, I understand. Still, I think that ending up with duplicate txnIds in the same channel at this point is more fundamentally dangerous. ...and of course that's just my persona opinion...
@kostas, yep, I understand. Still, I think that ending up with duplicate txnIds in the same channel at this point is more fundamentally dangerous. ...and of course that's just my personal opinion...
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=yAhtQg7euwDgeezLF) @manish-sethi I think I did it: https://jira.hyperledger.org/browse/FAB-8557
Thanks @minollo
Has joined the channel.
@here What is Endorser, Committer & Consenters? What are their roles?
Has joined the channel.
I’m new here so not sure if this the correct channel so happy to be advised. My friend and myself want to use Fabric to set up blockchain to record the details of a diamond through the supply chain journey. Any initial guidance would be appreciated.
Hello Fellow Hyperledgers
@debutinfotech please do not use @ here. it pings every on the channel. you spammed several different channels, pinging over 5000 people overnight.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hello everyone. In a Hyperldeger fabirc, can I have peer nodes acting as clients? in other words each participant in the network needs to be a peer node as well?
Has joined the channel.
Has joined the channel.
I just upgraded my docker images to use the new version of fabric (`rc1`) and the base image (`0.4.6`) and brought my network up exactly the same as it was before.
I just upgraded my docker images to use the new version of fabric (`rc1`) and the base image (`0.4.6`) and brought my network up exactly the same as it was before.
My indexes get added, but when I run a query that uses one, I get a `no usable index` error
I just upgraded my docker images to use the new version of fabric (`rc1`) and the base image (`0.4.6`) and brought my network up exactly the same as it was before.
My indexes get added, but when I run a query that uses one, I get a `no usable index` error.
I see a few index related changes in the changelogs for `rc1`, but nothing stands out as related.
Running stuff on `alpha` still works.. either with `0.4.5` or `0.4.6` as the base image
I just upgraded my docker images to use the new version of fabric ( `rc1` ) and base image ( `0.4.6` ) and brought my network up exactly the same as it was before.
My indexes get added, but when I run a query that uses one, I get a `no usable index` error.
I see a few index related changes in the changelogs for `rc1`, but nothing stands out as related.
Running stuff on `alpha` still works.. either with `0.4.5` or `0.4.6` as the base image
you mean a couchdb index?
Yeah
the "data" envelope is no longer needed
Not sure what you're referring to by "data envelope", sorry
I have the JSON index files in a `META-INF/statedb/couchdb/indexes` folder with my chaincode
that's the only change i can think of that might break prior index definitions.... the json fields had to be pre-pended with "data." in alpha
Oh I see what you mean, sorry
That might be it, I'll check
@dave.enyeart Removing the `data.` envelope, as you suggested, fixed the issue. Thanks :)
I have a questions on private data. Is private data planned for v1.1. I have looked at the release note and I don't see the JIRA number 1151 in release note of v1.1.0-rc1. https://jira.hyperledger.org/browse/FAB-1151
@gauthampamu Private data is an experimental feature in 1.1: https://wiki.hyperledger.org/projects/fabric/proposedv1_1#experimental_features_-_not_to_be_included_in_v11_release_images_but_available_if_you_build_from_source_and_first_set_experimental_true_environment_variable
Has joined the channel.
dave.enyeart
mastersingh24
dave.enyeart
manish-sethi
Has joined the channel.
Has joined the channel.
Has joined the channel.
is PBFT supported
BFT support is in progress, for details please ask on #fabric-orderer
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has left the channel.
Is there any way to get the missed chaincode events for clients (in case of crash or connectivity dropped) ?
@guruce in 1.0.x you'll need to query the ledger's blocks to catch up on any missed events. Starting in 1.1 the event interface allows resuming the event flow at the last block event received. For details see http://hyperledger-fabric.readthedocs.io/en/latest/peer_event_services.html and https://fabric-sdk-node.github.io/tutorial-channel-events.html .
@dave.enyeart A follow up question to guruce's question. When the buffersize gets full, events are not published. Is there a way to increase the buffersize to accommodate more events in the buffer or increasing the timeout to more than 10s?
@neharprodduturi Based on the context, I'm guessing you're wondering if there's a way to change the buffer size or the timeout dynamically. Unfortunately, the peers must be restarted in order for the new values of the buffer size and timeout to take effect.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=DzA3HbDFwhQvKhrjo) @wlahti okay. Thank you
Has joined the channel.
hi, I asked the same question yesterday in #fabric-questions but did not get an answer there:
does fabric provide any protection against tampering with the couchdb database?
I trie**d the fabcar example, and after modifying the data in the database, queryCar returns the modified data, no error or warning about the changed data
I tried the fabcar example, and after modifying the data in the database, queryCar returns the modified data, no error or warning about the changed data
from what I understand from sawtooth, it uses a radix merkle tree, which should be tamper proof, but naturally that's a totally different thing than a couchdb
@papegaaij It is the endorsement policy that ensures the integrity of the blockchain data and protects against a bad peer (whether the LevelDB or CouchDB data was tampered/corrupted, or any other problem on peer). Fabric uses an endorsement policy where multiple peers must return the same results. If ledger data has been altered or corrupted (in CouchDB, LevelDB, file system) it will be detected the next time the data is accessed. Transactions require N endorsing peers to execute the chaincode, the transaction results (reads and writes) across these endorsers must match. If ledger data had been altered or corrupted on a peer then the transaction results would be inconsistent across endorsing peers, the 'bad' peer will be found out, and the application client can throw out the results from the bad peer before submitting the transaction for ordering/commit. If client application tries to submit a transaction with inconsistent endorsement regardless, this will be detected and the transaction will be invalidated by all peers at commit time.
If you are doing read-only queries rather than update transactions, then you can similarly query multiple endorsing peers and verify the results from each are consistent.
If there is doubt about state database integrity, the state database can be dropped and it will automatically get regenerated from the chain source of truth. If there is doubt about the chain integrity itself, then the peer itself will need to be rebuilt and the chain will be the transferred from another peer upon startup.
@dave.enyeart thank you for the very clear answer, this conforms to what I expected, and certainly is something we need to take into account in our own solution
Hi @dave.enyeart, regarding to FAB-8665 "Support golang plugin architecture for pluggable state databases", is there a schedule for this work? how would you design the interfaces? Expecting a design doc could be shared first, and willing to contribute
@luomin investigation has begun. We expect the interfaces to be similar to the existing VersionedDB interface that existing implementations compile in. @Senthil1 is working on this and may be able to provide additional update. I agree design should be documented in FAB-8665
@luomin investigation has begun. We expect the interfaces for key/value state databases to be similar to the existing VersionedDB interface that existing implementations compile in. @Senthil1 is working on this and may be able to provide additional update. I agree design should be documented in FAB-8665
@luomin investigation has begun. We expect the interfaces for key/value state databases to be similar to the existing VersionedDB interface that existing implementations compile in. @Senthil1 is working on this and may be able to provide additional update. I agree design should be documented in FAB-8665, and would appreciate your review and partnering with @Senthil1
@dave.enyeart Is there a way to run the experimental features on 1.1 (e.g. FAB-1151) without recompiling the peer node?
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
@luomin Will add an design doc in the JIRA
@sakoula To try FAB-1151 you must re-compile peer with EXPERIMENTAL=true setting
@Senthil1 Thank you very much. I will read the design doc when it is ready and willing to have a chance to work together with you on this task.
Has joined the channel.
Has left the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hi Team for Fab-1151 what is the blockToLive attribute for? Is that the block number where the hashed Pvt RW Set gets written to? Thanks!
@tennenjl blockToLive will enable automatic purging of private data after a certain number of blocks. Some use cases require this for very sensitive information. The hashes would live on indefinitely though, as long lived proof of the data. timeToLive would have been preferable, although there is no common time across the peers, therefore blockToLive is the next closest approximation for passage of time. The implementation behind blockToLive is not yet merged, and is targeted for 1.2.
this message will self destruct in 5 minutes... that kind of thing :)
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=KpfTNezBpJzJX6ALM) @dave.enyeart Thanks, that explains it :-)
@dave.enyeart This new feature I think can be a game changer. I speak with clients that ask me about the EU/Google right to be forgotten issue and at first glance this seems like the perfect fit.
that is exactly what it is intended for
that is a prime use case - exactly what it is intended for
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=vTK5S4dLccruyda8e) @dave.enyeart Could this also change the discussion regarding PII data (on the ledger as well)?
Fab-1151 limits data dissemination to those peers with a need to know, blockToLive purges the data after the need to know has passed. I certainly think that would fit with some PII use cases.
@dave.enyeart Thanks!
Is there a max limit for block size in fabric?
Has joined the channel.
I don't believe there is a limit for the block size per se, but you would likely bump into networking limits at some point. The first one you hit may be the grpc limit which I believe is still 100MB. @yacovm is this limit configurable now? Or could it become configurable?
it is 100MB, it is not configurable via core.yaml
it can, of course
there is also the physical limit - you may run out of memory if you try to marshal a too big message ;)
as for the block size - there is a heuristic
there is a block size that makes a block to be cut
but if a transaction is bigger than that, then it gets bigger
I mean, I thought there was a Jira already created to make the 100MB configurable. Do you know?
not that I know of... perhaps @mastersingh24 might know
by the way - @dave.enyeart , @DRSK - I think that the kafka system itself might also impose an external limit on the transaction size so that might result in a max size of the block.
(I hope I'm not wrong... @kostas or @jyellick can confirm)
found it: https://jira.hyperledger.org/browse/FAB-4461
there's a JIRA for it ..... most of the plumbing code is done ....
https://jira.hyperledger.org/browse/FAB-6461
(I have it on the 1.2 list)
@yacov is correct (though it applies to all ordering service implementations). A block can't be larger than `BatchSize.AbsoluteMaxBytes` (plus the header overhead, etc.) -- see: https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/configtx.yaml#L292..L309
@yacovm is correct (though it applies to all ordering service implementations). A block can't be larger than `BatchSize.AbsoluteMaxBytes` (plus the header overhead, etc.) -- see: https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/configtx.yaml#L292..L309
@yacovm is correct (though it applies to all ordering service implementations). A block can't be larger than `BatchSize.AbsoluteMaxBytes` (plus the header overhead, etc.) -- see: https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/configtx.yaml#L292..L309
@yacovm is correct (though it applies to all ordering service implementations). A block can't be larger than `BatchSize.AbsoluteMaxBytes` (plus the header overhead, etc.) — see: https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/configtx.yaml#L292..L309
@dave.enyeart @yacovm Thanks :thumbsup:
Has joined the channel.
Hi experts
Anyone here knows how do I explore a ledger from couchDB? I can see database names
But I am not able to see ledger.
Anyone have any idea?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=vJ4S2nmyocaTBGiGX) @TobiasN @jyellick @mikykey Please Look into this
Has joined the channel.
Has joined the channel.
@pankajcheema For ledger do you mean the chain of blocks?
@mikykey I am using this command ```root@1523063cad82:/opt/gopath/src/github.com/hyperledger/fabric/peer# curl couchdb:5984/_all_dbs```
inside a peer
and I am getting result of this command ```["_global_changes","_replicator","_users","channel1_","channel1_cc","channel1_lscc"]```
Do you know how can I open anyof these dbs?
@TobiasN @mikykey @jyellick @DarshanBc @yacovm @mastersingh24 Please reply if anyone know this or have any idea
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=YSgxqhtvTfioNysaE) @pankajcheema OK. wait. With this command you are accessin the state database and not the real chain of blocks. To acces the database it is better to use the following url http://localhost:5984/_utils where 5984 is the predefined port used by CouchDB and configured in docker-compose.yaml (further details at http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html at the end of the page)
(Example of docker-compose file: https://github.com/hyperledger/fabric/blob/13447bf5ead693f07285ce63a1903c5d0d25f096/examples/e2e_cli/docker-compose-couch.yaml)
On the contrary, if you are interested in retrieving the real blocks of the chain, you must access the single blocks, i.e. you can use the `peer channel fetch (number)`, where number is the block you are interested in (please refer to http://hyperledger-fabric.readthedocs.io/en/latest/peer-commands.html for details in the command)
@mikykey http://couchdb:5984/_utils this doesnot work in peer container
Its a GUI interface I think
@pankajcheema http://localhost:5984/channel1_
@pankajcheema I think the CouchDB API is documented quite short and to the point: http://docs.couchdb.org/en/2.1.1/api/index.html
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=PcwWmSP5yoGjmw6vn) @pankajcheema I always used it from the browser hosting machine! As an alternative I think you can do something like this, i.e. doing a query by using cURL from the docker container (https://stackoverflow.com/questions/23201920/couchdb-having-trouble-querying-by-a-specific-key-or-value)
Hi Everyone, For Fab-1151, would client data queries be treated differently? What determines if a client has access to data in the stateDB versus the privateStateDB? Thanks!
@tennenjl FAB-1151 only controls which org's peers can persist private data. For client access control you would build access control into chaincode logic like usual.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
How to use Side DB? Is there any examples in github regarding the same? If so, please give me the link to access it.
Has joined the channel.
@shivaganesh01 See https://jira.hyperledger.org/browse/FAB-6600 for sample and instructions
Thanks @dave.enyeart
Has joined the channel.
Has joined the channel.
@dave.enyeart can you tell me how to get latest block in a block file
i know it starts with the func (s *blockfileStream) nextBlockBytesAndPlacementInfo() ([]byte, *blockPlacementInfo, error) {
https://github.com/hyperledger/fabric/blob/09d508af677781f4a981d677efe4416dfa5a96ee/common/ledger/blkstorage/fsblkstorage/block_stream.go#L93
more extractly,i don't understand the following code
https://github.com/hyperledger/fabric/blob/09d508af677781f4a981d677efe4416dfa5a96ee/common/ledger/blkstorage/fsblkstorage/block_stream.go#L107
@dave.enyeart https://github.com/hyperledger/fabric/blob/09d508af677781f4a981d677efe4416dfa5a96ee/common/ledger/blkstorage/fsblkstorage/blockfile_mgr.go#L631 can you give more comment about the checkPointInfo struct
Has joined the channel.
@manish-sethi could you help with the question from @asaningmaxchain123
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=KSFXS4Hf3eQL55MMi) @asaningmaxchain123 - For reading the next block we need to know the length of the block bytes in the block file. So, we first read the length (say `l`) and then further `l` bytes (which are the actual block bytes).
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=pkfg2YKjta5x4P3uN) @asaningmaxchain123 - checkPointInfo is used to persist the last known good state of the last block file. It info this includes is such as block file number, length where last block in the file finishes... etc. This helps in detecting a situation whether the ledger is being started after a crash and the crash left a half written block in the tail of the file. So, this helps as an optimization in starting up the peer...
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=pkfg2YKjta5x4P3uN) @asaningmaxchain123 - checkPointInfo is used to persist the last known good state of the last block file. This includes info such as block file number, length where last block in the file finishes... etc. This helps in detecting a situation whether the ledger is being started after a crash and the crash left a half written block in the tail of the file. So, this helps as an optimization in starting up the peer...
@manish-sethi thx,but i have a new question, that is the if the a new block size larger than available bytes in the blockfile,so it will create a new blockfile and append new block to new blockfile
@manish-sethi thx,but i have a new question, that is the if the a new block size larger than available bytes in the blockfile,so it will create a new blockfile and append new block to new blockfile?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=s8TRQe2y8Mp3FRCS8) @manish-sethi when append a block to blockfile it will append the length of the block into the blockfile
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=fsumDquYknJo9RTxN) @manish-sethi yes,it the latest block is crash it will use the latest second block as the new checkpointinfo
@asaningmaxchain123 yes to both of your questions
@asaningmaxchain123 yes to third one as well :-)
Your are making my job easy to answer - i simply have to say 'yes' :-)
You are making my job easy to answer - I simply have to say 'yes' :-)
another question,the blockfile is 64M,but when i see https://github.com/hyperledger/fabric/blob/09d508af677781f4a981d677efe4416dfa5a96ee/common/ledger/blkstorage/fsblkstorage/blockfile_rw.go#L56
another question,the blockfile is 64M,but when i see https://github.com/hyperledger/fabric/blob/09d508af677781f4a981d677efe4416dfa5a96ee/common/ledger/blkstorage/fsblkstorage/blockfile_rw.go#L56 it doesn't assign the size of the file
another question,the blockfile is 64M,but when i see https://github.com/hyperledger/fabric/blob/09d508af677781f4a981d677efe4416dfa5a96ee/common/ledger/blkstorage/fsblkstorage/blockfile_rw.go#L56 it doesn't assign the size of the file？
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=3LFo58B3xj9i9gNak) @manish-sethi i see the source code,but i want to get more precise answer
about 64 MB question, the code you pointed out is just for opening the file. before appending the next block to the file, the size of the file is computed (if this block is to be appended)..
so can you tell where the source code？
https://github.com/hyperledger/fabric/blob/09d508af677781f4a981d677efe4416dfa5a96ee/common/ledger/blkstorage/fsblkstorage/blockfile_mgr.go#L268
i got it
i got it.thx a lot,another question, do test the performance about the write block
i got it.thx a lot,another question, do you test the performance about the write block
You mean that microbenchmark only for append the block function?
yes
No at this microbenchmark level. However, this is expected to be bounded by only your disk sequential write throughput...
Not at this microbenchmark level. However, this is expected to be bounded by only your disk sequential write throughput...
Feel free to do so and report the finding here. However, you would essentially be reporting your disk write throughput...
ok,if i have time,i will write the code to test the benchmark
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hi, I made a mess of my channel when I mixed up certificates as I added peers and anchor peers to my channel. Now, having rectified the certificate error, I need to add the peers accordingly to the channel however, I'm getting a "ledger id already exists" error. My understanding thus far of Fabric is that peers cannot be removed from a channel neither can channels be deleted. Please how can I delete the channel from the file system (/var/hyperledger/production) or is there some other way I can rectify my error?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=EbPuSnLysb7kcZHrP) Hello @dave.enyeart Please can you help?
Hi, if you have messed up your peer somehow, I recommend delete everything in /var/hyperledger/production and restart peer from scratch, re-join any channels that you like
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=bTFgxty3TtvCFbB3B) @dave.enyeart Thanks for that feedback. Does this imply that in a production system, should an error be made later in the life of a peer or peers and a new channel, we simply clear out the production folder of peer(s) and start again thereby losing data?
Yes, the data is replicated to all peers. The system is designed such that peers can be removed and added at any time. Upon starting a new peer and (re)joining channels, the blockchain will get synchronized to the new peer. It is recommended to have multiple peers per organization, so that if you need to rebuild a peer for whatever reason, you have no downtime.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=BucTYx4HpxwybAdsK) @dave.enyeart Yes, I get that however, it seems that in a case like mine where things got messed up in my 2 peers each in 2 organisations (the evils of copy and paste), one is left with no choice but to lose all data. Is that a correct?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=BucTYx4HpxwybAdsK) @dave.enyeart Yes, I get that however, it seems that in a case like mine where things got messed up in my 2 peers each in 2 organisations (the evils of copy and paste), one is left with no choice but to lose all data. Is that correct?
Has joined the channel.
If 4 of 4 peers are 'messed up' then you are pressing your luck. But I believe for now you will still be ok as you can bring up new peers and they will get blocks from ordering service and re-process the entire chain. There is intent to purge blocks from ordering service after a time, but I don't think anything is implemented around that yet. @kostas @jyellick do you see any issue rebuilding peers entirely from ordering service and not relying on peer-to-peer gossip at all?
@wbhagan you should be good to proceed as @dave.enyeart suggested, having the peer issue a Deliver request to the ordering service, starting from the oldest block on that channel. (Repeat per channel.)
Hello, I have the same problem with wbhagan, but I don't know how I can fix it
unsupported file3.png
I provided the debugs but I don't see any problem,do you know why I get 1 permission denied?
I tried to restart the channel but didn't work
unsupported file4.png
@magicianx25 are you signing with an admin user?
@jyellick how do i check
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Ul43stFon2NCHfqAij) Thank you @kostas and @dave.enyeart. I appreciate your assistance. Kind Regards.
@magicianx25 Your `core.yaml` has two variables `peer.mspconfigpath`and `peer.localmspid`. These may be overridden via `CORE_PEER_MSPCONFIGPATH` and `CORE_PEER_LOCALMSPID` respectively. If you look in the directory pointed to by the msp config path, you should see a `signercerts` folder, and an `admincerts`. There is likely one certificate in each, you should check that they are the same via a command like `md5sum $CORE_PEER_MSPCONFIGPATH/{admincerts,signercerts}/*`
If they differ, you are not using an admin cert. If they are the same, the most likely, your msp id is not being set correctly. You can look in the orderer log for more details.
@jyellick found my error thanks
peer no.png
why did you exit after docker exec -it cli bash?
Anyone knows how to open or read the data stored inside ledger?
@pankajcheema you can read block by qscc invocation, or refer to `hyperledger-explorer`, i.e. `blockchain-explorer`.
@bh4rtp what do you mean by qscc
I know something about vscc
@pankajcheema it is query scc, please see https://github.com/hyperledger/fabric/blob/13447bf5ead693f07285ce63a1903c5d0d25f096/core/scc/qscc/query.go.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ZaCLKLJRdRuHpiNcG) @manish-sethi so how to make sure the each blockfile is 64M? i don't understand
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ZaCLKLJRdRuHpiNcG) @manish-sethi so how to make sure the each blockfile is 64M? from source code,i don't understand
Has joined the channel.
Has left the channel.
@asaningmaxchain123 it would be better if you point out what you do not understand in the code?
@manish-sethi how to make sure each blockfile is 64M
@manish-sethi how to make sure each blockfile is 64M,if the currentOffset+totalBytesToAppend > 64M
@manish-sethi how to make sure each blockfile is 64M,if the currentOffset+totalBytesToAppend > 64M,i think the totalBytesToAppend will move next blockfile
Yes, this if condition does this
if the currentOffset+totalBytesToAppend > 64M,i think the totalBytesToAppend will move next blockfile?
if the currentOffset+totalBytesToAppend > 64M,i think the totalBytesToAppend will move next blockfile?plesse take a look https://github.com/hyperledger/fabric/blob/09d508af677781f4a981d677efe4416dfa5a96ee/common/ledger/blkstorage/fsblkstorage/blockfile_mgr.go#L268
`currentOffset+totalBytesToAppend > 64M` then the existing file is closed and a new file is opened
see the next line `mgr.moveToNextFile()`
hey everyone, i have two peers living on different servers that belong to the same org. i've submitted ~1k transactions and noticed that couchDB for both report the same BlockNumber, but their UpdateSeq's are different. i thought that since both peers are referencing the same ledger data the couchDB info should be identical, is this not true? or does this mean the world states for the two peers are different?
Has joined the channel.
@jrosmith updatesequence number and _rev numbers are metadata maintained by each couchdb instance independently. The world state in statedb are identical across multiple peers at the same height.
@jrosmith updatesequence number and _rev numbers are metadata maintained by each couchdb instance independently. The world state in ledger is identical across multiple peers at the same height.
Has joined the channel.
Has joined the channel.
Has joined the channel.
For getting history data, is this the only method provided *stub.GetHistoryForKey(args[0])* or there are any variants like if I want to get history of last 10 updates of the record?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=CoJAbXvyBX5cP4jKK) @manish-sethi thx,i know it means the blockfile can't exceed 64M,not extractly 64M
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=CoJAbXvyBX5cP4jKK) @manish-sethi thx,i got it means the blockfile can't exceed 64M,not extractly 64M
@asaningmaxchain123 - yes, one block resides in one file completely and is never split across files
@manish-sethi if the blockfile is in T level in capacity,the performance will rapid reduce
```T level in capacity``` -- what does this mean>
```T level in capacity``` what does this mean ?
the total capacity is 1000T
the total capacity is 1000T my english is bad
the total capacity is 1000T ,my english is bad
the total capacity is 1000T @manish-sethi @dave.enyeart
Hi, is there a way (maybe a `peer` command) to know what statedb, i.e couch or level, a peer is using?
@balaji.viswanathan thank you!
@AdnanC you'd have to look into peer config or peer log
it's mentioned early on in peer log at INFO level
at least, if using couchdb it is mentioned
Thanks @dave.enyeart
as part of the initial connection check
Not sure if I understand this comment. It would be helpful if you can elaborate this. @asaningmaxchain123 [ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=YNSp2TLsBs4Jy9cqv)
Has joined the channel.
Has joined the channel.
Where is the physical ledger file located on my Ubuntu peer node? I am looking for the exact file location. Thanks
also, has anyone tried to deploy a network using Fabric, with a very large number of private ledgers (1000s)? Did you face any issues?
Hello, I am trying to compile my chaincode using Go language but I get an error
5.png
Anyone knows what this means?
@SmartContract2018 ledger will be stored at location specified by this config option:
https://github.com/hyperledger/fabric/blob/release-1.1/sampleconfig/core.yaml#L297-L300
@magicianx25 please post chaincode dev issues in #fabric-chaincode-dev
Has joined the channel.
Hi,
Hi,
Chaincode invocations execute transactions against the current state data. If I want to only one asset with key "A" in blockchain, I should query state in my chaincode? Well, if I change state from outside?
Chaincode state is only updated when transactions commit. So the only way your state can update is through a chaincode transactions. Your chaincode should `GetState` for your key `A`, and, if it is nil, then you may safely create the new key. If two invocations do this concurrently, only one of them (the first one) will successfully commit.
Ok, I assume that we have 2 org and use couchdb as state database
@jyellick I understood. What happen if deletes the committed transaction from state for each peer? If i understand correctly, getState is nil and transaction committed again and new blocks created. I confused about immutability.
@mozkarakoc Yes, if you had three transaction, one which creates the key, another which deletes it, and another which creates it again, this would succeed. If you need for keys not to be re-uesd by your application, then you should simply not delete the key.
@jyellick But I can make CRUD operations at state database from outside. For example CocuchDb console. Is this a immutabilitiy problem? I don't understand why we need blocks, ledger? Only transaction history?
@mozkarakoc You must protect your DB from external update operations. This is critical. If you allow modifications from outside, then the immutability property is lost.
@mozkarakoc You must protect your DB from external update operations. This is critical. If you allow modifications from outside, then Fabric will be entirely broken.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=B6rjRuihhMQjmfF7M) @dave.enyeart Thanks Dave. However I do not have this directory under /opt. I am using the docker containers to run fabric (fabric-samples) and am afraid if it is creating files at a temporary location.
@jyellick If the state database update from outside, can I rebuild state from ledgers? If yes, how?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=q8vQiZSAkhCLyXFfx) @mozkarakoc I have the same question. Thanks
Sure, the peer owner could tamper with their own state database data (whether couchdb or leveldb data on disk), but there is no incentive to do so. It is the endorsement policy that ensures the integrity of the blockchain data and protects against these scenarios. Fabric uses an endorsement policy where peers from different orgs must return the same results for transactions to be validated. If ledger state data had been altered or corrupted (in CouchDB or LevelDB file system) on a peer, then the transaction results would be inconsistent across endorsing peers, the 'bad’ peer/org will be found out, and the application client can throw out the results from the bad peer/org before submitting the transaction for ordering/commit. If client application tries to submit a transaction with inconsistent endorsement regardless, this will be detected on all the peers at validation time and the transaction will be invalidated.
At any time you can stop peer, delete state database, and restart peer to rebuild state database. A state database that is missing or behind in block height will automatically get rebuild upon peer startup.
At any time you can stop peer, delete state database, and restart peer to rebuild state database. A state database that is missing or behind in block height will automatically get rebuilt from the blockchain upon peer startup.
@SmartContract2018 I also use fabric-samples to start docker containers. Here's where the ledger data is:
```# ls /var/hyperledger/production/
chaincodes ledgersData peer.pid transientStore```
@dave.enyeart thanks for satisfactory information. I need to playaround with these scenarios to fully understand. :) BTW, I know we can use AND/OR conditional operations. So, If there are organizations that do not trust each other chaincode policies must contains each peers of organizations. Can I use percent operations in endorsment policies?
@dave.enyeart thanks for satisfactory information. I need to play with these scenarios to fully understand. :)
I know we can use AND/OR conditional operations. If there are organizations that do not trust each other chaincode policies must contains each peers of organizations. This is good solution. Well, Can I use percent operations in endorsment policies?
@muralisr Is there a way to model endorsement policies such as "x% of channel members must endorse"? Or would that require custom vscc? FYI @aso is looking into default vscc (plugin) capabilities for next release...
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=yeoJ4qwipu9N3ipXF) @dave.enyeart Thanks Dave. I dug deeper and found that it is under overlay2 directory under /var/lib/docker, and then containerID and multiple levels down. My user does not have permission to that directory (only root). How do I run my script so that it goes directly under /var/hyperledger as you have mentioned. Is there any command to create a link for that location while running docker container?
I went into docker container with `docker exec -it peer0.org1.example.com bash`
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=izFtbXN8fMyGaTKF3) @dave.enyeart Thanks. That worked. One more question, if I may ask :-) I want to start a peer node on another VM connecting to the same network. I have never done this and any assistance will be appreciated. Thanks for the anticipated response.
https://chat.hyperledger.org/channel/fabric-ledger?msg=b5pWzSj7gkTJDnCpz
I don't think there's a way to express % today @dave.enyeart ... if things haven't changed when I wasn't paying attention :-) the best we can do is M-outof-N where the N principal identites are specified explicitly. Also the "outof" is not supported from CLI (currently) but I believe is supported by the SDKs
I don't think there's a way to express % today @dave.enyeart ... if things haven't changed when I wasn't paying attention :-) the best we can do is M-outof-N where the N identites are specified explicitly. Also the "outof" is not supported from CLI (currently) but I believe is supported by the SDKs
@muralisr How exactly to define M-outof-N? Is it documented?
the protos/common/policies.proto gives the protobuf specification which underlies everything.
let me check the SDKs
@SmartContract2018 I also have not deployed across VMs. Many people use cello project to deploy across VMs, it uses ansible scripts, there is a channel #cello
@dave.enyeart for node SDK https://fabric-sdk-node.github.io/global.html#PolicySpec
there maybe something more for Java but the README has some starters https://github.com/hyperledger/fabric-sdk-java
thanks murali!
https://chat.hyperledger.org/channel/fabric-ledger?msg=q8vQiZSAkhCLyXFfx
@mozkarakoc You may simply stop the peer, drop the DB, and start it again. The peer will rebuild the state db.
@jyellick while your here, can you look over my response on policies and double check please ?
@jyellick while you are here, can you look over my response on policies and double check please ?
> Also the "outof" is not supported from CLI (currently) but I believe is supported by the SDKs
Actually, it is supported by the CLI!
M-outof-N ?
Indeed
:-) glad I checked
https://github.com/hyperledger/fabric/blob/release-1.1/common/cauthdsl/policyparser_test.go#L30
ah good. that one slipped by
@dave.enyeart a correction to the policies comment.. M-outof-N *is* supported in CLI too
I'm using node sdk. That is perfect! Thanks everyone. :)
btw, I have a question about node sdk with kafka cluster in #fabric-sdk-node could you pls shoot a glance? @muralisr @jyellick
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=P7mHGcRmLaPGyoJBe) @dave.enyeart Thanks,
Has any one deployed fabric channels across multiple VMs? I need some help with how to configure my peers. Thanks
@SmartContract2018 the various samplles such as `examples/e2e` contain all the information needed to construct different types of network (docker, VM, etc...) . Each component in the docker compose files such as orderer, peer and ca are networked with their own IPs. The mechanics of seperating the properties for each of those components into the VM should all be required.
(and I followed that approach to set up a network in AWS .. although I did that manually and not using another tool like Cello which might make that process easier)
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=GjexAzwe8T3b9zejK) @muralisr Thanks. I will try that out.
Hi
Can anyone tell me,when does the validation of ledger across peers take place?
if hackers taking information illegally from bank(AXIS bank), if the project into fabrics. if the data is taken from 1 peer how the owner of the bank get notification that our bank information has been stolen? in blockchain/fabrics
Hi All
I have tampered the ledger file blockfile_000000
in my peers container's /var/hyperledger/production/ledgersData/chains/chains/mychannel location .And when i made a second transaction, i expected a erroneous log but instead it gave me a successful transaction.So i checked the ledger file content again but surprisingly the new transaction wasnt committed on the ledger .Have anyone of you noticed this?
Hi All
I have tampered the ledger file blockfile_000000
in my peers container's /var/hyperledger/production/ledgersData/chains/chains/mychannel location .And when i made a second transaction, i expected a erroneous log but instead it gave me a successful transaction.So i checked the ledger file content again but surprisingly the new transaction wasnt committed on the ledger .Have anyone of you noticed this? @dave.enyeart
Has joined the channel.
@pb ordering service consensus defines the sequence of transactions in blocks. Then peers process those blocks and each (deterministically) identify which transactions are valid/invalid
@ammu In an permissioned blockchain you must follow enterprise security standards to ensure unauthorized clients (hackers) do not get your data.
@Ammu In an permissioned blockchain you must follow enterprise security standards to ensure unauthorized clients (hackers) do not get your data.
@pb That doesn't make sense to me, and I have not seen that, successful and validated transactions get posted to ledger state database. peer debug (CORE_LOGGING_LEVEL=DEBUG) will help demonstrate if the tran was validated and posted to state database.
Has joined the channel.
@pb this depends how you tempered the file and how you are observing the change to the file. Did you delete the partial contents towards the end of the file? For observing the change, did you reopen the file? If both of the above is true, can you make sure that you actually see the file till end... or simply see the size of the file before and after submitting your second tran
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=bqiHXFxoTI7vgIXuZO) @manish-sethi
Yes i made changes to the data of the last successfully committed transaction and reopened the file to ensure that the changes i made reflected the file .How is this possible that the subsequent transactions are not getting committed on to the tampered ledger file without even a single error message or failure alert?
I do always check the file contents and not size.
Hi!
In the Fabric FAQ, its said, under "How do I ensure data privacy?" , one of the points is "ledger data at rest can be encrypted via file system encryption on the peer."
How is this done
Hi!
In the Fabric FAQ, its said, under "How do I ensure data privacy?" , one of the points is "ledger data at rest can be encrypted via file system encryption on the peer."
How is this done?
Hi!
In the Fabric FAQ, under "How do I ensure data privacy?" , one of the points is "ledger data at rest can be encrypted via file system encryption on the peer."
How is this done?
@amolpednekar There are many options for whole disk encryption: https://en.wikipedia.org/wiki/Comparison_of_disk_encryption_software
Ah, alright! I thought there was some fabric specific config which allowed this. Thanks.
Has joined the channel.
@pb based on what you confirmed above, the behavior you are noticing is a side-effect of writing concurrently on the same file by more than one processes - 1) the peer process and 2) your editor. This is how many file systems behave. You would notice the similar behavior even if you open two instance of vi and try to manipulate the same file from both concurrently. Only concurrent append is well defined in the posix spec. For instance, if you would have appended something to the file (echo 'this is just for fun' >> blk_0000) instead of modifying you would have seen the new transaction entry (Or if you would have stopped the peer process before modifying....). BTW, even if you would deleted this file (instead of modifying the file) the running peer would not notice that on most filesystems.
https://www.unix.com/man-page/posix/3P/WRITE/ -- search for 'concurrent writes'
@pb based on what you confirmed above, the behavior you are noticing is a side-effect of writing concurrently on the same file by more than one processes - 1) the peer process and 2) your editor. This is how many file systems behave. You would notice the similar behavior even if you open two instance of vi and try to manipulate the same file from both concurrently. Only concurrent append is well defined in the posix spec. For instance, if you would have appended something to the file (echo 'this is just for fun' >> blk_0000) instead of modifying you would have seen the new transaction entry (Or if you would have stopped the peer process before modifying....). BTW, even if you would have deleted this file (instead of modifying the file) the running peer would not notice that on most filesystems.
https://www.unix.com/man-page/posix/3P/WRITE/ -- search for 'concurrent writes'
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=GCDQ6arZB5biu5N5k) @manish-sethi
*BTW, even if you would have deleted this file (instead of modifying the file) the running peer would not notice that on most filesystems. *
I have tried deleting the ledger in the peer and when i made transactions, the transactions were successfully committed in all other peers but the ledger file blockfile_000000 was not recreated in the peer from which i deleted .
Has joined the channel.
@pb yes, that's what I was trying to explain. In most of the filesystems you would notice the similar behavior. You may want to go through this stackexchange question that explains this in a bit more detail. So, in fabric one of the fundamental assumption is that no one is manually manipulating the files or any state data (the same as you would imagine the case in a secure IT environment in - say a database of a bank).
Having said this, it should still be possible for ledger to verify some basic sanity at the start up time. Some of these are already in place and surely there may be some scope of improving for other anomalies. But as I said before, one of the fundamental assumption is that at least no one is manually manipulating their own orgs data.
@pb yes, that's what I was trying to explain. In most of the filesystems you would notice the similar behavior. You may want to go through this stackexchange question explains this in a bit more detail 0 https://unix.stackexchange.com/questions/146929/how-can-a-log-program-continue-to-log-to-a-deleted-file. So, in fabric one of the fundamental assumption is that no one is manually manipulating the files or any state data (the same as you would imagine the case in a secure IT environment in - say a database of a bank).
Having said this, it should still be possible for ledger to verify some basic sanity at the start up time. Some of these are already in place and surely there may be some scope of improving for other anomalies. But as I said before, one of the fundamental assumption is that at least no one is manually manipulating their own orgs data.
@pb yes, that's what I was trying to explain. In most of the filesystems you would notice the similar behavior. You may want to go through this stackexchange question/answer. This explains the phenomena in bit more detail - https://unix.stackexchange.com/questions/146929/how-can-a-log-program-continue-to-log-to-a-deleted-file. So, in fabric one of the fundamental assumption is that no one is manually manipulating the files or any state data (the same as you would imagine the case in a secure IT environment in - say a database of a bank).
Having said this, it should still be possible for ledger to verify some basic sanity at the start up time. Some of these are already in place and surely there may be some scope of improving for other anomalies. But as I said before, one of the fundamental assumption is that at least no one is manually manipulating their own orgs data.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=x2qQp27oAHb8rCkTw) @manish-sethi
Thanks manish-sethi but how can we ignore the possibility of manual manipulation.Also it would be great if you could explain how the chain within each peer is validated?
@pb - It's not about ignoring but it's more about technology limitation. Theoretically, it is not always feasible if the owner manipulates it's system by authorized access. The manipulation can be at various levels not only the block file.. for instance, one can install a completely different code for the contract (chaincode), manipulate state in the db, or completely run a different binary for the peer....
The guarantees that block chain systems or BFT protocols provide under certain assumptions (e.g, 3f+1 node in PBFT) are that an 'honest' node should not be manipulatable by other malicious node. For instance, in fabric, the endorsement results from a manipulated node won't match with others. If one wants to corrupt it's own node, its hard to stop him (For this, there is an entirely different computing paradigm of 'trusted computing' that involves hardware level security as well...).
@pb - It's not about ignoring but it's more about technology limitation. Theoretically, it is not always feasible if the owner manipulates it's system by authorized access. The manipulation can be at various levels not only the block file.. for instance, one can install a completely different code for the contract (chaincode), manipulate state in the db, or completely run a different binary for the peer....
The guarantees that blockchain systems or BFT protocols provide under certain assumptions (e.g, 3f+1 node in PBFT) are that an 'honest' node should not be manipulatable by other malicious node. For instance, in fabric, the endorsement results from a manipulated node won't match with others. If one wants to corrupt it's own node, its hard to stop him (For this, there is an entirely different computing paradigm of 'trusted computing' that involves hardware level security as well...).
Hi @manish-sethi; quick question: how stable are the sidedb specific shim interfaces exposed in 1.1? I understand that's an experimental feature in 1.1, and that formal support is supposed to happen only in 1.2; but should I expect major changes between what I see in the 1.1 experimental code vs. what I will see in 1.2 - from a chaincode developer point of view? For example, I noticed in the code that private data queries are accepted only in the context of chaincode invocations which do not perform writes; is that limitation changing at all in 1.2? Thanks.
Hi @minollo - yes, the existing functions in chaincode shim for private data are expected to be there in 1.2 as well. Also, for these APIs, the behavior will also be the same - i.e., allowing queries only in the read-only transactions. Having said this, there may be some additions in the shim for allowing more flexibility for endorsement for certain data. However, they are expected to be in the form of additional APIs.
Excellent; thanks @manish-sethi
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=iYd52zK6H4kipWmPc) @manish-sethi
Ok .Thanks :)
Has joined the channel.
Is there any way to query history? `stub.GetHistoryForKey()` fetches all the transaction history for a particular key. Is there any way to fetch history based on some query or condition?
Has joined the channel.
@pankajcheema - for now, this is the only way to retrieve history
@manish-sethi One more query if am using couchdb the i can change the state directly from database.and now end user will get the wrong data .
@manish-sethi One more query if am using couchdb then i can change the state directly from database.and now end user will get the wrong data .
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=dXtF5QZ9X32zMRgAi) @pankajcheema you may like to follow the conversation with @pb above
@manish-sethi and what about if there are two participating organization in a network.Who will be owner of the database ?
is there any expert that can answer my question `How your data is safe in Hyperledger Fabric when one can make changes to couchdb data directly`
on https://stackoverflow.com/questions/49934312/how-your-data-is-safe-in-hyperledger-fabric-when-one-can-make-changes-to-couchdb
@pankajcheema each have their own copy of the db
Hi @manish-sethi; looking at the v1.1.0 code, it seems to me that range queries on private data are not added to the txn's rwset; which implies they are not validated at commit time for phantom reads; am I missing something in the code? If not, is that just a temporary limitation which is being addressed in the "blessed" release of sideDB in 1.2? Thanks!
Has joined the channel.
I had asked this question on Fabric Questions but did not receive an answer so am hoping here. Within the chaincode does the call stub.GetHistoryForKey() - does this call go against the ledger files or is it provided by the state db (couchdb)?
@tsnyder It goes against an index stored in LevelDB and then into the ledger to fetch the details. State db has nothing to do with it.
@minollo Thanks - so if you are using couchdb as the state db, leveldb is still there as an index for the block transactions? or the couchdb index is used?
@tsnyder LevelDB is the only implementation currently available for the index; not much point in having CouchDB as an alternative the way things are implemented right now, as no "actual data" is stored in that index - which implies no useful queries would be possible anyway.
@minollo - Thanks. To restate what you are saying - irrespective of what the statedb is (LevelDB or CouchDB), the ledger as represented by the blocks, has each block's transactions indexed by writeset key within LevelDB.
yep
Got it - thanks
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=DBabeZZqccFsQE5pZ) @minollo yes, your observation is correct. In fact, queries on private data are not supported in the update transactions. The fundamental problem is that the peers that do not maintain private data cannot re-execute the queries (as they maintain only hashed data).
@manish-sethi; yeah, I thought that was the case; you may want to change the documentation in the shim interface for the range query function on pvt data, as it explicitly mentions that it is re-executed at commit time for phantom reads detection. Any plan/idea about how to address this problem/limitation moving forward?
@minollo - I see. Would you mind opening a jira for this fixing the chaincode shim document. In fact, you may like to submit a patch if you will. As far as private data queries are concerned, in 1.2, they will stay as is and nothing concrete as yet for the later releases - thanks
@manish-sethi OK, I'll play with it when I'm back in EST. Thanks.
hi, what is the size of a normal transaction?
or what are the components in a transaction and what is the size for each of these component?
Are we adding new feature that will allow the member to keep the data on the ledger for certain time period to manage the size of the ledger and also purge the data that we no longer need after certain time period (30 days). I have heard from someone that we are introducing this new feature. I want to get more details about the feature.
@dave.enyeart Are we adding new feature that will allow the member to keep the data on the ledger for certain time period to manage the size of the ledger and also purge the data that we no longer need after certain time period (30 days). I have heard from someone that we are introducing this new feature. I want to get more details about the feature.
@dave.enyeart Are we adding new feature that will allow the member to keep the data on the ledger for certain time period to manage the size of the ledger and also purge the data that we no longer need after certain time period (30 days). I have heard from someone that we are introducing this new feature. I want to get more details about the feature. Is this separate feature, is it part of the private data/side db capability in v1.1
one question is often asked that what's the requirement for the computer used for fabric and how long it can serve. to answer this question, the size of a transaction is one factor to consider
Size of transactions. During this experiment, we also observed
the following is from "Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains" by IBM authors. the size MINT and SPEND transactions. In particular,
the 2MB-blocks contained 473 MINT or 670 SPEND transactions,
i.e., the average transaction size is 3.06kB for SPEND
and 4.33kB for MINT. In general, transactions in Fabric are
large because they carry certificate information. Besides,
MINT transactions of Fabcoin are larger than SPEND transactions
because they carry CB certificates. This is an avenue
for future improvement of both Fabric and Fabcoin.
the following is from "Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains" by IBM authors. the size MINT and SPEND transactions. In particular,
the 2MB-blocks contained 473 MINT or 670 SPEND transactions,
i.e., the average transaction size is 3.06kB for SPEND
and 4.33kB for MINT. In general, transactions in Fabric are
large because they carry certificate information. Besides,
MINT transactions of Fabcoin are larger than SPEND transactions
because they carry CB certificates. This is an avenue
for future improvement of both Fabric and Fabcoin.
the following is from "Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains" by IBM authors. During this experiment, we also observed
the size MINT and SPEND transactions. In particular,
the 2MB-blocks contained 473 MINT or 670 SPEND transactions,
i.e., the average transaction size is 3.06kB for SPEND
and 4.33kB for MINT. In general, transactions in Fabric are
large because they carry certificate information. Besides,
MINT transactions of Fabcoin are larger than SPEND transactions
because they carry CB certificates. This is an avenue
for future improvement of both Fabric and Fabcoin.
the following is from "Hyperledger Fabric: A Distributed Operating System for Permissioned Blockchains" by IBM authors. During this experiment, we also observed
the size MINT and SPEND transactions. In particular,
the 2MB-blocks contained 473 MINT or 670 SPEND transactions,
i.e., the average transaction size is 3.06kB for SPEND
and 4.33kB for MINT.
of course, the size of a transaction depends. For details, you can read the paper.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=C96cAEmmR8qzJJcAZ) @gauthampamu I am looking for the same to be answered as well. Please let us know when you have some update. Thanks.
I am working on a fabric based design that can potentially have 1000's of private transactions (as many chaincodes). From data privacy perspective, I am looking to have the optimum design. I can have individual channels for each private communication thus ensuring that only relevant transactions are stored physically on any node. However it means creating 1000s of individual channels. It creates operations/maintenance challenges and network stability. Any feedback would be appreciated.
Do we have sample example implementation that uses Side DB feature. Is the collection policy defined at chaincode level or defined at the transaction level.
Screen Shot 2018-04-26 at 12.01.27 PM.png
So lets say I have two member member A and member B and two other regulators (X and Y). Member A does not want to share data with member B and member B does want to shared data with member A but only want to shared other regulators X and Y. So do need to define two collections Collection-A and Collection-B during instantiation and then use them in the chaincode. Also in your explain you are sending the price as transient data and since the member A does not want to share the data with other members on the channel, do we have to send all data as transient data.
Also what is implications to collections when you add one other member C to the network. Is the expectation that member C would define it collection and the network founder should update the collection policy that includes C's new collection so that member C can use it when it submits the transaction.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=H9JbHvxtsK36ydiGL) @manish-sethi can you suggest me location ?
@SmartContract2018 @gauthampamu Lots of good questions here... let me provide a summary as a baseline for everybody, and answer your questions inline...
Channel private data via collections (aka Side DB) enables a subset of channel members to share private data amongst themselves via peer-to-peer gossip, with a hash of the private data on the public channel as data proof.
The first production release is targeted for v1.2 with support of explicitly defined collections having a publicly known membership list.
See example at https://jira.hyperledger.org/browse/FAB-6600.
The collections are defined at chaincode instantiation/upgrade. You can add members to the collection by updating the collection definition upon chaincode upgrade.
Transactions can have a combination of public data and private collection data.
Part of the feature includes ability to automatically purge private data after a certain number of blocks, while keeping all public data on-chain indefinitely, including the private data hashes.
There are various variants of this pattern being proposed for future releases, including:
1) ability to keep the membership list private with private data dissemination driven by the client rather than peers,
2) the ability to have implicitly defined collections based on any permutations of channel members (where non-members get the transactions with hashes), and
3) the ability to have implicitly defined subchannels based on any permutations of channel members (where non-members don’t get the private transactions at all).
It sounds like you would benefit from these implicit collection/subchannel proposals, such that you don’t need to explicitly create and administer large numbers of channels/collections.
Question - in your use cases, should the non-members receive the transactions with hashed data, or not receive the transactions at all?
Can you explain what you mean by implicitly defined collection.Just to clarify, in v1.1, you can only define one collection right ? Also where can I find the sample collections.json referenced in the JIRA documentation.
Is it possible to have multiple collections in the JSON file and each member can they use different collection name when they submit the transaction. For example, can you define collection1 for member A and collection 2 for member B in the json file. Member A uses the collection1 when it submits the transaction to the chaincode and chaincode uses the collection name when it calls save private data call.
@dave.enyeart I don't understand why a hash of the key value is even going to the ordering service or all the peers. Wouldn't it be sufficient to just include a hash of the private data RWset?
Peers would then store that with the TxID as the key
Has joined the channel.
The current design leaks a lot of information, such as who's communicating with whom and what keys are modified. What is the value in leaking that information, or perhaps to put it another way, what's the benefit of sending the keys/hashed-values instead of just a hash of the private RWset?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ugo4zX5WMYQpS6CL9) @SmartContract2018 This seems problematic on many levels. Not only in the architecture but also how this is managed from the client application perspective. I would advocate you await the Side DB functionality for this.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=xGCR2TE4c3awDA5Z4) @eabiodun How many separate channels do you think would be practical to create on one network?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=2Jd4RgLypLELE4C6d) @dave.enyeart Thanks Dave. I am ok for hashed data as long as there is no way for others to know the identity of the parties involved in that private communication.
Secondly, if I reduce the number of peer nodes, how many unique channels can be supported by one network (one set of orderers)? In my case, there is one entity that is controlling the network and orderers will be managed by that entity only. All participants are ok if the controlling entity has access to all private channels.
What do you think is practical timeline for production ready implementation of SiceDB?
Much appreciated.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ZurZDpX5iX8yKTEak) @SmartContract2018 It really depends on too many variables.... Overall channels are a relatively fragile way to do this in its existing form. Are all your channels 1 to 1 relationships in regards to MSP's?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=LKMMK66tdkbudF5LS) @eabiodun Yes 1 to 1 and the controlling entity is the 3rd in that relationship (who has access to all other 1 to 1 channels as well).
Why are the channels a fragile way? What is the alternate to manage multiple private channels on one network?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=3bgCEsSmMrxWexxtR) @SmartContract2018 Think of each channel as an expensive resource :-) Happy to have a "side channel" with you on this. In regards to your use case, it is quite a common request. So each entity transacts privately with each other entity with some regulator or entity that has overall view on all transactions?
@SmartContract2018 consider this. (I am not saying this is the best solution). How about simply having 1 channel and using PKI to encrypt the values...Anything that is to be visible to all can be plain text....
Has joined the channel.
@gauthampamu You can have multiple collections in each chaincode, the example at the end of this file shows two collections in the json format:
https://gerrit.hyperledger.org/r/#/c/14769/9/examples/e2e_cli/scripts/script_marbles_private.sh
Typically you will be transacting between multiple members, and therefore typically the collections will have as membership the members that are transacting together
implicit collections are just an idea at this point, see this chart deck for the thinking:
https://jira.hyperledger.org/secure/attachment/14891/CollectionTypesAndStateBasedEndorsement.pptx
@toddinpal You are right, technically we don't need the hashes of the values in order to process transactions. But they are there as 'proof' of the value on the blockchain in case the parties in the transaction have a dispute and need to lookup of proof of their private value
But a hash of the RWset would also provide proof
assuming the clients have access to the private write set pre-image, which they may not in the long term
but they surely would store the private keys/values in their own systems long term
the hash of the key is also needed to store the version, which is used in the public MVCC validation on all peers
Yeah, well that's another interesting point, the aging of the private keys... yet maintaining the hashes in the public part of the chain... what's the use case for this?
you are correct that the initial impl leaks the transactors. this is why other variants are being designed for more privacy-preserving scenarios
all peers (including non-members) need the hashed key to perform MVCC validation consistently
Seems like if the private parties maintain the RWset in their own ledger, then their clients would have access to necessary information to seek a proof... As for MVCC, that is true, although only if the non-private portions of the RWset have a dependency on the private portion
So instead of a side db, it would essentially be a side ledger, with proofs on the main ledger
That is being considered as another variant, it's just that the sponsor project of the initial impl wanted the private data purged rather than saved in a side ledger indefintely.
ahhh... interesting... ok
we see a lot more use cases where a side ledger or perhaps more importantly a main ledger that proofs could be posted to.
for MVCC... even transactions with private data only need a way to do the MVCC validation consistently on all peers, and doing MVCC validation on the hashes of the keys is the current impl solution
the current inability to write to two ledgers (channels) atomically makes that difficult.
you obviously have thought about the various scenarios a lot, could you perhaps write a Jira or google doc with the various scenarios enumerated, ideally with prioritization highlighted. we can merge with other use cases that we are seeing to determine what gets prioritized next...
Will do...
you can direct message me as well
Has joined the channel.
@dave.enyeart Thanks for the response. Going back to my use case. Lets say we have two member A and B and they competitors and they cannot share any data between each other but they want to share data with other participants Regulators X and Y. You mentioned we can have multiple collections in the JSON file. I want to define two collections, one for Member A such that transactions from Member A is shared with only Member A, X and Y. Also have another collection for Member B such that transactions from Member B are shared with only Member B, X and Y.
Will this collection configuration meet my requirements. What should be values for requiredPeerCount and maxPeerCount. In my case I don't want to delete the private data, so what should be the value for blockToLive.
[
{
"name": "collectionMemberAPrivateDetails”,
"policy": "OR('OrgAMSP.member', 'OrgXMSP.member’, 'OrgYMSP.member')”,
"requiredPeerCount": 1,
"maxPeerCount": 2,
"blockToLive":1000000
},
{
"name": "collectionMemberBPrivateDetails",
"policy": "OR('OrgBMSP.member', 'OrgXMSP.member’, 'OrgYMSP.member')”,
"requiredPeerCount": 1,
"maxPeerCount”: 2,
"blockToLive”:100000
}
]
In your example, why do they have two collections...are they linked in some way..or are they separate collections.
[
{
"name": "collectionMarbles",
"policy": "OR('Org1MSP.member', 'Org2MSP.member')",
"requiredPeerCount": 1,
"maxPeerCount": 2,
"blockToLive":1000000
},
{
"name": "collectionMarblePrivateDetails",
"policy": "OR('Org1MSP.member')",
"requiredPeerCount": 1,
"maxPeerCount": 1,
"blockToLive":3
}
]
@gauthampamu
Yes, that’s how you would setup two collections for your scenario.
The two collections are not ‘linked’. They are independent collections (key namespaces) within the chaincode.
*maxPeerCount* is how many other authorized peers the endorsing peer attempts to send the private data to. It tries to scatter the private data across peers in other orgs in a best effort.
*requiredPeerCount* is the minimum number of peers the endorsing peer must successfully disseminate data to, before endorsement returns success (this is to ensure private data availability before commit, even if some endorsing peers go down).
If authorized peers still don’t have the private data at commit time, they will attempt to pull the private data from a peer that does have it.
*blockToLive* can be set to 0 to indicate that the private data lives forever. Setting to an integer of 1 or higher indicates that the private data should be purged after this many blocks.
Here is another example, let say we have network work three A,B and C participants and the one of the member A wants to define the collection policy where only it should have access to it and other don't have access it but it wants others to endorse to it. For example Can we have endorsement policy of A and (B or C) to endorse it but B and C are not in the collection. Is that feasible ? Basic Question, Can peers endorse without having access to the data.
@gauthampamu No, that doesn't make sense. If peers don't have access to the private data, they will not be able to endorse transactions that manipulate the private data. If you give them the private data such that they can execute chaincode and endorse, then you've defeated the purpose of private data collections, which is keep the data private from certain org's (and their peers).
Has left the channel.
Has joined the channel.
Hi everyone. Can the hyperledger-fabric's couchdb be mounted on a S3 bucket?
technically it looks possible, but also looks like it would not be a recommended solution for a live database, see https://stackoverflow.com/a/10820560
@naveen_saravanan technically it looks possible, but also looks like it would not be a recommended solution for a live database, see https://stackoverflow.com/a/10820560
@dave.enyeart thanks for the reply but I would like to also know how the hyperledger-fabric's couchdb can be mounted on a S3 bucket?
And if you know any documents regarding it please share them.
@naveen_saravanan http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence mentions how to write couchdb docker container data to host, and https://www.turnkeylinux.org/blog/exploring-s3-based-filesystems-s3fs-and-s3backer mentions how mount S3 buckets to the host. None of this is fabric specific, search for docker volumes and S3.
that being said, it doesn't look like a good idea as files in S3 buckets cannot be incrementally written to, it would write the entire database file anytime there is a data change.
@dave.enyeart thanks for your reply. Are there any best approach in mounting Hyperledger fabric's couchdb?
@dave.enyeart thanks for your reply. Are there any best approach in mounting Hyperledger fabric's couchdb?
and where are the data is stored normally in a cluster environment?
@dave.enyeart thanks for your reply. Are there any best approach in mounting Hyperledger fabric's couchdb?
and where are the data are stored normally in a cluster environment?
@naveen_saravanan In a blockchain network every peer has its own local data. The peer's and couchdb's docker container should write to the host file system using a docker volume, so that you can update the container while preserving the data.
@dave.enyeart What is tentative target date for v1.2 ?
@gauthampamu we have shifted to quarterly releases, so v1.2 is targeted for end of june
@dave.enyeart Is it correct that we cannot have private collection that is smaller set than the endorsement policy set ? Basically you can have private collection with just peer/org and expect to have endorsement policy with more than one org because the client would have to the submit the transaction to the endorsement peers so that means they need to part of the collection.
Hi...I wanted to test a couple of samples with side db feature. Can somebody point me to its documentation or a getting started guide.
@gauthampamu Right. Endorsement is a signature against chaincode execution results. To execute the chaincode you must have access to the data. Therefore to endorse you must have access to the data.
@MeenakshiSingh Public tutorials/documentation will be made available in v1.2 release. In the meantime you can look at this sample: https://jira.hyperledger.org/browse/FAB-6600
Has joined the channel.
Has joined the channel.
The fabric chaincode supports the couchdb **/db/_find** API via the QueryDocuments function.
Is there similar support for CouchDB **/db/_design/design-doc/_view/view-name** API for querying views inside the chaincode?
Couldnt find anthing in the source : https://github.com/hyperledger/fabric/blob/13447bf5ead693f07285ce63a1903c5d0d25f096/core/ledger/util/couchdb/couchdb.go
Added the question here ->https://stackoverflow.com/questions/50128674/does-fabric-support-queries-on-views
@manish-sethi @dave.enyeart The fabric chaincode supports the couchdb **/db/_find** API via the QueryDocuments function.
Is there similar support for CouchDB **/db/_design/design-doc/_view/view-name** API for querying views inside the chaincode?
Couldnt find anthing in the source : https://github.com/hyperledger/fabric/blob/13447bf5ead693f07285ce63a1903c5d0d25f096/core/ledger/util/couchdb/couchdb.go
Added the question here ->https://stackoverflow.com/questions/50128674/does-fabric-support-queries-on-views
@manish-sethi @dave.enyeart The fabric chaincode supports the couchdb **/db/_find** API via the QueryDocuments function ( in core/ledger/util/couchdb/couchdb.go)
Is there similar support for CouchDB **/db/_design/design-doc/_view/view-name** API for querying views inside the chaincode?
Couldnt find anthing in the source : https://github.com/hyperledger/fabric/blob/13447bf5ead693f07285ce63a1903c5d0d25f096/core/ledger/util/couchdb/couchdb.go
Added the question here ->https://stackoverflow.com/questions/50128674/does-fabric-support-queries-on-views
If no , are there any future plans to support this ?
There is a requirement to add support for views: https://jira.hyperledger.org/browse/FAB-5528
It is not yet planned for a release... many people think such aggregate reporting should be done against a datastore outside of Fabric. For example have a client of the event deliver service listen for block events and build out a data warehouse that is more optimized for each specific organizations reporting needs.
Thanks @dave.enyeart! , This would be fine for orgs owning a peer(because they trust whats in their own peer),
Consider This case ..
An org may want to consume results of aggregations from the chaincode itself without owning a peer or having to build a data warehouse themselves. In such cases it would help to have the capability for basic aggregations.
agreed, that's why I created the requirement
cool thanks!
reading the documention on endorsement policies (https://hyperledger-fabric.readthedocs.io/en/release-1.1/endorsement-policies.html), i see a lot of great example policies, but no way to define them
for example, how do i define a policy that states: at least 3 members of org1?
Has joined the channel.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=JNtcwkrcvA7YCoT8n) @dave.enyeart Thank you for your reply.
Has left the channel.
Has joined the channel.
i've an application that's attempting to write a few dozen CONCURRENT transactions into fabric, and getting MVCC_READ_CONFLICT back. Anyone have any thoughts on this?
For what it's worth, I did a quick search in this channel and found someone asked practically the same question a while back. Here's the primary part of the response:
For what it's worth, I did a quick search in this channel and found someone asked practically the same question a while back. Here's the primary part of the response: https://chat.hyperledger.org/channel/fabric-ledger?msg=BHo3XRLhdLLBo67eZ
@downTheFallLine For what it's worth, I did a quick search in this channel and found someone asked practically the same question a while back. Here's the primary part of the response: https://chat.hyperledger.org/channel/fabric-ledger?msg=BHo3XRLhdLLBo67eZ
Has joined the channel.
I understand. Thanks. In a heavily concurrent application, this could well be the case, correct? i'm new on this channel, so let me look at the link above
yeah this seems to be at least a similar issue
@downTheFallLine yes, if you have a lot of updates to the same record you will get MVCC_READ_CONFLICT because multiple transactions in the same block are updating the readset to a new writeset.
in order to get around this you could play around with how long it takes to cut a block/how many transactions go into a block or rework your chaincode logic.
@downTheFallLine yes, if you have a lot of updates to the same record you will get MVCC_READ_CONFLICT because multiple transactions in the same block are updating the readset to new, conflicting writeset.
in order to get around this you could play around with how long it takes to cut a block/how many transactions go into a block or rework your chaincode logic.
@downTheFallLine yes, if you have a lot of updates to the same record you will get MVCC_READ_CONFLICT because multiple transactions in the same block are updating the readset to new, conflicting writesets.
in order to get around this you could play around with how long it takes to cut a block/how many transactions go into a block or rework your chaincode logic.
a high-throughput example can be found here: https://github.com/hyperledger/fabric-samples/tree/release-1.1/high-throughput
if i'm understanding you, the issue is that 2 different business transactions have been "cut" into the same block and thus conflicting.
@downTheFallLine yes. imagine you have an asset that has a key/value of `{"key": "val1"}`. two transactions then come in. tx1 reads `"key"`, sees it has a value of `"val1"`, and tries to update `"key"` to point to `"val2"`. tx2 reads `"key"`, sees it has a value of `"val1"`, and tries to update `"key"` to point to `"val3"`.
when it comes time to commit the block, we have two transactions with a read set of `{"key": "val1"}`, but tx1 has a writeset of `{"key": "val2"}` and tx2 has a writeset of `{"key": "val3"}`. if tx1 gets ordered first it will be committed, but tx2 will be rejected from the block with `MVCC_READ_CONFLICT`. assuming tx1 gets cut in a block, when you retry tx2 it will then see the readset as `{"key": "val2"}` and can successfully write `{"key": "val3"}`
@downTheFallLine yes. imagine you have an asset that has a key/value of `{"key": "val1"}`. two transactions then come in. tx1 reads `"key"`, sees it has a value of `"val1"`, and tries to update `"key"` to point to `"val2"`. tx2 reads `"key"`, sees it has a value of `"val1"`, and tries to update `"key"` to point to `"val3"`.
when it comes time to commit the block, we have two transactions with a read set of `{"key": "val1"}`, but tx1 has a writeset of `{"key": "val2"}` and tx2 has a writeset of `{"key": "val3"}`. if tx1 gets ordered first it will be committed, but tx2 will be rejected from the block with `MVCC_READ_CONFLICT`. assuming tx1 gets cut in the block, when you retry tx2 it will then see the readset as `{"key": "val2"}` and can successfully write `{"key": "val3"}`
Has joined the channel.
When I read source code of channel.go，
Only one grpc communication between client and endordser. here should not be more than one？
@C0rWin After the discussion at February maintainers meeting you had started a checkpoint writeup. Is it in any shape to post to FAB-106? @sheehan is asking about it in Fabric mailing list...
Has joined the channel.
@dave.enyeartI will post it once I will finish items for dynamic collections support. Also probably DM to @sheehan to update
@dave.enyeart I will post it once I will finish items for dynamic collections support. Also probably DM to @sheehan to update
Thanks! Do you know who is working on consensus on validation results? Or is that part of this same write up?
@sheehan what do you mean consensus for validation?
From Dave’s email
“To help simplify blockchain integrity verification, there are at least two (not mutually exclusive) proposals on the table for next releases:
- consensus on validation results (each block)
- consensus on checkpoints (at certain block intervals)”
Oh, so yes I am addressing the consensus on checkpoint, it sort of including validation results implicitly
Nobody is working on per-block validation consensus yet, it's just something we expect will need to be done if and when work starts on post-order execution model. And per the mailing list thread, can also provide benefit in the execute/order model to ensure deterministic validation.
Has joined the channel.
Hi, everyone. I am working on a project based on fabric, which is a auto-selling information market. Every participant store the information inside the ledger, and pay tokens/points to buy the information from smart contract. To ensure privacy and confidentiality, we encrypt all data in the ledger to prevent participant secretly query the info bypassing the smart contract. I heard in the fabric-question channel that there is an experimental feature in 1.1 which is called side-db. I can't found any clue about it except for a FAB link. Anyone can provide some example to show me how it works so that I can determine if I need to change my encryption solution.
Has joined the channel.
@C0rWin @dave.enyeart thanks, understood now
@lclclc perhaps take a look at the powerpoint attached to https://jira.hyperledger.org/browse/FAB-1151
https://jira.hyperledger.org/secure/attachment/12720/PrivacyEnabledLedger20171022.pptx
That contains a lot of info, really helpful.
That contains a lot of info, which is really helpful.
Hello everyone,
I want to know that, if I want to create a project in fabric, then what should be the basic architecture?
Thanks for the help
hello all,I am planning to write a chaincode that provides a look-up service using its internal lookup table. I know there could be multiple way to achieve this functionality but I would like this question to stay focused on this design pattern. The question: - what is the size limitation on a chaincode as my lookup data can get very large?
20180510_DFM_Server01_CommitLogs.zip
@dave.enyeart - the logs for the delay in multiple PUTSTATEs is attached here
20180510_DFM_LogsBreakup.txt
@dave.enyeart - the breakup of the logs attached with timings/linenumbers for your observations. Please let me know if you need any further info.
```2018-05-10 22:47:57.510 UTC [txvalidator] VSCCValidateTxForCC -> ERRO 60b8 VSCC check failed for transaction txid=e84c295b29eabae1b14867b831b2c5d153a036b7c8d93ae864e8cd01cc87967a, error VSCC error: policy evaluation failed, err Failed to authenticate policy
2018-05-10 22:47:57.510 UTC [lockbasedtxmgr] Done -> DEBU 60b9 Done with transaction simulation / query execution [f1779b40-77f9-4aa5-8757-fd6478110bc8]
2018-05-10 22:47:57.510 UTC [txvalidator] Validate -> ERRO 60ba VSCCValidateTx for transaction txId = e84c295b29eabae1b14867b831b2c5d153a036b7c8d93ae864e8cd01cc87967a returned error VSCC error: policy evaluation failed, err Failed to authenticate policy```
When using a endorsement-policy of the below I get the above error.
```'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: ORGS['dfm'].mspid }},
{ role: { name: 'member', mspId: ORGS['sca'].mspid }},
{ role: { name: 'member', mspId: ORGS['adx'].mspid }},
{ role: { name: 'admin', mspId: ORGS['dfm'].mspid }},
{ role: { name: 'admin', mspId: ORGS['sca'].mspid }}
],
policy: {
'1-of': [
{ 'signed-by': 3},
{ 'signed-by': 4},
{ '2-of': [{ 'signed-by': 0}, { 'signed-by': 1 }, {'signed-by': 2}]}
]
}
}```
```'endorsement-policy': {
identities: [
{ role: { name: 'member', mspId: ORGS['aaa'].mspid }},
{ role: { name: 'member', mspId: ORGS['bbb'].mspid }},
{ role: { name: 'member', mspId: ORGS['ccc'].mspid }},
{ role: { name: 'admin', mspId: ORGS['ddd'].mspid }},
{ role: { name: 'admin', mspId: ORGS['eee'].mspid }}
],
policy: {
'1-of': [
{ 'signed-by': 3},
{ 'signed-by': 4},
{ '2-of': [{ 'signed-by': 0}, { 'signed-by': 1 }, {'signed-by': 2}]}
]
}
}```
Can someone put some additional light on the issue faced today?
What if we submit a transaction when the peer is still waiting on some proposal responses. In my case the next service is hanging till all the nodes endorse the transaction and then only I can place new transactions - any help is greatly appreciated.
So I have a TX-1 (with 3 peers to endorse) - takes 30 seconds
I have a TX-2 (if tried within 30 seconds (the about timings) - I get a timeout from NODE
So I have a TX-1 (with 3 peers to endorse) - takes 30 seconds
I have a TX-2 (if tried within 30 seconds (the about timings) - I get a timeout from NODE . After that there is a quite period of 10 seconds and the process resumes.
So I have a TX-1 (with 3 peers to endorse) - takes 30 seconds
I have a TX-2 (if tried within 30 seconds (the above timings) - I get a timeout from NODE . After that there is a quite period of 10 seconds and the process resumes.
If I try TX-2 after the first one is completed then all goes fine
The above process effects query too - the query timesout while reading changed datasets, the retries itself to confirm all transactions
The above process effects query too - the query timesout while reading changed datasets, the retries itself to return all transactions
Environment - DOCKER/RHEL7.3/Docker/Docker-compose
Can someone provide me some insights to the below logs: The couch DB is taking too much time to save the DB
```2018-05-11 13:22:02.467 UTC [couchdb] handleRequest -> DEBU b94 Entering handleRequest() method=GET url=http://couchdb_sca02:5984/agmchannel/agmaccounttransactions%00EA3387ED-075E-4017-888E-E5DFA72BD335?attachments=true
2018-05-11 13:22:02.467 UTC [couchdb] handleRequest -> DEBU b95 HTTP Request: GET /agmchannel/agmaccounttransactions%00EA3387ED-075E-4017-888E-E5DFA72BD335?attachments=true HTTP/1.1 | Host: couchdb_sca02:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Accept-Encoding: gzip | |
2018-05-11 13:22:12.496 UTC [couchdb] handleRequest -> DEBU b96 Couch DB Error:not_found, Status Code:404, Reason:missing
2018-05-11 13:22:12.496 UTC [couchdb] ReadDoc -> DEBU b97 Document not found (404), returning nil value instead of 404 error
2018-05-11 13:22:12.496 UTC [couchdb] handleRequest -> DEBU b98 Entering handleRequest() method=PUT url=http://couchdb_sca02:5984/agmchannel/agmaccounttransactions%00EA3387ED-075E-4017-888E-E5DFA72BD335
2018-05-11 13:22:12.496 UTC [couchdb] handleRequest -> DEBU b99 HTTP Request: PUT /agmchannel/agmaccounttransactions%00EA3387ED-075E-4017-888E-E5DFA72BD335 HTTP/1.1 | Host: couchdb_sca02:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 817 | Accept: application/json | Content-Type: application/json | Accept-Encoding: gzip | |```
@Amjadnz That is a keyed lookup that is taking 10 seconds from couchdb. Keyed lookups in couchdb use a b-tree, and I've always seen them respond instantly. The only exception to that is I've seen the couchdb process halt in some virtualized environments (e.g. docker within vagrant on mac occassionally), and that has been a problem with the environment rather than fabric or couchdb. In that scenario I discussed in couchdb community and they convinced me it was an environment problem rather than a couchdb problem. If you think there is any chance it is a couchdb problem rather than an environment problem, please reach out to couchdb community (slack, IRC, jira issue) as described at https://couchdb.apache.org/ and keep us informed of any updates.
Ok @dave.enyeart - thanks
would check out to see if it is indeed a couch db related issue
am planning to move to LEVEL DB and check if the issue exists (of slowness)
As the trace shows the delay within couchdb, I would surely expect leveldb would not demonstrate the slowness. I suspect it is an issue running couchdb process (erlang process) on the particular environment.
That should work let me try - Thanks again.
I'm getting the following error if i reduce my endorsement-policy to 1 peer:
```2018-05-11 15:37:29.484 UTC [vscc] Invoke -> WARN 241b Endorsement policy failure for transaction txid=39fc27e682dba37929280b701266feeaf01b13fe18251345ea2e42c5c86a409c, err: Failed to authenticate policy
2018-05-11 15:37:29.484 UTC [shim] func1 -> DEBU 241c [f19309b4]Transaction completed. Sending COMPLETED
2018-05-11 15:37:29.484 UTC [shim] func1 -> DEBU 241d [f19309b4]Move state message COMPLETED
2018-05-11 15:37:29.484 UTC [shim] handleMessage -> DEBU 241e [f19309b4]Handling ChaincodeMessage of type: COMPLETED(state:ready)
2018-05-11 15:37:29.484 UTC [shim] func1 -> DEBU 241f [f19309b4]send state message COMPLETED
2018-05-11 15:37:29.484 UTC [chaincode] processStream -> DEBU 2420 [f19309b4]Received message COMPLETED from shim
2018-05-11 15:37:29.484 UTC [chaincode] HandleMessage -> DEBU 2421 [f19309b4]Fabric side Handling ChaincodeMessage of type: COMPLETED in state ready
2018-05-11 15:37:29.484 UTC [chaincode] HandleMessage -> DEBU 2422 [f19309b4-7683-414c-a178-51434deb6b3a]HandleMessage- COMPLETED. Notify
2018-05-11 15:37:29.484 UTC [chaincode] notify -> DEBU 2423 notifying Txid:f19309b4-7683-414c-a178-51434deb6b3a
2018-05-11 15:37:29.484 UTC [chaincode] Execute -> DEBU 2424 Exit
2018-05-11 15:37:29.484 UTC [txvalidator] VSCCValidateTxForCC -> ERRO 2425 VSCC check failed for transaction txid=39fc27e682dba37929280b701266feeaf01b13fe18251345ea2e42c5c86a409c, error VSCC error: policy evaluation failed, err Failed to authenticate policy
2018-05-11 15:37:29.484 UTC [lockbasedtxmgr] Done -> DEBU 2426 Done with transaction simulation / query execution [00166af3-83b0-4eee-ae15-e5ed1d3363a9]
2018-05-11 15:37:29.484 UTC [txvalidator] Validate -> ERRO 2427 VSCCValidateTx for transaction txId = 39fc27e682dba37929280b701266feeaf01b13fe18251345ea2e42c5c86a409c returned error VSCC error: policy evaluation failed, err Failed to authenticate policy```
```2018-05-11 15:37:29.574 UTC [vscc] deduplicateIdentity -> DEBU 2506 Signature set is of size 2 out of 2 endorsement(s)
2018-05-11 15:37:29.576 UTC [vscc] Invoke -> WARN 2507 Endorsement policy failure for transaction txid=2ac9f26677d21f4b525ec445bd2980415b793bec935f12fd172f94b297c6c403, err: Failed to authenticate policy
2018-05-11 15:37:29.576 UTC [shim] func1 -> DEBU 2508 [34c15e55]Transaction completed. Sending COMPLETED
2018-05-11 15:37:29.576 UTC [shim] func1 -> DEBU 2509 [34c15e55]Move state message COMPLETED
2018-05-11 15:37:29.576 UTC [shim] handleMessage -> DEBU 250a [34c15e55]Handling ChaincodeMessage of type: COMPLETED(state:ready)
2018-05-11 15:37:29.576 UTC [shim] func1 -> DEBU 250b [34c15e55]send state message COMPLETED
2018-05-11 15:37:29.576 UTC [chaincode] processStream -> DEBU 250c [34c15e55]Received message COMPLETED from shim
2018-05-11 15:37:29.576 UTC [chaincode] HandleMessage -> DEBU 250d [34c15e55]Fabric side Handling ChaincodeMessage of type: COMPLETED in state ready
2018-05-11 15:37:29.576 UTC [chaincode] HandleMessage -> DEBU 250e [34c15e55-9cb8-424b-80e8-7a87b49e1f44]HandleMessage- COMPLETED. Notify
2018-05-11 15:37:29.576 UTC [chaincode] notify -> DEBU 250f notifying Txid:34c15e55-9cb8-424b-80e8-7a87b49e1f44
2018-05-11 15:37:29.576 UTC [chaincode] Execute -> DEBU 2510 Exit
2018-05-11 15:37:29.576 UTC [txvalidator] VSCCValidateTxForCC -> ERRO 2511 VSCC check failed for transaction txid=2ac9f26677d21f4b525ec445bd2980415b793bec935f12fd172f94b297c6c403, error VSCC error: policy evaluation failed, err Failed to authenticate policy
2018-05-11 15:37:29.576 UTC [lockbasedtxmgr] Done -> DEBU 2512 Done with transaction simulation / query execution [b5e83e41-13a9-4a99-9ec7-b4b4f1805631]
2018-05-11 15:37:29.576 UTC [txvalidator] Validate -> ERRO 2513 VSCCValidateTx for transaction txId = 2ac9f26677d21f4b525ec445bd2980415b793bec935f12fd172f94b297c6c403 returned error VSCC error: policy evaluation failed, err Failed to authenticate policy```
Can someone help?
Question 1 : My endorsement policy is actually 1 of 1 but it is showing 2 of 2.
``` 'endorsement-policy': {
identities: [
{ role: { name: 'admin', mspId: ORGS['sca'].mspid }}
],
policy: {
'1-of': [{ 'signed-by': 0}]
}
}```
Thanks in advance.
Ok - when the policy was changed to "member" - it is working fine now.
Initial 6 transactions go through - but the seventh one takes 1 minute.
Once the chain code is migrated to the LEVELDB - all performance issues seems to be resolved. I can now do all tests successfully with the expected volume.
So I assume as @dave.enyeart pointed out was a CouchDB issue. Would be taking it with them and fix the issues.
Thanks all for the help and inputs.
what does this error mean when calling `stub.PutState`: ```2018-05-12 23:39:58.644 CST [shim] handlePutState -> ERRO 004 [95c37f35] Received ERROR. Payload: PUT_STATE failed: transaction ID: 95c37f357f71c3b05be3b8b5d323b88e5d13211b2c65cf2f3fb4407330578087: This instance should not be used after calling Done()```
@bh4rtp what release are you on?
@dave.enyeart i am using the latest master branch. this error did not occur before.
in the current chaincode, i invoke another chaincode where `stub.PutState` is called.
@bh4rtp Please open a Jira defect. There have been some changes in chaincode and txsimulator recently that may have caused it, let's check with the folks that have worked in that area recently - @sykesm @muralisr @manish-sethi @Senthil1
Has joined the channel.
@dave.enyeart @bh4rtp @sykesm I do see a regression in the invokechaincode execute path but not sure if that's the cause of your issue. Will put out a fix for that and we can go from there
@dave.enyeart @muralisr ok. thanks.
@bh4rtp if you have some time willl be good to see if this fix resolves your issue https://gerrit.hyperledger.org/r/#/c/21739/
@muralisr roger. i am pulling down the updates.
ty
@muralisr the issue is not really solved. now `stub.PutState` is ok, but after `stub.InvokeChaincode` returned, the errors say:
```2018-05-14 10:41:30.346 CST [shim] handleInvokeChaincode -> ERRO 129 [2343285e] Received 200. Error from chaincode
2018-05-14 10:41:30.346 CST [Trade_CC] Error -> ERRO 12a failed to invoke bidcheck chaincode, status = 500, message =```
No error message was printed.
sorry. i have not compiled using your provided patches, but pull from master branch which was committed three days ago.
@muralisr great. your patch does work. the issue is solved. :thumbsup:
Has joined the channel.
thanks for testing @bh4rtp
Has joined the channel.
@muralisr @dave.enyeart the state database for couchdb support the `index`
if it supports,please give me a example
@asaningmaxchain123 couchdb index support was added in v1.1, see details here:
http://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html?
http://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html
I have a question on CouchDB indexes. When you install chaincode, does it automatically deploy even the index JSON file in META folder.
does peer support only one type of ledger db, i.e. couchdb now? and is every ledger an instance of couchdb database?
@gauthampamu yes any index packaged with the chaincode will be deployed automatically when the chaincode is both installed on the peer and instantiated on the channel. for more details see http://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html
@gauthampamu yes any couchdb index packaged with the chaincode will be deployed automatically when the chaincode is both installed on the peer and instantiated on the channel. for more details see http://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html
@bh4rtp go-leveldb is the default state database. couchdb is the optional alternative if you want json query support. for more details see: http://hyperledger-fabric.readthedocs.io/en/latest/ledger/ledger.html
if you choose couchdb, each peer would have one corresponding instance of couchdb, with a couchdb database within that instance per channel/chaincode.
@dave.enyeart can you take a look #fabric-peer-endorser-committer
@asaningmaxchain123 Please review the Private Data demo playback at the bottom of this page first: https://wiki.hyperledger.org/projects/fabric/playbacks . Then ask any follow-on questions if you still have questions.
@dave.enyeart i see the video in the youtube. i am going to test it
What is the performance implication of having multiple channels. Do we have any limit on the number of channels on the peer ? Is it recommended to use SideDB from v1.2 to limit the number of channels.
Initially the number of channels will improve throughput as it enables more parallel processing. But there are diminishing returns after the resources are saturated, and eventually the overhead of many channels can be a drag, but not a large one. I think the line of questioning is incorrect though... better to choose an architecture based on functional requirements and then size the hardware accordingly. For example use channels if you need complete data isolation, use side db private data if participants should know about transactions, but keep actual data private, and share hashes in order to validate private data that they may later receive.
Hi All,
While fetching the block from sdk. I can see the transactions in ledger are getting saved with the time stamp of IST
as you can see here `"timestamp": "Thu May 17 2018 14:27:07 GMT+0530 (IST)"`
Can it be configured to save it in UTC?
Any help would be appreciated
Thanks
Has joined the channel.
Hi,
I have installed the chaincode and it got successful but facing this error when trying to instantiate the chaincode -
`ERRO 692 [[e9585782 PUT_STATE ERROR]]No ledger context for %!!(MISSING)s(MISSING). Sending %!!(MISSING)s(MISSING)
ERRO 6a2 [bloqchannel][e9585782] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction`
I am using Hyperledger Fabric v1.1.0 preview
I have 2 orgs and 3 peers per org.
Hi,
I have installed the chaincode and it got successful but facing this error when trying to instantiate the chaincode -
ERRO 692 [[e9585782 PUT_STATE ERROR]]No ledger context for %!!(MISSING)s(MISSING). Sending %!!(MISSING)s(MISSING)
ERRO 6a2 [bloqchannel][e9585782] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction
I am using Hyperledger Fabric v1.1.0 preview
I have 2 orgs and 3 peers per org.
Hi,
I have installed the chaincode and it got successful but facing this error when trying to instantiate the chaincode -
`ERRO 692 [[e9585782 PUT_STATE ERROR]]No ledger context for %!!(MISSING)s(MISSING). Sending %!!(MISSING)s(MISSING)
ERRO 6a2 [bloqchannel][e9585782] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction`
I am using Hyperledger Fabric v1.1.0 preview
I have 2 orgs and 3 peers per org.
Hi,
I have installed the chaincode and it got successful but facing this error when trying to instantiate the chaincode -
`ERRO 692 [[e9585782 PUT_STATE ERROR]]No ledger context for %!!(MISSING)s(MISSING). Sending %!!(MISSING)s(MISSING)`
`ERRO 6a2 [bloqchannel][e9585782] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction`
I am using Hyperledger Fabric v1.1.0 preview
I have 2 orgs and 3 peers per org.
`hi`
Has joined the channel.
@AnkitSingh5 Are you using golang or nodejs chaincode? If nodejs, make sure the filename in your package.json's run script is the same as your chaincode.
Can anyone tell me why the newer CouchDB images are tagged 0.4.x and not 1.1.x ? Has the versioning system changed?
Anyone ever see this?
```2018-05-25 15:32:42.673 UTC [shim] handlePutState -> ERRO 007 [dcc05043]Received ERROR. Payload: [[dcc05043 PUT_STATE ERROR]]No ledger context for %!s(MISSING). Sending %!s(MISSING)
2018-05-25 15:32:42.673 UTC [sacc] Errorf -> ERRO 008 [[dcc05043 PUT_STATE ERROR]]No ledger context for %!!(MISSING)s(MISSING). Sending %!!(MISSING)s(MISSING)
```
This code was working until I changed how I connect to the network.
@dave.enyeart can you take a look #fabric-peer-endorser-committer
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
https://chat.hyperledger.org/channel/fabric-orderer?msg=KCdP3mJHqxpYmG4yR
@dave.enyeart @manish-sethi Could you point @sarapara to the sidedb doc/examples
Has joined the channel.
@sarapara the side db docs and sample will be merged soon. In the meantime check these resources:
https://docs.google.com/document/d/1sdfSIyLvoVW_32LXipm8sgs87oCE7D7bK2eCC0sLH9s/edit
https://logs.hyperledger.org/production/vex-yul-hyp-jenkins-3/fabric-docs-build-x86_64/347/html/private_data_tutorial.html
https://gerrit.hyperledger.org/r/#/c/22255/
@amolpednekar Yes the versioning system for dependencies (couchdb, kafka) has changed. The dependencies used to be included in fabric and so the version matched the fabric version. Now the dependency images are associated with fabric-baseimage which allows them to be used across fabric levels.
Has joined the channel.
@dave.enyeart, I understand that SideDB feature will be available in V1.2 which is in June but if i want to play around sidedb feature right now how do it go about that?
@dave.enyeart, I understand that SideDB feature will be available in V1.2 which is in June but if i want to play around sidedb feature right now how do i go about that?
@sarapara It's working on latest master, you can either setup dev env (http://hyperledger-fabric.readthedocs.io/en/latest/dev-setup/devenv.html). Or pull daily docker images from nexus, these instructions are evolving but you could give it a try: https://github.com/hyperledger/ci-management/blob/master/docs/nexusdocker/nexusdocker_images.md
Then follow the tutorial/sample I mentioned above for private data
Has joined the channel.
I had a question about chaincode to chaincode calls.
Lets say there are two channels:
Channel A, with Org1, Org2, Org3, and chaincode A
Channel B, with Org1, Org4, Org5 and chaincode B
If Org1 makes a call from chaincode B on channel B to chaincode A on channel A, who need to be the endorsing peers on Chaincode B to commit this txn? Because if Org4 is also an endorsing peer for Chaincode B, it wont be access to chaincode A to run the function, right? Also, do committing peers (Lets say Org5, in the case) need access to Channel A? Or can they commit without being members?
@amolpednekar take a look at the [InvokeChaincode](https://github.com/hyperledger/fabric/blob/release-1.1/core/chaincode/shim/interfaces_stable.go#L65) description, i think that might answer your question
Thanks @jrosmith , so from my understanding, only Endorsing Peers need to be on both channels for inter-channel calls, correct?
@amolpednekar i dont think thats true, and from the description i don't think inter-channel writes are supported by `InvokeChaincode` based on the following excerpt:
``` Effectively the called chaincode on a different channel is a `Query`, which does not participate in state validation checks in subsequent commit phase.```
Yes, what I meant is for the Endorsing peer to able run run the transaction (in chaincodeB; which calls chaincodeA), it needs to be a part of chaincodeA as well, to actually be able to execute the chaincode query, but not the commiting peeers.
Yes, what I meant is for the Endorsing peer to able run run the transaction (in chaincodeB; which calls chaincodeA), it needs to be a part of chaincodeA as well, to actually be able to execute the chaincode query, but not the commiting peers on Channl B.
Yes, what I meant is for the Endorsing peer to able run run the transaction (in chaincodeB; which calls chaincodeA), it needs to be a part of ChannelA as well, to actually be able to execute the chaincode query, but not the commiting peers on Channl B.
i believe the peer would have to be a member of both channels, yes.
Has joined the channel.
I currently have a channel where (when querying the last block) `LastConfigFromBlock` points to block 1734, but actually, block 1735 is the CONFIG block.
Block 1734 is a ENDORSER_TRANSACTION
How can this happen?
GetLastConfigFromBlock: https://github.com/hyperledger/fabric-sdk-go/blob/master/pkg/fab/resource/config.go#L110
Has joined the channel.
Hi. Question on sidedb design: let's say there are three orgs in a channel. Only two orgs wants to share data with each privately. Wt would happen if one org doesn't get the privateRW set data from another org and also the client doesn't have access to the private data anymore?
Hi. Question on sidedb design: let's say there are three orgs in a channel. Only two orgs wants to share data with each other privately. Wt would happen if one org doesn't get the privateRW set data from another org and also the client doesn't have access to the private data anymore?
@niteshsolanki The peers that endorsed the transaction would always have the private data so you'd have to query one of them to get it. To avoid such problem, it is recommended to set the requiredPeerCount and maxPeerCount high enough such that there are guarantees that the endorsing peers disseminate the private data to other members of the collection.
In Fabric V1.1, is it possible to do cross-channels query ? Or is it available only in the future release?
@sarapara you can use [InvokeChaincode](https://github.com/hyperledger/fabric/blob/release-1.1/core/chaincode/shim/interfaces_stable.go#L65)
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=CZNJj5FCZCSFRxPhg) @jrosmith the ENDORSING peer, yes?
@dave.enyeart I had posted this question on #fabric-sdk-node Can you tell me who can answer this question. What is the max limit or the optimum size for the query data. https://chat.hyperledger.org/channel/fabric-sdk-node?msg=2TMtWCoAAvmnBxAyH
@gauthampamu what types of queries? Which state database?
CouchDB and queries supported by CouchDB. I understand we might not have limitation at the query level but my concern is with the data returned by the Fabric Node SDK.
@dave.enyeart CouchDB and queries supported by CouchDB. I understand we might not have limitation at the query level but my concern is with the data returned by the Fabric Node SDK.
@muralisr hi, remember invokechaincode question i asked? the master branch still has something wrong with it. now there is no error with invokechaincode but the sdk client invoke chaincode failed. i cannot find any message about the cause from container logging.
@muralisr hi, remember the `InvokeChaincode` question i asked? the master branch still has something wrong with it. now there is no error with `InvokeChaincode` but the sdk client fails in case of invoking chaincode with another chaincode invocation. i cannot find any message about the cause from container logging.
@muralisr hi, remember the `InvokeChaincode` question i asked? the master branch still has something wrong with it. now there is no error with `InvokeChaincode` but the sdk client fails to invoke chaincode in which invokes another chaincode. i cannot find any message about the cause from container logging.
@muralisr sdk client printed one endorsement is good while another one is bad.
@muralisr i found the reason. `InvokeChaincode` was just committed to `dev-peer0.org1.example.com-bidcheck-v2` while `dev-peer0.org2.example.com-bidcheck-v2` was not.
@muralisr i found the reason. `InvokeChaincode` was just committed to `dev-peer0.org1.example.com-bidcheck-v2` ok while `dev-peer0.org2.example.com-bidcheck-v2` failed with error.
@muralisr i found the reason. `InvokeChaincode` was successfully executed in `dev-peer0.org1.example.com-bidcheck-v2`, while `dev-peer0.org2.example.com-bidcheck-v2` failed with an error.
the endorsement peers are `peer0.org1.example.com` and `peer0.org2.example.com`.
from node sdk client, i invoke `bidcheck` to peers `peer0.org1.example.com` and `peer1.org1.example.com`. executing `bidcheck` in `dev-peer0.org1.example.com-bidcheck-v2` was ok, but `dev-peer1.org1.example.com-bidcheck-v2` failed with an error:
```[shim] handlePutState -> ERRO 004 [a6d0cb7a] Received ERROR. Payload: PUT_STATE failed: transaction ID: a6d0cb7a17429c943bf1e6ad9203a27ec17c496b001dd5cdd171b15dab8c8075: This instance should not be used after calling Done()```
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=do9hczevgAjaiJicF) @dave.enyeart The state database is CouchDB and queries will be select queries supported by CouchDB. I understand we might not have limitation at the query level but my question is with the data returned by the Fabric Node SDK.
Has joined the channel.
hello everyone! quick question
is it possible to move the genesis block up the chain every once in a while on the fly?
while also backing up the deleted blocks
i would like to keep the size of the whole ledger under a certain value, the entire history would not be essential for the functioning of the system
Has joined the channel.
@muralisr sorry. the issue is caused by endorsement policy configuration. i configured the endorsement peers as `peer0.org1.example.com` and `peer0.org2.example.com`, but invoked chaincode using `peer0.org1.example.com` and `peer1.org1.example.com`. correct the invocation peers, the issue will be solved.
@bh4rtp thanks for letting me know.... also meant to respond with questions but was not sure what to go after
glad it got resolved
@gauthampamu I responded through other channels about the query limits from ledger side, but for node sdk specific questions I'd suggest #fabric-sdk-node
@rake66 The feature you are talking about is generally called 'checkpoint', it is indeed part of the fabric roadmap, but not yet committed to a specific release
Upon running some high volume testing, I experienced a failure where all three of my peers failed catastrophically at pretty much the same moment. Upon inspecting the logs, it seems that the peer started to have issues contacting CouchDB and started to retry in a loop. This unfortunately occurred at a point where I was pushing some heavy volume and eventually the peers all failed out when they kept receiving blocks and couldn't process them. That then kicked me over to looking at the Couch logs and there are 0 errors over there. It all looks pretty normal right up to the point when the peers failed and at that point in time, Couch seems to have started compacting the shards. By the time it compacted them all, including shutting down the indexes and reopening them, it was about an hour later. Of course, it only took a second or two for the peer to fail.
What am I missing here? I have tons of questions including why it would take Couch so long to compact (DB was about 0.6 GB in size at this time). Why are there no errors over there if the peer apparently couldn't reach it? Does the compaction process make the DB unavailable? How can I configure couch since it's inside of a docker container? Can I set the log level or any parameters surrounding the compaction process?
What's really odd to me is that all three peers died the same way and within seconds of each other. I mean, the peers are each running in a VM of their own with the Couch container local to the VM. So how could the compaction process have started at nearly the same time? Is compaction triggered by a timer, or a volume/size trigger or something?
Setup:
Fabric 1.1.0, 3rd party images 0.4.6
(3 zookeepers, 4 kafka brokers, 3 orderers, 3 peers w/ couchdb as statedb)... all running in docker
3 separate "app" servers acting as clients and pushing invoke transactions via node sdk randomly against the three peers
In relation to my question earlier about all of my peers dying at the same time... when I bring their docker containers back up it's like they're fresh new peers. I have to join them back to the channel (which is no big deal), but unfortunately that means that they have to gossip in all of the blocks from the beginning. I guess I would have expected them to only have to gossip in blocks from the point of failure up to whatever is current. I suppose my question is more docker related considering I'm using containers. Is there something with the docker setup that would allow the peer to persist it's state from one startup to another? Since I'm working with larger datasets it can take a significant amount of time to gossip in all of the blocks.
Has joined the channel.
Has joined the channel.
Has joined the channel.
If I need to backup the ledger data at a peer, which folder from the filesystem should I backup? In the event of a crash of the infrastructure, will I be able to start the peer once I restore the backedup files ?
What would be the optimum backup strategy for hyperledger fabric peer and couchdb, given that there are no transaction pruning available according to
What would be the optimum backup strategy for hyperledger fabric peer and couchdb?
Should the peer not reconstruct data from the other peers?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=fgLEzASeeGbZRzTYN) @aatkddny The peer certainly *can* reconstruct the data from other peers, however @AbhijeetPal 's question is certainly still valid. What if you have a significant amount of data in your chain and you don't want to wait for all of the blocks to gossip in. From my understanding, bootstrapping a new peer with a copy of blocks is indeed possible but I've not personally done it.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ibCq2MgZvLyZJptwn) @AbhijeetPal I've not done it personally and unfortunately can't give you a step by step, but the chain data should be located at /var/hyperledger/production/ledgersData/chains/chains/
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Tmt8bh7rpeMvLxM5r) @header340
I'd expect you'd run at least two peers on different devices for HA. That drove my question. I couldn't imagine trying to snapshot the drive and restart from there - how would you ensure that the ledger and couchdb are in sync?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=QpSirhL55hWnGo999) @aatkddny Yes, you should be running more than one peer regardless, assuming you want to have any fault tolerance at all. But in my case I've been pushing quite heavy volumes and to bring up a new peer (or restore a failed peer) can take several hours. There is just a lot of data that needs to be gossip'd in. However, if you copy the actual blockfiles from a healthy peer and move them over to your new peer I thought that essentially bootstrapped the chain itself and would remove the need to gossip in the blocks. Again, I haven't done this but I do believe I've read about it being done. As for Couch, I thought any time you restart the peer it rebuilds the world state within Couch. So I don't see there being problems keeping the ledger and couch in sync.
hi, i have a question about transaction count. in my testing fabric network, there are 3 chaincodes `trade`, `check` and `clearing`. and i invoke 36 times of `trade` chaincode, in which one invokes `check` chaincode to put state, and one invokes `clearing` chaincode to put state too. but in the chaincodes page of `blockchain-explorer`, it reads `trade` has 34 transactions, `bid` has 0 transaction, `clearing` has 1 transaction. why does `bid` have no transactions while `clearing` have one transaction?
hi, i have a question about transaction count. in my testing fabric network, there are 3 chaincodes, i.e. `trade`, `check` and `clearing`. and i invoke 36 times of chaincode `trade`, in which one invokes chaincode `check` to put state, and one invokes chaincode `clearing` to put state too. but in the CHAINCODES page of `blockchain-explorer`, it reads `trade` has 34 transactions, `bid` has 0 transaction, `clearing` has 1 transaction.
why does `bid` have no transactions while `clearing` have one transaction?
hi, i have a question about transaction count. in my testing fabric network, there are 3 chaincodes, i.e. `trade`, `check` and `clearing`. and i invoke 36 times of chaincode `trade`, in which one invokes chaincode `check` and puts a state, and one invokes chaincode `clearing` and puts a state too. but in the CHAINCODES page of `blockchain-explorer`, it reads `trade` has 34 transactions, `bid` has 0 transaction, `clearing` has 1 transaction.
why does `bid` have no transactions while `clearing` have one transaction?
@AbhijeetPal @aatkddny @header340 You are generally correct. Please see the ledger backup description here for details: https://jira.hyperledger.org/browse/FAB-3364
@header340 I do not know the cause of your failures. Are they reproducible? If so, please open a Jira bug with full details of reproduction steps.
@header340 By default the docker container data is ephemeral. To persist the data, see this topic: http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=uj6RorZqJke2hgCvJ) @dave.enyeart This https://jira.hyperledger.org/browse/FAB-3364 accompanied with peer and couchdb data persistence would certainly help in case of significant volumes of data
Is there a simple way to set block size? I'm getting 10 tx/block with a set of basic puts and I'd like to up it to increase throughput.
Is there a simple way to set block size? I'm getting 10 tx/block with a set of basic puts and I'd like to up it to increase throughput.
```
2018-06-11 13:28:03.957 UTC [kvledger] CommitWithPvtData -> INFO 071 Channel [stationchannel]: Committed block [1] with 1 transaction(s)
2018-06-11 13:29:18.113 UTC [kvledger] CommitWithPvtData -> INFO 072 Channel [stationchannel]: Committed block [2] with 10 transaction(s)
2018-06-11 13:29:18.602 UTC [kvledger] CommitWithPvtData -> INFO 073 Channel [stationchannel]: Committed block [3] with 10 transaction(s)
2018-06-11 13:29:18.833 UTC [kvledger] CommitWithPvtData -> INFO 074 Channel [stationchannel]: Committed block [4] with 10 transaction(s)
2018-06-11 13:29:19.074 UTC [kvledger] CommitWithPvtData -> INFO 075 Channel [stationchannel]: Committed block [5] with 10 transaction(s)
2018-06-11 13:29:19.305 UTC [kvledger] CommitWithPvtData -> INFO 076 Channel [stationchannel]: Committed block [6] with 10 transaction(s)
2018-06-11 13:29:19.660 UTC [kvledger] CommitWithPvtData -> INFO 077 Channel [stationchannel]: Committed block [7] with 10 transaction(s)
2018-06-11 13:29:19.818 UTC [kvledger] CommitWithPvtData -> INFO 078 Channel [stationchannel]: Committed block [8] with 10 transaction(s)
```
Is there a simple way to set block size? I'm getting 10 tx/block with a set of basic puts and I'd like to up it to increase throughput. I have 200 threads running against this thing and the time to cut the block is proving a limiting factor.
```
2018-06-11 13:28:03.957 UTC [kvledger] CommitWithPvtData -> INFO 071 Channel [stationchannel]: Committed block [1] with 1 transaction(s)
2018-06-11 13:29:18.113 UTC [kvledger] CommitWithPvtData -> INFO 072 Channel [stationchannel]: Committed block [2] with 10 transaction(s)
2018-06-11 13:29:18.602 UTC [kvledger] CommitWithPvtData -> INFO 073 Channel [stationchannel]: Committed block [3] with 10 transaction(s)
2018-06-11 13:29:18.833 UTC [kvledger] CommitWithPvtData -> INFO 074 Channel [stationchannel]: Committed block [4] with 10 transaction(s)
2018-06-11 13:29:19.074 UTC [kvledger] CommitWithPvtData -> INFO 075 Channel [stationchannel]: Committed block [5] with 10 transaction(s)
2018-06-11 13:29:19.305 UTC [kvledger] CommitWithPvtData -> INFO 076 Channel [stationchannel]: Committed block [6] with 10 transaction(s)
2018-06-11 13:29:19.660 UTC [kvledger] CommitWithPvtData -> INFO 077 Channel [stationchannel]: Committed block [7] with 10 transaction(s)
2018-06-11 13:29:19.818 UTC [kvledger] CommitWithPvtData -> INFO 078 Channel [stationchannel]: Committed block [8] with 10 transaction(s)
```
@aatkddny yeah, in the config tx yaml. Batch timeout sets how long it waits until committing a block with whatever it has. batch size is the maximum number of transactions it includes. max bytes is the absolute maximum size for a block and prefered max bytes is a soft limit for the size. as in if it has some room for one more transaction but that transaction brings you over prefered max size, it puts it in anyway. if the transaction would put you over max bytes as well, it leaves it out and puts it in the next block
configtx meaning you have to build the things? not exactly what i had in mind for simple.
hi,
I faced this error on the peer couchdb issue , peer cannot be started again (v1.1.0 fabric). It worked normal until I did some invoking chaincode, then It stopped.
`panic: Error during commit to txmgr:Couch DB Error:illegal_docid, Status Code:400, Reason:Only reserved document ids may start with underscore.`
how to overcome in this situation.
peer log: https://hastebin.com/axeyidogec.go
@aatkddny well, you can also change it on the fly with configtxlator, but that's not necessarily simpler
So no matter what one does there's no way to change the block cut time or size without surgery. One would have thought it would be configurable as an orderer property somewhere, either for the fabric as a whole or for the individual channel.
Can some one pls help to confirm if my state db is leveldb then can I use composite key queries? I did read the doc but not able to get a confirmed answer. Also if I could, appreciate it if you could show me the composite key queries syntax (an example is good enough) for leveldb
@Ryan2 are you trying to use a string that starts with an underscore as a key in a `PutState` call?
@aatkddny no, not really. one orderer should not be able to mandate that there is a new time to cut. if a network needs to change the channel's time to cut, requisite members of that network need to agree as to what that time to cut is.
if you want one organization to be the arbiter of the network, you can make an endorsement policy where changes to network configurations requires the signature of that organizations admin
@l1nux the [marbles chaincode](https://github.com/hyperledger/fabric-samples/blob/release/chaincode/marbles02/marbles_chaincode.go#L208) example has syntax for setting composite keys and querying based on them
@jrosmith thanks, ok... would I be able to make composite-key queries with my state db is leveldb
@l1nux yes i believe you should able to
Clipboard - June 12, 2018 9:18 PM
> So no matter what one does there's no way to change the block cut time or size without surgery
It's configured in the configtx.yaml at the channel creation time.... @aatkddny
but I have to say i really like your analogy.
I see it there now. So I can tune by channel at create time, which will suffice.
Hi @jrosmith , In my chaincode, none of key starting with underscore in `Put_State` call,
The situation is, my network working normal, when I perform some load test, it was fine, but suddenly pump into peer stopped with this error,
I tried to recover, the couchdb recovery was fine til to the point it broke (you can see the recovery of couchdb full log here https://hastebin.com/obafaxoquq.go)
Hi @jrosmith , In my chaincode, none of key starting with underscore in `Put_State` call,
The situation is, my network working normal, when I perform some load test, it was fine, but suddenly pump into peer stopped error as mentioned,
I tried to recover, the couchdb recovery was fine til to the point it broke (you can see the recovery of couchdb full log here https://hastebin.com/obafaxoquq.go)
hi, is privacy enabled ledger still developing? and does it affect client?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=38N6k4WvbSov8fLn9) @Ryan2 - the error is not about the a key starting with an underscore. It's about the name of one of the fields in your JSON value happens to start with an underscore. Can you check and confirm if this is the case?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=38N6k4WvbSov8fLn9) @Ryan2 - the error is not about the a key starting with an underscore. It's about the name of one of the fields in your JSON value happens to start with an underscore. Can you check and confirm if this is the case?
@bh4rtp Private data feature is complete in master and will be delivered as part of v1.2. The only impact to the client is that client passes the collection config as part of chaincode instantiation, as described in this upcoming doc topic: https://gerrit.hyperledger.org/r/#/c/22817/3/docs/source/private-data-arch.rst
@dave.enyeart thanks. are there any differences between reading or writing public data and private data from the respective of client?
@dave.enyeart i have a further question on private data. the endorsement peers and authorized peers have copies of private data with blockToLive configurable (at least 1). but how to guarantee that the endorsement peer outside the authorized organization rebuild the peer docker image and save the private data into its own database permanently?
hi @manish-sethi , you are right, actually, I sent invoking transaction which starting with underscore for 1 field, and this error happened.
I tried to recover and here is the log the this issue: document id contained underscore at the beginning
https://hastebin.com/vucixoyavu.go
I referred to https://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html
As I understood is that in the fabric v1.1.0, in the request, JSON document cannot use the underscore as the starting for any field
So In my case, issue had already happened, So is it possible to recover and continue using existing fabric network,
Or abandon this network and avoid underscore?
hi @manish-sethi , you are right, actually, I sent invoking transaction which starting with underscore for 1 field, and this error happened.
I tried to recover and here is the log the this issue: document id contained underscore at the beginning
https://hastebin.com/vucixoyavu.go
I referred to https://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html
As I understood is that in the fabric v1.1.0, in the request, JSON document cannot use the underscore as the starting for any field
So In my case, issue had already happened, I cannot start the peers again due to this error, So is it possible to recover and continue using existing fabric network,
Or abandon this network and avoid underscore?
There is no immediate remedy and would require to develop a patch specifically for this situation - which may take some time. So, if proceeding with a fresh network is a possibility, I would advise to go ahead. If enough folks end up making this mistake, a patch may be worth it. Going forward, we will add this check at the time of simulation so that these mistakes get caught at the simulation time.
thank you @manish-sethi
side db
Has left the channel.
hey all, looking for some help with updating a channel. i have a network with N orgs, and i first updated the [Admin policy](https://hastebin.com/kuqukanepi.pl) to require only the signature of the first organization instead of it being the "MAJORITY" rule.
afterwards i tried to do another channel update only using the first organization, updating the [BatchTimeout time](https://hastebin.com/uculafiled.scala) but received a [BAD REQUEST](https://hastebin.com/ogigavojoq.vbs) error. but in my first update i thought i took out the sub policy?
[full original channel configuration](https://hastebin.com/uvovudeqeb.json) and [full config after the first update](https://hastebin.com/ifoqafakuh.json) for reference.
@jrosmith I'd suggest post in #fabric-orderer , as the folks over there also deal with channel config items like this
thanks dave
@bh4rtp In terms of interacting with private data from chaincode, the same operations are possible for regular data and private data, see the description in https://gerrit.hyperledger.org/r/#/c/22817/3/docs/source/private-data-arch.rst for more details of the chaincode APIs supported.
If a new peer comes online or gets rebuilt, if the peer is a member of the private data collection it will request the private data from one of the other collection member peers as it commits the blocks, and will commit the private data to private state db at the same time. If the peer is NOT a member of the private data collection, it will not request the private data (nor will other members provide the private data if asked).
@dave.enyeart Is there support for Views with Map Reduce capability in CouchDB. Can we generate a report that aggregates data. For example can we generate the result set with composite key and aggregate (sum/averages) the columns.
@dave.enyeart Is there support for Views with Map Reduce capability in CouchDB. Can we generate a report that aggregates data. For example can we generate the result set with composite key and aggregate (sum/averages) the attributes.
I am getting this error while trying to instantiate chaincode on peer1 of org1.
NodeJS console error :
`Failed to send Proposal and receive all good ProposalResponse
Failed to instantiate. cause:Failed to send Proposal and receive all good ProposalResponse
(node:25005) UnhandledPromiseRejectionWarning: Error: Failed to instantiate. cause:Failed to send Proposal and receive all good ProposalResponse`
Blockchain console error :
`ERRO 692 [[e9585782 PUT_STATE ERROR]]No ledger context for %!!(MISSING)s(MISSING). Sending %!!(MISSING)s(MISSING)
ERRO 6a2 [bloqchannel][e9585782] failed to invoke chaincode name:"lscc" , error: timeout expired while executing transaction`
I am using Hyperledger Fabric 1.1 and Hyperledger fabric node SDK. The nodeJS version is 8.11.2. The chaincode is in golang.
Any help is appreciated.
Has joined the channel.
/
Hello All, when using CouchDB, if I delete a key/value in the chaincode, will at some point after the commit, the couchdb documents associated with the key be automatically cleaned up? Is there and housekeeping required ? Does the fabric keep a document with a record that the key was deleted ?
I'm assuming its good practice to get rid of key/values that are no longer required.
I realise the history of the key value will be retained in the ledger.
@gauthampamu There is a Jira requirement to support CouchDB views: https://jira.hyperledger.org/browse/FAB-5528. It is not yet targeted for a release. For anything more advanced than the JSON selector queries that are already supported, the recommendation is to listen on the block events and create an external datastore optimized for the types of queries you need.
@rsherwood When the chaincode delete key transaction is committed to ledger, the delete will indeed be committed to couchdb state database as well. For example, if a subsequent chaincode tries to read that key, it will not be found.
@dave.enyeart i take `marbles02_private` as an example to learn private data. and still have trouble in invoking chaincode. the chaincode was instantiated successfully. but initMarble failed for `Failed disseminating 1 out of 2 private RWSets`.
There are different operations and configurations to deal with private data using node sdk, i.e. collections_config.json, `endorsement_policy` and `collections_config` in the instantiate chaincode and `network_config.yaml`. how to make sure they are consistent?
@dave.enyeart i take `marbles02_private` as an example to learn private data. and still have trouble in invoking chaincode. the chaincode was instantiated successfully. but initMarble failed for `Failed disseminating 1 out of 2 private RWSets`.
There are different operations and configurations to deal with private data using node sdk, i.e. 1) policy in collections_config.json, 2) `endorsement_policy` and `collections_config` in the instantiate chaincode and 3) endorsement configuration in network yaml file.what are the differences between them?
@dave.enyeart i take `marbles02_private` as an example to learn private data. and still have trouble in invoking chaincode. the chaincode was instantiated successfully. but initMarble failed for `Failed disseminating 1 out of 2 private RWSets`.
There are distributed operations and configurations to deal with private data using node sdk, i.e. 1) configtx.yaml file to create channel, 2) policy in collections_config.json, 3) `endorsement_policy` and `collections_config` in the instantiate chaincode and 4) endorsement configuration in network yaml file.what are the relations and differences between them?
@dave.enyeart i take `marbles02_private` as an example to learn private data. and still have trouble in invoking chaincode. the chaincode was instantiated successfully. but initMarble failed for `Failed disseminating 1 out of 2 private RWSets`.
There are distributed operations and configurations to deal with private data using node sdk, i.e. 1) configtx.yaml file to create channel, 2) policy in `collections_config.json`, 3) `endorsement_policy` and `collections_config` in the instantiate chaincode and 4) channel peer configurations in network yaml file. what are the relations and differences between them?
@dave.enyeart i take `marbles02_private` as an example to learn private data. and still have trouble in invoking chaincode. the chaincode was instantiated successfully. but initMarble failed for `Failed disseminating 1 out of 2 private RWSets`.
There are distributed operations and configurations to deal with private data using node sdk, i.e. 1) configtx.yaml file to create channel, 2) policy in `collections_config.json`, 3) `endorsement_policy` and `collections_config` in the instantiate chaincode and 4) channel peer configurations in network yaml file. what are the relationship and differences between them?
Has joined the channel.
Has joined the channel.
Has joined the channel.
hi, one question about CouchDB safe pagination, i found https://jira.hyperledger.org/browse/FAB-2809. Is this feature part of upcoming 1.2 release? And one more thing, is there chaincode example(or best practice) how pagination can be implemented in 1.1 ?
Has joined the channel.
Has joined the channel.
Has anyone actually successfully backed up and restored the ledger when running hyperledger fabric with Kafka. I can't get it to work. Should I be able to backup the ledger stored on the orderer? Am I expected to backup Kafka instead? How can I actually run this in production and have a plan for if I loose the entire cluster? Please help. Real world experience would be helpful.
sbft
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
is there an identifier in the peer log in the instantiation when you try to add private data to a chaincode
is there an identifier in the peer log in the instantiation when you try to add private data to a chaincode? trying to see if the code does what i think it does. or does it do it the first time it's used?
ummm i don't think it's possible @aatkddny
how can you add private data during instantiate?
there is no collection definition
channel can be between org or between peer? Can I create channel between peers of same org?
Has joined the channel.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=eZ9Hh5iizQizui4Ey) @yacovm I wasn't clear enough in my question.
What I *meant* to say was - when I *try* to instantiate a chaincode which uses private data - using an extra definition file as per the instructions, is there anything in the peer at chaincode instantiation time to tell me that it parsed and accepted same. I don't care what it is, a call to the couch container to set up another table, a log message saying something is ok or not, pretty much anything at all I can see that signals to me that my configuration was correct before I go off and write something to test that the private data works how I think it works.
Or alternately is all the setup done on the first call, and I need to look for errors then?
Hopefully that makes more sense.
@aatkddny you can't use private data writes when you instantiate a chaincode
since you define the collection at instantiation time....
you can't write private data at the time of instantiation since the collection isn't defined yet in the system
I get that. And that's my question. Is there anything that says it defined it properly at instantiation time.
I'm not trying to write to it. I'm trying to check I defined it correctly.
ohhh
you're asking if is there anything that checks that the collection policy is correctly defined?
yes.
exactly that
what would you consider correctly defined?
able to create. syntactically correct. pretty much anything that says go forward and try to write to it.
so recall instantiation is simply an endorsement.
the checks are done at commit time (validation)
so you need to see if the transaction was successfully validated
so you are saying that any first time initialization is done at first invoke rather than chaincode instantiation.
no
when you instantiate - you need to wait for the block to be committed
and then see if the instantiate succeeded or not since it's a transaction
fiar enough. so the tx success back means it was sound.
i was hoping to see some evidence in the peer log that it knew there was private data associated with this particular chaincode is all.
that way - since i'm using an SDK which adds another level of abstraction - I could be comfortable that it was all good.
i'll just assume it's all good and try adding some private data.
fair enough. so the tx success back means it was sound.
i was hoping to see some evidence in the peer log that it knew there was private data associated with this particular chaincode is all.
that way - since i'm using an SDK which adds another level of abstraction - I could be comfortable that it was all good.
i'll just assume it's all good and try adding some private data.
but the application doesn't have access to the peer log
no but i do.
docker log...
Has joined the channel.
Has joined the channel.
is there a specific reason why a key version is not just a counter rather than (blockNum,TxID)?
With just a counter, it would be difficult to find the previous transaction that modified a key. The blockNum + txID gives you a link back.
@adc Additionally, with a counter any deletes/re-creates would reset the counter and lead to confusion about state, and therefore a placeholder record with a version would have to remain after the delete, something we didn't want to burden the state database with.
while i trying to retrive the data frequently, I got the following error in Peer logs
`2018-07-09 04:06:38.612 UTC [endorser] simulateProposal -> ERRO 79dc0 [smschannel3][26ceb252] failed to invoke chaincode name:"xxxxx" , error: timeout expired while executing transaction
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:813
github.com/hyperledger/fabric/core/chaincode.Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/exectransaction.go:58
github.com/hyperledger/fabric/core/chaincode.ExecuteChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincodeexec.go:85
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:93
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:132
github.com/hyperledger/fabric/core/endorser.(*Endorser).simulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:265
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:491
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:781
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:981
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:551
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:2337
failed to execute transaction
error executing chaincode
2018-07-09 04:06:38.627 UTC [chaincode] isValidTxSim -> ERRO 79dc1 [920518c0]No ledger context for GetStateByRange. Sending ERROR
2018-07-09 04:06:38.629 UTC [dev-org0-peer0-SMS_CC_002-t1] func2 -> INFO 79dc2 2018-07-09 04:06:38.422 UTC [shim] handleGetStateByRange -> ERRO d24b [38e7d93d]Received ERROR
2018-07-09 04:06:38.632 UTC [dev-org0-peer0-SMS_CC_002-t1] func2 -> INFO 79dc3 2018-07-09 04:06:38.422 UTC [shim] handleGetStateByRange -> ERRO d24c [6361b54f]Received ERROR
2018-07-09 04:06:38.633 UTC [dev-org0-peer0-SMS_CC_002-t1] func2 -> INFO 79dc4 2018-07-09 04:06:38.426 UTC [shim] handleGetStateByRange -> ERRO d24d [0db44ff4]Received ERROR
2018-07-09 04:06:38.634 UTC [dev-org0-peer0-SMS_CC_002-t1] func2 -> INFO 79dc5 2018-07-09 04:06:38.426 UTC [shim] handleGetStateByRange -> ERRO d24e [2a96bee3]Received ERROR
2018-07-09 04:06:38.636 UTC [dev-org0-peer0-SMS_CC_002-t1] func2 -> INFO 79dc6 2018-07-09 04:06:38.430 UTC [shim] handleGetStateByRange -> ERRO d24f [aac6d03e]Received ERROR```
``` `
Any suggestion ?
I am trouble :(
Has joined the channel.
@sheehan @dave.enyeart thanks for the answer. The point is that in this way, it is not possible for a submitting peer to construct a set of transactions with dependencies that it can hope will be merged without conflicts. With the current model, a client has to first submit an endorsed transaction then wait for commit confirmation and then submit another transaction depended on the previous one.
@adc I think there is a (rather ugly) way around this - you can use commutative keys and a custom validation plugin that enforces double spending and other logic, and then when you read the state- you do range queries and infer the data from the updates of the commutative keys
of course - to make this scale and not bloat you'll have to issue transactions that do "garbage collection" to these update keys
skip and limit is not working in "GetQueryResult". please anyone help me on this?
@rajivgandhi2010 skip and limit is not yet supported. The intent is to add support for pagination of couchdb queries in v1.3, see https://jira.hyperledger.org/browse/FAB-2809 for discussion.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=nqEbkfuRBoHmCpzeP) @dave.enyeart Thank you Dave..
Has joined the channel.
@adc understand that pain point. We're working on a solution for 1.3.
https://jira.hyperledger.org/browse/FAB-10711
are you able to share your use case? We're collecting a list to ensure the solution satisfies the problems people are encountering
Has joined the channel.
I notice idemixgen is not built into fabric-tools docker image. Is that true in v1.2?
Has joined the channel.
Has joined the channel.
@sheehan, thanks for the reference :)
Has joined the channel.
Has joined the channel.
Hi, I notice that FAB-7330 describes a problem if multiple nodes in the kafka cluster go down as kafka does not flush all data to disk. In FAB-7330 it describes the circumstances when this was caused by an upgrade, and is fixed by making the upgrade gracefully shut down. What would happen if the failure was not caused by upgrade but by for example a hardware failure of a server ? Is there a way of recovering from this scenario. Is there a possibility for example that one of the orderers ledgers contain a block with transactions in that the kafka no longer has, and would that matter ?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=J6F3Bc4egFNxt2uug) Looking further I see that http://grokbase.com/t/kafka/users/162rashxyz/unable-to-start-kafka-cluster-after-crash-0-8-2-2 mentions a way of getting the Kafka cluster up but with data loss. What would the orders make of this, and how should the system be recovered ?
@rsherwood Could I ask you to re-post over in #fabric-orderer , as the kafka experts hang out over there...
Has joined the channel.
Has joined the channel.
Has joined the channel.
If i restart the system, the ledger data are lost. Is there any way to hold the records?
@rajivgandhi2010 I assume you are using ephemeral docker containers...you'll want to configure docker for data persistence e.g. http://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=NWrzRtvYqBHwMLksj) @dave.enyeart thank you..
anyone can share me the latest ledger design document? many thanks
Has joined the channel.
Has joined the channel.
@dave.enyeart or any other developer: In which piece of code can I find how the data structure of the chain (incl. update of that structure) is determined?
@SjirNijssen It can be difficult to parse through because there are many layers of serialized objects represented as bytes in the protos, but I'd still suggest to start by reading through the proto files. See block structure here as the starting point: https://github.com/hyperledger/fabric/blob/release-1.2/protos/common/common.proto#L161-L176. The BlockData is an array of Envelopes holding Transactions which have Proposals and ProposalResponses. Especially see the comments within transaction.proto, proposal.proto, proposal_response.proto.
@richzhao As a starting point I'd suggest look at the doc http://hyperledger-fabric.readthedocs.io/en/latest/ledger/ledger.html and ledger overview charts in https://jira.hyperledger.org/browse/FAB-758
thanks @dave.enyeart
@dave.enyeart Thanks Dave
Has joined the channel.
Hello everyone, Can anyone help? I am getting the issue "[[69b0d0ec PUT_STATE ERROR]]No ledger context for %!!(MISSING)s(MISSING). Sending %!!(MISSING)s(MISSING)" while instantiating the chaincode using cli container
@sykesm Any clue on the above error? Just curious if the message may have gotten mangled during the chaincode refactoring?
Has joined the channel.
What is the best way to manually create a minimal block that is accepted by the peer?
Currently I fail in the VerifyBlock method in the peer beause
```ERRO 24b [my-channel] Error verifying block with sequnce number 15725, due to Failed getting channel id from block with id [15725] on channel [my-channel]: [failed to retrieve channel id - block is empty]
```
because my block does not contain any transactions.
https://github.com/hyperledger/fabric/blob/5a6e86267d8436be1c862b9d542e0c21f60fbe7b/peer/gossip/mcs.go#L120
@anzalbeg what version of fabric?
@dave.enyeart fwiw, the log message referenced by @anzalbeg does not exist in 1.2 so it's pre-refactor.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=TY9oriuq4rJ2zCMgC) @sykesm by the way i am also getting teh same issue while deploying fabric on kubernetes
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=TY9oriuq4rJ2zCMgC) @sykesm by the way i am also getting teh same issue while deploying fabric on kubernetes. i am using fabric 1.1
Has joined the channel.
@dave.enyeart when i restart the peer` panic: Error while trying to open DB: resource temporarily unavailable`
@dave.enyeart when i restart the peer `panic: Error while trying to open DB: resource temporarily unavailable`
the peer data is persistent
https://chat.hyperledger.org/channel/fabric-ledger?msg=osSBBm93DGdi2Dhk9
@anzalbeg @javrevasandeep ^^^ above typically means the chaincode came back after the app the proposal timed out and cleaned up. This could happen if the proposal processing took more than the timeout value set in the core.yaml for some reason. Should be easy to tell if this is the case based on logs
@anzalbeg @javrevasandeep ^^^ above typically means the chaincode came back after proposal timed out waiting for chaincode and went away after cleaning up. This could happen if the proposal processing took more than the timeout value set in the core.yaml for some reason. Should be easy to tell if this is the case based on logs
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=oEAisAzxQoPXTEr96) @muralisr Thanks. I resolved the issue but i getting another error while invoking the transaction
below given is my peer logs
2018-07-25 05:59:45.983 UTC [shim] func1 -> DEBU 74d [0ebe1dea]Received message TRANSACTION from shim
2018-07-25 05:59:45.983 UTC [shim] handleMessage -> DEBU 74e [0ebe1dea]Handling ChaincodeMessage of type: TRANSACTION(state:ready)
2018-07-25 05:59:45.984 UTC [shim] beforeTransaction -> DEBU 74f [0ebe1dea]Received TRANSACTION, invoking transaction on chaincode(Src:ready, Dst:ready)
2018-07-25 05:59:45.984 UTC [vscc] Invoke -> DEBU 750 VSCC invoked
2018-07-25 05:59:45.984 UTC [vscc] deduplicateIdentity -> DEBU 751 Signature set is of size 1 out of 1 endorsement(s)
2018-07-25 05:59:45.984 UTC [vscc] Invoke -> WARN 752 Endorsement policy failure for transaction txid=bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9, err: signature set did not satisfy policy
2018-07-25 05:59:45.984 UTC [shim] func1 -> DEBU 753 [0ebe1dea]Transaction completed. Sending COMPLETED
2018-07-25 05:59:45.984 UTC [shim] func1 -> DEBU 754 [0ebe1dea]Move state message COMPLETED
2018-07-25 05:59:45.985 UTC [shim] handleMessage -> DEBU 755 [0ebe1dea]Handling ChaincodeMessage of type: COMPLETED(state:ready)
2018-07-25 05:59:45.985 UTC [shim] func1 -> DEBU 756 [0ebe1dea]send state message COMPLETED
2018-07-25 05:59:45.985 UTC [chaincode] processStream -> DEBU 757 [0ebe1dea]Received message COMPLETED from shim
2018-07-25 05:59:45.985 UTC [chaincode] handleMessage -> DEBU 758 [0ebe1dea]Fabric side Handling ChaincodeMessage of type: COMPLETED in state ready
2018-07-25 05:59:45.985 UTC [chaincode] handleMessage -> DEBU 759 [0ebe1dea-fd85-43b1-a291-b5aa50093a48]HandleMessage- COMPLETED. Notify
2018-07-25 05:59:45.985 UTC [chaincode] notify -> DEBU 75a notifying Txid:0ebe1dea-fd85-43b1-a291-b5aa50093a48, channelID:mychannel
2018-07-25 05:59:45.985 UTC [chaincode] Execute -> DEBU 75b Exit
2018-07-25 05:59:45.985 UTC [lockbasedtxmgr] Done -> DEBU 75c Done with transaction simulation / query execution [bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9]
2018-07-25 05:59:45.985 UTC [committer/txvalidator] VSCCValidateTxForCC -> DEBU 75d VSCCValidateTxForCC completes for envbytes 0xc421e98800
2018-07-25 05:59:45.985 UTC [committer/txvalidator] VSCCValidateTx -> DEBU 75e VSCCValidateTx completes for env 0xc423166e10 envbytes 0xc421e98800
2018-07-25 05:59:45.985 UTC [committer/txvalidator] validateTx -> ERRO 75f VSCCValidateTx for transaction txId = bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9 returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy
2018-07-25 05:59:45.985 UTC [committer/txvalidator] validateTx -> DEBU 760 validateTx completes for block 0xc42359a640 env 0xc423166e10 txn 0
2018-07-25 05:59:45.986 UTC [committer/txvalidator] Validate -> DEBU 761 got result for idx 0, code 10
2018-07-25 05:59:45.986 UTC [committer/txvalidator] Validate -> DEBU 762 END Block Validation
2018-07-25 05:59:45.987 UTC [kvledger] CommitWithPvtData -> DEBU 763 Channel [mychannel]: Validating state for block [4]
2018-07-25 05:59:45.987 UTC [lockbasedtxmgr] ValidateAndPrepare -> DEBU 764 Validating new block with num trans = [1]
2018-07-25 05:59:45.987 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 765 ValidateAndPrepareBatch() for block number = [4]
2018-07-25 05:59:45.987 UTC [valimpl] ValidateAndPrepareBatch -> DEBU 766 preprocessing ProtoBlock...
2018-07-25 05:59:45.987 UTC [valimpl] preprocessProtoBlock -> WARN 767 Channel [mychannel]: Block [4] Transaction index [0] TxId [bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9] marked as invalid by committer. Reason code [ENDORSEMENT_POLICY_FAILURE]
i am getting this "2018-07-25 05:59:45.985 UTC [committer/txvalidator] validateTx -> ERRO 75f VSCCValidateTx for transaction txId = bbae754cdb42ccf121ecb77eecfd51190c618416ffabc59dcce47f02693957a9 returned error: VSCC error: endorsement policy failure, err: signature set did not satisfy policy"
Hi Experts
I am trying to invoke a chaincode function. The couchdb is taking almost 15 seconds to serve 3 request to fabric (2 query and 1 write operation)
Here are the peer logs ==> https://hastebin.com/ezihededuq.md
Orderer logs ==> https://hastebin.com/enebuxuval.coffeescript
But when i directly query couchdb it only takes few milliseconds
If anyone knows
please help
Here `couchdb` took 5 seconds | line 5 & 6 ```2018-07-25 11:50:47.300 IST [couchdb] handleRequest -> DEBU 15cd HTTP Request: GET /assetchain_assetchaincode/_design/lastnameasc/_view/lastnameasc?stale=update_after HTTP/1.1 | Host: couchdb:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Accept-Encoding: gzip | |
2018-07-25 11:50:52.309 IST [couchdb] handleRequest -> DEBU 15ce Exiting handleRequest()```
Line 9 & 10 `couchdb` took 4 seconds ```2018-07-25 11:50:52.309 IST [couchdb] handleRequest -> DEBU 15d1 HTTP Request: GET /assetchain_assetchaincode/_design/lastnamedesc/_view/lastnamedesc?stale=update_after HTTP/1.1 | Host: couchdb:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Accept-Encoding: gzip | |
2018-07-25 11:50:56.991 IST [endorser] ProcessProposal -> DEBU 15d2 Entering: Got request from 192.168.0.18:60858```
Line 68 - 69 `couchdb` took 5 seconds again ```2018-07-25 11:50:57.322 IST [couchdb] handleRequest -> DEBU 160c HTTP Request: GET /assetchain_assetchaincode/_design/request_created_at_sort_asc/_view/request_sorting?stale=update_after HTTP/1.1 | Host: couchdb:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Accept-Encoding: gzip | |
2018-07-25 11:51:02.007 IST [couchdb] handleRequest -> DEBU 160d Exiting handleRequest()```
line 259-260 `couchdb` took 2 seconds ```2018-07-25 11:51:02.335 IST [couchdb] handleRequest -> DEBU 1699 HTTP Request: GET /assetchain_assetchaincode/_design/request_sort_name_asc/_view/request_sort_name_asc?stale=update_after HTTP/1.1 | Host: couchdb:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Accept-Encoding: gzip | |
2018-07-25 11:51:04.123 IST [policies] Evaluate -> DEBU 169a == Evaluating *policies.implicitMetaPolicy Policy /Channel/Orderer/BlockValidation ==```
line 293-294 `couchdb` took 2 seconds ```2018-07-25 11:51:04.125 IST [couchdb] handleRequest -> DEBU 16bb HTTP Request: GET /assetchain_lscc/assetchaincode?attachments=true HTTP/1.1 | Host: couchdb:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Accept-Encoding: gzip | |
2018-07-25 11:51:06.071 IST [endorser] ProcessProposal -> DEBU 16bc Entering: Got request from 192.168.0.18:60858```
line 381-382 `couchdb` took 2 seconds 2018-07-25 11:51:07.346 IST [couchdb] handleRequest -> DEBU 1713 HTTP Request: GET /assetchain_assetchaincode/_design/request_sort_name_dsc/_view/request_sort_name_dsc?stale=update_after HTTP/1.1 | Host: couchdb:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Accept-Encoding: gzip | |
2018-07-25 11:51:09.137 IST [couchdb] handleRequest -> DEBU 1714 Exiting handleRequest()
line 381-382 `couchdb` took 2 seconds ```2018-07-25 11:51:07.346 IST [couchdb] handleRequest -> DEBU 1713 HTTP Request: GET /assetchain_assetchaincode/_design/request_sort_name_dsc/_view/request_sort_name_dsc?stale=update_after HTTP/1.1 | Host: couchdb:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Accept-Encoding: gzip | |
2018-07-25 11:51:09.137 IST [couchdb] handleRequest -> DEBU 1714 Exiting handleRequest()```
line 489-490 `couchdb` took 3 seconds ```2018-07-25 11:51:09.338 IST [couchdb] handleRequest -> DEBU 177c HTTP Request: GET /assetchain_/statedb_savepoint?attachments=true HTTP/1.1 | Host: couchdb:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Accept-Encoding: gzip | |
2018-07-25 11:51:12.356 IST [couchdb] handleRequest -> DEBU 177d Exiting handleRequest()```
```func AddUser(stub shim.ChaincodeStubInterface, args []string) peer.Response {
if len(args) != 9 {
return createErrorResponse("Invalid number of arguments. Expected 9", 422, nil)
} else if len(args[4]) == 0 { //Phone number validation
return createErrorResponse("Please enter a valid phone number", 422, nil)
}
var emailArr = []string{args[5]}
var phoneArr = []string{args[4]}
var empID = []string{args[2]}
var emailValidateResponse = CheckEmail(stub, emailArr)
var phoneValidateResponse = CheckPhone(stub, phoneArr)
var empIDValidateResponse = CheckEmployeeID(stub, empID)
if emailValidateResponse.Status == 500 {
return emailValidateResponse
} else if phoneValidateResponse.Status == 500 {
return phoneValidateResponse
} else if empIDValidateResponse.Status == 500 {
return empIDValidateResponse
}
var randomPassword = args[8]
var hashedPassword = xhashes.SHA256(randomPassword)
phoneNumber, phoneConvError := strconv.ParseUint(args[4], 10, 64)
timeNow := time.Now().UTC()
id := args[7]
if phoneConvError != nil {
return shim.Error(phoneConvError.Error())
}
user := User{
FirstName: args[0],
LastName: args[1],
EmpID: args[2],
DocType: "user",
Password: hashedPassword,
CountryCode: args[3],
PhoneNumber: phoneNumber,
Email: args[5],
Role: 0,
DeviceToken: args[6],
Status: 1,
IsRandomPassword: true,
CreatedAt: timeNow,
UpdatedAt: timeNow}
userBytes, err := json.Marshal(user)
if err != nil {
return shim.Error(err.Error())
}
putStateError := stub.PutState(id, userBytes)
fmt.Println("User Record => " + string(userBytes))
fmt.Println("Hashed Password ==> " + hashedPassword)
if putStateError != nil {
return shim.Error(putStateError.Error())
}
userResponse := UserResponse{
ID: id,
GeneratedPassword: randomPassword,
Email: args[5],
FirstName: args[0],
LastName: args[1]}
response := Response{
Status: 1,
Message: "User created successfully",
Data: userResponse}
responseBytes, respError := json.Marshal(response)
if respError != nil {
return shim.Error(respError.Error())
}
fmt.Println("Hashed Last Password ==> " + hashedPassword)
return shim.Success(responseBytes)
}```
This is the chaincode function that is executed and logs belong to this function
newscreen.png
I have posted this on SO here is the link https://stackoverflow.com/questions/51515097/hyperledger-fabric-performance-issue-with-couchdb
Has joined the channel.
In our application the key value pairs quickly reach a final state that the application no longer needs. This means the couchdb will continue to grow over time. I am contemplating writing a cleanup fabric chaincode transaction that deletes (a maximum number at a time) of these final value key value pairs so that the couchDB is just left with the tombstones. We could manually removed the tombstones by copying the couchDB if we ever needed to using CouchDB utilities. In this way our couchDB size should be limited.
I've been asked to check with the experts if anyone can see a downside, and that this is the best way of doing the couchDB housekeeping, and that this is not going to interfere with any potential archiving / check pointing designs?
Has joined the channel.
the write doesn't complete until the block is cut. the default is 2s. perhaps that's the issue...
@rsherwood fabric has no need for tombstones, and has no intention of using them in the future (they are only used for couchdb replication purposes, which fabric doesn't utilize). My understanding is that they are tiny and harmless. How exactly do you propose to delete them with CouchDB utilities?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=zP37BpR8SvnCxQzJg) @dave.enyeart Hi Dave, at this stage I don't plan to get rid of them . However https://eclipsesource.com/blogs/2015/04/20/how-to-finally-delete-documents-in-couchdb/ suggest it would be possible to create a filtered replica if we ever need to (note I've not tested and am no CouchDB expert) . My real question was is the deleting the redundant key / values good practice through Fabric transactions good practice ? I assume its yes its just the customer asked me to check .
yes, when the lifecycle of a key comes to a logical conclusion, it is good practice to delete from current state. the history will remain on the chain regardless.
yes, when the lifecycle of a key comes to a logical conclusion, it is good practice to delete from current state via a chaincode call. the history will remain on the chain regardless.
@dave.enyeart @manish-sethi
Scenario:
- a channel exists, with a number of chaincodes installed
- a new peer joins the channel; it doesn't have (some of the) chaincodes installed (yet)
So, let's say peer 5 joins channel C on which chaincode X is instantiated; but peer 5 doesn't have chaincode X installed.
Is peer 5 supposed to maintain a stateDB for channel C/chaincode X? If yes, then I wonder why I see a log entry like this:
07-26 13:02:22.829 UTC [cceventmgmt] HandleChaincodeDeploy -> INFO 412 Channel [default]: Chaincode [Name=X, Version=v0, Hash=[]byte{...}] is not installed hence no need to create chaincode artifacts for endorsement
Skipping HandleChaincodeDeploy, that implies that the CouchDB statedb downstream isn't notified that a new chaincode needs to have a statedb associated - and the corresponding entities are not created; on the other hand, if that was not skipped, CouchDB wouldn't be able to create the proper indexes for chaincode X because the peer doesn't have the chaincode package installed
@minollo - in your scenario, the peer 5 will have the stateDB because, its required for performing the transaction validation at commit time. However, chaincode is not required to be installed. Since, the index definition are bundled in the chaincode package hence it is skipped.
Other way to look at this is that the peer 5 is a committer-only node and not a full endorser node
@manish-sethi ok; so, considering the CouchDB HandleChaincodeDeploy listener execution is skipped, how does CouchDB create its own artifact to manage the statedb for chaincode X?
@minollo - Since, there is no chaincode on this peer, you will not be able to invoke any chaincode function anyways
@manish-sethi that's not my question; you still need the CouchDB artifacts to do validation for that chaincode, right? That's what you wrote above
No, since we allow only range queries in the read-write transaction, so it works without indexes
sure, but ignore indexes for a moment
To add to that, When you later install the chaincode on the peer, the indexes etc will get created
doesn't CouchDB also create a specific database (or whatever they are called in CouchDB) to dedicate it to the representation of a chaincode's stateDB?
isn't that' performed as part of the listener code on handlechaincodedeploy?
No, the db gets created without chaincode
ok; so, indexes aside, what you are saying is that there is no specific code we do for couchdb statedb when a new chaincode is created
hence, skipping the listener execution is safe
yes
ok, got it; thanks
:thumbsup:
Has joined the channel.
Has left the channel.
hey all, is instantiation no longer considered a transaction? for example lets say i'm deploying chaincode `testcc` on channel `mychannel`, after instantiation i do not see a database of `mychannel_testcc` in couchDB
@jrosmith state databases are created upon first use, not necessarily at instantiate time
if instantiate inits some data or deploys a couchdb index, it will auto-create the database
otherwise database will get created upon first use
@dave.enyeart is there documentation somewhere with an example of setting up couchdb indices within the chaincode?
and i'm assuming that will only write those indices for a given statedb, not for all peers. if my chaincode is in go would I be able to throw index creation into the `init` function so every instance of the chaincode sets up its respective statedb?
yes, the docs point to a sample: https://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html#using-couchdb-from-chaincode
indexes defined in the chaincode get auto-created on each peer once the chaincode is installed on peer and instantiated on channel
this is described in the same doc
ahi see, reading through it now. thank you so much
you cannot create indexes via chaincode... you would have to upgrade the chaincode to a new definition
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=JSca26QEsrvAcziBi) In which version this behaviour was introduced ? @dave.enyeart
in v1.1, as that is when the state database structured changed to channel_chaincode
in v1.1, as that is when the state database structure changed to channel_chaincode
in v1.1, as that is when the state database structure changed to database per channel_chaincode
hey all, looking for more info on coucDB user creation. i know the peer automatically adds the admin as configured in `core.yaml` to the `admins`, but is there way to preconfigure users who fall under `members` of a specific couchDB database? or will I have to add those users to the database via couchDB directly.
for context i want to set up a couchDB user who has read only access of a given stateDB.
hey all, looking for more info on couchDB user creation. i know the peer automatically adds the admin as configured in `core.yaml` to the `admins`, but is there way to preconfigure users who fall under `members` of a specific couchDB database? or will I have to add those users to the database via couchDB directly.
for context i want to set up a couchDB user who has read only access of a given stateDB.
hey all, looking for more info on couchDB user creation. i know the peer automatically adds the admin as configured in `core.yaml` to the `admins`, but is there way to preconfigure users who fall under `members` of a `channel_chaincode` databases? or will I have to add those users to the database via couchDB directly?
for context i want to set up a couchDB user who has read only access of a given stateDB.
hey all, looking for more info on couchDB user creation. i know the peer automatically adds the admin as configured in `core.yaml` to the `admins`, but is there way to preconfigure users who fall under `members` of a `
hey all, looking for more info on couchDB user creation. i know the peer automatically adds the admin as configured in `core.yaml` to the `admins`, but is there way to preconfigure users who fall under `members` of `
Has joined the channel.
Has joined the channel.
Hi guys
{ key: "a",
version: {
block_num: {
low: 4,
high: 0,
unsigned: true
},
tx_num: {
low: 0,
high: 0,
unsigned: true
}
}
{ key: "a",
version: {
block_num: {
low: 4,
high: 0,
unsigned: true
},
tx_num: {
low: 0,
high: 0,
unsigned: true
}
}
How do I get the the invoked function name and the argument from the transaction proposal data. I've tried using the data as a buffer in nodejs and then printing that buffer as a string but I'm not able to decode it in a perfect string. For example, consider the invocation : '{"Args":["init","A","100","B","200"]}', the string that I'm getting after trying what I've mentioned above is -> '\n{\b\u0001\u0012\u0006\u0012\u0004lscc\u001ao\n\u0006deploy\n\tmychannel\n*\n(\b\u0001\u0012\f\u0012\u0005mycc2\u001a\u00031.0\u001a\u0016\n\u0004init\n\u0001A\n\u0003100\n\u0001B\n\u0003200\n"\u0012\f\u0012\n\b\u0001\u0012\u0002\b\u0000\u0012\u0002\b\u0001\u001a\b\u0012\u0006\n\u0004Org1\u001a\b\u0012\u0006\n\u0004Org2\n\u0004escc\n\u0004vscc'. Is there any way to get the above in the form of '{"Args":["init","A","100","B","200"]}'
can I ask what is different between MVCC read and Phantom read at committing phase?
They are both invalidations due to state changing between chaincode execution and commit time. MVCC invalidation means the version of a key that was read using a keyed query during chaincode execution has changed. Phantom read means a non-key query produced different result set at chaincode execution time and commit time, due to some key being added, updated, or deleted. In either case, that transaction would break the serializability property of the blockchain and therefore must be invalidated.
Thank @dave.enyeart for the reply.
If I use couchdb as statedb, and perform GetStateByPartialCompositeKey rich query in the chaincode,, then within the Block timeout limit, perform update on the key, is this possible avoiding Phantom read
Or it will be prevented by `phantom protection is limited to range queries (i.e., GetStateByRange function in the chaincode)`
(https://hyperledger-fabric.readthedocs.io/en/release-1.1/readwrite.html#transaction-validation-and-updating-world-state-using-read-write-set)
I tried to solve the issue of perform the multiple transaction with same key within the batch timeout timing by spliting the key
GetStateByPartialCompositeKey uses GetStateByRange under the covers, and as such phantoms will be validated against. The question is, in your solution do you want to tolerate phantoms or protect against them? If you want to protect against them this is the built in behavior when doing query/update in a single transaction. If you want to tolerate them then you would need to split your transaction into two... first a query, and then an update, and only submit the update transaction to ordering. These types of 'blind writes' have no state validation.
@jrosmith external read-only users of peer's CouchDB state database is not supported. See https://jira.hyperledger.org/browse/FAB-1308 for proposal to add such support (there is not consensus on whether this should be added or not)
@dave.enyeart thanks dave! not sure if there is an active discussion on this topic but i do think supporting read only users would be valuable in production, especially for doing analytics on the state of the database and items modeled within it.
hi, how to define cross-channel access policies? and what is the relationship between channel and chaincode?
can anybody explain what are the high and low in block_num and txn_num in read&write sets in block?
For example what does the read/write set
}
mean
mean ?
{
key:"a",
version:{
block_num:{
low:4,
high:0,
unsigned:true
},
tx_num:{
low:0,
high:0,
unsigned:true
}
}
}
mean?
Hi Fabric Experts!
Can anyone explain me the steps/procedure how data is saved in the ledger and blockchain in Hyperledger Fabric?
or link/url to the documentation of internal architecture?
I could not find any documentation for that
Please any help would be appreciated
I have faced an issue
https://jira.hyperledger.org/browse/FAB-11458
The peer is endorsing the transaction even if the `blockfile` and indexes are deleted
Confusing
@dave.enyeart Please if you know something about it
@manish-sethi
Has joined the channel.
Hi all
During Invoke while processing a proposal with endorser client in proto peer in node sdk with custom first network with tls enabled i am having this error
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: 14 UNAVAILABLE: Connect Failed
at new createStatusError (/var/www/html/hyperledgerfabric_tsest_chaincode/first-network/node_modules/fabric-client/node_modules/grpc/src/client.js:64:15).
I have six peers, one orderer, solo, tls enabled network
I followed https://fabric-sdk-node.github.io/tutorial-mutual-tls.html for node sdk
Hi all
During Invoke while processing a proposal with endorser client in proto peer in node sdk with custom first network with tls enabled i am having this error
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: 14 UNAVAILABLE: Connect Failed
at new createStatusError (/var/www/html/hyperledgerfabric_tsest_chaincode/first-network/node_modules/fabric-client/node_modules/grpc/src/client.js:64:15).
I have six peers, one orderer, solo, tls enabled network
I followed https://fabric-sdk-node.github.io/tutorial-mutual-tls.html for node sdk
@pankajcheema please tell if you know something
Hi all
During Invoke while processing a proposal with endorser client in proto peer in node sdk with custom first network with tls enabled i am having this error
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: 14 UNAVAILABLE: Connect Failed
at new createStatusError (/var/www/html/hyperledgerfabric_tsest_chaincode/first-network/node_modules/fabric-client/node_modules/grpc/src/client.js:64:15).
I have six peers, one orderer, solo, tls enabled network
I followed https://fabric-sdk-node.github.io/tutorial-mutual-tls.html for node sdk
@pankajcheema please tell if you know something
Hi all
During Invoke while processing a proposal with endorser client in proto peer in node sdk with custom first network with tls enabled i am having this error
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: 14 UNAVAILABLE: Connect Failed
at new createStatusError (/var/www/html/hyperledgerfabric_tsest_chaincode/first-network/node_modules/fabric-client/node_modules/grpc/src/client.js:64:15).
I have six peers, one orderer, solo, tls enabled network
I followed https://fabric-sdk-node.github.io/tutorial-mutual-tls.html for node sdk
@pankajcheema please tell if you know something
Hi all
During Invoke while processing a proposal with endorser client in proto peer in node sdk with custom first network with tls enabled i am having this error
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: 14 UNAVAILABLE: Connect Failed
at new createStatusError (/var/www/html/hyperledgerfabric_tsest_chaincode/first-network/node_modules/fabric-client/node_modules/grpc/src/client.js:64:15).
I have six peers, one orderer, solo, tls enabled network
I followed https://fabric-sdk-node.github.io/tutorial-mutual-tls.html for node sdk
@pankajcheema please tell if you know something
Hi all
During Invoke while processing a proposal with endorser client in proto peer in node sdk with custom first network with tls enabled i am having this error
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: 14 UNAVAILABLE: Connect Failed
at new createStatusError (/var/www/html/hyperledgerfabric_tsest_chaincode/first-network/node_modules/fabric-client/node_modules/grpc/src/client.js:64:15).
I have six peers, one orderer, solo, tls enabled network
I followed https://fabric-sdk-node.github.io/tutorial-mutual-tls.html for node sdk
@pankajcheema please if you know something
Hi all
During Invoke while processing a proposal with endorser client in proto peer in node sdk with custom first network with tls enabled i am having this error
error: [client-utils.js]: sendPeersProposal - Promise is rejected: Error: 14 UNAVAILABLE: Connect Failed
at new createStatusError (/var/www/html/hyperledgerfabric_tsest_chaincode/first-network/node_modules/fabric-client/node_modules/grpc/src/client.js:64:15).
I have six peers, one orderer, solo, tls enabled network
I followed https://fabric-sdk-node.github.io/tutorial-mutual-tls.html for node sdk
@pankajcheema please if you know something
Hi all
During Invoke while processing a proposal with endorser client in proto peer in node sdk with custom first network with tls enabled i am having this error
https://hastebin.com/befaviletu.js
I have six peers, one orderer, solo, tls enabled network
I followed https://fabric-sdk-node.github.io/tutorial-mutual-tls.html for node sdk
@pankajcheema please if you know something
Has joined the channel.
@pankajcheema - for the endorsement, state database is used - block files are not used in the endorsement process that's why it is working for you.
@pankajcheema - BTW, you may be interested in a similar discussion on this channel - https://chat.hyperledger.org/channel/fabric-ledger?msg=59EseRdGahqb5smok
@pankajcheema I've close the jira with the following comments:
@pankajcheema I've closed the jira with the following comments:
If you tamper with the block files, the peer will not automatically detect this (imagine how expensive it would be to constantly recalculate hashes for millions of blocks). But you can audit the integrity of the blockchain by running a utility to check the hashes. One such utility can be found at: https://github.com/C0rWin/ledgerfsck
There was a proposal to have such a verify utility within the peer itself, but current thinking is to use external verify tools. See discussion in FAB-6486.
If you stop peer, delete the chains directory, and then try to invoke chaincode on a channel, you will get an error since peer wasn't able to initialize the chain upon restart. I tested and confirmed, and will therefore close since it is working as designed.
A few comments:
- If you find your chain has been deleted or tampered, you will need to re-build your peer and re-join the channel. Peer will get blocks from ordering service or another peer.
- If you believe your chain indexes or state database is not correct, you can stop peer, delete them, and re-start peer. Peer will automatically rebuild indexes and state database based on the blockchain.
- The important concept in blockchain is - if you tamper with your own local copy of the blockchain, it is detectable and you will not be able to convince the network of other peers that your copy of the ledger is correct. The integrity of the network cannot be compromised by a rogue organization/peer.
Has joined the channel.
Hi @dave.enyeart Thank you so much for this detailed explanation.
`If you stop peer, delete the chains directory, and then try to invoke chaincode on a channel, you will get an error since peer wasn't able to initialise the chain upon restart`. I deleted `blockfilexxxx`, then deleted the file in `index` index dir, then restarted the peer and invoke chaincode, it does not throw any error and endorsed the transaction successfully. I can even query the chaincode.
In my scenario I deleted the entire chains directory. You're right, if you just delete one block file the peer will not detect this. But the peer will not be able to convince others that it has the correct ledger, hash verification utilities will detect the problem. That is the fundamental design point.
Hello, does anyone know what the fabric DB model looks, any DDL, or mapping, i need to know defined data types for the models, like MSP's, channel, organizations, chaincodes etc
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=hhEFsZn5WY3S8rdow) @MeghaGupta
Has joined the channel.
@dave.enyeart can you say something about this? https://stackoverflow.com/questions/51670810/implementing-acl-in-hyperledger-fabric-v1-2
@dave.enyeart does it even verify the hash of last commited block before writing a new block?
Someone said to me that Hyperledger Fabric is not truly blockchain but it is just an implementation of DLT
Is that correct?
@pankajcheema Let's move the ACL discussion to #fabric-peer-endorser-committer
Hyperledger Fabric is indeed a blockchain, see the topic http://hyperledger-fabric.readthedocs.io/en/latest/ledger/ledger.html to understand how the blocks form a hashchain.
Hi All, Is there any way to recover couchdb from blockchain??
You can delete the state database and restart the peer to regenerate the state database. Upon start the peer checks to see if the state database and block indexes are missing or behind in block height, and if so, builds them up based on the transactions in the blockchain to bring them up to current height.
@dave.enyeart your mentioned state database is not the ledger or block chain, is it?
Please read the ledger, blockchain, and state database overview here: http://hyperledger-fabric.readthedocs.io/en/latest/ledger/ledger.html
hi, I just wanna confirm that we don't support any pruning/archiving on peer/orderer yet, right? thx in advance
yes @guoger - that's right
Hello @dave.enyeart
Fabric Peer creates system couch databases, _global_changes system database contributes to a whole file-system space that requires a regular repair via compaction. In single node setup for fabric, do we need these 3 system databases. We would optionally require _users however not even the ` _replicator`.
Copying from - http://docs.couchdb.org/en/latest/install/setup.html#single-node-setup
```
Note that the last of these is not necessary if you do not expect to be using the global changes feed. Feel free to delete this database if you have created it, it has grown in size, and you do not need the function (and do not wish to waste system resources on compacting it regularly.)
```
Hello @dave.enyeart
Fabric Peer creates system couch databases, `_global_changes` system database contributes to a whole file-system space that requires a regular repair via compaction. In single node setup for fabric, do we need these 3 system databases. We would optionally require `_users` however not even the ` _replicator`.
Copying from - http://docs.couchdb.org/en/latest/install/setup.html#single-node-setup
```
Note that the last of these is not necessary if you do not expect to be using the global changes feed. Feel free to delete this database if you have created it, it has grown in size, and you do not need the function (and do not wish to waste system resources on compacting it regularly.)
```
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=hhEFsZn5WY3S8rdow) @dave.enyeart so the blockfile can't pull from the other peer?
For new blocks the peer can pull from ordering service or other peers. I'm just saying that the peer won't continually re-checks its old blocks. You'll need an external utility to do those checks, e.g. https://github.com/C0rWin/ledgerfsck
@rahulhegde option to disable _global_changes: https://gerrit.hyperledger.org/r/#/c/24619/
@rahulhegde option to disable global changes db: https://gerrit.hyperledger.org/r/#/c/24619/
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=4F4DbCLNydcZaomDL) @dave.enyeart it means the peer can pull the old block from the other peer but it should check it by the https://github.com/C0rWin/ledgerfsck
the peer self will not check it
I mean a peer that is running behind can safely pull its next blocks from other peers. But it won't re-check those blocks over and over at a later point in time. For that you'll need the utility.
but for the old block,it's missing?
'old' is relative... it may be new to my peer if my peer is running behind.
it can safely pull next blocks from other peers. I'm just saying it won't re-check already committed blocks later.
@dave.enyeart my question is if i delete the blockfile for peer1, and i restart the peer1,the missing blockfile will pull from the other peer?
no, the peer will not continually re-check old blocks. if you want to ensure that blocks did not get tampered/corrupted post-commit, you will need an external validation utility.
ok，i got it,
@dave.enyeart i use the e2e/cli to test the if i delete all data for a peer,but i still get the data from the data?
it seems wrong
Clipboard - August 6, 2018 9:44 PM
i did the data persistence
Clipboard - August 6, 2018 9:44 PM
and than i delete the file
Clipboard - August 6, 2018 9:45 PM
and i use the `peer chaincode query -C mychannel -n mycc -c '{"Args":["query","a"]}'`
to query a
it tell me 90
Clipboard - August 6, 2018 9:47 PM
@manish-sethi
can you take a look?
this is consistent with what i've said above. if you delete old block files manually, but keep the state database, then the chaincode that queries the state database will continue to work.
but i delete the all the file
i know the state database contains the information the last new state,it can work
but i delete the all the file which include the world state
@asaningmaxchain123 - i assume that you are observing that you are able to get the answer for the chaincode query after deleting the ledgersData folder? If you are using couchdb then that's outside this folder and if you are using leveldb then most likely you deleted the folder while the peer is running and the peer process already holds the file descriptors and won't observe the deletion of files by other process...
@manish-sethi so i should restart the container if i want to see it?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Ei8QjNXhBersP2Gzf) @dave.enyeart Thanks @dave.enyeart . So the procedure for repair would be to manually remove the `_gloabal_changes` from every couch instance and update the peer configuration via docker compose file to disable creation of it further.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Ei8QjNXhBersP2Gzf) @dave.enyeart Thanks @dave.enyeart . So the procedure for repair would be to manually remove the `_global_changes` from every couch instance and update the peer configuration via docker compose file to disable creation of it further.
right, the default going forward will be to have `_global_changes` disabled. per the couchdb docs, the database can be deleted if you are not using it: http://docs.couchdb.org/en/latest/install/setup.html#single-node-setup
right, the default going forward will be to have `_global_changes` disabled (never create it). per the couchdb docs, the database can be deleted if you are not using it: http://docs.couchdb.org/en/latest/install/setup.html#single-node-setup
We would like to change the existing JSON document representation from 1 format to another (couch database as world state ledger). I can think of two ways - 1. writing a Migrate Chaincode Invoke function and later asking client like PEER CLI to call the same until the migration process is complete. 2. Other approach would perform migration inside the Init method however number of documents for conversion can be far many.
Any other suggestion or recommendation?
can anyone please explain me what are high and low values in hyperledger fabric?
how do we read the high and low values in block structure for the version of an asset like ->
asset: "asset1",
version: {
low: 3,
high: 0,
}
i got that low means the latest block but what does the high imply?
@username343 This is a node.js sdk nuance, please take discussion to #fabric-sdk-node , you can see an existing answer here: https://chat.hyperledger.org/channel/fabric-sdk-node?msg=cLGhTykqwn5SJys7e
@dave.enyeart thanks man :thumbsup:
Has joined the channel.
where the ledger data are stored in system?
is it a file based storage?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=xQnDAhPjh5Xy9kLbv) @rajivgandhi2010 ledger data resides on peer file system under `/var/hyperledger/production/ledgersData/chains/`
in widnows?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=kJirCbyxgBCnYEXjT) @rajivgandhi2010 peer file system, if you running windows, then most likely it's within peer's docker container
Has joined the channel.
Has joined the channel.
@dave.enyeart i use the couchdb as the world state,i find it speed longer time to finish
Has joined the channel.
Could someone confirm whether in the current implementation of Fabric the writesets include the new value 'v' for key 'k' in it's entirety or a delta of 'k''s previous value?
Entirely
So strictly speaking if I was looking at the transaction log (assuming I didn't have access the World State), I only need to look at the last valid transaction for 'k' to determine it's value. In other words, k's history doesn
So strictly speaking if I was looking at the transaction log (assuming I didn't have access the World State), I only need to look at the last valid transaction for 'k' to determine it's value. In other words, k's history doesn't matter
So strictly speaking if I was looking at the transaction log (assuming I didn't have access to the World State), I only need to look at the last valid transaction for 'k' to determine it's value. In other words, k's history doesn't matter
That is correct
Is there a reason why we didn't want to use deltas for non-atomic values such as JSON documents? For instance of a single attribute in the document v was all that was changed, storing the delta in v' will be space efficient (I'm guessing the tradeoff here might not make a lot of sense in practice give storage is cheap)
@dave.enyeart i can set the couchdb index by the `curl` not in the chaincode isntall
@dave.enyeart i can set the couchdb index by the `curl` not in the chaincode isntall?
@dave.enyeart i can set the couchdb index by the `curl` not in the chaincode install?
You package the index with the chaincode installation. This documentation describes it: https://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html
yes,i can do it,but i can do it by the `curl`
not by the `peer chaincode install `
in a development environment, sure you can try some things out in curl prior to finalizing the chaincode installation package
ok,i got it
in the `SideDB`, the control strength is `org`
?
not the `peer`
correct, the collection configuration that is passed at chaincode instantiation defines the private data dissemination policies at the org level. Again, read all about it in the docs please: https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html https://hyperledger-fabric.readthedocs.io/en/latest/private-data-arch.html https://hyperledger-fabric.readthedocs.io/en/latest/private_data_tutorial.html
ok,thx
another question,if i write a bad query statement for couchdb as world state,the peer shutdown?
so i think the fabric should check it
no, your proposal will return the error to your client
no, the peer will process the proposal and will return the error to your client
are you sure?
in my test,the peer shutdown
i'm sure, if i pass a bad query to chaincode invoke, the peer stays up and returns an error to the client such as:
```Error: endorsement failure during query. response: status:500 message:"GET_QUERY_RESULT failed: transaction ID: aa61e25643450ba1a7dd3b72db1e2599d338bd5cd206bde41768ecc8e937cb2f: error handling CouchDB request. Error:missing_required_key, Status Code:400, Reason:Missing required key: selector"```
Clipboard - August 17, 2018 11:49 PM
yes, you are right
If you see something different, please open a Jira with the peer shutdown log
but in the v1.0, i am sure the peer shutdown
I don't recall what v1.0 did, as couchdb is only recommended for production purpose as of v1.1
ok,i got it, thx for a lot
ok,i got it, thx
in the fabric,the blockfile will be Archived?
the blockfile is stored on peer's disk, not archived
so the blockfile increase 1000T, i think the custom can't accept
so the blockfile increase into 1000T, i think the custom can't accept
the blockfiles can increase forever
until you run out of disk space that is, and then you obtain more disk space. in the future there is intent to provide some archive function.
ok, i got it. thx very much
no problem, i need to step away...
@dave.enyeart @manish-sethi Is there any activity going on about https://jira.hyperledger.org/browse/FAB-8031? Any concrete plans?
Hi, where in 1.2 is "private data collection" physically stored. We use CouchDB as the key/value store. Is it in a separate CouchDB database ? Is it anywhere else ? I'm asking from the point of view of knowing where we might have to allocate storage if we wanted to use it ?
Private data is stored per block next to the blockchain on the file system, and private data current state is stored in a separate couchdb database next to regular data current state database.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=gfnEfxZt4zv8i2pEg) @minollo Not the one that we can call concrete at the moment. This does not seem to have broken the 'priority' bar yet...
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hi all, i am trying to do pagination in my application(couchDB, Fabric Hyperleger). when i query with selector {"selector":{"docType":"account"},"limit": 4,"skip": 2} am getting all accounts. its not skipping and limiting...can any one explain me how to do this????
@Akash-digiledge paging support is being added in next release. you can read about it here: https://jira.hyperledger.org/browse/FAB-2809 . There are some workaround ideas mentioned in there.
Has joined the channel.
Hey All, I'm trying to deploy a piece of chaincode with a collection profile but I keep running into the following error:
`Error: could not assemble transaction, err Proposal response was not successful, error code 500, msg invalid number of arguments to lscc:
Hey All, I'm trying to deploy a piece of chaincode with a collection profile but I keep running into the following error:
`Error: could not assemble transaction, err Proposal response was not successful, error code 500, msg invalid number of arguments to lscc`
Command is:
``` docker exec cli peer chaincode instantiate -o $ORDERER_ADDRESS \
-C "$CHANNEL_NAME" \
-n "$CHAINCODE_ID" \
-v "$CHAINCODE_VERSION" \
-c "$INIT_ARGS" \
--policy "OR('org1.member', AND('org2.member', 'org3.member'))" \
--collections-config "/etc/hyperledger/policies/collections.json"```
Policy is
```[
{
"name": "collection1",
"policy": "OR('org1.peer', 'org2.peer')",
"requiredPeerCount": 0,
"maxPeerCount": 2,
"blockToLive": 1000000
}
]```
Has anyone seen this before or has any idea?
This is due to the channel not have application capability V1_2 defined. It's a bad error message though... I've opened https://jira.hyperledger.org/browse/FAB-11712 to improve it.
Has joined the channel.
awsome, thanks!
Hey All, I'm getting this after I push an anchor peer update:
```2018-08-24 09:11:38.582 UTC [gossip/gossip] learnAnchorPeers -> INFO 035 Anchor peer with same endpoint, skipping connecting to myself
2018-08-24 09:11:38.582 UTC [gossip/gossip] learnAnchorPeers -> INFO 036 Anchor peer peer0.org2.example.com:7051 isn't in our org(org2) and we have no external endpoint, skipping```
Hey All!
So I'm still stuck on this private data stuff, I've got my network deployed and 1.2 enabled now (huge thanks to @dave.enyeart) but I'm getting the following whenever I try to query private data:
```2018-08-24 09:14:55.575 UTC [chaincode] HandleTransaction -> ERRO 043 [3e392ac5] Failed to handle GET_STATE. error: Private data matching public hash version is not available. Public hash version = &version.Height{BlockNum:0x5, TxNum:0x0}, Private data version = (*version.Height)(nil)
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleGetState
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:545
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleGetState-fm
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:197
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:242
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361
GET_STATE failed: transaction ID: 3e392ac59e91f3c859404f6715168b2b5ba2024af572822f818954866e31de8d
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:246
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361```
```2018-08-24 09:14:55.581 UTC [endorser] SimulateProposal -> ERRO 044 [defaultchannel][3e392ac5] failed to invoke chaincode name:"cc1" , error: transaction returned with failure: {}
github.com/hyperledger/fabric/core/chaincode.(*ChaincodeSupport).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/chaincode_support.go:202
github.com/hyperledger/fabric/core/endorser.(*SupportImpl).Execute
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/support.go:141
github.com/hyperledger/fabric/core/endorser.(*Endorser).callChaincode
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:136
github.com/hyperledger/fabric/core/endorser.(*Endorser).SimulateProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:287
github.com/hyperledger/fabric/core/endorser.(*Endorser).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/endorser/endorser.go:501
github.com/hyperledger/fabric/core/handlers/auth/filter.(*expirationCheckFilter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/expiration.go:61
github.com/hyperledger/fabric/core/handlers/auth/filter.(*filter).ProcessProposal
/opt/gopath/src/github.com/hyperledger/fabric/core/handlers/auth/filter/filter.go:31
github.com/hyperledger/fabric/protos/peer._Endorser_ProcessProposal_Handler
/opt/gopath/src/github.com/hyperledger/fabric/protos/peer/peer.pb.go:112
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).processUnaryRPC
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:923
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).handleStream
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:1148
github.com/hyperledger/fabric/vendor/google.golang.org/grpc.(*Server).serveStreams.func1.1
/opt/gopath/src/github.com/hyperledger/fabric/vendor/google.golang.org/grpc/server.go:637
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:2361```
Hey All!
So I'm still stuck on this private data stuff, I've got my network deployed and 1.2 enabled now (huge thanks to @dave.enyeart) but I'm getting the following whenever I try to query private data:
```2018-08-24 09:14:55.575 UTC [chaincode] HandleTransaction -> ERRO 043 [3e392ac5] Failed to handle GET_STATE. error: Private data matching public hash version is not available. Public hash version = &version.Height{BlockNum:0x5, TxNum:0x0}, Private data version = (*version.Height)(nil)```
```2018-08-24 09:14:55.581 UTC [endorser] SimulateProposal -> ERRO 044 [defaultchannel][3e392ac5] failed to invoke chaincode name:"cc1" , error: transaction returned with failure: {}```
Hey All!
So I'm still stuck on this private data stuff, I've got my network deployed and 1.2 enabled now (huge thanks to @dave.enyeart) but I'm getting the following whenever I try to query private data:
```2018-08-24 09:14:55.575 UTC [chaincode] HandleTransaction -> ERRO 043 [3e392ac5] Failed to handle GET_STATE. error: Private data matching public hash version is not available. Public hash version = &version.Height{BlockNum:0x5, TxNum:0x0}, Private data version = (*version.Height)(nil)```
```2018-08-24 09:14:55.581 UTC [endorser] SimulateProposal -> ERRO 044 [defaultchannel][3e392ac5] failed to invoke chaincode name:"cc1" , error: transaction returned with failure: {}```
Hey All!
So I'm still stuck on this private data stuff, I've got my network deployed and 1.2 enabled now (huge thanks to @dave.enyeart) but I'm getting the following whenever I try to query private data:
```2018-08-24 09:14:55.575 UTC [chaincode] HandleTransaction -> ERRO 043 [3e392ac5] Failed to handle GET_STATE. error: Private data matching public hash version is not available. Public hash version = &version.Height{BlockNum:0x5, TxNum:0x0}, Private data version = (*version.Height)(nil)```
```2018-08-24 09:14:55.581 UTC [endorser] SimulateProposal -> ERRO 044 [defaultchannel][3e392ac5] failed to invoke chaincode name:"cc1" , error: transaction returned with failure: {}```
Hey All!
So I'm still stuck on this private data stuff, I've got my network deployed and 1.2 enabled now (huge thanks to @dave.enyeart) but I'm getting the following whenever I try to query private data:
`2018-08-24 09:14:55.575 UTC [chaincode] HandleTransaction -> ERRO 043 [3e392ac5] Failed to handle GET_STATE. error: Private data matching public hash version is not available. Public hash version = &version.Height{BlockNum:0x5, TxNum:0x0}, Private data version = (*version.Height)(nil)`
`2018-08-24 09:14:55.581 UTC [endorser] SimulateProposal -> ERRO 044 [defaultchannel][3e392ac5] failed to invoke chaincode name:"cc1" , error: transaction returned with failure: {}`
When I try to invoke and write private data however:
```2018-08-24 09:14:54.552 UTC [couchdb] CreateDatabaseIfNotExist -> INFO 041 Created state database defaultchannel_testCollection$$htestCollection$collection
2018-08-24 09:14:55.567 UTC [couchdb] CreateDatabaseIfNotExist -> INFO 042 Created state database defaultchannel_testCollection$$ptestCollection$collection```
```2018-08-24 09:18:14.432 UTC [kvledger] CommitWithPvtData -> INFO 045 Channel [defaultchannel]: Committed block [6] with 1 transaction(s)```
My Collection policy is as follows:
```[
{
"name": "exampleCollection",
"policy": "OR('org1.peer', 'org2.peer')",
"requiredPeerCount": 0,
"maxPeerCount": 2,
"blockToLive": 1000000
}
]```
I'm assuming this is set up correctly as I can deploy the code and invoke it however when it comes to querying I get errors. I'm invoking and querying on org1's peer.
Given that private data is dissemenated via gossip I am getting the following on the org1 peer (and equivalents on the others):
```2018-08-24 09:11:37.226 UTC [kvledger] CommitWithPvtData -> INFO 034 Channel [defaultchannel]: Committed block [1] with 1 transaction(s)
2018-08-24 09:11:38.582 UTC [gossip/gossip] learnAnchorPeers -> INFO 035 Anchor peer with same endpoint, skipping connecting to myself
2018-08-24 09:11:38.582 UTC [gossip/gossip] learnAnchorPeers -> INFO 036 Anchor peer peer0.org2.example.com:7051 isn't in our org(org2) and we have no external endpoint, skipping
2018-08-24 09:11:38.597 UTC [kvledger] CommitWithPvtData -> INFO 037 Channel [defaultchannel]: Committed block [2] with 1 transaction(s)
2018-08-24 09:11:39.957 UTC [gossip/gossip] learnAnchorPeers -> INFO 038 Anchor peer with same endpoint, skipping connecting to myself
2018-08-24 09:11:39.957 UTC [gossip/gossip] learnAnchorPeers -> INFO 039 Anchor peer peer0.org2.example.com:7051 isn't in our org(org2) and we have no external endpoint, skipping
2018-08-24 09:11:39.957 UTC [gossip/gossip] learnAnchorPeers -> INFO 03a Anchor peer peer0.org3.example.com:7051 isn't in our org(org3) and we have no external endpoint, skipping```
Org 2 should also be in the collection but doesn't have any of the creating the sidedb that Org1 has. I assume this is a product of Gossip not working.
As such, my questions are:
*Why aren't my queries working?*
*How do I get Gossip set up correctly? (if it's not working)*
Thanks!
When I try to invoke and write private data however:
```2018-08-24 09:14:54.552 UTC [couchdb] CreateDatabaseIfNotExist -> INFO 041 Created state database defaultchannel_testCollection$$htestCollection$collection
2018-08-24 09:14:55.567 UTC [couchdb] CreateDatabaseIfNotExist -> INFO 042 Created state database defaultchannel_testCollection$$ptestCollection$collection```
And then when I try to write again:
```2018-08-24 09:18:14.432 UTC [kvledger] CommitWithPvtData -> INFO 045 Channel [defaultchannel]: Committed block [6] with 1 transaction(s)```
My Collection policy is as follows:
```[
{
"name": "exampleCollection",
"policy": "OR('org1.peer', 'org2.peer')",
"requiredPeerCount": 0,
"maxPeerCount": 2,
"blockToLive": 1000000
}
]```
I'm assuming this is set up correctly as I can deploy the code and invoke it however when it comes to querying I get errors. I'm invoking and querying on org1's peer.
Given that private data is dissemenated via gossip I am getting the following on the org1 peer (and equivalents on the others):
```2018-08-24 09:11:37.226 UTC [kvledger] CommitWithPvtData -> INFO 034 Channel [defaultchannel]: Committed block [1] with 1 transaction(s)
2018-08-24 09:11:38.582 UTC [gossip/gossip] learnAnchorPeers -> INFO 035 Anchor peer with same endpoint, skipping connecting to myself
2018-08-24 09:11:38.582 UTC [gossip/gossip] learnAnchorPeers -> INFO 036 Anchor peer peer0.org2.example.com:7051 isn't in our org(org2) and we have no external endpoint, skipping
2018-08-24 09:11:38.597 UTC [kvledger] CommitWithPvtData -> INFO 037 Channel [defaultchannel]: Committed block [2] with 1 transaction(s)
2018-08-24 09:11:39.957 UTC [gossip/gossip] learnAnchorPeers -> INFO 038 Anchor peer with same endpoint, skipping connecting to myself
2018-08-24 09:11:39.957 UTC [gossip/gossip] learnAnchorPeers -> INFO 039 Anchor peer peer0.org2.example.com:7051 isn't in our org(org2) and we have no external endpoint, skipping
2018-08-24 09:11:39.957 UTC [gossip/gossip] learnAnchorPeers -> INFO 03a Anchor peer peer0.org3.example.com:7051 isn't in our org(org3) and we have no external endpoint, skipping```
Org 2 should also be in the collection but doesn't have any of the creating the sidedb that Org1 has. I assume this is a product of Gossip not working.
As such, my questions are:
*Why aren't my queries working?*
*How do I get Gossip set up correctly? (if it's not working)*
Thanks!
When I try to invoke and write private data however:
```2018-08-24 09:14:54.552 UTC [couchdb] CreateDatabaseIfNotExist -> INFO 041 Created state database defaultchannel_testCollection$$htestCollection$collection
2018-08-24 09:14:55.567 UTC [couchdb] CreateDatabaseIfNotExist -> INFO 042 Created state database defaultchannel_testCollection$$ptestCollection$collection```
And then when I try to write again:
```2018-08-24 09:18:14.432 UTC [kvledger] CommitWithPvtData -> INFO 045 Channel [defaultchannel]: Committed block [6] with 1 transaction(s)```
My Collection policy is as follows:
```[
{
"name": "exampleCollection",
"policy": "OR('org1.peer', 'org2.peer')",
"requiredPeerCount": 0,
"maxPeerCount": 2,
"blockToLive": 1000000
}
]```
I'm assuming this is set up correctly as I can deploy the code and invoke it however when it comes to querying I get errors. I'm invoking and querying on org1's peer.
Given that private data is dissemenated via gossip I am getting the following on the org1 peer (and equivalents on the others):
```2018-08-24 09:11:37.226 UTC [kvledger] CommitWithPvtData -> INFO 034 Channel [defaultchannel]: Committed block [1] with 1 transaction(s)
2018-08-24 09:11:38.582 UTC [gossip/gossip] learnAnchorPeers -> INFO 035 Anchor peer with same endpoint, skipping connecting to myself
2018-08-24 09:11:38.582 UTC [gossip/gossip] learnAnchorPeers -> INFO 036 Anchor peer peer0.org2.example.com:7051 isn't in our org(org2) and we have no external endpoint, skipping
2018-08-24 09:11:38.597 UTC [kvledger] CommitWithPvtData -> INFO 037 Channel [defaultchannel]: Committed block [2] with 1 transaction(s)
2018-08-24 09:11:39.957 UTC [gossip/gossip] learnAnchorPeers -> INFO 038 Anchor peer with same endpoint, skipping connecting to myself
2018-08-24 09:11:39.957 UTC [gossip/gossip] learnAnchorPeers -> INFO 039 Anchor peer peer0.org2.example.com:7051 isn't in our org(org2) and we have no external endpoint, skipping
2018-08-24 09:11:39.957 UTC [gossip/gossip] learnAnchorPeers -> INFO 03a Anchor peer peer0.org3.example.com:7051 isn't in our org(org3) and we have no external endpoint, skipping```
Org 2 should also be in the collection but doesn't have any of the creating the sidedb that Org1 has. I assume this is a product of Gossip not working.
As such, my questions are:
*Why aren't my queries working?*
*How do I get Gossip set up correctly? (if it's not working)*
Thanks!
@tom.appleyard I'll take a look at your peer debug (generate with CORE_LOGGING_LEVEL=DEBUG) when I get a chance... make sure to include the invoke/commit that adds the private key, as well as the query. Mention timestamp of both.
Has joined the channel.
@tom.appleyard - the logs say that your peer doesn't have an external endpoint configured... it's a dead giveaway.
if you want this peer to be accessible to other organizations you need to set its external endpoint
right now, your peer receives a config block with an anchor peer update for `peer0.org3` and it basically refuses to talk to it because it has no external endpoint, and thus other organizations aren't supposed to know about its existence :spy:
If you configure an external endpoint (`CORE_PEER_GOSSIP_EXTERNALENDPOINT`) then the peer would then reach to the anchor peers and say "hey! I'm here guys! talk to me!"
If you configure an external endpoint ( `CORE_PEER_GOSSIP_EXTERNALENDPOINT` ) then the peer would then reach to the anchor peers and say "hey! I'm here guys! talk to me!"
Has joined the channel.
Hi All , Greetings !
Does Fabric support MongoDB as a state database ?
@FaizulHassan not yet, there is some work in the community to add MongoDB support
thank you Dave !
thank you @dave.enyeart !
Has joined the channel.
Hello everyone, I need help. I try to configure the block browser on another server. I do not know how to get the pair's tls. Does anyone know how I can do?
Has joined the channel.
Has joined the channel.
hi am using fabric version 1.1. For getting events am using channel-eventhub. by using registerChaincodeEvent am getting the eventname and txnId but not getting the payload. can any one help me to find out the problem?
@Akash-digiledge You'll need to post on the relevant #fabric-sdk channel
Has left the channel.
Has joined the channel.
Can any one tell me how to invoke the system chaincode? please explain me with one example...any reply will be appreciated..
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=quSkFC7KCjb2gNNrk) @Akash-digiledge https://blockchain-fabric.blogspot.com/2018/03/system-chaincodes-in-hyperledger-fabric.html
Hello guys , I needs some clarity in Hyperledger Transaction Flow.
Kindly advice whether my assumption is right.
*Transaction flow:*
- Client application sends transaction proposal to "Endorsing Peers"
- "Endorsing Peers" validates participants by checking
- whether their Certificates are valid
- whether they are authorized to perform operation
- the Endorsement policies, signs the transation and sends response to client application
Question: What will be the Response from Endorsing Peers to client application contains ?
What are read/write sets ?
Also please brief about the transaction flow..
Thanks much in advance
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=hAsGvc7eGRj67gFDH) @FaizulHassan This should help you
https://hyperledger-fabric.readthedocs.io/en/release-1.2/txflow.html
thank you @adarshsaraf123 :)
Yuck. I'm not sure if this is the java-sdk or the peer or my lack of understanding here. Which is why I'm spamming two channels - for which I'll apologize in advance.
Stand up a fabric network. Create a channel. Life is good.
Stop and restart the peers. They come up. So far so good.
Try to rejoin the previously created channel. Not so good.
Channel rejoin code is the same as the sample sdk reconstruct logic - join peers to channel object and do an initialize. Code all works fine except in this case - it's been untouched for months.
SDK throws an access denied exception - `Sending proposal to peer1-org failed because of: gRPC failure=Status{code=UNKNOWN, description=access denied: channel [channel] creator org [msp], cause=null}` - msp and channel here are redacted but correct.
Peer throws this `2018-09-05 15:04:30.479 UTC [protoutils] ValidateProposalMessage -> WARN 15d7 channel [channel]: MSP error: channel doesn't exist` before all hell breaks loose (it starts throwing hundreds of peer event errors with same).
Channel was created just fine. I can see it in my orderer logs - here's two that seem pertinent - start and (as far as I can tell) end of the create
`2018-09-05 13:48:46.112 UTC [orderer/common/msgprocessor] ProcessConfigUpdateMsg -> DEBU 13f Processing channel create tx for channel channel on system channel genesischannel`
`2018-09-05 13:48:47.012 UTC [orderer/consensus/kafka] processConnect -> DEBU 47e [channel: ibm-block-channel] It's a connect message - ignoring`
TLS is off. Crypto is unchanged between restarts.
Peer storage persists and was untouched. Couchdb (which also restarted) storage persists and was untouched.
Do I need to join the channel differently in the case of a peer restart like this? Or is there some issue here? I - wrongly - assumed it would just pick up where it left off...
Yuck. I'm not sure if this is the java-sdk or the peer or my lack of understanding here. Which is why I'm spamming two channels - for which I'll apologize in advance.
Stand up a fabric network. Create a channel. Life is good.
Stop and restart the peers. They come up. So far so good.
Try to rejoin the previously created channel. Not so good.
Channel rejoin code is the same as the sample sdk reconstruct logic - join peers to channel object and do an initialize. Code all works fine except in this case - it's been untouched for months.
SDK throws an access denied exception - `Sending proposal to peer1-org failed because of: gRPC failure=Status{code=UNKNOWN, description=access denied: channel [channel] creator org [msp], cause=null}` - msp and channel here are redacted but correct.
Peer throws this `2018-09-05 15:04:30.479 UTC [protoutils] ValidateProposalMessage -> WARN 15d7 channel [channel]: MSP error: channel doesn't exist` before all hell breaks loose (it starts throwing hundreds of peer event errors with same).
Channel was created just fine. I can see it in my orderer logs - here's two that seem pertinent - start and (as far as I can tell) end of the create
`2018-09-05 13:48:46.112 UTC [orderer/common/msgprocessor] ProcessConfigUpdateMsg -> DEBU 13f Processing channel create tx for channel channel on system channel genesischannel`
`2018-09-05 13:48:47.012 UTC [orderer/consensus/kafka] processConnect -> DEBU 47e [channel: channel] It's a connect message - ignoring`
TLS is off. Crypto is unchanged between restarts.
Peer storage persists and was untouched. Couchdb (which also restarted) storage persists and was untouched.
Do I need to join the channel differently in the case of a peer restart like this? Or is there some issue here? I - wrongly - assumed it would just pick up where it left off...
Yuck. I'm not sure if this is the java-sdk or the peer or my lack of understanding here. Which is why I'm spamming two channels - for which I'll apologize in advance.
Stand up a fabric network. Create a channel. Life is good.
Stop and restart the peers. They come up. So far so good.
Try to rejoin the previously created channel. Not so good.
Channel rejoin code is the same as the sample sdk reconstruct logic - join peers to channel object and do an initialize. Code all works fine except in this case - it's been untouched for months.
SDK throws an access denied exception - `Sending proposal to peer1-org failed because of: gRPC failure=Status{code=UNKNOWN, description=access denied: channel [channel] creator org [msp], cause=null}` - msp and channel here are redacted but correct.
Peer throws this `2018-09-05 15:04:30.479 UTC [protoutils] ValidateProposalMessage -> WARN 15d7 channel [channel]: MSP error: channel doesn't exist` before all hell breaks loose (it starts throwing hundreds of peer event errors with same).
Channel was created just fine. I can see it in my orderer logs - here's two that seem pertinent - start and (as far as I can tell) end of the create
`2018-09-05 13:48:46.112 UTC [orderer/common/msgprocessor] ProcessConfigUpdateMsg -> DEBU 13f Processing channel create tx for channel channel on system channel genesischannel`
`2018-09-05 13:48:47.012 UTC [orderer/consensus/kafka] processConnect -> DEBU 47e [channel: channel] It's a connect message - ignoring`
TLS is off. Crypto is unchanged between restarts.
Peer storage is container local in this case. Couchdb (which also restarted) storage persists and was untouched.
Do I need to join the channel differently in the case of a peer restart like this? Or is there some issue here? I - wrongly - assumed it would just pick up where it left off and pull the channel info from another peer.
@dave.enyeart how many blockfile can generate by a fabric network?
1000000?
@dave.enyeart can you tell me in the fabric where use the `// BlockDataHashingStructure is encoded into the configuration transaction as a configuration item of
// type Chain with a Key of "BlockDataHashingStructure" and a Value of HashingAlgorithm as marshaled protobuf bytes
message BlockDataHashingStructure {
// width specifies the width of the Merkle tree to use when computing the BlockDataHash
// in order to replicate flat hashing, set this width to MAX_UINT32
uint32 width = 1;
}
`
@dave.enyeart can you tell me in the fabric where use the ``` // BlockDataHashingStructure is encoded into the configuration transaction as a configuration item of
// type Chain with a Key of "BlockDataHashingStructure" and a Value of HashingAlgorithm as marshaled protobuf bytes
message BlockDataHashingStructure {
// width specifies the width of the Merkle tree to use when computing the BlockDataHash
// in order to replicate flat hashing, set this width to MAX_UINT32
uint32 width = 1;
}
```
@asaningmaxchain123 there is no limit imposed by Fabric on number of block files... the zero padding you see in block files is there only to ensure reasonable file sorting in block file directory, it doesn't actually impose any limit.
@asaningmaxchain123 The block data hash ended up being a simple hash of the block's data, not a merkle tree. @jyellick is BlockDataHashingStructure used anywhere else? or can it be removed?
I wish it had not been added in the first place, but removing it will cause problems.
There had been aspirations of making the block hashing parameters configurable prior to v1.0 being released, and these fields were added, but when the feature didn't make it ,not everything was backed out.
i advice remove it in the 1.3 release
@jyellick
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hi everyone for private data collections,are there separate dbs for both private data collections and for the transient data? Thanks!
yes, private data is included in state database for chaincode interaction upon commit, and transient data is stored in a dedicated leveldb database until the tran is committed.
@dave.enyeart Thanks for the confirmation. As always, the help is greatly appreciated.
Has joined the channel.
Has joined the channel.
Hi
I have a question about the ledger design
Before doing my question I'd mention what I suppose to be true, so maybe it's trivial the answer to the question hehe
Each block is signed by the Orderer.
Tampering a block would yield in concluding that someone somehow has the Orderer private key.
If that is the case, it could re-calculate the following blocks of the tampered block... just to make the chain-hashing consistent.
So, my question is: What value has doing the well-known chain-hashing?
In public blockchains makes sense because re-calculating following blocks is computer expensive.
But in the case here, 'making' blocks means signing as the Orderer
and if you do it for one, you could make it for a lot more without effort. So whats the sense of linking the blocks thorough hashes?
> If that is the case, it could re-calculate the following blocks of the tampered block... just to make the chain-hashing consistent.
what do you mean?
Suppose the ledger has Block0, Block1, Block2 and Block3.
Somehow, Block1 is tampered... for example, a transaction is deleted. Even that Block1 was tampered, its valid... with this I mean that seems to be correctly signed by the Orderer (which seem to suggest that the private key was compromised).
Moreover, since Block1 changed, Block2 and Block3 should change too to make the whole ledger consistent. Right?
Since Block2 had the 'old' hash of Block1, etc.
right, block2 has the old hash of block 1
and now you need to sign every block again and again
Great. Since the private key was compromised, reconstructing Block 2 and Block3, it's also easy.
because this is a hash chain
So, my question is: Why we link blocks through this hashes here?
what kind of value they add to the design?
we link blocks via hashes so you can do backward hash chain validation
if you trust the last block's signature
then you don't need to verify the signatures of all the blocks before
just compute the hash
and check that the hash chain is consistent
Right... each block signature is the validation of the signer for the block itself and indirectly all the history throught the prior-hash block.
yes
Ok, so its only a means of making easier 'checksum' blocks in the chains. It adds no extra value on security itself.
I mention this compared to a public blockchain
you can't add more security if you're already secure though
Yes, that's my point!.
and yeah - since you have a signature on each block
you don't have to use the hash chain validation
but, however
signature checks are costly in comparison to hashing
so - you might waste less CPU if you do hash chain verification
For example if a new peer joins some ancient channel, it would just check the 'lead' Block signature, and then use hashing to validate older blocks. That is what you mean of an improved efficiency use case?.
yeah
though it's not implemented
right now i don't think there are ancient channels in the world ;)
and there is another problem anyway
that makes it not so effective
so, each block carries inside dozens of signatures to validate anyway
signatures of endorsing peers
correct
so - even if you save 1 signature check per block, you still have like 50 signature checks left to do
or maybe at least 3 more
You're right... since the orderer doesn't check signatures of endorsers Right?
it doesn't... it's the peers
Ok.. so I could have a valid block with the order signature correct, but the transactions are garbage.
That would make it an invalid transaction in the block?
yes
Ok.. so, in conclusion, I'd still had to validate all endorers signatures in the history of the ledger :s
yes
I hope this thing of linking blocks through hashing wasn't done for comercial purposes (you know: using 'blockchain' word )
hahahaha
who knows?
I still don't get why this exists here.
In public blockchains makes perfect sense and it's a critical design decision
Or maybe im confused
I think not.. because it's what forces you to re-calculate 'the future again'
and in the case of PoW chains, means wasting a lot of power
and in the case of hyperledger, it's wasting nothing (since I have the private key)
I'm not very aware of how the gossip protocol works and how a fork would impact the network...
Anyway, I'd prefer to think that there's still a good reason why here we're linking blocks with hashes...
@Jgnuid You are right, if you obtain the orderer private key you can cut different blocks going forward. But the blockchain is not about any one chain. It is about a distributed set of synchronized chains in a permissioned network. If one peer's chain is altered and deviates from the others, the hash chain makes it simple to identify the 'bad' chain and where exactly it deviated. The 'bad' peers state data would be different from all the other peers, and therefore it would not be able to participate in further chaincode transactions and endorsements. The 'bad' peer would be isolated from the distributed ledger, and the other organizations would kick the bad organization out of the permissioned network.
@dave.enyeart, for sure detecting forks is much easier with hashes.
But just imagine if the hash is 'block independant' too to achieve the same goal?. I mean, if block number N in the chain has a computed hash different from the majority of the ledger, we can also be sure that we have a fork (even if the block hash doesn't depend of priori block hashes). And reach your same right conclusion.
Why making a chain of hashes is necessary?
If you extend that argument to its logical conclusion, you could also say that everybody should just use their own databases and they can compare the individual records if any disputes come up. There is value in a single rolled up 'truth'.
If you extend that argument to its logical conclusion, you could also say that everybody should just use their own databases and they can compare the individual records and transaction logs if any disputes come up. There is value in a single rolled up 'truth'.
Well, I think there's a huge gap between not chaining hashes and reconsidering the whole idea of distributed ledger. Not sure why that's the logical conclusion of my question.
I guess I'm going to take that it helps in detecting fast forks in the network. Every block that the 'tampering peer' tries to spread in the network, could be easily detected because it would not be in the majority of what the ledger is saying its true. Moreover, it would happend to the tampered block but also with subsequent blocks (even if the tampering peer makes subsequent blocks identical to the real ones, because as hashes are chained, since he changed history, the block hash would be different).
@dave.enyeart , that was your point?. :)
If hashes wasn't chained, it would be harder to detect tampered history of this malicious peer (even if he nows tries to work as expected)
If hashes wasn't changed, it would be harder to detect tampered history of this malicious peer (even if he nows tries to work as expected)
Thanks for your opinion :)
Thanks for your opinion :), very valuable for me!
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=MhJwLRMLq8FW4yQi8) @Jgnuid How do you get to the "immutable" part of distributed and immutable without chaining the blocks?
Has joined the channel.
@aatkddny , since each block is signed by a trusted authority, any other peer cannot mutate a block without breaking the ledger.
@aatkddny , since each block is signed by a trust authority, any other peer cannot mutate a block without breaking the ledger.
yacov and jsign
Mutating one block doesn't break the ledger in that case. It breaks one block.
You'd have to check every block every time you write to see if any priors in that ledger were compromised.
@aatkddny , I guess this is an interesting discussion :)
@aatkddny , the way I think about immutability is the following: If you mutate the ledger, you will not satisfy the rules of a valid ledger. A valid ledger needs that every block is correctly signed. Thus, you 'broke' the ledger.
If chaining the blocks with hashes makes easier to check the validity of the whole chain, I think is a different dicussion.
That is true, but doesn't mean that you NEED to chain hashes to prove immutability of the ledger. (as a design feature of the ledger).
Maybe my definition of immutability is not totally correct.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=hTADLeRnS3NkzS64D) @Jgnuid Yes, in theory, your observation is correct in the sense that the trust model does not count on this and the chaining mainly helps in practice by adding a scope of optimization or discovering bugs in implementation. The chaining is essential if the forks are allowed because you need a reference point to anchor the incoming blocks.
@manish-sethi , correct. But in Hyperledger forks are mostly a sign of malicious behaviour or a bug. Is this correct?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=gQPucXguiLFgKFLfi) @Jgnuid Yes. Forks are not allowed by design
Have a problem with creating an index in couchdb and was referred here. Hopefully someone can tell me what I messed up...
Using the java SDK to create chaincode passing in an archive. Code works fine - been stable for months.
Tried to add an index using the instructions in the latest docs.
The archive looks like this:
cut2.png
CC is aacc. index1 looks like this:
```
{
"index":{
"fields":["id", "type"]
},
"ddoc":"index1Doc",
"name":"index1",
"type":"json"
}
```
CC instantiates as expected. Nothing about the couch index though.
What did I miss?
@aatkddny Check your peer log for a message like this:
```2018-09-18 10:53:38.013 EDT [couchdb] CreateIndex -> INFO 223 Created CouchDB index [indexOwner] in state database [myc_marbles] using design document [_design/indexOwnerDoc]```
I did. It's not there.
That's why I said it didn't work
ok, and if you got no error or warning in peer log, that means the client didn't package it up correctly
I know you've been bounced between chat channels, but if client isn't packaging it up correctly, you'll need to work that issue in the sdk chat channel
Well you can see the archive structure above. It looks exactly the same as that in the documents.
it has to be looked at per SDK
Round and round and round we go.
The SDK sends me here. You send me there.
Is there a different fence to throw it over?
Has joined the channel.
@dave.enyeart He provided you with how it was packaged -- you can't say what's wrong here ?
Peer log
```
2018-09-18 14:54:10.437 UTC [chaincode] Notify -> DEBU 61f [78f231d1] notifying Txid:78f231d109cf8797fa0ed3ebb14775548a83e3b9a6650e0c155d434b0c96a739, channelID:ibm-block-channel
2018-09-18 14:54:10.437 UTC [chaincode] Execute -> DEBU 620 Exit
2018-09-18 14:54:10.445 UTC [ccprovider] NewCCContext -> DEBU 621 NewCCCC(chain=ibm-block-channel,chaincode=aacc,version=1.0,txid=78f231d109cf8797fa0ed3ebb14775548a83e3b9a6650e0c155d434b0c96a739,syscc=false,proposal=0xc422ac8be0,canname=aacc:1.0)
2018-09-18 14:54:10.448 UTC [chaincode] func1 -> DEBU 622 chaincode aacc:1.0 is being launched
2018-09-18 14:54:10.449 UTC [chaincode] LaunchConfig -> DEBU 623 launchConfig: executable:"chaincode",Args:[chaincode,-peer.address=peer0.mediaocean.com:7052],Envs:[CORE_CHAINCODE_LOGGING_LEVEL=info,CORE_CHAINCODE_LOGGING_SHIM=warning,CORE_CHAINCODE_LOGGING_FORMAT=%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message},CORE_CHAINCODE_ID_NAME=aacc:1.0,CORE_PEER_TLS_ENABLED=true,CORE_TLS_CLIENT_KEY_PATH=/etc/hyperledger/fabric/client.key,CORE_TLS_CLIENT_CERT_PATH=/etc/hyperledger/fabric/client.crt,CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/peer.crt],Files:[/etc/hyperledger/fabric/client.crt /etc/hyperledger/fabric/client.key /etc/hyperledger/fabric/peer.crt]
2018-09-18 14:54:10.449 UTC [chaincode] Start -> DEBU 624 start container: aacc:1.0
2018-09-18 14:54:10.449 UTC [chaincode] Start -> DEBU 625 start container with args: chaincode -peer.address=peer0.mediaocean.com:7052
2018-09-18 14:54:10.449 UTC [chaincode] Start -> DEBU 626 start container with env:
CORE_CHAINCODE_LOGGING_LEVEL=info
CORE_CHAINCODE_LOGGING_SHIM=warning
CORE_CHAINCODE_LOGGING_FORMAT=%{color}%{time:2006-01-02 15:04:05.000 MST} [%{module}] %{shortfunc} -> %{level:.4s} %{id:03x}%{color:reset} %{message}
CORE_CHAINCODE_ID_NAME=aacc:1.0
CORE_PEER_TLS_ENABLED=true
CORE_TLS_CLIENT_KEY_PATH=/etc/hyperledger/fabric/client.key
CORE_TLS_CLIENT_CERT_PATH=/etc/hyperledger/fabric/client.crt
CORE_PEER_TLS_ROOTCERT_FILE=/etc/hyperledger/fabric/peer.crt
2018-09-18 14:54:10.450 UTC [container] lockContainer -> DEBU 627 waiting for container(aacc-1.0) lock
2018-09-18 14:54:10.450 UTC [container] lockContainer -> DEBU 628 got container (aacc-1.0) lock
2018-09-18 14:54:10.450 UTC [dockercontroller] Start -> DEBU 629 Cleanup container dcn_dcn-peer0.mediaocean.com-aacc-1.0
2018-09-18 14:54:10.452 UTC [dockercontroller] stopInternal -> DEBU 62a Stop container dcn_dcn-peer0.mediaocean.com-aacc-1.0(No such container: dcn_dcn-peer0.mediaocean.com-aacc-1.0)
2018-09-18 14:54:10.458 UTC [dockercontroller] stopInternal -> DEBU 62b Kill container dcn_dcn-peer0.mediaocean.com-aacc-1.0 (No such container: dcn_dcn-peer0.mediaocean.com-aacc-1.0)
2018-09-18 14:54:10.459 UTC [dockercontroller] stopInternal -> DEBU 62c Remove container dcn_dcn-peer0.mediaocean.com-aacc-1.0 (No such container: dcn_dcn-peer0.mediaocean.com-aacc-1.0)
2018-09-18 14:54:10.459 UTC [dockercontroller] Start -> DEBU 62d Start container dcn_dcn-peer0.mediaocean.com-aacc-1.0
2018-09-18 14:54:10.459 UTC [dockercontroller] getDockerHostConfig -> DEBU 62e docker container hostconfig NetworkMode: dcn_dcn
2018-09-18 14:54:10.460 UTC [dockercontroller] createContainer -> DEBU 62f Create container: dcn_dcn-peer0.mediaocean.com-aacc-1.0
2018-09-18 14:54:10.466 UTC [dockercontroller] Start -> DEBU 630 start-could not find image
peer0-log.txt
In the tar, META-INF must be the top level directory.
In the tar that SDK provides, META-INF must be the top level directory.
BTW hes sending this as his own stream .. so the SDK is not really doing any packaging at all
So the go code goes under /src but metadata stays outside. I'll give that a try. Thanks.
To finally close this out - was stuck in meetings most of the afternoon
```
2018-09-19 00:32:23.251 UTC [couchdb] CreateIndex -> DEBU 405 Entering CreateIndex() indexdefinition={
"index":{
"fields":["id", "type"]
},
"ddoc":"index1Doc",
"name":"index1",
"type":"json"
}
```
Thanks for the pointer.
@aatkddny nice. question - what would have helped you figure this out sooner? better fabric readthedocs? better sdk docs? something else?
It was an odd problem. I'm using the java SDK, which means I'm trying to figure things out without the benefit of documentation that's as comprehensive as that for node. The file structure is slightly different for one. It expects a /chaincode_name directory with the go files inside it for each chaincode.
You can see that from cut2.png uploaded above my CC is aacc and the go for it is aacc.go .
If you look at the marbles example in the docs the meta-inf is inside a directory with the go file.
If the docs explicitly said that meta-inf had to be a top level directory rather than in the /chaincode_name I'd likely not have screwed it up quite as badly.
It was an odd problem. I'm using the java SDK, which means I'm trying to figure things out without the benefit of documentation that's as comprehensive as that for node. The file structure is slightly different for one. My code expects a /chaincode_name directory with the go files inside it for each chaincode.
You can see that from cut2.png uploaded above my CC is aacc and the go for it is aacc.go .
If you look at the marbles example in the docs the meta-inf is inside a directory with the go file.
If the docs explicitly said that meta-inf had to be a top level directory rather than in the /chaincode_name I'd likely not have screwed it up quite as badly.
It was an odd problem. I'm using the java SDK, which means I'm trying to figure things out without the benefit of documentation that's as comprehensive as that for node. The file structure is slightly different for one. My code expects a /chaincode_name directory with the go files inside it for each chaincode.
You can see that from cut2.png uploaded above - my cc name is aacc and the go file for it is aacc.go .
If you look at the marbles example in the docs the meta-inf is inside a directory with the go file.
If the docs explicitly said that meta-inf had to be a top level directory rather than in the /chaincode_name I'd likely not have screwed it up quite as badly.
It was an odd problem. I'm using the java SDK, which means I'm trying to figure things out without the benefit of documentation that's as comprehensive as that for node. The file structure is slightly different for one. My code expects a /chaincode_name directory with the go files inside it for each chaincode. It then packages them into an archive with structure "src/chaincode_name/..."
You can see that from cut2.png uploaded above - my cc name is aacc and the go file for it is aacc.go.
If you look at the marbles example in the docs the META-INF directory is *inside* the /go directory with the go file.
There's nothing I could see saying that it needs to be pulled out and packaged in a different path from where it is, and not where it is implicitly located - right with the .go file(s). That was the source of the confusion.
If the docs explicitly said that META-INF/ had to be a top level directory at the same level as src/chaincode_name rather than inside the /chaincode_name directory I'd likely not have screwed it up quite as badly.
thanks, we'll improve that
When i try to update the configtx.yaml file to add new channel in profile section and when i execute the peer channel create command then m getting the error "Unknown consortium name: my_consoritum_name" ...........Any solution?
I suggest post to #fabric-orderer , the channel config/creation gurus hang out over there
@plato what we do to lock down couchdb is have peer and its couchdb on their own docker network, without exposing the couchdb port to external clients.
Has joined the channel.
and also set username/password
@dave.enyeart so if I understand you put kind of proxy to access to couchDb but I believe it's good to let anybody if the owner of peer want let to access the data at least for readonly use
in production environments i don't recommend making couchdb available outside of peer
@dave.enyeart look at this http://docs.couchdb.org/en/stable/intro/security.html
peer will set the configured username to be the couchdb database admin and member, this way other users can't access the database, even if the port gets exposed
peer uses the _security api mentioned on your page to set this
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=3dt5fmohobJEZcexM) @dave.enyeart so I believe we have to change the configuration for CouchDb the time that we have install it or maybe after that change the configuration inside the docker But wondering if this impact on the connectivity between peers and DB
change the config for what purpose?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=pHLzGhSCZGKQjgdPo) @dave.enyeart I mean inside docker-compose-couch.yaml to set the value for CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME=
- CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD=
you first set username/password in couchdb and then configure peer to use the same username/password. if using docker compose you can set them both in the same file as demonstrated in the sample here: https://github.com/hyperledger/fabric-samples/blob/release-1.2/first-network/docker-compose-couch.yaml#L15-L35
more info in the doc here: https://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html#couchdb-configuration
Has joined the channel.
I am using this command peer channel upgrade and getting this error.......Error: could not assemble transaction, err Proposal response was not successful, error code 500, msg cannot get package for chaincode (mycc:2.0)....any solution?
Has joined the channel.
As seen on https://hyperledger-fabric.readthedocs.io/en/release-1.2/private-data/private-data.html#what-is-a-private-data-collection :
A collection is the combination of two elements:
1. The actual private data, [...]
2. A hash of that data [...] The hash serves as evidence of the transaction and is used for state validation and can be used for audit purposes.
HI all,
As seen on https://hyperledger-fabric.readthedocs.io/en/release-1.2/private-data/private-data.html#what-is-a-private-data-collection :
A collection is the combination of two elements:
1. The actual private data, [...]
2. A hash of that data [...] The hash serves as evidence of the transaction and is used for state validation and can be used for audit purposes.
How do I do that audit? Should I extract the data directly from the blocks and database? Or can I invoke a query on the hash of the private data key?
On a slightly different topic, I have noticed some very strangely different behavior from using couchDB or levelDB when I use private data:
I am adding a new org into the network after a few transactions involving private data have been made, and then I change the collection definition (via chaincode upgrade operation) to include the new organization into the collection while excluding a previously included organisation.
Using levelDB, the new organisation will not receive any of the previous private data, but it will keep any new private data from new transactions; also, the organisation which lost authorization to the private data will keep the old data, but it will not receive any new private data.
Using couchDB, the old private data will reach the newly joined organization (a pleasant surprise); however, the unauthorized organization will still receive new private data it should no longer be entitled to (quite a breach of privacy).
Can anyone help me understand why using different databases is having different effect on the access to private data?
@GuillaumeTong - the behavior that you described about the leveldb is the expected behavior and should not depend on the db that you are using. Do you want to make sure that somehow your couchdb nodes are not mistakenly configured as a part of single couchdb cluster and data sync is going on in the back channel vis couchdb sync?
Right - we have not seen different behavior for CouchDB state database in our private data tests. @GuillaumeTong If you still see that behavior, please open a jira bug and attach peer debug log for analysis.
The 'nice surprise' that you mention about a new member receiving the old private data, is in fact a new 'reconciliation' feature in development targeted for a future release, but it should not be happening in current releases.
@GuillaumeTong Concerning how to audit private data, currently only way is to retrieve the block or transaction and inspect the readwriteset, the SDKs make this available to clients. There are some other ideas being considered for the future to make this simpler, for example a new chaincode API to retrieve hashes.
I am using this command to set the mod_policy.... jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"mod_policy":"Admins"}}}}}' config.json > modified_config.json....................to set the mod policy in config.json file.
But getting this error............. Error decoding: error decoding input: *common.Config: error in PopulateFrom for field channel_group for message *common.Config: *common.DynamicChannelGroup: error in PopulateFrom for map field groups with key Consortiums for message *common.DynamicChannelGroup: *common.DynamicConsortiumsGroup: expected map field groups value for mod_policy for message *common.DynamicConsortiumsGroup to be assignable from map[string]interface {} but was not. Is string....................Any solution?
Has joined the channel.
I have a doubt, as I am working on Hyperledger fabric
So
How to deploy chaincode in multiple organisation environment,
where all organisations in the environment has a peer node each,
so that any transaction that happens on single organization peer is reflected on the peers of other organizations
i.e how to keep the peers in each organization in sync ?
Or how to setup Hyperledger fabric in multiple organization environment ?
@Wizzy123 This is exactly how Fabric is designed to work. I suggest you read the Key Concepts here: https://hyperledger-fabric.readthedocs.io/en/latest/key_concepts.html
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Q8RejhyFSZPNetZLL) @manish-sethi I am running my test about private data on the "build your first network example", with the private marbles chaincode, then using eyfn to extend the network with an extra organisation wile updating the collection definition. Being mostly unfamiliar with couchDB I have not changed any of its configuration. Most of the initial access control over private data is working correctly, and I can see that the queries to peers from org1, org2 and org3 all give different results, which makes me think that their databases are probably not working as a cluster and sharing data.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=MoRKxmnLeymN5Cmfb) @dave.enyeart Thank you for this info, I'll look into the SDK for that, and I look forward for that hash retrieval API.
@GuillaumeTong - just wondering that could you be running into this because of this error in one of the sample files (https://jira.hyperledger.org/browse/FAB-12073). This is fixed now in this CR - https://gerrit.hyperledger.org/r/#/c/26412/. Can you again give it a try with latest fabric-sample.
also note that the peer's couchdbs do not form a cluster and share data. each peer has a dedicated couchdb, and will commit to its own state database as blocks are committed.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=2mGnJnmmgwymqjecj) @manish-sethi That might indeed explain what I am seeing. Let me try
@manish-sethi after fixing that issue in my files the behavior of the network with couchDB is now as expected: new orgs will not receive old data and old orgs will not receive new data they have been unautorized from.
Thanks for confirming :thumbsup: thumbsup:
No problem. Thanks for helping me find the root of the problem
Fortunately, that bug and fix came in time and I could relate that with your problem. Stars were aligned to help you :-)
Hi. I am using this command to set the mod_policy.... jq -s '.[0] * {"channel_group":{"groups":{"Consortiums":{"groups":{"mod_policy":"Admins"}}}}}' config.json > modified_config.json...................to add a new consortium in the existing network.
But getting this error............. Error decoding: error decoding input: *common.Config: error in PopulateFrom for field channel_group for message *common.Config: *common.DynamicChannelGroup: error in PopulateFrom for map field groups with key Consortiums for message *common.DynamicChannelGroup: *common.DynamicConsortiumsGroup: expected map field groups value for mod_policy for message *common.DynamicConsortiumsGroup to be assignable from map[string]interface {} but was not. Is string.....................Any solution??
Question: Should I think about endorsement policies like a guarantee that the writes to the ledger are "trusted"?. In the sense that enough parties reached consensus about what is the result of a particular chaincode invokation at a specific instant in time?
To put it in another way: Everyone in the channel agrees that if the policy was satisfied, the write to de ledger is correct (even if the write-set is some crazy thing)
I want to be sure to understand correctly that endorsement policies are only an instrument to be sure about writes to the ledger. For example, if all the members of an org were compromised, then if a chaincode has an endorsement policy that needs more than one org, then I'm safe.
Endorsement policies were design to resolve this kind of issues? There are more kind of problems that it solves?
@waxer you got it, sort of
It also reflects who the keys of the chaincode "belongs" to
It also reflects who the keys of the chaincode "belong" to
@yacovm , what are the keys of the chaincode?
like when you do `PutState(key, value)`
@yacovm , oh ok, but I should consider possible other chaincodes that could modify the state of the same keys. But yes, I agree that the 'key' belongs to every endorser of any chaincode (or chaincodes) that in some possible flow update the key. Is this what you mean?
a chaincode can only modify keys of itself
ah, so in my example
i meant to say - when you modify `PutState(key,value)` in chaincode `mycc` then the real key that gets modified is `mycc.key`
even when the transaction is committed, it is checked that the keys that were modified are only the keys of the chaincode of the transaction
unless, it is a chaincode-to-chaincode transaction
and then - all endorsement policies of all chaincodes combined, are checked
@yacovm , huh?!, I think I missed some kind of part of the architecture then. that my be exciting hehe
I wasn't aware that the chaincodes own keys of the ledger.
let's assume they don't
Do you mean that if I create a new chaincode, I cannot PutState of any key of the ledger?
if they don't - doesn't that mean that I can overwrite your writes with my own chaincode?
> Do you mean that if I create a new chaincode, I cannot PutState of any key of the ledger?
so, when you create a new chaincode - it writes to completely different keys
Wait, so you mean that chaincodes create like a new namespace of keys in the ledger? (in the same channel?)
that's exactly what it is.... it's even called `namespace` in the code
Oh man, what a surprise.
Where in the documentation says that?.. I think I've read most of it (maybe wrong)
so the only way to change a keys of a change is to invoke it
so the only way to change a keys of a chaincode is to invoke it
because you need signatures of the peers from the endorsement policy to make the transaction validated
@yacovm , just to be sure about this. If I ask you: 'What is the value of the key KEY1 in the ledger of channel CHANNEL1?'
You should ask me: 'Of what chaincode you're refering to?'
Is that correct?
yes
@yacovm , ok!, what a surprise. Though, it makes a lot of sense.
Chaincode owns their data.
exactly. chaincode is like a digital agreement between parties
@yacovm , this changes waht I thought about what a channel means...
no. channel is a definition of membership of the parties
channel defines the blockchain itself
@yacovm , ok, but there's only one ledger per channel right?, not one ledger per chaincode.
I mean, the ledger is only one (in the channel), and in some block, in a transaction says what chaincode made the write, then it implicitly defines the 'namespace' of the keys modified (or read). is this correct?
Yes.
1 ledger per channel
1 ledger/channel to rule them (chaincodes) all
@yacovm , so a channel is some kind of container that defines what chaincodes could interact to maybe modify multiple 'data domains'?
Considering that data is separated in boundaries defined by chaincodes
Channel is just a logical definition of the mapping between organizations and their CA certificates, orderer addresses, and other configurtion stuff
The mapping implicotly defines who can do what in the channel context
Who is authorized, etc.
But it also define a new ledger
Right. The blocks are produced, and fetched from the orderer in the context of a channel and form a ledger
@yacovm , ok!. Taking advantage of your last sentence: What do you mean that blocks are fetched from the orderer?. I read taht statement too in the documentation.
The orderer doesn't push the block to the leaders?
Or the peers does polling to the orderer?
(I understand 'fetching' as polling. Maybe its wrong)
(TLDR: Blocks are pushed from the orderer to the leaders, or the leaders poll the orderer for new blocks?)
The peer sends a single message saying the first block to get from the orderer
Amd then from that block onward, when the orderer has a new block kt sends it down the stream
Think netflix video stream but with blocks
The blocks are pushed to leader peers
@yacovm , clear!. Thanks a lot for putting light to my doubts 😀
@waxer sure. I also forgot to mention that in fabric v1.3 (will be released next week, but early candidate is released tomorrow I think) - you can set an endorsement policy *per key* (of a namespace).
https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#setting-key-level-endorsement-policies
Interesting. Raises some question, by I'll take a look at the docs first. Thanks!
Are there any plans to support a slightly more - shall we say - flexible (vis-a-vis indexing) state database? I need to do some sql like operations and the number of indexes in couch will be a nightmare to maintain.
Has joined the channel.
Hi,guys in the *data persistence* ,it mount peer and couchdb for restart ,but need kafka and zookeeper and CA to mount for persistent storage?
Has joined the channel.
Hi experts here, Orderers keeping configure transactions for system channel is reasonable. but why orderers also keep all transactions for each application channel? Thank you
Is there a max storage limit of Hyperledger Fabric? Such as, in the case of 6xTB or some other numbers... If so, in case that number is reached, what should we do?
Also, I found that when the ledger size for 1 channel grows, the TPS is getting worse. In my 600 users simulation case, the rough correlation of TPS and # of transactions (each is roughly 2.8x-3.x KB, the transaction just does a simple PutState) is -0.6. Anyone try more about that?
Also, I found that when the ledger size for 1 channel grows, the TPS is getting worse. In my 600 users simulation case, the rough correlation of TPS and # of transactions made (each is roughly 2.8x-3.x KB, the transaction just does a simple PutState) is -0.6. Anyone try more about that?
Has joined the channel.
Has joined the channel.
where is the actual ledger data stored?
@MeenakshiSingh are you asking about the world state of the ledger? if so thats couch db. if youre talking blocks i believe that is stored in a file on the peer but i forget where exactly
Has joined the channel.
Hello,
Can we use views in fabric couchdb?
The ledger (block storage and leveldb state database and indexes) is stored at the configured location here: https://github.com/hyperledger/fabric/blob/release-1.2/sampleconfig/core.yaml#L307
The only exception is if couchdb is configured as state database
There is no maximum to the number of blocks
Hi, When a channel is created, is a separate DB inside the CouchDB container created? How does HLF leverage CouchDB sharding capabilities? Thanks!
There is a CouchDB database created within the CouchDB instance per channel_chaincode combination, in order to isolate the data
The Fabric provided CouchDB docker images sets 8 shards per database, but tests have not been run to actually distribute this across 8 hosts as far as I know
The Fabric provided CouchDB docker image sets 8 shards per database, but tests have not been run yet to actually distribute this across 8 hosts as far as I know
@dave.enyeart As always, thank you!!
Has joined the channel.
Has joined the channel.
@dave.enyeart can i use the `curl` to add an index not by index file which defines in the chaincode install
that's because i want to dynamic add index not just write it in advance
i see the doc `https://hyperledger-fabric.readthedocs.io/en/master/couchdb_tutorial.html?highlight=couchdb%20index` that means when i want to update an index i should install/instantiate chaincode?
i see the doc https://hyperledger-fabric.readthedocs.io/en/master/couchdb_tutorial.html?highlight=couchdb%20index that means when i want to update an index i should install/instantiate chaincode?
i see the doc https://hyperledger-fabric.readthedocs.io/en/master/couchdb_tutorial.html?highlight=couchdb%20index that means when i want to update an index i should upgrade chaincode?
i don't think it's a good choice
because update an index is need by the business,upgrade chaincode is need by the logic
BFT
Has joined the channel.
@dave.enyeart when i want to open the data file in the `/var/hyperledger` i meet the following error
Clipboard - October 6, 2018 12:42 PM
@asaningmaxchain123 the indexes within the chaincode are indexes that all orgs will want to agree to, they should be finalized before doing to production with a certain chaincode version. if your org wants additional indexes, you can use curl to create them
@asaningmaxchain123 the indexes within the chaincode are indexes that all orgs will want to agree to, they should be finalized before doing to production with a certain chaincode version. if your org wants additional indexes, you can use curl to create them. in the future lifecycle enhancements, you may be able to update config including indexes without updating the chaincode itself.
@asaningmaxchain123 the indexes within the chaincode are indexes that all orgs will want to agree to, they should be finalized before going to production with a certain chaincode version. if your org wants additional indexes, you can use curl to create them. in the future lifecycle enhancements, you may be able to update config including indexes without updating the chaincode itself.
on the second question, only one process can open leveldb files at a time
@dave.enyeart thx i got it
Hello, from Fabric v1.1, the naming convention of couch database has been changed. one of the database is named as `channelname_` which holds the `statedb_savepoint`. Is that the complete name or something missing post `_` to be defined in the compose definition of peer?
Hello,
How can we add bulk data in couchdb/
Hello,
How can we add bulk data in couchdb?
@rahulhegde that is the correct name for the channel database. it is differentiated from the old `channelname` database to avoid collisions
@HoneyShah peer commits all the chaincode json writes in bulk at block commit time, since Fabric v1.1.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=rJpW7szzJ3Q92iNc9) @dave.enyeart Does this mean - if i have a multiple write-set in the Endorsement Response, would it be done using a single write to couch database? Is this also applicable even for Read-set, i.e. fetched in bulk during read-set validation.
If the rw set is very large, does peer do the bulk operation in batch?
@rahulhegde yes, all the writes and readset verifications for a chaincode are done in bulk for all the transactions in a block. if there are a huge number of writes, they will be batched up into multiple bulk writes based on core.yaml `maxBatchUpdateSize`
@rahulhegde yes, all the writes and readset verifications for a chaincode are done in bulk for all the valid transactions in a block. if there are a huge number of writes, they will be batched up into multiple bulk writes based on core.yaml `maxBatchUpdateSize`
@rahulhegde yes, all the writes and readset verifications for a chaincode are done in bulk for all the valid transactions in a block. this greatly improves performance starting in Fabric v1.1. if there are a huge number of writes, they will be batched up into multiple bulk writes based on core.yaml `maxBatchUpdateSize`
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=zvnMCFENpha4qovY9) @dave.enyeart This is better. Other part, did you mean bulk fetch of read set would be irrespective of the ledger transaction state (accepted/rejected).
@rahulhegde bulk fetch of readset is used to check all transactions for version conflicts. then all the resulting valid transactions will be bulk written
Question: in case of a dispute regarding the write set of a committed transaction. It would make sense that the client argues that the write set is wrong?. Is he responsible for the write set always since he chose to commit the proposal? It would be a good practice as a client to check the write set to make some sanity checks before taking responsibility?
I want to understand what are the indisputable facts about the responsibility of a transaction.
if A the buyer sends money to B the seller and the seller gets the money transmitted <<< that is the simple case of consensus -- a final sae or transaction <<< indisputable.
With any asset like a container of bananas there is a bill of lading and a receipted delivery but if their is fraud or some damaged or shorted goods ? There is a dispute? There would be no consensus and no change in the blockchain until the dispute is resolved where there can be a consensus?
there* is fraud
@dave.enyeart when the chaincode upgrading the invoke transaction should stop?
@dave.enyeart when the chaincode upgrading the invoke transaction should stop until all the peer has upgrade the chaincode successfully?
In a long view, or better said: in a business perspective, verification of some suspense criterion in a business transaction needs to be adjudicated, (acknowledged and confirmed), by the smart contract to the transaction <<< is what I am thinking.
In business, all transactions have some suspense period. Code is 1,0 or NULL Like apples and oranges but this is like fruit punch ;)
@asaningmaxchain123 i've answered your related question on #fabric-peer-endorser-committer
@Barry_CPF , not sure if your reply was for me hehe
Sort of waxer ... I am working out programing for my own business logic for Hyperledger using Stellar wallet smart contracts as transaction *intermediary* or "trigger" so to speak. Your question seemed to me more of a business logic issue than a coding issue.
I have 3 peers and 1 organisation then if I want to set an endorsement policy such that 2 of 3 peers should endorsed the transaction. Then how can I do this? Can anybody please help?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=PLTHbAFuwEqGcG2LA) @HoneyShah Wouldn't you just count the responses and send to the orderer if you get enough from the peers?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=gydr2PTHjz2CWPwan) @aatkddny How can I do that? I don't understand
your client calls the peers and collects the responses. i can show you an example using the java sdk but based on your response i'm guessing you aren't using that.
Has joined the channel.
When blocks are stored on the ledger (log of transactions, not the state db, which I believe is held in the peer container, correct?), what hashing function specifically is used to link the blocks together? Or is that modular?
@dave.enyeart can you provide an exmaple about `Setting key-level endorsement policies`
@asaningmaxchain123 that text that you provided from https://hyperledger-fabric.readthedocs.io/en/latest/whatsnew.html is actually a link that explains it: https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#key-level-endorsement
and if you want a more concrete example see https://gerrit.hyperledger.org/r/#/c/26232/
@HoneyShah endorsement policies are based on number or orgs endorsing, not number of peers endorsing. if you have 1 org and 3 peers, the only endorsement policy possible is for the one org. now, you as the client may want to ensure that all 3 peers from the one org give the same response, so sure, you could ask all 3 peers to endorse and check that the responses are all the same, but that is not a requirement for the transaction to be validated
@dave.enyeart i pull the master branch for `fabric-samples` but i don't get the example
https://gerrit.hyperledger.org/r/#/c/26232/ is not merged yet
you can cherry pick it if you'd like to try it: git fetch ssh://denyeart@gerrit.hyperledger.org:29418/fabric-samples refs/changes/32/26232/12 && git cherry-pick FETCH_HEAD
i git clone from the github,not gerrit
so i don't fetch it
@dave.enyeart can you merge it?
sorry, it hasnt been reviewed by 2 maintainers yet...
Clipboard - October 12, 2018 2:16 AM
how can i resolve it?
@dave.enyeart
@asaningmaxchain123 , you're accessing a repository where your public key is not registered as permissioned. Are you sure you have to access to that repository? Can you find what are you looking for in https://github.com/hyperledger/fabric ?
@waxer i have resolve it
thx very much
@dave.enyeart i see the https://gerrit.hyperledger.org/r/#/c/26232/ source code, i think it's very hard to understand about the financial market, can you provide a more simple to explain the `Setting key-level endorsement policies`
The more simple explanation is in the target of that link itself: https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#key-level-endorsement
@dave.enyeart can you tell me what's the propose of the `Setting key-level endorsement policies`
@dave.enyeart can you tell me what's the propose of the `Setting key-level endorsement policies` or what's the function of it
This topic explains the purpose and function of key-level endorsement policies: https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html#key-level-endorsement
This topic explains the purpose and function of key-level endorsement policies: https://hyperledger-fabric.readthedocs.io/en/latest/endorsement-policies.html
if there is something in there that is confusing, please raise it so that it can be clarified
thx i got it, the `Setting key-level endorsement policies` provides an Fine-grained endorsement policies for a special `assert` due to multiple reason
thx i got it, the `Setting key-level endorsement policies` provides an Fine-grained endorsement policies for a special `assert` base on multiple reason
it's right?
@asaningmaxchain123 , yes.
My all docker containers of peers and orderer are exiting except the cli container when i run docker-compose command to up my network. What could be the reason? Any info related to this?
@yousaf please stop cross-posting the same question in many channels
I answered you in #fabric-questions
@yacovm okay sir. I am sorry
Question: suppose a client makes a query invoke to a single peer. It gets the endorsement reply with the result of the query. This reply is signed by the peer (as is in a invoke with a readwrite set, right?). My question is: if the peer is malicious, the client has no way of knowing it right?
Say it differently, the current state of the world of the peers shouldn't be trusted. It's a easy store to tamper in the network.
Am I thinking it right?
@waxer In a blockchain network, any one peer may be tampered/corrupted/malicious. The point is, there are multiple peers out there (including your own if you don't trust others), and for critical queries you can cross-check responses from multiple peers to ensure they match.
@dave.enyeart thanks Dave. Regarding that point, why when BFT is talked in Fabric, it only correspons to the ordering service? Yes, Ordering service is critical, but why a Byzantine peer isnt included? Isnt a problem in gossip?
If a peer feeds you 'bad' data (a bad block or bad private data) via gossip, it will be found out by the hash checks at commit time, either at the time you get the bad data or upon receiving the next 'good' block from ordering service or another peer, as the hash chain will not line up. And then the peer that sent the bad data will be found out and can be kicked out of the network. Remember, this is a permissioned network and the assumption is that the peers don't want to be kicked out. So the network is optimized for performance, while still having recourse against bad actors. Anything to add @yacovm ?
it will find it before commit time
gossip verifies the signatures of blocks
so, if a peer changes the signature or changes the data - it will be found and the block will be discarded
also - you can't use hash checks to protect against signature tampering because you commit blocks in-order
you can only do backward hash check validation given that you verified the signature of the last block
but you could find out upon receiving the next honest block, right?
that would be too late, and since blocks are usually produced once per second or two, unless you're doing replication it's not cost effective to do hash chain validation because it means you need to wait for the next block
this would mean you increase latency
i have hash chain validation in raft replication :)
https://gerrit.hyperledger.org/r/#/c/26932/22/orderer/common/cluster/util.go@195
once I finish to write the unit tests... that is
got it, the gossip block signature verification is what protects us, with the block hash check being a 'backup' check
it depends - the backup doesn't protect you completely because if i'm a malicious peer and i feed you sequences 100, 101, 102 - i am probably clever enough to also feed you blocks with "previous hash" that diverges from the real chain,
but of course once you somehow get a real block you'll see and you will crash
but even if there is a clever and powerful adversary that isolates your network and feeds you with blocks only via gossip
it can't do anything
also there is another benefit of checking every block prior to commit
if you don't check each block - then it means the incorrect block enters your memory buffer
and then it means you also don't send other peers that pull from you, the correct block
so, a block is verified only once, and in all pathways it enters the memory
right, that's why i called the hash check a backup check... if we fail there, it is too late to save your chain, but at least you will find out and can start fresh if needed
ok
TLDR @waxer don't worry!
we would only expect to hit the 'backup' hash check upon a catastrophic bug or something
we would only expect to hit the 'backup' hash check failure upon a catastrophic bug or something
we would only expect to hit the 'backup' hash check failure upon a catastrophic bug or some user error
@yacovm , Just to check if I understood correctly: Every peer that receives a block through gossip, checks that block is correctly signed by the orderer. Supposing that the orderer private key wasn't compromised, it would be infeasible that any peer could tamper a block in a 'valid way', thus can't affect gossip distribution.
right
and if you compromise an orderer private key, at any point, it's game over
when we move to BFT
then you'll have to verify several signatures
and then it will be game over only if you compromise a threshold of private keys
@yacovm, right, makes sense. The root of my question was thinking about if solving byzantines in the ordering service, would imply that the whole network is BFT. I think I have some trouble defining exactly what a 'failure' would mean in the network. Do you have some kind of idea about what could be a definition of that?. Seems reasonable to say that the network has 'failed' if exists a fork in the honest peers?, or could be a weaker definition?
i don't understand
@yacovm , saying that Fabric is BFT, means that the network cannot fail due to byzantine faults. What would mean that the network 'fails'?
well BFT is being resistant to byzantine failures that make the blockchain be split
meaning, that 2 honest nodes have a different blockchain
Ok, so having no forks is the ultimate metric to define if the network has failed.
@yacovm , @dave.enyeart , thanks both for your help! :)
Has joined the channel.
Hello! I'm parsing сhannel using nodejs SDK and have two question:
1. metadata.metadata[2] array contains information about the validity of the transactions. I've seen status codes 0 (VALID) and 11 (MVCC_READ_CONFLICT). Are there exist another status codes?
2. data.data[tx_index].payload.data.actions - the length of this array for me is always 1, actions[0] contains information about chaincode invocation and so on. Why "actions" is an array? Is it possible that its size will be more than 1?
Hello! I'm parsing сhannel blocks using nodejs SDK and have two question:
1. metadata.metadata[2] array contains information about the validity of the transactions. I've seen status codes 0 (VALID) and 11 (MVCC_READ_CONFLICT). Are there exist another status codes?
2. data.data[tx_index].payload.data.actions - the length of this array for me is always 1, actions[0] contains information about chaincode invocation and so on. Why "actions" is an array? Is it possible that its size will be more than 1?
@krabradosty See the list of possible invalidation codes here: https://github.com/hyperledger/fabric/blob/master/protos/peer/transaction.proto#L115-L143
Currently peer only supports 1 action, in the future there is intent for peer to support N actions in a single transaction
Currently peer only supports 1 action, in the future there is intent for peer to support N actions in a single atomic transaction
Has joined the channel.
Has joined the channel.
Question: if I QueryChaincode to another chaincode, that means that keys read from the QueryChaincode chaincode would be included in the readset of the proposal?
And in the same vein, the queryed chaincode should necessary be installed in the same peer?
Has joined the channel.
@waxer Only if the chaincode you are calling is on the same channel. Otherwise the two requests are completely independent.
Is there a history database for sidedb? A presentation by Arnaud Le Hors indicated there is.
@toddinpal No, GetHistoryForKey api and underlying history database does not exist for private data
@dave.enyeart Thanks, that's what I thought, but this preso from Arnaud says otherwise: https://www.slideshare.net/alehors/hyperledger-fabric-update-june-2018
@toddinpal that is an architecture chart from private data design charts... history db is in fact planned, just not implemented yet
Has joined the channel.
Related to side db, the documentation diagram https://hyperledger-fabric.readthedocs.io/en/release-1.2/private-data/private-data.html seems to imply that the key is hashed. I was under the impression that only the value is hashed. Is the key indeed hashed?
key and value are hashed
the key itself may review private information. the hashed key enables version validation - all peers can validate based on the hashed key.
the key itself may reveal private information. the hashed key enables version validation - all peers can validate based on the hashed key.
@dave.enyeart Thanks Dave. Was this a change as I thought the key in the past was not hashed?
not a change, been like that since the initial private data delivery
hello @dave.enyeart - we would like to use the automatic compaction http://docs.couchdb.org/en/stable/config/compaction.html#config-compactions available as part of fabric v1.2 couch db image. Can you help how we can modify the .ini file or use docker environment variable?
@rahulhegde It should be configured by default... Look in your couchdb's default.ini, you should see [compaction_daemon] and [compactions] sections pre-configured.
For doc on config files in general, see http://docs.couchdb.org/en/stable/config/intro.html
I was not able to keep couch database container running when i tried to add docker host mount /opt/couchdb/data & /opt/couchdb/env. This only created `/opt/couchdb/env/local.d/docker.ini` but could not see rest of *.ini file. If this is not getting created, i cannot edit it - Problem1? I am using the ibm-blockchain image.
Q?
First, before it gets created for the first time, is there way i could use docker environment variable to update to the required value in *.ini file - i feel the answer is no?
secondly - if i update the *.ini file, would the current docker update back to default value or should reuse what is it in - again expect to be later?
If i multiple *.ini, is there order
I was not able to keep couch database container running when i tried to add docker host mount /opt/couchdb/data & /opt/couchdb/env. This only created `/opt/couchdb/env/local.d/docker.ini` but could not see rest of *.ini file. If this is not getting created, i cannot edit it - Problem1? I am using the ibm-blockchain image.
Q?
First, before it gets created for the first time, is there way i could use docker environment variable to update to the required value in *.ini file - i feel the answer is no?
secondly - if i update the *.ini file, would the current docker update back to default value or should reuse what is it in - again expect to be later?
the docker image comes pre-configured with /opt/couchdb/etc/default.ini having compaction configuration
you could re-build fabric-couchdb docker image with an updated config
0.4.10 config file is at: https://github.com/hyperledger/fabric-baseimage/blob/v0.4.10/images/couchdb/local.ini
local.ini takes precedence over default.ini, the full details are documented at http://docs.couchdb.org/en/stable/config/intro.html
The preference would be to use the same couch image that is released. I did add the volume mount but the couch database container failed to start.
If i get the default.ini after successful starting the couch container, I should be able to edit with changed default compaction setting strict_window = true and enable from-to. would it overwrite on the next start?
I'm not an expert in the docker mounting and persistence options, I'd have to point you to the docker doc. If you always want a certain config though, I'd recommend rebuild the couchdb image with the config you want
Hello everyone, I have setup a small network with 3 peers (p1, p2, p3) and two channels (ch1, ch2). p1 and p2 have access to ch1 and p1, p3 have access to ch2. Now what I would like to do is to make peer 1 (p1) read data from channel 1 (ch1) and execute a chaincode on ch2 based on that. Can anyone give me some direction on how to do that? Do I need to write some code on the p1 container to do that?
@Nabilel 1 You would need to do that in your client application code. Application reads from channel 1 (against p1 or p2) and then propose a transaction for channel 2 (against p1 and/or p3 depending on endorsement policy). Note that the channel interactions would be independent transactions.
yes I need it in the client application
ok great thank you
Has joined the channel.
Has joined the channel.
Question: how is the correct way of deleting a channel of a network?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=eSiFtExRpSBsbnZsP) @dave.enyeart no problem - i see w/o docker image rebuild, i may not achieve the same. Thanks @dave.enyeart
Has joined the channel.
Has joined the channel.
Has joined the channel.
In which folder leveldb files are stored inside peer container and is there a way we can view leveldb file ?
Has joined the channel.
Has joined the channel.
@dave.enyeart I am facing issue with one of the peers. Actually one of the peer server was down for some days. until then we upgraded the chaincode and redeployed it with the help of other peers in the network. Now since this peer which was down earlier came up again and running but now when we tried to upgrade the chaincode then this peer event hub is throwing error stating that
[committer/txvalidator] validateTx -> ERRO 00c VSCCValidateTx for transaction txId = 1d685017f2d2cbc1856e874715a2be9f532ceaa3ead2795bf345a388e7b8a1ac returned error: chaincode mycc:105.0/fatico-btic didn't match mycc:4.0/fatico-btic in lscc
@dave.enyeart I am facing issue with one of the peers. Actually one of the peer server was down for some days. until then we upgraded the chaincode and redeployed it with the help of other peers in the network. Now since this peer which was down earlier came up again and running but now when we tried to upgrade the chaincode then this peer event hub is throwing error stating that
instantiate-chaincode - Transaction 1d685017f2d2cbc1856e874715a2be9f532ceaa3ead2795bf345a388e7b8a1ac has status of MVCC_READ_CONFLICT in blocl 36
Also when i tried to invoke on this peer it shows the below error in peer logs
[committer/txvalidator] validateTx -> ERRO 00c VSCCValidateTx for transaction txId = 1d685017f2d2cbc1856e874715a2be9f532ceaa3ead2795bf345a388e7b8a1ac returned error: chaincode mycc:105.0/fatico-btic didn't match mycc:4.0/fatico-btic in lscc
and below logs in node sdk
[2018-11-13 08:58:29.480] [INFO] invoke-chaincode - Transaction aa5521dcf496b9fe3d937a338bf893569ed197c109ab2b46c260d9aa875da671 has status of EXPIRED_CHAINCODE in blocl 40
[2018-11-13 08:58:29.480] [ERROR] invoke-chaincode - The invoke chaincode transaction was invalid, code:EXPIRED_CHAINCODE
[2018-11-13 08:58:29.481] [ERROR] invoke-chaincode - Error: The invoke chaincode transaction was invalid, code:EXPIRED_CHAINCODE
I don't know what "redeployed it with the hold of other peers" means. Can you clarify what you mean? Your block height and state database may be out of sync. You can drop the state database, upon restart peer will rebuild it. Are you using leveldb or couchdb state database?
I don't know what "redeployed it with the help of other peers" means. Can you clarify what you mean? Your block height and state database may be out of sync. You can drop the state database, upon restart peer will rebuild it. Are you using leveldb or couchdb state database?
@MohammadObaid There are various leveldb databases within the /var/hyperledger/fabric directory. There is no good way to view them. You could switch state database to couchdb if you want to view the data in development environment.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=c5oGf6G3awxguHdST) @dave.enyeart i have two channels with this peer. for one channel this is working fine but on the other channel it is unable to upgrade / invoke on this peer
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=c5oGf6G3awxguHdST) @dave.enyeart i have two channels with this peer. for one channel this is working fine but on the other channel it is unable to upgrade / invoke on this peer. Now how to delete the state database for a particular channel specifically which folder under /var/hyperledger/production?
Are you using leveldb or couchdb as state database?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=SjLhNPHb7aYTRvefC) @dave.enyeart I am using couchDB
@javrevasandeep Here's I drop and restart couchdb:
```docker stop couchdb
docker rm couchdb
docker run --publish 5984:5984 --detach --name couchdb hyperledger/fabric-couchdb
```
if you are persisting data to a host volume, then delete couchdb data from `/opt/couchdb/data`
when you restart peer, the couchdb state database will be rebuilt from the blockchain
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=gDeF53XgqJMNFC46r) @dave.enyeart ok i will try this out but I am wondering what will happen to historyDB, will that also be built up from scratch from other peers
@javrevasandeep history db is also built from the blockchain. if you suspect it is not correct you can drop it so that it gets rebuilt upon peer startup. location is /var/hyperledger/production/ledgersData/historyLeveldb/
if you've got multiple things going wrong for whatever reason, i'd suggest to make a new peer and re-join the channel rather than spend cycles fixing it piece by piece
@dave.enyeart what i should do in order to block access to a channel. say i may want to make a channel read only or i may want to restrict it for both read and write
@javrevasandeep see https://hyperledger-fabric.readthedocs.io/en/latest/access_control.html
Hello,
When chaincode container remains idle for some time then it stops with error:
```
ERROR [lib/handler.js] Chat stream with peer - on error: "Error: 14 UNAVAILABLE: EOF\n at createStatusError (/usr/local/src/node_modules/grpc/src/client.js:64:15)\n at ClientDuplexStream._emitStatusIfDone (/usr/local/src/node_modules/grpc/src/client.js:270:19)\n at ClientDuplexStream._receiveStatus (/usr/local/src/node_modules/grpc/src/client.js:248:8)\n at /usr/local/src/node_modules/grpc/src/client.js:804:12"
```
And when the first request comes after idle time it gives an error of
```
Error: 14 UNAVAILABLE: TCP Write failed
```
And after that all works fine. How can I solve for the first request? Please help
hello, suppose a peer suddently cannot work when it is committing a block because of poweroff or somthing else. what should the peer do when it restarts? pull the ledger from other peers in the same channel? Thank you.
the answer should be yes. just like a new joined peer, maybe many blocks have been produced since the failure, so the peer should pull ledger from other peers.
@qsmen
If the peer is a gossip leader in the org:
- then it always pulls blocks from orderer
If the peer is not a gossip leader:
- if the peer is current or just a little behind (within a cache threshold), then it gets blocks as usual via gossip from the org's leader peer (or potentially another peer in the org).
- if the peer is way behind, then it gets blocks via block transfer from another peer (can be cross-org)
Hello,
What if someone change data of couchdb directly using commandline or interface? I tried to modify it from interface then when we query data using getState from same peer then it gives us modified data which is wrong. So how can we resolve this?
@HoneyShah See answer here: https://lists.hyperledger.org/g/fabric/message/4896
Has joined the channel.
Has joined the channel.
Thank you Dave for the detailed explanation.
@dave.enyeart each org must have one anchor peer at least
@dave.enyeart should assign it by myself or dynamic assign by fabric ?
you must configure anchor peers in a config transaction. please use #fabric-gossip for gossip config questions.
you must configure anchor peers in a config transaction. please use #fabric-gossip for gossip config questions, the experts in gossip hang out over there.
Has joined the channel.
Hi,
I have a question about the CouchDB databases created and used by the Hyperledger Fabric:
If I define a Private Data collection "org1only", I get 2 Couch databases called "[namespace]$$horg1only" & "[namespace]$$porg1only".
(The difference is "h" vs "p")
The question is what is their purpose and what is the workflow between them?
The use case/test scenario is (even I misuse the private data concept):
I have org1 & org2 and a collection "org1only" defined (using the java sdk) by referencing ONLY the org1 members.
Then the chaincode transaction signed and endorsed by ORG2 user & peer tries to write to the "org1only" collection.
Later org2 can not read the data. The data seems to be written to the "h" database, but the read uses the "p" database.
I can not see any Errors or Warnings in the peers logs (Org1 & Org2)...
Thanks,
Venko
Hi,
I have a question about the CouchDB databases created and used by the Hyperledger Fabric:
If I define a Private Data collection "org1only", I get 2 Couch databases called "[namespace]$$horg1only" & "[namespace]$$porg1only".
(The difference is "h" vs "p")
The question is what is their purpose and what is the workflow between them?
The use case/test scenario is (even I misuse the private data concept):
I have org1 & org2 and a collection "org1only" defined (using the java sdk) by referencing ONLY the org1 members.
Then the chaincode transaction signed and endorsed by ORG2 user & peer tries to write to the "org1only" collection.
Later org2 can not read the data. The data seems to be written to the "h" database, but the read uses the "p" database.
I can not see any Errors or Warnings in the peers logs (Org1 & Org2)...
Thanks,
Venko
Hi Dave,
Hi,
I have a question about the CouchDB databases created and used by the Hyperledger Fabric:
If I define a Private Data collection "org1only", I get 2 Couch databases called "[namespace]$$horg1only" & "[namespace]$$porg1only".
(The difference is "h" vs "p")
The question is what is their purpose and what is the workflow between them?
The use case/test scenario is (even I misuse the private data concept):
I have org1 & org2 and a collection "org1only" defined (using the java sdk) by referencing ONLY the org1 members.
Then the chaincode transaction signed and endorsed by ORG2 user & peer tries to write to the "org1only" collection.
Later org1 (fixed after Dave's reply) can not read the data. The data seems to be written to the "h" database, but the read uses the "p" database.
I can not see any Errors or Warnings in the peers logs (Org1 & Org2)...
Thanks,
Venko
@ivanovv the 'p' database stores the actual private data on the collection member peers. the 'h' database stores a hash of the private data on all peers. basically the 'h' database is needed so that all peers can do state validation at commit time, even though they don't have access to the actual private data. The private data collection defines which org peers can accept, persist, and query for the private data. In your example, org2 is indeed allowed to write private data to org1only, but org2 peers would not get the private data and therefore could not query it for users of the org2 peer. You may want to do this for example if org2 was transferring an asset to org1. org2 could delete the asset from their collection and write it to org1 private data collection. then only org1 peers would have the private data, and only org1 peers could later transfer the private data to somebody else.
Hi Dave,
thanks for the quick and punctual answer... but now I see I have made a mistake in my previous description (reverted the roles for clarity - my apologies for that ):
org1 can not read from "org1only" collection (the data written there by org2).
If you say that org2 CAN write to the org1only collection, this means that I have made mistake somewhere in the configs...
I do not see any errors/warnings and the collection definition is like:
{
"StaticCollectionConfig":{
"name":"org1Only",
"SignaturePolicyEnvelope":{
"identities":[
{
"user1":{
"role":{
"name":"member",
"mspId":"Org1MSP"
}
}
}
],
"policy":{
"1-of":[
{
"signed-by":"user1"
}
]
}
},
"requiredPeerCount":0,
"maximumPeerCount":0,
"blockToLive":0
}
}
and the org2 executes:
APIstub.PutPrivateData("org1only", key, value)
Thanks again and sorry for the confusion,
Venko
Hi Dave,
thanks for the quick and punctual answer... but now I see I have made a mistake in my previous description (reverted the roles for clarity - my apologies for that ):
org1 can not read from "org1only" collection (the data written there by org2).
If you say that org2 CAN write to the org1only collection, this means that I have made mistake somewhere in the configs...
I do not see any errors/warnings and the collection definition is like:
{
"StaticCollectionConfig":{
"name":"org1only",
"SignaturePolicyEnvelope":{
"identities":[
{
"user1":{
"role":{
"name":"member",
"mspId":"org1MSP"
}
}
}
],
"policy":{
"1-of":[
{
"signed-by":"user1"
}
]
}
},
"requiredPeerCount":0,
"maximumPeerCount":0,
"blockToLive":0
}
}
and the org2 executes:
APIstub.PutPrivateData("org1only", key, value)
Thanks again and sorry for the confusion,
Venko
The difference in the letter case in the description & the example is correct in my code (is not causing the issue).
Hi Dave,
Thanks for the quick and punctual answer (i have actually made a mistake in my problem description - it is fixed now).
Your statement that "org2 is INDEED ALLOWED to write private data to org1only" confirmed to me that I should be able to do what i needed and after a change in the collection policy I solved the issue.
Originally I had "requiredPeerCount&maximumPeerCount = 0", and after changing this to 1 the problem was solved.
I was misled by using a config like "org1andorg2" collection definition that worked (AFAI remember) with both values set to 0.
Thanks again for the great help!
Venko
Has joined the channel.
Has joined the channel.
Folks we are running into an issue when the number of transactions in the ledger increases,ledger query performance degrades badly. In our Fabric 1.1 implementation, we have an asset defined as follows:
asset TransferPointsTxn identified by transactionId {
o String transactionId
--> Account account
}
Basically we have a participant called account, and the transactions the account makes is recorded in this asset with transactionId pointing to the ledger transaction. What we are seeing is, when we try to look at an Account's transactions, cycling through the TransferPointTxn asset is pretty fast (it is from couchdb, and the query is indexed with a view etc) but when we try to pull the corresponding transaction from the ledger with a nested query based on transactionid, the retrieval from the ledger slows drown dramatically. With less than 100,000 transactions in the ledger, we are now seeing that it takes almost 2 seconds to retrieve each transaction from the ledger.
The query on TransaferPointsTxn asset itself takes only a few seconds totally for a typical account, but the subquery to retrieve each transaction from the ledger is taking almost 2 seconds per transaction! This means if a customer has 20 transactions, we spend 2 + 20*2 = 42 seconds for the retrieval.
2018-11-15T23:31:34.030Z [886d63c2] DEBUG :NodeDataService :executeQuery() > {"selector":{"\\$class":"com.gm.lob.loyalty.TransferPoints","\\$registryType":"Transaction","\\$registryId":"com.gm.lob.loyalty.TransferPoints","transactionId":{"$eq":"0d38c9fbb1263b12d69f78855fc592ac2910a433b53baaa9aa9f71560bce3bd9"}}}
2018-11-15T23:31:36.563Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2533.00
2018-11-15T23:31:38.818Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2222.00
2018-11-15T23:31:41.449Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2619.00
2018-11-15T23:31:43.944Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2480.00
2018-11-15T23:31:46.113Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2152.00
2018-11-15T23:31:48.664Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2529.00
2018-11-15T23:31:50.347Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 1655.00
2018-11-15T23:31:52.645Z [886d63c2] DEBUG :NodeDataService :@PERF executeQuery() Total (ms) duration: 2262.00
So question really is, as we add more transactions to the ledger, are there ways for improving query performance of the ledger ?. WIth assets and participants being in Couchdb, the performance there can be optimized various ways, but what tools do we have to optimize ledger query performance ?
@MaheshBalan_Pravici Make sure the CouchDB index covers all the fields in your query. Fully indexed queries should be fast. Note that Fabric doesn't interfere in the actual CouchDB query, you should be able to reproduce the same result outside of Fabric. So if you still have issues, try it outside of Fabric for example using the Fauxton client to query, and then open an issue against CouchDB: https://github.com/apache/couchdb/issues. They will be more likely to help if you can isolate an issue using Fauxton client to directly query CouchDB.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=GkyPkWFe7tA4B229z) @dave.enyeart thanks for your reply. cActually my problem seems to be with reading the ledger itself.
```
```
query TransferPointsByTxId {
description: "Select TransferPoints transactions by transactionid"
statement:
SELECT com.test.TransferPoints WHERE (transactionId == _$transactionId)
}
query TransferPointsTxnByAccount {
description: "Select all TransferPointsTxn by account"
statement:
SELECT com.test.TransferPointsTxn WHERE (account == _$account)
}
The couchdb query, which is the second query which gets from the asset the list of a customer's transactions itself is very fast taking 2 seconds. But for each row retrieved from that query, I am querying the ledger itself with the first "TransferPointsBtTxnId" query, which tries to query the ledger for a single transaction by the transaction id. This is the query which seems to get worse and worse as we add more transactions. Is there any way to optimize the reading of the ledger itself, short of emitting the Transactions and storing it in a separate database for query purposes ?
@MaheshBalan_Pravici ok, in that case please open a Fabric jira issue and attach peer debug, e.g.:
```CORE_LOGGING_LEVEL=info:chaincode=debug:endorser=debug:kvledger=debug:lockbasedtxmgr=debug:statecouchdb=debug:couchdb=debug:statebasedval=debug:fsblkstorage=debug peer node start```
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=EEPzzfhtsidoYcrLz) @dave.enyeart Will do. Thanks.
@manish-sethi I noticed that in 1.3 there are new Get/Set/DeleteStateMetadata functions in the ledger interface; it looks like the plumbing is already in place to eventually expose them through the chaincode shim. Are there any details about the semantics and usecases of those functions? It looks like they allow you to associate K/V pairs to a key, but I would like to understand a bit more about them. Thanks!
@minollo - these functions are not meant to expose directly to chaincode shim as is. The metadata associated with a key is primarily meant to persist additional security info with the key - which in the shim is exposed via 'Get/SetStateValidationParameter'. Only for internal flexibility they are exposed as a map. This is mainly used in the recently added feature named 'key-based-endorsement' (interchangeably referred as 'state-based-endorsement').
@minollo - these functions are not meant to expose directly to chaincode shim as is. The metadata associated with a key is primarily meant to persist additional security info with the key - which in the shim is exposed via 'Get/SetStateValidationParameter'. Only for internal flexibility they are exposed as a map. This is mainly used in the recently added feature in version 1.3 named 'key-based-endorsement' (interchangeably referred as 'state-based-endorsement').
You can find more details about this feature in docs here - https://hyperledger-fabric.readthedocs.io/en/release-1.3/endorsement-policies.html#setting-key-level-endorsement-policies
Got it; thanks @manish-sethi
Hello, Can someone please guide me to a resource relating to back-up/restore procedure for Hyperledger fabric network.
The best I could find is this: https://jira.hyperledger.org/browse/FAB-3364
Has joined the channel.
@melwindmello , if you use kafka, take care of good redundancy in the cluster. If you don't use kafka and are worries about data loss, use kafka.
Has joined the channel.
Thanks you @waxer .
However, I am looking at specific steps to backup/restore a Peer node (for now and then for Orderers, CAs) in case of total network failure. Kafka will provided take care of the Orderes.
I am following this https://jira.hyperledger.org/browse/FAB-3364 and was hoping that someone might have done this.
However, I am looking at specific steps to backup/restore a Peer node (for now and then for Orderers, CAs) in case of total network failure. Kafka will take care of the Orderes.
I am following this https://jira.hyperledger.org/browse/FAB-3364 and was hoping that someone might have done this.
@melwindmello kafka will take of the Orderers, and thus the peers indirectly.
If you want to avoid reprocessing the ledger again, thats another requirement. But all the necessary information to restore any orderer and any peer is in the kafka cluster.
If you bootstrap an Kafka-Orderer with 'FileLedger' and pre-existing blocks, will it revalidate the chain?
Has joined the channel.
https://www.businesswire.com/news/home/20181128005680/en/Amazon-Web-Services-Announces-AWS-Outposts
for file ledger, we are using `FD.Sync()` to flush data to disk [here](https://github.com/hyperledger/fabric/blob/d200615cd6f95f5ec19cf89fc5198aa754bfd57b/common/ledger/blkstorage/fsblkstorage/blockfile_rw.go#L43). However, I came across [this golang issue](https://github.com/golang/go/issues/26650), which may lead to using `syscall.Syscall(syscall.SYS_FCNTL, f.Fd(), uintptr(syscall.F_FULLFSYNC), uintptr(0))` instead. Maybe someone could take a look? cc @manish-sethi
Thanks @guoger for pointing to this - I'll take a closer look.
@manish-sethi thanks! I probably should've noted that it's for OSX only. let me know if you have any further questions :)
(sadly performance is just much worse with `F_FULLSYNC`)
Has left the channel.
@nRyDevOps The Fabric ledger has a state database interface that would allow you to add different database implementations. I know people have done trial MongoDB implementations, but nobody has submitted such an implementation to Fabric open source.
Has joined the channel.
@dave.enyeart thanks for answering this question as it helps me move forward with my testing of Fabric.
Has joined the channel.
Has joined the channel.
In the fabcar example, To whom the car belongs to and who is initializing the ledger precisely which peer?
Suppose there are two peers I want one one peer to setup the some rules or treaty then the second peer has to initialize the data , but while initializing it has to check and satisfy the treaty or rules created by another peer …. Where should I write this thing?
hey hai if you can give me some idea for the above mentioned one if would be great
Has joined the channel.
Quick clarification on Channel Readers as of Fabric 1.2: Are readers essentially committers that don't execute chaincode? They only allow queries via the CSCC and QSCC? Or has the thinking/design behind this changed to reflect what the user chaincode execution can and can't do with respect to reads and writes?
@wlahti can you answer the question from @dileban . The doc may also need to be clarified to explain this...
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=jmRaiKfspMQT6TPAY) @mallikarjunasai995 You can do such validations in chaincode, for example by getting the transaction submitter information using GetCreator() chaincode API or Client Identity Library APIs: https://hyperledger-fabric.readthedocs.io/en/latest/chaincode4ade.html#chaincode-api. For example you can save submitter information as 'owner' information in an asset key/value, and then check this on subsequent transactions. Or require one org submitter to set a key before another org submitter changes a key.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=jmRaiKfspMQT6TPAY) @mallikarjunasai995 You can do such validations in chaincode, for example by getting the transaction submitter information using GetCreator() chaincode API or Client Identity Library APIs: https://hyperledger-fabric.readthedocs.io/en/latest/chaincode4ade.html#chaincode-api. For example you can save submitter information as 'owner' information in an asset key/value, and then check this on subsequent transactions. Or require one org submitter to set a key before another org submitter changes a key in a subsequent transaction.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Nv88A8NWfZDQLrAir) @dave.enyeart thanks for the help but can you tell it in layman terms because i couldn't actually get it
where are assets stored in blockchain network ?
is it only transaction data that is storing if so then wat about assets
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=xdi9vwpoyum9g9ZhR) @mallikarjunasai995 Its stored in state database (couch db or level DB) and transaction data stored in file format as Block
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HkiZQoB3NAiajqLpu) @knagware9 so to store the assets in state dabatabase, do we have to perform a trasaction ?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=3xdiR6XiEdhYsyEPf) @mallikarjunasai995 transaction history and state database update happned at the same time whenever any succesfull transaction commiteed at any peer
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=yeycZ4zRycfXE5sR2) @knagware9 okay thanks ..... but i have small doubt
Suppose there are two peers I want one one peer to setup the some rules or treaty then the second peer has to initialize the data , but while initializing it has to check and satisfy the treaty or rules created by another peer …. Where should I write this thinif you can give me some idea for the above mentioned one if would be great
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=FqtpjkHusjiFwWfvv) @mallikarjunasai995 That we need to write in chaincode and while instatiating the chaincode you need to pass endorsement policy ..https://hyperledger-fabric.readthedocs.io/en/release-1.2/endorsement-policies.html
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=sG8kKD3EhGTeNiots) @knagware9 yes got it but endorsement policy is like what are the peers should accept to perform the successfull trasaction right but here in my case along with endorsement policy i have one peer that sets some rules so my question is where should i configure the rules in chaincode ?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=Z89NrTJ3CxxgHReMd) @mallikarjunasai995 I think in init function of chaincode,,
okay thanks Kamlesh :relaxed:
does peers perform the signing action or users in that peers will do that ?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HKTK7EY2Gv9AxxC75) @wlahti - Sorry to ping you guys directly, but any thoughts on this? @dave.enyeart Anyone else I could ping if walhti is away?
what is the difference between registering an user and enrolling an user?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=7pFGXCSvXhK8v5zhR) @dileban That's correct. They can also read events, which essentially means they can consume all the blockchain data. Many people use events to build other data stores for queries/analytics.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=7pFGXCSvXhK8v5zhR) @dileban That's correct. They can also read events, which essentially means they can consume all the blockchain data. Many people use events to build other data stores for queries/analytics. More granular access control at the data level can be encoded into chaincode logic.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=7pFGXCSvXhK8v5zhR) @dileban That's correct. They can also read events, which essentially means they can consume all the blockchain data. Many people use events to build other data stores for queries/analytics. More granular access control at the data level for individual reads and writes can be encoded into chaincode logic.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=scsQQoijL3an2CXbT) @mallikarjunasai995 Please don't copy and paste questions to multiple channels. This one is appropriate for #fabric-ca . Most of your questions are answered in the Key Concepts docs https://hyperledger-fabric.readthedocs.io/en/latest/key_concepts.html and Tutorials, especially these two: https://hyperledger-fabric.readthedocs.io/en/latest/write_first_app.html https://hyperledger-fabric.readthedocs.io/en/latest/tutorial/commercial_paper.html
Has joined the channel.
Has joined the channel.
Can some one point me to pluggable state database interface. Has any one tried AmazonDynamoDb as world state? Any recommendations. thanks.
I am running Fabric with couchdb, but got the following problem after the system runs for a while, any suggestion?
```
peer0.org1.example.com | 2018-12-10 15:09:56.644 UTC [couchdb] handleRequest -> WARN 13c Retrying couchdb request in 125ms. Attempt:1 Couch DB Error:badmatch, Status Code:500 Internal Server Error Reason:timeout
peer0.org1.example.com | 2018-12-10 15:10:06.771 UTC [couchdb] handleRequest -> WARN 13d Retrying couchdb request in 250ms. Attempt:2 Couch DB Error:badmatch, Status Code:500 Internal Server Error Reason:timeout
peer0.org1.example.com | 2018-12-10 15:10:09.595 UTC [gossip/discovery] func1 -> WARN 13e Could not connect to {127.0.0.1:7051 [] [] 127.0.0.1:7051
@qizhang - my initial suspect would be that couch is overloaded to handle the workload - "panic: Error during commit to txmgr:Couch DB Error:badmatch, Status Code:500, Reason:timeout"
@manish-sethi can you explain why you suspect couchdb overloaded from `panic: Error during commit to txmgr:Couch DB Error:badmatch, Status Code:500, Reason:timeout`?
@qizhang - When you say that you get this error in system tests after a while, I suspected the load in absence of further info. If you think that this is not the case, and you get this error all the time (perhaps, for a specific content) and is reproducible - please open a jira bug with the steps to reproduce.
@manish-sethi Thanks. Yeah, I think you suspection makes sense. Will create JIRA for this issue. This problem does not occur every time, but some times. I set the debug level to be `INFO`, and it is interesting that whenever I saw lots of messages like `couchdb0 | [notice] 2018-12-10T20:15:23.909367Z nonode@nohost <0.32441.10> 082507efcd couchdb0:5984 172.19.0.5 undefined POST /testorgschannel1_lscc/_all_docs?include_docs=true 200 ok 1`, then the couchdb will not panic, otherwise it does.
@manish-sethi Thanks. Yeah, I think you suspection makes sense. Will create JIRA for this issue. This problem does not occur every time, but sometimes. I set the debug level to be `INFO`, and it is interesting that whenever I saw lots of messages like `couchdb0 | [notice] 2018-12-10T20:15:23.909367Z nonode@nohost <0.32441.10> 082507efcd couchdb0:5984 172.19.0.5 undefined POST /testorgschannel1_lscc/_all_docs?include_docs=true 200 ok 1`, then the couchdb will not panic, otherwise it does.
Has joined the channel.
Has joined the channel.
Hi everyone,
in case of a transaction making use of private data: Is the transaction creators identity (certificate) still published to everyone on the channel?
@NilsP 1 yes, but you can use Identity Mixer to make it anonymous: https://hyperledger-fabric.readthedocs.io/en/latest/idemix.html
Has joined the channel.
Hi Team,
I have written an article over fabric ledger. Your feedback would be appreciated. Kindly find the link for article . “Deep dive into Hyperledger Fabric Ledger” by Shyam Pratap Singh https://link.medium.com/2NuQb92ZGS
Has joined the channel.
hello all,
I want to make a Supply Chain Traceability Application for peaches. We have farmers who have peaches and they write when they put fertiliser and such things. When they gather them, they bring them to something like a warehouse for peaches. There the peaches are chosen depending the weight and are packed. The packages are taken by a logistics company and brought to retailers. From the retailers the buyer can scan the number of the package and trace from which farmer are the peaches and when they where fertilised, when hey were transferred etc. Can you give me please an example how this can be done? Farmers, warehouse retail and customer will be my participants? The peaches and the farm in which they are grown will be the assets? how will I show with farm belongs to which farmer and from which farm is each peach? Thanks in advance for the answers!
I want to make a Supply Chain Traceability Application for peaches. We have farmers who have peaches and they write when they put fertiliser and such things. When they gather them, they bring them to something like a warehouse for peaches. There the peaches are chosen depending the weight and are packed. The packages are taken by a logistics company and brought to retailers. From the retailers the buyer can scan the number of the package and trace from which farmer are the peaches and when they where fertilised, when hey were transferred etc. Can you give me please an example how this can be done? Farmers, warehouse retail and customer will be my participants? The peaches and the farm in which they are grown will be the assets? how will I show with farm belongs to which farmer and from which farm is each peach? Thanks in advance for the answers!I want to make a Supply Chain Traceability Application for peaches. We have farmers who have peaches and they write when they put fertiliser and such things. When they gather them, they bring them to something like a warehouse for peaches. There the peaches are chosen depending the weight and are packed. The packages are taken by a logistics company and brought to retailers. From the retailers the buyer can scan the number of the package and trace from which farmer are the peaches and when they where fertilised, when hey were transferred etc. Can you give me please an example how this can be done? Farmers, warehouse retail and customer will be my participants? The peaches and the farm in which they are grown will be the assets? how will I show with farm belongs to which farmer and from which farm is each peach? Thanks in advance for the answers!
I want to make a Supply Chain Traceability Application for peaches. We have farmers who have peaches and they write when they put fertiliser and such things. When they gather them, they bring them to something like a warehouse for peaches. There the peaches are chosen depending the weight and are packed. The packages are taken by a logistics company and brought to retailers. From the retailers the buyer can scan the number of the package and trace from which farmer are the peaches and when they where fertilised, when hey were transferred etc. Can you give me please an example how this can be done? Farmers, warehouse retail and customer will be my participants? The peaches and the farm in which they are grown will be the assets? how will I show with farm belongs to which farmer and from which farm is each peach? Thanks in advance for the answers!
I will also have an angular app as a frontend
Has left the channel.
Has joined the channel.
I have a question about the TxIDs: for example when using stub.GetTxId() from the shim package.
With a given set of inputs (eg. ledger state), can I calculate the TxID for some arbitrary proposal without actually sending it form the client?
Is this a deterministic process?
@zacpl : the txid is generated by hashing the nonce (https://github.com/hyperledger/fabric/blob/release-1.4/protos/common/common.proto#L130) and the proposal/tx creator (https://github.com/hyperledger/fabric/blob/release-1.4/protos/common/common.proto#L127)
it has no relationship with ledger state, other than the fact that no two transactions can have the same txid
why do you need to pre-determine txids? What problem are you trying to solve?
hi expers here, as time passes, the ledger will become large. This will not affetct the ledger-write operation, but the ledger-query operation will be affected. How much does the query operation affected regarding to leger size? Could the ledger be shortened by removing the older part? Thank you.
@aso thank you for your answer!
I'm working on an international trade app. Looking at ways of creating events that are triggered by chaincode invocations of specific functions.
Looking at your answer I am unclear whether the same client could have two identical TxIDs that refered to transactions on different channels. Is this the case, or is the nonce incremented in such a way that proposals are submitted with a different nonce regardless of the channel on which endorsement is sought?
fabric enforces the uniqueness of txids on a channel basis - it's possible that two txes have the same txid on different channels if the same creator chooses the same nonce
@aso how is nonce chosen typically?
the nonce must be chosen randomly, otherwise the transactor might run the risk of compromising their privacy
Has joined the channel.
hi, while retriving records from ledger using startrkey,endkey unexpected results are shown,can any one help here
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=itsgjDd65aJLGB92E) @dave.enyeart hi
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=tbsmiaXXRexvRaSAW) @qsmen @zacpl - Query operations are not much of a concern. Do you have a specific query in mind that you are worrying about. But yes, it has a noticeable impact on storage demand and the time taken for a new peer to join an existing channel. We are planning to start work on state check-pointing that would allow pruning the older data to keep the size under control.
Thank you, Manish-sethi. Even query operation is a concern, it is related to dbbase and can be solved by dbbase technique. expecting the pruning to come.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=cxCpPbC7kP4CnH72E) @manish-sethi hi,feeling there is a bug in getallcarsbyrange(startkey,endkey)...if we give range as 1 to 12 having 20 records it retriving records like this...1,2,11,12,13,14...19...wats this error or bug..any one help me here
@chuda range queries use a lexicographic order
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=wndZrcxjkoTRZHKb5) @dave.enyeart thankyou,,but can you suggest me how i will resolve this issue,,,i need to display records as per range correctly..
Explanation of lexical order https://stackoverflow.com/q/47478926/1332076
@chuda you have two options. 1) utilize couchdb as state database which has support for querying and sorting integer fields within JSON. 2) utilize key range queries but encode the integers in an order preserving string. The most trivial approach would be to zero pad the numbers, although this will waste space, and you must know your longest number in advance. A quick google found this more elegant approach of an order preserving encoding, with a go implementation: https://github.com/jordanorelli/lexnum
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=77ea6c97-70bc-4319-9af2-1d756a8837b5) @mbwhite thankyou for your reply,,,now, iam using couchdb only as state database and tried range queries..and i try to encode string to int but it not allowing int type as key...can you please provide links if u find thank you...
@chuda couchdb does indeed support keys like "2" and "0000002". These work correctly as lexicographical range queries.
however, if using couchdb, it may make sense to include the integer within the json body and do a json query
note that for JSON queries that sort, you will need a corresponding index that includes the sort field. See the couchdb query doc: http://docs.couchdb.org/en/stable/api/database/find.html
I have running byfn network on which I have deployed FABCAR chaincode and invoked the chaincode function `initLedger` which has inserted 10 records onto blockchain.. now using this url `http://localhost:5984/_utils/#/_all_dbs` I can see the records of 10 cars... now If I delete all the data from couch db, can I get it back from the peer's ledger? How?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=BA82EbriQr85Zv4Ae) @FLASHJr yes ,,because you just deleted the couch db(state db) ,ledger is always there in peer side and even state db also can be recreated using ledger db
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=ESSMJijv8PxYQPP72) @knagware9 How?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=tnpRMhzA42tXfRs4G) @FLASHJr you just drop the peer and restart container again ..it will sync the current state of DB from other peer in the network
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=KYNuiCkdoCaHKxxu4) if peer starts up and finds CouchDB databases are missing or at lower block height (based on using an older CouchDB backup), the state database will be automatically re-constructed to catch up to current block height.
Has joined the channel.
https://chat.hyperledger.org/channel/composer?msg=3x3tZ4sXtj7a6Rjno
I amworking a project where large amount of doctor and users will be on the platform and each will have individual account along with lots of personal and business data in the blockchain. But currently i am facing a problem that whenever i am upgrading the business network , all the data gets loss. Still can not find a way to preserve the data while uograding the net work. I am using hyperledger fabric v 1.2 , couchdb as a state db and fabric-cli and loopback as a mid tier to generate the apis for the app. How can i solve this issue to store data which upgradind the business network or restarting it ?
@mefy-pushpendu Data is not lost upon upgrade. Please be sure you understand how docker volumes work and see these topics:
https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#a-note-on-data-persistence
https://hyperledger-fabric.readthedocs.io/en/release-1.3/upgrading_your_network_tutorial.html
@mefy-pushpendu Please don't copy and paste the same question to 10 channels in the future
@dave.enyeart thanks. But can you be more specific about how can i backup data and updagrade the network and restore the data again.
@mefy-pushpendu The upgrade document walks through all the steps: https://hyperledger-fabric.readthedocs.io/en/release-1.3/upgrading_your_network_tutorial.html
anyone know how to fix this error I am getting?
https://github.com/PaddyMc/decentralised-ecosystem-prototype/issues/26
main -> ERRO 001 Cannot run peer because cannot init crypto, missing /etc/hyperledger/msp/users/Admin@org1.example.com/msp folder
I created the directory that it says is missing but still getting the same error
any help would be very much appreciated! 😉
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=o5J2Dd5WcPGEyX3iC) @nRyDevOps issue with your docker volume mounting ..please check did you mounted crypto-config folder
hi , any function to get blockheight from sdk query.js...i have to post current height of the block to th applicaion user
@knagware9 thanks for the reply! I heard back from the developer on Github and have updated the issue.
Has there been any progress with HLF and IPFS or something similar?
https://discuss.ipfs.io/t/combining-ipfs-and-hyperledger-composer/2193
Hi everyone. I have seen that hyperledger cello and hyperledger explorer docs include mongodb and postgresql respectively. Both of the cello and explorer support fabric and fabric only supports level and couchdb. Then how cello and explorer have mentioned about mongo and postgreSql? kindly can somebody explain it?
I am getting the following warning:
(node:6083) DeprecationWarning: grpc.load: Use the @grpc/proto-loader module with grpc.loadPackageDefinition instead
how can I fix this?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=6jb8sBmcvRBWu5KzF) @nRyDevOps Its just warning only due to grpc version changed
Has joined the channel.
Has joined the channel.
Has joined the channel.
hi
What if I change blockchain data from backend through couchdb client
further transactions may not be committed; but is there any way to avoid it
See https://lists.hyperledger.org/g/fabric/message/4896
You should lock down couchdb with username/password and not expose port beyond the peer's docker network
You should lock down couchdb with username/password and not expose port beyond the peer's docker network, so that no external processes can connect and update the data
hey all, looking to get a better understanding of how couchdb is being utilized. all of the peers are interacting with their respective couchdb instances the same way...would this mean that the update sequences for every couchdb instance would be that same?
yes, all peers deterministically process blocks and update their respective state database
read https://hyperledger-fabric.readthedocs.io/en/latest/ledger/ledger.html and https://hyperledger-fabric.readthedocs.io/en/latest/couchdb_as_state_database.html
let us know what confusions remain
thank you!
Has joined the channel.
@dave.enyeart in the release1.3
Clipboard - January 7, 2019 6:10 PM
the three index doesn't support?
if so ,how can i use the sdk to get the specified tx for transaction information
@asaningmaxchain123 you don't have to worry about that, the peer always maintains all three indexes
Has any one tried using a different state database (other than levelDB and couchDB)? Please share.
How can in divide one org into mulptiple divisions with different msp id?
I read the best practice.
I think this kind config can be produced with cryptogen tool with a proper config in crypto-config.yaml.
Am I right?
But I can not find one example regarding this. Any one can help this?
thanks in advance.
is this the sub dir in peer org?
Has joined the channel.
hi, can we store more data in the format of json in ledger??? if not how wecan store more data in a record
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=FkZsfW4QR4TkRs7Hs) @wangdong The best way for this is to use OUs ( organization units) which each pone has diffrent responsibility and obliviously once you want to divided them as subsidiaries of the organization you have to set diffrent OU for each one inside the crypto-config things , let say if you have org1 which it has Marketing and sales department you could have define two different set of msp like org1.marketing and org1.sales which each identity only has access to thier own department , another approch is to define those diffrent department as diffrent organization with the same ca root
@chuda Please read the document carefully
@chuda yes, you can store complex objects within the ledger. fabric does not place any inherent limits on what you can store, it comes down to what can be stored in leveldb/couchdb
@plato Thanks for reply. But no, it is not used as that. It is related to identity administration. You can refer to the CA document.
hi everyone, is the file blockfile_000001 in /var/hyperledger/production/ledgersData/chains/c
hains/mychannel the blockchain?
hi everyone, is the file blockfile_000001 in /var/hyperledger/production/ledgersData/chains/c
hains/mychannel the blockchain?
hi everyone, is the file blockfile_000001 in `/var/hyperledger/production/ledgersData/chains/c
hains/mychannel` the blockchain?
hi everyone, is the file blockfile_000001 in /var/hyperledger/production/ledgersData/chains/c
hains/mychannel the blockchain?
I think so . But not sure
@JayJong
@dave.enyeart can you please confirm us on the same
yes
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=QnghL4Nb2JjWmNDHW) @wangdong at the end of day you have these inside the X509 which OU is part of any certification and obvioulsy ca is in charge to generate the certifications
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=rpM3GCh6XareeLLC3) @jrosmith thank you..please post any docs related to json inserting in to ledger,,,and can you help me here iam struggling to generate key while insertion,,bcoz cleint cannot creating key value...so how can i store value without key,,,r inherently any mechanism to create key..
@chuda assuming your're using go for your chaincode please refer to some of the example chaincodes in [fabric-samples](https://github.com/hyperledger/fabric-samples/). starting out i think the [marbles](https://github.com/hyperledger/fabric-samples/blob/release-1.4/chaincode/marbles02/go/marbles_chaincode.go#L160) chaincode is particularly useful. you can use the unique transaction id associate with the transaction as a key. in the chaincode it is retrieved by using `stub.GetTxId`
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=T5EPjjnoeWFiLo3RQ) @jrosmith Thank you so much, your are suggestion clear more doubts ...please keep sharing
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=BuLYRShzjFBdo9fwk) thank you, but where i need to change attribute data type?..please check this,in node chaincode i didnot find datatype declration of attributes used
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hello everyone,
I have a network with three peers A, B and C. All the peers are in channelone and A and C are in separate channeltwo for certain function in the application. The network uses CouchDB for database purposes. Is it appropriate to sync db of channelone with that of channeltwo such that changes in db of channelone are reflected in the channeltwo db but not the other way around? If not then suggestions would be most welcome.
Thanks.
@AbhishekDudhrejia No, the peer should be the only writer to its state database. If your goal is to have combined reporting, the recommended patterns are 1) listen to block events from both channels and build a fit-for-purpose data store whose schema meets your query needs or 2) replicate the state couchdb databases to a common downstream couchdb database for query purpose.
@AbhishekDudhrejia No, the peer should be the only writer to its state databases. If your goal is to have combined reporting, the recommended patterns are 1) listen to block events from both channels and build a fit-for-purpose data store whose schema meets your query needs or 2) replicate the state couchdb databases to a common downstream couchdb database for query purpose.
Hello,
While using pagination, suppose we are retrieving 10 data per page. I retrieved first 10 data and now I want directly 30-40 data (page 4) directly without retrieving 11-30 records. How can I achieve this?
Hi Guys, can someone help to enable getting history data for a key ? I implemented that functionality in chaincode (GO) and according to documentation set `core.ledger.history.enableHistoryDatabase` to be true. Beeing exact i added such line `- CORE_LEDGER_HISTORY_ENABLEHISTORYDATABASE=true` in `environment` section for peer (docker-compose.yaml), then i restarted network. As the result i am not getting any historical data. Do you have any suggestions ?
@alek It is true with default config, so you shouldn't have to configure. I'd recommend try marbles02 example that demonstrates getHistoryForKey() , see chaincode https://github.com/hyperledger/fabric-samples/blob/release-1.4/chaincode/marbles02/go/marbles_chaincode.go#L692-L702 and instructions https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#using-couchdb ...you dont have to use couchdb through for getHistoryForKey()
@alek It is true with default config, so you shouldn't have to configure. I'd recommend try marbles02 example that demonstrates getHistoryForKey() , see chaincode https://github.com/hyperledger/fabric-samples/blob/release-1.4/chaincode/marbles02/go/marbles_chaincode.go#L692-L702 and instructions https://hyperledger-fabric.readthedocs.io/en/latest/build_network.html#using-couchdb ...you dont have to use couchdb though for getHistoryForKey() ...you can follow the same instructions with the default leveldb
then after you are convinced it works, try to translate the same thing into your chaincode
@HoneyShah As that is not a performant paging pattern, chaincode doesn't have APIs to do that. But you could implement it in your own chaincode by getting a page of 40 and then Next()ing down to the 30th record before returning to client. It will work but not be very efficient... which is exactly why this is not implemented as a provided API. It would be more performant if you had a sorted and filtered query where client passes in starting point via filter condition and you get the next N results from that starting point.
Are there any tools to dump the contents of a ledger in human readable format, i.e., dissects the fields, etc.?
Has joined the channel.
Has left the channel.
Has joined the channel.
@dave.enyeart thanks a lot for support. I made mistake in other part of application - Fabric SDK and that's why i was not able to retreive data.
Has joined the channel.
@toddinpal looking for the same
@pankajcheema There is a tool called Fetchblock (https://github.com/cendhu/fetch-block) that is supposed to do this.
@toddinpal @pankajcheema Node.js SDK also has a queryBlock() method that returns a block decoded into fields : https://fabric-sdk-node.github.io/release-1.4/Channel.html
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=6Yj3LDT6hN45tmAm8) @dave.enyeart Okay, I understood. But I have one question, how can I pass starting point via filter condition? I am only aware about bookmark as starting point.
@HoneyShah Let's say you are doing a query that sorts on appraisedValue. The query could take a filter where appriasedValue is greater than X. Then client can pass in X as the starting point and get the next page of results.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HhRPDgqGEyRzSrFG6) @dave.enyeart Okay. Got it:thumbsup:
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=HhRPDgqGEyRzSrFG6) @dave.enyeart Got it:thumbsup:
I'm calling `stub.invokeChaincode` and getting this error within the peer..
```
peer0.org1.example.com|2019-01-29 12:25:18.566 UTC [chaincode] HandleTransaction -> DEBU 1ecc [ad48f68e] handling INVOKE_CHAINCODE from chaincode
peer0.org1.example.com|2019-01-29 12:25:18.566 UTC [chaincode] isValidTxSim -> ERRO 1ecd no ledger context: mychannel ad48f68e69b199d2b35875d35a2b89771c372a7bfc6ed83db3681d8bab0f99a3
peer0.org1.example.com|
peer0.org1.example.com| could not get valid transaction
peer0.org1.example.com|github.com/hyperledger/fabric/core/chaincode.(*Handler).isValidTxSim
peer0.org1.example.com| /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:545
peer0.org1.example.com|github.com/hyperledger/fabric/core/chaincode.(*Handler).getTxContextForInvoke
peer0.org1.example.com| /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:979
peer0.org1.example.com|github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction
peer0.org1.example.com| /opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:257
peer0.org1.example.com|runtime.goexit
peer0.org1.example.com| /opt/go/src/runtime/asm_amd64.s:1333
peer0.org1.example.com|2019-01-29 12:25:18.566 UTC [chaincode] HandleTransaction -> ERRO 1ece [ad48f68e] Failed to handle INVOKE_CHAINCODE. error: could not get valid transaction
```
Any pointers for debugging please? Or info around this area (Fabric 1.4.0)
Original invocation was from `docker exec cli peer chaincode invoke`
Has joined the channel.
^ above problem is solved - occurs because the `invokeChaincode` was invoking the same chaincode on the same channel (i.e. invoking myself).... kinda daft really!
@dave.enyeart hey Dave, I have stuck with some crazy part in my chain code , which I have put a json in the public ledger with stub.putstate(key,value) and after that I could retrieve the block content and I saw the the json in the content inside the block BUT once I'm trying to use stub.getState(key) unfortunately it return null without any error, any advise ?
@plato Possibly the PutState() transaction got invalidated? Check peer log to see if there is a Warning about invalidation. Otherwise try a known working example such as marbles02 and compare results: https://github.com/hyperledger/fabric-samples/blob/release-1.4/chaincode/marbles02/go/marbles_chaincode.go
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=KneRjn2kHxWNMwCLN) @dave.enyeart @dave.enyeart I have added ObjectType string `json:"docType"` on the struct in my chaincode then everything working fine !!!, just wondering if adding this ObjectType is mandatory or not ?
@plato nope, Fabric doesn't care about the JSON content, ObjectType is only there to demonstrate a data pattern in case your chaincode needs to distinguish between multiple data types.
Has joined the channel.
Has joined the channel.
Has joined the channel.
In HLF 1.4, there is fabric-ca 1.4.0 images but 1.4.0 images of fabric-ca-orderer and fabric-ca-peer is missing. Will fabric-ca-peer and fabric-ca-orderer work with 1.2.1 images?*
@sayan.hlf What is your use case? What do you mean by "work with"?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=exxjEMFjfZDGvWivg) @dave.enyeart @dave.enyeart I am trying to setup a network using Fabric CA and not cryptogen tool. So I have used RCA and ICA containers which uses fabric-ca:1.4.0 images. But for setting up the orderer and peer containers, i see there are no 1.4.0 images available for fabric-ca-orderer and fabric-ca-peer in docker hub. Will it work with this configuration?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=b9kMbvWtuHes6Wm3q) @sayan.hlf I think..there is no need of specific fabric-ca-peer & fabric-ca-orderer image.
Lets imagine a peer that is not an endorser from a chaincode. When he receives a transaction signed by two endorsers. And both endorsers coincide in the read and write set and everything seems fine. How does it know that even when the read write sets of both endorsers are the same, weren't produced by different code of the chaincode?. For example, when both endorsers installed version 2 of the chaincode, one of them modified slightly the code (imagine no signing packages)
@waxer On each peer that executes chaincode, there is check that the hash of the installed chaincode on the peer matches the hash of the chaincode that is instantiated on the channel. So in current releases such a check exists. Interestingly there is a proposal to relax this requirement in future releases. That is, endorsers could run different chaincode logic with their own organization specific validations (for example the chaincode could check some values against their own enterprise systems before endorsing). As long as all endorsers validate the proposal and come to agreement on the read set and write set of a given transaction, what difference does it make that the actual logic to get there was slightly different.
For a deep dive on this proposal, see Peer and Chaincode cloud native deployment support playback at https://wiki.hyperledger.org/display/fabric/playbacks
@dave.enyeart . I see. I understand that relaxation... Each non endorsing peer in fact already is satisfied only with the readwrite set agreement. What I dont like about this idea and the proposak you mention is reproduceability. This already can happen if chaincodes are non deterministic, i.e: call an external API. I think isnt wise to do that or promote that even further. At least for auditability is not nice. I think is an important feature of ledgers...
Im interested in your expert opinion on this. I might be thinking something wrong.
Has joined the channel.
Has left the channel.
Question: can I store imagea close to 100k in the ledger? If yes, should I save it as an array of bytes or a base64 string?
it doesn't matter how you store it... and yes. you can
Thanks @yacovm , gonna save it as a byte array then.
Has joined the channel.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=e2faf2a8-e1ec-4433-870d-d699879c7361) So long as the read/write set is consistent (and unless I misunderstood the whole premise of this thing that's what matters to the orderer) why would allowing different peers to validate differently matter?
Full disclosure - it fixes a use case for us where we have to model a multi-step process with each party giving assent sequentially so I'm in favor. Did I miss something by typing before I had my second cup of coffee?
@aatkddny Read/write set must be consistent across all endorsers. Peers must all validate using the same deterministric logic before commit. The point being discussed here is that in future releases the requirement that chaincode logic be identical across peers may be lifted. The important thing is that peers agree on the final transaction result, how the peers get to those results may be different.
@muralisr @jyellick Concerning the above discussion... In my opinion future releases should have an option (in the chaincode definition) that specifies whether chaincode bytes must be identical across peers. In many cases it would be acceptable for peers to have their own logic (for example org-specific validations in the chaincode logic). But in other cases you may want the chaincode bytes to be identical for reproducablity/auditability reasons (as waxer suggests), as well as a sanity check that you've installed the correct chaincode
@muralisr @jyellick Concerning the above discussion... In my opinion future releases should have an _option_ (in the chaincode definition) that specifies whether chaincode bytes must be identical across peers. In many cases it would be acceptable for peers to have their own logic (for example org-specific validations in the chaincode logic). But in other cases you may want the chaincode bytes to be identical for reproducablity/auditability reasons (as waxer suggests), as well as a sanity check that you've installed the correct chaincode
@muralisr @jyellick Concerning the above discussion... In my opinion future releases should have an _option_ (in the chaincode definition) that specifies whether chaincode bytes must be identical across peers. In many cases it would be acceptable for peers to have their own logic (for example org-specific validations in the chaincode logic). But in other cases you may want the chaincode bytes to be identical across peers for reproducablity/auditability reasons (as waxer suggests), as well as a sanity check that you've installed the correct chaincode
Thats what I figured. As I said it fixes one of our biggest issues with multiple orgs endorsing a single asset simultaneously.
The only other enhancement I personally would wish for is the option to endorse based on write set only. So I can have one org (who has access) do a cross chain code read and the other one (who doesn't) not perform that piece of validation.
@dave.enyeart Thats what I figured. As I said it fixes one of our biggest issues with multiple orgs endorsing a single asset simultaneously.
The only other enhancement I personally would wish for is the option to endorse based on write set only. So I can have one org (who has access) do a cross chain code read and the other one (who doesn't) not perform that piece of validation.
@dave.enyeart Thats what I figured. As I said it fixes one of our biggest issues with multiple orgs endorsing a single asset simultaneously.
The only other enhancement I personally would wish for is the option to endorse based on write set only. So I can have one org (who has access) do a cross chain code read to check that a linked asset is extant, and the other one (who doesn't) not perform that piece of validation.
@aatkddny cross channel reads are not added to read-write set regardless
@aatkddny cross channel reads are not added to read-write set regardless, see https://github.com/hyperledger/fabric/blob/release-1.4/core/chaincode/shim/interfaces.go#L62-L76
@aatkddny cross channel reads are not added to read-write set regardless and are therefore not validated, see https://github.com/hyperledger/fabric/blob/release-1.4/core/chaincode/shim/interfaces.go#L62-L76
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=spSvqzzzkWNA5XYmQ) @dave.enyeart Is that new to 1.4.
I'm asking because istr we ran into a problem where we couldn't read from one peer and could from another and ignoring the failure caused the endorser to reject. It was months ago and we solved it by going a different route, so I don't want to make a federal case about it. I was just curious.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=spSvqzzzkWNA5XYmQ) @dave.enyeart Is that new to 1.4.
I'm asking because istr we ran into a problem where we couldn't read from one peer and could from another and ignoring the failure caused the endorser to reject. It was months ago and we solved it by going a different route, so I don't want to make a federal case about it. I was just curious.
It's also entirely possible that the problem was misrepresented - I didn't write or audit the go code in this instance. Again I was curious if this was new or existing behavior.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=spSvqzzzkWNA5XYmQ) @dave.enyeart Is that new to 1.4.
I'm asking because istr we ran into a problem where channel auth meant that we couldn't read from one peer group, but could from another and ignoring the failure on the second set caused the endorser to reject. It was months ago and we solved it by going a different route, so I don't want to make a federal case about it. I was just curious.
It's also entirely possible that the problem was misrepresented - I didn't write or audit the go code in this instance. Again I was curious if this was new or existing behavior.
@dave.enyeart , in the 'Upgrading your network' article, you mention:
"We can then backup the peer’s ledger and MSP:"
Then it executes:
"docker cp $PEER:/var/hyperledger/production ./$LEDGERS_BACKUP/$PEER"
From what I understand, that backups the ledger. But the MSP isn't in /etc/hyperledger/fabric/msp?
in the 'Upgrading your network' article, it mentions:
"We can then backup the peer’s ledger and MSP:"
Then it executes:
"docker cp $PEER:/var/hyperledger/production ./$LEDGERS_BACKUP/$PEER"
From what I understand, that backups the ledger. But the MSP isn't in /etc/hyperledger/fabric/msp?
Additionally, wouldn't be better to backup the whole /etc/hyperledger/fabric folder?, just to backup the core.yaml if any custom configuration in the new operations service was made (i.e: the host and port).
Has joined the channel.
@Jgnuid yes, msp will be in `/etc/hyperledger/fabric/msp`. when following `Upgrade your network` tutorial, it uses byfn in which we generate the crypto material (msp) locally and mount the msp material to each peer docker container. So we will have the local copy of MSP
no additional backup is not required unless and until we dont delete local copy of MSP
no additional backup of MSP is required unless and until we dont delete local copy of MSP
https://github.com/hyperledger/fabric-samples/blob/4ed3933a8d6977c4c0d00116967f2da4439e4422/first-network/base/docker-compose-base.yaml#L70
@suryalanka , so in the docs you don't mention to backup the /etc/hyperledger/fabric/msp because it's in the host machine? (just repeating to be sure I understood correctly).
@Jgnuid yes
@suryalanka , so it may be a good idea to change '"We can then backup the peer’s ledger and MSP:"' with '"We can then backup the peer’s ledger:". Because it could confuse someone that doesn't remind that the MSP is on another path. Just a suggestion.
(Moreover, mention there where is the MSP to back it up too)
sure
@dave.enyeart @yacovm once I'
I'm trying to run latest version of first network based on 1.4 I'm facing this issue inside the peers
Clipboard - February 25, 2019 4:55 PM
@plato does this answer resolve it? https://stackoverflow.com/a/49649678/8205919
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=FrTTapNMfT35zkHdC) @dave.enyeart thanks!, it works
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hi Team
Could you please provide help on below question
I am using HL 1.2 network. Can i read data from peer which is still in syncing process with other peer.
In other words, lets say one of my peer is down for days and then all of a sudden it came up, so if i read data from this peer while it is still in the process of syncing up with other peers, then would it provide me data or no data or stale data...?
@javrevasandeep All peers are always trailing the latest block that has been cut, it makes no difference if it is trailing by milliseconds (the normal scenario) or minutes or days. The peer will respond with data at its current block height. There are two things that ensure data integrity across block heights:
1) multiple peers must return the same endorsement results... if there is one peer's response that deviates from the others (potentially due to it being further behind), then this response can be thrown out and you can get an endorsement from another peer to meet the endorsement policy.
2) If you do get enough matching responses to meet endorsement policy and submit the transaction, but there is another conflicting transactions that reads/writes the same keys, then your transaction will get invalidated at validation/commit time on each peer. This is why it is important for clients to listen for transaction events and ensure the transaction was committed.
Note that when using service discovery, SDKs will prioritize peers at higher block heights to avoid any issues with a peer that is lagging behind.
Has joined the channel.
Hello,
I am frequently getting following error:
https://stackoverflow.com/questions/53445400/hyperledger-fabric-error-14-unavailable-tcp-write-failed
Can anyone help please?
@dave.enyeart I have a multiple chaincode owner and I have signed it by all organization respectively (I have hand over this to the next org and again repeat the same thing and hand over the result to next org until I have received all signature in the signedccpack.out) what I have to do next, install the chaincode on all peers on on all organization? but how can I use signed package in installation or instantiate the chaincode
`peer chaincode package -n slc_s6 -p github.com/chaincode/slc_6/go/ -v 1 -s -S -i "AND('org1MSP.member', 'org2MSP.member', 'org3MSP.peer', 'org4MSP.peer', 'org5MSP.peer')" ccpack.out`
`peer chaincode signpackage ccpack.out signedccpack.out` ```
```
@dave.enyeart I have a multiple chaincode owner and I have signed it by all organization respectively (I have hand over this to the next org and again repeat the same thing and hand over the result to next org until I have received all signature in the signedccpack.out) what I have to do next, install the chaincode on all peers on on all organization? but how can I use signed package in installation or instantiate the chaincode
`peer chaincode package -n slc_s6 -p github.com/chaincode/slc_6/go/ -v 1 -s -S -i "AND('org1MSP.admin', 'org2MSP.admin', 'org3MSP.admin', 'org4MSP.admin', 'org5MSP.admin')" ccpack.out`
`peer chaincode signpackage ccpack.out signedccpack.out` ```
```
@dave.enyeart I have a multiple chaincode owner and I have signed it by all organization respectively (I have hand over this to the next org and again repeat the same thing and hand over the result to next org until I have received all signature in the signedccpack.out) what I have to do next, install the chaincode on all peers on on all organization? but how can I use signed package in installation or instantiate the chaincode
`peer chaincode package -n slc_s6 -p github.com/chaincode/slc_6/go/ -v 1 -s -S -i "AND('org1MSP.admin', 'org2MSP.admin', 'org3MSP.admin', 'org4MSP.admin', 'org5MSP.admin')" ccpack.out`
`peer chaincode signpackage ccpack.out signedccpack.out` ```
```
@dave.enyeart I have a multiple chaincode owner and I have signed it by all organization respectively (I have hand over this to the next org and again repeat the same thing and hand over the result to next org until I have received all signature in the signedccpack.out) what I have to do next, install the chaincode on all peers on on all organization? but how can I use signed package in installation or instantiate the chaincode
`peer chaincode package -n slc_s6 -p github.com/chaincode/slc_6/go/ -v 1 -s -S -i "AND('org1MSP.admin', 'org2MSP.admin', 'org3MSP.admin', 'org4MSP.admin', 'org5MSP.admin')" ccpack.out`
`peer chaincode signpackage ccpack.out signedccpack.out` ```
```
@dave.enyeart I have a multiple chaincode owner and I have signed it by all organization respectively (I have hand over this to the next org and again repeat the same thing and hand over the result to next org until I have received all signature in the signedccpack.out) what I have to do next, install the chaincode on all peers on on all organization? but how can I use signed package in installation or instantiate the chaincode
`peer chaincode package -n slc_s6 -p github.com/chaincode/slc_6/go/ -v 1 -s -S -i "AND('org1MSP.admin', 'org2MSP.admin', 'org3MSP.admin', 'org4MSP.admin', 'org5MSP.admin')" ccpack.out`
`peer chaincode signpackage ccpack.out signedccpack.out` ```
``` I have checked that the time that I instantiate I have used the admin user ```
peer chaincode instantiate -o orderer0.abcd.org:7050 --tls --cafile $ORDERER_CA -C abcdchannel -n slc_s6 -v 1.0 -c '{"Args":["init"]}' -P "AND('org1MSP.peer', 'org2MSP.peer', 'org3MSP.peer', 'org4MSP.peer', 'org52MSP.peer')" --collections-config $GOPATH/src/github.com/chaincode/slc_6/collections_config.json
```
@dave.enyeart I have a multiple chaincode owner and I have signed it by all organization respectively (I have hand over this to the next org and again repeat the same thing and hand over the result to next org until I have received all signature in the signedccpack.out) what I have to do next, install the chaincode on all peers on on all organization? but how can I use signed package in installation or instantiate the chaincode
`peer chaincode package -n slc_s6 -p github.com/chaincode/slc_6/go/ -v 1 -s -S -i "AND('org1MSP.admin', 'org2MSP.admin', 'org3MSP.admin', 'org4MSP.admin', 'org5MSP.admin')" ccpack.out`
`peer chaincode signpackage ccpack.out signedccpack.out` ```
``` I have checked that the time that I instantiate I have used the admin user ```
peer chaincode instantiate -o orderer0.abcd.org:7050 --tls --cafile $ORDERER_CA -C abcdchannel -n slc_s6 -v 1.0 -c '{"Args":["init"]}' -P "AND('org1MSP.peer', 'org2MSP.peer', 'org3MSP.peer', 'org4MSP.peer', 'org52MSP.peer')" --collections-config $GOPATH/src/github.com/chaincode/slc_6/collections_config.json
```
I have a multiple chaincode owner and I have signed it by all organization respectively (I have hand over this to the next org and again repeat the same thing and hand over the result to next org until I have received all signature in the signedccpack.out) what I have to do next, install the chaincode on all peers on on all organization? but how can I use signed package in installation or instantiate the chaincode
`peer chaincode package -n slc_s6 -p github.com/chaincode/slc_6/go/ -v 1 -s -S -i "AND('org1MSP.admin', 'org2MSP.admin', 'org3MSP.admin', 'org4MSP.admin', 'org5MSP.admin')" ccpack.out`
`peer chaincode signpackage ccpack.out signedccpack.out` ```
``` I have checked that the time that I instantiate I have used the admin user ```
peer chaincode instantiate -o orderer0.abcd.org:7050 --tls --cafile $ORDERER_CA -C abcdchannel -n slc_s6 -v 1.0 -c '{"Args":["init"]}' -P "AND('org1MSP.peer', 'org2MSP.peer', 'org3MSP.peer', 'org4MSP.peer', 'org52MSP.peer')" --collections-config $GOPATH/src/github.com/chaincode/slc_6/collections_config.json
```
Clipboard - March 12, 2019 10:28 AM
Clipboard - March 12, 2019 10:28 AM
@dave.enyeart this is the orderer log as well
this is the orderer log as well
Clipboard - March 12, 2019 10:30 AM
Has joined the channel.
In case I want to purge / archive the blockchain data because of size issues?
Can I do that?
If so then what can be standard / best practices?
Thanks.
hi team am querying this ledger and getting the below error ... can anybody help me out
Error: transaction returned with failure: Error: Illegal value for keyvalue element of type string: undefined (not a string)
@mallikarjunasai995 I don't see that error in Fabric code base
@npc0405 For state database data you can delete from chaincode. If you are talking about archiving the historical blockchain, there is a feature on the roadmap to support checkpoint and archive which would allow peers to consent on global state such that prior blocks could be archived away
Thanks @dave.enyeart !!!
@dave.enyeart when can we expect this? in release 2.0?
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=6f7kskvboR2A2krav) @dave.enyeart is there any article expalained in simple/layman terms on how to write chaincode and what are the packages that are available to write it . if so can you please post the link here ...
@mallikarjunasai995 For developing chaincode, a simple tutorial is https://hyperledger-fabric.readthedocs.io/en/latest/write_first_app.html. For a deeper view, see https://hyperledger-fabric.readthedocs.io/en/latest/developapps/developing_applications.html
@npc0405 Checkpoint and archive is not planned for v2.0, but we do expect it by end of year.
Thanks @dave.enyeart
While pushing bulk of records in blockchain in the form of chunks, some of records gets added and few of them missed without any error.
any idea?
Look in peer log for any invalidations. You can also see the keys that get committed to state database if you enable debug like this: FABRIC_LOGGING_SPEC=info:couchdb,stateleveldb=debug`
Look in peer log for any invalidations. You can also see the keys that get committed to state database if you enable debug like this: `FABRIC_LOGGING_SPEC=info:couchdb,stateleveldb=debug`
Has joined the channel.
Has joined the channel.
Hello,
When I use identityService.getOne() I got following response for attribute.
```
[ { name: 'userType', value: 'supplier' },
{ name: 'hf.EnrollmentID', value: '11', ecert: true },
{ name: 'hf.Type', value: 'client', ecert: true },
{ name: 'hf.Affiliation',
value: 'org1.department1',
ecert: true },
{ name: 'hf.Registrar.Roles', value: '*' },
{ name: 'hf.Registrar.Attributes', value: '*' } ]
```
But when I getAttribute value for `userType` it gives different value.
I have updated identity once using identity.update().
Hello,
When I use identityService.getOne() I got following response for attribute.
```
[ { name: 'userType', value: 'supplier' },
{ name: 'hf.EnrollmentID', value: '11', ecert: true },
{ name: 'hf.Type', value: 'client', ecert: true },
{ name: 'hf.Affiliation',
value: 'org1.department1',
ecert: true },
{ name: 'hf.Registrar.Roles', value: '*' },
{ name: 'hf.Registrar.Attributes', value: '*' } ]
```
But when I getAttribute value for `userType` in chaincode it gives different value.
I have updated identity once using identity.update().
Has joined the channel.
Has joined the channel.
Hi all. if I have a blockchain network up and running and something happens to my CA and lose my CA certificates, will I be able to have access to my ledger or because I will change certs it will be impossible? What should I do in a situation like that?
hi experts here, I know system chaincodes can query ledger to get CA certificate. Now I want to use CA certificate in my application chaincode, how should I do? Thank you very much.
If you are using the `fabric-contract-api` the `ClientIdentity` object is available to you via the stub in your chaincode and it includes the certificate.
https://fabric-shim.github.io/release-1.4/fabric-shim.ClientIdentity.html
the answer was given by Rthatcher in chaincode-dev channel. Thanks
However, I find the most related function getX509Certificate return the x509 certifcate of the revoking identity, not the root ca certificate.
how to verify that world state hasn't been changed by a process other than chaincode? I mean database can be hacked, if the consistent state of a record is only checked when blockchain transaction is processed, then we have an issue here, correct? because most of uses cases are some kind of trace and track, written records will never be input of another transaction again.
@mwenyan See https://lists.hyperledger.org/g/fabric/message/4896
experts on ledger, if possible， wouldst you please tell me how to obtain the CA
experts on ledger, Wouldst you please tell me how to obtain an org's root certificate. I know if it is possible because system chaincodes need root certificate to verify the correctness of certificates
experts on ledger, Would you please tell me how to obtain an org's root certificate in application chaincde? I know if it is possible because system chaincodes need root certificate to verify the correctness of certificates
@manish-sethi , it looks like at some point someone introduced this notion of state listeners in kvledger; now the txmgr invokes such state listener as part of the ValidateAndPrepare. The strange thing I notice is that in the invokeNamespaceListeners() function you create two query executors which bypass the read lock creation which is included in the creation of the usual query executors (created by NewQueryExecutor()). That seem to imply that the state listeners may perform read operations against the stateDB without any lock acquisition - which means they could access dirty reads; or am I missing something?
@minollo - you can blame me instead of "someone" :-). Since, this is in the commit path (we have a single writer/channel per channel) so locking is not needed in this path.
ok; then the assumption is that the lifecycle of that information (the query executor) terminates at the end of the HandleStateUpdates() call execution?
because the way things work today, the listeners holds on to that information; and in theory it can reuse it at any point later and asynchronously, if they want
Yes, the listeners are not supposed to keep hold of this beyond this scope else, they would be blocking the commit.
ok; you may want to reconsider your unit test then, as it does exactly that
Sure, can you please open a jira to keep track of this
will do; in the meanwhile you answered my question about the scope of these query executors, and that greatly helps my work in translating that approach in one which deals with db transactions; thanks!
Looking at raft for consensus (introduced in 1.4.1). Can a node be a leader for more than one channel? thanks.
[ ](https://chat.hyperledger.org/channel/fabric-ledger?msg=kPiAqCDjBnKMQSENu) @mbanerjee In raft every channel have different raft cluster so if same node is present in both channel raft cluster then it can have
Has joined the channel.
Hi,
*I am able to fetch the Private data in the initial setup 2Orgs 2 peers. However in the newly added peer i am unable to fetch the reconciled private data.*
I will eloborate my work in Private Data Reconciliation. Please suggest me if i am doing wrong in my process.
I have a blockchain network with 2 Orgs each with 2 Peers along with 1 Orderer.
I have a channel for 2 Orgs. I tried like below..
- Initially the Org1Peer0 and Org2Peer0 have joined the Channel. After that, installed, instantiated, Invoked and Queried Private Data. Its working fine.
- Later, the new peer Org1Peer1 joined to the channel. And also configured with the below options in the .bashrc file for Org1Peer0. But not added the below options in Peer0's of 2 Orgs.
- export CORE_PEER_GOSSIP_PVTDATA_RECONCILIATIONENABLED=true
- export CORE_PEER_GOSSIP_PVTDATA_RECONCILESLEEPINTERVAL=1m
- After that i tried to query the reconciled private data. But i end up with errors.
- To make simplify the process, i take only 1 Org with 2 peers to test the Privated Data Reconciliation.
- I stopped Org1 Peer1 but Org1 Peer0 is already in running mode. I added the Reconciliation options in both the peers in a .bashrc file.
- I installed new chaincode in Org1Peer0 and then instantiated, invoked couple of private data and then queryied the data. The private data is returning properly.
- Now i started Org1Peer1 and installed the new chaincode in this node. Then i tried querying the reconciled data. But i end up with the same errors provided you earlier.
Below is the collection config which i used for the 1 Org scenario.
[
{
"name": "collectionPurchaseOrders",
"policy": "OR('Org1MSP.member')",
"requiredPeerCount": 0,
"maxPeerCount": 3,
"blockToLive":1000000,
"memberOnlyRead": true
},
{
"name": "collectionPrivatePurchaseOrders",
"policy": "OR('Org1MSP.member')",
"requiredPeerCount": 0,
"maxPeerCount": 3,
"blockToLive":0,
"memberOnlyRead": true
}
]
Can you please suggest me if i have anything wrong in the above steps or configurations?
No Errors in Org1Peer0 while invoking. But, below is the error in Org1Peer1 while invoking the Private Data in Org1Peer0.
Error in Org1Peer1 while Invoking in Org1Peer0
---------------------------------------------
2019-04-25 09:55:38.088 UTC [gossip.privdata] reconcile -> ERRO 191f reconciliation error when trying to fetch missing items from different peers: Empty membership
2019-04-25 09:55:38.088 UTC [gossip.privdata] run -> ERRO 1920 Failed to reconcile missing private info, error: Empty membership
2019-04-25 09:55:38.536 UTC [gossip.privdata] fetchPrivateData -> WARN 1921 Do not know any peer in the channel( channeltest2 ) that matches the policies , aborting
2019-04-25 09:55:38.536 UTC [gossip.privdata] fetchFromPeers -> WARN 1922 Failed fetching private data for block 24 from peers: Empty membership
2019-04-25 09:55:39.537 UTC [gossip.privdata] fetchPrivateData -> WARN 1923 Do not know any peer in the channel( channeltest2 ) that matches the policies , aborting
2019-04-25 09:55:39.537 UTC [gossip.privdata] fetchFromPeers -> WARN 1924 Failed fetching private data for block 24 from peers: Empty membership
2019-04-25 09:55:40.537 UTC [gossip.privdata] StoreBlock -> WARN 1925 [channeltest2] Could not fetch all missing collection private write sets from remote peers. Will commit block [24] with missing private write sets:[txID: 03ece15b2ef5dcaa952cdf663a60292426e82aa838a0304d73b6cd1659711fb1, seq: 0, namespace: xyzchaincode, collection: collectionPrivatePurchaseOrders, hash: 34f6ade8fa9fa825797941777f170262a95bfaf217572660a2434677b31b97f8
txID: 03ece15b2ef5dcaa952cdf663a60292426e82aa838a0304d73b6cd1659711fb1, seq: 0, namespace: xyzchaincode, collection: collectionPurchaseOrders, hash: 50fe70b55805b8281669b7ddd9aa8ac78c02a42b6693cc2a96f0f601613253de
]
2019-04-25 09:55:40.553 UTC [kvledger] CommitWithPvtData -> INFO 1926 [channeltest2] Committed block [24] with 1 transaction(s) in 15ms (state_validation=0ms block_commit=9ms state_commit=3ms)
Error in Org1Peer1 while querying in the same peer:
-----------------------------------------------------
2019-04-25 09:59:02.150 UTC [endorser] callChaincode -> INFO 1933 [channeltest2][651413f6] Entry chaincode: name:"xyzchaincode"
2019-04-25 09:59:02.152 UTC [chaincode] HandleTransaction -> ERRO 1934 [651413f6] Failed to handle GET_STATE. error: private data matching public hash version is not available. Public hash version = &version.Height{BlockNum:0x18, TxNum:0x0}, Private data version = (*version.Height)(nil)
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleGetState
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:640
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleGetState-fm
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:214
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:272
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
GET_STATE failed: transaction ID: 651413f6371f594722a6c0b8ee46793e9232b32acac463939b356896d3211624
github.com/hyperledger/fabric/core/chaincode.(*Handler).HandleTransaction
/opt/gopath/src/github.com/hyperledger/fabric/core/chaincode/handler.go:276
runtime.goexit
/opt/go/src/runtime/asm_amd64.s:1333
2019-04-25 09:59:02.152 UTC [endorser] callChaincode -> INFO 1935 [channeltest2][651413f6] Exit chaincode: name:"xyzchaincode" (2ms)
2019-04-25 09:59:02.152 UTC [endorser] ProcessProposal -> ERRO 1936 [channeltest2][651413f6] simulateProposal() resulted in chaincode name:"xyzchaincode" response status 500 for txid: 651413f6371f594722a6c0b8ee46793e9232b32acac463939b356896d3211624
Please help me in this. Thank you.
Has joined the channel.
The errors above are almost always a result of gossip misconfiguration (anchor peers and/or endpoints)
Has joined the channel.
before initializing a chaincode, a docker image will be created and then a container instance. my questions are:
1) is it recommended to reuse the docker image for future endorsing peers?
2) does the docker image relate with crypto artifacts?
Has joined the channel.
Hi, i have question regarding 'sharing'(ability to read&update) of document(asset) that reside in private data collection(explicit collection) to member of Org that is not part of collection yet.
For example: private data collection=PDC1, members: OrgA and OrgB. Organization that should be able to read&update assets from PDC1 is OrgC.
I guess one way to achieve this is with 'explicit' collections like this:
1. Modify collection config: add OrgC in distribution policy. That operation trigger chaincode upgrade
2. If there is requirement for fine grain permission access in the future for specific asset(key) use key-level endorsement policy
Does this explanation make sense? Any other mechanism how to achieve this functionality (for ex with implicit collections or somethis else?)
Hi, i have question regarding 'sharing'(ability to read&update) of document(asset) that reside in private data collection(explicit collection) to member of Org that is not part of collection yet.
For example: private data collection=PDC1, members: OrgA and OrgB. Organization that should be able to read&update assets from PDC1 is OrgC.
I guess one way to achieve this is with 'explicit' collections like this:
1. Modify collection config: add OrgC in distribution policy. That operation trigger chaincode upgrade
2. If there is requirement for fine grain permission access in the future for specific asset(key) use key-level endorsement policy
Does this explanation make sense? Any other mechanism how to achieve this functionality (for ex with implicit collections or something else?)
Hello! Does Couchdb support "composite keys" and queries with prefixes of keys as Goleveldb supports? I mean, is it efficient to use partial key queries with CouchDB as a state database?
Also, could somebody provide a link to learn how these composite keys search works in Leveldb under the hood?
Has joined the channel.
yes ,, check this https://medium.com/wearetheledger/hyperledger-fabric-couchdb-fantastic-queries-and-where-to-find-them-f8a3aecef767
@krabradosty Yes, CouchDB supports range queries and composite key queries efficiently by using an internal index. For both CouchDB and LevelDB, the composite key query is actually turned into a simple range query in the shim, and then sent to CouchDB or LevelDB as a simple range query. For details see the shim code here: https://github.com/hyperledger/fabric/blob/release-1.4/core/chaincode/shim/chaincode.go#L778-L780
answered in mailing list: https://lists.hyperledger.org/g/fabric/message/6147
thanks
Has left the channel.
Has joined the channel.
Hi Team,
I am facing one strange issue with chaincode. I have one function in smart contract which gets asset record value from ledger based on asset key and based on the result, it create the asset record if it is not there and doesn't create the record if its already there and we have sub asset records for every asset record. The asset record data is coming from legacy systems one by one to blockchain ledger through invokation. What i found is that sometimes subsequent sub asset record is not getting stored for the asset record for which there is already at least one sub asset record for the same asset record stored on ledger in previous invokation request.
Hi Guys,
I am getting the below error while installing the chaincode in the multinode network.
Earlier it was working fine with the other chaincodes. Suddenly it stopped installing the chaincode and getting the below error.
Your help will be greatly appreciated.
Error: error getting chaincode code marblesp: error getting chaincode package bytes: Error obtaining imports: command
Has joined the channel.
Hi Team, Need clarification about Raft consensus algorithm. Since the genesis block is generated at network startup time if a new Raft orderer node is added as a consenter, how do we update the sys channel and the application channel?
Each new raft node will first receive all prior blocks starting with genesis block. For further questions about ordering nodes, please post to #fabric-orderer
Has joined the channel.
Has joined the channel.
Hi Can we integrate oracle db instead of couch db in hyperledger fabric?
what is beinfit?
Has joined the channel.
You can't ... Fabric does not support SQL databases to store ledger state. It only supports the embedded goleveldb and CouchDB
Has joined the channel.
checking https://console.aws.amazon.com/qldb/home?region=us-east-1#firstRun and yes, it works with SQL 'out-of-the-box' in a bucket of all places
Hi,
I am using fabric 1.3 and it is taking too much time for even querying ledger. I have two organanizations. Total 2 peers and 3 orderers. Is there anything to track why it is taking so long and the ways to resolve this?
@HoneyShah need to provide logs
Hello, can any maintainer look into the issue I opened in Jira https://jira.hyperledger.org/browse/FAB-15865 and give your comments? Thanks
Well the Oracle Blockchain Platform sort of does this. We replicate the transactions and state database into an Oracle DB if so configured, and we provide a SQL query interface to the state database based on BerkeleyDB and SQLite. But native Fabric doesn't support relational databases or SQL queries.
Hello. I had a question on indexing using couchDB. So i have a smart contract that has both public struct and a private struct that is used when a commit is done to the private database. (using a collections file). I have a filed called recordId in both the structs. Now i have added an index for querying faster and efficiently and i have used this recordId as a field for creating the index.
The question is - Will indexing work on both public ledger and private DB with this same index file? If not, what is the way to do indexing for private database?
Yes you can create the same index for private data collections. See the documentation and sample here: https://hyperledger-fabric.readthedocs.io/en/release-1.4/private-data-arch.html#using-indexes-with-collections
Thanks @dave.enyeart
hi experts, can a chaincode access the key in the world state which is created by one another chaincode? here the two chaincodes are in the same channel. Thank you
hi experts, can a chaincode read(or query) the key in the world state which is created by another chaincode? here the two chaincodes are in the same channel. Thank you
No directly, but you can achieve it by having one chaincode call the other chaincode. See https://github.com/hyperledger/fabric/blob/release-1.4/core/chaincode/shim/interfaces.go#L62-L76
Not directly, but you can achieve it by having one chaincode call the other chaincode. See https://github.com/hyperledger/fabric/blob/release-1.4/core/chaincode/shim/interfaces.go#L62-L76
Thank you. But this conflict our usual impression that members in one channel share the ledger. chaincode calling chaincode should work even they are not in the same channel.
Thank you. But this conflict with our usual impression that members in one channel share the ledger. chaincode calling chaincode should work even they are not in the same channel.
though eventing or did you fork it?
Has joined the channel.
getHistoryForKey can get the history transaction for the input key. My question is whether I can get the history transaction for the key if the key is deleted from the world state just now? Thank you
getHistoryForKey can get the history transaction for the input key. Can we get the history transaction for the key if the key is deleted from the world state? Thank you
Hello @dave.enyeart, we are running a Fabric peer v1.4.2 with Couch DB 2.3.1, and we have started receiving the below error
```
2019-08-09 18:32:43.786 CEST [couchdb] handleRequest -> DEBU 065 HTTP Request: PUT /_users/_security HTTP/1.1 | Host: couchdb01clsbgb6c.cit.clsnet:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 84 | Accept: application/json | Authorization: Basic Y2xzbmV0OmNvdWNoc2VjcmV0Y2l0MjE= | Content-Type: application/json | Accept-Encoding: gzip | |
2019-08-09 18:32:43.787 CEST [couchdb] handleRequest -> WARN 066 Retrying couchdb request in 1s. Attempt:4 Error:Put http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security: read tcp 172.16.210.210:59378->172.16.210.106:5984: read: connection reset by peer
2019-08-09 18:32:44.787 CEST [couchdb] CreateSystemDatabasesIfNotExist -> ERRO 067 Error calling CouchDB CreateDatabaseIfNotExist() for system dbName: _users, error: Put http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security: read tcp 172.16.210.210:59378->172.16.210.106:5984: read: connection reset by peer
2019-08-09 18:32:44.787 CEST [couchdb] VerifyCouchConfig -> ERRO 068 Unable to connect to CouchDB, error: Put http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security: read tcp 172.16.210.210:59378->172.16.210.106:5984: read: connection reset by peer. Check the admin username and password.
2019-08-09 18:32:44.788 CEST [couchdb] VerifyCouchConfig -> DEBU 069 Exiting VerifyCouchConfig()
panic: Error initializing ledger provider: unable to connect to CouchDB. Check the admin username and password: Put http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security: read tcp 172.16.210.210:59378->172.16.210.106:5984: read: connection reset by peer
goroutine 1 [running]:
github.com/hyperledger/fabric/core/ledger/ledgermgmt.initialize(0xc0004d9d10)
/go/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:81 +0x783
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize.func1()
/go/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:53 +0x2a
sync.(*Once).Do(0x232c8a8, 0xc000263410)
/usr/local/go/src/sync/once.go:44 +0xb3
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize(0xc0004d9d10)
/go/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:52 +0x55
github.com/hyperledger/fabric/peer/node.serve(0x232c7d0, 0x0, 0x0, 0x0, 0x0)
/go/src/github.com/hyperledger/fabric/peer/node/start.go:180 +0x5bd
github.com/hyperledger/fabric/peer/node.glob..func3(0x2222400, 0x232c7d0, 0x0, 0x0, 0x0, 0x0)
/go/src/github.com/hyperledger/fabric/peer/node/start.go:125 +0x9c
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x2222400, 0x232c7d0, 0x0, 0x0, 0x2222400, 0x232c7d0)
/go/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:762 +0x473
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x2222b20, 0x8, 0x0, 0x2221820)
/go/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:852 +0x2fd
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x2222b20, 0xc000263f40, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:800 +0x2b
main.main()
/go/src/github.com/hyperledger/fabric/peer/main.go:53 +0x2f7
```
Hello @dave.enyeart @jyellick , we are running a Fabric peer v1.4.2 with Couch DB 2.3.1, and we have started receiving the below error
```
2019-08-09 18:32:43.786 CEST [couchdb] handleRequest -> DEBU 065 HTTP Request: PUT /_users/_security HTTP/1.1 | Host: couchdb01clsbgb6c.cit.clsnet:5984 | User-Agent: Go-http-client/1.1 | Content-Length: 84 | Accept: application/json | Authorization: Basic Y2xzbmV0OmNvdWNoc2VjcmV0Y2l0MjE= | Content-Type: application/json | Accept-Encoding: gzip | |
2019-08-09 18:32:43.787 CEST [couchdb] handleRequest -> WARN 066 Retrying couchdb request in 1s. Attempt:4 Error:Put http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security: read tcp 172.16.210.210:59378->172.16.210.106:5984: read: connection reset by peer
2019-08-09 18:32:44.787 CEST [couchdb] CreateSystemDatabasesIfNotExist -> ERRO 067 Error calling CouchDB CreateDatabaseIfNotExist() for system dbName: _users, error: Put http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security: read tcp 172.16.210.210:59378->172.16.210.106:5984: read: connection reset by peer
2019-08-09 18:32:44.787 CEST [couchdb] VerifyCouchConfig -> ERRO 068 Unable to connect to CouchDB, error: Put http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security: read tcp 172.16.210.210:59378->172.16.210.106:5984: read: connection reset by peer. Check the admin username and password.
2019-08-09 18:32:44.788 CEST [couchdb] VerifyCouchConfig -> DEBU 069 Exiting VerifyCouchConfig()
panic: Error initializing ledger provider: unable to connect to CouchDB. Check the admin username and password: Put http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security: read tcp 172.16.210.210:59378->172.16.210.106:5984: read: connection reset by peer
goroutine 1 [running]:
github.com/hyperledger/fabric/core/ledger/ledgermgmt.initialize(0xc0004d9d10)
/go/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:81 +0x783
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize.func1()
/go/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:53 +0x2a
sync.(*Once).Do(0x232c8a8, 0xc000263410)
/usr/local/go/src/sync/once.go:44 +0xb3
github.com/hyperledger/fabric/core/ledger/ledgermgmt.Initialize(0xc0004d9d10)
/go/src/github.com/hyperledger/fabric/core/ledger/ledgermgmt/ledger_mgmt.go:52 +0x55
github.com/hyperledger/fabric/peer/node.serve(0x232c7d0, 0x0, 0x0, 0x0, 0x0)
/go/src/github.com/hyperledger/fabric/peer/node/start.go:180 +0x5bd
github.com/hyperledger/fabric/peer/node.glob..func3(0x2222400, 0x232c7d0, 0x0, 0x0, 0x0, 0x0)
/go/src/github.com/hyperledger/fabric/peer/node/start.go:125 +0x9c
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).execute(0x2222400, 0x232c7d0, 0x0, 0x0, 0x2222400, 0x232c7d0)
/go/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:762 +0x473
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0x2222b20, 0x8, 0x0, 0x2221820)
/go/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:852 +0x2fd
github.com/hyperledger/fabric/vendor/github.com/spf13/cobra.(*Command).Execute(0x2222b20, 0xc000263f40, 0x1)
/go/src/github.com/hyperledger/fabric/vendor/github.com/spf13/cobra/command.go:800 +0x2b
main.main()
/go/src/github.com/hyperledger/fabric/peer/main.go:53 +0x2f7
```
`curl -X GET -u clsnet:couchsecretcit21 http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security` works. Y2xzbmV0OmNvdWNoc2VjcmV0Y2l0MjE= does match to the credential.
But a PUT gives me a similar error
```
bash-4.4$ curl -X PUT -u clsnet:couchsecretcit21 http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security -d '{"admins":{"names":["clsnet"],"roles":[]},"members":{"names":["clsnet"],"roles":[]}}'
curl: (56) Recv failure: Connection reset by peer
```
I can do PUT on other channel specific database.
yes, getHistoryForKey will provide the full history of the key, including indication of which transaction it was deleted in
That PUT works for me against a CouchDB 2.3.1 environment. Got anything in your couchdb log?
I changed the couch database log to debug, but it does not print anything out there.
Security object is already present, it got created when it was working
```
bash-4.4$ curl -X GET -u clsnet:couchsecretcit21 http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security
{"admins":{"names":["clsnet"],"roles":[]},"members":{"names":["clsnet"],"roles":[]}}
```
Now curl fails
```
bash-4.4$ curl -X PUT -u clsnet:couchsecretcit21 http://couchdb01clsbgb6c.cit.clsnet:5984/_users/_security -d '{"admins":{"names":["clsnet"],"roles":[]},"members":{"names":["clsnet", "clsnet1"],"roles":[]}}'
curl: (56) Recv failure: Connection reset by peer
```
I see. Thank you.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Hello,
I am seeing the below error in orderer logs
any idea why I might be getting this error?
2019-08-28 05:55:14.477 CEST [orderer.consensus.kafka] enqueue -> ERRO 73b [channel: cls2obo-cls5obo] cannot enqueue envelope because = read tcp 172.16.212.20:45696->172.16.212.13:9092: i/o timeout
2019-08-28 05:55:14.477 CEST [orderer.common.broadcast] ProcessMessage -> WARN 73c [channel: cls2obo-cls5obo] Rejecting broadcast of normal message from 10.2.33.76:42658 with SERVICE_UNAVAILABLE: rejected by Order: cannot enqueue
We forked it...
Not sure if this should be here or in peer-endorser but here goes.
Just upgraded to 1.4 and there appears to be a change in behavior.
It makes sense but I'm not sure if it is new functionality or a bug we introduced somewhere because I don't see how it ever worked.
Consider a network with two channels - C1 and C2 and three Orgs A,B,C
C1 is comprised of A and B and holds a parent asset with an identifier.
C2 is comprised of B and C and holds an asset that needs to check if the parent asset is present.
Endorsing policy is
Not sure if this should be here or in peer-endorser but here goes.
Just upgraded to 1.4 and there appears to be a change in behavior.
It makes sense but I'm not sure if it is new functionality or a bug we introduced somewhere because I don't see how it ever worked.
Consider a network with two channels - C1 and C2 and three Orgs A,B,C
C1 is comprised of A and B and holds a parent asset with an identifier.
C2 is comprised of B and C and holds an asset that needs to check if the parent asset is present.
C2 chaincode does a cross channel read to C1 to check for the presence of parent asset.
It was working for both orgs - B and C - and I have proof in assets already on C2.
Not sure if this should be here or in peer-endorser but here goes.
Just upgraded to 1.4 and there appears to be a change in behavior.
It makes sense but I'm not sure if it is new functionality or a bug we introduced somewhere because I don't see how it ever worked.
Consider a network with two channels - C1 and C2 and three Orgs A,B,C
C1 is comprised of A and B and holds a parent asset with an identifier.
C2 is comprised of B and C and holds an asset that needs to check if the parent asset is present.
C2 endorsement policy code required both B and C to endorse.
C2 chaincode does a cross channel read to C1 to check for the presence of parent asset.
It was working for both orgs - B and C - and I have proof it worked with the presence of assets already on C2.
Now it's throwing an (expected now I look at it) failure in the C peers (remember C has no visibility to C1).
Did this get tightened up between 1.2 and 1.4 or is there something else going on here.
Not sure if this should be here or in peer-endorser but here goes.
Just upgraded to 1.4 and there appears to be a change in behavior.
It makes sense but I'm not sure if it is new functionality or a bug we introduced somewhere because I don't see how it ever worked.
Consider a network with two channels - C1 and C2 and three Orgs A,B,C
C1 is comprised of A and B and holds a parent asset with an identifier.
C2 is comprised of B and C and holds an asset that needs to check if the parent asset is present.
C2 endorsement policy code required both B and C to endorse.
C wants to add an asset to C2. It needs to check if the parent asset is present on C1.
C2 chaincode does a cross channel read to C1 to check for the presence of parent asset.
It was working for both orgs - B and C - and I have proof it worked with the presence of assets already on C2.
Now it's throwing an (expected now I look at it) failure in the C peers (remember C has no visibility to C1).
Did this get tightened up between 1.2 and 1.4 or is there something else going on here.
Not sure if this should be here or in peer-endorser but here goes.
Just upgraded to 1.4 and there appears to be a change in behavior.
It makes sense but I'm not sure if it is new functionality or a bug fix because I don't see how it ever worked.
Consider a network with two channels - C1 and C2 and three Orgs A,B,C
C1 is comprised of A and B and holds a parent asset with an identifier.
C2 is comprised of B and C and holds an asset that needs to check if the parent asset is present.
C2 endorsement policy code required both B and C to endorse.
C wants to add an asset to C2. It needs to check if the parent asset is present on C1.
C2 chaincode does a cross channel read to C1 to check for the presence of parent asset.
It was working for both orgs - B and C - and I have proof it worked with the presence of assets already on C2.
Now it's throwing an (expected now I look at it) failure in the C peers (remember C has no visibility to C1).
Did this get tightened up between 1.2 and 1.4 or is there something else going on here.
Any tutorials on hyperledger fabric on kubernetes? TIA.
try #fabric-kubernetes
Hi,
I have a HLF Network with 4 Orgs and each org has 2 peers in VM based environment.
Now, I have a business requirement that i need to add one more peer (3rd peer) for Org4. But it should be in a docker container in a separate windows machine.
I have done the setup with HLF in the docker container using docker-compose.yaml file.
But, when i try to install the chaincode in the docker container using Peer CLI, i am getting the below exception. By the way, i am using bccsp package in my chaincode.
Error: error getting chaincode code rcodso: error getting chaincode package bytes: Error obtaining dependencies for github.com/hyperledger/fabric/bccsp: command
`/fabric/bccsp` does exist, see https://github.com/hyperledger/fabric/tree/release-1.4/bccsp
`/fabric/bccsp` does exist, see https://github.com/hyperledger/fabric/tree/release-1.4/bccsp
why does your chaincode need internal fabric bccsp?
Hi Dave, We are using bccsp in our chaincodes for encrypting few of the confidential fields.
Hello @dave.enyeart, we are using Fabric v1.4.2 and we see delay in receiving the Peer endorsement response. Further looking at the Peer logs, the peer shows a freeze during execution of `func (pe *PluginEndorser) EndorseWithPlugin(ctx Context) (*pb.ProposalResponse, error) {`. This is not happening on other peer running on a different VM. Can you please hint use what could be the reason
Hello @dave.enyeart, we are using Fabric v1.4.2 and we see delay in receiving the Peer endorsement response. Further looking at the Peer logs, the peer shows a freeze during execution of `func (pe *PluginEndorser) EndorseWithPlugin(ctx Context) (*pb.ProposalResponse, error) {`. This is not happening on other peer running on a different VM. Can you please hint, what could be the reason.
@jyellick if you check.
@jyellick if you can check.
@rahulhegde EndorseWithPlugin is the step which actually computes the signature for the endorsement. My guess would be some different in entropy, crypto hardware, etc. which is causes the signature to stall on the one VM.
@rahulhegde EndorseWithPlugin is the step which actually computes the signature for the endorsement. My guess would be some difference in entropy, crypto hardware, etc. which is causes the signature to stall on the one VM.
@rahulhegde EndorseWithPlugin is the step which actually computes the signature for the endorsement. My guess would be some difference in entropy, crypto hardware, etc. which is causing the signature to stall on the one VM.
@rahulhegde if you see a freeze you can kill the peer with `kill -SIGABRT` and then get the stack trace
are you using HSM?
Yes - right, we are using HSM. Both the peers are using HSM however from a separate Partition/Label.
then do the trick i mentioned above.... i am betting it's stuck on the HSM somewhere
Let me do this - would we specific call trace.
Let me do this - would we see a specific call stack?
i am not psychic... give me the stack trace and i can look
Okay - was looking if there is some PKCS11 API in the call stack.
@yacovm - i tried killing the peer process inside the peer container and was not able to see any stack trace.
@yacovm - i tried killing the peer process inside the peer container and was not able to see any stack trace. Can you please check - what is incorrectly done here.
```
[rhegde@dusd1devrhap040 e2e_cli_v1_ops_kafka_tls]$ docker ps | grep peer02clsbgb65.cit.clsnet
ae63c46bac53 ibmblockchain/fabric-peer:1.4.2 "/docker-entrypoint.…" 46 hours ago Up 21 minutes 7052/tcp, 0.0.0.0:11051->7051/tcp, 0.0.0.0:11053->7053/tcp peer02clsbgb65.cit.clsnet
[rhegde@dusd1devrhap040 e2e_cli_v1_ops_kafka_tls]$ docker exec -it ae63c46bac53 sh
/opt/gopath/src/github.com/hyperledger/fabric/peer $ ps -ef
PID USER TIME COMMAND
1 10130 0:18 peer node start
23 10130 0:00 sh
28 10130 0:00 ps -ef
/opt/gopath/src/github.com/hyperledger/fabric/peer $ kill -SIGABRT 1
/opt/gopath/src/github.com/hyperledger/fabric/peer $ [rhegde@dusd1devrhap040 e2e_cli_v1_ops_kafka_tls]$
```
```
[rhegde@dusd1devrhap040 e2e_cli_v1_ops_kafka_tls]$ docker ps | grep peer02clsbgb65.cit.clsnet
ae63c46bac53 ibmblockchain/fabric-peer:1.4.2 "/docker-entrypoint.…" 46 hours ago Up 21 minutes 7052/tcp, 0.0.0.0:11051->7051/tcp, 0.0.0.0:11053->7053/tcp peer02clsbgb65.cit.clsnet
[rhegde@dusd1devrhap040 e2e_cli_v1_ops_kafka_tls]$ docker exec -it ae63c46bac53 sh
/opt/gopath/src/github.com/hyperledger/fabric/peer $ ps -ef
PID USER TIME COMMAND
1 10130 0:18 peer node start
23 10130 0:00 sh
28 10130 0:00 ps -ef
/opt/gopath/src/github.com/hyperledger/fabric/peer $ kill -SIGABRT 1
/opt/gopath/src/github.com/hyperledger/fabric/peer $ [rhegde@dusd1devrhap040 e2e_cli_v1_ops_kafka_tls]$
```
```
[rhegde@dusd1devrhap040 e2e_cli_v1_ops_kafka_tls]$ docker ps | grep peer02clsbgb65.cit.clsnet
ae63c46bac53 ibmblockchain/fabric-peer:1.4.2 "/docker-entrypoint.…" 46 hours ago Up 21 minutes 7052/tcp, 0.0.0.0:11051->7051/tcp, 0.0.0.0:11053->7053/tcp peer02clsbgb65.cit.clsnet
[rhegde@dusd1devrhap040 e2e_cli_v1_ops_kafka_tls]$ docker exec -it ae63c46bac53 sh
/opt/gopath/src/github.com/hyperledger/fabric/peer $ ps -ef
PID USER TIME COMMAND
1 10130 0:18 peer node start
23 10130 0:00 sh
28 10130 0:00 ps -ef
/opt/gopath/src/github.com/hyperledger/fabric/peer $ kill -SIGABRT 1
/opt/gopath/src/github.com/hyperledger/fabric/peer $ [rhegde@dusd1devrhap040 e2e_cli_v1_ops_kafka_tls]$
[rhegde@dusd1devrhap040 e2e_cli_v1_ops_kafka_tls]$ docker ps -a | grep peer02clsbgb65.cit.clsnet
ae63c46bac53 ibmblockchain/fabric-peer:1.4.2 "/docker-entrypoint.…" 46 hours ago Exited (2) About a minute ago peer02clsbgb65.cit.clsnet
```
@rahulhegde now do `docker logs ae63c46bac53`
hello @yacovm @jyellick - I want to pass the logs for review. I do see multiple Gossip related operation during the Endorsement Proposal signing operation. Is this also using the HSM and causing the slowness overall. are we incorrectly setting the gossip parameters for our blockchain?
ibmblockchain-fabric-peer-142.log
gossip periodically signs stuff
how many channels do you have?
please don't say " a lot" :joy:
we dont define Anchor Peer and hence we dont use Gossip, Let me get the channel count data in few mins.
we dont define Anchor Peer and hence we should not see Gossip interactions, Let me get the channel count data in few mins.
ibmblockchain-fabric-peer-142-windowscompatible.log
In case if u would like to view in windows notepad.
67 channels on that Peer.
Currently we are running with higher channel count in a pre-production enviornment ~200. This is currently running with Fabric v1.0.6
67 Channel Environment is SIT - System Integration Test environment where we installed Fabric v1.4.2
Not seen slowness on this environment.
Does Gossip use HSM for signing operations?
Does Gossip use HSM for signing operation?
There are 2 peers running on the same VM. One Peer running with 67 channel is seeing this slowness however the other peer which is running with 12 channel does is not showing this slowness.
There are 2 peers running on the same VM. One Peer running with 67 channel is seeing this slowness however the other peer which is running with 12 channel is not showing this slowness.
yeah it does
so when you say slowness.... how slow is it?
https://github.com/hyperledger/fabric/blob/master/sampleconfig/core.yaml#L135
look here at `publishStateInfoInterval: 4s`
you can increase it to a larger value, like `10s`
and see if it is solved
Endorsement Proposal signing operations is between 1sec to 20secs
oh i see
for the same Peer.
yeah that is indeed super slow
Is there a way to disable Gossip?
Even gossip uses the Endorsement signing key which is present in the HSM??
Even gossip uses the Endorsement signing key which is present in the HSM?
we will try what u have asked.
yes
you can just not put any bootstrap peers
and anchor peers
oh, hmmm
actually it won't disable the signing
i think we can maybe make a patch that disables it in the config
Is there way to delay the Gossip Operation say 4s to few mins.
but it will take time util it goes into any release any time soon
so unfortunately every time there is a commit of a block, you sign a message
but i don't understand
doesn't verification also slow you down
since it also goes through HSM
is there a specific log which i can check for commit time.
specifically like Entering endorsement and Exiting.
Block cut by the orderer is ~2secs. so i dont see any delay there. it also uses HSM.
Can you please suggest from below parameter - if this can be also changed.
```
election:
# Longest time peer waits for stable membership during leader election startup (unit: second)
startupGracePeriod: 15s
# Interval gossip membership samples to check its stability (unit: second)
membershipSampleInterval: 1s
# Time passes since last declaration message before peer decides to perform leader election (unit: second)
leaderAliveThreshold: 10s
# Time between peer sends propose message and declares itself as a leader (sends declaration message) (unit: second)
leaderElectionDuration: 5s
```
The environment in the test is isolated environment (not lab/dev) environment, so if we could suggest different combination, I can try this in.
I tried changing CORE_GOSSIP_PUBLISHSTATEINFOINTERVAL=30s in our non-HSM environment or DEV environment, but i do see the below logs continuously. I hope this is not the only parameter to be changed. @yacovm
```
2019-09-12 15:46:48.780 UTC [msp.identity] Sign -> DEBU 128d Sign: digest: 8AE2E4A1221B533CD3F56CB65319054B1DA2513B5D0D729E4D16CD143FFA97C2
2019-09-12 15:46:48.780 UTC [gossip.election] waitForInterrupt -> DEBU 128e 40cb42faca1e036953bc20efe4908c5941a8efe3070a6c2de1c5e4462dab701b : Entering
2019-09-12 15:46:48.829 UTC [gossip.election] waitForInterrupt -> DEBU 128f 40cb42faca1e036953bc20efe4908c5941a8efe3070a6c2de1c5e4462dab701b : Exiting
2019-09-12 15:46:48.830 UTC [gossip.election] IsLeader -> DEBU 1290 40cb42faca1e036953bc20efe4908c5941a8efe3070a6c2de1c5e4462dab701b : Returning true
2019-09-12 15:46:48.830 UTC [msp] GetDefaultSigningIdentity -> DEBU 1291 Obtaining default signing identity
2019-09-12 15:46:48.830 UTC [msp.identity] Sign -> DEBU 1292 Sign: plaintext: 12067075626C69631804A201320A2040...120C08A7D8B2D6F2E3EEE115104B1801
2019-09-12 15:46:48.830 UTC [msp.identity] Sign -> DEBU 1293 Sign: digest: B954291CBCAA463F87653DCEB2F646876D235EB45C9151EAA88E01AC1AC7A8C2
2019-09-12 15:46:48.830 UTC [gossip.election] waitForInterrupt -> DEBU 1294 40cb42faca1e036953bc20efe4908c5941a8efe3070a6c2de1c5e4462dab701b : Entering
2019-09-12 15:46:49.649 UTC [msp] GetDefaultSigningIdentity -> DEBU 1295 Obtaining default signing identity
2019-09-12 15:46:49.649 UTC [msp.identity] Sign -> DEBU 1296 Sign: plaintext: 18012A330A221A2040CB42FACA1E0369...1B120D08A096D9F9F1E3EEE11510A901
2019-09-12 15:46:49.649 UTC [msp.identity] Sign -> DEBU 1297 Sign: digest: 88ABDDC5994D6A7CC3AA35FAFEBC2B30537D9603CBE6AD7B57B95C9BECCAB56D
2019-09-12 15:46:49.649 UTC [msp] GetDefaultSigningIdentity -> DEBU 1298 Obtaining default signing identity
2019-09-12 15:46:49.649 UTC [msp.identity] Sign -> DEBU 1299 Sign: plaintext: 0A1E706565723032636C736267623635...2E6369742E636C736E65743A37303531
2019-09-12 15:46:49.649 UTC [msp.identity] Sign -> DEBU 129a Sign: digest: 966AADFBAC1FFB2C385FE6FE2B9BC930F1D78AA5287CAF0B97354712E90D3E88
```
Let me do the correction and try it again, it should be `CORE_PEER_GOSSIP_PUBLISHSTATEINFOINTERVAL`
No change - the logs are getting printed frequently. Do i need to change any other param to reduce the Gossip Interval?
@jyellick - if u can help.
@jyellick - if u can help also.
@yacovm Do you know how to tune this?
@jyellick so the signing occurs whenever a block is committed
not when you send the message
I was confused, in the past we were sending the message but then i optimized it
so changing the send interval won't do any good
@jyellick if you want... i can do an ad hoc fix
Out of curiosity, why is it that the peer signs, I would have thought the orderer signatures would have been adequate?
well, there is more data in that message than just the block height
I see
it's a generic channel metadata
Doing following changes snoozes the gossip for the first time however see the same messages coming back at frequency of 5secs
```
- CORE_PEER_GOSSIP_PULLINTERVAL=5m
- CORE_PEER_GOSSIP_ALIVETIMEINTERVAL=5m
- CORE_PEER_GOSSIP_PUBLISHSTATEINFOINTERVAL=5m
- CORE_PEER_GOSSIP_ELECTION_MEMBERSHIPSAMPLEINTERVAL=5m
- CORE_PEER_GOSSIP_ELECTION_LEADERELECTIONDURATION=5m
- CORE_PEER_GOSSIP_REQUESTSTATEINFOINTERVAL=5m
```
Just changing `CORE_PEER_GOSSIP_PUBLISHSTATEINFOINTERVAL` did nt help
@rahulhegde i have another idea
```
2019-09-12 15:46:48.780 UTC [gossip.election] waitForInterrupt -> DEBU 128e 40cb42faca1e036953bc20efe4908c5941a8efe3070a6c2de1c5e4462dab701b : Entering
2019-09-12 15:46:48.829 UTC [gossip.election] waitForInterrupt -> DEBU 128f 40cb42faca1e036953bc20efe4908c5941a8efe3070a6c2de1c5e4462dab701b : Exiting```
https://github.com/hyperledger/fabric/blob/master/sampleconfig/core.yaml#L103
make this `false`
`useLeaderElection: false`
First test has come good. Running another test with
```
- CORE_PEER_GOSSIP_PULLINTERVAL=5m
- CORE_PEER_GOSSIP_ALIVETIMEINTERVAL=5m
- CORE_PEER_GOSSIP_PUBLISHSTATEINFOINTERVAL=5m
- CORE_PEER_GOSSIP_ELECTION_MEMBERSHIPSAMPLEINTERVAL=5m
- CORE_PEER_GOSSIP_ELECTION_LEADERELECTIONDURATION=5m
- CORE_PEER_GOSSIP_REQUESTSTATEINFOINTERVAL=5m
```
First test has shown improved result. Running few more test
```
- CORE_PEER_GOSSIP_PULLINTERVAL=5m
- CORE_PEER_GOSSIP_ALIVETIMEINTERVAL=5m
- CORE_PEER_GOSSIP_PUBLISHSTATEINFOINTERVAL=5m
- CORE_PEER_GOSSIP_ELECTION_MEMBERSHIPSAMPLEINTERVAL=5m
- CORE_PEER_GOSSIP_ELECTION_LEADERELECTIONDURATION=5m
- CORE_PEER_GOSSIP_REQUESTSTATEINFOINTERVAL=5m
```
trust me.... disable the leader election
If you disable leader election, you must set one or more (or all) peers to be leaders, no?
yes of course
Note - CLS does not use anchor peer.
`orgLeader: false` needs to be `true` if you want to get blocks
So we have 2 peers in only 1 organization and rest organizations have 1 peer per organization.
Do you recommend to set?
```
- CORE_PEER_GOSSIP_USELEADERELECTION=false
- CORE_PEER_GOSSIP_ORGLEADER=true
```
So we have 2 peers in only 1 organization and rest organizations have 1 peer per organization.
Do you recommend to set for all peers and this would disable gossip forever?
```
- CORE_PEER_GOSSIP_USELEADERELECTION=false
- CORE_PEER_GOSSIP_ORGLEADER=true
```
It will not disable gossip entirely, but it will eliminate the leader election messages, which may be the source of your problem.
@rahulhegde yes
try it
No Luck on
```
- CORE_PEER_GOSSIP_USELEADERELECTION=false
- CORE_PEER_GOSSIP_ORGLEADER=true
```
I tried the same on DEV machine. I see these logs coming repeatedly and has signing operations
```
2019-09-12 18:05:30.406 UTC [chaincode] handleMessage -> DEBU 80e [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
2019-09-12 18:05:30.407 UTC [chaincode] handleMessage -> DEBU 80f [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
2019-09-12 18:05:30.408 UTC [chaincode] handleMessage -> DEBU 810 [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
2019-09-12 18:05:30.411 UTC [msp] GetDefaultSigningIdentity -> DEBU 811 Obtaining default signing identity
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 812 Sign: plaintext: 18012A320A221A2040CB42FACA1E0369...701B120C08B4E7C6D591DFF0E115101C
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 813 Sign: digest: 00E3A28C587EB6E256CD2EA318D182F4798759EB2E1795856E50E584DAFB0CED
2019-09-12 18:05:30.411 UTC [msp] GetDefaultSigningIdentity -> DEBU 814 Obtaining default signing identity
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 815 Sign: plaintext: 0A1E706565723032636C736267623635...2E6369742E636C736E65743A37303531
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 816 Sign: digest: 966AADFBAC1FFB2C385FE6FE2B9BC930F1D78AA5287CAF0B97354712E90D3E88
2019-09-12 18:05:30.412 UTC [gossip.discovery] periodicalSendAlive -> DEBU 817 Sleeping 5s
2019-09-12 18:05:30.415 UTC [msp] GetDefaultSigningIdentity -> DEBU 818 Obtaining default signing identity
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 819 Sign: plaintext: 18012A320A221A2040CB42FACA1E0369...701B120C08B4E7C6D591DFF0E115101D
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 81a Sign: digest: 1305DFD8ADB7404E5712B2C05B4ADAB287F5807026AE3A21BFE64980E6DF556B
2019-09-12 18:05:30.415 UTC [msp] GetDefaultSigningIdentity -> DEBU 81b Obtaining default signing identity
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 81c Sign: plaintext: 0A1E706565723032636C736267623635...2E6369742E636C736E65743A37303531
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 81d Sign: digest: 966AADFBAC1FFB2C385FE6FE2B9BC930F1D78AA5287CAF0B97354712E90D3E88
```
No Luck
```
- CORE_PEER_GOSSIP_USELEADERELECTION=false
- CORE_PEER_GOSSIP_ORGLEADER=true
```
I tried the same on DEV machine. I see these logs coming repeatedly and has signing operations
```
2019-09-12 18:05:30.406 UTC [chaincode] handleMessage -> DEBU 80e [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
2019-09-12 18:05:30.407 UTC [chaincode] handleMessage -> DEBU 80f [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
2019-09-12 18:05:30.408 UTC [chaincode] handleMessage -> DEBU 810 [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
2019-09-12 18:05:30.411 UTC [msp] GetDefaultSigningIdentity -> DEBU 811 Obtaining default signing identity
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 812 Sign: plaintext: 18012A320A221A2040CB42FACA1E0369...701B120C08B4E7C6D591DFF0E115101C
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 813 Sign: digest: 00E3A28C587EB6E256CD2EA318D182F4798759EB2E1795856E50E584DAFB0CED
2019-09-12 18:05:30.411 UTC [msp] GetDefaultSigningIdentity -> DEBU 814 Obtaining default signing identity
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 815 Sign: plaintext: 0A1E706565723032636C736267623635...2E6369742E636C736E65743A37303531
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 816 Sign: digest: 966AADFBAC1FFB2C385FE6FE2B9BC930F1D78AA5287CAF0B97354712E90D3E88
2019-09-12 18:05:30.412 UTC [gossip.discovery] periodicalSendAlive -> DEBU 817 Sleeping 5s
2019-09-12 18:05:30.415 UTC [msp] GetDefaultSigningIdentity -> DEBU 818 Obtaining default signing identity
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 819 Sign: plaintext: 18012A320A221A2040CB42FACA1E0369...701B120C08B4E7C6D591DFF0E115101D
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 81a Sign: digest: 1305DFD8ADB7404E5712B2C05B4ADAB287F5807026AE3A21BFE64980E6DF556B
2019-09-12 18:05:30.415 UTC [msp] GetDefaultSigningIdentity -> DEBU 81b Obtaining default signing identity
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 81c Sign: plaintext: 0A1E706565723032636C736267623635...2E6369742E636C736E65743A37303531
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 81d Sign: digest: 966AADFBAC1FFB2C385FE6FE2B9BC930F1D78AA5287CAF0B97354712E90D3E88
```
@rahulhegde how do you deduce there is no luck?
you still have cross channel signing but it's orthogonal to number of channels
what is cross channel signing?
i mean it's not channel related
we have messages about membership that is orthogonal to channels
so if you have 10 or 1000 channels it still signs once per 5 seconds
now when you disabled leader election can you perhaps check if the endorsements are still slow, @rahulhegde ?
We will try this test - we did break for 1hr. I had a question.
The logs that were shared as attachment - it does have
```
[36m2019-09-10 19:11:03.337 CEST [endorser] EndorseWithPlugin -> DEBU 6145a[0m Entering endorsement for {plugin: escc, channel: cls1obo-cls2obo, tx: cba4ac61ecace906e80eb1161f8bdaa3c61ac8874951375b77c7f4105b84e9ed, chaincode: p2pcls}
[36m2019-09-10 19:11:03.337 CEST [msp.identity] Sign -> DEBU 6145b[0m Sign: plaintext: 0A20CD46617AA34AEA3AB8D0AEC0D767...455254494649434154452D2D2D2D2D0A
[36m2019-09-10 19:11:03.337 CEST [msp.identity] Sign -> DEBU 6145c[0m Sign: digest: 603912D0F6BDE305A66098BA8B12CB71E7EDFAB6CFBC32AEA5AA5A682E341089
[36m2019-09-10 19:11:03.337 CEST [bccsp_p11] getSession -> DEBU 6145d[0m Reusing existing pkcs11 session 36 on slot 0
[36m2019-09-10 19:11:03.340 CEST [gossip.state] commitBlock -> DEBU 6145e[0m [cls1obo-cls2obo] Committed block [208224] with 3 transaction(s)
[36m2019-09-10 19:11:03.501 CEST [gossip.election] waitForInterrupt -> DEBU 6145f[0m 8f165a0bff9a395d72441ebb0be8e5f539ddd27172320230d93c826daf6a590a : Exiting
[36m2019-09-10 19:11:03.501 CEST [gossip.election] IsLeader -> DEBU 61460[0m 8f165a0bff9a395d72441ebb0be8e5f539ddd27172320230d93c826daf6a590a : Returning true
[36m2019-09-10 19:11:03.501 CEST [msp] GetDefaultSigningIdentity -> DEBU 61461[0m Obtaining default signing identity
[36m2019-09-10 19:11:03.501 CEST [msp.identity] Sign -> DEBU 61462[0m Sign: plaintext: 120F636C73356F626F2D636C73386F62...0D08B4FFB385E29AC8E11510E1011801
[36m2019-09-10 19:11:03.501 CEST [msp.identity] Sign -> DEBU 61463[0m Sign: digest: B55139BE9A1F916A88BE167FA9795E94D0C0AE0046B53E356850C903AE512834
[36m2019-09-10 19:11:03.501 CEST [bccsp_p11] getSession -> DEBU 61464[0m Reusing existing pkcs11 session 44 on slot 0
[36m2019-09-10 19:11:03.640 CEST [gossip.election] waitForInterrupt -> DEBU 61465[0m 8f165a0bff9a395d72441ebb0be8e5f539ddd27172320230d93c826daf6a590a : Exiting
[36m2019-09-10 19:11:03.640 CEST [gossip.election] IsLeader -> DEBU 61466[0m 8f165a0bff9a395d72441ebb0be8e5f539ddd27172320230d93c826daf6a590a : Returning true
[36m2019-09-10 19:11:03.640 CEST [msp] GetDefaultSigningIdentity -> DEBU 61467[0m Obtaining default signing identity
[36m2019-09-10 19:11:03.640 CEST [msp.identity] Sign -> DEBU 61468[0m Sign: plaintext: 120F616C7068636C732D636C73336F62...0D08B982FEB8889AC8E11510E7011801
[36m2019-09-10 19:11:03.640 CEST [msp.identity] Sign -> DEBU 61469[0m Sign: digest: CE92CFFB7DF2186125FFBEB2684AFAAB8936A7FA29531D4E3D18B58A329471DF
[36m2019-09-10 19:11:03.640 CEST [bccsp_p11] getSession -> DEBU 6146a[0m Reusing existing pkcs11 session 9 on slot 0
[36m2019-09-10 19:11:03.740 CEST [gossip.election] waitForInterrupt -> DEBU 6146b[0m 8f165a0bff9a395d72441ebb0be8e5f539ddd27172320230d93c826daf6a590a : Exiting
[36m2019-09-10 19:11:03.740 CEST [gossip.election] IsLeader -> DEBU 6146c[0m 8f165a0bff9a395d72441ebb0be8e5f539ddd27172320230d93c826daf6a590a : Returning true
[36m2019-09-10 19:11:03.740 CEST [msp] GetDefaultSigningIdentity -> DEBU 6146d[0m Obtaining default signing identity
[36m2019-09-10 19:11:03.740 CEST [msp.identity] Sign -> DEBU 6146e[0m Sign: plaintext: 120F636C73356F626F2D636C73366F62...0D08B9EBF0C5DE9AC8E11510E4011801
[36m2019-09-10 19:11:03.740 CEST [msp.identity] Sign -> DEBU 6146f[0m Sign: digest: 5294F85123BE5B2F91DB8775F5B111AA8C45637DC42823F38212E2D618BC5F76
[36m2019-09-10 19:11:03.740 CEST [bccsp_p11] getSession -> DEBU 61470[0m Reusing existing pkcs11 session 69 on slot 0
```
This one from DEV environment, does also have similar messages related to signing operation
```
2019-09-12 18:05:30.406 UTC [chaincode] handleMessage -> DEBU 80e [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
2019-09-12 18:05:30.407 UTC [chaincode] handleMessage -> DEBU 80f [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
2019-09-12 18:05:30.408 UTC [chaincode] handleMessage -> DEBU 810 [] Fabric side handling ChaincodeMessage of type: KEEPALIVE in state ready
2019-09-12 18:05:30.411 UTC [msp] GetDefaultSigningIdentity -> DEBU 811 Obtaining default signing identity
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 812 Sign: plaintext: 18012A320A221A2040CB42FACA1E0369...701B120C08B4E7C6D591DFF0E115101C
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 813 Sign: digest: 00E3A28C587EB6E256CD2EA318D182F4798759EB2E1795856E50E584DAFB0CED
2019-09-12 18:05:30.411 UTC [msp] GetDefaultSigningIdentity -> DEBU 814 Obtaining default signing identity
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 815 Sign: plaintext: 0A1E706565723032636C736267623635...2E6369742E636C736E65743A37303531
2019-09-12 18:05:30.411 UTC [msp.identity] Sign -> DEBU 816 Sign: digest: 966AADFBAC1FFB2C385FE6FE2B9BC930F1D78AA5287CAF0B97354712E90D3E88
2019-09-12 18:05:30.412 UTC [gossip.discovery] periodicalSendAlive -> DEBU 817 Sleeping 5s
2019-09-12 18:05:30.415 UTC [msp] GetDefaultSigningIdentity -> DEBU 818 Obtaining default signing identity
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 819 Sign: plaintext: 18012A320A221A2040CB42FACA1E0369...701B120C08B4E7C6D591DFF0E115101D
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 81a Sign: digest: 1305DFD8ADB7404E5712B2C05B4ADAB287F5807026AE3A21BFE64980E6DF556B
2019-09-12 18:05:30.415 UTC [msp] GetDefaultSigningIdentity -> DEBU 81b Obtaining default signing identity
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 81c Sign: plaintext: 0A1E706565723032636C736267623635...2E6369742E636C736E65743A37303531
2019-09-12 18:05:30.415 UTC [msp.identity] Sign -> DEBU 81d Sign: digest: 966AADFBAC1FFB2C385FE6FE2B9BC930F1D78AA5287CAF0B97354712E90D3E88
```
I am not sure - how would it improve throughput of Peer during Endorsement Processing?
Note - we ran 3 test and all went well by snoozing the Gossip using following params
```
- CORE_PEER_GOSSIP_PULLINTERVAL=5m
- CORE_PEER_GOSSIP_ALIVETIMEINTERVAL=5m
- CORE_PEER_GOSSIP_PUBLISHSTATEINFOINTERVAL=5m
- CORE_PEER_GOSSIP_ELECTION_MEMBERSHIPSAMPLEINTERVAL=5m
- CORE_PEER_GOSSIP_ELECTION_LEADERELECTIONDURATION=5m
- CORE_PEER_GOSSIP_REQUESTSTATEINFOINTERVAL=5m
```
do what you want.... it's your system
its true that its our system but would like to ask expert and do the best for the fabric product that we are running in Production and not in LAB or DEV
i'll be back in a few hours
meanwhile test what i asked ;)
disable leader election
Other thing i see in Fabric Peer (default value) v1.0.6 v/s Fabric v1.4.2
Fabric v1.0.6 - where we are
```
# Defines whenever peer will initialize dynamic algorithm for
# "leader" selection, where leader is the peer to establish
# connection with ordering service and use delivery protocol
# to pull ledger blocks from ordering service. It is recommended to
# use leader election for large networks of peers.
useLeaderElection: true
# Statically defines peer to be an organization "leader",
# where this means that current peer will maintain connection
# with ordering service and disseminate block across peers in
# its own organization
orgLeader: false
```
and Fabric v1.4.2
Other thing i see in Fabric Peer (default value) v1.0.6 v/s Fabric v1.4.2
Fabric v1.0.6 - where we are
```
# Defines whenever peer will initialize dynamic algorithm for
# "leader" selection, where leader is the peer to establish
# connection with ordering service and use delivery protocol
# to pull ledger blocks from ordering service. It is recommended to
# use leader election for large networks of peers.
useLeaderElection: true
# Statically defines peer to be an organization "leader",
# where this means that current peer will maintain connection
# with ordering service and disseminate block across peers in
# its own organization
orgLeader: false
```
and Fabric v1.4.2
```
# Defines whenever peer will initialize dynamic algorithm for
# "leader" selection, where leader is the peer to establish
# connection with ordering service and use delivery protocol
# to pull ledger blocks from ordering service. It is recommended to
# use leader election for large networks of peers.
useLeaderElection: true
# Statically defines peer to be an organization "leader",
# where this means that current peer will maintain connection
# with ordering service and disseminate block across peers in
# its own organization
orgLeader: false
```
Other thing i see in Fabric Peer (default value) v1.0.6 v/s Fabric v1.4.2
Fabric v1.0.6 -
```
# Defines whenever peer will initialize dynamic algorithm for
# "leader" selection, where leader is the peer to establish
# connection with ordering service and use delivery protocol
# to pull ledger blocks from ordering service. It is recommended to
# use leader election for large networks of peers.
useLeaderElection: true
# Statically defines peer to be an organization "leader",
# where this means that current peer will maintain connection
# with ordering service and disseminate block across peers in
# its own organization
orgLeader: false
```
and Fabric v1.4.2
```
# Defines whenever peer will initialize dynamic algorithm for
# "leader" selection, where leader is the peer to establish
# connection with ordering service and use delivery protocol
# to pull ledger blocks from ordering service. It is recommended to
# use leader election for large networks of peers.
useLeaderElection: true
# Statically defines peer to be an organization "leader",
# where this means that current peer will maintain connection
# with ordering service and disseminate block across peers in
# its own organization
orgLeader: false
```
Other thing i see in Fabric Peer (default value) v1.0.6 v/s Fabric v1.4.2
Fabric v1.0.6 -
```
# Defines whenever peer will initialize dynamic algorithm for
# "leader" selection, where leader is the peer to establish
# connection with ordering service and use delivery protocol
# to pull ledger blocks from ordering service. It is recommended to
# use leader election for large networks of peers.
useLeaderElection: false
# Statically defines peer to be an organization "leader",
# where this means that current peer will maintain connection
# with ordering service and disseminate block across peers in
# its own organization
orgLeader: true
```
and Fabric v1.4.2
```
# Defines whenever peer will initialize dynamic algorithm for
# "leader" selection, where leader is the peer to establish
# connection with ordering service and use delivery protocol
# to pull ledger blocks from ordering service. It is recommended to
# use leader election for large networks of peers.
useLeaderElection: true
# Statically defines peer to be an organization "leader",
# where this means that current peer will maintain connection
# with ordering service and disseminate block across peers in
# its own organization
orgLeader: false
```
The above 1.0.6 is running with 200 channels in PreProduction environment where we did not see the slowness. we will try u r test.
@yacovm - we were not able to reproduce this issue once was added.
```
- CORE_PEER_GOSSIP_USELEADERELECTION=false
- CORE_PEER_GOSSIP_ORGLEADER=true
```
@yacovm - we were not able to reproduce this issue once we added.
```
- CORE_PEER_GOSSIP_USELEADERELECTION=false
- CORE_PEER_GOSSIP_ORGLEADER=true
```
ok
@jyellick ^
Can you explain, `you still have cross channel signing but it's orthogonal to number of channels`
Can you explain with an example, `you still have cross channel signing but it's orthogonal to number of channels`
yes... gossip has 2 levels of membership information
the base level is alive membership - peers publish their Host:port periodically
they sign this message when they send it
the signing is used because this message is sent in hops and not point to point, so peer `a` can create this message and send to peer `b` and then peer `b` can send it to peer `c`
so in order for peer `c` to believe this message is authentic, it needs to be signed
we have also other information in this message but let's leave it out for now
now... on top of this level we build membership per channel
for each channel, we send channel related metadata
such as ledger height, and what chaincodes you have installed
so the first level is cross channel, as 2 peers can send each other this message even if they are not in the same channel, but they are in the same organization
now, this is orthogonal to the number of channels because it's on the first level and the channel membership uses this level to bootstrap itself
now an example would be, that if you have 2 peers- `p` and `q` then if `p` is member of 100 channels it will send an `AliveMessage` only once per 5 seconds
now an example would be, that if you have 2 peers- `p` and `q` then if `p` is member of 100 channels or 1000000 channels it will still send an `AliveMessage` to `q` only once per 5 seconds
Thanks @yacom and @jyellick for all the support.
Thanks @yacovm and @jyellick for all the support.
Has joined the channel.
hello everybody
i have a question about pagination
im using getQueryResultWithPagination function
but the returned bookmark is always emtpy
any idea why is that?
im sending a page of 1000 and sure that the query should return around 32,000 records
im getting the 1000 records, but i cannot get next 1000 records because i dont have the bookmark value
Has joined the channel.
Has joined the channel.
Has joined the channel.
Anyone seen this gem before?
```
10/16/2019 11:31:23 AM 2019-10-16 15:31:23.101 UTC [chaincode] HandleTransaction -> ERRO 155a [2cc0fa7a] Failed to handle GET_STATE. error: no revision tag detected
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/util/couchdb.getRevisionHeader
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:735
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchDatabase).ReadDoc
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:788
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.(*VersionedDB).GetState
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:297
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/privacyenabledstate.(*CommonStorageDB).GetState
10/16/2019 11:31:23 AM
Anyone seen this gem before?
```
10/16/2019 11:31:23 AM 2019-10-16 15:31:23.101 UTC [chaincode] HandleTransaction -> ERRO 155a [2cc0fa7a] Failed to handle GET_STATE. error: no revision tag detected
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/util/couchdb.getRevisionHeader
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:735
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchDatabase).ReadDoc
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:788
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.(*VersionedDB).GetState
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:297
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/privacyenabledstate.(*CommonStorageDB).GetState
10/16/2019 11:31:23 AM
Anyone seen this gem before?
```
10/16/2019 11:31:23 AM 2019-10-16 15:31:23.101 UTC [chaincode] HandleTransaction -> ERRO 155a [2cc0fa7a] Failed to handle GET_STATE. error: no revision tag detected
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/util/couchdb.getRevisionHeader
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:735
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/util/couchdb.(*CouchDatabase).ReadDoc
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/util/couchdb/couchdb.go:788
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb.(*VersionedDB).GetState
10/16/2019 11:31:23 AM /opt/gopath/src/github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/statedb/statecouchdb/statecouchdb.go:297
10/16/2019 11:31:23 AM github.com/hyperledger/fabric/core/ledger/kvledger/txmgmt/privacyenabledstate.(*CommonStorageDB).GetState
10/16/2019 11:31:23 AM
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
rebuild
how to view the data in the ledger ... for example car1 owner = "Ammu", car1 owner = "Ram",car1 owner = "prabu" how to view all these transaction change in hyper ledger fabric? in couch db i can see only latest updated data .
Has joined the channel.
Has joined the channel.
Clipboard - January 8, 2020 6:37 PM
Clipboard - January 8, 2020 6:38 PM
Clipboard - January 8, 2020 6:39 PM
Hi All, I am having some trouble with the indexing feature in couchDB. I have enabled index and I can see that in the peer logs also. I also see the design document in the couchDB database that has this index.
However when i try to query using this index, i keep getting a warning in the peer logs
I am using this in the query arguments from postman
["query","{\"selector\":{\"recordId\":\"uuid-1\"}, \"use_index\":[\"_design/indexRecordIdDoc\", \"indexRecordId\"]}"]
You need to implement in chaincode....GetHistoryForKey()
More information here - https://fabric-shim.github.io/master/fabric-shim.ChaincodeStub.html
couchdb does not think the index matches the query... this is pass through from Fabric perspective, so you'll need to test indexes and queries in couchdb outside of Fabric and get it working, then utilize the working index and query within chaincode. For troubleshooting CouchDB queries, I'd recommend go to CouchDB community rather than Fabric community.
Thanks Dave. I figured my issue and it works now. A very silly typo but took me a while to figure it out :)
Hi all, when I try to instantiate chaincode. the logs says, document not found error: ` HTTP Request: GET /twoorgschannel_lscc/ccex?attachments=true HTTP/1.1 | Host: couchdbp1o1:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Authorization: Basic cGVlcjEtb3JnMTpwMW8xY2RicHc= | Accept-Encoding: gzip | |
2020-01-10 12:54:21.903 UTC [couchdb] handleRequest -> DEBU 3897e Error handling CouchDB request. Error:not_found, Status Code:404, Reason:missing ` in the peer.
The couchdb logs has the following error:
``` HTTP Request: GET /twoorgschannel_lscc/ccex?attachments=true HTTP/1.1 | Host: couchdbp1o1:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Authorization: Basic cGVlcjEtb3JnMTpwMW8xY2RicHc= | Accept-Encoding: gzip | |
2020-01-10 12:54:21.903 UTC [couchdb] handleRequest -> DEBU 3897e Error handling CouchDB request. Error:not_found, Status Code:404, Reason:missing ```
Can anyone help me figure this out?
Hi all, when I try to instantiate chaincode. the logs says, document not found error: ``` HTTP Request: GET /twoorgschannel_lscc/ccex?attachments=true HTTP/1.1 | Host: couchdbp1o1:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Authorization: Basic cGVlcjEtb3JnMTpwMW8xY2RicHc= | Accept-Encoding: gzip | |
2020-01-10 12:54:21.903 UTC [couchdb] handleRequest -> DEBU 3897e Error handling CouchDB request. Error:not_found, Status Code:404, Reason:missing ``` in peer.
The couchdb logs has the following error:
``` HTTP Request: GET /twoorgschannel_lscc/ccex?attachments=true HTTP/1.1 | Host: couchdbp1o1:5984 | User-Agent: Go-http-client/1.1 | Accept: multipart/related | Authorization: Basic cGVlcjEtb3JnMTpwMW8xY2RicHc= | Accept-Encoding: gzip | |
2020-01-10 12:54:21.903 UTC [couchdb] handleRequest -> DEBU 3897e Error handling CouchDB request. Error:not_found, Status Code:404, Reason:missing ```
Can anyone help me figure this out?
@indirajith if first queries to see if the chaincode is already there, so a not_found error is expected if this is a new instantiation. it should go on to create the chaincode.
@indirajith it first queries to see if the chaincode is already there, so a not_found error is expected if this is a new instantiation. it should go on to create the chaincode.
oh, thank you very much. Now I get the point. So once, its instantiated or invoked, it will be created. So, shall I conclude the problem I face in instantiating is not related to this.
correct. look to see if there is an error response coming back to your client, or if there is a message in peer log, rather than looking at couchdb database level messages.
@dave.enyeart hi, I wonder why config block can't query by txId? how can I retrieve all the config block in history from the ledger
Hi All, has anyone here tried to run couchDB on a separate VM or as a cloud service and connected to the fabric peer?
Has joined the channel.
Hi Everyone, is it possible to use Private Data Collections if the network is configured to use LevelDB as the World State? Thanks!
yes, private data works with both leveldb and couchdb
@dave.enyeart . Thanks a bunch. Are there any performance considerations when using Private Data Collections?
Has joined the channel.
hello all , is there a anyone who tried to get peer identity using Shim functions ??
@Khaled.MH this story has just gotten merged for upcoming v2.0: https://jira.hyperledger.org/browse/FAB-17439
is that what you need? or you need something besides peer's org mspid?
@dave.enyeart i need something besides peer's org mspid !
@Khaled.MH ok, please describe the use case and what exactly you need. Ideally in a Jira story.
hello guys how can i download a specifig hyperledger lib using govendor ?
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has left the channel.
Has joined the channel.
Hi, I'm curious if creating a new channel (per year) could be considered as an acceptable practice/workaround, until the "Checkpoint and Archive" feature gets delivered. The data is relatively short living, so the question is more technical than business relevant. Thanks in advance!
@ivanovv if your data is append only, that sounds reasonable. if your transactions are read/write, then obviously the channel per year will become problematic at year boundaries
@dave.enyeart - Can Hyperledger Fabric peers be deployed in different AZ's? If so do you have any design document on that?
Yes, having peers distributed around the world is a typical scenario. The current deployment guide work will likely help people understand the considerations - https://jira.hyperledger.org/browse/FAB-11240
Has joined the channel.
Has joined the channel.
Hi all,
I believe I might of noticed a bug or maybe it is an expected error in regards to the fabric ledger.
**Problem**
So I noticed when a peer container gets rebuild or taken down/brought up and if there is no *disk mounting* enabled then peer gets taken out of the channel because the peer data is lost, which is completely expected. *However* when the peer rejoins the same application channel, the previous blocks before it left the channel become invalid but the same blocks on other peers are valid. The blocks after the peer rejoined channel are synced correctly with txValidadtioncode matching with the corresponding blocks in all peers.
I tried doing the command `peer node reset` on the peer that rejoined the channel but after the reset the peer still shows previous blocks as invalid.
**Steps to Reproduce**
1. Create HF network with 2 Orgs and at least one peer per Org
2. Create sample test transactions
3. Check the txValidationCode for a random application transaction block such as block #10
4. Change up a peer configuration such as logging level or timeout value.
5. Rebuild the peer container that had the configuration changed, I used the command `docker-compose up -d —build`
6. Rejoin the channel with the peer, because the peer left the channel due to the fact disk mounting was disabled when it rebuilt and all chaincode and channel data was lost.
7. Check the txValidationCode for the same block in step 3 (Block #10). Should change to invalid now.
8. I stopped the peer, then executed the command `peer node reset` and started the peer again but the previous blocks are still invalid.
Any thoughts or suggestions on this issue will be much appreciated. If this is an expected issue, please let me know on how I might be able to resolve this.
Jira ticket: https://jira.hyperledger.org/browse/FAB-17823
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
@dave.enyeart https://jira.hyperledger.org/browse/FAB-17035
i meet the same question
i meet the same question,do you resovle it?
@xachen it seems like a timing issue in peer startup that is benign... gossip gets connections a few seconds later.
Has joined the channel.
Hello, I'm trying to fetch peers from discover CLI but result giving me only target peer information. Is this the default behavior or should I expect all four peers information?
Note: I have set the "CORE_PEER_GOSSIP_EXTERNALENDPOINT" on all four anchor peers but still no way of knowing that gossip is running properly since, peers logs contain no warning and error.
https://chat.hyperledger.org/channel/fabric?msg=G65LwgcHxgYj3rbBn
@manish-sethi @dave.enyeart @Senthil1
can you help this question?
Hi, I'm trying to connect fabric java sdk with fabric network but due to some unknown reasons facing grpc connection issue with peer.
Issue:
`2020-08-11 12:43:09.433 WARN 3068 --- [ main] org.hyperledger.fabric.sdk.Channel : getConfigBlock for channel mychannel failed with peer peer1.liquidus.com. Status FAILURE, details: Channel Channel{id: 1, name: mychannel} Sending proposal with transaction: 3060b0f5b6220c393fb4b96be9d7bbe7d5799404e271bdf1573022265f866afa to Peer{ id: 2, name: peer1.liquidus.com, channelName: mychannel, url: grpc://SERVER_IP:7061, mspid: liquidusMSP} failed because of: gRPC failure=Status{code=UNAVAILABLE, description=Network closed for unknown reason, cause=null}
2020-08-11 12:43:09.435 ERROR 3068 --- [ main] org.hyperledger.fabric.sdk.Channel : getConfigBlock for channel mychannel failed with peer peer1.liquidus.com. Status FAILURE, details: Channel Channel{id: 1, name: mychannel} Sending proposal with transaction: 3060b0f5b6220c393fb4b96be9d7bbe7d5799404e271bdf1573022265f866afa to Peer{ id: 2, name: peer1.liquidus.com, channelName: mychannel, url: grpc://SERVER_IP:7061, mspid: liquidusMSP} failed because of: gRPC failure=Status{code=UNAVAILABLE, description=Network closed for unknown reason, cause=null}`
Hi, I'm trying to connect fabric java sdk with fabric network but due to some unknown reasons facing grpc connection issue.
Issue:
`2020-08-11 12:43:09.433 WARN 3068 --- [ main] org.hyperledger.fabric.sdk.Channel : getConfigBlock for channel mychannel failed with peer peer1.liquidus.com. Status FAILURE, details: Channel Channel{id: 1, name: mychannel} Sending proposal with transaction: 3060b0f5b6220c393fb4b96be9d7bbe7d5799404e271bdf1573022265f866afa to Peer{ id: 2, name: peer1.liquidus.com, channelName: mychannel, url: grpc://SERVER_IP:7061, mspid: liquidusMSP} failed because of: gRPC failure=Status{code=UNAVAILABLE, description=Network closed for unknown reason, cause=null}
2020-08-11 12:43:09.435 ERROR 3068 --- [ main] org.hyperledger.fabric.sdk.Channel : getConfigBlock for channel mychannel failed with peer peer1.liquidus.com. Status FAILURE, details: Channel Channel{id: 1, name: mychannel} Sending proposal with transaction: 3060b0f5b6220c393fb4b96be9d7bbe7d5799404e271bdf1573022265f866afa to Peer{ id: 2, name: peer1.liquidus.com, channelName: mychannel, url: grpc://SERVER_IP:7061, mspid: liquidusMSP} failed because of: gRPC failure=Status{code=UNAVAILABLE, description=Network closed for unknown reason, cause=null}`
Has left the channel.
Has joined the channel.
Has left the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Has joined the channel.
Asked this in the other channel but didn't see any response. Is there guidance on how to interpret `txValidationCode` returned when getting a block or transaction? I have most of mine showing up as 17, even the ones that were valid transactions. Looking backwards I now can't differentiate between what transactions failed "at the time" and which were previously valid and are now 17 (due to recent contract updates I assume).
All of my contract deploy transactions are also txValidationCode 10 which also seems strange as they definitely deployed
https://github.com/hyperledger/fabric-protos/blob/318e632e5e0c668a1be9e1f882f814f179460766/peer/transaction.proto#L95
Has joined the channel.
Dear All,
Dear Friends,
In CouchDB UI (Fauxton), I see that values are in encrypted format as below. Earlier, I used to see the exact values (plain text) (incluing big JSON values). Seems I am missing a simple thing. Please provide the way we can see exact values that are stored in CouchDB. Thank you.
{
"_id": "b",
"_rev": "2-f2e091417a9884e1f5ef483ae2b71093",
"~version": "\u0000CgMBBAA=",
"_attachments": {
"valueBytes": {
"content_type": "application/octet-stream",
"revpos": 2,
"digest": "md5-erMb61ThOljS75mpAoTenw==",
"length": 3,
"stub": true
}
}
}
Has joined the channel.
If the value being persisted to state database is not well formed JSON then it will be saved to CouchDB as an attachment. What you see here is the attachment hash. It seems therefore that your value was not JSON.
Has joined the channel.
Has joined the channel.
Hi Team,
I am trying to setup test-network in my local machine, it creates container and required artifacts but failing while creating channel.
It says "scripts/createChannel.sh: line 40: osnadmin: command not found
Channel creation failed"
Any idea what could go wrong here ?
Any help would be greatly appreciated.
Thanks
@dave.enyeart i meet a weird problem, when i start peer, it tell me
@dave.enyeart i meet a weird problem, i can't start the peer, the below is the peer's log,can you take a look?
Clipboard - 2021年12月10日下午5点21分
Clipboard - 2021年12月10日下午5点24分
Clipboard - 2021年12月10日下午5点46分
Clipboard - 2021年12月10日下午5点46分
@manish-sethi can you give me a clue, i see the code that you provide
Clipboard - December 21, 2021 10:23 PM
Has joined the channel.
.png){kind=link}
.png){kind=link}
