Smarter "double spending" detection #3853

One issue I see over and over is new users worrying about their transactions not getting confirmed after a few hours/days due to a low transaction fee. They typically panic a little and wonder if they lost their bitcoin or wonder when it will safe to send a new transaction again. Bitcointalk.org and /r/bitcoin are full of those posts.

This could be solved by having a "Resend with higher transaction fee" option in bitcoin wallets. This option would simply create a new transaction identical to the previous one but where the user could chose to assign a higher fee.

This could be implemented by adding new TXIN(s)/TXOUT (change address) to the transaction without changing anything else. Of course, this option would only be available when the wallet has spendable outputs that were not spent by the original transaction.

One problem with this solution is that even if a bitcoin wallet wanted to implement it, the second transaction would be detected as a double spend and would not be relayed by the network.

Would it be possible to have smarter double spend detection where a transaction wouldn't be considered as a double spend if it sends the same amounts to the same TXOUTs as the original (in other words, if it is a superset of the original transaction)?

Also, any thoughts on the proposed solution?

Related: https://github.com/spesmilo/electrum/issues/615

The first, best solution is for wallets to send transactions with the correct fee the first time.

Do you really see "over and over" users with stuck transactions with Bitcoin-Qt? The only issue I've seen over-and-over is users who are not yet done syncing the block chain worried that a transactions TO them is not shown in their wallet.

I do occasionally hear of people running ShadowOfHarbringer's "send with zero fees" patch getting themselves into trouble, but that is why that patch is a bad idea.

Or are you talking about this issue arising in the context of some other wallet software?

As for your particular scheme: please help test #3354 "Relay first double spend" which is a slightly different scheme that is more resistant to flood-the-network-with-double-spend denial-of-service attacks. Also help review/test #3753 to expire unconfirming transactions from the memory pool.

I am in precisely this situation. I clicked on blockchain.info ( my hotwallet ) frugal option because I was consolidating funds and doing some purchases and now I have a bunch of transactions stacked up all with 0 fees. Oddly with Armory (which I can't get working on Linux ) my transactions would confirm faster even with smaller fees, so this behavior is sorta unexpected.

My proposal would be to have the ability to bump a transaction somehow by ADDING just the fee. This would lead to positive behavior since it would give ANYONE ( buyer/seller/3rd party ) the opportunity to throw some more coin into the pot to pay for better service.

How feasible this would be, no clue. Just throwing it out there. I would GLADLY pay to fix the issue if I could now.

My 3.4cents worth.

The blockchain.info wallet behavior is unique to them rather than anything to do with the network. If they can't work out how to broadcast their clients transactions properly, that's their problem. If you have an issue with their fee policy then raise a ticket with them.

@bf0d7998-81ec-48d1-b236-076ed3c77581 oddly they all just released. ((( me reaches for roll of tinfoil and starts making cone shapes for family and dogs))

The point is .. there is no standard in terms of how transactions happen and when they happen. One would imagine that there would be some expectation of "guaranteed" deliverly based on what one picks when one creates the transaction ? i.e. Very High = next block = 10 minutes . or so .. etc .. down to 0 fees = SOL 2 days please wait.

To say .. well dude.. you picked blockchain.info and you decided to go with 0 fees, make a ticket with them, not our problem seems a little uncaring. Which is fine, but it still remains a big mystery .. WHEN WILL THE SHIT CONFIRM ... WHO KNOWS ? Today ? Tomorrow ? Fuck knows !?! is not a way to run things,

It's not a process you can realistically predict, just as you can't predict who will solve the next block and when. You might get Eligius who pack their blocks like there's no tomorrow, or Discus Fish who decided to make a lazy 40 transaction block, you might even get GHash.io who decide they're going to double spend again and invalidate your transaction. You can't guarantee anything to the client at all, even if they paid a 5BTC fee there's no certainty they'll be in any of the next 60 blocks.

My questions is simple : Why not ? All the known factors are in play. i.e. hashrate etc what is the random part about this ?

edit: again I am ignoring implementations because those are generally shit at best. .

you can't predict who will solve the next block and when

That's literally all there is too it. Different pools play by different rules.

@bf0d7998-81ec-48d1-b236-076ed3c77581 I think you are being overly cynic. I'm sure there's a way we can solve that problem if we think hard enough. It seems my proposed solution would at least enable people who miscalculated the fee to rectify their transaction immediately without having to wait a few days. I will try to have a look at #3354 when I get some time.

@olalonde If you happen upon a solution, be sure to let the core developers know.

Either implementing #3354 or relaying double spends that have at least four times the fee of the previously observed attempt and have a fee above some threshold would enable anyone to resend their transaction with higher fees.

I don't think a GUI or RPC command is nessesary for this in the reference implementation, but support at the network level could be a useful addition.

@leofidus that's a good idea. It would make spam costly while letting users reissue their transactions with a higher fee. Any thoughts @gavinandresen?

I think this is fixed/made redundant by RBF and bumpfee support