Topic: Bounty on orphaned block discarded - technical reason? (Read 2172 times)

Yes. It does. It is very helpful indeed.

I'm sorry about that and have to admit that i didn't read your post too closely. But I think my post explains why it's useless to have a bounty on oprhaned blocks which still makes it of some use to read for you.

Thanx wabber, for the additional contribution.


Sigh.  I did not make a proposal.    I had disclaimers in my OP in three places and stated that I want to understand a part of the concept.

Of course I appreciate your time and I am grateful that you read my questions and care to answer. But before suggesting that my proposal is useless and should be dropped - you could at least read as far as to realize that I did not make one. 

A bounty on orphaned blocks doesn't make sense. As already mentioned noone has to and noone probably would include a transaction to the miner who mined the orphaned block.
And another point is that it wouldn't increase the "fairness" because normally everyone should have the same rate of orphans in average. The miners who are much above the average rate are doing something wrong they are wasting hashing power for which we shouldn't give a bounty since it doesn't increase the network security.

I like the lottery analogy. Let's assume every block starts a lottery round then normally the only one who wins is the one who is the first that brings his lottery ticket to the lottery company. With your proposal the one who is a bit late would also get a small amount of money. In the long run it's nothing else than giving the first one more money. For Bitcoin giving a bounty for orphaned blocks is the same as increasing the block reward to 51BTC because everyone has the same chance to find a block that gets orphaned. If we would still want to limit the total BTC amount we would have to change the block reward to 49BTC and the bounty for an orphaned block to 1BTC.
But then we didn't change anything we only decreased the variance for miners and we didn't increase the fairness for miners. And to decrease variance which is the only thing your proposal could do there are much better methods like pools or even decreasing the average time to find a block.

In the end your proposal doesn't help anyone and I have no idea how to implement it and that's enough to simply drop it.

In your understanding, how does another block help secure the chain?

A formal mathematical proof that X+1 is greater than X?  Definitions don't need proof.

Maybe we should record every time someone hashes a block whether it meets difficulty or not. Wouldn't want to throw away and electricity.

But seriously if you waste something it doesn't help anyone to keep it around let alone pay you for it.

In order to help you have to to build on the highest block.

Similar question: Why would a miner include a transaction without fees? As far as I know we have no answer to that one as well. Still the algorithm works.


Do we have a formal, mathematical proof for that? Do we have comprehensive, published experimental test results which show this? If yes, I would like to learn where to find them. Please point out some sources or references so that I can study them.

Ok if I got that right, then it is an other than their own centralization, isn´t it?
Thus it is a multipoint centralization, which might be not that harmful.

Ok, I am totally noob and unaware and so an ... but if btc2 would work like that how can my fewandahalf reals:btc compete?

You didn't read the next sentence ...

Why would the new node include the orphan coinbase in the next block?

Also you are rewarding non security.  Block height = security.  Parallel blocks don't increase security.  We want miners to be competitive to minimze wasted hashing power.  You aren't throwing out work you are throwing out duplicated work.  Work which has no value to network.  As pointed out above.  If orphan rate is zero then network will simply compensate for higher difficulty.  globally miners will get same compensation and spend the same amount of energy you just have take away some of the consequence to avoid slow sloppy duplicated code.

TL/DR you would be rewarding duplicated worthless work that provides no security to the network, gives miners no compensation, and provides no incentive for miners to include orphaned blocks (other than their own) thus increasing centralization.

So the question becomes why?  Is it can OCD thing?

You throw away work of miners. And electricity.

So the question is: Is there a useful purpose for orphaned blocks?

I realize, in the current form of the algorithm, there is none.

Some time ago we had a discussion in the forum along the lines: Couldn't we include orphan blocks, the transactions of which are compatible with the true block chain also into the block chain. Then some miners could work on one group of transactions, other miners work on other groups of transactions and later we combine two block into one "super block". The idea was that this could improve bandwidth scalability. The idea was not really settled in that thread.

The purpose of mining is to secure the blockchain.

Orphans are not part of the blockchain.

If there was a reward for producing orphans, it would draw resources away from the blockchain (main purpose of mining).  At the very least, people would be lax about optimizing their setups and we would see more orphans as result.  In the worst case, we could even suffer attacks.

Also, it adds unnecessary complexity to the software.  An orphaned block is a block that does not follow the rules of bitcoin.  Even if everything else is correct, it was not based on the latest valid block at the time of creation.  But there might be more problems with the block.  We would need a special (exceptional) verification function to find out.

And last not least:  Properly verified, an orphan still represents "proof of work", although not for work towards the main blockchain.  However, it wouldn't indicate any "speed of hashing" anymore as we have now.  Even the slowest miner can produce an orphan, given enough time.  Under your hypothetical proposal, we'd only know that work has been done.  We wouldn't know whether it EVER had the slighest chance to be actually useful for the blockchain.

There is nothing to reward unless proof is shown that the blockchain is now more secure than before.

The question becomes why?

