* [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
@ 2016-01-29 2:31 Jannes Faber
2016-01-29 16:39 ` Gavin Andresen
2016-01-29 19:11 ` Peter Todd
0 siblings, 2 replies; 4+ messages in thread
From: Jannes Faber @ 2016-01-29 2:31 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2122 bytes --]
Hi,
Question if you'll allow me. This is not about Gavin's latest hard fork
proposal but in general about any hard (or soft) fork.
I was surprised to see a period expressed in human time instead of in block
time:
> Blocks with timestamps greater than or equal to the triggering block's
timestamp plus 28 days (60*60*24*28 seconds) shall have the new limits.
But even more so I would expect there to be significant differences in
effects on non-updated clients depending on the moment (expressed as block
number) of applying the new rules. I see a few options, all relating to the
2016 blocks recalibration window.
1) the first block after difficulty adjustment.
2) the last block before the difficulty adjustment.
3) in the middle
4) n blocks before the adjustment with n the smallest number of blocks
calculated such that the adjustment can just manage to do the maximum
possible drop in difficulty.
One of the effects I'm thinking of would be in case of an evil contentious
75-25 hard fork. If that activates at 1) or 2) it will take an awful long
time for the 25% chain to get to 2016 for the next adjustment all the while
having 40 minutes block times. Option 4) sounds a lot better for the
conservative chain. The attacking fork clearly has a choice to make it as
hard as possible for them.
On the other hand when a non-contentious hard fork is rolled out, one could
argue that it's actually best for everyone if the remaining 1% chain
doesn't stand a chance of ever reaching 2016 blocks anymore (not even by a
decent sized attacker trying to double spend on stragglers). Also causing
all alarm bells to go off in the non-updated clients.
Have people thought through all the different scenarios yet?
And would it not make sense to define whatever the best choice is as
mandatory for any hard fork proposal? BIP9? (Realising attackers won't
necessarily follow BIPs anyway.)
Does something like this also play a role for soft forks?
I do realise that it's quite possible for the first few blocks, mined after
the new rules become valid, to still be old style blocks. Thus maybe
defeating the whole planning.
[-- Attachment #2: Type: text/html, Size: 2377 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
2016-01-29 2:31 [bitcoin-dev] Best (block nr % 2016) for hard fork activation? Jannes Faber
@ 2016-01-29 16:39 ` Gavin Andresen
2016-01-29 18:50 ` Jorge Timón
2016-01-29 19:11 ` Peter Todd
1 sibling, 1 reply; 4+ messages in thread
From: Gavin Andresen @ 2016-01-29 16:39 UTC (permalink / raw)
To: Jannes Faber; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1957 bytes --]
On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Hi,
>
> Question if you'll allow me. This is not about Gavin's latest hard fork
> proposal but in general about any hard (or soft) fork.
>
> I was surprised to see a period expressed in human time instead of in
> block time:
>
> > Blocks with timestamps greater than or equal to the triggering block's
> timestamp plus 28 days (60*60*24*28 seconds) shall have the new limits.
>
>
Block timestamps are in the 80-byte block header, so activation is
completely deterministic and can be determined from just the sequence of
block headers. There are no edge cases to worry about.
But even more so I would expect there to be significant differences in
> effects on non-updated clients depending on the moment (expressed as block
> number) of applying the new rules. I see a few options, all relating to the
> 2016 blocks recalibration window.
>
It doesn't matter much where in the difficulty period the fork happens; if
it happens in the middle, the lower-power fork's difficulty will adjust a
little quicker.
Example: (check my math, I'm really good at screwing up at basic
arithmetic):
Fork at block%2016: 25% hashpower will take 8 weeks to produce 2016
blocks, difficulty drops by 4.
Fork one-week (halfway) into difficulty period: 25% hashpower will take 4
weeks to adjust, difficulty drops by 5/2 = 2.5
It will then take another 3.2 weeks to get to the next difficult adjustment
period and normal 10-minute blocks.
That's an unrealisitic scenario, though-- there will not be 25% of hash
power on a minority fork. I wrote about why in a blog post today:
http://gavinandresen.ninja/minority-branches
If you assume a more realistic single-digit-percentage of hash power on the
minority fork, then the numbers get silly (e.g. two or three months of an
hour or three between blocks before a difficulty adjustment).
--
--
Gavin Andresen
[-- Attachment #2: Type: text/html, Size: 3013 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
2016-01-29 16:39 ` Gavin Andresen
@ 2016-01-29 18:50 ` Jorge Timón
0 siblings, 0 replies; 4+ messages in thread
From: Jorge Timón @ 2016-01-29 18:50 UTC (permalink / raw)
To: Gavin Andresen; +Cc: Bitcoin Dev
On Fri, Jan 29, 2016 at 5:39 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Thu, Jan 28, 2016 at 9:31 PM, Jannes Faber via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> It doesn't matter much where in the difficulty period the fork happens; if
> it happens in the middle, the lower-power fork's difficulty will adjust a
> little quicker.
The reason why BIP9 (versionbits) only checks for new activations
during difficulty retargettings is a simple optimization to only check
1/2016 of the blocks.
I suspect the check itself is not that costly for Bitcoin Core, which
has all the block headers in memory anyway, but I don't think we
should assume that will be the case for all implementations.
<BIP99 aside comment>
As an aside, BIP99 never recommends a 75% mining signaling activation
threshold: it recommends 95% for uncontroversial rule changes and no
miner signaling at all for controversial hardforks.
I still have to update BIP99 with some later changes I commented at
Scaling Bitcoin HK like signaling hardfork activation with the
"negative int32_t bit" so that old clients are forced to
upgrade/decide. We could start deploying better ways to inform users
about a hardfork event, but of course those changes cannot be applied
to older software that is already deployed (but hopefully they will
still notice something is weird is happening if the longest chain that
keeps growing is invalid because it contained a block with a negative
version in it).
But I'm yet to see a single hardfork proposal that follows BIP99's
recommendations besides the hardfork proposed in BIP99 itself, which
should consist on a manageable list of very simple to deploy fixes
like the timewarp fix forward-ported from Freicoin 0.8 for the BIP. I
haven't seen much interest in growing that little list of "a few fixes
nobody disagrees are bugs or sub-optimal design decisions, plus the
changes are easy to implement both separately and as a whole" either.
I cannot say I have seen any opposition at all to BIP99 as a hardfork
either, but I naively expected people would ask me to implement more
things for BIP99 besides
https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11
or even contribute the patches themselves. For all that, I don't
consider BIP99 a priority to work on and I plan to complete it at some
point later, unless there's a time limit for a BIP to be in the
"draft" state or something.
If someone else considers completing BIP99 a priority, I'm happy to
review and integrate things, though. Thanks again to all the reviewers
and contributors to the BIP at this time and I'm sorry that it has
been stuck for some time. Maybe the classification/recommendations
should have been a BIP without code and the hardfork proposal itself
should have been another one and that would have been clearer. I just
wanted to have some code on my first BIP (and as said the plan is
still to put more code at some point).
</BIP99 aside comment>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] Best (block nr % 2016) for hard fork activation?
2016-01-29 2:31 [bitcoin-dev] Best (block nr % 2016) for hard fork activation? Jannes Faber
2016-01-29 16:39 ` Gavin Andresen
@ 2016-01-29 19:11 ` Peter Todd
1 sibling, 0 replies; 4+ messages in thread
From: Peter Todd @ 2016-01-29 19:11 UTC (permalink / raw)
To: Jannes Faber; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2222 bytes --]
On Fri, Jan 29, 2016 at 03:31:05AM +0100, Jannes Faber via bitcoin-dev wrote:
> On the other hand when a non-contentious hard fork is rolled out, one could
> argue that it's actually best for everyone if the remaining 1% chain
> doesn't stand a chance of ever reaching 2016 blocks anymore (not even by a
> decent sized attacker trying to double spend on stragglers). Also causing
> all alarm bells to go off in the non-updated clients.
>
> Have people thought through all the different scenarios yet?
I wrote up some of those risks in my "Soft Forks Are Safer Than Hard
Forks" post the other week:
https://petertodd.org/2016/soft-forks-are-safer-than-hard-forks
I was writing mainly in terms of technical risks for deployment
non-controversial forks; for controversial forks there's many more
failure scenarios. In any case, on technical grounds alone it's obvious
that hard-forks without very high - 95% or so - activation thresholds
are quite dangerous.
In general, it should be remembered that high activation thresholds for
hard-forks can always be soft-forked down after the fact. For instance,
suppose we initially used 100% support over the past one month of blocks
as a hard-fork threshold, but can't get more than 96% support. A
soft-fork with the following rule can be implemented:
If 95% of the past blocks vote yes, voting against the hard-fork is
not allowed.
As soft-forks can be rolled out quite quickly, implementing this in the
event that a hard-fork isn't getting sufficient support won't add much
delay to the overall process; as it is a soft-fork, only miners need to
adopt it for it to take effect.
For this reason I'd suggest any hard fork use 99%+ activation
thresholds, measured over multi-week timespan. Hard-forks should not be
controversial for good social/political reasons anyway, so there's
little harm in most cases to at worst delaying the fork by two or three
months if stragglers won't upgrade (in very rare cases like security
issues there may be exceptions; blocksize is certainly not one of those
cases).
--
https://petertodd.org 'peter'[:-1]@petertodd.org
000000000000000005822b77a904129795a3ff4167c57ed1044f5a93512c830f
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-01-29 19:11 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-29 2:31 [bitcoin-dev] Best (block nr % 2016) for hard fork activation? Jannes Faber
2016-01-29 16:39 ` Gavin Andresen
2016-01-29 18:50 ` Jorge Timón
2016-01-29 19:11 ` Peter Todd
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox