Author

Topic: Bug (?) - Inputs from unconfirmed transaction change addresses (Read 1059 times)

hero member
Activity: 715
Merit: 500
Bitcoin Venezuela
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?
newbie
Activity: 40
Merit: 0
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.
legendary
Activity: 1896
Merit: 1353
note that some miners (eligius) implement a "child pays for parent" policy:
https://github.com/bitcoin/bitcoin/pull/1647
newbie
Activity: 40
Merit: 0
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.
Jump to: