<block_header>
ref_block = <block_hash_reference>
add_txs = <list of transactions to be added>
rm_txs = <list of transactions to be removed>
Pretty much the same as I suggested. However, it is smaller just to have
<index>, <new hash>
Since, any new hash will either replace an old one or extend the chain.
you could have
<index>, <000....000>
to mean delete.
Right. The concept holds. How it's encoded is less important.
Nodes would then cache the last <cache time> seconds of blocks, and they would be able to reconstitute the complete block from blocks in the cache by adding the transactions <add_txs> and removing the transactions <rm_txs> from <block_hash_reference>.
That assumes the new miner is the same as the old one.
No that's not necessary as far as I can see. You simply have a module which gets blocks above or equal to 1/600th of the difficulty submitted to it. This module simply keeps the last full block template or set of block templates in memory, and figures out which of the previous templates to publish a diff against. So it quickly calculates which of the templates from the last 60 seconds would give the smallest message size if a diff was produced against it, and publishes this to the network.
But as you mention, the 60 second cache time isn't really necessary if nodes can just ask for the last
n block templates when they connect to the network.
If we assume a 1 MB block size
That's 1.7kB/s
and 300 bytes per transaction, that's around 3500 transaction hashes of 32 bytes each, every 60 seconds.
That's double relative to just downloading the chain and people are already complaining about it.
I think you are misunderstanding me.
If each block can be no larger than 1 MB, then if we assume each transaction is 300 bytes, then it contains around 3500 transactions.
Publishing the hash, 32 bytes each, of 3500 transactions is 109 KB. But the block is not 1 MB right after a new block is found. It starts out being very small, so that the full block templates are small right after a new block is found, and get larger and larger until the next block is found. That's why I assume they are, on average, only 50% of 109 KB.
I don't think clearing the cache every minute is a good plan. Better to keep it for at least 1-2 blocks length.
Yeah that makes sense. If new nodes can just connect and request full block templates, then there's no need to have a short cache time.
I was originally thinking it would be a "broadcast only"-protocol, so that miners just broadcast partial confirmations and they cascade throughout the network through the other peers. This keeps traffic down, but it means that new nodes need to wait until their cache contains the relevant full block templates in order to verify blocks.
A miner sees a header and notices it has a hash that the miner doesn't have, so it asks his peers for it. It would also show evidence of double spending.
Yes this is interesting too. It means that unless miners are deliberately mining double spends, it will be easier for the miners to find and resolve double spends.