Topic: Resending bitcoins (Read 761 times)
Bump?
I use Multibit, and I needed to send a little money to many people but didn't know how to send it within one block, with just one fee.
How do you create multiple transactions in one block, with only one transaction having a fee?
Is that a configuration within Multibit?
How do you create multiple transactions in one block, with only one transaction having a fee?
Is that a configuration within Multibit?
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 toforce encourage miners to include all the tx in the next 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
Bump.
Hello,
The following never happened to me, but I can just imagine the case, so I wanted to ask you:
Imagine, in the future, sending some bitcoins without a transaction fee.
No miner picks it up because it doesn't have a transaction fee.
On a Multibit, is there a way to cancel the transaction and resend it with a transaction fee?
Thank you,
Ven
The following never happened to me, but I can just imagine the case, so I wanted to ask you:
Imagine, in the future, sending some bitcoins without a transaction fee.
No miner picks it up because it doesn't have a transaction fee.
On a Multibit, is there a way to cancel the transaction and resend it with a transaction fee?
Thank you,
Ven
Jump to: