search

shea256 / proposed-bitlicense-regulations

The Proposed BitLicense Regulations for The State of New York (Thanks to Patrick Murck for the idea + support to convert this to markdown)
28 stars 18 forks source link

"control" is too broad #18

Open vogelito opened 10 years ago

vogelito commented 10 years ago

I don't believe this should apply to an entity that holds one of N multisigs in a wallet.

pmlaw commented 10 years ago

This is certainly an improvement. I think what's really missing is an accurate definition of custody. What constitutes custody not just in multi-sig but also split-key scenarios? It's a tricky question.

If the policy goal is to protect consumers from loss shouldn't the regs define a spectrum of custody risk and scale bonding and insurance obligations to correspond with actual consumer risk?

vogelito commented 10 years ago

@pmlaw I'd like to voice my concerns to Ben Lawsky through a formal comment under the NY state regulatory process but have never done anything like this in the past. Any pointers before I do so?

@rxl are you planning on merging these pull requests and then submitting a formal comment yourself or what is your plan with this repo?

pmlaw commented 10 years ago

@vogelito I hope you do. The DFS will set forth the procedures for submitting comments when the proposal is formally published on July 23rd.

shea256 commented 10 years ago

@vogelito I'm torn on this but I had the idea of keeping the master codebase pristine and true to the original document, allowing other branches and forks to incorporate changes. Would love your thoughts on this, though.

I also made @pmlaw a collaborator so he has the ability to merge and commit code.

vogelito commented 10 years ago

@rxl - Two suggestions: either create a branch with the original and let master evolve. Or let a branch evolve and keep master pristine.

But something should evolve :)

markdavidlamb commented 10 years ago

@rxl , @vogelito . I think we should have this branch be the master and let it evolve and grow. Primarily because we've already done commits, comments, pulls, etc to this version. This is the version people first go to and they should see the work being done towards fixing it and making it better. Ideally we could get some great contributions and actually make a serious attempt at fixing the problems with the NYDFS's proposed regulations.

vogelito commented 10 years ago

@markdavidlamb yeah, I like that. The original could be tagged or branched and referred to.

dabura667 commented 10 years ago

@rxl Just make a pristine branch called "Original" or something and merge everyone's proposals that seem to be at a consensus to master.

You could always link at the top to the "original" branch.

pmlaw commented 10 years ago

@markdavidlamb @dabura667 I think this is the right approach. It's good to have an original branch out there for people to work from as well but people have already invested time and effort into spotting issues and making changes to this version.

shea256 commented 10 years ago

OK cool. I'll create an ORIGINAL.md and then we can support merging of pull requests. Patrick, I can absolutely merge pull requests but I trust your judgement more than my own. Would you like to take charge of that?

pmlaw commented 10 years ago

@rxl Sure thing.

shea256 commented 10 years ago

Awesome, sounds like we have a plan then!

dabura667 commented 10 years ago

I was thinking instead of making an Original.md file, we could make the original document be README.md on a SEPARATE BRANCH called "Original"

That way Lawsky could just navigate his browser to

https://github.com/onenameio/proposed-bitlicense-regulations/compare/master...original

And he would have a nice looking red and green DIFF for him to look at.

Comparing two long documents that are on two separate webpages would require much effort... like opening two tabs and switching back and forth to see the differences.

Looking at a github DIFF (and linking to it at the top of the README.md) would be VERY easy to understand, even for people who don't know how to use github.

vogelito commented 10 years ago

@dabura667 :+1:

dabura667 commented 10 years ago

@vogelito #22 :+1:

markdavidlamb commented 10 years ago

:+1:

shea256 commented 10 years ago

Sure, I think a diff is a much more powerful way to do it. I simply included the original because it might not be clear to people hitting the page that the page they see is not the original. And if the viewer is not a hacker, he/she won't even know what a branch is, so they would have to be explicitly linked.

Maybe there's a way to have a big URL at the top of the doc like "see original" and then it links to the branch. That could solve these issues.

dabura667 commented 10 years ago

@rxl luckily, I have added such a pull request #22

Now all I need is for an "original" branch to exist where README.md is the original. (so that it will make a diff with the README.md on master) and you can leave Original.md on master if you want to.