--- Log opened Mon Dec 31 00:00:07 2018 00:14 -!- thaumavorio [~thaumavor@thaumavor.io] has quit [Quit: ZNC 1.7.1 - https://znc.in] 00:14 -!- thaumavorio [~thaumavor@thaumavor.io] has joined #bitcoin-core-dev 00:38 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 00:39 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 01:23 < wumpus> fanquake: OK 01:24 < fanquake> wumpus no pressure on your new years eve! 01:26 < 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 :) 01:27 < wumpus> don't they need t run some script to update the copyright in the source code as well 01:28 < fanquake> Yea, Marco has a another PR open that's doing that 01:28 < fanquake> We could probably combine the two, but I thought given they are both open already we can just get it over with hah 01:29 < wumpus> sure 01:32 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-bhpmpncvhdidxtpq] has joined #bitcoin-core-dev 01:32 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2741b2b6f468...cc07f9ce690c 01:32 < bitcoin-git> bitcoin/master ae5594d Emil Engler: [Trivial] Update license year range to 2019... 01:32 < bitcoin-git> bitcoin/master cc07f9c Wladimir J. van der Laan: Merge #15061: [Trivial] Update license year range to 2019... 01:32 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-bhpmpncvhdidxtpq] has left #bitcoin-core-dev [] 01:32 < fanquake> I guess #14974 is mergable as well. 01:32 < gribble> https://github.com/bitcoin/bitcoin/issues/14974 | doc: Removing redundant line: "Windows XP not supported" by benthecarman · Pull Request #14974 · bitcoin/bitcoin · GitHub 01:32 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-dvbuigsrjavitkao] has joined #bitcoin-core-dev 01:32 < 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 01:32 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-dvbuigsrjavitkao] has left #bitcoin-core-dev [] 01:34 < fanquake> The other copyright bump is in #15054, which assuming it's extensive, should be fine. Not sure we need a scripted diff. 01:34 < gribble> https://github.com/bitcoin/bitcoin/issues/15054 | Update copyright headers to 2018 by DrahtBot · Pull Request #15054 · bitcoin/bitcoin · GitHub 01:39 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:47 -!- murrayn [~murrayn@unaffiliated/murrayn] has quit [Quit: Leaving] 01:52 < luke-jr> fanquake: 14974 looks incomplete still 02:01 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 02:04 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has joined #bitcoin-core-dev 02:16 -!- war10ck [uid339220@gateway/web/irccloud.com/x-urvpsnyvckvpkfgj] has joined #bitcoin-core-dev 02:20 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 02:22 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 02:23 -!- irc_viewer_test [irc_viewer@gateway/vpn/privateinternetaccess/ircviewertest/x-06412631] has quit [Quit: irc_viewer_test] 02:36 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 02:41 -!- ovovo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 02:44 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 02:47 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection] 02:54 -!- Krellan [~Krellan@2601:642:100:30a7:1950:e8d6:a35e:d0d8] has quit [Remote host closed the connection] 02:56 -!- Lightsword [~Lightswor@107.170.253.193] has quit [Quit: ZNC] 02:56 -!- Lightsword [~Lightswor@107.170.253.193] has joined #bitcoin-core-dev 02:57 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds] 02:57 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 02:57 -!- roasbeef [~root@104.131.26.124] has quit [Ping timeout: 246 seconds] 02:57 -!- kallewoof [~quassel@fp96f94c66.tkyc515.ap.nuro.jp] has quit [Quit: No Ping reply in 180 seconds.] 02:58 -!- roasbeef [~root@104.131.26.124] has joined #bitcoin-core-dev 02:58 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Ping timeout: 246 seconds] 02:59 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has joined #bitcoin-core-dev 02:59 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev 03:21 -!- TX1683 [~TX1683@unaffiliated/tx1683] has quit [Ping timeout: 246 seconds] 03:22 -!- jungly [~quassel@79.8.200.97] has joined #bitcoin-core-dev 03:23 -!- TX1683 [~TX1683@unaffiliated/tx1683] has joined #bitcoin-core-dev 03:26 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-sevwigwhgpvqveiv] has joined #bitcoin-core-dev 03:26 < bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cc07f9ce690c...e756eca9e8bf 03:26 < bitcoin-git> bitcoin/master 06ba779 DrahtBot: Update copyright headers to 2018 03:26 < bitcoin-git> bitcoin/master 1a49a0e DrahtBot: Bump manpages 03:26 < bitcoin-git> bitcoin/master e756eca MarcoFalke: Merge #15054: Update copyright headers to 2018... 03:26 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-sevwigwhgpvqveiv] has left #bitcoin-core-dev [] 03:27 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-skskzkpoegnuaoqu] has joined #bitcoin-core-dev 03:27 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #15054: Update copyright headers to 2018 (master...DrahtBot_bump_headers) https://github.com/bitcoin/bitcoin/pull/15054 03:27 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-skskzkpoegnuaoqu] has left #bitcoin-core-dev [] 03:33 -!- wraithm [~wraithm@unaffiliated/wraithm] has quit [Ping timeout: 246 seconds] 03:34 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined #bitcoin-core-dev 03:37 -!- war10ck [uid339220@gateway/web/irccloud.com/x-urvpsnyvckvpkfgj] has left #bitcoin-core-dev [] 03:38 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection] 03:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:48 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 03:52 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 04:03 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection] 04:03 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 04:46 < 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 04:46 < cjd> now I see endian swapping macros in bitcoin and they look almost exactly like my old code 04:47 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Read error: Connection reset by peer] 04:47 < 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 04:48 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev 04:53 < 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. 04:54 < cjd> you mean aliasing ? 04:55 < 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) 04:56 < gmaxwell> endian fragile code also usually mishandles alignment. 04:57 < 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...) 04:58 < cjd> I've used alignment assertions in the past because I generally would rather everything be aligned than not know 04:59 < 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 04:59 < cjd> *being prepared to swap them 05:01 < gmaxwell> it's also no overhead because the compiler will totally eliminate the swaps where they aren't needed. 05:02 < cjd> runtime overhead, I was thinking development overhead (which is my main concern) 05:03 < cjd> easy to make things have no runtime overhead in most procs, specify everything as EL 05:03 < sipa> thankfully we don't (need to) touch the serialization code very often 05:03 < gmaxwell> (also, on lots of processors, though not x86, byteswapping is essentially free because it just gets turned into a flag on load instructions) 05:05 < 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. :) 05:06 < 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). 05:08 < cjd> I tend not to cast pointers that often, though I do a fair amount of memcpy 05:09 -!- mistergo1d [~mistergol@77.243.25.197] has joined #bitcoin-core-dev 05:10 < gmaxwell> right, well, if you have to call memcpy you can just call something else instead that handles byteorder if required. 05:11 < cjd> struct big_struct_with_lots_of_fields s; memcpy(s, data, sizeof s); 05:12 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Quit: Leaving] 05:13 -!- mistergold [~mistergol@77.243.25.197] has quit [Ping timeout: 240 seconds] 05:13 < gmaxwell> uhh, so you know that the structs layout in memory is totally not portable, right? :P 05:14 < gmaxwell> not just in terms of endianness. 05:14 < cjd> yes, and I also know that linux will run into problems before I do :P 05:15 < cjd> I don't use bitfields in structs I'm planning to write on the wire, they do 05:15 < 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 05:16 < 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 ) 05:16 < sipa> with enough safeguards against all possible choices a compiler/architecture could make, i'm sure you can make this reasonably safe 05:16 < sipa> it seems much more of a worry than just using layout-neutral code though :) 05:17 < 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 05:17 < cjd> ehh 05:17 < sipa> it's probably getting a bit offtopic here 05:17 < cjd> if (programmer_used_ub()) { insert_backdoor_code(); } I don't think the compiler authors are completely off the hook 05:17 < cjd> sorry 05:18 < cjd> happy newyear btw 05:18 < 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. 05:19 < cjd> Yeah, when I'm trying to get something accepted I follow whatever rules the project uses 05:21 < 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 05:21 -!- reardencode [~reardenco@shrugged.reardencode.com] has quit [Ping timeout: 246 seconds] 05:25 < midnightmagic> +1 endian-independent design.. 05:26 < 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. 05:26 < 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 05:27 < 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. 05:27 < wumpus> or char is two bytes... 05:27 < wumpus> maybe big endian will be one of those in the future but I don't think we're there 05:27 < gmaxwell> wumpus: I agree with you, though I have written code for char-is-two bytes platforms. 05:27 < cjd> wumpus: that's my thinking when I do projects these days 05:28 < gmaxwell> (TI VLIW DSPs) 05:28 < midnightmagic> Bitcoin can't run on an Amiga. :-P 05:28 < cjd> gmaxwell: reminds me of libdisalloc 05:28 < wumpus> cjd: I don't start projects in C anymore anyway :) 05:28 < midnightmagic> :-( 05:29 < cjd> good move, though I have not seen a really good replacement when speed is a high priority 05:29 < 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) 05:30 < wumpus> or 'is char signed', eeh I made some terrible mistakes with that 05:30 < gmaxwell> wumpus: I assume there are also standard types in rust for "the fastest thing that is at least 16 bits"? 05:31 < wumpus> gmaxwell: no, there's i16, u16, nothing else IIRC 05:31 < sipa> C++17 introduces the 'byte' type, which allows accessing the representation on memory of other types, without being an int type 05:31 < wumpus> gmaxwell: though, thinking of it, wouldn't be surprised if it exists in some crate 05:31 < gmaxwell> sipa: it's like char but without the char signness baggage? 05:31 < wumpus> gmaxwell: it's just not the common way of doing things and I like that 05:32 < sipa> gmaxwell: it's basically an 8-bit vector without integer aspects 05:32 < sipa> so no arithmetic, only bitwise operations 05:32 < 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 05:32 < midnightmagic> machine level. :( 05:32 < gmaxwell> sipa: but its allowed to alias like char? 05:33 < gmaxwell> e.g. can you implement memcpy using it? 05:33 < 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... 05:33 < sipa> yup 05:33 < sipa> gmaxwell: yup, byte pointers can alias any other pointer 05:33 < gmaxwell> sipa: sounds reasonable. 05:33 < 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 05:34 < wumpus> all the UB pitfalls are not necessary in a langage and harmful 05:36 < 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. 05:36 < midnightmagic> oh well 05: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). 05:36 < wumpus> 'baggage' is kind of the right word, anyhow, so many exceptions and irregularities for history's sake 05:36 < sipa> i like C as a lowest common denominator... if something has to work everywhere, C will do the job 05:37 < 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." 05:37 < 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 05:39 < cjd> And I still cast pointers and violate aliasing rules, because it's fast 05:39 < gmaxwell> you /really/ should not. 05:39 < sipa> cjd: i'm a bit skeptical that it actually gains you any speed 05:39 < gmaxwell> correctly written code is seldom any slower. (not to mention that only a tiny fraction of code is actually performance relavant) 05:40 -!- dviola [~diego@unaffiliated/dviola] has quit [Ping timeout: 245 seconds] 05:40 < 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 05:41 < 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 05:41 < 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. 05:41 < cjd> agreed on that point 05:41 < sipa> OAOBle32toh, sorry 05:41 < 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 05:42 < gmaxwell> wumpus: also they correctly estimate their best, or even just average, capability... which is a massive overestimate of them at their dumbest moment... :) 05:43 < cjd> I like the Rust vision of aliasing since in theory the compiler gets a lot more freedom 05:43 < gmaxwell> The same humans that one in one-hundred morings try to put their pants on inside or or their shirt on backwards... :) 05:43 < wumpus> gmaxwell: yep! this is what makes unsafe {} in rust better than having *everything* unsafe, I guess 05:43 -!- dendisuhubdy [~dendisuhu@125.160.114.221] has joined #bitcoin-core-dev 05:44 < cjd> we're slowly inching in the direction of everything being proven 05:44 < wumpus> at least the 'I'm doing crazy things here' sections are clearly cordoned off for review 05:44 < 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. 05:44 < cjd> very good point 05:45 < MarcoFalke> Should we add a repo to bitcoin-core with fuzz seeds? 05:45 < 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 05:45 < 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 05:46 < 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 05:46 < gmaxwell> them easier. 05:46 < gmaxwell> right now the only code that is even somewhat easy to prove properties of is code that generally doesn't need proofs. 05:46 < wumpus> gmaxwell: rihgt 05:47 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 05:47 < 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 05:47 < gmaxwell> thats a really low bar, however. 05:47 < cjd> I expect proof to creep in from the side of proving what code cannot do rather than proving what it will do 05:48 < 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 05:48 < gmaxwell> of course, getting rid of one or more whole classes of bugs is a win. More time to spend on other things. 05:49 < 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 05:49 < 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 05:49 < gmaxwell> But I think that e.g. JS hurts program safty in ways that more than make up for the lack of segfaults. 05:50 < gmaxwell> you can make C code segfault free too-- just run it in a sandbox that halts cleanly when native execution would have segfaulted. 05:51 < gmaxwell> e.g. the nacl sandbox essentially gives code written in whatever langauge the same 'provable' properties as JS. 05:51 < gmaxwell> Yet there seems to be no move to go deploy things that way. 05:51 < 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 05:52 < gmaxwell> even though the performance hit is radically lower than any of the popular interperted langauges. 05:52 < cjd> (IMO) 05:53 < 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 05:54 < 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 :) 05:54 < gmaxwell> presumably people would just extend haskell until it contained all of C++ and JS. ... :P 05:55 * midnightmagic jumps out window 05:55 < wumpus> gmaxwell: yes, it's a mistake to think of progress as linear, even in the area of computing 05:56 -!- dendisuhubdy [~dendisuhu@125.160.114.221] has quit [Remote host closed the connection] 05:56 < 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. 05:57 < wumpus> yes 05:58 < cjd> There are some people who think that the 50s was the best time in history 05:58 < wumpus> good old time when hardware improvements could still keep up with growth in software bloat :-) 05:58 < 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. 05:58 < 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. 05:59 < 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 05:59 < gmaxwell> Like "millseconds to respond to user input in the 99th percentile". Or, "doesn't secretly send your private data to third parties". 06:00 < gmaxwell> I'm sure things will improve again later. 06:00 < wumpus> I'm not as hopeful about the future 06:00 < cjd> Machines get faster, programming gets easier, and typical applications remain just within the range of "tollerable" 06:01 < 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. 06:02 < 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 06:02 < wumpus> I'm not convinced that is true, a lot of learning, say, JS is baggage as well 06:02 < gmaxwell> That isn't at all clear to me. 06:02 < wumpus> easy programming languages existed in the 90's as well 06:03 < gmaxwell> some of them were actually pretty effective, like hypercard. 06:03 < wumpus> yes 06:03 < gmaxwell> (in a way that I dont think you can credit JS with being) 06:04 < gmaxwell> (I mean actually effective at allowing less skilled/trained people to create non-trivial useful programs with only moderate effort) 06:05 < cjd> well, sometimes evolution carries us down a fluke path, we have to try a lot of things wrong before we get something right 06:05 < 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 06:05 < cjd> JS frameworks are a primordial soup for design patterns 06:06 < gmaxwell> also basically no feedback on why things aren't working right when you mix the soup parts incorrectly. 06:07 < 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. 06:07 < fanquake> npm install *everything* 06:08 * sipa imports the is_integer npm package 06:08 < 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 06:08 * midnightmagic sadly stares at the smoking crater where sipa was 06:09 < 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. 06:10 < 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 06:10 < wumpus> gmaxwell: yep... 06: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. 06:11 < cjd> That's an interesting observation 06:13 < 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... 06:13 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev 06:13 < cjd> But when efficiency is critical, one would expect to see GUI apps with keyboard shortcuts so that there is a smooth learning curve 06:14 < 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 06:15 < wumpus> cjd: you'd expect so 06:15 < 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 06:17 < 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. 06:18 < cjd> I suspect the same methodology works for evaluating editors, distros and blockchains 06:21 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has quit [Remote host closed the connection] 06:29 -!- cluelessperson [~cluelessp@unaffiliated/cluelessperson] has joined #bitcoin-core-dev 06:55 -!- mistergo1d [~mistergol@77.243.25.197] has quit [Read error: Connection reset by peer] 06:55 -!- mistergold [~mistergol@77.243.27.82] has joined #bitcoin-core-dev 07:03 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-hcpbevsguiclmnag] has joined #bitcoin-core-dev 07:03 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e756eca9e8bf...f5a70d146259 07:03 < bitcoin-git> bitcoin/master 3019ba2 Ben Carman: Making supported operating systems more clear 07:03 < bitcoin-git> bitcoin/master f5a70d1 Wladimir J. van der Laan: Merge #14974: doc: Removing redundant line: "Windows XP not supported"... 07:03 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-hcpbevsguiclmnag] has left #bitcoin-core-dev [] 07:04 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ejtymwploskrjjuq] has joined #bitcoin-core-dev 07:04 < 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 07:04 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ejtymwploskrjjuq] has left #bitcoin-core-dev [] 07:07 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 07:17 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection] 07:19 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 07:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 07:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 07:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 08:03 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 256 seconds] 08:04 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 08:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds] 08:31 -!- rex4539 [~rex4539@hotelmir.static.otenet.gr] has joined #bitcoin-core-dev 08:33 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 08:33 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 08:35 -!- mistergold [~mistergol@77.243.27.82] has quit [Read error: Connection reset by peer] 08:35 -!- tryphe_000 [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 08:36 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 268 seconds] 08:38 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 245 seconds] 08:42 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 08:49 -!- dviola [~diego@186.222.76.57] has joined #bitcoin-core-dev 08:49 -!- dviola [~diego@186.222.76.57] has quit [Changing host] 08:49 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 08:57 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has quit [Read error: Connection reset by peer] 08:58 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has joined #bitcoin-core-dev 09:04 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-dexvbveveudwesvm] has joined #bitcoin-core-dev 09:18 -!- cobega [1fcc966a@gateway/web/freenode/ip.31.204.150.106] has joined #bitcoin-core-dev 09:21 < 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). 09:24 < achow101> cobega: did you do listunspent with the watch_only option set to true? 09:25 < achow101> you can use importaddress with rescan false, then rescanblockchain from the block height that that address has its first transaction. 09:29 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 240 seconds] 09:29 < cobega> moment, will try first listunspent with watch only set to true. 09:31 < cobega> how to activate watch only option (https://bitcoin.org/en/developer-reference#listunspent)? 09:32 < cobega> It's a bit strange, using ./bitcoin-cli listreceivedbyaddress 1 true true I can see the multisig address 09:45 < gwillen> cobega: yeah the thing you want is to use importaddress with rescan false 09:45 < gwillen> and then use rescanblockchain, and tell it what height to start scanning from, i.e. the height you first sent to that address 09:45 < gwillen> then the rescan will be very fast 09:45 < gwillen> or if you import before sending you don't need to rescan at all 09:46 < gwillen> I can confirm the import was required when I tried to do this, so I assume it is necessary 09:46 < achow101> oh whoops. listunspent doesn't have a watchonly option 09:46 < gwillen> I don't know why addmultisigaddress doesn't import 09:47 < gwillen> or what distinguishes it from createmultisig given that it doesn't 09:49 < cobega> what about https://bitcoin.org/en/developer-reference#importmulti ? 09:49 < achow101> cobega: you can use importmulti too with a timestamp of the block height you first used the address 09:51 < achow101> gwillen: addmultisigaddress adds the redeemScript to your wallet 09:51 < achow101> so you can sign a transaction that spends the multisig without having funds sent to it showing up in your balance 09:55 -!- brianhoffman_ [~brianhoff@pool-72-83-155-130.washdc.fios.verizon.net] has joined #bitcoin-core-dev 09:55 -!- brianhoffman [~brianhoff@pool-72-83-155-130.washdc.fios.verizon.net] has quit [Ping timeout: 272 seconds] 09:55 -!- brianhoffman_ is now known as brianhoffman 10:00 < gwillen> achow101: ahh so it makes it solvable 10:00 < gwillen> that makes sense, thanks 10:01 < sipa> gwillen: createmultisig is the utility non-wallet version of the RapC, to just let you compute the address 10:01 < sipa> addmultisigaddress is the wallet importing version 10:04 < 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? 10:11 -!- ovovo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 245 seconds] 10:17 < achow101> cobega: the timestamp indicates from when to start rescanning. it basically combines importaddress and rescanblockchain 10:20 < cobega> Understand :) But should I set rescan to true or false when using the timestamp parameter? 10:21 < achow101> set it to true 10:26 -!- fabianfabian [~fabianfab@D9656CCE.cm-27.dynamic.ziggo.nl] has joined #bitcoin-core-dev 10:29 < 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? 10:31 < achow101> no, it's {"scriptPubKey":{"address":"..."}} 10:35 < cobega> using it like ./bitcoin-cli importmulti '[{"scriptPubKey":{"address":"2MtxopLjtoJbfxJqNptZR17RzPGSTSTmqZsy"},"timestamp":1546218000}]' it says "invalid address" 10:35 < achow101> is your node in testnet mode? 10:35 < achow101> that's a testnet address 10:36 < cobega> yes it is 10:36 < cobega> ./bitcoin-cli getnewaddress 2Mto6bcnFMdZ7M6E76Sd3PXYJzZxF9dupzG 10:36 < cobega> Using testnet while development of application. 10:38 < arubi> the 2Mtxop one is invalid 10:43 < cobega> shame on me. works as expected :) 10:43 < arubi> :) 10:47 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 11:07 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 11:08 -!- rex4539 [~rex4539@hotelmir.static.otenet.gr] has quit [Quit: rex4539] 11:19 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 11:20 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection] 11:22 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 11:24 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection] 11:25 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev 11:30 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Quit: Leaving] 11:37 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Remote host closed the connection] 11:46 < gwillen> sipa: except that addmultisigaddress only sort of imports 11:46 < gwillen> it makes it solveable but it doesn't make it "watchonly", i.e. look for utxos it owns 11:48 < sipa> gwillen: yes, you need importaddress for that 11:49 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.3] 11:49 < sipa> addmuktisigaddress predates support for watchonly addresses 11:49 < sipa> it uzed to only work in case you had *all* the private keys for a multisig address in your wallet, at all 11:50 < sipa> (yes, that makes no sense) 11:55 -!- rex4539 [~rex4539@hotelmir.static.otenet.gr] has joined #bitcoin-core-dev 11:59 -!- Krellan [~Krellan@c-174-62-65-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 12:02 < 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"} 12:04 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 12:10 -!- Krellan [~Krellan@c-174-62-65-144.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 12:10 < fabianfabian> I think your first param is an object but should be an array 12:12 < fabianfabian> so just enclose it in [] 12:13 < 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/ 12:22 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has quit [Read error: Connection reset by peer] 12:22 -!- CodeBlue1776 [~CodeBlue1@107-215-134-60.lightspeed.cicril.sbcglobal.net] has joined #bitcoin-core-dev 12:26 < gwillen> there's a stray close brace at the end of params there 12:26 < gwillen> not sure if it's doing anything 12:26 < gwillen> wait, nevermind, that's the outer braces, sorry 12:28 < cobega> your code from 21:13 is running. 12:36 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 256 seconds] 12:50 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 13:05 -!- cobega [1fcc966a@gateway/web/freenode/ip.31.204.150.106] has quit [Quit: Page closed] 13:14 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 13:25 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 13:41 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has joined #bitcoin-core-dev 13:42 -!- promag [~promag@bl22-246-44.dsl.telepac.pt] has quit [Remote host closed the connection] 13:51 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-dexvbveveudwesvm] has quit [Quit: Connection closed for inactivity] 14:11 -!- Krellan [~Krellan@2601:642:100:30a7:1950:e8d6:a35e:d0d8] has joined #bitcoin-core-dev 14:12 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has quit [Quit: Lost terminal] 14:13 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev 14:16 -!- Krellan [~Krellan@2601:642:100:30a7:1950:e8d6:a35e:d0d8] has quit [Ping timeout: 260 seconds] 14:18 -!- rex4539 [~rex4539@hotelmir.static.otenet.gr] has quit [Quit: rex4539] 14:34 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 14:38 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 14:48 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 14:52 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ceaxwcwqskhcohyi] has joined #bitcoin-core-dev 14:52 < 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 14:52 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ceaxwcwqskhcohyi] has left #bitcoin-core-dev [] 15:08 -!- tryphe_000 is now known as tryphe 15:25 -!- murrayn [~murrayn@unaffiliated/murrayn] has joined #bitcoin-core-dev 15:36 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 15:42 -!- brianhoffman_ [~brianhoff@pool-72-83-155-130.washdc.fios.verizon.net] has joined #bitcoin-core-dev 15:45 -!- brianhoffman [~brianhoff@pool-72-83-155-130.washdc.fios.verizon.net] has quit [Ping timeout: 250 seconds] 15:45 -!- brianhoffman_ is now known as brianhoffman 16:12 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 17:00 -!- harrymm [~harrymm@69.161.195.103] has quit [Ping timeout: 240 seconds] 17:35 -!- MrPaz [~MrPaz@c-71-57-73-68.hsd1.il.comcast.net] has joined #bitcoin-core-dev 18:08 -!- MrPaz [~MrPaz@c-71-57-73-68.hsd1.il.comcast.net] has quit [Quit: Leaving] 18:31 -!- saks [~saks@178-189-174-165.adsl.highway.telekom.at] has joined #bitcoin-core-dev 18:38 -!- bytting [~corebob@2a02:fe0:c130:6160:a966:37db:35e2:27d0] has joined #bitcoin-core-dev 19:00 -!- dviola [~diego@unaffiliated/dviola] has quit [Quit: WeeChat 2.3] 19:10 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection] 19:10 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev 19:29 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 19:30 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 19:35 -!- asoltys [~adam@115.96.198.104.bc.googleusercontent.com] has quit [Remote host closed the connection] 19:42 -!- asoltys [~adam@115.96.198.104.bc.googleusercontent.com] has joined #bitcoin-core-dev 21:10 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-pkjxejolukclaxru] has joined #bitcoin-core-dev 21:10 < bitcoin-git> [bitcoin] bitcoinVBR opened pull request #15070: V0.02 (master...v0.02) https://github.com/bitcoin/bitcoin/pull/15070 21:10 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-pkjxejolukclaxru] has left #bitcoin-core-dev [] 21:16 -!- bytting [~corebob@2a02:fe0:c130:6160:a966:37db:35e2:27d0] has quit [Remote host closed the connection] 21:19 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ydiuxkzxvzsryrwd] has joined #bitcoin-core-dev 21:19 < bitcoin-git> [bitcoin] fanquake closed pull request #15070: V0.02 (master...v0.02) https://github.com/bitcoin/bitcoin/pull/15070 21:19 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ydiuxkzxvzsryrwd] has left #bitcoin-core-dev [] 21:24 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 22:12 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-xvqgkmppfolfghwl] has joined #bitcoin-core-dev 22:12 < bitcoin-git> [bitcoin] seth586 opened pull request #15071: Docs: add gmake syntax to autoconf script (master...patch-1) https://github.com/bitcoin/bitcoin/pull/15071 22:12 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-xvqgkmppfolfghwl] has left #bitcoin-core-dev [] 22:32 < fanquake> achow101 How difficult is it to rebase your hww branch onto current master? Are the only changes essentially the required (some of which are now merged) PRs? 22:33 < achow101> fanquake: it's pretty easy 22:33 < achow101> so long as #14491 is mergeable with master, it should be rebaseable onto master. hww is just all of the prs merged 22:33 < gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub 22:34 < fanquake> achow101 cool, just wanted to make sure the PRs were the same, and no other changes. I'll look at it this arvo, cheers. 22:35 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 22:46 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 23:20 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 268 seconds] 23:31 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 23:32 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 23:55 -!- rex4539 [~rex4539@hotelmir.static.otenet.gr] has joined #bitcoin-core-dev --- Log closed Tue Jan 01 00:00:08 2019