Coin-based Secure Computations

In the history of cryptography, many cryptographic protocols have relied on random coin tosses to prove their security. Although flipping coins is indispensable in this manner, the coins themselves have never been in the spotlight. Therefore, we would like to make physical coins rise to the level of cryptography, just as a deck of physical playing cards has been used to perform a secure multi-party computation. Such a card-based protocol is known to be helpful both to perform a secure computation without any black-box computers and to understand the principles of secure protocols. In this paper, we propose a new framework of secure multi-party computation using physical coins, named a coin-based protocol. One advantage of the use of coins is that they are more ubiquitous than cards. Whereas a face-down card can conceal the information about its face side, one side of a coin reveals the information of its other side. Hence, more careful design is required for a secure coin-based protocol than for a card-based one. We formalize a computational model of the coin-based protocol and explicitly give protocols for NOT, AND, COPY, OR, and XOR computations. We also discuss the composability of the extended protocols and how to implement them in practice.


Introduction
Physical coins are widely used to perform random and fair selections, such as coin tosses in sports games. In the research of cryptography, coins have conceptually appeared as "the probability is taken over the random coin toss." Although coins play an important but invisible role, the coins themselves have never been on the center stage of cryptographic research. Therefore, we would like to make coins rise to this level. In contrast, a deck of physical playing cards has received the spotlight. That is, designing card-based pro-An earlier version of this study was presented at the 7th International Conference on the Theory and Practice of Natural Computing, TPNC 2018, Dublin, Ireland, December 12-14, 2018 Tohoku University, 6-3 Aramaki-Aza-Aoba, Aoba-ku, Sendai, Japan tocols, which perform secure multi-party computations [6] using physical cards, is an active research area. Let us start with a review of card-based protocols.

Related Work: Card-based Protocol
The first card-based protocol was proposed by den Boer [3] in 1989. His protocol performs a secure AND computation with five physical cards. Since the five-card AND protocol was invented, many protocols using fewer cards or realize other useful functions have been developed [4,7,14,16,19,20,22]. In addition, a computational model [17] and its implementation [23] have been established. Refer to [18] for a survey of recent the recent progress on card-based protocols.
In a card-based protocol, a two-suit deck of cards, for example, ♣ , ♥ are typically used. For example, in the sixcard AND protocol [19], each player first places face-down cards ? ? in accordance with his or her private input, based on the encoding ♣ ♥ = 0 and ♥ ♣ = 1. Such a pair of face-down cards is called a commitment and the proto- and ♣ ? and ♥ ? denote face-up cards.) Then, they change the order of the cards by a series of card operations, such as rearrangements and shuffles, to obtain a commitment to the AND value. Because these operations are easy to implement and both their correctness and security are intuitively understandable, such card-based protocols have been widely used to solve social problems in daily life, as well as to educate non-experts about cryptography [12,18].
One drawback of card-based protocols is that people do not typically carry a deck of cards to solve social problems. In contrast, many people have physical coins in their pockets or wallets. Thus, it would be beneficial to make use of such coins for secure multi-party computations.

Our Contribution
In this paper, we introduce a framework for multi-party computation that uses physical coins. We also give concrete examples of the coin-based protocols, such as an AND protocol. We assume that the head and tail of each coin have different patterns, as depicted in Fig. 1. Throughout this paper, we assume that the design of every coin is the same and that nobody can distinguish one coin from another 1 .
Hereinafter, • and • denote a face-up coin (head) and a face-down coin (tail), respectively. For example, the first (leftmost) and second coins in Fig. 1 are denoted by • and •, respectively. Given a single coin, we can encode a one-bit value with • and • as Recall that in a card-based protocol, two players, say Alice and Bob, place face-down cards according to their private input values; these values can be kept secret because the backside ? of every card has no information. In contrast, a coin placed on a table reveals, from either side, the information of the other side. This means that, if we simply replace a card with a coin in a card-based protocol, say, ♣ and ♥ with • and •, respectively, then the resulting "coin-based" protocol is no longer secure. To construct a secure coin-based protocol, new ideas for implementation and a computational model are required. Our answer is to hide the surface of the coin by having the player grab it and hold it in their hand or by stacking another coin onto the coin. For example, as illustrated in Fig. 1, a player can create a "coin-based" commitment to her or his private input bit by grabbing a coin without anyone else seeing which side is up. We give a formal treatment for coin-based protocols and their security in this paper.
In addition, we show concrete examples of coin-based protocols for NOT, AND, COPY, OR, and XOR computations, consisting of action sequences. We then confirm their correctness and security with the probability trace and the extended diagram proposed in [15]. We also discuss the implementation of actions and show that our protocols are executable in practice.
We emphasize that there are three merits to our coin-based protocols: 1 As we review in Section 1.1, there are many studies on card-based protocols. In addition to card-based protocols, other protocols use a physical tool, such as, protocols with a PEZ dispenser [1,2], tamper-evident seals [21], and visual secret sharing sheets [5], and bags and balls [13]. Compared with the physical objects in these protocols, a coin is a simple tool representing just one-bit information by itself. Specifically, with such a simple tool, the coin-based protocol can provide the most fundamental protocol with familiar tools. Its computation model or procedure can be useful in developing protocols with other tools. 2 Similar to the card-based protocol, it is easy to trace the steps of the coin-based protocol by tracking the actions of players' hands. Moreover, intuitively, it is also easy to check whether there is information leakage. Hence, the coin-based protocol is useful for understanding the principles of information security and cryptology. That is, the coin-based protocol, with a coin as a simpler and more familiar tool compared with other protocols, is a good tool for educating not only students but also new researchers and engineers of information security, and for enlightening citizens. 3 As with the card-based protocol, the coin-based protocol is executed without any black-box computers or any network communication. Hence, as players perform the coin-based protocols, they are reassured that there is no unintended leakage of their secrets, such as spyware surreptitiously transferring hidden information.
The main difference from the conference version of this paper [10] is that we add, as new material, Sections 3.4, 3.5, 4, and 5. In Sections 3.4 and 3.5, we give two basic coin-based protocols, namely, OR and XOR protocols, respectively. In Section 4.1, we formalize another action, pick, which is necessary for the protocol composition. We also modify the inputs of our coin-based protocols to be suitable for protocol composition, and give examples of protocol compositions, namely, a three-input AND protocol and a three-input majority decision protocol in Sections 4.2 and 4.3, respectively. Furthermore, in Section 5, we add discussions on the effect of human errors, namely, the correctness of the protocol and the information leakage of players' private inputs.

Organization
The remainder of this paper is organized as follows. In Section 2, we present our idea behind formalizing coin-based protocols and their definitions, and show that our actions are implementable. We then show concrete examples of coinbased protocols in Section 3. In Section 4, we introduce another action, pick, and give examples of protocol compositions. Moreover, following the discussion of human error in the card-based protocol [15], we discuss the effect of human error on the coin-based protocol in Section 5. Finally, Section 6 concludes this paper.

Model of Coin-based Protocols
In this section, we first present the idea behind our construction of coin-based protocols and then define their computational model formally. We also discuss how to implement the actions appearing in coin-based protocols.

Basic Idea
As mentioned in Section 1.2, given an existing card-based protocol, we can immediately transform it into an (insecure) coin-based protocol, by replacing the cards with coins, that is, by replacing ♣ and ♥ with • and •, respectively. For example, if we execute the six-card AND protocol mentioned in Section 1.1 with a sequence of coins, such as 01 = (•, •, •, •, •, •) for a = 0 and b = 1, we obtain a pair of coins corresponding to the value of a ∧ b.
The above coin-based protocol is insecure because a single coin cannot hold any secret information. How can we make coins behave more like cards? If we place a dummy coin on a given coin, the stack of both coins can simulate a card. Therefore, if we use twice as many coins as the number of cards used in a card-based protocol, we can construct a secure coin-based protocol. For example, let us put • on all six coins in 01 = (•, •, •, •, •, •). Because only the dummy coins are visible during the execution of the protocol, no secret information is revealed.
Technically, such a coin-based protocol using dummy coins works correctly and securely, but it may be hard for humans to use a stack of coins as if they were a card. Therefore, we should make use of more human-friendly actions. For instance, as already seen in Fig. 1, a player can create a commitment by grabbing a coin, which is an easy action for humans. Thus, our questions are: 1 Can we construct human-friendly coin-based protocols? 2 How can we model such a coin-based protocol formally?
As an answer, we formalize the computational model with five actions in the next subsection.

