Definition Messages and Transactions

jorijnsmit

With the current way "transactions" are defined in the whitepaper I do not see that it is possible for contracts to send transactions but only responses to messages:

"Messages" in Ethereum are somewhat similar to “transactions” in Bitcoin, but with three important differences. First, an Ethereum message can be created either by an external entity or a contract, whereas a Bitcoin transaction can only be created externally. Second, there is an explicit option for Ethereum messages to contain data. Finally, the recipient of an Ethereum message, if it is a contract account, has the option to return a response; this means that Ethereum messages also encompass the concept of functions.

The term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account.

This would mean that contracts that send ether would not do this via "transactions" but "messages", the only difference there being that the former is signed whereas the latter is not. Correct?

Jasper

Correct. Contract addresses arent public keys.

Note that transactions are on the block contain messages, but messages sent by contracts are not on the block as data, but are implied by contract execution.

jorijnsmit

The point I am trying to make is that because the term "transaction" is defined as a signed message, and only public keys have the ability to sign, a contract can never send a transaction.

Is that because they would only "relay" transactions made externally? Still I would find it confusing if a ether goes into a contract as a transaction and comes out as a message...

Jasper

Yeah contracts never make transactions, just messages.

You sign messages to make a transaction. As a result a message with (possibly zero)ether is sent. If sent to a contract, contract code runs. It may or may not send more messages as a result, and ether sent(again possibly zero) with those messages come from the contract.

The messages that come out only have to do with those that came into a contract based on the code that ran. In principle the contract could be in a state where it only cares that a message comes in, not what the message was or how much value it carried. This can happen in practice because there is currently no 'alarm clock' functionality, so instead it might just take opertunity of running, if the time is later than the 'alarm'. (I dont think that functioanilty is needed.)

jorijnsmit

Stephan Tual speaks of contracts sending and receiving transactions in the introductory video (at 7:15):

StephanTual

Yes, it's an oversimplification I made that helps describing what ethereum does

You're correct in your assumptions @jorijnsmit - a transaction is just data, signed by what we call External Actors. It represents either a Message or a new Autonomous Object (casually and slightly incorrectly referred to as 'contracts'). Transactions are recorded into each block of the blockchain.

Message are Data (as a set of bytes) and Value (specified as Ether), is passed between two Accounts, either through the execution of the code from an Autonomous Object or the cryptographically secure signature of the Transaction.

Jasper is therefore correct when he states that "contracts never make transactions, just messages".