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.
you literally said it in the same reply.. they do not relay them.. meaning its an issue..
if a
segwit node connected to a
old node and then the
old node connects to a
pool... the
pool wont get the tx.. because the
old node drops it.
segwit node-
old node-
poolso this is where segwit has to mess with what it connects to, to ensure its tx's get relayed to a pool
old node-
segwit node-
poolor to get past your padantic sidestepping.. segwit by default looks to find segwits first and then after activation it will have to white list old nodes
edit: old nodes(downstream) of the segwit node(upstream/gatekeeper)
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.
a malicious pool could include it in a block and then spend it. hence why you fear making transaction now with p2wpkh keys right now.. and have not included the p2wpkh key generation for
mainnet use in the versions you have released so far.
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.
fine you are releasing something unrelated in 0.14.0. but 0.14.X or 0.15.X... whatever the version number will be that includes MAINNET utility of p2wpkh and p2wsh key generation wallets, wont be released until after segwit activation.
im kind of thinking your just being knit picky about the version number rather then the fact of the p2wpkh and p2wsh key generation wallets available only AFTER activation, context.
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.
again lets not play your version number knitpicky game (facepalm at ur fail)
the version with the p2wpkh and p2wsh key generation wallets, AFTER activation will ensure there is a path from a segwit node to a pool because as you yourself said old nodes have issues and wont relay segwit unconfirmed tx's (red text at top)
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
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.
right now segwit is not activated so nothing now needs to change as there is only one varient of data being created right noe..
but in the context of after activation..
the context of it is instead of white listing OLD nodes as special and then send the blocks in a format old nodes understand. they will just connect to other segwit nodes and let the pools send whichever version block needs to go to whichever version node.
i even quoted the guide that says it too.. where messing with old nodes is a hassle(needing to white list old nodes.. so human psychology is that people wont whitelist old nodes but prefer segwit nodes.
you are really chomping hard at the bottom of the barrel of words.. rather then being honest of the context.
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.
yes your segwit nodes are already avoiding connecting to older nodes(even when right now its not nessessary).. i hear many people shouting loudly how they are not white listing old nodes already.
oh im inaccurate because my image was a 50/50 but i bet your claim is that its not a 50/50 because you see 61%... (facepalm).. the context is that old nodes and new nodes are not going to interact as much..
again knick pick the numbers if you want... but atleast try to aim at being honest with the context. because it is a failure of your honesty and a failure of you actually making a point by side stepping the context with silly knitpicks.
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.
you again are petty knitpicking.. i never said a node RECEIVES 2 variants.. i said a pool or a node that has been generous to white list old nodes. has to CREATE 2 varients (your buzzwords, stripped and unstripped). sending one varient to new and one variant to old..
petty knit picker. you have still not said anything that makes a point that differs. you are just swapping common speech for your buzzwords
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.
so because you have enough gatekeepers old nodes are meaningless to you
if segwit activates and lets say nodes stayed at under XX%.. by looking at the context of your reply. seems you will just leave oldnodes reliant on the very few generous segwit nodes and pools that do white list old nodes. but not care much about old nodes being part of the network because segwit are the gate keepers
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.
so your context is that old nodes are not important. and ok to ignore old nodes..
oh and as for bare minimum of segwit nodes.. shall we let you retry you explaining the relaying of unconfirmed transactions needed to ensure segwit transactions reach a pool (instead of your side stepping the concept to argue about the number version).
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.
yes you can run a old node without changing. but ur relying on segwit nodes to do the gate keeper duties. and filtering data to an old node.
if you had integrity, you would actually inform people their old node is not full validating.
if you had integrity, you would actually inform people their old node is reliant on a sgwit node being the gate keeper.
you wouldnt just stroke peoples heads and tell them its ok to be treated as second class like its nothing.
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.
a hard fork using consensus only activates with high majority. and i personally have been honest to say that old nodes not upgrading will be left unsynced.. yes its harsh. but atleast its honest.
side node.. "downstream modules".. is that what your buzzword is for the older nodes your segwit nodes have to whitelist. while segwit use the upstream modules buzzword i called the gatekeepers.. ill remember that.
Poll
