* [Bitcoin-development] Increasing regularity of block times?
@ 2014-10-30 23:18 Rusty Russell
2014-10-30 23:34 ` Jeff Garzik
2014-10-30 23:34 ` Gregory Maxwell
0 siblings, 2 replies; 4+ messages in thread
From: Rusty Russell @ 2014-10-30 23:18 UTC (permalink / raw)
To: Bitcoin Dev
Hi all,
I've been toying with an algorithm to place a ceiling on
confirmation latency by allowing weaker blocks after a certain time.
Hope this isn't noise, but thought someone must have considered this
before, or know of flaws in the scheme?
Gory details:
http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html
Thanks,
Rusty.
^ permalink raw reply [flat|nested] 4+ messages in thread* Re: [Bitcoin-development] Increasing regularity of block times? 2014-10-30 23:18 [Bitcoin-development] Increasing regularity of block times? Rusty Russell @ 2014-10-30 23:34 ` Jeff Garzik 2014-10-30 23:34 ` Gregory Maxwell 1 sibling, 0 replies; 4+ messages in thread From: Jeff Garzik @ 2014-10-30 23:34 UTC (permalink / raw) To: Rusty Russell; +Cc: Bitcoin Dev That's what we do for testnet today: https://en.bitcoin.it/wiki/Testnet If no block is found for 20 minutes, one minimum-diff block may be mined. On Thu, Oct 30, 2014 at 7:18 PM, Rusty Russell <rusty@rustcorp•com.au> wrote: > Hi all, > > I've been toying with an algorithm to place a ceiling on > confirmation latency by allowing weaker blocks after a certain time. > Hope this isn't noise, but thought someone must have considered this > before, or know of flaws in the scheme? > > Gory details: > http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html > > Thanks, > Rusty. > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] Increasing regularity of block times? 2014-10-30 23:18 [Bitcoin-development] Increasing regularity of block times? Rusty Russell 2014-10-30 23:34 ` Jeff Garzik @ 2014-10-30 23:34 ` Gregory Maxwell 2014-10-31 3:31 ` Rusty Russell 1 sibling, 1 reply; 4+ messages in thread From: Gregory Maxwell @ 2014-10-30 23:34 UTC (permalink / raw) To: Rusty Russell; +Cc: Bitcoin Dev On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell <rusty@rustcorp•com.au> wrote: > Hi all, > > I've been toying with an algorithm to place a ceiling on > confirmation latency by allowing weaker blocks after a certain time. > Hope this isn't noise, but thought someone must have considered this > before, or know of flaws in the scheme? > > Gory details: > http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html Irregularity is a required property for convergence. Imagine what would happen in a network where a blocks were produced at an exact interval: Almost everyone would produce one the exact same time, and the network would fragment and because the process would continue it would not converge. It is precisely the variance being some huge multiple of the network radius which allows the network to converge at all. When lower variance is tolerable for convergence it can be achieved by reducing the expectation. Maybe some other distribution can be proven to be convergent to, it's difficult to reason about. Bitcoin testnet implements a rule that allows lower difficulty blocks after a delay (20 minutes, in fact), but it's a testing-toy... not secure or intended to be so. At least one altcoin has copied that behavior and been exploited on account of it. If you're simply looking for faster evidence that the network is working on a particular transaction set, at some lower timescale:, then thats already possible. e.g. look into how the p2pool sharechain builds a consensus around mining work used for pooling. The same mechanism can be used to give faster transaction selection evidence. I'll dig up some citations for you later. Cheers. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] Increasing regularity of block times? 2014-10-30 23:34 ` Gregory Maxwell @ 2014-10-31 3:31 ` Rusty Russell 0 siblings, 0 replies; 4+ messages in thread From: Rusty Russell @ 2014-10-31 3:31 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev Gregory Maxwell <gmaxwell@gmail•com> writes: > On Thu, Oct 30, 2014 at 11:18 PM, Rusty Russell <rusty@rustcorp•com.au> wrote: >> Hi all, >> >> I've been toying with an algorithm to place a ceiling on >> confirmation latency by allowing weaker blocks after a certain time. >> Hope this isn't noise, but thought someone must have considered this >> before, or know of flaws in the scheme? >> >> Gory details: >> http://rustyrussell.github.io/pettycoin/2014/10/30/More-Regular-Block-Times.html > > Irregularity is a required property for convergence. Imagine what > would happen in a network where a blocks were produced at an exact > interval: Almost everyone would produce one the exact same time, and > the network would fragment and because the process would continue it > would not converge. Your point is well made. If everyone published their easy blocks at the 20 minute mark, divergence would be a problem (though with 6/7 blocks being normal, the network would probably recover). I was proposing to relay them as normal, they're just not accepted until 20 minutes. (Though with the suggested variant of accepting the most-compatible rather than first-seen block, this isn't so critical). > It is precisely the variance being some huge multiple of the network > radius which allows the network to converge at all. I hadn't thought about it that way, but I assumed GHOST mitigate this down to some lower limit. Or? > Bitcoin testnet implements a rule that allows lower difficulty blocks > after a delay (20 minutes, in fact), but it's a testing-toy... not > secure or intended to be so. At least one altcoin has copied that > behavior and been exploited on account of it. Agreed, that would be foolish. Note that in my proposal, block timestamps wouldn't reflect the delay (removing incentive to push timestamps forward, but making judging historical blockchain's validity harder). > If you're simply looking for faster evidence that the network is > working on a particular transaction set, at some lower timescale:, > then thats already possible. e.g. look into how the p2pool sharechain > builds a consensus around mining work used for pooling. The same > mechanism can be used to give faster transaction selection evidence. Nice idea. Publishing WIP blocks like this could provide evidence, but you'd have to incentivize miners to publish them. Can you think of a way to do that (which beats simply reducing the block time)? > I'll dig up some citations for you later. Cheers. Thanks for your time, Rusty. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2014-10-31 3:49 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-10-30 23:18 [Bitcoin-development] Increasing regularity of block times? Rusty Russell 2014-10-30 23:34 ` Jeff Garzik 2014-10-30 23:34 ` Gregory Maxwell 2014-10-31 3:31 ` Rusty Russell
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox