114
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 ...
39
if in the coming years the difficulty increases so much that mining is no longer profitable
That's not really possible. The mining power is set so that the miners need 10 minutes in average to mine a block. If 50% of the miners would disappear because it's not profitable any more, the difficulty would decrease so that it's profitable again.
Can the ...
34
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 ...
31
It's not completely clear what the situation is, but from what I gather it seems that you're the sender and the recipient is not acknowledging a payment you have sent.
I assume that you have verified that the credited address 1Gouzjo9Jav1k4AmRoUJJMzidVfnMoSieS matches the one that you were supposed to pay to, and that the amount matches the invoiced amount.
...
25
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 ...
20
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 ...
18
It depends on your risk model.
If you can trust the person paying you, you can accept payment on 0/unconfirmed if you want.
As a merchant or trader, you want to use the configuration that is more secure (no incoming connections permitted, explicity connect to well-connected nodes).
With zero confirmations you are vulnerable to the race attack and the ...
13
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 ...
12
The thing to consider is, "what does the attacker have to give up in order to attack me?" If the cost of that thing is less than the reward from a successful attack, then attacking is rational from a purely economic standpoint. (Obviously, attacking someone comes with a non-economic moral cost.)
A miner who controls more than half of the network hash rate,...
12
Very interesting question, let's see what the smallest transaction we can build is. For it to be minimal it has to be a single input and a single output. The non-segwit part would look something like this:
4 bytes version
1 byte input count
Input
36 bytes outpoint
1 byte scriptSigLen (0x00)
0 bytes scriptSig
4 bytes sequence
1 byte output count
8 bytes ...
10
The figure of 6 blocks is completely arbitrary. It is based on the assumptions that the attacker will not amass more than 10% of the network hashrate, and that a negligible chance of 0.1% for successfully double-spending is acceptable.
A more detailed analysis of this is available at Analysis of Hashrate-Based Double-Spending
10
This is definitely a concern, and is the reason why Bitcoin users are encouraged to wait for several confirmations before accepting a transaction and delivering goods.
It's not quite as easy as you suggest, though. When you made your transaction at the cafe, it was, as you say, broadcast across the network. Barring connectivity problems, every node on the ...
9
Just to give some specifics in addition to David Grayson's answer:
At current difficulty levels, mining a block requires computing an average of
29,973,900,941,385,007,104
hash operations. An ordinary computer can perform perhaps 10,000,000 such operations per second. At that rate, such a computer would take about 95,046 years to mine one block, on ...
9
Blocks in Bitcoin, as they exist in the blockchain, don't actually contain a confirmation field. When you query for a block in bitcoin-rpc or similar, additional information is added to the block based on your client's knowledge of the current state of the blockchain.
A pure block contains only five fields (some of which have sub-fields):
Magic number (to ...
9
(This data is current through block 535276.)
Based on block timestamps (which do not have to be accurate), the longest difference between successive blocks is 463160 seconds (5 days, 8 hours, 39 minutes, 20 seconds) between blocks 0 and 1. The second longest is 90532 seconds (1 day 1 hour 8 minutes 52 seconds) between blocks 15323 and 15324.
For "shortest"...
8
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.
8
The problem was that in case a duplicate transaction was created in a side branch that is afterwards reverted, and is only seen by a certain portion of the network, a fork risk exists. The nodes A that have seen the duplicate transactions and its reversal, will consider the original transaction unspendable (as it was overwritten and subsequently removed from ...
8
Since there is nothing that shows you that peers have received and are relaying your transaction you might want to leave your client open until there is one confirmation.
In addition to the initial broadcast to peers, there are subsequent re-broadcasts performed by your client if the transaction has not received a confirmation. This re-broadcast generally ...
8
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 ...
8
It is a lot of work and it requires a lot of computing power. To get the 25 BTC reward for a block (also known as the coinbase reward), you have to create the block in the first place. It is difficult to create blocks. A valid block will have to meet a large number of conditions, including that its header has a 256-bit hash whose numerical value is under ...
7
On March 11th, 2013 there was an unplanned hard fork and as a result there was at least one double spend attack performed in which a large amount of funds (bitcoins worth $10K USD) were double spent.
http://bitcointalk.org/index.php?topic=152348
http://www.bitcoinmoney.com/post/47048259653
7
At the moment there's very little orphaning of blocks, and next to no occurrence of two-block side chains. Unless you're dealing with large amounts (larger than two block rewards worth, probably), your chances of attack are incredibly incredibly low. If you're dealing with amounts less than a few BTC, I'd personally be happy accepting one-confirmation ...
7
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 ...
7
The Bitcoin Core -walletnotify should only run at most twice for a typical transaction:
When the transaction enters the local node's mempool
When a block arrives containing that transaction.
I haven't tested this, but it looks like the code may also send a notify if the transaction is conflicted, if it is no longer confirmed after a reorg, or when it is ...
7
This is essentially correct: the protocol leaves it up to the miner to decide which transactions to include in a block. There is no requirement for them to include any transactions at all, other than the "coinbase" transaction which specifies where to send the block reward.
However, most transactions have fees attached, which the miner can collect only by ...
6
If a transaction returned from the http://blockchain.info/rawtx/$tx_hash endpoint has a confirmation, it will have a block_height member. You can then calculate roughly its number of confirmations by subtracting that value from the latest height retrieved from the http://blockchain.info/latestblock endpoint.
Code example, in Ruby:
#!/usr/bin/env ruby
...
6
The number of Bitcoin network confirmations required for a particular transaction to be considered complete is determined by the BitPay account holder on a transaction-by-transaction basis.
Entities set the Risk/Speed of a transaction to "Low" (6 confirmations), "Medium" (3 confirmations), or "high" (1 confirmation) via the API when an invoice is created. ...
6
From
http://www.cryptocoinsnews.com/news/the-mathematically-secure-way-to-accept-zero-confirmation-transactions/2014/02/13, here is what services like MyCelium and BitPay may be doing:
More specifically, with every additional second a larger percentage of active Bitcoin nodes will have heard the original transaction and everyone viewing the blockchain can ...
6
As per: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list
We have,
[target-confirmations] intentionally does not affect the list of returned transactions, but only affects the returned 'lastblock' value.
What does this mean? It means the lastblock entry in your returned object is the last block you can see on the blockchain (as it the ...
6
Your answer assumes different nodes can have a consistent view of the mempool. If that were the case, we wouldn't need a blockchain at all, whose sole purpose is establishing consistency between different nodes' view of history.
The reason this is not possible is due to the laws of physics. A transaction tx1 broadcast in Australia, which conflicts with a ...
Only top voted, non community-wiki answers of a minimum length are eligible
