B&C signer voting watch

[Sabreiib]

You can use the getsignerrewardvotes RPC. It gives detailed results about the votes including the number of blocks who have not entered a value (“vote” : null) for both the number of rewarded signers and the amount of the reward. Here’s the current result:

Let’s vote for 6 eligible signers because only “6” has the potential to replace “4” in short time, although I like “1000”.

[jooize]

Wouldn’t shareholder takeover of top signers be something that can be detected while it’s happening if it becomes a problem?

Say we establish a sufficient amount of trusted signers with a few untrusted ones. How long would it take a majority shareholder to vote enough new signer identities to the top in order to begin stealing trades?

Is it possible to detect malicious signing and abort further trades?

If we build in a safety mechanism that triggers when signers are rapidly replaced?

Could traders get to choose which signers they trust?

[Sabreiib]

So I suggest many rooms where different groups signers may be selected by customers, competition will drive out corruption.

[mhps]

Could traders get to choose which signers they trust?

I think that is part of the design of B&C.

[jooize]

So I suggest many rooms where different groups signers may be selected by customers, competition will drive out corruption.

Ahh, thanks for summarising your idea. How would rooms be created? Are rooms basically preset preferences for traders? Can traders also cherry-pick signers?

I think that is part of the design of B&C.

I am under the impression that shareholders select signers that traders automatically use. Is this incorrect?

---

How much complexity is added by the room idea? Perhaps warranted, but I have not understood why it’s necessary. What are the main concerns?

I remain curious about the following, as it should function as an immediate emergency halt making the most an attacker can get away with be one trade.

Is it possible to detect malicious signing and abort further trades?

The trader publishes what it wants to happen, and if that isn’t what happens, clients should be able to detect that and cancel all trades.

It’s likely I don’t understand how BCE functions. If the coins are already in escrow by signers, there’s nothing the traders can do at that point?

Hmm.

I’m still not convinced the risk is substantial. I’d like to see responses to the other questions in my previous post.

---

Can we get an update of signer popularity status?

[mhps]

I am under the impression that shareholders select signers that traders automatically use. Is this incorrect?

Now I think you are right. I seem to remember that the traders can select signers but I can’t find where I saw it now. So I might get it wrong.

Can we get an update of signer popularity status?

./bcexchanged getreputations
{
    "8KXAthBdtPWokQRXB93FzPTKvBH5WXdTxV" : 2904.0,
    "8VTtwxu2T1yYUiXoq8BtGAjXxwPySRfFaX" : 150.0,
    "8WP6o6HrXQwc8hfhZPKzGGdd238UqCsRqz" : 1168.25,
    "8XQaJSXNFk5kijspiphx17EdET6QuDPi2a" : 5134.5,
    "8Yq1JGmKAm4qyitx6atpUz1QQqqFm5Ki19" : 3195.75,
    "8ZzENdnyZLDvsZPJmZhQYtdzaBwSKDLXGX" : 2440.0,
    "8c3VfkYUUaFWp75SiMhFasmWwmYVoWqTaT" : 1538.5,
    "8eA3FVjGUE2KFDJy6qSQxZb3MZdoqLf3ZL" : 1091.25
}

[Sabreiib]

