A few simple questions about contracts

cryptoartcryptoart cryptoart.comMember Posts: 3
I understand that contracts execute when a transaction is sent to them. Can contracts be executed automatically (like a cron job) without a third party action?

Can a contract call a URL/API and retrieve variables?

Can a contract send bitcoin or other crypto?

Thanks in advance.

Comments

  • StephanTualStephanTual mod London, EnglandMember, Moderator Posts: 1,282 mod
    1) No, there are talks about an ALARM opscode to wake them up at regular intervals but we're still debating that one.
    2) No, and won't, ever. Contracts are deterministic and access to URLs is random (I could be behind the great firewall of China for example). The dapp itself (ie, the HTML or QML interface), has full network access on the other hand.
    3) Contracts can send/receive ether, and through schellingcoins abstractions, or having metacoins pegged to the value of some token, or listening to another contract which is fed information from a separate chain, transfer other types of crypto. We're doing quite a bit of work on this type of thing at the moment.
  • cryptoartcryptoart cryptoart.comMember Posts: 3
    Thank you Stephan. I'm trying to figure out how Ethereum will interact with the outside world. If a contract needs information, can the owner (or anyone else) send variables to the contract?



  • StephanTualStephanTual mod London, EnglandMember, Moderator Posts: 1,282 mod
    Right, so there's 2 ways to do that.

    The first is rather simple, the contract expects certain calls from a certain address (for security). These calls are made using a centralized app, maybe an agent of some sort such as a python script on a schedule, 'feeding' outside world information to the contract.

    The second one would be for one contract to call another. The second contract holds data fed to it by an agent similar to what I described above. It could be the only function of that contract to hold certified 3rd party data, for example, a data feed from Bloomberg.
  • JasperJasper ✭✭✭ Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    Note that even if ALARM never gets implemented, you can still do it in contracts. Basically your contract would pay a little to the cronDAO and the cronDAO pays clients that send transactions to it for the gas plus some tiny amount for the service.
  • cryptoartcryptoart cryptoart.comMember Posts: 3
    Thanks guys.

    I'm particularly interested in how people can create DAO services in non-ether prices. Once ether valuation becomes subject to market volatility, it's going to be pretty tough to price your service in ether. Bitcoin solves this by third parties like coinbase quoting the price in BTC at the point of sale.

    It looks like an "Exchange Rate DAO" can be created that is fed a feed that prices ether in local currencies. Other DOAs simply refer to this DAO for the current exchange rate. My only concern is that this seems to break the chain of trustlessness.






  • PeterBBPeterBB Member Posts: 4
    An interesting approach for a lower-trust datafeed is presented on the ethereum blog:

    https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/
  • robmyersrobmyers ✭✭✭ Member Posts: 65 ✭✭✭
    I'm conflicted about ALARM. On the one hand it allows contracts to trigger actions. On the other too many ALARMs would bloat the processing time for each block.

    If a contract will receive transactions regularly it can perform "tickle" code before responding to the actual content of each message, like :tell() handlers in LambdaMOO or poor man's cron for web apps. But a cron contract looks like the most robust solution at the moment.
  • JasperJasper ✭✭✭ Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    ALARM might be cheaper computationally and storage-wise than cronDAO. It would save transactions too if ALARM could start up a message. Then again the same might be said by a lot of things that contracts do, that could instead be incorporated into Ethereum itself.

    Yeah, contracts could just run their 'time progression' to get to the current time, and then handle the input. In many cases this is not particularly hard, hard to foresee if there arent cases where this is difficult, though. All in all i am weakly against ALARM.
  • JasperJasper ✭✭✭ Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    @cryptoart yeah that is a valid point. Matter of getting the data feeds secure. Methods combining multiple might help, and @PeterBB‌'s link. Also helps to have some control. For instance a DAO could have a vote on changing the what tries to get at the ethereum price, and that vote might even involve setting it constant, ignoring the dollar price of ethers. This would make it actually actionable if you find out the data sources are bad.
  • sidazhangsidazhang Member Posts: 1
    @Stephan_Tual‌ What about the following case,

    Let's I have a business with several partners and I want to have a way to distribute profits from storage depending on daily profit figures.

    Since this is the profit of my company, I will be the one supplying the data. Is there a way establish a contract to say: only accept the data feed if the data has been signed by all 3 of the partners.
  • JasperJasper ✭✭✭ Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
    @sidazhang this is easy. Basically you send your claim to the contract, and then the others send messages acknowledging it, or it is even automatically considered too if they dont counter it.

    Might even be the size of a single signature, but so far how to implement aggegrate signatures elude me..(as do too many things..)

    Of course, in some cases the contract might be able to figure out the profit itself. Could be that this is only the better way to do it for particular businesses though.
  • BezpolBezpol Member Posts: 26
Sign In or Register to comment.