Maybe it’s a bit premature but it would be fun seeing future articles say “the Nu legal team has…”
1 Like
Maybe even more.
Could it be worth it?
I think so.
Let’s make some necessary adjustments in the liquidity provision scheme and spend parts of the saved money for that 
Forgive the potentially naive post, I’m still new here… But wanted to chime in 
As much as I love the idea of GitHub being the host (so you can track revisions over time), we’d still be up against the problem of figuring out whether…
a. the git diff reflects the (exact) text of the motion, and
b. the motion was actually passed
Without some check here, it’s possible that someone with access to a computer that has push-access to the GH repo could “update” the text. 
Maybe this could be solved with a quick validation script, to be run by Travis CI on each pull-request?
A “validation script” would (sort of like how we verify blocks in the Nu block chain…):
- Grab the messages from each commit being merged in the PR
- Pull the motion hash from the commit message (using magic syntax like
Motion: <hash here>) - Lookup the motion from the Nu network
- Check that it actually passed…
- Check that commit hash matches the one voted for
The idea then is that the process for proposing a change is:
- Fork the repository
- Add the statute you want to your repo, commit, push to your repo
- Create a PR to the NuBits repository with the commit (build will fail, that’s OK)
- Debate the commit in the PR on GH
- Once everyone agrees on GH, create a motion to "merge commit
<your hash here>" - Once it’s voted on, we re-trigger the build, and Travis will say “good to go” (build will pass)
- Click the Merge button
If someone were to ever try to merge something invalid, or mess with something in the git history (ie, rebase), the validation script, while going through all commit hashes, would notice the problem (“commit abcde references motion 12345 which wasn’t passed”).
Any commit that doesn’t validate would be a red flag, and since git is a hierarchical chain, changing something in the past affects all future hashes, so we’d have to re-vote on everything to get the new chain to validate.
This obviously assumes that all merges are fast-forward, which … seems like a reasonable assumption given that changes likely wouldn’t be all that frequent.
Thoughts? Am I overlooking some built-in feature of NuBits that already does this for us?
7 Likes
You’re not overlooking anything. Having automated verification would be extremely valuable. I think the process sounds nice except for the creation of a PR prior to motion passing and discussions on github (I find it to be a terrible platform for long discussions and debates). I would modify the process a bit to this:
- Submit a motion anywhere (Forums, Reddit, Facebook, etc.)
- Go through criticisms and critique until you feel it’s ready
- Finalize your motion by creating a RIPEMD-160 hash of the text to vote on and sharing it anywhere along with the text. Anyone will be able to validate the motion their voting on via the text.
All that is normal operating procedure at this point. Everyone is familiar with it thus far.
- Anyone can submit a PR to the repo with the motion text
- The validation script runs the validation,
- If the text is verified as passed. Click the Merge button, if not the PR is closed automatically.
The reason I suggest this is because NuSharesholders can be anyone. The motions can be presented and discussed by anyone on any platform. Not everyone knows or understands how to use Github. We required a Github login for Daology.org to find that many people don’t have a Github account or might be unwilling to create one for one purpose. While this forum is the main discussion place for motions at the moment, it may not be in the future. It’s really difficult to say “everyone start doing what you’ve been doing over here now”, and get everyone to comply. So this change keeps the current structure of issues being potentially discussed broadly across many online communities without requiring use of a specific platform. Though usually there’s one or two technical people in each group that could take the contents and submit it to the repo once it has been voted on, with validation that they aren’t trying to submit something that wasn’t accepted.
Maybe it doesn’t need to be exactly like that, but the goal is to try an be as platform neutral as possible. This same process could be ported over to bitbucket or gitlab without requiring people to move along with it. Just core maintainers utilizing some sort of hosted git solution.
1 Like
[proposals should be able to be] discussed broadly across many online communities without requiring use of a specific platform
Agreed. That seems perfectly reasonable.
The problem only arises when we realize that we’re effectively talking about “codification” in the legal sense.
Due to that, the “vote” needs to be for more than just the motion text; it also has to be for the modification to the codex – in our case, git repo.
(Using a diff becomes an obvious choice when the motion we want to pass actually affects several different files in the repo, at which point copying/pasting the new text makes it very difficult to spot what exactly is changing.)
Note that in regular-world, if there was a mistake in codifying something, a person would go “whoops, that was a mistake” and go fix it. But we live in crypto-world, where signatures either pass or they don’t, so there’s really no “whoops”. This means the diff becomes just as important as the text of the motion itself. Otherwise, the codex (git repo) is really just “somebody’s interpretation of the motions”, which is a troublesome direction to go.
If we agree on that situation, the important piece I’m trying to address is taking a git commit hash and tying it to a motion hash, because we effectively need to keep several things all bundled up together:
- the text of the motion (wherever it was posted and discussed)
- it’s RIPEMD-160 hash
- the git diff that represents the exact changes (textual alterations)
- the git commit hash that lives in the git repository (unique and chained)
In lawyer-land this (I think) corresponds to:
-
the text of the amendment (ie, Sep 29, 1999, http://uscode.house.gov/statviewer.htm?volume=113&page=478)
Sec. 644. (a) Increase in Annual Compensation.-- Section 102 of title 3, United States Code, is amended by striking “$200,000” and inserting “$400,000”
-
the codified law or decision (ie, https://www.law.cornell.edu/uscode/text/3/102)
The President shall receive in full for his services during the term for which he shall have been elected compensation in the aggregate amount of $400,000 a year
So, based on your comment, the process would be:
- Submit a motion anywhere (Forums, Reddit, Facebook, etc.)
- Go through criticisms and critique until you feel it’s ready for voting
- Create a git commit against the NuBits GH repository (to codify your change)
- Add the git commit hash and diff to the motion, so all pieces are included
- Create a RIPEMD-160 hash of the text, diff, and commit hash to vote on and share it anywhere (GH doesn’t require an account to look at diffs)
- Vote as usual
Does that line up with what you were thinking?
2 Likes
Very well explained. I didn’t fully grasp the extent of your idea. Thank you for elaborating. I think the changes are fantastic and offer more flexibility. I made a post recently about my belief that governance will be one of the key issues that defines crypto projects in 2016. I think developing an idea like this for Nu, (and even B&C Exchange) should be a priority for the network through the course of the year. Even if it takes a custodial grant to push things in motion.
3 Likes
Awesome.
I’m going to start sifting through the list of motions that have passed (which is no simple task), and doing my best to codify what they all said in the same style that BIPs do.
Once I have something worth looking at, I’ll send it over here, and if we get to the point where we have a bit of momentum, maybe we can consider making a motion of it.
6 Likes
After going through the first few motions (using http://blockexplorer.nu/api/successMotions as a starting point), things are … pretty messy.
I tried to add some structure just to get the motions in a somewhat standard format, but it’s definitely nowhere near done. Take a look if you’re interested: https://github.com/jgeewax/nubits-law
Once we have the motions all collected, the next step would be to start codifying these. With that in mind, I’m noticing that there are a few categories that might translate to “Titles”:
Title 1: Protocol
Rules here would be focused on changes to Nu’s protocol. Ideally the whole protocol is documented here, but that might be tricky…
Example motions include: voting on protocol versions, NuBits seeder, prioritizing fees.
Title 2: Funding
Could also be called “Custodians” or “Investments”, but the typical “rules” here would basically be a list of the current custodians, FLOT, and links back to the motions that include the more detailed terms of the funding arrangement.
Example motions include: B&C exchange, NuLagoon, liquidity operations compensation, new logos, FLOT team membership.
Title 3: Liquidity
Motions and rules having to do with liquidity pools. This would include the documentation of the liquidity tiers, all the currently running bots, the buy-back schedules, etc. This is likely to be the largest section as we’d want to keep a historical account of this stuff…
For this one, since we want to have the record of buy-backs and all that, we may run into trouble as the commit gets approved and sealed before the buy-back happens… We’ll have to figure something out for that…
Example motions include: auctions, custodial grants, burns, buybacks, dividends, new products, NuSafe, bots on exchanges.
Title 4: Community
The rules here might include what qualifies as a “featured exchange”, what the license of the NuBits source code should be, etc.
Example motions include: open sourcing code, listing exchanges, shareholder response rate test.
No idea if this is remotely close to what we had in mind… @willy, care to chime in?
If it is, the next step is to start working on the validation script that we can run against the repository to satisfy anyone worried about committers changing the rules out from under the network. Anyone should be able to run a quick script and know for sure that these rules are exactly what was intended.
Obviously, the “seed block” here will be the first commit, which brings things up to date – that’ll be a nasty commit to review, sorry for whoever draws that short straw.
I’d also like to suggest that from now on, a motion should be put inside code blocks so that we don’t wonder what the browser does between copy and hashing, so…:
Your motion text goes here:
1. Point 1
- Formatted however you want
2. Point 2
- Using *plaintext* style
3. Point 3
I haven’t verified the RIPEMD-160’s in the GH repo yet, but I suspect I’m going to have to do a bunch of sifting to make everything check out because of the rich-markup stuff we have in some of the motions posted.
3 Likes
Great start. I’ve got a busy day today but when I can dive in i’ll start going through the existing motions as well.
Cool. I added a script that automatically updates the motions/README.md with the motions and their hashes.
Looks like this: https://github.com/jgeewax/nubits-law/blob/master/motions/README.md
Script lives here: https://github.com/jgeewax/nubits-law/blob/master/scripts/generate_motions_table.py
4 Likes
I’m currently lacking the time to give a proper response to your tremendous proposal… All I can tell you for now is, that I imagined it like this: https://github.com/bananenwilly/nulaw/issues/1
After digging around in here a bit more, it seems like we should split content from presentation. Without this, cosmetic changes would require motions and votes, which seems off to me, but I could be wrong.
If that sounds like the right direction, it might make sense for the codex to actually be a set of structured JSON documents rather than plain text which we modify with diffs. We could use a super slimmed down organizational structure (hierarchy) defined by the US Code which is basically:
Title -> Subtitle -> Chapter -> Subchapter -> Part -> Subpart -> Section -> Subsection -> Paragraph -> Subparagraph -> Clause -> Subclause -> Item -> Subitem
Thought I doubt we’d use all of these levels of hierarchy, so we could do…
Title -> Chapter -> Section -> Item
Using @willy’s link from above, his text was:
§ 1 - "Motion for protocol changes" (Author: JordanLee) - Passed on Block 35532 (5 Oct 2014 14:52:55)
(1) Permit shareholders to vote to set transaction fees.
1. - Default transaction fees equal to the current transaction fees should be applied if there is no transaction fee vote for a particular currency in the majority of share days for the voting period of 2000 blocks. The share day weighted median vote will be the fee.
2. - The vote will consist of an 8 bit currency/share code and an uint32 expressing the fee in satoshis.
(2) Change the maximum interest rate rise from 1% per 1440 blocks to a per block rise of 0.002%. Enforce a maximum per block interest rate decrease of 0.004%.
(3) Remove the proof of stake difficulty floor of 0.000244414.
(4) Allow more than one motion vote per block.
(5) Transaction fees broadcasted in Blocks should be set using the fee from 60 blocks in the past. Parking rates in broadcasted Blocks shall also lag 60 blocks.
(6) Permit a custodial grant to have zero as the quantity of currency.
Note: This Guideline has been met with the release of NuBits v xyz on DateX.
Would translate to a file called title-1.json:
{
id: 1,
name: "Protocol",
chapters: [
...,
{
id: 4,
name: "Voting",
sections: [
....,
{
id: 7,
name: "Voting parameters",
items: [
{id: 'a', content: "All votes must consist of a currency/share code and a fee."},
{id: 'b', content: "Currency/share codes should be represented by an 8-bit unsigned integer (uint)."},
{id: 'c', content: "Voting fees should be represented by a 32-bit unsigned integer (uint32)."}
]
}
]
},
{
id: 2,
name: "Transaction fees",
sections: [
...
]
}
]
}
So then we can represent this as…
“Voting fees should be represented by a 32-bit unsigned integer (uint32).” - 1 NuBits 4 § 7(a)
Which says “See NuBits law Title 1, Chapter 4, Section 7, Item a”
Any likers/dislikers? It is pretty tough to strike a balance between “easy to deal with” and “easy to use as reference documentation later”
3 Likes
Making the source machine readable is probably the best way to go. It will be much easier to manage the presentation and parse specific points of data rather than trying to do it with raw text and some arbitrary dimiliters. Obviously not everyone will understand how to present their motions in such a manner, but maintainers of the codex only need worry about items which are actually voted in. Love the idea of wrapping it in JSON.
1 Like
Didn’t find much free time until this weekend. I’m not sure how closely this follows your proposal, but I wanted to convert an existing motion over into a full JSON implementation to discuss.
I used this motion as the base, as it’s pretty simple. Which in turn was translated to:
{
"id": "1",
"name": "Liquidity",
"chapters": [
{
"id": "1",
"name": "FLOT",
"section": [
{
"id": "1",
"name": "Joining FLOT",
"items": [
{
"id": "1",
"content": "@mhps shall be one of the members of the First Liquidity Operations Team (FLOT)."
},
{
"id": "2",
"content": " @mhps will coordinate with other members of FLOT, and members of FSRT if necessary, to defend the peg."
},
{
"id": "3",
"content": "@mhps promises to be a part of FLOT for at least one year and to abide by all shareholder motions governing the use of funds."
}
]
},
{
"id": "2",
"name": "Limitations",
"items": [
{
"id": "1",
"content": "@mhps will be able to respond to any proposal for signing within 24 hours for 280 days a year, and be available on a best effort basis for the rest of the days. "
},
{
"id": "2",
"content ": "@mhps is able to carry out a maximum one signing a week, with its required investigation, discussion and deliberation, and no more than three a month."
},
{
"id": "3",
"content": "FLOT must be informed of exceptions."
},
{
"id": "4",
"content": "Being able to sign a request within 24 hours requires tools whithout which the response time cannot be held in case access to the internet is limited."
}
]
},
{
"id": "3",
"name": "Compensation",
"items": [
{
"id": "1",
"content": "Compensation for @mhps will occur in 90-day cycles, for a total of 4 cycles."
},
{
"id": "2",
"content": "By the end of each cycle, a total of amount of 435 NBT shall be paid to @mhps, conditional on satisfactory performance, which shall be measured in terms of his presence, effort and contribution."
},
{
"id": "2",
"content": "@mhps reserves the right to withdraw from his service if he does not receive the full amount of compensation by the end of any cycle or by personal discretion."
}
]
},
{
"id": "4",
"name": "Operation start",
"items": [
{
"id": "1",
"content": "The service of @mhps and the compensation cycles will commence from the passage of this motion."
}
]
}
]
}
]
}
You can manipulate it pretty easily from here: http://www.jsoneditoronline.org/?id=4f6422b4a6dacd6cfce853940bb73f3d
There was a number of formatting changes I had to make. If i’m understanding the point of this makes it easier to automate presentation and finding specific components of a motion, so those formatting changed were needed. Though the original motion hash can’t be computed from the text when any changes occur. It may be worthwhile including a B64 encoding of the original text for validating the motion hash from this source. Which (with removing the chapter for brevity) would look like:
{
"id": "1",
"name": "Liquidity",
"chapters": [],
"B64": "PG1vdGlvbmhhc2g+PHA+PGNvZGU+PSMjPSMjPSMjPSMjPSMjPSMjIE1vdGlvbiBoYXNoIHN0YXJ0cyB3aXRoIHRoaXMgbGluZSAjIz0jIz0jIz0jIz0jIz0jIz08L2NvZGU+PC9wPjxwPjxtb3Rpb250ZXh0PjxwPkBtaHBzIHNoYWxsIGJlIG9uZSBvZiB0aGUgbWVtYmVycyBvZiB0aGUgRmlyc3QgTGlxdWlkaXR5IE9wZXJhdGlvbnMgVGVhbSAoRkxPVCkuIEBtaHBzIHdpbGwgY29vcmRpbmF0ZSB3aXRoIG90aGVyIG1lbWJlcnMgb2YgRkxPVCwgYW5kIG1lbWJlcnMgb2YgRlNSVCBpZiBuZWNlc3NhcnksIHRvIGRlZmVuZCB0aGUgcGVnLiBAbWhwcyBwcm9taXNlcyB0byBiZSBhIHBhcnQgb2YgRkxPVCBmb3IgYXQgbGVhc3Qgb25lIHllYXIgYW5kIHRvIGFiaWRlIGJ5IGFsbCBzaGFyZWhvbGRlciBtb3Rpb25zIGdvdmVybmluZyB0aGUgdXNlIG9mIGZ1bmRzLiBAbWhwczwvcD48cD53aWxsIGJlIGFibGUgdG8gcmVzcG9uZCB0byBhbnkgcHJvcG9zYWwgZm9yIHNpZ25pbmcgd2l0aGluIDI0IGhvdXJzIGZvciAyODAgZGF5cyBhIHllYXIsIGFuZCBiZSBhdmFpbGFibGUgb24gYSBiZXN0IGVmZm9ydCBiYXNpcyBmb3IgdGhlIHJlc3Qgb2YgdGhlIGRheXMuIEBtaHBzIGlzIGFibGUgdG8gY2Fycnkgb3V0IGEgbWF4aW11bSBvbmUgc2lnbmluZyBhIHdlZWssIHdpdGggaXRzIHJlcXVpcmVkIGludmVzdGlnYXRpb24sIGRpc2N1c3Npb24gYW5kIGRlbGliZXJhdGlvbiwgYW5kIG5vIG1vcmUgdGhhbiB0aHJlZSBhIG1vbnRoLiBGTE9UIG11c3QgYmUgaW5mb3JtZWQgb2YgZXhjZXB0aW9ucy4gQmVpbmcgYWJsZSB0byBzaWduIGEgcmVxdWVzdCB3aXRoaW4gMjQgaG91cnMgcmVxdWlyZXMgdG9vbHMgd2hpdGhvdXQgd2hpY2ggdGhlIHJlc3BvbnNlIHRpbWUgY2Fubm90IGJlIGhlbGQgaW4gY2FzZSBhY2Nlc3MgdG8gdGhlIGludGVybmV0IGlzIGxpbWl0ZWQuPC9wPjxwPkNvbXBlbnNhdGlvbiBmb3IgQG1ocHMgd2lsbCBvY2N1ciBpbiA5MC1kYXkgY3ljbGVzLCBmb3IgYSB0b3RhbCBvZiA0IGN5Y2xlcy4gQnkgdGhlIGVuZCBvZiBlYWNoIGN5Y2xlLCBhIHRvdGFsIG9mIGFtb3VudCBvZiA0MzUgTkJUIHNoYWxsIGJlIHBhaWQgdG8gQG1ocHMsIGNvbmRpdGlvbmFsIG9uIHNhdGlzZmFjdG9yeSBwZXJmb3JtYW5jZSwgd2hpY2ggc2hhbGwgYmUgbWVhc3VyZWQgaW4gdGVybXMgb2YgaGlzIHByZXNlbmNlLCBlZmZvcnQgYW5kIGNvbnRyaWJ1dGlvbi4gQG1ocHMgcmVzZXJ2ZXMgdGhlIHJpZ2h0IHRvIHdpdGhkcmF3IGZyb20gaGlzIHNlcnZpY2UgaWYgaGUgZG9lcyBub3QgcmVjZWl2ZSB0aGUgZnVsbCBhbW91bnQgb2YgY29tcGVuc2F0aW9uIGJ5IHRoZSBlbmQgb2YgYW55IGN5Y2xlIG9yIGJ5IHBlcnNvbmFsIGRpc2NyZXRpb24uPC9wPjxwPlRoZSBzZXJ2aWNlIG9mIEBtaHBzIGFuZCB0aGUgY29tcGVuc2F0aW9uIGN5Y2xlcyB3aWxsIGNvbW1lbmNlIGZyb20gdGhlIHBhc3NhZ2Ugb2YgdGhpcyBtb3Rpb24uPC9wPjwvbW90aW9udGV4dD48L3A+PHA+PGNvZGU+PSMjPSMjPSMjPSMjPSMjPSMjIE1vdGlvbiBoYXNoIGVuZHMgd2l0aCB0aGlzIGxpbmUgIyM9IyM9IyM9IyM9IyM9IyM9PC9jb2RlPjwvcD48L21vdGlvbmhhc2g+"
}
That way the original text used and voted on can be reproduced, since it cannot be reproduced from the codex format.
Is this in the direction you envisioned?
2 Likes
I think so
It is missing a definitions section (in section 1.1 you do a combination of definition and membership, so we should probably break that apart), but on the whole I think it codifies more clearly what the motion was about.
It might be worthwhile to standardize the compensation across members, and then have a section that basically says, “The members of the FLOT are as follows: […].”
Thinking about the kinds of questions I want to ask about FLOT are…
- Definition:
- what is it?
- what does it do?
- what is the context behind it?
- Policy:
- how do you join?
- how are they compensated?
- how do you leave?
- what happens when things go wrong? what’s the recourse?
- Members:
- who is a part of it?
- how long have they been members? (diff helps with this)
Just a guess at potential structure, but I think we’re in agreement in the broad sense, which is “let’s get the facts down in a somewhat structured way, and then we can make it prettier using something else”.
In the future, my hope is that a git diff would be the representation of motion itself, with the diff containing:
- The codified changes (ie, updating JSON docs)
- (optional) Supporting text added as a plaintext file (Markdown can be used for formatting)
The hash would be validated by taking the RIPEMD-160 of the diff body, which makes it super easy to validate:
$ git show 9af1128 | openssl rmd160
(stdin)= 0a46538843755990fac136b184bcbccf42e1a620
The validation script becomes pretty simple (pseudo-code…):
for each $commit
hash = `git show $commit | openssl rmd160 | cut -d' ' -f2`
assert motion_passed($hash) == true
Proposing a motion is effectively proposing a git commit, so when you have it all packaged up, the validation logic is super easy (no more questions about which browser you’re using).
To catch up, we’d effectively need to pass a motion that is “codify everything” as the initial diff. Not exactly fun, but the sooner the better.
I think for starters, you’re right that we need to include the original representation, and base64 seems like a reasonable enough choice.
3 Likes
@jgeewax you’re on fire!
@all others:
Please consider participating in the poll:
https://discuss.nubits.com/t/idea-nulaw/3250/10?u=willy
1 Like
On geez, I keep having these epiphanies every time you post. My brain is just so hard wired to think about how Nu works in a certain way because I’ve been grinding away at it for almost two years. I’m still thinking in terms of ad-hoc proposals and motions. Even when willy proposed it. Derp. (I’m mostly here for my looks anyway).
What I put together for one past motion is intended format to rewrite all previous (and future) motions into a unified organized JSON document.
Now with that understanding I can really appreciate the rest of what is being proposed here.
I have some more thoughts to share but its 2am and they can sit for tomorrow.
You are gorgeous, no one can deny it.
1 Like
We can have it on the front of the NuLaw book. Would be cute
2 Likes