Segregated Witness Sotf fork (Segwit) Pros and Cons

[adamstgbit]

Segwit Pros and Cons

​

Pros
________________________________________________________

Effective block size increase
this increase would be about 1.6 MB to 2.0 MB.
as far as relay speeds and network load is considered segwit blocks or 2MB traditional blocks, would cost the same.

Segwit is a softfork
- it hardly qualifies as a soft fork; users & wallets that do not implement segwit and receive funds from a segwit TX will end up with TX they cannot validate.
they should be able to spend the funds even if they dont
upgrade they simply see the TX as anyone-can-spend, when infact noly they can spend...
- Segwit allows a softfork by requiring a significant wast of space in the wtxid, it should be implmented as a hardfork.
its only 1kb wasted, softforks are favorable.
- calling segwit a softfork might lead people to believe they do not need to upgrade, confidence in the dev team will drop as these users figure out that it was indeed a mandatory upgrade.
-SegWit is technically superior as a hard fork. Witness proofs would be about 50% or 1,000 Bytes larger, and code would be more complex, as a soft fork.


Fixes third-party transaction malleability allowing LN and sidechains to be developed .
Possible 66% additional improvement in bi-directional channel efficiency by consolidating channel open and close operations.

Allows the ability to more easily upgrade Bitcoin’s Script language.


Includes fraud proofs.
enables sidechain type contracts.
it does not currently include fraud proof validations and it won't include it even in the first deployment.

Cons
________________________________________________________

The implementation of segwit is complex and multifaceted
- all the different wallets will need to implement segwit themselves, its unlikely they will all get it right the first time, could lead to some serious loses.

Bitcoin is fairly simply to explain, poeple can trust it because they understand it, segwit makes understanding bitcoin an order of magnitude more complex, which could lead to poeple not trusting bitcoin.


Upon adoption, segwit creates a 4X adversarial attack surface.
miners and network engineers have to design their systems to be able to handle 4 MB blocks without bogging down, but we only get to actually use about 40% of that capacity. This 4x adversarial case will make it very difficult to increase the blocksize limit in the future. With a 1 MB base block size, it's 4 MB, but with a 2 MB base block size, the adversarial case would be 8 MB.


Makes use of an existing feature (anyonecanspend) that was never meant to be used this way.

Introduces a new type of DOS attack (go-fish-wit-ddos)
An attacker mines a segwit-block with 1000 transactions the network has not yet seen (The attacker creates these TX herself )The attacker has the witness data readily available. When other miners try to validate this block they will go through every single one of these TX and say "I don't have the witness data for this TX_ID, I have to call TCP::GetWitnessData( TX_ID ) aw yes this is valid"


Subsidizes signature data in complex/large multisig transactions.
Weights signature data at 1/4 the level of transaction/UTXO data. Signatures are more expensive to validate than UTXO, so this is not justifiable in terms of computational cost.

Increased resource usage (capacity, bandwidth, processing power)


***
Black Text Is a Pro or Con related to segwit .
Green Text Is used to highlight key points which give the Pro or Con more validity
Red Text Is used to highlight key points which debunk or lessen the validity of the Pro or Con



We are compiling a list of some basic pros and cons for segwit softfork. please post below some Pros or Cons for segwit, and discuss them. Feel free to try and debunk the pros / cons i will try and follow the discussion and summarize / post links to these posts with more information. Free feel to ask me to reword a Pro or Con listed in OP for added clarity, please provide full text as you believe it should appear.

In a few month Core will be looking push segwit out onto the network, Its is my hope that this Pro & Con List will help users and miners understand all the specific issues related to segwit. so they can be confident about their decision to accept it or not.

Thank you for your input!

 

[adamstgbit]

Segwit is infinitely more complex than the 2MB block limit increase, trying to figure out all its pros and cons isn't going to be easy....

con: The implementation of segwit is complex and multifaceted
all the different wallets will need to implement segwit themselves, its unlikely they will all get it right the first time, could lead to some serious loses.
[doublepost=1458093617][/doublepost]

these 2 posts by satoshis_sockpuppet contain some more negative points:

• https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-429#post-14871
• https://bitco.in/forum/threads/gold-collapsing-bitcoin-up.16/page-432#post-15048

my personal points:

• not necessary
• not scaling solution or blocksize increase
• benefits (fraud proof, malleability) can be done separtely (without the package)
• high risk
• high wallet dev workload
• complex
• cannot be undone
• sneaky "soft-fork" is sneaky and not necessary
• hackish misuse of scripting language semantics

this is all meat and no potatoes. if you could expand on these points a little that would help me

if not i'm going to attempt to fill in the blanks myself...

 

[jl777]

SEGWIT WASTES BLOCKCHAIN SPACE

https://bitcointalk.org/index.php?topic=1398994.msg14211197#msg14211197

It will force all nodes to update, as if they dont they cant validate or spend any segwit tx they get.

which means the space used up by wtxid 30%+ is a TOTAL AND PERMANENT WASTE of space

 

[adamstgbit]

so mmm

Pro: segwit is a soft fork
it hardly qualifies as a soft fork; users & wallets that do not implement segwit and receive funds from a segwit TX will end up with unspendable funds. In a way it forces everyone to upgrade or there "backward compatible node" will be completely unusable shortly after segwit is released.
[doublepost=1458095213,1458094554][/doublepost]HODL that thought, notice how the title misspelt soft fork as sotf fork. HA!

sotf fork def. ::
a soft fork which when activated will force all older nodes to upgrade or quickly become utterly useless

here is a graphical example of a sotf fork:

 

[jl777]

the official party line is "wallets still function perfectly fine with the old system. They can still receive segwit transactions, they just can't spend from them"

so its fine, not being able to spend from them is functioning perfectly fine. After all who ever actually needs to spend the bitcoins they get

 

[solex]

A big con for me is the complete lack of transparency with the community. Wuille makes his HK presentation pitching SW as equivalent to a 4MB block size, putting smoke over the post-conference disucssions on scaling. Then he disappears into his concrete bunker leaving sycophants and shills to argue the SW case. Any facts and deeper info needs to be distilled from analysis done by people like AJ Towns.

Bitcoin is digital cash. Everyone can understand it. If it is changing so that only blockchain gurus can understand it, then who can trust it?

 

[jl777]

https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki

its a simple set of a dozen changes that requires a completely new overlay protocol and doesnt even solve the blocksize issue as anybody that wants to spend the segwit payments would need to download the full larger block and those are bloated with wtxid that otherwise wouldnt be needed in a simple 2MB hardfork

 

[adamstgbit]

@jl777 you lost me

define "completely new overlay protocol "
this is quite confusing... maybe it will make more sense to me tomorrow...

 

[jl777]

well for everybody that has written their own bitcoin core from scratch, it is pretty simple stuff. I was worried it required some zeroknowledge math, but it is just segregating data from one place to another.

by the way, I already segregate all the signature and vin data in a separate directory, so after it is validated, it can be deleted. this is fine for all but full relaying nodes.

I guess for the few people on earth who havent written a bitcoin core from scratch, it probably wont be so simple, but really, what type of small percentage of the population is that anyway

 

[Lee Adams]

It looks a bit one sided for now. Some of these Pros are devil's advocate, but still need to be included and discussed.

Pros:
It fixes third-party transaction malleability.
It allows the ability to more easily upgrade Bitcoin’s Script language.
Possible 66% additional improvement in bi-directional channel efficiency by consolidating channel open and close operations.
It includes fraud proofs.
The above points will also enables sidechain type contracts.
It is supported by developers who (according to GitHub) generated more than 90% of all commits to Bitcoin Core in 2015.

Cons:
Allowing more complex script language could open up attack vectors.
[doublepost=1458122827,1458121864][/doublepost]2 more from the core FAQ. Again pretty weak and contradictory ones IMHO, but should be discussed.

