No it wouldn't. You could do something similar to one of my yield proposals. For each distribution event, put the BTS / BitAssets being distributed into a "pool" specific to that distribution. The pool just contains a balance for each BitAsset type being distributed, plus a record of the time at which the distribution occurred and the quantity of UIA in existence at that time.
Then every time a balance moves, you check if there have been any distributions since the last time it moved. If so, then the transaction's allowed (or perhaps even required) to withdraw funds from the pool equal to the UIA balance which is moving, divided by the total UIA in existence at the time of the distribution event (which was recorded as part of the pool record).
That way every dividend collection transfer operation is O(N) where N is the number of distribution events that have occurred since the UIA stake was last moved. But we can design the system to do better than that.
If we want the number of operations to not depend on the number of distribution events, we could simply accumulate the ratios between the total distribution event yield and the amount of outstanding UIA at the time of the distribution event as each distribution event occurs. Then the difference between these accumulated values at the time the stake was last moved and the current time can be used to determine how many BitAssets the transfer is allowed to remove from the dividend pool.
There may be some numerical errors that grow with the number of distribution events, but I am not too concerned about that. If we round down when calculating the dividend for a transfer, I think there will be some dust left over in the dividend pool after everyone claims their dividends. Even if not, the amount of dividends the last person to claim the dividend would lose would likely be very small. In order to prevent a large accumulation of unclaimable BitAsset dividends in the pool due to rounding errors, it might make sense to have different generations of pools. For example there can be a separate pool for every year. Once all of the stake that existed in the prior year has moved (this is tracked by the variable t in my proposal below), any remaining dust in the pool for the previous year becomes reclaimable by the UIA issuer. Also, in order to prevent the transfer operations from becoming too complicated because of multiple generation of pools existing due to unclaimed stake in an old pool, we can simply require that the UIA holder move their balance once a year if they want to collect dividends (otherwise they still get to move their UIA stake, they just do not get to collect any dividends older than a year).
I have described this proposal more precisely below.
y_{u,a,i} = quantity of BitAsset a distributed to UIA u stakeholders as part of distribution event i of UIA u
b_{u,i} = block number at the time of the distribution event i of UIA u
I_{u,b} = most recent distribution event index for UIA u as of block number b ( b_{u,I_{u,n}} <= n < b_{u,I_{u,n}+1} for all n < b_{u,I_{u,latest_block}} )
l_{u} = latest distribution event index for UIA u (l_{u} is a mutable variable)
s_{u,i} = quantity of outstanding UIA u stake during block number b_{u,i}
t_{u,i} = quantity of unmoved UIA u stake existing in a block after b_{u,i} but before b_{u,i+1} if defined (each t_{u,i} is a mutable variable)
r_{u,i} = accumulator to help calculate dividends for UIA u right after distribution event i of UIA u
The accumulator is defined as follows:
r_{u,0} = 0,
r_{u,i+1} = a_{u,i} + y_{u,b,i+1} / s_{u,i+1}, for all i > 0 for which a distribution event exists.
For every UIA u, the database tracks a mutable variable l_{u}, a list of (i, r_{u,i}, b_{u,i}, t_{u,i}) for all distribution events (or as an optimization, only the relevant subset of them), and I_{u,b} for all blocks in which at least one UIA u transfer occurred (or again as an optimization, only the relevant subset). The values r_{u,i}, b_{u,i}, and I_{u,b} are immutable, but t_{u,i} is a mutable variable in the database. So, if a distribution (the ith distribution for UIA u) of BitAsset a of quantity y is given as a dividend at block b to all UIA u stake in existence at that time (total quantity of UIA u stake is s), the client sets the following values in the database:
r_{u,i} = r_{u,i-1} + y/s,
l_{u} := b,
t_{u,i} := 0.
Also, the BitAsset a of quantity y is moved into a dividend fund for the UIA u.
When a transfer occurs of UIA u stake of quantity q which was last moved at block b, the client calculates the divided d as follows:
d = (r_{u,l_{u}} - r_{u,I_{u,b}}) * q.
It then withdraws BitAsset a of quantity d from the dividend fund (or as much as possible if there is not enough do to rounding errors for example). Finally, it updates/sets the following values in the database:
t_{u,I_{u,b}} := t_{u,I_{u,b}} - q,
t_{u,l_{u}} := t_{u,l_{u}} + q,
I_{u,b} = l_{u} (this is only necessary to set once for the block b if there are multiple UIA u transfers in the block).
Also, whenever UIA u stake is either issued into existence or destroyed, the values of t_{u,*} may need to be updated. If UIA u stake of quantity q is issued in the newest block, then the following values must be update/set in the database:
t_{u,l_{u}} := t_{u,l_{u}} + q,
I_{u,b} = l_{u} (this is only necessary to set once for the block b if there are multiple UIA u stake issuance in the block or not necessary to set at all if there are any UIA u transfers in the block).
On the other hand, if UIA u stake of quantity q which was last moved in block b is destroyed in the current block, then the following value must be updated in the database:
t_{u,I_{u,b}} := t_{u,I_{u,b}} - q.
The full list of (i, r_{u,i}, b_{u,i}, t_{u,i}) recording the entire history of distributions does not need to be stored in the database (it can always be recovered from the blockchain anyway). It can be pruned by removing items from the head of the list if they are no longer necessary. An item at the head of the list corresponding to distribution event i is no longer necessary if its t_{u,i} == 0. Anytime there is an update to the t_{u,i} at the head of the pruned list, there is a potential for further pruning of the list. If this update happens (due to a transfer of UIA u stake), the client checks to see if t_{u,i} == 0. If so, it sets a pruning flag to true for the UIA u stake in the database that pruning is possible. When it gets the time (there are no time constraints), it can go through the list and check how many of the items in the beginning of the list satisfy the t == 0 condition, and remove them one by one. Only when the client gets to an item at the head of the new list where t != 0 does it set the pruning flag to false (at least until it is triggered to true again because of a UIA u stake transfer causing the t at the head of the list to become 0). The block number b_l for the item at the head of this list where t !=0 determines the blocks for which the I_{u,b} values can be also safely removed from the database (again no there are no time constraints to do this). The client can iterate in ascending order of block number b from the earliest pruned block for UIA u, and remove the I_{u,b} value if b < b_l. A more clever implementation would include the block number of the block storing the next I value, I_{u,b_{u,I_{u,b}+1}}, together with the value I_{u,b} to create a linked list of stored I values for each UIA u (also it would need to keep track of the mutable head index, H_{u}, and mutable tail index, T_{u}, of the linked list for each UIA u). This would allow the pruning process for the I values to be much faster.
Topic: User Issued Asset Upgrades (Read 18701 times)