Why would the new node include the orphan coinbase in the next block?  Without an incentive they won't.  You actually would make larger pools more powerful.  Every miner would include their own orphans in their own next block attempt.  For a smaller miner that means a negligible % gain however for a pool like DeepBit they would be able to recover 35% of their orphans.  Now orphans are currently only 1% but say in a different protocol they were higher .... 3%.  DeepBit size would give them a 1% advantage over smaller pools.  That higher revenue would likely mean they become even larger.  At 50% of hashing power they would gain 1.5% effective revenue over other pools.

The other issue is validation.  The original orphaned block (or at the very least the merkle tree, and block header) would need to be included.  To validate the new block w/ orphaned coinbase you would need to validate the coinbase was also valid.  Otherwise nodes could simply put double coinbases in every block.  That orphaned block data would need to remain a part of the blockchain forever so that blockchain can be validated back to the genesis block by future nodes.

So the short answer is there is no technical reason you couldn't but it would have some unintended consequences (giving larger pools advantage over smaller ones) and would require storage of orphan blocks into perpetuity.  A lot of code, complexity, and testing for something that in the long run has no appreciable benefit to any user.

Now for something like p2pool where the orphan rate has PR cost (xyz thinks p2pool is a scam because he "loses" 8% of his hash power to orphans) a system which merges orphaned shares may have some value.  p2pool discards the end of the sharechain so there is no "into perpetuity" storage cost.  Even here it would have real effect on revenue but it would reduce the volatility of smaller miners and improve the "perception" of uneducated miners.

No. Complete misunderstanding between us 

I asked for reasons against the idea - but I never intended to implement this. Remember the disclaimer at the beginning of my post? I really meant that disclaimer. 

My approach is the following: Whenever a program has to solve a certain task, you will end up with a specific implementation. Some of it's properties will be must-have properties (For example: Bitcoin would not work without some form of randomization. There is a proof on the complexity of deterministic consensus algorithms, which applies here, and which tell us that Bitcoin would not work without a random or pseudo random element in it.) There are other properties, which are nice-to-have or plainly coincidental. Currently I am trying to understand, which parts of Bitcoin are must-have and which parts of the algorithm could be different. If I have answers on this I can come up with different algorithmic schemes. That's the way I do research (which is the way I earn my living) I am into thinking, not into minting - and hopefully this may prove useful after all  Well, I get more pleasure from "ThinkCoins" than from Bitcoins, I guess 

About this orphan block thing. I realize that we need some incentive for miners to work on the most current block. The variant I suggested could enable malicious miners to obtain bounties by only producing orphaned blocks, which is not what we want. Therefore my original concept must be modified a bit - as I wrote in my post - by placing bounds on difficulty or depth. Currently we are seeing miners minting blocks without any transactions all - which could mean that the current implementation has a small incentive-loophole, given the conditions under which these miners (bot-nets ?) operate. The interesting question thus is: WHAT are the minimal conditions we must require for the bounty to work properly?


That is a great way to put it and this comment helps me a lot. We actually can model this part of the algorithm as difficulty (probably not lower but higher, if we take expected payout as constant in our model).

So, let us assume we have a percentage p of orphaned blocks. Now, let's assume we increase block chain speed. This has been discussed in the forum (and it would increase the number of orphaned blocks). According to your idea it would mean different difficulty. So a next question is, whether there are still other aspects in addition to different difficulty...

You asked for reasons against the idea, but what is needed is reasons for the idea.  It doesn't solve any problems with the bitcoin system, so there is no reason to implement it.  Orphaned blocks are not a problem.  If 1% of blocks are orphans, it just means that the difficulty will be 1% lower, and miners will on average get just as many bitcoins despite the occasional orphaned block.

Yes, we can drop orphans.

Could we still couple the limitation mechanism to the number of BTC minted thus far?

This will at least cause generation of more BTC than needed.

I am writing up a formal specification for the block chain algorithm and came across a question I was not able to settle on my own. (Disclaimer: I am not trying to make yet-another-suggestion for modifying Bitcoin nor am I proposing yet-another alternate chain. Just trying to understand).

When a block becomes orphaned - the bounty for the miners is lost, since the transaction does not make it into the "true" block chain. Life is risky and that is one of the risks of a miner. That said, it would be quite easy to change this: If someone presented this orphaned block (with correct difficulty, target matched properly etc.) to a mining node, this node could accept the coinbase transaction of the orphaned block and include it into the block it currently is working on. If this block wins, there would be 100 BTC created. Of course, there would be some checks (for example, correct difficulty, time stamp not too old, depth not too old - we want to prevent very old orphans from being use for that purpose).

I do not want to suggest that as a modification, but I would like to understand if there is any strong (technical, security, economic etc.) reason against this. (I might have missed the obvious).   

One issue I see is: It would reduce incentive for miners to immediately switch to a new block, if one is found, since they could make money with old blocks. To prevent that could be easy: Pay only half the bounty for orphaned blocks; accept only blocks with with a very small depth difference.

So far as I see, it would not break correctness/security of the algorithm, just mess with miner incentives.

Thanx for listening.