Coin selection, CreateTransaction, MAX_STANDARD_TX_SIZE #5782

1. 
   dexX7 commented at 10:35 am on February 10, 2015: contributor

   While regtesting with bitcoin-spock I noticed at some point the transaction creation via sendtoaddress -> CreateTransaction() fails, because the created transaction is larger than MAX_STANDARD_TX_SIZE.

   During the process a lot of raw transactions are created, which have smallish outputs and when then using sendtoaddress, it appears to attempt to create a transaction that spends too many of those dust-ish outputs.

   The transaction to create does not have many outputs, but it looks like it’s caused by the coin selection, which selects too many inputs. Testing was done with a 0.9 branch, but on the first glimpse I believe this issue is as well be present in 0.10. If this is a known issue, and if there is already a guard against this behavior, I’d be happy about a hint.

   Sorry in advance, I do not have a test script to reproduce this issue in an isolated manner. A potential fix would probably require to adjust the coin selection, so that it selects a combination of coins, which, in addition to the size of the rest of the transaction, is still smaller than the limit.

2. laanwj added the label Wallet on Feb 10, 2015
3. 
   laanwj commented at 11:01 am on February 10, 2015: member

   There have been some modifications to coin selection algorithm, maybe they improve things, see e.g. #4906
4. 
   dexX7 commented at 1:18 am on February 11, 2015: contributor

   Thanks for the link! Unfortunally it doesn’t seem to be related, but this issue is certainly something that probably won’t appear outside of a testing environment. I created a test for it nevertheless:

   https://github.com/dexX7/bitcoin/blob/qa-coin-selection-limit/qa/rpc-tests/coinselection_size_limit.py

   The problem is that the coin selection doesn’t relate to the transaction size at all. I came up with three scenarios, all failing at the moment:

   Scenario 1:

   • The actor starts with 1x 50.0 BTC and 1000x 0.05 BTC (100.0 BTC total) unspent outputs
   • Then tries to spend 49.5 BTC
   • The 50.0 BTC output should be selected, because the transaction would otherwise be too large

   Scenario 2:

   • The actor starts with 500x 0.1 BTC and 1000x 0.05 BTC (100.0 BTC total) unspent outputs
   • Then tries to spend 49.5 BTC
   • A combination of coins should be selected, such that the created transaction is not too large

   Scenario 3 (available as RPC test):

   • The actor starts with 1x 50.0 BTC, 500x 0.1 BTC and 1000x 0.05 BTC (150.0 BTC total) unspent outputs
   • Then tries to spend 49.5 BTC
   • A combination of coins should be selected, such that the created transaction is not too large

   For each scenario at least one solution exists, where a combination of coins results in a transaction that has a size of less than MAX_STANDARD_TX_SIZE.

5. 
   maflcko commented at 1:11 pm on April 29, 2018: member

   Is this a duplicate of #1643?
6. 
   dexX7 commented at 11:25 pm on April 29, 2018: contributor

   @MarcoFalke: looks like both issues tackle coin selection, while @dooglus’ is about minimizing fees, mine is about making sure the transaction creation doesn’t fail to begin with. Though optimizing fees also results in small transactions.

   What’s on top: there isn’t a check during coin selection, whether the transaction is still within MAX_STANDARD_TX_SIZE.

7. 
   murchandamus commented at 3:27 pm on July 25, 2022: contributor

   From a quick glance, it looks to me that we still not check for the maximum weight during coin selection. So, while the much lighter modern input types make it even less likely that the max weight would be hit and at high feerates we deliberately aim for a small input weight, I don’t think that we currently explicitly prevent that outcome during coin selection when it’s in the consolidatory feerate range.

   It would probably be a good first issue to check whether a selection result will be smaller than the maximum weight and to discard a selection result if not. Hopefully the other selection result candidates or a later back-off iteration would find a solution that fits then, but a slightly more involved task could be to add logic that guides coin selection to avoid exceeding the maximum weight if possible.

8. achow101 referenced this in commit ef744c03e5 on Dec 6, 2022
9. achow101 closed this on Dec 6, 2022

   ---

10. bitcoin locked this on Dec 6, 2023

Contributors
dexX7 laanwj maflcko murchandamus

Labels
Wallet