12018-08-21T00:03:21  *** lnostdal has quit IRC
  22018-08-21T00:12:22  *** fanquake has joined #bitcoin-core-dev
  32018-08-21T00:13:01  *** Victorsueca has quit IRC
  42018-08-21T00:13:29  <fanquake> cfields I think once #14005 is merged we could just skip to an rc2? Might also be able to get #13968 in before that.
  52018-08-21T00:13:31  <gribble> https://github.com/bitcoin/bitcoin/issues/14005 | [0.17] depends: fix qt determinism by MarcoFalke · Pull Request #14005 · bitcoin/bitcoin · GitHub
  62018-08-21T00:13:32  <gribble> https://github.com/bitcoin/bitcoin/issues/13968 | [wallet] couple of walletcreatefundedpsbt fixes by instagibbs · Pull Request #13968 · bitcoin/bitcoin · GitHub
  72018-08-21T00:14:21  *** Victorsueca has joined #bitcoin-core-dev
  82018-08-21T00:18:02  *** d9b4bef9 has quit IRC
  92018-08-21T00:19:07  *** d9b4bef9 has joined #bitcoin-core-dev
 102018-08-21T00:33:12  *** Aaronvan_ has quit IRC
 112018-08-21T00:43:57  *** AaronvanW has joined #bitcoin-core-dev
 122018-08-21T00:48:59  *** AaronvanW has quit IRC
 132018-08-21T01:16:16  *** fanquake has quit IRC
 142018-08-21T01:16:26  *** justanotheruser has quit IRC
 152018-08-21T01:23:38  *** fanquake has joined #bitcoin-core-dev
 162018-08-21T01:25:57  *** justanotheruser has joined #bitcoin-core-dev
 172018-08-21T01:26:26  *** fanquake has quit IRC
 182018-08-21T01:44:45  *** AaronvanW has joined #bitcoin-core-dev
 192018-08-21T01:48:59  *** AaronvanW has quit IRC
 202018-08-21T03:44:44  *** Jmabsd has joined #bitcoin-core-dev
 212018-08-21T03:44:56  *** phwalkr has joined #bitcoin-core-dev
 222018-08-21T03:45:36  <Jmabsd> Where is Bitcoin Core's serialization and deserialization code for values in various structures such as transactions, block headers, and protocol data?  This code shows the endianness used
 232018-08-21T03:46:24  *** AaronvanW has joined #bitcoin-core-dev
 242018-08-21T03:46:31  <luke-jr> serialization.h and the various class headers
 252018-08-21T03:48:11  <Jmabsd> luke-jr: great - in what cases (except for TCP/IP ip:s and ports) is small endian *not* useD?
 262018-08-21T03:49:02  <sipa> everything in bitcoin uses little endian
 272018-08-21T03:49:04  <sipa> *but*
 282018-08-21T03:49:27  <sipa> the output of hash functions is seen as byte arrays, which are just serialized byte-per-byte
 292018-08-21T03:49:59  <sipa> (SHA256 internally uses big endian, but that's black box - it's a function that takes as input a byte array and produces another byte array from bitcoin's pov)
 302018-08-21T03:50:19  *** Krellan has quit IRC
 312018-08-21T03:52:07  *** AaronvanW has quit IRC
 322018-08-21T03:54:48  <Jmabsd> sipa, the SHA256 specific about Bitcoin is why you need to byte-reverse most(all?) SHA256 libraries' results within Bitcoin merkle tree merkle node calculations, right?
 332018-08-21T03:55:12  *** gribble has quit IRC
 342018-08-21T03:55:19  <sipa> Jmabsd: no
 352018-08-21T03:55:20  <gmaxwell> what? no.
 362018-08-21T03:55:47  <sipa> Jmabsd: for human consumption the bytes are sometimes printed in reverse order
 372018-08-21T03:55:59  <sipa> but inside the protocol and data structures, there is never any swapping
 382018-08-21T03:57:29  <Jmabsd> endianness is so comical, smartphones (ARM) are big endian, derp. :))
 392018-08-21T03:57:54  <gmaxwell> I don't believe any smartphone is BE.
 402018-08-21T03:58:08  <gmaxwell> (ARM can run in BE mode or LE mode, but the smartphones all use them in LE mode)
 412018-08-21T03:58:21  <gmaxwell> (as does virtually all modern stuff)
 422018-08-21T03:58:50  <sipa> iOS and Android are LE
 432018-08-21T03:59:39  <Jmabsd> wait, where are Bitcoin Core's logics to actually enforce little-endian serialization   - say I run Bitcoin Core on an ARM.. is this the line that will cause the big endian (native to my computer) to little endian (serialization form) conversoin: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L89 ?
 442018-08-21T04:00:13  <sipa> yes
 452018-08-21T04:00:19  <sipa> htole means "host to little endian"
 462018-08-21T04:00:40  <sipa> on LE systems that function is a dummy; on BE systems it does a byteswap
 472018-08-21T04:01:02  <Jmabsd> right so, posix stipulates these, https://linux.die.net/man/3/htole32 , right.
 482018-08-21T04:01:04  <Jmabsd> cool!
 492018-08-21T04:03:23  *** gribble has joined #bitcoin-core-dev
 502018-08-21T04:04:54  <luke-jr> Jmabsd: actually, htole32 isn't POSIX
 512018-08-21T04:05:27  <Jmabsd> luke-jr: oh you are right, but instead, .." functions are **expected** to conform to a future version of IEEE Std 1003.1 (“POSIX.1”). The other functions are extensions that should not be used when portability is required. "
 522018-08-21T04:07:46  <Jmabsd> (this may be more of a #bitcoin question), what is an authoritative reference on that the DER signature's max size is 72 bytes?     i see some discussion like this https://bitcoin.stackexchange.com/questions/12554/why-the-signature-is-always-65-13232-bytes-long  but it's not super clea.r
 532018-08-21T04:08:17  <Jmabsd> sipa writes in this thread that "This results in 71 bytes signatures (on average)" - but what's the max
 542018-08-21T04:08:21  <Jmabsd> and why
 552018-08-21T04:09:13  <sipa> Jmabsd: the R and S value are 256-bit values, which are at most 33 bytes when encoded in DER
 562018-08-21T04:09:24  <sipa> then there is 6 bytes of DER headers
 572018-08-21T04:09:36  <sipa> and bitcoin adds a 1 byte sighash to the end
 582018-08-21T04:09:51  <sipa> so together 33+33+6+1 = 73 max
 592018-08-21T04:10:31  <sipa> however, since the introduction of the low-s rule (which is just policy, not a consensus rule), S values are at most 255 bits, which encodes to at most 32 bytes, reducing the maximum to 72
 602018-08-21T04:11:53  <Jmabsd> aha, so when low-s is not applied, 33B R + 33B S + 6B headers + 1B sighash = 73 bytes
 612018-08-21T04:12:03  <sipa> right
 622018-08-21T04:12:15  <Jmabsd> and with low-s, S (and not R) is 255 instead of 256 bits, meaning 33B R + 32B S + 6B headers + 1B sighash = 72B.
 632018-08-21T04:13:00  <Jmabsd> very well noted thanks!    if you like you can add what you just wrote to me here to that stackexchange thread, as final clarification. thanks for clarifying.
 642018-08-21T04:19:42  *** rls has quit IRC
 652018-08-21T04:24:27  <Jmabsd> sipa: wait, the way this max of 72/73B applies to P2PKH and P2PK sigscripts is... P2PK is only <signature>, since this is <= 75 only one byte for PUSHDATA is needed, and then follows up to **73** bytes of signature data, meaning P2PK may take **74** bytes at most?  and, P2PKH is <signature> <pubkey>, pubkey is normally 33B or for legacy uncompressed 65B, both push-datas are single-byte due to <=75B, and the signature may be **73B**
 662018-08-21T04:24:27  <Jmabsd> so 1 + 73 + 1 + 33/65 = 108 or 140B sigscript max for P2PKH?
 672018-08-21T04:25:18  <Jmabsd> libbitcoin though says "static BC_CONSTEXPR size_t max_der_signature_size = 72;", hm
 682018-08-21T04:25:46  <Jmabsd> ..which is excluding sighash byte, meaning 73B max here too?
 692018-08-21T04:25:57  <sipa> low s is not a consensus rule
 702018-08-21T04:28:37  <Jmabsd> sipa: are the calculations I made about max size sigscript for P2PKH and P2PK (108/140B and 74B) correct?
 712018-08-21T04:29:38  <sipa> i believe they're right
 722018-08-21T04:38:37  *** phwalkr has quit IRC
 732018-08-21T04:39:30  *** phwalkr has joined #bitcoin-core-dev
 742018-08-21T04:39:56  <arubi> just like low is isn't consensus rule, neither is a clean scriptsig for p2pk\p2pkh :)
 752018-08-21T04:42:16  <arubi> er, low *s*
 762018-08-21T04:44:19  *** phwalkr has quit IRC
 772018-08-21T04:53:47  *** Jmabsd has quit IRC
 782018-08-21T04:57:39  *** goatpig has quit IRC
 792018-08-21T05:12:00  *** jtimon has quit IRC
 802018-08-21T05:20:49  *** jtimon has joined #bitcoin-core-dev
 812018-08-21T05:33:02  *** jtimon has quit IRC
 822018-08-21T05:44:22  *** Jmabsd has joined #bitcoin-core-dev
 832018-08-21T05:56:05  <Jmabsd> arubi: wait, what do you mean?
 842018-08-21T06:14:58  <arubi> Jmabsd, I mean yes, you can calculate the maximum size of a signature and a pubkey, and also yes, normally it's only the signature in scriptsig for p2pk and pubkey+signature for p2pkh, but there is no rule that says that other things can't added in a p2pk or p2pkh spend scriptsig
 852018-08-21T06:15:54  *** Krellan has joined #bitcoin-core-dev
 862018-08-21T06:16:46  <luke-jr> wumpus: doc/man/Makefile -AWK = gawk+AWK = mawk
 872018-08-21T06:16:58  *** Jmabsd has quit IRC
 882018-08-21T06:17:11  <arubi> so saying that 108\140 bytes is the maximum size of such a scriptsig is not /wrong/, but it's not consensus accurate.  the only reason I brought it up is because it's the same thing with low s
 892018-08-21T06:18:17  <wumpus> cfields: agree, no need to sign rc1
 902018-08-21T06:18:40  <wumpus> cfields: we can skip over it and do rc2, there's another fix that needs to be merged to IIRC
 912018-08-21T06:18:44  <luke-jr> so I guess I need to uninstall gawk somehow
 922018-08-21T06:18:56  <wumpus> luke-jr: I'm not sure I understand
 932018-08-21T06:19:41  <wumpus> so the difference between awk and gawk causes non-determinism?
 942018-08-21T06:20:22  *** Jmabsd has joined #bitcoin-core-dev
 952018-08-21T06:20:51  <luke-jr> wumpus: gawk and mawk, but yes
 962018-08-21T06:21:10  <luke-jr> if gawk is found, configure prefers it, and it ends up in doc/man/Makefile
 972018-08-21T06:21:38  <luke-jr> so I guess the only way to fix it is to either guarantee all base VMs have no gawk, or to always install gawk so they do
 982018-08-21T06:22:07  <wumpus> what bothers me is that the different tool causes a different output
 992018-08-21T06:22:21  <wumpus> the build system is supposed to choose between *equivalent* tools
1002018-08-21T06:22:46  <wumpus> if it makes a difference which one is chosen I think it should reject either one, or we should change the usage so that the output matches
1012018-08-21T06:22:49  <luke-jr> wumpus: I'm sure the tools produce equivalent output
1022018-08-21T06:22:59  <luke-jr> the difference is the command line in the Makefile
1032018-08-21T06:23:00  <wumpus> then why is this a non-determinism issue?
1042018-08-21T06:23:10  <wumpus> how does that affect the executable?
1052018-08-21T06:23:11  <luke-jr> I'm not sure why the Makefile is included in the output
1062018-08-21T06:23:27  <wumpus> oh, me neither, are you sure that file needs to be deterministic at all?
1072018-08-21T06:23:49  *** StopAndDecrypt has quit IRC
1082018-08-21T06:23:51  <wumpus> if it includes a makefile it seems it's an intermediate product for something
1092018-08-21T06:23:55  <luke-jr> I guess that's the real bug
1102018-08-21T06:23:59  <wumpus> yes
1112018-08-21T06:24:08  <luke-jr> the nsis script seems to just include doc/*
1122018-08-21T06:24:59  <wumpus> I think 'make install' is supposed to install the man pages, but not a makefile?!?
1132018-08-21T06:25:40  <luke-jr> it uses @abs_top_srcdir@/doc\*.*
1142018-08-21T06:25:52  <luke-jr> so make install isn't involved
1152018-08-21T06:26:03  *** rex4539 has joined #bitcoin-core-dev
1162018-08-21T06:27:19  <wumpus> right--anyhow, let's try to fix this for rc2 as well
1172018-08-21T06:27:23  <wumpus> thanks for narrowing this down
1182018-08-21T06:28:03  <luke-jr> I suppose the dumbest way would be to delete Makefile* there first, or even all of the man directory (Windows can't view them anyeway?)
1192018-08-21T06:28:18  <luke-jr> I'm not sure what a *good* solution would look like
1202018-08-21T06:28:57  <luke-jr> fwiw, removing gawk implies: The following packages will be REMOVED:  byobu gawk ubuntu-server
1212018-08-21T06:29:20  <luke-jr> so apparently y'all have base VMs without ubuntu-server O.o
1222018-08-21T06:30:51  <Jmabsd> what may arubi have meant by "just like low is isn't consensus rule, neither is a clean scriptsig for p2pk\p2pkh :)"?
1232018-08-21T06:35:34  <wumpus> luke-jr: I think you'd want to delete everything that isn't a man page, isn't there a VARIABLE that has the man page names?
1242018-08-21T06:35:49  <wumpus> luke-jr: and,say, copy those instead of everything
1252018-08-21T06:36:47  <Jmabsd> (ah he responded on #bitcoin, great.)
1262018-08-21T06:38:23  <luke-jr> wumpus: uh? Windows users want everything except the manpages I would think
1272018-08-21T06:40:59  <wumpus> src/doc only has manpages
1282018-08-21T06:41:18  <wumpus> so if you don't want the manpages then yes you can skip the entire directory
1292018-08-21T06:42:08  <luke-jr> it's just doc/ not src/doc/
1302018-08-21T06:42:24  <luke-jr> src/doc/ doesn't exist <.<
1312018-08-21T06:42:32  <luke-jr> doc/ has the various README files etc
1322018-08-21T06:44:02  <wumpus> ok
1332018-08-21T06:44:31  <wumpus> yes, this is a drawback of not explicitly listing files but using wildcards, cfields has been discouraging those for about forever :)
1342018-08-21T06:45:49  <luke-jr> don't see a nice way to delete stuff :x
1352018-08-21T06:46:40  <luke-jr> maybe /x Makefile* for now
1362018-08-21T06:46:43  *** StopAndDecrypt has joined #bitcoin-core-dev
1372018-08-21T06:46:51  <luke-jr> http://nsis.sourceforge.net/Reference/File
1382018-08-21T06:47:18  <luke-jr> I guess /x man might work too
1392018-08-21T06:47:26  <luke-jr> if we definitely don't want the manpages install
1402018-08-21T06:49:33  *** karelb has joined #bitcoin-core-dev
1412018-08-21T06:51:17  *** vexbuy has joined #bitcoin-core-dev
1422018-08-21T06:52:14  <wumpus> I'd prefer to exclude copying the makefile instead of deleting it
1432018-08-21T06:52:28  <wumpus> yes
1442018-08-21T06:52:48  <wumpus> excluding it from the archive would work too I suppose
1452018-08-21T06:53:21  <luke-jr> wumpus: want to make a branch we both build and compare? ;)
1462018-08-21T06:55:46  <luke-jr> I pushed fix_nsis_makefile to my github
1472018-08-21T06:55:52  <luke-jr> pushing*
1482018-08-21T07:11:41  *** peevsie has quit IRC
1492018-08-21T07:12:07  *** peevsie has joined #bitcoin-core-dev
1502018-08-21T07:29:27  *** Jmabsd has quit IRC
1512018-08-21T07:43:22  *** MarcoFalke has quit IRC
1522018-08-21T07:44:18  *** MarcoFalke has joined #bitcoin-core-dev
1532018-08-21T07:45:26  *** itaseski has joined #bitcoin-core-dev
1542018-08-21T07:47:41  *** vexbuy has quit IRC
1552018-08-21T07:48:16  *** vexbuy has joined #bitcoin-core-dev
1562018-08-21T07:48:52  *** AaronvanW has joined #bitcoin-core-dev
1572018-08-21T07:51:27  <wumpus> sure, I can build that
1582018-08-21T07:51:48  *** vexbuy_ has joined #bitcoin-core-dev
1592018-08-21T07:52:44  *** vexbuy has quit IRC
1602018-08-21T07:53:30  *** AaronvanW has quit IRC
1612018-08-21T07:57:03  *** AaronvanW has joined #bitcoin-core-dev
1622018-08-21T08:00:36  *** vexbuy_ has quit IRC
1632018-08-21T08:01:11  *** vexbuy has joined #bitcoin-core-dev
1642018-08-21T08:05:46  *** vexbuy has quit IRC
1652018-08-21T08:11:01  *** d9b4bef9 has quit IRC
1662018-08-21T08:12:08  *** d9b4bef9 has joined #bitcoin-core-dev
1672018-08-21T08:15:46  *** SopaXorzTaker has joined #bitcoin-core-dev
1682018-08-21T08:18:29  <wumpus> promag: whoops, sorry about making #13529 need rebase again, we really need to get that in--asap
1692018-08-21T08:18:32  <gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub
1702018-08-21T08:23:57  *** elichai2 has joined #bitcoin-core-dev
1712018-08-21T08:25:03  *** Krellan has quit IRC
1722018-08-21T08:26:00  *** Krellan has joined #bitcoin-core-dev
1732018-08-21T08:43:45  *** csknk has joined #bitcoin-core-dev
1742018-08-21T08:46:14  *** promag has joined #bitcoin-core-dev
1752018-08-21T08:47:26  <promag> wumpus: rebased #13529
1762018-08-21T08:47:28  <gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub
1772018-08-21T08:53:21  <promag> wumpus: I also think #13501 should go as soon as possible
1782018-08-21T08:53:22  <gribble> https://github.com/bitcoin/bitcoin/issues/13501 | Correctly terminate HTTP server by promag · Pull Request #13501 · bitcoin/bitcoin · GitHub
1792018-08-21T09:05:00  <stevenroose> What is the guideline for using the UniValue [] operator or find_value?
1802018-08-21T09:07:20  <wumpus> stevenroose: [] is for indexing arrays, find_value for finding a value associated to a key in an object, IIRC
1812018-08-21T09:07:56  <wumpus> I don't think it's posbbile to use them interchangably
1822018-08-21T09:18:28  <stevenroose> wumpus: I found these lines almost underneath each other
1832018-08-21T09:18:30  <stevenroose> UniValue error = find_value(reply, "error");
1842018-08-21T09:18:40  <stevenroose> UniValue result = reply["result"];
1852018-08-21T09:18:49  <stevenroose> Reply object is the same, it's an RPC response.
1862018-08-21T09:18:53  *** vexbuy has joined #bitcoin-core-dev
1872018-08-21T09:19:33  <stevenroose> Looking at the implementation of both, they both seem to do the same in a different way :/
1882018-08-21T09:20:31  <stevenroose> wumpus: https://gist.github.com/stevenroose/b5a9a79e84bb949b08112d560ccec9e0
1892018-08-21T09:22:25  <stevenroose> Something else: the RPC error code RPC_IN_WARMUP, once one call does not respond with that code, can one assume all other calls to also not give it? I.e. do different RPC calls have different warmup times?
1902018-08-21T09:23:16  *** alicehatesbob has joined #bitcoin-core-dev
1912018-08-21T09:23:56  <stevenroose> Hmm, looking at the few times that variable is used, it seems to be a global one-time thing
1922018-08-21T09:27:48  <wumpus> I'd personally prefer find_value to override operator magic, but that's just my opinion, if they do effectively the same then I wouldn't know
1932018-08-21T09:28:37  <wumpus> stevenroose: yes, warmup is a global process
1942018-08-21T09:30:04  <wumpus> it was introduced to give feedback about the initialization process in bitcoind to RPC clients, a long time ago the RPC server was spun up as last thing after initialization but this meant that the process launching bitcoind had no idea of the status
1952018-08-21T09:31:00  *** lnostdal has joined #bitcoin-core-dev
1962018-08-21T09:51:28  *** math_ has quit IRC
1972018-08-21T09:54:40  <wumpus> so yes, it is valid to poll with a NOP RPC call such as 'echo' until it is out of warmup status, and assume everything after that will work
1982018-08-21T10:23:34  <wumpus> luke-jr: build output for your branch https://0bin.net/paste/JTH+pG9fCKr2zDdL#eiSYVxfEOv7lgguDxAI4AcgqOjNG4REi5m4NqlbgWQz
1992018-08-21T10:31:33  *** intcat has quit IRC
2002018-08-21T10:34:40  *** intcat has joined #bitcoin-core-dev
2012018-08-21T10:37:46  *** Krellan has quit IRC
2022018-08-21T10:38:39  *** Krellan has joined #bitcoin-core-dev
2032018-08-21T10:58:07  *** rex4539 has quit IRC
2042018-08-21T11:12:04  *** belcher_ has joined #bitcoin-core-dev
2052018-08-21T11:44:59  *** rex4539 has joined #bitcoin-core-dev
2062018-08-21T12:11:42  *** itaseski has quit IRC
2072018-08-21T12:11:52  *** someone235 has joined #bitcoin-core-dev
2082018-08-21T12:13:53  <someone235> someone knows what this script tries to test? ["1", "0x01 0x01 EQUAL", "P2SH,STRICTENC", "OK", "The following is useful for checking implementations of BN_bn2mpi"],
2092018-08-21T12:13:58  <someone235> from here https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json#L354
2102018-08-21T12:33:52  *** promag has quit IRC
2112018-08-21T13:06:27  *** vexbuy has quit IRC
2122018-08-21T13:07:03  *** Dizzle has joined #bitcoin-core-dev
2132018-08-21T13:07:05  *** vexbuy has joined #bitcoin-core-dev
2142018-08-21T13:09:02  <wumpus> well at least not BN_nb2mpi, that's an openSSL function and hasn't been used from consensus code for ages
2152018-08-21T13:09:44  <wumpus> still, apparently the goal is to check number conversion
2162018-08-21T13:11:05  *** vexbuy has quit IRC
2172018-08-21T13:23:36  <someone235> wumpus, what do you mean?
2182018-08-21T13:24:13  <someone235> wumpus, you mean it checks if the string parser works correctly?
2192018-08-21T13:26:55  <wumpus> no, I don't actually know, BN_bn2mpi/BN_mpi2bn was used for compact number representation (as in the PoW target), it's not used anywhere in the scripting language
2202018-08-21T13:27:05  <wumpus> and as far as I know, never was
2212018-08-21T13:27:48  <wumpus> but you can be certain it's not about a "string parser", nothing in bitcoin script uses strings
2222018-08-21T13:29:15  *** vexbuy has joined #bitcoin-core-dev
2232018-08-21T13:45:00  <someone235> wumpus, the parser of script_tests.json uses strings
2242018-08-21T13:45:27  <someone235> wumpus, it knows to convert "1" -> OP_1 etc
2252018-08-21T13:48:48  *** jtimon has joined #bitcoin-core-dev
2262018-08-21T13:57:30  *** promag has joined #bitcoin-core-dev
2272018-08-21T14:10:05  *** brianhoffman has quit IRC
2282018-08-21T14:14:27  *** csknk has quit IRC
2292018-08-21T14:16:36  <wumpus> ohh like that, no, there's separate unit tests for that, the script tests are for testing the script system
2302018-08-21T14:21:32  *** rex4539 has quit IRC
2312018-08-21T14:33:42  *** michaelsdunn1 has joined #bitcoin-core-dev
2322018-08-21T14:43:14  *** csknk has joined #bitcoin-core-dev
2332018-08-21T14:55:10  *** Krellan has quit IRC
2342018-08-21T14:55:44  *** Krellan has joined #bitcoin-core-dev
2352018-08-21T15:11:22  *** someone235 has quit IRC
2362018-08-21T15:45:22  *** no_input_found has quit IRC
2372018-08-21T15:45:23  *** SopaXorzTaker has quit IRC
2382018-08-21T15:46:07  *** Amuza has joined #bitcoin-core-dev
2392018-08-21T15:46:21  *** no_input_found has joined #bitcoin-core-dev
2402018-08-21T15:50:33  *** vexbuy_ has joined #bitcoin-core-dev
2412018-08-21T15:53:13  *** Amuza has quit IRC
2422018-08-21T15:53:35  *** vexbuy has quit IRC
2432018-08-21T16:04:51  *** Krellan has quit IRC
2442018-08-21T16:06:34  *** someone235 has joined #bitcoin-core-dev
2452018-08-21T16:22:51  *** promag has quit IRC
2462018-08-21T17:02:24  *** esotericnonsense has quit IRC
2472018-08-21T17:02:48  *** esotericnonsense has joined #bitcoin-core-dev
2482018-08-21T17:33:32  <gmaxwell> kallewoof: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes#partial-spend-avoidance  does this sound okay?
2492018-08-21T17:33:53  <gmaxwell> The earlier text made it sound like there was no change at all if the argument wasn't set.
2502018-08-21T17:39:40  *** Krellan has joined #bitcoin-core-dev
2512018-08-21T17:42:30  *** Amuza has joined #bitcoin-core-dev
2522018-08-21T17:45:13  <kanzure> http://diyhpl.us/wiki/transcripts/london-bitcoin-devs/jnewbery-bitcoin-core-v0.17/
2532018-08-21T17:47:00  *** itaseski has joined #bitcoin-core-dev
2542018-08-21T18:08:03  <luke-jr> wumpus: that's Linux builds.. this is a Windows issue :p
2552018-08-21T18:19:17  *** vexbuy_ has quit IRC
2562018-08-21T18:22:22  *** vexbuy has joined #bitcoin-core-dev
2572018-08-21T18:22:54  *** Krellan has quit IRC
2582018-08-21T18:37:31  *** lifeofguenter has quit IRC
2592018-08-21T18:37:31  *** qrestlove has quit IRC
2602018-08-21T18:37:31  *** nsh has quit IRC
2612018-08-21T18:37:31  *** GAit has quit IRC
2622018-08-21T18:37:31  *** ensign has quit IRC
2632018-08-21T18:39:53  *** lifeofguenter has joined #bitcoin-core-dev
2642018-08-21T18:42:01  *** qrestlove has joined #bitcoin-core-dev
2652018-08-21T18:42:13  *** provoostenator has quit IRC
2662018-08-21T18:42:13  *** sdaftuar has quit IRC
2672018-08-21T18:42:13  *** nejon has quit IRC
2682018-08-21T18:42:13  *** savantgarde has quit IRC
2692018-08-21T18:42:13  *** dlb76 has quit IRC
2702018-08-21T18:42:13  *** udiWertheimer has quit IRC
2712018-08-21T18:42:14  *** Emzy has quit IRC
2722018-08-21T18:42:43  *** nsh- has joined #bitcoin-core-dev
2732018-08-21T18:42:55  *** nsh- is now known as nsh
2742018-08-21T18:45:46  *** dlb76 has joined #bitcoin-core-dev
2752018-08-21T19:02:43  *** belcher_ has quit IRC
2762018-08-21T19:17:45  *** belcher_ has joined #bitcoin-core-dev
2772018-08-21T19:28:25  <jonasschnelli> gmaxwell: I don't feel comfortable with replacing the shake256/fips202 part with sha256 in the nist submitted newhope code (https://github.com/newhopecrypto/newhope/tree/master/ref)
2782018-08-21T19:29:33  <gmaxwell> jonasschnelli: OKAY, don't!
2792018-08-21T19:29:45  <gmaxwell> one of the hash uses in newhope is protocol normative.
2802018-08-21T19:30:05  <gmaxwell> (it sends a random seed, and the other side needs to generate the same random stream from it)
2812018-08-21T19:31:48  <jonasschnelli> Yeah. I think we should keep the fips202/shake256 part
2822018-08-21T19:33:11  <jonasschnelli> I guess we better use the implementation as it is and feed the NEWHOPE_KEY into out HKDF function together with the ECDH secret.
2832018-08-21T19:33:19  *** jhfrontz has quit IRC
2842018-08-21T19:33:20  <jonasschnelli> HKDF( NEWHOPE_KEY || ECDH_KEY)
2852018-08-21T19:34:00  *** helo has quit IRC
2862018-08-21T19:34:00  *** Megumiin has quit IRC
2872018-08-21T19:34:43  <gmaxwell> jonasschnelli: IIRC we need to at a minimum change the implementation to not read /dev/urandom itself.
2882018-08-21T19:35:01  <gmaxwell> though we don't have to do that now, just for testing/review.
2892018-08-21T19:35:26  <jonasschnelli> Yes. RIght.
2902018-08-21T19:35:40  <jonasschnelli> The encryption / protocol V2 implementation is ready (only secp256k1 ecdh), added tests and did exhausting field testing... its ~2014 lines of code already,...
2912018-08-21T19:35:55  <jonasschnelli> I'm not sure if we should load the newhope on top or add it later but within the same release
2922018-08-21T19:37:06  <jonasschnelli> Strategy A would be to publish/alter the BIP with NewHope and implement it within two steps... but I know it's also meh-ish
2932018-08-21T19:38:11  <jonasschnelli> Strategy B would open a +~2600 line pull request with 4 new crypto modules (ECDH, ChaCha, Poly1305, NewHope)
2942018-08-21T19:38:24  *** davex__ has joined #bitcoin-core-dev
2952018-08-21T19:38:40  <gmaxwell> I _expect_ that if no extra deployment logic is needed, adding new hope is litterally a few additional lines, plus dropping in the newhope reference code.  So then at least we could compare there.
2962018-08-21T19:39:11  *** gwillen has quit IRC
2972018-08-21T19:39:11  *** marcoagner has quit IRC
2982018-08-21T19:39:11  *** phantomcircuit has quit IRC
2992018-08-21T19:39:11  *** stevenroose has quit IRC
3002018-08-21T19:39:11  *** sturles has quit IRC
3012018-08-21T19:39:11  *** meshcollider has quit IRC
3022018-08-21T19:39:11  *** p3tr has quit IRC
3032018-08-21T19:39:11  *** sakalli_ has quit IRC
3042018-08-21T19:39:11  *** eenoch has quit IRC
3052018-08-21T19:39:11  *** molz has quit IRC
3062018-08-21T19:39:25  *** gwollon has joined #bitcoin-core-dev
3072018-08-21T19:39:39  <jonasschnelli> Yes. The handshake part is already implemented with maximum flexibility...
3082018-08-21T19:39:50  <jonasschnelli> And the impact on the non-newhope module is minimal
3092018-08-21T19:41:03  <gmaxwell> in any case, my thinking was just that deploying newhope in the inital is simpler than any after the fact addition, but we can see what other people think when the look at the impementation.
3102018-08-21T19:43:23  <jonasschnelli> Yes. Agree.
3112018-08-21T19:44:23  <gmaxwell> implementation*
3122018-08-21T19:45:57  *** stevenroose has joined #bitcoin-core-dev
3132018-08-21T19:46:02  *** phantomcircuit has joined #bitcoin-core-dev
3142018-08-21T19:46:46  *** molz has joined #bitcoin-core-dev
3152018-08-21T19:48:27  *** xHire has quit IRC
3162018-08-21T19:48:27  *** ryanofsky has quit IRC
3172018-08-21T19:49:56  *** ryanofsky has joined #bitcoin-core-dev
3182018-08-21T19:49:58  *** xHire has joined #bitcoin-core-dev
3192018-08-21T19:51:15  *** Victorsueca has quit IRC
3202018-08-21T19:52:25  *** Victorsueca has joined #bitcoin-core-dev
3212018-08-21T19:58:59  *** profmac has joined #bitcoin-core-dev
3222018-08-21T20:00:38  *** LeMiner has joined #bitcoin-core-dev
3232018-08-21T20:01:27  *** Amuza has quit IRC
3242018-08-21T20:03:38  *** Guest11272 has joined #bitcoin-core-dev
3252018-08-21T20:07:30  *** unholymachine has quit IRC
3262018-08-21T20:07:56  *** vexbuy has quit IRC
3272018-08-21T20:08:34  *** vexbuy has joined #bitcoin-core-dev
3282018-08-21T20:11:57  *** karelb_ has joined #bitcoin-core-dev
3292018-08-21T20:12:20  *** jl2012_ has joined #bitcoin-core-dev
3302018-08-21T20:13:53  *** games__ has joined #bitcoin-core-dev
3312018-08-21T20:14:02  *** IGHOR_ has joined #bitcoin-core-dev
3322018-08-21T20:15:26  *** petertod1 has joined #bitcoin-core-dev
3332018-08-21T20:15:35  *** vexbuy has quit IRC
3342018-08-21T20:16:04  *** Amuza has joined #bitcoin-core-dev
3352018-08-21T20:18:19  *** vexbuy has joined #bitcoin-core-dev
3362018-08-21T20:19:27  *** dlb76 has quit IRC
3372018-08-21T20:19:27  *** d9b4bef9 has quit IRC
3382018-08-21T20:19:27  *** karelb has quit IRC
3392018-08-21T20:19:28  *** IGHOR has quit IRC
3402018-08-21T20:19:28  *** Giszmo has quit IRC
3412018-08-21T20:19:28  *** jl2012 has quit IRC
3422018-08-21T20:19:28  *** games_ has quit IRC
3432018-08-21T20:19:28  *** chjj has quit IRC
3442018-08-21T20:19:28  *** petertodd has quit IRC
3452018-08-21T20:19:28  *** karelb_ is now known as karelb
3462018-08-21T20:19:28  *** jl2012_ is now known as jl2012
3472018-08-21T20:19:29  *** games__ is now known as games_
3482018-08-21T20:20:07  *** d9b4bef9 has joined #bitcoin-core-dev
3492018-08-21T20:24:29  *** LeMiner has quit IRC
3502018-08-21T20:25:17  *** chjj has joined #bitcoin-core-dev
3512018-08-21T20:30:46  *** gwollon is now known as gwillen
3522018-08-21T20:52:46  *** dlb76 has joined #bitcoin-core-dev
3532018-08-21T20:58:49  *** sdaftuar has joined #bitcoin-core-dev
3542018-08-21T21:00:35  *** Amuza has quit IRC
3552018-08-21T21:02:35  <luke-jr> https://github.com/bitcoin/bitcoin/pull/14018
3562018-08-21T21:03:57  *** csknk has quit IRC
3572018-08-21T21:18:59  *** Dizzle has quit IRC
3582018-08-21T21:21:20  <gmaxwell> jonasschnelli: if you send me the patch w/ newhope, I can spin it up here and we can addnode each other interop test with PPC too. :)
3592018-08-21T21:22:48  <gmaxwell> I wonder how much bandwidth overhead there would be in making dandelion largely traffic analysis immune
3602018-08-21T21:27:45  <gmaxwell> A way to do that would be to intoduce a new message type "txtrickle" that has a fixed payload size such as 64 bytes. And we'd send these messages to four outbound peers, two of which are our dandelion outedges, at some constant rate R.   If we have stem tx to send, they queue up and ride in these messages. Otherwise, the messages are just filled with zeros.
3612018-08-21T21:28:22  <gmaxwell> Rate R starts at some initial value and adjusts every 24 hours or something to keep tranmission delay low.
3622018-08-21T21:28:42  <gmaxwell> Some information would get leaked by R changing, but not a ton.
3632018-08-21T21:31:11  *** luke-jr has quit IRC
3642018-08-21T21:33:25  <gmaxwell> R should end up being some factor of txn_rate / listeners * dandelion_path length... which would be a really low number.
3652018-08-21T21:34:34  <gmaxwell> So I think that the actual bandwidth overhead might be really low.
3662018-08-21T21:36:39  *** vexbuy has quit IRC
3672018-08-21T21:36:49  *** vexbuy has joined #bitcoin-core-dev
3682018-08-21T21:40:21  *** luke-jr has joined #bitcoin-core-dev
3692018-08-21T21:44:22  *** promag has joined #bitcoin-core-dev
3702018-08-21T21:46:44  <gmaxwell> So, for example... at 4m weight max, assuming constant hashrate, maximum bandwidth of the blockchain is 53kbit/sec. with 10,000 listeners and a stem length of 10, we'd expect each listner to see at most ~53 bits/sec of stem forwarding.
3712018-08-21T21:49:35  <gmaxwell> So the actual rate we need would be really decided by how much latency we were willing to tolerate adding.
3722018-08-21T21:51:48  *** profmac has quit IRC
3732018-08-21T21:52:15  *** profmac has joined #bitcoin-core-dev
3742018-08-21T22:02:17  *** jhfrontz has joined #bitcoin-core-dev
3752018-08-21T22:08:20  *** elichai2 has quit IRC
3762018-08-21T22:12:02  *** Giszmo has joined #bitcoin-core-dev
3772018-08-21T22:12:45  *** someone235 has quit IRC
3782018-08-21T22:16:03  *** Empact has joined #bitcoin-core-dev
3792018-08-21T22:20:23  *** jhfrontz has quit IRC
3802018-08-21T22:37:27  *** michaelsdunn1 has quit IRC
3812018-08-21T22:43:05  *** itaseski has quit IRC
3822018-08-21T23:13:25  *** belcher_ has quit IRC
3832018-08-21T23:26:51  *** profmac has quit IRC
3842018-08-21T23:44:55  *** jhfrontz has joined #bitcoin-core-dev