Your Bitcoin transactions The Ultimate Bitcoin mixer made truly anonymous. with an advanced technology. Mix coins



Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.

gmaxwell

Legendary





Online



Activity: 2660

Merit: 2016









ModeratorLegendaryActivity: 2660Merit: 2016 Re: Reasons to keep 10 min target blocktime? July 21, 2013, 08:47:54 PM #2 You know this has been discussed many times before. it would be really best if you'd spent some more time studying them rather than starting a new thread and externalize the studying cost



You seem to know the primary arguments against it, but I'll repeat the ones I think are most interesting:



(1) Orphaning rate depends on the time relative to communications & validation delay (formula given in the link). At the limit as the block-time goes to zero the network will stop converging and typical reorganizations tend to infinitely long. The actual delays depend on network topography and block size. And as an aside in the past we've seen global convergence times on Bitcoin get up to over two minutes, although the software performance has been improved since then it doesn't seem that there a ton of headroom before convergence failures would be likely in practice, certainly fast convergence is harder with larger blocks.



(1a) There have been altcoins who didn't understand this and set their block times to be stupidly low and suffered pretty much instant convergence failure (e.g. liquidcoin). There are other ones that may start failing if they ever get enough transaction volume that validation actually takes a bit of time.



(2) The computational/bandwidth/storage cost of running a SPV node, or query a remote computation oracle for signing, or to present a bitcoin proof in a non-bitcoin chain is almost entirely due to the header rate. Going to 5 minutes, for example, would double these costs. Increasing costs for the most cost-sensitive usages is not very attractive.



(3) With the exception of 1 confirmation transactions, once you are slow enough that orphaning isn't a major consideration there is no real security difference that depend on the particular rate. For moderate length attacks sum computation matters and how you dice it up doesn't matter much. One confirm security however isn't particular secure.



(3a) If there is actually a demand for fast low security evidence of mining effort, you can achieve that simply by having miners publish shares like P2Pool does. You could then look at this data and estimate how much of the network hashrate is attempting to include the transaction you're interested in. This doesn't, however, create the orphaning/convergence problems of (1) or the bandwidth/storage impact on disinterested nodes of (2).



(3b) Because mining is a stochastic lottery confirmations can take a rather long time even when the mean is small. Few things which you can describe as "needing" a 2 minute mean would actually still be happy with it taking 5 times that sometimes. Those applications simply need to use other mechanisms than global consensus as their primary mechanism.



(4) While you can debate the fine details of the parameters perhaps 20 minutes or 5 minutes would have been wiser because of the above none of the arguments are all that compelling. Changing this parameter would require the consent of all of the surviving Bitcoin users, absent a really compelling argument it simply isn't going to happen.



If you'd like to explore these ideas just as an intellectual novelty, Amiller's ideas about merging in evidence of orphaned blocks to target an orphaning rate instead of a time are probably the most interesting the problem then becomes things like how to prevent cliques of fast miners self-centralizing against further away groups who can't keep up, and producing proofs for SPV clients which are succinct in the face of potentially quite fast blocks.



2112



Offline



Activity: 2114

Merit: 1027









LegendaryActivity: 2114Merit: 1027 Re: Reasons to keep 10 min target blocktime? July 22, 2013, 02:09:57 AM

Last edit: July 22, 2013, 02:29:30 AM by 2112 #3



(5) you really want to make sure that your coin can work and converge through Tor. That includes:



(5a) plain Tor: 3 hops



(5b) hidden service Tor: 6 hops + onion address lookup time



Edit: If you still aren't convinced please reread the discussion with Lolcust about Geist Geld with 15 seconds of interblock time.



https://bitcointalk.org/index.php?topic=42417.msg528001#msg528001

In addition to the excellent points made by gmaxwell:(5) you really want to make sure that your coin can work and converge through Tor. That includes:(5a) plain Tor: 3 hops(5b) hidden service Tor: 6 hops + onion address lookup timeEdit: If you still aren't convinced please reread the discussion with Lolcust about Geist Geld with 15 seconds of interblock time.

Long-term mining prognosis: Please comment, critique, criticize or ridicule BIP 2112: https://bitcointalk.org/index.php?topic=54382.0 Long-term mining prognosis: https://bitcointalk.org/index.php?topic=91101.0

kjj



Offline



Activity: 1302

Merit: 1001









LegendaryActivity: 1302Merit: 1001 Re: Reasons to keep 10 min target blocktime? July 22, 2013, 05:06:41 AM #4 And if that isn't enough, bitcoin has a bunch of magic numbers in it. Most of them seem to have been picked because they were round numbers that fit into a broad range of values that were "good enough".



Consider that the average block time could have been chosen anywhere from 1 second to 86400 seconds. 1 second is clearly too short for network convergence. 86400 seconds is clearly too long for effective commerce. Between those two extremes is a broad band that is "good enough" for both, as well as regions that are questionable for one or the other. Would 60 seconds be too short? Probably. 120? Maybe. Would 3600 seconds be too long? Probably. 1800? Maybe.



And the various magic numbers interact. For example, the block time and the subsidy function come together to set the generation curve.



Satoshi was either very lucky, or very thoughtful. The numbers he picked all came together to give us a workable system. The success of the system gives a very strong (quasi)anthropic argument: we are here discussion the merits of various key values because the system works well enough for us to care about it. If he had chosen poorly, bitcoin would not have taken off.



And finally, consider litecoin. Litecoin has a 150 second block time. This number appears to still be large enough that convergence isn't a huge problem. But litecoin does not appear to be used for commerce other than buying and selling litecoins, so a shorter time seems to provide no commercial benefits. If the long block time was holding us back, the world would have beaten a path to litecoin. 17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8

I routinely ignore posters with paid advertising in their sigs. You should too.

gmaxwell

Legendary





Online



Activity: 2660

Merit: 2016









ModeratorLegendaryActivity: 2660Merit: 2016 Re: Reasons to keep 10 min target blocktime? July 22, 2013, 03:32:47 PM #6 Quote from: kjj on July 22, 2013, 05:06:41 AM And finally, consider litecoin. Litecoin has a 150 second block time. This number appears to still be large enough that convergence isn't a huge problem.

I'm not so sure there as I mentioned we've observed propagation times in Bitcoin that would have made litecoin catch fire with its inter-block gap Difference is that Bitcoin is bigger and has more transactions, though perhaps the performance improvements made to 0.8+ have removed this risk. I'm not so sure there as I mentioned we've observed propagation times in Bitcoin that would have made litecoin catch fire with its inter-block gap Difference is that Bitcoin is bigger and has more transactions, though perhaps the performance improvements made to 0.8+ have removed this risk.

yaffare



Offline



Activity: 45

Merit: 0







NewbieActivity: 45Merit: 0 Re: Reasons to keep 10 min target blocktime? July 22, 2013, 07:37:24 PM #7 Isnt the argumentation at least a little flawed?



Because shorter block times also mean shorter blocks.



Should make no difference, if you have for 10 minute block time, 1 time long validation time,

while for 1 minute blocks, 10 time short validation time. The sum is the same.



gmaxwell

Legendary





Online



Activity: 2660

Merit: 2016









ModeratorLegendaryActivity: 2660Merit: 2016 Re: Reasons to keep 10 min target blocktime? July 22, 2013, 11:48:21 PM #15 Quote from: Cubic Earth on July 22, 2013, 09:09:39 PM I am concerned that a possible practical improvement is getting lost in the theory discussion. You have studiously ignored what was probably the most important point I made. There is no improvement possible here which requires a rule change. You could happily publish half-difficulty shares and share-chain like P2Pool if faster evidence of confirmation was needed. In light of that alone, regardless of any speculation about perhaps 5 minutes might actually also be safe (speculation I consider highly risky because it's only safe under the current network load and topology), I believe your advocacy here has no chance of forward progress.

You have studiously ignored what was probably the most important point I made. There is no improvement possible here which requires a rule change. You could happily publish half-difficulty shares and share-chain like P2Pool if faster evidence of confirmation was needed. In light of that alone, regardless of any speculation about perhaps 5 minutes might actually also be safe (speculation I consider highly risky because it's only safe under the current network load and topology), I believe your advocacy here has no chance of forward progress.

runeks



Offline



Activity: 952

Merit: 1000









LegendaryActivity: 952Merit: 1000 Re: Reasons to keep 10 min target blocktime? July 23, 2013, 09:22:02 AM #17 Quote from: gmaxwell on July 22, 2013, 11:48:21 PM Quote from: Cubic Earth on July 22, 2013, 09:09:39 PM I am concerned that a possible practical improvement is getting lost in the theory discussion. You have studiously ignored what was probably the most important point I made. There is no improvement possible here which requires a rule change. You could happily publish half-difficulty shares and share-chain like P2Pool if faster evidence of confirmation was needed. In light of that alone, regardless of any speculation about perhaps 5 minutes might actually also be safe (speculation I consider highly risky because it's only safe under the current network load and topology), I believe your advocacy here has no chance of forward progress.

You have studiously ignored what was probably the most important point I made. There is no improvement possible here which requires a rule change.In light of that alone, regardless of any speculation about perhaps 5 minutes might actually also be safe (speculation I consider highly risky because it's only safe under the current network load and topology), I believe your advocacy here has no chance of forward progress.



Let's say you create blocks every 10 seconds, and append them to a P2Pool-like share-chain, which much follow the same rules as the Bitcoin blockchain in the sense that no transactions in a share must conflict with a transaction in a previous share. The effect of this is that fees become irrelevant, or at least that you can only choose which transactions to include from the previous 10 seconds of transactions. If a block becomes full after 5 minutes, you would be forced to mine the share chain and not be able to remove low fee transactions even if new high fee transactions come in. You only have a window of 10 seconds within which you can choose which transactions to include. Once that share is calculated you cannot remove transactions from the share chain.



This creates an incentive for miners to not participate in this faster share chain, unless we can find some elegant way of compensating miners for their effort that doesn't bloat the block chain (I haven't been able to figure out how to do this yet). This is not equivalent to a shorter block time. The issue with this approach is that the miners who do not participate in this system have greater freedom in choosing which transactions to include in a block, and can thus make more money from fees. Perhaps this isn't an issue now, but it will become an issue at some point.Let's say you create blocks every 10 seconds, and append them to a P2Pool-like share-chain, which much follow the same rules as the Bitcoin blockchain in the sense that no transactions in a share must conflict with a transaction in a previous share. The effect of this is that fees become irrelevant, or at least that you can only choose which transactions to include from the previous 10 seconds of transactions. If a block becomes full after 5 minutes, you would be forced to mine the share chain and not be able to remove low fee transactions even if new high fee transactions come in. You only have a window of 10 seconds within which you can choose which transactions to include. Once that share is calculated you cannot remove transactions from the share chain.This creates an incentive for miners toparticipate in this faster share chain, unless we can find some elegant way of compensating miners for their effort that doesn't bloat the block chain (I haven't been able to figure out how to do this yet).

gmaxwell

Legendary





Online



Activity: 2660

Merit: 2016









ModeratorLegendaryActivity: 2660Merit: 2016 Re: Reasons to keep 10 min target blocktime? July 23, 2013, 09:29:07 AM #18 Quote from: runeks on July 23, 2013, 09:22:02 AM This is not equivalent to a shorter block time. The issue with this approach is that the miners who do not participate in this system have greater freedom in choosing which transactions to include in a block, and can thus make more money from fees. Perhaps this isn't an issue now, but it will become an issue at some point. Wherever did I say it was optional? I'm sorry if I was unclear. You can achieve equivalent behavior without a hard fork and without bloating up the headers with a higher block rate. I didn't say that you could achieve actual early consensus without imposing _any_ new rules (although if you only want evidence of intention thats another matter). You simply enforce the sharechain as a soft forking rule at the tip of the chain, and forget it with it buried non miners who don't care about this activity could ignore it.



You're over-constraining it with assumptions. 10 seconds? The poster referenced 5 minutes. Wherever did I say it was optional? I'm sorry if I was unclear. You can achieve equivalent behavior without a hard fork and without bloating up the headers with a higher block rate. I didn't say that you could achieve actual early consensus without imposing _any_ new rules (although if you only want evidence of intention thats another matter). You simply enforce the sharechain as a soft forking rule at the tip of the chain, and forget it with it buried non miners who don't care about this activity could ignore it.You're over-constraining it with assumptions. 10 seconds? The poster referenced 5 minutes.

TierNolan



Offline



Activity: 1218

Merit: 1002







LegendaryActivity: 1218Merit: 1002 Re: Reasons to keep 10 min target blocktime? July 23, 2013, 09:58:46 AM #19 Quote from: runeks on July 23, 2013, 09:22:02 AM This is not equivalent to a shorter block time. The issue with this approach is that the miners who do not participate in this system have greater freedom in choosing which transactions to include in a block, and can thus make more money from fees. Perhaps this isn't an issue now, but it will become an issue at some point.



Even as evidence it would be helpful. Each miner broadcasts all headers with 1/64 of the standard difficulty. This allows ties to be broken more quickly, so random reversals are much less likely.



It helps even with malicious reversals, as long as honest nodes are willing to mine against a slightly shorter chain.



Forks could be compared using total number of low POW headers on each block in the chain.



So, if there were 2 possible chains which fork at B/B', then the first chain would still win.



A(63) <- B(72) <- C(37) <- D(58)



and



A(63) <- B'(6) <- C'(9) <- D'(4) <- E(7) <- F(6)



Miners would know that almost all of the hashing power is against the first fork, so it will eventually overpower then 2nd fork.



Even if only 75% of the miners have that rule, the top fork will win. Even as evidence it would be helpful. Each miner broadcasts all headers with 1/64 of the standard difficulty. This allows ties to be broken more quickly, so random reversals are much less likely.It helps even with malicious reversals, as long as honest nodes are willing to mine against a slightly shorter chain.Forks could be compared using total number of low POW headers on each block in the chain.So, if there were 2 possible chains which fork at B/B', then the first chain would still win.A(63) 1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF