Configure your votes when minting!

Continuing the discussion from [Mandatory Upgrade] All minters need to upgrade to B&C Exchange 4.0.1:

After having upgraded to 4.0.1 you might consider configuring votes.
It’s like is is ever since the beginning of Nu: if you mint and don’t vote for something, you essentially vote against everything!

So take your time and at least configure some assets you want to see traded on BCE.
Signers are not yet available (not by BKS address), so “reputation vote” won’t work and the rest is not that important at the moment.
But at least the “asset vote” should be configured.

If you have no better idea, please start discussing this proposal:

Every asset has a maxtrade value of close to $1,000.
I don’t know what happens, if people vote for different maxtrade and mintrade values.
I have no idea, what happens, if people vote for different regsigners or totalsigners values.

Let’s give it a start with my proposal that is built on knowing as much as Jon Snow.


what’s unitexponent?

I think mintrades should be higher, at least 0.01 BKC for example. I’d more prefer something like min = 1, max = 5,000 to start off.

why not 3 of 5? I think we have enough signers for it.

BTC should do just 2 confirmations. The rest are ok.

I’d prefer a 0.1 BKC fee, but that’s just my opinion.


Oh, I just clicked through the available options without much thought.
The only thing that caught my eye was the maxtrade, which is “1” per default and I thought that really is low :wink:
I like your suggestions! :smiley:

I make the OP a wiki post and see what happens…
Maybe there are even more suggestions.
It might not hurt to try finding a common ground. If that doesn’t work for some, every BKS holder can still vote after his/her fancy.

Don’t forget the Bitcointalk thread. I’m not sure how many shareholders we have over there and whether they visit our forum or not.

Good point. I made a reference there.

I follow MoDs proposals. We have to start from somewhere.
I am thinking to vote for some other coins i like :wink:
Can we discuss a little about “confirmations”? How can we calculate that?

1 Like

By now they are @Nagalim’s proposals (the wiki!)…

You need enough confirmations to have a low risk of losing funds due to forks, which could be used for double spends.
I don’t know how to calculate the risk for a fork that goes x blocks deep in a certain blockchain.
Historic information about forks (and their depth!) might help a little bit.


Ppc being 6 is client standard. 15 for Nu and B&C is because the blocks come so fast. 6 for ltc is cause i felt like it. 2 for btc is just to make absolutely sure we’re not on a fork.

Some networks are more trustworthy than others. A network like btc will be used a lot on our exchange and it’s reasonable to have a lot of confidence in just a couple confirmations, as opposed to a network like ltc.


I took the initiative and vote also for:

with 12 confirmations each
we can discuss the confirmations later
I am thinking also to add maidsafe,storj and factom but since all of these are depending on BTC’s blockchain,
i am not sure how easy it will be to set them up for B&C.


I’m sure the B&C Exchange developers will eventually have a more concrete proposal, but it’s quite likely the early days of the exchange will have very low trading limits. This will be done to make sure that user losses are limited to token amounts in the event of an unforeseen bug.

1 Like

Have been thinking about this: That would potentially significantly increase the transaction times while still having security at cost. It looks like a signer could pull this off as a service instead of needing B&C protocol support. One issue might be that once we have voted for 2 confirmation for Bitcoin this option most likely won’t work based on Jordan’s last answer regarding different caps for one coin. This appears not to be possible (yet?).

Can you offer your proposal as a unsigned data feed? It’s pretty easy with github.

Not sure what you are after? Why unsigned? I have already a data feed setup. Used it to support the first B&C motion. Just need to do some testing as soon as the protocol changes are approved.

1 Like

I’ve been signed up under your feed since the beginning, just so you know people do use it.

1 Like

Updated my feeds here based on some of the suggestions from this thread.

1 Like

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.


Do we need to continuously vote for signers? Because the protocol checks the signers voting within last 2000 blocks.

1 Like

I believe so, since a signer’s behavior is a “real time asset” :wink:
I will then update my asset voting after JL’s suggestions.

1 Like

Not really. If you don’t vote for signers, it won’t have any negative impact, unlike with motions and grants. However, reputation voting is intended to be perpetual. I expect most shareholders will continuously vote on that. Do it if you want to change signers’ rewards, otherwise you can leave it alone and let others decide.


So the “latest 2000 blocks” are the blocks with signer votes.