Optionally is the key word. Blockchain transactions must be signed, and they must be accepted as following the blockchain rules by validators.
But this is just a policy decision, not a property of the technology. You can easily implement a script that checks if every commit from remotes are signed, accepts them if they are and drops them if they aren’t or the signature is invalid.
If you contribute to a project where the majority require signed commits, then you need to sign commits in order for your change to be integrated into the consensus.
That has nothing to do with the technology itself, just with the application.
So if you state that signatures are required to be a blockchain, then you can use git to create a blockchain, by just having that policy.
(IMO I wouldn’t say that signatures are required, just that blockchains usually have them.)
You can easily implement a script that checks if every commit from remotes are signed, accepts them if they are and drops them if they aren’t or the signature is invalid.
Now add some logic to check whether the actual data is valid (i.e. bob has enough coins in his account to send to Charlie).
Make some incentive to ensure only the main branch survives and forks are either eliminated or merged.
Automate
Now git replicates blockchain’s functionality.
So if you state that signatures are required to be a blockchain, then you can use git to create a blockchain, by just having that policy.
Yes, but add automatically processing the content of the commit for validity and incentives to reduce the number of forks.
(IMO I wouldn’t say that signatures are required, just that blockchains usually have them.)
Without public key cryptography you just have a hash linked list (like Git).
