VeloCash: Anonymous Decentralized Probabilistic Micropayments With Transferability

Micropayments are one of the challenges in cryptocurrencies. Micropayments on the blockchain have the problem that the fee is high for the transfer amount. As a countermeasure, a method called Layer-two has been proposed to consolidate transactions outside the blockchain and improve the blockchain’s throughput. As one of the existing Layer-two schemes, Decentralized Probabilistic Micropayments have been proposed. The winning amount is registered in the blockchain, and the lottery tickets are issued to be won with probability <inline-formula> <tex-math notation="LaTeX">$p$ </tex-math></inline-formula>, which allows us to aggregate approximately <inline-formula> <tex-math notation="LaTeX">$(1/p)$ </tex-math></inline-formula> transactions into one. Unfortunately, existing solutions do not allow for ticket transferability, and the smaller <inline-formula> <tex-math notation="LaTeX">$p$ </tex-math></inline-formula>, the more difficult it is to use them in the real world. Here we propose <inline-formula> <tex-math notation="LaTeX">$\textsf {VeloCash}$ </tex-math></inline-formula>, Decentralized Probabilistic Micropayments with Transferability, which preserves anonymity. By introducing tamper-proof assumptions for sending and receiving the tickets, we make <inline-formula> <tex-math notation="LaTeX">$p$ </tex-math></inline-formula> smaller. As a tamper-proof hardware assumption, <inline-formula> <tex-math notation="LaTeX">$\textsf {VeloCash}$ </tex-math></inline-formula> uses Attested Execution Secure Processors, a formal abstraction of secure processors with attested execution functionality and Direct Anonymous Attestation to achieve anonymity for sending and receiving tickets. <inline-formula> <tex-math notation="LaTeX">$\textsf {VeloCash}$ </tex-math></inline-formula> can detect double-spending attacks perfectly and revoke the adversary’s device.

Instead of registering all transactions in the blockchain, 32 The associate editor coordinating the review of this manuscript and approving it for publication was Chien-Ming Chen .
Layer-two aggregates small transactions into a few larger 33 ones, increasing transaction throughput and reducing trans-34 action fees. Decentralized probabilistic micropayments [1], 35 [3] have been proposed as one of the methods for Layer-36 two. It is a lottery-based scheme, the amount of required 37 payments is locked in an escrow, and micropayments are 38 issued as lottery tickets. Let the winning amount be β, and 39 the winning probability is p, the expected value per lottery 40 ticket is p · β, and the ticket is used as currency. Probabilistic 41 micropayments allow us to aggregate the entire transactions 42 by approximately p. For example, if 10, 000 transactions are 43 processed by a probabilistic micropayments scheme, only 44 10, 000 · p transactions will be registered in the blockchain. 45 Almashaqbeh et al. have proposed MicroCash [3] which 46 is a lightweight protocol for non-interactive and sequential 47 payments. The disadvantage of MicroCash is that the game 48 theory guarantees safety against double-spending attacks. 49 Thus, the amount of money for the escrow account, which 50 is confiscated when a double-spending attack is discov-51 ered, is considerable. As an example, when m = 5 and 52 of tickets will be published on the blockchain. Hence its 109 anonymity is equivalent to Bitcoin as far as addresses are not 110 reused. 111 A. CONTRIBUTION 112 In this paper, we have achieved stronger notions of anonymity 113 on the previous work of Takahashi and Otsuka [1]. The main 114 contributions of this paper are the followings: 115 1) Extended anonymity notions for blockchain-based 116 decentralized transferable payment schemes: 117 All of the previous anonymity notions [4], [5] assume 118 the existence of the bank as the central authority. Thus, 119 applying those anonymity notions to the blockchain-120 based decentralized payment schemes is not straight-121 forward. In this paper, we introduced the general-122 ized anonymity notions of transferred electronic cash 123 schemes to cover both centralized and decentralized 124 payment schemes.

127
Attested Execution Secure Processors (AESP) [6] is the 128 abstraction of tamper-proof secure processors, which 129 enforces every installed program to attach an attested 130 signature as proof to show that the output is the 131 result of the execution of the program. In this paper, 132 we proposed a new mechanism to revoke tampered 133 AESP's utilizing the idea of key extractor when double-134 spending is detected. In order not to be too abstracted, 135 our key extractor is defined over Enhanced Privacy 136 Identifier (EPID) [7]. Still, our technique can be 137 applied to any Direct Anonymous Attestation (DAA) 138 scheme [8] with Fiat-Shamir proof of knowledge for 139 NP relation.

