12016-10-27T00:00:01 <gmaxwell> Eligius 0.589615
22016-10-27T00:00:04 <gmaxwell> Telco 0.709605
32016-10-27T00:01:18 <TD-Linux> gmaxwell, well 0.246 btc loss is directly proportional to their block size
42016-10-27T00:02:05 *** Chris_Stewart_5 has quit IRC
52016-10-27T00:02:19 <gmaxwell> Indeed.
62016-10-27T00:02:30 <Lightsword> gmaxwell, do you have stats on kanoâs ckpool and ckâs solopool?
72016-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.
82016-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.
92016-10-27T00:03:14 *** Chris_Stewart_5 has joined #bitcoin-core-dev
102016-10-27T00:03:14 <gmaxwell> s/fine/find/
112016-10-27T00:04:48 <sipa> gmaxwell: over how many blocks is this data?
122016-10-27T00:04:48 <gmaxwell> 67
132016-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
142016-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.
152016-10-27T00:06:24 <gmaxwell> e.g. "you mined fees consistent with forming your block 30 seconds ago"
162016-10-27T00:18:48 *** PRab has quit IRC
172016-10-27T00:19:19 *** a_meteorite has quit IRC
182016-10-27T00:39:42 *** fengling has quit IRC
192016-10-27T00:47:06 *** Ylbam_ has quit IRC
202016-10-27T01:00:18 *** echonaut has quit IRC
212016-10-27T01:00:43 *** echonaut has joined #bitcoin-core-dev
222016-10-27T01:00:44 *** randy-waterhouse has quit IRC
232016-10-27T01:04:21 *** randy-waterhouse has joined #bitcoin-core-dev
242016-10-27T01:04:30 *** randy-waterhouse has joined #bitcoin-core-dev
252016-10-27T01:14:16 <jeremyrubin> gmaxwell: can you normalize by block size?
262016-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
272016-10-27T01:25:26 <midnightmagic> sorry for the mixup
282016-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.
292016-10-27T01:32:59 <gmaxwell> which now shows the small blocks as slightly negative, which makes sense, since they took the highest fee txn.
302016-10-27T01:33:13 *** randy-waterhouse has quit IRC
312016-10-27T01:42:02 <luke-jr> gmaxwell: that looks like the fallback where Eloipool has to guess the template itself until GBT completes
322016-10-27T01:42:18 <luke-jr> it's supposed to be based on the previous valid template, not sure what's going wrong there
332016-10-27T01:45:51 *** DigiByteDev has joined #bitcoin-core-dev
342016-10-27T01:46:17 *** randy-waterhouse has joined #bitcoin-core-dev
352016-10-27T01:46:51 *** randy-waterhouse has joined #bitcoin-core-dev
362016-10-27T01:55:10 <gmaxwell> luke-jr: fix.
372016-10-27T02:07:50 *** fengling has joined #bitcoin-core-dev
382016-10-27T02:19:35 *** Giszmo has quit IRC
392016-10-27T02:20:44 *** randy-waterhouse has quit IRC
402016-10-27T02:26:22 *** PRab has joined #bitcoin-core-dev
412016-10-27T02:27:09 *** tulip has joined #bitcoin-core-dev
422016-10-27T02:37:10 *** PRab has quit IRC
432016-10-27T02:55:57 *** fengling has quit IRC
442016-10-27T03:11:23 *** PRab has joined #bitcoin-core-dev
452016-10-27T03:26:18 *** midnightmagic has quit IRC
462016-10-27T03:28:23 *** Chris_Stewart_5 has quit IRC
472016-10-27T03:34:33 *** jtimon has quit IRC
482016-10-27T03:45:22 *** midnightmagic has joined #bitcoin-core-dev
492016-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
502016-10-27T03:51:05 <luke-jr> >_<
512016-10-27T04:18:09 *** a_meteorite has joined #bitcoin-core-dev
522016-10-27T04:21:13 *** a_meteorite has quit IRC
532016-10-27T04:21:40 *** a_meteorite has joined #bitcoin-core-dev
542016-10-27T04:32:27 *** aalex has quit IRC
552016-10-27T04:32:47 *** aalex has joined #bitcoin-core-dev
562016-10-27T04:42:41 *** nickler has quit IRC
572016-10-27T04:48:12 *** d_t has quit IRC
582016-10-27T04:53:27 *** nickler has joined #bitcoin-core-dev
592016-10-27T05:10:08 *** tulip has quit IRC
602016-10-27T05:25:36 *** DigiByteDev has quit IRC
612016-10-27T05:30:11 *** harrymm has quit IRC
622016-10-27T05:34:21 <whphhg> Sup blockstream
632016-10-27T05:35:08 *** fengling has joined #bitcoin-core-dev
642016-10-27T05:44:10 *** harrymm has joined #bitcoin-core-dev
652016-10-27T05:45:57 *** DigiByteDev has joined #bitcoin-core-dev
662016-10-27T05:50:36 *** wasi has quit IRC
672016-10-27T05:50:43 *** d_t has joined #bitcoin-core-dev
682016-10-27T05:55:12 *** d_t has quit IRC
692016-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
702016-10-27T06:11:22 <GitHub177> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/a32d7c23fc0e...03422e564b55
712016-10-27T06:11:22 <GitHub177> bitcoin/0.13 1d12463 Michael Ford: Update release notes for dropping osx 10.7 support
722016-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...
732016-10-27T06:15:31 *** a_meteorite has quit IRC
742016-10-27T06:21:03 <wumpus> would be interesting to check this against univalue http://seriot.ch/parsing_json.html
752016-10-27T06:22:38 <jonasschnelli> wumpus: heh. Yes. Someone should turn this into unit-tests.
762016-10-27T06:22:44 <jonasschnelli> Maybe open an easy-to-implement issue?
772016-10-27T06:22:53 <jonasschnelli> though not sure how easy it is.
782016-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 :)
792016-10-27T06:24:18 <jonasschnelli> Indeed...
802016-10-27T06:24:58 <wumpus> but even without that it'd be interesting to see how it compares
812016-10-27T06:26:19 <wumpus> hopefully there's nothing in the "parser crashed" category, we've done quite a lot of fuzzing
822016-10-27T06:29:04 *** a_meteorite has joined #bitcoin-core-dev
832016-10-27T06:31:00 <jonasschnelli> I'm glad all JSON operations are hidden behind the HTTP Auth...
842016-10-27T06:31:11 <jonasschnelli> With rest it gets a bit more risky...
852016-10-27T06:31:42 <wumpus> I've purposedly kept JSON parsing out of REST
862016-10-27T06:31:50 <wumpus> just simple query strings
872016-10-27T06:32:33 <jonasschnelli> Ah. Right. Only output.
882016-10-27T06:33:23 <wumpus> output far from as much of a risk as parsing
892016-10-27T06:33:27 <wumpus> +is
902016-10-27T06:33:46 <wumpus> still possible for there to be bugs there, but much less scope for trickery
912016-10-27T06:35:54 *** DigiByteDev has quit IRC
922016-10-27T06:36:18 *** DigiByteDev has joined #bitcoin-core-dev
932016-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.
942016-10-27T06:38:00 <btcdrak> oh, I see wumpus found the PR already :-)
952016-10-27T06:38:38 <wumpus> https://github.com/bitcoin/bitcoin/issues/9028
962016-10-27T06:38:57 <wumpus> btcdrak: if tests are failing due to a trailing space you're doing comparison in the wrong domain
972016-10-27T06:39:21 <wumpus> I agree with your pull request but not that it should cause (non-JSON-pedanticness) tests to fail :)
982016-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
992016-10-27T06:43:24 *** Ylbam_ has joined #bitcoin-core-dev
1002016-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.
1012016-10-27T06:46:27 <wumpus> I understand, but there is no standard way to pretty-print JSON
1022016-10-27T06:46:48 <wumpus> having the tests depend on how the jSON lib happens to do pretty printing is fragile
1032016-10-27T06:47:05 <wumpus> ideally the tests should compare the data, not the text
1042016-10-27T06:48:36 <btcdrak> yes, I agree.
1052016-10-27T06:49:59 <wumpus> I think we have some similar problems in other places, which complicated switching JSON libraries last time
1062016-10-27T06:50:30 <wumpus> not a huge proiority to change ofcourse
1072016-10-27T06:50:44 <btcdrak> but while indentation may not have a standard, I think trailing whitespace has no place in any output.
1082016-10-27T06:50:57 *** DigiByteDev has quit IRC
1092016-10-27T06:51:48 <luke-jr> but what if you want to embed a Whitespace program? :p
1102016-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
1112016-10-27T06:52:21 <btcdrak> yup
1122016-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
1132016-10-27T06:52:45 <wumpus> and spend hours debugging that problem instead of something that matters :)
1142016-10-27T06:53:12 <wumpus> luke-jr: ah yes, white-space steganogrpaphy
1152016-10-27T06:53:28 <btcdrak> haha yes.
1162016-10-27T06:53:29 <btcdrak> well again, I found changing a 1 to a 2 isnt that straight forward....
1172016-10-27T06:53:49 <btcdrak> wumpus: can you restart https://travis-ci.org/bitcoin/bitcoin/builds/170827031, dunno why Travis borked
1182016-10-27T06:53:57 *** BashCo has quit IRC
1192016-10-27T06:54:19 <luke-jr> wumpus: do you have any expectation of further merges before tagging?
1202016-10-27T06:54:38 <wumpus> luke-jr: if there are further improvements to the release notes
1212016-10-27T06:55:41 <wumpus> otherwise, no
1222016-10-27T07:04:03 *** dcousens has joined #bitcoin-core-dev
1232016-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?
1242016-10-27T07:06:33 <jonasschnelli> s/_Var/_var
1252016-10-27T07:07:52 <luke-jr> I'd rather 'var' than '_var' for public stuff at least
1262016-10-27T07:08:04 <luke-jr> I don't see a problem with o->var or o->fVar
1272016-10-27T07:08:20 *** wasi has joined #bitcoin-core-dev
1282016-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.
1292016-10-27T07:15:52 <jonasschnelli> this-> clusters to code to much IMO, ... using _var seems acceptable to me.
1302016-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.)
1312016-10-27T07:16:24 <luke-jr> we're already using _var for local variables to avoid shadowing :/
1322016-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?!
1332016-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
1342016-10-27T07:20:00 *** Samdney has joined #bitcoin-core-dev
1352016-10-27T07:21:40 *** d_t has joined #bitcoin-core-dev
1362016-10-27T07:22:18 *** d_t has joined #bitcoin-core-dev
1372016-10-27T07:26:06 *** BashCo has joined #bitcoin-core-dev
1382016-10-27T07:29:11 <wumpus> no, we have no naming convention for instance variables, just use whatever makes sense in the context
1392016-10-27T07:29:58 <jonasschnelli> I personally like this-> but I know most people don't like that
1402016-10-27T07:30:05 <jonasschnelli> I'll try _
1412016-10-27T07:30:11 <wumpus> at least the qt coding convention recommends against using m_ or _ or such
1422016-10-27T07:31:08 <jonasschnelli> The m prefix would not allow to use the fVar, etc. prefix.
1432016-10-27T07:31:15 <jonasschnelli> mfBool would look strange. :)
1442016-10-27T07:31:19 <jonasschnelli> i'd prefere _fBool
1452016-10-27T07:31:23 <wumpus> m_fBool that would be, then
1462016-10-27T07:31:27 *** Samdney has quit IRC
1472016-10-27T07:31:31 <jonasschnelli> m_ yes... why not
1482016-10-27T07:31:57 <sipa> wumpus: what does the qt coding convention suggest?
1492016-10-27T07:32:13 <wumpus> sipa: no specific one, just use this->name where necessary
1502016-10-27T07:32:34 <wumpus> in many cases there's no need to name instance variables any differently from local variables
1512016-10-27T07:33:04 <jonasschnelli> wumpus: readability?
1522016-10-27T07:33:06 <sipa> luke-jr: where do we use _var for local variables?
1532016-10-27T07:33:08 <wumpus> e.g. https://forum.qt.io/topic/150/member-variable-naming-convention-in-qt-and-the-qtdn-wiki
1542016-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
1552016-10-27T07:33:45 <sipa> luke-jr: underscores are used in several places for formal parameters to avoid colliding with field variables
1562016-10-27T07:33:48 <wumpus> but I don't know, I hate these kind of discussions
1572016-10-27T07:33:59 <jonasschnelli> Reading through new code i often found myself checking if the variable is local or instance-wide
1582016-10-27T07:34:00 <sipa> haha
1592016-10-27T07:34:04 <jonasschnelli> heh
1602016-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
1612016-10-27T07:34:48 <jonasschnelli> sipa: yes. If. now open main.cpp. :)
1622016-10-27T07:34:55 <wumpus> jonasschnelli: that probably means the code itself is badly commented / structured
1632016-10-27T07:35:15 <wumpus> a shallow 'fix' like renaming instance variables won't help much in that case except check a checkbox
1642016-10-27T07:36:30 <sipa> jonasschnelli: so help refactoring those functions to be morw readable :)
1652016-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
1662016-10-27T07:37:02 <wumpus> it's the typical pointy-haired boss solution to
1672016-10-27T07:37:06 <wumpus> "code is unreadable"
1682016-10-27T07:37:10 <wumpus> FORCE a coding style!
1692016-10-27T07:37:57 <wumpus> now you have nicely formatted ununderstandable code :)
1702016-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?
1712016-10-27T07:38:22 *** nanotube has quit IRC
1722016-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.
1732016-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 :-)
1742016-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.
1752016-10-27T07:41:17 <dcousens> improving readability*
1762016-10-27T07:41:31 *** d_t has quit IRC
1772016-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
1782016-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)
1792016-10-27T07:43:00 *** whphhg has left #bitcoin-core-dev
1802016-10-27T07:44:05 *** nanotube has joined #bitcoin-core-dev
1812016-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>
1822016-10-27T07:46:08 *** wasi has quit IRC
1832016-10-27T07:47:26 <wumpus> time to tag 0.13.1 final?
1842016-10-27T07:47:49 <sipa> i'm about to fall asleep
1852016-10-27T07:48:04 <wumpus> I'll wait until you're asleep then
1862016-10-27T07:48:08 <dcousens> ha
1872016-10-27T07:48:33 * sipa goes into ACPI standby
1882016-10-27T07:48:38 <wumpus> NN
1892016-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.
1902016-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.
1912016-10-27T08:00:49 <gmaxwell> FWIW, my testing with RC3 all looks fine.
1922016-10-27T08:01:28 <wumpus> hahahaa yes Github151 for president
1932016-10-27T08:03:11 * luke-jr ponders writing-in Github151 on his ballot
1942016-10-27T08:05:06 <gmaxwell> many states require a write in candidate register with them before being eligible to be counted. :(
1952016-10-27T08:05:27 *** moli has quit IRC
1962016-10-27T08:05:40 <luke-jr> I was joking anyway :p
1972016-10-27T08:05:51 <gmaxwell> I think this is intended to help avoid "Which John Smith did we just elect?"
1982016-10-27T08:06:30 <luke-jr> heh
1992016-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
2002016-10-27T08:11:21 <wumpus> maybe they should use a blockchain for registering candidates *ducks*
2012016-10-27T08:11:40 <luke-jr> sadly, some people think that makes sense
2022016-10-27T08:13:40 <gmaxwell> wumpus: so, final?
2032016-10-27T08:21:58 *** laurentmt has joined #bitcoin-core-dev
2042016-10-27T08:22:36 *** laurentmt has quit IRC
2052016-10-27T08:22:43 <wumpus> yes, let's do it
2062016-10-27T08:22:47 <wumpus> sipa's asleep
2072016-10-27T08:25:07 <wumpus> * [new tag] v0.13.1 -> v0.13.1
2082016-10-27T08:25:15 <gmaxwell> \O/
2092016-10-27T08:25:49 <luke-jr> oh wow, rc3 just deleted my entire home directory â¦â¦â¦â¦â¦.. jk :P
2102016-10-27T08:26:54 <gmaxwell> cool "0.13.1 addresses user's concerns with excessive disk space consumption."
2112016-10-27T08:28:08 <wumpus> hehe, always the positive side
2122016-10-27T08:28:14 <luke-jr> lol
2132016-10-27T08:28:27 <jonasschnelli> heh
2142016-10-27T08:28:31 <warren> that sounds like one particular user had concerns
2152016-10-27T08:30:09 *** Guyver2 has joined #bitcoin-core-dev
2162016-10-27T08:32:33 <jonasschnelli> huh! Why can this happen: http://paste.ubuntu.com/23387379/
2172016-10-27T08:34:10 <wumpus> huh, that looks like a bug in assertlockheld
2182016-10-27T08:34:12 <jonasschnelli> maybe a different wallet instance...
2192016-10-27T08:34:19 <wumpus> ah yes ofcourse
2202016-10-27T08:34:49 <wumpus> maybe the lock naming should include instance pointer
2212016-10-27T08:35:01 <jonasschnelli> Yes. My fault... different instances
2222016-10-27T08:35:29 * jonasschnelli curses pwalletMain
2232016-10-27T08:36:51 <luke-jr> hm, I didn't encounter such issues with multiwallet? O.o
2242016-10-27T08:40:44 <wumpus> did you run with lock debugging on?
2252016-10-27T08:41:26 <wumpus> (--enable-debug will do)
2262016-10-27T08:44:04 <luke-jr> no
2272016-10-27T08:44:16 <luke-jr> does the assertlockheld only work with that?
2282016-10-27T08:44:33 <wumpus> yes
2292016-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
2302016-10-27T08:55:22 *** btcfanboi has joined #bitcoin-core-dev
2312016-10-27T09:02:38 *** JackH has joined #bitcoin-core-dev
2322016-10-27T09:07:59 <michagogo> ðð
2332016-10-27T09:09:00 * michagogo sends a message and requests that his computer be turned on
2342016-10-27T09:09:41 <wumpus> wake-over-IRC?
2352016-10-27T09:15:24 *** Yogh has joined #bitcoin-core-dev
2362016-10-27T09:15:43 *** Yogh has left #bitcoin-core-dev
2372016-10-27T09:19:22 *** Guyver2 has quit IRC
2382016-10-27T09:37:27 <michagogo> wumpus: wake-over-iMessage
2392016-10-27T09:37:40 <michagogo> (Poweron, really)
2402016-10-27T09:37:56 <michagogo> Anyway, build running now
2412016-10-27T09:38:11 <michagogo> As usual, sigs will auto-PR
2422016-10-27T09:40:59 <michagogo> I wonder how quickly we'll get sigs
2432016-10-27T09:41:08 <michagogo> Think release will come today?
2442016-10-27T09:43:15 *** cdecker has joined #bitcoin-core-dev
2452016-10-27T09:48:47 *** mkarrer_ has joined #bitcoin-core-dev
2462016-10-27T09:52:16 *** mkarrer has quit IRC
2472016-10-27T10:01:40 *** n1ce has quit IRC
2482016-10-27T10:04:27 *** n1ce has joined #bitcoin-core-dev
2492016-10-27T10:12:31 *** btcfanboi has quit IRC
2502016-10-27T10:13:29 *** cdecker has quit IRC
2512016-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
2522016-10-27T10:14:21 *** harrymm has quit IRC
2532016-10-27T10:19:56 <michagogo> Ooh, just got my hacktoberfest email
2542016-10-27T10:24:04 <gmaxwell> https://blockchain.info/charts/utxo-count?timespan=60days and fees are back down to ~0.5 btc/block...
2552016-10-27T10:24:57 *** Ylbam_ has quit IRC
2562016-10-27T10:26:33 *** jl2012 has quit IRC
2572016-10-27T10:27:19 *** jl2012 has joined #bitcoin-core-dev
2582016-10-27T10:27:37 *** cdecker has joined #bitcoin-core-dev
2592016-10-27T10:27:53 *** Ylbam_ has joined #bitcoin-core-dev
2602016-10-27T10:32:16 *** harrymm has joined #bitcoin-core-dev
2612016-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
2622016-10-27T10:43:33 *** harrymm has quit IRC
2632016-10-27T10:46:17 <gmaxwell> andytoshi: wumpus: http://seriot.ch/parsing_json.html < json test vectors.
2642016-10-27T10:48:28 <wumpus> gmaxwell: yeah came up earlier today already there's even an issue :) https://github.com/bitcoin/bitcoin/issues/9028
2652016-10-27T10:49:34 *** a_meteorite has quit IRC
2662016-10-27T10:49:55 *** a_meteorite has joined #bitcoin-core-dev
2672016-10-27T10:58:19 *** harrymm has joined #bitcoin-core-dev
2682016-10-27T11:06:14 *** fengling has quit IRC
2692016-10-27T11:11:56 *** n1ce has quit IRC
2702016-10-27T11:18:02 <jonasschnelli> Just got a report that prioritisetransaction does not work on 0.12?
2712016-10-27T11:18:38 <wumpus> on 0.12? or 0.13?
2722016-10-27T11:19:10 <jonasschnelli> The reporter reported its working on 0.13 but not on 0.12
2732016-10-27T11:20:55 <luke-jr> do we care then?
2742016-10-27T11:22:43 <wumpus> I don't
2752016-10-27T11:22:54 <wumpus> was briefly in shock because of 0.13.1 :)
2762016-10-27T11:25:31 <luke-jr> jonasschnelli: the reporter is a miner? why aren't they on 0.13.0?
2772016-10-27T11:25:49 <luke-jr> sounds suspiciously like BU
2782016-10-27T11:26:02 <wumpus> yea
2792016-10-27T11:28:40 *** n1ce has joined #bitcoin-core-dev
2802016-10-27T11:31:44 <jonasschnelli> i don't care as well
2812016-10-27T11:32:17 <jonasschnelli> but good to know >if< 0.12 is not working and if so, why 0.13 is working
2822016-10-27T11:33:42 *** rebroad has joined #bitcoin-core-dev
2832016-10-27T11:34:48 <Victorsueca> 0.12 is supposed to be still supported, should we backport a fix for this?
2842016-10-27T11:35:11 <wumpus> if someone writes a fix I'm happy to merge it
2852016-10-27T11:36:23 <luke-jr> Eligius didn't use 0.12 for long, but I am pretty certain prioritise worked
2862016-10-27T11:37:47 <luke-jr> (and I do check GBT returns the txid when I prioritise stuff)
2872016-10-27T11:38:01 <luke-jr> so IMO it's probably either BU nonsense or PEBKAC
2882016-10-27T11:38:21 *** cryptapus has joined #bitcoin-core-dev
2892016-10-27T11:38:22 *** cryptapus has joined #bitcoin-core-dev
2902016-10-27T11:52:19 <jonasschnelli> first we would need to double-check if its not working on 0.12. It was just a report.
2912016-10-27T11:52:50 <jonasschnelli> There are some RPC tests.. although not sure when we have added those.
2922016-10-27T12:00:13 *** moli has joined #bitcoin-core-dev
2932016-10-27T12:04:32 *** a_meteorite has quit IRC
2942016-10-27T12:04:43 *** a_meteor_ has joined #bitcoin-core-dev
2952016-10-27T12:05:14 <wumpus> I'm surprised if it really doesn't work and we only hear about it now
2962016-10-27T12:06:54 *** a_meteor_ has quit IRC
2972016-10-27T12:07:23 *** a_meteorite has joined #bitcoin-core-dev
2982016-10-27T12:07:56 *** n1ce has quit IRC
2992016-10-27T12:09:39 *** n1ce has joined #bitcoin-core-dev
3002016-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
3012016-10-27T12:11:19 *** a_meteorite has quit IRC
3022016-10-27T12:11:32 <wumpus> btcdrak: https://github.com/bitcoin/bitcoin/pull/9032
3032016-10-27T12:12:35 *** a_meteorite has joined #bitcoin-core-dev
3042016-10-27T12:14:05 <btcdrak> wumpus: interesting
3052016-10-27T12:14:19 *** a_meteorite has joined #bitcoin-core-dev
3062016-10-27T12:14:25 <wumpus> I'm not even sure the second step should be a fatal error or just a warning
3072016-10-27T12:14:46 <wumpus> a_meteorite: please fix your IRC client, you're generating too many join/part messages
3082016-10-27T12:14:52 <btcdrak> wumpus: this was really helpful
3092016-10-27T12:14:53 <btcdrak> https://github.com/bitcoin/bitcoin/pull/9023
3102016-10-27T12:15:43 <wumpus> yes, but I think it makes the test too noisy in the pass case
3112016-10-27T12:15:59 <wumpus> printing a diff when the test fails makes sense though
3122016-10-27T12:16:11 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3132016-10-27T12:16:39 <btcdrak> maybe should shield the pass stuff with a -verbose flag? or ditch the pass logs entirely?
3142016-10-27T12:17:08 <wumpus> yes I'd say ditch the pass logs, ideally tests are silent if nothing is wrong
3152016-10-27T12:17:11 <wumpus> (esp in travis)
3162016-10-27T12:17:31 *** jtimon has joined #bitcoin-core-dev
3172016-10-27T12:18:34 * luke-jr publishes Knots 0.13.1 and goes to bed :P
3182016-10-27T12:19:33 *** a_meteorite has quit IRC
3192016-10-27T12:19:47 <wumpus> btcdrak: this may be already what it does, I was confused by all the logging stuff
3202016-10-27T12:20:06 *** a_meteorite has joined #bitcoin-core-dev
3212016-10-27T12:20:15 *** ChanServ sets mode: +o wumpus
3222016-10-27T12:20:30 <luke-jr> poor a_meteorite is going to fall to Earth
3232016-10-27T12:20:34 <btcdrak> iirc it prints pass and fail. lemme rerun quickly
3242016-10-27T12:20:55 *** wumpus sets mode: +b *!*@unaffiliated/ameteorite/x-000000001
3252016-10-27T12:21:00 <wumpus> luke-jr: hah
3262016-10-27T12:21:06 <wumpus> btcdrak: but also in non-verbose mode?
3272016-10-27T12:21:18 *** Chris_Stewart_5 has quit IRC
3282016-10-27T12:21:32 <btcdrak> ok just checked, by default passes are silent
3292016-10-27T12:21:42 <btcdrak> if you add -v then you get full output
3302016-10-27T12:21:50 <wumpus> ok, and diffs are printed on failure?
3312016-10-27T12:21:58 <btcdrak> https://www.irccloud.com/pastebin/fuxIut4y/
3322016-10-27T12:22:28 <wumpus> even in non-verbose mode?
3332016-10-27T12:22:56 *** a_meteorite has quit IRC
3342016-10-27T12:23:23 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3352016-10-27T12:24:11 <btcdrak> oh wait, my cherry-pick failed and I didnt notice :-p
3362016-10-27T12:24:25 <wumpus> gah
3372016-10-27T12:24:33 <btcdrak> so it is noisy without -v
3382016-10-27T12:24:39 <btcdrak> https://www.irccloud.com/pastebin/hd69OPZ4/
3392016-10-27T12:24:41 <wumpus> sigh
3402016-10-27T12:24:50 * wumpus re-edits his post again
3412016-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
3422016-10-27T12:26:46 <btcdrak> wumpus: I commented too
3432016-10-27T12:27:15 *** MarcoFalke has joined #bitcoin-core-dev
3442016-10-27T12:28:04 <btcdrak> wumpus: otherwise the errors are great e.g.
3452016-10-27T12:28:07 <btcdrak> https://www.irccloud.com/pastebin/xL5cqNGo/
3462016-10-27T12:29:36 <achow101> oh hey, a tag!
3472016-10-27T12:29:42 <wumpus> yes that seems useful
3482016-10-27T12:30:56 *** wasi has joined #bitcoin-core-dev
3492016-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
3502016-10-27T12:36:42 *** Chris_Stewart_5 has quit IRC
3512016-10-27T12:38:50 <wumpus> btcdrak: does -v actually work for you?
3522016-10-27T12:39:10 <btcdrak> wumpus: it doesnt do anything different under his patch
3532016-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
3542016-10-27T12:41:30 <btcdrak> same here, hmm
3552016-10-27T12:42:24 <wumpus> figured it out
3562016-10-27T12:52:17 *** PaulCapestany has quit IRC
3572016-10-27T12:56:24 <GitHub49> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/2e2388a5cbb9a6e101b36e4501698fec538a5738
3582016-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...
3592016-10-27T12:58:49 <GitHub138> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/a49b4a75a1b671492e65eed17d6894d85ea5ebfd
3602016-10-27T12:58:50 <GitHub138> bitcoin/master a49b4a7 Wladimir J. van der Laan: doc: Add release notes for 0.13.1 release
3612016-10-27T12:59:35 <timothy> does 0.13.1 requires new or different libraries?
3622016-10-27T12:59:39 <timothy> to built
3632016-10-27T12:59:40 <GitHub66> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a49b4a75a1b6...83234d4d1723
3642016-10-27T12:59:41 <GitHub66> bitcoin/master ba26d41 Michael Ford: Update build notes for dropping osx 10.7 support...
3652016-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)...
3662016-10-27T12:59:48 <wumpus> compared to what?
3672016-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
3682016-10-27T12:59:52 <timothy> 0.13.0
3692016-10-27T13:00:08 <wumpus> yes there was at least a patch to boost
3702016-10-27T13:00:19 <timothy> so can't I use vanilla boost?
3712016-10-27T13:00:32 <wumpus> sure, you always can
3722016-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
3732016-10-27T13:04:05 *** PaulCapestany has joined #bitcoin-core-dev
3742016-10-27T13:07:19 *** laurentmt has joined #bitcoin-core-dev
3752016-10-27T13:07:19 *** laurentmt has quit IRC
3762016-10-27T13:09:12 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3772016-10-27T13:12:53 *** wasi has quit IRC
3782016-10-27T13:16:13 *** laurentmt has joined #bitcoin-core-dev
3792016-10-27T13:16:18 *** laurentmt has quit IRC
3802016-10-27T13:19:25 *** whphhg has joined #bitcoin-core-dev
3812016-10-27T13:19:36 <whphhg> Hej, is there a Bitcoin Unlimited channel on freenode?
3822016-10-27T13:23:16 <timothy> lol
3832016-10-27T13:23:30 <rabidus_> lol
3842016-10-27T13:23:39 <timothy> it's like entering on FBI channel and ask for drug
3852016-10-27T13:26:44 <PatBoy> hahahah
3862016-10-27T13:26:56 *** atroxes has quit IRC
3872016-10-27T13:29:25 <wumpus> rofl
3882016-10-27T13:31:25 *** wasi has joined #bitcoin-core-dev
3892016-10-27T13:32:28 *** Chris_Stewart_5 has quit IRC
3902016-10-27T13:33:21 <whphhg> Lol, I wasn't aware it was that bad. :o
3912016-10-27T13:33:22 *** atroxes has joined #bitcoin-core-dev
3922016-10-27T13:39:40 <BlueMatt> wumpus: so do i wait to update the ppa or just do it today?
3932016-10-27T13:41:27 <wumpus> BlueMatt: let me see, how many gitian sigs do we have now
3942016-10-27T13:42:19 <wumpus> three matching ones
3952016-10-27T13:42:43 <BlueMatt> i said today, not now....still eating breakfast :p
3962016-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
3972016-10-27T13:43:15 <btcdrak> Better not do it until the release actual announcement when we have everything done.
3982016-10-27T13:48:01 <BlueMatt> btcdrak: meh, i often do it early...otherwise i forget
3992016-10-27T13:48:19 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4002016-10-27T13:49:19 *** fengling has joined #bitcoin-core-dev
4012016-10-27T13:51:57 <Lauda> BlueMatt please ppa as soon as possible 0.13.0 took forever. :)
4022016-10-27T13:53:57 *** Chris_Stewart_5 has quit IRC
4032016-10-27T13:57:47 <btcdrak> Lauda: good point :-p
4042016-10-27T14:03:28 *** jl2012 has quit IRC
4052016-10-27T14:03:53 <michagogo> BlueMatt: is it all ready in terms of packaging, i.e. just a matter of pushing the button?
4062016-10-27T14:04:16 *** Ylbam_ has quit IRC
4072016-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?)
4082016-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
4092016-10-27T14:06:21 <michagogo> Or 48 or something
4102016-10-27T14:07:11 <michagogo> (Also, it's unfortunate that only cfields_ can produce the detached sigsâ¦)
4112016-10-27T14:10:55 <btcdrak> wumpus: I uploaded my gitian sigs
4122016-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
4132016-10-27T14:11:41 *** Giszmo has joined #bitcoin-core-dev
4142016-10-27T14:16:51 <michagogo> wumpus: re: #9028 (and in general), have you considered tagging some issues for Hacktoberfest?
4152016-10-27T14:17:03 <BlueMatt> 'tf is hacktoberfest?
4162016-10-27T14:17:13 <michagogo> ;;Google hacktoberfest
4172016-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>
4182016-10-27T14:17:23 <BlueMatt> also, isnt october over?
4192016-10-27T14:17:43 <michagogo> Well, almost
4202016-10-27T14:27:41 *** waxwing has quit IRC
4212016-10-27T14:28:33 *** waxwing has joined #bitcoin-core-dev
4222016-10-27T14:41:06 <wumpus> would be a bit too late I guess
4232016-10-27T14:42:33 <wumpus> (for hacktoberfest)
4242016-10-27T14:42:48 <wumpus> woohoo, 6 sigs all match
4252016-10-27T14:43:10 <wumpus> ping cfields_
4262016-10-27T14:44:00 *** whphhg has left #bitcoin-core-dev
4272016-10-27T14:47:35 <GitHub55> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/83234d4d1723...fea5e05a6380
4282016-10-27T14:47:36 <GitHub55> bitcoin/master 1c3ecc7 S. Matthew English: instance of 'mem pool' to 'mempool'...
4292016-10-27T14:47:36 <GitHub55> bitcoin/master fea5e05 Wladimir J. van der Laan: Merge #9029: instance of 'mem pool' to 'mempool'...
4302016-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
4312016-10-27T14:54:58 *** pedrobranco has joined #bitcoin-core-dev
4322016-10-27T14:56:13 *** luke-jr has quit IRC
4332016-10-27T14:56:16 *** AtashiCon has quit IRC
4342016-10-27T14:56:20 *** Arnavion3 has joined #bitcoin-core-dev
4352016-10-27T14:56:22 *** luke-jr has joined #bitcoin-core-dev
4362016-10-27T14:56:24 <sipa> BlueMatt: Oktoberfest is also mostly not in october :)
4372016-10-27T14:56:24 *** Arnavion3 is now known as AtashiCon
4382016-10-27T14:56:48 <BlueMatt> heh, true
4392016-10-27T15:04:40 <andytoshi> thanks gmaxwell (re json test vectors)
4402016-10-27T15:12:59 <kanzure> andytoshi: trying to save yourself some work on mimblewimble?
4412016-10-27T15:20:30 * michagogo waves at cfields_
4422016-10-27T15:27:53 * michagogo watches https://github.com/bitcoin-core/bitcoin-detached-sigs/tags
4432016-10-27T15:28:44 <achow101> michagogo: are we harassing cfields_ now to get the code signed sigs?
4442016-10-27T15:29:22 <michagogo> achow101: no need to harass, I think - he pushed his gitian sigs up
4452016-10-27T15:29:36 <michagogo> I assume the detached will be up shortly
4462016-10-27T15:30:02 <michagogo> BlueMatt: there are enough gitian builders around that it's probably safe to get the PPA ready
4472016-10-27T15:30:32 <BlueMatt> yea, busy fixing 8969 for now, will soon
4482016-10-27T15:30:40 <michagogo> BTW, has anyone here looked into Ubuntu's new "snap" packaging thing?
4492016-10-27T15:31:16 *** BCBot has quit IRC
4502016-10-27T15:34:29 *** fengling has quit IRC
4512016-10-27T15:35:10 *** BashCo has quit IRC
4522016-10-27T15:36:22 *** cryptapus has quit IRC
4532016-10-27T15:39:53 *** cryptapus has joined #bitcoin-core-dev
4542016-10-27T15:39:53 *** cryptapus has joined #bitcoin-core-dev
4552016-10-27T15:48:45 <michagogo> wumpus: I don't see the usual PR for the release notes on bitcoin.org
4562016-10-27T15:49:42 *** Chris_Stewart_5 has joined #bitcoin-core-dev
4572016-10-27T15:52:07 <achow101> are the release notes finalized yet?
4582016-10-27T15:56:34 <cfields_> hehe, i was working on the sigs while you guys were busy waving :)
4592016-10-27T15:56:49 <cfields_> gitian builders: v0.13.1 sigs are pushed
4602016-10-27T15:56:53 <michagogo> achow101: I think so, yeah
4612016-10-27T16:00:45 <michagogo> My sigs are pushed as well
4622016-10-27T16:01:31 <achow101> so are mine
4632016-10-27T16:01:54 <michagogo> wumpus: looks like the release is ready when you are
4642016-10-27T16:02:45 <btcdrak> segwit upgrading guide published today
4652016-10-27T16:02:46 <btcdrak> https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
4662016-10-27T16:04:30 <michagogo> https://github.com/bitcoin-core/bitcoincore.org/pull/241 needs updating
4672016-10-27T16:05:30 *** BashCo has joined #bitcoin-core-dev
4682016-10-27T16:06:31 <cfields_> btcdrak: you can add ckpool to the mining list. and the cgminer PR hasn't been merged yet.
4692016-10-27T16:07:12 <btcdrak> ok
4702016-10-27T16:08:49 *** rebroad has quit IRC
4712016-10-27T16:10:43 *** BCBot has joined #bitcoin-core-dev
4722016-10-27T16:10:55 <btcdrak> seems like the binaries will be ready today?
4732016-10-27T16:14:10 *** BCBot has quit IRC
4742016-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
4752016-10-27T16:17:32 <cfields_> btcdrak: technically just need 1 more match i think, which i'm sure will show up any minute
4762016-10-27T16:21:10 <michagogo> cfields_: that match is probably going to be wumpus
4772016-10-27T16:21:24 <michagogo> Who is the one that does the release anyway
4782016-10-27T16:23:27 *** laurentmt has joined #bitcoin-core-dev
4792016-10-27T16:26:57 *** laurentmt has quit IRC
4802016-10-27T16:35:37 <cfields_> btcdrak: thanks
4812016-10-27T16:36:43 <sipa> what does mf mean?
4822016-10-27T16:36:55 <sipa> "0.13.1 signed mf"
4832016-10-27T16:37:20 <MarcoFalke> my initials
4842016-10-27T16:37:26 <MarcoFalke> :P
4852016-10-27T16:37:36 <sipa> oh, of course
4862016-10-27T16:37:46 <cfields_> I read it as Samuel L. Jackson.
4872016-10-27T16:37:46 * sipa stupid
4882016-10-27T16:37:55 <sipa> ...?
4892016-10-27T16:39:13 <cfields_> as in: I've had it with these MarcoFalke snakes, on this MarcoFalke plane!
4902016-10-27T16:40:02 <sipa> i see.
4912016-10-27T16:45:51 *** cryptapus has quit IRC
4922016-10-27T16:47:18 *** cryptapus has joined #bitcoin-core-dev
4932016-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.
4942016-10-27T17:23:24 *** laurentmt has joined #bitcoin-core-dev
4952016-10-27T17:24:54 *** cryptapus has quit IRC
4962016-10-27T17:25:43 *** laurentmt has quit IRC
4972016-10-27T17:30:25 *** Ylbam_ has joined #bitcoin-core-dev
4982016-10-27T17:31:27 <wumpus> hahaha
4992016-10-27T17:35:51 *** cryptapus has joined #bitcoin-core-dev
5002016-10-27T17:41:15 *** belcher has quit IRC
5012016-10-27T17:43:44 *** jl2012 has joined #bitcoin-core-dev
5022016-10-27T17:54:34 *** dcousens has quit IRC
5032016-10-27T17:56:19 *** achow101_ has joined #bitcoin-core-dev
5042016-10-27T17:57:12 <achow101_> are we so lucky that the time from tag to release will be less than 12 hours this time>
5052016-10-27T17:57:13 <achow101_> ?
5062016-10-27T18:03:44 <btcdrak> achow101_: looks like everything has been done barring release notes and upload to bitcoin.org
5072016-10-27T18:04:01 <btcdrak> s/notes/announce/
5082016-10-27T18:04:23 <achow101_> :D
5092016-10-27T18:04:30 <btcdrak> meeting time? or is everyone down at the pub having a well deserved pint?
5102016-10-27T18:04:46 <achow101_> I think you're an hour early
5112016-10-27T18:05:00 <btcdrak> wait, did the clocks change?
5122016-10-27T18:05:17 <achow101_> idk, depends on your country
5132016-10-27T18:05:33 <btcdrak> automatic clock update so I would never know >_>
5142016-10-27T18:05:44 <btcdrak> this explains a lot...
5152016-10-27T18:06:26 <achow101_> dst ends for me next week
5162016-10-27T18:07:04 <sipa> it's one hour from now
5172016-10-27T18:07:24 <sipa> btcdrak: set it in your calendar as 7pm iceland time
5182016-10-27T18:10:52 *** frederic94500 has joined #bitcoin-core-dev
5192016-10-27T18:12:04 <morcos> jonasschnelli: i think apple gave us an idea. you should move the fee slider to the touch bar.
5202016-10-27T18:12:23 <btcdrak> sipa: let's all just move to Iceland.
5212016-10-27T18:12:33 <sipa> morcos: 'touch bar' ?
5222016-10-27T18:12:49 <morcos> what they replaced function keys with on the new macbook pros
5232016-10-27T18:12:53 <jonasschnelli> sipa: new MacBook Pro physical UX element
5242016-10-27T18:13:05 <jonasschnelli> A screen replaces the F function keys
5252016-10-27T18:13:13 <sipa> i don't understand
5262016-10-27T18:13:15 <BlueMatt> wtf is a "physical UX element"
5272016-10-27T18:13:16 <jonasschnelli> morcos: I need to watch the presentation
5282016-10-27T18:13:23 <BlueMatt> sipa: they replace the top line of your keyboard with an ipad
5292016-10-27T18:13:42 <jonasschnelli> http://photos.reportinglive.com/p/2016-10-27/f1477589812.jpg
5302016-10-27T18:13:56 <btcdrak> o.O
5312016-10-27T18:14:11 <sipa> i still don't understand what it means to move the fee slider
5322016-10-27T18:14:21 <achow101_> looks stupid
5332016-10-27T18:14:29 <morcos> there was some PR discussion about the right way for the fee slider to work in QT
5342016-10-27T18:14:36 <jeremyrubin> Let's add touchid support at least...
5352016-10-27T18:15:45 <btcdrak> what is touchid?
5362016-10-27T18:15:53 <achow101_> the fingerprint sensor stuff
5372016-10-27T18:16:16 <jeremyrubin> fingerprint sensor + secure enclave
5382016-10-27T18:16:52 <jonasschnelli> finger print has no plausible deniability
5392016-10-27T18:17:01 <gmaxwell> the lenovo x1s have a touchscreen at the top of the keyboard instead of fkeys, it's awful.
5402016-10-27T18:17:28 <BlueMatt> jonasschnelli: and your machine is..uhhh...covered in your fingerprints
5412016-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.
5422016-10-27T18:17:52 <sipa> BlueMatt: i'm sure my keyboard is already covered with fingerprints :)
5432016-10-27T18:17:56 <jonasschnelli> Right... adhesive tape is sufficient to unlock
5442016-10-27T18:18:15 <btcdrak> seems like security theatre
5452016-10-27T18:18:32 <jonasschnelli> Probably state sponsored move.. :)
5462016-10-27T18:18:46 <jeremyrubin> gmaxwell: it's a different thing than that kind
5472016-10-27T18:18:47 <jonasschnelli> You can now force everyone to unlock your HDD/SDD
5482016-10-27T18:18:53 <achow101_> btcdrak: mythbusters did an episode about fingerprint spoofing
5492016-10-27T18:18:54 <jeremyrubin> is that one on X1 even a screen?
5502016-10-27T18:19:16 <btcdrak> This was it in 2014 http://www.bbc.com/news/technology-30623611
5512016-10-27T18:19:25 <jeremyrubin> Also touchid doesn't usually replace password
5522016-10-27T18:20:38 <jonasschnelli> jeremyrubin: Yeah. But if you login with touchid after a cold-start... I guess it replaces passwords.
5532016-10-27T18:20:45 <jonasschnelli> It's probably different then on iOS
5542016-10-27T18:20:46 <btcdrak> I prefer passwords + smartcards
5552016-10-27T18:20:55 <jonasschnelli> Yes. FIDO enabled hardware wallet
5562016-10-27T18:20:59 <jonasschnelli> Works since 10.11 on OSX
5572016-10-27T18:21:01 *** gabridome has joined #bitcoin-core-dev
5582016-10-27T18:21:03 <sipa> fingerprint unlocking is so annoyingly convenient :(
5592016-10-27T18:21:09 <jonasschnelli> heh
5602016-10-27T18:21:26 <jonasschnelli> What I want is fingerprint & passphrase
5612016-10-27T18:22:20 <btcdrak> I want to keep my fingers
5622016-10-27T18:25:10 *** pedrobranco has quit IRC
5632016-10-27T18:25:40 *** pedrobranco has joined #bitcoin-core-dev
5642016-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
5652016-10-27T18:26:54 *** d9b4bef9 has quit IRC
5662016-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
5672016-10-27T18:28:08 *** d9b4bef9 has joined #bitcoin-core-dev
5682016-10-27T18:28:15 <sipa> but i guess it could speed up looking for the ones that aren't
5692016-10-27T18:28:17 <NicolasDorier> sipa: the thing that slow down is BIP30
5702016-10-27T18:28:24 <NicolasDorier> because we are checking for a negative
5712016-10-27T18:28:29 <NicolasDorier> so it is not in the cache
5722016-10-27T18:28:42 <sipa> we don't do that anymore, afaik
5732016-10-27T18:29:12 <sipa> only before bip34 activation
5742016-10-27T18:29:23 <NicolasDorier> oh checking that
5752016-10-27T18:29:31 *** frederic94500 has quit IRC
5762016-10-27T18:30:16 *** pedrobranco has quit IRC
5772016-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
5782016-10-27T18:31:41 *** Frederic94500 has joined #bitcoin-core-dev
5792016-10-27T18:32:18 <NicolasDorier> the commit on disk is in background on core right ?
5802016-10-27T18:32:36 <NicolasDorier> except TxUndo if I remember
5812016-10-27T18:41:03 *** nibor has joined #bitcoin-core-dev
5822016-10-27T18:44:17 *** BCBot has joined #bitcoin-core-dev
5832016-10-27T18:45:02 <NicolasDorier> mmh... well, I'll wait I reach later block mayb it's not the case
5842016-10-27T18:47:16 *** kangx has joined #bitcoin-core-dev
5852016-10-27T18:54:10 *** gabridome has quit IRC
5862016-10-27T19:00:25 *** whphhg has joined #bitcoin-core-dev
5872016-10-27T19:00:37 <jtimon> meeting...
5882016-10-27T19:01:16 <wumpus> congrats on 0.13.1 everyone!
5892016-10-27T19:01:21 * btcdrak rings the gong
5902016-10-27T19:01:23 <wumpus> #startmeeting
5912016-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.
5922016-10-27T19:01:23 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
5932016-10-27T19:01:26 <jtimon> 0.13.1 is out 18 mins ago! yay
5942016-10-27T19:01:40 <CodeShark> binaries?
5952016-10-27T19:01:42 <kanzure> btcdrak: looks like faq menu entry is working now https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
5962016-10-27T19:01:59 <jeremyrubin> here
5972016-10-27T19:02:26 <wumpus> CodeShark: https://bitcoin.org/bin/bitcoin-core-0.13.1/
5982016-10-27T19:02:27 * luke-jr wakes up
5992016-10-27T19:02:44 *** dermoth has joined #bitcoin-core-dev
6002016-10-27T19:02:46 <CodeShark> Nice!
6012016-10-27T19:02:49 <gmaxwell> https://www.reddit.com/r/Bitcoin/comments/59pt66/bitcoin_core_0131_released/
6022016-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
6032016-10-27T19:03:51 <wumpus> bitcoin.org should be updated after travis passes on https://github.com/bitcoin-dot-org/bitcoin.org/pull/1400
6042016-10-27T19:04:25 <morcos> congrats everyone!
6052016-10-27T19:04:31 <sipa> indeed!
6062016-10-27T19:04:53 <wumpus> woohoo!
6072016-10-27T19:05:03 <sipa> and thanks everyone for getting us this far
6082016-10-27T19:05:37 <luke-jr> wumpus: did we get the gitian builds already? is that a record? :o
6092016-10-27T19:05:54 <wumpus> luke-jr: yes, four signed builders IIRC
6102016-10-27T19:06:24 <luke-jr> or maybe it just feels like a record since it was the middle of the night for me
6112016-10-27T19:06:30 <jtimon> I'm trying the gitian builder script for the first time
6122016-10-27T19:06:33 <wumpus> it may be a record
6132016-10-27T19:06:43 <wumpus> very fast at least
6142016-10-27T19:07:09 <jtimon> btcdrak reminded me I have no good excuse for not doing gitian builds
6152016-10-27T19:07:33 <sipa> i haven't even started :(
6162016-10-27T19:08:20 <jtimon> well, I have never done it so it may take some time, but the sooner I learn...
6172016-10-27T19:08:22 <btcdrak> wumpus: I dont see a signed message from you with the binary hashes
6182016-10-27T19:08:44 <wumpus> BlueMatt: you can release your PPA now (if you didn't yet)
6192016-10-27T19:09:03 <wumpus> btcdrak: https://bitcoin.org/bin/bitcoin-core-0.13.1/SHA256SUMS.asc
6202016-10-27T19:09:04 <BlueMatt> wumpus: i have not yet, will try to get that out
6212016-10-27T19:09:23 <jonasschnelli> BlueMatt: don't forget to add libzmq
6222016-10-27T19:09:35 <harding> btcdrak: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-October/000023.html
6232016-10-27T19:09:37 <jonasschnelli> Some uses have complained about the missing ZMQ support
6242016-10-27T19:10:12 <BlueMatt> jonasschnelli: yup
6252016-10-27T19:11:30 <wumpus> ok, any other topics today than 0.13.1?
6262016-10-27T19:11:51 <kanzure> i was going to ask sipa or jtimon about libconsensus follow-up stuff
6272016-10-27T19:12:04 <sipa> i'm the wrong person to ask
6282016-10-27T19:12:16 <wumpus> I'm kind of tired so I wouldn't mind ending early :p
6292016-10-27T19:12:59 <jtimon> kanzure: nothing to report, nobody suggested anything to me or gave me any feedback since last week
6302016-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
6312016-10-27T19:13:24 <BlueMatt> few minutes late there, gmaxwell
6322016-10-27T19:13:27 <jtimon> been focusing on the signedblocks patch
6332016-10-27T19:13:32 <gmaxwell> Just noticed wumpus hadn't done it. :)
6342016-10-27T19:13:43 <sipa> maybe we can discuss signed blocks a bit
6352016-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.
6362016-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
6372016-10-27T19:14:10 <morcos> (signed blocks)
6382016-10-27T19:14:11 <gmaxwell> (I guess some are in and just need to backport to 0.13 branch.
6392016-10-27T19:14:21 <wumpus> no, it's not meant to replace the current testnet
6402016-10-27T19:14:24 <kanzure> re: testnet i also saw the suggestion of loading testnet params from json file
6412016-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
6422016-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.
6432016-10-27T19:15:11 <jtimon> what I have implemented is from .conf file, not .json file
6442016-10-27T19:15:11 <wumpus> indeed there should at least be a PoW testnet
6452016-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
6462016-10-27T19:15:47 <morcos> perhaps it would be possible for transactions to easily end up on both?
6472016-10-27T19:15:49 <kanzure> jtimon: didn't mean to recommend a specific file format; i was just pulling a thing from memory.
6482016-10-27T19:15:55 *** gabridome has joined #bitcoin-core-dev
6492016-10-27T19:16:05 <morcos> but maybe thats askign for trouble
6502016-10-27T19:16:06 <wumpus> yes the file format is completely not important
6512016-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
6522016-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"
6532016-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.
6542016-10-27T19:16:31 <sipa> and those aren't reconcilable, i think
6552016-10-27T19:16:56 <jtimon> that alone should be helpful for rapidly creating a new segwitnet (for the next thing) or whatever
6562016-10-27T19:17:03 <btcdrak> Blog post is up https://bitcoincore.org/en/2016/10/27/release-0.13.1/
6572016-10-27T19:17:13 <wumpus> one testnet is simply not enough for all testing scenarios
6582016-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.
6592016-10-27T19:17:19 <wumpus> btcdrak: awesome
6602016-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.
6612016-10-27T19:18:07 <wumpus> kanzure: right - within a trusted group using a regtest is just as useful as signed blocks
6622016-10-27T19:18:25 <kanzure> oh is that what the proposal is-- i'll have to go look. sorry.
6632016-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
6642016-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.
6652016-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.
6662016-10-27T19:19:57 <JackH> when will ubuntu ppa's be updated?
6672016-10-27T19:20:17 <BlueMatt> JackH: when i get to it (today)
6682016-10-27T19:20:29 <JackH> ah sweet, you are fast this time then
6692016-10-27T19:20:30 <sipa> btcdrak: nice, the timeline is cool
6702016-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?)
6712016-10-27T19:21:56 <wumpus> I think everyone can sign up to make PPAs
6722016-10-27T19:22:11 * btcdrak is reading scrollback
6732016-10-27T19:22:52 <BlueMatt> luke-jr: its not bad
6742016-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..
6752016-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
6762016-10-27T19:23:48 *** pedrobranco has joined #bitcoin-core-dev
6772016-10-27T19:25:07 <Frederic94500> #bitcoin If segwit doesn't activate, he will be activate to the next 2016 blocks?
6782016-10-27T19:25:29 <sipa> parse error
6792016-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
6802016-10-27T19:25:43 <BlueMatt> Frederic94500: we're in the middle of a meeting, please go to #bitcoin
6812016-10-27T19:26:01 <jtimon> for the hash of the genesis block depends on -chainpetname
6822016-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
6832016-10-27T19:26:16 <wumpus> luke-jr: no need to run ubuntu yourself
6842016-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
6852016-10-27T19:26:47 <BlueMatt> wumpus: only in theory....the upload tool stuff is really a bitch to get installed on non-debian systems
6862016-10-27T19:26:55 <luke-jr> :x
6872016-10-27T19:27:17 *** Frederic94500 has quit IRC
6882016-10-27T19:27:24 <wumpus> BlueMatt: haha that's sad, I didn't know
6892016-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
6902016-10-27T19:27:58 *** pedrobranco has quit IRC
6912016-10-27T19:28:05 <jtimon> well, signed blocks have other advantages for testing, but it's definitely more dsiruptive
6922016-10-27T19:28:07 *** gabridome has quit IRC
6932016-10-27T19:28:16 <wumpus> bitcoin.org change is merged
6942016-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
6952016-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
6962016-10-27T19:29:47 <wumpus> right, changing the block header structure is what makes it scary
6972016-10-27T19:30:53 <petertodd> wumpus: s/scary/a lot of work/ :)
6982016-10-27T19:31:12 <gmaxwell> topic: suggestion final alert stuff.
6992016-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
7002016-10-27T19:31:21 <wumpus> I mean more s/scary/high risk/
7012016-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
7022016-10-27T19:31:35 <wumpus> the implementation work is not so bad, review, sure
7032016-10-27T19:31:38 <sipa> petertodd: pick 2
7042016-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
7052016-10-27T19:31:51 <jtimon> we could make other chainparams count for the genesis block hash
7062016-10-27T19:32:04 *** cryptapus has quit IRC
7072016-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
7082016-10-27T19:33:25 <petertodd> wumpus: ah, yes, good point
7092016-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)
7102016-10-27T19:33:46 <petertodd> wumpus: I'm wrong - that is scary
7112016-10-27T19:33:52 <btcdrak> sipa: you have to thank harding! he wrote it all.
7122016-10-27T19:35:15 <kanzure> what is remaining re: final alert things?
7132016-10-27T19:35:24 <kanzure> was the page on one of the .org sites merged
7142016-10-27T19:35:55 <jtimon> topic suggestion: are we removing the use of checkpoints for progress estimation?
7152016-10-27T19:35:55 <gmaxwell> kanzure: we're not on that toopic now.
7162016-10-27T19:36:24 <gmaxwell> topic suggestion: My work removing checkpoints _completely_.
7172016-10-27T19:36:45 <wumpus> #topic removing checkpoints
7182016-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.
7192016-10-27T19:37:46 <gmaxwell> It's not hard to do that, just takes a little twiddling.
7202016-10-27T19:37:50 <wumpus> that's good news - progress estimation is probably the least interesting use of them
7212016-10-27T19:38:00 <gmaxwell> https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints
7222016-10-27T19:38:01 <wumpus> yea
7232016-10-27T19:38:11 <wumpus> #link https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints
7242016-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:
7252016-10-27T19:38:50 <wumpus> did you run into something difficult / uncertain?
7262016-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.
7272016-10-27T19:39:43 <wumpus> what about the DoS protection?
7282016-10-27T19:40:07 <wumpus> consensus change, as in a softfork?
7292016-10-27T19:40:14 <morcos> do tell
7302016-10-27T19:40:20 <gmaxwell> not a softfork. I'm telling.
7312016-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.
7322016-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.
7332016-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
7342016-10-27T19:41:49 <jtimon> isn't the minimum difficulty check a softfork?
7352016-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. :)
7362016-10-27T19:42:10 <wumpus> petertodd: well it wouldn't lock in specific blocks as the checkpoints do
7372016-10-27T19:42:10 <petertodd> er, gregs #2 thing makes my statement invalid :)
7382016-10-27T19:42:40 <jtimon> gmaxwell: yeah, it's a softfork in the pedantic sense
7392016-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
7402016-10-27T19:42:45 <gmaxwell> jtimon: in a sense, but an unobservable one. Yes.
7412016-10-27T19:42:45 <jeremyrubin> I don't think that's great...
7422016-10-27T19:43:03 <jeremyrubin> Can't difficulty fall that low under a soft fork to a different PoW?
7432016-10-27T19:43:16 <jeremyrubin> (not that that should happen)
7442016-10-27T19:43:19 <petertodd> jeremyrubin: yes, and at that point your idea of what bitcoin is is so insecure as to be useless
7452016-10-27T19:43:22 <gmaxwell> jeremyrubin: then you take out the rule.
7462016-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
7472016-10-27T19:43:40 <petertodd> jtimon: +1
7482016-10-27T19:43:43 <Chris_Stewart_5> wouldn't that be a hard fork to remove it if it was enforced?
7492016-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.
7502016-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
7512016-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.
7522016-10-27T19:44:54 <petertodd> gmaxwell: honestly, I'd be inclined to go even higher - 10 machines is absolutely nothing
7532016-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.
7542016-10-27T19:45:22 *** gabridome has joined #bitcoin-core-dev
7552016-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..
7562016-10-27T19:45:25 *** gabridome has quit IRC
7572016-10-27T19:45:36 <jeremyrubin> petertodd: I disagree, but that's more of a wizards topic
7582016-10-27T19:45:50 <jtimon> gmaxwell: are you sure you want to change CheckBlockHeader instead of CheckProofOfWork ?
7592016-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?
7602016-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
7612016-10-27T19:46:10 <jeremyrubin> petertodd: e.g., something like tadge's proof of idle
7622016-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.
7632016-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
7642016-10-27T19:46:25 <gmaxwell> morcos: it is preserved.
7652016-10-27T19:46:33 <gmaxwell> to the extent that it exists.
7662016-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
7672016-10-27T19:46:46 <jtimon> Chris_Stewart_5: yeah if you want a different pow just hardfork
7682016-10-27T19:46:49 *** gabridome has joined #bitcoin-core-dev
7692016-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.
7702016-10-27T19:47:01 <morcos> ok, i need to think about it more.. but i think we should analyze all those scenarios
7712016-10-27T19:47:21 <gmaxwell> morcos: but thats also why my figure is ~10 devices and not 10,000 devices. :)
7722016-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.
7732016-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. :)
7742016-10-27T19:47:51 <gmaxwell> But I expected thought and discussion on it.
7752016-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
7762016-10-27T19:48:24 <petertodd> gmaxwell: if hardware improves, do we up the min diff again? IMO that'd be reasonable
7772016-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
7782016-10-27T19:48:42 <gmaxwell> BlueMatt: So hold up there.
7792016-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.
7802016-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?
7812016-10-27T19:49:18 <BlueMatt> gmaxwell: didnt disagree, only suggested that ideally we'd fix the issues we have now
7822016-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
7832016-10-27T19:49:19 <gmaxwell> BlueMatt: right now we won't accept lower difficulty blocks after we've validated up to a paritcular checkpoint.
7842016-10-27T19:49:30 <gmaxwell> (okay I'll still explain as other people might miss this)
7852016-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.
7862016-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
7872016-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)
7882016-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
7892016-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.
7902016-10-27T19:50:53 <BlueMatt> (under first-peer-is-evil attacks, but ok)
7912016-10-27T19:50:57 *** achow101_ has quit IRC
7922016-10-27T19:51:00 <gmaxwell> BlueMatt: but my proposal needs only headers.
7932016-10-27T19:51:16 <gmaxwell> oh under first peer is attacker
7942016-10-27T19:51:17 <petertodd> morcos: anyway, good to do up some deployment scenarios regardless to explain how that'd work
7952016-10-27T19:51:17 <BlueMatt> oh, i thought we applied checkpoints against headers now
7962016-10-27T19:51:18 <BlueMatt> nvm
7972016-10-27T19:51:49 <sipa> BlueMatt: we do; after passing a certain checkpoint, we don't accept headers that fork off before that checkpoint
7982016-10-27T19:52:06 <BlueMatt> ok, lets take this offline
7992016-10-27T19:52:11 <BlueMatt> suggested additional topics?
8002016-10-27T19:52:13 <gmaxwell> Okay, thats the overview.
8012016-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?
8022016-10-27T19:53:38 <jtimon> mhmm, pindexBestHeader->nChainWork < UintToArith256(consensusParams.nMinimumChainWork) ? consensusParams.powLimit : consensusParams.powLimitLater
8032016-10-27T19:53:38 <jtimon> what about instead... block.nHeight < consensusParams.highPowLimitHeight ? consensusParams.powLimit : consensusParams.powLimitLater
8042016-10-27T19:53:39 <wumpus> #topic the final alert
8052016-10-27T19:53:53 <wumpus> no reason IMO
8062016-10-27T19:53:55 <btcdrak> gmaxwell: please get it over with.
8072016-10-27T19:54:39 <gmaxwell> Okay. will coordinate.
8082016-10-27T19:55:13 <gmaxwell> jtimon: that would make it trivial for an attacker to capture you on a fake chain.
8092016-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.
8102016-10-27T19:56:48 <jtimon> gmaxwell: how am I prevented from handling reorgs in the same way as you?
8112016-10-27T19:57:14 <sipa> jtimon: creating many blocks is easy. creating much work is hard
8122016-10-27T19:57:43 <gmaxwell> anyting left in the meeting (I'll continue this convo after)
8132016-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?
8142016-10-27T19:58:24 <jtimon> I must be missing something, I don't see the vulnerability that my proposed change introduces
8152016-10-27T19:58:26 <wumpus> ok, that concludes the meeting I think
8162016-10-27T19:58:34 <wumpus> #endmeeting
8172016-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)
8182016-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
8192016-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
8202016-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
8212016-10-27T19:59:07 <btcdrak> party time?
8222016-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
8232016-10-27T19:59:16 <BlueMatt> but that shouldnt matter much
8242016-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.
8252016-10-27T19:59:56 <jtimon> yes, how my proposed change makes your branch more vulnerable to that attack is what I don't see
8262016-10-27T20:00:17 <jtimon> why wouldn't I reorg to the most work change?
8272016-10-27T20:00:31 <gmaxwell> Because you won't even process the first block in that chain.
8282016-10-27T20:00:34 *** d_t has joined #bitcoin-core-dev
8292016-10-27T20:00:39 <sipa> jtimon: because you'll reject the low-difficulty headers from the real chain you get later
8302016-10-27T20:00:41 <jtimon> just like your branch without my proposed change, I think
8312016-10-27T20:00:58 *** murch has joined #bitcoin-core-dev
8322016-10-27T20:01:08 <jtimon> mhmm, no, say highPowLimitHeight is the current height whatever it is
8332016-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.
8342016-10-27T20:01:50 <gmaxwell> jtimon: yes, 436182. Say it's that.
8352016-10-27T20:02:04 <gmaxwell> Attacker computes 500000 diff 1 headers, and gives you that.
8362016-10-27T20:02:08 <jtimon> right, and mine activates at a fixed height, say 436182
8372016-10-27T20:02:16 <gmaxwell> Under my code you would sitll reorg to the best chain.
8382016-10-27T20:02:19 <jtimon> ok, I accept that chain
8392016-10-27T20:02:29 <jtimon> then when I see the real one I reorg, no?
8402016-10-27T20:02:29 <gmaxwell> Under your code you would not reorg to the best chain.
8412016-10-27T20:02:33 <gmaxwell> No.
8422016-10-27T20:02:41 <jtimon> why not?
8432016-10-27T20:02:45 <sipa> jtimon: no, you'll reject the low-difficulty headers once you pass the watermark
8442016-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.
8452016-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
8462016-10-27T20:03:11 <jtimon> oh, we have limits on reorg, right, sorry, I get it, thanks
8472016-10-27T20:03:19 <sipa> no, we don't have limits on reorg
8482016-10-27T20:03:20 <gmaxwell> We don't have limits on reorg.
8492016-10-27T20:03:28 <jtimon> mhm, let me read again
8502016-10-27T20:03:34 <sipa> we just reject headers that are too low difficulty once we know we're past that stafe
8512016-10-27T20:03:38 <sipa> *stage
8522016-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
8532016-10-27T20:04:30 <gmaxwell> if you don't reject low diff headers someone can exaust your memory/disk with header flooding.
8542016-10-27T20:05:00 <gmaxwell> which the code you were quoting protect against but wouldn't if it were a height check.
8552016-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
8562016-10-27T20:06:56 <jtimon> I don't get it but let's move on I will think more about it
8572016-10-27T20:07:16 *** waxwing has quit IRC
8582016-10-27T20:07:21 *** Guyver2 has joined #bitcoin-core-dev
8592016-10-27T20:07:50 <sipa> jtimon: being past 436182 does not mean you're on the right chain
8602016-10-27T20:07:50 <sipa> an attacker can veriy easily create such a long chain
8612016-10-27T20:08:08 *** Guyver2 has left #bitcoin-core-dev
8622016-10-27T20:08:15 <sipa> creating as much work of the real 43612 chain is nearly impossible
8632016-10-27T20:08:18 <jtimon> sipa: right it means the min diff is higher from now on
8642016-10-27T20:08:26 <jtimon> right
8652016-10-27T20:08:43 <sipa> jtimon: if yhe min difficulty is more than 1 you will reject the early part of the real chain!!!
8662016-10-27T20:09:04 <sipa> because the real chain has diff 1 in the beginning
8672016-10-27T20:09:05 <jtimon> and "my code" will always prefer the real chain because it's more work
8682016-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?
8692016-10-27T20:09:24 <jtimon> sipa: no, the early part of the real chain is height < 436182 !
8702016-10-27T20:09:29 *** waxwing has joined #bitcoin-core-dev
8712016-10-27T20:10:02 <sipa> jtimon: we DO NOT want to accept just any header below height 436182
8722016-10-27T20:10:18 <sipa> jtimon: that is exactly the DoS attack this change is intended to fix
8732016-10-27T20:10:57 *** Guyver2 has joined #bitcoin-core-dev
8742016-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
8752016-10-27T20:11:15 <sipa> even in an entirely unrelated chain
8762016-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
8772016-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()
8782016-10-27T20:11:46 <BlueMatt> does anyone object to me making it call BlockChecked for AcceptBlock failures?
8792016-10-27T20:11:53 *** achow101_ has joined #bitcoin-core-dev
8802016-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
8812016-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
8822016-10-27T20:12:34 <sipa> jtimon: it only protects us once we see the real chain
8832016-10-27T20:12:57 <sipa> jtimon: your proposal can trigger even if we don't have the real chain
8842016-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
8852016-10-27T20:15:24 <sipa> so you haven't solved the issue
8862016-10-27T20:15:58 <jtimon> note I didn't say pindexBestHeader->nHeight but block.nHeight (that is, the header you are checking now)
8872016-10-27T20:16:38 <sipa> you're really doing somwthing completely different
8882016-10-27T20:16:58 <jtimon> well, that line is supposed to save us from min diff blocks in the future, no?
8892016-10-27T20:18:03 <sipa> your change does not prevent that
8902016-10-27T20:18:20 <sipa> someone can keep spamming low-height headers in your proposal
8912016-10-27T20:19:02 <jtimon> oh, and you won't ignore them if they're < 436182, sorry, I finally get it
8922016-10-27T20:19:05 <jtimon> thanks
8932016-10-27T20:20:03 <instagibbs> Congrats! Managed to sleep exactly through meeting time.
8942016-10-27T20:20:39 <BlueMatt> ok, I'm removing CValidationState from ProcessNewBlock
8952016-10-27T20:21:38 <jtimon> sorry BlueMatt wasn't listening
8962016-10-27T20:22:21 <btcdrak> sipa: remember to update your http://bitcoin.sipa.be/ver9-2k.png graphs :)
8972016-10-27T20:22:27 <sipa> instagibbs: and through the release
8982016-10-27T20:22:31 <sipa> btcdrak: indeed!
8992016-10-27T20:23:29 *** pedrobranco has joined #bitcoin-core-dev
9002016-10-27T20:23:32 <instagibbs> Yeah missed all the action.
9012016-10-27T20:24:33 *** achow101_ has quit IRC
9022016-10-27T20:25:35 <sipa> BlueMatt: iirc the only reason for CVS in PNB is to return system failure conditions
9032016-10-27T20:26:08 <BlueMatt> sipa: nope, its also used to return AcceptBlock errors
9042016-10-27T20:26:09 <BlueMatt> sipa: also, its never checked for system failure conditions
9052016-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)
9062016-10-27T20:27:40 *** pedrobranco has quit IRC
9072016-10-27T20:33:20 <BlueMatt> jtimon: https://github.com/bitcoin/bitcoin/commit/a4f82de1bdde644e9bad4c524b638dd5bd4d69f7
9082016-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
9092016-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
9102016-10-27T20:36:40 *** belcher has joined #bitcoin-core-dev
9112016-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
9122016-10-27T20:38:28 <jtimon> BlueMatt: yeah, I definitely like that commit
9132016-10-27T20:38:57 *** skyraider has joined #bitcoin-core-dev
9142016-10-27T20:39:18 <jtimon> yeah I only briefly looked at that one, sorry
9152016-10-27T20:40:06 <murch> quick question: Does 0.13.1 already include functions for creation of SegWit transactions?
9162016-10-27T20:40:22 <BlueMatt> yes
9172016-10-27T20:40:29 <BlueMatt> so did 0.13.0
9182016-10-27T20:40:46 <BlueMatt> (its all gated on segwit being activated, so it works on testnet)
9192016-10-27T20:41:31 <murch> ah okay, thanks
9202016-10-27T20:56:06 *** Chris_Stewart_5 has quit IRC
9212016-10-27T21:09:55 *** Chris_Stewart_5 has joined #bitcoin-core-dev
9222016-10-27T21:11:53 *** Victor_sueca has joined #bitcoin-core-dev
9232016-10-27T21:13:34 *** jl2012 has quit IRC
9242016-10-27T21:14:04 *** Victorsueca has quit IRC
9252016-10-27T21:20:35 <BlueMatt> wait, did we un-support qt5?
9262016-10-27T21:20:42 <BlueMatt> wasnt there talk of deprecating it?
9272016-10-27T21:26:10 *** Guyver2 has quit IRC
9282016-10-27T21:35:24 *** wasi has quit IRC
9292016-10-27T21:45:58 <cfields_> BlueMatt: you mean qt4?
9302016-10-27T21:48:26 <BlueMatt> uhh, yes
9312016-10-27T21:49:45 <cfields_> BlueMatt: i'd say it's pretty well deprecated already. iirc the discussion was about completely dropping support
9322016-10-27T21:52:46 <BlueMatt> mmm, nvm, realized it only breaks precise, which was broken by c++11
9332016-10-27T21:56:19 <michagogo> Ack, missed another meeting :-/
9342016-10-27T21:56:34 <michagogo> Did it start late, or just late ping?
9352016-10-27T21:57:49 <luke-jr> I think at this point, once Qt4 becomes a burden we can probably drop it?
9362016-10-27T21:57:52 <luke-jr> BlueMatt: what breaks precise?
9372016-10-27T21:58:06 <BlueMatt> there is no qt4 on precise
9382016-10-27T21:58:18 <BlueMatt> also, the boost in precise doesnt compile in c++11 mode
9392016-10-27T21:58:55 <luke-jr> so don't build qt4?
9402016-10-27T21:59:14 <luke-jr> I thought we didn't use any boost that had ABI changes for C++11
9412016-10-27T21:59:41 <BlueMatt> luke-jr: https://svn.boost.org/trac/boost/ticket/6198
9422016-10-27T22:00:20 <luke-jr> compile with GCC?
9432016-10-27T22:00:40 *** kadoban has quit IRC
9442016-10-27T22:00:42 <BlueMatt> the gcc in precise does not support c++11
9452016-10-27T22:00:46 <luke-jr> ugh
9462016-10-27T22:01:06 *** kadoban has joined #bitcoin-core-dev
9472016-10-27T22:01:34 <BlueMatt> the ppa currently has an empty dummy package for precise
9482016-10-27T22:01:37 <BlueMatt> because fuck precise
9492016-10-27T22:01:44 <luke-jr> uh
9502016-10-27T22:01:49 <luke-jr> at least leave the old version?
9512016-10-27T22:02:02 <BlueMatt> no
9522016-10-27T22:02:06 <luke-jr> â¦
9532016-10-27T22:02:25 <luke-jr> patch the code to #define size size_arg? >_<
9542016-10-27T22:02:34 <BlueMatt> no
9552016-10-27T22:02:45 <BlueMatt> feel free to create the debian/ folder and send it to me and I'll upload
9562016-10-27T22:02:51 <BlueMatt> I'm not fighting with it to make precise work
9572016-10-27T22:02:54 <luke-jr> XD
9582016-10-27T22:03:11 <luke-jr> wait, to do the PPA you just upload the debian folder?
9592016-10-27T22:03:20 <BlueMatt> and the original source archive
9602016-10-27T22:03:25 <BlueMatt> (ie git archive)
9612016-10-27T22:04:00 <BlueMatt> and two other strange metadata files
9622016-10-27T22:09:22 <luke-jr> any reason we can't get gitian to produce the files needing to upload? <.<
9632016-10-27T22:09:41 <BlueMatt> gitian? they're all in the source tree
9642016-10-27T22:09:46 <BlueMatt> except signed by my pgp key
9652016-10-27T22:10:05 *** kadoban has quit IRC
9662016-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)
9672016-10-27T22:10:14 <luke-jr> so we don't need to do https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage ?
9682016-10-27T22:11:04 *** MarcoFalke has left #bitcoin-core-dev
9692016-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
9702016-10-27T22:12:20 <BlueMatt> so, no, its really entirely useless to do anything in gitian for this
9712016-10-27T22:15:27 *** blkdb has quit IRC
9722016-10-27T22:16:05 *** blkdb has joined #bitcoin-core-dev
9732016-10-27T22:17:15 *** pedrobranco has joined #bitcoin-core-dev
9742016-10-27T22:20:09 *** cdecker has quit IRC
9752016-10-27T22:21:18 *** pedrobranco has quit IRC
9762016-10-27T22:33:11 *** lclc has quit IRC
9772016-10-27T22:36:22 <gmaxwell> when did we back off the checkblocks check? was that in 0.13.0 or 0.13.1?
9782016-10-27T22:59:50 <BlueMatt> heh, 66/130 connections segwit (with 52/8 blocked)
9792016-10-27T22:59:55 <BlueMatt> guess preferential peering works =D
9802016-10-27T23:15:32 <sipa> gmaxwell: 0
9812016-10-27T23:15:38 <sipa> gmaxwell: 0.13.1
9822016-10-27T23:15:58 *** dstadulis has joined #bitcoin-core-dev
9832016-10-27T23:16:11 <gmaxwell> sipa: explaines people saying it stats so much faster.
9842016-10-27T23:16:26 <sipa> ha
9852016-10-27T23:16:31 <gmaxwell> sipa: how many connections does your node have?
9862016-10-27T23:17:06 <gmaxwell> I am 124/124.
9872016-10-27T23:21:42 *** dstadulis has quit IRC
9882016-10-27T23:22:04 *** dstadulis has joined #bitcoin-core-dev
9892016-10-27T23:26:45 <sipa> compiling 0.13.1 now
9902016-10-27T23:27:11 <sipa> i was on 0.13.0 i think
9912016-10-27T23:29:49 <BlueMatt> ok, all ppas are built and published
9922016-10-27T23:34:34 *** echonaut has quit IRC
9932016-10-27T23:34:34 *** echonaut1 has joined #bitcoin-core-dev
9942016-10-27T23:38:31 <gmaxwell> BlueMatt: if the ppas are downloadable, go post on reddit?
9952016-10-27T23:43:42 *** d_t has quit IRC
9962016-10-27T23:43:48 *** dstadulis has quit IRC
9972016-10-27T23:49:15 *** justan0theruser has joined #bitcoin-core-dev
9982016-10-27T23:51:13 *** justanotheruser has quit IRC
9992016-10-27T23:51:51 <luke-jr> Why does bitcoincore announcements ML include tracking?
10002016-10-27T23:57:23 <sipa> ?
10012016-10-27T23:57:54 <luke-jr> there's an invisible <img> with a tracking id at the bottom
10022016-10-27T23:58:22 <luke-jr> it attempts to load the image from the internet, thus informing the webserver it was read