--- Day changed Fri Jan 06 2017 00:00 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 00:08 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 00:24 -!- thib [~thib@wikimedia/Thibaut120094] has quit [Ping timeout: 258 seconds] 00:31 -!- Netsplit *.net <-> *.split quits: sdaftuar, musalbas, Guest26441, trippysalmon, aj, Taek, ratoder, xiangfu, PatBoy, waxwing, (+86 more, use /NETSPLIT to show all of them) 00:34 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-euxyuxjomobthsex] has quit [Ping timeout: 260 seconds] 00:35 -!- so [~so@unaffiliated/so] has quit [Ping timeout: 250 seconds] 00:37 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev 00:37 -!- jyap [~jyap@2604:180:1:7f5::b59a] has joined #bitcoin-core-dev 00:37 -!- thib_ [~thib@ns527631.ip-192-99-32.net] has joined #bitcoin-core-dev 00:37 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 00:37 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 00:37 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 00:37 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 00:37 -!- dermoth [~thomas@dsl-66-36-158-182.mtl.aei.ca] has joined #bitcoin-core-dev 00:37 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zflodhdpeelpsnrl] has joined #bitcoin-core-dev 00:37 -!- tunafizz [tunafizz@c-71-207-55-31.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 00:37 -!- mappum [sid43795@gateway/web/irccloud.com/x-dovkbenqddonujgf] has joined #bitcoin-core-dev 00:37 -!- eragmus [sid136308@gateway/web/irccloud.com/x-dxtwomjijaanfbnz] has joined #bitcoin-core-dev 00:37 -!- aspect_ [sid151486@gateway/web/irccloud.com/x-rodisjcrbevhmfhy] has joined #bitcoin-core-dev 00:37 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-eybphxocnajhfdjv] has joined #bitcoin-core-dev 00:37 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-nexidsjonumbkijr] has joined #bitcoin-core-dev 00:37 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev 00:37 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 00:37 -!- rubensayshi [uid201751@gateway/web/irccloud.com/x-ghpvbmrwzmbsxzkq] has joined #bitcoin-core-dev 00:37 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev 00:37 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev 00:37 -!- Soligor [~Soligor@unaffiliated/soligor] has joined #bitcoin-core-dev 00:37 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev 00:37 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 00:37 -!- paracyst [paracyst@unaffiliated/paracyst] has joined #bitcoin-core-dev 00:37 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 00:37 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has joined #bitcoin-core-dev 00:37 -!- nsh- [~lol@wikipedia/nsh] has joined #bitcoin-core-dev 00:37 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-core-dev 00:37 -!- gielbier [~michiel@2001:981:9573:1:5428:c047:3a2f:e262] has joined #bitcoin-core-dev 00:37 -!- sipa [~pw@vps64477.public.cloudvps.com] has joined #bitcoin-core-dev 00:37 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev 00:37 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev 00:37 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined #bitcoin-core-dev 00:37 -!- Bootvis [bob@baltar.lan.endoria.net] has joined #bitcoin-core-dev 00:37 -!- ill [~ill@32.210.34.9] has joined #bitcoin-core-dev 00:37 -!- PatBoy [xyz@192.99.249.194] has joined #bitcoin-core-dev 00:37 -!- owowo [ovovo@gateway/vpn/mullvad/x-sutgtiqxmxirkvkc] has joined #bitcoin-core-dev 00:37 -!- ryan-c [~ryan@znc.rya.nc] has joined #bitcoin-core-dev 00:37 -!- Eliel_ [~jojkaart@104-250-47-212.rev.cloud.scaleway.com] has joined #bitcoin-core-dev 00:37 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev 00:37 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 00:37 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev 00:37 -!- wvr [~wvr@215.red-83-59-62.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 00:37 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev 00:37 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev 00:37 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:37 -!- kinlo [~peter@unaffiliated/kinlo] has joined #bitcoin-core-dev 00:37 -!- TD-Linux [~Thomas@about/essy/indecisive/TD-Linux] has joined #bitcoin-core-dev 00:37 -!- BCBot_ [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 00:37 -!- da2ce7 [~da2ce7@opentransactions/dev/da2ce7] has joined #bitcoin-core-dev 00:37 -!- adam3us [~adam3us@unaffiliated/adam3us] has joined #bitcoin-core-dev 00:37 -!- phantomcircuit [~phantomci@192.241.205.97] has joined #bitcoin-core-dev 00:37 -!- baldur [~baldur@pool-100-2-139-91.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 00:37 -!- crescendo [~mozart@unaffiliated/crescendo] has joined #bitcoin-core-dev 00:37 -!- thokon00 [~thokon00@gw.linuxit.at] has joined #bitcoin-core-dev 00:37 -!- gluytium [U2FsdGVkX1@ma.sdf.org] has joined #bitcoin-core-dev 00:37 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev 00:37 -!- bad_duck [~arthur@area51.powaaa.com] has joined #bitcoin-core-dev 00:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 00:37 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 00:37 -!- waxwing [~waxwing@62.205.214.125] has joined #bitcoin-core-dev 00:37 -!- juscamarena_ [~justin@47.148.176.74] has joined #bitcoin-core-dev 00:37 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 00:37 -!- tadasv [ttttt@gateway/shell/panicbnc/x-koezlkvmruytqkso] has joined #bitcoin-core-dev 00:37 -!- trippysalmon [~trippy@cyberdynesys.org] has joined #bitcoin-core-dev 00:37 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev 00:37 -!- davec [~davec@cpe-24-243-230-253.hot.res.rr.com] has joined #bitcoin-core-dev 00:37 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev 00:37 -!- norotartagen [~norotarta@71-89-76-184.dhcp.bycy.mi.charter.com] has joined #bitcoin-core-dev 00:37 -!- ratoder [~ratoder@static.111.19.201.138.clients.your-server.de] has joined #bitcoin-core-dev 00:37 -!- JackH [~laptop@79-73-186-204.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 00:37 -!- xiangfu [~xiangfu@223.223.187.142] has joined #bitcoin-core-dev 00:37 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 00:37 -!- OfficialLeibniz [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 00:37 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 00:37 -!- lejitz [uid205154@gateway/web/irccloud.com/x-xnpldnvwaaimiqdn] has joined #bitcoin-core-dev 00:37 -!- nOgAnOo [sid146237@gateway/web/irccloud.com/x-pohyphteesrtsgfy] has joined #bitcoin-core-dev 00:37 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-gdanbzyzmhdawgjl] has joined #bitcoin-core-dev 00:37 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:b89a:ee52:e255:ec7f] has joined #bitcoin-core-dev 00:37 -!- Taek [~quassel@2001:41d0:1:472e::] has joined #bitcoin-core-dev 00:37 -!- murr4y [ali@17.57.211.130.bc.googleusercontent.com] has joined #bitcoin-core-dev 00:37 -!- _mn3monic [~guido@176.9.68.68] has joined #bitcoin-core-dev 00:37 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev 00:37 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-core-dev 00:37 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-caeftmjllkdipuja] has joined #bitcoin-core-dev 00:37 -!- ybit [~ybit@unaffiliated/ybit] has joined #bitcoin-core-dev 00:37 -!- jrayhawk [~jrayhawk@unaffiliated/jrayhawk] has joined #bitcoin-core-dev 00:37 -!- Aleph0 [~User@unaffiliated/amphetamine] has joined #bitcoin-core-dev 00:37 -!- aj [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev 00:37 -!- goregrin1 [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev 00:37 -!- ryanofsky [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 00:37 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev 00:39 -!- jyap [~jyap@2604:180:1:7f5::b59a] has quit [Changing host] 00:39 -!- jyap [~jyap@unaffiliated/jyap] has joined #bitcoin-core-dev 00:39 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 00:40 -!- thib_ [~thib@ns527631.ip-192-99-32.net] has quit [Quit: leaving] 00:40 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 251 seconds] 00:40 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-nexidsjonumbkijr] has quit [Ping timeout: 255 seconds] 00:41 -!- roasbeef [~root@104.131.26.124] has joined #bitcoin-core-dev 00:41 -!- profall [sid29922@gateway/web/irccloud.com/x-irsmqqbwdvhfsmce] has joined #bitcoin-core-dev 00:42 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-phahrsctibqawwii] has joined #bitcoin-core-dev 00:45 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Quit: ZNC - http://znc.in] 00:46 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev 00:47 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Changing host] 00:47 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev 00:47 -!- limpkin [sid20909@gateway/web/irccloud.com/x-ozhydhybwbnfgote] has joined #bitcoin-core-dev 00:51 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-jeclfhbkoqjeehcq] has joined #bitcoin-core-dev 00:55 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 01:14 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 01:17 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev 01:24 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 01:31 -!- goregrin1 is now known as goregrind 01:31 -!- so [~so@unaffiliated/so] has joined #bitcoin-core-dev 01:41 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 01:48 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #7826: [Qt] show conflicts of unconfirmed transactions in the UI (master...2016/04/ui_mem_cflct) https://github.com/bitcoin/bitcoin/pull/7826 01:49 < bitcoin-git> [bitcoin] jonasschnelli closed pull request #7817: [Qt] attribute replaceable (RBF) transactions (master...2016/04/qt_rbf) https://github.com/bitcoin/bitcoin/pull/7817 01:56 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 02:03 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9481: [Qt] Show more significant warning if we fall back to the default fee (master...2017/01/fee_warning) https://github.com/bitcoin/bitcoin/pull/9481 02:13 < btcdrak> jonasschnelli: I'm willing to test those this weekend... 02:14 < jonasschnelli> btcdrak: They need overhaul from my side, don't bother 02:14 < btcdrak> ok 02:14 < jonasschnelli> I'll re-base overhaul them as soon as they rise on my pile-of-work 02:27 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has joined #bitcoin-core-dev 02:46 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 255 seconds] 02:56 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev 03:25 -!- paveljanik [~paveljani@79.98.72.176] has quit [Quit: Leaving] 03:35 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev 04:37 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has left #bitcoin-core-dev [] 05:01 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 05:02 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 05:25 -!- berndj [~berndj@mail.azna.co.za] has joined #bitcoin-core-dev 05:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 05:49 < jonasschnelli> Request for review: #9294 05:49 < gribble> https://github.com/bitcoin/bitcoin/issues/9294 | Use internal HD chain for change outputs (hd split) by jonasschnelli · Pull Request #9294 · bitcoin/bitcoin · GitHub 05:53 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:55 < morcos> gmaxwell: re: CreateTransaction logging, I think thats a great idea. If needed we could even make fee estimation take a bool to output more debugging information for the times its called via CreateTransaction. but even without that, just having the basic info would be nice. 06:04 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [] 06:06 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 06:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 06:23 < jonasschnelli> Idea: would it be stupid to use the first 16 addrs of the dns-seeder DNS response as a "hidden" secp256k1 compact sig for the next 16 addrs of a complete response of 32 addrs? 06:23 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 06:23 < jonasschnelli> Then ship apps with an ec pubkey per seeder (that supports signed dns responses) 06:24 < jonasschnelli> I think this approach would be a simple hack and much less work then switching to DNSSEC 06:26 < sipa> jonasschnelli: i believw intermediate resolvers can reorder/filter responses 06:29 < gmaxwell> s/can/constantly/ 06:30 < gmaxwell> a lot of intermediate resolvers trim the results to just a few, and many (most?) reorder them (e.g. under the assumption that the final device will use the first, then yielding a cached response they reorder to avoid overloading the source). 06:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:39 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:40 -!- BCBot_ [~BCBot@46.101.246.115] has quit [Remote host closed the connection] 06:49 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 06:51 < jonasschnelli> hmm... that unfortunate. 06:55 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 06:58 -!- BCBot [~BCBot@46.101.246.115] has quit [Remote host closed the connection] 06:58 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 07:04 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 07:05 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has joined #bitcoin-core-dev 07:19 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev 07:20 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Excess Flood] 07:20 -!- Alina-malina [~Alina-mal@37.157.216.129] has joined #bitcoin-core-dev 07:22 -!- Alina-malina [~Alina-mal@37.157.216.129] has quit [Changing host] 07:22 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 08:05 -!- whphhg [whphhg@gateway/vpn/mullvad/x-vfbhxndhhvtxnqoi] has joined #bitcoin-core-dev 08:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 08:06 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:12 < jonasschnelli> We do we try to connect to the dnsseeder on 8333? One-shot getaddr? 08:14 < sipa> ? 08:14 < sipa> you mean why does the oneshot concept exist? 08:15 < sipa> if you're connecting over Tor you shouldn't do DNS lookups, as they'd leak your traffic 08:15 < jonasschnelli> sipa: That was the problem! Dam Qt settings... 08:16 < jonasschnelli> Now I also know why my SPV block downloads where slower then expected. :) 08:16 < sipa> so instead we "connect" to the seeder, which in practice means we're connecting to a Tor exit router, and make the router resoove the seeder, and connect tovit 08:16 < sipa> we don't actually learn what IP we're connecting to in that case 08:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 08:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:38 < bitcoin-git> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/f646275b90b1...a55716abe566 08:38 < bitcoin-git> bitcoin/master 50bd12c Gregory Maxwell: Break addnode out from the outbound connection limits.... 08:38 < bitcoin-git> bitcoin/master 90f13e1 Gregory Maxwell: Add release notes for addnode changes. 08:38 < bitcoin-git> bitcoin/master 032ba3f Gregory Maxwell: RPC help documentation for addnode peerinfo.... 08:38 < bitcoin-git> [bitcoin] sipa closed pull request #9319: Break addnode out from the outbound connection limits. (master...addnode_own_count) https://github.com/bitcoin/bitcoin/pull/9319 08:44 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #9483: Complete hybrid full block SPV mode (master...2017/01/spv) https://github.com/bitcoin/bitcoin/pull/9483 08:45 < midnightmagic> \o/ YAYYY 08:45 -!- brg444 [~bergealex@184.151.111.252] has joined #bitcoin-core-dev 08:47 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:50 -!- brg444 [~bergealex@184.151.111.252] has quit [Read error: No route to host] 08:50 -!- brg444 [~bergealex@184.151.111.252] has joined #bitcoin-core-dev 08:53 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 255 seconds] 08:57 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 09:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds] 09:08 < morcos> cfields: just finished reading through 9441, didn't understand your last comment on the PR, you are going to change it back to what? 09:08 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 09:09 < sipa> morcos: the current PR makes ProcessMessages only process one message at a timre 09:09 < morcos> i don't think you need to change it (now) i think its fairly clear any edge case change from current behavior is a net benefit 09:09 < morcos> sipa: but thats what it did before 09:10 < sipa> yes 09:10 < morcos> so you think he should change it to process more than one? 09:10 < sipa> i'd be more confortable with that 09:11 < BlueMatt> you'd be more comfortable with a change in behavior? 09:11 < morcos> that seems like the change to me, possibly a good one, but the PR seems more clearly correct without doing that b/c it doesn't require thinking about that 09:11 < BlueMatt> I mean I agree we should probably do that in the furture, but why change it now? 09:11 < morcos> BlueMatt: +! 09:11 < morcos> 1 09:11 < sipa> i'm confused 09:11 < sipa> the current code processes multiple messages at once 09:11 < BlueMatt> the pr does not change the behavior except for some stupid weird edge cases 09:11 < sipa> his current PR changes that to only process one at a time 09:11 < BlueMatt> specifically, currently, if you have a message with a bad hash, it will process more than once 09:12 < morcos> morcos> sipa: but thats what it did before (meaning master does not process more than one) 09:12 < BlueMatt> but the current code does NOT process more than one message if it calls ProcessMessage 09:12 < sipa> morcos: heh? 09:12 < BlueMatt> (also the pr just disconnects on a bad hash, which I think is a change, but a good one imo) 09:12 < sipa> master does process more than one, unless it's a block 09:12 < BlueMatt> no 09:12 < sipa> or the send buffer is full 09:12 < BlueMatt> it does not 09:13 < BlueMatt> I had the same misunderstanding initially 09:14 < morcos> line 2566 in net_processing.cpp on master i think 09:14 < sipa> ok, i was not aware of that 09:15 < sipa> but that seems to be a bug 09:15 < morcos> :) i think cfields tried to explain it multiple times 09:15 < morcos> i think we all agree it may be better to process multiple messages, but it seems to me to make more sense to do that as a follow on PR 09:16 < BlueMatt> (and the overhead of not doing so is (likely) not too terrible) 09:16 < BlueMatt> (except for the bug fixed by #9315) 09:16 < gribble> https://github.com/bitcoin/bitcoin/issues/9315 | Request announcement by cmpctblock AFTER requesting cmpctblock/blocktxn by rebroad · Pull Request #9315 · bitcoin/bitcoin · GitHub 09:18 < morcos> we need to think carefully if there could be negative situations in the other direction.. you're about to announce blocks to all your peers or respond to their getblocktxns messages and some other peer manages to tie you up with a slew of expensive to process received msgs 09:18 < BlueMatt> heh, fun github bug - if you "start a review" and then "add single comment", it will publish all pending comments 09:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:19 < sipa> on a different page? 09:20 < sipa> ok, so it seems i had completely forgotten about #3180 (> 3 years old) 09:20 < gribble> https://github.com/bitcoin/bitcoin/issues/3180 | Reduce latency in network processing by pstratem · Pull Request #3180 · bitcoin/bitcoin · GitHub 09:20 < BlueMatt> you dont /usually/ forget prs from 3 years ago???! 09:20 < BlueMatt> man, I cant remember prs from 6 months ago 09:20 < cfields> sipa: heh, i commented on it in about ~5 places :) 09:20 < morcos> i think clearly we should do SOMETHING smarter, i mean if a block has been announced to you and is sitting in yoru receive queue, seems silly to announce it back just b/c you haven't read it... 09:21 < cfields> sipa: i thought you just wanted to minimize the diff here 09:21 < sipa> cfields: you said "in nearly all cases, only one message is processed" - i thought that referred to cases where the buffer was full or we're processing blocks - the pre-3180 behaviour 09:21 < sipa> and i didn't understand why you'd be changing it 09:22 < morcos> so do we all agree that cfields should leave 9441 alone, and any further change should be in a separate PR? 09:22 < sipa> yes. 09:22 < cfields> sipa: ah, sorry. the only cases for processing multiple are for bad hash, or bad header 09:22 -!- brg444 [~bergealex@184.151.111.252] has quit [Ping timeout: 248 seconds] 09:23 < sipa> i was trying to ask "why are you changing behaviour" - it would have been clearer if you just had said "it doesn't" 09:23 < sipa> :) 09:23 < morcos> s/only cases/only preexisting cases were/ 09:23 < jonasschnelli> luke-jr: I first was using the term "non-validation mode". But than – after reading satoshis whitepaper again – considered to use the name "Simple Payment Verification". 09:23 < BlueMatt> fucking engineers - always precise..... 09:23 < sipa> sorry, i was probably misreading what you said 09:24 < morcos> or something.. nm 09:24 < cfields> sipa: it's mentioned in a bunch of places and at one point you said "I certainly noticed it only processed one message at a time", so i thought we were on the same page 09:24 < cfields> no worries though, sounds like we're all good now 09:24 < morcos> cfields: i'll review again after you fix outstanding comments 09:24 < sipa> cfields: i noticed that your PR changed it to only processing one message at a time 09:25 < sipa> i didn't realize that that was not a change 09:25 < cfields> sipa: ah, heh. i misread you too then :) 09:25 < morcos> i'm not sure i 100% understand the wait_until condition, is the idea that you don't want spurious wakeups to cause another loop? 09:25 < cfields> ok. I rebased this morning to address all nits and keep the loop in. Will back that out and push. 09:26 < sipa> anyway - misunderstandings in both directions. i should have read the code, instead of making (apparently 3-year old) assumptions about the code 09:26 < cfields> sipa: sure, no worries. It's not obvious behavior _at all_. 09:27 < cfields> morcos: the condition lets us wake the processor from the message handler thread when a new message comes in 09:27 < cfields> and yea, avoids spurious wakes too 09:31 -!- brg444 [~bergealex@184.151.111.252] has joined #bitcoin-core-dev 09:38 < bitcoin-git> [bitcoin] sipa pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a55716abe566...46b249e578e8 09:38 < bitcoin-git> bitcoin/master 9479f8d Jonas Schnelli: Allow shutdown during LoadMempool, dump only when necessary 09:38 < bitcoin-git> bitcoin/master 325e400 Jonas Schnelli: [Qt] Do proper shutdown 09:38 < bitcoin-git> bitcoin/master 46b249e Pieter Wuille: Merge #9408: Allow shutdown during LoadMempool, dump only when necessary... 09:38 < bitcoin-git> [bitcoin] sipa closed pull request #9408: Allow shutdown during LoadMempool, dump only when necessary (master...2016/12/memp_dump) https://github.com/bitcoin/bitcoin/pull/9408 09:38 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has joined #bitcoin-core-dev 09:45 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has quit [Quit: wrkrcoop] 09:45 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has joined #bitcoin-core-dev 09:47 < morcos> cfields: ah yes, ok good.. cool. i like the new design... 09:48 < cfields> morcos: great, thanks. 09:50 -!- brg444 [~bergealex@184.151.111.252] has quit [Read error: Connection reset by peer] 09:51 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has joined #bitcoin-core-dev 09:53 < luke-jr> BlueMatt: how's this look now? 09:56 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 09:57 < cfields> morcos: updated. Very little changed from before, mostly just fixed some things in the interim commits to be more correct for easier review 10:00 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Quit: Leaving] 10:05 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 10:25 -!- sipa [~pw@vps64477.public.cloudvps.com] has quit [Changing host] 10:25 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev 10:37 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 10:38 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 10:40 < brg444> can someone confirm how many iterations of segwit testnet there were? 10:41 < sipa> 4, i believe 10:42 < brg444> thanks 11:18 < morcos> cfields: one more question on that wait_until.. lets say a block message comes in, takes you a while to process.. if any peers sent you a new message in the interim, you won't wait b/c of fMsgProcWake correct? 11:19 < morcos> But if no peers sent you a message, you will announce quickly to peers N+1 -> MAX_CONNECTIONS, but then sleep up to 100ms before announcing to peers 1 -> N-1 ? 11:20 < gmaxwell> sipa: Processmessage _currently_ processes one at a time, there is a break stuck in the bottom of the loop. 11:21 -!- Netsplit *.net <-> *.split quits: Guest98817 11:21 < morcos> I thought I had seen somewhere talk about making the wait_until time be 100ms from start of loop and not end, or perhaps we should add a WakeMessageHandler for new tips in particular? 11:22 -!- cjamthagen_ [~user@h-88-153.a230.priv.bahnhof.se] has joined #bitcoin-core-dev 11:22 -!- wump [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev 11:22 -!- Netsplit *.net <-> *.split quits: wumpus, cjamthagen, afk11, so, AaronvanW 11:22 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 11:22 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 11:22 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 11:23 < gmaxwell> morcos: I opened a PR that did those things, and also explicitly asked about the fact that it changed the message handling back to process multiple messages. After no one replied for a bit I just changed it back to one message at a time. 11:23 < cfields> morcos: yes, that would probably make sense. I think gmaxwell's change included that 11:23 < gmaxwell> Then after cfields said he preferred his net refactors I closed it. 11:23 < gmaxwell> it didn't really make that much of a difference when the other problems were fixed. 11:24 < morcos> gmaxwell: I like the changes in 9441 and i think its good to be making progress as part of a larger roadmap.. i think it captures most of the improtant improvements.. 11:25 < morcos> perhaps we can add quick relay of new tips, and processing multiple messages requires a bit more thought in my view.. as we can see by the fact that it was ever taken out in the first place 11:25 < morcos> that said, i admit i did not look at your PRs 11:25 < morcos> hard to keep up! 11:26 < cfields> It's certainly reasonable to tweak it now that the dependencies are untangled, I just tried to keep the scope narrow at first 11:26 < gmaxwell> I know, that why I closed them rather than have more things to look at! 11:26 < gmaxwell> not gonna stop me from going 'I already pointed this out, if you only listened!' :P 11:27 < morcos> insufficient emoticons 11:27 < sipa> gmaxwell: i finally understand your comment on the PR 11:27 < sipa> gmaxwell: i thought you were trying to say that that PR changed it to only process one at a time (which i noticed)... and i was very confused by what you said afterwards about fixing it 11:30 < gmaxwell> sipa: it changed it to process multiple at a time initially, and I immediately added a line comment on that change asking for review of that (which github seems to have lost when I force pushed a change that reverted back to the old behavior) 11:30 < cfields> morcos: hmm, wait. Are you talking about the new quick-relay from 9375 in particular? 11:30 < morcos> cfields: no i'm talking about exactly not that 11:30 < sipa> seems i was just assuming i knew what master did, and i misinterpreted everything that people tried to explain it to me 11:30 < cfields> morcos: ok, good 11:31 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 11:31 < gmaxwell> sipa: I think it should probably handle multiple at a time subject to some time limit. ::shrugs:: 11:31 < morcos> cfields: its very easy to see the behavior with 9375 now though b/c of the cached blocks making the annoucements so fast. you watch annoucements in quick succession up to some high numbered peer and then a pause before announcements start to low numbered peers 11:32 < sipa> gmaxwell: absolutely agree 11:33 < sipa> but if we've done it this way since 0.10, i really don't care whether that happens in 0.14 or not 11:33 < morcos> sipa: gmaxwell: i think ideally we might do something even smarter, such as queue received transactions to be ATMP'ed after we'd gotten through block relay.. however its a bit tricky in that you dont' want to reorder those after any potential other cmpctblock messages for reconstruction purposes 11:33 < cfields> morcos: ah, i think that'd be a different culprit then 11:34 < gmaxwell> sipa: in other things people probably didn't notice, I've been complaining that our socket recieve buffer (5 MB) is _way_ too small given how long executions of the message handler take; and it is adversely impacting performance; even with cfields' PR. 11:34 < morcos> cfields: wait, why a different culprit? didn't the old code have the same problem in a different way? 11:35 < cfields> morcos: to be clear, you're saying that you observe that behavior with the cached blocks? 11:36 < morcos> cfields: :) yes, but not the pre-announced cached blocks. we use the cached blocks for regular announcment too. 11:36 < gmaxwell> sipa: e.g. right now we can, during a single handler run, connect 999 blocks which will take 2000 seconds even on a moderately fast computer... all the rx buffers just fill. (and on a really slow computer, we'll ping timeout our peers while connecting a wad of blocks) 11:36 < cfields> gmaxwell: https://github.com/bitcoin/bitcoin/pull/9441#issuecomment-270397280 . I think we should consider changing this for 0.14 as well. 11:39 < cfields> morcos: aha, i see. I'm with you now. 11:39 < morcos> they just make the rest of the loop so fast that the pause is more visible 11:43 < gmaxwell> morcos: my strategy was basically to make the loop run immediately again after anything interestin happened. I think it's harmless to always execute the loop an extra time. 11:47 < morcos> gmaxwell: how would you define interesting? any message processed? 11:48 < gmaxwell> morcos: yes, though my PR didn't bother catching any message processed, it did catch any message sent or any block recieved, I believe. 11:49 < gmaxwell> I think it would be fine to make it do any message sent or recieved. 11:51 < gmaxwell> I also made it run through the loop an extra time in any case it skipped something due to lock contention. 11:51 < sipa> gmaxwell: i'm aware... but i think it's just fundamentally broken that we're pegging the message handler thread for 2000s 11:51 < sipa> gmaxwell: it's not too hard to not always connect everything we have 11:52 < gmaxwell> sipa: That would be good, the change to accomplish that wasn't obvious to me or I would have PRed it already; though that is necessary it's not sufficient. 11:53 < gmaxwell> sipa: since even a _1_ second delay coupled with a 5MB buffer is enough to limit our IBD sync speed to far below what we can reindex-chainstate at on reasonable hardware. 11:54 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has quit [Quit: wrkrcoop] 11:56 < gmaxwell> morcos: the wake on lock contention seemed important to me, otherwise we could get a message from a peer, bounce off cs_main before getting to handle it, then sleep for 100ms before trying again. 11:57 < gmaxwell> (e.g. if we're competing with rpc for cs_main) 11:59 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has joined #bitcoin-core-dev 11:59 < morcos> gmaxwell: hmm.. that makes sense. where are you referring to where we skip handling the message if we can't get cs_main? 12:00 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has quit [Client Quit] 12:02 < gmaxwell> morcos: ah, I think one of the just merged networking changes just removed where we did that. 12:02 < morcos> oh in SendMessages 12:02 < gmaxwell> oh no, there it is. 12:05 < morcos> gmaxwell: on another note, i guess our ability to make use of >4 cores isn't as good as I thought... I had a whole series of PR's that removed successive bottlenecks, but i'd misremembered how much progress we could make wiht only the cuckoocache 12:05 < morcos> And then I got sidetracked by the near conesnsus bug with CCoinsViewCache.. but when I get a chance I'll go back and see if there are other parts of that that are still worth doing now 12:05 < gmaxwell> yea... 12:07 < BlueMatt> ugh, ffs, fibre cuts in india means fibre rtt between eu and asia is up 90ms on one path :( 12:07 < BlueMatt> luke-jr: did you fix https://github.com/bitcoin/bitcoin/pull/8775#discussion_r94985339 ? 12:07 < sipa> that try_lock cs_main can go away after #9419 (+ follow ups), i think, as it will be replaced by the nodestate locks 12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9419 | Stop Using cs_main for CNodeState/State() by TheBlueMatt · Pull Request #9419 · bitcoin/bitcoin · GitHub 12:10 < luke-jr> BlueMatt: no, where is it assumed to return non-NULL? 12:10 < gmaxwell> there is some advantage in skipping processing peers that need a lock, when other peers can be processed without it. 12:10 < BlueMatt> luke-jr: ok, please add documentation to note that it is assumed it can return null 12:12 < gmaxwell> though on the other hand, I think that that construction could leave us sending pings even if cs_main is deadlocked which would be undesirable. (not an actual issue because our message handler will get stuck elsewhere in the case, but still) 12:12 < luke-jr> I would think that's implied in returning a pointer type, but ok 12:15 < BlueMatt> luke-jr: could you not rebase when people are in the middle of review? 12:18 < luke-jr> haven't rebased that PR in a week, but ok 12:18 < BlueMatt> did you just rebase again? 12:18 < luke-jr> no, just added the comment 12:19 < BlueMatt> no? the previous head is now gone? 12:19 < luke-jr> indeed, I amended it 12:19 < BlueMatt> please do not do that 12:19 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has joined #bitcoin-core-dev 12:21 * luke-jr starts a list of the contradicting development processes preferred by various people. 12:25 * BlueMatt restarts review from the start :( 12:25 < BlueMatt> does anyone ask for regular squash/rebase mid-review? 12:28 < luke-jr> I don't usually distinguish (or have a way to) when others are actively reviewing. (note there was already amended commits before I became aware you were) 12:29 < gmaxwell> at what point is someone not reviewing? 12:30 < luke-jr> gmaxwell: exactly, hence why some desiring squashing vs others not liking squashing [at particular times] is confusing to resolve 12:30 < BlueMatt> when it is time to merge and/or there are limited comments showing up? 12:30 < BlueMatt> no one desires squashing unless its been a while since things have been commented on, though to be fair, you should, at a minimum, comment when you squash and note changes 12:31 < BlueMatt> eg respond to the previous comments and note where you did/didnt make changes, instead of letting them sit 12:32 < sipa> i usually prefer squashing trivial fixes immediately, unless it's a very complicated PR 12:32 < sipa> most of the time is understanding what the PR is trying to achieve and how... reading the code is easy 12:32 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has quit [Quit: wrkrcoop] 12:33 < gmaxwell> matt's style can be helpful on more complicated ones, but as someone who has often come to a PR to review later, I've found the style to really suck in that case. I waste my time finding bugs that are already fixed in later updates. 12:33 < BlueMatt> not for a major refactor pr where most of the pr is just code movement 12:33 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has joined #bitcoin-core-dev 12:33 < sipa> gmaxwell: likewise 12:33 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has quit [Client Quit] 12:33 < sipa> (but i don't mind following either style... just my personal preference is usually fixing things immediately) 12:33 < BlueMatt> gmaxwell: I try to title such commits f "Commit title this should be squashed into" fix XYZ 12:33 < BlueMatt> which should at least make it easy to glance at such changes 12:34 < sipa> i guess things have improved with the "review" thing 12:34 < gmaxwell> also it leaves me having to re-review the squash since sometimes a pair of reasonable looking changes my reveal their brokenness once merged. (also we have no tools to tell if a squash was faithful in any case, so someone malicious could slip something in if people didn't review the squash just as carefully) 12:34 < sipa> so you can comment on an issue, and then later delete if you see it's already fixed ahead of time 12:35 < BlueMatt> yes, my bigger annoyance is having to re-review after squash was shit 12:35 < BlueMatt> its easy if its clear and the commits are just being cleanly squashed (can compare treeish) 12:35 < luke-jr> I have an alias that compares diffs that I've gotten used to using to see what changed in an amend 12:41 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has joined #bitcoin-core-dev 12:50 -!- Giszmo [~leo@46.128.114.214.dynamic.cablesurf.de] has quit [Quit: Leaving.] 13:04 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has quit [Quit: wrkrcoop] 13:10 < owowo> is there a time when core drops a tx if unconfirmed for a long time? Or will it just keep on rebroadcasting it until the return of the Messiah? 13:11 < BlueMatt> the wallet will keep rebroadcasting, but you can "abandon" a transaction both in the gui and the rpc 13:11 < BlueMatt> the mempool will eventually drop them, but there are "helpful" nodes which like to rebroadcast lots of shit to their peers all the time 13:12 < owowo> ok, thx 13:23 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has joined #bitcoin-core-dev 13:35 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has quit [Read error: Connection reset by peer] 13:39 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has joined #bitcoin-core-dev 13:43 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 13:45 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 13:49 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-phahrsctibqawwii] has quit [Quit: Connection closed for inactivity] 13:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 14:30 -!- juscamarena_ [~justin@47.148.176.74] has quit [Quit: Leaving] 14:38 -!- fengling [~fengling@223.223.187.142] has quit [Ping timeout: 268 seconds] 14:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds] 15:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 15:06 -!- fengling [~fengling@223.223.187.142] has joined #bitcoin-core-dev 15:14 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 256 seconds] 15:16 -!- fengling [~fengling@223.223.187.142] has quit [Ping timeout: 268 seconds] 15:18 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 15:18 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 15:18 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 15:18 < bitcoin-git> [bitcoin] gmaxwell opened pull request #9484: Introduce assumevalid setting to skip validation presumed valid scripts. (master...script_elide_verified) https://github.com/bitcoin/bitcoin/pull/9484 15:29 < bitcoin-git> [bitcoin] mcelrath opened pull request #9485: ZMQ example using python3 and asyncio (master...python3zmq) https://github.com/bitcoin/bitcoin/pull/9485 15:43 -!- MarcoFalke [~marco@2a02:778:100:ea01:2225:64ff:fe3b:d4ca] has quit [Quit: MarcoFalke] 15:44 -!- fengling [~fengling@223.223.187.142] has joined #bitcoin-core-dev 15:44 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 15:54 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has quit [Quit: wrkrcoop] 15:58 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 256 seconds] 15:59 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has joined #bitcoin-core-dev 16:01 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 16:03 -!- Giszmo [~leo@ppp-93-104-180-82.dynamic.mnet-online.de] has joined #bitcoin-core-dev 16:03 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has quit [Client Quit] 16:15 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 16:18 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has joined #bitcoin-core-dev 16:22 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 16:33 -!- wrkrcoop [~martee@adsk-nat-ip8.autodesk.com] has quit [Quit: wrkrcoop] 16:51 -!- brg444 [~bergealex@qubcpq1531w-lp130-02-65-92-224-54.dsl.bell.ca] has quit [Ping timeout: 258 seconds] 17:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 17:36 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 17:49 -!- LeMiner2 [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 17:51 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds] 17:51 -!- LeMiner2 is now known as LeMiner 17:53 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-vfjscqeglycdzyon] has joined #bitcoin-core-dev 18:09 < gmaxwell> morcos: actually the parallel signature checking gains are better than expected. So consider (all reindex chainstate, dbcache2000) no-scriptchecks par=4 10680.346728 seconds, all scriptchecks par=4 24453.715550 , all scriptchecks part=default (24 core, 48 thread host): 12182.296543 ... so if you compute (par4-none)/(parN-none) = 9.17 ... impressive trick considering MAX_SCRIPTCHECK_THREADS i 18:09 < gmaxwell> s 16. ... my numbers may not be totally compariable because I had a rebase between the par4 and parN cases, that I didn't _think_ would impact performance. 18:09 < gmaxwell> Good test hygine is hard when doing tests that take 7 hours. 18:12 < Chris_Stewart_5> jonasschnelli: Do you have any numbers on how long it takes to sync headers with your pull req? 18:19 -!- Giszmo1 [~leo@ppp-93-104-165-9.dynamic.mnet-online.de] has joined #bitcoin-core-dev 18:21 -!- Giszmo [~leo@ppp-93-104-180-82.dynamic.mnet-online.de] has quit [Ping timeout: 248 seconds] 18:21 < warren> jonasschnelli: hmm, I'm excited to use your SPV mode in conjunction with BIP150 (authenticated connection to my own full nodes) 18:23 < gmaxwell> warren: just need 5 more regular contributors to get all the outstanding things done. 18:34 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 18:57 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 19:04 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 19:04 < morcos> gmaxwell: i don't think thats a fair calculation though since during the none part the script checking threads are running 19:04 < morcos> or at least N-1 of them 19:06 < gmaxwell> morcos: I agree someone is wrong, but I don't follow your explination. None is effectively fScriptChecks = false. The threads may be running but they're not doing anything. 19:07 < gmaxwell> all is fScriptChecks wedged true. (no checkpoints). 19:08 < morcos> yes but during the all time so take the par=default case.. you have 15 script check threads running for 10k seconds and then 16 running for another 2k seconds, so its not fair to say it only took them 2k seconds 19:09 < gmaxwell> duh right. 19:09 < gmaxwell> okay, it's been a long day. 19:10 < morcos> all this flurry of trying to fix concurrency problems showed up when it turned out that it could actually be faster to NOT have signatures cached because of the contention on the sigcache 19:10 < morcos> thats certainly been fixed with the cuckoocache 19:10 < gmaxwell> well for IBD it still might be. :P 19:11 < morcos> but it is still the case that when sigs are cached, its harder to see the benefits of more parallelism, b/c then the contention on the checkqueue is greater 19:12 < gmaxwell> I wish our design made it easier to get multiple blocks in the scriptchecking pipeline at once. 19:13 < morcos> I suspect that improvement wouldn't be that much any more 19:13 < morcos> with full blocks, there isn't much time where you have idle cores with nothing to do 19:13 < morcos> it makes a much bigger difference with the old small blocks though 19:14 < morcos> i do think if i had your computer i'd change MAX_SCRIPTCHECK_THREADS though! 19:14 < gmaxwell> yes. well, also, I'm usually using 48 or 56 thread hosts. 19:14 < gmaxwell> well it used to make it _slower_ I'm trying now with it at 48. 19:15 < gmaxwell> it's at height 250k at hte moment and not making it much past 700% cpu according to top... but thats still early. 19:16 < morcos> it's worse than video games. you're still going to be doing that at 3am 19:16 < morcos> have a good night! 19:17 < gmaxwell> hah 19:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-zflodhdpeelpsnrl] has quit [Quit: Connection closed for inactivity] 19:18 < gmaxwell> "I thought mine-craft was a graphical program?" 19:50 < Chris_Stewart_5> How is CScript serialized? It doesn't seem to use ADD_SERIALIZE_METHODS 19:54 < luke-jr> Chris_Stewart_5: it's just a vector of uint8s 20:04 < Chris_Stewart_5> luke-jr: Which is why we things like this? static_cast 20:09 < sipa> yes CScript is just a subclass of std::vector 20:23 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 246 seconds] 20:25 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 20:35 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 20:36 < warren> https://0bin.net/paste/iJSqUPkqv-zAG-ZN#vKw4haQ8j5fbQZK7NAkYO+nXugLmLPZP73uJghKj6nl This is an example of a double-spent transaction, previously confirmed in the local wallet but now invalid. I think years ago this output would continue to show the blockhash of the block that it was previously confirmed (but no longer the longest chain)? Any idea when this changed? 20:38 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 245 seconds] 20:53 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev 21:07 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 21:08 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 21:22 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 264 seconds] 21:23 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 21:50 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 240 seconds] 21:56 -!- afk11 [~afk11@176.61.67.182] has joined #bitcoin-core-dev 21:56 -!- afk11 [~afk11@176.61.67.182] has quit [Changing host] 21:56 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 21:57 -!- Giszmo [~leo@ppp-93-104-165-252.dynamic.mnet-online.de] has joined #bitcoin-core-dev 21:59 -!- Giszmo1 [~leo@ppp-93-104-165-9.dynamic.mnet-online.de] has quit [Ping timeout: 240 seconds] 22:09 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 245 seconds] 22:36 -!- Giszmo [~leo@ppp-93-104-165-252.dynamic.mnet-online.de] has quit [Ping timeout: 272 seconds] 23:00 -!- dermoth [~thomas@dsl-66-36-158-182.mtl.aei.ca] has quit [Read error: Connection reset by peer] 23:01 -!- dermoth [~thomas@dsl-66-36-158-182.mtl.aei.ca] has joined #bitcoin-core-dev 23:20 -!- LeMiner2 [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 23:23 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds] 23:23 -!- LeMiner2 is now known as LeMiner 23:29 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 23:37 -!- LeMiner2 [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 23:39 -!- LeMiner [~LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has quit [Ping timeout: 260 seconds] 23:39 -!- LeMiner2 is now known as LeMiner 23:40 -!- sqltest [65332216@gateway/web/freenode/ip.101.51.34.22] has joined #bitcoin-core-dev 23:42 < sqltest> hello. I'm having a problem getting bitcoind to run as a different user (other than logged in user) using init conf. It always fails because it tries to create a .bitcoin dir. If I create a /.bitcoin dir with ownership of user it works. But I don't want a root .bitcoin dir. The running user has no home dir. The bitcoin.conf is provided on cmd and datadir is in conf so works fine. No need to create an empty .bitcoin dir at a 23:44 < sqltest> eg. "sudo -u btc bitcoind -conf=/etc/bitcoin/bitcoin.conf" works only if an extraneous .bitcoin dir exists even when not used 23:48 < gmaxwell> you need to set the datadir path, not conf. 23:48 < gmaxwell> you can just bitcoind -datadir=/etc/bitcoin/ 23:49 < sqltest> I do set that in the conf file and it works. But only when an empty .bitcoin is "hanging around". The .bitcoin remains empty even when daemon is full functionaing. 23:50 < sqltest> I have other settings I need in the bitcoin.conf as well so provide that instead of datadir alone. 23:50 < sqltest> It seems to test the exitence of .bitcoin even when using another datadir path. 23:51 < sqltest> The issue is it is run as btc user by start-stop-daemon but that process chdirs to root first. 23:52 < sqltest> So if I create an empty /.bitcoin dir it starts fine. But when that is not present it cannot start. 23:52 < jonasschnelli> <*highlight> jonasschnelli: Do you have any numbers on how long it takes to sync headers with your pull req? 23:53 < jonasschnelli> 2-3min 23:53 < sqltest> If I tell start-stop-daemon to chdir to a writeable dir I thought it would create a .bitcoin dir there but for some reason it doesn't. 23:53 < jonasschnelli> Headers-Sync does not run in parallel (from different peers) 23:53 < jonasschnelli> So.. if you have download them from a slow peer, it may take longer. 23:56 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 23:57 < gmaxwell> sqltest: don't use the config file to set it, thats too late. 23:57 < gmaxwell> hm. well, that might be a bug then. 23:57 < jcorgan> sqltest: i can confirm i've seen exactly the same behavior as you describe. i don't know if it is a feature or a bug, but nowadays i run bincoind inside a container so i map $HOME/.bitcoin inside the container to wherever i want outside the container 23:57 < gmaxwell> though I don't think so. 23:58 * gmaxwell straces. 23:59 < gmaxwell> with datadir set on the commandline I don't see any access to $HOME/.bitcoin 23:59 < gmaxwell> with master, I don't have a 0.13.2 binary handy to test at the moment. 23:59 < jcorgan> i did trace through the code (though this was back in the 0.8 or 0.9 days, so it's probably all changed)