bsip#12 BitShares Hardfork Precdure Proposal

```
BSIP: 0011
Title: BitShares Hardfork Precdure Proposal
Authors: Fabian@BitShares.eu
Status: Draft
Created: 2016-01-13
```
# Purpose

This documents tries to establish a process that will be applied to all
future hard fork proposal and that will be used to identify if
a proposal is approved or not.
# Preface

In BitShares, every shareholder has a vote as to whether a new feature,
innovation or other proposal shall be integrated into the BitShares
protocol via a hard fork.

It is of importance to establish a voting mechanism that _clearly_
resolves to either
- `approved` by shareholders, or
- `not approved`.

To identify the will of the shareholders, we make use of blockchain
workers that is attached to a [BitShares Improvement Proposal (BSIP)](https://github.com/bitshares/bsips).

Every shareholder can approve, or disapprove the worker and by this
casts a vote. Currently, a worker proposal is considered approved once
it enters the actively paid workers (independent of its actual pay). In
other words, a worker that has more approval votes than the last
approved worker that is paid (often a _refund_ or _burn_ worker), then
the proposal is `approved`. Thus we currently have:

``` python

vNet(fork) = vPro(fork) - vCon(fork)

"approved" if (vNet(fork) > vAct(x)) else "not approved"

```

With
- `vNet` being the net votes
- `vPro(x)` being the approval votes
- `vCon(x)` being the disapproval votes
- `vAct(x)` being the _last_ **active** worker

Once a proposal has reached approval, it **has to be implemented** by
the witnesses until the hard forking block.
# Problem Statement
- There never was an approved consensus about the threshold.
- Hard Fork Proposals compete with Workers which is a different demographic
# Solution Proposal 1

Since Worker Proposals can be approved **and** disapproved, a **net
positive** vote for a hard fork proposal can be considered `approved`.
If the net vote result is negative, the proposal is `not approved`. Here
shareholders compete with pro and contra votes.

Thus we here have:

``` python

vNet(fork) = vPro(fork) - vCon(fork)

"approved" if (vNet(fork) > 0) else "not approved"

```
## Pros
- Fair representation of consensus
- Simple Scheme
## Cons
- Shareholders need to vote on _every_ hard fork
# Solution Proposal 2

To relax the rule, we could have a _threshold worker_ (zero pay) so that
shareholders can define the threshold as well.

By this, shareholders vote on hard forks in general and have the options
to _also_ vote for particular hard forks of which they are in favor, or
not.

If a shareholder doesn't want to see additional features implemented, he can
approve the threshold worker and raise the required net votes for a hard fork.

Alternatively, those that want a flexible protocol can disapprove it and
have hard fork proposals be approved more easily.

Thus we here have:

``` python

vNet(fork) = vPro(fork) - vCon(fork)
vNet(threshold) = vPro(threshold) - vCon(threshold)

"approved" if (vNet(fork) > vNet(threshold)) else "not approved"

```

In order to prevent rapid approvals, a proposal will only be evaluated
after 2 weeks. This gives shareholders time to disapprove in a timely
manner.
## Pros
- Allows to set a 'default' approval/disapproval
- Only a little more difficult scheme
## Cons
- Can not distinguish between different degrees of innovation in a hard fork
# Solution Proposal 3

To extend the previous idea, we propose to characterize different BSIPs
into categories (_tier-1_, _tier-2_, ..) and have a distinct threshold
for each of them.

This would lead to the rule:

``` python

tier = characterize(fork)
vNet(fork) = vPro(fork) - vCon(fork)
vNet(threshold, tier) = vPro(threshold, tier) - vCon(threshold, tier)

"approved" if (vNet(fork, tier) > vNet(threshold, tier)) else "not approved"

```

In order to prevent rapid approvals, a threshold worker will only be
considered if it existed at least 2 weeks. Furthermore, threshold
workers shall be created by the committee-account, only.
# Pro
- Very Flexible
# Con
- Very difficult approach
- How to decide categories in a decentralized way
# Solution Proposal 4

And then of course we can combine them. A hard threshold which must be
passed by ever soft threshold and a successfully approved proposal must
surpass the hard threshold **as well** as the tier-specific soft
threshold.

``` python

tier = characterize(fork)
vNet(fork) = vPro(fork) - vCon(fork)
vNet(threshold, tier) = vPro(threshold, tier) - vCon(threshold, tier)
vNet(hardthreshold) = vPro(hardthreshold) - vCon(hardthreshold)

"approved" if (vNet(fork, tier) > vNet(threshold, tier) AND vNet(fork, tier) > VNet(hardthreshold)) else "not approved"

```
## Pros
- Most flexible approach
## Cons
- Very difficult approach
# Initialization

In order to reach consensus, we propose a 2-step procedure.
1. We first let shareholders approve this general document such that
a consensus is reach about the general concept.
2. Shall this document be approve, each proposed solution will have it's
own (zero-pay) hard fork worker. The last active worker (that is
being paid) is considered as approval threshold.
- If any of the proposals is approved into the active domain within
8 weeks after creation, the active proposal with the most net votes
is approved an shall be implemented accordingly at that time.
- If after 8 weeks, no proposal has reached the active domain, the
proposal with the most active net votes shall be implemented.
# Conclusion

We here present four approaches to identify if shareholders approve
a hard fork or not and show a way to reach consensus about the
implementation of one of these options.