--- Log opened Thu Oct 18 00:00:40 2018 00:01 < promag> yes https://github.com/bitcoin/bitcoin/pull/14291/files#diff-e802a36c28b0140bab62cb5366199656R38 00:01 < wumpus> ohh that's neat 00:02 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev 00:02 < wumpus> (it's somewhat hard to review changes if you don't add commits but squash them) 00:04 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has joined #bitcoin-core-dev 00:04 < wumpus> the endianness thing is really a gothcha 00:05 < promag> the last change was https://github.com/bitcoin/bitcoin/commit/743a3a9b20768519a11f54834d27fd7585a0670a <- I have to remove that #include though.. 00:05 < wumpus> thank you 00:05 < promag> regarding endianness, I don't know what to do there 00:06 < wumpus> add a comment as suggested 00:06 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 00:06 < wumpus> most people reading the code will be unaware of this fact, which is the best reason to add a useful comment 00:07 < promag> wumpus: ok, going to take kids to school, I'll update when I get back 00:07 < wumpus> thanks 00:07 < wumpus> this is... telling, I don't suppose anyone ever used bitcoin on a big endian system 00:07 < wumpus> at least not with wallet 00:07 < wumpus> (and tried to copy the files from another system) 00:08 < wumpus> please be really sure that this is really the case 00:09 < wumpus> or does BDB *produce* native endian but *accept* either? 00:09 < wumpus> in that case the code needs to check for both endiannesses 00:09 < sipa> wumpus: that's my theory 00:09 < sipa> it writes in native, but converts when the file is the other endianness 00:10 < wumpus> right, that'd make some sense 00:11 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 00:11 < wumpus> have certainly seen that before in file formats 00:13 < promag> wumpus: nothing would go wrong anyway, it would give no wallets 00:14 -!- jarthur [~jarthur@2605:6000:1019:41ab:3ce8:37ee:b8f0:f5e5] has joined #bitcoin-core-dev 00:14 < wumpus> promag: I just want to be careful here and be sure of what we're doing 00:14 < promag> wumpus: I can't virtualize different endianness right? 00:15 < wumpus> sure you can, in qemu, though I'd expect the number of linux distros that even run in a big endian host is low these days 00:18 -!- jarthur [~jarthur@2605:6000:1019:41ab:3ce8:37ee:b8f0:f5e5] has quit [Ping timeout: 250 seconds] 00:19 < promag> ty, bbl 00:19 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has quit [Ping timeout: 260 seconds] 00:20 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 00:22 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev 00:24 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 00:24 < wumpus> promag: anyhow, no matter what the assumption is going to be, make sure it's documented in a comment 00:25 < wumpus> it's IMO perfectly acceptable if you don't want to actually check this on a BE host 00:25 < sipa> ... what actual BE systems exist these days? 00:25 < wumpus> but if you make assumptions like that, anywhere, add a comment 00:26 < sipa> i think our primary interest in being BE compatible is that it forces a degree of endian-neutrality on the code 00:26 < sipa> not so much supporting actual systems 00:26 < wumpus> yes, agree 00:28 < sipa> Some current big-endian architectures include the IBM z/Architecture, Freescale ColdFire (which is Motorola 68000 series-based), Xilinx MicroBlaze, Atmel AVR32. 00:28 < sipa> -- https://en.wikipedia.org/wiki/Endianness#Current_architectures 00:28 < wumpus> being endian independent with regard to data files is good practice, no matter if there are any 00:29 < gmaxwell> wumpus: it works fine on BE, I just never tried moving iles over. 00:29 < gmaxwell> sipa: PPC is biendian now. 00:29 < wumpus> yes IBM power can run in BE as well (https://github.com/bitcoin/bitcoin/pull/14066 has some discussion in that regard whether we should ship executables for that case) 00:30 < gmaxwell> and yes, the main advantage of supporting BE is that testing there will reveal other issues in the code, including issues that are real but harder to observe on other systems. 00:30 < wumpus> gmaxwell: I'd be surprised if this was not possible and we would have never noticed; I vaguely remember trying at the time, but not sure 00:30 < gmaxwell> Though BE power is both real and an actually interesting host to run bitcoin on. 00:31 < gmaxwell> wumpus: I kinda thought I tried that too... or at least I know I moved a whole .bitcoin over, but I might have not tried with the wallet. 00:31 < wumpus> what I did was copy over a data directory but I'm not sure if it had a wallet, might have been only block files etc 00:31 < wumpus> right. 00:32 < sipa> would be interesting to test with #14479 to see if the fee estimates files are compatible 00:32 < gribble> https://github.com/bitcoin/bitcoin/issues/14479 | serialization: Dont invoke undefined behaviour when doing type punning by practicalswift · Pull Request #14479 · bitcoin/bitcoin · GitHub 00:32 < gmaxwell> sipa: they won't be thats obvious. 00:32 < gmaxwell> ( and I pointed that out on the PR ) 00:33 < sipa> gmaxwell: from what i've read since, is that most BE systems actually store IEEE floats in byteswapped form 00:33 < sipa> as IEEE 754 only specifies the bit encoding 00:33 < sipa> not how to store the bytes 00:34 < sipa> but at least historically there are various ways, and not much consistency; including one platform that stores 64 bits in 2 LE 32-bit integers, but the most significant first 00:36 < wumpus> yes, from what I know too, most systems use the same endian for floats and integers, as this makes the implementation simpler, and also allows doing some tricks like fast radix sort of floats efficiently 00:36 -!- jarthur [~jarthur@2605:6000:1019:41ab:9534:a0a5:4f3e:eeb] has joined #bitcoin-core-dev 00:36 < wumpus> of course making that assumption without checking it is a bad idea 00:37 < sipa> but for example Boost.Endian intentionally does not support encoding floats because there is no guaranteed consistency 00:37 < sipa> An attempt was made to support four-byte floats and eight-byte doubles, limited to IEEE 754 (also know as ISO/IEC/IEEE 60559) floating point and further limited to systems where floating point endianness does not differ from integer endianness. 00:37 < wumpus> I think it would be perfectly OK to just add a check to the build system 00:38 < wumpus> and fail if the architecture doesn't match the current assumption 00:38 < gmaxwell> sipa: power64be has BE floats (and in fact the BE/LE autoswitch is implemented by footwork in the address decoder, values still get stored in memory as BE, but it's hidden (according to the ISA manual)) 00:38 < gmaxwell> We should probably just avoid serializing floats at all. 00:38 < sipa> yes, absolutely 00:39 < wumpus> we don't have to handle everything, certainly not every possible historical architecture, but do need to be explicit about it 00:39 < gmaxwell> There is no particular need to, this decay thing in fact just uses the float to store one of three values. 00:39 < sipa> afaik indeed; i haven't checked in detail 00:39 < gmaxwell> (in general floats, like strings, are a source of fun bugs in many cases.) 00:39 < sipa> so we could just hardcode the 8-byte serializations, and encode those 00:39 < gmaxwell> (e.g. when A != A due to !@#! nan and your code infinite loops) 00:39 < sipa> and switch when decode 00:39 < wumpus> yes, like using signalling NaNs in binary protocols to crash MMO servers :-) 00:40 < gmaxwell> or that 00:40 < gmaxwell> or float code that dorks with the rounding rule registers and then breaks OTHER float code. 00:40 < wumpus> yes, indeed 00:41 < gmaxwell> I don't whine about it in our codebase because we've mostly limited it to feerates (and sometimes time things) where it is less critical. 00:41 -!- jarthur [~jarthur@2605:6000:1019:41ab:9534:a0a5:4f3e:eeb] has quit [Ping timeout: 260 seconds] 00:41 < gmaxwell> but in general our usage of float should be pretty sparing. 00:41 < wumpus> I'm still scared about using floats for monetary values at all, but yes 00:43 < wumpus> in fee estimation I'd grant that the whole thing is so *heuristic* that the usual things that make floats unsuitable don't count, it needs to be robust against many things, a very small precision issue won't break it 00:45 < gmaxwell> (or someone compiles with -Ofast and then all your careful float code behaves different because of the compiler treating them like reals) 00:45 < wumpus> with regard to the file format, we could certainly have prevented encoding the values directly as float 00:45 < sipa> it seems that before fee_estimates.dat, we never used the float serialization code at all 00:45 < gmaxwell> wumpus: If we didn't use floats for some of that stuff, we'd still run into issues with precision problems in whatever fixed point math we'd have-- at least that isn't why I didn't go through and rip them out myself. :P 00:45 < wumpus> they're limited range so quantizing it to 64 bits would likely have been ok 00:47 < gmaxwell> Though I do worry about eventually ending up with an infinite loop or undefined behavior (like indexing an array with a float) due to NaNs. 00:47 < wumpus> aanyhow, I think not worth breaking backwards compatibily for this 00:47 < wumpus> gmaxwell: it's true, but at least it'd be deterministic / arch independent so easier to be confident about... but yeah 00:47 < gmaxwell> no, though we could fix it without being incompatible. E.g. change to coding values with the LE bytes as meaning the same old thing. 00:48 < gmaxwell> I don't mind breaking compat on BE. 00:48 < gmaxwell> presumably fee estimates format is gonna change in not enormous amounts of time anyways. 00:48 < gmaxwell> though we should probably eliminate any generic float serialization before some other goof is added. :) 00:48 < wumpus> I think that's good, it's something to write down for the next time the format has to change anyway 00:49 < sipa> gmaxwell: but currently the code is compatible for systems that store both floats and ints in the same endianness 00:49 < sipa> so we can just replace it with byte matches, and it shouldn't break anything 00:50 < wumpus> gmaxwell: yes, ripping out the float serialization code would be neat, I toyed with the idea of moving it to a separate header with a big "don't use this for new code" warning 00:50 < sipa> it doesn't sound like much work at all 00:51 < wumpus> at the time it was more work than I expected 00:51 < sipa> when was fee_estimates.dat introduced? 00:51 < sipa> 0.12 ish? 00:52 < wumpus> some of the things handling float datat types, weren't that easy to isolate out, at least not if including was to be optional 00:52 < wumpus> but I don't remember specifics, I'm not the best versed in C++ template magic 00:52 < sipa> ah, yes 00:52 < sipa> you'd need forward declares and stuff 00:52 < wumpus> right 00:55 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-litwfaoklxegclln] has joined #bitcoin-core-dev 00:55 -!- Krellan [~Krellan@2601:640:4000:9258:96b:c6b4:7ae:b201] has quit [Read error: Connection reset by peer] 00:55 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/816fab9ccae5...041224a75c16 00:55 < bitcoin-git> bitcoin/master d562027 Sjors Provoost: [doc] getblocktemplate: use SegWit in example 00:55 < bitcoin-git> bitcoin/master 041224a Wladimir J. van der Laan: Merge #14472: [doc] getblocktemplate: use SegWit in example... 00:55 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-litwfaoklxegclln] has left #bitcoin-core-dev [] 00:56 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-nygkhgndyqkzensx] has joined #bitcoin-core-dev 00:56 < bitcoin-git> [bitcoin] laanwj closed pull request #14472: [doc] getblocktemplate: use SegWit in example (master...2018/10/doc-getblocktemplate-segwit) https://github.com/bitcoin/bitcoin/pull/14472 00:56 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-nygkhgndyqkzensx] has left #bitcoin-core-dev [] 00:56 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has joined #bitcoin-core-dev 00:56 < wumpus> sipa: acc. to release notes, fee_estimates.dat was introduced in 0.10 00:57 < sipa> ah 01:02 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has quit [Ping timeout: 250 seconds] 01:02 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev 01:07 < karelb> thinking out loud- yesterday we talked with colleague how we hate that JSON RPC returns BTC values as floats. (at various points.) Do you think it would be a good idea to be able to somehow switch this with some option? either option for whole bitcoind, or just another parameter for bitcoin-cli 01:08 < wumpus> I tried that once... 01:08 < karelb> there are workarounds around that, but it's still annoying 01:08 < sipa> karelb: you have no idea how often this comes up :) 01:08 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-unqpguonxqbqiwrw] has joined #bitcoin-core-dev 01:08 < bitcoin-git> [bitcoin] Sjors opened pull request #14509: [doc] getblocktemplate: use SegWit in example (0.17...2018/10/backport-doc-getblocktemplate-segwit) https://github.com/bitcoin/bitcoin/pull/14509 01:08 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-unqpguonxqbqiwrw] has left #bitcoin-core-dev [] 01:08 < karelb> wumpus: ahh, with what result? 01:08 < karelb> sipa hahaha ok 01:08 < wumpus> karelb: people didn't really care ,even the ones that brought it up in the first place 01:08 < sipa> it always turns into a bikeshedding over redesigning the entire RPC interface 01:08 < wumpus> yess and that 01:08 < karelb> .. oh 01:09 < wumpus> we already *accept* strings for amounts, btw 01:09 < sipa> also (and i'm aware this is somewhat pedantic), JSON doesn't having a concept of floating point 01:09 < sipa> it has numbers 01:09 < wumpus> but this is just not worth changing at this point, I think... 01:10 < wumpus> everyone who cared back in the day will have their own specific JSON parser for interfacing to bitcoind now 01:10 < wumpus> it's just, solved at the client side 01:10 < wumpus> and sipa is right too—for everyone's sanity, please just leave this be 01:10 < karelb> :D 01:12 < karelb> ok thx for info. we are not alone in thinking that it's annoying though. good to know :) 01:12 < wumpus> there are literally hundreds of actual user issues reported that need to be solved 01:14 < wumpus> in the end, as the bikeshedding and different 'tastes' suggest, changes resulting from it will just end up making it more difficult for users, breaking the interface, to satisfy some idea of interface purity 01:17 < wumpus> did we scare away this person with the sheer number of comments on such a small patch #14125 01:17 < gribble> https://github.com/bitcoin/bitcoin/issues/14125 | Add testcase to simulate bitcoin schema in leveldb by MapleLaker · Pull Request #14125 · bitcoin/bitcoin · GitHub 01:17 < kallewoof> TBH, using floats is insane. *shrug* 01:17 < wumpus> the world, is insane 01:17 < sipa> karelb: also, inside bitcoin core there no conversion of amounts to floats ever (except feerates), even to convert to JSON 01:17 < kallewoof> wumpus: we could make it less so or contribute to its insanity lol 01:17 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 01:18 < wumpus> kallewoof: what if every initiative tom ake it more sane actually makes it more insane 01:18 < kallewoof> It's been raised countless times though. I still have hope that one day we will be saying sat/byte rather than btc/kb (*weeps*) 01:18 < kallewoof> Yeah... there's that. 01:18 < wumpus> omg .. please 01:18 < wumpus> STOP 01:19 < sipa> saying... sure :) 01:19 < kallewoof> I apparently stepped on something. My apologies, I'll shut up now. 01:19 < karelb> (why solve hard issues when you can bikeshed interfaces :)) ok got you 01:20 < karelb> I will add this to "weird stuff Bitcoin does for backwards compatibility reasons", just next to the endian switching 01:21 < sipa> bitcoin uses little endian everywhere, except when presenting things for human consumption :) 01:21 < sipa> (and inside sha256 which you should treat as a black box that converts bytes to bytes) 01:23 < wumpus> sipa: I think that's what makes him right in that it is a similar thing; just the interface 01:24 < sipa> fair 01:24 < wumpus> over the years, people have adopted to this convention, even though the convention itself might or might not make sense has become irrelevant 01:25 < sipa> i'm just suffering from stockholm syndrome, trying to defend the original reasoning behind the convention which is now completely irrelevant :) 01:25 < wumpus> indeed :) 01:26 < karelb> well that's what I think about as "backwards compatibility" :) 01:27 < wumpus> though I mean, it might still be interesting to know how something got a certain way for historical reasons 01:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 244 seconds] 01:27 < wumpus> yes 01:30 < sipa> meshcollider: in the P2WSH-multisig test in 14454 you're only importing one of the two private keys 01:30 < sipa> if i change it to have both, i expect the result to become ismine:true, but it doesn't 01:30 < meshcollider> sipa: the ismine logic never treats a multisig as mine 01:31 < meshcollider> even if we have all the keys 01:31 -!- bitconner [~conner@c-73-170-56-77.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 01:31 < meshcollider> thats unrelated to this PR, maybe a fault there though 01:31 < sipa> meshcollider: yes it does? 01:31 < sipa> if you have all the private keys 01:32 < sipa> not bare multisig, though 01:32 < meshcollider> Oh I must be thinking of bare multisig 01:32 < sipa> but P2WSH-multisig, i don't see why not 01:32 < meshcollider> hmm 01:33 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has quit [Ping timeout: 250 seconds] 01:34 < sipa> (i wouldn't care at all if the functionality was different - it all makes equally little sense - but i want to understand why the behaviour doesn't match what i think the code does) 01:35 -!- bitconner [~conner@c-73-170-56-77.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 01:37 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-byavryuqxfrcmwrq] has joined #bitcoin-core-dev 01:37 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/041224a75c16...9c5f0d542d1d 01:37 < bitcoin-git> bitcoin/master 86eb3b3 Chun Kuan Lee: utils: Add fsbridge fstream function wrapper 01:37 < bitcoin-git> bitcoin/master a554cc9 Chun Kuan Lee: Move boost/std fstream to fsbridge 01:37 < bitcoin-git> bitcoin/master f86a571 Chun Kuan Lee: tests: Add test case for std::ios_base::ate 01:37 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-byavryuqxfrcmwrq] has left #bitcoin-core-dev [] 01:38 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-awntnogxzngtjbof] has joined #bitcoin-core-dev 01:38 < bitcoin-git> [bitcoin] laanwj closed pull request #13878: utils: Add fstream wrapper to allow to pass unicode filename on Windows (master...iofstream-custom) https://github.com/bitcoin/bitcoin/pull/13878 01:38 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-awntnogxzngtjbof] has left #bitcoin-core-dev [] 01:40 < meshcollider> indeed that's confusing 01:43 * sipa needs sleep 01:46 < wumpus> goodnight sipa 01:49 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:50 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 01:59 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-hwqiudjseknnnsgl] has joined #bitcoin-core-dev 01:59 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/9c5f0d542d1d...d98777f302e1 01:59 < bitcoin-git> bitcoin/master ea3009e Pierre Rochard: wallet: Add walletdir arg unit tests 01:59 < bitcoin-git> bitcoin/master 2d47163 Pierre Rochard: wallet: Remove trailing separators from -walletdir arg 01:59 < bitcoin-git> bitcoin/master d98777f Wladimir J. van der Laan: Merge #14146: wallet: Remove trailing separators from -walletdir arg... 01:59 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-hwqiudjseknnnsgl] has left #bitcoin-core-dev [] 02:00 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-xvbznmfrjaizbmst] has joined #bitcoin-core-dev 02:00 < bitcoin-git> [bitcoin] laanwj closed pull request #14146: wallet: Remove trailing separators from -walletdir arg (master...wallet-env-bug) https://github.com/bitcoin/bitcoin/pull/14146 02:00 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-xvbznmfrjaizbmst] has left #bitcoin-core-dev [] 02:04 -!- shesek [~shesek@bzq-84-110-60-238.red.bezeqint.net] has joined #bitcoin-core-dev 02:04 -!- shesek [~shesek@bzq-84-110-60-238.red.bezeqint.net] has quit [Changing host] 02:04 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 02:06 < promag> wumpus: from https://docs.oracle.com/cd/E17275_01/html/programmer_reference/magic.txt the magic is the same for Btree, or am I wrong? 02:08 < promag> so I should just replace memcmp with uint32_t != uint32_t? 02:09 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev 02:29 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-gixzboefhcoegqak] has joined #bitcoin-core-dev 02:29 < bitcoin-git> [bitcoin] practicalswift opened pull request #14510: Avoid triggering undefined behaviour in base_uint::bits() (master...1<<31) https://github.com/bitcoin/bitcoin/pull/14510 02:29 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-gixzboefhcoegqak] has left #bitcoin-core-dev [] 02:37 -!- jarthur [~jarthur@2605:6000:1019:41ab:9534:a0a5:4f3e:eeb] has joined #bitcoin-core-dev 02:42 -!- jarthur [~jarthur@2605:6000:1019:41ab:9534:a0a5:4f3e:eeb] has quit [Ping timeout: 264 seconds] 02:42 < promag> I think https://github.com/bitcoin/bitcoin/pull/14291/commits/21c475119949f0fde0a478e4f3ad301c5be0c497 would work in both endianness 02:46 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 02:58 < wumpus> so *I think* you'd want to check for the magic in both endian-nesses, whether you do that by memcmp or uint32_t != is equivalent 02:59 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has quit [Ping timeout: 250 seconds] 03:03 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has quit [Read error: Connection reset by peer] 03:03 < wumpus> but if you don't, and only compare against the native one, that's a valid choice but you need to document it with a comment, because wallets copied from a system with another endian will not show up 03:03 < wumpus> I don't think always comparing against the LE value even on BE-native systems makes sense 03:03 < wumpus> as it means they won't see their native wallets 03:03 < wumpus> which is worse than not seeing ported ones 03:06 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has joined #bitcoin-core-dev 03:10 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Read error: Connection reset by peer] 03:12 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev 03:26 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-vzyihxulknlejddr] has joined #bitcoin-core-dev 03:26 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d98777f302e1...32c5f188d4fd 03:26 < bitcoin-git> bitcoin/master b0510d7 Hennadii Stepanov: Set C locale for amountWidget... 03:26 < bitcoin-git> bitcoin/master 32c5f18 Wladimir J. van der Laan: Merge #14177: qt: Set C locale for amountWidget... 03:26 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-vzyihxulknlejddr] has left #bitcoin-core-dev [] 03:27 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-kvcfewlacuhoiddl] has joined #bitcoin-core-dev 03:27 < bitcoin-git> [bitcoin] laanwj closed pull request #14177: qt: Set C locale for amountWidget (master...fix-amount-locale) https://github.com/bitcoin/bitcoin/pull/14177 03:27 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-kvcfewlacuhoiddl] has left #bitcoin-core-dev [] 03:30 < luke-jr> ugh, bdb isn't endian-independent? -.- 03:31 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-poocztslwyiawlsd] has joined #bitcoin-core-dev 03:31 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/32c5f188d4fd...fe23553edd84 03:31 < bitcoin-git> bitcoin/master 3045704 Hennadii Stepanov: Add "Blocksdir" to Debug window... 03:31 < bitcoin-git> bitcoin/master 2ab9140 Hennadii Stepanov: Add tooltips for both datadir and blocksdir 03:31 < bitcoin-git> bitcoin/master fe23553 Wladimir J. van der Laan: Merge #14374: qt: Add "Blocksdir" to Debug window... 03:31 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-poocztslwyiawlsd] has left #bitcoin-core-dev [] 03:32 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-zpmltzkjjxzpkmnl] has joined #bitcoin-core-dev 03:32 < bitcoin-git> [bitcoin] laanwj closed pull request #14374: qt: Add "Blocksdir" to Debug window (master...20181002-debugwindow-blocksdir) https://github.com/bitcoin/bitcoin/pull/14374 03:32 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-zpmltzkjjxzpkmnl] has left #bitcoin-core-dev [] 03:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:37 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has quit [Ping timeout: 250 seconds] 03:38 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has joined #bitcoin-core-dev 03:39 -!- ken2812221 [~ken281222@2001-b011-4010-14fa-5940-50b4-e455-30f9.dynamic-ip6.hinet.net] has quit [Client Quit] 03:46 -!- jarthur [~jarthur@2605:6000:1019:41ab:3ce8:37ee:b8f0:f5e5] has joined #bitcoin-core-dev 03:51 -!- jarthur [~jarthur@2605:6000:1019:41ab:3ce8:37ee:b8f0:f5e5] has quit [Ping timeout: 250 seconds] 03:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 03:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds] 04:02 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-jzccqfjxdkeludqp] has joined #bitcoin-core-dev 04:02 < bitcoin-git> [bitcoin] ken2812221 closed pull request #13887: build: Compile leveldb with unicode enable on Windows (master...leveldb-windows-unicode) https://github.com/bitcoin/bitcoin/pull/13887 04:02 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-jzccqfjxdkeludqp] has left #bitcoin-core-dev [] 04:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 04:05 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 04:06 -!- hebasto [~hebasto@95.164.65.194] has quit [Read error: Connection reset by peer] 04:06 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 04:14 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Read error: Connection reset by peer] 04:14 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev 04:17 < promag> ken2812221: are you aware of https://medium.com/@leandrw/speeding-up-wsl-i-o-up-than-5x-fast-saving-a-lot-of-battery-life-cpu-usage-c3537dd03c74 ? 04:18 < wumpus> luke-jr: we're not sure; what is clear is that bdb databases can have either endian, and are created with host endian, what we *don't* know is whether they are interchangeable (they probably are) 04:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 04:25 -!- ken2812221 [~ken281222@110.50.135.178] has joined #bitcoin-core-dev 04:37 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 04:38 -!- jarthur [~jarthur@2605:6000:1019:41ab:9534:a0a5:4f3e:eeb] has joined #bitcoin-core-dev 04:43 -!- jarthur [~jarthur@2605:6000:1019:41ab:9534:a0a5:4f3e:eeb] has quit [Ping timeout: 276 seconds] 04:58 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 05:08 < promag> wumpus: see https://github.com/bitcoin/bitcoin/pull/14291/commits/b791ef12c3605c185432e391e1571853b07a7441 05:12 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has quit [Read error: Connection reset by peer] 05:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 05:17 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has joined #bitcoin-core-dev 05:21 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-mnbsvpnjhxlvmskb] has joined #bitcoin-core-dev 05:21 < bitcoin-git> [bitcoin] merland opened pull request #14511: Increase storage requirement from 100GB to 200GB (master...patch-1) https://github.com/bitcoin/bitcoin/pull/14511 05:21 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-mnbsvpnjhxlvmskb] has left #bitcoin-core-dev [] 05:30 -!- bitconner [~conner@c-73-170-56-77.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 05:34 -!- bitconner [~conner@c-73-170-56-77.hsd1.ca.comcast.net] has quit [Ping timeout: 250 seconds] 05:36 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 05:36 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 05:41 -!- klot [~klot@188.113.35.204] has joined #bitcoin-core-dev 05:42 -!- klot [~klot@188.113.35.204] has quit [Remote host closed the connection] 05:42 -!- klot [~klot@188.113.35.204] has joined #bitcoin-core-dev 05:43 -!- klot [~klot@188.113.35.204] has quit [Remote host closed the connection] 05:44 -!- klot [~klot@188.113.35.204] has joined #bitcoin-core-dev 05:45 -!- klot [~klot@188.113.35.204] has quit [Remote host closed the connection] 05:45 -!- klot [~klot@188.113.35.204] has joined #bitcoin-core-dev 05:51 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-xcwonjhblizkncbs] has joined #bitcoin-core-dev 05:51 < bitcoin-git> [bitcoin] merland opened pull request #14512: Textual improvements (master...merland-patch-2) https://github.com/bitcoin/bitcoin/pull/14512 05:51 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-xcwonjhblizkncbs] has left #bitcoin-core-dev [] 06:02 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 06:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 06:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:07 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Read error: Connection reset by peer] 06:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 06:10 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 06:17 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 06:23 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 06:38 -!- promag [~promag@83.223.251.173] has joined #bitcoin-core-dev 06:39 -!- jarthur [~jarthur@2605:6000:1019:41ab:9534:a0a5:4f3e:eeb] has joined #bitcoin-core-dev 06:44 -!- jarthur [~jarthur@2605:6000:1019:41ab:9534:a0a5:4f3e:eeb] has quit [Ping timeout: 250 seconds] 06:49 -!- promag [~promag@83.223.251.173] has quit [Remote host closed the connection] 06:56 < wumpus> promag: LGTM 07:12 -!- BladeZero [~bladezero@207.244.82.194] has joined #bitcoin-core-dev 07:12 < BladeZero> Hey dudes. Want a Torrentleech invite for free? 07:15 -!- AhNo1 [~AhNo1@unaffiliated/ahno1] has joined #bitcoin-core-dev 07:17 < BladeZero> fo free 07:17 < BladeZero> What's your e-mail right now? 07:17 -!- AhNo1 [~AhNo1@unaffiliated/ahno1] has quit [Remote host closed the connection] 07:22 -!- AhNo1 [~AhNo1@unaffiliated/ahno1] has joined #bitcoin-core-dev 07:26 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ 07:27 -!- mode/#bitcoin-core-dev [+b *!*o@207.244.82.194] by wumpus 07:27 -!- mode/#bitcoin-core-dev [+b *!*@207.244.82.194] by wumpus 07:27 -!- BladeZero was kicked from #bitcoin-core-dev by wumpus [BladeZero] 07:27 -!- mode/#bitcoin-core-dev [-b *!*o@207.244.82.194] by wumpus 07:30 -!- bitconner [~conner@c-73-170-56-77.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 07:39 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving] 07:39 -!- bitconner [~conner@c-73-170-56-77.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds] 07:46 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev 07:49 -!- AhNo1 [~AhNo1@unaffiliated/ahno1] has quit [Quit: Leaving] 07:57 -!- promag [~promag@83.223.248.27] has joined #bitcoin-core-dev 07:58 < promag> wumpus: can I squash 14291? 08:01 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Read error: Connection reset by peer] 08:06 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 08:06 <@wumpus> depends on wheter other people want to review the changes commit by commit I guess? 08:06 <@wumpus> I don't think squashing too often is good 08:07 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ 08:07 < promag> ok, I'll just wait then 08:07 < luke-jr> I assume he means the fixup!s, not everything :p 08:07 < wumpus> yes, I understood that :p 08:11 -!- promag [~promag@83.223.248.27] has quit [Remote host closed the connection] 08:12 < wumpus> I only mentioned that because promag has the tendency to squash fixups immediately, this makes it difficult to check whether comments were adressed, it's prbably best to do it once before merge 08:16 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-utmfneelswbtqink] has joined #bitcoin-core-dev 08:16 < bitcoin-git> [bitcoin] hebasto closed pull request #14427: docs: Add config file docs to '-help' messages (master...20181004-help-config) https://github.com/bitcoin/bitcoin/pull/14427 08:16 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-utmfneelswbtqink] has left #bitcoin-core-dev [] 08:18 -!- IceHard [~user@176.107.82.36] has joined #bitcoin-core-dev 08:28 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 08:49 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has joined #bitcoin-core-dev 08:56 -!- AM5800 [5f5bf570@gateway/web/freenode/ip.95.91.245.112] has joined #bitcoin-core-dev 09:03 -!- IceHard [~user@176.107.82.36] has quit [Remote host closed the connection] 09:26 -!- IceHard [~user@176.107.82.36] has joined #bitcoin-core-dev 09:29 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 09:29 < IceHard> hello all :)))))) 09:30 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 09:33 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has quit [Read error: Connection reset by peer] 09:35 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has joined #bitcoin-core-dev 09:36 -!- promag [~promag@83.223.248.27] has joined #bitcoin-core-dev 09:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 09:36 < promag> wumpus: ^ noted 09:37 -!- AM5800 [5f5bf570@gateway/web/freenode/ip.95.91.245.112] has quit [Ping timeout: 256 seconds] 09:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 09:57 < instagibbs> hm is --enable-debug not enough to avoid "value has been optimized out" anymore? 09:57 -!- promag [~promag@83.223.248.27] has quit [Remote host closed the connection] 09:57 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has quit [Remote host closed the connection] 09:58 < jnewbery> promag: apologies, I haven't been very active in reviewing recently. I know there are a bunch of PRs that I need to catch up on. 09:59 < jnewbery> I don't think 13339 necessarily needs to go into project 2. I think we can probably just close project 2 once 13100 is merged 10:03 < wumpus> instagibbs: it usually is, though even with -Og it's possible that things are optimized out, you might want to try explicitly overriding CXXFLAGS to -O0 10:03 < wumpus> (and yes, even with that you can still get that ...) 10:07 < sipa> i don't think i've ever seen at -O0 10:08 < gmaxwell> 01:07:44 < karelb> thinking out loud- yesterday we talked with colleague how we hate that JSON RPC returns BTC values as floats. ( 10:08 < gmaxwell> karelb: the json rpc values ARE NOT FLOATS 10:09 < gmaxwell> json spec defines those values as "numbers" which have exact precision. it's up to implementations how they represent them. 10:10 < gmaxwell> in Bitcoin core they're just 64 bit integers. 10:11 < karelb> I didn't read json spec, isn't json spec supposed to compatible with JavaScript, which will interpret that as floating point? 10:12 < gmaxwell> karelb: no, as wikipedia says, "Numbers in JSON are agnostic with regard to their representation within programming languages." 10:13 < wumpus> no, json spec does not refer to the javascript spec 10:13 < jarthur> It's flexible, though the RFC indeed recommends it be compatible with the double float as used by JavaScript - https://tools.ietf.org/html/rfc7159#section-6 10:13 < wumpus> it's entirely self contained and very short, you should read it 10:13 < karelb> I thought json is supposed to be a strict subset of JS. ok I was wrong 10:14 < wumpus> as any format spec it only describes the *syntax* not how things should be stored 10:14 < gmaxwell> since JS accepts random stuff and does random stuff with it, I suppose this IRC log is a strict subset of js. :P 10:14 < wumpus> hehe exactly 10:14 < karelb> 🙂 10:15 < gmaxwell> There were patches floating around to add quotes around the amount values in bitcoind's rpc that can make it easier to correctly deal with values when you're stuck with a typical, stupid, json library. 10:17 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has quit [Ping timeout: 260 seconds] 10:18 < karelb> ... oh json spec is really deadly simple 10:19 -!- Tralfaz [~none@185.156.175.59] has joined #bitcoin-core-dev 10:20 < wumpus> gmaxwell: yes, it's trivial change to ValueFromAmount if you really want to, though I'd suggest looking at a better suited JSONRPC library, by now for most languages there's something for bitcoin specifically 10:21 < wumpus> ok that wasn't really directed at gmaxwell 10:22 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has joined #bitcoin-core-dev 10:32 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has quit [Ping timeout: 260 seconds] 10:33 -!- IceHard [~user@176.107.82.36] has quit [Remote host closed the connection] 10:43 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has joined #bitcoin-core-dev 10:49 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 10:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 11:01 < phantomcircuit> gmaxwell, iirc even if they are floats they're not in a range where it would be an issue 11:05 < luke-jr> phantomcircuit: but floats are binary, so they can't store fifths accurately, and you will need to round to get the right numbers 11:06 < gmaxwell> phantomcircuit: depends on what you mean by float, common bitcoin values don't fit precisely in 32-bit floats, they do in 64-bit doubles. 11:10 -!- Krellan [~Krellan@2601:640:4000:9258:38ac:a4ba:cad1:3968] has quit [Ping timeout: 260 seconds] 11:10 < jarthur> Interestingly JavaScript has an integer type now. You can play around with it in the Chrome developer console, just put 'n' after the numerals, like 1359873196781496491761916n 11:12 < wumpus> yes the different ECMA standards are slighly different in that regard 11:15 < wumpus> 'javascript' itself is ambigious, though, none of that reflects on JSON which is well-defined 11:16 < phantomcircuit> gmaxwell, iirc basically all js implementations are double right? 11:17 < andytoshi> yes, but the problem is that a lot of json parsers do stupid things and lose accuracy anyway 11:21 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 11:22 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 11:28 < phantomcircuit> andytoshi, yeah i guess that's the real thing 11:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 11:30 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 11:35 < wumpus> yes, off-by-ones are pretty common 11:37 < wumpus> as luke-jr says floats can't represent 1/5th (or 1e-8 for that matter) exactly so there's always some rounding going on 11:37 < wumpus> (floats of any precision) 11:41 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 11:41 * wumpus wishes any of the common serialization formats had a decimal type 11:41 < wumpus> an explicit one, I mean 11:43 < luke-jr> decimal sucks though :p 11:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 11:43 < gmaxwell> phantomcircuit: the old json library bitcoin used to use randomly inserted conversions to float in a minor upgrade! 11:43 < wumpus> for better or worse it's the choice for monetary values 11:44 < phantomcircuit> gmaxwell, :/ 11:45 < wumpus> as you can't really make an assumption about the precision, yes if you write software for bitcoin specifically you can hardcode 10^-8, but anythign that needs to interface between different systems and APIs and databases needs to convert between them on their own terms 11:56 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev 11:59 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 12:00 < luke-jr> hi? 12:01 < BlueMatt> mtg? 12:01 < sipa> ohai 12:02 < gmaxwell> ??!? 12:02 < achow101> hi 12:02 < gleb> hi 12:02 < luke-jr> ohayo 12:02 < jonasschnelli> hi 12:02 < BlueMatt> wherefor art thou wumpus 12:02 < sipa> we need to hunt the wumpus 12:03 < luke-jr> do we hunt the wumpus with nuclear, DDoS, or 51% attack? 12:03 < BlueMatt> dont hunt wumpus :O 12:03 < promag> hi 12:04 * luke-jr drops a hat on BlueMatt's head? 12:04 < jonasschnelli> #startmeeting 12:04 < lightningbot> Meeting started Thu Oct 18 19:04:07 2018 UTC. The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:04 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:04 < jonasschnelli> Topics? 12:04 < wumpus> hello 12:04 -!- rex4539 [~rex4539@ppp-2-84-165-183.home.otenet.gr] has joined #bitcoin-core-dev 12:04 < luke-jr> there he is 12:05 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 12:05 < jnewbery> hi 12:05 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator 12:06 < meshcollider> hi 12:06 < promag> topics suggestion, (remove?) address book 12:06 < jonasschnelli> #topic high priority list 12:06 < jonasschnelli> https://github.com/bitcoin/bitcoin/projects/8 12:06 < jonasschnelli> anything to add / del? 12:06 < instagibbs> hi 12:07 < wumpus> ListWalletDir is pretty much mergeable, needs sign-off on the last change 12:08 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer] 12:08 < wumpus> there was some confusion around BerkekleyDB and its endian handling, apparently it writes databases in native endian, but we're not 100% sure the database files are portable between little and big endian 12:08 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:08 < wumpus> (most likely they are and it's smart enough to interpret databases in alt endian) 12:08 < gmaxwell> wumpus: I'll test sometime in the next couple days, I'm pretty sure that it'll just convert it. 12:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 12:08 < promag> jonasschnelli: I don't mind replacing 14291 with 14350 12:08 < sipa> i'd like #14150 on the high priority list 12:08 < promag> gmaxwell: that would be cool 12:08 < meshcollider> Yeah I'm fairly sure it'll be fine with both 12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/14150 | Add key origin support to descriptors by sipa · Pull Request #14150 · bitcoin/bitcoin · GitHub 12:08 < wumpus> gmaxwell: great ! 12:08 < jnewbery> Should #14416 be high priority? I don't think there's anything to review, but the issue is important. 12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/14416 | [WIP] fix OSX dmg issue (10.12 to 10.14) by jonasschnelli · Pull Request #14416 · bitcoin/bitcoin · GitHub 12:09 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 12:09 < wumpus> jnewbery: sure 12:09 < jonasschnelli> sipa: added 12:09 < jnewbery> jonasschnelli: any update on that issue? 12:09 < jonasschnelli> promag: changed 12:09 < promag> jonasschnelli: ty 12:09 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 12:09 < meshcollider> I'd like #14454 on there please 12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/14454 | Add SegWit support to importmulti by MeshCollider · Pull Request #14454 · bitcoin/bitcoin · GitHub 12:09 < jonasschnelli> jnewbery: I'm currently investigating... but haven't found the issue yet 12:10 < promag> IIRC the idea was to create DS_Store with xenial? 12:10 < wumpus> although it's still WIP so normally that doesn't qualify 12:10 < jonasschnelli> meshcollider: done 12:10 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 12:10 < meshcollider> jonasschnelli: thanks :) 12:10 < jonasschnelli> #topic ds_store OSX issue 12:10 < jnewbery> wumpus: yeah, it's not high priority for review, but I'd say it's high priority to fix! 12:10 < jonasschnelli> i'm currently removing instruction by instruction to figure out, where the issue is 12:11 < jonasschnelli> (always. requires a gitian build) 12:11 < wumpus> jnewbery: would agree on that 12:11 < jonasschnelli> help from cfields would be welcome... but I guess his busy with other things 12:12 < jonasschnelli> Anyways,.. I'm on it. 12:12 < wumpus> so if anyone knows MacOSX low-level details about DS_store, please help with that issue 12:13 < jonasschnelli> #topic (remove?) address book (promag) 12:13 < wumpus> it's an undocumented, reverse-engineered format so it's quite hard to get right 12:13 < jonasschnelli> wumpus: indeed 12:13 < promag> We could remove access to the address book from the File Menu 12:14 < promag> so people would have to go to receive 12:14 < luke-jr> does the dmg have translations in it? 12:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 12:14 < instagibbs> ack 14150 12:14 < jonasschnelli> luke-jr: Yes 12:14 < wumpus> any specific reason to remove this functionality? 12:14 < luke-jr> jonasschnelli: I wonder if that's related. Do older versions' DMGs work? 12:14 < jonasschnelli> #14150 12:14 < gribble> https://github.com/bitcoin/bitcoin/issues/14150 | Add key origin support to descriptors by sipa · Pull Request #14150 · bitcoin/bitcoin · GitHub 12:14 < achow101> promag: isn't that the only way to change labels from the gui? 12:15 < promag> 12:15 < wumpus> achow101: you an also edit label from the transaction list 12:15 < wumpus> (right button context menu) 12:15 < promag> gmaxwell: knows better about the complaints/questions 12:15 < jonasschnelli> In the long run, the address book makes little sense to me... 12:15 < gmaxwell> wumpus: I don't know the context either, when I heard it above I assumed because it's been involved with the recent confusion about the get new address removal button and encourages address reuse. 12:15 < jonasschnelli> But I guess there are still users using it... 12:15 < gmaxwell> okay so that is the context. 12:16 < achow101> wumpus: that's... non-obvious 12:16 < meshcollider> that requires actually having a transaction then 12:16 < promag> but looks like people will reuse addresses not that the "new button" is gone 12:16 < promag> s/not/now 12:16 < jonasschnelli> *sigh* 12:16 < luke-jr> ugh 12:16 < wumpus> could re-add that button 12:16 < gmaxwell> wumpus: 0.17 really confused a lot of people due to the removal of the new button there. I've now seen more than a dozen questions about it online (linked some here, previously). 12:17 < wumpus> if people miss that, i'm not sure removing even more functionality is the right way forward 12:17 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 12:17 < wumpus> let's revert the remove and call it a day, users happy and it's easy 12:17 < achow101> concept nack on removing the address book. it'll just make people more confused 12:17 < promag> but I think that's because people goes to File menu and then they see the "received addresses" 12:17 < gmaxwell> wumpus: as gwillen points out, the 'request payment' button is really not-obvious. 12:17 < achow101> promag: instead of removing it, rename it to be more clear? 12:17 < jonasschnelli> PR: #12721 (remove) 12:17 < gribble> https://github.com/bitcoin/bitcoin/issues/12721 | Qt: remove "new" button during receive-mode in addressbook by jonasschnelli · Pull Request #12721 · bitcoin/bitcoin · GitHub 12:18 < luke-jr> achow101: we can revert + rename to cover both bases 12:18 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 12:18 < achow101> luke-jr: +1 12:18 < wumpus> yes 12:18 < gmaxwell> I wasn't previously thinking that we should remove the address book, but maybe we should: What use is it beyond enabling reuse? I do think if we don't remove it we should revert the removal. 12:18 < sipa> i think just adding text to the adress book that says "Use the receive payment tab to create new addresses" would help a lot already 12:18 < jonasschnelli> Or we can add a hint: "use Receive tab to create a new address"? 12:18 < jonasschnelli> :-) 12:18 < wumpus> removing the address book will probably result in even more complaints 12:19 < luke-jr> sipa: true 12:19 < sipa> but many wallets don't even have a concept of an address book 12:19 < gmaxwell> The complaints themselves aren't the concept, the resulting confusion is. :) 12:19 < wumpus> not worth it imo unless there's a really good story to do it besides 'it encourages re-use' as that's nothing new 12:19 < jarthur> People use the signing feature quite a bit. 12:19 < jonasschnelli> oh.. for that. Yes. 12:19 < luke-jr> jarthur: misuse* I suspect :/ 12:20 < gmaxwell> Okay, thats a reason to keep/rename. 12:20 < jonasschnelli> What about.. a) warn about address reuse, b) add hint to receive tab for new addresses? 12:20 < meshcollider> Theres an issue for renaming btw #14482 12:20 < gribble> https://github.com/bitcoin/bitcoin/issues/14482 | Better name for "Request Payment" button · Issue #14482 · bitcoin/bitcoin · GitHub 12:20 < achow101> topic suggestion: plans for new windows code signing key 12:20 < gmaxwell> Users really shouldn't be using it to get addresses to pay for. 12:20 < promag> gmaxwell: exactly 12:20 < jonasschnelli> Agree 12:20 < wumpus> no, they shouldn't, but for better or worse they're used to that 12:21 < luke-jr> I'm not really sure a clear rename for it btw 12:21 < gmaxwell> Re "request payment" being confusing, I had an argument with multiple people _in here_ because they believed "Request Payment" was somehow BIP70. So I think it's not disputable that its confusing. :P 12:21 < wumpus> it's not really easy to change people's behavior 12:21 < promag> I think we should improve the UI, remove address book from File menu, improve receive tab 12:21 < jonasschnelli> Agree also with gmaxwell 12:21 < gmaxwell> promag: +1 12:21 < jonasschnelli> "Request payment" is confusing 12:21 < jonasschnelli> Yes. Please do that promag 12:21 < wumpus> how is it called in other wallets? 12:22 < luke-jr> we could add sign message to the request-payment dialog probably 12:22 < gmaxwell> it doesn't exist in other wallets. 12:22 < jonasschnelli> wumpus "Receive" 12:22 < wumpus> well let's rename to that 12:22 < gmaxwell> oh you mean getting an address, 'recieve' 12:22 < gmaxwell> (my doesn't exist was referring to the address book) 12:22 < luke-jr> "Receive" implies you would receive it immediately :x 12:22 < jonasschnelli> And then maybe automatically show the next unused address? 12:22 < wumpus> if it doesnt' exist then maybe we should remove it too 12:22 < gmaxwell> jonasschnelli: the workflow can stay the same. 12:23 < wumpus> I wouldn't change the workflow too much either 12:23 < wumpus> lots of people will be used to that workflow too 12:23 < gmaxwell> Just change the label to make it more discoverable. 12:23 < wumpus> if you change that too much, you'll get the same issue in another place 12:23 < jonasschnelli> Wait,.. the tab is already labeled with "Receive", right? We are talking about the button for creating a new address? 12:23 < wumpus> yes, the tab is Receive 12:23 < wumpus> always has been 12:23 < gmaxwell> And the address book, should be moved out of the way... if it's utlity is just sign message it should be treated that way. 12:23 < meshcollider> Yep 12:24 < jonasschnelli> I think there should be a "new address" button and a "receive specific amount" button where you get prompted for amount / label 12:24 < luke-jr> gmaxwell: signing messages only makes sense pre-receive, so even that can be moved somewhere more logical (eg, part of the receive tab) 12:24 < promag> jonasschnelli: yes 12:24 < luke-jr> jonasschnelli: label is always desirable 12:25 < wumpus> I think 'make the workflow more apparent' is better than changing it 12:25 < jnewbery> meta-topic suggestion: does it make sense to discuss qt UI issues in the general bitcoin core IRC meeting? 12:25 < gmaxwell> jonasschnelli: label should always be availble, but I don't think a parallel button would be bad. 12:25 -!- rex4539 [~rex4539@ppp-2-84-165-183.home.otenet.gr] has quit [Quit: rex4539] 12:25 < wumpus> jnewbery: well the UI is part of the code base, if we don't want to discuss it, we should remove it 12:25 < sipa> meta-comment: at coredev tokyo it was suggested to have a separate wallet meeting as well, every 2 weeks 12:25 < gmaxwell> How about we just discuss nothing, jnewbery because there is no element of the software which is interesting to everyone. 12:25 < wumpus> as long as it is part of the code base it should be discussable in the meeting 12:26 < wumpus> gmaxwell: exactly 12:26 < jonasschnelli> Long term, multiple meeting make sense, until we have that, UI belong here 12:26 < jnewbery> My point was more along the lines of what sipa is talking about: the project doesn't scale if everyone discusses everything 12:26 < jonasschnelli> +s 12:26 < wumpus> it's already hard enough to fill the meetings hour many times 12:26 < wumpus> I don't think we should be discussing getting rid of cetain topics 12:26 < wumpus> but that's just IMO 12:26 < luke-jr> maybe when/if meetings get cut off due to time ;) 12:26 < gmaxwell> jnewbery: if we're always running out of time that would be a concern, but we seldom do. 12:27 < wumpus> yes, then it's time to prioritize certain topics 12:27 < jnewbery> ok, let me rephrase: does it make sense to have a separate meeting for qt issues? 12:27 < wumpus> no, I don't think so 12:27 < gmaxwell> And it's useful, even if you mostly don't care about something to occassionally get exposed to them. 12:27 < wumpus> as soon as the GUI is a aseparate project, that makes sense to reconsider. 12:27 < gmaxwell> certantly ignorance about the GUI contributes to problems in the software already... (see my above comment that there were _developers_ that though request payment was bip70). 12:28 < wumpus> and to be clear I think it's absurd the GUI and other things are the same repository as consensus code, but that's a wholly differnt issue, I don't think we have any problem in that regard with the meeting 12:28 < jonasschnelli> Indeed 12:29 < jonasschnelli> #action overhaul the receive page, overhaul the address-book to cure confusion with 0.17 12:29 < jonasschnelli> #topic plans for new windows code signing key (achow101) 12:29 < promag> ok thanks, I'll add screenshots too 12:30 < wumpus> gmaxwell: it's clear most of the developers here don't give a shit about the gui 12:30 < wumpus> gmaxwell: always has been 12:30 < jnewbery> my other topic suggestion was having a separate wallet meeting (which sipa already mentioned) 12:30 < achow101> the windows signing key expires just before the next release is scheduled 12:30 < wumpus> it has always been a thankless job maintainging it, lots of respect to jonasschnelli for that :D 12:31 < jonasschnelli> Though I should do more. :) 12:31 < achow101> IIRC there were plans to do mpc rsa stuff to replace it, did anything come of that? 12:31 < jonasschnelli> achow101: I don't think so.. 12:31 < jonasschnelli> Have you talked wo cfields (current Win signing key owner)? 12:31 < jonasschnelli> s/wo/to 12:31 < achow101> not yet. I only just noticed as I was looking at the key details today 12:31 < meshcollider> I thought he was working on something 12:31 < jonasschnelli> Ideally we get new keys also via the Bitcoin Core Code Signing Association (http://bitcoincorecodesigning.org) 12:32 < gmaxwell> achow101: I have it working for three parties, but got stuck extending it for more. 12:32 < jonasschnelli> achow101: thanks for pointing that out,.. better care about earlier then when its too late 12:33 < gmaxwell> achow101: would you lie to try the MPC with me at some point? 12:33 < achow101> gmaxwell: sure 12:33 < jonasschnelli> Maybe MPC it's not worth it. IMO windows code signing is more or less security theatre... 12:33 -!- bitconner [~conner@136.24.75.121] has joined #bitcoin-core-dev 12:34 < wumpus> does it give users problems if it's not signed? 12:34 < gmaxwell> Yes. 12:34 < achow101> wumpus: windows gives scary warnings 12:34 < gmaxwell> you get warnings that the software might be malicious. 12:34 < jonasschnelli> I think no-one would recognise if the certificate would be issued to "Bitcoin Cash Code Signing Association" 12:34 < jonasschnelli> We need to sign it for UX,.. but much for security reasons. 12:34 < meshcollider> jonasschnelli: how difficult is it to get a key for the code signing association then 12:34 < luke-jr> jonasschnelli: meaning nobody would mind, or it would freak them out? 12:35 < meshcollider> I'm unfamiliar with the process 12:35 < meshcollider> luke-jr: I'd say it would freak people out tbh 12:35 < achow101> luke-jr: I think no one would mind or even notice the name is different 12:35 < gmaxwell> luke-jr: he's saying no one would notice, I think thats mostly right. 12:35 < meshcollider> Not the different name, but not signing at all 12:35 < jonasschnelli> I founded an swiss association with no legal paper, no real address and could get a D-U-N-S address and an iOS apple enterprise program. So.. security means shit here. 12:35 < gmaxwell> (though the 'bitcoin foundation' thing did have an unfortunate effect of making people think BCF made the bitcoin software) 12:36 < luke-jr> "Bitcoin Cash Code Signing Association" hopefully wouldn't have that confusion 12:36 < jonasschnelli> Getting Windows signing key should be a simple task,.. we just need to decide on a cert supplier 12:37 < jonasschnelli> Lets wait on cfields though,.. he has the most knowhow here (before any action, buying certs, etc.) 12:37 < wumpus> jonasschnelli: it's still more work for scammers than nothing at all! but yes, not much. 12:37 < jonasschnelli> wumpus: Yes. But people may think, oh, its code signing, so it must be "secure" (false sense of sec.) 12:38 < jonasschnelli> The only difference is that some CA guy clicked to okay button after reading an address (for most CAs) 12:38 < wumpus> oh yes I don't disagree the user perception of what signingmeans is completely wrong 12:38 < meshcollider> IMO anyone confused by what the code signing means probably isn't aware of code signing at all? 12:38 < meshcollider> Users just get software and run it 12:39 < sipa> really it's a way to make some platforms shut up about untrusted code 12:39 < luke-jr> I suspect nobody would really notice if we stopped codesigning 12:39 < wumpus> sipa: yep 12:39 < meshcollider> Exactly 12:39 < gmaxwell> luke-jr: they would, because they get a big nasty warning 12:39 < meshcollider> luke-jr: I disagree, yeah 12:39 < luke-jr> maybe if we timed it right, we could use it as an opportunity to teach PGP verification 12:39 < jonasschnelli> If we want secure "update", we should finally have a "verificator" function in Core 12:40 < jonasschnelli> Some glue code that does gitian verification against a downloaded binary dummy-save 12:40 < luke-jr> gmaxwell: a warning they're used to clicking through all the time..? 12:40 < gmaxwell> luke-jr: most software is signed. 12:40 -!- bitconner [~conner@136.24.75.121] has quit [Ping timeout: 246 seconds] 12:40 < achow101> luke-jr: no, it's actually a warning on top of the normal warning 12:40 < phantomcircuit> gmaxwell, maybe it should be an "open source code signing association" 12:40 < phantomcircuit> rather than something bitcoin specific? (even if it's only signing bitcoin in practice) 12:41 < sipa> we talked about that a while ago 12:41 < luke-jr> phantomcircuit: jonasschnelli already set it up, for better or worse 12:41 < sipa> that it could just be something that signs off on deterministic builds 12:41 < meshcollider> phantomcircuit: if we already have the iOS certificate with the bitcoin one the windows one should be the same 12:41 < jonasschnelli> phantomcircuit: I think "Bitcoin Core" should be in the name 12:41 < luke-jr> although I suppose if there's a desire for a broader codesigning org, we could make another 12:41 < sipa> luke-jr: agree 12:41 < jonasschnelli> phantomcircuit: its somehow the only binding "guarantee" for the user 12:42 < phantomcircuit> this seems likely to be an issue faced by numerous projects 12:42 < luke-jr> jonasschnelli: ? seems like it would just reaffirm the false sense of security 12:42 < jonasschnelli> luke-jr: somehow,.. yes. :) 12:42 < luke-jr> jonasschnelli: a more obviously-dummy org name might prompt a real security verification 12:42 < phantomcircuit> it's certainly no actual security 12:42 < luke-jr> maybe we should call it Malware Signing Group 12:42 < luke-jr> :P 12:42 < phantomcircuit> luke-jr, doubtful honestly 12:42 < jonasschnelli> heh 12:43 < achow101> luke-jr: you wouldn't get issued a cert with that name 12:43 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has quit [Remote host closed the connection] 12:43 < jonasschnelli> Oh.. I'm sure you would 12:43 < luke-jr> Check The PGP Signatures, LLC 12:43 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has joined #bitcoin-core-dev 12:43 -!- bitconner [~conner@136.24.75.121] has joined #bitcoin-core-dev 12:44 < jonasschnelli> #topic suggestion was having a separate wallet meeting (which sipa already mentioned) (jnewbery) 12:44 < jonasschnelli> -suggestion 12:45 < wumpus> would this involve different people than the current meeting? 12:45 < achow101> how much wallet stuff is there to discuss? 12:45 < jnewbery> This was brought up in Tokyo. People seemed keen to have a separate meeting (perhaps once every two weeks) to discuss wallet issues 12:45 < meshcollider> And is it worth it until there's more actual separation 12:45 < wumpus> achow101: yes.. exactly.. how much wallet stuff do we discuss 12:45 < jonasschnelli> I think it worth it if we run constantly out of time 12:45 < wumpus> but if people want that, why not 12:45 < luke-jr> just the Core wallet, or wallets in general? 12:46 < jnewbery> Code/repo separation is somewhat orthogonal to project separation 12:46 < wumpus> luke-jr: wallets in general would make more sense I guess 12:46 < meshcollider> Worth noting that if we had a separate meeting, it might promote more discussion even if we don't have it right now 12:46 < gmaxwell> the disadvantage is just having to reserve and schedule more time. 12:46 < luke-jr> perhaps a S3ND IRC meeting or something 12:46 < jnewbery> Bitcoin core wallet 12:46 < sipa> wumpus: i think the question is more whether there are topics people don't bring up here because they're too work-in-progress or not relevant enough to bring up for everyone 12:46 < wumpus> we need a wallet maintainer... 12:46 < instagibbs> gmaxwell, depends on how big the group is 12:46 < gmaxwell> but maybe some things about the wallet aren't getting discussed in here. 12:46 -!- ExtraCrispy [~ExtraCris@gateway/tor-sasl/extracrispy] has quit [Remote host closed the connection] 12:46 < meshcollider> wumpus: how do we train someone for that job then 12:46 < instagibbs> in Tokyo there were a small handful who discussed some short term improvements, wouldn't be hard to coordinate among those 12:47 < wumpus> exactly; it makes sense to coordinate among the people who are interested in having this meeting 12:47 < meshcollider> For example I think there would be some good discussion around descriptor stuff in the near future right? 12:47 < gmaxwell> If people who want to talk about wallet stuff more want another meeting, great. 12:47 < wumpus> if you want to organize a meeting about your part of the code, go ahead 12:47 < jonasschnelli> Agree with wumpus 12:47 < jonasschnelli> (I'm happy to join that meeting) 12:47 * sipa suggests: same time, fridays, every two weeks 12:47 < wumpus> meetingbot is here and we'll respect it and shut up during it :) 12:48 < jnewbery> a couple of questions: how many people are interested? Should it be in here or a different channel? 12:48 < meshcollider> I'm interested 12:48 < gmaxwell> It should be here. 12:48 < jonasschnelli> we should probably list the meeting(s) somewhere (bitcoincore.org?) 12:48 < sipa> i'd rather keep it in this channel 12:48 < jonasschnelli> ack 12:48 < luke-jr> jnewbery: I'm not entirely disinterested, but I don't think I have time for it 12:48 < wumpus> yes, why not this channel 12:48 < gmaxwell> If there is anything so important going on that the meeting interrupting it would be a problem, then probably the meeting would be heled off in any case. :) 12:48 < achow101> sipa: +1 (re date and time) 12:49 < gmaxwell> held* 12:49 < sipa> being in this channel may encourage others to participate (or at least lurk and see what's being worked on) 12:49 < meshcollider> I was very confused because I thought it *was* Friday, but then I remembered you're all in the wrong time zone 12:49 < luke-jr> lol 12:49 < jonasschnelli> * has a while thought that meeting could be done in voice via jitsi *duck* 12:49 < meshcollider> +1 then 12:49 < achow101> meshcollider: at least we're not upside down 12:49 < meshcollider> :( 12:50 < gmaxwell> What would be bad is if it siphons wallet discussion off into places where fewer people see it. Keeping it in the same place would be a minor improement. 12:50 < jnewbery> so Friday for us would be saturday for meshcollider. Is that ok for you, or would you prefer it on a week day? 12:50 < meshcollider> Saturday is probably preferable even, less conflict with lectures 12:50 < sipa> (i'm suggesting friday because i already have meetings on all other days around that time) 12:51 < sipa> but that's a personal preference and i'm sure i can accomodate other times 12:51 < meshcollider> So are we starting this tomorrow then? 12:52 < jnewbery> ok, let's try for Friday then. I can't this week or next week. I'm happy to chair, or equally happy if someone else wants to volunteer 12:52 < jonasschnelli> We can do a poll? 12:52 < gmaxwell> It's probably better to start sooner, the first few meetings of this sort of thing are usually poorly attended. :P 12:52 < gmaxwell> better get that out of the way. 12:52 < sipa> i'm happy to chair as well 12:53 < luke-jr> does GUI move to wallet meetings or stay here? 12:53 < sipa> i wouldn't say anything "moves" 12:53 < meshcollider> Chair of wallet meeting = new wallet maintainer :D 12:53 < jonasschnelli> Wallet GUI in wallet, rest-GUI here? 12:53 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds] 12:53 < jonasschnelli> meshcollider: lol 12:54 < gmaxwell> I wouldn't say moves either. We should expect some duplication, with the extended discussion in comittee. 12:54 < jonasschnelli> Yes. That's fine I guess. 12:54 < gmaxwell> Otherwise, people get forced to attend all meetings, which I think is a non-goal. 12:54 < instagibbs> +1 12:54 < achow101> ack 12:55 < meshcollider> +1 12:55 < jnewbery> yeah, the suggestion ceratinly isn't that wallet isn't discussed in regular weekly meetings 12:55 < booyah> luke-jr: I would notice last of signs on binaries and/or on git tags. FYI :) 12:56 < luke-jr> FWIW, someone is already telling me OOB that there will be outrage if the address book is removed :P 12:56 < luke-jr> booyah: huh? 12:56 < jnewbery> topic suggestion: I think aj was going to bring up IRC meeting logs on bitcoincore.org today 12:56 < jnewbery> not sure if he's here 12:56 < jonasschnelli> 3.5min left. :/ 12:57 < luke-jr> pause the clock? 12:57 < gmaxwell> luke-jr: we weren't going to anyways, but what is the use they are referring to. 12:57 < gmaxwell> The action was to just refactor the interface some to make it less confusing. 12:57 < jnewbery> I guess if aj isn't here there's not much to talk about 12:57 < luke-jr> gmaxwell: apparently to "see all their addresses in one place"; I don't really get it 12:58 < gmaxwell> Though I'm interested in hearing about what the use of it is. 12:58 < gmaxwell> (other than signmessage) 12:58 < molz> lol 12:58 < booyah> luke-jr: I mean that some people do check signatures on binaries (from bitcoincore.org) and on git. Though now I see you could mean the windows specific signatures on exe, dunno how much people would care about that one 12:58 < luke-jr> booyah: rigth 12:58 < wumpus> yes, some people like the address book, could have told you so 12:59 < molz> gmaxwell, i know some people do save every address they have, like forever, and they save the wallet.dats they have and they like to see all their addresses in the address book, so i told luke in another channel that yes i think they would be mad at you guys if you get rid of the address book 12:59 < wumpus> you're going to get complaints if you remove it, that's why I said there's better be a very good reason/story to do so, "it's easy to reuse addresses" is nothing new 13:00 < jonasschnelli> #endmeeting good night, good morning or enjoy your lunch 13:00 < lightningbot> Meeting ended Thu Oct 18 20:00:18 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-10-18-19.04.html 13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-10-18-19.04.txt 13:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-10-18-19.04.log.html 13:00 < wumpus> that's been an issue since 2010 and I don't see why it warrants removal of anything now, personally 13:00 -!- Tralfaz [~none@185.156.175.59] has quit [Read error: Connection reset by peer] 13:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 13:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 13:01 -!- Tralfaz [~none@185.156.175.59] has joined #bitcoin-core-dev 13:01 < promag> molz: my suggestion is to move it away from the File Menu (not sure why is there) 13:01 < booyah> one use case might be, to view easily all my addresses ever used, all my recipients addresses, to retrospect a bit about for example how much privacy about me is leaked about me in blockchain 13:01 < booyah> like... did I ever transffered money to wikileaks or not (from this wallet) 13:02 < sipa> oh, this is about send addresses? 13:02 < booyah> I guess that is also visible in gui (mostly familiar with cli not gui) in tx history? but is it as easly accessible and wiht comments? 13:03 < gmaxwell> wumpus: we have been generally doing things to move away from reuse for a long time. 13:03 < jonasschnelli> sipa: there are both 13:03 < gmaxwell> _complaints_ are a one time thing, we shouldn't shy away from an actual intentional improvement because some people will complain. 13:03 < gmaxwell> I've been raising issues with the complaints because the confusion we're getting now wasn't intentional or expected. 13:04 < gmaxwell> They're a problem because people are confused, can't figure out how to get a new address... they're not a problem just because they're complaining. 13:04 < sipa> i think addressing the confusion is separate really from the address book 13:04 < wumpus> gmaxwell: still, I think the most straightforward is just to return the button 13:05 < wumpus> gmaxwell: instead of trying to re-educate people 13:05 < luke-jr> wumpus: return the button, but make it show a "this is how you do it" prompt and switch the tab? :p 13:05 < wumpus> then agian I'm not a GUI designer nor pretending to be one 13:06 < luke-jr> says the guy who wrote bitcoin-qt.. 13:06 < booyah> luke-jr: embbed a twitch stream with some slim cryptogirl showing how to do it >_> 13:06 < wumpus> yess I'm... not sure how I got involved in this at all tbh, I made bitcoin-qt because I thought it would help get actual GUI people invovled, make it easier for them 13:06 < promag> I think "File -> Receiving Addresses" is too powerful and misleading - old users are used to that and have to learn the new way 13:06 < sipa> wumpus: i think it has, actually 13:07 < sipa> wumpus: though perhaps to a lesser extent than you hoped 13:07 < promag> "Window -> Address Book" with 2 tabs or whatever just does the job for those that want that 13:07 < wumpus> I didn't expect this (apart from jonasschnelli who is doing a great job, as I said) 13:07 < wumpus> sipa: sure! 13:07 < luke-jr> I certainly would not have done anything with the GUI if not for wumpus's port 13:08 < wumpus> I think we can all agree wxwindows was even worse :-) 13:08 < promag> fortunately I'm not not from that time :P 13:08 < gmaxwell> wumpus: I think we should probably return the button, move the address book to where people will misuse it less, AND make the recieve button we want people to use more obvious. :P 13:08 -!- spinza [~spin@155.93.246.187] has quit [Ping timeout: 268 seconds] 13:08 < jonasschnelli> I think if we bring a "light client" mode during IBD and some throttling function, then redesign the GUI a bit, it will increase its userbase significant... although not sure if we want that. / 13:09 < luke-jr> jonasschnelli: want what? 13:09 < wumpus> I don't see how increasing the user base could ever be bad 13:09 < jonasschnelli> luke-jr: a large user base of novice users 13:09 < luke-jr> increasing the user base is essential :/ 13:09 < luke-jr> dangerously too many people aren't using their own full node right now 13:10 < wumpus> I mean, if that's not the point we could do with a command-line UI 13:10 < jonasschnelli> Yes. Thats a point. 13:10 -!- bitconner [~conner@136.24.75.121] has quit [Ping timeout: 244 seconds] 13:10 < sipa> pfff, netcat and JSON-RPC aren't that that hard 13:10 < sipa> :p 13:11 < promag> wumpus: btw I think 14453 is done 13:11 < luke-jr> speaking of which, I'd like to get the Windows/Mac builds automatically installing and setting up a Tor hidden service .. ? 13:11 < wumpus> though I agree with you there's .. some limit, we can extend the user base, but as an open source project we can never compete with bigcorp UIs in user friendlyness support etc 13:11 -!- bitconner [~conner@136.24.75.121] has joined #bitcoin-core-dev 13:12 < wumpus> luke-jr: a bitcoin core-tor bundle has been talked about since 2012 at least 13:12 < wumpus> I'm... not sure where all those years went, but we're still not there yet ;) 13:13 < wumpus> promag: thank you 13:13 < wumpus> luke-jr: at least the torcontrol support should be one step along the way, most of the work left is packaging etc 13:14 < luke-jr> wumpus: yes, I think we're pretty close now 13:14 < gmaxwell> wumpus: I think we should focus on power users and (esp small/medium scale) commercial users for that reason. 13:15 < wumpus> gmaxwell: yes, I think that makes most sense 13:15 < gmaxwell> since we'll never bring ourselves to be the best at ease of use (esp since we'd have a hard time agreeing to trade off privacy or security for ease of use) 13:16 < wumpus> right, don't really want to compromise everything for 'ease of use', we have a much harder goal, it should be user friendly and still accomplish those goals.. 13:17 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev 13:17 -!- phwalkr [~phwalkr@192.32.61.94.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 13:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 13:25 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 13:25 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 13:28 < wumpus> argh things like #14510 really want me to stop bothering with c++ 13:28 < gribble> https://github.com/bitcoin/bitcoin/issues/14510 | Avoid triggering undefined behaviour in base_uint ::bits() by practicalswift · Pull Request #14510 · bitcoin/bitcoin · GitHub 13:29 < gmaxwell> at least the compilers can just warn about that. 13:30 < wumpus> so this is undefined behavior, the thing that could spawn unicorns or swallow galaxies or other arbitrary behavior 13:33 < wumpus> this particular instance hasn't killed us yet 13:34 -!- Guest63155 [~schmidty@104-7-216-111.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 246 seconds] 13:35 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 13:39 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 13:39 -!- laurentmt [~Thunderbi@185.242.6.5] has joined #bitcoin-core-dev 13:52 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev 13:56 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-parrwleczbmokduf] has joined #bitcoin-core-dev 13:56 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fe23553edd84...3715b2489e98 13:56 < bitcoin-git> bitcoin/master 96f6dc9 practicalswift: Avoid triggering undefined behaviour in base_uint::bits() 13:56 < bitcoin-git> bitcoin/master 3715b24 Wladimir J. van der Laan: Merge #14510: Avoid triggering undefined behaviour in base_uint::bits()... 13:56 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-parrwleczbmokduf] has left #bitcoin-core-dev [] 13:57 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ephmcukffssezqts] has joined #bitcoin-core-dev 13:57 < bitcoin-git> [bitcoin] laanwj closed pull request #14510: Avoid triggering undefined behaviour in base_uint::bits() (master...1<<31) https://github.com/bitcoin/bitcoin/pull/14510 13:57 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ephmcukffssezqts] has left #bitcoin-core-dev [] 14:07 -!- kelt [~kelt@mobile-166-177-121-91.mycingular.net] has joined #bitcoin-core-dev 14:09 < hebasto> wumpus: may you look into #14409 ? 14:09 < gribble> https://github.com/bitcoin/bitcoin/issues/14409 | utils and libraries: Make blocksdir always net specific by hebasto · Pull Request #14409 · bitcoin/bitcoin · GitHub 14:10 -!- laurentmt [~Thunderbi@185.242.6.5] has quit [Quit: laurentmt] 14:15 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-okmctxurffoxnlqw] has joined #bitcoin-core-dev 14:15 < bitcoin-git> [bitcoin] practicalswift opened pull request #14513: Avoid 1 << 31 (UB) in calculation of SEQUENCE_LOCKTIME_DISABLE_FLAG (master...1<<31-again) https://github.com/bitcoin/bitcoin/pull/14513 14:15 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-okmctxurffoxnlqw] has left #bitcoin-core-dev [] 14:17 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection] 14:17 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 14:29 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 14:30 -!- earlz is now known as tubetime2 14:30 -!- tubetime2 is now known as earlz 14:32 < phantomcircuit> im not sure exactly how to deal with detecting functional poll() support 14:32 < phantomcircuit> it's definitely broken on windows 14:33 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 14:33 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection] 14:34 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 256 seconds] 14:34 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev 14:35 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-fbgtzrsdlrvgihbd] has joined #bitcoin-core-dev 14:35 < bitcoin-git> [bitcoin] practicalswift closed pull request #14506: Remove redundancies: redundant forward declaration, redundant namespace, redundant copying, redundant conditionals (master...remove) https://github.com/bitcoin/bitcoin/pull/14506 14:35 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-fbgtzrsdlrvgihbd] has left #bitcoin-core-dev [] 14:37 < wumpus> definitely don't use poll on windows 14:37 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ctuibgimslactobi] has joined #bitcoin-core-dev 14:37 < bitcoin-git> [bitcoin] practicalswift closed pull request #13897: clientversion: Define only macros we’ll use (master...remove-unused-macros) https://github.com/bitcoin/bitcoin/pull/13897 14:37 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ctuibgimslactobi] has left #bitcoin-core-dev [] 14:37 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-zoztfohavlbnflfi] has joined #bitcoin-core-dev 14:37 < bitcoin-git> [bitcoin] practicalswift closed pull request #13548: Document assumptions made in PeerLogicValidation::SendMessages(...) and rescanblockchain(...) (master...document-non-nullptr-assumptions) https://github.com/bitcoin/bitcoin/pull/13548 14:37 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-zoztfohavlbnflfi] has left #bitcoin-core-dev [] 14:38 < wumpus> every *POSIX* OS supports poll() 14:38 < wumpus> so that's everything we support, except windows 14:46 < wumpus> select on windows doesn't have the same problems as select on unices anyhow; just keep using it 14:48 < sipa> it's pretty inefficient (stores the fds in a linked list afaik), but it doesn't have a hard limit on the number of watched fds or ooen files 14:48 < luke-jr> re bundling tor: it's a shame Tor has stopped using gitian :/ 14:50 -!- str4d [~str4d@169.243.9.51.dyn.plus.net] has joined #bitcoin-core-dev 14:52 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 14:52 < wumpus> sipa: so does windwos have any better alternative? at least not poll... 14:53 < luke-jr> Windows has an alternative that requires a different paradigm IIRC 14:53 < luke-jr> you read/write and get told when it's done; rather than waiting for read/writability 14:54 < wumpus> right, some async notification 15:13 < promag> meshcollider: achow101: can you take a look at #14291 so I can squash? 15:13 < gribble> https://github.com/bitcoin/bitcoin/issues/14291 | wallet: Add ListWalletDir utility function by promag · Pull Request #14291 · bitcoin/bitcoin · GitHub 15:14 < meshcollider> promag: sure :) 15:20 -!- jarthur_ [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 15:23 -!- jarthur [~jarthur@207.114.244.5] has quit [Ping timeout: 252 seconds] 15:24 -!- jarthur_ [~jarthur@207.114.244.5] has quit [Ping timeout: 246 seconds] 15:24 < wumpus> yes let's squash and merge it 15:25 -!- dviola [~diego@unaffiliated/dviola] has quit [Ping timeout: 245 seconds] 15:26 < meshcollider> +1 15:30 < promag> thanks guys, squash and push done, waiting to ci 15:30 < promag> err, for ci 15:36 < wumpus> how crap is C++ that even defining a constant can be undefined behavior, without the compiler complaining? 15:36 < meshcollider> promag: thank you for taking that up btw 15:37 < meshcollider> wumpus: no doubt about it lol 15:37 < sipa> wumpus: presumably because in the actual implementation it isn't undefined 15:37 < wumpus> sipa: I'm not sure I understand, hwo can it be defined in the implementation but not in the language? 15:38 < sipa> wumpus: non-standard extension to the language 15:38 < wumpus> I really don't understand it, I'm not sure how I've even been able to use it without knowing this 15:38 < wumpus> how much broken code I must have written 15:39 < gmaxwell> The compiler can freely implementation define any undefined behavior. 15:39 < sipa> in practice, compilers implement a language that is significantly closer to people's expectations than what the actual standard specifies 15:39 < wumpus> the many times i've written 1< it's sad 15:39 < gmaxwell> and C/C++ code is typically FULL of stuff that a wonkish read of the language is undefined. 15:39 < promag> sipa: could you reack 14453? comment added and a variable renamed. 15:40 < wumpus> gmaxwell: isn't that bizarre 15:41 < gwillen> a lot of it is just due to the tight binding between C and asm 15:41 < wumpus> tight binding? 15:41 < sipa> C historically is much worse in that regard than C++ 15:41 < gwillen> where a lot of the most natural interpretations of technically-undefined behavior, i.e. what it does if you're not clever, is whatever the CPU does 15:41 < wumpus> i'm convinced I can write better assembly than c++ at this point 15:41 < gwillen> for example, in a twos-complement environment, signed integer overflow naturally works 15:41 < gwillen> and people have come to rely on it 15:41 < wumpus> at least the instructions simply mean what htey do 15:41 < gwillen> but in C it is undefined 15:41 < gmaxwell> gwillen: I don't think that has anything to do with C binding with ASM. 15:41 < luke-jr> wumpus: ironically, the fix here is also undefined behaviour >.> 15:42 < gwillen> well, binding with the environment it was born in 15:42 < wumpus> assembly language is.. mechanical, well documented 15:42 < sipa> wumpus: there are plenty of machine code instructions without well documented behaviour too :) 15:42 < gwillen> like, the reason people come to expect undefined things to still work is that they just do whatever the natural implementation is if you didn't care about it 15:42 < wumpus> okay 15:42 < luke-jr> (just undefined behaviour we rely on, for now) 15:42 < gwillen> if signed overflow trapped in the CPU then people wouldn't rely on it working in C 15:42 < gwillen> and then get nailed when the compiler writers take it away 15:43 < luke-jr> (it's still undefined, because unsigned int is only required to be 16 bits, not 32) 15:43 < sipa> luke-jr: that's implementation defined :) 15:44 < wumpus> implementation defined makes some sense 15:44 < sipa> luke-jr: if the unsigned int type is 32 bits, then shifts up to 31 bits are well defined 15:44 < wumpus> like 'int' types being the natural size for an architecture 15:44 < wumpus> that's not ub 15:44 < sipa> so you can write platform specific code that's fully correct 15:45 < gwillen> I mean, we also have uint32_t and the like now, so we don't ever have to rely on the length of a native int 15:45 < sipa> yeah... 15:45 < wumpus> that's indeed the result of a direct mapping from C to te underlying architecture as gwillen said 15:45 < gwillen> (and rust made imo the right choice to kill the native int) 15:45 < gwillen> (I mean you can still ask for it, but it isn't named "int" anymore so nobody's tempted) 15:45 < sipa> the uintX_t and uint_fast_X_t model is a far better than the arbitrary mapping for short/int/long 15:45 < luke-jr> native int does make sense for some things 15:46 < luke-jr> like <15 bit iteration loops 15:46 < sipa> luke-jr: you know of uint_fast16_t for example? 15:46 < luke-jr> sipa: vaguely; I don't have its semantics memorised 15:46 < gwillen> sipa: I don't know about this! 15:46 < gwillen> is that "at least 16 but something the cpu likes"? 15:46 < sipa> it's a data type that's at least 16 bits, but may be larger if larger is faster to work with 15:47 < gwillen> that's cool, I had no idea 15:47 < wumpus> yes there's a whole zoo of data types in stdint.h 15:47 < luke-jr> so by definition the same as unsigned int? :P 15:47 < gwillen> I don't think unsigned int is required to be fast 15:47 < gwillen> you could make it 16 if you wanted to be perverse 15:48 < luke-jr> but it's supposed to be the fastest for the platform, IIRC? 15:48 < sipa> there is also uint_least16_t for example, which is the smallest type that supports 16 bits 15:48 < sipa> (in case there is no actual type with 16 bits of width) 15:48 < gwillen> it's not required to be anything in particular, e.g. on 64-bit platforms int is usually still 32 but sometimes 64 depending on what model you're using 15:48 < gwillen> even though 64 is probably faster to work with 15:48 < gwillen> (I think people have generally settled on 32 for int, 64 is rare now, but in the early 64-bit days it was up in the air I believe) 15:49 < sipa> on windows 64, int and long are both 32 bits 15:50 < wumpus> right, instruction sets tend to have instructions for working with either 32 or 64 bit because of that, 16 or 8 is usually slower because of extra ands etc 15:50 -!- jimmysong [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has joined #bitcoin-core-dev 15:50 < gmaxwell> wumpus: re the additional 1<<31, I commented about that on the other PR. ... I'm not sure why the compiler doesn't warn about that. It may be that doing that is so common that they don't warn. 15:50 -!- tknp [~tknp@unaffiliated/tknp] has joined #bitcoin-core-dev 15:50 < sipa> yeah, c++14 makes it well defined evne 15:51 < luke-jr> clang does warn for it with -Weverything 15:51 < luke-jr> a.c:2:18: warning: signed shift result (0x80000000) sets the sign bit of the shift expression's type ('int') and becomes negative [-Wshift-sign-overflow] 15:51 < phantomcircuit> wumpus, seems to be broken on HPUX but im not sure we care really 15:51 < luke-jr> (IIRC it also miscompiles it) 15:51 < wumpus> phantomcircuit: didn't HPUX die in 2000 or o 15:52 < sipa> which probably means "treat as unsigned, and convert back to signed" is so common in practice (because that's the only reasonable way to compile it on modern platforms) 15:52 < wumpus> we don't need to support museum operating systems 15:52 < phantomcircuit> http://www.greenend.org.uk/rjk/tech/poll.html 15:53 < luke-jr> I can only imagine how many warnings Core has if we use clang's -Weverything.. 15:53 < wumpus> sipa: right, breaking that assumption would likely break all the code in practice 15:53 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [Remote host closed the connection] 15:53 < sipa> luke-jr: so that warning tells you it's likely not the behaviour you want (which is a totally reasonable warning), but it's not actually warning that on other platforms this code may be UB 15:53 < phantomcircuit> anything with 0 is broken anything with ? is probably broken 15:53 < sipa> luke-jr: i expect that even in C++14 that warning will still appear 15:54 < wumpus> phantomcircuit: everything and everyone is broken 15:54 < promag> luke-jr: what's the difference to -Wall? 15:54 < luke-jr> sipa: yes 15:54 < luke-jr> promag: -Weverything is a lot more warnings 15:54 < luke-jr> -Wall IIRC is some kind of "everything GCC supports" 15:55 < promag> luke-jr: ty 15:55 < phantomcircuit> luke-jr, it's not any more 15:55 < luke-jr> ? 15:56 < phantomcircuit> there's a bunch of warning flags that -Wall doesn't turn on 15:56 < wumpus> so do I still dare merge anything 15:56 < luke-jr> merge bacon 15:57 < sipa> wumpus: i think we should keep in mind that we're actually fairly restrictive in supported platforms 15:57 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Ping timeout: 252 seconds] 15:58 < sipa> where things are far saner than the technical language specification 15:58 < wumpus> sipa: that's true 15:58 < sipa> that doesn't mean we should dismiss these improvements to get us closer to compliance with the standard 15:58 < wumpus> but it could break any time right 15:58 < sipa> have we ever had a bug that was due to a misunderstanding of undefined behaviour? 15:59 < wumpus> I don't think we had, I remember there were some awful bugs in the linux kernel though 15:59 < sipa> wumpus: compilers are very careful generally in not breaking behavior that is relied on in practice 15:59 < gmaxwell> No, I don't believe we have.. the closest is %0 in the bloom filter thing. 16:00 < gmaxwell> (a failure to follow my aversion to any and all division... :P but not UB) 16:00 < sipa> all i'm saying is that we should treat getting rid of reliance on implementation defined as a worthy goal, but it's not a drama that we have in fact for years relied on some totally reasonable but unspecified things in practice 16:00 < sipa> BIP 42 perhaps 16:00 < sipa> :) 16:00 < wumpus> hehe yes BIP42 16:01 < gmaxwell> some of these things which are safe by compiler defined behavior but out of spec are mostly interesting to fix so that we can use stronger testing tools without false positives. 16:01 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ebskioqoykvgoskk] has joined #bitcoin-core-dev 16:01 < bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/3715b2489e98...8eb2cd1ddaab 16:01 < bitcoin-git> bitcoin/master fc4db35 João Barbosa: wallet: Add ListWalletDir utility... 16:01 < bitcoin-git> bitcoin/master d1b03b8 João Barbosa: interfaces: Add getWalletDir and listWalletDir to Node 16:01 < bitcoin-git> bitcoin/master cc33773 João Barbosa: rpc: Add listwalletdir RPC 16:01 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-ebskioqoykvgoskk] has left #bitcoin-core-dev [] 16:02 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-xvaezstwzsmboyic] has joined #bitcoin-core-dev 16:02 < bitcoin-git> [bitcoin] laanwj closed pull request #14291: wallet: Add ListWalletDir utility function (master...2018-09-list-wallet-dir) https://github.com/bitcoin/bitcoin/pull/14291 16:02 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-xvaezstwzsmboyic] has left #bitcoin-core-dev [] 16:05 -!- klot [~klot@188.113.35.204] has quit [Read error: Connection reset by peer] 16:08 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection] 16:10 < meshcollider> \o/ 16:10 * gmaxwell cries 16:10 < gmaxwell> https://www.reddit.com/r/Bitcoin/comments/9pcfwu/full_node_slow_to_sync_help_needed/ 16:10 < gmaxwell> all the bad advice 16:11 < meshcollider> promag: I'll review #14350 after you've rebased it too 16:11 < gribble> https://github.com/bitcoin/bitcoin/issues/14350 | Add WalletInfo class by promag · Pull Request #14350 · bitcoin/bitcoin · GitHub 16:12 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 16:12 < meshcollider> heh, just as I say that... 16:13 < promag> can you add refactoring label to 14350? 16:13 < promag> thanks 16:18 < gwillen> gmaxwell: my experience is that, as much as the client SHOULD be better than this, "disconnect/reconnect to get better peers" is not bad advie 16:18 < gwillen> advide* 16:18 < gwillen> ... spelling. 16:22 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 245 seconds] 16:23 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev 16:24 < booyah> wumpus: gmaxwell: actually, ((int)1) << ((int)31) is *not* UB, it is fully defined 16:24 < booyah> as smart people on ##c++ confirmed my suspicion that UBSAN doesn't cmplain about that operation 16:24 < booyah> legal because: http://eel.is/c++draft/expr.shift#2.sentence-3 16:24 < gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub 16:25 < sipa> booyah: i believe it is undefined by the C++11 spec, and not in C++14 16:25 < sipa> booyah: that is new language in C++14 16:26 < sipa> C++11 just says if the result of a shift is not representable in a signed type, it is UB 16:26 < booyah> wait, actually it's implementation-defined still. RandomReader: so this means entire (int)1 << (int)31 is then IB, because of that final conversion after therorethically *2^E2 done as-if values would be unsigned? yes 16:27 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [Ping timeout: 244 seconds] 16:31 < booyah> yeap ok UB in 11. 16:36 < gmaxwell> gwillen: it's mostly placebo advice. Yes, you may have more apparent progress for a bit, but you'll stall out again. And, of course, any of that has nothing to do with rate limiting. The rate limiting the poster discusses disconnects peers. 16:38 < gwillen> does Core in fact have logic for tossing out slow peers during IBD? My experience has definitely been that it will chug along forever at a trickle unless I force it to switch. 16:39 < sipa> gwillen: yes 16:39 < sipa> gwillen: though it can definitely be improved 16:40 < sipa> the downloading happens in a sliding window of 1024 window, and when all blocks within the window are either downloaded, or waiting for a single peer, that peer is kicked after a few seconds 16:41 < sipa> or in other words, when a single peer is the reason why the window can't advance, that peer is kicked 16:41 < gwillen> ahh hmm, so it could take awhile to trigger the kick 16:41 < gwillen> and if it's two peers you still lose 16:41 < sipa> if you have 2 equally slow peers this logic will never kick in practice 16:41 < sipa> only when one is significantly slower than all others 16:41 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 16:42 < gwillen> I suspect one benefit of restarting during IBD may be related to Comcast peers (or others with a similar scheme) 16:42 < phantomcircuit> gwillen, restarting can actually break that logic and make things take longer 16:42 < gwillen> they get some kind of temporary bandwidth boost good for a limited number of bytes 16:42 < gwillen> and then they get throttled 16:42 < gwillen> (is my understanding) 16:42 < gwillen> designed to cheat speedtests, if one is cynical 16:43 < phantomcircuit> gwillen, "BOOST!" 16:43 < phantomcircuit> yeah that's literally what it's designed to do 16:44 < gmaxwell> gwillen: the fastest computers we've ever run this on can't sync at more than 50mbit/sec due to other limits. 16:45 < gmaxwell> so that requires 6mbit/sec service from 8 peers, which isn't asking for that much. 16:47 < gwillen> you wouldn't think, but if that were true then IBD would always proceed at full sync speed and nobody would be complaining on reddit about it 16:48 < gwillen> I mean, until I gave in and gave up on sonic, I was a DSL user, so my upload was maybe 1.5 on a good day 16:48 < phantomcircuit> gmaxwell, yeah i think the main issue is actually aws nodes 16:48 < phantomcircuit> there they can give you recent blocks but have multi second latency to get old blocks 16:54 < sipa> gwillen: also, a window of 1024 blocks is ginormous for recent blocks 16:54 < gwillen> *nods* 16:54 < sipa> (but kinda small for the first 100000 blocks or so...) 16:58 -!- Bullit [~Bullit01@037-230-158-163.dynamic.caiway.nl] has quit [Quit: Leaving] 17:02 < gmaxwell> gwillen: there are a lot of reasons things can be slow. 17:02 < gwillen> yeah, but I know I have a decent CPU, and I know how to check if my own connection is working 17:03 < gmaxwell> including, for example, that when blocks arrive out of order, they'll all processed at once while not emptying the buffers on connections, which are only 5MB in size. 17:03 -!- str4d [~str4d@169.243.9.51.dyn.plus.net] has quit [Ping timeout: 244 seconds] 17:04 < gmaxwell> so when a peer or two is slow and pauses validation, once the missing blocks show up, you'll connect up to 1000 blocks at once, and all your transfers stall out. 17:04 < gwillen> oof, *nod* 17:05 < gmaxwell> and even on a fast computer, 1 second per block to validate during sync isn't too unrealistic. 17:11 -!- bralyclow [~bralyclow@76-202-84-204.lightspeed.tukrga.sbcglobal.net] has joined #bitcoin-core-dev 17:12 -!- bralycl__ [~bralyclow@195.242.213.119] has joined #bitcoin-core-dev 17:13 -!- bralyclo_ [~bralyclow@195.242.213.117] has quit [Ping timeout: 252 seconds] 17:16 < phantomcircuit> gmaxwell, hmm that seems kind of broken 17:16 -!- bralyclow [~bralyclow@76-202-84-204.lightspeed.tukrga.sbcglobal.net] has quit [Ping timeout: 246 seconds] 17:16 < phantomcircuit> how difficult would it be to process one block at a time instead? what kind of negative performance could that cause 17:17 < gmaxwell> the reason it processes all at once is more about not ending up in a weird place during a reorg, rather than anything performance related. 17:20 < sipa> phantomcircuit: we should just reduce the size of the download window later in the chain 17:20 < sipa> it actually releases cs_main briefly in between each block 17:22 < luke-jr> or finally get on with a block weight limit decrease <.< 17:23 -!- Bullit [~Bullit01@037-230-158-163.dynamic.caiway.nl] has joined #bitcoin-core-dev 17:25 < gmaxwell> sipa: it releases cs_main, but doesn't exit the message handling loop and go empty the queues for the other peers. 17:25 -!- jimmysong [~jimmysong@72-48-253-51.dyn.grandenetworks.net] has quit [Ping timeout: 268 seconds] 17:26 < gmaxwell> it's really easy to see the effect... bandwidth usage continually drops to zero while syncing. 17:27 < sipa> gmaxwell: yup 17:27 < sipa> the solution to that is doing blocm validation in the background... 17:28 < gmaxwell> or just exit the message handling loop after processing a couple blocks... so that it can go drain the queues for the other peers. 17:28 < sipa> fair; but we'd need to make sure to not process any further messages from the peer until all blocks are processed 17:29 < sipa> but that doesn't sound too hard actually 17:30 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 17:31 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 17:37 < gmaxwell> Some people, when confronted with a problem, think "I know, I'll use concurrency." Now they have tproblemsow. 17:39 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 17:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 17:41 < sipa> Some people, when confronted with a problem, think "I know, I'll use floating point." Now they have 1.9999997 problems. 17:45 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev 17:46 < andytoshi> in fairness, i can read "tproblemsow" twice as fast as i could read two words 17:46 * andytoshi ducks 17:52 < phantomcircuit> gmaxwell, hmm i guess with a reorg we rewind and then walk all the way to the new tip 17:52 < phantomcircuit> could rewind to the split and then do normal sync again with the new headers 17:54 < phantomcircuit> i assume rewinding is reasonably fast? 17:54 < phantomcircuit> or no 17:54 < gmaxwell> rewinding is slow 17:54 < sipa> phantomcircuit: we release cs_main whenever we're in a state that's better than the previous state 17:55 < sipa> or when we're back in a previous state and there is no valid better chain available 18:01 < gmaxwell> it should just do enough work to get to a better position then it last was and stop. 18:02 < gmaxwell> so a reorg would still block things for a while but otherwise it won't slow down progress generally. 18:06 -!- ken2812221 [~ken281222@110.50.135.178] has quit [Quit: Leaving] 18:09 -!- jb55 [~jb55@S010660e327dca171.vc.shawcable.net] has quit [Quit: WeeChat 2.2] 18:15 -!- jpe__ [~jpe@2001:16b8:4840:b300:1a90:8c48:4352:4903] has joined #bitcoin-core-dev 18:16 < phantomcircuit> sipa, it would be nice if there was something like "step and tell me if you did something" 18:16 < phantomcircuit> then run that in the background 18:17 < sipa> gmaxwell: seems reasonable... but how do you make sure to continue processing blocks when no peer is giving you anything? 18:17 < sipa> whenever the processing timeout fires? 18:18 -!- jpe_ [~jpe@2001:16b8:48fd:8300:2fd5:7fe8:28da:c43f] has quit [Ping timeout: 260 seconds] 18:20 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…] 18:22 < phantomcircuit> sipa, background thread 18:24 < sipa> phantomcircuit: i'm trying to get gmaxwell to see that may be useful :p 18:37 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection] 18:38 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev 18:59 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 19:05 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:05 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev 19:06 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood] 19:07 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 19:07 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit [Client Quit] 19:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 250 seconds] 19:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:11 -!- lukedashjr is now known as luke-jr 19:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 19:15 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection] 19:26 -!- Murch [~murch@50-200-105-218-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.] 19:29 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection] 19:33 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev 19:56 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 19:57 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 20:03 -!- bralyclow2 [~bralyclow@195.242.213.121] has joined #bitcoin-core-dev 20:04 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 252 seconds] 20:05 -!- bralyclow2 [~bralyclow@195.242.213.121] has quit [Client Quit] 20:05 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 252 seconds] 20:14 -!- satashi [1753fb86@gateway/web/freenode/ip.23.83.251.134] has joined #bitcoin-core-dev 20:20 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 20:20 -!- satashi [1753fb86@gateway/web/freenode/ip.23.83.251.134] has quit [Ping timeout: 256 seconds] 20:22 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 20:39 -!- bitconner [~conner@136.24.75.121] has quit [Ping timeout: 246 seconds] 20:40 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Ping timeout: 245 seconds] 20:46 -!- tknp [~tknp@unaffiliated/tknp] has quit [Quit: tknp] 20:56 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev 20:57 -!- schnerchi [~schnerchi@p3EE1C414.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 20:59 -!- schnerch_ [~schnerchi@p3EE1C1B7.dip0.t-ipconnect.de] has quit [Ping timeout: 246 seconds] 21:24 -!- harrymm [~harrymm@69.161.195.103] has quit [Ping timeout: 245 seconds] 21:27 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-mwunrudsgbtzzhfo] has joined #bitcoin-core-dev 21:27 < bitcoin-git> [bitcoin] fanquake opened pull request #14515: doc: Update OpenBSD build guide for 6.4 (master...openbsd-6-4) https://github.com/bitcoin/bitcoin/pull/14515 21:27 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-mwunrudsgbtzzhfo] has left #bitcoin-core-dev [] 21:27 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-xyjgtnucndupbuew] has joined #bitcoin-core-dev 21:27 < bitcoin-git> [bitcoin] fanquake closed pull request #14314: Trivial: gitignore contents of db4 folder (master...master) https://github.com/bitcoin/bitcoin/pull/14314 21:27 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-xyjgtnucndupbuew] has left #bitcoin-core-dev [] 21:28 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev 21:41 -!- harrymm [~harrymm@mx-ll-223.204.113-194.dynamic.3bb.co.th] has joined #bitcoin-core-dev 21:52 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 21:55 -!- jarthur [~jarthur@2605:6000:1019:41ab:f1a8:97f5:2e5c:9a90] has joined #bitcoin-core-dev 21:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 22:06 -!- dviola [~diego@unaffiliated/dviola] has quit [Ping timeout: 245 seconds] 22:07 -!- diego2 [~diego@186.222.90.17] has joined #bitcoin-core-dev 22:10 -!- gwillen [~gwillen@unaffiliated/gwillen] has quit [Ping timeout: 268 seconds] 22:11 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined #bitcoin-core-dev 22:12 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer] 22:12 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 22:14 -!- diego2 [~diego@186.222.90.17] has quit [Quit: WeeChat 2.2] 22:21 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev 22:49 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev 22:49 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection] 22:53 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-lityhyfcyyiksoda] has joined #bitcoin-core-dev 22:53 < bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8eb2cd1ddaab...d387507aeca6 22:53 < bitcoin-git> bitcoin/master ca6d86c Chun Kuan Lee: tests: Stop node before removing the notification file 22:53 < bitcoin-git> bitcoin/master d387507 Pieter Wuille: Merge #14465: tests: Stop node before removing the notification file... 22:53 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-lityhyfcyyiksoda] has left #bitcoin-core-dev [] 22:54 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-bnzutyvyuebhzppo] has joined #bitcoin-core-dev 22:54 < bitcoin-git> [bitcoin] sipa closed pull request #14465: tests: Stop node before removing the notification file (master...test-notification-fix) https://github.com/bitcoin/bitcoin/pull/14465 22:54 -!- bitcoin-git [bitcoin-gi@gateway/service/github.com/x-bnzutyvyuebhzppo] has left #bitcoin-core-dev [] 23:08 -!- rh0nj [~rh0nj@136.243.139.96] has quit [Remote host closed the connection] 23:09 -!- rh0nj [~rh0nj@136.243.139.96] has joined #bitcoin-core-dev 23:18 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 260 seconds] 23:32 -!- jarthur [~jarthur@2605:6000:1019:41ab:f1a8:97f5:2e5c:9a90] has quit [] 23:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 23:49 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 23:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 23:51 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 23:58 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Ping timeout: 268 seconds] --- Log closed Fri Oct 19 00:00:41 2018