Bitcoin Core to Release SegWit in November

[achow101]

Franky, do us all a favor and stop spreading FUD.

remember folks. its not just getting miners to allow tx's into blocks. its also merchants changing their wallets to have new keys to be able to "spend" funds if they too want to use segwit..

Not necessarily merchants. Users too can use segwit. The sender can take advantage of segwit even if the receiver is not segwit capable.

if its active by christmas then miners have not done any testing on the side.
if merchants have the nodes before christmas, then they too have not done any testing.

That's a load of bullshit. Segwit has been and still is being continuously tested on the testnet. It is not as if the software was just written and now is being released. It was written several months ago and been in continuous testing since then. Furthermore several of the Core devs have reached out to miners, merchants, and wallet devs to help them with implementing and testing segwit.

if 95% of "segwit" is purely core0.132 and not peoples own implementations of the code. there is no point having distribution apart from worries of power cuts and data loss.

What are you saying? The vast majority of full nodes run some version of core. Do you mean that everyone has to have their own implementation? Also, the only other true alternative full node implementation is btcd and they have already completed implementing segwit.

seems the people that want it running before christmas are sounding like they care less about testing, care less about security and more about bitcoin price.

and ontop of that the majority that have this careless nature are mostly people that do not even run a full node in the first place
kind of funny that the "slow careful and smart testing mindset defending cores delays" turns into "before christmas, before christmas before christmas"

anyone wanting it active and in full use before christmas should be tagged as fiat loving bitcoin security hating nutters.
if those same people have previously shouted how any other proposal needs months of review and months of grace period. should be tagged as hypocritical fiat loving bitcoin security hating nutters

Or they care about testing and have tested it themselves on testnet and are sure that the software is secure. I know a lot of the developers want it out ASAP and have extensively tested it on testnet and are absolutely sure about its security.

[1714786264]

1714786264

[1714786264]

1714786264

[franky1]

Franky, do us all a favor and stop spreading FUD.

remember folks. its not just getting miners to allow tx's into blocks. its also merchants changing their wallets to have new keys to be able to "spend" funds if they too want to use segwit..

Not necessarily merchants. Users too can use segwit. The sender can take advantage of segwit even if the receiver is not segwit capable.

yes gmaxwell and sipa can play with themselves. but to be truly USEFUL merchants need to be involved. you know where bitcoin is actually useful (hint:buy things).

if its active by christmas then miners have not done any testing on the side.
if merchants have the nodes before christmas, then they too have not done any testing.

That's a load of bullshit. Segwit has been and still is being continuously tested on the testnet. It is not as if the software was just written and now is being released. It was written several months ago and been in continuous testing since then. Furthermore several of the Core devs have reached out to miners, merchants, and wallet devs to help them with implementing and testing segwit.

and over them months many things have changed. and in all those months it has not interacted with 7 years of historic data or mutiple pools or thousands of users.
sandbox tests does not equal utopian perfection in the real world. miners will still want to review and test the public release it before implementing it as their full live main node.
afterall the code next month is not the same code as last month, they are still tweaking it.

if 95% of "segwit" is purely core0.132 and not peoples own implementations of the code. there is no point having distribution apart from worries of power cuts and data loss.

What are you saying? The vast majority of full nodes run some version of core. Do you mean that everyone has to have their own implementation? Also, the only other true alternative full node implementation is btcd and they have already completed implementing segwit.

if the fiat lovers think that segwt should run by christmas. then where is the screams of grace period they were crying about..
oh wait they need no grace because they want everyone to just run core..
like i said many times in the past, the network should remain diverse. giving time for those to review and adapt the code into their own implementations or atleast test it on bitcoins mainnet before waving their hands in the air

seems the people that want it running before christmas are sounding like they care less about testing, care less about security and more about bitcoin price.

and ontop of that the majority that have this careless nature are mostly people that do not even run a full node in the first place
kind of funny that the "slow careful and smart testing mindset defending cores delays" turns into "before christmas, before christmas before christmas"

anyone wanting it active and in full use before christmas should be tagged as fiat loving bitcoin security hating nutters.
if those same people have previously shouted how any other proposal needs months of review and months of grace period. should be tagged as hypocritical fiat loving bitcoin security hating nutters

Or they care about testing and have tested it themselves on testnet and are sure that the software is secure. I know a lot of the developers want it out ASAP and have extensively tested it on testnet and are absolutely sure about its security.

