Transaction times | Bitcointalksearch.org

gweedo

legendary

Activity: 1498

Merit: 1000

Quote from: BitCoinDream on January 09, 2014, 05:30:35 AM

Quote from: amincd on January 09, 2014, 04:27:46 AM

Yes. I would be fine with a zero-confirmation transaction for anything less than $100 if the tx is a one time affair and I'm personally handling it. For a web-service that is handling transactions automatically, and allowing withdrawals, I would always need at least one confirmation, because if the web service accepts 0 confirmation transactions, an attacker could automate the attack and make thousands of attempts to defraud the web service at zero cost (for example, if he had one major miner cooperating with him), where he constantly deposits, withdraws, and then tries to double spend the deposit.

No One should ever accept Zero transaction unless they are confirmed about Tx fees. Any transaction without a Tx fee will never get confirmed in current situation. So even if the amount gets deducted from buyer, seller will never be able to use it. So, even for micro payments, u need to wait for 1 confirmation.

Very much false. Aged coins can be sent without a fee and get confirmed.

BTC-TK

member

Activity: 154

Merit: 14

Fake money is also unacceptable in everyday use, the difference is you wouldn't know even a month after receiving the bill that it's fake. There are some high quality Chinese copies these days, we aren't in the 19th century anymore where faking a paper bill is incredibly hard.

BitCoinDream

legendary

Activity: 2394

Merit: 1216

The revolution will be digital

Quote from: amincd on January 09, 2014, 04:27:46 AM

Yes. I would be fine with a zero-confirmation transaction for anything less than $100 if the tx is a one time affair and I'm personally handling it. For a web-service that is handling transactions automatically, and allowing withdrawals, I would always need at least one confirmation, because if the web service accepts 0 confirmation transactions, an attacker could automate the attack and make thousands of attempts to defraud the web service at zero cost (for example, if he had one major miner cooperating with him), where he constantly deposits, withdraws, and then tries to double spend the deposit.

No One should ever accept Zero transaction unless they are confirmed about Tx fees. Any transaction without a Tx fee will never get confirmed in current situation. So even if the amount gets deducted from buyer, seller will never be able to use it. So, even for micro payments, u need to wait for 1 confirmation.

amincd

hero member

Activity: 772

Merit: 501

Yes. I would be fine with a zero-confirmation transaction for anything less than $100 if the tx is a one time affair and I'm personally handling it. For a web-service that is handling transactions automatically, and allowing withdrawals, I would always need at least one confirmation, because if the web service accepts 0 confirmation transactions, an attacker could automate the attack and make thousands of attempts to defraud the web service at zero cost (for example, if he had one major miner cooperating with him), where he constantly deposits, withdraws, and then tries to double spend the deposit.

jonanon

full member

Activity: 154

Merit: 100

Quote from: amincd on January 09, 2014, 03:58:25 AM

Quote

once this has happened, obviously it's not confirmed, what could happen to make this payment not successful?

If the transaction has a sufficient fee, then there's a very high likelihood it will be safe from a double spend. A few things could still happen however to make the payment unsuccessful:

1. A miner could have replace-by-fee enabled (which I'm not aware of any miner doing yet, as the standard Bitcoin client doesn't allow replace-by-fee) and the payer could replace the already propagated transaction with a double spend transaction with a higher fee.

2. A malicious miner, who is cooperating with the payer, could secretly include a double spend transaction from the payer in the block he is hashing on, and not propagate this transaction to other nodes. If he finds a block, the secret transaction will be confirmed and the propagated transaction will become invalid.

3. A Finney attack: https://bitcointalksearch.org/topic/m.48384

Thanks for the explanation

So for small items we should be OK - Less chance someone wants to steal $5 worth of merchandise so in this instance the buyer could pay and leave quickly. For larger more expensive items there is likely to be less people waiting in line - say for a TV or car so waiting shouldn't be an issue.

amincd

hero member

Activity: 772

Merit: 501

Quote

once this has happened, obviously it's not confirmed, what could happen to make this payment not successful?

If the transaction has a sufficient fee, then there's a very high likelihood it will be safe from a double spend. A few things could still happen however to make the payment unsuccessful:

1. A miner could have replace-by-fee enabled (which I'm not aware of any miner doing yet, as the standard Bitcoin client doesn't allow replace-by-fee) and the payer could replace the already propagated transaction with a double spend transaction with a higher fee.

2. A malicious miner, who is cooperating with the payer, could secretly include a double spend transaction from the payer in the block he is hashing on, and not propagate this transaction to other nodes. If he finds a block, the secret transaction will be confirmed and the propagated transaction will become invalid.

3. A Finney attack: https://bitcointalksearch.org/topic/m.48384

jonanon

full member

Activity: 154

Merit: 100

I have read numerous times about people saying that the transaction times for BTC are unacceptable for everyday life.

However if I receive a payment in my wallet it will show up as being seen by x amount of peers as soon as it's been sent - once this has happened, obviously it's not confirmed, what could happen to make this payment not successful? Could this pending transaction not be seen as being good enough for say shop owners to release goods to the buyer?

Huh

Topic: Transaction times (Read 722 times)