<p>Non-segwit clients do not send witness data. They do not know what witness data is and would not know how to interpret it.</p>

<p>However, I think you are asking about the scriptSigs, which contain largely the same data as witnesses. ScriptSigs are actually scripts, but since the only standard scriptSigs push data to the stack, the same behavior can be done by segwit with the witness data. Non-segwit clients must transmit scriptSigs (and the scriptSigs of segwit output spends are empty) because they are part of the data that is hashed for the transaction id. Furthermore, non-segwit clients must be able to verify non-segwit transactions; they shouldn't just blindly trust that the transaction is valid. So the scriptSigs provide the information necessary for them to verify those transactions.</p>

CC BY-SA 3.0
2017-12-08T07:51:54.860Z
2017-12-08T07:51:54.860Z
Ava Chow
<p>I'm simplifying, but hopefully this makes sense.</p>

<p>To spend bitcoin, a user must prove they have the right to spend the bitcoin from an address by signing the transaction with a signature corresponding to that address.</p>

<p>Pre-segwit, the signature appears next to the transaction in the block.</p>

<p>For segwit, the required signatures are separated from the transactions and grouped together at the end of a block. A pre-segwit node would not recognise the segwit area of the block, so for backwards compatibility it is removed when sending to a pre-segwit node, and an empty signature is left where the pre-segwit signature would have been. Additionally, a segwit transaction is structured so that it appears to be valid to a pre-segwit node with the empty signature.</p>

<p>This has the effect that for pre-segwit nodes, segwit transactions look like they can be spent with the empty signature. The transaction format is also non-standard from the point of view of a pre-segwit node, so the node will ignore these transactions until they are in a block. However if a pre-segwit node did try to spend a segwit transaction with an empty signature, it would be rejected by other segwit nodes because the required witness data would be missing.</p>

<blockquote>
  <p>Why do clients even send that data in in the first place?</p>
</blockquote>

<p>The signature/witness data is required to validate the transaction. Pre-segwit nodes are unable to fully validate segwit transactions, so are depending on segwit-enabled nodes to validate and place them into blocks.</p>

CC BY-SA 3.0
2017-12-11T16:11:12.333Z
And there are far more SegWit nodes than non-SegWit nodes, right? To appropriately reject the transaction with a 51% mayority.
Attila Szeremi
CC BY-SA 3.0
2017-12-11T21:46:14.787Z
It's not necessary for there to be a majority because non-segwit nodes will not forward segwit transactions, or spends from segwit transaction outputs, but will respect them if they are in a block. Maybe you'll find https://bitcoincore.org/en/2016/10/28/segwit-costs/#risks-related-to-soft-fork-deployment useful.
Adam Millerchip
CC BY-SA 3.0
2017-12-09T06:47:27.670Z
2017-12-09T06:47:27.670Z
Adam Millerchip
<p>Attila Szeremi-The witness data isn't "discarded" so much as "stored outside of the block". This is so that the LN payment channel can malleate the witness data as they need to in order to justify higher fees, arbitrarily renegotiate the terms of your agreement without your consent, re-order your txs to put you in the hole, and have you owing the bank, or other legacy financial service provider whose processing your txs, steal your Bitcoin and give you IOUs to spend.... You know, all of the fun, and abusive practices that caused you to look for another means to tx monetary value. </p>