140
3) Secure construction of probabilistic anonymous pay-141 ments with transferability: 142 We propose VeloCash, an anonymous probabilis-143 tic micropayment scheme with transferability. The 144 construction satisfies all the security and anonymity 145 notions claimed in the theorems.
TumbleBit, allowing anonymous transfer of coins from Bob 217 to a third party Charlie. 218 Both [14], [15] realize the anonymous coin spending 219 through an intermediary. Their schemes require setting up 220 an online intermediary for each spending, possibly increasing 221 the transaction fee, which is unsuitable for micropayments. 222 D. E-CASH 223 If lottery tickets are used as currency, it is desirable to have 224 anonymity as physical currency has. Several schemes for 225 anonymous transfer have been proposed earlier. However, 226 some problems were pointed out, such as the existence of 227 the trusted party. Recently, Foteini Baldimtsi et al. pro-228 posed a new anonymous transferable scheme, Transferable 229 E-cash [16]. It makes it possible to create a fully anony-230 mous transferable electronic cash scheme without trusted 231 third parties with malleable signatures to construct their 232 secure and anonymous transfer of coins. However, the Trans-233 ferable E-cash scheme has the drawbacks such as effi-234 ciency pointed out by Bauer et al. [5]. In the work [5] they 235 revisited and proposed the definition of the security and 236 anonymity properties, which Transferable E-cash systems 237 should satisfy -(1) unforgeability: an adversarial user cannot 238 spend more e-coins than he withdrew, and (2) anonymity: 239 nobody can link spending transactions to each other or to spe-240 cific withdrawal transactions. Their definition of anonymity 241 consists of three parts -(1) coin anonymity, (2) user 242 anonymity and (3) coin transparency. 244 As in [1], the transferable payment scheme is realized 245 using tamper-proof devices. In this study, which realizes 246 the anonymity of the transferable payment scheme, we also 247 assume tamper-proof devices. More specifically, we use 248 Attested Execution Secure Processors (AESP), that abstracts 249 ''attested execution'' secure processors. In the ''attested exe-250 cution'' of AESP, the output of the installed program is 251 digitally signed with the secret key in the AESP. The signature 252 enables verification that the output is indeed from a legitimate 253 AESP. 254 Direct Anonymous Attestation (DAA) has been used for 255 the attested signature. DAA can be seen as group signa-256 tures [17] but differs from group signatures in that DAA does 257 not have an opening algorithm that allows the group manager 258 to obtain the identity of the signer from the signature. Instead 259 of having opening function, DAA has a so-called ''revocation 260 function''. Suppose a particular hardware module has been 261 broken and its secret key has been compromised; the secret 262 key is placed on the revocation list. When a verifier receives 263 the signature, he can verify whether it is signed with the secret 264 key on the revocation list. 265 In this study, we use AESP to send and receive tickets, and 266 DAA is used for attested signatures and for sending tickets. 267 There are three reasons to adopt DAA: 1) For anonymization 268 of attested signature. 2) To extract the adversary's secret if 269 the double-spending attacks are performed 3) To revoke the 270 VOLUME 10, 2022 extracted adversary's secret key. In particular, extracting and 271 revoking the adversary's secret key is a strong motivation 272 for adopting DAA. We adopt Enhanced Privacy ID (EPID), 273 a DAA scheme that uses Fiat-Shamir proof of knowledge for 274 NP relation. Thus, since the Extractor can be configured, it is 275 possible to extract and revoke the adversary's secret key from 276 the double-spending tickets with the same commitment but 277 different challenges. 278 A possible alternative to anonymization other than DAA 279 is using ring signatures. Traceable ring signatures [18], [19] 280 limit the number of times a secret key can sign transac-281 tions, making it possible to detect double-spending attacks. scheme for trusted hardware module has been proposed by 289 Brickell et al. [8]. DAA has been adopted by the Trusted 290 Computing Group (TCG). 291 There are multiple DAA schemes have been proposed [20], 292 [21], [22], [23], [24]. In this paper, we adopt the EPID technology [26], [27]. 303

304
EPID is one of the DAA schemes which preserves anonymity 305 proposed by Brickell and Li [7], [25]. There are two types 306 of revocation in EPID, the secret key based revocation, and 1 In the original definition by Brickwell and Li [7], [25], platforms are the secure hardware-based signing entities such as SGX in Intel processors. Pass et al. [6] refers to the signing entities to produce attested signatures as ideal functionality G att , and they used the term 'platform' for the entities who is allowed to invoke functionalities in G att .

2) SECURITY DEFINITION OF EPID 319
An EPID scheme is secure if it satisfies the following three 320 requirements: correctness, anonymity, unforgeability [7], [8]. 321 The correctness requires that every signature a platform 322 generates is valid except when the platform is revoked by the 323 secret key based revocation or the signature based revocation. 324 Theorem 1 (Theorem 4 of [28]): The EPID scheme is 325 correct. 326 The EPID scheme is anonymous if the adversary can not 327 determine from the signature the secret key used to generate 328 the signature.

329
Theorem 2 (Theorem 5 of [28]): An EPID scheme is 330 anonymous in the random oracle model under the decisional 331 Diffie-Hellman assumption in G 3 .

332
The EPID scheme is unforgeable if the adversary can not 333 forge a valid signature with all secret keys known to the 334 adversary that has been revoked.

338
See Appendix C for more detailed definitions and 339 Appendix B for the construction of EPID.

IV. PROBABILISTIC TRANSFERABLE PAYMENT SCHEMES 341
A. PROBABILISTIC TRANSFER SCHEME

342
The probabilistic transferable payment scheme [1] uses 343 the lottery-based mechanism to enable micropayments. The 344 ticket issuer creates an escrow account with the winning 345 amount and registers it on the blockchain. Then, the ticket 346 is issued based on the escrow account and distributed among 347 users. The users who receive a ticket that meets the winning 348 condition can receive the winning amount.

349
All tickets are sent and received via a tamper-proof device 350 wallet, and tickets are sent using the digital signature key in 351 the wallet. Since the tamper-proof device is used, double-352 spending attacks would not be performed. However, in reality, 353 tamper-proof devices can be broken, and double-spending 354 attacks can be performed. Thus, Takahashi and Otsuka [1] 355 proposed two detection methods that can completely detect 356 double-spending attacks and place an upper bound on the 357 expected value of the attack when the tamper-proof devices 358 are broken. 359 We denote by σ A a signature signed by A. For readability, we write a ticket τ as: (3) 367 Let A and B both be the receiving addresses. Also, X is 368 the signature of the sender A, which indicates the signer's 369 identity. 370 We define |τ | the ''number of generations'' of τ , which is 371 the length of the sequence from to τ . For example, |τ | = n 372 if there exists a sequence τ 1 , . . . , τ n−1 such that τ ≺ τ 1 ≺ 373 τ 2 ≺ · · · ≺ τ n−1 ≺ τ . We define |τ | = ∞ if no such 374 sequence exists. 2 To write compactly, we denote by τ i the i-th 375 generation of τ .

376
Definition 2 (Transferred Transaction): Two tickets τ i = 377 A → B, τ pre X and τ i+1 = A → B , τ pre X are said to be 378 transferred if and only if following properties satisfies: Then, we write τ i ≺ τ i+1 . 381 We write τ i ≺ ≺ τ i+n if there exists a sequence of ordered 382 lottery tickets τ 1 ≺ . . . ≺ τ n for n ≥ 1 and they satisfy τ i ≺ τ 1 383 and τ n ≺ τ i+n . If τ has no previous lottery tickets, the ticket 384 is called a ''genesis'' ticket. For the genesis tickets τ 1 tied to 385 an escrow account , we specially denote by ≺ τ 1 so that 386 lottery tickets are simply written as: Garay et al. [29].