“count” : [
{
“vote” : 3,
“value” : 3,
“count” : 275,
“accumulated_percentage” : 13.8
},
{
> “vote” : null,
> “value” : 4,
> “count” : 419,
> “accumulated_percentage” : 34.7
> },
> {
> “vote” : 4,
> “value” : 4,
> “count” : 468,
> “accumulated_percentage” : 58.1
> },
{
“vote” : 5,
“value” : 5,
“count” : 156,
“accumulated_percentage” : 65.9
},
{
“vote” : 6,
“value” : 6,
“count” : 467,
“accumulated_percentage” : 89.3
},
{
“vote” : 7,
“value” : 7,
“count” : 129,
“accumulated_percentage” : 95.7
},
{
“vote” : 15,
“value” : 15,
“count” : 1,
“accumulated_percentage” : 95.8
},

apparently, some voters left blank on eligible signers, so “4” is elected as current number, please vote 6.

[sigmike]

Could traders get to choose which signers they trust?

It was not clear to me when I read the design paper. I asked about that in the protocol specs I wrote but I’m not sure Jordan saw it. It’s about the requirements on deposit address requests:

the pubkeys must have been published by the current top n reputed signers who have available keys on this asset (or 2 * n?)

If the keys must be from the top n signers with available keys, then the user cannot choose the signers (n being the voted number of required signers on the asset, it’s not related to the number of rewarded signers).

To allow signer selection we can loosen that to allow a request to include keys from the top X signers. X would have to be defined (for example the top 2*n signers, or could be added as a voted value on each asset).

[Sabreiib]

count" : [
{
“vote” : 3,
“value” : 3,
“count” : 301,
“accumulated_percentage” : 15.1
},
{
“vote” : 4,
“value” : 4,
“count” : 336,
“accumulated_percentage” : 31.9
},
{
“vote” : null,
“value” : 5,
“count” : 377,
“accumulated_percentage” : 50.7
},
{
“vote” : 5,
“value” : 5,
“count” : 131,
“accumulated_percentage” : 57.3
},
{
“vote” : 6,
“value” : 6,
“count” : 720,
“accumulated_percentage” : 93.3
},
{
“vote” : 7,
“value” : 7,
“count” : 130,
“accumulated_percentage” : 99.8
},
{
“vote” : 15,
“value” : 15,
“count” : 5,
“accumulated_percentage” : 100.0
}
],

Why eligible signers are still 5?

[sigmike]

Why eligible signers are still 5?

Because the first value with an accumulated percentage above 50% is still 5.

[cryptog]

For a new asset to be added it requires an absolute majority of the last 2000 blocks to vote for it with the same exponent value.

That is crucial info. We d never get an exchange running if we do not have assets selected.
There is no awareness across shareholders about the importance of the same exponent value.
But what is this exponent value in any case?

[sigmike]

But what is this exponent value in any case?

It’s the number of decimals allowed on the asset. In the asset vote dialog this value is already defined for all the preset assets. So shareholders only have to decide it on custom assets (or if they disagree with the preset values).

The value should generally be the one used by the asset on its blockchain. It should only need special thoughts when this number is large (like the 18 decimals of Ethereum), in which case a smaller number must be used. It would be very complex to allow this value to change, so if this asset’s value ever becomes too large and shareholders want to allow trading of smaller units they would need to add another asset with a different exponent (for example adding a wei asset with zero decimals). Signers handling this asset would have to do the appropriate adjustments.

[Sabreiib]

