Why Bitcoin needs Segregated Witness

[^BuTcH^]

Why does Bitcoin need Segregated Witness

Just read this article and finally it became clear to me why BTC needs Segregated Witness. Recommended to everyone https://medium.com/@corp_92607/why-bitcoin-needs-segregated-witness-5b664e2ec6ec

Is everything correct in the article or you have something to add?

[1714060361]

1714060361

[1714060361]

1714060361

[1714060361]

1714060361

[1714060361]

1714060361

[1714060361]

1714060361

[1714060361]

1714060361

[franky1]

firstly
segwit has not fixed malleability.
it created a new TX format that people can use to (at the time) show they cannot perform malleability.
a. people could continue to use old legacy tx formats and still malleate
b. recently due to new feature needs. core devs introduced a new sighash opcode that actually allows segwit tx's to malleate again..

secondly
the wishy washy code of witness scale factor. does not actually give more transaction capacity per real hard drive storage bytes of full block data.
stripped blocks do not contain signature data to validate a tx is truly authentic. thus having a node storing stripped data is not a guarantee to hold valid data or a ability to relay full data to real full nodes. thus no point being a node messing with stripped data

thirdly
the purpose of segwit is actually to change bitcoin to have a new gateway tx format that would allow features to be done that would suit another network (LN)

fourthly
segwit was conceived to edit bitcoin to give bitcoin a doorway to an alternative network.
the other network was not edited to be purely bitcoin functional
the esssence is to eventually persuade users to de-burden themselves of using the bitcoin network and use another network. thus reduce bitcoin networks utility

[magnumwallet]

firstly
segwit has not fixed malleability.
it created a new TX format that people can use to (at the time) show they cannot perform malleability.
a. people could continue to use old legacy tx formats and still malleate
b. recently due to new feature needs. core devs introduced a new sighash opcode that actually allows segwit tx's to malleate again..

secondly
the wishy washy code of witness scale factor. does not actually give more transaction capacity per real hard drive storage bytes of full block data.
stripped blocks do not contain signature data to validate a tx is truly authentic. thus having a node storing stripped data is not a guarantee to hold valid data or a ability to relay full data to real full nodes. thus no point being a node messing with stripped data

thirdly
the purpose of segwit is actually to change bitcoin to have a new gateway tx format that would allow features to be done that would suit another network (LN)

fourthly
segwit was conceived to edit bitcoin to give bitcoin a doorway to an alternative network.
the other network was not edited to be purely bitcoin functional
the esssence is to eventually persuade users to de-burden themselves of using the bitcoin network and use another network. thus reduce bitcoin networks utility

Thanks for your message, here what we think:

1) SegWit by itself is a fix, albeit a nonobligatory one, and that is its main feature.
Please tell us which opcode you are referring to. If what you are stating is indeed true we can include that in the article, because such information is hard to come by.

2) It was mentioned in the article that the signature data is still stored on the blockchain. The issue you're referring to is indeed relevant, but nodes that do not have access to the signature data can simply "wait it out" until enough confirmations are acquired.

3) The number 1 purpose of SegWit (stated in the full text of BIP 141) is to ensure that "Nonintentional malleability becomes impossible".

4) Again, none of this contradicts the article, except for the last sentence. The network's utility is actually enhanced by these alternative networks as Bitcoin (in its current form) has become too expensive and overcrowded for the majority of its daily users.

[dothebeats]

The network's utility is actually enhanced by these alternative networks as Bitcoin (in its current form) has become too expensive and overcrowded for the majority of its daily users.

I like SegWit's idea of trying to relieve/alleviate the stress on the nodes and cramming more transactions in a block compared to the previous LBTC code, but do we really have to resort to another network in order to solve the scaling problem that we've been bothered since early 2014? For what purpose does the main chain of bitcoin serve if we are just going to load most transactions at the LN? I don't think bitcoin getting 'too expensive' is a problem in bettering the code for the way it handles data. It should 'scale' if we want it to compete against other payment processors (Paypal, Visa, etc.) without relying on a third-party service that also asks for fees in exchange of using their platform.

