And to my knowledge 95% of miners did not update within the 2 week time frame. Doesn’t this mean that it became a hard fork?
https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality This blog will explain segwit upgrade.
Hi! Thanks for the great course and explanation! I have one question regarding the signatures. Where are they stored if they are no longer in the transactions. The information cannot be stored in the block, because then it wouldn’t decrease the overall size. Do nodes keep a separate database of signatures then? How is it linked to the blockchain? Thx.
SegWit separates the signatures from the transaction hash, not the transaction itself. The signatures are in the block, right along with the transactions, just as before. Fully upgraded SegWit nodes see the whole block, if you have a fully upgraded node, all signature data is available forever. If you are not upgraded, you won’t know what that signature data means and would ignore it, so it is not sent to you. Hope this make sense.
If the signature is removed from the Txn block, then where is it now stored?
And can you please explain a little bit more what you mean by “smaller btc nodes that don’t store signatures” I don’t understand that please sir.
And also why are larger nodes queried for signatures? This last question isn’t so right because my first question needs a answer.
@filip
This is a great analogy!
I don’t really get the transaction malleability part.
How could you change a signature and still get a valid hash ?
What I understood is that a signature is a proof that our private key approves the transaction. It’s our wallet that creates the signature as an authentification certificate kind of and sends it to nodes.
The signature is obtained by hashing the transaction with our private key, right ?
So how could you change that ?
Is it generating a hash with another random private key ?
I think I just don’t understand technically how a signature is made and therefore I’m confused
1 Like
The thing that could be changed in the tx is the unlocking script or witness. Which is determined by the receiver. Since it was historically part of the tx it was hashed with the tx to get the transaction id (txid) if the receiver changed the script while it was still in the mempool the id changed so the original txid was not found once it was eventually confirmed. There is still a history where the tx was sent from its just that the current one couldn’t be found using the original id. You can also learn in detail how both these concepts work in our Bitcoin Programming course
2 Likes
Even i seem to have lost it from the point when Bob sends again. is it a new block or a new transaction that is sent by Bob. Can Bob send a transaction with Alice’s signature? If the bob is sending the same transaction the signature would change. If I understand correctly, the transaction would not be accepted as the hashes would change, and also the signature won’t match that of Alice.
Sorry maybe i have misunderstood this part.
The thing that could be changed in the tx is the unlocking script or witness. Which is determined by the receiver. Since it was historically part of the tx it was hashed with the tx to get the transaction id (txid) if the receiver changed the script while it was still in the mempool the id changed so the original txid was not found once it was eventually confirmed. There is still a history where the tx was sent from its just that the current one couldn’t be found using the original id. You can also learn in detail how both these concepts work in our Bitcoin Programming course.
Hey, I’m not sure if I understood this topic 100%.
As far as I understood it the whole point is that tx malleabilities are possible only on blocks filled up to 1mb. Why is that the case?
I think you misunderstood the concept of tx malleabilities, it does not have anything to do with block size.
It’s an attack that lets someone change the unique ID of a bitcoin transaction before it is confirmed on the bitcoin network.
1 Like
Okay, thanks for the clarification 
If transactions don’t have the signatures how are the transactions verified? Where do the nodes look?
Hello everyone! Just a note on the link for the Segwit reading assignment, the link does not work.
Thanks for this course!!
hmm 
, it is working for me if you are mean this link https://web.archive.org/web/20191001083147/https://www.coindesk.com/information/what-is-segwit.
From the minute 05:50 of the video on, the doubt of mine that remains…
How is Bob able to alter the key signature of the transaction? How is anyone able to do such a thing? Isn’t this something supposed to be impossible since we can’t reverse the hash to what has generated it?
That I can’t simply understand.
Looks like you were left hanging with your question. Did you get answers a different way?
To answer this, I believe it might be more of a memory hack than a programming logic hack.
Using machine code or assembly language, a programmer could map out the ram memory, find the transaction in the memory pool and brute force it to be something else. This is before any hashes for the newly proposed block are calculated. It ~is~ nearly impossible to write blocks with compromised hashes. This hack takes place before that. This is my “rough idea” of how this hack would occur. Can someone else in here verify it?