--- Day changed Wed Oct 19 2016
00:03 < wumpus>  it should be announced earlier so people won't waste time on building <- still makes sense to build to make sure that your gitian infrastructure is working an capable of building deterministic 0.13.1 executables
00:04 < wumpus> also dependencies are cached by gitian so rc2 build will be faster
00:06 < GitHub108> [bitcoin] laanwj closed pull request #8962: Correct checksum error message (and debug node id) (master...CorrectChecksumError) https://github.com/bitcoin/bitcoin/pull/8962
00:08 < GitHub6> [bitcoin] laanwj closed pull request #8957: Additional UpdateBlockAvailability (master...AddUpdateBlockAvailability) https://github.com/bitcoin/bitcoin/pull/8957
00:09 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev     
00:09 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:10 < GitHub111> [bitcoin] laanwj closed pull request #8963: NodeId missing from this debug line (master...SocketSendErrorNodeId) https://github.com/bitcoin/bitcoin/pull/8963
00:12 < sipa> wumpus: wow, do you sleep?
00:12 < wumpus> I've slept a bit
00:13 < wumpus> back to whack-a-mole now...
00:14 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 265 seconds]     
00:15 < wumpus> and merging #8951 and tagging rc2 I guess
00:17 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev     
00:17 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host]     
00:17 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
00:19 < wumpus> anything else that needs to go into rc2 but doesn't have a 'Needs backport' tag?
00:20 < wumpus> sipa: better question, do *you* sleep? You're still here afterall :)
00:21 < tulip> wumpus: #8949 maybe? seems sort of critical.
00:21 < sipa> 8949?
00:21 < tulip> "Be more agressive in getting connections to peers with relevant services."
00:21 < sipa> wumpus: currently at the airport
00:22 < wumpus> thanks added tag
00:22 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]     
00:22 < sipa> wumpus: my comment is more aimed "8 hours ago you were merging/closing PRs, and now again" :)
00:23 < sipa> i'm just hanging out on irc
00:28 -!- nibor [~nibor@185.9.34.66] has joined #bitcoin-core-dev     
00:31 < gmaxwell> I expect 8949 to apply cleanly to 0.13 or nearly so, it's a trivial patch in any case.
00:31 -!- bluerazo_ [~bluerazor@221.176.33.135] has quit [Remote host closed the connection]     
00:32 -!- bluerazor [~bluerazor@221.176.33.135] has joined #bitcoin-core-dev     
00:37 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Read error: Connection reset by peer]     
00:40 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 248 seconds]     
00:41 < wumpus> leave it up to rebroad to come up with lousy suggestions
00:42 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 250 seconds]     
00:42 < gmaxwell> what PR?
00:42 < sipa> 8949
00:43 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev     
00:43 < gmaxwell> lol     
00:43 < Victorsueca> morning
00:43 < wumpus> I mean you're runnig a P2P network with decentralized propagation of node addresses, and what would you want to do, query centralized servers automatically periodically? :p
00:44 < wumpus> morning Victorsueca 
00:44 < gmaxwell> better that he asked instead of submitting a patch "Improve DNSseeding."
00:44 < btcdrak> yeah wumpus I replied to him
00:44 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-jdqomahqfbfjlqse] has joined #bitcoin-core-dev     
00:44 < wumpus> true gmaxwell , very true
00:44 < gmaxwell> had I added the skip I would have written a comment in the code that explained why it was there.
00:44 < gmaxwell> perhaps I should have done so when editing that section.
00:44 < Victorsueca> left 0.13.1rc1 running all night
00:44 < Victorsueca> seems to work good
00:45 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev     
00:45 < wumpus> gmaxwell: you could do it at the same time as the c++11 nit if you want, if not I'll just merge it as-is
00:45 < gmaxwell> Victorsueca: do you have nodewitness peers?
00:47 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
00:47 < gmaxwell> wumpus: Didn't know if we wanted the range based for. Okay, doing.
00:47 < wumpus> 13 witness peers on ereshkigal, two outgoing, rest incoming
00:48 < wumpus> gmaxwell: yes,we do :)
00:48 < wumpus> for new code, absolutely
00:48 < Victorsueca> gmaxwell: have 4
00:48 < gmaxwell> Victorsueca: inbound or outbound?
00:49 < Victorsueca> 3 outbound 1 inbound
00:53 < gmaxwell> will push an update as soon as this compiles.
00:53 < wumpus> going to kick my non-witness outbound peers until they're witness too :)
00:54 < Victorsueca> wumpus: lol, you'll hardfork the network if everybody does that
00:54 < wumpus> Victorsueca: I don't think so, I have plenty of non-witness inbound peers
00:54 < gmaxwell> Victorsueca: nah, it won't partition due to inbounds-- SW is intended to be witness only on outbound.
00:55 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hqbdvukntvmvysvo] has joined #bitcoin-core-dev     
00:55 < gmaxwell> We don't want the topology to suddenly change when SW activates, if something goes wrong it's better if it goes wrong for people as they upgrade.
00:55 < gmaxwell> and once SW is active we'll need to only fetch new blocks from SW peers.
00:56 < sipa> Victorsueca: and if that actually happened, we could set up some proxy nodes to relay across (though that is an emergency only, obviously)
00:57 < wumpus> Victorsueca: though, arguably if everyone did the same things as me it'd be a weird place
00:57 < gmaxwell> yes, if there are any partioning problems as a result of some oversight there, the partition can be healed by even a single fixed node. 
00:58 -!- bluerazor [~bluerazor@221.176.33.135] has quit [Ping timeout: 256 seconds]     
01:03 < wumpus> it's somewhat working: gained one more outgoing witness peer
01:08 < gmaxwell> I updated #8949 but did not rerun tests locally (laptop slow, took all that time to just compile it. :) )
01:09 -!- mkarrer_ [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has quit [Read error: No route to host]     
01:10 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
01:10 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
01:10 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
01:12 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Ping timeout: 258 seconds]     
01:15 < wumpus> gmaxwell: luckily there's travis, and also if you just changes the loop type I'm not terribly afraid of that messing up :)
01:16 < gmaxwell> just letting you know.
01:16 < sipa> it's not like we're merging things and then immediately after marking it as release candidate
01:16 < sipa> oh, wait
01:16 < btcdrak> XD     
01:17 < wumpus> noo, we woudl never do something ill-advised like that
01:18 < Victorsueca> lol     
01:19 < gmaxwell> maybe we should think about having a non-mandatory beta as part of the process. I noticed RC picked up a lot of testing pretty much instantly.. way more than what we had going on with 0.13 before it.
01:20 < wumpus> non-mandatory beta?
01:21 < wumpus> sounds intruiging, how do you suggest forcing people to install it :)
01:21 < gmaxwell> hah I mean when we think were close to an rc, tagging something as 'beta' as inspiration to get people to switch their attention.
01:21 < wumpus> oh, never mind, NON-mandatory. Boo.
01:21 < gmaxwell> lol     
01:22 -!- rebroad [~rebroad@180.183.72.230] has joined #bitcoin-core-dev     
01:22 < gmaxwell> We only have mandatory fun.
01:22 < wumpus> well the good news is that we can use the word 'beta' now in releases
01:22 < rebroad> is testnet broken?
01:22 < Victorsueca> if you think more testing is required then the beta release is pretty much mandatory
01:22 < wumpus> as it's no longer a static part of the release naming, as it used to be
01:23 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev     
01:23 < gmaxwell> rebroad: looks fine to me, can you be more specific?
01:24 < rebroad> My node and my peers are al stuck on block 998938
01:24 < rebroad> all     
01:24 < rebroad> have raised an issue for it
01:25 < gmaxwell> rebroad: why are you saying they're stuck?
01:25 < rebroad> based on their reported startheight and my last new best
01:26 < gmaxwell> if your height is 998938 and all of their height is 998938 ... then perhaps you are all one big happy family.
01:26 < rebroad> have been for over an hour now
01:26 < tulip> receive version message: /Satoshi:0.11.0/: version 70002, blocks=1002280
01:26 < Victorsueca> rebroad: have you considered the possibility that 998938 is the best block right now?
01:27 < gmaxwell> it looks like the best block to me.
01:27 < tulip> rebroad: that's pretty normal for testnet though, and even the main network, frequently there's no blocks for hours at a time. 
01:27 < gmaxwell> may just be no one is actively mining at the moment.
01:27 < rebroad> I am seeing many headers for higher heights though                                                                              
01:28 < Victorsueca> maybe testnet is hard-forked
01:28 < gmaxwell> Yes, and?
01:28 < Victorsueca> that's why some nodes have a higher height
01:28 < Victorsueca> there's nothing to do with that
01:28 < gmaxwell> it has been for something like 6 months now, rogerver's "bitcoin.com" pool.
01:28 < rebroad> why isn't my node sending getdata requests for headers that are new to the block index though?
01:28 < gmaxwell> Not being sent by witness peers.
01:29 < tulip> that's not really a good view to have as your first diagnosis. testnet is very frequently completely hosed, it's par for the course. 
01:29 < rebroad> unless proof of work is too low or something.. i guess more debug is needed
01:29 -!- laurentmt [~Thunderbi@80.215.234.43] has joined #bitcoin-core-dev     
01:30 < rebroad> AcceptBlockHeader returns true and AddToBlockIndex was called... but it needs more debug to debug
01:30 < Victorsueca> "needs more debug to debug" -genius
01:32 < rebroad> either it's broken or my understanding is wrong. probably the latter
01:32 -!- laurentmt [~Thunderbi@80.215.234.43] has quit [Client Quit]     
01:34 < sipa> rebroad: < gmaxwell> Not being sent by witness oeers.
01:35 -!- laurentmt [~Thunderbi@80.215.234.43] has joined #bitcoin-core-dev     
01:36 < GitHub170> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/05998da5a7e2...1230890a6d04
01:36 < GitHub170> bitcoin/master a1919ad R E Broadley: Report NodeId in misbehaving debug
01:36 < GitHub170> bitcoin/master 1230890 Wladimir J. van der Laan: Merge #8936: Report NodeId in misbehaving debug...
01:36 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev     
01:36 < GitHub189> [bitcoin] laanwj closed pull request #8936: Report NodeId in misbehaving debug (master...NodeIdWhenMisbehaving) https://github.com/bitcoin/bitcoin/pull/8936
01:39 < gmaxwell> https://www.blocktrail.com/tBTC appears to be having fun, it's a non-SW testnet explorer and it seems to be jumping back in forth between different chains. 
01:39 < wumpus> we have a blocktrail contact
01:41 < gmaxwell> pretty interesting to reload it and watch the block numbers constantly change but continue reading 1 hr 48m ago.
01:42 < gmaxwell> may be nothing wrong there, I currently don't have any non-SW testnet nodes, but that chain may be flapping around in a reorg war.
01:42 < wumpus> hehe
01:44 -!- laurentmt [~Thunderbi@80.215.234.43] has quit [Quit: laurentmt]     
01:44 < GitHub181> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/1230890a6d04...e44753c06794
01:44 < GitHub181> bitcoin/master 9583477 Gregory Maxwell: Be more aggressive in connecting to peers with relevant services....
01:44 < GitHub181> bitcoin/master 4630479 Gregory Maxwell: Make dnsseed's definition of acute need include relevant services....
01:44 < GitHub181> bitcoin/master e44753c Wladimir J. van der Laan: Merge #8949: Be more agressive in getting connections to peers with relevant services....
01:44 < GitHub25> [bitcoin] laanwj closed pull request #8949: Be more agressive in getting connections to peers with relevant services. (master...more_agressive_witness_connect) https://github.com/bitcoin/bitcoin/pull/8949
01:48 < Victorsueca> has somebody actually tried to fill a block over 1MB on testnet too see if the whole witness thing works and doesn't hard-fork the chain due to a invalid block size?
01:48 -!- mkarrer_ [~mkarrer@109.69.10.67] has joined #bitcoin-core-dev     
01:48 < aj> Victorsueca: https://testnet.smartbit.com.au/blocks?sort=size
01:49 < tulip> Victorsueca: you're not being at all helpful by continuously saying that. 
01:49 < Victorsueca> tulip: when did I say it previously?
01:49 < Victorsueca> aj: thanks
01:50 < wumpus> SegWit has been extensively tested, if  we weren't sure "the whole witness thing works" it certainly wouldn't have been merged
01:50 < Victorsueca> wumpus: I guess so, just couldn't find any block that went over 1MB
01:51 < wumpus> and certainly no activation parameter would have been set on mainnet
01:51 < gmaxwell> Victorsueca: yes, there are many very large blocks on testnet (and segnet before it)
01:51 < gmaxwell> Victorsueca: https://testnet.smartbit.com.au/block/0000000000000896420b918a83d05d028ad7d61aaab6d782f580f2d98984a392
01:51 < wumpus> Victorsueca: sure, then just ask a question, instead of injecting fud into it
01:51 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has quit [Ping timeout: 252 seconds]     
01:52 < Victorsueca> wumpus: sorry, didn't mean to FUD stuff
01:52 < wumpus> okay :)
01:54 < GitHub172> [bitcoin] MarcoFalke opened pull request #8972: [Qt] make warnings label selectable (master...Mf1610-qtWarnSelJS) https://github.com/bitcoin/bitcoin/pull/8972
01:55 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
01:55 < btcdrak> wumpus: rubensayshi and afk11 are Blocktrail contacts
01:56 < btcdrak> but Blocktrail isnt segwitty, so use https://testnet.smartbit.com.au/ for the time being
01:56 -!- cdecker [~quassel@2a02:aa16:1105:4a80:183c:ad5:f656:aa73] has joined #bitcoin-core-dev     
01:56 < wumpus> btcdrak: thanks
01:57 < rebroad> MarcoFalke, how did you find that commit by jonasschnelli to fix #8970 so quickly?!
01:58 < wumpus> search the current pulls / issues before opening a new one
01:58 < MarcoFalke> out of memory :P
01:59 < MarcoFalke> rebroad: I think it helps if "trivial" pull don't come in massive batches. If you see there is still a "trivial" pull open on your name, make sure to queue up additional ones locally.
01:59 < GitHub169> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e44753c06794...b2df292e341d
01:59 < GitHub169> bitcoin/master 59daa58 Luke Dashjr: RPC/Mining: getblocktemplate: Update and fix formatting of help
01:59 < GitHub169> bitcoin/master b2df292 Wladimir J. van der Laan: Merge #8951: RPC/Mining: getblocktemplate: Update and fix formatting of help...
01:59 < MarcoFalke> You can submit a new one when the old one got merged.
01:59 < MarcoFalke> or closed
01:59 < GitHub139> [bitcoin] laanwj closed pull request #8951: RPC/Mining: getblocktemplate: Update and fix formatting of help (master...gbt_help_update) https://github.com/bitcoin/bitcoin/pull/8951
02:00 < rebroad> MarcoFalke, "locally"?
02:00 < MarcoFalke> on your machine
02:00 < MarcoFalke> in your .git folder
02:00 < wumpus> MarcoFalke: interesting, why did the original change never get merged? it looks fine
02:00 < rebroad> MarcoFalke, you mean some sort of "rate limiting"?
02:00 < MarcoFalke> ^     
02:00 < MarcoFalke> Jup, we have over 100 open pulls and there is lack of review.
02:00 < wumpus> yes, rate limiting, to avoid DoSing other people
02:02 < rebroad> MarcoFalke, to hold back branches on my end would create more rebase work for me. I tend to work in bursts, so the PRs get raised in bursts too. 
02:02 < MarcoFalke> Then wumpus has to go ahead and merge something and later on people complain that there are bugs in master.
02:02 < wumpus> which is fine if the topics of the branches are wildly different
02:02 < btcdrak> each comment, or action taken on the tracker mails 1230 people...
02:02 < MarcoFalke> rebroad: But it seems you don't even compile the changes sometimes
02:02 < wumpus> but if they are the same or simlar (e.g. change a log message) then group them or add them to an existing PR
02:03 < MarcoFalke> Please make sure to put work in a pull before you send it to a thousand people
02:03 < MarcoFalke> at least: compile, run tests, run python tests
02:03 < MarcoFalke> Also, mention the motivation in the commit body or pull body
02:03 < MarcoFalke> (I know I don't do it either, sometimes)
02:04 < MarcoFalke> but it is good practice and helps review
02:04 < wumpus> I don't think there's ever a good reason for one person to submit 8 pulls at once, I'm sure some are similar or part of similar intent
02:04 < wumpus> working on 8 completely disparate things at the same time is beyond the scope of human memory :p
02:05 < rebroad> MarcoFalke, I am sometimes guilty of not compiling after what looks like a very simple rebase...  I do need to revise my workflow admittedly
02:05 < MarcoFalke> I stole the commit from https://github.com/bitcoin/bitcoin/pull/7134/commits
02:05 < MarcoFalke> :P     
02:05 < rebroad> MarcoFalke, I am only just starting to familiarise myself with the tests.... do you mean "make check" or something else?
02:06 < MarcoFalke> ./qa/pull-tester/rpc-tests.py
02:06 < rebroad> wumpus, "8 pulls at once"? why ever not?
02:06 < wumpus> rebroad: so did #8972 solve your problem?
02:06 < MarcoFalke> We need more people running the pull tester suite, anyway
02:07 < wumpus> rebroad: because a) it comes over as horribly spammy, there are 120 pulls open by many different people, you're monoolizing the pull list with trivial stuff b) as I said above, if there's so many changes you must be able to combine a few as they will share a theme
02:08 < wumpus> 'shoot a buckshot at the codebase and see what sticks' is not a strategy for development
02:09 < wumpus> at least not one that respects the time constraints and priorities of other people partaking in the project
02:12 < wumpus> to get started on testing, read https://github.com/bitcoin/bitcoin#automated-testing , it mentions the kinds of tests available
02:12 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev     
02:14 < rebroad> wumpus, how does it make any difference between raising 1 PR a day, and 7 only on Saturdays?
02:14 < wumpus> please, dont' keep arguing this
02:15 < rebroad> wumpus, you put forward an argument (based on false assumptions) and then complain when I correct those assumptions. I am not interested in hearing your rants.
02:15 < tulip> for anyone following, there's progress on testnet now. 
02:15 < wumpus> then just go away
02:15 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ     
02:16 -!- mode/#bitcoin-core-dev [+b *!*@180.183.72.230] by wumpus     
02:16 -!- rebroad was kicked from #bitcoin-core-dev by wumpus [rebroad]     
02:16 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ     
02:20 -!- bluerazor [~bluerazor@221.176.33.135] has joined #bitcoin-core-dev     
02:25 < GitHub106> [bitcoin] laanwj pushed 3 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/2c0913d0b3e1...7c2bf4b1759b
02:25 < GitHub106> bitcoin/0.13 33cd553 Gregory Maxwell: Be more aggressive in connecting to peers with relevant services....
02:25 < GitHub106> bitcoin/0.13 91ae0b0 Gregory Maxwell: Make dnsseed's definition of acute need include relevant services....
02:25 < GitHub106> bitcoin/0.13 7c2bf4b Luke Dashjr: RPC/Mining: getblocktemplate: Update and fix formatting of help...
02:27 < GitHub93> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b2df292e341d...d736a6eb1f91
02:27 < GitHub93> bitcoin/master ef0c9ee Jonas Schnelli: [Qt] make warnings label selectable
02:27 < GitHub93> bitcoin/master d736a6e Wladimir J. van der Laan: Merge #8972: [Qt] make warnings label selectable (jonasschnelli)...
02:27 < wumpus> MarcoFalke:  #8972 for 0.13 too?
02:27 < GitHub37> [bitcoin] laanwj closed pull request #8972: [Qt] make warnings label selectable (jonasschnelli) (master...Mf1610-qtWarnSelJS) https://github.com/bitcoin/bitcoin/pull/8972
02:28 < MarcoFalke> Should not matter
02:28 < wumpus> ok, going to update the release notes lists and pulling in new translations and tagging rc2
02:30 < gmaxwell> oops.
02:30 < gmaxwell> backport is going to fail to compile.
02:30 < wumpus> we'll hear from travis soon I guess
02:30 < gmaxwell> net.cpp:1718:108: error: ‘nMaxOutbound’ was not declared in this scope if ((addr.nServices & nRelevantServices) != nRelevantServices && (nTries < 40 || nOutbound >= (nMaxOutbound >> 1)))
02:32 < Victorsueca> RIP backport
02:33 < gmaxwell> replace with MAX_OUTBOUND_CONNECTIONS
02:33 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ     
02:34 -!- mode/#bitcoin-core-dev [-b *!*@180.183.72.230] by wumpus     
02:34 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ     
02:35 -!- rebroad [~rebroad@180.183.72.230] has joined #bitcoin-core-dev     
02:35 < rebroad> Apologies for earlier. I need to learn to get less emotionally involved in my pull requests.
02:36 < wumpus> we all do, np, it's kind of a stressful time and not a good time to pick fights now :)
02:36 < rebroad> oh.. I didn't realise that? stress due to SegWit...? bitcoin related?
02:36 < btcdrak> releases are always stressful. lots to get done.
02:37 < MarcoFalke> rebroad: Also the pull request backlog
02:37 < rebroad> ah ok. will bear that in mind. PRT (pre-release-tension)
02:37 < btcdrak> ha!     
02:38 -!- PRab_ [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-core-dev     
02:39 < rebroad> I am inclined to think of the backlog in the same way I think of my browser tabs. I have so many I struggle to keep track of them.. I do need to find a new system to organise them rather than a simple list as they currently are. Perhaps there might be a similar way to organise the issues - i.e. it's not the large number that's the issue but they way they are organised/sorted..?
02:40 < btcdrak> rebroad: well the first thing we can do is be good citizens and consider the whole process - submitting a PR is just one part of the process. Think of reviewers and the effort they have to go through to verify and review. This is why grouping things is important. Etiquette starts from there.
02:40 < rebroad> if there is anything I can do to help make the backlog seem less daunting, please do let me know
02:40 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Ping timeout: 252 seconds]     
02:40 -!- PRab_ is now known as PRab     
02:41 < btcdrak> rebroad: review more PRs
02:41 < btcdrak> review and _test_
02:42 < wumpus> "error: use of undeclared identifier 'nMaxOutbound'; did you mean 'nOutbound'" eh, no thangs clang
02:42 -!- bluerazor [~bluerazor@221.176.33.135] has quit []     
02:42 < rebroad> btcdrak, I certainly could do that, although it's hard to know which ones to review and test. is there an easy way to see which ones require greater attention or are the more useful/desired PRs?
02:42 < gmaxwell> wumpus: yea, helpful compiler suggestions: Good news, your code compiles. You really didn't want that nice compiler static analysis to actually help you find bugs, right?
02:43 < btcdrak> rebroad: right, so putting yourself in the POV of the reviewers is very good practice...
02:43 < MarcoFalke> rebroad: Those tagged for 0.14, right now.
02:43 < rebroad> MarcoFalke, ah... great starting point. thanks
02:44 < MarcoFalke> We have also different labels where you can group by. E.g. https://github.com/bitcoin/bitcoin/pulls?q=is%3Apr+is%3Aopen+label%3AP2P
02:45 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Ping timeout: 250 seconds]     
02:50 < GitHub144> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/7c2bf4b1759b...0dbc48a5bd83
02:50 < GitHub144> bitcoin/0.13 53e6196 Wladimir J. van der Laan: qt: pre-rc2 translations update
02:50 < GitHub144> bitcoin/0.13 0dbc48a Wladimir J. van der Laan: nMaxOutbound is MAX_OUTBOUND_CONNECTIONS on 0.13...
02:52 < rebroad> has anyone else notices that the arrows point the wrong way in the peer table in the debug window? I've raised #8959 to fix this
02:52 < rebroad> (the arrows to indicate sort direction)
02:53 < wumpus> I haven't noticed, but don't think I've ever paid close attention to it so it's certainly possible
02:53 < Victorsueca> you mean the ones on the table sort?
02:53 < rebroad> Victorsueca, yes
02:54 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
02:54 < Victorsueca> ahh yeah, I aalways felt weird when sorting that table, now I know why
02:54 < rebroad> I wasn't sure if I fixed it in the best pace. the way I did it makes columns default to descending when you first click to sort them
02:54 -!- drizztbsd is now known as timothy     
02:55 < rebroad> which is fine as descending is the more useful for most of the columns, IMHO
02:56 < rebroad> an extra click to make it ascending, of course
02:56 < wumpus> for things such as ping that makes sense, I guess, the only time descending is annoying is in text columns
02:58 < Victorsueca> I think the arrow should be a bit darker to make it more visible, this is pure aesthetics tho
02:58 -!- maluzek_ [~user@xd9bef696.dyn.telefonica.de] has joined #bitcoin-core-dev     
02:58 < wumpus> that's up to your theme
02:59 < Victorsueca> ahh windows theme
03:00 < Victorsueca> but it seems to be rendered as text, why is it lighter than the rest of text?
03:00 < wumpus> I don't know where qt takes the theme from on windows
03:01 < wumpus> in any case it's not something that should be micro-managed, e.g. I have a theme that is pretty much black on black so marking the arrow *darker* would make it invisible :)
03:02 < Victorsueca> that could be solved with a white outline
03:02 < Victorsueca> but anyway, it's ok now, no reason to bother on that
03:03 < wumpus> that's up to the theme, too
03:04 < wumpus> some of the altcoins set up their own qt theme instead of using the system theme, but I think that's kind of pushy, no need to push your asthethic preferences to others
03:04 < Victorsueca> yeah, dogecoin for example uses a funny typography
03:05 < GitHub156> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/6e8936032fb865c0448bec0e0f168e041a586285
03:05 < GitHub156> bitcoin/0.13 6e89360 Wladimir J. van der Laan: doc: Update release notes for rc2
03:07 -!- maluzek_ [~user@xd9bef696.dyn.telefonica.de] has quit [Quit: leaving]     
03:11 < Victorsueca> 3 outbound 2 inbound right now
03:13 < wumpus> 4 outbound 10 inbound SW connections here
03:13 < Victorsueca> found a fail on the peers screen
03:13 < Victorsueca> some peers display "via 127.0.0.1:8333" instead of the address bitcoin is bound to
03:15 < gmaxwell> Victorsueca: you have tor HS peers.
03:15 < Victorsueca> tor peers display "via mytoraddress.onion:8333"
03:17 < gmaxwell> Victorsueca: no, _outbound_ hs peers do, inbound ones are 127,0,0,1.
03:17 < Victorsueca> ahh, makes sense
03:18 < tulip> there's no meaningful identifier for them other than "hey there's a tcp connection" 
03:18 -!- testnet [~testnet@pub082136074119.dh-hfc.datazug.ch] has joined #bitcoin-core-dev     
03:18 < gmaxwell> I expect someday we'll listen on a special port for those... and then we'll be able to display "onion" or whatnot.
03:19 < Victorsueca> it's a bit deceptive to invert a "something via something" sentence without explanation
03:21 < Victorsueca> maybe we should rephrase that to "Local address:...." and "Remote address:..."
03:21 -!- testnet0 [~testnet@pub082136074119.dh-hfc.datazug.ch] has joined #bitcoin-core-dev     
03:21 -!- testnet [~testnet@pub082136074119.dh-hfc.datazug.ch] has quit [Read error: Connection reset by peer]     
03:27 -!- testnet0 is now known as testnet     
03:27 -!- rebroad [~rebroad@180.183.72.230] has quit [Ping timeout: 260 seconds]     
03:29 < wumpus> yes, listening on a special port would make a lot of sense
03:29 < wumpus> not sure why we haven't chosen to do that esp. for the auto-torcontrol stuff
03:30 < wumpus> another things some hs hosts do is to use alternative localhost interfaces, e.g. 127.0.0.2, but the alternative port is a no-brainer
03:33 -!- testnet [~testnet@pub082136074119.dh-hfc.datazug.ch] has quit [Quit: testnet]     
03:35 -!- Victorsueca is now known as Victor_sueca     
03:35 -!- Victor_sueca is now known as Victorsueca|Mob     
03:35 -!- Victorsueca|Mob is now known as aceusrotciV     
03:35 -!- aceusrotciV is now known as Tipper     
03:36 -!- Tipper is now known as ErroneousNicknam     
03:36 -!- ErroneousNicknam is now known as Victorsueca     
03:40 < gmaxwell> yea, for autocontrol its especially a no-brainer... other than needing to find another reliably free port.
03:40 < gmaxwell> (it could be ephemeral, but better if not.. if I saw a random listning port on my host I'd be rather concerned. :) )
03:41 < wumpus> won't TCP automatically choose a port for you if you listen() without setting one?
03:41 < tulip> 6667 seems pretty unused. 
03:41 < tulip> if you attempt to listen on port 0, apparently that's the behaviour. 
03:41 < wumpus> oh, random is not good, okay wouldn't know then. Just pick a new fixed one one and put it in chainparams then
03:42 < gmaxwell> just means that when you run multiple daemons on the same network and host, they'll collide.
03:42 < gmaxwell> same as p2p/rpc.
03:43 < wumpus> https://github.com/bitcoin/bitcoin/issues/8973  in the issue I propose ` hsport` option for that
03:43 < tulip> random would also have the weird effect of killing other daemons that try to bind to something after bitcoind 
03:43 < gmaxwell> wumpus: sounds great to me.
03:43 < Victorsueca> what about random but exclude common ports?
03:43 < wumpus> why would it kill other daemons?
03:43 < gmaxwell> the special port would also allow more than labling, e.g. preferrential relay to HS peers.. which we can only do for outbound hs peers right now.
03:43 < tulip> wumpus: say bitcoind came up, randomly chose 22, and then openssh tried to come up. 
03:44 < wumpus> I'm all for daemon-kiliing functionality in bitcoind, but arguably it should happen intentionally :p
03:44 < btcdrak> is that everything now for rc2?
03:44 < gmaxwell> tulip: it won't randomly choose 22. It will get some port over 32768.
03:44 < tulip> gmaxwell: talking hypothetical, but ok. 
03:45 < gmaxwell> kernel reserves some range of ports for ephemeral use that is outside of the range normally used for services.
03:45 < wumpus> I wonder if tor can create some kind of private, non-TCP socket
03:45 < wumpus> anyhow that's not relevant to solving the issue, but for the far future would be nice list
03:45 < tulip> gmaxwell: so there's privileged 1-1023, and >32768 for ephemeral. are there any other ranges?
03:46 < wumpus> btcdrak: I think so!
03:46 < btcdrak> wumpus: my gitian VM is ready!
03:46 < wumpus> tulip: ranges are configurable and depend on the OS, although <1024 private is pretty ingrained (I think windows is an exception there?)
03:46 < gmaxwell> tulip: not coming to mind. keep in mind these are local policy... there are sysctls to change them.
03:47 < gmaxwell> yea, for a long time if you could get access to ports <1024 you could escilate to root access on other hosts that rhosts trusted your host. 
03:48 < tulip> I hate to think what caused that to be implemented. 
03:49 < wumpus> yeah rsh :-(
03:51 -!- shangzhou [uid156782@gateway/web/irccloud.com/x-jdqomahqfbfjlqse] has quit [Quit: Connection closed for inactivity]     
03:51 < wumpus>  * [new tag]         v0.13.1rc2 -> v0.13.1rc2
03:52 < wumpus> I guess that was a time in which the number of people having enough knowledge to circumvent that was so small that you could just trust them not to do it, sysadmin-inside-knowledge-based-access-control or so:p
03:52  * Victorsueca starts compiling
03:52 < gmaxwell> wumpus: yea, that time lasted about 10 minutes.
03:53  * btcdrak starts gitian
03:56 < wumpus> gmaxwell: yes I can't imagine it taking long. And after that the long period it was (mis)configured by default on some OSes
03:59 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
04:09 -!- fengling [~fengling@223.223.187.136] has quit [Ping timeout: 268 seconds]     
04:13 < Victorsueca> so... rc2 has gmaxwell's aggressive witness node search right?
04:13 < wumpus> yes     
04:18 < btcdrak> that sounds so mafia
04:19 < Victorsueca> lol     
04:19 < btcdrak> the node needs a witnesss protection program
04:24 < sipa> bitcoind --aggressive=passive
04:34 < Victorsueca> done building, now starting
04:45 < jonasschnelli> [22:07:48] <wumpus:#bitcoin-core-dev> jonasschnelli: could you elaborate in #8546 what you mean with " I think its acceptable if it breaks wallets used back in 0.3.x in conjunction with IP transaction". I don't think it'd be acceptable if the client suddenly crashes if someone happens to be using a wallet that still has a pay-to-IP transaction in it.
04:45 < jonasschnelli> Yes. Your probably right... 
04:46 < jonasschnelli> I don't have enough informations about the field-usage of IP transactions... 
04:47 < jonasschnelli> Better keep the code as it is
04:51 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
04:53 -!- cryptapus [~cryptapus@87.254.202.160] has joined #bitcoin-core-dev     
04:53 -!- cryptapus [~cryptapus@87.254.202.160] has quit [Changing host]     
04:53 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
04:53 < arubi> is it bad to symlink the database directory which is in datadir (contains log.0000000001 like files) to a tmpfs filesystem like /dev/shm ?  It makes things like importing scripts and generating keys much quicker for me, e.g. initial keypool population takes 14418ms vs. 4236ms with the database dir in /dev/shm
04:53 < arubi> I did (superficially with iotop) notice that a lot of writing is done to this log.0000.. file when I import many scripts, so this is why I ask.
05:02 < Victorsueca> 7 witness peers now, all outbound
05:04 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
05:12 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
05:19 < wumpus> arubi: I don't know about berkeleydb specifics but having the wallet database crossing filesystem boundaries is reasonably dangerous
05:19 < achow101> was rc1 DOA?
05:20 < wumpus> arubi: also tmpfs is lost on reboot, which means you may lose data
05:22 < arubi> wumpus, yea I'm aware about the second point. thought about copying it back to the hard drive periodically, but didn't take into account if bdb itself might not like it.  I'll rtfm about bdb
05:25 < jonasschnelli> BDB has some really strange way of storing data...
05:26 < jonasschnelli> Look at http://bitcoin.stackexchange.com/questions/48070/format-of-mkey-field-in-encrypted-wallet-dat-file
05:27 < jonasschnelli> I tried to track this down and found out, that the chunks of the records value are stored in different locations.
05:31 < luke-jr> https://curl.haxx.se/mail/lib-2016-10/0076.html sigh
05:32 < arubi> thanks for the lead jonasschnelli 
05:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:44 < wumpus> jonasschnelli: yeah I wouldn't mind changing the 'transaction details' window if anyone has a good plan to do so, but this just seemed like ripping out a few things at semi-random, not sure either whether it would affect things such as watch-only or payment requests
05:44 < jonasschnelli> wumpus: Yes. Indeed.
05:44 < wumpus> with so many more urgent pulls open, it didn't seem worth the bother
05:46 < wumpus> gah instead of building rc2 I re-built rc1
05:46 < wumpus> achow101: yes
05:47 < wumpus> it didn't have the version bumped and BlueMatt discovered a crash issue within a few minutes
05:48 < wumpus> (probably in an RPC command that only he uses, but okay that's clearly a bug that shouldn't be in a release)
05:49 < jonasschnelli> wumpus: what crash? The wallet/init one? https://github.com/bitcoin/bitcoin/pull/8928
05:49 < wumpus> addnode
05:49 < wumpus> #8928 issue doesn't exist in 0.13
05:49 < wumpus> fairly sure it was introduced in the refactoring
05:50 < jonasschnelli> We should extend addnode's RPC tests
05:50 < wumpus> yes     
05:52 < jonasschnelli> wumpus: The RPC command-structure refactoring (https://github.com/bitcoin/bitcoin/pull/8788) includes your JSONRPCRequestObj renaming now. Would be nice to get this in soon to escape the rebase-hamster-wheel
05:53 < luke-jr> I still prefer 8775 :x
05:54 < luke-jr> it's just ugly to have request.params everywhere
05:57 < wumpus> I like request.params
05:58 < wumpus> it's literally "request parameters", what naming could be better
05:58 < jonasschnelli> I think request.param improves readability
05:58 < luke-jr> params is clear and much shorter. but whatever
05:58 < jonasschnelli> params is to generic and could be interpreted as local scope var
05:59 < luke-jr> obviously when it comes to taste, majority rules, so if everyone else disagrees, just go ahead and do it
05:59 < wumpus> yes it's a bit of a taste issue
05:59 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev []     
05:59 < jonasschnelli> Right. The important thing is, that we have a flexible container in the RPC command function structure.
06:01 < wumpus> right
06:20 < BlueMatt> who is mining testnet-segwit?
06:20 < BlueMatt> phantomcircuit: or Lightsword, maybe?
06:24 < tulip> BlueMatt: me, problem?
06:25 < GitHub21> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/d736a6eb1f91...97c7f7362f9b
06:25 < GitHub21> bitcoin/master 23c32a9 Wladimir J. van der Laan: rpc: Change JSONRPCRequest to JSONRPCRequestObj...
06:25 < GitHub21> bitcoin/master 69d1c25 Jonas Schnelli: [RPC] Give RPC commands more information about the RPC request
06:25 < GitHub21> bitcoin/master e7156ad Jonas Schnelli: [RPC] pass HTTP basic authentication username to the JSONRequest object
06:25 < GitHub131> [bitcoin] laanwj closed pull request #8788: [RPC] Give RPC commands more information about the RPC request (master...2016/09/rpc_container) https://github.com/bitcoin/bitcoin/pull/8788
06:28 < BlueMatt> tulip: yes, we havent addnode'd between the new fibre test network and your mining bitcoind :p
06:34 < wumpus> jonasschnelli: darn now #7551 needs rebase again
06:34 < luke-jr> :p     
06:39 < wumpus> I really think we should merge that one soon, it's been open for ages and he's been rebasing time after time and fixing load of nits after load of nits. And it has tests. I'm not convinced that it is bugless (it adds a lot of functionality) but it'd probably be better to merge it so it gets more testing.
06:40 < wumpus> but it's very useful functionality that definitely needs to be in 0.14
06:44 -!- fengling [~fengling@43.255.176.6] has joined #bitcoin-core-dev     
06:46 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
06:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
07:00 -!- wumpus [~wumpus@pdpc/supporter/professional/wumpus] has quit [Quit: leaving]     
07:01 -!- wumpus [~wumpus@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev     
07:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:02 -!- wumpus [~wumpus@pdpc/supporter/professional/wumpus] has quit [Client Quit]     
07:03 -!- wumpus [~wumpus@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev     
07:05 < btcdrak> BlueMatt: Lightsword, but he stopped mining yesterday to let cfields test out cgminer I believe.
07:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hqbdvukntvmvysvo] has quit [Quit: Connection closed for inactivity]     
07:08 -!- adiabat [~adiabat@67.205.158.84] has joined #bitcoin-core-dev     
07:18 < luke-jr> http://arstechnica.com/security/2016/10/flaw-in-intel-chips-could-make-malware-attacks-more-potent/ :/
07:20 < wumpus> the branch prediction profiling makes local attacks (e.g. against the kernel) somewhat easier, ASLR is still a good measure against remote attacks
07:23 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
07:24 < wumpus> also think function-level ASLR (selfrando) would make this harder to exploit, as you cannot just guess one offset and compute others from it
07:25 < wumpus> haven't heard about using that at the kernel level though :)
07:27 < BlueMatt> hey-o, fibre works on segwit
07:27 < BlueMatt> look at that
07:27 < BlueMatt> anyone need high-speed testnet blocks? :p
07:27 < wumpus> awesome!
07:27 < BlueMatt> even worked on the first try :)
07:29 < wumpus> of course we need fast testnet blocks
07:31 < adiabat> repost from wizards, but anyone know what's up with testnet3?
07:32 < adiabat> seem to be 2 chains
07:32 < BlueMatt> what about it?
07:32 < BlueMatt> all my nodes ended up on the same chain when i synced them last night?
07:32 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
07:32 < BlueMatt> adiabat: is classic forked off again?
07:32 < adiabat> could be
07:32 < adiabat> test.webbtc.com is where I can see another one, that's longer
07:33 < adiabat> seems to diverge at 996198, but not sure why
07:33 < BlueMatt> 2016-10-19 14:25:57.059547 UpdateTip: new best=00000000000f939a09a192c06dec99490018fa8dc488cb25cc9141612eb57bf2 height=1003480 version=0x20000000 log2_work=68.579739 tx=11657519 date='2016-10-19 14:45:27' progress=1.000000 cache=0.3MiB(1882tx)
07:33 -!- rebroad [~rebroad@223.205.201.120] has joined #bitcoin-core-dev     
07:38 < GitHub143> [bitcoin] s-matthew-english opened pull request #8974: readability improvement (master...patch-5) https://github.com/bitcoin/bitcoin/pull/8974
07:40 < adiabat> BlueMatt: yeah I'm on that one as well.  Guess it doesn't really matter, just curious why there's a longer (presumably invalid) chain
07:41 < BlueMatt> adiabat: well at least tulip and Lightsword are both mining
07:41 < BlueMatt> maybe they're not peered.....
07:42 < GitHub129> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/97c7f7362f9b...5d2c8e524e10
07:42 < GitHub129> bitcoin/master fc14609 mruddy: RPC: augment getblockchaininfo bip9_softforks data
07:42 < GitHub129> bitcoin/master 5d2c8e5 Wladimir J. van der Laan: Merge #7948: RPC: augment getblockchaininfo bip9_softforks data...
07:42 < GitHub154> [bitcoin] laanwj closed pull request #7948: RPC: augment getblockchaininfo bip9_softforks data (master...version_bits_locked_in_block) https://github.com/bitcoin/bitcoin/pull/7948
07:50 < jonasschnelli> wumpus: Yes. 7551 should go in soon. I gave it my tested ACK (tested pretty well), though, some comments where added/amend-changed afterwards.
07:50 < jonasschnelli> sipa said he want to test it as well (before we merge)
07:51 < jonasschnelli> I think we should merge it and fix (possible) issues later
07:51 < jonasschnelli> but the rebase needs to be done
07:51 < jonasschnelli> I guess 8788 will lead to plenty of rebases
07:58 < btcdrak> Lightsword wanna connect to FIBRE?
07:59 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vdjqgigcycapvway] has joined #bitcoin-core-dev     
08:06 < GitHub37> [bitcoin] MarcoFalke closed pull request #8974: readability improvement (master...patch-5) https://github.com/bitcoin/bitcoin/pull/8974
08:07 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-esevveyphvvmyxqo] has quit [Read error: Connection reset by peer]     
08:07 < tulip> adiabat: BlueMatt: 00000000000f939a09a192c06dec99490018fa8dc488cb25cc9141612eb57bf2 is my chain and is valid with 0.13.1. I don't know why webbtc is showing a different one, I noticed that before. 
08:07 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-cguhrffmamatrwdz] has joined #bitcoin-core-dev     
08:08 < GitHub48> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/5d2c8e524e10...3e942a7060fe
08:08 < GitHub48> bitcoin/master 1880aeb Luke Dashjr: Qt: Get the private key for signing messages via WalletModel
08:08 < GitHub48> bitcoin/master 178cd88 Luke Dashjr: Qt/splash: Specifically keep track of which wallet(s) we are connected to for later disconnecting
08:08 < GitHub48> bitcoin/master 3e942a7 Jonas Schnelli: Merge #8774: Qt refactors to better abstract wallet access...
08:08 < GitHub155> [bitcoin] jonasschnelli closed pull request #8774: Qt refactors to better abstract wallet access (master...multiwallet_prefactor_qt) https://github.com/bitcoin/bitcoin/pull/8774
08:09 < tulip> I have >30 peers connected to that node, 11 of which are NODE_WITNESS. if there's a peering problem it's unlikely to be mine. 
08:23 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [K-Lined]     
08:29 < GitHub135> [bitcoin] jonasschnelli closed pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (master...multiwallet_prefactor_rpc) https://github.com/bitcoin/bitcoin/pull/8775
08:34 < Lightsword> btcdrak, sure
08:40 -!- Anduck [~Anduck@unaffiliated/anduck] has quit [Quit: leaving]     
08:42 < GitHub16> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3e942a7060fe...475d68252e9c
08:42 < GitHub16> bitcoin/master acf853d Johnson Lau: Add script tests for FindAndDelete in pre-segwit and segwit scripts
08:42 < GitHub16> bitcoin/master 475d682 Wladimir J. van der Laan: Merge #8927: Add script tests for FindAndDelete in pre-segwit and segwit scripts...
08:42 < GitHub87> [bitcoin] laanwj closed pull request #8927: Add script tests for FindAndDelete in pre-segwit and segwit scripts (master...findanddeletetest) https://github.com/bitcoin/bitcoin/pull/8927
08:45 -!- mkarrer [~mkarrer@7.red-83-47-85.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
08:49 -!- mkarrer_ [~mkarrer@109.69.10.67] has quit [Ping timeout: 256 seconds]     
08:53 -!- Anduck [~Anduck@unaffiliated/anduck] has joined #bitcoin-core-dev     
09:00 -!- fengling [~fengling@43.255.176.6] has quit [Ping timeout: 268 seconds]     
09:06 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev     
09:11 < GitHub183> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/475d68252e9c...c5875773561c
09:11 < GitHub183> bitcoin/master 37aefff Matt Corallo: Fix init segfault where InitLoadWallet() calls ATMP before genesis
09:11 < GitHub183> bitcoin/master c587577 Wladimir J. van der Laan: Merge #8928: Fix init segfault where InitLoadWallet() calls ATMP before genesis...
09:11 < GitHub121> [bitcoin] laanwj closed pull request #8928: Fix init segfault where InitLoadWallet() calls ATMP before genesis (master...2016-10-fix-segfault) https://github.com/bitcoin/bitcoin/pull/8928
09:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]     
09:28 -!- goatpig [5a5c653a@gateway/web/freenode/ip.90.92.101.58] has joined #bitcoin-core-dev     
09:29 -!- laurentmt [~Thunderbi@80.215.178.194] has joined #bitcoin-core-dev     
09:30 < goatpig> is someone trolling the testnet?
09:34 -!- laurentmt [~Thunderbi@80.215.178.194] has quit [Quit: laurentmt]     
09:36 < btcdrak> goatpig: what do you mean?
09:41 < goatpig> someone pointed me to a 4k long fork
09:42 < goatpig> got me thinking
09:42 < rabidus_> how did your software manage that? :P
09:42 < goatpig> no idea, someone showed that to me
09:43 < goatpig> so, say i create a SW anyone can spend output
09:43 < goatpig> mine it
09:43 < goatpig> spend it
09:43 < goatpig> that would fork the chain for any 0.13 testnet node
09:43 < goatpig> but 0.12 nodes would see it as valid
09:43 < goatpig> say I throw in a couple asics and mine the hell out of that fork
09:44 < goatpig> I could maintain a testnet fork for a wihle, right?
09:46 < arubi> it really doesn't matter what you do.  sure the partitioning of post fork and pre fork nodes is obvious, but that's any soft fork.  you're really fighting hashpower, which is what pow is about
09:46 < goatpig> im trying to figure out if someone could pull that out on the testnet
09:47 < goatpig> im not concerned about the mainnet because, precisely because of the hashpower competition there
09:47 < arubi> you could probably do that on testnet, sure
09:47 < goatpig> ok     
09:49 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 250 seconds]     
09:51 < Victorsueca> testnet shows "Warning: unknown new rules activate (versionbit 28)
09:51 < Victorsueca> activated*
09:52 < jtimon> oh, rc already?
09:52 < jtimon> oh, rc2 already?
09:53 < Victorsueca> yep     
09:53 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev     
09:54 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
09:55 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
09:56 < wumpus> yes, rc1 was doa
09:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:00 < wumpus> for rc2 we're actually going to upload executables
10:00 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]     
10:00 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev     
10:00 -!- drizztbsd is now known as timothy     
10:02 -!- cbit [~Camar@47.148.176.74] has joined #bitcoin-core-dev     
10:03 < cbit> I'm getting hit with spy nodes again. Running RC1, and just checked the peers connected after running it all night.
10:05 < GitHub127> [bitcoin] jtimon opened pull request #8975: Chainparams: Trivial: In AppInit2(), s/Params()/chainparams/ (master...0.13-chainparams-init) https://github.com/bitcoin/bitcoin/pull/8975
10:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vdjqgigcycapvway] has quit [Quit: Connection closed for inactivity]     
10:16 -!- face [~face@mail.hmel.org] has quit [Ping timeout: 244 seconds]     
10:22 < btcdrak> testnet is a total mess at the moment. Not sure this diff 1 thing is working out very well.
10:31 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 248 seconds]     
10:34 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
10:42 -!- Alina-malina [~Alina-mal@37.157.216.129] has joined #bitcoin-core-dev     
10:49 < Chris_Stewart_5> Yeah, I was trying to figure out what the heck is going on
10:49 < Chris_Stewart_5> btcdrak: What is the difficult 1 thing? 
10:52 < rabidus_> if there is no mined blocks within x minutes, difficulty drops to 1
10:53 < rabidus_> so no one can make difficulty bomb at testnet
10:53 < Chris_Stewart_5> rabidus_: Yes, but blocks are clearly being mined within the 20 minute threshold, unless it was dropped or something
10:54 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
10:55 < cbit> uh. 58 connections off a fresh rc2. Everything inbound: 52.xx.... At least I have 6 outbound witness peers off the bat, one being wumpus ha
11:01 < molz> how can you tell if your node and other nodes are witness nodes or not?
11:02 < rabidus_> i know how to tell that my node is :P
11:03 < molz> mine is  0.13.1rc2 but bitnodes doesn't list it as a witness node
11:04 < goatpig> shoudn't that be advertized in the services?
11:04 < Lauda> cbit just ban it all
11:05 -!- cbit [~Camar@47.148.176.74] has quit [Ping timeout: 249 seconds]     
11:08 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
11:10 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
11:18 -!- Alina-malina [~Alina-mal@37.157.216.129] has quit [Changing host]     
11:18 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
11:21 < achow101> wtf. gitian is failing to build the binaries.
11:23 < wumpus> what error? mac/linux/win all built fine here
11:24 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
11:25 < achow101> it fails for all three for me
11:25 < achow101> here's the log starting from actually building the binaries for windows http://pastebin.com/rSDHf76d
11:25 < Victorsueca> windows built correctly here using WSL
11:26 < wumpus> "     
11:26 < wumpus> x86_64-w64-mingw32-g++: internal compiler error: Killed (program cc1plus)"
11:26 < wumpus> either out of memory, or memory corruption/CPU overheat
11:27 < wumpus> could also be a compiler bug, but those are extrememly rare, usually it's a hw issue :/
11:27 < rabidus_> hot stuff
11:27 < achow101> ok... The memory is whatever gitian's default is
11:28 < achow101> If it's a hardware issue, i'm not too surprised then. This computer I'm using has some hardware issues.
11:30 < wumpus> you could try with lower parallelism
11:30 < wumpus> -j8 is a lot, esp. if you didn't increase the amount of memory available
11:31 < achow101> ok. I didn't set the -m parameter this time. so I guess I should set that?
11:33 < wumpus> --memory 3000 is recommended by reease-process.md
11:33 < wumpus> that is if you don't change -j from the default
11:34 < achow101> well. I just set it to -j8 and -m 9000 because I have cores and memory to spare
11:54 < btcdrak> i just use -j4 and nothing else, works nicely for me
12:00 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
12:01 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
12:02 -!- cbit [~Camar@139.182.205.165] has joined #bitcoin-core-dev     
12:06 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds]     
12:06 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]     
12:14 -!- JackH [~laptop@79-73-190-13.dynamic.dsl.as9105.com] has quit [Remote host closed the connection]     
12:14 -!- cbit [~Camar@139.182.205.165] has quit [Quit: Leaving]     
12:21 -!- cbit [~Camar@139.182.205.165] has joined #bitcoin-core-dev     
12:21 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
12:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
12:42 -!- cbit [~Camar@139.182.205.165] has quit [Ping timeout: 250 seconds]     
12:55 -!- cbit [~Camar@139.182.205.165] has joined #bitcoin-core-dev     
12:56 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]     
12:59 < sipa> wumpus: maybe you know: http://bitcoin.stackexchange.com/q/49077/208
12:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
13:16 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
13:17 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Max SendQ exceeded]     
13:19 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has joined #bitcoin-core-dev     
13:23 -!- cbit [~Camar@139.182.205.165] has quit [Ping timeout: 250 seconds]     
13:34 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qkghpjpxgkzgzcoy] has joined #bitcoin-core-dev     
13:43 -!- cbit [~Camar@139.182.205.165] has joined #bitcoin-core-dev     
13:47 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has quit [Quit: MarcoFalke]     
13:51 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev     
13:52 < michagogo> rc2 detached sigs coming soon?
13:55 -!- cbit [~Camar@139.182.205.165] has quit [Ping timeout: 250 seconds]     
13:56 < michagogo> Oh, right, that's still cfields_
13:56 < michagogo> Why did I think wumpus was doing those these days
13:56 < cfields_> michagogo: will do in a bit, my cpus are tied up atm
13:58 -!- cryptapus_afk is now known as cryptapus     
14:00 < michagogo> cfields_: np
14:02 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!]     
14:04 < michagogo> cfields_: I think my shell should now be retrying it every 10 minutes until it works
14:04 < michagogo> so whenever you push them up, my result should show up
14:05 < michagogo> (until <myscript>; do sleep 600; done)
14:05 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
14:05 -!- cbit [~Camar@139.182.205.165] has joined #bitcoin-core-dev     
14:23 -!- cdecker [~quassel@2a02:aa16:1105:4a80:183c:ad5:f656:aa73] has quit [Ping timeout: 250 seconds]     
14:29 < BlueMatt> so there was a reasonably large performance regression in block acceptance time jeremyrubin found a while back...what are folks opinions on https://github.com/TheBlueMatt/bitcoin/commits/2016-10-fix-tx-regression ?
14:29 < BlueMatt> it switches ProcessNewBlock's block pointer to a shared_ptr to a const CBlock
14:29 < BlueMatt> ehh, fuck it, I'ma just pr it
14:30 < sipa> BlueMatt: which pr caused the regression?
14:30 < BlueMatt> the one where we moved tx wallet callbacks out of main
14:30 < BlueMatt> because now we keep a vector of every tx we connected
14:30 < BlueMatt> which requires lots of copies
14:31 < BlueMatt> solution: keep a shared_ptr to the block itself either as you deserialize it or as you call into ProcessNewBlock
14:31 < BlueMatt> later we should change the CValidationState callback to just take that shared_ptr instead of calling it for each tx
14:31 < sipa> does #8515 affect it?
14:32 < BlueMatt> sipa: I'm talking about txChanged, not txConflicted
14:32 < BlueMatt> so, no
14:32 < sipa> ok     
14:32 < BlueMatt> though probably conflicts like a motherfucker
14:33 < BlueMatt> sipa: if you go ahead and rebase that I'll ack it and then we dont have to have two open prs that conflict so much
14:33 < BlueMatt> (if you have time)
14:33 < sipa> BlueMatt: about to land in SF, i can rebase 8515 in a few hours
14:34 < BlueMatt> sipa: alright, I'll hold off until tomorrow
14:34 < BlueMatt> sipa: give gmaxwell a big hug from me :p
14:37 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
14:37 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
14:37 < sipa> :)     
14:39  * gmaxwell guesses he should go into the office.
14:46 -!- goatpig [5a5c653a@gateway/web/freenode/ip.90.92.101.58] has quit [Quit: Page closed]     
14:54 -!- cryptapus is now known as cryptapus_afk     
15:03 -!- cbit [~Camar@139.182.205.165] has quit [Ping timeout: 252 seconds]     
15:05  * achow101 is about to throw his computer out the window
15:06 < sipa> achow101: graphics acceleration at 9.81 m/s^2?
15:08 < achow101> :)     
15:18 -!- achow101 [~achow101@unaffiliated/achow101] has quit [Quit: Leaving]     
15:22 -!- cbit [~Camar@139.182.205.165] has joined #bitcoin-core-dev     
15:25 -!- achow101 [~achow101@unaffiliated/achow101] has joined #bitcoin-core-dev     
15:28 -!- cbit [~Camar@139.182.205.165] has quit [Ping timeout: 260 seconds]     
15:31 < cfields_> gitian builders: detached sigs for 0.13.1rc2 pushed
15:34 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]     
15:37 -!- cbit [~Camar@139.182.205.165] has joined #bitcoin-core-dev     
15:39 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
15:40 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
15:43 -!- cbit [~Camar@139.182.205.165] has quit [Ping timeout: 250 seconds]     
15:51 < sipa> test
15:51 -!- sipa [~pw@unaffiliated/sipa1024] has left #bitcoin-core-dev []     
15:52 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev     
15:52 < sipa> d_t: yow
15:54 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
15:55 -!- cbit [~Camar@139.182.205.165] has joined #bitcoin-core-dev     
15:56 < d_t> sipa: yow
15:56 < sipa> :)     
16:04 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]     
16:07 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
16:08 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
16:27 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qkghpjpxgkzgzcoy] has quit [Quit: Connection closed for inactivity]     
16:27 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 245 seconds]     
16:50 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
17:05 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 252 seconds]     
17:09 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
17:15 -!- cbit [~Camar@139.182.205.165] has quit [Ping timeout: 250 seconds]     
17:23 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 256 seconds]     
17:31 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
17:34 -!- d_t [~textual@83-244-233-135.cust-83.exponential-e.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
17:44 -!- cbit [~Camar@139.182.205.165] has joined #bitcoin-core-dev     
17:53 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
18:03 -!- cbit [~Camar@139.182.205.165] has quit [Ping timeout: 250 seconds]     
18:25 -!- jujumax [~jujumax@host101.200-45-126.telecom.net.ar] has joined #bitcoin-core-dev     
18:32 < wumpus> "graphics acceleration at 9.81 m/s^2" hahahah genius
18:33 < sipa> wumpus: based on an old linux joke "the best windows accelerator is one that works at 9.81 m/s^2"
18:33 < sipa> also, why are you awake?
18:34 < sipa> i have an excuse, it's 6:30 pm here.
18:35 < wumpus> I have no excuse
18:35 < wumpus> it's eh 03:35 here :D
18:38 -!- Yogh_ [~Yogh@f36186.upc-f.chello.nl] has quit [Ping timeout: 250 seconds]     
18:38 -!- Yogh [~Yogh@f36186.upc-f.chello.nl] has joined #bitcoin-core-dev     
18:44 < wumpus> the freebsd issue on stack exchange is weird, my gut feeling is that it has something to do with locale settings but I saw nothing of the kind at least with 0.13
18:45 -!- fengling [~fengling@223.223.187.136] has joined #bitcoin-core-dev     
19:03 -!- jujumax [~jujumax@host101.200-45-126.telecom.net.ar] has quit [Ping timeout: 248 seconds]     
19:22 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Ping timeout: 244 seconds]     
19:23 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev     
19:26 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev     
19:27 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 265 seconds]     
19:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
19:32 -!- shaiguit1r [~rosenfs@shairosenfeld.com] has quit [Write error: Broken pipe]     
19:32 -!- shaiguitar [~rosenfs@shairosenfeld.com] has joined #bitcoin-core-dev     
19:38 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]     
19:39 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev     
19:40 -!- rebroad [~rebroad@223.205.201.120] has quit [Ping timeout: 256 seconds]     
19:46 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
19:47 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:49 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 245 seconds]     
19:55 -!- rebroad [~rebroad@223.206.64.164] has joined #bitcoin-core-dev     
20:01 < wumpus> rc2 executables up https://bitcoin.org/bin/bitcoin-core-0.13.1/test.rc2/
20:01 < achow101> Did the release email go out?
20:01 < wumpus> no     
20:02 < achow101> ok. Shouldn't you be asleep?
20:02 < wumpus> could announce the rc on mailng list, but an rc does not warrant a 'release email'
20:03 < wumpus> this is only a test, not a release yet
20:04 < achow101> i meant like the email saying that the rc exists.
20:04 < achow101> like https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2016-August/000017.html
20:04 < wumpus> yea, will send one, but I thought peopel here may be interested in it as well and it's easier to paste an url
20:05 < achow101> oh ok
20:05 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Ping timeout: 256 seconds]     
20:08 < wumpus> good time to sneak out a rc2 mail though while the US is distracted with their clown show :)
20:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:33 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev     
20:53 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has quit [Quit: Whatever]     
21:00 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev []     
21:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]     
21:16 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Excess Flood]     
21:16 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev     
21:44 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
21:48 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
21:57 -!- Alina-malina [~Alina-mal@37.157.216.159] has joined #bitcoin-core-dev     
22:00 -!- dermoth [~thomas@dsl-199-102-156-15.mtl.aei.ca] has quit [Read error: Connection reset by peer]     
22:01 -!- dermoth [~thomas@dsl-199-102-156-15.mtl.aei.ca] has joined #bitcoin-core-dev     
22:04 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
22:07 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev]     
22:08 -!- jtimon [~quassel@211.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]     
22:31 < NicolasDorier> passing flag CLEAN_STACK to libconsensus seems to make crash the whole process.
22:32 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev     
22:33 < NicolasDorier> somehow https://github.com/bitcoin/bitcoin/blob/v0.13.1rc2/src/test/data/script_tests.json#L1831
22:33 < NicolasDorier> now crash
22:33 < NicolasDorier> when using libconsensus
22:33 < NicolasDorier> trying to deep what it going on
22:33 < NicolasDorier> dig     
22:34 < wumpus> strange
22:35 < wumpus> on master or 0.13.1?
22:35 < jl2012> does libconsensus has CLEANSTACK flag?
22:35 < NicolasDorier> downloaded libconsensus from https://bitcoin.org/bin/bitcoin-core-0.13.1/test.rc2/
22:35 < jl2012> i thought it only has consensus critical flags?
22:36 < NicolasDorier> jl2012: was working before, and the flags in libconsensus are not reallyused, the flags is coverted into a SCRIPT_VERIFY flag without check
22:36 < wumpus> no, it doesn't
22:36 < wumpus> https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.h#L50
22:36 < wumpus> that doesn't crashing is a valid outcome ofcourse
22:37 < NicolasDorier> and it is not the cause https://github.com/bitcoin/bitcoin/blob/master/src/script/bitcoinconsensus.cpp#L88 
22:37 < jl2012> using CLEANSTACK without WITNESS would fail assertion?
22:37 < NicolasDorier> the flags is converted into SCRIPT_VERIFY
22:37 < NicolasDorier> not really using the libconsensus flags at all
22:39 < wumpus> can you post a traceback?
22:39 < jl2012> https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1505
22:40 < NicolasDorier> I'm checking if it is not my binding code between C# and C++ which is at fault... But it would be strange as the previous version was working nice. wumpus : how can I do a traceback on windows ? I may be able to use windbg, but not sure if the output of it would be of big use
22:41 < wumpus> don't ask me how to do debugging on windows :)
22:41 < jl2012> NicolasDorier: what would happen if you add a WITNESS flag to the test?
22:41 < NicolasDorier> trying that
22:41 < NicolasDorier> one sec
22:42 < NicolasDorier> jl2012: with the flag, no crash
22:43 < jl2012> so that's the reason
22:44 < NicolasDorier> yep, can reproduce crash if P2SH|CLEANSTACK not with P2SH|WITNESS|CLEANSTACK... why did the bitcoin C++ test worked fine ?
22:44 < jl2012> sipa: we should add WITNESS flag to all tests with CLEANSTACK
22:44 < jl2012> NicolasDorier: I'm also wondering the same
22:45 < jl2012> maybe it failed before the assertion at L1505 is triggered
22:45 < NicolasDorier> yeah, and why did it not failed before when using libconsensus OO
22:45 < NicolasDorier> checking
22:46 < jl2012> to fix it, search all tests with CLEANSTACK. They should all have P2SH and WITNESS
22:47 < jl2012> also, all tests with WITNESS must have P2SH
22:47 < NicolasDorier> jl2012: I'm step by stepping my C# code, and I confirm that this test should pass through those asserts
22:48 < jl2012> with all 3 flags?
22:48 < NicolasDorier> with 2 flags. So the assert is the cause of the crash, but why it did not crashed on C++ tests really bother me
22:49 < wumpus> yes, that is really strange
22:52 < NicolasDorier> jl2012: also I don't understand why WITNESS should be set at all cost if CLEANSTACK is set
22:53 < NicolasDorier> I think adding WITNESS to all CLEANSTACK test is the wrong way
22:53 < NicolasDorier> CLEANSTACK | P2SH should not fail
22:54 < wumpus> well the P2SH rationale is explained
22:54 < wumpus> "Disallow CLEANSTACK without P2SH, as otherwise a switch CLEANSTACK->P2SH+CLEANSTACK would be possible, which is not a softfork (and P2SH should be one)."
22:54 < wumpus> don't know about WITNESS
22:54 < NicolasDorier> yes for P2SH not a problem
22:54 -!- rebroad [~rebroad@223.206.64.164] has quit [Ping timeout: 256 seconds]     
22:54 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]     
22:56 < wumpus> NicolasDorier: it's adding the flags in the tes https://github.com/bitcoin/bitcoin/blob/master/src/test/script_tests.cpp#L163
22:56 < jl2012> Witness script is violation of cleanstack
22:57 < NicolasDorier> wumpus: oh thanks
22:57 < wumpus> that explains why the C++ tests do pass, updating the tests would have been clearer.
22:58 < NicolasDorier> I still think that CLEANSTACK | P2SH should not crash
22:58 < NicolasDorier> even without this test change
22:58 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
22:59 < jl2012> It's only a problem if we had a cleanstack softfork before witness
23:01 < NicolasDorier> jl2012: What I mean is that segwit should not break something that was working before, if it is not activated... Users of libconsensus were passing P2SH | CLEANSTACK
23:01 < NicolasDorier> now, if they just update the library, their code will crash
23:01 < NicolasDorier> even if witness is not activated
23:02 < jl2012> Then we need to remove that assert
23:03 < NicolasDorier> I think we should yes
23:03 < wumpus> but CLEANSTACK isn't even part of the libconsensus API
23:04 < wumpus> you've been relying on undocumented behavior, that can change from release to release
23:04 < NicolasDorier> mh good point
23:04 < wumpus> I don't think crashing with an assert is any good way of error handling , but still
23:05 < wumpus> the asserts are there to prevent bugs, e.g. "this combination of flags should not be used", and through libconsensus it shouldn't even be possible to pass them. Possibly libconsensus should do better input checking on the flag bits.
23:06 < wumpus> I'm not against removing the asserts if it doesn't actually protect against something dangerous, but the rationale in the comment seems pretty grave
23:08 < NicolasDorier> I would prefer removing the assert so we don't break code that were using this undoc API if not dangerous. But if we keep it, a comment about it would be very useful
23:09 < wumpus> one of the arguments against doing libconsensus in the first place was this - as the API is set in stone, it makes us less flexible to change things. Doubly so if even undocumented behavior is considered.
23:10 < wumpus> guaranteeing one bug-for-bug compatible interface (the consensus itself) ought to be enough of a challenge
23:10 < NicolasDorier> I agree. But the alternative (making an alt implementation) is even more dangerous I think. One way to fix the problem would be to add a "flags = flags & CONSENSUS_FLAGS" 
23:11 < wumpus> but why do you really need this?
23:11 < NicolasDorier> if the user passed non consensus flags (like I already did), then the function would just strip the non consensus bits instead of crashing
23:11 < wumpus> yes I think the call should fail (with an error code, not an assertion) when unrecognized bits are passed in
23:13 < NicolasDorier> we can do that, I'm still a bit worried as I think lots of people passed SCRIPT_VERIFY_STANDARD to this call.
23:13 < wumpus> just ANDing them out can be risky too. There is no guarantee that the bits will aways map one to one to internal script verification bits
23:13 < NicolasDorier> yes I understand. So might be good to do it now before libconsensus is too much use
23:13 < wumpus> may warrant mentioniong in the release notes then
23:13 < NicolasDorier> is not
23:29 < wumpus> ugh, even our own tests make use of this undocumented API
23:34 -!- Alina-malina [~Alina-mal@37.157.216.159] has quit [Changing host]     
23:34 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
23:35 < GitHub0> [bitcoin] laanwj opened pull request #8976: libconsensus: Add input validation of flags (master...2016_10_bitcoinconsensus_input_checking) https://github.com/bitcoin/bitcoin/pull/8976
23:49 -!- rebroad [~rebroad@node-17ka.pool-118-173.dynamic.totbb.net] has joined #bitcoin-core-dev     
23:50 -!- molz [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]     
23:50 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev     
23:52 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 250 seconds]     
23:56 < wumpus> NicolasDorier: I'm not entirely convinced of #8976 yet, at the least because it can't pass the combinations required to pass our own tests right now, but I hope it will start a discussion about what we really want the behavior to be here
23:57 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
23:57 < NicolasDorier> wumpus: We can also expose the whole SCRIPT_VERIFY to libconsensus (it is ok, as I doubt this will ever change)
23:58 < NicolasDorier> I'm kind of neutral, I think we can break the API and reject wrong flags, libconsensus is not too much used yet for doing that. 
23:58 < wumpus> yes, though I remember back in the day when libconsensus API was drafted there were reasons not to do so
23:58 < wumpus> I think the point is that only consensus flags are offered, the rest is kind of arbitrary
23:59 < wumpus> but uhm, we'd have to change our approach to testing at least then
23:59 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev     
23:59 < NicolasDorier> yeah, it also make sense. The base of the problem being that the script evaluator has policy AND consensus code :D