Understanding Ethereum Smart Contracts • Hacker News Board

Re: Understanding Ethereum Smart Contracts

#151

Post by tlrobinson » Thu, Nov 30, 2017, 3:37 AM UTC

joosters wrote: post #131

tlrobinson wrote: post #128

Earlier quoted context omitted.

The difference is there is no counterparty risk. Not with the gas station, not with Visa. Admittedly that’s not a big problem with gas pumps (at least where I live, though card skimming is definitely a thing) but you can easily imagine other use-cases. For example your computer could automatically pay an untrusted WiFi hotspot per MB (and automatically pay the VPN you use to secure said untrusted WiFi hotspot) Zero c…

There's still counterparty risk: I could start paying the wifi hotspot but there is no guarantee that it will let me use what I've paid for. At any point, the next microtransaction could fail because the counterparty decides to steal my cash.

My point is if you can make the microtransactions arbitrarily small you can make the counterparty risk negligible.

If I’m sending 1 cent micropayments continuously as long as the services are being delivered (e.x. 1 cent per 1 MB WiFi, 0.1 kWh electricity, or 0.5 oz gasoline, etc) then the most that can be stolen is 1 cent, so why would they bother?

Re: Understanding Ethereum Smart Contracts

#152

Post by alasdair_ » Thu, Nov 30, 2017, 4:08 AM UTC

SanFranManDan wrote: post #55

jackpeterfletch wrote: post #51

Earlier quoted context omitted.

True, but the extra code around those solutions cost gas, of which your looking at around 500 lines worth. How long is BigDecimal.class?

Likely you don't need a generic implementation of Decimal. What money do you want to represent, they all have a "atomic value". For instance, when working with dollars store cents. When working with Eth, store wei. etc. I can't think of a use case of money that needs decimals except maybe computing ownerships percentage. but that should never be stored, but rather computed. Anything that needs to be converted is a "f…

>For instance, when working with dollars store cents.

How does this work of you are, say, coding for a gas station where the price is in 1/10ths of a cent?

Alternatively, how does your banking application handle adding 10% interest to a bank account with 1c in it?

Re: Understanding Ethereum Smart Contracts

#153

Post by alasdair_ » Thu, Nov 30, 2017, 4:11 AM UTC

decentralised wrote: post #13

scandox wrote: post #10

What I'd greatly appreciate is a walk through of a plausible real world use case. I find it hard to concentrate on the technology itself until I understand the application.

Crowdfunding (ICOs) is a use case. DNS (ENS) is a use case. Organisational Transparency (Aragon) is a use case. Prediction Markets(Augur) are a use case. Electricity Markets (Grid+) are a use case. International payment card with zero fees (TenX) is a use case. I can go on for a while longer, there are hundreds of use cases but the question is: what would be a use case for you?

>Prediction Markets(Augur) are a use case

The difficult part about something like a prediction market is that it's hard to get an authoritative source for the result. How can you prevent a fake result being sent out, for example?

Re: Understanding Ethereum Smart Contracts

#154

Post by Slartie » Thu, Nov 30, 2017, 10:11 AM UTC

Kranar wrote: post #138

cosmotron wrote: post #121

Earlier quoted context omitted.

> [...] only to eventually encounter all the issues that floating point was invented to solve. When they encounter those issues they then end up having to adapt their code only to basically re-invent a broken, unstable quasi-floating point system when they would have been much better off using the IEEE floating point system [...] Would you care to elaborate on some of these issues? I'm genuinely curious.

Sure, I'll embarrass myself here and use myself as an example since this is how I actually came to even learn about this to begin with. When I started working in finance straight out of school (not in HFT at the time), I naively accepted the dogma that money should never be represented using floating points. I mean everywhere I went I would read in bold letters don't use floating point! Don't use floating point! So I…

Thanks for the detailed explanation of your thought process.

I guess you fall into the few percent of developers who are NOT meant to be addressed by the general rule of "don't use float for money". Like with all "general rules" in software development, it is intended to guide the >90% of devs who don't want and sometimes also aren't capable of fully grasping the domain they're working in and the inner workings of the technology they use. The majority of devs need simple, clear guidelines that prevent them from making expensive mistakes while wielding technology that's made up of layers and layers of abstractions, of which some (or even most) are entirely black boxes to them. "Playing it safe" often comes with other shortcomings like worse performance, and if those are not acceptable in a specific scenario, you need a developer who fully grasps the problem domain and technology stack and who is thus capable of ignoring the "general rules" because he knows exactly why they exist and why he won't get into the troubles they are intended to protect you from.

I have long thought that every developer under the sun should strive to get up to this point, and I still think that it is an admirable goal, but I came to understand that not all developers share this goal, and that even if someone tries to learn as much as possible about every technology that he comes in contact with, he will never be able to reach this state of deep understanding in every technical domain imaginable, as there are just too many of them nowadays. We all, no matter how smart we are, sometimes need to rely on "general rules" in order to not make stupid mistakes.

Re: Understanding Ethereum Smart Contracts

#155

Post by patrickk » Thu, Nov 30, 2017, 10:20 AM UTC

alexasmyths wrote: post #111

Brotkrumen wrote: post #73

Earlier quoted context omitted.

The only thing seckimjohn showed is that contracts, paper or "smart", are only as good as they're written. Since contracts such as _red gave, "we are friends, this is our company, we share the EBT equally", exist right now, it's a perfectly realistic use case for a smart contract. Hell, I'd even do that for a small project. Smart contracts being fixed and errors being exploitable is a valid criticism but it's not the…

