Segregated Witness, Segwit - Discussion

Blockchain and Bitcoin 101
#204

@filip @ivan please have some comments to these trivial questions:

Thanks

#205

Hi @longph68, welcome to the forum! :slight_smile:

Alice creates a signature of the unlocking script that allows her to spend the Bitcoin locked in the UTXO, this is the input of the transaction and only a part of it. The rest of the transaction is serialized and hashed to get the txid.
The reason Bob can then change the id is because he can make changes to the locking scrpit which (also called a witness) like inserting an OP_DROP at the end of it which does nothing but it does chane the txid.

You can’t because this is not part of the witness data. Alice decides how much she will pay to Bob and not vice versa.

Once a transaction is confirmed and part of a block this is no longer an issue. Malleability is only a concern when the transaction is still pending in the mempool. This becomes an issue for unknowing users that don’t know this can happen and are waiting for a specific txid to become visible in the blockchain.
For example Bob can say to Alice, the transaction with this id is not there and Alice would think she made a mistake and create a new transaction thus sending Bob the value twice.

3 Likes
#206

Thank you @Alko89. It’s a bless to join such a great community.

As I understand when Alice sign and send the transaction (lets call it TX0), TX0 is then propagated to a random number of nodes in the network waiting to be verified and sent to a block where the transaction is finally confirmed. My question is:

  1. After TX0’s signature is altered by B to create new txid (TX1), what will happen to TX0 which was verified by other nodes? How will the Bitcoin network decide which transaction to put into a block, since TX0 and TX1 are both verified by different nodes?
  2. Since Bob can edit the signature to create a new txid, can he repeat the process and wipe out Alice’s bitcoin balance?

Thanks for helping !

1 Like
#207

Bob wouldn’t really make a new transaction, this would be more considered a TX0’, because its technically the same tx with a different id so only one transaction gets confirmed at the end. The attack must also be timed well because if a miner is already constructing a block with TX0 then TX0’ will not have any effect.

Bob can’t really empty Alices balance unless Bob convinces Alice that TX0 didn’t go through and Alice creates a new TX1 on her own. :slight_smile:

3 Likes
#208

Wait a minute, after all the thoughts and time that Bob put into lying Alice he only receives the TX0’ amount of bitcoin since TX0 was discarded because like you said only one transaction gets confirmed at the end? What is the benefit here for Bob to carry out such an attack?

#209

Not much unless he convinces Alice to send the tx again. The issue is more prominent when machines send transactions among themselves, like nodes on the lightning network. Its not such an issue if Bob and Alice are human that are sending txs manually. :slight_smile:

1 Like
#210

Wow, I see, if there is an automated contract/ smart contract between Alice and Bob, this is certainly a way of grinding Alice’s account. It will make bitcoin network a bankrupted contract instead of smart contract. Very interesting. Thanks for the insight @Alko89 !

#211

Bob altered the transaction ID from the first transaction and is still recieveing the inputs from that transaction from Alice? I thought Blockchain was immutable? Or does this take place prior to the network confirming the transaction?

#212

Yes, malleability attack must be timed well and is only an issue before the transaction is confirmed. :slight_smile:

1 Like
#213

Would it still be possible today? Or post btc core update (segwit) make it impossible? Also, sine the segwit introduced ‘block weight’ and now the block weight 4mb vs block size 1mb is that an increase of four times? Meaning can a block now hold 4 times the transactions than the previous block size of 1 mb?

Thanks! :slight_smile:

#214

No because Segwit fixed the malleability issue.

It depends on the transactions that go in a block, some transactions can have very large witness data and can quickly fill up. But transaction size in a block was decreased around 30%. :slight_smile:

3 Likes
#215

Awesome, thanks for the info. :sunglasses:

#217

You replied to the discussion thread not where the homework is. :slight_smile: also you missed the first question :wink:

2 Likes
#218

Hello,
I have understood that the signature was moved out of the transaction with the segwit.

But where did the signatures go? To the nodes which are not running on segwit and store the full transaction, a kind of a backup?
What would happen if 100% of the nodes would switch to segwit?

#219

The witness data is stored in a separate data structure that all segwit nodes download.

Nothing much, segwit is already accepted eventually all nodes will be updated and it will be just a normal day in crypto :slight_smile:

2 Likes
#220

But where did the signatures go? To the nodes which are not running on segwit and store the full transaction, a kind of a backup?

The witness data is stored in a separate data structure that all Segwit nodes download.

But if the witness data are just stored in a separate data structure which is as well shared to all Segwit nodes, I don’t understand how the overall size problem is solved. I mean the block size might be smaller, but the overall package which has to be distributed to all the node must still be the same (size wise)!?

1 Like
#221

The block size remained the same, this is how segwit was able to be implemented as a soft fork (initially it was intended to be implemented as a hard fork).
By moving the witness data to a new data structure, old nodes still accept blocks because they kept the same size of 1MB.
Updated nodes that also store witness data store it in a new data structure that is limited to 4MB and only segwit nodes will download it. Thus keeping backwards compatibility. :slight_smile:

#222

So in other words, the Segwit blocks are 4 mB blocks and therefore the total Segwit Blocksize (base transaction block + extended block) has been increased.
As the 4mB blocks have to be distributed to the hole network (at least to the Segwit nodes), the Bitcoin network slowed down (at least for the confirmation time) as more then 50% of all transaction are on Segwit and probably more will follow, correct?

In this way, the Segwit update was very important and good, but has also a negative impact on the confirmation time, correct?

#223

Why do you think the network slowed down or has slower confirmation time? Segwit update actually boosted transaction throughput and the more people adopt it more transactions will able to be stored in a block also making transaction fees lower. :slight_smile:

#224

Hi Filip,

Enjoying your lectures so far. Quick question, you mentioned issues with full blocks. How many transactions contain in a Full block? Thanks! :hugs:

1 Like