12018-10-18T00:00:10  *** Murch has quit IRC
   22018-10-18T00:03:46  *** jarthur has joined #bitcoin-core-dev
   32018-10-18T00:09:01  <promag> meshcollider: how are you testing #14478?
   42018-10-18T00:09:03  <gribble> https://github.com/bitcoin/bitcoin/issues/14478 | Show error to user when corrupt wallet unlock fails by MeshCollider · Pull Request #14478 · bitcoin/bitcoin · GitHub
   52018-10-18T00:09:14  <meshcollider> promag: I haven't tested it yet
   62018-10-18T00:09:20  *** michaelsdunn1 has joined #bitcoin-core-dev
   72018-10-18T00:09:21  <meshcollider> I will have to make a corrupt wallet somehow
   82018-10-18T00:09:32  <meshcollider> latest commit is WIP tho
   92018-10-18T00:11:09  <promag> you can fake CCryptoKeyStore::Unlock
  102018-10-18T00:11:31  *** josephnicholas has quit IRC
  112018-10-18T00:11:58  <promag> anyway for these changes a test guide would be nice
  122018-10-18T00:13:23  *** leishman has joined #bitcoin-core-dev
  132018-10-18T00:15:42  *** leishman has quit IRC
  142018-10-18T00:19:13  <promag> I'm dying with vcpkg install qt5..
  152018-10-18T00:26:03  *** Chris_Stewart_5 has quit IRC
  162018-10-18T00:28:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  172018-10-18T00:30:48  *** intcat has quit IRC
  182018-10-18T00:39:32  *** spinza has quit IRC
  192018-10-18T00:40:36  *** intcat has joined #bitcoin-core-dev
  202018-10-18T00:43:09  *** Chris_Stewart_5 has quit IRC
  212018-10-18T00:49:34  *** shesek has quit IRC
  222018-10-18T00:49:48  *** spinza has joined #bitcoin-core-dev
  232018-10-18T00:51:28  *** Murch has joined #bitcoin-core-dev
  242018-10-18T01:06:28  *** Murch has quit IRC
  252018-10-18T01:07:05  *** fanquake has joined #bitcoin-core-dev
  262018-10-18T01:08:02  *** rh0nj has quit IRC
  272018-10-18T01:09:09  *** rh0nj has joined #bitcoin-core-dev
  282018-10-18T01:09:45  <fanquake> cfields carldong fwiw I started collecting together the determinism cases we discussed at Core Dev, just for easy reference. Let me know if you want anything added, still some to add.
  292018-10-18T01:09:50  <fanquake> Notes are here: https://github.com/fanquake/core-review/blob/master/determinism.md
  302018-10-18T01:11:49  *** josephnicholas has joined #bitcoin-core-dev
  312018-10-18T01:12:39  *** hellobitnomics has joined #bitcoin-core-dev
  322018-10-18T01:13:14  *** shesek has joined #bitcoin-core-dev
  332018-10-18T01:13:14  *** shesek has joined #bitcoin-core-dev
  342018-10-18T01:14:17  *** hellobitnomics has quit IRC
  352018-10-18T01:16:19  *** jpe_ has joined #bitcoin-core-dev
  362018-10-18T01:19:16  *** jpe has quit IRC
  372018-10-18T01:32:30  *** fanquake has quit IRC
  382018-10-18T01:33:01  *** wumpus has quit IRC
  392018-10-18T01:34:48  *** coolpup is now known as coolcat
  402018-10-18T01:41:28  *** bitconner has quit IRC
  412018-10-18T01:45:49  *** josephnicholas has quit IRC
  422018-10-18T01:47:58  *** IceHard has quit IRC
  432018-10-18T01:58:53  *** fanquake has joined #bitcoin-core-dev
  442018-10-18T02:02:32  *** fanquake has quit IRC
  452018-10-18T02:10:15  *** justan0theruser has joined #bitcoin-core-dev
  462018-10-18T02:10:50  *** Aaronvan_ has quit IRC
  472018-10-18T02:11:15  *** bralyclow2 has joined #bitcoin-core-dev
  482018-10-18T02:11:48  *** justanotheruser has quit IRC
  492018-10-18T02:12:08  <meshcollider> dongcarl *
  502018-10-18T02:13:26  <dongcarl> fanquake: thank you, will take a look
  512018-10-18T02:14:20  *** bralyclow2 has quit IRC
  522018-10-18T02:29:39  *** coolcat is now known as coolpup
  532018-10-18T02:32:47  *** bitconner has joined #bitcoin-core-dev
  542018-10-18T02:37:30  *** bitconner has quit IRC
  552018-10-18T02:39:33  *** pkx1 has joined #bitcoin-core-dev
  562018-10-18T02:45:41  *** ken2812221_ has joined #bitcoin-core-dev
  572018-10-18T02:48:31  *** pkx1 has quit IRC
  582018-10-18T02:49:20  *** ken2812221__ has joined #bitcoin-core-dev
  592018-10-18T02:53:35  *** ken2812221_ has quit IRC
  602018-10-18T02:59:44  *** bralyclow2 has joined #bitcoin-core-dev
  612018-10-18T02:59:45  *** bralyclow2 has quit IRC
  622018-10-18T03:00:48  *** ken2812221 has quit IRC
  632018-10-18T03:01:03  *** ken2812221__ is now known as ken2812221
  642018-10-18T03:05:53  *** michaelsdunn1 has quit IRC
  652018-10-18T03:13:41  *** jarthur_ has joined #bitcoin-core-dev
  662018-10-18T03:16:33  *** ken2812221 has quit IRC
  672018-10-18T03:16:55  *** ken2812221 has joined #bitcoin-core-dev
  682018-10-18T03:18:16  *** jarthur_ has quit IRC
  692018-10-18T03:27:03  *** Krellan has quit IRC
  702018-10-18T03:28:16  *** Krellan has joined #bitcoin-core-dev
  712018-10-18T03:57:29  *** schnerch_ has joined #bitcoin-core-dev
  722018-10-18T04:00:16  *** booyah has quit IRC
  732018-10-18T04:00:19  *** schnerchi has quit IRC
  742018-10-18T04:22:51  *** booyah has joined #bitcoin-core-dev
  752018-10-18T04:33:46  *** bitcoin-git has joined #bitcoin-core-dev
  762018-10-18T04:33:46  <bitcoin-git> [bitcoin] kallewoof opened pull request #14507: net: avoid being disconnected from pruned nodes when syncing up (master...net-pruned-limit-requests) https://github.com/bitcoin/bitcoin/pull/14507
  772018-10-18T04:33:46  *** bitcoin-git has left #bitcoin-core-dev
  782018-10-18T04:39:36  <achow101> meshcollider: easy way to corrupt a wallet is to db_dump, change some bytes randomly, and then db_load to make the .dat file again
  792018-10-18T04:40:01  <achow101> I can make one for you
  802018-10-18T04:40:44  <meshcollider> achow101: ah yep, although promag is right, I could just force the code to throw the error anyway
  812018-10-18T04:41:01  <meshcollider> ill come back to that after the segwit importmulti stuff is done
  822018-10-18T04:41:57  <achow101> there's a bunch of failures involving corrupted wallets that we don't test. we could add a corrupted wallet to the test suite and then test those things
  832018-10-18T05:08:53  *** bralyclow has joined #bitcoin-core-dev
  842018-10-18T05:12:08  *** bralycl__ has quit IRC
  852018-10-18T05:13:45  *** bralyclo_ has joined #bitcoin-core-dev
  862018-10-18T05:16:09  *** bralyclow has quit IRC
  872018-10-18T05:28:38  *** booyah has quit IRC
  882018-10-18T05:29:14  *** booyah has joined #bitcoin-core-dev
  892018-10-18T05:32:15  *** josephnicholas has joined #bitcoin-core-dev
  902018-10-18T05:35:25  *** josephnicholas has quit IRC
  912018-10-18T05:35:44  *** jarthur has quit IRC
  922018-10-18T05:42:09  *** Krellan has quit IRC
  932018-10-18T05:43:14  *** Krellan has joined #bitcoin-core-dev
  942018-10-18T05:49:56  *** ken2812221 has quit IRC
  952018-10-18T06:37:53  *** wumpus has joined #bitcoin-core-dev
  962018-10-18T06:45:23  *** bitcoin-git has joined #bitcoin-core-dev
  972018-10-18T06:45:23  <bitcoin-git> [bitcoin] laanwj closed pull request #14370: utils and libraries: Allow values quoting in config files (master...20181002-config-quotes) https://github.com/bitcoin/bitcoin/pull/14370
  982018-10-18T06:45:23  *** bitcoin-git has left #bitcoin-core-dev
  992018-10-18T06:50:57  <promag> achow101: instead of adding a corrupted wallet, could add code to corrupt the wallet
 1002018-10-18T06:52:25  <promag> wumpus: I'd love to see 14291 reviewed
 1012018-10-18T06:55:15  <promag> wumpus: I think that optimisations could be added next if worth it, like caching results, pagination or ryanofsky suggestion
 1022018-10-18T06:56:35  <wumpus> 'code to corrupt the wallet' ehhh what about no :$
 1032018-10-18T06:57:49  <wumpus> that's, like, wiring a footgun to your program, or do you mean in the test framework?
 1042018-10-18T06:57:59  <wumpus> promag: ok
 1052018-10-18T06:58:45  <wumpus> promag: I don't really care about it being optimized, just it being correct and not interfering with other use of the file system
 1062018-10-18T06:58:52  <wumpus> promag: will re-review
 1072018-10-18T06:59:16  <promag> wumpus: thanks!
 1082018-10-18T06:59:57  <wumpus> so does it avoid nuking the lock now?
 1092018-10-18T07:01:03  <promag> yes https://github.com/bitcoin/bitcoin/pull/14291/files#diff-e802a36c28b0140bab62cb5366199656R38
 1102018-10-18T07:01:47  <wumpus> ohh that's neat
 1112018-10-18T07:02:14  *** ken2812221 has joined #bitcoin-core-dev
 1122018-10-18T07:02:26  <wumpus> (it's somewhat hard to review changes if you don't add commits but squash them)
 1132018-10-18T07:04:03  *** jungly has joined #bitcoin-core-dev
 1142018-10-18T07:04:45  <wumpus> the endianness thing is really a gothcha
 1152018-10-18T07:05:22  <promag> the last change was https://github.com/bitcoin/bitcoin/commit/743a3a9b20768519a11f54834d27fd7585a0670a <- I have to remove that #include though..
 1162018-10-18T07:05:43  <wumpus> thank you
 1172018-10-18T07:05:49  <promag> regarding endianness, I don't know what to do there
 1182018-10-18T07:06:03  <wumpus> add a comment as suggested
 1192018-10-18T07:06:19  *** setpill has joined #bitcoin-core-dev
 1202018-10-18T07:06:35  <wumpus> most people reading the code will be unaware of this fact, which is the best reason to add a useful comment
 1212018-10-18T07:07:01  <promag> wumpus: ok, going to take kids to school, I'll update when I get back
 1222018-10-18T07:07:06  <wumpus> thanks
 1232018-10-18T07:07:36  <wumpus> this is... telling, I don't suppose anyone ever used bitcoin on a big endian system
 1242018-10-18T07:07:40  <wumpus> at least not with wallet
 1252018-10-18T07:07:58  <wumpus> (and tried to copy the files from another system)
 1262018-10-18T07:08:18  <wumpus> please be really sure that this is really the case
 1272018-10-18T07:09:28  <wumpus> or does BDB *produce* native endian but *accept* either?
 1282018-10-18T07:09:42  <wumpus> in that case the code needs to check for both endiannesses
 1292018-10-18T07:09:46  <sipa> wumpus: that's my theory
 1302018-10-18T07:09:59  <sipa> it writes in native, but converts when the file is the other endianness
 1312018-10-18T07:10:17  <wumpus> right, that'd make some sense
 1322018-10-18T07:11:30  *** hebasto has quit IRC
 1332018-10-18T07:11:54  <wumpus> have certainly seen that before in file formats
 1342018-10-18T07:13:33  <promag> wumpus: nothing would go wrong anyway, it would give no wallets
 1352018-10-18T07:14:11  *** jarthur has joined #bitcoin-core-dev
 1362018-10-18T07:14:25  <wumpus> promag: I just want to be careful here and be sure of what we're doing
 1372018-10-18T07:14:35  <promag> wumpus: I can't virtualize different endianness right?
 1382018-10-18T07:15:27  <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
 1392018-10-18T07:18:47  *** jarthur has quit IRC
 1402018-10-18T07:19:36  <promag> ty, bbl
 1412018-10-18T07:19:46  *** ken2812221 has quit IRC
 1422018-10-18T07:20:11  *** promag has quit IRC
 1432018-10-18T07:22:42  *** ken2812221 has joined #bitcoin-core-dev
 1442018-10-18T07:24:02  *** Guyver2 has joined #bitcoin-core-dev
 1452018-10-18T07:24:49  <wumpus> promag: anyhow, no matter what the assumption is going to be, make sure it's documented in a comment
 1462018-10-18T07:25:18  <wumpus> it's IMO perfectly acceptable if you don't want to actually check this on a BE host
 1472018-10-18T07:25:34  <sipa> ... what actual BE systems exist these days?
 1482018-10-18T07:25:45  <wumpus> but if you make assumptions like that, anywhere, add a comment
 1492018-10-18T07:26:01  <sipa> i think our primary interest in being BE compatible is that it forces a degree of endian-neutrality on the code
 1502018-10-18T07:26:08  <sipa> not so much supporting actual systems
 1512018-10-18T07:26:21  <wumpus> yes, agree
 1522018-10-18T07:28:26  <sipa> Some current big-endian architectures include the IBM z/Architecture, Freescale ColdFire (which is Motorola 68000 series-based), Xilinx MicroBlaze, Atmel AVR32.
 1532018-10-18T07:28:30  <sipa> -- https://en.wikipedia.org/wiki/Endianness#Current_architectures
 1542018-10-18T07:28:40  <wumpus> being endian independent with regard to data files is good practice, no matter if there are any
 1552018-10-18T07:29:23  <gmaxwell> wumpus: it works fine on BE, I just never tried moving iles over.
 1562018-10-18T07:29:35  <gmaxwell> sipa: PPC is biendian now.
 1572018-10-18T07:29:44  <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)
 1582018-10-18T07:30:22  <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.
 1592018-10-18T07:30:35  <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
 1602018-10-18T07:30:48  <gmaxwell> Though BE power is both real and an actually interesting host to run bitcoin on.
 1612018-10-18T07:31:17  <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.
 1622018-10-18T07:31:17  <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
 1632018-10-18T07:31:21  <wumpus> right.
 1642018-10-18T07:32:13  <sipa> would be interesting to test with #14479 to see if the fee estimates files are compatible
 1652018-10-18T07:32:15  <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
 1662018-10-18T07:32:26  <gmaxwell> sipa: they won't be thats obvious.
 1672018-10-18T07:32:40  <gmaxwell> ( and I pointed that out on the PR )
 1682018-10-18T07:33:03  <sipa> gmaxwell: from what i've read since, is that most BE systems actually store IEEE floats in byteswapped form
 1692018-10-18T07:33:15  <sipa> as IEEE 754 only specifies the bit encoding
 1702018-10-18T07:33:23  <sipa> not how to store the bytes
 1712018-10-18T07:34:42  <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
 1722018-10-18T07:36:06  <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
 1732018-10-18T07:36:21  *** jarthur has joined #bitcoin-core-dev
 1742018-10-18T07:36:27  <wumpus> of course making that assumption without checking it is a bad idea
 1752018-10-18T07:37:11  <sipa> but for example Boost.Endian intentionally does not support encoding floats because there is no guaranteed consistency
 1762018-10-18T07:37:33  <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.
 1772018-10-18T07:37:58  <wumpus> I think it would be perfectly OK to just add a check to the build system
 1782018-10-18T07:38:20  <wumpus> and fail if the architecture doesn't match the current assumption
 1792018-10-18T07:38:20  <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))
 1802018-10-18T07:38:45  <gmaxwell> We should probably just avoid serializing floats at all.
 1812018-10-18T07:38:50  <sipa> yes, absolutely
 1822018-10-18T07:39:01  <wumpus> we don't have to handle everything, certainly not every possible historical architecture, but do need to be explicit about it
 1832018-10-18T07:39:03  <gmaxwell> There is no particular need to, this decay thing in fact just uses the float to store one of three values.
 1842018-10-18T07:39:22  <sipa> afaik indeed; i haven't checked in detail
 1852018-10-18T07:39:28  <gmaxwell> (in general floats, like strings, are a source of fun bugs in many cases.)
 1862018-10-18T07:39:41  <sipa> so we could just hardcode the 8-byte serializations, and encode those
 1872018-10-18T07:39:44  <gmaxwell> (e.g. when A != A due to !@#! nan and your code infinite loops)
 1882018-10-18T07:39:47  <sipa> and switch when decode
 1892018-10-18T07:39:49  <wumpus> yes, like using signalling NaNs in binary protocols to crash MMO servers :-)
 1902018-10-18T07:40:00  <gmaxwell> or that
 1912018-10-18T07:40:25  <gmaxwell> or float code that dorks with the rounding rule registers and then breaks OTHER float code.
 1922018-10-18T07:40:49  <wumpus> yes, indeed
 1932018-10-18T07:41:16  <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.
 1942018-10-18T07:41:21  *** jarthur has quit IRC
 1952018-10-18T07:41:34  <gmaxwell> but in general our usage of float should be pretty sparing.
 1962018-10-18T07:41:37  <wumpus> I'm still scared about using floats for monetary values at all, but yes
 1972018-10-18T07:43:34  <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
 1982018-10-18T07:45:09  <gmaxwell> (or someone compiles with -Ofast and then all your careful float code behaves different because of the compiler treating them like reals)
 1992018-10-18T07:45:18  <wumpus> with regard to the file format, we could certainly have prevented encoding the values directly as float
 2002018-10-18T07:45:49  <sipa> it seems that before fee_estimates.dat, we never used the float serialization code at all
 2012018-10-18T07:45:56  <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
 2022018-10-18T07:45:57  <wumpus> they're limited range so quantizing it to 64 bits would likely have been ok
 2032018-10-18T07:47:02  <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.
 2042018-10-18T07:47:21  <wumpus> aanyhow, I think not worth breaking backwards compatibily for this
 2052018-10-18T07:47:40  <wumpus> gmaxwell: it's true, but at least it'd be deterministic / arch independent so easier to be confident about... but yeah
 2062018-10-18T07:47:55  <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.
 2072018-10-18T07:48:04  <gmaxwell> I don't mind breaking compat on BE.
 2082018-10-18T07:48:27  <gmaxwell> presumably fee estimates format is gonna change in not enormous amounts of time anyways.
 2092018-10-18T07:48:48  <gmaxwell> though we should probably eliminate any generic float serialization before some other goof is added. :)
 2102018-10-18T07:48:53  <wumpus> I think that's good, it's something to write down for the next time the format has to change anyway
 2112018-10-18T07:49:07  <sipa> gmaxwell: but currently the code is compatible for systems that store both floats and ints in the same endianness
 2122018-10-18T07:49:36  <sipa> so we can just replace it with byte matches, and it shouldn't break anything
 2132018-10-18T07:50:30  <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
 2142018-10-18T07:50:45  <sipa> it doesn't sound like much work at all
 2152018-10-18T07:51:16  <wumpus> at the time it was more work than I expected
 2162018-10-18T07:51:39  <sipa> when was fee_estimates.dat introduced?
 2172018-10-18T07:51:41  <sipa> 0.12 ish?
 2182018-10-18T07:52:10  <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
 2192018-10-18T07:52:23  <wumpus> but I don't remember specifics, I'm not the best versed in C++ template magic
 2202018-10-18T07:52:23  <sipa> ah, yes
 2212018-10-18T07:52:32  <sipa> you'd need forward declares and stuff
 2222018-10-18T07:52:56  <wumpus> right
 2232018-10-18T07:55:26  *** bitcoin-git has joined #bitcoin-core-dev
 2242018-10-18T07:55:26  *** Krellan has quit IRC
 2252018-10-18T07:55:27  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/816fab9ccae5...041224a75c16
 2262018-10-18T07:55:27  <bitcoin-git> bitcoin/master d562027 Sjors Provoost: [doc] getblocktemplate: use SegWit in example
 2272018-10-18T07:55:28  <bitcoin-git> bitcoin/master 041224a Wladimir J. van der Laan: Merge #14472: [doc] getblocktemplate: use SegWit in example...
 2282018-10-18T07:55:28  *** bitcoin-git has left #bitcoin-core-dev
 2292018-10-18T07:56:34  *** bitcoin-git has joined #bitcoin-core-dev
 2302018-10-18T07:56:35  <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
 2312018-10-18T07:56:35  *** bitcoin-git has left #bitcoin-core-dev
 2322018-10-18T07:56:35  *** Krellan has joined #bitcoin-core-dev
 2332018-10-18T07:56:50  <wumpus> sipa: acc. to release notes, fee_estimates.dat was introduced in 0.10
 2342018-10-18T07:57:28  <sipa> ah
 2352018-10-18T08:02:07  *** ken2812221 has quit IRC
 2362018-10-18T08:02:35  *** ken2812221 has joined #bitcoin-core-dev
 2372018-10-18T08:07:44  <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
 2382018-10-18T08:08:05  <wumpus> I tried that once...
 2392018-10-18T08:08:11  <karelb> there are workarounds around that, but it's still annoying
 2402018-10-18T08:08:20  <sipa> karelb: you have no idea how often this comes up :)
 2412018-10-18T08:08:21  *** bitcoin-git has joined #bitcoin-core-dev
 2422018-10-18T08:08:21  <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
 2432018-10-18T08:08:21  *** bitcoin-git has left #bitcoin-core-dev
 2442018-10-18T08:08:28  <karelb> wumpus: ahh, with what result?
 2452018-10-18T08:08:36  <karelb> sipa hahaha ok
 2462018-10-18T08:08:50  <wumpus> karelb: people didn't really care ,even the ones that brought it up in the first place
 2472018-10-18T08:08:52  <sipa> it always turns into a bikeshedding over redesigning the entire RPC interface
 2482018-10-18T08:08:55  <wumpus> yess and that
 2492018-10-18T08:08:57  <karelb> ..  oh
 2502018-10-18T08:09:14  <wumpus> we already *accept* strings for amounts, btw
 2512018-10-18T08:09:21  <sipa> also (and i'm aware this is somewhat pedantic), JSON doesn't having a concept of floating point
 2522018-10-18T08:09:25  <sipa> it has numbers
 2532018-10-18T08:09:30  <wumpus> but this is just not worth changing at this point, I think...
 2542018-10-18T08:10:00  <wumpus> everyone who cared back in the day will have their own specific JSON parser for interfacing to bitcoind now
 2552018-10-18T08:10:09  <wumpus> it's just, solved at the client side
 2562018-10-18T08:10:38  <wumpus> and sipa is right too—for everyone's sanity, please just leave this be
 2572018-10-18T08:10:55  <karelb> :D
 2582018-10-18T08:12:21  <karelb> ok thx for info. we are not alone in thinking that it's annoying though. good to know :)
 2592018-10-18T08:12:34  <wumpus> there are literally hundreds of actual user issues reported that need to be solved
 2602018-10-18T08:14:27  <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 </topic>
 2612018-10-18T08:17:15  <wumpus> did we scare away this person with the sheer number of comments on such a small patch #14125
 2622018-10-18T08:17:18  <gribble> https://github.com/bitcoin/bitcoin/issues/14125 | Add testcase to simulate bitcoin schema in leveldb by MapleLaker · Pull Request #14125 · bitcoin/bitcoin · GitHub
 2632018-10-18T08:17:21  <kallewoof> TBH, using floats is insane. *shrug*
 2642018-10-18T08:17:31  <wumpus> the world, is insane
 2652018-10-18T08:17:34  <sipa> karelb: also, inside bitcoin core there no conversion of amounts to floats ever (except feerates), even to convert to JSON
 2662018-10-18T08:17:47  <kallewoof> wumpus: we could make it less so or contribute to its insanity lol
 2672018-10-18T08:17:53  *** Guyver2 has quit IRC
 2682018-10-18T08:18:12  <wumpus> kallewoof: what if every initiative tom ake it more sane actually makes it more insane
 2692018-10-18T08:18:13  <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*)
 2702018-10-18T08:18:28  <kallewoof> Yeah... there's that.
 2712018-10-18T08:18:33  <wumpus> omg .. please
 2722018-10-18T08:18:34  <wumpus> STOP
 2732018-10-18T08:19:13  <sipa> saying... sure :)
 2742018-10-18T08:19:14  <kallewoof> I apparently stepped on something. My apologies, I'll shut up now.
 2752018-10-18T08:19:30  <karelb> (why solve hard issues when you can bikeshed interfaces :)) ok got you
 2762018-10-18T08:20:59  <karelb> I will add this to "weird stuff Bitcoin does for backwards compatibility reasons", just next to the endian switching
 2772018-10-18T08:21:33  <sipa> bitcoin uses little endian everywhere, except when presenting things for human consumption :)
 2782018-10-18T08:21:51  <sipa> (and inside sha256 which you should treat as a black box that converts bytes to bytes)
 2792018-10-18T08:23:10  <wumpus> sipa: I think that's what makes him right in that it is a similar thing; just the interface
 2802018-10-18T08:24:04  <sipa> fair
 2812018-10-18T08:24:08  <wumpus> over the years, people have adopted to this convention, even though the convention itself might or might not make sense has become irrelevant
 2822018-10-18T08:25:08  <sipa> i'm just suffering from stockholm syndrome, trying to defend the original reasoning behind the convention which is now completely irrelevant :)
 2832018-10-18T08:25:25  <wumpus> indeed :)
 2842018-10-18T08:26:11  <karelb> well that's what I think about as "backwards compatibility" :)
 2852018-10-18T08:27:26  <wumpus> though I mean, it might still be interesting to know how something got a certain way for historical reasons
 2862018-10-18T08:27:55  *** shesek has quit IRC
 2872018-10-18T08:27:57  <wumpus> yes
 2882018-10-18T08:30:09  <sipa> meshcollider: in the P2WSH-multisig test in 14454 you're only importing one of the two private keys
 2892018-10-18T08:30:28  <sipa> if i change it to have both, i expect the result to become ismine:true, but it doesn't
 2902018-10-18T08:30:57  <meshcollider> sipa: the ismine logic never treats a multisig as mine
 2912018-10-18T08:31:00  <meshcollider> even if we have all the keys
 2922018-10-18T08:31:14  *** bitconner has joined #bitcoin-core-dev
 2932018-10-18T08:31:19  <meshcollider> thats unrelated to this PR, maybe a fault there though
 2942018-10-18T08:31:31  <sipa> meshcollider: yes it does?
 2952018-10-18T08:31:38  <sipa> if you have all the private keys
 2962018-10-18T08:32:34  <sipa> not bare multisig, though
 2972018-10-18T08:32:40  <meshcollider> Oh I must be thinking of bare multisig
 2982018-10-18T08:32:41  <sipa> but P2WSH-multisig, i don't see why not
 2992018-10-18T08:32:47  <meshcollider> hmm
 3002018-10-18T08:33:45  *** ken2812221 has quit IRC
 3012018-10-18T08:34:18  <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)
 3022018-10-18T08:35:27  *** bitconner has quit IRC
 3032018-10-18T08:37:31  *** bitcoin-git has joined #bitcoin-core-dev
 3042018-10-18T08:37:32  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/041224a75c16...9c5f0d542d1d
 3052018-10-18T08:37:32  <bitcoin-git> bitcoin/master 86eb3b3 Chun Kuan Lee: utils: Add fsbridge fstream function wrapper
 3062018-10-18T08:37:33  <bitcoin-git> bitcoin/master a554cc9 Chun Kuan Lee: Move boost/std fstream to fsbridge
 3072018-10-18T08:37:33  <bitcoin-git> bitcoin/master f86a571 Chun Kuan Lee: tests: Add test case for std::ios_base::ate
 3082018-10-18T08:37:34  *** bitcoin-git has left #bitcoin-core-dev
 3092018-10-18T08:38:13  *** bitcoin-git has joined #bitcoin-core-dev
 3102018-10-18T08:38:14  <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
 3112018-10-18T08:38:14  *** bitcoin-git has left #bitcoin-core-dev
 3122018-10-18T08:40:31  <meshcollider> indeed that's confusing
 3132018-10-18T08:43:25  * sipa needs sleep
 3142018-10-18T08:46:49  <wumpus> goodnight sipa
 3152018-10-18T08:49:41  *** timothy has joined #bitcoin-core-dev
 3162018-10-18T08:50:39  *** promag has joined #bitcoin-core-dev
 3172018-10-18T08:59:28  *** bitcoin-git has joined #bitcoin-core-dev
 3182018-10-18T08:59:28  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/9c5f0d542d1d...d98777f302e1
 3192018-10-18T08:59:29  <bitcoin-git> bitcoin/master ea3009e Pierre Rochard: wallet: Add walletdir arg unit tests
 3202018-10-18T08:59:29  <bitcoin-git> bitcoin/master 2d47163 Pierre Rochard: wallet: Remove trailing separators from -walletdir arg
 3212018-10-18T08:59:30  <bitcoin-git> bitcoin/master d98777f Wladimir J. van der Laan: Merge #14146: wallet: Remove trailing separators from -walletdir arg...
 3222018-10-18T08:59:30  *** bitcoin-git has left #bitcoin-core-dev
 3232018-10-18T09:00:22  *** bitcoin-git has joined #bitcoin-core-dev
 3242018-10-18T09:00:22  <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
 3252018-10-18T09:00:22  *** bitcoin-git has left #bitcoin-core-dev
 3262018-10-18T09:04:15  *** shesek has joined #bitcoin-core-dev
 3272018-10-18T09:04:15  *** shesek has joined #bitcoin-core-dev
 3282018-10-18T09:06:29  <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?
 3292018-10-18T09:08:45  <promag> so I should just replace memcmp with uint32_t != uint32_t?
 3302018-10-18T09:09:03  *** ken2812221 has joined #bitcoin-core-dev
 3312018-10-18T09:29:25  *** bitcoin-git has joined #bitcoin-core-dev
 3322018-10-18T09:29:26  <bitcoin-git> [bitcoin] practicalswift opened pull request #14510: Avoid triggering undefined behaviour in base_uint<BITS>::bits() (master...1<<31) https://github.com/bitcoin/bitcoin/pull/14510
 3332018-10-18T09:29:26  *** bitcoin-git has left #bitcoin-core-dev
 3342018-10-18T09:37:35  *** jarthur has joined #bitcoin-core-dev
 3352018-10-18T09:42:30  *** jarthur has quit IRC
 3362018-10-18T09:42:44  <promag> I think https://github.com/bitcoin/bitcoin/pull/14291/commits/21c475119949f0fde0a478e4f3ad301c5be0c497 would work in both endianness
 3372018-10-18T09:46:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 3382018-10-18T09:58:42  <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
 3392018-10-18T09:59:33  *** ken2812221 has quit IRC
 3402018-10-18T10:03:02  *** Krellan has quit IRC
 3412018-10-18T10:03:08  <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
 3422018-10-18T10:03:25  <wumpus> I don't think always comparing against  the LE value even on BE-native systems makes sense
 3432018-10-18T10:03:38  <wumpus> as it means they won't see their native wallets
 3442018-10-18T10:03:45  <wumpus> which is worse than not seeing ported ones
 3452018-10-18T10:06:59  *** Krellan has joined #bitcoin-core-dev
 3462018-10-18T10:10:07  *** drexl has quit IRC
 3472018-10-18T10:12:41  *** ken2812221 has joined #bitcoin-core-dev
 3482018-10-18T10:26:50  *** bitcoin-git has joined #bitcoin-core-dev
 3492018-10-18T10:26:50  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d98777f302e1...32c5f188d4fd
 3502018-10-18T10:26:51  <bitcoin-git> bitcoin/master b0510d7 Hennadii Stepanov: Set C locale for amountWidget...
 3512018-10-18T10:26:51  <bitcoin-git> bitcoin/master 32c5f18 Wladimir J. van der Laan: Merge #14177: qt: Set C locale for amountWidget...
 3522018-10-18T10:26:52  *** bitcoin-git has left #bitcoin-core-dev
 3532018-10-18T10:27:40  *** bitcoin-git has joined #bitcoin-core-dev
 3542018-10-18T10:27:40  <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
 3552018-10-18T10:27:40  *** bitcoin-git has left #bitcoin-core-dev
 3562018-10-18T10:30:57  <luke-jr> ugh, bdb isn't endian-independent? -.-
 3572018-10-18T10:31:45  *** bitcoin-git has joined #bitcoin-core-dev
 3582018-10-18T10:31:46  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/32c5f188d4fd...fe23553edd84
 3592018-10-18T10:31:47  <bitcoin-git> bitcoin/master 3045704 Hennadii Stepanov: Add "Blocksdir" to Debug window...
 3602018-10-18T10:31:47  <bitcoin-git> bitcoin/master 2ab9140 Hennadii Stepanov: Add tooltips for both datadir and blocksdir
 3612018-10-18T10:31:47  <bitcoin-git> bitcoin/master fe23553 Wladimir J. van der Laan: Merge #14374: qt: Add "Blocksdir" to Debug window...
 3622018-10-18T10:31:48  *** bitcoin-git has left #bitcoin-core-dev
 3632018-10-18T10:32:44  *** bitcoin-git has joined #bitcoin-core-dev
 3642018-10-18T10:32:44  <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
 3652018-10-18T10:32:44  *** bitcoin-git has left #bitcoin-core-dev
 3662018-10-18T10:34:09  *** AaronvanW has joined #bitcoin-core-dev
 3672018-10-18T10:37:41  *** ken2812221 has quit IRC
 3682018-10-18T10:38:13  *** ken2812221 has joined #bitcoin-core-dev
 3692018-10-18T10:46:36  *** jarthur has joined #bitcoin-core-dev
 3702018-10-18T10:51:08  *** jarthur has quit IRC
 3712018-10-18T10:52:39  *** AaronvanW has quit IRC
 3722018-10-18T10:53:13  *** AaronvanW has joined #bitcoin-core-dev
 3732018-10-18T10:58:08  *** AaronvanW has quit IRC
 3742018-10-18T11:02:21  *** bitcoin-git has joined #bitcoin-core-dev
 3752018-10-18T11:02:21  <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
 3762018-10-18T11:02:21  *** bitcoin-git has left #bitcoin-core-dev
 3772018-10-18T11:03:23  *** Chris_Stewart_5 has quit IRC
 3782018-10-18T11:05:17  *** hebasto has joined #bitcoin-core-dev
 3792018-10-18T11:06:12  *** hebasto has quit IRC
 3802018-10-18T11:06:32  *** hebasto has joined #bitcoin-core-dev
 3812018-10-18T11:14:42  *** Zenton has quit IRC
 3822018-10-18T11:14:49  *** Zenton has joined #bitcoin-core-dev
 3832018-10-18T11:17:39  <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 ?
 3842018-10-18T11:18:34  <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)
 3852018-10-18T11:23:42  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 3862018-10-18T11:25:24  *** ken2812221 has joined #bitcoin-core-dev
 3872018-10-18T11:37:52  *** Chris_Stewart_5 has quit IRC
 3882018-10-18T11:38:33  *** jarthur has joined #bitcoin-core-dev
 3892018-10-18T11:43:20  *** jarthur has quit IRC
 3902018-10-18T11:58:40  *** drexl has joined #bitcoin-core-dev
 3912018-10-18T12:08:26  <promag> wumpus: see https://github.com/bitcoin/bitcoin/pull/14291/commits/b791ef12c3605c185432e391e1571853b07a7441
 3922018-10-18T12:12:31  *** Krellan has quit IRC
 3932018-10-18T12:17:32  *** AaronvanW has joined #bitcoin-core-dev
 3942018-10-18T12:17:32  *** Krellan has joined #bitcoin-core-dev
 3952018-10-18T12:21:45  *** bitcoin-git has joined #bitcoin-core-dev
 3962018-10-18T12:21:45  <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
 3972018-10-18T12:21:45  *** bitcoin-git has left #bitcoin-core-dev
 3982018-10-18T12:30:32  *** bitconner has joined #bitcoin-core-dev
 3992018-10-18T12:34:41  *** bitconner has quit IRC
 4002018-10-18T12:36:12  *** hebasto has quit IRC
 4012018-10-18T12:36:32  *** hebasto has joined #bitcoin-core-dev
 4022018-10-18T12:41:23  *** klot has joined #bitcoin-core-dev
 4032018-10-18T12:42:09  *** klot has quit IRC
 4042018-10-18T12:42:35  *** klot has joined #bitcoin-core-dev
 4052018-10-18T12:43:39  *** klot has quit IRC
 4062018-10-18T12:44:06  *** klot has joined #bitcoin-core-dev
 4072018-10-18T12:45:10  *** klot has quit IRC
 4082018-10-18T12:45:41  *** klot has joined #bitcoin-core-dev
 4092018-10-18T12:51:21  *** bitcoin-git has joined #bitcoin-core-dev
 4102018-10-18T12:51:21  <bitcoin-git> [bitcoin] merland opened pull request #14512: Textual improvements (master...merland-patch-2) https://github.com/bitcoin/bitcoin/pull/14512
 4112018-10-18T12:51:21  *** bitcoin-git has left #bitcoin-core-dev
 4122018-10-18T13:02:34  *** setpill has quit IRC
 4132018-10-18T13:05:36  *** AaronvanW has quit IRC
 4142018-10-18T13:06:05  *** AaronvanW has joined #bitcoin-core-dev
 4152018-10-18T13:07:43  *** drexl has quit IRC
 4162018-10-18T13:10:36  *** AaronvanW has quit IRC
 4172018-10-18T13:10:48  *** SopaXorzTaker has joined #bitcoin-core-dev
 4182018-10-18T13:17:07  *** drexl has joined #bitcoin-core-dev
 4192018-10-18T13:23:18  *** promag has quit IRC
 4202018-10-18T13:38:47  *** promag has joined #bitcoin-core-dev
 4212018-10-18T13:39:26  *** jarthur has joined #bitcoin-core-dev
 4222018-10-18T13:44:01  *** jarthur has quit IRC
 4232018-10-18T13:49:33  *** promag has quit IRC
 4242018-10-18T13:56:29  <wumpus> promag: LGTM
 4252018-10-18T14:12:32  *** BladeZero has joined #bitcoin-core-dev
 4262018-10-18T14:12:56  <BladeZero> Hey dudes.  Want a Torrentleech invite for free?
 4272018-10-18T14:15:57  *** AhNo1 has joined #bitcoin-core-dev
 4282018-10-18T14:17:20  <BladeZero> fo free
 4292018-10-18T14:17:29  <BladeZero> What's your e-mail right now?
 4302018-10-18T14:17:42  *** AhNo1 has quit IRC
 4312018-10-18T14:22:25  *** AhNo1 has joined #bitcoin-core-dev
 4322018-10-18T14:26:39  *** ChanServ sets mode: +o wumpus
 4332018-10-18T14:27:13  *** wumpus sets mode: +b *!*o@207.244.82.194
 4342018-10-18T14:27:18  *** wumpus sets mode: +b *!*@207.244.82.194
 4352018-10-18T14:27:20  *** BladeZero was kicked by wumpus (BladeZero)
 4362018-10-18T14:27:28  *** wumpus sets mode: -b *!*o@207.244.82.194
 4372018-10-18T14:30:47  *** bitconner has joined #bitcoin-core-dev
 4382018-10-18T14:39:04  *** SopaXorzTaker has quit IRC
 4392018-10-18T14:39:39  *** bitconner has quit IRC
 4402018-10-18T14:46:55  *** michaelsdunn1 has joined #bitcoin-core-dev
 4412018-10-18T14:49:16  *** AhNo1 has quit IRC
 4422018-10-18T14:57:58  *** promag has joined #bitcoin-core-dev
 4432018-10-18T14:58:50  <promag> wumpus: can I squash 14291?
 4442018-10-18T15:01:08  *** drexl has quit IRC
 4452018-10-18T15:06:08  *** drexl has joined #bitcoin-core-dev
 4462018-10-18T15:06:23  <wumpus> depends on wheter other people want to review the changes commit by commit I guess?
 4472018-10-18T15:06:38  <wumpus> I don't think squashing too often is good
 4482018-10-18T15:07:09  *** ChanServ sets mode: -o wumpus
 4492018-10-18T15:07:23  <promag> ok, I'll just wait then
 4502018-10-18T15:07:24  <luke-jr> I assume he means the fixup!s, not everything :p
 4512018-10-18T15:07:43  <wumpus> yes, I understood that :p
 4522018-10-18T15:11:09  *** promag has quit IRC
 4532018-10-18T15:12:56  <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
 4542018-10-18T15:16:28  *** bitcoin-git has joined #bitcoin-core-dev
 4552018-10-18T15:16:29  <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
 4562018-10-18T15:16:29  *** bitcoin-git has left #bitcoin-core-dev
 4572018-10-18T15:18:14  *** IceHard has joined #bitcoin-core-dev
 4582018-10-18T15:28:00  *** jarthur has joined #bitcoin-core-dev
 4592018-10-18T15:49:53  *** ExtraCrispy has joined #bitcoin-core-dev
 4602018-10-18T15:56:18  *** AM5800 has joined #bitcoin-core-dev
 4612018-10-18T16:03:23  *** IceHard has quit IRC
 4622018-10-18T16:26:58  *** IceHard has joined #bitcoin-core-dev
 4632018-10-18T16:29:19  *** Victorsueca has quit IRC
 4642018-10-18T16:29:24  <IceHard> hello all :))))))
 4652018-10-18T16:30:35  *** Victorsueca has joined #bitcoin-core-dev
 4662018-10-18T16:33:16  *** Krellan has quit IRC
 4672018-10-18T16:35:46  *** Krellan has joined #bitcoin-core-dev
 4682018-10-18T16:36:07  *** promag has joined #bitcoin-core-dev
 4692018-10-18T16:36:54  *** AaronvanW has joined #bitcoin-core-dev
 4702018-10-18T16:36:56  <promag> wumpus: ^ noted
 4712018-10-18T16:37:15  *** AM5800 has quit IRC
 4722018-10-18T16:55:30  *** AaronvanW has quit IRC
 4732018-10-18T16:57:13  <instagibbs> hm is --enable-debug not enough to avoid "value has been optimized out" anymore?
 4742018-10-18T16:57:15  *** promag has quit IRC
 4752018-10-18T16:57:33  *** jungly has quit IRC
 4762018-10-18T16:58:38  <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.
 4772018-10-18T16:59:10  <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
 4782018-10-18T17:03:05  <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
 4792018-10-18T17:03:21  <wumpus> (and yes, even with that you can still get that ...)
 4802018-10-18T17:07:37  <sipa> i don't think i've ever seen <value optimized out> at -O0
 4812018-10-18T17:08:42  <gmaxwell> 01:07:44 < karelb> thinking out loud- yesterday we talked with colleague how we hate that JSON RPC returns BTC values as floats. (
 4822018-10-18T17:08:49  <gmaxwell> karelb: the json rpc values ARE NOT FLOATS
 4832018-10-18T17:09:55  <gmaxwell> json spec defines those values as "numbers" which have exact precision.  it's up to implementations how they represent them.
 4842018-10-18T17:10:11  <gmaxwell> in Bitcoin core they're just 64 bit integers.
 4852018-10-18T17:11:18  <karelb> I didn't read json spec, isn't json spec supposed to compatible with JavaScript, which will interpret that as floating point?
 4862018-10-18T17:12:48  <gmaxwell> karelb: no, as wikipedia says, "Numbers in JSON are agnostic with regard to their representation within programming languages."
 4872018-10-18T17:13:01  <wumpus> no, json spec does not refer to the javascript spec
 4882018-10-18T17:13:30  <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
 4892018-10-18T17:13:47  <wumpus> it's entirely self contained and very short, you should read it
 4902018-10-18T17:13:51  <karelb> I thought json is supposed to be a strict subset of JS. ok I was wrong
 4912018-10-18T17:14:16  <wumpus> as any format spec it only describes the *syntax* not how things should be stored
 4922018-10-18T17:14:20  <gmaxwell> since JS accepts random stuff and does random stuff with it, I suppose this IRC log is a strict subset of js. :P
 4932018-10-18T17:14:29  <wumpus> hehe exactly
 4942018-10-18T17:14:44  <karelb> 🙂
 4952018-10-18T17:15:21  <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.
 4962018-10-18T17:17:06  *** Krellan has quit IRC
 4972018-10-18T17:18:16  <karelb> ... oh json spec is really deadly simple
 4982018-10-18T17:19:20  *** Tralfaz has joined #bitcoin-core-dev
 4992018-10-18T17:20:51  <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
 5002018-10-18T17:21:41  <wumpus> ok that wasn't really directed at gmaxwell
 5012018-10-18T17:22:31  *** Krellan has joined #bitcoin-core-dev
 5022018-10-18T17:32:16  *** Krellan has quit IRC
 5032018-10-18T17:33:22  *** IceHard has quit IRC
 5042018-10-18T17:43:02  *** Krellan has joined #bitcoin-core-dev
 5052018-10-18T17:49:18  *** Murch has joined #bitcoin-core-dev
 5062018-10-18T17:55:19  *** AaronvanW has joined #bitcoin-core-dev
 5072018-10-18T18:01:53  <phantomcircuit> gmaxwell, iirc even if they are floats they're not in a range where it would be an issue
 5082018-10-18T18:05:12  <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
 5092018-10-18T18:06:22  <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.
 5102018-10-18T18:10:11  *** Krellan has quit IRC
 5112018-10-18T18:10:49  <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
 5122018-10-18T18:12:05  <wumpus> yes the different ECMA standards are slighly different in that regard
 5132018-10-18T18:15:59  <wumpus> 'javascript' itself is ambigious, though, none of that reflects on JSON which is well-defined
 5142018-10-18T18:16:00  <phantomcircuit> gmaxwell, iirc basically all js implementations are double right?
 5152018-10-18T18:17:01  <andytoshi> yes, but the problem is that a lot of json parsers do stupid things and lose accuracy anyway
 5162018-10-18T18:21:02  *** rh0nj has quit IRC
 5172018-10-18T18:22:12  *** rh0nj has joined #bitcoin-core-dev
 5182018-10-18T18:28:18  <phantomcircuit> andytoshi, yeah i guess that's the real thing
 5192018-10-18T18:28:21  *** promag has joined #bitcoin-core-dev
 5202018-10-18T18:30:49  *** promag has quit IRC
 5212018-10-18T18:35:57  <wumpus> yes, off-by-ones are pretty common
 5222018-10-18T18:37:23  <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
 5232018-10-18T18:37:50  <wumpus> (floats of any precision)
 5242018-10-18T18:41:21  *** Guyver2 has joined #bitcoin-core-dev
 5252018-10-18T18:41:23  * wumpus wishes any of the common serialization formats had a decimal type
 5262018-10-18T18:41:31  <wumpus> an explicit one, I mean
 5272018-10-18T18:43:09  <luke-jr> decimal sucks though :p
 5282018-10-18T18:43:39  *** AaronvanW has quit IRC
 5292018-10-18T18:43:54  <gmaxwell> phantomcircuit: the old json library bitcoin used to use randomly inserted conversions to float in a minor upgrade!
 5302018-10-18T18:43:55  <wumpus> for better or worse it's the choice for monetary values
 5312018-10-18T18:44:39  <phantomcircuit> gmaxwell, :/
 5322018-10-18T18:45:13  <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
 5332018-10-18T18:56:31  *** clarkmoody has joined #bitcoin-core-dev
 5342018-10-18T18:59:21  *** promag has joined #bitcoin-core-dev
 5352018-10-18T19:00:45  <luke-jr> hi?
 5362018-10-18T19:01:20  <BlueMatt> mtg?
 5372018-10-18T19:01:38  <sipa> ohai
 5382018-10-18T19:02:05  <gmaxwell> ??!?
 5392018-10-18T19:02:06  <achow101> hi
 5402018-10-18T19:02:08  <gleb> hi
 5412018-10-18T19:02:09  <luke-jr> ohayo
 5422018-10-18T19:02:16  <jonasschnelli> hi
 5432018-10-18T19:02:27  <BlueMatt> wherefor art thou wumpus
 5442018-10-18T19:02:39  <sipa> we need to hunt the wumpus
 5452018-10-18T19:03:06  <luke-jr> do we hunt the wumpus with nuclear, DDoS, or 51% attack?
 5462018-10-18T19:03:07  <BlueMatt> dont hunt wumpus :O
 5472018-10-18T19:03:10  <promag> hi
 5482018-10-18T19:04:02  * luke-jr drops a hat on BlueMatt's head?
 5492018-10-18T19:04:07  <jonasschnelli> #startmeeting
 5502018-10-18T19:04:07  <lightningbot> Meeting started Thu Oct 18 19:04:07 2018 UTC.  The chair is jonasschnelli. Information about MeetBot at http://wiki.debian.org/MeetBot.
 5512018-10-18T19:04:07  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 5522018-10-18T19:04:13  <jonasschnelli> Topics?
 5532018-10-18T19:04:15  <wumpus> hello
 5542018-10-18T19:04:23  *** rex4539 has joined #bitcoin-core-dev
 5552018-10-18T19:04:28  <luke-jr> there he is
 5562018-10-18T19:05:01  *** belcher has quit IRC
 5572018-10-18T19:05:05  <jnewbery> hi
 5582018-10-18T19:05:16  <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
 5592018-10-18T19:06:03  <meshcollider> hi
 5602018-10-18T19:06:30  <promag> topics suggestion, (remove?) address book
 5612018-10-18T19:06:35  <jonasschnelli> #topic high priority list
 5622018-10-18T19:06:36  <jonasschnelli> https://github.com/bitcoin/bitcoin/projects/8
 5632018-10-18T19:06:42  <jonasschnelli> anything to add / del?
 5642018-10-18T19:06:52  <instagibbs> hi
 5652018-10-18T19:07:11  <wumpus> ListWalletDir is pretty much mergeable, needs sign-off on the last change
 5662018-10-18T19:08:03  *** lnostdal has quit IRC
 5672018-10-18T19:08:04  <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
 5682018-10-18T19:08:12  *** Krellan has joined #bitcoin-core-dev
 5692018-10-18T19:08:24  <wumpus> (most likely they are and it's smart enough to interpret databases in alt endian)
 5702018-10-18T19:08:30  <gmaxwell> wumpus: I'll test sometime in the next couple days, I'm pretty sure that it'll just convert it.
 5712018-10-18T19:08:31  *** AaronvanW has joined #bitcoin-core-dev
 5722018-10-18T19:08:37  <promag> jonasschnelli: I don't mind replacing 14291 with 14350
 5732018-10-18T19:08:43  <sipa> i'd like #14150 on the high priority list
 5742018-10-18T19:08:45  <promag> gmaxwell: that would be cool
 5752018-10-18T19:08:47  <meshcollider> Yeah I'm fairly sure it'll be fine with both
 5762018-10-18T19:08:47  <gribble> https://github.com/bitcoin/bitcoin/issues/14150 | Add key origin support to descriptors by sipa · Pull Request #14150 · bitcoin/bitcoin · GitHub
 5772018-10-18T19:08:51  <wumpus> gmaxwell: great !
 5782018-10-18T19:08:58  <jnewbery> Should #14416 be high priority? I don't think there's anything to review, but the issue is important.
 5792018-10-18T19:09:00  <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
 5802018-10-18T19:09:07  *** Krellan has quit IRC
 5812018-10-18T19:09:09  <wumpus> jnewbery: sure
 5822018-10-18T19:09:10  <jonasschnelli> sipa: added
 5832018-10-18T19:09:20  <jnewbery> jonasschnelli: any update on that issue?
 5842018-10-18T19:09:42  <jonasschnelli> promag: changed
 5852018-10-18T19:09:48  <promag> jonasschnelli: ty
 5862018-10-18T19:09:50  *** Krellan has joined #bitcoin-core-dev
 5872018-10-18T19:09:51  <meshcollider> I'd like #14454 on there please
 5882018-10-18T19:09:55  <gribble> https://github.com/bitcoin/bitcoin/issues/14454 | Add SegWit support to importmulti by MeshCollider · Pull Request #14454 · bitcoin/bitcoin · GitHub
 5892018-10-18T19:09:59  <jonasschnelli> jnewbery: I'm currently investigating... but haven't found the issue yet
 5902018-10-18T19:10:01  <promag> IIRC the idea was to create DS_Store with xenial?
 5912018-10-18T19:10:01  <wumpus> although it's still WIP so normally that doesn't qualify
 5922018-10-18T19:10:16  <jonasschnelli> meshcollider: done
 5932018-10-18T19:10:32  *** belcher has joined #bitcoin-core-dev
 5942018-10-18T19:10:32  <meshcollider> jonasschnelli: thanks :)
 5952018-10-18T19:10:43  <jonasschnelli> #topic ds_store OSX issue
 5962018-10-18T19:10:54  <jnewbery> wumpus: yeah, it's not high priority for review, but I'd say it's high priority to fix!
 5972018-10-18T19:10:57  <jonasschnelli> i'm currently removing instruction by instruction to figure out, where the issue is
 5982018-10-18T19:11:07  <jonasschnelli> (always. requires a gitian build)
 5992018-10-18T19:11:13  <wumpus> jnewbery: would agree on that
 6002018-10-18T19:11:39  <jonasschnelli> help from cfields would be welcome... but I guess his busy with other things
 6012018-10-18T19:12:44  <jonasschnelli> Anyways,.. I'm on it.
 6022018-10-18T19:12:45  <wumpus> so if anyone knows MacOSX low-level details about DS_store, please help with that issue
 6032018-10-18T19:13:05  <jonasschnelli> #topic (remove?) address book (promag)
 6042018-10-18T19:13:16  <wumpus> it's an undocumented, reverse-engineered format so it's quite hard to get right
 6052018-10-18T19:13:23  <jonasschnelli> wumpus: indeed
 6062018-10-18T19:13:40  <promag> We could remove access to the address book from the File Menu
 6072018-10-18T19:14:01  <promag> so people would have to go to receive
 6082018-10-18T19:14:06  <luke-jr> does the dmg have translations in it?
 6092018-10-18T19:14:11  *** AaronvanW has quit IRC
 6102018-10-18T19:14:20  <instagibbs> ack 14150
 6112018-10-18T19:14:22  <jonasschnelli> luke-jr: Yes
 6122018-10-18T19:14:24  <wumpus> any specific reason to remove this functionality?
 6132018-10-18T19:14:34  <luke-jr> jonasschnelli: I wonder if that's related. Do older versions' DMGs work?
 6142018-10-18T19:14:36  <jonasschnelli> #14150
 6152018-10-18T19:14:38  <gribble> https://github.com/bitcoin/bitcoin/issues/14150 | Add key origin support to descriptors by sipa · Pull Request #14150 · bitcoin/bitcoin · GitHub
 6162018-10-18T19:14:39  <achow101> promag: isn't that the only way to change labels from the gui?
 6172018-10-18T19:15:02  <promag> 
 6182018-10-18T19:15:05  <wumpus> achow101: you an also edit label from the transaction list
 6192018-10-18T19:15:15  <wumpus> (right button context menu)
 6202018-10-18T19:15:37  <promag> gmaxwell: knows better about the complaints/questions
 6212018-10-18T19:15:42  <jonasschnelli> In the long run, the address book makes little sense to me...
 6222018-10-18T19:15:44  <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.
 6232018-10-18T19:15:51  <jonasschnelli> But I guess there are still users using it...
 6242018-10-18T19:15:57  <gmaxwell> okay so that is the context.
 6252018-10-18T19:16:02  <achow101> wumpus: that's... non-obvious
 6262018-10-18T19:16:18  <meshcollider> that requires actually having a transaction then
 6272018-10-18T19:16:24  <promag> but looks like people will reuse addresses not that the "new button" is gone
 6282018-10-18T19:16:34  <promag> s/not/now
 6292018-10-18T19:16:45  <jonasschnelli> *sigh*
 6302018-10-18T19:16:47  <luke-jr> ugh
 6312018-10-18T19:16:48  <wumpus> could re-add that button
 6322018-10-18T19:16:49  <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).
 6332018-10-18T19:17:08  <wumpus> if people miss that, i'm not sure removing even more functionality is the right way forward
 6342018-10-18T19:17:12  *** belcher_ has joined #bitcoin-core-dev
 6352018-10-18T19:17:25  <wumpus> let's revert the remove and call it a day, users happy and it's easy
 6362018-10-18T19:17:31  <achow101> concept nack on removing the address book. it'll just make people more confused
 6372018-10-18T19:17:31  <promag> but I think that's because people goes to File menu and then they see the "received addresses"
 6382018-10-18T19:17:36  <gmaxwell> wumpus: as gwillen points out, the 'request payment' button is really not-obvious.
 6392018-10-18T19:17:49  <achow101> promag: instead of removing it, rename it to be more clear?
 6402018-10-18T19:17:50  <jonasschnelli> PR: #12721 (remove)
 6412018-10-18T19:17:51  <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
 6422018-10-18T19:18:14  <luke-jr> achow101: we can revert + rename to cover both bases
 6432018-10-18T19:18:26  *** belcher has quit IRC
 6442018-10-18T19:18:27  <achow101> luke-jr: +1
 6452018-10-18T19:18:32  <wumpus> yes
 6462018-10-18T19:18:37  <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.
 6472018-10-18T19:18:40  <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
 6482018-10-18T19:18:42  <jonasschnelli> Or we can add a hint: "use Receive tab to create a new address"?
 6492018-10-18T19:18:49  <jonasschnelli> :-)
 6502018-10-18T19:18:56  <wumpus> removing the address book will probably result in even more complaints
 6512018-10-18T19:19:05  <luke-jr> sipa: true
 6522018-10-18T19:19:10  <sipa> but many wallets don't even have a concept of an address book
 6532018-10-18T19:19:22  <gmaxwell> The complaints themselves aren't the concept, the resulting confusion is. :)
 6542018-10-18T19:19:22  <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
 6552018-10-18T19:19:35  <jarthur> People use the signing feature quite a bit.
 6562018-10-18T19:19:47  <jonasschnelli> oh.. for that. Yes.
 6572018-10-18T19:19:53  <luke-jr> jarthur: misuse* I suspect :/
 6582018-10-18T19:20:04  <gmaxwell> Okay, thats a reason to keep/rename.
 6592018-10-18T19:20:11  <jonasschnelli> What about.. a) warn about address reuse, b) add hint to receive tab for new addresses?
 6602018-10-18T19:20:19  <meshcollider> Theres an issue for renaming btw #14482
 6612018-10-18T19:20:20  <gribble> https://github.com/bitcoin/bitcoin/issues/14482 | Better name for "Request Payment" button · Issue #14482 · bitcoin/bitcoin · GitHub
 6622018-10-18T19:20:23  <achow101> topic suggestion: plans for new windows code signing key
 6632018-10-18T19:20:24  <gmaxwell> Users really shouldn't be using it to get addresses to pay for.
 6642018-10-18T19:20:35  <promag> gmaxwell: exactly
 6652018-10-18T19:20:41  <jonasschnelli> Agree
 6662018-10-18T19:20:52  <wumpus> no, they shouldn't, but for better or worse they're used to that
 6672018-10-18T19:21:11  <luke-jr> I'm not really sure a clear rename for it btw
 6682018-10-18T19:21:15  <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
 6692018-10-18T19:21:18  <wumpus> it's not really easy to change people's behavior
 6702018-10-18T19:21:25  <promag> I think we should improve the UI, remove address book from File menu, improve receive tab
 6712018-10-18T19:21:30  <jonasschnelli> Agree also with gmaxwell
 6722018-10-18T19:21:36  <gmaxwell> promag: +1
 6732018-10-18T19:21:41  <jonasschnelli> "Request payment" is confusing
 6742018-10-18T19:21:56  <jonasschnelli> Yes. Please do that promag
 6752018-10-18T19:21:57  <wumpus> how is it called in other wallets?
 6762018-10-18T19:22:01  <luke-jr> we could add sign message to the request-payment dialog probably
 6772018-10-18T19:22:04  <gmaxwell> it doesn't exist in other wallets.
 6782018-10-18T19:22:05  <jonasschnelli> wumpus "Receive"
 6792018-10-18T19:22:14  <wumpus> well let's rename to that
 6802018-10-18T19:22:15  <gmaxwell> oh you mean getting an address, 'recieve'
 6812018-10-18T19:22:30  <gmaxwell> (my doesn't exist was referring to the address book)
 6822018-10-18T19:22:32  <luke-jr> "Receive" implies you would receive it immediately :x
 6832018-10-18T19:22:35  <jonasschnelli> And then maybe automatically show the next unused address?
 6842018-10-18T19:22:36  <wumpus> if it doesnt' exist then maybe we should remove it too
 6852018-10-18T19:22:48  <gmaxwell> jonasschnelli: the workflow can stay the same.
 6862018-10-18T19:23:22  <wumpus> I wouldn't change the workflow too much either
 6872018-10-18T19:23:34  <wumpus> lots of people will be used to that workflow too
 6882018-10-18T19:23:38  <gmaxwell> Just change the label to make it more discoverable.
 6892018-10-18T19:23:42  <wumpus> if you change that too much, you'll get the same issue in another place
 6902018-10-18T19:23:50  <jonasschnelli> Wait,.. the tab is already labeled with "Receive", right? We are talking about the button for creating a new address?
 6912018-10-18T19:23:57  <wumpus> yes, the tab is Receive
 6922018-10-18T19:23:58  <wumpus> always has been
 6932018-10-18T19:23:59  <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.
 6942018-10-18T19:23:59  <meshcollider> Yep
 6952018-10-18T19:24:26  <jonasschnelli> I think there should be a "new address" button and a "receive specific amount" button where you get prompted for amount / label
 6962018-10-18T19:24:27  <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)
 6972018-10-18T19:24:34  <promag> jonasschnelli: yes
 6982018-10-18T19:24:49  <luke-jr> jonasschnelli: label is always desirable
 6992018-10-18T19:25:00  <wumpus> I think 'make the workflow more apparent' is better than changing it
 7002018-10-18T19:25:06  <jnewbery> meta-topic suggestion: does it make sense to discuss qt UI issues in the general bitcoin core IRC meeting?
 7012018-10-18T19:25:13  <gmaxwell> jonasschnelli: label should always be availble, but I don't think a parallel button would be bad.
 7022018-10-18T19:25:34  *** rex4539 has quit IRC
 7032018-10-18T19:25:34  <wumpus> jnewbery: well the UI is part of the code base, if we don't want to discuss it, we should remove it
 7042018-10-18T19:25:42  <sipa> meta-comment: at coredev tokyo it was suggested to have a separate wallet meeting as well, every 2 weeks
 7052018-10-18T19:25:45  <gmaxwell> How about we just discuss nothing, jnewbery because there is no element of the software which is interesting to everyone.
 7062018-10-18T19:25:52  <wumpus> as long as it is part of the code base it should be discussable in the meeting
 7072018-10-18T19:26:10  <wumpus> gmaxwell: exactly
 7082018-10-18T19:26:20  <jonasschnelli> Long term, multiple meeting make sense, until we have that, UI belong here
 7092018-10-18T19:26:22  <jnewbery> My point was more along the lines of what sipa is talking about: the project doesn't scale if everyone discusses everything
 7102018-10-18T19:26:24  <jonasschnelli> +s
 7112018-10-18T19:26:24  <wumpus> it's already hard enough to fill the meetings hour many times
 7122018-10-18T19:26:32  <wumpus> I don't think we should be discussing getting rid of cetain topics
 7132018-10-18T19:26:41  <wumpus> but that's just IMO
 7142018-10-18T19:26:50  <luke-jr> maybe when/if meetings get cut off due to time ;)
 7152018-10-18T19:26:56  <gmaxwell> jnewbery: if we're always running out of time that would be a concern, but we seldom do.
 7162018-10-18T19:27:03  <wumpus> yes, then it's time to prioritize certain topics
 7172018-10-18T19:27:05  <jnewbery> ok, let me rephrase: does it make sense to have a separate meeting for qt issues?
 7182018-10-18T19:27:11  <wumpus> no, I don't think so
 7192018-10-18T19:27:13  <gmaxwell> And it's useful, even if you mostly don't care about something to occassionally get exposed to them.
 7202018-10-18T19:27:50  <wumpus> as soon as the GUI is a aseparate project, that makes sense to reconsider.
 7212018-10-18T19:27:58  <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).
 7222018-10-18T19:28:30  <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
 7232018-10-18T19:28:59  <jonasschnelli> Indeed
 7242018-10-18T19:29:29  <jonasschnelli> #action overhaul the receive page, overhaul the address-book to cure confusion with 0.17
 7252018-10-18T19:29:54  <jonasschnelli> #topic plans for new windows code signing key (achow101)
 7262018-10-18T19:29:58  <promag> ok thanks, I'll add screenshots too
 7272018-10-18T19:30:02  <wumpus> gmaxwell: it's clear most of the developers here don't give a shit about the gui
 7282018-10-18T19:30:06  <wumpus> gmaxwell: always has been
 7292018-10-18T19:30:20  <jnewbery> my other topic suggestion was having a separate wallet meeting (which sipa already mentioned)
 7302018-10-18T19:30:44  <achow101> the windows signing key expires just before the next release is scheduled
 7312018-10-18T19:30:50  <wumpus> it has always been a thankless job maintainging it, lots of respect to jonasschnelli for that :D
 7322018-10-18T19:31:02  <jonasschnelli> Though I should do more. :)
 7332018-10-18T19:31:06  <achow101> IIRC there were plans to do mpc rsa stuff to replace it, did anything come of that?
 7342018-10-18T19:31:14  <jonasschnelli> achow101: I don't think so..
 7352018-10-18T19:31:25  <jonasschnelli> Have you talked wo cfields (current Win signing key owner)?
 7362018-10-18T19:31:32  <jonasschnelli> s/wo/to
 7372018-10-18T19:31:54  <achow101> not yet. I only just noticed as I was looking at the key details today
 7382018-10-18T19:31:58  <meshcollider> I thought he was working on something
 7392018-10-18T19:31:59  <jonasschnelli> Ideally we get new keys also via the Bitcoin Core Code Signing Association (http://bitcoincorecodesigning.org)
 7402018-10-18T19:32:31  <gmaxwell> achow101: I have it working for three parties, but got stuck extending it for more.
 7412018-10-18T19:32:36  <jonasschnelli> achow101: thanks for pointing that out,.. better care about earlier then when its too late
 7422018-10-18T19:33:27  <gmaxwell> achow101: would you lie to try the MPC with me at some point?
 7432018-10-18T19:33:33  <achow101> gmaxwell: sure
 7442018-10-18T19:33:50  <jonasschnelli> Maybe MPC it's not worth it. IMO windows code signing is more or less security theatre...
 7452018-10-18T19:33:53  *** bitconner has joined #bitcoin-core-dev
 7462018-10-18T19:34:17  <wumpus> does it give users problems if it's not signed?
 7472018-10-18T19:34:22  <gmaxwell> Yes.
 7482018-10-18T19:34:29  <achow101> wumpus: windows gives scary warnings
 7492018-10-18T19:34:33  <gmaxwell> you get warnings that the software might be malicious.
 7502018-10-18T19:34:36  <jonasschnelli> I think no-one would recognise if the certificate would be issued to "Bitcoin Cash Code Signing Association"
 7512018-10-18T19:34:53  <jonasschnelli> We need to sign it for UX,.. but much for security reasons.
 7522018-10-18T19:34:53  <meshcollider> jonasschnelli: how difficult is it to get a key for the code signing association then
 7532018-10-18T19:34:57  <luke-jr> jonasschnelli: meaning nobody would mind, or it would freak them out?
 7542018-10-18T19:35:00  <meshcollider> I'm unfamiliar with the process
 7552018-10-18T19:35:13  <meshcollider> luke-jr: I'd say it would freak people out tbh
 7562018-10-18T19:35:13  <achow101> luke-jr: I think no one would mind or even notice the name is different
 7572018-10-18T19:35:15  <gmaxwell> luke-jr: he's saying no one would notice, I think thats mostly right.
 7582018-10-18T19:35:34  <meshcollider> Not the different name, but not signing at all
 7592018-10-18T19:35:38  <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.
 7602018-10-18T19:35:46  <gmaxwell> (though the 'bitcoin foundation' thing did have an unfortunate effect of making people think BCF made the bitcoin software)
 7612018-10-18T19:36:03  <luke-jr> "Bitcoin Cash Code Signing Association" hopefully wouldn't have that confusion
 7622018-10-18T19:36:12  <jonasschnelli> Getting Windows signing key should be a simple task,.. we just need to decide on a cert supplier
 7632018-10-18T19:37:12  <jonasschnelli> Lets wait on cfields though,.. he has the most knowhow here (before any action, buying certs, etc.)
 7642018-10-18T19:37:22  <wumpus> jonasschnelli: it's still more work for scammers than nothing at all! but yes, not much.
 7652018-10-18T19:37:46  <jonasschnelli> wumpus: Yes. But people may think, oh, its code signing, so it must be "secure" (false sense of sec.)
 7662018-10-18T19:38:15  <jonasschnelli> The only difference is that some CA guy clicked to okay button after reading an address (for most CAs)
 7672018-10-18T19:38:16  <wumpus> oh yes I don't disagree the user perception of what signingmeans is completely wrong
 7682018-10-18T19:38:38  <meshcollider> IMO anyone confused by what the code signing means probably isn't aware of code signing at all?
 7692018-10-18T19:38:58  <meshcollider> Users just get software and run it
 7702018-10-18T19:39:02  <sipa> really it's a way to make some platforms shut up about untrusted code
 7712018-10-18T19:39:12  <luke-jr> I suspect nobody would really notice if we stopped codesigning
 7722018-10-18T19:39:12  <wumpus> sipa: yep
 7732018-10-18T19:39:15  <meshcollider> Exactly
 7742018-10-18T19:39:24  <gmaxwell> luke-jr: they would, because they get a big nasty warning
 7752018-10-18T19:39:28  <meshcollider> luke-jr: I disagree, yeah
 7762018-10-18T19:39:35  <luke-jr> maybe if we timed it right, we could use it as an opportunity to teach PGP verification
 7772018-10-18T19:39:39  <jonasschnelli> If we want secure "update", we should finally have a "verificator" function in Core
 7782018-10-18T19:40:13  <jonasschnelli> Some glue code that does gitian verification against a downloaded binary dummy-save
 7792018-10-18T19:40:15  <luke-jr> gmaxwell: a warning they're used to clicking through all the time..?
 7802018-10-18T19:40:25  <gmaxwell> luke-jr: most software is signed.
 7812018-10-18T19:40:31  *** bitconner has quit IRC
 7822018-10-18T19:40:34  <achow101> luke-jr: no, it's actually a warning on top of the normal warning
 7832018-10-18T19:40:37  <phantomcircuit> gmaxwell, maybe it should be an "open source code signing association"
 7842018-10-18T19:40:50  <phantomcircuit> rather than something bitcoin specific? (even if it's only signing bitcoin in practice)
 7852018-10-18T19:41:03  <sipa> we talked about that a while ago
 7862018-10-18T19:41:06  <luke-jr> phantomcircuit: jonasschnelli already set it up, for better or worse
 7872018-10-18T19:41:16  <sipa> that it could just be something that signs off on deterministic builds
 7882018-10-18T19:41:18  <meshcollider> phantomcircuit: if we already have the iOS certificate with the bitcoin one the windows one should be the same
 7892018-10-18T19:41:25  <jonasschnelli> phantomcircuit: I think "Bitcoin Core" should be in the name
 7902018-10-18T19:41:27  <luke-jr> although I suppose if there's a desire for a broader codesigning org, we could make another
 7912018-10-18T19:41:43  <sipa> luke-jr: agree
 7922018-10-18T19:41:53  <jonasschnelli> phantomcircuit: its somehow the only binding "guarantee" for the user
 7932018-10-18T19:42:09  <phantomcircuit> this seems likely to be an issue faced by numerous projects
 7942018-10-18T19:42:11  <luke-jr> jonasschnelli: ? seems like it would just reaffirm the false sense of security
 7952018-10-18T19:42:21  <jonasschnelli> luke-jr: somehow,.. yes. :)
 7962018-10-18T19:42:32  <luke-jr> jonasschnelli: a more obviously-dummy org name might prompt a real security verification
 7972018-10-18T19:42:34  <phantomcircuit> it's certainly no actual security
 7982018-10-18T19:42:42  <luke-jr> maybe we should call it Malware Signing Group
 7992018-10-18T19:42:44  <luke-jr> :P
 8002018-10-18T19:42:48  <phantomcircuit> luke-jr, doubtful honestly
 8012018-10-18T19:42:59  <jonasschnelli> heh
 8022018-10-18T19:43:01  <achow101> luke-jr: you wouldn't get issued a cert with that name
 8032018-10-18T19:43:13  *** ExtraCrispy has quit IRC
 8042018-10-18T19:43:15  <jonasschnelli> Oh.. I'm sure you would
 8052018-10-18T19:43:26  <luke-jr> Check The PGP Signatures, LLC
 8062018-10-18T19:43:42  *** ExtraCrispy has joined #bitcoin-core-dev
 8072018-10-18T19:43:48  *** bitconner has joined #bitcoin-core-dev
 8082018-10-18T19:44:36  <jonasschnelli> #topic suggestion was having a separate wallet meeting (which sipa already mentioned) (jnewbery)
 8092018-10-18T19:44:40  <jonasschnelli> -suggestion
 8102018-10-18T19:45:04  <wumpus> would this involve different people than the current meeting?
 8112018-10-18T19:45:15  <achow101> how much wallet stuff is there to discuss?
 8122018-10-18T19:45:18  <jnewbery> This was brought up in Tokyo. People seemed keen to have a separate meeting (perhaps once every two weeks) to discuss wallet issues
 8132018-10-18T19:45:25  <meshcollider> And is it worth it until there's more actual separation
 8142018-10-18T19:45:35  <wumpus> achow101: yes.. exactly.. how much wallet stuff do we discuss
 8152018-10-18T19:45:41  <jonasschnelli> I think it worth it if we run constantly out of time
 8162018-10-18T19:45:44  <wumpus> but if people want that, why not
 8172018-10-18T19:45:50  <luke-jr> just the Core wallet, or wallets in general?
 8182018-10-18T19:46:05  <jnewbery> Code/repo separation is somewhat orthogonal to project separation
 8192018-10-18T19:46:08  <wumpus> luke-jr: wallets in general would make more sense I guess
 8202018-10-18T19:46:13  <meshcollider> Worth noting that if we had a separate meeting, it might promote more discussion even if we don't have it right now
 8212018-10-18T19:46:13  <gmaxwell> the disadvantage is just having to reserve and schedule more time.
 8222018-10-18T19:46:14  <luke-jr> perhaps a S3ND IRC meeting or something
 8232018-10-18T19:46:16  <jnewbery> Bitcoin core wallet
 8242018-10-18T19:46:20  <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
 8252018-10-18T19:46:22  <wumpus> we need a wallet maintainer...
 8262018-10-18T19:46:26  <instagibbs> gmaxwell, depends on how big the group is
 8272018-10-18T19:46:27  <gmaxwell> but maybe some things about the wallet aren't getting discussed in here.
 8282018-10-18T19:46:29  *** ExtraCrispy has quit IRC
 8292018-10-18T19:46:52  <meshcollider> wumpus: how do we train someone for that job then
 8302018-10-18T19:46:54  <instagibbs> in Tokyo there were a small handful who discussed some short term improvements, wouldn't be hard to coordinate among those
 8312018-10-18T19:47:26  <wumpus> exactly; it makes sense to coordinate among the people who are interested in having this meeting
 8322018-10-18T19:47:31  <meshcollider> For example I think there would be some good discussion around descriptor stuff in the near future right?
 8332018-10-18T19:47:39  <gmaxwell> If people who want to talk about wallet stuff more want another meeting, great.
 8342018-10-18T19:47:39  <wumpus> if you want to organize a meeting about your part of the code, go ahead
 8352018-10-18T19:47:43  <jonasschnelli> Agree with wumpus
 8362018-10-18T19:47:55  <jonasschnelli> (I'm happy to join that meeting)
 8372018-10-18T19:47:57  * sipa suggests: same time, fridays, every two weeks
 8382018-10-18T19:47:59  <wumpus> meetingbot is here and we'll respect it and shut up during it :)
 8392018-10-18T19:48:10  <jnewbery> a couple of questions: how many people are interested? Should it be in here or a different channel?
 8402018-10-18T19:48:16  <meshcollider> I'm interested
 8412018-10-18T19:48:18  <gmaxwell> It should be here.
 8422018-10-18T19:48:19  <jonasschnelli> we should probably list the meeting(s) somewhere (bitcoincore.org?)
 8432018-10-18T19:48:20  <sipa> i'd rather keep it in this channel
 8442018-10-18T19:48:25  <jonasschnelli> ack
 8452018-10-18T19:48:45  <luke-jr> jnewbery: I'm not entirely disinterested, but I don't think I have time for it
 8462018-10-18T19:48:46  <wumpus> yes, why not this channel
 8472018-10-18T19:48:58  <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. :)
 8482018-10-18T19:48:58  <achow101> sipa: +1 (re date and time)
 8492018-10-18T19:49:08  <gmaxwell> held*
 8502018-10-18T19:49:21  <sipa> being in this channel may encourage others to participate (or at least lurk and see what's being worked on)
 8512018-10-18T19:49:27  <meshcollider> I was very confused because I thought it *was* Friday, but then I remembered you're all in the wrong time zone
 8522018-10-18T19:49:34  <luke-jr> lol
 8532018-10-18T19:49:49  <jonasschnelli> * has a while thought that meeting could be done in voice via jitsi *duck*
 8542018-10-18T19:49:52  <meshcollider> +1 then
 8552018-10-18T19:49:53  <achow101> meshcollider: at least we're not upside down
 8562018-10-18T19:49:58  <meshcollider> :(
 8572018-10-18T19:50:07  <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.
 8582018-10-18T19:50:13  <jnewbery> so Friday for us would be saturday for meshcollider. Is that ok for you, or would you prefer it on a week day?
 8592018-10-18T19:50:39  <meshcollider> Saturday is probably preferable even, less conflict with lectures
 8602018-10-18T19:50:42  <sipa> (i'm suggesting friday because i already have meetings on all other days around that time)
 8612018-10-18T19:51:02  <sipa> but that's a personal preference and i'm sure i can accomodate other times
 8622018-10-18T19:51:45  <meshcollider> So are we starting this tomorrow then?
 8632018-10-18T19:52:11  <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
 8642018-10-18T19:52:15  <jonasschnelli> We can do a poll?
 8652018-10-18T19:52:40  <gmaxwell> It's probably better to start sooner, the first few meetings of this sort of thing are usually poorly attended. :P
 8662018-10-18T19:52:48  <gmaxwell> better get that out of the way.
 8672018-10-18T19:52:56  <sipa> i'm happy to chair as well
 8682018-10-18T19:53:02  <luke-jr> does GUI move to wallet meetings or stay here?
 8692018-10-18T19:53:17  <sipa> i wouldn't say anything "moves"
 8702018-10-18T19:53:25  <meshcollider> Chair of wallet meeting = new wallet maintainer :D
 8712018-10-18T19:53:29  <jonasschnelli> Wallet GUI in wallet, rest-GUI here?
 8722018-10-18T19:53:32  *** justan0theruser has quit IRC
 8732018-10-18T19:53:38  <jonasschnelli> meshcollider: lol
 8742018-10-18T19:54:01  <gmaxwell> I wouldn't say moves either. We should expect some duplication, with the extended discussion in comittee.
 8752018-10-18T19:54:13  <jonasschnelli> Yes. That's fine I guess.
 8762018-10-18T19:54:16  <gmaxwell> Otherwise, people get forced to attend all meetings, which I think is a non-goal.
 8772018-10-18T19:54:29  <instagibbs> +1
 8782018-10-18T19:54:46  <achow101> ack
 8792018-10-18T19:55:02  <meshcollider> +1
 8802018-10-18T19:55:03  <jnewbery> yeah, the suggestion ceratinly isn't that wallet isn't discussed in regular weekly meetings
 8812018-10-18T19:55:51  <booyah> luke-jr: I would notice last of signs on binaries and/or on git tags. FYI :)
 8822018-10-18T19:56:02  <luke-jr> FWIW, someone is already telling me OOB that there will be outrage if the address book is removed :P
 8832018-10-18T19:56:20  <luke-jr> booyah: huh?
 8842018-10-18T19:56:28  <jnewbery> topic suggestion: I think aj was going to bring up IRC meeting logs on bitcoincore.org today
 8852018-10-18T19:56:33  <jnewbery> not sure if he's here
 8862018-10-18T19:56:43  <jonasschnelli> 3.5min left. :/
 8872018-10-18T19:57:02  <luke-jr> pause the clock?
 8882018-10-18T19:57:03  <gmaxwell> luke-jr: we weren't going to anyways, but what is the use they are referring to.
 8892018-10-18T19:57:36  <gmaxwell> The action was to just refactor the interface some to make it less confusing.
 8902018-10-18T19:57:48  <jnewbery> I guess if aj isn't here there's not much to talk about
 8912018-10-18T19:57:49  <luke-jr> gmaxwell: apparently to "see all their addresses in one place"; I don't really get it
 8922018-10-18T19:58:04  <gmaxwell> Though I'm interested in hearing about what the use of it is.
 8932018-10-18T19:58:12  <gmaxwell> (other than signmessage)
 8942018-10-18T19:58:25  <molz> lol
 8952018-10-18T19:58:36  <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
 8962018-10-18T19:58:46  <luke-jr> booyah: rigth
 8972018-10-18T19:58:57  <wumpus> yes, some people like the address book, could have told you so
 8982018-10-18T19:59:54  <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
 8992018-10-18T19:59:56  <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
 9002018-10-18T20:00:18  <jonasschnelli> #endmeeting good night, good morning or enjoy your lunch
 9012018-10-18T20:00:18  <lightningbot> Meeting ended Thu Oct 18 20:00:18 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 9022018-10-18T20:00:18  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-10-18-19.04.html
 9032018-10-18T20:00:18  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-10-18-19.04.txt
 9042018-10-18T20:00:18  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-10-18-19.04.log.html
 9052018-10-18T20:00:24  <wumpus> that's been an issue since 2010 and I don't see why it warrants removal of anything now, personally
 9062018-10-18T20:00:25  *** Tralfaz has quit IRC
 9072018-10-18T20:00:35  *** ghost43 has quit IRC
 9082018-10-18T20:00:52  *** ghost43 has joined #bitcoin-core-dev
 9092018-10-18T20:01:14  *** Tralfaz has joined #bitcoin-core-dev
 9102018-10-18T20:01:46  <promag> molz: my suggestion is to move it away from the File Menu (not sure why is there)
 9112018-10-18T20:01:47  <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
 9122018-10-18T20:01:59  <booyah> like... did I ever transffered money to wikileaks or not (from this wallet)
 9132018-10-18T20:02:22  <sipa> oh, this is about send addresses?
 9142018-10-18T20:02:36  <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?
 9152018-10-18T20:03:00  <gmaxwell> wumpus: we have been generally doing things to move away from reuse for a long time.
 9162018-10-18T20:03:10  <jonasschnelli> sipa: there are both
 9172018-10-18T20:03:24  <gmaxwell> _complaints_ are a one time thing, we shouldn't shy away from an actual intentional improvement because some people will complain.
 9182018-10-18T20:03:41  <gmaxwell> I've been raising issues with the complaints because the confusion we're getting now wasn't intentional or expected.
 9192018-10-18T20:04:03  <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.
 9202018-10-18T20:04:06  <sipa> i think addressing the confusion is separate really from the address book
 9212018-10-18T20:04:53  <wumpus> gmaxwell: still, I think the most straightforward is just to return the button
 9222018-10-18T20:05:00  <wumpus> gmaxwell: instead of trying to re-educate people
 9232018-10-18T20:05:27  <luke-jr> wumpus: return the button, but make it show a "this is how you do it" prompt and switch the tab? :p
 9242018-10-18T20:05:32  <wumpus> then agian I'm not a GUI designer nor pretending to be one
 9252018-10-18T20:06:07  <luke-jr> says the guy who wrote bitcoin-qt..
 9262018-10-18T20:06:35  <booyah> luke-jr: embbed a twitch stream with some slim cryptogirl showing how to do it >_>
 9272018-10-18T20:06:36  <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
 9282018-10-18T20:06:40  <promag> I think "File -> Receiving Addresses" is too powerful and misleading - old users are used to that and have to learn the new way
 9292018-10-18T20:06:52  <sipa> wumpus: i think it has, actually
 9302018-10-18T20:07:01  <sipa> wumpus: though perhaps to a lesser extent than you hoped
 9312018-10-18T20:07:08  <promag> "Window -> Address Book" with 2 tabs or whatever just does the job for those that want that
 9322018-10-18T20:07:16  <wumpus> I didn't expect this (apart from jonasschnelli who is doing a great job, as I said)
 9332018-10-18T20:07:22  <wumpus> sipa: sure!
 9342018-10-18T20:07:51  <luke-jr> I certainly would not have done anything with the GUI if not for wumpus's port
 9352018-10-18T20:08:08  <wumpus> I think we can all agree wxwindows was even worse :-)
 9362018-10-18T20:08:46  <promag> fortunately I'm not not from that time :P
 9372018-10-18T20:08:48  <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
 9382018-10-18T20:08:49  *** spinza has quit IRC
 9392018-10-18T20:08:58  <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. /
 9402018-10-18T20:09:16  <luke-jr> jonasschnelli: want what?
 9412018-10-18T20:09:27  <wumpus> I don't see how increasing the user base could ever be bad
 9422018-10-18T20:09:35  <jonasschnelli> luke-jr: a large user base of novice users
 9432018-10-18T20:09:38  <luke-jr> increasing the user base is essential :/
 9442018-10-18T20:09:53  <luke-jr> dangerously too many people aren't using their own full node right now
 9452018-10-18T20:10:06  <wumpus> I mean, if that's not the point we could do with a command-line UI
 9462018-10-18T20:10:13  <jonasschnelli> Yes. Thats a point.
 9472018-10-18T20:10:35  *** bitconner has quit IRC
 9482018-10-18T20:10:40  <sipa> pfff, netcat and JSON-RPC aren't that that hard
 9492018-10-18T20:10:43  <sipa> :p
 9502018-10-18T20:11:01  <promag> wumpus: btw I think 14453 is done
 9512018-10-18T20:11:11  <luke-jr> speaking of which, I'd like to get the Windows/Mac builds automatically installing and setting up a Tor hidden service .. ?
 9522018-10-18T20:11:19  <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
 9532018-10-18T20:11:42  *** bitconner has joined #bitcoin-core-dev
 9542018-10-18T20:12:16  <wumpus> luke-jr: a bitcoin core-tor bundle has been talked about since 2012 at least
 9552018-10-18T20:12:33  <wumpus> I'm... not sure where all those years went, but we're still not there yet ;)
 9562018-10-18T20:13:06  <wumpus> promag: thank you
 9572018-10-18T20:13:53  <wumpus> luke-jr: at least the torcontrol support should be one step along the way, most of the work left is packaging etc
 9582018-10-18T20:14:31  <luke-jr> wumpus: yes, I think we're pretty close now
 9592018-10-18T20:14:42  <gmaxwell> wumpus: I think we should focus on power users and (esp small/medium scale) commercial users for that reason.
 9602018-10-18T20:15:16  <wumpus> gmaxwell: yes, I think that makes most sense
 9612018-10-18T20:15:35  <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)
 9622018-10-18T20:16:37  <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..
 9632018-10-18T20:17:27  *** phwalkr has joined #bitcoin-core-dev
 9642018-10-18T20:20:23  *** AaronvanW has joined #bitcoin-core-dev
 9652018-10-18T20:25:32  *** tryphe has quit IRC
 9662018-10-18T20:25:58  *** tryphe has joined #bitcoin-core-dev
 9672018-10-18T20:28:07  <wumpus> argh things like #14510 really want me to stop bothering with c++
 9682018-10-18T20:28:09  <gribble> https://github.com/bitcoin/bitcoin/issues/14510 | Avoid triggering undefined behaviour in base_uint ::bits() by practicalswift · Pull Request #14510 · bitcoin/bitcoin · GitHub
 9692018-10-18T20:29:37  <gmaxwell> at least the compilers can just warn about that.
 9702018-10-18T20:30:57  <wumpus> so this is undefined behavior, the thing that could spawn unicorns or swallow galaxies or other arbitrary behavior
 9712018-10-18T20:33:30  <wumpus> this particular instance hasn't killed us yet
 9722018-10-18T20:34:04  *** Guest63155 has quit IRC
 9732018-10-18T20:35:40  *** spinza has joined #bitcoin-core-dev
 9742018-10-18T20:39:10  *** michaelsdunn1 has quit IRC
 9752018-10-18T20:39:31  *** laurentmt has joined #bitcoin-core-dev
 9762018-10-18T20:52:38  *** michaelsdunn1 has joined #bitcoin-core-dev
 9772018-10-18T20:56:12  *** bitcoin-git has joined #bitcoin-core-dev
 9782018-10-18T20:56:13  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fe23553edd84...3715b2489e98
 9792018-10-18T20:56:13  <bitcoin-git> bitcoin/master 96f6dc9 practicalswift: Avoid triggering undefined behaviour in base_uint<BITS>::bits()
 9802018-10-18T20:56:14  <bitcoin-git> bitcoin/master 3715b24 Wladimir J. van der Laan: Merge #14510: Avoid triggering undefined behaviour in base_uint<BITS>::bits()...
 9812018-10-18T20:56:14  *** bitcoin-git has left #bitcoin-core-dev
 9822018-10-18T20:57:26  *** bitcoin-git has joined #bitcoin-core-dev
 9832018-10-18T20:57:27  <bitcoin-git> [bitcoin] laanwj closed pull request #14510: Avoid triggering undefined behaviour in base_uint<BITS>::bits() (master...1<<31) https://github.com/bitcoin/bitcoin/pull/14510
 9842018-10-18T20:57:27  *** bitcoin-git has left #bitcoin-core-dev
 9852018-10-18T21:07:43  *** kelt has joined #bitcoin-core-dev
 9862018-10-18T21:09:45  <hebasto> wumpus: may you look into #14409 ?
 9872018-10-18T21:09:47  <gribble> https://github.com/bitcoin/bitcoin/issues/14409 | utils and libraries: Make blocksdir always net specific by hebasto · Pull Request #14409 · bitcoin/bitcoin · GitHub
 9882018-10-18T21:10:23  *** laurentmt has quit IRC
 9892018-10-18T21:15:33  *** bitcoin-git has joined #bitcoin-core-dev
 9902018-10-18T21:15:34  <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
 9912018-10-18T21:15:34  *** bitcoin-git has left #bitcoin-core-dev
 9922018-10-18T21:17:29  *** ghost43 has quit IRC
 9932018-10-18T21:17:44  *** ghost43 has joined #bitcoin-core-dev
 9942018-10-18T21:29:51  *** grubles has quit IRC
 9952018-10-18T21:30:28  *** earlz is now known as tubetime2
 9962018-10-18T21:30:39  *** tubetime2 is now known as earlz
 9972018-10-18T21:32:06  <phantomcircuit> im not sure exactly how to deal with detecting functional poll() support
 9982018-10-18T21:32:12  <phantomcircuit> it's definitely broken on windows
 9992018-10-18T21:33:18  *** dviola has joined #bitcoin-core-dev
