Proposal: Mini-blocks for network split detection

[Sergio_Demian_Lerner]

Last week I read in a thread about how mini-blocks (blocks with less PoW generated during mining and no list of transactions included) could be used to switch faster between best chains and reduce orphan block rate.
The idea of min-blocks is particularly interesting to me, since it could also help detecting if the network is split. More precisely if the user has been disconnected from a set of miners with a high percentage of the network hashing power. This method won't detect colluding malicious miners, just an accidental split of the network or an split attack performed by a party controlling the links of a node.

So the idea is...

When the miner finds a solution to the block with PoW >= 1/20 of the target , but still not high as the target, the miner publishes the block-header. Now nodes will receive approximately 2 mini-blocks per minute, and they can keep track of the current hash rate. At any time, if the rate of mini-blocks per minute (counted in an average of 1 hour) drops to less than a half, then the client application warns the user he has been disconnected from half of the mining power. The user may check in forums if this disconnection is because an earthquake has happened or anything, and decide if he's under an targeted attack or not.
(Obviously it is required to compute the probability of the node detecting a half-drop when there is none, and adjust the window time and the mini-block rate so this is very uncommon).

Also a modification of the idea could be used to check the number of distinct miners in the network:

Let Kpriv,Kpub a miner's special purpose ECDSA private/public key.

In each block, the miner also includes in the coinbase field a value x computed as x = Sign(KPriv,r),  where r is a random message.

When the miner finds a solution to the block with PoW >= 1/20 of the target , but still not high as the target, the miner publishes the tuple (block-header,KPub,r), and choses another r to continue mining.

Now everybody can verify that the min-block came from the identity that owns Kpub by checking that CheckSig(Kpub,x,r)==true.
(here I'm assuming ECDSA resists a special kind of malleability)

If the miner finds a solution to the target PoW, he does not publish his identity (the values KPub and r). Since x is worthless without knowing r, nobody can know for sure who is the creator of the block.

At any time, the nodes can infer the number of distinct active miners and inform the user about any pattern that matters to the security and stability of the network.

Opinions?

[1714762303]

1714762303

[coinft]

The idea is interesting, but I think I don't fully understand it, or there's a flaw: without the full block with TXs, how can everyone else verify the PoW is within 1/20 of the required one?

[jl2012]

The idea is interesting, but I think I don't fully understand it, or there's a flaw: without the full block with TXs, how can everyone else verify the PoW is within 1/20 of the required one?

all you need is the block header to verify

[coinft]

The idea is interesting, but I think I don't fully understand it, or there's a flaw: without the full block with TXs, how can everyone else verify the PoW is within 1/20 of the required one?

all you need is the block header to verify

How exactly? The header contains (loosely) the hash over all the TXs in the block and the previous block hash. Without the TXs themself how can I verify the hash?

[TierNolan]

How exactly? The header contains (loosely) the hash over all the TXs in the block and the previous block hash. Without the TXs themself how can I verify the hash?

No the header is 80 bytes.  32 bytes of that is the merkle root.  That is part of the header and isn't affected by the nonce.

You can verify POW without anything else.  That is the whole point of the system. 

If you hash the header and get a number that is less than 20 times higher than the normal target, then it is within 20 of the required POW.

[coinft]

No the header is 80 bytes.  32 bytes of that is the merkle root.  That is part of the header and isn't affected by the nonce.

You can verify POW without anything else.  That is the whole point of the system. 

If you hash the header and get a number that is less than 20 times higher than the normal target, then it is within 20 of the required POW.

OK understood.

[leijurv]

Sounds like a good idea. So these mini-blocks would only contain the time, the previous block hash, and the nonce? Would they also contain the previous mini-block hash or just the previous normal block hash? I am assuming that you would expect miners to choose the chain with the most mini-blocks in the case of a fork? That makes a lot of sense.

[TierNolan]

Sounds like a good idea. So these mini-blocks would only contain the time, the previous block hash, and the nonce? Would they also contain the previous mini-block hash or just the previous normal block hash? I am assuming that you would expect miners to choose the chain with the most mini-blocks in the case of a fork? That makes a lot of sense.

The proposal here is to just use it to determine total network power.

In my thread (referenced in the OP, but not linked), the proposal was to have miners count the number of mini-blocks confirming each full block and then use that to break ties.  This would move the majority of the network hashing power onto a single block much faster than the current system (when 2 blocks are found at around the same time).

The current system waits until the next block happens before breaking the tie.

[leijurv]

Sounds like a good idea. So these mini-blocks would only contain the time, the previous block hash, and the nonce? Would they also contain the previous mini-block hash or just the previous normal block hash? I am assuming that you would expect miners to choose the chain with the most mini-blocks in the case of a fork? That makes a lot of sense.

The proposal here is to just use it to determine total network power.

In my thread (referenced in the OP, but not linked), the proposal was to have miners count the number of mini-blocks confirming each full block and then use that to break ties.  This would move the majority of the network hashing power onto a single block much faster than the current system (when 2 blocks are found at around the same time).

The current system waits until the next block happens before breaking the tie.

Ah. Thanks.

[jl2012]

Sounds like a good idea. So these mini-blocks would only contain the time, the previous block hash, and the nonce? Would they also contain the previous mini-block hash or just the previous normal block hash? I am assuming that you would expect miners to choose the chain with the most mini-blocks in the case of a fork? That makes a lot of sense.

The proposal here is to just use it to determine total network power.

In my thread (referenced in the OP, but not linked), the proposal was to have miners count the number of mini-blocks confirming each full block and then use that to break ties.  This would move the majority of the network hashing power onto a single block much faster than the current system (when 2 blocks are found at around the same time).

The current system waits until the next block happens before breaking the tie.

As an experiment, I think it is good to first implement it as a voluntary system like OP, and make it mandatory when we have more data

[TierNolan]

As an experiment, I think it is good to first implement it as a voluntary system like OP, and make it mandatory when we have more data

Sounds reasonable.  The only protocol change would be to allow block headers to be forwarded if they meet a lower POW target.

[Shevek]

In different context, I've thought a scheme involving ECDSA signing in the PoW. So, I know what you mean and it looks great (a deeper insight is needed although).

The aim of my idea is to block out the collaborating mining (the pools), who centralized the network.

Sometime I'll post the full idea in other thread...