1

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?

Attila Szeremi
  • 111
  • 3
  • 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 Dec 07 '17 at 00: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 – Attila Szeremi Dec 07 '17 at 00: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. – Pieter Wuille Dec 07 '17 at 00: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. – Attila Szeremi Dec 07 '17 at 00:59
  • No. Non-SegWit transaction don't have witnesses, they have normal scriptSigs instead. – Pieter Wuille Dec 07 '17 at 01:02
  • @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 Dec 07 '17 at 01:04
  • Woah there seems to be even more to it than I thought. I didn't know executable code was involved. – Attila Szeremi Dec 07 '17 at 01:12
  • 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 Dec 07 '17 at 01:16
  • If they had no scriptSig or witness, there would be no signatures so anybody could steal the money. – Claris Dec 07 '17 at 05:26
  • 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 Dec 07 '17 at 08:49
  • 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. – Andrew Chow Dec 08 '17 at 07:46

3 Answers3

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.

Andrew Chow
  • 67,209
  • 5
  • 76
  • 149
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.

Adam Millerchip
  • 1,035
  • 9
  • 18
  • And there are far more SegWit nodes than non-SegWit nodes, right? To appropriately reject the transaction with a 51% mayority. – Attila Szeremi Dec 11 '17 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 https://bitcoincore.org/en/2016/10/28/segwit-costs/#risks-related-to-soft-fork-deployment useful. – Adam Millerchip Dec 11 '17 at 21:46
-2

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.

Frank Dashwood
  • 1
  • 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. – Andrew Chow Dec 08 '17 at 07:48
  • 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 Dec 10 '17 at 18:36
  • 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). – Andrew Chow Dec 11 '17 at 01: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. – Andrew Chow Dec 11 '17 at 01: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. – Andrew Chow Dec 11 '17 at 01: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". – Andrew Chow Dec 11 '17 at 01:52
  • 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. – Andrew Chow Dec 11 '17 at 01:53