Welcome to the discussion thread about this lecture section. Here you can feel free to discuss the topic at hand and ask questions.
8 Likes
Hey Filip,
I don’t know if I understand it correctly.
Alice sends the transaction with right signatures, nodes validated the transaction and they put it into the mempool. Bob finds the transaction by the transaction ID and he changes the signature to random number. Once the transaction has got into mempool nobody is checking the signatures again. Miners just come and take the transaction, since it is in the mempool it suposed to be alright and these transaction is appended to the blockchain but with random signature.
Since the signature is changed by Bob, Alice can’t find it and she decides to send it again.
Is that right?
I understood that when the segwit was introduced there is no need for node to keep signature data, so in this case he is blindly copying the blockchain from other nodes?
28 Likes
Hi,
Great question. The signature is altered by Bob, yes. But that doesn’t invalidate the signature. It’s still a valid signature and a valid tx. So nodes doesn’t care. But the TX id is changed and therefore Alice’s old tx looks like it’s lost to her. And then she might resend a new tx to Bob, and he gets both.
With segwit, Bob can still alter the signature, but that doesn’t effect the tx id (since the signatures are outside of the tx). So it doesn’t have any effect.
35 Likes
Thank you for answer, but definitelyI need to learn more about it, I understand the general concept, but I still don’t get it 100%.
8 Likes
Sounds good. If you want more information here is a good start: https://en.bitcoin.it/wiki/Transaction_malleability
But it’s beginning to get quite complex when you dig deeper, because now you are getting down to cryptography and discrete math.
10 Likes
I can see that SegWit was implemented as a soft-fork update, as it has backwards compatibility with nodes which haven’t updated for Segwit, and therefore hasn’t caused a permanent split in the blockchain.
But I have been struggling to find other similarities with the soft-fork characteristics in the example used in the previous section (reduction in the block-size limit from 1MB to 0.5MB):
-
Does the contraction of the rule set with SegWit come about because the new locking script literally just requires a public key to spend the UTXO (i.e. anyone can spend it), instead of both a public key AND a signature?
This shorter locking script is less restrictive, because now anyone can spend the UTXO (at least according to how non-Segwit nodes interpret it).
In contrast, the reduction in block-size limit makes the rules more restrictive.
My understanding is that the shorter locking script is actually just a programming “trick” to get the non-updated nodes to accept the SegWit transactions as valid, and that this isn’t a security problem because there is still a high percentage of updated nodes that will read the shortened locking script to mean that the UTXOs can only be spent by the owner of both the public keys and the signatures stored separately. Is that correct? -
SegWit has been optional and no-one has been forced to adopt the new rule set. In the reading assignment homework, most people have said that this is because SegWit is a soft-fork update. However, previously, we learnt that a soft-fork update normally ends up forcing the minority group of miners (that don’t update) to adopt the new rules if they want their blocks included in the longest chain. Is the key to the optional nature of SegWit more to do with the different locking scripts used to distinguish between the two types of transactions?
-
If I’ve understood correctly, I think the SegWit-updated nodes accept both types of transactions, and therefore append blocks with both types of transactions in them. However, previously, we learnt that soft-fork updates make previously valid blocks invalid: with a reduction in the block-size limit, updated nodes reject blocks that are valid under the previous rule set. So, with a soft-fork update wouldn’t we expect SegWit-updated nodes to reject blocks with non-SegWit transactions in them?
12 Likes
Very good questions, as always. Let’s hope I manage to answer them clearly.
Does the contraction of the rule set with SegWit come about because the new locking script literally just requires a public key to spend the UTXO (i.e. anyone can spend it), instead of both a public key AND a signature?
The new segwit locking scripts are not really a contradiction to previous rules. They fit within the previous rules perfectly as you state (anyone can spend them according to old nodes). This is more of a programming trick, yes.
The term “less restrictive” could be a bit misleading here. The new rules need to fit within the previous ruleset. But it all depends on your perspective on the change. You could have the perspective that the segwit nodes from this point forward only creates transactions with the new format, and not the old one. Both the new and old format is still valid for both segwit and non-segwit nodes. But since the new nodes will create tx’s with only the new format, you could argue that they have reduced the amount of valid scripts.
But you could also view it from another perspective, which you did, where you say that the new segwit scripts are “looser” in a sense because anyone can spend them (according to the old nodes). But that has nothing to do with the size of the ruleset itself, which still has shrunk and therefore become more restrictive.
But in the end, from a programming perspective, the rules when it comes to which scripts are valid hasn’t changed at all. The ruleset is the same there. It’s just that segwit nodes choose to create them in a new way.
My understanding is that the shorter locking script is actually just a programming “trick” to get the non-updated nodes to accept the SegWit transactions as valid, and that this isn’t a security problem because there is still a high percentage of updated nodes that will read the shortened locking script to mean that the UTXOs can only be spent by the owner of both the public keys and the signatures stored separately. Is that correct?
Basically correct yes. Your description of how nodes read the new script is not necessarily correct, but the general perspective yes. The new script will be interpreted by the segwit nodes in exactly the same way as old scripts, it’s just different syntax. (Apart from the signature which is in another place)
Is the key to the optional nature of SegWit more to do with the different locking scripts used to distinguish between the two types of transactions?
Yeah, because non-segwit transactions are still accepted by segwit nodes.
So, with a soft-fork update wouldn’t we expect SegWit-updated nodes to reject blocks with non-SegWit transactions in them?
They will reject blocks that don’t fit the new segwit rules. For example blocks that don’t adhere to the new block weight rules. But non-segwit transactions can still be added into valid blocks. Because those transactions are still valid in the eyes of new nodes.
Wow, that was a long answer… I hope I answered your questions. Let me know if anything is unclear.
17 Likes
Hey Filip,
Thanks for your detailed reply! I think it’s slowly becoming clearer…
Here’s what I’ve understood and interpreted from your comments. I hope you can follow my reasoning, and it’s not too twisted! 
So are we saying that even though non-SegWit nodes continue to create txs using the longer locking script, theoretically there is nothing to stop them creating txs using the shorter SegWit locking script, because BOTH are permitted syntax within the old rule set (although, of course, they never actually use the shorter script in practice, because that would effectively mean leaving the UTXO unlocked for anyone to spend)?
In contrast, the SegWit update doesn’t permit SegWit nodes to create txs using the longer locking script. And so this is the actual tightening/shrinking of the rule set which makes it a soft-fork update. At the same time, these two different locking scripts are what distinguishes SegWit and non-SegWit txs from each other.
Is that correct?
So does this mean that wallets which give the option of sending either tx type have to integrate with both SegWit and non-SegWit nodes to be able to create both?
So even though SegWit nodes only create SegWit txs, and vice versa, once created, either type of tx can then be propagated to and validated by any node in the network, then included in blocks and mined by any miner, and ultimately blocks containing mixed txs can then be propogated to any node for validation and inclusion in their version of the blockchain.
Is that correct?
Are the new block-weight calculation rules a clever way to account for both types of tx within the same block, and still include the segregated witness data within the calculation (albeit at a “discount”); and at the same time it enables more transactions to fit into a block than before, while still providing an overall cap (the SegWit-node majority rejects blocks greater than the weight limit of 4M weight units), which is also backwards compatible with the 1MB block-size limit used by non-SegWit nodes to validate and append new blocks?
2 Likes
So are we saying that even though non-SegWit nodes continue to create txs using the longer locking script, theoretically there is nothing to stop them creating txs using the shorter SegWit locking script, because BOTH are permitted syntax within the old rule set (although, of course, they never actually use the shorter script in practice, because that would effectively mean leaving the UTXO unlocked for anyone to spend)?
That’s correct.
In contrast, the SegWit update doesn’t permit SegWit nodes to create txs using the longer locking script. And so this is the actual tightening/shrinking of the rule set which makes it a soft-fork update. At the same time, these two different locking scripts are what distinguishes SegWit and non-SegWit txs from each other.
Is that correct?
There is nothing stopping segwit nodes from creating tx’s with the old syntax. They don’t need permission to do so. And both are valid. But they do generally, create tx’s using the new syntax. But this question originally came from a discussion about expanding/contracting the rule set, which from a pure programming it isn’t really related to. It was just another view point of the new tx types. There were no changes in which scripts are allowed or not allowed in sewit. It just changes the way they are generally created. So I don’t think this point will lead to greater understanding of the nature of the fork necessarily.
So does this mean that wallets which give the option of sending either tx type have to integrate with both SegWit and non-SegWit nodes to be able to create both?*
No, both nodes can use the old syntax. The only difference is that the old nodes won’t interpret it the same.
So even though SegWit nodes only create SegWit txs, and vice versa, once created, either type of tx can then be propagated to and validated by any node in the network, then included in blocks and mined by any miner, and ultimately blocks containing mixed txs can then be propogated to any node for validation and inclusion in their version of the blockchain.
Yes, except that blocks can’t be mined by any miner. Blocks can only be mined by segwit miners. But blocks by segwit nodes will be accepted and verified by old nodes and miners. But vice versa is not true. We need to separate tx’s from blocks. Old tx’s are still valid, not old blocks.
Are the new block-weight calculation rules a clever way to account for both types of tx within the same block, and still include the segregated witness data within the calculation (albeit at a “discount”); and at the same time it enables more transactions to fit into a block than before, while still providing an overall cap (the SegWit-node majority rejects blocks greater than the weight limit of 4M weight units), which is also backwards compatible with the 1MB block-size limit used by non-SegWit nodes to validate and append new blocks?
Yes. You could say it was a way to increase the block size in practice while still keeping the block size below 1mb in theory.
3 Likes
Thanks for your patience!
I haven’t given up yet…
How does this summary look?
Shorter SegWit locking-script:
- Not really a contraction of rule set BUT fits within legacy rule set
= backwards compatible => soft fork - Programming trick to enable legacy nodes to validate and accept SegWit txs
(interpret SegWit locking-script as “anyone can spend”, which is strange but still valid) - Two different locking scripts distinguish between SegWit and legacy txs
New block-weight limit
- Not a contraction of rule set BUT keeps the blocks mined by SegWit nodes theoretically within the legacy 1MB block-size limit = backwards compatible => soft fork
(although thanks to some creative accounting the effective block size is now bigger
= more txs per block
)
I still can’t see where the rule set has actually shrunk (become more restrictive). Instead of an actual contraction as such, isn’t it more just backwards compatibility (“fitting in”) with the legacy rules and programming syntax (which effectively has the same outcome as a contraction anyway => soft fork)?
Tx creation:
SegWit nodes can create both SegWit txs and legacy txs.
Legacy nodes can’t create SegWit txs, only legacy txs.
Validation:
Both SegWit and legacy nodes can (i) validate both types of txs; and (ii) validate and append new blocks (which contain both types of txs) to their versions of the blockchain.
Mining:
Only SegWit mining nodes can mine blocks containing both types of txs, because SegWit requires changes to the block structure e.g.
- witness data hashed and stored in a separate Merkle tree to the tx data
- “witness Merkle root” = input in the coinbase tx
Why did the miners (who didn’t want to hard-fork update to Bitcoin Cash etc.) have to either update to SegWit or stop mining? What stopped them from selecting only legacy txs from the mempool and continuing to mine blocks containing only these? As SegWit is backwards compatible, I guess SegWit nodes would still be able to validate and append blocks with only legacy txs. Is it because this would put them at a competitive and economic disadvantage compared to SegWit miners?
10 Likes
This is great. I really get to think through my answers as well, so I learn a lot too.
Not really a contraction of rule set BUT fits within legacy rule set
= backwards compatible => soft fork
Programming trick to enable legacy nodes to validate and accept SegWit txs
(interpret SegWit locking-script as “anyone can spend”, which is strange but still valid)
Two different locking scripts distinguish between SegWit and legacy txs
Yes, correct.
I still can’t see where the rule set has actually shrunk (become more restrictive). Instead of an actual contraction as such, isn’t it more just backwards compatibility (“fitting in”) with the legacy rules and programming syntax (which effectively has the same outcome as a contraction anyway => soft fork)?
That’s true, most of the changes are changes that just fits in the legacy rules. I actually had to go back and research a little bit to find what actually restricts the ruleset. Because I remembered there was something, otherwise non-segwit blocks would be accepted as well.
And as you pointed out as well it’s the witness hash in the coinbase transaction that makes the difference. Non-segwit nodes won’t create blocks according to that rule, so the ruleset has shrunk, and therefor non-segwit nodes can’t create blocks that are accepted by segwit nodes. You can read more about this in BIP141.
You are correct in all your comments on tx creation, validation and mining. But you missed a little detail in your summary. Here is it.
Why did the miners (who didn’t want to hard-fork update to Bitcoin Cash etc.) have to either update to SegWit or stop mining?
Even if they only selected legacy transactions their blocks don’t follow the same structure as defined in new “segwit blocks”, with the witness root hash in the coinbase transaction. So regardless of the transactions in that block, it won’t get accepted by segwit nodes. And since a majority is segwit nodes, they won’t get any block rewards.
Great job on researching and questioning on this. You have great knowledge of not only segwit now, but bitcoin forks and block/tx structure in general.
8 Likes
Hi Filip. Everything is clear so far. Thank you for the killer explanation! 
1 Like
So, now all bitcoin nodes are with Segwit? Have everyone accepted it?
just a bit confusing… here https://charts.woobull.com/bitcoin-segwit-adoption/ it looks like only part of all transactions…
But, if Segwit can have more transactions in their blocks, doesn’t it mean that they can earn more tx fees? so it is in their interest to get in segwit…?
segwit transactions are much cheaper (Segwit separates signatures from the transaction hash)
They are discounted in the block weight.
(fee’s are calculated in sats/byte)
1 Like
No, not all nodes have accepted it. But a majority has, and that’s what’s important with a soft fork.
It could be both ways, they could perhaps earn more fees, but it might also lower the tx fee per transaction. Generally fees are very volatile and depend on many factors. You can see a histogram of fees collected here: https://www.blockchain.com/sv/charts/transaction-fees
1 Like
But if the tx signature is removed with segwith, doesnt it make the network more unsecure?
Also, if the signature is not included in the tx hash, then where is it?
Like, if i send a tx to somebody, where is the signature stored and how can somebody verify that its my signature, if it doesnt come with the actual tx?
And, segwit was very controversial, maybe youll speak about it in the next chapters, but if not, then perhaps you can ellaborate why so many people where against it? What were the downsides of it?
3 Likes
Segregated Witness was a proposal to change the structure of bitcoin transaction data.
The main reason for doing this is to fix the problem of transaction malleability . However, this change also allows for other , such as increasing the number of transactions that can fit in to a block .
Without segwit, the lightning network wouldn’t be possible because of this transaction malleability issue.
Some people were against it because they wanted bigger blocks Instead. (So Bitcoin cash forked from Bitcoin)
What are the changes?
In the current transaction data structure, signatures (the code that “unlocks” existing bitcoins) sit next to each input, so this unlocking code is spread throughout the transaction data. The TXID is then created from the entire transaction data .
In Segregated Witness (occassionally and affectionately referred to as SegWit from here on out), the proposal was to move all of the unlocking code to the end of the transaction data . The TXID is then created from all of the transaction data, except for the unlocking code .
Result:
The TXID is only influenced by the effects of a transaction (the movement of bitcoins), and not by any code needed to validate the transaction (i.e. signatures used to unlock existing bitcoins so that they can be spent).
So in essence, you have separated the “validating” part (unlocking code) from the “effective” part of the transaction.
What are the benefits?
12 Likes
When Segwit is implemented, how does a node know what signature belongs to what transaction when they are separated from each other?
1 Like
A Bitcoin address , or simply address , is an identifier of 26-35 alphanumeric characters, beginning with the number 1 , 3 or bc1 that represents a possible destination for a bitcoin payment
P2PKH (legacy) which begin with the number 1, eg: 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2.
P2SH (Segwit compatible) type starting with the number 3, eg: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy.
Bech32 (Segwit native) type starting with bc1, eg: bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq
This way nodes know wich version the transaction is using.
The signatures are still sent together with the transaction. They are just not included in the hash of the transaction, like @Fabrice showed in the graphic. I hope that makes sense 
2 Likes