Topic: Block lattice - page 5. (Read 8444 times)

Unless every owner a token is going to be online mining all the time, then mining will need to be delegated. So some pools have more weighted-balance voting power than others. You need to offer some incentive for mining. Profits accrue to those with the most economy-of-scale if the incentives are market (competitively) priced, thus you will likely end up with the situation that Bitcoin had where a single pool or potential grouping of large pools had more than 51% of the hashrate but in your design this would be more than 51% of the voting power.

Is a cascade of intertwined inter-chained reorganizations when multiple double-spends are reverted by a fork more onerous than in a single block chain? Isn't that complexity similar to the reason you rejected multiple inputs and outputs in transactions?

The key failure in your design is the lack of incentive to have a consensus. What is the incentive for voting nodes to agree with the correct fork and for minority nodes to agree with the majority fork? Seems to me they can all disagree and no one can prove otherwise, because they can pretend to have never heard the votes of others (no way to prove receipt of a vote on the internet). This shows that without the objectivity of a PoW, then there is no objectivity and you end up in chaos.

In PoW, miners have an incentive to reach consensus because otherwise their rewards won't be honored by the longest chain. In your system the majority of the vote is the winning fork, except there is no penalty for delaying for an indefinite period acknowledging receipt of such a vote. Thus complex game theories arise. Even more critically, the majority vote may be split among multiple forks, such that there is no consensus, because you have multiple chains thus a plurality of permutations of forks.

I do want readers to note which of the three posters in this thread was able to state directly the design error. That should be instructive to investorswhich lead developer is most qualified.

We have a section on Sybil attacks in the attacks documentation https://github.com/clemahieu/raiblocks/wiki/Attacks

The resolution protocol is a balance-weighted vote by account holders in the network, this is the core of what prevents sybil attacks.  In order to attack the network, you need to have ownership in the network in proportion to your attack weight.

It appears (from the writeup) that you are unaware of sybil attacks?

The graph of transactions in bitcoin already functions like what you describe (except 'accounts' are single use txouts); Bram Cohen likes to call Bitcoin without the blockchain "bitpeso".  In Bitcoin the blockchain is overlaid on top of "bitpeso" to resolve "complex forks" (using your language) in a manner that allows someone to join the network and know which resolution is authoritative in a way which is both robust to sybil attacks and does not require membership (because a membership process would create control over the system).

In your description you appears to liberally conflate forks and double-spending.  In Bitcoin, double spending a traditional txout requires malicious behavior, just as you describe.  Blockchain forking in the absence of double spending is benign and no different to the "multiple resolution rounds" you mention from your resolution protocol but fail to describe detail sufficient to permit any analysis.

Hey everyone, I designed a system which, for lack of a better term, is called a block lattice.

https://github.com/clemahieu/raiblocks/wiki/Block-lattice

The idea is each account in the system has a block chain that is controlled only by them, all chains are replicated to all peers in the network.

The advantage of doing this is each account can order their own transactions meaning no proof besides a digital signature is needed.

I think this goes a long way toward scalability by removing block intervals, mining, transaction fees etc and wondered what everyone thought.