Quote from: MadCow on April 05, 2016, 12:58:04 AM

Thanks, it would be good to compile a list of data feed providers to make it easier for people to decide

Having a list is not enough. You need to assess the data feed provider; this is crucial. You need to make sure he/she configures the votes after your fancy.
If you register a feed from a provider who doesn't vote like you'd vote (or at least very often close to it) if you'd configure the votes manually, you might be better off, stopping the minting.
That theoretically harms the security of the network, because it reduces the part of the shares that are minting.
The alternative - having votes that lead (from your perspective) in the wrong direction - can be dangerous (for your interest) as well.
That's what I mean when saying there comes a responsibility with owning shares of a corporation, especially if you are able to vote directly and make decisions; like the protocol update:

Quote from: BCExchange on April 05, 2016, 04:12:28 AM

We have reached 42.85% of protocol votes for version 4.0. All shareholders must upgrade to version 4.0 immediately. The protocol switch date will be two weeks after 90% of blocks are minted with 4.0.0 or 4.0.1.

The protocol switch can only happen, if the vast majority of (active!) minters have switched to 4.0.0 or 4.0.1!

Selecting a data feed provider requires finding out, what side takes in discussions and what are the arguments of the provider.
It's pretty much like trying to find out about whether you want to elect a specific politician:
try to find out what he/she says (here: forum discussions) and what he/she does (here: data feeds; are the aligned with the discussions?)!
You can look for data feed providers here:
https://discuss.nubits.com/c/b-c-exchange

Regarding asset voting (that will be able once the protocol switch is complete), from:
https://discuss.nubits.com/t/configure-your-votes-when-minting/3729/16

Quote from: JordanLee, post:16, topic:3729, full:true

There a number of facts shareholders should know (unless they are using data feeds) regarding configuring asset voting.

For the maxtrade value, bear in mind that it won't really matter until the 5.0 version is released. Let me explain a little about the development process as I see it from now until just past release of 5.0, which will explain my suggested maxtrade value. Right now most messages can be sent, but their processing isn't implemented. We will work on that and as we do, we will begin see the exchange function in the context of a few narrow and limited use cases. Because the exchange will be incomplete, it stands to reason there will be plenty of ways to exploit the solution in its incomplete form. That is fine, because we are on test net and it is just part of the process. Eventually, we will get to where we have provided for all the use cases and no known major or high risk exploits are possible. This will be the time to move the solution to production, but we wouldn't want to do so with high max trade values. We want to start it with very low max trade sizes, so it can be tested without risk of loss of substantial funds. A good place to start would be around 1 USD. Once the exchange performs well with that limit, it can be raised incrementally at whatever pace seems appropriate at the time.

In regard to required signers and total signers, please remember that the protocol requires two backup signers to validate orders. This means 2 of 3 multisig cannot meet B&C protocol. The protocol can be changed (this hasn't even been coded yet), but doing so increases risk. I recommend we not do that. 2 of 4 is the minimum number of signers to be protocol compliant. If 2 of 4 is used, and a single signer is unavailable, no orders with the involved funds can placed. The funds wouldn't be lost because they can still be withdrawn without backup signers, however. I suggest 3 of 6 as a minimum number of required and total signers. More total signers and more required signers, such as 8 of 15, provide much better decentralisation but somewhat higher costs for transaction fees and signer compensation. My recommendation for a starting point is 3 of 6: 3 required signers and 6 total signers. I hope we move to 8 of 15 soon.

Also bear in mind that once an asset has been successfully voted in, you don't need to keep voting for it with its maxtrade value and so forth, unless you want to change one of the values from its current setting. If you don't vote, then your vote is counted as a vote for the status quo. So, if the current number of required Bitcoin signers is 3, if I vote for 3, it just wastes blockchain space. An abstention will be interpreted as a 3 by protocol. If you wanted to change it to 5, then you should include it in your vote. This notion of an abstention being counted as a vote for the current network setting applies to most things that can be voted for within B&C Exchange.