19:00:10 <wumpus> #startmeeting
19:00:10 <lightningbot> Meeting started Thu Feb  1 19:00:10 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:10 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:25 <provoostenator> hi
19:00:32 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
19:00:34 <achow101> hi
19:00:35 <jonasschnelli> hi
19:00:39 <cfields> hi
19:00:52 <sdaftuar> ack
19:00:58 <jcorgan> hey folks
19:01:04 <meshcollider> hi
19:01:08 <luke-jr> hi
19:01:14 <BlueMatt> 0.16!
19:01:19 <meshcollider> \o/
19:01:23 <wumpus> so with regard for 0.16.0 status, there already have been some issues that came up with rc1, so I think it makes sense to skip uploading binaries for that and go to rc2 soon
19:01:30 <BlueMatt> ack
19:01:31 <achow101> what issues?
19:01:32 <cfields> agreed
19:01:48 <cfields> achow101: see backlog for the last ~3hrs
19:02:01 <wumpus> https://github.com/bitcoin/bitcoin/milestone/30
19:02:18 <wumpus> the serious issue is https://github.com/bitcoin/bitcoin/issues/12323
19:02:46 <achow101> ok
19:03:24 <wumpus> there's another issue with onetry connections being re-tried forever, resulting in potential DoS on DNS seeds in the case they temporarily fail
19:03:34 <wumpus> cfields is working on a patch for that
19:03:42 <instagibbs> oh right, thursday
19:03:59 <wumpus> https://github.com/bitcoin/bitcoin/pull/12327 fixes a more minor issue with coin control and the change type setting
19:04:05 <wumpus> in the gui
19:04:20 <jonasschnelli> by the way, is it a policy that a DNS seed also runs a node (same ip) for the oneshot?
19:04:34 <wumpus> jonasschnelli: no, that's not necessary
19:04:48 <wumpus> jonasschnelli: it looks up the DNS seed which will return a (the first?) node
19:04:51 <jonasschnelli> wumpus: okay. My seeders will refuse connections to 8333
19:05:02 <jonasschnelli> wumpus: okay.
19:05:34 <wumpus> jonasschnelli: that is not the IP of the DNS server. I was confused about that too at some point in the past.
19:05:50 <jonasschnelli> I think also has something do to with tor mode
19:05:54 <provoostenator> Using A records is what makes it confusing
19:05:54 <cfields> yea, it's just some random peer
19:06:18 <BlueMatt> jonasschnelli: yes, you'd have to include your own ip in the dnsseed to (maybe) get the oneshot to be you, but that would be bad, and a violation of dnsseed policy (IIRC)
19:06:32 <jonasschnelli> BlueMatt: sure.
19:06:41 <wumpus> yes, in tor mode no resolving is used to get  multiple results (that'd require some SOCKS5 extension being used), so it uses a one shot to a random node as replacement
19:06:53 <jonasschnelli> But in tor only mode, don't we do a oneshot to the seeds?
19:06:58 <wumpus> no
19:06:58 <provoostenator> BlueMatt: and an effective way to DDOS yourself
19:07:12 <jonasschnelli> wumpus: okay. Thanks... never looked that up properly
19:07:30 <wumpus> it never looks up the IP of the DNS server at all, that's all happening below the libc abstraction
19:07:49 <wumpus> any topics?
19:10:03 <jonasschnelli> Everyone already back at work it seems
19:10:04 <wumpus> ok.. seems not... well please review anything under the 0.16.0 milestone, and anything added in the next day too
19:10:09 <sdaftuar> if we don't have more pressing things to discuss, i'd like to solicit feedback on #11739 (backdating p2sh /segwit v0 script rules) to genesis
19:10:12 <gribble> https://github.com/bitcoin/bitcoin/issues/11739 | Enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis by sdaftuar · Pull Request #11739 · bitcoin/bitcoin · GitHub
19:10:14 <wumpus> then we'll tag rc2 after that
19:10:42 <wumpus> and try to find the next round of bugs :)
19:10:50 <bitcoin-git> [13bitcoin] 15theuni opened pull request #12329: net: don't retry failed oneshot connections forever (06master...06no-infinite-oneshot) 02https://github.com/bitcoin/bitcoin/pull/12329
19:10:51 <wumpus> sdaftuar: okay
19:11:03 <sdaftuar> mostly i want to know if there are any concept NACKs
19:11:14 <wumpus> #topic enforce SCRIPT_VERIFY_P2SH and SCRIPT_VERIFY_WITNESS from genesis (sdaftuar)
19:12:17 <sdaftuar> and i guess the other question is confirming whether/how such a change should be documented
19:12:19 <cfields> +0
19:12:40 <cfields> sdaftuar: going forward, you mean? or this one?
19:12:44 <sdaftuar> both?
19:12:48 <sdaftuar> i drafted a BIP for this one
19:13:05 <cfields> well going forward, i think we could specify this intention as part of a soft-fork bip?
19:13:06 <wumpus> no NACK from me, if the code can be simplified that way then it's great
19:13:29 <BlueMatt> +1
19:13:34 <wumpus> it doesn't change the rules enforced for current blocks, does it?
19:13:38 <wumpus> how is it a softfork?
19:13:42 <sdaftuar> no effect on current blocks
19:13:56 <wumpus> if it's a softfork I am misunderstanding
19:14:04 <BlueMatt> its a soft spoon - only prevents a 6-month reorg from removing segwit :p
19:14:06 <luke-jr> it restricts the rules on older blocks
19:14:07 <sdaftuar> it's a softfork under a technical definition
19:14:10 <BlueMatt> not a fork
19:14:18 <sdaftuar> of making valid things now invalid
19:14:21 <cfields> sorry, my fault.
19:14:29 <morcos> +1 as well..  but i do have concerns about how we could do this on a going forward basis
19:14:30 <wumpus> oh, right
19:14:38 <provoostenator> Or just Buried Deployment?
19:14:39 <wumpus> but it makes no difference bencause the old blocks all qualify
19:14:41 <luke-jr> the question comes down to, are we limiting soft/hardfork definitions to only ones that affect future blocks?
19:14:43 <morcos> it seems like if this is always our intention, then as soon as we announce a future soft fork
19:14:53 <morcos> some jack ass is going to mine violations just to make us annoyed
19:15:00 <BlueMatt> luke-jr: yes, we should start calling buried deployments spoons
19:15:02 <luke-jr> or do we consider this an implementation detail?
19:15:13 <cfields> morcos: true
19:15:17 <sdaftuar> morcos: i think it's not really worth worrying about that
19:15:21 <wumpus> I see this as an implementation detail to validation
19:15:32 <wumpus> there's no need to cause a lot of rufus about it
19:15:42 <wumpus> if you call it softfork you'll have the miners in arms, and whatnot
19:15:43 <cfields> luke-jr: well if there's an absolutely massive reorg, it's not just an implementation detail, no?
19:15:48 <morcos> well it addresses cfields point about having the original BIP specify the intention.  i think we should always only consider backdating after the fact
19:16:03 <sdaftuar> morcos: oh i see your point
19:16:07 <wumpus> because then it also needs to be signaled some way, I guess
19:16:10 <luke-jr> cfields: if there's an absolutely massive reorg, it's unclear what the outcome will be period
19:16:24 <luke-jr> cfields: for example, Knots has a checkpoint on a Segwit block
19:16:30 <cfields> well isn't the intention here to clarify that outcome?
19:16:32 <BlueMatt> if there's a 6 month reorg there will be debate as to whether to follow it...whether we follow it or not ends up being a community question anyway :p
19:16:35 <wumpus> if there's a reorg that big that all segwit blocks are reorged out, well...
19:16:53 <sdaftuar> i think in this case, it's clear that segwit transactors do not intend for their funds to be spendable on a segwit-inactive chain
19:17:00 <wumpus> yes, I'm sure there will be discussion enough in that case
19:17:14 <sdaftuar> so backdating the segwit rules matches consensus, in that sense
19:17:15 <BlueMatt> so, definitely not a fork
19:17:22 <wumpus> right
19:18:10 <luke-jr> in which case, I don't see that we need a BIP for it. I suggest we make a new repo for Core-specific documentation like this.
19:18:26 <cfields> morcos: i half agree about after-the-fact. Not mentioning backdating with the intention of doing so anyway is a bit... iffy
19:18:31 <luke-jr> BIPs are for cross-software standards, which doesn't really include implementation details
19:18:34 <BlueMatt> seems fine to me, I also appreciate gmaxwell's partially-joking suggestion of calling it a spoon
19:18:48 <wumpus> hehe
19:18:51 <luke-jr> (actually, we have a repo for gitian docs already, right?)
19:18:51 <sdaftuar> i personally think that it's helpful to put it in a BIP, because it affects the implementation of existing BIPs
19:18:52 <BlueMatt> and then doing a bip and just saying "Soft Spoon"
19:19:05 <sdaftuar> but i don't feel strongly
19:19:19 <BlueMatt> i mean we use BIPs for things that are core-specific anyway, like getblocktemplate
19:19:23 <wumpus> but in the end it doesn't matter whether people implement this BIP
19:19:27 <wumpus> because it's an implementation detail
19:19:27 <luke-jr> BlueMatt: GBT isn't Core-specific
19:19:29 <sdaftuar> wumpus: agreed
19:19:32 <sdaftuar> it's an informational BIP
19:19:37 <cfields> luke-jr: there are several post-mortem BIPs
19:19:38 <wumpus> BlueMatt: well that's an interface! interfaces need documentation
19:19:42 <kanzure> hi.
19:20:29 <luke-jr> maybe we can put it in an annex for the BIPs it affects or something? just seems like it will get old to have two BIPs for every fork
19:20:37 <wumpus> if a softspoon drops at 300000 blocks deep and no one hears it, did it happen at all?
19:20:44 <luke-jr> one for the deployment and implementation, and another for the reinterpretation of the deployment
19:20:54 <sdaftuar> luke-jr: that seems reasonable to me as well, if the BIP authors agree?
19:22:08 <wumpus> luke-jr: agree
19:22:25 <luke-jr> none of the authors appear to be here now, but I doubt they'd object
19:22:34 <luke-jr> at least for Segwit
19:23:32 <provoostenator> And the winner of the git bisect game is....
19:23:37 <provoostenator> bluematt! https://github.com/bitcoin/bitcoin/commit/62e764219b25f5d5a4de855e53f62c43130ec918
19:23:57 <BlueMatt> we already decided it was cfields' fault
19:24:07 <sdaftuar> i knew it was both of you
19:24:08 * BlueMatt is gonna keep repeating that until someone buys it
19:24:10 <sdaftuar> :)
19:24:21 * BlueMatt *definitely* didnt also review and ack the bug-introducing pr......
19:24:23 <cfields> heh it was me for sure
19:24:41 <cfields> the busted part of 62e7642 was even my suggestion!
19:25:10 <wumpus> it's everyone's fault for not finding the fault in review! :)
19:25:17 <sdaftuar> +1
19:25:32 <cfields> well, sorry everyone. I'm glad it didn't make it into a release.
19:25:52 <luke-jr> I'm glad someone noticed it before a release XD
19:25:54 <wumpus> the rc process, it works
19:26:15 <cfields> yea, the surge of reports in the last ~day is actually really nice to see
19:26:19 <provoostenator> Bad linux skills on my part (causing the seed not to restart): it works
19:26:38 <sdaftuar> good thing it was down or we never would have found this before release!
19:26:44 <sdaftuar> (which is very disturbing)
19:26:54 <wumpus> we do need tests for the DNS seed code
19:27:02 <meshcollider> clearly
19:27:04 <provoostenator> +1 for tests there
19:27:15 <cfields> agreed. I'll add some.
19:27:20 <BlueMatt> lol, maybe keep your dnsseed down until after rc cycle? :P
19:27:57 <wumpus> any other topics?
19:28:07 <cfields> or we could just add a dummy seednode to test.com or something :p
19:30:03 <wumpus> testing that code is not entirely trivial as-is as you somehow need to redirect DNS resolving
19:30:22 <wumpus> if no other topics, I'm closing the meeting early
19:30:43 <wumpus> #endmeeting