1 2016-06-23T00:00:35  *** isis has quit IRC
  2 2016-06-23T00:03:02  *** isis has joined #bitcoin-core-dev
  3 2016-06-23T00:25:52  *** raedah has quit IRC
  4 2016-06-23T00:26:58  *** raedah has joined #bitcoin-core-dev
  5 2016-06-23T00:35:04  *** Chris_Stewart_5 has quit IRC
  6 2016-06-23T00:42:38  *** xiangfu has quit IRC
  7 2016-06-23T00:48:43  *** belcher has quit IRC
  8 2016-06-23T00:54:16  *** Lauda has quit IRC
  9 2016-06-23T00:54:31  *** Lauda has joined #bitcoin-core-dev
 10 2016-06-23T00:55:00  *** Taek has quit IRC
 11 2016-06-23T00:55:01  *** nsh has quit IRC
 12 2016-06-23T00:55:44  *** Ylbam has quit IRC
 13 2016-06-23T00:57:28  *** Taek has joined #bitcoin-core-dev
 14 2016-06-23T01:10:14  *** nsh has joined #bitcoin-core-dev
 15 2016-06-23T01:10:44  *** justanotheruser has quit IRC
 16 2016-06-23T01:17:32  *** fengling has joined #bitcoin-core-dev
 17 2016-06-23T01:19:31  *** justanotheruser has joined #bitcoin-core-dev
 18 2016-06-23T01:27:54  *** zooko has quit IRC
 19 2016-06-23T02:05:09  *** ClockCat has quit IRC
 20 2016-06-23T02:10:54  *** rallat has joined #bitcoin-core-dev
 21 2016-06-23T02:11:46  *** rallat has quit IRC
 22 2016-06-23T02:35:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 23 2016-06-23T02:43:40  *** hsmiths has quit IRC
 24 2016-06-23T02:45:45  <GitHub58> [bitcoin] dcousens opened pull request #8244: remove unnecessary LOCK(cs_main) (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8244
 25 2016-06-23T02:46:24  *** dcousens has joined #bitcoin-core-dev
 26 2016-06-23T02:46:36  <dcousens> uh, I probably meant to ask about https://github.com/bitcoin/bitcoin/pull/8244 here, not #bitcoin-dev
 27 2016-06-23T02:49:31  *** hsmiths has joined #bitcoin-core-dev
 28 2016-06-23T02:55:06  *** afk11 has quit IRC
 29 2016-06-23T02:56:04  *** Chris_Stewart_5 has quit IRC
 30 2016-06-23T03:02:07  *** raedah has quit IRC
 31 2016-06-23T03:03:30  *** raedah has joined #bitcoin-core-dev
 32 2016-06-23T03:28:40  *** TomMc has quit IRC
 33 2016-06-23T03:32:15  *** TomMc has joined #bitcoin-core-dev
 34 2016-06-23T03:40:30  *** TomMc has quit IRC
 35 2016-06-23T03:42:08  *** raedah has quit IRC
 36 2016-06-23T03:42:53  *** raedah has joined #bitcoin-core-dev
 37 2016-06-23T03:53:41  *** TomMc has joined #bitcoin-core-dev
 38 2016-06-23T04:14:33  *** TomMc has quit IRC
 39 2016-06-23T04:19:46  *** ClockCat has joined #bitcoin-core-dev
 40 2016-06-23T04:27:43  *** dcousens has quit IRC
 41 2016-06-23T04:28:01  *** dcousens has joined #bitcoin-core-dev
 42 2016-06-23T04:48:20  *** dcousens has quit IRC
 43 2016-06-23T04:54:18  *** zooko has joined #bitcoin-core-dev
 44 2016-06-23T05:00:06  *** fengling has quit IRC
 45 2016-06-23T05:01:09  *** kitty_ has joined #bitcoin-core-dev
 46 2016-06-23T05:01:20  <kitty_> Hi I need help please
 47 2016-06-23T05:01:35  <kitty_> Does anyone here know how to contact the bitcoin core wallet support team
 48 2016-06-23T05:03:40  <kitty_> Is there a support team for bitcoin core wallet
 49 2016-06-23T05:17:52  <kitty_> is anyone here
 50 2016-06-23T05:29:37  *** btcdrak has quit IRC
 51 2016-06-23T05:33:02  *** fengling has joined #bitcoin-core-dev
 52 2016-06-23T05:35:53  *** Ylbam has joined #bitcoin-core-dev
 53 2016-06-23T05:36:53  *** CubicEarth has joined #bitcoin-core-dev
 54 2016-06-23T05:43:13  <kitty_> is there anyone here that helps with bitcoin core wallet
 55 2016-06-23T05:48:04  *** zooko has quit IRC
 56 2016-06-23T05:49:02  <jl2012> Just ask your question, or try #bitcoin
 57 2016-06-23T05:50:31  <kitty_> what do you mean #bitcoin
 58 2016-06-23T05:50:39  <kitty_> #bitcoin
 59 2016-06-23T06:23:22  *** raedah has quit IRC
 60 2016-06-23T06:24:17  *** raedah has joined #bitcoin-core-dev
 61 2016-06-23T06:27:14  *** btcdrak has joined #bitcoin-core-dev
 62 2016-06-23T06:35:07  *** CubicEarth has quit IRC
 63 2016-06-23T06:35:31  *** CubicEarth has joined #bitcoin-core-dev
 64 2016-06-23T06:41:46  *** CubicEarth has quit IRC
 65 2016-06-23T06:42:02  *** CubicEarth has joined #bitcoin-core-dev
 66 2016-06-23T06:53:05  *** kitty_ has quit IRC
 67 2016-06-23T06:55:06  *** [b__b] has quit IRC
 68 2016-06-23T06:55:33  *** [b__b] has joined #bitcoin-core-dev
 69 2016-06-23T07:06:48  *** coredump___ has joined #bitcoin-core-dev
 70 2016-06-23T07:10:09  *** coredump___ has quit IRC
 71 2016-06-23T07:11:39  *** Giszmo has quit IRC
 72 2016-06-23T07:33:36  *** shangzhou has joined #bitcoin-core-dev
 73 2016-06-23T07:35:18  <shangzhou>  means try another channel called #bitcoin this is #bitcoin-core-dev
 74 2016-06-23T07:39:27  *** PaulCape_ has joined #bitcoin-core-dev
 75 2016-06-23T07:42:37  *** PaulCapestany has quit IRC
 76 2016-06-23T08:07:50  *** CubicEarth has quit IRC
 77 2016-06-23T08:32:57  *** Guyver2 has joined #bitcoin-core-dev
 78 2016-06-23T08:33:28  *** MarcoFalke has joined #bitcoin-core-dev
 79 2016-06-23T08:37:37  *** Ginnarr has joined #bitcoin-core-dev
 80 2016-06-23T09:08:17  *** CubicEarth has joined #bitcoin-core-dev
 81 2016-06-23T09:14:32  *** Guyver2 has quit IRC
 82 2016-06-23T09:15:02  *** CubicEarth has quit IRC
 83 2016-06-23T09:18:41  *** assder has joined #bitcoin-core-dev
 84 2016-06-23T09:30:26  *** assder has quit IRC
 85 2016-06-23T09:37:25  *** pedrobranco has joined #bitcoin-core-dev
 86 2016-06-23T09:38:49  *** shangzhou has quit IRC
 87 2016-06-23T10:11:09  *** Guyver2 has joined #bitcoin-core-dev
 88 2016-06-23T10:44:18  *** jtimon has joined #bitcoin-core-dev
 89 2016-06-23T10:50:56  <GitHub7> [bitcoin] laanwj opened pull request #8246: trivial: capitalize BIP32 in option help (master...2016_06_bip32_uppercase) https://github.com/bitcoin/bitcoin/pull/8246
 90 2016-06-23T11:02:38  <GitHub70> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9f1807af2422...147a7b6726d3
 91 2016-06-23T11:02:39  <GitHub70> bitcoin/master a1c92c2 Wladimir J. van der Laan: trivial: capitalize BIP32 in option help...
 92 2016-06-23T11:02:39  <GitHub70> bitcoin/master 147a7b6 Wladimir J. van der Laan: Merge #8246: trivial: capitalize BIP32 in option help...
 93 2016-06-23T11:02:48  <GitHub103> [bitcoin] laanwj closed pull request #8246: trivial: capitalize BIP32 in option help (master...2016_06_bip32_uppercase) https://github.com/bitcoin/bitcoin/pull/8246
 94 2016-06-23T11:05:01  <GitHub5> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/147a7b6726d3...08338942b50f
 95 2016-06-23T11:05:02  <GitHub5> bitcoin/master d80efec Peter Todd: Update petertodd's testnet seed...
 96 2016-06-23T11:05:02  <GitHub5> bitcoin/master 0833894 Wladimir J. van der Laan: Merge #8204: Update petertodd's testnet seed...
 97 2016-06-23T11:05:11  <GitHub150> [bitcoin] laanwj closed pull request #8204: Update petertodd's testnet seed (master...2016-06-15-update-tbtc-seed) https://github.com/bitcoin/bitcoin/pull/8204
 98 2016-06-23T11:12:06  *** CubicEarth has joined #bitcoin-core-dev
 99 2016-06-23T11:15:21  *** robs has quit IRC
