104

How Bitcoin Mining Works Bitcoin transactions are mined (processed) by Miners, and Miners want to benefit from their work. By mining transactions with higher fees, they make more money. Some miners can decide to mine all transactions no matter the fee but they still must compete with every other financially motivated miner. Why is it taking so long for my ...


37

As of Bitcoin Core 0.14.0, these are the ways a transaction can leave the mempool: The transaction was included in a block. The transaction or one of its unconfirmed ancestors conflicts with a transaction that was included in a block. The transaction was replaced by a newer version (see BIP 125). The transaction was at the bottom of the mempool (when sorted ...


30

Yes, there is a way to save a borked transmission. A restart of the wallet and some patience typically fixes the issue. How to stop/reverse a Bitcoin transaction without confirmations: Run bitcoind and with -zapwallettxes. This makes the wallet "forget" any unconfirmed transactions, thus enabling you to reuse their inputs. Create a new transaction to make ...


30

this is a generic answer applying to "light" wallets - I don't know much about the blockchain.info-wallet There are several approaches that may work. I'm not sure which methods are most easily available for a user of a blockchain.info-wallet, but probably #0a and #2, followed by #3, #0b and #1b. 0) Wait it out. 0a) Wait for the transaction to go through. ...


29

Most clients on the network have a transaction pool in their memory. The same basically applies to miners: they just dump the top 500KB (or some other value) transactions into a block, sorted by transaction fee (descending, of course). When there aren't many transactions, maybe because of a series of block in a short amount of time, it will be confirmed ...


22

In the case that your fee is too low: Now that child-pays-for-parent has been merged, you(or any of the recipients of your unconfirmed transaction) could spend the Bitcoin received and the fee associated with that second transaction will help prioritize the confirmation of the original transaction. This does require more fine grained control of which ...


17

Here is a guide for as many wallets as I could figure out how to perform an RBF with. This is adapted from my bitcointalk post: https://bitcointalk.org/index.php?topic=1802212.0 What is a "Stuck" transaction? How are they caused? A "stuck" transaction is a transaction which has remained unconfirmed for period of time which either the receiver or the sender ...


14

The incentive to mine on the currently longest chain is that there is a risk to the dishonest miner that honest, non-mining nodes may have already propagated the first block and hence reject and not propagate the second block found at an equal block height. As Proof of Work is not reusable this leads the dishonest miner to waste resources.


13

The RPC interface includes the getrawmempool command which returns transactions in your memory pool. Transactions stay in your memory pool until they're confirmed, so this is effetively a list your known unconfirmed transacions. Since getrawmempool returns only a list of transaction ids, you'll have to getrawtransaction <txid> for each transaction id ...


12

Bitcoin-Qt doesn't support anything like that. Theoretically: A transaction is canceled by publishing a second transaction which double-spends some of the coins used in the first transaction (this can be a send-to-self). If the second transaction is included in a block before the first one, the first one becomes invalid and can be considered fully ...


11

Rebroadcasting a similar transaction with a fee attached will invalidate the one that's waiting. Basically you initiate a double-spend and the new one (with a fee) will get confirmed. Once it's confirmed, the old transaction will be invalid and forgotten. Your client probably does not allow double-spend attempts, but it's possible via blockchain.info. ...


11

The other answers cover most useful information already, I'd like to add one point though: The fee estimation of most wallets has significantly improved since blocks have gotten full. If you're running an outdated version, it's likely that it is doing a bad job of guessing the fee. That may cause you to either overpay or your transactions not getting ...


11

Replace-by-fee means transactions spending the same coin to the same addresses are not considered double-spends by the network and are still relayed, as long as they pay a higher fee than the preceding transaction. Example: Alice pays Bob with a coin worth 1 BTC, sending 0.5 BTC to Bob, 0.49995 BTC to herself as change, and 0.00005 BTC to fees. Alice sees ...


8

-zapwallettxes removes all wallet transactions that are not in the blockchain. It can remove "stuck" transactions, although you don't need this feature in normal operations mode. Solution A) On Windows, you need to start the command line prompt (cmd.exe), go to your window search and enter "cmd" and start cmd.exe. Start bitcoin-qt with --zapwallettxes=1 C:...


8

There are a variety of different ways to construct a micropayment channel, but there are two designs that I think are particularly relevant to your question about "simple, one-directional, micropayment channels": Spillman-style micropayment channels: this was a commonly-described micropayment channel design prior to BIP65 (OP_CHECKLOCKTIMEVERIFY, CLTV). ...


7

If you are using Electrum, there is no equivalent to -zapwallettxes. The closest thing you can do is to restore your wallet from a seed. This will wipe your client of any unconfirmed transactions. Then, you can resend the transaction with a higher fee.


7

I recently sent 0.03 BTC to Satoshi Dice without a tx fee from a blockchain.info wallet. It stayed for about 3 days without being confirmed and it finally expired. At some moments while the tx was unconfirmed the network propagation was dropping to 2 nodes and then going back up to about 50 nodes. After it expired the sum of the transaction was added back to ...


7

Your client will have this marked as spent and will prevent you from sending any unspent coins included in the transaction while continuing to try to broadcast the original transaction. There is an easy solution, though. You simply need to dumpprivkey and add it to another client, where you can send the coins from this address to another, effectively ...


6

All three proposals attempt to solve the same problem, the issue of stuck transactions. Due to the behavior of Bitcoin Core with respect to double spends (they are silently dropped, and not relayed), it is impossible to spend outputs that you've used in an existing transaction. Typically this is a good thing, but there are a few cases where a user may have ...


6

In addition to Mark S.'s answer, since Bitcoin Core 0.12 there actually is an expiration in the mempool, which evicts unconfirmed transactions after N hours, where N is set by -mempoolexpiry, and defaults to 72 hours. This is not a reliable feature, as wallets (and really, anyone) can rebroadcast the transaction, but helps keeping the mempool fresh.


6

This is not a full answer, but a partial answer somebody may use as a stepping stone to craft a complete answer. E.g. blockchain.info shows both "received time" and the time of the block a transaction was included in. It appears to me that the "11 minutes" in the "Included in Blocks" time for this transaction corresponds to the difference between "...


6

There are 3 cases. Case 1a: if Fee(Tx1) < Dust Fee then Tx1 gets dropped by nodes that do not offer Free Relay Policy. Then all other transaction dependent on the outputs of Tx1 will never be committed to the blockchain, even though descendent transactions may or may not be accepted into the mempool of a subset of nodes in the network. Case 1b: if Fee(...


6

There is no fixed expiration time for each node, but the default setting is 72 hours. https://bitcoin.stackexchange.com/a/43165/24926


6

A specified locktime indicates that the transaction is only valid at the given blockheight or later. Since the locktime field indicated is 419382 and currently the latest blockheight as of 12th July 2016 1108 (AEST) is 420352 the transaction is now valid and can be included in a block by any miner that chooses to do so.


6

I've just visited #electrum on IRC to get some advice. While restoring from a seed may make your wallet forget a transaction and allow you to resend it with a higher fee, abpa there told me that this sometimes doesn't work because the server will remind the client about the transaction if it's still in the server's mempool. abpa suggested using child-pays-...


5

The command line option is -zapwallettxes This will clear unconfirmed transactions from your wallet. See https://en.bitcoin.it/wiki/Running_Bitcoin


5

If a transaction goes unconfirmed for too long, it will eventually disappear from the network. Most clients will remove it from their pool of unconfirmed transactions at some point. When most clients have removed it, you can go ahead and send the transaction again, this time with a higher fee. There's not a precise time when the transaction will disappear ...


5

You may ask viabtc.com to prioritize. https://pool.viabtc.com/tools/txaccelerator/


5

The upcoming release of the Bitcoin.org client, version 0.7, includes: getrawmempool


5

You are technically able to do this but it is strongly not recommended. A transaction can spend the output of another transaction so long as the parent transaction is known by the node in question, however this is quite fragile. Bitcoin transactions back reference by TXID, a cryptographic hash of the previous one being spent. Due to a property known as ...


Only top voted, non community-wiki answers of a minimum length are eligible