396
To specify the parameters of the transferable transaction, 397 the escrow account further contains: where β is the ticket winning amount, p is the probability for 400 determining winning a ticket, q is the lottery ticket transaction 401 rate of proportional fee scheme, 3 and µ is a fixed value used 402 to determine the winning ticket. 403 We define an escrow as active when the ticket generated 404 from the escrow has been distributed.

412
2 For practical purposes, we assume that the height of τ can only be measured when all tickets in the sequence from τ to τ are given. Even if such a sequence exists, the height of τ is considered to be ∞ unless the entire sequence is specifically presented.
3 See Appendix D.

413
This section describes the design of the ticket winnings.

414
Definition 5: τ v is said to be win if and only if the following 415 properties satisfy: where v is the number of generations of τ , h 0 is the block 418 height containing the escrow account and µ is the fixed 419 number specified in the escrow account . 420 The probability p is calculated using a simple Verifiable 421 Delay Function (VDF) [30]. The calculation can be done after 422 a certain period of time has elapsed from when the ticket 423 is transferred according to the number of generations. For 424 example, if a ticket with h 0 = 100, µ = 5 and v = 3 is 425 received, the VDF value will be known when the block height 426 of 115 is confirmed.

427
If the ticket τ ∈ win has already been sent and the owner-428 ship has been transferred, the user with the latest ownership 429 is considered eligible and can get the winning amount β.

430
Definition 6: τ v is said to be eligible if and only if the 431 following properties satisfies: 10) 433 eligible ticket will be considered as the final winning 434 ticket. Thus, the user who has the eligible ticket can get β 435 from the escrow account . 2) PROPORTIONAL FEE SCHEME 437 Proportional Fee Scheme is a payment scheme first intro-438 duced by Takahashi and Otsuka [1]. This scheme is where 439 each time a payer transfers a ticket; the payer bears the fee 440 based on the number of generations of the ticket.

441
Definition 7 (Proportional Fee Scheme): Let q be the lot-442 tery ticket transaction fee rate. Suppose a payer sends a ticket 443 τ i , and the payee gives goods or services worth (1 − q) i β to 444 the sender. The fee borne by each payment is (1 − q) i−1 qβ. 445 This scheme has the advantage that the payment fee can 446 be smaller than the blockchain transaction fee. The aver-447 age transaction fee for cryptocurrencies, especially Bitcoin, 448 is approximate $2 [31]. By contrast, in our transferable 449 scheme, let β = $100, p = 1 100 and q = 1 10 , the fee for a 450 $1 transfer is about 10 cents.

456
The security design requires the adversary to have an 457 expected value obtained from the attack that exceeds the cost 458 by breaking the tamper-proof device.

459
Fork detection is a method that perfectly detects double-460 spending attacks. Fork implies that two tickets are assumed 461 to exist, and the resulting ticket prefixes are identical except 462 for k elements from both ends of the ticket.  where is the cost of breaking κ-tamper proof wallet.

510
See formal definitions and proofs in Appendix D.

512
The results in the preceding section show that the cost of 513 breaking a κ-tamper proof wallet must exceed the expected 514 utility of an adversary. In this section, we follow the formal 515 abstraction of attested execution secure processors [6] with 516 adequate tamper-resistance (whose breaking cost exceeds ). 517 All previously proposed anonymous and transferable elec-518 tronic cash schemes [4], [5], [16], [32], [33] assume that: 519 1) the existence of central authority (bank), and 520 2) only the bank can detect double-spending.

521
Our decentralized blockchain-based transferable payment 522 scheme is described in the previous section; however, every 523 player is eligible to set up an escrow account and initi-524 ate offline transferable payments; hence no central author-525 ity (bank) exists. Further, our collision-detection and fork-526 detection techniques enable every recipient of transferable 527 payments to detect double-spending and publish the evidence 528 on the blockchain. That is, every player can potentially detect 529 double-spending. Finally, to capture the anonymity in these 530 decentralized settings, we will define generalized anonymity 531 notions in the following subsections.

533
A conventional transferable e-cash system generally involves 534 two types of players: a bank B and a user U. Whereas a 535 blockchain-based transferable e-cash system has no banks, 536 a blockchain C takes the role of a bank B. C can be regarded 537 as B that holds no secret information and publishes all of its 538 views and the deposited coin list L.

539
A coin is represented by an identifier id and some values 540 π needed to prove its validity.

541
• ParamGen(1 λ ) is a probabilistic algorithm that outputs 542 the system's parameters param (including the security 543 parameter λ ). We assume all functions take param as 544 their inputs unless otherwise specified.

545
Note: param may contain the genesis block of the 546 blockchain C. For schemes assuming DAA-based 547 anonymous signature schemes with tamper-proof 548 devices, ParamGen generates the DAA public key and 549 secret key pair (gpk, gsk) and param contains gpk for 550 the verification of anonymous signatures.

554
Remark: Blockchain-based transferable e-cash systems 555 have the blockchain C in place of the bank B, and C has 556 no secret information. Thus, BKeyGen(param) outputs 557 nothing such that sk B , pk B = (⊥, ⊥).

558
Remark: For schemes assuming DAA-based anony-559 mous signature schemes with a tamper-proof device, 560 UKeyGen(param) invokes Join(gpk) protocol with the 561 manufacturer who holds gsk, and stores sk i securely in 562 the tamper-proof device within a platform P i . Such sys-563 tems share the group public key gpk, and no individual 564 public key pk i for the platform P i exists. Hence, 565 sk U , pk U = (sk i , ⊥).

566
• Withdraw B sk B , pk B , pk U , U sk U , pk U , pk B is 567 an interactive protocol where U withdraws from B one 568 coin. At the end, U either gets a coin C = (id, π) and 569 outputs OK, or outputs ⊥. The output of B is either its 570 view V W B of the protocol (including pk U ), or ⊥. blockchain C, where is related to the public key pk U 575 and spendable using the secret key sk U .
tive protocol where U j gives a coin to U i . At the end, 578 either U i outputs a coin C = (id C , π C ) or ⊥, and either 579 U i saves that C is a spent coin and outputs OK, or U i 580 outputs ⊥.

582
B sk B , pk B , pk U , L is an interactive protocol where 583 U deposits a coin (id, π) at the bank B. If (id, π) is not 584 consistent/fresh, then B outputs ⊥ 1 . Else, if id already 585 belongs to the list of spent coins L, then there is an 586 entry id, π and B outputs ⊥ 2 , id, π, π . Else, B adds 587 (id, π) to its list L, credits U 's account, and returns L.

