On Segwit not being backwards compatible question

[Wind_FURY]

Danny Hamilton, achow, Carlton Banks and the rest of the Bitcoin technical gurus, can you comment on the post I quoted.

I left his name out on purpose. I want an unbiased technical approach to answer this.  

segwit is not backward compatible
segwit tx's is set to be (ELI-5) invisible/ (ELI-15) not validatable by old consensus.
if you looked into it you will see terms such as what gmax named "upstream" filter nodes and LukJR calls "bridges" which is where if a old client just connects to the network and received the current block data the same way a segwit node does. it wont be understood.
a segwit node has to act as a translater and convert the chain of 2017+ into a different format specifically for the requesting node.
https://bitcoincore.org/assets/images/filtering-by-upgraded-node.svg



in short. if segwit nodes had a bug. you cannot just manually copy and paste the blockchain data from a folder to another folder for an old client and carry on. its all completely different.
so with all currnt nodes being strict core2017+ policy/rule following nodes. if core nodes did bug out they cant just downgrade to an earlier version. because the data would not have a translater.. (the translator has the flu)
EG. the 2013 levelDB event would have crashed the network if people were not able to just downgrade without a translator required.
back then they didnt need a translater so downgrading was simple.. now thats not the case. and makes the network more fragile to bug attack of a client running exact same ruleset and codebase

