2021 16th Asia Joint Conference on Information Security (AsiaJCIS)

A Privacy-Preserving Enforced Bill Collection

System using Smart Contracts
2021 16th Asia Joint Conference on Information Security (AsiaJCIS) | 978-1-6654-1788-4/21/$31.00 ©2021 IEEE | DOI: 10.1109/AsiaJCIS53848.2021.00018

Tomoki Fujitani Keita Emura Kazumasa Omote

University of Tsukuba National Institute of University of Tsukuba
National Institute of Information and National Institute of
Information and Communications Technology Information and
Communications Technology Japan Communications Technology
Japan Japan

Abstract—Maintaining a balance between anonymity and system, a bill collector has the role in the group manager. A
traceability is a fundamental issue in privacy-preserving systems. user of a service is given a signing key of a group signature
Isshiki et al. proposed an identity management system based scheme by the bill collector, generates a group signature as a
on group signatures in which a service provider anonymously
determines whether or not users of the service are legitimate certificate, and sends it to the service provider. Owing to the
members, and only a bill collector can identify users for the anonymity of group signatures, the service provider can only
purposes of sending them invoices. It is particularly worth noting verify whether or not the user is a valid group member and
that, under the Isshiki system, the service provider is not required then provide a service. After delivering the service, the service
to manage personal information such as user lists, which allows provider sends an invoice (a group signature) to a different
the system to outperform other in terms of preserving user
privacy and managing personal information leakage risk. It is entity, called the bill collector, who manages the opening
also noteworthy that the Isshiki system only considers cases in key of group signatures. The bill collector opens the group
which the bill collector identifies users who have used the service signature, identifies the user who has used the service, and
and that, in fact, identified users who ignore invoices can use the sends an (actual) invoice to the user. Because group signatures
service for free. In this paper, we extended the Isshiki system are traceable, there is no group signature that is valid but
by adding a smart contract-enabled enforcement bill collection
functionality. Under this functionality, deposits made by users cannot be traced to a user.
who do not pay a service fee are automatically transferred to
the bill collector. Because of their centralized structure, group
signatures are not suitable to blockchain systems, therefore, the
proposed system employs accountable ring signatures as building
blocks. The privacy-preserving enforced bill collection system
is implemented using the accountable ring signature scheme
developed by Bootle et al. and Ethereum smart contracts. To
reduce the gas costs associated with running smart contracts,
the smart contract is not run unless the user ignores an invoice,
and basic procedures are run via an off-chain channel. To avoid
the use of heavy cryptographic algorithms in carrying out the
accountable ring signature scheme for running smart contracts,
we employed standard elliptic curve digital signature algorithm
(ECDSA) signatures without especially changing the state to be Fig. 1. Isshiki System
verified in smart contracts.
In implementing the Isshiki system, potentially any group
I. I NTRODUCTION
signature scheme can be employed. Following a similar system
A. A Privacy-Preserving Bill Collection System proposed by Camenisch at al. [17], Isshiki et al. further
Group signatures [20] provide signer anonymity through the considered the use of revocations when users leave the service
use of the verification algorithm that checks only whether a or ignore an invoice, and defined a user-revocation manager
signer of a group signature is a member of the group, and that revokes users from the system (more precisely it expires
traceability through the use of an authority called a group users’ signing keys). To make the underlying group signature
manager or an opener who is only able to identify signers. scheme revocable, Isshiki et al. employed an extension of
These anonymity and traceability are important in preserving the Camenisch-Groth revocable group signature scheme [16].
privacy and accountability. For example, Isshiki et al. [29] We note that, although the bill collector and user-revocation
proposed a privacy-preserving identity management system manager can be the same entity under these schemes, the
using group signatures (hereafter referred to as the Isshiki service provider must be a distinct entity to ensure separation
system). The Isshiki system is shown in Figure 1. Under this of the tracing ability. It is particularly worth noting that the

978-1-6654-1788-4/21/$31.00 ©2021 IEEE 51

DOI 10.1109/AsiaJCIS53848.2021.00018

Authorized licensed use limited to: Synopsys. Downloaded on November 25,2021 at 11:06:09 UTC from IEEE Xplore. Restrictions apply.
service provider is not required to manage personal informa- Although smart contracts are a promising approach to
tion such as user lists, that eliminates the risk of personal implementing the Isshiki system, the centralized structure of
information leakage. Because information leakage incidents group signatures, where users’ signing keys are issued by a
are common, the Isshiki system outperforms other in terms of group manager, is not fully compatible with a decentralized
preserving user privacy while managing personal information blockchain system. Typically, blockchain systems employ ring
leakage risk. Isshiki et al. presented their system as an identity signatures [40] (or their linkable variants [37], [47]) because
management scheme, the Isshiki system can be considered a users generate signing keys by themselves. However, ring
privacy-preserving bill collection system. signatures do not support the tracing functionality necessary
for the Isshiki system. Thus, we employ accountable ring
Extension of the Isshiki System: The Isshiki system assumes
signatures [13], [50] that support both stand-alone key gener-
that the bill collector is trusted for user identification in the
ation and tracing functionality.1 In particular, the accountable
sense that the open results of group signatures are always
ring signature scheme proposed by Bootle et al. [13], which
trusted. Problems can arise, however, when even users who
supports the Judge algorithm and weak opening soundness
do not use the service are required to pay a service fee, which
as found under the Emura-Hayashi extension [26], is used
would be impossible to prevent owing to anonymity. As a
by the proposed system. We demonstrated implementation of
service that generated such illegal fees would be unlikely to
the proposed system using the Bootle et al. accountable ring
be used, we can realistically assume that the bill collector
signature scheme and Ethereum smart contracts [49].
will not send charges to users who do not use the service.
Similarly, we assume that services are always performed by C. Differences from Fair Exchange
service providers (once again, a system in which this did not It might be assumed that the proposed enforced bill col-
occur would be unlikely to be used). However, it is possible lection system, which essentially involves the exchange of
for users who have used the service to claim that they did services and fees, could be constructed from a fair exchange
not, in fact, use it and insist that the bill collector has made a scheme. Although this would be possible, the proposed system
mistake. In this case, the bill collector must prove that the open differs from fair exchange in several respects. Several opti-
result is correct. Emura and Hayashi [26] considered a case in mistic fair exchange (OFE) systems, especially smart contract-
which the bill collector generates a proof for opening and the based systems, have been proposed [6], [18], [24], [25],
Judge algorithm is used to publicly check whether the opening [45], [48]. In these systems, a trusted third party (TTP), or
result is correct (see Section II-A for details of the syntax). adjudicator, is replaced by smart contracts.2 Although the
Although the Judge algorithm had previously been defined TTP (adjudicator) is implemented only if an exchange fails,
in the group signature context under the Bellare-Shi-Zhang its involvement in cryptographic protocols should still be
(BSZ) model [9], Emura and Hayashi further considered the minimized. From this perspective, smart contract-based OFEs
weak opening soundness defined in the Sakai et al. model [42], serve as reasonable instantiations of OFE in practice. For
which captures the unforgeability of the opening proof. example, under OptiSwap [25], which is known to be the most
Remaining Issue with the Isshiki System: The Isshiki system efficient smart contract-based OFE system to date, a buyer
(as well as its extension [26]) considers only the case in which pays a coin to a seller in exchange for a witness x that satisfies
the bill collector identifies users who have used the service. If, φ(x) = 1 for a predicate function φ. If the final value x is not
in fact, an identified user ignores invoices, they are able to use correct, that is, φ(x) = 0, then the buyer initiates an interactive
the service for free. Although they will of course be subse- dispute protocol (SmartJudge [48]) that freezes the coins in the
quently revoked from the system, the revocation functionality contract.
itself will not help in collecting the fee. Therefore, practical The proposed enforced bill collection system adds smart
implementation of the Isshiki system requires the introduction contracts to the Isshiki system to support a functionality for
of a method for forcibly collecting service fees. forcibly collecting service fees from users. As under the Isshiki
system, it is assumed that all agreed-upon services are always
B. Our Contribution provided to the users; by contrast, OptiSwap considers cases in
In this paper, we propose a privacy-preserving enforced bill which services are not provided, that is, φ(x) = 0, and initiates
collection system supporting a functionality for forcibly col- the dispute protocol when this happens. By introducing the
lecting service fees from users. The proposed system employs assumption that all services are provided, the proposed system
smart contracts that provide a mechanism for automatically avoids the dispute protocol, thereby reducing the number
executing programs on the blockchain. Intuitively, a user sends of procedures that need to be run in the smart contract.
a deposit to the smart contract before receiving a service, Furthermore, the service fee is transferred via typical payment
which is delivered by the service provider via the Isshiki systems, that is, the smart contract is employed only when
system. If the user pays the service fee, that is, the user a user ignores an invoice. Under OptiSwap, by contrast, the
accepts the invoice sent by the bill collector, the deposit service fee is always transferred via smart contract, making
is automatically refunded to the user; otherwise, if the user 1 In this paper, we adopted the suggestion by Sato et al. [43] that accountable
ignores the invoice the deposit is automatically transferred to ring signatures are useful in blockchain systems.
the bill collector. 2 We note that, in [36], both a TTP and smart contracts are used.

52

