1

Let's say that, through a stroke of luck, 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.

1 Answer 1

3

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 message, containing an inventory item 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 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 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. If the peer doesn't have the parent of your block yet, this may trigger fetches for ancestors, using getdata or getheaders (which you'll be expected to respond to with a headers message).
  • The BIP130 mechanism: when negotiated using the sendheaders message at connection time, blocks can be announced to peers using a 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 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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.