<p>This is an implementation detail; it is up to you.</p>
<p>The short transaction ID is a 48-bit number, obtained by computing the SipHash-2-4 (a 64-bit number) as described in those documents, and setting the top two bytes (= 16 bits) to 0.</p>
<p>How you then store those 48 bits is up to you. You can store them in 6 bytes, or in a 64-bit integer type (as actual computer hardware generally doesn't have 48-bit integers as a native thing) whose top 16 bits will be 0.</p>
<p>In the BIP152 protocol message <code>cmpctblock</code> they are sent as 6-byte encodings.</p>

CC BY-SA 4.0
2023-12-22T14:57:13.923Z
Fine, but what about serializing and sending messages like this in reality? There must be some approach adopted by the majority (following Bitcoin core). Is append done during serialization or not (per Bitcoin core)?
Cosmos
CC BY-SA 4.0
2023-12-22T15:03:22.160Z
I've amended my answer to address that.
Pieter Wuille
CC BY-SA 4.0
2023-12-22T14:53:50.273Z
2023-12-22T14:53:50.273Z
Pieter Wuille
<p><a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow noreferrer">BIP152</a> says not to append two null bytes on Short transaction ID, but <a href="https://developer.bitcoin.org/reference/p2p_networking.html" rel="nofollow noreferrer">Bitcoin for developers</a> says to append.</p>
<p>Algorithm for calculating Short transaction ID in BIP152 (<a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#short-transaction-ids" rel="nofollow noreferrer">link</a>):</p>
<blockquote>
<p><a href="https://i.sstatic.net/Lsp41.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/Lsp41.png" alt="enter image description here" /></a></p>
</blockquote>
<p>Algorithm for calculating Short transaction ID in Bitcoin.developer ([link](Are two null bytes appended to the end of the Short Transaction ID?)):</p>
<blockquote>
<p><a href="https://i.sstatic.net/yFiYl.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/yFiYl.png" alt="enter image description here" /></a></p>
</blockquote>
<p><strong>Should we do append or not?</strong></p>

<message>
Are two null bytes appended to the end of the Short Transaction ID?
Cosmos
# Are two null bytes appended to the end of the Short Transaction ID?

(Asked by: username_0 on 2023-12-22)

[BIP152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) says not to append two null bytes on Short transaction ID, but [Bitcoin for developers](https://developer.bitcoin.org/reference/p2p_networking.html) says to append.

Algorithm for calculating Short transaction ID in BIP152 ([link](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki#short-transaction-ids)):

> [![enter image description here](https://i.sstatic.net/Lsp41.png)](https://i.sstatic.net/Lsp41.png)

Algorithm for calculating Short transaction ID in Bitcoin.developer ([link](Are two null bytes appended to the end of the Short Transaction ID?)):

> [![enter image description here](https://i.sstatic.net/yFiYl.png)](https://i.sstatic.net/yFiYl.png)

**Should we do append or not?**

**Tags:** message


---

## 1 answers

### Answer by username_1 on 2023-12-22. Score: 1 | Accepted answer

This is an implementation detail; it is up to you.

The short transaction ID is a 48-bit number, obtained by computing the SipHash-2-4 (a 64-bit number) as described in those documents, and setting the top two bytes (= 16 bits) to 0.

How you then store those 48 bits is up to you. You can store them in 6 bytes, or in a 64-bit integer type (as actual computer hardware generally doesn't have 48-bit integers as a native thing) whose top 16 bits will be 0.

In the BIP152 protocol message `cmpctblock` they are sent as 6-byte encodings.

> **Comments:**
> **username_0**: Fine, but what about serializing and sending messages like this in reality? There must be some approach adopted by the majority (following Bitcoin core). Is append done during serialization or not (per Bitcoin core)?  
> **username_1**: I've amended my answer to address that.  

---

