Recent studies show that a public randomness beaconoutputting 64 bits of min

Recent studies show that a public randomness

This preview shows page 174 - 176 out of 216 pages.

Recent studies show that a public randomness beacon—outputting 64 bits of min-entropy every 10 minutes—can be built atop Bitcoin [19]. 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
Image of page 174
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. 8.2.5.1 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 [20], 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.
Image of page 175
Image of page 176

You've reached the end of your free preview.

Want to read all 216 pages?

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

Stuck? We have tutors online 24/7 who can help you get unstuck.
A+ icon
Ask Expert Tutors You can ask You can ask You can ask (will expire )
Answers in as fast as 15 minutes