Post
Topic
Board Development & Technical Discussion
Re: How a floating blocksize limit inevitably leads towards centralization
by
TierNolan
on 27/02/2013, 17:09:55 UTC
But the miners would still need to check those blocks, and eventually so would everyone else.  This could introduce a new network attack vector.

I think miners are going to need to verify everything, at the end of the day.  However, it may be possible to do that in a p2p way.

I made a suggestion in another thread about having "parity" rules for transactions. 

A transaction of the form:

Input 0: tx_hash=1234567890/out=2
Input 1: tx_hash=2345678901/out=1
Output 0:

would have an mixed parity, since the it its inputs come from some transaction with an odd hash and some with an even hash.

However, a parity rule could be added that requires either odd or even parity.

Input 0: tx_hash=1234567897/out=0
Input 1: tx_hash=2345678901/out=1
Output 0:

If the block height is even, then only even parity transactions would be allowed, and vice-versa for odd.

If a super-majority of the network agreed with that rule, then it wouldn't cause a fork.  Mixed parity blocks would just be orphaned.

The nice feature of the rule is that it allows blocks to be prepared in advance.

If the next block is an odd block, then a P2P miner system could broadcast a list of proposed transactions for inclusion and have them verified.  As long as all the inputs into the proposed transactions are from even transactions, they won't be invalidated by the next block.  It will only have transactions with inputs from odd transactions, under the rule.

This gives the P2P system time to reject invalid transactions.

All nodes on the network could be ready to switch to the next block immediately, without having to even read the new block (other than check the header).  Verification could happen later.