Hisham

<BlueMatt> Hisham: bitcoin's consensus rules are not a development topic, and its best to keep irc channels on-topic so people can filter for what discussions they want to be involved in based on channels :)
<BlueMatt> ehh, merging proposed consensus rules, that is
<BlueMatt> given they have already been technically vetted (not sure anyone bothered to review the uasf code that was posted, but it looked trivial, soooo)
<gmaxwell> Hisham: Sorry, I wasn't trying to be rude before-- just wanted you to know that asking to ask is not well recieved in chat generally. It is surprising to some people, but there are good reasons for it... and not a think unique at all to the bitcoin channels. :)  Cheers.
<Hisham> No problem Gregory, it's ok, I still like you guys :)
<BlueMatt> Hisham: you might wish to read the blog post i linked you to, it tries to describe some of why "consensus" matters, ie why things like fork activation, while they might be proposed by devs, must be decided on by a large body of users, and why its important that those users try their damndest to only make changes when they are really uncontroversial
<BlueMatt> not sure i did a good job, but i /tried/ to make those points :P
<Hisham> Matt, what I want to discuss with all of you is, how me as Hisham can get consensus ?
<Hisham> How you as a developers measure this ?
<Hisham> Talk or reddit for example ?
<belcher> educate yourself on the issues and talk to people, correct misinformation, explain why segwit is a good idea, etc
<Hisham> Twitter ?
<belcher> yes, all of those
<BlueMatt> go to meetups, go talk to businesses, post about it on forums and reddit, email people asking for their opinions, etc, etc
<BlueMatt> and twitter and wechat and.....
<Hisham> It's not what I shall I do, I will try my best to do what you've recommended but what I'm asking now is, lets say we already have consensus for SegWit UASF, how will you as a developers will know that there are a hell lot of people in your back supporting you to get the SegWit UASF integrated into Bitcoin Core ?
<Hisham> Hopefully it's more clear now.
<Hisham> And to be more clear, I'm not aganist consensus "at all
<Hisham> "
<Hisham> It's a must and this is how Bitcoin works.
<sipa> the kind of consensus needed depends on the failure mode
<Hisham> May you elaborate more please ?
<sipa> for certain types of changes, like SegWit's current proposal, the system only fails if a majority of miners signal they're ready, but in reality aren't, and at the same time there is not widespread adootion of segwit-conpatible software deployed in the network
<sipa> UASF drops the miner signalling requirement, so it can fail under wider conditions
<sipa> that makes it riskier, and thus we'd need a clearer signal from the community that it is the way forward
<Hisham> Perfect.
<Hisham> Stop here please and let me quote you.
<Hisham> "clearer signal from the community that it is the way forward"
<Hisham> How will you witness this ?
<sipa> I'm not.
<sipa> I'm not even saying UASF is a good or bad thing.
<Hisham> I understand.
<sipa> All I'm saying is that it is more complicated.
<dgenr8> sipa: is a supermajority of mining signaling "yes" a necessary component of the "clear community signal"?
<sipa> dgenr8: no
<dgenr8> thank you
<sipa> hashrate only represents mining readiness
<Hisham> You are not getting my point still, with all respect, I'm not asking for your opinion because I understand that nobody is entitled to ask this.
<Hisham> What I'm saying, you've said that Core developers need clearer signal from the community.
<Hisham> I fully agree.
<sipa> Hisham: i'm not answering your question because i'm not interested in doing politics
<sipa> all i'm saying is why some changes are more complicated then others
<sipa> based on their technical properties
<BlueMatt> miners are users of the system, like anyone else, but for the purpose of consensus changes, are only users of the system, like anyone else :P
<sipa> Hisham: if you're asking me under what conditions UASF would be merged into Core, you're asking the wrong question. You should ask under what conditions people would decide to run that version of Core. And to that, I don't know the answer.
<Hisham> Well, I guess there is a lot of misunderstanding here, so to make clear because I'm not really getting it, telling me how consensus is being measured from Core developers is a question that can't be answered ?
<sipa> Hisham: it shouldn't matter. Core is just a software project, and there are several forks
<BlueMatt> Hisham: its a useless question, especially when you're talking about a 5-line patch
<BlueMatt> the question is, when will people run such a version of a bitcoin full node
<sipa> if Core developers would merge something crazy, i would hope that the community is smart enough to start running a fork that doesn't have craziness
<dgenr8> that turns out to be difficult
<sipa> of course, developers have influence
<sipa> by the choices they make
<BlueMatt> sipa: dont worry, if you merge something crazy I'll maintain a fork :P
<Hisham> :D
<sipa> but in an ideal world, maintainers don't matter - only users
<Hisham> Sipa, we are in agreement by the way.
<Hisham> But there is something that is still I'm missing.
<Hisham> And please guys, no need to set up the exile for me.
<Hisham> I'm not an enemy :D
<sipa> UASF has a flag date. If we expect that before the flag date nearly the entire ecosystem will have adopted software that implements UASF with that flagdate, it is safe.
<Hisham> Yes, I'm noob or rookie whatever, I just want to understand and help even a tiny bit :)
<Hisham> How will they adopt the software if still the code in not merged into any Core version ?
<jwinterm> what happens if expected outcome of expectation does not materialize?
<jwinterm> just call the whole thing off?
<Hisham> Sipa, there ?
<sipa> Hisham: as i said, in an ideal world, maintainers don't matter, and users run software that is sane
<sipa> Hisham: so in an ideal world, the coices that any given software project makes don't matter
<sipa> we don't live in an ideal world, and in the real world there exists politics
<sipa> which i'm not not going to participate in
<dgenr8> BlueMatt once explained to me quite forcefully that there must only be one consensus implementation (absent some idealistic provable equivalence condition)
<BlueMatt> dgenr8: luckily a carefully-constructed fork is pretty much quivalent :)
<BlueMatt> dgenr8: and there is a big difference between "we're adding a new consensus rule by all agreeing to run it" and "we're gonna run 32 different clients and have 32 different consensus rules risking everyon's money and consensus for marginal gain"
<dgenr8> And getting off your crazy treadmill isn't marginal gain.
<BlueMatt> dgenr8: hmm?
<BlueMatt> dgenr8: I would say that there is lots of value to be had by accessing consensus rules by different apis, yes, but that doesnt inherintly mean different implementations, and there is real risk to having many different implementations
<BlueMatt> consider for a moment the history of different implementations in bitcoin.....its really not good