<blockquote>
<p>What message could he send to the node to be confident that his valid block will be broadcast to the network and appended to the chain?</p>
</blockquote>
<p>You can never be confident. The node you connect to may be malicious, malfunctioning, or be badly connected itself. But you can certainly increase the odds of good propagation by sending your friend's block to as many nodes as possible.</p>
<blockquote>
<p>What should the format/encoding be?</p>
<p>What communication protocol(s) should he use?</p>
</blockquote>
<p>The Bitcoin P2P protocol has roughly three mechanisms for announcing new blocks to the network:</p>
<ul>
<li>The old <strong><code>inv</code> / <code>getdata</code> / <code>block</code> mechanism</strong>: you'd first send an <a href="https://en.bitcoin.it/wiki/Protocol_documentation#inv" rel="nofollow noreferrer"><code>inv</code></a> message, containing an <a href="https://en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors" rel="nofollow noreferrer">inventory item</a> of type MSG_BLOCK (2), and the block hash. The peer will then possibly request the actual block data (if they don't have it already) using a <a href="https://en.bitcoin.it/wiki/Protocol_documentation#getdata" rel="nofollow noreferrer"><code>getdata</code></a> message containing a similar inventory item with type MSG_BLOCK or MSG_WITNESS_BLOCK (depending on whether they want witness data). You will then respond by sending a <a href="https://en.bitcoin.it/wiki/Protocol_documentation#block" rel="nofollow noreferrer"><code>block</code></a> message containing the block header plus the transaction vector, in serialized format (the same format that transaction hashes are computed over). If the type in <code>getdata</code> was MSG_WITNESS_BLOCK, you are expected to include witnesses in the transactions, using the <a href="https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki#user-content-Serialization" rel="nofollow noreferrer">BIP144 encoding</a>. If the peer doesn't have the parent of your block yet, this may trigger fetches for ancestors, using <code>getdata</code> or <a href="https://en.bitcoin.it/wiki/Protocol_documentation#getheaders" rel="nofollow noreferrer"><code>getheaders</code></a> (which you'll be expected to respond to with a <a href="https://en.bitcoin.it/wiki/Protocol_documentation#headers" rel="nofollow noreferrer"><code>headers</code></a> message).</li>
<li>The <strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki" rel="nofollow noreferrer">BIP130</a> mechanism</strong>: when negotiated using the <code>sendheaders</code> message at connection time, blocks can be announced to peers using a <a href="https://en.bitcoin.it/wiki/Protocol_documentation#headers" rel="nofollow noreferrer"><code>headers</code></a> message instead of <code>inv</code>. This lets the peer ask for missing parent headers before actually getting the full block from you. The <code>getdata</code> and <code>data</code> steps of the previous approach remain unchanged in that case.</li>
<li>The <strong><a href="https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki" rel="nofollow noreferrer">BIP152</a> mechanism</strong> (compact blocks). The details of the actual protocol are too intricate to explain in a paragraph here, but the rough idea is to only hand (short) identifiers for each transaction in the block to the peer, who will then reconstruct the block on their own, and possibly ask for missing transactions.</li>
</ul>
<p>In certain cases, Bitcoin Core will also accept unsolicited blocks, namely just <code>block</code> messages sent to it without preceeding <code>getdata</code>. That's the easiest approach, but it's not guaranteed to work.</p>
<blockquote>
<p>Would the full node need any specific operating system configuration, or additional software, to facilitate this?</p>
</blockquote>
<p>All (honest) full nodes can validate and relay blocks to their peers. Obviously ones with more processing power, or better-connected networking, can do so faster.</p>
<blockquote>
<p>Incidentally, let's say that my friend would be particularly grateful for answers within ~10 minutes.</p>
</blockquote>
<p>Haha, sorry, too late!</p>

CC BY-SA 4.0
2024-05-09T12:43:04.447Z
2024-05-09T12:43:04.447Z
Pieter Wuille
<p>Let's say that, <a href="https://bitcoin.stackexchange.com/a/120592/34190">through a stroke of luck</a>, a friend has found a valid block on his laptop.</p>
<p>Let's say he knows the IP address of a remote Bitcoin Core full node.</p>
<p>What message could he send to the node to be confident that his valid block will be broadcast to the network and appended to the chain?</p>
<p>What should the format/encoding be?</p>
<p>What communication protocol(s) should he use?</p>
<p>Would the full node need any specific operating system configuration, or additional software, to facilitate this?</p>
<p>Are there any other approaches he could use?</p>
<p><strike>Incidentally, let's say that my friend would be particularly grateful for answers within ~10 minutes.</strike></p>

