Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chasing the DAO Attacker’s Wake – A second exploit

pdaian.com

Post reply on HN
Print view View original

171–180 of 180 posts

Re: Chasing the DAO Attacker’s Wake – A second exploit

#171

Post by DennisP »

dragonwriter wrote: post #138
DennisP wrote: post #133

Earlier quoted context omitted.

It's software, not really comparable to an English-language contract. Most software is much bigger than that. Five pages is an outside estimate, for something like a currency exchange. My crowdfunding contract is about two pages, and the vault is one.

> It's software, not really comparable to an English-language contract. If the point is to be an alternative to normal, "dumb" contracts, than that is exactly what it needs to be comparable to.

Smart contracts are not an alternative for things like employment, NDAs, and IP transfer. But how long would your contract be if you were setting up a currency exchange?

And how much software would you have to write in addition to that? On Ethereum the back-end software and the "contract" are the same thing, since the software enforces the terms.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#172

Post by vessenes »

drcode wrote: post #72
vessenes wrote: post #64

Earlier quoted context omitted.

The typical solidity dev is "but mutexes cost so much gas!" There's an optimization problem not yet sorted out here. If I were king of ethereum, (happily I'm not), I'd make a very cheap mutex support part of the eth vm and encourage solidity and serpent devs to use it as needed.

I suspect we'll see something like mutexes in the next ethereum EVM revision.

Yes, that would be a kind and fine thing to do, or at least change the cost of a specially designated bool argument to something cheap. You get one per contract, kind of thing. Or you pay on deployment.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#173

Post by homogeneous »

jsprogrammer wrote: post #162
homogeneous wrote: post #159

Earlier quoted context omitted.

I'm not really sure what you're asking for. If you're looking for a system capable of accepting payment without an attendant there are many. Here is just one example: http://bw-2e2c4bf7ceaa4712a72dd5ee136dc9a8-bwcore.s3.amazona... If this is not the type of device you're talking about please be more specific.

I was thinking of a system that would let you place a deposit immediately before rental (imagine a rental car in a public lot) and then automatically receive your deposit back when you are done with the car (which was possibly even left in a different lot). I'm thinking the car would use its sensor system to detect if any damage might have occurred and if not, it could trigger the return of a deposit as soon as the v…

The system you describe is already possible today without the need for a smart contract.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#174

Post by stcredzero »

tremon wrote: post #168
heliumcraft wrote: post #88

Earlier quoted context omitted.

Essentially this is the equivalent of a dev mistakely using an eval in the wrong place in a nodejs code. But all these articles are making it sound like the Ethereum team created the DAO and this issues affect Ethrereum as whole, which just isn't true.

The way I see it (continuing the simile): if you're writing something as critical as monetary transactions, everywhere is the wrong place to use eval in nodejs code. And when you're writing a dedicated language for monetary transactions, including eval in your API is just as wrong. The last part is why this issue affects all of ETH. Solidify is a new language, specifically designed for Ethereum. If the response to co…

If the response to contract issues like this is "but that's a known failure mode, don't do that", then that signals a problem with the language, not just the contract code.

It also signals a problem with the culture, with respect to the perceived amount of rigor required by the problem domain.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#175

Post by jsprogrammer »

homogeneous wrote: post #173
jsprogrammer wrote: post #162

Earlier quoted context omitted.

I was thinking of a system that would let you place a deposit immediately before rental (imagine a rental car in a public lot) and then automatically receive your deposit back when you are done with the car (which was possibly even left in a different lot). I'm thinking the car would use its sensor system to detect if any damage might have occurred and if not, it could trigger the return of a deposit as soon as the v…

The system you describe is already possible today without the need for a smart contract.

Can you link to an implementation?

Admittedly, I don't really understand the distinction of a "smart contract". I am only describing the function of the system that there was some confusion over.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#176

Post by homogeneous »

jsprogrammer wrote: post #175
homogeneous wrote: post #173

Earlier quoted context omitted.

The system you describe is already possible today without the need for a smart contract.

Can you link to an implementation? Admittedly, I don't really understand the distinction of a "smart contract". I am only describing the function of the system that there was some confusion over.

Ok. What I'm saying is that the ability to accept and relinquish an automated security deposit does not require a decentralized technology such as ethereum or even bitcoin.

A machine (like the one I linked above) can accept money and dispense money at the discretion of the business rules that determine the appropriate criteria for these operations (via car sensors or whatever).

Re: Chasing the DAO Attacker’s Wake – A second exploit

#177

Post by jsprogrammer »

homogeneous wrote: post #176
jsprogrammer wrote: post #175

Earlier quoted context omitted.

Can you link to an implementation? Admittedly, I don't really understand the distinction of a "smart contract". I am only describing the function of the system that there was some confusion over.

Ok. What I'm saying is that the ability to accept and relinquish an automated security deposit does not require a decentralized technology such as ethereum or even bitcoin. A machine (like the one I linked above) can accept money and dispense money at the discretion of the business rules that determine the appropriate criteria for these operations (via car sensors or whatever).

Yes, but that requires a fixed machine (or a cash lock box on every vehicle?).

Shouldn't I be able to just leave the car anywhere in a city?

Re: Chasing the DAO Attacker’s Wake – A second exploit

#178

Post by homogeneous »

jsprogrammer wrote: post #177
homogeneous wrote: post #176

Earlier quoted context omitted.

Ok. What I'm saying is that the ability to accept and relinquish an automated security deposit does not require a decentralized technology such as ethereum or even bitcoin. A machine (like the one I linked above) can accept money and dispense money at the discretion of the business rules that determine the appropriate criteria for these operations (via car sensors or whatever).

Yes, but that requires a fixed machine (or a cash lock box on every vehicle?). Shouldn't I be able to just leave the car anywhere in a city?

> Yes, but that requires a fixed machine (or a cash lock box on every vehicle?).

Of course not. Do it exactly like how rentals work today except in an app instead of in person. Put in your bank card info, a hold is placed on your card, when the vehicle is returned the hold is released and the service fee is charged.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#179

Post by malandrew »

djcapelis wrote: post #43
malandrew wrote: post #38

Earlier quoted context omitted.

just for a point of reference: https://www.torproject.org/about/board.html.en granted a few people with the right background, but also a bunch with backgrounds like those you listed.

You may want to read that list again. Over half of Tor's board of directors have deep experience in software security. And even their attorney has given talks at hacker conferences and is very, very well respected. Tor's board shows precisely the opposite: a deep list of well qualified people to run an organization that works on an important piece of security software.

I did read it, which is why I said " a few people with the right background". I counted less than half, but my point was that it's okay for people without technical background to sit on the board of well known crypto projects.

Re: Chasing the DAO Attacker’s Wake – A second exploit

#180

Post by IncRnd »

Inthenameofmine wrote: post #68
AJ007 wrote: post #20

Nearly a year ago I made the comment -- "Who are these people[1] and what credentials do they have to build and run a cryptocurrency platform?" [1] https://angel.co/ethereum-1 Today, not a single cryptographer, mathematician, or anyone with software security experience is listed on the Ethereum Foundation member list[2]. I am not attacking any individuals by themselves, but as a group this says a lot. For the record,…

Generally speaking the longer someone has been in a specific field, the lower the probability of them thinking of a new method or agreeing with new things. This is a general pattern across the board with anything ews, startups, projects, etc. As somebody working with a lot os startups, having somebody with 30 years of a specific core competency on the founding team is a huge red flag.

That's ridiculous.
Post reply on HN