Initial Witness Pay & Number of Witnesses

[BunkerChainLabs-DataSecurityNode]

Also, doesn't 17 witnesses kiss goodbye to minebitshares?

Depends on the voting public really. It's not the right vehicle for funding it anymore in regards to using witnesses. Witnesses are supposed to be putting all their resources towards the network. In our case, I have considered the possibility of donating those resources and instead moving a portion of that pay towards the dev. As I said though, I don't think that's the correct purpose... though it does help the project.

However I have stated before that we are going to reduce our position to one if any and instead submit a worker proposal for further development. Again though.. its totally up to the voting public.

[Method-X]

I have no idea how "the market" will perceive 17 witnesses but I personally see no problem with it. Since the number of witnesses is dynamic, shareholders can vote for increased security if and when it's needed. How many bouncers does a little mom and pop business need? Not many. Wait until the little business turns into something huge before adding all those redundant expenses up-front. I don't think this community should let irrational perception guide it, even if it means a smaller market cap for now.

[monsterer]

Also, doesn't 17 witnesses kiss goodbye to minebitshares?

[mindphlux]

I would feel safer with a minimum of 25 witnesses, 17 seems to low.

The witnesses should be all in individual countries to be safe. With rising marketcap, the number can be increased.

[monsterer]

IMO better to not support 100k TPS than to have a handful of witnesses. Security of the chain is much more important than chain performance.

[jakub]

I think it's a good approach to start with a low number like 17 and then increase this number in the future.
This would show that:
(1) we care about our operating costs
(2) as our business grows we invest profits in improving security

[sittingduck]

There is no maximum.   Only a maximum total budget.   


Sent from my iPhone using Tapatalk

[xeroc]

First, in regards to PR, we should pursue a narrative where we *start out* with x, and then move towards y. None of the people I initially told about 1s transaction times objected when I said due to complications we would do 3->2->1, because people intuitively understand start small and grow towards a goal - everyone can relate and it makes for an interesting story.

Second, I feel like the discussion is too theoretical for this stage. We can't simply decide in advance on the number of good witnesses relative to pay, because we have no idea who is out there and willing to jump into this spare time. There is a human element here, where we need to take note of the people who are willing and active right here right now, and see what they are willing to do for how much.

Mixing these considerations with the other suggestions here, I think we should collect a list of at least 17 independent people who are willing to be a witness right here and now, and PR wise point to a future number, like 37, that we are aiming for as we grow.

This.
Emphasiaing we are talking about INITIAL values I think we can start with 17 at least 25 at most and aggressively educate the possibility for 200 ..

[Riverhead]

Looking at the business partners Graphene has attracted, and what attracted them, it matters little what "bitcoiners" perceive as secure.

Yes, this is what you guys said about dilution.

[snip...]

Your current valuation and 6 figure volumes are from alt-coin speculators and investors. Not new business partners and their networks, yet. So I would say it matters quite a lot how the alt-coin market views BTS.

[/c][/c]

Correct on all counts - but I still stand by what I said. The market cap of crypto hasn't move from around ~$4BB USD. All these changes and volumes are exactly just the crypto community shuffling funds from one place to another. Chicken feed and table scraps. The real money, hundreds of billions, has yet to enter the fray and it's them I'm interested in designing the system for.

[liondani]

I disagree to have only 17 witnesses.
You have not considered a bribe attack...
A competitive chain could "buy" 9 witnesses to outplay bts2.0 the "early days"...
It make more sense to lower the number of witnesses when the market cap goes significant up, not now!
Why not let the market dynamically make the decision every day... or even the "code"  that make automated decisions relative to the current market cap or the average uptime of all witnesses or the average latency, or all this together?


PS by the way I want to maintain a witness... (I will participate on the test-network also)

[luckybit]

In the most recent Mumble session we discussed the witness pay and witness count for BTS 2.0 and today I would like to bring the discussion to the forum.

The job of a witness is the following:

1.  Have 99.9% uptime
2.  Maintain Low Latency connections
3.  Rapidly upgrade in response to bug fixes.
4.  Identify and help fix issues that may occur.