even the guidelines on upgrading to segwit say. if you want to run an old node, due to the network not wanting to act as translators for old clients(ban-hammer) you would personally need to download a segwit client. and white list yor old node to get accepted and then let your segwit client translate data for the old client. where by your old client treats segwit transactions as not requiring validation (funky tx's)
(image above simplifys the waffle)


imagine a system of checking passports. where in a decentralised world every passport needs checking.
segwit is set to be a diplomatic immunity holder that pretends the block creator validated them and so the decentralised consensus network do not need to check it.

There is also this little fun drama I want to ask about. I believe "they" means Barry Silbert and his friends.

segwit is a consensus rule break. hense why from november 2016-summer 2017 they only had 35% consensus vote and thus segwit would not have got activated as it would caused issues to the network at 35%

thats why they got bloq to make cash. to get rid of the 65% opposers. so that segwit could fake a 95% vote to activate segwit

bloq and core are partners in crime. the bilateral split was a bi-directional (2 altcoin) event that both are different codebases,, address types, network topology compared to bitcoin 2009-2013

Is this bullshit? Then what really happened?

[nc50lc]

I left his name out on purpose. I want an unbiased technical approach to answer this.  

Unfortunately, the source was on my watchlist all along: A reply from franky1 Thoughts on the Bitcoin vs Bitcoin Cash Dilemia  

[Xynerise]

segwit is not backward compatible

Yes, it is -- as much as soft forks can be backwards compatible.

segwit tx's is set to be (ELI-5) invisible/ (ELI-15) not validatable by old consensus.

Yes, that's HOW it is backwards compatible; segwit transactions appear as anyone-can-spend to old (non-segwit) nodes.

in short. if segwit nodes had a bug. you cannot just manually copy and paste the blockchain data from a folder to another folder for an old client and carry on. its all completely different.
so with all currnt nodes being strict core2017+ policy/rule following nodes. if core nodes did bug out they cant just downgrade to an earlier version. because the data would not have a translater.. (the translator has the flu)

This applies for all SOFT FORKS.

EG. the 2013 levelDB event would have crashed the network if people were not able to just downgrade without a translator required.

The LevelDB incident caused an inadvertent chain split/ Hard fork.

back then they didnt need a translater so downgrading was simple.. now thats not the case. and makes the network more fragile to bug attack of a client running exact same ruleset and codebase

Again, this applies to all soft forks, unless you, like Popescu, are against soft forks and don't consider P2SH addresses and transactions as valid.

imagine a system of checking passports. where in a decentralised world every passport needs checking.
segwit is set to be a diplomatic immunity holder that pretends the block creator validated them and so the decentralised consensus network do not need to check it.

Segwit transactions are not validated by legacy nodes because legacy nodes CANNOT correctly validate them.

All his talking points apply to ALL SOFT FORKS in bitcoin, from BIP16(P2SH) to CLTV, to Segwit.

lots of stupid conspiracy theory which doesn't bear quoting/quote]
It's missing Blockstream, AXA, Bilderberg and Jews to be complete.

. the bilateral split was a bi-directional (2 altcoin) event that both are different codebases,

What does "different codebase" mean?
Bitcoin version 0.3 is a different codebase from 0.8 or even 0.16, so are upgrades a bad thing?
Should the code have been left untouched since Satoshi left?

address types,

Blah blah.
"Soft forks are bad; P2SH is bad, etc."
Segwit is backwards compatible; it uses the same P2SH addresses available since BIP16 -- unless of course, you consider P2SH to be as incompatible as segwit.
Also Bech32  are just an encoding; it doesn't have to be for segwit specifically, you can use it for non-segwit.

network topology compared to bitcoin 2009-2013

Segwit wasn't deployed in 2013, so the OP has a grouse with other improvements before segwit.

Is this bullshit?

Obviously.
These talking points are usually due to ignorance or most likely the OP is being disingenuous with malicious intent.

[squatter]

segwit is not backward compatible
segwit tx's is set to be (ELI-5) invisible/ (ELI-15) not validatable by old consensus.
if you looked into it you will see terms such as what gmax named "upstream" filter nodes and LukJR calls "bridges" which is where if a old client just connects to the network and received the current block data the same way a segwit node does. it wont be understood.
a segwit node has to act as a translater and convert the chain of 2017+ into a different format specifically for the requesting node.

Franky is trying to bombard the reader with meaningless jargon to obfuscate what backward compatibility is. Let's look at what it means:

Backward compatibility is a property of a system, product, or technology that allows for interoperability with an older legacy system, or with input designed for such a system, especially in telecommunications and computing.

It doesn't matter whether legacy nodes fully understand new scripts. What matters is that both versions retain interoperability (compatibility). Necessitating that every node validates every aspect of every transaction would entail hard forking and breaking compatibility every time you wanted to add a new consensus rule.

Regarding backward compatibility, what matters is that new rules don't break consensus. If Segwit compromised the integrity of Bitcoin (regarding supply, etc.) then its blocks would be rejected by legacy nodes. Older nodes still check newer blocks against their consensus rules. They are simply continuing to propagate valid transactions and blocks, even though they may not fully understand them.

All of this was laid out by Satoshi long ago. Bolding by me for emphasis:

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime.  Because of that, I wanted to design it to support every possible transaction type I could think of.  The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time.  It would have been an explosion of special cases.  The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate.  It's just an equation that evaluates to true or false.  Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script.  Currently, receivers only accept two templates: direct payment and bitcoin address.  Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them.  All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago.  Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.  If Bitcoin catches on in a big way, these are things we'll want to explore in the future, but they all had to be designed at the beginning to make sure they would be possible later.

It should be noted that soft forks are not backwards compatible by definition, as many people wrongfully claim. As soft/hard forks are currently defined in Bitcoin development (side note -- not a fan of these definitions since they are orthogonal to network compatibility), a soft fork simply means adding/restricting consensus rules.

It's completely possible to incompatibly soft fork -- for example, if 51% of miners do not enforce the fork -- in which case a soft fork is not backwards compatible.

An incompatible soft fork and a hard fork are not particularly different, hence my distaste for the above definition.

[DooMAD]

There is also this little fun drama I want to ask about. I believe "they" means Barry Silbert and his friends.

segwit is a consensus rule break. hense why from november 2016-summer 2017 they only had 35% consensus vote and thus segwit would not have got activated as it would caused issues to the network at 35%

thats why they got bloq to make cash. to get rid of the 65% opposers. so that segwit could fake a 95% vote to activate segwit

bloq and core are partners in crime. the bilateral split was a bi-directional (2 altcoin) event that both are different codebases,, address types, network topology compared to bitcoin 2009-2013

Is this bullshit? Then what really happened?

Based purely on miners and not the economic majority, what happened is an outside developer stepped in and offered a solution that would alleviate the deadlock and prevent UASF from happening.  Miners were then left with the choice of Segwit2x or regular SegWit, Bitmain had declared they were going to launch some bullshit fork with a premine, but no one cared about that.  And then seemingly out of nowhere, BCH forked away, but lacked the hashrate to produce enough blocks to maintain the ~10 minute interval.  This indicates they had very little mining support and had to implement an emergency difficulty adjustment to compensate for it. 

The only impact BCH had was to cause SegWit2x to abandon their plans because they didn't want a 3-way fight, particularly considering BCH took some of their market demographic.

So even on purely the mining front, BCH was always the minority fork.  But that doesn't take into account the economic majority, which they had even less chance of winning.  Ultimately, it really doesn't matter who is responsible for the BCH fork. 

[Carlton Banks]

segwit is a consensus rule break. hense why from november 2016-summer 2017 they only had 35% consensus vote and thus segwit would not have got activated as it would caused issues to the network at 35%

thats why they got bloq to make cash. to get rid of the 65% opposers. so that segwit could fake a 95% vote to activate segwit

bloq and core are partners in crime. the bilateral split was a bi-directional (2 altcoin) event that both are different codebases,, address types, network topology compared to bitcoin 2009-2013

Is this bullshit? Then what really happened?

The text above in particular is pure imagination. No evidence exists that Bitcoin Core (or DGC) deliberately created Bitcoin Cash to force miners (the 65% opposed) onto the Bitcoin Cash chain.

Evidence does exist that even if that was the secret plan, it most certainly didn't work: Bitcoin Cash would have 65% of the global hashrate now if that were true. Bitcoin Cash has never had anything close to that hashrate, now or in the past (it's not even reached double digits IIRC)


