<p>Once a day, take the addresses with balances more than some multiple (say, twice) of the average, and create a transaction that sends money to the lowest-value addresses. E.g. let's say the average is 0.5 and call the addresses A-Z:</p>

<ul>
<li>A: 2.0 BTC</li>
<li>B: 1.5 BTC</li>
<li>C: 1.0 BTC</li>
<li>...[other addresses with under 1 BTC]</li>
<li>X: 0.1 BTC</li>
<li>Y: 0.05 BTC</li>
<li>Z: 0 BTC</li>
</ul>

<p>Transaction would send from A, B, and C to X, Y, and Z so that each has the same amount (0.775 BTC).</p>

CC BY-SA 3.0
2014-08-22T14:44:06.377Z
2014-08-22T14:44:06.377Z
Tim S.
<p><strong>Another solution might be to rebalance during the regular use of the addresses:</strong></p>

<p>Whenever one of the addresses is selected to spend from, check whether an above average balance would remain.</p>

<p>If that is the case, additionally to the planned transaction, redistribute the <em>excess</em> to underfunded addresses, where <code>excess = remainder - average_balance</code>.</p>

<p>You could pick recipient addresses for the redistribution by performing a greedy algorithm such as for example a knapsack problem solver, optimizing for minimal sum of squared distances from the average over all addresses. You could restrain the number of recipient addresses by only allowing an additional recipient address if all previous recipient addresses will be raised to the average.</p>

CC BY-SA 3.0
2014-08-27T17:07:54.583Z
2014-08-27T17:07:54.583Z
Murch
<p>Let's say I have 50 addresses which have an average of 0.5 BTC. Some have two or three times the average balance, while others have less than 0.1% of the average. Many times per day an address is selected to either receive or send some amount of coins, fueling the inequality.</p>

<p><strong>What's an efficient, cost-effective method of rebalancing a large number of addresses such that each contains roughly the average balance?</strong></p>

<p>(Assume the algorithm to select a keypair with which to transact is fixed and cannot be modified for argument sake.)</p>

CC BY-SA 3.0
2014-08-19T19:02:16.513Z
I am wondering whether this is an [XY-Problem](http://meta.stackexchange.com/a/66378). At least it makes me curious, why you would want to do that.
Murch
CC BY-SA 3.0
2014-08-19T19:04:12.707Z
I don't believe it's an XY problem. The reason is that I would like to keep coins spread across 50 addresses roughly evenly, and sometimes I might transact with a given address without checking its balance in relation to the other 50 for performance reasons.
Chris Cashwell
CC BY-SA 3.0
2014-08-19T20:18:26.767Z
@Chris You still haven't answered the base question: Why do you want to keep your balance spread across 50 addresses instead of any other way (e.g. in one wallet, in whatever addresses they happen to go in)?
Tim S.
CC BY-SA 3.0
2014-08-19T20:21:50.567Z
@TimS. I don't really see how the reasoning is relevant. The point here is that I have N addresses and want to occasionally make their balances roughly equally. Assume there's a good reason why without needing to understand that specific reason.
Chris Cashwell
CC BY-SA 3.0
2014-08-19T20:24:44.110Z
Better yet, assume I don't know the reason why many addresses are desirable. Assume that the parameters are set and I'm simply looking for a solution within those parameters.
Chris Cashwell
<transactions><balance>
What's an efficient model for redistribution of coins between wallets?
Chris Cashwell
# What's an efficient model for redistribution of coins between wallets?

(Asked by: username_0 on 2014-08-19)

Let's say I have 50 addresses which have an average of 0.5 BTC. Some have two or three times the average balance, while others have less than 0.1% of the average. Many times per day an address is selected to either receive or send some amount of coins, fueling the inequality.

**What's an efficient, cost-effective method of rebalancing a large number of addresses such that each contains roughly the average balance?**

(Assume the algorithm to select a keypair with which to transact is fixed and cannot be modified for argument sake.)

**Tags:** transactions, balance

> **Comments:**
> **username_1**: I am wondering whether this is an [XY-Problem](http://meta.stackexchange.com/a/66378). At least it makes me curious, why you would want to do that.  
> **username_0**: I don't believe it's an XY problem. The reason is that I would like to keep coins spread across 50 addresses roughly evenly, and sometimes I might transact with a given address without checking its balance in relation to the other 50 for performance reasons.  
> **username_2**: @username_0 You still haven't answered the base question: Why do you want to keep your balance spread across 50 addresses instead of any other way (e.g. in one wallet, in whatever addresses they happen to go in)?  
> **username_0**: @TimS. I don't really see how the reasoning is relevant. The point here is that I have N addresses and want to occasionally make their balances roughly equally. Assume there's a good reason why without needing to understand that specific reason.  
> **username_0**: Better yet, assume I don't know the reason why many addresses are desirable. Assume that the parameters are set and I'm simply looking for a solution within those parameters.  

---

## 2 answers

### Answer by username_2 on 2014-08-22. Score: 1

Once a day, take the addresses with balances more than some multiple (say, twice) of the average, and create a transaction that sends money to the lowest-value addresses. E.g. let's say the average is 0.5 and call the addresses A-Z:

* A: 2.0 BTC
* B: 1.5 BTC
* C: 1.0 BTC
* ...[other addresses with under 1 BTC]
* X: 0.1 BTC
* Y: 0.05 BTC
* Z: 0 BTC

Transaction would send from A, B, and C to X, Y, and Z so that each has the same amount (0.775 BTC).


---

### Answer by username_1 on 2014-08-27. Score: 1

**Another solution might be to rebalance during the regular use of the addresses:**

Whenever one of the addresses is selected to spend from, check whether an above average balance would remain.

If that is the case, additionally to the planned transaction, redistribute the *excess* to underfunded addresses, where `excess = remainder - average_balance`.

You could pick recipient addresses for the redistribution by performing a greedy algorithm such as for example a knapsack problem solver, optimizing for minimal sum of squared distances from the average over all addresses. You could restrain the number of recipient addresses by only allowing an additional recipient address if all previous recipient addresses will be raised to the average.


---

