Why aren't transactions faster?

[BitchicksHusband]

Can somebody explain to me why:

* Mining isn't 10 times faster (a new block every minute instead of 10 minutes)
* With difficulty 10 times easier
* With 1/10 the payout (like 5 coins instead of 50)
* With 1/10 the blocksize (1/10MB instead of 1MB)

Wouldn't confirmations be quicker but everything else be roughly the same?  I am pretty sure there's a good reason for what Satoshi did.  What am I missing?

Also, wouldn't more miners make money?  The coins would be spread out more.

[1715019390]

1715019390

[1715019390]

1715019390

[wumpus]

Because the confirmations would be backed by 1/10th as much hashing power, so also only 1/10th as secure. If you wait for one confirmation now, you would have to wait for 10 confirmations with the new system to have a comparable level of security.

There would also be more orphan blocks, and thus more bandwidth usage and overhead.

See also litecoin (https://en.bitcoin.it/wiki/Litecoin), which does this, but with a factor of 4 instead of 10.

[CIYAM]

Satoshi made some choices pretty much arbitrarily with things like average confirmation time and many alt coins you see tend to have much faster confirmation times (although as pointed out in the post above they are thus arguably not as secure as Bitcoin is because of this).

It's arguable whether the Bitcoin settings are the most effective but it would not be so easy to change them (we are pretty much stuck with what Satoshi chose).

In regards to the block sizes it would actually be less efficient in terms of storage space required to make them a lot smaller.

[BitchicksHusband]

Because the confirmations would be backed by 1/10th as much hashing power, so also only 1/10th as secure. If you wait for one confirmation now, you would have to wait for 10 confirmations with the new system to have a comparable level of security.

There would also be more orphan blocks, and thus more bandwidth usage and overhead.

See also litecoin (https://en.bitcoin.it/wiki/Litecoin), which does this, but with a factor of 4 instead of 10.

I didn't realize that this was virtually the only feature of Litecoin (I knew it was one of them).

So an orphan block is a single confirmation that never gets a second confirmation, right?

[wumpus]

So an orphan block is a single confirmation that never gets a second confirmation, right?

An orphan is a block that didn't "make it", because someone else made a longer chain without that block in it.
If blocks are generated more often and require less work on average, there is a larger chance of miners generating longer chains on top of older blocks instead of the latest one. This is due to network latency and variance, after all it's a random process and it's possible to generate two blocks in very quick succession.

In any case - it's simply a choice, a compromise that had to be made. Very fast as well as very slow confirmations would have been worse. But there is nothing magical about the 10 in itself.

[gmaxwell]

1/10th?

It's important to realize that if the rate blocks are being found is not a large multiple of how long it takes for a block to be propagated to and accepted by ~all of the network that the network will start suffering from convergence failures and see enormous reorgs. Even before the point where it would cause convergence failure a block time which is too fast relative to latencies would confer an an advantage to large hashpower consolidations (e.g. attackers).

Reducing the block size has some effect on propagation time, but it doesn't eliminate the effect of network latency.

More frequent blocks would also multiplicatively increase the header costs for SPV nodes. E.g. 10 years of headers would be 400MBytes for 1m blocks than 40MBytes.

[amincd]

Because the confirmations would be backed by 1/10th as much hashing power, so also only 1/10th as secure. If you wait for one confirmation now, you would have to wait for 10 confirmations with the new system to have a comparable level of security.

But it gives you the option of accepting a transaction that has 1/10th the security of a 10 minute block if you can afford to sacrifice some security for greater speed, but not to the point of accepting a zero confirmation transaction.

To the OP, one other disadvantage of shorter block intervals is that it encourages centralization by giving miners with faster internet connections a greater advantage.

[BitchicksHusband]

Cool, guys.  That was all very helpful.  Thanks.

[JoelKatz]

But it gives you the option of accepting a transaction that has 1/10th the security of a 10 minute block if you can afford to sacrifice some security for greater speed, but not to the point of accepting a zero confirmation transaction.

Exactly. With a one minute block time, your average time to first confirmation is one minute. With a ten minute block time, it's ten minutes. So if two weak confirmations is enough for you, you can have them in two minutes on average, rather than having to wait ten minutes for one strong confirmation. Arguably, two weak confirmations is at least as good as one strong confirmation.

As noted, there are disadvantages to faster block times, of course.

[rpietila]

But it gives you the option of accepting a transaction that has 1/10th the security of a 10 minute block if you can afford to sacrifice some security for greater speed, but not to the point of accepting a zero confirmation transaction.

What are the practical chances of getting screwed if one accepts a zeroconf transaction with Bitcoin (ie. Blockchain.info shows it)?

[JoelKatz]

What are the practical chances of getting screwed if one accepts a zeroconf transaction with Bitcoin (ie. Blockchain.info shows it)?

I'm assuming you use the best known defenses against the most common attacks. That would mean connecting close to as many mining pools as possible and watching for conflicting transactions. The best known attack would then be a Finney attack. Anyone attempting such an attack would risk losing a block they had just mined, so they're risking 25 Bitcoins. So if the sale value is much less than 25 Bitcoins, the risk is very low. You're not going to risk losing 25 Bitcoins to steal 2.

[rpietila]

What are the practical chances of getting screwed if one accepts a zeroconf transaction with Bitcoin (ie. Blockchain.info shows it)?

I'm assuming you use the best known defenses against the most common attacks. That would mean connecting close to as many mining pools as possible and watching for conflicting transactions. The best known attack would then be a Finney attack. Anyone attempting such an attack would risk losing a block they had just mined, so they're risking 25 Bitcoins. So if the sale value is much less than 25 Bitcoins, the risk is very low. You're not going to risk losing 25 Bitcoins to steal 2.

So this is only possible if all of the following coincide:
- Malicious intent
- Access to great hashing power
- Luck
- Opportunity to steal >BTC25
- ...with 100% chance of getting caught if successful.

Hardly my customers...

[CIYAM]

What are the practical chances of getting screwed if one accepts a zeroconf transaction with Bitcoin (ie. Blockchain.info shows it)?
...
So this is only possible if all of the following coincide:

Not quite - if the priority is very low there is every chance that the tx may *disappear* after a day or so (in which case the original sender could just delete that tx from their wallet and you'll never get those funds unless they decide to send them to you again with an appropriate fee included).

And recently this problem has actually been fairly common (due to the large # of transactions in the pool).

[JoelKatz]

Not quite - if the priority is very low there is every chance that the tx may *disappear* after a day or so (in which case the original sender could just delete that tx from their wallet and you'll never get those funds unless they decide to send them to you again with an appropriate fee included).

And recently this problem has actually been fairly common (due to the large # of transactions in the pool).

Yeah, you need to use a variety of defenses to sanely accept zero confirmation transactions. One important thing is to make sure the transaction fee is adequate.

[solex]

What are the practical chances of getting screwed if one accepts a zeroconf transaction with Bitcoin (ie. Blockchain.info shows it)?

I'm guessing that also the thrust of the OP is that faster blocks allow for faster transactions at a point of sale, especially physical shops where the customer walks out of the store immediately after paying.

Last month I did my first wave-and-pay transaction on my Visa card, which does not even require require a pin number for small amounts. It took 1 second and was done. There is no way a decentralized cryptocurrency will ever compete with that in terms of waiting for block confirmations. This is why Litecoin's 2.5 minute block time is not a significant benefit.

The solution for immediate sales (zero confirmations) must lie elsewhere. Merchants can accept the double-spend risk as a cost of doing business just as they accept the risk of forged currency or stolen credit cards today. In the future there might be insurance available against double-spends for an annual premium. 3rd-party applications which run on top of the Bitcoin protocol can enable instant confirmations if the customer and merchant both use the same 3rd-party service (this is probably a future role for the CC companies).

[rpietila]

Not quite - if the priority is very low there is every chance that the tx may *disappear* after a day or so (in which case the original sender could just delete that tx from their wallet and you'll never get those funds unless they decide to send them to you again with an appropriate fee included).

And recently this problem has actually been fairly common (due to the large # of transactions in the pool).

Yeah, you need to use a variety of defenses to sanely accept zero confirmation transactions. One important thing is to make sure the transaction fee is adequate.

The main defence is that I know who my customers are. From anonymous strangers, I have taken 2 confirmations for sums up to BTC50 (method: sweeping of private key). Is this prudent enough? (BTC50 is more dollarz than it used to be)

[rpietila]

Merchants can accept the double-spend risk as a cost of doing business just as they accept the risk of forged currency or stolen credit cards today. In the future there might be insurance available against double-spends for an annual premium. 3rd-party applications which run on top of the Bitcoin protocol can enable instant confirmations if the customer and merchant both use the same 3rd-party service (this is probably a future role for the CC companies).

Has any of the merchants ever complained about this supposed risk?  As a merchant I find the risk waywaywaywayway smaller than the variable percent of physical shoplifting.

[solex]

Has any of the merchants ever complained about this supposed risk?  As a merchant I find the risk waywaywaywayway smaller than the variable percent of physical shoplifting.

This is a good question. Has any of the btc accepting shops in Berlin, or the various cafes around the world complained about a successful double-spend against them?

[maaku]

Because the confirmations would be backed by 1/10th as much hashing power, so also only 1/10th as secure. If you wait for one confirmation now, you would have to wait for 10 confirmations with the new system to have a comparable level of security.

This is a commonly held belief here, but incorrect. One 10-second confirmation provides exactly the same security as a a single 10-minute confirmation. A coin with block coming 10x as quickly would allow you to wait less time for confirmations. It would also be a terrible idea for a whole host of other reasons, many of them mentioned above.

[JoelKatz]

This is a commonly held belief here, but incorrect. One 10-second confirmation provides exactly the same security as a a single 10-minute confirmation.

I disagree. With 10 second confirmations, the probability of a second block being found before the first block propagated to the majority of mining pools would be *much* higher. The longer the confirmation time, the lower the chance a one-confirmation block will be orphaned.