6 ms·

Bitcoin 10 minute block generation times is an inherent problem that unless changed, will doom the protocol to its eventual death. It's like trying to make a 5

Bitcoin 10 minute block generation times is an inherent problem that unless changed, will doom the protocol to its eventual death. It's like trying to make a 56k modem work, when broadband is available. When litecoin came around a few years ago these were abstract problems, but now that transactions with $10 fees take 36 hours to confirm... the issues are real and a switch needs to happen. Lightning network or not, these hacks to speed up the network unequivocally make more sense to do on a network with faster block generation times. Necessity will force this outcome.

ericb 9y ago
That problem isn't a result of the 10 minute blocks. A 0-confirmation transaction normally is just fine. These are available on Bitcoin Cash.
- jdc0589 9y ago
  I honestly don't know a ton about cryptocurrencies, but I though confirmed transactions were.....more or less whole point? can you give me an ELI5 version of why 0-confirmation transactions are ok?
  - ericb 9y ago
    It depends on the use-case. If you look at credit card transactions, they are only "confirmed" after 120 days (when chargebacks become harder...not impossible). A 0-conf transaction will work for all scenarios where you would trust a credit card with about the same amount of certainty. For those other scenarios, 10 minutes is better.
    - Isomatik 9y ago
      I think it's really only comparable for online transactions, where all credit card transactions are Card Not Present and you aren't able to 100% guarantee that the delivery went to the correct person or that the card wasn't stolen, making fighting the chargeback sometimes not worth it. A brick and mortar doing swipe transactions should have everything they need to effectively fight chargebacks, so I wouldn't consider that money to be 'gone' the way it would be in a double-spend.
  - Obi_Juan_Kenobi 9y ago
    For small transactions, it's often a tolerable risk. You amortize any losses to double-spends and compare that to e.g CC fees. For larger amounts, you want confirmations, but then it's generally alright to wait a little while for confirmation, too. Note that replace-by-fee means this only works with Bitcoin Cash.
- grey-area 9y ago
  A 0-confirmation transaction normally is just fine. It's really not fine at all. The competition is full confirmation transactions on a debit card or bank account in seconds with much lower or zero fees.
  - seanp2k2 9y ago
    >seconds At PoS systems in the US, it's typical to have to wait 30+ seconds for chip cards to go through. I'm guessing that this has more to do with the PoS system / slow internet connection for the store / slow network on the back-end card network, but cryptocurrencies would need to be sub-minute to be ~acceptable for in-person retail transactions. Until that is solved, until cryptocoins are more than speculative securities where the value is only the current market price on a handful of exchanges, and until you can use them to realistically buy and sell things instead of using cash or a credit card, I don't consider them a "real" currency (by my own definition). I DO hope that it gets there some day, but I don't see that happening for at least another 5 years, likely with quite a few people who put a significant amount of money into it getting burned quite badly.
    - bootlooped 9y ago
      I have absolutely never had to wait 30+ seconds for a credit card transaction that used the chip, so I don't agree with your assessment of that amount of time being typical. Generally, for me, I think it takes about 3-5 seconds from the time I confirm the dollar amount to the time the confirmation comes back.
    - dlubarov 9y ago
      30s isn't really typical; the average is in the ballpark of 10s. When I worked at Square we got our average down to 4.2s [1]. Modern Verifone terminals seem pretty quick as well. Long term, "instant" contactless will probably become the norm (though it's taking hold very slowly in the US). [1] https://squareup.com/townsquare/weve-chipped-away-at-emv-transaction-speed-and-were-not-done https://squareup.com/townsquare/weve-chipped-away-at-emv-tra...
    - deleted 9y ago
      [deleted]
- sf_rob 9y ago
  0-conf isn't fine in many trustless scenarios with Bitcoin because of Replace By Fee.
  - ericb 9y ago
    Agreed, but Bitcoin Cash intentionally has not added Replace By Fee for this reason.
cup-of-tea 9y ago
10 minute block generation time is not a problem at all. What's a problem is every block being full.
- ExactoKnight 9y ago
  Can you name one good reason for having it be 10 minutes rather than 30 seconds? If you can't then you are going to lose this argument.
Klathmon 9y ago
I know this probably sounds like a stuck record at this point, but Lightning Network can solve this, and will relegate the actual blockchain as an arbitration/settlement layer where the 10 minute blocktime isn't a problem.
- XR0CSWV3h3kZWg 9y ago
  LN's security model relies on being able to close a channel before a certain block. This means that there will be periods of time that paying the fee to close a channel in time will be cost prohibitive and the security property evaporates. That being said we really should see exchange -> exchange txs be conducted over large LN channels, it could off load a lot of pressure off the chain.
  - Klathmon 9y ago
    There is a method (which is already in LN) to prevent this which will stop the nSequence countdown if blocks are congested. From the LN paper: >For example, if a parent transaction output is spent by a child with a nSequence value of 10, one must wait 10 confirmations before the transaction becomes valid. However, if the timestop flag has been set, the counting of confirmations stops, even with new blocks. If 6 confirmations have elapsed (4 more are necessary for the transaction to be valid), and the timestop block has been set on the 7th block, that block does not count towards the nSequence requirement of 10 confirmations; the child is still at 6 blocks for the relative confirmation value. >This gives sufficient time and block-space for transactions at the current auxiliary timestop block height to enter into the blockchain, which can prevent systemic attackers from successfully attacking the system. It's not perfect by any means (a malicious miner with a significant portion of the hashpower could never set the timestop bit and spam the mempool at the same time), but it mostly removes this worry in a "normal congestion" scenario, and makes it require a pretty large portion of global hashpower as well as very VERY deep pockets to pull it off in a "malicious" scenario.
    - XR0CSWV3h3kZWg 9y ago
      the main repo doesn't seem to have the string timestop in it. Nor does any of the bips. What BIP was this implemented in? Seems like a decent idea, although I don't see why miners would be incentivized to set timestop and the paper suggests that timestop is set to 1 whenever the block is full. The blocks are almost always full, so is it just up to the miner to choose if time is stopped or not?

