< GitHub137> [bitcoin] PRabahy opened pull request #7417: Minor improvements to the release process (master...patch-1) https://github.com/bitcoin/bitcoin/pull/7417
< gavink> i am considering a PR for the website. I think an issue is the community believes core = no HF. I think as an addition to the overall statements, it could be defined that an HF is likely in the next couple years. Listened to Adam Back interview and he said likely 1 to 2 years. Any feedback on this tone?
< gavink> I did some previous corrections, so I'm familiar with the site. Possibly there could be a definition of what is the best practice and how an HF would be approached, so people understand the concerns, and how long it takes to do correctly. Thanks for entertaining my ideas.
< Luke-Jr> gavink: depends on adoption, really
< Luke-Jr> gavink: Lightning is likely to reset block size to like 5k/block avg, so it's possible we won't need one for a while unless adoption picks up
< gavink> Luke-Jr: My question is core unwilling to make a statement that there is a possibility, and the current plan will go forward. Or is it too unclear to even hint to that. My sense is the debate is hinged that core will never HF, would it be interesting to expand potential long-term road maps, or theories to make it clear you have a plan to deal with volume. This might be too direct I understand.
< Luke-Jr> gavink: it is certainly possible IMO. but maybe other devs would disagree? dunno
< gavink> Luke-Jr: ok that's interesting. I've heard the claim everything can be changed eventually in a soft-fork, so what do you think is agreeable with a hard-fork much further down the road. My assumption is there should be a protocol or definition for what is the correct or best practice standard that core holds itself to, and why that requires more time, not that it's just out of the picture. Anyways, I'll see if Drak can give any insight, my guess based
< gavink> on this is it's not something to be placed on the site then.
< Luke-Jr> gavink: increasing the block size further than segwit, will probably need a hardfork. while extension blocks could make it a softfork, that is a stupid idea IMO.
< aj> gavink: gmaxwell's roadmap specifically says 2MB/4MB (or similar) hardfork patches should be maintained ready to go...
< Luke-Jr> gavink: even those of us working on Core are constantly learning more, however, and it's likely that a year from now we will have better answers on hardfork questions than we would have today
< gavink> aj, yes I've seen this, but where is it stated that it's actually still being considered.
< gavink> Luke-Jr I think this is a great message to make clear. What is being learned, what is the concern, how would it be approached. I respectfully do not understand fully this process, but I'm confused with the claim that core is permanently at stalemate with any 2MB or adaptive blocksize.
< Luke-Jr> gavink: Core plans to deploy 2 MB before summer
< gavink> ok this answers my questions, is this included on the website though?
< Luke-Jr> perhaps not clearly. I think the website people are working on improving that.
< Luke-Jr> there is a segwit FAQ page being made
< aj> gavink: that seems a pretty clear statement that a hardfork is a possibility. so i don't get where "is core unwilling to make a statement that there is a possibility" and "core will never HF" comes from
< Luke-Jr> (segwit does lots of things, including 2 MB block size)
< gavink> so the 2MB you mention is gmaxwell's plan, or the proposed benefits from SW
< gavink> aj it's more a tone from community, but i'll abstain from anymore confusion or "drama"
< Luke-Jr> gavink: yes, SW is a 2 MB block size increase
< gavink> ok fair enough thank you very much. thank you for your time.
< moli> gavink: here's the roadmap that might help answer your question: https://bitcoin.org/en/bitcoin-core/capacity-increases-faq
< gavink> moli thank you, yes wow this does actually answer all of those questions very clearly. My bad.
< moli> no problem
< aj> wow, there are people who care about this stuff and haven't seen that faq? crazy
< belcher> that is the problem of public relations, you have to dominate the conversation
< belcher> simple points, repeat them often and maybe you'll get a 30% of people to hear, its hard work (phew)
< gavink> aj i have seen the faq, and read through believe me, i just didn't re-reference I'm sorry
< aj> gavink: ahh
< gavink> i'm absorbing more of the stuff about segwit, the opinion box on HF is so full, it's hard to keep track of who said what.
< gavink> what sparked my re-interest, and slack is probably the better forum, was the adam back interview. so i'll be in slack :) thank you
< moli> i haven't read adam back's interview
< moli> anything new in his interview?
< Luke-Jr> wtf is "Work queue depth exceeded"? O.o
< GitHub61> [bitcoin] jonn4y opened pull request #7419: 0.9 (master...0.9) https://github.com/bitcoin/bitcoin/pull/7419
< moli> gavink: ah.. thanks for that link
< GitHub105> [bitcoin] jonn4y closed pull request #7419: 0.9 (master...0.9) https://github.com/bitcoin/bitcoin/pull/7419
< GitHub179> [bitcoin] sdaftuar opened pull request #7421: [doc] Release notes update for 0.12 (0.12...release-notes-update-12) https://github.com/bitcoin/bitcoin/pull/7421
< GitHub160> [bitcoin] btcdrak opened pull request #7422: Update release-notes.md (0.12...patch-2) https://github.com/bitcoin/bitcoin/pull/7422
< Taek> I think it would be beneficial to add a 'risks' section that goes in depth on all the risks associated with soft forks, to help quell the FUD
< Taek> would be useful to drop this link somewhere: https://bitcoincore.org/en/2016/01/26/segwit-benefits/
< jonasschnelli> Taek: Agree. A compression between HF and SF security on bitcoincore.org would be nice
< AdrianG> compression?
< btcdrak> Taek: contributions accepted :)