--- Day changed Thu Feb 02 2017 00:04 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 00:26 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:55 < bitcoin-git> [bitcoin] laanwj closed pull request #9658: Add clang_format.py to help automate code style analysis (master...PR-clang-format) https://github.com/bitcoin/bitcoin/pull/9658 00:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:00 < bitcoin-git> [bitcoin] laanwj closed pull request #9632: Add clang_static_analysis.py to help automate static analysis runs (master...PR-clang-static) https://github.com/bitcoin/bitcoin/pull/9632 01:06 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 01:13 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/77bd8c4cab67...e30d9287fd48 01:13 < bitcoin-git> bitcoin/master 3eba88d Gregory Sanders: clarify listunspent amount description 01:13 < bitcoin-git> bitcoin/master e30d928 Wladimir J. van der Laan: Merge #9663: [RPC] clarify listunspent amount description... 01:14 < bitcoin-git> [bitcoin] laanwj closed pull request #9663: [RPC] clarify listunspent amount description (master...listoutput) https://github.com/bitcoin/bitcoin/pull/9663 01:17 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 01:19 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e30d9287fd48...ae972a5e996a 01:19 < bitcoin-git> bitcoin/master b9d95bd Douglas Roark: Fix various minor linearization script issues... 01:19 < bitcoin-git> bitcoin/master ae972a5 Wladimir J. van der Laan: Merge #9580: Fix various minor linearization script issues... 01:19 < bitcoin-git> [bitcoin] laanwj closed pull request #9580: Fix various minor linearization script issues (master...linearizefix) https://github.com/bitcoin/bitcoin/pull/9580 01:43 -!- rabidus_ is now known as rabidus 01:43 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 02:00 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 255 seconds] 02:32 -!- harrymm [~wayne@191.96.49.105] has quit [Ping timeout: 255 seconds] 02:47 -!- harrymm [~wayne@104.207.83.35] has joined #bitcoin-core-dev 02:58 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ae972a5e996a...4e19efba0331 02:58 < bitcoin-git> bitcoin/master 8fc6989 practicalswift: Remove redundant semicolons 02:58 < bitcoin-git> bitcoin/master 4e19efb Wladimir J. van der Laan: Merge #9556: Remove redundant semicolons... 02:58 < bitcoin-git> [bitcoin] laanwj closed pull request #9556: Remove redundant semicolons (master...remove-redundant-braces) https://github.com/bitcoin/bitcoin/pull/9556 03:41 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 04:05 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/4e19efba0331...7c93952feccb 04:05 < bitcoin-git> bitcoin/master 3e900ac Matt Corallo: Require merge commits merge branches on top of other merge commits... 04:05 < bitcoin-git> bitcoin/master ba94426 Matt Corallo: Test that pushes to bitcoin/bitcoin are signed per verify-commits 04:05 < bitcoin-git> bitcoin/master 7c93952 Wladimir J. van der Laan: Merge #9656: Check verify-commits on pushes to master... 04:05 < bitcoin-git> [bitcoin] laanwj closed pull request #9656: Check verify-commits on pushes to master (master...2017-01-fix-verify-commits) https://github.com/bitcoin/bitcoin/pull/9656 04:14 < bitcoin-git> [bitcoin] laanwj opened pull request #9670: contrib: github-merge improvements (master...2017_01_ghmerge_update) https://github.com/bitcoin/bitcoin/pull/9670 04:24 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 04:24 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 04:26 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7c93952feccb...1c2edd9f6707 04:26 < bitcoin-git> bitcoin/master 178454d Jorge Timón: Contrib: Add jtimon pgp keys for commit sigs and future gitian builds 04:26 < bitcoin-git> bitcoin/master 1c2edd9 Wladimir J. van der Laan: Merge #9654: Add jtimon pgp keys for commit sigs and future gitian builds... 04:26 < bitcoin-git> [bitcoin] laanwj closed pull request #9654: Add jtimon pgp keys for commit sigs and future gitian builds (master...jtimon-key-gpg) https://github.com/bitcoin/bitcoin/pull/9654 05:08 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke] 05:16 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 256 seconds] 05:36 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 05:37 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 05:38 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 06:01 -!- isle2983 [~isle2983@gateway/vpn/privateinternetaccess/isle2983] has joined #bitcoin-core-dev 06:27 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 06:27 < BlueMatt> #9650 (and, by extension, #9634) are probably 0.14 06:27 < gribble> https://github.com/bitcoin/bitcoin/issues/9650 | Better handle invalid parameters to signrawtransaction by TheBlueMatt · Pull Request #9650 · bitcoin/bitcoin · GitHub 06:28 < gribble> https://github.com/bitcoin/bitcoin/issues/9634 | Fail in DecodeHexTx if there is extra data at the end by jtimon · Pull Request #9634 · bitcoin/bitcoin · GitHub 06:28 < BlueMatt> (ie need tag) 06:28 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-core-dev 06:29 < wumpus> tagged 06:29 < BlueMatt> thanks 06:29 < wumpus> 9634 seems ready, it would be nice if it had a test though - this seems like something that could regress early if it's not caught by the tests 06:53 -!- jtimon [~quassel@245.30.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 07:06 < wumpus> it doesn't necessarily need to hold up the pull request, but there's not been a reply from the author yet 07:11 -!- handlex [~handlex@189.74.9.113] has joined #bitcoin-core-dev 07:34 -!- handlex [~handlex@189.74.9.113] has quit [Quit: handlex] 07:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 07:47 -!- handlex [~handlex@189.74.9.113] has joined #bitcoin-core-dev 07:47 -!- handlex [~handlex@189.74.9.113] has quit [Client Quit] 07:52 -!- handlex [~handlex@189.74.9.113] has joined #bitcoin-core-dev 08:02 -!- handlex [~handlex@189.74.9.113] has quit [Quit: handlex] 08:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:07 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 08:07 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 08:34 < BlueMatt> wumpus: I'll take a look at doing that in a bit 08:35 -!- waxwing [~waxwing@62.205.214.125] has quit [Ping timeout: 240 seconds] 08:35 < BlueMatt> question, would anyone object to me trying to add something like https://github.com/TheBlueMatt/RelayNode/blob/next/c%2B%2B/preinclude.h to bitcoin? it makes atomics replaceable with either std::atomic or a custom thing which has valgrind annotations so that helgrind/drd actually work and dont spew spurious crap all the time 08:36 < BlueMatt> means atomics get declared with DECLARE_ATOMIC instead of std::atomic x, though 08:36 < BlueMatt> well, suppose they could be OUR_ATOMIC_OR_NOT, but either way 08:37 < sipa> why use macros? 08:37 < BlueMatt> because otherwise you override std::atomic? 08:37 < BlueMatt> i mean you can say all atomics are now of type MACRO_ATOMIC_TYPE 08:38 < sipa> no, if you're going to switch all places where atomocs are used to macros, why not switch them with a self defined class directly 08:38 < sipa> and when you don't need the self defined type, have it be typedefed to be std::atomic 08:39 < BlueMatt> yea, well same thing either way 08:42 < BlueMatt> also, due to the presence of _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE, that file would need to be included everywhere prior to the inclusion of any std includes 08:42 < BlueMatt> well, the atomics could be in a separate file 08:42 < BlueMatt> but... 08:48 -!- waxwing [waxwing@gateway/vpn/mullvad/x-xobbegqrfmokflbk] has joined #bitcoin-core-dev 08:50 -!- abpa [~abpa@2602:306:b837:dbf0:2d95:eb62:1ebc:2019] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 09:06 -!- handlex [~handlex@189.74.9.113] has joined #bitcoin-core-dev 09:07 -!- handlex [~handlex@189.74.9.113] has quit [Client Quit] 09:16 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 258 seconds] 09:17 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev 09:27 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 09:37 < isle2983> please don't talk about coding style at the meeting 09:38 < isle2983> I have some automation pieces coming togeher, but it might take a little while to get it done 09:38 < wumpus> BlueMatt: wouldn't it be possible to do this with std::atomic? I like the move towards using standard primitives instead of self-defined ttpes 09:38 < isle2983> I am working near-full-time on this in the short term 09:39 < isle2983> a viable end objective might be a 'Nit Bot' that can analize the commits from a PR and detect a few categories of things 09:39 < isle2983> it looks like you can load a github acct auth token into the TravisCI account as an env var 09:39 < isle2983> so, securely the travisCI script can post content back to github 09:40 < wumpus> are you sure that's worth spending so much work on? there are some much more pressing issues than code style 09:41 < wumpus> we've considered using that but the TravisCI token stuff is easy to circumvent if it's used for testing pulls - the test script for the pull could just output the token or upload it somewhere 09:43 < isle2983> I am not sure it is the ultimate thing, but there is a cost to the project - you spent 20 minutes talking about it last week 09:43 < isle2983> and there is some annoyance at trivial pulls 09:43 < wumpus> that's a rarity, usually it doesn't come up at all 09:43 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 09:44 < isle2983> if it can be automated, it should be automated at some point 09:45 < isle2983> I am also of the school that says code is written once, and read 100s of times afterwards, so make reading easy 09:45 < isle2983> probably 100,000s of times afterwards for bitcoin 09:45 < wumpus> BlueMatt: in general the more 'you need to use this special type' rules a project has, the harder it is to contribute to. Though making it easier to valgrind/helgrind is certainly a valuable goal. 09:46 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 09:49 < wumpus> isle2983: all too true, but I don't think most of the (superficial) code style makes much difference to that. Having a sensible design and the logic and the reason for things documented/commented is what is important to understanding difficult code 09:54 < isle2983> totally agreed, but I see that as all the more reason to filter out distractions so that attention can focus 100% on the important things 09:54 < wumpus> focusing too much on moving around spaces and such takes away the focus from what really matters, and it's much easier so it easily crowds out deeper thinking 09:55 < wumpus> well as I see it a 'style nit bot' would add distractions, not remove them 09:57 < gmaxwell> talking about pointless stuff is good for community. :) 09:57 < wumpus> unless it annoys people 09:58 < isle2983> in the short term, perhaps. but in the long term it would train submitters to get the PR right offline. Using common tools and scripts also lets the coders just integrate it into their text editor so they don't have to think. 09:59 < wumpus> there's two ways to go at this sanely: one is to use something like clang-format from the begining. For example in golang projects everyone uses the same formatter with the same style, preventing any disagreements about style. The other is to do best effort and just not worry too much about it. It's too late for the former. 09:59 < wumpus> our goal is not to 'train submitters' 10:00 < wumpus> it's just importing concerns that shouldn't be part of this, creating extra bureaucratic barriers 10:01 < BlueMatt> wumpus: yea, I tend to agree, I'm not sure I really want to do it, but if valgrind doesnt get an update to actually support std::atomic I might have to do it 10:03 < gmaxwell> wumpus: I wouldn't worry too much; thats what review is for.. and that is the kind of thing everyone will spot, no one should mind fixing up, especially since it would be visible in practice all over... Obviously preferable to not. 10:05 < wumpus> gmaxwell: I do worry about it. We've had this problem in the past with a certain person commenting on every pull about e.g. sorting include headers, whitespace, and so on, and it was incredibly annoying 10:07 < gmaxwell> ah, I was commenting more on the macro for atomics. 10:07 < gmaxwell> Yes. It certantly doesn't work if everyeone doesn't support it, especially if its merely cosmetic. 10:08 < wumpus> right, I'm not worried about using a custom type for std::atomic, it shouldn't be used that much anyway. THough it seems to be something a tool should just handle. 10:08 < gmaxwell> but "make valgrind usable to help us find data-races" is a substantial boon I hope we could all support. :) 10:09 < wumpus> sure 10:10 < wumpus> though it seems reasonably important to have it work for std::atomic so that the tool can analyse all projects using it, without needing special support at that side 10:13 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 10:18 < cfields> wumpus: i wonder if that one, specifically, gets solved with newer versions of std libraries. For ex, iirc newer libc++ adds attributes to std::mutex/std::lock, etc, so that we won't need the wrappers in threadsafety.h 10:18 < isle2983> I am happy to talk more about style automation on side channels - or also hear suggestions for what else I could be working on. I am in the learning phase and am open to anything that needs an extra brain and can help the project. Yielding now for important topics. Thanks. 10:19 -!- Evel-Laptop [~Evel-Knie@46.25.71.147] has joined #bitcoin-core-dev 10:20 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 10:21 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 276 seconds] 10:22 < wumpus> isle2983: to be clear I'm not trying to bash your work, just trying to set expectation how these kind of things are received, so you don't spend a lot of work automating something that won't be used 10:23 < wumpus> cfields: indeed it could also be improved from the side of the library 10:24 < cfields> yes, found it: https://reviews.llvm.org/D14731 10:24 < cfields> i guess runtime tools wouldn't get access to those attributes, though 10:25 < wumpus> they could if it would be exposed in debug metadata in some way 10:26 < wumpus> isle2983: as for things to be working on, improving the tests is always very welcome :) 10:28 < Chris_Stewart_5> isle2983: If you are interested, I'm working on a new testing paradigm in core in #8469 10:28 < gribble> https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub 10:29 < Chris_Stewart_5> I've found it to be a useful way to get familiar with the core codebase as well 10:30 < Chris_Stewart_5> wrt to what wumpus said about improving/adding tests 10:30 < isle2983> wumpus: hey no worries. I wouldn't want to work on a project that didn't have strong skepticism and pushback 10:31 < isle2983> Chris_Stewart_5: cool, I will take a peek. Thanks. 10:34 < sipa> BlueMatt: are relaxed reads from an atomic even recognizable from the binary? 10:34 < BlueMatt> relaxed I dont know, but certainly most reads/writes show up in the st as load()/store() 10:35 < BlueMatt> its unclear to me whether helgrind is just being overly conservative and reporting them anyway because they could still be logic-races, or whether helgrind also isnt taking into account the ordering there 10:36 < BlueMatt> its also unclear to me whether libc++ is doing the right thing with _GLIBCXX_SYNCHRONIZATION_HAPPENS_BEFORE set in their atomics and I just dont have that mapped to helgrind's equivalent 10:36 < BlueMatt> which may be an easy fix 10:36 < BlueMatt> (but that hadnt previously fixed it months ago when I was doing that for the relay network code) 10:37 -!- handlex [~handlex@189.74.9.113] has joined #bitcoin-core-dev 10:38 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 276 seconds] 10:38 -!- handlex [~handlex@189.74.9.113] has quit [Client Quit] 10:46 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 10:48 -!- GAit [~GAit@unaffiliated/gait] has joined #bitcoin-core-dev 10:55 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9671: Fix super-unlikely race introduced in 236618061a445d2cb11e72 (master...2017-02-fix-initnode-race) https://github.com/bitcoin/bitcoin/pull/9671 10:55 < BlueMatt> cfields: I blame you for ^, btw, you asked me to do it :p 10:59 < cfields> BlueMatt: In my defense I'm pretty sure i only said that it was ugly and that it should be cleaned up later, but I didn't complain when you went ahead and moved it either. So I'll take the blame :) 10:59 -!- MarcoFalke [~marco@host191-2.natpool.mwn.de] has joined #bitcoin-core-dev 10:59 < BlueMatt> lol, yea, well /someone/ should have bothered to look at the implications :( 11:00 < wumpus> #startmeeting 11:00 < lightningbot> Meeting started Thu Feb 2 19:00:02 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:00 < jonasschnelli> hi 11:00 < BlueMatt> oh thats today? 11:00 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier 11:00 < sipa> yow. 11:00 < luke-jr> BlueMatt: no, it's fake news. 11:00 < wumpus> BlueMatt: it's thursday I hope? 11:00 < luke-jr> /s 11:00 < sipa> luke-jr: alternative news 11:00 < BlueMatt> wumpus: alternative facts 11:00 < BlueMatt> heh 11:00 < sipa> jinx 11:01 < sipa> i don't have topics 11:01 < wumpus> foremost topic would be what to still include in 0.14, as rc1 release is planned for monday 11:02 < gmaxwell> I propose not including any bugs. 11:02 < BlueMatt> I think the current list (+#9671) are going to be required for release, sooooo 11:02 < gribble> https://github.com/bitcoin/bitcoin/issues/9671 | Fix super-unlikely race introduced in 236618061a445d2cb11e72 by TheBlueMatt · Pull Request #9671 · bitcoin/bitcoin · GitHub 11:02 < jonasschnelli> These are the issues tagged for 0.14 : https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.14.0 11:02 < MarcoFalke> I think only remaining is the net stuff? 11:03 < cfields> rebasing 9609 now. 11:03 < instagibbs> hi 11:03 < BlueMatt> MarcoFalke: we added the signrawtransaction assertion too 11:03 < wumpus> do we have a fix for #9027 in the works yet? 11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9027 | Unbounded reorg memory usage · Issue #9027 · bitcoin/bitcoin · GitHub 11:03 < jonasschnelli> Imo the importmulti fixes can be done after 0.14 11:03 < BlueMatt> and importmulti 11:03 < cfields> probably a good time to call for release notes additions 11:03 < BlueMatt> wumpus: I vote we push that one 11:03 < BlueMatt> (to 0.15) 11:03 < wumpus> BlueMatt: ok, no problem with that 11:03 < BlueMatt> because not-regression, it turns out 11:04 < sipa> not regression? 11:04 < BlueMatt> slightly worse than it tused to be, but not so massively so that I think we definitely need to fix it asap 11:04 < gmaxwell> changing the API in the very next release would be unfortunate. 11:04 < achow101> are the three rpc things necessary for this release? 11:04 < BlueMatt> gmaxwell: context? 11:04 < BlueMatt> sipa: you're the one who decided it wasnt! 11:04 < jonasschnelli> gmaxwell: importmulti? 11:04 < sipa> gmaxwell: fixing 9027 does not need an api change afaik 11:04 < sipa> BlueMatt: oh! 11:05 < wumpus> we could disable importmulti if it isn't safe in time for the release 11:05 < sipa> or leave it undocumented? 11:05 < wumpus> depends on whether the issue of #9491 is serious enough 11:05 < gribble> https://github.com/bitcoin/bitcoin/issues/9491 | Importmulti api is confusing in a way that could lead to funds loss. · Issue #9491 · bitcoin/bitcoin · GitHub 11:05 < gmaxwell> fixing the fact that it's very easy to fail to rescan anything, when you thought it was... does. 11:06 < wumpus> yes undocumented or could add a "warning: experimental, API will likely change next release" in any case too 11:06 < jonasschnelli> Or we just fix 9491... seems not very complex? 11:06 < jonasschnelli> Can fix in rc2 if it's to late for monday? 11:07 < wumpus> sure 11:07 < wumpus> but there's no guarantee there is a rc2 11:07 < gmaxwell> okay, lets see where that goes in the next couple days. 11:07 < wumpus> I don't know how hard it is? it seems to have caused quite a discussion but no fix 11:07 < luke-jr> importmulti seems akin to importprivkey which shouldn't be used by users anyway? 11:07 < gmaxwell> We can hide it right before cutting RC1 if nothing else. 11:08 < wumpus> yes 11:08 < gmaxwell> ashame, as it's a nice improvement. 11:08 < sipa> i think the fix would be easy? 11:10 < gmaxwell> sure, that is why I said lets see. 11:10 < BlueMatt> who is working on it? 11:10 < achow101> can't you just change the default timestamp to be 0? 11:10 < gmaxwell> but we have a fallback if it doesn't get fixed. 11:10 < BlueMatt> "lets see" only works if someone does it :p 11:10 < gmaxwell> achow101: then there is no easy way to express now. 11:10 < jonasschnelli> Would a fix where we set the importmulti timestamp to 0 instead of "now" do it for 0.14? 11:10 < luke-jr> gmaxwell: using time() from your OS? 11:10 < jonasschnelli> *default timestamp 11:10 < achow101> -1 for "now" 11:10 < wumpus> or have no default at all and require a time to be specified 11:10 < jonasschnelli> wumpus: +1 11:10 < luke-jr> wumpus: no default at all is nice since it allows a default to be chosen later 11:10 < jonasschnelli> 0 as timestamp is very inefficient. 11:10 < gmaxwell> Lets not hash it out here, there is an issue. 11:10 < jonasschnelli> Okay. Lets comment there. Agree with gmaxwell 11:10 < gmaxwell> I agree with jonasschnelli in the sense there that we really have to stop assuming a full rescan is possible. 11:11 < wumpus> good point, yes 11:11 < jonasschnelli> Is also very inefficient if you have pruned or run hybrid SPV 11:11 < wumpus> it certainly shouldn't be the default 11:11 < gmaxwell> It takes many hours on my normal development system, and is still quite slow even on the fastest hardware available. But avoiding the rescan takes second seat to surprising the user. :) 11:11 < wumpus> it's inefficient and lazy 11:12 < gmaxwell> in my view, except for certan recover operations that are infrequently done-- rescan effectively doesn't work anymore (takes more time than converting your entire usage to a third party api...) 11:13 < wumpus> users of the API should be encouraged to keep track of key birthdates 11:13 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 11:14 < gmaxwell> if we define a new private key format in the not so far future, we should make sure its string clearly integrates a birthdate. :P 11:14 < BlueMatt> ok, so discuss on the issue....next topic? 11:14 < wumpus> a full rescan is indeed only something that should be done for infrequent recovery reasons 11:15 < wumpus> no other topics? 11:16 < MarcoFalke> shortest meeting ever 11:16 < wumpus> I had expected heated debates on what to include last-minute in 0.14 and why to delay the rc, what a disappointment! 11:17 < BlueMatt> great, lets get 0.14 done so I can get back to writing code :) 11:17 < jonasschnelli> Heh. 11:17 < sdaftuar> let's talk about code style again 11:17 < BlueMatt> wumpus: I vote we push it back a month so we can do all the things we wanted to a month ago :p 11:17 < wumpus> BlueMatt: lol! 11:17 < BlueMatt> wait, i had something to talk about re: cde style 11:17 < BlueMatt> hum 11:17 < gmaxwell> BlueMatt: die 11:17 < sdaftuar> i'll get the baseball bat 11:17 < BlueMatt> oh, auto 11:18 < jonasschnelli> Bumpfee: is there a reason why the logic is in the rpcwallet.cpp and not in wallet.cpp? 11:18 < jonasschnelli> Makes it really hard to use in the gui... 11:18 < BlueMatt> jonasschnelli: please move it, agreed 11:18 < luke-jr> jonasschnelli: it can be moved 11:18 < sdaftuar> jonasschnelli: i think we can refactor as needed 11:18 < luke-jr> in 0.15* 11:18 < wumpus> jonasschnelli: because it's only used in rpcwallet.cpp, if you need it in a more general place move it 11:18 < jonasschnelli> Okay. 11:18 < sipa> BlueMatt: i am strongly in favor of auto. 11:18 * sipa hides 11:19 < wumpus> jonasschnelli: although moving everything to wallet.cpp isn't very nice either, we should refactor the wallet code some day 11:19 < luke-jr> I did suggest it earlier, but didn't seem like a blocker for merging 11:19 < wumpus> I'm also in favor of auto 11:19 < BlueMatt> sipa: it makes certain review much, much harder (I often grep for "everywhere X is used") 11:19 < luke-jr> wumpus: well, it's wallet code.. 11:19 < BlueMatt> and have already missed things as a result 11:19 < wumpus> luke-jr: so? not all wallet code needs to be in one file 11:19 < wumpus> forbidding auto is just masochism 11:19 < jonasschnelli> wumpus: yes. Thats a good point. 11:19 < BlueMatt> wumpus: i wasnt voding forbidding it 11:19 < sipa> BlueMatt: introduce an incompatible change to the type, and recompile. tadaa, all places it is used 11:19 < BlueMatt> only carefully considering its use 11:19 < cfields> sipa: same. BlueMatt: maybe paste the thread in question? 11:19 < luke-jr> I like auto when the type is implied by some other type; eg, instead of xyz::value_type 11:20 < jtimon> yeah, but not forbidding it doesn't mean recommending it always either 11:20 < BlueMatt> https://github.com/bitcoin/bitcoin/pull/9609#discussion_r98335218 11:20 < wumpus> we have a whole src/wallet directory which could have tons of different implementation files for different facets of the wallet, instead of stashing it all into one file 11:20 < BlueMatt> (I believe gmaxwell's comment there was intedned for a different line) 11:20 < jonasschnelli> yes. Stuff like coin selection should be more modular 11:21 < wumpus> sure, as with any use of any c++ statement, use of auto should be measured 11:21 < MarcoFalke> Lets do it after priority removal 11:21 < MarcoFalke> Otherwise we step on each others toes 11:21 < wumpus> if you have some specific cases where it's bad to use auto, please document them 11:21 < BlueMatt> wumpus: mostly only things that are /actually/ a mile of text to type, imo 11:21 < sipa> BlueMatt: and not needing to change things all over the place when you turn a tuple into a struct 11:22 < sipa> or add a wrapper 11:22 < BlueMatt> sipa: I have no problem reviewing sed-based changes 11:22 < BlueMatt> in fact prefer that 11:22 < wumpus> BlueMatt: there's plenty of those - c++ is overly verbose, auto is a great advancement 11:22 < sipa> they're still annoying to fo 11:22 < BlueMatt> since I'm gonna go read every single place the change effected anyway 11:22 < BlueMatt> to review 11:22 < sipa> *to do 11:22 < sipa> and of course, let's consider on a case by case basis 11:22 < wumpus> right 11:22 < BlueMatt> wumpus: sure, iterators in iterators, np 11:23 < BlueMatt> yea, ok, whatever, I'll shut up 11:23 < sipa> but in my own preference, that is overwhelmingly the case 11:24 < cfields> well the specific case here is for loops. "for (auto& foo : bar)" 11:24 < MarcoFalke> Agree with BlueMatt, that auto should not be used unless necessary. 11:24 < cfields> any reason not to use auto there? 11:24 < jtimon> BlueMatt: the question is, do you have a general advice on when not to use auto? 11:24 < wumpus> it's never *necessary* auto is just nice 11:24 < BlueMatt> cfields: yes, so I can grep and review if the type's behavior changes in some way 11:24 < BlueMatt> jtimon: personally, if the type really, really doesnt matter 11:24 < luke-jr> cfields: if it's liable to produce bad results with bar changing under it 11:24 < BlueMatt> (which means very rarely use it) 11:24 < jtimon> BlueMatt: I'm afraid "doesn't matter" it's too vague here 11:25 < wumpus> I don't think this is going anywhere, too much isagreement 11:25 < BlueMatt> eg if you're taking an iterator and passing it through to another function 11:25 < wumpus> any other topics? 11:25 < wumpus> BlueMatt: function arguments can't use auto, right? 11:25 < sipa> indeed 11:25 < sipa> c++14 and later introduce some auto types in lambdas 11:25 < BlueMatt> wumpus: correct, but eg doing auto it = map.find(thing); if (it != ma.end()) DoThingWith(*it); 11:25 < BlueMatt> is like not a problem 11:26 < BlueMatt> auto it = map.find(thing); if (it != ma.end()) ILikePonies(it->second.rainbows); I do not like 11:26 < sipa> BlueMatt: how is that different from a for (const auto& x : container) {} 11:27 < BlueMatt> sipa: because in the specific case here the thing in the loop is not defined to take a specific type 11:27 < BlueMatt> it is templated 11:27 < jtimon> my question was, do you have a deductive method for finding the not ok cases instead of an inductive one for the "not a problem cases"? 11:27 < sipa> you can see that as an oblivious loop with iterators, and passing *it to a function that is tje body of the loop 11:27 < BlueMatt> jtimon: jtimon: personally, if the type really, really doesnt matter 11:28 < sipa> i see your point, but i don't think it weighs up against the benefitd 11:28 < sipa> *benefits 11:28 < wumpus> if you're iterating over some container, the type of container usually really doesn't matter, unless you make specific assumptions (but then you'd generally not be using a range for loop in the first place) 11:28 < BlueMatt> wumpus: imo if you are ever actually dereferencing the type you should not use auto 11:28 < sipa> BlueMatt: your own example dereferences... 11:28 < BlueMatt> if you're dereferencing the iterator to eg a pair or just taking the element and passing it to something else, ok 11:29 < BlueMatt> but if you're dereferencing it and accessing something inside it, no 11:29 < sipa> then we might as well not use it at all, i think 11:29 < jtimon> ok, I think I get what you mean by "doesn't matter" now 11:29 < BlueMatt> sipa: there are many places where you might do for (auto& thing: list) ActOn(thing); 11:29 < BlueMatt> thats reasonable 11:30 < sipa> requiring programmers to spell out redundant information just so you can grep for it seems extreme to me 11:30 < gmaxwell> sipa: so functions shouldn't have prototypes? :) 11:30 < BlueMatt> yes, I didnt expect people to agree with me...I have extreme distaste for auto, personally 11:30 < wumpus> yes, that' extreme, and not going tohhappen. Just use smarter tools. 11:30 < BlueMatt> wumpus: suggestions? 11:31 * BlueMatt would love a grep --allusesoftype thing 11:31 < wumpus> it should be fairly easy to implement using clang's parser, would be surprised if it doesn't exist 11:31 < gmaxwell> There is another side to it is that auto enables you to write code that acts on a type while having no idea of the type yourself. Which is safe 99% of the time and deadly the rest. 11:32 < gmaxwell> because in C++ not all operations which are catgorically unsafe on a type are actually stopped by typechecking. :( 11:33 < gmaxwell> I have an auto to a container... and then I extract an auto to an iterator on it and erase things. Is my code guilty of the sin of using an invalidated iterator? It depends on what container was in use, and that was hid by auto... 11:34 < gmaxwell> But... that sort of thing is an edge case, I'd love to see a realistic list of where auto is likely to cause problems, just to keep it in mind. 11:34 < wumpus> right - just keep it in mind while reviewing 11:34 < wumpus> and if there are well-defined cases where auto is dangerous, they should be documented in the developer notes 11:34 < BlueMatt> ehh, ok, well I go read all of wallet half the time reviewing wallet changes, i guess I'll just start doing that for net, too :p 11:35 < BlueMatt> (not a bad thing, that) 11:35 < gmaxwell> unfortunately, auto is most interesting when you have some horrible complex signature. But those are the cases where it is also more of an issue. 11:36 < cfields> gmaxwell: for(auto& : foo) doesn't give you an iterator though, just a reference. So imo that should be highly preferred when possible to avoid your example. 11:36 < wumpus> well no, it's most interesting for bog-standard loops, 99% of the cases. If you're doing anything horribly complex, that's probably where you should be careful 11:36 < jtimon> BlueMatt: we can agree that auto is totally fine for unittests too, right? :p 11:37 < cfields> (preferred over auto foo = bar.begin(), that is) 11:37 < gmaxwell> wumpus: well my point is that stating the type explicitly is just as easy as auto when it's simple and obvious. 11:37 < sipa> gmaxwell: when you have some horrid complex type signature, best practice is to introduce a typedef for it... that also results in succint usage, and lacks the review concerns that BlueMatt has i think 11:37 < jtimon> I agree it removes clarity some times 11:37 < wumpus> gmaxwell: it's *easy* but the point is to avoid unnecessary verbosity/typing, not so you can forget the type 11:37 < BlueMatt> sipa: yes, agreed, also means dont use auto in place, which some people like to do 11:38 < jtimon> but I don't have a clear criterion on when to use it like matt 11:38 < BlueMatt> wumpus: I'm generally 100% in favor of extra verbosity 11:38 < wumpus> e.g. to avoid having to type std::vector for the zillionth time 11:38 < gmaxwell> fking java programmers. :P 11:38 < wumpus> BlueMatt: go use java 11:38 < BlueMatt> extra verbosity generally means less magic, which makes review easier 11:38 < BlueMatt> lol, i expected that.... 11:38 < gmaxwell> (though on type signatures, I usually also prefer being explicit more often) 11:38 < wumpus> BlueMatt: that's not categorically true, more verbosity also means more distraction 11:38 < sipa> agree 11:38 < BlueMatt> wumpus: well, ok, more verbosity as long as it actually provides information 11:39 < sipa> nobody actually looks at what large type definitions contain 11:39 < wumpus> having lot's of boilerplate does *not* equal easier review 11:39 -!- Evel-Laptop [~Evel-Knie@46.25.71.147] has quit [] 11:39 < BlueMatt> public static void main(String[] args) {} probably doesnt provide more information 11:39 < wumpus> anyhow 11:39 < BlueMatt> sipa: I do! 11:39 < wumpus> any other topics? this is going the wrong way 11:39 < sipa> haha 11:39 < luke-jr> lol 11:40 < BlueMatt> soooo...endmeeting? 11:40 < wumpus> #endmeeting 11:40 < lightningbot> Meeting ended Thu Feb 2 19:40:26 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 11:40 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-02-19.00.html 11:40 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-02-19.00.txt 11:40 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-02-02-19.00.log.html 11:40 < gmaxwell> wumpus: your request is a little explicit, you could have just said... for auto meetingstep. 11:41 < BlueMatt> heh 11:41 < wumpus> gmaxwell: #endcurrentcontext 11:42 < jtimon> regarding https://github.com/bitcoin/bitcoin/pull/9609#issuecomment-276974228 I generally dislike habing the release branches differ from the master they branched from more than they need "artificially" 11:43 < jtimon> also for "we can fix that after the branch" types of things 11:44 < MarcoFalke> jtimon: master is for testing, release branches are for production 11:44 < jtimon> MarcoFalke: I know 11:44 < gmaxwell> The asserts don't leve enough record in any case, during development. 11:44 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 11:45 < MarcoFalke> jtimon: The thing is you may want asserts during testing, but you may not want them in production 11:45 < gmaxwell> I've had asserts fire and have had no idea which assert fired or why, only that my daemon went away. So a crash was introduced but we didn't even learn from it. 11:45 < MarcoFalke> jtimon: We can not compile without asserts, so this is the only way? 11:46 < jtimon> MarcoFalke: perhaps something like if(debug) ? 11:46 < gmaxwell> (moreover, differences in behavior between testing and production exposes you to bugs that the testing code fixes) 11:46 < gmaxwell> e.g. when an asserts check has a side effect. 11:47 < gmaxwell> In any case, asserts around the net stuff are also special because the testing there is woefully inadequate right now. 11:48 < gmaxwell> As evidenced by the fact that the version assert was there for months and only triggered a couple times, but yet was still triggerable! 11:48 < jtimon> yeah, I'm talking more generally about the "we can fix that after the branch" or let's do A and master and B in 0.14 attitude 11:48 < luke-jr> #9619 has plenty of ACKs; shall I go add test cases, or merge this and PR test cases separate? 11:48 < gribble> https://github.com/bitcoin/bitcoin/issues/9619 | Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates by luke-jr · Pull Request #9619 · bitcoin/bitcoin · GitHub 11:49 < BlueMatt> I do believe we need to start talking about making our assert infrastructure better - building test bins by default with DEBUG_LOCKORDER and many more asserts, with most of those asserts just printing warnings in production 11:50 < jtimon> yeah, and that doesn't require to have different code, maybe just change the value of a constant or something 11:52 < jtimon> or do all that stuff when -debug 11:52 < bitcoin-git> [bitcoin] isle2983 closed pull request #9459: Improvements to copyright_header.py and some minor copyright header tweaks. (master...PR-copyright-script-improve) https://github.com/bitcoin/bitcoin/pull/9459 11:53 < bitcoin-git> [bitcoin] isle2983 closed pull request #9603: Add basic_style.py to automate some style checking. (master...PR-basic-style) https://github.com/bitcoin/bitcoin/pull/9603 11:53 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 258 seconds] 12:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 12:14 < jtimon> ugh, I missed the change in style... https://github.com/bitcoin/bitcoin/pull/9566#discussion_r98842239 12:15 < jtimon> there's a lot of code of the form 12:15 < jtimon> if (checkwhatever) 12:15 < jtimon> return false/error(...)/state.DoS(...) 12:15 < jtimon> that's no suddenly against our style... 12:15 < jtimon> s/that's no/that's now/ 12:16 < sipa> jtimon: indeed. my preference is that anytime you're touching code (except simple move-onlys), you adapt the style of the code 12:16 < sipa> but no big refactors changing the style all over 12:17 < jtimon> right, my point is I would prefer that our rules for style was something that we're actually closer to achieve, even if that's something less strict 12:19 < jtimon> this is an invitation for someone to create a PR correcting some of those cases 12:21 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 12:22 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:27 < isle2983> it seems strange to me that the style is a moving target. is there some nuance that I am missing? 12:28 < isle2983> I would think that one of the off-the-shelf choices would be best. 12:28 < sipa> isle2983: the original satoshi code used a very arcane style, which many people dislike, and has in practice not been followed by contributors after satoshi left 12:29 < sipa> at some point we formalized the effective style people were using in the developer notes, but reviewers didn't actually enforce it 12:29 < sipa> plus, there was a strong "mimick the style around what you're editing" tendency, which doesn't really help converging 12:29 < sipa> i hope that going forward we start enforcing it 12:29 < sipa> in modified code, at least 12:30 < sipa> https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#developer-notes 12:36 < isle2983> yeah, that makes sense to me. but I am not going to poke the enforcement side too hard. 12:36 -!- F0sea [~F0sea@185.86.151.126] has joined #bitcoin-core-dev 12:36 < jtimon> hmm, I'm also not sure https://github.com/bitcoin/bitcoin/blob/master/src/.clang-format enforces the "always braces except if everything in one line" rule 12:37 < sipa> i'm not sure that it can 12:37 < isle2983> the clang-format script in #9658 generates a 'score' metric 12:37 < gribble> https://github.com/bitcoin/bitcoin/issues/9658 | Add clang_format.py to help automate code style analysis by isle2983 · Pull Request #9658 · bitcoin/bitcoin · GitHub 12:38 < isle2983> so at the very least, we can watch it converge rather than diverge over time 12:39 < jtimon> yeah, it seems some (all?) of your tools would fit better in https://github.com/bitcoin-core/bitcoin-maintainer-tools from what other people said 12:40 < isle2983> yep 12:40 < isle2983> I am happy with that as a starting place 12:41 < jtimon> IMO, style rules aren't so useful until you start to enforce it with the help of automatic tools in the whole project, that's the only way you can really stop talking about style, which is the goal of having style rules in the first place, right? 12:41 < gmaxwell> sipa: clang-format (latest versions) can enforce that rule. 12:41 < gmaxwell> jtimon: I don't agree. Code style existed long before tools to do anything special with it. 12:42 < jtimon> gmaxwell: thanks for confirming, that's what I thought, including the exception for the single line ifs 12:42 < gmaxwell> I think automatic tools often handicap style discussions, because they enforce it stupidly to the point where they can irritate people and cause general opposition to standards. 12:42 -!- handlex [~handlex@189.74.9.113] has joined #bitcoin-core-dev 12:42 < gmaxwell> jtimon: yes, including the exception, according to the docs. I have not tested it. 12:42 < jtimon> well, code style without automatic rules may save you some style discussions, but not all 12:42 < gmaxwell> (I don't have a current version of clang on my laptop -- another challenge with formating tools, they change.) 12:43 -!- handlex [~handlex@189.74.9.113] has quit [Client Quit] 12:43 < jtimon> yep 12:43 < gmaxwell> jtimon: they give people a way to answer the question without first asking everyone else all the time. :) 12:44 < jtimon> absolutely 12:44 < gmaxwell> (I'm not opposed to tools, but they work MUcH better for single developers and single companies with rigidly enforced development workstation configs.. than they do for big projects) 12:46 < jtimon> true that, my very positive experience where with enforced development confgs per project, the project that had discussions about syle were those not enforcing the style automatically 12:46 < jtimon> s/experience where/experiences were 12:47 < isle2983> the trend does seem to be towards containerized environments for builds there the dependencies can be managed. That might be wrong for bitcoin, however. 12:47 < luke-jr> git-clang-format looks interesting 12:47 < isle2983> *where 12:49 < jtimon> luke-jr: https://github.com/llvm-mirror/clang/blob/master/tools/clang-format/git-clang-format ? seems the same concept as MarcoFalke's script we don't use, no? 12:49 < luke-jr> I haven't followed all the discussion, but an upstreamed tool seems better than one we maintain 12:50 < jtimon> ie this one https://github.com/bitcoin-core/bitcoin-maintainer-tools/blob/master/clang-format.py but yeah, this seems to be more interesting as it integrates with git 12:51 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye] 12:52 < luke-jr> step 1: provide a config file so we can just use git-clang-format manually for correct output ;) 12:53 < cfields> luke-jr: even better, i assume it can be a commit hook? 12:53 < luke-jr> cfields: I would think so, but I haven't tried it 12:53 < cfields> (that's a bit dangerous though i suppose, if the script breaks and you lose your commit) 12:54 < luke-jr> repo-wide commit hooks seem like a complex enough thing with git that I'd make that a full step 2 though ;) 12:54 < cfields> heh, yes 13:17 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 13:21 < MarcoFalke> luke-jr: It is a 1-1 copy of llvm 13:30 < luke-jr> >_< 13:30 < MarcoFalke> Eh, whatever. Misread the scorllback 13:30 < MarcoFalke> We could add the git-clang-format as well, so it is in our tree 13:35 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 13:57 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 264 seconds] 13:59 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 13:59 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 14:00 < luke-jr> I don't see how this is possible https://github.com/bitcoin/bitcoin/pull/9619#issuecomment-277096336 14:19 < MarcoFalke> Is there a way to bisect only on (signed) merge commits? 14:22 < MarcoFalke> Otherwise merging this will probably upset a few: https://github.com/bitcoin/bitcoin/pull/9657#issuecomment-277094673 14:23 < luke-jr> it wouldn't be the first time we have an untestable tree merged in history 14:24 < luke-jr> it's a potential security issue to keep in mind though 14:24 < luke-jr> (bisecting unsigned commits) 14:25 < MarcoFalke> Well, I hope when people review, they check that the intermediate commits don't add random binary blobs 14:26 < gmaxwell> MarcoFalke: code that totally backdoors your machine could be a couple lines of shellscript. And the concern there is just that you pull and some is slipped in and you run in bisect... it's worried me before, but didn't seem like there was anything to do over it. 14:27 < MarcoFalke> Still should be part of review to ensure this does not happen 14:27 < gmaxwell> it's not something review can control. 14:27 < kanzure> hi am i late 14:27 < gmaxwell> I do wish you could check in a .gitbisectuntestable which has a list of commits bisect should just skip over. 14:28 < MarcoFalke> Please explain why review can not control it 14:28 < sipa> gmaxwell, MarcoFalke: write a script that produces a list of all unsigned commits, and feed those to 'git bisect skip 14:28 < sipa> ? 14:30 < jtimon> BlueMatt: at this point, should I just close #9634 as included in #9650 ? 14:30 < gribble> https://github.com/bitcoin/bitcoin/issues/9634 | Fail in DecodeHexTx if there is extra data at the end by jtimon · Pull Request #9634 · bitcoin/bitcoin · GitHub 14:30 < gribble> https://github.com/bitcoin/bitcoin/issues/9650 | Better handle invalid parameters to signrawtransaction by TheBlueMatt · Pull Request #9650 · bitcoin/bitcoin · GitHub 14:30 < BlueMatt> jtimon: I suppose so 14:30 < gmaxwell> MarcoFalke: Because compromised code can hide things from reviewers. And there is no guarentee that things that hit the tree have been reviewed (particularly if a commiter is compromised). So if you get compromised you might merge bad commits. You can't see they're bad because the compromise hides them. Other people don't see they're bad because they only review the ultimate commit if at all. 14:30 < gmaxwell> .. and becuase once they run something in a bad commit they become compromised and can't see it either. 14:31 < jtimon> BlueMatt: ok, thanks for the tests! 14:32 < luke-jr> all the more reason to sandbox dev 14:32 < gmaxwell> especially since we don't require that PR that we merge be based on the current tip (it would be unreasnable to do so), the intermediate commits will often not match exactly what anyone has reviewed. 14:32 < bitcoin-git> [bitcoin] jtimon closed pull request #9634: Fail in DecodeHexTx if there is extra data at the end (master...upstream-fail-decode-tx) https://github.com/bitcoin/bitcoin/pull/9634 14:32 < gmaxwell> Even where the final result does. 14:32 < BlueMatt> jtimon: thanks for catching that I forgot to upstream this! 14:32 < jtimon> np 14:33 < luke-jr> it'd probably be more practical to review if we used merge commits instead of rebasing 14:33 < MarcoFalke> Which is why I proposed we don't corrupt merge commits 14:33 < MarcoFalke> See #8089 14:33 < gribble> https://github.com/bitcoin/bitcoin/issues/8089 | verify-commits should also check for malicious code in merge commits · Issue #8089 · bitcoin/bitcoin · GitHub 14:33 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 14:34 < MarcoFalke> > Other people don't see they're bad because they only review the ultimate commit if at all. 14:34 < MarcoFalke> Review should always be done commit-by-commit 14:34 < gmaxwell> MarcoFalke: conflicts though is not the same as no difference at all. 14:35 < gmaxwell> Bascially if you require there be no difference then we must require every PR rebase and re-review every time another PR is merged that touches the same files (or at least functions). 14:35 < gmaxwell> Otherwise you can arrange the automatic resolution to add vulnerabilities. 14:36 < gmaxwell> and already people will review commits, but not review that what is ultimately merged were the same commits exactly (usually aren't, due to other changes) 14:38 < MarcoFalke> I don't understand how you end up with two different results when you merge the exact same commits. 14:38 < MarcoFalke> I mean you get a different commit hash when you don't adjust the time to time-of-merge and author to merge-commit-author etc 14:39 < MarcoFalke> but it should be possible to replay all merge commits and compare them to what peoples eyes reviewed 14:40 < jtimon> BlueMatt: you missed one garbate in 9650 :p 14:40 < BlueMatt> oh ffs, leave my spelling alone! 14:40 < BlueMatt> /s 14:41 < gmaxwell> MarcoFalke: If I review PR X which is on head Y (or which I merged to Q) that is not the same as reviewing PR X merged against Z. (particularly in adversarial condictions) 14:42 < gmaxwell> I think this is getting too abstract, for this discussion I think it suffices to point out that people will pull code into their local branches before reviewing it, because pulling it into their branch is how they go about reviewing it. 14:42 < MarcoFalke> Reviewers don't commit to "PR X merged against Z", they commit to "PR X". 14:43 < MarcoFalke> They can only commit to the merge commit when the merge actually happened in the master branch 14:45 < MarcoFalke> I mean I can merge a commit_A locally for testing, but when I publish my review I don't refer to my local merge commit by to commit_A 14:45 < gmaxwell> You're saying the same thing as me--- I think. Reviewers review PR X and so cannot be counted on strongly to catch malicious behavior in X which is only exposed by its merge in Z. 14:45 < MarcoFalke> /by/but/ 14:45 < gmaxwell> MarcoFalke: right, and so your review /may/ be ineffective, particularly if X was maliciously constructed. 14:47 < bitcoin-git> [bitcoin] luke-jr opened pull request #9672: Opt-into-RBF for RPC & bitcoin-tx (master...rpc_rbf) https://github.com/bitcoin/bitcoin/pull/9672 14:47 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 14:47 * luke-jr kicks insta-conflict 14:48 < MarcoFalke> Oh I think we were talking about two completely unrelated things, I think. You were raising concerns about possible exploits that only arise after gits merge algorithm processed them. I was talking about maintainers appending commit/ ammending commits/ editing merge commits or reviewers skipping individual commits of pull request which happen to contain a +++ exploit.sh and ---exploit.sh 14:50 < gmaxwell> Right. and I am saying that I do not believe people review intermeadate commits in merges, because doing so cannot show issues that arose through the merge. They look at PRs and at end results. If you slip in extra commits that do not change the end results, I believe it is unlikely to get noticed. 14:50 < gmaxwell> Perhaps I'm wrong. 14:53 < MarcoFalke> I don't think you are wrong, so we should work towards making it easy such that a uncompromised machine with a helper script and some verified keys can validate the current state of the bitcoin-git repo 14:54 < luke-jr> ideally, but I think we need to prioritise getting reviews done over making reviews more effort 14:54 < MarcoFalke> Yeah, that is the downside. 15:31 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Quit: Leaving] 15:31 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9673: Set correct metadata on bumpfee wallet transactions (master...pr/bumpfee-meta) https://github.com/bitcoin/bitcoin/pull/9673 15:47 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 15:48 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 15:51 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has quit [Remote host closed the connection] 16:03 < BlueMatt> #9673 probably needs an 0.14 tag? I believe its a bugfix for bumpfee 16:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9673 | Set correct metadata on bumpfee wallet transactions by ryanofsky · Pull Request #9673 · bitcoin/bitcoin · GitHub 16:06 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Read error: Connection reset by peer] 16:07 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev 16:11 -!- jnewbery [~Thunderbi@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Quit: jnewbery] 16:11 < achow101> what do you all think of the release notes so far? Is there anything else to add? 16:29 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has quit [Quit: e4xit] 16:30 -!- e4xit [~textual@cpc1-cmbg20-2-0-cust188.5-4.cable.virginm.net] has joined #bitcoin-core-dev 16:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [] 17:05 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #9674: Lock cs_vSend and cs_inventory in a consistent order even in TRY (master...2017-02-inv-send-lockorder) https://github.com/bitcoin/bitcoin/pull/9674 17:24 -!- harrymm [~wayne@104.207.83.35] has quit [Ping timeout: 240 seconds] 17:35 -!- harrymm [~wayne@191.96.49.98] has joined #bitcoin-core-dev 17:39 -!- Cory [~Cory@unaffiliated/cory] has quit [Ping timeout: 256 seconds] 17:41 -!- Pasha [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev 17:44 -!- CubicEarth [~cubiceart@c-50-159-126-21.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 17:46 -!- harrymm [~wayne@191.96.49.98] has quit [Ping timeout: 260 seconds] 17:48 -!- Pasha is now known as Cory 17:50 -!- harrymm [~wayne@191.96.49.98] has joined #bitcoin-core-dev 17:55 -!- harrymm [~wayne@191.96.49.98] has quit [Ping timeout: 258 seconds] 18:00 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 18:07 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-thoataxmcuspukgf] has quit [Quit: Connection closed for inactivity] 18:07 -!- harrymm [~wayne@104.207.83.31] has joined #bitcoin-core-dev 18:31 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev 18:35 -!- alpalp [~alpalp@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev 18:35 -!- alpalp [~alpalp@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host] 18:35 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 18:44 -!- MarcoFalke [~marco@host191-2.natpool.mwn.de] has quit [Ping timeout: 256 seconds] 19:47 < luke-jr> hm, I guess rawtx ought not use -walletrbf as a default 19:59 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 240 seconds] 20:00 -!- dermoth [~thomas@dsl-66-36-143-138.mtl.aei.ca] has quit [Read error: Connection reset by peer] 20:00 -!- dermoth [~thomas@dsl-66-36-143-138.mtl.aei.ca] has joined #bitcoin-core-dev 20:20 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:7544:1851:318a:8188] has quit [Ping timeout: 255 seconds] 20:20 -!- PaulCape_ [~PaulCapes@2604:5500:17:2ea:280e:4d78:25b6:9bea] has joined #bitcoin-core-dev 20:36 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev 20:37 < ossifrage> So I was just trying to do a send and bitcoin-qt crashed: 2017-02-03 04:32:10 GUI: QXcbConnection: XCB error: 3 (BadWindow), sequence: 15464, resource id: 64026419, major code: 40 (TranslateCoords), minor code: 0 20:38 < ossifrage> 2017-02-03 04:32:23 GUI: Cannot mix incompatible Qt library (version 0x50700) with this library (version 0x50701) 20:38 < ossifrage> When I restarted the send did not show up as pending, but it very much was not a 'warm and fuzzy' 20:40 < ossifrage> I'm using v0.13.2 built from the github git tree 20:43 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev 20:46 < luke-jr> ossifrage: sounds like you built it on another machine? 20:47 < ossifrage> Nope, I built it on the same machine it was running 20:47 < ossifrage> https://forum.manjaro.org/t/unstable-qt5-5-7-1-update-breaks-applications/14234 20:49 < ossifrage> I'm not so worried that it crashed, but instead that the transaction was in limbo. When I restarted it did not show up as pending, so no harm done. 20:50 < ossifrage> The client seemed to be just fine, it downloaded the full block chain and has run on and off for a few weeks, it didn't expire until I tried to do a send 20:51 < luke-jr> I would assume it is still pending 20:52 -!- chris200_ [~chris2000@p5082AC21.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 20:54 < ossifrage> luke-jr, when I restarted the client it did not show up in the transactions list and it did not show up as a negative pending value 20:55 < ossifrage> I also didn't see anything in debug.log about a transaction. Is there a confirm dialog after clicking 'send'? 20:55 -!- chris2000 [~chris2000@p5DCB4AF1.dip0.t-ipconnect.de] has quit [Ping timeout: 252 seconds] 20:56 < luke-jr> there usually is, yes; if you didn't confirm, you're safe 20:59 < ossifrage> Yeah, I'd be a bit annoyed if I lost $570 to bitpay 21:02 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Ping timeout: 248 seconds] 21:32 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:33 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 21:48 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 21:58 -!- vFSgrcFGBJHg [~rYUtdcvYT@2a02:2f0a:b0b7:c00:a595:d890:edcc:bbee] has joined #bitcoin-core-dev 22:28 -!- vFSgrcFGBJHg [~rYUtdcvYT@2a02:2f0a:b0b7:c00:a595:d890:edcc:bbee] has quit [Quit: Leaving] 22:29 -!- vFSgrcFGBJHg [~rYUtdcvYT@2a02:2f0a:b0b7:c00:a595:d890:edcc:bbee] has joined #bitcoin-core-dev 23:15 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 23:29 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-smvfaflawjazxeyu] has joined #bitcoin-core-dev 23:32 -!- Evel-Laptop [~Evel-Knie@195.76.173.123] has joined #bitcoin-core-dev