What actually happened was that the miners compromised with BIP91, probably because they wanted to make sure they could continue mining without causing a controversy that would affect the BTC price too much. BIP91 was an aggressive way of getting BIP 141 (the Segwit softfork) activated, which was achieved by orphaning non-segwit signalling blocks and activating Segwit at an 80% signalling level instead of the 95% signalling level required by BIP141. BIP91 was similar to the UASF BIP148/9 in that way, it took what was a simple signalling exercise and changed into something more forceful.

Only miners ran the BIP91 code, as far as the rest of the Bitcoin network was concerned, BIP141 got it's 95% signalling and BIP91 never existed (segwit signalling went straight to 95% anyway very quickly after miners started running BIP91, which is kind of predictable seeing as miners risked losing any blocks they mined once 80% of miners were signalling BIP141). I don't know how many miners were actually ever running BIP91, as simply signalling BIP141 was enough to make sure they could continue mining without having their blocks automatically orphaned. BIP91 was a risky move, but it all happened so quickly that there was little time for anyone much to feel nervous about it (except the miners not signalling BIP141 yet, who were probably pretty stressed out for a day or so)


TBH WindFURY, you should be able to tell that most of this is nonsense without having to ask anyone; the writer suggests that the old style of Bitcoin addresses (starting with a 1) can no longer be used. This is so obviously false that it's not really worth giving any of it much time.

[cellard]

The text above in particular is pure imagination. No evidence exists that Bitcoin Core (or DGC) deliberately created Bitcoin Cash to force miners (the 65% opposed) onto the Bitcoin Cash chain.

Evidence does exist that even if that was the secret plan, it most certainly didn't work: Bitcoin Cash would have 65% of the global hashrate now if that were true. Bitcoin Cash has never had anything close to that hashrate, now or in the past (it's not even reached double digits IIRC)

