1 2016-06-23 02:45:46	0|GitHub58|[13bitcoin] 15dcousens opened pull request #8244: remove unnecessary LOCK(cs_main) (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/8244
  2 2016-06-23 02:46:37	0|dcousens|uh, I probably meant to ask about https://github.com/bitcoin/bitcoin/pull/8244 here, not #bitcoin-dev
  3 2016-06-23 05:01:20	0|kitty_|Hi I need help please
  4 2016-06-23 05:01:36	0|kitty_|Does anyone here know how to contact the bitcoin core wallet support team
  5 2016-06-23 05:03:40	0|kitty_|Is there a support team for bitcoin core wallet
  6 2016-06-23 05:17:52	0|kitty_|is anyone here
  7 2016-06-23 05:43:13	0|kitty_|is there anyone here that helps with bitcoin core wallet
  8 2016-06-23 05:49:02	0|jl2012|Just ask your question, or try #bitcoin
  9 2016-06-23 05:50:32	0|kitty_|what do you mean #bitcoin
 10 2016-06-23 05:50:40	0|kitty_|#bitcoin
 11 2016-06-23 07:35:19	0|shangzhou|means try another channel called #bitcoin this is #bitcoin-core-dev
 12 2016-06-23 10:50:56	0|GitHub7|[13bitcoin] 15laanwj opened pull request #8246: trivial: capitalize BIP32 in option help (06master...062016_06_bip32_uppercase) 02https://github.com/bitcoin/bitcoin/pull/8246
 13 2016-06-23 11:02:39	0|GitHub70|13bitcoin/06master 14a1c92c2 15Wladimir J. van der Laan: trivial: capitalize BIP32 in option help...
 14 2016-06-23 11:02:39	0|GitHub70|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/9f1807af2422...147a7b6726d3
 15 2016-06-23 11:02:40	0|GitHub70|13bitcoin/06master 14147a7b6 15Wladimir J. van der Laan: Merge #8246: trivial: capitalize BIP32 in option help...
 16 2016-06-23 11:02:49	0|GitHub103|[13bitcoin] 15laanwj closed pull request #8246: trivial: capitalize BIP32 in option help (06master...062016_06_bip32_uppercase) 02https://github.com/bitcoin/bitcoin/pull/8246
 17 2016-06-23 11:05:02	0|GitHub5|13bitcoin/06master 14d80efec 15Peter Todd: Update petertodd's testnet seed...
 18 2016-06-23 11:05:02	0|GitHub5|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/147a7b6726d3...08338942b50f
 19 2016-06-23 11:05:03	0|GitHub5|13bitcoin/06master 140833894 15Wladimir J. van der Laan: Merge #8204: Update petertodd's testnet seed...
 20 2016-06-23 11:05:12	0|GitHub150|[13bitcoin] 15laanwj closed pull request #8204: Update petertodd's testnet seed (06master...062016-06-15-update-tbtc-seed) 02https://github.com/bitcoin/bitcoin/pull/8204
 21 2016-06-23 13:45:17	0|GitHub21|[13bitcoin] 15sipa opened pull request #8247: Mark my dnsseed as supporting filtering (06master...06newseed) 02https://github.com/bitcoin/bitcoin/pull/8247
 22 2016-06-23 14:57:52	0|GitHub49|[13bitcoin] 15laanwj opened pull request #8249: Enable (and check for) 64-bit ASLR on Windows (06master...062016_06_windows64_security) 02https://github.com/bitcoin/bitcoin/pull/8249
 23 2016-06-23 19:00:37	0|wumpus|meeting time?
 24 2016-06-23 19:02:26	0|sipa|present
 25 2016-06-23 19:02:31	0|gmaxwell|past?
 26 2016-06-23 19:02:41	0|lightningbot|Meeting started Thu Jun 23 19:02:40 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 27 2016-06-23 19:02:41	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
 28 2016-06-23 19:02:41	0|wumpus|#startmeeting
 29 2016-06-23 19:03:05	0|wumpus|any proposed topics?
 30 2016-06-23 19:04:01	0|wumpus|I think https://github.com/bitcoin/bitcoin/issues/8245 needs discussion, whether reindex/verification slowed down
 31 2016-06-23 19:04:05	0|gmaxwell|sdaftuar: sipa: phantomcircuit: jonasschnelli: MarcoFalke: jtimon: phantomcircuit: instagibbs: petertodd: morcos:
 32 2016-06-23 19:04:08	0|sipa|ack topic
 33 2016-06-23 19:04:12	0|gmaxwell|ack.
 34 2016-06-23 19:04:41	0|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
 35 2016-06-23 19:04:47	0|wumpus|#topic perceived validation slowdowns
 36 2016-06-23 19:04:59	0|sipa|i noticed very slow chainstate writes (close to a minute, even though the chainstate is only 53 MB)
 37 2016-06-23 19:05:03	0|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.
 38 2016-06-23 19:05:14	0|sipa|though this may be due to my laptop's disk setup (zfs on encrypted lvm volume)
 39 2016-06-23 19:05:27	0|wumpus|so, some people are noticiing slow validation, I wonder what changed there
 40 2016-06-23 19:05:30	0|gmaxwell|(two identical hosts)
 41 2016-06-23 19:05:49	0|sipa|from gmaxwell's numbers, it does not look like his time is dominated by database flushes, however
 42 2016-06-23 19:05:57	0|gmaxwell|I think I am often guilty of only testing things with a non-default dbcache.
 43 2016-06-23 19:06:04	0|sipa|likewise
 44 2016-06-23 19:06:13	0|gmaxwell|I previously _expected_ reindex to be slow due to the signature checking.
 45 2016-06-23 19:06:20	0|wumpus|I usually run with default dbcache
 46 2016-06-23 19:06:30	0|jtimon|maybe a solution would be to change the default dbcache for something more common among testers?
 47 2016-06-23 19:06:46	0|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.
 48 2016-06-23 19:06:48	0|sipa|jtimon: we still need to figure out what is behind this... but independently, yes
 49 2016-06-23 19:06:50	0|wumpus|yes, we should definitely crank up the dbcache no matter what
 50 2016-06-23 19:06:54	0|wumpus|but I like to know what happened
 51 2016-06-23 19:07:09	0|jtimon|sipa: yeah, of course, I meant independently
 52 2016-06-23 19:07:30	0|wumpus|should at least try to bisec tthis, I know it's frustrating as everything takes so long :)
 53 2016-06-23 19:08:07	0|sipa|oh, this is with txindex enabled
 54 2016-06-23 19:08:14	0|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?
 55 2016-06-23 19:08:18	0|wumpus|gmaxwell didn't you have some suspicions that CB would affect initial sync? could that also affect reindex?
 56 2016-06-23 19:08:25	0|wumpus|not in my case
 57 2016-06-23 19:08:27	0|sipa|wumpus: gmaxwell's test was before cb was merged
 58 2016-06-23 19:08:57	0|gmaxwell|my test is without cb merged, also the CB concern was just related to general sync logic, not processing.
 59 2016-06-23 19:08:59	0|jtimon|are there recent changes that people suspect may have caused the regression ?
 60 2016-06-23 19:09:07	0|wumpus|wouldbe good to test against #7917, as many people benchmarked that
 61 2016-06-23 19:09:19	0|wumpus|and it was perceived fast at the time
 62 2016-06-23 19:09:40	0|wumpus|jtimon: not really
 63 2016-06-23 19:09:42	0|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.
 64 2016-06-23 19:10:13	0|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.
 65 2016-06-23 19:10:31	0|gmaxwell|(maybe not leveldb itself being slow, e.g. making extranious accesses to it)
 66 2016-06-23 19:10:47	0|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
 67 2016-06-23 19:10:57	0|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
 68 2016-06-23 19:11:04	0|gmaxwell|So actions are. determine if regression, if so where, ... seperately, consider a dbcache increase for the next release.
 69 2016-06-23 19:11:08	0|wumpus|I doubt it is leveldb itself as there haven't been changed to that for ages
 70 2016-06-23 19:11:17	0|gmaxwell|sipa: yes this might be txindex related. I can test that too.
 71 2016-06-23 19:11:23	0|wumpus|yes, txindex is *slow*
 72 2016-06-23 19:11:25	0|CodeShark|is something slowing down validation that wasn't before?
 73 2016-06-23 19:11:29	0|sipa|CodeShark: maybe
 74 2016-06-23 19:11:33	0|wumpus|lots of extra I/O. I also made that mistake once
 75 2016-06-23 19:11:40	0|gmaxwell|wumpus: we have changed (reduced) the amount of interaction with leveldb during validation.
 76 2016-06-23 19:11:51	0|wumpus|gmaxwell: sure, it may be the level above leveldb
 77 2016-06-23 19:12:00	0|sipa|yes, it may be
 78 2016-06-23 19:12:06	0|wumpus|I just don't suspect the databse itself this time
 79 2016-06-23 19:12:34	0|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.
 80 2016-06-23 19:12:37	0|wumpus|unless some compiler flag changed things shockingly, say, the c++11 switch, but I doubt it
 81 2016-06-23 19:12:54	0|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.
 82 2016-06-23 19:13:07	0|sipa|i briefly suspected the IsInitialBlockDownload change, but apart from using an atomic, its semantics should be unchanged
 83 2016-06-23 19:13:19	0|wumpus|especialy if you see the slowdown in the flush; txindex writes a lot of data to the block index databse
 84 2016-06-23 19:13:43	0|sipa|wumpus: but the txindex writes don't happen during the flush
 85 2016-06-23 19:13:46	0|wumpus|so maybe false alarm, the sync is slow, news at 11
 86 2016-06-23 19:13:59	0|sipa|wumpus: though they may accumulate somewhere in leveldb until a flush is issued
 87 2016-06-23 19:14:01	0|CodeShark|can't we add tracers around calls to narrow it down?
 88 2016-06-23 19:14:09	0|gmaxwell|wumpus: well, the "lets increase the dbcache" is still a useful response to this catching attention again.
 89 2016-06-23 19:14:31	0|sipa|action points: benchmark in same conditions without txindex, and with larger dbcache?
 90 2016-06-23 19:14:56	0|wumpus|yes we should increate the dbcache, and probably change how it is allocated
 91 2016-06-23 19:15:10	0|wumpus|(e.g. a relatively large part now goes to leveldb caches, that's a waste
 92 2016-06-23 19:15:17	0|gmaxwell|(as my laptop is about to be on day three of reindex)
 93 2016-06-23 19:15:51	0|sipa|wumpus: the reasoning was that leveldb cache is serialized, so it has a much large impact per byte than the internal cache
 94 2016-06-23 19:15:56	0|wumpus|leveldb's own caches are completely ineffective compared to bitcoind's application level cache
 95 2016-06-23 19:15:59	0|sipa|but it has the deserialization overhead
 96 2016-06-23 19:16:17	0|sipa|but that's mostly a guess without substansive benchmarking
 97 2016-06-23 19:16:18	0|wumpus|sipa: that makes a lot of sense in theory, but leveldb just sucks at caching :)
 98 2016-06-23 19:16:43	0|gmaxwell|I can benchmark a bunch of mixes of cache sizes and see how they pan out.
 99 2016-06-23 19:16:54	0|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
