I was thinking about Git... Is it possible to backup / restore (effectively cancelling unconfirmed transactions) your wallet by transforming the ~/.bitcoin into git local repository?
So, after each transaction (sending or receiving), a git commit occurs... Or something like that... It would be possible to "undo" transactions easily (for git users at least)... Going back and forward into transaction history...
http://en.wikipedia.org/wiki/Git_(software)
I'm going to try that, do I need to shutdown bitcoin-qt before running git-stuff to commit wallet changes?
Best,
Thiago
Topic: Cancelling unconfirmed transactions - page 3. (Read 21112 times)
Also most mining pools limit incoming connections as a pool wants to get a block to other miners (namely other large pools) quickly. Having a bitcoind bogged down with hundreds of connections doesn't help orphan rates. In theory a miner's optimal peer configuration would be direct connections to all other mining pools and then a few connections to major tx hubs (exchanges, blockchain.info, major merchants, etc).
If there was a significant demand for non-standard transactions they could set up a separate node, perhaps only available to subscribers, in order to accept them. Of course the people wanting to send these non-standard transactions would need to pay for the additional risk of orphaned blocks, since they wouldn't be in the signature cache of other nodes. 
It would be useful to include a "special exception" to the double spend rules. Nodes will drop double spends of outputs currently in their memory pool. A double spend which consists of the exact same inputs and same outputs and only differs in the amount of the fee to miner by a preset amount (say up to 5x min fee) could be allowed to "pass through" the double spend shield. This would allow users to "upgrade" a transaction from low/no fee to standard/higher fee and get it to miners.
Mining pools could offer this as a service by setting up a node that allows for lots of direct connections and bypasses the normal relaying rules, and which immediately includes qualifying transactions in the next block.They could but for it to be useful it would need to be integrated into the client. If you need to hack the wallet.dat to force a change then you might as well just delete the offending transaction and wait for the network to forget about it.
Also most mining pools limit incoming connections as a pool wants to get a block to other miners (namely other large pools) quickly. Having a bitcoind bogged down with hundreds of connections doesn't help orphan rates. In theory a miner's optimal peer configuration would be direct connections to all other mining pools and then a few connections to major tx hubs (exchanges, blockchain.info, major merchants, etc).
It would be useful to include a "special exception" to the double spend rules. Nodes will drop double spends of outputs currently in their memory pool. A double spend which consists of the exact same inputs and same outputs and only differs in the amount of the fee to miner by a preset amount (say up to 5x min fee) could be allowed to "pass through" the double spend shield. This would allow users to "upgrade" a transaction from low/no fee to standard/higher fee and get it to miners.
Mining pools could offer this as a service by setting up a node that allows for lots of direct connections and bypasses the normal relaying rules, and which immediately includes qualifying transactions in the next block.
It is possible to cancel a transaction although it is intentionally not user friendly.
The first thing to know is that all nodes will forget about transactions after a few hours. This is intentional otherwise someone could bring the network to its knees by spawning a huge number of low/no fee transactions when the blocks are close to max size. Memory Pool spam vs blockchain spam.
The problem is your client is very diligent. It continually looks to see if a transaction it sent has been including in a block. If it hasn't then periodically it will notify its peers and the transaction will propogate the network again. Any node which has forgotten about the tx will be informed of it again and the process will continuing infinitely.
To cancel a transaction you must delete it from your wallet.dat. This will prevent your client from keeping it alive. Eventually all nodes will drop it from their memory pool automatically.
It would be useful to include a "special exception" to the double spend rules. Nodes will drop double spends of outputs currently in their memory pool. A double spend which consists of the exact same inputs and same outputs and only differs in the amount of the fee to miner by a preset amount (say up to 5x min fee) could be allowed to "pass through" the double spend shield. This would allow users to "upgrade" a transaction from low/no fee to standard/higher fee and get it to miners.
The first thing to know is that all nodes will forget about transactions after a few hours. This is intentional otherwise someone could bring the network to its knees by spawning a huge number of low/no fee transactions when the blocks are close to max size. Memory Pool spam vs blockchain spam.
The problem is your client is very diligent. It continually looks to see if a transaction it sent has been including in a block. If it hasn't then periodically it will notify its peers and the transaction will propogate the network again. Any node which has forgotten about the tx will be informed of it again and the process will continuing infinitely.
To cancel a transaction you must delete it from your wallet.dat. This will prevent your client from keeping it alive. Eventually all nodes will drop it from their memory pool automatically.
It would be useful to include a "special exception" to the double spend rules. Nodes will drop double spends of outputs currently in their memory pool. A double spend which consists of the exact same inputs and same outputs and only differs in the amount of the fee to miner by a preset amount (say up to 5x min fee) could be allowed to "pass through" the double spend shield. This would allow users to "upgrade" a transaction from low/no fee to standard/higher fee and get it to miners.
It's not a hard rule (in the sense of "a client that does this will create an invalid fork") that the newer transaction HAS to be ignored, no matter what, but currently this is the case.
Hey,
wouldn't it be a realistic scenario, that the transaction without fee gets just ignored by the miners. I mean, if you have 1 BTC and try to make a transaction without fee. Than you wait, and wait, wait and nothing happens. Than you try the same transaction with 0.001 BTC fee and the miners include that transaction into a block and the other transaction never will, because it is invalide? Or is there currently a hard rule, that the later transaction will always be ignored?
greetings
wouldn't it be a realistic scenario, that the transaction without fee gets just ignored by the miners. I mean, if you have 1 BTC and try to make a transaction without fee. Than you wait, and wait, wait and nothing happens. Than you try the same transaction with 0.001 BTC fee and the miners include that transaction into a block and the other transaction never will, because it is invalide? Or is there currently a hard rule, that the later transaction will always be ignored?
greetings
I thought I have seen Gavin somewhere talking about adding fees to already existing transactions... am I mistaken ?
I was now thinking of the following scenario: somebody tries to be a cheapass by not adding a fee to his transaction, transaction volume picks up forever, and the transaction is stuck in limbo forever.
There was a feature that was written but never released in which the child could pay for parent. What this means is that the code that determines if the fee is appropriate will also consider any other transactions that depend on this transaction and what are the fees for those transactions. That way the miner can receive the fee for processing both the parent and the child.
- https://github.com/bitcoin/bitcoin/pull/1647
That would give the recipient of the payment a method to pay an additional fee after the sender has broadcast the transaction.
There is no cancellation available at the protocol level. The best one could do would be to double-spend a duplicate transaction. Clients consider spent = spent, the spent funds being removed from your balance and unavailable, even if the transaction never will confirm.
The way a client could do this would be to offer a "modify and retransmit" feature, allowing one to re-spend the identical inputs and outputs of a transaction with more fees (adding more inputs if needed to increase the fee). Implementing a double-spend feature with this method shouldn't make an unconfirmed payment less trustable if the resent payment was recognized as a replacement.
The reference client doesn't let you create inadequately-fee'd transactions, so this is a feature unnecessary in any client that understands the rules. Only if larger-than-minimum fees become required for timely processing in the future, by everyone else paying more than standard fees for preferential treatment on an extremely busy network, would this be useful. I would expect new clients which start automatically recommending higher fees based on network activity if Bitcoin becomes this busy.
The way a client could do this would be to offer a "modify and retransmit" feature, allowing one to re-spend the identical inputs and outputs of a transaction with more fees (adding more inputs if needed to increase the fee). Implementing a double-spend feature with this method shouldn't make an unconfirmed payment less trustable if the resent payment was recognized as a replacement.
The reference client doesn't let you create inadequately-fee'd transactions, so this is a feature unnecessary in any client that understands the rules. Only if larger-than-minimum fees become required for timely processing in the future, by everyone else paying more than standard fees for preferential treatment on an extremely busy network, would this be useful. I would expect new clients which start automatically recommending higher fees based on network activity if Bitcoin becomes this busy.
As far as I know something like this does not yet exist and yes, imho this is a far more pressing issue than MAX_BLOCK_SIZE.
There might be problems for services that allow 0-confirmation transactions to already gain some kind of access/benefit if you implement a "currently pending transactions" screen with a "cancel" buttin next to each one - and also there might be some flooding issues if you can just create and withdraw transactions at will...
A solution might be to drop unconfirmed transactions out of the memorypool after 1008 blocks (~1 week) automatically and after 6 blocks (~1 hour) upon explicit request. Until then other clients will see other transactions with the same input(s) as a double spend and not relay them. I don't know if this should be a hard rule though, seems rather like a "nice thing to do" rule of thumb towards people who get a transaction stuck in limbo.
There might be problems for services that allow 0-confirmation transactions to already gain some kind of access/benefit if you implement a "currently pending transactions" screen with a "cancel" buttin next to each one - and also there might be some flooding issues if you can just create and withdraw transactions at will...
A solution might be to drop unconfirmed transactions out of the memorypool after 1008 blocks (~1 week) automatically and after 6 blocks (~1 hour) upon explicit request. Until then other clients will see other transactions with the same input(s) as a double spend and not relay them. I don't know if this should be a hard rule though, seems rather like a "nice thing to do" rule of thumb towards people who get a transaction stuck in limbo.
Hi
As far as I am aware it is not possible to cancel unconfirmed transactions currently. If the block limit is maintained, this will likely lead to a scenario where first transactions without fees will go through in calmer moments, then not at all anymore.
I was now thinking of the following scenario: somebody tries to be a cheapass by not adding a fee to his transaction, transaction volume picks up forever, and the transaction is stuck in limbo forever. He might try a new doublespend with fee, but apparently that is not trivial either?
Would it be good to implement a "cancel unconfirmed transaction" option in the clients? Or does this already exist and is my information outdated?
As far as I am aware it is not possible to cancel unconfirmed transactions currently. If the block limit is maintained, this will likely lead to a scenario where first transactions without fees will go through in calmer moments, then not at all anymore.
I was now thinking of the following scenario: somebody tries to be a cheapass by not adding a fee to his transaction, transaction volume picks up forever, and the transaction is stuck in limbo forever. He might try a new doublespend with fee, but apparently that is not trivial either?
Would it be good to implement a "cancel unconfirmed transaction" option in the clients? Or does this already exist and is my information outdated?
Jump to: