--- Day changed Sun Jul 24 2016
00:48 < jonasschnelli> [09:47:47]  <goatpig>	[04:21:48] any reason ChaCha20-Poly1305 was picked over AES-GCM?
00:48 < jonasschnelli> ChaCha20-Poly1305 is also faster
00:50 -!- murch [~murch@p4FE38D8B.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
00:52 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:15 < gmaxwell> The recommendation sipa and I made is because it is considerably faster on anything without hardware AES.
01:15 < gmaxwell> And the devices with hardware AES it is only slightly slower, and those devices we largely don't care about how fast it is (as they're faster hardware)
01:16 < gmaxwell> helpfully it also requires very little code for a good implementation. The same can't really be said for AES-GCM.
01:30 < adiabat> also stream cipher beats block cipher any day of the week (imho)
01:31 < gmaxwell> both are stream ciphers.
01:31 < adiabat> well, AES isn't... GCM sortof makes it into one
01:32 < gmaxwell> There is no sort of, there. And what was being discussed was AES-GCM not AES-CBC or otherwise.
01:33 < gmaxwell> it is unambigiously a stream cipher. Which is an appropritate tool here even though stream ciphers have a long and well established history of resulting, in practice, in insecure protocols usually because of the fragility of IV handling, and how often developers mishandle them.
01:33 < adiabat> maybe linked to the "very little code", I think using a counter mode to make a stream cipher is more complex than starting with one
01:36 < gmaxwell> much of the code complexity for AES-GCM comes from sidechannel resistance for AES being hard, especially if performance must be maintained. chach20 (which is _also_ a block cipher in CTR mode internally) is unusually simple however.
01:38 < adiabat> I mean, I understand that the code is what matters but if you look up "AES", people call it a block cipher, and "chacha20", people call a stream cipher
01:38 < adiabat> I guess chacha20 is more specified than aes, which has a plethora of modes
01:40 < adiabat> You can certainly shoot yourself in the foot with any of them though
02:02 < sipa> adiabat: chacha20 is internally also a block transformation, which is being used in counter mode
02:10 < sipa> except there is no standardization for the pure transformation
02:11 < sipa> NicolasDorier: what is your db cache?
02:11 < NicolasDorier> kept default
02:12 < NicolasDorier> good idea, trying to change it to see how it goes
02:16 < sipa> it helps massively on systems with slow io
02:17 < NicolasDorier> just changed to 1024 to see how it goes
02:26 < NicolasDorier> does not seems to improve it that much... It may come from some kind of IO threshold I may be hitting on Azure. If nobody experience that it's fine
02:27 < NicolasDorier> this is highly possible, as I have several bitcoind instance as well as an indexer for my blockexplorer on the same machine
02:33 < sipa> are you hitting swap space?
02:35 < NicolasDorier> sipa: nop 
02:36 < NicolasDorier> https://usercontent.irccloud-cdn.com/file/oZYm8TtW/
02:36 < NicolasDorier> my ram seems fine
02:36 < NicolasDorier> and cpu as well
02:36 < NicolasDorier> I'll try on a brand new VM later, I think it is just some IO threshold of azure
02:38 < NicolasDorier> or try to just update the disk to be SSD on the vm, on a separate azure storage account (the threshold "domain"). I think we can disregard my machine for now, if nobody experience such slowness it is probably my VM's fault
02:39 < sipa> are these recent blocks?
02:39 < sipa> or during initial sync?
02:39 < NicolasDorier> initial sync
02:39 < sipa> can you run eith -debug=bench ?
02:39 < NicolasDorier> it is what I did, look the screenshot I sent
02:39 < sipa> oops missed that
02:40 < NicolasDorier> https://usercontent.irccloud-cdn.com/file/oZYm8TtW/
02:41 < sipa> ok, it's spending really all the time fetching inputs
02:41 < NicolasDorier> "connect transactions" mean fetching the inputs ?
02:41 < sipa> yes
02:42 < sipa> well, it does more than that
02:42 < sipa> but fetching inouts is the only slow part
02:43 < NicolasDorier> ok yeah so no worry. I'll try with better hard drive and separate on another azure storage account and see if it is better later
03:18 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev
03:27 -!- Giszmo [~leo@ppp-83-171-170-52.dynamic.mnet-online.de] has joined #bitcoin-core-dev
03:27 < GitHub192> [bitcoin] asteroidsbg opened pull request #8397: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8397
03:40 < GitHub81> [bitcoin] jonasschnelli closed pull request #8397: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8397
03:49 -!- ArthurNumbanumba [~ArthurNum@h247079.upc-h.chello.nl] has joined #bitcoin-core-dev
04:10 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Quit: Textual IRC Client: www.textualapp.com]
04:18 -!- challisto [~challisto@unaffiliated/challisto] has joined #bitcoin-core-dev
05:03 -!- JackH [~Jack@79-73-188-30.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev
05:12 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
05:18 -!- shesek [~shesek@bzq-84-110-33-253.red.bezeqint.net] has quit [Ping timeout: 240 seconds]
05:32 -!- goatpig [56f74bcf@gateway/web/freenode/ip.86.247.75.207] has joined #bitcoin-core-dev
05:39 < goatpig> gmaxwell: adiabat: so to summarize, ChaCha20-Poly1305 has a simpler implementation (less chance of mishandling) and is faster on desktop CPUs.
05:39 < goatpig> is there a stand alone implementation of that cypher or does one have to go to OpenSSL?
05:40 < goatpig> also I see in BIP151 that it allows for negotiating the cypher, so will it support AES-GCM too?
05:48 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]
05:49 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
06:00 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds]
06:17 -!- murch [~murch@p4FE38D8B.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
06:21 -!- shesek [~shesek@bzq-84-110-209-97.cablep.bezeqint.net] has joined #bitcoin-core-dev
06:30 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev
06:33 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
06:34 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
06:36 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]
07:04 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rlkalayxbljsntjy] has joined #bitcoin-core-dev
07:22 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 244 seconds]
07:27 < NicolasDorier> There is a refactoring I am thinking about as part as libconsenus work: Instead of calling UTXOs database directly in the consensus code lazily as we need them, aggressively fetching them before calling consensus functions. This would also mean we can parallelize previous coin fetching more easily. 
07:27 < NicolasDorier> *lazily as we need the previous coins
07:27 < NicolasDorier> might make the Connect Transaction quicker
07:36 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
07:45 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 252 seconds]
08:17 -!- Giszmo [~leo@ppp-83-171-170-52.dynamic.mnet-online.de] has quit [Ping timeout: 250 seconds]
08:19 -!- Giszmo [~leo@ppp-83-171-170-52.dynamic.mnet-online.de] has joined #bitcoin-core-dev
08:33 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
08:46 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 258 seconds]
08:47 < goatpig> can someone answer some more SW related questions?
08:47 -!- ko543 [77ebfc8e@gateway/web/freenode/ip.119.235.252.142] has joined #bitcoin-core-dev
08:49 < sipa> NicolasDorier: that's actually what happens
08:49 < sipa> NicolasDorier: haveinputs gets called first
08:49 < sipa> which loads everything in the cache
08:50 < NicolasDorier> oooh so that's what the dbcache is about ? 
08:50 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
08:50 < NicolasDorier> I thought the dbcache was just about keeping recent output in cache as they have higher chance to get used later
08:51 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
08:58 < sipa> there are several layers of cache :)
09:05 -!- ko543 [77ebfc8e@gateway/web/freenode/ip.119.235.252.142] has quit [Quit: Page closed]
09:22 < sipa> NicolasDorier: there is pcoinsTip
09:23 < sipa> but there is also a second cache in ConnectBlock, which fetches the inputs, does validation, applies the changes to the utxo set to thid 2nd cache
09:23 < sipa> and when validation succeeds, the changes in the 2nd cache are pushed to pcoinsTip
09:23 < sipa> if validatiin fails, the changes in the second cache are discarded
09:35 -!- murch [~murch@p4FE38D8B.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
10:05 -!- AaronvanW [~ewout@D47FA7CC.cm-9-1a.dynamic.ziggo.nl] has joined #bitcoin-core-dev
10:05 -!- AaronvanW [~ewout@D47FA7CC.cm-9-1a.dynamic.ziggo.nl] has quit [Changing host]
10:05 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
10:20 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
11:38 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
11:47 -!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has joined #bitcoin-core-dev
12:11 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]
12:15 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
12:19 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds]
12:23 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
12:53 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
12:53 -!- adiabat [~tx@159.203.193.74] has quit [Remote host closed the connection]
13:35 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
13:36 -!- zooko [~user@c-71-229-205-98.hsd1.co.comcast.net] has quit [Ping timeout: 276 seconds]
13:48 -!- murch [~murch@p4FE38D8B.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
14:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
14:28 -!- a87ry5 [~a87ry5@cpe-158-222-198-108.nyc.res.rr.com] has joined #bitcoin-core-dev
14:49 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
14:57 < gmaxwell> ::sigh:: cookie auth picks passwords which are apparer to be incompatible with the python json rpc stuff. (apparently it can't handle passwords with / in them)
15:00 < sipa> file an issue
15:01 < sipa> this sounds like a simple introduction task
15:02 < gmaxwell> I think the bug is in some python URL lib, though for the code that provided recommended rpcpasswords in the past I used base58 in order to avoid any characters that would get mishandled in URLs.
15:04 < sipa> we need base66 code
15:05 < sipa> there are 66 url-safe characters (a-z, A-Z, 0-9, _, -, ., ~)
15:07 < gmaxwell> https://github.com/bitcoin/bitcoin/issues/8399
15:07 < gmaxwell> base58 is fine.
15:15 < sipa> but but but 3.18% less space efficient for the same information density
15:22 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
15:25 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
15:28 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
15:28 -!- justanot1eruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
15:28 -!- d_t [~textual@185.69.203.10] has quit [Client Quit]
15:35 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds]
15:37 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:38 < GitHub87> [bitcoin] yurizhykin opened pull request #8400: [qa]: enable rpcbind_test (master...rpcbind-test) https://github.com/bitcoin/bitcoin/pull/8400
15:39 < gmaxwell> sipa: who cares. :P
15:40 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
15:46 -!- justanot1eruser is now known as justanotheruser
15:46 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 276 seconds]
16:05 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Read error: Connection reset by peer]
16:12 < Chris_Stewart_5> When checking signatures for a SIGHASH_ALL, do you remove all inputs AFTER the input index you are checking?
16:16 -!- challisto [~challisto@unaffiliated/challisto] has quit [Quit: Leaving]
16:17 < sipa> check the code :)
16:18 < sipa> there are two versiond
16:18 < sipa> one in script/interpreter, one in test/sighash_testz
16:27 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
16:28 -!- Cheeseo [~x@c-174-59-210-71.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
16:28 -!- Cheeseo [~x@c-174-59-210-71.hsd1.pa.comcast.net] has quit [Changing host]
16:28 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
16:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
16:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:40 < Chris_Stewart_5> sipa: Does it make sense to have a correct r value when creating a digital signature but an incorrect s value (and that is not related to low-s)? 
16:41 -!- jiggalator [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
16:42 -!- jiggalator is now known as netsin_
16:48 -!- netsin_ [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
16:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2]
16:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
16:50 -!- Giszmo [~leo@ppp-83-171-170-52.dynamic.mnet-online.de] has quit [Quit: Leaving.]
16:51 < sipa> Chris_Stewart_5: make sense for whatm
16:52 < sipa> every value for r can be correct
16:52 < Chris_Stewart_5> hmm yeah, I guess I don't know really what I am trying to say. It seems strange that only one of the values would be incorrect on a signature and not both of them 
16:52 < sipa> you can't individually judge them
16:52 < Chris_Stewart_5> when trying to recreate a digital signature from bitcoin core 
16:53 < sipa> your r is right but the s is not?
16:53 < Chris_Stewart_5> yes
16:53 < Chris_Stewart_5> and it is not due to low-s, i've made to sure to check that
16:53 < sipa> can you paste the signature?
16:53 < Chris_Stewart_5> sure, i'll paste the correct one the one i have generated
16:58 < Chris_Stewart_5> http://pastebin.com/L9veUyXV
17:11 < Chris_Stewart_5> It seems that both values would be incorrect if I had generated the incorrect tx hash for signing..
17:14 < sipa> you generated the k value yourself using rfc6979?
17:15 < Chris_Stewart_5> I'm importing the key from bitcoin core's WIF format, I used dumpprivkey. Did I screw something up along the way? 
17:15 < sipa> is the overall signature valid?
17:17 < Chris_Stewart_5> Hmm no it doesn't look so. 
17:19 < Chris_Stewart_5> Welp that at least narrows it down. I didn't realize that the r value would be correct even if the key is incorrect 
17:20 < sipa> maybe you should first try to make your code generate valid sognatures
17:20 < sipa> before trying to mimick the signatures another implementation creates
17:20 < sipa> *signatures
17:21 < Chris_Stewart_5> sipa: It does generate valid signatures
17:21 < sipa> apparently not
17:22 < sipa> you're generating a signature that is different from the one created by bitcoin core
17:22 < sipa> and it's not due to low-s
17:22 < sipa> only one of both can be valid in that case
17:25 < Chris_Stewart_5> But having the r value be correct (in accordance to bitcoin core) and the s value incorrect seems like a strange case. Any way I'm going to investigate further and play with core's signing message functionality
17:25 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rlkalayxbljsntjy] has quit [Quit: Connection closed for inactivity]
17:34 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
17:34 < Chris_Stewart_5> thanks for the guidance / help
17:34 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
17:48 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
17:49 -!- netsinn is now known as netsin_
17:50 -!- netsin_ [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
17:53 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
18:00 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
18:34 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
18:39 -!- face_ [~face@mail.hmel.org] has quit [Read error: Connection reset by peer]
18:46 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 260 seconds]
18:49 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]
18:50 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev
18:54 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
19:02 -!- goatpig [56f74bcf@gateway/web/freenode/ip.86.247.75.207] has quit [Quit: Page closed]
19:20 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
19:20 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
19:34 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
19:56 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
20:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
20:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
20:30 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds]
21:01 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has joined #bitcoin-core-dev
21:18 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
21:32 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Disconnected by services]
21:32 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
21:38 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
21:40 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
21:50 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
21:50 -!- d_t [~textual@185.69.203.10] has quit [Client Quit]
21:50 -!- adiabat [~tx@159.203.193.74] has joined #bitcoin-core-dev
22:00 -!- d_t [~textual@185.69.203.10] has joined #bitcoin-core-dev
22:03 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
22:37 -!- d_t [~textual@185.69.203.10] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:00 -!- a87ry5 [~a87ry5@cpe-158-222-198-108.nyc.res.rr.com] has quit []
23:30 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev
23:30 -!- netsinn [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection]
23:49 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]