Faster block rates with DECOR protocol

[Sergio_Demian_Lerner]

Hi!

I wish you take a look at a new protocol I proposed to achieve high block rates and tell me your opinion.
I think it competes or maybe outperforms the GHOST protocol, but I have done no simulations to verify it. I will test it in my http://NimbleCoin.com cryptocurrency and see what happens.

This is my post: http://bitslog.wordpress.com/2014/05/02/decor/

Best regards,
 Sergio.

[TierNolan]

What about just paying the parent and uncle block an equal amount.  They have both contributed the same to the POW of the chain.

The minting fee is for adding POW not entirely for transactions.  Tx fees could be excluded for the Uncle.

Well, maybe

Miner gets M * 1.1
Parent got M from the previous block
Uncle gets M

Rule: Hash(uncle) must be less than Hash(parent).

If the uncle miner builds on his own block alone, he gets M * 2 reward, if he finds the next block.

If he builds on the combined block, he gets M * (1.0 + 1.1) = M * 2.1 reward, if he finds the next block.

If the parent miner builds on his own block alone, he gets M * 2 reward, if he finds the next block.

If he builds on the combined block, he gets M * (1.0 + 1.1) = M * 2.1 reward, if he finds the next block.

If a third party builds on the parent block, he gets M reward, if he finds the next block.

If he builds on the combined block, get gets M * 1.1.

All miners have an incentive to build on the 2 blocks.

For added security, the uncle block would be included in the blockchain.  This isn't really necessary though.  A miner can only submit an unchecked block if a tie happens and he has a lower block hash.

He could wait for the next block to be found and then submit his block header (plus presumably coinbase tx), but there is only a 50% chance that his hash will be lower than the found block.

If he doesn't check his blocks are valid, he loses 50% of his income.  It would be more efficient to just submit coinbase only blocks.

[jonald_fyookball]

hi Sergio,

By "faster" , do you mean less orphaned blocks?

First, all conflicting blocks headers that are not very old are forwarded to allow all peers to compare block hashes. If a miner Carol (or Alice or Bob) solves a following block, she includes in his block a reference to the uncle block header that was left out of the main chain.

This is interesting to me.  Could this be a mechanism to force
some transaction inclusion in the event of a 51% attack situation?

[telepatheic]

Could you succinctly explain what problem DECOR solves? Give an example of a scenario where Bitcoin would fail and your solution would work. I can't see how it allows faster block rates.

[TierNolan]

hi Sergio,

By "faster" , do you mean less orphaned blocks?

One of the "collapse" scenarios with fast blocks is that nobody has an incentive to publish.

If the block rate is much faster than network latency, then nobody has an incentive to publish blocks.

The best strategy is to generate a chain of blocks and then publish them as a unit.

The miner with the single concentration of hashing power will win more than 50% of the mini-chains.

If 65% of the miners are fragmented, they have a slight delay after each block.  If they find a block every 5 seconds, but latency is 5 seconds, then they are only 50% effective.

A miner  with 35% of the mining power would be able to generate blocks faster.  Their efficiency is 50%, so they effectively have 32.5% of the mining power.

If the latency is much bigger than the block rate, the mining efficiency of fragmented miners is extremely low.

This system could be expanded to allow multiple "uncle" blocks.

The header could be

Hash(prev)
Hash(merkle-uncles)
<etc>

The merkle-uncles would be be the merkle root of a list of uncle headers.

This would allow a majority of the hashing power to combine their block headers, without having to form a chain.

The block rate could be adjusted if there are to many orphans.  

The mint reward could be doubled if the block rate was halved (due to latency), so everything remains balanced.

[jonald_fyookball]

Sorry I'm not following.  Blocks are 10m...how did you get to 5s 

[telepatheic]

If the block rate is much faster than network latency, then nobody has an incentive to publish blocks.

So DECOR is simply a protocol to incentivise miners to not be greedy miners where block rates are of the same order as the network latency.

Sorry I'm not following.  Blocks are 10m...how did you get to 5s

Sergio is creating NimbleCoin which will have 5 second blocks.

[TierNolan]

Sorry I'm not following.  Blocks are 10m...how did you get to 5s  

The thread is "fast block rates".  One of the reasons for the 10 minute block rate is to prevent the network collapsing due to latency.

5 seconds of latency combined with a 10 minute block time means that fragmented miners are 99.2% as efficient as a single concentrated miner.

With a 1 second block time, the fragmented miners would be 17% as efficient as a concentrated miner.

The scheme means that the fragmented miners can combine their blocks into a super-block and restores their ability to generate POW.

Even with a 10 minute block time, it means that orphan blocks add their POW to the chain, so protect against reversals.

Finally, by clearly defining how to break ties, it means that all mining power quickly moves to a particular block.

If the block rate is much faster than network latency, then nobody has an incentive to publish blocks.

So DECOR is simply a protocol to incentivise miners to not be greedy miners where block rates are of the same order as the network latency.

It isn't just greed.  Fragmented miners cannot coordinate to produce chains, so they can't generate a longer chain faster than the concentrated miner.

[jonald_fyookball]

Ahhhh... Ok.  Very different context than bitcoin then.
Not needed in bitcoin since the block duration is so much larger.

Still I like this uncle block concept.  If a malicious monopolist
Starting dropping transactions from blocks, that idea
could be useful maybe.