For those who don't know it, Franky1 appears to have a full time job lying about segwit on Bitcoin talk. I see that he now has technobabble charts to match his technobable claims. The graphs look sciency but actually have nothing to do with Bitcoin at all-- no part of Bitcoin before of after segwit has any resemblance to either of those meshy graphs. He's stuffing that stuff into his posts in order to make people who don't know much about the technology believe that he knows more than them.
I have him on ignore and I strongly recommend other people set him on ignore too.
I got asked to post some corrections here, so I am.
BUT before confirmation because it appears as signatureless tx (anyonecanspend) old nodes can cause issues.
Pre-segwit nodes know they don't understand segwit transactions so they simply do not relay or mine them. They don't cause any issues. The reason they do not relay or mine them is because segwit uses some intentionally constructed forward compatibility in the protocol, which was put in by Satoshi specifically to enable new signature systems. They'll tolerate things using this forward extensibility when they show up in blocks, but because they can't completely judge the validity on their own, they don't mine them (or relay them) themselves.
this is why 0.14(the implementation with p2wpkh and p2wsh key generation wallets) wont be released before activation.
0.14 will be released in Feburary/March and has nothing to do with segwit. Segwit support went into 0.13.1.
and then after activation, 0.14 wont connect with non-segwit nodes for relaying unconfirmed transactions to avoid the silly things that happen at unconfirmed relay level.
No, 0.14 is exactly the same as 0.13.1 with its connections and don't do anything special with relaying unconfirmed transactions. Sounds like you are mixing up the behavior of 0.14 with the behavior of pre-segwit nodes.
they could connect to old nodes and just relay old transactions. but lets be honest segwit-node users wont bother doing all the setting changes to mix and match tx's. so will just whitelist segwit nodes to make things simple
The behavior of segwit enabled nodes is no mystery. The software has been complete for almost a year now, and has been running on the majority of the nodes on the network is months. They don't "whitelist segwit nodes" to make things simple or otherwise.
segwit will divide the network at unconfirmed tx relay level
To avoid any instantaneous disruption of the network topology segwit nodes make no changes to their connection behavior when segwit activates. So if they would divide the network, it would already be divided. ... though considering that over 61% of listening nodes are segwit, it would be impossible for them to 'divide' the network in two even if their behavior were like you inaccurately describe it.
technically its all the 'same network' (due to all nodes connecting to a pool), but the nodes become more biased to only communicate with their own kind. where it becomes more work for a pool to send out 2 different variants of a block. --witness
Nope. No more block versions are sent out, if someone wants a stripped block they get a stripped block. But every node creates stripped blocks for non-segwit peers that want them, and in no case does two versions need to be sent to any peer.
again core will try to advertise the need to get nodes to upgrade to gain more connections and be more part of their side of the network (although in their half truth twisting of words is one network)
And yet no such 'advertisement' has happened or is necessary. That might have been the case if there was risk of segwit activating with only a couple percent of nodes being upgraded, but a couple percent was passed in the first few hours of 0.13.1's release.
this is why it should have been a proper network consensus rather than a emulated consensus of just the pools, so that by being a full network consensus before pools, allows the nodes to be ready and fully compatible rather than just SPV compatible to segwit
Again, 61% of reachable nodes. If a consensus of nodes were all that were required-- that would have long since been passed. But softforks do not require nodes beyond a bare minimum. They're safe with just mining.
as you can see by segwits own guide. if not upgrading they want you to set up another node to 'filter' your unupgraded node through a segwit node (facepalm) when sending old tx's but you wont receive new tx's. it also allows segwit nodes to be the controller of what becomes a 'valid block' or not. rather than the old node doing independent checks
The guide is also quite specific that you have the freedom to do nothing. If you want segwit validation for the strongest security you can also get it without modifying your existing software and risking disruption of your operation. This is pure flexibility that you have from a softfork, a free choice you can make or not make, which is ripped away from you by hardforks. In a hardfork you cannot retain your existing infrastructure at all, you must replace it with upgraded software which may be incompatible with the customizations and downstream modules you already have running.
There is no point in discussing SegWit in its current state as it lately became clear that miners won't support this update.
Segwit has more hashrate than BIP66 did this many days after start. Your opinion is possibly being manipulated by malicious people who are exploiting the fact that it often takes miners a long time to upgrade to try to convince you that segwit will not activate.
It will activate if people want it and make their preferences known, no more, no less. Contrary to franky1's claims I nor any of the other developers get paid based on segwit activating. We did our part.
Personally, I'm happy that it hasn't activated yet (though not so happy about the people lying about it). The lack of urgency in getting it going coupled with the continued health and success of Bitcoin without any capacity increase just shows what a big stinking liar people like franky1 have been with their hyper-aggressive doom and gloom claims that Bitcoin was going to fail unless it had a capacity increase ASAP.