588
U 's output is OK or ⊥. then there is an entry (id, π ) and every user U who 599 received (id, π) can output (⊥ 2 , id, π, π ). Else, (id, π) 600 is published on the blockchain C and added to its list of 601 spent coins L. U's output is OK or ⊥.

602
• Identify id, π, π is a deterministic algorithm executed 603 by B that outputs a public key pk U and a proof G . We store all information about users in the user list UL 626 consisting of U i = (pk i , sk i , uds i ) where uds i indicates 627 how many times user U i has performed the double-spending 628 attacks. The set of supplied coins by the oracles is denoted by 629 SC, and the set of all coins owned by the oracles is denoted 630 by OC. The set of deposited coins is denoted by DC.

631
If an error occurs during the execution of the oracles, the 632 oracles output ⊥. Otherwise, the call of the oracles is assumed 633 to have succeeded. The adversary can instruct the creation of honest users or 636 passively observe registration. It can moreover spy on users, 637 meaning that the adversary can learn the user's secret key. 638 Note that the spy can not be performed on the challenge users. 639 • BRegist() plays the bank side of the key generation 640 algorithm BKeyGen and interacts with the adversary. 641 If successful, it adds (pk, ⊥, uds = 0) to UL. The adversary can withdraw a coin from the bank or passively 664 observe a withdrawal. Identify and returns (pk, G ) ← Identify(id, π, π ). Detection methods, which are the core security design of [1], 723 and organize the conditions that must be satisfied.

724
Economic properties ensure that users do not incur eco-725 nomic losses when they participate in the system. It consists 726 of soundness, unforgeability, and exculpability. 727 We define a negligible function negl if for every positive 728 polynomial function p there exists λ 0 ∈ N such that for all 729 λ > λ 0 the following holds: .
Suppose an honest user issues or accepts a ticket during a 733 transfer; he should be guaranteed that others will accept the 734 ticket. In that case, either honest users when transferring or 735 the blockchain escrow account when claiming.

736
The game is formalized in Figure 1. The adversary issues 737 a ticket or sends the received ticket τ to the user i 0 . If the 738 result of sending the ticket to the user i 1 or claiming to the 739 blockchain is false, the adversary wins.
Unforgeability ensures that no user can spend more than 745 the number of tickets received or issued. Unforgeability also 746 guarantees that the adversary address is accused whenever a 747 ticket is double-spending. The game is formalized in Figure 2. 748 Definition 12 (Unforgeability): An anonymous transfer-749 able scheme is unforgeable if for all PPT adversaries A, 750 we have Exculpability ensures that an honest user can not wrongly be 754 accused of double-spending. Exculpability also guarantees 755 that the adversary's address is accused whenever a ticket is 756 double-spending. Specifically, it guarantees that the adver-757 sary can not produce double-spending coins that can output 758    • Perfect anonymity satisfies full anonymity, and the 781 adversary can not decide whether a coin is the one that 782 he has previously owned or not. 2) USER ANONYMITY (u-an) 810 We describe User anonymity game in Figure 5. The adversary 811 issues or receives a ticket and sends it to one of two user 812 VOLUME 10, 2022 groups. Then, the adversary receives the ticket again, which 813 has been passed through between the users, and determines 814 which of two user groups it has passed through.
The experiment is specified in Figure 6. We assume Adv c-tr A, (λ) Note that in this paper, we assume that the winning amount 845 β is equal for all escrow accounts , because if the winning 846 amount β is very high, the winning ticket may not satisfy the 847 anonymity notions. Consider the case where a ticket returns 848 to the same sender again, and the ticket is won. The user can 849 identify the ticket from the amount spent and the number of 850 times the ticket has been transferred.

851
This is a trivial assumption and is a setting to simplify 852 the conditions for achieving anonymity. In Proportional Fee 853 Scheme, there is a concern that the high winning amount 854 causes the speed of payment to be slowed down since the 855 difference between the value of the ticket and the winning 856 amount is large. For example, if the winning amount is 857 $10, 000 and the ticket value is 1 cent, it is not surprising 858 that people would wait for the winning result before using it 859 to pay. For Proportional Fee Scheme to work practically, it is 860 ideal if the winning amount is not very high, i.e., β − γ is 861 negligibly small, where γ is the blockchain transaction fee. 862

D. ATTESTED EXECUTION SECURE PROCESSORS (AESP) 863
Tamper-proof is a property of a secure processor that prevents 864 the leakage of sensitive information such as cryptographic 865 keys and other confidential information against non-invasive 866 attacks such as side-channel attacks and invasive attacks such 867 as reverse engineering. There is no known theoretical imple-868 mentation method. In many practical cases, the hardware 869 is referred to as ''tamper-proof'' that has passed exhaustive 870 penetration tests such as FIPS 140 and AVA_VAN.5 in CC 871 certification (ISO/IEC 15408). 872 Several methods have been proposed in academic and com-873 mercial literature to achieve tamper-proof secure processors, 874 As a de facto standard, it is often referred to as Trusted Exe-875 cution Environment (TEE). TEE allows any program to be 876 executed in secure processors. Furthermore, TEE also has the 877 ''attested execution'' function of verifying that the program's 878 output in the device is from a legitimate tamper-proof device 879 T. Takahashi    2) The installed programs are obfuscated; thus, the adver-885 sary can not obtain any information more than input 886 and output. anonymity is lost if the signer's identity is known. Anony-896 mous cryptographic technology that can not determine from 897 which device the signature came is called ''Anonymous 898 Attestation''.

899
Realizing anonymous attestation is achieved using a dig-900 ital signature scheme called Direct Anonymous Attestation 901 (DAA), similar to group signatures. DAA differs from group 902 signatures in that it has strong anonymity, in that even the 903 group manager can not identify which key was used to create 904 the signature.  The structure of AESP is shown in Figure 7,8. Pass et al. 910 have proposed an ideal function G att that abstractly captures 911 the essence of the wide range of attested execution proces-912 sors. The most naive abstraction of G att has a public key 913 and a secret key pair (gpk, msk) for signing embedded by a 914 manufacturer. By sharing the same secret keys among all G att , 915 no one can distinguish the issuer of the attested signatures.