Yeah, this never made sense to me. If that 65% of miners were so involved and dedicated to make Bitcoin Cash the leading crypto, then why the hell have they gone back to Bitcoin? If they had such a philosophical conviction about big blocks being the way to go, they would all keep mining BCash, even at a loss if needed, in order to support it, but facts point otherwise.

Current stats from right now can be seen here:

https://fork.lol/pow/hashrate

Looks like barely anyone cares to mine BCH compared to BTC. That conspiracy theory is therefore nonsense.

[Wind_FURY]

segwit is not backward compatible

Yes, it is -- as much as soft forks can be backwards compatible.

segwit tx's is set to be (ELI-5) invisible/ (ELI-15) not validatable by old consensus.

Yes, that's HOW it is backwards compatible; segwit transactions appear as anyone-can-spend to old (non-segwit) nodes.

in short. if segwit nodes had a bug. you cannot just manually copy and paste the blockchain data from a folder to another folder for an old client and carry on. its all completely different.
so with all currnt nodes being strict core2017+ policy/rule following nodes. if core nodes did bug out they cant just downgrade to an earlier version. because the data would not have a translater.. (the translator has the flu)

This applies for all SOFT FORKS.

EG. the 2013 levelDB event would have crashed the network if people were not able to just downgrade without a translator required.

The LevelDB incident caused an inadvertent chain split/ Hard fork.

back then they didnt need a translater so downgrading was simple.. now thats not the case. and makes the network more fragile to bug attack of a client running exact same ruleset and codebase

Again, this applies to all soft forks, unless you, like Popescu, are against soft forks and don't consider P2SH addresses and transactions as valid.

imagine a system of checking passports. where in a decentralised world every passport needs checking.
segwit is set to be a diplomatic immunity holder that pretends the block creator validated them and so the decentralised consensus network do not need to check it.

Segwit transactions are not validated by legacy nodes because legacy nodes CANNOT correctly validate them.

All his talking points apply to ALL SOFT FORKS in bitcoin, from BIP16(P2SH) to CLTV, to Segwit.

lots of stupid conspiracy theory which doesn't bear quoting

It's missing Blockstream, AXA, Bilderberg and Jews to be complete.

. the bilateral split was a bi-directional (2 altcoin) event that both are different codebases,

What does "different codebase" mean?
Bitcoin version 0.3 is a different codebase from 0.8 or even 0.16, so are upgrades a bad thing?
Should the code have been left untouched since Satoshi left?

address types,

Blah blah.
"Soft forks are bad; P2SH is bad, etc."
Segwit is backwards compatible; it uses the same P2SH addresses available since BIP16 -- unless of course, you consider P2SH to be as incompatible as segwit.
Also Bech32  are just an encoding; it doesn't have to be for segwit specifically, you can use it for non-segwit.

network topology compared to bitcoin 2009-2013

Segwit wasn't deployed in 2013, so the OP has a grouse with other improvements before segwit.

Is this bullshit?

Obviously.
These talking points are usually due to ignorance or most likely the OP is being disingenuous with malicious intent.

Thank you. Yes, I am starting to believe that he is one of Roger Ver's most loyal followers in /r/btc. His hate for the Core developers is like a man's hate for a cheating ex-wife. Hahahaha.

But I encourage him to go to that topic and let the readers decide. It's good for fairness' sake. Plus the more he speaks the more the bullshit is exposed as bullshit.

[cellard]

Lately the BCash propaganda machine is spamming this on a bunch of internet forums:



Looks like they really think that eventually the hashrate will go from Bitcoin to BCash because they argue that LN will not allow miners to make enough revenue for it to be more profitable that people transacting on-chain on BCash, which would eventually lead to a "flippening" and therefore chain death for Bitcoin (and as a result, BCash would become "Bitcoin").

They are trying really hard to keep the price of BCH up.

[Wind_FURY]

As long as the Bitcoin blockchain lives, as long as the market is supporting it, as long as the Core developers maintain it, as long as its community stand behind it, the word Bitcoin will always refer to what the big blockers call "Bitcoin Core".

