Consolidation of Sanctuaries

[Rob Andrews]

Since BiblePay is moving to Evolution in June, we have the opportunity to potentially change the Sanctuary lockup requirements from 1,550,001 to another figure.

I think this would be a good time to discuss potentially changing this lockup requirement higher in order to :
- Give our investors more ROI per Sanc
- Decrease Hosting Costs
- Increase reliability per Sanc (because user may afford a higher quality host and have more time to monitor each sanc)

The obvious downside to this is a higher barrier of entry cost for the small investor.
But, with our recent downturn in price bringing a sanctuary investment to only $400, I think this is a feasible idea.

For me as an investor, I would personally lean towards consolidating so I can spend less on hosting fees.
Analyzing the effect of wasted hosting:

We currently have about 500 sancs.
Our sanc owners are spending a very high percentage of the revenue on hosting (If hosting is $10 per month, with $20 of revenue that is 50% spent on hosting).

I believe reducing the sanc count by half will not hurt biblepay (as 250 nodes are still more than enough to service our network), and, it could be argued that 250 high quality sancs are better than 500 low quality sancs (as with low quality instant sends could get lost).

Additionally over the next 5 years, even if we move to 125 sancs, our sanc count will again increase (due to more coins being emitted and a lockup ratio average of approx 50% coins become locked into sancs).

I propose that we enter 3 sanctuary proposals floating this idea with different size lockups:
1) 3 million lockup
2) 4.5 million lockup
3) 7 million lockup

If all 3 are voted down we keep 1.55 MM.

[strayapple]

I hope this rule will take effect for new sancs in the future,the old sancs are not affected.

[Rob Andrews]

Maybe we could have the so-called tiered masternodes? For example, three tiers: 1.5m, 3m and 6m. We could even name other tiers something like "shrines" etc.

So if someone has more masternodes, they can consolidate them. And if someone has one masternode, they can stay on the lowest tier undisturbed.

Unfortunately, the code lockup value is hardcoded in 75 areas (in BiblePay we made it a constant so its cleaner).

But yes, the only way to do that is to make variable payments per dynamic lockup, but we cant make variable with 7 minute blocks (it would require multiple outputs per coinbase, and that requires the voting system to be changed  etc, etc).

So in summary, its just not possible in this particular version of Evo (with our block spacing and recipient count and ABN feature).

[Rob Andrews]

I hope this rule will take effect for new sancs in the future,the old sancs are not affected.

Everyone with an existing sanc would need to take it down, upgrade it to a DIP3 sanc (deterministic sanc) with 3 keys, change the lockup req, and bring it back online at a certain hard-fork deadline height.

(We will all need to do this first part anyway, for Evo).

[Rob Andrews]

If the primary reason is the current price of  BBP,   I don't agree with this..

Wouldn't the better focus instead be how to make BBP more valuable,  thereby raising the cost for a MN?

The problem is we only have a few whales here so far, so I think the whales will agree that they dont need 50 sancs per whale, and I dont think it would be a good idea to tell the whales to sell their bbp now (as then there is no reward incentive for them).

So for right now, I think the idea makes sense.

Of course we should work on making biblepay valuable anyway.

[Rob Andrews]

Ill give it a couple more days and if all 3 look unpopular Ill put a smaller one in also  - so please keep an eye out for a smaller option.

All the current negatives might be Slovakia and Noko.

[capo]

if you have 2 nodes and get 5000 per node or you have 1 node and get 10000 per node is same
lower hosting cost is fine

i never had masternode so i dont know how it exactly works, but what about possibility to use any port for node? i dont know why it is fixed
with unlocked port it is easy to run all nodes on one server (using docker or so for example)

for me 4.5m looks good

[MIP]

I am for some sort of consolidation.

I guess that people for it will vote in only 1 of the 3 proposals (the one they prefer), but owners against it will vote down all 3 proposals.

So I would propose to apply a majority of the sum of all yes votes in 3 proposals against the biggest "no" count in one of the three (will probably be the same number in the 3 proposals)

For example
3MM: 40 yes/200 no
4.5MM: 50 yes/200 no
7MM: 20 yes/200 no
40+50+20=110 yes, 200 no = no wins

