Bitcoin Forum
May 30, 2024, 12:25:48 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Is there any obvious reason not to cut the block confirmation time?  (Read 531 times)
leemar (OP)
Full Member
***
Offline Offline

Activity: 193
Merit: 100


View Profile
March 10, 2014, 04:21:24 PM
 #1

Lots of infrastructure is going to get build (is being built) that in time will make payments pretty instantaneous.  But until they become ubiquitous, what are the downsides to reducing the block confirmation time and block issuance rate to say 2.5 coins every minute?  I understand this might be no more secure than a well propagated message today but it might help in terms of perception?
leemar (OP)
Full Member
***
Offline Offline

Activity: 193
Merit: 100


View Profile
March 10, 2014, 04:32:47 PM
 #2

No worries, just found this......

https://bitcointalk.org/index.php?topic=260180.msg2782197#msg2782197
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
March 10, 2014, 04:32:48 PM
 #3

The downside is that increased rate of orphans means reduced effective security and increased orphan cost.  The later is more of an issue while the block subsidy is relatively high.  Reducing the orphan cost should be a high priority.  A reduction in the orphan cost of 90%+ is possible with some small non-forking changes to the protocol (the message format used for relaying blocks).

Oprhans reduce the effective security of the network.  Any hashpower spent on orphaned blocks is essentially wasted, reducing the potential cost to an attacker.  As an example a network with 100 TH and 10% orphan rate can be 51% attacked with only 90 TH/s.

The orphan cost is the cost to the miner to add one more tx to the block.  A shorter block interval increases that cost.  If the compensation for the miner is less than the orphan cost then it doesn't make direct economic sense for the miner to include the transactions.  Miners may include the transaction "anyways" to support the network but we should be aware of the risk of designing a system which requires miners to accept a reduction in reward to "help the network".

It is possible that the benefits outweigh the cost but those are the downsides.  I think achieving a consensus is pretty much impossible but improving the efficiency of the protocol should be done first.  Any change should likely be small (2 to 6 minutes as target).  I would need to see a lot of solid modeling on a robust test net simulation to be convinced it is viable.

leemar (OP)
Full Member
***
Offline Offline

Activity: 193
Merit: 100


View Profile
March 10, 2014, 04:41:25 PM
 #4

The downside is that increased rate of orphans means reduced effective security and increased orphan cost.  The later is more of an issue while the block subsidy is relatively high.  Reducing the orphan cost should be a high priority.  A reduction in the orphan cost of 90%+ is possible with some small non-forking changes to the protocol (the message format used for relaying blocks).

Oprhans reduce the effective security of the network.  Any hashpower spent on orphaned blocks is essentially wasted, reducing the potential cost to an attacker.  As an example a network with 100 TH and 10% orphan rate can be 51% attacked with only 90 TH/s.

The orphan cost is the cost to the miner to add one more tx to the block.  A shorter block interval increases that cost.  If the compensation for the miner is less than the orphan cost then it doesn't make direct economic sense for the miner to include the transactions.  Miners may include the transaction "anyways" to support the network but we should be aware of the risk of designing a system which requires miners to accept a reduction in reward to "help the network".

It is possible that the benefits outweigh the cost but those are the downsides.  I think achieving a consensus is pretty much impossible but improving the efficiency of the protocol should be done first.  Any change should likely be small (2 to 6 minutes as target).  I would need to see a lot of solid modeling on a robust test net simulation to be convinced it is viable.



Thank you, that is very helpful.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!