1 2018-12-31T00:04:01  *** opdenkamp has joined #bitcoin-core-dev
  2 2018-12-31T00:20:41  *** jasonzhouu has quit IRC
  3 2018-12-31T00:21:26  *** jasonzhouu has joined #bitcoin-core-dev
  4 2018-12-31T00:22:43  *** promag has joined #bitcoin-core-dev
  5 2018-12-31T00:23:15  *** dgenr8 has quit IRC
  6 2018-12-31T00:24:44  *** dviola has quit IRC
  7 2018-12-31T00:31:01  *** jasonzhouu has quit IRC
  8 2018-12-31T00:32:25  *** jasonzhouu has joined #bitcoin-core-dev
  9 2018-12-31T01:06:45  *** keddek has joined #bitcoin-core-dev
 10 2018-12-31T01:14:52  *** grubles has quit IRC
 11 2018-12-31T01:33:27  *** promag has quit IRC
 12 2018-12-31T02:09:26  *** promag has joined #bitcoin-core-dev
 13 2018-12-31T02:17:57  *** promag has quit IRC
 14 2018-12-31T02:31:36  *** keddek has quit IRC
 15 2018-12-31T02:57:36  *** EagleTM has quit IRC
 16 2018-12-31T03:06:49  *** AaronvanW has quit IRC
 17 2018-12-31T03:26:26  *** grubles has joined #bitcoin-core-dev
 18 2018-12-31T03:48:01  *** rh0nj has quit IRC
 19 2018-12-31T03:51:07  *** rh0nj has joined #bitcoin-core-dev
 20 2018-12-31T03:58:07  <fanquake> wumpus Could merge #15061 before 1/1/19, save all the PRs that'll be opened to bump the same dates.
 21 2018-12-31T03:58:09  <gribble> https://github.com/bitcoin/bitcoin/issues/15061 | [Trivial] Update license year range to 2019 by emilengler · Pull Request #15061 · bitcoin/bitcoin · GitHub
 22 2018-12-31T03:59:28  <luke-jr> fanquake: they'll just open them to bump dates on the individual files :/
 23 2018-12-31T04:07:54  *** spinza has quit IRC
 24 2018-12-31T04:16:42  *** spinza has joined #bitcoin-core-dev
 25 2018-12-31T04:37:16  *** justan0theruser has joined #bitcoin-core-dev
 26 2018-12-31T04:38:23  *** justanotheruser has quit IRC
 27 2018-12-31T04:38:30  *** justan0theruser is now known as justanotheruser
 28 2018-12-31T04:44:23  *** cluelessperson has quit IRC
 29 2018-12-31T04:50:26  *** mistergold has joined #bitcoin-core-dev
 30 2018-12-31T04:52:35  *** cluelessperson has joined #bitcoin-core-dev
 31 2018-12-31T05:06:52  *** cluelessperson has quit IRC
 32 2018-12-31T05:14:55  *** cluelessperson has joined #bitcoin-core-dev
 33 2018-12-31T05:28:41  <arubi> cheers wumpus
 34 2018-12-31T05:47:05  *** CodeBlue1776 has quit IRC
 35 2018-12-31T05:47:22  *** CodeBlue1776 has joined #bitcoin-core-dev
 36 2018-12-31T05:53:30  *** Sathai has joined #bitcoin-core-dev
 37 2018-12-31T06:09:21  *** Sathai has quit IRC
 38 2018-12-31T06:16:33  *** irc_viewer_test has joined #bitcoin-core-dev
 39 2018-12-31T06:17:09  *** Klox has joined #bitcoin-core-dev
 40 2018-12-31T06:20:30  *** bitcoin-git has joined #bitcoin-core-dev
 41 2018-12-31T06:20:30  <bitcoin-git> [bitcoin] luke-jr opened pull request #15068: Install icon & .desktop file to XDG data (master...xdg) https://github.com/bitcoin/bitcoin/pull/15068
 42 2018-12-31T06:20:30  *** bitcoin-git has left #bitcoin-core-dev
 43 2018-12-31T06:27:30  *** irc_viewer_test has quit IRC
 44 2018-12-31T06:30:04  *** irc_viewer_test has joined #bitcoin-core-dev
 45 2018-12-31T06:31:24  *** irc_viewer_test has joined #bitcoin-core-dev
 46 2018-12-31T06:32:28  *** jasonzhouu has left #bitcoin-core-dev
 47 2018-12-31T06:36:20  *** irc_viewer_test has quit IRC
 48 2018-12-31T06:38:20  *** irc_viewer_test has joined #bitcoin-core-dev
 49 2018-12-31T06:38:37  *** hebasto has joined #bitcoin-core-dev
 50 2018-12-31T06:43:31  *** irc_viewer_test has quit IRC
 51 2018-12-31T06:49:42  *** irc_viewer_test has joined #bitcoin-core-dev
 52 2018-12-31T07:02:05  *** irc_viewer_test has quit IRC
 53 2018-12-31T07:17:08  *** rex4539 has joined #bitcoin-core-dev
 54 2018-12-31T07:32:01  *** rex4539 has quit IRC
 55 2018-12-31T07:59:35  *** Krellan has joined #bitcoin-core-dev
 56 2018-12-31T08:14:09  *** thaumavorio has quit IRC
 57 2018-12-31T08:14:55  *** thaumavorio has joined #bitcoin-core-dev
 58 2018-12-31T08:38:01  *** rh0nj has quit IRC
 59 2018-12-31T08:39:08  *** rh0nj has joined #bitcoin-core-dev
 60 2018-12-31T09:23:31  <wumpus> fanquake: OK
 61 2018-12-31T09:24:07  <fanquake> wumpus no pressure on your new years eve!
 62 2018-12-31T09:26:27  <wumpus> hehe for some reason I never saw the copyright year bumping as particularly pressuring, but we don't like a flood of PRs so I agree it's good to have it over with :)
 63 2018-12-31T09:27:33  <wumpus> don't they need t run some script to update the copyright in the source code as well
 64 2018-12-31T09:28:07  <fanquake> Yea, Marco has a another PR open that's doing that
 65 2018-12-31T09:28:40  <fanquake> We could probably combine the two, but I thought given they are both open already we can just get it over with hah
 66 2018-12-31T09:29:23  <wumpus> sure
 67 2018-12-31T09:32:11  *** bitcoin-git has joined #bitcoin-core-dev
 68 2018-12-31T09:32:12  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2741b2b6f468...cc07f9ce690c
 69 2018-12-31T09:32:12  <bitcoin-git> bitcoin/master ae5594d Emil Engler: [Trivial] Update license year range to 2019...
 70 2018-12-31T09:32:13  <bitcoin-git> bitcoin/master cc07f9c Wladimir J. van der Laan: Merge #15061: [Trivial] Update license year range to 2019...
 71 2018-12-31T09:32:13  *** bitcoin-git has left #bitcoin-core-dev
 72 2018-12-31T09:32:44  <fanquake> I guess #14974 is mergable as well.
 73 2018-12-31T09:32:46  <gribble> https://github.com/bitcoin/bitcoin/issues/14974 | doc: Removing redundant line: "Windows XP not supported" by benthecarman · Pull Request #14974 · bitcoin/bitcoin · GitHub
 74 2018-12-31T09:32:53  *** bitcoin-git has joined #bitcoin-core-dev
 75 2018-12-31T09:32:54  <bitcoin-git> [bitcoin] laanwj closed pull request #15061: [Trivial] Update license year range to 2019 (master...update-license-to-2019) https://github.com/bitcoin/bitcoin/pull/15061
 76 2018-12-31T09:32:54  *** bitcoin-git has left #bitcoin-core-dev
 77 2018-12-31T09:34:15  <fanquake> The other copyright bump is in #15054, which assuming it's extensive, should be fine. Not sure we need a scripted diff.
 78 2018-12-31T09:34:17  <gribble> https://github.com/bitcoin/bitcoin/issues/15054 | Update copyright headers to 2018 by DrahtBot · Pull Request #15054 · bitcoin/bitcoin · GitHub
 79 2018-12-31T09:39:38  *** Guyver2 has joined #bitcoin-core-dev
 80 2018-12-31T09:47:49  *** murrayn has quit IRC
 81 2018-12-31T09:52:53  <luke-jr> fanquake: 14974 looks incomplete still
 82 2018-12-31T10:01:58  *** setpill has joined #bitcoin-core-dev
 83 2018-12-31T10:04:26  *** irc_viewer_test has joined #bitcoin-core-dev
 84 2018-12-31T10:16:28  *** war10ck has joined #bitcoin-core-dev
 85 2018-12-31T10:20:18  *** promag has joined #bitcoin-core-dev
 86 2018-12-31T10:22:09  *** spinza has quit IRC
 87 2018-12-31T10:23:05  *** irc_viewer_test has quit IRC
 88 2018-12-31T10:36:59  *** EagleTM has joined #bitcoin-core-dev
 89 2018-12-31T10:41:43  *** ovovo has joined #bitcoin-core-dev
 90 2018-12-31T10:44:00  *** spinza has joined #bitcoin-core-dev
 91 2018-12-31T10:47:56  *** promag has quit IRC
 92 2018-12-31T10:54:50  *** Krellan has quit IRC
 93 2018-12-31T10:56:24  *** Lightsword has quit IRC
 94 2018-12-31T10:56:39  *** Lightsword has joined #bitcoin-core-dev
 95 2018-12-31T10:57:27  *** jnewbery has quit IRC
 96 2018-12-31T10:57:41  *** jnewbery has joined #bitcoin-core-dev
 97 2018-12-31T10:57:48  *** roasbeef has quit IRC
 98 2018-12-31T10:57:59  *** kallewoof has quit IRC
 99 2018-12-31T10:58:08  *** roasbeef has joined #bitcoin-core-dev