Pros:
A modest reduction in fees.
Allows miners to put more transactions in their blocks, which may allow them to increase their per-block revenue.

 

[Lee Adams]

Con:
It makes use of an existing feature (anyonecanspend) that was never meant to be used this way. This creates more technical debt.

 

[Chronos]

@jl777 I've been hearing that not upgrading will not leave your wallet at risk to receive unspendable coins, because it would never generate a "segwit payment address" without updating. So, nobody receives coins that they themselves cannot spend. Any thoughts on that?

 

[jl777]

you can receive from segwit nodes, you just have to trust it is valid since you cant verify it. Even if you run a full relay node. It is reduced to SPV security. If that is ok, then maybe it is fine.

Oh, except I have not received the answer about what happens to this unverifiable tx when you spend it to another non-segwit node. Presumably that node also needs to trust that it is valid. Or maybe double spends are possible. But why is that any concern? We need to get the bitcoin peoples use to trusting tx that the official segwit nodes say are valid.

Isnt that what is most important?
centralized control over all the bitcoin tx. How else can KYC be introduced

 

[molecular]

well for everybody that has written their own bitcoin core from scratch, it is pretty simple stuff. I was worried it required some zeroknowledge math, but it is just segregating data from one place to another.

I have a question about the malleability fix: As I understand this is fixed by segwit because the signatures (witnesses) are not part of the transaction data structure any more, (but separated from it), right? So what keeps us from fixing malleability separately by simply ignoring the signatures when calculating txid?

 

[adamstgbit]

theoretically, couldn't i fool a non-segwit full node to believe I sent it BTC??

i simply send it a segwit TX with invalid signature, it can't validate the fact that the signature is invalid, because it sees the TX as a anyone can spend TX.

 

[molecular]

@jl777 I've been hearing that not upgrading will not leave your wallet at risk to receive unspendable coins, because it would never generate a "segwit payment address" without updating. So, nobody receives coins that they themselves cannot spend. Any thoughts on that?

This sounds at least plausible to me. There should be such a thing as a "segwit address" which should look different than p2sh or p2pkh.

 

[adamstgbit]

I have a question about the malleability fix: As I understand this is fixed by segwit because the signatures (witnesses) are not part of the transaction data structure any more, (but separated from it), right? So what keeps us from fixing malleability separately by simply ignoring the signatures when calculating txid?

I do believe you are right,
txid will be calculated without considering the signature
weather or not the TX is included in a block with or without that signature is inconsequential to malleability.
[doublepost=1458147490][/doublepost]question...

if this is indeed a sotffork wouldn't a minner be allowed to continue to make blocks which calculate TX_ID the old way ( with the sig )?

i mean once segwit sotffork is activated, can the old fork produce valid blocks or not?

 

[molecular]

theoretically, couldn't i fool a non-segwit full node to believe I sent it BTC??

i simply send it a segwit TX with invalid signature, it can't validate the fact that the signature is invalid, because it sees the TX as a anyone can spend TX.

I don't think so. I'm not sure about this, though and should probably shut up. But I'm guessing: Segwit outputs go to ANYONECANSPEND? So the wallet wouldn't even recognize the output(s) as belonging to any of its keys.

another view: if you're sendig to the wallet you have to output to the hash of one of its pubkeys. Once you do that, though: the wallet can spend those funds by definition.
[doublepost=1458147746][/doublepost]Why are we even talking about the possible cons of segwit?

Who needs this and what are the pros?

Why would we want it?

The whole things seems like a huge resource hog (I mean community / dev / ...)

 

[adamstgbit]

Core will soon attempt to enforce segwit ( 1 or 2 months ), we have no choice but to talk about it.

 

[Chronos]

Some pros are outlined here: https://bitcoincore.org/en/2016/01/26/segwit-benefits/#block-capacitysize-increase

Would be interested to hear expert opinion on which of these would be lost if we used a simpler solution to malleability.