tested on testnet.. tested on testnet.. tested on testnet..
thats like saying testing it on Clams or other alts... meaningless
it needs testing on bitcoin main net before settling minds can then say its safe to then flag consensus.
so stop thinking it should be active by christmas and atleast settle for atleast spring next year (if people are doing the right thing and checking)

EG even windows gets alpha and beta tested. but even after retail release it still ends up with people having system crashes and patches needed.
never claim anything is utopia until is has had time to run on the platform it is meant for.

i do find it funny how achow101 proclaims 0.132 to be perfect and well tested. though not running live on mainnet..
i presume 0.12 and 0.131 are perfect too... where even after release.. even after running there are still issues
 even achow101 spends alot of time in the support category dealing with crashes and many issues. with 'legacy' versions.
kind of strange to even need a support section if everything is perfect.. right?

and now you see why its safer to review test and use it before hailing it utopia to garner 95% utility

ok lets put my waffle into a simple question.
knowing it requires 95% over a month. where start of month needs to be at 95%, throughout month, and end of month needs to be 95% (3831 of 4032blocks)
are you saying mining pools should drop their "legacy" (nodes as you call it) at the latest november 24th and use only core 0.132 from november 24th because its safe to all rush to run before christmas? honest answer please

[thejaytiesto]

Big thanks to Pieter Wuille in particular for the major coding effort on Segwit. With a little luck, maybe the 13.1 client will get out of release candidate stage earlier than November 15th Here's to a Christmas holidays activation!



There's somewhere around 5 or 6 different Lightning implementations, the teams behind them are apparently collaborating to make each different system interoperable with the others. I suspect they won't take long to test before they roll out beta versions, it's unlikely we'll end up using 6+ different implementations once the tech is mature, and everyone knows the first viable product to market gets a psychological boost.

I hope that everyone collaborates and starts mining towards segwit activation as soon as possible and we avoid any idiotic fights like the ViaBTC morons going against it. They put a lot of effort into codding it so it would suck if they delay it because of that.

[achow101]

i do find it funny how achow101 proclaims 0.132 to be perfect and well tested. though not running live on mainnet..
i presume 0.12 and 0.131 are perfect too... where even after release.. even after running there are still issues

Where have I ever claimed that they are perfect? All I have said is that the software has been extensively tested and any more testing is unnecessary and just stalling.

Also, what is Core 0.132? It surely isn't 0.13.2 because that isn't a version that doesn't exist. 0.13.1 is the version with segwit.

The extensive testing has primarily been done with builds of the master branch of Bitcoin Core. You'll see it as version 0.13.99. 0.13.1 is made from backports of stuff that was already merged into master.

even achow101 spends alot of time in the support category dealing with crashes and many issues. with 'legacy' versions.
kind of strange to even need a support section if everything is perfect.. right?

Again, I have never said that everything is perfect.

99% of the issues are all due to user error. The vast majority of those being unconfirmed transactions because people do not set proper fees. There have been very few legitimate bugs and those bugs are of low severity, just minor nuisances. Those bugs are also fixed very quickly when reported.

and now you see why its safer to review test and use it before hailing it utopia to garner 95% utility

I have never called it perfect nor utopia. All of us developers know that review and testing is extremely important. That is part of the reason why segwit is behind the original timeline.

ok lets put my waffle into a simple question.
knowing it requires 95% over a month. where start of month needs to be at 95%, throughout month, and end of month needs to be 95% (3831 of 4032blocks)

It only requires 95% over one retarget period, starting on November 15th.

are you saying mining pools should drop their "legacy" (nodes as you call it) at the latest november 24th and use only core 0.132 from november 24th because its safe to all rush to run before christmas? honest answer please

What are you even asking? In order to signal segwit support, they have to stop using their legacy nodes and use segwit capable ones. If there is a "rollback" (which is impossible without a hard fork), then they have previous versions they can use unless they are so stupid that they don't use a VCS.

tested on testnet.. tested on testnet.. tested on testnet..
thats like saying testing it on Clams or other alts... meaningless
it needs testing on bitcoin main net before settling minds can then say its safe to then flag consensus.
so stop thinking it should be active by christmas and atleast settle for atleast spring next year (if people are doing the right thing and checking)

It is impossible to test on the mainnet without it being active. It is tested on the network most analogous to the mainnet which is the testnet.

[franky1]

I hope that everyone collaborates and starts mining towards segwit activation as soon as possible and we avoid any idiotic fights like the ViaBTC morons going against it. They put a lot of effort into codding it so it would suck if they delay it because of that.

translate
I hope that pools review next months release. tests it onchain and ensures it does everything it should do as standard and able to do what it should BEFORE mining towards segwit activation when confident
though devs put a lot of effort into coding it, so it would suck if pools rush it because peer pressure. but rather done due to individual confidence in the code they are using based on their own review, and again not based on "trust" by others.

[achow101]

I hope that everyone collaborates and starts mining towards segwit activation as soon as possible and we avoid any idiotic fights like the ViaBTC morons going against it. They put a lot of effort into codding it so it would suck if they delay it because of that.

translate
I hope that pools review next months release. tests it onchain and ensures it does everything it should do as standard and able to do what it should BEFORE mining towards segwit activation when confident
though devs put a lot of effort into coding it, so it would suck if pools rush it because peer pressure. but rather done due to individual confidence in the code they are using based on their own review, and again not based on "trust" by others.

I agree, they should test it very thoroughly. However, it is not necessary for them to have to wait for another couple of months while they test it because they are not going to start implementing and testing at the time of release. They started implementing and testing months ago. The spec has been public for a long time, discussions and reference implementations have been available for a long time. No respectable dev (for both miners and wallets) is going to sit on his ass and wait for an official release of a new thing before going to start work on stuff that will use it. All of that is already implemented or being implemented and being tested with testnet.

Also, you keep saying "test it on chain" "test it on mainnet". Do you realize that it is impossible to test a consensus change on the mainnet without actually deploying it? The only way to test it is to use a test network, either testnet, or a private test network. These test networks simulate the mainnet as best as possible. So while it's not mainnet, it's as good as it gets to being mainnet.

[franky1]

99% of the issues are all due to user error. The vast majority of those being unconfirmed transactions because people do not set proper fees. There have been very few legitimate bugs and those bugs are of low severity, just minor nuisances. Those bugs are also fixed very quickly when reported.

so ignore the 1% because rush rush rush.. got ya

ok lets put my waffle into a simple question.
knowing it requires 95% over a month. where start of month needs to be at 95%, throughout month, and end of month needs to be 95% (3831 of 4032blocks)

It only requires 95% over one retarget period, starting on November 15th.

and i said for a activation pre christmas requires the retarget period to begin at the latest november 24th.. thus only giving 9 days to go from 0-95% to then be constant 95 for the period.
remember you replied to me about people who wanted a pre-christmas activation. so i was showing the requirements needed to get it.
which i see you avoided answering as a bad thing. but subtly suggesting people just just run it and trust it works

are you saying mining pools should drop their "legacy" (nodes as you call it) at the latest november 24th and use only core 0.132 from november 24th because its safe to all rush to run before christmas? honest answer please

What are you even asking? In order to signal segwit support, they have to stop using their legacy nodes and use segwit capable ones. If there is a "rollback" (which is impossible without a hard fork), then they have previous versions they can use unless they are so stupid that they don't use a VCS.

even without signalling support. pools can run a node on the side to ensure it can import/export keys, ensure theres no trojans, send tx's to see if they get rejected. again before flagging.
even without making a block. (imagine it usernode to usernode). use actual bitcoin transactions in combination with the segwit signing procedure to see if it reveals bugs when using real bitcoin transactions. as oppose to the false transactions on testnet. this can be done without activation.
to trule see how it interacts with 'legacy' nodes within the real blockchain (im talking tx relay not block creation)

there are many other tests that can be done onchain without having to actually activate it. but still do things onchain
i do love how you are brushing possible tests that can be done purely to push the rush rush rush rhetoric

tested on testnet.. tested on testnet.. tested on testnet..
thats like saying testing it on Clams or other alts... meaningless
it needs testing on bitcoin main net before settling minds can then say its safe to then flag consensus.
so stop thinking it should be active by christmas and atleast settle for atleast spring next year (if people are doing the right thing and checking)

It is impossible to test on the mainnet without it being active. It is tested on the network most analogous to the mainnet which is the testnet.

even without signalling support. pools can run a node to ensure it can import/export keys, ensure theres no trojans, send tx's to see if they get rejected. etc etc etc again before flagging.

expecting pools to just change from legacy based on "trust" and not doing their own due diligence is a flaw in security.

its better to tell people to expect a spring 2017 .. rather then go with people shouting "activate pre-christmas"

[achow101]

so ignore the 1% because rush rush rush.. got ya

No, I never said that. The 1% are legitimate bugs that are all low severity bugs. No severe or critical bugs have been found on a release, only on testing versions, if at all. Usually they are caught during the pull request code review time before being merged into the master branch.

Do you really think that they are rushing? Have you not seen the massive deadline slip? Core releases are always late. They are always released later than they plan to.

and i said for a activation pre christmas requires the retarget period to begin at the latest november 24th.. thus only giving 9 days to go from 0-95% to then be constant 95 for the period.
remember you replied to me about people who wanted a pre-christmas activation. so i was showing the requirements needed to get it.
which i see you avoided answering as a bad thing. but subtly suggesting people just just run it and trust it works

No, I wasn't avoiding your question, I was misunderstanding what you were saying. I do not think it is a bad thing for segwit to activate as soon as possible because I know that miners have been writing and testing segwit implementations for a few months now. I know that several core devs are also helping them write and test segwit so that it will be ready by the start time. However, I don't think it will activate until early 2017 at the earliest because there are still some miners who actively block it.

The latest date for the retarget period to have segwit active before Christmas is actually November 27th. November 24th is more than 4 weeks before Christmas. The actual earliest possible activation date is December 17th. That means that miners would need to start signalling on November 19th, 4 days after 0.13.1's release. After that it would be December 31st.

even without signalling support. pools can run a node on the side to ensure it can import/export keys, ensure theres no trojans, send tx's to see if they get rejected. again before flagging.
even without making a block. (imagine it usernode to usernode). use actual bitcoin transactions in combination with the segwit signing procedure to see if it reveals bugs when using real bitcoin transactions. as oppose to the false transactions on testnet. this can be done without activation.
to trule see how it interacts with 'legacy' nodes within the real blockchain (im talking tx relay not block creation)

there are many other tests that can be done onchain without having to actually activate it. but still do things onchain
i do love how you are brushing possible tests that can be done purely to push the rush rush rush rhetoric

What makes a transaction on testnet a "false transaction"? That it has no monetary value? It is all technically the same. Furthermore, doing any of that testing on mainnet before activation would not even work because Segwit hasn't activated on mainnet.

All the tests that can be done "onchain" cannot actually be done on the mainnet blockchain without activation. All the tests that do not rely on the network can and already have been done (i.e. import/export keys, create and sign transactions, create witness addresses).

even without signalling support. pools can run a node to ensure it can import/export keys, ensure theres no trojans, send tx's to see if they get rejected. etc etc etc again before flagging.

expecting pools to just change from legacy based on "trust" and not doing their own due diligence is a flaw in security.

Most of them are implementing segwit in their own software, so there is no concern about that with running Bitcoin Core. Furthermore, Bitcoin Core uses a deterministic build process so the binaries are always the same. They can review the code changes since the last release and build it themselves and see if the hashes match. It's fairly simple to do, and part of the release process is to have multiple people do the deterministic build to check that all the hashes match.

[Wind_FURY]

This thread escalated quickly into a word war between core and the big blockers. While I do support both movements and could see the advatages of both, I do like to see Segwit and then the Lightning Network be implemented first. I just think avoiding a hard fork for as long as possible as a safety measure must be the path to follow.

I am excited for 0.13.1, let's all hope everything all goes as planned and as smoothly as possible. From a speculator's standpoint, the potential for the Lightning Network is more promising and exciting for me.

[hv_]

Very interesting. Lets see what game theory says. Chinese miners seem to start evaluating on chain scaling again:

https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=https%3A%2F%2Fmp.weixin.qq.com%2Fs%3F__biz%3DMzIxNTA0NDQzMA%3D%3D%26mid%3D2651797972%26idx%3D1%26sn%3Da1dea9858a16b519258dee91176d2a8b%26chksm%3D8c65c1f5bb1248e382745b80b421bcc3fbbeb91cac20ae74c020315363d36756ad2f056325ec%26mpshare%3D1%26scene%3D1%26srcid%3D1022MmwyTZv0RtFUNVZwztBb%26from%3Dgroupmessage%26isappinstalled%3D0%23wechat_redirect&edit-text=&act=url

[croutonhexagon]

Awesome technology. Yes we need some modification and new technology in bitcoin to make it go on the same track with the modern technology and trends. I think if money investment in bitcoin happens then we will have price rise in bitcoin, i am not sure about the price.

