12017-11-01T00:04:51  *** dff_ has joined #bitcoin-core-dev
  22017-11-01T00:06:20  *** Deacydal has joined #bitcoin-core-dev
  32017-11-01T00:08:19  *** dff has quit IRC
  42017-11-01T00:22:50  *** Deacydal has quit IRC
  52017-11-01T00:22:50  *** Deacyde has quit IRC
  62017-11-01T00:26:47  *** Chris_Stewart_5 has quit IRC
  72017-11-01T00:38:21  *** chj has joined #bitcoin-core-dev
  82017-11-01T00:57:24  *** dabura667 has joined #bitcoin-core-dev
  92017-11-01T01:09:20  *** quantbot has joined #bitcoin-core-dev
 102017-11-01T01:14:02  *** quantbot has quit IRC
 112017-11-01T01:50:35  *** chj has quit IRC
 122017-11-01T01:56:17  *** Aaronvan_ has quit IRC
 132017-11-01T01:56:41  *** MrPaz has joined #bitcoin-core-dev
 142017-11-01T01:56:53  *** AaronvanW has joined #bitcoin-core-dev
 152017-11-01T02:00:57  *** AaronvanW has quit IRC
 162017-11-01T02:14:16  *** PaulCape_ has quit IRC
 172017-11-01T02:14:41  *** PaulCapestany has joined #bitcoin-core-dev
 182017-11-01T02:54:51  *** meshcollider has quit IRC
 192017-11-01T03:04:13  *** Deacyde has joined #bitcoin-core-dev
 202017-11-01T03:07:16  *** AaronvanW has joined #bitcoin-core-dev
 212017-11-01T03:10:18  *** quantbot has joined #bitcoin-core-dev
 222017-11-01T03:11:28  *** AaronvanW has quit IRC
 232017-11-01T03:14:35  *** quantbot has quit IRC
 242017-11-01T03:25:56  <earlz> jonasschnelli: not sure how to compile bitcoin-qt to be dynamically linked without building it on device.. and building on device would take days if it's even possible. I got a compiler error that the ARM compiler wasn't supported for building Qt through gitian, so guess I'm just out of luck on it
 252017-11-01T03:36:56  *** Giszmo has quit IRC
 262017-11-01T03:46:36  *** grio has joined #bitcoin-core-dev
 272017-11-01T03:49:47  *** jtimon has joined #bitcoin-core-dev
 282017-11-01T04:09:18  <jonasschnelli> earlz: Indeed. ARM & QT is a large rabbit hole...
 292017-11-01T04:10:42  <luke-jr> why? :/
 302017-11-01T04:11:30  <luke-jr> should be strictly easier than Windows/Mac
 312017-11-01T04:11:48  <luke-jr> unless you're trying to do an Android/iOS build or something
 322017-11-01T04:23:38  *** MrPaz has quit IRC
 332017-11-01T04:29:21  *** Deacydal has joined #bitcoin-core-dev
 342017-11-01T04:30:18  *** Deacyde has quit IRC
 352017-11-01T04:33:05  <earlz> I'm focused on raspberry pi specifically
 362017-11-01T04:33:27  <earlz> but I'd like to do it all cross-compile, not on device
 372017-11-01T04:33:53  <earlz> But unsure how to get gitian or the depends system to cooperate with that
 382017-11-01T04:56:56  *** LumberCartel has joined #bitcoin-core-dev
 392017-11-01T05:08:02  *** AaronvanW has joined #bitcoin-core-dev
 402017-11-01T05:09:28  *** meshcollider has joined #bitcoin-core-dev
 412017-11-01T05:11:09  *** quantbot has joined #bitcoin-core-dev
 422017-11-01T05:12:35  *** AaronvanW has quit IRC
 432017-11-01T05:16:18  *** quantbot has quit IRC
 442017-11-01T06:00:57  *** dermoth has joined #bitcoin-core-dev
 452017-11-01T06:05:17  *** AaronvanW has joined #bitcoin-core-dev
 462017-11-01T06:22:23  *** AaronvanW has quit IRC
 472017-11-01T06:34:44  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #11590: [Wallet] always show help-line of wallet encryption calls (master...2017/10/enc_wallet_help) https://github.com/bitcoin/bitcoin/pull/11590
 482017-11-01T07:12:13  *** quantbot has joined #bitcoin-core-dev
 492017-11-01T07:16:17  *** quantbot has quit IRC
 502017-11-01T07:19:51  *** MrPaz has joined #bitcoin-core-dev
 512017-11-01T07:24:35  *** MrPaz has quit IRC
 522017-11-01T07:45:44  *** riemann has joined #bitcoin-core-dev
 532017-11-01T07:45:55  *** AaronvanW has joined #bitcoin-core-dev
 542017-11-01T07:49:11  *** AaronvanW has quit IRC
 552017-11-01T07:49:47  *** AaronvanW has joined #bitcoin-core-dev
 562017-11-01T07:54:07  *** AaronvanW has quit IRC
 572017-11-01T07:58:23  <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
 582017-11-01T07:58:44  <wumpus> so it would be pretty pointless to distrubute them
 592017-11-01T07:59:29  <wumpus> with your own cross-compile environment you can certainly build bitcoin-qt for ARM
 602017-11-01T07:59:59  <wumpus> but it's quite specifific to the device
 612017-11-01T08:01:06  <wumpus> or at least what libraries and versions and such are in its buildroot
 622017-11-01T08:02:16  *** wordsToL_ has joined #bitcoin-core-dev
 632017-11-01T08:02:21  *** wordsToLiveBy has quit IRC
 642017-11-01T08:02:49  <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
 652017-11-01T08:04:48  <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
 662017-11-01T08:13:21  *** owowo has quit IRC
 672017-11-01T08:14:12  *** owowo has joined #bitcoin-core-dev
 682017-11-01T08:24:33  *** zach__ has joined #bitcoin-core-dev
 692017-11-01T08:28:37  *** str4d has joined #bitcoin-core-dev
 702017-11-01T08:36:37  <luke-jr> wumpus: ideally you'd build against some minimum required Qt.. Qt is good about backward binary compat, IIRC
 712017-11-01T08:46:29  *** dermoth has quit IRC
 722017-11-01T08:46:52  *** dermoth has joined #bitcoin-core-dev
 732017-11-01T08:51:12  *** riemann has quit IRC
 742017-11-01T08:53:39  *** BGL has quit IRC
 752017-11-01T09:13:06  *** quantbot has joined #bitcoin-core-dev
 762017-11-01T09:17:53  *** quantbot has quit IRC
 772017-11-01T09:19:50  <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...
 782017-11-01T09:20:42  <jouke> win 32
 792017-11-01T09:20:45  <wumpus> could bulid dynamically against the first sane version of qt5. We used to do something like that for qt4 IIRC
 802017-11-01T09:26:53  *** AaronvanW has joined #bitcoin-core-dev
 812017-11-01T09:31:01  *** AaronvanW has quit IRC
 822017-11-01T09:37:34  *** berndj has quit IRC
 832017-11-01T09:39:16  <luke-jr> wumpus: this would fix the Ubuntu issues as well, perhaps
 842017-11-01T09:39:43  <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
 852017-11-01T09:42:36  <wumpus> I remember there was a good reason we switched to statically linking qt, there were qt incompatiblity issues on some platforms
 862017-11-01T09:43:01  <wumpus> I think there was at least some security feature on one distro that affected qt's binary compatiblity
 872017-11-01T09:44:13  <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)
 882017-11-01T09:46:58  <luke-jr> the latter is better IMO
 892017-11-01T09:47:03  <wumpus> and it becomes even more involved when embedded development of any form is involved.
 902017-11-01T09:47:24  <luke-jr> at least with that approach, users can choose between using the bundled libs or using the system ones
 912017-11-01T09:47:45  <wumpus> linux is an operating system where things are built from source, either by the user themselves or their distro/buildroot
 922017-11-01T09:48:24  *** ula has joined #bitcoin-core-dev
 932017-11-01T09:48:36  <wumpus> distributing binaries for linux is really a no-go, and so is trying to provide any one-size-fits-all linux cross target
 942017-11-01T09:48:47  <luke-jr> dunno, for Android and iOS it might be possible
 952017-11-01T09:48:48  <wumpus> our current hacks work pretty well given that
 962017-11-01T09:49:27  <wumpus> yes, I don't consider android or iOS 'linux' for this intent. THey have heavily standardized API specifications.
 972017-11-01T09:49:46  <luke-jr> ABCore is nice, but loses the whole GUI :P
 982017-11-01T09:49:56  <wumpus> for 'open' linux there's just too much drift
 992017-11-01T09:50:05  <wumpus> too much custom patching
