> 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

I proposed 'chain merge' for blockchains awhile back, because I spent way
too much time merging linux kernels with cvs/bitkeeper/git/hg

I also remember conversations with Larry McVoy where he thought a LOT
about how a distributed version control system with no central authority
could achieve a consistent global merge state.

So what if you included a micropayment per change, and come up with some
way to provide a 'merge reward' for the person who takes the time and
effort to merge the 'shorter' chain back in?

Why don't you just keep ALL the forks, and have multiple 'heads' in the
block chain, but you select the default one to build work from by the
Satoshi consensus model, and if you want to build on a non-tip head, you
have to pay a storage fee to all the nodes?

Bitcoin-based systems do stupid shit like throw away non-tip forks, which
makes it damned hard to figure out what went wrong, or who's not behaving
nicely.

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@???
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash