udaykiran19491/user-stories-from-tawos-for-llm-fine-tuning huggingface dataset:
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Because agreement is going to be stored in private-data collections which are only accessible to the owning organization, other orgs will need to be able to verify agreement without being able to actually read the data (only its hashes).    The implementation should effectively serialize the structure, then confirm that the hash of serialized version matches the stored hashes."
Answer: 63478.0

User story: "The rationale behind custom marshaling for FAB-13500 is to allow more fine-grained dependencies in the read set of transactions depending on the chaincode (or other namespace) definition.  Therefore, it's necessary to allow the deserialization of single fields from serialized structures."
Answer: 63478.0

User story: "This is a symmetrical story to FAB-13500.  The structures serialized must be able to be deserialized."
Answer: 63479.0

User story: "The v1.x implementation of LSCC stored all of the chaincode information (except for collections) in a single monolithic value using protobuf.  This has the problem that any change to the chaincode definition invalidates all in-flight requests, so for instance changing the endorsement policy (which has no affect on the output of the tx) will invalidate a transaction unnecessarily.    Therefore, it's desirable to have a way to store individual structure fields as keys, but without introducing the complexity of serializing all fields individually.    The implementation should allow for abitrary structures with int64, uint64, string, and byte fields to be serialized.  "
Answer: 63479.0

User story: There are a few items that need to be done when branching fabric-test to v1.4.   * update the PTE version in the following files (may be done before branching):   ** tools/ATD/vars/1channel.yml (tag: "1.4.0")   ** tools/ATD/vars/FAB12135.yml (tag: "1.4.0")   * change .gitmodules  ** add "branch = release-1.4" to each of the repos *minus* cello (until cello releases supporting versions)  * change Makefile  ** "git-latest" target needs to explicitly pull from the set branch  ** fabric replace "master" with "release-1.4"  ** ca replace "master" with "release-1.4"  ** fabric-chaincode-java replace "master" with "release-1.4"  ** (Once we are pulling images successfully for the test runs, we also need to ensure that pullDockerImages.sh pulls the correct images from dockerhub)  * feature/package.json  ** change "unstable" to "unstable-1.4"  * tools/PTE/package.json  ** change "unstable" to "unstable-1.4"  * tools/PTE/README.md  ** change "master" to "release-1.4"  * tools/PTE/CITest/README.md  ** change "master" to "release-1.4"
Answer: 5268.0

User story: "{color:#333333}GetPrivateDataQueryResult was written as GetQueryResult{color}"
Answer: 562331.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: I have checked the core/chaincode/platforms/golang/package.go file    the content is below.    var includeFileTypes = map[string]bool    { ".c": true, ".h": true, ".s": true, ".go": true, ".yaml": true, ".json": true,}         var logger = flogging.MustGetLogger("golang-platform")    I got the error as below.    github.com/hyperledger/fabric/vendor/golang.org/x/crypto/curve25519  opt/gopath/src/github.com/hyperledger/fabric/vendor/golang.org/x/crypto/curve25519/mont25519_amd64.go:15:6: missing function body    What should I do?
Answer: 565406.0

User story: "In the event that something goes wrong at the prover peer, we have to make sure that panics are caught when the prover peer endpoint is used."
Answer: 115463.0

User story: "The fabcar sample currently includes smart contract and application samples. It would be nice if it also included some operational samples that demonstrate using the Node.js, Java, and Go SDKs to perform operational tasks such as installing and instantiating smart contracts. Currently, the fabcar sample uses the Fabric CLI (peer command) to perform these operations."
Answer: 575062.0

User story: "A short topic on chaincode namespaces"
Answer: 43062.0

User story: To prevent dragging bunch of unnecessary complexity, the healthcheck should be implemented as a basic http or https endpoint at /healthz. When the orderer is healthy, it will return with a status of `HTTP 200/OK` and JSON payload of '    {"status": "OK"}    '. If the orderer is responsive to the status check, but unhealthy, it will return with a status of `HTTP 503/Service Unavailable` and a JSON message that indicates which subsystem has failed the health check.
Answer: 40253.0

User story: "Currently PTE request transactions are synchronous in that unless promise is resolved or timed out, next transaction is not sent. For load generation purpose to benchmark capacity / load handling of fabric network, network test tool with asynchronous load generation capability is required. "
Answer: 574698.0

User story: "When operating a system, I would like to be able to observe whether there is an increase of info, error, and warning messages that are emitted by the logging framework as a metric."
Answer: 41592.0

User story: "Fabric misses an integration test for idemix that will ensure that a transaction signed with idemix is correctly processed by Fabric.  "
Answer: 392154.0

User story: "Current token transaction design:    When a token output is spent, token processor creates a new key (tokenInputXXX) to indicate the output is spent. This incurs   # extra ledger calls when committing a token transaction,   # cause confusion in relationship between tokenInputXXX and tokenOutputXXX,   # the size of state db keeps growing.    An alternative approach is to delete the token output key to mark that that output is not available anymore. State DB then plays the role of the unspent tokens pool.    Note that this delete only impacts statedb. Fabric will still keeps the complete transaction history.      "
Answer: 130606.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: Currently, token transactions are stored using "transaction id + output index" as the state key. As a result, the "ListTokens" call will have to scan the entire "tms" namespace. If there are lots of token transactions in the ledger, this design may cause performance issue.    New Proposal: Add "owner id" to the token transaction keys when stored the state in ledger.     
Answer: 143891.0

User story: "objective: use a json file to replace a json object variable definition, see the following.     async myFunc(args) {    // the following var re-use failed  /* re-usable code has issue, 11/30/2018  var myVar = require('fieldsNvalues.json');  */    // the following static var definition works  var MyVar = {  docType: 'text',  field1: args[1],  field2: args[2],  field3: args[3],  field4: args[4]  };    await someOtherFunc(args[0], JSON.stringfy(myVar));  // replacing JSON.stringfy and changed to the following resulted in the same failure  await someOtherFunc(args[0], JSON.parse(myVar));    // fieldsNvalues.json file is a valid json file, in current directory and it contains the following  {  docType: 'text',  field1: args[1],  field2: args[2],  field3: args[3],  field4: args[4]  }"
Answer: 592223.0

User story: "The peer and orderer should export a gauge named 'fabric_version' with the following labels:  - version  - go_version  - commit_sha (tbd - could be high cardinality and should be implied by version)    The values can be obtained from fabric/common/metadata and runtime.Version."
Answer: 9486.0

User story: "I'm using fabric-chaincode-java in maven ([https://github.com/hyperledger/fabric-chaincode-java/tree/release-1.3/fabric-chaincode-example-maven)]    my project at github : [https://github.com/penggle/fabric-chaincode-example-bankmaster2]    when i execute docker exec cli peer chaincode instantiate ...    while i instantiate the chaincode successfully，the logback.xml(src/main/resource/logback.xml) was missing in chaincode.jar in docker container, but when i build the fabric-chaincode-example-bankmaster2 by command (mvn compile package) in *host machine* is correctly(the logback.xml is include in chaincode.jar)    {color:#172b4d}I don't understand why the logback.xml missing while execute docker exec cli peer chaincode instantiate ... {color}     "
Answer: 593920.0

User story: "This is to avoid snapshot sending cycles, per [comments|https://github.com/etcd-io/etcd/blob/dedae6eb7c253635e70403a1fb04842700277b23/etcdserver/server.go#L2173-L2177] in etcd:    {quote}  When sending a snapshot, etcd will pause compaction.  After receives a snapshot, the slow follower needs to get all the entries right after the snapshot sent to catch up. If we do not pause compaction, the log entries right after the snapshot sent might already be compacted. It happens when the snapshot takes long time to send and save. Pausing compaction avoids triggering a snapshot sending cycle.  {quote}"
Answer: 341301.0

