 |
January 15, 2013, 04:37:16 PM |
|
Not easily. It will require some manual modification of the wallet file. Tools exist for the QT client but I don't know if they exist for multibit. Even then it isn't that simple. Nodes which have seen the original tx will see the "new" tx as an invalid double spend and refuse to relay it. For obvious (intentional double spend) reasons there is no protocol command to "undo" a tx. Miners (depending on their memory pool rules) may drop the new tx as long as the old tx is in their memory pool. To prevent tx from remaining in the memory pool forever, nodes will drop old unconfirmed tx from the memory pool after enough time however as long as the tx remains in the wallet file of the original client it will periodically rebroadcast it until it detects that it is in a block.
So removal requires
a) manually removing the tx from the wallet file (so client "forgets" about it)
b) waiting long enough for nodes in the network to forget the tx (because the client isn't "reminding" them of the old tx).
c) create a new spend.
If that sounds like a mess well it is and that is one of the effects of a decentralized network. Even if you can absolutely control your client you can't guarantee the behavior of other nodes.
The "solution" is actually simpler. There are two seperate categories.
a) truly invalid transactions (double spends, invalid signatures, malformed tx, violation of protocol rules, etc).
b) valid transactions without a fee (but not in violation of the anti-spam rules) which may be unattractive to miners.
For truly invalid transactions there is no easy fix. The fix is don't make invalid tx. A good client will prevent you from making invalid transactions. Don't use patches that remove things like the anti-spam rules, and don't manually (use QT rawtransaction API) create transactions.
For valid tx with no or low fee the recipient can include that unspent output in a tx which has a fee. Currently miners don't look "forward" to see if low/no fee tx are the input for higher fee tx but they can and likely will (especially as fees become more important).
Example:
Address A sends coins to Address B in a tx (t1) with no fee.
Address B includes that in a tx(t2) to Address C with a fee.
A -(t1)-> B -(t2)-> C
A mining node sees that t2 is a paying tx and requires t1 an unpaid tx. Both tx can be included in the same block but t2 can't be included without t1 (it would make the block invalid to have a tx with an unconfirmed input in it). The mining node includes both in the same block in order to collect the tx fee. This would be especially useful for merchants. Merchants could combine multiple no fee tx from customers into another tx with a fee back to themselves with a fee to force encourage miners to include all the tx in the next block.
|
