--- Day changed Wed Sep 14 2016
00:00 < sipa> jonasschnelli: yes, agree there
00:00 < wumpus> what did I break?
00:00 < jonasschnelli> ;-)
00:01 < sipa> wumpus: ?
00:01 < wumpus> oh that, yes that's a simple extension to JSON batching that would allow chaining of return values
00:03 < wumpus> don't know whether to propose it or not, I'm fairly sure their reply will be 'if you need this level of sophistication don't use JSON-RPC you noob'
00:03 < sipa> who is they?
00:03 < wumpus> the people who made the JSON RPC standard
00:04 < dcousens> I think if the RTT time is more significant than the encoding of the data itself, and you want to optimize RPC, its very likely you have control over the node anyway, just write a small HTTP wrapper that does that over localhost for you/
00:05 < dcousens> or hell... write a RPC command that does what you want
00:05 < sipa> hah, yes
00:05 < sipa> that's my approach usually :)
00:05  * sipa zZzZ
00:05 < dcousens> as is mine :S
00:05 < wumpus> the point is that we don't want the API clogged full of 'chain A and B' commands
00:06 < wumpus> but for a local patch sure
00:06 < wumpus> in the end  I think no one really has any convincing use-cases for this
00:06 < dcousens> yup, we're all just lazy cause it means 1 more line
00:07 < jonasschnelli> I think the RPC layer is for app to app communication
00:07 < wumpus> I've had approximately zero replies on me JSON-RPC extension proposal, though I think it makes a lot of sense *if* people are seriously considering this
00:07 < jonasschnelli> The Qt console is supposed to be a human command line interface
00:07 -!- OdicforceSounds [~i00nsu@gw.vpn.autistici.org] has joined #bitcoin-core-dev
00:07 < wumpus> yes, the RPC layer is for app to app communication, it is an API
00:07 < jonasschnelli> The convenience of nested commands are probably on the client side
00:08 < dcousens> wumpus: I'm against the idea,  just wasn't sure if the Qt change (#7783) was relevant
00:08 < wumpus> dcousens: huh?
00:08 < wumpus> no, qt has nothing to do with it
00:08 < wumpus> that' just a user convenience
00:08 < dcousens> indeed, hence ACK :)
00:09 < wumpus> I mean with bitcoin-cli you have full access to bash' scripting/variable munging/etc capabilities, in the Qt console you don't, so this adds a bit of shell power to it
00:09 < sipa> wumpus: oh, i had no idea that that chaining value idea was your proposal
00:09 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev
00:10 < gmaxwell> or the rpc console could just link in a lua/python/js engine, all of which are embedable.
00:10 < wumpus> this is  a completely orthogonal concern from being able to chain values at the server side to avoid latency
00:10 < wumpus> gmaxwell: :-(
00:10 < gmaxwell> heh
00:10 < wumpus> no interpreters in bitcoin please
00:11 < wumpus> (apart from the one we really need)
00:11 < dcousens> no more* 
00:11 < wumpus> having a powerful interpreter in the target executable makes exploitation so much easier
00:12 < dcousens> maybe the CLI could just have an interactive mode with a LUA shell or something?
00:12 < gmaxwell> well it could be a seperate interface, e.g. fancy-console.
00:12 -!- OdicforceSounds [~i00nsu@gw.vpn.autistici.org] has quit [K-Lined]
00:12 < dcousens> that way its not in the core as such
00:12 < wumpus> dcousens: yes, that has been proposed, we could jut have a python-based interactive CLI
00:12 < gmaxwell> I've only heard of five or six instances where the Js enable ethereum wallet stuff was used to trick people into sending away all their funds. :P
00:12 < dcousens> bitcoin-cli*, that is
00:12 < wumpus> dcousens: it could be based on ncurses, ipython, etc, that idea is old as the hills, yet no one wrote one :)
00:12 < gmaxwell> but yes, not having it in the main binary would be obvious. I dunno, I think the utility is all that great.
00:12 < wumpus> I thnk the current tools are jut ok
00:12 < dcousens> wumpus: but jonasschnelli wrote this :P
00:13 < wumpus> gmaxwell: right, it just doesn't matter that much, people like talking about this but it's no itch to scratch
00:13 < wumpus> dcousens: yes, he did, and it works
00:13 < wumpus> it's awesome
00:13 < dcousens> haha,indeed
00:13 < wumpus> let's not try to shed-paint it to death
00:14 < gmaxwell> the standard python bitcoin json library that people get linked to is not at all reliable (gets disconnected and then throws exceptions, and has to be wrapped to be usable) and I don't see anyone even complaining about it.
00:14 < wumpus> s/json/json-rpc   and you're right
00:15 < dcousens> I've found it much easier to just always use a well-tested rpc library than use something "bitcoin tailored"
00:15 < wumpus> which one are you using for your projects?
00:15 < gmaxwell> json-rpc, yes.
00:15 < wumpus> are there any RPC mechanisms that don't suck?
00:16 < dcousens> wumpus: myself? as most of my work is in JS, I ended up using my own (haha) simply because all the batch interfaces sucked with error handling for well tested ones
00:16 < wumpus> this presentation talks about people using MQTT for bitcoin wallet control, among other things:  https://media.defcon.org/DEF%20CON%2024/DEF%20CON%2024%20presentations/DEFCON-24-Lucas-Lundgren-Light-Weight%20Protocol-Critical-Implications.pdf   of course, without authentication or encryption and on the public internet :)
00:17 < wumpus> tl.dr: don't do that
00:17 < luke-jr> [06:53:12] <jonasschnelli> We could either have a special RPC command that result in parsing and executing multiple nested commands…but I don't think this would be clever. <-- this would be useful if the RPC client was over a netwrok, to avoid round-trips and such
00:17 < dcousens> but, my point was, even my own implementation has nothing to do bitcoin as such, its just an RPC implementation
00:17 < jonasschnelli> Luke-Jr: Yes. The server-side nesting could save bandwidth... 
00:18 < luke-jr> FWIW, I both dislike and like the idea at the same time. >_<
00:18 < gmaxwell> wumpus: What did we do in the embeded python json-rpc used in the tests to make it reliable? (or did we not and the test just run fast enough that it isn't an issue?)
00:18 < wumpus> server-side promise pipelining aves some bandwidth, but it mostly saves *latency*
00:18 < jonasschnelli> Example: with RPC nesting, you could get the first outputs value of the second transactions of the bestblock with just one command ---> bandwith: a couple of bytes:
00:19 < jonasschnelli> s/:/.
00:19 < luke-jr> it's easier to support server-side expressions when bitcoind is split from the consensus stuff someday
00:19 < wumpus> gmaxwell: which issue do you exactly mean?
00:19 < luke-jr> ("support" in a human manner, not technical)
00:20 < wumpus> gmaxwell: we did add some code to AuthServiceProxy._request to handle connection loss
00:21 < luke-jr> I think there's some RPC mechanism which does expressions already BTW
00:21 < wumpus> luke-jr: yes, it's old as the hills, "promise pipelining" is usually what it's called
00:21 < wumpus> luke-jr: capnproto does it for example
00:22 < wumpus> I think even CORBA could do it in the 90's, but don't look for that, it'll turn you crazy
00:22 < wumpus> XCB (X11's RPC protocol) can do it too
00:22 < gmaxwell> wumpus: varrious forms of connection loss; bitcoind either times out the persistant connection then any other interaction with the proxy object throws an exception, or I believe any case where bitcoind returns an error. I don't have a detailed list because I've always just soloved it by creating a wrapper that catches the exception and reconnects.
00:23 < wumpus> gmaxwell: the high-level problem is that AuthServiceProxy uses python's http mechanism in an unconventional way: it opens a connection to a HTTP server, and instead of immediately queuing a bunch of requests, it keeps the connection open
00:23 < wumpus> gmaxwell: which in principle is fine, web browsers also do that, but it needs code to handle the case where the remote server hung up on you
00:24 < wumpus> gmaxwell: stock AuthServiceProxy has no code for that, our version (in the tests) does
00:24 < luke-jr> it used to :x
00:25 < wumpus> no, it assumes a unwordly friendly RPC server that never disconnects. Which used to be the case, approximately, before the switch to evhttpd, which introduced (like any other HTTP server in the world) connection timeouts 
00:25 < wumpus> (but network problems can *also* result in the http connection being closed, you just can't make the assumption it will always be there in the real world)
00:26 < dcousens> wumpus: fwiw, I occassionally sync an address index from genesis just to see how fast it goes,  and its never the throughput/bandwidth that slows it up,  its the disk thrashing,  even in just a query-of txindex case
00:26 < dcousens> s/address index/script index
00:27 < gmaxwell> wumpus: yea, it was unreliable before-- just more obvious now.
00:27 < wumpus> dcousens: thanks for actually benchmarking to find bottlenecks instead of making assumptions :) ("it must be RPC overhead")
00:27 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]
00:27 < luke-jr> oh, I see what it was: the older version that I thought worked simply never reused the connection :|
00:28 < wumpus> luke-jr: that's also a valid way to do it, if you don't have too many requests or theyr're sparse
00:28 < wumpus> it's how people usually use python's http: just open a connection per requests. The whole keep-alive thing is an optimization, not required
00:28 < wumpus> it brings a lot of state and complexity
00:29 < luke-jr> yet another unmaintained jgarzik project: https://github.com/jgarzik/python-bitcoinrpc/pull/49
00:29 < gmaxwell> though without it, I imagine performance is poor (well even with it, performance is poor)
00:30 < gmaxwell> it stinks mostly because everywhere recommends it, and it falls flat on its face... and I'm not sure what to recommend instead.
00:30 < wumpus> well "performance is poor" is relative. keep-alive only helps with repeated requests. In many cases of using RPC you don't really care about performance of repeated reuqests at all
00:31 < wumpus> many people just use the RPC through curl, or bitcoin-cli, which involves executing an external process per connection per command, and they don't complain either
00:32 < dcousens> wumpus: heh, I'm using 16 concurrent RPC connections w/ 300 batched in each
00:32 < wumpus> I think the problem is recommending using a broken-ish) library when the underlying mechanism is so trivial
00:33 < dcousens> needless to say I found where my custom RPC commands were missing LOCKs pretty quick
00:33 < gmaxwell> right, but "walk through the last N blocks to gather data" taking longer in python than it takes me to modify bitcoind and recompile feels a little silly.
00:34 < wumpus> yes, if you're one of the few people that needs to do really dense requesting, there are various optimizations that help
00:34 < wumpus> but that's not what JSON RPC was designed for in the first place
00:34 < wumpus> it's a high-overhead protocol that was designed to be simple to use, not for low-latency high-throughput application
00:34 < dcousens> wumpus: my point was, the RPC isn't whats slow, so no point changing it
00:35 < wumpus> something like capnproto is designed for the latter
00:35 < wumpus> howeer it's much harder to use, bind, and have basic setup, which is why companie generally offer JSON RPC or REST APIs
00:35 < dcousens> lest we forget SOAP
00:35 < wumpus> heh :)
00:36 < gmaxwell> author of capnproto didn't seem to regard sending uninitilized memory in struct padding to remote peers as a serious security problem when I spoke to him a year or two ago.
00:37 < wumpus> yes, security is another thing that is usually compromised on when latency is the most important thing
00:37 < gmaxwell> in any case, after seeing that the python stuff was slow I tested with curl and it didn't appear to be the bitcoind side that was slow.
00:37 < wumpus> it's a difficult choice, I think JSON-RPC was a fairly good choice as these things go
00:37 < gmaxwell> I agree.
00:38  * jonasschnelli thinks we should fork to use CORBA as our bitcoin scripting language and SOAP as http API :}
00:39 < luke-jr> ._.
00:39 -!- dermoth [~thomas@24.114.97.129] has quit [Read error: Connection reset by peer]
00:39 < luke-jr> jonasschnelli: you forgot /s
00:39 < jonasschnelli> Ah... I forgot to migrate the Qt client to a chrome html/css extension. :)
00:39 < wumpus> the network and JSON processing on the bitcoind side is fast: the most common bottleneck would be the locking, which has nothing to do with the RPC mechanism. Or reading/deserializing blocks. Or...
00:40 < wumpus> jonasschnelli: hehe, maybe if bitcoin was designed 10 years earlier
00:40 < dcousens> jonasschnelli: I wonder when a ECDSA library will be written with pure CSS
00:40 < jonasschnelli> lol
00:40 < wumpus> dcousens: at least you can write a ECDSA library with just x86 mov instructions
00:40 < luke-jr> >_<
00:40 < luke-jr> https://github.com/xoreaxeaxeax/movfuscator
00:40 < wumpus> yea
00:41 < luke-jr> no need to write a new one, just build libsecp256k1..
00:41 < jonasschnelli> How large will it be?
00:41 < wumpus> moon-sized
00:42 < luke-jr> dunno, never tried it
00:42 < jonasschnelli> Would be fun open the moon-sized library in IDA-PRO
00:43 < wumpus> yes I think that's the only reason why anyone would do something like that, throw off people trying to analyze it 'this can't be real x86 code'
00:44 < luke-jr> s/people/software/
00:44 < luke-jr> eg virus scanners
00:44 < wumpus> well not just software, software is much easier to throw off
00:45 < luke-jr> is it? ☺
00:45 < dcousens> jonasschnelli: its possible to de-movuscate,isn't it? in which case eh?
00:45 < luke-jr> dcousens: IIRC this one intentionally makes it hard
00:46 -!- PatBoy [xyz@192.99.249.194] has quit [Ping timeout: 255 seconds]
00:48 < wumpus> then again if the virus is 1000MB it kind of inhibits its own spread
00:49 -!- PatBoy [xyz@192.99.249.194] has joined #bitcoin-core-dev
00:54 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev
01:00 -!- laurentmt [~Thunderbi@80.215.178.31] has joined #bitcoin-core-dev
01:02 -!- laurentmt [~Thunderbi@80.215.178.31] has quit [Client Quit]
01:03 -!- dermoth [~thomas@dsl-216-221-58-231.mtl.aei.ca] has joined #bitcoin-core-dev
01:11 -!- dermoth [~thomas@dsl-216-221-58-231.mtl.aei.ca] has quit [Ping timeout: 265 seconds]
01:13 -!- dermoth [~thomas@dsl-66-36-139-211.mtl.aei.ca] has joined #bitcoin-core-dev
01:15 -!- dermoth [~thomas@dsl-66-36-139-211.mtl.aei.ca] has quit [Disconnected by services]
01:16 < GitHub179> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/57b34599b2de...881d7eaf29f7
01:16 < GitHub179> bitcoin/master 36fa01f Cory Fields: net: only delete CConnman if it's been created...
01:16 < GitHub179> bitcoin/master 881d7ea Wladimir J. van der Laan: Merge #8715: net: only delete CConnman if it's been created...
01:17 < GitHub0> [bitcoin] laanwj closed pull request #8715: net: only delete CConnman if it's been created (master...fix-connman-shutdown) https://github.com/bitcoin/bitcoin/pull/8715
01:18 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Ping timeout: 250 seconds]
01:30 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
01:50 -!- dermoth [~thomas@dsl-66-36-156-88.mtl.aei.ca] has joined #bitcoin-core-dev
01:51 -!- dermoth [~thomas@dsl-66-36-156-88.mtl.aei.ca] has quit [Client Quit]
01:56 -!- AaronvanW [~ewout@77pc231.sshunet.nl] has joined #bitcoin-core-dev
01:56 -!- AaronvanW [~ewout@77pc231.sshunet.nl] has quit [Changing host]
01:56 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:57 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lxvsqyxtivzarjmx] has joined #bitcoin-core-dev
02:01 -!- dermoth [~thomas@dsl-66-36-156-88.mtl.aei.ca] has joined #bitcoin-core-dev
02:02 < jonasschnelli> Is there a reason why the last key in out HD scheme (and in BIP32) is non-hardened? Its m/0'/0'/0 for the first key and not m/0'/0'/0'
02:02 < jonasschnelli> Or does it just don't matter at the last level
02:24 < gmaxwell> because the wallet itself isn't intended to iterate at that level. The part below is subkeys.
02:24 < gmaxwell> So every key the wallet gives out is strong against unzipping, but it could support repeated payment arrangements without address reuse.
02:24 < gmaxwell> IIRC.
02:28 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has left #bitcoin-core-dev []
02:34 -!- netzin [~netsin@unaffiliated/jiggalator] has joined #bitcoin-core-dev
02:36 -!- netzin [~netsin@unaffiliated/jiggalator] has quit [Client Quit]
02:40 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev
02:56 < MarcoFalke> wumpus: Can you elaborate? (random.random() *is* deterministic)
02:56 < MarcoFalke> I think the seed is the current time, so we may not know that
02:56 < MarcoFalke> But knowing the seed is not required.
02:56 < wumpus> MarcoFalke: I like test that simply test the same thing every time
02:56 < wumpus> there is no need to randomize here
02:56 < MarcoFalke> So just set it to usehd=0
02:56 < wumpus> just make every odd bitcoind a legacy wallet and every even one a HD one, or so
02:57 < wumpus> I just don't see the point of random() here, there's a fair chance that it ends up testing all-hd or all-non-hd
03:01 < MarcoFalke> Which is a legit case to test
03:01 < MarcoFalke> But I can remove it, so we don't need the import random
03:01 < wumpus> sure, but not randomly
03:02 < wumpus> I like deterministic tests, esp in travis
03:02 < MarcoFalke> But you want them to be constant?
03:02 < wumpus> yes
03:03 < MarcoFalke> Have you seen the print(extra_args) to make it reproducible in case of failure?
03:03 < wumpus> otherwise there's a larger chance it will fail due to reasons unrelated to the code changes
03:03 < wumpus> which confuses people
03:03 -!- rubensayshi [~ruben@82.201.93.169] has quit [Read error: Connection reset by peer]
03:04 < wumpus> tests run in travis should preferably be constant and deterministic. I'm ok with a random fuzzing jackpot testing method for running locally, but the tests running for every pull should be the same tests every time
03:07 < wumpus> if you want to test with a combination of legacy and HD wallets in a test that's good, but just hardcode that
03:09 < MarcoFalke> fine
03:09 < MarcoFalke> Then we should write some new tests which do "parameter fuzzing" some time
03:10 < MarcoFalke> Sadly this depends somewhat on rewrinting the arg parser
03:10 < wumpus> sorry that I feel so strongly about htis, but I've seen too many random travis failures in the last months :)
03:15 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
03:15 -!- fengling [~fengling@58.135.95.136] has quit [Client Quit]
03:37 -!- laurentmt [~Thunderbi@80.215.178.31] has joined #bitcoin-core-dev
03:38 -!- laurentmt [~Thunderbi@80.215.178.31] has quit [Client Quit]
03:55 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has left #bitcoin-core-dev ["Verlassend"]
03:58 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
03:59 < wumpus> cfields_: oh shit oh shit oh shit https://github.com/bitcoin/bitcoin/pull/8653#issuecomment-246973266
04:00 < wumpus> bitcoin core win64 cross-build is in a state of crap with ubuntu 16.04
04:01 < wumpus> I thought I did this before, and didn't have any of these issues, but I must hae imagined it
04:02 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 276 seconds]
04:06 < GitHub17> [bitcoin] andersoyvind opened pull request #8720: Minor change in section name (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8720
04:39 -!- JackH [~Jack@79-73-191-94.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
04:44 -!- cryptapus [~cryptapus@87.254.202.248] has joined #bitcoin-core-dev
04:44 -!- cryptapus [~cryptapus@87.254.202.248] has quit [Changing host]
04:44 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:13 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
05:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:35 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
06:00 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev
06:12 < GitHub88> [bitcoin] laanwj opened pull request #8722: bitcoin-cli: More detailed error reporting (master...2016_09_cli_http_error) https://github.com/bitcoin/bitcoin/pull/8722
06:22 < GitHub10> [bitcoin] jonasschnelli opened pull request #8723: [Wallet] Add support for flexible BIP32/HD keypath-scheme (master...2016/09/hd_flex) https://github.com/bitcoin/bitcoin/pull/8723
06:22  * jonasschnelli thinks he should review Luke-Jr multiwallet PR
06:23 < wumpus> jonasschnelli: whatevery you do don't look at #8653
06:24 < jonasschnelli> wumpus: hehe.. I did already and started disable --hardening wherever I can to avoid "possible startup problems". :P
06:25 < wumpus> my new favourite number is "zu"
06:26 < jonasschnelli> :-)
06:26 < wumpus> I think it's that posix mode of gcc that completely throws everything off track
06:26 < wumpus> (on windows)
06:27 < wumpus> I'm going to locally revert the usage of c++11 threads, compile with the -win32 compiler then see what happens, I think everything will be fine
06:27 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
06:27 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has quit [Changing host]
06:27 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
06:29 -!- cryptapus [~cryptapus@66.119.84.15] has joined #bitcoin-core-dev
06:29 -!- cryptapus [~cryptapus@66.119.84.15] has quit [Changing host]
06:29 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
06:29 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Read error: Connection reset by peer]
06:32 < jonasschnelli> wumpus: Not sure if this helps.. but in another project I'm using mingw.thread.h (https://github.com/digitalbitbox/dbb-app/blob/master/src/mingw/mingw.thread.h)
06:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
06:33 < jonasschnelli> Then just include it with a #ifdef WIN32
06:33 < jonasschnelli> Probably a huge hack
06:34 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev
06:36 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
06:49 < wumpus> jonasschnelli: that makes sense; but I don't get it, why isn't it part of mingw-w64 itself?
06:50 < wumpus> well it's less of a hack than fully fledged POSIX emulation mode on windows
06:54 < wumpus> it's supposed to just support it, and on trusty it doe
06:54 < wumpus> (it=std::mutex and friends)
06:56 < jonasschnelli> wumpus: Yes. I don't know why its not part of mingw itself... I just added them and it worked fine, though, I'm not using stuff like the --enable-hardening we do at Core
06:56 < wumpus> I doubt this has anything to do with hardening, I think with hardening it just detects the crazy memory corruption that happens sooner
06:57 < GitHub93> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/881d7eaf29f7...a82e5d8220bb
06:57 < GitHub93> bitcoin/master 1111ddb MarcoFalke: gitignore: Remove unused lines
06:57 < GitHub93> bitcoin/master a82e5d8 MarcoFalke: Merge #8714: [qa] gitignore: Remove unused lines...
06:58 < GitHub7> [bitcoin] MarcoFalke closed pull request #8714: [qa] gitignore: Remove unused lines (master...Mf1609-qaUnused) https://github.com/bitcoin/bitcoin/pull/8714
06:58 < wumpus> also there's a mutex header in ./lib/gcc/x86_64-w64-mingw32/5.3-win32/include/c++/mutex
06:58 < wumpus> maybe we need to #define something
06:58 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
06:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:00 < wumpus> well at least that's one more 'trivial' I've removed from a pull title
07:02 < jonasschnelli> heh.. yes. That happens quick..
07:05 < MarcoFalke> Hmm. Github allows us to write to branches that have a pull request open against bitcoin.
07:05 < MarcoFalke> c.f. https://github.com/bitcoin/bitcoin/pull/8720/commits
07:05 < MarcoFalke> Might come in handy but I'd prefer to disable it
07:05 < MarcoFalke> (if possible)
07:08 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has joined #bitcoin-core-dev
07:08 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:09 < jonasschnelli> MarcoFalke: so you did amend commit force push to 8720?
07:09 < MarcoFalke> Jup: https://github.com/blog/2247-improving-collaboration-with-forks
07:09 < MarcoFalke> Apparently not possible to disable
07:09 < jonasschnelli> Heh... that's handy but evil.
07:10 -!- AaronvanW_ [~ewout@77pc231.sshunet.nl] has joined #bitcoin-core-dev
07:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
07:14 -!- AaronvanW [~ewout@185pc230.sshunet.nl] has quit [Ping timeout: 260 seconds]
07:15 -!- AaronvanW__ [~ewout@185pc230.sshunet.nl] has joined #bitcoin-core-dev
07:18 -!- AaronvanW_ [~ewout@77pc231.sshunet.nl] has quit [Ping timeout: 260 seconds]
07:20 < wumpus> that can be really useful
07:21 < wumpus> was of course already possible to do that locally, but ok
07:21 < jonasschnelli> Yes. Thinking of all there cases where a nit holds back a PR
07:21 < jonasschnelli> I think its much better to have a more public way then locally alter during the merge
07:22 < wumpus> before the merge*
07:24 < wumpus> if you do a local merge you can simply add your own commits before doing it, that's pretty public
07:24 < jonasschnelli> It's public, but only in the commit list and not on the PR
07:25 < wumpus> right. Just wanted to be clear I didn't mean anything as sneaky as squashing it into the merge commit, or into the author's commits
07:25 < MarcoFalke> Also quite fiddly trying to emulate github-merge.py
07:25 < MarcoFalke> I think it is fine to use the new feature when we announce in in the pr that is affected
07:25 < wumpus> yes I've always intended to add a local mode to github-merge.py
07:25 < wumpus> (I have a local version of github-merge but it's really messy)
07:33 < GitHub197> [bitcoin] MarcoFalke opened pull request #8724: [qa] walletbackup: Sync blocks inside the loop (master...Mf1609-qaWalletBackupFix) https://github.com/bitcoin/bitcoin/pull/8724
07:39 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
07:55 < jonasschnelli> windows_hell, nice branch name
07:56  * jonasschnelli wishes we could include a ubuntu vm and the linux binaries for the windows package
07:56 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:57 < wumpus> well there seems to be a shitload of issues, for now the best recommendation would be to just use trusty. The "zu" issue doesn't exist with the gitian executables does it?
07:58 < wumpus> let's first try to figure out why the tests crash...
08:01 -!- AaronvanW__ is now known as AaronvanW
08:01 < jonasschnelli> Yes. We should probably flag certain distros not compatible with out cross compile process or so
08:08 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
08:16 < wumpus> it only seemed like bitcoin-qt was working: I had disabled wallet support, apparently it works then
08:16 < wumpus> windows is truly a mess on gcc 5.3
08:16 < wumpus> the test crash before it even get to the BasicTestingSetup constructor
08:17 < wumpus> at least I can reproduce it on wine....
08:18 < achow101> Is this windows problem the same thing as I was having a while back?
08:21 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:31 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
08:34 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:41 < wumpus> there are at least three seperate issues here
08:42 < achow101> the thing with mutex and not compiling
08:42 < wumpus> 1) the std::mutex/thread c++11 compilation issue 2) something trange with libevent (the 'zu' issue) 3)  something with hardening
08:43 < wumpus> some of these may partially overlap in cause or effect
08:43 < wumpus> but it's a mess
08:45 < achow101> Yeah, it looks like the same problem, it happened on ubuntu 15.10 (wily)
08:47 < achow101> This is the discussion if it's of any help: https://botbot.me/freenode/bitcoin-core-dev/2016-08-08/?msg=70975840&page=1
08:48 < wumpus> right - it's still an issue on 16.04
08:50 -!- dermoth [~thomas@dsl-66-36-156-88.mtl.aei.ca] has quit [Remote host closed the connection]
08:51 -!- achow101 [~achow101@129-2-207-18.student.umd.edu] has quit [Quit: Leaving]
08:52 -!- achow101 [~achow101@129-2-207-18.student.umd.edu] has joined #bitcoin-core-dev
08:57 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
09:00 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 240 seconds]
09:01 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has left #bitcoin-core-dev []
09:07 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
09:11 < wumpus> ok, phew, at least verified that the libevent `zu` issue doesn't exist in the released 0.13.0 executables
09:15 < sipa> good
09:16 < wumpus> well travis RPC tests pass on windows, so it'd be surprising, but I don't understand why it suddenly starts happening with a certain gcc version
09:16 < wumpus> the libevent version didn't change since 0.13.0, neither did our use of it
09:20 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Gotta Go Fast! TM]
09:23 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
09:28 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 240 seconds]
09:32 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
09:32 < wumpus> achow101: which patches? I've also been testing w/ Ubuntu 16.04 and windows 10
09:37 -!- neha [~narula@tbilisi.csail.mit.edu] has quit [Ping timeout: 250 seconds]
09:39 -!- neha [~narula@tbilisi.csail.mit.edu] has joined #bitcoin-core-dev
09:53 < GitHub12> [bitcoin] rebroad opened pull request #8725: Split debug for estimatefee into {estimatefee,2} (master...MoreGranularDebug2) https://github.com/bitcoin/bitcoin/pull/8725
09:53 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
09:56 < GitHub174> [bitcoin] rebroad opened pull request #8726: Move a bunch of fairly verbose debug messages from mempool to mempool2 (master...MoreGranularDebug3) https://github.com/bitcoin/bitcoin/pull/8726
09:59 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
10:01 < GitHub66> [bitcoin] rebroad opened pull request #8727: Move logic for TX INVs together (master...MoreGranularDebug4) https://github.com/bitcoin/bitcoin/pull/8727
10:05 < GitHub85> [bitcoin] rebroad opened pull request #8728: More granular debug5 (master...MoreGranularDebug5) https://github.com/bitcoin/bitcoin/pull/8728
10:18 < GitHub29> [bitcoin] rebroad opened pull request #8729: More granular debug6 (master...MoreGranularDebug6) https://github.com/bitcoin/bitcoin/pull/8729
10:31 -!- dermoth [~thomas@dsl-66-36-156-88.mtl.aei.ca] has joined #bitcoin-core-dev
10:32 -!- rebroad [~rebroad@node-122g.pool-118-173.dynamic.totbb.net] has joined #bitcoin-core-dev
10:34 < GitHub64> [bitcoin] laanwj opened pull request #8730: depends: Add libevent compatibility patch for windows (master...2016_09_libevent_windows_gcc_531) https://github.com/bitcoin/bitcoin/pull/8730
10:35 < wumpus> sheesh how many debug pulls do we need...
10:36 < paveljanik> 8(
10:37 < paveljanik> 6+1. The last one combines all prev 8)
10:37 < wumpus> we really should add a suggestion not to spam pull requests
10:39 < wumpus> especially if they're all related
10:48 < paveljanik> well, I know how he feels. Sometimes you know it is much easier to make it in steps. But doing steps separately and then all in one PR is nonsense...
10:49 < paveljanik> let's close the steps PR and comment only the final one.
10:49 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
10:50 < paveljanik> rebroad, is it ok for you?
10:56 < rebroad> paveljanik, hi
10:57 < rebroad> paveljanik, I find the whole process quite confusing... in my experience my smaller pull requests get merged but the larger ones don't... so this way I'm trying to hedge my bets and provide small ones and a larger one to work out which is preferred.
10:58 < rebroad> paveljanik, not sure what you mean by "the final one"
10:58 < paveljanik> the final one - the one containing all (almost) the previous
10:58 < rebroad> do you mean the one with all the commits in? and close the others?
10:58 < cfields_> wumpus: ok, diving into the win32 mess. I'd written it off as user error, but looks like I need to familiarize myself with what's going on now.
10:58 < paveljanik> 8729
10:58 < rebroad> paveljanik, I'm happy to do this, but I'm not sure if this is would the other devs would prefer also
10:59 < paveljanik> well, some changes are wrong, yes, but they can tell you in one PR.
10:59 < rebroad> paveljanik, wrong?
11:00 < paveljanik> yes
11:00 < paveljanik> lets wait for comments
11:00 < paveljanik> I have already added approx. 5 comments.
11:00 < rebroad> paveljanik, ah, thank you
11:01 < GitHub154> [bitcoin] rebroad opened pull request #8731: Debug headers received ("block" for new block announcement, "block2" … (master...DebugHeadersReceived) https://github.com/bitcoin/bitcoin/pull/8731
11:01 < rebroad> paveljanik, is there a way to easily go to my pull requests that have had comments left? i.e. is there an inbox for these comments somewhere on github?
11:02 < paveljanik> rebroad, yes, please read https://help.github.com/articles/about-discussions-in-issues-and-pull-requests/
11:02 < rebroad> thanks
11:03 < paveljanik> and especially "Further reading"
11:04 < rebroad> paveljanik, what did you mean by "why?" in #8728?
11:07 < paveljanik> expanded there...
11:08 < rebroad> paveljanik, #8727 you asked what other inv.type I can see.. not sure why you are asking this
11:09 < rebroad> I just moved the code that was doing the same thing as the code above into the same if statement.. which is needed to avoid messier code with the later commits also
11:11 < wumpus> this is starting to be annoying, please stop pushing debug pull requests
11:11 < rebroad> paveljanik, #8725 have added a description now... I guess the "why" is a reasonable question given it was absent.
11:12 < wumpus> most debugging information is only intersting for yourself during a debugging session, there is no reason to merge them upstream
11:12 < rebroad> wumpus, what is your issue with debug pull requests?
11:12 < paveljanik> there are many of them and useless - wumpus wrote it above...
11:12 < wumpus> a) there are way too many already b) it's mostly ego-commits, not intersting to other people
11:13 < rebroad> wumpus, from the pull requests I have seen I would say that various developers have found a number of my debug pull requests useful, and they facilitate better understanding of what is happening. It would be unreasonable to expect everyone to have to make their own changed to obtain useful debug information.
11:13 < wumpus> try to be focused when you submit pulls upsteam. Every one of us likely has tons of patches adding personal debugging information to solve specific problems, but it's not in general useful for others and you're wasting review time
11:14 < wumpus> it wouldn't be a problem if this was one or two pulls, but you keep pushing this on
11:15 < rebroad> wumpus, i just spend 3 days having to rebase all these debug commits due to changes that were made recently.. I am getting very very fed up with the amount of time wasted rebasing when I could be spending that time adding functionality to bitcoin. this is why this needs to get merged!
11:15 < wumpus> do you really expect people to review "more granular debug6"?
11:15 < rebroad> i have a life, which I'd like to spend living rather than rebasing 
11:15 < wumpus> that's not a reason to merge it though, to merge it it needs to actually be considered useful, the project doesn't exist to save you work
11:15 < wumpus> we all have a life
11:15 < wumpus> it's kind of insulting to suggest you're the only one
11:16 < paveljanik> so why do you spend your time with useless stuff instead of The functionality?
11:16 < wumpus> and you can just burden us with your shit
11:16 < rebroad> wumpus, it's not just saving me work. I wouldn't write it if I thought it was only useful for me
11:16 < rebroad> i agree that some of the commits are trivial...
11:16 < rebroad> wumpus, what do you mean by "ego-commits"?
11:16 < wumpus> well some of them may be useful to others
11:16 < wumpus> but it's the sheer volume
11:17 < wumpus> everyone tries to make time to write and review patches that add functionality and fix bugs
11:17 < wumpus> not just debugging spam
11:17 < wumpus> <paveljanik> so why do you spend your time with useless stuff instead of The functionality? <- very good question
11:18 < wumpus> we have 402 issues and 140 pull requests open at this moment
11:18 < paveljanik> yup, pick one of the issues and try to solve it!
11:18 < wumpus> lots of actual problems that need to be solved, that are experienced by users
11:18 < rebroad> wumpus, you say sheer volume, but I'm not sure what you mean. do you mean pull reqs, or lines of code?
11:18 < wumpus> and yes, some of them may be bullshit, but let's try not to add too much more
11:19 < wumpus> rebroad: number of pull requests inthis case
11:19 < wumpus> (same could hold for lines of changed code, in some cases)
11:20 < rebroad> wumpus, ok, I will close the smaller ones as paveljanik suggests 
11:20 < wumpus> yes just merge some together if they are related to the same concern
11:20 < wumpus> and at least make some effort to name/describe them
11:21 < wumpus> 'more granular debug5' really sucks as name
11:21 < GitHub9> [bitcoin] rebroad closed pull request #8484: More granular debug (master...MoreGranularDebug) https://github.com/bitcoin/bitcoin/pull/8484
11:21 < rebroad> wumpus, you don't mince your words, do you :)
11:21 < wumpus> rebroad: sorry this has been annoying me for a while
11:22 < rebroad> spending 3 days rebasing has been annoying me too ...
11:22 < wumpus> well then don
11:22 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
11:22 < wumpus> 't
11:22 < rebroad> if i need to understand the code and how it functions I do... unless these commits get merged
11:22 < rebroad> ok, I am oversimplifying a little
11:23 < rebroad> but it all helps, IMHO
11:23 < wumpus> you can understand code without logging everything, or by adding temporary logging
11:23 < wumpus> or by stepping through with a debugger
11:23 < wumpus> many ways taht don't involve adding logging statements to the upstream code
11:23 < rebroad> part of me needs to disagree with you as otherwise I've spent a lot of time for very little reason :-s
11:24 < wumpus> I'm not saying it's all useless
11:24 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 240 seconds]
11:24 -!- Guyver2_ is now known as Guyver2
11:24 < rebroad> there are some more commits yet to come that might help to reveal the usefulness of the so far seemingly useless ones
11:24 < wumpus> just try to have some discipline, spend time explaining to others why something is useful, instead of just adding pulls with very little description
11:26 < rebroad> but yes, the mempool2 and estimatefee2 ones were a bit trivial... estimatefee2 more so... but still useful to an extent...  I'd still like to know what you mean by ego-commits... i do wonder how much ego is behind my struggle to get things merged.
11:26 < wumpus> and maybe explain the overall plan, people get lost if they only see details instead of where something is going
11:26 < rebroad> wumpus, you are right.. i do need to be less lazy when it comes to explaining
11:27 < rebroad> wumpus, thank you for your feedback and patience
11:27 < wumpus> an ego-commit is something that is useful to yourself, for example some feature that you need, or some piece of information that you specifically need, but without regard whether it's useful for other users
11:28 < rebroad> wumpus, I would find it hard to believe that some features are useful to only one person
11:28 < wumpus> and then to stop having to rebase it yourself you try to push it upstream
11:29 < wumpus> well it tends to happen if something is only a perceived need, someone is really held up about something
11:29 < rebroad> there seems to be a general attitude among many developers that "debug" commits are a waste of time.. I don't quite understand why that is the popular viewpoint
11:29 < wumpus> maybe it's useful to one other person :) but all code needs to be maintained, so there has to be some threashold
11:29 < wumpus> well debugging is something kind of personal to developers
11:29 < wumpus> what information do you need
11:29 < wumpus> for what you're doing
11:30 < wumpus> for the problem you're trying to find
11:30 < rebroad> a lot of people, non-developers especially often ask for more feedback on what their full-node is doing... they want to see what it is doing... 
11:30 < rebroad> so in a sense, this debug info might benefit non-developers more than developers
11:30 < wumpus> e.g. to find a wine issue I"m now instrumenting some code to log every executed instruction
11:30 < wumpus> that's not something anyone would ever want upstream :-)
11:31 < rebroad> i could code something prettier like a matrix style green scrolly thing.. but that would move away from actual useful information then!
11:31 < wumpus> if I became really obsessed about this, and wanted this a default part of bitcoin, and became angry if other developers disagreed, that would be an ego commit
11:32 < wumpus> yes on a high level I agree with you, it'd be nice to have some more insight into what a node is doing
11:32 < wumpus> I kind of like statoshi's approach
11:33 < wumpus> but I'm not sure e.g. splitting up debug into a zillion categories, or adding lots of messages, is the way to go
11:33 < wumpus> haha if you'd add that to the GUI it may well be accepted
11:33 < rebroad> if it's granular enough, then no one should need to add adhoc debug message as you are suggesting... there'd be a debug message already there that they can activate just by editing bitcoin.conf
11:33 < wumpus> jonasschnelli did a screensaver-like thing once that showed statistics
11:33 < rebroad> and they'd not need to recompile etc
11:33 < rebroad> which wastes a lot of cpy, energy, etc...
11:33 < rebroad> cpu
11:34 < wumpus> but gave up on it unfortuantely
11:34 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/5896
11:34 < rebroad> :)
11:34 < jonasschnelli> I haven't gave it up... I just came with a more stable solution for a first start
11:34 < jonasschnelli> The mempool stats
11:34 < rebroad> I love the mempool graphs..
11:34 < jonasschnelli> Once this will be merged, more can be added
11:34 < jonasschnelli> Nodes / Tx / Mempool just don't fit in one screem
11:34 < rebroad> although it would be great if I could point to the graph and it would tell me the X-Y co-ords of the point closest to the pointer
11:34 < kanzure> not clear to me if rebroad has used gdb and code stepping
11:35 < wumpus> well i think there's always someone that wants to add an ad-hoc debug messgae, I don't think it's possible to be complete in that regard
11:35 < kanzure> if there needs to be metrics for user display then probably a more general frmaewokr would be useful, rather than individual debugger additions
11:35 < rebroad> kanzure, i have used gdb.. but i think it's of limited use, in my experience and not as clear as some good debug messages, imho
11:36 < wumpus> the linux kernel has something called 'tracepoints' which allows inserting print or other hooks at certain points to print information on the fly
11:36 < wumpus> I think a similar thing exists for user space
11:36 < kanzure> wumpus: probably there's a very noisy compiler option for this...
11:36 < wumpus> most annoying about gdb is <value optimized out>
11:37 < GitHub167> [bitcoin] rebroad closed pull request #8728: More granular debug5 (master...MoreGranularDebug5) https://github.com/bitcoin/bitcoin/pull/8728
11:38 < kanzure> -finstrument-functions
11:38 < kanzure> hehehe
11:39 < wumpus> another one is systemtap probe points
11:39 < GitHub28> [bitcoin] rebroad closed pull request #8725: Split debug for estimatefee into {estimatefee,2} (master...MoreGranularDebug2) https://github.com/bitcoin/bitcoin/pull/8725
11:40 < GitHub62> [bitcoin] rebroad closed pull request #8726: Move a bunch of fairly verbose debug messages from mempool to mempool2 (master...MoreGranularDebug3) https://github.com/bitcoin/bitcoin/pull/8726
11:40 < kanzure> cool.
11:40 < GitHub25> [bitcoin] rebroad closed pull request #8727: Move logic for TX INVs together (master...MoreGranularDebug4) https://github.com/bitcoin/bitcoin/pull/8727
11:41 < wumpus> or gdb's "The dynamic printf command dprintf combines a breakpoint with formatted printing of your program's data to give you the effect of inserting printf calls into your program on-the-fly, without having to recompile it."
11:41 < rebroad> someone on github mentioned that everytime i change the pull title, or close/open that 1200 emails get sent... is this true?
11:41 < achow101> rebroad: yes.
11:41 < wumpus> well I think 1200 is kind of overstating it
11:42 < rebroad> if so.... this sounds a little verbose... i agree with paveljanik's comment that things can be concise to one person while verbose to another
11:42 < rebroad> which is why I felt more granular was the answer..
11:42 < kanzure> it's the same thing with mailing lists too. your email will be sent to many thousands of people.
11:42 < wumpus> but at least the maintainers and people that have posted to an issue get a notification
11:42 < achow101> wumpus: I don't think it is actually overstating it. Anyone who watches the repo will get an email and there are 1206 watchers
11:42 < kanzure> and if everyone is reading their email then a 5 minute email ~= economic catastrophe of time spent reading
11:43 < wumpus> achow101: I'm not sure watchers get a mail for everything that happens in a repostiory, but you could be right
11:43 < kanzure> wumpus: are you a watcher?
11:44 < achow101> I'm watching and I get mails for every comment and commit to every pr or issue
11:44 < kanzure> i sort of assumed all the regulars were using the watchers feature.
11:44 < kanzure> ah maybe it's something about org members on github. nevermind.
11:44 < wumpus> kanzure: I'm repo owner, so I get a lot of mail from github, but I didn't realize watchers get all that too
11:44 < rebroad> paveljanik, was it you who sent me a github article earlier on here? i am struggling to find the link you quoted earlier :-s
11:45 < paveljanik> rebroad, see topic, it contains a link to log of this channel...
11:45 < kanzure> you want https://help.github.com/articles/about-discussions-in-issues-and-pull-requests/
11:45 < wumpus> I don't amange to read most of it though
11:45 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
11:45 < wumpus> still looking for a way to filter when someone @'s me from the rest of the github spam
11:46 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 240 seconds]
11:46 -!- Guyver2_ is now known as Guyver2
11:46 < kanzure> wumpus: i think github is supposed to do that on its homepage, but IIRC nobody ever views the github homepage :)
11:46 < achow101> Does anyone think that the pull request review feature on github might be useful?
11:47 < wumpus> really those should end up in my personal mailbox instead of with the bulk
11:47 < wumpus> achow101: haven't looked at it yet
11:47 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev
11:47 -!- achow101_ [~achow101@206.196.187.157] has joined #bitcoin-core-dev
11:48 < achow101> part of it looks like basically preventing PRs from merging without ACKs and ACKs are built in
11:48 < paveljanik> wumpus, github mails contain this weird CC: ... Comment <comment@noreply.github.com> or Mention or ...
11:48 < wumpus> ok that sounds fairly useful
11:48 < kanzure> achow101: are those ACKs tied to specific commit ids?
11:48 < achow101> Dunno, haven't fully checked it out yet. I just read over the help article they linked
11:49 < wumpus> paveljanik: that could be key
11:53 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
11:53 -!- achow101_ [~achow101@206.196.187.157] has quit [Ping timeout: 250 seconds]
11:55 < wumpus> paveljanik: yes, searching for to:mention@noreply.github.com seems to do what I want
11:55 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev
12:00 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2]
12:00 < GitHub131> [bitcoin] rebroad opened pull request #8733: More granular debug [WIP] (master...MoreGranularDebug.wip) https://github.com/bitcoin/bitcoin/pull/8733
12:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
12:00 < rebroad> this is the version with 22 commit.... hopefuly if anyone can be bothered to look they can get a clearer idea of where it was all going..
12:00 -!- achow101_ [~achow101@206.196.185.22] has joined #bitcoin-core-dev
12:03 < wumpus> much better
12:13 < GitHub147> [bitcoin] MarcoFalke closed pull request #8731: Debug headers received ("block" for new block announcement, "block2" … (master...DebugHeadersReceived) https://github.com/bitcoin/bitcoin/pull/8731
12:19 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Gotta Go Fast! TM]
12:21 < btcdrak> wow, what is this new "review" thing on Github
12:21 -!- BunBun [~BunBun@32.97.110.56] has joined #bitcoin-core-dev
12:22 < BunBun> quit
12:22 -!- BunBun [~BunBun@32.97.110.56] has quit [Client Quit]
12:27 -!- achow101_ [~achow101@206.196.185.22] has quit [Ping timeout: 244 seconds]
12:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
12:31 -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Ping timeout: 240 seconds]
12:40 < GitHub198> [bitcoin] rebroad closed pull request #8596: [WIP] Feeler code and debugging. (master...FeelerFixes) https://github.com/bitcoin/bitcoin/pull/8596
12:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
12:51 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]
12:51 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev
12:51 -!- drizztbsd is now known as timothy
13:00 -!- achow101_ [~achow101@129-2-207-18.student.umd.edu] has joined #bitcoin-core-dev
13:00 -!- achow101_ [~achow101@129-2-207-18.student.umd.edu] has quit [Client Quit]
13:07 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
13:23 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]
13:25 < cfields_> wumpus: ok, i've finally had enough of the system package crap that we can't control. I'm adding native toolchains to depends, along with a BOOTSTRAP option, false by default. Bootstrapping can be done in gitian and uploaded, so that they're simply fetched 99% of the time.
13:29 < sipa> cfields_: so gcc being part of the build for all platforms?
13:30 < cfields_> sipa: that's what I'm considering, yes
13:31 < sipa> awesome.
13:32 < cfields_> I'm sure it'll spiral downward with arguments about where to stop, but gcc/binutils seems like a reasonable start.
13:33 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
13:33 < sipa> cfields_: do you know nixos?
13:34 < cfields_> sipa: not really
13:34 < cfields_> sipa: looks interesting. Is it intended to be deterministic across builders?
13:35 < sipa> it is not
13:35 < sipa> but it uses hashes of build instructions to identify packages
13:36 < cfields_> ah, nice. sounds familiar :)
13:36 < MarcoFalke> Isn't this what docker does?
13:37 < sipa> docker builds from source?
13:40 < cfields_> docker just does whatever you tell it to. but yes, i'd assume it uses the hash of the recipe for checkpointing
13:50 < luke-jr> btcdrak: paveljanik: where do you see the new review thing⁇
13:50 < btcdrak> luke-jr: look on the diff tab
13:51 < luke-jr> cfields_: we need to support building outside gitian anyway, so not sure I see the point
13:51 < btcdrak> luke-jr: "the files changed" tab.
13:52 < luke-jr> huh
13:52 < luke-jr> interesting
13:58 < MarcoFalke> luke-jr: I think the goal is to solve the cross compile issues with depends.
14:00 < MarcoFalke> So if you fetch the (gitian-built) toolchain, you can just build outside gitian like you do today
14:22 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
14:35 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:29 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
15:40 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
15:55 -!- achow101_ [~achow101@206.196.187.157] has joined #bitcoin-core-dev
16:02 -!- wjx [~quassel@123.120.20.66] has joined #bitcoin-core-dev
16:21 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has quit [Quit: MarcoFalke]
16:21 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
16:22 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
16:49 -!- afk11 [~afk11@79.97.105.226] has joined #bitcoin-core-dev
16:49 -!- afk11 [~afk11@79.97.105.226] has quit [Changing host]
16:49 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
16:59 -!- achow101_ [~achow101@206.196.187.157] has quit [Ping timeout: 250 seconds]
17:10 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
17:11 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
17:18 -!- PatBoy [xyz@192.99.249.194] has quit [Ping timeout: 250 seconds]
17:20 -!- PatBoy [xyz@192.99.249.194] has joined #bitcoin-core-dev
17:28 -!- achow101_ [~achow101@206.196.187.157] has joined #bitcoin-core-dev
17:28 -!- achow101_ [~achow101@206.196.187.157] has quit [Client Quit]
17:48 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev
17:57 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-uuiottdcbxbvfyyh] has quit [Quit: Connection closed for inactivity]
17:58 < achow101> I'm experimenting with the review thing. Can someone go to https://github.com/achow101/ProtectedBranchTest/pull/3 and submit an "Approve" review?
17:59 < sdaftuar> achow101: done
18:00 < achow101> thanks. something's not working...
18:00 < sdaftuar> yeah i saw :)
18:01 < sdaftuar> does it need to be approved by someone with write privs maybe?
18:01 < achow101> I don't know. I can't approve it since I wrote it. I'll try with the other account.
18:03 < achow101> oh yeah. That was totally it.
18:06 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lxvsqyxtivzarjmx] has quit [Quit: Connection closed for inactivity]
18:08 < achow101> Interesting that the status checks are still pending.
18:11 -!- Magma [~magma@magma.tokyo] has joined #bitcoin-core-dev
18:15 -!- nibor [~nibor@185.9.34.66] has quit [Read error: Connection reset by peer]
18:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
18:40 < rebroad> is the -dropmessagestest code still needed in main.cpp? It's not even mentioned as a command line option in init.cpp
18:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
18:41 < rebroad> oh... sorry, it is
18:46 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 250 seconds]
18:58 < rebroad> ok, so I am wondering... develoeprs seem to complain when I either raise too many pull requests or raise a pull request with too many changes.. so it seems the complain is about the amount of development I am doing, so my thnking is that this is implying I should be working on other thnigs, code review perhaps? In what areas is it that the complaint might be indication that I am not contributing enough?
19:00 < achow101> I've mostly figured out how the review thing works, and it could benefit us.
19:00 < achow101> So comments through the review thing are just general comments on the whole thing, kind of useless. You can still do line notes though and that is good
19:01 < achow101> approving cannot be done commit by commit but rather by the full diff at the time of review.
19:04 < achow101> requesting changes seems like it will revoke a previous approval
19:04 < dcousens> achow101: you can't edit comments interestingly when posting an 'approval'
19:05 < achow101> And lastly branches can be setup with protections to require an approve from a committer, pass status checks (travis), and prevent administrators from merging regardless
19:05 < achow101> also the submitter can't approve or request changes in his own PR (duh)
19:06 < GitHub54> [bitcoin] rebroad opened pull request #8734: Send NOTFOUND when we don't have the block data. (master...NotfoundIfPruned) https://github.com/bitcoin/bitcoin/pull/8734
19:07 < achow101> dcousens: right. so any comments done with the review thing can't be edited
19:07 < rebroad> achow101, all sounds good!
19:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
19:08 -!- dermoth [~thomas@dsl-66-36-156-88.mtl.aei.ca] has quit [Quit: Ex-Chat]
19:09 < achow101> I think the best thing about this is that it can be set so that a PR submitted by a committer must have another committer review it before it can be merged
19:09 < achow101> just in case someone gets hacked
19:11 < dcousens> achow101: eh,  they already have multiple processes in place... trusting github further isn't really necessary
19:12 < dcousens> achow101: RE privileges to approve, you don't need any see https://github.com/bitcoin/bitcoin/pull/8723#pullrequestreview-82853
19:13 < dcousens> I honestly don't see this being any better than the current ACK' system
19:15 < achow101> anyone can approve, but only certain people's approvals (the committers) will allow a PR to be merged when the branch is protected
19:16 < achow101> If you look at the one I linked earlier, you can see the message there about an "approved review" which apparantly must come from someone with write access
19:38 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
19:39 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
19:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
20:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
20:14 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:26 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:46 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]
20:51 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:51 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 265 seconds]
20:51 -!- Soligor [~Soligor@unaffiliated/soligor] has quit [Ping timeout: 250 seconds]
20:52 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:55 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
21:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:03 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:15 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:16 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:37 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]
21:37 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev
21:37 -!- drizztbsd is now known as timothy
22:02 -!- rebroad [~rebroad@node-122g.pool-118-173.dynamic.totbb.net] has quit [Ping timeout: 265 seconds]
22:18 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wmccdywsmlpiopbp] has joined #bitcoin-core-dev
22:28 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev
22:42 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]
22:42 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev
22:43 -!- drizztbsd is now known as timothy
22:50 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:51 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:00 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev
23:00 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services]
23:00 -!- drizztbsd is now known as timothy
23:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
23:22 < jonasschnelli> I guess thats also a new Githup thing: you can later change the base branch of a pull request
23:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
23:31 -!- rebroad [~rebroad@183.89.24.190] has joined #bitcoin-core-dev
23:33 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds]
23:41 -!- rebroad_ [~rebroad@183.89.38.148] has joined #bitcoin-core-dev
23:44 -!- rebroad [~rebroad@183.89.24.190] has quit [Ping timeout: 248 seconds]
23:48 < cfields_> wumpus: wip mingw toolchain: https://github.com/theuni/bitcoin/commit/6cc40455c96f8820a35f745fb03466bcdc8d9919
23:49 < cfields_> wumpus: lots of work remains. But, mingw depends build fully, and bitcoin build breaks with the same threading problems that have been reported, so it's enough to help with testing/debugging.
23:50 < cfields_> will continue with it tomorrow.
23:51 < jonasschnelli> nice cfields_ !
23:51 < cfields_> jonasschnelli: heh, not really. It's at the "it's a bloodbath, but it builds" stage of development :)
23:54 -!- lahwran [~lahwran@python/site-packages/lahwran] has joined #bitcoin-core-dev