916
The signature on message m with the signing key is denoted 917 as .Sign sk (idx, eid, prog, m; r).

918
G att has four interfaces as follows: Generates the key pair (mpk, msk) to be used 921 for attested execution and initializes the internal 922 memory T . Register a program prog in G att and allocate unique 928 memory space mem for the program. Enclave instance 929 is a pair of (idx, prog, mem) for idx, which is the 930 session ID when prog is registered. eid is the identifier 931 of the enclave instance and is recorded in T for each 932 platform P.  When G att is executed, the output outp is always signed 938 with the embedded signing key msk. Based on the output and 939 the signature, a verifier can verify that the output is sent from 940 a secure processor G att .

942
We propose the following extension to the original AESP to 943 revoke malicious platforms. We assume that AESP utilizes 944 any direct anonymous attestation (DAA) schemes with  Shamir proof of knowledge for NP relation. The idea is 946 the following: When a platform P receives a transaction, 947 we force P to commit to a set of one-time randomness 948 Then, prog w encrypts the above plain-text and the signa-986 ture, and G att applies an EPID signature on it and sends the 987 following items to the payee's AESP.

990
The plain text and the EPID signature on it that will even-991 tually appear on the blockchain will be encrypted between

992
AESPs so that nobody can track the history of transmission 993 from outside the AESP. 994

995
In the original definition of AESP, at the end of the process of 996 resume, a signature is performed that makes it verifiable that 997 the output is from AESP. The signature input value consists 998 of (idx, eid, prog, outp).

999
In VeloCash, we make the input values idx and eid be 1000 specified in a hash of the prog.

1001
When the ticket is sent, idx and eid can be seen in 1002 rich environments. In the payment protocol described later, 1003 when a ticket is won, all transaction information, including 1004 past transactions, is registered in the blockchain, including 1005 the signatures. Since the winning ticket is registered in the 1006 blockchain, including idx and eid, it does not satisfy the coin 1007 transparency of the anonymity notion. By fixing idx and eid 1008 as the hash values of prog, it makes it impossible to identify 1009 from which AESP the ticket was sent.

1010
Fixing eid means single instantiation of prog. For prog 1011 to send and receive tickets, it only needs to be able to store 1012 previously received tickets and information associated with 1013 the tickets. Since the memory corresponding to prog can store 1014 the states, single instantiation does not affect sending and 1015 receiving.

1017
In VeloCash, we would like to have a mechanism to revoke 1018 an adversary if he performs a double-spending attack. For 1019 revocation, we use the EPID revocation function.

1020
In this paper, we do not use the EPID's signature based 1021 revocation. From the signature based revocation, the value to 1022 be registered in the revocation list is B, K (= B f ) where f 1023 is the secret key. In VeloCash, the signer takes a different 1024 value for B for each signature. Therefore, the signature based 1025 revocation list can not revoke the adversary. 1026 Instead, we adopt the secret key based revocation. Once 1027 the adversary performs a double-spending attack, we make 1028 the secret key f extractable and put the f into the secret key 1029 revocation list. 1030 We define Key Extractor, which is an extractor for extract-1031 ing secret keys in non-interactive zero-knowledge proof using 1032     relation R λ as follows: 1068 By solving the above equations, the witness (x, f , a, b) is 1069 extracted as follows: 1070 This section introduces the protocol VC of VeloCash. The 1088 general framework of the protocol is the same as Taka-1089 hashi and Otsuka [1]; however, it includes a mechanism to 1090 anonymise the sending and receiving of tickets.

1091
The protocol VC consists of three phases: 1) Escrow 1092 Setup, 2) Payment with Lottery Ticket, and 3) Ticket Winning 1093 and Publication. The EPID's secret key based revocation list Priv-RL and 1096 signature based revocation list Sig-RL referenced among all 1097 user's AEPS shall be distributed in a blockchain and globally 1098 referenceable.

1099
In the construction section, we have omitted the verifica-1100 tion method of blockchain data performed by AESP. In each 1101 phase, AESP must efficiently verify that the escrow is actu-1102 ally registered in the blockchain and that there are no winners 1103 already by referring to the blockchain data provided by the 1104 wallet owner.

1105
To achieve the verification, we can use the notion of Proof 1106 of Publication for PoW blockchains from [38], [39], which 1107 allows AESP to verify that a blockchain transaction is valid 1108 from the blockchain fragment received from the wallet owner. 1109 In summary, it is an extension of standard transaction 1110 confirmation of the Proof-of-Work blockchain. More specif-1111 ically, an AESP receives n blocks n-T = {B i , · · · , B i+n } and 1112 evaluates whether the time to produce the blocks is less than 1113 the specified security parameter, as follows: where t i and t i+n are time stamps extracted from blocks B i 1116 and B i+n respectively, and δ is a security parameter. where gpk = (p, G 1 , G 2 , G 3 , g 1 , g 2 , g 3 , h 1 , h 2 , w = g γ 2 ) and 1127 gsk = γ . G 1 , G 2 , G 3 are groups of order p. g 1 , h 1 , h 2 ∈ G 1 , 1128 g 2 ∈ G 2 , and g 3 ∈ G 3 . It outputs param = {gpk}.      It outputs ( , ⊥) as a ticket (id, π).
We only take id, π, sk U i as inputs, and neglect pk U i , pk B 1179 and treat them as (⊥, ⊥). First, to establish a secure 1180 channel, U j randomly choose sid and a, and sends g a 1181 and the attested signature σ j to U i by sending a message 1182 resume(sid, eid, ''init keyex'') to G attj . U i generates 1183 his temporary receiving address addr i from the random-1184 ness identifier rid and randomly choose b, and encrypts it 1185 with the shared secret key K = (g a ) b and obtains addr i , 1186 and sends addr i and g b to P j by sending a message 1187 resume(eid, (''get addr'', sid, g a , σ j )) to G attj . Next, prog w of P j creates a transaction and calls 1192 G attj .sign(τ n+1 ; rid) and obtains the signature σ j on 1193 (sid, eid, prog w , τ n+1 ). The transaction consists as follows: 1194 Note that the rid specified here must be the same rid 1198 used to output the receiving address when receiving the 1199 ticket. P j sends the encrypted address addr j returned from 1200 resume(eid, (''get addr'', sid, g a , σ j )) call to his G attj 1201 when he received the ticket. Since addr and rid are recorded 1202 within prog w , the rid used when receiving the ticket can be 1203 reused when sending.

