1 2016-10-27T00:00:01 <gmaxwell> Eligius 0.589615
2 2016-10-27T00:00:04 <gmaxwell> Telco 0.709605
3 2016-10-27T00:01:18 <TD-Linux> gmaxwell, well 0.246 btc loss is directly proportional to their block size
4 2016-10-27T00:02:05 *** Chris_Stewart_5 has quit IRC
5 2016-10-27T00:02:19 <gmaxwell> Indeed.
6 2016-10-27T00:02:30 <Lightsword> gmaxwell, do you have stats on kanoâs ckpool and ckâs solopool?
7 2016-10-27T00:02:41 <TD-Linux> also I don't think there's really enough samples there to draw a conclusion. would be neat to automate this though.
8 2016-10-27T00:03:11 <gmaxwell> they didn't fine a block in the union of my and btcdrak's observation windows. I have mempool data for 435976 to now.
9 2016-10-27T00:03:14 *** Chris_Stewart_5 has joined #bitcoin-core-dev
10 2016-10-27T00:03:14 <gmaxwell> s/fine/find/
11 2016-10-27T00:04:48 <sipa> gmaxwell: over how many blocks is this data?
12 2016-10-27T00:04:48 <gmaxwell> 67
13 2016-10-27T00:05:12 <gmaxwell> here is the max from that data, BitClub -0.00042054 HaoBTC 0.03818631 BitFury 0.05457683 BTC.com 0.07372295 SlushPool 0.09595818 BTCC 0.09886828 ViaBTC 0.11170776 F2Pool 0.12080682 Bitcoin.com 0.12846755 AntPool 0.14341536 Unknown 0.16687057 BW.COM 0.18705609 GBMiners 0.24633568 Telco 0.709605 Eligius 1.03414
14 2016-10-27T00:05:43 <gmaxwell> I can also estimate mining process latency from this. I'm saving the fees for my gbt every 10 seconds.
15 2016-10-27T00:06:24 <gmaxwell> e.g. "you mined fees consistent with forming your block 30 seconds ago"
16 2016-10-27T00:18:48 *** PRab has quit IRC
17 2016-10-27T00:19:19 *** a_meteorite has quit IRC
18 2016-10-27T00:39:42 *** fengling has quit IRC
19 2016-10-27T00:47:06 *** Ylbam_ has quit IRC
20 2016-10-27T01:00:18 *** echonaut has quit IRC
21 2016-10-27T01:00:43 *** echonaut has joined #bitcoin-core-dev
22 2016-10-27T01:00:44 *** randy-waterhouse has quit IRC
23 2016-10-27T01:04:21 *** randy-waterhouse has joined #bitcoin-core-dev
24 2016-10-27T01:04:30 *** randy-waterhouse has joined #bitcoin-core-dev
25 2016-10-27T01:14:16 <jeremyrubin> gmaxwell: can you normalize by block size?
26 2016-10-27T01:25:12 <midnightmagic> I'm going to regen the entire build instead of modifying the .assert in place to be able to say I ran it plus gverify against the other two sigs in there, michagogo et al
27 2016-10-27T01:25:26 <midnightmagic> sorry for the mixup
28 2016-10-27T01:32:27 <gmaxwell> jeremyrubin: okay, I added two columns, one is my mempool fees sscaled to the actual block size, the next is the difference.
29 2016-10-27T01:32:59 <gmaxwell> which now shows the small blocks as slightly negative, which makes sense, since they took the highest fee txn.
30 2016-10-27T01:33:13 *** randy-waterhouse has quit IRC
31 2016-10-27T01:42:02 <luke-jr> gmaxwell: that looks like the fallback where Eloipool has to guess the template itself until GBT completes
32 2016-10-27T01:42:18 <luke-jr> it's supposed to be based on the previous valid template, not sure what's going wrong there
33 2016-10-27T01:45:51 *** DigiByteDev has joined #bitcoin-core-dev
34 2016-10-27T01:46:17 *** randy-waterhouse has joined #bitcoin-core-dev
35 2016-10-27T01:46:51 *** randy-waterhouse has joined #bitcoin-core-dev
36 2016-10-27T01:55:10 <gmaxwell> luke-jr: fix.
37 2016-10-27T02:07:50 *** fengling has joined #bitcoin-core-dev
38 2016-10-27T02:19:35 *** Giszmo has quit IRC
39 2016-10-27T02:20:44 *** randy-waterhouse has quit IRC
40 2016-10-27T02:26:22 *** PRab has joined #bitcoin-core-dev
41 2016-10-27T02:27:09 *** tulip has joined #bitcoin-core-dev
42 2016-10-27T02:37:10 *** PRab has quit IRC
43 2016-10-27T02:55:57 *** fengling has quit IRC
44 2016-10-27T03:11:23 *** PRab has joined #bitcoin-core-dev
45 2016-10-27T03:26:18 *** midnightmagic has quit IRC
46 2016-10-27T03:28:23 *** Chris_Stewart_5 has quit IRC
47 2016-10-27T03:34:33 *** jtimon has quit IRC
48 2016-10-27T03:45:22 *** midnightmagic has joined #bitcoin-core-dev
49 2016-10-27T03:51:04 <luke-jr> gmaxwell: looks like it was in wizkid057's GBT proxy thing.. [03:34:24] <wizkid057> oh, I never commited that to the production server
50 2016-10-27T03:51:05 <luke-jr> >_<
51 2016-10-27T04:18:09 *** a_meteorite has joined #bitcoin-core-dev
52 2016-10-27T04:21:13 *** a_meteorite has quit IRC
53 2016-10-27T04:21:40 *** a_meteorite has joined #bitcoin-core-dev
54 2016-10-27T04:32:27 *** aalex has quit IRC
55 2016-10-27T04:32:47 *** aalex has joined #bitcoin-core-dev
56 2016-10-27T04:42:41 *** nickler has quit IRC
57 2016-10-27T04:48:12 *** d_t has quit IRC
58 2016-10-27T04:53:27 *** nickler has joined #bitcoin-core-dev
59 2016-10-27T05:10:08 *** tulip has quit IRC
60 2016-10-27T05:25:36 *** DigiByteDev has quit IRC
61 2016-10-27T05:30:11 *** harrymm has quit IRC
62 2016-10-27T05:34:21 <whphhg> Sup blockstream
63 2016-10-27T05:35:08 *** fengling has joined #bitcoin-core-dev
64 2016-10-27T05:44:10 *** harrymm has joined #bitcoin-core-dev
65 2016-10-27T05:45:57 *** DigiByteDev has joined #bitcoin-core-dev
66 2016-10-27T05:50:36 *** wasi has quit IRC
67 2016-10-27T05:50:43 *** d_t has joined #bitcoin-core-dev
68 2016-10-27T05:55:12 *** d_t has quit IRC
69 2016-10-27T06:11:20 <GitHub7> [bitcoin] laanwj closed pull request #9022: Update release notes to mention dropping OS X 10.7 support (0.13...0-13-1-osx-notes) https://github.com/bitcoin/bitcoin/pull/9022
70 2016-10-27T06:11:22 <GitHub177> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/a32d7c23fc0e...03422e564b55
71 2016-10-27T06:11:22 <GitHub177> bitcoin/0.13 1d12463 Michael Ford: Update release notes for dropping osx 10.7 support
72 2016-10-27T06:11:23 <GitHub177> bitcoin/0.13 03422e5 Wladimir J. van der Laan: Merge #9022: Update release notes to mention dropping OS X 10.7 support...
73 2016-10-27T06:15:31 *** a_meteorite has quit IRC
74 2016-10-27T06:21:03 <wumpus> would be interesting to check this against univalue http://seriot.ch/parsing_json.html
75 2016-10-27T06:22:38 <jonasschnelli> wumpus: heh. Yes. Someone should turn this into unit-tests.
76 2016-10-27T06:22:44 <jonasschnelli> Maybe open an easy-to-implement issue?
77 2016-10-27T06:22:53 <jonasschnelli> though not sure how easy it is.
78 2016-10-27T06:23:36 <wumpus> it seems pretty straightforward to run the tests, if the files + results are available. Fixing the discovered issues is proably far from easy-to-implement :)
79 2016-10-27T06:24:18 <jonasschnelli> Indeed...
80 2016-10-27T06:24:58 <wumpus> but even without that it'd be interesting to see how it compares
81 2016-10-27T06:26:19 <wumpus> hopefully there's nothing in the "parser crashed" category, we've done quite a lot of fuzzing
82 2016-10-27T06:29:04 *** a_meteorite has joined #bitcoin-core-dev
83 2016-10-27T06:31:00 <jonasschnelli> I'm glad all JSON operations are hidden behind the HTTP Auth...
84 2016-10-27T06:31:11 <jonasschnelli> With rest it gets a bit more risky...
85 2016-10-27T06:31:42 <wumpus> I've purposedly kept JSON parsing out of REST
86 2016-10-27T06:31:50 <wumpus> just simple query strings
87 2016-10-27T06:32:33 <jonasschnelli> Ah. Right. Only output.
88 2016-10-27T06:33:23 <wumpus> output far from as much of a risk as parsing
89 2016-10-27T06:33:27 <wumpus> +is
90 2016-10-27T06:33:46 <wumpus> still possible for there to be bugs there, but much less scope for trickery
91 2016-10-27T06:35:54 *** DigiByteDev has quit IRC
92 2016-10-27T06:36:18 *** DigiByteDev has joined #bitcoin-core-dev
93 2016-10-27T06:36:27 <btcdrak> btw this is the issue I found with Univalue https://github.com/jgarzik/univalue/pull/29 - wasted quite a few hours trying to work out why some tests were failing because of this.
94 2016-10-27T06:38:00 <btcdrak> oh, I see wumpus found the PR already :-)
95 2016-10-27T06:38:38 <wumpus> https://github.com/bitcoin/bitcoin/issues/9028
96 2016-10-27T06:38:57 <wumpus> btcdrak: if tests are failing due to a trailing space you're doing comparison in the wrong domain
97 2016-10-27T06:39:21 <wumpus> I agree with your pull request but not that it should cause (non-JSON-pedanticness) tests to fail :)
98 2016-10-27T06:41:35 <wumpus> but I'd say, to compare two json documents: parse them and compare the underlying data. Don't compare pretty-printed representations
99 2016-10-27T06:43:24 *** Ylbam_ has joined #bitcoin-core-dev
100 2016-10-27T06:45:31 <btcdrak> wumpus: well we have tests that compare the json output of "./bitcoin-tx -json ..." with a json file. trailing white space can get trimmed by IDE/editor settings. Trailing white space has no place in a json file. If it wasnt for that nice "log errors as diff" patch to bitcoin-unit-test.py submitted yesterday I would have lost my mind.
101 2016-10-27T06:46:27 <wumpus> I understand, but there is no standard way to pretty-print JSON
102 2016-10-27T06:46:48 <wumpus> having the tests depend on how the jSON lib happens to do pretty printing is fragile
103 2016-10-27T06:47:05 <wumpus> ideally the tests should compare the data, not the text
104 2016-10-27T06:48:36 <btcdrak> yes, I agree.
105 2016-10-27T06:49:59 <wumpus> I think we have some similar problems in other places, which complicated switching JSON libraries last time
106 2016-10-27T06:50:30 <wumpus> not a huge proiority to change ofcourse
107 2016-10-27T06:50:44 <btcdrak> but while indentation may not have a standard, I think trailing whitespace has no place in any output.
108 2016-10-27T06:50:57 *** DigiByteDev has quit IRC
109 2016-10-27T06:51:48 <luke-jr> but what if you want to embed a Whitespace program? :p
110 2016-10-27T06:51:55 <wumpus> as I said I agree with your PR, I don't think emitting trailing whitespace is desirable, but if it causes test failures that points at a deeper issue
111 2016-10-27T06:52:21 <btcdrak> yup
112 2016-10-27T06:52:26 <wumpus> next time the problem may be the other way around, someone accidentally adds trailing whitespace to the example and the test fails
113 2016-10-27T06:52:45 <wumpus> and spend hours debugging that problem instead of something that matters :)
114 2016-10-27T06:53:12 <wumpus> luke-jr: ah yes, white-space steganogrpaphy
115 2016-10-27T06:53:28 <btcdrak> haha yes.
116 2016-10-27T06:53:29 <btcdrak> well again, I found changing a 1 to a 2 isnt that straight forward....
117 2016-10-27T06:53:49 <btcdrak> wumpus: can you restart https://travis-ci.org/bitcoin/bitcoin/builds/170827031, dunno why Travis borked
118 2016-10-27T06:53:57 *** BashCo has quit IRC
119 2016-10-27T06:54:19 <luke-jr> wumpus: do you have any expectation of further merges before tagging?
120 2016-10-27T06:54:38 <wumpus> luke-jr: if there are further improvements to the release notes
121 2016-10-27T06:55:41 <wumpus> otherwise, no
122 2016-10-27T07:04:03 *** dcousens has joined #bitcoin-core-dev
123 2016-10-27T07:06:17 <jonasschnelli> Do we follow a code-convention for instance variables? I guess we don't want this->var? Also, the prefixes (mapX, fX, etc.) are also used for non instance vars. What about using _Var for instance variables? Acceptable?
124 2016-10-27T07:06:33 <jonasschnelli> s/_Var/_var
125 2016-10-27T07:07:52 <luke-jr> I'd rather 'var' than '_var' for public stuff at least
126 2016-10-27T07:08:04 <luke-jr> I don't see a problem with o->var or o->fVar
127 2016-10-27T07:08:20 *** wasi has joined #bitcoin-core-dev
128 2016-10-27T07:15:30 <jonasschnelli> Luke-Jr: my problems is, that the code is really not easy readable if you don't highlight instance variable in some form.
129 2016-10-27T07:15:52 <jonasschnelli> this-> clusters to code to much IMO, ... using _var seems acceptable to me.
130 2016-10-27T07:16:19 <jonasschnelli> Using fVar, etc. will not increase readability because we are also using this for non-instance vars (function parameters, etc.)
131 2016-10-27T07:16:24 <luke-jr> we're already using _var for local variables to avoid shadowing :/
132 2016-10-27T07:17:14 <jonasschnelli> argh... I though we are using _var for instance vars to avoid shadowing... do we also use _var in local scope?!
133 2016-10-27T07:17:45 <luke-jr> I didn't look at all cases explicitly, but when I encountered merge conflicts due to the shadowing changes, _var was always the local scope
134 2016-10-27T07:20:00 *** Samdney has joined #bitcoin-core-dev
135 2016-10-27T07:21:40 *** d_t has joined #bitcoin-core-dev
136 2016-10-27T07:22:18 *** d_t has joined #bitcoin-core-dev
137 2016-10-27T07:26:06 *** BashCo has joined #bitcoin-core-dev
138 2016-10-27T07:29:11 <wumpus> no, we have no naming convention for instance variables, just use whatever makes sense in the context
139 2016-10-27T07:29:58 <jonasschnelli> I personally like this-> but I know most people don't like that
140 2016-10-27T07:30:05 <jonasschnelli> I'll try _
141 2016-10-27T07:30:11 <wumpus> at least the qt coding convention recommends against using m_ or _ or such
142 2016-10-27T07:31:08 <jonasschnelli> The m prefix would not allow to use the fVar, etc. prefix.
143 2016-10-27T07:31:15 <jonasschnelli> mfBool would look strange. :)
144 2016-10-27T07:31:19 <jonasschnelli> i'd prefere _fBool
145 2016-10-27T07:31:23 <wumpus> m_fBool that would be, then
146 2016-10-27T07:31:27 *** Samdney has quit IRC
147 2016-10-27T07:31:31 <jonasschnelli> m_ yes... why not
148 2016-10-27T07:31:57 <sipa> wumpus: what does the qt coding convention suggest?
149 2016-10-27T07:32:13 <wumpus> sipa: no specific one, just use this->name where necessary
150 2016-10-27T07:32:34 <wumpus> in many cases there's no need to name instance variables any differently from local variables
151 2016-10-27T07:33:04 <jonasschnelli> wumpus: readability?
152 2016-10-27T07:33:06 <sipa> luke-jr: where do we use _var for local variables?
153 2016-10-27T07:33:08 <wumpus> e.g. https://forum.qt.io/topic/150/member-variable-naming-convention-in-qt-and-the-qtdn-wiki
154 2016-10-27T07:33:36 <wumpus> jonasschnelli: I think usually it should be clear from the context what is a member variable and what is not, there's not much of a need to flag them
155 2016-10-27T07:33:45 <sipa> luke-jr: underscores are used in several places for formal parameters to avoid colliding with field variables
156 2016-10-27T07:33:48 <wumpus> but I don't know, I hate these kind of discussions
157 2016-10-27T07:33:59 <jonasschnelli> Reading through new code i often found myself checking if the variable is local or instance-wide
158 2016-10-27T07:34:00 <sipa> haha
159 2016-10-27T07:34:04 <jonasschnelli> heh
160 2016-10-27T07:34:36 <sipa> jonasschnelli: if the function body is not too long, it's usually pretty easy to see if there is a local variable with that name
161 2016-10-27T07:34:48 <jonasschnelli> sipa: yes. If. now open main.cpp. :)
162 2016-10-27T07:34:55 <wumpus> jonasschnelli: that probably means the code itself is badly commented / structured
163 2016-10-27T07:35:15 <wumpus> a shallow 'fix' like renaming instance variables won't help much in that case except check a checkbox
164 2016-10-27T07:36:30 <sipa> jonasschnelli: so help refactoring those functions to be morw readable :)
165 2016-10-27T07:36:33 <wumpus> the superlative of adding metadata into variable names is something crazy like Hungarian notation, and I don't think that makes code anything easier to read
166 2016-10-27T07:37:02 <wumpus> it's the typical pointy-haired boss solution to
167 2016-10-27T07:37:06 <wumpus> "code is unreadable"
168 2016-10-27T07:37:10 <wumpus> FORCE a coding style!
169 2016-10-27T07:37:57 <wumpus> now you have nicely formatted ununderstandable code :)
170 2016-10-27T07:38:18 <sipa> i realize that i know what pointy-haired-boss means in the context of dilbert, but not in real life. Do posses have pointy hair stereotypically?
171 2016-10-27T07:38:22 *** nanotube has quit IRC
172 2016-10-27T07:38:32 <gmaxwell> if style differences are making code much less readable for you, sounds like an oppturnity to refine your reading skills. :) -- there are obviously extreme examples, codebases that mangle everything with macros and other insanity. :P But really, a casual approach is best.
173 2016-10-27T07:39:16 <wumpus> sipa: I don't think so, it's just the dilbert stereotype, it doesn't have anything to do with hair :-)
174 2016-10-27T07:41:01 <dcousens> gmaxwell: certainly syntax can get in the way, but, majority of the time, readability is more about a reduction in complexity than consistently spacing things.
175 2016-10-27T07:41:17 <dcousens> improving readability*
176 2016-10-27T07:41:31 *** d_t has quit IRC
177 2016-10-27T07:41:52 <wumpus> sipa: I think the gist is doing something for the sake of it being easy to enforce/check something, because the boss feels more in control that way and it superficiously looks like progress
178 2016-10-27T07:42:15 <gmaxwell> I wondered if perhaps PHB predated dilbert and dilbert was riffing off it, ... but I'd forgotten how old dilber is .. (1980-04)
179 2016-10-27T07:43:00 *** whphhg has left #bitcoin-core-dev
180 2016-10-27T07:44:05 *** nanotube has joined #bitcoin-core-dev
181 2016-10-27T07:44:26 <wumpus> now we've done it, we're slacking off and discussing dilbert, we should come up with a business metric for IRC messages and employees should be rated on the number of on-topic IRC messages </s>
182 2016-10-27T07:46:08 *** wasi has quit IRC
183 2016-10-27T07:47:26 <wumpus> time to tag 0.13.1 final?
184 2016-10-27T07:47:49 <sipa> i'm about to fall asleep
185 2016-10-27T07:48:04 <wumpus> I'll wait until you're asleep then
186 2016-10-27T07:48:08 <dcousens> ha
187 2016-10-27T07:48:33 * sipa goes into ACPI standby
188 2016-10-27T07:48:38 <wumpus> NN
189 2016-10-27T07:59:57 <gmaxwell> wumpus: all we need to is train some machine learning to read IRC and correlate that with commits, assigning score to IRC messages that come shortly before more commits.
190 2016-10-27T08:00:33 <gmaxwell> After we make the high scoreholder, Github151, in charge of the project I'm sure things will run much better.
191 2016-10-27T08:00:49 <gmaxwell> FWIW, my testing with RC3 all looks fine.
192 2016-10-27T08:01:28 <wumpus> hahahaa yes Github151 for president
193 2016-10-27T08:03:11 * luke-jr ponders writing-in Github151 on his ballot
194 2016-10-27T08:05:06 <gmaxwell> many states require a write in candidate register with them before being eligible to be counted. :(
195 2016-10-27T08:05:27 *** moli has quit IRC
196 2016-10-27T08:05:40 <luke-jr> I was joking anyway :p
197 2016-10-27T08:05:51 <gmaxwell> I think this is intended to help avoid "Which John Smith did we just elect?"
198 2016-10-27T08:06:30 <luke-jr> heh
199 2016-10-27T08:09:22 <luke-jr> of course, that wouldn't explain why real candidates are not allowed to register for write-in in some States (IIRC mainly NY and CA), but we're getting a bit too far off-topic I think
200 2016-10-27T08:11:21 <wumpus> maybe they should use a blockchain for registering candidates *ducks*
201 2016-10-27T08:11:40 <luke-jr> sadly, some people think that makes sense
202 2016-10-27T08:13:40 <gmaxwell> wumpus: so, final?
203 2016-10-27T08:21:58 *** laurentmt has joined #bitcoin-core-dev
204 2016-10-27T08:22:36 *** laurentmt has quit IRC
205 2016-10-27T08:22:43 <wumpus> yes, let's do it
206 2016-10-27T08:22:47 <wumpus> sipa's asleep
207 2016-10-27T08:25:07 <wumpus> * [new tag] v0.13.1 -> v0.13.1
208 2016-10-27T08:25:15 <gmaxwell> \O/
209 2016-10-27T08:25:49 <luke-jr> oh wow, rc3 just deleted my entire home directory â¦â¦â¦â¦â¦.. jk :P
210 2016-10-27T08:26:54 <gmaxwell> cool "0.13.1 addresses user's concerns with excessive disk space consumption."
211 2016-10-27T08:28:08 <wumpus> hehe, always the positive side
212 2016-10-27T08:28:14 <luke-jr> lol
213 2016-10-27T08:28:27 <jonasschnelli> heh
214 2016-10-27T08:28:31 <warren> that sounds like one particular user had concerns
215 2016-10-27T08:30:09 *** Guyver2 has joined #bitcoin-core-dev
216 2016-10-27T08:32:33 <jonasschnelli> huh! Why can this happen: http://paste.ubuntu.com/23387379/
217 2016-10-27T08:34:10 <wumpus> huh, that looks like a bug in assertlockheld
218 2016-10-27T08:34:12 <jonasschnelli> maybe a different wallet instance...
219 2016-10-27T08:34:19 <wumpus> ah yes ofcourse
220 2016-10-27T08:34:49 <wumpus> maybe the lock naming should include instance pointer
221 2016-10-27T08:35:01 <jonasschnelli> Yes. My fault... different instances
222 2016-10-27T08:35:29 * jonasschnelli curses pwalletMain
223 2016-10-27T08:36:51 <luke-jr> hm, I didn't encounter such issues with multiwallet? O.o
224 2016-10-27T08:40:44 <wumpus> did you run with lock debugging on?
225 2016-10-27T08:41:26 <wumpus> (--enable-debug will do)
226 2016-10-27T08:44:04 <luke-jr> no
227 2016-10-27T08:44:16 <luke-jr> does the assertlockheld only work with that?
228 2016-10-27T08:44:33 <wumpus> yes
229 2016-10-27T08:51:42 <wumpus> it uses the same data structures as the lock order checks, there's a fair amount of overhead in tracking locks at run-time so it is not enabled in release builds
230 2016-10-27T08:55:22 *** btcfanboi has joined #bitcoin-core-dev
231 2016-10-27T09:02:38 *** JackH has joined #bitcoin-core-dev
232 2016-10-27T09:07:59 <michagogo> ðð
233 2016-10-27T09:09:00 * michagogo sends a message and requests that his computer be turned on
234 2016-10-27T09:09:41 <wumpus> wake-over-IRC?
235 2016-10-27T09:15:24 *** Yogh has joined #bitcoin-core-dev
236 2016-10-27T09:15:43 *** Yogh has left #bitcoin-core-dev
237 2016-10-27T09:19:22 *** Guyver2 has quit IRC
238 2016-10-27T09:37:27 <michagogo> wumpus: wake-over-iMessage
239 2016-10-27T09:37:40 <michagogo> (Poweron, really)
240 2016-10-27T09:37:56 <michagogo> Anyway, build running now
241 2016-10-27T09:38:11 <michagogo> As usual, sigs will auto-PR
242 2016-10-27T09:40:59 <michagogo> I wonder how quickly we'll get sigs
243 2016-10-27T09:41:08 <michagogo> Think release will come today?
244 2016-10-27T09:43:15 *** cdecker has joined #bitcoin-core-dev
245 2016-10-27T09:48:47 *** mkarrer_ has joined #bitcoin-core-dev
246 2016-10-27T09:52:16 *** mkarrer has quit IRC
247 2016-10-27T10:01:40 *** n1ce has quit IRC
248 2016-10-27T10:04:27 *** n1ce has joined #bitcoin-core-dev
249 2016-10-27T10:12:31 *** btcfanboi has quit IRC
250 2016-10-27T10:13:29 *** cdecker has quit IRC
251 2016-10-27T10:13:29 <GitHub161> [bitcoin] s-matthew-english opened pull request #9029: instance of 'mem pool' to 'mempool' (master...patch-7) https://github.com/bitcoin/bitcoin/pull/9029
252 2016-10-27T10:14:21 *** harrymm has quit IRC
253 2016-10-27T10:19:56 <michagogo> Ooh, just got my hacktoberfest email
254 2016-10-27T10:24:04 <gmaxwell> https://blockchain.info/charts/utxo-count?timespan=60days and fees are back down to ~0.5 btc/block...
255 2016-10-27T10:24:57 *** Ylbam_ has quit IRC
256 2016-10-27T10:26:33 *** jl2012 has quit IRC
257 2016-10-27T10:27:19 *** jl2012 has joined #bitcoin-core-dev
258 2016-10-27T10:27:37 *** cdecker has joined #bitcoin-core-dev
259 2016-10-27T10:27:53 *** Ylbam_ has joined #bitcoin-core-dev
260 2016-10-27T10:32:16 *** harrymm has joined #bitcoin-core-dev
261 2016-10-27T10:39:29 <GitHub174> [bitcoin] rebroad opened pull request #9030: Don't process blocktxns when we have the block already. (master...BlocktxnExits) https://github.com/bitcoin/bitcoin/pull/9030
262 2016-10-27T10:43:33 *** harrymm has quit IRC
263 2016-10-27T10:46:17 <gmaxwell> andytoshi: wumpus: http://seriot.ch/parsing_json.html < json test vectors.
264 2016-10-27T10:48:28 <wumpus> gmaxwell: yeah came up earlier today already there's even an issue :) https://github.com/bitcoin/bitcoin/issues/9028
265 2016-10-27T10:49:34 *** a_meteorite has quit IRC
266 2016-10-27T10:49:55 *** a_meteorite has joined #bitcoin-core-dev
267 2016-10-27T10:58:19 *** harrymm has joined #bitcoin-core-dev
268 2016-10-27T11:06:14 *** fengling has quit IRC
269 2016-10-27T11:11:56 *** n1ce has quit IRC
270 2016-10-27T11:18:02 <jonasschnelli> Just got a report that prioritisetransaction does not work on 0.12?
271 2016-10-27T11:18:38 <wumpus> on 0.12? or 0.13?
272 2016-10-27T11:19:10 <jonasschnelli> The reporter reported its working on 0.13 but not on 0.12
273 2016-10-27T11:20:55 <luke-jr> do we care then?
274 2016-10-27T11:22:43 <wumpus> I don't
275 2016-10-27T11:22:54 <wumpus> was briefly in shock because of 0.13.1 :)
276 2016-10-27T11:25:31 <luke-jr> jonasschnelli: the reporter is a miner? why aren't they on 0.13.0?
277 2016-10-27T11:25:49 <luke-jr> sounds suspiciously like BU
278 2016-10-27T11:26:02 <wumpus> yea
279 2016-10-27T11:28:40 *** n1ce has joined #bitcoin-core-dev
280 2016-10-27T11:31:44 <jonasschnelli> i don't care as well
281 2016-10-27T11:32:17 <jonasschnelli> but good to know >if< 0.12 is not working and if so, why 0.13 is working
282 2016-10-27T11:33:42 *** rebroad has joined #bitcoin-core-dev
283 2016-10-27T11:34:48 <Victorsueca> 0.12 is supposed to be still supported, should we backport a fix for this?
284 2016-10-27T11:35:11 <wumpus> if someone writes a fix I'm happy to merge it
285 2016-10-27T11:36:23 <luke-jr> Eligius didn't use 0.12 for long, but I am pretty certain prioritise worked
286 2016-10-27T11:37:47 <luke-jr> (and I do check GBT returns the txid when I prioritise stuff)
287 2016-10-27T11:38:01 <luke-jr> so IMO it's probably either BU nonsense or PEBKAC
288 2016-10-27T11:38:21 *** cryptapus has joined #bitcoin-core-dev
289 2016-10-27T11:38:22 *** cryptapus has joined #bitcoin-core-dev
290 2016-10-27T11:52:19 <jonasschnelli> first we would need to double-check if its not working on 0.12. It was just a report.
291 2016-10-27T11:52:50 <jonasschnelli> There are some RPC tests.. although not sure when we have added those.
292 2016-10-27T12:00:13 *** moli has joined #bitcoin-core-dev
293 2016-10-27T12:04:32 *** a_meteorite has quit IRC
294 2016-10-27T12:04:43 *** a_meteor_ has joined #bitcoin-core-dev
295 2016-10-27T12:05:14 <wumpus> I'm surprised if it really doesn't work and we only hear about it now
296 2016-10-27T12:06:54 *** a_meteor_ has quit IRC
297 2016-10-27T12:07:23 *** a_meteorite has joined #bitcoin-core-dev
298 2016-10-27T12:07:56 *** n1ce has quit IRC
299 2016-10-27T12:09:39 *** n1ce has joined #bitcoin-core-dev
300 2016-10-27T12:10:31 <GitHub57> [bitcoin] laanwj opened pull request #9032: test: Add format-dependent comparison to bctest (master...2016_10_bctest_smart_compare) https://github.com/bitcoin/bitcoin/pull/9032
301 2016-10-27T12:11:19 *** a_meteorite has quit IRC
302 2016-10-27T12:11:32 <wumpus> btcdrak: https://github.com/bitcoin/bitcoin/pull/9032
303 2016-10-27T12:12:35 *** a_meteorite has joined #bitcoin-core-dev
304 2016-10-27T12:14:05 <btcdrak> wumpus: interesting
305 2016-10-27T12:14:19 *** a_meteorite has joined #bitcoin-core-dev
306 2016-10-27T12:14:25 <wumpus> I'm not even sure the second step should be a fatal error or just a warning
307 2016-10-27T12:14:46 <wumpus> a_meteorite: please fix your IRC client, you're generating too many join/part messages
308 2016-10-27T12:14:52 <btcdrak> wumpus: this was really helpful
309 2016-10-27T12:14:53 <btcdrak> https://github.com/bitcoin/bitcoin/pull/9023
310 2016-10-27T12:15:43 <wumpus> yes, but I think it makes the test too noisy in the pass case
311 2016-10-27T12:15:59 <wumpus> printing a diff when the test fails makes sense though
312 2016-10-27T12:16:11 *** Chris_Stewart_5 has joined #bitcoin-core-dev
313 2016-10-27T12:16:39 <btcdrak> maybe should shield the pass stuff with a -verbose flag? or ditch the pass logs entirely?
314 2016-10-27T12:17:08 <wumpus> yes I'd say ditch the pass logs, ideally tests are silent if nothing is wrong
315 2016-10-27T12:17:11 <wumpus> (esp in travis)
316 2016-10-27T12:17:31 *** jtimon has joined #bitcoin-core-dev
317 2016-10-27T12:18:34 * luke-jr publishes Knots 0.13.1 and goes to bed :P
318 2016-10-27T12:19:33 *** a_meteorite has quit IRC
319 2016-10-27T12:19:47 <wumpus> btcdrak: this may be already what it does, I was confused by all the logging stuff
320 2016-10-27T12:20:06 *** a_meteorite has joined #bitcoin-core-dev
321 2016-10-27T12:20:15 *** ChanServ sets mode: +o wumpus
322 2016-10-27T12:20:30 <luke-jr> poor a_meteorite is going to fall to Earth
323 2016-10-27T12:20:34 <btcdrak> iirc it prints pass and fail. lemme rerun quickly
324 2016-10-27T12:20:55 *** wumpus sets mode: +b *!*@unaffiliated/ameteorite/x-000000001
325 2016-10-27T12:21:00 <wumpus> luke-jr: hah
326 2016-10-27T12:21:06 <wumpus> btcdrak: but also in non-verbose mode?
327 2016-10-27T12:21:18 *** Chris_Stewart_5 has quit IRC
328 2016-10-27T12:21:32 <btcdrak> ok just checked, by default passes are silent
329 2016-10-27T12:21:42 <btcdrak> if you add -v then you get full output
330 2016-10-27T12:21:50 <wumpus> ok, and diffs are printed on failure?
331 2016-10-27T12:21:58 <btcdrak> https://www.irccloud.com/pastebin/fuxIut4y/
332 2016-10-27T12:22:28 <wumpus> even in non-verbose mode?
333 2016-10-27T12:22:56 *** a_meteorite has quit IRC
334 2016-10-27T12:23:23 *** Chris_Stewart_5 has joined #bitcoin-core-dev
335 2016-10-27T12:24:11 <btcdrak> oh wait, my cherry-pick failed and I didnt notice :-p
336 2016-10-27T12:24:25 <wumpus> gah
337 2016-10-27T12:24:33 <btcdrak> so it is noisy without -v
338 2016-10-27T12:24:39 <btcdrak> https://www.irccloud.com/pastebin/hd69OPZ4/
339 2016-10-27T12:24:41 <wumpus> sigh
340 2016-10-27T12:24:50 * wumpus re-edits his post again
341 2016-10-27T12:25:49 <GitHub48> [bitcoin] MarcoFalke reopened pull request #9011: 0.13.2 backports (0.13...2016_10_backports_conditional_rc3) https://github.com/bitcoin/bitcoin/pull/9011
342 2016-10-27T12:26:46 <btcdrak> wumpus: I commented too
343 2016-10-27T12:27:15 *** MarcoFalke has joined #bitcoin-core-dev
344 2016-10-27T12:28:04 <btcdrak> wumpus: otherwise the errors are great e.g.
345 2016-10-27T12:28:07 <btcdrak> https://www.irccloud.com/pastebin/xL5cqNGo/
346 2016-10-27T12:29:36 <achow101> oh hey, a tag!
347 2016-10-27T12:29:42 <wumpus> yes that seems useful
348 2016-10-27T12:30:56 *** wasi has joined #bitcoin-core-dev
349 2016-10-27T12:31:25 <GitHub163> [bitcoin] MarcoFalke opened pull request #9033: Update build notes for dropping osx 10.7 support (fanquake) (master...Mf1610-docFanquake) https://github.com/bitcoin/bitcoin/pull/9033
350 2016-10-27T12:36:42 *** Chris_Stewart_5 has quit IRC
351 2016-10-27T12:38:50 <wumpus> btcdrak: does -v actually work for you?
352 2016-10-27T12:39:10 <btcdrak> wumpus: it doesnt do anything different under his patch
353 2016-10-27T12:39:13 <wumpus> I moved the PASSED messages to the debug level, but now I can't get them to output at all
354 2016-10-27T12:41:30 <btcdrak> same here, hmm
355 2016-10-27T12:42:24 <wumpus> figured it out
356 2016-10-27T12:52:17 *** PaulCapestany has quit IRC
357 2016-10-27T12:56:24 <GitHub49> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/2e2388a5cbb9a6e101b36e4501698fec538a5738
358 2016-10-27T12:56:25 <GitHub49> bitcoin/0.13 2e2388a Wladimir J. van der Laan: Move release notes to release-notes/release-notes-0.13.1.md...
359 2016-10-27T12:58:49 <GitHub138> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/a49b4a75a1b671492e65eed17d6894d85ea5ebfd
360 2016-10-27T12:58:50 <GitHub138> bitcoin/master a49b4a7 Wladimir J. van der Laan: doc: Add release notes for 0.13.1 release
361 2016-10-27T12:59:35 <timothy> does 0.13.1 requires new or different libraries?
362 2016-10-27T12:59:39 <timothy> to built
363 2016-10-27T12:59:40 <GitHub66> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a49b4a75a1b6...83234d4d1723
364 2016-10-27T12:59:41 <GitHub66> bitcoin/master ba26d41 Michael Ford: Update build notes for dropping osx 10.7 support...
365 2016-10-27T12:59:41 <GitHub66> bitcoin/master 83234d4 Wladimir J. van der Laan: Merge #9033: Update build notes for dropping osx 10.7 support (fanquake)...
366 2016-10-27T12:59:48 <wumpus> compared to what?
367 2016-10-27T12:59:49 <GitHub134> [bitcoin] laanwj closed pull request #9033: Update build notes for dropping osx 10.7 support (fanquake) (master...Mf1610-docFanquake) https://github.com/bitcoin/bitcoin/pull/9033
368 2016-10-27T12:59:52 <timothy> 0.13.0
369 2016-10-27T13:00:08 <wumpus> yes there was at least a patch to boost
370 2016-10-27T13:00:19 <timothy> so can't I use vanilla boost?
371 2016-10-27T13:00:32 <wumpus> sure, you always can
372 2016-10-27T13:00:58 <wumpus> I thought you were talking about the gitian build, if you build using your OS' libraries there no need to do anything special
373 2016-10-27T13:04:05 *** PaulCapestany has joined #bitcoin-core-dev
374 2016-10-27T13:07:19 *** laurentmt has joined #bitcoin-core-dev
375 2016-10-27T13:07:19 *** laurentmt has quit IRC
376 2016-10-27T13:09:12 *** Chris_Stewart_5 has joined #bitcoin-core-dev
377 2016-10-27T13:12:53 *** wasi has quit IRC
378 2016-10-27T13:16:13 *** laurentmt has joined #bitcoin-core-dev
379 2016-10-27T13:16:18 *** laurentmt has quit IRC
380 2016-10-27T13:19:25 *** whphhg has joined #bitcoin-core-dev
381 2016-10-27T13:19:36 <whphhg> Hej, is there a Bitcoin Unlimited channel on freenode?
382 2016-10-27T13:23:16 <timothy> lol
383 2016-10-27T13:23:30 <rabidus_> lol
384 2016-10-27T13:23:39 <timothy> it's like entering on FBI channel and ask for drug
385 2016-10-27T13:26:44 <PatBoy> hahahah
386 2016-10-27T13:26:56 *** atroxes has quit IRC
387 2016-10-27T13:29:25 <wumpus> rofl
388 2016-10-27T13:31:25 *** wasi has joined #bitcoin-core-dev
389 2016-10-27T13:32:28 *** Chris_Stewart_5 has quit IRC
390 2016-10-27T13:33:21 <whphhg> Lol, I wasn't aware it was that bad. :o
391 2016-10-27T13:33:22 *** atroxes has joined #bitcoin-core-dev
392 2016-10-27T13:39:40 <BlueMatt> wumpus: so do i wait to update the ppa or just do it today?
393 2016-10-27T13:41:27 <wumpus> BlueMatt: let me see, how many gitian sigs do we have now
394 2016-10-27T13:42:19 <wumpus> three matching ones
395 2016-10-27T13:42:43 <BlueMatt> i said today, not now....still eating breakfast :p
396 2016-10-27T13:42:46 <wumpus> but no code-signed ones yet. I guess it's somewhat strange to have the ppa built before the binaries available
397 2016-10-27T13:43:15 <btcdrak> Better not do it until the release actual announcement when we have everything done.
398 2016-10-27T13:48:01 <BlueMatt> btcdrak: meh, i often do it early...otherwise i forget
399 2016-10-27T13:48:19 *** Chris_Stewart_5 has joined #bitcoin-core-dev
400 2016-10-27T13:49:19 *** fengling has joined #bitcoin-core-dev
401 2016-10-27T13:51:57 <Lauda> BlueMatt please ppa as soon as possible 0.13.0 took forever. :)
402 2016-10-27T13:53:57 *** Chris_Stewart_5 has quit IRC
403 2016-10-27T13:57:47 <btcdrak> Lauda: good point :-p
404 2016-10-27T14:03:28 *** jl2012 has quit IRC
405 2016-10-27T14:03:53 <michagogo> BlueMatt: is it all ready in terms of packaging, i.e. just a matter of pushing the button?
406 2016-10-27T14:04:16 *** Ylbam_ has quit IRC
407 2016-10-27T14:04:35 <michagogo> (Also, how long on average does it take from the time you push the build up until the server farm actually builds and publishes it?)
408 2016-10-27T14:06:17 <michagogo> If it's done with a command, you could avoid forgetting by setting a cronjob (or just a screen/tmux with a `sleep &&`) to do it in 24 hours
409 2016-10-27T14:06:21 <michagogo> Or 48 or something
410 2016-10-27T14:07:11 <michagogo> (Also, it's unfortunate that only cfields_ can produce the detached sigsâ¦)
411 2016-10-27T14:10:55 <btcdrak> wumpus: I uploaded my gitian sigs
412 2016-10-27T14:11:24 <BlueMatt> michagogo: naa, need to do a few things first, then its like within 20-30 minutes after upload that they're all built and available
413 2016-10-27T14:11:41 *** Giszmo has joined #bitcoin-core-dev
414 2016-10-27T14:16:51 <michagogo> wumpus: re: #9028 (and in general), have you considered tagging some issues for Hacktoberfest?
415 2016-10-27T14:17:03 <BlueMatt> 'tf is hacktoberfest?
416 2016-10-27T14:17:13 <michagogo> ;;Google hacktoberfest
417 2016-10-27T14:17:14 <gribble> Hacktoberfest 2016 - DigitalOcean: <https://hacktoberfest.digitalocean.com/>; Hacktoberfest is back · GitHub: <https://github.com/blog/2260-hacktoberfest-is-back>; # hacktoberfest hashtag on Twitter: <https://twitter.com/hashtag/hacktoberfest>
418 2016-10-27T14:17:23 <BlueMatt> also, isnt october over?
419 2016-10-27T14:17:43 <michagogo> Well, almost
420 2016-10-27T14:27:41 *** waxwing has quit IRC
421 2016-10-27T14:28:33 *** waxwing has joined #bitcoin-core-dev
422 2016-10-27T14:41:06 <wumpus> would be a bit too late I guess
423 2016-10-27T14:42:33 <wumpus> (for hacktoberfest)
424 2016-10-27T14:42:48 <wumpus> woohoo, 6 sigs all match
425 2016-10-27T14:43:10 <wumpus> ping cfields_
426 2016-10-27T14:44:00 *** whphhg has left #bitcoin-core-dev
427 2016-10-27T14:47:35 <GitHub55> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/83234d4d1723...fea5e05a6380
428 2016-10-27T14:47:36 <GitHub55> bitcoin/master 1c3ecc7 S. Matthew English: instance of 'mem pool' to 'mempool'...
429 2016-10-27T14:47:36 <GitHub55> bitcoin/master fea5e05 Wladimir J. van der Laan: Merge #9029: instance of 'mem pool' to 'mempool'...
430 2016-10-27T14:47:46 <GitHub196> [bitcoin] laanwj closed pull request #9029: instance of 'mem pool' to 'mempool' (master...patch-7) https://github.com/bitcoin/bitcoin/pull/9029
431 2016-10-27T14:54:58 *** pedrobranco has joined #bitcoin-core-dev
432 2016-10-27T14:56:13 *** luke-jr has quit IRC
433 2016-10-27T14:56:16 *** AtashiCon has quit IRC
434 2016-10-27T14:56:20 *** Arnavion3 has joined #bitcoin-core-dev
435 2016-10-27T14:56:22 *** luke-jr has joined #bitcoin-core-dev
436 2016-10-27T14:56:24 <sipa> BlueMatt: Oktoberfest is also mostly not in october :)
437 2016-10-27T14:56:24 *** Arnavion3 is now known as AtashiCon
438 2016-10-27T14:56:48 <BlueMatt> heh, true
439 2016-10-27T15:04:40 <andytoshi> thanks gmaxwell (re json test vectors)
440 2016-10-27T15:12:59 <kanzure> andytoshi: trying to save yourself some work on mimblewimble?
441 2016-10-27T15:20:30 * michagogo waves at cfields_
442 2016-10-27T15:27:53 * michagogo watches https://github.com/bitcoin-core/bitcoin-detached-sigs/tags
443 2016-10-27T15:28:44 <achow101> michagogo: are we harassing cfields_ now to get the code signed sigs?
444 2016-10-27T15:29:22 <michagogo> achow101: no need to harass, I think - he pushed his gitian sigs up
445 2016-10-27T15:29:36 <michagogo> I assume the detached will be up shortly
446 2016-10-27T15:30:02 <michagogo> BlueMatt: there are enough gitian builders around that it's probably safe to get the PPA ready
447 2016-10-27T15:30:32 <BlueMatt> yea, busy fixing 8969 for now, will soon
448 2016-10-27T15:30:40 <michagogo> BTW, has anyone here looked into Ubuntu's new "snap" packaging thing?
449 2016-10-27T15:31:16 *** BCBot has quit IRC
450 2016-10-27T15:34:29 *** fengling has quit IRC
451 2016-10-27T15:35:10 *** BashCo has quit IRC
452 2016-10-27T15:36:22 *** cryptapus has quit IRC
453 2016-10-27T15:39:53 *** cryptapus has joined #bitcoin-core-dev
454 2016-10-27T15:39:53 *** cryptapus has joined #bitcoin-core-dev
455 2016-10-27T15:48:45 <michagogo> wumpus: I don't see the usual PR for the release notes on bitcoin.org
456 2016-10-27T15:49:42 *** Chris_Stewart_5 has joined #bitcoin-core-dev
457 2016-10-27T15:52:07 <achow101> are the release notes finalized yet?
458 2016-10-27T15:56:34 <cfields_> hehe, i was working on the sigs while you guys were busy waving :)
459 2016-10-27T15:56:49 <cfields_> gitian builders: v0.13.1 sigs are pushed
460 2016-10-27T15:56:53 <michagogo> achow101: I think so, yeah
461 2016-10-27T16:00:45 <michagogo> My sigs are pushed as well
462 2016-10-27T16:01:31 <achow101> so are mine
463 2016-10-27T16:01:54 <michagogo> wumpus: looks like the release is ready when you are
464 2016-10-27T16:02:45 <btcdrak> segwit upgrading guide published today
465 2016-10-27T16:02:46 <btcdrak> https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
466 2016-10-27T16:04:30 <michagogo> https://github.com/bitcoin-core/bitcoincore.org/pull/241 needs updating
467 2016-10-27T16:05:30 *** BashCo has joined #bitcoin-core-dev
468 2016-10-27T16:06:31 <cfields_> btcdrak: you can add ckpool to the mining list. and the cgminer PR hasn't been merged yet.
469 2016-10-27T16:07:12 <btcdrak> ok
470 2016-10-27T16:08:49 *** rebroad has quit IRC
471 2016-10-27T16:10:43 *** BCBot has joined #bitcoin-core-dev
472 2016-10-27T16:10:55 <btcdrak> seems like the binaries will be ready today?
473 2016-10-27T16:14:10 *** BCBot has quit IRC
474 2016-10-27T16:16:32 <andytoshi> kanzure: no, i have a rust json parsing library for bitcoin purposes, a low-priority TODO is for me to aggressively compare its behaviour to that of univalue
475 2016-10-27T16:17:32 <cfields_> btcdrak: technically just need 1 more match i think, which i'm sure will show up any minute
476 2016-10-27T16:21:10 <michagogo> cfields_: that match is probably going to be wumpus
477 2016-10-27T16:21:24 <michagogo> Who is the one that does the release anyway
478 2016-10-27T16:23:27 *** laurentmt has joined #bitcoin-core-dev
479 2016-10-27T16:26:57 *** laurentmt has quit IRC
480 2016-10-27T16:35:37 <cfields_> btcdrak: thanks
481 2016-10-27T16:36:43 <sipa> what does mf mean?
482 2016-10-27T16:36:55 <sipa> "0.13.1 signed mf"
483 2016-10-27T16:37:20 <MarcoFalke> my initials
484 2016-10-27T16:37:26 <MarcoFalke> :P
485 2016-10-27T16:37:36 <sipa> oh, of course
486 2016-10-27T16:37:46 <cfields_> I read it as Samuel L. Jackson.
487 2016-10-27T16:37:46 * sipa stupid
488 2016-10-27T16:37:55 <sipa> ...?
489 2016-10-27T16:39:13 <cfields_> as in: I've had it with these MarcoFalke snakes, on this MarcoFalke plane!
490 2016-10-27T16:40:02 <sipa> i see.
491 2016-10-27T16:45:51 *** cryptapus has quit IRC
492 2016-10-27T16:47:18 *** cryptapus has joined #bitcoin-core-dev
493 2016-10-27T16:59:19 <MarcoFalke> Heh, I should change it to m4r(0f41k3 as there will be 1337 commits in the repo after it is merged.
494 2016-10-27T17:23:24 *** laurentmt has joined #bitcoin-core-dev
495 2016-10-27T17:24:54 *** cryptapus has quit IRC
496 2016-10-27T17:25:43 *** laurentmt has quit IRC
497 2016-10-27T17:30:25 *** Ylbam_ has joined #bitcoin-core-dev
498 2016-10-27T17:31:27 <wumpus> hahaha
499 2016-10-27T17:35:51 *** cryptapus has joined #bitcoin-core-dev
500 2016-10-27T17:41:15 *** belcher has quit IRC
501 2016-10-27T17:43:44 *** jl2012 has joined #bitcoin-core-dev
502 2016-10-27T17:54:34 *** dcousens has quit IRC
503 2016-10-27T17:56:19 *** achow101_ has joined #bitcoin-core-dev
504 2016-10-27T17:57:12 <achow101_> are we so lucky that the time from tag to release will be less than 12 hours this time>
505 2016-10-27T17:57:13 <achow101_> ?
506 2016-10-27T18:03:44 <btcdrak> achow101_: looks like everything has been done barring release notes and upload to bitcoin.org
507 2016-10-27T18:04:01 <btcdrak> s/notes/announce/
508 2016-10-27T18:04:23 <achow101_> :D
509 2016-10-27T18:04:30 <btcdrak> meeting time? or is everyone down at the pub having a well deserved pint?
510 2016-10-27T18:04:46 <achow101_> I think you're an hour early
511 2016-10-27T18:05:00 <btcdrak> wait, did the clocks change?
512 2016-10-27T18:05:17 <achow101_> idk, depends on your country
513 2016-10-27T18:05:33 <btcdrak> automatic clock update so I would never know >_>
514 2016-10-27T18:05:44 <btcdrak> this explains a lot...
515 2016-10-27T18:06:26 <achow101_> dst ends for me next week
516 2016-10-27T18:07:04 <sipa> it's one hour from now
517 2016-10-27T18:07:24 <sipa> btcdrak: set it in your calendar as 7pm iceland time
518 2016-10-27T18:10:52 *** frederic94500 has joined #bitcoin-core-dev
519 2016-10-27T18:12:04 <morcos> jonasschnelli: i think apple gave us an idea. you should move the fee slider to the touch bar.
520 2016-10-27T18:12:23 <btcdrak> sipa: let's all just move to Iceland.
521 2016-10-27T18:12:33 <sipa> morcos: 'touch bar' ?
522 2016-10-27T18:12:49 <morcos> what they replaced function keys with on the new macbook pros
523 2016-10-27T18:12:53 <jonasschnelli> sipa: new MacBook Pro physical UX element
524 2016-10-27T18:13:05 <jonasschnelli> A screen replaces the F function keys
525 2016-10-27T18:13:13 <sipa> i don't understand
526 2016-10-27T18:13:15 <BlueMatt> wtf is a "physical UX element"
527 2016-10-27T18:13:16 <jonasschnelli> morcos: I need to watch the presentation
528 2016-10-27T18:13:23 <BlueMatt> sipa: they replace the top line of your keyboard with an ipad
529 2016-10-27T18:13:42 <jonasschnelli> http://photos.reportinglive.com/p/2016-10-27/f1477589812.jpg
530 2016-10-27T18:13:56 <btcdrak> o.O
531 2016-10-27T18:14:11 <sipa> i still don't understand what it means to move the fee slider
532 2016-10-27T18:14:21 <achow101_> looks stupid
533 2016-10-27T18:14:29 <morcos> there was some PR discussion about the right way for the fee slider to work in QT
534 2016-10-27T18:14:36 <jeremyrubin> Let's add touchid support at least...
535 2016-10-27T18:15:45 <btcdrak> what is touchid?
536 2016-10-27T18:15:53 <achow101_> the fingerprint sensor stuff
537 2016-10-27T18:16:16 <jeremyrubin> fingerprint sensor + secure enclave
538 2016-10-27T18:16:52 <jonasschnelli> finger print has no plausible deniability
539 2016-10-27T18:17:01 <gmaxwell> the lenovo x1s have a touchscreen at the top of the keyboard instead of fkeys, it's awful.
540 2016-10-27T18:17:28 <BlueMatt> jonasschnelli: and your machine is..uhhh...covered in your fingerprints
541 2016-10-27T18:17:43 <btcdrak> Did anyone see that presentation where someone lifted a fingerprint off a photo of someone and reproduced the print on a 3D printer... and managed to open their phone with it? I think it was a German politician's phone.
542 2016-10-27T18:17:52 <sipa> BlueMatt: i'm sure my keyboard is already covered with fingerprints :)
543 2016-10-27T18:17:56 <jonasschnelli> Right... adhesive tape is sufficient to unlock
544 2016-10-27T18:18:15 <btcdrak> seems like security theatre
545 2016-10-27T18:18:32 <jonasschnelli> Probably state sponsored move.. :)
546 2016-10-27T18:18:46 <jeremyrubin> gmaxwell: it's a different thing than that kind
547 2016-10-27T18:18:47 <jonasschnelli> You can now force everyone to unlock your HDD/SDD
548 2016-10-27T18:18:53 <achow101_> btcdrak: mythbusters did an episode about fingerprint spoofing
549 2016-10-27T18:18:54 <jeremyrubin> is that one on X1 even a screen?
550 2016-10-27T18:19:16 <btcdrak> This was it in 2014 http://www.bbc.com/news/technology-30623611
551 2016-10-27T18:19:25 <jeremyrubin> Also touchid doesn't usually replace password
552 2016-10-27T18:20:38 <jonasschnelli> jeremyrubin: Yeah. But if you login with touchid after a cold-start... I guess it replaces passwords.
553 2016-10-27T18:20:45 <jonasschnelli> It's probably different then on iOS
554 2016-10-27T18:20:46 <btcdrak> I prefer passwords + smartcards
555 2016-10-27T18:20:55 <jonasschnelli> Yes. FIDO enabled hardware wallet
556 2016-10-27T18:20:59 <jonasschnelli> Works since 10.11 on OSX
557 2016-10-27T18:21:01 *** gabridome has joined #bitcoin-core-dev
558 2016-10-27T18:21:03 <sipa> fingerprint unlocking is so annoyingly convenient :(
559 2016-10-27T18:21:09 <jonasschnelli> heh
560 2016-10-27T18:21:26 <jonasschnelli> What I want is fingerprint & passphrase
561 2016-10-27T18:22:20 <btcdrak> I want to keep my fingers
562 2016-10-27T18:25:10 *** pedrobranco has quit IRC
563 2016-10-27T18:25:40 *** pedrobranco has joined #bitcoin-core-dev
564 2016-10-27T18:26:21 <NicolasDorier> while playing doing my node in C#, I tried a way to speedup IBD by 50%: Basically I prefetch the UTXO and tx id's (for BIP30) of block N+1 while validating block N. Still a bit early to call victory, but might be a piste to explore for core
565 2016-10-27T18:26:54 *** d9b4bef9 has quit IRC
566 2016-10-27T18:27:49 <sipa> NicolasDorier: interesting idea, though i'm not sure it's so useful - i expect we already have the majority of utxo entires cached
567 2016-10-27T18:28:08 *** d9b4bef9 has joined #bitcoin-core-dev
568 2016-10-27T18:28:15 <sipa> but i guess it could speed up looking for the ones that aren't
569 2016-10-27T18:28:17 <NicolasDorier> sipa: the thing that slow down is BIP30
570 2016-10-27T18:28:24 <NicolasDorier> because we are checking for a negative
571 2016-10-27T18:28:29 <NicolasDorier> so it is not in the cache
572 2016-10-27T18:28:42 <sipa> we don't do that anymore, afaik
573 2016-10-27T18:29:12 <sipa> only before bip34 activation
574 2016-10-27T18:29:23 <NicolasDorier> oh checking that
575 2016-10-27T18:29:31 *** frederic94500 has quit IRC
576 2016-10-27T18:30:16 *** pedrobranco has quit IRC
577 2016-10-27T18:31:30 <NicolasDorier> ah yeah you are right. It's strange, I do'nt know why I get more speed on validation.... well I think I'll get a better idea once my node reach block above 400 000
578 2016-10-27T18:31:41 *** Frederic94500 has joined #bitcoin-core-dev
579 2016-10-27T18:32:18 <NicolasDorier> the commit on disk is in background on core right ?
580 2016-10-27T18:32:36 <NicolasDorier> except TxUndo if I remember
581 2016-10-27T18:41:03 *** nibor has joined #bitcoin-core-dev
582 2016-10-27T18:44:17 *** BCBot has joined #bitcoin-core-dev
583 2016-10-27T18:45:02 <NicolasDorier> mmh... well, I'll wait I reach later block mayb it's not the case
584 2016-10-27T18:47:16 *** kangx has joined #bitcoin-core-dev
585 2016-10-27T18:54:10 *** gabridome has quit IRC
586 2016-10-27T19:00:25 *** whphhg has joined #bitcoin-core-dev
587 2016-10-27T19:00:37 <jtimon> meeting...
588 2016-10-27T19:01:16 <wumpus> congrats on 0.13.1 everyone!
589 2016-10-27T19:01:21 * btcdrak rings the gong
590 2016-10-27T19:01:23 <wumpus> #startmeeting
591 2016-10-27T19:01:23 <lightningbot> Meeting started Thu Oct 27 19:01:23 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
592 2016-10-27T19:01:23 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
593 2016-10-27T19:01:26 <jtimon> 0.13.1 is out 18 mins ago! yay
594 2016-10-27T19:01:40 <CodeShark> binaries?
595 2016-10-27T19:01:42 <kanzure> btcdrak: looks like faq menu entry is working now https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
596 2016-10-27T19:01:59 <jeremyrubin> here
597 2016-10-27T19:02:26 <wumpus> CodeShark: https://bitcoin.org/bin/bitcoin-core-0.13.1/
598 2016-10-27T19:02:27 * luke-jr wakes up
599 2016-10-27T19:02:44 *** dermoth has joined #bitcoin-core-dev
600 2016-10-27T19:02:46 <CodeShark> Nice!
601 2016-10-27T19:02:49 <gmaxwell> https://www.reddit.com/r/Bitcoin/comments/59pt66/bitcoin_core_0131_released/
602 2016-10-27T19:03:04 <wumpus> or magnet:?xt=urn:btih:dbe48c446b1113890644bbef03e361269f69c49a&dn=bitcoin-core-0.13.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F
603 2016-10-27T19:03:51 <wumpus> bitcoin.org should be updated after travis passes on https://github.com/bitcoin-dot-org/bitcoin.org/pull/1400
604 2016-10-27T19:04:25 <morcos> congrats everyone!
605 2016-10-27T19:04:31 <sipa> indeed!
606 2016-10-27T19:04:53 <wumpus> woohoo!
607 2016-10-27T19:05:03 <sipa> and thanks everyone for getting us this far
608 2016-10-27T19:05:37 <luke-jr> wumpus: did we get the gitian builds already? is that a record? :o
609 2016-10-27T19:05:54 <wumpus> luke-jr: yes, four signed builders IIRC
610 2016-10-27T19:06:24 <luke-jr> or maybe it just feels like a record since it was the middle of the night for me
611 2016-10-27T19:06:30 <jtimon> I'm trying the gitian builder script for the first time
612 2016-10-27T19:06:33 <wumpus> it may be a record
613 2016-10-27T19:06:43 <wumpus> very fast at least
614 2016-10-27T19:07:09 <jtimon> btcdrak reminded me I have no good excuse for not doing gitian builds
615 2016-10-27T19:07:33 <sipa> i haven't even started :(
616 2016-10-27T19:08:20 <jtimon> well, I have never done it so it may take some time, but the sooner I learn...
617 2016-10-27T19:08:22 <btcdrak> wumpus: I dont see a signed message from you with the binary hashes
618 2016-10-27T19:08:44 <wumpus> BlueMatt: you can release your PPA now (if you didn't yet)
619 2016-10-27T19:09:03 <wumpus> btcdrak: https://bitcoin.org/bin/bitcoin-core-0.13.1/SHA256SUMS.asc
620 2016-10-27T19:09:04 <BlueMatt> wumpus: i have not yet, will try to get that out
621 2016-10-27T19:09:23 <jonasschnelli> BlueMatt: don't forget to add libzmq
622 2016-10-27T19:09:35 <harding> btcdrak: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-October/000023.html
623 2016-10-27T19:09:37 <jonasschnelli> Some uses have complained about the missing ZMQ support
624 2016-10-27T19:10:12 <BlueMatt> jonasschnelli: yup
625 2016-10-27T19:11:30 <wumpus> ok, any other topics today than 0.13.1?
626 2016-10-27T19:11:51 <kanzure> i was going to ask sipa or jtimon about libconsensus follow-up stuff
627 2016-10-27T19:12:04 <sipa> i'm the wrong person to ask
628 2016-10-27T19:12:16 <wumpus> I'm kind of tired so I wouldn't mind ending early :p
629 2016-10-27T19:12:59 <jtimon> kanzure: nothing to report, nobody suggested anything to me or gave me any feedback since last week
630 2016-10-27T19:13:05 <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
631 2016-10-27T19:13:24 <BlueMatt> few minutes late there, gmaxwell
632 2016-10-27T19:13:27 <jtimon> been focusing on the signedblocks patch
633 2016-10-27T19:13:32 <gmaxwell> Just noticed wumpus hadn't done it. :)
634 2016-10-27T19:13:43 <sipa> maybe we can discuss signed blocks a bit
635 2016-10-27T19:13:51 <gmaxwell> So there are a number of things we want to do in a 0.13.2; so those should get in soon.
636 2016-10-27T19:14:06 <morcos> i'm interested in discussing that, because i want to understand whether this is meant to replace the existing testnet or just be another option
637 2016-10-27T19:14:10 <morcos> (signed blocks)
638 2016-10-27T19:14:11 <gmaxwell> (I guess some are in and just need to backport to 0.13 branch.
639 2016-10-27T19:14:21 <wumpus> no, it's not meant to replace the current testnet
640 2016-10-27T19:14:24 <kanzure> re: testnet i also saw the suggestion of loading testnet params from json file
641 2016-10-27T19:14:31 <jtimon> fine with me, I still extremely dsilike having to use a global, but don't see other way around it if we want to use the union
642 2016-10-27T19:14:51 <gmaxwell> morcos: my expectation was that it would just be another option. Obviously it would be useless for testing much of anything mining related.
643 2016-10-27T19:15:11 <jtimon> what I have implemented is from .conf file, not .json file
644 2016-10-27T19:15:11 <wumpus> indeed there should at least be a PoW testnet
645 2016-10-27T19:15:27 <morcos> ok, i think its still important that we have a well used testnet that uses PoW as similarly to mainnet as possible.. i worry that there is kind of only going to be one "testnet" that people use for most purposes though
646 2016-10-27T19:15:47 <morcos> perhaps it would be possible for transactions to easily end up on both?
647 2016-10-27T19:15:49 <kanzure> jtimon: didn't mean to recommend a specific file format; i was just pulling a thing from memory.
648 2016-10-27T19:15:55 *** gabridome has joined #bitcoin-core-dev
649 2016-10-27T19:16:05 <morcos> but maybe thats askign for trouble
650 2016-10-27T19:16:06 <wumpus> yes the file format is completely not important
651 2016-10-27T19:16:13 <jtimon> I'm still trying to test the blocksigning stuff, but the "custom chain" code that preceeds it is pretty much ready I think (feel free to test it and give suggestions), see https://github.com/bitcoin/bitcoin/pull/8994
652 2016-10-27T19:16:16 <sipa> morcos: i think the issue is that 'testnet' can mean "a place where we test new network features, and subject it to huge reorgs, and other edge cases" or "a place where we expect companies to build a parallel infrastructure"
653 2016-10-27T19:16:28 <cfields_> adding to that, see the faux-mining mode added in the #9000 PR. That was crucial for me for real-world mining testing of segwit.
654 2016-10-27T19:16:31 <sipa> and those aren't reconcilable, i think
655 2016-10-27T19:16:56 <jtimon> that alone should be helpful for rapidly creating a new segwitnet (for the next thing) or whatever
656 2016-10-27T19:17:03 <btcdrak> Blog post is up https://bitcoincore.org/en/2016/10/27/release-0.13.1/
657 2016-10-27T19:17:13 <wumpus> one testnet is simply not enough for all testing scenarios
658 2016-10-27T19:17:16 <gmaxwell> morcos: alas, I don't think htats really possible. Right now the consensus insability of testnet causes some people to just not test on it.
659 2016-10-27T19:17:19 <wumpus> btcdrak: awesome
660 2016-10-27T19:17:32 <kanzure> re: company testing, i have been (lightly) planning to use regtest for those purposes. e.g. company-to-company regtest instances. testnet is still important for testing of course.
661 2016-10-27T19:18:07 <wumpus> kanzure: right - within a trusted group using a regtest is just as useful as signed blocks
662 2016-10-27T19:18:25 <kanzure> oh is that what the proposal is-- i'll have to go look. sorry.
663 2016-10-27T19:18:45 <wumpus> it's only when exposing publicly that signing is necessary so people can't grief by generating e.g. tons of blocks
664 2016-10-27T19:19:30 <gmaxwell> morcos: the issue is that while not ideal, on mainnet a reasonable way of handling very large reorgs is to shut your site down and wait for the operator to manually do something about it. If you try that strategy on testnet, your service will just be down all the time.
665 2016-10-27T19:19:38 <kanzure> so for the company-to-company testing scenario, my assumption was you simply limit the number of participants to one other group, and then you know who is causing problems (either you or the other guys). still, i can see some advantages to public regtesting. sure.
666 2016-10-27T19:19:57 <JackH> when will ubuntu ppa's be updated?
667 2016-10-27T19:20:17 <BlueMatt> JackH: when i get to it (today)
668 2016-10-27T19:20:29 <JackH> ah sweet, you are fast this time then
669 2016-10-27T19:20:30 <sipa> btcdrak: nice, the timeline is cool
670 2016-10-27T19:21:25 <luke-jr> BlueMatt: btw, is it possible/easy to do a PPA with Knots as well? (is it something I can do reasonably myself perhaps?)
671 2016-10-27T19:21:56 <wumpus> I think everyone can sign up to make PPAs
672 2016-10-27T19:22:11 * btcdrak is reading scrollback
673 2016-10-27T19:22:52 <BlueMatt> luke-jr: its not bad
674 2016-10-27T19:22:55 <kanzure> without signedblocks, if you had three companies trying to test an integration, you would need multiple different regtest links and to relay blocks from one network to the other with a different signature. i could see how that would be annoying to write. yeah..
675 2016-10-27T19:23:03 <luke-jr> wumpus: yes, it's just not very clear how one would actually make them, especially someone who doesn't use Ubuntu :p
676 2016-10-27T19:23:48 *** pedrobranco has joined #bitcoin-core-dev
677 2016-10-27T19:25:07 <Frederic94500> #bitcoin If segwit doesn't activate, he will be activate to the next 2016 blocks?
678 2016-10-27T19:25:29 <sipa> parse error
679 2016-10-27T19:25:30 <jtimon> one thing about #8994 related to wumpus' point about regtest among trusted peers... one can select -chain=custom -chainpetname=mysharedsecret and people without access to mysharedsecret won't be able to create the genesis block locally
680 2016-10-27T19:25:43 <BlueMatt> Frederic94500: we're in the middle of a meeting, please go to #bitcoin
681 2016-10-27T19:26:01 <jtimon> for the hash of the genesis block depends on -chainpetname
682 2016-10-27T19:26:06 <wumpus> luke-jr: in a way it's similar to travis, you have to configure the environment and the building happens on their build servers
683 2016-10-27T19:26:16 <wumpus> luke-jr: no need to run ubuntu yourself
684 2016-10-27T19:26:36 <jonasschnelli> Luke-Jr: there are also meta-generator that auto-generated deb/PPA and fedora, etc. out of one script/conf
685 2016-10-27T19:26:47 <BlueMatt> wumpus: only in theory....the upload tool stuff is really a bitch to get installed on non-debian systems
686 2016-10-27T19:26:55 <luke-jr> :x
687 2016-10-27T19:27:17 *** Frederic94500 has quit IRC
688 2016-10-27T19:27:24 <wumpus> BlueMatt: haha that's sad, I didn't know
689 2016-10-27T19:27:34 <petertodd> jtimon: I like the idea of a shared secret vs. pubkey based testnet, as it makes it clear that it's only for testing, not doing some kind of "bankchain" sillyness
690 2016-10-27T19:27:58 *** pedrobranco has quit IRC
691 2016-10-27T19:28:05 <jtimon> well, signed blocks have other advantages for testing, but it's definitely more dsiruptive
692 2016-10-27T19:28:07 *** gabridome has quit IRC
693 2016-10-27T19:28:16 <wumpus> bitcoin.org change is merged
694 2016-10-27T19:29:08 <petertodd> jtimon: also, a hmac based thing may be easier to implement it - can be done by just changing the most-work chain test to require XOR key == 0; doesn't require any datastructures to change
695 2016-10-27T19:29:41 <jtimon> you can just share a chainparams.conf file and when if someone decides to load your testnet with too much work, s/mychainname/mychainname2/ and you start again I guess
696 2016-10-27T19:29:47 <wumpus> right, changing the block header structure is what makes it scary
697 2016-10-27T19:30:53 <petertodd> wumpus: s/scary/a lot of work/ :)
698 2016-10-27T19:31:12 <gmaxwell> topic: suggestion final alert stuff.
699 2016-10-27T19:31:12 <jtimon> petertodd: not hmac, the chainpetname is simply used for the genesis block timestamp (ie replacing "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"), see https://github.com/bitcoin/bitcoin/pull/8994/commits/ee3a9e4ed986a3aef84b0e081a31d91237d53294
700 2016-10-27T19:31:21 <wumpus> I mean more s/scary/high risk/
701 2016-10-27T19:31:31 <sipa> petertodd: it's surprisingly little work, but it's hard to do in a way that is 1) clean 2) runtime selectable 3) reviewable
702 2016-10-27T19:31:35 <wumpus> the implementation work is not so bad, review, sure
703 2016-10-27T19:31:38 <sipa> petertodd: pick 2
704 2016-10-27T19:31:50 <petertodd> fwiw, I use this same kind of hmac auth trick in open timestamps so calendar servers can use clients as a last-ditch backup, without having the servers actually sign anything in a non-repudiatable way
705 2016-10-27T19:31:51 <jtimon> we could make other chainparams count for the genesis block hash
706 2016-10-27T19:32:04 *** cryptapus has quit IRC
707 2016-10-27T19:33:10 <wumpus> I mean introducing some union into CBlockHeader would mean there'd be a risk of regression even in the non-testing case
708 2016-10-27T19:33:25 <petertodd> wumpus: ah, yes, good point
709 2016-10-27T19:33:28 <jtimon> petertodd: well, I find it more scary than painful too, at least the way I'm doing it with the union (there's also a less scary way that uses more memory in mainnet and another one that is simply way way way too disruptive)
710 2016-10-27T19:33:46 <petertodd> wumpus: I'm wrong - that is scary
711 2016-10-27T19:33:52 <btcdrak> sipa: you have to thank harding! he wrote it all.
712 2016-10-27T19:35:15 <kanzure> what is remaining re: final alert things?
713 2016-10-27T19:35:24 <kanzure> was the page on one of the .org sites merged
714 2016-10-27T19:35:55 <jtimon> topic suggestion: are we removing the use of checkpoints for progress estimation?
715 2016-10-27T19:35:55 <gmaxwell> kanzure: we're not on that toopic now.
716 2016-10-27T19:36:24 <gmaxwell> topic suggestion: My work removing checkpoints _completely_.
717 2016-10-27T19:36:45 <wumpus> #topic removing checkpoints
718 2016-10-27T19:37:24 <gmaxwell> I have a branch that is removing checkpoints. Haven't totally taken them out yet because I need to replace progress estimation.
719 2016-10-27T19:37:46 <gmaxwell> It's not hard to do that, just takes a little twiddling.
720 2016-10-27T19:37:50 <wumpus> that's good news - progress estimation is probably the least interesting use of them
721 2016-10-27T19:38:00 <gmaxwell> https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints
722 2016-10-27T19:38:01 <wumpus> yea
723 2016-10-27T19:38:11 <wumpus> #link https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints
724 2016-10-27T19:38:47 <gmaxwell> There are three main components: Removal of checkpoints for IBD test. This is a no brainer. Removal of checkpoints for script checking-- this depends on benchmark results, as we discussed perhaps 4 meethings ago. and the third:
725 2016-10-27T19:38:50 <wumpus> did you run into something difficult / uncertain?
726 2016-10-27T19:39:42 <gmaxwell> The last use is avoiding header flooding. I came up with a tidy way to do this, I think, but it requires an implicit consensus change but I think it is very trivial and obviously fine. But likely to delay things.
727 2016-10-27T19:39:43 <wumpus> what about the DoS protection?
728 2016-10-27T19:40:07 <wumpus> consensus change, as in a softfork?
729 2016-10-27T19:40:14 <morcos> do tell
730 2016-10-27T19:40:20 <gmaxwell> not a softfork. I'm telling.
731 2016-10-27T19:40:38 <gmaxwell> My changes introduce a constant in chain params which is the known amount of work in the best chain at ~release time. The IBD check uses this, we've talked about using that before for some checkpoint like things.
732 2016-10-27T19:41:34 <gmaxwell> So I propose that once we have any header chain that has at least that much work in it, we do not accept any more blocks with difficulty under 16 million-- which is roughly equal to about 10 commercially available mining devices.
733 2016-10-27T19:41:35 <petertodd> note that from the point of view of consensus this is technically speaking no different than making bitcoin core come with a set of blockchain data
734 2016-10-27T19:41:49 <jtimon> isn't the minimum difficulty check a softfork?
735 2016-10-27T19:42:06 <gmaxwell> This is a consenus change because the chain could never fall below difficulty 16 million in the future, but an unobservable one... as observing it would require the difficulty fall below 16 million. :)
736 2016-10-27T19:42:10 <wumpus> petertodd: well it wouldn't lock in specific blocks as the checkpoints do
737 2016-10-27T19:42:10 <petertodd> er, gregs #2 thing makes my statement invalid :)
738 2016-10-27T19:42:40 <jtimon> gmaxwell: yeah, it's a softfork in the pedantic sense
739 2016-10-27T19:42:42 <petertodd> wumpus: right, I mean, w/o the minimum diff thing, the effect would be no different than ensuring bitcoin core shipped with blockchain data
740 2016-10-27T19:42:45 <gmaxwell> jtimon: in a sense, but an unobservable one. Yes.
741 2016-10-27T19:42:45 <jeremyrubin> I don't think that's great...
742 2016-10-27T19:43:03 <jeremyrubin> Can't difficulty fall that low under a soft fork to a different PoW?
743 2016-10-27T19:43:16 <jeremyrubin> (not that that should happen)
744 2016-10-27T19:43:19 <petertodd> jeremyrubin: yes, and at that point your idea of what bitcoin is is so insecure as to be useless
745 2016-10-27T19:43:22 <gmaxwell> jeremyrubin: then you take out the rule.
746 2016-10-27T19:43:30 <jtimon> like really imposing the 21 M limit, that was a softfork too, but no need to use bip9 to deploy I guess
747 2016-10-27T19:43:40 <petertodd> jtimon: +1
748 2016-10-27T19:43:43 <Chris_Stewart_5> wouldn't that be a hard fork to remove it if it was enforced?
749 2016-10-27T19:43:53 <gmaxwell> the 16 million number was just a result of a tidy amount with bitmasking that also is really infeasable to attack but also trivial to mine... 10 devices.
750 2016-10-27T19:44:11 <petertodd> Chris_Stewart_5: yes, removiing is a hard fork, but remember we're talking about a situation where bitcoin as you know it is useless, so tha'ts irrelevant IMO
751 2016-10-27T19:44:24 <gmaxwell> If someone worried that 16 million were too high, there is a pretty broad range that the number could reasonable be set in.
752 2016-10-27T19:44:54 <petertodd> gmaxwell: honestly, I'd be inclined to go even higher - 10 machines is absolutely nothing
753 2016-10-27T19:45:18 <gmaxwell> Anything over 100k would pretty much halt any real risk headerflooding, with current hardware. 16M adds a good amount of headroom.
754 2016-10-27T19:45:22 *** gabridome has joined #bitcoin-core-dev
755 2016-10-27T19:45:24 <Chris_Stewart_5> but in jeremyrubin example if we are soft forkign to a different PoW that doesn't necessarily hold true, does it? Perhaps I don't understand circumstances of forking to another PoW though..
756 2016-10-27T19:45:25 *** gabridome has quit IRC
757 2016-10-27T19:45:36 <jeremyrubin> petertodd: I disagree, but that's more of a wizards topic
758 2016-10-27T19:45:50 <jtimon> gmaxwell: are you sure you want to change CheckBlockHeader instead of CheckProofOfWork ?
759 2016-10-27T19:45:53 <morcos> gmaxwell: i'm not so sure about that.. isn't the abilitity to soft fork to a different PoW something we might want to preserve?
760 2016-10-27T19:45:57 <petertodd> Chris_Stewart_5: a "soft-fork" to a different PoW isn't really a soft-fork, because the old clients are now horribly insecure
761 2016-10-27T19:46:10 <jeremyrubin> petertodd: e.g., something like tadge's proof of idle
762 2016-10-27T19:46:11 <gmaxwell> Chris_Stewart_5: softforking to a new pow is not really a softfork. In any case: keeping it at least that high would require only 10 devices, and ... any old nodes in that world could have their chain redone by those same 10 devices.
763 2016-10-27T19:46:23 <petertodd> morcos: there is no such thing as a soft-fork to a different proof-of-work - doing that doesn't have the security characteristics of a soft-fork
764 2016-10-27T19:46:25 <gmaxwell> morcos: it is preserved.
765 2016-10-27T19:46:33 <gmaxwell> to the extent that it exists.
766 2016-10-27T19:46:34 <morcos> give how hard hard forks are.. imagine there was a contentious HF that took majority hash power.. might the minority not want to be able to softfork away without having to agree on a HF
767 2016-10-27T19:46:46 <jtimon> Chris_Stewart_5: yeah if you want a different pow just hardfork
768 2016-10-27T19:46:49 *** gabridome has joined #bitcoin-core-dev
769 2016-10-27T19:46:58 <gmaxwell> Imagine the diff floor is 1. okay, then the diff goes down to 1. okay.. now I start up a 2011 asic miner and immediately break all those un upgraded nodes.
770 2016-10-27T19:47:01 <morcos> ok, i need to think about it more.. but i think we should analyze all those scenarios
771 2016-10-27T19:47:21 <gmaxwell> morcos: but thats also why my figure is ~10 devices and not 10,000 devices. :)
772 2016-10-27T19:47:43 <gmaxwell> In any case. I think it's fairly easy to understand. And I think the solution basically has all the properties that we want.
773 2016-10-27T19:47:48 <petertodd> morcos: again, this is a scenario where bitcoin as you know it is horribly insecure - anyone with >10 machines could attack your min-diff chain. I had a high enough credit limit as a student to buy more machines than that. :)
774 2016-10-27T19:47:51 <gmaxwell> But I expected thought and discussion on it.
775 2016-10-27T19:48:12 <BlueMatt> gmaxwell: ideally we would like to add the property that someone cant flood you during IBD, but to be fair we also suffer from DoS issues there now
776 2016-10-27T19:48:24 <petertodd> gmaxwell: if hardware improves, do we up the min diff again? IMO that'd be reasonable
777 2016-10-27T19:48:31 <morcos> petertodd: not if you've softforked in other PoW requirements that the attackers don't have the hashing or whateve rto produce
778 2016-10-27T19:48:42 <gmaxwell> BlueMatt: So hold up there.
779 2016-10-27T19:49:01 <gmaxwell> BlueMatt: I think what I propos has _exactly_ as good protection for that as we currently have, if not somewhat better.
780 2016-10-27T19:49:09 <Chris_Stewart_5> And this solves header flooding because it requires the attacker to provide headers with ATLEAST that much difficulty, correct?
781 2016-10-27T19:49:18 <BlueMatt> gmaxwell: didnt disagree, only suggested that ideally we'd fix the issues we have now
782 2016-10-27T19:49:18 <petertodd> morcos: but again, because that's not really a soft-fork, might as well do a small hardfork at that point to drop the requirement for SHA2 PoW at some point wel before just 10 machines are needed
783 2016-10-27T19:49:19 <gmaxwell> BlueMatt: right now we won't accept lower difficulty blocks after we've validated up to a paritcular checkpoint.
784 2016-10-27T19:49:30 <gmaxwell> (okay I'll still explain as other people might miss this)
785 2016-10-27T19:49:51 <gmaxwell> So you can consider two cases: one where the first peer you fetch from is an attacker, and one where the first peer is honest.
786 2016-10-27T19:50:10 <morcos> petertodd: i need to think about that.. but i imagine it might always be easier to soft fork, even under adverse scenario like that
787 2016-10-27T19:50:11 <gmaxwell> If the first peer is an attacker, you'll get header flooded now or under my proposal. (but at least it's just a one time initial install exposure)
788 2016-10-27T19:50:33 <BlueMatt> gmaxwell: well, not sure its better since the "frst checkpoint" is "known amount of work in the best chain at ~release time" instead of a few along the way to 300k
789 2016-10-27T19:50:51 <gmaxwell> If the first peer is not an attacker, in my propoal you'll quickly have all the headers and blocked from any attacks. Also no less good than now.
790 2016-10-27T19:50:53 <BlueMatt> (under first-peer-is-evil attacks, but ok)
791 2016-10-27T19:50:57 *** achow101_ has quit IRC
792 2016-10-27T19:51:00 <gmaxwell> BlueMatt: but my proposal needs only headers.
793 2016-10-27T19:51:16 <gmaxwell> oh under first peer is attacker
794 2016-10-27T19:51:17 <petertodd> morcos: anyway, good to do up some deployment scenarios regardless to explain how that'd work
795 2016-10-27T19:51:17 <BlueMatt> oh, i thought we applied checkpoints against headers now
796 2016-10-27T19:51:18 <BlueMatt> nvm
797 2016-10-27T19:51:49 <sipa> BlueMatt: we do; after passing a certain checkpoint, we don't accept headers that fork off before that checkpoint
798 2016-10-27T19:52:06 <BlueMatt> ok, lets take this offline
799 2016-10-27T19:52:11 <BlueMatt> suggested additional topics?
800 2016-10-27T19:52:13 <gmaxwell> Okay, thats the overview.
801 2016-10-27T19:52:42 <gmaxwell> I suggested the final alert. I suppose I should coordinate with achow and cobra to get the thing up and alert out. Any reasons to hold off?
802 2016-10-27T19:53:38 <jtimon> mhmm, pindexBestHeader->nChainWork < UintToArith256(consensusParams.nMinimumChainWork) ? consensusParams.powLimit : consensusParams.powLimitLater
803 2016-10-27T19:53:38 <jtimon> what about instead... block.nHeight < consensusParams.highPowLimitHeight ? consensusParams.powLimit : consensusParams.powLimitLater
804 2016-10-27T19:53:39 <wumpus> #topic the final alert
805 2016-10-27T19:53:53 <wumpus> no reason IMO
806 2016-10-27T19:53:55 <btcdrak> gmaxwell: please get it over with.
807 2016-10-27T19:54:39 <gmaxwell> Okay. will coordinate.
808 2016-10-27T19:55:13 <gmaxwell> jtimon: that would make it trivial for an attacker to capture you on a fake chain.
809 2016-10-27T19:55:38 <gmaxwell> jtimon: just feed you a chain of diff 1 blocks of that height.. and now you won't accept the low diff blocks on the real chain anymore.
810 2016-10-27T19:56:48 <jtimon> gmaxwell: how am I prevented from handling reorgs in the same way as you?
811 2016-10-27T19:57:14 <sipa> jtimon: creating many blocks is easy. creating much work is hard
812 2016-10-27T19:57:43 <gmaxwell> anyting left in the meeting (I'll continue this convo after)
813 2016-10-27T19:57:49 <jtimon> what I think it's add less risk since consensusParams.highPowLimitHeight is fixed but nMinimumChainWork is expected to chain with each release, no?
814 2016-10-27T19:58:24 <jtimon> I must be missing something, I don't see the vulnerability that my proposed change introduces
815 2016-10-27T19:58:26 <wumpus> ok, that concludes the meeting I think
816 2016-10-27T19:58:34 <wumpus> #endmeeting
817 2016-10-27T19:58:34 <lightningbot> Meeting ended Thu Oct 27 19:58:34 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
818 2016-10-27T19:58:34 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.html
819 2016-10-27T19:58:34 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.txt
820 2016-10-27T19:58:34 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.log.html
821 2016-10-27T19:59:07 <btcdrak> party time?
822 2016-10-27T19:59:11 <BlueMatt> gmaxwell: wait, so how is it better? the only practical difference i see is that you need to get a headers chain up to today before getting protection, instead of only up to checkpoints
823 2016-10-27T19:59:16 <BlueMatt> but that shouldnt matter much
824 2016-10-27T19:59:27 <gmaxwell> jtimon: if you start a node and connect to an evil node. The evil node can feed you 500000 blocks at diff 1 and then you will not reorg onto the mainchain anymore.
825 2016-10-27T19:59:56 <jtimon> yes, how my proposed change makes your branch more vulnerable to that attack is what I don't see
826 2016-10-27T20:00:17 <jtimon> why wouldn't I reorg to the most work change?
827 2016-10-27T20:00:31 <gmaxwell> Because you won't even process the first block in that chain.
828 2016-10-27T20:00:34 *** d_t has joined #bitcoin-core-dev
829 2016-10-27T20:00:39 <sipa> jtimon: because you'll reject the low-difficulty headers from the real chain you get later
830 2016-10-27T20:00:41 <jtimon> just like your branch without my proposed change, I think
831 2016-10-27T20:00:58 *** murch has joined #bitcoin-core-dev
832 2016-10-27T20:01:08 <jtimon> mhmm, no, say highPowLimitHeight is the current height whatever it is
833 2016-10-27T20:01:15 <gmaxwell> No. My branch does not activate until you have enough work to be the real chain at the time of the release.
834 2016-10-27T20:01:50 <gmaxwell> jtimon: yes, 436182. Say it's that.
835 2016-10-27T20:02:04 <gmaxwell> Attacker computes 500000 diff 1 headers, and gives you that.
836 2016-10-27T20:02:08 <jtimon> right, and mine activates at a fixed height, say 436182
837 2016-10-27T20:02:16 <gmaxwell> Under my code you would sitll reorg to the best chain.
838 2016-10-27T20:02:19 <jtimon> ok, I accept that chain
839 2016-10-27T20:02:29 <jtimon> then when I see the real one I reorg, no?
840 2016-10-27T20:02:29 <gmaxwell> Under your code you would not reorg to the best chain.
841 2016-10-27T20:02:33 <gmaxwell> No.
842 2016-10-27T20:02:41 <jtimon> why not?
843 2016-10-27T20:02:45 <sipa> jtimon: no, you'll reject the low-difficulty headers once you pass the watermark
844 2016-10-27T20:02:56 <gmaxwell> You will reach 500,000 and now you will reject blocks with low difficulty. So when an honest node sends you block 1 of the real chain you will reject it.
845 2016-10-27T20:03:01 <sipa> jtimon: because this is a fix to the otherwise existing DoS of being able to feed someone low-difficulty headers
846 2016-10-27T20:03:11 <jtimon> oh, we have limits on reorg, right, sorry, I get it, thanks
847 2016-10-27T20:03:19 <sipa> no, we don't have limits on reorg
848 2016-10-27T20:03:20 <gmaxwell> We don't have limits on reorg.
849 2016-10-27T20:03:28 <jtimon> mhm, let me read again
850 2016-10-27T20:03:34 <sipa> we just reject headers that are too low difficulty once we know we're past that stafe
851 2016-10-27T20:03:38 <sipa> *stage
852 2016-10-27T20:04:08 <jtimon> " So when an honest node sends you block 1 of the real chain you will reject it." not if the block is height < 436182
853 2016-10-27T20:04:30 <gmaxwell> if you don't reject low diff headers someone can exaust your memory/disk with header flooding.
854 2016-10-27T20:05:00 <gmaxwell> which the code you were quoting protect against but wouldn't if it were a height check.
855 2016-10-27T20:06:42 <jtimon> don't I reject them more than you? ie in your first version nMinimumChainWork will be total work at 436182, then in the next release, total work at a higher height, etc. I always reject low diff after 436182
856 2016-10-27T20:06:56 <jtimon> I don't get it but let's move on I will think more about it
857 2016-10-27T20:07:16 *** waxwing has quit IRC
858 2016-10-27T20:07:21 *** Guyver2 has joined #bitcoin-core-dev
859 2016-10-27T20:07:50 <sipa> jtimon: being past 436182 does not mean you're on the right chain
860 2016-10-27T20:07:50 <sipa> an attacker can veriy easily create such a long chain
861 2016-10-27T20:08:08 *** Guyver2 has left #bitcoin-core-dev
862 2016-10-27T20:08:15 <sipa> creating as much work of the real 43612 chain is nearly impossible
863 2016-10-27T20:08:18 <jtimon> sipa: right it means the min diff is higher from now on
864 2016-10-27T20:08:26 <jtimon> right
865 2016-10-27T20:08:43 <sipa> jtimon: if yhe min difficulty is more than 1 you will reject the early part of the real chain!!!
866 2016-10-27T20:09:04 <sipa> because the real chain has diff 1 in the beginning
867 2016-10-27T20:09:05 <jtimon> and "my code" will always prefer the real chain because it's more work
868 2016-10-27T20:09:05 <Chris_Stewart_5> Not sure if this this is a good question or not, but is this something deployed with BIP9?
869 2016-10-27T20:09:24 <jtimon> sipa: no, the early part of the real chain is height < 436182 !
870 2016-10-27T20:09:29 *** waxwing has joined #bitcoin-core-dev
871 2016-10-27T20:10:02 <sipa> jtimon: we DO NOT want to accept just any header below height 436182
872 2016-10-27T20:10:18 <sipa> jtimon: that is exactly the DoS attack this change is intended to fix
873 2016-10-27T20:10:57 *** Guyver2 has joined #bitcoin-core-dev
874 2016-10-27T20:11:07 <sipa> jtimon: maybe you're missing this: once you have *ANY* chain with chainwork above the limit, you reject *every* header below the new difficulty
875 2016-10-27T20:11:15 <sipa> even in an entirely unrelated chain
876 2016-10-27T20:11:31 <BlueMatt> oh, damn, something i should've brought up in the meeting - ProcessNewBlock's CValidationState& argument - its really fucking strange. So its used to communicate either a) Errors (ie out of disk, block pruned, etc) or b) AcceptBlock (ie CheckBlock, ContextualCheckBlock, etc) Invalids()...it is NOT used to return success for the current (or any) block, and even if ActivateBestChain finds an invalid block, it will not set the
877 2016-10-27T20:11:31 <BlueMatt> CValidationState argument as such. 1) a few places in the code get this wrong and 2) this means you have to duplicate logic between the call-site as well as to CValidationInterface's BlockChecked()
878 2016-10-27T20:11:46 <BlueMatt> does anyone object to me making it call BlockChecked for AcceptBlock failures?
879 2016-10-27T20:11:53 *** achow101_ has joined #bitcoin-core-dev
880 2016-10-27T20:11:55 <jtimon> I don't seee how pindexBestHeader->nChainWork < UintToArith256(consensusParams.nMinimumChainWork) ? consensusParams.powLimit : consensusParams.powLimitLater) saves us from the attacker sending us 500k diff 1 blocks just like with my change, that line only saves you from accepting mindiff blocks afterwards
881 2016-10-27T20:12:20 <BlueMatt> so then ProcessNewBlock would only use its CValidationState argument (which would then just be optional) in case of failures, not invalid blocks
882 2016-10-27T20:12:34 <sipa> jtimon: it only protects us once we see the real chain
883 2016-10-27T20:12:57 <sipa> jtimon: your proposal can trigger even if we don't have the real chain
884 2016-10-27T20:14:50 <jtimon> right, and with my chain it only protects us for blocks that have height > 436182, the change is not "globally activated forever" in this case, if a shorter chain with more work appears, you may go back below height 436182 and the min diff blocks would be accepted again
885 2016-10-27T20:15:24 <sipa> so you haven't solved the issue
886 2016-10-27T20:15:58 <jtimon> note I didn't say pindexBestHeader->nHeight but block.nHeight (that is, the header you are checking now)
887 2016-10-27T20:16:38 <sipa> you're really doing somwthing completely different
888 2016-10-27T20:16:58 <jtimon> well, that line is supposed to save us from min diff blocks in the future, no?
889 2016-10-27T20:18:03 <sipa> your change does not prevent that
890 2016-10-27T20:18:20 <sipa> someone can keep spamming low-height headers in your proposal
891 2016-10-27T20:19:02 <jtimon> oh, and you won't ignore them if they're < 436182, sorry, I finally get it
892 2016-10-27T20:19:05 <jtimon> thanks
893 2016-10-27T20:20:03 <instagibbs> Congrats! Managed to sleep exactly through meeting time.
894 2016-10-27T20:20:39 <BlueMatt> ok, I'm removing CValidationState from ProcessNewBlock
895 2016-10-27T20:21:38 <jtimon> sorry BlueMatt wasn't listening
896 2016-10-27T20:22:21 <btcdrak> sipa: remember to update your http://bitcoin.sipa.be/ver9-2k.png graphs :)
897 2016-10-27T20:22:27 <sipa> instagibbs: and through the release
898 2016-10-27T20:22:31 <sipa> btcdrak: indeed!
899 2016-10-27T20:23:29 *** pedrobranco has joined #bitcoin-core-dev
900 2016-10-27T20:23:32 <instagibbs> Yeah missed all the action.
901 2016-10-27T20:24:33 *** achow101_ has quit IRC
902 2016-10-27T20:25:35 <sipa> BlueMatt: iirc the only reason for CVS in PNB is to return system failure conditions
903 2016-10-27T20:26:08 <BlueMatt> sipa: nope, its also used to return AcceptBlock errors
904 2016-10-27T20:26:09 <BlueMatt> sipa: also, its never checked for system failure conditions
905 2016-10-27T20:27:02 <jtimon> BlueMatt: not sure what you propose to do CValidationState is usually to return error details from functions that already return false when they fail most of the time (if we returned 0 for success and anything else for error codes we wouldn't need it)
906 2016-10-27T20:27:40 *** pedrobranco has quit IRC
907 2016-10-27T20:33:20 <BlueMatt> jtimon: https://github.com/bitcoin/bitcoin/commit/a4f82de1bdde644e9bad4c524b638dd5bd4d69f7
908 2016-10-27T20:33:43 <BlueMatt> also, the fact that you can access commits via that url when they arent in the bitcoin/bitcoin repo is freaky
909 2016-10-27T20:35:25 <jtimon> yeah, seems it makes sense to move it down to ProcessNewBlock it is certainly the higher level function where I have ever used it
910 2016-10-27T20:36:40 *** belcher has joined #bitcoin-core-dev
911 2016-10-27T20:38:27 <BlueMatt> anyway, I'll pr it after https://github.com/bitcoin/bitcoin/pull/8969, I know suhas was waiting on it
912 2016-10-27T20:38:28 <jtimon> BlueMatt: yeah, I definitely like that commit
913 2016-10-27T20:38:57 *** skyraider has joined #bitcoin-core-dev
914 2016-10-27T20:39:18 <jtimon> yeah I only briefly looked at that one, sorry
915 2016-10-27T20:40:06 <murch> quick question: Does 0.13.1 already include functions for creation of SegWit transactions?
916 2016-10-27T20:40:22 <BlueMatt> yes
917 2016-10-27T20:40:29 <BlueMatt> so did 0.13.0
918 2016-10-27T20:40:46 <BlueMatt> (its all gated on segwit being activated, so it works on testnet)
919 2016-10-27T20:41:31 <murch> ah okay, thanks
920 2016-10-27T20:56:06 *** Chris_Stewart_5 has quit IRC
921 2016-10-27T21:09:55 *** Chris_Stewart_5 has joined #bitcoin-core-dev
922 2016-10-27T21:11:53 *** Victor_sueca has joined #bitcoin-core-dev
923 2016-10-27T21:13:34 *** jl2012 has quit IRC
924 2016-10-27T21:14:04 *** Victorsueca has quit IRC
925 2016-10-27T21:20:35 <BlueMatt> wait, did we un-support qt5?
926 2016-10-27T21:20:42 <BlueMatt> wasnt there talk of deprecating it?
927 2016-10-27T21:26:10 *** Guyver2 has quit IRC
928 2016-10-27T21:35:24 *** wasi has quit IRC
929 2016-10-27T21:45:58 <cfields_> BlueMatt: you mean qt4?
930 2016-10-27T21:48:26 <BlueMatt> uhh, yes
931 2016-10-27T21:49:45 <cfields_> BlueMatt: i'd say it's pretty well deprecated already. iirc the discussion was about completely dropping support
932 2016-10-27T21:52:46 <BlueMatt> mmm, nvm, realized it only breaks precise, which was broken by c++11
933 2016-10-27T21:56:19 <michagogo> Ack, missed another meeting :-/
934 2016-10-27T21:56:34 <michagogo> Did it start late, or just late ping?
935 2016-10-27T21:57:49 <luke-jr> I think at this point, once Qt4 becomes a burden we can probably drop it?
936 2016-10-27T21:57:52 <luke-jr> BlueMatt: what breaks precise?
937 2016-10-27T21:58:06 <BlueMatt> there is no qt4 on precise
938 2016-10-27T21:58:18 <BlueMatt> also, the boost in precise doesnt compile in c++11 mode
939 2016-10-27T21:58:55 <luke-jr> so don't build qt4?
940 2016-10-27T21:59:14 <luke-jr> I thought we didn't use any boost that had ABI changes for C++11
941 2016-10-27T21:59:41 <BlueMatt> luke-jr: https://svn.boost.org/trac/boost/ticket/6198
942 2016-10-27T22:00:20 <luke-jr> compile with GCC?
943 2016-10-27T22:00:40 *** kadoban has quit IRC
944 2016-10-27T22:00:42 <BlueMatt> the gcc in precise does not support c++11
945 2016-10-27T22:00:46 <luke-jr> ugh
946 2016-10-27T22:01:06 *** kadoban has joined #bitcoin-core-dev
947 2016-10-27T22:01:34 <BlueMatt> the ppa currently has an empty dummy package for precise
948 2016-10-27T22:01:37 <BlueMatt> because fuck precise
949 2016-10-27T22:01:44 <luke-jr> uh
950 2016-10-27T22:01:49 <luke-jr> at least leave the old version?
951 2016-10-27T22:02:02 <BlueMatt> no
952 2016-10-27T22:02:06 <luke-jr> â¦
953 2016-10-27T22:02:25 <luke-jr> patch the code to #define size size_arg? >_<
954 2016-10-27T22:02:34 <BlueMatt> no
955 2016-10-27T22:02:45 <BlueMatt> feel free to create the debian/ folder and send it to me and I'll upload
956 2016-10-27T22:02:51 <BlueMatt> I'm not fighting with it to make precise work
957 2016-10-27T22:02:54 <luke-jr> XD
958 2016-10-27T22:03:11 <luke-jr> wait, to do the PPA you just upload the debian folder?
959 2016-10-27T22:03:20 <BlueMatt> and the original source archive
960 2016-10-27T22:03:25 <BlueMatt> (ie git archive)
961 2016-10-27T22:04:00 <BlueMatt> and two other strange metadata files
962 2016-10-27T22:09:22 <luke-jr> any reason we can't get gitian to produce the files needing to upload? <.<
963 2016-10-27T22:09:41 <BlueMatt> gitian? they're all in the source tree
964 2016-10-27T22:09:46 <BlueMatt> except signed by my pgp key
965 2016-10-27T22:10:05 *** kadoban has quit IRC
966 2016-10-27T22:10:11 <BlueMatt> git archive + contrib/debian (though i have some mods i make to contrib/debian....i keep forgetting to re-upstream those, i used to keep it synced)
967 2016-10-27T22:10:14 <luke-jr> so we don't need to do https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage ?
968 2016-10-27T22:11:04 *** MarcoFalke has left #bitcoin-core-dev
969 2016-10-27T22:11:54 <BlueMatt> yes, we do do that, but building a source package results in a) the git archive tar itself b) a tar of the debian/ folder and c) two files which pretty much just list some metadata extracted from the debian folder and hashes of the other files, which is signed by my pgp key
970 2016-10-27T22:12:20 <BlueMatt> so, no, its really entirely useless to do anything in gitian for this
971 2016-10-27T22:15:27 *** blkdb has quit IRC
972 2016-10-27T22:16:05 *** blkdb has joined #bitcoin-core-dev
973 2016-10-27T22:17:15 *** pedrobranco has joined #bitcoin-core-dev
974 2016-10-27T22:20:09 *** cdecker has quit IRC
975 2016-10-27T22:21:18 *** pedrobranco has quit IRC
976 2016-10-27T22:33:11 *** lclc has quit IRC
977 2016-10-27T22:36:22 <gmaxwell> when did we back off the checkblocks check? was that in 0.13.0 or 0.13.1?
978 2016-10-27T22:59:50 <BlueMatt> heh, 66/130 connections segwit (with 52/8 blocked)
979 2016-10-27T22:59:55 <BlueMatt> guess preferential peering works =D
980 2016-10-27T23:15:32 <sipa> gmaxwell: 0
981 2016-10-27T23:15:38 <sipa> gmaxwell: 0.13.1
982 2016-10-27T23:15:58 *** dstadulis has joined #bitcoin-core-dev
983 2016-10-27T23:16:11 <gmaxwell> sipa: explaines people saying it stats so much faster.
984 2016-10-27T23:16:26 <sipa> ha
985 2016-10-27T23:16:31 <gmaxwell> sipa: how many connections does your node have?
986 2016-10-27T23:17:06 <gmaxwell> I am 124/124.
987 2016-10-27T23:21:42 *** dstadulis has quit IRC
988 2016-10-27T23:22:04 *** dstadulis has joined #bitcoin-core-dev
989 2016-10-27T23:26:45 <sipa> compiling 0.13.1 now
990 2016-10-27T23:27:11 <sipa> i was on 0.13.0 i think
991 2016-10-27T23:29:49 <BlueMatt> ok, all ppas are built and published
992 2016-10-27T23:34:34 *** echonaut has quit IRC
993 2016-10-27T23:34:34 *** echonaut1 has joined #bitcoin-core-dev
994 2016-10-27T23:38:31 <gmaxwell> BlueMatt: if the ppas are downloadable, go post on reddit?
995 2016-10-27T23:43:42 *** d_t has quit IRC
996 2016-10-27T23:43:48 *** dstadulis has quit IRC
997 2016-10-27T23:49:15 *** justan0theruser has joined #bitcoin-core-dev
998 2016-10-27T23:51:13 *** justanotheruser has quit IRC
999 2016-10-27T23:51:51 <luke-jr> Why does bitcoincore announcements ML include tracking?
1000 2016-10-27T23:57:23 <sipa> ?
1001 2016-10-27T23:57:54 <luke-jr> there's an invisible <img> with a tracking id at the bottom
1002 2016-10-27T23:58:22 <luke-jr> it attempts to load the image from the internet, thus informing the webserver it was read