The only way to cancel an unconfimed transaction is to make it invalid and the only way to make a valid transaction invalid is to spend one of its inputs and get this confirmed in a block before the unwanted transaction makes its way into a block.
The problem I see here is that as long as the unwanted transaction is already hanging around in the miners' memory pools the new transaction would not even be allowed to enter their memory pools.
Topic: Add option to add a fee to dead transactions - page 2. (Read 2595 times)
I think the way it is supposed to work with the system the way it currently is, is not that you change an existing pending transaction, but you spend the same coins again with different fees attached and let the network sort out the doublespending weeding out whichever copies of the transaction doesn't get done first.
Yes, that is what I am suggesting. You just spend the coin a second time and once one of the transactions is accepted, then the other transaction is automatically cancelled.
You'd have to empty the account you were sending from. Otherwise, nothing would prevent both transactions from going through.
That isn't true. Your account balance is entirely virtual. The money is made up of lots of coins (actually outputs from accepted transactions).
Assuming you own coins A, B and C, you can send any number of transactions with those as inputs.
Transaction 1 (fee = 0):
Inputs:
A: 0.4
B: 0.2
Outputs:
D: 0.5
E: 0.1
Transaction 2 (fee = 0.001)
Inputs:
A: 0.4
C: 1.0
Outputs:
D: 0.5
E: 0.899
The E coin is the change coin and it would be set to only be spendable by someone who knows the private key linked to your address.
You'd have to empty the account you were sending from. Otherwise, nothing would prevent both transactions from going through.
Update: THIS IS INCORRECT. See next message. Mea culpa.
Update: THIS IS INCORRECT. See next message. Mea culpa.
I think the way it is supposed to work with the system the way it currently is, is not that you change an existing pending transaction, but you spend the same coins again with different fees attached and let the network sort out the doublespending weeding out whichever copies of the transaction doesn't get done first.
The thing is the client currently locks out 'coins already included in an outgoing transaction, even if unconfirmed, and got no means of letting the user try to send those coins again.
I'm not sure what changes would be necessary to allow people to change existing transactions instead of just repeating transactions with different fees.
If i said anything wrong please someone that understands the system better correct me, aight?
The thing is the client currently locks out 'coins already included in an outgoing transaction, even if unconfirmed, and got no means of letting the user try to send those coins again.
I'm not sure what changes would be necessary to allow people to change existing transactions instead of just repeating transactions with different fees.
If i said anything wrong please someone that understands the system better correct me, aight?
If a user sends a transaction with insufficient fees, it ends up lost in limbo and never confirms.
However, there is no downside to allowing a client to increase the fee for a transaction after it has been sent out.
This would resend the transaction except it would reduce the output and/or increase the inputs, so as to include a fee (and recalculate any hashes/signatures).
If the original transaction happens first, then great, you got a free transaction. Otherwise, the updated transaction is processed as it meets the fee requirement.
This would allow market forces to kick in, rather than requiring the fee rules to be incorporated into the default client. Users would get a feel for what kind of fees are required to get transactions accepted by the miners/forwarders.
However, there is no downside to allowing a client to increase the fee for a transaction after it has been sent out.
This would resend the transaction except it would reduce the output and/or increase the inputs, so as to include a fee (and recalculate any hashes/signatures).
If the original transaction happens first, then great, you got a free transaction. Otherwise, the updated transaction is processed as it meets the fee requirement.
This would allow market forces to kick in, rather than requiring the fee rules to be incorporated into the default client. Users would get a feel for what kind of fees are required to get transactions accepted by the miners/forwarders.
Jump to: