#bitcoin-core-dev

/

      • cfields
        gmaxwell: hence m_ :)
      • gmaxwell
        so if naming helps disambiguate that I would not be unhappy.
      • wumpus
        for variable names, for method names we should obviously keep sticking to camelcase
      • morcos
        are we ok with combining small words without the udnerscore like feerate or blocksize or something?
      • sipa
        wumpus: agree, and class names as well
      • wumpus
        sipa: yes
      • sdaftuar
        bit_coin right?
      • sipa
        morcos: ack from me
      • wumpus
        sdaftuar: it's better than BitCoin
      • sipa
        one lowercase word is totally fine for local variables
      • wumpus
        yes
      • cfields
        sipa: ack all of the above
      • luke-jr
        I prefer camelcase, except for the annoying conflict w/ hungarian
      • I don't care strongly tho
      • sipa
        oh, what to do with the cs_* variables we have now?
      • do we want an exception for that?
      • morcos
        oh ok, so we're keeping camel for class and method names and snake for variables.. ok someone write it up
      • gmaxwell
        I would be fine with an exception for cs_.
      • wumpus
        cs_ for locks? it's fine with me
      • sipa
        so... g_blockindex g_cs_blockindex?
      • wumpus
        though I still thing the scope is more useful
      • morcos
        but no exception for pblockindex ?
      • sipa
        that's hungarian - dia
      • die
      • ;)
      • wumpus
        pblockindex could just be block_index
      • sipa
        indeed
      • wumpus
        though we aren't actrually going to rename variables en-messe
      • cfields
        [11:17:50] -*- cfields would kill for m_ == member
      • [11:18:13] <luke-jr> pls don't kill
      • sipa
        wumpus: indeed
      • gmaxwell
        cfields: thou shall not kill
      • sipa
        i'll write up a PR, and we discuss there further?
      • gmaxwell
        is all I think luke was saying.
      • luke-jr
        yes
      • morcos
        sounds good
      • sipa
        ok, topic closed
      • gmaxwell
        sipa to do all the work, agreed.
      • wumpus
        I don't want to see any more variable renaming PRs, the Wshadow war made me so tired of that
      • other topics?
      • luke-jr
        BIP148
      • morcos
        next topic
      • wumpus
        I have nothing to say about that, at least
      • but i f you insist
      • #topic BIP148
      • jonasschnelli
        I guess we have already enough comments on the PRs..
      • sipa
        my opinion is that it would go against our principles to merge BIP148 into core
      • luke-jr
        sipa: how so?
      • BlueMatt
        sipa: +100
      • sipa
        i've given my opinion more than enough on existing PRs
      • i strongly disagree with the "less safe" argument
      • wumpus
        right, I think everyone already had their say on this
      • sipa
        and we shouldn't encourage forks in the network
      • nor is it out place to push for consensus changes
      • luke-jr
        so we should put users at risk by refusing to enforce the new rule?
      • wumpus
        let's merge BIP149 instead
      • luke-jr
        sipa: refusing to merge is what encourages the fork in this case
      • sipa
        luke-jr: i strongly disagree that it puts users more at risk
      • gmaxwell
        wumpus: I brought up 149's timeout on the list, but its author hasn't replied, I think it is needlessly long.
      • morcos
        My opinion closely matches sdaftuars from : https://lists.linuxfoundation.org/pipermail/bit...
      • luke-jr
        not only does not-merging it encourage a chain split, it also puts users on the side vulnerable to reorg wipeout
      • gmaxwell: I think it's too early
      • morcos
        I'd be in favor of 149, but I think we should start by being a bit more public about the idea and building consensus for it before actually merging
      • BlueMatt
        gmaxwell: ack, your proposal of 6 months seemed reasonable to me
      • morcos
        And eys I agree we could tweak it a bit
      • BlueMatt
        morcos: +1
      • wumpus
        gmaxwell: yes we need to agree on the timeout at lesat
      • sipa
        luke-jr: the only condition under which it helps users avoid a huge reorg is one under which those who didn't upgrade already experienced a (temporary, but long) fork
      • jtimon
        as said on the mailing list I think bip148 is rushed and that makes it risky, bip8 on the other hand...(although I'm writing suggestions for changing bip8)
      • luke-jr
        sipa: this seems tautological?
      • jtimon
        we can merge bip8 without merging bip149 yet, although the sooner it is released the more secure it will be
      • sipa
        luke-jr: then how is merging it less risky?
      • luke-jr: it only helps in case a fork already happened!
      • while at the same time encouraging said fork
      • gmaxwell
        luke-jr: I haven't seen the kind of support required to justify your position on that; afaict so far no exchange or payment processor of note has said they would stick with 148. I think you'd have an argument if there was any of that, but right now I think it's hard to distinguish a subsanstive level of support. (And I've seen some clearly malicious parties pumping support for it too.)
      • luke-jr
        sipa: if a fork happens, it puts them on the side that isn't vulnerable to a reorg, and it helps avoid the fork in the first place
      • sipa
        not encouraging it seems far safer than slightly reducing the risk in case it does
      • luke-jr: under the assumption a hashrate majority adopts it
      • luke-jr: which i think is crazy
      • gmaxwell
        My discussions on reddit with people promoting BIP148 seemed to be because they earniestly believed it was the only choice.
      • luke-jr
        sipa: BIP148 only needs about 25% hashrate to be successful
      • morcos
        At the end of the day I think most of us have no interest in greatly increasing the risk of a devastating currency split. I think 148 does that.. But 149 has a decent chance of not doing that if there have been no other consensus rule changes in the interim. But will require consensus building.
      • gmaxwell
        E.g. someone managed to convince them that the project would never adopt something like BIP149.
      • sipa
        morcos: +1
      • it will require consensus building
      • not discussions here
      • BlueMatt
        yup
      • jtimon
        gmaxwell: ack on making the period shorter
      • gmaxwell
        which seemed really weird to me, because I thought it was pretty obvious that a 149-like thing would be done.
      • petertodd
        gmaxwell: it's only obvious if people say that
      • morcos
        And to be clear, I think we'd all like to activate segwit via UASF before we could do so with BIP149 (and it would be feasible I think to build support in a shorter time frame), but we just don't have the technical bandwidth to code that up safely in time.
      • wumpus
        I think that wasn't obvioius, no
      • luke-jr
        if businesses get to decide protocol changes, then I guess bit 4 SW it is
      • gmaxwell
        luke-jr: there is a big difference between saying 'businesses get to decide' and saying that the fact that virtually no industry participant is resolute with 148 is a strong sign the support isn't significant enough. If 148 and six months or a year on its clock that would be another matter.
      • sipa
        gmaxwell: i don't think it's obvious that BIP149 will happen at all
      • morcos
        luke-jr: no one even knows what bit 4 SW is? we might like it, what if its compatible with BIP141 segwit... lets not make decisions based on a single line in a medium post.
      • luke-jr
        in the meantime, a sizable portion of the community will be enforcing BIP148, and with success eventually replacing the non-compliant chain
      • gmaxwell: it's only virtually none if you exclude the ones who have supported it
      • Joseph__ joined the channel
      • jonasschnelli
        luke-jr: that's speculation
      • petertodd
        luke-jr: while technically the result of bip148 may be a reorg, in practice if there is a non-trivial split the result will be two currencies, as someone will launch a currency based on a checkpoint
      • jonasschnelli
        You can't measure "community"
      • gmaxwell
        luke-jr: maybe I'm just not aware then.
      • sipa
        luke-jr: i hope you're right, but my expectation is that every economically relevant full node will revert away from bip148 code hours after the hashrate fails to adopts it
      • morcos
        luke-jr: I would hope that BIP148 and BIP149 supporters are able to agree at least that they should all support the same thing.
      • luke-jr
        sipa: Bitfury has already agreed to enforce BIP148 if the bit-4 thing doesn't activate Segwit by August
      • petertodd
        sipa: depends on how much hash rate... lots of incentive for exchanges to support it and let the two coins trade against each other
      • jonasschnelli
        sipa: I guess they have also agree (among others) to run Classic
      • (meant luke-jr)
      • sipa
        luke-jr: well, i hope you're right
      • but i'm very skeptical about that
      • topic suggestion: high-priority PRs?
      • luke-jr
        if we're divided in opinion on this, we should at *least* give users the choice, even if they want to stick to Core releases
      • gmaxwell
        If 148 managed to get the kind of support needed to result in avoiding a chain split, I'm fine with that. But I think it's a very poor and needlessly risky approach.
      • sipa
        luke-jr: users already have a choice to not run Core
      • morcos
        luke-jr: you already have a release process, release Knots with the option.
      • luke-jr
        sipa: many don't want to choose that
      • jonasschnelli
        maybe for a reason?
      • sipa
        luke-jr: for good reasons, because we don't do reckless things
      • NewLiberty_ joined the channel
      • gmaxwell
        luke-jr: then perhaps because the realize that we've usually had good judgement...
      • kanzure
        what was the default in the bip148 paramflag pull request?
      • petertodd
        kanzure: false
      • jcorgan
        off
      • luke-jr
        gmaxwell: and in this case, we disagree on that judgement.
      • petertodd
        kanzure: I wouldn't have concept acked it otherwise...
      • BlueMatt
        alright, next topic
      • jtimon
        alright, sent suggestions to change bip8 to the mailing list...
      • sdfkjs23
        deciding what choices users do or do not get seems overly political to me, if core developers want to make a political statement that's fine, but pretending to be neutral and not allowing an optional switch for bip148 seems disingenuous
      • kanzure
        with context of "default off" some of the above comments make less sense
      • cfields
        oh, quick topic suggestion: 0.14.2
      • jonasschnelli
        sdfkjs23? You can offer it yourself by forking and deploying or patching?
      • gmaxwell
        jtimon: I don't think we should change BIP8 generally: the reason we can do a shorter termination with SW is because we've already done one deployment-- so we know what the uptake looks like and how fast it went the first time.
      • petertodd
        sdfkjs23: there's a multiple of optional switches that we could add to be neutral - we're not going to add them all, thus we have to make some kind of (hopefully conservative) political statement
      • cfields
        (sorry, forgot all about it. we can pick it up after the meeting)
      • luke-jr
        jonasschnelli: too many people (and especially companies) refuse to run anything unless Core releases it
      • jonasschnelli: it sucks, but it's reality
      • gmaxwell
        sdfkjs23: Offering users settings we believe will harm third parties and the user is not 'neutral'.
      • kanzure
        luke-jr: they want default-off merged and that's what will get them interested in bip148?
      • wumpus
        #topic 0.14.2
      • jtimon
        gmaxwell: the changes are just for providing warnngs in unkown deployments, like bip9 did
      • jonasschnelli
        luke-jr: But core is consensus among devs for a reason. And I guess we mostly (never?) merged controversial consensus changes
      • gmaxwell
        sdfkjs23: if users want 'neutral' they have a copy of GCC, they can write their own node.
      • petertodd
        gmaxwell: +1
      • wumpus
        let's do a 0.14.2 soon, even if just for the UPNP CVE
      • gmaxwell
        (want neutral in that sense)
      • luke-jr
        gmaxwell: we don't all believe that in this case. some of us admit that it's riskier to NOT enforce BIP148
      • wumpus
        (of course we want to include some other fixes as well)
      • gmaxwell
        sdfkjs23: sofware worth running is always opinionated in many ways, even if you don't realize it.
      • luke-jr
        jonasschnelli: it's controversial to fail to enforce the softfork now