ericb 9y ago

That problem isn't a result of the 10 minute blocks. A 0-confirmation transaction normally is just fine. These are available on Bitcoin Cash.

jdc0589 9y ago
I honestly don't know a ton about cryptocurrencies, but I though confirmed transactions were.....more or less whole point? can you give me an ELI5 version of why 0-confirmation transactions are ok?
- ericb 9y ago
  It depends on the use-case. If you look at credit card transactions, they are only "confirmed" after 120 days (when chargebacks become harder...not impossible). A 0-conf transaction will work for all scenarios where you would trust a credit card with about the same amount of certainty. For those other scenarios, 10 minutes is better.
  - Isomatik 9y ago
    I think it's really only comparable for online transactions, where all credit card transactions are Card Not Present and you aren't able to 100% guarantee that the delivery went to the correct person or that the card wasn't stolen, making fighting the chargeback sometimes not worth it. A brick and mortar doing swipe transactions should have everything they need to effectively fight chargebacks, so I wouldn't consider that money to be 'gone' the way it would be in a double-spend.
- Obi_Juan_Kenobi 9y ago
  For small transactions, it's often a tolerable risk. You amortize any losses to double-spends and compare that to e.g CC fees. For larger amounts, you want confirmations, but then it's generally alright to wait a little while for confirmation, too. Note that replace-by-fee means this only works with Bitcoin Cash.
grey-area 9y ago
A 0-confirmation transaction normally is just fine. It's really not fine at all. The competition is full confirmation transactions on a debit card or bank account in seconds with much lower or zero fees.
- seanp2k2 9y ago
  >seconds At PoS systems in the US, it's typical to have to wait 30+ seconds for chip cards to go through. I'm guessing that this has more to do with the PoS system / slow internet connection for the store / slow network on the back-end card network, but cryptocurrencies would need to be sub-minute to be ~acceptable for in-person retail transactions. Until that is solved, until cryptocoins are more than speculative securities where the value is only the current market price on a handful of exchanges, and until you can use them to realistically buy and sell things instead of using cash or a credit card, I don't consider them a "real" currency (by my own definition). I DO hope that it gets there some day, but I don't see that happening for at least another 5 years, likely with quite a few people who put a significant amount of money into it getting burned quite badly.
  - bootlooped 9y ago
    I have absolutely never had to wait 30+ seconds for a credit card transaction that used the chip, so I don't agree with your assessment of that amount of time being typical. Generally, for me, I think it takes about 3-5 seconds from the time I confirm the dollar amount to the time the confirmation comes back.
  - dlubarov 9y ago
    30s isn't really typical; the average is in the ballpark of 10s. When I worked at Square we got our average down to 4.2s [1]. Modern Verifone terminals seem pretty quick as well. Long term, "instant" contactless will probably become the norm (though it's taking hold very slowly in the US). [1] https://squareup.com/townsquare/weve-chipped-away-at-emv-transaction-speed-and-were-not-done https://squareup.com/townsquare/weve-chipped-away-at-emv-tra...
  - deleted 9y ago
    [deleted]
sf_rob 9y ago
0-conf isn't fine in many trustless scenarios with Bitcoin because of Replace By Fee.
- ericb 9y ago
  Agreed, but Bitcoin Cash intentionally has not added Replace By Fee for this reason.

cup-of-tea 9y ago

10 minute block generation time is not a problem at all. What's a problem is every block being full.

ExactoKnight 9y ago
Can you name one good reason for having it be 10 minutes rather than 30 seconds? If you can't then you are going to lose this argument.

Klathmon 9y ago

I know this probably sounds like a stuck record at this point, but Lightning Network can solve this, and will relegate the actual blockchain as an arbitration/settlement layer where the 10 minute blocktime isn't a problem.

XR0CSWV3h3kZWg 9y ago
LN's security model relies on being able to close a channel before a certain block. This means that there will be periods of time that paying the fee to close a channel in time will be cost prohibitive and the security property evaporates. That being said we really should see exchange -> exchange txs be conducted over large LN channels, it could off load a lot of pressure off the chain.
- Klathmon 9y ago
  There is a method (which is already in LN) to prevent this which will stop the nSequence countdown if blocks are congested. From the LN paper: >For example, if a parent transaction output is spent by a child with a nSequence value of 10, one must wait 10 confirmations before the transaction becomes valid. However, if the timestop flag has been set, the counting of confirmations stops, even with new blocks. If 6 confirmations have elapsed (4 more are necessary for the transaction to be valid), and the timestop block has been set on the 7th block, that block does not count towards the nSequence requirement of 10 confirmations; the child is still at 6 blocks for the relative confirmation value. >This gives sufficient time and block-space for transactions at the current auxiliary timestop block height to enter into the blockchain, which can prevent systemic attackers from successfully attacking the system. It's not perfect by any means (a malicious miner with a significant portion of the hashpower could never set the timestop bit and spam the mempool at the same time), but it mostly removes this worry in a "normal congestion" scenario, and makes it require a pretty large portion of global hashpower as well as very VERY deep pockets to pull it off in a "malicious" scenario.
  - XR0CSWV3h3kZWg 9y ago
    the main repo doesn't seem to have the string timestop in it. Nor does any of the bips. What BIP was this implemented in? Seems like a decent idea, although I don't see why miners would be incentivized to set timestop and the paper suggests that timestop is set to 1 whenever the block is full. The blocks are almost always full, so is it just up to the miner to choose if time is stopped or not?