Transcript for #bitcoin-dev 2017/10/27

00:41 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?
00:41 xmlnewbi im on 0.15.0.1
01:26 molz xmlnewbi, you have 64 unconfirmed txs in a chain?
01:29 esotericnonsense xmlnewbi: imagine that for example you begin in a state in which you have five unspent outputs
01:29 esotericnonsense xmlnewbi: you send five transactions of minimal value, you now have five unconfirmed transactions
01:30 esotericnonsense if you send another five transactions of minimal value you have five chains of length 2
01:31 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
01:31 esotericnonsense and then you just need 20 tx to have a chain that's too long
01:31 esotericnonsense ~20, rather
01:33 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).
01:33 esotericnonsense then it'll hit the limit faster
01:34 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