Bitcoin Forum
November 16, 2024, 01:45:10 AM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Reducing the orphan rate to 0 in a >100k TPS chain  (Read 1265 times)
monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1007


View Profile
September 17, 2015, 03:08:23 PM
Last edit: September 17, 2015, 04:59:54 PM by monsterer
 #1

There are two main reasons we get orphaned blocks in blockchains:

1) N miners simultaneously solve a POW for a block, each submitting a new block with the same parent (which is what causes the fork)
2) Double spend attempts

1) occurs because we have linked list of blocks
2) occurs because of fraud, or broken wallets

Simply using a DAG instead of linked list (and one transaction per block) will improve the orphan rate because the number of allowable DAG heads is greater than 1, but this is still not optimal, since the orphan rate will only reduce by a factor of the number of heads.

Optimally (for orphan reduction), each unspent output is a DAG head. If you and only you can mine your own transactions, you can never get an orphaned block (except in the case of a double spend). This would lead to maximum possible transaction throughput.

The huge problem with this is that once you do this, you completely lose the chain of consensus, because you can't build on someone else's UTXOs. The question, then, is this: is there another way around this? Can you do something like have a parallel consensus chain consisting of only major miners collecting only the block reward and doing no transaction verification, or bundling. Then, when a transaction is sent, it is built referencing the best block of the consensus chain?

gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4284
Merit: 8808



View Profile WWW
September 19, 2015, 09:25:56 PM
 #2

The reason to care about "orphaned" blocks is because you might believe a transaction is confirmed when it really won't be part of the eventual history.  This cannot be prevented in a system without predefined membership, because its always possible that there exist two conflicting transactions where both cannot be confirmed.  You can eliminate orphaned blocks by eliminating blocks and yet provide no improvement to anything that matters to anyone. Smiley
monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1007


View Profile
September 19, 2015, 09:43:13 PM
 #3

The reason to care about "orphaned" blocks is because you might believe a transaction is confirmed when it really won't be part of the eventual history.  This cannot be prevented in a system without predefined membership, because its always possible that there exist two conflicting transactions where both cannot be confirmed.  You can eliminate orphaned blocks by eliminating blocks and yet provide no improvement to anything that matters to anyone. Smiley

As you decrease the block time, the orphan rate increases irrespective of double spend attempts because of the first reason listed above. If you want a system with very high transaction throughput, reducing orphan rate is important - if you can eliminate orphans due to submission latency, then all that remains are double spend attempts.
gmaxwell
Moderator
Legendary
*
expert
Offline Offline

Activity: 4284
Merit: 8808



View Profile WWW
September 19, 2015, 10:28:38 PM
 #4

I think you're missing my point:  There is no reason to care about orphans absent double spends and incentive compatibility in mining.   If a scheme eliminates "orphans" without addressing the reasons anyone would care about them, then it's uninteresting.  Assuming efficient transmission they don't even appear to have a greatly adverse impact on goodput, as if the 'orphan' blocks carry mostly the same data you only need to send the insignificant amount of differential data.

E.g. imagine someone "solving" orphans by renaming them to bloopthrops; thus the system is orphan free. Smiley

monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1007


View Profile
September 20, 2015, 09:12:08 AM
 #5

I think you're missing my point:  There is no reason to care about orphans absent double spends and incentive compatibility in mining.   If a scheme eliminates "orphans" without addressing the reasons anyone would care about them, then it's uninteresting. 

The reason orphans are bad is that the chain selection rule doesn't count the work which they took to produce into account. This means the work is wasted, leading to greater overall chain inefficiency. They also set a lower bound on the block times which are achievable - once you start talking about 10 second blocks and below, the orphan rate is so high that it becomes difficult for the chain to make progress.
Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 555
Merit: 654


View Profile WWW
September 20, 2015, 01:09:48 PM
Merited by ABCbits (2)
 #6

Four possible solutions for a 10 sec blockchain with low wasted PoW:

1. GHOST: https://eprint.iacr.org/2013/881.pdf
2. DECOR+: https://bitslog.wordpress.com/2014/05/07/decor-2/
3. MinCen: https://bitslog.wordpress.com/2014/03/20/mincen-a-new-protocol-to-achieve-instant-payments/
4. DagCoin: https://bitslog.wordpress.com/2015/09/11/dagcoin/

Sergio_Demian_Lerner
Hero Member
*****
expert
Offline Offline

Activity: 555
Merit: 654


View Profile WWW
September 20, 2015, 01:38:33 PM
 #7

One more:

5. Bitcoin NG: https://scalingbitcoin.org/montreal2015/presentations/Day1/8-Ittay-eyal-testbed-for-bitcoin-scaling.pdf

But this solution is a trade-off of PoW security against latency: not all blocks are PoW-mined.
monsterer (OP)
Legendary
*
Offline Offline

Activity: 1008
Merit: 1007


View Profile
September 20, 2015, 03:23:43 PM
 #8


There are all interesting solutions. GHOST is nice because you don't waste work at all, but you still get around 200 orphans per day at 10 second block intervals. At that granularity, network latency becomes a problem because you have N miners all trying to update exactly the same part of the same data structure simultaneously.

DagCoin is a nice approach to mitigating that problem, but I wondering if you can take this idea to its natural conclusion and have UTXOs be the DAG heads, and only the UTXO owners can build on their own heads while at the same time still maintaining a consensus.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!