BKS multisig group to provide an incentive for client update

[masterOfDisaster]

###Introduction

The upgrade of the Blocks & Chains Exchange client from version 3 to version 4 is not exactly what you could call a success.
This slows down all steps that build upon the protocol upgrade.
After weeks of notifications via Twitter, Bitcointalk and posts here, only roughly 60% of minting clients are on protocol 4, while 90% are necessary to inititate the protocol upgrade.

JordanLee is on the way to introduce default data feeds:

Proposal to speed adoption of the reputation system

It has been 30 days since we released B&C Exchange 4.0, but only 47% of network minting power has upgraded. To effect the protocol change that will allow us to use the reputation system requires a 90% adoption rate. Given that the adoption rate is rising only very slowly, it is likely that it would take months to reach the switch threshold of 90%. It is important that we move forward with adoption of the reputation system more quickly so we can prepare for the full release of B&C Exchange. We ne…

That can indeed mitigate problems that originate from minters not configuring votes.
But it can’t help upgrading the client version that is used for minting.

Solution

I have created a draft that deals with fixing the problem of old clients used for minting.
This is a problem surfacing at a time when BCE needs an upgrade of a majority of minters to prepare the next steps for bringing BCE live.
But it can be a recurring problem that endangers the operation of BCE if a bug fix release needs to be deployed and the minters just don’t upgrade.
I don’t want to cite the proposal in big parts, so please have a look here:

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

Continuing the discussion from [Mandatory Upgrade] All minters need to upgrade to B&C Exchange 4.0.1: Introduction This draft is dealing with a BKS grant that aims at fixing a serious issue with client updating apathy. The votes (=blocks minted with version 4 clients) for protocol 4.0 is far below 90%, which is required to initialize the protocol switch. Without that protocol switch, trading on B&C Exchange can't be enabled. Other solutions There's a proposal from @JordanLee (https://discu…

Requirements

To provide minters with incentives, distributing BKS as dividend to minters who mint protocol 4.0 blocks is on the agenda.
Those BKS need to be granted by BKS holders.
While a simple solution could be to grant them to a BKS address JordanLee holds (given he’d support that), I believe it’s in the best interest of BCE to not bother JordanLee with that, let him focus on the BCE architecture and use a multisig group instead just like Nu uses multisig groups to share responsibility over funds across custodians.

BCE needs a multisig group handling BKS which will be used for distribution.
I encourage community members to draft motions for becoming member of that BKS multisig group.

From creating NuSafe we know that 3-of-5 is the maximum that can currently be handled.
If more than 5 applicants want to be in the group, the first 5 that get elected shall be in that group.
@applicants: don’t forget to include a compensation - you might have some efforts!

A separate motion for this topic should be superfluous.
The full control about the BKS and their use will be part of the BKS grant proposal - which can only pass if a majority of BKS minters vote for it.

[Sentinelrv]

Distributing BKS as dividend to minters who mint protocol 4.0 blocks is on the agenda.

Quick question, if v4.0.1 has that bug in it that prevents minting blocks while reputation votes are set and Jordan and team are already working on a fix for it and the inclusion of default data feeds, would it be better to target the v5.0 release when it’s ready instead of v4.0?

The way Jordan described it, it seemed as though it wouldn’t take too long to prepare the v5.0 release. In the meantime we could elect members of the multisig group.

[masterOfDisaster]

I want to avoid that we are heading to a “55% protocol” switch, just because some BKS holders don’t act responsibly, which would increase the risk of a fork by far compared to a switch with 90%.

Forming a BKS multisig group might not be the worst idea - no matter whether it’ll be used to fix the current problem with upgrading apathy.
The concrete use of the BKS multisig group to provide additional incentives for upgrading the client will be part of the BKS grant.

[Sentinelrv]

Can the BKS grant state that v5.0 needs to be 90% rather than 55% or would we need a separate motion for that? That way we can target v5.0 with all its upgrades like default feeds, but the 90% remains.

[masterOfDisaster]

I think so.
At the very least the BKS grant I have in mind can support boosting the percentage by distributing BKS to minters of the “right” protocol blocks.
But the grant is step 2. That can be prepared as well, but the more urgent topic in my opinion is to form a BKS multisig group.

[Sentinelrv]

Right, that is the purpose of this thread. Feel free to move my comments to the other thread about the grant if a mod reads this.

[Nagalim]

v4.0.1 has that bug

It doesnt. I went pouring through the posts on that subject. That bug never existed, it was a result of @cryptog setting a datafeed with null values for signer reward.

[Sentinelrv]

Then why did my client still not mint even after I removed Cryptog’s feed? In my posts where I did my tests I said that everything worked except for when I set reputation votes. When I did that I couldn’t mint a block. I tested this without Cryptog’s feed set.

Edit: I will test it once more today.