--- Day changed Thu Mar 10 2016
00:24 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:35 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-zrjpujtphdfdsqln] has quit [Ping timeout: 260 seconds]
00:36 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-phgxcstrpdwjlhus] has quit [Ping timeout: 276 seconds]
00:36 -!- binns [sid105317@21/bitcoin/binns] has quit [Ping timeout: 250 seconds]
00:36 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-yrgoubinsswtnauf] has quit [Ping timeout: 250 seconds]
00:36 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-xuxwavzwxqtdamkr] has quit [Ping timeout: 250 seconds]
00:36 -!- eragmus [sid136308@gateway/web/irccloud.com/x-wovrwsujaipsfjou] has quit [Ping timeout: 268 seconds]
00:39 -!- ibrightly [sid113387@gateway/web/irccloud.com/x-ivpcunvxydutizey] has joined #bitcoin-core-dev
00:41 -!- zmanian__ [sid113594@gateway/web/irccloud.com/x-vjccyxmljydosypa] has joined #bitcoin-core-dev
00:41 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-yshridwmazkddgda] has joined #bitcoin-core-dev
00:45 -!- eragmus [sid136308@gateway/web/irccloud.com/x-eubwytnbhpjptphc] has joined #bitcoin-core-dev
00:48 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-mryabbrtgwhzoqmj] has joined #bitcoin-core-dev
00:50 -!- binns [sid105317@21/bitcoin/binns] has joined #bitcoin-core-dev
01:02 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
01:06 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
01:07 -!- chris2000 [~chris2000@p54AE71A7.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
01:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
01:20 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has quit [Ping timeout: 268 seconds]
01:32 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has joined #bitcoin-core-dev
01:40 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
01:50 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
01:53 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 244 seconds]
02:01 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has joined #bitcoin-core-dev
02:05 < GitHub191> [bitcoin] MarcoFalke opened pull request #7666: [0.12.1] Fix doc and output for rpcauth (0.12...Mf1603-012fixdocrpcauth) https://github.com/bitcoin/bitcoin/pull/7666
02:07 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
02:48 < go1111111> so, wumpus commented on PR 7635 with "utACK after squash". As the PR author does this mean I should make another PR with the changes all squashed into one commit? or will whoever merges it squash them and I take no more action? (this is my first non-trivial PR)
02:50 < MarcoFalke> git checkout docs4; git log -1
02:50 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:50 < jonasschnelli> go1111111: squash and force push on the same branch/PR
02:50 < MarcoFalke> You should not see you last commit 429
02:50 < jonasschnelli> I do that with git rebase -i HEAD~X (X needs to be replace with >= amount of commits)
02:51 < MarcoFalke> git rebase --interactive ed067f722a244a31809eab633fbe316028a6f80b~
02:51 < MarcoFalke> and then select `f` or `s`
02:51 < go1111111> ok, will do. thank you
02:51 < MarcoFalke> finally git push $origin docs4 -f
02:52 < go1111111> random github newb question: in the comments on that PR I referred to another branch in my repo (zmq3). it seemed like github then automatically included that branch in the PR also. which seems dangerous if I want to refer to a branch without including it. is my interpretation of how github handles that correct?
02:53 < go1111111> i couldn't find that behavior documented
02:57 < MarcoFalke> no, should not happen
02:57 < MarcoFalke> maybe you fiddled locally with it.
02:57 < MarcoFalke> Try git branch -v
02:58 < MarcoFalke> to see what your branches look like locally
03:00 < go1111111> ok, thanks.
03:50 -!- shesek [~shesek@bzq-84-110-110-85.cablep.bezeqint.net] has joined #bitcoin-core-dev
04:05 -!- p15 [~p15@131.91.145.64.unassigned.bringover.net] has quit [Ping timeout: 248 seconds]
04:14 -!- p15x [~p15x@151.91.145.64.unassigned.bringover.net] has joined #bitcoin-core-dev
04:14 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
04:14 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has quit [Ping timeout: 252 seconds]
04:16 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has joined #bitcoin-core-dev
04:22 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has quit [Ping timeout: 244 seconds]
04:28 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has joined #bitcoin-core-dev
04:31 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
04:36 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has quit [Read error: Connection reset by peer]
04:36 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.]
04:36 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
04:37 -!- blkdb [~blkdb@2a01:4f8:140:1407::2] has joined #bitcoin-core-dev
04:45 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: zzz]
04:46 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
04:46 -!- afk11_ [~afk11@109.255.154.81] has joined #bitcoin-core-dev
04:48 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Client Quit]
04:48 -!- afk11_ [~afk11@109.255.154.81] has quit [Client Quit]
04:50 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
04:51 -!- afk11_ [~afk11@109.255.154.81] has joined #bitcoin-core-dev
04:54 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]
04:54 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
04:55 -!- nkuttler [~nkuttler@unaffiliated/nkuttler] has quit [Quit: Reconnecting]
04:55 -!- nkuttler [~nkuttler@unaffiliated/nkuttler] has joined #bitcoin-core-dev
05:03 -!- cj [~cjac@104.36.247.21] has quit [Ping timeout: 252 seconds]
05:05 -!- cj [~cjac@104.36.247.21] has joined #bitcoin-core-dev
05:05 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: zzz]
05:05 -!- afk11_ [~afk11@109.255.154.81] has quit [Quit: zzz]
05:15 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has quit [Ping timeout: 240 seconds]
05:21 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
05:22 -!- afk11_ [~afk11@109.255.154.81] has joined #bitcoin-core-dev
05:24 -!- cj [~cjac@104.36.247.21] has quit [Ping timeout: 252 seconds]
05:25 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Client Quit]
05:25 -!- afk11_ [~afk11@109.255.154.81] has quit [Client Quit]
05:27 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has joined #bitcoin-core-dev
05:30 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has joined #bitcoin-core-dev
05:33 -!- cj [~cjac@104.36.247.21] has joined #bitcoin-core-dev
05:37 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
05:41 -!- cj [~cjac@104.36.247.21] has quit [Ping timeout: 252 seconds]
05:49 -!- hybridsole [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
05:59 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev
06:00 -!- p15x [~p15x@151.91.145.64.unassigned.bringover.net] has quit [Ping timeout: 240 seconds]
06:05 < wumpus> go1111111: should be no reason to make a new pull request  - rather not - if you need help with git just let me know
06:06 < wumpus> I've listed the steps in various PRs scattered over the place, probably would make sense to add it to some developer faw
06:06 < wumpus> faq
06:11 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 244 seconds]
06:17 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
06:17 -!- afk11_ [~afk11@109.255.154.81] has joined #bitcoin-core-dev
06:18 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Client Quit]
06:18 -!- afk11_ [~afk11@109.255.154.81] has quit [Client Quit]
06:19 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
06:19 -!- afk11_ [~afk11@109.255.154.81] has joined #bitcoin-core-dev
06:22 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Disconnected by services]
06:22 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
06:26 -!- afk11_ [~afk11@109.255.154.81] has quit [Quit: zzz]
06:26 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Client Quit]
06:27 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
06:30 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Client Quit]
06:31 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
06:31 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Client Quit]
06:32 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
06:39 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: zzz]
06:41 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
06:48 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: zzz]
07:19 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
07:29 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has joined #bitcoin-core-dev
07:45 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
07:49 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has quit [Ping timeout: 246 seconds]
07:50 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
07:50 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has joined #bitcoin-core-dev
07:55 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has quit [Ping timeout: 248 seconds]
07:57 -!- fredrin [~fredrin@cm-84.215.171.162.getinternet.no] has joined #bitcoin-core-dev
08:10 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
08:20 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
08:21 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
08:21 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
08:25 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
08:27 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
08:28 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
08:38 -!- hybridsole [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has quit [Ping timeout: 248 seconds]
08:41 -!- hybridsole [~hybridsol@c-67-177-114-112.hsd1.fl.comcast.net] has joined #bitcoin-core-dev
08:52 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
08:52 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
08:56 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 244 seconds]
09:05 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Ping timeout: 248 seconds]
09:08 -!- Don_John [~Don@251-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
09:14 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has joined #bitcoin-core-dev
09:14 -!- Don_John [~Don@251-223-114-134.nat.resnet.nau.edu] has quit [Ping timeout: 250 seconds]
09:15 < morcos> btcdrak: ok. i got sucked in.  i'm writing rpc/p2p tests for 68/112/113.
09:16 < morcos> i'm basically taking one of your tests that tests the activation logic and modifying to try many variations of different txs before and after soft fork activates and make sure they are accepted/rejected appropriately
09:18 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has joined #bitcoin-core-dev
09:19 -!- Don_John [~Don@251-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
09:38 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
09:39 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
09:44 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
09:44 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
09:49 -!- shesek [~shesek@bzq-84-110-110-85.cablep.bezeqint.net] has quit [Ping timeout: 276 seconds]
09:50 -!- Don_John [~Don@251-223-114-134.nat.resnet.nau.edu] has quit [Read error: Connection reset by peer]
09:52 -!- Don_John [~Don@251-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
09:53 < btcdrak> morcos: we can never have enough test :)
09:58 < morcos> btcdrak: well i was letting you know in case someone else was working on them
09:58 < morcos> but as far as i know we don't have any other than the unit tests so far right?
09:58 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
10:02 -!- shesek [~shesek@bzq-84-110-110-85.red.bezeqint.net] has joined #bitcoin-core-dev
10:09 < sipa> morcos: awesome, thanks
10:09 < sipa> so what is the current state of the pull request against my bip9 pr?
10:10 < sipa> i agree with you that it makes sense to have separate tests for "50% of the past N blocks have a version we don't know", and one for "an unknowm versionbits deployment is lockedin/activated"
10:11 < morcos> sipa: hmm, i guess thats up to you
10:12 < sipa> though the latter one should be permanent i think... if you happened to be offline during the window in which it activated, you won't ever know itherwise
10:12 < morcos> what do you mean by permanent?
10:12 < sipa> that was a downside we get from bit flags that expire: they are not visible forever
10:12 < morcos> i guess its not clear to me how these alerts work
10:13 < morcos> if you're not using QT, there is no permanent way is there?
10:13 < sipa> if any vb deployment ever activated in your currently active blockchain, you get a warning
10:13 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
10:13 < sipa> eh, no clue what qt does
10:13 < morcos> so right now that strMiscWarning isn't displayed in the errors field
10:13 < morcos> i don't think
10:13 < sipa> hmm?
10:14 < morcos> so the errors that are printed in getInfo won't include this
10:14 < morcos> i think
10:14 < morcos> even for ISM soft forks
10:14 -!- skyraider [uid41097@gateway/web/irccloud.com/x-qhhryptwdfxknbga] has joined #bitcoin-core-dev
10:14 < morcos> the only way you see it is if you look at your debug log
10:14 < morcos> or if you're using QT or the -alertnotify script
10:14 < sipa> what?
10:14 < sipa> really?
10:15 < morcos> maybe?
10:15 < sipa> well, i have no counterevidence
10:15 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
10:15 < sipa> so i think that needs investigating
10:15 < morcos> maybe i taket hat back
10:15 < morcos> sorry, let me see
10:17 < morcos> yeah i think thats right
10:17 < morcos> look at GetWarnngs in main.cpp
10:17 < morcos> strRPC isn't updated by strMiscWarning
10:17 < sipa>  heh
10:17 < sipa> that variable name does not even look familiar to me
10:17 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
10:18 < morcos> i also find it a bit disturbing that one warning can wipe out another
10:19 < sipa> i doubt i have ever looked at that code
10:20 < morcos> so for instance if PartitionCheck causes "abnormally high number of blocks" that wipes out your warning that a soft fork has activated
10:20 < morcos> and even in the ISM code, that warning only happens once
10:24 < morcos> so....  i'm going to quietly slink away and go back to my test writing...
10:24 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
10:26 < sipa> we should probably concatenate all warnings...
10:26 < sipa> and have a boolean for "serious" or so
10:27 < sipa> that can make RPCs fail or the GUI show bigger animated themed warning boxes
10:27 < morcos> yeah i think the quick and dirty way is to have separate variables though for each of the warnings
10:27 < morcos> b/c some occur repeatedly or can get cleared out or whatever
10:27 < morcos> and then the display mechanism can check each one and do the right thing?
10:27 < sipa> yeah
10:28 < morcos> i guess it wouldn't be that hard to just have a set of strings, and then you can clear them to
10:28 < sipa> anyway, the point i was trying to make (and which is independent of the warning presentation problem) is that imho a versionbits deployment from anywhere in your past should remain visible (but probably should not be considered serious)
10:29 < morcos> wait, an unknown one should not be considered serious?
10:30 < gmaxwell> Meeting in half an hour, everyone should think back to all the great topics we ran out of time for last week and have them ready for the agenda this time.
10:31 < morcos> sipa: i suppose what we could do is everytime you start the node we rescan for unknown deployments from the beginning (which would speak to using a real cache)..  b/c otherwise there is a risk that you shutdown your old node and when you restart it you've lost the warning, is that what you meant?
10:32 < sipa> morcos: i think that the presence of an unknown softfork should not be treated as something serious
10:32 < sipa> morcos: or just have a versionbits cache per bit for warnings
10:32 < sipa> without special logic
10:32 < morcos> sipa: yes thats what i meant by speaking to using a real cache
10:32 < morcos> perhaps its worth the 300k extra memory
10:32 < morcos> but why isn't it serious?
10:33 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Ping timeout: 240 seconds]
10:33 < morcos> i think it should be considered quite serious
10:33 < morcos> we have in the past, we told you your node was obsolete and you must upgrade
10:33 < morcos> there is no way to know whether the soft fork was relatively benign or not
10:34 < morcos> but if we give the information on the bit/activation height, then it should be easy for people to look up that soft fork, and decide for themselves whether they care
10:34 < morcos> but to suhas's point, thats why its important to be able to warn on the same bit more than once?  
10:35 < sipa> hmm
10:36 < sipa> maybe i misunderstood the code
10:36 < sipa> it seemed to me that it would not catch historical deployments
10:37 < morcos> my code will catch historical deployments but only once
10:37 < morcos> i mean once per each deployment, will catch multiple on the same bit
10:37 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
10:41 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
10:49 -!- kangx_ [42d7ee99@gateway/web/freenode/ip.66.215.238.153] has joined #bitcoin-core-dev
10:50 -!- mrkent [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
10:52 < morcos> so sipa, i think if it were me, i'd just change my PR to run on start up on the entire blockchain, instead of actually populating a cache that is mostly usless and whose only effect is to obscure multiple deployments on the same bit
10:53 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
10:54 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has joined #bitcoin-core-dev
10:55 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
10:55 < sipa> ok
10:56 < gmaxwell> sipa: morcos: sdaftuar: petertodd: btcdrak: wumpus: cfields_: jonasschnelli: phantomcircuit: BlueMatt: jtimon: CodeShark: NicolasDorier: paveljanik:  meetin in 4 minutes.
10:56 < jonasschnelli> here!
10:56 < BlueMatt> ahhhhhh
10:57 < BlueMatt> taggggggg
10:57 < btcdrak> present! 
10:57 < wumpus> yep
10:57 < sipa> here
10:57 < warren> here
10:57 < morcos> sipa: so do you want me to make changes?
10:57 < btcdrak> it's like being in school again :)
10:58 < sipa> morcos: go ahead
10:58 < jcorgan> not invited but still here :-)
10:58 < gmaxwell> (sorry to ping, but we've had slow starts and time shortfalls recently)
10:59 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
11:00 < wumpus> #startmeeting
11:00 < lightningbot> Meeting started Thu Mar 10 18:59:59 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 < wumpus> topics?
11:00 < evoskuil> here
11:01 < morcos> we have a list of remaining segwit items that were written on whiteboard at MIT...  should we assign those?
11:01 < wumpus> sure
11:01  * sipa hides
11:01 -!- mm_1 [bnc33@bnc33.nitrado.net] has quit [Ping timeout: 276 seconds]
11:01  * btcdrak locked the door
11:01 < wumpus> #topic remaining segwit items
11:01 < jonasschnelli> I'm happy to help,... probably in the wallet section.
11:02 < morcos> seems to me it would nice to buckle down and prioritize  BIP 9,  BIPs 68,112,113  ,   segwit.   i mean i think we are all working on those things, but there is still more to do on all of them
11:02 < sipa> my plan was to rebase segwit on top of bip9, add the rewind logic to continie after post-softfork uograde, and do a new testnet
11:02 < sipa> eh, new segnet
11:02 < btcdrak> great
11:02 < CodeShark> when do you think to deploy the new testnet?
11:02 < sdaftuar> we also need to discuss standardness rules
11:02 < sdaftuar> (or rather, propose and discuss)
11:02 < warren> What was decided for safety on the edge of the rule change in case of reorg?
11:03 < morcos> I think my suggestion would be to push that problem to wallet users
11:03 < sdaftuar> warren: i believe we decided to advise wallet authors to wait some time after segwit activates before using
11:03 < sipa> one possibility is not enabling relay/mempool logic for segwit transactions until 2 period after activatation
11:03 < morcos> yes authors i meant
11:04 < gmaxwell> warren: I don't understand the context of your question.  Generall new soft fork rules should not be used immediately.
11:04 < sipa> another is to just be cautious and nit enable the functionality in wallets until a post segwit release
11:04 < sdaftuar> gmaxwell: this one is more dangerous than usual though
11:04 < gmaxwell> sdaftuar: it's just like p2sh.
11:04 < warren> OK, that seems adequate enough.
11:04 < CodeShark> I'm not that concerned about edge case reorg situations
11:04 < morcos> gmaxwell: its a bit riskier than p2sh...  don't need a preimage
11:04 < sipa> it's not situation*s*
11:05 < gmaxwell> in core I would recommend that we would switch to using segwit as default in a subsiquent release after the SF activates.
11:05 < jonasschnelli> so have it ready and auto-use it whiteout creating another release?
11:06 < morcos> so in any case, i think we just advise wallet authors to wait some minimum amount of time after activation to send segwit txs.. they are already going to have to put in some code to wait until it activates
11:06 < jonasschnelli> *without
11:06 < CodeShark> either wait until next release - or wait a few blocks after activation before enabling it in wallet
11:06 < sipa> ok
11:06 < jonasschnelli> auto-enable in in the wallet after 95%?
11:06 < gmaxwell> no.
11:06 < btcdrak> I think better to wait a release code afterwards
11:06 < sipa> not even at 100%
11:07 < jonasschnelli> Okay. Then do it over the release-cycle..
11:07 < gmaxwell> I recommend using a release. Automatic behavior is not needed here. Also-- it's a pretty big behavioral change to use it, e.g. you'd be issuing other address styles in response.
11:07 < jonasschnelli> Agree.
11:07 < morcos> also we haven't written that code yet anyway
11:07 < sipa> that is an open question
11:07 < jonasschnelli> I just think there is a hight incentive to use it (fees)
11:07 < CodeShark> this is something that can be decided once segwit has already been deployed and is awaiting activation
11:07 < gmaxwell> having that triggered by invisible-to-the-user network behavior isn't reat.
11:08 < gmaxwell> great*
11:08 < sipa> i wish we had an address style for segwit part of the standard :(
11:08 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
11:09 < gmaxwell> sipa: no you don't. Deploying a new address style takes forever. :P what you wish for is a magic wand.
11:09 < btcdrak> sipa I thought we did? BIP142?
11:09 < CodeShark> btcdrak: we haven't been pushing it because of concerns regarding scary "new addresses"
11:09 < jonasschnelli> P2WPKH?
11:09 < morcos> i think we should do that though, otherwise everyone is going to embed them in p2sh which is kind of silly
11:09 < sipa> i think we have more buy-in from wallet authors about segwit now, than p2sh had at the timr
11:10 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has joined #bitcoin-core-dev
11:10 < CodeShark> p2sh was almost entirely under the radar as far as the community at large
11:10 < gmaxwell> also, continued use of base58 is awful. I am going to refuse to discuss address encodings with anyone who hasn't read an address to me over the phone. :)
11:10 < btcdrak> CodeShark: I would suggest brining it back. There's no problem.
11:10 < gmaxwell> CodeShark: thats not the case; besides there is a material difference in the sheer mass of code that must be updated. Besides why is this being discussed there.
11:11 < CodeShark> btcdrak: there sort of is a problem still...
11:11 < gmaxwell> btcdrak: I oppose it in the strongest possible terms.
11:11 < CodeShark> both internal and external
11:11 < btcdrak> CodeShark: you can change you mind :)
11:11 < CodeShark> internally some people hate base58, externally some people are still grandstanding with the "segwit is too hard" crap
11:11 < BlueMatt> gmaxwell: there is certain value in user expectations of things that look like base58
11:12 < CodeShark> I think it's a battle not worth fighting right now
11:12 < jonasschnelli> +1
11:12 < btcdrak> +1
11:12 < morcos> gmaxwell: whats your number
11:12 < jonasschnelli> haha
11:12 < gmaxwell> BlueMatt: You are on subject-matter-ignore until you call me and successfully read me a base58 address.  :)
11:13 < sipa> i would really like to have some psegwit afdressddress as part of the "package"
11:13 < gmaxwell> morcos: PM :P
11:13 < BlueMatt> gmaxwell: I'm not suggesting I'm necessarily in support of base58 addresses, but my point is that it is not up to us here to figure out addressing for segwit...that is something WALLETS need to be involved in...people who actually have some ux experience, which does not exist here
11:14 < morcos> gmaxwell: BlueMatt says "..."
11:14 < gmaxwell> yes indeed. but thats also why taking on a new address type at the same time is not a good idea, it would get in the way of that kind of collaboration.
11:14 < gmaxwell> hahha
11:14 < BlueMatt> agreed
11:14 < sipa> do you think so?
11:14 < sipa> i think it's the opposite
11:14 < BlueMatt> I think the idea of pushing off address types for segwit for broader feedback is a good thing
11:14 < Luke-Jr> sipa: that was a lot of backspaces.
11:15 < CodeShark> good UI design wouldn't even burden users with having to deal with copy/pasting cryptographic keys
11:15 < CodeShark> but that's an entirely separate discussion
11:15 < Luke-Jr> FWIW, I've been thinking of implementing the payment protocol better in Core
11:15 < Luke-Jr> including the new BIP 75 stuff
11:15 < jonasschnelli> We are far away from designing the UX... this is a topic we can talk about in 2-3 years.
11:16 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
11:16 < sipa> :)
11:16 < jonasschnelli> But sipa: is the P2WPKH address type not okay?,.. addresses like "p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm"?
11:16 < sipa> ok, let's postpone that address discussion
11:16 < sipa> jonasschnelli: you mean bip142?
11:17 < jonasschnelli> Yes. Easy to handle by existing wallets?
11:17 < BlueMatt> jonasschnelli: ACK
11:17 < gmaxwell> sipa was raising the concern that if something weren't done sooner we'd be left stuck with 80 bit security forever, I reminded him in PM that we have an upcoming checksig improvement to reduce transaction sizes by 30% which would be a nice time to do a new address type too. :) 
11:17 < wumpus> would be good to have concrete proposals for address formats ,say as BIPs
11:17 < CodeShark> we'll have plenty of opportunities to introduce new stuff in the future
11:18 < CodeShark> right now we should focus on the path of least resistance
11:18 < sipa> the reason against incorporating bip142 is people yelling "see! sehwit needs new address types! everyone has to upgrade! not backward compatible!"
11:18 < gmaxwell> The amount going on right now is too great to be able to afford forced seralization.
11:18 < CodeShark> eventually my hope is we'll actually have a competent ecosystem that can actually do tech
11:18 < CodeShark> but for now we must deal with what we have
11:18 < morcos> Yeah I think it would make a lot of sense to release just the P2WPKH address
11:18 < Luke-Jr> sipa: we could add sending support, and discourage anyone from using it to receive for now
11:18 < jonasschnelli> sipa: You could still uses it over P2SH... but we don't live for the critics.
11:18 < morcos> sipa: don't you think everyone is going to say that even more if we don't have address types
11:19 < sipa> i don't know
11:19 < sipa> i'm an engineer, not a marketer
11:19 < jonasschnelli> +1 for P2WPKH bip142
11:19 < wumpus> shouldn't be expected from you to act as marketeer sipa
11:19 < wumpus> you have enough on your plate
11:19 < sipa> next topic?
11:20 < CodeShark> yes please
11:20 < wumpus> suggestions?
11:20 < Luke-Jr> (I don't see value in p2wpkh, but let's move on)
11:21 < wumpus> ok, if not, that was a quick meeting
11:21 < gmaxwell> there were many things last week that got cut off.
11:21 < wumpus> (I'm still too tired and jetlaggy to contribute much now)
11:21 < jonasschnelli> If no one has something important... what do you think about my approach of IBD with a pregenerated signed UTXOset?
11:21 < btcdrak> Can I ask people to review the backport PRs for BIP68 and 112? They were straight cherry-picks into 0.12 but they do need a couple eyes on them.
11:22 < morcos> jonasschnelli: i think thats a bad idea
11:22 < Luke-Jr> jonasschnelli: sounds like a waste of time at best, to be frank. :x
11:22 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev
11:22 < wumpus> #action review backport PRs for BIP68 and 112
11:22 < morcos> jonasschnelli: core devs (or anybody for that matter) should not be authorizing the state of the ledger at any time
11:22 < wumpus> #topic IBD with a pregenerated signed UTXOse
11:22 < wumpus> it's risky, it brings trust into the system
11:22 < Luke-Jr> much prefer to see SPV mode until IBD completes
11:23 < jonasschnelli> Luke-Jr: Yes. Agree.
11:23 < wumpus> who would you trust to sign something like that? 
11:23 < sipa> Bob.
11:23 < jonasschnelli> Just thought we might want to reduce the amount of block-serving even more.
11:23 < wumpus> yes, definitely Bob
11:23 < Luke-Jr> XD
11:23 < jonasschnelli> wumpus: could be signed by the same users/devs who are signing the gitian builds.
11:24 < sipa> jonasschnelli: that's not reducing block serving; it's changing the trust model instead
11:24 < jonasschnelli> I agree. It does change the trust model.
11:24 < wumpus> jonasschnelli: hmm don't put too much on their shoulders
11:24 < CodeShark> without TXO commitments it's unfixable
11:24 < CodeShark> :p
11:24 < morcos> if we go back to the backport question, we also need to backport all these SF's to 0.11 is that correct?
11:24 -!- shawnmaten [~shawnmate@104.236.230.75] has joined #bitcoin-core-dev
11:24 < jonasschnelli> Okay... so. Then let me not implement it. :)
11:25 < wumpus> yea, UTXO commitments would make this somewhat more realistic, although it'd still reduce the overall trust model to SPV
11:25 < wumpus> jonasschnelli: yes, better not for now I think
11:25 < wumpus> #topic backports to 0.11
11:25 -!- cocoBTC [~cocoBTC__@c-d73a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has joined #bitcoin-core-dev
11:25 < gmaxwell> morcos: I was thinking about this this morning. The normal release cadance would have us do so, I believe.
11:25 < jonasschnelli> SPV during IBD and a throttled(CPU) IBD is the better approach.
11:26 < wumpus> jonasschnelli: yes, definitely those would be good to have
11:26 < Luke-Jr> how practical is it to backport to 0.10?
11:26 < warren> why 0.10?
11:26 < wumpus> topic is backport to 0.11 Luke-Jr :p 
11:26 < sipa> 0.10 and 0.11 are close
11:26 < morcos> 0.10?  i'd hoped you guys would be willing to skip 0.11
11:26 < sipa> but agree; just 0.11
11:26 < btcdrak> morcos: I would skip 0.11 
11:26 < sipa> we have a published release schedule, no?
11:26 < wumpus> I think backporting to 0.11 is fairly necessary, that's only one release back
11:26 < Luke-Jr> sipa: of guaranteed support, not limited-to
11:27 < Luke-Jr> 0.11 is necessary; 0.10 would be ideal
11:27 < morcos> wumpus: i suppose, i'm worried about how well tested these major changes will be
11:27 < sipa> master, 0.12, 0.11
11:27 < Luke-Jr> but I'll deal with 0.10 later I guess
11:27 < jonasschnelli> 0.10 is not necessary... we once agree in supporting only two major versions.
11:27 < btcdrak> sipa: our lifecycle doc is at https://bitcoincore.org/en/lifecycle/
11:28 < Luke-Jr> jonasschnelli: it was never agreed to drop support for older ones, only to not promise support for them; but that's on me for 0.10 I think
11:28 < wumpus> morcos: it's a challenge, but I think you can't get around it, some people won't be ready yet to upgrade to 0.12
11:28 < btcdrak> the backports to 0.12 are trivial, but 0.11 will be a little more annoying, especially for BIP68 I believe
11:29 < morcos> btcdrak: we should just backport them kind of altogether right?
11:29 < btcdrak> btw the backports for BIP68,112 are #7543 and #7544, I forgot to mention the numbers earlier
11:29 < morcos> i suppose they don't overlap that much
11:29 < morcos> i think i can make sure BIP68 for 0.11 backports properly
11:30 < btcdrak> morcos: you'd be the best person to backport BIP68 to 0.11.
11:30 < morcos> i will take the approach of not keeping the mempool consistent and checking sequence values in the mining code, which will probably not make much of an effect on the already absurdly slow mining code
11:30 < morcos> thats why 7187 was separate, that won't be backported to 0.11
11:30 < btcdrak> morcos: plenty miners have upgraded to 0.12 fwiw
11:30 < btcdrak> well pools*
11:31 < morcos> ok. i'll work on that
11:31 < wumpus> the other path would be to wait for 0.13, then only backport to 0.12, but then you'll have to wait 6 months :p
11:31 < Luke-Jr> >_<
11:31 < btcdrak> wumpus: nice joke there :-P
11:31 < wumpus> well not exactly 6 anymore but ok...
11:32 < wumpus> I don't think it's realistic no
11:32 < sipa> i think we can do 9/68/112/113 soon
11:32 < wumpus> aim for 0.13 would be july
11:33 < morcos> sipa: agreed!
11:33 < wumpus> sipa: I hope so!
11:33 < btcdrak> sipa: I also believe so. 68/112/113 are done from my side, morcos wants to add more RPC tests which is fine.
11:33 < morcos> did you ever reply to my comment on block version = 4  
11:33 < morcos> btcdrak: there are NONE!
11:33 < CodeShark> any plans to remove the default version crap out of primitives?
11:33 < btcdrak> morcos: yes there are. same standard as for BIP65
11:33 < sipa> CodeShark: yes, see bip9
11:34 < sipa> morcos: it was needed in combination with the warning logic
11:34 < btcdrak> morcos: see #7648
11:34 < sipa> it may not be needed anymore with imoroved logic
11:34 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
11:34 < morcos> btcdrak: i saw, and i agree, BIP65 made it out withotu adequate tests
11:35 < sdaftuar> sipa: right now #7575 will revert back to version 4 blocks after the first soft fork activates, if no other soft forks are in the queue
11:35 < jonasschnelli> bip65 had rpc tests from petertodd?!
11:35 < sdaftuar> i assume that is unintentional?
11:35 < btcdrak> morcos: I would disagree they were not adaquet, you can always have more sure.
11:35 < btcdrak> bip65 had RPC tests.
11:35 < sipa> sdaftuar: that seems correct to mr
11:35 < sdaftuar> oh, i didn't realize that!
11:35 < morcos> sipa: huh?  correct as in you wanted that?
11:36 < sipa> the old version is used to indicate "no versionbits"
11:36 < btcdrak> bip68/112/113 have the p2p RPC tests in #7648
11:36 < sipa> morcos: yes, otherwise the version is ambiguous based on what software miners use, ignoring deploymemts
11:36 < sipa> which the warning logic can't deal with
11:36 < sipa> it must be absolute "these deployments -> this nVersion"
11:37 < morcos> sipa: all prior soft forks required minors to upgrade
11:37 < sipa> miners :p
11:37 < btcdrak> lol
11:37 < CodeShark> minors can always get a fake ID
11:37 < morcos> sipa: what i would like to do is with this first soft fork, require nVersion > 4
11:37 < sipa> why?
11:37 < btcdrak> morcos: why?
11:37 < morcos> then we can warn on anything that is not 001...  unless it is <=4 which we know are invalid
11:38 < morcos> that seems consistent with how we've done other soft forks
11:38 < morcos> there is an expected version number, unknown differences are warned on
11:38 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-core-dev
11:38 < gmaxwell> so old software versions warn.
11:38 < gmaxwell> and continue warning.
11:38 -!- Adiabat [~tx@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev
11:38 < morcos> gmaxwell: yes, old software versions are incapable of noticing transient changes
11:39 < morcos> thats why we need to rework alerts/warning to correctly identify them now
11:39 < morcos> in fact if you turned off a 0.12 node for a couple months
11:39 < morcos> and then turned it back on after all these SF's activated
11:39 < morcos> you would have no idea
11:39 < morcos> even if you looked at your debug logs
11:39 < morcos> b/c the warning logic doesn't run in IBD
11:40 < morcos> i feel like that makes it a requirement that we permanently increase the version number
11:40 < sdaftuar> agreed
11:40 < sipa> wth are you talking about?
11:40 < morcos> who?
11:41 < CodeShark> I don't follow
11:41 < morcos> me?  which part?
11:41 < sipa> versionbits is deterministic based on the chain histotu
11:41 < morcos> yes 0.12 doesn't have version bits
11:41 < morcos> 0.12.0
11:41 < CodeShark> after versionbits deployment, all block versions would be > 4
11:41 < sipa> ah
11:41 < gmaxwell> sipa: he's talking about software which doesn't have versionbits.
11:41 < sipa> oh, now i get it
11:41 < sipa> sorry
11:41 < morcos> CodeShark: thats what i'm trying to say, thats not how its written
11:42 < sipa> so increase to 5 after the first vb deployment?
11:42 < morcos> no no no
11:42 < sdaftuar> why not increase to 001...?
11:42 < morcos> not 5
11:42 < sdaftuar> consensus rule is >= 5 i guess
11:42 < morcos> just > 4, but you expect to see 001
11:43 < sipa> consensus >=4, but by default set 001...000....?
11:43 < morcos> >4
11:43 < morcos> yes
11:43 < jonasschnelli> morcos: but you should see it in the debug log? https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2464
11:44 < jonasschnelli> Agree that we should also warn in IDB (but low prio IMO).
11:44 < sdaftuar> jonasschnelli: that code doesn't run during initialblockdownload
11:44 < morcos> the assumption is if you see something that starts with 001 you think you know whats happening and you're unknown activation detector can alert you with specific information
11:44 < jonasschnelli> Then lets improve that and BP.
11:44 < morcos> and if you see soemthing that doesn't start with 001  such as a 5  or  a 110... 
11:45 < morcos> jonasschnelli: thats what we're doing , but we can't retroactively change old code
11:45 < CodeShark> 110... would be treated as negative, no? because for some reason signed types were used
11:45 < morcos> then you assume that someone is doing something you really don't understand 
11:45 < jonasschnelli> Yes. Sure... we might not be capable of warning for the next SF.
11:45 < morcos> CodeShark: sure i mean 010 
11:45 < btcdrak> morcos: there is already 011 on the network too
11:46 < morcos> btcdrak: exactly, and we should be warning about that (and we are now) b/c its changes our software doesn't understand
11:46 < btcdrak> right
11:46 < morcos> and if > 50/100 blocks then we turn that warning into an alert
11:47 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
11:47 < jonasschnelli> Agree. But that raises also the question how to deploy an alert... debug.log? Yes. No.
11:48 < morcos> jonasschnelli: see scroll back before meeting
11:48  * jonasschnelli has only a 500 lines scrollback >_<
11:48 < morcos> sipa: so agreed that we should increase version number?  should i make a new BIP for that?  and we'll just soft fork it in at same time, or add to existing BIP
11:49 < sipa> morcos: consensus or not?
11:49 < morcos> sipa: consensus rule that nVersion must be >= 5.
11:50 < sipa> morcos: why consensus?
11:50 < btcdrak> morcos: confused
11:51 < CodeShark> before or after versionbits activation?
11:51 < CodeShark> still don't follow
11:51 < morcos> sipa: well i suppose it doesn't have to be a consensus rule... 
11:51 < morcos> CodeShark: with the first SF that activates
11:51 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 268 seconds]
11:51 < morcos> sipa: but i think its more clear to me that it doesn't have problems if it is a consensus rule
11:51 < morcos> b/c thats how the other ones worked
11:51 < gmaxwell> making it consensus would cause gratitious orphaning, which we were generally trying to avoid in the design of segwit.
11:51 < morcos> gmaxwell: this will be before segwit
11:52 < sipa> i prefer not introducing new consensus logic, especially when the only argument for it is better guarantees for warnings
11:52 < morcos> sipa: yes thats the only difference i see.  is that now we somehow can't warn on version = 4 blocks  
11:52 < sipa> and if it's not consnesus, we can say bip9 miners without active rollouts use 001000...
11:53 < gmaxwell> I like 001000 in that it would encourage visualization tools to parse the bitfield instead of just displaying an integer.
11:53 < btcdrak> yes
11:53 < morcos> sipa: if its not a consensus rule, you can't be SURE that old nodes will be warned that the rules have changed... perhaps thats not worth worrying about
11:54 < sipa> miners can already cause total network forks
11:54 < btcdrak> That was my initial understanding that the new version would be 00100..0 when no sfs are being deployed
11:54 < morcos> its just cleaner to me
11:54 < sipa> are we worried that they can bypass a warning mechanism?
11:54 < btcdrak> sipa: no
11:56 -!- mm_1 [bnc33@bnc33.nitrado.net] has joined #bitcoin-core-dev
11:56 < morcos> sipa: ok i guess. i'm ok with not making it a consensus rule..  but just seems weird to me...  i feel like we're transitioning from an old system to a new system, and the transition should conform to the old system
11:57 < gmaxwell> Lets wrap the metting now and talk more about warning after. Unless there are any other subject to squeek in at the end?
11:57 < wumpus> meeting: 3 minutes to go
11:57 < morcos> but as long as we make the default 00100  then i think its just theoretical concerns
11:57 < sipa> yeah
11:58 < wumpus> #endmeeting
11:58 < lightningbot> Meeting ended Thu Mar 10 19:58:17 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
11:58 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.html
11:58 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.txt
11:58 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-03-10-18.59.log.html
11:59 < kanzure> #action review scrollback
11:59 < sipa> haha
11:59 < btcdrak> haha
11:59 < btcdrak> that was a really long meeting...
11:59 < gmaxwell> sipa: So a concern I raised on the PR is that I'd like nodes to stop mining (e.g. error on GBT results) after a SW upgrade happens. The issue I'm trying to address is say the network successfully upgrades, and then a couple huge pools reboot and end up on pre softfork code-- e.g. bootscripts start the wrong versions; things run happily for a while, but then someone mines an invalid transaction a
12:00 < gmaxwell> nd then a huge amount of hashpower begins a fork.  Nversion progression previously prevented this, but at the expense of creating gratitious orphans around the switchover time.
12:00 < morcos> gmaxwell: i was wondering about that, but do miners change their version number outside of bitcoind anyway?
12:01 < gmaxwell> morcos: in the past some mining hardware had hardcoded versions numbers, but I think the last couple softforks probably shook out a fair amount of that.
12:01 < sipa> we hope...
12:01 < morcos> gmaxwell: so this is another reason to make >= 5 a consensus rule
12:01 < Luke-Jr> morcos: they set it outside bitcoind generally
12:01 < morcos> if you don't you can't fix that problem for 0.12.0 miners
12:01 < sipa> how does that help?
12:02 < gmaxwell> sipa: the idea is that post SW miners would do the voluntarily shut off unless overridden. 
12:03 < morcos> sipa: well i don't know.  i took gmaxwell's scenario at face value.. but maybe it doesn't make sense.  i guess the difference is whether you find out right away or not?
12:03 < gmaxwell> It's a difference in the size of the fork; and who takes the risks.
12:03 < morcos> gmaxwell: are you specficially talking about SW script upgrades?  or do you mean BIP 9 soft forks?
12:03 < gmaxwell> BIP9 softforks.
12:04 < morcos> gmaxwell: can you explain a bit why the fork size would be bigger?
12:04 < sipa> if the vereion number is set outside of bitcoim core, then logic there won't help
12:04 < sipa> you just need logic that stops GBT in case the vb warning logic triggered
12:04 -!- shawnmaten [~shawnmate@104.236.230.75] has left #bitcoin-core-dev ["undefined"]
12:05 < morcos> that seems a bit risky to me to automatically stop GBT
12:05 < gmaxwell> morcos: Because only an exceptional circumstance would begin such a fork, it might happen months or years after the change, with no one paying attention.
12:05 < morcos> i mean i guess it does take 95% of miners to cause a fake trigger
12:06 < gmaxwell> morcos: the existing warning stuff is stupid, boarderline broken-- which is why I was suggesting it only for BIP9 activation.
12:07 < jonasschnelli> Is https://github.com/sipa/bitcoin/tree/segwit still the most recent segnet working tree?
12:07 < jonasschnelli> BTW: how changes the https://github.com/bitcoin icon? Nice one!
12:07 < jonasschnelli> *who
12:07 < jonasschnelli> *changed (damit)
12:07 < gmaxwell> morcos: the idea that the network in bulk could silently regress rules (though detectable by the nodes themselves) concerns me; but I don't know how much of a pratical concern it should be.
12:09 < morcos> gmaxwell: the fact that nVersion is set outside bitcoind is disturbing, but imagine 1% of miners don't upgrade to versionbits and the 68/112/113 soft fork
12:09 < morcos> they will happily mine version 4 blocks for months until they accidentally mine an invalid BIP68 tx, and then all the SPV miners will just build off them
12:10 < morcos> as opposed to htat thing happening right away if the nVersion had to increase
12:10  * Luke-Jr wonders if versionbits has GBT extensions yet
12:12 < sipa> Luke-Jr: is it not enough to report nVersionm
12:12 < sipa> ?
12:12 < gmaxwell> morcos: right, so two questions: avoiding that for this one change vs in the long term.
12:12 < Luke-Jr> sipa: no, because nVersion could mean different things
12:12 < morcos> gmaxwell: yes, i agree that perhaps your long term change makes sense
12:13 < sdaftuar> gmaxwell: morcos: seems to me like we should do both things you guys are suggesting
12:13 < morcos> i mean your change now to solve the longer term problem
12:13 < sipa> Luke-Jr: ?
12:13 < Luke-Jr> sipa: version=69632 could mean different softforks depending on context of the block
12:13 < sipa> so?
12:14 < gmaxwell> morcos: in the long term I think it's adequate to refuse to serve GBT requests after a BIP9 activiation triggers. (and perhaps mine only empty blocks during the quiet period for further visibility)
12:14 < gmaxwell> sipa: matters if you're adding additional txn to the gbt output.
12:14 < Luke-Jr> sipa: so the GBT client won't know which softforks to enable
12:14 < gmaxwell> morcos: for the current issue, I agree that an upgrade to >=5 may be needed.
12:14 < sipa> Luke-Jr: nobody is doing that, right?
12:15 < gmaxwell> Luke-Jr: I think you actually want to expose the mempool validation flags in GBT for that, not just softforks.
12:15 < Luke-Jr> sipa: adding transactions, not at the moment AFAIK, but GBT clients always must be aware of what the block rules are to some extent
12:15 < sdaftuar> note that the version bits do not indicate what the consensus rules are
12:15 < sipa> Luke-Jr: i guess those can be per-softfork extensions to GBT
12:16 < sipa> as their effects can be hard to generalize
12:16 < Luke-Jr> sipa: some way to indicate them is still needed, but yes
12:16 < Luke-Jr> ie, we don't want old GBT clients to think they can handle bit X, but interpret it differently
12:17 < morcos> Luke-Jr: any time you are setting bit X it by definition means that soft fork isn't even active yet
12:17 < morcos> or at least by implementation
12:18 < Luke-Jr> more likely the GBT client would be the side setting the bits it implements
12:20 < gmaxwell> Luke-Jr: trying to move network consensus logic into gbt clients seems inadvisible and should only be done where strictly needed.
12:22 < sipa> gmaxwell: +1
12:25 < BlueMatt> instead we should be pulling out as MUCH logic as possible from gbt clients/pool servers into bitcoind
12:25 < BlueMatt> and also kill getblocktemplate
12:25 < BlueMatt> because no one uses it and everyone hates it
12:29 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:30 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:31 < gmaxwell> BlueMatt: so mean. By "kill" you mean "optimize".
12:31 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:31 < BlueMatt> gmaxwell: I mean replace entirely
12:31 < sipa> making it observable what is being mined makes sense
12:31 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:31 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:32 < BlueMatt> gmaxwell: no one cares about the features provided by gbt, and every time I talk to /anyone/ using it (except eloipool) the response is "omg, just replace it with a binary something-or-other that has nearly opposite features of what gbt provides"
12:32 < sipa> but i don't think GBT's goal should be letting block construction outside of bitcoind
12:32 < BlueMatt> ^that
12:32 < BlueMatt> is also what people want
12:32 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:32 < BlueMatt> most folks just want the minimal data they need to be able to twiddle extranonce
12:32 < gmaxwell> if the nonce in header fork were done we could go back to getwork. :)
12:32 < BlueMatt> and that
12:33 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:36 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:37 < btcdrak> BlueMatt: is there any more progress on HF contents? 
12:38 < BlueMatt> btcdrak: I havent seen anything on bitcoin-dev?
12:38 < BlueMatt> btcdrak: also #bitcoin-dev
12:38 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:39 < Luke-Jr> sipa: so just give up on decentralised mining entirely?
12:39 < BlueMatt> Luke-Jr: that is a false dichotomy
12:39 < gmaxwell> there are other ways to do that, e.g. telling bitcoind what the requirements are for a block it creates and letting it create it.
12:39 < BlueMatt> Luke-Jr: the amount of data you need to twiddle the extranonce is almost the same as the amount of data you need to create a coinbase for gbt in the same way you want people to do decentralized mining
12:39 < gmaxwell> E.g. coinbase must pay to X.
12:40 < BlueMatt> gmaxwell: you can create the coinbase downstream of bitcoind
12:40 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:40 < gmaxwell> only by implementing consensus rules outside of bitcoind, however.
12:40 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:40 < BlueMatt> bitcoind should be able to tell you things like requirements for what scriptSig should look like
12:40 < gmaxwell> BlueMatt: you are reinventing GBT. :)
12:40 < Luke-Jr> gmaxwell: this is higher latency
12:41 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:41 < BlueMatt> gmaxwell: no, gbt gives you all kinds of shit like details for every transaction in the block
12:41 < BlueMatt> you should only be providing minimal merkle tree info
12:41 < gmaxwell> BlueMatt: which is actually needed if you're building your own coinbase, because you may need to drop out transactions to make room.
12:41 < BlueMatt> gmaxwell: also, phantomcircuit has a protocol designed for this
12:41 < BlueMatt> that is pretty minimal
12:41 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:42 < BlueMatt> gmaxwell: "meh", your coinbase shouldnt be /that/ large
12:42 < gmaxwell> go look at a p2pool coinbase txn.
12:42 < BlueMatt> I'm aware
12:43 -!- Eliel [~jojkaart@91-159-8-128.elisa-laajakaista.fi] has quit [Ping timeout: 244 seconds]
12:43 < BlueMatt> ehh, whatever, fine, give bitcoind a coinbase output list
12:43 < BlueMatt> either way, push complexity into bitcoind :)
12:43  * Luke-Jr notes that's the approach he took originally and gave up after years of it not being merged.
12:43 < morcos> i know nothing about mining, so hopefully im not wasting peoples time
12:44 < morcos> but it seems to me that it would be reasonable to require miners to run a bitcoind
12:44 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:44  * gmaxwell plays taps for 'coinbaser'
12:44 < morcos> and we should provide an API by which they can submit a block to to a pool and say hey, is this acceptable
12:44 < morcos> and then they can work on that
12:44 < morcos> i know thats the idea behind GBT (sort of)
12:44 < morcos> but instead of building all the functionality into the API
12:44 < BlueMatt> Luke-Jr: to be fair, people also hate json, so need something outside the existing rpc
12:45 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:45 < Luke-Jr> BlueMatt: it wasn't via RPC ;)
12:45 < BlueMatt> hmm, fair enough
12:45 < morcos> just have a testBlock RPC call that the pool can say, yeah thats cool pays the right coinbase or whatever and is valid according to our consensus rules
12:45 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:46 < Luke-Jr> preferably there'd be a way to avoid sending the entire gen-tx around.
12:46 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:46 < BlueMatt> Luke-Jr: so revive it now :)
12:46 < Luke-Jr> BlueMatt: ?
12:46 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
12:47 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:47 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
12:47 < Luke-Jr> not sure the point
12:53 < jtimon> sipa morcos, what about always producing 0010... (even when no deployments are being checked) after the the starttime of the first deployment? (my own solution was to just do it right away for new miners, even before any start time, but sipa complained that old nodes would get warnings before start time [they're going to receive warnings before activation anyway, so I wasn't too concerned about that])
12:53 -!- Eliel [~jojkaart@91-159-8-128.elisa-laajakaista.fi] has joined #bitcoin-core-dev
12:53 < morcos> jtimon: yeah i think its strictly better for the old nodes to get the warnings earlier
12:53 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
12:54 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
12:54 < jtimon> that was my point, the dicsussion is there in some outdated comment in #7575
12:54 -!- jgarzik [~jgarzik@220.sub-70-193-164.myvzw.com] has joined #bitcoin-core-dev
12:54 -!- jgarzik [~jgarzik@220.sub-70-193-164.myvzw.com] has quit [Changing host]
12:54 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
12:55 < jtimon> and that solution doesn't require any additional consensus checks, which seems to be what people dislike more from your proposal
12:59 -!- e0_ [~e0@cs10-dhcp127.bu.edu] has joined #bitcoin-core-dev
12:59 < e0_> The variables  pathCached and pathCachedNetSpecific in util.cpp appears to be unused (find doesn't return any results of them being set) but can cause interesting segfaults since depending on the order in which objects are created they can be uninitialized.  Are they actually unused
12:59 < e0_> [3:38] 
12:59 < e0_> ?
12:59 < e0_> https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp#L485
12:59 < e0_> I have a pull request, but I don't want to waste peoples time in case I am missing something
13:00 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
13:01 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
13:04 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
13:12 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
13:14 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection]
13:18 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
13:23 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
13:25 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
13:26 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
13:57 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
14:04 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Ping timeout: 276 seconds]
14:12 -!- mrkent_ [~textual@unaffiliated/mrkent] has joined #bitcoin-core-dev
14:14 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
14:14 -!- mrkent [~textual@unaffiliated/mrkent] has quit [Ping timeout: 260 seconds]
14:29 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
14:35 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
14:47 -!- zooko [~user@50.141.119.23] has joined #bitcoin-core-dev
14:55 -!- lahwran is now known as lauren
15:11 < dgenr8> 144*365
15:15 -!- Adiabat [~tx@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Ping timeout: 252 seconds]
15:17 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection]
15:20 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving]
15:21 -!- musalbas [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
15:22 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
15:22 -!- musalbas [~musalbas@2001:bc8:30c2::] has left #bitcoin-core-dev ["Leaving"]
15:22 -!- musalbas [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev
15:26 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
15:48 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
15:49 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
16:02 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has left #bitcoin-core-dev []
16:02 -!- kangx_ [42d7ee99@gateway/web/freenode/ip.66.215.238.153] has quit [Quit: Page closed]
16:03 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
16:05 -!- cocoBTC [~cocoBTC__@c-d73a71d5.136-1-64736c10.cust.bredbandsbolaget.se] has quit [Remote host closed the connection]
16:17 -!- belcher [~user@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]
16:25 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
16:32 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Quit: Reconnecting]
16:32 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
16:34 -!- btcbandit [~02@107.150.94.3] has joined #bitcoin-core-dev
16:37 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
16:47 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has quit [Quit: ChatZilla 0.9.92 [Firefox 44.0.2/20160210153822]]
16:50 < achow101> Is there any way in Bitcoin Core to mine to a specific address when in regtest mode?
17:07 -!- zooko [~user@50.141.119.23] has quit [Ping timeout: 252 seconds]
17:11 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
17:13 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
17:30 -!- btcbandit [~02@107.150.94.3] has quit [Ping timeout: 246 seconds]
17:44 -!- btcbandit [~02@107.150.94.3] has joined #bitcoin-core-dev
17:45 < warren> achow101: you can construct a valid block outside of core and submit it
17:48 -!- btcbandit [~02@107.150.94.3] has quit [Ping timeout: 244 seconds]
17:51 -!- p15 [~p15@6.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
17:57 < achow101> warren: I suppose I could do that, but that just make things annoying since this is just for rpc tests for Armory. Do you know if the Bitcoin Core rpc tests have mining implmented in them? If so I can just borrow that
17:58 < gmaxwell> achow101: import the key it choses into armory? hm. we could make the generate take an option for the output, I guess. it seems like a reasonable request.
17:59 < achow101> warren: can't import the key since armory doesn't accept compressed keys yet.
18:00 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Ping timeout: 246 seconds]
18:00 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rxylxvosbtclpvch] has quit [Quit: Connection closed for inactivity]
18:01 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
18:07 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
18:09 < achow101> well it looks like the rpc tests do have regtest mining stuff there, but I'm not sure that it will work well with not being in the Bitcoin Core project. 
18:14 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
18:29 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 248 seconds]
18:33 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:48 -!- mrkent_ [~textual@unaffiliated/mrkent] has quit []
19:14 -!- Tasoshi [~Tasoshi@unaffiliated/tasoshi] has quit [Read error: Connection reset by peer]
19:15 -!- zooko [~user@50.141.118.215] has joined #bitcoin-core-dev
19:24 -!- wangchun_ [~wangchun@li414-193.members.linode.com] has joined #bitcoin-core-dev
19:27 -!- wump [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev
19:30 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
19:30 -!- ebfull [~sean@73.34.119.0] has quit [Ping timeout: 260 seconds]
19:30 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 260 seconds]
19:30 -!- wangchun [~wangchun@li414-193.members.linode.com] has quit [Ping timeout: 260 seconds]
19:30 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Ping timeout: 260 seconds]
19:30 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
19:30 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has joined #bitcoin-core-dev
19:38 -!- achow101 [~achow101@pool-96-227-114-115.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer]
19:38 -!- jarret [~jarret@162.216.46.151] has quit [Quit: Leaving]
19:50 -!- jarret [~jarret@162.216.46.151] has joined #bitcoin-core-dev
19:53 -!- zooko` [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
19:53 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has joined #bitcoin-core-dev
19:54 -!- zooko [~user@50.141.118.215] has quit [Ping timeout: 260 seconds]
19:55 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
19:55 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
20:21 -!- PRab [~chatzilla@c-68-34-102-231.hsd1.mi.comcast.net] has joined #bitcoin-core-dev
20:28 -!- jgarzik [~jgarzik@unaffiliated/jgarzik] has quit [Ping timeout: 264 seconds]
20:28 -!- zooko` [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds]
20:43 -!- chris2000 [~chris2000@p54AE71A7.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds]
21:17 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:18 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:30 -!- Giszmo [~leo@pc-122-14-46-190.cm.vtr.net] has quit [Quit: Leaving.]
21:48 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 250 seconds]
21:49 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 276 seconds]
21:50 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
21:51 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 250 seconds]
21:51 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
21:56 -!- Netsplit *.net <-> *.split quits: anttea, NicolasDorier, CodeShark, Guest15994, cfields_
22:02 -!- ChillazZ [~ChillazZ@194.97.152.20] has joined #bitcoin-core-dev
22:02 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-mryabbrtgwhzoqmj] has joined #bitcoin-core-dev
22:02 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-yshridwmazkddgda] has joined #bitcoin-core-dev
22:02 -!- cfields_ [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev
22:02 -!- anttea [~anttea@a88-112-146-73.elisa-laajakaista.fi] has joined #bitcoin-core-dev
22:10 -!- skyraider [uid41097@gateway/web/irccloud.com/x-qhhryptwdfxknbga] has quit [Quit: Connection closed for inactivity]
22:10 -!- wump is now known as wumpus
22:16 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
22:28 -!- chris200_ [~chris2000@p5B3AAF26.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
22:44 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
22:53 -!- btcbandit [~02@107.150.94.3] has joined #bitcoin-core-dev
23:02 -!- btcbandit [~02@107.150.94.3] has quit [Ping timeout: 276 seconds]
23:06 -!- berndj [~berndj@azna.co.za] has quit [Ping timeout: 260 seconds]
23:10 -!- Netsplit *.net <-> *.split quits: anttea, NicolasDorier, CodeShark, cfields_, ChillazZ
23:13 -!- berndj [~berndj@azna.co.za] has joined #bitcoin-core-dev
23:20 < GitHub182> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c8d2473e6cb0...3da5d1bc2e5d
23:20 < GitHub182> bitcoin/master e219503 Wladimir J. van der Laan: Fix memleak in TorController [rework]...
23:20 < GitHub182> bitcoin/master 3da5d1b Wladimir J. van der Laan: Merge #7637: Fix memleak in TorController [rework]...
23:20 < GitHub152> [bitcoin] laanwj closed pull request #7637: Fix memleak in TorController [rework] (master...2016_03_torcontrol_leak) https://github.com/bitcoin/bitcoin/pull/7637
23:21 < GitHub46> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3da5d1bc2e5d...26a2a7214fe1
23:21 < GitHub46> bitcoin/master 8fc81e0 Wladimir J. van der Laan: mempool: Reduce ERROR logging for mempool rejects...
23:21 < GitHub46> bitcoin/master 26a2a72 Wladimir J. van der Laan: Merge #7592: mempool: Re-remove ERROR logging for mempool rejects...
23:21 < GitHub68> [bitcoin] laanwj closed pull request #7592: mempool: Re-remove ERROR logging for mempool rejects (master...2016_02_mempool_error_spam) https://github.com/bitcoin/bitcoin/pull/7592
23:21 -!- ChillazZ [~ChillazZ@194.97.152.20] has joined #bitcoin-core-dev
23:21 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-mryabbrtgwhzoqmj] has joined #bitcoin-core-dev
23:21 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-yshridwmazkddgda] has joined #bitcoin-core-dev
23:21 -!- cfields_ [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev
23:21 -!- anttea [~anttea@a88-112-146-73.elisa-laajakaista.fi] has joined #bitcoin-core-dev
23:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-ivufepvsjhzxwlar] has joined #bitcoin-core-dev
23:25 < GitHub32> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/26a2a7214fe1...9f14e5ad918d
23:25 < GitHub32> bitcoin/master 110b62f Patrick Strateman: Remove vfReachable and modify IsReachable to only use vfLimited....
23:25 < GitHub32> bitcoin/master 9f14e5a Wladimir J. van der Laan: Merge #7553: Remove vfReachable and modify IsReachable to only use vfLimited....
23:25 < GitHub55> [bitcoin] laanwj closed pull request #7553: Remove vfReachable and modify IsReachable to only use vfLimited. (master...2016-02-17-reachable) https://github.com/bitcoin/bitcoin/pull/7553
23:27 -!- btcbandit [~02@107.150.94.3] has joined #bitcoin-core-dev
23:30 < GitHub23> [bitcoin] laanwj closed pull request #7640: Removes forward slash (/) from user agent in peers tab UI. (master...master) https://github.com/bitcoin/bitcoin/pull/7640
23:39 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev
23:40 -!- frankenmint [~frankenmi@174-25-22-102.ptld.qwest.net] has quit [Remote host closed the connection]
23:41 < GitHub32> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9f14e5ad918d...86a1ec5b2c97
23:41 < GitHub32> bitcoin/master 72c2651 Jonas Schnelli: [Wallet] move wallet help string creation to CWallet
23:41 < GitHub32> bitcoin/master 86a1ec5 Wladimir J. van der Laan: Merge #7576: [Wallet] move wallet help string creation to CWallet...
23:41 < GitHub180> [bitcoin] laanwj closed pull request #7576: [Wallet] move wallet help string creation to CWallet (master...2016/02/wallet_helpstr) https://github.com/bitcoin/bitcoin/pull/7576
23:43 < GitHub33> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/86a1ec5b2c97...0fa88ef784dd
23:43 < GitHub33> bitcoin/master 2ab835a Elliot Olds: Check if zmq is installed in tests, update docs...
23:43 < GitHub33> bitcoin/master 0fa88ef Wladimir J. van der Laan: Merge #7635: [Documentation] Add dependency info to test docs...
23:43 < GitHub79> [bitcoin] laanwj closed pull request #7635: [Documentation] Add dependency info to test docs (master...docs4) https://github.com/bitcoin/bitcoin/pull/7635
23:45 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
23:47 -!- Netsplit *.net <-> *.split quits: anttea, NicolasDorier, CodeShark, cfields_, ChillazZ
23:53 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
23:54 -!- ChillazZ [~ChillazZ@194.97.152.20] has joined #bitcoin-core-dev
23:54 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-mryabbrtgwhzoqmj] has joined #bitcoin-core-dev
23:54 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-yshridwmazkddgda] has joined #bitcoin-core-dev
23:54 -!- cfields_ [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev
23:54 -!- anttea [~anttea@a88-112-146-73.elisa-laajakaista.fi] has joined #bitcoin-core-dev
23:57 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
23:57 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:58 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 276 seconds]