Security considerations for range patch

[mitar]

I don't think this should be part of the synchronization type. I think the synchronization type only needs to be there in order for two synchronizers to consistently resolve to the same state — that just means that they need to use the same function to merge multiple parent versions into a single resulting state.

So a synchronization type doesn't need to be more than a function merge (parent_versions) => state_of_child_version. This doesn't need to care about whether the version dag is merkle; whether it is hashes; it doesn't need to validate. The version identifiers can be determined by something separate, and validation can be a separate process and separate specification.

Overall, I think that this can make the actual Synchronizer-Type a lot more specific, which also reduces the potential security problems, and as a result, I think a lot of the security considerations don't need to be in there.

Originally posted by @toomim in https://github.com/braid-work/braid-spec/pull/20

[mitar]

First, in contrast with media types, security considerations for sync types are not required and one can just state that they have not been assessed. So somebody can completely ignore that and do nothing there.

But I think it is important to ask those questions and that people can explain/communicate them to anyone deciding to choose between different sync types. Again, I am having in mind that those are more than sync types just for Braid. For example, they could also be for consensus algorithms in blockchain. And some of those security properties/questions are present there.

BTW, I based this on what is required (not optional) for media types. So if for "static" media types they have such questions, then for "dynamic" synchronization approaches we should have them even more.

This doesn't need to care about whether the version dag is merkle; whether it is hashes; it doesn't need to validate.

For those used in Braid maybe. But even in Braid we might want to define at some point a sync9+rsa synchronization type for P2P synchronization which also validates signatures.

So, my take here is: we can make sync types we register simple. But that does not mean everyone who will be making them will make them simple.

[toomim]

You're still lumping together:

• Validation specs
• Merge specs
• Tie-Breaker specs (e.g. proof-of-work)

Please distinguish these three things.

we might want to define at some point a sync9+rsa synchronization type for P2P synchronization which also validates signatures.

Validation is independent of merging. It will use a different spec.

For those used in Braid maybe. But even in Braid

This isn't about Braid vs. non-Braid. Braid is a general protocol that you can do any synchronization over. If you have a synchronization system, you can express it over the Braid protocol.

[mitar]

Closing in favor of #46.