[Idea] NuLaw - 60 NBT bounty!

willy · December 29, 2015, 8:30pm

Hey howdy hey there,

I had a quick idea on my commute, so don’t judge me if it turns out to be useless

Problem:

There are a lot of motions that passed so far. Getting a quick overview what rules are currently in place requires you to enjoy a lot of forum posts.

Solution:

I suppose having all of them on one page would be cool.

This way we would have rule book like

§ 1 - @woolly_sammoth has the most awesome beard.
§ 2 - @willy shall not pull on @woolly_sammoth’s beard.

and so on.

Changing existing rules would than look like this:

I hereby propose to change § 2 of the NuLaw book to
"§ 2 - @willy shall be allowed to pull on @woolly_sammoth’s beard."

Motion hash: 1323489723adsasdaiuhsiSKsjkl

Here’s the clue: The site will be edited with github pull requests.

When the motion passed, I’ll go on github and create a pull request for my fresh piece of law.
A couple of NuDruids (don’t mix this up with NuDroid), who are allowed to merge the repository, will then allow my request into the master branch and thus the website.

masterOfDisaster · December 29, 2015, 8:35pm

Great idea!
I already wrote a concern about that in a recent conversation

[quote]
The forum already is cluttered and will rather sooner than later require some more structure like wiki threads that track activities just like the “voting hotlist” does.[/quote]

Your proposal is very useful to get an overview and track changes!
I don’t see why it wouldn’t work this way.

willy · December 29, 2015, 8:43pm

https://docs.nubits.com/ looks like a good place to use.

erkan · December 29, 2015, 9:27pm

+1, I like this

willy · December 29, 2015, 9:58pm

just gonna leave this here

Sentinelrv · December 29, 2015, 10:43pm

You could also call them “Nu Regulations” as well.

crypto_coiner · December 30, 2015, 12:32am

Sounds great and indeed like a simple working solution.

Financisto · December 30, 2015, 1:04am

Good idea: plain and simple!

willy · December 30, 2015, 10:51am

I thought we would have to books

Book I - Rules / Laws (e. g. pool operators shall allow a SAF of 1%)
Book II - Guidelines (e. g. Nu shall create Nu-SDR)

I’m currently discussing the implementation of a project like this into docs.nubits.com with @CoinGame.

Looking at http://blockexplorer.nu/motions/success, there is a lot of work to be done.
Any volunteers yet?

Maybe we can distribute the work load like volunteer 1 gets motions from 09/14 till 12/14 and so on.

willy · January 26, 2016, 4:38pm

Okay, no it seems.

I can understand. Reading and reviewing about 48 motions is a lot of work.

What would shareholders be willing to pay for that work?

0 NBT
1-100 NBT
101-500 NBT
501-1000 NBT
1001-2000 NBT
More than 2000 NBT

0 voters

Show results

Voting period: 14 days from now.

CoinGame · January 26, 2016, 4:43pm

Can we like… hire an actual lawyer to create legal documents for a DAO? That would be interesting.

willy · January 26, 2016, 4:52pm

Why not. But I guess that would require around 5-10k?!

CoinGame · January 26, 2016, 4:53pm

Maybe it’s a bit premature but it would be fun seeing future articles say “the Nu legal team has…”

masterOfDisaster · January 26, 2016, 4:54pm

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

jgeewax · February 2, 2016, 3:15pm

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?

CoinGame · February 2, 2016, 5:47pm

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.

jgeewax · February 2, 2016, 7:12pm

[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?

CoinGame · February 2, 2016, 7:42pm

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.

jgeewax · February 2, 2016, 8:04pm

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.

jgeewax · February 3, 2016, 12:28am

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.