Topic: Block propagation latency with Odd/Even transaction outputs (Read 1440 times)

The advantage is that nodes can have new blocks ready well in advance of when a block is found.

You can create block number 300,002 once block 300,000 is found.  This makes it possible to quickly switch to the new block when a block is found.

The current process means that nodes have to update their memory pools with the new block (delete all the transactions) and then generate a new block with the transactions that are left.

This is slow and can't really be done in a distributed way.


A transaction with even inputs and odd outputs could be spent in the next block.  Each address could only receive transactions every 2nd block.


Yes, if 2 blocks are found once after another then the problem still occurs, but that is less often.

A less complex system would be if pools had a way to tell miners that they have no block ready.



-> Send message to all miners to cancel the current block



-> Send info to miners to build on the new block

This would mean that if a pool was slow to update, their miners could switch to a backup pool while they generate a new block.

This would allow high latency pools to compete.

TierNolan

Please explain the benefits of this?  I don’t understand why this helps.  Under IBLT miners can begin work on the next block as soon as they are able to reconstruct the previous one, they don’t need to receive the full block.

Under your proposal I assume there is a rule that one needs to wait at least 2 blocks before spending a new output again?  Will this not make Bitcoin quiet slow?

Will there still not be a propagation problem occurring if two blocks are found quickly?  Why not increase the number of groups to 10 and have a target time of 1 minute?

Your wallet could be all even or all odd.  When you ask for an address, it can check if it gives even/odd and discard it if it is the wrong parity.

This gives a longer wait until first confirm (half of the time) but the time until 6 confirms is only increased from 60 minutes to 70 minutes.

You can send all your even-coins to an odd output to make odd-coins.


I meant you could have the block almost completely ready.  You could compute the merkle root. 

You would need to update the header to add the prev block (and the path to the coinbase to handle the extra-nonce)

The key point is that when a new block arrives, it invalidates lots of transaction outputs.

This means that if you have a block ready, you have to scan it and drop all transactions that depended on those outputs.

But, if the next block is only allowed to spend even outputs and you can create a block which contains only odd transactions, then no matter what transactions are in the next block, they can't invalidate any of the transactions in the block you have ready.


They would have to broadcast a valid header that meets POW. 

Each miner would be mining against one block and have the next block ready.

When a miner finds a valid nonce, they instantly forward the block header to all peers who forward it onward.  This doesn't require checking that the block is ok, just the header.

This is not recommended currently, since it creates an incentive for the miner to withhold the full block.  With this system, there is lots of time for the miner to send on their block.

When a miner receives the header, they can instantly update the prev field in their "next" block header and begin mining on that block.

I suggest the rules

- mine on the longest chain
- if tied, mine on the full block received earliest
- if tied, mine on the header received earliest

Picking the low hanging fruit - so then I can't spend my money. I've received .5 "even" and .5 "odd" into my wallet, neither of which were under my control. Now I want to pay 1 to a single party.


Have it ready how? A block work still needs to include the hash of the previous block. Miners could be duped into flushing their work and working on the wrong parity by malicious header broadcasts. Maybe you should define what you mean by this.

You seem to be mixing your definitions for odd block/transaction/address etc.

Yes, that is the tradeoff.  The advantage is that it eliminates (or at least greatly reduces) the benefit of having extremely low latency connections to other miners.

This will increase, if not double, the time for first confirmation. At least it will increase the variance of confirmation time

The main benefit of the IBLT system is that it allows fast propagation of blocks.  It doesn't reduce the average bandwidth required for a node (well 50% reduction).  It reduces the amount of low latency bandwidth required for a node.

Miners need to receive the new block before they can produce the subsequent block.  This dead time results in lost hashing power.

New blocks cannot be produced in advance, since any transactions in that block might be invalidated when a miner finds the next block.

I suggest adding a new soft-fork rule. 

- Each UTXO is designated odd or even based on the LSB of hash(scriptPubKey) for that output
- All inputs into a transaction must be either all odd or all even (giving an odd or even tx)
- Blocks are considered odd/even based on the LSB of their height
- Odd blocks can only contain odd txs and vice versa

This means that the UTXO set will be split into 2 subsets.  If the next block is even, then it will not be able to spend any of the UTXOs in the odd subset.  Since the block after it will be odd, miners can create a block containing all odd transactions and have it ready.

Once a miner hits a block, they broadcast their header only and all miners can instantly switch to a full length block.    The miner can then broadacst their block and will have on average 10 minutes to send it.

IBTL could still be used for actual distribution.

Wallets could be setup to only produce odd or even addresses.  If all your addresses are even, then you don't lose much by the system.  You just produce transactions as normal.  50% of the time, you have to wait an extra block for your tx to be included.  The parity of outputs can be swapped by sending them to an output of the other parity.

If this was an issue, the wallet could store some of its funds in the other parity.  Wallets would ideally randomly pick one or other as its primary parity.