<p>If this sounds far-fetched, consider. Normally the witness data is locked up in an encrypted block of hashes. In order to malleate the witness data, you have to get the block ahead of the rest of the chain, decrypt it, change the witness data, and re-broadcast the changed block back out to the network and get it included instead of the "true" block. With the witness data stored outside of the block, (I don't think it is encrypted...not sure) you just have to be the only recipient of the block before it's included in the chain. If you were a company that was performing Lightning Network services, all of the txs only happen in your payment channel before you broadcast them to the blockchain. This would allow you a lot longer than 10 minutes to do whatever you wanted with your customers funds until whenever you decided to close your payment channels. Considering we can now do "Atomic Swaps", it's conceivable that the coins you are sold/paid/given won't actually be Bitcoin. You may give them Bitcoin, but they will be binding some other IOUcoin to the keys they issue you. </p>

CC BY-SA 3.0
2017-12-08T07:48:05.270Z
This is just incredibly incorrect. Besides the fact that you clearly do not understand how segwit and the lightning network works, segwit does not exist solely for the lightning network. Furthermore, there is no encryption in any of Bitcoin's protocols at all. There are no "IOUcoins". This answer reeks of conspiracy theory and completely lack of understanding of the topic at hand. I highly suggest that you actually read into how Segwit and the lightning network works before answering such questions.
Ava Chow
CC BY-SA 3.0
2017-12-10T18:36:24.377Z
No sir, I am simply thinking further down the road than you are. I do notice that you don't have any real counters though, you just call me crazy/ignorant. The blocks are in fact encrypted (SHA-256 remember?).
Frank Dashwood
CC BY-SA 3.0
2017-12-11T01:45:11.387Z
There are so many things wrong with this post that I don't have enough characters to explain why, but I will try. Firstly SHA256 is a hash function, not an encryption function. You cannot decrypt a SHA256 hash. Secondly, the witness data is not stored outside of the block. It is stored within a block as part of each transaction. It is stored in each transaction in a new structure within the transaction itself which is not relayed to non-segwit nodes. LN payment channels do not malleate witness data; they need segwit to avoid third party malleation (first party malleation is always possible).
Ava Chow
CC BY-SA 3.0
2017-12-11T01:47:35.670Z
No malleation is done in a payment channel. There is no "higher fees" or "arbitrarily renegotionte the terms of your agreement without consent". Besides the fact that there is no agreement, if there were, LN does not allow just one party to change the channel; both parties must consent to change anything in the channel. Regarding fees, LN and segwit reduce fees; Segwit by increasing the block size with the block weight redefinition and LN by moving many transactions off-chain. There are no "IOUs" or owing any money to anyone; the money in an LN channel exists and is not a debt to someone.
Ava Chow
CC BY-SA 3.0
2017-12-11T01:50:13.247Z
Malleation of witness data does not require "unlocking" a block (which are not encrypted) or "changing a block". Malleation occurs when a transaction is unconfirmed; and the malleated transaction is effectively a double spend that confuses many software. It also makes LN difficult to work. Segwit does not allow for malleation of a transaction when it is included in a block. It is protected by having the hash of all of the transactions in their entirety (so including witnesses) included in the coinbase transaction. The merkle root in the block header protects the txids.
Ava Chow
CC BY-SA 3.0
2017-12-11T01:52:29.123Z
When using LN for atomic swaps, you will receive Bitcoin (or whatever coin you wanted to receive). Each channel can only exist for one coin, and you will know exactly what coin it is because the channel must have been funded with that coin when the channel was created. When doing transactions in a payment channel, the funds still exist in that channel and do not leave, so it is impossible for a merchant to "do whatever you wanted with your customers funds".
Ava Chow
CC BY-SA 3.0
2017-12-11T01:53:58.037Z
As we can see from the above four comments, your post is incredibly incorrect. It is not "thinking further down the road than you are" but rather a gross misunderstanding and mischaracterization of the technologies involved. Just because I did not go through the effort to write this up the first time I commented does not mean that I am incorrect or do not know what I am doing. It is simply that there is so much wrong that sometimes it isn't worth it to break everything down. I guess this time is not one of those times.
Ava Chow
CC BY-SA 3.0
2017-12-08T06:30:30.710Z
2017-12-08T06:30:30.710Z
Frank Dashwood
<p>If SegWit leaves out witness data for backwards-compatibility, thus witness data isn't so important apparently, then why do clients even send that data in in the first place?</p>

<p>Aren't they making their transactions unnecessarily bigger and thus more expensive?</p>

CC BY-SA 3.0
2017-12-07T00:43:33.973Z
Non-SegWit clients never see the witness data - they don't care about it and wouldn't understand it. It's only relayed between SegWit-enabled software.
Pieter Wuille
CC BY-SA 3.0
2017-12-07T00:51:44.623Z
But I mean basically SegWit saves space in (backwards-compatible) transactions by not including witness data in the 1MB blocks, allowing for cheaper transactions, and keeping the witness data separate. So then why don't non-SegWit clients to save the same amount of transaction space, just create transactions without witness data PERIOD? :D
Attila Szeremi
CC BY-SA 3.0
2017-12-07T00:53:16.470Z
Non-SegWit clients can't create any witness data. They can only spend non-SegWit outputs anyway, which don't need witnesses. Your question makes no sense.
Pieter Wuille
CC BY-SA 3.0
2017-12-07T00:59:20.277Z
I could be getting my terms on, but as far as I know non-SegWit transactions do send witness data, but they're stored non-segragated in the transactions.
Attila Szeremi
CC BY-SA 3.0
2017-12-07T01:02:00.053Z
No. Non-SegWit transaction don't have witnesses, they have normal scriptSigs instead.
Pieter Wuille
CC BY-SA 3.0
2017-12-07T01:04:06.907Z
@AttilaSzeremi You may find [this question thread](https://bitcoin.stackexchange.com/questions/42409/segregated-witness-soft-fork-how-is-the-funding-tx-made-anyonecanspend) has some answers for you.
chytrik
CC BY-SA 3.0
2017-12-07T01:12:51.540Z
Woah there seems to be even more to it than I thought. I didn't know executable code was involved.
Attila Szeremi
CC BY-SA 3.0
2017-12-07T01:16:57.313Z
In any case, then how come non-SegWit clients don't just also create this same OP_0 thing as a really cheap scriptSig replacement to gain the same space saving as what SegWit transactions get? Some important security involved making it well worth it for each client the increased transaction cost for creating the ~1.5x extra bytes of data?
Attila Szeremi
CC BY-SA 3.0
2017-12-07T05:26:43.490Z
If they had no scriptSig or witness, there would be no signatures so anybody could steal the money.
Claris
CC BY-SA 3.0
2017-12-07T08:49:07.753Z
But if that were the case, then since SegWit transactions also have no scriptSig or witness at least in the point of view of non-SegWit clients, that would imply that money of any SegWit transactions could be stolen by anybody non-SegWit clients. Does that make sense?
Attila Szeremi
CC BY-SA 3.0
2017-12-08T07:46:16.423Z
Since the transaction needs to be mined by miners enforcing segwit and verified by nodes enforcing segwit, such transactions that spend segwit outputs would be invalid without the corresponding witnesses. If a network does not have segwit enabled, then yes, you could steal from segwit outputs, but they aren't really segwit outputs there but rather anyone-can-spend outputs. This has happened on the Bitcoin Cash network already.
Ava Chow
<segregated-witness>
Why do non-SegWit clients send witness data in the first place?
Attila Szeremi
# Why do non-SegWit clients send witness data in the first place?

(Asked by: username_0 on 2017-12-07)

If SegWit leaves out witness data for backwards-compatibility, thus witness data isn't so important apparently, then why do clients even send that data in in the first place?

Aren't they making their transactions unnecessarily bigger and thus more expensive?

**Tags:** segregated-witness

> **Comments:**
> **username_1**: Non-SegWit clients never see the witness data - they don't care about it and wouldn't understand it. It's only relayed between SegWit-enabled software.  
> **username_0**: But I mean basically SegWit saves space in (backwards-compatible) transactions by not including witness data in the 1MB blocks, allowing for cheaper transactions, and keeping the witness data separate. So then why don't non-SegWit clients to save the same amount of transaction space, just create transactions without witness data PERIOD? :D  
> **username_1**: Non-SegWit clients can't create any witness data. They can only spend non-SegWit outputs anyway, which don't need witnesses. Your question makes no sense.  
> **username_0**: I could be getting my terms on, but as far as I know non-SegWit transactions do send witness data, but they're stored non-segragated in the transactions.  
> **username_1**: No. Non-SegWit transaction don't have witnesses, they have normal scriptSigs instead.  
> **username_2**: @username_0 You may find [this question thread](https://bitcoin.stackexchange.com/questions/42409/segregated-witness-soft-fork-how-is-the-funding-tx-made-anyonecanspend) has some answers for you.  
> **username_0**: Woah there seems to be even more to it than I thought. I didn't know executable code was involved.  
> **username_0**: In any case, then how come non-SegWit clients don't just also create this same OP_0 thing as a really cheap scriptSig replacement to gain the same space saving as what SegWit transactions get? Some important security involved making it well worth it for each client the increased transaction cost for creating the ~1.5x extra bytes of data?  
> **username_3**: If they had no scriptSig or witness, there would be no signatures so anybody could steal the money.  
> **username_0**: But if that were the case, then since SegWit transactions also have no scriptSig or witness at least in the point of view of non-SegWit clients, that would imply that money of any SegWit transactions could be stolen by anybody non-SegWit clients. Does that make sense?  
> **username_4**: Since the transaction needs to be mined by miners enforcing segwit and verified by nodes enforcing segwit, such transactions that spend segwit outputs would be invalid without the corresponding witnesses. If a network does not have segwit enabled, then yes, you could steal from segwit outputs, but they aren't really segwit outputs there but rather anyone-can-spend outputs. This has happened on the Bitcoin Cash network already.  

---

## 3 answers

### Answer by username_4 on 2017-12-08. Score: 2

Non-segwit clients do not send witness data. They do not know what witness data is and would not know how to interpret it.

However, I think you are asking about the scriptSigs, which contain largely the same data as witnesses. ScriptSigs are actually scripts, but since the only standard scriptSigs push data to the stack, the same behavior can be done by segwit with the witness data. Non-segwit clients must transmit scriptSigs (and the scriptSigs of segwit output spends are empty) because they are part of the data that is hashed for the transaction id. Furthermore, non-segwit clients must be able to verify non-segwit transactions; they shouldn't just blindly trust that the transaction is valid. So the scriptSigs provide the information necessary for them to verify those transactions.


---

### Answer by username_5 on 2017-12-09. Score: 1

I'm simplifying, but hopefully this makes sense.

To spend bitcoin, a user must prove they have the right to spend the bitcoin from an address by signing the transaction with a signature corresponding to that address.

Pre-segwit, the signature appears next to the transaction in the block.

For segwit, the required signatures are separated from the transactions and grouped together at the end of a block. A pre-segwit node would not recognise the segwit area of the block, so for backwards compatibility it is removed when sending to a pre-segwit node, and an empty signature is left where the pre-segwit signature would have been. Additionally, a segwit transaction is structured so that it appears to be valid to a pre-segwit node with the empty signature.

This has the effect that for pre-segwit nodes, segwit transactions look like they can be spent with the empty signature. The transaction format is also non-standard from the point of view of a pre-segwit node, so the node will ignore these transactions until they are in a block. However if a pre-segwit node did try to spend a segwit transaction with an empty signature, it would be rejected by other segwit nodes because the required witness data would be missing.

> Why do clients even send that data in in the first place?

The signature/witness data is required to validate the transaction. Pre-segwit nodes are unable to fully validate segwit transactions, so are depending on segwit-enabled nodes to validate and place them into blocks.

> **Comments:**
> **username_0**: And there are far more SegWit nodes than non-SegWit nodes, right? To appropriately reject the transaction with a 51% mayority.  
> **username_5**: It's not necessary for there to be a majority because non-segwit nodes will not forward segwit transactions, or spends from segwit transaction outputs, but will respect them if they are in a block. Maybe you'll find https://bitcoincore.org/en/2016/10/28/segwit-costs/#risks-related-to-soft-fork-deployment useful.  

---

### Answer by username_6 on 2017-12-08. Score: -2

username_0 username_0-The witness data isn't "discarded" so much as "stored outside of the block". This is so that the LN payment channel can malleate the witness data as they need to in order to justify higher fees, arbitrarily renegotiate the terms of your agreement without your consent, re-order your txs to put you in the hole, and have you owing the bank, or other legacy financial service provider whose processing your txs, steal your Bitcoin and give you IOUs to spend.... You know, all of the fun, and abusive practices that caused you to look for another means to tx monetary value.

If this sounds far-fetched, consider. Normally the witness data is locked up in an encrypted block of hashes. In order to malleate the witness data, you have to get the block ahead of the rest of the chain, decrypt it, change the witness data, and re-broadcast the changed block back out to the network and get it included instead of the "true" block. With the witness data stored outside of the block, (I don't think it is encrypted...not sure) you just have to be the only recipient of the block before it's included in the chain. If you were a company that was performing Lightning Network services, all of the txs only happen in your payment channel before you broadcast them to the blockchain. This would allow you a lot longer than 10 minutes to do whatever you wanted with your customers funds until whenever you decided to close your payment channels. Considering we can now do "Atomic Swaps", it's conceivable that the coins you are sold/paid/given won't actually be Bitcoin. You may give them Bitcoin, but they will be binding some other IOUcoin to the keys they issue you.

> **Comments:**
> **username_4**: This is just incredibly incorrect. Besides the fact that you clearly do not understand how segwit and the lightning network works, segwit does not exist solely for the lightning network. Furthermore, there is no encryption in any of Bitcoin's protocols at all. There are no "IOUcoins". This answer reeks of conspiracy theory and completely lack of understanding of the topic at hand. I highly suggest that you actually read into how Segwit and the lightning network works before answering such questions.  
> **username_6**: No sir, I am simply thinking further down the road than you are. I do notice that you don't have any real counters though, you just call me crazy/ignorant. The blocks are in fact encrypted (SHA-256 remember?).  
> **username_4**: There are so many things wrong with this post that I don't have enough characters to explain why, but I will try. Firstly SHA256 is a hash function, not an encryption function. You cannot decrypt a SHA256 hash. Secondly, the witness data is not stored outside of the block. It is stored within a block as part of each transaction. It is stored in each transaction in a new structure within the transaction itself which is not relayed to non-segwit nodes. LN payment channels do not malleate witness data; they need segwit to avoid third party malleation (first party malleation is always possible).  
> **username_4**: No malleation is done in a payment channel. There is no "higher fees" or "arbitrarily renegotionte the terms of your agreement without consent". Besides the fact that there is no agreement, if there were, LN does not allow just one party to change the channel; both parties must consent to change anything in the channel. Regarding fees, LN and segwit reduce fees; Segwit by increasing the block size with the block weight redefinition and LN by moving many transactions off-chain. There are no "IOUs" or owing any money to anyone; the money in an LN channel exists and is not a debt to someone.  
> **username_4**: Malleation of witness data does not require "unlocking" a block (which are not encrypted) or "changing a block". Malleation occurs when a transaction is unconfirmed; and the malleated transaction is effectively a double spend that confuses many software. It also makes LN difficult to work. Segwit does not allow for malleation of a transaction when it is included in a block. It is protected by having the hash of all of the transactions in their entirety (so including witnesses) included in the coinbase transaction. The merkle root in the block header protects the txids.  
> **username_4**: When using LN for atomic swaps, you will receive Bitcoin (or whatever coin you wanted to receive). Each channel can only exist for one coin, and you will know exactly what coin it is because the channel must have been funded with that coin when the channel was created. When doing transactions in a payment channel, the funds still exist in that channel and do not leave, so it is impossible for a merchant to "do whatever you wanted with your customers funds".  
> **username_4**: As we can see from the above four comments, your post is incredibly incorrect. It is not "thinking further down the road than you are" but rather a gross misunderstanding and mischaracterization of the technologies involved. Just because I did not go through the effort to write this up the first time I commented does not mean that I am incorrect or do not know what I am doing. It is simply that there is so much wrong that sometimes it isn't worth it to break everything down. I guess this time is not one of those times.  

---

