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