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?

  • 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. Commented Dec 7, 2017 at 0:43
  • 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 Commented Dec 7, 2017 at 0:51
  • 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. Commented Dec 7, 2017 at 0:53
  • 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. Commented Dec 7, 2017 at 0:59
  • 1
    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
    Commented Dec 8, 2017 at 7:46

3 Answers 3


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.


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.

  • And there are far more SegWit nodes than non-SegWit nodes, right? To appropriately reject the transaction with a 51% mayority. Commented Dec 11, 2017 at 16:11
  • 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 bitcoincore.org/en/2016/10/28/segwit-costs/… useful. Commented Dec 11, 2017 at 21:46

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.

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.

  • 1
    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
    Commented Dec 8, 2017 at 7:48
  • 1
    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
    Commented Dec 11, 2017 at 1:45
  • 1
    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
    Commented Dec 11, 2017 at 1:47
  • 1
    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
    Commented Dec 11, 2017 at 1:50
  • 1
    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
    Commented Dec 11, 2017 at 1:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.