100 2016-06-23 19:17:04	0|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
101 2016-06-23 19:17:10	0|jtimon|not sure I'm following but maybe we want separate options for the "internal" and "external" caches?
102 2016-06-23 19:17:28	0|wumpus|jtimon: for testing that'd be awesome
103 2016-06-23 19:17:42	0|sipa|jtimon: for testing that makes sense, but as a product it should work well with the fewest number of tunable possible
104 2016-06-23 19:17:47	0|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)
105 2016-06-23 19:17:58	0|sipa|jynx
106 2016-06-23 19:18:00	0|instagibbs2|On phone but present
107 2016-06-23 19:18:21	0|jtimon|there's some options that can only be accessed if --debug, right?
108 2016-06-23 19:18:25	0|wumpus|gmaxwell: you'd be surprised :-)
109 2016-06-23 19:18:35	0|wumpus|some users are very persistent in trying to find settings that are fastest for them
110 2016-06-23 19:18:49	0|CodeShark|I'd venture to say it's probably not the majority
111 2016-06-23 19:18:51	0|wumpus|but yes, it should be a hidden option (--help-debug)
112 2016-06-23 19:18:53	0|jtimon|oh, no they may not be showed in the help but they're still accesible I think
113 2016-06-23 19:19:00	0|wumpus|CodeShark: sure, but don't underestimate peole
114 2016-06-23 19:19:08	0|sipa|wumpus: maybe such options should be marked with ("If you find a setting for this value that improves performance, please let us know")
115 2016-06-23 19:19:15	0|wumpus|sipa: +1 :D
116 2016-06-23 19:19:18	0|gmaxwell|-funroll-loops -O20
117 2016-06-23 19:19:34	0|sipa|-femit-broken-code
118 2016-06-23 19:20:06	0|wumpus|-fskip-computing-even-bits
119 2016-06-23 19:20:14	0|wumpus|ok, any other topics?
120 2016-06-23 19:20:15	0|sipa|relatedly, i think -qt can by default use more ram
121 2016-06-23 19:20:37	0|sipa|also, 100 mb is kinda ridiculous with the mempool already being 300 mb
122 2016-06-23 19:20:42	0|wumpus|yes, probably, although qt itself also uses more ram
123 2016-06-23 19:21:02	0|wumpus|yes, agreed
124 2016-06-23 19:21:11	0|sipa|other topic: merge segwit yay or nay
125 2016-06-23 19:21:17	0|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.
126 2016-06-23 19:21:17	0|wumpus|let's reduce the mempool to 100mb and increase dbcache to 300mb
127 2016-06-23 19:21:39	0|petertodd|sipa: re: segwit, has it been rebased?
128 2016-06-23 19:21:45	0|wumpus|#topic segwit
129 2016-06-23 19:21:47	0|sipa|petertodd: 12 times by now
130 2016-06-23 19:21:51	0|CodeShark|lol
131 2016-06-23 19:21:54	0|sipa|see 8149
132 2016-06-23 19:21:55	0|CodeShark|poor sipa
133 2016-06-23 19:21:56	0|jtimon|how can we feature freeze without merging segwit?
134 2016-06-23 19:22:03	0|wumpus|sipa is getting carpal tunnel syndrome from rebasing
135 2016-06-23 19:22:05	0|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.
136 2016-06-23 19:22:16	0|wumpus|jtimon: softforks / consensus changes don't count as software features
137 2016-06-23 19:22:28	0|wumpus|jtimon: that's also why they're allowed to be introduced in minor versions
138 2016-06-23 19:22:30	0|petertodd|sipa: I mean, is the current pull-req rebased since compact blocks got merged?
139 2016-06-23 19:22:32	0|gmaxwell|also it's not even activated in any case. it's pure code updates.
140 2016-06-23 19:22:35	0|sipa|petertodd: yes
141 2016-06-23 19:22:50	0|jtimon|wumpus: so it won't be possible to include any feature post segwit merge in 0.13 ?
142 2016-06-23 19:22:52	0|CodeShark|current is #8149, yes?
143 2016-06-23 19:23:00	0|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)
144 2016-06-23 19:23:05	0|wumpus|jtimon: right, 0.13 is closed feature-wise
145 2016-06-23 19:23:53	0|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.
146 2016-06-23 19:23:55	0|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)
147 2016-06-23 19:24:02	0|jtimon|wumpus: that is a no, that is unconvenient and I wasn't expecting it, but thanks
148 2016-06-23 19:24:34	0|wumpus|#link see the release schedule here: https://github.com/bitcoin/bitcoin/issues/8250
149 2016-06-23 19:24:56	0|CodeShark|sipa: which PR should we be testing against?
150 2016-06-23 19:24:56	0|jtimon|yeah, should have asked "what about segwit?" back then
151 2016-06-23 19:25:06	0|sipa|CodeShark: 8149 and 7190 are the exact same code
152 2016-06-23 19:25:10	0|sipa|so whatever you like
153 2016-06-23 19:25:45	0|gmaxwell|I had completed review up to the CB rebase, which I have not looked at yet.
154 2016-06-23 19:26:03	0|gmaxwell|(I mean I haven't looked at segwit's rebase for CB)
155 2016-06-23 19:26:25	0|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
156 2016-06-23 19:26:46	0|sipa|git show -w c4e3c755d7e41aaabe74c84af7e4bf00a62c96fb
157 2016-06-23 19:26:54	0|sipa|and then search for cmpctblk and blocktxn
158 2016-06-23 19:27:01	0|sipa|to see the changes related to that
159 2016-06-23 19:27:05	0|btcdrak|oh I'm late
160 2016-06-23 19:27:21	0|wumpus|jtimon: we all would have preferred other timings, but we have to cope with how things actually are :)
161 2016-06-23 19:27:47	0|jtimon|I planned to rebase/rewrite some of the consensus encapsulation code after segwit, I guess the plan doesn't change anyway
162 2016-06-23 19:28:02	0|wumpus|well you can still do that, it just won't make 0.13
163 2016-06-23 19:28:38	0|jtimon|wumpus: well, yeah, I could have helped more with reviewing and testing segwit
164 2016-06-23 19:28:42	0|gmaxwell|sipa: thanks, will review once I start up the test panel for the prior topic. :)
165 2016-06-23 19:28:48	0|jtimon|wumpus: understood
166 2016-06-23 19:29:07	0|sipa|jtimon: you can still do that, even after merge :)
167 2016-06-23 19:29:23	0|gmaxwell|yes, post merge review and testing is super important too.
168 2016-06-23 19:29:45	0|wumpus|yes, absolutely
169 2016-06-23 19:30:23	0|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)
170 2016-06-23 19:30:43	0|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
171 2016-06-23 19:30:48	0|gmaxwell|Obviously there may still need to be some fixes and nits. But thats what we have time for.
172 2016-06-23 19:30:54	0|sipa|(compared to running just cb before)
173 2016-06-23 19:30:56	0|wumpus|anyone against merging segwit?
174 2016-06-23 19:31:04	0|wumpus|(I mean right now, not in general)
175 2016-06-23 19:32:00	0|wumpus|*crickets*
176 2016-06-23 19:32:11	0|sipa|i have no objections :)
177 2016-06-23 19:32:14	0|wumpus|that's clear then
178 2016-06-23 19:32:17	0|btcdrak|I'd like to see it merged too
179 2016-06-23 19:32:19	0|wumpus|yes, I understood
180 2016-06-23 19:32:27	0|jtimon|sipa: yeah, it just won't make it to 0.13 as wumpus explained
181 2016-06-23 19:32:30	0|CodeShark|the sooner the better (as long as it doesn't break current behavior)
182 2016-06-23 19:32:40	0|wumpus|#action Merge segwit
183 2016-06-23 19:32:45	0|btcdrak|o/
184 2016-06-23 19:33:11	0|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.
185 2016-06-23 19:33:27	0|instagibbs3|Good.
186 2016-06-23 19:34:00	0|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?
187 2016-06-23 19:34:20	0|petertodd|gmaxwell: fine by me
188 2016-06-23 19:34:22	0|sipa|i believe jonasschnelli builds nightly binaries
189 2016-06-23 19:34:22	0|wumpus|sure, why not
190 2016-06-23 19:34:47	0|wumpus|I prefer doing that outside the 'official' release cycle, but I don't mind running gitian for it
191 2016-06-23 19:34:51	0|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. :)
192 2016-06-23 19:35:15	0|gmaxwell|yes, I don't want something part of the release cycle. Just binaries to give to power users to give it a spin.
193 2016-06-23 19:35:27	0|wumpus|testnet-only
194 2016-06-23 19:35:52	0|CodeShark|testnet as in not segnet, right?
195 2016-06-23 19:35:52	0|gmaxwell|yea, pre-RC testnet only, we could one line patch to change the default network, so it'll be easier to use.
196 2016-06-23 19:36:07	0|sipa|CodeShark: segnet has been removed a few weeks ago from the patch
197 2016-06-23 19:36:18	0|gmaxwell|Testnet is segwit now. Segnet is dead long live segnet.
198 2016-06-23 19:36:21	0|petertodd|gmaxwell: maybe better to just make it fail unless -testnet is enabled, in case someone does run it in production
199 2016-06-23 19:36:27	0|wumpus|no, not segnet. Regtest could be allowed. But mainnet disabled and testnet as default
200 2016-06-23 19:36:32	0|CodeShark|is segwit live on testnet?!?!
201 2016-06-23 19:36:36	0|gmaxwell|yea. exactly.
202 2016-06-23 19:36:38	0|sipa|CodeShark: yes, since months
203 2016-06-23 19:37:02	0|wumpus|petertodd: what is the worst that could happen if you accidentally run testnet?
204 2016-06-23 19:37:15	0|petertodd|wumpus: hard to know!
205 2016-06-23 19:37:40	0|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?
206 2016-06-23 19:37:44	0|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
207 2016-06-23 19:37:46	0|wumpus|at least the default ports etc will be different, default data dir is different, etc
208 2016-06-23 19:38:13	0|wumpus|petertodd: apart from GUI users I guess
209 2016-06-23 19:38:20	0|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.
210 2016-06-23 19:38:25	0|sipa|i believe this is a nit not worth minutes of discussion time
211 2016-06-23 19:38:26	0|petertodd|wumpus: yes, but imagine someone has an automated system setup which calls bitcoin-cli...
212 2016-06-23 19:38:41	0|gmaxwell|in any case, can be discussed later or not.
213 2016-06-23 19:38:42	0|gmaxwell|:)
214 2016-06-23 19:38:47	0|btcdrak|any more topics?
215 2016-06-23 19:40:07	0|jtimon|are we merging the bip9 activation parameters for testnet?
216 2016-06-23 19:40:28	0|CodeShark|hmm - I don't see the activation parameters for segwit on testnet
217 2016-06-23 19:40:39	0|CodeShark|how can it be live on testnet?
218 2016-06-23 19:40:54	0|jtimon|CodeShark: people running custom code I assume
219 2016-06-23 19:40:58	0|sipa|CodeShark: in the segwit branch
220 2016-06-23 19:41:03	0|jtimon|oh
221 2016-06-23 19:41:03	0|sipa|not in master
222 2016-06-23 19:41:20	0|btcdrak|CodeShark: it was activated months ago
223 2016-06-23 19:41:44	0|CodeShark|yes, but I'm still confused as to the release here
224 2016-06-23 19:41:59	0|CodeShark|shouldn't testnet only run stuff that's been merged?
225 2016-06-23 19:42:11	0|instagibbs3|bip 9 activation can still be set.
226 2016-06-23 19:42:13	0|btcdrak|no, we set the parameters
227 2016-06-23 19:42:26	0|gmaxwell|CodeShark: we wanted testing in a mixed enviroment with most nodes not upgraded.
228 2016-06-23 19:42:27	0|btcdrak|and that allowed a miner to activate it
229 2016-06-23 19:42:29	0|sipa|CodeShark: it was a very useful testing exercise
230 2016-06-23 19:42:32	0|gmaxwell|CodeShark: since thats realistic.
231 2016-06-23 19:42:49	0|gmaxwell|and segnet couldn't easily provide that.
232 2016-06-23 19:43:01	0|CodeShark|sure, I'm all for the additional testing - I'm just concerned about breaking the master builds for testnet
233 2016-06-23 19:43:10	0|gmaxwell|CodeShark: it's a softfork, hurrah.
234 2016-06-23 19:43:18	0|sipa|(although, there are so few testnet segwit nodes running right now that it really does not work without -addnode)
235 2016-06-23 19:43:19	0|jtimon|answer my own question: yes, the testnet activation is part of #7910 : https://github.com/bitcoin/bitcoin/pull/8149/files#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R191
236 2016-06-23 19:43:40	0|CodeShark|gmaxwell: yes, but it will still break miners. however, if no issues arose as a result I'm fine with it
237 2016-06-23 19:43:58	0|sipa|CodeShark: testnet miners are clearly already running it
238 2016-06-23 19:44:05	0|CodeShark|yes, indeed
239 2016-06-23 19:44:09	0|sipa|so how could merging break anything for them?
240 2016-06-23 19:44:20	0|CodeShark|nvm, all's good
241 2016-06-23 19:44:24	0|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)
242 2016-06-23 19:44:37	0|gmaxwell|er, wouldn't have been
243 2016-06-23 19:45:02	0|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.
244 2016-06-23 19:45:02	0|jtimon|it is the first time a softfork is activated on testnet before it is in master thought, right?
245 2016-06-23 19:45:14	0|gmaxwell|Are the testnet seeds running the code that can give filtered responses?
246 2016-06-23 19:45:17	0|sipa|indeed, and we can test the dns filtering
247 2016-06-23 19:45:23	0|sipa|gmaxwell: jonasschnelli's is
248 2016-06-23 19:45:27	0|sipa|not sure about petertodd's
249 2016-06-23 19:45:38	0|sipa|oh, yes
250 2016-06-23 19:45:50	0|sipa|https://github.com/bitcoin/bitcoin/pull/8204
251 2016-06-23 19:46:49	0|sipa|petertodd: are you sure that's running the filtering code?
252 2016-06-23 19:46:58	0|jtimon|gmaxwell: the "testnet only" builds are just from master after merging segwit, right?
253 2016-06-23 19:47:02	0|petertodd|sipa: should be
254 2016-06-23 19:47:02	0|sipa|jtimon: yes
255 2016-06-23 19:47:04	0|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.
256 2016-06-23 19:47:11	0|petertodd|sipa: I'll recheck
257 2016-06-23 19:47:15	0|sipa|x9.seed.tbtc.petertodd.org gives many results, more than i'd expect
258 2016-06-23 19:47:32	0|petertodd|sipa: note that it is running with extra args to support rbf
259 2016-06-23 19:47:40	0|gmaxwell|jtimon: yes, likely with a trivial patch to change it to default to testnet (or require it). (and maybe a renamed binary)
260 2016-06-23 19:47:42	0|petertodd|sipa: so maybe there's a bug there that you haven't run into yet
261 2016-06-23 19:48:16	0|sipa|petertodd: can i see the code for that?
262 2016-06-23 19:48:25	0|jtimon|gmaxwell: why the changes? aren't this power users?
263 2016-06-23 19:48:33	0|sipa|after the meeting, please
264 2016-06-23 19:48:44	0|petertodd|sipa: it's with the command line arg; which incidentlaly was broken when I tried it (see my pullreq)
265 2016-06-23 19:49:03	0|gmaxwell|any other topics for this meeting?
266 2016-06-23 19:49:31	0|wumpus|doesn't seem so
267 2016-06-23 19:49:58	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.log.html
268 2016-06-23 19:49:58	0|lightningbot|Meeting ended Thu Jun 23 19:49:58 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
269 2016-06-23 19:49:58	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.html
270 2016-06-23 19:49:58	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-23-19.02.txt
271 2016-06-23 19:49:58	0|wumpus|#endmeeting
272 2016-06-23 19:50:23	0|sipa|petertodd: are you including -w 9 ?
273 2016-06-23 19:50:36	0|jtimon|oh, I think we forgot to make a joke, that's bad for the summaries :p
274 2016-06-23 19:51:04	0|btcdrak|there is plenty comic relief there
275 2016-06-23 19:51:07	0|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.
276 2016-06-23 19:51:16	0|petertodd|sipa: yeah, I think so
277 2016-06-23 19:51:46	0|btcdrak|wumpus: so is segwit is the last feature PR and now 0.13 is frozen?
278 2016-06-23 19:51:55	0|gmaxwell|segwit is not a feature PR
279 2016-06-23 19:52:04	0|gmaxwell|and 0.13 has been frozen for a bit now.
280 2016-06-23 19:52:12	0|wumpus|as gmaxwell says ^^
281 2016-06-23 19:52:16	0|btcdrak|fine
282 2016-06-23 19:52:28	0|gmaxwell|(it's especially not a feature PR with it not yet activated in mainnet. :) )
283 2016-06-23 19:52:30	0|jtimon|gmaxwell: whatever, the patch to change the default and/or disable mainnet should be trivial anyway
284 2016-06-23 19:52:52	0|sipa|i'd be perfectly fine with that binary also supporting mainnet
285 2016-06-23 19:52:59	0|gmaxwell|jtimon: yup. if it were hard I wouldn't have suggsted it. I think it's useful but not of great importance.
286 2016-06-23 19:53:35	0|jtimon|I think I disagree with the notion that "the segwit PR is not a feature"
287 2016-06-23 19:53:38	0|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).
288 2016-06-23 19:53:56	0|gmaxwell|jtimon: I feel sorry for you then?  It's not even exposed in 0.13 as merged.
289 2016-06-23 19:54:35	0|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
290 2016-06-23 19:54:53	0|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)
291 2016-06-23 19:55:06	0|jtimon|gmaxwell: precisely I thought the "softforks are minor releases" applied to the activation, not to the inactive code
292 2016-06-23 19:55:32	0|gmaxwell|jtimon: sure though inactive code is not a feature either.
293 2016-06-23 19:55:50	0|CodeShark|if it includes the testnet code I'd argue it is a feature
294 2016-06-23 19:55:53	0|gmaxwell|wumpus: that would be fantastic, and would radically increase the use of testnet, I expect.
295 2016-06-23 19:56:08	0|gmaxwell|CodeShark: A feature for testnet. ooohkay.
296 2016-06-23 19:56:26	0|gmaxwell|I don't disagree but I don't think the distinction is important.
297 2016-06-23 19:56:50	0|gmaxwell|Testnet is not very serious, as much as I'd like it to be more serious. It's often pretty broken.
298 2016-06-23 19:57:29	0|CodeShark|going forward, as long as activation parameters for testnet softforks are documented somewhere and we agree on them it seems ok
299 2016-06-23 19:57:59	0|btcdrak|CodeShark: they are already documented: https://github.com/bitcoin/bips/blob/master/bip-0009/assignments.mediawiki
300 2016-06-23 19:57:59	0|gmaxwell|Not sure how you missed the couple weeks of discussion about segwit in testnet before.
301 2016-06-23 19:58:21	0|CodeShark|I remember the discussion - I just wasn't clear on the release cycle as it pertains to testnet
302 2016-06-23 19:58:55	0|jtimon|yeah, I think that's the source of the discussion
303 2016-06-23 19:58:57	0|btcdrak|there is no release cycle. miners can apply whatever sfs they like at any time
304 2016-06-23 19:59:14	0|jtimon|not saying necessarily the new method is worse, but it has changed
305 2016-06-23 19:59:34	0|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.
306 2016-06-23 19:59:42	0|jtimon|well, "release cycle", "modus operandi", whatever
307 2016-06-23 19:59:48	0|wumpus|I don't think the distinction is important either
308 2016-06-23 19:59:59	0|wumpus|we just need segwit out, and everything that helps the testing and review process is great
309 2016-06-23 20:00:05	0|gmaxwell|(e.g. you didn't see any of us howling about release cycle when jtoomim was using the XT hardfork on it)
310 2016-06-23 20:00:18	0|wumpus|we're not goingn to block segwit on a procedural detail
311 2016-06-23 20:00:19	0|btcdrak|jtimon: there isnt a release cycle. The consensus rules of the network are not defined by a release cycle of software
312 2016-06-23 20:00:39	0|btcdrak|gmaxwell: exactly
313 2016-06-23 20:00:42	0|gmaxwell|as btcdrak said.
314 2016-06-23 20:01:23	0|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.
315 2016-06-23 20:01:45	0|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
316 2016-06-23 20:01:48	0|gmaxwell|esp when the thing we're trying to test is deployment of a feature in a non-upgraded network. :)
317 2016-06-23 20:02:04	0|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
318 2016-06-23 20:02:18	0|sipa|CodeShark: there have been proposals in the past for having multiple testnetd
319 2016-06-23 20:02:31	0|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.
320 2016-06-23 20:02:48	0|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
321 2016-06-23 20:02:52	0|gmaxwell|and if they were, we could easily move more disruptive things to other testnets.
322 2016-06-23 20:03:08	0|jtimon|btcdrak: ack
323 2016-06-23 20:03:38	0|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)
324 2016-06-23 20:04:03	0|wumpus|jtimon: sure, I just get crazy from all the time pressure and all the different things that pop up
325 2016-06-23 20:04:23	0|wumpus|jtimon: I don't have much trust in anything ever being done the 'ideal' way :-)
326 2016-06-23 20:04:27	0|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)
327 2016-06-23 20:04:37	0|jtimon|wumpus: not regreting anything rewarding segwit
328 2016-06-23 20:04:39	0|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
329 2016-06-23 20:05:02	0|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. :)
330 2016-06-23 20:05:06	0|wumpus|jtimon: well the critical thing is that segwit is reviewed and tested enough, that there are no technical concerns with merging it
331 2016-06-23 20:05:08	0|CodeShark|not sure it's necessary to test on testnet itself
332 2016-06-23 20:05:12	0|CodeShark|at least for an application developer
333 2016-06-23 20:05:19	0|CodeShark|although there is a benefit to us
334 2016-06-23 20:05:20	0|gmaxwell|er after dersig was released.
335 2016-06-23 20:05:20	0|jtimon|wumpus: ack
336 2016-06-23 20:05:23	0|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
337 2016-06-23 20:05:53	0|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.
338 2016-06-23 20:05:57	0|sipa|well, maybe having a windows desktop shortcut for testnet makes it more visible and attractive to test on
339 2016-06-23 20:06:06	0|gmaxwell|E.g. left to their own devices reorg handling may be compeltely untested.
340 2016-06-23 20:06:21	0|gmaxwell|also testnet is useful for interworking tests between multiple implementations.
341 2016-06-23 20:06:39	0|sipa|i would love to see an actually operational test network, where you can try sending from testnet bitgo to testnet bitawesomewallet or something
342 2016-06-23 20:06:44	0|jtimon|wumpus: that's perfect. I'm not criticizing. Just wondering if things can be done EVEN better
343 2016-06-23 20:06:48	0|gmaxwell|I've joked before, but really seriously, that someone should setup a dumb gambling thing on testnet.
344 2016-06-23 20:07:13	0|gmaxwell|I spent much of 2012 begging services to setup testnet instances of themselves with play money, without much luck.
345 2016-06-23 20:07:32	0|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
346 2016-06-23 20:07:48	0|wumpus|the only services that exist for testnet seem to be some block explorers, also mostly broken
347 2016-06-23 20:08:26	0|wumpus|I think regtest made it too attractive to set up internal testing networks :-)
348 2016-06-23 20:08:40	0|wumpus|jtimon: agree, there's always room for improvement
349 2016-06-23 20:08:44	0|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
350 2016-06-23 20:09:01	0|wumpus|testnet has 'more features', e.g. no standardness
351 2016-06-23 20:09:05	0|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.
352 2016-06-23 20:09:20	0|CodeShark|with regtest you can definitely do more rigorous testing - given you have programs that can simulate network conditions on it
353 2016-06-23 20:09:27	0|gmaxwell|jtimon: softforks have pretty much always activated first on testnet.
354 2016-06-23 20:09:48	0|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. :)
355 2016-06-23 20:10:11	0|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
356 2016-06-23 20:10:25	0|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.
357 2016-06-23 20:10:29	0|wumpus|gmaxwell: (not that that kind of testing isn't useful, but it just isn't very popular)
358 2016-06-23 20:10:56	0|wumpus|it requires people actually paying attention on the fly :)
359 2016-06-23 20:11:25	0|gmaxwell|unpredictablity of blocktimes on testnet has not helpped for application testing.
360 2016-06-23 20:11:51	0|wumpus|also unrealistic reorgs
361 2016-06-23 20:12:57	0|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.
362 2016-06-23 20:12:58	0|wumpus|whole runs of difficulty-1 blocks that are reorged away suddenly
363 2016-06-23 20:13:12	0|btcdrak|there is no incentive to mine on testnet. that is the main issue
364 2016-06-23 20:13:32	0|wumpus|btcdrak: right - if there was, then testnet coins would have a value
365 2016-06-23 20:13:46	0|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.
366 2016-06-23 20:15:00	0|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.
367 2016-06-23 20:15:24	0|btcdrak|gmaxwell: i like the idea of testnet block signers.
368 2016-06-23 20:15:27	0|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.
369 2016-06-23 20:15:56	0|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.
370 2016-06-23 20:17:03	0|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
371 2016-06-23 20:17:16	0|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.
372 2016-06-23 20:17:45	0|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
373 2016-06-23 20:17:47	0|gmaxwell|CodeShark: its mostly not used for that. The most use it gets is breaking secondary implementations.
374 2016-06-23 20:18:27	0|gmaxwell|halariously, there is one of these "messaging via the blockchain" spammy things that uses testnet for production.
375 2016-06-23 20:18:59	0|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.
376 2016-06-23 20:19:29	0|jtimon|sorry, was afk
377 2016-06-23 20:19:51	0|helo|god forbid they form their own relay network that actually fits their use case
378 2016-06-23 20:20:10	0|btcdrak|helo: they are too lazy.
379 2016-06-23 20:20:19	0|gmaxwell|It's complicated.
380 2016-06-23 20:22:15	0|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'
381 2016-06-23 20:22:21	0|gmaxwell|m certantly not out going to make some custom network for some crazy app dejure (unless they're going to pay...)
382 2016-06-23 20:22:21	0|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)
383 2016-06-23 20:22:34	0|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
384 2016-06-23 20:23:28	0|jtimon|gmaxwell: well, we could maintain a single-element (ie block signing) chain in elements...
385 2016-06-23 20:24:10	0|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.
386 2016-06-23 20:24:14	0|CodeShark|gmaxwell: even if they're going to pay you probably have better things to do ;)
387 2016-06-23 20:24:20	0|gmaxwell|helo: so I think thats one component of the blockchain hype.
388 2016-06-23 20:25:05	0|gmaxwell|jtimon: yes, and a seperate network that used just that and was otherwise the same as bitcoin testnet
389 2016-06-23 20:25:40	0|jtimon|yes
390 2016-06-23 20:26:49	0|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.
391 2016-06-23 20:27:13	0|btcdrak|permissioned testnet :)
392 2016-06-23 20:27:54	0|jtimon|gmaxwell: interesting thought
393 2016-06-23 20:28:02	0|sipa|yow
394 2016-06-23 20:28:41	0|helo|yeah, that sounds about right...
395 2016-06-23 20:30:13	0|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
396 2016-06-23 20:30:19	0|gmaxwell|have the background/time/interest to go build a regtest test harness.
397 2016-06-23 20:30:22	0|gmaxwell|I can tell you that a lot of bitcoin services have no reorg handling at all. :(
398 2016-06-23 20:34:09	0|da2ce7_mobile|has something happened to sipa's node, or the BIP9 chart looking very werid: http://bitcoin.sipa.be/ver9-2k.png
399 2016-06-23 20:34:18	0|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
400 2016-06-23 20:34:25	0|CodeShark|correct?
401 2016-06-23 20:34:31	0|gmaxwell|CodeShark: no.
402 2016-06-23 20:34:35	0|btcdrak|urgh
403 2016-06-23 20:34:39	0|btcdrak|I PMd him
404 2016-06-23 20:34:56	0|gmaxwell|there is nothing weird about it.
405 2016-06-23 20:35:30	0|da2ce7_mobile|I was expecting the CSV flags to drop straight down to zero.
406 2016-06-23 20:35:38	0|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.
407 2016-06-23 20:35:57	0|sipa|da2ce7_mobile: BIP9 suggests that they don't
408 2016-06-23 20:36:07	0|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.
409 2016-06-23 20:36:08	0|sipa|da2ce7_mobile: and that they keep setting the flag during the locked_in phase
410 2016-06-23 20:36:23	0|da2ce7_mobile|:(
411 2016-06-23 20:36:40	0|sipa|why :(
412 2016-06-23 20:36:58	0|gmaxwell|presumably that was to the manual setting of bits.
413 2016-06-23 20:37:02	0|da2ce7_mobile|well it would be better if they followed the protocol.
414 2016-06-23 20:37:41	0|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.
415 2016-06-23 20:37:59	0|sipa|da2ce7_mobile: the difference between theory and practice is that there is none in theory
416 2016-06-23 20:38:12	0|gmaxwell|"Bit 1 activate"  "set hyperdrive to on" "engage flanx warbler" "Bit 1 deactivate"
417 2016-06-23 20:38:31	0|sipa|check sequence verify!
418 2016-06-23 20:38:38	0|da2ce7_mobile|:D :D
419 2016-06-23 20:38:42	0|sipa|median time: set to past
420 2016-06-23 20:39:23	0|gmaxwell|haha   "reorganize! everybody shake!"
421 2016-06-23 20:40:21	0|da2ce7_mobile|Ok. It look like that CSV could be a bit of a bumpy ride when activating.
422 2016-06-23 20:40:26	0|gmaxwell|da2ce7_mobile: huh?
423 2016-06-23 20:40:28	0|sipa|set activation threshold to 95%
424 2016-06-23 20:40:33	0|gmaxwell|da2ce7_mobile: not at all.
425 2016-06-23 20:40:54	0|btcdrak|da2ce7_mobile: activation is now certain and we know which block it will occur on
426 2016-06-23 20:40:57	0|Lightsword|is it only eloipool based pools that manually set the version?
427 2016-06-23 20:41:20	0|da2ce7_mobile|well if the bits are not being auto-unset then that suggests that the miners haven't upgraded their nodes.
428 2016-06-23 20:41:23	0|btcdrak|Lightsword: no. we have contacted the pools who do.
429 2016-06-23 20:41:31	0|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).
430 2016-06-23 20:41:50	0|btcdrak|da2ce7_mobile: not at all. it just means they set the bit manually, against our advice.
431 2016-06-23 20:42:12	0|da2ce7_mobile|ok. well in that case I'm less worried.
432 2016-06-23 20:42:12	0|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.
433 2016-06-23 20:42:17	0|btcdrak|it's explained here: https://bitcoincore.org/en/2016/06/08/version-bits-miners-faq/
434 2016-06-23 20:42:36	0|btcdrak|and also here: https://bitcoincore.org/en/2016/06/21/csv-softfork-instructions/
435 2016-06-23 20:42:53	0|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.
436 2016-06-23 20:44:32	0|da2ce7_mobile|ok :)  you guys are way ahead of me.  Colour me impressed (yet again).
437 2016-06-23 20:44:47	0|gmaxwell|in any case, "we've (hopefully) got this"
438 2016-06-23 20:44:48	0|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
439 2016-06-23 20:45:01	0|gmaxwell|I was irritated to find people were still manually overriding it.
440 2016-06-23 20:45:05	0|gmaxwell|Lightsword: take the version from the template.
441 2016-06-23 20:45:18	0|btcdrak|Lightsword: chat with jl2012, he said he found a solution for one of the pools at least
442 2016-06-23 20:46:10	0|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...
443 2016-06-23 20:46:38	0|da2ce7_mobile|I really like BIP9. It is a really elegant solution and upgrade.
444 2016-06-23 20:46:40	0|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.
445 2016-06-23 20:49:23	0|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. :)
446 2016-06-23 20:50:01	0|sipa|da2ce7_mobile: thanks :)
447 2016-06-23 20:50:37	0|sipa|(and thank everyone who's helping... i didn't even write the majority of the code)