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 
Topic: On Segwit not being backwards compatible question - page 3. (Read 1213 times)
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.
There is also this little fun drama I want to ask about. I believe "they" means Barry Silbert and his friends.
Is this bullshit? Then what really happened?
I left his name out on purpose. I want an unbiased technical approach to answer this.
Quote
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.
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.
Quote
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
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?
Jump to: