feature request: automatically (and maybe conditionally) send to many addresses instead of just one (fan-out)

[molecular]

This might be a non-trivial extension and definitely beside the core functionality of the plugin, but here's the idea:

For each utxo to be transferred, send to (potentially) more than one destination address. Determining number of destination addresses could be user-defined (options: "constant number", "max coin size") Type of distribution to the destination adresses could be user-specified (for example using a slider on a scale from "distribute evenly" to "distribute randomly" and maybe some other more elaborate types of distribution other than linear (exponential,...)?)

I'd be willing to pay for this feature.

[KarolTrzeszczkowski]

It seems actually pretty straight forward and I'd know how to code it right away. The benefit would be more natural looking out coming transactions?

[molecular]

The benefit would be more natural looking out coming transactions?

Good point. My use-case is actually to transfer coins to a wallet for fusing. Until there is more liquidity in larger tiers (I guess), fusing large (>50 BCH) utxos is very slow if possible at all. So in my case this really makes the most sense in conjunction with hw-wallets working as source wallets... or maybe the plugin could be used in the same wallet just to break utxos into smaller pieces (might be a stretch, though)

In case you have time and want to implement this, I would be happy to pay you some hourly rate or flat rate if you can quote a price. Same for the hw wallet feature. On the other hand I don't want to pull your resources from potentially more important work... just let me know.

[zveda]

I think I want to work on this feature if nobody minds. @KarolTrzeszczkowski can I modify the GUI to add the number of outputs of each transactions, and the min and max value of the outputs?

[molecular]

@zveda (others: we talked on tg about this a bit):

Let me suggest the following approach:

3 new text entry boxes (and maybe an "advanced settings" checkbox those are hidden behind)

• min_outputs ("minimum number of outputs per transaction") default: 1
• min_output_amount ("minimum output amount"): default: dust limit
• max_output_amount ("maximum output amount") can be empty, then no maximum. default: empty

What we want to do is generate a transaction for each utxo with at least min_outputs outputs. The output amounts should be randomized between min_output_amount and max_output_amount while one output ("change") is allowed to be smaller than min_output_amount.

the following pseudocode might achieve this:

for each utxo to transfer:

• generate a transaction tx
  • tx.input = utxo
  • if max_output_amount <= 0 or not set: let max_output_amount := utxo.amount
  • let remaining_amount := utxo.amount
  • let remaining_min_outputs := min_outputs
  • while remaining_amount > 0:
    • remaining_min_outputs -= max( 0, remaining_min_outputs - 1) // tracks how many outputs we still need to g`enerate (excluding the current one)
    • let amount := random number between min_output_amount and max_output_amount - remaining_min_outputs * min_output_amount // set to None if not possible
    • if amount is None or amount > remaining_amount:
    • if remaining_min_outputs > 0: abort and skip this utxo
    • amount = remaining_amount // last output can be < min_output_amount
    • tx.add_output_to_new_destination_address( amount )
    • remaining_amount -= amount
  • append tx to scheduler queue

I pledge a bounty of 1 BCH to implement this and get @KarolTrzeszczkowski to accept it and pull it in.

Open to any suggestions, of course.

[zveda]

I think default "minimum number of outputs per transaction" should probably be two, as that is the most common type of transaction, and the purpose of this plugin is to preserve privacy.

[zveda]

I wonder if this breaking up coins into many inputs of random sizes should not be a separate plugin. I actually already have a script that does this.

[molecular]

@zveda I chose 1 as default for "minimum number of outputs per transaction" to mimic current behaviour (so users aren't taken by surprise by new behaviour)