A more important consideration than segwit's timeout is when code can bereleased, which will no doubt be several months after SegWit's currenttimeout.

Greg's proposed 6 months seems much more reasonable to me, assuming itsstill many months after the formal release of code implementing it.

Matt

Post by Gregory Maxwell via bitcoin-devBased on how fast we saw segwit adoption, why is the BIP149 timeout sofar in the future?It seems to me that it could be six months after release and hit thekind of density required to make a stable transition.

Agreed, I would suggest 16th December, 2017 (otherwise, it should be16th January 2018; during EOY holidays seems a bad idea).This means this whole debacle has delayed segwit exactly 1 (2) month(s)beyond what we'd have if it used BIP8 in the first place.Cheers,Rusty._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

The current proposal assumes that bip149 would only be merged andreleased after nov15, so there's not time in one day.

My preference would be a bip149 proposal that could be merged andreleased now, but some people complain that would require moretesting, because if you deploy bip149 and then sw gets activated prenov15, then you want bip149 nodes to use the old service bit forsegwit, not the new one (you would use that one if it activates postnov15, so that pre-bip149 nodes don't get confused).

I was slowly modifying shaolinfry's code to try to code that, but I'mcurrently not working on it because there doesn't seem there's a lotof interest in releasing bip149 before nov15...

https://github.com/jtimon/bitcoin/commits/b15-shaolinfry-bip149

On Sun, Jun 11, 2017 at 7:48 AM, Ryan Grant via bitcoin-dev

Post by Ryan Grant via bitcoin-devIs there any reason that BIP149 activation on November 16th wouldcause a problem?_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

"My preference would be a bip149 proposal that could be merged andreleased now, but some people complain that would require moretesting, because *if you deploy bip149 and then sw gets activated prenov15, then you want bip149 nodes to use the old service bit forsegwit*, not the new one (you would use that one if it activates postnov15, so that pre-bip149 nodes don't get confused)."(emphasis added)

Why not just make sure BIP 149 will never activate unless BIP 141 hasexpired unsuccessfully? If BIP 141 should unexpectly activate, thenBIP 149 nodes would notice and act as pre-SegWit nodes indefinitely,but remain in consensus with BIP 141 nodes.

It might be slightly less convenient for BIP 149 users to upgradeagain, but then at least we could start deploying BIP 149 sooner.

Right, that would be part of it, as well as not removing the BIP141deployment with bip9.See https://github.com/jtimon/bitcoin/commit/62efd741740f5c75c43d78358d6318941e6d3c04

Post by Martijn Meijering via bitcoin-devIf BIP 141 should unexpectly activate, thenBIP 149 nodes would notice and act as pre-SegWit nodes indefinitely,but remain in consensus with BIP 141 nodes.It might be slightly less convenient for BIP 149 users to upgradeagain, but then at least we could start deploying BIP 149 sooner.

No, if segwit activates pre nov15, bip149 nodse can detect andinterpret that just fine.The problem if it activates post nov15, then you need a separateservice bit in the p2p network, for pre-BIP149 will think sw hasn'tactivated while post-BIP149 would know it has activated.

If you release it only after nov15, you don't need to testcompatibility between the two for neither of this two cases.Or do you? Actually you only save testing the easier case of pre-nov15activation.