<p>"Full protection" is a relative term.  TCP packets include only a simple checksum, effectively just the sum of all the 16-bit words in the packet.  See RFC 793 section 3.1.  This is a fairly weak integrity protection mechanism.  The Bitcoin designers may have felt the use of sha256 gave better protection.  It may also, as you say, have been intended to provide forward compatibility for running Bitcoin over UDP or other protocols.  It may even just have been paranoia.</p>

CC BY-SA 3.0
2014-03-02T15:04:06.330Z
But this weak protection is good enough for other sensitive protocols like FTP and HTTP? They don't include checksums, right? (HTTPS/SFTP does of course, but just plain FTP/HTTP errors could be disastrous too). Thanks for answering though :)
Jori
CC BY-SA 3.0
2014-03-02T15:15:32.343Z
@jori It's not necessarily good enough, but it's what we've got.
Nate Eldredge
CC BY-SA 3.0
2014-03-02T15:26:33.487Z
I'm going to research the TCP checksum capabilities a bit further and then post back as I cannot believe the designers deliberately choose a bad schema for such an important task. It would be disastrous if using some executable file send across the network using FTP, resulted in unexpected.behavior.
Jori
CC BY-SA 3.0
2014-03-02T15:39:38.303Z
@jori: Bear in mind that the design is almost 40 years old, and it was important that the checksum be easy to compute on primitive hardware. CRCs were probably considered but rejected as too expensive, and our modern cryptographic hashes had not been invented.
Nate Eldredge
CC BY-SA 3.0
2014-07-31T16:23:42.137Z
Bitcoin originally didn't have this checksum, but Satoshi was having a lot of trouble with various garbled packets on the network, so he added it. It's better than the TCP checksum, and it also covers cases where bad data is sent to the socket. See the post [here](https://bitcointalk.org/index.php?topic=56272.msg669898#msg669898) starting with "I'll take a look a the logs."
theymos
CC BY-SA 3.0
2014-07-31T20:17:17.063Z
@theymos: Thanks for the history.  Since this feature doesn't affect the block chain, it could easily be added without risking a fork.
Nate Eldredge
CC BY-SA 3.0
2014-03-01T18:50:15.430Z
2014-03-01T18:50:15.430Z
Nate Eldredge
<p>According to the <a href="https://en.bitcoin.it/wiki/Protocol_specification#Common_structures" rel="nofollow">protocol specification</a> at the Bitcoin wiki, each message header includes the  <em>first 4 bytes of sha256(sha256(payload)</em> as a packet checksum. I suppose this checksum is used for packet validation, but I do not see any benefit of this, as Bitcoin utilizes TCP which already has (as far as I know) full protection from lost and damaged  packets. So... why this checksum? Is it to maintain compatibility for future UDP clients?</p>

<security><tcp><protocol>
What is the function of the payload_checksum field in the Bitcoin protocol
Jori
# What is the function of the payload_checksum field in the Bitcoin protocol

(Asked by: username_0 on 2014-03-01)

According to the [protocol specification](https://en.bitcoin.it/wiki/Protocol_specification#Common_structures) at the Bitcoin wiki, each message header includes the *first 4 bytes of sha256(sha256(payload)* as a packet checksum. I suppose this checksum is used for packet validation, but I do not see any benefit of this, as Bitcoin utilizes TCP which already has (as far as I know) full protection from lost and damaged packets. So... why this checksum? Is it to maintain compatibility for future UDP clients?

**Tags:** security, tcp, protocol


---

## 1 answers

### Answer by username_1 on 2014-03-01. Score: 2

"Full protection" is a relative term. TCP packets include only a simple checksum, effectively just the sum of all the 16-bit words in the packet. See RFC 793 section 3.1. This is a fairly weak integrity protection mechanism. The Bitcoin designers may have felt the use of sha256 gave better protection. It may also, as you say, have been intended to provide forward compatibility for running Bitcoin over UDP or other protocols. It may even just have been paranoia.

> **Comments:**
> **username_0**: But this weak protection is good enough for other sensitive protocols like FTP and HTTP? They don't include checksums, right? (HTTPS/SFTP does of course, but just plain FTP/HTTP errors could be disastrous too). Thanks for answering though :)  
> **username_1**: @username_0 It's not necessarily good enough, but it's what we've got.  
> **username_0**: I'm going to research the TCP checksum capabilities a bit further and then post back as I cannot believe the designers deliberately choose a bad schema for such an important task. It would be disastrous if using some executable file send across the network using FTP, resulted in unexpected.behavior.  
> **username_1**: @username_0: Bear in mind that the design is almost 40 years old, and it was important that the checksum be easy to compute on primitive hardware. CRCs were probably considered but rejected as too expensive, and our modern cryptographic hashes had not been invented.  
> **username_2**: Bitcoin originally didn't have this checksum, but Satoshi was having a lot of trouble with various garbled packets on the network, so he added it. It's better than the TCP checksum, and it also covers cases where bad data is sent to the socket. See the post [here](https://bitcointalk.org/index.php?topic=56272.msg669898#msg669898) starting with "I'll take a look a the logs."  
> **username_1**: @username_2: Thanks for the history.  Since this feature doesn't affect the block chain, it could easily be added without risking a fork.  

---