They have lost.

[nc50lc]

-snip-

-snip-

Why here? I  mean, in this thread.

Is there any way to patent the name "Bitcoin" because V and his lads wont stop these kind of propaganda unless there's something regulating the "names".
Like a specialized world-wide patent regulatory body for open-source projects to protect the brand.
Potentially, it can minimize scam coins and ICOs too. The system will be too complicated, I guess.

Anyways, here's to be on-topic again: Yes, SegWit is Backward Compatible

[Wind_FURY]

-snip-

-snip-

Why here? I  mean, in this thread.

Is there any way to patent the name "Bitcoin" because V and his lads wont stop these kind of propaganda unless there's something regulating the "names".
Like a specialized world-wide patent regulatory body for open-source projects to protect the brand.
Potentially, it can minimize scam coins and ICOs too. The system will be too complicated, I guess.

But saying "Bitcoin Cash is Bitcoin" to confuse the public is wrong. Are you arguing that it's true? Then ok. Give me your Bitcoin address, I will give you some Bitcoins.

Are you going to give me your Bitcoin Cash address? Hahaha.

Bitcoin is the cryptocurrency the big blockers call "Bitcoin Core".

[nc50lc]

Are you going to give me your Bitcoin Cash address? Hahaha.

Did you just mistook me for a Bitcoin Trash supporter?  
The the main point of my post is: It's getting off-topic. (look at your title and OP)

Read this again:

Is there any way to patent the name "Bitcoin" because V and his lads wont stop these kind of propaganda unless there's something regulating the "names".

Anyways, no hard feelings and I think it's time to lock this thread.

Thank you. (+1 politeness)

[Carlton Banks]

Is there any way to patent the name "Bitcoin" because V and his lads wont stop these kind of propaganda unless there's something regulating the "names".

There is something "regulating the names", it's the brains and respective mouths of the people involved in cryptocurrency. If some people want to shout very loudly "Bitcoin Best is the real Bitcoin!", it doesn't much matter, because no-one else will care.

Besides, being called "Bitcoin" doesn't make something inherently or universally good, there are (probably) a majority of people out there that dislike Bitcoin, and so to them the name carries nothing but negative connotations.

The trouble with legislating this sort of thing is that the legal system is pretty corrupt already, and Bitcoin is treading on the toes of an even more corrupt system (the banking system). Do you honestly feel confident that a legal judgement about the "real Bitcoin" will produce the "right" answer?

[thecodebear]

Lately the BCash propaganda machine is spamming this on a bunch of internet forums:

Looks like they really think that eventually the hashrate will go from Bitcoin to BCash because they argue that LN will not allow miners to make enough revenue for it to be more profitable that people transacting on-chain on BCash, which would eventually lead to a "flippening" and therefore chain death for Bitcoin (and as a result, BCash would become "Bitcoin").

They are trying really hard to keep the price of BCH up.

Man BCH people are sooo desperate haha. It's pathetic. Just looking at that text, "BCH will live forever", "Bitcoin will die", "BCH will become Bitcoin". God how pathetic can you be?! You know they know they've got nothing going for them when their only tactic is to say Bitcoin will die and their altcoin will somehow become Bitcoin haha. Their entire value proposition for BCH is to pretend they are Bitcoin, which begs the question, why not just stick with the real thing haha. But I guess conmen will always try to con people.

[franky1]

segwit is not backward compatible
segwit as is, is not understood by legacy nodes. copy a segit block into a legacy block AS IS in full proper segwit format. a legacy block will not enjoy or accept it.

legacy nodes cannot FULLY VALIDATE A SEGWIT TRANSACTION
legacy nodes cannot RELAY A UNCONFIRMED SEGWIT TRANSACTION
legacy nodes cannot RELAY A stripped legacy formatted segwit block back to the relay network of segwit enabled nodes for them to validate
if you grabbed the blockchain as is in 2018. and copied it into a directory of a legacy node. the legacy node will NOT find the data compatible

