< sipa>
bip9 specifies a replacement for the alert logic
< gmaxwell>
heh. 25% of the design of versionbits is specificlly there to facilitate smarter warning behavior.
< CodeShark>
the current spec says we should only warn if a lock-in is detected for an unknown bit - so if the bit is set in 94% of blocks for an interval no warning?
< CodeShark>
I was thinking to warn if any unknown bit is detected...but that would make it easy for miners to trip off a bunch of clients with a single block
< CodeShark>
furthermore, it presumes we can detect a lock-in for a fork we haven't even defined...so this would force the threshold to actually be a chain parameter (and would potentially complicate matters if we ever want to modify thresholds)
< CodeShark>
I'd say we should warn if at least half of the blocks within an interval show an unknown bit
< gmaxwell>
CodeShark: the document talks about this. :(
< CodeShark>
yes, I'm referring to the document
< gmaxwell>
The thresholds are specified but they are not consensus rules. If one uses another threshold, one can do so-- but one has to cope with whatever impact that has on warning behavior.
< CodeShark>
the document says "Whenever lock-in for the unknown upgrade is detected, the software should warn loudly about the upcoming soft fork. It should warn even more loudly after the next retarget period." - I'm saying if at least half the blocks in an interval show a particular set bit that we do not recognize, we should probably start warning
< CodeShark>
regardless of whether or not it's locked in
< CodeShark>
moreover, if we up the thresholds later on and still have soft forks deployed that have not locked in nor expired, it gets tricky
< CodeShark>
95% minimum for lock in is probably a good idea - but for warning I'd go WAY lower
< gmaxwell>
but I think it should not be <50% in some analysis window.
< CodeShark>
right - at least 50%
< CodeShark>
it indicates that there's sufficient hash power on the network to enforce it
< CodeShark>
regardless of what the actual activation mechanism might be
< gmaxwell>
it also means that if someone is just trying to trigger the warning for lulz they need enough hashpower to cause much more trouble. :)
< CodeShark>
right
< CodeShark>
and we also need to consider cases where nVersion is not a versionbits version
< gmaxwell>
CodeShark: treat as unknown versionbits.
< CodeShark>
what if 25% set bit 4 and a disjoint 25% set bit 5 (and we don't recognize either bit 4 nor 5)
< CodeShark>
that means 50% of versions are unknown, but they are different versions - still no hashpower majority on either
< CodeShark>
the logic I was considering was checking whether nVersion starts with bits 001. If so, count each unknown bit separately for the interval. If not, use different logic
< gmaxwell>
my expectation is that we should warn if half the hashpower is doing something we don't know about.
< CodeShark>
that would be easiest - just count how many blocks have unrecognized nVersion (versionbits or no) within an interval
< CodeShark>
if at least 50%, warn (which is similar to the current logic...except that the test is not > CBlock::CURRENT_VERSION
< sipa>
but within which interval?
< CodeShark>
well, for ISM we were using a window of 1000, right?
< sipa>
if the versions _are_ versionbits compatible, you can treat them as an unknown versionbits, and warn if it trigger
< CodeShark>
and for the current warning system we use a window of 100
< sipa>
which remains the case potentially after the window expires
< CodeShark>
right - so we would check a moving window of 100 and continue warning regardless of whether or not anything strange happens afterwards
< CodeShark>
I'm concerned about reading too much into the deployment mechanism...especially if we're presumably running obsolete software
< CodeShark>
if half or more of hashing power is doing something we don't recognize, we better figure out what's going on
< CodeShark>
easiest would be to replace if (pindex->nVersion > CBlock::CURRENT_VERSION) ++nUpgraded; with if (CheckVersion(pindex->nVersion) != VALID) ++nUpgraded;
< CodeShark>
or CheckVersion(pindex, blockRuleIndex, consensusParams) rather
< CodeShark>
in
< CodeShark>
UpdateTip
< CodeShark>
where CheckVersion handles all the logic for determining what constitutes a recognized and valid version
< CodeShark>
and use a sticky flag...once it's triggered it remains set
< CodeShark>
if it *is* versionbits compatible, we can check whether it is a versionbits version and check for lock-in windows and stuff like that
< GitHub9>
[bitcoin] CodeShark opened pull request #6888: Clear strMiscWarning before running PartitionAlert (master...alert_tests) https://github.com/bitcoin/bitcoin/pull/6888
< CodeShark>
wumpus: should I open an issue for PR #6888?