On Mon, Nov 07, 2011 at 10:27:57AM -0500, Luke-Jr wrote:
> On Monday, November 07, 2011 10:02:43 AM Pieter Wuille wrote:
> > Maybe a short interval (1 minute? 10 minutes?) instead of a fixed
> > value could be allowed for the multiple-of-2016 blocks.
>
> Reminder that there is *already* a short in
On Monday, November 07, 2011 10:02:43 AM Pieter Wuille wrote:
> Maybe a short interval (1 minute? 10 minutes?) instead of a fixed
> value could be allowed for the multiple-of-2016 blocks.
Reminder that there is *already* a short interval only allowed for blocks in
general...
On Tue, Sep 13, 2011 at 11:06:37AM -0400, Gavin Andresen wrote:
> Background:
>
> Timejacking:
> http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html
>
> And a recent related exploit launched against the low-difficulty
> alternative chains:
> https://bitcointalk.org/index.php?topi
On Wednesday, September 14, 2011 4:09:00 PM Gregory Maxwell wrote:
> Though I generally agree with Luke that we should just fix the root
> cause even though it forks the chain.
I don't support this, unless all other chain-forking-needed changes are made
at the same time. I do point out that chang
On Wednesday, September 14, 2011 5:51 PM, "Gregory Maxwell"
wrote:
> General network health and user security _requires_ periodic upgrades
> in any case, and will for the foreseeable future. The whole notion
> that old versions will _stop working_ would be a pretty good thing at
> this point in b
On Wed, Sep 14, 2011 at 5:36 PM, Alex Waters wrote:
> On Wed, Sep 14, 2011 at 4:28 PM, Gavin Andresen
> wrote:
>
>> What do other people think? I think it is too high risk for too
>> little benefit and shouldn't be done until we have a really compelling
>> reason to introduce a forking change.
A better retarget strategy might be to use the real average time
between all of the blocks in the interval so that no blocks are
treated specially in the calculation. I agree that this is not
important enough to fork the chain over, though. An attacker would
have to maintain control for a *very* lo
On Wed, Sep 14, 2011 at 4:28 PM, Gavin Andresen wrote:
> What do other people think? I think it is too high risk for too
> little benefit and shouldn't be done until we have a really compelling
> reason to introduce a forking change.
Could we bundle this and potential future blockchain-splittin
> Perhaps better thing to do is to also delay the _forwarding_ of these
> blocks _and_ blocks that extend them, until extended one more time.
Excellent idea, that gets the incentives right.
RE: fixing the root cause with a forking change:
What do other people think? I think it is too high risk
On Wed, Sep 14, 2011 at 3:52 PM, Aidan Thornton wrote:
> Of course, if only a small percentage of mining power adopts this
> scheme, everyone that does so will presumably be harming themselves by
> doing so since they're essentially increasing the odds that the next
> block they mine will become i
On Wed, Sep 14, 2011 at 3:45 PM, Gavin Andresen wrote:
> Modify the getwork code to build on the second-from-tip block if the
> first-on-tip block is on the discouraged list.
>
> Assuming a majority of pools/miners adopt the "discourage blocks with
> stale timestamps" rule, that should squash any
Am I the only one to think putting pools at a disadvantage is actually
desirable?
Back when pools started to appear we all had huge reservations about putting
so much control into the hands of a few pool operators, but nowadays it
seems that having pool operators control a vast majority of the
comp
On Wednesday, September 14, 2011 10:45:36 AM Gavin Andresen wrote:
> The block timestamp rules currently give HOURS of wiggle-room for
> timestamps. We can't change those rules without risking a chain split.
And those hours of wiggle-room are not enough to cause a problem.
The problem only comes i
> But that doesn't solve the whole problem, because the block timestamp
> checking is based on the assumption that the node is looking at the bitcoin
> clock rather than the, ahem, real clock. If we change the idea of network
> time to NTP, we will then need to write (and test!) new block timestam
On Tuesday, September 13, 2011 11:06:37 AM Gavin Andresen wrote:
> Fixing (2) is easier; incorporating a ntp library and/or simply
> removing the bitcoin mining code from the client but requiring pools
> and miners to have accurate-to-within-a-minute system clocks (or their
> blocks will be "discou
Gavin Andresen wrote:
> Background:
>
> Timejacking:
>http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html
>
> And a recent related exploit launched against the low-difficulty
> alternative chains:
>https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
>
>
> Seems to
> Fixing (2) is easier; incorporating a ntp library and/or simply
> removing the bitcoin mining code from the client but requiring pools
> and miners to have accurate-to-within-a-minute system clocks (or their
> blocks will be "discouraged") seems reasonable to me.
Incorporating NTP seems overkil
> 2) Bitcoin's "what time is it" code is kind of a hack.
...
> Fixing (2) is easier; incorporating a ntp library and/or simply
> removing the bitcoin mining code from the client but requiring pools
> and miners to have accurate-to-within-a-minute system clocks (or their
> blocks will be "discourage
Background:
Timejacking:
http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html
And a recent related exploit launched against the low-difficulty
alternative chains:
https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772
Seems to me there are two fundamental problems:
1
19 matches
Mail list logo