imagine it this way. imagine there was a bug in segwit nodes that shut them down as soon as they run.. in no way can anyone say 'its fine the blockchain is fully understood and validated by legacy nodes and the network will run fine without distruption'.

what really happens is that segwit nodes who choose to allow legacy nodes to b conected to them, strip and translate a segwit block into something a legacy block will STORE but not fully validate
if anything segwit is "legacy translatable on request".

that way it does not confuse people to think that legacy nodes are a backup if segwit nodes fail. bcause if segwit nods fail. they wont be available to translate. so people need to be aware that there would be network disruption should segwit nodes have a bug

the bitcoin devs admit this.
they went to great efforts to explain that legacy nodes are not part of the relay network. instead they are treated as second layer nodes
which require a segwit enabled node to do the translating for the legacy node.
greg maxwell calls the segwit nodes that translate "upstream filters"
luke JR calls the segwit nodes that translate "bridge nodes"

here is even a picture of the process, provided by those that coded segwit


analogy time
segwit is wrote in dutch and the blockchain prior to august 1st is wrote in english. the legacy nodes only understand english. and anything dutch they will not accept. it requires a dutch node to translate ON REQUEST the dutch blockchain into pidgeon english. though its not 100% graammatically valid the english will blindly accept it, under the prtense that the dutch node has validated it and knows what its talking about

i use dutch as an example because of pieter wuille's native language and the fact that segwit is pieter wuille native project.

so will people stop with the propaganda that legacy nodes are on the same level playing field as segwit nodes. because its not just propaganda. its actualy a security risk to the network to make people believe that legacy nodes are fully compatible and will continu running even if segwit nodes had a bug.

and if you want to argue how much of a part legacy nodes are in the peer-to-peer network. by pretenting its all intercommunicable and everyones on the same level playing field.
take another long look at the image. then have a few coffee's, sit and think about it for a bit. ask youself why the 'older nodes's are separate. and then go read code wrote by pieter wuille, go read stuff by gregmaxwell and luke JR. go speak to the devs. and stop just taking the word of these fanboys (achowe/carlton) who care more about promoting and ovrpromosing but dont care about security/bugs.
yep ill even call out achowe who has profited in the bast from a core bug, without then reporting the bug to the core devs.

have a nice day.
be sure to sit back and have coffee.. remove the core defense cap, take off the overpromoting shirt. and relax for a bit before replying

[Wind_FURY]

franky1, I know that you made that argument to make yourself believe that Bitcoin "bilaterally split" into two so that you can call Bitcoin "Bitcoin Core" and Bitcon Cash "Bitcoin Cash".

But if we look at the history of ALL soft forks and hard forks of Bitcoin in the past, https://blog.bitmex.com/bitcoins-consensus-forks/

Do we then have the right to call Bitcoin "Bitcoin Something" post fork?

No because there was no chain split when the soft fork to Segwit happened, which was what the Core developers were avoiding right from the beginning, the same as there were no chain splits in the soft forks of the past. Bitcoin remains intact.

It was Bitcoin Cash that forked away and became an altcoin.

[franky1]

franky1, I know that you made that argument to make yourself believe that Bitcoin "bilaterally split" into two so that you can call Bitcoin "Bitcoin Core" and Bitcon Cash "Bitcoin Cash".

But if we look at the history of ALL soft forks and hard forks of Bitcoin in the past, https://blog.bitmex.com/bitcoins-consensus-forks/

Do we then have the right to call Bitcoin "Bitcoin Something" post fork?

No because there was no chain split when the soft fork to Segwit happened, which was what the Core developers were avoiding right from the beginning, the same as there were no chain splits in the soft forks of the past. Bitcoin remains intact.

It was Bitcoin Cash that forked away and became an altcoin.

ha ha ha such a comedian
grabbing blog posts full of twisted buzzwords

