1 2016-11-11 01:58:55	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #9125: Make CBlock a vector of shared_ptr of CTransactions (06master...06sharedblock) 02https://github.com/bitcoin/bitcoin/pull/9125
  2 2016-11-11 02:20:08	0|cfields|sipa: interesting
  3 2016-11-11 02:20:39	0|sipa|cfields: the PR above?
  4 2016-11-11 02:20:45	0|cfields|sipa: yes
  5 2016-11-11 02:21:08	0|sipa|i was surprised that i didn't need to touch any of the block or transaction serialization logic
  6 2016-11-11 02:21:31	0|cfields|yes, it's simpler than I would've expected too
  7 2016-11-11 02:21:46	0|cfields|trying to decide how much foot-gun the serialize.h changes allow
  8 2016-11-11 02:22:27	0|sipa|the shared_ptr serializer only applies when the element type is const
  9 2016-11-11 02:27:57	0|cfields|sipa: yep, actually seems innocuous
 10 2016-11-11 02:28:56	0|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
 11 2016-11-11 02:29:56	0|sipa|cfields: right, but that doesn't apply when the element type is const
 12 2016-11-11 02:30:11	0|sipa|you can just see the different shared_ptr's as deduplicated copies of the same data
 13 2016-11-11 02:30:54	0|cfields|yes. I like it :)
 14 2016-11-11 02:32:47	0|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.
 15 2016-11-11 02:36:02	0|cfields|yes, this seems like a really good use-case.
 16 2016-11-11 02:40:44	0|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.
 17 2016-11-11 02:40:50	0|cfields|s/requires/allows/
 18 2016-11-11 02:42:33	0|sipa|cfields: well that would better be served by using shared_ptr's to CBlock itself
 19 2016-11-11 02:43:23	0|cfields|sipa: i was wondering if that's the next logical step. I don't think they'd be mutually exclusive?
 20 2016-11-11 02:45:07	0|sipa|cfields: sure
 21 2016-11-11 02:47:20	0|sipa|there are probably a few more optimizations that i haven't addressed
 22 2016-11-11 02:47:31	0|sipa|i think ATMP should take a shared_ptr
 23 2016-11-11 02:47:56	0|sipa|so a reorg wouldn't require a copy back from the block to the mempool
 24 2016-11-11 06:28:29	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #9128: net: Decouple CConnman and message serialization (06master...06connman-send) 02https://github.com/bitcoin/bitcoin/pull/9128
 25 2016-11-11 06:38:51	0|bitcoin-git|[13bitcoin] 15rebroad opened pull request #9129: One fDisconnect to rule them all (06master...06OnefDisconnect) 02https://github.com/bitcoin/bitcoin/pull/9129
 26 2016-11-11 07:08:33	0|luke-jr|should we be using std::random_device?
 27 2016-11-11 07:10:25	0|sipa|luke-jr: afaik it has 0 guarantees
 28 2016-11-11 07:10:58	0|luke-jr|can't hurt though, right?
 29 2016-11-11 07:11:40	0|luke-jr|(and what's the point of the exception if there's no guarantees at all? O.o)
 30 2016-11-11 07:13:49	0|sipa|the exception is for when no random number can be generated at all
 31 2016-11-11 07:14:10	0|sipa|even if it generates one, it doesn't guarantee cryptographic quality (or any quality at all)
 32 2016-11-11 08:57:32	0|fanquake|Competing pull-requests seems to be a "thing" now..
 33 2016-11-11 09:04:46	0|wumpus|yeah...
 34 2016-11-11 09:05:46	0|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
 35 2016-11-11 09:07:33	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9129: One fDisconnect to rule them all (06master...06OnefDisconnect) 02https://github.com/bitcoin/bitcoin/pull/9129
 36 2016-11-11 09:07:45	0|bitcoin-git|13bitcoin/06master 14617c96d 15fanquake: [depends] Set OSX_MIN_VERSION to 10.8
 37 2016-11-11 09:07:45	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/71bc39eb7483...21e6c6b569c5
 38 2016-11-11 09:07:46	0|bitcoin-git|13bitcoin/06master 1421e6c6b 15Wladimir J. van der Laan: Merge #9114: [depends] Set OSX_MIN_VERSION to 10.8...
 39 2016-11-11 09:07:53	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9114: [depends] Set OSX_MIN_VERSION to 10.8 (06master...06depends-min-osx-10-8) 02https://github.com/bitcoin/bitcoin/pull/9114
 40 2016-11-11 09:08:17	0|wumpus|we're better off implementing our own secure random functionality, given how critical it is for the wallet at least
 41 2016-11-11 09:09:14	0|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...
 42 2016-11-11 09:11:02	0|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?
 43 2016-11-11 09:11:27	0|wumpus|Victorsueca: maybe. At the least we should be reading /dev/urandom ourselves
 44 2016-11-11 09:12:01	0|wumpus|it's not rocket science and there is nothing to be gained by hiding it behind layers of abstraction
 45 2016-11-11 09:12:45	0|Victorsueca|sounds good, definitely better than using the default source of randomness which could be backdoored by the hardware manufacturer
 46 2016-11-11 09:13:44	0|sipa|if your hardware is backdoored, the technical term for the situation you're in is: utterly fucked
 47 2016-11-11 09:13:47	0|wumpus|that's not really the threat model we're fighting here...
 48 2016-11-11 09:13:54	0|wumpus|right
 49 2016-11-11 09:14:17	0|luke-jr|wumpus: I just meant in addition to other entropy sources
 50 2016-11-11 09:15:39	0|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
 51 2016-11-11 09:16:55	0|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
 52 2016-11-11 09:17:20	0|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...
 53 2016-11-11 09:17:21	0|luke-jr|just happened to glance at that shell at the right instant
 54 2016-11-11 09:17:45	0|luke-jr|eh, Intel ME is a pretty low risk explicit backdoor
 55 2016-11-11 09:17:45	0|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
 56 2016-11-11 09:17:58	0|Victorsueca|is the kind of thing I never seen but I think it should already exist
 57 2016-11-11 09:18:15	0|luke-jr|Victorsueca: pretty sure something does using radio waves
 58 2016-11-11 09:18:17	0|wumpus|luke-jr: well in any case thanks for letting me know it exists at all, it may be useful for some other projects
 59 2016-11-11 09:19:12	0|wumpus|Victorsueca: those exist and are in active use, both for secure randomness and by gambling sites
 60 2016-11-11 09:20:17	0|Victorsueca|wumpus: thought gambling sites used atomic event observation which is pretty expensive devices, I was thinking on something affordable for any home user
 61 2016-11-11 09:20:38	0|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 :-)
 62 2016-11-11 09:20:57	0|luke-jr|heh
 63 2016-11-11 09:21:23	0|Victorsueca|and what if rowhammer is a backdoor and was implemented on purpose?
 64 2016-11-11 09:21:45	0|wumpus|Victorsueca: there's low end and high end devices in that range, just a google away :p
 65 2016-11-11 09:22:35	0|wumpus|you can even build a randomness device pretty easily yourself, building unstable hardware is not rocket science :-)
 66 2016-11-11 09:23:16	0|Victorsueca|wumpus: maybe, but preventing it from putting your house on fire is ;)
 67 2016-11-11 09:23:40	0|Victorsueca|then use the shape of the flames as random source
 68 2016-11-11 09:27:11	0|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
 69 2016-11-11 09:27:17	0|wumpus|similar, though much more general.
 70 2016-11-11 09:27:49	0|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)
 71 2016-11-11 09:28:52	0|wumpus|Victorsueca: ascribing such natural engineering properties to state actors is paranoid to the level of schizofrenia :)
 72 2016-11-11 09:29:53	0|wumpus|*finding* these kinds of bugs on the other hand is something they're certainly working very hard at
 73 2016-11-11 09:30:11	0|Victorsueca|they control temperature and humidity to manipulate your randomness
 74 2016-11-11 09:33:38	0|Victorsueca|jokes apart, Yesterday I had an idea
 75 2016-11-11 09:34:21	0|Victorsueca|would be possible to make that after abandoning a transaction core spends the same inputs for the next transaction you make?
 76 2016-11-11 09:34:51	0|Victorsueca|I think it's possible, the question would rather be if it makes sense
 77 2016-11-11 09:35:56	0|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
 78 2016-11-11 09:36:44	0|wumpus|delaying it until you happen to need to send again creates a potentially huge time window in which you're exposed
 79 2016-11-11 09:36:58	0|Victorsueca|I was thinking on somebody who has his transaction stuck because ha paid a low fee
 80 2016-11-11 09:37:13	0|Victorsueca|so he abandons the transaction and double-spends it with a higher fee
 81 2016-11-11 09:37:20	0|wumpus|just use RBF?
 82 2016-11-11 09:37:51	0|Victorsueca|then why is there a banadon transaction button at all?
 83 2016-11-11 09:37:59	0|Victorsueca|abandon*
 84 2016-11-11 09:38:21	0|Victorsueca|not to mention RBF is not yet implemented in the GUI
 85 2016-11-11 09:39:21	0|wumpus|bumpfee needs to be on RPC first e.g. see https://github.com/bitcoin/bitcoin/pull/8456
 86 2016-11-11 09:39:28	0|wumpus|all needs review
 87 2016-11-11 09:39:51	0|wumpus|sorry to say this but we need more review and testing on actual work people are doing, not out-there ideas
 88 2016-11-11 09:40:22	0|Victorsueca|it's ok
 89 2016-11-11 09:41:30	0|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
 90 2016-11-11 09:41:40	0|wumpus|no, it's not
 91 2016-11-11 09:41:50	0|Victorsueca|thought so
 92 2016-11-11 09:42:04	0|wumpus|changes to coin selection are one of the most difficult categories of changes
 93 2016-11-11 09:46:52	0|Victorsueca|well, I can help testing changes on windows, AFAIK few devs work on windows
 94 2016-11-11 09:50:55	0|wumpus|awesome!
 95 2016-11-11 09:50:59	0|fanquake|Great!
 96 2016-11-11 09:51:38	0|fanquake|There is always need for more reviewers, especially on Windows, because as you've mentioned, few devs are using it.
 97 2016-11-11 09:52:41	0|wumpus|yes especially for GUI changes there's pretty few testers at all
 98 2016-11-11 09:52:53	0|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.
 99 2016-11-11 09:52:55	0|fanquake|https://github.com/bitcoin/bitcoin/issues?q=is%3Aopen+is%3Aissue+label%3AWindows
