< GitHub74> [bitcoin] MarcoFalke opened pull request #6887: [qt] Update coin control and smartfee labels (master...MarcoFalke-2015-qtMaxMin_Fee_and_Max_Fee) https://github.com/bitcoin/bitcoin/pull/6887
< CodeShark> I'm experiencing a very strange travis issue - everything works fine with one commit, then I just add this https://github.com/CodeShark/bitcoin/commit/6f42f34f03834b67cc09b53a3809bee9d2239b8e and suddenly I get the seemingly unrelated error: test/alert_tests.cpp(223): error in "PartitionAlert": check strMiscWarning.empty() failed - https://s3.amazonaws.com/archive.travis-ci.org/jobs
< CodeShark> /87276294/log.txt
< CodeShark> the previous commit has no issues: https://github.com/bitcoin/bitcoin/pull/6816/commits
< CodeShark> I'm completely stumped on this one
< phantomcircuit> jgarzik, you can do INSERT INTO table (column, column) VALUES (1,2),(3,4);
< phantomcircuit> batch the batches
< sipa> i doubt that makes any difference
< phantomcircuit> also you need to assert the returned data type
< phantomcircuit> sqlite doesn't strictly enforce the data types...
< phantomcircuit> <jgarzik> I think there is a background WAL checkpoint mode
< phantomcircuit> there isn't you have to do it yourself
< phantomcircuit> sipa, it can make a difference if the batches are very large
< phantomcircuit> you get the best performance with a wal and a background thread that's doing passive checkpoints in a loop
< phantomcircuit> iirc there's an api call to get stats on the journal which can tell you if a SQLITE_CHECKPOINT_FULL would be fast
< phantomcircuit> it'll still be slow probably though
< phantomcircuit> right it's the two output values from sqlite3_wal_checkpoint_v2
< phantomcircuit> pnLog tells you how many frames there are and pnCkpt tells you how many have been checkpointed
< phantomcircuit> nLog - nCkpt == frames left to checkpoint
< CodeShark> hmmm - this won't work for versionbits at all: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2034
< 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?
< wumpus> don't think that's necessary