how about read real data. like the blockchain itself
how about speak to the main devs. not the SPV wallet core fan wannabe's

bitcoin CORE, on august 1st  rejected any blocks that were not signaling for segwit.
basically bitcoin core rejected all legacy blocks.. thus bitcoin core did actually split AWAY from the past.
yep bitcoin core went in a different direction. and so did bitcoin cash.
hense it was a 2 way split. where both sides decided to go in separate directions compared to the past.
thats the very definition of a bilateral split.

and it was not a consensus upgrade because that would be where no split occured, everyone continues on the same network and no legacy blocks get rejected but new formats get accepted aswell as legacy blocks.
but a consensus event did not happen
 
core only had 35% vote under consensus.. so they gave up on waiting for consensus. and got their partners to organise the mandatory bilateral split.(again check the blockchain, check with the devs, both show it. (hint:blogs dont outrule real data))

yep.. and dont take the word of your propaganda pals. look at the data, its in the blockchain.. talk to the main devs (not the SPV wallet guys you have been hugging lately)

gmaxwell, pieter wuiile, luke Jr, etc all admit it was a bilateral split event on august first.
it was not a consensus event. so the propaganda blog you displayed is foolish nonsense of misrepresentation.

i think i have had my fill of laughs for the day,
its real funny that you been fooled into thinking that mandarorally demanding that nodes reject blocks  that would be valid under normal rules is a softfork.
windfury. if there ever was a bitcoin conference, and you become a public speaker. if you say what you have been saying recently, proper people that know whats really happened. that have been around alot longer then you. will ask who wrote your script and is your segment the comedy night part of the conference.

i think its time you go find other opinions and new script handouts away from the core defence league. because the core defense league is not the bitcoin decentralisation league. which is more reason to ensure people know about the bilateral split and how/why/when core gained controls of the network.. and why the community should name the network now empowered by core as bitcoin core.  
core should not own brand bitcoin.. no one should.

but i already know. as you admitted already you sheep follow core. so all arguments about
bitcoin decentralisation, vs core defense. you will always aid the core defense.

but dont reply until you have looked at the blockchain and done some proper research. because you are just slipping further and further away from understanding decentralisation. and definetly sounding like you are not desiring or defending decentralisation

have a nice day.

[DooMAD]

bitcoin CORE, on august 1st  rejected any blocks that were not signaling for segwit.
basically bitcoin core rejected all legacy blocks.. thus bitcoin core did actually split AWAY from the past.

"Waaaa!  Core did this!  Waaaa!  Core did that!"

NO.

Users and miners made a conscious decision to run code that rejected blocks that weren't signalling for SegWit, therefore it was the users and miners who made that happen.  It doesn't matter where the code came from, or who made it, because code is completely meaningless if no one runs it.  The network participants make the decisions, not the devs.  I don't know how many more times you need it hammered into that thick head of yours.  If the users didn't agree with the effects of that code, it wouldn't have happened.  Come back when you have the first clue what you're talking about.

[achow101]

bitcoin CORE, on august 1st  rejected any blocks that were not signaling for segwit.
basically bitcoin core rejected all legacy blocks.. thus bitcoin core did actually split AWAY from the past.

This is completely and absolutely false. Bitcoin Core at no point in time implemented BIP 148 or BIP 91 nor was there any release of Bitcoin Core which supported BIPs 148 or 91. All attempts to implement BIP 148 and BIP 91 into Bitcoin Core were never merged. There was no release of Bitcoin Core that contained any support for BIPs 148 or 91. All clients that did support it were software forks of Bitcoin Core and created by primarily (i.e. mostly) by individuals unrelated to Bitcoin Core (as in they have not contributed to Bitcoin Core before). While some Bitcoin Core developers did partake in the alternative implementations for BIPs 148 and 91, this does not mean that Bitcoin Core supported it nor does it mean that Bitcoin Core rejected non-segwit signalling blocks on August 1st as Bitcoin Core itself did not have code for that.