12018-12-31T00:04:01  *** opdenkamp has joined #bitcoin-core-dev
  22018-12-31T00:20:41  *** jasonzhouu has quit IRC
  32018-12-31T00:21:26  *** jasonzhouu has joined #bitcoin-core-dev
  42018-12-31T00:22:43  *** promag has joined #bitcoin-core-dev
  52018-12-31T00:23:15  *** dgenr8 has quit IRC
  62018-12-31T00:24:44  *** dviola has quit IRC
  72018-12-31T00:31:01  *** jasonzhouu has quit IRC
  82018-12-31T00:32:25  *** jasonzhouu has joined #bitcoin-core-dev
  92018-12-31T01:06:45  *** keddek has joined #bitcoin-core-dev
 102018-12-31T01:14:52  *** grubles has quit IRC
 112018-12-31T01:33:27  *** promag has quit IRC
 122018-12-31T02:09:26  *** promag has joined #bitcoin-core-dev
 132018-12-31T02:17:57  *** promag has quit IRC
 142018-12-31T02:31:36  *** keddek has quit IRC
 152018-12-31T02:57:36  *** EagleTM has quit IRC
 162018-12-31T03:06:49  *** AaronvanW has quit IRC
 172018-12-31T03:26:26  *** grubles has joined #bitcoin-core-dev
 182018-12-31T03:48:01  *** rh0nj has quit IRC
 192018-12-31T03:51:07  *** rh0nj has joined #bitcoin-core-dev
 202018-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.
 212018-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
 222018-12-31T03:59:28  <luke-jr> fanquake: they'll just open them to bump dates on the individual files :/
 232018-12-31T04:07:54  *** spinza has quit IRC
 242018-12-31T04:16:42  *** spinza has joined #bitcoin-core-dev
 252018-12-31T04:37:16  *** justan0theruser has joined #bitcoin-core-dev
 262018-12-31T04:38:23  *** justanotheruser has quit IRC
 272018-12-31T04:38:30  *** justan0theruser is now known as justanotheruser
 282018-12-31T04:44:23  *** cluelessperson has quit IRC
 292018-12-31T04:50:26  *** mistergold has joined #bitcoin-core-dev
 302018-12-31T04:52:35  *** cluelessperson has joined #bitcoin-core-dev
 312018-12-31T05:06:52  *** cluelessperson has quit IRC
 322018-12-31T05:14:55  *** cluelessperson has joined #bitcoin-core-dev
 332018-12-31T05:28:41  <arubi> cheers wumpus
 342018-12-31T05:47:05  *** CodeBlue1776 has quit IRC
 352018-12-31T05:47:22  *** CodeBlue1776 has joined #bitcoin-core-dev
 362018-12-31T05:53:30  *** Sathai has joined #bitcoin-core-dev
 372018-12-31T06:09:21  *** Sathai has quit IRC
 382018-12-31T06:16:33  *** irc_viewer_test has joined #bitcoin-core-dev
 392018-12-31T06:17:09  *** Klox has joined #bitcoin-core-dev
 402018-12-31T06:20:30  *** bitcoin-git has joined #bitcoin-core-dev
 412018-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
 422018-12-31T06:20:30  *** bitcoin-git has left #bitcoin-core-dev
 432018-12-31T06:27:30  *** irc_viewer_test has quit IRC
 442018-12-31T06:30:04  *** irc_viewer_test has joined #bitcoin-core-dev
 452018-12-31T06:31:24  *** irc_viewer_test has joined #bitcoin-core-dev
 462018-12-31T06:32:28  *** jasonzhouu has left #bitcoin-core-dev
 472018-12-31T06:36:20  *** irc_viewer_test has quit IRC
 482018-12-31T06:38:20  *** irc_viewer_test has joined #bitcoin-core-dev
 492018-12-31T06:38:37  *** hebasto has joined #bitcoin-core-dev
 502018-12-31T06:43:31  *** irc_viewer_test has quit IRC
 512018-12-31T06:49:42  *** irc_viewer_test has joined #bitcoin-core-dev
 522018-12-31T07:02:05  *** irc_viewer_test has quit IRC
 532018-12-31T07:17:08  *** rex4539 has joined #bitcoin-core-dev
 542018-12-31T07:32:01  *** rex4539 has quit IRC
 552018-12-31T07:59:35  *** Krellan has joined #bitcoin-core-dev
 562018-12-31T08:14:09  *** thaumavorio has quit IRC
 572018-12-31T08:14:55  *** thaumavorio has joined #bitcoin-core-dev
 582018-12-31T08:38:01  *** rh0nj has quit IRC
 592018-12-31T08:39:08  *** rh0nj has joined #bitcoin-core-dev
 602018-12-31T09:23:31  <wumpus> fanquake: OK
 612018-12-31T09:24:07  <fanquake> wumpus no pressure on your new years eve!
 622018-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 :)
 632018-12-31T09:27:33  <wumpus> don't they need t run some script to update the copyright in the source code as well
 642018-12-31T09:28:07  <fanquake> Yea, Marco has a another PR open that's doing that
 652018-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
 662018-12-31T09:29:23  <wumpus> sure
 672018-12-31T09:32:11  *** bitcoin-git has joined #bitcoin-core-dev
 682018-12-31T09:32:12  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2741b2b6f468...cc07f9ce690c
 692018-12-31T09:32:12  <bitcoin-git> bitcoin/master ae5594d Emil Engler: [Trivial] Update license year range to 2019...
 702018-12-31T09:32:13  <bitcoin-git> bitcoin/master cc07f9c Wladimir J. van der Laan: Merge #15061: [Trivial] Update license year range to 2019...
 712018-12-31T09:32:13  *** bitcoin-git has left #bitcoin-core-dev
 722018-12-31T09:32:44  <fanquake> I guess #14974 is mergable as well.
 732018-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
 742018-12-31T09:32:53  *** bitcoin-git has joined #bitcoin-core-dev
 752018-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
 762018-12-31T09:32:54  *** bitcoin-git has left #bitcoin-core-dev
 772018-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.
 782018-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
 792018-12-31T09:39:38  *** Guyver2 has joined #bitcoin-core-dev
 802018-12-31T09:47:49  *** murrayn has quit IRC
 812018-12-31T09:52:53  <luke-jr> fanquake: 14974 looks incomplete still
 822018-12-31T10:01:58  *** setpill has joined #bitcoin-core-dev
 832018-12-31T10:04:26  *** irc_viewer_test has joined #bitcoin-core-dev
 842018-12-31T10:16:28  *** war10ck has joined #bitcoin-core-dev
 852018-12-31T10:20:18  *** promag has joined #bitcoin-core-dev
 862018-12-31T10:22:09  *** spinza has quit IRC
 872018-12-31T10:23:05  *** irc_viewer_test has quit IRC
 882018-12-31T10:36:59  *** EagleTM has joined #bitcoin-core-dev
 892018-12-31T10:41:43  *** ovovo has joined #bitcoin-core-dev
 902018-12-31T10:44:00  *** spinza has joined #bitcoin-core-dev
 912018-12-31T10:47:56  *** promag has quit IRC
 922018-12-31T10:54:50  *** Krellan has quit IRC
 932018-12-31T10:56:24  *** Lightsword has quit IRC
 942018-12-31T10:56:39  *** Lightsword has joined #bitcoin-core-dev
 952018-12-31T10:57:27  *** jnewbery has quit IRC
 962018-12-31T10:57:41  *** jnewbery has joined #bitcoin-core-dev
 972018-12-31T10:57:48  *** roasbeef has quit IRC
 982018-12-31T10:57:59  *** kallewoof has quit IRC
 992018-12-31T10:58:08  *** roasbeef has joined #bitcoin-core-dev
