4 ms·

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 11y ago
Is this because of the unknown cost at the time?
- ludbb 11y ago
  I believe the reference is coming from http://docs.ethereum-alarm-clock.com/en/latest/overview.html#guarantees http://docs.ethereum-alarm-clock.com/en/latest/overview.html...: 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 11y ago
    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.
- joosters 11y ago
  It's because the alarm program relies upon someone calling it at the right time. The code itself does not 'sleep' until the right time.
llamataboot 11y ago
room for an insurance contract on the alarm clock call. Libertarians love contracts ;)
pipermerriam 11y ago
I'm the author of the service. This is a fundamental limitation of the network as opposed to a shortcoming of the service. When you submit a transaction, it is up to the miners as to whether it gets included in the next block. There are lots of factors that go into this decision, and in normal situations, transactions are going to get included in a block very quickly. If you accept the assumption that there are enough people executing calls (in exchange for $$) and that the network is not so flooded with transactions that miners are having to exclude them due to volume, then the likelihood that your function won't be called drops near zero. If the network is congested with too many transactions, then it doesn't matter if the call was triggered by the alarm service or somewhere else, it will still have to compete to be included in a block just like any other transaction. Now if you want to talk about selective censorship of function calls, then that is an interesting attack vector that I'd love to chat about.

dangero 11y ago

Is this because of the unknown cost at the time?

ludbb 11y ago
I believe the reference is coming from http://docs.ethereum-alarm-clock.com/en/latest/overview.html#guarantees http://docs.ethereum-alarm-clock.com/en/latest/overview.html...: 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 11y ago
  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.
joosters 11y ago
It's because the alarm program relies upon someone calling it at the right time. The code itself does not 'sleep' until the right time.

llamataboot 11y ago

room for an insurance contract on the alarm clock call. Libertarians love contracts ;)

pipermerriam 11y ago

I'm the author of the service. This is a fundamental limitation of the network as opposed to a shortcoming of the service. When you submit a transaction, it is up to the miners as to whether it gets included in the next block. There are lots of factors that go into this decision, and in normal situations, transactions are going to get included in a block very quickly. If you accept the assumption that there are enough people executing calls (in exchange for $$) and that the network is not so flooded with transactions that miners are having to exclude them due to volume, then the likelihood that your function won't be called drops near zero. If the network is congested with too many transactions, then it doesn't matter if the call was triggered by the alarm service or somewhere else, it will still have to compete to be included in a block just like any other transaction. Now if you want to talk about selective censorship of function calls, then that is an interesting attack vector that I'd love to chat about.