BIP XXXX : User activated features (ROUGH OVERVIEW)
A proposed change to a usage of the 'OP_RETURN' script opcode in Bitcoin transactions, allowing multiple changes (features) to be deployed in parallel. It relies on interpreting the output field as a bit vector, where each bit can be used to track an independent change. Like BIP9, once a consensus change succeeds or times out, there is a "fallow" pause after which the bit can be reused for later changes.
==Motivation==
BIP 9 introduced a mechanism for doing soft-forking changes, relying on measuring miner support indicated by version bits in block headers. As it relies on miner support, any change which may conflict with miners but is acceptable to users may be difficult to deploy. The alternative, a flag-day deployment can cause issues for users of a feature that has failed to achieve adequate miner support.
BIP XXXX, if used for deployment, can be used in conjunction with BIP 9, in order to more safely deploy soft-forking changes that do not require a supermajority of miners, but do require a large percentage of active users.
Alternatively, BIP XXXX signalling can be used to gauge user support for "features" - independent of its use as a direct deployment mechanism. In this document a "feature" can be considered synonymous with "soft fork", but since this mechanism is "user activated", it is not necessarily restricted to soft-forks.
==Specification==
Each "feature" is specified by the sames set of per-chain parameters as in BIP9, with the same usage and meaning (name, bit, starttime and timeout).
===Bit flags===
If the outputs contain a zero valued OP_RETURN, and the length of the key is 2 bytes, and if the first byte (prefix) of that OP_RETURN's key parameter is 0x012, then the remaining byte is to be interpreted as an 8-bit little-endian integer, and bits are selected within this integer as values (1 << N) where N is the bit number. This allows up to 8 features to be in the STARTED state at a time.
===Array determination===
In order for this to successfully be used for deployment, a lightweight UTXO must be maintained in memory. For each bit in STARTED state, a corresponding bit is set in a map entry for each input address. Each input address is hashed to a 24 bit value using SHA3-256(input)[0:24]. An array with 16777216 2-byte entries (~32MB RAM) is used to record the current activation state. The first byte contains the bit flags most recently associated with an entry.
The second byte contains the log base 2 of the number of "1/100th" bitcoins most recently associated with this entry. This is computed by taking the value, multiplying by 100, converting to an unsigned 32 bit integer, and using the log2_32 function below (.... log2_32 func defined below ....).
This array is initialized to zero. The array must be stored and maintained for each block. When a block is in the STARTED state for any bit, the array is updated for each transaction in the block according to the rules above: a[i][0]=bits, a[i][1]=log2_32(....)
===State transitions===
State transitions work the same as BIP9, however, the determination of the LOCKED_IN tally is as follows:
For each bit in STARTED state, using the array above, the values are totaled (unsigned int)(2 << a[i][1]) for each entry where this bit is set in a[i][0]. In addition the total of all the entries in a, irrespective of bit, are computed. This can be done in a single pass, resulting in a vector of up to 8 32 bit entries containing the "feature totals" for the array, and one extra 32 bit entry for the sum total of observations since the start time.
The percentage of observations is computed for each bit. Up to 8 features can be computed at a time, with reuse similar to BIP9.
If 2016 sequential blocks have a value of 95% or greater, a feature is "LOCKED_IN", (75% on testnet)
bit.
Similar to BIP9, a block's state never depends on its own transactions set; only on that of its ancestors. ACTIVE and FAILED are terminal states, etc.