[HandoR]

Who makes the decision of applying these new rules?

[Carlton Banks]

This thread escalated quickly into a word war between core and the big blockers. While I do support both movements and could see the advatages of both, I do like to see Segwit and then the Lightning Network be implemented first. I just think avoiding a hard fork for as long as possible as a safety measure must be the path to follow.

This is the big joke IMO amongst the whole debate: that's pretty similar to what my actual position is, too. But I'm probably cast, by those doing the casting, as an arch small-blocker.
"Staying conservative for as long as possible" is how I'd sum it up, but that doesn't close the door on increasing the transaction blocksize as well as the signature blocksize. Be kind of hard for me to support Segwit without supporting blocksize increases, the signature block is 6x the size it would have been if no increase had been introduced with Segwit.

I am excited for 0.13.1, let's all hope everything all goes as planned and as smoothly as possible. From a speculator's standpoint, the potential for the Lightning Network is more promising and exciting for me.

Yep. Even if the opportunity wasn't taken to make the signature blocks bigger, this still would've been the most important update purely because it makes Lightning possible, and Lightning's going to do more for the transaction rate than any blocksize increase can.

[hv_]

Huh?

The very most conservative change to bitcoin would be to keep historical distance from used block size to max limit - in percentage!

No more

 

[franky1]

This thread escalated quickly into a word war between core and the big blockers. While I do support both movements and could see the advantages of both, I do like to see Segwit and then the Lightning Network be implemented first. I just think avoiding a hard fork for as long as possible as a safety measure must be the path to follow.

I am excited for 0.13.1, let's all hope everything all goes as planned and as smoothly as possible. From a speculator's standpoint, the potential for the Lightning Network is more promising and exciting for me.

my only criticism is this hypocritical 9 days to attain 95% and then the month to keep 95% to activate before the christmas new year period.
yet cores code is not set in stone yet. even 3 days ago it has changed.

other proposals have had a RC running on mainnet right now and for months, code is fixed in stone for their concept..
yet core proposal doesnt even have an RC that is actually running on mainnet. or fixed in stone for others to confidently make their diverse implementations of.
pools need to change alot. and while the code is still tinkering with even days ago. its silly to try suggesting activation before the new year.

but strangely 9 days after RC is available(code set in stone) is hypocritically acceptable time for others to make their own diverse implementations based on cores RC next month.
afterall there is no point using cores 2 month old code, thats outdated already.
also to keep tweeking it daily to match the tinkerings. and then told 'all is fine rush it, rush it rush it,'

but simultaneously core have been saying it will take them a year to code something similar whats already an RC of other proposals
followed by 6 months for others to make their own diverse versions after cores version becomes an RC..(before activation can even occur)

its has all been a bait and switch double-standard hypocrisy.
afterall
where is all the safety rhetoric about grace period time for others to make diverse implementations that meet the rules
even smart people should not be shouting "now now now" simply to uphold their old "safety concerns"

[achow101]

Franky, stop with the lies.

my only criticism is this hypocritical 9 days to attain 95% and then the month to keep 95% to activate before the christmas new year period.
yet cores code is not set in stone yet. even 3 days ago it has changed.

The last code change was 6 days ago. The thing that changed 3 days ago were just docs (the release notes) and some comments in the code.

other proposals have had a RC running on mainnet right now and for months, code is fixed in stone for their concept..
yet core proposal doesnt even have an RC that is actually running on mainnet. or fixed in stone for others to confidently make their diverse implementations of.
pools need to change alot. and while the code is still tinkering with even days ago. its silly to try suggesting activation before the new year.

The vast majority of the segwit changes have been fixed in stone since the PR for it was merged several months ago. The final change was just the deployment which required changing two lines. People have been running those changes since they went in, either with a build of the master branch or with one of the RC's for 0.13.1 that were tagged and released last week.

but strangely 9 days after RC is available(code set in stone) is hypocritically acceptable time for others to make their own diverse implementations based on cores RC next month.
afterall there is no point using cores 2 month old code, thats outdated already.

The release is going to be available for a few weeks before that earliest start time. The Nov. 15th date is not the date for the software release but rather the date the miners can start signallying. It is very different from the software release date which will be next week.

also to keep tweeking it daily to match the tinkerings. and then told 'all is fine rush it, rush it rush it,'