Authorized licensed use limited to: Synopsys. Downloaded on November 25,2021 at 11:06:09 UTC from IEEE Xplore. Restrictions apply.
gas costs necessary for each payment even when the buyer and specific value). Although, unlike the proposed system, PGC
seller correctly exchange the coin and witness. In Section IV, checks whether confidential transactions follow compliance, it
we demonstrate the effectiveness of our assumption in terms supports no functionality to forcibly collect amounts.
of reducing gas costs. Zhang et al. [51] proposed an onion chain that considers
both the privacy and traceability of blockchain-based appli-
D. Related Work cations. Their system is inspired by Onion routing protocols,
Achieving privacy with traceability, auditability, or account- in which there are many hops between each transmitter and
ability is an important issue in blockchain systems.3 Damgård receiver and identity disclosure is obtained by reversing the
et al. [23] proposed a system in which accounts are generally message transmission process. Although each message in
anonymous but can be identified when accidents occur. In this an onion chain is encrypted, anonymity and traceability are
system, each user has an identity and credentials authorized achieved through a non-cryptographic approach, whereas the
by an identity provider and, through the use of a threshold proposed system employs accountable ring signatures that
cryptosystem, an appropriate number of anonymity revokers guarantee anonymity and traceability via cryptography.
can identify the user. As in the Isshiki system, it only considers
the case that anonymity revokers identify users, and there is II. P RELIMINARIES
no explicit mechanism for collecting service fees.
Kosba et al. [30] proposed a decentralized privacy- A. Accountable Ring Signatures
preserving smart contract system called Hawk in which finan- Here, we introduce accountable ring signatures [13], [50]
cial transactions are encrypted and stored on the blockchain. which is a generalization of ring signatures and group signa-
In developing their approach, they considered how to ensure tures. Briefly, as in ring signatures, each user generates own
financial fairness against malicious contractual parties who public key pk and secret key sk. This decentralized structure
prematurely abort from a protocol to avoid making finan- matches blockchain systems. There are openers where each
cial payment. Hawk guarantees that the aborting party will opener has a public key opk and a secret key osk. When a user
be financially penalized while the remaining parties receive who has (pk, sk) generates a ring signature Σ on a message M ,
compensation. The system proposed in this paper can also be the user selects a set of public keys, which we call ring R, and
regarded as one that ensures financial fairness through the use assume that pk ∈ R. The user then designates an opener by
of smart contracts. specifying opk. From (Σ, M ), it is possible to verify whether
Büunz et al. [14] proposed a decentralized, confidential the signer is a member of R; that is, that there exists pk ∈ R
payment mechanism called Zether in which account bal- for which the corresponding sk has been used to generate Σ.
ances are encrypted and their validity is proved using zero- As under the group signatures approach, the designated opener
knowledge proofs. As in Monero [2], the sender and re- can trace the signer using osk.
ceiver involved in a transaction are hidden among a group
of users, enabling a level of anonymity equivalent to that Definition 1 (Syntax of Accountable Ring Signatures [13]):
under group/ring signatures.4 Zether introduced a new type • Setup(1λ ): The setup algorithm takes the security param-
of zero-knowledge proof, Σ-Bullets, which enhances the in- eter λ ∈ N as input and outputs the common parameter
teroperability of Σ-protocols [22] with Bulletproofs [15]. Σ- pp.
Bullets are constructed using zero-knowledge proofs, public • OKGen(pp): The opener key generation algorithm takes
key encryption, and digital signatures, which are essentially pp as input and outputs the opener public and secret keys
the components used under the Bootle et al. accountable opk and osk, respectively.
ring signature scheme [13] employed in our implementation. • UKGen(pp): The user key generation algorithm takes pp
Unlike the proposed system, Zether does not consider user as input and outputs the user public verification key pk
identification because all users are essentially equivalent and and the user secret signing key sk.
all transactions are sent among them. • RSign(opk, M, R, sk): The signing algorithm takes the
Chen et al. [21] proposed an auditable decentralized con- designated opener public key opk, a message to be signed
fidential payment system called Pretty Good Confidentiality M , a ring R, and sk as inputs and outputs a ring signature
(PGC). In this context, auditability means that an auditor Σ. Here, R is a set of user public keys and the pk
specifies a set of transactions and requests that the participants corresponding to sk is assumed to be pk ∈ R.
prove compliance with several policies, such as a limit policy • RVerify(opk, M, R, Σ): The verification algorithm takes
(under which the sum of amounts is less than a limit), a rate opk, M , R, and Σ as inputs and outputs 1 (accept) or 0
policy (under which the ratio of two transfer amounts is a (reject).
specific value), or an open policy (under which the underlying • Open(M, R, Σ, osk): The open algorithm takes as M , R,
transfer amount of a confidential transaction is equal to a Σ, and osk as inputs and outputs pk ∈ R of the signer
and its proof π or ⊥ otherwise.
3 A useful survey of auditability and accountability in distributed payment
• Judge(opk, M, R, Σ, pk, π): The judge algorithm takes
systems was published by Chatzigiannis et al. [19].
4 That is, user keys can be reused. Fauzi et al. proposed Quisquis [27], opk, M , R, Σ, pk, and π as inputs and outputs 0 if
which applies a stronger anonymity in which each key is used only once. RVerify(opk, M, R, Σ) = 0; otherwise, it outputs 1 to

53

Authorized licensed use limited to: Synopsys. Downloaded on November 25,2021 at 11:06:09 UTC from IEEE Xplore. Restrictions apply.
 indicate that Σ is generated by sk corresponding to pk, collector via the smart contract. The bill collector is assumed
and 0 otherwise. to send no illegal charges to users who do not use the service,
In [13], Bootle et al. defined unforgeability, anonymity, and services are always provided by the service providers (as,
traceability, and tracing soundness. See [13] for details on otherwise, the system would not be used). We note that ring
these security definitions. signatures are sent via an off-chain channel because the user
The signing and verification algorithms contain a ring R, address becomes public when the transaction is issued, which
which is a set of public keys. In systems in which an authority detracts from anonymity. We also note that we do not consider
such as the public key infrastructure (PKI) administrator anonymity when a fee is forcibly collected via a smart contract.
publishes all public keys as a list, revocation can be simply
Security Requirements: As in the Isshiki system, we assume
performed by having a verification algorithm check whether
that the service provider and bill collector do not collude with
or not a ring is a subset of the list and removing a public
each other and follow the protocol description (i.e., that they
key from the list if the corresponding user is revoked. Under
are semi-honest entities). Our security requirements are as
the proposed system, the service provider manages the list. To
follows:
verify group signatures, the verification algorithm takes a com-
mon group public key as an input. As a result, the revocation • User Anonymity: No one, except for the bill collector,
of group signatures is much more complex (e.g., [5], [8], [11], can identify a user from a certificate.
[26], [28], [31]–[34], [38], [39], [41], [44]) than the revocation • Certificate Unforgeability: No one can modify/forge a
of (accountable) ring signatures; this is an additional advantage certificate.
of employing accountable ring signatures under the Isshiki • Collection Correctness: Each fee is correctly collected
system. from each user by the bill collector even if the user
Fully dynamic group signatures [7], [12], [35] allow users to ignores a payment request.
join and leave a system at any time. As their results demon-
strated that accountable ring signatures can be regarded as A Straightforward Construction and its Limitation: Here,
fully dynamic group signatures, we can say that the proposed we make an initial consideration of a straightforward incor-
system is based on fully dynamic group signatures and smart poration of smart contracts into the Isshiki system (based
contracts. on the use of accountable ring signatures) and explain the
limitations of this approach from the perspective of gas cost.
B. Smart Contracts We assume that a user has generated a ring signature and
Smart contracts provide a mechanism for the automatic that the bill collector receives it as an invoice. Because under
execution of programs on a blockchain. In deploying a smart the Isshiki system (specifically, under the Emura-Hayashi
contract, the conditions of a transaction (trigger) are specified extension [26]) the bill collector outputs the identity of the
in addition to the terms of the contract. If these conditions are user (i.e., the opening result) and a proof of opening, the
satisfied, the contract (program) is automatically run. Smart most straightforward trigger for running a smart contract is
contracts can be used in cryptocurrencies such as Ethereum, signature and proof verification using the Judge algorithm (we
EOS, and Steem. In this study, we used Ethereum, which is note that the RVerify algorithm is run internally within the
currently the second-largest cryptocurrency in terms of market Judge algorithm because it outputs 0 if Σ is invalid). That is,
capitalization. To carry out an Ethereum transaction, a fee the bill collector inputs the ring signature, the identity of the
known as the gas cost, which depends on the number of user (more precisely the user public key), and the proof, and
computation steps and the size of the storage space needed the smart contract transfers the deposit to the bill collector
for the transaction, must be paid. Ethereum gas costs are paid address only if both the ring signature and proof are valid.
in the Ethereum coin ETH. Thus, each smart contract needs to run the Judge algorithm.
In our implementation, we employed the Ropsten testnet [3] To reduce the gas costs required to run a smart contract, the
as the implementation environment for Ethereum. Because procedures run by the contract should be as simple as possible.
Ropsten, like the Ethereum main network, applies the Proof This is particularly important given the recent rise in Ethereum
of Work (PoW) consensus algorithm, it allowed us to closely prices.5
emulate actual operation
Our Construction Idea: To reduce the gas cost, the smart
III. P ROPOSED E NFORCED B ILL C OLLECTION S YSTEM contract does not explicitly check the validity of the ring signa-
ture and opening proof because anyone can check their validity
In this section, we present the proposed privacy-preserving
outside of the blockchain. Let (opk, M, R, Σ, pki , π) be a ring
enforced bill collection system. The system comprises three
signature and opening proof input to the Judge algorithm.
entities: user, service provider, and bill collector. The service
Since the public key of the bill collector opk is included in the
provider verifies a certificate (a ring signature) and provides
input, the algorithm also checks whether π is introduced by
a service. As in the Isshiki system, service providers have no
personal data. The bill collector identifies users who have used 5 For example, the price of 1 ETH rose from 128.72US$ on January 1st,
the service and sends invoices to them. If a user does not pay 2020 to 384.47US$ on April 11, 2020. See Ethereum Price (ETH) Price Index
a fee, the fee is automatically or forcibly transferred to the bill and Live Chart-CoinDesk (https://www.coindesk.com/price/ethereum).

54

Authorized licensed use limited to: Synopsys. Downloaded on November 25,2021 at 11:06:09 UTC from IEEE Xplore. Restrictions apply.
the bill collector. Owing to the unforgeability and weak open- following methods:
ing soundness of the underlying accountable ring signature • Method 1: A smart contract is assigned to each user,
scheme, (M, Σ) and π are unforgeable. However, if someone with the number of smart contact deployments depending
declares (opk, M, R, Σ, pk , π) where pki = pk and pk ∈ R, linearly on the number of users. We let sc addri be the
then (M, Σ) is still valid since RVerify(opk, M, R, Σ) = 1 address of the smart contract for user i.
holds but the Judge algorithm outputs 0. So, it may be used for • Method 2: All users share a smart contract. The common
a proof that the key holder of pk did not generate Σ and thus smart contact is deployed only once; in place of deploying
it should be guaranteed that the tuple (M, R, Σ, pki , π) is not new contracts, it is necessary to manage a user list
modified. In other words, we cannot guarantee that the staste of containing the address of each user and to search it when
the verification outside of the blockchain is the same as that of a program is run for a user. We let sc addr be the address
the smart contract verification unless (M, R, Σ, pki , π) is guar- of the common smart contract.
anteed to be unmodified. Thus, in our system we additionally
• Setup: The setup phase involves key generation and the
emoloy a signature scheme where the bill collector generates
deployment of smart contracts.
a signature σ on each ring signature and opening proof. In our
- (S-1) Bill Collector: Generate the opener public key
implementation, we employ the elliptic curve digital signature
opk of the accountable ring signature scheme such
algorithm (ECDSA), which has been widely employed in
that pp ← Setup(1λ ) and (opk, osk) ← OKGen(pp).
Ethereum smart contracts. We remark that in Solidity that
Generate a key pair of the signature scheme such that
is used in our implementation, the sender of a message can
(vk, sigk) ← KGen(1λ ). Publish (pp, opk, vk) as the
be verified by require(msg.sender==Bill Collector) that also
public key of the bill collector.
guarantees the transaction is not modified. However, it does not
- (S-2) User i: Let addri be the address. Generate a
verify the transaction itself, especially an ECDSA signature,
verification key and a signing key for the account-
and thus, we explicitly verify the ECDSA signature in our
able ring signature scheme such that (pki , ski ) ←
system and the smart contract transfers the deposit only if
UKGen(pp). Send pki to the service provider (via an
the ECDSA signature is valid.6 In terms of running time,
off-chain channel) and notify the bill collector that
the Judge algorithm is approximately 107 times slower than
user i is participating in the system.
the ECDSA verification algorithm (see Section IV). Thus, by
- (S-3) Bill Collector: Deploy smart contacts according
employing ECSDA signatures it is possible to significantly
to the method. In both cases, the addresses addrbc and
reduce the number of procedures performed by the smart
vk are set in the contract (in our implementation, vk is
contract.
used as addrbc ). addrbc is used to transfer a deposit
Proposed Enforced Bill Collection System: Here, we de- from addri to addrbc , and vk is used for ESDSA
scribe the proposed bill collection system. The system op- verification.
erates in four steps: Setup, Authentication, BillCollection, - Method 1: Deploy the smart contract sc addri for
and Revocation. In Figure 2, we illustrate the flow of user i. Set the addresses addrbc and vk in the
this system when a user does not pay a service fee. Let contract.
(KGen, Sign, Verify) be a signature scheme. For a security - Method 2: Deploy a common smart contract,
parameter λ ∈ N, the KGen algorithm generates a verifica- sc addr. Set the addresses addrbc and vk in
tion key vk and a signing key sigk such that (vk, sigk) ← the contract and set a user list ulist =
KGen(1λ ). For a message M , the Sign algorithm generates {(addri , Deposit)}, for which the initial value is
a signature σ using sigk such that σ ← Sign(sigk, M ). The the empty set.
Verify algorithm outputs 1 if σ is a valid signature on M under - (S-4) User i: Set addri and deposit it into the con-
vk such that Verify(vk, M, σ) = 1, and outputs 0 otherwise. tract.7 Without loss of generality, we assume that the
In this implementation, the ECDSA is employed. We let i deposit is higher than the service fee.
be the user index, where addri the address of user i, and - Method 1: Set addri and the deposit to sc addri .
we let (pki , ski ) be the verification and signing keys of the - Method 2: Set addri and the deposit to sc addr.
accountable ring signature scheme generated by the UKGen The contract searches addri to determine if it
algorithm. We assume that the service provider manages the is contained in ulist: if not, (addri , Deposit) is
public key list plist = {pki } and each user defines a ring R registered as ulist; otherwise, the deposit of the
by selecting public keys from plist. We then consider the two entry of addri is updated to the current deposit
value.
6 We remark that in our implementation first the smart contract runs the
require check, and then checks the validity of the ECDSA signature. This
- (S-5) Bill Collector: Confirm that user i has set addri
double check might be redundant, however, purposes of these procedures are and the deposit in the contract. Notify the service
different, i.e., the former checks who sent the transaction and the latter checks
the validity of the ECDSA signature. Moreover, the gas cost is increased 7 If user i interacts with the smart contract right after sending pk to the
i
just 0.2% (5.28 × 10−7 EHT, 0.0003 USD) compared to the case that smart service provider, then it may allow timing attacks (especially if the number
contract does not run the require check and checks the validity of the ECDSA of users is small) that deanonymize users to the service provider. Thus, we
signature only. Thus, we selected the current option as our system. assume that user i interacts with the smart contract after a certain period.

55

Authorized licensed use limited to: Synopsys. Downloaded on November 25,2021 at 11:06:09 UTC from IEEE Xplore. Restrictions apply.
 Fig. 2. Flow of proposed bill collection system in enforced bill collection case

provider that the contract has been configured for user i. The contract is only executed if i ignores the
i. invoice, in which case the following two processes
- (S-6) Service Provider: Add pki to plist. Using this are carried out:
procedure, non-registered users who do not set de- - (B-2) Bill Collector: Generate a signature on
posits in the contract can be prevented from using (M, Σ, pki , π, R) such that M  := M, Σ, pki , π, R
the service. and σ ← Sign(sigk, M  ). (M  , σ) then becomes
• Authentication: The user generates a ring signature as a the trigger for the contract to transfer the deposit.
certificate and the service provider verifies the validity To reduce the search cost under Method 2, the
of the signature and then provides the service. These bill collector indicates the index i of ulist, that is,
processes occur on an off-chain. ulist[i ] = (addri , Deposit).
- (A-1) User i: Select a ring R ⊆ plist, where - Method 1: Input (M  , σ) to sc addri .
pki ∈ R. Generate a ring signature Σ ← - Method 2: Input (M  , σ) and i to sc addr where
RSign(opk, M, R, ski ) on the message M : = {Service ulist[i ] = (addri , Deposit).
Name: yyyy/mm/dd: Use}. Send the certificate - (B-3) Smart Contract: For (M  , σ), the contract
(R, M, Σ) to the service provider. checks whether Verify(vk, M  , σ) = 1. Here, vk is
- (A-2) Service Provider: If R ⊆ plist and intentionally excluded as an input value because vk
RVerify(opk, M, R, Σ) = 1 hold, the service provider has been set in the contract as the verification key
provides the service and sends (R, M, Σ) to the bill for the bill collector.
collector. - Method 1: If Verify(vk, M  , σ) = 1, the deposit is
• BillCollection: For each (R, M, Σ) sent by the service transferred from sc addri to addrbc ; otherwise, if
provider, the bill collector opens a ring signature using Verify(vk, M  , σ) = 0, do nothing.
osk and sends an invoice to the user via an off-chain - Method 2: If Verify(vk, M  , σ) = 1, then transfer
channel.8 If the user ignores the invoice, the contract the deposit from sc addr to addrbc ; otherwise, if
forcibly transfers the deposit set by the user to the bill Verify(vk, M  , σ) = 0, do nothing.
collector.
• Revocation: Here, we consider the case in which user i
- (B-1) Bill Collector: Open (R, M, Σ) such that intentionally leaves the service. However, this approach
(pki , π) ← Open(M, R, Σ, osk) to identify user i.9 can also treat cases in which users are revoked because of
Send an invoice containing (M, Σ, pki , π, R) to user misbehavior involving, for example, ignoring an invoice.
8 Of In this case, phase (R-3) is sufficient after the deposit has
course, here we do not restrict what currency is used for this payment.
9 Because the service provider has checked the validity of Σ, the Open been forcibly transferred ((B-2) and (B-3)).
algorithm will correctly identify the user owing to the traceability of the - (R-1) User i: Notify the bill collector to delete the
accountable ring signature scheme and, therefore, we do not consider the
case in which the Open algorithm outputs ⊥. membership of i from the service.

56

Authorized licensed use limited to: Synopsys. Downloaded on November 25,2021 at 11:06:09 UTC from IEEE Xplore. Restrictions apply.
 - (R-2) Bill Collector: If addri is not contained in ulist, were input and the API returned the verification key recovered
the request is rejected. Otherwise, the leave message from σ. In our implementation, the verification key of the bill
is forwarded to the service provider. For a revocation collector, vk, was set in the deployment phase (S-3) and the
message Mrevoke :={Service Name: yyyy/mm/dd: contract checked whether vk was the same as the verification
Revoke}, generate σ ← Sign(sigk, Mrevoke ) as the key recovered from σ in (B-3).
trigger for refunding the deposit. First, we show the running times of cryptographic algo-
- Method 1: Input (Mrevoke , σ) to sc addri . rithms in Table I. We used MacBook Pro (2.3 GHz Intel Core
- Method 2: Input (Mrevoke , σ) and i to sc addr i5, 16 GB 2133 MHz LPDDR3).
where ulist[i ] = (addri , Deposit).
- (R-3) Service Provider: Delete pki from plist. TABLE I
RUNNING T IMES OF S IGNATURE S CHEMES
- (R-4) Smart Contract: For (Mrevoke , σ), the contract
checks whether Verify(vk, Mrevoke , σ) = 1. Signature Algorithm Time (ms)
RSign 13.7
- Method 1: If Verify(vk, Mrevoke , σ) = 1, the deposit Accountable RVerify 11.0
is transferred from sc addri to addri . Otherwise, Ring Signatures Open 17.4
do nothing. Judge 17.1
ECDSA Sign 9.9 × 10−2
- Method 2: If Verify(vk, Mrevoke , σ) = 1, transfer Verify 1.6 × 10−1
the deposit from sc addr to addri and remove the
entry addri from ulist. Otherwise, do nothing. As mentioned previously, the Judge algorithm runs the RVerify
Security Discussion: Here, we briefly describe how the sys- algorithm internally and, therefore, its running time contains
tem satisfies the following security requirements: that of the RVerify algorithm. We note that, although the
• User Anonymity: Owing to the anonymity of the under- ECDSA Verify algorithm is run in the smart contract im-
lying accountable ring signature scheme, the certificate plemented in our system, the results in Table I show the
(R, M, Σ) does not leak information on user i. We note running time of the Verify algorithm on an off-chain envi-
that we do not consider leakage from meta-information ronment as a reference. In terms of running time, the Judge
such as IP addresses or messages to be signed, M . algorithm is approximately 107 times slower than the ECDSA
• Certificate Unforgeability: Owing to the unforgeability verification algorithm. This result indicates the effectiveness
of the underlying accountable ring signature scheme, the of our approach and suggests the usefulness of employing
certificate (R, M, Σ) is unforgeable. ECDSA instead of verifying accountable ring signatures in
• Collection Correctness: Each invoice contains (M, Σ, pki , implementing smart contracts.
π, R), where π proves that Σ is generated by ski corre- We then evaluated the proposed system in terms of the gas
sponding to pki , i.e., that user i has provided the service. costs relating to smart contract execution. To assess these, we
Owing to the traceability of the underlying accountable used the Ethereum testnet Ropsten [3], with the results listed
ring signature scheme, the opening result i is correct. in Table II. Our experiment was run on December 9, 2020
Moreover, owing to the weak opening soundness of between 5:25 and 5:45 (UTC), during which 1 ETH=573.44
the underlying accountable ring signature scheme, π is USD. We set the gas price to three Gwei (1 Gwei= 1.0 ×
unforgeable. Finally, owing to the unforgeability of the 10−9 ETH). We considered the case in which one transaction
signature scheme, no one except the bill collector can is included in a block within a minute. The Deploy, Send
run the smart contract. ETH, Enforced Bill Collection, and Refund laws were used
to describe, respectively, the deployment phase undertaken
IV. I MPLEMENTATION by the bill collector (S-3), the deposit phase undertaken by
In this section, we discuss the implementation results ob- users (S-4), the enforcement bill collection phase (B-4), and
tained using an accountable ring signature scheme constructed the revocation phase (R-4). We recall that one smart contract
following Bootle et al. [13] with a ring size of N = nm . is assigned per user under Method 1 and a common smart
Because Morero used a ring size of 11, [46], we set n = 4 contract is shared by all users under Method 2. In Method 2,
and m = 2 to obtain a ring size of N = 16. The security of the the search cost depends linearly on the number of users (i.e., a
Bootle et al. scheme relies on the hardness of the decisional simple sequential search is required); therefore, we evaluated
Diffie-Hellman (DDH) problem. Accordingly, in implementing the costs under Method 1 and under Method 2 for cases of
the scheme we used the Curve25519 [10], which is known three, 50, and 100 users, respectively. Although under Method
to be a DDH-hard curve. We generated ECDSA signatures 2 the list (ulist) is also set during the deployment phase, this
using the ethereumjs-util [1] of Node.js. We note that, whereas initial setting does not require a list size and, therefore, the
an ECDSA signature is usually described as σ = (r, s), in cost does not depend on the number of users. The index i is
Ethereum smart contracts σ = (r, s, v), with the additional input to remove entries from ulist, which allows the contract
value v used to obtain the verification key from σ. Using a to directly remove entries without searching them. As a result,
Solidity API (erecover), an ECDSA signature σ = (r, s, v) the cost of the revocation phase does not depend on the number
and a message M  (which was hashed in our implementation) of users.

57

Authorized licensed use limited to: Synopsys. Downloaded on November 25,2021 at 11:06:09 UTC from IEEE Xplore. Restrictions apply.
 TABLE II
G AS C OSTS PER T RANSACTION

Operation Method 1 Method 2

Gas cost Dollar Gas Cost (ETH) Dollar
(ETH) (USD) 3 Users 50 Users 100 Users 3 Users 50 Users 100 Users
Deploy 2.18 × 10−3 1.25 3.03 × 10−3 1.74
Send ETH 1.43 × 10−4 0.082 2.18 × 10−4 4.73 × 10−4 7.46 × 10−4 0.125 0.271 0.428
Enforced Bill Collection 2.60 × 10 −4 0.149 2.69 × 10−4 0.154
Refund 2.15 × 10−4 0.123 2.16 × 10−4 0.124

As seen from Table II, the deployment of smart contracts TABLE IV

requires the highest gas cost of all operations. Method 1 C OMPARISON OF M ETHOD 2 AND PAY PAL
requires several contract deployments but does not require Total User PayPal (USD) Method 2 (USD)
a search operation, whereas Method 2 deploys a contract 3 9.6 2.5
only once but requires a search operation. Table III shows 50 160.0 21.6
100 320.0 57.2
a comparison of the costs of Method 1 and Method 2 more
concretely for three, 50, and 100 users, respectively. It is
TABLE V
assumed that, 33% (resp. 10%) of the users pay no fee and G AS COSTS UNDER O PTI S WAP
their deposits are forcibly collected for the three-user case
(resp. for the 50 and 100-user cases); this corresponds to one Case Function ETH USD
Deployment (Seller) 6.82 × 10−3 3.91
Enforced Bill Collection and two Refunds for the three-user Optimistic accept (Buyer) 9.72 × 10−5 0.056
case, five Enforced Bill Collections and 45 Refunds for the 50- revealKey (Seller) 1.65 × 10−4 0.095
noComplain (Buyer) 4.16 × 10−5 2.38 × 10−2
user case, and 10 Enforced Bill Collections and 90 Refunds
challenge (Buyer) 2.88 × 10−3 1.66
for the 100-user case. We note that each user must pay gas Pessimistic response (Seller) 1.58 × 10−2 9.04
costs when setting the deposit in the contract (S-4); we assume complainAboutLeaf (Buyer) 5.82 × 10−4 0.33
that these costs are paid by the bill collector. It is seen from
Table III that the cost of Method 2 is lower than that of Method
1, indicating that Method 2 is more efficient. 5. Aggregated gas costs for the challenge-response procedure
for a file sale based on OptiSwap). For the comparison, we
TABLE III set 1 ETH=573.44 USD and the gas price to 3 GWei. Our
C OMPARISON OF COSTS M ETHODS 1 AND 2 implementation results are listed. Unlike the proposed system,
Number of Users Method 1 (USD) Method 2 (USD)
under OptiSwap both the buyer and seller must run smart
3 4.4 2.5 contracts and pay gas costs; therefore, the table notes the
50 73.0 21.6 entity that runs each function in parentheses. Under OptiSwap,
100 146.0 57.2 where each buyer pays a coin to their seller in exchange for
a witness x that satisfies φ(x) = 1 for a predicate function
We then compared Method 2 with an actual online pay-
φ, each seller encrypts x using a symmetric key encryption
ment system, PayPal10 . Note that, unlike our system, PayPal
scheme and generates commitments of the encryption key
must manage personal information such as users’ real names,
and ciphertext. The seller deploys a smart contract containing
bank accounts or credit card numbers, etc., and, therefore,
the addresses of the seller and buyer, the price, and the
anonymity is not guaranteed. We assumed that all transactions
commitments (deployment in Table V). The seller sends a
were made in the United States and settled online, with a per-
ciphertext to the buyer directly (i.e., via an off-chain channel).
transaction fee of 2.9% plus 0.3 USD based on the assumption
The buyer checks the values contained in the smart contract
that each person made a payment of 100 USD (these fees
and, upon acceptance, sends a transaction to the smart contract
are paid by PayPal). Table IV shows a comparison between
(see Table V). The coins are then locked into the contract
the results of Method 2 and PayPal in terms of fees for the
and the buyer can no longer obtain a witness x. Finally, the
cases of three, 50, and 100 users, respectively. It is seen that,
seller reveals the encryption key and its validity is checked
even though the proposed system guarantees user anonymity
by decommitting the commitment (revealKey in Table V). If
and has an enforced bill collection functionality, the gas costs
the decryption result is correct, that is, φ(x) = 1, then the
paid by the service manager (bill collector) are less than those
buyer obtains the witness (noComplain in Table V). If not,
under PayPal.
i.e., if φ(x) = 0, the buyer initiates an interactive challenge-
Finally, we compared Method 2 with OptiSwap [25], which
response dispute protocol (SmartJudge [48]) that freezes the
is known to be the most efficient smart contract-based OFE
coins in the contract (challenge and response in Table V). We
system to date. Table V shows gas costs under OptiSwap.
note that the function complainAboutLeaf in Table V is an
We adopted the gas costs given in [25] (Table 3. Gas costs of
option for implementing the contract (see [24] for details).
all functions executed in the optimistic execution, and Table
As mentioned previously, under the proposed system it is
10 PayPal Holdings, Inc. -https://www.paypal.com/us/home assumed that a service is always provided to a user; by

58

Authorized licensed use limited to: Synopsys. Downloaded on November 25,2021 at 11:06:09 UTC from IEEE Xplore. Restrictions apply.
contrast, OptiSwap considers cases in which services are not [7] Michael Backes, Lucjan Hanzlik, and Jonas Schneider-Bensch. Mem-
provided. To demonstrate the effectiveness of this assumption bership privacy for fully dynamic group signatures. In ACM CCS, pages
2181–2198. ACM, 2019.
in reducing gas costs, we show an optimistic case (in which [8] Nasima Begum and Toru Nakanishi. Efficiency improvement in group
the service is normally provided and the fee is paid) and a signature scheme with probabilistic revocation. J. Inf. Process., 27:508–
pessimistic case (in which the buyer finds that the received 516, 2019.
[9] Mihir Bellare, Haixia Shi, and Chong Zhang. Foundations of group
witness is incorrect, that is, φ(x) = 0, and runs the dispute signatures: The case of dynamic groups. In CT-RSA, pages 136–153,
protocol) for OptiSwap in Table V. Table VI shows the 2005.
comparison of Method 2 and OptiSwap. [10] Daniel J. Bernstein. Curve25519: New Diffie-Hellman speed records.
In Public Key Cryptography, pages 207–228, 2006.
[11] Dan Boneh and Hovav Shacham. Group signatures with verifier-local
TABLE VI revocation. In ACM CCS, pages 168–177, 2004.
C OMPARISON OF M ETHOD 2 AND O PTI S WAP [12] Jonathan Bootle, Andrea Cerulli, Pyrros Chaidos, Essam Ghadafi, and
Jens Groth. Foundations of fully dynamic group signatures. In Applied
Number of Users Method 2 (USD) OptiSwap (USD)
Cryptography and Network Security, pages 117–136, 2016.
3 2.5 19.2
50 21.6 70.8 [13] Jonathan Bootle, Andrea Cerulli, Pyrros Chaidos, Essam Ghadafi, Jens
100 57.2 133.8 Groth, and Christophe Petit. Short accountable ring signatures based on
DDH. In ESORICS, pages 243–265, 2015.
[14] Benedikt Bünz, Shashank Agrawal, Mahdi Zamani, and Dan Boneh.
It is seen that the ratio of enforced bill collection to refund is Zether: Towards privacy in a smart contract world. In Financial
the same as in Table III (the pessimistic case is regarded as Cryptography and Data Security, pages 423–443, 2020.
[15] Benedikt Bünz, Jonathan Bootle, Dan Boneh, Andrew Poelstra, Pieter
the enforced bill collection case). In Optiswap, each user is Wuille, and Gregory Maxwell. Bulletproofs: Short proofs for confiden-
essentially regarded as a buyer and the service provider and bill tial transactions and more. In IEEE Symposium on Security and Privacy,
collector are regarded as sellers. Under the proposed system, pages 315–334, 2018.
no gas cost is required for users. Because it is assumed that [16] Jan Camenisch and Jens Groth. Group signatures: Better efficiency and
new theoretical aspects. In Security in Communication Networks, pages
the bill collector will pay the gas costs for setting a user’s 120–133. Springer, 2004.
deposit into the contract, for fairness we calculated the total [17] Jan Camenisch, Jean-Marc Piveteau, and Markus Stadler. An efficient
costs of the seller and buyer. It is seen from the results that the fair payment system. In ACM CCS, pages 88–94. ACM, 1996.
[18] Matteo Campanelli, Rosario Gennaro, Steven Goldfeder, and Luca
proposed system is more efficient than OptiSwap, leading us Nizzardo. Zero-knowledge contingent payments revisited: Attacks and
to conclude that assuming that the service is always provided payments for services. In ACM CCS, pages 229–243, 2017.
to the user is effective in reducing gas costs. [19] Panagiotis Chatzigiannis, Foteini Baldimtsi, and Konstantinos Chalkias.
SoK: Auditability and accountability in distributed payment systems. In
V. C ONCLUSION AND F UTURE W ORK Applied Cryptography and Network Security, pages 311–337, 2021.
[20] David Chaum and Eugène van Heyst. Group signatures. In EURO-
In this paper, we proposed a privacy-preserving enforced CRYPT, pages 257–265, 1991.
bill collection system that supports a functionality for forcibly [21] Yu Chen, Xuecheng Ma, Cong Tang, and Man Ho Au. PGC: decentral-
collecting service fees from users. The proposed system is ized confidential payment system with auditability. In ESORICS, pages
591–610, 2020.
based on the use of accountable ring signatures and smart [22] Ivan Damgård. On Σ-protocols. https://www.cs.au.dk/∼ivan/Sigma.pdf,
contracts. 2010.
In future work, it would be interesting to enhance our system [23] Ivan Damgård, Chaya Ganesh, Hamidreza Khoshakhlagh, Claudio Or-
landi, and Luisa Siniscalchi. Balancing privacy and accountability in
in terms of privacy by, for example, providing membership blockchain identity management. In CT-RSA, pages 552–576, 2021.
privacy using the fully dynamic group signature scheme de- [24] Stefan Dziembowski, Lisa Eckey, and Sebastian Faust. FairSwap: How
veloped by Backes et al. [7]. It would also be interesting to to fairly exchange digital goods. In ACM CCS, pages 967–984, 2018.
develop a bill collection method in which the service fee is [25] Lisa Eckey, Sebastian Faust, and Benjamin Schlosser. OptiSwap: Fast
optimistic fair exchange. In ASIACCS, pages 543–557, 2020.
collected from users without identifying them, for example, [26] Keita Emura and Takuya Hayashi. A revocable group signature scheme
through the use of anonymous cryptoassets such as Monero [2] with scalability from simple assumptions. IEICE Trans. Fundam.
or Zcash [4]. Electron. Commun. Comput. Sci., 103-A(1):125–140, 2020.
[27] Prastudy Fauzi, Sarah Meiklejohn, Rebekah Mercer, and Claudio Or-
Acknowledgment: This work was supported by JSPS KAK- landi. Quisquis: A new design for anonymous cryptocurrencies. In
ASIACRYPT, pages 649–678, 2019.
ENHI Grant Numbers JP19H04107 and JP21K11897.
[28] Ai Ishida, Yusuke Sakai, Keita Emura, Goichiro Hanaoka, and Keisuke
Tanaka. Fully anonymous group signature with verifier-local revocation.
R EFERENCES In Security and Cryptography for Networks, pages 23–42, 2018.
[1] ethereumjs-util. 7.0.7, 2020-10-15, https://github.com/ethereumjs/ [29] Toshiyuki Isshiki, Kengo Mori, Kazue Sako, Isamu Teranishi, and Shoko
ethereumjs-util. Yonezawa. Using group signatures for identity management and its
[2] Monero. https://getmonero.org. implementation. In ACM Digital Identity Management, pages 73–78,
[3] Testnet Ropsten (ETH) blockchain explorer. https://ropsten.etherscan.io/. 2006.
[4] Zcash. https://z.cash/. [30] Ahmed E. Kosba, Andrew Miller, Elaine Shi, Zikai Wen, and Charalam-
[5] Nuttapong Attrapadung, Keita Emura, Goichiro Hanaoka, and Yusuke pos Papamanthou. Hawk: The blockchain model of cryptography and
Sakai. A revocable group signature scheme from identity-based revo- privacy-preserving smart contracts. In IEEE Symposium on Security and
cation techniques: Achieving constant-size revocation list. In Applied Privacy, pages 839–858, 2016.
Cryptography and Network Security, pages 419–437, 2014. [31] Vireshwar Kumar, He Li, Jung-Min ”Jerry” Park, Kaigui Bian, and
[6] Nicola Atzei, Massimo Bartoletti, Tiziana Cimoli, Stefano Lande, and Yaling Yang. Group signatures with probabilistic revocation: A
Roberto Zunino. SoK: Unraveling bitcoin smart contracts. In POST, computationally-scalable approach for providing privacy-preserving au-
pages 217–242, 2018. thentication. In ACM CCS, pages 1334–1345, 2015.

59

Authorized licensed use limited to: Synopsys. Downloaded on November 25,2021 at 11:06:09 UTC from IEEE Xplore. Restrictions apply.
[32] Adeline Langlois, San Ling, Khoa Nguyen, and Huaxiong Wang.
Lattice-based group signature scheme with verifier-local revocation. In
Public-Key Cryptography, pages 345–361, 2014.
[33] Benoı̂t Libert, Thomas Peters, and Moti Yung. Group signatures with
almost-for-free revocation. In CRYPTO, pages 571–589, 2012.
[34] Benoı̂t Libert, Thomas Peters, and Moti Yung. Scalable group signatures
with revocation. In EUROCRYPT, pages 609–627, 2012.
[35] San Ling, Khoa Nguyen, Huaxiong Wang, and Yanhong Xu. Lattice-
based group signatures: Achieving full dynamicity (and deniability) with
ease. Theor. Comput. Sci., 783:71–94, 2019.
[36] Jian Liu, Wenting Li, Ghassan O. Karame, and N. Asokan. Toward
fairness of cryptocurrency payments. IEEE Secur. Priv., 16(3):81–89,
2018.
[37] Joseph K. Liu, Victor K. Wei, and Duncan S. Wong. Linkable
spontaneous anonymous group signature for ad hoc groups (extended
abstract). In ACISP, pages 325–335, 2004.
[38] Toru Nakanishi and Nobuo Funabiki. Verifier-local revocation group
signature schemes with backward unlinkability from bilinear maps. In
ASIACRYPT, pages 533–548, 2005.
[39] Kazuma Ohara, Keita Emura, Goichiro Hanaoka, Ai Ishida, Kazuo Ohta,
and Yusuke Sakai. Shortening the Libert-Peters-Yung revocable group
signature scheme by using the random oracle methodology. IEICE Trans.
Fundam. Electron. Commun. Comput. Sci., 102-A(9):1101–1117, 2019.
[40] Ronald L. Rivest, Adi Shamir, and Yael Tauman. How to leak a secret.
In ASIACRYPT, pages 552–565, 2001.
[41] Shahidatul Sadiah and Toru Nakanishi. Revocable group signatures
with compact revocation list using vector commitments. IEICE Trans.
Fundam. Electron. Commun. Comput. Sci., 100-A(8):1672–1682, 2017.
[42] Yusuke Sakai, Jacob C. N. Schuldt, Keita Emura, Goichiro Hanaoka, and
Kazuo Ohta. On the security of dynamic group signatures: Preventing
signature hijacking. In Public Key Cryptography, pages 715–732, 2012.
[43] Teppei Sato, Keita Emura, Tomoki Fujitani, and Kazumasa Omote. An
anonymous trust-marking scheme on blockchain systems. In IEEE
International Conference on Blockchain and Cryptocurrency, ICBC,
pages 1–3, 2021.
[44] Yasuyuki Seita and Toru Nakanishi. Speeding up revocable group
signature with compact revocation list using vector commitments. IEICE
Trans. Fundam. Electron. Commun. Comput. Sci., 102-A(12):1676–
1687, 2019.
[45] Cheng Shi and Kazuki Yoneyama. Formal verification of fair exchange
based on bitcoin smart contracts. In INDOCRYPT, pages 89–106, 2020.
[46] Riccardo Spagni. Monero 0.13.0 “Beryllium Bullet” release.
https://web.getmonero.org/tr/2018/10/11/monero-0.13.0-released.html.
Accessed : 2018-10-11.
[47] Shifeng Sun, Man Ho Au, Joseph K. Liu, and Tsz Hon Yuen. RingCT
2.0: A compact accumulator-based (linkable ring signature) protocol for
blockchain cryptocurrency Monero. In ESORICS, pages 456–474, 2017.
[48] Eric Wagner, Achim Völker, Frederik Fuhrmann, Roman Matzutt, and
Klaus Wehrle. Dispute resolution for smart contract-based two-party
protocols. In IEEE ICBC, pages 422–430, 2019.
[49] G. Wood. Ethereum: A secure decentralised generalised transaction
ledger (eip-150 revision), 2017. https://gavwood.com/paper.pdf.
[50] Shouhuai Xu and Moti Yung. Accountable ring signatures: A smart card
approach. In CARDIS, pages 271–286, 2004.
[51] Yue Zhang, Jian Weng, Jia-Si Weng, Ming Li, and Weiqi Luo. Onion-
chain: Towards balancing privacy and traceability of blockchain-based
applications. CoRR, abs/1909.03367, 2019.

60

Authorized licensed use limited to: Synopsys. Downloaded on November 25,2021 at 11:06:09 UTC from IEEE Xplore. Restrictions apply.