In segwit, the signatures are not included in the transaction itself, but just a different datastructure. So that the core of the transaction is always the same, even if you broadcast the same transaction with a different signature, the transaction ID remains the same.
Watch Andreas talking about it:
https://youtu.be/Vux6o7gSnhE
Take per exemple a traking number for some shipping that you wait for, if you have a tracking number 5885-A-8388 and you look online, you will be able to track your package. But if someone at the shipping facility are tired to receive your call about questionning why your package it’s stock somewhere in London… the guys can change the Tracking number that is affiliate with your package and now next time you try to do take a look, your tracking number is not working anymore… But the fact is your will still receive your package, but both side will not be able to see the history of the shipping using the older tracking numuber, as they emplpoyee’s have change it. Only the new tracking number will give that answer. But Imagine if by changing the Tracking Number that will changer also the name of the Receive or sender, that was Bob doing, by changing the tracking number ( signature ) and change the name of the receiver. If Alice try to track the package under her Name : Alice Brown and will also see nothing because Bob have change the signature ( tracking number ) and now the name on the tracking slip will be Monique Larose. With segwit, that will not change the name on it, meaning that Alice will search for Alice Brown and will be able to track it. But no matter what, No matter if it’s write Alice Brown or Monique Larose on the slip, the package will arrive to the same house. Segwit, no Segwit…
1 Like
I have a question for how the signature data is stored without it being included in the transactional data? In order for the signature data to be stored on the blockchain it would need to be included in the block data so it can be propagated to the network. If most modes are still storing transactional data is it just done locally and off chain? If it is done on chain I do not see how it helps with the issue of blocks being full
The signatures are still next to the transaction data, and not really like physically separated.
Signatures are just stored next to the transaction data in a different field that will not be used to hash everything. So basically we could increase the blocksize a little bit without a hardfork + we have trusted transaction ID’s that can’t change.
1 Like
Hi Filip,
I have what i think is a very simple question which may not required a simple answer.
When you change a signiture does this not also change the Hash of the TX? (in which case it just becomes invalid?)
Thanks
Thank you for the explanation, size the block size has been pseudo increased this surely means that there is now more latency in the network as the blocks will take longer to be sent to each node? also what id like to know is how the change of measurement from mb to weight is able to trick the nodes which have not updated to segwit? Is it that they read the ‘weight’ of less that 1,000,000 as bytes instead of weight due to the way they interpret the code?
1 Like
Old nodes just don’t get the signatures of (segwit) blocks from their (segwit) peers so the transaction data part is physically always still less or equal than 1MB and still fit the old rules. Old nodes are basically becoming a light client. Almost every miner updated, but not every wallet and user is using segwit addresses.
1 Like
In this Lesson we learn that after segwit bitcoin remained with the 1mb block size. However When I am on the blockchain explorer it is evident that many of the block sizes are indeed over 1mb… Am I missing something?
3 Likes
Hello everybody, I have a question, so with the new segwit update is the security of transactions the same by not having the signature into the transaction script?? Thank you, @filip 
Love the course, and Fillip and Ivan as educators - they are really good at explaining everything in a simple way! I struggle to get the Transaction mallability bug though. How can it be possible to change the signature - because the signature is based on the private key, and if you change the signature, surely it will no longer be valid based on the private key?
Filip explains, in his example on transaction malleability, that it would be possible to interfere with a transaction, so that the signature was changed, which would change the hash and make it appear that the transaction did not take place to someone tracking the transaction. I get that, but surely if the signature changed, then the transaction would no longer be valid. Surely it needs to be signed by the sender in order to be valid, so changing the signature would change the ID but also result in the transaction being rejected?
Am I missing something?
@filip is the amount of time a transaction sits in the mempool correlated to the fee paid for confirmation?
1 Like
I think it’s the 1mb maximum size, plus block header plus witness data.
Hello Filip
Thank you for the lecture. I have one question though:
How were you able to manipulate the signature before segwit and keep the bitcoin that was sent to you. This would change the hash of the block and then you will have to mine that block again for the transaction to be validated?
@Henk1 & @Kiki
Hello sir(s), i think both of you guys refer to the transaction malleability issue, let me try to explain it simple:
Here’s how the transaction malleability attack works:
- Alice creates a Bitcoin payment transaction, and sends it to her peers.
- The original Bitcoin implementation was underspecified with respect to how txids were actually calculated. - Therefore, it’s possible for Alice’s peers to slightly modify the transaction.
- Suppose Bob is a peer of Alice, and wants to initiate a transaction malleability attack against Alice.
- The inputs, outputs, and payment amount are all cryptographically signed, so Bob can’t steal money or make any semantic changes to the transaction.
- However, Bob can make some changes that don’t change the transaction semantics, but do change the computed txid.
- At this point Bob will broadcast the transaction with a new txid to the rest of the network.
- At this point it’s a race to see which transaction will actually be accepted by the network: the original transaction created by Alice and relayed by her good peers, or the modified version created by Bob.
- The attack is called “transaction malleability” because Bob was able to modify the transaction, even though the transaction was supposed to be immutable.
In Example:
- Suppose Alice sends 1 BTC with expected txid A, but Bob modifies the transaction so the new txid is B.
- The modified transaction B then gets added to the blockchain, which implicitly invalidates A.
- Alice’s client software keeps checking for txid A, but never sees it.
- Alice’s wallet software will debit 1 BTC from her account once the modified transaction is confirmed, since the modified transaction still sent 1 BTC from her account.
- But if Alice isn’t paying close attention, she might eventually give up and think the transaction failed for some reason, and she could retry the transaction.
- If she does retry the transaction, she’ll send another 1 BTC to the same address.
- In essence, Bob has tricked Alice into double paying.
The signature does not change, what is changed is the transaction ID (txid), so essentially, its a valid transaction since the signature is completely valid. Problem is that the txid has change, and the sender wallet could not recognized since it has another txid.
The receiver does not manipulate the signature, just the txid that it has to propagate through the network, so the sender will not be able to “see” the txid that it’s wallet creates, since its a different, problem is that the new txid manipulated by the receiver contains the signature from the sender, so it is a valid transaction.
If you want a more graphical example, check this PDF from the BlackHat Team, BITCOIN TRANSACTION MALLEABILITY THEORY IN PRACTICE.
Hope this gives you a clear view of the subject, keep learning! 
If you have any doubt, please let us know so we can help you!
Carlos Z.
2 Likes
@filip I dont understand how someone can modify the transaction ID and how it works to trick me in to double send a payment.
Lets say Bob sends 1 btc to Alice and Alice modifies the transaction ID. How do Alice do that?
Is it possible to modify in just BTC not using SegWit or can you do it in other currencies aswell like Ethereum, etc?
Thank you so much for your answer @thecil. I am not 100% clear on how the signature is still valid if the details, any detail at all , is changed in the TX. The signature is a signing of the transaction by the sender, right? So if anythithing changes, that signature should not be valid.
I can see one possibility…
The TX contains a signature by the sender, of only some elements, and a hash of all elements.
When something outside the signature of the sender changes, it changes the overall hash.
Is that so?
1 Like
yes, the signature is the sign from the private key of the sender, most cases is the same for every transaction.
If the signature is the same, the txid is the one that change, and is signed with the same signature.
Yes, the txid is signed with the same signature, but if the txid is manipulated, it will change the hash of the txid, but is still a valid txid since it’s signed with a valid signature from the private key of the sender.
Thats why, the txid can be manipulated, since you send a txid signed by you, you get a txid hash, but if the receiver alter that txid, it still have the same signature, so is a valid new txid, problem is that your first txid will not show up by your wallet, but you do sign a txid with your signature, so the transaction is completely valid, thats was the issue with the double spend.
Hope this gives you a clear view of the subject, keep learning!
Carlos Z.
1 Like