< * Luke-Jr>
prods cfields to fix the OSX SDK from Travis..
< btcdrak>
Luje-Jr: what's wrong with it?
< Luke-Jr>
btcdrak: it's Forbidden as usual
< btcdrak>
link?
< btcdrak>
oh the SDK, yeah.
< 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
< cfields>
Luke-Jr: just grepped the logs and guessed on a range based on what was failing. fingers crossed, should work now.
< gmaxwell>
#startmeeting
< lightningbot>
Meeting started Thu Feb 25 19:01:14 2016 UTC. The chair is gmaxwell. Information about MeetBot at http://wiki.debian.org/MeetBot.
< gmaxwell>
Hello. Welcome to today's meeting (bot is broken in #bitcoin-dev. Topics?
< morcos>
Did anyone review 7187 as per last weeks action item?
< morcos>
We need punishments
< petertodd>
morcos: heh, you're making me glad I was on a plane :)
< btcdrak>
I got stuck in traffic, honest
< morcos>
Actually to make a topic out of it, lets gameplan a 68/112/113 rollout
< gmaxwell>
morcos: we'll end up with people showing up every other meeting it seems. I also wasn't in last week.
< gmaxwell>
#topic 68/112/113 rollout
< btcdrak>
+1 morcos
< petertodd>
so, rollout is made more complex by a non-trivial amount of hashing power nVersion voting for classic
< jonasschnelli>
could a bip 68/112/113 softfork be a timestopper for SW?
< gmaxwell>
This... again. :(
< 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
< petertodd>
jonasschnelli: what do you mean by 'timestopper'?
< 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.
< petertodd>
gmaxwell: fwiw I asked f2pool and bitmain to use coinbase to allow hashers to show support rather than nVersion
< petertodd>
gmaxwell: 68/112/113 were briefly discussed in HK, with no objections, fwiw
< gmaxwell>
I am pretty fond of sipa's BIP9 implementation.
< 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
< 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.
< 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?
< 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?"
< 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
< morcos>
gmaxwell: yes thats my point exactly, i think much less likely to have complaints if we are doing it via bip9
< petertodd>
btcdrak: just don't bump the default tx version number yet!
< 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?
< 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.
< 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.
< btcdrak>
I'm building a patch based on #7575
< CodeShark>
I personally dislike adding these constants to the CTransaction class
< jonasschnelli>
#action talk to BTCD folk about bips 9/68/112/113
< btcdrak>
maybe also action review 7575?
< gmaxwell>
Should we send a last call-ish like message about 68/112/113 ?
< CodeShark>
CTransaction should be relay policy independent as well as consensus independent
< petertodd>
gmaxwell: ack
< btcdrak>
gmaxwell: in what way?
< gmaxwell>
btcdrak: "We're thinkin about moving these to deployment. Speak now or be mocked when you complain later."
< morcos>
CodeShark: are you referring to BIP68 stuff. (I mostly agree, but we merged that already)
< petertodd>
CodeShark: I think that's a reasonable concern
< sdaftuar>
gmaxwell: ack
< btcdrak>
gmaxwell: yes that would be great. I had been contemplating this.
< petertodd>
gmaxwell: probably worth mentioning that we're considering version bits due to classic conflicts
< morcos>
Who is taking that action item
< sipa>
hi, i'm on bad internet in barbados
< gmaxwell>
I could do it but I'm not ideal; not super up to date on the history there.
< 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
< CodeShark>
sipa: what's the status on bip 9?
< petertodd>
morcos: eh, that's reasonable if we think we're close
< sipa>
CodeShark: i started working on some other changes to the bip (disambiguate some things, add a state transition diagram, and add start time)
< jonasschnelli>
morcos: do you want to take the action-item for email re-68/112/113 deployment?
< morcos>
sure unless btcdrak wants it
< btcdrak>
morcos: I'll pass :)
< sipa>
CodeShark: but not submitted yet
< jonasschnelli>
morocs has "a white vest".
< btcdrak>
sipa: is #7575 not up to date?
< jonasschnelli>
7575 was updated today
< sipa>
btcdrak: is that my pr?
< gmaxwell>
jonasschnelli: all the better to show the gunshot wounds.
< jonasschnelli>
gmaxwell... haha
< sipa>
btcdrak: it impkements a start time, which is not in bip9
< btcdrak>
sipa: oh, _that_ is why my RPC tests did not work....
< morcos>
uhh
< 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
< 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.
< btcdrak>
sipa: I was going bananas
< sipa>
sorry for typing, in a bumpy car
< CodeShark>
argh...I added and removed a start time several times to the bip :p
< sipa>
CodeShark: i know, sorry
< sipa>
i believe we need one, but i want some other explanations on the bip too
< btcdrak>
sipa: I agree with starttime, prefer it.
< sipa>
there are different ways to do it
< 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
< gmaxwell>
I can't imagine doin BIP9 without a start time. Rusty was opposed on principle, I think, but expirence trumps.
< btcdrak>
sipa: so I'll have to mock time for the RPC test
< petertodd>
gmaxwell: by start time, you mean minimum possible activation data right?
< morcos>
btcdrak can simultaneously work on getting the 68/112/113 ready to use it
< petertodd>
gmaxwell: or grace period post-activation?
< sdaftuar>
fyi 7575 is still failing travis, haven't dived in to see what is wrong
< gmaxwell>
morcos: people reviewing should keep in mind that intentional discrepency with the BIP at the moment.
< morcos>
we need both of those and 7187 merged for backport
< 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.
< CodeShark>
Which wasn't even the main point of that PR
< btcdrak>
morcos: yeah it's basically done, modulo converting the RPC tests from my ISM PR.
< petertodd>
gmaxwell: right, any idea on how many months after final release that should be?
< sipa>
btcdrak: starttime is blocktime based, not real time; you don't need mocktime
< sipa>
morcos: 7575 is where i want it to be, but the logic should also go in bip9
< 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.
< sipa>
CodeSharki'll have a look at your pr to the bip again
< petertodd>
gmaxwell: ok, so maybe 1-2 months?
< btcdrak>
our roadmap FAQ tentatively pencilled BIP68,112,113 for March.
< sipa>
sdaftuar: if tests still fails, the pr is certainly not where it should be regarding tests
< 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?
< morcos>
why not? at 95% miner threshold and with innocous soft forks, it should be ok to do it sooner.
< CodeShark>
We need to start getting into the habit of publishing less optimistic schedules ;)
< morcos>
maybe something a bit more invasive (like segwit) then you could put a couple 1000 block delay
< gmaxwell>
morcos: ideally nodes are updated first, though it's not strictly needed.
< 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)
< 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.
< gmaxwell>
morcos: because you want them rejecting any blocks from that 5% that are not valid.
< CodeShark>
However long you think anything could reasonably take, double it for public expectations
< petertodd>
morcos: one argument for it, is it can be done in about one line of code - cheap protection
< petertodd>
CodeShark: yeah, so a practical problem, is you'd be changing unit tests right up until the last minute pre-release
< 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
< 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
< petertodd>
CodeShark: less important if the minimum start time is far into the future, but 1-2 months isn't
< morcos>
that might be good
< petertodd>
morcos: yeah, 100% ok to signal immediately
< 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.
< 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
< btcdrak>
petertodd: exactly.
< petertodd>
alright, ack 1-2 month min start time
< 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).
< petertodd>
btcdrak: I suggest we buy jtimom a time machine so he can do his refactors in the past :)
< petertodd>
*jtimon
< gmaxwell>
Any other topics? (we can discuss BIP9 more out of meeting and maybe when sipa has better connectivity?
< sipa>
i'm going afk now; i'll look at bip9 and 7575 and tests next week
< 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.
< 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.
< petertodd>
gmaxwell: and fortunately, PP isn't consensus critical, which helps a bit
< morcos>
oh so i don't need to ever bother figuring out what PP is?
< petertodd>
morcos: payment protocol
< gmaxwell>
petertodd: still means we need to roll emergency updates for serious openssl vulnerabilties.
< morcos>
i just mean i haven't looked at the code
< warren>
Does anyone use rpcssl?
< 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
< gmaxwell>
It's written in QT, uses QT for HTTP.
< gmaxwell>
warren: thats gone.
< warren>
oh good
< gmaxwell>
petertodd: I know nothing about windows packaging. I did believe we installed a URL handler.
< 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.
< petertodd>
gmaxwell: we can always do a release where you need a command line flag to enable it and see if anyone notices :)
< gmaxwell>
petertodd: thats kind of what I was thinking with the GUI option too "If you've turned this on, please report to..."
< 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
< 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
< CodeShark>
PP is dumb
< petertodd>
CodeShark: eh, it goes in the right direction, it's just not so useful in the current environment
< CodeShark>
silly to try to specify it when so many more fundamental things still aren't solved ;)
< 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!)
< gmaxwell>
Okay any other topics?
< gmaxwell>
Otherwise, I'm going to call the end.
< petertodd>
ack
< gmaxwell>
#endmeeting
< lightningbot>
Meeting ended Thu Feb 25 19:41:18 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sdaftuar>
if we're lucky we'll get lots of 500000's
< petertodd>
paveljanik: why? why not celibrate an important number like 524288?
< btcdrak>
LOL
< paveljanik>
sdaftuar, ;-)
< paveljanik>
sdaftuar, so many to choose from :-)
< petertodd>
paveljanik: I'm also partial to 0x6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
< paveljanik>
sdaftuar, maybe we can patch UI to help user to select from all #500000s ;-)
< sdaftuar>
paveljanik: :)
< 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
< CodeShark>
It's sorta like trying to specify ssl before we've even specified tcp
< zooko>
Does the payment protocol use Bitcoin private (signing) keys?
< 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
< btcdrak>
jtimon: great.
< sipa>
zooko: no
< sipa>
it uses ssl :(
< 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.
< zooko>
In current Bitcoin core.
< zooko>
Although I fully agree that "No openssl anywhere near our codebase" is a desirable goal.
< paveljanik>
zooko, who created them then? ;-)
< 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
< jtimon>
bip99 anyway)
< jtimon>
I feel sorry for you that it wasn't incorporated to spec at the time
< jtimon>
sipa starttime is block.nTime based? we're using median time for the timeout
< sipa>
jtimon: yes, mediantimepast
< sipa>
jtimon: i mean it is not based on the real clock time, it deoends on the block chain only
< btcdrak>
I can't believe I missed the start time detail
< 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
< 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
< 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
< 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.
< jonasschnelli>
instagibbs: hmm... could be a bud. Can you explain how you do a "zapping"?
< jtimon>
See my other comment bike-shedding the enumerator.
< 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.
< 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).
< 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)?
< jtimon>
< jtimon>
BIP113 is ready, right? or do we plan to wait some more time of it being deployed as relay policy ?
< midnightmagic>
I really like this, from the OpenSSL team: "You can not pay us to get security patches in advance."
< midnightmagic>
good for them.
< jtimon>
sipa sorry for the bunch of comments in #7575, I edited some of them to make clear they are not very important
< 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.
< 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)
< jtimon>
sipa I believe your implementation would currently fail that test (assuming the test is properly implemented)
< jtimon>
I'm not sure I'm explaining myself...
< 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
< 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
< 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