Initial Witness Pay & Number of Witnesses

[mindphlux]

51 would seem like a good number, a number that bitcoiners would understand too. Perception is everything. 31 seems low, too easy to collude.What does it look like to the outside bitcoiner when you say

"Bitshares is secured by 31 elected witnesses (block producers) who sign blocks" Reponse: 31? That's very centralized

OR

"Bitshares is secured by 51elected witnesses (block producers) who sign blocks."

Matter of perception.

EDIT: Also what comes to mind, in the past we had situations when up to 3 witnesses were no longer signing blocks because they were offline or use a old version etc. 3 witnesses on 31% means roughly 10%. That's way too much of a network to be misbehaving, on 51 witnesses it would be 6% .. much better. Voter apathy can lead to this.

[Thom]

This is a great and much needed discussion. Many good considerations have been brought up.

Spectral's analysis aims at the level I think we should be thinking. Focusing on the witness pay is not the prime concern IMO, plus that can be adjusted as marketcap grows or as other factors dictate (supply of witnesses of adequate skill level and familiarity with BitShares technology). I say $300 / month is actually very low cost security. I think that is a good initial pay rate to start. Initially more attention to running witnesses will be required as the new code is set free into the wild. I think the first set of witnesses will be working pretty hard to keep up with code changes as bugs are discovered to sustain 99% reliability.

I also think a very important consideration is the voter apathy angle. For that reason I think the number of witnesses should not be too big to start off. IMO 30ish sounds like a good starting point until enough infrastructure (i.e. education, DPOSHUB, proxies, reliability tract records etc) is in place to get a clear picture of how to make adjustments.

There are a number of independent factors at play, like how well informed the biggest stakeholders are, how many proxies are active, what level of awareness the proxies have of what is actually going on in the network, what effect on perception bug discoveries might have, all these things could impact voting quality and quantity. Pretty damned hard to predict how effective voting will be with all that in play.

Who thought it would be so difficult to vote out delegates that aren't even producing blocks or have asked to be voted out in 1.0?
Who is John Galt?

I also think we need to be looking at the attack vector angle. Wackou & I are actively engaged at just that. The backbone infrastructure and "small world" approach can be an effective defense against attack, including DDoS attacks. Although it may be possible to manually "activate" a backup witness node, or switch a seed node to an active block producer within minutes from the start of an attack, I think it would be much better to automate such switching with quality monitoring.  If backbone connections to witnesses can be monitored and they drop below a minimal threshold (which could be monitored by backbone nodes AND witnesses, i.e. both sides of the connection) a switch to alternate nodes can be done automatically. If witnesses can ascertain the health of the backbone nodes and it is good, they can limit their connections to backbone nodes exclusively, in which case the IP address of the witnesses is protected by the backbone nodes, and backbone nodes are likewise protected by seed nodes. If the health of the backbone drops below an acceptable threshold the witnesses turn to backups, alternates or even trusted seed nodes in a fallback cascade to insure network reliability. Witnesses may expose their IP address in such an event, but at least the network survives. It may buy enough time to get redundant backbone nodes up.

As for Riverhead's remarks, how does having alternate keys keep the original witness from coming back online and resuming block production with the original set of keys in addition to the new witness? Doesn't that require two separate witnesses that have to be independently voted in? What prevents 2 witness nodes operating under the same account name but using different keys? If only 1 is allowed to produce blocks which one chosen if 2 (or more) are configured as block producers?

[mike623317]

I think it would be a mistake to have too many witnesses at the start because we have seen managing the voting can become an issue.My 2 cents is that we should start off with perhaps 31 and increase as necessary. Prove we can handle 31, then increase it as funds allow.

[BTSdac]

how about set a minimum number first such as 17 then increase the number according to the feed price(acutally this is the paramater of marketing cap)?

For example:
17 witness when 2.0 lunch.
if feed_price > 0.1, witness_number = 33
if feed_price > 0.2, witness_number = 51
......

if the system is strong, we don't need to worry about this delution and we can even set more than 101 witness, but the reality is we're still a little baby, we need to make us strong step by step

The actual number need not be coded in and is entirely set by voters in real time.   The only number we need to set is PAY.

I think pay is not much in initially , I think   $150  is enough ,  hire $80 per month vps  and other $70 is for maintain
I  personally gold to  expend all pay  on hiring VPS
of course  in long-term view , I hope the witness is a career, like a  staff hired by block chain ,
so it should have reasonable pay . since we all think bts price would rise much in future

