<blockquote>
<p>Suppose that the light client wants to retrieve the complete block number 1234. I've seen on the documentation the <code>getdata</code> message, which other nodes can reply with a block message.</p>
<p>Do you have any hints on how to evaluate how many bytes the light client must send for the <code>getdata</code> message and how many bytes must be received?</p>
</blockquote>
<p>It depends on how big the block is. The block is 0-1 MB prior to segregated witness activating, and 0-4 MB afterward. In general, the earlier the block is from, the less data it contains.</p>
<p>There's some overhead for the message header, but it's 24 bytes, so it doesn't really matter.</p>

CC BY-SA 3.0
2017-04-06T05:18:29.493Z
Ok thank you! Is my way of thinking about the exchanged messages correct ?
gatb27
CC BY-SA 3.0
2017-04-06T05:32:43.020Z
There's overhead for message framing, and keepalive messages. It's not exactly 80 bytes/10 minutes.
Nick ODell
CC BY-SA 3.0
2017-04-06T14:57:11.447Z
What is the best approximation we can do to evaluate this overhead?
gatb27
CC BY-SA 3.0
2017-04-05T15:13:12.677Z
2017-04-05T15:13:12.677Z
2020-06-16T11:10:03.350Z
Nick ODell
<p>I'd like to better understand how a light node can retrieve a complete node. If I understood correctly, I can consider a light node a node which is part of the peer-to-peer network that receives and stores only block headers, which means around 80 Bytes every 10 minutes (of course with some approximations).</p>

<p>Suppose that the light client wants to retrieve the complete block number 1234. I've seen on the documentation the <em><code>getData</code></em> message, which other nodes can reply with a <em><code>block</code></em> message. </p>

<p>Do you have any hints on how to evaluate <strong>how many bytes</strong> the light client must send for the getData message and how many bytes must be received? I think it could sufficient to retrieve only one block from the network since the light node can validate if this block is part of its local head-only-blockchain. </p>

<p>Thanks for the support :) </p>

<block><block-header><thin-clients>
How a Light Node can get a block?
gatb27
# How a Light Node can get a block?

(Asked by: username_0 on 2017-04-05)

I'd like to better understand how a light node can retrieve a complete node. If I understood correctly, I can consider a light node a node which is part of the peer-to-peer network that receives and stores only block headers, which means around 80 Bytes every 10 minutes (of course with some approximations).

Suppose that the light client wants to retrieve the complete block number 1234. I've seen on the documentation the *`getData`* message, which other nodes can reply with a *`block`* message.

Do you have any hints on how to evaluate **how many bytes** the light client must send for the getData message and how many bytes must be received? I think it could sufficient to retrieve only one block from the network since the light node can validate if this block is part of its local head-only-blockchain.

Thanks for the support :)

**Tags:** block, block-header, thin-clients


---

## 1 answers

### Answer by username_1 on 2017-04-05. Score: 0 | Accepted answer

> Suppose that the light client wants to retrieve the complete block number 1234. I've seen on the documentation the `getdata` message, which other nodes can reply with a block message.
>
> Do you have any hints on how to evaluate how many bytes the light client must send for the `getdata` message and how many bytes must be received?

It depends on how big the block is. The block is 0-1 MB prior to segregated witness activating, and 0-4 MB afterward. In general, the earlier the block is from, the less data it contains.

There's some overhead for the message header, but it's 24 bytes, so it doesn't really matter.

> **Comments:**
> **username_0**: Ok thank you! Is my way of thinking about the exchanged messages correct ?  
> **username_1**: There's overhead for message framing, and keepalive messages. It's not exactly 80 bytes/10 minutes.  
> **username_0**: What is the best approximation we can do to evaluate this overhead?  

---

