Earlier quoted context omitted.
What bit of that needs a smart contract? Seems perfectly do-able without one, and you still need the same levels of trust even when there's a smart contract in there.
The smart contract is the tool to make sure* that transferred Ether results in power being transferred. Of course we could just use a blockchain like Bitcoin and define "send x BTC to wallet y and I promise you will get your power" - but in that case, the blockchain can just guarantee the value transfer, not the subsequent actions being undertaken. * since this involves interaction with the outside world, I don't kno…
Understanding Ethereum Smart Contracts
91–100 of 162 posts
Re: Understanding Ethereum Smart Contracts
#92Earlier quoted context omitted.
The smart contract is the tool to make sure* that transferred Ether results in power being transferred. Of course we could just use a blockchain like Bitcoin and define "send x BTC to wallet y and I promise you will get your power" - but in that case, the blockchain can just guarantee the value transfer, not the subsequent actions being undertaken. * since this involves interaction with the outside world, I don't kno…
This seems like a perfect use-case for payment channels, e.x. Lightning Network: Car continuously delivers micropayments to charger while charger continuously delivers power to car, if one stops the other also stops. If the power is cut off prematurely the car only loses maybe a couple cents worth of power. (Payment channels are built using smart contracts, but they’re simple enough that Bitcoin’s more limited smart…
Re: Understanding Ethereum Smart Contracts
#93Earlier quoted context omitted.
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…
You might need to work with fractions of "atomic values" to get the desired level of accuracy. So you have to store not logical cents, but 1/100th of cents or something like that. Much easier and straightforward just use decimal-like type.
Re: Understanding Ethereum Smart Contracts
#94Earlier quoted context omitted.
Interesting point on the lack of floating-point support. I've dealt with storing fiat in real world software and using floating point is a big no-no due to the fact it is only an approximation by its very design. We therefore always stored money as integer cents/pennies etc. How is this approached with digital "money" where there is no smallest divisible unit?
I'm not sure if there are infinitely divisible currencies? The cryptocurrencies I know (Ethereum, Bitcoin) _do_ have a smallest divisible unit (wei and satoshi respectively).
Re: Understanding Ethereum Smart Contracts
#95Earlier quoted context omitted.
> There are no floating point numbers. Since you're probably working with "money", this can make things tricky. 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 appli…
>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…
Kranar: > working in the financial sector (high frequency trading)
Okay, you got me there - you have pointed me to that single application from the financial sector where it is not totally acceptable to "waste" a few thousands of processor cycles to compute some money-related stuff. Granted, in HFT applications, these cycles may allow you to get your trades in front of those of the other HFT companies. You are forced to use CPU-accelerated (or maybe even GPU?) computations in this case, which automatically means "floating point".
But there's another difference that allows you do do this: you mostly don't have to care about exact, accurate-up-to-the-penny results. I assume most of your calculations are done to eventually arrive at a conclusion of whether to buy or sell some stock or not, and at which price. You have to take care of not accumulating too much rounding errors in the process, of course, but the threshold for these errors is set by yourself, and you can give yourself a bit of leeway on this, because it's all internal stuff, mostly probabilistic and statistics-based - the only stuff that may be audited by someone else and thus has to match the real numbers up to the last penny are the trades you do and the money you move around, and I bet all of this accounting-style stuff is recorded using...decimal numbers :D
I work in the retail industry (think cash registers, retail sale accounting, that kind of stuff) and pretty much any legislation on this planet would obliterate us if we'd tell them that the result of the computations of our systems may be some cents up or down from the real result - the one someone would get who just scribbled the numbers on a sheet of paper and added them up manually. Our customers have to pay taxes based on the sales that they account using our systems, and the tax calculations as well as the entire chain of processes they use to arrive at the final numbers are regularly audited by the respective governments. There are specific rules (of course differing by country) as to how many decimal places have to be used and how stuff has to be rounded in which particular cases in calculations that would require more decimals. We waste an enormous amount of CPU cycles just to strictly adhere to these rules - and that is not only absolutely necessary, but also totally okay, modern CPUs can easily accomodate this in our scenario.
Re: Understanding Ethereum Smart Contracts
#96Earlier quoted context omitted.
_Red gave two examples of Ethereum applications. SeckimJohn quite quickly showed why neither work. The are some niche digital uses, but not the ones people often tout. Ethereum contracts basically break down at the point they need to interact with the real world.
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…
In the trust fund example, you cant stop the recipient trading their key or wallet early, as you have no way to verify the human holding it.
Unless you keep that access with some legal guardian. In which case your security still sits in the legal system, as it would if you just used a trust fund. So whats the point?
Again in the company example, it only works if you both observe that the coins mean shares in company. Which you can only really enforce with a legal agreement, but again, why not just have a legal agreement that says you split your share?
They completely breakdown at the physical barrier. Darknet markets only work because the seller doesnt control the market and has a deposit. But apart from that they can transact anonymously, that part has nothing to do with blockchain.
Re: Understanding Ethereum Smart Contracts
#97What 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.
So maybe it's not such a great idea after all.
Re: Understanding Ethereum Smart Contracts
#98Earlier quoted context omitted.
> There are no floating point numbers. Since you're probably working with "money", this can make things tricky. 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 appli…
>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…
The common programmer has no clue about the numerical instabilities that floating point numbers are causing.
Your examples are exactly what I would expect from a capable engineer that is pondering the different pros and cons when you have to optimize your code.
Calling BigDecimals entirely unneeded tells me you are in a luxury position where you can draw from a pool of the best programmers that are out there.
For lesser programmers and for the areas where speed is not as important, BigDecimal solves the issues completely and without any clever thinking and most importantly, consistently correct without having to rely on the skills of the programmer.
Re: Understanding Ethereum Smart Contracts
#99Earlier quoted context omitted.
_Red gave two examples of Ethereum applications. SeckimJohn quite quickly showed why neither work. The are some niche digital uses, but not the ones people often tout. Ethereum contracts basically break down at the point they need to interact with the real world.
Well I'm entirely new to this and pretty blockchain sceptical but I don't think SeckimJohn showed why neither work, did he? As I understand it each concern requires some kind of function/method which addresses it within the smart contract, right? So the real problem is that once you publish the contract you better make sure you haven't forgotten something important...
Which they both need to work today anyway. So whats the point?
Until ether contracts can hold people to their word, are recognised by the judicial system (which wouldn't be able to effect it without some weird judge API), or is able to enforce some kind of judiciary process itsefl (SKYNET WARNING), they'll always break down at the physical barrier.
Re: Understanding Ethereum Smart Contracts
#100Earlier quoted context omitted.
regarding number 2, the child would not have a way of selling that Ethereum before 2035.
Can't they just sell access to their address?