At a minimum this will require $40 per month to host a Digital Ocean (or equivalent machine).  It will also require at least 10 hours of work per month to keep up to date, especially at first.  The labor required is skilled labor.

I suggested that each witness should receive $300 per month for 100% uptime.   This should make the job very competitive and therefore result in higher quality witnesses with an eye toward keeping their job rather than relying on volunteer witnesses with nothing to lose if they have less than 99.9% reliability.   

At today's market cap the network has a maximum spending rate of about $65,000 per month which can go toward witnesses and workers.   If we were to maintain 101 witnesses it would cost the network $30,000 per month at $300 per witness.

In my opinion we should aim for around 17 witnesses rather than 101 for the following reasons:

1. It would only cost the network about $5100 per month
2. It is a number that is small enough for voters to reason about and evaluate
3. It is a number that is large enough to be geographically / politically diverse
4. Is greater than the number of slices in the Bitcoin mining distribution: https://blockchain.info/pools
5. It is similar to the number of validators Ripple has:  https://validators.ripple.com/#/validators 

While we are small having more witnesses does not buy us anything.  The probability that an extra 84 witnesses will have any impact on the security of the network is so close to 0 that the price we  pay for that extra redundancy does not make economic sense.


I would recommend that we instead diversify the other 84 positions into a combination of:

Committee Members, Workers, and Proxy Voters.   

Having a core group of active proxy voters will help make the network more responsive and more secure than having more witnesses.

Cryptonomex will not be a witness so has no skin in the game of setting this price.   We just want to offer the best advice we know of and then let you all decide how many you can actually vote for and are willing to pay for.

I would go with 25 witnesses. 25 is around 25% of 101 and easier marketability than 17.

[monsterer]

This is the trouble when you aim for super high performance - the higher you aim, the more expensive it is to run a witness, and therefore the more centralisation you get in a system where the market cap is insufficient to support the performance at break even cost.

[CLains]

First, in regards to PR, we should pursue a narrative where we *start out* with x, and then move towards y. None of the people I initially told about 1s transaction times objected when I said due to complications we would do 3->2->1, because people intuitively understand start small and grow towards a goal - everyone can relate and it makes for an interesting story.

Second, I feel like the discussion is too theoretical for this stage. We can't simply decide in advance on the number of good witnesses relative to pay, because we have no idea who is out there and willing to jump into this spare time. There is a human element here, where we need to take note of the people who are willing and active right here right now, and see what they are willing to do for how much.

Mixing these considerations with the other suggestions here, I think we should collect a list of at least 17 independent people who are willing to be a witness right here and now, and PR wise point to a future number, like 37, that we are aiming for as we grow.

[gamey]

1. how does we guarentee that all 17 witnesses are unic?
2. if they all run on amazon, i don't call us decentraliced, because this gigant can shut all witnesses easily out.

+5% +5%

17 sounds very low to me.
there are roughly 193 countries in the world.
- decentralization requires a diverse geographical-location too.

webhosting companies are a dime a dozen and I can pretty much assure you that there is an io.js hosting company in every one of those 193 countries. 

if we can somehow code it so that paid witnesses are auto-chosen by their low latency, high uptime, rapid upgrades/updates (separate blockchain for logging this info?) and geo-location (detected via IP, ping times, EnvVars (see code below), "whoisHostingThis", etc), then I think we're good. a bare minimum being 20, and if the network tries to dip below that then ____fill in ramifications here____.

Code Select Expand


Environment Variables:

