The current behaviour of the PrimeUTXOs method is that it tries to end up with the exact # of utxos that you request. So for instance if you currently have 2 utxos and make a request to prime 50 of them, you end up with 50 utxos. Which is fine.. but on the flip side, if you have 100 utxos already and then request to prime another 50... you still end up at 50 total, because it decides to size it down rather than just make additional ones.
This works ok for smallish amounts but will quickly start failing when hundreds or even thousands of txos are needed, which need to be prepared in a series of transactions.
For instance say you have 1,000 utxos you need to create. You can't really get away with making one massive transaction that primes that all, so instead you want to split it up between say 10 transactions with 100 utxos each. The way that bitsplit (and the distributor prototype as well) handles this is that it does priming in two stages. First it figures out how many priming transactions it will need to create (10 in this case) and the total each one will need (e.g 100 * 0.0001543). It then creates a "pre-prime" transaction, priming the primes (yo dawg..)... then once that confirms moves on to the 2nd stage, loops through and creates the 10 big primes with 100 outputs each. This works great in the prototype, but currently does not work in Bitsplit because instead of creating additional outputs 10 times, it keeps resizing down to a total of only 100.
So basically we need an option for xchain to allow me to create as many additional priming tx as I want. Perhaps in the utxo selection for this it could ignore any existing matching prime outputs so that you don't accidentally spend previously generated primes while trying to make new ones.
The current behaviour of the PrimeUTXOs method is that it tries to end up with the exact # of utxos that you request. So for instance if you currently have 2 utxos and make a request to prime 50 of them, you end up with 50 utxos. Which is fine.. but on the flip side, if you have 100 utxos already and then request to prime another 50... you still end up at 50 total, because it decides to size it down rather than just make additional ones.
This works ok for smallish amounts but will quickly start failing when hundreds or even thousands of txos are needed, which need to be prepared in a series of transactions.
For instance say you have 1,000 utxos you need to create. You can't really get away with making one massive transaction that primes that all, so instead you want to split it up between say 10 transactions with 100 utxos each. The way that bitsplit (and the distributor prototype as well) handles this is that it does priming in two stages. First it figures out how many priming transactions it will need to create (10 in this case) and the total each one will need (e.g 100 * 0.0001543). It then creates a "pre-prime" transaction, priming the primes (yo dawg..)... then once that confirms moves on to the 2nd stage, loops through and creates the 10 big primes with 100 outputs each. This works great in the prototype, but currently does not work in Bitsplit because instead of creating additional outputs 10 times, it keeps resizing down to a total of only 100.
So basically we need an option for xchain to allow me to create as many additional priming tx as I want. Perhaps in the utxo selection for this it could ignore any existing matching prime outputs so that you don't accidentally spend previously generated primes while trying to make new ones.