--- Day changed Thu Sep 01 2016 00:02 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 00:04 -!- kyletorpey [~kyle@pool-173-53-94-96.rcmdva.fios.verizon.net] has quit [Quit: Leaving.] 00:06 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 00:08 -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev 00:08 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Ping timeout: 265 seconds] 00:11 < GitHub15> [bitcoin] rebroad reopened pull request #8622: [WIP] Clarify variable names (master...ClarifyVariableNames) https://github.com/bitcoin/bitcoin/pull/8622 00:12 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 244 seconds] 00:18 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:20 -!- adiabat [~adiabat@159.203.193.74] has quit [Ping timeout: 250 seconds] 00:23 -!- warren [~warren@fedora/wombat/warren] has quit [Ping timeout: 276 seconds] 00:24 -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev 00:24 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 00:32 -!- FNinTak [~jonhbit@2601:600:8c01:6ab0:ee1a:59ff:fec0:acd6] has joined #bitcoin-core-dev 01:01 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 265 seconds] 01:01 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev 01:02 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds] 01:05 < GitHub2> [bitcoin] sipa closed pull request #8597: Move code from VERACK to VERSION (since VERACK is not requied) (master...NotDependentOnVerack) https://github.com/bitcoin/bitcoin/pull/8597 01:05 < GitHub45> [bitcoin] sipa closed pull request #8622: [WIP] Clarify variable names (master...ClarifyVariableNames) https://github.com/bitcoin/bitcoin/pull/8622 01:05 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Quit: ZNC - http://znc.in] 01:06 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev 01:07 -!- laurentmt [~Thunderbi@80.215.138.153] has joined #bitcoin-core-dev 01:07 -!- laurentmt [~Thunderbi@80.215.138.153] has quit [Client Quit] 01:15 -!- laurentmt [~Thunderbi@80.215.138.153] has joined #bitcoin-core-dev 01:17 -!- mn3monic [~guido@176.9.68.68] has joined #bitcoin-core-dev 01:19 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:24 -!- laurentmt [~Thunderbi@80.215.138.153] has quit [Quit: laurentmt] 01:25 < GitHub22> [bitcoin] rebroad opened pull request #8642: Less reliance on node version (master...LessRelianceOnNodeVersion) https://github.com/bitcoin/bitcoin/pull/8642 01:25 < luke-jr> sigh 01:28 < gmaxwell> I dunno whats going on there. 01:28 < gmaxwell> I feel like I am being fuzz tested. 01:28 < luke-jr> lol 01:30 < gmaxwell> we need pulltester tests that test against a fixed point, so that if you break the protocol in a self-compatible way, the CI tests will still fail. 01:31 < gmaxwell> those changes will throughly break communications with at least some versions. 01:32 < sipa> gmaxwell: it seems intentional 01:33 < gmaxwell> it's completely wildly handled though, sending garbage messages to peers that will tell who knows what malfunction. 01:35 < sipa> one of the commits mentions that a protocol change introduced in 2010 should be supported by everyone 01:35 < sipa> but he kills pre-bip31 nodes as well, which dates from 2012 01:38 < gmaxwell> yea, I was looking at the BIP31 changes and scratching my head. 01:39 < luke-jr> I guess there's a safe way one /could/ do that.. not sure it's worth the effort though 01:39 < luke-jr> (if vRecv has nonce data, read and use it; otherwise, don't) 01:43 < gmaxwell> I don't see why we'd touch old, working, functional code-- if there was some big reworking of those parts for other reasons, then sure it might be justifyable to break compatiblity at least back to the point where compatability is already likely broken for other reasons. 01:48 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev 01:50 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 01:50 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Disconnected by services] 01:50 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 01:51 < warren> Big reworking of the network layer is happening in the rewrite. It makes no sense to change anything before the rewrite, especially working code. 01:52 < sipa> can someone else other than me comment there? 01:53 -!- ybit_ [~ybit@bryan.fairlystable.org] has joined #bitcoin-core-dev 01:54 -!- ybit_ [~ybit@bryan.fairlystable.org] has quit [Changing host] 01:54 -!- ybit_ [~ybit@unaffiliated/ybit] has joined #bitcoin-core-dev 01:54 < gmaxwell> last comment from his is you're right. 01:56 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 01:56 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 01:56 < warren> I don't understand why he's citing nodes that are INTENDED to be incompatible as reason to change anything. 01:58 -!- Netsplit *.net <-> *.split quits: sanada`, Bootvis, harding, go1111111, jyap, Taek, mn3monic, slackircbridge1, ybit, gijensen3, (+4 more, use /NETSPLIT to show all of them) 01:59 -!- jyap [~jyap@2604:180:1:7f5::b59a] has joined #bitcoin-core-dev 01:59 -!- jyap [~jyap@2604:180:1:7f5::b59a] has quit [Changing host] 01:59 -!- jyap [~jyap@unaffiliated/jyap] has joined #bitcoin-core-dev 01:59 -!- gijensen [~gijensen@gijensen.xyz] has joined #bitcoin-core-dev 02:00 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:34f7:f4d2:3e19:2a7f] has joined #bitcoin-core-dev 02:00 -!- Netsplit over, joins: go1111111 02:00 -!- lukedashjr is now known as luke-jr 02:01 -!- JackH [~Jack@79-73-189-132.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 02:02 -!- Netsplit over, joins: morcos 02:02 -!- Netsplit over, joins: aalex 02:03 -!- Netsplit over, joins: crudel, mn3monic, Taek, sanada`, Bootvis, harding 02:20 -!- laurentmt [~Thunderbi@80.215.138.153] has joined #bitcoin-core-dev 02:34 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 02:50 -!- laurentmt [~Thunderbi@80.215.138.153] has quit [Quit: laurentmt] 02:59 -!- isis is now known as isis_ 03:04 -!- isis_ is now known as isis 03:11 -!- AaronvanW [~ewout@80.174.233.149.dyn.user.ono.com] has joined #bitcoin-core-dev 03:11 -!- AaronvanW [~ewout@80.174.233.149.dyn.user.ono.com] has quit [Changing host] 03:11 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:15 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev 03:21 < GitHub97> [bitcoin] sipa pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/84decb54f259...19b0f33de0ef 03:21 < GitHub97> bitcoin/master d2c5d04 Pieter Wuille: Precompute sighashes... 03:21 < GitHub97> bitcoin/master ab48c5e Nicolas DORIER: Unit test for sighash caching 03:21 < GitHub97> bitcoin/master 35fe039 Pieter Wuille: Rename to PrecomputedTransactionData 03:21 < GitHub100> [bitcoin] sipa closed pull request #8524: Precompute sighashes (master...noprecomputecachedhashes) https://github.com/bitcoin/bitcoin/pull/8524 03:25 < gmaxwell> \O/ 03:25 -!- FNinTak [~jonhbit@2601:600:8c01:6ab0:ee1a:59ff:fec0:acd6] has quit [Quit: Leaving] 03:26 -!- FNinTak [~jonhbit@2601:600:8c01:6ab0:ee1a:59ff:fec0:acd6] has joined #bitcoin-core-dev 03:33 -!- FNinTak [~jonhbit@2601:600:8c01:6ab0:ee1a:59ff:fec0:acd6] has quit [Quit: Leaving] 03:34 -!- FNinTak [~jonhbit@2601:600:8c01:6ab0:ee1a:59ff:fec0:acd6] has joined #bitcoin-core-dev 03:37 < jl2012> great, one big step closer to 0.13.1 03:37 -!- FNinTak [~jonhbit@2601:600:8c01:6ab0:ee1a:59ff:fec0:acd6] has quit [Client Quit] 03:39 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:34f7:f4d2:3e19:2a7f] has quit [Read error: Connection timed out] 03:39 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lekvmzkyzfxwydft] has joined #bitcoin-core-dev 03:39 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:34f7:f4d2:3e19:2a7f] has joined #bitcoin-core-dev 03:53 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:34f7:f4d2:3e19:2a7f] has quit [Ping timeout: 265 seconds] 04:04 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:ac6d:f433:257:90a2] has joined #bitcoin-core-dev 04:36 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Quit: Textual IRC Client: www.textualapp.com] 04:42 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lekvmzkyzfxwydft] has quit [Remote host closed the connection] 04:42 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-ymmumcnqosftkfjp] has quit [Remote host closed the connection] 04:56 < GitHub89> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/2663e5149dc06dedb8c29672abe4b1c645768e52 04:56 < GitHub89> bitcoin/master 2663e51 Wladimir J. van der Laan: Merge #8640: [depends] Remove Qt46 package... 04:56 < GitHub131> [bitcoin] laanwj closed pull request #8640: [depends] Remove Qt46 package (master...remove-qt46-depends) https://github.com/bitcoin/bitcoin/pull/8640 04:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pjyccpdnldrwmgef] has joined #bitcoin-core-dev 05:00 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-kumzgpnclxqexlyp] has joined #bitcoin-core-dev 05:02 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 276 seconds] 05:17 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 05:17 -!- pmienk [~pmienk@71.227.177.179] has joined #bitcoin-core-dev 05:19 -!- dermoth_ [~thomas@dsl-66-36-158-91.mtl.aei.ca] has joined #bitcoin-core-dev 05:19 -!- dermoth [~thomas@dial-216-221-43-39.mtl.aei.ca] has quit [Disconnected by services] 05:19 -!- dermoth_ is now known as dermoth 05:32 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 05:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:42 < GitHub162> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/2663e5149dc0...0e563d89c075 05:42 < GitHub162> bitcoin/master 33d15a3 Pavel Janík: Do not shadow LOCK's criticalblock variable for LOCK inside LOCK 05:42 < GitHub162> bitcoin/master 0e563d8 Wladimir J. van der Laan: Merge #8472: Do not shadow LOCK's criticalblock variable for LOCK inside LOCK... 05:42 < GitHub159> [bitcoin] laanwj closed pull request #8472: Do not shadow LOCK's criticalblock variable for LOCK inside LOCK (master...20160806_Wshadow_LOCK) https://github.com/bitcoin/bitcoin/pull/8472 05:51 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev 05:52 -!- gijensen is now known as gijensen3 05:52 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 06:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 06:11 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 06:13 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection] 06:14 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev 06:20 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection] 06:20 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev 06:20 -!- laurentmt [~Thunderbi@80.215.138.153] has joined #bitcoin-core-dev 06:25 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 06:26 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection] 06:26 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev 06:34 -!- aalex_ [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 06:36 -!- laurentmt [~Thunderbi@80.215.138.153] has quit [Quit: laurentmt] 06:36 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 06:36 -!- laurentmt [~Thunderbi@80.215.138.153] has joined #bitcoin-core-dev 06:37 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 06:40 < GitHub84> [bitcoin] laanwj closed pull request #7376: Payments: Allow zero value OP_RETURN in PaymentRequests (master...zeropayments) https://github.com/bitcoin/bitcoin/pull/7376 06:44 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 06:45 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 06:47 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 06:57 < GitHub140> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/0e563d89c075...44691f3c51c9 06:57 < GitHub140> bitcoin/master fab1f92 MarcoFalke: [contrib] verifybinaries: Adjust parsing to new rc path 06:57 < GitHub140> bitcoin/master fa917f6 MarcoFalke: [contrib] verifybinaries: Keep downloads by default 06:57 < GitHub140> bitcoin/master faaed88 MarcoFalke: [contrib] verifybinaries: Mention mandatory preparation step 06:57 < GitHub143> [bitcoin] laanwj closed pull request #8557: [contrib] Rework verifybinaries (master...Mf1608-verifyBins) https://github.com/bitcoin/bitcoin/pull/8557 06:58 -!- timothy [~quassel@archlinux/trusteduser/DrizztBSD] has quit [Disconnected by services] 06:58 -!- drizztbsd [~quassel@archlinux/trusteduser/DrizztBSD] has joined #bitcoin-core-dev 06:58 -!- drizztbsd is now known as timothy 06:59 < GitHub10> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/44691f3c51c9...f061415d12ce 06:59 < GitHub10> bitcoin/master f012a85 djpnewton: rest.cpp: change HTTP_INTERNAL_SERVER_ERROR to HTTP_BAD_REQUEST 06:59 < GitHub10> bitcoin/master f061415 Wladimir J. van der Laan: Merge #8638: rest.cpp: change HTTP_INTERNAL_SERVER_ERROR to HTTP_BAD_REQUEST... 06:59 < GitHub78> [bitcoin] laanwj closed pull request #8638: rest.cpp: change HTTP_INTERNAL_SERVER_ERROR to HTTP_BAD_REQUEST (master...patch-2) https://github.com/bitcoin/bitcoin/pull/8638 07:03 -!- LeMiner2 [LeMiner@5ED1AFBF.cm-7-2c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 07:05 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Ping timeout: 252 seconds] 07:05 -!- LeMiner2 is now known as LeMiner 07:14 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 07:18 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer] 07:19 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 07:20 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 07:22 -!- aalex [~aalex@64.187.177.58] has quit [Max SendQ exceeded] 07:23 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 07:25 < GitHub130> [bitcoin] laanwj pushed 5 new commits to 0.12: https://github.com/bitcoin/bitcoin/compare/15502d7b2543...ec0afbd52b78 07:25 < GitHub29> [bitcoin] laanwj closed pull request #8176: [0.12.x]: Versionbits: GBT support (0.12...gbt_bip9-0.12.x) https://github.com/bitcoin/bitcoin/pull/8176 07:25 < GitHub130> bitcoin/0.12 ddd8c01 Luke Dashjr: Implement BIP 9 GBT changes... 07:25 < GitHub130> bitcoin/0.12 40e81f5 Luke Dashjr: qa/rpc-tests: bip9-softforks: Add tests for getblocktemplate versionbits updates 07:25 < GitHub130> bitcoin/0.12 65ee332 Luke Dashjr: getblocktemplate: Explicitly handle the distinction between GBT-affecting softforks vs not 07:28 < paveljanik> sipa, PrecomputedTransactionData is defined as struct, but: src/main.h:class PrecomputedTransactionData; 07:29 < sipa> will fix 07:29 < paveljanik> ok, thanks. 07:32 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection] 07:39 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection] 07:40 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev 07:41 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 07:47 -!- laurentmt [~Thunderbi@80.215.138.153] has quit [Quit: laurentmt] 07:47 -!- laurentmt [~Thunderbi@80.215.138.153] has joined #bitcoin-core-dev 08:05 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 276 seconds] 08:06 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev 08:11 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 08:16 -!- slackircbridge [~slackircb@139.59.146.250] has joined #bitcoin-core-dev 08:17 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer] 08:17 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 08:17 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has quit [Changing host] 08:17 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 08:53 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 09:01 -!- goregrin1 [~goregrind@unaffiliated/goregrind] has quit [Read error: Connection reset by peer] 09:07 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev 09:17 -!- achow101 [~achow101@129.2.206.174] has quit [Remote host closed the connection] 09:21 -!- achow101 [~achow101@129.2.206.174] has joined #bitcoin-core-dev 09:22 -!- laurentmt [~Thunderbi@80.215.138.153] has quit [Ping timeout: 265 seconds] 09:34 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 276 seconds] 09:38 -!- HoloIRCUser13 [~holoirc@179.202.232.134] has joined #bitcoin-core-dev 09:40 -!- HoloIRCUser13 is now known as yep555 09:43 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 09:43 -!- Cheeseo [~x@c-174-54-219-36.hsd1.pa.comcast.net] has quit [Changing host] 09:43 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev 09:52 < jtimon> it seems travis is failing walletbackup.py no matter what I push https://travis-ci.org/bitcoin/bitcoin/jobs/156853453#L2310 10:01 -!- gabridome [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-core-dev 10:02 < jtimon> mhmm, no, just randomly it seems, nothing to see here, sorry 10:04 -!- gabridome [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Client Quit] 10:07 -!- Yv7trNY [~IUTYVExrY@188.25.138.15] has joined #bitcoin-core-dev 10:13 < wumpus> jtimon: travis is a tad flakey at the moment 10:15 < jtimon> I see 10:16 -!- kyletorpey [~kyle@pool-173-53-94-96.rcmdva.fios.verizon.net] has joined #bitcoin-core-dev 10:18 -!- Yv7trNY [~IUTYVExrY@188.25.138.15] has quit [Read error: No route to host] 10:26 -!- niska [~niska@68.ip-149-56-14.net] has quit [Quit: Leaving] 10:37 -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Ping timeout: 264 seconds] 10:47 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 10:48 < jeremyrubin> Yeah my lockfree checkqueue work should be passing all tests now; but has failures due to flaky pulltester :/ 10:51 < jeremyrubin> Ah 10:52 < jeremyrubin> actually I did pass them on the last run; but I hadn't really made any changes that should have affected pass/fail 10:58 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev 10:58 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [] 10:58 -!- pmienk [~pmienk@71.227.177.179] has quit [Ping timeout: 244 seconds] 11:03 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 11:06 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:12 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 11:25 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: gtg] 11:44 -!- yep555 [~holoirc@179.202.232.134] has quit [Read error: Connection reset by peer] 11:50 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev 11:53 -!- w00t88 [b3da1843@gateway/web/cgi-irc/kiwiirc.com/ip.179.218.24.67] has joined #bitcoin-core-dev 11:54 -!- ybit_ [~ybit@unaffiliated/ybit] has quit [Quit: leaving] 11:54 -!- ybit [~ybit@unaffiliated/ybit] has joined #bitcoin-core-dev 11:55 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 11:59 < wumpus> meeting time? 11:59 < helo> <3 11:59 < jonasschnelli> yes 11:59 < luke-jr> big storm here, I may lose power 12:00 < paveljanik> Hi 12:00 < sipa> ohai 12:00 < achow101> hi 12:00 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier 12:00 < kanzure> greetz. 12:00 -!- grubles_ [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 12:00 < sdaftuar> hi 12:00 < cfields> here 12:00 < gmaxwell> luke-jr: I miss thunderstorms. 12:00 -!- gabridome [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-core-dev 12:01 < btcdrak> here 12:01 < sipa> there 12:01 < wumpus> #startmeeting 12:01 < lightningbot> Meeting started Thu Sep 1 19:01:57 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:02 < wumpus> proposed topics? 12:02 < sipa> remaining 0.13.1 issues 12:02 < jtimon> hi 12:02 < instagibbs> present 12:03 < wumpus> there are lots of 0.13.1-tagged pull requests open, any that should be prioritized for review? 12:03 < jeremyrubin> present 12:03 < sipa> wumpus: in fact, some conflict 12:03 < wumpus> (e.g. what should go in first) 12:03 < wumpus> yes, I thought so 12:03 < jonasschnelli> https://github.com/bitcoin/bitcoin/milestones/0.13.1 12:03 < wumpus> #link https://github.com/bitcoin/bitcoin/milestones/0.13.1 12:04 -!- grubles [~grubles@unaffiliated/grubles] has quit [Ping timeout: 240 seconds] 12:04 < sipa> 8393 (segwit + compact blocks) is a big blocker 12:04 < jeremyrubin> I'd like to mention that my Checkqueue Lockfree is passing tests, would like to hear what people need to see for it to merge (will be restructuing my commits later today.tomorrow) 12:04 < wumpus> #topic remaining 0.13.1 issues 12:04 < jeremyrubin> (also can't stick around meeting past 12:15 FYI) 12:04 < sipa> beyond that, we still need to choose a solution to the mempool dos issue around segwit 12:04 < instagibbs> yes cb and then dos issues are probably 2 biggest? 12:04 < sipa> this has been brought uo several times the past few meetings 12:05 -!- grubles_ is now known as grubles 12:05 < wumpus> #action #8393 (segwit + compact blocks) is a blocker, needs review testing and be merged 12:05 < sdaftuar> sipa: do we think that the BIP for cb+segwit is basically in final substantive form? i saw there were some language discussions 12:05 < sipa> sdaftuar: matt had more comments on the bip, but just on wording, not on semantics 12:05 < jtimon> sorry what was cb ? 12:05 < instagibbs> compact blocks 12:05 < sipa> compact blocks 12:05 < wumpus> jeremyrubin: great to hear it is passing the tests, we can talk about the topic later, but not if you have to leave that soon probably 12:05 < jtimon> compact blocks 12:05 < jtimon> sorry 12:05 < sdaftuar> sipa: ok, i intend to review/test 8393 soon 12:06 < sipa> thank you 12:06 < sipa> beyond that, the dos issue 12:06 < sipa> i'm not confortable with the previous suggestion of fully validating everything 12:06 < sipa> as a change for a minor point release 12:06 < jeremyrubin> wumpus: I'll try to swing back in the last few minutes of the meeting if possible? 12:07 < wumpus> it's a major change to how things have been done for the last few versions, that's for sure 12:07 < sdaftuar> so in a previous IRC meeting morcos had suggested mandatory feefilter + rejection cache only for non-witness tx, is that right? 12:07 < sipa> so that leaves us with not storing witness txn in the rejection cache, feefilter (possibly mandatory), and heuristics to detect invalid bloating before validation 12:07 < jonasschnelli> shouldn't we tag https://github.com/bitcoin/bitcoin/issues/8279 for 0.13.1? 12:08 < sipa> sdaftuar: yes, there have been other suggestions in other talks to 12:09 < luke-jr> I feel like I don't fully understand the issue, but couldn't the rejection cache use the [witness] hash instead of txid? 12:09 < sdaftuar> luke-jr: that's the approach i prefer, but it requires redoing tx relay to use wtxid, which is probably a big change 12:10 < sdaftuar> (and i don't think anyone has started work on it) 12:10 < sipa> yes, that's a bigger change, and there are complications 12:10 < sipa> like duplicating several indexes 12:10 < sipa> and always risking downloading twice, because old nodes may announce using the txid 12:10 < sipa> twice is better than $CONNECTIONS times, but still 12:11 < luke-jr> old nodes won't relay witness transactions at all.. (or if they do, they'll be incomplete) 12:11 < gmaxwell> On CB, I'm due to test the latest version-- I had tested the earlier version.. just been testing other things recently. Those things are now merged. 12:11 < sipa> i very much like the idea of mandatory feefilter 12:11 < CodeShark> me too 12:11 < sipa> moving the responsibiloty of resource cost to the sender 12:12 < jtimon> can someone summarize the idea? 12:12 < CodeShark> it's the least hackish approach 12:12 < sdaftuar> would we get rid of free tx relay at the same time, or not necessarily? 12:12 < gmaxwell> I think mandatory feefilter should be done, though I think it is not as much of a silverbullet as some thing. Feerate is only one of several resource related limitations that get imposed. 12:12 < sipa> but are we fine for 0.13.1 with only rejection cache for non-witness, and heuristics for detecting invalid witness bloating for the most common transaction types 12:12 < BlueMatt> sdaftuar: would be nice to get rid of that code 12:13 < sdaftuar> BlueMatt: i don't object in theory, but it's a sudden change for a point release 12:13 < gmaxwell> s/thing/think/ 12:13 < CodeShark> what sort of heuristics? 12:13 < sipa> sdaftuar: agree 12:13 < BlueMatt> sdaftuar: sure, i wouldnt recommend it for that 12:13 < jtimon> just stop allowing free transactions? 12:13 < gmaxwell> sdaftuar: in practice it's not enabled in any case. 12:13 < jtimon> s/allowing/relaying/ 12:13 < BlueMatt> jtimon: we effectively already do... 12:13 < instagibbs> jtimon, it's about particular feerate, not just free 12:13 < sipa> CodeShark: check whether the witness program's embedded scriot hash matches the hash of the witness script, for example 12:13 < gmaxwell> jtimon: they're already not relayed on nodes that are up for more than a few hours. 12:13 < sdaftuar> jtimon: because mempools are full 12:13 < jtimon> so what's the mandatory feefilter changing? 12:13 < instagibbs> sipa, yes that would be an easy fix, early on 12:14 < sipa> instagibbs: there is a PR for this 12:14 < gmaxwell> "mempoolminfee": 0.00001812 12:14 < instagibbs> is that jls? I can't remember 12:14 < jtimon> if it's too long to summarize that's fine 12:14 < sipa> instagibbs: yes, on a phonr, i can't seatch the pr number 12:14 < instagibbs> #8593 12:15 < sipa> jtimon: mandatory feefilter is that you can ban a node if it does not obey the feefilter you sent it 12:15 < sdaftuar> so mandatory fee filter would only apply to witness transactions? 12:15 < sdaftuar> er, NODE_WITNESS peers? 12:15 < sipa> sdaftuar: that's a possibility 12:15 < instagibbs> he moves full input validation up front in #8539 12:15 < sdaftuar> it doesn't make sense otherwise, we can't stop relaying transactions from older clients right 12:15 < sipa> instagibbs: oh, no, not that one 12:15 < instagibbs> would be abusive to disconnect older nodes imo 12:15 < gmaxwell> sdaftuar: It has to be negoiated somehow, node witness would be one way.. though a bit disruptive on testnet. 12:16 < gmaxwell> instagibbs: no one is going to do that. 12:16 < sipa> instagibbs: full validation has some kinks to work out; something for 0.14 imho 12:16 < luke-jr> mandatory feefilter seems liable to cause issues with 1) diverging fee policies; 2) ancestor feerate (CPFP) relay stuff 12:16 < jtimon> sipa: I see, thanks, like an additional filter per peer 12:16 < BlueMatt> sdaftuar: well you could gate it on something else (protocol version/message/whatever), but I'm not against fucking up testnet to do it for NODE_WITNESS 12:16 -!- thestringpuller [~stevie@unaffiliated/thestringpuller] has joined #bitcoin-core-dev 12:16 < instagibbs> sipa, I don't see the PR you are talking about then 12:17 < sdaftuar> conceptually though: the idea is that we only download witness transactions from peers with whom we've negotiated mandatory feefilter semantics? 12:17 < jonasschnelli> instagibbs: i think there is no PR right now for that proposal 12:17 < gmaxwell> sdaftuar: that would be fine too. 12:17 < petertodd> sdaftuar: yes 12:17 < sipa> instagibbs: 8499 12:17 < sipa> yes there is 12:17 < instagibbs> oh that one 12:18 < jonasschnelli> Indeed: https://github.com/bitcoin/bitcoin/pull/8499/files 12:18 < sipa> so, i would like to request review on 8499 and 8525 12:18 < sipa> neither of those is a policy change 12:18 < instagibbs> wumpus, can you tag that PR please #8499 12:18 < sdaftuar> sipa: will do 12:19 < wumpus> sure 12:19 < instagibbs> I will review 8499 12:19 < sipa> and untag 8593 12:20 < wumpus> done 12:20 < sipa> so the only remaining thing is enforcing feefilter stronger as sdaftuar suggests only for witness peers 12:20 < BlueMatt> I'd ACK that 12:20 < gmaxwell> luke-jr: CPFP relay is already inhibited to the maximum extent that it could be by feefilter in the current non-mandatory form. Improving that will require some kind of package relay. Mandatory fee filter won't make it worse. 12:20 < sipa> does that sound reasonable for 0.13.1? 12:21 < gmaxwell> FWIW, mandatory fee filter would couple well with 8525, rejection cache mostly exists due to a lack of feefilter. 12:21 < sipa> besides fixing known bugs, obviously 12:21 < petertodd> gmaxwell: yup 12:21 < sdaftuar> sipa: yes 12:21 < petertodd> sipa: sure 12:21 < sipa> great 12:21 < sdaftuar> you started a PR that did that, yes? 12:22 < sipa> sdaftuar: not yet, i will 12:22 < sdaftuar> ok 12:22 < gmaxwell> I'd like feelers (and my addrman insert fix) to get backported. (I'm happy to do the 'backport') I think it will be important to have feelers to compensate for any loss of network density for witness enabled nodes. 12:22 < instagibbs> gmaxwell, ack 12:22 < sdaftuar> sounds reasonable 12:22 < sipa> ack on backporting feelers 12:22 < sdaftuar> curious to know if anyone has experimented with that on testnet and has any results? 12:23 < sipa> i think it will take a while for network wide effects of feelers to become visible 12:23 < sdaftuar> oh maybe i misunderstood, i thought your own node would benefit from that by itself? 12:23 < sipa> and testnet is not particularly in a sane p2p state 12:23 < CodeShark> if a node with low feefilter connects to peers that all have a higher feefilter the higher filters would dominate. is that a problem? 12:23 < gmaxwell> we had repeated minor problems with isoloation on testnet early on when we deployed segwit there. I expect less of those on mainnet, and more proactive efforts to avoid them (eg spinning up nodes), but belt and suspenders is good. 12:24 < sipa> right, but indirectly the results of addr messages will get better too from feelers 12:24 < sipa> if the overall quality of addrmans improves 12:24 < sdaftuar> sipa: ah, yes 12:24 < gmaxwell> CodeShark: the filters are one way. "Here is what you can send me" 12:24 < instagibbs> https://github.com/bitcoin/bitcoin/pull/8282 12:25 < CodeShark> gmaxwell: sure...but your peers would filter stuff you wanted to see 12:25 < sipa> next topic? 12:25 < gmaxwell> CodeShark: has nothing to do with fee filter. 12:25 < sipa> i'm in a mildly unconfortable position here (irl meetup in milan, where BlueMatt spoke) 12:25 < gmaxwell> CodeShark: peers already filter anything they won't relay. 12:26 < BlueMatt> sipa: you can irc from my laptop if you prefer 12:26 < jtimon> its kind of "please, don't bother sending me things below X or I'll disconnect from you" 12:26 < luke-jr> gmaxwell: no particular p2p protocol changes would be needed right now afaik (would just need to send the children first, and then teach the receiver to use the feerate including orphan txs) 12:27 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:ac6d:f433:257:90a2] has quit [Read error: Connection timed out] 12:27 < luke-jr> if we're not careful, mandatory feefilter could in practice make fee policy code as sensitive as consensus code 12:27 < petertodd> luke-jr: how? 12:28 < jtimon> luke-jr: I'm not following, how does the peer know your rate X 12:28 < jtimon> ? 12:28 < luke-jr> petertodd: if you change your fee policy code, you could be partitioned off from the other peers, no? 12:28 -!- cdecker [~cdecker@2a02:aa16:1105:4a80:ac6d:f433:257:90a2] has joined #bitcoin-core-dev 12:28 < sdaftuar> luke-jr: no 12:28 < instagibbs> suggested topic: "Extra" softforks low_s and nulldummy 12:28 < luke-jr> what am I missing? 12:29 < sdaftuar> only if you lie about it to your peers 12:29 < sipa> instagibbs: ack topic 12:29 < jtimon> I believe low_s was discussed already? 12:29 < BlueMatt> am I missing something? isnt the feefilter potentially rather deanonymizing? we should probably round/randomize the amount somewhat, no? (or do we, I probably wouldnt know) 12:29 < gmaxwell> luke-jr: e.g. later we can add a package fee filter and nodes would signal a package fee filter of X, and a fee filter of 0. 12:29 < sipa> i believe it needs rediscussing (low_s) 12:29 < jtimon> BlueMatt: good point 12:29 < instagibbs> BlueMatt, that's a good point 12:29 < sdaftuar> BlueMatt: we do, but worht looking at again 12:29 < gmaxwell> BlueMatt: we do. 12:30 < BlueMatt> ok, nvm, ignore my ramblings 12:30 < jtimon> BlueMatt: please keep rumbling out loud, I hadn't even thought about it, now seems obvious 12:30 < gmaxwell> BlueMatt: but also, we really can make no guarentees that a single node with multiple interfaces can't be distinguished as the same node. There are several ways to do this. (obviously I'm happy to reduce them, but it's not a property we currently provide) 12:30 < sipa> (can we move on to next topic?) 12:31 < gmaxwell> jtimon: it was specfically addressed in the original feefilter PR. 12:31 < BlueMatt> gmaxwell: indeed, shame we dont 12:31 < jtimon> ack next topic 12:31 < BlueMatt> also, what sipa said 12:31 < sipa> wumpus: ring topic bell? :) 12:31 < gmaxwell> we put wumpus to sleep. 12:31 < paveljanik> ;-) 12:31 < petertodd> gmaxwell: ring wumpus bell? 12:31 * sdaftuar rings the wumpus bell 12:31 < sipa> ok, i'll go on anyway 12:32 < paveljanik> I think that wumpus never sleeps 12:32 < jtimon> go sipa go 12:32 < sipa> so, the nulldummy and low_s softfork proposals 12:32 < btcdrak> #topic nulldummy and low_s softfork proposals 12:32 < wumpus> #topic nulldummy and low_s softfork proposals 12:32 < sipa> it was discovered by jl that low_ has a really strange implementation issue leaked into the semantics 12:32 < jtimon> I don't remember any objections on low_s last time we discussed it? 12:32 < sipa> which is not an issue for standardness, but for consensus i think we prefer clean sema tics 12:33 < instagibbs> jtimon, https://github.com/bitcoin/bitcoin/pull/8533#issuecomment-243973512 12:33 < gmaxwell> sipa: are clean semantics even possible? 12:33 < jtimon> instagibbs: thanks 12:33 < sipa> gmaxwell: yes, if we also do the only-empty-signature-in-invalid-checksig sf 12:33 < gmaxwell> sipa: oh indeed okay, yes that would be clean 12:33 < sipa> which is why i'd propose that we do low_s later, together with that empty sigs rule 12:34 < sipa> and only bundle nulldummy with 0.13.1 12:34 < sipa> s/0.13.1/segwit/ 12:34 < gmaxwell> The clenlyness issue is that lowS test fails for some encodings of invalid encodings. 12:34 < gmaxwell> er encodings of invalid signatures. 12:34 < sipa> yes, some illegal signatures are exempt from low_s 12:34 < BlueMatt> would be a shame, but seems like a reasonable approach...has anyone checked for the #/frequency of invalid sigs in the chain? 12:34 < BlueMatt> that are non-0-length, at least 12:35 < sipa> such signatures are NOT valid 12:35 < BlueMatt> but can bt OP_NOT'd, no? 12:35 < sipa> yes, but nobody sane does that 12:35 < sdaftuar> has NULLDUMMY been discussed on the mailing list yet? i see one mention of it in passing about the LOW_S BIP. 12:35 < BlueMatt> sure, but /has/ anyone ever done so? 12:35 < sipa> "yes, this output can be spent UNLESS BlueMatt likes it" 12:35 < jtimon> no objections on delaying low_s enforcement 12:35 < gmaxwell> BlueMatt: with the exception of intentional insanity, any invalid signature could be malleated to a zero length one, in any case. I had looked previously and seen no ongoing checksig-not activity, obvious. 12:35 < BlueMatt> I might suggest that it is not crazy to propose doing it in 0.13.1 if it has never happened 12:36 < BlueMatt> indeed, I'm asking with the assumption that someone might have done intentional insantiy as a test-case or so 12:36 < sipa> BlueMatt: the only opractical difference is that the BIP to specify LOW_S would contain a rule that is pointless and complicating 12:36 < sipa> i think we should aboid that 12:36 < BlueMatt> (wait, it is non-stad to do non-0-length, correct?) 12:36 < gmaxwell> BlueMatt: a checksig not has been done at least once in the chain history. 12:36 < jtimon> BlueMatt: good question, petertodd has anybody done that? :p 12:36 < gmaxwell> By someone triggering a fork off of bitcoin ruby. 12:37 < sipa> petertodd: have you done that? 12:37 < BlueMatt> gmaxwell: sure, but with 0-length, or with a non-emtpy sig 12:37 < gmaxwell> yea, don't recall, we could check. 12:37 < petertodd> sipa: me personally, probably not - I'm a fine arts grad :P 12:37 < gmaxwell> But I don't think the test here should be none at all. If there was an obvious test someplace in the past, who cares? 12:37 < BlueMatt> (this would be immaterial if it is not already nonstd...which I do not recall) 12:37 < sipa> jl also pointed out that the benefit of low_s is lower, as it can only be used.for mutating, but not for bloating 12:38 < BlueMatt> I was informed that non-0-length invalid sigs is not nonstd 12:38 < BlueMatt> I would propose we do so in 0.13.1 12:38 < gmaxwell> It is non-standard for segwit. (unless I am on drugs.) 12:38 < sipa> gmaxwell: you're on drugs 12:38 < gmaxwell> I am on drugs then. Okay. Good to know. 12:38 < jtimon> are we still talking low_S ? 12:39 < sipa> yes 12:39 < BlueMatt> I was assuming it was nonstd, and thus thought it might be reasonable for a softfork, but withdraw my insanity 12:39 < gmaxwell> wlel thats insane, we should fix that at least. 12:39 < BlueMatt> gmaxwell: ack 12:39 < gmaxwell> yes, it needs to be non-standard first. pronto. 12:39 < BlueMatt> 0.13.1 should make invalid sigs which are non-0-length nonstd 12:39 < sipa> agree 12:39 < sdaftuar> agree 12:39 < wumpus> yes, absolutely 12:39 < CodeShark> +1 12:39 < sipa> great 12:40 < jtimon> this needs a bip, no? 12:40 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Quit: Lost terminal] 12:40 < sipa> jtimon: yes, but we just suggest it as nonstd now 12:40 < jtimon> sure 12:40 < sipa> (which certainly needs ML discussion too) 12:40 < gmaxwell> there is copy for null dummy as part of the old malleability bip, no? 12:40 < gmaxwell> nulldummy and fixed invalid? 12:40 < sipa> null dummy is about the ignored arg for CMS 12:41 < gmaxwell> thus my follow up. 12:41 < sipa> empty invalid was not part of bip62 12:41 < gmaxwell> okay. 12:41 < sipa> because it wasn't needed fir standard txn at the time 12:41 < sipa> ok, next topic? 12:42 < kanzure> jeremyrubin's stuff see above 12:42 < kanzure> 12:04 < jeremyrubin> I'd like to mention that my Checkqueue Lockfree is passing tests, would like to hear what people need to see for it to merge (will be restructuing my commits later today.tomorrow) 12:42 < gmaxwell> jeremyrubin is busy making validation great again. I'm super excited about this. 12:42 < sdaftuar> sorry before we move topics -- we should repropose NULLDUMMY by itself on the mailing list, yes? 12:42 < wumpus> if he's here, at least 12:42 < sipa> sdaftuar: ack 12:42 < BlueMatt> gmaxwell: ACK 12:42 < petertodd> so, one mitigation to this malleability stuff I think we should also consider doing, is having transaction replacement trigger if the tx has a higher fee rate than the old tx (over a certain ratio) 12:43 < instagibbs> link to jeremyrubin's stuff? 12:43 < sipa> petertodd: that would be a side effect of switching to wtzid based indexing, actually 12:43 < sdaftuar> https://github.com/bitcoin/bitcoin/pull/8464 12:43 < kanzure> instagibbs: https://github.com/bitcoin/bitcoin/pull/8464 12:44 < jonasschnelli> It's a very invasive change... 12:44 < jonasschnelli> though, I like the concept 12:44 < BlueMatt> jonasschnelli: its worth it, by a lot 12:44 < btcdrak> sdaftuar there is a NULLDUMMY only PR as well https://github.com/bitcoin/bitcoin/pull/8636 12:44 < petertodd> sipa: not quite - I'm proposing we re-broadcast such replacements to our peers 12:45 < BlueMatt> (for those interested, when it was first posted I went and reimplemented it as lockfree but with a single atomic which was contested between threads a decent amount.....my reimplementation might not have been ideal, but was only marginally better than master...jeremy's work is something like 10-20%) 12:45 < petertodd> sipa: need to pick a reasonable ratio, geometric series, so something like 75% would be absolute worst case a 4x bandwidth increase, while allowing no more than 25% bloat by a malleability attacker 12:45 < sdaftuar> petertodd: you're suggesting different replacement semantics than we have under BIP 125? 12:45 < sipa> ah, i see 12:46 < petertodd> sdaftuar: yeah, obvious one would be to just do replacements if vout #1 == vout #2 regardless of BIP125, which handles malleability just fine 12:47 < petertodd> sdaftuar: mainly proposing this as a belt and suspenders to limit the damage of malleability attacks 12:47 < gmaxwell> petertodd: may just be better for mempool reconcillation to handle that. 12:47 < petertodd> gmaxwell: sure - when's that coming? :) 12:47 < gmaxwell> petertodd: interested in helping define it? :P 12:48 -!- Cory [~C@unaffiliated/cory] has quit [] 12:48 < sipa> i believe we're drifting off topic 12:48 < gmaxwell> Who was phone? 12:48 < petertodd> gmaxwell: heh, seems like I should do a pull-req of this ratio thing for now - that's just a few lines of code 12:48 < gmaxwell> fair 12:49 < sipa> other topics? 12:49 < gmaxwell> petertodd: if you do it right, it will interact well with mempool batching, and the batching will eliminate a lot of the bandwidth overhead. 12:49 < wumpus> yes, any other topic proposals? 12:49 < gmaxwell> s/mempool batching/relay batching/ 12:49 < petertodd> gmaxwell: oh, batching? I'm unfamilar with that idea 12:50 < BlueMatt> 10 min bell 12:50 < gmaxwell> petertodd: relay behavior changed in 0.13, I think you're aware. 12:50 < gmaxwell> petertodd: will talk after meeting. 12:50 < petertodd> gmaxwell: ack 12:50 < sdaftuar> quick travis discussion? 12:50 < wumpus> seems that there are no other meeting topics proposals, so we can close 12:51 < wumpus> sure 12:51 < GitHub133> [bitcoin] jonasschnelli opened pull request #8643: [0.13 backport] Added feeler connections increasing good addrs in the tried table. (0.13...2016/08/feeler_013) https://github.com/bitcoin/bitcoin/pull/8643 12:51 < gmaxwell> Non-discussion: 0.13 deployment seems to be trouble free , congrats everyone. 12:51 < wumpus> #topic travis discussion 12:51 < sdaftuar> i've been away for the last couple weeks, can anyone summarize the state of our testsuite these days? 12:51 < jeremyrubin> Yes 12:51 < sdaftuar> i feel like i've seen lots of people complaining 12:51 < wumpus> yes, congrats everyone on the 0.13.0 release 12:51 < jeremyrubin> Basically theres some failing rpctests 12:51 < sdaftuar> and my own local runs are failing a lot too, but i havent figured out why yet 12:51 < jeremyrubin> and the make check code is slow 12:51 < gmaxwell> what is this backupwallet test thing that keeps failing? 12:51 < wumpus> there are randomly failing RPC tests, and also some random timeouts 12:51 < cfields> yes, there are a few racy conditions 12:51 < sipa> segwit.py also fails sometimes 12:52 < jeremyrubin> I've also seen an abandonconflict failure once 12:52 < cfields> i believe i tracked down the segwit issue, which may be the root cause of some other issues 12:52 < sdaftuar> oh! good to know 12:52 < gmaxwell> I saw some indication before that this was actually misbehavior on the part of the travis infra, that it was occassionally running too slow and timing out. 12:52 < sipa> cfields: elobarate? 12:52 < cfields> (if that's the same as the one that was worsened by the timing change) 12:53 < cfields> sipa: need to check if it's the same thing and gather my notes, take it up after meeting? 12:53 < jonasschnelli> can we not just move the segwith test to the end/last item? 12:53 < sipa> cfields: ok 12:53 < sdaftuar> sounds good 12:53 < wumpus> there's an issue open about txn_doublespend and segwit.py, it was worse and made batter by reverting a timeout change, but not solved (as MarcoFalke says) 12:53 < jonasschnelli> s/segwith/segwit 12:53 < wumpus> the thing is, the tests never fail locally at least here 12:53 < wumpus> so yes I also suspect the travis infrastructure for some failiures 12:54 < jeremyrubin> There's also an open issue with travis race conditions internally 12:54 < wumpus> anyhow the issue is https://github.com/bitcoin/bitcoin/issues/8532 12:54 < jtimon> I suspect some tests fail in a non-reproducible way, I don't have local travis, but when the tests doesn't fail locally I just change the last commit id and force push, it works most times 12:54 < sipa> sdaftuar says he sometimes sees the failures locally? 12:54 < sdaftuar> sipa: yes, with an error condition i don't understand at all, let me find it 12:54 < jeremyrubin> e.g. if you push a commit before the last push finished testing 12:54 < cfields> ok, same one then. the issue there is that the node heights are in sync, but the wallet hasn't necessarily updated with their txs. So sync_all() followed by a balance check is racy. 12:55 < wumpus> so we need a better sync call 12:55 < sipa> cfields: so switch to a while loop until balances are an equal/expected value, with a certain timeout? 12:55 < wumpus> a kind of fence 12:55 < wumpus> sipa: that would imply updating all the balance checks to loops 12:55 < gmaxwell> run a ping and check the ping time on all the node.s 12:56 < jonasschnelli> gmaxwell: from the RPC API? 12:56 < sipa> getpeerinfo, i oresume 12:56 < gmaxwell> yes, the ping will act as a barrier in the current p2p protocol, though perhaps cfields is about to kill me 12:56 < sipa> i hope cfields isn't changing that barrier effect 12:56 < BlueMatt> gmaxwell: iirc breaking that breaks things 12:56 < wumpus> yes, ping will work for that, but it's unclear how to use that in RPC tests 12:56 < cfields> i was thinking about some rpc call like "wait_for_[height|block]" that would block until reached and finished processing everywhere. then we wouldn't need to loop 12:56 < gmaxwell> we had that discussion with cfields before, which is why I mention it. :P 12:56 < cfields> i suppose that just introduces its own issues, though 12:57 < cfields> heh 12:57 < wumpus> no, the barrier effect certainly shouldn't be removed, unless a better mechanism is introduced 12:57 < BlueMatt> (I'd actually kinda like a test which relies on pings being barriers, since some software assumes that for the p2p network, and, in fact, for some things you have to) 12:57 < gmaxwell> (I actually like ping being head of line blocked for the reason that it lets you measure processing delays of your remote peers) 12:57 < wumpus> and that's a huge protocol change, so probably not worth it right now 12:57 < sipa> yes, that's out of scope 12:57 < gmaxwell> sorry, I started a tangent. 12:58 < cfields> well, as a nasty short-term fix, we can just throw some sleeps in after sync. that should at least shut travis up while we work on a fix 12:58 < sipa> for a "get the damn unit tests to work again", at least 12:58 < gmaxwell> in any case, maybe ping can be used to sync for these tests. 12:58 < BlueMatt> 2 min bell 12:58 < wumpus> sleeps are pretty terrible, it's easy to get those wrong and travis has a very unpredictable load pattern 12:58 < gmaxwell> sleeps for now sound fine to me. We could all use more sleep. 12:58 < wumpus> hah 12:58 < sdaftuar> i was seeing this a bunch, but i haven't looked at the latest fails yet to confirm if they're the same: https://0bin.net/paste/nvDO+4yPU0w5332j#Y4BWnYpKcTTIW6ePHglWpEwpE4XtfA+I-NP2M3ObMkp 12:58 < jonasschnelli> sleeps will just kick the problem a bit further down... 12:58 < BlueMatt> cfields: if we commit to reverting it within X days, ACK 12:58 < wumpus> but indeed this started when the timeouts were lowered all over the place 12:58 < gmaxwell> tests randomly faily though is ... not good. 12:59 < jtimon> cfields: go with the sleeps, better solutions later 12:59 < gmaxwell> jonasschnelli: I'm not suggesting delting fixing things at all. 12:59 < jonasschnelli> and a sleep in sync_all will have a performance impact on the test-duration-tim 12:59 < jonasschnelli> though, ack on the sleep for now 12:59 < sipa> sgtm 12:59 < wumpus> right 12:59 < cfields> BlueMatt: +1 for that. Sleeps are ripped out at next meeting if they're still there, and the tests fails again 12:59 < gmaxwell> we must not habituate ourselves to test failures being orinary, already that we weren't responding to failures as a potential emergency indicates we're in a bad state. 12:59 < BlueMatt> ACK 12:59 < sdaftuar> gmaxwell: yep 13:00 < BlueMatt> ACK to gmaxwell and cfields 13:00 < BlueMatt> also, dingdingding 13:00 < sipa> POING 13:00 < wumpus> #endmeeting 13:00 < lightningbot> Meeting ended Thu Sep 1 20:00:10 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-01-19.01.html 13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-01-19.01.txt 13:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-09-01-19.01.log.html 13:00 < wumpus> gmaxwell: yes it's not a good thing that travis failures are a normal thing now 13:00 < wumpus> I tend to rely on local tests more and more 13:00 < wumpus> if that continues, travis just becomes a distraction 13:01 < sipa> ;;tslb 13:01 < gribble> Time since last block: 31 minutes and 15 seconds 13:01 < cfields> an alternative is to avoid giving up cs_main while the wallet syncs, but i suppose we shouldn't neuter real usage for the sake of tests :p 13:01 < wumpus> cfields: yes, and adding a flag to do that for the tests kind of defeats the purpose of tests too 13:01 < wumpus> let's try to solve it properly 13:02 < petertodd> gmaxwell: I'm aware that we changed relay behavior; forget the exact details there 13:02 < cfields> wumpus: sure, that wasn't a real suggestion 13:02 < gmaxwell> petertodd: regarding batching, 0.13 changed relay behavior so every peer has a possion timer (5 seconds expected or 2 seconds for outbound), no relaying happens on a peer until the timer hits again. when relaying happens, the transactions are checked to see if they're still in mempool and still passing fee filter.. and relayed in topology+feerate sorted order 13:03 < jeremyrubin> (a "stopgap" measure till better things are worked out could be to run the rpc tests 3 times and take a best of three; that way we at least get rpc_tests not blocking probably working code) 13:03 < gmaxwell> petertodd: so I'm pointing out that if the replacement arrives soon, and the original is removed from the mempool, it will never get offered to most peers. 13:03 < wumpus> cfields: adding a wait RPC specific to testing to wait for completion of some ongoing things would be fine, though 13:04 < jeremyrubin> (that would at least help us catalouge a definitely non-deterministic failure) 13:04 < gmaxwell> jeremyrubin: I don't think thats better than increasing the sync sleeping... it would conceal real issue of kinds that we've encountered before, and it would make travis much slower. :) 13:04 < petertodd> gmaxwell: right, so in the malleability case, if we get a 1-byte-less transaction, but haven't sent out the previous one yet to many of our peers, it'd be perfectly reasonable to replace, for instance 13:04 < cfields> wumpus: i've often thought that would be very helpful. Not sure how to avoid long timeouts when things really do fail, though 13:04 -!- xiangfu [~xiangfu@58.135.95.141] has quit [Ping timeout: 265 seconds] 13:04 < jtimon> agreed, if we get used to "that's probably a travis thing, just push again" then it becomes kind of worthless, when it fails you should be able to get the same error at home 13:05 < wumpus> cfields: well we already have plenty of timeouts, can't become that much worse, most important is that everything is logged so that it can be troublehsooted 13:05 < gmaxwell> petertodd: right. in general I think the replacement should always happen in the mempool, and if we relay or not is a seperate decision. 13:05 < cfields> wumpus: so maybe not wait-for-completion, but wait-for-a-while? 13:05 < jeremyrubin> gmaxwell: you can still have it fail; but at least being able to have an estimate of if it is deterministic fail or spurrious would be useful 13:05 < gmaxwell> petertodd: and for CB we should have a rejection/eviction cache. 13:05 < cfields> wumpus: fair point 13:05 < petertodd> gmaxwell: CB? compact blocks? 13:05 < sdaftuar> gmaxwell: why do we need an eviction cache, if we're using feefilter? 13:05 < gmaxwell> jeremyrubin: okay, potentially useful. Though the time is a concern. 13:05 -!- xiangfu [~xiangfu@58.135.95.141] has joined #bitcoin-core-dev 13:05 < sdaftuar> oh 13:06 < sdaftuar> i misunderstood 13:06 < jeremyrubin> gmaxwell: can have further runs only happen if the last one fails 13:06 -!- w00t88 [b3da1843@gateway/web/cgi-irc/kiwiirc.com/ip.179.218.24.67] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client] 13:06 < jeremyrubin> gmaxwell: (up to a bound) 13:06 < cfields> wumpus: wait_for_block(height, hash) seems pretty obvious. If either one is hit without matching, it returns failure. That at least eliminates some potential timeouts 13:06 < gmaxwell> jeremyrubin: too bad there is probably no way to report the failure right away and keep running. :P 13:06 < petertodd> gmaxwell: this could solve this SIGHASH_ANYONECANPAY issue w/o having to put in specific support for SIGHASH_ANYONECANPAY 13:06 * jeremyrubin shakes fist at travis 13:07 < wumpus> cfields: what about a 'wait for a change in either height or hash'? 13:07 < wumpus> cfields: the client can then check the details 13:08 < jeremyrubin> gmaxwell: after_failure hook? Not sure when those get run w.r.t. ui updates :) 13:08 < cfields> jeremyrubin: seems to me that behavior belongs in the test-script, so that it can be done locally as well 13:08 < jeremyrubin> cfields: fair. 13:08 < gmaxwell> petertodd: my current mental model for how all this stuff should work is that you should make your mempool the best, and then have a bandwidth limited process that at every timestep uses the available bandwidth in the best way you can to bring your peers closer to your idea of the best. And for the purpose of CB you should keep around recent second bests for a little while. 13:08 < cfields> wumpus: makes sense. and in that case, we block until everything is done processing rather than asap 13:08 < jeremyrubin> cfields: proposal: failed test gets re-run once after all tests complete? 13:08 < cfields> wumpus: i like that. 13:09 < wumpus> cfields: doesn't matter to loop a bit in the client, after all 13:09 < wumpus> cfields: right 13:09 < jtimon> gmaxwell: oh, even with the parallel rpc tests you still wait for all to fail without seeing anything...yuck 13:09 < petertodd> gmaxwell: makes sense to me too 13:09 < cfields> wumpus: i should think that would speed tests up a pretty good bit as well. avoids tons of msec waits 13:10 < petertodd> gmaxwell: also, at some point you want to be transmitting tx replacement deltas, rather than full txs, but that's an advanced topic... 13:10 < cfields> wumpus: ok, that sounds simple enough. only complication would be waiting for the wallet 13:10 * cfields crosses his fingers that there's some signal/condvar already doing that 13:11 < gmaxwell> I don't know that that would be worth the effort. maybe. once you compress the tx format, most of the size comes from high entropy parts in signatures which would change on most modifications. 13:11 < petertodd> gmaxwell: a simple first step might be to have a boolean flag in AcceptToMemPool the decides whether or not we'll relay this newly accepted transaction 13:11 < petertodd> gmaxwell: in the transaction replacement case, often you'll just be changing small parts of a tx - sigs don't come into it (especially if it's malleability that lead to the replacement) 13:11 < wumpus> cfields: yes, it needs to be a wallet call 13:12 < sdaftuar> petertodd: for context, are you talking about a replacement policy specifically for when txids match existing ones (ie malleated segwit transactions), or something more general? 13:12 < jtimon> gmaxwell: yep, your idea of the ideal mempool/relay management is great and respectful with diverse policies, I was scared when I read the first "the best" and breathed with "your idea of the best" 13:12 < gmaxwell> petertodd: I just mean that if the modification changes outputs, it will normally change signatures... 13:12 < petertodd> sdaftuar: slightly more general; I'd do it so long as the vout is the same 13:12 < petertodd> gmaxwell: normally :) but not always, e.g. SIGHASH_ANYONECANPAY 13:13 < sdaftuar> oh, so if someone adds an input, you can remove it 13:13 < sdaftuar> i think you guys were discussing that on some PR? 13:14 < petertodd> sdaftuar: yup 13:14 < petertodd> sdaftuar: https://github.com/bitcoin/bitcoin/pull/8543 13:14 < sdaftuar> thanks 13:14 < jtimon> note that the "second best" pool may not be "second best" at all, maybe stuff that passes your minimums and your peers seem to repeat for some unkown reason (they should know that's not the best, but at least they agree on being wrong on the same weird way) 13:14 < gmaxwell> jtimon: well unlikely luke I don't actually believe that different policies (beyond straight resource limits) are actually virtuious, but in a hetrogenious network, with softforks and whatever, its simply unrealistic to expect equal policy even though I think it would be ideal to have equal policy. 13:15 < gmaxwell> jtimon: yea by 'second best' I really meant something more like "data you previously had, prioritized by how shocked you'd be to see it in a block" 13:15 < gmaxwell> e.g. you wouldn't keep invalid transactions, but you would keep non-standard ones. 13:16 < gmaxwell> s/unlikely/unlike/ 13:16 < jtimon> I guess it's kind of a philosophically pedantic way of saying "hey, this is not consensus code", but terms...we agree on the overall design 13:17 < jtimon> gmaxwell: lol, let's call it "the shockpool" 13:18 < jtimon> but I really don't know what criteria would I use there 13:19 < cfields> wumpus: looking closer, if we subscribe to a signal rather than just hammering on chainActive.Tip(), the wallet will have already been sync'd. So that's easy. doing it up now. 13:20 < sdaftuar> cfields: ah, good idea 13:21 < gmaxwell> jtimon: well obviously you just use machine learning to predict what will end up in blocks... :P 13:22 < petertodd> gmaxwell: better, yet, use hashing power to make your predictions come true... 13:22 < jtimon> gmaxwell: of course, I'm ashamed I hadn't thought of a neural network, the fact that txs are variable size shouldn't stop us... 13:22 < gmaxwell> jtimon: hah well actually running a model on the tx data itself is not likely to work well without a very big model. 13:23 < gmaxwell> feature vector is [feerate, tx version, vector of failed is standard rules, time in the shockpool] and the model outputs a ranking that tells you how long you should retain it. :P 13:23 < gmaxwell> I've suggested similar things for utxo cache management in the past. 13:24 < jeremyrubin> Can I ask for some thoughts on the checkqueue stuff? 13:24 < jtimon> gmaxwell: model? what's wrong with feeding them binary data? 13:25 < jtimon> 13:25 < jeremyrubin> My basic plan for restructuring was to add the benchmarks for the earlier version and then add the new version. I wasn't going to make my tests work for the old code, but could do it if that's neccessary for review 13:25 < gmaxwell> jtimon: nothing, except the result will require a large, deep, complex and hard to train network. at it has to learn transaction parsing. The result would be low performance enough that I think it would preclude actually using for anything except a toy. :) 13:25 < gmaxwell> oh okay. 13:25 < gmaxwell> :P 13:25 < jeremyrubin> (also if anyone would care to try testing it out would be great help for me) 13:26 < jeremyrubin> (for reference, PR is here https://github.com/bitcoin/bitcoin/pull/8464) 13:29 < Chris_Stewart_5> jeremyrubin: Might be worth while to look at #8469 and write some properties for testing 13:30 < gmaxwell> jonasschnelli: thanks for that backport. 13:30 < jeremyrubin> Chris_Stewart_5: looks cool; I have a pretty good test suite I added already though. When that gets merged I'd be happy to 13:31 -!- gabridome1 [~gabridome@5.90.33.44] has joined #bitcoin-core-dev 13:32 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 265 seconds] 13:34 -!- gabridome [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Ping timeout: 276 seconds] 13:34 < jtimon> gmaxwell: yep, it would need to learn script parsing, for all I know, random search may be as good as anything else for training in this case 13:36 -!- HoloIRCUser6 [~holoirc@104.129.29.236] has joined #bitcoin-core-dev 13:36 -!- gabridome1 [~gabridome@5.90.33.44] has quit [Read error: Connection reset by peer] 13:36 -!- gabridome [~gabridome@2-228-102-98.ip191.fastwebnet.it] has joined #bitcoin-core-dev 13:37 -!- gabridome1 [~gabridome@5.90.33.44] has joined #bitcoin-core-dev 13:40 -!- HoloIRCUser6 [~holoirc@104.129.29.236] has quit [Ping timeout: 265 seconds] 13:41 -!- gabridome [~gabridome@2-228-102-98.ip191.fastwebnet.it] has quit [Ping timeout: 252 seconds] 13:41 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 13:42 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 13:43 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 255 seconds] 13:49 < gmaxwell> PR #8212 needs backport too. 13:49 < gmaxwell> er I meant PR #8612. 13:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 255 seconds] 13:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 13:52 < instagibbs> what's the New Improved Way(TM) to get uint256 as string 13:53 < instagibbs> still working my way around git blaming in reverse, failing me right now 13:54 < gmaxwell> instagibbs: do you mean as hex? 13:54 < instagibbs> yeah hex string 13:57 < instagibbs> oh weight, nevermind me, just in .cpp now, and complaining 13:57 < instagibbs> wait even 13:57 < instagibbs> probably just fat fingered 13:59 -!- Eliel_ [~jojkaart@104-250-47-212.rev.cloud.scaleway.com] has quit [Ping timeout: 244 seconds] 14:00 -!- HoloIRCUser [~holoirc@179.218.24.67] has joined #bitcoin-core-dev 14:00 -!- Eliel [~jojkaart@104-250-47-212.rev.cloud.scaleway.com] has joined #bitcoin-core-dev 14:06 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 14:13 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 14:14 < gmaxwell> interesting: 14:14 < gmaxwell> 2016-09-01 15:35:29.537118 replacing tx 528f6cbebe29fa6bdab3be077a48754c2371df2fbf4cbb8fbc11992fdeb26470 with 14:14 < gmaxwell> 922a0895c7246b46533d1d356152bde2477cc9987c96b78e02da4d5869e4b7cc for 0.00008873 BTC additional fees, -194 delta bytes 14:14 < gmaxwell> 2016-09-01 15:35:29.537194 replacing tx 308a560e8e90ccaf64af9f5cd3b1dcfe4bccf8d49d73b0460b95b1616bb26c9d with 14:14 < gmaxwell> 922a0895c7246b46533d1d356152bde2477cc9987c96b78e02da4d5869e4b7cc for 0.00008873 BTC additional fees, -194 delta bytes 14:14 < gmaxwell> 2016-09-01 15:35:50.780139 Successfully reconstructed block 000000000000000002f65cc5054fefb1b8fe75ebb685ac6b51f05dac0b84ee3d with 1 txn 14:14 < gmaxwell> prefilled, 2465 txn from mempool and 2 txn requested 2016-09-01 15:35:50.780208 Reconstructed block 14:14 < gmaxwell> 000000000000000002f65cc5054fefb1b8fe75ebb685ac6b51f05dac0b84ee3d required tx 14:15 < gmaxwell> 528f6cbebe29fa6bdab3be077a48754c2371df2fbf4cbb8fbc11992fdeb26470 14:15 < gmaxwell> 2016-09-01 15:35:50.780253 Reconstructed block 000000000000000002f65cc5054fefb1b8fe75ebb685ac6b51f05dac0b84ee3d required tx 14:15 < gmaxwell> 308a560e8e90ccaf64af9f5cd3b1dcfe4bccf8d49d73b0460b95b1616bb26c9d 14:18 < gmaxwell> other recent CB extra round trips were: a single txn that failed minfee 30 minutes before the block, a pair of transactions that were rejected due to being mempool conflicts ~5-10 minutes before the block, and an orphan that was in my orphan pool at the time. 14:22 < luke-jr> gmaxwell: presumably the parent of the orphan was missing in your mempool? was that one of the conflicts? 14:23 < gmaxwell> those were three steperate blocks. 14:23 -!- HoloIRCUser [~holoirc@179.218.24.67] has quit [Ping timeout: 276 seconds] 14:23 < luke-jr> so what was the cause of the orphan not being in the mempool (or rejected)? 14:23 < gmaxwell> yea, trying to figure that out. 14:24 -!- HoloIRCUser [~holoirc@104.129.29.236] has joined #bitcoin-core-dev 14:24 < gmaxwell> maybe it actually had been evicted by the time the parent came around. 14:24 < gmaxwell> 2016-09-01 11:50:23.982337 stored orphan tx aeb9dac61cf2cc7fd535f2b4b685070b0dce2690c9f78d9987335cbadedf5aa3 (mapsz 101 outsz 110) 14:25 < gmaxwell> 2016-09-01 11:53:45.913417 Successfully reconstructed block 000000000000000004e70299cd0284b177412b63144fc4b9c6080c65545e875b with 1 txn prefilled, 1868 txn from mempool and 1 txn requested 14:25 < gmaxwell> 2016-09-01 11:53:45.913505 Reconstructed block 000000000000000004e70299cd0284b177412b63144fc4b9c6080c65545e875b required tx aeb9dac61cf2cc7fd535f2b4b685070b0dce2690c9f78d9987335cbadedf5aa3 14:26 < luke-jr> hmm 14:26 < gmaxwell> looking up the parents now. 14:28 < luke-jr> FWIW, looking through my logs, most blocks seem to require a round trip. not particularly surprising (spam I assume) 14:28 < gmaxwell> luke-jr: wow, no way. 14:28 -!- HoloIRCUser [~holoirc@104.129.29.236] has quit [Ping timeout: 265 seconds] 14:29 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 265 seconds] 14:29 < luke-jr> http://0bin.net/paste/nELoeFqIuT4891qP#P8ugYLrvtlhggdD80jGS5NDOuhJYpJ37JgDgHiGF1CF 14:30 < gmaxwell> grep econs ~/.bitcoin/debug.log | tail -n 100 | awk '{aa+=$16>1} END {print aa/NR}' 14:30 < gmaxwell> 0.11 14:30 < gmaxwell> 11% here. 14:30 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 14:30 < luke-jr> 0.661538 14:31 < gmaxwell> how long have you been up? 14:31 < gmaxwell> my past expirence is that it takes a good 24 hour uptime before it really behaves normally (and I think I saw measureable improvement for up to three days, though much of that was due to orphans, which should be less bad since the other changes.) 14:32 < gmaxwell> also, if you have an atypical mempool policy, thats going to slow you down.. until we get some kind of rejects cache going. 14:33 < luke-jr> about 1.5 hours now, but quite a bit longer before that restart 14:33 < luke-jr> yes, that's why I said not surprising ;) 14:33 < gmaxwell> oh... 'spam I assume' 14:33 < gmaxwell> indeed. okay. 14:35 < luke-jr> sub-second round-trip for 3 txn, so I assume it's still a gain 14:37 < gmaxwell> luke-jr: yes, I found that it was in testing. 14:41 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 14:44 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 14:58 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 15:01 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 15:11 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 15:12 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:18 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 276 seconds] 15:19 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 255 seconds] 15:24 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 15:28 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 15:28 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 244 seconds] 15:31 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 15:35 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 16:00 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 16:32 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 276 seconds] 16:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 16:37 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 16:46 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds] 17:03 -!- gabridome [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has joined #bitcoin-core-dev 17:06 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pjyccpdnldrwmgef] has quit [Quit: Connection closed for inactivity] 17:12 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 17:13 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 17:16 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev 17:23 < GitHub92> [bitcoin] gmaxwell opened pull request #8644: [0.13 backport] Check for compatibility with download in FindNextBlocksToDownload (0.13...findnext_backport) https://github.com/bitcoin/bitcoin/pull/8644 17:24 < gmaxwell> Do we want to backport, "Reduce default number of blocks to check at startup"? It's a trivial fix to long startup time complaints, and arguably the dbcache increase in 0.13 was a startup time regression for some people. 17:25 < GitHub29> [bitcoin] droark opened pull request #8645: Remove unused Qt 4.6 patch. (master...master) https://github.com/bitcoin/bitcoin/pull/8645 17:26 < sipa> i would be fime with that, though calling it a bugfix is a stretch 17:27 < gmaxwell> well I gave a pragmatic argument for it being one. 17:27 < gmaxwell> but I don't think I needed to, it's pretty obviously riskless with no "interface" impact. 17:28 < sipa> yes, i agree it has very low risk 17:28 < gmaxwell> which I think beyond 'fix' should be the goal for point releases, nothing that is going to turn a working deployment into a broken one. 17:32 < luke-jr> sounds reasonable to do, in any case 17:36 < GitHub176> [bitcoin] gmaxwell opened pull request #8646: [0.13 backport] Reduce default number of blocks to check at startup (0.13...reduceblocks_backport) https://github.com/bitcoin/bitcoin/pull/8646 17:39 -!- gabridome [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has quit [Quit: gabridome] 17:41 -!- gabridome [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has joined #bitcoin-core-dev 17:42 -!- gabridome [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has quit [Client Quit] 17:43 -!- gabridome [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has joined #bitcoin-core-dev 17:44 < GitHub102> [bitcoin] gmaxwell opened pull request #8648: [0.13 backport] Precompute sighashes (0.13...precompute_backport) https://github.com/bitcoin/bitcoin/pull/8648 17:44 < gmaxwell> wumpus: feel free to close my backport prs if you don't find them helpful, I was just feeling usless simply saying X or Y should be backported rather than doing it. 17:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 17:56 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 17:57 -!- gabridome [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has quit [Quit: gabridome] 18:00 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 18:13 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 18:16 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 18:17 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.4] 18:17 -!- justanotheruser [~justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 18:34 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 18:34 -!- achow101 [~achow101@129.2.206.174] has quit [Remote host closed the connection] 18:35 -!- achow101 [~achow101@129.2.206.174] has joined #bitcoin-core-dev 18:38 < jl2012> We need a nulldummy only bip? 18:38 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 18:42 < jl2012> And I already have a PR for empty failing signature https://github.com/bitcoin/bitcoin/pull/8634 18:47 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 18:51 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 18:57 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 18:58 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 19:01 -!- Chris_St1 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 19:04 < cfields> sdaftuar: did you say you were able to reproduce the segwit.py failure locally? 19:05 < cfields> sdaftuar: if so: https://github.com/theuni/bitcoin/commit/fa88a425c0c1089ab75ea9223699286f40c8eea7 19:06 < cfields> it's pretty hackish, needs a cleanup. But should be enough to determine if it fixes the problem 19:07 < cfields> wumpus: let me know if ^^ is what you had in mind 19:09 < cfields> that not only eliminates polling, but also drops cs_main locking, so i should think it'd be a good bit quicker 19:19 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 19:20 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 19:21 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4] 19:25 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has left #bitcoin-core-dev ["Verlassend"] 19:25 -!- achow101 [~achow101@129.2.206.174] has quit [Remote host closed the connection] 19:27 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 240 seconds] 19:29 -!- jtimon [~quassel@38.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 19:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 19:31 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 19:35 -!- adiabat [~adiabat@159.203.193.74] has joined #bitcoin-core-dev 19:41 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 19:42 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 19:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 19:55 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 19:56 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 20:00 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 20:04 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 20:05 -!- justanotheruser [~justan@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds] 20:24 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:25 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 20:36 -!- jcorgan [~ubuntu@unaffiliated/jcorgan] has joined #bitcoin-core-dev 20:45 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 240 seconds] 20:47 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has joined #bitcoin-core-dev 20:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 20:56 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 20:57 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 21:01 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: zzzzzz] 21:02 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 21:05 -!- TomMc [~tom@gateway/vpn/privateinternetaccess/tommc] has quit [Ping timeout: 244 seconds] 21:11 -!- JackH [~Jack@79-73-189-132.dynamic.dsl.as9105.com] has quit [Ping timeout: 265 seconds] 21:11 -!- JackH [~Jack@79-73-189-132.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 21:22 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:33 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 21:37 -!- cfields [~quassel@unaffiliated/cfields] has quit [Remote host closed the connection] 21:40 -!- achow101 [~achow101@129.2.206.174] has joined #bitcoin-core-dev 21:42 -!- achow101 [~achow101@129.2.206.174] has quit [Remote host closed the connection] 21:44 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 21:45 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 21:48 -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev 21:52 -!- achow101 [~achow101@129.2.206.174] has joined #bitcoin-core-dev 21:57 -!- achow101 [~achow101@129.2.206.174] has quit [Ping timeout: 260 seconds] 21:58 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 22:03 < GitHub186> [bitcoin] JeremyRubin opened pull request #8650: Make tests much faster by replacing BOOST_CHECK with FAST_CHECK (master...faster_tests) https://github.com/bitcoin/bitcoin/pull/8650 22:03 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 22:10 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 258 seconds] 22:13 < gmaxwell> down with 'test frameworks'. 22:18 -!- gabridome [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has joined #bitcoin-core-dev 22:19 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 264 seconds] 22:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-kvujyybnlmiklgzv] has joined #bitcoin-core-dev 22:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:30 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:31 -!- gabridome [~gabridome@net-93-145-200-45.cust.vodafonedsl.it] has quit [Quit: gabridome] 22:45 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev 22:47 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 22:48 < jeremyrubin> gmaxwell: Hear, hear! 22:51 < GitHub124> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f061415d12ce...91990ee01dab 22:51 < GitHub124> bitcoin/master 854f1af Pieter Wuille: Make the dummy argument to getaddednodeinfo optional 22:51 < GitHub124> bitcoin/master 91990ee Wladimir J. van der Laan: Merge #8272: Make the dummy argument to getaddednodeinfo optional... 22:51 < GitHub133> [bitcoin] laanwj closed pull request #8272: Make the dummy argument to getaddednodeinfo optional (master...optionaladdnodedummy) https://github.com/bitcoin/bitcoin/pull/8272 22:52 < gmaxwell> jeremyrubin: I had someone 'testframeworkize' one of my tests in another project and it caused it to go from 45 second runtime something like an hour. 22:55 -!- jannes [~jannes@178.132.211.90] has quit [Ping timeout: 258 seconds] 23:02 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 23:03 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 23:05 -!- assder [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has joined #bitcoin-core-dev 23:15 < jeremyrubin> gross :/ 23:26 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev 23:44 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 23:52 -!- gabridome [~gabridome@109.112.75.195] has joined #bitcoin-core-dev 23:54 -!- gabridome [~gabridome@109.112.75.195] has quit [Client Quit] 23:56 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]