TERM=xterm
PATH=/sbin:/usr/sbin:/bin:/usr/bin
PWD=/var/www/ecd6a08763eae1bb12c9b395811c802f/live
LANG=en_US.UTF-8
SHLVL=2
_=/opt/nginx/sbin/nginx
SERVER_SOFTWARE=nginx/1.6.0
PASSENGER_DEBUG_DIR=/tmp/passenger.spawn-debug.XXXX154IJs
USER=app_1031
LOGNAME=app_1031
SHELL=/sbin/nologin
HOME=/home/app_1031
IN_PASSENGER=1
PYTHONUNBUFFERED=1
NODE_PATH=/opt/passenger/passenger-4.0.48/node_lib
RAILS_ENV=production
RACK_ENV=production
WSGI_ENV=production
NODE_ENV=production
PASSENGER_APP_ENV=production
SERVER_PROTOCOL=HTTP/1.1
SCGI=1
DOCUMENT_ROOT=/var/www/ecd6a08763eae1bb12c9b395811c802f//live/public
QUERY_STRING=
SERVER_NAME=some-domain.com
REMOTE_PORT=33984
REMOTE_ADDR=79.214.235.96
SERVER_PORT=80
REQUEST_METHOD=GET
APP_CONFIG={"mongo":{"host":"localhost","port":27017,"hostString":"localhost:27017\/app_1031","user":"app_1031","db":"app_1031"}}
SERVER_ADDR=172.31.26.5
REQUEST_URI=/


i think we should let the code make those decisions, not humans.

Evennode (in Slovakia) for example, is an iojs host that only costs 6€ per month and their uptimes are incredible. if we set the pay as a dynamic percentage of [and the minimum number of witnesses based on] market cap, then each node will get paid what they need to be paid, plus a little to make it worth everyone's while AND then we do not have to cap the max number of witnesses.

LIFE requires Else conditions.
just my 2sats :)

Although putting such heuristics into the procotol seems to add security, such things open up a ton of attack vectors.

[kenCode]

1. how does we guarentee that all 17 witnesses are unic?
2. if they all run on amazon, i don't call us decentraliced, because this gigant can shut all witnesses easily out.

+5% +5%

17 sounds very low to me.
there are roughly 193 countries in the world.
- decentralization requires a diverse geographical-location too.

webhosting companies are a dime a dozen and I can pretty much assure you that there is an io.js hosting company in every one of those 193 countries. 

if we can somehow code it so that paid witnesses are auto-chosen by their low latency, high uptime, rapid upgrades/updates (separate blockchain for logging this info?) and geo-location (detected via IP, ping times, EnvVars (see code below), "whoisHostingThis", etc), then I think we're good. a bare minimum being 20, and if the network tries to dip below that then ____fill in ramifications here____.

Code Select Expand


Environment Variables:

TERM=xterm
PATH=/sbin:/usr/sbin:/bin:/usr/bin
PWD=/var/www/ecd6a08763eae1bb12c9b395811c802f/live
LANG=en_US.UTF-8
SHLVL=2
_=/opt/nginx/sbin/nginx
SERVER_SOFTWARE=nginx/1.6.0
PASSENGER_DEBUG_DIR=/tmp/passenger.spawn-debug.XXXX154IJs
USER=app_1031
LOGNAME=app_1031
SHELL=/sbin/nologin
HOME=/home/app_1031
IN_PASSENGER=1
PYTHONUNBUFFERED=1
NODE_PATH=/opt/passenger/passenger-4.0.48/node_lib
RAILS_ENV=production
RACK_ENV=production
WSGI_ENV=production
NODE_ENV=production
PASSENGER_APP_ENV=production
SERVER_PROTOCOL=HTTP/1.1
SCGI=1
DOCUMENT_ROOT=/var/www/ecd6a08763eae1bb12c9b395811c802f//live/public
QUERY_STRING=
SERVER_NAME=some-domain.com
REMOTE_PORT=33984
REMOTE_ADDR=79.214.235.96
SERVER_PORT=80
REQUEST_METHOD=GET
APP_CONFIG={"mongo":{"host":"localhost","port":27017,"hostString":"localhost:27017\/app_1031","user":"app_1031","db":"app_1031"}}
SERVER_ADDR=172.31.26.5
REQUEST_URI=/


i think we should let the code make those decisions, not humans.

Evennode (in Slovakia) for example, is an iojs host that only costs 6€ per month and their uptimes are incredible. if we set the pay as a dynamic percentage of [and the minimum number of witnesses based on] market cap, then each node will get paid what they need to be paid, plus a little to make it worth everyone's while AND then we do not have to cap the max number of witnesses.

LIFE requires Else conditions.
just my 2sats :)