Quote from: Ephebus on September 13, 2013, 02:17:52 PM

That raises another interesting question: how to make that broadcasting stop in case the sender realizes he has set the transaction fee too low and wants to correct it?

It can be done but it should be considered a hack as a last resort. You will need to use the pywallet tool and delete the transaction from your wallet. You will want to make separate backups BEFORE and AFTER the update. Then you will need to ensure you node stays offline until other nodes forget about it. If your node immediately goes online there is a chance another node will relay your tx back to you and your wallet will happily include it in its history (essentially undoing your erase so that is why I said make a post edit backup). Still it can be done. Eventually the entire network will drop your old tx and without your node to "remind them" by rebroadcasting it will be like the original tx never existed. You can then create a new tx.

You may wonder why doesn't the client just allow you to cancel. Due to the way Bitcoin works you have no control over what other nodes do so while you can trivially "undoing" a tx locally you can force other nodes to also perform that undo. This means your node will be out of sync with the rest of the network. It is a common abstraction to think of "the network" as this unified system but really it is more like a sea of independent nodes which speak the same language. So what kind of weird problems could occur if there was a "cancel" button in the client.

a) You can cancel a tx locally but it still end being confirmed in a block.
b) You can cancel a tx locally but your peers reject your modified tx because they still see the original as valid and thus the replacement is a fraudulent double spend attempt.
c) You can cancel a tx locally and create a new one but it happens to use different coins. Both tx end up being included in a block and you double paid.
d) You can cancel a tx locally and pay a different person with those coins but the original tx confirms and now to the second person it looks like you performed a double spend.
Starting to see while you can technically cancel a tx locally (just delete it and stop broadcasting it) allowing users to do that is likely going to create a huge amount of confusion and chaos.

Still this entire issues has less to do with fees and more to do with the person running the casino has no clue what they are doing. Not only did they send low priority tx w/ no fees (which means many nodes won't even relay them due to "spam" prevention) but the tx had NO CHANCE of being included in a block even with a massive fee. The reason is that the inputs for the tx (all inputs are outputs of prior txs) are from txs (parents) which aren't confirmed either and one of those has the same issue (grandparent tx is unconfirmed). The operator is utterly incompetent. Worse the default client prevents you from making these types of mistakes. You can't spend unconfirmed outputs and you can't bypass the min mandatory fee on low priority txs. So the operator is using raw txs. Raw txs plus incompetence is a good way to lose Bitcoins forever. You can create raw tx which result in the permanent loss of Bitcoins. It is a tool for experts only, experts who have done extensive testing.

As for "I want to hack my client because I don't want to pay fees" mentality. Really this is cutting off your nose to spite your face. The "min mandatory fee" ONLY applies to low priority txs and (post v0.8.2) is 0.1 mBTC or about $0.01. It exists as an anti-DOS mechanism so even if you bypass it by hacking the client (or using raw txs) there is a good chance not all tx wil be relayed by all nodes.

The simpler longer term solution for unconfirmed txs is for something which has been proposed called the "child pays parent" patch. It doesn't need to change the protocol just how miners pick txs. Currently miners will only include txs in a block if the inputs are already confirmed. So you can't confirm a tx (tx A) which won't confirmed by spending it (tx B) because even if tx B has a fee no miner will include it until tx A has been confirmed. With "child pays parent". Miners will look backwards to find the unconfirmed inputs and include them as well. So if miner accepts tx B (which has a fee) and tx B has tx A (unconfirmed) as an input then the miner would include both in the block. Of course that still won't solve general incompetence which is the larger issue not the network.