Low-Latency Restricted DAG

[likeatree]

Hello,

I have come with a tweak on directed acyclic graph blockchain structure which reduces latency. Basically, each user has their own personal blockchain "swimlane", and these chains are linked together temporally through witness hashes. There is no chance of un-intentional forking. You will still need to define a consensus function to deal with bad actors. If someone tries to attack by splitting their "swimlane" for example, consensus could choose the lane which has the most witnesses or just permanently ban them from participating in the ledger.
 
Here's a basic idea of what I'm talking about:
http://imgur.com/SOKHqAO

A whitepaper.
https://www.scribd.com/document/386713928/Restricted-DAG

Please let me know what you guys think. Thank you!

[aliashraf]

Thank for sharing. I Just read the introductory section of the white paper, very impressive, a deep understanding of blockchain and cryptocurrency

Let me finish reading it and will share my ideas regarding your(?) work.

[monsterer2]

In Figure 6, user A attempts to publish alternate blocks A2† and A3†. Since user B3 has already wit-nessed blocks A2, A2† would be rejected by all participants. Furthermore, A can be flagged as a malicious or compromised user for presenting two different solutions for A1

I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3.

You need an objective way to sort this out.

[aliashraf]

I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3.

You need an objective way to sort this out.

I guess OP would say B should never witness both A2 and A2+, users are supposed to get enough witness for A chain before considering a transaction confirmed.

[monsterer2]

I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3.

You need an objective way to sort this out.

I guess OP would say B should never witness both A2 and A2+, users are supposed to get enough witness for A chain before considering a transaction confirmed.

That might work for an individual user, but if different users see a different state due to latency, you're back at square 1. There has to be some objective way of resolving this; either you have to adopt the synchronous swilrds hashgrid consensus(1), or you need to adopt something with a probabilistic finality like the tangle(2), or T.E.T.O(3).


1) https://swirlds.com/downloads/SWIRLDS-TR-2016-01.pdf
2) https://assets.ctfassets.net/r1dr6vzfxhev/2t4uxvsIqk0EUau6g2sw0g/45eae33637ca92f85dd9f4a3a218e1ec/iota1_4_3.pdf
3) https://github.com/wildbunny/docs/blob/master/T.E.T.O-draft.pdf

[aliashraf]

I fail to see how this can work; the concept of 'already' is totally subjective due to latency. It is just as likely that the situation presented in that figure will shortly be resolved in favour of A2 and A3 as other users see that branch 'first' before B3.

You need an objective way to sort this out.

I guess OP would say B should never witness both A2 and A2+, users are supposed to get enough witness for A chain before considering a transaction confirmed.

That might work for an individual user, but if different users see a different state due to latency, you're back at square 1. There has to be some objective way of resolving this; either you have to adopt the synchronous swilrds hashgrid consensus(1), or you need to adopt something with a probabilistic finality like the tangle(2), or T.E.T.O(3).

Not completely sure, but it seems op's main weapon is to be find in his proposal for random mesh overlay network. It seems that double spend attempt is discouraged by not giving witness credit to none of blocks A2 and A2+ (supposedly) because they either arrive sequentially or simultaneously to nodes as a result of semi-perfect topology of the network.

Reminding that I have not fully digested this proposal, I wish you don't take my comments here as a personal judgment in favor of it.

Yet for some reason, I'm positively biased toward shifting attentions from the sole consensus method a bit more to overlay network topology in crypto and blockchain techs. I mean it is so ridiculous we don't take care of this issue enough. Isn't it?