Recent studies show that a public randomness beacon—outputting 64 bits of min-entropy every 10 minutes—can be built atop Bitcoin . Given this, GetRandomness then unfolds as follows. On input time t , GetRandomness outputs the hash of the latest block that has appeared since time t in the Bitcoin blockchain. Clearly, if t > cur corresponds to a time in the future, then GetRandomness will output ⊥ , since the hash of a Bitcoin block that would appear in the future cannot be predicted. On the other hand, it is straightforward to compute GetRandomness ( t ) for a value t ≤ cur (i.e., t is in the past) by fetching the hash of previous Bitcoin blocks. In this way, GetRandomness enables an untrusted party to sample randomness without being able to predict the outcome ahead of
time. Note that the security of GetRandomness depends on the underlying security of the blockchain. More specifically, if an entity is able to predict the outcome of GetRandomness , then he or she is able to predict a future block hash in the blockchain. 8.2.5 Smart Contracts Developers can leverage multisignature transactions in Bitcoin in order to construct smart contracts. Smart contracts refer to binding contracts between two or more parties and are enforced in a decentralized manner by the blockchain without the need for a centralized enforcer. Recall that multisignature transactions (see Chapter 4) require m > 1 correct signatures to be considered valid transactions. Although the primary use of multisig- nature transactions mainly targeted resistance to coin theft, these transactions also support the construction of smart contracts in Bitcoin. In what follows, we discuss various types of achievable contracts in Bitcoin. 188.8.131.52 Making a Deposit Recall that Bitcoin is mainly used to issue nonrefundable payments among users. However, there are a number of application scenarios where users need to make deposits (e.g., when using a service which requires assurance in case of damage or misuse). Bitcoin can plan for this case by enabling the creation of deposits to potentially untrusted entities. As described in , a user A can make a deposit of v BTCs to entity B by constructing a transaction T 1 that spends v BTCs into an output address C in such a way that the signatures of both A and B are required to spend T 1 . The user A does not immediately broadcast T 1 in the Bitcoin network; instead, A sends B H ( T 1 ) , C , as well as a new address that is owned by A using an off-line channel (e.g., using a direct TCP connection). Upon reception of H ( T 1 ) , B constructs another transaction T 2 that spends the BTCs stored in C (by linking it to H ( T 1 ) ) back to an address specified by A . T 2 is formed such that the nLockTime field is set to a future preagreed date, and the sequence number for the input is set to zero. B then sends T 2 to A using an off-line channel.