Why include witness data in Segwit transactions?

[zylstra]

My understanding is that Segwit transactions that are included in legacy BTC blocks do not contain witness data.  Why then include witness data in Segwit transactions that are included in Segwit blocks?  It seems like we get 2x transaction throughput for 4x block size, or maybe 2x block size on average.  So why even bother with Segwit?

[1714865885]

1714865885

[1714865885]

1714865885

[1714865885]

1714865885

[1714865885]

1714865885

[1714865885]

1714865885

[Xynerise]

My understanding is that Segwit transactions that are included in legacy BTC blocks do not contain witness data.

When segwit transactions are related to legacy nodes, the witness data is stripped so they can be valid under the consensus rules that legacy nodes follow(i.e 1 million bytes block size limit) That was how Segwit was deployed as a soft fork.

 

Why then include witness data in Segwit transactions that are included in Segwit blocks?

The so-called "witness data" is essentially the scriptSig(signature, pubkey, etc)
If the witness data isn't included in segwit transactions then how do you validate a transaction without the signature?
The witness data can be over 1 million bytes, that's how the block size increase segwit brings comes into play.
 

It seems like we get 2x transaction throughput for 4x block size, or maybe 2x block size on average.  So why even bother with Segwit?

There is no block size anymore with Segwit deployment, but block weight.
We get 2x the "block size" as you put it, because that that was the requirement

[zylstra]

Thanks for your reply and help, Xynerise.

My question was because I read this:

When serialized to a Legacy node, they will be 400 bytes, 300 bytes and 500 bytes respectively (tx size without witness data). When serialized to a Segwit node, they will be 800 bytes, 1100 bytes and 500 bytes respectively.

If the witness data isn't included in segwit transactions then how do you validate a transaction without the signature?

The same way you validate that same transaction when it's included in legacy blocks?  Or do legacy blocks need not validate segwit transactions?  If not, why not?  As soon as we discovered we don't need witness data in legacy blocks why not simply cut them out?

So we agree that, on average, the block size will increase approximately 2x in Segwit.  With that 2x size increase we will also get 2x throughput?  If so, we could have done just as well simply increasing block size without Segwit.

[DannyHamilton]

My question was because I read this:

When serialized to a Legacy node, they will be 400 bytes, 300 bytes and 500 bytes respectively (tx size without witness data). When serialized to a Segwit node, they will be 800 bytes, 1100 bytes and 500 bytes respectively.

That comment is talking about "Legacy Nodes" not "Legacy Blocks".

Where did you come up with the concept of a Legacy Block?  the only Legacy Blocks are the blocks that were created before SegWit was activated. Or are you talking about SegWit blocks stored by a Legacy Node?

If the witness data isn't included in segwit transactions then how do you validate a transaction without the signature?

The same way you validate that same transaction when it's included in legacy blocks?

In Legacy Blocks the witness data is still there.  It just isn't Segregated yet.

If you are asking about SegWit blocks stored by a Legacy Node, then those nodes are fooled into thinking that bitcoins sent to a SegWit address are sent to a "ANYONE CAN SPEND" output.  Therefore, when they try to validate the blocks that spend those bitcoins, they are unable to tell the difference between a block where those bitcoins are validly spent or a block where they are invalidly spent.  In other words, a Legacy Node is unable to fully validate a block that has transactions spending bitcoins that were previously received at a SegWit address. Instead, it must trust that those blocks have been validated by a SegWit node.

Or do legacy blocks need not validate segwit transactions? If not, why not?

There were no SegWit transactions yet back when Legacy Blocks were being created, therefore there was no need to validate them. (You can't validate something that doesn't exist).

If you are asking about SegWit blocks stored by a Legacy Node, then I've already explained that the Legacy Node can't tell the difference between a valid transaction that spends bitcoins which were previously received at a SegWit address and an invalid transaction that spends bitcoins which were previously received at a SegWit address. The Legacy Node must trust that the block has already been validated by a SegWit node.

As soon as we discovered we don't need witness data in legacy blocks why not simply cut them out?

It was never discovered that we don't need witness data.

So we agree that, on average, the block size will increase approximately 2x in Segwit.  With that 2x size increase we will also get 2x throughput?

Yes.

If so, we could have done just as well simply increasing block size without Segwit.

Except that we would miss out on all the benefits that SegWit provides.  SegWit was not intended to be a method of significantly increasing throughput. It was intended to fix some issues with bitcoin transactions (such as maleability), and to make other transaction types easier or possible.

[zylstra]

Or are you talking about SegWit blocks stored by a Legacy Node?

This is it.

If you are asking about SegWit blocks stored by a Legacy Node, then those nodes are fooled into thinking that bitcoins sent to a SegWit address are sent to a "ANYONE CAN SPEND" output.  Therefore, when they try to validate the blocks that spend those bitcoins, they are unable to tell the difference between a block where those bitcoins are validly spent or a block where they are invalidly spent.  In other words, a Legacy Node is unable to fully validate a block that has transactions spending bitcoins that were previously received at a SegWit address. Instead, it must trust that those blocks have been validated by a SegWit node.

This is what I was looking for.  Thanks.

If you are asking about SegWit blocks stored by a Legacy Node, then I've already explained that the Legacy Node can't tell the difference between a valid transaction that spends bitcoins which were previously received at a SegWit address and an invalid transaction that spends bitcoins which were previously received at a SegWit address. The Legacy Node must trust that the block has already been validated by a SegWit node.

More confirmation.  Good stuff.

Except that we would miss out on all the benefits that SegWit provides.  SegWit was not intended to be a method of significantly increasing throughput. It was intended to fix some issues with bitcoin transactions (such as maleability), and to make other transaction types easier or possible.

Ah, yes, true dat.

Thanks again.

[Carlton Banks]

So we agree that, on average, the block size will increase approximately 2x in Segwit.  With that 2x size increase we will also get 2x throughput?  If so, we could have done just as well simply increasing block size without Segwit.

No, that would have been reckless.

Segwit (amongst other fixes already mentioned) fixed a Denial of Service attack. That DoS attack was increasingly more effective as blocks became larger. This could have been used to force the Bitcoin network into long waits between blocks while CPUs struggled to process the attack blocks.

So, it wasn't safe to increase the size of blocks without mitigating the attack. Segwit constrained that attack, and increased the maximum block size at the same time.