--- Day changed Thu Dec 15 2016
00:11 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
00:20 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:27 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Read error: Connection reset by peer]     
00:29 -!- snowden69 [~ed@193.134.219.70] has quit [Read error: Connection reset by peer]     
00:29 -!- snowden69 [~ed@193.134.219.70] has joined #bitcoin-core-dev     
00:34 -!- wvr [~wvr@0.red-88-15-41.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
00:40 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 258 seconds]     
00:45 -!- LeMiner [~LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev     
01:12 -!- Alina-malina [~Alina-mal@37.157.216.188] has joined #bitcoin-core-dev     
01:14 -!- laurentmt [~Thunderbi@80.215.210.28] has joined #bitcoin-core-dev     
01:14 -!- laurentmt [~Thunderbi@80.215.210.28] has quit [Client Quit]     
01:15 -!- Alina-malina [~Alina-mal@37.157.216.188] has quit [Changing host]     
01:15 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev     
01:24 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Ping timeout: 260 seconds]     
01:25 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-cmdnkqjweucnuike] has joined #bitcoin-core-dev     
01:37 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:80ba:b743:538a:b5ae] has quit [Quit: .]     
01:38 -!- abpa [~abpa@107-131-125-191.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
01:46 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev     
01:51 < gmaxwell> I triggered some kind of hang or deadlock today on master by running bitcoin-cli stop shortly after starting bitcoind but before it had come up.  Was in a rush to fix something else so I didn't attach a debugger before killing it.   Mentioning so that if someone else encounteres it, you're not imagining it.
01:51 < gmaxwell> will try to reproduce tomorrow.
01:52 -!- PaulCapestany [~PaulCapes@2604:5500:17:2ea:e531:2902:9583:e521] has joined #bitcoin-core-dev     
02:05 < gmaxwell> [OT] I was really impressed by the technical accuracy of today's SMBC, then I saw it had a co-author.
02:09 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Read error: Connection reset by peer]     
02:17 -!- Cory [~Cory@unaffiliated/cory] has joined #bitcoin-core-dev     
02:19 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has joined #bitcoin-core-dev     
02:34 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 250 seconds]     
02:41 -!- Guest80396 [~ChillazZ@194.97.152.20] has quit [Quit: Lost terminal]     
02:43 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev     
02:44 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]     
02:45 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
02:53 -!- laurentmt [~Thunderbi@80.215.178.151] has joined #bitcoin-core-dev     
02:53 -!- laurentmt [~Thunderbi@80.215.178.151] has quit [Client Quit]     
02:53 -!- wvr [~wvr@0.red-88-15-41.dynamicip.rima-tde.net] has quit [Read error: Connection reset by peer]     
02:53 -!- wvr [~wvr@0.red-88-15-41.dynamicip.rima-tde.net] has joined #bitcoin-core-dev     
03:04 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
03:06 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 246 seconds]     
03:22 -!- laurentmt [~Thunderbi@80.215.178.151] has joined #bitcoin-core-dev     
03:22 -!- laurentmt [~Thunderbi@80.215.178.151] has quit [Client Quit]     
03:30 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
03:42 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 258 seconds]     
03:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev     
04:07 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has quit [Disconnected by services]     
04:07 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 258 seconds]     
04:08 -!- mturquette [sid66043@gateway/web/irccloud.com/x-mpgthzcsfhvtqwio] has quit [Ping timeout: 258 seconds]     
04:08 -!- atroxes [~atroxes@unaffiliated/atroxes] has quit [Ping timeout: 258 seconds]     
04:08 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev     
04:09 -!- lightningbot [~supybot@2400:8901::f03c:91ff:febb:bbc1] has joined #bitcoin-core-dev     
04:13 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev     
04:40 -!- Atomicat_ [~Atomicat@unaffiliated/atomicat] has joined #bitcoin-core-dev     
04:42 -!- Atomicat [~Atomicat@unaffiliated/atomicat] has quit [Ping timeout: 246 seconds]     
04:42 -!- Atomicat_ is now known as Atomicat     
05:09 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has joined #bitcoin-core-dev     
05:09 -!- alpalp [~allen@cpe-24-27-58-209.austin.res.rr.com] has quit [Changing host]     
05:09 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
05:17 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 258 seconds]     
05:19 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
05:25 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
05:27 -!- snowden66 [~ed@194.230.159.180] has joined #bitcoin-core-dev     
05:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2]     
05:29 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 258 seconds]     
05:29 -!- xiangfu [~xiangfu@223.223.187.142] has quit [Ping timeout: 244 seconds]     
05:30 -!- snowden69 [~ed@193.134.219.70] has quit [Ping timeout: 256 seconds]     
05:30 -!- snowden66 [~ed@194.230.159.180] has quit [Read error: Connection reset by peer]     
05:30 -!- snowden24 [~ed@193.134.219.70] has joined #bitcoin-core-dev     
05:30 -!- xiangfu [~xiangfu@223.223.187.142] has joined #bitcoin-core-dev     
05:31 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev     
05:32 -!- laurentmt [~Thunderbi@80.215.138.21] has joined #bitcoin-core-dev     
05:32 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev     
05:34 -!- laurentmt [~Thunderbi@80.215.138.21] has quit [Client Quit]     
05:36 -!- cannon-c [ccc23f04@gateway/web/freenode/ip.204.194.63.4] has quit [Quit: Page closed]     
05:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:42 -!- snowden24 [~ed@193.134.219.70] has quit [Read error: Connection reset by peer]     
05:45 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 268 seconds]     
06:00 -!- shesek [~shesek@bzq-84-110-55-170.cablep.bezeqint.net] has joined #bitcoin-core-dev     
06:03 -!- mturquette [sid66043@gateway/web/irccloud.com/x-xghbtogzhrrndmdh] has joined #bitcoin-core-dev     
06:07 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev     
06:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]     
06:25 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:29 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
06:37 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]     
06:38 -!- gjgkhfg [4e30757c@gateway/web/freenode/ip.78.48.117.124] has joined #bitcoin-core-dev     
06:43 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has joined #bitcoin-core-dev     
06:56 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
07:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
07:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:58 -!- abpa [~abpa@2602:306:b837:dbf0:bcaf:9c30:6db3:71d5] has joined #bitcoin-core-dev     
07:58 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/b83264d9c7a8...5bc209c73fb6
07:58 < bitcoin-git> bitcoin/master a4153e2 Patrick Strateman: Simple fuzzing framework
07:58 < bitcoin-git> bitcoin/master 8b15434 Wladimir J. van der Laan: doc: Add bare-bones documentation for fuzzing
07:59 < bitcoin-git> bitcoin/master 5bc209c Wladimir J. van der Laan: Merge #9172: Resurrect pstratem's "Simple fuzzing framework"...
07:59 -!- abpa [~abpa@2602:306:b837:dbf0:bcaf:9c30:6db3:71d5] has quit [Client Quit]     
08:00 -!- laurentmt [~Thunderbi@80.215.138.21] has joined #bitcoin-core-dev     
08:01 < btcdrak> wumpus: #7562 is ready for merge.
08:01 < gribble> https://github.com/bitcoin/bitcoin/issues/7562 | Bump transaction version default to 2 by btcdrak · Pull Request #7562 · bitcoin/bitcoin · GitHub
08:01 < bitcoin-git> [bitcoin] laanwj closed pull request #9340: [0.13] Update secp256k1 subtree (0.13...Mf1612-013subtree) https://github.com/bitcoin/bitcoin/pull/9340
08:01 < wumpus> btcdrak: thanks
08:03 -!- xiangfu [~xiangfu@223.223.187.142] has quit [Ping timeout: 264 seconds]     
08:03 < bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/5bc209c73fb6...1eef038b1bcf
08:03 < bitcoin-git> bitcoin/master 1f0ca1a BtcDrak: Bump default transaction version to 2
08:03 < bitcoin-git> bitcoin/master c5d746a Alex Morcos: tiny test fix for mempool_tests
08:03 < bitcoin-git> bitcoin/master dab207e BtcDrak: Preserve tx version=1 for certain tests...
08:04 -!- laurentmt [~Thunderbi@80.215.138.21] has quit [Client Quit]     
08:05 -!- xiangfu [~xiangfu@223.223.187.142] has joined #bitcoin-core-dev     
08:07 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1eef038b1bcf...c6fd923886a3
08:07 < bitcoin-git> bitcoin/master d8c0b9f Russell Yanofsky: [qa] Add test for rescan feature of wallet key import RPCs...
08:07 < bitcoin-git> bitcoin/master c6fd923 Wladimir J. van der Laan: Merge #9331: [qa] Add test for rescan feature of wallet key import RPCs...
08:07 < bitcoin-git> [bitcoin] laanwj closed pull request #9331: [qa] Add test for rescan feature of wallet key import RPCs (master...pr/test-import-rescan) https://github.com/bitcoin/bitcoin/pull/9331
08:10 -!- ryanofsky_ [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has left #bitcoin-core-dev ["Leaving"]     
08:10 -!- ryanofsky_ [~russ@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
08:14 -!- MykelSIlver [~MykelSIlv@192-228-145-85.ftth.glasoperator.nl] has quit [Quit: -a- Android IRC 2.1.17]     
08:14 -!- Atomicat [~Atomicat@unaffiliated/atomicat] has quit [Read error: Connection reset by peer]     
08:16 -!- Atomicat [~Atomicat@unaffiliated/atomicat] has joined #bitcoin-core-dev     
08:29 -!- laurentmt [~Thunderbi@80.215.138.21] has joined #bitcoin-core-dev     
08:31 -!- laurentmt [~Thunderbi@80.215.138.21] has quit [Client Quit]     
08:37 -!- LeMiner [~LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer]     
08:39 -!- TomMc [~tom@unaffiliated/tommc] has quit [Ping timeout: 260 seconds]     
08:45 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev     
08:47 < bitcoin-git> [bitcoin] laanwj opened pull request #9353: Add data() method to CDataStream (master...2016_12_cdatastream_data) https://github.com/bitcoin/bitcoin/pull/9353
08:49 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:54 -!- laurentmt [~Thunderbi@80.215.138.21] has joined #bitcoin-core-dev     
08:55 -!- jtimon [~quassel@231.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
08:59 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
09:01 -!- laurentmt [~Thunderbi@80.215.138.21] has quit [Quit: laurentmt]     
09:03 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 250 seconds]     
09:05 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Ping timeout: 245 seconds]     
09:08 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
09:11 -!- laurentmt [~Thunderbi@80.215.138.21] has joined #bitcoin-core-dev     
09:18 -!- laurentmt [~Thunderbi@80.215.138.21] has quit [Remote host closed the connection]     
09:19 < bitcoin-git> [bitcoin] sipa opened pull request #9354: Make fuzzer actually test CTxOutCompressor (master...fixfuzz) https://github.com/bitcoin/bitcoin/pull/9354
09:19 -!- laurentmt [~Thunderbi@80.215.138.21] has joined #bitcoin-core-dev     
09:28 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Ping timeout: 256 seconds]     
09:32 < bitcoin-git> [bitcoin] hoffmabc opened pull request #9355: Add welcome script to Bitcoin Ocho (master...master) https://github.com/bitcoin/bitcoin/pull/9355
09:33 < bitcoin-git> [bitcoin] hoffmabc closed pull request #9355: Add welcome script to Bitcoin Ocho (master...master) https://github.com/bitcoin/bitcoin/pull/9355
09:37 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev     
09:38 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
09:46 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
09:46 -!- laurentmt [~Thunderbi@80.215.138.21] has quit [Quit: laurentmt]     
09:50 -!- windsok [~windsok@45.63.59.8] has quit [Ping timeout: 250 seconds]     
09:51 < wumpus> and another user banned. Fuck off with the Ocho trolling.
09:52 -!- windsok [~windsok@45.63.59.8] has joined #bitcoin-core-dev     
09:53 < Lauda> Calm down wumpus :/
10:02 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer]     
10:02 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev     
10:09 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
10:19 < gmaxwell> wumpus: I believe 9313 may be ready for merge.
10:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]     
10:38 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer]     
10:38 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
10:50 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c6fd923886a3...756374c522c4
10:50 < bitcoin-git> bitcoin/master 01fea7a Alex Morcos: If we don't allow free txs, always send a fee filter
10:50 < bitcoin-git> bitcoin/master 756374c Wladimir J. van der Laan: Merge #9313: If we don't allow free txs, always send a fee filter...
10:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:50 < bitcoin-git> [bitcoin] laanwj closed pull request #9313: If we don't allow free txs, always send a fee filter (master...minminfee) https://github.com/bitcoin/bitcoin/pull/9313
10:55  * jtimon shamelssly reminds people of https://github.com/bitcoin/bitcoin/pull/8855 (part of https://github.com/bitcoin/bitcoin/pull/8994 which needs rebase again)
10:55 -!- TomMc [~tom@unaffiliated/tommc] has quit [Quit: WeeChat 1.4]     
11:00 < achow101> meeting?
11:00 < wumpus> #startmeeting
11:00 < lightningbot> Meeting started Thu Dec 15 19:00:42 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:00 < jonasschnelli> here
11:00 < wumpus> proposed topics?
11:01 < 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
11:01 < sdaftuar> hi     
11:01 < wumpus> + jl2012
11:01 < gmaxwell> I was going to talk about some backlog but almost all of it got merged.
11:01 < instagibbs> oh right
11:01  * gmaxwell looks
11:01 < cfields> sick and useless, but here
11:02 < BlueMatt> cfields: ouch you got it now, too?
11:02 < cfields> BlueMatt: mine was nice enough to wait until the flight home :\
11:02 < wumpus> #9322 seems to need discussion
11:02 < gribble> https://github.com/bitcoin/bitcoin/issues/9322 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
11:02 < phantomcircuit> hi     
11:03 < instagibbs> interesting issue
11:03 < wumpus> "Don't set unknown rpcserialversion"
11:03 < gmaxwell> #9322 
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9322 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
11:03 < BlueMatt> #9352 needs to move forward quickly for fibre/some current network issues
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9352 | Attempt reconstruction from all compact block announcements by sdaftuar · Pull Request #9352 · bitcoin/bitcoin · GitHub
11:03 < wumpus> looks like there is disagreement about whether it should be done at all
11:04 < BlueMatt> wumpus: on which?
11:04 < wumpus> the one I just mentioned
11:05 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has joined #bitcoin-core-dev     
11:05 < gmaxwell> I don't see the disagreement on 9332?
11:05 < instagibbs> luke-jr seemingly does
11:05 < wumpus> #9352 is 21 hours old, that could hardly be called backlog
11:05 < gribble> https://github.com/bitcoin/bitcoin/issues/9352 | Attempt reconstruction from all compact block announcements by sdaftuar · Pull Request #9352 · bitcoin/bitcoin · GitHub
11:05 < gmaxwell> The purpose of the change is to return an error if you ask for seralization version 9 on software that supports 0/1. 
11:05 < BlueMatt> wumpus: didnt say backlog, said critical to address current ongoing network issues
11:05 < instagibbs> yes I think that's well understood 
11:06 < gmaxwell> we can talk about that next.
11:06 < wumpus> would have been useful if luke-jr was here
11:06 < kanzure> hi. late.
11:06 < gmaxwell> oh missed his comment.
11:06 < phantomcircuit> #9332
11:06 < gribble> https://github.com/bitcoin/bitcoin/issues/9332 | Let wallet importmulti RPC accept labels for standard scriptPubKeys (on top of #9331) by ryanofsky · Pull Request #9332 · bitcoin/bitcoin · GitHub
11:07 < gmaxwell> I read luke's comment as saying he wanted a "max you support" version. 
11:07 < phantomcircuit> you mean 9322?
11:07 < gmaxwell> and the response was that this was expected to be the default. Or at least thats my understanding.
11:07 < jtimon> is luke's comment related to https://github.com/bitcoin/bitcoin/pull/9322/files#r92147938 ?
11:07 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
11:08 < gmaxwell> I agree that being able to ask for a max possible is fine. (though 9999 isn't an especially good number for it. :P)
11:08 < instagibbs> I think #9262 is ready, but some disagreement over default value?
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub
11:08 < jtimon> do we have a topic?
11:08 < gmaxwell> jtimon: pr backlog
11:09 < wumpus> gmaxwell: in any case that doesn't have to be done in that pull, so we can just go ahead and merge it
11:09 < gmaxwell> ACK     
11:10 < gmaxwell> in 9262 I don't believe this should default to on, for the same reason that spending unconfirmed coins is enabled by default.
11:10 < gmaxwell> The transactions will be queued in the wallet and periodically rebroadcast (due to other fixes) and go out once they're no longer overlimit.
11:10 < gmaxwell> the meat of the change was avoiding those cases (sometimes) when it could.
11:10 < cfields> #9289 is holding up the next round of changes, and I believe the linked issue is unrelated
11:10 < gribble> https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
11:10 < instagibbs> with other fixes I'm completely comfortable with it off by default.
11:10 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/756374c522c4...c9e00591cd3f
11:11 < bitcoin-git> bitcoin/master 80d073c Pieter Wuille: Complain when unknown rpcserialversion is specified
11:11 < bitcoin-git> bitcoin/master fa615d3 MarcoFalke: [qa] Don't set unknown rpcserialversion
11:11 < bitcoin-git> bitcoin/master c9e0059 Wladimir J. van der Laan: Merge #9322: [qa] Don't set unknown rpcserialversion...
11:11 < cfields> (though maybe #9212 deserves a topic of its own)
11:11 < gribble> https://github.com/bitcoin/bitcoin/issues/9212 | Assertion failed: (nSendVersion != 0), function GetSendVersion, file ./net.h, line 775. · Issue #9212 · bitcoin/bitcoin · GitHub
11:11 < bitcoin-git> [bitcoin] laanwj closed pull request #9292: Complain when unknown rpcserialversion is specified (master...nofutureserial) https://github.com/bitcoin/bitcoin/pull/9292
11:11 < wumpus> cfields: agreed
11:12 < wumpus> ok, so #9262 off by default? should it still be backported then?
11:13 < gribble> https://github.com/bitcoin/bitcoin/issues/9262 | Prefer coins that have fewer ancestors, sanity check txn before ATMP by instagibbs · Pull Request #9262 · bitcoin/bitcoin · GitHub
11:13 < BlueMatt> cfields/wumpus: I think there is a fix commit for 9212 on the issue page at the bottom (I havent pr'ed yet because testing, but I think it'd work)
11:13 < gmaxwell> wumpus: yes, it should, the main thing in the change is that it avoids creating those poorly propagating transactions when it's possible.
11:13 < gmaxwell> (My opinion)
11:13 < sipa> wumpus: 9262 does 2 things 1) avoid long chains 2) pre-reject created wallet transactions that would exceed limits
11:13 < wumpus> gmaxwell: so it still does something even if it's disabled? okay
11:13 < sipa> wumpus: only 2 is optional
11:13 < wumpus> okay, right, that wasn't clear to me
11:14 < wumpus> BlueMatt: ok, will test that too
11:14 < instagibbs> yes so with default off it will simply try harder to pick coins that have shorter chain length
11:14 < instagibbs> rather than blindly 
11:15 < sipa> which won't have an effect if you're always sending your full change
11:15 < sipa> but better is better
11:15 < cfields> BlueMatt: the reason I didn't do that is that it hides the previous behavior. The current asserts point out issues that need to be backported to 0.13
11:15 < cfields> (which admittedly should've been loud errors rather than asserts)
11:15 < gmaxwell> The original suggestion to create that change was (1) based on me actually encountering users that could have avoided the long chains.
11:16 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has quit [Remote host closed the connection]     
11:16 < btcdrak> here
11:16 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has joined #bitcoin-core-dev     
11:16 < wumpus> cfields: critical issues? or nothing that needs to hold up 0.13.2?
11:16 < gmaxwell> cfields: I had a node go down with-- we think-- that assert.. but can't tell where it was triggered from.
11:16 < sipa> cfields: do they really need backporting?
11:17 < cfields> wumpus: likely nothing critical, just possible data leaks
11:17 -!- MarcoFalke [~marco@2001:4ca0:0:f226:a063:75b:7f88:d780] has quit [Read error: Connection reset by peer]     
11:17 < wumpus> so if I get this right there are now two remaining unmerged pulls that need backport to 0.13.2 https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.2
11:17 -!- MarcoFalke [~marco@host247-2.natpool.mwn.de] has joined #bitcoin-core-dev     
11:17 < BlueMatt> cfields: why are those data leaks? anyway, I think we previously discussed not using nVersion != 0 for this check
11:17 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Ping timeout: 264 seconds]     
11:17 < wumpus> just one I mean, the other *is* a a backport
11:17 < sipa> cfields: i'd say that such issues are things where we're certainly violating some of our own assumptions about how the p2p implementation works, but unlikely things that cause issues in interaction with other nodes
11:18 < cfields> any assert represents some case where we should be disconnected, but instead are still sending/responding.
11:18 < jtimon> #8855 could need rebase if there's new uses of Params(std::string), but if there are, they won't necessarily cause git conflicts
11:18 < BlueMatt> cfields: no, in this case it means we are sending, but havent yet sent version message
11:19 < gmaxwell> wumpus: I believe #9352 will be tagged for backport-- but it's too green to comment on it for the moment. 
11:19 < wumpus> gmaxwell: that's too bad, I hoped we could finally get this over with this week
11:19 < cfields> BlueMatt: right, which specifically here means that we've refused the connection due to missing connection flags, but we're still sending/responding
11:19 < wumpus> gmaxwell: can't it wait for 0.13.3?
11:19 < sdaftuar> gmaxwell: should i go ahead and open the backport version of #9352?
11:19 < BlueMatt> wumpus: its a relatively simple patch, I'm hopeful we still can :)
11:20 < instagibbs> I will review asap
11:20 < cfields> BlueMatt: let's take it up after the meeting
11:21 < BlueMatt> cfields: sure
11:23 < wumpus> okay, any other topics to discuss?
11:23 < gmaxwell> sdaftuar: I think that would be useful.
11:23 < gmaxwell> wumpus: I really want 0.13.2 in RC ASAP. just have some specific conerns about needing that. We'll work through it.
11:24 < MarcoFalke> Could 9262 delay the rc?
11:24 < MarcoFalke> Is it well tested?
11:24 < jtimon> #8498 has been in the backlog for a while too (before that, #6445 was waiting for #6526/#6625/#6557 and friends, which were merged or closed long ago)
11:24 < MarcoFalke> (Note that it was not yet merged into master)
11:24 < gmaxwell> MarcoFalke: I've tested the heck out of it. dunno about others.
11:24 < MarcoFalke> (I haven't really looked at it)
11:24 < cfields> wumpus: regarding the assertion backports, nothing would be a regression from 0.13, so no need to delay, only a bonus if we get fixes in.
11:25 < btcdrak> sdaftuar: ack on backport #9352
11:25 < gmaxwell> MarcoFalke: it's the oldest of thes long-chain wallet fixes, just last to merge. as it had lots of oppturnities for shed painting and resulted in deciding to fix the other issues. :)
11:25 < wumpus> MarcoFalke: there was at least the discussion to disable the setting by default, but after that change I don't know why it should hold up anything
11:25 < wumpus> MarcoFalke: I don't think there's any critical concerns with it left
11:26 < gmaxwell> with the default off it only changes 'non-determinstic' behavior.
11:26 < gmaxwell> (selectcoins)
11:26 < sipa> the patch always had the setting off by default - i was the one arguing that it should be on by default instead (and it seems few people agree, fine)
11:26 < instagibbs> Hm? it was on before
11:26 < instagibbs> but this is pre other 2 changes
11:26 < sipa> oh? maybe before i looked at it :)
11:27 < wumpus> let's just settle on having it disabled by default in the initial merge and the backport, it can always be set to be enabled by default later...
11:27 < gmaxwell> sipa: you could argue for that in 0.14 later. 
11:27 < gmaxwell> that.
11:27 < MarcoFalke> Agree wumpus
11:28 < wumpus> there's no need to fix everything in one pull, or one version for that matter, sometimes things are held up too long on minor discussion points
11:28 < instagibbs> better is better
11:28 < wumpus> right.
11:28 < MarcoFalke> morcos: gmaxwell: Do you have a strong opinion about the fLimitFree flag in the #9290
11:28 < MarcoFalke>  backport?
11:28 < gmaxwell> sometimes better is worse, there is totally like an essay on this. :P
11:28 < jtimon> sipa: just said fine on not having it on by default, didn't he?
11:29 < wumpus> yes he did, I meant in general
11:29 < sipa> jtimon: yes, i'm fine with it being off
11:29 < wumpus> MarcoFalke: ah yes that's an important point
11:29 < gmaxwell> MarcoFalke: Didn't see your question until now. will evaluate.
11:30 < wumpus> so this is about this comment: https://github.com/bitcoin/bitcoin/pull/9347#discussion_r92503011
11:30 < MarcoFalke> Imo it should not matter too much, but I'd rather have a second opinion
11:30 < bitcoin-git> [bitcoin] sdaftuar opened pull request #9357: [0.13 backport] Attempt reconstruction from all compact block announcements (0.13...backport-optimistic-cb) https://github.com/bitcoin/bitcoin/pull/9357
11:32 < MarcoFalke> I haven't checked if it caused issues with txes evicted from the pool due to low fee.
11:32 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has joined #bitcoin-core-dev     
11:32 < gmaxwell> I need to look into it carefully to make a decision on my view, not going to manage it during the meeting.
11:33 < MarcoFalke> ok, other topics?
11:34 < morcos> MarcoFalke: I hadn't seen the flimitFree thing before now, I'll take a look and get back to you after...  (same as gmaxwell)
11:34 < MarcoFalke> great, thx
11:34 < gmaxwell> We could talk about the compact block announcement stuff not the backports but the change; just so people know what the change is about.
11:34 < wumpus> #topic compact block announcement stuff
11:35 < gmaxwell> Right now, if someone sends us a header, we request a block and mark the block in flight. If a compact block (e.g. from a HB mode sender that sends unsolicited ones) shows up while we're waiting.. we just ignore it, instead of trying to reconstruct the block.
11:35 < gmaxwell> This means that if a peer is broken and slowly transmits or fails to reply, the HB mode will fail to work around it.
11:36 < gmaxwell> There is a deep rabbit hole we can go down towards optimal behavior, but what is proposed right now is a super minimal change where even if a block is in flight, we'll still see if we can recover the whole block from just the compact block. And if we can, we take it, and mark the block as complete.
11:37 < wumpus> sounds sensible
11:37 < gmaxwell> greater than 2/3rs of all blocks can be recovered from just the compact block (varries a lot based on miner/network behavior) so even this small improvement should be a pretty big help.
11:37 < wumpus> there seems some potential for race conditions though
11:37 < BlueMatt> this is especially important with prefill, where, if your peer upgrades to prefill txn in the announcement you can recover the block somtimes and recover from stalling without yourself upgrading
11:38 < wumpus> what if the compact block is reconstructed, and then the inflight block comes in?
11:38 < gmaxwell> wumpus: yes, though we don't count on the in-flight to protect against that, and if a full block shows up right now we'll accept it.
11:38 < sdaftuar> wumpus: should not be a problem.  there's generally no downside to receiving a block you already have.
11:38 < gmaxwell> wumpus: then its just like someone sending us an unsolicited full block, which we'll process if it's not best already.
11:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds]     
11:40 < wumpus> sdaftuar: in general there's no downside, just thought it'd be a potential edge case, but if that's handled that's ok
11:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
11:40 < gmaxwell> In any case, I think that summarizes where that is, I have several nodes testing live right now.. obviously will need review and testing.. but I just wanted everyone to know what was going on there.
11:42 -!- chris2000 [~chris2000@p5082A662.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
11:42 -!- chris2000 [~chris2000@p5082A662.dip0.t-ipconnect.de] has left #bitcoin-core-dev []     
11:42 -!- chris2000 [~chris2000@p5082A662.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
11:44 < jtimon> thanks, I assume more questions about this or other topics?
11:46 < achow101> when are we planning to start rc'ing for 0.13.2
11:47 < wumpus> dunno, yesterday if it was up to me :p
11:48 < wumpus> in any case there's still a few things open and you can help by testing and reviewing: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.2
11:49 < wumpus> bah looks like the build is broken
11:50 < wumpus> any other topics? if not we'll close the meeting early
11:51 < sipa> very short report: gmaxwell and i have been experimenting with a per-txout utxo cache approach
11:51 < gmaxwell> Close meeting early and make 0.13.2 great again ACK.
11:51 < sipa> so far results don't look too promising
11:51 < wumpus> heh     
11:51 < morcos> sipa: yeah i haven't looked at that yet
11:51 < morcos> i'm surprised!
11:51 < morcos> i was super optimistic
11:52 < sipa> me too
11:52 < wumpus> sipa: so grouping the utxos per transaction turns out to have been a good optimization? I'm surprised too
11:52 < gmaxwell> Well when it's operating totally in memory it's 15% faster even though sipa has not exploited the new structure for better cache intelligence (so its still doing the same dumb flush thing). But when leveldb came into the picture it ate dirt.
11:52 < morcos> 15% is for babies
11:52 < instagibbs> what level are you on morcos :)
11:52 < sdaftuar> i'm going to give a cheers for the sigcache cuckoocache merge now!
11:53 < jtimon> mhm, haven't looked at the branch, are the utxo's catched per txout but stored per-tx?
11:53 < sipa> jtimon: both per txout
11:53 < gmaxwell> Assuming the issue isn't extra debugging sipa added, the downside is perhaps that it is just much harder on leveldb and writes a lot more traffic to the leveldb log.
11:53 < BlueMatt> gmaxwell: seems like something where you can per-utxo in memory and per-tx on disk?
11:53 < wumpus> BlueMatt: yes I was about to suggest that too
11:53 < gmaxwell> The real gains from the change would come from making the cache smarter, so I thought 15% was great news.. since that likely came from reduced malloc traffic.
11:53 < BlueMatt> i mean might lose all the performance on the boundary, but its worth a shot
11:54 < jtimon> sipa: thanks. mhmm, yeah, this is surprising then
11:54 < sipa> BlueMatt: that doesn't solve the O(n^2) issue with large transactions
11:54 < gmaxwell> BlueMatt: yes, I made that observation too.... but it means that read modify write cycles would be needed.
11:54 < wumpus> gmaxwell: yeah that would be bad...
11:54 < wumpus> lookups are slow, if you need read-modify-write cycles it's not going to help performance
11:54 < sipa> the O(n^2) issue is that a tx with many outputs on every spend needs to write n-i outputs to the database
11:55 < gmaxwell> wumpus: yes, though it might pay for itself by the cache being much more effective. I guess we won't know until after more testing.
11:55 < cfields> sdaftuar: +1. Still catching up, didn't see that got merged. Great to see :)
11:56 < gmaxwell> the other negative is that it looks like this change will require a chainstate reindex. making it compatible with undo files seems really hard.
11:56 < sipa> basically my reason for wanting per-txout cache is that the current behaviour may be good on average, but it's terrible for big transactions
11:56 < jtimon> maybe somehow writting txouts in batches could help? (thinking out loud, may be a stupid thought)
11:56 < wumpus> requiring everyone to do a chainstate reindex would be bad too :/
11:57 < sipa> jtimon: we're already batching _all_ writes from many blocks
11:57 < jtimon> sipa: I see, it was a stupid thought
11:57 < sipa> anyway, just reporting on an experiment - nothing more at this point
11:57 < morcos> gmaxwell: i'm not sure what you mean about making the cache smarter
11:58 < gmaxwell> wumpus: right now everyone's chainstate is corrupted... to at some point we'll need to do something about that.  (TXversions)
11:58 < wumpus> writes are pretty fast with leveldb, it's lookups/reads are slow, especially on slow disks
11:58 < sipa> morcos: not wiping the cache after a write
11:58 < morcos> in my view once its only keeping utxos that were actually accessed and not the rest that tagged along with the tx, then thats as smart as it gets
11:58 < Chris_Stewart_5> Are we thinking txs are going to become larger in terms of inputs/outputs as Bitcoin grows? UTXO size is constantly growing right?
11:58 < morcos> sipa: sure but you still have to do something when you hit memory limits
11:58 < sipa> Chris_Stewart_5: i wish it were not growing at all
11:59 < wumpus> batching writes more is not going to help, and batches are already huge in memory
11:59 < morcos> you can save the things that are in blocks from the top of your mempool, but thats really small... small enough that it can be done pretty effectively with the existing model
11:59 < sipa> Chris_Stewart_5: http://bitcoin.sipa.be/utxo_size.png
11:59 < gmaxwell> morcos: yes the right thing to do is to expire only the oldest entrties at that point. Which is much cleaner when there is no such thing as entry mutation.
11:59 < Chris_Stewart_5> I guess it is just interesting to hear the tidbit about terrible performance of large txs. 
11:59 < wumpus> gmaxwell: requiring everyone to reindex at the same time is not an acceptable solution though :)
11:59 < morcos> ah, oldest, yes ok, but that requires extra state
11:59 < wumpus> gmaxwell: maybe it could support two database versions for a while
11:59 < sipa> Chris_Stewart_5: in general, we need to optimize worst-case performance, not average performance
11:59 < wumpus> gmaxwell: new reindexes/syncs would use the new format
12:00 < wumpus> in any acsae, thanks for trying this experiment
12:00 < sipa> Chris_Stewart_5: as a large difference between worst-case and average means we could be missing DoS opportunities where an attacker can force us into the worsr
12:00 < gmaxwell> wumpus: if it made it N fold faster, than reindex on a new version... might be something we could have happen. I think perhaps we'd want to finish your snapshooting work and other things at the same time. ... in any case it's just an expirement now.
12:00 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev     
12:00 < wumpus> even if it turns out it's not better it's good to know this for sure
12:00 < gmaxwell> it also has resulted in some other optimizations, e.g. the flushing optimization PR that we have right now.
12:00 < sipa> Chris_Stewart_5: but it's really sad when you need to decrease your average performance in order to improve the worst case... because people don't observe the worst case
12:00 < wumpus> gmaxwell: if it was possible to convert the old database to the new database without a reindex (e.g. just rewriting) then an upgrade process would be acceptable. But a full reindex? no
12:01 < gmaxwell> Good, the meeting has run over, so all is well with the world. :)
12:01 < wumpus> #endmeeting
12:01 < lightningbot> Meeting ended Thu Dec 15 20:01:08 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:01 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.html
12:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.txt
12:01 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-12-15-19.00.log.html
12:01 < sipa> wumpus: i believe it is convertible, but it's nontrivial
12:01 < gmaxwell> wumpus: that would be possible, though perhaps a lot of code.
12:01 < Chris_Stewart_5> sipa: Thanks for the food for thought. I appreciate the extra explanation :-) 
12:01 < wumpus> gmaxwell: ah yes thanks for reminding me of the snapshotting
12:02 < sipa> the tx height/coinbase is currently only stored in the undo data for the last spend from one tx's outputs, and needs to be stored in all
12:02 < sipa> but that can be done by walking the undo data backwards (which is always possible, even in pruned mode), and building a temporary database with tx->metadata maps, and using that to rebuild the undo data in the new format
12:03 < jtimon> wumpus: what snapshotting?
12:03 < wumpus> jtimon: automatic utxo database backups
12:04  * jtimon nods
12:05 < gmaxwell> morcos: my thought was that with the per-utxo model we could simply have a list of keys as they're read into the cache... and then when the cach is full, pop from the beginning of the list and flush those entries... to take it back to 90% or something (whatever is big enough to have a reasonable batch size for leveldb).
12:05 < wumpus> sipa: btw I still get no results from "host seed.bitcoin.sipa.be"
12:05 < gmaxwell> Sipa noticed that right now we end up using somewhat less than twice our memory limit; the flush process copies the data being flushed.
12:05 < morcos> gmaxwell: wow, really... i didn't realize that
12:06 < morcos> sdaftuar also points out that just deleting spent entries will help
12:07 < gmaxwell> morcos: well their deletion needs to hit the disk if their creation ever did.
12:07 < morcos> i had observed that it wasn't THAT helpful, but that was with requiring the whole TX to be spent... should be a much bigger effect
12:07 < gmaxwell> oh yea, thats one of the benefits of the per txout model.
12:07 < morcos> yes, so on flush, you can keep everything that isn't spent and your memory usage may reduce non-trivially
12:09 < gmaxwell> in any case, because of that memory usage we should be limiting our leveldb batch sizes. I'm guessing there probably is no real performance benefit to a batch of 200MB (or 2000mb) over 20MB.
12:09 < sipa> the size of batches is determined by how much has changed
12:09 < morcos> yeah, thats what i was thinking a bit annoying to have to track that too
12:10 < sipa> unless we maintain multiple checkpoints in-memory, to know which entries combined form a consistent state, that's very hard to reduce
12:10 < sipa> multiple in-memory checkpoints also implies we can't do the fresh optimization until an entry is in no snapshot
12:10 < wumpus> that sounds overly complicated
12:10 < sipa> yes.
12:11 < morcos> gmaxwell: one advnatage of bigger batch sizes is the ability to delete fresh pruned entries...  you lose all your freshness after a flush
12:12 < gmaxwell> well, the alternative for memory usage is that we start making changes to the leveldb api so that it can do some kind of gather callback or something for the batch.
12:13 < sipa> yes.
12:13 < gmaxwell> (I'm not even sure if thats possible, but it looked like it with a quick glance at the leveldb code)
12:13 < sipa> we discovered that a leveldb write batch is a wrapped std::string
12:13 < sipa> which just gets writes and erased appended to in a binary format
12:14 < wumpus> optimizing leveldb's batch representation/scheduling would certainly be possible, yes
12:15 < wumpus> but in my experience it's reads / lookups that take lots of time, especially on slow disks, not so much writing, writing with leveldb is much faster than comparable databases such as lmdb
12:16 < sipa> well writing 2GB of modified utxo entries required 90s in gmaxwell's benchmarks
12:16 < gmaxwell> well it was 40s with master, 90s with the per-utxo.
12:17 < wumpus> but that's hardly realistic for normal usage
12:17 < wumpus> if you have a dbcache of gigabytes you hardly really need a database at all
12:18 < gmaxwell> wumpus: so right now our initial sync performance is really poor with the default cache. it takes 21076 seconds to chainstate reindex even with all signature checking disabled on a fast machine.  We often tell people to crank their dbcache to big numbers to make ibd take more acceptable time.
12:19 < wumpus> gmaxwell: but is that due to writing? as said, in my experience, it spends almost all the time connecting inputs - e.g. fetching and random lookups
12:19 < wumpus> it could be I just have very strange hardware of course
12:20 < gmaxwell> sorry, I thought you were saying that it wasn't realistic for people to run with a big dbcache; and I was just countering that running with a big dbcache is the only way to get ibd to run in a sane-ish amount of time. I guess I was on a tangent from your point.
12:24 < wumpus> right - maybe the best solution for small memory usage and large memory usage is completely different
12:26 < wumpus> another thing with writes is that things can be pipelined, as soon as the batch buffers have been filled it could be shipped off to a background thread doing the writing, there's no need to wait for it to continue
12:31 < gmaxwell> wumpus: yes. Indeed. perhaps a little tricky with consistency between the chainstate and the blockindex.
12:31 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Ping timeout: 258 seconds]     
12:31 -!- droark [~droark@c-24-22-123-27.hsd1.or.comcast.net] has quit [Ping timeout: 248 seconds]     
12:40 < gmaxwell> ohh sipa's per utxo code had debugging code that was trashing performance, rebenchmarking is looking much more promising!
12:43 < sdaftuar> yay!
12:43 < sipa> (with large dbcache)
12:43 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
12:44 < gmaxwell> Man.  Thomas Zander wrote some article attacking segwit today that says up front "Once a user gets a SegWit transaction, she will only be able to move that money forward in a SegWit wallet. So if a person doesn't upgrade they will eventually not be able to accept money from anyone." -- will there be no consequence in this ecosystem for this kind of incompetence or dishonesty?  damn.  It also rep
12:44 < gmaxwell> eats Jeff Garzik's two buckets lie. 
12:44 < gmaxwell> https://bitcoinclassic.com/devel/FlexTrans-vs-SegWit.html
12:46 < gmaxwell> Also deceptively claims to make transactions smaller (actually-- it increases the amount of information in a transaction-- because it makes the field ordering non-normative--, making the smallest possible representation larger...)
12:51 < juscamarena> Just saw that. Was the site hacked? He can't really believe that?
12:52 < sipa> i'm sure he believes it
12:53 < gmaxwell> he's previously posted a number of absurd things, e.g. the posts claiming that BIP152 was going to "disrupt the network" and trying to get us to abort the 0.13 release.
12:59 < btcdrak> gmaxwell: what the heck? that's just ...
13:02 < juscamarena> Sigh. He might have gotten confused here: "When spending your bitcoins after the upgrade to segwit, you will still be able to pay the original type of Bitcoin addresses that start with a ‘1’ (a P2PKH address) as well as being able to pay other users of P2SH addresses."
13:02 < juscamarena> Thinking upgrade meant upgrading the wallet.
13:03 -!- grubles_ is now known as grubles     
13:03 < gmaxwell> I'm having a really hard time believing that he is actually this confused.
13:06 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
13:26 -!- crescendo [~mozart@unaffiliated/crescendo] has joined #bitcoin-core-dev     
13:28 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye]     
13:33 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
13:36 < morcos> gmaxwell: just skimmed what he wrote.. i don't think hes confused.. (except about the 2 buckets crap, but you know "math is hard")
13:37 < morcos> i think he was just trying to make a point that i don't think really makes any sense, that people with segwit wallets would prefer to send to other segwit addresses
13:37 < morcos> well yes i guess maybe thats what you meant by confused, since there is no reason they would prefer that?
13:38 < gmaxwell> there is no reason they would prefer that.
13:38 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
13:38 < gmaxwell> Doesn't cost them any more or less.
13:38 < gmaxwell> it's indistinguishable to them.
13:39 < morcos> it seems maybe the text changed if yours was an actual quote
13:39 < gmaxwell> actually, since the only kind of address type right now used for segwit is p2sh-p2w* it is cryptographically indistinguishable.
13:39 < gmaxwell> morcos: my test was an actual quote.
13:39 < gmaxwell> er text.
13:39 < morcos> it still says this which is at best badly misleading
13:39 < morcos> "receiving a SegWit transaction requires a SegWit wallet which then will generate SegWit transactions forcing everyone around you to get one too."
13:40 < gmaxwell> that is absurdly untrue too.
13:41 < gmaxwell> amusingly one of the big reasons we didn't move foward with a new address type was specifically to avoid this class of misunderstanding.  (the other being that several people wanted time to establish a new base-32 based encoding with proper error detection)
13:44 < MarcoFalke> morcos: Motivated from the rpc test failure: Should the feefilter rounder not return a fee that is less (or equal to) the target fee?
13:44 < MarcoFalke> otherwise you might miss some tx if you "round up"
13:44 < morcos> MarcoFalke: which test failure?
13:44 < MarcoFalke> fundrawtx
13:45 < MarcoFalke> Just a sync mempool issue due to feefilter, I guess
13:45 < morcos> i mean is there a link to what you are talking about
13:45 < MarcoFalke> #9313
13:45 < gribble> https://github.com/bitcoin/bitcoin/issues/9313 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
13:45 < MarcoFalke> If you run fundrawtransaciton on master it will fail randomly
13:46 < morcos> i'm not following... ok, thats what i was wondering
13:46 < morcos> really?
13:46 < MarcoFalke> Likely due to current choice of the feefilter
13:46 < MarcoFalke> It becomes visible when the transaction pays a fee close to the minrelayfee
13:46 < MarcoFalke> your feefilter will be maybe minrelaytxfee+x, so you never see the tx
13:46 < morcos> yeah i guess if you tried to pay exactly the minrelayfee it might not work
13:47 < MarcoFalke> Would it make sense to always send feefilters that are less than the currentFeeFilter?
13:47 < morcos> the variance was put in there to slightly obscure the exact state of your mempool..  but ehh, i'm not sure its worth the effort
13:48 < MarcoFalke> You can keep the variance
13:48 < morcos> realistically i doubt it would be a problem except in tests..
13:48 < MarcoFalke> Sure, on current main net
13:49 < MarcoFalke> with default minrelaytxfee
13:49 < morcos> i mean its been like that since it came out, the only difference is it happens now before your mempool gets full
13:49 < MarcoFalke> Right
13:50 < morcos> i don't feel strongly...   
13:51 < MarcoFalke> As we send a feefilter now by default for all connections, it might not be too much wasted bandwith if we received some minrelaytxfee-dust txs
13:52 < gmaxwell> I think it's okay to leak that you're at the floor. e.g. apply the max after the variance.
13:55 < MarcoFalke> In which case your node is identifiable if you set a non-default value for the relay fee, no? 
13:56 < gmaxwell> it's identifyable by behavior in that case, regardless.
14:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]     
14:13 < morcos> MarcoFalke: yeah the floor is a separate issue.  we already send under the floor all the time anyway... i think that could be a special case perhaps.
14:13 < morcos> i'm just not sure how much any of this is worth it.  to make sure the tests work at exactly minrelaytxfee, need to check all the < vs <='s as well
14:14 -!- Taek [~quassel@2001:41d0:1:472e::] has quit [Ping timeout: 258 seconds]     
14:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]     
14:19 -!- Taek [~quassel@2001:41d0:1:472e::] has joined #bitcoin-core-dev     
14:28 -!- gjgkhfg [4e30757c@gateway/web/freenode/ip.78.48.117.124] has quit [Quit: Page closed]     
14:31 -!- abpa [~abpa@96-82-80-25-static.hfc.comcastbusiness.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
14:32 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
15:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]     
15:04 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
15:07 < luke-jr> instagibbs: more of a suggestion than disagreement re 9322
15:28 -!- wasi [~wasi@gateway/tor-sasl/wasi] has quit [Remote host closed the connection]     
15:29 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds]     
15:34 -!- JackH [~laptop@79-73-185-145.dynamic.dsl.as9105.com] has quit [Quit: Leaving]     
15:36 -!- MarcoFalke [~marco@host247-2.natpool.mwn.de] has left #bitcoin-core-dev []     
15:48 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
16:04 -!- wasi [~wasi@gateway/tor-sasl/wasi] has joined #bitcoin-core-dev     
16:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
16:10 < bitcoin-git> [bitcoin] funbucks opened pull request #9358: Tell github to quit trippin (master...master) https://github.com/bitcoin/bitcoin/pull/9358
16:18 -!- PRab_ [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.93 [Firefox 50.0.2/20161129173726]]     
16:18 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.93 [Firefox 50.0.2/20161129173726]]     
16:19 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-core-dev     
16:42 < gmaxwell> Good news: for a dbcache of size 2000, sipa's "per utxo" cache model is now 22.6% faster than master in a signature validation free chainstate reindex! (benchmarking with a cache size of 300 now, will report back in a few hours)
16:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
16:54 < bitcoin-git> [bitcoin] theuni closed pull request #9358: Tell github to quit trippin (master...master) https://github.com/bitcoin/bitcoin/pull/9358
17:23 < kallle> According to the bitcoin.it wiki, "CompactSize" is a var int, and CVarInt is an "even more compact integer for the purpose of local storage (which is incompatible with "CompactSize" described here)". But it's described in all documentation there and elsewhere as a "varint". So the varint is the compact size and the CVarInt/VARINT refer to something else. Doesn't that cause confusion?
17:28 < sipa> the CVarInt in serialize.h is a bitcoin core internal thing, only used for the utxo database and undo data
17:28 < sipa> and it doesn't appear anywhere in the p2p protocol
17:28 < sipa> CompactSize is the varint type used in the p2p protocol for vector sizes etc
17:30 < sipa> and yes, it's confusing...
17:30 < sipa> historical reasons :)
17:33 < kallle> Seems like a candidate for renaming but I can see how it would cause issues as people have used the two as they are for years... esp if COMPACTSIZE becomes VARINT.
17:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]     
17:49 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
18:17 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-cmdnkqjweucnuike] has quit [Quit: Connection closed for inactivity]     
18:21 -!- jtimon [~quassel@231.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 256 seconds]     
18:23 < Chris_Stewart_5> What is the criteria for setting the default dbcache value? Does a BIP have to be proposed to change it? 
18:24 < sipa> no     
18:24 < sipa> it doesn't affect the network in any way
18:25 < sipa> only your own memory/cpu tradeoff
18:27 < Chris_Stewart_5> What do you think about raising the dbcache defeault value along the lines of your BIP10x proposal of scaling blocksize at the rate of tech growth (.. or something like that)
18:27 < Chris_Stewart_5> I know blocksize/dbcache aren't really related, but I think I was thinking about that as policy for some defaults in bitcoin core. 
18:27 < sipa> sure, but it doesn't need any consideration ahead of time
18:28 < sipa> we can just occasionally change defaults to keep up with technology trends
18:28 < sipa> i think bitcoin-qt for example should just detect how much memory you have at startup, and based on that, choose something and let the user customize
18:29 < sipa> it's harder to do that in bitcoind, which we exapct to run on low-power devices too
18:29 < Chris_Stewart_5> I guess it seems like it could break out into a very politicized change, which is why I think the BIP process would be needed -- but I understand what you mean by it doesn't affect consensus
18:29 < gmaxwell> Chris_Stewart_5: that would be like having a BIP for the color of your theme... it's a purely local thing .. it doesn't matter to you what anyone else uses.
18:29 < gmaxwell> It isn't something where "interoperability" is required.
18:30 < sipa> BIP42 suggests that the currency symbol color should be considered
18:31 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 250 seconds]     
18:33 < Chris_Stewart_5> sipa: That is interesting. I kind of like that idea wrt to reading mem and just setting it off of that.
18:34 < sipa> what idea?
18:34 < Chris_Stewart_5> your comment wrt to bitcoin-qt
18:34 < sipa> Chris_Stewart_5: not only does not affect consensus - it doesn't affect anything
18:35 < sipa> BIP32 also does not affect consensus, but it's still very useful to get people to agree on it
18:35 < gmaxwell> Chris_Stewart_5: it would be a wrong assumption to assume the user wants all their memory used by bitcoin. :(
18:35 < Chris_Stewart_5> gmaxwell: absurd! :P 
18:37 < gmaxwell> we could certantly reduce it based on the amount of free memory!
18:37 < Chris_Stewart_5> ahh, BIP42, not BIP142. I was thinking there was a proposal for strange chars in segwit addresses
18:39 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
18:42 < bitcoin-git> [bitcoin] ryanofsky opened pull request #9359: Fix CWalletTx::GetImmatureCredit() returning stale values. (master...pr/immature) https://github.com/bitcoin/bitcoin/pull/9359
18:42 < Chris_Stewart_5> sipa: That made my night. I unequivocally support BIP42 and (while were at it) make PHP great again!
18:46 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 260 seconds]     
18:47 -!- alpalp [~allen@unaffiliated/alpalp] has joined #bitcoin-core-dev     
18:58 -!- abpa [~abpa@2602:306:b837:dbf0:2057:a981:63b3:9dcd] has joined #bitcoin-core-dev     
19:05 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has quit [Ping timeout: 245 seconds]     
19:09 -!- NielsvG [~Necrathex@2001:982:aa8:1:76d4:35ff:fe12:58d6] has joined #bitcoin-core-dev     
19:09 -!- NielsvG [~Necrathex@2001:982:aa8:1:76d4:35ff:fe12:58d6] has quit [Changing host]     
19:09 -!- NielsvG [~Necrathex@unaffiliated/necrathex] has joined #bitcoin-core-dev     
19:16 -!- Alopex [~bitcoin@176.9.70.183] has quit [Remote host closed the connection]     
19:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:21 -!- Kexkey [~kexkey@184.75.212.158] has joined #bitcoin-core-dev     
19:27 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Read error: Connection reset by peer]     
19:29 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has quit [Quit: Whatever]     
19:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
19:36 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:48 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
19:49 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
19:49 -!- Atomicat_ [~Atomicat@unaffiliated/atomicat] has joined #bitcoin-core-dev     
19:52 -!- Atomicat [~Atomicat@unaffiliated/atomicat] has quit [Ping timeout: 258 seconds]     
19:52 -!- Atomicat_ is now known as Atomicat     
19:53 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
19:55 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 250 seconds]     
19:56 -!- Kexkey [~kexkey@184.75.212.158] has quit [Remote host closed the connection]     
20:00 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]     
20:01 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev     
20:06 -!- alpalp [~allen@unaffiliated/alpalp] has quit [Ping timeout: 264 seconds]     
20:10 -!- MurhS0xFF [~2efPer_1a@222.117.212.4] has joined #bitcoin-core-dev     
20:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]     
20:20 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
20:33 -!- chris200_ [~chris2000@p5082A9F7.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
20:37 -!- chris2000 [~chris2000@p5082A662.dip0.t-ipconnect.de] has quit [Ping timeout: 260 seconds]     
20:52 -!- abpa [~abpa@2602:306:b837:dbf0:2057:a981:63b3:9dcd] has quit [Ping timeout: 245 seconds]     
21:02 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]     
21:22 -!- To7 [~theo@cpe-158-222-222-232.nyc.res.rr.com] has joined #bitcoin-core-dev     
21:26 -!- MurhS0xFF [~2efPer_1a@222.117.212.4] has quit [Quit: 暂离]     
22:00 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
22:03 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 258 seconds]     
22:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
22:21 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye]     
22:50 -!- [Author] [~Author]@2401:a400:3200:5600:bad:d09:15:90d] has quit [Ping timeout: 268 seconds]     
22:50 -!- [Author] [~Author]@2401:a400:3200:5600:bad:d09:15:90d] has joined #bitcoin-core-dev     
22:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ymwrmbtvguzhzstz] has joined #bitcoin-core-dev     
23:19 -!- wvr [~wvr@0.red-88-15-41.dynamicip.rima-tde.net] has quit [Ping timeout: 246 seconds]     
23:30 -!- jtimon [~quassel@231.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
23:48 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-nuxczbthzvhmygpe] has quit [Quit: Connection closed for inactivity]