--- Day changed Wed Nov 01 2017 00:12 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev 00:16 -!- quantbot [~quantbot@38.101.106.141] has quit [Ping timeout: 248 seconds] 00:19 -!- MrPaz [~PazPazPaz@2602:306:8348:2f70:90b7:91f7:1898:e5cc] has joined #bitcoin-core-dev 00:24 -!- MrPaz [~PazPazPaz@2602:306:8348:2f70:90b7:91f7:1898:e5cc] has quit [Ping timeout: 252 seconds] 00:45 -!- riemann [~riemann@ip-222-88.ists.pl] has joined #bitcoin-core-dev 00:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 00:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 00:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 00:54 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds] 00:58 < wumpus> ARM and QT5 works great, a lot of embedded devices vendors use that combination, the problem (with regard to bitcoin) is that it's not really standardized, so one mgiht be using qt w/ kms backend, the other with wayland, the other with X11, there's no one-size-fits-all static executable 00:58 < wumpus> so it would be pretty pointless to distrubute them 00:59 < wumpus> with your own cross-compile environment you can certainly build bitcoin-qt for ARM 00:59 < wumpus> but it's quite specifific to the device 01:01 < wumpus> or at least what libraries and versions and such are in its buildroot 01:02 -!- wordsToL_ [~wordsToLi@gateway/vpn/privateinternetaccess/wordstoliveby] has joined #bitcoin-core-dev 01:02 -!- wordsToLiveBy [~wordsToLi@gateway/vpn/privateinternetaccess/wordstoliveby] has quit [Read error: Connection reset by peer] 01:02 < wumpus> you might have luck changing qt to dynamically link, but you'd have to be sure to have a compatible version of qt5 on the device - ideally you'd build against the specific qt5 library that is on the device 01:04 < wumpus> if both the host and device are ubuntu you can "cheat" by installing the qt5-dev:armhf package on the host, the cross-build chain should automatically pick that up 01:13 -!- owowo [ovovo@gateway/vpn/mullvad/x-nqlbhlzzoozscvbu] has quit [Ping timeout: 248 seconds] 01:14 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 01:24 -!- zach__ [4c4e476a@gateway/web/freenode/ip.76.78.71.106] has joined #bitcoin-core-dev 01:25 -!- zach__ [4c4e476a@gateway/web/freenode/ip.76.78.71.106] has quit [Client Quit] 01:28 -!- str4d [~str4d@27.110.123.91] has joined #bitcoin-core-dev 01:36 < luke-jr> wumpus: ideally you'd build against some minimum required Qt.. Qt is good about backward binary compat, IIRC 01:46 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection] 01:46 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 01:51 -!- riemann [~riemann@ip-222-88.ists.pl] has quit [Ping timeout: 248 seconds] 01:53 -!- BGL [eighty@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Ping timeout: 258 seconds] 02:13 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev 02:17 -!- quantbot [~quantbot@38.101.106.141] has quit [Ping timeout: 252 seconds] 02:19 < wumpus> luke-jr: yeah that'd work, certainly in our case you'd lose nothing with that approach, we don't use any actual qt5 features, let alone new ones... 02:20 < jouke> win 32 02:20 < wumpus> could bulid dynamically against the first sane version of qt5. We used to do something like that for qt4 IIRC 02:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 02:37 -!- berndj [~berndj@mail.azna.co.za] has quit [Ping timeout: 264 seconds] 02:39 < luke-jr> wumpus: this would fix the Ubuntu issues as well, perhaps 02:39 < luke-jr> wumpus: we don't even need the Qt5 we build against to be completely sane either since we won't distribute that.. just binary-compatible 02:42 < wumpus> I remember there was a good reason we switched to statically linking qt, there were qt incompatiblity issues on some platforms 02:43 < wumpus> I think there was at least some security feature on one distro that affected qt's binary compatiblity 02:44 < wumpus> distribution-agnostic GUI software on linux is an unsolved problem, the only things that seem to work, unfortunately (because they're big hammers) are either statically linking or shipping the whole whopping library chain (most linux games do this) 02:46 < luke-jr> the latter is better IMO 02:47 < wumpus> and it becomes even more involved when embedded development of any form is involved. 02:47 < luke-jr> at least with that approach, users can choose between using the bundled libs or using the system ones 02:47 < wumpus> linux is an operating system where things are built from source, either by the user themselves or their distro/buildroot 02:48 -!- ula [~kvirc@b2b-78-94-11-194.unitymedia.biz] has joined #bitcoin-core-dev 02:48 < wumpus> distributing binaries for linux is really a no-go, and so is trying to provide any one-size-fits-all linux cross target 02:48 < luke-jr> dunno, for Android and iOS it might be possible 02:48 < wumpus> our current hacks work pretty well given that 02:49 < wumpus> yes, I don't consider android or iOS 'linux' for this intent. THey have heavily standardized API specifications. 02:49 < luke-jr> ABCore is nice, but loses the whole GUI :P 02:49 < wumpus> for 'open' linux there's just too much drift 02:50 < wumpus> too much custom patching 02:50 < wumpus> and so on 02:50 < wumpus> which is good for freedom but not for binary software :-) (which could be considered a feature in some regards) 02:51 < wumpus> yeah, user expectation wise qt isn't that suited to building android GUIs 02:51 < wumpus> bitcoin-qt's gui would be kind of weird on a mobile device 02:51 < luke-jr> the Qt example in Play store didn't seem that bad :P 02:51 < wumpus> probably the fancy qml qt5 stuff? 02:51 < wumpus> not 'widgets' that we use 02:51 < luke-jr> dunno, does QML not use the same code as normal GUI? 02:51 < wumpus> no, it's completely different 02:51 < luke-jr> I would have expected QML was just an interface to widgets 02:51 < luke-jr> that sucks 02:52 * luke-jr misses TrollTech 02:53 < wumpus> qml is a graphics markup language, a kind of 2D scene graph, with lots of plugins for animation, video, audio, touch gestures, etc 02:53 < luke-jr> I thought it did widgets too 02:53 < wumpus> its' erally different from widgets which is aimed at old-style GUIs (say, desktop spreadsheets) 02:53 < wumpus> going to QML would be a complete redesign of the GUI 02:54 < luke-jr> Widgets don't look native on Android? 02:54 < wumpus> which would be ok with me, but I just don't know anything about that side of GUI design, nor do I have the time 02:54 -!- BGL [sixty@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 02:54 < luke-jr> .. ironic coming from the original GUI dev :P 02:54 < luke-jr> but tbh, I probably wouldn't want to change to QML 02:54 < luke-jr> I prefer doing the entire GUI in code 02:55 < wumpus> I come from opengl driver dev, rendering backends, not frontends :p 02:55 < luke-jr> sure, I just meant that you wrote bitcoin-qt entirely yourself 02:55 < luke-jr> initially 02:55 < wumpus> oh sure I've used qt a lot in the past, mostly for tooling 02:56 < wumpus> that's old-style GUIs though, I meant I don't get QML 02:56 < luke-jr> old-style GUIs ftw 02:57 < wumpus> I agree (but we're a dying breed) 02:59 < wumpus> in any case my point was that qt-for-mobile is mostly aimed at QML, widgets are not a good fit for what peopel expect w/ touch interfaces 03:00 < luke-jr> that's disappointing to hear 03:01 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 03:02 < wumpus> it would certainly be possible to port the current GUI as-is to android, but I'd expect that'd mostly result in complaints 03:02 -!- riemann [~riemann@ip-222-88.ists.pl] has joined #bitcoin-core-dev 03:14 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds] 03:16 -!- riemann [~riemann@ip-222-88.ists.pl] has quit [Quit: Leaving] 03:21 -!- warxhead [warxhead@c-73-243-180-191.hsd1.co.comcast.net] has quit [] 03:27 -!- tevrizci [4ea84c65@gateway/web/freenode/ip.78.168.76.101] has joined #bitcoin-core-dev 03:27 < tevrizci> hi 03:27 -!- tevrizci [4ea84c65@gateway/web/freenode/ip.78.168.76.101] has quit [Client Quit] 03:28 -!- Cogito_Ergo_Sum [~Myself@athedsl-314500.home.otenet.gr] has joined #bitcoin-core-dev 03:28 -!- Cogito_Ergo_Sum [~Myself@athedsl-314500.home.otenet.gr] has quit [Changing host] 03:28 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev 03:28 < wumpus> hi 03:39 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 03:46 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #bitcoin-core-dev 03:58 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 03:59 < bitcoin-git> [bitcoin] fanquake closed pull request #11587: Fix warnings when building with -Wthread-safety-analysis (master...–Wthread-safety-analysis) https://github.com/bitcoin/bitcoin/pull/11587 03:59 < fanquake> wumpus are you still around? 04:04 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Read error: No route to host] 04:04 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 04:14 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev 04:14 < promag> a bit late for the qml chat 04:14 < promag> > qml is a graphics markup language, a kind of 2D scene graph, with lots of plugins for animation, video, audio, touch gestures, etc 04:15 < promag> maybe it started in that context, but qml is a declarative language with a javascript engine 04:15 < promag> it is used in other contexts, for instance, qbs which is the most recent building system 04:17 < promag> anyway, I though that if we want to split the wallet UI and add IPC then it would be a great opportunity to reimplement the UI in QtQuick 04:18 -!- quantbot [~quantbot@38.101.106.141] has quit [Ping timeout: 240 seconds] 04:20 < luke-jr> promag: I don't see what reimplementing the wallet has to do with splitting it out 04:21 -!- nelruk [~dax_the_c@host-252.58.217.201.copaco.com.py] has joined #bitcoin-core-dev 04:26 < promag> to change the current wallet from widgets to qtquick would take several PR's (which would sit there for a long time) 04:27 < promag> dunno if the IPC PR from ryanofsky is going forward 04:27 < promag> both require lots of changes to the wallet ui code 04:28 < promag> that's why I think adding IPC to glue a new wallet ui is probably easier 04:29 < promag> we could have both bitcoin-qt and bitcoin-quick and later drop support for the first 04:29 < promag> anyway, moving to qtquick is something IMHO we should plan 04:30 < luke-jr> why? what are the benefits? 04:32 < promag> modern ui, hw accelerated, adapts easily to non-desktop platforms, qt is pushing to that direction too, it is way easier to read and understand the code, it forces the mvc pattern.. 04:32 < promag> not something we should do for the next release or 2 04:32 < fanquake> What's the minimum supported qt version? 04:32 < luke-jr> sounds mostly subjective. C++ Qt code is plenty readable. 04:33 < promag> qt5 04:33 < fanquake> 5. what? 04:33 < fanquake> 5.0 04:34 < promag> depends which components we plsn to use 04:35 < fanquake> Anything introduced earlier than 5.2 should be ok to use. 04:36 < fanquake> That is atleast the minimum for qt, because of an osx hack. Although it could be > now. 04:36 < promag> luke-jr: I've used both widgets and qtquick a lot, and from my experience with qtquick the code is more expressive and easy to read 04:38 < fanquake> promag do you have a good open source project that's using it as an example to look at? 04:39 < promag> mine no, I can point to some products that were using native code and moved to qtquick 04:40 < promag> qt has a lot of sample code 04:42 < luke-jr> I'm not sure embedding a JS engine in a wallet is a good idea :/ 04:44 < promag> my point is, it's not we should do for the current ui, but we could do if something requires a great ui refactor 04:45 < luke-jr> hmm 04:45 < promag> luke-jr: why? overhead or security 04:45 < luke-jr> security mainly 04:45 < luke-jr> overhead may be a consideration for mobile too, I guess 04:46 < luke-jr> otoh, if we're refactoring, we can isolate the GUI from the wallet itself, so maybe less of an issue 04:46 < promag> right 04:47 < luke-jr> but not a non-issue either, since the GUI obviously needs to be able to make transactions 04:47 -!- pergaminho [~Cleber@201.47.91.172] has joined #bitcoin-core-dev 04:48 < promag> anyway, I could write a prototype if it's something we all agree on seeing 04:49 < luke-jr> promag: can C++ code contruct the GUI still with QtQuick? 04:50 -!- unholymachine [~quassel@2601:8c:c003:9f16:5554:198e:ad6c:2a43] has quit [Remote host closed the connection] 04:51 < promag> you can manipulate the "DOM" in c++ 04:51 < promag> but that is pretty ugly on the qml land 04:51 < luke-jr> I found it convenient to implement policy options in the GUI with format strings 04:51 < promag> usually you implement the model(s) in c++ and the view(s) in qml 04:52 -!- unholymachine [~quassel@2601:8c:c003:9f16:ecd4:4011:efc:297a] has joined #bitcoin-core-dev 04:52 < luke-jr> tr("Require transaction fees to be at least %s per kB higher than transactions they are replacing.") 04:52 < luke-jr> where %s becomes the option control 04:53 < luke-jr> not sure QML can do anything similar 04:53 < promag> is this what we want: not see http://doc.qt.io/qt-5/qtquick-internationalization.html#4-use-op-op-x-to-insert-parameters-into-a-string 04:53 < gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub 04:53 < promag> s/we/you 04:53 < luke-jr> no, that's just inserting stuff 04:54 < luke-jr> in my case, %s is turning into a spinbox, inputbox, etc 04:55 < promag> we mean the text to translate has something that is binded to a combobox selection? 04:55 < promag> err, s/we/you 04:55 < luke-jr> yes 04:55 < promag> text: qsTr("File %1 of %2").arg(combobox.selectedText).arg(total) 04:55 < luke-jr> no :p 04:56 < luke-jr> the combobox (or whatever type) would literally be inside the string 04:56 * luke-jr grabs a screenshot 04:59 < luke-jr> promag: http://luke.dashjr.org/tmp/screenshots/Screenshot_20171101_115900.png 05:01 < luke-jr> I suppose the trick to do this might be to implement a special widget *for* QML that can do it.. 05:01 < promag> to do what? 05:02 -!- dermoth_ [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 05:02 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Disconnected by services] 05:02 -!- dermoth_ is now known as dermoth 05:03 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 258 seconds] 05:03 < promag> everything there can be done with out-of-the-box qtquick, not sure what you mean 05:04 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 05:09 < promag> ah, but how do you do that with widgets? horizontal layout with label + combo + label? 05:39 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev 05:39 < wumpus> fanquake: yes 05:42 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 05:44 < wumpus> promag: luke-jr: FWIW javascript of any kind in bitcoin core scares me, even in the GUI, I know this is not like dragging in a browser (it's not html based, nor is it meant as a sandbox for untrusted code) but it's still such a huge exploitable component 05:45 < wumpus> in addition to javascript just being a terrible language 05:45 < wumpus> I'd loathe to maintain that or even have to review changes to it 05:50 < wumpus> but the same argument would hold for e.g. integrating a lua or python scripting engine 05:50 < wumpus> even though I like those languages :-) 05:59 < fanquake> wumpus Cool. I think #11442 is ready to go. 05:59 < gribble> https://github.com/bitcoin/bitcoin/issues/11442 | [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2 by fanquake · Pull Request #11442 · bitcoin/bitcoin · GitHub 05:59 < wumpus> fanquake: yes it is! sorry, lost track of it a bit 06:00 -!- Plus [674e9ce2@gateway/web/freenode/ip.103.78.156.226] has quit [Ping timeout: 260 seconds] 06:01 < fanquake> wumpus no worries. I was half waiting for someone else to test it, but I think it's better to just replace the outdated instructions. 06:01 < fanquake> Also need you to glance over #11573 given that you've pretty much maintained our changes to that code. 06:01 < gribble> https://github.com/bitcoin/bitcoin/issues/11573 | [Util] Update tinyformat.h by fanquake · Pull Request #11573 · bitcoin/bitcoin · GitHub 06:02 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8335cb478183...e8f3c88133b7 06:02 < bitcoin-git> bitcoin/master 9d30f54 fanquake: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2 06:02 < bitcoin-git> bitcoin/master e8f3c88 Wladimir J. van der Laan: Merge #11442: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2... 06:03 < bitcoin-git> [bitcoin] laanwj closed pull request #11442: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2 (master...openbsd-doc-update) https://github.com/bitcoin/bitcoin/pull/11442 06:05 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.15: https://github.com/bitcoin/bitcoin/commit/cf18f4289911c657eb876d91dee055db807870ad 06:05 < bitcoin-git> bitcoin/0.15 cf18f42 fanquake: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2... 06:05 < fanquake> #11571 is also a trivial merge. 06:05 < gribble> https://github.com/bitcoin/bitcoin/issues/11571 | Fixed a couple small grammatical errors. by BitsInMyBlood · Pull Request #11571 · bitcoin/bitcoin · GitHub 06:05 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 06:06 < wumpus> hah the compiler checks for // Falls through comments now? 06:06 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 06:07 < fanquake> wumpus good explainer here https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/ 06:07 < wumpus> fanquake: thanks 06:07 < wumpus> anyhow the change looks obviously ok, just adds sanity checking 06:09 < fanquake> #11565 is also ready to go. 06:09 < gribble> https://github.com/bitcoin/bitcoin/issues/11565 | Make listsinceblock refuse unknown block hash by ryanofsky · Pull Request #11565 · bitcoin/bitcoin · GitHub 06:10 < wumpus> ah so gcc added recognition of fallthrough comments, as placeholder for in c++17 we get an explicit [[fallthrough]] marker 06:10 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev 06:10 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 06:11 < wumpus> makes sense 06:11 -!- quantbot [~quantbot@38.101.106.141] has quit [Remote host closed the connection] 06:11 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev 06:12 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e8f3c88133b7...2631d55f61cd 06:12 < bitcoin-git> bitcoin/master 60b98f8 fanquake: [Util] Update tinyformat.h... 06:12 < bitcoin-git> bitcoin/master 2631d55 Wladimir J. van der Laan: Merge #11573: [Util] Update tinyformat.h... 06:13 < bitcoin-git> [bitcoin] laanwj closed pull request #11573: [Util] Update tinyformat.h (master...pull-upstream-tinyformat) https://github.com/bitcoin/bitcoin/pull/11573 06:13 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev 06:13 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host] 06:13 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 06:13 < bitcoin-git> [bitcoin] laanwj closed pull request #11565: Make listsinceblock refuse unknown block hash (master...pr/since) https://github.com/bitcoin/bitcoin/pull/11565 06:16 < fanquake> #11550 Is also mergeable, unless there are some more backports to be added. A new PR can always be opened later anyways. 06:16 < gribble> https://github.com/bitcoin/bitcoin/issues/11550 | [0.15.1] qa: Backports by MarcoFalke · Pull Request #11550 · bitcoin/bitcoin · GitHub 06:16 < wumpus> I was confused about 0.15.1 versus 0.15.0.2 there 06:17 < fanquake> Should it make a difference if it's ending up in the 0.15 branch? 06:17 < wumpus> so if they are 0.15.1 backports they shouldn't go in yet 06:17 < bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.15: https://github.com/bitcoin/bitcoin/commit/7d4546f17dca84928bd2b6d1e2588b673c237321 06:17 < bitcoin-git> bitcoin/0.15 7d4546f Russell Yanofsky: Make listsinceblock refuse unknown block hash... 06:17 < wumpus> I don't know - usually not, I guess 06:17 < wumpus> unless it's segwit wallet functionality then it shoudl be held up 06:19 < fanquake> wumpus yea ok, it can wait then. 06:20 < wumpus> it's just testing stuff so as it passes it can get in already 06:20 < fanquake> Don't think it will create any rebase issues either 06:20 < wumpus> if anything it makes rebasing easier by making 0.15 more like master :) 06:22 < bitcoin-git> [bitcoin] laanwj closed pull request #11550: [0.15.1] qa: Backports (0.15...Mf1710-0151qaBackports) https://github.com/bitcoin/bitcoin/pull/11550 06:23 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e1f6a2a801a0...c95832da87ac 06:23 < bitcoin-git> bitcoin/master f927ee1 Christian Gentry: Fixed a couple small grammatical errors.... 06:23 < bitcoin-git> bitcoin/master c95832d Wladimir J. van der Laan: Merge #11571: Fixed a couple small grammatical errors.... 06:23 < bitcoin-git> [bitcoin] laanwj closed pull request #11571: Fixed a couple small grammatical errors. (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11571 06:24 < fanquake> Just checking for anything else that is ready to go. 06:24 < fanquake> Maybe #11511 , I feel like we are going in circles a bit with the EXIT_CODE stuff though. 06:25 < gribble> https://github.com/bitcoin/bitcoin/issues/11511 | [Init] Remove redundant exit(EXIT_FAILURE) instances and replace with return false by donaloconnor · Pull Request #11511 · bitcoin/bitcoin · GitHub 06:25 < fanquake> They seem to get added, then removed, then added again. 06:25 < wumpus> fanquake: yeah same feeling here, it didn't occur to me as terribly relevant 06:25 < wumpus> but as it has ACKs, I"m fine with merging it 06:25 < luke-jr> ‎[12:09:14] ‎<‎promag‎>‎ ah, but how do you do that with widgets? horizontal layout with label + combo + label? <-- yes, autogenerated from the (post-translated) strign 06:26 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c95832da87ac...db2f83ed463b 06:26 < bitcoin-git> bitcoin/master b296bf1 donaloconnor: Init: Remove redundant exit(EXIT_FAILURE) instances and replace with return false 06:26 < bitcoin-git> bitcoin/master db2f83e Wladimir J. van der Laan: Merge #11511: [Init] Remove redundant exit(EXIT_FAILURE) instances and replace with return false... 06:27 < bitcoin-git> [bitcoin] practicalswift opened pull request #11591: wallet: Add missing cs_wallet locks in GetAvailableCredit/GetAvailableWatchOnlyCredit/CreateWalletFromFile (master...cs_wallet) https://github.com/bitcoin/bitcoin/pull/11591 06:27 < bitcoin-git> [bitcoin] laanwj closed pull request #11511: [Init] Remove redundant exit(EXIT_FAILURE) instances and replace with return false (master...161017_refactor_AppInit) https://github.com/bitcoin/bitcoin/pull/11511 06:32 -!- Gnof [~Gnof@CPE00fc8d7da303-CM00fc8d7da300.cpe.net.cable.rogers.com] has joined #bitcoin-core-dev 06:33 -!- Gnof [~Gnof@CPE00fc8d7da303-CM00fc8d7da300.cpe.net.cable.rogers.com] has quit [Remote host closed the connection] 06:33 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 06:35 < fanquake> Seems like the windows instructions need updating again already. Should we just be providing instructions for the latest release? 06:35 < fanquake> Having multiple different sets of instructions just for enabling the same feature seems un-ideal 06:36 < fanquake> I'm also not a great fan of 11438, seems like it just opens up lots of opportunities for miscompilation 06:39 < fanquake> Although it has been simplified quite a bit now. 06:42 < bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/db2f83ed463b...cffa5ee132f3 06:42 < bitcoin-git> bitcoin/master 3b4ac43 Matt Corallo: Rewrite p2p-acceptblock in preparation for slight behavior changes... 06:42 < bitcoin-git> bitcoin/master 3d9c70c Matt Corallo: Stop always storing blocks from whitelisted peers... 06:42 < bitcoin-git> bitcoin/master 932f118 Matt Corallo: Accept unrequested blocks with work equal to our tip... 06:43 < bitcoin-git> [bitcoin] laanwj closed pull request #11531: Check that new headers are not a descendant of an invalid block (more effeciently) (master...2017-10-cache-invalid-indexes) https://github.com/bitcoin/bitcoin/pull/11531 06:50 < BlueMatt> yeesh, can I get some postumous acks on that one ^ 06:54 < LumberCartel> That looks like a good idea. 06:55 < wumpus> fanquake: yeah... tend to agree one maintained way that works is better than 10 different ways different people prefer that work a bit 06:56 -!- aeftimia____ [32fd387b@gateway/web/freenode/ip.50.253.56.123] has joined #bitcoin-core-dev 07:01 < wumpus> I've long since given up getting people to agree, the only request I make is that cross-building for windows on 16.04 should be heavily discouraged because of the stack protector issue 07:02 < wumpus> it's potentially very dangerous 07:03 < wumpus> but in any case it results in broken executables so itt's a waste of time 07:03 < LumberCartel> I should clarify -- I was commenting that 11531 looks like a good idea. I think that improving ways to reduce or eliminate the effective of DoS attacks always a good idea. 07:05 < wumpus> yes, it is (if it works, please help review the code) 07:08 -!- wordsToL_ [~wordsToLi@gateway/vpn/privateinternetaccess/wordstoliveby] has quit [Quit: I'm chasing my sanity and it just ran out of the room, bbiab.] 07:08 -!- nelruk [~dax_the_c@host-252.58.217.201.copaco.com.py] has quit [Ping timeout: 252 seconds] 07:12 -!- nelruk [~dax_the_c@host-252.58.217.201.copaco.com.py] has joined #bitcoin-core-dev 07:16 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #11592: [qa] 0.15.0.2: Fix silent merge conflict (assert_raises_rpc_error) (0.15...Mf1711-qa01502) https://github.com/bitcoin/bitcoin/pull/11592 07:20 -!- nelruk [~dax_the_c@host-252.58.217.201.copaco.com.py] has quit [Ping timeout: 248 seconds] 07:21 -!- nelruk [~dax_the_c@host-252.58.217.201.copaco.com.py] has joined #bitcoin-core-dev 07:29 -!- nelruk [~dax_the_c@host-252.58.217.201.copaco.com.py] has quit [Ping timeout: 252 seconds] 07:29 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-bwxptvwkfrcutdbh] has quit [Quit: Connection closed for inactivity] 07:30 -!- nelruk [~dax_the_c@host-252.58.217.201.copaco.com.py] has joined #bitcoin-core-dev 07:33 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 07:34 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 07:42 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds] 07:46 -!- LumberCartel [~randolf@96.53.47.42] has quit [Ping timeout: 260 seconds] 07:46 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 07:47 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 07:55 -!- aeftimia____ [32fd387b@gateway/web/freenode/ip.50.253.56.123] has quit [Ping timeout: 260 seconds] 07:56 < xinxi> Will the US regulate Bitcoin development while it’s going to regulate Bitcoin derivatives? 07:56 < xinxi> What do you guys think? 07:57 < wumpus> no political discussion here please, use #bitcoin instead 07:58 -!- Guest21 [~textual@qr148.plus.com] has quit [Quit: Textual IRC Client: www.textualapp.com] 08:06 -!- d_p [~d_p@gateway/tor-sasl/dp/x-51976874] has left #bitcoin-core-dev [] 08:14 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.] 08:16 -!- LumberCartel [~randolf@207.81.117.86] has joined #bitcoin-core-dev 08:19 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 08:25 -!- MrPaz [~PazPazPaz@2602:306:8348:2f70:90b7:91f7:1898:e5cc] has joined #bitcoin-core-dev 08:25 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 08:26 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 08:26 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 08:29 -!- harrymm [~harrymm@85.203.47.115] has quit [Ping timeout: 240 seconds] 08:30 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 08:33 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #bitcoin-core-dev 08:36 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 08:39 -!- LumberCartel [~randolf@207.81.117.86] has quit [Ping timeout: 248 seconds] 08:44 -!- harrymm [~harrymm@85.203.47.58] has joined #bitcoin-core-dev 08:53 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 09:02 < karelb> is there ETA for 0.15.0.2? 09:03 < karelb> not exact date, just if it will be this week or before 2x at all etc (yeah I know ETA questions are annoying :)) 09:07 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev 09:08 -!- nelruk [~dax_the_c@host-252.58.217.201.copaco.com.py] has quit [Quit: Leaving] 09:11 < sipa> karelb: "soon" 09:11 < sdaftuar> cfields: i just commented in #11560 -- i'd like to undo the change to looping on mapNodeState vs ForEachNode 09:11 < gribble> https://github.com/bitcoin/bitcoin/issues/11560 | Connect to a new outbound peer if our tip is stale by sdaftuar · Pull Request #11560 · bitcoin/bitcoin · GitHub 09:12 < sdaftuar> matt pointed out to me that ForNode has to walk vNodes -- so looping on mapNodeState makes that loop n^2, instead of n log n 09:16 < cfields> sdaftuar: well you'll have to hold cs_vNodes for that to be safe... 09:17 < sdaftuar> ForEachNode already holds cs_vNodes right? 09:17 < cfields> or you mean doing the whole thing in ForEachNode ? 09:17 < sdaftuar> yeah i wanted to undo the change from ForEachNode -> loop on mapNodeState 09:17 < cfields> do you have the old commit handy? 09:17 < sdaftuar> yep 09:18 < sdaftuar> this is the commit that changed it: https://github.com/sdaftuar/bitcoin/commit/be8c4337838b17cc495f657c2f8bd94912e158d3 09:18 < sdaftuar> unsquashed branch is here: https://github.com/sdaftuar/bitcoin/commits/11560.1 09:18 < sdaftuar> it occurred to me that maybe i should check that CNodeState is not null in there 09:19 < sdaftuar> if i'm using ForEachNode i mean 09:19 < cfields> oh, i see what you mean. I thought you were talking about the _other_ lookup in ForNode below 09:19 < sdaftuar> ah, no i'm not worried about that, that's just O(n) 09:19 < sdaftuar> i'm just concerned about the n^2 09:22 < cfields> yea, ok 09:23 < sdaftuar> great thanks 09:25 < cfields> sdaftuar: fwiw, I was hoping to do something like this: https://github.com/theuni/bitcoin/commit/0693ffb8ed386095a27a8ca62a7eacada2e9db04 09:26 < cfields> (after the upcoming libevent changes, the fDisconnect status doesn't really matter since nodes are disconnected almost instantly. So we will want to drop those checks anyway. 09:27 < cfields> so that just leaves the CNodeState checks in that first test 09:27 < sdaftuar> ah, interesting 09:27 < sdaftuar> so we'd drop having to look into the cnode at all? 09:28 * sdaftuar -> lunch 09:28 < cfields> yea, we'd just connman->Disconnect(id) 09:30 < cfields> well, we'd also have to check for connection time > 30 sec. That's why I was suggesting that we make the timeout equal to the handshake, then we wouldn't have to do that either. 09:30 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cffa5ee132f3...1b8c88451b05 09:30 < bitcoin-git> bitcoin/master 5d465e3 Tomas van der Wansem: Ensure backupwallet fails when attempting to backup to source file... 09:30 < bitcoin-git> bitcoin/master 1b8c884 MarcoFalke: Merge #11376: Ensure backupwallet fails when attempting to backup to source file... 09:31 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #11376: Ensure backupwallet fails when attempting to backup to source file (master...core) https://github.com/bitcoin/bitcoin/pull/11376 09:33 < sipa> sdaftuar: were you going to adapt the approach to use an incrementable semaphore instead of a separate bool? 09:33 < sipa> or rather do that in a post-0.15.0.2 improvement 09:48 -!- pergamo [~Cleber@201.47.91.172] has joined #bitcoin-core-dev 09:48 -!- pergaminho [~Cleber@201.47.91.172] has quit [Read error: Connection reset by peer] 09:50 < sdaftuar> sipa: i'm not that familiar with the semaphore implementation so i was going to hold off on that 09:51 < sipa> okay 09:51 < sdaftuar> also i think there was some preference (at least from matt, not sure about others) for not having both a feeler and a 9th connection out at the same time 09:51 < sdaftuar> i don't feel strongly about that, but that would be a reason in favor of a bool vs incrementable semaphore i think? 09:53 < sdaftuar> cfields: i'm not following how you could drop the connection time > 30 second check? 09:57 < sdaftuar> cfields: specifically i had greg's same question about how you avoid disconnecting a peer that you just connected to 10:00 -!- quantbot_ [~quantbot@38.101.106.141] has joined #bitcoin-core-dev 10:01 -!- quantbot_ [~quantbot@38.101.106.141] has quit [Remote host closed the connection] 10:01 -!- quantbot_ [~quantbot@38.101.106.141] has joined #bitcoin-core-dev 10:04 -!- quantbot [~quantbot@38.101.106.141] has quit [Ping timeout: 246 seconds] 10:05 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 248 seconds] 10:07 < cfields> sdaftuar: you'd still check, but it could be done in CConnman. Changing to 60sec would just mean that CConnman's notion of earliest-possible-timeout (these change to libevent timers) wouldn't change 10:08 < cfields> I was getting ahead of myself, I guess that comment makes no sense without the future changes in mind 10:10 -!- warxhead [warxhead@c-73-243-180-191.hsd1.co.comcast.net] has joined #bitcoin-core-dev 10:10 -!- stevenroose [~steven@vps.weuste.club] has quit [Ping timeout: 240 seconds] 10:14 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 10:15 -!- stevenroose [~steven@vps.weuste.club] has joined #bitcoin-core-dev 10:23 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 246 seconds] 10:27 -!- xinxi [~xinxi@39.109.214.22] has quit [Remote host closed the connection] 10:28 -!- xinxi [~xinxi@39.109.214.22] has joined #bitcoin-core-dev 10:33 -!- xinxi [~xinxi@39.109.214.22] has quit [Ping timeout: 264 seconds] 10:40 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev 10:41 -!- vicenteH [~user@35.233.15.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer] 10:41 -!- vicenteH [~user@35.233.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 10:45 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 10:48 -!- xinxi [~xinxi@39.109.214.22] has joined #bitcoin-core-dev 10:50 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds] 10:52 < sipa> BlueMatt: how did the invalidateblock code result in failure for pruned nodes? 10:53 < sipa> (just trying to understand) 10:53 < sdaftuar> sipa: i think the issue is if you call invalidateblock on a blockhash that you've pruned 10:53 < BlueMatt> yea, it'll walk backwards, and set the invalid flag BEFORE disconnecting it 10:53 < BlueMatt> then when you go to disconnect, you will fail to read from disk and shut down 10:54 < BlueMatt> (AbortNode, I believe) but now when you start up no block meets the conditions for inclusion in setBlockIndexCandidates 10:54 < BlueMatt> because there are no blocks that are either a) our tip and valid or b) at least as much work as our tip and have data 10:55 < BlueMatt> so you hit the !setBlockIndexCandidates.empty() assert 10:55 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 246 seconds] 10:55 < sipa> BlueMatt: i see! 10:55 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev 10:56 < sipa> would there be a problem with marking the blocks invalid after disconnecting them, but one by one? 10:56 < sipa> as opposed to after the whole invalidated 10:56 < sipa> brb, meeting 10:57 < BlueMatt> sipa: not 100% sure. you'd definitely fail CheckBlockIndex, but it may actually be fine...you'd end up with things in your mapBlockIndex upon restart that have BLOCK_FAILED_CHILD but who's parents are IsValid, which is nonsense 10:57 < BlueMatt> it might, however, very likely not actually break anything 10:57 < BlueMatt> still, I *really* didnt want to try to think through that in the context of the g_failed_blocks stuff 10:57 < sipa> anyone, no objection to the change that was merged 10:58 < sipa> *anyway 10:58 < BlueMatt> I take that back, CheckBlockIndex does *not* verify this, but, again, its nonsense 11:00 -!- quantbot_ [~quantbot@38.101.106.141] has quit [Remote host closed the connection] 11:00 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev 11:03 -!- Giszmo [~leo@pc-204-28-214-201.cm.vtr.net] has joined #bitcoin-core-dev 11:05 -!- quantbot [~quantbot@38.101.106.141] has quit [Ping timeout: 260 seconds] 11:13 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Ping timeout: 252 seconds] 11:14 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 11:15 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev 11:19 -!- BGL [sixty@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer] 11:19 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev 11:20 -!- xinxi [~xinxi@39.109.214.22] has quit [Remote host closed the connection] 11:20 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds] 11:20 -!- xinxi [~xinxi@39.109.214.22] has joined #bitcoin-core-dev 11:27 -!- xinxi [~xinxi@39.109.214.22] has quit [Ping timeout: 258 seconds] 11:30 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-hngpjmmsbzyxzoxc] has joined #bitcoin-core-dev 11:39 -!- harrymm [~harrymm@85.203.47.58] has quit [Ping timeout: 252 seconds] 11:42 -!- harrymm [~harrymm@85.203.47.58] has joined #bitcoin-core-dev 12:06 < sipa> BlueMatt: i've for a while regretted the choice of having validity flags inside the block index 12:07 < BlueMatt> I mean they are a pretty separate concept 12:07 < sipa> your PR makes me wonder if we couldn't get rid of them entirely 12:07 < sipa> valid = chainActive 12:07 < BlueMatt> I mean we have to have them somewhere 12:07 < sipa> invalid = in g_failed_blocks 12:07 < BlueMatt> no, we need a concept of "descends from invalid" 12:07 < BlueMatt> I mean that kinda sucks cause it grows unbounded 12:08 < BlueMatt> though not the end of the world, I suppose 12:08 < sipa> it's at most a constant factor larger than mapBlockIndex itself 12:08 < sipa> a very small constant factor 12:08 < gmaxwell> how would thing like invalidateblock / reconsider block work? or pipelined validation with multiple stages of verification? 12:08 < sdaftuar> yes but it slows down acceptblockheader 12:08 < sdaftuar> you wouldn't want to iterate mapBlockindex just to accept a new header 12:09 < sipa> right, you want some form of 'caching' of invalid descendants 12:09 < sipa> but perhaps that doesn't need to be mapBlockIndex 12:10 < sipa> anyway, just a wild idea 12:10 < gmaxwell> it is kind of silly to have an extra field for something that is almost always just in a single state. 12:11 < BlueMatt> yea, I mean it is true that we barely use nStatus for anything except for HAVE_DATA 12:11 < sipa> and it doesn't even cover the whole thing 12:11 < BlueMatt> (which I guess is implied by the diskpos thing) 12:12 < sipa> we use nChainTx as indicator for "all parent blocks downloaded" 12:12 -!- quantbot_ [~quantbot@cpe-74-73-145-69.nyc.res.rr.com] has joined #bitcoin-core-dev 12:13 -!- quantbot [~quantbot@38.101.106.141] has quit [Read error: Connection reset by peer] 12:13 < BlueMatt> yea, I mean we do need VALID_SCRIPTS for net_processing :/ 12:13 < BlueMatt> cause we're not allowed to send stuff unless its VALID_SCRIPTS 12:14 -!- quantbot [~quantbot@38.101.106.141] has joined #bitcoin-core-dev 12:15 -!- str4d [~str4d@27.110.123.91] has quit [Ping timeout: 240 seconds] 12:17 -!- quantbot_ [~quantbot@cpe-74-73-145-69.nyc.res.rr.com] has quit [Ping timeout: 240 seconds] 12:20 -!- str4d [~str4d@27.110.123.91] has joined #bitcoin-core-dev 12:25 -!- BGL [twenty@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:31 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev 12:32 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 12:48 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev 13:03 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 13:06 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds] 13:09 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #bitcoin-core-dev 13:24 < bitcoin-git> [bitcoin] theuni opened pull request #11593: rpc: work-around an upstream libevent bug (master...fix-libevent-cb) https://github.com/bitcoin/bitcoin/pull/11593 13:39 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 13:41 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 13:42 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 13:47 -!- zi0nman [~textual@51.15.57.117] has joined #bitcoin-core-dev 13:48 < BlueMatt> cfields: travis failed on ^ (libevent in the travis os is 2.0, looks like, which does not have the getcb function) 13:48 < BlueMatt> only 2.1 has it 13:48 < cfields> ugh 13:49 < cfields> ok, working on it 14:10 -!- zi0nman [~textual@51.15.57.117] has quit [Ping timeout: 248 seconds] 14:12 < MarcoFalke> wumpus: cfields: I was trying to prepare the 0.15.0.2 release but I am stuck at deciding whether to backport #10756. 14:12 < gribble> https://github.com/bitcoin/bitcoin/issues/10756 | net processing: swap out signals for an interface class by theuni · Pull Request #10756 · bitcoin/bitcoin · GitHub 14:13 < MarcoFalke> some of the commits depend on it 14:13 < MarcoFalke> It might be shorter (with regard to LOC) to solve the merge conflicts manually 14:13 < MarcoFalke> But I'd wanted to see what you prefer 14:16 < cfields> MarcoFalke: i don't think that should be needed. What are the conflicts? 14:17 < MarcoFalke> In function ‘bool SendMessages(CNode*, CConnman&, const std::atomic&)’: error: ‘ConsiderEviction’ was not declared in this scope 14:20 < cfields> ah right, new members 14:20 < cfields> sec 14:22 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 14:23 < cfields> MarcoFalke: blah, backporting 10756 may be easier, as more and more commits build on it 14:24 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #bitcoin-core-dev 14:24 < cfields> MarcoFalke: it's either that, or break the new functions (like ConsiderEviction) global/static, and pass in the CConnman pointer 14:24 < MarcoFalke> Jup, figured that 14:27 < MarcoFalke> Since the not-yet-merged #11560 also needs it, I will try to cherry-pick your refactoring commits 14:27 < gribble> https://github.com/bitcoin/bitcoin/issues/11560 | Connect to a new outbound peer if our tip is stale by sdaftuar · Pull Request #11560 · bitcoin/bitcoin · GitHub 14:35 < ghost43> I would be interested in the exact semantics of nLockTime and chainActive.Height() here https://github.com/bitcoin/bitcoin/blob/5b059a833eb57a4dd8458f42aedba85265b2bbf3/src/wallet/wallet.cpp#L2661 -- does this line ensure that only the next block contain the tx? should it be height+1? at the same time I just tested and bitcoind rejects transactions with nLockTime for the next block. so does nLockTime mean that the block to contain a tx 14:35 < ghost43> has to have a height of nLockTime+1? 14:43 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Read error: Connection reset by peer] 14:49 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 14:54 < cfields> BlueMatt: pushed a new version that mimics the upstream fix 14:58 < BlueMatt> thanks! will review in a few minutes 15:00 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 240 seconds] 15:00 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev 15:07 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit [] 15:16 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has quit [Ping timeout: 260 seconds] 15:28 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] 15:42 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has joined #bitcoin-core-dev 16:13 -!- mlz [~IRCIdent@unaffiliated/molly] has quit [Quit: ZNC 1.6.5 - http://znc.in] 16:16 -!- shesek [~shesek@bzq-84-110-177-46.cablep.bezeqint.net] has joined #bitcoin-core-dev 16:16 -!- shesek [~shesek@bzq-84-110-177-46.cablep.bezeqint.net] has quit [Changing host] 16:16 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 16:19 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 252 seconds] 16:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 16:39 -!- molly [~IRCIdent@unaffiliated/molly] has joined #bitcoin-core-dev 16:53 -!- molly [~IRCIdent@unaffiliated/molly] has quit [Quit: ZNC 1.6.5 - http://znc.in] 17:01 -!- mlz [~IRCIdent@unaffiliated/molly] has joined #bitcoin-core-dev 17:07 -!- Sentineo [~Undefined@unaffiliated/sentineo] has quit [Ping timeout: 260 seconds] 17:07 -!- Sentineo [~Undefined@unaffiliated/sentineo] has joined #bitcoin-core-dev 17:16 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 240 seconds] 17:34 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 260 seconds] 17:35 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has quit [Ping timeout: 258 seconds] 17:38 -!- NielsvG [~Necrathex@2001:981:9573:1:d044:2ff:fe29:ad61] has joined #bitcoin-core-dev 17:38 -!- NielsvG [~Necrathex@2001:981:9573:1:d044:2ff:fe29:ad61] has quit [Changing host] 17:38 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has joined #bitcoin-core-dev 17:40 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 17:51 < bitcoin-git> [bitcoin] promag opened pull request #11594: Improve -disablewallet parameter interaction (master...2017-11-disable-wallet) https://github.com/bitcoin/bitcoin/pull/11594 17:53 -!- jeremyrubin [~jr@c-98-234-232-29.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 17:56 < promag> fanquake is the lucky luke of github labels 17:58 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 18:07 -!- ag__ [989cd87e@gateway/web/freenode/ip.152.156.216.126] has joined #bitcoin-core-dev 18:08 -!- SoGi [2d4896b1@gateway/web/freenode/ip.45.72.150.177] has joined #bitcoin-core-dev 18:15 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 18:16 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 18:17 -!- ag__ [989cd87e@gateway/web/freenode/ip.152.156.216.126] has quit [Quit: Page closed] 18:18 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 248 seconds] 18:25 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 18:26 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 18:56 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 19:01 -!- roadcrap [~roadcrypt@unaffiliated/roadcrap] has quit [Ping timeout: 248 seconds] 19:01 -!- roadcrap [~roadcrypt@unaffiliated/roadcrap] has joined #bitcoin-core-dev 19:03 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev 19:32 -!- goatpig [56f75683@gateway/web/freenode/ip.86.247.86.131] has quit [Quit: Page closed] 19:47 -!- dcousens [~dcousens@CPE-101-181-191-60.lnse6.cha.bigpond.net.au] has joined #bitcoin-core-dev 20:04 < bitcoin-git> [bitcoin] T-Pham opened pull request #11595: Update error messages in bitcoin-cli.cpp (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11595 20:17 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 240 seconds] 20:20 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev 20:21 -!- kkode [~eliasc@ool-18bfd89e.dyn.optonline.net] has joined #bitcoin-core-dev 20:26 -!- darkbtcfire [abf9a777@gateway/web/freenode/ip.171.249.167.119] has joined #bitcoin-core-dev 20:32 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds] 20:35 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.] 20:55 -!- darkbtcfire [abf9a777@gateway/web/freenode/ip.171.249.167.119] has quit [Quit: Page closed] 21:00 < dcousens> if `getblock` fails because we are pruning... could it be possible to instead the route the call to a network peer for the block? 21:00 < dcousens> (`getblock`, the rpc call) 21:03 -!- grio [~grio@ip68-102-158-172.ks.ok.cox.net] has quit [Ping timeout: 240 seconds] 21:13 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:13 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Client Quit] 21:13 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:14 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 255 seconds] 21:30 -!- grio [~grio@ip68-102-158-172.ks.ok.cox.net] has joined #bitcoin-core-dev 22:08 -!- MrPaz [~PazPazPaz@2602:306:8348:2f70:90b7:91f7:1898:e5cc] has quit [Ping timeout: 252 seconds] 22:27 -!- LumberCartel [~randolf@96.53.47.42] has joined #bitcoin-core-dev 22:33 -!- kkode [~eliasc@ool-18bfd89e.dyn.optonline.net] has quit [Quit: kkode] 22:35 -!- PaulCape_ [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has quit [Read error: Connection reset by peer] 22:38 -!- LumberCartel [~randolf@96.53.47.42] has quit [Quit: http://www.randolfrichardson.com/] 22:39 -!- PaulCapestany [~PaulCapes@ip68-100-207-53.dc.dc.cox.net] has joined #bitcoin-core-dev 22:39 -!- LumberCartel [~randolf@96.53.47.42] has joined #bitcoin-core-dev 22:42 -!- grio [~grio@ip68-102-158-172.ks.ok.cox.net] has quit [Ping timeout: 258 seconds] 22:52 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 23:09 < gmaxwell> dcousens: that is a minor amplification attack. 23:09 < gmaxwell> moreover, no one should be getblocking you for things you can't serve. 23:10 < dcousens> gmaxwell: my use case is a separate index that wants to catch up to a pruning local bitcoind 23:11 < dcousens> in no way would I intend for that RPC to be public 23:12 < dcousens> (context: https://github.com/bitcoinjs/indexd/issues/6) 23:16 < sipa> dcousens: i think that will be easy to support after we have lightweight mode (which will require that the wallet can also ask for a block to be downloaded) 23:17 < sipa> concept ack, but it may be far out 23:41 < dcousens> sipa: fair enough :), so many other things to fix first, and data duplication isn't that bad in the mean time. Users could still run pruned nodes, they simply have to do it *after* the initial sync 23:41 < dcousens> aka, could use the pruning RPC 23:43 < gmaxwell> dcousens: then you want manual pruning, no 23:44 < dcousens> gmaxwell: well, its not ideal, but it works - unless the `indexd` db is lost, then you need to reset both. 23:45 < dcousens> I think some of the bigger deployments for `indexd` this are either imaging monthly anyway, so they run the pruning about that length 23:47 -!- whphhg [~whphhg@unaffiliated/whphhg] has quit [Quit: Leaving] 23:53 -!- whphhg [~whphhg@unaffiliated/whphhg] has joined #bitcoin-core-dev