1 2015-10-25T00:11:38  *** gmaxwell is now known as gmaxweii
  2 2015-10-25T00:11:42  *** gmaxweii is now known as gmaxweiI
  3 2015-10-25T00:11:47  *** gmaxweiI is now known as gmaxwell_
  4 2015-10-25T00:11:58  *** gmaxwell_ is now known as gmaxwelI
  5 2015-10-25T00:12:00  *** gmaxwelI is now known as gmaxwell
  6 2015-10-25T00:15:17  *** danielsocials has joined #bitcoin-core-dev
  7 2015-10-25T00:19:17  *** belcher is now known as beIcher
  8 2015-10-25T00:19:39  *** beIcher is now known as belcher
  9 2015-10-25T00:31:11  *** dgenr8 has quit IRC
 10 2015-10-25T00:54:20  *** Ylbam has quit IRC
 11 2015-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
 12 2015-10-25T01:14:57  *** danielsocials has quit IRC
 13 2015-10-25T01:16:59  *** alpalp has quit IRC
 14 2015-10-25T01:21:18  *** dgenr8 has joined #bitcoin-core-dev
 15 2015-10-25T01:37:46  *** danielsocials has joined #bitcoin-core-dev
 16 2015-10-25T01:58:54  *** danielsocials has quit IRC
 17 2015-10-25T02:07:29  *** danielsocials has joined #bitcoin-core-dev
 18 2015-10-25T02:26:32  *** vbuilderv has joined #bitcoin-core-dev
 19 2015-10-25T02:30:11  *** davec has quit IRC
 20 2015-10-25T02:36:24  *** danielsocials has quit IRC
 21 2015-10-25T03:03:31  *** belcher has quit IRC
 22 2015-10-25T03:14:17  *** danielsocials has joined #bitcoin-core-dev
 23 2015-10-25T03:17:03  *** danielsocials has quit IRC
 24 2015-10-25T03:32:20  *** vbuilderv has quit IRC
 25 2015-10-25T04:45:55  *** helo has quit IRC
 26 2015-10-25T04:47:28  *** helo has joined #bitcoin-core-dev
 27 2015-10-25T05:16:51  *** danielsocials has joined #bitcoin-core-dev
 28 2015-10-25T05:20:31  *** danielsocials has quit IRC
 29 2015-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
 30 2015-10-25T05:50:58  <CodeShark> /87276294/log.txt
 31 2015-10-25T05:52:00  <CodeShark> the previous commit has no issues: https://github.com/bitcoin/bitcoin/pull/6816/commits
 32 2015-10-25T05:53:51  <CodeShark> I'm completely stumped on this one
 33 2015-10-25T06:10:29  <phantomcircuit> jgarzik, you can do INSERT INTO table (column, column) VALUES (1,2),(3,4);
 34 2015-10-25T06:10:37  <phantomcircuit> batch the batches
 35 2015-10-25T06:10:57  <sipa> i doubt that makes any difference
 36 2015-10-25T06:14:52  <phantomcircuit> also you need to assert the returned data type
 37 2015-10-25T06:15:00  <phantomcircuit> sqlite doesn't strictly enforce the data types...
 38 2015-10-25T06:17:47  <phantomcircuit> <jgarzik> I think there is a background WAL checkpoint mode
 39 2015-10-25T06:17:55  <phantomcircuit> there isn't you have to do it yourself
 40 2015-10-25T06:21:59  <phantomcircuit> sipa, it can make a difference if the batches are very large
 41 2015-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
 42 2015-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
 43 2015-10-25T06:24:25  <phantomcircuit> it'll still be slow probably though
 44 2015-10-25T06:25:13  <phantomcircuit> right it's the two output values from sqlite3_wal_checkpoint_v2
 45 2015-10-25T06:25:29  <phantomcircuit> pnLog tells you how many frames there are and pnCkpt tells you how many have been checkpointed
 46 2015-10-25T06:25:46  <phantomcircuit> nLog - nCkpt == frames left to checkpoint
 47 2015-10-25T06:34:06  *** crescendo has quit IRC
 48 2015-10-25T06:35:04  *** crescendo has joined #bitcoin-core-dev
 49 2015-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
 50 2015-10-25T06:42:57  <sipa> bip9 specifies a replacement for the alert logic
 51 2015-10-25T06:45:53  <gmaxwell> heh. 25% of the design of versionbits is specificlly there to facilitate smarter warning behavior.
 52 2015-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?
 53 2015-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
 54 2015-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)
 55 2015-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
 56 2015-10-25T06:57:54  <gmaxwell> CodeShark: the document talks about this. :(
 57 2015-10-25T06:58:34  <CodeShark> yes, I'm referring to the document
 58 2015-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.
 59 2015-10-25T06:59:58  <gmaxwell> https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#Support_for_future_changes
 60 2015-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
 61 2015-10-25T07:01:02  <CodeShark> regardless of whether or not it's locked in
 62 2015-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
 63 2015-10-25T07:05:49  <CodeShark> 95% minimum for lock in is probably a good idea - but for warning I'd go WAY lower
 64 2015-10-25T07:06:42  <gmaxwell> but I think it should not be <50% in some analysis window.
 65 2015-10-25T07:06:53  <CodeShark> right - at least 50%
 66 2015-10-25T07:07:25  <CodeShark> it indicates that there's sufficient hash power on the network to enforce it
 67 2015-10-25T07:07:44  <CodeShark> regardless of what the actual activation mechanism might be
 68 2015-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. :)
 69 2015-10-25T07:11:31  <CodeShark> right
 70 2015-10-25T07:12:31  <CodeShark> and we also need to consider cases where nVersion is not a versionbits version
 71 2015-10-25T07:12:57  <gmaxwell> CodeShark: treat as unknown versionbits.
 72 2015-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)
 73 2015-10-25T07:14:42  <CodeShark> that means 50% of versions are unknown, but they are different versions - still no hashpower majority on either
 74 2015-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
 75 2015-10-25T07:16:33  <gmaxwell> my expectation is that we should warn if half the hashpower is doing something we don't know about.
 76 2015-10-25T07:17:23  <CodeShark> that would be easiest - just count how many blocks have unrecognized nVersion (versionbits or no) within an interval
 77 2015-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
 78 2015-10-25T07:18:13  <sipa> but within which interval?
 79 2015-10-25T07:18:15  *** danielsocials has joined #bitcoin-core-dev
 80 2015-10-25T07:18:32  <CodeShark> well, for ISM we were using a window of 1000, right?
 81 2015-10-25T07:18:51  <sipa> if the versions _are_ versionbits compatible, you can treat them as an unknown versionbits, and warn if it trigger
 82 2015-10-25T07:18:51  <CodeShark> and for the current warning system we use a window of 100
 83 2015-10-25T07:19:05  <sipa> which remains the case potentially after the window expires
 84 2015-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
 85 2015-10-25T07:21:15  <CodeShark> I'm concerned about reading too much into the deployment mechanism...especially if we're presumably running obsolete software
 86 2015-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
 87 2015-10-25T07:23:18  *** danielsocials has quit IRC
 88 2015-10-25T07:25:23  <CodeShark> easiest would be to replace if (pindex->nVersion > CBlock::CURRENT_VERSION) ++nUpgraded; with if (CheckVersion(pindex->nVersion) != VALID) ++nUpgraded;
 89 2015-10-25T07:26:02  <CodeShark> or CheckVersion(pindex, blockRuleIndex, consensusParams) rather
 90 2015-10-25T07:26:34  <CodeShark> in
 91 2015-10-25T07:26:37  <CodeShark> UpdateTip
 92 2015-10-25T07:27:12  <CodeShark> where CheckVersion handles all the logic for determining what constitutes a recognized and valid version
 93 2015-10-25T07:27:54  <CodeShark> and use a sticky flag...once it's triggered it remains set
 94 2015-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
 95 2015-10-25T07:36:34  *** ParadoxSpiral has joined #bitcoin-core-dev
 96 2015-10-25T07:40:59  *** ParadoxSpiral_ has joined #bitcoin-core-dev
 97 2015-10-25T07:43:50  *** ParadoxSpiral has quit IRC
 98 2015-10-25T07:46:18  *** wangchun has quit IRC
 99 2015-10-25T07:46:50  *** wangchun has joined #bitcoin-core-dev
