It looks like current protocol already allows for the first option, Combining Rewards. There is a parameter, nCombineThreshold, which goes into determining what outputs get combined. It is currently set at 1/3 of the PoW reward, however as far as I know there are no protocol rules that prevent it from being increased to a large number. In addition, it only combines utxos that are at the same address. I think this function can be modified to do what we want, but also I believe that we need to impose additional protocol rules to prevent it from being abused as I mention in the OP. Specifically, I think the protocol rules should be as follows:
- Max nCombineThreshold = 1/6 the number of coins used to mint, regardless of coindays
- Total Coinstake transaction size = 1 KB
I choose 1/6 for 2 reasons:
- Outputs that have a split tree where one branch is 3 splits deeper than the other will have outputs with 1/8 the size that can then be recombined. This allows the split/combine trees to be more flexible over time if there are large swings in PoS difficulty.
- With a 60 day split frequency, recombining outputs that are 1/6 the size of an output split at 60 days will have a >50% chance of minting within 360 days (60*6=360, and the 90 day mint chance is greater than the 60 day mint chance).
The total coinstake transaction size is quite limiting for a number of applications. I chose it with mint pools in mind and with the idea that you could track input addresses directly to output addresses within the coinstake. This way, no one has to worry about who pays the fee (minters get 1 KB for free) and you can truly pool together outputs owned by different people that have their rewards paid to the correct address. This allows for seamless integration of a pool, potentially even just using the standard client software. However, you could achieve the same effect by making this simply a client rule, so it may not be necessary to promote this to the protocol level.