--- Day changed Thu Feb 25 2016
00:03 -!- danielsocials [~quassel@123.119.91.62] has quit [Ping timeout: 250 seconds]
00:25 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:32 -!- chris2000 [~chris2000@p54AE7A2F.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
00:32 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 244 seconds]
00:34 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
00:41 -!- fkhan [weechat@gateway/vpn/mullvad/x-ryanbpobizuuupqu] has quit [Ping timeout: 240 seconds]
00:54 -!- fkhan [weechat@gateway/vpn/mullvad/x-rbedxlwjcewsgeem] has joined #bitcoin-core-dev
01:01 -!- danielsocials [~quassel@123.119.91.62] has joined #bitcoin-core-dev
01:07 -!- danielsocials [~quassel@123.119.91.62] has quit [Ping timeout: 255 seconds]
01:16 -!- MarcoFalke [d9fd2576@gateway/web/cgi-irc/kiwiirc.com/ip.217.253.37.118] has joined #bitcoin-core-dev
01:27 -!- AaronvanW_ [~ewout@f055048210.adsl.alicedsl.de] has joined #bitcoin-core-dev
01:48 -!- go1111111 [~go1111111@104.232.116.217] has quit [Ping timeout: 252 seconds]
02:00 -!- go1111111 [~go1111111@104.200.154.24] has joined #bitcoin-core-dev
02:01 -!- MarcoFalke [d9fd2576@gateway/web/cgi-irc/kiwiirc.com/ip.217.253.37.118] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
02:07 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
02:14 -!- zooko [~user@50.141.119.67] has quit [Ping timeout: 244 seconds]
02:29 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
02:47 -!- MarcoFalke [d9fd2576@gateway/web/cgi-irc/kiwiirc.com/ip.217.253.37.118] has joined #bitcoin-core-dev
02:49 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 240 seconds]
02:51 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
03:04 -!- danielsocials [~quassel@123.119.91.62] has joined #bitcoin-core-dev
03:16 -!- MarcoFalke [d9fd2576@gateway/web/cgi-irc/kiwiirc.com/ip.217.253.37.118] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
03:20 -!- danielsocials [~quassel@123.119.91.62] has quit [Ping timeout: 276 seconds]
03:36 < GitHub199> [bitcoin] luke-jr closed pull request #7529: Bugfix: Rename descendantfees to descendantmodfees (master...bugfix_descendantfees) https://github.com/bitcoin/bitcoin/pull/7529
03:48 -!- xiangfu [~xiangfu@111.198.29.53] has quit [Ping timeout: 255 seconds]
04:36 -!- dermoth_ [~thomas@dsl-66-36-146-203.mtl.aei.ca] has joined #bitcoin-core-dev
04:37 -!- dermoth [~thomas@dial-216-221-43-252.mtl.aei.ca] has quit [Disconnected by services]
04:37 -!- dermoth_ is now known as dermoth
04:40 -!- MarcoFalke [8af60239@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.57] has joined #bitcoin-core-dev
04:41 -!- p15x [~p15x@125.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
04:47 -!- Thireus [~Thireus@217.170.197.92] has quit [Ping timeout: 255 seconds]
04:47 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
04:48 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
04:51 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 244 seconds]
04:55 -!- MarcoFalke [8af60239@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.57] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
04:56 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
05:01 -!- dermoth_ [~thomas@dsl-216-221-62-124.mtl.aei.ca] has joined #bitcoin-core-dev
05:02 -!- dermoth [~thomas@dsl-66-36-146-203.mtl.aei.ca] has quit [Ping timeout: 240 seconds]
05:02 -!- dermoth_ is now known as dermoth
05:02 -!- laurentmt [~Thunderbi@128.79.141.196] has joined #bitcoin-core-dev
05:15 -!- Kexkey [~kexkey@108.61.17.171] has joined #bitcoin-core-dev
05:16 -!- gevs [~greg@ip-80-236-216-234.dsl.scarlet.be] has joined #bitcoin-core-dev
05:16 -!- gevs [~greg@ip-80-236-216-234.dsl.scarlet.be] has quit [Changing host]
05:16 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
05:17 -!- danielsocials [~quassel@123.119.91.62] has joined #bitcoin-core-dev
05:20 -!- zooko [~user@2601:281:8001:26aa::f25c] has joined #bitcoin-core-dev
05:22 -!- danielsocials [~quassel@123.119.91.62] has quit [Ping timeout: 244 seconds]
05:32 -!- xiangfu [~xiangfu@123.125.212.78] has joined #bitcoin-core-dev
05:35 -!- Kexkey [~kexkey@108.61.17.171] has quit [Remote host closed the connection]
05:58 -!- MarcoFalke [8af602b9@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.185] has joined #bitcoin-core-dev
06:00 -!- p15 [~p15@90.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 240 seconds]
06:01 -!- p15x [~p15x@125.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 252 seconds]
06:02 -!- p15x [~p15x@58.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
06:03 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev
06:10 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 255 seconds]
06:13 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
06:19 -!- danielsocials [~quassel@123.119.91.62] has joined #bitcoin-core-dev
06:25 -!- MarcoFalke [8af602b9@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.185] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
06:25 -!- danielsocials [~quassel@123.119.91.62] has quit [Ping timeout: 248 seconds]
06:44 -!- zooko [~user@2601:281:8001:26aa::f25c] has quit [Ping timeout: 250 seconds]
07:12 -!- p15x [~p15x@58.91.145.64.client.static.strong-tk2.bringover.net] has quit [Ping timeout: 244 seconds]
07:22 -!- danielsocials [~quassel@123.119.91.62] has joined #bitcoin-core-dev
07:31 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
07:32 -!- MarcoFalke [8af6020a@gateway/web/cgi-irc/kiwiirc.com/ip.138.246.2.10] has joined #bitcoin-core-dev
07:33 -!- murch [~murch@p4FE38EB4.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:34 -!- danielsocials [~quassel@123.119.91.62] has quit [Ping timeout: 276 seconds]
07:53 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds]
07:53  * Luke-Jr prods cfields to fix the OSX SDK from Travis..
08:12 -!- xiangfu [~xiangfu@123.125.212.78] has quit [Remote host closed the connection]
08:16 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
08:18 < btcdrak> Luje-Jr: what's wrong with it?
08:19 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
08:21 < Luke-Jr> btcdrak: it's Forbidden as usual
08:23 -!- cheese_ [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
08:23 < btcdrak> link?
08:24 < btcdrak> oh the SDK, yeah.
08:25 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]
08:26 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
08:32 -!- danielsocials [~quassel@123.119.91.62] has joined #bitcoin-core-dev
08:34 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev
08:35 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 244 seconds]
08:38 -!- danielsocials [~quassel@123.119.91.62] has quit [Ping timeout: 240 seconds]
08:41 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
08:42 -!- dermoth [~thomas@dsl-216-221-62-124.mtl.aei.ca] has quit [Ping timeout: 255 seconds]
08:47 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
08:47 -!- Don_John [~Don@248-223-114-134.nat.resnet.nau.edu] has joined #bitcoin-core-dev
08:48 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
08:48 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
08:55 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
08:55 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection]
08:56 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 240 seconds]
09:08 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
09:09 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
09:10 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
09:13 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 248 seconds]
09:19 < GitHub178> [bitcoin] morcos opened pull request #7598: Refactor CreateNewBlock to be a method of the BlockAssembler class (master...BlockAssembler) https://github.com/bitcoin/bitcoin/pull/7598
09:25 -!- laurentmt [~Thunderbi@128.79.141.196] has quit [Quit: laurentmt]
09:29 -!- gevs [~greg@ip-80-236-216-234.dsl.scarlet.be] has joined #bitcoin-core-dev
09:29 -!- gevs [~greg@ip-80-236-216-234.dsl.scarlet.be] has quit [Changing host]
09:29 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev
09:34 -!- cj [~cjac@104.36.247.28] has quit [Ping timeout: 252 seconds]
09:35 -!- danielsocials [~quassel@123.119.91.62] has joined #bitcoin-core-dev
09:37 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has quit [Remote host closed the connection]
09:37 -!- lightningbot [supybot@2400:8900::f03c:91ff:fedf:3a06] has joined #bitcoin-core-dev
09:41 -!- jon3ss [~jones@104.238.169.80] has joined #bitcoin-core-dev
09:43 -!- jon3ss [~jones@104.238.169.80] has quit [Read error: Connection reset by peer]
09:44 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 244 seconds]
09:44 -!- danielsocials [~quassel@123.119.91.62] has quit [Ping timeout: 250 seconds]
09:50 -!- skyraider_ [uid41097@gateway/web/irccloud.com/x-lyexkyewveyqdjcm] has joined #bitcoin-core-dev
09:52 -!- cj [~cjac@207-118-89-97.dyn.centurytel.net] has joined #bitcoin-core-dev
09:53 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 248 seconds]
10:04 -!- raedah [~raedah@172.58.33.159] has quit [Remote host closed the connection]
10:05 -!- raedah [~raedah@172.58.33.159] has joined #bitcoin-core-dev
10:06 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
10:08 -!- murch [~murch@p4FE38EB4.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
10:13 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
10:14 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Remote host closed the connection]
10:14 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
10:18 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 252 seconds]
10:26 -!- cj [~cjac@207-118-89-97.dyn.centurytel.net] has quit [Ping timeout: 252 seconds]
10:28 -!- cj [~cjac@104.36.247.21] has joined #bitcoin-core-dev
10:30 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Quit: AtashiCon]
10:30 -!- AtashiCon [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
10:40 -!- raedah [~raedah@172.58.33.159] has quit [Ping timeout: 248 seconds]
10:43 < cfields> Luke-Jr: just grepped the logs and guessed on a range based on what was failing. fingers crossed, should work now.
10:50 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
10:54 -!- raedah [~raedah@172.58.33.159] has joined #bitcoin-core-dev
10:55 -!- raedah [~raedah@172.58.33.159] has quit [Remote host closed the connection]
10:58 -!- achow101 [~achow101@166.170.28.66] has joined #bitcoin-core-dev
11:01 < gmaxwell> #startmeeting
11:01 < lightningbot> Meeting started Thu Feb 25 19:01:14 2016 UTC.  The chair is gmaxwell. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:01 < gmaxwell> Hello. Welcome to today's meeting (bot is broken in #bitcoin-dev. Topics?
11:02 < morcos> Did anyone review 7187 as per last weeks action item?  
11:02 < morcos> We need punishments
11:02 < petertodd> morcos: heh, you're making me glad I was on a plane :)
11:02 < btcdrak> I got stuck in traffic, honest
11:02 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 244 seconds]
11:03 -!- proslogion [~proslogio@90.209.31.108] has joined #bitcoin-core-dev
11:03 < morcos> Actually to make a topic out of it, lets gameplan a 68/112/113 rollout
11:03 < gmaxwell> morcos: we'll end up with people showing up every other meeting it seems. I also wasn't in last week.
11:03 < gmaxwell> #topic  68/112/113 rollout
11:03 < btcdrak> +1 morcos
11:03 < petertodd> so, rollout is made more complex by a non-trivial amount of hashing power nVersion voting for classic
11:03 < jonasschnelli> could a bip 68/112/113 softfork be a timestopper for SW?
11:04 < gmaxwell> This... again. :(
11:04 < morcos> sorry btcdrak i haven't checked recently, but it seemed to me that the soft fork logic was relatively easy to review (except for gmaxwells concern), but that we still needed more extensive testing
11:04 < petertodd> jonasschnelli: what do you mean by 'timestopper'?
11:04 < btcdrak> Yes. I have written an ISM rollout in https://github.com/bitcoin/bitcoin/pull/7561 but we may need to consider BIP9 now
11:04 < sdaftuar> has anyone reviewed either of the new versionbits proposals? (i haven't)
11:04 < jonasschnelli> timestopper: I guess we can't run two SF at the same time.
11:04 < morcos> yes, that should be action item for next week.
11:05 < btcdrak> sipa started a BIP9 implementation in https://github.com/bitcoin/bitcoin/pull/7575
11:05 < gmaxwell> jonasschnelli: I don't think so; at least we can roll multiple ISM sofforks at once so long as they are strictly additive. No one that I'm aware of is clamoring againsst 68/112/113.
11:05 < petertodd> gmaxwell: fwiw I asked f2pool and bitmain to use coinbase to allow hashers to show support rather than nVersion
11:05 < petertodd> gmaxwell: 68/112/113 were briefly discussed in HK, with no objections, fwiw
11:05 < gmaxwell> I am pretty fond of sipa's BIP9 implementation.
11:05 < btcdrak> I've been working on converting the tests in #7561 to work with versionbits so we have both options. But I have a couple of technical nits I'd like to discuss
11:06 < morcos> I think it would be the wiser move technically and politically to do BIP9 first if we don't think the delay is too long.  It's kind of the whole point of the thign.
11:06 < btcdrak> BIP68 obviously requires v2 transactions, which currently dont relay. So we need to bump the relay policy. the question is do we go for sf enforcement first, and then bump the policy or do we change the relay policy with the sf deployment?
11:07 < gmaxwell> petertodd: it's hard to be sure, it may be that it only becomes a constructed political hot potato once merged as we've seen for at least one other thing. But we can't plan based on my cyncicism. Maybe a last call to the mailing list would be useful.  "We're thinking about moving this into deployment, what if any complaints remain?"
11:07 < petertodd> btcdrak: I think changing the relay policy in the release that supports it is fine - that's basically what we did with CLTV after all
11:07 < morcos> gmaxwell: yes thats my point exactly, i think much less likely to have complaints if we are doing it via bip9
11:07 < petertodd> btcdrak: just don't bump the default tx version number yet!
11:07 < btcdrak> We also have a sort of chicken and egg situation for changing the default tx version, so I proposed this https://github.com/btcdrak/bitcoin/commit/957d59043b1eb3a2525eae6cae6a2a15b2eab401 so it can be done in two steps
11:08 < petertodd> btcdrak: looks good
11:08 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has joined #bitcoin-core-dev
11:08 < morcos> two steps seems logical, and bumping the default isn't particularly important while we don't have wallet code for sending BIP68 locked txs anyway right?
11:08 < btcdrak> Unless miners were change their signalling, I think we should go for BIP9 this time. It shouldnt take too long to convert the RPC tests over to sipa's PR.
11:09 < gmaxwell> I haven't spoken to the BTCD folks in a bit, they've provided useful feedback on protocol changes in the past. I'll take an action to go talk to them about 9/68/112/113.
11:09 < btcdrak> I'm building a patch based on #7575
11:09 < CodeShark> I personally dislike adding these constants to the CTransaction class
11:09 < jonasschnelli> #action talk to BTCD folk about bips 9/68/112/113
11:10 < btcdrak> maybe also action review 7575?
11:10 < gmaxwell> Should we send a last call-ish like message about 68/112/113 ?
11:10 < CodeShark> CTransaction should be relay policy independent as well as consensus independent
11:10 < petertodd> gmaxwell: ack
11:10 < btcdrak> gmaxwell: in what way? 
11:10 < gmaxwell> btcdrak: "We're thinkin about moving these to deployment. Speak now or be mocked when you complain later."
11:10 < morcos> CodeShark: are you referring to BIP68 stuff.  (I mostly agree, but we merged that already)
11:10 < petertodd> CodeShark: I think that's a reasonable concern
11:11 < sdaftuar> gmaxwell: ack
11:11 < btcdrak> gmaxwell: yes that would be great. I had been contemplating this.
11:11 < gmaxwell> #action Send email re-68/112/113 deployment.
11:11 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
11:11 < petertodd> gmaxwell: probably worth mentioning that we're considering version bits due to classic conflicts
11:11 < morcos> Who is taking that action item
11:11 < sipa> hi, i'm on bad internet in barbados
11:12 < gmaxwell> I could do it but I'm not ideal; not super up to date on the history there.
11:12 < morcos> petertodd: i think we should not mention that, lets just see if we can get bip 9 ready quickly and then say we're doing it
11:12 < CodeShark> sipa: what's the status on bip 9?
11:12 < petertodd> morcos: eh, that's reasonable if we think we're close
11:13 < sipa> CodeShark: i started working on some other changes to the bip (disambiguate some things, add a state transition diagram, and add start time)
11:13 < jonasschnelli> morcos: do you want to take the action-item for email re-68/112/113 deployment?
11:13 < morcos> sure unless btcdrak wants it
11:13 < btcdrak> morcos: I'll pass :)
11:13 < sipa> CodeShark: but not submitted yet
11:13 < jonasschnelli> morocs has "a white vest".
11:14 < btcdrak> sipa: is #7575 not up to date?
11:14 < jonasschnelli> 7575 was updated today
11:14 < sipa> btcdrak: is that my pr?
11:14 < gmaxwell> jonasschnelli: all the better to show the gunshot wounds.
11:14 < jonasschnelli> gmaxwell... haha
11:14 < sipa> btcdrak: it impkements a start time, which is not in bip9
11:14 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 252 seconds]
11:14 < btcdrak> sipa: oh, _that_ is why my RPC tests did not work.... 
11:14 < morcos> uhh
11:14 < sipa> btcdrak: and i had to make some interoretation as bip9 is ambiguous about what hapoens when both transitiin to failed and lockedin happen simultaneously
11:15 < gmaxwell> We had previously discussed a start time esp with the debacle that happened with CLTV being used by 1/4 to 1/3 of the hashpower before any released software supported it.
11:15 < btcdrak> sipa: I was going bananas 
11:15 < sipa> sorry for typing, in a bumpy car
11:15 < CodeShark> argh...I added and removed a start time several times to the bip :p
11:15 < sipa> CodeShark: i know, sorry
11:16 < sipa> i believe we need one, but i want some other explanations on the bip too
11:16 < btcdrak> sipa: I agree with starttime, prefer it.
11:16 < sipa> there are different ways to do it
11:16 < morcos> sipa: so to be clear, is your bip 9 pr (7575) where you want it to be?  if so i think that should be primary action item for everyone else to review and feedback
11:16 < gmaxwell> I can't imagine doin BIP9 without a start time. Rusty was opposed on principle, I think, but expirence trumps.
11:17 < btcdrak> sipa: so I'll have to mock time for the RPC test
11:17 < petertodd> gmaxwell: by start time, you mean minimum possible activation data right?
11:17 < morcos> btcdrak can simultaneously work on getting the 68/112/113 ready to use it
11:17 < petertodd> gmaxwell: or grace period post-activation?
11:17 < sdaftuar> fyi 7575 is still failing travis, haven't dived in to see what is wrong
11:17 < gmaxwell> morcos: people reviewing should keep in mind that intentional discrepency with the BIP at the moment.
11:17 < morcos> we need both of those and 7187 merged for backport
11:17 < morcos> gmaxwell: noted.  :)
11:17 < CodeShark> https://github.com/bitcoin/bips/pull/219 didn't even get merged over this whole starttime crap :(
11:17 < gmaxwell> petertodd: former, in what the PR implements there is a time where the bit in the header becomes defined as counting for the soft-fork.
11:18 < CodeShark> Which wasn't even the main point of that PR
11:18 < btcdrak> morcos: yeah it's basically done, modulo converting the RPC tests from my ISM PR.
11:18 < petertodd> gmaxwell: right, any idea on how many months after final release that should be?
11:18 < sipa> btcdrak: starttime is blocktime based, not real time; you don't need mocktime
11:19 < sipa> morcos: 7575 is where i want it to be, but the logic should also go in bip9
11:19 < gmaxwell> petertodd: I think it's OKAY for it to be relatively near the release. considering that we've survived with an effectively negative start time.
11:19 < sipa> CodeSharki'll have a look at your pr to the bip again
11:19 < petertodd> gmaxwell: ok, so maybe 1-2 months?
11:20 < btcdrak> our roadmap FAQ tentatively pencilled BIP68,112,113 for March.
11:20 < sipa> sdaftuar: if tests still fails, the pr is certainly not where it should be regarding tests
11:20 < morcos> petertodd: i'm not following, you think you shouldn't be able to start soft fork activation for 1-2 months after code release?
11:20 < morcos> why not? at 95% miner threshold and with innocous soft forks, it should be ok to do it sooner.  
11:20 < CodeShark> We need to start getting into the habit of publishing less optimistic schedules ;)
11:21 < morcos> maybe something a bit more invasive (like segwit) then you could put a couple 1000 block delay
11:21 < gmaxwell> morcos: ideally nodes are updated first, though it's not strictly needed.
11:21 < petertodd> morcos: yes, that's gmaxwell's argument, to give non-miners some time to upgrade their nodes (even in a soft-fork that's a good thing)
11:21 < btcdrak> morcos: we want to avoid the situation we had with CLTV where f2pool were mining v4 blocks before we'd actually released the code.
11:21 < gmaxwell> morcos: because you want them rejecting any blocks from that 5% that are not valid.
11:21 < CodeShark> However long you think anything could reasonably take, double it for public expectations
11:21 < petertodd> morcos: one argument for it, is it can be done in about one line of code - cheap protection
11:22 < petertodd> CodeShark: yeah, so a practical problem, is you'd be changing unit tests right up until the last minute pre-release
11:22 < petertodd> CodeShark: a grace period - if it could be implemented easily enough - is better in that regard as it's defined from after the point at which the fork activates
11:22 < morcos> petertodd: i'm mostly just thinking about making changes take even longer..  and also perhaps losing attention focused on what's happening...   oh maybe i'm misunderstanding.  you could signal for it immediately, but it couldn't activate until start time
11:22 < petertodd> CodeShark: less important if the minimum start time is far into the future, but 1-2 months isn't
11:22 < morcos> that might be good
11:23 < petertodd> morcos: yeah, 100% ok to signal immediately
11:23 < btcdrak> petertodd: I think we get the PR into a mergable state, once agreed (and decided on deployment of code), we can set the start date for a reasonable amount of time into the future.
11:23 < petertodd> btcdrak: well, so long as we can co-ordinate that with the bitcoin core release schedule - which admittedly is much easier if we continue to do that in minor version releases
11:23 < btcdrak> petertodd: exactly.
11:24 < petertodd> alright, ack 1-2 month min start time
11:25 < btcdrak> wumpus: I would caution any merging consensus refactoring PRs until we get the sf code emerged. It will make backporting to 0.12 easier and easier to verify (basically an easy cherrypick).
11:26 < petertodd> btcdrak: I suggest we buy jtimom a time machine so he can do his refactors in the past :)
11:26 < petertodd> *jtimon
11:28 < gmaxwell> Any other topics? (we can discuss BIP9 more out of meeting and maybe when sipa has better connectivity?
11:29 < sipa> i'm going afk now; i'll look at bip9 and 7575 and tests next week
11:30 < petertodd> I'm working on a tech writeup re: HK
11:30 < warren> FYI: probably need to be ready to analyze and act on https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html if necessary
11:31 < petertodd> warren: interesting!
11:31 < gmaxwell> #topic openssl drama again
11:31 < gmaxwell> our response needs to get openssl out of the software to the greatest extent possible. It's already out of consensus, it's close to out of bitcoind.
11:32 < gmaxwell> The only thing we don't have an answer for is payment protocol, and the feedback I'm getting is that PP is virtually unused esp in core. We could consider making PP off by default and have a setting in the UI to enable it.
11:32 < petertodd> gmaxwell: and fortunately, PP isn't consensus critical, which helps a bit
11:33 < morcos> oh so i don't need to ever bother figuring out what PP is?
11:33 < petertodd> morcos: payment protocol
11:33 < gmaxwell> petertodd: still means we need to roll emergency updates for serious openssl vulnerabilties.
11:33 < morcos> i just mean i haven't looked at the code
11:33 < warren> Does anyone use rpcssl?
11:33 -!- jtimon [~quassel@35.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev
11:33 < petertodd> gmaxwell: interesting question re: PP - does the average install of Bitcoin Core's qt wallet actually let people click on a PP link and have their wallet pop up? if not, strongly suggests it isn't being used much
11:33 < gmaxwell> It's written in QT, uses QT for HTTP.
11:33 < gmaxwell> warren: thats gone.
11:33 < warren> oh good
11:34 < gmaxwell> petertodd: I know nothing about windows packaging. I did believe we installed a URL handler.
11:35 < gmaxwell> If PP continues in the long run it should be process seperated at least, I tried to do this before (and also to make it useful from cli/rpc) but the implementation was such that it didn't lend itself to that.
11:35 < petertodd> gmaxwell: we can always do a release where you need a command line flag to enable it and see if anyone notices :)
11:35 < gmaxwell> petertodd: thats kind of what I was thinking with the GUI option too "If you've turned this on, please report to..."
11:36 < petertodd> also, PP w/o multisig has somewhat dubious advantages right now, and even with multisig I'm not sure there are any wallets that really do it well
11:37 < petertodd> more likely that PP will have worse CA verification than your browser, which benefits from the massive amount of work done to make SSL secure in the face of bad cert authorities
11:38 < CodeShark> PP is dumb
11:38 < petertodd> CodeShark: eh, it goes in the right direction, it's just not so useful in the current environment
11:39 < CodeShark> silly to try to specify it when so many more fundamental things still aren't solved ;)
11:39 < petertodd> CodeShark: in the far future I'd be surprised if we aren't using something like PP for all txs, probably on a mandatory basis (but I assume treechains will eventually happen!)
11:40 < gmaxwell> Okay any other topics?
11:41 < gmaxwell> Otherwise, I'm going to call the end.
11:41 < petertodd> ack
11:41 < gmaxwell> #endmeeting
11:41 < lightningbot> Meeting ended Thu Feb 25 19:41:18 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
11:41 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-25-19.01.html
11:41 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-25-19.01.txt
11:41 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-25-19.01.log.html
11:41 < gmaxwell> thanks everyone.
11:41 < btcdrak> thank you!
11:41 < paveljanik> Let's celebrate #400000 :-)
11:41 < jonasschnelli> \o/
11:41 < morcos> and hope we make it to 500000
11:41 < sdaftuar> if we're lucky we'll get lots of 500000's
11:42 < petertodd> paveljanik: why? why not celibrate an important number like 524288?
11:42 < btcdrak> LOL
11:42 < paveljanik> sdaftuar, ;-)
11:42 < paveljanik> sdaftuar, so many to choose from :-)
11:43 < petertodd> paveljanik: I'm also partial to 0x6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
11:44 < paveljanik> sdaftuar, maybe we can patch UI to help user to select from all #500000s ;-)
11:45 -!- achow101 [~achow101@166.170.28.66] has quit [Quit: Bye]
11:48 < sdaftuar> paveljanik: :)
11:51 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
11:52 < CodeShark> petertodd: my comment regarding PP is not to be understood to mean such layers aren't necessary...but that I think such specification is premature
11:53 < CodeShark> It's sorta like trying to specify ssl before we've even specified tcp
12:07 < zooko> Does the payment protocol use Bitcoin private (signing) keys?
12:07 < jtimon> petertodd: lol, actually you guys need the time machine to review my code in the past, most of what's in https://github.com/jtimon/bitcoin/tree/libconsensus-p3 / https://github.com/jtimon/bitcoin/tree/jt I had coded in some way or another for long (although I constantly rewrite history to try to have the "most mergeable things" as the first commits)
12:09 < jtimon> btcdrak: fwiw all my consensus PRs merged since 0.12 's fork are already backported (with anything that would make the rebase less clean) in https://github.com/jtimon/bitcoin/tree/backports-0.12 in case they were necessary for backporting SF functionality
12:10 < btcdrak> jtimon: great.
12:11 < sipa> zooko: no
12:11 < sipa> it uses ssl :(
12:12 < zooko> Great, so no matter how badly screwed up this new openssl announcement is, openssl isn't being given the opportunity to touch Bitcoin signing keys.
12:12 < zooko> In current Bitcoin core.
12:13 < zooko> Although I fully agree that "No openssl anywhere near our codebase" is a desirable goal.
12:14 < paveljanik> zooko, who created them then? ;-)
12:17 < jtimon> CodeShark: when I first reviewed your BIP9 implementation I first complained aboutthe start time but then reading the code more was convinced that it could actually simplify the implementation, after implementing it myself, I realized it does not simplify things, but it's just a couple of extra lines for a very reaonable feature (specially needed if we are ever going to use versionbits for hardfork deployment as recommended by 
12:17 < jtimon> bip99 anyway)
12:17 < jtimon> I feel sorry for you that it wasn't incorporated to spec at the time
12:19 < jtimon> sipa starttime is block.nTime based? we're using median time for the timeout
12:20 -!- treehug88 [~textual@static-108-30-103-59.nycmny.fios.verizon.net] has quit [Ping timeout: 244 seconds]
12:22 < sipa> jtimon: yes, mediantimepast
12:22 < sipa> jtimon: i mean it is not based on the real clock time, it deoends on the block chain only
12:23 < btcdrak> I can't believe I missed the start time detail
12:25 -!- zooko [~user@c-73-217-16-2.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
12:26 < jtimon> btw, my wip bip9 implementation is #7566 I started before sipa but got distracted maximizing its libconsensus friendly-ness and...sipa codes faster than me
12:27 < jtimon> in any case, it seems we're both copying a little bit of code from one another since we found out we were both working on it
12:48 < GitHub136> [bitcoin] sdaftuar opened pull request #7600: [WIP] Mining: Select transactions using feerate-with-ancestors (master...ancestor-mining) https://github.com/bitcoin/bitcoin/pull/7600
12:50 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
12:52 < instagibbs> what's the correct way to flush the wallet db? I'm "zapping" individual transactions and internal accounting doesn't realize this until I shut down and start back up.
12:53 < jonasschnelli> instagibbs: hmm... could be a bud. Can you explain how you do a "zapping"?
12:53 < jonasschnelli> bug
12:53 < sipa> instagibbs: what do you mean by flush?
12:54 < GitHub141> [bitcoin] ebfull opened pull request #7601: [WIP] HTLC implementation in the wallet (master...zkcp) https://github.com/bitcoin/bitcoin/pull/7601
12:55 < instagibbs> jonasschnelli, I'm rolling my own, which is probably why it's my fault. I'm calling EraseTx.
12:55 < instagibbs> i run my code, check listunspent/listreceivedbyX, transactions are still there. If I shut down, start back up, they're gone.
12:56 < jonasschnelli> call `void CWallet::MarkDirty()`=
12:56 < jonasschnelli> s/=/?
12:56 < instagibbs> ah the whole wallet?
12:56 < instagibbs> makes sense
12:57 < jonasschnelli> hmm... but you can't marke the erased wtx as dirty. :)... not sure if it works.
12:57 < instagibbs> heh, ill test
12:57 < sipa> if you erase a tx, you need to dirty all the transactions that it's spending coins from
12:57 < jonasschnelli> Wait... you only call EraseTx?!
12:57 < jonasschnelli> You also need to remove it from the in memory map
12:58 < instagibbs> that could definitely explain it yes
12:58 < sipa> the mempool?
12:58 < jonasschnelli> no... :)
12:58 < jonasschnelli> mapWallet
12:58 < jonasschnelli> <const uint256, CWalletTx>
12:58 < sipa> i was assuming that that's exactly what EraseTx does
12:58 < instagibbs> nope from the wallet itself
12:59 < instagibbs> ZapWalletTxns calls it on aLL THE THINGS
12:59 < sipa> oh, from the database?
12:59 < sipa> the database has no effect on runtime
12:59 < jonasschnelli> probably you should do: 1. remove from mapWallet, 2. remove from DB (eraseTx), mark whole wallet as dirty 
12:59 < sipa> we only read from it at startup
12:59 < instagibbs> i see ok cool
12:59 < instagibbs> so yeah
12:59 < instagibbs> map
12:59 < instagibbs> thanks jonasschnelli i think that'll do it
12:59 < jonasschnelli> And PR your work. We need a runtime zap wallet tx functionality!
12:59 < instagibbs> I know!
13:00 < instagibbs> belcher was bitching about it in pruned mode :)
13:00 < instagibbs> and i coded the reverse(importprunedfunds), so figured i should do it
13:00 < belcher> to clarify, i was not bitching
13:00 < jonasschnelli> yes. You probably can't zap in prune because of missing rescan functionality 
13:00 < jonasschnelli> belcher: lol
13:00 < instagibbs> ;)
13:01 < instagibbs> jonasschnelli, right, you can't do that zap, so im making no-rescan equiv
13:02 < jonasschnelli> instagibbs: also keep an eye on the "abandontransaction" RPC function
13:02 < jonasschnelli> Could be saver for most usecases then just zapping.
13:22 -!- drnet [~drnett@91.141.3.166.wireless.dyn.drei.com] has joined #bitcoin-core-dev
13:32 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Ping timeout: 260 seconds]
13:34 -!- drnet [~drnett@91.141.3.166.wireless.dyn.drei.com] has quit [Quit: Leaving]
13:41 < GitHub22> [bitcoin] instagibbs opened pull request #7602: [WIP] [RPC] Add call zaptransaction to delete transaction from wallet (master...zaponetx) https://github.com/bitcoin/bitcoin/pull/7602
13:43 -!- danielsocials [~quassel@123.119.91.62] has joined #bitcoin-core-dev
13:48 -!- danielsocials [~quassel@123.119.91.62] has quit [Ping timeout: 276 seconds]
13:49 < jtimon> sipa btcdrak I was going to comment on https://github.com/sipa/bitcoin/commit/99f66325e83f8da3b5dfe38cad4f5fdc60bca05a#commitcomment-16313065 but I thought IRC could be more appropriate:
13:49 < jtimon> See my other comment bike-shedding the enumerator.
13:49 < jtimon> I think it makes a lot of sense that BIP68 and BIP112 are deployed together (in fact, I would have been happy if they had been a single BIP), but I'm not so sure about BIP113.
13:49 < jtimon> @petertodd mentioned that BIP68 required more testing and that's why I went with BIP113 in my implementation (although I'm happy to change it to something else and that will probably mean less code in my PR).
13:49 < jtimon> Assuming BIP9 was reviewed, tested and ready for merge, what would be the BIPs from this 3 that are ready to be deployed right now (modulo backports)?
13:49 < jtimon>  
13:53 < jtimon> BIP113 is ready, right? or do we plan to wait some more time of it being deployed as relay policy ?
13:55 < midnightmagic> I really like this, from the OpenSSL team: "You can not pay us to get security patches in advance."
13:55 < midnightmagic> good for them.
13:56 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has joined #bitcoin-core-dev
14:01 -!- jujumax [~jujumax@host204.200-117-184.telecom.net.ar] has joined #bitcoin-core-dev
14:04 -!- AaronvanW_ [~ewout@f055048210.adsl.alicedsl.de] has quit [Quit: Leaving]
14:12 -!- Expanse [uid146237@gateway/web/irccloud.com/x-tjeuxxkgflhkcpup] has joined #bitcoin-core-dev
14:30 -!- 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]
14:51 -!- Thireus1 [~Thireus@vps-92.197.170.217.stwvps.net] has quit [Ping timeout: 244 seconds]
14:52 -!- Thireus [~Thireus@vps-92.197.170.217.stwvps.net] has joined #bitcoin-core-dev
15:03 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has joined #bitcoin-core-dev
15:17 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev
15:28 -!- AaronvanW [~ewout@f055048210.adsl.alicedsl.de] has joined #bitcoin-core-dev
15:28 -!- AaronvanW [~ewout@f055048210.adsl.alicedsl.de] has quit [Changing host]
15:28 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
15:29 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
15:40 < jtimon> sipa sorry for the bunch of comments in #7575, I edited some of them to make clear they are not very important
15:40 < jtimon> the difference between my implementation and yours that worries me the most is https://github.com/bitcoin/bitcoin/pull/7575/files#r54179238
15:41 < gmaxwell> midnightmagic: the last time they did one of these timed code dumps they also had run the code through a reformat so it was impossible to easily tell what they changed.
15:44 -!- danielsocials [~quassel@123.119.91.62] has joined #bitcoin-core-dev
15:47 < jtimon> one test case comes to mind that my explain my point better: my implementation should be fine if you have if you schedule 3 different deployments for the same bit on the same date (or in three consecutive days), even if each of them takes 3 months to be deployed (the other ones will just wait)
15:48 < jtimon> sipa I believe your implementation would currently fail that test (assuming the test is properly implemented)
15:49 < jtimon> I'm not sure I'm explaining myself...
15:54 < jtimon> but sipa is probably busy, so, never mind, I will maintain the "can queue new deployments on utilized bits without knowing when the previous started deployments on that bit will be activated" feature in mind for now, even if I still don't see a clean wait of making that feature with nicely separating the warning code (while still reusing a lot of code) like you've done
15:57 -!- danielsocials [~quassel@123.119.91.62] has quit [Ping timeout: 240 seconds]
15:57 < jtimon> in the meantime, I think I will decouple my PR from BIP113 (I don't know why #7565 is currently failing in travis anyway, but doesn't inspire confidence) and use BIP112 as example as well
15:59 < jtimon> I guess I should also decouple it from the two first commits in #7563 as well to make it easier to review and compare with #7575
16:00 < jtimon> although I hope to undo the undoing of that work at some point in the future
16:12 < sipa> jtimon: use non-overlapping begin/end dates :)
16:12 < sipa> jtimon: there should never be a need for conflicts on bits
16:13 < jtimon> but what if all the bits are being used? you know the timeout date, but not the activation date
16:13 < sipa> if you don't schedule more than 9 deployments per year, and have 3 year timeouts, you never run out
16:13 < jtimon> realistically, no, more than 29 concurrent deployments are very unlikely
16:17 -!- lightningbot is now known as lightningbot_
16:18 < jtimon> ok, if I sacrifice that feature (which is only really necessary without the start date), I think I can maintain the struct-with-the-current-state-of-all-deployments instead of your individual per-deployment cache while separating the warning check from consensus::getflags() like you've done
16:18  * jtimon reminds a please please please nit
16:20 -!- lightningbot_ is now known as lightningbot
16:21 < aj> gmaxwell: lightningbot is back on #bitcoin-dev; it was blocked from joining because it wasn't registered with nickserv fwiw
16:27 < jtimon> sipa: thoughts on moving to BIP112 instead of BIP113 as an example?
16:31 < sipa> sure
16:31 < sipa> or both
16:35 -!- laurentmt [~Thunderbi@128-79-141-196.hfc.dyn.abo.bbox.fr] has quit [Quit: laurentmt]
16:44 < GitHub96> [bitcoin] JeremyRand opened pull request #7603: Build System: Use PACKAGE_TARNAME in NSIS script (master...nsis-tarname) https://github.com/bitcoin/bitcoin/pull/7603
17:05 < kanzure> a friend has asked me for "ideal introductory (closed) pull requests to read". i sadly don't have a good list. any thoughts?
17:14 < kanzure> i decided to go with bip113 https://github.com/bitcoin/bitcoin/pull/6566/files bip65 https://github.com/bitcoin/bitcoin/pull/6707 mempool-only bip65 https://github.com/bitcoin/bitcoin/pull/6124 and mempool limiting https://github.com/bitcoin/bitcoin/pull/6722
17:14 < kanzure> and zeromq https://github.com/bitcoin/bitcoin/pull/6103/files and libevent https://github.com/bitcoin/bitcoin/pull/5677/files
17:34 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]
17:34 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
17:40 -!- zooko [~user@c-73-229-199-227.hsd1.co.comcast.net] has quit [Ping timeout: 248 seconds]
17:42 < jtimon> sipa well, I'm ok with doing both, but if I deploy BIP113 and you don't, my implementation doesn't have any chance to compete with yours in minimal-ness (just like if I don't decouple it from the commits it has from #7563), anyway, the part that really worries me from using BIP113 as example, is the fact that #7565 is making both (itself and #7566 ) fail on travis, and trying the couple of things that I thought could be causing 
17:42 < jtimon> it didn't help
17:44 < jtimon> I shouldn't need to fix #7565 for #7566 to pass travis, it was supposed to be a bonus-free-super-clean refactoring, if it doesn't do it at this point, should be out of #7566
17:45 < jtimon> even if it's unrelated, review on #7565 very welcomed as well, specially from @wumpus
17:47 < jtimon> because I unburied it from libconsensus-p3 when I saw his #7552, I'm mainly interested in comments related to the relation bettwen #7552 and #7565 (I just thought it was "almost free" for #7566)
17:49 -!- libertalis [~libertali@c-73-207-38-154.hsd1.ga.comcast.net] has quit [Ping timeout: 244 seconds]
17:52 -!- libertalis [~libertali@c-73-207-38-154.hsd1.ga.comcast.net] has joined #bitcoin-core-dev
17:55 -!- danielsocials [~quassel@61.149.223.100] has joined #bitcoin-core-dev
17:56 -!- proslogion [~proslogio@90.209.31.108] has quit [Ping timeout: 276 seconds]
17:57 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Remote host closed the connection]
17:58 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
18:00 -!- Guest19954 [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has joined #bitcoin-core-dev
18:00 -!- Guest19954 is now known as [_smitty]
18:05 -!- danielsocials [~quassel@61.149.223.100] has quit [Ping timeout: 255 seconds]
18:18 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-rdjppzdqxolpcfev] has quit [Quit: Connection closed for inactivity]
18:21 < michagogo> Re: removing OpenSSL
18:21 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
18:21 < michagogo> IIRC Qt depends on it at build time…
18:24 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
18:25 < Luke-Jr> michagogo: good point, we can never truly remove it completely I guess
18:29 < GitHub38> [bitcoin] jtimon closed pull request #7564: libconsensus-p2a: Preparations to decouple libconsensus from coins.o (master...libconsensus-p2a-coins-cpp-interface-0.12.99) https://github.com/bitcoin/bitcoin/pull/7564
18:34 -!- AaronvanW [~ewout@unaffiliated/aaronvanw] has quit [Ping timeout: 276 seconds]
18:37 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 250 seconds]
18:38 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
18:48 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
18:50 < gmaxwell> https://bitcointalk.org/index.php?topic=1377345.0 "Blocksonly mode BW savings, the limits of efficient block xfer, and better relay"
19:03 -!- p15 [~p15@7.91.145.64.client.static.strong-tk2.bringover.net] has joined #bitcoin-core-dev
19:09 -!- jarret [~jarret@162.216.46.123] has quit [Ping timeout: 244 seconds]
19:11 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
19:12 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
19:14 -!- amiller [~socrates1@unaffiliated/socrates1024] has quit [Ping timeout: 248 seconds]
19:16 < GitHub182> [bitcoin] dooglus opened pull request #7604: Remove spurious dollar sign. Fixes #7189. (master...fix_qt4_failback) https://github.com/bitcoin/bitcoin/pull/7604
19:16 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Ping timeout: 248 seconds]
19:17 < petertodd> jtimon: wait, why do you want to decouple bip113? it's a very simple and easy bip, and we really don't want it to become an issue in of itself because it fixes a potential exploit
19:20 -!- Guest86209 [~socrates1@li175-104.members.linode.com] has joined #bitcoin-core-dev
19:36 < jtimon> petertodd: 
19:36 < jtimon> 1) I thought travis was going to love #7565 at the first try but after several of them it doesn't seem like one of those times that travis just doesn't like one particular commit id (ie not solved by add space, squash, remove space, squash), I even tried removing the only change in functionality that I would be happy to renounce. Right now I'm reading #7574 , which I supect contains some answers to my future questions about  #
19:36 < jtimon> 7565.
19:36 < jtimon> TL;DR:  #7565 was supposed to only move functionality reducing some redundancy (and adding some at the same time, but I removed that part), too many unexpected fails for a supposedly non-functionality (I mean, I'm not closing the PR, if it get fixed and merged before #7566 or #7575 all the better)
19:37 < jtimon> 2) I should't had enumerated if I didn't had two points
19:42 < jtimon> petertodd: in any case, github/bitcoin/jtimon/bip9-0.12.99-bip113-just-in-case should be easy to rebase on top of both #7575 and #7566
19:46 -!- jujumax [~jujumax@host204.200-117-184.telecom.net.ar] has quit [Ping timeout: 244 seconds]
19:56 -!- jarret [~jarret@162.216.46.189] has joined #bitcoin-core-dev
19:57 -!- jarret_ [~jarret@162.216.46.160] has joined #bitcoin-core-dev
19:59 < jtimon> stupid me, just trying to replace bip112 with bip113 told me the answer, rebase!
20:00  * jtimon is sorry for thinking out loud
20:00 < jtimon> they cannot all be flag 1U << 10 !
20:01 -!- jarret [~jarret@162.216.46.189] has quit [Ping timeout: 255 seconds]
20:02 -!- danielsocials [~quassel@61.149.223.100] has joined #bitcoin-core-dev
20:03 < Luke-Jr> why not?
20:06 -!- danielsocials [~quassel@61.149.223.100] has quit [Ping timeout: 250 seconds]
20:29 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has joined #bitcoin-core-dev
20:33 -!- Chris_Stewart_5 [~Chris_Ste@173-31-39-168.client.mchsi.com] has quit [Ping timeout: 248 seconds]
20:46 -!- Chris_Stewart_5 [~Chris_Ste@104.156.228.122] has joined #bitcoin-core-dev
20:46 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-ylhmvvxrnmbyosnz] has quit [Quit: Connection closed for inactivity]
20:47 -!- Alopex [~bitcoin@176.9.70.183] has quit [Remote host closed the connection]
20:48 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:54 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds]
20:59 -!- chris2000 [~chris2000@p54AE7A2F.dip0.t-ipconnect.de] has quit [Ping timeout: 250 seconds]
21:03 -!- danielsocials [~quassel@61.149.223.100] has joined #bitcoin-core-dev
21:11 -!- [_smitty] [~chatzilla@97-90-24-187.dhcp.mtpk.ca.charter.com] has quit [Ping timeout: 240 seconds]
21:11 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
21:12 -!- Chris_Stewart_5 [~Chris_Ste@104.156.228.122] has quit [Ping timeout: 255 seconds]
21:13 -!- danielsocials [~quassel@61.149.223.100] has quit [Ping timeout: 248 seconds]
21:39 -!- btcdrak [uid115429@gateway/web/irccloud.com/x-wzkmmjbmhteybnsl] has joined #bitcoin-core-dev
21:49 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
22:13 -!- wallet42 [~wallet42@unaffiliated/wallet42] has quit [Quit: Leaving.]
22:13 -!- wallet42 [~wallet42@unaffiliated/wallet42] has joined #bitcoin-core-dev
22:19 -!- Don_John [~Don@248-223-114-134.nat.resnet.nau.edu] has quit [Read error: Connection reset by peer]
22:29 -!- jarret_ [~jarret@162.216.46.160] has quit [Ping timeout: 240 seconds]
22:29 -!- jarret_ [~jarret@162.216.46.160] has joined #bitcoin-core-dev
23:11 -!- danielsocials [~quassel@61.149.223.100] has joined #bitcoin-core-dev
23:16 -!- danielsocials [~quassel@61.149.223.100] has quit [Ping timeout: 276 seconds]
23:28 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vyqermoneijcjlut] has joined #bitcoin-core-dev
23:45 -!- xiangfu [~xiangfu@111.198.29.53] has joined #bitcoin-core-dev
23:56 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]