Fee discovery

[DannyHamilton]

Just to be clear, the above is a complete, working, implementation of the idea. Any wallet software that handles double-spends and mutability correctly can implement it without much difficulty.

I haven't had a chance to look at it yet, but I wonder how you get around the problem of the vast majority of nodes refusing to relay or accept a transaction that spends the same inputs as a transaction already in their unconfirmed transaction queue?

[1538089887]

1538089887

[1538089887]

1538089887

[1538089887]

1538089887

[piotr_n]

See my replace-by-fee-tools, specifically bump-fee.py for an alternative based on increasing your bid. Not always convenient by itself - fee estimation is still useful - but being able to increase fees after the fact lets you be much more aggressive in your fee estimates.

Yeah, but this isn't trivial to implement and also creates additional traffic.
Sure, adjustable fees is a solution, but there is a long way for it.
Besides, one approach to the problem does not exclude another.

Just to be clear, the above is a complete, working, implementation of the idea. Any wallet software that handles double-spends and mutability correctly can implement it without much difficulty.

I understand. But it is a different approach to the solution.
Some people want to just send transaction with a fee that the minters require at a certain moment in time.
And then they want to forget about the unconfirmed transaction, knowing that it will be mined as soon as any of the miners, asked for the minimal fee, brings in a new block.

Your proposal is about waiting for a transaction to not get confirmed - and only then increasing the fee.

[piotr_n]

What I proposed is simple, very easy to implement and it achieves the goal.

Great!

Implement it.  I look forward to seeing it in action.

Thanks for all your hard work.

Get yourself together, man.
I told you that I look for allies in this project. And we had already established long ago that it wasn't you.

[kingscrown]

decent idea but not sure if its that easy to count

[Peter Todd]

Just to be clear, the above is a complete, working, implementation of the idea. Any wallet software that handles double-spends and mutability correctly can implement it without much difficulty.

I haven't had a chance to look at it yet, but I wonder how you get around the problem of the vast majority of nodes refusing to relay or accept a transaction that spends the same inputs as a transaction already in their unconfirmed transaction queue?

I don't have to actually! The replace-by-fee supporting nodes preferentially peer with each other, so there's always peers to relay your transactions. Since those nodes are well connected they have a pretty good shot of getting your tx to a miner who is accepting a higher fee but not the lower one you tried first. In practice this already works really well when bumping fees past the 0.8/0.9 fee drop, or between the various 0.8/0.8 tweaks to fee acceptance.