User story: "Add basic endorse metrics ."
Answer: 61306.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: This came from code review: [https://gerrit.hyperledger.org/r/#/c/27588/10/token/tms/plain/verifier.go@234]        One for later, but how about we re-organise the naming conventions here? the word "output" has two meanings: 1) any new ledger keys that a transaction under evaluation proposes to create; 2) any existing ledger key that the transaction uses as input.  This is somewhat confusing: case in point: the first function that checkInputs() calls is createOutputKey() followed by getOutput().    If you don't disagree, would you mind creating a JIRA please?   
Answer: 588683.0

User story: "This story enable the support of the new transaction type that bound an endorsed action and a token transaction."
Answer: 528511.0

User story: "Augment the fabric-samples first-network sample to include a flag that allows a choice of  consensus-type.    Add a flag -o that allows users to choose between the solo or kafka consensus-type of the ordering service.    Use a single orderer node.    Use a single kafka server and a single zookeeper node.    Add two containers when kafka is selected - one for kafka one for zookeeper."
Answer: 21944.0

User story: "Start from a network similar to BYFN:   * one ordering org, with kafka-based ordering service, 3 OSNs   * 2 peer orgs, 2 peers each   * 1 kafka server + 1 zookeeper   * add a channel    Migrate the network to an etcd/raft ordering service   * etcd/raft with 3 consenters based on same OSNs   * show how to prepare the config update txs   * show how to submit said txs   * restart OSNs, verify etcd/raft OSNs    * shut down kafka+zookeeper   * test functionality by executing chaincode txs    all this should be scripted and documented"
Answer: 484013.0

User story: *Expected*:    When either *"peer.tls.clientKey.file"* or *"peer.tls.clientKey.file"* we default to read the config as    keyFile.= viper.GetString(*"*peer.tls.key.file*"*)    certPath := viper.GetString(*{color:#00875a}"peer.tls.cert.file"{color}*)          *Actual*:    Instead, by mistake, we need to read the cert path, from the "cert" file value.         *To do*:    Fix typo and default to read the *cert*.file is such a case   *cert*Path *=* viper.GetString("{color:#de350b}*peer.tls.key.file*{color}"*)               NOTE: Change may affect already deployed Fabric 1.3.0 and 1.2.0 systems.          
Answer: 608497.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Currently private data is disseminated randomly to collection member peers.  It would be better to make a best effort attempt to distribute the private data to as many orgs as possible, before sending to same org's 2nd, 3rd, etc peers.    This would provide a higher degree of data availability, for example in case a subset of orgs went offline.    On the commit pull side, peers would consequently want to prefer peers from their same org, as these peers are more likely to be co-located. For example for pull we may want to prioritize peers as follows:  1) endorsers from same org  2) endorsers from other orgs  3) non-endorsers from same org  4) non-endorsers from other orgs"
Answer: 87030.0

User story: "Add subtopic in Developing Applications chapter for connection options"
Answer: 36691.0

User story: "The zap console encoder uses JSON to represent the key/value pairs in logging context. While this usually works, most humans expect to see a logfmt style encoding of key=value."
Answer: 135314.0

User story: "Add a topic on connection profile"
Answer: 31682.0

User story: "There is a lot of duplication of vars and setup in token/server/prover_test.go. Need to cleanup/refactor the tests to remove the duplication. "
Answer: 604669.0

User story: "comments in https://gerrit.hyperledger.org/r/#/c/27227/"
Answer: 604718.0

User story: "Currently PTE keeps running even if transactions fail due to underlying Fabric bug or due to any server side environment issue. There is no value in continuing the run when failures occur. Instead, it will help aborting the test and sending failure report to tester so a bug can be filed sooner than later.   # Add parameter for failure threshold. This could either be % failures or absolute threshold count for # of failed transactions.    2. Check failure threshold value and abort test when threshold is crossed i.e. failure count > threshold.   3. Save logs. This should include test client CPU, memory, disk and block chain network - peer, order and CA container - CPU, memory, disk utilization when threshold is crossed. test client stats required so we can isolate if it's client side issue or network side issue.   4. Generate report to show total transactions, total successful transaction, total failed transactions, test name, network id (applicable for IBP), type of network (IBP - starter, EP. or simple non-IBP, if it can be determined).         At a more basic level, pte should abort when return non-zero exit codes for each step failure (e.g. instantiation).         Related: add option to operator/testInput to allow testers to specify threshhold."
Answer: 619445.0

User story: "Two clients agree, out of band, on the terms of a swap. Using these terms, both clients first ask their prover peers to create atomic swap token transactions, which they then submit. After both transactions are successfully processed and committed, the tokens are atomically swapped."
Answer: 605168.0

User story: "Check that the peer can communicate with the configured CouchDB"
Answer: 85225.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "I have a channel with 900+ blocks on it. I am installing/instantiating new chaincode on this channel and the response time when instantiating is very slow as compared to a channel with > 100 blocks on it. Instantiating with 900+ blocks can take me 5+ minutes, whereas instantiating with > 100 blocks can take 5-10 seconds (normal response).           I would think block height wouldn't matter when instantiating new chaincode, but I have found this to be the case every time."
Answer: 621874.0

User story: "Gateway topic"
Answer: 30255.0

User story: "The following line is seen    Error: failed to import '/w/workspace/fabric-chaincode-node-verify-x86_64/gopath/src/[github.com/hyperledger/fabric-chaincode-node/fabric-shim/lib/protos/token/expectations.proto'|http://github.com/hyperledger/fabric-chaincode-node/fabric-shim/lib/protos/token/expectations.proto'] in 'peer/proposal.proto': file not found         In the node chaincode builds.         Believe this is connected to FAB-12787"
Answer: 1196.0

User story: "Currently the FabCar sample deploys to the basic-network, but this is not ideal as it is not really a realistic network configuration. It only has a single organisation, and a single peer, and it is not configured with TLS. There is also no tutorial explaining the basic-network configuration.    I plan to rebase the FabCar sample on first-network (aka BYFN). This is a much more realistic network configuration, as it has two organisations, and two peers, and it is configured with TLS. There is also a tutorial explaining the first-network configuration - Building Your First Network - that we can nicely link to from the FabCar tutorial Writing Your First Application."
Answer: 874294.0

User story: "The go runtime provides hooks for monitoring that need to be wired into the metrics subsystem of choice.    Memory: https://golang.org/pkg/runtime/#ReadMemStats  Go routines: https://golang.org/pkg/runtime/#NumGoroutine    Surfacing these metrics as gauges will provide some basic insight into the process characteristics. As the data can only be retrieved from polling, collection will need to be associated with a ticker.  "
Answer: 33359.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Chaincode developers should be able to check ACL policies inside their code to manage access to resources.    ACL validation could be done as soon as a request comes via Invoke or inside a particular function.  This feature is implementation/use-case agnostic.    This way, any consortium can use declared access policies to add a function-level control that allows to use certificate attributes to restrict certain user actions."
Answer: 211924.0

User story: "The fabcar sample should be updated to use the new programming model; this story will update both the Node.js sample applications, and the Node.js smart contract."
Answer: 164385.0

User story: Peer CLI errors out when using it to query chainless SysCC. There are two reasons for this error:   # Incorrect parsing of \{{peer chaincode query -C"" -n"qscc" -c ' {"Args": ["foo"]}'}}. Instead of taking {{-C}} as empty string, it sets channelID to {{-n}}     # Peer CLI requires {{-C}} to be non empty. This was introduced in commit: d2038953d, meant to address FAB-5604 (remove all instances of testchainid). The commit made -C a required parameter, but that prevents chainless SysCCs from being called.    I'm not sure what can be done about first problem. I tried digging up viper, but couldn't find much.
Answer: 84153.0

User story: "Wallet topic for developing apps documentation"
Answer: 26879.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: Hi,    maybe I'm wrong (using the wrong test set or wrong Jira Project) but the code on: [https://github.com/hyperledger/fabric/blob/master/core/handlers/validation/builtin/v13/lscc_validation_logic.go] and more specifically:  |// make sure that the signature policy is meaningful (only consists of ORs)|  |err := *validateSpOrConcat*(newCollection.MemberOrgsPolicy.GetSignaturePolicy().Rule)|  |if err != nil {|  |  return errors.WithMessage(err, fmt.Sprintf("collection-name: %s -- error in member org policy", collectionName))|  |}|  |}|  |return nil|  |}   |  | |  |// validateSpOrConcat checks if the supplied signature policy is just an OR-concatenation of identities|  |func *validateSpOrConcat*(sp *common.SignaturePolicy) error {|  |  if sp.GetNOutOf() == nil {|  |    return nil|  |  }|  |  // check if N == 1 (OR concatenation)|  |  *if* *sp.**GetNOutOf**().N !=* *1* *{*|  |    return errors.New(fmt.Sprintf("signature policy is not an OR concatenation, NOutOf %d", sp.GetNOutOf().N))|  |  }  imples that ONLY "1-of" policy will be accepted.  All the examples (Java/Node SDK or yaml/json) like those on: [https://github.com/hyperledger/fabric-sdk-java/tree/master/src/test/fixture/collectionProperties] do not work with the network (throw exceptions when sent to the peer) or provide a wrong information "1-of: # must be signed by at least one of these (OR) can *be 2-of for both (AND)*."  Assuming there is a collaboration between the core & SDK developer, could you please make sure that the examples are consistent with the core design (or the core design could log a statement that certain functionalities are NOT supported YET)?!  Best regards,  <USER>
Answer: 632953.0

User story: "Once a client receives a proposal response containing a token expectation, We need to do the following things:   # Allow the client to contact the prover peer to get a token transaction satisfying the token expectation;   # Allow the client to generate a transaction carrying the endorsement and the token transaction"
Answer: 560407.0

User story: "Once a client receives a proposal response containing a token expectation, the client needs to generate a token transaction that satisfies the expectation. We need to extend the prover peer capability to support the client needs."
Answer: 560411.0

User story: "A chaincode defines the business logic of an application running on a ledger. To allow a chaincode to interoperate with the token ecosystem, we need to allow the chaincode to request token operations.    On high level, we need the following actions:   # New protobuf messages for token operations requested by a chaincode   # A TokenStubInterface to allow the chaincode to set token operations.   # Set the token operations in the proposal response   # Update the chaincode execution path to propagate the token operations up to the endorser (bridge for 3.)"
Answer: 560423.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Capabilities are used to gate features and functions that impact a network of peers. We need to establish a capability name (and associated configuration support) to enable the *token-chaincode interoperation* features of fabric.    Acceptance: I can define the new capability in an config update transaction, submit it, and observe the peer can support the new capability."
Answer: 27.0

User story: "Convert fabric-sdk-node verify and merge job configuration to pipeline"
Answer: 142683.0

User story: "*IMPORTANT*: The design presented here was replaced by: https://jira.hyperledger.org/browse/FAB-15041    Goal:   * Migrate an existing kafka-based ordering service to a raft-based ordering service.   * Assumptions:   ** The migration is one way. Once migrated to etcd/raft it will not be possible to go back to kafka.   ** Downtime is allowed during the migration.   * Design & implement the mechanism in the orderer node   * Provide tools that automate the process   * Provide documentation and guidelines   * Design guideline   ** Make it simple and robust   ** Migration is all or nothing – if something fails in the middle, the system should be able to revert to a kafka-base functioning network.         As part of this story, we'll need to provide tooling and documentation (a very concrete set of steps) that will allow ordering service administrators to do this transition.    We want to gate this transition behind an Orderer & Channel capability.          See [High level design on Google Drive|https://docs.google.com/document/d/1sDSsehNR2vLf1cgZzsAjTCsoSyy0CpUg5rOb4YmXi00/edit?usp=sharing]    See [Detailed design on Google Drive (work in progress) |https://docs.google.com/document/d/1g_M8KO9cdbYMLBsscHd6ffv-X_ZRLeHvDcIEoV7YXUE/edit?usp=sharing]"
Answer: 301628.0

User story: More testing is needed in the area of Service Discovery using the different SDKs. This requires a network to configure to use service discovery and to call a SDK API that indicates that service discovery is in use. Then when 1 peer goes down, it should not cause errors when sending transactions on a channel.     Be sure to test within an organization and across organizations and with different sdks.     Note: there is an API that needs to be called that returns the list of available peers for service discovery.    Questions:   1. Is there a way to set the retry timeout for the clients such that we can verify that a "downed" peer returns an error and a "newly discovered" peer is successful?
Answer: 635238.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Currently, while chaincode-calling-chaincode is supported, the called chaincode doesn't know the identity of the calling chaincode. This prevents applications from developing ERC20-like features. Specifically, the applications cannot implement the {{tranferFrom()}} and {{approve()}} functions in case the addresses involved are those of smart contracts. In the Ethereum world, this is possible because smart contract accounts are not much different from user accounts. The same is not the case in Fabric.    In Fabric, chaincodes do have some form of identity, however. That is how one chaincode can call another chaincode - using its 'identity'. To solve the problem mentioned above, I propose that in chaincode-calling-chaincode scenarios, we make the caller chaincode information available to the callee chaincode, where the information can be some function of Channel and Chaincode Id.    While [this SO answer|https://stackoverflow.com/a/51808454] provides a partial solution, it requires extra work from the platform user and it doesn't handle the case where a complex chain of chaincodes invocation (e.g. C1 calling C2 calling C3)"
Answer: 637354.0

User story: "Use private data in balance transfer example."
Answer: 638603.0

User story: "fabric-ca has the ability to revoke certificates for a person as well as an organization. This ability needs to be added and tested."
Answer: 641455.0

User story: "In the Makefile, there needs to be a separate target for each repository that uses the interoperability tests.    interop-fabric should pull the latest versions of:   * fabric-sdk-java  * fabric-sdk-node  * fabric-chaincode-shim  * fabric-node-shim  * fabric-ca  The fabric-ca-peer and fabric-ca-orderer images should be built based on the git commit hash in the latest fabric-ca image.     interop-fabric-ca should pull the latest versions of:   * fabric-sdk-java  * fabric-sdk-node  * fabric-chaincode-shim  * fabric-node-shim  * fabric-peer  * fabric-orderer  The fabric-ca-peer and fabric-ca-orderer images should be built based on the git commit hash of the merged CR.     interop-fabric-sdk-node should pull the latest versions of:   * fabric-sdk-java  * fabric-chaincode-shim  * fabric-node-shim  * fabric-ca-peer  * fabric-ca-orderer    interop-fabric-sdk-java should pull the latest versions of:   * fabric-sdk-node  * fabric-chaincode-shim  * fabric-node-shim  * fabric-ca-peer  * fabric-ca-orderer  "
Answer: 57216.0

User story: "There is a new log level variable and configuration setup. The test tools need to reflect using this new config value."
Answer: 65.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "I find a corner case during writing complex system with multiple chaincode and cross chaincode calling    Environments   - set individual couchdb(as docker container) for each peer (as docker container)   - org ASTRI.org, has 1 peer, `peer0.ASTRI.org`   - org icdd, has 1 peer, `peer0.icdd`   - we have 3 golang smartContract, all 3 are installed on each peer,   - chaincode：mainCC   ** `chaincodePath`: [https://github.com/<USER>chaincode/tree/master/golang/mainChain]   - chaincode：sideCC   ** `chaincodePath`: [https://github.com/<USER>chaincode/tree/master/golang/sideChain]   - chaincode：sideCC2   ** `chaincodePath`: [https://github.com/<USER>chaincode/tree/master/golang/sideChain2|https://github.com/<USER>chaincode/tree/master/golang/sideChain2]     - instantiate： both `peer0.ASTRI.org` and `peer0.icdd` are target peers   - all parts are under 1 channel `allchannel`    How to reproduce   * follow README in my own fabric-sdk-node based project   ** [https://github.com/<USER>delphi-fabric]   * Or if a fabric network exist, please choose your own way to do that   ## invoke chaincode `sideCC` with   *** fcn: 'put'   *** target peers: [`peer0.ASTRI.org`]   ## Get the response of invoke as `key`   ## invoke chaincode `sideCC2` with   ### fcn: 'get'   ### target peers: [`peer0.icdd`]   ### args: [key]     the txEvent after the second invoke will prompt with code 'MVCC_READ_CONFLICT'         More details   * What those chaincode do   ## mainCC: simple key-value setter, getter   *** fcn=='put': setter   *** fcn=='get': putter   ## sideCC: when invoked with fcn=='put',   ###   generate a new key not exist in mainCC   #### randomly generate a new string `rKey`   #### use stub.InvokeChaincode to call mainCC with fcn='get', args=[rkey]   #### if non-empty response from mainCC, recurse the process; other wise, return the `rKey`.   ### use stub.InvokeChaincode to call mainCC with fcn='put', args=[rkey,${anything}]   ## sideCC2: when invoked with fcn=='get', use stub.InvokeChaincode to call mainCC with fcn='get', args=[params[0]]     * timing: after half a second passed, we could retry the the second invoke and get a success   * couchdb exclusive: this error will not appear when we use default leveldb for all peers"
Answer: 648884.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "A new sample should focus on good application practices, such that Fabric application developers can use it as an example and starting point for their own applications.    The new sample should:   * utilize Service Discovery with preferred orgs/peers configured.  For example if endorsement requires two orgs, the application may want to utilize one random peer from it's own organization, and one random peer from any other org (see FABN-982 for related SDK service discovery improvements).  The 'randomness' ensures load balancing across peers. Additionally it should be possible to specify exact endorser organizations, for example state-based endorsement scenarios will require this.   * Do proposal retries for certain proposal failures like gRPC errors. Chaincode errors may or may not benefit from a retry, depending on the problem. (see FABN-984 for SDK retry improvements).   * Check that all proposal responses are consistent before submitting transaction to orderer (and if not consistent, request another proposal and throw out the 'bad' proposal response).   * Use channel events to ensure submitted transactions are validated   * Do transaction retries for invalidated transactions (such as upon MVCC_READ_CONFLICT invalidations)   * Reuse channels, channel event hub registrations, etc instead of obtaining a new one for each transaction.    The new sample should not:   * have extra layers on top which will only distract sample consumers (REST APIs, UI)."
Answer: 931587.0

User story: "There are some intermittent timing failures in CI when starting kafka and chaincode containers. When this occurs, it would help in the debugging process to see what containers are running."
Answer: 78124.0

User story: "We need to use configtxlator from a web browser... and configtxlator runs from a different domain than the UI...         We need to be able to setup configtxlator with CORS to allow    # specific the application domain   # allow wildcard domains"
Answer: 34743.0

User story: "This item requires extending the MSP configuration to accept an OU specification for orderers in the system. So far, we offer this configuration ability only for peers and clients."
Answer: 429758.0

User story: "The purpose is to generate TLS certificates for chaincode on local machine, in orderer to g{color:#172b4d}enerate chaincode tls certs, need to set chaincode name and version, but how, the easy way is to set in core.yaml. If we put chaincode in different machine, we need to set TLS, just for safety.{color}"
Answer: 653526.0

User story: "Committing peer logic needs to be enhanced to be able to process combined transactions (i.e., transactions containing an endorsed and token action) with a token action corresponding to a TransferFrom action. Notice that components of FAB-11965 need to be extended."
Answer: 655890.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Prover peer component developed in FAB-11965 should be extended to support computation of a TokenTransaction that contains an indirect TransferFrom request. Notice that in this case Approve requests may need to be extended to allow for delegating the spending of a token to a chaincode."
Answer: 655892.0

User story: "This refers to the extension of the committing peer logic to be able to process combined transactions (i.e., transactions containing endorsement and token actions) that would contain an Approve token action. "
Answer: 655894.0

User story: "This refers to the extension of the components developed within FAB-11965 to allow the prover peer to compute a Token Action using an expectation corresponding to an Approve request. "
Answer: 655895.0

User story: "This refers to the extension of client wallet library to support the creation (through contacting the prover peer) and submission (through transaction submitter) of a TransferFrom token transaction."
Answer: 642497.0

User story: "This refers to the extension of client wallet library to support the creation (through contacting the prover peer) and submission (through transaction submitter) of an Approve token transaction."
Answer: 642498.0

User story: "Put the JSONSchema for the meta data to a known location.     Suggest that this should be within the JSDoc for the chaincode"
Answer: 63356.0

User story: "This refers to an extension to client wallet library to allow for a query to be submitted on the prover peer on the status of a given swap."
Answer: 657286.0

User story: "Extension to the client wallet library to accommodate atomic swap transaction creation requests."
Answer: 657287.0

User story: "Here the prover peer is able to accommodate queries on the status of a given swap.    If according to the ledger, the swap status is PENDING, the response should contain the swap description, which terms have been addressed, which terms have not been addressed.    If according to the ledger, the swap has been abandoned, nothing else needs to be returned."
Answer: 657289.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "h3. This is fix and improvement of the scripts of fabric-ca in fabric-samples.     * h4. 1st Issue : When running start.sh again,  it fails to remove data directory.  {code:java}  $ ./start.sh  ...  $ ./stop.sh  ...  $ ./start.sh  ##### 2018-10-23 14:19:21 Cleaning up the data directory from previous run at ./data  rm: cannot remove './data/tls/peer2-org1-cli-client.key': Permission denied  rm: cannot remove './data/tls/peer1-org1-client.crt': Permission denied  rm: cannot remove './data/tls/peer2-org2-client.crt': Permission denied  rm: cannot remove './data/tls/peer2-org1-cli-client.crt': Permission denied  rm: cannot remove './data/tls/peer1-org1-cli-client.crt': Permission denied  rm: cannot remove './data/tls/peer2-org1-client.key': Permission denied  rm: cannot remove './data/tls/peer1-org2-cli-client.key': Permission denied  rm: cannot remove './data/tls/peer1-org2-client.crt': Permission denied  rm: cannot remove './data/tls/peer1-org1-client.key': Permission denied  rm: cannot remove './data/tls/peer2-org2-cli-client.key': Permission denied  rm: cannot remove './data/tls/peer2-org2-client.key': Permission denied  rm: cannot remove './data/tls/peer1-org2-client.key': Permission denied  rm: cannot remove './data/tls/peer1-org2-cli-client.crt': Permission denied  rm: cannot remove './data/tls/peer1-org1-cli-client.key': Permission denied  rm: cannot remove './data/tls/peer2-org2-cli-client.crt': Permission denied  rm: cannot remove './data/tls/peer2-org1-client.crt': Permission denied  rm: cannot remove './data/orgs': Permission denied  {code}   ** Reason   *** After running 'start.sh' the permission of the directory, './data',  is 'root:root' in a user's host.     *** Docker is usually using root's account. If a docker container makes some files, their ownership will be root, especially in shared volumes.   ** Way round of avoiding the problem.   *** a user must have to command 'sudo rm -rf data' in order to remove the dir.   *** in start.sh script, use 'sudo rm -rf data', instead of 'rm -rf data'   **** a user has to type the password, but it's not sophisticated.   **  Suggestion (TODO)   *** In the stage of preparing the docker containers in the script 'start.sh', add a new file '.host_env' into './data' directory, which is shared volume between the host and the containers.  '.host_evn' file should be filled with host's user-id-number and group-id-number.   *** In the stage of finishing test through docker's container, the whole files in './data' directory ownership should be changed to the host's one through saved '.host_env' file.     * h4. 2nd Issue: Jenkins test case does NOT cover the restarting situation.   ** Suggestion (TODO)   *** After solving the 1st issue, a stopping and re-starting part should be also included into Jenkins test case.     "
Answer: 109580.0

User story: "Generate TLS certificates for chaincode on local machine, also support windows"
Answer: 658840.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Given a system channel config block, we need a mechanism that:   * Figures out the channels the cluster node participates in   * Reaches out to the existing orderer nodes in these channels, and pulls the blocks.    First, we need to implement functionality that pulls blocks from a Raft node. (This will also be used to pull blocks from an OSN for snapshots.) Ideally, the functionality would figure out the heights of all orderer nodes: i.e - h0, h1, h2, h3 and then connect to a random one, but one that has the needed blocks. This ensures that we don't always connect to the leader, but also that we don't connect to an OSN that is too far behind and it might be one that is catching up on its own. In addition, we need to add block verification functionality in this client, and optionally use backward hash validation in chunks - pull some blocks up to a maximum configurable size (say, 10MB by default) and then verify the last block's signature and verify the rest via looking in the previous hash.    Then, the synchronization component will work as follows. Given a config block with a number *N*, the component is going to:   * Pull the entire system chain starting from genesis, and ending in block *N*, and do hash chain validation during pulling, and make sure the given bootstrapping block *N* has a prev hash that is equal to the pulled block of *N-1* , and so on, down to the genesis block.   * During that pull, all channel names are going to be collected and returned.   * For each channel, we're going to connect to all orderer endpoints that are in the system channel in parallel, in order to find some orderer that services that channel. That orderer is going to be used to pull blocks from genesis, up to the last block.   * Now that we know which orderer endpoints service the channels, we're going to iteratively (for each channel) - pull the chain and commit the blocks in the ledger.   * Finally, the system channel itself is going to be pulled (once again!), and it would be committed up to the last block."
Answer: 132590.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: There are a few items that need to be done when branching fabric-test to v1.3.   * update the PTE version in the following files (may be done before branching):   ** tools/ATD/vars/1channel.yml (tag: "1.3.0")   ** tools/ATD/vars/FAB12135.yml (tag: "1.3.0")   * change .gitmodules  ** add "branch = release-1.3" to each of the repos *minus* cello (until cello releases supporting versions)  * change Makefile  ** "git-latest" target needs to explicitly pull from the set branch  ** fabric replace "master" with "release-1.3"  ** ca replace "master" with "release-1.3"  ** fabric-chaincode-java replace "master" with "release-1.3"  ** (Once we are pulling images successfully for the test runs, we also need to ensure that pullDockerImages.sh pulls the correct images from dockerhub)  * feature/package.json  ** change "unstable" to "1.3.0"  * tools/PTE/package.json  ** change "unstable" to "1.3.0"  * tools/PTE/README.md  ** change "master" to "1.3.0"  * tools/PTE/CITest/README.md  ** change "master" to "1.3.0"
Answer: 109553.0

User story: "The Step() in the cluster is invoked very frequently, and is spamming the logs.    We should use a different module and a different logger instance."
Answer: 629.0

User story: "Currently, orderers pull blocks and only verify the standard signatures on the blocks and the previous hashes, and data hashes.    However - the last config block signatures that were added late, should be validated on their own if:   * We want orderers and peers to use them.   * We are in a byzantine environment and orderer outputs aren't trusted by default.         [~<USER>"
Answer: 665216.0

User story: "A general purpose smart contract will be useful for most projects. Such a smart contract will enable application developers to easily integrate their application to Hyperledger Fabric.    I've written a general purpose smart contract than can store any key-value to either LevelDB or CouchDB. The idea is to pass the value as a JSON object and insert it to the ledger so that rich queries can be run.    An example with PutState()    User's application provides a key and a value in JSON, and the smart contract unmarshals and then marshals the value before calling shim's PutState() method. This makes the value field to appear in the CouchDB document as a valid JSON object.    So, the user's application can run native CouchDB queries on his data.    I've also added built-in support for Statsd reporting using the same go library as used in Fabric. Each call to GetState(), PutState() etc are counted and reported to the given statsd server.    Please find attached my implementation of general purpose smart contract.    Regards,    // Gokhan   "
Answer: 665841.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "Currently the peer while executing peer session during integration tests it's only possible to setup environment for peers organizations users. However for certain operation it's required to be able to operate under MSP of ordering service users organization.    For example if need to update orderer related configuration updates, default policy requires signature of the orderer admin user."
Answer: 2832.0

User story: When Fabric builds a docker chaincode container it may need internet access. For example if the chaincode is Node.js or a Composer BNA file an npm install is necessary.    Some provisioning environments require *network mode 'host'* to be set in the docker build container to enable external network connectivity.    We found the following code to create the build container does not set or allow to be set the HostConfig option: [https://github.com/hyperledger/fabric/blob/ce1bd7286ed0c1915dc9020182d8e9ad5a9959de/core/chaincode/platforms/util/utils.go#L144]    In our testing we found a simple modification to this function fixed the problem, for example:          *{color:#00875a}hostConfig := docker.HostConfig\{NetworkMode: "host"}{color}*    {color:#00875a}{{//------------------------------------------------------}}{color}    {color:#00875a}{{// Create an ephemeral container, armed with our Env/Cmd }}{color}    {color:#00875a}{{//------------------------------------------------------}}{color}    {color:#00875a}{{ container, err := client.CreateContainer(docker.CreateContainerOptions{}}{color}    {color:#00875a}{{ Config: &docker.Config{}}{{ }}{color}    {color:#00875a}{{Image:        opts.Image,}}{{ }}{color}    {color:#00875a}{{Env:          opts.Env,}}{{ }}{color}    {color:#00875a}{{Cmd:          []string\{"/bin/sh", "-c", opts.Cmd},}}{{ }}{color}    {color:#00875a}{{AttachStdout: true,}}{{ }}{color}    {color:#00875a}{{AttachStderr: true, },}}{{ }}{color}    *{color:#00875a}{{HostConfig: &hostConfig,}}{color}*    {color:#00875a}{{ })}}{color}         A more comprehensive solution is probably needed that allows existing env vars to override these parameters and are used in other parts of fabric, for example:    CORE_VM_DOCKER_HOSTCONFIG_NETWORKMODE=host
Answer: 668721.0

User story: "In this item, we aim to enhance the processing capability of committing peers in token transactions with accommodating TransferFrom token transactions.    Here the owner or the delegator of a set of coins can essentially transfer a few of these tokens to one or more other users. Committing peers should ensure that the transaction creator has permissions to move these tokens and that these tokens have not been spent already. Last but not least, the committing peer would update the state of the ledger to consider the new owners for the tokens to be transferred and the old ones for the change. "
Answer: 655480.0
give resolution time in minutes for the given user story, only provide the number of minutes in the output without any other text

User story: "In this item, we aim to enhance the processing capability of committing peers in token transactions with accommodating Approve token transactions.    Here the owner of a set of coins can essentially delegate the use of a few of its tokens to one or more other users. Committing peers should ensure that the tokens to be delegated have not been spent so far, and that the transaction creator is indeed their owner. Last but not least, the committing peer would update the state of the ledger to consider the new owners for the tokens to be delegated."
Answer: 655484.0

User story: "In this item we want to enhance the prover peer with the ability to recognise and respond to TransferFrom proof computation requests from a simulated client."
Answer: 595178.0

User story: In this item we want to enhance the prover peer service to accommodate requests for computation of "approve" proofs. 
Answer: 655493.0

User story: "To endorse a transaction, an endorser mentions its identity along with the  signature so that it can be verified. However, for certain transactions, difference in  opinion may exist among endorsers. Disclosure of identity of endorser may lead to  conflict within the consortium. In such cases, an endorsement policy which allows an  endorser to support a transaction discreetly but simultaneously takes into account  the decision of the majority is preferred. As a solution, we propose an Anonymous  Endorsement System which uses a threshold endorsement policy. For hiding the identity  of endorsers, a new ring signature scheme, called Fabric’s Constant-Sized Linkable  Ring Signature (FCsLRS) with Transaction-Oriented linkability has been proposed. The code for the algorithm proposed is written in Golang and a performance analysis has also been done.    So the following are the contributions made in this work :    1. We have proposed an Anonymous Endorsement System which implements a  simple threshold endorsement policy which requires at least t out of n endorsers  to approve of the transaction without explicitly mentioning their identity.    2. We have given the construction of a constant sized linkable ring signature  scheme, Fabric’s Constant-Sized Linkable Ring Signature (FCsLRS), to hide  the identity of an endorser.    3.A new linking criterion, called as “transaction-oriented” linkability, is used  which prevents an endorser from signing same transaction more than once.    4. We have implemented this scheme in Golang and analysed its performance.    5. A detailed description of the integration of the scheme with existing framework  of Hyperledger Fabric has been discussed.    This is a part of my thesis work - Link http://library.isical.ac.in:8080/jspui/bitstream/123456789/6956/1/Diss-390.pdf    Presentation : https://drive.google.com/file/d/1D9YoGXZSb0yyzt9UZVnRnWjHY_5jAYTN/view?usp=drive_open"
Answer: 669094.0