4 ms·

I'm curious if you would expand on why this is a terrible idea.

vessenes 11y ago
1) Get trusted 2) Wait until your function is used a lot 3) Lie, ideally in a plausibly deniable way. 4) Profit. "We had a hiccup with processing USD and EUR prices, and briefly crossed them with this code push, sorry. Everything is back to normal now." While it's easy to imagine how you'd use this as a trader, I think my fundamental disagreement with the idea is that you are expanding your threat surface for anything that consumes data from 'trusted' providers. That seems almost impossible to be a good idea. Mitigating this risk with, e.g. multiple 'trusted' providers reduces to the problem bitcoin mining solves in the first place. I think I would have a more informed opinion if you detailed a sample application consuming this; I'm not trying to shit on what was undoubtedly very solid work putting the service together, but I'm very dubious about the breadth of useful services that wouldn't have unacceptable risk profiles.
- pipermerriam 11y ago
  * Recurring and Scheduled payments. On the first of every month, the alarm service pings my wallet to pay my utility bill. Most of the other potential applications it's easy to argue that they could set up their own incentives to get some user in the system to execute the call. (lottery payout, scheduled trade, crowdfunding payout, etc). I think that yes, each of those applications has a viable way of motivating some party to execute the call. However, if a service like Alarm proved to be very reliable, it may be simpler to just automate it with a scheduling service. Scheduled or recurring execution doesn't have to be the only solution to a problem for it to still be a good solution.
  - vessenes 11y ago
    OK, that's interesting, and I agree that for the use case you specify you're essentially fixing a hole in the ethereum specification / building out the 'standard library' in a useful way. If I were running it, I would still make strong recommendations that recipients of the alarm 'ping' only execute idempotent functions which do not rely on any data from the ping itself, or on the ping being executed implying any state anywhere in the world, whether on blockchain or not.
    - pipermerriam 11y ago
      A point of clarification. All call execution is just a ping. If the call requires call data it is supplied by the scheduler and cannot be manipulated or changed by the caller. All call execution is relayed through the alarm service so it only relies on the executor to initiate the transaction and then the alarm service does all of the rest.
- pkinsky 11y ago
  It's not really a trust-based mechanism. Ethereum runs on a blockchain, just like bitcoin, but instead of just maintaining account balances it implements a simple turing machine where each instruction costs some amount of the underlying cryptocurrency. Contract code is stored on the blockchain, so the behavior of any contract is fully predictable. Here's one example: Augur (http://www.augur.net/ http://www.augur.net/) have already released an alpha of their fully decentralized prediction market. With bitcoin someone could run a prediction market, pools payments and pay out to winners. With Ethereum you will be able to send cryptocurrency directly to a contract that manages the bet and pays out to the winners, based on some prearranged signal source.
  - vessenes 11y ago
    Augur is a great example, and you mention my concern right here. Under no circumstances should Ethereum Alarm Clock be used as the signal source for Augur's "signal source" / adjudication on prop bets.
    - pipermerriam 11y ago
      @vessenes, I would ask that you backup that assertion with an actual explanation of why Alarm should never be used for Augur. Just saying it shouldn't be used isn't very constructive. Edit: If I make some assumptions about why you think it's a bad idea then I would guess it is that you think the call executors can behave badly in some way. The way the call execution works is that as long as there is at least one honest caller, then calls cannot be censored. Call execution is a binary operation as the executor can't control the call data. So the only thing a call executor has control over is whether or not they execute the call. Even in the situation where some attacker represents a large part of the caller pool, there is a section during the last part of the call window where anyone may execute the function call in exchange for a large payout. So even if an attacker is operating 99/100 of the accounts executing function calls, that 1 honest person can execute the call if everyone else chooses not to.
      - vessenes 11y ago

1) Get trusted 2) Wait until your function is used a lot 3) Lie, ideally in a plausibly deniable way. 4) Profit. "We had a hiccup with processing USD and EUR prices, and briefly crossed them with this code push, sorry. Everything is back to normal now." While it's easy to imagine how you'd use this as a trader, I think my fundamental disagreement with the idea is that you are expanding your threat surface for anything that consumes data from 'trusted' providers. That seems almost impossible to be a good idea. Mitigating this risk with, e.g. multiple 'trusted' providers reduces to the problem bitcoin mining solves in the first place. I think I would have a more informed opinion if you detailed a sample application consuming this; I'm not trying to shit on what was undoubtedly very solid work putting the service together, but I'm very dubious about the breadth of useful services that wouldn't have unacceptable risk profiles.

pipermerriam 11y ago
* Recurring and Scheduled payments. On the first of every month, the alarm service pings my wallet to pay my utility bill. Most of the other potential applications it's easy to argue that they could set up their own incentives to get some user in the system to execute the call. (lottery payout, scheduled trade, crowdfunding payout, etc). I think that yes, each of those applications has a viable way of motivating some party to execute the call. However, if a service like Alarm proved to be very reliable, it may be simpler to just automate it with a scheduling service. Scheduled or recurring execution doesn't have to be the only solution to a problem for it to still be a good solution.
- vessenes 11y ago
  OK, that's interesting, and I agree that for the use case you specify you're essentially fixing a hole in the ethereum specification / building out the 'standard library' in a useful way. If I were running it, I would still make strong recommendations that recipients of the alarm 'ping' only execute idempotent functions which do not rely on any data from the ping itself, or on the ping being executed implying any state anywhere in the world, whether on blockchain or not.
  - pipermerriam 11y ago
    A point of clarification. All call execution is just a ping. If the call requires call data it is supplied by the scheduler and cannot be manipulated or changed by the caller. All call execution is relayed through the alarm service so it only relies on the executor to initiate the transaction and then the alarm service does all of the rest.
pkinsky 11y ago
It's not really a trust-based mechanism. Ethereum runs on a blockchain, just like bitcoin, but instead of just maintaining account balances it implements a simple turing machine where each instruction costs some amount of the underlying cryptocurrency. Contract code is stored on the blockchain, so the behavior of any contract is fully predictable. Here's one example: Augur (http://www.augur.net/ http://www.augur.net/) have already released an alpha of their fully decentralized prediction market. With bitcoin someone could run a prediction market, pools payments and pay out to winners. With Ethereum you will be able to send cryptocurrency directly to a contract that manages the bet and pays out to the winners, based on some prearranged signal source.
- vessenes 11y ago
  Augur is a great example, and you mention my concern right here. Under no circumstances should Ethereum Alarm Clock be used as the signal source for Augur's "signal source" / adjudication on prop bets.
  - pipermerriam 11y ago
    @vessenes, I would ask that you backup that assertion with an actual explanation of why Alarm should never be used for Augur. Just saying it shouldn't be used isn't very constructive. Edit: If I make some assumptions about why you think it's a bad idea then I would guess it is that you think the call executors can behave badly in some way. The way the call execution works is that as long as there is at least one honest caller, then calls cannot be censored. Call execution is a binary operation as the executor can't control the call data. So the only thing a call executor has control over is whether or not they execute the call. Even in the situation where some attacker represents a large part of the caller pool, there is a section during the last part of the call window where anyone may execute the function call in exchange for a large payout. So even if an attacker is operating 99/100 of the accounts executing function calls, that 1 honest person can execute the call if everyone else chooses not to.
    - vessenes 11y ago