In this section we discuss the assumptions of trust necessary for our protocols. We then consider two modifications based on alternative trust assumptions.
While there are many places where a dishonest participant or saboteur
could delay progress or prevent commitment (e.g. by disrupting a
communication channel), there is only one location where a corrupt
coalition may benefit illegitimately. For this reason, there is one
trust assumption required by the protocol; the merchant must trust the
log to record received messages. If the log, in collusion with the
consumer, fails to produce 
, but simply passes k (which is
contained in 
) to the consumer, then the consumer will gain
access to the goods while the merchant will not have , and
thus will not be able to demand payment. In practice, if the time to
is sufficiently long and the log is accountable for
responsiveness, this sort of fraud might be detected. Trusted outside
observers could notice that the log is failing to respond in
reasonable time and take some action.
This trust assumption against a log-consumer coalition is a reason for the existence of the transaction log as a separate entity. Before he commits to the transaction, the merchant knows the identity of the log, and therefore he need only commit if the specified log is trusted. In practice, the selection of the log might be decided in the initial negotiation between the consumer and merchant. If the merchant is assumed to trust the bank not to conspire with the consumer, the transaction protocol can be simplified by merging the bank and the log.
The second reason for a separate transaction log is the consumer's desire for timely access to the goods. From a practical standpoint, the consumer must trust that the log will not intentionally delay passing the key to the consumer. Although the key must eventually be revealed to the consumer for the bank to justify crediting the transaction, this would likely take place on a much larger time scale than would be desirable for key delivery. If the log is required to satisfy some responsiveness guarantees, then limited delays can be enforced with the assistance of a trusted outside party. If the consumer is assumed to trust the merchant to make timely delivery of the key (given that it must be delivered eventually), then the transaction protocol can be simplified by merging the merchant and the log.