[Draft] BKS grant to bring protocol 4.0 votes above 90%

[masterOfDisaster]

I don’t want to cut anybody out.
I don’t like pushing this proposal.
It leaves a bad taste in my mouth to discuss a measure, which is nothing else, but partially dispossessing people.
Alas, I don’t see viable alternatives.

@Sentinelrv hit the nail on the head:

Just think what would happen if a severe bug was discovered in the protocol while we were managing people’s funds and it took our lazy shareholders over a month and a half to realize they needed to upgrade.

Not only the reputation would be damaged. BCE could tumble and fall because of such apathy.

At the moment BCE is in the convenient situation that nothing else but the start of the business is at stake (which in my opinion is just enough to think about wake-up calls).
Gladly it’s not customers’ funds that are at risk.

The decentralized and distributed nature of BCE can’t prevent users from having funds stuck at BCE multisignature addresses if a sever bug hinders them from withdrawing them,
…registering a data feed is not enough…

[Nagalim]

I won’t support this yet. I’m not convinced that the distribution method is sufficiently elegant. I worry about the marketing angles. I also don’t think 1.5 months is too long, it took me a while to upgrade to v4.0. Some people will wait a good bit of time to make sure the upgrade is stable before switching to it.

[masterOfDisaster]

What’s the alternative?
Sit and wait?
Let other decentralized exchanges start with their business?
Struggle with apathetic BKS holders each time a decision needs support?

I bet you are aware that BCE isn’t operational just because the protocol switch (that still takes 2 weeks after 90% are on version 4) was initiated…

[Sentinelrv]

I don’t want to cut anybody out.I don’t like pushing this proposal.

Neither do I, but I fear the possible failure of BCE a lot more than angering shareholders who could get partially dispossessed.

[masterOfDisaster]

shareholders who could get partially dispossessed.

Even if this proposal would find support.
Even if a BKS grant to distribute BKS to 4.0 minters would pass.
Even if the distribution would be planned (by extracting BKS addresses from 4.0 blocks in a given window).
Even if all that would happen…
…all a shareholder who doesn’t want to fall victim to the dispossession has to do is: mint with a version 4 client!

I can’t believe that’s too much, but if it is, well…

[Nagalim]

What’s the alternative

I’m not convinced that the distribution method is sufficiently elegant

I’m not saying we nees an alternative. I am saying I’m scared of one-time dilutions that cause abrupt discontinuities in share valuation.

[Sentinelrv]

I am saying I’m scared of one-time dilutions that cause abrupt discontinuities in share valuation.

I understand BlockShare prices would be impacted negatively by a dilution like this, but how many people are really paying attention at this point to notice a devaluation? We have only one exchange with low volume and every time I look at Coinmarketcap I don’t see BlockShares in the list. It’s almost as if we don’t exist yet. If we were Ethereum and in the top 2 with all eyes on us, then everyone would see the devaluation happen. If we had to do it, then this would probably be the best time to reduce the impact. That’s only my opinion though.

[Yurizhai]

I think I’ll be ready to support this motion after hearing what Jordan and the data feed providers have to say.

[masterOfDisaster]

I don’t plan on creating only a motion.
I hope that what I have in mind is possible with a multisig BKS address:

1. make a motion to outline the plan and elect multisig custodians
2. grant BKS to a multisig address
3. distribute BKS from the multisig address to BKS addresses that mint 4.0 blocks
4. repeat step 3. until enough minting power is in the hands of people who mint with 4.0 clients (very well possible by waking up shareholders!)

[Nagalim]

Ok, now you’re not talking a one time dilution anymore. So do we give enough time between dilution events for people to notice and upgrade to catch the next dilution? Are we bribing people to become active, or are we rewarding those that already were?

[dysconnect]

Would it be better to penalize those who actually mint with <4.0 and never switched to 4.0 within a given time frame, rather than those that don’t mine with 4.0? I worry about those who only have a small amount of BKS (like up to ~20 BKS), who by chance might not get a block in a long period of time. It’ll benefit non-minters, but the purpose is to get the message across.

I’ll support an other 1-month time frame for waiting, after warnings are publicized at certain selected venues. We might also need a clause that this plan is void if we can update to 4.0 on time, which will likely be better for PR.

[masterOfDisaster]

Ok, now you’re not talking a one time dilution anymore

I was hoping to wake up people with the sheer discussion.
That didn’t work.
Now it’s time for the next step(s).

So do we give enough time between dilution events for people to notice and upgrade to catch the next dilution?

Exactly.
A one-time dilution was never my intention, although it would have been the more frightening one (I was rather trying to sound things out).

Are we bribing people to become active, or are we rewarding those that already were?

A bit of both.
As running this business is not enough incentive, we need to provide the apathetic guys with additional incentives to act responsibly.

[masterOfDisaster]

Would it be better to penalize those who actually mint with <4.0 and never switched to 4.0 within a given time frame, rather than those that don’t mine with 4.0?

Sure, only I don’t know how.
Distributing BKS to addresses that mint 4.0 blocks is the only publicly verifiable and relatively easy (for those who can parse blockchains…) operable approach I can think of.

I’ll support an other 1-month time frame for waiting, after warnings are publicized at certain selected venues.

The motion and the grant alone will take some time and create some efforts.
The nagging thing is, that if all pans out, all this effort is wasted, wasted by those who care to compensate the bad effect of those who don’t.

[Nagalim]

all this effort is wasted

Electing a BKS multisig for B&C would not be a waste.

[cryptog]

I think we should wait a bit more before adopting this kind of last resort.

Another thing is that we should think about is to use a lower necessary threshold, 60% or even 50%.

Why 90% should be necessary per se?

[masterOfDisaster]

Look at what happened to Peercoin recently after Peerunity with a bug was released.
The blockchain forked.

The closer you are at 50%, the bigger the risk that two equal forks occur.
In this case: one run by old clients, one run by updated clients.
We don’t want to risk that.

But yeah, let’s wait some more - we only wait for weeks now…

[dysconnect]

The upgrading issue has attracted criticism. While I agree with the sentiment that the time and effort need to be rewarded, and we should consider a better reward system than just minting, we’re trapped between a rock and a hard place, and it’s not because you and I want different things… .

[cryptog]

what about this?

Proposal to speed adoption of the reputation system

Lowering the switch threshold to 55% from its current value of 90%: 55% is the lowest percentage that we can be reasonably confident will prevent large numbers of consecutive orphan blocks as the switch occurs. While a 55% percent threshold brings higher risks of problems around the time of the switch, the risks are much smaller than the risks of substantial additional delay that the 90% threshold brings.

[crypto_coiner]

We should vote about the threshold of percentage of votes needed to switch to the new protocol.

[masterOfDisaster]

what about this?

a 55% percent threshold brings higher risks of problems around the time of the switch

Do you want to treat symtoms or cure the illness?

We should vote about the threshold of percentage of votes needed to switch to the new protocol.

The security and reliability of the blockchain can’t be created by a motion. It needs to be created by minting.