3MM: 40 yes/100 no
4.5MM: 50 yes/100 no
7MM: 20 yes/100 no
40+50+20=110 yes, 100 no = yes wins and 4.5MM option wins

I think it's fairer.

[Rob Andrews]

No ... This is not "Fairer", as someone who is happy with any of the options could vote 3 times, and have their vote counted 3x.


What I worry this seems like an attempt to consolidate power,  I currently have more than one MN,  and one of the options would exclude me outright . 

I do see value in less for hosting fees, but I do not agree we should be excluding more folks from the voting process.

A more "Fair" way to approach that would be to start with a single poll, "Should we raise the cost of a sanctuary"  get a yes/no on that before trying to figure out which level to raise it to.

Each individual poll does have the individual ability to win or lose though, and everyone with sanc voting rights can vote on an individual poll currently.
So I wouldnt go as far as saying its "unfair", I would say, this needs to be a strategic decision certainly.

I'm for instance holding back and watching the public opinion on this as I dont want to weigh in and hurt the small guys by forcefully voting for the highest for example.  If people seem to gravitate towards the 4.5 then Ill probably weigh in on that.

I do want to exclaim loudly, that I am very very merciful and compassionate for the small investor!  I am not against voting for a reduction in 18 months if our price is 20* higher then.  At the same time, I obviously am against constant changes!  --  Im just saying that I wouldnt want BiblePay to cost $100,000 per sanctuary like Stratis for instance .

As far as consolidation of power, we are cheap right now, I think its a fair argument to say that a $1,200 slice of BiblePay - will still give One slice of voting power.  Its not true to say that I for example am becoming more powerful.  The remainder of a fractional straggling sanc is what is at stake - and yes a fractional sanc share is what we would be expecting that person to buy on the open market.   (I made my transparent case that we would also on the flip side not really want to let a whale dump extra bbp because they cant manage the day to day activities of running their sancs.  I fit in that category - I  prioritize release punchlist points every day over rebooting sancs in new start required state).

[MIP]

No ... This is not "Fairer", as someone who is happy with any of the options could vote 3 times, and have their vote counted 3x.
...
The way to approach that would be to start with a single poll, "Should we raise the cost of a sanctuary"  get a yes/no on that before trying to figure out which level to raise it to.

Yes, that would definitely be more precise. Because I am for 1 of the 3 options and I wouldn't vote up any of the other 3, but neither would I vote them down.

[Rob Andrews]

Yes, that would definitely be more precise. Because I am for 1 of the 3 options and I wouldn't vote up any of the other 3, but neither would I vote them down.

No, but putting in a poll to raise or not is equal to the responsible sancs voting all 3 options down.  We dont need one to see if people will raise first.

I don't think an error was made here.

[sunk818]

Exactly because of this, I'd argue it's best to vote "abstain" on the other two options, because that makes it transparent that you didn't vote "yes" on those too, but that you are participating in the vote for one of the three.

You vote based on the merits of the individual proposal irrespective of what surrounds it. The proposals aren't dependent on each other. They just happen to all be posted in the same monthly superblock, but I'm voting as if each proposal was added on separate superblocks. How could you vote otherwise since there was no prior discussion?

[oncoapop]

I wonder if the consolidation can be achieved in an alternative way (as maybe others have suggested in other forums) that is to allow for multiple masternodes on a single host? That would mean allowing each sanc to use a different port. I don't know if that is worth considering or even technically possible.

[sunk818]

I wonder if the consolidation can be achieved in an alternative way (as maybe others have suggested in other forums) that is to allow for multiple masternodes on a single host? That would mean allowing each sanc to use a different port. I don't know if that is worth considering or even technically possible.

It is something I've been trying to do recently, but have had difficulty compiling from source. Evo 1.4 is different enough from 1.2 that I've hit a few stumbling blocks. I know one coin where the user has 32 masternodes on one IP utilizing different ports.

[sunk818]

I see 25 masternodes got made in the last 24 hours And voted yes by one person. More than saving hosting fees, the priority seems to be a desire to maintain control and power. You raise MN cost to 4.5M and that makes it 3x as difficult for newcomers to buy enough bbp for a MN.

Vps cost less than $1/mo.

If you want diversity and the ability to voice an opinion, make the MN cost 750k bbp instead.