1 2017-10-27 00:41:04 <xmlnewbi> so I have a rather active node sending a lot of txs, and for some reason my txs are not on chain. when I try to rebroadcast im getting this, 64: too-long-mempool-chain. I dont understand how sendtoaddress would spend something with too many unconfirms? that means that im trying to spend the same change 24+ times right?
 2 2017-10-27 00:41:24 <xmlnewbi> im on 0.15.0.1
 3 2017-10-27 01:26:36 <molz> xmlnewbi, you have 64 unconfirmed txs in a chain?
 4 2017-10-27 01:29:27 <esotericnonsense> xmlnewbi: imagine that for example you begin in a state in which you have five unspent outputs
 5 2017-10-27 01:29:59 <esotericnonsense> xmlnewbi: you send five transactions of minimal value, you now have five unconfirmed transactions
 6 2017-10-27 01:30:35 <esotericnonsense> if you send another five transactions of minimal value you have five chains of length 2
 7 2017-10-27 01:31:21 <esotericnonsense> if the transactions are not of minimal value (where I define this as being e.g. 100x smaller than the smallest initial unspent output) then eventually you'll be combining them
 8 2017-10-27 01:31:34 <esotericnonsense> and then you just need 20 tx to have a chain that's too long
 9 2017-10-27 01:31:55 <esotericnonsense> ~20, rather
10 2017-10-27 01:33:00 <esotericnonsense> (I am assuming here that the coin selection logic will prefer a 1-chain or set of 1-chains over a 2-chain regardless of size. it might be that actually it ignores some of the smaller chains and tries to spend from the longer ones to reduce size/fees paid).
11 2017-10-27 01:33:16 <esotericnonsense> then it'll hit the limit faster
12 2017-10-27 01:34:19 <esotericnonsense> if you need to send a bunch of transactions quickly it would make sense to use sendmany anyway, then you'll both save on fees and run into this issue far less frequently