“count” : [
{
“vote” : 4,
“value” : 4,
“count” : 672,
“accumulated_percentage” : 33.6
},
{
“vote” : null,
“value” : 5,
“count” : 335,
“accumulated_percentage” : 50.3
},
{
“vote” : 5,
“value” : 5,
“count” : 141,
“accumulated_percentage” : 57.4
},
{
“vote” : 6,
“value” : 6,
“count” : 592,
“accumulated_percentage” : 87.0
},
{
“vote” : 7,
“value” : 7,
“count” : 199,
“accumulated_percentage” : 97.0
},
{
“vote” : 15,
“value” : 15,
“count” : 1,
“accumulated_percentage” : 97.0
},

What’s the accumulated percentage? It looks like “6” gets more count than “5”, 592 vs (335+141).

[sigmike]

What’s the accumulated percentage? It looks like “6” gets more count than “5”, 592 vs (335+141).

The result is not based on the majority. It’s a median.

Consider each vote individually. There are 672 votes for 4, 335+141 votes for 5, etc. Sort them by the value they vote for. So the first 672 are the votes for 4, the next 335+141 are for 5, etc. Then take the vote exactly at the middle of this long chain and you have the median (the middle is actually between two votes, so we take the one immediately after the middle). It means half of the votes are below or equal to the median, and the other half is above or equal to it.

That’s why the votes are returned sorted by voted value and an accumulated percentage is calculated to make it easy to find where the middle is (the first value with an accumulated percentage > 50).

So the median is still 5 because there are more votes for 5 or less than for 6 or more. But only by a small number of votes (7.4% of 2000 = 148 votes).

[Phoenix]

I just noticed reputed signer 8Z3cSbWKeCiE5A15dJpsHmou34w5BYVHqM has just begun to receive votes and now has a reputation score of 8. This address does not appear anywhere on this forum. It appears a single shareholder is voting to give themselves reputation without being a reputed signer.

Such occurrences (where a completely unknown address gets reputation) should be regarded as undesirable by shareholders. It is the best use for down voting. Indeed, some down voting of this type will be needed to keep the network healthy. It remains to be seen whether down voting is important in this case. Only the top 5 signers are getting rewarded right now, and 8Z3cSbWKeCiE5A15dJpsHmou34w5BYVHqM is currently ranked 9th. This is one reason why we want to keep the number of eligible reputed signers somewhat exclusive. The system needs to exclude low reputation addresses from becoming signers or even getting rewards.

Right now this address would need more than 2354 reputation points to gain anything from voting for himself.

The system is properly protected by protocol from such selfish and anti-social shareholders. We can tolerate this type of behavior, although down voting can add additional safety from this type of exploit, even in the case of a very large shareholder. However, large shareholders will tend to not do this type of thing because they would probably lose more in BlockShare value than they would gain from reputed signer rewards.

Please down vote 8Z3cSbWKeCiE5A15dJpsHmou34w5BYVHqM
because it is an entirely unknown address.

[Sabreiib]

This issue is more complex than we thought. Two styles can be implemented.

A solution: semi-centralized exchange, signed by a dozen of famous forum ID.

B solution: decentralized exchange, signed by thousands of anonymous shareholders.

Solution A’s merit is it can easily filter some unknown/fake//hostile ID/shareholders, but the shortcoming is semi-decentralized, the hacker/governments easily locate a dozen of signers.

Solution B is more resistant to censorship, traditional exchanges must comply the famous “know your customers” and FinCEN, so B&C’s law risk is relative high.

We must trade off something.

[Sabreiib]

The result is not based on the majority. It’s a median.

Consider each vote individually. There are 672 votes for 4, 335+141 votes for 5, etc. Sort them by the value they vote for. So the first 672 are the votes for 4, the next 335+141 are for 5, etc. Then take the vote exactly at the middle of this long chain and you have the median (the middle is actually between two votes, so we take the one immediately after the middle). It means half of the votes are below or equal to the median, and the other half is above or equal to it.

That’s why the votes are returned sorted by voted value and an accumulated percentage is calculated to make it easy to find where the middle is (the first value with an accumulated percentage > 50).

So the median is still 5 because there are more votes for 5 or less than for 6 or more. But only by a small number of votes (7.4% of 2000 = 148 votes).

So if I vote for “100,000” eligible signers, it can not influence much more than voting for “6” because the accumulated percentage <=5 is still the same.

[sigmike]

So if I vote for “100,000” eligible signers, it can not influence much more than voting for “6”

Indeed. Until the median becomes “6” in which case voting for “100,000” would still be a vote to increase the result, unlike a vote for “6”.

[mhps]

Indeed. Until the median becomes “6” in which case voting for “100,000” would still be a vote to increase the result, unlike a vote for “6”.

This is a feature of median compared to mean. A few exceptional point don’t influence the result. Te mean of 1 2 3 4 990 is 200, the median is 3.

[cryptog]

I am wondering about when we ll be able to see some assets actually showing up in the client assets field…