Good questions. I didn’t clarify those points. I’m not even sure this is the right way to go about the process, but all of the needed information to perform various functions is contained in a format that is easy to work with programatically. That was really my initial goal here.
So, the hash-content field won’t produce the hash. I included it simply to have a plain english version of the text for reading. It has been converted from the original raw text to play nicely within JSON (characters escaped, single lined). The content-b64 is produced using the original raw text. Once decoded it can be passed to a ripemd160 hash function and should produce the hash.
I guess I shouldn’t call that field hash-content… it sounds like you can produce the hash from it but that’s not the case.
So how does this all work within the scheme of the validation script? We’ll produce individual files like every other motion using the new source content for these motions. They will be included in the NuLaws process the same as every other motion. The difference being that when the script tries to validate these individual files (by producing a hash and looking to see if it passed in the blockchain) there will be a condition that looks for the old hash in the blockchain instead of the new one. The purposes of my motion above is to receive consensus from shareholders that this is an acceptable modification to the process.
Other option could be to vote on each of these new hashes all over again, and completely ignore all of the older hashes. Though I think acknowledging this historical change in the code through a single motion is cleaner even if we have to create a special condition in the script for these five motions. The idea being that we won’t ever have to make such a condition again and it will only need to be coded once and left that way.