Coin-based Protocols
As stated in Section 1.2, let • and • denote face-up and facedown coins, respectively. As also stated, we assume that all coins are indistinguishable from each other by their surface appearance.
For two coins c, c ∈ {•, •}, let a stack of coins, where c is on c , be denoted by cc . For example, cc = •• is a stack of two coins for c = • and c = •, such that the top coin of the stack is head up and the bottom coin is tail up. For more than two coins, we consider a stack in a similar manner. For two stacks of two coins c 1 = •• and c 2 = ••, for instance, c 1 c 2 is the stack of four coins ••••.
S k denotes the set of all stacks of at most k coins for some integer k, namely, let which is a finite set of all strings over the alphabets {•, •}. Here, we designate the symbol as an empty stack with no coin.
Let us consider a coin-based protocol to be executed by two semi-honest players, Alice and Bob, with a table and k coins. We use a tuple to describe the status of the coins, which we call an arrangement, during execution of the protocol: where, a L , a R , b L , b R , t i ∈ S k are stacks of coins in (closed) Alice's left hand, Alice's right hand, Bob's left hand, Bob's right hand, and the i-th area of the table where 1 ≤ i ≤ k, respectively. We assume that every hand is closed. Then, A L , A R , B L , B R , and T i denote their variables, namely, the locations where stacks of coins are placed. We use this notation to define the set of all arrangements of stacks from k coins as where size(c i ) means the size of c i , namely, the number of coins in c i , which is defined by As seen below, we use U ⊆ Arg k to represent a set of initial arrangements, that is, inputs of the protocol. In the subsequent operations, we may omit t j in an arrangement and the corresponding variable T j if a protocol requires k areas on the table, and no coin is placed on the j-th area ( j > k ) throughout the protocol.
For a stack of coins c ∈ S k , top(c), bottom(c), and turn(c) denote the top of c, the bottom of c, and the turned stack of c, respectively (they are defined to be if c = ). Namely, for a stack of n coins where turn(•) = • and turn(•) = •.
Let us define a visible sequence for an arrangement = (c 1 , c 2 |c 3 , c 4 |c 5 , c 6 , · · · , c k+4 ) ∈ Arg k . We first extend top as follows. For Now, for the above , we set With these notations, let us formally define a coin-based protocol.