100 2018-12-31T10:58:30  *** CodeBlue1776 has quit IRC
101 2018-12-31T10:59:13  *** kallewoof has joined #bitcoin-core-dev
102 2018-12-31T10:59:28  *** CodeBlue1776 has joined #bitcoin-core-dev
103 2018-12-31T11:21:57  *** TX1683 has quit IRC
104 2018-12-31T11:22:47  *** jungly has joined #bitcoin-core-dev
105 2018-12-31T11:23:08  *** TX1683 has joined #bitcoin-core-dev
106 2018-12-31T11:26:20  *** bitcoin-git has joined #bitcoin-core-dev
107 2018-12-31T11:26:20  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cc07f9ce690c...e756eca9e8bf
108 2018-12-31T11:26:21  <bitcoin-git> bitcoin/master 06ba779 DrahtBot: Update copyright headers to 2018
109 2018-12-31T11:26:21  <bitcoin-git> bitcoin/master 1a49a0e DrahtBot: Bump manpages
110 2018-12-31T11:26:22  <bitcoin-git> bitcoin/master e756eca MarcoFalke: Merge #15054: Update copyright headers to 2018...
111 2018-12-31T11:26:22  *** bitcoin-git has left #bitcoin-core-dev
112 2018-12-31T11:27:00  *** bitcoin-git has joined #bitcoin-core-dev
113 2018-12-31T11:27:01  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #15054: Update copyright headers to 2018 (master...DrahtBot_bump_headers) https://github.com/bitcoin/bitcoin/pull/15054
114 2018-12-31T11:27:01  *** bitcoin-git has left #bitcoin-core-dev
115 2018-12-31T11:33:09  *** wraithm has quit IRC
116 2018-12-31T11:34:47  *** wraithm has joined #bitcoin-core-dev
117 2018-12-31T11:37:43  *** war10ck has left #bitcoin-core-dev
118 2018-12-31T11:38:02  *** Emcy has quit IRC
119 2018-12-31T11:42:40  *** AaronvanW has joined #bitcoin-core-dev
120 2018-12-31T11:48:55  *** Emcy has joined #bitcoin-core-dev
121 2018-12-31T11:52:31  *** dviola has joined #bitcoin-core-dev
122 2018-12-31T12:03:09  *** Emcy has quit IRC
123 2018-12-31T12:03:37  *** Emcy has joined #bitcoin-core-dev
124 2018-12-31T12:46:33  <cjd> This is funny, 4 years ago bitcoin could only possibly work on little endian (probably only on i386/amd64) and cjdns had nice endian swapping macros and all of that
125 2018-12-31T12:46:48  <cjd> now I see endian swapping macros in bitcoin and they look almost exactly like my old code
126 2018-12-31T12:47:12  *** CodeBlue1776 has quit IRC
127 2018-12-31T12:47:26  <cjd> but now, I'm nolonger writing code with endian swapping, I consider all processors that matter to be EL and I'm holding my breath for the last of the BEs to die out
128 2018-12-31T12:48:21  *** CodeBlue1776 has joined #bitcoin-core-dev
129 2018-12-31T12:53:51  <gmaxwell> cjd: our working correctly on BE has very little to do with caring if the software works correctly on BE, and a lot more to do with code that doesn't is almost always executing undefined behavior, and is potentially vulnerable to the compiler being especially creative as a result.
130 2018-12-31T12:54:50  <cjd> you mean aliasing ?
131 2018-12-31T12:55:46  <gmaxwell> Yes, thats one sort of undefined behavior that will cause you endianness handling issues (and which, in fact, will cause compilers to do things you probably didn't expect, in practice not just theory)
132 2018-12-31T12:56:29  <gmaxwell> endian fragile code also usually mishandles alignment.
133 2018-12-31T12:57:37  <gmaxwell> (esp when most of the developers are on x86, which usually doesn't crash on alignment mistakes...  unless the alignment mistake crosses a page boundary, and the compiler manges to use one of the aligned simd loads...)
134 2018-12-31T12:58:42  <cjd> I've used alignment assertions in the past because I generally would rather everything be aligned than not know
135 2018-12-31T12:59:32  <cjd> but if you're unpacking tight structures like transactions, swapping byte order is no real extra overhead since you have to be quite careful with them anyway
136 2018-12-31T12:59:42  <cjd> *being prepared to swap them
137 2018-12-31T13:01:24  <gmaxwell> it's also no overhead because the compiler will totally eliminate the swaps where they aren't needed.
138 2018-12-31T13:02:33  <cjd> runtime overhead, I was thinking development overhead (which is my main concern)
139 2018-12-31T13:03:06  <cjd> easy to make things have no runtime overhead in most procs, specify everything as EL
140 2018-12-31T13:03:34  <sipa> thankfully we don't (need to) touch the serialization code very often
141 2018-12-31T13:03:48  <gmaxwell> (also, on lots of processors, though not x86, byteswapping is essentially free because it just gets turned into a flag on load instructions)
142 2018-12-31T13:05:29  <gmaxwell> e.g. you wire encode little endian, on x86 the macros just vanish entirely, and on (say) BE-power9 it turns into the byteswapping version of the relavant load instruction, and the result is as fast as if only one way existed. :)
143 2018-12-31T13:06:29  <gmaxwell> as far as the code goes--- you've got to have something there where you are reading from char into ints. Just casting is not correct (prohibited by aliasing, alignment, or both).
144 2018-12-31T13:08:35  <cjd> I tend not to cast pointers that often, though I do a fair amount of memcpy
145 2018-12-31T13:09:49  *** mistergo1d has joined #bitcoin-core-dev
146 2018-12-31T13:10:31  <gmaxwell> right, well, if you have to call memcpy you can just call something else instead that handles byteorder if required.
147 2018-12-31T13:11:51  <cjd> struct big_struct_with_lots_of_fields s;  memcpy(s, data, sizeof s);
148 2018-12-31T13:12:48  *** spaced0ut has quit IRC
149 2018-12-31T13:13:07  *** mistergold has quit IRC
150 2018-12-31T13:13:59  <gmaxwell> uhh, so you know that the structs layout in memory is totally not portable, right? :P
151 2018-12-31T13:14:32  <gmaxwell> not just in terms of endianness.
152 2018-12-31T13:14:36  <cjd> yes, and I also know that linux will run into problems before I do :P
153 2018-12-31T13:15:05  <cjd> I don't use bitfields in structs I'm planning to write on the wire, they do
154 2018-12-31T13:15:45  <cjd> I also use explicit pad fields and generally static assert the size to be reasonably assured that the compiler didn't imagine some place to add padding
155 2018-12-31T13:16:07  <gmaxwell> Linux isn't written in C. in particualr it sticks in all sorts of specialized directives at the compiler to fix the behavior, and then only works on a subset of systems (which is fine, since its an OS its naturally restricted there. :P )
156 2018-12-31T13:16:43  <sipa> with enough safeguards against all possible choices a compiler/architecture could make, i'm sure you can make this reasonably safe
157 2018-12-31T13:16:54  <sipa> it seems much more of a worry than just using layout-neutral code though :)
158 2018-12-31T13:17:01  <gmaxwell> welp, when some clever compiler operations turns that code into something that gives remote root to the world, you'll have only yourself to blame. :P
159 2018-12-31T13:17:14  <cjd> ehh
160 2018-12-31T13:17:46  <sipa> it's probably getting a bit offtopic here
161 2018-12-31T13:17:50  <cjd> if (programmer_used_ub()) { insert_backdoor_code(); }    I don't think the compiler authors are completely off the hook
162 2018-12-31T13:17:58  <cjd> sorry
163 2018-12-31T13:18:06  <cjd> happy newyear btw
164 2018-12-31T13:18:53  <gmaxwell> In any case, new code under the logic you're using wouldn't be accepted to this project without a really strong justification.  Other projects might do different things, sounds like a problem for their channels.
165 2018-12-31T13:19:58  <cjd> Yeah, when I'm trying to get something accepted I follow whatever rules the project uses
166 2018-12-31T13:21:50  <wumpus> IBM power arch can use big-endian and apparently some linux distros use it with that, I think it's part of basic correctness/abstraction to have software work independent of CPU endianness
167 2018-12-31T13:22:00  *** reardencode has quit IRC
168 2018-12-31T13:25:14  <midnightmagic> +1 endian-independent design..
169 2018-12-31T13:26:09  <gmaxwell> I wish someone made a (could be simulated only) arch that made every free decision opposite.  Endianness, stack growth direction, calling conventions, etc.  I've found more than a few all-platform bugs from testing code on BE simply because differences in the execution enviroment turned a usually invisible bug into an instant crasher.
170 2018-12-31T13:26:58  <wumpus> although I agree there are some decisions, and choices with regard to architecture that simply die out, there's no need to support any architecture, real and imagined since the 60s, say, no need to handle the case where int is 16 bit
171 2018-12-31T13:27:15  <gmaxwell> an "adversarial C compiler" would be fun, ... tries to behave in a way most likely to make everything fail, subject to being strictly standards conforming.
172 2018-12-31T13:27:15  <wumpus> or char is two bytes...
173 2018-12-31T13:27:43  <wumpus> maybe big endian will be one of those in the future but I don't think we're there
174 2018-12-31T13:27:59  <gmaxwell> wumpus: I agree with you, though I have written code for char-is-two bytes platforms.
175 2018-12-31T13:27:59  <cjd> wumpus: that's my thinking when I do projects these days
176 2018-12-31T13:28:16  <gmaxwell> (TI VLIW DSPs)
177 2018-12-31T13:28:20  <midnightmagic> Bitcoin can't run on an Amiga. :-P
178 2018-12-31T13:28:22  <cjd> gmaxwell: reminds me of libdisalloc
179 2018-12-31T13:28:39  <wumpus> cjd: I don't start projects in C anymore anyway :)
180 2018-12-31T13:28:56  <midnightmagic> :-(
181 2018-12-31T13:29:46  <cjd> good move, though I have not seen a really good replacement when speed is a high priority
182 2018-12-31T13:29:53  <wumpus> (not that that avoids the endian question, but, say, rust has all common types fixed-size, so it avoids the 'is this type one or two bytes' question at least)
183 2018-12-31T13:30:34  <wumpus> or 'is char signed', eeh I made some terrible mistakes with that
184 2018-12-31T13:30:49  <gmaxwell> wumpus: I assume there are also standard types in rust for "the fastest thing that is at least 16 bits"?
185 2018-12-31T13:31:04  <wumpus> gmaxwell: no, there's i16, u16, nothing else IIRC
186 2018-12-31T13:31:14  <sipa> C++17 introduces the 'byte' type, which allows accessing the representation on memory of other types, without being an int type
187 2018-12-31T13:31:39  <wumpus> gmaxwell: though, thinking of it, wouldn't be surprised if it exists in some crate
188 2018-12-31T13:31:49  <gmaxwell> sipa: it's like char but without the char signness baggage?
189 2018-12-31T13:31:50  <wumpus> gmaxwell: it's just not the common way of doing things and I like that
190 2018-12-31T13:32:21  <sipa> gmaxwell: it's basically an 8-bit vector without integer aspects
191 2018-12-31T13:32:35  <sipa> so no arithmetic, only bitwise operations
192 2018-12-31T13:32:42  <midnightmagic> I'm torn between the nature of the safety decision against using C and/or assembly as a learning environment, and the problematic results of C projects done badly. All I can say is I think it's vewry unfortunate that people are moving away from the bare metal level in general, as it generates a type of ignorance in the average which makes us in general more vulnerable to problems at the
193 2018-12-31T13:32:48  <midnightmagic> machine level. :(
194 2018-12-31T13:32:59  <gmaxwell> sipa: but its allowed to alias like char?
195 2018-12-31T13:33:13  <gmaxwell> e.g. can you implement memcpy using it?
196 2018-12-31T13:33:14  <cjd> I want to love rust but I'm afraid that too much logic goes into the compiler itself and it's not general purpose enough... so my concern is that some wizard is going to come down from the hill and make a language with 7 builtin keywords and the ability to DSL just about anything...
197 2018-12-31T13:33:17  <sipa> yup
198 2018-12-31T13:33:29  <sipa> gmaxwell: yup, byte pointers can alias any other pointer
199 2018-12-31T13:33:39  <gmaxwell> sipa: sounds reasonable.
200 2018-12-31T13:33:54  <wumpus> midnightmagic: I like assambly (though I don't use it a lot in practice because I tend to write platform independent software!), I don't really like C
201 2018-12-31T13:34:45  <wumpus> all the UB pitfalls are not necessary in a langage and harmful
202 2018-12-31T13:36:05  <midnightmagic> wumpus: I have a secret love for C which as far as I can tell has never dissipated even when I stopped enjoying owning most computers due to backdooring issues. But I don't think people who prefer C or something like it are fetishists-- not quite yet anyway.
203 2018-12-31T13:36:18  <midnightmagic> oh well
204 2018-12-31T13:36:36  <gmaxwell> Well the specific way C UB works is not so lovely.  Rust has things which are defined to be an error and only caught in debug builds, but have well defined semantics otherwise (even though your code is still technically incorrect if does them).
205 2018-12-31T13:36:39  <wumpus> 'baggage' is kind of the right word, anyhow, so many exceptions and irregularities for history's sake
206 2018-12-31T13:36:40  <sipa> i like C as a lowest common denominator... if something has to work everywhere, C will do the job
207 2018-12-31T13:37:18  <cjd> problem w/ C is as gmax pointed out, UB is something that people use every day and the compiler is technically allowed to do anything..  in the words of HST: "In a closed society where everybody's guilty, the only crime is getting caught."
208 2018-12-31T13:37:44  <wumpus> and this is not speaking as a programming newbie but someone who made every mistake that is possible, and still makes them even after so many years
209 2018-12-31T13:39:10  <cjd> And I still cast pointers and violate aliasing rules, because it's fast
210 2018-12-31T13:39:23  <gmaxwell> you /really/ should not.
211 2018-12-31T13:39:40  <sipa> cjd: i'm a bit skeptical that it actually gains you any speed
212 2018-12-31T13:39:47  <gmaxwell> correctly written code is seldom any slower. (not to mention that only a tiny fraction of code is actually performance relavant)
213 2018-12-31T13:40:28  *** dviola has quit IRC
214 2018-12-31T13:40:42  <sipa> for example a function uint32_t readLE(const unsigned char* data) { uint32_t ret; memcpy(&ret, data, sizeof(uint32_t)); return letohs(ret); } will basically compile to just reading memory on x86
215 2018-12-31T13:41:00  <wumpus> cjd: yes, it's not a good situation IMO, people tend to overestimate themselves, 'I can make this violation because I know what I"m doing' and maybe that's true part of the time, but the times it's not make it very dangerous in critical code, and lots of code is critical today
216 2018-12-31T13:41:18  <gmaxwell> I've found that its more common that convincing the compiler that there isn't any of the _permitted_ kinds of aliasing ends up being important for performance, since it allows vectorization.
217 2018-12-31T13:41:49  <cjd> agreed on that point
218 2018-12-31T13:41:50  <sipa> OAOBle32toh, sorry
219 2018-12-31T13:41:57  <wumpus> also yeah compilers change, violations that could be done more or less safely in the past no longer safe now, you have this running in the same place to keep up with the ocmpiler
220 2018-12-31T13:42:08  <gmaxwell> wumpus: also they correctly estimate their best, or even just average, capability... which is a massive overestimate of them at their dumbest moment... :)
221 2018-12-31T13:43:12  <cjd> I like the Rust vision of aliasing since in theory the compiler gets a lot more freedom
222 2018-12-31T13:43:17  <gmaxwell> The same humans that one in one-hundred morings try to put their pants on inside or or their shirt on backwards... :)
223 2018-12-31T13:43:31  <wumpus> gmaxwell: yep! this is what makes unsafe {} in rust better than having *everything* unsafe, I guess
224 2018-12-31T13:43:51  *** dendisuhubdy has joined #bitcoin-core-dev
225 2018-12-31T13:44:06  <cjd> we're slowly inching in the direction of everything being proven
226 2018-12-31T13:44:10  <wumpus> at least the 'I'm doing crazy things here' sections are clearly cordoned off for review
227 2018-12-31T13:44:23  <gmaxwell> cjd: well rust behavior is good for performance in other ways... you're forced into using iterators for everything to escape constant bounds checks,  but then that also gives the compiler more freedom.
228 2018-12-31T13:44:41  <cjd> very good point
229 2018-12-31T13:45:33  <MarcoFalke> Should we add a repo to bitcoin-core with fuzz seeds?
230 2018-12-31T13:45:40  <cjd> I really do want to love rust, I think my biggest complaint is the fact that it's static assertion capability is significantly weaker than C's
231 2018-12-31T13:45:51  <wumpus> cjd: I hope so re: the "being proven" part, that languages are going to allow specifying high-level invariants that can be checked, and that using this is going to be common sense
232 2018-12-31T13:46:01  <gmaxwell> cjd: I don't really think there is much in the way of material progress in terms of provability. like I think I would agree that we're moving in the direction where something people actually use is proven in a way that could have avoided problems... but everything? dunno there. It's not like new and trendy languages like go or rust were designed with making proving things about code writeen in
233 2018-12-31T13:46:02  <gmaxwell> them easier.
234 2018-12-31T13:46:56  <gmaxwell> right now the only code that is even somewhat easy to prove properties of is code that generally doesn't need proofs.
235 2018-12-31T13:46:56  <wumpus> gmaxwell: rihgt
236 2018-12-31T13:47:05  *** Guyver2 has quit IRC
237 2018-12-31T13:47:06  <cjd> Proven code in the traditional sense is difficult/expensive and unlikely to gain a lot of traction, but even Javascript is "proven" not to segfault
238 2018-12-31T13:47:22  <gmaxwell> thats a really low bar, however.
239 2018-12-31T13:47:38  <cjd> I expect proof to creep in from the side of proving what code cannot do rather than proving what it will do
240 2018-12-31T13:48:05  <gmaxwell> and consider, JS code for bitcoin has a had flaws that cost users funds many many many more times than code written in languages that aren't segfault free. :P
241 2018-12-31T13:48:54  <gmaxwell> of course, getting rid of one or more whole classes of bugs is a win. More time to spend on other things.
242 2018-12-31T13:49:03  <wumpus> I mean that's already the case with rust, by using only safe code (and assuming dependent crates don't violate assumptions) you're essentialy proving you can't have certain classes of bugs
243 2018-12-31T13:49:23  <cjd> Bitcoin is a unique project, in that it's a piece of code which is typically not exploited to get access to someting else, it's exploited for it's own purpose
244 2018-12-31T13:49:34  <gmaxwell> But I think that e.g. JS hurts program safty in ways that more than make up for the lack of segfaults.
245 2018-12-31T13:50:41  <gmaxwell> you can make C code segfault free too-- just run it in a sandbox that halts cleanly when native execution would have segfaulted.
246 2018-12-31T13:51:21  <gmaxwell> e.g. the nacl sandbox essentially gives code written in whatever langauge the same 'provable' properties as JS.
247 2018-12-31T13:51:34  <gmaxwell> Yet there seems to be no move to go deploy things that way.
248 2018-12-31T13:51:53  <cjd> I contend that even the worst languages are valuable because they advance the state of the art, somewhere in some university there is a guy who will no doubt argue that all languages except haskell must be banned, but if he had his way then the industry would still be in the early 90s if not earlier
249 2018-12-31T13:52:08  <gmaxwell> even though the performance hit is radically lower than any of the popular interperted langauges.
250 2018-12-31T13:52:09  <cjd> (IMO)
251 2018-12-31T13:53:16  <gmaxwell> I think a lot of things were better in the 90s.  My document readers were actually document readers and not remote spy device execution enviroments for obfscuated non-free software. :P
252 2018-12-31T13:54:21  <wumpus> cjd: I'd be quite interested in seeing that timeline (given the questionable assumption a programming language ban works in the first place...), everyone using the same language and it happens to be haskell :)
253 2018-12-31T13:54:56  <gmaxwell> presumably people would just extend haskell until it contained all of C++ and JS. ... :P
254 2018-12-31T13:55:42  * midnightmagic jumps out window
255 2018-12-31T13:55:44  <wumpus> gmaxwell: yes, it's a mistake to think of progress as linear, even in the area of computing
256 2018-12-31T13:56:07  *** dendisuhubdy has quit IRC
257 2018-12-31T13:56:52  <gmaxwell> cjd: also a lot of the computing systems I use today are significantly slower and less responsive than what I used in the 90s.
258 2018-12-31T13:57:11  <wumpus> yes
259 2018-12-31T13:58:02  <cjd> There are some people who think that the 50s was the best time in history
260 2018-12-31T13:58:02  <wumpus> good old time when hardware improvements could still keep up with growth in software bloat :-)
261 2018-12-31T13:58:30  <gmaxwell> even just desktop applications have degraded in performance, stuff like compositing displays, anti-aliasing, and smooth scrolling have added multiple frames of delay. Which is in fact visible... and thats without getting to the insanity of the web.  Every once in a while I dig up a really old system to pull some data off it and end up being surprised at how fast it is.
262 2018-12-31T13:58:57  <gmaxwell> I don't mean this in some kind of vague 50s-were-the-best I mean by objective criteria that most of us would agree are important.
263 2018-12-31T13:59:48  <cjd> So stuff like electron is making programming more accessible to a wider number of people, the cost is that things get slow, but that will eventually be solved as well
264 2018-12-31T13:59:49  <gmaxwell> Like "millseconds to respond to user input in the 99th percentile".  Or, "doesn't secretly send your private data to third parties".
265 2018-12-31T14:00:00  <gmaxwell> I'm sure things will improve again later.
266 2018-12-31T14:00:14  <wumpus> I'm not as hopeful about the future
267 2018-12-31T14:00:39  <cjd> Machines get faster, programming gets easier, and typical applications remain just within the range of "tollerable"
268 2018-12-31T14:01:22  <gmaxwell> For a number of years my main display was an IBM T221, a more than decade (at the time) outdated display, because pretty much from the moment HDTV came out for about 10 years thereafter it became impossible to get a computer display that was higher resolution than 1080p at basically any price.  But eventually, 4k+ displays started being made. It just took a long time.
269 2018-12-31T14:02:03  <cjd> but to throw us back to the age of COM C++ programming would be to remove maybe 80% of the programmers from the programmer pool, so then less software and then less choice
270 2018-12-31T14:02:34  <wumpus> I'm not convinced that is true, a lot of learning, say, JS is baggage as well
271 2018-12-31T14:02:43  <gmaxwell> That isn't at all clear to me.
272 2018-12-31T14:02:45  <wumpus> easy programming languages existed in the 90's as well
273 2018-12-31T14:03:14  <gmaxwell> some of them were actually pretty effective, like hypercard.
274 2018-12-31T14:03:20  <wumpus> yes
275 2018-12-31T14:03:25  <gmaxwell> (in a way that I dont think you can credit JS with being)
276 2018-12-31T14:04:10  <gmaxwell> (I mean actually effective at allowing less skilled/trained people to create non-trivial useful programs with only moderate effort)
277 2018-12-31T14:05:01  <cjd> well, sometimes evolution carries us down a fluke path, we have to try a lot of things wrong before we get something right
278 2018-12-31T14:05:04  <wumpus> JS has so many weird frameworks, different ways to do UI, the HTML UI manipulation isn't *that* intuitive, and with so many different ways a lot of people get confused
279 2018-12-31T14:05:33  <cjd> JS frameworks are a primordial soup for design patterns
280 2018-12-31T14:06:03  <gmaxwell> also basically no feedback on why things aren't working right when you mix the soup parts incorrectly.
281 2018-12-31T14:07:08  <gmaxwell> it does benefit from an enormous amount of code you can copy/paste import, but a lot of it is fairly low quality, undocumented, etc.
282 2018-12-31T14:07:48  <fanquake> npm install *everything*
283 2018-12-31T14:08:11  * sipa imports the is_integer npm package
284 2018-12-31T14:08:22  <wumpus> people also overstate the accessibility asspects, it's not that modern UI frameworks, no matter how bloated, really that useful (by default) by someone using a screen reader, braille display, etc, in a way console/text based interfaces were *better* for that
285 2018-12-31T14:08:35  * midnightmagic sadly stares at the smoking crater where sipa was
286 2018-12-31T14:09:49  <gmaxwell> wumpus: Some of the regression in objective quality I think is because people often dont bother to write down what they did well, and as a result things get replaced by things that are worse but look better.
287 2018-12-31T14:10:47  <wumpus> I don't think much progress is being made and we're seeing lots of cambrian explosions without follow-up winnowing down phase, so many competing things, ways to do the same
288 2018-12-31T14:10:49  <wumpus> gmaxwell: yep...
289 2018-12-31T14:11:11  <gmaxwell> wumpus: I lamented this a lot back when banks moved from terminal based applications to windows UI applications... and visits to the banks started taking 5x longer (and only ever recovered to 2x longer even after years).  The gui apps were faster to onboard staff perhaps, but expirenced staff was much slower with them.
290 2018-12-31T14:11:55  <cjd> That's an interesting observation
291 2018-12-31T14:13:03  <cjd> Banks are not exactly known for efficiency so one can expect practically anything to happen in their IT systems, even to be written in brainf*ck because a number of tie-wearing men declared that it would be better/faster/safer/higher quality...
292 2018-12-31T14:13:12  *** spaced0ut has joined #bitcoin-core-dev
293 2018-12-31T14:13:33  <cjd> But when efficiency is critical, one would expect to see GUI apps with keyboard shortcuts so that there is a smooth learning curve
294 2018-12-31T14:14:41  <wumpus> gmaxwell: yes, learning curve is not really taken into account, in ways it seems that UI went from a serious study to 'what looks nice and seems intuitive at first glance', with different companies doing different things and zillions of different metaphors
295 2018-12-31T14:15:24  <wumpus> cjd: you'd expect so
296 2018-12-31T14:15:36  <cjd> At the end of the day, we probably ought to evaluate programming languages using the anthropological toolkit used for religions because I think they tend to spread similarly
297 2018-12-31T14:17:05  <gmaxwell> I think there is a general pattern with tools, where first generation tools are barely usable, second generation are radically improved, and third generation try to improve initial impressions or learning curve and ultimately limit the tool.
298 2018-12-31T14:18:31  <cjd> I suspect the same methodology works for evaluating editors, distros and blockchains
299 2018-12-31T14:21:56  *** cluelessperson has quit IRC
300 2018-12-31T14:29:55  *** cluelessperson has joined #bitcoin-core-dev
301 2018-12-31T14:55:29  *** mistergo1d has quit IRC
302 2018-12-31T14:55:33  *** mistergold has joined #bitcoin-core-dev
303 2018-12-31T15:03:19  *** bitcoin-git has joined #bitcoin-core-dev
304 2018-12-31T15:03:20  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e756eca9e8bf...f5a70d146259
305 2018-12-31T15:03:20  <bitcoin-git> bitcoin/master 3019ba2 Ben Carman: Making supported operating systems more clear
306 2018-12-31T15:03:21  <bitcoin-git> bitcoin/master f5a70d1 Wladimir J. van der Laan: Merge #14974: doc: Removing redundant line: "Windows XP not supported"...
307 2018-12-31T15:03:21  *** bitcoin-git has left #bitcoin-core-dev
308 2018-12-31T15:04:00  *** bitcoin-git has joined #bitcoin-core-dev
309 2018-12-31T15:04:00  <bitcoin-git> [bitcoin] laanwj closed pull request #14974: doc: Removing redundant line: "Windows XP not supported" (master...release_notes_doc) https://github.com/bitcoin/bitcoin/pull/14974
310 2018-12-31T15:04:00  *** bitcoin-git has left #bitcoin-core-dev
311 2018-12-31T15:07:37  *** setpill has quit IRC
312 2018-12-31T15:17:43  *** jungly has quit IRC
313 2018-12-31T15:19:04  *** dermoth has joined #bitcoin-core-dev
314 2018-12-31T15:44:58  *** AaronvanW has quit IRC
315 2018-12-31T15:55:18  *** AaronvanW has joined #bitcoin-core-dev
316 2018-12-31T15:55:19  *** AaronvanW has quit IRC
317 2018-12-31T15:55:38  *** AaronvanW has joined #bitcoin-core-dev
318 2018-12-31T16:03:43  *** dermoth has quit IRC
319 2018-12-31T16:04:23  *** dermoth has joined #bitcoin-core-dev
320 2018-12-31T16:24:38  *** AaronvanW has quit IRC
321 2018-12-31T16:31:12  *** rex4539 has joined #bitcoin-core-dev
322 2018-12-31T16:33:02  *** rh0nj has quit IRC
323 2018-12-31T16:33:38  *** tryphe_ has joined #bitcoin-core-dev
324 2018-12-31T16:35:04  *** mistergold has quit IRC
325 2018-12-31T16:35:19  *** tryphe_000 has joined #bitcoin-core-dev
326 2018-12-31T16:36:32  *** tryphe has quit IRC
327 2018-12-31T16:38:23  *** tryphe_ has quit IRC
328 2018-12-31T16:42:27  *** hebasto has quit IRC
329 2018-12-31T16:49:17  *** dviola has joined #bitcoin-core-dev
330 2018-12-31T16:49:53  *** dviola has joined #bitcoin-core-dev
331 2018-12-31T16:57:15  *** Skirmant has quit IRC
332 2018-12-31T16:58:04  *** Skirmant has joined #bitcoin-core-dev
333 2018-12-31T17:04:23  *** elichai2 has joined #bitcoin-core-dev
334 2018-12-31T17:18:40  *** cobega has joined #bitcoin-core-dev
335 2018-12-31T17:21:20  <cobega> running bitcoind "walletversion": 169900, after creating a multisig address using "addmultisigaddress" and depositing some coins to this address, using the "listunspent" command doesn't list this address. Is some more efficient way then using "importaddress" (since this will block the bitcoind for a while).
336 2018-12-31T17:24:56  <achow101> cobega: did you do listunspent with the watch_only option set to true?
337 2018-12-31T17:25:37  <achow101> you can use importaddress with rescan false, then rescanblockchain from the block height that that address has its first transaction.
338 2018-12-31T17:29:27  *** EagleTM has quit IRC
339 2018-12-31T17:29:30  <cobega> moment, will try first listunspent with watch only set to true.
340 2018-12-31T17:31:11  <cobega> how to activate watch only option (https://bitcoin.org/en/developer-reference#listunspent)?
341 2018-12-31T17:32:28  <cobega> It's a bit strange, using ./bitcoin-cli listreceivedbyaddress 1 true true I can see the multisig address
342 2018-12-31T17:45:24  <gwillen> cobega: yeah the thing you want is to use importaddress with rescan false
343 2018-12-31T17:45:42  <gwillen> and then use rescanblockchain, and tell it what height to start scanning from, i.e. the height you first sent to that address
344 2018-12-31T17:45:46  <gwillen> then the rescan will be very fast
345 2018-12-31T17:45:54  <gwillen> or if you import before sending you don't need to rescan at all
346 2018-12-31T17:46:06  <gwillen> I can confirm the import was required when I tried to do this, so I assume it is necessary
347 2018-12-31T17:46:11  <achow101> oh whoops. listunspent doesn't have a watchonly option
348 2018-12-31T17:46:45  <gwillen> I don't know why addmultisigaddress doesn't import
349 2018-12-31T17:47:05  <gwillen> or what distinguishes it from createmultisig given that it doesn't
350 2018-12-31T17:49:21  <cobega> what about https://bitcoin.org/en/developer-reference#importmulti ?
351 2018-12-31T17:49:44  <achow101> cobega: you can use importmulti too with a timestamp of the block height you first used the address
352 2018-12-31T17:51:03  <achow101> gwillen: addmultisigaddress adds the redeemScript to your wallet
353 2018-12-31T17:51:34  <achow101> so you can sign a transaction that spends the multisig without having funds sent to it showing up in your balance
354 2018-12-31T17:55:10  *** brianhoffman_ has joined #bitcoin-core-dev
355 2018-12-31T17:55:42  *** brianhoffman has quit IRC
356 2018-12-31T17:55:43  *** brianhoffman_ is now known as brianhoffman
357 2018-12-31T18:00:03  <gwillen> achow101: ahh so it makes it solvable
358 2018-12-31T18:00:05  <gwillen> that makes sense, thanks
359 2018-12-31T18:01:25  <sipa> gwillen: createmultisig is the utility non-wallet version of the RapC, to just let you compute the address
360 2018-12-31T18:01:34  <sipa> addmultisigaddress is the wallet importing version
361 2018-12-31T18:04:23  <cobega> using importmulti, will I have to set rescan to false, when I used the option timestamp of it, or would I need to set rescan to true anyways?
362 2018-12-31T18:11:18  *** ovovo has quit IRC
363 2018-12-31T18:17:38  <achow101> cobega: the timestamp indicates from when to start rescanning. it basically combines importaddress and rescanblockchain
364 2018-12-31T18:20:37  <cobega> Understand :) But should I set rescan to true or false when using the timestamp parameter?
365 2018-12-31T18:21:46  <achow101> set it to true
366 2018-12-31T18:26:20  *** fabianfabian has joined #bitcoin-core-dev
367 2018-12-31T18:29:56  <cobega> using ./bitcoin-cli importmulti '[{ "address": "2MtxopLjtoJbfxJqNptZR17RzPGSTSTmqZsy", "timestamp": 1546218000 }]' I get this error Invalid scriptPubKey, as far as I see the docs, it's either scriptPubKey or address to use?
368 2018-12-31T18:31:31  <achow101> no, it's {"scriptPubKey":{"address":"..."}}
369 2018-12-31T18:35:24  <cobega> using it like ./bitcoin-cli importmulti '[{"scriptPubKey":{"address":"2MtxopLjtoJbfxJqNptZR17RzPGSTSTmqZsy"},"timestamp":1546218000}]' it says "invalid address"
370 2018-12-31T18:35:46  <achow101> is your node in testnet mode?
371 2018-12-31T18:35:54  <achow101> that's a testnet address
372 2018-12-31T18:36:02  <cobega> yes it is
373 2018-12-31T18:36:25  <cobega> ./bitcoin-cli getnewaddress 2Mto6bcnFMdZ7M6E76Sd3PXYJzZxF9dupzG
374 2018-12-31T18:36:43  <cobega> Using testnet while development of application.
375 2018-12-31T18:38:24  <arubi> the 2Mtxop one is invalid
376 2018-12-31T18:43:01  <cobega> shame on me. works as expected :)
377 2018-12-31T18:43:25  <arubi> :)
378 2018-12-31T18:47:32  *** Guyver2 has joined #bitcoin-core-dev
379 2018-12-31T19:07:11  *** hebasto has joined #bitcoin-core-dev
380 2018-12-31T19:08:15  *** rex4539 has quit IRC
381 2018-12-31T19:19:50  *** EagleTM has joined #bitcoin-core-dev
382 2018-12-31T19:22:25  *** EagleTM has joined #bitcoin-core-dev
383 2018-12-31T19:24:46  *** EagleTM has quit IRC
384 2018-12-31T19:25:14  *** EagleTM has joined #bitcoin-core-dev
385 2018-12-31T19:30:53  *** spaced0ut has quit IRC
386 2018-12-31T19:37:57  *** EagleTM has quit IRC
387 2018-12-31T19:46:07  <gwillen> sipa: except that addmultisigaddress only sort of imports
388 2018-12-31T19:46:28  <gwillen> it makes it solveable but it doesn't make it "watchonly", i.e. look for utxos it owns
389 2018-12-31T19:48:53  <sipa> gwillen: yes, you need importaddress for that
390 2018-12-31T19:49:13  *** dviola has quit IRC
391 2018-12-31T19:49:17  <sipa> addmuktisigaddress predates support for watchonly addresses
392 2018-12-31T19:49:41  <sipa> it uzed to only work in case you had *all* the private keys for a multisig address in your wallet, at all
393 2018-12-31T19:50:00  <sipa> (yes, that makes no sense)
394 2018-12-31T19:55:52  *** rex4539 has joined #bitcoin-core-dev
395 2018-12-31T19:59:49  *** Krellan has joined #bitcoin-core-dev
396 2018-12-31T20:02:45  <cobega> Anybody a bit more familiar with curl? Using CLI my command works fine, but for curl I receive: curl --user user:pass --data-binary '{"jsonrpc": "1.0", "id":"", "method": "importmulti", "params": [{"scriptPubKey":{"address":"2MtxopLjtoJbfxJqNptZR17RzPGSTSTmqZy"},"timestamp":1546218000},{"rescan":true}] }' -H 'content-type: text/plain;' http://domain.com:28339/  {"code":-3,"message":"Expected type array, got object"}
397 2018-12-31T20:04:07  *** rh0nj has joined #bitcoin-core-dev
398 2018-12-31T20:10:44  *** Krellan has quit IRC
399 2018-12-31T20:10:59  <fabianfabian> I think your first param is an object but should be an array
400 2018-12-31T20:12:31  <fabianfabian> so just enclose it in []
401 2018-12-31T20:13:09  <fabianfabian> curl --user user:pass --data-binary '{"jsonrpc": "1.0", "id":"", "method": "importmulti", "params": [[{"scriptPubKey":{"address":"2MtxopLjtoJbfxJqNptZR17RzPGSTSTmqZy"},"timestamp":1546218000}],{"rescan":true}] }' -H 'content-type: text/plain;' http://domain.com:28339/
402 2018-12-31T20:22:35  *** CodeBlue1776 has quit IRC
403 2018-12-31T20:22:49  *** CodeBlue1776 has joined #bitcoin-core-dev
404 2018-12-31T20:26:35  <gwillen> there's a stray close brace at the end of params there
405 2018-12-31T20:26:37  <gwillen> not sure if it's doing anything
406 2018-12-31T20:26:51  <gwillen> wait, nevermind, that's the outer braces, sorry
407 2018-12-31T20:28:23  <cobega> your code from 21:13 is running.
408 2018-12-31T20:36:51  *** dermoth has quit IRC
409 2018-12-31T20:50:11  *** dermoth has joined #bitcoin-core-dev
410 2018-12-31T21:05:48  *** cobega has quit IRC
411 2018-12-31T21:14:39  *** spinza has quit IRC
412 2018-12-31T21:25:28  *** spinza has joined #bitcoin-core-dev
413 2018-12-31T21:41:35  *** promag has joined #bitcoin-core-dev
414 2018-12-31T21:42:20  *** promag has quit IRC
415 2018-12-31T21:51:26  *** elichai2 has quit IRC
416 2018-12-31T22:11:29  *** Krellan has joined #bitcoin-core-dev
417 2018-12-31T22:12:27  *** davec has quit IRC
418 2018-12-31T22:13:13  *** davec has joined #bitcoin-core-dev
419 2018-12-31T22:16:11  *** Krellan has quit IRC
420 2018-12-31T22:18:47  *** rex4539 has quit IRC
421 2018-12-31T22:34:01  *** spinza has quit IRC
422 2018-12-31T22:38:22  *** spinza has joined #bitcoin-core-dev
423 2018-12-31T22:48:07  *** dviola has joined #bitcoin-core-dev
424 2018-12-31T22:52:45  *** bitcoin-git has joined #bitcoin-core-dev
425 2018-12-31T22:52:46  <bitcoin-git> [bitcoin] Empact opened pull request #15069: test: Fix rpc_net.py "pong" race condition (master...rpc_net-race) https://github.com/bitcoin/bitcoin/pull/15069
426 2018-12-31T22:52:46  *** bitcoin-git has left #bitcoin-core-dev
427 2018-12-31T23:08:16  *** tryphe_000 is now known as tryphe
428 2018-12-31T23:25:23  *** murrayn has joined #bitcoin-core-dev
429 2018-12-31T23:36:29  *** hebasto has quit IRC
430 2018-12-31T23:42:52  *** brianhoffman_ has joined #bitcoin-core-dev
431 2018-12-31T23:45:34  *** brianhoffman has quit IRC
432 2018-12-31T23:45:34  *** brianhoffman_ is now known as brianhoffman