btc-address-scripting-mechanism
Purpose
This doc describes the required changes to Bitcoin multisignature wallet scripting mechanism (previously described in Multisignature wallet LLD).
Scope
TODO
Process Overview
SONs are expected to be co-signatories for the funds stored on PW. Each SON has a public key on Bitcoin (secp256k1) and the weight of its signature.
This is executed on Bitcoin blockchain with the following script:
<pubkey1> OP_CHECKSIG
OP_IF
<voting_weight1>
OP_ELSE
0
OP_ENDIF
OP_SWAP
<pubkey2> OP_CHECKSIG
OP_IF
<voting_weight2>
OP_ADD
OP_ENDIF
...
OP_SWAP
<pubkeyN-1> OP_CHECKSIG
OP_IF
<voting_weightN-1>
OP_ADD
OP_ENDIF
OP_SWAP
<pubkeyN> OP_CHECKSIG
OP_IF
<voting_weightN>
OP_ADD
OP_ENDIF
<two_thirds_of_total_voting_weight>
OP_GREATERTHAN
The point of the script is that each SON has a weight (sum of votes for SON that is set at maintenance). Depending on the cumulative weight of votes a decision is made on whether the transfer is to be executed. For the transfer to happen the sum of weights in the script must be >= 2/3 + 1 from the number of current active SON weights.
Since the addresses depend on weights, and weights in turn depend on balances, on most occasions the deposit addresses will be re-generated after maintenance. There are two ways to handle this situation:
All pre-maintenance are to be considered invalid after maintenance.
Consider the pre-maintenance composition of SONs and their weights trusted post-maintenance. If the composition of SONs doesn't change, but their weights do, SON members are to be allowed to process the transaction in accordance with their pre-maintenance weights.
We can change the ranking upon the first transaction related to PW/SONs takes place. This is further discussed here : Functional Specification - SONs switchover scenarios#SONsswitchoverscenarios-6.Scenarios