1 2017-11-01 03:25:56	0|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
  2 2017-11-01 04:09:19	0|jonasschnelli|earlz: Indeed. ARM & QT is a large rabbit hole...
  3 2017-11-01 04:10:43	0|luke-jr|why? :/
  4 2017-11-01 04:11:31	0|luke-jr|should be strictly easier than Windows/Mac
  5 2017-11-01 04:11:49	0|luke-jr|unless you're trying to do an Android/iOS build or something
  6 2017-11-01 04:33:06	0|earlz|I'm focused on raspberry pi specifically
  7 2017-11-01 04:33:28	0|earlz|but I'd like to do it all cross-compile, not on device
  8 2017-11-01 04:33:54	0|earlz|But unsure how to get gitian or the depends system to cooperate with that
  9 2017-11-01 06:34:45	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #11590: [Wallet] always show help-line of wallet encryption calls (06master...062017/10/enc_wallet_help) 02https://github.com/bitcoin/bitcoin/pull/11590
 10 2017-11-01 07:58:24	0|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
 11 2017-11-01 07:58:44	0|wumpus|so it would be pretty pointless to distrubute them
 12 2017-11-01 07:59:30	0|wumpus|with your own cross-compile environment you can certainly build bitcoin-qt for ARM
 13 2017-11-01 07:59:59	0|wumpus|but it's quite specifific to the device
 14 2017-11-01 08:01:07	0|wumpus|or at least what libraries and versions and such are in its buildroot
 15 2017-11-01 08:02:50	0|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
 16 2017-11-01 08:04:49	0|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
 17 2017-11-01 08:36:38	0|luke-jr|wumpus: ideally you'd build against some minimum required Qt.. Qt is good about backward binary compat, IIRC
 18 2017-11-01 09:19:51	0|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...
 19 2017-11-01 09:20:43	0|jouke|win 32
 20 2017-11-01 09:20:46	0|wumpus|could bulid dynamically against the first sane version of qt5. We used to do something like that for qt4 IIRC
 21 2017-11-01 09:39:17	0|luke-jr|wumpus: this would fix the Ubuntu issues as well, perhaps
 22 2017-11-01 09:39:44	0|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
 23 2017-11-01 09:42:37	0|wumpus|I remember there was a good reason we switched to statically linking qt, there were qt incompatiblity issues on some platforms
 24 2017-11-01 09:43:01	0|wumpus|I think there was at least some security feature on one distro that affected qt's binary compatiblity
 25 2017-11-01 09:44:13	0|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)
 26 2017-11-01 09:46:59	0|luke-jr|the latter is better IMO
 27 2017-11-01 09:47:04	0|wumpus|and it becomes even more involved when embedded development of any form is involved.
 28 2017-11-01 09:47:25	0|luke-jr|at least with that approach, users can choose between using the bundled libs or using the system ones
 29 2017-11-01 09:47:45	0|wumpus|linux is an operating system where things are built from source, either by the user themselves or their distro/buildroot
 30 2017-11-01 09:48:37	0|wumpus|distributing binaries for linux is really a no-go, and so is trying to provide any one-size-fits-all linux cross target
 31 2017-11-01 09:48:48	0|luke-jr|dunno, for Android and iOS it might be possible
 32 2017-11-01 09:48:49	0|wumpus|our current hacks work pretty well given that
 33 2017-11-01 09:49:27	0|wumpus|yes, I don't consider android or iOS 'linux' for this intent. THey have heavily standardized API specifications.
 34 2017-11-01 09:49:47	0|luke-jr|ABCore is nice, but loses the whole GUI :P
 35 2017-11-01 09:49:57	0|wumpus|for 'open' linux there's just too much drift
 36 2017-11-01 09:50:06	0|wumpus|too much custom patching
 37 2017-11-01 09:50:08	0|wumpus|and so on
 38 2017-11-01 09:50:29	0|wumpus|which is good for freedom but not for binary software :-) (which could be considered a feature in some regards)
 39 2017-11-01 09:51:05	0|wumpus|yeah, user expectation wise qt isn't that suited to building android GUIs
 40 2017-11-01 09:51:23	0|wumpus|bitcoin-qt's gui would be kind of weird on a mobile device
 41 2017-11-01 09:51:25	0|luke-jr|the Qt example in Play store didn't seem that bad :P
 42 2017-11-01 09:51:37	0|wumpus|probably the fancy qml qt5 stuff?
 43 2017-11-01 09:51:44	0|wumpus|not 'widgets' that we use
 44 2017-11-01 09:51:46	0|luke-jr|dunno, does QML not use the same code as normal GUI?
 45 2017-11-01 09:51:56	0|wumpus|no, it's completely different
 46 2017-11-01 09:51:58	0|luke-jr|I would have expected QML was just an interface to widgets
 47 2017-11-01 09:52:00	0|luke-jr|that sucks
 48 2017-11-01 09:53:02	0|wumpus|qml is a graphics markup language, a kind of 2D scene graph, with lots of plugins for animation, video, audio, touch gestures, etc
 49 2017-11-01 09:53:23	0|luke-jr|I thought it did widgets too
 50 2017-11-01 09:53:25	0|wumpus|its' erally different from widgets which is aimed at old-style GUIs (say, desktop spreadsheets)
 51 2017-11-01 09:53:56	0|wumpus|going to QML would be a complete redesign of the GUI
 52 2017-11-01 09:54:07	0|luke-jr|Widgets don't look native on Android?
 53 2017-11-01 09:54:23	0|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
 54 2017-11-01 09:54:37	0|luke-jr|.. ironic coming from the original GUI dev :P
 55 2017-11-01 09:54:51	0|luke-jr|but tbh, I probably wouldn't want to change to QML
 56 2017-11-01 09:54:58	0|luke-jr|I prefer doing the entire GUI in code
 57 2017-11-01 09:55:01	0|wumpus|I come from opengl driver dev, rendering backends, not frontends :p
 58 2017-11-01 09:55:28	0|luke-jr|sure, I just meant that you wrote bitcoin-qt entirely yourself
 59 2017-11-01 09:55:33	0|luke-jr|initially
 60 2017-11-01 09:55:46	0|wumpus|oh sure I've used qt a lot in the past, mostly for tooling
 61 2017-11-01 09:56:04	0|wumpus|that's old-style GUIs though, I meant I don't get QML
 62 2017-11-01 09:56:24	0|luke-jr|old-style GUIs ftw
 63 2017-11-01 09:57:47	0|wumpus|I agree (but we're a dying breed)
 64 2017-11-01 09:59:41	0|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
 65 2017-11-01 10:00:01	0|luke-jr|that's disappointing to hear
 66 2017-11-01 10:02:03	0|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
 67 2017-11-01 10:27:27	0|tevrizci|hi
 68 2017-11-01 10:28:48	0|wumpus|hi
 69 2017-11-01 10:59:25	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11587: Fix warnings when building with -Wthread-safety-analysis (06master...06–Wthread-safety-analysis) 02https://github.com/bitcoin/bitcoin/pull/11587
 70 2017-11-01 10:59:37	0|fanquake|wumpus are you still around?
 71 2017-11-01 11:14:04	0|promag|a bit late for the qml chat
 72 2017-11-01 11:14:27	0|promag|> qml is a graphics markup language, a kind of 2D scene graph, with lots of plugins for animation, video, audio, touch gestures, etc
 73 2017-11-01 11:15:16	0|promag|maybe it started in that context, but qml is a declarative language with a javascript engine
 74 2017-11-01 11:15:56	0|promag|it is used in other contexts, for instance, qbs which is the most recent building system
 75 2017-11-01 11:17:46	0|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
 76 2017-11-01 11:20:41	0|luke-jr|promag: I don't see what reimplementing the wallet has to do with splitting it out
 77 2017-11-01 11:26:25	0|promag|to change the current wallet from widgets to qtquick would take several PR's (which would sit there for a long time)
 78 2017-11-01 11:27:05	0|promag|dunno if the IPC PR from ryanofsky is going forward
 79 2017-11-01 11:27:39	0|promag|both require lots of changes to the wallet ui code
 80 2017-11-01 11:28:19	0|promag|that's why I think adding IPC to glue a new wallet ui is probably easier
 81 2017-11-01 11:29:13	0|promag|we could have both bitcoin-qt and bitcoin-quick and later drop support for the first
 82 2017-11-01 11:29:43	0|promag|anyway, moving to qtquick is something IMHO we should plan
 83 2017-11-01 11:30:02	0|luke-jr|why? what are the benefits?
 84 2017-11-01 11:32:09	0|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..
 85 2017-11-01 11:32:35	0|promag|not something we should do for the next release or 2
 86 2017-11-01 11:32:54	0|fanquake|What's the minimum supported qt version?
 87 2017-11-01 11:32:55	0|luke-jr|sounds mostly subjective. C++ Qt code is plenty readable.
 88 2017-11-01 11:33:02	0|promag|qt5
 89 2017-11-01 11:33:10	0|fanquake|5. what?
 90 2017-11-01 11:33:15	0|fanquake|5.0
 91 2017-11-01 11:34:07	0|promag|depends which components we plsn to use
 92 2017-11-01 11:35:32	0|fanquake|Anything introduced earlier than 5.2 should be ok to use.
 93 2017-11-01 11:36:39	0|fanquake|That is atleast the minimum for qt, because of an osx hack. Although it could be > now.
 94 2017-11-01 11:36:57	0|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
 95 2017-11-01 11:38:33	0|fanquake|promag do you have a good open source project that's using it as an example to look at?
 96 2017-11-01 11:39:36	0|promag|mine no, I can point to some products that were using native code and moved to qtquick
 97 2017-11-01 11:40:18	0|promag|qt has a lot of sample code
 98 2017-11-01 11:42:15	0|luke-jr|I'm not sure embedding a JS engine in a wallet is a good idea :/
 99 2017-11-01 11:44:49	0|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
100 2017-11-01 11:45:12	0|luke-jr|hmm
101 2017-11-01 11:45:19	0|promag|luke-jr: why? overhead or security
102 2017-11-01 11:45:31	0|luke-jr|security mainly
103 2017-11-01 11:45:46	0|luke-jr|overhead may be a consideration for mobile too, I guess
104 2017-11-01 11:46:17	0|luke-jr|otoh, if we're refactoring, we can isolate the GUI from the wallet itself, so maybe less of an issue
105 2017-11-01 11:46:52	0|promag|right
106 2017-11-01 11:47:38	0|luke-jr|but not a non-issue either, since the GUI obviously needs to be able to make transactions
107 2017-11-01 11:48:53	0|promag|anyway, I could write a prototype if it's something we all agree on seeing
108 2017-11-01 11:49:58	0|luke-jr|promag: can C++ code contruct the GUI still with QtQuick?
109 2017-11-01 11:51:14	0|promag|you can manipulate the "DOM" in c++
110 2017-11-01 11:51:28	0|promag|but that is pretty ugly on the qml land
111 2017-11-01 11:51:58	0|luke-jr|I found it convenient to implement policy options in the GUI with format strings
112 2017-11-01 11:51:59	0|promag|usually you implement the model(s) in c++ and the view(s) in qml
113 2017-11-01 11:52:29	0|luke-jr|tr("Require transaction fees to be at least %s per kB higher than transactions they are replacing.")
114 2017-11-01 11:52:39	0|luke-jr|where %s becomes the option control
115 2017-11-01 11:53:31	0|luke-jr|not sure QML can do anything similar
116 2017-11-01 11:53:32	0|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
117 2017-11-01 11:53:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format · Issue #4 · bitcoin/bitcoin · GitHub
118 2017-11-01 11:53:50	0|promag|s/we/you
119 2017-11-01 11:53:57	0|luke-jr|no, that's just inserting stuff
120 2017-11-01 11:54:14	0|luke-jr|in my case, %s is turning into a spinbox, inputbox, etc
121 2017-11-01 11:55:03	0|promag|we mean the text to translate has something that is binded to a combobox selection?
122 2017-11-01 11:55:13	0|promag|err, s/we/you
123 2017-11-01 11:55:38	0|luke-jr|yes
124 2017-11-01 11:55:51	0|promag|text: qsTr("File %1 of %2").arg(combobox.selectedText).arg(total)
125 2017-11-01 11:55:57	0|luke-jr|no :p
126 2017-11-01 11:56:15	0|luke-jr|the combobox (or whatever type) would literally be inside the string
127 2017-11-01 11:59:57	0|luke-jr|promag: http://luke.dashjr.org/tmp/screenshots/Screenshot_20171101_115900.png
128 2017-11-01 12:01:31	0|luke-jr|I suppose the trick to do this might be to implement a special widget *for* QML that can do it..
129 2017-11-01 12:02:00	0|promag|to do what?
130 2017-11-01 12:03:49	0|promag|everything there can be done with out-of-the-box qtquick, not sure what you mean
131 2017-11-01 12:09:15	0|promag|ah, but how do you do that with widgets? horizontal layout with label + combo + label?
132 2017-11-01 12:39:59	0|wumpus|fanquake: yes
133 2017-11-01 12:44:24	0|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
134 2017-11-01 12:45:01	0|wumpus|in addition to javascript just being a terrible language
135 2017-11-01 12:45:56	0|wumpus|I'd loathe to maintain that or even have to review changes to it
136 2017-11-01 12:50:05	0|wumpus|but the same argument would hold for e.g. integrating a lua or python scripting engine
137 2017-11-01 12:50:19	0|wumpus|even though I like those languages :-)
138 2017-11-01 12:59:05	0|fanquake|wumpus Cool. I think #11442 is ready to go.
139 2017-11-01 12:59:07	0|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
140 2017-11-01 12:59:44	0|wumpus|fanquake: yes it is! sorry, lost track of it a bit
141 2017-11-01 13:01:16	0|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.
142 2017-11-01 13:01:37	0|fanquake|Also need you to glance over #11573 given that you've pretty much maintained our changes to that code.
143 2017-11-01 13:01:38	0|gribble|https://github.com/bitcoin/bitcoin/issues/11573 | [Util] Update tinyformat.h by fanquake · Pull Request #11573 · bitcoin/bitcoin · GitHub
144 2017-11-01 13:02:28	0|bitcoin-git|13bitcoin/06master 149d30f54 15fanquake: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2
145 2017-11-01 13:02:28	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8335cb478183...e8f3c88133b7
146 2017-11-01 13:02:29	0|bitcoin-git|13bitcoin/06master 14e8f3c88 15Wladimir J. van der Laan: Merge #11442: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2...
147 2017-11-01 13:03:06	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11442: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2 (06master...06openbsd-doc-update) 02https://github.com/bitcoin/bitcoin/pull/11442
148 2017-11-01 13:05:06	0|bitcoin-git|13bitcoin/060.15 14cf18f42 15fanquake: [Docs] Update OpenBSD Build Instructions for OpenBSD 6.2...
149 2017-11-01 13:05:06	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.15: 02https://github.com/bitcoin/bitcoin/commit/cf18f4289911c657eb876d91dee055db807870ad
150 2017-11-01 13:05:34	0|fanquake|#11571 is also a trivial merge.
151 2017-11-01 13:05:36	0|gribble|https://github.com/bitcoin/bitcoin/issues/11571 | Fixed a couple small grammatical errors. by BitsInMyBlood · Pull Request #11571 · bitcoin/bitcoin · GitHub
152 2017-11-01 13:06:49	0|wumpus|hah the compiler checks for // Falls through comments now?
153 2017-11-01 13:07:18	0|fanquake|wumpus good explainer here https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/
154 2017-11-01 13:07:43	0|wumpus|fanquake: thanks
155 2017-11-01 13:08:00	0|wumpus|anyhow the change looks obviously ok, just adds sanity checking
156 2017-11-01 13:09:48	0|fanquake|#11565 is also ready to go.
157 2017-11-01 13:09:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/11565 | Make listsinceblock refuse unknown block hash by ryanofsky · Pull Request #11565 · bitcoin/bitcoin · GitHub
158 2017-11-01 13:10:57	0|wumpus|ah so gcc added recognition of fallthrough comments, as placeholder for in c++17 we get an explicit [[fallthrough]] marker
159 2017-11-01 13:11:02	0|wumpus|makes sense
160 2017-11-01 13:12:42	0|bitcoin-git|13bitcoin/06master 1460b98f8 15fanquake: [Util] Update tinyformat.h...
161 2017-11-01 13:12:42	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e8f3c88133b7...2631d55f61cd
162 2017-11-01 13:12:43	0|bitcoin-git|13bitcoin/06master 142631d55 15Wladimir J. van der Laan: Merge #11573: [Util] Update tinyformat.h...
163 2017-11-01 13:13:20	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11573: [Util] Update tinyformat.h (06master...06pull-upstream-tinyformat) 02https://github.com/bitcoin/bitcoin/pull/11573
164 2017-11-01 13:13:55	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11565: Make listsinceblock refuse unknown block hash (06master...06pr/since) 02https://github.com/bitcoin/bitcoin/pull/11565
165 2017-11-01 13:16:22	0|fanquake|#11550 Is also mergeable, unless there are some more backports to be added. A new PR can always be opened later anyways.
166 2017-11-01 13:16:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/11550 | [0.15.1] qa: Backports by MarcoFalke · Pull Request #11550 · bitcoin/bitcoin · GitHub
167 2017-11-01 13:16:48	0|wumpus|I was confused about 0.15.1 versus 0.15.0.2 there
168 2017-11-01 13:17:14	0|fanquake|Should it make a difference if it's ending up in the 0.15 branch?
169 2017-11-01 13:17:15	0|wumpus|so if they are 0.15.1 backports they shouldn't go in yet
170 2017-11-01 13:17:26	0|bitcoin-git|13bitcoin/060.15 147d4546f 15Russell Yanofsky: Make listsinceblock refuse unknown block hash...
171 2017-11-01 13:17:26	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.15: 02https://github.com/bitcoin/bitcoin/commit/7d4546f17dca84928bd2b6d1e2588b673c237321
172 2017-11-01 13:17:44	0|wumpus|I don't know - usually not, I guess
173 2017-11-01 13:17:53	0|wumpus|unless it's segwit wallet functionality then it shoudl be held up
174 2017-11-01 13:19:31	0|fanquake|wumpus yea ok, it can wait then.
175 2017-11-01 13:20:11	0|wumpus|it's just testing stuff so as it passes it can get in already
176 2017-11-01 13:20:38	0|fanquake|Don't think it will create any rebase issues either
177 2017-11-01 13:20:56	0|wumpus|if anything it makes rebasing easier by making 0.15 more like master :)
178 2017-11-01 13:22:05	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11550: [0.15.1] qa: Backports (060.15...06Mf1710-0151qaBackports) 02https://github.com/bitcoin/bitcoin/pull/11550
179 2017-11-01 13:23:04	0|bitcoin-git|13bitcoin/06master 14f927ee1 15Christian Gentry: Fixed a couple small grammatical errors....
180 2017-11-01 13:23:04	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e1f6a2a801a0...c95832da87ac
181 2017-11-01 13:23:05	0|bitcoin-git|13bitcoin/06master 14c95832d 15Wladimir J. van der Laan: Merge #11571: Fixed a couple small grammatical errors....
182 2017-11-01 13:23:39	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11571: Fixed a couple small grammatical errors. (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11571
183 2017-11-01 13:24:15	0|fanquake|Just checking for anything else that is ready to go.
184 2017-11-01 13:25:00	0|fanquake|Maybe #11511 , I feel like we are going in circles a bit with the EXIT_CODE stuff though.
185 2017-11-01 13:25:01	0|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
186 2017-11-01 13:25:15	0|fanquake|They seem to get added, then removed, then added again.
187 2017-11-01 13:25:24	0|wumpus|fanquake: yeah same feeling here, it didn't occur to me as terribly relevant
188 2017-11-01 13:25:44	0|wumpus|but as it has ACKs, I"m fine with merging it
189 2017-11-01 13:25:56	0|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
190 2017-11-01 13:26:49	0|bitcoin-git|13bitcoin/06master 14b296bf1 15donaloconnor: Init: Remove redundant exit(EXIT_FAILURE) instances and replace with return false
191 2017-11-01 13:26:49	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c95832da87ac...db2f83ed463b
192 2017-11-01 13:26:50	0|bitcoin-git|13bitcoin/06master 14db2f83e 15Wladimir J. van der Laan: Merge #11511: [Init] Remove redundant exit(EXIT_FAILURE) instances and replace with return false...
193 2017-11-01 13:27:06	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11591: wallet: Add missing cs_wallet locks in GetAvailableCredit/GetAvailableWatchOnlyCredit/CreateWalletFromFile (06master...06cs_wallet) 02https://github.com/bitcoin/bitcoin/pull/11591
194 2017-11-01 13:27:25	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11511: [Init] Remove redundant exit(EXIT_FAILURE) instances and replace with return false (06master...06161017_refactor_AppInit) 02https://github.com/bitcoin/bitcoin/pull/11511
195 2017-11-01 13:35:09	0|fanquake|Seems like the windows instructions need updating again already. Should we just be providing instructions for the latest release?
196 2017-11-01 13:35:44	0|fanquake|Having multiple different sets of instructions just for enabling the same feature seems un-ideal
197 2017-11-01 13:36:33	0|fanquake|I'm also not a great fan of 11438, seems like it just opens up lots of opportunities for miscompilation
198 2017-11-01 13:39:36	0|fanquake|Although it has been simplified quite a bit now.
199 2017-11-01 13:42:36	0|bitcoin-git|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/db2f83ed463b...cffa5ee132f3
200 2017-11-01 13:42:37	0|bitcoin-git|13bitcoin/06master 143b4ac43 15Matt Corallo: Rewrite p2p-acceptblock in preparation for slight behavior changes...
201 2017-11-01 13:42:37	0|bitcoin-git|13bitcoin/06master 143d9c70c 15Matt Corallo: Stop always storing blocks from whitelisted peers...
202 2017-11-01 13:42:38	0|bitcoin-git|13bitcoin/06master 14932f118 15Matt Corallo: Accept unrequested blocks with work equal to our tip...
203 2017-11-01 13:43:07	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11531: Check that new headers are not a descendant of an invalid block (more effeciently) (06master...062017-10-cache-invalid-indexes) 02https://github.com/bitcoin/bitcoin/pull/11531
204 2017-11-01 13:50:11	0|BlueMatt|yeesh, can I get some postumous acks on that one ^
205 2017-11-01 13:54:29	0|LumberCartel|That looks like a good idea.
206 2017-11-01 13:55:57	0|wumpus|fanquake: yeah... tend to agree one maintained way that works is better than 10 different ways different people prefer that work a bit
207 2017-11-01 14:01:38	0|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
208 2017-11-01 14:02:10	0|wumpus|it's potentially very dangerous
209 2017-11-01 14:03:30	0|wumpus|but in any case it results in broken executables so itt's a waste of time
210 2017-11-01 14:03:33	0|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.
211 2017-11-01 14:05:28	0|wumpus|yes, it is (if it works, please help review the code)
212 2017-11-01 14:16:40	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11592: [qa] 0.15.0.2: Fix silent merge conflict (assert_raises_rpc_error) (060.15...06Mf1711-qa01502) 02https://github.com/bitcoin/bitcoin/pull/11592
213 2017-11-01 14:56:44	0|xinxi|Will the US regulate Bitcoin development while it’s going to regulate Bitcoin derivatives?
214 2017-11-01 14:56:51	0|xinxi|What do you guys think?
215 2017-11-01 14:57:48	0|wumpus|no political discussion here please, use #bitcoin instead
216 2017-11-01 16:02:08	0|karelb|is there ETA for 0.15.0.2?
217 2017-11-01 16:03:34	0|karelb|not exact date, just if it will be this week or before 2x at all etc (yeah I know ETA questions are annoying :))
218 2017-11-01 16:11:36	0|sipa|karelb: "soon"
219 2017-11-01 16:11:40	0|sdaftuar|cfields: i just commented in #11560 -- i'd like to undo the change to looping on mapNodeState vs ForEachNode
220 2017-11-01 16:11:43	0|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
221 2017-11-01 16:12:08	0|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
222 2017-11-01 16:16:45	0|cfields|sdaftuar: well you'll have to hold cs_vNodes for that to be safe...
223 2017-11-01 16:17:05	0|sdaftuar|ForEachNode already holds cs_vNodes right?
224 2017-11-01 16:17:11	0|cfields|or you mean doing the whole thing in ForEachNode ?
225 2017-11-01 16:17:30	0|sdaftuar|yeah i wanted to undo the change from ForEachNode -> loop on mapNodeState
226 2017-11-01 16:17:36	0|cfields|do you have the old commit handy?
227 2017-11-01 16:17:41	0|sdaftuar|yep
228 2017-11-01 16:18:09	0|sdaftuar|this is the commit that changed it: https://github.com/sdaftuar/bitcoin/commit/be8c4337838b17cc495f657c2f8bd94912e158d3
229 2017-11-01 16:18:34	0|sdaftuar|unsquashed branch is here: https://github.com/sdaftuar/bitcoin/commits/11560.1
230 2017-11-01 16:18:53	0|sdaftuar|it occurred to me that maybe i should check that CNodeState is not null in there
231 2017-11-01 16:19:06	0|sdaftuar|if i'm using ForEachNode i mean
232 2017-11-01 16:19:09	0|cfields|oh, i see what you mean. I thought you were talking about the _other_ lookup in ForNode below
233 2017-11-01 16:19:32	0|sdaftuar|ah, no i'm not worried about that, that's just O(n)
234 2017-11-01 16:19:39	0|sdaftuar|i'm just concerned about the n^2
235 2017-11-01 16:22:48	0|cfields|yea, ok
236 2017-11-01 16:23:05	0|sdaftuar|great thanks
237 2017-11-01 16:25:47	0|cfields|sdaftuar: fwiw, I was hoping to do something like this: https://github.com/theuni/bitcoin/commit/0693ffb8ed386095a27a8ca62a7eacada2e9db04
238 2017-11-01 16:26:59	0|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.
239 2017-11-01 16:27:13	0|cfields|so that just leaves the CNodeState checks in that first test
240 2017-11-01 16:27:19	0|sdaftuar|ah, interesting
241 2017-11-01 16:27:45	0|sdaftuar|so we'd drop having to look into the cnode at all?
242 2017-11-01 16:28:28	0|cfields|yea, we'd just connman->Disconnect(id)
243 2017-11-01 16:30:02	0|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.
244 2017-11-01 16:30:54	0|bitcoin-git|13bitcoin/06master 145d465e3 15Tomas van der Wansem: Ensure backupwallet fails when attempting to backup to source file...
245 2017-11-01 16:30:54	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/cffa5ee132f3...1b8c88451b05
246 2017-11-01 16:30:55	0|bitcoin-git|13bitcoin/06master 141b8c884 15MarcoFalke: Merge #11376: Ensure backupwallet fails when attempting to backup to source file...
247 2017-11-01 16:31:25	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11376: Ensure backupwallet fails when attempting to backup to source file (06master...06core) 02https://github.com/bitcoin/bitcoin/pull/11376
248 2017-11-01 16:33:09	0|sipa|sdaftuar: were you going to adapt the approach to use an incrementable semaphore instead of a separate bool?
249 2017-11-01 16:33:31	0|sipa|or rather do that in a post-0.15.0.2 improvement
250 2017-11-01 16:50:37	0|sdaftuar|sipa: i'm not that familiar with the semaphore implementation so i was going to hold off on that
251 2017-11-01 16:51:09	0|sipa|okay
252 2017-11-01 16:51:14	0|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
253 2017-11-01 16:51:28	0|sdaftuar|i don't feel strongly about that, but that would be a reason in favor of a bool vs incrementable semaphore i think?
254 2017-11-01 16:53:28	0|sdaftuar|cfields: i'm not following how you could drop the connection time > 30 second check?
255 2017-11-01 16:57:02	0|sdaftuar|cfields: specifically i had greg's same question about how you avoid disconnecting a peer that you just connected to
256 2017-11-01 17:07:56	0|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
257 2017-11-01 17:08:25	0|cfields|I was getting ahead of myself, I guess that comment makes no sense without the future changes in mind
258 2017-11-01 17:52:57	0|sipa|BlueMatt: how did the invalidateblock code result in failure for pruned nodes?
259 2017-11-01 17:53:09	0|sipa|(just trying to understand)
260 2017-11-01 17:53:34	0|sdaftuar|sipa: i think the issue is if you call invalidateblock on a blockhash that you've pruned
261 2017-11-01 17:53:51	0|BlueMatt|yea, it'll walk backwards, and set the invalid flag BEFORE disconnecting it
262 2017-11-01 17:53:58	0|BlueMatt|then when you go to disconnect, you will fail to read from disk and shut down
263 2017-11-01 17:54:25	0|BlueMatt|(AbortNode, I believe) but now when you start up no block meets the conditions for inclusion in setBlockIndexCandidates
264 2017-11-01 17:54:44	0|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
265 2017-11-01 17:55:11	0|BlueMatt|so you hit the !setBlockIndexCandidates.empty() assert
266 2017-11-01 17:55:46	0|sipa|BlueMatt: i see!
267 2017-11-01 17:56:06	0|sipa|would there be a problem with marking the blocks invalid after disconnecting them, but one by one?
268 2017-11-01 17:56:13	0|sipa|as opposed to after the whole invalidated
269 2017-11-01 17:56:15	0|sipa|brb, meeting
270 2017-11-01 17:57:23	0|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
271 2017-11-01 17:57:29	0|BlueMatt|it might, however, very likely not actually break anything
272 2017-11-01 17:57:55	0|BlueMatt|still, I *really* didnt want to try to think through that in the context of the g_failed_blocks stuff
273 2017-11-01 17:57:57	0|sipa|anyone, no objection to the change that was merged
274 2017-11-01 17:58:04	0|sipa|*anyway
275 2017-11-01 17:58:48	0|BlueMatt|I take that back, CheckBlockIndex does *not* verify this, but, again, its nonsense
276 2017-11-01 19:06:56	0|sipa|BlueMatt: i've for a while regretted the choice of having validity flags inside the block index
277 2017-11-01 19:07:13	0|BlueMatt|I mean they are a pretty separate concept
278 2017-11-01 19:07:13	0|sipa|your PR makes me wonder if we couldn't get rid of them entirely
279 2017-11-01 19:07:22	0|sipa|valid = chainActive
280 2017-11-01 19:07:23	0|BlueMatt|I mean we have to have them somewhere
281 2017-11-01 19:07:30	0|sipa|invalid = in g_failed_blocks
282 2017-11-01 19:07:34	0|BlueMatt|no, we need a concept of "descends from invalid"
283 2017-11-01 19:07:59	0|BlueMatt|I mean that kinda sucks cause it grows unbounded
284 2017-11-01 19:08:03	0|BlueMatt|though not the end of the world, I suppose
285 2017-11-01 19:08:14	0|sipa|it's at most a constant factor larger than mapBlockIndex itself
286 2017-11-01 19:08:18	0|sipa|a very small constant factor
287 2017-11-01 19:08:24	0|gmaxwell|how would thing like invalidateblock / reconsider block work?  or pipelined validation with multiple stages of verification?
288 2017-11-01 19:08:24	0|sdaftuar|yes but it slows down acceptblockheader
289 2017-11-01 19:08:40	0|sdaftuar|you wouldn't want to iterate mapBlockindex just to accept a new header
290 2017-11-01 19:09:35	0|sipa|right, you want some form of 'caching' of invalid descendants
291 2017-11-01 19:09:43	0|sipa|but perhaps that doesn't need to be mapBlockIndex
292 2017-11-01 19:10:08	0|sipa|anyway, just a wild idea
293 2017-11-01 19:10:36	0|gmaxwell|it is kind of silly to have an extra field for something that is almost always just in a single state.
294 2017-11-01 19:11:32	0|BlueMatt|yea, I mean it is true that we barely use nStatus for anything except for HAVE_DATA
295 2017-11-01 19:11:47	0|sipa|and it doesn't even cover the whole thing
296 2017-11-01 19:11:48	0|BlueMatt|(which I guess is implied by the diskpos thing)
297 2017-11-01 19:12:01	0|sipa|we use nChainTx as indicator for "all parent blocks downloaded"
298 2017-11-01 19:13:09	0|BlueMatt|yea, I mean we do need VALID_SCRIPTS for net_processing :/
299 2017-11-01 19:13:19	0|BlueMatt|cause we're not allowed to send stuff unless its VALID_SCRIPTS
300 2017-11-01 20:24:01	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #11593: rpc: work-around an upstream libevent bug (06master...06fix-libevent-cb) 02https://github.com/bitcoin/bitcoin/pull/11593
301 2017-11-01 20:48:05	0|BlueMatt|cfields: travis failed on ^ (libevent in the travis os is 2.0, looks like, which does not have the getcb function)
302 2017-11-01 20:48:07	0|BlueMatt|only 2.1 has it
303 2017-11-01 20:48:35	0|cfields|ugh
304 2017-11-01 20:49:09	0|cfields|ok, working on it
305 2017-11-01 21:12:48	0|MarcoFalke|wumpus: cfields: I was trying to prepare the 0.15.0.2 release but I am stuck at deciding whether to backport #10756.
306 2017-11-01 21:12:50	0|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
307 2017-11-01 21:13:07	0|MarcoFalke|some of the commits depend on it
308 2017-11-01 21:13:36	0|MarcoFalke|It might be shorter (with regard to LOC) to solve the merge conflicts manually
309 2017-11-01 21:13:48	0|MarcoFalke|But I'd wanted to see what you prefer
310 2017-11-01 21:16:41	0|cfields|MarcoFalke: i don't think that should be needed. What are the conflicts?
311 2017-11-01 21:18:00	0|MarcoFalke|In function ‘bool SendMessages(CNode*, CConnman&, const std::atomic<bool>&)’: error: ‘ConsiderEviction’ was not declared in this scope
312 2017-11-01 21:20:28	0|cfields|ah right, new members
313 2017-11-01 21:20:30	0|cfields|sec
314 2017-11-01 21:23:29	0|cfields|MarcoFalke: blah, backporting 10756 may be easier, as more and more commits build on it
315 2017-11-01 21:24:28	0|cfields|MarcoFalke: it's either that, or break the new functions (like ConsiderEviction) global/static, and pass in the CConnman pointer
316 2017-11-01 21:24:40	0|MarcoFalke|Jup, figured that
317 2017-11-01 21:27:28	0|MarcoFalke|Since the not-yet-merged #11560 also needs it, I will try to cherry-pick your refactoring commits
318 2017-11-01 21:27:30	0|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
319 2017-11-01 21:35:01	0|ghost43|has to have a height of nLockTime+1?
320 2017-11-01 21:35:01	0|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
321 2017-11-01 21:54:25	0|cfields|BlueMatt: pushed a new version that mimics the upstream fix
322 2017-11-01 21:58:15	0|BlueMatt|thanks! will review in a few minutes