[maqifrnswa]

Then get witnesses to be paid only if uptime is higher than 98% but let others operate within a larger limit. We could have 50 or more witnesses competing for that spot instead of the original 17. As long as a witness has >98% uptime they get paid.
Chance the requirements from a random quantitative number, to performance.

I think the concern is that the "punishment" for not producing > 99% isn't strong enough if it is simply not getting paid. And what happens if someone says, "i'm not getting paid, i'm turning off the node" -- that means we end up with a 0% delegate until someone votes them out.

This new model is different than the 101 delegates we currently have. These new witnesses should be professional operations, not hobbyist (or at least the capability to turn into a professional operation on demand). I'm all for being extremely selective over whom will be hired to be witnesses.  I think it's better to pay 20 people $200 each with 99% uptime than 100 people $40 each with 98% uptime; especially if those first 20 have the capability of expanding to high transaction volumes and the larger group of 100 does not have the resources nor technical ability to pull it off.

And my opinion is for right now -- this will change and we will probably have to expand both the number of witnesses and pay per witness as BTS2.0 demand grows.

Participation in bitshares is broader now: if you want to be a marketer, be a marketer. If you want to be a dev or some other value add, be a worker. But witnesses is a specific job, and it comes with high expectations and high requirements. I think it sends a strong signal that we aren't messing around with this tech. It will be professional and robust.

[liondani]

Then get witnesses to be paid only if uptime is higher than 98% but let others operate within a larger limit. We could have 50 or more witnesses competing for that spot instead of the original 17. As long as a witness has >98% uptime they get paid.
Chance the requirements from a random quantitative number, to performance.

 

[Pheonike]

Tiered performance pay. Less than 90% are your standby.

<98%   = 100% pay
95%-97.99%  = 80% pay
90%-94.99%  = 50% pay
>89.99%  = no pay

[Akado]

I think this could be a solution but I don't know if it's feasible. Would grant us what we want, high number of witnesses and save money

Get some parameters like (from btsblocks):
- Average Latency
- Active feeds
- Uptime

Witnesses only get paid as long as those parameters have a certain value. Example: to get paid a witness would need >98% uptime and 1,4s average latency and published all feeds. This would increase the number of witnesses and competetivity. For example we would still have the benefits of having witnesses with 97% uptime, published all-1 feeds, etc, etc

Does this make sense? Is it feasible? That's the best I can think of. Satisfies all conditions we want.

Latency calculations are completely relative to where you are pinging from... so I don't see how that can work unless you incorporate much more complicated calculations that make each node geo aware. I am concerned that could provide an attack vector of not implemented correctly.

I understand that pay is already tied to uptime... as for feeds that's what is being debated now I think.

Then get witnesses to be paid only if uptime is higher than 98% but let others operate within a larger limit. We could have 50 or more witnesses competing for that spot instead of the original 17. As long as a witness has >98% uptime they get paid.

Chance the requirements from a random quantitative number, to performance.

[mindphlux]

how about set a minimum number first such as 17 then increase the number according to the feed price(acutally this is the paramater of marketing cap)?


The actual number need not be coded in and is entirely set by voters in real time.   The only number we need to set is PAY.

Can't we set the pay to initially $x BTS and have it changeable by shareholder approval?

[BunkerChainLabs-DataSecurityNode]

I think this could be a solution but I don't know if it's feasible. Would grant us what we want, high number of witnesses and save money

Get some parameters like (from btsblocks):
- Average Latency
- Active feeds
- Uptime

Witnesses only get paid as long as those parameters have a certain value. Example: to get paid a witness would need >98% uptime and 1,4s average latency and published all feeds. This would increase the number of witnesses and competetivity. For example we would still have the benefits of having witnesses with 97% uptime, published all-1 feeds, etc, etc

Does this make sense? Is it feasible? That's the best I can think of. Satisfies all conditions we want.

Latency calculations are completely relative to where you are pinging from... so I don't see how that can work unless you incorporate much more complicated calculations that make each node geo aware. I am concerned that could provide an attack vector of not implemented correctly.

I understand that pay is already tied to uptime... as for feeds that's what is being debated now I think.

[bytemaster]

how about set a minimum number first such as 17 then increase the number according to the feed price(acutally this is the paramater of marketing cap)?

For example:
17 witness when 2.0 lunch.
if feed_price > 0.1, witness_number = 33
if feed_price > 0.2, witness_number = 51
......

