<blockquote>
  <p>But how would someone know which associated transaction is required to hash with your transaction to confirm its validity? And where would you get it from?</p>
</blockquote>

<p>Your question is a little vague, it sounds like you are asking how a lite client confirms that a transaction they care about is indeed in a block. The party trying to convince them the transaction is included can give them the required information.</p>

<p>Full nodes already have all the data and don't need to have it provided.</p>

<blockquote>
  <p>Also, i'm a little confused about Segregated Witness. As I understand it, the signatures are separated from the transactions and the signatures are hashed in the same manner as transactions. This final signature hashed is either hashed with the final transaction hash to form a Merkle root, or it is contained as another Merkle root in a separate field in the block. But if the Merkle root is always the same size (I assume) how does this save space? If the Merkle root is always 256 bits,</p>
</blockquote>

<p>The segwit commitment is down lower in the tree not at the top. This doesn't make any real functional difference but it answers your question about the root always being the same size.</p>

<blockquote>
  <p>why does it matter if the signatures are hashed with the transactions or hashed separately?</p>
</blockquote>

<p>Because when transactions specify which coins they are spending they refer to it by the txid. If the signature data is part of the txid then changes to the signature (like third party malleation or resigning) invalidate subsequent transactions.  If the signatures are excluded from those txids this problem does not happen.</p>

CC BY-SA 4.0
2019-03-12T22:30:29.610Z
2019-03-13T10:57:12.453Z
2019-03-13T10:57:12.453Z
G. Maxwell
<p>I'm trying to find out how exactly transactions are confirmed in a block.  I understand that to confirm a transaction, you hash it with its associated transaction and then the associated hashes until you get the Merkle root, and if the Merkle root is the same as that which is in the block, the transaction is legitimate.</p>

<p>But how would someone know which associated transaction is required to hash with your transaction to confirm its validity?  And where would you get it from?</p>

<p>Also, i'm a little confused about Segregated Witness.  As I understand it, the signatures are separated from the transactions and the signatures are hashed in the same manner as transactions.  This final signature hashed is either hashed with the final transaction hash to form a Merkle root, or it is contained as another Merkle root in a separate field in the block.  But if the Merkle root is always the same size (I assume) how does this save space?  If the Merkle root is always 256 bits, why does it matter if the signatures are hashed with the transactions or hashed separately?</p>

<p>I can't find clear answers to my questions so any help will be appreciated.</p>

<transactions><blockchain><segregated-witness><transaction-verification><merkle-tree>
Confirming transactions in the Merkle root and SegWit
vasimmahmood
# Confirming transactions in the Merkle root and SegWit

(Asked by: username_0 on 2018-02-26)

I'm trying to find out how exactly transactions are confirmed in a block. I understand that to confirm a transaction, you hash it with its associated transaction and then the associated hashes until you get the Merkle root, and if the Merkle root is the same as that which is in the block, the transaction is legitimate.

But how would someone know which associated transaction is required to hash with your transaction to confirm its validity? And where would you get it from?

Also, i'm a little confused about Segregated Witness. As I understand it, the signatures are separated from the transactions and the signatures are hashed in the same manner as transactions. This final signature hashed is either hashed with the final transaction hash to form a Merkle root, or it is contained as another Merkle root in a separate field in the block. But if the Merkle root is always the same size (I assume) how does this save space? If the Merkle root is always 256 bits, why does it matter if the signatures are hashed with the transactions or hashed separately?

I can't find clear answers to my questions so any help will be appreciated.

**Tags:** transactions, blockchain, segregated-witness, transaction-verification, merkle-tree


---

## 1 answers

### Answer by username_1 on 2019-03-12. Score: 2

> But how would someone know which associated transaction is required to hash with your transaction to confirm its validity? And where would you get it from?

Your question is a little vague, it sounds like you are asking how a lite client confirms that a transaction they care about is indeed in a block. The party trying to convince them the transaction is included can give them the required information.

Full nodes already have all the data and don't need to have it provided.

> Also, i'm a little confused about Segregated Witness. As I understand it, the signatures are separated from the transactions and the signatures are hashed in the same manner as transactions. This final signature hashed is either hashed with the final transaction hash to form a Merkle root, or it is contained as another Merkle root in a separate field in the block. But if the Merkle root is always the same size (I assume) how does this save space? If the Merkle root is always 256 bits,

The segwit commitment is down lower in the tree not at the top. This doesn't make any real functional difference but it answers your question about the root always being the same size.

> why does it matter if the signatures are hashed with the transactions or hashed separately?

Because when transactions specify which coins they are spending they refer to it by the txid. If the signature data is part of the txid then changes to the signature (like third party malleation or resigning) invalidate subsequent transactions. If the signatures are excluded from those txids this problem does not happen.


---

