Topic: Allowing new blocks to be prepared ahead of time (Read 717 times)

That is only if you use the 8X parity system.

If you just use odd/even system, then there is a 50% chance your tx will be eligible to be included in the next block and, if not, will be eligible to be included in the one after that.

Having said that, in the short term, the best plan for a p2p miner would be to just mine a block with just a coinbase until it has a verified block that links to the new best block.


The idea is that for a p2p verification system, you need some settling time.  Basically, you have proof that the block is valid, but verification is split over many nodes.

If you have all the proof, then you can verify that the block is ok, but that is pretty much having the entire block anyway.

However, if you break up the proof with something like a merkle tree, then you can share verification.

So, someone says that is a group of txs with a tx fee of 0.5123 bitcoins.

It is easy to show a node in the tree is invalid by showing the path down the tree.  However, proving that a node is invalid requires that node + its children.  So by withholding the children, you can prevent the proof.

If verification is spread out, then anyone can post that proof and it should flood to all nodes quickly.

So, the proof of corruption would be

-> (path to node) ->    + claim(children don't exist)

All blocks can verify that, but how to prove the children are not available.  That inherently requires giving the network time to get the children.

80 minutes for first confirmation is going to go down real well with the we want it naow, naow,, naow generation.

Nice idea, even elegant, but getting the masses to put up with ten minute blocks already led to at least two altchains with faster block times.

-MarkM-

I'm going to take a guess that this will open nodes up to an attack where fake blocks are promised, but not delivered.

Under the current rule, you can't create new blocks ahead of time.  Once the new block is announced, you have to download and verify it before you can start hashing against the one after that.

If you have a list of 100 verified transactions that you intend to include in the next block, once the new block is found, you have to remove any transactions that have been invalidated.

This makes it harder for peer to peer miners to coordinate on the next block.  If the verification was handled in a distributed way, then it might not be possible to re-verify the new block with low latency. 

If a rule was added that restricted the allowable TXOs that could be included in a block, then this problem is greatly reduced.

The easiest example would be that you can only include TXOs from transactions that hash to even values in even numbered blocks and vice-versa for odd numbered blocks.

This is a soft fork, since it makes currently valid blocks invalid.  This means that it could be implemented as long as >50% of miners supported it.

This means that if the next block was even, then a block with all odd TXOs could be prepared and verified, in advance, and all peers could have it ready to hash as soon as the switch happens.  Since the next block was even, odd TXOs would be guaranteed to not to be spent.

It would mean that "parity-change" transactions would be needed, if you want to combine transactions of opposite parity.  You create a transaction that has 1 input and 1 output, but the hash has the opposite parity to the input.  This would be easy with a small nonce in the transaction.  A var_int nonce would be 1 byte in almost all cases.

This isn't as big an inconvenience as it would seem.  A wallet could be setup to keep all of its TXOs the same parity.

On average you would need to wait 0.5 blocks extra for confirmations, since half the time, the next block wouldn't be accepting you transaction.  It spreads confirmation over 2 blocks, so wouldn't make any difference to the required block size.

This also helps with the MAX_BLOCK_SIZE debate.  Smaller miners would have the full 10 minutes (or whatever the next block takes) to download and verify the new block.

The process could be
1) wait for header for current block (81 byte payload)
2) verify header, goto 1) on failure
3) switch mining to prepared next block
4) download and verify full current block
5) If failed, switch mining back and goto 1)
6) prepare next block based on verification and goto 1)

This can be extended to even longer time by using more than 1 bit.  If 3 bits were used, then there would be 8 different "parities", but again your wallet could keep all your outputs the same parity.  This would give up to 8 block intervals before the tx can be included in a block.