
Ethereum Alarm Clock - mwilcox
http://www.ethereum-alarm-clock.com/
======
tonetheman
While this site looks interesting enough and even the comments below sort of
say the same thing. What is this? I mean really. I look at this site and
think. I do not know what this is. And even worse there is nothing on the site
that even remotely explains it. Why was it even posted?

~~~
aakilfernandes
Its a cron system for decentralized apps. Since there's no way to run 'cron'
trustlessly, this alarm clock creates an incentive to call functions at given
time periods.

Its one of those things that you need some background on Ethereum to
understand, but if you understand Ethereum you know why something like could
be the cornerstone of a lot of apps.

~~~
sdoering
Thanks for clarification. I had the same problem as OP and was literary
scratching my head.

------
rubicon33
This sounds interesting, but I'm not sure I really grasp what it 'is'. Can you
explain what this it to me, as if I were 5 years old? I really struggle to
understand two things:

a) What this is. b) Why it's valuable.

~~~
pipermerriam
On Ethereum there is no built in way to have a contract be called
periodically, say every 5 blocks, or at a specific time in the future. This
contract creates a market which allows contracts to hire people to call them
at the requested time.

~~~
mmanfrin
What is a contract, and why would people want one called periodically?

~~~
joeyspn
> What is a contract...

A contract is a group of functions that live in the Ethereum Blockchain (a
distributed virtual machine for running decentralized applications)

> Why would people want one called periodically?

For the same reason people need cron to call periodic functions.

------
pcl
For those of us who are new to Ethereum:

 _Ethereum is a decentralized platform that runs smart contracts: applications
that run exactly as programmed without any possibility of downtime,
censorship, fraud or third party interference._

[https://www.ethereum.org/](https://www.ethereum.org/)

~~~
CGamesPlay
After reading about this for the past hour or so, I found this to be the most
helpful document to understanding Etherium:
[https://github.com/ethereum/wiki/wiki/Ethereum-
Development-T...](https://github.com/ethereum/wiki/wiki/Ethereum-Development-
Tutorial)

~~~
kristopolous
Great. It's essentially a cluster computing platform with a handful of small
permutations on that basic idea. Why don't these people use more accessible
language? It would dramatically help increase adoption.

~~~
bildung
> _Great. It 's essentially a cluster computing platform with a handful of
> small permutations on that basic idea. Why don't these people use more
> accessible language? It would dramatically help increase adoption._

I guess because they aren't aware of the precursors.

------
Animats
Ethereum's contract system has no way of knowing whether events outside its
little world actually occurred. It can't tell if someone who said they'd send
your alarm message actually did so before paying them. There's talk of
"trusted intermediaries", but if you have trusted parties, then you don't need
Ethereum.

The banks that are talking about blockchain technology for settlements have a
better handle on this. If bond ownership transfers are actually recorded
through a transaction on the bond blockchain, then you could have offers,
acceptances, contracts, and verified deliveries without a trusted back-end
service.

Conceivably you could put a music or video download service on Etherium, where
you got a crypto key to unlock the content by paying for it. But Etherium
can't tell if the key you got was any good, or that the file it unlocks was
what was ordered.

Does someone have a convincing use case for this thing?

------
vessenes
So often Ethereum straddles the line between brilliant and terrible idea.

Outsourcing function calls to 'trusted' providers is brilliantly interesting,
and a terrible, terrible idea.

What if this used for trading purposes, e.g. price reports from an exchange?

~~~
joeyspn
> What if this used for trading purposes, e.g. price reports from an exchange?

Timestamping trades clearly is not the use case for this. Don't blame the tool
but he who uses it in the wrong way...

~~~
vessenes
I urge you to read this classic, The case of the killer robot.
[http://tareksobh.org/online_courses/cpe300/Lectures/Lecture1...](http://tareksobh.org/online_courses/cpe300/Lectures/Lecture11/The_Case_of_The_Killer_Robot.pdf)

I believe all engineers have a responsibility to adjust design for risks,
especially unintended use cases.

Most engineers would generally agree with this principle, although I have
found software engineers tend to be a little more lax than, say civilian
engineers.

------
joosters
Just one minor problem: _There are no guarantees that your function will be
called_. So it's an alarm clock that might not work.

~~~
dangero
Is this because of the unknown cost at the time?

~~~
ludbb
I believe the reference is coming from [http://docs.ethereum-alarm-
clock.com/en/latest/overview.html...](http://docs.ethereum-alarm-
clock.com/en/latest/overview.html#guarantees):

Guarantees - Will the call happen?

There are no guarantees that your function will be called. The design of this
service is meant to provide the proper motivation for calls to be executed,
but it is entirely possible that certain calls will be missed due to unforseen
circumstances.

~~~
avmich
Strictly speaking, there is no such a thing as "guarantee". Your alarm clock
may malfunction in an important moment. An asteroid can suddenly wipe
civilization with all insurance providers (now that's an idea...) So you - in
a strict sense of a word - always have to estimate and compare probabilities.

------
to3m
Why is a caller pool required? You don't care who calls your contract, as I
see it, nor how reliable they are in general - provided they call _your_
contract at the right time, you're happy!

Since the caller gets rewarded for making the call, the incentives should be
in place to make things work without any need for centralization.

~~~
pipermerriam
Calling contracts has to be profitable, otherwise nobody would do it.

Since there is no way to reject a transaction, every person who attempts to
execute a scheduled call will have to pay some small amount for the
transaction. If the service is implemented as a first call wins sort of thing,
then all of the people who tried and failed would be out the gas cost of that
transaction. For calling contracts to be profitable, these costs would have to
be covered somehow, otherwise there is no incentive for people to execute
calls.

So, this cost would have to be offloaded onto the people scheduling calls
which would cause a significant increase in the overhead of scheduling a
function call.

The alternative solution I came up with was having a caller pool. The people
executing the calls are guaranteed a window of time where they can call the
contract and also incentivized (by their bond) to fulfill that duty lest the
next person in the pool claim their bond.

I'm open to alternate solutions to this problem.

