Hey man Omar from Kueski, good to see you are progressing on this. I will definitely download the CLI program and start playing with it!
Show HN: Dharma – Programmable Peer-To-Peer Loans Using Ethereum Smart Contracts
61–65 of 65 posts
Re: Show HN: Dharma – Programmable Peer-To-Peer Loans Using Ethereum Smart Contracts
#62Earlier quoted context omitted.
Not off topic in the slightest! In fact, all too topical, given the past few weeks. For what it's worth -- I'm a former engineer at Coinbase / Google and recently graduated from Stanford. Though I didn't touch Solidity as part of my work at Coinbase, I've been following Ethereum extremely closely since its beginnings, and any mainnet release I'd push forward would certainly undergo rigorous third-party auditing at th…
This project is simultaneously a great example of the democratizing effect of Ethereum while also being truly terrifying. A Stanford '17 grad with a few internships worth of industry experience is able to create and deploy a peer-to-peer loan infrastructure. This isn't meant to be demeaning in any way, I'm just remarking on how incredible of an accomplishment it is for both you and Ethereum that the previous sentence…
>I need to at least mention that, well, this project is probably a bomb and you should be really careful with it. I, at least, wouldn't want to be the next DAO dev (e.g. project takes off quickly, unseen exploit exists, I lose some 10's of millions of other people's money) at mostly a personal (I'd feel guilty) and career trajectory level.
>The Parity multi-sig bug occurred in a solidity shop that was founded by the father of the language itself. It got past a serious audit and had the best eng process known (for solidity) enforced. The odds that your code -- currently unaudited correct? -- doesn't have an exploit are, while impossible to accurately calculate, quite remote.
I think this is very inaccurate. There have been devastating bugs in Ethereum, namely the bug in the DAO and the one in the Parity multisig contract. But there are numerous smart contracts that have not been found to be vulnerable. You cannot extrapolate what happened to two contracts to the entire ecosystem. It's inaccurate to claim that the probability that the loan contract he's working on will not have critical bugs once it's live is "remote", and a red herring to point out that it is unlikely to be bug free now, when it is still in development.
Re: Show HN: Dharma – Programmable Peer-To-Peer Loans Using Ethereum Smart Contracts
#63Earlier quoted context omitted.
This project is simultaneously a great example of the democratizing effect of Ethereum while also being truly terrifying. A Stanford '17 grad with a few internships worth of industry experience is able to create and deploy a peer-to-peer loan infrastructure. This isn't meant to be demeaning in any way, I'm just remarking on how incredible of an accomplishment it is for both you and Ethereum that the previous sentence…
>I need to at least mention that, well, this project is probably a bomb and you should be really careful with it. I, at least, wouldn't want to be the next DAO dev (e.g. project takes off quickly, unseen exploit exists, I lose some 10's of millions of other people's money) at mostly a personal (I'd feel guilty) and career trajectory level. >The Parity multi-sig bug occurred in a solidity shop that was founded by the…
I had a long discussion about this topic here: https://news.ycombinator.com/item?id=14807779
> I think this is very inaccurate.
Perhaps, though keep in mind I did say that it is "[the odds that this code has a serious bug are] impossible to calculate accurately" and there's a reason for that. I'd argue that it wasn't an imprecise statement. Gavin was the father of solidity, put in the process at Parity, had an audit team, and the $200M multi-sig bug still got through. If the top-tier team and process failed, it's not imprecise to say that a more complex code base that didn't follow the best approach available likely has a bug. This is invariant on the phase of development.
Moreover, I was cautioning OP to be careful. One valid response to that is what he's already going to do (get an audit). This makes a bug less likely. The next phase would be a Bankor-style pilot+bounty. After that... well we just don't know.
> But there are numerous smart contracts that have not been found to be vulnerable.
Sorry, but unexploited is not unexploitable. Many/most of these contracts are probably unexploitable, but the problem is that we can't be sure. To me, smart contract construction on the EVM/Solidity is closer to a "rolling your own crypto" grade problem, which is something that after years of massive exploits we've all agreed that you do not ever do it, vs building a webapp. Long term as tooling + approaches + standards + the language itself mature, it'll come closer to "backend programming at a hedge fund/bank" where it's doable but you need to be responsible.
Re: Show HN: Dharma – Programmable Peer-To-Peer Loans Using Ethereum Smart Contracts
#64Earlier quoted context omitted.
The white-paper has more detail than the homepage and I recommend reading it for a better understanding of the project From what I understand, third party entities responsible for vetting borrowers. These entities referred to as "Risk-Assessment Attestor"(RAA) are incentivized to do quality risk assessment as they get a piece of the loans they vet. Here's a section from the white paper, discussing the importance of R…
What happens when the borrower and the RAA turn out to be the same entity?
A series of defaults where the RAA shrugs after questions about their legitimacy surface, I bet.
Re: Show HN: Dharma – Programmable Peer-To-Peer Loans Using Ethereum Smart Contracts
#65Earlier quoted context omitted.
>I need to at least mention that, well, this project is probably a bomb and you should be really careful with it. I, at least, wouldn't want to be the next DAO dev (e.g. project takes off quickly, unseen exploit exists, I lose some 10's of millions of other people's money) at mostly a personal (I'd feel guilty) and career trajectory level. >The Parity multi-sig bug occurred in a solidity shop that was founded by the…
I had a long discussion about this topic here: https://news.ycombinator.com/item?id=14807779 > I think this is very inaccurate. Perhaps, though keep in mind I did say that it is "[the odds that this code has a serious bug are] impossible to calculate accurately" and there's a reason for that. I'd argue that it wasn't an imprecise statement. Gavin was the father of solidity, put in the process at Parity, had an audit…
>it's not imprecise to say that a more complex code base that didn't follow the best approach available likely has a bug.
It is imprecise because the Parity multisig bug is an outlier. There are numerous contracts both by 'crack' teams like Parity, and by teams with a less established reputation, that have not been found to have a critical bug in production.
Therefore, the evidence that most contracts have serious bugs is simply absent, and one can't accurately state that the odds of a contract being launched without a serious bug is "remote".
>Moreover, I was cautioning OP to be careful. One valid response to that is what he's already going to do (get an audit). This makes a bug less likely. The next phase would be a Bankor-style pilot+bounty. After that... well we just don't know.
Yes and I agree with your advice.
>Sorry, but unexploited is not unexploitable.
And the possibility that it is exploitable does not mean it is exploitable. I'm not saying that it's out of the question that there are numerous contracts out there with exploits. I'm saying that we can't assign a probability to that being the situation.