1002018-12-31T10:58:30  *** CodeBlue1776 has quit IRC
1012018-12-31T10:59:13  *** kallewoof has joined #bitcoin-core-dev
1022018-12-31T10:59:28  *** CodeBlue1776 has joined #bitcoin-core-dev
1032018-12-31T11:21:57  *** TX1683 has quit IRC
1042018-12-31T11:22:47  *** jungly has joined #bitcoin-core-dev
1052018-12-31T11:23:08  *** TX1683 has joined #bitcoin-core-dev
1062018-12-31T11:26:20  *** bitcoin-git has joined #bitcoin-core-dev
1072018-12-31T11:26:20  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cc07f9ce690c...e756eca9e8bf
1082018-12-31T11:26:21  <bitcoin-git> bitcoin/master 06ba779 DrahtBot: Update copyright headers to 2018
1092018-12-31T11:26:21  <bitcoin-git> bitcoin/master 1a49a0e DrahtBot: Bump manpages
1102018-12-31T11:26:22  <bitcoin-git> bitcoin/master e756eca MarcoFalke: Merge #15054: Update copyright headers to 2018...
1112018-12-31T11:26:22  *** bitcoin-git has left #bitcoin-core-dev
1122018-12-31T11:27:00  *** bitcoin-git has joined #bitcoin-core-dev
1132018-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
1142018-12-31T11:27:01  *** bitcoin-git has left #bitcoin-core-dev
1152018-12-31T11:33:09  *** wraithm has quit IRC
1162018-12-31T11:34:47  *** wraithm has joined #bitcoin-core-dev
1172018-12-31T11:37:43  *** war10ck has left #bitcoin-core-dev
1182018-12-31T11:38:02  *** Emcy has quit IRC
1192018-12-31T11:42:40  *** AaronvanW has joined #bitcoin-core-dev
1202018-12-31T11:48:55  *** Emcy has joined #bitcoin-core-dev
1212018-12-31T11:52:31  *** dviola has joined #bitcoin-core-dev
1222018-12-31T12:03:09  *** Emcy has quit IRC
1232018-12-31T12:03:37  *** Emcy has joined #bitcoin-core-dev
1242018-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
1252018-12-31T12:46:48  <cjd> now I see endian swapping macros in bitcoin and they look almost exactly like my old code
1262018-12-31T12:47:12  *** CodeBlue1776 has quit IRC
1272018-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
1282018-12-31T12:48:21  *** CodeBlue1776 has joined #bitcoin-core-dev
1292018-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.
1302018-12-31T12:54:50  <cjd> you mean aliasing ?
1312018-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)
1322018-12-31T12:56:29  <gmaxwell> endian fragile code also usually mishandles alignment.
1332018-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...)
1342018-12-31T12:58:42  <cjd> I've used alignment assertions in the past because I generally would rather everything be aligned than not know
1352018-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
1362018-12-31T12:59:42  <cjd> *being prepared to swap them
1372018-12-31T13:01:24  <gmaxwell> it's also no overhead because the compiler will totally eliminate the swaps where they aren't needed.
1382018-12-31T13:02:33  <cjd> runtime overhead, I was thinking development overhead (which is my main concern)
1392018-12-31T13:03:06  <cjd> easy to make things have no runtime overhead in most procs, specify everything as EL
1402018-12-31T13:03:34  <sipa> thankfully we don't (need to) touch the serialization code very often
1412018-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)
1422018-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. :)
1432018-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).
1442018-12-31T13:08:35  <cjd> I tend not to cast pointers that often, though I do a fair amount of memcpy
1452018-12-31T13:09:49  *** mistergo1d has joined #bitcoin-core-dev
1462018-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.
1472018-12-31T13:11:51  <cjd> struct big_struct_with_lots_of_fields s;  memcpy(s, data, sizeof s);
1482018-12-31T13:12:48  *** spaced0ut has quit IRC
1492018-12-31T13:13:07  *** mistergold has quit IRC
1502018-12-31T13:13:59  <gmaxwell> uhh, so you know that the structs layout in memory is totally not portable, right? :P
1512018-12-31T13:14:32  <gmaxwell> not just in terms of endianness.
1522018-12-31T13:14:36  <cjd> yes, and I also know that linux will run into problems before I do :P
1532018-12-31T13:15:05  <cjd> I don't use bitfields in structs I'm planning to write on the wire, they do
1542018-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
1552018-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 )
1562018-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
1572018-12-31T13:16:54  <sipa> it seems much more of a worry than just using layout-neutral code though :)
1582018-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
1592018-12-31T13:17:14  <cjd> ehh
1602018-12-31T13:17:46  <sipa> it's probably getting a bit offtopic here
1612018-12-31T13:17:50  <cjd> if (programmer_used_ub()) { insert_backdoor_code(); }    I don't think the compiler authors are completely off the hook
1622018-12-31T13:17:58  <cjd> sorry
1632018-12-31T13:18:06  <cjd> happy newyear btw
1642018-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.
1652018-12-31T13:19:58  <cjd> Yeah, when I'm trying to get something accepted I follow whatever rules the project uses
1662018-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
1672018-12-31T13:22:00  *** reardencode has quit IRC
1682018-12-31T13:25:14  <midnightmagic> +1 endian-independent design..
1692018-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.
1702018-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
1712018-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.
1722018-12-31T13:27:15  <wumpus> or char is two bytes...
1732018-12-31T13:27:43  <wumpus> maybe big endian will be one of those in the future but I don't think we're there
1742018-12-31T13:27:59  <gmaxwell> wumpus: I agree with you, though I have written code for char-is-two bytes platforms.
1752018-12-31T13:27:59  <cjd> wumpus: that's my thinking when I do projects these days
1762018-12-31T13:28:16  <gmaxwell> (TI VLIW DSPs)
1772018-12-31T13:28:20  <midnightmagic> Bitcoin can't run on an Amiga. :-P
1782018-12-31T13:28:22  <cjd> gmaxwell: reminds me of libdisalloc
1792018-12-31T13:28:39  <wumpus> cjd: I don't start projects in C anymore anyway :)
1802018-12-31T13:28:56  <midnightmagic> :-(
1812018-12-31T13:29:46  <cjd> good move, though I have not seen a really good replacement when speed is a high priority
1822018-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)
1832018-12-31T13:30:34  <wumpus> or 'is char signed', eeh I made some terrible mistakes with that
1842018-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"?
1852018-12-31T13:31:04  <wumpus> gmaxwell: no, there's i16, u16, nothing else IIRC
1862018-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
1872018-12-31T13:31:39  <wumpus> gmaxwell: though, thinking of it, wouldn't be surprised if it exists in some crate
1882018-12-31T13:31:49  <gmaxwell> sipa: it's like char but without the char signness baggage?
1892018-12-31T13:31:50  <wumpus> gmaxwell: it's just not the common way of doing things and I like that
1902018-12-31T13:32:21  <sipa> gmaxwell: it's basically an 8-bit vector without integer aspects
1912018-12-31T13:32:35  <sipa> so no arithmetic, only bitwise operations
1922018-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
1932018-12-31T13:32:48  <midnightmagic> machine level. :(
1942018-12-31T13:32:59  <gmaxwell> sipa: but its allowed to alias like char?
1952018-12-31T13:33:13  <gmaxwell> e.g. can you implement memcpy using it?
1962018-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...
1972018-12-31T13:33:17  <sipa> yup
1982018-12-31T13:33:29  <sipa> gmaxwell: yup, byte pointers can alias any other pointer
1992018-12-31T13:33:39  <gmaxwell> sipa: sounds reasonable.
2002018-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
2012018-12-31T13:34:45  <wumpus> all the UB pitfalls are not necessary in a langage and harmful
2022018-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.
2032018-12-31T13:36:18  <midnightmagic> oh well
2042018-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).
2052018-12-31T13:36:39  <wumpus> 'baggage' is kind of the right word, anyhow, so many exceptions and irregularities for history's sake
2062018-12-31T13:36:40  <sipa> i like C as a lowest common denominator... if something has to work everywhere, C will do the job
2072018-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."
2082018-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
2092018-12-31T13:39:10  <cjd> And I still cast pointers and violate aliasing rules, because it's fast
2102018-12-31T13:39:23  <gmaxwell> you /really/ should not.
2112018-12-31T13:39:40  <sipa> cjd: i'm a bit skeptical that it actually gains you any speed
2122018-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)
2132018-12-31T13:40:28  *** dviola has quit IRC
2142018-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
2152018-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
2162018-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.
2172018-12-31T13:41:49  <cjd> agreed on that point
2182018-12-31T13:41:50  <sipa> OAOBle32toh, sorry
2192018-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
2202018-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... :)
2212018-12-31T13:43:12  <cjd> I like the Rust vision of aliasing since in theory the compiler gets a lot more freedom
2222018-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... :)
2232018-12-31T13:43:31  <wumpus> gmaxwell: yep! this is what makes unsafe {} in rust better than having *everything* unsafe, I guess
2242018-12-31T13:43:51  *** dendisuhubdy has joined #bitcoin-core-dev
2252018-12-31T13:44:06  <cjd> we're slowly inching in the direction of everything being proven
2262018-12-31T13:44:10  <wumpus> at least the 'I'm doing crazy things here' sections are clearly cordoned off for review
2272018-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.
2282018-12-31T13:44:41  <cjd> very good point
2292018-12-31T13:45:33  <MarcoFalke> Should we add a repo to bitcoin-core with fuzz seeds?
2302018-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
2312018-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
2322018-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
2332018-12-31T13:46:02  <gmaxwell> them easier.
2342018-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.
2352018-12-31T13:46:56  <wumpus> gmaxwell: rihgt
2362018-12-31T13:47:05  *** Guyver2 has quit IRC
2372018-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
2382018-12-31T13:47:22  <gmaxwell> thats a really low bar, however.
2392018-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
2402018-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
2412018-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.
2422018-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
2432018-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
2442018-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.
2452018-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.
2462018-12-31T13:51:21  <gmaxwell> e.g. the nacl sandbox essentially gives code written in whatever langauge the same 'provable' properties as JS.
2472018-12-31T13:51:34  <gmaxwell> Yet there seems to be no move to go deploy things that way.
2482018-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
2492018-12-31T13:52:08  <gmaxwell> even though the performance hit is radically lower than any of the popular interperted langauges.
2502018-12-31T13:52:09  <cjd> (IMO)
2512018-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
2522018-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 :)
2532018-12-31T13:54:56  <gmaxwell> presumably people would just extend haskell until it contained all of C++ and JS. ... :P
2542018-12-31T13:55:42  * midnightmagic jumps out window
2552018-12-31T13:55:44  <wumpus> gmaxwell: yes, it's a mistake to think of progress as linear, even in the area of computing
2562018-12-31T13:56:07  *** dendisuhubdy has quit IRC
2572018-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.
2582018-12-31T13:57:11  <wumpus> yes
2592018-12-31T13:58:02  <cjd> There are some people who think that the 50s was the best time in history
2602018-12-31T13:58:02  <wumpus> good old time when hardware improvements could still keep up with growth in software bloat :-)
2612018-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.
2622018-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.
2632018-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
2642018-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".
2652018-12-31T14:00:00  <gmaxwell> I'm sure things will improve again later.
2662018-12-31T14:00:14  <wumpus> I'm not as hopeful about the future
2672018-12-31T14:00:39  <cjd> Machines get faster, programming gets easier, and typical applications remain just within the range of "tollerable"
2682018-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.
2692018-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
2702018-12-31T14:02:34  <wumpus> I'm not convinced that is true, a lot of learning, say, JS is baggage as well
2712018-12-31T14:02:43  <gmaxwell> That isn't at all clear to me.
2722018-12-31T14:02:45  <wumpus> easy programming languages existed in the 90's as well
2732018-12-31T14:03:14  <gmaxwell> some of them were actually pretty effective, like hypercard.
2742018-12-31T14:03:20  <wumpus> yes
2752018-12-31T14:03:25  <gmaxwell> (in a way that I dont think you can credit JS with being)
2762018-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)
2772018-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
2782018-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
2792018-12-31T14:05:33  <cjd> JS frameworks are a primordial soup for design patterns
2802018-12-31T14:06:03  <gmaxwell> also basically no feedback on why things aren't working right when you mix the soup parts incorrectly.
2812018-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.
2822018-12-31T14:07:48  <fanquake> npm install *everything*
2832018-12-31T14:08:11  * sipa imports the is_integer npm package
2842018-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
2852018-12-31T14:08:35  * midnightmagic sadly stares at the smoking crater where sipa was
2862018-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.
2872018-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
2882018-12-31T14:10:49  <wumpus> gmaxwell: yep...
2892018-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.
2902018-12-31T14:11:55  <cjd> That's an interesting observation
2912018-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...
2922018-12-31T14:13:12  *** spaced0ut has joined #bitcoin-core-dev
2932018-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
2942018-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
2952018-12-31T14:15:24  <wumpus> cjd: you'd expect so
2962018-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
2972018-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.
2982018-12-31T14:18:31  <cjd> I suspect the same methodology works for evaluating editors, distros and blockchains
2992018-12-31T14:21:56  *** cluelessperson has quit IRC
3002018-12-31T14:29:55  *** cluelessperson has joined #bitcoin-core-dev
3012018-12-31T14:55:29  *** mistergo1d has quit IRC
3022018-12-31T14:55:33  *** mistergold has joined #bitcoin-core-dev
3032018-12-31T15:03:19  *** bitcoin-git has joined #bitcoin-core-dev
3042018-12-31T15:03:20  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e756eca9e8bf...f5a70d146259
3052018-12-31T15:03:20  <bitcoin-git> bitcoin/master 3019ba2 Ben Carman: Making supported operating systems more clear
3062018-12-31T15:03:21  <bitcoin-git> bitcoin/master f5a70d1 Wladimir J. van der Laan: Merge #14974: doc: Removing redundant line: "Windows XP not supported"...
3072018-12-31T15:03:21  *** bitcoin-git has left #bitcoin-core-dev
3082018-12-31T15:04:00  *** bitcoin-git has joined #bitcoin-core-dev
3092018-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
3102018-12-31T15:04:00  *** bitcoin-git has left #bitcoin-core-dev
3112018-12-31T15:07:37  *** setpill has quit IRC
3122018-12-31T15:17:43  *** jungly has quit IRC
3132018-12-31T15:19:04  *** dermoth has joined #bitcoin-core-dev
3142018-12-31T15:44:58  *** AaronvanW has quit IRC
3152018-12-31T15:55:18  *** AaronvanW has joined #bitcoin-core-dev
3162018-12-31T15:55:19  *** AaronvanW has quit IRC
3172018-12-31T15:55:38  *** AaronvanW has joined #bitcoin-core-dev
3182018-12-31T16:03:43  *** dermoth has quit IRC
3192018-12-31T16:04:23  *** dermoth has joined #bitcoin-core-dev
3202018-12-31T16:24:38  *** AaronvanW has quit IRC
3212018-12-31T16:31:12  *** rex4539 has joined #bitcoin-core-dev
3222018-12-31T16:33:02  *** rh0nj has quit IRC
3232018-12-31T16:33:38  *** tryphe_ has joined #bitcoin-core-dev
3242018-12-31T16:35:04  *** mistergold has quit IRC
3252018-12-31T16:35:19  *** tryphe_000 has joined #bitcoin-core-dev
3262018-12-31T16:36:32  *** tryphe has quit IRC
3272018-12-31T16:38:23  *** tryphe_ has quit IRC
3282018-12-31T16:42:27  *** hebasto has quit IRC
3292018-12-31T16:49:17  *** dviola has joined #bitcoin-core-dev
3302018-12-31T16:49:53  *** dviola has joined #bitcoin-core-dev
3312018-12-31T16:57:15  *** Skirmant has quit IRC
3322018-12-31T16:58:04  *** Skirmant has joined #bitcoin-core-dev
3332018-12-31T17:04:23  *** elichai2 has joined #bitcoin-core-dev
3342018-12-31T17:18:40  *** cobega has joined #bitcoin-core-dev
3352018-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).
3362018-12-31T17:24:56  <achow101> cobega: did you do listunspent with the watch_only option set to true?
3372018-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.
3382018-12-31T17:29:27  *** EagleTM has quit IRC
3392018-12-31T17:29:30  <cobega> moment, will try first listunspent with watch only set to true.
3402018-12-31T17:31:11  <cobega> how to activate watch only option (https://bitcoin.org/en/developer-reference#listunspent)?
3412018-12-31T17:32:28  <cobega> It's a bit strange, using ./bitcoin-cli listreceivedbyaddress 1 true true I can see the multisig address
3422018-12-31T17:45:24  <gwillen> cobega: yeah the thing you want is to use importaddress with rescan false
3432018-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
3442018-12-31T17:45:46  <gwillen> then the rescan will be very fast
3452018-12-31T17:45:54  <gwillen> or if you import before sending you don't need to rescan at all
3462018-12-31T17:46:06  <gwillen> I can confirm the import was required when I tried to do this, so I assume it is necessary
3472018-12-31T17:46:11  <achow101> oh whoops. listunspent doesn't have a watchonly option
3482018-12-31T17:46:45  <gwillen> I don't know why addmultisigaddress doesn't import
3492018-12-31T17:47:05  <gwillen> or what distinguishes it from createmultisig given that it doesn't
3502018-12-31T17:49:21  <cobega> what about https://bitcoin.org/en/developer-reference#importmulti ?
3512018-12-31T17:49:44  <achow101> cobega: you can use importmulti too with a timestamp of the block height you first used the address
3522018-12-31T17:51:03  <achow101> gwillen: addmultisigaddress adds the redeemScript to your wallet
3532018-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
3542018-12-31T17:55:10  *** brianhoffman_ has joined #bitcoin-core-dev
3552018-12-31T17:55:42  *** brianhoffman has quit IRC
3562018-12-31T17:55:43  *** brianhoffman_ is now known as brianhoffman
3572018-12-31T18:00:03  <gwillen> achow101: ahh so it makes it solvable
3582018-12-31T18:00:05  <gwillen> that makes sense, thanks
3592018-12-31T18:01:25  <sipa> gwillen: createmultisig is the utility non-wallet version of the RapC, to just let you compute the address
3602018-12-31T18:01:34  <sipa> addmultisigaddress is the wallet importing version
3612018-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?
3622018-12-31T18:11:18  *** ovovo has quit IRC
3632018-12-31T18:17:38  <achow101> cobega: the timestamp indicates from when to start rescanning. it basically combines importaddress and rescanblockchain
3642018-12-31T18:20:37  <cobega> Understand :) But should I set rescan to true or false when using the timestamp parameter?
3652018-12-31T18:21:46  <achow101> set it to true
3662018-12-31T18:26:20  *** fabianfabian has joined #bitcoin-core-dev
3672018-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?
3682018-12-31T18:31:31  <achow101> no, it's {"scriptPubKey":{"address":"..."}}
3692018-12-31T18:35:24  <cobega> using it like ./bitcoin-cli importmulti '[{"scriptPubKey":{"address":"2MtxopLjtoJbfxJqNptZR17RzPGSTSTmqZsy"},"timestamp":1546218000}]' it says "invalid address"
3702018-12-31T18:35:46  <achow101> is your node in testnet mode?
3712018-12-31T18:35:54  <achow101> that's a testnet address
3722018-12-31T18:36:02  <cobega> yes it is
3732018-12-31T18:36:25  <cobega> ./bitcoin-cli getnewaddress 2Mto6bcnFMdZ7M6E76Sd3PXYJzZxF9dupzG
3742018-12-31T18:36:43  <cobega> Using testnet while development of application.
3752018-12-31T18:38:24  <arubi> the 2Mtxop one is invalid
3762018-12-31T18:43:01  <cobega> shame on me. works as expected :)
3772018-12-31T18:43:25  <arubi> :)
3782018-12-31T18:47:32  *** Guyver2 has joined #bitcoin-core-dev
3792018-12-31T19:07:11  *** hebasto has joined #bitcoin-core-dev
3802018-12-31T19:08:15  *** rex4539 has quit IRC
3812018-12-31T19:19:50  *** EagleTM has joined #bitcoin-core-dev
3822018-12-31T19:22:25  *** EagleTM has joined #bitcoin-core-dev
3832018-12-31T19:24:46  *** EagleTM has quit IRC
3842018-12-31T19:25:14  *** EagleTM has joined #bitcoin-core-dev
3852018-12-31T19:30:53  *** spaced0ut has quit IRC
3862018-12-31T19:37:57  *** EagleTM has quit IRC
3872018-12-31T19:46:07  <gwillen> sipa: except that addmultisigaddress only sort of imports
3882018-12-31T19:46:28  <gwillen> it makes it solveable but it doesn't make it "watchonly", i.e. look for utxos it owns
3892018-12-31T19:48:53  <sipa> gwillen: yes, you need importaddress for that
3902018-12-31T19:49:13  *** dviola has quit IRC
3912018-12-31T19:49:17  <sipa> addmuktisigaddress predates support for watchonly addresses
3922018-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
3932018-12-31T19:50:00  <sipa> (yes, that makes no sense)
3942018-12-31T19:55:52  *** rex4539 has joined #bitcoin-core-dev
3952018-12-31T19:59:49  *** Krellan has joined #bitcoin-core-dev
3962018-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"}
3972018-12-31T20:04:07  *** rh0nj has joined #bitcoin-core-dev
3982018-12-31T20:10:44  *** Krellan has quit IRC
3992018-12-31T20:10:59  <fabianfabian> I think your first param is an object but should be an array
4002018-12-31T20:12:31  <fabianfabian> so just enclose it in []
4012018-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/
4022018-12-31T20:22:35  *** CodeBlue1776 has quit IRC
4032018-12-31T20:22:49  *** CodeBlue1776 has joined #bitcoin-core-dev
4042018-12-31T20:26:35  <gwillen> there's a stray close brace at the end of params there
4052018-12-31T20:26:37  <gwillen> not sure if it's doing anything
4062018-12-31T20:26:51  <gwillen> wait, nevermind, that's the outer braces, sorry
4072018-12-31T20:28:23  <cobega> your code from 21:13 is running.
4082018-12-31T20:36:51  *** dermoth has quit IRC
4092018-12-31T20:50:11  *** dermoth has joined #bitcoin-core-dev
4102018-12-31T21:05:48  *** cobega has quit IRC
4112018-12-31T21:14:39  *** spinza has quit IRC
4122018-12-31T21:25:28  *** spinza has joined #bitcoin-core-dev
4132018-12-31T21:41:35  *** promag has joined #bitcoin-core-dev
4142018-12-31T21:42:20  *** promag has quit IRC
4152018-12-31T21:51:26  *** elichai2 has quit IRC
4162018-12-31T22:11:29  *** Krellan has joined #bitcoin-core-dev
4172018-12-31T22:12:27  *** davec has quit IRC
4182018-12-31T22:13:13  *** davec has joined #bitcoin-core-dev
4192018-12-31T22:16:11  *** Krellan has quit IRC
4202018-12-31T22:18:47  *** rex4539 has quit IRC
4212018-12-31T22:34:01  *** spinza has quit IRC
4222018-12-31T22:38:22  *** spinza has joined #bitcoin-core-dev
4232018-12-31T22:48:07  *** dviola has joined #bitcoin-core-dev
4242018-12-31T22:52:45  *** bitcoin-git has joined #bitcoin-core-dev
4252018-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
4262018-12-31T22:52:46  *** bitcoin-git has left #bitcoin-core-dev
4272018-12-31T23:08:16  *** tryphe_000 is now known as tryphe
4282018-12-31T23:25:23  *** murrayn has joined #bitcoin-core-dev
4292018-12-31T23:36:29  *** hebasto has quit IRC
4302018-12-31T23:42:52  *** brianhoffman_ has joined #bitcoin-core-dev
4312018-12-31T23:45:34  *** brianhoffman has quit IRC
4322018-12-31T23:45:34  *** brianhoffman_ is now known as brianhoffman