[franky1]

I like SegWit's idea of trying to relieve/alleviate the stress on the nodes and cramming more transactions in a block compared to the previous LBTC code,

it doesnt cram more transactions in. .
back in 2010 there was some math done and it was shown that bitcoins 1mb can fit 600k tx a day
9 years later and that benchmark has still not ben surpassed
also the wishy washy code of MISCOUNTING data does not make more transactions, it just fools a software rule into doing something. but at the hard drive storage of a full block of transaction data. the bytes per transaction of a segwit tx vs a legacy tx actually show a segwit tx uses slightly more bytes per tx

[magnumwallet]

9 years later and that benchmark has still not ben surpassed

While what you are saying is true, you have to admit that there are very few backward compatible solutions that Bitcoin could implement.
Of course, the network could (and probably should) reinvent itself entirely, as efficiency is clearly not its biggest strength. But it won't, because Bitcoin's popularity also gave it great inertia, and all changes have to both satisfy all parties AND can't allow the network to fork into pieces.

[franky1]

9 years later and that benchmark has still not ben surpassed

While what you are saying is true, you have to admit that there are very few backward compatible solutions that Bitcoin could implement.
Of course, the network could (and probably should) reinvent itself entirely, as efficiency is clearly not its biggest strength. But it won't, because Bitcoin's popularity also gave it great inertia, and all changes have to both satisfy all parties AND can't allow the network to fork into pieces.

the thing is. the network DID controversially fork

there was a controversial hard fork in summer 2017, to get rid of opposition. to then fake approval for segwit to activate after the controversy

if devs were smart they would have used the controversial date to include extra features that could only be included using a controversial fork

the whole 'compatibility' ruse was not about network security but as a ploy to try and get segwit activated without having to reach the ultimate consensus %

..
but anyway. here is some funny facts
1. Sipa (pieter wuille) the innovator/dev of segwit still to this day does not trust his bitcoin donations on segwit bech32 addresses
http://bitcoin.sipa.be/  - bottom right of page -  1NrohbDoPkARCGdjvtnXbwFLwoBH86pskX

2. BTCC, the biggest bitcoin mining pool that sponsored advocated and promoted sgwit as being the best thing ever, did not trust bitcoin blockrewards to be put on segwit bech32 addresses
13TEThZNnKPk34HYAuo1QqYMwDdjF3qeHx
even its last block (543,040) used legacy

[bitmover]

Segwit somehow solves blocksize problems, by reducing transaction size. So more transactions can go in a block with the same size.

Additionally it also adds new features which will allow lightning network.

[BrewMaster]

Segwit somehow solves blocksize problems, by reducing transaction size. So more transactions can go in a block with the same size.

Additionally it also adds new features which will allow lightning network.

OP is not asking a question here that you are answering it! OP is just sharing a link here.
and you are wrong, SegWit does not reduce transaction size, it instead increases capacity by moving the signatures (witnesses) elsewhere inside transactions that way the legacy nodes still see the 1 MB cap while we have more transactions in new versions with witness.

[bitmover]

Segwit somehow solves blocksize problems, by reducing transaction size. So more transactions can go in a block with the same size.

Additionally it also adds new features which will allow lightning network.

OP is not asking a question here that you are answering it! OP is just sharing a link here.
and you are wrong, SegWit does not reduce transaction size, it instead increases capacity by moving the signatures (witnesses) elsewhere inside transactions that way the legacy nodes still see the 1 MB cap while we have more transactions in new versions with witness.

Ok thank k you for your correction about segwit. You are right, it does not reduce transaction size, just made a small research about it now.

[Wind_FURY]

firstly
segwit has not fixed malleability.
it created a new TX format that people can use to (at the time) show they cannot perform malleability.
a. people could continue to use old legacy tx formats and still malleate