Segwit isn't being "tweaked daily". The things that are being tweaked are not consensus related and do not matter to other developers implementing segwit. All of the consensus changes were made a long time ago. No one is saying "rush it rush it".

but simultaneously core have been saying it will take them a year to code something similar whats already an RC of other proposals
followed by 6 months for others to make their own diverse versions after cores version becomes an RC..(before activation can even occur)

its has all been a bait and switch double-standard hypocrisy.
afterall
where is all the safety rhetoric about grace period time for others to make diverse implementations that meet the rules
even smart people should not be shouting "now now now" simply to uphold their old "safety concerns"

All that safety rhetoric is still there, but the key point is that all those wallets and miners have been working on their implementations of segwit long before the release. They don't have to start working on it after the release, they work on it beforehand. Again, no consensus changes to segwit have been made since it was merged except for the deployment start time which is a very easy change. Only local node policy (which can be easily taken care of because that local node policy was already a standard thing for wallets to already be doing) and local changes within Bitcoin Core itself.

[franky1]

All that safety rhetoric is still there, but the key point is that all those wallets and miners have been working on their implementations of segwit long before the release. They don't have to start working on it after the release, they work on it beforehand. Again, no consensus changes to segwit have been made since it was merged except for the deployment start time which is a very easy change. Only local node policy (which can be easily taken care of because that local node policy was already a standard thing for wallets to already be doing) and local changes within Bitcoin Core itself.

same has been said about BU which is actually already running on mainnet for months as a release.. yet the 12 months coding rhetoric, and 6 months grace, 6 months grace, 6 months grace repeated 'safety' concern
do you see the hypocrisy
delay or else..
but rush core activation.. screw pools own local needs..instead 95% by christmas, beat your chest, get it done now now now

why so desiring a pre-new year activation.. hmm? why not just let pools flag it when THEY ARE CONFIDENT. why not atleast be calm and say hopefully by spring 2017

again emphasis: why wishing for rushing to 95% yet argue other proposals should take a natural long time to get 95%.

[achow101]

same has been said about BU which is actually already running on mainnet for months as a release.. yet the 12 months coding rhetoric, and 6 months grace, 6 months grace, 6 months grace repeated 'safety' concern
do you see the hypocrisy
delay or else..
but rush core activation.. screw pools own local needs..instead 95% by christmas, beat your chest, get it done now now now

why so desiring a pre-new year activation.. hmm? why not just let pools flag it when THEY ARE CONFIDENT. why not atleast be calm and say hopefully by spring 2017

again emphasis: why wishing for rushing to 95% yet argue other proposals should take a natural long time to get 95%.

I highly suggest that you not listen to people other than the developers of their software. No developer I have talked to has ever said "rush it rush it" for segwit. No developer I have talked to has said that they are going to cut corners to get segwit out the door as fast as possible.

All the people who are saying "rush it" or "we need super long grace periods for hard forks" are misconstruing what the developers are saying. The concern about the hard forks was because for it to be done properly, everyone needs to upgrade. However, people have misconstrued that and continuously repeated that over and over again as "we need super long, months long, grace periods". No developer has said that "we need segwit out asap so rush it", only uninformed users.

Users who use Core do not represent Core, only the developers. Likewise users who use Classic or BU do not represent them, only their respective developers. To say that the users who use those software represent what those groups of developers are saying or want to do, is disingenuous.

[franky1]

but we know you are not just a "user" so i specifically chosen to get an answer from you.

here is the subtle point.

if there is a RC available next week with unchanged code viewable (consensus AND LOCAL) available for a weeks prior.
should there be a 12 month coding delay just so that the opposition can code something equivalent.
then after 12 months. get to 95%. and then after 95% have 6 months grace
even when the code has been viewable weeks before RC release 18 months earlier then when you finally want it activated.

give yourself an answer and hold that answer and dont change it.

now then lets add an extra dimension to the question
if there is a RC available months ago with unchanged code (consensus AND LOCAL) available even before that.
blah blah same timescale 12month 95% 6 months grace
blah blah code available before RC

if the answer is no. then you will see the issue in a minute

however lets continue
if devs have not coded a diverse implementation by the time a RC is released. it is the devs own fault .. right??
devs should instead not give own timescales to then make their own equivalent as its deemed delaying..  but just run the RC ... right??
they should not test the RC because its their fault and treated as delaying if making a request for time. and trust the RC works... right??

think long and hard about the subtle point.

