--- Day changed Thu Oct 27 2016
00:04 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev     
00:06 < 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?
00:06 < jonasschnelli> s/_Var/_var
00:07 < luke-jr> I'd rather 'var' than '_var' for public stuff at least
00:08 < luke-jr> I don't see a problem with o->var or o->fVar
00:08 -!- wasi [~wasi@2a02:121e:41b:0:226:c7ff:fe74:7fa6] has joined #bitcoin-core-dev     
00:15 < jonasschnelli> Luke-Jr: my problems is, that the code is really not easy readable if you don't highlight instance variable in some form.
00:15 < jonasschnelli> this-> clusters to code to much IMO, ... using _var seems acceptable to me.
00:16 < jonasschnelli> Using fVar, etc. will not increase readability because we are also using this for non-instance vars (function parameters, etc.)
00:16 < luke-jr> we're already using _var for local variables to avoid shadowing :/
00:17 < jonasschnelli> argh... I though we are using _var for instance vars to avoid shadowing... do we also use _var in local scope?!
00:17 < 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
00:20 -!- Samdney [~Samdney@pD9518A96.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
00:21 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
00:21 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Max SendQ exceeded]     
00:22 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
00:26 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:29 < wumpus> no, we have no naming convention for instance variables, just use whatever makes sense in the context
00:29 < jonasschnelli> I personally like this-> but I know most people don't like that
00:30 < jonasschnelli> I'll try _
00:30 < wumpus> at least the qt coding convention recommends against using m_ or _ or such
00:31 < jonasschnelli> The m prefix would not allow to use the fVar, etc. prefix.
00:31 < jonasschnelli> mfBool would look strange. :)
00:31 < jonasschnelli> i'd prefere _fBool
00:31 < wumpus> m_fBool that would be, then
00:31 -!- Samdney [~Samdney@pD9518A96.dip0.t-ipconnect.de] has quit [Quit: Verlassend]     
00:31 < jonasschnelli> m_ yes... why not
00:31 < sipa> wumpus: what does the qt coding convention suggest?
00:32 < wumpus> sipa: no specific one, just use this->name where necessary
00:32 < wumpus> in many cases there's no need to name instance variables any differently from local variables
00:33 < jonasschnelli> wumpus: readability?
00:33 < sipa> luke-jr: where do we use _var for local variables?
00:33 < wumpus> e.g. https://forum.qt.io/topic/150/member-variable-naming-convention-in-qt-and-the-qtdn-wiki
00:33 < 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
00:33 < sipa> luke-jr: underscores are used in several places for formal parameters to avoid colliding with field variables
00:33 < wumpus> but I don't know, I hate these kind of discussions
00:33 < jonasschnelli> Reading through new code i often found myself checking if the variable is local or instance-wide
00:34 < sipa> haha
00:34 < jonasschnelli> heh     
00:34 < 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
00:34 < jonasschnelli> sipa: yes. If. now open main.cpp. :)
00:34 < wumpus> jonasschnelli: that probably means the code itself is badly commented / structured
00:35 < wumpus> a shallow 'fix' like renaming instance variables won't help much in that case except check a checkbox
00:36 < sipa> jonasschnelli: so help refactoring those functions to be morw readable :)
00:36 < 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
00:37 < wumpus> it's the typical pointy-haired boss solution to 
00:37 < wumpus> "code is unreadable"
00:37 < wumpus> FORCE a coding style!
00:37 < wumpus> now you have nicely formatted ununderstandable code :)
00:38 < 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?
00:38 -!- nanotube [~nanotube@unaffiliated/nanotube] has quit [Excess Flood]     
00:38 < 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. 
00:39 < wumpus> sipa: I don't think so, it's just the dilbert stereotype, it doesn't have anything to do with hair :-)
00:41 < 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. 
00:41 < dcousens> improving readability*
00:41 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
00:41 < 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
00:42 < gmaxwell> I wondered if perhaps PHB predated dilbert and dilbert was riffing off it, ... but I'd forgotten how old dilber is .. (1980-04)
00:43 -!- whphhg [whphhg@gateway/vpn/mullvad/x-lxokzibzsmrcthkr] has left #bitcoin-core-dev ["Leaving"]     
00:44 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev     
00:44 < 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>
00:46 -!- wasi [~wasi@2a02:121e:41b:0:226:c7ff:fe74:7fa6] has quit [Ping timeout: 250 seconds]     
00:47 < wumpus> time to tag 0.13.1 final?
00:47 < sipa> i'm about to fall asleep
00:48 < wumpus> I'll wait until you're asleep then
00:48 < dcousens> ha     
00:48  * sipa goes into ACPI standby
00:48 < wumpus> NN     
00:59 < 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.
01:00 < gmaxwell> After we make the high scoreholder, Github151, in charge of the project I'm sure things will run much better.
01:00 < gmaxwell> FWIW, my testing with RC3 all looks fine.
01:01 < wumpus> hahahaa yes Github151 for president
01:03  * luke-jr ponders writing-in Github151 on his ballot
01:05 < gmaxwell> many states require a write in candidate register with them before being eligible to be counted. :(
01:05 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
01:05 < luke-jr> I was joking anyway :p
01:05 < gmaxwell> I think this is intended to help avoid "Which John Smith did we just elect?"
01:06 < luke-jr> heh     
01:09 < 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
01:11 < wumpus> maybe they should use a blockchain for registering candidates *ducks*
01:11 < luke-jr> sadly, some people think that makes sense
01:13 < gmaxwell> wumpus: so, final?
01:21 -!- laurentmt [~Thunderbi@80.215.178.153] has joined #bitcoin-core-dev     
01:22 -!- laurentmt [~Thunderbi@80.215.178.153] has quit [Client Quit]     
01:22 < wumpus> yes, let's do it
01:22 < wumpus> sipa's asleep
01:25 < wumpus>  * [new tag]         v0.13.1 -> v0.13.1
01:25 < gmaxwell> \O/     
01:25 < luke-jr> oh wow, rc3 just deleted my entire home directory …………….. jk :P
01:26 < gmaxwell> cool "0.13.1 addresses user's concerns with excessive disk space consumption."
01:28 < wumpus> hehe, always the positive side
01:28 < luke-jr> lol     
01:28 < jonasschnelli> heh     
01:28 < warren> that sounds like one particular user had concerns
01:30 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
01:32 < jonasschnelli> huh! Why can this happen: http://paste.ubuntu.com/23387379/
01:34 < wumpus> huh, that looks like a bug in assertlockheld
01:34 < jonasschnelli> maybe a different wallet instance...
01:34 < wumpus> ah yes ofcourse
01:34 < wumpus> maybe the lock naming should include instance pointer
01:35 < jonasschnelli> Yes. My fault... different instances
01:35  * jonasschnelli curses pwalletMain
01:36 < luke-jr> hm, I didn't encounter such issues with multiwallet? O.o
01:40 < wumpus> did you run with lock debugging on?
01:41 < wumpus> (--enable-debug will do)
01:44 < luke-jr> no     
01:44 < luke-jr> does the assertlockheld only work with that?
01:44 < wumpus> yes     
01:51 < 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
01:55 -!- btcfanboi [32a85762@gateway/web/freenode/ip.50.168.87.98] has joined #bitcoin-core-dev     
02:02 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
02:07 < michagogo> 🎉🎊
02:09  * michagogo sends a message and requests that his computer be turned on
02:09 < wumpus> wake-over-IRC?
02:15 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has joined #bitcoin-core-dev     
02:15 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has left #bitcoin-core-dev []     
02:19 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
02:37 < michagogo> wumpus: wake-over-iMessage
02:37 < michagogo> (Poweron, really)
02:37 < michagogo> Anyway, build running now
02:38 < michagogo> As usual, sigs will auto-PR
02:40 < michagogo> I wonder how quickly we'll get sigs
02:41 < michagogo> Think release will come today?
02:43 -!- cdecker [~quassel@2a02:aa16:1105:4a80:2ce9:4987:85ed:4607] has joined #bitcoin-core-dev     
02:48 -!- mkarrer_ [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
02:52 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has quit [Ping timeout: 276 seconds]     
03:01 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Quit: Nettalk6 - www.ntalk.de]     
03:04 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
03:12 -!- btcfanboi [32a85762@gateway/web/freenode/ip.50.168.87.98] has quit [Ping timeout: 260 seconds]     
03:13 -!- cdecker [~quassel@2a02:aa16:1105:4a80:2ce9:4987:85ed:4607] has quit [Ping timeout: 250 seconds]     
03:13 < 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
03:14 -!- harrymm [~wayne@104.222.140.122] has quit [Ping timeout: 250 seconds]     
03:19 < michagogo> Ooh, just got my hacktoberfest email
03:24 < gmaxwell> https://blockchain.info/charts/utxo-count?timespan=60days  and fees are back down to ~0.5 btc/block... 
03:24 -!- Ylbam_ [uid99779@gateway/web/irccloud.com/x-pafbngllcycbvakc] has quit [Ping timeout: 260 seconds]     
03:26 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-zmdmvydffoaeltpc] has quit [Ping timeout: 256 seconds]     
03:27 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-sgodoivxuleqtkgz] has joined #bitcoin-core-dev     
03:27 -!- cdecker [~quassel@2a02:aa16:1105:4a80:2ce9:4987:85ed:4607] has joined #bitcoin-core-dev     
03:27 -!- Ylbam_ [uid99779@gateway/web/irccloud.com/x-lbqydsdmefxwezgu] has joined #bitcoin-core-dev     
03:32 -!- harrymm [~wayne@104.222.140.87] has joined #bitcoin-core-dev     
03:39 < 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
03:43 -!- harrymm [~wayne@104.222.140.87] has quit [Ping timeout: 256 seconds]     
03:46 < gmaxwell> andytoshi: wumpus: http://seriot.ch/parsing_json.html  < json test vectors.
03:48 < wumpus> gmaxwell: yeah came up earlier today already there's even an issue :) https://github.com/bitcoin/bitcoin/issues/9028
03:49 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Read error: Connection reset by peer]     
03:49 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
03:58 -!- harrymm [~wayne@104.222.140.53] has joined #bitcoin-core-dev     
04:06 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
04:11 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Read error: Connection reset by peer]     
04:18 < jonasschnelli> Just got a report that prioritisetransaction does not work on 0.12?
04:18 < wumpus> on 0.12? or 0.13?
04:19 < jonasschnelli> The reporter reported its working on 0.13 but not on 0.12
04:20 < luke-jr> do we care then?
04:22 < wumpus> I don't
04:22 < wumpus> was briefly in shock because of 0.13.1 :)
04:25 < luke-jr> jonasschnelli: the reporter is a miner? why aren't they on 0.13.0?
04:25 < luke-jr> sounds suspiciously like BU
04:26 < wumpus> yea     
04:28 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
04:31 < jonasschnelli> i don't care as well
04:32 < jonasschnelli> but good to know >if< 0.12 is not working and if so, why 0.13 is working
04:33 -!- rebroad [~rebroad@223.205.208.152] has joined #bitcoin-core-dev     
04:34 < Victorsueca> 0.12 is supposed to be still supported, should we backport a fix for this?
04:35 < wumpus> if someone writes a fix I'm happy to merge it
04:36 < luke-jr> Eligius didn't use 0.12 for long, but I am pretty certain prioritise worked
04:37 < luke-jr> (and I do check GBT returns the txid when I prioritise stuff)
04:38 < luke-jr> so IMO it's probably either BU nonsense or PEBKAC
04:38 -!- cryptapus [~cryptapus@66.119.84.15] has joined #bitcoin-core-dev     
04:38 -!- cryptapus [~cryptapus@66.119.84.15] has quit [Changing host]     
04:38 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
04:52 < jonasschnelli> first we would need to double-check if its not working on 0.12. It was just a report.
04:52 < jonasschnelli> There are some RPC tests.. although not sure when we have added those.
05:00 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
05:04 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Read error: Connection reset by peer]     
05:04 -!- a_meteor_ [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
05:05 < wumpus> I'm surprised if it really doesn't work and we only hear about it now
05:06 -!- a_meteor_ [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Read error: Connection reset by peer]     
05:07 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
05:07 -!- n1ce [~n1ce@unaffiliated/n1ce] has quit [Quit: Nettalk6 - www.ntalk.de]     
05:09 -!- n1ce [~n1ce@unaffiliated/n1ce] has joined #bitcoin-core-dev     
05:10 < 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
05:11 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Read error: Connection reset by peer]     
05:11 < wumpus> btcdrak: https://github.com/bitcoin/bitcoin/pull/9032
05:12 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
05:13 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Read error: Connection reset by peer]     
05:14 < btcdrak> wumpus: interesting
05:14 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
05:14 < wumpus> I'm not even sure the second step should be a fatal error or just a warning
05:14 < wumpus> a_meteorite: please fix your IRC client, you're generating too many join/part messages
05:14 < btcdrak> wumpus: this was really helpful
05:14 < btcdrak> https://github.com/bitcoin/bitcoin/pull/9023
05:15 < wumpus> yes, but I think it makes the test too noisy in the pass case
05:15 < wumpus> printing a diff when the test fails makes sense though
05:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:16 < btcdrak> maybe should shield the pass stuff with a -verbose flag? or ditch the pass logs entirely?
05:17 < wumpus> yes I'd say ditch the pass logs, ideally tests are silent if nothing is wrong
05:17 < wumpus> (esp in travis)
05:17 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
05:18  * luke-jr publishes Knots 0.13.1 and goes to bed :P
05:19 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Ping timeout: 260 seconds]     
05:19 < wumpus> btcdrak: this may be already what it does, I was confused by all the logging stuff
05:20 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has joined #bitcoin-core-dev     
05:20 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ     
05:20 < luke-jr> poor a_meteorite is going to fall to Earth
05:20 < btcdrak> iirc it prints pass and fail. lemme rerun quickly
05:20 -!- mode/#bitcoin-core-dev [+b *!*@unaffiliated/ameteorite/x-000000001] by wumpus     
05:21 <@wumpus> luke-jr: hah
05:21 <@wumpus> btcdrak: but also in non-verbose mode?
05:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
05:21 < btcdrak> ok just checked, by default passes are silent
05:21 < btcdrak> if you add -v then you get full output
05:21 <@wumpus> ok, and diffs are printed on failure?
05:21 < btcdrak> https://www.irccloud.com/pastebin/fuxIut4y/
05:22 <@wumpus> even in non-verbose mode?
05:22 -!- a_meteorite [~a_meteori@unaffiliated/ameteorite/x-000000001] has quit [Read error: Connection reset by peer]     
05:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:24 < btcdrak> oh wait, my cherry-pick failed and I didnt notice :-p
05:24 <@wumpus> gah     
05:24 < btcdrak> so it is noisy without -v
05:24 < btcdrak> https://www.irccloud.com/pastebin/hd69OPZ4/
05:24 <@wumpus> sigh
05:24  * wumpus re-edits his post again
05:25 < 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
05:26 < btcdrak> wumpus: I commented too
05:27 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
05:28 < btcdrak> wumpus: otherwise the errors are great e.g.
05:28 < btcdrak> https://www.irccloud.com/pastebin/xL5cqNGo/
05:29 < achow101> oh hey, a tag!
05:29 <@wumpus> yes that seems useful
05:30 -!- wasi [~wasi@2a02:121e:41b:0:226:c7ff:fe74:7fa6] has joined #bitcoin-core-dev     
05:31 < 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
05:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
05:38 <@wumpus> btcdrak: does -v actually work for you?
05:39 < btcdrak> wumpus: it doesnt do anything different under his patch
05:39 <@wumpus> I moved the PASSED messages to the debug level, but now I can't get them to output at all
05:41 < btcdrak> same here, hmm
05:42 <@wumpus> figured it out
05:52 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:7170:5354:1132:b152] has quit [Quit: .]     
05:56 < GitHub49> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/2e2388a5cbb9a6e101b36e4501698fec538a5738
05:56 < GitHub49> bitcoin/0.13 2e2388a Wladimir J. van der Laan: Move release notes to release-notes/release-notes-0.13.1.md...
05:58 < GitHub138> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/a49b4a75a1b671492e65eed17d6894d85ea5ebfd
05:58 < GitHub138> bitcoin/master a49b4a7 Wladimir J. van der Laan: doc: Add release notes for 0.13.1 release
05:59 < timothy> does 0.13.1 requires new or different libraries?
05:59 < timothy> to built
05:59 < GitHub66> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a49b4a75a1b6...83234d4d1723
05:59 < GitHub66> bitcoin/master ba26d41 Michael Ford: Update build notes for dropping osx 10.7 support...
05:59 < GitHub66> bitcoin/master 83234d4 Wladimir J. van der Laan: Merge #9033: Update build notes for dropping osx 10.7 support (fanquake)...
05:59 <@wumpus> compared to what?
05:59 < 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
05:59 < timothy> 0.13.0
06:00 <@wumpus> yes there was at least a patch to boost
06:00 < timothy> so can't I use vanilla boost?
06:00 <@wumpus> sure, you always can
06:00 <@wumpus> I thought you were talking about the gitian build, if you build using your OS' libraries there no need to do anything special
06:04 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:19a4:48b3:7218:f2a5] has joined #bitcoin-core-dev     
06:07 -!- laurentmt [~Thunderbi@80.215.178.153] has joined #bitcoin-core-dev     
06:07 -!- laurentmt [~Thunderbi@80.215.178.153] has quit [Client Quit]     
06:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:12 -!- wasi [~wasi@2a02:121e:41b:0:226:c7ff:fe74:7fa6] has quit [Ping timeout: 250 seconds]     
06:16 -!- laurentmt [~Thunderbi@80.215.178.153] has joined #bitcoin-core-dev     
06:16 -!- laurentmt [~Thunderbi@80.215.178.153] has quit [Client Quit]     
06:19 -!- whphhg [whphhg@gateway/vpn/mullvad/x-lxokzibzsmrcthkr] has joined #bitcoin-core-dev     
06:19 < whphhg> Hej, is there a Bitcoin Unlimited channel on freenode?
06:23 < timothy> lol     
06:23 < rabidus_> lol     
06:23 < timothy> it's like entering on FBI channel and ask for drug
06:26 < PatBoy> hahahah
06:26 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 252 seconds]     
06:29 <@wumpus> rofl
06:31 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev     
06:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
06:33 < whphhg> Lol, I wasn't aware it was that bad. :o
06:33 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev     
06:39 < BlueMatt> wumpus: so do i wait to update the ppa or just do it today?
06:41 <@wumpus> BlueMatt: let me see, how many gitian sigs do we have now
06:42 <@wumpus> three matching ones
06:42 < BlueMatt> i said today, not now....still eating breakfast :p
06:42 <@wumpus> but no code-signed ones yet. I guess it's somewhat strange to have the ppa built before the binaries available
06:43 < btcdrak> Better not do it until the release actual announcement when we have everything done.
06:48 < BlueMatt> btcdrak: meh, i often do it early...otherwise i forget
06:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:49 -!- fengling [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
06:51 < Lauda> BlueMatt please ppa as soon as possible 0.13.0 took forever. :)
06:53 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
06:57 < btcdrak> Lauda: good point :-p
07:03 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-sgodoivxuleqtkgz] has quit [Ping timeout: 256 seconds]     
07:03 < michagogo> BlueMatt: is it all ready in terms of packaging, i.e. just a matter of pushing the button?
07:04 -!- Ylbam_ [uid99779@gateway/web/irccloud.com/x-lbqydsdmefxwezgu] has quit [Ping timeout: 260 seconds]     
07:04 < 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?)
07:06 < 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
07:06 < michagogo> Or 48 or something
07:07 < michagogo> (Also, it's unfortunate that only cfields_ can produce the detached sigs…)
07:10 < btcdrak> wumpus: I uploaded my gitian sigs
07:11 < 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
07:11 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
07:16 < michagogo> wumpus: re: #9028 (and in general), have you considered tagging some issues for Hacktoberfest?
07:17 < BlueMatt> 'tf is hacktoberfest?
07:17 < michagogo> ;;Google hacktoberfest
07:17 < 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>
07:17 < BlueMatt> also, isnt october over?
07:17 < michagogo> Well, almost
07:27 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 244 seconds]     
07:28 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-core-dev     
07:41 <@wumpus> would be a bit too late I guess
07:42 <@wumpus> (for hacktoberfest)
07:42 <@wumpus> woohoo, 6 sigs all match
07:43 <@wumpus> ping cfields_ 
07:44 -!- whphhg [whphhg@gateway/vpn/mullvad/x-lxokzibzsmrcthkr] has left #bitcoin-core-dev ["Leaving"]     
07:47 < GitHub55> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/83234d4d1723...fea5e05a6380
07:47 < GitHub55> bitcoin/master 1c3ecc7 S. Matthew English: instance of 'mem pool' to 'mempool'...
07:47 < GitHub55> bitcoin/master fea5e05 Wladimir J. van der Laan: Merge #9029: instance of 'mem pool' to 'mempool'...
07:47 < GitHub196> [bitcoin] laanwj closed pull request #9029: instance of 'mem pool' to 'mempool' (master...patch-7) https://github.com/bitcoin/bitcoin/pull/9029
07:55 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev     
07:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]     
07:56 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Disconnected by services]     
07:56 -!- Arnavion3 [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
07:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
07:56 < sipa> BlueMatt: Oktoberfest is also mostly not in october :)
07:56 -!- Arnavion3 is now known as AtashiCon     
07:56 < BlueMatt> heh, true
08:04 < andytoshi> thanks gmaxwell (re json test vectors)
08:12 < kanzure> andytoshi: trying to save yourself some work on mimblewimble?
08:20  * michagogo waves at cfields_
08:27  * michagogo watches https://github.com/bitcoin-core/bitcoin-detached-sigs/tags
08:28 < achow101> michagogo: are we harassing cfields_ now to get the code signed sigs?
08:29 < michagogo> achow101: no need to harass, I think - he pushed his gitian sigs up
08:29 < michagogo> I assume the detached will be up shortly
08:30 < michagogo> BlueMatt: there are enough gitian builders around that it's probably safe to get the PPA ready
08:30 < BlueMatt> yea, busy fixing 8969 for now, will soon
08:30 < michagogo> BTW, has anyone here looked into Ubuntu's new "snap" packaging thing?
08:31 -!- BCBot [~BCBot@46.101.246.115] has quit [Ping timeout: 250 seconds]     
08:34 -!- fengling [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
08:35 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
08:36 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!]     
08:39 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
08:48 < michagogo> wumpus: I don't see the usual PR for the release notes on bitcoin.org
08:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
08:52 < achow101> are the release notes finalized yet?
08:56 < cfields_> hehe, i was working on the sigs while you guys were busy waving :)
08:56 < cfields_> gitian builders: v0.13.1 sigs are pushed
08:56 < michagogo> achow101: I think so, yeah
09:00 < michagogo> My sigs are pushed as well
09:01 < achow101> so are mine
09:01 < michagogo> wumpus: looks like the release is ready when you are
09:02 < btcdrak> segwit upgrading guide published today 
09:02 < btcdrak> https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
09:04 < michagogo> https://github.com/bitcoin-core/bitcoincore.org/pull/241 needs updating
09:05 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:06 < cfields_> btcdrak: you can add ckpool to the mining list. and the cgminer PR hasn't been merged yet.
09:07 < btcdrak> ok     
09:08 -!- rebroad [~rebroad@223.205.208.152] has quit [Ping timeout: 250 seconds]     
09:10 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev     
09:10 < btcdrak> seems like the binaries will be ready today?
09:14 -!- BCBot [~BCBot@46.101.246.115] has quit [Remote host closed the connection]     
09:16 < 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
09:17 < cfields_> btcdrak: technically just need 1 more match i think, which i'm sure will show up any minute
09:21 < michagogo> cfields_: that match is probably going to be wumpus
09:21 < michagogo> Who is the one that does the release anyway
09:23 -!- laurentmt [~Thunderbi@80.215.234.174] has joined #bitcoin-core-dev     
09:26 -!- laurentmt [~Thunderbi@80.215.234.174] has quit [Client Quit]     
09:35 < cfields_> btcdrak: thanks
09:36 < sipa> what does mf mean?
09:36 < sipa> "0.13.1 signed mf"
09:37 < MarcoFalke> my initials
09:37 < MarcoFalke> :P     
09:37 < sipa> oh, of course
09:37 < cfields_> I read it as Samuel L. Jackson.
09:37  * sipa stupid
09:37 < sipa> ...?
09:39 < cfields_> as in: I've had it with these MarcoFalke snakes, on this MarcoFalke plane!
09:40 < sipa> i see.
09:45 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection]     
09:47 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
09:59 < MarcoFalke> Heh, I should change it to m4r(0f41k3 as there will be 1337 commits in the repo after it is merged.
10:23 -!- laurentmt [~Thunderbi@80.215.234.174] has joined #bitcoin-core-dev     
10:24 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds]     
10:25 -!- laurentmt [~Thunderbi@80.215.234.174] has quit [Client Quit]     
10:30 -!- Ylbam_ [uid99779@gateway/web/irccloud.com/x-mamdrgjnroyywxfy] has joined #bitcoin-core-dev     
10:31 <@wumpus> hahaha
10:35 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
10:41 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]     
10:43 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-ypuzbhetnqbhfiew] has joined #bitcoin-core-dev     
10:54 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 276 seconds]     
10:56 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
10:57 < achow101_> are we so lucky that the time from tag to release will be less than 12 hours this time>
10:57 < achow101_> ?     
11:03 < btcdrak> achow101_: looks like everything has been done barring release notes and upload to bitcoin.org
11:04 < btcdrak> s/notes/announce/
11:04 < achow101_> :D     
11:04 < btcdrak> meeting time? or is everyone down at the pub having a well deserved pint?
11:04 < achow101_> I think you're an hour early
11:05 < btcdrak> wait, did the clocks change?
11:05 < achow101_> idk, depends on your country
11:05 < btcdrak> automatic clock update so I would never know >_>
11:05 < btcdrak> this explains a lot...
11:06 < achow101_> dst ends for me next week
11:07 < sipa> it's one hour from now
11:07 < sipa> btcdrak: set it in your calendar as 7pm iceland time
11:10 -!- frederic94500 [4d808e1f@gateway/web/freenode/ip.77.128.142.31] has joined #bitcoin-core-dev     
11:12 < morcos> jonasschnelli: i think apple gave us an idea.  you should move the fee slider to the touch bar.  
11:12 < btcdrak> sipa: let's all just move to Iceland.
11:12 < sipa> morcos: 'touch bar' ?
11:12 < morcos> what they replaced function keys with on the new macbook pros
11:12 < jonasschnelli> sipa: new MacBook Pro physical UX element
11:13 < jonasschnelli> A screen replaces the F function keys
11:13 < sipa> i don't understand
11:13 < BlueMatt> wtf is a "physical UX element"
11:13 < jonasschnelli> morcos: I need to watch the presentation
11:13 < BlueMatt> sipa: they replace the top line of your keyboard with an ipad
11:13 < jonasschnelli> http://photos.reportinglive.com/p/2016-10-27/f1477589812.jpg
11:13 < btcdrak> o.O     
11:14 < sipa> i still don't understand what it means to move the fee slider
11:14 < achow101_> looks stupid
11:14 < morcos> there was some PR discussion about the right way for the fee slider to work in QT
11:14 < jeremyrubin> Let's add touchid support at least...
11:15 < btcdrak> what is touchid?
11:15 < achow101_> the fingerprint sensor stuff
11:16 < jeremyrubin> fingerprint sensor + secure enclave
11:16 < jonasschnelli> finger print has no plausible deniability
11:17 < gmaxwell> the lenovo x1s have a touchscreen at the top of the keyboard instead of fkeys, it's awful.
11:17 < BlueMatt> jonasschnelli: and your machine is..uhhh...covered in your fingerprints
11:17 < 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.
11:17 < sipa> BlueMatt: i'm sure my keyboard is already covered with fingerprints :)
11:17 < jonasschnelli> Right... adhesive tape is sufficient to unlock
11:18 < btcdrak> seems like security theatre 
11:18 < jonasschnelli> Probably state sponsored move.. :)
11:18 < jeremyrubin> gmaxwell: it's a different thing than that kind
11:18 < jonasschnelli> You can now force everyone to unlock your HDD/SDD
11:18 < achow101_> btcdrak: mythbusters did an episode about fingerprint spoofing
11:18 < jeremyrubin> is that one on X1 even a screen?
11:19 < btcdrak> This was it in 2014 http://www.bbc.com/news/technology-30623611
11:19 < jeremyrubin> Also touchid doesn't usually replace password
11:20 < jonasschnelli> jeremyrubin: Yeah. But if you login with touchid after a cold-start... I guess it replaces passwords.
11:20 < jonasschnelli> It's probably different then on iOS
11:20 < btcdrak> I prefer passwords + smartcards 
11:20 < jonasschnelli> Yes. FIDO enabled hardware wallet
11:20 < jonasschnelli> Works since 10.11 on OSX
11:21 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has joined #bitcoin-core-dev     
11:21 < sipa> fingerprint unlocking is so annoyingly convenient :(
11:21 < jonasschnelli> heh     
11:21 < jonasschnelli> What I want is fingerprint & passphrase
11:22 < btcdrak> I want to keep my fingers
11:25 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]     
11:25 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev     
11:26 < 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
11:26 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Ping timeout: 244 seconds]     
11:27 < sipa> NicolasDorier: interesting idea, though i'm not sure it's so useful - i expect we already have the majority of utxo entires cached
11:28 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev     
11:28 < sipa> but i guess it could speed up looking for the ones that aren't
11:28 < NicolasDorier> sipa: the thing that slow down is BIP30
11:28 < NicolasDorier> because we are checking for a negative
11:28 < NicolasDorier> so it is not in the cache
11:28 < sipa> we don't do that anymore, afaik
11:29 < sipa> only before bip34 activation
11:29 < NicolasDorier> oh checking that
11:29 -!- frederic94500 [4d808e1f@gateway/web/freenode/ip.77.128.142.31] has quit [Ping timeout: 260 seconds]     
11:30 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]     
11:31 < 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
11:31 -!- Frederic94500 [4d808e1f@gateway/web/freenode/ip.77.128.142.31] has joined #bitcoin-core-dev     
11:32 < NicolasDorier> the commit on disk is in background on core right ?
11:32 < NicolasDorier> except TxUndo if I remember
11:41 -!- nibor [~nibor@185.9.34.66] has joined #bitcoin-core-dev     
11:44 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev     
11:45 < NicolasDorier> mmh... well, I'll wait I reach later block mayb it's not the case
11:47 -!- kangx [2f2168ed@gateway/web/freenode/ip.47.33.104.237] has joined #bitcoin-core-dev     
11:54 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has quit [Quit: gabridome]     
12:00 -!- whphhg [whphhg@gateway/vpn/mullvad/x-jobdkmhspvpetgpo] has joined #bitcoin-core-dev     
12:00 < jtimon> meeting...
12:01 <@wumpus> congrats on 0.13.1 everyone!
12:01  * btcdrak rings the gong
12:01 <@wumpus> #startmeeting
12:01 < lightningbot> Meeting started Thu Oct 27 19:01:23 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:01 < jtimon> 0.13.1 is out 18 mins ago! yay
12:01 < CodeShark> binaries?
12:01 < kanzure> btcdrak: looks like faq menu entry is working now https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/
12:01 < jeremyrubin> here
12:02 <@wumpus> CodeShark: https://bitcoin.org/bin/bitcoin-core-0.13.1/
12:02  * luke-jr wakes up
12:02 -!- dermoth [~thomas@dsl-66-36-159-136.mtl.aei.ca] has joined #bitcoin-core-dev     
12:02 < CodeShark> Nice!
12:02 < gmaxwell> https://www.reddit.com/r/Bitcoin/comments/59pt66/bitcoin_core_0131_released/
12:03 <@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
12:03 <@wumpus> bitcoin.org should be updated after travis passes on https://github.com/bitcoin-dot-org/bitcoin.org/pull/1400
12:04 < morcos> congrats everyone!
12:04 < sipa> indeed!
12:04 <@wumpus> woohoo!
12:05 < sipa> and thanks everyone for getting us this far
12:05 < luke-jr> wumpus: did we get the gitian builds already? is that a record? :o
12:05 <@wumpus> luke-jr: yes, four signed builders IIRC
12:06 < luke-jr> or maybe it just feels like a record since it was the middle of the night for me
12:06 < jtimon> I'm trying the gitian builder script for the first time
12:06 <@wumpus> it may be a record
12:06 <@wumpus> very fast at least
12:07 < jtimon> btcdrak reminded me I have no good excuse for not doing gitian builds
12:07 < sipa> i haven't even started :(
12:08 < jtimon> well, I have never done it so it may take some time, but the sooner I learn...
12:08 < btcdrak> wumpus: I dont see a signed message from you with the binary hashes
12:08 <@wumpus> BlueMatt: you can release your PPA now (if you didn't yet)
12:09 <@wumpus> btcdrak: https://bitcoin.org/bin/bitcoin-core-0.13.1/SHA256SUMS.asc
12:09 < BlueMatt> wumpus: i have not yet, will try to get that out
12:09 < jonasschnelli> BlueMatt: don't forget to add libzmq
12:09 < harding> btcdrak: https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-October/000023.html
12:09 < jonasschnelli> Some uses have complained about the missing ZMQ support
12:10 < BlueMatt> jonasschnelli: yup
12:11 <@wumpus> ok, any other topics today than 0.13.1?
12:11 < kanzure> i was going to ask sipa or jtimon about libconsensus follow-up stuff
12:12 < sipa> i'm the wrong person to ask
12:12 <@wumpus> I'm kind of tired so I wouldn't mind ending early :p
12:12 < jtimon> kanzure: nothing to report, nobody suggested anything to me or gave me any feedback since last week
12:13 < 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
12:13 < BlueMatt> few minutes late there, gmaxwell 
12:13 < jtimon> been focusing on the signedblocks patch
12:13 < gmaxwell> Just noticed wumpus hadn't done it. :)
12:13 < sipa> maybe we can discuss signed blocks a bit
12:13 < gmaxwell> So there are a number of things we want to do in a 0.13.2; so those should get in soon.
12:14 < 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
12:14 < morcos> (signed blocks)
12:14 < gmaxwell> (I guess some are in and just need to backport to 0.13 branch.
12:14 <@wumpus> no, it's not meant to replace the current testnet
12:14 < kanzure> re: testnet i also saw the suggestion of loading testnet params from json file
12:14 < 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
12:14 < gmaxwell> morcos: my expectation was that it would just be another option. Obviously it would be useless for testing much of anything mining related.
12:15 < jtimon> what I have implemented is from .conf file, not .json file
12:15 <@wumpus> indeed there should at least be a PoW testnet
12:15 < 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
12:15 < morcos> perhaps it would be possible for transactions to easily end up on both?
12:15 < kanzure> jtimon: didn't mean to recommend a specific file format; i was just pulling a thing from memory.
12:15 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has joined #bitcoin-core-dev     
12:16 < morcos> but maybe thats askign for trouble
12:16 <@wumpus> yes the file format is completely not important
12:16 < 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
12: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"
12:16 < 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.
12:16 < sipa> and those aren't reconcilable, i think
12:16 < jtimon> that alone should be helpful for rapidly creating a new segwitnet (for the next thing) or whatever
12:17 < btcdrak> Blog post is up https://bitcoincore.org/en/2016/10/27/release-0.13.1/
12:17 <@wumpus> one testnet is simply not enough for all testing scenarios
12:17 < 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. 
12:17 <@wumpus> btcdrak: awesome
12:17 < 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.
12:18 <@wumpus> kanzure: right - within a trusted group using a regtest is just as useful as signed blocks
12:18 < kanzure> oh is that what the proposal is-- i'll have to go look. sorry.
12:18 <@wumpus> it's only when exposing publicly that signing is necessary so people can't grief by generating e.g. tons of blocks
12:19 < 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.
12:19 < 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.
12:19 < JackH> when will ubuntu ppa's be updated?
12:20 < BlueMatt> JackH: when i get to it (today)
12:20 < JackH> ah sweet, you are fast this time then
12:20 < sipa> btcdrak: nice, the timeline is cool
12:21 < 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?)
12:21 <@wumpus> I think everyone can sign up to make PPAs
12:22  * btcdrak is reading scrollback
12:22 < BlueMatt> luke-jr: its not bad
12:22 < 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..
12:23 < luke-jr> wumpus: yes, it's just not very clear how one would actually make them, especially someone who doesn't use Ubuntu :p
12:23 -!- pedrobranco [~pedrobran@2001:8a0:ff62:a601:20d2:996:b147:47ba] has joined #bitcoin-core-dev     
12:25 < Frederic94500> #bitcoin If segwit doesn't activate, he will be activate to the next 2016 blocks?
12:25 < sipa> parse error
12:25 < 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
12:25 < BlueMatt> Frederic94500: we're in the middle of a meeting, please go to #bitcoin
12:26 < jtimon> for the hash of the genesis block depends on -chainpetname
12:26 <@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
12:26 <@wumpus> luke-jr: no need to run ubuntu yourself
12:26 < jonasschnelli> Luke-Jr: there are also meta-generator that auto-generated deb/PPA and fedora, etc. out of one script/conf
12:26 < BlueMatt> wumpus: only in theory....the upload tool stuff is really a bitch to get installed on non-debian systems
12:26 < luke-jr> :x     
12:27 -!- Frederic94500 [4d808e1f@gateway/web/freenode/ip.77.128.142.31] has quit [Quit: Page closed]     
12:27 <@wumpus> BlueMatt: haha that's sad, I didn't know
12:27 < 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
12:27 -!- pedrobranco [~pedrobran@2001:8a0:ff62:a601:20d2:996:b147:47ba] has quit [Ping timeout: 245 seconds]     
12:28 < jtimon> well, signed blocks have other advantages for testing, but it's definitely more dsiruptive
12:28 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has quit [Quit: gabridome]     
12:28 <@wumpus> bitcoin.org change is merged
12:29 < 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
12:29 < 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
12:29 <@wumpus> right, changing the block header structure is what makes it scary
12:30 < petertodd> wumpus: s/scary/a lot of work/ :)
12:31 < gmaxwell> topic: suggestion final alert stuff.
12:31 < 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
12:31 <@wumpus> I mean more s/scary/high risk/
12: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 
12:31 <@wumpus> the implementation work is not so bad, review, sure
12:31 < sipa> petertodd: pick 2
12:31 < 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
12:31 < jtimon> we could make other chainparams count for the genesis block hash
12:32 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 276 seconds]     
12:33 <@wumpus> I mean introducing some union into CBlockHeader would mean there'd be a risk of regression even in the non-testing case
12:33 < petertodd> wumpus: ah, yes, good point
12:33 < 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)
12:33 < petertodd> wumpus: I'm wrong - that is scary
12:33 < btcdrak> sipa: you have to thank harding! he wrote it all.
12:35 < kanzure> what is remaining re: final alert things?
12:35 < kanzure> was the page on one of the .org sites merged
12:35 < jtimon> topic suggestion: are we removing the use of checkpoints for progress estimation?
12:35 < gmaxwell> kanzure: we're not on that toopic now.
12:36 < gmaxwell> topic suggestion: My work removing checkpoints _completely_.
12:36 <@wumpus> #topic removing checkpoints
12:37 < gmaxwell> I have a branch that is removing checkpoints. Haven't totally taken them out yet because I need to replace progress estimation.
12:37 < gmaxwell> It's not hard to do that, just takes a little twiddling.
12:37 <@wumpus> that's good news - progress estimation is probably the least interesting use of them
12:38 < gmaxwell> https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints
12:38 <@wumpus> yea     
12:38 <@wumpus> #link https://github.com/gmaxwell/bitcoin/tree/remove_checkpoints
12:38 < 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:
12:38 <@wumpus> did you run into something difficult / uncertain?
12:39 < 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.  
12:39 <@wumpus> what about the DoS protection?
12:40 <@wumpus> consensus change, as in a softfork?
12:40 < morcos> do tell
12:40 < gmaxwell> not a softfork. I'm telling.
12:40 < 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.
12:41 < 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. 
12:41 < 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
12:41 < jtimon> isn't the minimum difficulty check a softfork?
12:42 < 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. :)
12:42 <@wumpus> petertodd: well it wouldn't lock in specific blocks as the checkpoints do
12:42 < petertodd> er, gregs #2 thing makes my statement invalid :)
12:42 < jtimon> gmaxwell: yeah, it's a softfork in the pedantic sense
12: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
12:42 < jeremyrubin> I don't think that's great...
12:42 < gmaxwell> jtimon: in a sense, but an unobservable one. Yes.
12:43 < jeremyrubin> Can't difficulty fall that low under a soft fork to a different PoW?
12:43 < jeremyrubin> (not that that should happen)
12:43 < petertodd> jeremyrubin: yes, and at that point your idea of what bitcoin is is so insecure as to be useless
12:43 < gmaxwell> jeremyrubin: then you take out the rule.
12:43 < jtimon> like really imposing the 21 M limit, that was a softfork too, but no need to use bip9 to deploy I guess
12:43 < petertodd> jtimon: +1
12:43 < Chris_Stewart_5> wouldn't that be a hard fork to remove it if it was enforced?
12:43 < 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.
12:44 < 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
12:44 < gmaxwell> If someone worried that 16 million were too high, there is a pretty broad range that the number could reasonable be set in.
12:44 < petertodd> gmaxwell: honestly, I'd be inclined to go even higher - 10 machines is absolutely nothing
12:45 < gmaxwell> Anything over 100k would pretty much halt any real risk headerflooding, with current hardware. 16M adds a good amount of headroom.
12:45 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has joined #bitcoin-core-dev     
12:45 < 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..
12:45 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has quit [Client Quit]     
12:45 < jeremyrubin> petertodd: I disagree, but that's more of a wizards topic
12:45 < jtimon> gmaxwell: are you sure you want to change CheckBlockHeader instead of CheckProofOfWork ?
12:45 < 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?
12:45 < 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
12:46 < jeremyrubin> petertodd: e.g., something like tadge's proof of idle 
12:46 < 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.
12:46 < 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
12:46 < gmaxwell> morcos: it is preserved.
12:46 < gmaxwell> to the extent that it exists.
12:46 < 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
12:46 < jtimon> Chris_Stewart_5: yeah if you want a different pow just hardfork
12:46 -!- gabridome [~gabridome@host189-56-dynamic.16-87-r.retail.telecomitalia.it] has joined #bitcoin-core-dev     
12:46 < 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. 
12:47 < morcos> ok, i need to think about it more.. but i think we should analyze all those scenarios
12:47 < gmaxwell> morcos: but thats also why my figure is ~10 devices and not 10,000 devices. :)
12:47 < 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.
12:47 < 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. :)
12:47 < gmaxwell> But I expected thought and discussion on it.
12:48 < 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
12:48 < petertodd> gmaxwell: if hardware improves, do we up the min diff again? IMO that'd be reasonable
12:48 < morcos> petertodd: not if you've softforked in other PoW requirements that the attackers don't have the hashing or whateve rto produce
12:48 < gmaxwell> BlueMatt: So hold up there.
12:49 < gmaxwell> BlueMatt: I think what I propos has _exactly_ as good protection for that as we currently have, if not somewhat better.
12:49 < Chris_Stewart_5> And this solves header flooding because it requires the attacker to provide headers with ATLEAST that much difficulty, correct? 
12:49 < BlueMatt> gmaxwell: didnt disagree, only suggested that ideally we'd fix the issues we have now
12:49 < 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
12:49 < gmaxwell> BlueMatt: right now we won't accept lower difficulty blocks after we've validated up to a paritcular checkpoint.
12:49 < gmaxwell> (okay I'll still explain as other people might miss this)
12:49 < 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.
12:50 < 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
12:50 < 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)
12:50 < 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
12:50 < 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.
12:50 < BlueMatt> (under first-peer-is-evil attacks, but ok)
12:50 -!- achow101_ [~achow101@unaffiliated/achow101] has quit [Ping timeout: 256 seconds]     
12:51 < gmaxwell> BlueMatt: but my proposal needs only headers.
12:51 < gmaxwell> oh under first peer is attacker
12:51 < petertodd> morcos: anyway, good to do up some deployment scenarios regardless to explain how that'd work
12:51 < BlueMatt> oh, i thought we applied checkpoints against headers now
12:51 < BlueMatt> nvm     
12:51 < sipa> BlueMatt: we do; after passing a certain checkpoint, we don't accept headers that fork off before that checkpoint
12:52 < BlueMatt> ok, lets take this offline
12:52 < BlueMatt> suggested additional topics?
12:52 < gmaxwell> Okay, thats the overview.
12:52 < 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?
12:53 < jtimon> mhmm, pindexBestHeader->nChainWork < UintToArith256(consensusParams.nMinimumChainWork) ? consensusParams.powLimit : consensusParams.powLimitLater
12:53 < jtimon> what about instead... block.nHeight < consensusParams.highPowLimitHeight ? consensusParams.powLimit : consensusParams.powLimitLater
12:53 <@wumpus> #topic the final alert
12:53 <@wumpus> no reason IMO
12:53 < btcdrak> gmaxwell: please get it over with.
12:54 < gmaxwell> Okay. will coordinate. 
12:55 < gmaxwell> jtimon: that would make it trivial for an attacker to capture you on a fake chain.
12:55 < 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.
12:56 < jtimon> gmaxwell: how am I prevented from handling reorgs in the same way as you?
12:57 < sipa> jtimon: creating many blocks is easy. creating much work is hard
12:57 < gmaxwell> anyting left in the meeting (I'll continue this convo after)
12:57 < jtimon> what I think it's add less risk since  consensusParams.highPowLimitHeight is fixed but nMinimumChainWork is expected to chain with each release, no?
12:58 < jtimon> I must be missing something, I don't see the vulnerability that my proposed change introduces
12:58 <@wumpus> ok, that concludes the meeting I think
12:58 <@wumpus> #endmeeting
12:58 < lightningbot> Meeting ended Thu Oct 27 19:58:34 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:58 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.html
12:58 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.txt
12:58 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-10-27-19.01.log.html
12:59 < btcdrak> party time?
12:59 < 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
12:59 < BlueMatt> but that shouldnt matter much
12:59 < 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.
12:59 < jtimon> yes, how my proposed change makes your branch more vulnerable to that attack is what I don't see
13:00 < jtimon> why wouldn't I reorg to the most work change?
13:00 < gmaxwell> Because you won't even process the first block in that chain.
13:00 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
13:00 < sipa> jtimon: because you'll reject the low-difficulty headers from the real chain you get later
13:00 < jtimon> just like your branch without my proposed change, I think
13:00 -!- murch [~murch@p4FE394B1.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
13:01 < jtimon> mhmm, no, say highPowLimitHeight is the current height whatever it is
13:01 < gmaxwell> No. My branch does not activate until you have enough work to be the real chain at the time of the release.
13:01 < gmaxwell> jtimon: yes, 436182.  Say it's that.
13:02 < gmaxwell> Attacker computes 500000 diff 1 headers, and gives you that.
13:02 < jtimon> right, and mine activates at a fixed height, say 436182
13:02 < gmaxwell> Under my code you would sitll reorg to the best chain.
13:02 < jtimon> ok, I accept that chain
13:02 < jtimon> then when I see the real one I reorg, no?
13:02 < gmaxwell> Under your code you would not reorg to the best chain.
13:02 < gmaxwell> No.     
13:02 < jtimon> why not?
13:02 < sipa> jtimon: no, you'll reject the low-difficulty headers once you pass the watermark
13:02 < 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.
13:03 < sipa> jtimon: because this is a fix to the otherwise existing DoS of being able to feed someone low-difficulty headers
13:03 < jtimon> oh, we have limits on reorg, right, sorry, I get it, thanks
13:03 < sipa> no, we don't have limits on reorg
13:03 < gmaxwell> We don't have limits on reorg.
13:03 < jtimon> mhm, let me read again
13:03 < sipa> we just reject headers that are too low difficulty once we know we're past that stafe
13:03 < sipa> *stage
13:04 < 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
13:04 < gmaxwell> if you don't reject low diff headers someone can exaust your memory/disk with header flooding.
13:05 < gmaxwell> which the code you were quoting protect against but wouldn't if it were a height check.
13:06 < 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
13:06 < jtimon> I don't get it but let's move on I will think more about it
13:07 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 260 seconds]     
13:07 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
13:07 < sipa> jtimon: being past 436182 does not mean you're on the right chain
13:07 < sipa> an attacker can veriy easily create such a long chain
13:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has left #bitcoin-core-dev []     
13:08 < sipa> creating as much work of the real 43612 chain is nearly impossible
13:08 < jtimon> sipa: right it means the min diff is higher from now on
13:08 < jtimon> right
13:08 < sipa> jtimon: if yhe min difficulty is more than 1 you will reject the early part of the real chain!!!
13:09 < sipa> because the real chain has diff 1 in the beginning
13:09 < jtimon> and "my code" will always prefer the real chain because it's more work
13:09 < Chris_Stewart_5> Not sure if this this is a good question or not, but is this something deployed with BIP9? 
13:09 < jtimon> sipa: no, the early part of the real chain is height < 436182 !
13:09 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-core-dev     
13:10 < sipa> jtimon: we DO NOT want to accept just any header below height 436182
13:10 < sipa> jtimon: that is exactly the DoS attack this change is intended to fix
13:10 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
13:11 < 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
13:11 < sipa> even in an entirely unrelated chain
13:11 < 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 
13:11 < 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()
13:11 < BlueMatt> does anyone object to me making it call BlockChecked for AcceptBlock failures?
13:11 -!- achow101_ [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
13:11 < 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
13:12 < BlueMatt> so then ProcessNewBlock would only use its CValidationState argument (which would then just be optional) in case of failures, not invalid blocks
13:12 < sipa> jtimon: it only protects us once we see the real chain
13:12 < sipa> jtimon: your proposal can trigger even if we don't have the real chain
13:14 < 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
13:15 < sipa> so you haven't solved the issue
13:15 < jtimon> note I didn't say pindexBestHeader->nHeight but block.nHeight (that is, the header you are checking now)
13:16 < sipa> you're really doing somwthing completely different
13:16 < jtimon> well, that line is supposed to save us from min diff blocks in the future, no?
13:18 < sipa> your change does not prevent that
13:18 < sipa> someone can keep spamming low-height headers in your proposal
13:19 < jtimon> oh, and you won't ignore them if they're < 436182, sorry, I finally get it
13:19 < jtimon> thanks
13:20 < instagibbs> Congrats! Managed to sleep exactly through meeting time. 
13:20 < BlueMatt> ok, I'm removing CValidationState from ProcessNewBlock
13:21 < jtimon> sorry BlueMatt wasn't listening
13:22 < btcdrak> sipa: remember to update your http://bitcoin.sipa.be/ver9-2k.png graphs :)
13:22 < sipa> instagibbs: and through the release
13:22 < sipa> btcdrak: indeed!
13:23 -!- pedrobranco [~pedrobran@bl21-77-63.dsl.telepac.pt] has joined #bitcoin-core-dev     
13:23 < instagibbs> Yeah missed all the action. 
13:24 -!- achow101_ [~achow101@unaffiliated/achow101] has quit [Quit: Leaving]     
13:25 < sipa> BlueMatt: iirc the only reason for CVS in PNB is to return system failure conditions
13:26 < BlueMatt> sipa: nope, its also used to return AcceptBlock errors
13:26 < BlueMatt> sipa: also, its never checked for system failure conditions
13:27 < 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)
13:27 -!- pedrobranco [~pedrobran@bl21-77-63.dsl.telepac.pt] has quit [Ping timeout: 250 seconds]     
13:33 < BlueMatt> jtimon: https://github.com/bitcoin/bitcoin/commit/a4f82de1bdde644e9bad4c524b638dd5bd4d69f7
13:33 < BlueMatt> also, the fact that you can access commits via that url when they arent in the bitcoin/bitcoin repo is freaky
13:35 < 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
13:36 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
13:38 < BlueMatt> anyway, I'll pr it after https://github.com/bitcoin/bitcoin/pull/8969, I know suhas was waiting on it
13:38 < jtimon> BlueMatt: yeah, I definitely like that commit
13:38 -!- skyraider [uid41097@gateway/web/irccloud.com/x-hzypwstdhsjknrtp] has joined #bitcoin-core-dev     
13:39 < jtimon> yeah I only briefly looked at that one, sorry
13:40 < murch> quick question: Does 0.13.1 already include functions for creation of SegWit transactions?
13:40 < BlueMatt> yes     
13:40 < BlueMatt> so did 0.13.0
13:40 < BlueMatt> (its all gated on segwit being activated, so it works on testnet)
13:41 < murch> ah okay, thanks
13:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]     
14:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:11 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
14:13 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-ypuzbhetnqbhfiew] has quit [Quit: Connection closed for inactivity]     
14:14 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 252 seconds]     
14:20 < BlueMatt> wait, did we un-support qt5?
14:20 < BlueMatt> wasnt there talk of deprecating it?
14:26 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection]     
14:35 -!- wasi [~wasi@183.12.202.62.static.wline.lns.sme.cust.swisscom.ch] has quit [Quit: Leaving]     
14:45 < cfields_> BlueMatt: you mean qt4?
14:48 < BlueMatt> uhh, yes
14:49 < cfields_> BlueMatt: i'd say it's pretty well deprecated already. iirc the discussion was about completely dropping support
14:52 < BlueMatt> mmm, nvm, realized it only breaks precise, which was broken by c++11
14:56 < michagogo> Ack, missed another meeting :-/
14:56 < michagogo> Did it start late, or just late ping?
14:57 < luke-jr> I think at this point, once Qt4 becomes a burden we can probably drop it?
14:57 < luke-jr> BlueMatt: what breaks precise?
14:58 < BlueMatt> there is no qt4 on precise
14:58 < BlueMatt> also, the boost in precise doesnt compile in c++11 mode
14:58 < luke-jr> so don't build qt4?
14:59 < luke-jr> I thought we didn't use any boost that had ABI changes for C++11
14:59 < BlueMatt> luke-jr: https://svn.boost.org/trac/boost/ticket/6198
15:00 < luke-jr> compile with GCC?
15:00 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Remote host closed the connection]     
15:00 < BlueMatt> the gcc in precise does not support c++11
15:00 < luke-jr> ugh     
15:01 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
15:01 < BlueMatt> the ppa currently has an empty dummy package for precise
15:01 < BlueMatt> because fuck precise
15:01 < luke-jr> uh     
15:01 < luke-jr> at least leave the old version?
15:02 < BlueMatt> no     
15:02 < luke-jr> …     
15:02 < luke-jr> patch the code to #define size size_arg? >_<
15:02 < BlueMatt> no     
15:02 < BlueMatt> feel free to create the debian/ folder and send it to me and I'll upload
15:02 < BlueMatt> I'm not fighting with it to make precise work
15:02 < luke-jr> XD     
15:03 < luke-jr> wait, to do the PPA you just upload the debian folder?
15:03 < BlueMatt> and the original source archive
15:03 < BlueMatt> (ie git archive)
15:04 < BlueMatt> and two other strange metadata files
15:09 < luke-jr> any reason we can't get gitian to produce the files needing to upload? <.<
15:09 < BlueMatt> gitian? they're all in the source tree
15:09 < BlueMatt> except signed by my pgp key
15:10 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 260 seconds]     
15:10 < 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)
15:10 < luke-jr> so we don't need to do https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage ?
15:11 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []     
15:11 < 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
15:12 < BlueMatt> so, no, its really entirely useless to do anything in gitian for this
15:15 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Write error: Broken pipe]     
15:16 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev     
15:17 -!- pedrobranco [~pedrobran@2001:8a0:ff62:a601:e95e:bb3d:aa4d:e9ca] has joined #bitcoin-core-dev     
15:20 -!- cdecker [~quassel@2a02:aa16:1105:4a80:2ce9:4987:85ed:4607] has quit [Ping timeout: 260 seconds]     
15:21 -!- pedrobranco [~pedrobran@2001:8a0:ff62:a601:e95e:bb3d:aa4d:e9ca] has quit [Ping timeout: 245 seconds]     
15:33 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 250 seconds]     
15:36 < gmaxwell> when did we back off the checkblocks check? was that in 0.13.0 or 0.13.1?
15:59 < BlueMatt> heh, 66/130 connections segwit (with 52/8 blocked)
15:59 < BlueMatt> guess preferential peering works =D
16:15 < sipa> gmaxwell: 0
16:15 < sipa> gmaxwell: 0.13.1
16:15 -!- dstadulis [~dstadulis@2602:30a:2e05:2130:d83a:725e:eae:6a55] has joined #bitcoin-core-dev     
16:16 < gmaxwell> sipa: explaines people saying it stats so much faster.
16:16 < sipa> ha     
16:16 < gmaxwell> sipa: how many connections does your node have?
16:17 < gmaxwell> I am 124/124.
16:21 -!- dstadulis [~dstadulis@2602:30a:2e05:2130:d83a:725e:eae:6a55] has quit [Read error: Connection reset by peer]     
16:22 -!- dstadulis [~dstadulis@2602:30a:2e05:2130:d83a:725e:eae:6a55] has joined #bitcoin-core-dev     
16:26 < sipa> compiling 0.13.1 now
16:27 < sipa> i was on 0.13.0 i think
16:29 < BlueMatt> ok, all ppas are built and published
16:34 -!- echonaut [~echonaut@46.101.192.134] has quit [Read error: Connection reset by peer]     
16:34 -!- echonaut1 [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
16:38 < gmaxwell> BlueMatt: if the ppas are downloadable, go post on reddit?
16:43 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
16:43 -!- dstadulis [~dstadulis@2602:30a:2e05:2130:d83a:725e:eae:6a55] has quit [Ping timeout: 245 seconds]     
16:49 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
16:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]     
16:51 < luke-jr> Why does bitcoincore announcements ML include tracking?
16:57 < sipa> ?     
16:57 < luke-jr> there's an invisible <img> with a tracking id at the bottom
16:58 < luke-jr> it attempts to load the image from the internet, thus informing the webserver it was read
17:00 < midnightmagic> my odroid xu4 has been sync'ing for ..  mm..  four days now I guess. still going, "92%" complete.
17:00 < midnightmagic> Dunno what the hell anyone saying an rpi is a good node is talking about.
17:01 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev     
17:03 -!- pedrobranco [~pedrobran@2001:8a0:ff62:a601:e95e:bb3d:aa4d:e9ca] has joined #bitcoin-core-dev     
17:03 < gmaxwell> midnightmagic: they probably never actually brought one up on it.
17:03 < gmaxwell> Surely no one here has been saying that.
17:04 < gmaxwell> (besides, pretty inadvisable to run on anything with less than 2GB ram)
17:04 < sipa> luke-jr: uh
17:04 < sipa> btcdrak: ^
17:05 < midnightmagic> gmaxwell: 72h ETA assuming current average verification rate.  yikes.
17:06 -!- murch [~murch@p4FE394B1.dip0.t-ipconnect.de] has quit [Remote host closed the connection]     
17:07 < gmaxwell> luke-jr: whats the server?
17:08 -!- pedrobranco [~pedrobran@2001:8a0:ff62:a601:e95e:bb3d:aa4d:e9ca] has quit [Ping timeout: 250 seconds]     
17:10 < luke-jr> https://sendy.bitcoincore.org
17:11 -!- squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Read error: Connection reset by peer]     
17:11 -!- squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev     
17:15 < owowo> midnightmagic: Get a Banana Pi with 9 core ;)
17:15 -!- jnewshoes [~jodie@sydnns0115w-142167035138.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Ping timeout: 245 seconds]     
17:15 < owowo> *8     
17:15 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]     
17:16 -!- jnewshoes [~jodie@sydnns0115w-142167035138.dhcp-dynamic.FibreOp.ns.bellaliant.net] has joined #bitcoin-core-dev     
17:16 -!- tulip [uid192128@gateway/web/irccloud.com/x-oumncyfrrppnxcwd] has joined #bitcoin-core-dev     
17:17 < tulip> owowo: 4+4 core big.LITTLE processors aren't really ideal.
17:17 < midnightmagic> owowo: I have an XU4 with 8 cores! It's pretty quick for a little credit-card-area sbc.
17:18 < owowo> tulip, why not?
17:20 < sipa> sbc?
17:20 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
17:20 < gmaxwell> owowo: because they 'little' cores are power efficient but not fast, you normally don't use all 8 at one time.
17:21 < tulip> it's unclear if the a83t in that Single Board Computer is actually big.LITTLE. 
17:21 -!- skyraider [uid41097@gateway/web/irccloud.com/x-hzypwstdhsjknrtp] has quit [Quit: Connection closed for inactivity]     
17:21 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
17:21 < luke-jr> regardless, POWER8 would still be better :p
17:22 < tulip> ok, I stand corrected, it does actually have 8*a7 cores. in *general* 8 core ARM SoC have been big.LITTLE, which have 4 high power and 4 low power cores with different instruction sets. 
17:22 < owowo> but it works :D
17:24 < owowo> and the HDD works too, though it crashed with the computer from about 1.6 meters.
17:25 < owowo> about 5 years ago ;)
17:38 < BlueMatt> gmaxwell: ok, done
17:44 < phantomcircuit> gmaxwell: i restarted a node at ~tip of master
17:44 < phantomcircuit> a huge number of inbound connections claim to be 0.13.1
17:44 < phantomcircuit> which seems a bit fast
17:45 < gmaxwell> phantomcircuit: preferential peering.
17:48 < sipa> i see a large number of /BTCC:0.13.1/ with 00000001 service bits
17:50 < gmaxwell> oh fake nodes, fake nodes.
17:51 < gmaxwell> I think all of those ended up on my banlist previously for being fake and connecting to everyone.
17:52 < aj> "fake nodes, fake nodes, what you gonna do, what you gonna do when they connect to you?" o/ o/
17:53 < achow101> all those nodes are aws nodes too
17:53 < sipa> yeah i think they're on my banlist
18:02 < BlueMatt> gmaxwell: lol
18:02 < BlueMatt> didnt realize the btcc things were that fake
18:04 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 260 seconds]     
18:05 < achow101> the one with the chinese ip is probably the real one. The rest are all aws nodes which seems a little suspicious
18:23 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-qesqjycjrpjxqifx] has joined #bitcoin-core-dev     
18:23 < shangzhou> I have upgraded my node to 0.13.1
18:23 < shangzhou> From China Suzhou
18:32 -!- PRab_ [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-core-dev     
18:34 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Ping timeout: 260 seconds]     
18:34 -!- PRab_ is now known as PRab     
18:39 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
18:51 -!- fanquake [~Adium@unaffiliated/fanquake] has joined #bitcoin-core-dev     
18:51 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev     
18:52 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-zfbtboastiqsdekd] has joined #bitcoin-core-dev     
18:53 -!- fanquake [~Adium@unaffiliated/fanquake] has quit [Client Quit]     
19:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
19:07 -!- rebroad [~rebroad@223.205.208.152] has joined #bitcoin-core-dev     
19:10 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 244 seconds]     
19:15 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
19:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
19:23 -!- pedrobranco [~pedrobran@2001:8a0:ff62:a601:2c84:4788:1c3c:e00e] has joined #bitcoin-core-dev     
19:27 -!- pedrobranco [~pedrobran@2001:8a0:ff62:a601:2c84:4788:1c3c:e00e] has quit [Ping timeout: 245 seconds]     
19:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]     
20:05 -!- rebroad [~rebroad@223.205.208.152] has quit [Ping timeout: 256 seconds]     
20:10 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 252 seconds]     
20:13 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
20:13 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
20:19 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
20:23 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
20:23 -!- pedrobranco [~pedrobran@2001:8a0:ff62:a601:fc35:27de:5cb6:b52a] has joined #bitcoin-core-dev     
20:28 -!- pedrobranco [~pedrobran@2001:8a0:ff62:a601:fc35:27de:5cb6:b52a] has quit [Ping timeout: 245 seconds]     
20:40 -!- Ylbam_ [uid99779@gateway/web/irccloud.com/x-mamdrgjnroyywxfy] has quit [Quit: Connection closed for inactivity]     
20:41 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
20:43 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 265 seconds]     
20:51 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-qesqjycjrpjxqifx] has quit [Quit: Connection closed for inactivity]     
20:59 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 276 seconds]     
21:03 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
21:16 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
21:18 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
21:18 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 245 seconds]     
21:23 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
21:31 < achow101> gmaxwell: for the alert key retirement, what about testnet's key?
21:35 -!- kangx [2f2168ed@gateway/web/freenode/ip.47.33.104.237] has quit [Ping timeout: 260 seconds]     
21:35 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
21:37 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 256 seconds]     
21:38 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
21:38 -!- andytoshi [~apoelstra@wpsoftware.net] has quit [Read error: Connection reset by peer]     
21:39 -!- andytoshi [~apoelstra@wpsoftware.net] has joined #bitcoin-core-dev     
21:40 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Client Quit]     
21:47 < phantomcircuit> achow101: is there even a separate key
21:50 < achow101> phantomcircuit: there is. mainnet: https://github.com/bitcoin/bitcoin/blob/0.11/src/chainparams.cpp#L51 testnet: https://github.com/bitcoin/bitcoin/blob/0.11/src/chainparams.cpp#L148
21:53 -!- pedrobranco [~pedrobran@bl21-77-63.dsl.telepac.pt] has joined #bitcoin-core-dev     
21:54 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
21:56 -!- rebroad [~rebroad@223.205.208.152] has joined #bitcoin-core-dev     
21:57 -!- pedrobranco [~pedrobran@bl21-77-63.dsl.telepac.pt] has quit [Ping timeout: 245 seconds]     
21:59 -!- DigiByteDev [~JT2@178.208.172.137] has joined #bitcoin-core-dev     
22:04 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
22:05 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 250 seconds]     
22:07 < phantomcircuit> interesting
22:12 < midnightmagic> to.. uh. Whomever? Do you want me to open a new PR re: functional 0.13.1rc3 gitian sig update, or just update the pre-existing one.. or? I've rebuult (in total) the rc3 gitians and actually done a gverify on them against the others available now.
22:17 < midnightmagic> Well. I'll open a new one. Seems github makes that easier.
22:24 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has quit [Ping timeout: 244 seconds]     
22:27 -!- DigiByteDev [~JT2@178.208.172.137] has quit [Quit: DigiByteDev]     
22:36 -!- tunafizz [~tuna@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
22:40 -!- tulip [uid192128@gateway/web/irccloud.com/x-oumncyfrrppnxcwd] has quit [Quit: Connection closed for inactivity]     
22:42 -!- DigiByteDev [~JT2@178.208.172.137] has joined #bitcoin-core-dev     
22:43 -!- tulip [uid192128@gateway/web/irccloud.com/x-dtpbqwufvtgwmbxn] has joined #bitcoin-core-dev     
22:44 < tulip> rebroad: the peer in your issue about "already received" is one with a /ViaBTC/ subversion. in a misguided attempt to improve their stale block rate (which they do have, though their pool reports a false "0") they wrote a piece of software which hammers out blocks to peers that don't request it, burning bandwidth in the process. 
22:48 -!- DigiByteDev [~JT2@178.208.172.137] has quit [Ping timeout: 250 seconds]     
22:50 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
22:54 < phantomcircuit> uh     
22:54 < phantomcircuit> so im not exactly 100% on c++ inheritance stuff
22:54 < phantomcircuit> but i feel like this should work
22:54 < phantomcircuit> https://0bin.net/paste/f9fapca8fsr46oed#Xkqs57RGuJRtBRJBoX25sqxzW7KAiKjIBZAotGks4gR
22:55 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Ping timeout: 256 seconds]     
22:58 < gmaxwell> tulip: I've encountered a number of other nodes doing that, wastes a lot of bandwidth. now that we have BIP152 deployed, we should look to banning peers that send unsolicited full blocks.
22:59 < gmaxwell> perhaps unsolicited CB too (e.g. when they weren't selected to be high bandwidth peers)... though thats less awful.
23:07 -!- DigiByteDev [~JT2@178.208.166.224] has joined #bitcoin-core-dev     
23:08 -!- DigiByteDev [~JT2@178.208.166.224] has quit [Client Quit]     
23:10 -!- DigiByteDev [~JT2@178.208.167.99] has joined #bitcoin-core-dev     
23:10 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 256 seconds]     
23:13 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
23:14 -!- DigiByteDev [~JT2@178.208.167.99] has quit [Ping timeout: 265 seconds]     
23:18 -!- DigiByteDev [~JT2@178.208.174.118] has joined #bitcoin-core-dev     
23:20 < phantomcircuit> gmaxwell: any ideas
23:21 < aj> phantomcircuit: you're trying to access a protected member in an instance of the /base/ class
23:21 < aj> phantomcircuit: if it were an instance of the child class you could do it
23:22 < phantomcircuit> aj: right so i have to actually replace the CWallet object with a CWalletAccountingTests object
23:24 < aj> phantomcircuit: or you could declare CWalletAccounttests a friend class? i don't see any other ways...
23:25 < phantomcircuit> hmm     
23:26 < phantomcircuit> now i need to find where pwalletMain is intialized during testing
23:26 < aj> wallet/test/wallet_test_fixture.cpp?
23:27 < aj> but you might be able to use reinterpret_cast in a way that's not too horrific
23:27 -!- Cory [~Cory@unaffiliated/cory] has quit [Read error: Connection reset by peer]     
23:28 < phantomcircuit> yeah
23:31 < aj> phantomcircuit: http://0bin.net/paste/xjooaSxyMVgrJfAe#-BDbENY7Ld4HMIkB7O3nIAuSdSQpIuDo03jLJh1MnU8 maybe
23:36 < phantomcircuit> yeah i can do that but....
23:37 < aj> ...you don't like the taste of vomit? :)
23:44 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
23:45 -!- DigiByteDev [~JT2@178.208.174.118] has quit [Quit: DigiByteDev]     
23:51 < phantomcircuit> aj: indeed