But those are not Segwit transactions.

b. recently due to new feature needs. core devs introduced a new sighash opcode that actually allows segwit tx's to malleate again..

Can you post some links proving that? That's going to be a big issue if it's really true. Plus, if it's true, how did the Core developers react when it was "discovered"?

[Pursuer]

b. recently due to new feature needs. core devs introduced a new sighash opcode that actually allows segwit tx's to malleate again..

Can you post some links proving that? That's going to be a big issue if it's really true. Plus, if it's true, how did the Core developers react when it was "discovered"?

there has been no change to the sighash type flags for a very long time. there still are the same 4 of them as always. by the way sighash types are not "op codes" they are more like flags.
https://github.com/bitcoin/bitcoin/blob/78dae8caccd82cfbfd76557f1fb7d7557c7b5edb/src/script/interpreter.h#L21-L28

[Wind_FURY]

b. recently due to new feature needs. core devs introduced a new sighash opcode that actually allows segwit tx's to malleate again..

Can you post some links proving that? That's going to be a big issue if it's really true. Plus, if it's true, how did the Core developers react when it was "discovered"?

there has been no change to the sighash type flags for a very long time. there still are the same 4 of them as always. by the way sighash types are not "op codes" they are more like flags.
https://github.com/bitcoin/bitcoin/blob/78dae8caccd82cfbfd76557f1fb7d7557c7b5edb/src/script/interpreter.h#L21-L28

Then is that another example of franky1 lying, and making up his own facts again, because I don't know what's going on. Please explain it to a stupid person like me.

[Kakmakr]

In spite of all the negativity of SegWit in this thread, I can say that SegWit certainly reduced the Spam attacks on the network. It became very expensive to launch a prolonged spam attack on a SegWit network, so more and more attackers decided not to launch these attacks on the Bitcoin network, after this was introduced.

Bitcoin without SegWit was an easy target and one of the reasons why congestion and scaling was a problem during the Bitcoin fork periods. 

[jseverson]

It became very expensive to launch a prolonged spam attack on a SegWit network, so more and more attackers decided not to launch these attacks on the Bitcoin network, after this was introduced.

I'm not so sure about this. Things are certainly better scaling-wise, but Segwit only really helps on legitimate traffic (and not all of these are Segwit transactions). Bad actors don't need to use it, so they can fill up blocks with regular transactions nearly as easily as they did in the past. Additionally, hostile miners could choose not to mine Segwit transactions to compound the issue.

[pooya87]

In spite of all the negativity of SegWit in this thread, I can say that SegWit certainly reduced the Spam attacks on the network. It became very expensive to launch a prolonged spam attack on a SegWit network, so more and more attackers decided not to launch these attacks on the Bitcoin network, after this was introduced.

Bitcoin without SegWit was an easy target and one of the reasons why congestion and scaling was a problem during the Bitcoin fork periods. 

the misunderstanding of SegWit has always been the biggest problem that bitcoin faced during this fork!
SegWit did not stop the spam attacks and did not change the cost of such attacks. if the attackers wanted or were capable of continuing their attack they could have done it. and i assure you that in the future we will see more spam attacks against bitcoin because by design bitcoin is vulnerable to spam attacks and will always be.

[Wind_FURY]

It became very expensive to launch a prolonged spam attack on a SegWit network, so more and more attackers decided not to launch these attacks on the Bitcoin network, after this was introduced.

I'm not so sure about this. Things are certainly better scaling-wise, but Segwit only really helps on legitimate traffic (and not all of these are Segwit transactions). Bad actors don't need to use it, so they can fill up blocks with regular transactions nearly as easily as they did in the past. Additionally, hostile miners could choose not to mine Segwit transactions to compound the issue.

But I'm confident that the "leader" of the "hostile miners", the Jihan Wu ruled-Bitmain is gone, and will not be attacking Bitcoin again.

