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 ...
I believe this is addressed in page 8 of Satoshi's Bitcoin paper when showing the probability of an attacker catching up.
The wiki states:
"Only 6 blocks or 1 hour is enough to make reversal computationally impractical."
The key word is "impractical".
The important sentence in Satoshi's paper is:
"Assuming the honest blocks took the average ...
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.
P < 0.001
The green address is a third party trust trick and can help resolve most problems related to the need to wait for confirmations (slow transactions).
To make it very simple :
Service A publishes its green address, service B decides to trust service A.
When someone send bitcoins from service A to service B, he will send from the service A green address.
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 ...
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.
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 ...
Bitcoin confirmations represent the number of blocks in the block chain that have been accepted by the network since the block that includes the transaction.
In simpler terms it represents the difficulty of a double spend attack. With zero confirmations no proof of work has been done, so you can't tell if anyone considers the transaction valid. Even with a ...
If you don't grasp the basic concept, imagine for a second that a network outage split the bitcoin network in half. I could send one transaction giving 30 bitcoins to Abel to one half and one transaction giving those same 30 bitcoins to Fred to the other. Each half would accept that transaction and until the two halves reconnected, you wouldn't know which ...
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 ...
Here are some of the relevant sections from Satoshi's paper:
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. ... The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest ...
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 ...
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 ...
Green address technique from Instawallet. System sends bitcoins from well known address called Green Address and if recipient trusts Instawallet or any other major organization that uses same technique, then he or she can accept payment without waiting for confirmations. This is what already implemented but it solves only the third problem.
Instant TX for ...
For what it's worth, MyBitcoin.com claimed that their closure was precipitated by a series of double-spend attacks:
Our programmer was under the assumption that one block was good enough
to secure a transaction. Two years ago when the software was written,
this single confirm myth was a popular belief.
User theymos (an administrator of the ...
If your transaction does not get accepted, you have a few options. Right now, at least for Bitcoin itself, there are still enough miners willing to include any valid transaction. So if you just keep waiting, it should eventually get confirmed.
You may also wish to stop your client and then restart it, manually forcing it to connect to a client known to ...
Transactions are first transmitted to all the nodes in the p2p network. At this point they are "unconfirmed".
At some point a miner includes the transaction in a block. The transaction now has 1 confirmation.
Miners continue to find blocks and the next block builds on the block that contains the transaction. The transaction now has 2 confirmations (the ...
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,...
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 ...
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
36 bytes outpoint
1 byte scriptSigLen (0x00)
0 bytes scriptSig
4 bytes sequence
1 byte output count
8 bytes ...
This question has been asked several times in several different places, and nobody has yet come forward with evidence of a double-spend attack. It is, of course, possible that nobody is bothering with such an attack because everyone waits for confirmations anyway.
Your analysis is correct. You can act on fewer confirmations with the same level of ...
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 ...
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
One thing people fail to realize when saying "0 confirms are risky" is that risk is all relative. A lot depends on how valuable the goods are. While 0 confirmation may have some risk it is very low for low value transactions and likely far less than credit card fraud.
Say you are selling a sandwich for whatever $5 is worth in BTC. When you get a 0 ...
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, [...])
return (SelectCoinsMinConf(nTargetValue, 1, 6, vCoins, setCoinsRet, ...
Just to give some specifics in addition to David Grayson's answer:
At current difficulty levels, mining a block requires computing an average of
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 ...
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 ...
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" ...
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 ...
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 ...