On 03/12/2014 11:00 AM, Peter Todd wrote:
> On Wed, Mar 12, 2014 at 10:31:05AM +0100, Caleb James DeLisle wrote:
>>> Care to explain what exactly a "blockchain" is being used for in this case?
>>>
>>> In particular, how does what you are doing differ from the directec acyclic graph structure seen in, say, git-style decentralized revision control systems?
>>>
>>
>> Although there is a central server in the reference implementation, the algorithm is designed to be able to be p2p and if two groups become partitioned for a period of time, the chain will fork and when they re-join, the longest fork of the chain will win with those using the shorter fork being reverted. I'm using the term blockchain because unlike git, it is a p2p consensus seeking algorithm... And I happen to have stolen almost every design aspect from Satoshi.
>
> But you're leaving out the PoW/difficulty that makes it "consensus seeking", yet at the same time also inherenting the linear nature of it


Leaving out the difficulty doesn't make it not seek consensus just makes
it insecure, I assume that nobody will maliciously generate long side
chains to break other users.


> that obstructs groups trying to work together by making it impossible to merge forks together.
>
> Why should two groups that have become partitioned be unable to merge their respective histories together when editing a document?


The lack of merge is mostly just a technical detail since in the event of
a reorg, each client will identify it's own patches and move them back to
"uncommitted work" to be transformed and pushed again. The reason for this
is to avoid ever transforming the work of others so it is easier to be
assure myself that the algorithm will always reach consensus, even if that
consensus is messy.

There is a bug if a user leaves the session (closes their browser) and
their work is lost in a reorg. OTOH I'm not sure if there will ever be
big enough reorgs in the real world to make this bug noticeable.
I'm of course coming from the assumption that the users are friendly,
without that assumption you need either a central authority or miners.

Thanks,
Caleb


>
>
>
> _______________________________________________ unSYSTEM mailing list: http://unsystem.net https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>