Topic: Reduce Orphaning Risk and Improve Zero-Confirmation Security With Subchains (Read 735 times)

This is very clever, it needs more exposure.

Typically, between 1% and 2% of blocks end up being orphaned. 

are orphans that high with bitcoin, i was aware that the 10 min average for the block, was done exactly to avoid it as a possible

how many orphan block we have per day on average right now?

your welcome.
it seems actually a novel idea.
i would however concentrate less on the orphan argument as thats more arbitrary in relation to human decision to stale their attempt or push on to win blockheight of next block to validate both blocks.

but adding in what i would call 'transaction clusters' you call weak blocks (my word is just laymans way to separate the term 'block' to reduce confusion) would benefit the system alot.. which using a banking analogy the weakblock(transaction cluster) can be seen as the 'debit'/'withdrawal' part preventing users from double spending.. and then the real block solving is the 'crediting'/'deposit' part to the recipient.

if you can to ensure all miners agree to re-jig their mempool storage to this method, then you have a better solution to malleability /double spending than others so far

Thanks for reading my paper!

Indeed, it's not an orphan fix, but I do believe it will permit significantly more transactions per second at the same level of orphaning risk.  Here is a chart that explains what I think should be possible, given the current network infrastructure:

good in theory but not in practice..
orphans will still happen, its the way the mining game is played. (there can only be one winner, the rest are rejected, orphaned, stale)
edit: its more of a double spend fix, and not so much a orphan fix

but lets explain how its not an complete orphan fix to all the new people in the world who dont know what an orphan is.

at 10h:00m:00s two mining pools start mining their blocks. pool A has 100petahash pool B has 80petahash
at 10h:08m:56s Pool A solves their blockheight 400. contains 500tx and begins working on the next block
at 10h:09m:03s Pool B solves their blockheight 400. contains 700tx and begins working on the next block

at 10h:08m:56s pool B should have given up at 10h:08m:56s and treated their work as stale, to start afresh with blockheight 401. but they continued as there is a chance pool A's block could be rejected due to bad data..

pool A started their block401 at 10h:08m:57s contains 800tx
pool B starts their block401 at 10h:09m:04s contains 400tx

pool B's aim is to try and win the next block(401) quicker than pool A, so that not only will pool B win the reward of 401 but also their block 400 becomes valid aswell.(double win), making pool A's 400 the orphan
but if pool A wins again, then obviously pool B has to finally give up, so pool B would then class their block 400 as orphaned

no matter who has what data or how such data is organized. its not going to fix the orphan problem in practice, because by their very nature miners are going to compete to get ahead of each other. some will give up(stale block) as soon as they see a winner. some push on a little further just incase they can solve 2 blocks before the other. but ultimately there will be an orphan

but lets assume all miners agreed to include the exact same pre-checked data(subchaincluster), just to avoid rejection.
and yes i did prefer to use 'cluster' instead of 'weak block' as its less confusing between transactions weakblock and normal block

in theory if
pool A block creates block 402 containing SCcluster001, SCcluster002, SCcluster003, SCcluster004, SCcluster005
pool B block creates block 402 containing SCcluster001, SCcluster002, SCcluster003, SCcluster004, SCcluster005

and both start mining at the very exact same second of 10h:20m:30s, Pool A will still win purely due to better hash power than pool B.
but because pool B knows instantly that pool A's block wont get rejected(because all valid data) Pool B WILL give up(stale data) before solving their block and start a fresh on block 403. thus there is no losing solved block to be called orphaned
well thats the theory..

but in practice (yes subchains requires cooperation rather than competition) due to competition
pool A block creates block 403 containing SCcluster001, SCcluster002, SCcluster003, SCcluster004, SCcluster005
pool B block creates block 403 containing SCcluster001, SCcluster002,

pool B wins this time. but A pushes on hoping their hash power will win block 404 making 404 valid along with making their 403 valid too.
pool A block creates block 404 containing SCcluster006, SCcluster007, SCcluster008, SCcluster009, SCcluster010
pool B block creates block 404 containing SCcluster003, SCcluster004,

yes orphaning will decrease because miners are more trusting that a winning block wont be rejected. so prefer to stale their attempt ASAP, but greed is a b*tch and some miners will push on hoping their attempt will give them better luck on the next block to validate 2 blocks in one shot, just by getting ahead.
and this greed is why even 1 confirmation is sometimes not enough.
they will include less clusters to have less processing to do to and many other things to get ahead. this is why many tx's spend hours waiting to confirm now and will still occur even with subchain clusters.

because while pool B may have won block 403.. pool A, by not staling their 403 and then winning block 404 in 5 minutes 405 in 5 minutes before pool B takes 9 minutes to solve their 404. now pool A has got ahead by 2 blocks making not only 404, 405 valid.. but also now their 403 valid, making pool B's 403 and 404 orphaned.

so yes in theory pool B should have staled their 404 attempt at 5 minutes when they seen pool A's 404 solved block.. but greed, as i said would push some miners on. and they will always compete.

if all miners cooperated, then the only winner will by the guy with the highest hash power in more cases then currently. so competition and greed would outweigh cooperation.. as proven by miners ignoring 0fee tx's even when the average block is only 66% full

summary
good in theory but is not the ultimate solution to orphans. it can help reduce orphans.. but not eradicate them.
i do like the idea that tx's are preconfirmed. as that means the mempool can reject people trying to send 2 tx's using the same source funds as the first tx is already 'locked' into a cluster. which all the pools are copied into.

this is actually a better idea for double spend(malle) prevention. and should be re-written as such, rather than an orphan solution

Abstract


http://www.bitcoinunlimited.info/downloads/subchains.pdf (Peter R. Rizun)