19:01:14 <gmaxwell> #startmeeting
19:01:14 <lightningbot> Meeting started Thu Feb 25 19:01:14 2016 UTC.  The chair is gmaxwell. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:14 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:01:35 <gmaxwell> Hello. Welcome to today's meeting (bot is broken in #bitcoin-dev. Topics?
19:02:08 <morcos> Did anyone review 7187 as per last weeks action item?
19:02:14 <morcos> We need punishments
19:02:29 <petertodd> morcos: heh, you're making me glad I was on a plane :)
19:02:30 <btcdrak> I got stuck in traffic, honest
19:03:05 <morcos> Actually to make a topic out of it, lets gameplan a 68/112/113 rollout
19:03:10 <gmaxwell> morcos: we'll end up with people showing up every other meeting it seems. I also wasn't in last week.
19:03:18 <gmaxwell> #topic  68/112/113 rollout
19:03:18 <btcdrak> +1 morcos
19:03:37 <petertodd> so, rollout is made more complex by a non-trivial amount of hashing power nVersion voting for classic
19:03:54 <jonasschnelli> could a bip 68/112/113 softfork be a timestopper for SW?
19:04:09 <gmaxwell> This... again. :(
19:04:11 <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
19:04:14 <petertodd> jonasschnelli: what do you mean by 'timestopper'?
19:04:17 <btcdrak> Yes. I have written an ISM rollout in https://github.com/bitcoin/bitcoin/pull/7561 but we may need to consider BIP9 now
19:04:21 <sdaftuar> has anyone reviewed either of the new versionbits proposals? (i haven't)
19:04:33 <jonasschnelli> timestopper: I guess we can't run two SF at the same time.
19:04:38 <morcos> yes, that should be action item for next week.
19:05:01 <btcdrak> sipa started a BIP9 implementation in https://github.com/bitcoin/bitcoin/pull/7575
19:05:02 <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.
19:05:12 <petertodd> gmaxwell: fwiw I asked f2pool and bitmain to use coinbase to allow hashers to show support rather than nVersion
19:05:37 <petertodd> gmaxwell: 68/112/113 were briefly discussed in HK, with no objections, fwiw
19:05:40 <gmaxwell> I am pretty fond of sipa's BIP9 implementation.
19:05:46 <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
19:06:52 <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.
19:06:52 <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?
19:07:08 <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?"
19:07:29 <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
19:07:36 <morcos> gmaxwell: yes thats my point exactly, i think much less likely to have complaints if we are doing it via bip9
19:07:48 <petertodd> btcdrak: just don't bump the default tx version number yet!
19:07:55 <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
19:08:18 <petertodd> btcdrak: looks good
19:08:50 <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?
19:08:52 <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.
19:09:01 <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.
19:09:14 <btcdrak> I'm building a patch based on #7575
19:09:36 <CodeShark> I personally dislike adding these constants to the CTransaction class
19:09:37 <jonasschnelli> #action talk to BTCD folk about bips 9/68/112/113
19:10:02 <btcdrak> maybe also action review 7575?
19:10:15 <gmaxwell> Should we send a last call-ish like message about 68/112/113 ?
19:10:27 <CodeShark> CTransaction should be relay policy independent as well as consensus independent
19:10:28 <petertodd> gmaxwell: ack
19:10:30 <btcdrak> gmaxwell: in what way?
19:10:53 <gmaxwell> btcdrak: "We're thinkin about moving these to deployment. Speak now or be mocked when you complain later."
19:10:53 <morcos> CodeShark: are you referring to BIP68 stuff.  (I mostly agree, but we merged that already)
19:10:54 <petertodd> CodeShark: I think that's a reasonable concern
19:10:59 <sdaftuar> gmaxwell: ack
19:11:10 <btcdrak> gmaxwell: yes that would be great. I had been contemplating this.
19:11:26 <gmaxwell> #action Send email re-68/112/113 deployment.
19:11:30 <petertodd> gmaxwell: probably worth mentioning that we're considering version bits due to classic conflicts
19:11:40 <morcos> Who is taking that action item
19:11:46 <sipa> hi, i'm on bad internet in barbados
19:12:08 <gmaxwell> I could do it but I'm not ideal; not super up to date on the history there.
19:12:10 <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
19:12:16 <CodeShark> sipa: what's the status on bip 9?
19:12:46 <petertodd> morcos: eh, that's reasonable if we think we're close
19:13:02 <sipa> CodeShark: i started working on some other changes to the bip (disambiguate some things, add a state transition diagram, and add start time)
19:13:03 <jonasschnelli> morcos: do you want to take the action-item for email re-68/112/113 deployment?
19:13:17 <morcos> sure unless btcdrak wants it
19:13:31 <btcdrak> morcos: I'll pass :)
19:13:34 <sipa> CodeShark: but not submitted yet
19:13:48 <jonasschnelli> morocs has "a white vest".
19:14:02 <btcdrak> sipa: is #7575 not up to date?
19:14:12 <jonasschnelli> 7575 was updated today
19:14:16 <sipa> btcdrak: is that my pr?
19:14:19 <gmaxwell> jonasschnelli: all the better to show the gunshot wounds.
19:14:26 <jonasschnelli> gmaxwell... haha
19:14:28 <sipa> btcdrak: it impkements a start time, which is not in bip9
19:14:56 <btcdrak> sipa: oh, _that_ is why my RPC tests did not work....
19:14:58 <morcos> uhh
19:14:58 <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
19:15:04 <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.
19:15:09 <btcdrak> sipa: I was going bananas
19:15:27 <sipa> sorry for typing, in a bumpy car
19:15:42 <CodeShark> argh...I added and removed a start time several times to the bip :p
19:15:52 <sipa> CodeShark: i know, sorry
19:16:06 <sipa> i believe we need one, but i want some other explanations on the bip too
19:16:07 <btcdrak> sipa: I agree with starttime, prefer it.
19:16:22 <sipa> there are different ways to do it
19:16:46 <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
19:16:58 <gmaxwell> I can't imagine doin BIP9 without a start time. Rusty was opposed on principle, I think, but expirence trumps.
19:17:00 <btcdrak> sipa: so I'll have to mock time for the RPC test
19:17:11 <petertodd> gmaxwell: by start time, you mean minimum possible activation data right?
19:17:13 <morcos> btcdrak can simultaneously work on getting the 68/112/113 ready to use it
19:17:19 <petertodd> gmaxwell: or grace period post-activation?
19:17:20 <sdaftuar> fyi 7575 is still failing travis, haven't dived in to see what is wrong
19:17:24 <gmaxwell> morcos: people reviewing should keep in mind that intentional discrepency with the BIP at the moment.
19:17:28 <morcos> we need both of those and 7187 merged for backport
19:17:36 <morcos> gmaxwell: noted.  :)
19:17:49 <CodeShark> https://github.com/bitcoin/bips/pull/219 didn't even get merged over this whole starttime crap :(
19:18:03 <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.
19:18:07 <CodeShark> Which wasn't even the main point of that PR
19:18:13 <btcdrak> morcos: yeah it's basically done, modulo converting the RPC tests from my ISM PR.
19:18:34 <petertodd> gmaxwell: right, any idea on how many months after final release that should be?
19:18:46 <sipa> btcdrak: starttime is blocktime based, not real time; you don't need mocktime
19:19:10 <sipa> morcos: 7575 is where i want it to be, but the logic should also go in bip9
19:19:31 <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.
19:19:43 <sipa> CodeSharki'll have a look at your pr to the bip again
19:19:55 <petertodd> gmaxwell: ok, so maybe 1-2 months?
19:20:11 <btcdrak> our roadmap FAQ tentatively pencilled BIP68,112,113 for March.
19:20:14 <sipa> sdaftuar: if tests still fails, the pr is certainly not where it should be regarding tests
19:20:31 <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?
19:20:53 <morcos> why not? at 95% miner threshold and with innocous soft forks, it should be ok to do it sooner.
19:20:56 <CodeShark> We need to start getting into the habit of publishing less optimistic schedules ;)
19:21:14 <morcos> maybe something a bit more invasive (like segwit) then you could put a couple 1000 block delay
19:21:15 <gmaxwell> morcos: ideally nodes are updated first, though it's not strictly needed.
19:21:15 <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)
19:21:26 <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.
19:21:26 <gmaxwell> morcos: because you want them rejecting any blocks from that 5% that are not valid.
19:21:35 <CodeShark> However long you think anything could reasonably take, double it for public expectations
19:21:45 <petertodd> morcos: one argument for it, is it can be done in about one line of code - cheap protection
19:22:13 <petertodd> CodeShark: yeah, so a practical problem, is you'd be changing unit tests right up until the last minute pre-release
19:22:35 <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
19:22:50 <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
19:22:53 <petertodd> CodeShark: less important if the minimum start time is far into the future, but 1-2 months isn't
19:22:54 <morcos> that might be good
19:23:04 <petertodd> morcos: yeah, 100% ok to signal immediately
19:23:05 <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.
19:23:38 <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
19:23:51 <btcdrak> petertodd: exactly.
19:24:15 <petertodd> alright, ack 1-2 month min start time
19:25:30 <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).
19:26:28 <petertodd> btcdrak: I suggest we buy jtimom a time machine so he can do his refactors in the past :)
19:26:40 <petertodd> *jtimon
19:28:52 <gmaxwell> Any other topics? (we can discuss BIP9 more out of meeting and maybe when sipa has better connectivity?
19:29:04 <sipa> i'm going afk now; i'll look at bip9 and 7575 and tests next week
19:30:02 <petertodd> I'm working on a tech writeup re: HK
19:30:46 <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
19:31:35 <petertodd> warren: interesting!
19:31:38 <gmaxwell> #topic openssl drama again
19:31:54 <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.
19:32:37 <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.
19:32:54 <petertodd> gmaxwell: and fortunately, PP isn't consensus critical, which helps a bit
19:33:04 <morcos> oh so i don't need to ever bother figuring out what PP is?
19:33:10 <petertodd> morcos: payment protocol
19:33:16 <gmaxwell> petertodd: still means we need to roll emergency updates for serious openssl vulnerabilties.
19:33:27 <morcos> i just mean i haven't looked at the code
19:33:43 <warren> Does anyone use rpcssl?
19:33:46 <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
19:33:49 <gmaxwell> It's written in QT, uses QT for HTTP.
19:33:52 <gmaxwell> warren: thats gone.
19:33:56 <warren> oh good
19:34:22 <gmaxwell> petertodd: I know nothing about windows packaging. I did believe we installed a URL handler.
19:35:24 <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.
19:35:24 <petertodd> gmaxwell: we can always do a release where you need a command line flag to enable it and see if anyone notices :)
19:35:56 <gmaxwell> petertodd: thats kind of what I was thinking with the GUI option too "If you've turned this on, please report to..."
19:36:32 <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
19:37:16 <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
19:38:15 <CodeShark> PP is dumb
19:38:50 <petertodd> CodeShark: eh, it goes in the right direction, it's just not so useful in the current environment
19:39:36 <CodeShark> silly to try to specify it when so many more fundamental things still aren't solved ;)
19:39:56 <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!)
19:40:02 <gmaxwell> Okay any other topics?
19:41:02 <gmaxwell> Otherwise, I'm going to call the end.
19:41:15 <petertodd> ack
19:41:18 <gmaxwell> #endmeeting