1002017-11-01T09:50:07  <wumpus> and so on
1012017-11-01T09:50:28  <wumpus> which is good for freedom but not for binary software :-) (which could be considered a feature in some regards)
1022017-11-01T09:51:04  <wumpus> yeah, user expectation wise qt isn't that suited to building android GUIs
1032017-11-01T09:51:22  <wumpus> bitcoin-qt's gui would be kind of weird on a mobile device
1042017-11-01T09:51:24  <luke-jr> the Qt example in Play store didn't seem that bad :P
1052017-11-01T09:51:36  <wumpus> probably the fancy qml qt5 stuff?
1062017-11-01T09:51:43  <wumpus> not 'widgets' that we use
1072017-11-01T09:51:45  <luke-jr> dunno, does QML not use the same code as normal GUI?
1082017-11-01T09:51:55  <wumpus> no, it's completely different
1092017-11-01T09:51:57  <luke-jr> I would have expected QML was just an interface to widgets
1102017-11-01T09:51:59  <luke-jr> that sucks
1112017-11-01T09:52:10  * luke-jr misses TrollTech
1122017-11-01T09:53:01  <wumpus> qml is a graphics markup language, a kind of 2D scene graph, with lots of plugins for animation, video, audio, touch gestures, etc
1132017-11-01T09:53:22  <luke-jr> I thought it did widgets too
1142017-11-01T09:53:24  <wumpus> its' erally different from widgets which is aimed at old-style GUIs (say, desktop spreadsheets)
1152017-11-01T09:53:56  <wumpus> going to QML would be a complete redesign of the GUI
1162017-11-01T09:54:06  <luke-jr> Widgets don't look native on Android?
1172017-11-01T09:54:23  <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
1182017-11-01T09:54:26  *** BGL has joined #bitcoin-core-dev
1192017-11-01T09:54:36  <luke-jr> .. ironic coming from the original GUI dev :P
1202017-11-01T09:54:50  <luke-jr> but tbh, I probably wouldn't want to change to QML
1212017-11-01T09:54:57  <luke-jr> I prefer doing the entire GUI in code
1222017-11-01T09:55:00  <wumpus> I come from opengl driver dev, rendering backends, not frontends :p
1232017-11-01T09:55:27  <luke-jr> sure, I just meant that you wrote bitcoin-qt entirely yourself
1242017-11-01T09:55:32  <luke-jr> initially
1252017-11-01T09:55:45  <wumpus> oh sure I've used qt a lot in the past, mostly for tooling
1262017-11-01T09:56:03  <wumpus> that's old-style GUIs though, I meant I don't get QML
1272017-11-01T09:56:23  <luke-jr> old-style GUIs ftw
1282017-11-01T09:57:46  <wumpus> I agree (but we're a dying breed)
1292017-11-01T09:59:40  <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
1302017-11-01T10:00:00  <luke-jr> that's disappointing to hear
1312017-11-01T10:01:22  *** jtimon has quit IRC
1322017-11-01T10:02: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
1332017-11-01T10:02:49  *** riemann has joined #bitcoin-core-dev
1342017-11-01T10:14:24  *** shesek has quit IRC
1352017-11-01T10:16:28  *** riemann has quit IRC
1362017-11-01T10:21:36  *** warxhead has quit IRC
1372017-11-01T10:27:16  *** tevrizci has joined #bitcoin-core-dev
1382017-11-01T10:27:27  <tevrizci> hi
1392017-11-01T10:27:57  *** tevrizci has quit IRC
1402017-11-01T10:28:06  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
1412017-11-01T10:28:06  *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
1422017-11-01T10:28:48  <wumpus> hi
1432017-11-01T10:39:51  *** PaulCapestany has quit IRC
1442017-11-01T10:46:07  *** PaulCape_ has joined #bitcoin-core-dev
1452017-11-01T10:58:56  *** fanquake has joined #bitcoin-core-dev
1462017-11-01T10:59:24  <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
1472017-11-01T10:59:36  <fanquake> wumpus are you still around?
1482017-11-01T11:04:06  *** dabura667 has quit IRC
1492017-11-01T11:04:25  *** dabura667 has joined #bitcoin-core-dev
1502017-11-01T11:14:02  *** quantbot has joined #bitcoin-core-dev
1512017-11-01T11:14:03  <promag> a bit late for the qml chat
1522017-11-01T11:14:26  <promag> > qml is a graphics markup language, a kind of 2D scene graph, with lots of plugins for animation, video, audio, touch gestures, etc
1532017-11-01T11:15:15  <promag> maybe it started in that context, but qml is a declarative language with a javascript engine
1542017-11-01T11:15:55  <promag> it is used in other contexts, for instance, qbs which is the most recent building system
1552017-11-01T11:17:45  <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
1562017-11-01T11:18:57  *** quantbot has quit IRC
1572017-11-01T11:20:40  <luke-jr> promag: I don't see what reimplementing the wallet has to do with splitting it out
1582017-11-01T11:21:45  *** nelruk has joined #bitcoin-core-dev
1592017-11-01T11:26:24  <promag> to change the current wallet from widgets to qtquick would take several PR's (which would sit there for a long time)
1602017-11-01T11:27:04  <promag> dunno if the IPC PR from ryanofsky is going forward
1612017-11-01T11:27:38  <promag> both require lots of changes to the wallet ui code
1622017-11-01T11:28:18  <promag> that's why I think adding IPC to glue a new wallet ui is probably easier
1632017-11-01T11:29:12  <promag> we could have both bitcoin-qt and bitcoin-quick and later drop support for the first
1642017-11-01T11:29:42  <promag> anyway, moving to qtquick is something IMHO we should plan
1652017-11-01T11:30:01  <luke-jr> why? what are the benefits?
1662017-11-01T11:32:08  <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..
1672017-11-01T11:32:34  <promag> not something we should do for the next release or 2
1682017-11-01T11:32:53  <fanquake> What's the minimum supported qt version?
1692017-11-01T11:32:54  <luke-jr> sounds mostly subjective. C++ Qt code is plenty readable.
1702017-11-01T11:33:01  <promag> qt5
1712017-11-01T11:33:09  <fanquake> 5. what?
1722017-11-01T11:33:14  <fanquake> 5.0
1732017-11-01T11:34:06  <promag> depends which components we plsn to use
1742017-11-01T11:35:31  <fanquake> Anything introduced earlier than 5.2 should be ok to use.
1752017-11-01T11:36:38  <fanquake> That is atleast the minimum for qt, because of an osx hack. Although it could be > now.
1762017-11-01T11:36:56  <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
1772017-11-01T11:38:32  <fanquake> promag do you have a good open source project that's using it as an example to look at?
1782017-11-01T11:39:35  <promag> mine no, I can point to some products that were using native code and moved to qtquick
1792017-11-01T11:40:17  <promag> qt has a lot of sample code
1802017-11-01T11:42:14  <luke-jr> I'm not sure embedding a JS engine in a wallet is a good idea :/
1812017-11-01T11:44:48  <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
1822017-11-01T11:45:11  <luke-jr> hmm
1832017-11-01T11:45:18  <promag> luke-jr: why? overhead or security
1842017-11-01T11:45:30  <luke-jr> security mainly
1852017-11-01T11:45:45  <luke-jr> overhead may be a consideration for mobile too, I guess
1862017-11-01T11:46:16  <luke-jr> otoh, if we're refactoring, we can isolate the GUI from the wallet itself, so maybe less of an issue
1872017-11-01T11:46:51  <promag> right
1882017-11-01T11:47:37  <luke-jr> but not a non-issue either, since the GUI obviously needs to be able to make transactions
1892017-11-01T11:47:45  *** pergaminho has joined #bitcoin-core-dev
1902017-11-01T11:48:52  <promag> anyway, I could write a prototype if it's something we all agree on seeing
1912017-11-01T11:49:57  <luke-jr> promag: can C++ code contruct the GUI still with QtQuick?
1922017-11-01T11:50:45  *** unholymachine has quit IRC
1932017-11-01T11:51:13  <promag> you can manipulate the "DOM" in c++
1942017-11-01T11:51:27  <promag> but that is pretty ugly on the qml land
1952017-11-01T11:51:57  <luke-jr> I found it convenient to implement policy options in the GUI with format strings
1962017-11-01T11:51:58  <promag> usually you implement the model(s) in c++ and the view(s) in qml
1972017-11-01T11:52:01  *** unholymachine has joined #bitcoin-core-dev
1982017-11-01T11:52:29  <luke-jr> tr("Require transaction fees to be at least %s per kB higher than transactions they are replacing.")
1992017-11-01T11:52:38  <luke-jr> where %s becomes the option control
2002017-11-01T11:53:30  <luke-jr> not sure QML can do anything similar
2012017-11-01T11:53:31  <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
2022017-11-01T11:53:34  <gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
2032017-11-01T11:53:49  <promag> s/we/you
2042017-11-01T11:53:56  <luke-jr> no, that's just inserting stuff
2052017-11-01T11:54:13  <luke-jr> in my case, %s is turning into a spinbox, inputbox, etc
2062017-11-01T11:55:02  <promag> we mean the text to translate has something that is binded to a combobox selection?
2072017-11-01T11:55:12  <promag> err, s/we/you
2082017-11-01T11:55:37  <luke-jr> yes
2092017-11-01T11:55:50  <promag> text: qsTr("File %1 of %2").arg(combobox.selectedText).arg(total)
2102017-11-01T11:55:56  <luke-jr> no :p
2112017-11-01T11:56:14  <luke-jr> the combobox (or whatever type) would literally be inside the string
2122017-11-01T11:56:33  * luke-jr grabs a screenshot
2132017-11-01T11:59:56  <luke-jr> promag: http://luke.dashjr.org/tmp/screenshots/Screenshot_20171101_115900.png
2142017-11-01T12:01:30  <luke-jr> I suppose the trick to do this might be to implement a special widget *for* QML that can do it..
2152017-11-01T12:01:59  <promag> to do what?
2162017-11-01T12:02:32  *** dermoth_ has joined #bitcoin-core-dev
2172017-11-01T12:02:32  *** dermoth has quit IRC
2182017-11-01T12:02:48  *** dermoth_ is now known as dermoth
2192017-11-01T12:03:47  *** Deacydal has quit IRC
2202017-11-01T12:03:48  <promag> everything there can be done with out-of-the-box qtquick, not sure what you mean
2212017-11-01T12:04:03  *** dabura667 has quit IRC
2222017-11-01T12:09:14  <promag> ah, but how do you do that with widgets? horizontal layout with label + combo + label?
2232017-11-01T12:39:04  *** goatpig has joined #bitcoin-core-dev
2242017-11-01T12:39:58  <wumpus> fanquake: yes
2252017-11-01T12:42:01  *** promag has quit IRC
2262017-11-01T12:44:23  <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
2272017-11-01T12:45:00  <wumpus> in addition to javascript just being a terrible language
2282017-11-01T12:45:56  <wumpus> I'd loathe to maintain that or even have to review changes to it
2292017-11-01T12:50:04  <wumpus> but the same argument would hold for e.g. integrating a lua or python scripting engine
2302017-11-01T12:50:18  <wumpus> even though I like those languages :-)
2312017-11-01T12:59:04  <fanquake> wumpus Cool. I think #11442 is ready to go.
2322017-11-01T12:59:06  <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
2332017-11-01T12:59:44  <wumpus> fanquake: yes it is! sorry, lost track of it a bit
2342017-11-01T13:00:14  *** Plus has quit IRC
2352017-11-01T13:01:15  <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.
2362017-11-01T13:01:36  <fanquake> Also need you to glance over #11573 given that you've pretty much maintained our changes to that code.
2372017-11-01T13:01:37  <gribble> https://github.com/bitcoin/bitcoin/issues/11573 | [Util] Update tinyformat.h by fanquake · Pull Request #11573 · bitcoin/bitcoin · GitHub
2382017-11-01T13:02:27  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8335cb478183...e8f3c88133b7
2392017-11-01T13:02:27  <bitcoin-git> bitcoin/master 9d30f54 fanquake: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2
2402017-11-01T13:02:28  <bitcoin-git> bitcoin/master e8f3c88 Wladimir J. van der Laan: Merge #11442: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2...
2412017-11-01T13:03:05  <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
2422017-11-01T13:05:05  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.15: https://github.com/bitcoin/bitcoin/commit/cf18f4289911c657eb876d91dee055db807870ad
2432017-11-01T13:05:06  <bitcoin-git> bitcoin/0.15 cf18f42 fanquake: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2...
2442017-11-01T13:05:33  <fanquake> #11571 is also a trivial merge.
2452017-11-01T13:05:35  <gribble> https://github.com/bitcoin/bitcoin/issues/11571 | Fixed a couple small grammatical errors. by BitsInMyBlood · Pull Request #11571 · bitcoin/bitcoin · GitHub
2462017-11-01T13:05:54  *** promag has joined #bitcoin-core-dev
2472017-11-01T13:06:48  <wumpus> hah the compiler checks for // Falls through comments now?
2482017-11-01T13:06:50  *** promag has quit IRC
2492017-11-01T13:07:17  <fanquake> wumpus good explainer here https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
2502017-11-01T13:07:42  <wumpus> fanquake: thanks
2512017-11-01T13:07:59  <wumpus> anyhow the change looks obviously ok, just adds sanity checking
2522017-11-01T13:09:47  <fanquake> #11565 is also ready to go.
2532017-11-01T13:09:49  <gribble> https://github.com/bitcoin/bitcoin/issues/11565 | Make listsinceblock refuse unknown block hash by ryanofsky · Pull Request #11565 · bitcoin/bitcoin · GitHub
2542017-11-01T13:10:56  <wumpus> ah so gcc added recognition of fallthrough comments, as placeholder for in c++17 we get an explicit [[fallthrough]] marker
2552017-11-01T13:10:59  *** quantbot has joined #bitcoin-core-dev
2562017-11-01T13:10:59  *** cryptapus has quit IRC
2572017-11-01T13:11:01  <wumpus> makes sense
2582017-11-01T13:11:29  *** quantbot has quit IRC
2592017-11-01T13:11:55  *** quantbot has joined #bitcoin-core-dev
2602017-11-01T13:12:41  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e8f3c88133b7...2631d55f61cd
2612017-11-01T13:12:41  <bitcoin-git> bitcoin/master 60b98f8 fanquake: [Util] Update tinyformat.h...
2622017-11-01T13:12:42  <bitcoin-git> bitcoin/master 2631d55 Wladimir J. van der Laan: Merge #11573: [Util] Update tinyformat.h...
2632017-11-01T13:13:19  <bitcoin-git> [bitcoin] laanwj closed pull request #11573: [Util] Update tinyformat.h (master...pull-upstream-tinyformat) https://github.com/bitcoin/bitcoin/pull/11573
2642017-11-01T13:13:20  *** cryptapus has joined #bitcoin-core-dev
2652017-11-01T13:13:20  *** cryptapus has joined #bitcoin-core-dev
2662017-11-01T13:13:54  <bitcoin-git> [bitcoin] laanwj closed pull request #11565: Make listsinceblock refuse unknown block hash (master...pr/since) https://github.com/bitcoin/bitcoin/pull/11565
2672017-11-01T13:16:21  <fanquake> #11550 Is also mergeable, unless there are some more backports to be added. A new PR can always be opened later anyways.
2682017-11-01T13:16:23  <gribble> https://github.com/bitcoin/bitcoin/issues/11550 | [0.15.1] qa: Backports by MarcoFalke · Pull Request #11550 · bitcoin/bitcoin · GitHub
2692017-11-01T13:16:48  <wumpus> I was confused about 0.15.1 versus 0.15.0.2 there
2702017-11-01T13:17:13  <fanquake> Should it make a difference if it's ending up in the 0.15 branch?
2712017-11-01T13:17:15  <wumpus> so if they are 0.15.1 backports they shouldn't go in yet
2722017-11-01T13:17:25  <bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.15: https://github.com/bitcoin/bitcoin/commit/7d4546f17dca84928bd2b6d1e2588b673c237321
2732017-11-01T13:17:25  <bitcoin-git> bitcoin/0.15 7d4546f Russell Yanofsky: Make listsinceblock refuse unknown block hash...
2742017-11-01T13:17:44  <wumpus> I don't know - usually not, I guess
2752017-11-01T13:17:53  <wumpus> unless it's segwit wallet functionality then it shoudl be held up
2762017-11-01T13:19:30  <fanquake> wumpus yea ok, it can wait then.
2772017-11-01T13:20:10  <wumpus> it's just testing stuff so as it passes it can get in already
2782017-11-01T13:20:37  <fanquake> Don't think it will create any rebase issues either
2792017-11-01T13:20:55  <wumpus> if anything it makes rebasing easier by making 0.15 more like master :)
2802017-11-01T13:22:04  <bitcoin-git> [bitcoin] laanwj closed pull request #11550: [0.15.1] qa: Backports (0.15...Mf1710-0151qaBackports) https://github.com/bitcoin/bitcoin/pull/11550
2812017-11-01T13:23:03  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e1f6a2a801a0...c95832da87ac
2822017-11-01T13:23:04  <bitcoin-git> bitcoin/master f927ee1 Christian Gentry: Fixed a couple small grammatical errors....
2832017-11-01T13:23:04  <bitcoin-git> bitcoin/master c95832d Wladimir J. van der Laan: Merge #11571: Fixed a couple small grammatical errors....
2842017-11-01T13:23:38  <bitcoin-git> [bitcoin] laanwj closed pull request #11571: Fixed a couple small grammatical errors. (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11571
2852017-11-01T13:24:15  <fanquake> Just checking for anything else that is ready to go.
2862017-11-01T13:24:59  <fanquake> Maybe #11511 , I feel like we are going in circles a bit with the EXIT_CODE stuff though.
2872017-11-01T13:25:01  <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
2882017-11-01T13:25:14  <fanquake> They seem to get added, then removed, then added again.
2892017-11-01T13:25:23  <wumpus> fanquake: yeah same feeling here, it didn't occur to me as terribly relevant
2902017-11-01T13:25:44  <wumpus> but as it has ACKs, I"m fine with merging it
2912017-11-01T13:25:55  <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
2922017-11-01T13:26:48  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c95832da87ac...db2f83ed463b
2932017-11-01T13:26:48  <bitcoin-git> bitcoin/master b296bf1 donaloconnor: Init: Remove redundant exit(EXIT_FAILURE) instances and replace with return false
2942017-11-01T13:26:49  <bitcoin-git> bitcoin/master db2f83e Wladimir J. van der Laan: Merge #11511: [Init] Remove redundant exit(EXIT_FAILURE) instances and replace with return false...
2952017-11-01T13:27:05  <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
2962017-11-01T13:27:24  <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
2972017-11-01T13:32:54  *** Gnof has joined #bitcoin-core-dev
2982017-11-01T13:33:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2992017-11-01T13:35:08  <fanquake> Seems like the windows instructions need updating again already. Should we just be providing instructions for the latest release?
3002017-11-01T13:35:43  <fanquake> Having multiple different sets of instructions just for enabling the same feature seems un-ideal
3012017-11-01T13:36:32  <fanquake> I'm also not a great fan of 11438, seems like it just opens up lots of opportunities for miscompilation
3022017-11-01T13:39:35  <fanquake> Although it has been simplified quite a bit now.
3032017-11-01T13:42:35  <bitcoin-git> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/db2f83ed463b...cffa5ee132f3
3042017-11-01T13:42:36  <bitcoin-git> bitcoin/master 3b4ac43 Matt Corallo: Rewrite p2p-acceptblock in preparation for slight behavior changes...
3052017-11-01T13:42:36  <bitcoin-git> bitcoin/master 3d9c70c Matt Corallo: Stop always storing blocks from whitelisted peers...
3062017-11-01T13:42:37  <bitcoin-git> bitcoin/master 932f118 Matt Corallo: Accept unrequested blocks with work equal to our tip...
3072017-11-01T13:43:06  <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
3082017-11-01T13:50:10  <BlueMatt> yeesh, can I get some postumous acks on that one ^
3092017-11-01T13:54:28  <LumberCartel> That looks like a good idea.
3102017-11-01T13:55:56  <wumpus> fanquake: yeah... tend to agree one maintained way that works is better than 10 different ways different people prefer that work a bit
3112017-11-01T13:56:52  *** aeftimia____ has joined #bitcoin-core-dev
3122017-11-01T14:01:37  <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
3132017-11-01T14:02:09  <wumpus> it's potentially very dangerous
3142017-11-01T14:03:29  <wumpus> but in any case it results in broken executables so itt's a waste of time
3152017-11-01T14:03:32  <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.
3162017-11-01T14:05:27  <wumpus> yes, it is (if it works, please help review the code)
3172017-11-01T14:08:35  *** wordsToL_ has quit IRC
3182017-11-01T14:08:50  *** nelruk has quit IRC
3192017-11-01T14:12:35  *** nelruk has joined #bitcoin-core-dev
3202017-11-01T14:16:39  <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
3212017-11-01T14:20:16  *** nelruk has quit IRC
3222017-11-01T14:21:59  *** nelruk has joined #bitcoin-core-dev
3232017-11-01T14:29:10  *** nelruk has quit IRC
3242017-11-01T14:29:17  *** meshcollider has quit IRC
3252017-11-01T14:30:41  *** nelruk has joined #bitcoin-core-dev
3262017-11-01T14:33:49  *** promag has joined #bitcoin-core-dev
3272017-11-01T14:34:35  *** promag has quit IRC
3282017-11-01T14:42:09  *** Chris_Stewart_5 has quit IRC
3292017-11-01T14:46:02  *** LumberCartel has quit IRC
3302017-11-01T14:46:04  *** d9b4bef9 has quit IRC
3312017-11-01T14:47:10  *** d9b4bef9 has joined #bitcoin-core-dev
3322017-11-01T14:55:09  *** aeftimia____ has quit IRC
3332017-11-01T14:56:43  <xinxi> Will the US regulate Bitcoin development while it’s going to regulate Bitcoin derivatives?
3342017-11-01T14:56:50  <xinxi> What do you guys think?
3352017-11-01T14:57:47  <wumpus> no political discussion here please, use #bitcoin instead
3362017-11-01T14:58:42  *** Guest21 has quit IRC
3372017-11-01T15:06:16  *** d_p has left #bitcoin-core-dev
3382017-11-01T15:14:59  *** fanquake has quit IRC
3392017-11-01T15:16:10  *** LumberCartel has joined #bitcoin-core-dev
3402017-11-01T15:19:04  *** jtimon has joined #bitcoin-core-dev
3412017-11-01T15:25:44  *** MrPaz has joined #bitcoin-core-dev
3422017-11-01T15:25:48  *** laurentmt has joined #bitcoin-core-dev
3432017-11-01T15:26:01  *** SopaXorzTaker has joined #bitcoin-core-dev
3442017-11-01T15:26:34  *** laurentmt has quit IRC
3452017-11-01T15:29:27  *** harrymm has quit IRC
3462017-11-01T15:30:02  *** PaulCape_ has quit IRC
3472017-11-01T15:33:52  *** PaulCapestany has joined #bitcoin-core-dev
3482017-11-01T15:36:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3492017-11-01T15:39:45  *** LumberCartel has quit IRC
3502017-11-01T15:44:53  *** harrymm has joined #bitcoin-core-dev
3512017-11-01T15:53:46  *** laurentmt has joined #bitcoin-core-dev
3522017-11-01T16:02:07  <karelb> is there ETA for 0.15.0.2?
3532017-11-01T16:03:33  <karelb> not exact date, just if it will be this week or before 2x at all etc (yeah I know ETA questions are annoying :))
3542017-11-01T16:07:57  *** jb55 has joined #bitcoin-core-dev
3552017-11-01T16:08:52  *** nelruk has quit IRC
3562017-11-01T16:11:35  <sipa> karelb: "soon"
3572017-11-01T16:11:39  <sdaftuar> cfields: i just commented in #11560 -- i'd like to undo the change to looping on mapNodeState vs ForEachNode
3582017-11-01T16:11:42  <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
3592017-11-01T16:12:07  <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
3602017-11-01T16:16:44  <cfields> sdaftuar: well you'll have to hold cs_vNodes for that to be safe...
3612017-11-01T16:17:04  <sdaftuar> ForEachNode already holds cs_vNodes right?
3622017-11-01T16:17:10  <cfields> or you mean doing the whole thing in ForEachNode ?
3632017-11-01T16:17:29  <sdaftuar> yeah i wanted to undo the change from ForEachNode -> loop on mapNodeState
3642017-11-01T16:17:35  <cfields> do you have the old commit handy?
3652017-11-01T16:17:40  <sdaftuar> yep
3662017-11-01T16:18:08  <sdaftuar> this is the commit that changed it: https://github.com/sdaftuar/bitcoin/commit/be8c4337838b17cc495f657c2f8bd94912e158d3
3672017-11-01T16:18:33  <sdaftuar> unsquashed branch is here: https://github.com/sdaftuar/bitcoin/commits/11560.1
3682017-11-01T16:18:52  <sdaftuar> it occurred to me that maybe i should check that CNodeState is not null in there
3692017-11-01T16:19:05  <sdaftuar> if i'm using ForEachNode i mean
3702017-11-01T16:19:08  <cfields> oh, i see what you mean. I thought you were talking about the _other_ lookup in ForNode below
3712017-11-01T16:19:31  <sdaftuar> ah, no i'm not worried about that, that's just O(n)
3722017-11-01T16:19:38  <sdaftuar> i'm just concerned about the n^2
3732017-11-01T16:22:47  <cfields> yea, ok
3742017-11-01T16:23:04  <sdaftuar> great thanks
3752017-11-01T16:25:46  <cfields> sdaftuar: fwiw, I was hoping to do something like this: https://github.com/theuni/bitcoin/commit/0693ffb8ed386095a27a8ca62a7eacada2e9db04
3762017-11-01T16:26:58  <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.
3772017-11-01T16:27:12  <cfields> so that just leaves the CNodeState checks in that first test
3782017-11-01T16:27:18  <sdaftuar> ah, interesting
3792017-11-01T16:27:44  <sdaftuar> so we'd drop having to look into the cnode at all?
3802017-11-01T16:28:01  * sdaftuar -> lunch
3812017-11-01T16:28:27  <cfields> yea, we'd just connman->Disconnect(id)
3822017-11-01T16:30:01  <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.
3832017-11-01T16:30:53  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cffa5ee132f3...1b8c88451b05
3842017-11-01T16:30:53  <bitcoin-git> bitcoin/master 5d465e3 Tomas van der Wansem: Ensure backupwallet fails when attempting to backup to source file...
3852017-11-01T16:30:54  <bitcoin-git> bitcoin/master 1b8c884 MarcoFalke: Merge #11376: Ensure backupwallet fails when attempting to backup to source file...
3862017-11-01T16:31:24  <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
3872017-11-01T16:33:08  <sipa> sdaftuar: were you going to adapt the approach to use an incrementable semaphore instead of a separate bool?
3882017-11-01T16:33:30  <sipa> or rather do that in a post-0.15.0.2 improvement
3892017-11-01T16:48:13  *** pergamo has joined #bitcoin-core-dev
3902017-11-01T16:48:52  *** pergaminho has quit IRC
3912017-11-01T16:50:36  <sdaftuar> sipa: i'm not that familiar with the semaphore implementation so i was going to hold off on that
3922017-11-01T16:51:07  <sipa> okay
3932017-11-01T16:51:13  <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
3942017-11-01T16:51:27  <sdaftuar> i don't feel strongly about that, but that would be a reason in favor of a bool vs incrementable semaphore i think?
3952017-11-01T16:53:27  <sdaftuar> cfields: i'm not following how you could drop the connection time > 30 second check?
3962017-11-01T16:57:01  <sdaftuar> cfields: specifically i had greg's same question about how you avoid disconnecting a peer that you just connected to
3972017-11-01T17:00:34  *** quantbot_ has joined #bitcoin-core-dev
3982017-11-01T17:01:34  *** quantbot_ has joined #bitcoin-core-dev
3992017-11-01T17:04:09  *** quantbot has quit IRC
4002017-11-01T17:05:48  *** dermoth has quit IRC
4012017-11-01T17:07:55  <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
4022017-11-01T17:08:24  <cfields> I was getting ahead of myself, I guess that comment makes no sense without the future changes in mind
4032017-11-01T17:10:38  *** warxhead has joined #bitcoin-core-dev
4042017-11-01T17:10:57  *** stevenroose has quit IRC
4052017-11-01T17:14:10  *** dermoth has joined #bitcoin-core-dev
4062017-11-01T17:15:15  *** stevenroose has joined #bitcoin-core-dev
4072017-11-01T17:23:08  *** jb55 has quit IRC
4082017-11-01T17:27:47  *** xinxi has quit IRC
4092017-11-01T17:28:21  *** xinxi has joined #bitcoin-core-dev
4102017-11-01T17:33:22  *** xinxi has quit IRC
4112017-11-01T17:40:58  *** jb55 has joined #bitcoin-core-dev
4122017-11-01T17:41:06  *** vicenteH has quit IRC
4132017-11-01T17:41:16  *** vicenteH has joined #bitcoin-core-dev
4142017-11-01T17:45:19  *** laurentmt has quit IRC
4152017-11-01T17:48:28  *** xinxi has joined #bitcoin-core-dev
4162017-11-01T17:50:22  *** Chris_Stewart_5 has quit IRC
4172017-11-01T17:52:57  <sipa> BlueMatt: how did the invalidateblock code result in failure for pruned nodes?
4182017-11-01T17:53:08  <sipa> (just trying to understand)
4192017-11-01T17:53:33  <sdaftuar> sipa: i think the issue is if you call invalidateblock on a blockhash that you've pruned
4202017-11-01T17:53:50  <BlueMatt> yea, it'll walk backwards, and set the invalid flag BEFORE disconnecting it
4212017-11-01T17:53:57  <BlueMatt> then when you go to disconnect, you will fail to read from disk and shut down
4222017-11-01T17:54:24  <BlueMatt> (AbortNode, I believe) but now when you start up no block meets the conditions for inclusion in setBlockIndexCandidates
4232017-11-01T17:54:44  <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
4242017-11-01T17:55:10  <BlueMatt> so you hit the !setBlockIndexCandidates.empty() assert
4252017-11-01T17:55:15  *** jb55 has quit IRC
4262017-11-01T17:55:45  <sipa> BlueMatt: i see!
4272017-11-01T17:55:54  *** jb55 has joined #bitcoin-core-dev
4282017-11-01T17:56:05  <sipa> would there be a problem with marking the blocks invalid after disconnecting them, but one by one?
4292017-11-01T17:56:12  <sipa> as opposed to after the whole invalidated
4302017-11-01T17:56:14  <sipa> brb, meeting
4312017-11-01T17:57:22  <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
4322017-11-01T17:57:28  <BlueMatt> it might, however, very likely not actually break anything
4332017-11-01T17:57:54  <BlueMatt> still, I *really* didnt want to try to think through that in the context of the g_failed_blocks stuff
4342017-11-01T17:57:56  <sipa> anyone, no objection to the change that was merged
4352017-11-01T17:58:03  <sipa> *anyway
4362017-11-01T17:58:47  <BlueMatt> I take that back, CheckBlockIndex does *not* verify this, but, again, its nonsense
4372017-11-01T18:00:28  *** quantbot_ has quit IRC
4382017-11-01T18:00:54  *** quantbot has joined #bitcoin-core-dev
4392017-11-01T18:03:34  *** Giszmo has joined #bitcoin-core-dev
4402017-11-01T18:05:32  *** quantbot has quit IRC
4412017-11-01T18:13:34  *** davec has quit IRC
4422017-11-01T18:14:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4432017-11-01T18:15:31  *** davec has joined #bitcoin-core-dev
4442017-11-01T18:19:27  *** BGL has quit IRC
4452017-11-01T18:19:57  *** quantbot has joined #bitcoin-core-dev
4462017-11-01T18:20:05  *** xinxi has quit IRC
4472017-11-01T18:20:17  *** Chris_Stewart_5 has quit IRC
4482017-11-01T18:20:38  *** xinxi has joined #bitcoin-core-dev
4492017-11-01T18:27:07  *** xinxi has quit IRC
4502017-11-01T18:30:10  *** meshcollider has joined #bitcoin-core-dev
4512017-11-01T18:39:58  *** harrymm has quit IRC
4522017-11-01T18:42:43  *** harrymm has joined #bitcoin-core-dev
4532017-11-01T19:06:55  <sipa> BlueMatt: i've for a while regretted the choice of having validity flags inside the block index
4542017-11-01T19:07:12  <BlueMatt> I mean they are a pretty separate concept
4552017-11-01T19:07:12  <sipa> your PR makes me wonder if we couldn't get rid of them entirely
4562017-11-01T19:07:21  <sipa> valid = chainActive
4572017-11-01T19:07:22  <BlueMatt> I mean we have to have them somewhere
4582017-11-01T19:07:29  <sipa> invalid = in g_failed_blocks
4592017-11-01T19:07:33  <BlueMatt> no, we need a concept of "descends from invalid"
4602017-11-01T19:07:58  <BlueMatt> I mean that kinda sucks cause it grows unbounded
4612017-11-01T19:08:02  <BlueMatt> though not the end of the world, I suppose
4622017-11-01T19:08:13  <sipa> it's at most a constant factor larger than mapBlockIndex itself
4632017-11-01T19:08:17  <sipa> a very small constant factor
4642017-11-01T19:08:23  <gmaxwell> how would thing like invalidateblock / reconsider block work?  or pipelined validation with multiple stages of verification?
4652017-11-01T19:08:23  <sdaftuar> yes but it slows down acceptblockheader
4662017-11-01T19:08:39  <sdaftuar> you wouldn't want to iterate mapBlockindex just to accept a new header
4672017-11-01T19:09:34  <sipa> right, you want some form of 'caching' of invalid descendants
4682017-11-01T19:09:42  <sipa> but perhaps that doesn't need to be mapBlockIndex
4692017-11-01T19:10:08  <sipa> anyway, just a wild idea
4702017-11-01T19:10:35  <gmaxwell> it is kind of silly to have an extra field for something that is almost always just in a single state.
4712017-11-01T19:11:31  <BlueMatt> yea, I mean it is true that we barely use nStatus for anything except for HAVE_DATA
4722017-11-01T19:11:46  <sipa> and it doesn't even cover the whole thing
4732017-11-01T19:11:47  <BlueMatt> (which I guess is implied by the diskpos thing)
4742017-11-01T19:12:00  <sipa> we use nChainTx as indicator for "all parent blocks downloaded"
4752017-11-01T19:12:48  *** quantbot_ has joined #bitcoin-core-dev
4762017-11-01T19:13:01  *** quantbot has quit IRC
4772017-11-01T19:13:08  <BlueMatt> yea, I mean we do need VALID_SCRIPTS for net_processing :/
4782017-11-01T19:13:18  <BlueMatt> cause we're not allowed to send stuff unless its VALID_SCRIPTS
4792017-11-01T19:14:15  *** quantbot has joined #bitcoin-core-dev
4802017-11-01T19:15:27  *** str4d has quit IRC
4812017-11-01T19:17:01  *** quantbot_ has quit IRC
4822017-11-01T19:20:38  *** str4d has joined #bitcoin-core-dev
4832017-11-01T19:25:19  *** BGL has joined #bitcoin-core-dev
4842017-11-01T19:31:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4852017-11-01T19:32:37  *** SopaXorzTaker has quit IRC
4862017-11-01T19:48:33  *** Deacyde has joined #bitcoin-core-dev
4872017-11-01T20:03:10  *** PaulCapestany has quit IRC
4882017-11-01T20:06:28  *** Chris_Stewart_5 has quit IRC
4892017-11-01T20:09:05  *** PaulCapestany has joined #bitcoin-core-dev
4902017-11-01T20:24:00  <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
4912017-11-01T20:39:49  *** promag has joined #bitcoin-core-dev
4922017-11-01T20:42:45  *** Cheeseo has joined #bitcoin-core-dev
4932017-11-01T20:47:41  *** zi0nman has joined #bitcoin-core-dev
4942017-11-01T20:48:04  <BlueMatt> cfields: travis failed on ^ (libevent in the travis os is 2.0, looks like, which does not have the getcb function)
4952017-11-01T20:48:06  <BlueMatt> only 2.1 has it
4962017-11-01T20:48:34  <cfields> ugh
4972017-11-01T20:49:08  <cfields> ok, working on it
4982017-11-01T21:10:23  *** zi0nman has quit IRC
4992017-11-01T21:12:47  <MarcoFalke> wumpus: cfields: I was trying to prepare the 0.15.0.2 release but I am stuck at deciding whether to backport #10756.
5002017-11-01T21:12:49  <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
5012017-11-01T21:13:06  <MarcoFalke> some of the commits depend on it
5022017-11-01T21:13:35  <MarcoFalke> It might be shorter (with regard to LOC) to solve the merge conflicts manually
5032017-11-01T21:13:47  <MarcoFalke> But I'd wanted to see what you prefer
5042017-11-01T21:16:40  <cfields> MarcoFalke: i don't think that should be needed. What are the conflicts?
5052017-11-01T21:17:59  <MarcoFalke> In function ‘bool SendMessages(CNode*, CConnman&, const std::atomic<bool>&)’: error: ‘ConsiderEviction’ was not declared in this scope
5062017-11-01T21:20:27  <cfields> ah right, new members
5072017-11-01T21:20:29  <cfields> sec
5082017-11-01T21:22:52  *** PaulCapestany has quit IRC
5092017-11-01T21:23:28  <cfields> MarcoFalke: blah, backporting 10756 may be easier, as more and more commits build on it
5102017-11-01T21:24:02  *** PaulCape_ has joined #bitcoin-core-dev
5112017-11-01T21:24:27  <cfields> MarcoFalke: it's either that, or break the new functions (like ConsiderEviction) global/static, and pass in the CConnman pointer
5122017-11-01T21:24:39  <MarcoFalke> Jup, figured that
5132017-11-01T21:27:27  <MarcoFalke> Since the not-yet-merged #11560 also needs it, I will try to cherry-pick your refactoring commits
5142017-11-01T21:27:29  <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
5152017-11-01T21:35:00  <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
5162017-11-01T21:35:00  <ghost43> has to have a height of nLockTime+1?
5172017-11-01T21:43:38  *** Cheeseo has quit IRC
5182017-11-01T21:49:17  *** RoyceX has joined #bitcoin-core-dev
5192017-11-01T21:54:24  <cfields> BlueMatt: pushed a new version that mimics the upstream fix
5202017-11-01T21:58:14  <BlueMatt> thanks! will review in a few minutes
5212017-11-01T22:00:01  *** jb55 has quit IRC
5222017-11-01T22:00:58  *** jb55 has joined #bitcoin-core-dev
5232017-11-01T22:07:21  *** Cogito_Ergo_Sum has quit IRC
5242017-11-01T22:16:44  *** goatpig has quit IRC
5252017-11-01T22:28:16  *** jtimon has quit IRC
5262017-11-01T22:42:48  *** goatpig has joined #bitcoin-core-dev
5272017-11-01T23:13:02  *** mlz has quit IRC
5282017-11-01T23:16:46  *** shesek has joined #bitcoin-core-dev
5292017-11-01T23:16:46  *** shesek has joined #bitcoin-core-dev
5302017-11-01T23:19:22  *** RoyceX has quit IRC
5312017-11-01T23:28:05  *** promag has joined #bitcoin-core-dev
5322017-11-01T23:39:35  *** molly has joined #bitcoin-core-dev
5332017-11-01T23:53:09  *** molly has quit IRC