< 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.