12015-10-25T00:11:38  *** gmaxwell is now known as gmaxweii
  22015-10-25T00:11:42  *** gmaxweii is now known as gmaxweiI
  32015-10-25T00:11:47  *** gmaxweiI is now known as gmaxwell_
  42015-10-25T00:11:58  *** gmaxwell_ is now known as gmaxwelI
  52015-10-25T00:12:00  *** gmaxwelI is now known as gmaxwell
  62015-10-25T00:15:17  *** danielsocials has joined #bitcoin-core-dev
  72015-10-25T00:19:17  *** belcher is now known as beIcher
  82015-10-25T00:19:39  *** beIcher is now known as belcher
  92015-10-25T00:31:11  *** dgenr8 has quit IRC
 102015-10-25T00:54:20  *** Ylbam has quit IRC
 112015-10-25T01:09:31  <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
 122015-10-25T01:14:57  *** danielsocials has quit IRC
 132015-10-25T01:16:59  *** alpalp has quit IRC
 142015-10-25T01:21:18  *** dgenr8 has joined #bitcoin-core-dev
 152015-10-25T01:37:46  *** danielsocials has joined #bitcoin-core-dev
 162015-10-25T01:58:54  *** danielsocials has quit IRC
 172015-10-25T02:07:29  *** danielsocials has joined #bitcoin-core-dev
 182015-10-25T02:26:32  *** vbuilderv has joined #bitcoin-core-dev
 192015-10-25T02:30:11  *** davec has quit IRC
 202015-10-25T02:36:24  *** danielsocials has quit IRC
 212015-10-25T03:03:31  *** belcher has quit IRC
 222015-10-25T03:14:17  *** danielsocials has joined #bitcoin-core-dev
 232015-10-25T03:17:03  *** danielsocials has quit IRC
 242015-10-25T03:32:20  *** vbuilderv has quit IRC
 252015-10-25T04:45:55  *** helo has quit IRC
 262015-10-25T04:47:28  *** helo has joined #bitcoin-core-dev
 272015-10-25T05:16:51  *** danielsocials has joined #bitcoin-core-dev
 282015-10-25T05:20:31  *** danielsocials has quit IRC
 292015-10-25T05:50:58  <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
 302015-10-25T05:50:58  <CodeShark> /87276294/log.txt
 312015-10-25T05:52:00  <CodeShark> the previous commit has no issues: https://github.com/bitcoin/bitcoin/pull/6816/commits
 322015-10-25T05:53:51  <CodeShark> I'm completely stumped on this one
 332015-10-25T06:10:29  <phantomcircuit> jgarzik, you can do INSERT INTO table (column, column) VALUES (1,2),(3,4);
 342015-10-25T06:10:37  <phantomcircuit> batch the batches
 352015-10-25T06:10:57  <sipa> i doubt that makes any difference
 362015-10-25T06:14:52  <phantomcircuit> also you need to assert the returned data type
 372015-10-25T06:15:00  <phantomcircuit> sqlite doesn't strictly enforce the data types...
 382015-10-25T06:17:47  <phantomcircuit> <jgarzik> I think there is a background WAL checkpoint mode
 392015-10-25T06:17:55  <phantomcircuit> there isn't you have to do it yourself
 402015-10-25T06:21:59  <phantomcircuit> sipa, it can make a difference if the batches are very large
 412015-10-25T06:23:01  <phantomcircuit> you get the best performance with a wal and a background thread that's doing passive checkpoints in a loop
 422015-10-25T06:23:35  <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
 432015-10-25T06:24:25  <phantomcircuit> it'll still be slow probably though
 442015-10-25T06:25:13  <phantomcircuit> right it's the two output values from sqlite3_wal_checkpoint_v2
 452015-10-25T06:25:29  <phantomcircuit> pnLog tells you how many frames there are and pnCkpt tells you how many have been checkpointed
 462015-10-25T06:25:46  <phantomcircuit> nLog - nCkpt == frames left to checkpoint
 472015-10-25T06:34:06  *** crescendo has quit IRC
 482015-10-25T06:35:04  *** crescendo has joined #bitcoin-core-dev
 492015-10-25T06:39:00  <CodeShark> hmmm - this won't work for versionbits at all: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2034
 502015-10-25T06:42:57  <sipa> bip9 specifies a replacement for the alert logic
 512015-10-25T06:45:53  <gmaxwell> heh. 25% of the design of versionbits is specificlly there to facilitate smarter warning behavior.
 522015-10-25T06:52:48  <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?
 532015-10-25T06:53:13  <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
 542015-10-25T06:55:50  <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)
 552015-10-25T06:56:07  <CodeShark> I'd say we should warn if at least half of the blocks within an interval show an unknown bit
 562015-10-25T06:57:54  <gmaxwell> CodeShark: the document talks about this. :(
 572015-10-25T06:58:34  <CodeShark> yes, I'm referring to the document
 582015-10-25T06:59:53  <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.
 592015-10-25T06:59:58  <gmaxwell> https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#Support_for_future_changes
 602015-10-25T07:00:44  <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
 612015-10-25T07:01:02  <CodeShark> regardless of whether or not it's locked in
 622015-10-25T07:04:17  <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
 632015-10-25T07:05:49  <CodeShark> 95% minimum for lock in is probably a good idea - but for warning I'd go WAY lower
 642015-10-25T07:06:42  <gmaxwell> but I think it should not be <50% in some analysis window.
 652015-10-25T07:06:53  <CodeShark> right - at least 50%
 662015-10-25T07:07:25  <CodeShark> it indicates that there's sufficient hash power on the network to enforce it
 672015-10-25T07:07:44  <CodeShark> regardless of what the actual activation mechanism might be
 682015-10-25T07:10:48  <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. :)
 692015-10-25T07:11:31  <CodeShark> right
 702015-10-25T07:12:31  <CodeShark> and we also need to consider cases where nVersion is not a versionbits version
 712015-10-25T07:12:57  <gmaxwell> CodeShark: treat as unknown versionbits.
 722015-10-25T07:13:58  <CodeShark> what if 25% set bit 4 and a disjoint 25% set bit 5 (and we don't recognize either bit 4 nor 5)
 732015-10-25T07:14:42  <CodeShark> that means 50% of versions are unknown, but they are different versions - still no hashpower majority on either
 742015-10-25T07:15:33  <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
 752015-10-25T07:16:33  <gmaxwell> my expectation is that we should warn if half the hashpower is doing something we don't know about.
 762015-10-25T07:17:23  <CodeShark> that would be easiest - just count how many blocks have unrecognized nVersion (versionbits or no) within an interval
 772015-10-25T07:18:06  <CodeShark> if at least 50%, warn (which is similar to the current logic...except that the test is not > CBlock::CURRENT_VERSION
 782015-10-25T07:18:13  <sipa> but within which interval?
 792015-10-25T07:18:15  *** danielsocials has joined #bitcoin-core-dev
 802015-10-25T07:18:32  <CodeShark> well, for ISM we were using a window of 1000, right?
 812015-10-25T07:18:51  <sipa> if the versions _are_ versionbits compatible, you can treat them as an unknown versionbits, and warn if it trigger
 822015-10-25T07:18:51  <CodeShark> and for the current warning system we use a window of 100
 832015-10-25T07:19:05  <sipa> which remains the case potentially after the window expires
 842015-10-25T07:19:55  <CodeShark> right - so we would check a moving window of 100 and continue warning regardless of whether or not anything strange happens afterwards
 852015-10-25T07:21:15  <CodeShark> I'm concerned about reading too much into the deployment mechanism...especially if we're presumably running obsolete software
 862015-10-25T07:22:12  <CodeShark> if half or more of hashing power is doing something we don't recognize, we better figure out what's going on
 872015-10-25T07:23:18  *** danielsocials has quit IRC
 882015-10-25T07:25:23  <CodeShark> easiest would be to replace if (pindex->nVersion > CBlock::CURRENT_VERSION) ++nUpgraded; with if (CheckVersion(pindex->nVersion) != VALID) ++nUpgraded;
 892015-10-25T07:26:02  <CodeShark> or CheckVersion(pindex, blockRuleIndex, consensusParams) rather
 902015-10-25T07:26:34  <CodeShark> in
 912015-10-25T07:26:37  <CodeShark> UpdateTip
 922015-10-25T07:27:12  <CodeShark> where CheckVersion handles all the logic for determining what constitutes a recognized and valid version
 932015-10-25T07:27:54  <CodeShark> and use a sticky flag...once it's triggered it remains set
 942015-10-25T07:29:11  <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
 952015-10-25T07:36:34  *** ParadoxSpiral has joined #bitcoin-core-dev
 962015-10-25T07:40:59  *** ParadoxSpiral_ has joined #bitcoin-core-dev
 972015-10-25T07:43:50  *** ParadoxSpiral has quit IRC
 982015-10-25T07:46:18  *** wangchun has quit IRC
 992015-10-25T07:46:50  *** wangchun has joined #bitcoin-core-dev
1002015-10-25T07:51:05  *** wangchun has quit IRC
1012015-10-25T07:52:24  *** wangchun has joined #bitcoin-core-dev
1022015-10-25T07:55:33  *** danielsocials has joined #bitcoin-core-dev
1032015-10-25T08:34:02  *** Ylbam has joined #bitcoin-core-dev
1042015-10-25T08:42:36  *** rcutmore_ has joined #bitcoin-core-dev
1052015-10-25T08:43:47  *** rcutmore has quit IRC
1062015-10-25T08:49:50  *** randy-waterhouse has joined #bitcoin-core-dev
1072015-10-25T09:34:25  *** go111111111 has quit IRC
1082015-10-25T09:47:54  *** go111111111 has joined #bitcoin-core-dev
1092015-10-25T09:49:58  <GitHub9> [bitcoin] CodeShark opened pull request #6888: Clear strMiscWarning before running PartitionAlert (master...alert_tests) https://github.com/bitcoin/bitcoin/pull/6888
1102015-10-25T09:57:47  *** paveljanik has joined #bitcoin-core-dev
1112015-10-25T10:09:51  *** pigeons has quit IRC
1122015-10-25T10:21:13  *** pigeons has joined #bitcoin-core-dev
1132015-10-25T10:21:37  *** pigeons is now known as Guest25608
1142015-10-25T10:38:55  *** danielsocials has quit IRC
1152015-10-25T11:11:18  *** danielsocials has joined #bitcoin-core-dev
1162015-10-25T11:15:15  *** danielsocials has quit IRC
1172015-10-25T11:16:37  *** danielsocials has joined #bitcoin-core-dev
1182015-10-25T11:17:58  *** danielsocials has quit IRC
1192015-10-25T11:49:59  *** CodeShark has quit IRC
1202015-10-25T12:30:35  *** CodeShark has joined #bitcoin-core-dev
1212015-10-25T12:32:07  <CodeShark> wumpus: should I open an issue for PR #6888?
1222015-10-25T13:13:25  <wumpus> don't think that's necessary
1232015-10-25T13:54:20  *** Ylbam has quit IRC
1242015-10-25T14:03:01  *** Thireus1 has joined #bitcoin-core-dev
1252015-10-25T14:05:16  *** Thireus has quit IRC
1262015-10-25T14:13:26  *** kanzure has quit IRC
1272015-10-25T14:13:55  *** Thireus has joined #bitcoin-core-dev
1282015-10-25T14:14:30  *** kanzure has joined #bitcoin-core-dev
1292015-10-25T14:15:03  *** Thireus1 has quit IRC
1302015-10-25T14:18:38  *** Thireus1 has joined #bitcoin-core-dev
1312015-10-25T14:18:38  *** Thireus has quit IRC
1322015-10-25T14:21:13  *** Thireus has joined #bitcoin-core-dev
1332015-10-25T14:24:19  *** Thireus1 has quit IRC
1342015-10-25T15:35:08  *** rcutmore_ has quit IRC
1352015-10-25T16:09:56  *** d_t has joined #bitcoin-core-dev
1362015-10-25T16:18:03  *** Ylbam has joined #bitcoin-core-dev
1372015-10-25T16:35:30  *** dgenr8 has quit IRC
1382015-10-25T16:36:41  *** davec has joined #bitcoin-core-dev
1392015-10-25T17:04:38  *** d_t has quit IRC
1402015-10-25T17:07:28  *** belcher has joined #bitcoin-core-dev
1412015-10-25T17:44:16  *** CodeShark_ has joined #bitcoin-core-dev
1422015-10-25T17:56:26  *** maaku__ has quit IRC
1432015-10-25T17:57:19  *** CodeShark_ has quit IRC
1442015-10-25T17:57:22  *** belcher has quit IRC
1452015-10-25T17:57:36  *** belcher has joined #bitcoin-core-dev
1462015-10-25T17:58:50  *** challisto has joined #bitcoin-core-dev
1472015-10-25T17:58:50  *** challisto has joined #bitcoin-core-dev
1482015-10-25T20:06:54  *** dgenr8 has joined #bitcoin-core-dev
1492015-10-25T20:15:51  *** JoeLiu has joined #bitcoin-core-dev
1502015-10-25T20:52:12  *** randy-waterhouse has quit IRC
1512015-10-25T21:05:06  *** molly has joined #bitcoin-core-dev
1522015-10-25T21:08:15  *** moli has quit IRC
1532015-10-25T21:15:21  *** ParadoxSpiral_ has quit IRC
1542015-10-25T21:17:09  *** CodeShark_ has joined #bitcoin-core-dev
1552015-10-25T21:59:37  *** d_t has joined #bitcoin-core-dev
1562015-10-25T22:25:48  *** JoeLiu has quit IRC
1572015-10-25T22:32:55  *** dgenr8 has quit IRC
1582015-10-25T22:34:33  <gmaxwell> uh. hm. this looks wrong in my logs.  "connection from x:y accepted" then after ver/verack "Moving x:y to tried".
1592015-10-25T22:34:51  <gmaxwell> Just becausewe got a connection _from_ something does not make it addrman tried.
1602015-10-25T22:38:38  *** go111111111 has quit IRC
1612015-10-25T22:44:02  *** d_t has quit IRC
1622015-10-25T23:15:17  *** dgenr8 has joined #bitcoin-core-dev
1632015-10-25T23:27:17  *** d_t has joined #bitcoin-core-dev
1642015-10-25T23:27:56  *** d_t has joined #bitcoin-core-dev