100 2015-10-25T07:51:05  *** wangchun has quit IRC
101 2015-10-25T07:52:24  *** wangchun has joined #bitcoin-core-dev
102 2015-10-25T07:55:33  *** danielsocials has joined #bitcoin-core-dev
103 2015-10-25T08:34:02  *** Ylbam has joined #bitcoin-core-dev
104 2015-10-25T08:42:36  *** rcutmore_ has joined #bitcoin-core-dev
105 2015-10-25T08:43:47  *** rcutmore has quit IRC
106 2015-10-25T08:49:50  *** randy-waterhouse has joined #bitcoin-core-dev
107 2015-10-25T09:34:25  *** go111111111 has quit IRC
108 2015-10-25T09:47:54  *** go111111111 has joined #bitcoin-core-dev
109 2015-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
110 2015-10-25T09:57:47  *** paveljanik has joined #bitcoin-core-dev
111 2015-10-25T10:09:51  *** pigeons has quit IRC
112 2015-10-25T10:21:13  *** pigeons has joined #bitcoin-core-dev
113 2015-10-25T10:21:37  *** pigeons is now known as Guest25608
114 2015-10-25T10:38:55  *** danielsocials has quit IRC
115 2015-10-25T11:11:18  *** danielsocials has joined #bitcoin-core-dev
116 2015-10-25T11:15:15  *** danielsocials has quit IRC
117 2015-10-25T11:16:37  *** danielsocials has joined #bitcoin-core-dev
118 2015-10-25T11:17:58  *** danielsocials has quit IRC
119 2015-10-25T11:49:59  *** CodeShark has quit IRC
120 2015-10-25T12:30:35  *** CodeShark has joined #bitcoin-core-dev
121 2015-10-25T12:32:07  <CodeShark> wumpus: should I open an issue for PR #6888?
122 2015-10-25T13:13:25  <wumpus> don't think that's necessary
123 2015-10-25T13:54:20  *** Ylbam has quit IRC
124 2015-10-25T14:03:01  *** Thireus1 has joined #bitcoin-core-dev
125 2015-10-25T14:05:16  *** Thireus has quit IRC
126 2015-10-25T14:13:26  *** kanzure has quit IRC
127 2015-10-25T14:13:55  *** Thireus has joined #bitcoin-core-dev
128 2015-10-25T14:14:30  *** kanzure has joined #bitcoin-core-dev
129 2015-10-25T14:15:03  *** Thireus1 has quit IRC
130 2015-10-25T14:18:38  *** Thireus1 has joined #bitcoin-core-dev
131 2015-10-25T14:18:38  *** Thireus has quit IRC
132 2015-10-25T14:21:13  *** Thireus has joined #bitcoin-core-dev
133 2015-10-25T14:24:19  *** Thireus1 has quit IRC
134 2015-10-25T15:35:08  *** rcutmore_ has quit IRC
135 2015-10-25T16:09:56  *** d_t has joined #bitcoin-core-dev
136 2015-10-25T16:18:03  *** Ylbam has joined #bitcoin-core-dev
137 2015-10-25T16:35:30  *** dgenr8 has quit IRC
138 2015-10-25T16:36:41  *** davec has joined #bitcoin-core-dev
139 2015-10-25T17:04:38  *** d_t has quit IRC
140 2015-10-25T17:07:28  *** belcher has joined #bitcoin-core-dev
141 2015-10-25T17:44:16  *** CodeShark_ has joined #bitcoin-core-dev
142 2015-10-25T17:56:26  *** maaku__ has quit IRC
143 2015-10-25T17:57:19  *** CodeShark_ has quit IRC
144 2015-10-25T17:57:22  *** belcher has quit IRC
145 2015-10-25T17:57:36  *** belcher has joined #bitcoin-core-dev
146 2015-10-25T17:58:50  *** challisto has joined #bitcoin-core-dev
147 2015-10-25T17:58:50  *** challisto has joined #bitcoin-core-dev
148 2015-10-25T20:06:54  *** dgenr8 has joined #bitcoin-core-dev
149 2015-10-25T20:15:51  *** JoeLiu has joined #bitcoin-core-dev
150 2015-10-25T20:52:12  *** randy-waterhouse has quit IRC
151 2015-10-25T21:05:06  *** molly has joined #bitcoin-core-dev
152 2015-10-25T21:08:15  *** moli has quit IRC
153 2015-10-25T21:15:21  *** ParadoxSpiral_ has quit IRC
154 2015-10-25T21:17:09  *** CodeShark_ has joined #bitcoin-core-dev
155 2015-10-25T21:59:37  *** d_t has joined #bitcoin-core-dev
156 2015-10-25T22:25:48  *** JoeLiu has quit IRC
157 2015-10-25T22:32:55  *** dgenr8 has quit IRC
158 2015-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".
159 2015-10-25T22:34:51  <gmaxwell> Just becausewe got a connection _from_ something does not make it addrman tried.
160 2015-10-25T22:38:38  *** go111111111 has quit IRC
161 2015-10-25T22:44:02  *** d_t has quit IRC
162 2015-10-25T23:15:17  *** dgenr8 has joined #bitcoin-core-dev
163 2015-10-25T23:27:17  *** d_t has joined #bitcoin-core-dev
164 2015-10-25T23:27:56  *** d_t has joined #bitcoin-core-dev