if the system is strong, we don't need to worry about this delution and we can even set more than 101 witness, but the reality is we're still a little baby, we need to make us strong step by step

The actual number need not be coded in and is entirely set by voters in real time.   The only number we need to set is PAY.

[maqifrnswa]

Right now we have 65 delegates at 3%, those are the current "witnesses." 55 of them have > 95% reliability. At least 10 of those are duplicates.

BTS2.0 will take a little more technical skill to set up at first since there aren't many FAQ/How to/tutorials on basic sys admin for new witnesses, so you want expert sys admins at the helm as BTS2.0 launches. I'd say <50% would be experts. That leaves you with ~22 current "witnesses."

I think that 22 should be the max at launch, so 17 might be acceptable. As xeroc suggested, you can let people know that there are plans to scale security/decentralization by both increasing pay and number of witnesses appropriately.

I think $300/month is a good number because 1) it's enough to get good sys admins excited but 2) not enough for hard-core professional sys admins to get involved beyond a hobby level.  As BTS2.0 grows, you can increase the pay to scale the quality of services (reliability/capacity) or increase witnesses to increase security. The committee can suggest appropriate directions.

Therefore, $300/month and ~20 witnesses seems about right now. That said, I probably am more interested as a worker than a witness unless we really need more witnesses to kick this off.

EDIT: the key is that both pay rate and number of witnesses MUST be adjusted as BTS2.0 grows to stave off real attack concerns. Which one we do depends on how BTS grows. We don't know that yet, so we just need to pick a starting point that is reasonable and adjust in the future.

[Spectral]

BitShares may be be doing things more efficiently than Bitcoin, but I'm struggling to see how a big actor will have any problem whatsoever taking down 17 witnesses running on 300$ a month. Now I'm not a hacker or security expert, but I've seen how something so small as the newly set up Norwegian Pirate Party DNS server (combatting Pirate Bay censorship) may quickly find itself under heavy DDOS fire. Why would something like this not pose a danger to the BitShares network, with our portfolio of powerful enemies?

A delegate can move their block signing node to any computer under their control connected to the internet in a matter of seconds. This makes a DDOS attack nearly impossible.

In detail:
1) You notice your node is missing blocks and can't log in to your server due to DDOS
2) Connect to another computer you control, update_witness with new signing key

This allows your new witness to sign blocks and prevents your old witness, in the event the DDOS is not a complete shutout or ends, from double signing.

I guess this can be done in theory, but will it work in practice?
1. Will witnesses respond quickly enough (within seconds or minutes)?
2. Will the alert witnesses have servers on standby, compiled and ready with fully loaded blockchains?
3. Can 17 witnesses defend against a dedicated attacker keeping it up for, say, 48 hours?

If there are all those spare witnesses on standby we're not really talking about 17 witnesses cost-wise anyway. They might as well be signing blocks.

I'm seeing a complete blackout of the BitShares network within minutes, and a serious struggle to get it back up again.

[Akado]

I think this could be a solution but I don't know if it's feasible. Would grant us what we want, high number of witnesses and save money

Get some parameters like (from btsblocks):
- Average Latency
- Active feeds
- Uptime

Witnesses only get paid as long as those parameters have a certain value. Example: to get paid a witness would need >98% uptime and 1,4s average latency and published all feeds. This would increase the number of witnesses and competetivity. For example we would still have the benefits of having witnesses with 97% uptime, published all-1 feeds, etc, etc

Does this make sense? Is it feasible? That's the best I can think of. Satisfies all conditions we want.

[Riverhead]

BitShares may be be doing things more efficiently than Bitcoin, but I'm struggling to see how a big actor will have any problem whatsoever taking down 17 witnesses running on 300$ a month. Now I'm not a hacker or security expert, but I've seen how something so small as the newly set up Norwegian Pirate Party DNS server (combatting Pirate Bay censorship) may quickly find itself under heavy DDOS fire. Why would something like this not pose a danger to the BitShares network, with our portfolio of powerful enemies?

A delegate can move their block signing node to any computer under their control connected to the internet in a matter of seconds. This makes a DDOS attack nearly impossible.

In detail:
1) You notice your node is missing blocks and can't log in to your server due to DDOS
2) Connect to another computer you control, update_witness with new signing key

This allows your new witness to sign blocks and prevents your old witness, in the event the DDOS is not a complete shutout or ends, from double signing.