100 2016-06-23T11:17:03  *** CubicEarth has quit IRC
101 2016-06-23T11:20:04  *** Ginnarr has quit IRC
102 2016-06-23T11:28:47  *** cryptapus_ has joined #bitcoin-core-dev
103 2016-06-23T11:32:36  *** cryptapus_ is now known as cryptapus
104 2016-06-23T11:46:06  *** fengling has quit IRC
105 2016-06-23T12:08:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
106 2016-06-23T12:12:45  *** CubicEarth has joined #bitcoin-core-dev
107 2016-06-23T12:17:11  *** CubicEarth has quit IRC
108 2016-06-23T12:18:43  *** Chris_Stewart_5 has quit IRC
109 2016-06-23T12:35:38  *** pedrobranco has quit IRC
110 2016-06-23T12:43:09  *** fengling has joined #bitcoin-core-dev
111 2016-06-23T12:47:26  *** fengling has quit IRC
112 2016-06-23T13:09:14  *** Chris_Stewart_5 has joined #bitcoin-core-dev
113 2016-06-23T13:13:32  *** CubicEarth has joined #bitcoin-core-dev
114 2016-06-23T13:18:28  *** CubicEarth has quit IRC
115 2016-06-23T13:20:48  *** pedrobranco has joined #bitcoin-core-dev
116 2016-06-23T13:41:36  *** cjcj has joined #bitcoin-core-dev
117 2016-06-23T13:43:52  *** fengling has joined #bitcoin-core-dev
118 2016-06-23T13:45:09  *** xiangfu has joined #bitcoin-core-dev
119 2016-06-23T13:45:16  <GitHub21> [bitcoin] sipa opened pull request #8247: Mark my dnsseed as supporting filtering (master...newseed) https://github.com/bitcoin/bitcoin/pull/8247
120 2016-06-23T13:48:06  *** fengling has quit IRC
121 2016-06-23T13:56:28  *** Chris_Stewart_5 has quit IRC
122 2016-06-23T14:12:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
123 2016-06-23T14:14:14  *** CubicEarth has joined #bitcoin-core-dev
124 2016-06-23T14:18:50  *** CubicEarth has quit IRC
125 2016-06-23T14:21:46  *** TomMc has joined #bitcoin-core-dev
126 2016-06-23T14:23:15  *** raedah has quit IRC
127 2016-06-23T14:24:08  *** raedah has joined #bitcoin-core-dev
128 2016-06-23T14:26:26  *** Giszmo has joined #bitcoin-core-dev
129 2016-06-23T14:31:22  *** TomMc has quit IRC
130 2016-06-23T14:44:37  *** fengling has joined #bitcoin-core-dev
131 2016-06-23T14:46:09  *** Greybits has joined #bitcoin-core-dev
132 2016-06-23T14:48:46  *** fengling has quit IRC
133 2016-06-23T14:50:22  *** MCCCS has joined #bitcoin-core-dev
134 2016-06-23T14:50:48  *** MCCCS has quit IRC
135 2016-06-23T14:57:52  <GitHub49> [bitcoin] laanwj opened pull request #8249: Enable (and check for) 64-bit ASLR on Windows (master...2016_06_windows64_security) https://github.com/bitcoin/bitcoin/pull/8249
136 2016-06-23T15:15:00  *** CubicEarth has joined #bitcoin-core-dev
137 2016-06-23T15:19:33  *** CubicEarth has quit IRC
138 2016-06-23T15:29:55  *** xiangfu has quit IRC
139 2016-06-23T15:36:34  *** xiangfu has joined #bitcoin-core-dev
140 2016-06-23T15:45:23  *** fengling has joined #bitcoin-core-dev
141 2016-06-23T15:49:26  *** fengling has quit IRC
142 2016-06-23T15:53:34  *** xiangfu has quit IRC
143 2016-06-23T16:06:50  *** laurentmt has joined #bitcoin-core-dev
144 2016-06-23T16:08:19  *** laurentmt has quit IRC
145 2016-06-23T16:15:42  *** CubicEarth has joined #bitcoin-core-dev
146 2016-06-23T16:20:17  *** CubicEarth has quit IRC
147 2016-06-23T16:36:38  *** kadoban has joined #bitcoin-core-dev
148 2016-06-23T16:50:05  *** pedrobranco has quit IRC
149 2016-06-23T16:50:23  *** pedrobranco has joined #bitcoin-core-dev
150 2016-06-23T17:00:32  *** Chris_Stewart_5 has quit IRC
151 2016-06-23T17:03:50  *** pedrobranco has quit IRC
152 2016-06-23T17:04:18  *** pedrobranco has joined #bitcoin-core-dev
153 2016-06-23T17:07:43  *** Greybits has quit IRC
154 2016-06-23T17:16:30  *** CubicEarth has joined #bitcoin-core-dev
155 2016-06-23T17:21:13  *** CubicEarth has quit IRC
156 2016-06-23T17:26:36  *** CubicEarth has joined #bitcoin-core-dev
157 2016-06-23T17:43:21  *** MarcoFalke has left #bitcoin-core-dev
158 2016-06-23T17:46:51  *** fengling has joined #bitcoin-core-dev
159 2016-06-23T17:48:15  *** jtimon has quit IRC
160 2016-06-23T17:51:06  *** fengling has quit IRC
161 2016-06-23T18:04:15  *** jtimon has joined #bitcoin-core-dev
162 2016-06-23T18:07:58  *** spudowiar1 has joined #bitcoin-core-dev
163 2016-06-23T18:10:01  *** spudowiar1 has quit IRC
164 2016-06-23T18:21:40  *** pedrobranco has quit IRC
165 2016-06-23T18:21:53  *** pedrobranco has joined #bitcoin-core-dev
166 2016-06-23T18:26:42  *** pedrobranco has quit IRC
167 2016-06-23T18:26:49  *** kadoban has quit IRC
168 2016-06-23T18:37:12  *** jl2012 has quit IRC
169 2016-06-23T18:37:34  *** jl2012 has joined #bitcoin-core-dev
170 2016-06-23T18:40:19  *** pedrobranco has joined #bitcoin-core-dev
171 2016-06-23T18:44:49  *** pedrobranco has quit IRC
172 2016-06-23T18:46:00  *** jcorgan has joined #bitcoin-core-dev
173 2016-06-23T19:00:37  <wumpus> meeting time?
174 2016-06-23T19:00:42  *** CubicEarth has quit IRC
175 2016-06-23T19:01:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
176 2016-06-23T19:02:26  <sipa> present
177 2016-06-23T19:02:31  <gmaxwell> past?
178 2016-06-23T19:02:40  <wumpus> #startmeeting
179 2016-06-23T19:02:40  <lightningbot> Meeting started Thu Jun 23 19:02:40 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
180 2016-06-23T19:02:40  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
181 2016-06-23T19:03:05  <wumpus> any proposed topics?
182 2016-06-23T19:04:01  <wumpus> I think https://github.com/bitcoin/bitcoin/issues/8245 needs discussion, whether reindex/verification slowed down
183 2016-06-23T19:04:04  <gmaxwell> sdaftuar: sipa: phantomcircuit: jonasschnelli: MarcoFalke: jtimon: phantomcircuit: instagibbs: petertodd: morcos:
184 2016-06-23T19:04:08  <sipa> ack topic
185 2016-06-23T19:04:11  <gmaxwell> ack.
186 2016-06-23T19:04:41  <jtimon> I missed a couple of meetings and I have some questions about merging segwit and 0.13 feature freeze, but maybe that can wait for after the meeting
187 2016-06-23T19:04:46  <wumpus> #topic perceived validation slowdowns
188 2016-06-23T19:04:58  <sipa> i noticed very slow chainstate writes (close to a minute, even though the chainstate is only 53 MB)
189 2016-06-23T19:05:03  <gmaxwell> I was just going to go try reindexes with 0.12.1 and master on two hosts, to see if its a regression.  Even if it is not, it's absurdly slow (and I assume for sync too, but that should be validated) and maybe we should consider cranking dbcache and making a release note for loe memory hosts.
190 2016-06-23T19:05:13  <sipa> though this may be due to my laptop's disk setup (zfs on encrypted lvm volume)
191 2016-06-23T19:05:27  <wumpus> so, some people are noticiing slow validation, I wonder what changed there
192 2016-06-23T19:05:29  <gmaxwell> (two identical hosts)
193 2016-06-23T19:05:49  <sipa> from gmaxwell's numbers, it does not look like his time is dominated by database flushes, however
194 2016-06-23T19:05:57  <gmaxwell> I think I am often guilty of only testing things with a non-default dbcache.
195 2016-06-23T19:06:03  <sipa> likewise
196 2016-06-23T19:06:12  <gmaxwell> I previously _expected_ reindex to be slow due to the signature checking.
197 2016-06-23T19:06:19  <wumpus> I usually run with default dbcache
198 2016-06-23T19:06:30  <jtimon> maybe a solution would be to change the default dbcache for something more common among testers?
199 2016-06-23T19:06:46  <gmaxwell> my laptop runs with default dbcache and I have been noticing verification is slow for a while, but I have not reindexed for quite a long time.
200 2016-06-23T19:06:48  <sipa> jtimon: we still need to figure out what is behind this... but independently, yes
201 2016-06-23T19:06:50  <wumpus> yes, we should definitely crank up the dbcache no matter what
202 2016-06-23T19:06:53  <wumpus> but I like to know what happened
203 2016-06-23T19:07:08  <jtimon> sipa: yeah, of course, I meant independently
204 2016-06-23T19:07:24  *** CubicEarth has joined #bitcoin-core-dev
205 2016-06-23T19:07:30  <wumpus> should at least try to bisec tthis, I know it's frustrating as everything takes so long :)
206 2016-06-23T19:08:07  <sipa> oh, this is with txindex enabled
207 2016-06-23T19:08:14  <gmaxwell> Well I will test against 0.12.1 and see if there is a regression.  oh crap. testing against 0.12.1 will be messed up by signature checking, I guess I will test against patched 0.12.1 that skips signature checking before block 295000? does that sound okay?
208 2016-06-23T19:08:18  <wumpus> gmaxwell didn't you have some suspicions that CB would affect initial sync? could that also affect reindex?
209 2016-06-23T19:08:24  <wumpus> not in my case
210 2016-06-23T19:08:27  <sipa> wumpus: gmaxwell's test was before cb was merged
211 2016-06-23T19:08:57  <gmaxwell> my test is without cb merged, also the CB concern was just related to general sync logic, not processing.
212 2016-06-23T19:08:58  <jtimon> are there recent changes that people suspect may have caused the regression ?
213 2016-06-23T19:09:07  <wumpus> wouldbe good to test against #7917, as many people benchmarked that
214 2016-06-23T19:09:18  <wumpus> and it was perceived fast at the time
215 2016-06-23T19:09:40  <wumpus> jtimon: not really
216 2016-06-23T19:09:42  <gmaxwell> I can refine further if it looks like a regression.  I think it's likely when I tested 7917 it was with a high dbcache and the result was that things got much faster.
217 2016-06-23T19:10:13  <gmaxwell> At least the logs I'm seeing suggest that the slow performace is leveldb performance being slow, so it would be completely hidden by a sufficiently large dbcache.
218 2016-06-23T19:10:30  <gmaxwell> (maybe not leveldb itself being slow, e.g. making extranious accesses to it)
219 2016-06-23T19:10:47  <wumpus> it may be the windows machine I'm testing on is just crappy, I also had a strange issue with ldb files: https://github.com/bitcoin/bitcoin/issues/8250 .. possible that the disk is just very slow due to other processes interfering
220 2016-06-23T19:10:56  <sipa> gmaxwell: note that txindex may actually influence this; the txindex entries are written continuously to the db, and not cached inside the application or batched together with the rist
221 2016-06-23T19:11:03  <gmaxwell> So actions are. determine if regression, if so where, ... seperately, consider a dbcache increase for the next release.
222 2016-06-23T19:11:08  <wumpus> I doubt it is leveldb itself as there haven't been changed to that for ages
223 2016-06-23T19:11:13  *** molz has joined #bitcoin-core-dev
224 2016-06-23T19:11:17  <gmaxwell> sipa: yes this might be txindex related. I can test that too.
225 2016-06-23T19:11:23  <wumpus> yes, txindex is *slow*
226 2016-06-23T19:11:24  <CodeShark> is something slowing down validation that wasn't before?
227 2016-06-23T19:11:29  <sipa> CodeShark: maybe
228 2016-06-23T19:11:32  <wumpus> lots of extra I/O. I also made that mistake once
229 2016-06-23T19:11:40  <gmaxwell> wumpus: we have changed (reduced) the amount of interaction with leveldb during validation.
230 2016-06-23T19:11:51  <wumpus> gmaxwell: sure, it may be the level above leveldb
231 2016-06-23T19:12:00  <sipa> yes, it may be
232 2016-06-23T19:12:06  <wumpus> I just don't suspect the databse itself this time
233 2016-06-23T19:12:34  <gmaxwell> but yes, the only path I see to leveldb itself would just be that it now has more data in it than ever before, and perhaps it crossed some performance cliff. but otherwise, nah.
234 2016-06-23T19:12:36  <wumpus> unless some compiler flag changed things shockingly, say, the c++11 switch, but I doubt it
235 2016-06-23T19:12:53  <gmaxwell> I think txindex is a good lead, my laptop is the only host I regularly use with it, and I've been noticing poor validation performance for a while.
236 2016-06-23T19:13:07  <sipa> i briefly suspected the IsInitialBlockDownload change, but apart from using an atomic, its semantics should be unchanged
237 2016-06-23T19:13:19  <wumpus> especialy if you see the slowdown in the flush; txindex writes a lot of data to the block index databse
238 2016-06-23T19:13:42  <sipa> wumpus: but the txindex writes don't happen during the flush
239 2016-06-23T19:13:45  <wumpus> so maybe false alarm, the sync is slow, news at 11
240 2016-06-23T19:13:59  <sipa> wumpus: though they may accumulate somewhere in leveldb until a flush is issued
241 2016-06-23T19:14:01  <CodeShark> can't we add tracers around calls to narrow it down?
242 2016-06-23T19:14:08  <gmaxwell> wumpus: well, the "lets increase the dbcache" is still a useful response to this catching attention again.
243 2016-06-23T19:14:11  *** moli has quit IRC
244 2016-06-23T19:14:31  <sipa> action points: benchmark in same conditions without txindex, and with larger dbcache?
245 2016-06-23T19:14:55  <wumpus> yes we should increate the dbcache, and probably change how it is allocated
246 2016-06-23T19:15:09  <wumpus> (e.g. a relatively large part now goes to leveldb caches, that's a waste
247 2016-06-23T19:15:16  <gmaxwell> (as my laptop is about to be on day three of reindex)
248 2016-06-23T19:15:51  <sipa> wumpus: the reasoning was that leveldb cache is serialized, so it has a much large impact per byte than the internal cache
249 2016-06-23T19:15:55  <wumpus> leveldb's own caches are completely ineffective compared to bitcoind's application level cache
250 2016-06-23T19:15:59  <sipa> but it has the deserialization overhead
251 2016-06-23T19:16:04  *** instagibbs2 has joined #bitcoin-core-dev
252 2016-06-23T19:16:17  <sipa> but that's mostly a guess without substansive benchmarking
253 2016-06-23T19:16:18  <wumpus> sipa: that makes a lot of sense in theory, but leveldb just sucks at caching :)
254 2016-06-23T19:16:43  <gmaxwell> I can benchmark a bunch of mixes of cache sizes and see how they pan out.
255 2016-06-23T19:16:53  <sipa> wumpus: it may also be due to our access pattern... the things that get written to leveldb haven't been touched for a while; maybe they won't be touched any time soon as a result either
256 2016-06-23T19:17:04  <wumpus> the current values are probably ok, I just mean: if we scale dbcache we probably don't want to scale those caches with it
257 2016-06-23T19:17:10  <jtimon> not sure I'm following but maybe we want separate options for the "internal" and "external" caches?
258 2016-06-23T19:17:27  <wumpus> jtimon: for testing that'd be awesome
259 2016-06-23T19:17:42  <sipa> jtimon: for testing that makes sense, but as a product it should work well with the fewest number of tunable possible
260 2016-06-23T19:17:46  <gmaxwell> In principle we shouldn't add knobs as a punt for highly technical settings that even we haven't figured out, the users will do no better at it. :P  (as hidden options for testing or whatnot, sure)
261 2016-06-23T19:17:58  <sipa> jynx
262 2016-06-23T19:17:59  <instagibbs2> On phone but present
263 2016-06-23T19:18:21  <jtimon> there's some options that can only be accessed if --debug, right?
264 2016-06-23T19:18:25  <wumpus> gmaxwell: you'd be surprised :-)
265 2016-06-23T19:18:35  <wumpus> some users are very persistent in trying to find settings that are fastest for them
266 2016-06-23T19:18:48  <CodeShark> I'd venture to say it's probably not the majority
267 2016-06-23T19:18:51  <wumpus> but yes, it should be a hidden option (--help-debug)
268 2016-06-23T19:18:52  <jtimon> oh, no they may not be showed in the help but they're still accesible I think
269 2016-06-23T19:19:00  <wumpus> CodeShark: sure, but don't underestimate peole
270 2016-06-23T19:19:08  <sipa> wumpus: maybe such options should be marked with ("If you find a setting for this value that improves performance, please let us know")
271 2016-06-23T19:19:15  <wumpus> sipa: +1 :D
272 2016-06-23T19:19:18  <gmaxwell> -funroll-loops -O20
273 2016-06-23T19:19:34  <sipa> -femit-broken-code
274 2016-06-23T19:20:05  <wumpus> -fskip-computing-even-bits
275 2016-06-23T19:20:13  <wumpus> ok, any other topics?
276 2016-06-23T19:20:15  <sipa> relatedly, i think -qt can by default use more ram
277 2016-06-23T19:20:37  <sipa> also, 100 mb is kinda ridiculous with the mempool already being 300 mb
278 2016-06-23T19:20:42  <wumpus> yes, probably, although qt itself also uses more ram
279 2016-06-23T19:21:02  <wumpus> yes, agreed
280 2016-06-23T19:21:11  <sipa> other topic: merge segwit yay or nay
281 2016-06-23T19:21:16  <wumpus> let's reduce the mempool to 100mb and increase dbcache to 300mb
282 2016-06-23T19:21:17  <gmaxwell> okay, I have my action items on this. I will benchmark a bunch of configurations. 0.12.1 vs master;  and master  w/wo txindex, w/wo default dbcache.... and also try different cache splits. I may ask for suggestions on the interesting parameter space when I go to do that. If there is a 0.12.1 vs master regression I'll find out where.
283 2016-06-23T19:21:38  <petertodd> sipa: re: segwit, has it been rebased?
284 2016-06-23T19:21:42  *** laurentmt has joined #bitcoin-core-dev
285 2016-06-23T19:21:45  <wumpus> #topic segwit
286 2016-06-23T19:21:46  <sipa> petertodd: 12 times by now
287 2016-06-23T19:21:50  <CodeShark> lol
288 2016-06-23T19:21:53  <sipa> see 8149
289 2016-06-23T19:21:55  <CodeShark> poor sipa
290 2016-06-23T19:21:55  <jtimon> how can we feature freeze without merging segwit?
291 2016-06-23T19:22:02  *** laurentmt has quit IRC
292 2016-06-23T19:22:03  <wumpus> sipa is getting carpal tunnel syndrome from rebasing
293 2016-06-23T19:22:05  <gmaxwell> We can do some checking to see what mempool size should be based on current traffic, in principle I'd agree shifting memory from one to the other.
294 2016-06-23T19:22:16  <wumpus> jtimon: softforks / consensus changes don't count as software features
295 2016-06-23T19:22:28  <wumpus> jtimon: that's also why they're allowed to be introduced in minor versions
296 2016-06-23T19:22:29  <petertodd> sipa: I mean, is the current pull-req rebased since compact blocks got merged?
297 2016-06-23T19:22:32  <gmaxwell> also it's not even activated in any case. it's pure code updates.
298 2016-06-23T19:22:35  <sipa> petertodd: yes
299 2016-06-23T19:22:49  <jtimon> wumpus: so it won't be possible to include any feature post segwit merge in 0.13 ?
300 2016-06-23T19:22:52  <CodeShark> current is #8149, yes?
301 2016-06-23T19:23:00  <sipa> petertodd: and i've been running the rebase on both testnet (where it syncs segwit blocks) and on mainnet (where it uses compact blocks)
302 2016-06-23T19:23:05  <wumpus> jtimon: right, 0.13 is closed feature-wise
303 2016-06-23T19:23:25  *** CubicEarth has quit IRC
304 2016-06-23T19:23:52  <gmaxwell> I haven't done CB+segwit testing yet, but I'm due to bring up a new testnet node, so I can do that.
305 2016-06-23T19:23:55  <wumpus> features will be merged again on master after a 0.13 branch is created, which will be around the rc1 release (planned july 6 I think)
306 2016-06-23T19:24:02  <jtimon> wumpus: that is a no, that is unconvenient and I wasn't expecting it, but thanks
307 2016-06-23T19:24:18  *** instagibbs3 has joined #bitcoin-core-dev
308 2016-06-23T19:24:34  <wumpus> #link see the release schedule here: https://github.com/bitcoin/bitcoin/issues/8250
309 2016-06-23T19:24:56  <CodeShark> sipa: which PR should we be testing against?
310 2016-06-23T19:24:56  <jtimon> yeah, should have asked "what about segwit?" back then
311 2016-06-23T19:25:06  <sipa> CodeShark: 8149 and 7190 are the exact same code
312 2016-06-23T19:25:10  <sipa> so whatever you like
313 2016-06-23T19:25:44  <gmaxwell> I had completed review up to the CB rebase, which I have not looked at yet.
314 2016-06-23T19:26:03  <gmaxwell> (I mean I haven't looked at segwit's rebase for CB)
315 2016-06-23T19:26:24  <jtimon> I would have preferred that segwit would have been merged before feature freeze to have time to do something post-segwit for 0.13, but mainly I just wanted to undesrtand the situation
316 2016-06-23T19:26:45  <sipa> git show -w c4e3c755d7e41aaabe74c84af7e4bf00a62c96fb
317 2016-06-23T19:26:54  *** instagibbs2 has quit IRC
318 2016-06-23T19:26:54  <sipa> and then search for cmpctblk and blocktxn
319 2016-06-23T19:27:01  <sipa> to see the changes related to that
320 2016-06-23T19:27:05  <btcdrak> oh I'm late
321 2016-06-23T19:27:21  <wumpus> jtimon: we all would have preferred other timings, but we have to cope with how things actually are :)
322 2016-06-23T19:27:46  <jtimon> I planned to rebase/rewrite some of the consensus encapsulation code after segwit, I guess the plan doesn't change anyway
323 2016-06-23T19:28:02  <wumpus> well you can still do that, it just won't make 0.13
324 2016-06-23T19:28:37  <jtimon> wumpus: well, yeah, I could have helped more with reviewing and testing segwit
325 2016-06-23T19:28:41  <gmaxwell> sipa: thanks, will review once I start up the test panel for the prior topic. :)
326 2016-06-23T19:28:48  <jtimon> wumpus: understood
327 2016-06-23T19:29:07  <sipa> jtimon: you can still do that, even after merge :)
328 2016-06-23T19:29:22  <gmaxwell> yes, post merge review and testing is super important too.
329 2016-06-23T19:29:44  <wumpus> yes, absolutely
330 2016-06-23T19:29:52  *** Chris_Stewart_5 has quit IRC
331 2016-06-23T19:30:22  <gmaxwell> In any case I am in favor of the merge. (and don't expect my remaining review to turn up any reason not to)
332 2016-06-23T19:30:43  <sipa> i'm running the cb+segwit rebase on bitcoin.sipa.be since a few days, to see if there was an impact on memory usage - i see none
333 2016-06-23T19:30:48  <gmaxwell> Obviously there may still need to be some fixes and nits. But thats what we have time for.
334 2016-06-23T19:30:54  <sipa> (compared to running just cb before)
335 2016-06-23T19:30:56  <wumpus> anyone against merging segwit?
336 2016-06-23T19:31:03  <wumpus> (I mean right now, not in general)
337 2016-06-23T19:32:00  <wumpus> *crickets*
338 2016-06-23T19:32:11  <sipa> i have no objections :)
339 2016-06-23T19:32:14  <wumpus> that's clear then
340 2016-06-23T19:32:17  <btcdrak> I'd like to see it merged too
341 2016-06-23T19:32:19  <wumpus> yes, I understood
342 2016-06-23T19:32:27  <jtimon> sipa: yeah, it just won't make it to 0.13 as wumpus explained
343 2016-06-23T19:32:30  <CodeShark> the sooner the better (as long as it doesn't break current behavior)
344 2016-06-23T19:32:39  <wumpus> #action Merge segwit
345 2016-06-23T19:32:44  *** MarcoFalke has joined #bitcoin-core-dev
346 2016-06-23T19:32:45  <btcdrak> o/
347 2016-06-23T19:33:10  <gmaxwell> at this point it will amplify testing, since we've done a much of the specialized testing. Testing for incidental effects by a broader audience would be good.
348 2016-06-23T19:33:26  <instagibbs3> Good.
349 2016-06-23T19:34:00  <gmaxwell> Would it be awful to suggest that we put out 'testnet binaries' right away off master to also get more people testing with that code in use?
350 2016-06-23T19:34:19  <petertodd> gmaxwell: fine by me
351 2016-06-23T19:34:21  <sipa> i believe jonasschnelli builds nightly binaries
352 2016-06-23T19:34:22  <wumpus> sure, why not
353 2016-06-23T19:34:47  <wumpus> I prefer doing that outside the 'official' release cycle, but I don't mind running gitian for it
354 2016-06-23T19:34:51  <gmaxwell> I think that the prior segnet testing didn't include anyone that was likely to be confused by status changes in the UI or whatnot-- too technical an audience since you had to build it. :)
355 2016-06-23T19:35:15  <gmaxwell> yes, I don't want something part of the release cycle. Just binaries to give to power users to give it a spin.
356 2016-06-23T19:35:27  <wumpus> testnet-only
357 2016-06-23T19:35:51  <CodeShark> testnet as in not segnet, right?
358 2016-06-23T19:35:52  <gmaxwell> yea, pre-RC testnet only, we could one line patch to change the default network, so it'll be easier to use.
359 2016-06-23T19:36:07  <sipa> CodeShark: segnet has been removed a few weeks ago from the patch
360 2016-06-23T19:36:17  <gmaxwell> Testnet is segwit now. Segnet is dead long live segnet.
361 2016-06-23T19:36:21  <petertodd> gmaxwell: maybe better to just make it fail unless -testnet is enabled, in case someone does run it in production
362 2016-06-23T19:36:26  <wumpus> no, not segnet. Regtest could be allowed. But mainnet disabled and testnet as default
363 2016-06-23T19:36:32  <CodeShark> is segwit live on testnet?!?!
364 2016-06-23T19:36:36  <gmaxwell> yea. exactly.
365 2016-06-23T19:36:38  <sipa> CodeShark: yes, since months
366 2016-06-23T19:37:01  <wumpus> petertodd: what is the worst that could happen if you accidentally run testnet?
367 2016-06-23T19:37:14  <petertodd> wumpus: hard to know!
368 2016-06-23T19:37:39  <gmaxwell> it's just pre-RC master, lots of people do run that in production. I wouldn't worry too much, discretion of whomever makes the testnet-as-default patch?
369 2016-06-23T19:37:44  <petertodd> wumpus: having to add a -testnet flag isn't a big deal; and failing hard if you don't shouldn't have any consequences
370 2016-06-23T19:37:46  <wumpus> at least the default ports etc will be different, default data dir is different, etc
371 2016-06-23T19:37:55  *** CubicEarth has joined #bitcoin-core-dev
372 2016-06-23T19:38:13  <wumpus> petertodd: apart from GUI users I guess
373 2016-06-23T19:38:19  <gmaxwell> petertodd: I hope the user doesn't have to set any flags, if they have to set flags far fewer people will try it.
374 2016-06-23T19:38:25  <sipa> i believe this is a nit not worth minutes of discussion time
375 2016-06-23T19:38:25  <petertodd> wumpus: yes, but imagine someone has an automated system setup which calls bitcoin-cli...
376 2016-06-23T19:38:41  <gmaxwell> in any case, can be discussed later or not.
377 2016-06-23T19:38:42  <gmaxwell> :)
378 2016-06-23T19:38:46  <btcdrak> any more topics?
379 2016-06-23T19:39:41  *** Chris_Stewart_5 has joined #bitcoin-core-dev
380 2016-06-23T19:40:06  <jtimon> are we merging the bip9 activation parameters for testnet?
381 2016-06-23T19:40:27  <CodeShark> hmm - I don't see the activation parameters for segwit on testnet
382 2016-06-23T19:40:39  <CodeShark> how can it be live on testnet?
383 2016-06-23T19:40:54  <jtimon> CodeShark: people running custom code I assume
384 2016-06-23T19:40:57  <sipa> CodeShark: in the segwit branch
385 2016-06-23T19:41:02  <jtimon> oh
386 2016-06-23T19:41:03  <sipa> not in master
387 2016-06-23T19:41:20  <btcdrak> CodeShark: it was activated months ago
388 2016-06-23T19:41:44  <CodeShark> yes, but I'm still confused as to the release here
389 2016-06-23T19:41:59  <CodeShark> shouldn't testnet only run stuff that's been merged?
390 2016-06-23T19:42:11  <instagibbs3> bip 9 activation can still be set.
391 2016-06-23T19:42:13  <btcdrak> no, we set the parameters
392 2016-06-23T19:42:26  <gmaxwell> CodeShark: we wanted testing in a mixed enviroment with most nodes not upgraded.
393 2016-06-23T19:42:26  <btcdrak> and that allowed a miner to activate it
394 2016-06-23T19:42:29  <sipa> CodeShark: it was a very useful testing exercise
395 2016-06-23T19:42:32  <gmaxwell> CodeShark: since thats realistic.
396 2016-06-23T19:42:48  <gmaxwell> and segnet couldn't easily provide that.
397 2016-06-23T19:43:00  <CodeShark> sure, I'm all for the additional testing - I'm just concerned about breaking the master builds for testnet
398 2016-06-23T19:43:10  <gmaxwell> CodeShark: it's a softfork, hurrah.
399 2016-06-23T19:43:18  <sipa> (although, there are so few testnet segwit nodes running right now that it really does not work without -addnode)
400 2016-06-23T19:43:19  <jtimon> answer my own question: yes, the testnet activation is part of #7910 : https://github.com/bitcoin/bitcoin/pull/8149/files#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R191
401 2016-06-23T19:43:39  <CodeShark> gmaxwell: yes, but it will still break miners. however, if no issues arose as a result I'm fine with it
402 2016-06-23T19:43:58  <sipa> CodeShark: testnet miners are clearly already running it
403 2016-06-23T19:44:05  <CodeShark> yes, indeed
404 2016-06-23T19:44:09  <sipa> so how could merging break anything for them?
405 2016-06-23T19:44:19  <CodeShark> nvm, all's good
406 2016-06-23T19:44:24  <gmaxwell> CodeShark: no issues appear to have arisen.  (also testnet reorgs a lot in any case, so a little instability would have been an issue)
407 2016-06-23T19:44:37  <gmaxwell> er, wouldn't have been
408 2016-06-23T19:45:02  <jtimon> it is the first time a softfork is activated on testnet before it is in master thought, right?
409 2016-06-23T19:45:02  <gmaxwell> in any case, so that would be an action to go with the testnet only builds: get more testnet nodes running upgraded so that it works without addnode.
410 2016-06-23T19:45:14  <gmaxwell> Are the testnet seeds running the code that can give filtered responses?
411 2016-06-23T19:45:16  <sipa> indeed, and we can test the dns filtering
412 2016-06-23T19:45:23  <sipa> gmaxwell: jonasschnelli's is
413 2016-06-23T19:45:27  <sipa> not sure about petertodd's
414 2016-06-23T19:45:37  <sipa> oh, yes
415 2016-06-23T19:45:49  <sipa> https://github.com/bitcoin/bitcoin/pull/8204
416 2016-06-23T19:46:49  <sipa> petertodd: are you sure that's running the filtering code?
417 2016-06-23T19:46:57  <jtimon> gmaxwell: the "testnet only" builds are just from master after merging segwit, right?
418 2016-06-23T19:47:02  <sipa> jtimon: yes
419 2016-06-23T19:47:02  <petertodd> sipa: should be
420 2016-06-23T19:47:03  <gmaxwell> good okay, so an action right after merge will be to get some more testnet nodes running it spun up, and cooridnate a pre-rc testnet-default/only binary.
421 2016-06-23T19:47:10  <petertodd> sipa: I'll recheck
422 2016-06-23T19:47:14  <sipa> x9.seed.tbtc.petertodd.org gives many results, more than i'd expect
423 2016-06-23T19:47:32  <petertodd> sipa: note that it is running with extra args to support rbf
424 2016-06-23T19:47:40  <gmaxwell> jtimon: yes, likely with a trivial patch to change it to default to testnet (or require it). (and maybe a renamed binary)
425 2016-06-23T19:47:42  <petertodd> sipa: so maybe there's a bug there that you haven't run into yet
426 2016-06-23T19:48:16  <sipa> petertodd: can i see the code for that?
427 2016-06-23T19:48:20  *** fengling has joined #bitcoin-core-dev
428 2016-06-23T19:48:24  <jtimon> gmaxwell: why the changes? aren't this power users?
429 2016-06-23T19:48:33  <sipa> after the meeting, please
430 2016-06-23T19:48:44  <petertodd> sipa: it's with the command line arg; which incidentlaly was broken when I tried it (see my pullreq)
431 2016-06-23T19:49:02  <gmaxwell> any other topics for this meeting?
432 2016-06-23T19:49:31  <wumpus> doesn't seem so
433 2016-06-23T19:49:58  <wumpus> #endmeeting
434 2016-06-23T19:49:58  <lightningbot> Meeting ended Thu Jun 23 19:49:58 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
435 2016-06-23T19:49:58  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.html
436 2016-06-23T19:49:58  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.txt
437 2016-06-23T19:49:58  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.log.html
438 2016-06-23T19:50:23  <sipa> petertodd: are you including -w 9 ?
439 2016-06-23T19:50:35  <jtimon> oh, I think we forgot to make a joke, that's bad for the summaries :p
440 2016-06-23T19:51:03  <btcdrak> there is plenty comic relief there
441 2016-06-23T19:51:06  <gmaxwell> jtimon: the network changing expirence is not a great UI; I know of many people that are running a half dozen altcoins and got lost when asked to use testnet.  Especially since it's not a release that we want anyone messing up and running in production on mainnet, it makes sense to switch the default, both to make it easy to use, and harder to screw up.
442 2016-06-23T19:51:15  <petertodd> sipa: yeah, I think so
443 2016-06-23T19:51:46  <btcdrak> wumpus: so is segwit is the last feature PR and now 0.13 is frozen?
444 2016-06-23T19:51:55  <gmaxwell> segwit is not a feature PR
445 2016-06-23T19:52:03  <gmaxwell> and 0.13 has been frozen for a bit now.
446 2016-06-23T19:52:12  <wumpus> as gmaxwell says ^^
447 2016-06-23T19:52:16  <btcdrak> fine
448 2016-06-23T19:52:26  *** fengling has quit IRC
449 2016-06-23T19:52:27  <gmaxwell> (it's especially not a feature PR with it not yet activated in mainnet. :) )
450 2016-06-23T19:52:30  <jtimon> gmaxwell: whatever, the patch to change the default and/or disable mainnet should be trivial anyway
451 2016-06-23T19:52:52  <sipa> i'd be perfectly fine with that binary also supporting mainnet
452 2016-06-23T19:52:58  <gmaxwell> jtimon: yup. if it were hard I wouldn't have suggsted it. I think it's useful but not of great importance.
453 2016-06-23T19:53:34  <jtimon> I think I disagree with the notion that "the segwit PR is not a feature"
454 2016-06-23T19:53:38  <gmaxwell> I'd suggest just change testnet default to 1 in it. lots of people run git master in production (sadly, and sometimes without realizing it).
455 2016-06-23T19:53:55  <gmaxwell> jtimon: I feel sorry for you then?  It's not even exposed in 0.13 as merged.
456 2016-06-23T19:54:22  *** MarcoFalke has quit IRC
457 2016-06-23T19:54:35  <wumpus> re: launching testnet it would be useful if the windows installer created a Bitcoin Core (Testnet) link in the menu too, which does nothing but launch bitcoin-qt with -testnet flag. I have no idea how to do that though
458 2016-06-23T19:54:53  <gmaxwell> And the release cycle distinction we make for bitcoin is that consensus consistency changes are base, mandatory, functionality-- not software features (though sometimes some features must ride along with them)
459 2016-06-23T19:55:05  <jtimon> gmaxwell: precisely I thought the "softforks are minor releases" applied to the activation, not to the inactive code
460 2016-06-23T19:55:31  <gmaxwell> jtimon: sure though inactive code is not a feature either.
461 2016-06-23T19:55:50  <CodeShark> if it includes the testnet code I'd argue it is a feature
462 2016-06-23T19:55:53  <gmaxwell> wumpus: that would be fantastic, and would radically increase the use of testnet, I expect.
463 2016-06-23T19:56:08  <gmaxwell> CodeShark: A feature for testnet. ooohkay.
464 2016-06-23T19:56:25  <gmaxwell> I don't disagree but I don't think the distinction is important.
465 2016-06-23T19:56:49  <gmaxwell> Testnet is not very serious, as much as I'd like it to be more serious. It's often pretty broken.
466 2016-06-23T19:57:28  <CodeShark> going forward, as long as activation parameters for testnet softforks are documented somewhere and we agree on them it seems ok
467 2016-06-23T19:57:59  <btcdrak> CodeShark: they are already documented: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
468 2016-06-23T19:57:59  <gmaxwell> Not sure how you missed the couple weeks of discussion about segwit in testnet before.
469 2016-06-23T19:58:21  <CodeShark> I remember the discussion - I just wasn't clear on the release cycle as it pertains to testnet
470 2016-06-23T19:58:55  <jtimon> yeah, I think that's the source of the discussion
471 2016-06-23T19:58:57  <btcdrak> there is no release cycle. miners can apply whatever sfs they like at any time
472 2016-06-23T19:59:14  <jtimon> not saying necessarily the new method is worse, but it has changed
473 2016-06-23T19:59:34  <gmaxwell> In the future it might be useful to try to get softfork changes in earlier, and have them make it a whole cycle inactive on mainnet.  But testnet is testnet, whatever happens there is what people using it think is best for testing.
474 2016-06-23T19:59:42  <jtimon> well, "release cycle", "modus operandi", whatever
475 2016-06-23T19:59:48  <wumpus> I don't think the distinction is important either
476 2016-06-23T19:59:59  <wumpus> we just need segwit out, and everything that helps the testing and review process is great
477 2016-06-23T20:00:04  <gmaxwell> (e.g. you didn't see any of us howling about release cycle when jtoomim was using the XT hardfork on it)
478 2016-06-23T20:00:18  <wumpus> we're not goingn to block segwit on a procedural detail
479 2016-06-23T20:00:18  <btcdrak> jtimon: there isnt a release cycle. The consensus rules of the network are not defined by a release cycle of software
480 2016-06-23T20:00:39  <btcdrak> gmaxwell: exactly
481 2016-06-23T20:00:42  <gmaxwell> as btcdrak said.
482 2016-06-23T20:01:23  <gmaxwell> And sure, on _mainnet_ having consensus rules change without released software would be _insane_, thats why BIP9 got a starting date... but for testnet, that can make sense.
483 2016-06-23T20:01:45  <CodeShark> ok, fair enough - in the past I've been a bit confused as to testnet's purpose as it seems to be used for very different things. it seems like it should be the place where we try to break the protocol, first and foremost - and not so much the place where application developers can try out new stuff
484 2016-06-23T20:01:47  <gmaxwell> esp when the thing we're trying to test is deployment of a feature in a non-upgraded network. :)
485 2016-06-23T20:02:04  <jtimon> wumpus: completely agree re segwit, but if we can improve things for the future, it may be worth the discussion (ie like gmaxwell's suggestion on making a whole unactivaded release cycle). There's no harm on trying to think what would be "ideal" for next time
486 2016-06-23T20:02:18  <sipa> CodeShark: there have been proposals in the past for having multiple testnetd
487 2016-06-23T20:02:30  <gmaxwell> I'd love it to be where application developers can try new stuff, but virtually none have been interested in using it in the past, even with begging.
488 2016-06-23T20:02:48  <sipa> CodeShark: it is not ideal that network feature deployments are being tested in the same place as where we hope applications test before mainnet exposure
489 2016-06-23T20:02:52  <gmaxwell> and if they were, we could easily move more disruptive things to other testnets.
490 2016-06-23T20:03:08  <jtimon> btcdrak: ack
491 2016-06-23T20:03:38  <gmaxwell> but so far, people largely aren't, and there are barely enough running nodes to keep even one functional.  (and to be clear, segwit hasn't been disruptive of testnet)
492 2016-06-23T20:04:03  <wumpus> jtimon: sure, I just get crazy from all the time pressure and all the different things that pop up
493 2016-06-23T20:04:23  <wumpus> jtimon: I don't have much trust in anything ever being done the 'ideal' way :-)
494 2016-06-23T20:04:25  *** cryptapus has quit IRC
495 2016-06-23T20:04:27  <gmaxwell> Though its often disrupted by random stuff, and by ordinary releases too. (The alpha sidechain uses testnet and we've had a couple firedrills with it when the ordinary release cycle caused forks because of absentee miners on testnet)
496 2016-06-23T20:04:36  <jtimon> wumpus: not regreting anything rewarding segwit
497 2016-06-23T20:04:38  <CodeShark> if you're interested in testing applications and are comfortable assuming that the protocol itself isn't broken it seems preferable to spawn up a new testnet or just use regtest
498 2016-06-23T20:05:01  <gmaxwell> e.g. for a while after dersig would merge, testnet would fork as soon as the miner in my office got turned off because I was on a phone call and wanted less noise. :)
499 2016-06-23T20:05:05  <wumpus> jtimon: well the critical thing is that segwit is reviewed and tested enough, that there are no technical concerns with merging it
500 2016-06-23T20:05:08  <CodeShark> not sure it's necessary to test on testnet itself
501 2016-06-23T20:05:12  <CodeShark> at least for an application developer
502 2016-06-23T20:05:19  <CodeShark> although there is a benefit to us
503 2016-06-23T20:05:20  <gmaxwell> er after dersig was released.
504 2016-06-23T20:05:20  <jtimon> wumpus: ack
505 2016-06-23T20:05:23  <wumpus> jtimon: that's the kind of thing I lay awake about at night, not whether we do the release phases in the right order
506 2016-06-23T20:05:52  <gmaxwell> CodeShark: it's useful because most developers don't have the time and interest to simulate the volitility of a real network in their testing.
507 2016-06-23T20:05:57  <sipa> well, maybe having a windows desktop shortcut for testnet makes it more visible and attractive to test on
508 2016-06-23T20:06:05  <gmaxwell> E.g. left to their own devices reorg handling may be compeltely untested.
509 2016-06-23T20:06:21  <gmaxwell> also testnet is useful for interworking tests between multiple implementations.
510 2016-06-23T20:06:39  <sipa> i would love to see an actually operational test network, where you can try sending from testnet bitgo to testnet bitawesomewallet or something
511 2016-06-23T20:06:43  <jtimon> wumpus: that's perfect. I'm not criticizing. Just wondering if things can be done EVEN better
512 2016-06-23T20:06:48  <gmaxwell> I've joked before, but really seriously, that someone should setup a dumb gambling thing on testnet.
513 2016-06-23T20:07:12  <gmaxwell> I spent much of 2012 begging services to setup testnet instances of themselves with play money, without much luck.
514 2016-06-23T20:07:32  <gmaxwell> I think I got one exchange to do it for a bit. And they ended up stealing 10000 tnbtc from me and going unresponsive. :P
515 2016-06-23T20:07:48  <wumpus> the only services that exist for testnet seem to be some block explorers, also mostly broken
516 2016-06-23T20:08:26  <wumpus> I think regtest made it too attractive to set up internal testing networks :-)
517 2016-06-23T20:08:40  <wumpus> jtimon: agree, there's always room for improvement
518 2016-06-23T20:08:43  <jtimon> well, people used segtest, right? maybe if testnet usually had more features it would be more used (following gmaxwell's suggestion to have softforks activated in testnet but not activated in master for longer). Please, I'm just speculating
519 2016-06-23T20:09:00  <wumpus> testnet has 'more features', e.g. no standardness
520 2016-06-23T20:09:05  <gmaxwell> wumpus: most parties just seem to 'test' with mainnet, which is fine too, but you can't really test reorg and doublespend handling that way.
521 2016-06-23T20:09:20  <CodeShark> with regtest you can definitely do more rigorous testing - given you have programs that can simulate network conditions on it
522 2016-06-23T20:09:27  <gmaxwell> jtimon: softforks have pretty much always activated first on testnet.
523 2016-06-23T20:09:48  <gmaxwell> CodeShark: yes, you can but with a lot of work. What you can't test is what happens when crazy things that you didn't even know where possible happen. :)
524 2016-06-23T20:10:10  <wumpus> gmaxwell: well people like predictability for testing, as most testing is automated and internal anyway. On regtest you can trigger a reorg when you want to test it, instead of randomly happening at a point you're doing something else
525 2016-06-23T20:10:24  <gmaxwell> I think prudent parties will do both: rigorous tests with regtest and a harness, and a toy instance on testnet to see what catches fire.
526 2016-06-23T20:10:29  <wumpus> gmaxwell: (not that that kind of testing isn't useful, but it just isn't very popular)
527 2016-06-23T20:10:56  <wumpus> it requires people actually paying attention on the fly :)
528 2016-06-23T20:11:25  <gmaxwell> unpredictablity of blocktimes on testnet has not helpped for application testing.
529 2016-06-23T20:11:49  *** robs has joined #bitcoin-core-dev
530 2016-06-23T20:11:50  <wumpus> also unrealistic reorgs
531 2016-06-23T20:12:56  <gmaxwell> I've wondered if it might not be interesting to have a testnet with the rather small code for signed blocks from alpha and have a testnet where blocks happen once a minute constantly, and every N hours there is a reorg which includes every conflict the signer has learned about.
532 2016-06-23T20:12:58  <wumpus> whole runs of difficulty-1 blocks that are reorged away suddenly
533 2016-06-23T20:13:12  <btcdrak> there is no incentive to mine on testnet. that is the main issue
534 2016-06-23T20:13:31  <wumpus> btcdrak: right - if there was, then testnet coins would have a value
535 2016-06-23T20:13:45  <gmaxwell> btcdrak: I don't think thats an issue, I have 2TH that are basically always on testnet except when someone moves them off to test something else and forgets to move them back.
536 2016-06-23T20:15:00  <gmaxwell> I don't consider it important and don't actively monitor them, though I could have that setup... often it's the only mining of testnet though.
537 2016-06-23T20:15:23  <btcdrak> gmaxwell: i like the idea of testnet block signers.
538 2016-06-23T20:15:27  <gmaxwell> wumpus: it's tricky, for that kind of testing there should be substantive reorgs (that mainnet has only very rarely); but not absurd ones.
539 2016-06-23T20:15:55  <gmaxwell> the diff-1 stuff in testnet feels like its mostly been a failure, ... okay, it's an improvement over being stuck for days, but it's lame in a lot of other ways.
540 2016-06-23T20:17:02  <CodeShark> the way I always looked at it, testnet is ideal for people who want to try to break the protocol itself and try their exploits
541 2016-06-23T20:17:16  <gmaxwell> btcdrak: I'd say that someone who wanted that could just use alpha, but alpha has a lot of radical depatures, it's not that compatible.
542 2016-06-23T20:17:45  <CodeShark> for any sort of testing where you know the edge cases, regtest is better  - but testnet can help with the cases we didn't think of
543 2016-06-23T20:17:47  <gmaxwell> CodeShark: its mostly not used for that. The most use it gets is breaking secondary implementations.
544 2016-06-23T20:18:27  <gmaxwell> halariously, there is one of these "messaging via the blockchain" spammy things that uses testnet for production.
545 2016-06-23T20:18:58  <gmaxwell> Bitcoin tx fees were too high for them, so they only use bitcoin for periodic commitments and they use testnet as a messaging flooding network.
546 2016-06-23T20:19:28  <jtimon> sorry, was afk
547 2016-06-23T20:19:51  <helo> god forbid they form their own relay network that actually fits their use case
548 2016-06-23T20:20:10  <btcdrak> helo: they are too lazy.
549 2016-06-23T20:20:19  <gmaxwell> It's complicated.
550 2016-06-23T20:22:14  <gmaxwell> I think a lot of 'programming' has split into layers, there are systems people like me that generally don't touch UIs. And 'applications' people that wont touch a protocol. ... and in the later case a very strong culture of using hosted services. (I've seen webapps calling third party rest APIs to do things like sort a list) ... so using some found network seems sensible to some people... and I'
551 2016-06-23T20:22:21  <NicolasDorier> wumpus: you were whinning about testing 0.13 on windows on twitter? I can help if needed (btw, all my compact blocks tests were done on windows)
552 2016-06-23T20:22:21  <gmaxwell> m certantly not out going to make some custom network for some crazy app dejure (unless they're going to pay...)
553 2016-06-23T20:22:34  <CodeShark> helo: if you haven't noticed, it seems the opposite is more prevalent these days...people trying to fit their use cases to use blockchains somehow
554 2016-06-23T20:23:28  <jtimon> gmaxwell: well, we could maintain a single-element (ie block signing) chain in elements...
555 2016-06-23T20:24:10  <gmaxwell> helo: so I think part of it is a software norm that has arisen where you build software by using third party APIs that you find.. BUT you reconize that these centeralized APIs are a problem... sooooo a "found" distributed network is the obvious solution.
556 2016-06-23T20:24:14  <CodeShark> gmaxwell: even if they're going to pay you probably have better things to do ;)
557 2016-06-23T20:24:19  <gmaxwell> helo: so I think thats one component of the blockchain hype.
558 2016-06-23T20:25:04  <gmaxwell> jtimon: yes, and a seperate network that used just that and was otherwise the same as bitcoin testnet
559 2016-06-23T20:25:40  <jtimon> yes
560 2016-06-23T20:26:48  <gmaxwell> jtimon: I dunno if anyone would use it.  it could even do a clever thing where blocks that would be reorged out are signed by seperate keys, so that users could decide if they want to see reorgs or not.
561 2016-06-23T20:27:12  <btcdrak>  permissioned testnet :)
562 2016-06-23T20:27:37  *** Anduck has quit IRC
563 2016-06-23T20:27:38  *** bustd_soket has quit IRC
564 2016-06-23T20:27:38  *** rubensayshi has quit IRC
565 2016-06-23T20:27:38  *** adamg has quit IRC
566 2016-06-23T20:27:38  *** musalbas has quit IRC
567 2016-06-23T20:27:43  *** sipa has quit IRC
568 2016-06-23T20:27:43  *** jron_ has quit IRC
569 2016-06-23T20:27:43  *** hexis has quit IRC
570 2016-06-23T20:27:44  *** harding has quit IRC
571 2016-06-23T20:27:45  *** cfields_ has quit IRC
572 2016-06-23T20:27:45  *** petertodd has quit IRC
573 2016-06-23T20:27:47  *** harding has joined #bitcoin-core-dev
574 2016-06-23T20:27:47  *** sipa has joined #bitcoin-core-dev
575 2016-06-23T20:27:48  *** petertodd has joined #bitcoin-core-dev
576 2016-06-23T20:27:53  *** Anduck has joined #bitcoin-core-dev
577 2016-06-23T20:27:53  <jtimon> gmaxwell: interesting thought
578 2016-06-23T20:27:56  *** hexis has joined #bitcoin-core-dev
579 2016-06-23T20:28:01  *** bustd_soket has joined #bitcoin-core-dev
580 2016-06-23T20:28:02  <sipa> yow
581 2016-06-23T20:28:04  *** adamg has joined #bitcoin-core-dev
582 2016-06-23T20:28:05  *** rubensayshi has joined #bitcoin-core-dev
583 2016-06-23T20:28:15  *** jron has joined #bitcoin-core-dev
584 2016-06-23T20:28:41  <helo> yeah, that sounds about right...
585 2016-06-23T20:29:19  *** musalbas has joined #bitcoin-core-dev
586 2016-06-23T20:29:43  *** cfields has joined #bitcoin-core-dev
587 2016-06-23T20:30:12  <gmaxwell> e.g. produce a block every 5 minutes that it promses to not reorg, and otherwise produces faster blocks which it _tries_ to reorg with doublespends whenever they happen.  If you want to test something and not see reorgs, just ignore the non-guarenteed blocks.  Would be a fair amount of coding though to do the try-to-reorg behavior. But I think it would be quite valuable for some people who don't
588 2016-06-23T20:30:18  <gmaxwell>  have the background/time/interest to go build a regtest test harness.
589 2016-06-23T20:30:22  <gmaxwell> I can tell you that a lot of bitcoin services have no reorg handling at all. :(
590 2016-06-23T20:30:32  *** zmanian__ has quit IRC
591 2016-06-23T20:30:55  *** wallet42 has quit IRC
592 2016-06-23T20:31:41  *** limpkin has quit IRC
593 2016-06-23T20:32:14  *** zmanian__ has joined #bitcoin-core-dev
594 2016-06-23T20:32:52  *** wallet42 has joined #bitcoin-core-dev
595 2016-06-23T20:34:09  <da2ce7_mobile> has something happened to sipa's node, or the BIP9 chart looking very werid: http://bitcoin.sipa.be/ver9-2k.png
596 2016-06-23T20:34:11  *** limpkin has joined #bitcoin-core-dev
597 2016-06-23T20:34:18  <CodeShark> just to be 100% clear, the plan is no more minor releases on 0.12, merge segwit into master now but without activation parameters
598 2016-06-23T20:34:24  <CodeShark> correct?
599 2016-06-23T20:34:31  <gmaxwell> CodeShark: no.
600 2016-06-23T20:34:35  <btcdrak> urgh
601 2016-06-23T20:34:39  <btcdrak> I PMd him
602 2016-06-23T20:34:56  <gmaxwell> there is nothing weird about it.
603 2016-06-23T20:35:29  <da2ce7_mobile> I was expecting the CSV flags to drop straight down to zero.
604 2016-06-23T20:35:37  <gmaxwell> Miners are turning off their BIP9 signaling manually (which is what I was fussing about a few days ago). It's no longer required as it locked in.
605 2016-06-23T20:35:56  <sipa> da2ce7_mobile: BIP9 suggests that they don't
606 2016-06-23T20:36:07  <gmaxwell> the fact that miners are manually twiddling their versions is a big long term concern and risk, but checking directly with them suggests things are fine.
607 2016-06-23T20:36:08  <sipa> da2ce7_mobile: and that they keep setting the flag during the locked_in phase
608 2016-06-23T20:36:17  *** bustd_soket has quit IRC
609 2016-06-23T20:36:23  <da2ce7_mobile> :(
610 2016-06-23T20:36:23  *** instagibbs3 has quit IRC
611 2016-06-23T20:36:40  <sipa> why :(
612 2016-06-23T20:36:58  <gmaxwell> presumably that was to the manual setting of bits.
613 2016-06-23T20:37:02  <da2ce7_mobile> well it would be better if they followed the protocol.
614 2016-06-23T20:37:40  <gmaxwell> There is a cellphone game called spaceteam where you have to call out instructions for other people to punch in to jointly fly a fictional spacecraft.  Manually setting consensus normative flags in bitcoin makes me think of spaceteam.
615 2016-06-23T20:37:59  <sipa> da2ce7_mobile: the difference between theory and practice is that there is none in theory
616 2016-06-23T20:38:11  <gmaxwell> "Bit 1 activate"  "set hyperdrive to on" "engage flanx warbler" "Bit 1 deactivate"
617 2016-06-23T20:38:31  <sipa> check sequence verify!
618 2016-06-23T20:38:38  <da2ce7_mobile> :D :D
619 2016-06-23T20:38:42  <sipa> median time: set to past
620 2016-06-23T20:39:23  <gmaxwell> haha   "reorganize! everybody shake!"
621 2016-06-23T20:40:20  <da2ce7_mobile> Ok. It look like that CSV could be a bit of a bumpy ride when activating.
622 2016-06-23T20:40:26  <gmaxwell> da2ce7_mobile: huh?
623 2016-06-23T20:40:27  <sipa> set activation threshold to 95%
624 2016-06-23T20:40:32  <gmaxwell> da2ce7_mobile: not at all.
625 2016-06-23T20:40:54  <btcdrak> da2ce7_mobile: activation is now certain and we know which block it will occur on
626 2016-06-23T20:40:57  <Lightsword> is it only eloipool based pools that manually set the version?
627 2016-06-23T20:41:19  <da2ce7_mobile> well if the bits are not being auto-unset then that suggests that the miners haven't upgraded their nodes.
628 2016-06-23T20:41:23  <btcdrak> Lightsword: no. we have contacted the pools who do.
629 2016-06-23T20:41:31  <gmaxwell> it's locked in, the bit doesn't technically matter, we've checked with the miners who aren't setting it anymore and confirmed that they're all upgraded.. they're only not setting it now because they manually set the version (danger! danger!, but not at the moment).
630 2016-06-23T20:41:50  <btcdrak> da2ce7_mobile: not at all. it just means they set the bit manually, against our advice.
631 2016-06-23T20:42:11  <gmaxwell> da2ce7_mobile: they have, (well they have or they're lying) the explination is that due to how past softforks worked their infrastructure is setup to 'fake' all versions.
632 2016-06-23T20:42:12  <da2ce7_mobile> ok. well in that case I'm less worried.
633 2016-06-23T20:42:16  <btcdrak> it's explained here: https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/
634 2016-06-23T20:42:36  <btcdrak> and also here: https://bitcoincore.org/en/2016/06/21/csv-softfork-instructions/
635 2016-06-23T20:42:52  <gmaxwell> Because past softforks would orphan your blocks if you had the wrong version.   We specifically got rid of that behavior in BIP9 in part to discourage faking the versions, but this improvement is not yet well understood and the software is already written.
636 2016-06-23T20:43:51  *** gluytium has joined #bitcoin-core-dev
637 2016-06-23T20:44:32  <da2ce7_mobile> ok :)  you guys are way ahead of me.  Colour me impressed (yet again).
638 2016-06-23T20:44:46  <gmaxwell> in any case, "we've (hopefully) got this"
639 2016-06-23T20:44:48  <Lightsword> yeah, I can see why some have to set it manually, especially since some build blocks from stratum templates…not sure what the proper way to handle it with those situations would be
640 2016-06-23T20:45:00  <gmaxwell> I was irritated to find people were still manually overriding it.
641 2016-06-23T20:45:04  <gmaxwell> Lightsword: take the version from the template.
642 2016-06-23T20:45:18  <btcdrak> Lightsword: chat with jl2012, he said he found a solution for one of the pools at least
643 2016-06-23T20:46:10  <gmaxwell> We could also in GBT return a "next block version" to allowed delayed computation there. Thoug we can't do a "next block bits" which would be more useful...
644 2016-06-23T20:46:38  <da2ce7_mobile> I really like BIP9. It is a really elegant solution and upgrade.
645 2016-06-23T20:46:39  <gmaxwell> and part of the reason why BIP9 flag changes happen at retargets is to make the header unpredictable at the same time the bits change makes it unpredictable.
646 2016-06-23T20:49:07  *** fengling has joined #bitcoin-core-dev
647 2016-06-23T20:49:22  <da2ce7_mobile> sipa: while I have been following your segwit pull request(s); the code goes over my head. however it is easy to see your professionalism and dedication is really exceptional. :)
648 2016-06-23T20:49:52  *** MarcoFalke has joined #bitcoin-core-dev
649 2016-06-23T20:50:00  <sipa> da2ce7_mobile: thanks :)
650 2016-06-23T20:50:37  <sipa> (and thank everyone who's helping... i didn't even write the majority of the code)
651 2016-06-23T20:52:23  *** MarcoFalke has quit IRC
652 2016-06-23T20:53:26  *** fengling has quit IRC
653 2016-06-23T20:54:56  *** bustd_soket has joined #bitcoin-core-dev
654 2016-06-23T20:57:22  *** Chris_Stewart_5 has quit IRC
655 2016-06-23T21:12:32  *** Chris_Stewart_5 has joined #bitcoin-core-dev
656 2016-06-23T21:49:54  *** fengling has joined #bitcoin-core-dev
657 2016-06-23T21:54:06  *** fengling has quit IRC
658 2016-06-23T21:55:14  *** Guyver2 has quit IRC
659 2016-06-23T22:04:08  *** cryptapus_afk is now known as cryptapus
660 2016-06-23T22:05:19  *** gluytium has quit IRC
661 2016-06-23T22:20:21  *** gluytium has joined #bitcoin-core-dev
662 2016-06-23T22:23:57  *** jcorgan has left #bitcoin-core-dev
663 2016-06-23T22:44:02  *** cryptapus is now known as cryptapus_afk
664 2016-06-23T22:50:38  *** fengling has joined #bitcoin-core-dev
665 2016-06-23T22:54:46  *** fengling has quit IRC
666 2016-06-23T22:59:02  *** CubicEarth has quit IRC
667 2016-06-23T23:03:36  *** CubicEarth has joined #bitcoin-core-dev
668 2016-06-23T23:10:33  *** pedrobranco has joined #bitcoin-core-dev
669 2016-06-23T23:14:49  *** pedrobranco has quit IRC
670 2016-06-23T23:15:17  *** CubicEarth has quit IRC
671 2016-06-23T23:15:45  *** whogoesthere__ has joined #bitcoin-core-dev
672 2016-06-23T23:23:16  *** CubicEarth has joined #bitcoin-core-dev
673 2016-06-23T23:29:42  *** d9b4bef9 has quit IRC
674 2016-06-23T23:30:03  *** neuroses1412 has quit IRC
675 2016-06-23T23:30:15  *** d9b4bef9 has joined #bitcoin-core-dev
676 2016-06-23T23:46:54  *** CubicEarth has quit IRC
677 2016-06-23T23:51:20  *** fengling has joined #bitcoin-core-dev
678 2016-06-23T23:55:26  *** fengling has quit IRC
679 2016-06-23T23:55:55  *** gluytium has quit IRC