Quote from: Red-Apple on January 21, 2017, 03:54:40 PM

i disagree. it is not a civil war unless we make it one.

currently we are waiting for the miners to decide on the acceptance or denial of SegWit (the proposal they are signalling- BIP141 IIRC)

and users have only nodes to voice their opinion and there are only ~5000 nodes and lot more users. so i want to know out of the 929828 members on bitcointalk and ~2 million daily visits and more other places how many want, don't want or even have no idea about BIP141

and as i said in OP, this the results will just be results.

(so far 126 times read and only 7 votes!)

you do understand segwit right??

you understand that although when confirmed in a block old nodes dont fully validate the tx. but instead blindly look passed it..('compatible backwards' cough cough)
BUT before confirmation because it appears as signatureless tx (anyonecanspend) old nodes can cause issues.

this is why 0.14(the implementation with p2wpkh and p2wsh key generation wallets) wont be released before activation.

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.
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 connect to segwit nodes to make things simple

yes after tx are passed by segwit nodes to a segwit accepting pool, they will then relay block data out to all nodes new and old.. but due to the unconfirmed tx relay part. segwit will divide the network at unconfirmed tx relay level

segwit done as non network consensus node activation is going to cause issues.. but core wont tell you about this until after its activated as a strongarm motive for everyone to jump onboard at a rapid pace to join their nodes. or be left ignored. (changing the network)

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

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)

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

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

https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/

Quote

In this configuration, you set your current Bitcoin Core node (which well call the older node) to connect exclusively to a node running Bitcoin Core 0.13.1 or later (which well call the newer node). The newer node is connected to the Bitcoin P2P network as usual. Because the newer node knows about the segwit changes to the consensus rules, it wont relay invalid blocks or transactions to the older nodebut it will relay everything else.

When using this configuration, please note that the older node, if it uses Bitcoin Core defaults, will not see transactions using segwit features until those transactions are included in a block.

Configuration:

For the newer node, start it normally and let it sync the blockchain. At present, you cannot use a pruned node for this purpose because pruned nodes will not act as relay nodes. You may optionally start the newer node with either or both of the following command line parameters so that it treats the older node as special (these options may also be placed in Bitcoin Cores configuration file):

  -whitebind=
   Bind to given address and whitelist peers connecting to it. Use
   [host]:port notation for IPv6

  -whitelist=
   Whitelist peers connecting from the given netmask or IP address. Can be
   specified multiple times. Whitelisted peers cannot be DoS banned
   and their transactions are always relayed, even if they are
   already in the mempool, useful e.g. for a gateway

For the older node, first wait for the newer node to finish syncing the blockchain and then restart the older node with the following command line parameter (this may also be placed in the Bitcoin Core configuration file):

-connect=