Bug (?) - Inputs from unconfirmed transaction change addresses

[running]

I have a slight bug - or maybe it can't be classified as bug, that's up to you.

I yesterday sent a transaction with a zero fee that was stuck for long hours before confirmation (10 hours, actually). That is fine, if I wanted it faster, I would pay higher fee. No problem there. (10 hours is still a lot, but hey, I paid nothing for it.)

However, when I wanted to send another transaction, even with high fee, that I wanted fast, Electrum used as an input the change address from the unconfirmed transaction, so I had to wait until that confirmed. I had enough money in other change addresses, but Electrum chose the unconfirmed one. That was dumb. (I have Electrum 1.7.1)

So, I propose: prioritize confirmed change addresses before the unconfirmed ones. I don't want to wait on transaction B because transaction A is stuck.

[1715087996]

1715087996

[1715087996]

1715087996

[ThomasV]

note that some miners (eligius) implement a "child pays for parent" policy:
https://github.com/bitcoin/bitcoin/pull/1647

[running]

note that some miners (eligius) implement a "child pays for parent" policy:
https://github.com/bitcoin/bitcoin/pull/1647

I am not sure what that means. (Sorry.)

What happened to me:

I sent from address A to address B with change C which had low fee and stayed unconfirmed for hours.

I then wanted to sent something to address D. Instead of using address E with confirmed bitcoins, electrum decided to post it from the address C, so I had to wait until the first transaction confirmed.

That's why I am saying Electrum should prefer using confirmed inputs as outputs.

[btcven]

note that some miners (eligius) implement a "child pays for parent" policy:
https://github.com/bitcoin/bitcoin/pull/1647

So a new transaction that get stuck because of an older unconfirmed tx can pay the fees of the old one and both got confirmed in the next catch. Right?