1207
It outputs OK, τ * 1208 The message flow of the above process is complex. See 1209 Figure 10 for actual operations between G att and prog w .
We only take id, π, sk U as inputs, and neglect pk U , sk B , pk B 1212 and treat them as (⊥, ⊥). P send his crypto address pk to 1213 receive the winning money and the ticket receiving address 1214 addr by sending a message 1215 resume(sid, eid, (''check winning'', pk, addr)) 1216 to G att . If the ticket satisfies the winning condition, prog w cre-1217 ates a blockchain transaction τ := (addr → pk, Hash(τ pre )) 1218 and sends it with the attested signature.

1219
It outputs OK, τ * 1220 The message flow of the above process is complex. See 1221 Figure 11 for actual operations between G att and prog w . 1222 VOLUME 10, 2022  and G = Priv-RL = {f 1 , f 2 , · · · , f n }. It outputs 1 iff  Step 1: The ticket issuer issues a smart contract escrow 1260 account and confirms that has been registered in the 1261 blockchain.
Step 2: The payee sends the ticket τ to a payee.

1262
The payee verifies that the ticket came from a legitimate 1263 wallet and that the escrow account is registered correctly in 1264 the blockchain. If there is no problem, the payee receives the 1265 ticket and returns the service or product to the payer. Then, the 1266 payee signs the ticket with his wallet and sends it to another 1267 user.
Step 3: If the ticket received meets the requirements for 1268 lottery winning, The ticket owner can use the ticket to send 1269 the winning amount to their address. 1270 1) ESCROW SETUP 1271 Figure 9 shows the flow diagram. This process is part of 1272 Withdraw. It executes a deposit transaction τ l on the output 1273 and registers τ l to the blockchain network B. The issuer's 1274 wallet W X requests an escrow account from G att . After 1275 the wallet obtains from G att , W X creates a transaction τ l 1276 that transfer the winning amount β to and sends it to the 1277 blockchain network.  Figure 10 shows the flow diagram which shows sending a 1280 ticket from X to Y . Suppose that the X 's wallet has a ticket τ n 1281 and generates τ n+1 or generates τ 1 from the escrow account . 1282 First, the sender X 's wallet W X resumes ''init keyex'' 1283 to perform Diffie-Hellman key exchange with the payer Y , 1284 and requests invoice to Y 's wallet W Y . G att in W Y generates 1285 the receiving address and encrypts it with the DH shared 1286 secret key, then sends it to W X .

1287
Second, W X processes ticket transfers to the address sent 1288 by W Y . W X passes to G att the address received from W Y and 1289 the encrypted address addr X used to receive the ticket or 1290 create an escrow account in the past.

1292
When the ticket satisfies the winning condition, the ticket 1293 owner sends the winning ticket to the blockchain network. 1294 See Figure 11. 1295 The ticket owner sends his address pk Y and the encrypted 1296 address used to receive the ticket to G att . Inside G att , G att 1297 creates and returns the transaction to transfer to the address 1298 sent by the ticket owner. Then, the ticket owner receives the 1299 transaction and sends it to the blockchain network.

1300
If the winning ticket is a double-spending one, the adver-1301 sary's secret key is extracted by Fork and collision detection. 1302

1303
In this section, we analyze whether VeloCash satisfies eco-1304 nomic and anonymity properties. 1305 Finally, we analyze whether the proportional fee scheme 1306 and double-spending attacks detection methods, a require-1307 ment of the transferable micropayment scheme, can be 1308 achieved even if the anonymity is preserved. 1309 We construct the theorems under the following assump-1310 tions. First, we assume that the tamper-proof hardware wallet 1311 and the collision-resistant hash function exist. attacks. Thus, to win the game, the adversary has to forge 1345 the EPID secret key and creates a ticket with a valid EPID 1346 signature. However, since the probability of forging an EPID 1347 signature is negligible small from the EPID's unforgeability 1348 in the Theorem 3, A 1 refuses to receive it.

1349
If the adversary can break his tamper-proof wallet, the 1350 adversary will perform double-spending attacks. Suppose the 1351 adversary performs double-spending attacks on A 1 and other 1352 users, and the attack is detected. In that case, this must 1353 be a case where the adversary's secret key is registered in 1354 Priv-RL, and A 2 refuses payment from A 1 . Soundness is 1355 broken if sk A / ∈ Priv-RL when A 1 receives the ticket from 1356 A, but sk A ∈ Priv-RL when A 2 received the ticket from A 1 . 1357 However, for an adversary to gain sufficient economic benefit 1358 from a double-spending attack, a large number of double-1359 spending would be required. From Theorem 4, there exists 1360 an upper bound on the expected utility of the attack. For 1361 users who receive double-spending tickets, it is possible to 1362 compensate for the loss by setting an appropriate issuance. 1363 See the details in [1].

1364
The temporal collapse of soundness is a universal issue 1365 that also exists in E-Cash due to the timing gap between the 1366 execution of the attack and disabling the adversary. (λ) if he succeeds in creating a new valid ticket 1374 (id, π) which is not included in the supplied coin list SC 1375 or to create multiple proofs π, π for the same ticket id, id, 1376 which is included in SC, to get (id, π, π ) but never identified 1377 VOLUME 10, 2022 as a double-spender by the Identify(id, π, π ) algorithm.

1378
The former case corresponds to the existential unforgeability 1379 property of EPID in VeloCash VC . We focus on the latter 1380 case, which is further divided into three cases:   This must be the case that the adversary succeeded in forg-1417 ing the EPID secret key f . Since the EPID's unforgeability 1418 property, the probability of succeeding is negligibly small in 1419 the security parameter λ. 1420 Next, consider the case where the different 1421 sk A (= f ) is extracted in Equation (36), that is, the 1422 VOLUME 10, 2022 same two com (= (R 1 , R 2 )) are created with different secret key f .