<full-node><p2p><peers><message><broadcast>
Broadcast a valid block to network, without a local full node
Lee
# Broadcast a valid block to network, without a local full node

(Asked by: username_0 on 2024-05-09)

Let's say that, [through a stroke of luck](https://bitcoin.stackexchange.com/a/120592/34190), a friend has found a valid block on his laptop.

Let's say he knows the IP address of a remote Bitcoin Core full node.

What message could he send to the node to be confident that his valid block will be broadcast to the network and appended to the chain?

What should the format/encoding be?

What communication protocol(s) should he use?

Would the full node need any specific operating system configuration, or additional software, to facilitate this?

Are there any other approaches he could use?

Incidentally, let's say that my friend would be particularly grateful for answers within ~10 minutes.

**Tags:** full-node, p2p, peers, message, broadcast


---

## 1 answers

### Answer by username_1 on 2024-05-09. Score: 3 | Accepted answer

> What message could he send to the node to be confident that his valid block will be broadcast to the network and appended to the chain?

You can never be confident. The node you connect to may be malicious, malfunctioning, or be badly connected itself. But you can certainly increase the odds of good propagation by sending your friend's block to as many nodes as possible.

> What should the format/encoding be?
>
> What communication protocol(s) should he use?

The Bitcoin P2P protocol has roughly three mechanisms for announcing new blocks to the network:

* The old **`inv` / `getdata` / `block` mechanism**: you'd first send an [`inv`](https://en.bitcoin.it/wiki/Protocol_documentation#inv) message, containing an [inventory item](https://en.bitcoin.it/wiki/Protocol_documentation#Inventory_Vectors) of type MSG\_BLOCK (2), and the block hash. The peer will then possibly request the actual block data (if they don't have it already) using a [`getdata`](https://en.bitcoin.it/wiki/Protocol_documentation#getdata) message containing a similar inventory item with type MSG\_BLOCK or MSG\_WITNESS\_BLOCK (depending on whether they want witness data). You will then respond by sending a [`block`](https://en.bitcoin.it/wiki/Protocol_documentation#block) message containing the block header plus the transaction vector, in serialized format (the same format that transaction hashes are computed over). If the type in `getdata` was MSG\_WITNESS\_BLOCK, you are expected to include witnesses in the transactions, using the [BIP144 encoding](https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki#user-content-Serialization). If the peer doesn't have the parent of your block yet, this may trigger fetches for ancestors, using `getdata` or [`getheaders`](https://en.bitcoin.it/wiki/Protocol_documentation#getheaders) (which you'll be expected to respond to with a [`headers`](https://en.bitcoin.it/wiki/Protocol_documentation#headers) message).
* The **[BIP130](https://github.com/bitcoin/bips/blob/master/bip-0130.mediawiki) mechanism**: when negotiated using the `sendheaders` message at connection time, blocks can be announced to peers using a [`headers`](https://en.bitcoin.it/wiki/Protocol_documentation#headers) message instead of `inv`. This lets the peer ask for missing parent headers before actually getting the full block from you. The `getdata` and `data` steps of the previous approach remain unchanged in that case.
* The **[BIP152](https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki) mechanism** (compact blocks). The details of the actual protocol are too intricate to explain in a paragraph here, but the rough idea is to only hand (short) identifiers for each transaction in the block to the peer, who will then reconstruct the block on their own, and possibly ask for missing transactions.

In certain cases, Bitcoin Core will also accept unsolicited blocks, namely just `block` messages sent to it without preceeding `getdata`. That's the easiest approach, but it's not guaranteed to work.

> Would the full node need any specific operating system configuration, or additional software, to facilitate this?

All (honest) full nodes can validate and relay blocks to their peers. Obviously ones with more processing power, or better-connected networking, can do so faster.

> Incidentally, let's say that my friend would be particularly grateful for answers within ~10 minutes.

Haha, sorry, too late!


---

