--- Log opened Tue Aug 21 00:00:46 2018
00:11 -!- peevsie [~peevsie@2604:2000:f18f:e300::2] has quit [Remote host closed the connection]
00:12 -!- peevsie [~peevsie@2604:2000:f18f:e300::2] has joined #bitcoin-core-dev
00:29 -!- Jmabsd [~jmabsd@static-118-252-90.rpnspl.com] has quit [Ping timeout: 272 seconds]
00:43 -!- MarcoFalke [~none@198.12.116.246] has quit [Ping timeout: 268 seconds]
00:44 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev
00:45 -!- itaseski [~itaseski@213.135.176.233] has joined #bitcoin-core-dev
00:47 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
00:48 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
00:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:51 < wumpus> sure, I can build that
00:51 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
00:52 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 256 seconds]
00:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
00:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
01:00 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
01:01 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
01:05 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 256 seconds]
01:11 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
01:12 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
01:15 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
01:18 < wumpus> promag: whoops, sorry about making #13529 need rebase again, we really need to get that in--asap
01:18 < gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub
01:23 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-hhmzrkilieuoxoyo] has joined #bitcoin-core-dev
01:25 -!- Krellan [~Krellan@2601:640:4000:9258:15b9:9c11:dff8:429b] has quit [Read error: Connection reset by peer]
01:26 -!- Krellan [~Krellan@2601:640:4000:9258:15b9:9c11:dff8:429b] has joined #bitcoin-core-dev
01:43 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
01:46 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
01:47 < promag> wumpus: rebased #13529
01:47 < gribble> https://github.com/bitcoin/bitcoin/issues/13529 | Use new Qt5 connect syntax by promag · Pull Request #13529 · bitcoin/bitcoin · GitHub
01:53 < promag> wumpus: I also think #13501 should go as soon as possible
01:53 < gribble> https://github.com/bitcoin/bitcoin/issues/13501 | Correctly terminate HTTP server by promag · Pull Request #13501 · bitcoin/bitcoin · GitHub
02:05 < stevenroose> What is the guideline for using the UniValue [] operator or find_value?
02:07 < wumpus> stevenroose: [] is for indexing arrays, find_value for finding a value associated to a key in an object, IIRC
02:07 < wumpus> I don't think it's posbbile to use them interchangably
02:18 < stevenroose> wumpus: I found these lines almost underneath each other
02:18 < stevenroose> UniValue error = find_value(reply, "error");
02:18 < stevenroose> UniValue result = reply["result"];
02:18 < stevenroose> Reply object is the same, it's an RPC response.
02:18 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
02:19 < stevenroose> Looking at the implementation of both, they both seem to do the same in a different way :/
02:20 < stevenroose> wumpus: https://gist.github.com/stevenroose/b5a9a79e84bb949b08112d560ccec9e0
02:22 < 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?
02:23 -!- alicehatesbob [~aphex@51.179.162.234] has joined #bitcoin-core-dev
02:23 < stevenroose> Hmm, looking at the few times that variable is used, it seems to be a global one-time thing
02:27 < 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
02:28 < wumpus> stevenroose: yes, warmup is a global process
02:30 < 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
02:31 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
02:51 -!- math_ [~mario@p4FCB3FA3.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
02:54 < 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
03:23 < wumpus> luke-jr: build output for your branch https://0bin.net/paste/JTH+pG9fCKr2zDdL#eiSYVxfEOv7lgguDxAI4AcgqOjNG4REi5m4NqlbgWQz
03:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 250 seconds]
03:34 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev
03:37 -!- Krellan [~Krellan@2601:640:4000:9258:15b9:9c11:dff8:429b] has quit [Read error: Connection reset by peer]
03:38 -!- Krellan [~Krellan@2601:640:4000:9258:15b9:9c11:dff8:429b] has joined #bitcoin-core-dev
03:58 -!- rex4539 [~rex4539@2a02:587:3516:600:498b:79b4:c41b:40fe] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
04:12 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
04:44 -!- rex4539 [~rex4539@62.38.35.218] has joined #bitcoin-core-dev
05:11 -!- itaseski [~itaseski@213.135.176.233] has quit [Ping timeout: 256 seconds]
05:11 -!- someone235 [~Simon@unaffiliated/someone235] has joined #bitcoin-core-dev
05:13 < 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"],
05:13 < someone235> from here https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_tests.json#L354
05:33 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
06:06 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
06:07 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev
06:07 -!- vexbuy [~vexbuy@89.39.107.196] has joined #bitcoin-core-dev
06:09 < wumpus> well at least not BN_nb2mpi, that's an openSSL function and hasn't been used from consensus code for ages
06:09 < wumpus> still, apparently the goal is to check number conversion
06:11 -!- vexbuy [~vexbuy@89.39.107.196] has quit [Ping timeout: 240 seconds]
06:23 < someone235> wumpus, what do you mean?
06:24 < someone235> wumpus, you mean it checks if the string parser works correctly?
06:26 < 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
06:27 < wumpus> and as far as I know, never was
06:27 < wumpus> but you can be certain it's not about a "string parser", nothing in bitcoin script uses strings
06:29 -!- vexbuy [~vexbuy@89.39.107.196] has joined #bitcoin-core-dev
06:45 < someone235> wumpus, the parser of script_tests.json uses strings
06:45 < someone235> wumpus, it knows to convert "1" -> OP_1 etc
06:48 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
06:57 -!- promag [~promag@119.70.114.89.rev.vodafone.pt] has joined #bitcoin-core-dev
07:10 -!- brianhoffman [~brianhoff@pool-108-31-201-103.washdc.fios.verizon.net] has quit [Quit: brianhoffman]
07:14 -!- csknk [~csknk@unaffiliated/csknk] has quit [Ping timeout: 240 seconds]
07:16 < wumpus> ohh like that, no, there's separate unit tests for that, the script tests are for testing the script system
07:21 -!- rex4539 [~rex4539@62.38.35.218] has quit [Read error: Connection reset by peer]
07:33 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has joined #bitcoin-core-dev
07:43 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
07:55 -!- Krellan [~Krellan@2601:640:4000:9258:15b9:9c11:dff8:429b] has quit [Read error: Connection reset by peer]
07:55 -!- Krellan [~Krellan@2601:640:4000:9258:15b9:9c11:dff8:429b] has joined #bitcoin-core-dev
08:11 -!- someone235 [~Simon@unaffiliated/someone235] has quit [Ping timeout: 244 seconds]
08:45 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Read error: Connection reset by peer]
08:45 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 256 seconds]
08:46 -!- Amuza [~amuza@212.230.156.111] has joined #bitcoin-core-dev
08:46 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev
08:50 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
08:53 -!- Amuza [~amuza@212.230.156.111] has quit [Ping timeout: 244 seconds]
08:53 -!- vexbuy [~vexbuy@89.39.107.196] has quit [Ping timeout: 240 seconds]
09:04 -!- Krellan [~Krellan@2601:640:4000:9258:15b9:9c11:dff8:429b] has quit [Ping timeout: 276 seconds]
09:06 -!- someone235 [~someone23@unaffiliated/someone235] has joined #bitcoin-core-dev
09:22 -!- promag [~promag@119.70.114.89.rev.vodafone.pt] has quit [Remote host closed the connection]
10:02 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 256 seconds]
10:02 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev
10:33 < gmaxwell> kallewoof: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes#partial-spend-avoidance  does this sound okay?
10:33 < gmaxwell> The earlier text made it sound like there was no change at all if the argument wasn't set.
10:39 -!- Krellan [~Krellan@2601:640:4000:9258:15b9:9c11:dff8:429b] has joined #bitcoin-core-dev
10:42 -!- Amuza [~amuza@212.230.156.111] has joined #bitcoin-core-dev
10:45 < kanzure> http://diyhpl.us/wiki/transcripts/london-bitcoin-devs/jnewbery-bitcoin-core-v0.17/
10:47 -!- itaseski [~itaseski@213.135.176.233] has joined #bitcoin-core-dev
11:08 < luke-jr> wumpus: that's Linux builds.. this is a Windows issue :p
11:19 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
11:22 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
11:22 -!- Krellan [~Krellan@2601:640:4000:9258:15b9:9c11:dff8:429b] has quit [Remote host closed the connection]
11:37 -!- Netsplit *.net <-> *.split quits: GAit, nsh, lifeofguenter, ensign, qrestlove
11:39 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has joined #bitcoin-core-dev
11:42 -!- qrestlove [~qrestlove@2605:6000:eb4a:ef00:454f:112b:9095:f0ea] has joined #bitcoin-core-dev
11:42 -!- Netsplit *.net <-> *.split quits: sdaftuar, nejon, provoostenator
11:42 -!- nsh- [~lol@wikipedia/nsh] has joined #bitcoin-core-dev
11:42 -!- Netsplit *.net <-> *.split quits: udiWertheimer, savantgarde, dlb76
11:42 -!- nsh- is now known as nsh
11:45 -!- dlb76 [~dlb76@unaffiliated/dlb76] has joined #bitcoin-core-dev
12:02 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
12:17 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
12:28 < 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)
12:29 < gmaxwell> jonasschnelli: OKAY, don't! 
12:29 < gmaxwell> one of the hash uses in newhope is protocol normative.
12:30 < gmaxwell> (it sends a random seed, and the other side needs to generate the same random stream from it)
12:31 < jonasschnelli> Yeah. I think we should keep the fips202/shake256 part
12:33 < 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.
12:33 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Ping timeout: 244 seconds]
12:33 < jonasschnelli> HKDF( NEWHOPE_KEY || ECDH_KEY)
12:34 -!- Netsplit *.net <-> *.split quits: Megumiin
12:34 < gmaxwell> jonasschnelli: IIRC we need to at a minimum change the implementation to not read /dev/urandom itself.
12:35 < gmaxwell> though we don't have to do that now, just for testing/review.
12:35 < jonasschnelli> Yes. RIght.
12:35 < jonasschnelli> The encryption / protocol V2 implementation is ready (only secp256k1 ecdh), added tests and did exhausting field testing... its ~2014 lines of code already,...
12:35 < jonasschnelli> I'm not sure if we should load the newhope on top or add it later but within the same release
12:37 < 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
12:38 < jonasschnelli> Strategy B would open a +~2600 line pull request with 4 new crypto modules (ECDH, ChaCha, Poly1305, NewHope)
12:38 -!- davex__ [~user@97.119.150.83] has joined #bitcoin-core-dev
12:38 < 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.
12:39 -!- Netsplit *.net <-> *.split quits: molz, meshcollider, eenoch, marcoagner, gwillen, sturles, stevenroose, p3tr, phantomcircuit, sakalli_
12:39 -!- gwollon [~gwillen@unaffiliated/gwillen] has joined #bitcoin-core-dev
12:39 < jonasschnelli> Yes. The handshake part is already implemented with maximum flexibility...
12:39 < jonasschnelli> And the impact on the non-newhope module is minimal
12:41 < 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.
12:43 < jonasschnelli> Yes. Agree.
12:44 < gmaxwell> implementation*
12:45 -!- stevenroose [~steven@vps.weuste.club] has joined #bitcoin-core-dev
12:46 -!- phantomcircuit [~phantomci@192.241.205.97] has joined #bitcoin-core-dev
12:46 -!- molz [~IRCIdent@unaffiliated/molly] has joined #bitcoin-core-dev
12:48 -!- xHire [~xHire@kos.paskuli.cz] has quit [Ping timeout: 256 seconds]
12:48 -!- ryanofsky [russ@jumpy.yanofsky.org] has quit [Ping timeout: 256 seconds]
12:49 -!- ryanofsky [russ@jumpy.yanofsky.org] has joined #bitcoin-core-dev
12:49 -!- xHire [~xHire@kos.paskuli.cz] has joined #bitcoin-core-dev
12:51 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
12:52 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
12:58 -!- profmac [~ProfMac@2001:470:1f0f:226:f020:6036:b332:771f] has joined #bitcoin-core-dev
13:00 -!- LeMiner [~LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev
13:01 -!- Amuza [~amuza@212.230.156.111] has quit [Ping timeout: 240 seconds]
13:03 -!- Guest11272 [~sturles@unaffiliated/sturles] has joined #bitcoin-core-dev
13:07 -!- unholymachine [~quassel@2601:8c:c003:9f16:f9cb:95da:f0c0:8e79] has quit [Ping timeout: 255 seconds]
13:07 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
13:08 -!- vexbuy [~vexbuy@89.39.107.199] has joined #bitcoin-core-dev
13:11 -!- karelb_ [uid316741@gateway/web/irccloud.com/x-mkfofbuiiybjpdcw] has joined #bitcoin-core-dev
13:12 -!- jl2012_ [sid133844@gateway/web/irccloud.com/x-mspisgraidtswzjf] has joined #bitcoin-core-dev
13:13 -!- games__ [sid99242@gateway/web/irccloud.com/x-rcwnxmphnjjdvpth] has joined #bitcoin-core-dev
13:14 -!- IGHOR_ [~quassel@93.178.216.72] has joined #bitcoin-core-dev
13:15 -!- petertod1 [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has joined #bitcoin-core-dev
13:15 -!- vexbuy [~vexbuy@89.39.107.199] has quit [Remote host closed the connection]
13:16 -!- Amuza [~amuza@212.230.156.111] has joined #bitcoin-core-dev
13:18 -!- vexbuy [~vexbuy@89.39.107.199] has joined #bitcoin-core-dev
13:19 -!- karelb_ is now known as karelb
13:19 -!- jl2012_ is now known as jl2012
13:19 -!- games__ is now known as games_
13:19 -!- Netsplit *.net <-> *.split quits: IGHOR, d9b4bef9, petertodd, dlb76, Giszmo, chjj
13:20 -!- Netsplit over, joins: d9b4bef9
13:24 -!- LeMiner [~LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer]
13:25 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev
13:30 -!- gwollon is now known as gwillen
13:52 -!- dlb76 [~dlb76@unaffiliated/dlb76] has joined #bitcoin-core-dev
13:58 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev
14:00 -!- Amuza [~amuza@212.230.156.111] has quit [Ping timeout: 240 seconds]
14:02 < luke-jr> https://github.com/bitcoin/bitcoin/pull/14018
14:03 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
14:18 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]
14:21 < 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. :)
14:22 < gmaxwell> I wonder how much bandwidth overhead there would be in making dandelion largely traffic analysis immune
14:27 < 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.
14:28 < gmaxwell> Rate R starts at some initial value and adjusts every 24 hours or something to keep tranmission delay low.
14:28 < gmaxwell> Some information would get leaked by R changing, but not a ton.
14:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
14:33 < gmaxwell> R should end up being some factor of txn_rate / listeners * dandelion_path length... which would be a really low number.
14:34 < gmaxwell> So I think that the actual bandwidth overhead might be really low.
14:36 -!- vexbuy [~vexbuy@89.39.107.199] has quit [Read error: Connection reset by peer]
14:36 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
14:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
14:44 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
14:46 < 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. 
14:49 < gmaxwell> So the actual rate we need would be really decided by how much latency we were willing to tolerate adding.
14:51 -!- profmac [~ProfMac@2001:470:1f0f:226:f020:6036:b332:771f] has quit [Read error: Connection reset by peer]
14:52 -!- profmac [~ProfMac@2001:470:1f0f:226:f020:6036:b332:771f] has joined #bitcoin-core-dev
15:02 -!- jhfrontz [~Adium@68.68.26.2.customer.bluemilenetworks.com] has joined #bitcoin-core-dev
15:08 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-hhmzrkilieuoxoyo] has quit [Quit: Connection closed for inactivity]
15:12 -!- Giszmo [~leo@45.232.32.202] has joined #bitcoin-core-dev
15:12 -!- someone235 [~someone23@unaffiliated/someone235] has quit [Ping timeout: 276 seconds]
15:16 -!- Empact [~empact@192-195-80-226.PUBLIC.monkeybrains.net] has joined #bitcoin-core-dev
15:20 -!- jhfrontz [~Adium@68.68.26.2.customer.bluemilenetworks.com] has quit [Quit: Leaving.]
15:37 -!- michaelsdunn1 [~michaelsd@38.126.31.226] has quit [Remote host closed the connection]
15:43 -!- itaseski [~itaseski@213.135.176.233] has quit [Ping timeout: 240 seconds]
16:13 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
16:26 -!- profmac [~ProfMac@2001:470:1f0f:226:f020:6036:b332:771f] has quit [Ping timeout: 276 seconds]
16:44 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev
17:01 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
17:02 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
17:03 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
17:04 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
17:05 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
17:06 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
17:15 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
17:31 -!- profmac [~ProfMac@2001:470:1f0f:226:510c:aa9e:3b83:d01b] has joined #bitcoin-core-dev
17:52 < kallewoof> gmaxwell: We actually disabled the "attempt if fee is same" part for address reuse after review.
17:53 < kallewoof> Sorry, "attempt and do avoidreuse if fee is same" part I mean.
17:53 < kallewoof> s/avoidreuse/avoidpartialspend/
17:57 < kallewoof> gmaxwell: see https://github.com/bitcoin/bitcoin/pull/12257#pullrequestreview-139209710
18:04 -!- peevsie [~peevsie@2604:2000:f18f:e300::2] has quit [Ping timeout: 265 seconds]
18:06 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]
18:27 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
18:29 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
18:30 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Quit: Leaving.]
18:38 < phantomcircuit> gmaxwell, what's the newhope stuff for?
18:39 < sipa> phantomcircuit: post quantum link layer encryption
18:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
18:49 < gmaxwell> Post-quantum might over/undersell it a bit. Its recently become a fashionable design for ephemerial key agreement to make use a hybrid ciphersuite where your key is H(ecc || some thing else), with the rational being that some attacker could be logging all your traffic in the hopes that 20 years from now your ECC group will pratically be broken and the decrypted data will be useful to them.  Majo
18:49 < gmaxwell> r fad is to pick the other thing out of a set of things conjectured to hold up to quantum computers, but it could be helpful against more conventional crypto breaks.
18:51 < gmaxwell> kallewoof: I've reread the whole PR there and I am not seeing the rationale for that.
18:54 < phantomcircuit> gmaxwell, ah
18:54 < phantomcircuit> sipa, ah
18:56 < gmaxwell> In any case, might well turn out that any particular candidate scheme isn't secure against classical computers, much less quantum ones... thus combining it with ECC, so at worst you just waste a bit of cpu and bandwidth.
19:06 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
19:22 -!- Giszmo [~leo@45.232.32.202] has quit [Ping timeout: 252 seconds]
19:37 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev
19:50 -!- Jmabsd [~jmabsd@static-118-252-90.rpnspl.com] has joined #bitcoin-core-dev
19:52 -!- phwalkr [~phwalkr@2001:1284:f019:69b1:4c1a:ead4:8328:6282] has joined #bitcoin-core-dev
19:52 < Jmabsd> Wait, in what situations are sighash bytes not added vs. added, to ecdsa signatures in Bitcoin?  With a sighhash byte the DER signature max size is 73B (if low-s, 72B) whereas without sighash byte the max size is 72B (if low-s, 71B).
19:56 < Jmabsd> ..so "contract endorsement" is DER signature + endorsement byte (= max 73B), and the DER signature is max 72B.
19:59 < sipa> what do you mean by 'situations' ?
19:59 < sipa> every signature in bitcoin script has a sighash byte
20:01 -!- profmac [~ProfMac@2001:470:1f0f:226:510c:aa9e:3b83:d01b] has quit [Ping timeout: 276 seconds]
20:04 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has joined #bitcoin-core-dev
20:05 < Jmabsd> sipa: ah right, so, the zoomed-out situation in Bitcoin is that DER situations are in sigscript, redeem script (part of sigscript right) and P2WSH witness script (input's last witness element), only.
20:05 < sipa> "only" ?
20:05 < sipa> what else is there?
20:05 < Jmabsd> sipa: so those three are the only 'situations', and in each of them there's a sighash byte, and, the OP_CHECKSIG operator processes the sighash byte too.
20:05 < sipa> yes
20:06 < sipa> OP_CHECKSIG and friends all require a sighash byte
20:06 < Jmabsd> and so Bitcoin is really only dealing with the "contract endorsement" structures, and hence in the real world those are 72B+1B sighhash=73B max.
20:06 < Jmabsd> great. thx for confirming.
20:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
20:16 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Ping timeout: 252 seconds]
20:34 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
20:37 < Jmabsd> where is CHashWriter's sourcecode?  hash.h defines the interface but its logics are not in hash.cpp 
20:39 < Jmabsd> the hash used in signing is a single-pass (small-endian? err) SHA256 hash of the signtext  (here, https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1298 ) right?
20:39 < sipa> Jmabsd: hash.h has all of it
20:41 < Jmabsd> oh there we go, CHashWriter wraps CHash256, which is a double-SHA256 hashing facility.
20:41 < Jmabsd> why is double-pass SHA256 used when signing?
20:42 < sipa> Jmabsd: ask satoshi :)
20:42 < Jmabsd> aha.
20:46 < sipa> bitcoin basically everywhere either uses ripemd160(sha256(x)) or sha256(sha256(x))
20:50 < Jmabsd> sipa, right - and normally when you pass around (communicate between parties) a hash, using double-hash is a nice convention as it protects from extension attacks right
20:50 < Jmabsd> however in the particular case of using the hash as input for signature, it doesn't make sense... 
20:50 < Jmabsd> or can some actual utility of double-hashing the signtext when signing be guessed / thought of? 
20:51 < sipa> nope. i believe it is pointless
20:51 < sipa> protecting against length extension attacks is generally a good reason, but it doesn't apply here
20:53 < Jmabsd> aha. 
20:55 < Jmabsd> sipa, two quick off-topic but conceptually related questions, as general guidance for design of any new signing protocols, would you suggest using a single hash instead of double, or could it make sense to recycle Bitcoin's double-hash for symmetry with Bitcoin?     also for guidance for other protocols, if you're going to do a salted hash of some message e.g.   SHA256HMAC(protocolmessage,"SIPAPROTOCOL"),   then for extension 
20:55 < Jmabsd> protection would you do the SHA256HMAC doubly i.e.  SHA256HMAC(SHA256HMAC(protocolmessage,"SIPAPROTOCOL"),"SIPAPROTOCOL") or would you do an inner SHA256 i.e. SHA256HMAC(SHA256(protocolmessage),"SIPAPROTOCOL") ?
20:58 < sipa> Jmabsd: a good guideline is to make sure that the data you're hashing is always deserializable
20:58 < sipa> whenever you're writing things into a hash with self-descriptive lengths, length extension attacks generally don't ezist
20:59 < sipa> and i would use single hashes
20:59 < Jmabsd> ahh so you mean, if your message protocol has the format      <length><message data>,  then noone could meaningfully attack a single-hash anyhow.
21:00 < Jmabsd> because they can't forge the <length> part in a hash anyhow - however, if the message format was just <message data> then they could (given a single hash). noted.
21:00 < Jmabsd> sipa, couldn't double hashing provide some other benefit.. or you mean, hashes may be data-destructive so risk that some rainy day there'd be hash collision attacks could be higher with double-hash or?
21:00 < Jmabsd> like what's motivating arguments in the choice for and against
21:02 < Jmabsd> ..ok so i take your suggestion that single-hash, and have the message format be well-defined and mark out length, should suffice. thanks for suggesting!
21:05 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]
21:06 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev
21:12 -!- rls [~rls@69.197.143.181] has joined #bitcoin-core-dev
21:13 -!- profmac [~ProfMac@2001:470:1f0f:226:510c:aa9e:3b83:d01b] has joined #bitcoin-core-dev
21:16 -!- lone3lf [~lone3lf@179.222.90.216] has joined #bitcoin-core-dev
21:20 < Jmabsd> it would be great if crypto/sha256.cpp's SHA256D64() would be clarified in a comment, what it does exactly (https://github.com/bitcoin/bitcoin/blob/master/src/crypto/sha256.cpp#L698)
21:21 < Jmabsd> it's used in merkle calculation (https://github.com/bitcoin/bitcoin/blob/master/src/consensus/merkle.cpp#L57) and the code in itself presently leaves a little bit of guesswork to the reader about what's going on
21:21 < luke-jr> Jmabsd: SHA256(SHA256(64 bytes))
21:21 < Jmabsd> luke-jr: ah, so an optimized double-SHA256 for a 64-bytes input. so a double-sha256 optimized for merkle node calculation. neat. thanks.
21:22 < Jmabsd> luke-jr: is any particular byte ordering or "endianness" to the SHA256 used here, i've seen some Bitcoin merkle node calculation use byte-reverse logics
21:23 < sipa> Jmabsd: as i've said before, all hash functions are treated as black box that convert from byte arrays to byte arrays
21:23 < sipa> no endianness is relevant
21:23 < gmaxwell> Jmabsd: Sipa already answered this question previously.  The bitcoin protocol uses sha256 exactly as it is.
21:23 < gmaxwell> Asking again won't make the answer change.
21:24 < gmaxwell> oops. didn't mean to pile on.
21:24 < luke-jr> XD
21:24 < sipa> :)
21:24 < gmaxwell> the stuff you're seeing is probably working from hex in UIs or something, and got reversed there.
21:26 < gmaxwell> Bitcoin "UI" hashes are backwards for path dependant but otherwise explicable reasons... 
21:27 < luke-jr> it's probably because the block hash is interpreted as a 256-bit little endian number for target comparison, or something like that
21:28 < Jmabsd> gmaxwell, yes interesting, i see clearly in Bitcoin Core and other implementations that indeed there is no reversing whatsoever, no "endianness" or the like here.  you are right that the code in the wild must have been mitigating some kind of user-facing hex representation quirk.
21:28 < gmaxwell> luke-jr: right, and then you want to print it so that it starts with leading 0s so that the 'less than' comparison makes sense.
21:28 < Jmabsd> i think here it's only about transaction hashes
21:29 < gmaxwell> Jmabsd: the point is that bitcoin's UI uses the same stuff to print all these 256 bit hashes.
21:29 < luke-jr> ^
21:30 < gmaxwell> block hash is interpreted as a 256-bit little endian number for target comparison as luke says, so then bitcoin needed to print it that way too, otherwise the 0s would have been on the right which would have been confusing... and the same code was then used to print other hashes.
21:30 < gmaxwell> But thats just a UI thing.
21:32 < Jmabsd> gmaxwell: ahaaa so for symmetry reasons there's reverse output order of transaction hashes too, i understand - "big endian".
21:32 < Jmabsd> noo, little-endian.
21:33 < Jmabsd> gmaxwell, this applies only to the string representation of block hashes and transaction hashes - any more?
21:34 < luke-jr> Jmabsd: the hash is interpreted little-endian, and printed big-endian. don't try too hard to make endian sense of it or you'll hurt your brain :P
21:35 < Jmabsd> luke-jr: this transformation when providing a string serialization, has it been applied (assumed as convention to be applied) to any more data than block hashes and transaction hashes?
21:36 < luke-jr> off-hand, I don't think we print any other hashes in the UI, but I could be forgetting something
21:38 < sipa> Jmabsd: it's used everywhere hashes are printed for human consumption
21:38 < sipa> so txids and block hashes
21:38 < sipa> also the chainstate hash in gettxoutsetinfo
21:39 < Jmabsd> hash prints.. hm.. ok so it won't apply to other data like merkle tree root printouts? or signatures and such. ok. (y)
21:39 < luke-jr> I'm glad getwork is gone :D
21:40 < luke-jr> Jmabsd: probably there too
21:40 < luke-jr> but that's not really exposed to the user
21:40 < luke-jr> (other than RPC stuff)
21:41 < Jmabsd> aha. ok so the quirk of this reverse ordering UI representation thing, is that transaction hashes have the funny representation order too, and this needs a bit of extra consideration when making a simple example script to calculate merkle nodes, as they need to reverse the byte order of the transaction hash. gotcha.
21:42 -!- ExtraCrispy [~ExtraCris@89.39.105.101] has quit [Ping timeout: 260 seconds]
21:42 < luke-jr> Jmabsd: no, not there
21:43 < sipa> Jmabsd: no, it's only used when printing for human consumption
21:43 < sipa> internally there is no reversing ever 
21:43 < luke-jr> I'm not 100% sure, but I suspect the merkle root is printed reversed in getblock RPC for example; but never internally
21:43 < sipa> oh, yes it is
21:43 < sipa> but again, just when converting to hex
21:45 < Jmabsd> luke-jr, what's the code location for this hex serialization?
21:46 < Jmabsd> (yes I totally see that Bitcoin Core or the Bitcoin protocol never represent data in reverse order internally - it's only a human representation thing)
21:46 < Jmabsd> sipa, right, so it's when you're making a test script on the theme "user enters two+ transaction hashes for you to calculate merkle nodes / merkle root out of it", you take the human-output form as input there.
21:47 < Jmabsd> also when making a block explorer and taking transaction hashes, you take the reverse form as input there too no?
21:47 -!- lone3lf [~lone3lf@179.222.90.216] has quit [Quit: Leaving]
21:50 -!- airplanemod [~checkm8@72.53.14.168] has joined #bitcoin-core-dev
21:52 -!- Rootsudo [~textual@180.191.96.215] has joined #bitcoin-core-dev
21:53 < sipa> Jmabsd: uint256's ToString() method
21:58 < airplanemod> Hey guys, I would like to know if it is possible to set up a development environment for bitcoin-qt and/or bitcoind that will allow me to set breakpoints and step through live code as it is running? I cannot seem to find a tutorial or any good starting point for how to do this. I have been testing my own edits in a simple text editor and using gitian builder to compile and test using 
21:58 < airplanemod> the debug.log file but that is tedious and time-consuming work. Can anyone give any tips or pointers for how I might get a proper developement environment set up for testing?
22:01 < sipa> airplanemod: sure, you can run bitcoind in gdb or so
22:01 < sipa> setting up a development environment isn't very bitcoin core specific, so i wouldn't say is on topic here
22:02 < sipa> but it's no different than other c/c++ projects
22:03 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-core-dev
22:04 -!- phwalkr [~phwalkr@2001:1284:f019:69b1:4c1a:ead4:8328:6282] has quit [Remote host closed the connection]
22:06 < airplanemod> ok thanks for replying sipa. Ive done tons of development but never touched c++ so I wasnt sure if there was a recommended IDE or anything specific that would cater to blockchain dev specifically or if its easier on linux vs windows for example
22:08 < sipa> airplanemod: bitcoin core is primarily developed on unix systems (and the windows binaries are produced through cross compiling on linux)
22:08 -!- Jmabsd [~jmabsd@static-118-252-90.rpnspl.com] has quit [Ping timeout: 240 seconds]
22:08 < sipa> you can use an IDE if you like, but i believe most developers use just text editors
22:11 < luke-jr> I use a text editor with syntax highlighting
22:11 < airplanemod> sipa: thats kind of what I was wondering about. so most developers are editing the source and then building binary executable files to test their changes? thats what Ive been doing up to now but I consider that to be working blind
22:11 -!- windsok [~windsok@unaffiliated/windsok] has quit [Remote host closed the connection]
22:12 < sipa> yes, i just use a text editor
22:12 < airplanemod> im guessing because of the complexity of how the bicoin wallet works that it isnt possible to run it in a debugger. i couldnt find any info online to suggest this would be possible which is why i came here to ask
22:12 < luke-jr> I'm not aware of any way to modify code at runtime
22:13 < luke-jr> airplanemod: running it in a debugger just works
22:13 < luke-jr> (in valgrind, is a bit more painful..)
22:13 < airplanemod> luke-jr: not modify code at runtime but see the contents of variables
22:15 < sipa> airplanemod: i occasionally run bitcoind in a debugger
22:16 < sipa> which lets you put breakpoints and see the contents of variables etc
22:16 < sipa> inside functional tests it's harder though, as they spin up multiple communicating bitcoinds
22:17 < airplanemod> sipa: is that with gbd? (i havent used gdb before but i did come across it already tonight in my search)
22:17 < luke-jr> while ! gdb -p $(ps ax | grep node0 | cut -b 1-5); do true; done
22:17 < luke-jr> <.<
22:17 < sipa> airplanemod: yes, gdb
22:18 < airplanemod> great, thanks guys. I will look into gdb and keep using my text editor for qt debugging
22:20 -!- someone235 [~someone23@unaffiliated/someone235] has joined #bitcoin-core-dev
22:22 -!- airplanemod [~checkm8@72.53.14.168] has left #bitcoin-core-dev []
22:25 -!- Krellan [~Krellan@2601:640:4000:9258:6990:ddbb:83a0:d4b9] has joined #bitcoin-core-dev
22:40 -!- Rootsudo [~textual@180.191.96.215] has quit [Ping timeout: 252 seconds]
22:50 -!- phwalkr [~phwalkr@2001:1284:f019:69b1:4c1a:ead4:8328:6282] has joined #bitcoin-core-dev
22:50 -!- phwalkr [~phwalkr@2001:1284:f019:69b1:4c1a:ead4:8328:6282] has quit [Remote host closed the connection]
23:11 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]
23:18 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev
--- Log closed Wed Aug 22 00:00:47 2018