Minter Budget: Optimizing Merging/Splitting of Outputs in RFC0002


If you don’t know what RFC0002 is, please read this article:

I’d like to discuss how the coinstake transaction can optimize the merging and splitting of outputs given a particular minter budget. Currently, the protocol merges all mint block rewards and splits in half outputs that mint in less than 90 days. I want to seek a solution like this to the output complexity caused by splitting the coinstake transaction.

First, I suggest a more aggressive split:
Split in half if output mints before 90 days
Split in thirds if output mints before 60 days
Split in quarters if output mints before 50 days
Split in ‘n’ parts if output mints before ‘30+60/(n-1)’ days
Limit the total number of splits such that the resulting transaction will not exceed the minter budget

A generalized merge is more complicated. I’m currently thinking something like: take the current PoS difficulty, calculate percent chance of minting each output over the next 90 days (like the wallet does in the staking section) and merge everything under a certain threshold. This is also limited by the minter budget and takes precedence over splitting outputs.


The generalized merge has issues with its basic premise: the same wallet is used for minting and transacting. A merge is more than just a fee, it is a freezing of the small output. If the client is automatically merging small outputs, it may unexpectedly merge an output that the user was about to send somewhere else, forcing them to either burn coindays by using an older, bigger output or worse, not being able to do the transaction at all because the coins are locked for some time. For this reason, we should seek to distinguish between small minting outputs and small liquidity outputs.

This line of thinking leads us back to the way the RFC is written, actually, in that RFC0002 merges only outputs that are block rewards. These block rewards are surely small outputs being used for minting because we know their origin.

If we want to merge outputs more aggressively than whats described in RFC0002, we will need to add some additional criteria, such as a 30 day old maturation period, before merging outputs that did not come from coinbase.


This is not a protocol requirement. The protocol allows you to decide for yourself how you split and merge.
This is purely client behavior that can be changed, no need to formalize on protocol level.


This thread is for sure about optimizing client behavior, assuming the protocol changes in rfc0002.


How about something as simple as a check box next to each input on the mint tab asking “merge?”. If you check this, then it will merge that input in the next coinstake txn.