what will be the solution to this? is there an inbuilt logic for this kind of privacy?

Consider a bidding platform of 4 organizations where org1 publishes an item and org 2,3 and 4 bid for it(in dollars). 
and then there is a chaincode that checks the bids and compare them and declares the winner bidder (one with the highest bid) to make the platform decentralized we make all the three organizations as endorser peers so that each peer is able to see what others have bid.

the problem is that: in a particular scenario being an endorser peer org2 can see the bid of org3 and then increase it’s bid accordingly

what can I do to make the platform decentralized while avoiding this scenario and keeping the system realtime(<50ms)? something like: the organizations are only able to see each others bids only after the winner is 
declared

If you don't have a 3rd party coordinating the auction, you can have the seller drive the auction as follows...

- Seller invokes chaincode to start the auction (on sufficient number of peers to meet chaincode endorsement policy).
- Bidders each write their bid (with a salt) in their own private data collection, a hash of the private bid will automatically get written to the channel's ledger for all to see.
- Seller ends the auction by invoking chaincode (on sufficient number of peers to meet chaincode endorsement policy) that captures the various hashes using GetPrivateDataHash() API (so that bids can't get changed after the auction).
- The bidders then each write their actual bid on the channel's public ledger. If getting sufficient endorsements is a concern, the seller could pre-allocate keys for each of the bidders with each key governed by state-based endorsement requiring only the respective bidder to endorse.
- Finally, seller invokes chaincode (on sufficient number of peers to meet chaincode endorsement policy) that queries for highest public bid and marks it as the winner. The chaincode should also verify that a hash of the winning public bid matches the submitter's original hashed bid (again using GetPrivateDataHash() API, or comparing with the hashes captured in above step).

Other variants of this pattern can be used depending on the specific requirements. For example, if you don't want the bids to ever become public:
- The bidders can write their bids to the seller's private data collection instead of the public channel ledger (either during the auction, or after the auction if you want to keep the bids private from even the seller during the auction).
- At the end of the auction, the seller queries their peer's private data collection for highest private bid.
- Seller then invokes chaincode to close the auction (on sufficient number of peers to meet chaincode endorsement policy). Seller passes in the hash of the winning bid, the chaincode verifies that the hash of the winning private bid matches the submitter's original hashed bid (again using GetPrivateDataHash() API), and then marks the bid as the winner.

Note that as of Fabric v2.0, an endorsement policy can be specified on a private data collection to override the chaincode endorsement policy (e.g. writing to an org's private data collection may only require that the respective org endorse it). This simplifies some of the more complex state-based endorsement solutions that were required in Fabric v1.x to achieve similar result.

The ideas above are essentially a specific application of the general private data patterns that are documented here: https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html#sharing-private-data.


Dave Enyeart

yashukla47---01/15/2020 06:10:14 AM---what will be the solution to this? is there an inbuilt logic for this kind of privacy? Consider a bi

From: yashukla47@...
To: fabric@...
Date: 01/15/2020 06:10 AM
Subject: [EXTERNAL] [Hyperledger Fabric] #fabric-questions #hyperledger-fabric
Sent by: fabric@...

what will be the solution to this? is there an inbuilt logic for this kind of privacy?

Consider a bidding platform of 4 organizations where org1 publishes an item and org 2,3 and 4 bid for it(in dollars). 
and then there is a chaincode that checks the bids and compare them and declares the winner bidder (one with the highest bid) to make the platform decentralized we make all the three organizations as endorser peers so that each peer is able to see what others have bid.

the problem is that: in a particular scenario being an endorser peer org2 can see the bid of org3 and then increase it’s bid accordingly

what can I do to make the platform decentralized while avoiding this scenario and keeping the system realtime(<50ms)? something like: the organizations are only able to see each others bids only after the winner is 
declared