Welcome to the discussion about this section. Here you can ask questions or post feedback about this specific lecture.
Really enjoying these videos! Just one point of feedback is it’s a little bit tricky to keep track of these different parts when scrolling up and down. If possible it would be nice to keep things on the same slide as much as possible or maybe zoom in and zoom out rather than scrolling.
Q: If I understand correctly, is it the fact that you’re able to embed a segwit transaction inside a P2SH transaction which makes it a soft fork rather than a hard fork? It’s a bit confusing what an old node can and cannot do when it comes to segwit transactions, but I’ll re-watch the videos and stick with it.
also just fyi there’s a blooper for the first 12s of " Segwit Scripting Part 2 - Embedded Transactions"
Thank you for the feedback! I appreciate it. I have also edited out the blooper and will upload a new video for that section. You have no idea how many of those I have to edit out
To your question. No, not really. The reason it was a soft fork is that old nodes that didn’t upgrade still see segwit txs as valid. To them, a segwit tx looks like a “anyone can spend” tx. Because they don’t see the witness part and don’t know about the new locking script standard. The locking script to them contains no function call that verifies or checks signatures.
Remember, a segwit locking script i just 0 <PK_HASH>. To nodes that are unaware of the new scripting standard, they will just look at that locking script as something that anyone can redeem. While a segwit node will know what it actually means. I hope it became more clear
Hi. For more advanced information, check out this page. (Also possible reading assignment to be added)
The website and video’s of Greg Walker are amazing. Very detailed explanation.
Thanks for the great lectures! Would it be also possible to provide us the presentations of Segwit Scripting Part 1 and Part 2? Thanks a lot!
I’ve added them as downloads now!
So, Segwit changed the locking script to simply
which is good. BUT:
For Pay to Witness Script Hash (P2WSH), they now use sha256(script) which is 32 bytes instead of ripemd160(sha256(script)) which is 20 bytes, adding 12 bytes, but allowing the network to differentiate between P2WSH and Pay to Witness Public Key Hash (P2WPKH) which still uses ripemd160(sha256(pubkey)). This is good, but could devs not better just added a single byte to the tx to tell the network what kind of tx? One extra byte for all txs, instead of 12 extra bytes for the txs that are P2WSH. Could have saved more tx size?
Hello everybody, and thank you for the great lecture.
My question is: When we say that the LOCKING SCRIPT is going to the witness then we say that the functions and hash of public key is going into the witness area. But in the quiz you say “the benefits of Segwit enabled outputs are”
one of it is
“Enables nodes to query a transaction without the signatures included”
but the outputs do not contain signature. Am I right?
It only contains the functions and the public key hash. Or the public key hash is the signature also?
This is the output: OP_DUP OP_HASH160 9b7906c8b4f9370e390863d26709fd16e34de2ea
What is the signature in it?
So is there any difference between signatures and public key hashes or sometimes we call them signatures sometimes public key hash?
This confuse me, thank you for the answer.
Hi filip, can you please explain to me the difference between Segwit and Native Segwit (Beech 32) ?
I have these 2 accounts on my Ledger. Is there a difference in security or usability?
Sometimes I cannot use one or the other account to receive bitcoins… The sender-wallet said that the receiving address is “strange”… So I was using the “other” Bitcoin account just to be sure…
native segwit bc1…
Thx. a lot 4 your help.