1424
The following lemma states that, once VerifyGuilt 1425 outputs 1 on input one of the signature (id i , π i ) with G for 1426 some honest user i, then it outputs 1 for the other signatures 1427 (id * i , π * i ) with G of the same user i.
tures of a user i. Then, for all honest user i ∈ UL and for all 1430 signature (id * i , π * i ) generated by i, the following holds: A is the adversary's EPID signature on the message 1509 A is the adversary's EPID signature on the 1510 ciphertext AE.Enc K (·) 0 (·, ·). → i (1) 0 , σ A , 1516 93720 VOLUME 10, 2022 (47)

1517
The adversary can infer two partial messages as follows: such that whose signature parts are hidden from the adversary.
where b ∈ {0, 1}. Then, the challenge user returns the follow-1550 ing tickets to the adversary.
The adversary can infer two partial messages as follows: 1555 such that whose signature parts are hidden from the adversary.

1556
Similar to the coin anonymity game, it is easy to see that the (53) 1579 Next, the adversary sends to user i Then, the challenge user returns the following ticket to the 1590 adversary.  Once the adversary's address is detected from the forked 1647 point, the wallet sends τ andτ to the EPID revocation man-1648 ager R. Then, R registers the adversary's secret key into the 1649 EPID's secret key based revocation list Priv-RL.

1651
In this section, we present the size of each object in our 1652 proposed VeloCash and its comparison with Bauer et al.

1654
The setting for cyclic groups G 1 , G 2 and G 3 and other 1655 elements are same as in Appendix C. Note that in Bauer 1656 et.
[5] G 1 , G 2 should be cyclic groups chosen that Symmetric 1657 External Diffie-Hellman assumption (SXDH) holds. On the 1658 other hand, in our VeloCash, G 1 , G 2 should be the groups 1659 that q-Strong Diffie-Hellman (q-SDH) assumption holds, 1660 and G 3 should be the group that decisional Diffie-Hellman 1661 assumption holds.

1662
Since our VeloCash is a decentralized scheme and there 1663 is no online and trusted party Bank as in [5], we still need to 1664 trust to some extent, the tamper-proof device manufacturer, 1665 which is also EPID's group manager. Therefore, we compare 1666 sk B and pk B with isk and gpk, respectively.

1667
At first glance, the ticket size (coin size) of Bauer et al.
[5] 1668 appears much larger than of VeloCash. This is because 1669 VeloCash is based on the stronger assumption (but widely 1670 used in industry), such as the existence of tamper-proof 1671 devices, whereas [5] is based purely on cryptographic 1672 assumptions.

1674
In this paper, we have proposed VeloCash, transferable 1675 decentralized probabilistic micropayments which preserve 1676 anonymity. For the construction of VeloCash, we utilized a 1677 tamper-proof wallet consisting of AESP. To achieve double-1678 spending attack detection and preserve anonymity, we add 1679 extensions to AESP that allow for randomness tape and 1680 requesting EPID signatures from prog to G att .  Setup : and outputs a group public key gpk and an issuing 1694 private key isk.

1696
Issuer I is given gpk and isk. P i is given gpk and 1697 outputs a secret key sk i .

1698
Sign : The above is a probabilistic signature algorithm Given gpk, Priv-RL, and sk, R updates Priv-RL by 1743 adding sk into Priv-RL. An EPID scheme is secure if it satisfies the following three 1752 requirements: correctness, anonymity, unforgeability [7], [8]. 1753 The correctness requires that every signature generated by 1754 a platform is valid except when the platform is revoked by the 1755 secret key based revocation or the signature based revocation. Theorem 14 (Theorem 4 of [28]): The EPID scheme is 1765 correct. 1766 In the anonymity game, the adversary's goal is to determine 1767 which one of two secret keys were used in generating the 1768 signature. The anonymity game between a challenger and an 1769 adversary A is described in Figure 12.  a challenger is negligible as follows: Theorem 15 (Theorem 5 of [28]): An EPID scheme is Diffie-Hellman problem is hard. Let g 1 , g 2 , g 3 be the gener-1805 ators of G 1 , G 2 , G 3 respectively. I chooses h 1 , h 2 ← G 1 , 1806 γ ← Z * p , and ω := g γ 2 . This algorithm outputs The Join protocol is performed interactively between issuer 1810 I and platformer P. The flow is described in Figure 13.

1811
I has (gpk, isk) and P takes gpk. Finally, P obtains 1812 sk = ((A, x, y), f ) where f is a unique membership key and 1813 (A, x, y) is a BBS+ signature [42] on f . 3) It randomly picks 2) appends f in σ 0 to Sig-RL 1867 2) SIGNATURE BASED REVOCATION

1868
Given gpk, Priv-RL, Sig-RL, m, and σ to be revoked, revo-1869 cation manager R updates Sig-RL as follows: In VeloCash, our premise is that all users participating in the 1877 transferable scheme have tamper-proof hardware wallets. The 1878 wallet consists of AESP (tamper-proof device) manufactured 1879 by a trusted manufacturer. The obfuscated program that sends 1880 and receives tickets is installed in the wallet's AESP. It does 1881 not accept any unauthorized operations that deviate from the 1882 protocol, such as double-spending tickets.

1883
For each tamper-proof wallet, the G att in the wallet has an 1884 EPID secret key manufactured and embedded by a trusted 1885 manufacturer. The role of EPID in VeloCash is to make 1886 it possible to verify that the ticket has been sent from a 1887 legitimate and genuine wallet.

1888
It also plays an essential role in excluding adversaries who 1889 have performed double-spending attacks. When the adver-1890 sary performs the double-spending attacks, honest users will 1891 detect the attack and put the adversary's secret key f into the 1892 secret key based revocation list Priv-RL. This will prevent 1893 the adversaries from sending and receiving the tickets with 1894 honest users; thus, the adversary will not be able to perform 1895 double-spending attacks again.

