Post your SegWit questions here - open discussion - big week for Bitcoin!

[Lauda]

- A two (or is it four with a soft Cap of two) megabyte blocksize

The actual 'weight' limit is 4 MB. In other words, if Segwit is activated we will see blocks between 0 and 4 MB. However, it is expect that the 'maximum' block size will be around 2.1 MB (due to the current transaction type usage). If more people use n-of-m addresses, then the block size will likely be higher. Keep in mind that a higher block size does not necessarily imply more transactions.

- Smaller transaction size by removing a large part of the transaction (I'm not sure what this is)

Actually the transactions are slightly larger IIRC. However, what you're referring to is the witness segregation.
This isn't really a thread to get familiar with Segwit. There are 'more simplistic' explanations elsewhere IMO.

[1715077132]

1715077132

[1715077132]

1715077132

[1715077132]

1715077132

[1715077132]

1715077132

[JeffBrad12]

Just a simple question from me,
1. If I won't upgrade into the supporting SegWit and Will it give any impact for me to sending or receiving such amount from the Supporting SegWit?  

2. Why SegWit is complex rather than a simple hardfork.

3. Are the implementing of SegWit will need blocksize hardfork?

[achow101]

Just a simple question from me,
1. If I won't upgrade into the supporting SegWit and Will it give any impact for me to sending or receiving such amount from the Supporting SegWit?  

Not upgrading to a segwit enabled wallet will not affect sending or receiving Bitcoin as you do now. The backwards compatibility of segwit means that you will be able to receive from someone with segwit (albeit after the transaction has confirmed a few times) and send to someone who wants to use segwit.

2. Why SegWit is complex rather than a simple hardfork.

Hard forks are far from simple. Segwit also solves a lot of problems simultaneously, not just capacity. A "simple" block size increase hard fork ignores a lot of the nuance that comes from making such a change

3. Are the implementing of SegWit will need blocksize hardfork?

Segwit does not need a block size increase hard fork.

[JeffBrad12]

Just a simple question from me,
1. If I won't upgrade into the supporting SegWit and Will it give any impact for me to sending or receiving such amount from the Supporting SegWit?  

Not upgrading to a segwit enabled wallet will not affect sending or receiving Bitcoin as you do now. The backwards compatibility of segwit means that you will be able to receive from someone with segwit (albeit after the transaction has confirmed a few times) and send to someone who wants to use segwit.

2. Why SegWit is complex rather than a simple hardfork.

Hard forks are far from simple. Segwit also solves a lot of problems simultaneously, not just capacity. A "simple" block size increase hard fork ignores a lot of the nuance that comes from making such a change

3. Are the implementing of SegWit will need blocksize hardfork?

Segwit does not need a block size increase hard fork.

Thanks achow for your answer,
The others were saying if Lightning Network was possible without SegWit and it is true? or SegWit was becoming a responsibility for Lightning Network.


Why bitcoin core has opted the complex softfork  rather than be implemented into hardfork with more simply and cleaner.

[HomoHenning]

adoption takes time, why? when we can expect >90%?

[achow101]

Thanks achow for your answer,
The others were saying if Lightning Network was possible without SegWit and it is true? or SegWit was becoming a responsibility for Lightning Network.

Lightning is certainly possible without segwit, it is just a lot harder to implement and more complex. Segwit makes lightning easier to implement and less susceptible to failure.

Why bitcoin core has opted the complex softfork  rather than be implemented into hardfork with more simply and cleaner.

As I said earlier, hard forks are neither simple nor clean. Even implementing segwit as a hard fork would not be simple nor cleaner. Either you break every single unconfirmed transaction, or you go through the pain of a hard fork for basically no reason as the things that would require hard forking can and are already done in a way to allow soft forks.

adoption takes time, why?

Because people are testing the software and upgrading custom software. Also a lot of pools seem to not support segwit for some reason.

when we can expect >90%?

We can't predict the future, no one knows.

[JayJuanGee]

Thanks achow for your answer,
The others were saying if Lightning Network was possible without SegWit and it is true? or SegWit was becoming a responsibility for Lightning Network.

Lightning is certainly possible without segwit, it is just a lot harder to implement and more complex. Segwit makes lightning easier to implement and less susceptible to failure.

Why bitcoin core has opted the complex softfork  rather than be implemented into hardfork with more simply and cleaner.

As I said earlier, hard forks are neither simple nor clean. Even implementing segwit as a hard fork would not be simple nor cleaner. Either you break every single unconfirmed transaction, or you go through the pain of a hard fork for basically no reason as the things that would require hard forking can and are already done in a way to allow soft forks.

adoption takes time, why?

Because people are testing the software and upgrading custom software. Also a lot of pools seem to not support segwit for some reason.

when we can expect >90%?

We can't predict the future, no one knows.

Achow101...

Great that you have a lot of patience answering apparent trolls.


Yeah, at first, maybe we can give them some benefit of the doubt, but when they keep insisting on the bigblocker talking points while claiming to not understand technicalities while at the same time suggesting that seg wit is "too complex" and suggesting that a hard fork is preferable to a soft fork... blah blah blah, we certainly can get the sense that they are disingenuous, just bringing over some big blocker nut job talking points.. and likely trolling.

[classicsucks]

suggesting that seg wit is "too complex" and suggesting that a hard fork is preferable to a soft fork... blah blah blah, we certainly can get the sense that they are disingenuous, just bringing over some big blocker nut job talking points.. and likely trolling.

I feel like I understand the technical details fairly well, and I'm confident that Segwit has been the largest change to the Bitcoin codebase in the past few years, both in terms of number of lines of code and the depth to which it reaches. Also it requires changes to the code in all wallets and utilities. Changes that are nowhere near complete, as people are waiting to see if Segwit is adopted. I'm not a "big-blocker" at all, I've been a vocal opponent of Classic, XT, Unlimited, etc.

I believe it's time to speak honestly about Segwit, which I do not support, for different reasons. No troll. Flame away. Kano is a legit developer of mining software who has also raised valid concerns about the code.

[Carlton Banks]

I believe it's time to speak honestly about Segwit, which I do not support, for different reasons. No troll. Flame away. Kano is a legit developer of mining software who has also raised valid concerns about the code.

Kano raised invalid concerns, just like the rest of your concerns, not valid.


It seems like a huge number of people are saying: "I don't understand the point of fixing signature malleability, or why quadratic sighash scaling is an issue, so, why?"

This is incredibly arrogant, and ignorant. And I don't normally listen to anything that people say who are too arrogant to fix their own ignorance. Do you?

[Manfred Macx]

I have started studying SegWit more closely and I have several questions. One of the things it does is that it fixes malleability. The point of malleability is that a tx hash can change before it is commited to the block without changing the result of the transaction. The abandoned BIP62 list all(?) of the ways in which a transaction can be malleated. My first question is, would it be enough to just change the hashing algorithm (BIP143) to fix this instead of introducing the witness field?

Superfluous scriptSig operations Adding extra data pushes at the start of scripts, which are not consumed by the corresponding scriptPubKey, is also a source of malleability.

Can this happen in P2WSH? If witness looks like

Code:

1 0 <sig1> <witnessScript>

That 1 is superflous and I think it is the malleability form described by the quote above. Or is this case covered by BIP141#Wintess Program "The script must not fail, and result in exactly a single TRUE on the stack."?

Sighash flags based masking Sighash flags can be used to ignore certain parts of a script when signing.

Is this covered by the new hashing algorithm described in BIP143?

[amaclin]

Can this happen in P2WSH? If witness looks like

Changing witness data without invalidating transaction does not change txid

[Manfred Macx]

Changing witness data without invalidating transaction does not change txid

Ah, right. I forgot about that.

[achow101]

My first question is, would it be enough to just change the hashing algorithm (BIP143) to fix this instead of introducing the witness field?

First of all, the new hashing algorithm is for sighashing, so it has no effect on malleability. That new hashing algorithm is to fix quadratic sighashing.

It is possible to fix malleability be redefining txid hashing to ignore everything in the scriptsig. However this would be a hard fork and break every single unconfirmed transaction at the time of said fork.

[Manfred Macx]

First of all, the new hashing algorithm is for sighashing, so it has no effect on malleability. That new hashing algorithm is to fix quadratic sighashing.

It is possible to fix malleability be redefining txid hashing to ignore everything in the scriptsig. However this would be a hard fork and break every single unconfirmed transaction at the time of said fork.

Thank you. I figured out later that my question makes no sense

[Manfred Macx]

Is BIP142, new segwit address format, abandoned? Also, are CLTV and CSV treated as P2WS now?

[achow101]

Is BIP142, new segwit address format, abandoned?

It has been deferred, meaning that it is abandoned for now but likely that it will be picked up again later.

Also, are CLTV and CSV treated as P2WS now?

CLTV and CSV are OP codes. They are part of scripts, so they can be used in any p2sh address. Anything that was p2sh can become p2wsh.

[Fatman3001]

I believe it's time to speak honestly about Segwit, which I do not support, for different reasons. No troll. Flame away. Kano is a legit developer of mining software who has also raised valid concerns about the code.

Kano raised invalid concerns, just like the rest of your concerns, not valid.


It seems like a huge number of people are saying: "I don't understand the point of fixing signature malleability, or why quadratic sighash scaling is an issue, so, why?"

This is incredibly arrogant, and ignorant. And I don't normally listen to anything that people say who are too arrogant to fix their own ignorance. Do you?

Damn.... You do realize this is a q&a thread? Maybe it's a good idea to retract those claws so people can ask some "stupid questions". Adoption isn't exactly going swimmingly.

[TransaDox]

I believe it's time to speak honestly about Segwit, which I do not support, for different reasons. No troll. Flame away. Kano is a legit developer of mining software who has also raised valid concerns about the code.

Kano raised invalid concerns, just like the rest of your concerns, not valid.


It seems like a huge number of people are saying: "I don't understand the point of fixing signature malleability, or why quadratic sighash scaling is an issue, so, why?"

This is incredibly arrogant, and ignorant. And I don't normally listen to anything that people say who are too arrogant to fix their own ignorance. Do you?

This post is the epitome of arrogance and the irony is spectacular. Maybe achow101 should take you aside and teach you how to play nice with us remedial kids.

Kano raised concerns. You can allay or confirm those concerns or just not answer. I would prefer the former but would be just as happy with the latter.

[Carlton Banks]

Any actual questions, do step right up

[Manfred Macx]

I'm reading BIP143 about new transaction digest algorithm. In Specification item 5 is scriptCode of the input and for P2WPKH it says 'For P2WPKH witness program, the scriptCode is 0x1976a914{20-byte-pubkey-hash}88ac'. For a script to be P2WPKH it has to have output '0 {20-byte-hash}'. Am I to understand that this new digest algorithm takes this 20-byte-hash and wraps it into script code before hashing?