Some kind of warning when consolidating coins when selecting toomany.

[the-real-vortex-v]

Problem: When selecting inputs to consolidate (I have a few thousand now), I get a couple of error messages that say "Transaction too large" and "Transaction creation failed!".

Solution: When selecting the inputs, the bytes used is calculated. It would be nice to maybe offer two solutions or both.

1. Warn the user that the number of inputs is too large and offer to remove the transactions that won't fit. Include a checkbox to enable this option so it automatically happens as well might be nice. This is a non batch mode.
2. Ask the user if they'd like to "auto" split the transactions up into batches. Include a checkbox as well.

[andyoknen]

Do you mean automatic creation of multiple transactions if the desired transaction is too large?

[the-real-vortex-v]

Do you mean automatic creation of multiple transactions if the desired transaction is too large?

Yes. It just seems quite absurd that automation like this isn't standard on a financial platform. Having it just fail when the user has set a target amount that they want to send/consolidate etc is counter intuitive. If anything making things more intuitive should be a goal to strive for. Bitcoin is old enough now that the tech built on top or derived from it should not have these issues. Either way it's not a stupidly difficult thing to add and would make ease of use much better. Also adding a "consolidate coin for stupid people" kind of button would also be a nice thing. Lots of fragments tends to slow things down. It might be something to add to the easynode for example.

[andyoknen]

In general, I agree with the idea. But the implementation of such functionality in the current code base is not as simple as it might seem. We are currently thinking about the future of the project, one of the points is to change the technical implementation of the blockchain to a more modern and more scalable one (not bitcoin).

[the-real-vortex-v]

In general, I agree with the idea. But the implementation of such functionality in the current code base is not as simple as it might seem.

I don't seem to understand why? I can do this manually by just adding inputs with coin control and stopping when the TX size is less than the max tx size. Then consolidate them then repeat this until all the inputs are joined. I can then select the newly created consolidated inputs and consolidate them further if I require that.

This is code that is not difficult to make. I understand that you must see an underlying issue with the way that coin control is implemented and don't want to encourage input consolidation but right now this kind of functionality would be handy.

If at the least a tx size overflow check should be done. That's just good bug prevention.

[andyoknen]

Also, the consolidation of coins contradicts the idea of stacking implemented in the package - many small coins are better for stacking than one large one. Also, this process tends to divide the coins used. In general, creating a separate function for consolidating/dividing coins with manual control may make sense. The functionality is similar to sending to another person. I'll keep this in mind, but I'm not sure I'll be able to set aside time for this in the near future.

Help in mind the Pull Request would certainly not hurt here;)

[the-real-vortex-v]

Also, the consolidation of coins contradicts the idea of stacking implemented in the package - many small coins are better for stacking than one large one. Also, this process tends to divide the coins used. In general, creating a separate function for consolidating/dividing coins with manual control may make sense. The functionality is similar to sending to another person. I'll keep this in mind, but I'm not sure I'll be able to set aside time for this in the near future.

Help in mind the Pull Request would certainly not hurt here;)

Yes I was thinking about the staking thing the other day. The only issue I have is that when you get lots and lots of small inputs then it costs a huge amount (relative to the value of the input) to actually do anything with the coins. One way to fix this might be to stop splitting the inputs in half and adding the stake win to only one input. So for example you could instead split the stake win in half and add each half to the split inputs. You still need to create two new inputs from the old input anyway. So why not make them both bigger (to avoid lots of small inputs) ?

I assume lots of small stakes are better because less coins are taken out of your pool at once thus reducing stakes. How ever too many inputs can cause the software to run slowly when you want to do anything.

Also the TX size check is in the code that creates the new transactions. One of the things I'm talking about is to add that check into the UI section in relation to selecting the inputs. Waiting until you've selected them all and then doing the check is rather annoying. I'd display the TX size of the current selected inputs (in say blue when you select an input to add) and if it overflows display it in Red and then giving a warning or something like that.

I'm thinking you could copy and paste the TX size check basicly from the other function. I'm assuming it'd be like 4 lines of code. Calculate size of TXs, if it's bigger than maxtx then display an error and then unselect the last selected TX/don't select the selected tx etc.

[andyoknen]

Manual selection of transaction inputs? It sounds interesting.

I also thought now about the configurable value that the stacking process would strive for - now it's 5 coins for one output. For large wallets (say more than several thousand coins), it would make sense to increase this value, let's say up to 50 coins per output. This will not have a negative impact on stacking, but it will give fewer outputs in the wallet.

[the-real-vortex-v]

Manual selection of transaction inputs? It sounds interesting.

That's just coin control. In the UI you turn coin control on then you can manually choose which inputs to join together to make your desired output/transaction.

I also thought now about the configurable value that the stacking process would strive for - now it's 5 coins for one output. For large wallets (say more than several thousand coins), it would make sense to increase this value, let's say up to 50 coins per output. This will not have a negative impact on stacking, but it will give fewer outputs in the wallet.

It should be at least based on the cost to send coins on the network. I.e you want it at least 2 to 5 orders of magnitude more than the current cost to send the transaction. So if it costs 2000pkoshi to send a transaction then times that by 100000 or so to get the size of the transaction you want to make. So if it costs 0.00002pkoin to send a transaction then make the minimum transaction 1pkoin.

Also what I was saying (to clarify) is that currently it splits a transaction (say 10pkoin) in half and only adds the stake win to one half. So you end up with a 5pkoin input and a 7.44pkoin (or so) input. It'd be better to add half of that 2.44pkoin to each half so make 2 transactions of 6.22pkoin instead. This will go a long way to fixing the small inputs issue. Each half will end up growing a little rather than one half being forced towards 0.

[andyoknen]

In general, I think there is agreement on what needs to be done. Now it remains to find time for this..