Segregated Witness, Segwit - Discussion

awesome. thanks Filip

Hey, sorry I seemed to miss your question. I’m not aware of any website that would track the statistics of nodes in the network, but nodes do gossip their versions among each other, so you would have to read the versions of nodes in the network. Personally I would imagine most nodes would be updated by now, but people are weird and I found a v0.15.0.1 (which is pre segwit) node in my peers list. :stuck_out_tongue:
image

How is it that TX malleability is only possible for signatures? Couldn’t you theoretically add a space or any number of things to a transaction that wouldn’t change the underlying information but would create a new hash?

I’m not completely sure how this is a soft fork instead of a hard fork. Before, signatures needed to be included. Now, they do not. Doesn’t that mean that blocks that were once invalid for not having signatures are now valid (expansion/hard fork)?

The transaction is serialized so all spaces would get removed before its hashed. And the receiver can only influence the locking script or (witness) part of the tx therefore he effectively can’t change anything else in it.

Segwit update changed the way certain type of transaction is handled by adding new meaning to it. So old nodes will accept the tx as valid but would be unable to spend it.

You can learn in detail how both these concepts work in our Bitcoin Programming course :slight_smile:

I have a question about the Segwit reading assignment’s 3rd question, relating to similarities between Bitcoin and the Lightning network. I understand that Segwit introduced support for layer 2 capabilities, but I am not sure what that means or how it relates to the Lightning network. I also don’t understand what the Lightning network is & whether it’s a part of Bitcoin or an entirely separate project. I read the Wikipedia article on the Lightning network, but that confused me even more :sweat_smile:
Can someone please help clarify these confusions for me? Can I learn more about this in future courses? Thanks for any insights you can provide :slight_smile:
-Nick

Hi! beginner here myself, but I was thinking the same thing, and from what I can find, it seems that how it works is by essentially creating channels between the first and last user in a group that is transacting, and only the ‘opening’ and ‘closing’ channels (peers on the beginning and ending of a sequence of transactions) are charged a fee. that is how the lightning network is able to keep fees so low.
For example; Alice sends BTC to Bob, who sends some to Tim, who then sends some to Renee, who then sends some to Jon who sends some to Bob, who sends some to John. I am not sure exactly HOW, but essentially the fee is calculated for Alice’s initial transaction and for Johns final transaction. This data is "connected’ as a layer to the block chain now.

1 Like
  • What was a proposed alternative to Segwit? The proposed alternative was to enlarge the block size limit.

  • What did Segwit solve more than just the scaling issue? It did a few things: first, it avoided a hard fork. Second, it eliminated transaction malleability by having the signatures stored separately from the transaction itself. Lastly, it leds itself to the development of second layer protocols (i.e. lightning network, MAST [brings smart contracts to the bitcoin network], and Schnorr signatures [a means of singing the transaction requiring less data size creation]).

  • How is Segwit and the Lightning network connected? The lightning network allows transactions to occur off the blockchain (peer-to-peer without fees or delay by creating channels between users). Only the ‘opening’ and ‘closing’ channels are made between the first and last user to the chain. Users are then free to transact amongst themselves, only to ensure that they are all balanced between themselves before ‘closing’ the channel.

  • Are people, wallets and other services forced to use Segwit? No they are not. Segwit adaptation requires updates to systemic application, and at present time, it’s adoption is at 40% (at the time of writing the article, it was 14%!)

1 Like

Yes as you mentioned Segwit enabled second layer solutions to be build on top of Bitcoin. Lightning is one of these. its a separate project that is intended to run on top of Bitcoin (or any other Segwit enabled blockchain). Simply its a second layer network made of payment channels between participants to enable fast and low fee off chain txs as pointed out by @cryptcat :slight_smile:

You can learn all about the Lightning network in out Lightning 101 course :wink:

1 Like

Ok, it makes more sense now. I think I’ll add Lightning 101 to my study plan, it might help me better understand Ethereum layer 2 solutions as well. Thank you for your help! :slight_smile:

Hey Filip or anyone kind who can explain :slight_smile:
Hope im not repeating a question. My question is how can Bob spend the transaction he altered if it is no longer recognisible that it came from alice? How does network verify his UTXOs if it has a random hash ?

The signature alteration can be done in such a way that if you run a mathematical check on it, it is still valid according to the network, but if you run a hashing algorithm on it gives a different transaction id. Bob is just confusing Alice to send him again by changing the transaction id.

1 Like

I see so the utxos are verified mathematically? I thought it is more like the network traces back the hash to where it has originally came from and that only newly mined bitcoin has no history?

Am a little confused on how removing the signature wouldn’t change the hash? Is it because you only need it once? Does segwit make two transactions (one for the signature and one for the Tx id) or does it just completely remove the signature from the equation? And do miner store the signatures or are they irrelevant and can be disposed off?

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. :slight_smile:

Its still one tx. The witness hasn’t been removed. It was moved to a new data structure that segwit enabled nodes hold and the data in the tx was replaced with a hash of the witness script.
If now someone would change the witness script the hash in the transaction would still remain the same, thus the txid would remain the same. But the unlocking script would not be found later which would harm the receiver which is the one that was able to change it before, thus making him unable to later spend these funds. :slight_smile:

1 Like

Thanks for asking the question by the way, I had the same question too.

I agree - this kind of question is poorly formed because it relies on subtle interpretation of meaning between “moved” and “removed”. So instead of discovering whether the quiz taker understands something, we find out how the exam writer doesn’t understand something.

No there is an obvious difference between moving and removing something. The witness in segwt was moved to a new data structure and not removed entirely. Its an important distinction. :slight_smile:

Note how you now added the word “entirely” to further qualify the distinction. You just made the point I was making. And it is an important distinction.

You can REMOVE something and put it somewhere else. The sentence would be accurate. You can move something somewhere else. Context can be read both ways:

I can move something from Box A to Box B. I can remove something from Box A and put it in Box B. Both work.