Are you saying that this is something that already happens in the code or is this something you are proposing to be implemented to solve the problem in future?
It's something I'm proposing.
Could you please also be a little bit more explicit as to how the input cancelling would solve the problem?
As a solution to the general problem of transactions that will never get into a block, sending a conflicting transaction (a transaction sharing one of the inputs to the "stuck" transaction) is guaranteed to cancel the old transaction if the new transaction gets into a block (and the normal SIGHASH mode is used). You can't just mark the old transaction as "canceled" without creating a conflicting transaction, since the old transaction might go through eventually, which would often be bad.
Sending just one of the stuck inputs at a time increases the chances that your new transaction will go through.
This isn't necessary if you
know the transaction is already conflicting with something in the block chain, but often a transaction will not be accepted due to fee problems, and lightweight clients
won't know about already-conflicting transactions.
And why only cancel one per day if more are eligible for cancellation?
There isn't a major reason why you couldn't do that, though if you sent all the transactions at once, then your peers would probably reject all but the first. Also, it seems dangerous to have many conflicting transactions floating around: if an attacker gets control of the network, they could do some extra things to transactions based on yours.
Show Posts
