107
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 ...
41
Many people misquote Satoshi paper and assume 6 is some value of significance.
Satoshi's paper outlines the number of confirmations necessary to be 99.9% sure (less than 1 in 1000 chance of success) that an attacker couldn't build a longer chain to reverse the transaction.
http://bitcoin.org/bitcoin.pdf
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=...
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 ...
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.
...
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 ...
23
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 ...
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 ...
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 ...
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,...
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
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
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
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
9
Yes. Unlike other transactions you don't need to wait for the confirmations.
From the code which selects which coins to use to fund a transaction in src/wallet.cpp:
bool CWallet::SelectCoins(int64 nTargetValue, [...])
{
vector<COutput> vCoins;
AvailableCoins(vCoins);
return (SelectCoinsMinConf(nTargetValue, 1, 6, vCoins, setCoinsRet, ...
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 ...
8
No. The average time per confirmation will always be about 10 minutes (but it's possible that the variance will be lower in the future). And the number of confirmations required to prevent double-spending by an agent with a given hashrate will also not change (6 is an arbitrary number reflecting a "low enough" probability for someone with a "high enough" ...
8
The lifetime of a transaction would be something like this:
You start with a client, a wallet that contains your keypairs, and some unspent transactions (you get those from other people or through mining).
You create a new transaction spending some of your unspent Bitcoins, sign it with your private keys. Your client will store a copy of it.
Your client ...
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
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
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
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
If you are attempting a 0-confirm double spend then which transactions (if any) are included in the next block is irrelevant. Your goal is to simply complete both transaction prior to either merchant getting notification of the other one.
The "problem" is that the network is fairly quick at passing transactions from one node to the next. Unless you have ...
7
I don't think it helps much. The biggest real threat is the Finney attack, and the Finney attack is just as big a threat even with such a promise.
7
You're correct; the expected confirmation time from any given point in time is always around 10 minutes (it may be a little more or less when the network hash rate has changed since the last difficulty adjustment). This question looked at that exact issue.
Note that a retailer (or other transaction acceptor) doesn't necessarily need to wait for a block to ...
7
It seems like there is some policy against free transactions in official client.
There are some anti-spam protections, which my toy transactions exactly meet (low transactions, recently accepted coins, etc)
https://bitcointalk.org/index.php?topic=63553.0
https://en.bitcoin.it/wiki/Free_transaction_relay_policy
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
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 ...
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 ...
Only top voted, non community-wiki answers of a minimum length are eligible
