18:59:45 <wumpus> #startmeeting
18:59:45 <lightningbot> Meeting started Thu Aug 11 18:59:45 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:59:45 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:00:25 <sipa> present
19:00:37 <wumpus> sipa proposed some topics earlier today: 1) segwit policy limits  2) can we propose a softfork to make low-s required simultaneously with segwit?  3) 3) raising mandatory script flags to include bip66 4)
19:00:41 <wumpus> eh no 4
19:01:11 <wumpus> can anyone do the giant highlight list?
19:01:44 <jonasschnelli> ping gmaxwell
19:01:47 <cfields> gmaxwell: paging bot
19:01:50 <gmaxwell> #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
19:01:55 <kanzure> hi.
19:02:08 <instagibbs> oops, it's not wednesday, how about that
19:02:08 <wumpus> thanks
19:02:41 <luke-jr> heh
19:02:47 <wumpus> another topic would be rc3 go-ahead
19:02:48 <kanzure> not sure about priority but jtimon was asking for code review eyeballs on #8493
19:03:05 <wumpus> but let's start with sipa's topics
19:03:07 <btcdrak> hi
19:03:14 <wumpus> #topic segwit policy limits
19:03:27 <michagogo> cfields: I think last time he said it's not a bot...
19:03:48 <cfields> michagogo: was a joke :)
19:03:49 <gmaxwell> it's just an alias.
19:03:50 <wumpus> michagogo: all bots say that!
19:03:51 <sipa> jl2012 has suggested some changes to prevent DoS attacks with segwit
19:04:08 <michagogo> Also, if anyone's interested I think the KSK ceremony is starting soon
19:04:21 <sipa> do we in addition want per txin witness size limits or so
19:04:56 <wumpus> may make sense to add some initial limits, they can always be removed later
19:05:02 <wumpus> adding limits later is more controversial
19:05:14 <sipa> agree
19:05:51 <instagibbs> is this merely to offset people stuffing data for 25% the price
19:05:54 <sipa> but i'd like to know what opinions people have about this
19:06:06 <instagibbs> could you elaborate additional motivations if any
19:06:07 <jl2012> this is a conceptual PR: https://github.com/bitcoin/bitcoin/pull/8499
19:06:11 <wumpus> ofc
19:06:18 <luke-jr> a policy limit matching p2sh's consensus limit sounds uncontroversial
19:06:37 <luke-jr> but this is too small for N-of->15, so maybe slightly larger is desirable
19:07:28 <luke-jr> someone involved with Lightning probably should comment as well
19:07:58 <wumpus> yes, it would be important not to sabotage that
19:08:28 <btcdrak> ping roasbeef GreenIsMyPepper rusty ^
19:08:33 <instagibbs> could someone tell me what we're protecting against first? I can't really form an opinion
19:09:06 <jtimon> is this a new consensus rule or just policy? (looking at 8499 seems policy only, just want to confirm)
19:09:12 <sipa> jl2012: policy
19:09:16 <sipa> eh, jtimon ^
19:09:16 <kanzure> instagibbs: txin witness size bloating
19:09:20 <jtimon> thanks
19:10:05 <sipa> jl2012: 8499 does not set a size limit, right?
19:10:35 <instagibbs> 8499 I think just bans peers for bad witnesses
19:10:58 <sipa> instagibbs: also protection against the problems discussed in #8279
19:11:18 <jl2012> sipa: it's per input size limit
19:11:26 <instagibbs> sipa, yes, makes sense
19:11:37 <sipa> ok
19:12:11 <sipa> jl2012: but no limits for p2wsh
19:12:39 <sipa> (sorry, i haven't looked in detail; correct me if i'm wrong)
19:13:53 <sipa> seems there are not too many opinions; i'll propose some thing for next meeting
19:14:19 <sipa> next topic?
19:14:50 <wumpus> #topic softfork to make low-s required simultaneously with segwit
19:15:37 <wumpus> there was some discussion about this earliet today between sipa and jl2012
19:15:38 <luke-jr> IIRC, this just blocks transactions that can be fixed with malleation anyway. might as well.
19:15:39 <wumpus> <jl2012> sipa: why would you like to have a low-s softfork? And is it for segwit  scripts only, or for all scripts?
19:15:39 <wumpus> <sipa> jl2012: it's already nonstandard for a long time, it doesn't hurt anyone, and removes a source of malleability
19:15:39 <wumpus> <jl2012> so you want it for non-segwit scripts too?
19:15:39 <wumpus> <sipa> well to be discussed
19:15:52 <murch> Are there any downsides to that?
19:15:57 <sipa> so it was recently suggested that since low-s has been non-standard and not present on the network for over a year now, we could propose to turn it into a consensus rules
19:16:06 <wumpus> <jl2012> with low-s rule, even the wtxid of a p2wpkh tx is not malleable
19:16:13 <wumpus> <jl2012> I don't see a compelling reason to have a low-s soft fork with segwit (in 0.13.1). Non-segwit txs are hopeless and we should not spend any energy to fix them. For segwit txs, why would we need immallable wtxid?
19:16:13 <wumpus> <sipa> one reason would be avoid 3rd party relayers messing with compact block relay
19:16:41 <jl2012> sipa: limiting p2wsh is more difficult, I think it could only be done case-by-case
19:16:52 <wumpus> sipa: agreed; the thing for discussion is mostly why to combine it with segwit
19:17:13 <wumpus> a low-s softfork itself at some point is uncontroversial imo
19:17:17 <sipa> pro combining it with segwit: it may be hard to do this as a separate softfork
19:17:32 <jonasschnelli> why is it hard?
19:17:34 <luke-jr> ^
19:17:52 <sipa> miners need to upgrade software
19:18:08 <jonasschnelli> Combine it with another, later software?
19:18:12 <jonasschnelli> softfork
19:18:16 <sipa> a low-s softfork would be uncontroversial, but also very low benefit
19:18:27 <luke-jr> no reason to make it urgent; just roll it out and let miners deploy on their own time?
19:18:30 <sipa> that's possible, but i thought it would be neat to just never have anything but low-s in segwit
19:18:30 <wumpus> but rolling everything into one giant softfork is more risky
19:18:36 <GreenIsMyPepper> reading scrollback...
19:19:30 <wumpus> that is true
19:19:39 <jonasschnelli> I think it's useful to combine to low-s restriction with the SW software in 0.13.1
19:19:52 <sipa> it's literally, VersionBitsActive(pindexPrev, DEPLOYMENT_LOW_S) == ACTIVE { flags |= SCRIPT_VERIFY_LOW_S; }
19:19:56 <wumpus> well yes that would be 0.13.1
19:19:59 <GreenIsMyPepper> is the policy limit for number of sigs? (sorry for the noise)
19:20:11 <kanzure> size
19:20:13 <jtimon> a low s softfork should be also quite easy, no? it's already implemented, just make a flag mandatory for consensus
19:20:18 <luke-jr> oh, right. speaking of 0.13.1, it seems quite uncontroversial
19:20:20 <instagibbs> Oh, if the two bip9 aren't packaged, I think we should
19:20:25 <wumpus> jtimon: yes, sipa just quoted the code change :)
19:20:28 <instagibbs> (duh, bip9)
19:21:31 <sipa> jl2012 sounded like he thought this would require more testing; and i agree that if due to extra testing this would delay the segwit softfork, we should not
19:21:45 <wumpus> I like coupling an uncontroversial change to a more risky one more than the other way around at least
19:21:46 <kanzure> s/we should not/we should not bundle
19:21:53 <luke-jr> (huh, it occurs to me - not a real suggestion - that we *could* have de-bundled the block size increase from segwit into a separate BIP9 bit, so long as all deployment of segwit included support for the separate blocksize-increase bit; IMO interesting)
19:22:13 <jtimon> no strong opinion about doing the low-s sf with segwit or later
19:22:35 <jtimon> but yeah, the sf itself seems uncontroversial
19:22:41 <sipa> gmaxwell countered that if low_s requires testing, that's testing we should be doing already, as it's being enforced on every transaction on the network already, so making it consensus likely just removes the possibility for untested cases
19:23:13 <GreenIsMyPepper> seems cleaner to have low-S from the start, no?
19:24:22 <luke-jr> wumpus: coupling an uncontroversial change to a more controversial one, could be taken as pressure to activate the controversial one; so for that reason, it may be best to keep them separate (like how we don't do softforks in .0 releases)
19:24:34 <luke-jr> (separate in the BIP9 sense, not necessarily a different release)
19:24:53 <instagibbs> luke-jr, my assumption would be a different bit
19:24:54 <btcdrak> I think lowS softfork is a nobrainer, it's also easy and uncomplicated since it's already policy.
19:25:04 <wumpus> luke-jr:that would be if it is uncontroverial *and* attractive, but there's no one really waiting for low-s enforcement, it's just a cleanup
19:25:05 <jtimon> I mean, we can also deploy low-s in, say 0.12.2 before segwit (oh, wait, backport bip9)
19:25:24 <jtimon> if they go in the same release, why separate them in the bip9 sense?
19:25:29 <kanzure> luke-jr: that's at best an argument for your segwit bip9 activation decoupling idea.
19:25:39 <wumpus> I don't think we should deploy anything before segwit
19:25:50 <sipa> wumpus: agree
19:25:58 <jonasschnelli> agree
19:26:27 <wumpus> it's time for segwit now, we should try to move ahead with things instead of introducing more things in between
19:26:35 <luke-jr> kanzure: well, it's almost certainly too late for that (it definitely would add to testing required)
19:26:45 <jtimon> wumpus: just saying that together is not the only option for having low-s from the start of segwit, no strong opinion
19:26:54 <wumpus> so, yeah, let's get 0.13.0 out asap then decide on a timeframe etc for segwit and do 0.13.1
19:27:02 <sipa> ok
19:27:08 <GreenIsMyPepper> luke-jr: to follow up with the above ping, we're presuming a policy limit to be the same as P2SH constraints with the redeemScript size
19:27:22 <luke-jr> GreenIsMyPepper: thanks
19:27:57 <wumpus> adding LOW_S is fine with me, it's simple to do and not risky and not controversial, indeed is a lot of overhead to do a seperate softfork for it
19:28:32 <instagibbs> also segwit could activate first, in some universe
19:28:33 <sipa> GreenIsMyPepper: oh sure - no reason why segwit would be able to do less than what is currently possible with P2SH
19:29:26 <wumpus> next topic?
19:29:41 <wumpus> #topic raising mandatory script flags to include bip66
19:29:53 <btcdrak> I would prefer we combine lowS with segwit.
19:29:58 <jtimon> regarding luke-jr's argument, I don't think segwit is controversial either, but if segwit+low-s deployment fails, you can always try again with them separated
19:29:59 <sipa> so, we have 3 sets of flags currently
19:30:00 <luke-jr> what node versions does this result in cutting off from the network? pre-0.8, I think?
19:30:16 <sipa> 1) mandatory flags 2) consensus flags 3) standardness
19:30:26 <wumpus> luke-jr: no one is 'cut off' from the network?
19:30:39 <luke-jr> then I am misunderstanding
19:30:42 <jtimon> sipa: how are mandatory flags different from consensus flags?
19:30:50 <sipa> luke-jr is not misunderstanding
19:31:00 <wumpus> luke-jr: it's a softfork so 0.8 nodes should still be able to verify?
19:31:14 <sipa> wumpus: i'm explaining
19:31:27 <instagibbs> Mandatory script verification flags that all new blocks must comply with for
19:31:28 <instagibbs> * them to be valid. (but old blocks may not comply with) Currently just P2SH,
19:31:34 <sipa> the reason why mandatory flags are different from consensus is because old nodes are not guaranteed to not send us currently-invalid transactions
19:31:50 <sipa> and we would ban them if they send a BIP66-invalid transaction, for example
19:31:55 <instagibbs> "Failing one of these tests may trigger a DoS ban" I see
19:32:01 <sipa> so that's why BIP66 is not part of mandatory flags
19:32:18 <sipa> i just wanted to bring up the topic, not necessarily for anytime soon
19:32:20 <wumpus> right, so they would not be cut off the network, but only if they actually generate or relay something invalid by new rules
19:32:28 <luke-jr> note we have a fork of 0.5.3 that is actively "maintained" and used
19:32:33 <jtimon> instagibbs: also bip66, bip65 and bip112, no?
19:32:34 <sipa> wumpus: it could partition the network, though
19:32:41 <luke-jr> s/we/someone else on the network/
19:32:55 <wumpus> sipa: ok, let's look at it from the other side then
19:32:57 <instagibbs> jtimon, oh, the comment is straight from master
19:33:00 <wumpus> sipa: what would be the advantage?
19:33:01 <sipa> wumpus: if there is a large group of pre-0.8 nodes connected to eachother, and they get an invalid transactions relayed to eachother
19:33:23 <jtimon> but all new blocks must comply with those too
19:33:45 <wumpus> does it cost a node a lot of resources to verify BIP66 compliance? if not, why does it warrant DoS banning?
19:33:58 <sipa> wumpus: good point
19:34:22 <sipa> perhaps the policy should just be to never extend mandatory flags
19:34:31 <sipa> unless there is a DoS attack that needs it to be fixed
19:34:39 <wumpus> I remember a previous discussion about being less trigger happy regarding DoS banning
19:34:49 <wumpus> right, if there is DoS risk it is the appropriate measure
19:35:04 <sipa> i just noticed that this is something we've been ignoring the value of mandatory flags
19:35:20 <wumpus> yes, sure, it's confusing
19:35:25 <sipa> yes, indeed, i remember reducing dos banning flags
19:35:50 <wumpus> but adding a comment explaining this rationale would do just as well as extending the mandatory flags
19:36:08 <sipa> fair enough
19:36:45 <jtimon> sipa: I'm not sure I follow, why aren't SCRIPT_VERIFY_CHECKLOCKTIMEVERIFY and SCRIPT_VERIFY_CHECKSEQUENCEVERIFY in MANDATORY_SCRIPT_VERIFY_FLAGS ?
19:37:18 <sipa> jtimon: because pre-0.11.2 nodes could get banned by us if they'd send a CSV-violating transaction
19:37:25 <wumpus> jtimon: for the same reason, probably, it would be harmful to DoS ban on them
19:37:45 <luke-jr> jtimon: if a 0.5.3 node sends you a transaction violating those rules, you don't want to ban them, just reject it; if you banned them, you partition such nodes off the network and they stop getting blocks
19:37:55 <wumpus> (to not accidentally partition the network)
19:38:01 <jtimon> ok, so it's all about the DoS score
19:38:06 <wumpus> yes
19:38:23 <instagibbs> so why is it ok to ban a misbehaving p2sh transaction (probably veering off the path here)
19:38:44 <jtimon> why SCRIPT_VERIFY_P2SH is different from other softforks for this again?
19:38:48 <wumpus> validation overhead?
19:39:06 <sipa> jtimon: it was very old at the time mandatory flags was introduced, so nobody cared, i guess
19:39:13 <gmaxwell> We can't reasonably support old versions forever; We're not testing them, and certantly not testing weirdo transactions with them.  perhaps we should have a program of making links to sufficiently old versions blocks-only after some point.
19:39:43 <wumpus> well people run them on their own risk
19:40:04 <jtimon> wumpus: well they risk being banned, no?
19:40:17 <gmaxwell> yes, though if we blocks only them we won't risk partitioning them do to weirdness with txn handling. Much more likely to be reliable.
19:41:12 <sipa> i think it's more a philosophical issue... another implementation may have different policy, and it's not our place to trigger happy ban them
19:41:12 <sipa> i like the idea of reducing dos banning where possible
19:41:14 <wumpus> sure, but would be best to not DoS ban in the first place for non DoS offenses
19:41:45 <jtimon> sipa: for SCRIPT_VERIFY_P2SH too?
19:41:57 <luke-jr> gmaxwell: would blocks-only treatment break their wallet broadcasts, though?
19:42:07 <gmaxwell> Sending a consensus invalid transaction is a prefectly reasonable thing to ban for ... ignoring that the consensus rules change over time.
19:42:09 <wumpus> I don't think we should make the one-sided decision to make lower version nodes blocks-only
19:42:28 <gmaxwell> luke-jr: yes but nodes that old already have wallet broadcast problems because of high-S enforcement as standardness.
19:42:28 <wumpus> e.g. something may report a low network version but be perfectly able to handle new transactions
19:42:44 <wumpus> they're not really coupled the same way in other software than bitcoin core
19:42:50 <gmaxwell> probablity of their txn not relaying already is exponential in the number of signatures.
19:42:51 <luke-jr> gmaxwell: consider that there's a crowd who insist on using 0.5.3 :/
19:43:06 <wumpus> in any case I don't think this is a very urgent topic
19:43:08 <luke-jr> I guess they must have patched that
19:43:31 <jtimon> luke-jr: who insists in using 0.5.3 ?
19:43:48 <luke-jr> jtimon: therealbitcoin.org people
19:43:58 <gmaxwell> luke-jr: they have to apply a small pile of fixes in any case.
19:44:25 <gmaxwell> presumably they're fixed to produce high-S signatures (or not transacting at all... :P )
19:45:20 <luke-jr> I suppose the BIP 66 patch is fairly trivial to add to that pile if they care; but sipa is right about the principle of not cutting them off IMO
19:45:27 <wumpus> they probably write raw transactions in their head instead of using the bitcoin core wallet
19:45:30 <jtimon> I guess I can ask after the meeting, but why don't they want to upgrade?
19:45:51 <sipa> jtimon: yes, let's discuss that after the meeting
19:45:58 <luke-jr> ^+1
19:46:02 <jtimon> sipa: sure, np
19:46:07 <sipa> i think this is getting too abstract
19:46:21 <sipa> i just wanted to raise attention to the neglected mandatory flags :)
19:46:29 <wumpus> in any case, not our problem, we should not do anything to sabotage use of old clients, but we're also not responsible for making sure all old versions still work, they'll have to do with a pile of patches on top
19:46:33 <wumpus> yes, next topic?
19:46:39 <btcdrak> I dont see any 0.5.3 useragents
19:46:58 <sipa> wumpus: you had rc3 as topic?
19:47:04 <wumpus> #topic rc3 go-ahead
19:47:30 <btcdrak> luke-jr: are you sure there are 0.5.3 nodes on the network? https://bitnodes.21.co/nodes/?q=0.5.3
19:47:32 <wumpus> yes, quick question, anything that still needs to be merged/backported for 0.13.0 apart from release notes?
19:48:09 <wumpus> not seeing anything here https://github.com/bitcoin/bitcoin/milestone/20
19:48:11 <luke-jr> on the off-chance there's no objection, I'd like to PR https://github.com/bitcoin/bitcoin/commit/5a716a3bc6621e4d2e2c1de5b6b5596d6877d589 for 0.13.0 mostly just to make #8459 uncontroversial
19:48:28 <wumpus> so I'm going to tag rc3 in a very short while, after the usual translation updates and such
19:48:49 <luke-jr> btcdrak: 1) those are just listening nodes, 2) 7 nodes show as 99999 "/therealbitcoin.org:0.9.99.99/"
19:49:23 <wumpus> yes they don't report as 0.5.3
19:49:40 <jtimon> sipa: so should we get  SCRIPT_VERIFY_P2SH out of mandatory too?
19:49:57 <btcdrak> luke-jr: ok so there are 5 nodes out of 5000, I really dont think we have to be concerned.
19:50:01 <sipa> jtimon: out of topic :)
19:50:15 <jtimon> sipa: ok, later too, whatever
19:50:26 <wumpus> btcdrak: it's not a concern
19:50:29 <btcdrak> wumpus: rc3 looks good to go.
19:50:59 <wumpus> foss gives that freedom to run your own stack of weird hacks if you want for whatever reason
19:51:15 <wumpus> btcdrak: ok!
19:51:37 <sipa> ack rc3
19:51:44 <jonasschnelli> ready to build
19:51:52 <cfields> sipa: as discussed yesterday, any need to try to get default_witness_commitment added to gbt with no witness data for 0.13.0? So miners can start easily adding commitments even before activation?
19:52:00 <btcdrak> There's also a blog post being written about 0.13.0 if some eyes could review and comment https://github.com/bitcoin-core/bitcoincore.org/pull/199
19:52:38 <sipa> cfields: fine be me
19:53:18 <sipa> btcdrak: great
19:53:30 <wumpus> cfields: eh, so that means holding up rc3?
19:53:32 <cfields> wumpus: opinion ^^? Not critical, we have testnet.
19:53:55 <wumpus> if it's not critical I'd say not do it, at this point
19:54:03 <sipa> cfields: 0.13.0 has no activation, so it would not produce a default_witness_commitment?
19:54:10 <wumpus> unless you want to be that person holding up the release :)
19:54:13 <sipa> i think there is no need for that in 0.13.0
19:54:22 <luke-jr> sipa: the subject was commitments pre-activation
19:54:40 <sipa> i'm confused about that
19:55:01 <wumpus> #link review blog post https://github.com/bitcoin-core/bitcoincore.org/pull/199
19:55:13 <sipa> i think a miner on 0.13.0 should never produce a segwit commitment, and a 0.13.1 one (assuming it has a defined start date) should always (regardless of whether it is before or after the start time)
19:55:35 <gmaxwell> ^ thats my expectation
19:55:38 <sipa> there is no problem if people choose to diverge from that
19:56:08 <wumpus> cfields: to be honest I'm not sure what the advantage or disadvantage of that is
19:56:56 <gmaxwell> The reason I believe we should do that is so that we don't hae sudden behavior changes at times which are far away from updating the software which might break downstream mining infrastructure.
19:56:57 <cfields> works for me. i was only considering it as a way to see that pools had begun adding valid structures. obviously it wouldn't be actually checked/used
19:57:32 <gmaxwell> e.g. if you update your bitcoin node and then days/weeks later it starts doing thing with segwit commitments that breaks your miners or pooling software, that is preferable. You would prefer the break to happen at upgrade time.
19:57:44 <sipa> cfields: 0.13.0 for all intents and purposes behaves identical to older nodes wrt segwit behaviour
19:58:03 <sipa> cfields: so i think there is no point in using witness commitments as a signalling mechanism for anything in 0.13.0 already
19:58:05 <cfields> sipa: understood
19:58:44 <sipa> so, ack rc3?
19:58:50 <gmaxwell> as far as 0.13 vs 0.13.1 I think 0.13 should not change behavior, because it won't ever activate. so there is no problem of behavior suddenly changing with it.
19:58:55 <gmaxwell> rc3 sounds good to me.
19:59:19 <cfields> works for me
19:59:41 <jtimon> yay 0.13.0!
19:59:54 <gmaxwell> jtimon: careful, you're going to trigger some confused reddit posts.
20:00:12 <wumpus> roughly one minute to go
20:00:20 <jtimon> oops, sorry, yay ack rc3
20:00:24 <gmaxwell> I think someone's clock is off.
20:00:31 <gmaxwell> Time to die.
20:00:37 <wumpus> jtimon: yes, let's not get ahead of ourselves
20:00:39 <wumpus> #endmeeting