[PROPOSAL] Change the share structure to support multiple subsidies

[derjanb]

Rework the share_data attribute of the share_info_type structure to contain
a weighted list of subsidies instead of a single subsidy Bitcoin address.

This could look maybe like this:

           ('subsidies', pack.ListType(pack.ComposedType([
                ('weight', pack.IntType(16)),
                ('worker', pack.IntType((64)))])),

By doing so every P2Pool node can choose how to to honor the work of the attached miners:

Option 1: The node generates work that only mentions the miner that requested it at the new subsidies field.
Therefore only shares that match the current P2Pool difficulty are honored and payed if a block is found within 24 hours.
This is the equivalent to how P2Pool works now.

Option 2: The node generates work that contains a weighted list of miners that submitted shares to the server within the last 24 hours.
If one attached miner finds a share that matches the current p2pool difficulty the pool will publish that share and all other nodes calculate the weighted payout according to the included list.
To limit the weight calculation complexity there can be options to count only shares with a given difficulty or a special time frame lower than 24 hours.

I think this can be a important feature for P2Pool to grow in the future. The current P2Pool difficulty is too high for miners with only some GHs or less, but by implementing this feature their work can be rewarded even if the don't find a share.
This will make the pool interesting for any kind of miner independent from their hash rate again and will cause an increased active users count.

The only disadvantages I see atm are:

• the increased share size, but this may doesn't matter at all cause the shares are only stored for 24 hours, only the used network bandwidth will be higher
• and (and this maybe is the main issue) another chain fork would be necessary.

What do you think? :)

[Rav3nPL]

Good thinking. Second chain would be better option imo.