<blockquote>
  <p>Question 1) It says that when bob makes a transaction to alice, that transaction goes to bob's malicious node. then bob changes signature so that It still stays valid transaction. and After that, there's a chance that this transaction will take place quicker than the original transaction that some other nodes have in mempool. and BOb has a chance of getting double * amount that alice is intended to transfer.</p>
</blockquote>

<p>No, Bob will not get double. He will see two transactions that conflict with each other. No additional coins are created or spent. It is just annoying and wallets do not handle these conflicting transactions very well.</p>

<blockquote>
  <p>I'm curious what bob's malicious node change in a signature part that it still stays alice's signature and still valid? how is it possible?</p>
</blockquote>

<p>The signature is malleable. An ECDSA signature is composed of two values, <code>R</code> and <code>s</code>. Due to how the signature verification algorithm works, it is possible to replace the <code>s</code> with it's negation (<code>-s</code>). <code>-s</code> is easily computable by a third party, so an attacker can compute <code>-s</code>, replace the <code>s</code> value with the inverse, and send the new transaction. Because the contents of the transaction are now different due to the replacement of <code>s</code> with <code>-s</code>, the transaction has a different id so is considered different. But it is still completely valid.</p>

<blockquote>
  <p>QUestion 2) How does segwit work? I know scriptSig is deleted from transaction, but where is it saved?</p>
</blockquote>

<p>Segwit defines a new transaction format which is an extension of the original transaction format. In this format, a new field is added that is known as <code>scriptWitness</code>. The <code>scriptWitness</code> is where the signatures go. For nodes that do not have segwit, they only receive transactions in the old format. They won't see the <code>scriptWitness</code>.</p>

<p>The signatures are not deleted from the transaction. They are just moved elsewhere.</p>

<blockquote>
  <p>QUestion 3) if it's saved in blockchain still, then how is it a less size and how can block have more transactions than now?</p>
</blockquote>

<p>Blocks are not actually physically smaller. The block size has increased without a hard fork.</p>

<p>What segwit also did was redefine the metric of block size from bytes to a new unit called weight. To calculate the weight of a block, you have to look at the transactions. Each byte of a transaction that is part of the original transaction format is counted as 4 weight units. Each byte that is part of the new segwit transaction format is 1 weight unit. The maximum number of weight units in a block is 4000000. The math works out such that an old node will not see a block with more than 1 MB of data (since they do not receive transaction in the new format).</p>

<p>So with this new definition of a weight unit, transactions without segwit have more weight units than transactions that use segwit. Thus transactions are "smaller" so more transactions can fit in a block.</p>

<blockquote>
  <p>Question 4) They say signature part is saved as the merkle root hash. but how can a node check that specific signature is related to specific transaction?</p>
</blockquote>

<p>The signature is not saved in the merkle root hash. You cannot save any data in a hash. The signatures are committed to in the merkle root hash. What that means is that the data that went into the merkle root hash includes the signatures. This makes it so that the signatures cannot be once the transactions are in a block. The reason that this needs to be done is because the merkle root is only over the txids, which the <code>scriptWitness</code>es are not part of (they are ignored in the txid calculation). So the full transaction hash (known as the <code>wtxid</code>) is used in a witness merkle root which is included in the coinbase transaction. This results in that hash being part of the coinbase transaction's txid which goes into the merkle root of the block.</p>

CC BY-SA 4.0
2018-10-07T04:52:19.670Z
Not s^(-1) but -s.
Pieter Wuille
CC BY-SA 4.0
2018-10-07T05:04:50.400Z
Oh, right. I don't know why I used s^-1. Fixed.
Ava Chow
CC BY-SA 4.0
2018-10-07T04:28:25.190Z
2018-10-07T05:04:23.603Z
2018-10-07T05:04:23.603Z
Ava Chow
<p>I'm kind of desperate as I can't follow some ideas that I don't understand. I hope you can help me. Thank you in advance</p>

<p>It's all about Segwit</p>

<p>Question 1) It says that when bob makes a transaction to alice, that transaction goes to bob's malicious node. then bob changes signature so that It still stays valid transaction. and After that, there's a chance that this transaction will take place quicker than the original transaction that some other nodes have in mempool. and BOb has a chance of getting double * amount that alice is intended to transfer. I'm curious what bob's malicious node change in a signature part that it still stays alice's signature and still valid? how is it possible?</p>

<p>QUestion 2) How does segwit work? I know scriptSig is deleted from transaction, but where is it saved?</p>

<p>QUestion 3) if it's saved in blockchain still, then how is it a less size and how can block have more transactions than now?</p>

<p>Question 4) They say signature part is saved as the merkle root hash. but how can a node check that specific signature is related to specific transaction?</p>

<p>THank you guys.I hope your explanation will make sense</p>

