1 2016-11-11T00:24:59  *** Guyver2 has quit IRC
  2 2016-11-11T01:22:38  *** baldur has quit IRC
  3 2016-11-11T01:22:56  *** baldur has joined #bitcoin-core-dev
  4 2016-11-11T01:25:12  *** baldur has quit IRC
  5 2016-11-11T01:25:27  *** baldur has joined #bitcoin-core-dev
  6 2016-11-11T01:37:54  *** AaronvanW has quit IRC
  7 2016-11-11T01:58:05  *** abpa has quit IRC
  8 2016-11-11T01:58:55  <bitcoin-git> [bitcoin] sipa opened pull request #9125: Make CBlock a vector of shared_ptr of CTransactions (master...sharedblock) https://github.com/bitcoin/bitcoin/pull/9125
  9 2016-11-11T02:08:20  *** fengling has joined #bitcoin-core-dev
 10 2016-11-11T02:08:33  *** DigiByteDev has joined #bitcoin-core-dev
 11 2016-11-11T02:10:18  *** tulip has quit IRC
 12 2016-11-11T02:19:23  *** jtimon has quit IRC
 13 2016-11-11T02:20:08  <cfields> sipa: interesting
 14 2016-11-11T02:20:39  <sipa> cfields: the PR above?
 15 2016-11-11T02:20:42  *** sipa sets mode: -o sipa
 16 2016-11-11T02:20:45  <cfields> sipa: yes
 17 2016-11-11T02:21:08  <sipa> i was surprised that i didn't need to touch any of the block or transaction serialization logic
 18 2016-11-11T02:21:31  <cfields> yes, it's simpler than I would've expected too
 19 2016-11-11T02:21:46  <cfields> trying to decide how much foot-gun the serialize.h changes allow
 20 2016-11-11T02:22:27  <sipa> the shared_ptr serializer only applies when the element type is const
 21 2016-11-11T02:27:57  <cfields> sipa: yep, actually seems innocuous
 22 2016-11-11T02:28:55  <cfields> sipa: and my knee-jerk when I see shared_ptr is to grumble about ownership models, but I can't imagine this being any worse than duplicating all over the place
 23 2016-11-11T02:29:56  <sipa> cfields: right, but that doesn't apply when the element type is const
 24 2016-11-11T02:30:11  <sipa> you can just see the different shared_ptr's as deduplicated copies of the same data
 25 2016-11-11T02:30:53  <cfields> yes. I like it :)
 26 2016-11-11T02:32:47  <gmaxwell> keep up the grumbling at shared_ptr, I agree.. but it sure seems to make sense for mempool transactions which otherwise we'd have copies of, since the different uses have different lifetimes.
 27 2016-11-11T02:36:02  <cfields> yes, this seems like a really good use-case.
 28 2016-11-11T02:40:10  *** Ylbam has quit IRC
 29 2016-11-11T02:40:43  <cfields> probably requires new approaches in lots of places. For ex where copying a block becomes very cheap for the purposes of caching around locks.
 30 2016-11-11T02:40:50  <cfields> s/requires/allows/
 31 2016-11-11T02:42:33  <sipa> cfields: well that would better be served by using shared_ptr's to CBlock itself
 32 2016-11-11T02:43:23  <cfields> sipa: i was wondering if that's the next logical step. I don't think they'd be mutually exclusive?
 33 2016-11-11T02:45:07  <sipa> cfields: sure
 34 2016-11-11T02:47:20  <sipa> there are probably a few more optimizations that i haven't addressed
 35 2016-11-11T02:47:31  <sipa> i think ATMP should take a shared_ptr
 36 2016-11-11T02:47:55  <sipa> so a reorg wouldn't require a copy back from the block to the mempool
 37 2016-11-11T03:23:41  *** btcdrak has joined #bitcoin-core-dev
 38 2016-11-11T03:44:36  *** fanquake has joined #bitcoin-core-dev
 39 2016-11-11T03:48:45  *** DigiByteDev has quit IRC
 40 2016-11-11T03:55:12  *** abpa has joined #bitcoin-core-dev
 41 2016-11-11T04:56:14  *** kadoban has quit IRC
 42 2016-11-11T05:26:16  *** Alopex has quit IRC
 43 2016-11-11T05:27:22  *** Alopex has joined #bitcoin-core-dev
 44 2016-11-11T05:31:21  *** jl2012 has quit IRC
 45 2016-11-11T05:33:25  *** jl2012 has joined #bitcoin-core-dev
 46 2016-11-11T05:40:45  *** DigiByteDev has joined #bitcoin-core-dev
 47 2016-11-11T06:10:33  *** jl2012 has quit IRC
 48 2016-11-11T06:10:54  *** jl2012 has joined #bitcoin-core-dev
 49 2016-11-11T06:27:59  *** btcdrak has quit IRC
 50 2016-11-11T06:28:29  <bitcoin-git> [bitcoin] theuni opened pull request #9128: net: Decouple CConnman and message serialization (master...connman-send) https://github.com/bitcoin/bitcoin/pull/9128
 51 2016-11-11T06:33:03  *** DigiByteDev has quit IRC
 52 2016-11-11T06:38:51  <bitcoin-git> [bitcoin] rebroad opened pull request #9129: One fDisconnect to rule them all (master...OnefDisconnect) https://github.com/bitcoin/bitcoin/pull/9129
 53 2016-11-11T06:54:53  *** thokon00 has quit IRC
 54 2016-11-11T06:58:52  *** windsok has joined #bitcoin-core-dev
 55 2016-11-11T07:03:00  *** btcdrak has joined #bitcoin-core-dev
 56 2016-11-11T07:03:19  *** windsok has quit IRC
 57 2016-11-11T07:05:31  *** thokon00 has joined #bitcoin-core-dev
 58 2016-11-11T07:06:04  *** windsok has joined #bitcoin-core-dev
 59 2016-11-11T07:08:33  <luke-jr> should we be using std::random_device?
 60 2016-11-11T07:10:25  <sipa> luke-jr: afaik it has 0 guarantees
 61 2016-11-11T07:10:58  <luke-jr> can't hurt though, right?
 62 2016-11-11T07:11:39  <luke-jr> (and what's the point of the exception if there's no guarantees at all? O.o)
 63 2016-11-11T07:12:32  *** aalex has joined #bitcoin-core-dev
 64 2016-11-11T07:13:49  <sipa> the exception is for when no random number can be generated at all
 65 2016-11-11T07:14:10  <sipa> even if it generates one, it doesn't guarantee cryptographic quality (or any quality at all)
 66 2016-11-11T07:14:53  *** DigiByteDev has joined #bitcoin-core-dev
 67 2016-11-11T07:19:01  *** aalex has quit IRC
 68 2016-11-11T07:25:17  *** cfields has quit IRC
 69 2016-11-11T07:25:47  *** cfields has joined #bitcoin-core-dev
 70 2016-11-11T07:39:43  *** DigiByteDev has quit IRC
 71 2016-11-11T07:55:27  *** jl2012 has quit IRC
 72 2016-11-11T07:57:02  *** jl2012 has joined #bitcoin-core-dev
 73 2016-11-11T08:12:31  *** Guyver2 has joined #bitcoin-core-dev
 74 2016-11-11T08:21:24  *** testnet has quit IRC
 75 2016-11-11T08:21:25  *** wasi has quit IRC
 76 2016-11-11T08:21:51  *** wasi has joined #bitcoin-core-dev
 77 2016-11-11T08:22:55  *** rubensayshi has joined #bitcoin-core-dev
 78 2016-11-11T08:25:46  *** testnet has joined #bitcoin-core-dev
 79 2016-11-11T08:29:07  *** Ylbam has joined #bitcoin-core-dev
 80 2016-11-11T08:41:54  *** DigiByteDev has joined #bitcoin-core-dev
 81 2016-11-11T08:57:32  <fanquake> Competing pull-requests seems to be a "thing" now..
 82 2016-11-11T09:04:46  <wumpus> yeah...
 83 2016-11-11T09:05:45  <wumpus> sure, it can happen that pulls overlap, but I guess one certain person seems to be trying hard to duplicate other people's work
 84 2016-11-11T09:07:33  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #9129: One fDisconnect to rule them all (master...OnefDisconnect) https://github.com/bitcoin/bitcoin/pull/9129
 85 2016-11-11T09:07:45  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/71bc39eb7483...21e6c6b569c5
 86 2016-11-11T09:07:45  <bitcoin-git> bitcoin/master 617c96d fanquake: [depends] Set OSX_MIN_VERSION to 10.8
 87 2016-11-11T09:07:46  <bitcoin-git> bitcoin/master 21e6c6b Wladimir J. van der Laan: Merge #9114: [depends] Set OSX_MIN_VERSION to 10.8...
 88 2016-11-11T09:07:52  <bitcoin-git> [bitcoin] laanwj closed pull request #9114: [depends] Set OSX_MIN_VERSION to 10.8 (master...depends-min-osx-10-8) https://github.com/bitcoin/bitcoin/pull/9114
 89 2016-11-11T09:07:55  *** MarcoFalke has joined #bitcoin-core-dev
 90 2016-11-11T09:08:17  <wumpus> we're better off implementing our own secure random functionality, given how critical it is for the wallet at least
 91 2016-11-11T09:09:14  <wumpus> at least relying on the C++ library to do the right thing, especially with a new thing (I hadn't heard of std::Random_device before) seems a bad idea...
 92 2016-11-11T09:11:02  <Victorsueca> wumpus: you mean that bitcoin core should have it's own random service like, for example, OpenPGP that uses other computationally intensive processes running on your system?
 93 2016-11-11T09:11:27  <wumpus> Victorsueca: maybe. At the least we should be reading /dev/urandom ourselves
 94 2016-11-11T09:12:01  <wumpus> it's not rocket science and there is nothing to be gained by hiding it behind layers of abstraction
 95 2016-11-11T09:12:45  <Victorsueca> sounds good, definitely better than using the default source of randomness which could be backdoored by the hardware manufacturer
 96 2016-11-11T09:13:44  <sipa> if your hardware is backdoored, the technical term for the situation you're in is: utterly fucked
 97 2016-11-11T09:13:47  <wumpus> that's not really the threat model we're fighting here...
 98 2016-11-11T09:13:53  <wumpus> right
 99 2016-11-11T09:14:17  <luke-jr> wumpus: I just meant in addition to other entropy sources
100 2016-11-11T09:15:39  <wumpus> buggy hardware is more common though, so relying only on hw random instructions is a bad idea no matter how much you trust or don't trust your CPU vendor
101 2016-11-11T09:16:55  <luke-jr> sure, only reason I even thought of it was seeing GCC's compile checking for /dev/u(?)random for std::random_device  :p
102 2016-11-11T09:17:20  <wumpus> there's always talk about backdoored this and that, but in practice there is no need for explicit backdoors in CPUs. They are way too risky from a commercial perspective. There are also so many bugs in hardware and software that no one needs them...
103 2016-11-11T09:17:20  <luke-jr> just happened to glance at that shell at the right instant
104 2016-11-11T09:17:45  <Victorsueca> would be nice if someone made a Plug&Play open-source device that you plug into a USB and uses some external sources like temperature with a accuracy of 0.0001, microphone ambient noise, amount of lumens etc... to fill your computer's randomness
105 2016-11-11T09:17:45  <luke-jr> eh, Intel ME is a pretty low risk explicit backdoor
106 2016-11-11T09:17:58  <Victorsueca> is the kind of thing I never seen but I think it should already exist
107 2016-11-11T09:18:14  <luke-jr> Victorsueca: pretty sure something does using radio waves
108 2016-11-11T09:18:17  <wumpus> luke-jr: well in any case thanks for letting me know it exists at all, it may be useful for some other projects
109 2016-11-11T09:19:12  <wumpus> Victorsueca: those exist and are in active use, both for secure randomness and by gambling sites
110 2016-11-11T09:20:16  <Victorsueca> wumpus: thought gambling sites used atomic event observation which is pretty expensive devices, I was thinking on something affordable for any home user
111 2016-11-11T09:20:37  <wumpus> luke-jr: I mean the "flip a few bits in a certain pattern and gain instand code execution" kinds of backdoors, who needs them if there's bugs like rowhammer :-)
112 2016-11-11T09:20:57  <luke-jr> heh
113 2016-11-11T09:21:23  <Victorsueca> and what if rowhammer is a backdoor and was implemented on purpose?
114 2016-11-11T09:21:29  * Victorsueca adjusts tinfoil hat
115 2016-11-11T09:21:45  <wumpus> Victorsueca: there's low end and high end devices in that range, just a google away :p
116 2016-11-11T09:22:35  <wumpus> you can even build a randomness device pretty easily yourself, building unstable hardware is not rocket science :-)
117 2016-11-11T09:23:16  <Victorsueca> wumpus: maybe, but preventing it from putting your house on fire is ;)
118 2016-11-11T09:23:40  <Victorsueca> then use the shape of the flames as random source
119 2016-11-11T09:24:09  *** DigiByteDev has quit IRC
120 2016-11-11T09:25:38  *** Guyver2 has quit IRC
121 2016-11-11T09:25:50  *** rubensayshi has quit IRC
122 2016-11-11T09:26:06  *** jannes has joined #bitcoin-core-dev
123 2016-11-11T09:27:10  <wumpus> Victorsueca: meh. I read a report back in the 90's about an evolutionary algorithm being used to optimize code. After some time it found an optimal solution but no one understood how it worked. To the surprise of the researchers it only worked on that specific chip, not others of the same kind. Turns out it was expliting some timing/physical peculiarity of that specific chip. Rowhammer is
124 2016-11-11T09:27:16  <wumpus> similar, though much more general.
125 2016-11-11T09:27:48  <wumpus> Victorsueca: physical processes have effects on electronics that are not always taken into account, especially when there's undefined behavior at the instruction level (given timing etc)
126 2016-11-11T09:28:52  <wumpus> Victorsueca: ascribing such natural engineering properties to state actors is paranoid to the level of schizofrenia :)
127 2016-11-11T09:29:52  <wumpus> *finding* these kinds of bugs on the other hand is something they're certainly working very hard at
128 2016-11-11T09:30:10  <Victorsueca> they control temperature and humidity to manipulate your randomness
129 2016-11-11T09:30:36  * Victorsueca puts tinfoil around his parts
130 2016-11-11T09:33:38  <Victorsueca> jokes apart, Yesterday I had an idea
131 2016-11-11T09:34:21  <Victorsueca> would be possible to make that after abandoning a transaction core spends the same inputs for the next transaction you make?
132 2016-11-11T09:34:51  <Victorsueca> I think it's possible, the question would rather be if it makes sense
133 2016-11-11T09:35:56  <wumpus> what are you trying to accomplish? if you want to make the transaction impossible to be mined later on you should *immediately* create a new transaction spending them to yourself
134 2016-11-11T09:36:44  <wumpus> delaying it until you happen to need to send again creates a potentially huge time window in which you're exposed
135 2016-11-11T09:36:58  <Victorsueca> I was thinking on somebody who has his transaction stuck because ha paid a low fee
136 2016-11-11T09:37:13  <Victorsueca> so he abandons the transaction and double-spends it with a higher fee
137 2016-11-11T09:37:20  <wumpus> just use RBF?
138 2016-11-11T09:37:50  <Victorsueca> then why is there a banadon transaction button at all?
139 2016-11-11T09:37:58  <Victorsueca> abandon*
140 2016-11-11T09:38:21  <Victorsueca> not to mention RBF is not yet implemented in the GUI
141 2016-11-11T09:39:21  <wumpus> bumpfee needs to be on RPC first e.g. see https://github.com/bitcoin/bitcoin/pull/8456
142 2016-11-11T09:39:27  <wumpus> all needs review
143 2016-11-11T09:39:51  <wumpus> sorry to say this but we need more review and testing on actual work people are doing, not out-there ideas
144 2016-11-11T09:40:22  <Victorsueca> it's ok
145 2016-11-11T09:41:29  <Victorsueca> I was thinking that making core automatic input picking to give priority to inputs that have been spent in a abandoned unconfirmed transaction would be easier to review and implement
146 2016-11-11T09:41:40  <wumpus> no, it's not
147 2016-11-11T09:41:50  <Victorsueca> thought so
148 2016-11-11T09:42:04  <wumpus> changes to coin selection are one of the most difficult categories of changes
149 2016-11-11T09:46:22  *** chris2000 has joined #bitcoin-core-dev
150 2016-11-11T09:46:51  <Victorsueca> well, I can help testing changes on windows, AFAIK few devs work on windows
151 2016-11-11T09:50:55  <wumpus> awesome!
152 2016-11-11T09:50:59  <fanquake> Great!
153 2016-11-11T09:51:37  <fanquake> There is always need for more reviewers, especially on Windows, because as you've mentioned, few devs are using it.
154 2016-11-11T09:52:40  <wumpus> yes especially for GUI changes there's pretty few testers at all
155 2016-11-11T09:52:53  <fanquake> If your interested in testing more general issues/changes, there is a decent list of Windows specific issues, some which have been open for > 4 years here.
156 2016-11-11T09:52:54  <fanquake> https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+label%3AWindows
157 2016-11-11T09:53:39  <jonasschnelli> For multiwallet, this PR is large but simple to review: https://github.com/bitcoin/bitcoin/pull/8764
158 2016-11-11T09:54:16  <phantomcircuit> wumpus: the wallet recovery stuff will print a warning if it fails to parse the value in the key/value pair
159 2016-11-11T09:54:28  <phantomcircuit> this is the last reference to CWallet from CWalletDB
160 2016-11-11T09:54:36  <phantomcircuit> i have a patch that just removes this
161 2016-11-11T09:54:44  <phantomcircuit> i'd like to know what you think about it
162 2016-11-11T09:54:53  <phantomcircuit> (not the patch, removing the warning)
163 2016-11-11T09:54:57  <wumpus> please don't remove that warning. You can't move it anywhere else?
164 2016-11-11T09:55:15  <wumpus> we have open issues with salvagewallet that's why the debug level there was increased
165 2016-11-11T09:55:40  <wumpus> https://github.com/bitcoin/bitcoin/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20salvagewallet
166 2016-11-11T09:55:51  <phantomcircuit> ok i'll take another look at it to see if there's a better way of handling that
167 2016-11-11T09:56:10  <phantomcircuit> (i mean really the better way would be a completely separate tool, but that is not in scope)
168 2016-11-11T09:56:37  <fanquake> wumpus: I've ack'd #9112 if you just want to merge it.
169 2016-11-11T09:56:38  <gribble> https://github.com/bitcoin/bitcoin/issues/9112 | Avoid ugly exception in log on unknown inv type by laanwj · Pull Request #9112 · bitcoin/bitcoin · GitHub
170 2016-11-11T09:57:06  *** moli has quit IRC
171 2016-11-11T09:57:07  <wumpus> phantomcircuit: jonasschnelli made such a tool https://github.com/bitcoin/bitcoin/pull/8745  - but yeah that's out of scope
172 2016-11-11T09:57:14  *** AaronvanW has joined #bitcoin-core-dev
173 2016-11-11T09:57:14  *** AaronvanW has quit IRC
174 2016-11-11T09:57:14  *** AaronvanW has joined #bitcoin-core-dev
175 2016-11-11T09:57:41  <jonasschnelli> wumpus: we first need to solve the cirular dependencies.
176 2016-11-11T09:57:45  <wumpus> fanquake: thanks, yes just going to merge it, I think we should have some solution there but I don't want to spend more time discussing details
177 2016-11-11T09:57:45  <jonasschnelli> *circular
178 2016-11-11T09:59:24  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/21e6c6b569c5...46027e8668ec
179 2016-11-11T09:59:24  <bitcoin-git> bitcoin/master e9f25dd Wladimir J. van der Laan: Avoid ugly exception in log on unknown inv type...
180 2016-11-11T09:59:25  <bitcoin-git> bitcoin/master 46027e8 Wladimir J. van der Laan: Merge #9112: Avoid ugly exception in log on unknown inv type...
181 2016-11-11T09:59:34  <bitcoin-git> [bitcoin] laanwj closed pull request #9112: Avoid ugly exception in log on unknown inv type (master...2016_11_invtype_debugging) https://github.com/bitcoin/bitcoin/pull/9112
182 2016-11-11T09:59:44  <bitcoin-git> [bitcoin] laanwj closed pull request #9113: Return the type when it's unknown instead of throwing an exception (master...ReturnNotThrow) https://github.com/bitcoin/bitcoin/pull/9113
183 2016-11-11T10:02:31  <Victorsueca> how do you do to pull a unmerged pull request into your working directory?
184 2016-11-11T10:03:05  <fanquake> Have a look at the github-merge script in this dir https://github.com/bitcoin/bitcoin/tree/master/contrib/devtools
185 2016-11-11T10:03:15  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/46027e8668ec...7977a1157a3a
186 2016-11-11T10:03:15  <wumpus> contrib/devtools/github-merge.py 1234
187 2016-11-11T10:03:15  <bitcoin-git> bitcoin/master 47e9659 Russell Yanofsky: [qa] Fix bug in compactblocks v2 merge...
188 2016-11-11T10:03:16  <bitcoin-git> bitcoin/master 55bfddc Russell Yanofsky: [qa] Fix stale data bug in test_compactblocks_not_at_tip...
189 2016-11-11T10:03:16  <bitcoin-git> bitcoin/master dac53b5 Russell Yanofsky: Modify getblocktxn handler not to drop requests for old blocks...
190 2016-11-11T10:03:18  <wumpus> yes, that :)
191 2016-11-11T10:03:25  <bitcoin-git> [bitcoin] laanwj closed pull request #9058: Fixes for p2p-compactblocks.py test timeouts on travis (#8842) (master...fix-8842-sync-timeouts) https://github.com/bitcoin/bitcoin/pull/9058
192 2016-11-11T10:03:45  *** Evel-Knievel has quit IRC
193 2016-11-11T10:04:07  <jonasschnelli> heh
194 2016-11-11T10:04:33  *** fengling has quit IRC
195 2016-11-11T10:04:46  <wumpus> you can also do it manually e.g. git fetch upstream pull/1234/head && git checkout FETCH_HEAD  ... this will give you the literal commit instead of a version merged to master
196 2016-11-11T10:05:21  <wumpus> (where "upstream" is the name of your remote for bitcoin/bitcoin, big chance it is "origin" for you)
197 2016-11-11T10:05:28  <jonasschnelli> For testing, it's probably better if you test them applied on the current master
198 2016-11-11T10:05:35  <jonasschnelli> (unless they have merge conflicts)
199 2016-11-11T10:05:40  <wumpus> yes, true
200 2016-11-11T10:14:01  <Victorsueca> ok, got it, thanks
201 2016-11-11T10:15:14  <Victorsueca> building it at the moment
202 2016-11-11T10:16:59  <bitcoin-git> [bitcoin] jonasschnelli pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/7977a1157a3a...ab914a65301b
203 2016-11-11T10:17:00  <bitcoin-git> bitcoin/master 7c9a98a Jon Lund Steffensen: Allow network activity to be temporarily suspended....
204 2016-11-11T10:17:00  <bitcoin-git> bitcoin/master e38993b Jon Lund Steffensen: RPC: Add "togglenetwork" method to toggle network activity temporarily...
205 2016-11-11T10:17:01  <bitcoin-git> bitcoin/master 32efa79 Jon Lund Steffensen: Qt: Add GUI feedback and control of network activity state....
206 2016-11-11T10:17:09  <bitcoin-git> [bitcoin] jonasschnelli closed pull request #8996: Network activity toggle (master...networkactive) https://github.com/bitcoin/bitcoin/pull/8996
207 2016-11-11T10:17:32  <Victorsueca> it's me or this new bot is more spammy than the previous one?
208 2016-11-11T10:18:11  <luke-jr> just you
209 2016-11-11T10:19:09  <jonasschnelli> Luke-Jr: how do we continue with https://github.com/bitcoin/bitcoin/pull/8889? Close?
210 2016-11-11T10:19:57  <luke-jr> for now
211 2016-11-11T10:20:04  <bitcoin-git> [bitcoin] luke-jr closed pull request #8889: Qt/ModalOverlay: Use theme tooltip colours (master...overlay_theme) https://github.com/bitcoin/bitcoin/pull/8889
212 2016-11-11T10:20:20  <jonasschnelli> Okay. Yes. We can always reopen this.
213 2016-11-11T10:20:59  <luke-jr> I suspect the problems were due to tooltips not normally having focus
214 2016-11-11T10:22:29  <luke-jr> ie, the theme doesn't bother defining the tooltip-with-focus colours sanely
215 2016-11-11T10:25:45  <wumpus> there is no 'new bot', I've just changed its configuration to use a consistent name
216 2016-11-11T10:26:07  <wumpus> if it seems more spammy it's just because there's a lot of merging going on
217 2016-11-11T10:26:42  <Victorsueca> ahh ok
218 2016-11-11T10:27:11  <Victorsueca> 0.14 seems like it's finally going to be a version dedicated to GUI and wallet
219 2016-11-11T10:27:12  <wumpus> there is increased activity lately, which is mostly a good thing, though it also means we need to be selective in how much attention we pay to what
220 2016-11-11T10:29:20  <fanquake> wumpus: If you want to get the PR list down, there are a few trivial ones.
221 2016-11-11T10:29:39  <wumpus> fanquake: sure, let me know
222 2016-11-11T10:29:42  <fanquake> #9115 has been updated so can get ACK'd/merged.
223 2016-11-11T10:29:43  <gribble> https://github.com/bitcoin/bitcoin/issues/9115 | Mention reporting security issues responsibly by paveljanik · Pull Request #9115 · bitcoin/bitcoin · GitHub
224 2016-11-11T10:30:47  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ab914a65301b...bfc7aad00884
225 2016-11-11T10:30:47  <bitcoin-git> bitcoin/master 7d1de30 Pavel Janík: Mention reporting security issues responsibly
226 2016-11-11T10:30:48  <bitcoin-git> bitcoin/master bfc7aad Wladimir J. van der Laan: Merge #9115: Mention reporting security issues responsibly...
227 2016-11-11T10:30:58  <bitcoin-git> [bitcoin] laanwj closed pull request #9115: Mention reporting security issues responsibly (master...20161109_secissues) https://github.com/bitcoin/bitcoin/pull/9115
228 2016-11-11T10:31:16  <fanquake> #9064 Should get a yes/no on wether it's going to be to much work for translators, otherwise, can probably be merged. It does include some whitespace changes to line-endings.
229 2016-11-11T10:31:17  <gribble> https://github.com/bitcoin/bitcoin/issues/9064 | unify capitalization of "bitcoin address" by s-matthew-english · Pull Request #9064 · bitcoin/bitcoin · GitHub
230 2016-11-11T10:32:40  <wumpus> ooh capitalizing Bitcoin just now that internet is no longer going to be capitalized :)
231 2016-11-11T10:32:51  <Victorsueca> heh
232 2016-11-11T10:33:51  <wumpus> I don't really care, I guess it makes sense to be consistent though...
233 2016-11-11T10:34:11  <fanquake> #8983 Has had some review, but now needs rebasing, and probably some concept ACKs as to if it's wanted. Given it seems to be a WIP it could be closed for now and re-opened when finished.
234 2016-11-11T10:34:14  <gribble> https://github.com/bitcoin/bitcoin/issues/8983 | WIP: Log block height and size when received by rebroad · Pull Request #8983 · bitcoin/bitcoin · GitHub
235 2016-11-11T10:34:30  <paveljanik> wumpus, internet and Internet are two different things... ;-)
236 2016-11-11T10:35:07  <Victorsueca> shouldn't be really difficult to change capitals, except for some languages like German where concepts are one-worded
237 2016-11-11T10:35:44  <wumpus> paveljanik: "the internet of different things"
238 2016-11-11T10:36:36  <wumpus> it's not "difficult" in any sense of the work, the only thing I'm afraid of is giving people useless busywork in these hard times
239 2016-11-11T10:37:35  <Victorsueca> not to mention that could cause people blames capitals being wrong, I still remember when someone put "advertize" in the log messages
240 2016-11-11T10:37:58  <Victorsueca> almost starts WW3
241 2016-11-11T10:38:12  <wumpus> capital punishment
242 2016-11-11T10:39:33  <fanquake> #9124 Is a trivial merge, variable renaming in the benchmarking code.
243 2016-11-11T10:39:35  <gribble> https://github.com/bitcoin/bitcoin/issues/9124 | Use better name for local variable to prevent -Wshadow compiler warning by paveljanik · Pull Request #9124 · bitcoin/bitcoin · GitHub
244 2016-11-11T10:39:54  <wumpus> phantomcircuit: I don't understand why you can't keep a warning in #9101 when the try{...} fails
245 2016-11-11T10:39:55  <gribble> https://github.com/bitcoin/bitcoin/issues/9101 | [Wallet] Do not parse ssValue in CWalletDB::Recover by pstratem · Pull Request #9101 · bitcoin/bitcoin · GitHub
246 2016-11-11T10:40:51  <wumpus> you do catch(...) { continue; } silently ignoring aspecific exceptions is usually a code smell and means there should be a warning at least
247 2016-11-11T10:43:17  <wumpus> silent errors mean that someone is going to have a very difficult time troubleshooting at some point
248 2016-11-11T10:44:18  <Victorsueca> what about make it silent by default but not when -debug is enabled?
249 2016-11-11T10:44:37  <wumpus> WHY?
250 2016-11-11T10:44:50  <wumpus> salvagewallet is already a troubleshooting option
251 2016-11-11T10:44:56  <Victorsueca> right
252 2016-11-11T10:45:06  <wumpus> why the hell would you want to have people enable debug to see when things go wrong? that's nonsense
253 2016-11-11T10:46:11  <Victorsueca> maybe somebody who expects salvagewallet to go well doesn't want his logs nuked with lots of lines
254 2016-11-11T10:46:25  <Victorsueca> if something goes wrong you can always try again with -debug
255 2016-11-11T10:46:36  <wumpus> if it goes well there will be no logging because it won't get there!
256 2016-11-11T10:47:20  <Victorsueca> hmmm I don't know what would I do
257 2016-11-11T10:47:41  <wumpus> you're worrying about the bedsprings being noisy on the titanic while it is colliding against an iceberg
258 2016-11-11T10:47:50  <rabidus_> :DD
259 2016-11-11T10:47:53  <Victorsueca> heh yeah
260 2016-11-11T10:48:57  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bfc7aad00884...87ab49e4fe38
261 2016-11-11T10:48:57  <bitcoin-git> bitcoin/master bf49f10 Pavel Janík: Use better name for local variable to prevent -Wshadow compiler warning
262 2016-11-11T10:48:58  <bitcoin-git> bitcoin/master 87ab49e Wladimir J. van der Laan: Merge #9124: Use better name for local variable to prevent -Wshadow compiler warning...
263 2016-11-11T10:49:09  <bitcoin-git> [bitcoin] laanwj closed pull request #9124: Use better name for local variable to prevent -Wshadow compiler warning (master...20161110_Wshadow_benchcheckblock) https://github.com/bitcoin/bitcoin/pull/9124
264 2016-11-11T10:49:23  <Victorsueca> - Mr president, the poles are melting, the global warming has reached too high extremes
265 2016-11-11T10:49:33  <Victorsueca> - Thanks for informing, now go away
266 2016-11-11T10:49:46  <Victorsueca> President* Looks at a Titanic picture
267 2016-11-11T10:49:55  <Victorsueca> - The revenge is ours!
268 2016-11-11T10:51:39  <fanquake> #9100 is another fairly trivial one, with your questions answered.
269 2016-11-11T10:51:40  <gribble> https://github.com/bitcoin/bitcoin/issues/9100 | tx_valid: re-order inputs to how they are encoded by dcousens · Pull Request #9100 · bitcoin/bitcoin · GitHub
270 2016-11-11T11:02:02  <bitcoin-git> [bitcoin] paveljanik opened pull request #9130: Mention the new network toggle functionality in the tooltip. (master...20161111_disable_network_tooltip) https://github.com/bitcoin/bitcoin/pull/9130
271 2016-11-11T11:10:22  <wumpus> I'd like an ack from someone else on #9100 before merging
272 2016-11-11T11:10:23  <gribble> https://github.com/bitcoin/bitcoin/issues/9100 | tx_valid: re-order inputs to how they are encoded by dcousens · Pull Request #9100 · bitcoin/bitcoin · GitHub
273 2016-11-11T11:10:26  <wumpus> I'm not sure enough about it
274 2016-11-11T11:11:34  <wumpus> I think it's ok though
275 2016-11-11T11:13:35  *** whphhg is now known as mistermister
276 2016-11-11T11:23:08  <fanquake> wumpus: I'll look at that shortly.
277 2016-11-11T11:24:21  <fanquake> One thing I wanted you to take a look at this this diff generated by your diff-tool -> https://github.com/bitcoin/bitcoin/pull/8808#issuecomment-259657066 , the bottom change seems to significant to be part of the PR.
278 2016-11-11T11:25:28  <fanquake> I'm working on making the maintainer tools run on OS X so there are a few more people running them.
279 2016-11-11T11:27:38  <wumpus> for the Wshadow stuff I want to be entirely sure that it doesn't cause floods of warnings for anyone
280 2016-11-11T11:27:57  <wumpus> I don't want to enable it again and get complaints that some obscure compiler is generating a shitton of senseless warnings
281 2016-11-11T11:28:31  <fanquake> Sure. Is them some threshold for compiler age/obscureness.
282 2016-11-11T11:28:34  <fanquake> *there
283 2016-11-11T11:29:00  <wumpus> maybe  a solution that enables it conditionally for compilers where it is shown to be ok
284 2016-11-11T11:29:33  <wumpus> yeah if someone wants to chase obscure rabbits there's enough issues, for example the bench crash on freebsd
285 2016-11-11T11:30:40  <wumpus> I just don't have the conviction anymore, after reading around a bit and googling for WShadow, that it's not going to be an endless source of busywork
286 2016-11-11T11:31:06  <wumpus> even if you enable it by default you may not see any warnings, but someone wit hcompiler Y might
287 2016-11-11T11:31:12  <wumpus> resulting in tons of extra nits on every pull
288 2016-11-11T11:32:28  <wumpus> or 'fix Wshadow after blablba' commits forever
289 2016-11-11T11:34:19  <fanquake> Indeed. I guess we either define some set/range of compilers, and guarantee them to be warning-less, and suggest their use? Or as you say, possibly enable it by default for only that set.
290 2016-11-11T11:34:58  <fanquake> I think the improvements/potential bug catching effects of having it turned on should outweigh potential concerns?
291 2016-11-11T11:37:31  <MarcoFalke> If you enable it only for a specific set of compilers, it is the same issue as enabling it for all compilers and having compilers handle it differently.
292 2016-11-11T11:37:49  <MarcoFalke> Sadly there is no -Wshadow-common-for-all-compilers
293 2016-11-11T11:46:09  <phantomcircuit> wumpus: the parsing is done by the CWallet dummyWallet
294 2016-11-11T11:46:13  <phantomcircuit> which i removed entirely
295 2016-11-11T11:46:31  <phantomcircuit> so the exception handling is basically just for the type not parsing
296 2016-11-11T11:47:20  <MarcoFalke> phantomcircuit: Maybe add a comment why that case is not needed to be handled
297 2016-11-11T11:48:12  *** DigiByteDev has joined #bitcoin-core-dev
298 2016-11-11T12:23:32  *** cryptapus has joined #bitcoin-core-dev
299 2016-11-11T12:23:32  *** cryptapus has joined #bitcoin-core-dev
300 2016-11-11T12:26:13  *** cryptapus has quit IRC
301 2016-11-11T12:39:42  <Victorsueca> ok, so I got #8456 built
302 2016-11-11T12:39:43  <gribble> https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
303 2016-11-11T12:40:22  <Victorsueca> how do I create a BIP 125 transaction?
304 2016-11-11T12:49:56  <jonasschnelli> Victorsueca: createrawtransaction
305 2016-11-11T12:50:06  <jonasschnelli> Victorsueca: set nSequence to INT::MAX-2
306 2016-11-11T12:50:09  <jonasschnelli> but wait..
307 2016-11-11T12:50:10  *** Ylbam has quit IRC
308 2016-11-11T12:50:58  <Victorsueca> yeah, I'm trying to use createrawtransaction but not sure how to signal that the transaction is replaceable
309 2016-11-11T12:51:14  <jonasschnelli> I though we have a global OptInRBF flag...
310 2016-11-11T12:51:23  <jonasschnelli> but looks like we never merged it..
311 2016-11-11T12:51:26  * jonasschnelli checking...
312 2016-11-11T12:51:45  <Victorsueca> i'm currently using head f3833f4
313 2016-11-11T12:52:02  <jonasschnelli> Victorsueca: we have one!
314 2016-11-11T12:52:04  <jonasschnelli> -walletrbf=1
315 2016-11-11T12:52:09  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8601/files
316 2016-11-11T12:52:17  <Victorsueca> nice, will try that
317 2016-11-11T12:52:32  <jonasschnelli> This will autoset the inputs nSequence Number to INT::MAX-2
318 2016-11-11T12:52:43  <jonasschnelli> phantomcircuit: ping
319 2016-11-11T12:53:01  <jonasschnelli> In PR9101 you mentioned that "Removes the last dependency from walletdb.cpp on CWallet."
320 2016-11-11T12:53:13  <jonasschnelli> I see other CWallet interaction in walletdb.cpp
321 2016-11-11T12:53:30  <jonasschnelli> IMO CWalletDB should be hidden behind CWallet
322 2016-11-11T12:53:45  <jonasschnelli> And CWalletDB should habe no knowhow of CWallet
323 2016-11-11T12:54:17  *** JackH has quit IRC
324 2016-11-11T12:55:12  *** moli has joined #bitcoin-core-dev
325 2016-11-11T12:56:11  *** JackH has joined #bitcoin-core-dev
326 2016-11-11T12:58:53  <Victorsueca> nice, it worked
327 2016-11-11T12:59:34  <Victorsueca> got to bump the fee for a transaction from 260sat to 520sat
328 2016-11-11T13:00:06  *** cdecker has joined #bitcoin-core-dev
329 2016-11-11T13:00:44  <wumpus> phantomcircuit: why would 'type not handled' not need to be warned about?
330 2016-11-11T13:02:29  <Victorsueca> here's the result https://softnet.homenet.org/zerobin/?915143c9d44e6ad6#gzz/IhVKwH2IRWeZoIuYermb53dUYWjEhY3sTtwc9Sk=
331 2016-11-11T13:09:28  <jonasschnelli> Victorsueca: nice! Please report on the PR and ACK
332 2016-11-11T13:11:31  <bitcoin-git> [bitcoin] jonasschnelli opened pull request #9131: fNetworkActive is not protected by a lock, use an atomic (master...2016/11/net_toggle) https://github.com/bitcoin/bitcoin/pull/9131
333 2016-11-11T13:13:47  *** cryptapus has joined #bitcoin-core-dev
334 2016-11-11T13:13:47  *** cryptapus has joined #bitcoin-core-dev
335 2016-11-11T13:21:35  *** cryptapus has quit IRC
336 2016-11-11T13:24:54  *** cryptapus has joined #bitcoin-core-dev
337 2016-11-11T13:28:01  *** fanquake has quit IRC
338 2016-11-11T13:37:49  <Victorsueca> done, ping me whenever you need to test something on windows
339 2016-11-11T13:40:33  *** luke-jr has quit IRC
340 2016-11-11T13:40:43  *** luke-jr has joined #bitcoin-core-dev
341 2016-11-11T13:41:13  <jonasschnelli> Victorsueca : thx
342 2016-11-11T13:41:25  <Victorsueca> no problem
343 2016-11-11T13:54:50  *** laurentmt has joined #bitcoin-core-dev
344 2016-11-11T13:56:59  *** laurentmt has quit IRC
345 2016-11-11T13:58:34  *** mistermister has quit IRC
346 2016-11-11T14:13:01  *** DigiByteDev has quit IRC
347 2016-11-11T14:43:36  *** cryptapus has quit IRC
348 2016-11-11T14:48:37  *** cryptapus has joined #bitcoin-core-dev
349 2016-11-11T15:00:55  *** jtimon has joined #bitcoin-core-dev
350 2016-11-11T15:05:36  <bitcoin-git> [bitcoin] morcos opened pull request #9133: Unset fImporting for loading mempool (master...noImportLoadMempool) https://github.com/bitcoin/bitcoin/pull/9133
351 2016-11-11T15:31:23  *** aalex has joined #bitcoin-core-dev
352 2016-11-11T15:32:03  *** PatBoy has quit IRC
353 2016-11-11T15:59:25  *** abpa has quit IRC
354 2016-11-11T16:00:27  *** PatBoy has joined #bitcoin-core-dev
355 2016-11-11T16:06:39  *** aalex has quit IRC
356 2016-11-11T16:18:31  *** Ylbam has joined #bitcoin-core-dev
357 2016-11-11T16:22:48  *** cryptapus has quit IRC
358 2016-11-11T16:44:37  *** abpa has joined #bitcoin-core-dev
359 2016-11-11T16:49:23  *** GoogleHater has joined #bitcoin-core-dev
360 2016-11-11T16:49:29  <GoogleHater> Hello.
361 2016-11-11T16:49:48  <GoogleHater> Why speed limit isn't implemented in Bitcoin Core?
362 2016-11-11T17:00:17  <Lauda> What speed limit?
363 2016-11-11T17:00:22  *** tulip has joined #bitcoin-core-dev
364 2016-11-11T17:09:32  *** Chris_Stewart_5 has quit IRC
365 2016-11-11T17:10:39  *** Evel-Knievel has joined #bitcoin-core-dev
366 2016-11-11T17:10:49  <GoogleHater> It's too hard for me to download 100 GB without half-speed.
367 2016-11-11T17:11:20  *** Chris_Stewart_5 has joined #bitcoin-core-dev
368 2016-11-11T17:13:40  <tulip> > and what if rowhammer is a backdoor and was implemented on purpose?
369 2016-11-11T17:13:40  <tulip> Victorsueca: it's a physical property. on a deep level a lot of what you do in software can have an impact on other things electrically. for example, without care one circuit turning on can be enough to "trigger" others near a threshold. normally random timings become synchronised as a result.
370 2016-11-11T17:23:24  <Victorsueca> GoogleHater: I think it's planned to add a feature to limit or halt bandwidth usage
371 2016-11-11T17:23:38  <Victorsueca> tulip: ik, I was joking
372 2016-11-11T17:23:58  <GoogleHater> Second problem.
373 2016-11-11T17:24:24  <GoogleHater> I'm using Tor through iptables.
374 2016-11-11T17:24:41  <GoogleHater> My Bitcoin Core does not finding *.onion peers.
375 2016-11-11T17:26:28  <Victorsueca> try adding yu7sezmixhmyljn4.onion, it's mine
376 2016-11-11T17:31:43  *** Giszmo has quit IRC
377 2016-11-11T17:39:36  <GoogleHater> I'm using Testnet now.
378 2016-11-11T17:39:54  <GoogleHater> But I want to use mainnet soon.
379 2016-11-11T17:40:29  <Victorsueca> ahh wait a second, i'll boot my testnet node
380 2016-11-11T17:44:19  <Victorsueca> there, my testnet node is at agw4m7vx4gceyttj.onion
381 2016-11-11T18:12:10  *** DigiByteDev has joined #bitcoin-core-dev
382 2016-11-11T18:16:17  *** DigiByteDev has quit IRC
383 2016-11-11T18:28:28  *** cryptapus has joined #bitcoin-core-dev
384 2016-11-11T18:28:29  *** cryptapus has joined #bitcoin-core-dev
385 2016-11-11T19:04:37  *** jtimon has quit IRC
386 2016-11-11T19:30:13  *** Arnavion has quit IRC
387 2016-11-11T19:31:32  *** Arnavion has joined #bitcoin-core-dev
388 2016-11-11T19:40:00  *** Chris_Stewart_5 has quit IRC
389 2016-11-11T19:40:18  *** tulip has quit IRC
390 2016-11-11T19:45:39  <phantomcircuit> wumpus: i dont think it can actually fail
391 2016-11-11T19:52:07  <phantomcircuit> yeah im pretty sure that ssKey >> strType; cannot fail actually
392 2016-11-11T19:58:07  *** abc has joined #bitcoin-core-dev
393 2016-11-11T19:58:29  *** abc is now known as Guest24458
394 2016-11-11T20:00:01  *** Guest24458 has quit IRC
395 2016-11-11T20:00:31  *** Guyver2 has joined #bitcoin-core-dev
396 2016-11-11T20:06:10  *** jannes has quit IRC
397 2016-11-11T20:10:01  *** d9b4bef9 has quit IRC
398 2016-11-11T20:10:58  *** rabidus_ has quit IRC
399 2016-11-11T20:21:26  <sipa> phantomcircuit: what if ssKey is empty?
400 2016-11-11T20:23:33  *** Giszmo has joined #bitcoin-core-dev
401 2016-11-11T20:46:36  *** dermoth has quit IRC
402 2016-11-11T21:02:12  *** GoogleHater has quit IRC
403 2016-11-11T21:07:52  *** cryptapus has quit IRC
404 2016-11-11T21:09:23  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9136: sync_blocks cleanup (master...sync-clean) https://github.com/bitcoin/bitcoin/pull/9136
405 2016-11-11T21:10:16  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9137: WIP: Allow wallet key import RPCs to track TxOut amounts on -prune nodes (master...import-pruned) https://github.com/bitcoin/bitcoin/pull/9137
406 2016-11-11T21:14:09  *** chris2000 has quit IRC
407 2016-11-11T21:30:04  *** whphhg has joined #bitcoin-core-dev
408 2016-11-11T21:30:04  <bitcoin-git> [bitcoin] morcos opened pull request #9138: Improve fee estimation (master...refactorFeeEstimation) https://github.com/bitcoin/bitcoin/pull/9138
409 2016-11-11T21:32:42  <bitcoin-git> [bitcoin] morcos closed pull request #9123: Remove extraneous LogPrint from fee estimation (master...eliminateFeeWarning) https://github.com/bitcoin/bitcoin/pull/9123
410 2016-11-11T21:37:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
411 2016-11-11T21:39:32  *** achow101 has quit IRC
412 2016-11-11T21:52:44  <phantomcircuit> sipa: i guess it would fail then?
413 2016-11-11T21:54:25  *** achow101 has joined #bitcoin-core-dev
414 2016-11-11T21:55:21  <sipa> phantomcircuit: yes, std::ios_base::failure("CDataStream::read(): end of data")
415 2016-11-11T21:57:37  <phantomcircuit> the question is really how much checking of the result do we want to do?
416 2016-11-11T21:57:46  <sipa> phantomcircuit: i miss context
417 2016-11-11T22:04:36  *** nibor has joined #bitcoin-core-dev
418 2016-11-11T22:07:53  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9139: Change sync_blocks to pick smarter maxheight (master...sync-height) https://github.com/bitcoin/bitcoin/pull/9139
419 2016-11-11T22:09:42  *** zmanian____ has quit IRC
420 2016-11-11T22:09:55  *** zmanian has joined #bitcoin-core-dev
421 2016-11-11T22:11:34  *** Chris_Stewart_5 has quit IRC
422 2016-11-11T22:14:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
423 2016-11-11T22:17:50  *** Guyver2 has quit IRC
424 2016-11-11T22:30:36  *** cryptapus_afk is now known as cryptapus
425 2016-11-11T22:42:21  *** cryptapus has joined #bitcoin-core-dev
426 2016-11-11T22:42:22  *** cryptapus has joined #bitcoin-core-dev
427 2016-11-11T22:42:28  *** cryptapus is now known as cryptapus_afk
428 2016-11-11T22:56:06  *** luke-jr has quit IRC
429 2016-11-11T22:56:14  *** luke-jr has joined #bitcoin-core-dev
430 2016-11-11T23:07:59  *** btcdrak has quit IRC
431 2016-11-11T23:18:15  *** niska` has joined #bitcoin-core-dev
432 2016-11-11T23:18:26  *** niska has quit IRC
433 2016-11-11T23:31:38  *** abpa has quit IRC