100 2016-11-11 09:53:39	0|jonasschnelli|For multiwallet, this PR is large but simple to review: https://github.com/bitcoin/bitcoin/pull/8764
101 2016-11-11 09:54:16	0|phantomcircuit|wumpus: the wallet recovery stuff will print a warning if it fails to parse the value in the key/value pair
102 2016-11-11 09:54:28	0|phantomcircuit|this is the last reference to CWallet from CWalletDB
103 2016-11-11 09:54:36	0|phantomcircuit|i have a patch that just removes this
104 2016-11-11 09:54:44	0|phantomcircuit|i'd like to know what you think about it
105 2016-11-11 09:54:53	0|phantomcircuit|(not the patch, removing the warning)
106 2016-11-11 09:54:58	0|wumpus|please don't remove that warning. You can't move it anywhere else?
107 2016-11-11 09:55:15	0|wumpus|we have open issues with salvagewallet that's why the debug level there was increased
108 2016-11-11 09:55:41	0|wumpus|https://github.com/bitcoin/bitcoin/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20salvagewallet
109 2016-11-11 09:55:51	0|phantomcircuit|ok i'll take another look at it to see if there's a better way of handling that
110 2016-11-11 09:56:11	0|phantomcircuit|(i mean really the better way would be a completely separate tool, but that is not in scope)
111 2016-11-11 09:56:37	0|fanquake|wumpus: I've ack'd #9112 if you just want to merge it.
112 2016-11-11 09:56:39	0|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
113 2016-11-11 09:57:07	0|wumpus|phantomcircuit: jonasschnelli made such a tool https://github.com/bitcoin/bitcoin/pull/8745  - but yeah that's out of scope
114 2016-11-11 09:57:42	0|jonasschnelli|wumpus: we first need to solve the cirular dependencies.
115 2016-11-11 09:57:45	0|jonasschnelli|*circular
116 2016-11-11 09:57:45	0|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
117 2016-11-11 09:59:24	0|bitcoin-git|13bitcoin/06master 14e9f25dd 15Wladimir J. van der Laan: Avoid ugly exception in log on unknown inv type...
118 2016-11-11 09:59:24	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/21e6c6b569c5...46027e8668ec
119 2016-11-11 09:59:25	0|bitcoin-git|13bitcoin/06master 1446027e8 15Wladimir J. van der Laan: Merge #9112: Avoid ugly exception in log on unknown inv type...
120 2016-11-11 09:59:34	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9112: Avoid ugly exception in log on unknown inv type (06master...062016_11_invtype_debugging) 02https://github.com/bitcoin/bitcoin/pull/9112
121 2016-11-11 09:59:44	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9113: Return the type when it's unknown instead of throwing an exception (06master...06ReturnNotThrow) 02https://github.com/bitcoin/bitcoin/pull/9113
122 2016-11-11 10:02:31	0|Victorsueca|how do you do to pull a unmerged pull request into your working directory?
123 2016-11-11 10:03:05	0|fanquake|Have a look at the github-merge script in this dir https://github.com/bitcoin/bitcoin/tree/master/contrib/devtools
124 2016-11-11 10:03:15	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/46027e8668ec...7977a1157a3a
125 2016-11-11 10:03:15	0|wumpus|contrib/devtools/github-merge.py 1234
126 2016-11-11 10:03:16	0|bitcoin-git|13bitcoin/06master 1447e9659 15Russell Yanofsky: [qa] Fix bug in compactblocks v2 merge...
127 2016-11-11 10:03:16	0|bitcoin-git|13bitcoin/06master 1455bfddc 15Russell Yanofsky: [qa] Fix stale data bug in test_compactblocks_not_at_tip...
128 2016-11-11 10:03:17	0|bitcoin-git|13bitcoin/06master 14dac53b5 15Russell Yanofsky: Modify getblocktxn handler not to drop requests for old blocks...
129 2016-11-11 10:03:18	0|wumpus|yes, that :)
130 2016-11-11 10:03:26	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9058: Fixes for p2p-compactblocks.py test timeouts on travis (#8842) (06master...06fix-8842-sync-timeouts) 02https://github.com/bitcoin/bitcoin/pull/9058
131 2016-11-11 10:04:07	0|jonasschnelli|heh
132 2016-11-11 10:04:46	0|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
133 2016-11-11 10:05:22	0|wumpus|(where "upstream" is the name of your remote for bitcoin/bitcoin, big chance it is "origin" for you)
134 2016-11-11 10:05:28	0|jonasschnelli|For testing, it's probably better if you test them applied on the current master
135 2016-11-11 10:05:36	0|jonasschnelli|(unless they have merge conflicts)
136 2016-11-11 10:05:40	0|wumpus|yes, true
137 2016-11-11 10:14:01	0|Victorsueca|ok, got it, thanks
138 2016-11-11 10:15:14	0|Victorsueca|building it at the moment
139 2016-11-11 10:16:59	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7977a1157a3a...ab914a65301b
140 2016-11-11 10:17:00	0|bitcoin-git|13bitcoin/06master 147c9a98a 15Jon Lund Steffensen: Allow network activity to be temporarily suspended....
141 2016-11-11 10:17:00	0|bitcoin-git|13bitcoin/06master 14e38993b 15Jon Lund Steffensen: RPC: Add "togglenetwork" method to toggle network activity temporarily...
142 2016-11-11 10:17:01	0|bitcoin-git|13bitcoin/06master 1432efa79 15Jon Lund Steffensen: Qt: Add GUI feedback and control of network activity state....
143 2016-11-11 10:17:10	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #8996: Network activity toggle (06master...06networkactive) 02https://github.com/bitcoin/bitcoin/pull/8996
144 2016-11-11 10:17:33	0|Victorsueca|it's me or this new bot is more spammy than the previous one?
145 2016-11-11 10:18:11	0|luke-jr|just you
146 2016-11-11 10:19:09	0|jonasschnelli|Luke-Jr: how do we continue with https://github.com/bitcoin/bitcoin/pull/8889? Close?
147 2016-11-11 10:19:57	0|luke-jr|for now
148 2016-11-11 10:20:05	0|bitcoin-git|[13bitcoin] 15luke-jr closed pull request #8889: Qt/ModalOverlay: Use theme tooltip colours (06master...06overlay_theme) 02https://github.com/bitcoin/bitcoin/pull/8889
149 2016-11-11 10:20:20	0|jonasschnelli|Okay. Yes. We can always reopen this.
150 2016-11-11 10:20:59	0|luke-jr|I suspect the problems were due to tooltips not normally having focus
151 2016-11-11 10:22:29	0|luke-jr|ie, the theme doesn't bother defining the tooltip-with-focus colours sanely
152 2016-11-11 10:25:46	0|wumpus|there is no 'new bot', I've just changed its configuration to use a consistent name
153 2016-11-11 10:26:07	0|wumpus|if it seems more spammy it's just because there's a lot of merging going on
154 2016-11-11 10:26:42	0|Victorsueca|ahh ok
155 2016-11-11 10:27:11	0|Victorsueca|0.14 seems like it's finally going to be a version dedicated to GUI and wallet
156 2016-11-11 10:27:12	0|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
157 2016-11-11 10:29:20	0|fanquake|wumpus: If you want to get the PR list down, there are a few trivial ones.
158 2016-11-11 10:29:40	0|wumpus|fanquake: sure, let me know
159 2016-11-11 10:29:42	0|fanquake|#9115 has been updated so can get ACK'd/merged.
160 2016-11-11 10:29:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/9115 | Mention reporting security issues responsibly by paveljanik · Pull Request #9115 · bitcoin/bitcoin · GitHub
161 2016-11-11 10:30:47	0|bitcoin-git|13bitcoin/06master 147d1de30 15Pavel Janík: Mention reporting security issues responsibly
162 2016-11-11 10:30:47	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ab914a65301b...bfc7aad00884
163 2016-11-11 10:30:48	0|bitcoin-git|13bitcoin/06master 14bfc7aad 15Wladimir J. van der Laan: Merge #9115: Mention reporting security issues responsibly...
164 2016-11-11 10:30:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9115: Mention reporting security issues responsibly (06master...0620161109_secissues) 02https://github.com/bitcoin/bitcoin/pull/9115
165 2016-11-11 10:31:16	0|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.
166 2016-11-11 10:31:18	0|gribble|https://github.com/bitcoin/bitcoin/issues/9064 | unify capitalization of "bitcoin address" by s-matthew-english · Pull Request #9064 · bitcoin/bitcoin · GitHub
167 2016-11-11 10:32:40	0|wumpus|ooh capitalizing Bitcoin just now that internet is no longer going to be capitalized :)
168 2016-11-11 10:32:52	0|Victorsueca|heh
169 2016-11-11 10:33:51	0|wumpus|I don't really care, I guess it makes sense to be consistent though...
170 2016-11-11 10:34:12	0|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.
171 2016-11-11 10:34:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/8983 | WIP: Log block height and size when received by rebroad · Pull Request #8983 · bitcoin/bitcoin · GitHub
172 2016-11-11 10:34:30	0|paveljanik|wumpus, internet and Internet are two different things... ;-)
173 2016-11-11 10:35:08	0|Victorsueca|shouldn't be really difficult to change capitals, except for some languages like German where concepts are one-worded
174 2016-11-11 10:35:44	0|wumpus|paveljanik: "the internet of different things"
175 2016-11-11 10:36:37	0|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
176 2016-11-11 10:37:35	0|Victorsueca|not to mention that could cause people blames capitals being wrong, I still remember when someone put "advertize" in the log messages
177 2016-11-11 10:37:58	0|Victorsueca|almost starts WW3
178 2016-11-11 10:38:12	0|wumpus|capital punishment
179 2016-11-11 10:39:34	0|fanquake|#9124 Is a trivial merge, variable renaming in the benchmarking code.
180 2016-11-11 10:39:35	0|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
181 2016-11-11 10:39:54	0|wumpus|phantomcircuit: I don't understand why you can't keep a warning in #9101 when the try{...} fails
182 2016-11-11 10:39:56	0|gribble|https://github.com/bitcoin/bitcoin/issues/9101 | [Wallet] Do not parse ssValue in CWalletDB::Recover by pstratem · Pull Request #9101 · bitcoin/bitcoin · GitHub
183 2016-11-11 10:40:52	0|wumpus|you do catch(...) { continue; } silently ignoring aspecific exceptions is usually a code smell and means there should be a warning at least
184 2016-11-11 10:43:17	0|wumpus|silent errors mean that someone is going to have a very difficult time troubleshooting at some point
185 2016-11-11 10:44:18	0|Victorsueca|what about make it silent by default but not when -debug is enabled?
186 2016-11-11 10:44:38	0|wumpus|WHY?
187 2016-11-11 10:44:50	0|wumpus|salvagewallet is already a troubleshooting option
188 2016-11-11 10:44:56	0|Victorsueca|right
189 2016-11-11 10:45:07	0|wumpus|why the hell would you want to have people enable debug to see when things go wrong? that's nonsense
190 2016-11-11 10:46:12	0|Victorsueca|maybe somebody who expects salvagewallet to go well doesn't want his logs nuked with lots of lines
191 2016-11-11 10:46:25	0|Victorsueca|if something goes wrong you can always try again with -debug
192 2016-11-11 10:46:36	0|wumpus|if it goes well there will be no logging because it won't get there!
193 2016-11-11 10:47:20	0|Victorsueca|hmmm I don't know what would I do
194 2016-11-11 10:47:41	0|wumpus|you're worrying about the bedsprings being noisy on the titanic while it is colliding against an iceberg
195 2016-11-11 10:47:51	0|rabidus_|:DD
196 2016-11-11 10:47:53	0|Victorsueca|heh yeah
197 2016-11-11 10:48:57	0|bitcoin-git|13bitcoin/06master 14bf49f10 15Pavel Janík: Use better name for local variable to prevent -Wshadow compiler warning
198 2016-11-11 10:48:57	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bfc7aad00884...87ab49e4fe38
199 2016-11-11 10:48:58	0|bitcoin-git|13bitcoin/06master 1487ab49e 15Wladimir J. van der Laan: Merge #9124: Use better name for local variable to prevent -Wshadow compiler warning...
200 2016-11-11 10:49:10	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9124: Use better name for local variable to prevent -Wshadow compiler warning (06master...0620161110_Wshadow_benchcheckblock) 02https://github.com/bitcoin/bitcoin/pull/9124
201 2016-11-11 10:49:23	0|Victorsueca|- Mr president, the poles are melting, the global warming has reached too high extremes
202 2016-11-11 10:49:33	0|Victorsueca|- Thanks for informing, now go away
203 2016-11-11 10:49:47	0|Victorsueca|President* Looks at a Titanic picture
204 2016-11-11 10:49:55	0|Victorsueca|- The revenge is ours!
205 2016-11-11 10:51:39	0|fanquake|#9100 is another fairly trivial one, with your questions answered.
206 2016-11-11 10:51:40	0|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
207 2016-11-11 11:02:03	0|bitcoin-git|[13bitcoin] 15paveljanik opened pull request #9130: Mention the new network toggle functionality in the tooltip. (06master...0620161111_disable_network_tooltip) 02https://github.com/bitcoin/bitcoin/pull/9130
208 2016-11-11 11:10:22	0|wumpus|I'd like an ack from someone else on #9100 before merging
209 2016-11-11 11:10:23	0|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
210 2016-11-11 11:10:27	0|wumpus|I'm not sure enough about it
211 2016-11-11 11:11:34	0|wumpus|I think it's ok though
212 2016-11-11 11:23:08	0|fanquake|wumpus: I'll look at that shortly.
213 2016-11-11 11:24:21	0|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.
214 2016-11-11 11:25:28	0|fanquake|I'm working on making the maintainer tools run on OS X so there are a few more people running them.
215 2016-11-11 11:27:38	0|wumpus|for the Wshadow stuff I want to be entirely sure that it doesn't cause floods of warnings for anyone
216 2016-11-11 11:27:57	0|wumpus|I don't want to enable it again and get complaints that some obscure compiler is generating a shitton of senseless warnings
217 2016-11-11 11:28:31	0|fanquake|Sure. Is them some threshold for compiler age/obscureness.
218 2016-11-11 11:28:35	0|fanquake|*there
219 2016-11-11 11:29:00	0|wumpus|maybe  a solution that enables it conditionally for compilers where it is shown to be ok
220 2016-11-11 11:29:33	0|wumpus|yeah if someone wants to chase obscure rabbits there's enough issues, for example the bench crash on freebsd
221 2016-11-11 11:30:40	0|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
222 2016-11-11 11:31:06	0|wumpus|even if you enable it by default you may not see any warnings, but someone wit hcompiler Y might
223 2016-11-11 11:31:13	0|wumpus|resulting in tons of extra nits on every pull
224 2016-11-11 11:32:28	0|wumpus|or 'fix Wshadow after blablba' commits forever
225 2016-11-11 11:34:19	0|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.
226 2016-11-11 11:34:58	0|fanquake|I think the improvements/potential bug catching effects of having it turned on should outweigh potential concerns?
227 2016-11-11 11:37:32	0|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.
228 2016-11-11 11:37:50	0|MarcoFalke|Sadly there is no -Wshadow-common-for-all-compilers
229 2016-11-11 11:46:10	0|phantomcircuit|wumpus: the parsing is done by the CWallet dummyWallet
230 2016-11-11 11:46:13	0|phantomcircuit|which i removed entirely
231 2016-11-11 11:46:32	0|phantomcircuit|so the exception handling is basically just for the type not parsing
232 2016-11-11 11:47:20	0|MarcoFalke|phantomcircuit: Maybe add a comment why that case is not needed to be handled
233 2016-11-11 12:39:42	0|Victorsueca|ok, so I got #8456 built
234 2016-11-11 12:39:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/8456 | [RPC] Simplified bumpfee command. by mrbandrews · Pull Request #8456 · bitcoin/bitcoin · GitHub
235 2016-11-11 12:40:23	0|Victorsueca|how do I create a BIP 125 transaction?
236 2016-11-11 12:49:56	0|jonasschnelli|Victorsueca: createrawtransaction
237 2016-11-11 12:50:07	0|jonasschnelli|Victorsueca: set nSequence to INT::MAX-2
238 2016-11-11 12:50:10	0|jonasschnelli|but wait..
239 2016-11-11 12:50:59	0|Victorsueca|yeah, I'm trying to use createrawtransaction but not sure how to signal that the transaction is replaceable
240 2016-11-11 12:51:14	0|jonasschnelli|I though we have a global OptInRBF flag...
241 2016-11-11 12:51:24	0|jonasschnelli|but looks like we never merged it..
242 2016-11-11 12:51:45	0|Victorsueca|i'm currently using head f3833f4
243 2016-11-11 12:52:03	0|jonasschnelli|Victorsueca: we have one!
244 2016-11-11 12:52:04	0|jonasschnelli|-walletrbf=1
245 2016-11-11 12:52:09	0|jonasschnelli|https://github.com/bitcoin/bitcoin/pull/8601/files
246 2016-11-11 12:52:18	0|Victorsueca|nice, will try that
247 2016-11-11 12:52:32	0|jonasschnelli|This will autoset the inputs nSequence Number to INT::MAX-2
248 2016-11-11 12:52:44	0|jonasschnelli|phantomcircuit: ping
249 2016-11-11 12:53:02	0|jonasschnelli|In PR9101 you mentioned that "Removes the last dependency from walletdb.cpp on CWallet."
250 2016-11-11 12:53:13	0|jonasschnelli|I see other CWallet interaction in walletdb.cpp
251 2016-11-11 12:53:30	0|jonasschnelli|IMO CWalletDB should be hidden behind CWallet
252 2016-11-11 12:53:45	0|jonasschnelli|And CWalletDB should habe no knowhow of CWallet
253 2016-11-11 12:58:53	0|Victorsueca|nice, it worked
254 2016-11-11 12:59:35	0|Victorsueca|got to bump the fee for a transaction from 260sat to 520sat
255 2016-11-11 13:00:44	0|wumpus|phantomcircuit: why would 'type not handled' not need to be warned about?
256 2016-11-11 13:02:30	0|Victorsueca|here's the result https://softnet.homenet.org/zerobin/?915143c9d44e6ad6#gzz/IhVKwH2IRWeZoIuYermb53dUYWjEhY3sTtwc9Sk=
257 2016-11-11 13:09:28	0|jonasschnelli|Victorsueca: nice! Please report on the PR and ACK
258 2016-11-11 13:11:32	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9131: fNetworkActive is not protected by a lock, use an atomic (06master...062016/11/net_toggle) 02https://github.com/bitcoin/bitcoin/pull/9131
259 2016-11-11 13:37:49	0|Victorsueca|done, ping me whenever you need to test something on windows
260 2016-11-11 13:41:13	0|jonasschnelli|Victorsueca : thx
261 2016-11-11 13:41:25	0|Victorsueca|no problem
262 2016-11-11 15:05:37	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #9133: Unset fImporting for loading mempool (06master...06noImportLoadMempool) 02https://github.com/bitcoin/bitcoin/pull/9133
263 2016-11-11 16:49:30	0|GoogleHater|Hello.
264 2016-11-11 16:49:48	0|GoogleHater|Why speed limit isn't implemented in Bitcoin Core?
265 2016-11-11 17:00:18	0|Lauda|What speed limit?
266 2016-11-11 17:10:49	0|GoogleHater|It's too hard for me to download 100 GB without half-speed.
267 2016-11-11 17:13:40	0|tulip|> and what if rowhammer is a backdoor and was implemented on purpose?
268 2016-11-11 17:13:40	0|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.
269 2016-11-11 17:23:25	0|Victorsueca|GoogleHater: I think it's planned to add a feature to limit or halt bandwidth usage
270 2016-11-11 17:23:39	0|Victorsueca|tulip: ik, I was joking
271 2016-11-11 17:23:58	0|GoogleHater|Second problem.
272 2016-11-11 17:24:24	0|GoogleHater|I'm using Tor through iptables.
273 2016-11-11 17:24:41	0|GoogleHater|My Bitcoin Core does not finding *.onion peers.
274 2016-11-11 17:26:28	0|Victorsueca|try adding yu7sezmixhmyljn4.onion, it's mine
275 2016-11-11 17:39:37	0|GoogleHater|I'm using Testnet now.
276 2016-11-11 17:39:55	0|GoogleHater|But I want to use mainnet soon.
277 2016-11-11 17:40:30	0|Victorsueca|ahh wait a second, i'll boot my testnet node
278 2016-11-11 17:44:19	0|Victorsueca|there, my testnet node is at agw4m7vx4gceyttj.onion
279 2016-11-11 19:45:40	0|phantomcircuit|wumpus: i dont think it can actually fail
280 2016-11-11 19:52:07	0|phantomcircuit|yeah im pretty sure that ssKey >> strType; cannot fail actually
281 2016-11-11 20:21:26	0|sipa|phantomcircuit: what if ssKey is empty?
282 2016-11-11 21:09:24	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9136: sync_blocks cleanup (06master...06sync-clean) 02https://github.com/bitcoin/bitcoin/pull/9136
283 2016-11-11 21:10:16	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9137: WIP: Allow wallet key import RPCs to track TxOut amounts on -prune nodes (06master...06import-pruned) 02https://github.com/bitcoin/bitcoin/pull/9137
284 2016-11-11 21:30:05	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #9138: Improve fee estimation (06master...06refactorFeeEstimation) 02https://github.com/bitcoin/bitcoin/pull/9138
285 2016-11-11 21:32:43	0|bitcoin-git|[13bitcoin] 15morcos closed pull request #9123: Remove extraneous LogPrint from fee estimation (06master...06eliminateFeeWarning) 02https://github.com/bitcoin/bitcoin/pull/9123
286 2016-11-11 21:52:45	0|phantomcircuit|sipa: i guess it would fail then?
287 2016-11-11 21:55:21	0|sipa|phantomcircuit: yes, std::ios_base::failure("CDataStream::read(): end of data")
288 2016-11-11 21:57:38	0|phantomcircuit|the question is really how much checking of the result do we want to do?
289 2016-11-11 21:57:46	0|sipa|phantomcircuit: i miss context
290 2016-11-11 22:07:53	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #9139: Change sync_blocks to pick smarter maxheight (06master...06sync-height) 02https://github.com/bitcoin/bitcoin/pull/9139