CC BY-SA 4.0
2018-10-04T16:19:46.467Z
Have you read BIP141 (segwit proposal) ? Most of your questions are answered there.
Mike D
CC BY-SA 4.0
2018-10-04T21:59:40.360Z
*"and BOb has a chance of getting double * amount that alice is intended to transfer"*. Transaction malleability does not allow a user to receive double the coins. Whichever tx is confirmed in a block first would invalidate the other, it is not possible for both to confirm. Note that you will probably find stories of exchanges being defrauded by tx malleability. In those cases, the exchange built a system which checked tx ids to verify txs were sent. By malleating  the tx, an attacker could convince an exchange their withdrawal was not processed. This is simply an implementation issue.
chytrik
CC BY-SA 4.0
2018-10-05T08:44:36.160Z
Signatures are never deleted.
Claris
<segregated-witness>
Transaction Malleability, How can I change signature?
Nika Kurashvili
# Transaction Malleability, How can I change signature?

(Asked by: username_0 on 2018-10-04)

I'm kind of desperate as I can't follow some ideas that I don't understand. I hope you can help me. Thank you in advance

It's all about Segwit

Question 1) It says that when bob makes a transaction to alice, that transaction goes to bob's malicious node. then bob changes signature so that It still stays valid transaction. and After that, there's a chance that this transaction will take place quicker than the original transaction that some other nodes have in mempool. and BOb has a chance of getting double \* amount that alice is intended to transfer. I'm curious what bob's malicious node change in a signature part that it still stays alice's signature and still valid? how is it possible?

QUestion 2) How does segwit work? I know scriptSig is deleted from transaction, but where is it saved?

QUestion 3) if it's saved in blockchain still, then how is it a less size and how can block have more transactions than now?

Question 4) They say signature part is saved as the merkle root hash. but how can a node check that specific signature is related to specific transaction?

THank you guys.I hope your explanation will make sense

**Tags:** segregated-witness

> **Comments:**
> **username_1**: Have you read BIP141 (segwit proposal) ? Most of your questions are answered there.  
> **username_2**: *"and BOb has a chance of getting double * amount that alice is intended to transfer"*. Transaction malleability does not allow a user to receive double the coins. Whichever tx is confirmed in a block first would invalidate the other, it is not possible for both to confirm. Note that you will probably find stories of exchanges being defrauded by tx malleability. In those cases, the exchange built a system which checked tx ids to verify txs were sent. By malleating  the tx, an attacker could convince an exchange their withdrawal was not processed. This is simply an implementation issue.  
> **username_3**: Signatures are never deleted.  

---

## 1 answers

### Answer by username_4 on 2018-10-07. Score: 3 | Accepted answer

> Question 1) It says that when bob makes a transaction to alice, that transaction goes to bob's malicious node. then bob changes signature so that It still stays valid transaction. and After that, there's a chance that this transaction will take place quicker than the original transaction that some other nodes have in mempool. and BOb has a chance of getting double \* amount that alice is intended to transfer.

No, Bob will not get double. He will see two transactions that conflict with each other. No additional coins are created or spent. It is just annoying and wallets do not handle these conflicting transactions very well.

> I'm curious what bob's malicious node change in a signature part that it still stays alice's signature and still valid? how is it possible?

The signature is malleable. An ECDSA signature is composed of two values, `R` and `s`. Due to how the signature verification algorithm works, it is possible to replace the `s` with it's negation (`-s`). `-s` is easily computable by a third party, so an attacker can compute `-s`, replace the `s` value with the inverse, and send the new transaction. Because the contents of the transaction are now different due to the replacement of `s` with `-s`, the transaction has a different id so is considered different. But it is still completely valid.

> QUestion 2) How does segwit work? I know scriptSig is deleted from transaction, but where is it saved?

Segwit defines a new transaction format which is an extension of the original transaction format. In this format, a new field is added that is known as `scriptWitness`. The `scriptWitness` is where the signatures go. For nodes that do not have segwit, they only receive transactions in the old format. They won't see the `scriptWitness`.

The signatures are not deleted from the transaction. They are just moved elsewhere.

> QUestion 3) if it's saved in blockchain still, then how is it a less size and how can block have more transactions than now?

Blocks are not actually physically smaller. The block size has increased without a hard fork.

What segwit also did was redefine the metric of block size from bytes to a new unit called weight. To calculate the weight of a block, you have to look at the transactions. Each byte of a transaction that is part of the original transaction format is counted as 4 weight units. Each byte that is part of the new segwit transaction format is 1 weight unit. The maximum number of weight units in a block is 4000000. The math works out such that an old node will not see a block with more than 1 MB of data (since they do not receive transaction in the new format).

So with this new definition of a weight unit, transactions without segwit have more weight units than transactions that use segwit. Thus transactions are "smaller" so more transactions can fit in a block.

> Question 4) They say signature part is saved as the merkle root hash. but how can a node check that specific signature is related to specific transaction?

The signature is not saved in the merkle root hash. You cannot save any data in a hash. The signatures are committed to in the merkle root hash. What that means is that the data that went into the merkle root hash includes the signatures. This makes it so that the signatures cannot be once the transactions are in a block. The reason that this needs to be done is because the merkle root is only over the txids, which the `scriptWitness`es are not part of (they are ignored in the txid calculation). So the full transaction hash (known as the `wtxid`) is used in a witness merkle root which is included in the coinbase transaction. This results in that hash being part of the coinbase transaction's txid which goes into the merkle root of the block.

> **Comments:**
> **username_5**: Not s^(-1) but -s.  
> **username_4**: Oh, right. I don't know why I used s^-1. Fixed.  

---