""smart", are only as good as they're written" There are so many things that go into contracts that cannot be articulated in 'code' that this all hardly makes sense. Employment contracts are long. Comp packages can be complex. And we all live in countries with employment laws etc. that require these things anyhow. I don't see any actual real-world cases for Eth contracts just yet.

The earliest smart contracts will likely involve things that are relatively easy to verify, e.g. a bet that the price of ETH will be above X at Y date and time.

Ensuring that accurate, real-world data gets entered into the blockchain to enable broadly useful smart contracts is going to be an interesting area to monitor over the next few years.

Augur attempts to align people's incentives to accurately report on real world events, like political events (aka Oracles). Axa pays out on delayed flights with a new flight insurance product[1], from data gathered from public flight information, which triggers an automated payout.

[1] https://fizzy.axa/

Re: Understanding Ethereum Smart Contracts

#156

Post by Slartie » Thu, Nov 30, 2017, 10:22 AM UTC

simonbyrne wrote: post #124

Kranar wrote: post #89

Earlier quoted context omitted.

>That is actually a feature when it comes to working with money. You don't ever want to use floating-point arithmetic with monetary values due to its inability to represent all possible decimal fractions of your base unit. This is just as true for over-hyped blockchain stuff as it is for any imaginable application in the "classic" financial sector. I feel like this is constantly repeated but is simply untrue and work…

Additionally, the most widely used programming language in finance, Microsoft Excel, is based entirely on IEEE binary floating point arithmetic (though with a few hacks on top [1]). [1]: https://stackoverflow.com/a/43046570/392585

True, but the number of weird mistakes due to floating point inaccuracies that happened in Excel spreadsheets is probably too large to be accurately representable in a 32bit float number.

Re: Understanding Ethereum Smart Contracts

#157

Post by alexasmyths » Thu, Nov 30, 2017, 12:51 PM UTC

patrickk wrote: post #155

alexasmyths wrote: post #111

Earlier quoted context omitted.

""smart", are only as good as they're written" There are so many things that go into contracts that cannot be articulated in 'code' that this all hardly makes sense. Employment contracts are long. Comp packages can be complex. And we all live in countries with employment laws etc. that require these things anyhow. I don't see any actual real-world cases for Eth contracts just yet.

The earliest smart contracts will likely involve things that are relatively easy to verify, e.g. a bet that the price of ETH will be above X at Y date and time. Ensuring that accurate, real-world data gets entered into the blockchain to enable broadly useful smart contracts is going to be an interesting area to monitor over the next few years. Augur attempts to align people's incentives to accurately report on real w…

"a bet that the price of ETH will be above X at Y date and time"

Not so fast. Who says 'what the price of ETH' is? There is no such thing as 'the price of ETH' - there are simply buyers and sellers each willing to sell and buy at different amounts.

You'd have to agree on a mechanism to agree on what that price even is.

And what about odd fluxuations? Market cheaters - i.e. getting a hold of a vast quantity of ETH just to jolt markets for a few hundred milliseconds just to jigger some contract?

As far as 'paying out on delayed flights' - that's a very cool idea, but I can't imagine why on earth it would be in ETH on a distributed ledger.

Re: Understanding Ethereum Smart Contracts

#158

Post by thomasthomas » Thu, Nov 30, 2017, 1:49 PM UTC

jatsign wrote: post #29

I've been programing my own Ethereum smart contract (virtual currency) for awhile now. Here's some gotchas off the top of my head: - You have about 500 lines of code to work with. This of course varies, but smart contracts have to be really small to fit in the max gas limit (6.7 million wei). - You can't pass strings between contracts (coming soon). - There are no floating point numbers. Since you're probably working…

just curious, what are you doing with ETH contracts? working on a product or just hobby?

Re: Understanding Ethereum Smart Contracts

#159

Post by tatersolid » Sat, Dec 02, 2017, 2:26 PM UTC

anarazel wrote: post #144

Kranar wrote: post #138

Earlier quoted context omitted.

Sure, I'll embarrass myself here and use myself as an example since this is how I actually came to even learn about this to begin with. When I started working in finance straight out of school (not in HFT at the time), I naively accepted the dogma that money should never be represented using floating points. I mean everywhere I went I would read in bold letters don't use floating point! Don't use floating point! So I…

You know there's a numeric type in postgres? Not quite arbitrary precision, but large enough for pretty all practical purposes "up to 131072 digits before the decimal point; up to 16383 digits after the decimal point" https://www.postgresql.org/docs/current/static/datatype-nume...

NUMERIC (without a precision or scale) is a variable-length datatype, and suffers all the performance problems mentioned above.

If you specify a precision and scale, performance of NUMERIC improves quite a bit, but now you can’t store values with vastly different magnitudes (USD and JPY) in the same column without wasting tons of storage on each row. You’re back to square one.

Re: Understanding Ethereum Smart Contracts

#160

Post by runeks » Sun, Dec 03, 2017, 2:06 PM UTC

stuxnet79 wrote: post #87

fortenforge wrote: post #86

> Bitcoin transactions are pretty simple in what they do. You can do one single thing. One type of transaction. Skipping some details, it all boils down to TO (who is receiving money), FROM (who is sending money) and AMOUNT (how much money). This let’s bitcoin be a store of value with the capability to transfer the value between participants in the network. Doesn't Bitcoin script allow you to do far more complex thin…

Yes it does. A lot of people tend to brush over this aspect of BTC. The whole notion of smart contracts is really just an extension of the scripting capability introduced in BTC which some felt was far too limited.

Not only that, but Bitcoin script was intentionally designed to be Turing incomplete, in order to allow static analysis of time/space complexity.

Ethereum was invented to fill the space of a blockchain with a Turing-complete scripting language, which may or may not prove to be useful in the real world (in my opinion it hasn’t yet).