November 2015
tjade273: The point is that third parties are incentivised to execute the call, so you don't need to trust that any single person or server will be available and willing to call the contract.
As long as there are people who want Ether, someone will execute the call, who that is, however, is not important. All you are trusting is that people in the future will want money.
ethereumnick:
tjade273 said "As long as there are people who want Ether, someone will execute the call, who that is, however, is not important. All you are trusting is that people in the future will want money."
Isn't that "All you are trusting is that people in the future will want money and won't be advantaged by reporting the wrong time, and won't have their clocks wrong?" Or will there be proof of stake to those answering the call?
tjade273: Oh, I see the confusion. This service simply ensures that the contract will be called at a particular block number in the future. It makes no guarantees about the actual time, in seconds, or even that the contract will only be called at that time.
It's up to the contract itself to verify that the block number and time is correct, both of which can be easily done with block.number or block.timestamp in Solidity.
pipermerriam: If we want to go down the rabbit hole. You are trusting that your ethereum node is doing the right thing. You are trusting that the Ethereum Spec is correct. You are trusting that the network won't be taken down by a denial of service attack during the call window. You are trusting that the solidity compiler isn't doing something unwanted or undesired.
There are lots of layers of trust that we take for granted and the term trustless is a bit loaded. The service is trustless in that it does not rely on any centralized or trusted service. It relies on a proper incentive system that hopes to motivate rational actors to make the function call on your behalf.
Source: https://forum.ethereum.org/discussion/3571/ethereum-alarm-clock-call-scheduling-for-contracts