get off your back? you have been on matts back in this thread since before he even joined it. don’t think u have a leg to stand on telling me to get off your back while you try to silence critics of this proposal.
i don’t think you should be slandering other people’s character, engaging in ad hominem, spreading rumors about secret identities, all because some inconvenient facts about your precious ren were brought up. matt hasn’t said anything untrue on this thread or twitter as far as i can see. i see him and rob and other ppl on this thread trying to raise awareness that ren custody is not decentralized as was originally advertised on this thread and i think that is a good and relevant thing for yfi voters to know before adding renbtc. take the criticism with grace, be respectful towards others and maybe you’ll get treated the same in return.
I agree with the critics of this proposal. I proposed it, the community decided against the implementation of the proposed strategy 1 which is the first of a multi stage progressive strategy implementation plan. Whatever happens next I’m good with it, won’t stop me proposing whatever good ideas I can as long as they include decent specs. The specific criticism of the proposal strategy I do not believe to have been related to the specifics of the Ren project. If I’m mistaken there, please do point it out to clarify.
Please reference the specific slander and ad hominem, I will be more than happy to apologize and take responsibility for misconduct.
Regarding secret identities, I noticed the username, noticed it was mentioned in twitter, then recall it somehow being debunked which is fine. I’ll update the post to mention it’s debunked.
If you check the reference links, I copy pasted the intro line from Ren’s post on Maker proposals forum.
Agreed on good and relevant, as for specifics you may refer to @amcassetti 's post
insinuating the points he brings up aren’t valid because of what project he works on (ad hominem) and that he puts his monetary incentive ahead of the truth (character slander).
Bitgo may be safer against a collusion attack. It seems to me Ren is safer against general hackers as the password doesnt exist on paper anywhere. Bitgo is a custody themselves, do they have an army defending the billions custodied? Guess what? Ren doesnt have to. At the flip of a switch (see how andre handed out multisig) they can make Ren totally unstoppable in a way that Bitgo couldnt do should a powerful entity turn on them, such as say NYC sues Bitgo next
Wouldn’t it be safer to at least wait till greycore is open-sourced? Its about to be published soon anyway. It would be the prudent thing to do. If anyone wants to argue ren is safe, then well, it would be open sourced already. Lets give it a solid 1-2 weeks after publish.
Ren now has a $124m honeypot without proper public scrutiny. A few weeks isn’t going to hurt anyone… That massive honeypot will attract the best hackers around, if it passes 1-2 weeks opensourced, it’s good to go.
I am under the impression Ren has shared their code with key integrators, such as Curve
Edit: so if this is our requirement we could easily put on hold until Andre can audit code. But that may come from open sourcing or it may come from team choosing a collaboration
RenVM is being rolled out per Andreessen Horowitz’s guidelines on Progressive Decentralization
RenVM is being rolled out in progressive stages per Andreessen Horowitz’s guidelines on Progressive Decentralization.
The three RenVM Mainnet stages are:
Mainnet Subzero (Released May 27th, 2020 - Our current Stage)
Mainnet Zero
Mainnet One
This info is outlined in our Phases documentation which can be found in our Wiki. More specifics on RenVM SubZero:
At the beginning of phase sub-zero, the Ren core developers will secure and maintain all nodes in the Greycore, and the Greycore will be the only group of nodes responsible for consensus and execution. Community nodes will be responsible for operating the P2P networking, including storage. This allows the Ren core developers to:
-respond quickly to downtime in the event of unexpected shutdowns,
-respond quickly to bugs that are found, by deploying fixes or triggering an emergency shutdown,
-help recover funds in the event that third-party developers make mistakes in their implementations, and
-help recover funds in the event that users make mistakes when interacting with RenVM.
Important technical nuance on sMPC | Nodes collectively sign for one (1) BTC address RenVM uses secure multi-party computation (sMPC) to power its network of nodes (collectivity called RenVM). What makes RenVM unique is that it uses sMPC and this essentially allows for a (one) private key to be broken up into small pieces, amongst all the nodes, that then collectively come together and sign an ECDSA key (i.e. a BTC private key) whenever they are requested to mint and burn assets (BTC, renBTC, etc). A very important aspect of sMPC is that no one node knows the private key, the info is hidden from everyone, including the nodes themselves.
These 13x randomly geo-distributed (Greycore) nodes use sMPC to keep the key safe. Nodes are run by the team at the moment, expanding to others at the inception of Mainnet Zero. Sharding (the use of multiple private keys), also comes in the next phase.
Takeaway: RenVM is being rolled out in a progressive way towards full decentralization, we’ve communicated this fact and believe it is the safest and most prudent way to protect users’ funds. There are trade-offs of course (remaining more centralized in the beginning), but we believe this is more prudent than releasing an untested protocol into the wild from day one. https://a16z.com/2020/01/09/progressive-decentralization-crypto-product-management/
Thank you for creating this suggestion for adding renBTC.
I am also sure that RZL sMPC code will be published along with the code security audit report from ToB. Yearn community would be wise to wait for this to happen and only then consider this initiative. Also thank you to FUD-satellites (such as Matt) that are haunted by the rapid adoption of RenVM in DeFi-ecosystem.
You help us, you make us better.
what is more important and relevant here, some vc firm’s self-made “guidelines” or fincen regulations that state that a custodian of funds has compliance duties such as kyc aml, suspicious activity reporting etc etc which afaict ren does none of?
found on fincen website:
if the person combines the services of a multiple-signature wallet provider and a hosted
wallet provider, that person will then qualify as a money transmitter.
from page 17 here. if renbtc has any u.s. based users this applies to you.
imo the even more prudent thing would be to follow the law so u don’t get goxed (remember gox had millions of dollars seized from them by dhs for noncompliance), or maybe hold off taking people’s money until the decentralized system is ready to go so you dont expose your company and your users to the security and regulatory risks associated with being a centralized custodian of funds. ianal.
Closed code of the MPC algorithm (although many other code is open) - this argument will not be relevant in the near future.
Greycore controlled by REN team - I assume that the team already knows which companies will participate in Graycore. So this argument will also lose its relevance.
Before these two arguments become irrelevant, you need to come up with new arguments to criticize REN. Go for it!
One thing I dont like about this proposal is you’re cramming everything in to one yip which are separate issues. The yen vault is one, the strat is completely different and they should NOT be in the same YIP. Plus we dont vote on strats Andre and the multisig deal with them for now.
funds are safu