Definition 1 (Coin-based protocol) A coin-based protocol
k is the number of coins used in the protocol; -U is an input set where U ⊆ Arg k ; -Q is a state set having an initial state q 0 ∈ Q and a final state q f ∈ Q; where Action is the set of the following actions: A player moves the upper n coins of the stack p 1 , consisting of m(≥ n) coins, on P 1 onto p 2 on P 2 . Let p (u) and p (l) denote the stack of the upper n coins and lower m − n coins of p, respectively. This action changes the arrangement from (· · · , p 1 , · · · , p 2 , · · · ) to (· · · , p (l) the player opens her or his hand at first. If another stack p 2 is in she or he opens their hand and moves p (u) 1 onto p 2 . At the end, she or he closes their hands. Note that, when Alice and Bob hold stacks of coins in all their hands in {A L , A R , B L , B R }\{P 1 , P 2 }, it is infeasible to execute this action; hence, the protocol stops (fails) in this case. Also note that top(p 1 ), top(p (l) 1 ), and top(p 2 ) are visible to the public. The players perform operates this action so that no information leaks except the visible coins.
with P 1 = P 2 : A player puts a hand P 1 holding a stack of coins p 1 ∈ S k on another hand P 2 so that the palms of both hands touch each other. Then, the players open their hands at the same time, and close their bottom hand so that the composite stack is hidden in the closed hand. This action changes the arrangement from (· · · , p 1 , · · · , p 2 , · · · ) to (· · · , , · · · , turn(p 1 )p 2 , · · · ). -(shuffle, P 1 , P 2 ) for P 1 , P 2 ∈ {T 1 , T 2 , · · · , T k } with P 1 = P 2 : A player shuffles the two stacks placed on P 1 and P 2 . This action changes the arrangement from (· · · , p 1 , · · · , p 2 , · · · ) to (· · · , p 1 , · · · , p 2 , · · · ) (which is unchanged) or (· · · , p 2 , · · · , p 1 , · · · ), where each case occurs with a probability of 1 2 . No player can know which case occurs if size(p 1 ) = size(p 2 ) and top(p 1 ) = top(p 2 ). Note that, unless at least one of Alice and Bob holds no stack of coins in both hands, it is infeasible to execute this action; hence, the protocol stops (fails) when both players hold a stack of coins in her or his hand.
-(flip, P) for P ∈ {T 1 , T 2 , · · · , T k }: A player turns over the stack on P. This action changes the arrangement from (· · · , p, · · · ) to (· · · , turn(p), · · · ). Note that, unless at least one of Alice and Bob holds no stack of coins in her or his hand, it is infeasible to execute this action; hence, the protocol stops (fails) when both players hold stacks of coins in their hands.
domly flips the stack placed on P. This action changes the tuple from (· · · , p, · · · ) to (· · · , p, · · · ) (which is unchanged) or (· · · , turn(p), · · · ); each case occurs with a probability of 1 2 . No player can know which case occurs if top(p) = bottom(p). Note that, similar to shuffle, unless at least one of Alice and Bob holds no stack of coins in both hands, it is infeasible to execute this action; hence, the protocol stops (fails) when both players hold a stack of coins in her or his hand.
We say that the protocol for a function f is correct if it finally outputs the correct value of f (a, b) for any input (a, b).
The protocol P = (k, U , Q, A) proceeds as a Turing machine does. That is, starting from an initial state q 0 and an initial arrangement 0 ∈ U , its current state q and arrangement move to the next state q and arrangement , respectively, according to the output of the action function A.

Feasibility of Actions
In this subsection, we discuss the implementation of the five actions in Definition 1. Among these five actions, move and flip are naturally implementable without explanation. Therefore, we focus on the remaining three actions; hand, shuffle, and rflip. As for shuffle, it can be operated in a similar manner to the shuffling operation in the card-based protocol. A player exchanges the positions of two stacks of coins multiple times so that the number of moves cannot be traced.
We then show two implementations for rflip. One of them is performed without any item and the other uses an item such as a binder clip. In the former implementation, a player holds the stack of coins and rotates it horizontally multiple times so that the number of the rotations cannot be traced, as shown in the left of Fig. 3. In the latter case, the player clips stacks into one stack with, for example, a binder clip, as shown in the right side of Fig. 3, and then, throws the clipped stack in the air like a coin toss.
Note that, to make the results shuffle and flip random from the viewpoint of both players, they can execute the action in relays (sequentially).
In addition, it is natural to assume that a semi-honest player is able to create a coin-based commitment (according to her or his private bit) by adjusting the direction of the coin after grabbing it.

Definitions for Security
This subsection gives definitions related to the security of the protocols. As we explain in Section 2.2, we assume that the players are semi-honest. Let us assume that other entities, including an adversary, are also semi-honest. That is, the aim of an attacker is to maliciously obtain any information from the secret input, by observing the protocol.
To discuss security, we need to consider publicly observable information, which may leak a secret input with a protocol. There are two kinds of such information. The first one is visible information of coins on the table, such as the surface (direction) of the topmost coin and the number of stacked coins. The second one is publicly detectable information of coins in a player's hand, such as the coin of an initial arrangement, that is independent from the input, and one which is publicly detectable from the previous state of the protocol.
Let us define a detectable sequence for an arrangement = (c 1 , c 2 |c 3 , c 4 |c 5 , c 6 , · · · , c k+4 ) ∈ Arg k . We first extend top and size as follows. Unlike top(c) which returns "?" if c is in a player's hand, the following top(c) and size(c) return invisible information if it is publicly detectable from the specification of the protocol. That is, for [1,4] and it is detectable) ?
(i ∈ [1,4] and it is not detectable yet) top(c i ) (i ≥ 5) , and We then set the detectable sequence of , top( ),  To confirm the correctness and security of a coin-based protocol, we used an extended diagram [15] that replaces a probability within the diagram, as proposed by Koch, Walzer, and Härtel [7], with the probability trace. We give a definition of the probability trace below, which is a modification from [15] to replace the step number j to the detectable sequence trace d for Step j of the protocol. Here, the detectable sequence trace for Step j is a set of detectable sequences which appear before or at Step j of the protocol. of a coinbased protocol P. Let d be a detectable sequence trace. An |U |-tuple (q 1,d,s , q 2,d,s , · · · , q |U |,d,s ) such that is called a probability trace for an arrangement s and the detectable sequence trace d, where M, G j , and D are random variables of the original input sequence of the arrangement when d is seen, and of the detectable sequence trace, respectively.
With the detectable sequence trace and probability trace, let us define the security of the coin-based protocol as follows.
Definition 3 (Perfect security of coin-based protocol) We say that a coin-based protocol P is perfectly secure if it leaks no information for any run of the protocol (i.e., the input and the detectable sequence trace are independent).
Note that an implementation of a coin-based protocol may leak the number of held coins (c where size(c) =?) via sidechannel information 2 , such as the volume of players' hands and the jingle of coins in players' hands. Depending on the protocol, the number of held coins may be different based on the secret input, and, in this case, such side-channel information may leak a secret, that is, the protocol may be insecure. In our protocols presented later, the number of held coins does not depend on the secret input and no secret leaks from the side-channel information. For the sake of simplicity, we hereafter ignore such information leakage in this paper.

Extended Diagram
This subsection briefly reviews the extended diagram introduced in [15] with the concrete example described in Fig. 4. The diagram consists of nodes, and each node is connected to its neighboring node(s) through action(s). For example, Fig. 4 contains six nodes. The topmost node corresponds to an initial arrangement, and it is connected to the next node which corresponds to an arrangement after the actions of hand (Steps 1 and 2 in the six-coin AND protocol in Section 3.2).
Each node consists of a "detectable sequence," "arrangements," and "probability traces." Let us look at the topmost node in Fig. 4 again. There are four entries, each of which consists of the arrangement and the probability trace, which comes from one of the four kinds of inputs (0, 0), (0, 1), (1, 0), and (1, 1). The first entry corresponds to the input (0, 0). The arrangement is an initial one for input (0, 0) of the protocol itself, which is derived only when the input sequence is (0, 0) with a probability of p 00 , and hence, the first coordinate of the probability trace is p 00 and the remaining three coordinates are 0.
Note that, if there is more than one detectable sequence after some action (move at Step 7 in the six-coin AND protocol in Section 3.2, for example), we prepare a node for each sequence as in the fifth and sixth nodes in Fig. 4.

Examples of the Coin-based Protocol
In this section, we give examples of coin-based protocols for NOT, AND, and COPY computations, and check their correctness and security with the extended diagram [15].

NOT Protocol
Assume that Alice holds a coin-based commitment; that is, she grabs a coin that encodes a one-bit information according to Eq. (1), as illustrated in Fig. 1. Then, the NOT computation can be executed by turning over the coin. For example, hand performs such a computation. With hand, the correctness and security trivially hold. Note that, ignoring the security, flip also performs the NOT computation.

AND Protocol
Let a ∈ {0, 1} and b ∈ {0, 1} be private inputs of Alice and Bob, respectively. Also, let a and b be flipped bits of a and b, namely, a ⊕ 1 and b ⊕ 1, respectively. Alice and Bob initially grab stacks of coins as follows: a L is set to a L = a according to the encoding defined in Eq. (1), a R is always •, b L = b•, and b R = b•. Namely, the initial arrangement can be written as Note that there are four candidates ab ∈ U for the initial arrangement of this protocol.
Six-coin AND Protocol P AND coin Input: Steps: Output: The result of the protocol also follows the encoding defined in Eq. (1).
We can check the correctness and security of P AND coin by using the extended diagram. Fig. 4 shows a summary of the diagram. In this diagram, the topmost node consists of triplet of the detectable sequence, the arrangements, and the probability traces of inputs, namely, just before the first step.
We first check the correctness. The output is the bottom of the corresponding underlined coin in the final step of this figure, such as 3 •• and ••. With this diagram, it is obvious that (a, b) = (1, 1), namely, the fourth component in the probability trace, p 11 , is non-zero if and only if the output is bottom(••) = • which is the encoding of 1.
We now discuss the security. Fig. 4, the sum of the probability traces is ( p 00 , p 01 , p 10 , p 11 ). Namely, the probability distribution of the input after the topmost coin of each stack is removed is unchanged from the viewpoint of the players and observers. This means that no information leaks through the protocol. Similarly, no information leaks when (top(t 1 ), top(t 2 )) is (•, •). Hence, we have confirmed the security of the protocol.

COPY Protocol
Here, we present how to make an identical commitment copy from a given coin-based commitment. In addition to a coin for Alice's secret bit a, we prepare two coins of •(= 0) and two more dummy coins. Alice stacks these coins as •0a0• (where we write 0 instead of • for convenience) and performs rflip, resulting in •ra r • for a random bit r where a = a ⊕ r . If a = 0, we have a = r , which leads to the situation where the second and fourth coins are equal to a; conversely, if a = 1, they are equal to a ⊕ 1. From these relations, we can obtain a COPY protocol as follows. In this protocol, there are two input candidates a ∈ U for a ∈ {0, 1}.
Five-coin COPY Protocol P COPY coin Input: Steps: Output: We can check the correctness and security, similarly to the procedure for P AND coin , regardless of whether the optional action at Step 6(c) is executed. With the optional action, the resulting stacks are •a; whereas, without it, one of them becomes •a with a probability of 1 2 . Note that the above COPY protocol, with one coin for input a, uses four additional coins and obtains two coins for a. If we use 2k + 2 coins, instead of the four coins, we can obtain 2k coins for a. Specifically, we replace the stacks for A R and T 1 in the inputs as follows. Instead of •• on A R (•• on T 1 , respectively), we set •• · · · •• (•• · · · •, respectively). The above protocol ends with two stacks, with k + 1 coins each, on T 1 and T 2 . With these two stacks, the bottoms k lower coins in each obtained stack are coins for a (2k coins in total).

OR Protocol
We now obtain a coin-based OR protocol by combining the above AND and NOT protocols. The OR of a, b ∈ {0, 1} is computed by flipping the result of P AND coin ( ab ). The following specifically shows the protocol. Note that, in the following protocol, we change the encoding in 00 , 01 , 10 , and 11 from the above AND protocol so that we can perform P AND coin ( ab ) without any action in advance.
Six-coin OR Protocol P OR coin Input: Steps: We can check the correctness and security of this protocol in the same manner as for the AND protocol.

XOR Protocol
Next, we explain a coin-based XOR protocol executed by Alice and Bob. To compute a ⊕ b, we introduce a random bit r , which is the remainder of the number of flips in rflip divided by 2. Note that both the number of flips and r are unknown to Alice and Bob. We add this r to both a and b, that is, we have a = a ⊕r and b = b ⊕r so that we compute Precisely, a and b are generated for an unknown unique r , as follows: We place the coin for b onto the coin for a as ba, and randomly flip the stack to b a = ba (unchanged when r = 0) or a b = ab (flipped when r = 1). Therefore, after the random flip, these coins are for a = a ⊕ r and b = b ⊕ r . To compute a ⊕ b = a ⊕ b, we select one of coins for a and b , and then flip the other coin if the selected coin is for a bit one. To avoid information leakage, we need to cover the coins with dummy coins and shuffle the coins in the selection.
The following shows the protocol. The initial arrangement is (•a•, | • b•, | , , ), and similarly to the above two protocols, there are four input candidates ab ∈ U for this protocol.
Six-coin XOR Protocol P XOR coin Input: Steps: Output: In a manner similar to that of previous protocols, we can check the correctness and security.

Toward More Protocols
The previous section shows concrete examples of coin-based protocols. Let us discuss protocols for other functionalities. Note that the set {NOT, AND} is known to be functionally complete. Hence, a protocol for any (two-variable) Boolean function can be realized by combining the coin-based NOT and AND protocols presented above.
Let us consider the composition of logical gates in a logic circuit. If the fan-out of a logical gate is two or more, the signal is duplicated to be connected to each gate. In a coinbased protocol, a one-bit value can be duplicated by the coinbased COPY protocol presented in Section 3.3. Therefore, by combining the coin-based NOT, AND, and COPY protocols, a protocol for any function can be constructed.
To make the discussion on the composition more clear and universal, we introduce another action, pick, and modify the initial states of the coin-based protocols presented in the above.

Pickup Action
Our example protocols in Section 3 produce their output as a coin with an unknown state (head or tail) because the coin is covered by another coin. Hence, it may be possible to compose protocols if a player can move the resulting coin of the first protocol into her or his hand as an input to the next protocol. Therefore, if it is possible to pick the resulting coin in one's hand without revealing its information, any secure function evaluation can be executed with our examples of NOT, AND, and COPY protocols. To this end, we provide the following action, called pick, which can also be implemented by humans.
• (pick, P 1 → P 2 , n) for P 1 ∈ {T 1 , T 2 , · · · , T k } and This action changes the tuple from (· · · , p 2 = , · · · | · · ·, p 1 , · · · ) to (· · · , turn(p The following is an implementation of pick that picks up a coin in three steps. Assume that there is a stack of two coins t 1 (•• or •• if the result is 1 or 0, respectively) on the table area T 1 as a result of the AND protocol, and that a player, Alice, wants to pick up the lower coin by performing (pick, T 1 → A L , 1) with her left hand A L where a L = . She places her hand over the stack to hide it (left of Fig. 5), removes the upper coin(s) of t

Modified Protocols Suitable for Composition
We are now ready to modify the protocols in Section 3. In Section 3, for simplicity, we assume that the players initially hold coins in their hands, in accordance with their inputs.
In this subsection, we modify the initial arrangement of the protocol so that the players do not hold coins but the coins are initially placed on the table. Let us first recall the COPY protocol presented in Section 3.3, with which the initial arrangement can be written as (a, ••| , |•, •, , ). Instead of this, let us consider the arrangement ( , | , |•, •, •a, ••) where the coin corresponding to a is put on the table area T 3 with a dummy coin (and both Alice's hands are empty). Using the pick action, we can easily move this commitment on T 3 to Alice's hand A L , namely (pick, T 3 → A L , 1). Then, (move, T 4 → A R , 2) brings the initial arrangement for the original COPY protocol. Thus, we modify the COPY protocol to start with a commitment to a on the table. Note that its output, namely two coins with dummy coins corresponding to a are on the table.
Next, let us recall the coin-based AND protocol in Section 3.2. The initial arrangement was (a, •|b•, b•| , , , ) for their inputs (a, b). We change the initial arrangement to Then, using the modified COPY protocol together with other actions, we can easily transform the initial arrangement into ( , | , |•a, •, •b, •b). After this, the following actions create coin-based commitments in hands that suffice for the AND computation.
That is, after these actions, the arrangement becomes identical to the initial arrangement of the coin-based AND protocol in Section 3.2; therefore, the players compute a ∧ b by performing Steps 1 to 9 of the protocol.
Note that it may be difficult to execute the above pick actions only by two players. In such case, another player, Charlie, provides assistance. For example, the first action is proceeded by: where C L and C R are Charlie's left hand and right hand, respectively. Hereinafter, we simply write that the pick actions are executed by Alice and Bob.
Similarly, one can easily modify the protocols for OR and XOR, where the coins are on the table in the initial arrangement.

Examples of Composition Protocols
In this section, we discuss a three-input AND protocol and a three-input majority decision protocol for inputs (a, b, c) ∈ {0, 1} 3 , as examples of composition.
The three-input AND is evaluated by a∧b∧c = (a∧b)∧c, which executes the (two-input) AND protocol twice. The procedure of the three-input coin-based AND protocol is as follows: 1 Alice, Bob, and Charlie place their inputs •a, •b, and •c on table T 1,1 , T 2,1 , and T 3,1 , respectively. 2 Alice and Bob perform the modified coin-based AND protocol so that they obtain t 1,1 = •(a ∧ b), namely the stack of resulting coins on T 1,1 for a ∧ b. 3 Alice and Charlie perform the modified coin-based AND protocol to compute (a ∧ b) ∧ c as in Step 2.
The three-input majority decision is evaluated by (a ∧ b) ∨ (b ∧ c) ∨ (c ∧ a). The coin-based OR protocol in Section 3.4 is a natural composition of the coin-based NOT protocol and AND protocol. Therefore, we use the protocols for NOT, AND, COPY, and OR as building blocks below.
1 Alice, Bob, and Charlie place their inputs •a, •b, and •c on table T 1,1 , T 2,1 , and T 3,1 , respectively. 2 Alice copies her input by using the modified COPY protocol so that the resulting stacks are t 1,1 = t 1,2 = •a. 3 Bob and Charlie each copy their inputs as in Step 2 above.
The resulting stacks are t 2,1 = t 2,2 = •b and t 3,1 = t 3,2 = •c. 4 Alice and Bob perform the modified coin-based AND protocol with coin stacks t 1,1 and t 2,1 to compute a ∧ b. Let t 1,1 = •(a ∧ b) be the resulting stack of coins. 5 Bob and Charlie perform the modified coin-based AND protocol with coin stacks t 2,2 and t 3,1 to compute b ∧ c. Let t 2,1 = •(b ∧ c) be the resulting stack of coins.

Effect of Human Error
In Section 3, we propose coin-based protocols that produce correct results when the players perform them. However, because humans make mistakes in general, the effect of human error on the protocols is discussed. For example, for the card-based AND protocol, Mizuki and Komano discussed the effect, the information leakage, human error [15]. Thus, in this section, we analyze the effect of human error in terms of information leakage and correctness. Let us discuss the effect on the six-coin AND protocol P AND Coin in Section 3.2. This protocol consists of the following five actions; "set the initial configuration," "hand coins from Bob's left hand (right hand, respectively) to Alice's left hand (right hand, respectively)," "move the stack of coins on the table," "shuffle the stacks of coins on the table," and "move the topmost coins of the stacks." Among these actions, Alice and Bob may make a mistake when they "hand coins from Bob's hand to Alice's hand"; namely, Bob may hand the stack of coins in his left hand (right hand, respectively) to Alice's right hand (left hand, respectively) incorrectly. As for the other four actions, because these actions are simple to execute, it seems that mistakes while performing them would be rare. Hence, let us consider the erroneous six-coin AND protocol where the following two steps are executed, with the probability of (1 − q 1 ), instead of Steps 1 and 2 in P AND Coin .
(1 ) (hand, A L ← B R ) (2 ) (hand, A R ← B L ) Figure 6 shows the extended diagram for the incorrectly performed protocol. If Bob hands a stack of coins to the wrong hand as (1') and (2') above, the protocol outputs a ∧b instead of a ∧ b.
Each sum of the probability traces of the bottom two nodes (final states) in Fig. 6 is ( p 00 , p 01 , p 10 , p 11 ), which means that no information on the inputs leaks even if the players make a mistake during the hand action. However, as we discussed the erroneous protocol outputs an incorrect result. For example, the protocol outputs 0 with an input pair (1, 1) with the probability of (1 − q 1 ) p 11 as in the second line from the bottom of the bottommost node in the diagram. Conversely, the protocol outputs 1 with an input pair (1, 0) with the probability of q 1 p 10 , as in the first line from the bottom of the bottommost node in the diagram.

Conclusions
This paper introduced the formal treatment for coin-based protocols and presented concrete examples to show that the secure multi-party computation is reliably executed with physical coins. An intriguing future work includes the development of more practical protocols with fewer coins.