Segregated Witness, Segwit - Discussion

Blockchain and Bitcoin 101
#42

Bitcoin has a build-in upgrade mechanism. If a majority of the bitcoin miners vote for a particular upgrade, then by definition this is the new version of Bitcoin. The number of votes each miner gets is proportional to the amount of computation power they are adding to the network (can’t be faked)
These votes can happen at any time.

The discussion takes place on multiple places off course. Most of the debates has focused on written proposals, conferences, signed letters, Twitter name calling, IRC, bitcoin talk, reddit,…

2 Likes
#43

Amazing. Makes perfect sense thank you :pray:

1 Like
#44

@filip

Couldn’t the sender just check the recent transactions from destination address and verify their address is the sender?

Also, how does one actually try to change the transaction information? i just don’t understand how a person would accomplish this. is there certain wallets that allow this accomplished through software the general public is unaware of.

I understand how segwit fixes transaction malleability but would’t adoption eventually make the blocksize full again in the future?

1 Like
#45

Yes, only the transaction ID could be changed when it is still uncomfirmed. You could mislead people, but if you check the addresses, you can’t be fooled.

In Bitcoin core, you can change the signature by broadcasting the same transaction with a different signature.
Not in simple wallets. RBF (replace by fee) is also something that you can update an unconfirmed transactions by updating your Fee. (if it takes to long to get your transaction confirmed)
https://bitcoin.stackexchange.com/questions/79811/transaction-malleability-how-can-i-change-signature

That’s why we need second layer solutions like the lighting network. Scaling to much on chain is not very wise if you need to make a trade-off with security or decentralization

2 Likes
#46

Ty for answering my questions. much appreciated. love the course!

1 Like
#47

@filip

Blockquote
Reading Assignment
What is Segwit?

SegWit introduced a new concept called “block weight.” This is a mashup of the block size with and without the signature data, and is capped at 4MB, while the block size limit for the base transactions remains at 1MB. This means that the SegWit upgrade is compatible with the previous protocol, and avoids the need for a hard fork.

So, SegWit does not increase the block size limit, but it does enable a greater number of transactions within the 1MB blocks. The 4MB cap includes the segregated witness data, which technically does not form part of the 1MB base transaction block.

If a miner finds a block, only the transaction block (1MB block size) is propagated to the nodes. But what about the segregated witness data? Who does keep these data? Only the miner node, which found the block? Or are there any other nodes, which store these data?
And if there are other nodes, which also store these data, how do they get it? Do these nodes construct the witness data using the data in the 1MB base transaction block?

#48

I have problems understanding how a Malicious Node can alter a TX and put in the Mempool since other Nodes have the correct TX. :confused:

Mallitious TX
Mallitious TX748×483 47.8 KB

If my question is pertinent and someone can clarify it, it will be grateful. :grinning:

#49

Every node has a mempool, so every node will double check with other nodes mempool. If they see that some node has different information than the others, this node will be dropped from the network

1 Like
#50

Hello Fabrice. Thank you for your time and effort to answer my question.

Now I am confused.

As far as I understood, if Sender A creates a transaction (TX.A) for receiver B, the receiver B can alter the Signature of TX.A in order to obtain TX Malleability (TX.B).
What I don’t understand, is how TX.B is being accepted in the Mempools.

My understanding
My understanding892×2128 268 KB

Acc. to my understanding, In order for this to happen, Node/Receiver B is the first Node that will receive the information (TX.A).
After receiving TX.A, it will alter it making it TX.B and broadcast it through the network as TX.B.

TX.B

2 Likes
#51

Great answers, so glad I read this discussion. One more question though for my understanding, are Tx Signatures literally stored off the chain? Was it just that small change in the syntax that boosted the block weight?

#52

I like Segwit because of how much lower the fees are and quickness of the transactions. Three years into it and I believe most have implemented into Segwit, I’ve heard.

#53

@filip

Hey Filip, how are you today?
I am not quite sure that I understood the TX malleability subject.
In my understanding changing the signature is basically changing the data of the input ? or what do you mean a change of the script signature?
As far as I know today you can track exactly each TX on the block explorer by filling in the wallet address ? there for Alice could see exactly where the funds went?

I might be confused a bit, would love a clarification.

#54

It’s basically by broadcasting the same transaction, but with different signatures. In a transaction, You need to unlock your utxo’s with a script (unlocking script)
As long your transaction is not confirmed, you could do that.
You will learn more about this in Bitcoin programming course

https://en.bitcoin.it/wiki/Transaction_malleability

1 Like
#55

Thanks a lot bro :slight_smile:

1 Like
#56

@filip
Question: If segwit removed the signature from the transaction, allowing more txs to fit in a 1 BM block, but then have to send 1 MB worth of signatures around to all the nodes to “store separately”, then what is the advantage over 2 MB block sizes? In both cases you have 2 MB of data that have to be passed around to all the nodes. Yes nodes can choose not to keep the signatures at all, but you said that most or all do keep them anyway for security. So total data being passed around is still 2 MB, just not in the “block”. I don’t get the practical difference.

#57

The signatures are not on the block itself, it’s just in a different (less prioritized) datastructure. For example, nodes not only need to sync the blockchain, but also the mempool etcetera. If you would count everything, you would be very high in weight. Now signatures are just not part of the blockchain itself. Soon with schnorr signatures, you don’t even need to sign every utxo separately. You could sum all signatures from utxo’s in 1 (combined) signature. And even less weight needed in multisig)

#58

Thank you for that explanation. And indeed Schnorr signatures sound like a phenomenal improvement.

1 Like
#59

@filip
I have some things to discuss.
How often do transaction malleabilities occur? Is/ was this really a common problem?
When I have a look at the average bitcoin block size:
https://bitinfocharts.com/comparison/bitcoin-size.html
it looks like the average size is around 800kb. I could imagine that in case of a new bull run/ more adaption, it looks like the problem with full blocks could occur again. What will happen then? Are there other solutions if the full block size problem appears again?

#60

I have a question @filip. So where are the signatures included, are they still part of the block? If not, how do you verify the block? What do you mean by “stored on the side”? Are they just kept in the database of the nodes but not in the actual blockchain? Can you still mess with the sigantures, even if they are not part of the tx?

1 Like
#61

As long as a transaction was unconfirmed, users could send the same transaction again but with a different VALID signature. Segwit segregated the signatures in a different datastructure that isn’t part of the transaction itself. So the transaction ID is based on data of the transaction without the possibility to have another (same) transaction with more fee + a different signature that produce a different ID, would be mined first. People that pay bitcoin, will always look at the transaction ID to check if it’s payed or not. So bad people could copy the same transaction with a different transaction ID that get mined instead, so they can say to the buyer that they didn’t receive the funds. Because the victim will look at the first transaction ID wich will never be confirmed because this transaction is confirmed with a different ID. so they could tell buyers to send the amount again. So sneaky people could mislead others to pay twice.

Transaction malleability + segwit by Andreas Antonopoulos

Scaling is another issue. This is the reason we have the lightning network for small payments. On chain payments have a fee market. So it’s supply and demand to get your transaction faster or slower mined into a block. Scaling on chain is not wise, because it takes heavy equipment and fast network connections to propagate heavy sized blocks. So increasing the blocksize will always lead to more centralisation. (Like the rich with expensive equipment become more rich and the poor stay poor)