1896
Theoretically, a tamper-proof device is not destructive; 1897 however, the adversary can break it realistically.
1953 5 For practical purposes, we assume that the height of τ can only be measured when all tickets in the sequence from τ to τ are given. Even if such a sequence exists, the height of τ is considered to be ∞ unless the entire sequence is specifically presented.
C k denotes the set of blocks that are k or more blocks 1954 before the beginning of the blockchain. This notion is bor-1955 rowed from Garay et al. [29]. 1956 In order to specify the parameters of the transferable trans-1957 action, the escrow account further contains: where β is the ticket winning amount, p is the probability for 1960 determining winning a ticket, q is the lottery ticket transaction 1961 rate of proportional fee scheme , 6 and µ is a fixed value used 1962 to determine the winning ticket. 1963 We define an escrow as active when the ticket generated 1964 from the escrow is in the process of being distributed, but 1965 the ticket does not meet the condition for winning and is not 1966 registered in the blockchain.
where v is the number of generations of τ , h 0 is the block 1978 height containing the escrow account and µ is the fixed 1979 number specified in the escrow account .

1980
The probability p is calculated using a simple Verifiable 1981 Delay Function (VDF) [30]. The calculation can be done after 1982 a certain period of time has elapsed from when the ticket 1983 is transferred according to the number of generations. For 1984 example, if a ticket with h 0 = 100, µ = 5 and v = 3 is 1985 received, the VDF value will be known when the block height 1986 of 115 is confirmed.

1987
If the ticket τ ∈ win has already been sent and the owner-1988 ship has been transferred, the user with the latest ownership 1989 is considered eligible and can get the winning amount β.

1990
Definition 29: τ v is said to be eligible if and only if the 1991 following properties satisfies: 87) 1993 eligible ticket will be considered as the final winning 1994 ticket. Thus, the user who has the eligible ticket can get β 1995 from the escrow account . This scheme has the advantage that the payment fee can 2033 be smaller than the blockchain transaction fee. There is a concern that the sizeable winning amount β 2055 decreases the velocity of the ticket. Since if there is a large gap 2056 between the winning amount β and the value of the ticket, the 2057 profit of winning β − γ will be more significant. Therefore, 2058 recipients should decide whether to use the ticket for payment 2059 after confirming their winnings, which causes the velocity of 2060 the ticket to be slow. The solution is not to make the winning 2061 amount β too high. In addition, if we set the winning amount 2062 β to a value almost equal to the blockchain transaction fee γ , 2063 the profit of winning will be minimal; thus, the velocity of the 2064 ticket will not be affected.

2066
We adopt tamper-proof devices for sending and receiving 2067 tickets and assume that double-spending attacks can not be 2068 performed under normal circumstances. However, in reality, 2069 the tamper-proof device can be broken, and the adversary can 2070 perform double-spending attacks. We propose two detection 2071 methods. One is Fork Detection which detects the attacks 2072 perfectly, and the other one is Collision Detection which takes 2073 places an upper bound on the expected value by the attack. 2074 When both Fork and Collision detection detect an attack, 2075 honest users share the adversary's address and revoke it so 2076 that the adversary can never participate in the payment system 2077 again.

2078
With the two methods, we force an adversary to compare 2079 the cost of breaking the tamper-proof wallet with the expected 2080 utility obtained. In order for the adversary to profit from the 2081 attack, he has to benefit from a single attack more than the 2082 cost of breaking the tamper-proof wallet. 2083

2084
Fork detection is a detection method that detects double-2085 spending attacks perfectly. Fork implies that two tickets are 2086 assumed to exist, and the resulting ticket prefixes are identical 2087 except for k elements from both ends of the ticket.  Proof: Put the two transactions τ ,τ as τ = { ≺ 2098 τ 1 ≺ · · · ≺ τ n }, andτ = {˜ ≺τ 1 ≺ · · · ≺τ n }. 2099 From the Definition 9, there exists k ≥ 0 that satisfies the 2100 condition (89). We assume n ≥ n without loss of generality. 2101 Then, τ * = { ≺ τ 1 ≺ · · · ≺ τ n−k } is the longest com-2102 mon prefix, and τ n−k+1 andτ n−k+1 are the double spending 2103 transactions. to work the collision detection effectively, we assume that the 2127 ticket transaction protocol is conducted in the three rounds: 2128 Round 1) The adversary sends the tickets to an honest payee.

2129
Round 2) The payee checks received tickets for the collisions.  In reality, the number of addresses each user has is considered more likely to follow an exponential distribution. Therefore, it is an unfavourable assumption that all users have the same number of addresses α.
Assume that the adversary double-spending l tickets with a 2154 maximum value of β per ticket. The adversary's expected 2155 utility value is 2156 E d < max l lβ · (1 − p(l; u)) .
(92) 2157 Thus, E d is at most u e β when l = √ u.

2158
In our transferable scheme, a double-spending attack is 2159 perfectly detected, and the address used in the attack will be 2160 rejected by all users. Therefore, it is not profitable for the 2161 adversary unless the cost of breaking a single tamper-proof 2162 wallet exceeds the maximum expected value gained by the 2163 attack. Specifically, the adversary can not profit under the 2164 following conditions: where is the cost of breaking κ-tamper proof wallet.

PROOF OF THEOREM 8 2172
To prove exculpability property stated in Theorem 8, 2173 we assume there exists a PPT adversary A ex that wins 2174 the exculpability game defined in Definition 13 with non-2175 negligible probability, namely, that outputs (id, π, G ) such 2176 that VerifyGuilt((id, π), G ) = 1.

2177
We will show a reduction that we can construct a PPT 2178 adversary A which wins the EPID anonymity game defined in 2179 Definition 21 with non-negligible probability provided oracle 2180 access to A ex is available.

2181
In order to share the same user list between A and A ex , 2182 we will not allow A ex access to Join; instead, A provide a 2183 sufficiently long list of users (i 1 , . . . , i n ) created by A and 2184 provide the list of users to A ex . Note that this modification to 2185 the exculpability game does not affect the success probability 2186 of A ex .

2187
In the reduction, A generates the parameter param 2188 and sk B , and it joins n users and creates the list 2189 of users (i 1 , . . . , i n ). Then, A ex is executed with input 2190 (param, sk B , (i 1 , . . . , i n )), and it outputs (id, π, G ) with 2191 non-negligible probability as follows: Note that the accused double-spender i * is con-2198 tained in the user list (i 1 , . . . , i n ). Otherwise, given 2199 VerifyGuilt((id, π), G ) = 1, A ex must win the unforgeabil-2200 ity game in Figure 2, and it contradicts with Theorem 7.