--- Day changed Thu Jun 30 2016 00:04 -!- harrymm [~wayne@178.162.214.49] has quit [Ping timeout: 260 seconds] 00:25 -!- harrymm [~wayne@171.5.182.196] has joined #bitcoin-core-dev 00:40 -!- harrymm [~wayne@171.5.182.196] has quit [Ping timeout: 244 seconds] 00:41 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 244 seconds] 00:55 -!- harrymm [~wayne@178.162.214.49] has joined #bitcoin-core-dev 00:55 -!- murch [~murch@p4FE38846.dip0.t-ipconnect.de] has quit [Ping timeout: 244 seconds] 01:15 -!- murch [~murch@p4FE39793.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 01:18 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.] 01:33 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection] 01:33 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 01:40 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 01:54 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:58 -!- slackircbridge1 [~slackircb@45.55.41.36] has joined #bitcoin-core-dev 02:01 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds] 02:01 -!- Michail1_ [~michail@michail.com] has joined #bitcoin-core-dev 02:01 -!- hybridsole_ [~hybridsol@unaffiliated/hybridsole] has joined #bitcoin-core-dev 02:03 -!- pmienk_ [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 02:03 -!- Amnez777- [~Amnez777@37.157.216.155] has joined #bitcoin-core-dev 02:04 -!- roasbeef_ [~root@104.131.26.124] has joined #bitcoin-core-dev 02:05 -!- aj_ [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev 02:06 -!- xiangfu [~xiangfu@58.135.95.135] has quit [Ping timeout: 276 seconds] 02:08 -!- Netsplit *.net <-> *.split quits: Amnez777, slackircbridge, wangchun, aj, roasbeef, sturles, Michail1, whphhg, luke-jr, hybridsole, (+1 more, use /NETSPLIT to show all of them) 02:08 -!- Michail1_ is now known as Michail1 02:08 -!- hybridsole_ is now known as hybridsole 02:08 -!- Netsplit over, joins: wangchun 02:08 -!- Netsplit over, joins: luke-jr 02:08 -!- paveljanik [~paveljani@14.150.broadband14.iol.cz] has joined #bitcoin-core-dev 02:08 -!- paveljanik [~paveljani@14.150.broadband14.iol.cz] has quit [Changing host] 02:08 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 02:10 -!- whphhg [whphhg@gateway/vpn/mullvad/x-lasdmhsjpgkxasgv] has joined #bitcoin-core-dev 02:11 -!- sturles [~sturles@ulrik.uio.no] has joined #bitcoin-core-dev 02:11 -!- sturles [~sturles@ulrik.uio.no] has quit [Changing host] 02:11 -!- sturles [~sturles@unaffiliated/sturles] has joined #bitcoin-core-dev 02:15 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev 02:24 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 02:28 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds] 02:32 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 260 seconds] 02:36 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev 02:37 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev 02:37 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host] 02:37 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 02:42 -!- xiangfu [~xiangfu@58.135.95.135] has joined #bitcoin-core-dev 02:56 -!- xiangfu [~xiangfu@58.135.95.135] has quit [Ping timeout: 244 seconds] 03:21 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds] 03:23 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev 03:25 -!- davec_ [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 03:29 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 276 seconds] 03:31 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 03:37 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev 03:37 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host] 03:37 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 03:41 -!- ratoder [~ratoder@static.111.19.201.138.clients.your-server.de] has quit [Ping timeout: 240 seconds] 03:41 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Ping timeout: 252 seconds] 03:41 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Ping timeout: 250 seconds] 03:49 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has joined #bitcoin-core-dev 03:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 03:55 -!- fengling [~fengling@58.135.95.133] has quit [Ping timeout: 240 seconds] 04:01 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 04:20 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Changing host] 04:20 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev 04:36 -!- pmienk_ [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 244 seconds] 04:36 -!- pmienk_ [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 04:50 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 05:15 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 05:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 05:52 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 05:56 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 246 seconds] 06:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:49 -!- murch [~murch@p4FE39793.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds] 06:49 -!- murch [~murch@p4FDB6C64.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 07:00 -!- murch1 [~murch@p4FE39268.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 07:01 -!- murch [~murch@p4FDB6C64.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds] 07:13 -!- harrymm [~wayne@178.162.214.49] has quit [Ping timeout: 272 seconds] 07:20 < GitHub96> [bitcoin] jmcorgan closed pull request #8284: Backport remaining commits for out-of-tree builds from master to 0.12 branch (0.12...build-oot-0.12) https://github.com/bitcoin/bitcoin/pull/8284 07:32 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev 07:34 -!- harrymm [~wayne@171.5.182.196] has joined #bitcoin-core-dev 07:38 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Remote host closed the connection] 07:40 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has joined #bitcoin-core-dev 07:56 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 07:58 -!- pmienk_ [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 272 seconds] 07:58 -!- harrymm [~wayne@171.5.182.196] has quit [Ping timeout: 250 seconds] 07:59 -!- cryptapus_ is now known as cryptapus 08:01 < sdaftuar> proposed topic for the meeting today: wrapping up the mining-related changes to 0.13.0 (please see #8294) 08:04 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 250 seconds] 08:06 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!] 08:07 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 08:09 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev 08:25 -!- zooko [~user@2601:281:8000:8387:5157:31b2:4a62:d545] has joined #bitcoin-core-dev 08:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 08:40 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev 08:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 08:59 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 09:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 09:09 -!- jtimon [~quassel@LAubervilliers-656-1-271-230.w193-248.abo.wanadoo.fr] has joined #bitcoin-core-dev 09:10 < jtimon> since then does AcceptToMemoryPoolWorker take a bool* pfMissingInputs parameter instead of just logging a validation error and returning false? 09:11 < jtimon> that's a consensus check, do we plan to pass bool* pfMissingInputs to libconsensus' veryfyTx too? 09:12 < sipa> since 0.1.0 09:12 < sipa> it's literally been there in every release ever 09:13 -!- davec_ [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 09:13 -!- davec_ [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 09:15 < jtimon> mhmm, somehow I remember return state.DoS(missing inputs) in https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1236 09:15 < jtimon> may have been in one of my consensus branches... 09:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:17 < jtimon> never mind, I must have dreamed it or something 09:18 < sipa> Sounds like a nice dream. 09:20 -!- jtimon [~quassel@LAubervilliers-656-1-271-230.w193-248.abo.wanadoo.fr] has quit [Remote host closed the connection] 09:22 < GitHub6> [bitcoin] sdaftuar opened pull request #8295: Mining-related fixups for 0.13.0 (master...cnb-segwit) https://github.com/bitcoin/bitcoin/pull/8295 09:27 -!- Frederic94500 [4d808e1f@gateway/web/freenode/ip.77.128.142.31] has joined #bitcoin-core-dev 09:33 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye] 09:36 -!- Lysanders [~Lysanders@unaffiliated/lysanders] has joined #bitcoin-core-dev 09:38 -!- murch1 [~murch@p4FE39268.dip0.t-ipconnect.de] has quit [Quit: Leaving.] 09:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 09:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 09:46 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 09:48 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds] 09:50 -!- harrymm [~wayne@213.152.162.84] has joined #bitcoin-core-dev 09:50 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 09:52 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 09:54 -!- harrymm [~wayne@213.152.162.84] has quit [Ping timeout: 252 seconds] 09:55 -!- bsm1175321 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection] 09:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:01 -!- dingus is now known as grubles 10:02 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 10:11 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 10:17 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 10:20 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 264 seconds] 10:25 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Remote host closed the connection] 10:32 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 10:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:39 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Ping timeout: 244 seconds] 10:44 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev 10:55 < GitHub138> [bitcoin] MarcoFalke opened pull request #8296: [qa] Make setup_chain private (master...Mf1607-qaSetupChain) https://github.com/bitcoin/bitcoin/pull/8296 10:57 -!- roasbeef_ is now known as roasbeef 11:00 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.] 11:00 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 11:04 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Remote host closed the connection] 11:09 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection] 11:11 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 11:18 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection] 11:19 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 11:20 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 11:20 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 11:21 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 11:25 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Ping timeout: 252 seconds] 11:25 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev 11:30 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Ping timeout: 260 seconds] 11:33 -!- cjcj [2e3b026a@gateway/web/freenode/ip.46.59.2.106] has quit [Ping timeout: 250 seconds] 11:38 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev 11:43 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 276 seconds] 11:45 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has joined #bitcoin-core-dev 11:47 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has left #bitcoin-core-dev [] 11:49 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 11:56 -!- jtimon [~quassel@2a01cb0407fe74008c885ec7d8adc95c.ipv6.abo.wanadoo.fr] has joined #bitcoin-core-dev 12:00 < MarcoFalke> no meeting? 12:00 < sdaftuar> i'm here! 12:00 < gmaxwell> Yes meeting. 12:01 < sipa> i ' m h e r e 12:01 < gmaxwell> #startmeeting 12:01 < lightningbot> Meeting started Thu Jun 30 19:01:10 2016 UTC. The chair is gmaxwell. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:01 < btcdrak> ping 12:01 <@wumpus> pong 12:01 -!- TheFactory7 [uid164731@gateway/web/irccloud.com/x-fforntroldkxwcpj] has joined #bitcoin-core-dev 12:01 < sipa> pang 12:01 < gmaxwell> Welcome to the meeting. Hard start today, sorry to not get pings out earlier. 12:01 < jonasschnelli> pong 12:01 <@wumpus> proposed topic for the meeting today: wrapping up the mining-related changes to 0.13.0 (please see #8294) 12:02 < gmaxwell> wumpus: jtimon: jonasschnelli: petertodd: morcos: MarcoFalke: NicolasDorier: paveljanik: 12:02 < jtimon> pong 12:02 < gmaxwell> #topic wrapping up the mining-related changes to 0.13.0 (please see #8294) 12:02 <@wumpus> also segwit 0.12 backport status, maybe 12:02 < sipa> unstarted. 12:03 < sdaftuar> so i mentioned a few things in that issue that i think we need to address for 0.13.0 12:03 < petertodd> hi 12:03 < sdaftuar> a couple should be non-controversial bugfixes 12:03 < kanzure> hi 12:03 < gmaxwell> sdaftuar: blockminsize should just go 12:03 < sdaftuar> two things i wanted feedback on were (a) removing the old mining algorithm ("addScoreTxs") and (b) -blockminsize 12:04 < sdaftuar> ok great, that's what i think too 12:04 < sipa> in favor of just dropping -blockminsize 12:04 < gmaxwell> sdaftuar: "Should we remove the old transaction selection algorithm" I'm indifferent to favoring removing code. 12:04 < gmaxwell> luke-jr: your thoughts? 12:04 <@wumpus> if the code is not used, it should be removed 12:04 < gmaxwell> (like to sdaftuar's issue: https://github.com/bitcoin/bitcoin/issues/8294 ) 12:04 < sipa> i think we shouldn't keep the old algorithm just because we're not sure if the new one works 12:05 < sipa> we can always revert code if needed 12:05 < sipa> the current reason for keeping is because when -blockminsiz or -blockmaxsize are -blockprioritysize are given, the new algorithm does not work (due to missing accounting) 12:05 < sipa> if we fix the accounting, and make the new algorithm support those parameters, the old algorithm can go 12:05 < sdaftuar> sipa: right, and that is addressed in the first commit of #8295 12:05 < gmaxwell> the only gain I see is if there is some stupidity in the new one the old one is a switch away... but the new one has a reasonable amount of testing and if it has some issue it seems unlikely that its so major that just fixing it wouldn't be the prefered solution. 12:06 < sipa> ok, grea;t i haven't looked 12:06 < jtimon> I don't remember addScoreTx, but ack on removing blockminsize 12:06 <@wumpus> it's a bit late in the release to be removing arguments, on the other hand it was already not working so let's do it... 12:07 <@wumpus> as long as it's documented in the release notes 12:07 < gmaxwell> it should be removed but not cause the daemon to fail to start if specified. 12:07 < sdaftuar> wumpus: agree, the release notes need a bunch of writeup for all the mining changes 12:07 <@wumpus> or e.g. emit a warning/error if it is provided 12:07 < sipa> i am perfectly fine with just making -blockminsize work for 0.13 with CPFP, and removing it in 0.14 12:07 < sipa> sdaftuar: unless you think that would be much more work (i think it would be deleting 2 lines to stop supporting it) 12:08 <@wumpus> sounds like that would be a waste of work, if it is going to be removed anyway, but I don't know how much work it is 12:08 < sdaftuar> sipa: it'd be adding code to support it. i think it's probably easy, but i haven't thought carefully about it. probably a one line change. 12:08 < sipa> i expect it to be trivial to make it work, and also trivial to remove 12:08 <@wumpus> if it's trivial to make it work, let's go for that 12:08 < sipa> also, i think it's utterly pointless in the current mining encironment 12:08 < sdaftuar> sipa: agreed. 12:09 < jtimon> emit warning seems a good option 12:09 < gmaxwell> I think it's a goofy option. 12:09 <@wumpus> if it's not trivial, or annoying to test, let's get rid of it 12:09 < gmaxwell> less options good. 12:09 < sipa> ack, we could just test for its value, and fail at startup if a nonzero value is passed 12:09 < sdaftuar> we have no tests for it now, i believe. 12:09 < sipa> it has no tests 12:09 < sipa> pretty sure 12:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 12:09 < sdaftuar> my preference would be to get rid of it, rather than add a test to make sure it works. 12:10 < sipa> sdaftuar: will review your patch 12:10 <@wumpus> right, that's fine 12:10 -!- Bootvis [bob@baltar.lan.endoria.net] has joined #bitcoin-core-dev 12:10 < jtimon> gmaxwell: why you don't want it to fail if the argument is provided ? 12:11 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon luke-jr cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier 12:11 < gmaxwell> (sorry, just creating a ping macro for future use) 12:11 < michagogo> Oh 12:11 < michagogo> Hi 12:11 < sdaftuar> jtimon: my preference for not causing failure is that that would be extra code to write/test/review. silent failure seems easier, and harmless in this situation. 12:11 < gmaxwell> jtimon: because it's a mostly meaningless setting that some people are going to have by virtue of copy and pasting things. 12:11 < sipa> meh, ok 12:11 < kanzure> i nominate jtimon for double inclusion in the ping, but otherwise ACK 12:12 <@wumpus> I don't really like ignoring options, that can be really frustrating 12:12 <@wumpus> 'wtf doesn't this work', oh, then after an hour of debugging you notice that the functionality has been removed 12:12 < sipa> agree 12:12 < sdaftuar> wumpus: in this case though, you wouldn't have been noticing the old behavior "working" 12:12 <@wumpus> at least add a warning, I don't care about failing 12:12 < jtimon> I'm fine with either failing or giving a warning 12:12 < sdaftuar> i can add a warning, sure. 12:12 < sipa> let's discuss this when the actual PR is created 12:13 < jtimon> fair enough 12:13 < sdaftuar> i included removal of -blockminsize in 8295 12:13 < sdaftuar> i can fix to warn if the argument is given 12:13 <@wumpus> great 12:13 < gmaxwell> okay warning fine. 12:14 < sdaftuar> one thing i wanted to mention, if we do decide to remove addScoreTxs(), we could also remove the mining_score from the mempool multiindex 12:14 < gmaxwell> wumpus: I agree in principle except for the fact that a LOT of people have copied the "example config" from the bitcoin wiki and are setting all kinds of crazy things. :) 12:14 < sdaftuar> i didn't incldue that in 8295, but wanted to mention it in case we want to remove for 0.13 12:14 < sdaftuar> it would give us a small memory savings in the mempool, but not sure if that's a change that we'd rather wait for 0.14 tomake 12:14 < sdaftuar> i don't have a preference 12:14 < sipa> ENOCARE 12:15 < jtimon> sdaftuar: can't https://github.com/bitcoin/bitcoin/pull/8295/commits/27362dda4d583a43ebf687ae097d2f45ba1c4c32 be a trivial to review separate PR ? 12:15 <@wumpus> gmaxwell: yes, indeed, it's an option that's bound to be misinterpreted/misused anyway 12:15 < gmaxwell> 12:15 < sdaftuar> jtimon: it builds on removing addScoreTxs i think? 12:15 < jtimon> sdaftuar: oh, I see 12:15 < sdaftuar> jtimon: but yes i could have split those two commits out 12:15 < jtimon> mhmm 12:16 < gmaxwell> Okay, anything more on this that needs to happen in the meeting? 12:16 < jtimon> whatever, minor point, I just don't think I can ack the pr like that because I haven't been following some of the refactors in miner much 12:17 < sdaftuar> i think we can move on, thanks 12:17 < jtimon> well, refactors and changes 12:17 <@wumpus> sdaftuar: I'd say if they are after your changes remove the mempool fields, it's not much of a risk, if everything is alright the compiler checks that nothing is referring to it 12:17 < sdaftuar> wumpus: ok great, thanks 12:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:18 < sdaftuar> i'll defer that until after 8295 is merged anyway 12:18 <@wumpus> right, it's not a priority 12:18 < sdaftuar> yep 12:18 <@wumpus> any other topics for today? 12:18 < CodeShark> hmm 12:19 < petertodd> anyone get a chnace to look at https://github.com/bitcoin/bitcoin/issues/8279 ? at a conf right now 12:19 < sipa> petertodd: yes, i think it is a good point 12:19 < petertodd> sipa: cool, thanks 12:19 < sdaftuar> sipa: you noticed a related issue as well, right? 12:19 < petertodd> sipa: (mainly wanted to know if I needed to post a retraction!) 12:20 < sipa> sdaftuar: the sigops counting? i believe that is not vulnerable to mauling (the verb related to 'malleability', apparently) 12:20 < sipa> (also not found by me) 12:20 < gmaxwell> #topic segwit 12:21 < sdaftuar> sipa: it is, because we don't verify that the witness script matches the commitment in the pubkey output 12:21 < sdaftuar> right? 12:21 < petertodd> sdaftuar: no, I think we do that prior to sigops checking 12:21 < sdaftuar> i'll take another look. pretty sure sipa and i discussed and concluded that we didn't. 12:21 < sipa> sdaftuar: something to look into 12:22 < petertodd> sdaftuar: yeah, wouldn't hurt to take another look - that review was a bunch of owrk and I may have been a bit faded by the end :) 12:22 < sipa> i don't think these are serious problems (it allows preventing a node from getting a transaction, but there are other means for that, like announcing it and not responding) 12:22 < sdaftuar> petertodd: i'm specifically referring to the sigopcount checks in accepttomemorypool, not consensus level checking 12:22 < sipa> but they should be understood 12:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 12:23 < petertodd> sdaftuar: yeah, I _thought_ I looked at that, but may have missed it - mempool was the last thing I looked at 12:23 < sipa> petertodd: i'm really glad you did that review, by the way - the writeup makes a lot of things more communicatable 12:24 < petertodd> sipa: thanks! yeah, mainly wanted to demystify the process of doing review 12:24 < gmaxwell> I don't think its of major importance, but "Bitcoin XT" recently started making only outbound connections to other XT nodes. In combination with segwit, I believe this will partition them. Because they are such a small number of nodes I don't think it warrents much attention, but something to be aware of. 12:24 -!- laurentmt [~Thunderbi@LCaen-656-1-123-117.w80-13.abo.wanadoo.fr] has joined #bitcoin-core-dev 12:25 < gmaxwell> petertodd: yea, nice work. 12:25 < sdaftuar> gmaxwell: we have a little time before that will happen, as we haven't yet activated the preferential peering yet 12:25 < gmaxwell> sdaftuar: indeed. 12:26 < petertodd> gmaxwell: ... 12:26 < sipa> segwit by the way does not _only_ make outbound connections to segwit 12:26 < sipa> but it strongly prefers them 12:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:27 < petertodd> sipa: yeah, I noticed that - after 40 tries you connect to non-segwit outgoing 12:27 < gmaxwell> sipa: right, I think that would be sufficient to partition there. 12:27 < sipa> petertodd: yes, totally arbitrary number 12:28 < jl2012> gmaxwell: they should fix that. We just need to let them know 12:28 < petertodd> wouln't be a crazy idea to have a mode that disabled the DoS banning for incoming nodes btw... 12:28 < sipa> petertodd: DoS banning, or also DoS disconnection? 12:28 < gmaxwell> petertodd: one can set that threshold arbritarily high at least. 12:28 < petertodd> sipa: both, to be able to (at least temproarily) work around bugs related to DoS banning 12:29 < petertodd> sipa: equally, have a small subset of nodes that can be set to ignore the DoS banning 12:29 < gmaxwell> Patch accepted to make low-dos-score a ranking criteria in eviction protection logic, which would also make running with a very high dos threshold more reasonable. 12:29 < petertodd> gmaxwell: good idea 12:30 < gmaxwell> jl2012: I was just made aware of it, but sure. 12:31 < gmaxwell> my past expirence with that project has not been very good. 12:31 <@wumpus> so a different ban thrshold for incoming versus outgoing connections? 12:31 < petertodd> jl2012: there's a issue open in the XT repo for it already 12:31 < btcdrak> jl2012: there is a ticket open already 12:31 < gmaxwell> petertodd: we should probably just brainstorm some about connection management stuff, there are a number of neat improvements we can make. 12:32 < sipa> if we're thinking about such refactors, the DoS score should probably also attenuate over time 12:32 < petertodd> wumpus: I think the main thing, is just to have different thresholds period for some nodes, so that while you won't wast bandwidth on everyone, keep a few peers connected regardless in case you're dealing with a DoS-related bug and should be distributing the data anyway 12:32 < sipa> otherwise longer-lived connections will accumulate a score they don't deserve 12:32 <@wumpus> petertodd: so a sort of halfway-whitelisting 12:32 < petertodd> wumpus: also, along those lines, distributing invalid blocks with valid PoW isn't a crazy idea 12:32 < petertodd> wumpus: yup 12:32 < gmaxwell> petertodd: such a thing could also turn those peers into blocksonly. 12:32 < gmaxwell> since thats all we care about for anti-partitioning. 12:32 < petertodd> gmaxwell: yeah, that's a good idea 12:33 < gmaxwell> and yet it almost completely eliminates dos concerns. 12:33 -!- laurentmt [~Thunderbi@LCaen-656-1-123-117.w80-13.abo.wanadoo.fr] has quit [Quit: laurentmt] 12:34 < petertodd> blocksonly on-DoS + relaying of invalid blocks w/ valid PoW in a separate "may be invalid" message would satisfy everything I think 12:34 <@wumpus> sipa: attentuating theDoS score over time makes sense, a very slow DoS attack isn't really a DoS attack (apart from keeping a connection slot open, but that's not what the score is to protect against) 12:35 < sipa> theDos? sister of GLaDoS? 12:35 < petertodd> sipa: lol 12:35 < btcdrak> omg 12:36 <@wumpus> then again it's not really a anti-DoS score is it, it won't get triggered on accidental over-use of resources, more a misbehavior score 12:36 <@wumpus> hehe 12:36 < sipa> yes, i think there may be reasons to introduce something like a "resource usage score" which is distinct from "misbehaviour" 12:36 <@wumpus> the cake is a lie 12:36 < sipa> and which gets used to decide which peers to disconnect in favor of others 12:36 < sipa> but never causes a ban 12:37 <@wumpus> yes, indeed 12:37 < sipa> not a disconnection, unless there is a pressing reason to disconnect someone anyway 12:37 < petertodd> wumpus: might not be a bad idea to go through the DoS stuff and remove bans in cases where the misbehavior doesn't take much cpu time to detect (and then use it in the anti-partitioning score instead) 12:37 < gmaxwell> yea, I think there is a lot we can do here. 12:38 < gmaxwell> So-- the issue of dbcache that I brought up last week can we talk about that for a bit? 12:38 < sipa> ack topic 12:38 <@wumpus> sure 12:38 < gmaxwell> #topic dbcache 12:38 <@wumpus> petertodd: agreed 12:38 < gmaxwell> Last week I brought up that reindex with defaults was SUPER slow on my laptop, been a while since I'd reindexed with default dbcache. 12:39 < gmaxwell> This resulted in more benchmarking, and wumpus has a PR to increase the default dbcache to 300mb and also clamp the leveldb cache usage (so that it doesn't go gigantic as dbcache increases) 12:39 <@wumpus> the pull request to bump default dbcache to 300MiB is ready: https://github.com/bitcoin/bitcoin/pull/8273 12:39 < gmaxwell> I did testing to confirm that the leveldb cache sizes don't have much effect. 12:39 < gmaxwell> they seem like they have more effect with txindex enabled, however. 12:40 * jonasschnelli will test 8273 12:40 <@wumpus> which makes sense, txindex has a completely different access pattern than the utxo set 12:40 <@wumpus> it's almost write-only 12:40 < sipa> morcos: no more work on #6936? 12:40 < gmaxwell> As a related aside txindex performance is fairly slow, makes an 'infinite' dbcache reindex by about 25%. 12:40 <@wumpus> so we could cap that at a different value 12:41 < sipa> txindex adds many many more writes 12:41 < gmaxwell> wumpus: yes, ran a test with 32mb which has finished but I didn't have time before the meeting to collect the results, will shortly after. 12:41 < sipa> though they should be configured to bypass all caches 12:41 <@wumpus> yes txindex is very slow, just a lot of data 12:41 < gmaxwell> my testing is on a fast spinning disk system, which I think is probaby the right thing to test for on this. 12:42 < sdaftuar> sipa: oh, morcos and i were just talking about whether there were things we were working on that used the mining score index, but i think we had both forgotten about #6936. 12:42 <@wumpus> even the idea of indexing every transaction on the block chain is crazy 12:42 < jonasschnelli> My last tests showd me that a reindex (master) was twice as long as a a normal IDB (from rnd peers) from the scratch... 12:42 <@wumpus> there's much slower implementations possible though, like stashing everything into mysql :-) 12:42 < sipa> jonasschnelli: wut?! 12:42 < gmaxwell> One result of my testing is showing that even the 300MB dbcache is really not big enough to give good reindex performance. We should consider something for 0.14 to give mempool memory to dbcache during ibd/reindex or something. 12:43 < gmaxwell> jonasschnelli: that last test was before the signature checking fix? 12:43 < jonasschnelli> sipa: 5.5h reindex against ~3h IBD 12:43 <@wumpus> jonasschnelli: whoa 12:43 < jonasschnelli> I'm redoing it now... 12:43 < gmaxwell> jonasschnelli: when was it? 12:43 < sipa> jonasschnelli: what part of that was real reindex, and what was chainstate rebuilding? 12:43 <@wumpus> I thought we solved that recently 12:43 < jonasschnelli> a couple of weeks ago after sipas work 12:43 < jonasschnelli> sipa: just a plain -reindex 12:43 < jonasschnelli> wth dbcache=8000 12:44 < sipa> that's painful 12:44 < gmaxwell> Reindex now has that header scan, it adds about 20 minutes on my test hosts that a sync wouldn't have. 12:44 < sipa> jonasschnelli: can you benchmark -reindex-chainstate vs IBD? 12:44 <@wumpus> that can't make the difference between 3h and 5.5h though 12:44 < gmaxwell> but I tested with and without signature checking, and in both cases reindex in master is faster than 0.12.1. 12:44 < jonasschnelli> sipa: okay. Will do. 12:44 <@wumpus> 20 minutes difference would be ok 12:45 < sipa> it may depend on your disk 12:45 < gmaxwell> I didn't test an IBD but I can easily do that. We do probably lose some time due to out of order blocks. 12:45 < jonasschnelli> Also there is the potential_deadlock_detected that stops my node (-debug) every couple of minutes.. 12:45 < sipa> if it's a VM with a file-backed storage which is on a network filesystem stored on an encrypted ZFS container... 12:46 < sipa> jonasschnelli: i hope your normal benchmarks are not with -debug builds 12:46 <@wumpus> lock debugging slows down the sync too 12:46 < sipa> additionally, we need to fix that bug 12:46 < sipa> i'll look into that lockorder 12:46 <@wumpus> but yes, the deadlock detected in the network code seems to be a real deadlock 12:46 < jonasschnelli> wumpus: yes. Agree. But i have compare -debug IBD against -debug reindex 12:47 < sipa> jonasschnelli: meh, don't do that 12:47 < sipa> debug is not ever going to give you a realistic benchmark 12:47 < jonasschnelli> developer are supposed to run --enable-debug software! :) 12:47 <@wumpus> do we have an issue open for that deadlock issue btw? 12:47 < sipa> jonasschnelli: yes, but not for benchmarking 12:47 < gmaxwell> #topic net deadlock 12:47 < jonasschnelli> wumpus: no. Let me open one. 12:47 < sipa> jonasschnelli: thanks 12:48 < jonasschnelli> sipa: Yes. Agree... will benchmark again without -debug 12:48 < sipa> jonasschnelli: please list your exact commit (so we can identify the line numbers) 12:48 < jonasschnelli> okay. Good point. 12:49 < gmaxwell> #action jonasschnelli to open issue on lockorder deadlock report that he's seeing 12:49 < gmaxwell> Any other topics? 12:50 < gmaxwell> okay Seems quiet, perhaps we can end a bit early. 12:50 < sdaftuar> maybe bip152? 12:50 <@wumpus> seemingly not :) 12:50 < gmaxwell> ah okay! 12:50 < sdaftuar> not sure if that's worht bringing up here 12:50 < gmaxwell> #topic BIP152 12:50 < gmaxwell> So sipa has SW BIP 152 working on testnet and a number of people testing it. 12:51 <@wumpus> good to hear 12:51 < petertodd> gmaxwell: as in, segwit bip152 right? +1 12:51 < btcdrak> I dont recall seeing a PR for that yet? 12:51 < gmaxwell> petertodd: yes. 12:51 <@wumpus> there's no PR for that 12:51 < sipa> btcdrak: intentionally not 12:52 < sipa> 1) this allows us to test interaction between non-SW-BIP152 testnet and changed 12:52 < sipa> 2) needs some BIP changes (in BIP144, BIP152, or a separate bip entirely) 12:52 < petertodd> sipa: +1 12:52 < sipa> 3) not necessary before the segwit softfork 12:53 < sipa> branch: github.com/sipa/bitcoin/commits/segwitcb 12:53 <@wumpus> not necessary, but would be good to have it before the activation, otherwise CB will suddenly disable 12:53 < sipa> indeed; it is necessary imho before activation in mastdr 12:54 < gmaxwell> Thats my view. 12:54 <@wumpus> right, for 0.12 it makes no different, there's no cb there anyhow 12:54 < gmaxwell> jinx 12:55 < sipa> agree 12:55 -!- zooko [~user@2601:281:8000:8387:5157:31b2:4a62:d545] has quit [Ping timeout: 250 seconds] 12:55 < gmaxwell> In any case, it's working, didn't require anything too complicated. (says the guy who didn't write it) 12:56 < sdaftuar> sipa, gmaxwell: i still think it'd be better if the information in a blocktxn message could be understood without any state. did i make any progress trying to convince you? 12:56 <@wumpus> there's no need to hurry it anyhow, CB and segwit separately are already huge changes, better to test them in isolation for now 12:56 < gmaxwell> sdaftuar: only a very small amount. 12:57 < sipa> sdaftuar: no strong opinion yet 12:57 < gmaxwell> sdaftuar: we can talk more post meeting. 12:57 < sdaftuar> sure 12:58 < gmaxwell> okay, Anything else, we're almost out of time? :) 12:58 < petertodd> ack endmeeting 12:58 < gmaxwell> #endmeeting 12:58 < lightningbot> Meeting ended Thu Jun 30 19:58:51 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:58 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-30-19.01.html 12:58 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-30-19.01.txt 12:58 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-06-30-19.01.log.html 12:58 < gmaxwell> Hurrah we ended early. 12:59 < gmaxwell> :P 12:59 < jonasschnelli> 1min! :) 12:59 < gmaxwell> May your usage of the remaining minute be productive. 12:59 < petertodd> heh, my clock must be off... :) 12:59 < petertodd> brb, gonna fix ntp :) 13:00 < sipa> doh, too late 13:01 < gmaxwell> sdaftuar: So; I'm still trying to come up with a case where the offsets would be useful where were are not already keeping an equiivlent amount of state. There are DOS reasons why we can't, say, loadbalance getblocktxn fragments to all peers that have inved. But even if we have, keeping a list of indexes per peer is negligible additional state. 13:02 < sdaftuar> sipa: btw morcos was away from his desk, but says he can look at the coins cache stuff again after 0.13 is branched off 13:02 < sipa> sdaftuar: sounds good 13:02 < sdaftuar> gmaxwell: basically you'd be tracking your last getblocktxn request to each peer 13:03 -!- Frederic94500 [4d808e1f@gateway/web/freenode/ip.77.128.142.31] has quit [Quit: Page closed] 13:03 < sdaftuar> i agree you could do something like that, but this is also complicated, as you'd have to ensure you don't have more than one in-flight 13:04 < gmaxwell> right, effectively the same information the peer would send back over the wire, you'd keep in memory. You can have more than one in-flight per peer but not more than one for a given block. 13:04 < sdaftuar> i guess my point is that it's a trivial amount of bandwidth use in order to do less bookkeeping in code 13:04 < gmaxwell> But at the same time we could probably even DOS a peer that getblocktxned the same block multiple times. (and we should perhaps consider doing that) 13:05 < sdaftuar> i think that's a bit too aggressive -- there are legitimate reasons you could do that i think 13:05 < sdaftuar> ie if block reconstruction failed in an unexpected place 13:05 < gmaxwell> it's maybe 0.4% overhead 13:05 < sdaftuar> but you got insight from another peer 13:06 < sdaftuar> i just don't want to overly limit what we can do with the p2p messages we're adding 13:07 < sdaftuar> .4% is probably an upperbound on the overhead 13:07 < gmaxwell> yes. 13:08 < gmaxwell> sdaftuar: I agree on not limiting the usefulness but I really am just trying to get a case where I agree that it's actually helpful beyond reducing the state size slightly in an already stateful exchange. 13:09 < gmaxwell> Because there is a cost-- the admitably trivial overhead, and the extra error conditions to test for. 13:09 < sdaftuar> yeah, it'd be more useful if i had an implementation of something that used it that i could point to, which i sadly don't 13:09 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.] 13:09 < gmaxwell> I had a couple ideas, but then found that they didn't actually work. :) 13:10 < sdaftuar> my intuition is that messages which can be interpreted on their own is more helpful for writing code. this isn't super relevant for bitcoind, but imagine how much better it would be to look at historical data that can stand on its own, versus require state 13:10 < sdaftuar> or writing tests that do strange things 13:11 < gmaxwell> hah but thats part of my point: it adds more corner cases that need to be tested. E.g. what happens when the indexes weren't what you asked for but were correct, what happens if the txn are what you asked for but the indexes are correct? 13:11 * gmaxwell steps out for lunch and to ruminate. 13:11 * sdaftuar has to leave to catch a train anyway, will think about it some more 13:16 < midnightmagic> hrm.. I like meetbot. 13:17 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 13:17 < morcos> sipa: yes i'm happy to take another pass at keeping the cache warm. but whats your current state of thinking with keeping the utxos by txid instead of by individual utxo? we had discussed at one point changing that? 13:18 < sipa> i think we should switch to individual utxo 13:18 < sipa> but it's a pretty nontrivial change 13:18 < morcos> yeah... 13:18 < morcos> i wonder what the current overhead is 13:18 < sipa> the one pain point is storage of per-tx information (height and coinbaseness) 13:19 < sipa> and nversion 13:19 < sipa> copied into each utxo, or still have some per txid state 13:21 < morcos> yeah maybe there is some hybrid that makes the most sense.. anyway, ok, just food for thought 13:22 < sipa> in the storage format that means refcounting per txid, though 13:23 < sipa> yuckness 13:23 < sipa> or a read after write to see if any entries remain, and if not, delete the txid data 13:24 < morcos> yeah, i was thinking more the latter, we kind of already do that right? 13:24 < morcos> at the disk level for pruning 13:24 < morcos> ugh sorry, bad choice of words, but think its called that in the code 13:26 < morcos> maybe you could keep a bit field of the spentness of various vout#s in the txid level state, so when its in memory, you know whether any uncached vout#s are still unspent. 13:44 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 13:53 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.] 13:55 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev 14:18 -!- zooko [~user@2601:281:8000:8387:5157:31b2:4a62:d545] has joined #bitcoin-core-dev 14:20 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 14:28 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has joined #bitcoin-core-dev 14:29 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has quit [Client Quit] 14:30 < gmaxwell> own't the key overhead make the dataset much larger? whats the average outputs per key in the database today? 14:32 -!- Amnez777 [~Amnez777@37.157.216.155] has joined #bitcoin-core-dev 14:33 -!- Amnez777- [~Amnez777@37.157.216.155] has quit [Ping timeout: 244 seconds] 14:36 -!- jtimon [~quassel@2a01cb0407fe74008c885ec7d8adc95c.ipv6.abo.wanadoo.fr] has quit [Ping timeout: 260 seconds] 14:37 < luke-jr> I don't see why the new algorithm can't work with blockmaxsize etc? 14:37 < gmaxwell> because it will produce wrong results if blockmaxsize is the limited commodity. 14:38 < gmaxwell> wrong in the sense of not picking the optimal block subject to that constraint. 14:41 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has joined #bitcoin-core-dev 14:45 -!- Netsplit *.net <-> *.split quits: face, Taek, bsm1175321 14:47 < zooko> Hey Bitcoin core devs. Over in the Zcash project we occasionally do things which might be independently useful to Bitcoin core. 14:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 14:48 < zooko> One of those is a performance measurement of a transaction with the maximal number of inputs. 14:48 < zooko> We're currently talking about that test/measurement over in #zcash and Nathan mentioned that it might be of use to core. 14:56 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev 14:59 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has quit [Ping timeout: 252 seconds] 15:01 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has joined #bitcoin-core-dev 15:02 < luke-jr> gmaxwell: if we're hoping to see that constraint unnecessary in the next year, I don't think we need it to be "ideal"; but if sdaftuar wants to support it better, that's fine with me too 15:02 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [Ping timeout: 260 seconds] 15:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 15:05 < gmaxwell> I think its fine if its not ideal. given the current climate we can expect people to just turn it as high as possible in any case. 15:06 < gmaxwell> just as they're doing with the current target. 15:08 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 15:09 -!- BCBot [~BCBot@46.101.246.115] has quit [Remote host closed the connection] 15:09 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 15:12 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 244 seconds] 15:12 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 276 seconds] 15:13 < dgenr8> regarding gmaxwell statement on XT above https://github.com/bitcoinxt/bitcoinxt/issues/153#issuecomment-229793755 15:19 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds] 15:20 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev 15:20 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host] 15:20 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 15:22 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 15:22 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 276 seconds] 15:30 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:31 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev 15:31 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has quit [Remote host closed the connection] 15:33 < gmaxwell> dgenr8: your intended behavior will partition the network and leave XT isolated. 15:34 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev 15:35 < gmaxwell> as your only connections from core nodes will be inbound and after segwit activates core will avoid making outbound connections to non-segwit enabled hosts; already that behavior is dangerous because there are relatively few hosts that it is willing to outbound connect to, making chance partitioning and vulnerability to sybil attacks worse. 15:36 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has quit [Remote host closed the connection] 15:37 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev 15:37 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 15:37 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has quit [Remote host closed the connection] 15:41 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 15:41 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev 15:43 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has quit [Remote host closed the connection] 15:43 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev 15:45 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has quit [Remote host closed the connection] 15:45 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev 15:46 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has quit [Quit: Ex-Chat] 15:46 -!- Prattler [~ttttt@78-60-12-33.static.zebra.lt] has joined #bitcoin-core-dev 15:46 -!- BCBot_ [~BCBot@141.94.62.81.dynamic.wline.res.cust.swisscom.ch] has quit [Remote host closed the connection] 15:49 -!- Amnez777 [~Amnez777@37.157.216.155] has quit [Ping timeout: 244 seconds] 15:49 -!- BCBot [~BCBot@46.101.246.115] has quit [Remote host closed the connection] 15:50 -!- justanother|NYY is now known as justanotheruser 15:51 < sipa> gmaxwell: that's not the reason. the algorithm needs per-package byte sizes, which are not counted currently 15:51 < sipa> gmaxwell: it's not just that it's suboptinal 15:51 < sipa> without adding package-accounted sizes, it just cannot work 15:51 -!- Amnez777 [~Amnez777@37.157.216.155] has joined #bitcoin-core-dev 15:51 < gmaxwell> sipa: hm why doesn't it just construct assuming that there is no size limit then truncate when the block is full. 15:51 < gmaxwell> [pp.getblock(pp.getblockhash(x))['size'] for x in range(353213,417725)] ... man rpc from python is slow, thats running at 9 blocks per second and is going to take two hours to finish. --- Log closed Thu Jun 30 16:00:49 2016 --- Log opened Thu Jun 30 16:31:57 2016 16:31 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #bitcoin-core-dev 16:31 -!- Irssi: #bitcoin-core-dev: Total of 144 nicks [1 ops, 0 halfops, 0 voices, 143 normal] 16:37 -!- ybit [~ybit@unaffiliated/ybit] has quit [Ping timeout: 250 seconds] --- Log closed Thu Jun 30 16:42:16 2016 --- Log opened Thu Jun 30 16:42:50 2016 16:42 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #bitcoin-core-dev 16:42 -!- Irssi: #bitcoin-core-dev: Total of 144 nicks [1 ops, 0 halfops, 0 voices, 143 normal] 16:43 < sdaftuar> sipa: gmaxwell: i think the fix is straightforward, please see https://github.com/bitcoin/bitcoin/pull/8295/commits/f15c2cde455174c7c899833fd5792460ed49a472 16:43 < sdaftuar> i guess i didn't test it very well though! 16:43 < sdaftuar> oops, i should go back and do that more carefully 16:43 < sdaftuar> also, that silly function name gets improved in the next commit of the PR, which adds witness checking as well. 16:43 < sdaftuar> #8295 16:44 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.] 16:44 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 16:44 -!- ybit [~ybit@unaffiliated/ybit] has quit [Ping timeout: 276 seconds] 16:45 -!- ybit [~ybit@unaffiliated/ybit] has joined #bitcoin-core-dev --- Log closed Thu Jun 30 16:50:53 2016 --- Log opened Thu Jun 30 16:51:51 2016 16:51 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #bitcoin-core-dev 16:51 -!- Irssi: #bitcoin-core-dev: Total of 143 nicks [1 ops, 0 halfops, 0 voices, 142 normal] 16:52 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev 16:52 -!- ybit [~ybit@unaffiliated/ybit] has joined #bitcoin-core-dev 16:55 -!- zooko [~user@2601:281:8000:8387:5157:31b2:4a62:d545] has quit [Ping timeout: 250 seconds] 17:01 -!- ybit [~ybit@unaffiliated/ybit] has quit [Ping timeout: 260 seconds] 17:01 -!- ybit [~ybit@unaffiliated/ybit] has joined #bitcoin-core-dev 17:05 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has joined #bitcoin-core-dev 17:05 -!- cryptapus_afk is now known as cryptapus 17:05 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 17:06 -!- Retric [~Retric@ppp118-208-195-193.lns20.hba1.internode.on.net] has joined #bitcoin-core-dev 17:08 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 17:13 -!- Irssi: Join to #bitcoin-core-dev was synced in 1345 secs 17:18 < sdaftuar> oddly, travis doesn't appear to have run #8295 17:18 -!- cryptapus is now known as cryptapus_afk 17:38 -!- frankenmint [~frankenmi@174-25-9-165.ptld.qwest.net] has quit [] 17:43 -!- TheFactory7 [uid164731@gateway/web/irccloud.com/x-fforntroldkxwcpj] has quit [Quit: Connection closed for inactivity] 17:51 -!- zooko [~user@2601:281:8000:8387:5157:31b2:4a62:d545] has joined #bitcoin-core-dev 17:55 -!- fengling [~fengling@58.135.95.133] has joined #bitcoin-core-dev 17:58 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev 18:02 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Remote host closed the connection] 18:03 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 276 seconds] 18:12 -!- xiangfu [~xiangfu@58.135.95.135] has joined #bitcoin-core-dev 18:32 -!- face [~face@mail.hmel.org] has joined #bitcoin-core-dev 18:35 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hnvatvcgrfuscujh] has quit [Quit: Connection closed for inactivity] 18:36 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 18:36 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 18:36 -!- Taek [~quassel@ks36119.kimsufi.com] has joined #bitcoin-core-dev 18:38 < luke-jr> fwiw, there appears to be no changes affecting bitcoin-cli between 0.12.0 and 0.12.1 18:40 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 18:53 -!- cryptapus_afk is now known as cryptapus 18:55 -!- cryptapus is now known as cryptapus_afk 19:08 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Quit: leaving] 19:09 -!- wangchun [~wangchun@106.187.94.193] has joined #bitcoin-core-dev 19:15 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 19:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 19:20 -!- adiabat [~tx@159.203.193.74] has joined #bitcoin-core-dev 19:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 20:30 -!- adiabat [~tx@159.203.193.74] has left #bitcoin-core-dev [] 20:49 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev 20:54 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 276 seconds] 20:57 -!- fengling [~fengling@58.135.95.133] has quit [Read error: No route to host] 21:14 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 240 seconds] 21:19 -!- afk11 [~afk11@109.255.154.81] has joined #bitcoin-core-dev 21:19 -!- afk11 [~afk11@109.255.154.81] has quit [Changing host] 21:19 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev 21:52 -!- Guest27612 [~chatzilla@71-95-217-105.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev 21:52 -!- Guest27612 is now known as roidster 21:59 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 250 seconds] 21:59 < gmaxwell> Can anyone think of why we'd get a "CommitTransaction(): Error: Transaction not valid" on a new transaction being created that paid twice the nodes minrelay fee, ... and then managed to broadcast when the rebroadcast ran? 21:59 < gmaxwell> it looks like it was spending an unconfirmed input. 22:10 < gmaxwell> okay I think the issue was he managed to make a 25 deep unconfirmed chain, and got the last txn in it rejected. 22:10 < gmaxwell> Doesn't look like the wallet handles that well. 22:13 < gmaxwell> I think we should avoid using coins that are at the unconfirmed limit maximum unless not otherwise possible. 22:13 < gmaxwell> Also ooRBF to sendmany would have eliminated 25 transactions here. 22:20 -!- zooko [~user@2601:281:8000:8387:5157:31b2:4a62:d545] has quit [Ping timeout: 250 seconds] 22:26 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 22:41 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-lmtosqfecaezoaiz] has joined #bitcoin-core-dev 23:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 23:38 -!- Inaltoas1nistra [~jonathan@88.147.121.77] has joined #bitcoin-core-dev 23:40 -!- Inaltoasinistra [~jonathan@88-149-226-189.v4.ngi.it] has quit [Ping timeout: 250 seconds] 23:48 -!- roidster [~chatzilla@71-95-217-105.static.mtpk.ca.charter.com] has quit [Quit: ChatZilla 0.9.92 [SeaMonkey 2.39/20151103191810]]