I haven't fully thought it through, but don't forget that although a fork only takes 10 seconds to resolve in your scheme, forks happen a whole ton more often. I don't know what all the terms add up to, but it wouldn't surprise me if this turned out to cause miners to spend more time mining on forks than less. Especially as you lower that average-time-between-blocks closer to the average header propagation time. I don't know what propagation times are, but if they were on average 30s to reach 99% of the network, you could have X% (X>10) of the network always mining on [soon-to-be] dead chains.
They aren't actually chains. They are just counters for all potential orphans. If there is a tie, mine against the block with the most mini-confirms (though 16 mini-confirms is equal to 1 full block).
Propagation of the block headers should be very fast. All you need to do is verify that the prev hash link points to a header within the last 100 blocks (including side chains) and then check that it meets 1/64 of the POW. That is a hashmap lookup and a hash, and then send 80 bytes to all peers.
If there is a 5% orphan rate now, then this would only have an effect 5% of the time. In that 5% of the time, you are just recording the number of mini-confirms for the 2 potential blocks.
At the very least it would lower the effective hashrate, making the network more vulnerable.
I don't see why. If 100% of the network agrees on the next block, then this has no effect.
If it is split 2-1, then it should move the 33% over to the 67% side more quickly.
Having said that, there isn't that massive an incentive to switch. Unless you are 16 mini-confirms behind, your next full block will still break the tie.
If you have 4 groups of 25 units each mining on different forks, an attacker only need 26 to outpace it, even though the total network hashrate is the same.
This is about having those 4 groups agree on which of the 4 to all mine on. The mini-confirms are a notification to the rest of the network that that block is being mined against.
Satoshi picked 10 minutes, because he was concerned about the network dynamics of slow block propagation and what dragons it would create. He picked 10 minutes to be conservative, knowing that if it's long enough to absolutely be sure that propagation can happen reliably and consistently. Though I don't have any links off-hand to previous discussions about that. I'd be curious to re-read it myself.
This is not about reducing the block time to 10 seconds. This is having headers being sent (not forming chains) to indicate where the rest of the network is mining, when two blocks are found close enough to split the network hashing power.
There is no verification of signatures or anything, just an 80 byte header.
Though, I'm going off on a tangent: your idea doesn't rely on 10s... it can be calibrated to whatever is "safe."
I don't see any issue with going even lower than 10. However, the benefits are limited, since you still need 1 full block confirmation.
I do like the gist of the idea, since we already know that safety is basically a asymptotically increasing as the number of confirmations goes up, so if you can get the first couple confirmations out the door immediately 64 mini-confirmations would most definitely be better than 1 regular confirmation.
Well, it doesn't speed up the first confirm, since the mini-confirms aren't actually blocks. It just makes it much less likely that a block would be randomly reversed.
1 full confirm and then 20-30 mini-confirms would be highly unlikely to be reversed.
Miners have an incentive to always mine on a block that is within 16 mini-confirms of the block with the most mini-confirms.
This means that a block that is more than 16 mini-confirms ahead of any other block is likely to have 100% of the hashing power on that block.
The recommendation could be 1 full block + 32 mini-confirms to give a high safety margin. That is 15 minutes instead of 1 hour to get a high degrees of safety.
