How to implement decentralization + trust in the following scenario 

An organization A wants to set up a Hyperledger network using which organizations 1,2 and 3 can transact which each other in a decentralized way with trust and company A wants to charge a commission on what every "value" transaction that takes place between the three organization. and only company A should be allowed to add and remove an organization basically company owns the network but it is decentralized and can be trusted by organizations 1,2,3.

 

So what should be the configuration of the network to implement this scenario? i.e

1) What role should the organization A have? what should the organization A need to have to own the network?
2) Who all should be made the endorser, root CA, MSP, etc?
3) (main doubt) what should be the config for the ordering service? who all should participate in it?
4) If later on more new organizations join the network and form new channels then will there be any change in the architecture?
5) Would org A have to be part of every channel to keep a monitor on the transactions in order to charge the commission?

Last but the main question- is it possible that a 3rd party organization makes and owns a network and charges commission at the same time keeping it decentralized and trusted for the participant organizations.

This has gone without a reply since it was posted so I thought I would add one,

It's terrific to see this energy for expanding the global footprint for Fabric! And for taking such a well researched and thoughtful approach to figuring out how to support the needs of translators efficiently. And your recommendations on bold at the bottom make sense for me. Thank you for writing up the recommendations and the rationale, that is valuable for future teams looking at this. An additional repo makes a ton of sense. I am sure here are good techniques to correlate updates to core docs to a need for updating their translated equivalents.

So far, the TSC seems like it has been happy leaving these questions up to individual projects rather than setting a site-wide standard. But the TSC and others in the community might still want to weigh in on this, and if it looks good, consider adopting it as a common standard across projects, so that it's even easier for volunteers for translations on any project to know how and where to plug in.

One last question: would it make sense for translation bundles for in-app localizations to be done in this -i18n repo, or to be done in the main code repo? I'm guessing the former so that a distribution can easily bundle them all together, and they change much less frequently, but I believe they are as important as translated docs (for projects that use them) to highlight to volunteers.

Again, thanks!

Brian

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Hello!

We will continue our documentation workgroup calls this Friday, both Western and Eastern hemispheres.  A big welcome to everyone - we had a great turn out last week - thanks to everyone who attended!

You can read the summary minutes for last week's meeting: https://wiki.hyperledger.org/display/fabric/Meetings

This call really had a lot of content, with a fabulous IOT demo from Chris, super Commercial paper updates from Matthew, exploiting Nick new test network, and Pam bringing us up to date on Rich Zhao's Chinese excellent language doc work. You can catch up via the recording: https://wiki.hyperledger.org/display/fabric/Recordings

You'll see that there are lots of interesting items for this week: https://wiki.hyperledger.org/display/fabric/2020+01+17+DWG+Agenda
Please feel free to contribute using the wiki!

You can also help build next week's agenda: https://wiki.hyperledger.org/display/fabric/2020+01+24+DWG+Agenda

Really looking forward to more great work on Fabric documentation in 2020!

Pam, Anthony,  Joe, Nik

Meeting Details
-------------
Please use the following link to attend the meeting:  https://zoom.us/j/6223336701

The meeting times are as follows: https://wiki.hyperledger.org/display/fabric/Documentation+Working+Group

Meeting 111A: Friday 17 Jan
                    1130 India Standard Time
                   1400 China Standard Time
                   1500 Japan Standard Time
                   1700 Australia Eastern Time
                   1400 Singapore Time
                   1000 Gulf Standard Time
                   0900 Moscow Standard Time
                   0600 Greenwich Mean Time
                   0700 Central European Time    

Meeting 111B: Friday 17 Jan
              1000 Central Daylight Time
                   1100 Eastern Daylight Time
                   0800 Pacific Daylight Time
                   1300 Brasil Time (BRT)
                   1600 Greenwich Mean Time
                   1700 Central European Time
                   1800 Moscow Standard Time

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



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

Hi All,

If we want to process/upload file's like PDF(1millions of the pdf file) in Hyperledger Fabric, How can we store them there is a storage issue right

Can anyone know how to process millions of pdf file in Hyperledger Fabric

Thanks
Suresh

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

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

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

• Add a new maintainers team to the Fabric repository - `Documentation Maintainers` where membership to this group is managed by the Linux Foundation.
• Configure a mergify bot such that after:
1. The documentation PR is approved by a Documentation Maintainer using the normal "Review changes" pane,  and 
2. The Documentation Maintainer adds the label `doc-approve` to a documentation PR.

•  Then, the mergify bot runs and the content is merged. 

• Because the traditional "Merge" button will be disabled for Documentation Maintainers, they have to add the `doc-approve` label to trigger the bot merge. 
• Non-documentation Maintainers can still continue to the use the merge button to merge documentation PRs as per usual.
• The bot is configured such that Documentation Maintainers are restricted to merging PRs under the /docs folder.
• For adding or removing documentation maintainers, we can add a 'Documentation Maintainers' table to MAINTAINERS.md. 
• Then, submit a PR against that table, collect the votes, and merge.
• Someone from the Linux Foundation updates the team definition per the table.

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

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

Yes, see the getStateByPartialCompositeKey sample here:
https://github.com/hyperledger/fabric-samples/blob/release-1.4/chaincode/marbles02/node/marbles_chaincode.js#L243-L295


Dave Enyeart

"Kimheng SOK" ---01/13/2020 12:27:00 PM---Dear all, Is there any documentation example of how to use

From: "Kimheng SOK" <sok.kimheng@...>
To: hyperledger-fabric@...
Date: 01/13/2020 12:27 PM
Subject: [EXTERNAL] [Hyperledger Fabric] Chaincode nodejs getStateByPartialCompositeKey
Sent by: fabric@...

---

Dear all,

Is there any documentation example of how to use getStateByPartialCompositeKey in nodejs chaincode to query the data from the object list and iterate through it to view all the result. 

Thank for help.

Bests,

--