Topic: Multi-pass block validation (Read 622 times)

The excess would just be discarded.  The principle is that once transaction ordering has been established, the system doesn't need to rush working out the final/compacted block.

This means that miners can add transactions into blocks, even if they aren't sure if they have been spent yet. 

What happens if there are too many valid txs and are unable to fit in a bitcoin block?

Proof of publication systems require much less complex validation by miners.  Miners just need to check the merkle tree and the POW.  Invalid transactions don't invalidate the block.

This allows stream validation of blocks.  You can start forwarding the block to your peers even before receiving the complete block.  Miners should not build on a block until it is fully received though.

Even SPV nodes could help with proof of publication block forwarding (if the smartphone was charging overnight and had a wireless link).

Proof of publication assumes that >50% of miners are 'honest'.  In this context, it means that they will not build on a block that they have not seen in its entirety and also that they will make the blocks available publicly.

This gives an ordering of transactions (including invalid ones).  A full node would scan all the transactions, in order, and simply discard any invalid ones.

With this system, SPV nodes can't assume that the transactions in the block are valid.  Proving a transaction exists doesn't mean that the transaction is valid.

With a multi-pass system, SPV clients can get some of the benefits restored and historical blocks wouldn't need to store invalid transactions.

This could be implemented as a soft fork.

Each bitcoin block would store the hash of the proof of publication block that is 16 blocks ahead of it.

The bitcoin block can be pre-computed and the hash added to its coinbase.  If you know the publication chain, you can work out the bitcoin block.

Miners just mine the proof of publication chain and naturally produce standard bitcoin blocks that are consistent with the proof of publication chain.  Miners have over 2.5 hours to work out what transactions are in the proof of publication block.

The tail of the bitcoin chain would be 2.5 hours behind the publication chain.  If your transaction gets into the publication chain, then you know it will end up in the bitcoin chain.  Legacy clients would have to wait 2.5 hours though.

The proof of publication blocks would only need to be held for a short time, so they could have a higher size limit.  This would allow miners to include more transactions than are necessary into the block and repeats would be automatically discarded as part of generating the bitcoin block.

For transactions that are more than 2.5 hours old, SPV nodes can check the bitcoin chain.  For newer transactions, they have to trust their peers not to give them invalid information.

If they checked with 8 peers for an outpoint, then at least one of them would probably send the first time that output was spent.  This gives them some double spend protection. 

The proof of publication chain could be arranged to run faster than the bitcoin chain.  Hitting the lower difficulty target advances the proof of publication chain, while hitting the standard bitcoin difficulty advances the bitcoin height and the proof of publication chain height).  Something like the Nimblecoin system could be used to drop the block rate to a few seconds.

If miner fees are out of channel (like a payment channel), miners don't even need to check if the transaction is valid.  Block space is auctioned, which protects against a DoS attack.

Normal fees still work though and even with mini-blocks, the calculated bitcoin block could share the mint fee between all miners on the publication chain.