"control" is too broad #18
Conversation
|
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? |
|
@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? |
|
@vogelito I hope you do. The DFS will set forth the procedures for submitting comments when the proposal is formally published on July 23rd. |
|
@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. |
|
@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 :) |
|
@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. |
|
@markdavidlamb yeah, I like that. The original could be tagged or branched and referred to. |
|
@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. |
|
@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. |
|
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? |
|
@rxl Sure thing. |
|
Awesome, sounds like we have a plan then! |
|
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 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. |
|
👍 |
|
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. |
I don't believe this should apply to an entity that holds one of N multisigs in a wallet.