Bijective send proposal

I'm going to present a far-out idea that I hope one day will be commonly implemented.

Suppose we have a deterministic wallet A based on a master private key A, and we want to transfer all funds from this wallet into another deterministic wallet B based on a master private key B.

Possible reasons why we might want to do this:

• We suspect that private key A has been compromised.
• We want to "close out" our books on wallet A, so to speak, and begin this year with a fresh, empty transaction history in wallet B.
• We're simply making a large payment.

The normal "sweep" procedure is to just do a single send of all the funds. So all the unspent funds in all of the addresses in wallet A end up in a single place in wallet B. The big problem here is loss of privacy: In wallet A we generated a new address each time we received funds, and now all of those addresses show up as sending into a single destination address.

Proposed solution: A bijective send. When given this command, and given two sets of addresses, our software sends the funds available in each address in wallet A to a separate address in wallet B.

Optionally, this could be a batched command, executing over hours or days, so the blockchain would not show the sends as occurring together in time.

Optionally, a threshold could be specified, and funds less than that in an address would be ignored, to avoid creating unnecessary dust where the transaction fee would swallow most of the available funds.

Implementation would require the sending wallet to have a list of receiving addresses. If both wallets are held within the same software, then that is easy. If not, then the sending wallet would need to either be able to generate receiving addresses from a master public key, or be simply provided with a list.

A bijective send could be used when paying another party. Our wallet would pick N addresses from which to send, send the value N to the receiving party, and get a list of N receiving addresses. The bijective send would then send the desired funds, with any excess going to a single change address. Privacy is preserved, because multiple addresses do not lead to one receiving address.

The issue names no files, tests, or entry points. Start by locating Electrum’s existing sweep and address-generation behavior, then define the scope for one-to-one sends, optional batching, thresholds, and external receiving-address lists. Done would require an agreed design and implementation plan before coding.