10002018-10-18T21:33:59  *** michaelsdunn1 has quit IRC
10012018-10-18T21:34:42  *** ghost43 has quit IRC
10022018-10-18T21:34:53  *** ghost43 has joined #bitcoin-core-dev
10032018-10-18T21:35:39  *** bitcoin-git has joined #bitcoin-core-dev
10042018-10-18T21:35:39  <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
10052018-10-18T21:35:39  *** bitcoin-git has left #bitcoin-core-dev
10062018-10-18T21:37:31  <wumpus> definitely don't use poll on windows
10072018-10-18T21:37:36  *** bitcoin-git has joined #bitcoin-core-dev
10082018-10-18T21:37:36  <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
10092018-10-18T21:37:36  *** bitcoin-git has left #bitcoin-core-dev
10102018-10-18T21:37:54  *** bitcoin-git has joined #bitcoin-core-dev
10112018-10-18T21:37:54  <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
10122018-10-18T21:37:54  *** bitcoin-git has left #bitcoin-core-dev
10132018-10-18T21:38:15  <wumpus> every *POSIX* OS supports poll()
10142018-10-18T21:38:23  <wumpus> so that's everything we support, except windows
10152018-10-18T21:46:15  <wumpus> select on windows doesn't have the same problems as select on unices anyhow; just keep using it
10162018-10-18T21:48:41  <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
10172018-10-18T21:48:55  <luke-jr> re bundling tor: it's a shame Tor has stopped using gitian :/
10182018-10-18T21:50:02  *** str4d has joined #bitcoin-core-dev
10192018-10-18T21:52:26  *** grubles has joined #bitcoin-core-dev
10202018-10-18T21:52:29  <wumpus> sipa: so does windwos have any better alternative? at least not poll...
10212018-10-18T21:53:21  <luke-jr> Windows has an alternative that requires a different paradigm IIRC
10222018-10-18T21:53:43  <luke-jr> you read/write and get told when it's done; rather than waiting for read/writability
10232018-10-18T21:54:26  <wumpus> right, some async notification
10242018-10-18T22:13:36  <promag> meshcollider: achow101: can you take a look at #14291 so I can squash?
10252018-10-18T22:13:39  <gribble> https://github.com/bitcoin/bitcoin/issues/14291 | wallet: Add ListWalletDir utility function by promag · Pull Request #14291 · bitcoin/bitcoin · GitHub
10262018-10-18T22:14:33  <meshcollider> promag: sure :)
10272018-10-18T22:20:07  *** jarthur_ has joined #bitcoin-core-dev
10282018-10-18T22:23:18  *** jarthur has quit IRC
10292018-10-18T22:24:40  *** jarthur_ has quit IRC
10302018-10-18T22:24:56  <wumpus> yes let's squash and merge it
10312018-10-18T22:25:03  *** dviola has quit IRC
10322018-10-18T22:26:10  <meshcollider> +1
10332018-10-18T22:30:08  <promag> thanks guys, squash and push done, waiting to ci
10342018-10-18T22:30:21  <promag> err, for ci
10352018-10-18T22:36:25  <wumpus> how crap is C++ that even defining a constant can be undefined behavior, without the compiler complaining?
10362018-10-18T22:36:45  <meshcollider> promag: thank you for taking that up btw
10372018-10-18T22:37:01  <meshcollider> wumpus: no doubt about it lol
10382018-10-18T22:37:20  <sipa> wumpus: presumably because in the actual implementation it isn't undefined
10392018-10-18T22:37:57  <wumpus> sipa: I'm not sure I understand, hwo can it be defined in the implementation but not in the language?
10402018-10-18T22:38:12  <sipa> wumpus: non-standard extension to the language
10412018-10-18T22:38:29  <wumpus> I really don't understand it, I'm not sure how I've even been able to use it without knowing this
10422018-10-18T22:38:42  <wumpus> how much broken code I must have written
10432018-10-18T22:39:00  <gmaxwell> The compiler can freely implementation define any undefined behavior.
10442018-10-18T22:39:09  <sipa> in practice, compilers implement a language that is significantly closer to people's expectations than what the actual standard specifies
10452018-10-18T22:39:12  <wumpus> the many times i've written 1<<something without thinking about this
10462018-10-18T22:39:17  *** kelt has quit IRC
10472018-10-18T22:39:22  <wumpus> it's sad
10482018-10-18T22:39:42  <gmaxwell> and C/C++ code is typically FULL of stuff that a wonkish read of the language is undefined.
10492018-10-18T22:39:44  <promag> sipa: could you reack 14453? comment added and a variable renamed.
10502018-10-18T22:40:26  <wumpus> gmaxwell: isn't that bizarre
10512018-10-18T22:41:01  <gwillen> a lot of it is just due to the tight binding between C and asm
10522018-10-18T22:41:10  <wumpus> tight binding?
10532018-10-18T22:41:14  <sipa> C historically is much worse in that regard than C++
10542018-10-18T22:41:16  <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
10552018-10-18T22:41:23  <wumpus> i'm convinced I can write better assembly than c++ at this point
10562018-10-18T22:41:35  <gwillen> for example, in a twos-complement environment, signed integer overflow naturally works
10572018-10-18T22:41:38  <gwillen> and people have come to rely on it
10582018-10-18T22:41:40  <wumpus> at least the instructions simply mean what htey do
10592018-10-18T22:41:41  <gwillen> but in C it is undefined
10602018-10-18T22:41:44  <gmaxwell> gwillen: I don't think that has anything to do with C binding with ASM.
10612018-10-18T22:41:53  <luke-jr> wumpus: ironically, the fix here is also undefined behaviour >.>
10622018-10-18T22:42:02  <gwillen> well, binding with the environment it was born in
10632018-10-18T22:42:03  <wumpus> assembly language is.. mechanical, well documented
10642018-10-18T22:42:09  <sipa> wumpus: there are plenty of machine code instructions without well documented behaviour too :)
10652018-10-18T22:42:21  <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
10662018-10-18T22:42:22  <wumpus> okay
10672018-10-18T22:42:27  <luke-jr> (just undefined behaviour we rely on, for now)
10682018-10-18T22:42:38  <gwillen> if signed overflow trapped in the CPU then people wouldn't rely on it working in C
10692018-10-18T22:42:55  <gwillen> and then get nailed when the compiler writers take it away
10702018-10-18T22:43:12  <luke-jr> (it's still undefined, because unsigned int is only required to be 16 bits, not 32)
10712018-10-18T22:43:35  <sipa> luke-jr: that's implementation defined :)
10722018-10-18T22:44:10  <wumpus> implementation defined makes some sense
10732018-10-18T22:44:10  <sipa> luke-jr: if the unsigned int type is 32 bits, then shifts up to 31 bits are well defined
10742018-10-18T22:44:19  <wumpus> like 'int' types being the natural size for an architecture
10752018-10-18T22:44:22  <wumpus> that's not ub
10762018-10-18T22:44:24  <sipa> so you can write platform specific code that's fully correct
10772018-10-18T22:45:06  <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
10782018-10-18T22:45:21  <sipa> yeah...
10792018-10-18T22:45:22  <wumpus> that's indeed the result of a direct mapping from C to te underlying architecture as gwillen said
10802018-10-18T22:45:26  <gwillen> (and rust made imo the right choice to kill the native int)
10812018-10-18T22:45:40  <gwillen> (I mean you can still ask for it, but it isn't named "int" anymore so nobody's tempted)
10822018-10-18T22:45:47  <sipa> the uintX_t and uint_fast_X_t model is a far better than the arbitrary mapping for short/int/long
10832018-10-18T22:45:54  <luke-jr> native int does make sense for some things
10842018-10-18T22:46:08  <luke-jr> like <15 bit iteration loops
10852018-10-18T22:46:22  <sipa> luke-jr: you know of uint_fast16_t for example?
10862018-10-18T22:46:35  <luke-jr> sipa: vaguely; I don't have its semantics memorised
10872018-10-18T22:46:39  <gwillen> sipa: I don't know about this!
10882018-10-18T22:46:49  <gwillen> is that "at least 16 but something the cpu likes"?
10892018-10-18T22:46:52  <sipa> it's a data type that's at least 16 bits, but may be larger if larger is faster to work with
10902018-10-18T22:47:00  <gwillen> that's cool, I had no idea
10912018-10-18T22:47:09  <wumpus> yes there's a whole zoo of data types in stdint.h
10922018-10-18T22:47:14  <luke-jr> so by definition the same as unsigned int? :P
10932018-10-18T22:47:42  <gwillen> I don't think unsigned int is required to be fast
10942018-10-18T22:47:48  <gwillen> you could make it 16 if you wanted to be perverse
10952018-10-18T22:48:01  <luke-jr> but it's supposed to be the fastest for the platform, IIRC?
10962018-10-18T22:48:15  <sipa> there is also uint_least16_t for example, which is the smallest type that supports 16 bits
10972018-10-18T22:48:27  <sipa> (in case there is no actual type with 16 bits of width)
10982018-10-18T22:48:28  <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
10992018-10-18T22:48:33  <gwillen> even though 64 is probably faster to work with
11002018-10-18T22:48:53  <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)
11012018-10-18T22:49:33  <sipa> on windows 64, int and long are both 32 bits
11022018-10-18T22:50:11  <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
11032018-10-18T22:50:14  *** jimmysong has joined #bitcoin-core-dev
11042018-10-18T22:50:14  <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.
11052018-10-18T22:50:17  *** tknp has joined #bitcoin-core-dev
11062018-10-18T22:50:53  <sipa> yeah, c++14 makes it well defined evne
11072018-10-18T22:51:09  <luke-jr> clang does warn for it with -Weverything
11082018-10-18T22:51:15  <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]
11092018-10-18T22:51:17  <phantomcircuit> wumpus, seems to be broken on HPUX but im not sure we care really
11102018-10-18T22:51:28  <luke-jr> (IIRC it also miscompiles it)
11112018-10-18T22:51:45  <wumpus> phantomcircuit: didn't HPUX die in 2000 or o
11122018-10-18T22:52:03  <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)
11132018-10-18T22:52:14  <wumpus> we don't need to support museum operating systems
11142018-10-18T22:52:15  <phantomcircuit> http://www.greenend.org.uk/rjk/tech/poll.html
11152018-10-18T22:53:05  <luke-jr> I can only imagine how many warnings Core has if we use clang's -Weverything..
11162018-10-18T22:53:14  <wumpus> sipa: right, breaking that assumption would likely break all the code in practice
11172018-10-18T22:53:19  *** clarkmoody has quit IRC
11182018-10-18T22:53:24  <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
11192018-10-18T22:53:26  <phantomcircuit> anything with 0 is broken anything with ? is probably broken
11202018-10-18T22:53:36  <sipa> luke-jr: i expect that even in C++14 that warning will still appear
11212018-10-18T22:54:00  <wumpus> phantomcircuit: everything and everyone is broken
11222018-10-18T22:54:02  <promag> luke-jr: what's the difference to -Wall?
11232018-10-18T22:54:11  <luke-jr> sipa: yes
11242018-10-18T22:54:17  <luke-jr> promag: -Weverything is a lot more warnings
11252018-10-18T22:54:27  <luke-jr> -Wall IIRC is some kind of "everything GCC supports"
11262018-10-18T22:55:10  <promag> luke-jr: ty
11272018-10-18T22:55:53  <phantomcircuit> luke-jr, it's not any more
11282018-10-18T22:55:58  <luke-jr> ?
11292018-10-18T22:56:04  <phantomcircuit> there's a bunch of warning flags that -Wall doesn't turn on
11302018-10-18T22:56:08  <wumpus> so do I still dare merge anything
11312018-10-18T22:56:54  <luke-jr> merge bacon
11322018-10-18T22:57:27  <sipa> wumpus: i think we should keep in mind that we're actually fairly restrictive in supported platforms
11332018-10-18T22:57:57  *** jcorgan has quit IRC
11342018-10-18T22:58:05  <sipa> where things are far saner than the technical language specification
11352018-10-18T22:58:11  <wumpus> sipa: that's true
11362018-10-18T22:58:26  <sipa> that doesn't mean we should dismiss these improvements to get us closer to compliance with the standard
11372018-10-18T22:58:32  <wumpus> but it could break any time right
11382018-10-18T22:58:48  <sipa> have we ever had a bug that was due to a misunderstanding of undefined behaviour?
11392018-10-18T22:59:09  <wumpus> I don't think we had, I remember there were some awful bugs in the linux kernel though
11402018-10-18T22:59:14  <sipa> wumpus: compilers are very careful generally in not breaking behavior that is relied on in practice
11412018-10-18T22:59:20  <gmaxwell> No, I don't believe we have.. the closest is %0 in the bloom filter thing.
11422018-10-18T23:00:01  <gmaxwell> (a failure to follow my aversion to any and all division... :P but not UB)
11432018-10-18T23:00:27  <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
11442018-10-18T23:00:31  <sipa> BIP 42 perhaps
11452018-10-18T23:00:33  <sipa> :)
11462018-10-18T23:00:49  <wumpus> hehe yes BIP42
11472018-10-18T23:01:08  <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.
11482018-10-18T23:01:55  *** bitcoin-git has joined #bitcoin-core-dev
11492018-10-18T23:01:56  <bitcoin-git> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/3715b2489e98...8eb2cd1ddaab
11502018-10-18T23:01:56  <bitcoin-git> bitcoin/master fc4db35 João Barbosa: wallet: Add ListWalletDir utility...
11512018-10-18T23:01:57  <bitcoin-git> bitcoin/master d1b03b8 João Barbosa: interfaces: Add getWalletDir and listWalletDir to Node
11522018-10-18T23:01:57  <bitcoin-git> bitcoin/master cc33773 João Barbosa: rpc: Add listwalletdir RPC
11532018-10-18T23:01:58  *** bitcoin-git has left #bitcoin-core-dev
11542018-10-18T23:02:49  *** bitcoin-git has joined #bitcoin-core-dev
11552018-10-18T23:02:50  <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
11562018-10-18T23:02:50  *** bitcoin-git has left #bitcoin-core-dev
11572018-10-18T23:05:14  *** klot has quit IRC
11582018-10-18T23:08:29  *** hebasto has quit IRC
11592018-10-18T23:10:18  <meshcollider> \o/
11602018-10-18T23:10:48  * gmaxwell cries
11612018-10-18T23:10:51  <gmaxwell> https://www.reddit.com/r/Bitcoin/comments/9pcfwu/full_node_slow_to_sync_help_needed/
11622018-10-18T23:10:54  <gmaxwell> all the bad advice
11632018-10-18T23:11:31  <meshcollider> promag: I'll review #14350 after you've rebased it too
11642018-10-18T23:11:33  <gribble> https://github.com/bitcoin/bitcoin/issues/14350 | Add WalletInfo class by promag · Pull Request #14350 · bitcoin/bitcoin · GitHub
11652018-10-18T23:12:17  *** Guyver2 has quit IRC
11662018-10-18T23:12:21  <meshcollider> heh, just as I say that...
11672018-10-18T23:13:03  <promag> can you add refactoring label to 14350?
11682018-10-18T23:13:42  <promag> thanks
11692018-10-18T23:18:43  <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
11702018-10-18T23:18:46  <gwillen> advide*
11712018-10-18T23:18:52  <gwillen> ... spelling.
11722018-10-18T23:22:58  *** Zenton has quit IRC
11732018-10-18T23:23:50  *** clarkmoody has joined #bitcoin-core-dev
11742018-10-18T23:24:19  <booyah> wumpus: gmaxwell: actually, ((int)1) << ((int)31) is *not* UB, it is fully defined
11752018-10-18T23:24:49  <booyah> as smart people on ##c++ confirmed my suspicion that UBSAN doesn't cmplain about that operation
11762018-10-18T23:24:55  <booyah> legal because: http://eel.is/c++draft/expr.shift#2.sentence-3
11772018-10-18T23:24:58  <gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
11782018-10-18T23:25:06  <sipa> booyah: i believe it is undefined by the C++11 spec, and not in C++14
11792018-10-18T23:25:34  <sipa> booyah: that is new language in C++14
11802018-10-18T23:26:07  <sipa> C++11 just says if the result of a shift is not representable in a signed type, it is UB
11812018-10-18T23:26:55  <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
11822018-10-18T23:27:57  *** clarkmoody has quit IRC
11832018-10-18T23:31:37  <booyah> yeap ok UB in 11.
11842018-10-18T23:36:02  <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.
11852018-10-18T23:38:39  <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.
11862018-10-18T23:39:31  <sipa> gwillen: yes
11872018-10-18T23:39:46  <sipa> gwillen: though it can definitely be improved
11882018-10-18T23:40:38  <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
11892018-10-18T23:41:06  <sipa> or in other words, when a single peer is the reason why the window can't advance, that peer is kicked
11902018-10-18T23:41:06  <gwillen> ahh hmm, so it could take awhile to trigger the kick
11912018-10-18T23:41:13  <gwillen> and if it's two peers you still lose
11922018-10-18T23:41:22  <sipa> if you have 2 equally slow peers this logic will never kick in practice
11932018-10-18T23:41:29  <sipa> only when one is significantly slower than all others
11942018-10-18T23:41:56  *** promag has quit IRC
11952018-10-18T23:42:25  <gwillen> I suspect one benefit of restarting during IBD may be related to Comcast peers (or others with a similar scheme)
11962018-10-18T23:42:31  <phantomcircuit> gwillen, restarting can actually break that logic and make things take longer
11972018-10-18T23:42:35  <gwillen> they get some kind of temporary bandwidth boost good for a limited number of bytes
11982018-10-18T23:42:38  <gwillen> and then they get throttled
11992018-10-18T23:42:41  <gwillen> (is my understanding)
12002018-10-18T23:42:50  <gwillen> designed to cheat speedtests, if one is cynical
12012018-10-18T23:43:37  <phantomcircuit> gwillen, "BOOST!"
12022018-10-18T23:43:45  <phantomcircuit> yeah that's literally what it's designed to do
12032018-10-18T23:44:40  <gmaxwell> gwillen: the fastest computers we've ever run this on can't sync at more than 50mbit/sec due to other limits.
12042018-10-18T23:45:01  <gmaxwell> so that requires 6mbit/sec service from 8 peers, which isn't asking for that much.
12052018-10-18T23:47:36  <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
12062018-10-18T23:48:12  <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
12072018-10-18T23:48:30  <phantomcircuit> gmaxwell, yeah i think the main issue is actually aws nodes
12082018-10-18T23:48:43  <phantomcircuit> there they can give you recent blocks but have multi second latency to get old blocks
12092018-10-18T23:54:29  <sipa> gwillen: also, a window of 1024 blocks is ginormous for recent blocks
12102018-10-18T23:54:37  <gwillen> *nods*
12112018-10-18T23:54:40  <sipa> (but kinda small for the first 100000 blocks or so...)
12122018-10-18T23:58:44  *** Bullit has quit IRC