He has bigger problems. Hahaha.

https://bitcointalk.org/index.php?topic=5023556.msg50332997#msg50332997

He's hiding in Singapore.

[franky1]

talking about spam
it was actually the core crowd that instigated the spam. as their way of making people think silly half promises core were offering were needed.

i get astonishingly shocked that people actually follow reddit scripts more than basic logic/common sense thoughts

first of all it was proven that mixers rampd up their tx spamming. and yep certain core devs are involved with certain mixers
also pools related to bitmain. were not filling blocks with loads of 1confirm utxo respends. thus it was not bitmain spamming.
also the timing of spam attacks were (not coincidentally) obvious, just by looking at stats to me timed right when cor wanted a bip activated. where opposition would not actually gain anything by spamming at those times

but i guess reddit propaganda vs logic= reddit wins

so here is some basic logic.
reddit propaganda want to suggest anti-cor pools want to ramp up the tx fee.. because they are greedy and risk of going bankrupt

yet
1. anti-core pools happy make blocks and not care about tx fee's (empty blocks)
as oppose to
2. btcc which was very pro core, pro segwit.
3  btcc shown prefrnce to include tx's of its users that also used their other services like gambing(spaming) and partnenrs mixing
4. btcc pools shown to love adding higher than average fee's to thier collate tx lists in a block
5. btcc even got IPO'd by DCG..... are now dead and bankrupt.. which is why you will see all the twitter and rddit scripts sourcing samson mow
funny part is samson mow is butt hurt that he lost his BTCC job but is blaming others

[squatter]

first of all it was proven that mixers rampd up their tx spamming. and yep certain core devs are involved with certain mixers

Which mixers? Do you have a source for either claim? I can't find anything about either one.

also pools related to bitmain. were not filling blocks with loads of 1confirm utxo respends. thus it was not bitmain spamming.
also the timing of spam attacks were (not coincidentally) obvious, just by looking at stats to me timed right when cor wanted a bip activated. where opposition would not actually gain anything by spamming at those times

but i guess reddit propaganda vs logic= reddit wins

So we should revise history to incorporate your propaganda? You don't have evidence for anything you're saying.

1. anti-core pools happy make blocks and not care about tx fee's (empty blocks)
as oppose to
2. btcc which was very pro core, pro segwit.
3  btcc shown prefrnce to include tx's of its users that also used their other services like gambing(spaming) and partnenrs mixing
4. btcc pools shown to love adding higher than average fee's to thier collate tx lists in a block
5. btcc even got IPO'd by DCG..... are now dead and bankrupt.. which is why you will see all the twitter and rddit scripts sourcing samson mow
funny part is samson mow is butt hurt that he lost his BTCC job but is blaming others

What is this supposed to prove?

[franky1]

Which mixers? Do you have a source for either claim? I can't find anything about either one.

So we should revise history to incorporate your propaganda? You don't have evidence for anything you're saying.

revise history?
here is the most incredible lesson you may learn about bitcoin.
when it comes to bitcoin tx information. you dont learn things from reddit. you actually learn things from the blockchain. yep the immutable blockchain that history cannot be tampered with.

so if you want to use logic rather than reddit. try looking at blockchain data.

as for the whats talking about BTCC suppose to prove.
some funny facts
1. btcc was the mining pool that done alot of fee war drama and spammy crap (hostile)
2. btcc was the pools that was over promising over promoting segwit. but after activation BTCC didnt trust segwit for its own coin rewards
3. btcc was the company that couldnt pay its bills and ended up getting bought out, and dissolved
4. the employee's of btcc pretend things like bitmain are hostile. yet its the btcc ex employees that do alot of social drama propaganda

you might want to do some research. oh and you will find more evidence of btcc's demise, lack of trust of segwit and also the spam fee war stuff by checking immutable blockchain data... not reddit/twitter

but if you would rather trust reddit/twitter drama more than blockchain statistics.. thats your choice