--- Day changed Tue Jan 19 2016
00:00 -!- wallet42 [~wallet42@98.147.125.124] has quit [Quit: Leaving.]
00:14 -!- wallet42 [~wallet42@cpe-98-150-152-189.hawaii.res.rr.com] has joined #bitcoin-core-dev
00:24 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Read error: No route to host]
00:24 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
00:42 < GitHub199> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/21376af183ff...668906fcf27b
00:42 < GitHub199> bitcoin/master fada0c9 MarcoFalke: [travis] Fail when documentation is outdated
00:42 < GitHub199> bitcoin/master faeda0e MarcoFalke: [travis] Run contrib/devtools/check-doc.py early
00:42 < GitHub199> bitcoin/master 668906f Wladimir J. van der Laan: Merge pull request #7280...
00:42 < GitHub66> [bitcoin] laanwj closed pull request #7280: [travis] Fail when documentation is outdated (master...MarcoFalke-2015-travisDoc) https://github.com/bitcoin/bitcoin/pull/7280
00:48 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
00:52 -!- ryitpm [~ryitpm@87.121.52.41] has quit [Remote host closed the connection]
00:54 -!- p15 [~p15@52.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 264 seconds]
01:00 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
01:07 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
01:09 -!- p15 [~p15@127.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
01:10 -!- T23WS [~textual@45.41.135.10] has joined #bitcoin-core-dev
01:15 < GitHub40> [bitcoin] laanwj opened pull request #7378: devtools: replace github-merge with python version (master...2016_01_python_github_merge) https://github.com/bitcoin/bitcoin/pull/7378
01:17 -!- wallet42 [~wallet42@cpe-98-150-152-189.hawaii.res.rr.com] has quit [Quit: Leaving.]
01:19 -!- wallet42 [~wallet42@98.150.152.189] has joined #bitcoin-core-dev
01:27 -!- wallet421 [~wallet42@98.150.152.189] has joined #bitcoin-core-dev
01:27 -!- wallet421 [~wallet42@98.150.152.189] has quit [Changing host]
01:27 -!- wallet421 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
01:27 -!- wallet42 is now known as Guest59729
01:27 -!- Guest59729 [~wallet42@98.150.152.189] has quit [Killed (weber.freenode.net (Nickname regained by services))]
01:27 -!- wallet421 is now known as wallet42
01:40 -!- blur3d [~blur3d@d114-78-45-177.rdl805.qld.optusnet.com.au] has joined #bitcoin-core-dev
01:59 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
02:17 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:21 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
02:21 -!- adnn_ [adnn@gateway/vpn/mullvad/x-kejkdkmomxrsvlsb] has quit [Ping timeout: 250 seconds]
02:41 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Quit: Leaving]
02:42 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
02:42 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
03:07 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
03:29 < GitHub178> [bitcoin] jtimon closed pull request #6597: Chainparams: Don't check the genesis block (master...chainparams-genesis-no-check-0.12.99) https://github.com/bitcoin/bitcoin/pull/6597
03:38 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
03:49 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
03:50 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Client Quit]
03:54 -!- drnet [~drnett@178.165.131.187.wireless.dyn.drei.com] has joined #bitcoin-core-dev
03:59 < GitHub134> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/668906fcf27b...3b43cad9d059
03:59 < GitHub134> bitcoin/master 39a525c ptschip: Do not download transactions during inital sync
03:59 < GitHub134> bitcoin/master 3b43cad Wladimir J. van der Laan: Merge pull request #7164: Do not download transactions during initial blockchain sync...
03:59 < GitHub58> [bitcoin] laanwj closed pull request #7164: Do not download transactions during initial blockchain sync (master...tx_getdata) https://github.com/bitcoin/bitcoin/pull/7164
04:00 -!- cjcj [82ebca3a@gateway/web/freenode/ip.130.235.202.58] has joined #bitcoin-core-dev
04:06 -!- blur3d [~blur3d@d114-78-45-177.rdl805.qld.optusnet.com.au] has quit [Quit: blur3d]
04:23 < GitHub104> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/3b43cad9d059...f9fd4c288484
04:23 < GitHub104> bitcoin/master fd83615 Peter Todd: Improve CheckInputs() comment about sig verification
04:23 < GitHub104> bitcoin/master f9fd4c2 Wladimir J. van der Laan: Merge pull request #7281: Improve CheckInputs() comment about sig verification...
04:23 < GitHub3> [bitcoin] laanwj closed pull request #7281: Improve CheckInputs() comment about sig verification (master...2016-01-improve-checkinputs-comment) https://github.com/bitcoin/bitcoin/pull/7281
04:27 < wumpus> sdaftuar: I'm not sure I quite understand why rbf.cpp should be part of the wallet - does it use any wallet functions?
04:29 < wumpus> I understand it's only used in the wallet, but having it in policy then linking it only into the wallet is a bit strange
04:29 < wumpus> cfields, what circular dependency is this? we should get rid of it 
04:30 < wumpus> come on, this linker behavior can't be so random we have to do something random to make a problem seem to go away
04:31 < wumpus> I'll take a look...
04:32 < wumpus> also I don't understand why github says #7222 has 'conflicts that need to be resolved', even though travis apparently builds it
04:36 < wumpus> I don't think server can depend on the wallet in any way, if we do a --disable-wallet build the wallet library won't even be built
04:42 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
04:47 < wumpus> oh it does - the problem is that the RPC calls for the wallet are referenced from libbitcoin_server. this may be solved by something like #7307, which moves the registration of the wallet RPC calls to the wallet itself
04:48 < wumpus> and that's only part of it, there are other parts of e.g. init.cpp which are part of the server and make direct calls into the wallet
04:50 < wumpus> basically, we need to get rid of all #ifdef ENABLE_WALLET code in bitcoin_server library
04:50 < wumpus> that's too much for 0.12 backport so I agree on sdaftuar 's intermediate "hack"
04:58 -!- jtimon [~quassel@126.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
04:58 -!- dayZh [~dayzh@220.191.5.100] has joined #bitcoin-core-dev
05:09 < sdaftuar> wumpus: thanks for taking a look.
05:09 < sdaftuar> wumpus: will look at the new merge conflicts (was clean when i last pushed)
05:10 < wumpus> oh sorry if I broke your pull
05:11 < wumpus> seems a conflict in listtransactions.py
05:11 < sdaftuar> yeah
05:11 < sdaftuar> hmm
05:12 < sdaftuar> oh yeah the mocktime thing
05:12 < sdaftuar> in #7164
05:12 < wumpus> yeah
05:14 < wumpus> should be easy to resolve
05:14 < wumpus> (add-add conflict)
05:14 < sdaftuar> yep agreed.
05:15 < sdaftuar> just want to make sure the 0.12 backport will be clean before i push
05:19 < sdaftuar> ok when i fix the issue and try to cherrypick to 0.12, i get a conflict to resolve.  it's easy to fix, but would it better to open a second PR for the 0.12 branch which is clean?
05:22 -!- wumpus [~wladimir@pdpc/supporter/professional/wumpus] has quit [Ping timeout: 260 seconds]
05:30 < sdaftuar> ah, if i just move my new method to further down in the file, then no conflict in 0.12.  i'll just do that for simplicity
05:40 -!- Chris_Stewart_5 [~Chris_Ste@173-26-115-141.client.mchsi.com] has joined #bitcoin-core-dev
05:46 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
05:47 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
05:51 -!- Chris_Stewart_5 [~Chris_Ste@173-26-115-141.client.mchsi.com] has quit [Ping timeout: 255 seconds]
05:52 -!- dayZh [~dayzh@220.191.5.100] has quit [Remote host closed the connection]
06:01 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
06:01 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
06:01 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
06:05 -!- wumpus [~wladimir@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev
06:05 -!- Chris_Stewart_5 [~Chris_Ste@108.61.228.104] has joined #bitcoin-core-dev
06:05 -!- bronzehedwick [~Adium@mskresolve-8.mskcc.org] has joined #bitcoin-core-dev
06:18 -!- dayZh [~dayzh@220.191.5.100] has joined #bitcoin-core-dev
06:30 -!- zookolaptop [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
06:37 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer]
06:38 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
06:41 -!- dayZh [~dayzh@220.191.5.100] has quit [Read error: Connection reset by peer]
06:41 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
06:45 -!- T23WS [~textual@45.41.135.10] has quit [Quit: Textual IRC Client: www.textualapp.com]
06:47 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
06:47 -!- bsm1175321 is now known as bsm117532
06:52 -!- ryitpm [~ryitpm@87.121.52.41] has joined #bitcoin-core-dev
06:53 < bsm117532> Is it possible to be invited to the bitcoincore slack channel?  Is relevant dev discussion happening there or is it essentially all here?
06:56 -!- bronzehedwick [~Adium@mskresolve-8.mskcc.org] has left #bitcoin-core-dev []
07:26 < michagogo> Slack?
07:32 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
07:35 < jonasschnelli> bitcoincore.slack.com (no invitation required)
07:41 < instagibbs> bsm117532, mostly a community outreach deal. CEOs, press, others actually idle there now
07:43 < bsm117532> Ok thanks
07:47 < bsm117532> instagibbs: It looks like I can't log into bitcoincore.slack.com without an invitation.  But not so concerned about it, the last thing I need is another chat I have to pay attention to!
07:47 < michagogo> What is that, who uses it, and what for?
07:48 < bsm117532> Let's just use IRC. ;-)
07:50 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
07:56 < instagibbs> michagogo, "mostly a community outreach deal. CEOs, press, others actually idle there now"
07:58 -!- Cory [~C@unaffiliated/cory] has quit []
08:00 -!- lpersona [63cfa628@gateway/web/freenode/ip.99.207.166.40] has quit [Ping timeout: 252 seconds]
08:00 -!- rsx [~dummy@host-188-174-216-181.customer.m-online.net] has joined #bitcoin-core-dev
08:05 -!- MarcoFalke [c3523fc9@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.201] has joined #bitcoin-core-dev
08:05 -!- dayZh [~dayzh@122.233.243.136] has quit [Remote host closed the connection]
08:05 -!- T23WS [~textual@210-20-183-152.rev.home.ne.jp] has joined #bitcoin-core-dev
08:05 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
08:10 -!- dayZh [~dayzh@122.233.243.136] has quit [Ping timeout: 265 seconds]
08:12 -!- T23WS [~textual@210-20-183-152.rev.home.ne.jp] has quit [Ping timeout: 245 seconds]
08:19 -!- JackH [~Jack@host-80-43-141-112.as13285.net] has joined #bitcoin-core-dev
08:21 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 276 seconds]
08:24 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 264 seconds]
08:29 -!- ronbo [~ronbo@c-73-30-230-54.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
08:30 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
08:34 -!- drnet [~drnett@178.165.131.187.wireless.dyn.drei.com] has quit [Quit: Leaving]
08:37 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
08:42 < btcdrak> bsm117532: you can get an invitation from https://slack.bitcoincore.org
08:42 -!- xiangfu [~xiangfu@xd9bad2d1.dyn.telefonica.de] has joined #bitcoin-core-dev
08:43 < btcdrak> instagibbs: it's also for Bitcoin Core community to gather
08:43 < btcdrak> it's not a replacement for IRC or developer collaboration though, that remains in IRC.
08:43 < instagibbs> ^^ that's what I meant
08:46 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
08:47 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
08:49 < bsm117532> Thanks btcdrak.  Looked briefly, this looks like it's probably about as useful as the #bitcoin IRC channel (very low signal/noise, no serious dev discussion)...
08:51 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
09:00 -!- rsx [~dummy@host-188-174-216-181.customer.m-online.net] has quit [Quit: rsx]
09:04 -!- zookolaptop [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Quit: ERC Version 5.3 (IRC client for Emacs)]
09:04 -!- skyraider_ [uid41097@gateway/web/irccloud.com/x-ydikjtrdhmtvgqyd] has joined #bitcoin-core-dev
09:04 -!- zookolaptop [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
09:14 -!- ronbo [~ronbo@c-73-30-230-54.hsd1.pa.comcast.net] has quit []
09:18 -!- T23WS [~textual@45.41.135.14] has joined #bitcoin-core-dev
09:19 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
09:39 -!- T23WS_ [~textual@210-20-183-152.rev.home.ne.jp] has joined #bitcoin-core-dev
09:41 -!- T23WS [~textual@45.41.135.14] has quit [Ping timeout: 264 seconds]
09:46 -!- T23WS [~textual@88.150.157.95] has joined #bitcoin-core-dev
09:47 -!- xiangfu [~xiangfu@xd9bad2d1.dyn.telefonica.de] has quit [Ping timeout: 245 seconds]
09:47 -!- T23WS_ [~textual@210-20-183-152.rev.home.ne.jp] has quit [Ping timeout: 260 seconds]
09:54 < GitHub38> [bitcoin] MarcoFalke opened pull request #7380: [qa] Disable salvagewallet check (master...Mf1601-qaDisableSalvagewalletCheck) https://github.com/bitcoin/bitcoin/pull/7380
10:05 < cfields> wumpus: thanks for having a look. yes, of course fixing the real dependency issue is the way to go :)
10:11 < gmaxwell> Freeking malloc in glibc on linux calls open on files in proc.
10:21 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
10:24 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
10:27 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
10:28 -!- dayZh [~dayzh@122.233.243.136] has quit [Ping timeout: 255 seconds]
10:36 -!- jonasschnelli [~jonasschn@2a01:4f8:200:7025::2] has quit [Ping timeout: 255 seconds]
10:37 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer]
10:37 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #bitcoin-core-dev
10:37 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
10:45 -!- drnet [~drnett@178.165.131.187.wireless.dyn.drei.com] has joined #bitcoin-core-dev
10:47 -!- ronbo [~ronbo@c-73-30-230-54.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
10:49 -!- T23WS [~textual@88.150.157.95] has quit [Quit: Textual IRC Client: www.textualapp.com]
10:57 < GitHub27> [bitcoin] MarcoFalke closed pull request #7380: [qa] Disable salvagewallet check (master...Mf1601-qaDisableSalvagewalletCheck) https://github.com/bitcoin/bitcoin/pull/7380
11:00 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
11:00 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
11:15 < michagogo> cfields: just checking, you saw that wumpus figured out the fix, right?
11:15 -!- drnet [~drnett@178.165.131.187.wireless.dyn.drei.com] has quit [Quit: Leaving]
11:15 < cfields> michagogo: the gitian issue, you mean?
11:16 < michagogo> yeah
11:16 < michagogo> (at the cost of a non-matching in hash)
11:16 < cfields> michagogo: yea, i saw. did't look into it, though. I guess lxc doesn't install python but kvm does, somehow?
11:17 < michagogo> It would seem so.
11:17 < cfields> weird
11:17 -!- MarcoFalke [c3523fc9@gateway/web/cgi-irc/kiwiirc.com/ip.195.82.63.201] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
11:18 < cfields> i suppose we should put it in the descriptor then. obviously it's needed, even if it happens to be pulled in by something else already
11:18 < michagogo> I guess it boils down to debootstrap vs pxc
11:18 < michagogo> lxc*
11:19 < michagogo> Yeah, I wonder what changed from 0.11 to 0.2
11:19 < michagogo> 0.12*
11:19 < cfields> michagogo: does trusty only install python3 by default, maybe?
11:19 < cfields> (or default to it)
11:19 < michagogo> If so, kvm should also fail
11:20 < michagogo> And I don't think they're there yet. IIRC I saw on the MLs that they're working on removing it from the default packages in xenial...
11:20 < cfields> michagogo: i was thinking part of the kvm install switched the default somehow
11:20 < cfields> but yea, that doesn't really make sense
11:21 < michagogo> the question is really what does debootstrap do different from vmbuilder
11:21 < michagogo> And yeah, https://wiki.ubuntu.com/Python confirms. Under "Plans for 16.04": UOS for Xenial had a session on the removal of Python 2.7 from the default images/seeds. 
11:21 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
11:24 < cfields> ok
11:30 < michagogo> so there are 3 real questions. 1) why does debootstrap not install python? 2) what changed from 0.11 to 0.12? and 3) why does this only affect OS X?
11:30 < Luke-Jr> cfields: I'm trying to add a depends pkg for qtsvg, and I have it with a dependencies on qt, but how do I get qmake? :/
11:35 < cfields> michagogo: unsure on all counts :\
11:35 < cfields> Luke-Jr: yuck, what's qtsvg for?
11:35 < Luke-Jr> cfields: I want to make the icons SVG only? :/
11:35 < cfields> Luke-Jr: isn't that just a config switch for the qt build?
11:35 < cfields> to enable the svg module?
11:36 < Luke-Jr> no, qtsvg is the svg module
11:37 < cfields> Luke-Jr: right. ./configure ... -svg
11:37 < Luke-Jr> …
11:39 < cfields> Luke-Jr: oh, i see the confusion, i think
11:39 < cfields> Luke-Jr: we grab the modules, put them in place, then tell qt's main configure which ones to build
11:40 < Luke-Jr> cfields: yuck? :P
11:40 < Luke-Jr> why can't packages use their dependencies?
11:41 < cfields> Luke-Jr: shrug, it never seemed to work well for me to try to split it into native/target builds
11:41 -!- lpersona [18630a99@gateway/web/freenode/ip.24.99.10.153] has joined #bitcoin-core-dev
11:41 < Luke-Jr> oh!
11:41 < cfields> you're welcome to give it a shot, of course :)
11:41 < Luke-Jr> so I need to depend on native too, makes sense
11:41 < michagogo> So the answer is to add ..qtsvg....tar.gz to the qt package file list, and then add the configure flag?
11:41 < cfields> Luke-Jr: yea, the tools are native, but qt doesn't make it easy to _just_ build the native parts. so in the end, it's easier to just build it all in one go
11:41 < Luke-Jr> eh, but there's no native-qt pkg
11:42 < cfields> Luke-Jr: what michagogo said. see qttranslations as an example
11:42 < Luke-Jr> cfields: that's ugly though :<
11:42 < cfields> Luke-Jr: very.
11:43 < cfields> Luke-Jr: maybe they've fixed it up lately and you'll have better luck these days splitting it up
11:43 < Luke-Jr> :|
11:43 < Luke-Jr> so how would I get access to qmake?
11:43 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
11:43 < cfields> Luke-Jr: you'd have to create a native package for just qmake/rcc/etc
11:44 < Luke-Jr> eh, nothing else already uses qmake?
11:44 < cfields> then add that as a dependency to the child package
11:44 < cfields> Luke-Jr: no, only qt internally
11:45 < Luke-Jr> i c
11:45 < cfields> Luke-Jr: see protobuf as an example of native/target split
11:46 < Luke-Jr> nah, if you and Gentoo both couldn't figure it out, I'll give up and go the qttranslations route
11:46 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer]
11:46 < cfields> Luke-Jr: heh, they do it the same way?
11:46 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
11:47 < Luke-Jr> no, but they don't make qmake available independently
11:47 < cfields> Luke-Jr: from what i could tell last time, trying to build just the native tools was painful, as well as trying to force the rest of the build stuff to use an out-of-tree qmake/rcc
11:48 < cfields> Luke-Jr: they probably make lots of assumptions that the versions being built are the ones used to compile the rest. kinda understandable.
11:52 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
11:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds]
12:11 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
12:13 < Luke-Jr> //home/ubuntu/cache/common/qttools-opensource-src-5.5.0.tar.gz: OK
12:13 < Luke-Jr> tar: /home/ubuntu/cache/common/qtsvg-opensource-src-5.5.0.tar.gz: Cannot open: No such file or directory
12:13 < Luke-Jr> cfields: any idea why it wasn't fetched? :x
12:15 < cfields> Luke-Jr: not without seeing what you changed
12:47 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
12:49 < Luke-Jr> cfields: http://codepad.org/dioh3N8s
12:51 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
12:53 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
13:00 < cfields> Luke-Jr: looks ok to me...
13:00 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
13:00 < cfields> Luke-Jr: though i just noticed, our hash-check isn't actually working there. we need to change those "echo foo > bar" to "echo foo >> bar"
13:00 < cfields> only the last one's getting hashed :\
13:01 < Luke-Jr> :/
13:17 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
13:18 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
13:22 -!- dayZh [~dayzh@122.233.243.136] has quit [Ping timeout: 240 seconds]
13:23 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
13:27 -!- lpersona [18630a99@gateway/web/freenode/ip.24.99.10.153] has quit [Quit: Page closed]
13:28 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
13:46 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
13:59 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
14:01 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 255 seconds]
14:02 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
14:03 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
14:03 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
14:20 -!- skyraider_ [uid41097@gateway/web/irccloud.com/x-ydikjtrdhmtvgqyd] has quit [Quit: Connection closed for inactivity]
14:35 -!- T23WS [~textual@88.150.157.95] has joined #bitcoin-core-dev
15:01 -!- ronbo [~ronbo@c-73-30-230-54.hsd1.pa.comcast.net] has quit [Read error: Connection reset by peer]
15:04 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Quit: Leaving.]
15:09 -!- zookolaptop [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds]
15:17 -!- [\\\] [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev
15:19 -!- zookolaptop [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
15:20 -!- [\\\] is now known as tripleslash
15:21 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
15:23 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Client Quit]
15:34 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
15:34 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
15:38 -!- dayZh [~dayzh@122.233.243.136] has quit [Ping timeout: 240 seconds]
15:42 -!- ronbo [~ronbo@c-73-30-230-54.hsd1.pa.comcast.net] has joined #bitcoin-core-dev
15:45 -!- zookolaptop [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds]
15:47 -!- adnn [adnn@gateway/vpn/mullvad/x-rtoarwuxhbislier] has joined #bitcoin-core-dev
15:49 -!- zookolaptop [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
15:54 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Read error: Connection reset by peer]
15:55 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has joined #bitcoin-core-dev
16:08 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
16:12 -!- dayZh [~dayzh@122.233.243.136] has quit [Ping timeout: 250 seconds]
16:23 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
16:28 -!- dayZh [~dayzh@122.233.243.136] has quit [Ping timeout: 264 seconds]
16:52 -!- drnet [~drnett@178.165.131.187.wireless.dyn.drei.com] has joined #bitcoin-core-dev
16:54 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
16:54 < dcousens> Hmph,  I just got a bunch of RPC server socket timeouts over 1.5 days old lol
16:56 < dcousens> socket sending timeout: 85865s
16:56 < dcousens> Maybe under 1.5 days, but over 1 day.  Anyway,  entering a line feed to STDIN unlocked the file descriptor?  Suddenly got "socket send error Bad file descriptor (9)"
16:56 < dcousens> And now my node has resumed catching up on the last day of missed blocks
16:57 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
16:58 < dcousens> Any ideas? Wondering where I should start with debugging this
16:59 < dcousens> (obviously an RPC call didn't give up CS_MAIN until the socket closed?)
17:02 -!- dayZh [~dayzh@122.233.243.136] has quit [Ping timeout: 256 seconds]
17:06 -!- adnn [adnn@gateway/vpn/mullvad/x-rtoarwuxhbislier] has quit [Remote host closed the connection]
17:10 -!- adnn_ [adnn@gateway/vpn/mullvad/x-jmracepgfghudqyu] has joined #bitcoin-core-dev
17:34 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Killed (orwell.freenode.net (Nickname regained by services))]
17:35 -!- bsm1175321 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev
17:35 -!- bsm1175321 is now known as bsm117532
17:36 -!- drnet [~drnett@178.165.131.187.wireless.dyn.drei.com] has quit [Quit: Leaving]
17:40 -!- afk11 [~afk11@gateway/vpn/privateinternetaccess/afk11] has joined #bitcoin-core-dev
17:43 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
17:47 -!- dayZh [~dayzh@122.233.243.136] has quit [Ping timeout: 260 seconds]
17:55 -!- afk11 [~afk11@gateway/vpn/privateinternetaccess/afk11] has quit [Ping timeout: 250 seconds]
18:00 < gijensen> Shorter timeouts? What was the last RPC call you made?
18:04 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
18:05 -!- zookolaptop [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds]
18:06 -!- GAit [~GAit@2-230-161-158.ip202.fastwebnet.it] has quit [Quit: Leaving.]
18:08 -!- dayZh [~dayzh@122.233.243.136] has quit [Ping timeout: 250 seconds]
18:16 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
18:18 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mcnsceyagcmhrebw] has quit [Quit: Connection closed for inactivity]
18:25 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Ping timeout: 260 seconds]
18:28 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
18:33 -!- warren [~warren@fedora/wombat/warren] has quit [Quit: ZNC - http://znc.in]
18:36 -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has joined #bitcoin-core-dev
18:36 -!- dayZh [~dayzh@122.233.243.136] has quit [Ping timeout: 265 seconds]
18:39 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
18:47 -!- afk11_ [~afk11@109.255.154.81] has joined #bitcoin-core-dev
18:47 -!- afk11 [~afk11@unaffiliated/afk11] has quit [Quit: Leaving.]
18:47 -!- afk11_ is now known as afk11
18:49 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
18:55 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:55 -!- dayZh [~dayzh@122.233.243.136] has quit [Remote host closed the connection]
18:55 -!- dayZh [~dayzh@122.233.243.136] has joined #bitcoin-core-dev
19:04 -!- afk11 [~afk11@109.255.154.81] has quit [Quit: ZNC - http://znc.in]
19:22 -!- afk11 [~afk11@unaffiliated/afk11] has joined #bitcoin-core-dev
19:23 -!- zookolaptop [~user@50.141.117.124] has joined #bitcoin-core-dev
19:23 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 255 seconds]
19:25 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
19:27 -!- zookolap` [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
19:29 -!- zookolaptop [~user@50.141.117.124] has quit [Ping timeout: 260 seconds]
19:39 -!- dayZh [~dayzh@122.233.243.136] has quit []
19:46 -!- warren [~warren@fedora/wombat/warren] has joined #bitcoin-core-dev
19:53 < wangchun> BlueMatt: ping
19:54 < BlueMatt> wangchun: yea, I mean I definitely understand what you're proposing, but I dont believe that any such soft fork would ever occur
19:54 < wangchun> so if you merge a patch that remove the block size limit completely NOW, but this patch does not take into effect until 2017-01-01
19:54 < BlueMatt> once its in there, the political pressure to not remove it is too strong
19:55 < BlueMatt> and, what do you set the limit to?
19:55 < wangchun> And time now is 2016-09-30, we have a consensus to upgrade to 2MB, that is fine, merge another patch for 2MB,
19:55 < BlueMatt> the political pressure to set the limit to something like 10mb at that time from people like coinbase would be huge...and 10mb would result in 0 fees for a long time to come
19:55 < wangchun> this new patch is soft fork for those running 0.12+, only hard fork for those running 0.11 or lower
19:56 < wangchun> and if no consensus on 2016-09-30, we can just remove the earlier patch, that nothing happens for those running 0.11 or lower, and it is a soft fork for those running 0.12+
19:56 < BlueMatt> suresure, but how do we pick the number in 2016-09?
19:56 < wangchun> this buys lots of time for waiting for the consensus
19:56 < BlueMatt> like, the selection of the number would fall to miners
19:56 < BlueMatt> how would miners pick the block size at that point?
19:57 < wangchun> three months buffer for a soft fork is enough
19:57 < wangchun> but for hard fork, we need probably a year
19:57 < wangchun> that's how these numbers are chosen
19:57 < BlueMatt> I understand that part, sure
19:57 < BlueMatt> but how will *you* pick the block size come 2016-09
19:58 < BlueMatt> and how will you, and the other miners agree on something in 2016-09?
19:58 < BlueMatt> otherwise we end up with an infinite blocksize and bitcoin blows up :/
19:58 < wangchun> any block size below 33.5MB is soft fork to those have upgraded
19:58 < BlueMatt> 33M will clearly break bitcoin in many way
19:58 < BlueMatt> s
19:59 < BlueMatt> and what if we cant get 51% to agree to a number?
19:59 < BlueMatt> then we end up with 33M and we have no fees and massive blocks :(
19:59 < wangchun> just change it back to 1MB
19:59 < BlueMatt> but there is no "just change it"
19:59 < BlueMatt> it has to be a soft fork, so miners have to agree to do it
19:59 < wangchun> it is soft fork for those upgraded
19:59 < BlueMatt> but miners have to agree
19:59 < wangchun> yes, it is
20:00 < kanzure> no way to change back
20:00 < BlueMatt> yes, it is a soft fork
20:00 < BlueMatt> but miners have to agree to do a soft fork
20:00 < wangchun> change it back is soft fork for those have upgraded, and it is no fork for those havn't.
20:01 < wangchun> OK, I explain it again...
20:01 < BlueMatt> nono, I understand
20:01 < BlueMatt> it is a soft fork for those who have upgraded, I agree
20:01 < wangchun> We schedule a "virtual" hard fork NOW, but only active it one year into the future
20:01 < dcousens> gijensen: sendrawtx
20:02 < BlueMatt> but my point is that a soft fork is not an upgrade by users, it is an upgrade by miners...what we're doing is setting the blocksize to 32M in 2017 if miners do nothing. Miners can soft fork it back down to something else before 2017, but they have to agree
20:02 < wangchun> after 9 months, if we have a detailed hard fork specs ready by then, go ahead,
20:02 < warren> wangchun: You have certainty that the bandwidth situation will be better a year from now?
20:02 < wangchun> otherwise change it back to what it was
20:02 < kanzure> wangchun: there is no way to ensure agreement about reverting to 1 MB in the event of catastrophic failure...... bitcoin miners will still continue to mine, even if 32 MB breaks the network.
20:02 < kanzure> wangchun: so they have no reason to agree to activate the soft-fork to "change it back".....
20:03 < wangchun> The hard fork is just an option for the future
20:03 < kanzure> even if everything is broken, maybe they will be OK with this
20:03 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev
20:03 < wangchun> Who are "they"?
20:04 < kanzure> miners.
20:04 < BlueMatt> wangchun: once its in the code it is no longer an option. it is an option for miners to soft-fork to decrease it again or set it to 1M, but if miners do not, then it is not an option
20:05 < kanzure> wangchun: bluematt's concern is the following scenario: (1) hard-fork block size increase, (2) the bitcoin network is broken, (3) miners disagree with #2, (4) miners do NOT activate soft-fork to "change it back".
20:05 < wangchun> OK, merge 2MB now but not activate it until 2017-01-01
20:05 < jl2012> wangchun, would you please elaborate you rationale of completing removing limit?
20:05 < warren> wangchun: Keep in mind that those miners who want to agree to a soft-fork might be at a significant orphan disadvantage to others who have greater connectivity.  It could be dangerous to make any assumptions about what the network and mining power distribution will look like in the future.
20:05 < wangchun> completely remove the limit is better, as it gives an option for any proposals
20:05 < wangchun> not just 2MB
20:05 < BlueMatt> jl2012: the rationale is that we know a hard fork needs at least a year to be deployed, so his proposal is to start it now
20:05 < BlueMatt> jl2012: by removing the limit, +/-
20:05 < BlueMatt> jl2012: and then soft fork it back down
20:06 < jl2012> but not completely removing
20:06 < BlueMatt> jl2012: well, remove up to the network message size limit, ie ~32M
20:06 < jl2012> that's basically completely remove
20:06 < BlueMatt> yes
20:07 < wangchun> sure, when the activate date getting close, add another patch soft fork it back to the consensus we have by then
20:07 < jl2012> if the consensus is X MB is tolerable, than X MB, not >X MB
20:07 < jl2012> wangchun, what if miners do not do to SF?
20:08 < wangchun> It will be no worse than the current debate we have.
20:08 < jl2012> much worse
20:08 < kanzure> the network will be broken, though. much worse.
20:08 < BlueMatt> wangchun: my big concern is we have no idea /who/ "the miners" will be in a year...bitfury may be 50% by themselves...
20:08 < kanzure> the scenario was (2) the network is broken, and (3) miners disagree.
20:08 < jl2012> yes, don't forget their new chips
20:09 < BlueMatt> or (2) the network is broken and (3) bitfury disagrees, since they have better bandwidth than other people 
20:09 < wangchun> How about merge 2MB now schedule it one year later?
20:09 < kanzure> that's true, bitfury has good bandwidth
20:09 < jl2012> "2MB now but not activate it until 2017-01-01" is basically another BIP102. Personally I don't think it is bad, if the date is far enough
20:10 < BlueMatt> (if anyone from bitfury is reading this, I dont mean to pick on y'all...just needed to pick someone...I mean ffs in a year /I/ might be 50% of the network...)
20:10 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 240 seconds]
20:10 < gijensen> dcousens, I have no idea where you'd start. I thought the timeout for RPC was limited to "timeout" too, so I didn't think that could happen.
20:10 < jl2012> just my 2 cents
20:10 < morcos> wangchun: I also like the idea.  I think we have spent too long trying to solve a technical problem when we really have a social problem.
20:11 < kanzure> agreed with morcos.
20:11 < BlueMatt> wangchun: you mean 4mb in a year
20:11 < BlueMatt> we're already doing 2mb...scheduling 2mb now means 4mb
20:11 < wangchun> Many people do not want hard fork just because it is risky,
20:11 < jl2012> BlueMatt, no need to mix segwit in this discussion
20:11 < wangchun> then we give them enough time to prepare the fork
20:11 < wangchun> that is the point
20:11 < jl2012> segwit can adapt a HF
20:12 < warren> wangchun: Say for example, the network breaks in some way with huge blocks, but miners with super fast centralized servers and very fast connectivity between each other decide they like it this way.  Miners with less bandwidth would have less ability to influence a soft-fork vote since they are orphaned out often due to the huge blocks.  It could be quite dangerous to make any assumptions about what the network and mining power distribution
20:12 < warren>  will look like in the future.
20:12 < BlueMatt> jl2012: hmm? no, its rather important? if we just want 2mb, no need to do that in a hf (if people are worried about a hf, lets increase the nonce space instead)
20:12 < jl2012> BIP141 will allow only 1.75MB with normal use
20:13 < jl2012> and assuming 100% people use it
20:13 < wangchun> warren: just 2mb or 4mb won't "break the network"
20:13 < BlueMatt> as for a 2.5/3ish mb hf, if I knew people would work on better relay mechanisms, I would be fine with that, mostly...but so far I'm +/- the only person at all who has worked on better relay
20:13 < BlueMatt> no, sorry, thats a lie, wangchun has as well
20:13 < wangchun> the problem is those nodes left behind a hard fork will be at risk
20:13 < wangchun> that is the issue this is trying to solve
20:13 < BlueMatt> but I'm not aware of anyone except for wangchun and I who have spent any serious time implementing better relay
20:13 < BlueMatt> 0.12 was a big step, but we need better relay, not just validation time for another step
20:14 < Luke-Jr> +1 for more nonce space; sadly, I'm sure Classic would reject that too :\
20:14 < jl2012> wangchun, yes, that's the biggest risk of hardfork. That's why the flag date has to be far enough
20:14  * Luke-Jr might as well throw it out there just in case
20:14 < wangchun> but now we do not have the consensus, we need something to buy us some time. That it is.
20:15 < jl2012> people are running legacy clients. E.g. I'm still running 0.9.5 for other applications to work
20:19 < BlueMatt> wangchun: in any case, I think there is some agreement on something around 2mb...if people really dont think the 1.75 of segwit is enough, forming consensus around a 2mb hf just to bump up segwith by .25mb is probably not hard, and could be done rather quickly, I think
20:19 < BlueMatt> wangchun: given 0.12 is adopted quickly, block process times and p2p relay should be improved enough that 2mb wont hurt decentralization incentives
20:19 < wangchun> Then we need to get the code merged as soon as possible
20:20 < wangchun> Activation date is not that important
20:20 < wangchun> but it should be far enough
20:20  * BlueMatt will complain loudly if its any less than a year from when the code is released
20:20 < jl2012> wangchun, I think consensus has been reached that 2MB is tolerable. The only remaining question is how to archive 2MB
20:20 < BlueMatt> thats probably still really tight, but I'd say at least a year
20:20 < wangchun> BlueMatt: I agree
20:21 < wangchun> Then we are talking something not happen until 2017
20:21 < gijensen> dcousens, ignore that. "timeout" doesn't effect RPC. I'm curious if it lasted longer than the specified RPC timeout though (set by bundling a timeout parameter via RPC or -rpcclienttimeout on bitcoin-cli)
20:21 < wangchun> Until it is too late, we need to do something
20:28 -!- cypherBlock [32bd885e@gateway/web/freenode/ip.50.189.136.94] has joined #bitcoin-core-dev
20:34 < BlueMatt> warren: how about we go jointly propose a hard fork that activates in like late feb 2017 that also includes more nonce space (so that people cant argue its too trivial a change for a hard fork) :)
20:34 < BlueMatt> wangchun: 
20:34 < BlueMatt> is who I meant to tag
20:35 -!- yifu [426c51db@gateway/web/freenode/ip.66.108.81.219] has joined #bitcoin-core-dev
20:35 < wangchun> good to me
20:35 < BlueMatt> maybe early march, but whatever, first half of 2017
20:36 -!- zookolap` [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 250 seconds]
20:36 -!- yifu [426c51db@gateway/web/freenode/ip.66.108.81.219] has quit [Client Quit]
20:36 -!- AdrianG [~User@unaffiliated/amphetamine] has joined #bitcoin-core-dev
20:50 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 240 seconds]
20:58 < Luke-Jr> BlueMatt: jtoomim is already opposing more nonce space though, implying all sorts of nonsense accusations
20:59 < jtoomim> changing the headers probably breaks compatibility with SPV wallets.
20:59 < BlueMatt> jtoomim: it doesnt change the headers in any meaningful way
21:00 < jtoomim> hmm, let me look through the irc chat first
21:00 < jtoomim> i got linked into this discussion without context
21:00 < jtoomim> and i've been running into a lot of trolls trying to add bugs to Classic
21:00 < Luke-Jr> jtoomim: changing anything should break compatibility with SPV wallets; that it doesn't just goes to show the "SPV" wallets out there are buggy
21:00 < jtoomim> so i'm in super-pessimistic mode rightnow
21:00 < Luke-Jr> jtoomim: if you mean me, it's in your head only
21:01 < jtoomim> no, not you luke
21:01 < jtoomim> mostly james
21:01 < jtoomim> by the way, i wanted to apologize to you
21:01 < jtoomim> i think i accused you of being a troll, but in retrospect, you were innocent
21:01 < jtoomim> changing the PoW function is a reasonable thing in this context, just not for classic
21:02 < jtoomim> it's a reasonable thing for the minority branch to do
21:02 < warren> jtoomim: It's quite dangerous to do a HF to fullnodes that is seen as a SF to SPV?
21:02 < jtoomim> although i think it would be better to use AuxPoW and merge-mine
21:02 < jtoomim> is that a question or a statement!
21:02 < jtoomim> s/!/./
21:02 < warren> Wondering your opinion on that.
21:03 < jtoomim> i don't think it's quite dangerous, no, but i do think we should be careful during testing to make sure it goes as expected
21:03 < warren> Err ... I mean the SPV clients can't tell the difference, and that's dangerous.
21:03 < jtoomim> well, only if you think that the fork is going to be contentious
21:03 < Luke-Jr> warren: it'd be a 200k proof, but SPV clients *could* tell if they did fraud proofs
21:03 < jtoomim> but SPV wallets can either wait it out, or import their keys, or watch the block versions or something
21:05 < jtoomim> i've been thinking about including an increase to the coinbase scriptsig size in the HF
21:05 < jtoomim> i don't think that would affect SPV wallets
21:05 < jtoomim> but i really want to keep the change count as low as is safe for this HF
21:06 < jtoomim> which means mostly just tx validation cost limits (bytes hashed), versionbits logic, and the blocksize limit itself
21:08 -!- cryptojonathan [~AndChat22@190.141.37.178] has joined #bitcoin-core-dev
21:08 < Luke-Jr> jtoomim: how about expanding versionbits to use all 32 bits?
21:08 < Luke-Jr> jtoomim: right now it's like 30 bits to avoid hardforking only
21:08 < randy-waterhouse> can't see how this discussion should be in bitcoin-core-dev ... take it too bitcoin-dev or bitcoin-classic?
21:09 < Luke-Jr> randy-waterhouse: fair
21:09 < jtoomim> luke-jr, it would break compatibiltiy with SPV.
21:09 < jtoomim> unless no SPV wallets even look at the nVersion field
21:09 < jtoomim> which i doubt
21:09 < jtoomim> ok
21:18 -!- T23WS_ [~textual@210-20-183-152.rev.home.ne.jp] has joined #bitcoin-core-dev
21:19 -!- adnn_ [adnn@gateway/vpn/mullvad/x-jmracepgfghudqyu] has quit []
21:21 < warren> BlueMatt: wangchun: Just throwing out ideas here ... it's certainly positive to add reasons to make a hardfork more worthwhile than 1.75MB -> 2MB like adding extra nonce space.  I think we could do even better than that, as we have had a hardfork wishlist for years and this gives us an opportunity to fix more than one problem.  I wonder if people would be OK with agreeing on the current roadmap to get us to an effective 1.75MB+ in a few mon
21:21 < warren> ths, and also set a deadline for HF wishlist item implementation (BIPs and code) for a scheduled hardfork in early 2017.  Whatever isn't fully approved in peer tech review before that deadline is cut.  Everyone could become far more productive if we agreed to end the drama and work on real improvements together in this manner?
21:21 -!- T23WS [~textual@88.150.157.95] has quit [Ping timeout: 264 seconds]
21:26 -!- AndChat|221969 [~AndChat22@200.108.58.52] has joined #bitcoin-core-dev
21:27 -!- cryptojonathan [~AndChat22@190.141.37.178] has quit [Ping timeout: 276 seconds]
21:38 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
21:48 -!- jtoomim [~jtoomim@63.135.62.197] has quit []
21:51 -!- JackH [~Jack@host-80-43-141-112.as13285.net] has quit [Ping timeout: 276 seconds]
21:56 -!- JackH [~Jack@host-80-43-141-112.as13285.net] has joined #bitcoin-core-dev
22:08 -!- priver__ [688e768f@gateway/web/freenode/ip.104.142.118.143] has joined #bitcoin-core-dev
22:14 -!- priver__ [688e768f@gateway/web/freenode/ip.104.142.118.143] has quit [Quit: Page closed]
22:16 -!- cypherBlock [32bd885e@gateway/web/freenode/ip.50.189.136.94] has quit [Quit: Page closed]
22:30 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has quit [Read error: Connection reset by peer]
22:30 -!- d_t [~textual@c-50-136-139-144.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
22:32 < Lightsword> BlueMatt, btw looks like ckpool now has what is essentially an internal relay network for multi-node regional deployments, but only works for trusted stratum server nodes
22:37 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-qssqvpcuzfkvokef] has joined #bitcoin-core-dev
22:43 < BlueMatt> Lightsword: yea, if we all spv mine it's fine! :/
22:45 < Lightsword> BlueMatt, yeah….it’s different from the HO mining at least since it ships around ckpool’s workinfos between nodes or something like that
22:46 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has quit [Ping timeout: 276 seconds]
22:51 < BlueMatt> suresure, if its your own nodes I get it
22:56 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
22:56 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
22:56 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
22:59 -!- rubensayshi [~ruben@c89225.upc-c.chello.nl] has joined #bitcoin-core-dev
23:01 -!- brg444 [415ce066@gateway/web/freenode/ip.65.92.224.102] has quit [Ping timeout: 252 seconds]
23:14 -!- jtimon [~quassel@126.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds]
23:40 -!- murch [~murch@p4FE392F7.dip0.t-ipconnect.de] has joined #bitcoin-core-dev