now if you still think there is no reason for 12 months coding and 6 months grace after a RC, anyone asking for time should be disregarded..right?

now explain the last year of civil war.
where core agreed to flex caps. a RC was released. but then core backtracked.
oh wait i can predict you flip flopping your answers while reading this to protect your interests

do you atleast see the subtle point of hypocrisy?

[achow101]

but we know you are not just a "user" so i specifically chosen to get an answer from you.

here is the subtle point.

Your point is not subtle. Look up the definition of subtle.

if there is a RC available next week with unchanged code viewable (consensus AND LOCAL) available for a weeks prior.
should there be a 12 month coding delay just so that the opposition can code something equivalent.
then after 12 months. get to 95%. and then after 95% have 6 months grace
even when the code has been viewable weeks before RC release 18 months earlier then when you finally want it activated.

give yourself an answer and hold that answer and dont change it.

The opposition? As in Classic and BU? Or do you mean other wallets like Armory and Electrum?

Either way, no, that time frame is way too long, for both hard and soft forks. Technology moves quickly, that timeframe is much too long.

If we assume that the changes were implemented and the only time that those changes were seen are after the release has been made, I would say that 1 month is probably sufficient to fully implement and test a large code change such as segwit assuming that the released version of the reference implementation has no major bugs, is well documented, and the devs actively answer questions and comments (which means that they extensively tested the change prior to the release).

With the code available beforehand but still somewhat WIP (as with the case of segwit where the vast majority of the code was already finalized and merged with just some local stuff that was being changed), then I would say that 2 weeks are sufficient. This is because the devs can work on their implementations at the same time as or immediately after the main code change was implemented and merged. Any following changes can also be implemented relatively quickly. It is much easier to implement something when there is an existing codebase that you can reference.

A 6 month grace period is too long. I would say 4 weeks at most, 2 weeks is fine, for both hard and soft forks (keep in mind that previous soft forks except CSV have had no grace period whatsoever).

And I know you are going to say that those other devs did not test the change itself. But in actuality, they do. When they implement the change using the existing reference implementation as a reference, they are essentially doing code review on that. If they find any bugs during that review, they are reported and fixed. Those devs will also be running their own tests on their implementation of the software. If they find any issues there and it is related to the change itself and not the implementation, then those are reported too. Having the devs work on different implementation simultaneously allows for more robust code as each dev will have their own set of tests that will catch issues in the entire change itself and not just their implementation.

now then lets add an extra dimension to the question
if there is a RC available months ago with unchanged code (consensus AND LOCAL) available even before that.
blah blah same timescale 12month 95% 6 months grace
blah blah code available before RC

I don't see how that changes anything.

if the answer is no. then you will see the issue in a minute

however lets continue
if devs have not coded a diverse implementation by the time a RC is released. it is the devs own fault .. right??

Yes. However it is their choice whether to make an implementation or not.

devs should instead not give own timescales to then make their own equivalent as its deemed delaying..  but just run the RC ... right??

No. Devs should still take their time to carefully implement the changes even after the official release has already been made. This is the case for Armory because we started work on segwit a few months following the merge of the code change instead of working on it simultaneously. It is unlikely that we will have the segwit stuff released by November 15th.

they should not test the RC because its their fault and treated as delaying if making a request for time. and trust the RC works... right??

No. When they are doing the code review during their own implementations, any critical issues with the implementation of the rc can and should be reported. These can be blockers and delay the official release, but it is all needed and welcomed in order to produce code that is as secure as possible.

think long and hard about the subtle point.

now if you still think there is no reason for 12 months coding and 6 months grace after a RC, anyone asking for time should be disregarded..right?

Given that segwit is a soft fork, anyone asking for time should be disregarded unless they find a critical bug. If it is just a request for a delay because they want to have a release out for segwit at the same time, then that can be disregarded. Their software's current state will continue to function following activation. They can still take their time to implement segwit properly. Note that this is only because segwit is a soft fork.

For hard forks, anyone asking for time should not be disregarded so that everyone on the network can upgrade at around the same time to avoid chain splitting.

now explain the last year of civil war.
where core agreed to flex caps. a RC was released. but then core backtracked.

When did Core agree to flex caps? When was a release made with flex caps?

oh wait i can predict you flip flopping your answers while reading this to protect your interests

Oh wait, I can predict you cherry-picking my answers so it seems like they flip flop to you so you can further attack me.