Forwarding from IRC since the requester dropped off and the info may be
useful to others on the list.

e

[12:08] <fpelliccioni> Hello!
[12:10] <fpelliccioni> Hi Eric, hi guys...
[12:10] <fpelliccioni> Eric, I am Fernando
[12:10] <fpelliccioni> I am implemeting some mining methods...
[12:10] <fpelliccioni> I need to implement the ¨submitblock¨
method/message
[12:11] <fpelliccioni> Do you know what is the simplest way to inject a
block into libbitcoin? via libbitcoin-node? libbitcoin-blockchain?
[12:12] <fpelliccioni> I need the block to be stored and transmitted to the
BTC-P2P network
[14:44] <evoskuil> fpelliccioni: Hi Fernando
[14:44] <evoskuil> ingenius: maybe you can relay to fernando, looks like he
dropped off after posting...
[14:45] <evoskuil> Block submission (like tx submission) would be properly
implemented in the client/server interface.
[14:46] <evoskuil> The naive approach is to simply add a block message that
works just like the tx message.
[14:46] <evoskuil> The block would then be accepted by the node in the same
manner that the tx is accepted presently.
[14:47] <evoskuil> This would only take a few minutes for me to implement.
In fact I did so already but then pulled it out.
[14:47] <evoskuil> The simple/naive approach has certain deficiencies in the
mining scenario.
[14:48] <evoskuil> First, you don't want block submission, you want a merkle
block.
[14:48] <evoskuil> You would prefer that the merkle block was generated from
the same node/server, so that you know it will have all of the txs.
[14:49] <evoskuil> Libbitcoin-node does not ever lose unconfirmed
transactions (unless the store is rebuilt).
[14:50] <evoskuil> That ensures that the merkle block will validate as long
as it is well formed.
[14:50] <evoskuil> Sending a full block also works, but it is much more
costly to validate (in relative terms, the numbers are both small, but this
matters).
[14:52] <evoskuil> The node would not announce the block to peers unless it
had validated it and stored it, otherwise the peer would not be able to
retrieve it.
[14:53] <evoskuil> This aspect is already implemented, so the trick is to
just get the merkle block (or block) into the validation process.
[14:57] <evoskuil> That would be implemented in the server's merkle/block
message handler(s) by a call to node.chain().organize(block, handler)
[14:58] <evoskuil> Upon handler invocation the message response is sent to
the client including any validation error (just as with .organize(tx,
handler)).
[14:59] <evoskuil> I would start with the naive (block) approach given that
merkle block validation is not yet fully implemented in the node.
[15:00] <evoskuil> This is planned work to accompany the compact blocks
protocol implementation, as a compact block is just a weaker merkle block.
[15:00] <evoskuil> Once the node validates merkle and     compact blocks, the
server interface can then easily be extended to accept a merkle block.
[15:02] <evoskuil> Finally, even the merkle block approach is not fully
optimal. Ideally you want the server to issue a block header on which to
mine...
[15:04] <evoskuil> and for the server to cache the headers it has issued.
that would allow the miner to submit the mined header only (ie without the
merkle block's list of hashes).
[15:05] <evoskuil> The server would then validate the header (only) and
would not even need to look at the hashes.
[15:06] <evoskuil> This is much more than eliminating the tx hash list from
the traffic, this eliminates the need to look anywhere beyond the header
validation, which is trivial.