Anti-DoS Library State Validations

[marcoonroad]

The replicated and distributed nature of Git may lead to huge security breaches. Nowadays, Git repositories are wrapped under either HTTPS or SSH to accept updates performed by git push. The cloning may be unauthenticated. Therefore, this scheme implies in a rather centralized approach to protect Git repositories.

In our planned solution, a good approach might be to receive the update order from any node, but to validate the consistence of the provided commits by using Git Hooks. Keep in mind that nodes might provide valid commits and yet, at the same time, attack the internal state by flooding, aiming a DoS. A Proof-of-Work scheme can help here.

The replication may be performed by Swarm/P2P networks, but it's not our responsibility to implement that. Our responsibility is only the mergeable nature of the application state repository, by avoiding any prior kind of Network Replication, the replication can be made in many ways, for instance, extracting and packing ZIP files, etc.

An implemented quite good and strong encryption algorithm (such as Twofish) could be used to protect the seeds/private keys, and therefore, backup the user's wallet keys by the mean of data replication. A Post-Quantum mechanism to sign the commits (akin to GPG keys) is interesting as well, and it's possible to bootstrap this library to sign its own Git state repository through the Irmin's commit information layer.

---

Note:

It doesn't mean that our library will maintain a fully sync and up-to-date internal Git state by blockchain-alike replication. Really, our goal is not to create the next blockchain. Well, perhaps not just within this library. Our goal is to enable a client wallet be usable in many kind of devices, such as smart phones and notebooks. By dropping the network replication assumption and only focus on the mergeability, the customer/user can use a layered authentication mechanism on top of that, which would enable the synchronization of the state among his devices.

The validation here is not just to avoid intentional attacks, but also unintentional mistakes which could introduce bugs and typos on the internal persisted library state. An error correction algorithm for the Git state would fit well here.