This is an interesting bunch of thoughts.
I'll have to give some more thought to the matter of merging but
on the topic of saving all blocks, this is currently what we do.
It seems easier to store every block so that when a new client
joins the collab document, they will be able to see every block
(patch) as did the clients who had been editing the document all
along. We're not worried about a security issue with someone
generating zillions of trash-blocks to consume space.

Thanks,
Caleb


On 03/13/2014 05:30 PM, Troy Benjegerdes wrote:
>> 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.
>
>