Delegated staking

[robvanmieghem]

Currently the blockstakes are handed over to the addresses of the blockcreators, this means that the private keys have to be fetched and stored from the containers running them to recuperate the mining fees and recover the blockstakes in case of node crashes.
It would be better to authorize a node to create blocks.
In a first version, let's keep it simple and give the mining fees to the address holding the blockstake authorizing the blockcreation.

• Create new output condition
• Add support in wallet for delegated blockstakes
• Add support in wallet for blockstakes which you have delegated to someone else
• Create blocks using delegated blockstakes
• First class support in consensus set for blocks created with a delegated block stake (need to verify what actually needs to happen)

[LeeSmet]

proposal for design:

In order to delegate a blockstake output to a third party, a new output type (type 5) is defined. The condition in this output holds 2 single signature (01) addresses: 1 address which can use the output to create blocks, and 1 address which can reclaim the blockstake (i.e. the owner). As such, the condition could be structured as follows:

{
    "value": 1, // amount of blockstake to lease
    "condition": {
        "owner":"0100112233445566778899aabbccddeeff00112233445566778899aabbccddeeff",
        "delegate":"010123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"
    }
}

The output can be spend with a singlesig fulfillment of one of the 2 included addresses.

Similar to the multisig wallets, a wallet can then check the addresses within the known delegated outputs. If it finds a singlesig address which it own in the "owner" field, then it can add the value to a new "leased out" field, so the wallet knows it owns the blockstake but can't do anything with them untill they are recovered. Likewise if a wallet finds an address it owns in the delegate field, it can add the output to a new "leased to me" field.

The blockcreator will need to take into account the blockstakes which have been leased to its wallet.

The biggest problem is that there currently is no way for an input to also impose restrictions on the way it is then spend. So we will also need to modify the consensus set code which validates a transaction. More precisely, if the output is spend by the delegate, it is only valid if it recreates the exact same output, and is the only input/output pair in the transaction (thus this is a block creating transaction which only respends the blockstake for the proof of blockstake protocol). If the output is unlocked by the owner, it MUST be in a valid transaction which changes the output, thus not being a pure block creating tx, meaning there must be a transaction fee. The owner IS allowed to reclaim the blockstake by creating a singlesig output to itself, but this requires a txfee.

[robvanmieghem]

The biggest problem is that there currently is no way for an input to also impose restrictions on the way it is then spend

Indeed, I wonder if it might be better to modify the current block creation by no longer spending the blockstake.
@GlenDC didn't you already start on something like this a couple of months ago?

If it's only a lease, then the owner might also be dropped, leaving the current sending and owning of blockstakes untouched.

[robvanmieghem]

On the last remark, I think I understand now since you do not reference the blockstake output, hence the owner and the amount but how do we redelegate then?

[GlenDC]

but how do we redelegate then?

I imagine similar to how we do it know?

[LeeSmet]

As it turns out the transaction seems to be injected in the fulfill method already as part of the context, since we need it to verify the signature. Although there is currently no other condition which does this, it seems like the logic which checks the transaction which spends the output can also be added here, which would mean no changes are required in the consensus set. Thoughts @GlenDC ?

[LeeSmet]

After some discussion with @robvanmieghem this morning, a different approach could be:

Create a new block creation transaction version. This transaction has no inputs or outputs, and is always tx 0 in the block. Instead of a blockstake input which gets respent, it only holds a reference to a delegate condition.

The delegate condition itself would then be rewritten to be:

condition: {
    blockstake_output_id: xxxxxxxxxxxxxx...,
    delegate: {} //actual delegate condition, single sig, timelocked, ...
}

This means that the blockstake is no longer spent in order to delegate to someone, instead a reference is created along with a condition which needs to be fulfilled in order to be able to create blocks. The owner can then reclaim / redelegate / ... the blockstake simply by spending the referenced output.

This also means we need to block the regular owner from creating a block creation tx with this output, as else there would be 2 block creators trying to use the same block stake output to create blocks (since the delegation will use its own ID in the block creation tx).

[LeeSmet]

Closed in favor of #147