Micropayments, or payments in pennies, are increasingly being used by applications as diverse as ad-free web surfing, online gaming, and peer-assisted service networks . This paradigm allows participants to exchange monetary incentives at a small scale, e.g., pay per minute in online games. Such a fine-grained payment process has several advantages, including a great deal of flexibility for customers who may stop a service at any time. In addition, it reduces the financial risks between mutually-distrusted participants, where there is no guarantee that a client will pay after being served, or that a server will deliver service when paid in advance.
However, processing these small payments individually can incur high transaction fees that exceed the few pennies received. For example, the average base cost of a debit or credit card transaction in the US is around 21 to 24 cents, and 23 to 42 cents [9, 10], respectively. In cryptocurrencies such a fee could be even higher, e.g., above 1 in Bitcoin . Beside this financial drawback, handling micropayments individually can impose a huge workload on the system, and may explode the log needed for accountability purposes. Thus, there is a need for a payment aggregation mechanism that records fewer transactions with values that still compensate properly for the small payments received to date.
. In these models, the amount of required payments is locked in an escrow and micropayments are issued as lottery tickets. Each ticket has a probabilityof winning a lottery, and when it wins, produces a transaction of currency units. This means that, on average, only one large transaction is processed out of a batch of tickets. Unfortunately, these early proposals rely on a trusted party to audit the lottery and manage payments. Such a centralized approach may increase the deployment cost and limit the use of the payment service to systems of fully authenticated participants .
As cryptocurrencies evolved, a number of initiatives have attempted to convert these schemes to distributed ones [33, 25]. This is done by replacing the trusted party with the miners, and utilizing the blockchain to provide public verifiability of system operation. Yet, these approaches have several drawbacks that may hinder their usage in large-scale systems. First, they force a customer to issue micropayments sequentially using the same escrow. This means a new ticket cannot be issued until it is confirmed that the previous one did not win, which requires a merchant to report the lottery outcome back to the customer. To issue tickets at a fast rate under this structure, this customer needs to create a large number of escrows, which increases the amount of data on the blockchain. Second, these schemes rely on computationally-heavy cryptographic primitives [33, 25], and several rounds of communication to exchange payments , which incur a large overhead. Such performance issues reduce the potential benefits of micropayments.
This paper proposes a solution to these drawbacks by introducing MicroCash, the first decentralized probabilistic framework that supports concurrent micropayments. MicroCash features a novel payment setup that allows a customer to issue micropayments in parallel and at a fast rate using a single escrow that can pay many winning tickets. This is achieved by having the customer specify the total number of tickets it may issue, and provide an escrow balance that covers all winning tickets under its payment setup.
MicroCash is also cost effective because it introduces a lightweight non-interactive lottery protocol. This protocol requires only secure hashing and allows a payment exchange using only one round of communication without demanding the merchant to report anything to the customer. Furthermore, this protocol is the first to eliminate situations where all lottery tickets may win or lose the lottery. Although the probability of these events is very small, it may discourage customers from using the system since such a possibility, i.e., to pay much more than the expected payments, may impose a strong psychological obstacle . Moreover, accounting for the worst case when all, or almost all, tickets win requires a large escrow balance, which increases the collateral cost. Our protocol solves this problem by selecting an exact number of winning tickets each round (where a round is the time needed to mine a block on the blockchain). All tickets issued in the same round are tied to a lottery draw value in a future block on the blockchain, which is used to determine the set of winning tickets through an iterative hashing process. The security of this protocol, and the whole system, is enforced using both cryptographic and financial techniques. The latter requires a customer to create a penalty escrow that is revoked upon cheating, with a lower bound derived using a game theoretic modeling of the system.
To evaluate its efficiency, we experimentally test MicroCash’s performance and compare it to MICROPAY , a state-of-the-art sequential micropayment scheme. Our results show that a modest merchant machine in MicroCash is able to process 2,240 - 10,500 ticket/sec, which is around 1.7-4.2x times the rate in MICROPAY, with reduction in the aggregated payment size. Furthermore, a modest customer machine in MicroCash is able to concurrently issue more than 33,000 ticket/sec using one escrow over any period, while MICROPAY requires the creation of more than 1000 escrows per second to support a comparable issue rate. This allows MicroCash to reduce transaction fees and amount of data on the blockchain in a video delivery and online gaming applications by .
2 Related Work
To orient readers to the current state-of-the-art in
probabilistic micropayments, in this section we review
prior work done in this area. In addition, we review an alternative payment
aggregation mechanism, called payment networks [26, 34],
focusing on its limitations when used to handle micropayments.
Probabilistic Micropayments. The idea of probabilistic micropayments dates back to the seminal works of Wheeler  and Rivest . In these schemes, a customer and a merchant run the lottery on each ticket by using a simple coin tossing protocol. Thus, there is a chance than more, or less, tickets than expected may win. All of these schemes rely on a centralized bank to track and authorize payments. This imposes additional overhead on the users who have to establish business relationships with this bank. Also, it limits the use of the service to only fully authenticated users. Therefore, this centralization issue is viewed as the main reason for the limited adoption of such solutions .
Systems using cryptocurrency-based probabilistic micropayments have the potential to overcome both the cost and efficiency problems inherent in earlier schemes. To the best of our knowledge, only two such schemes have been proposed to date in the literature, MICROPAY  and DAM .
MICROPAY translates the scheme of Rivest  into an implementation on top of a cryptocurrency system. Instead of using an authorized bank account, customers create escrows on the blockchain that they use to issue lottery tickets. For the lottery protocol, MICROPAY implements a similar interactive coin tossing protocol, and adds an alternative non-interactive version that reduces the communication complexity (a merchant still has to report the lottery result back to the customer). However, the latter is computationally-heavy since it requires public key cryptography-based operations and a non-interactive zero knowledge (NIZK) proof system. Moreover, MICROPAY only supports sequential micropayments as mentioned earlier. DAM shares similar constraints, but it adds the feature of preserving user privacy (not like MICROPAY that is public), where it extends Zerocash  primitives to implement anonymous micropayments.
We believe that the added blockchain transactions due to sequential payments,
coupled with the high computation cost, point to the
need for optimized approaches
that support concurrent micropayments at a lower
overhead. This need is the motivation behind building MicroCash.
Payment Channels and Networks. This payment paradigm was originally developed to handle micropayments in Bitcoin , where it relies on a similar concept of processing most of the small payments locally. Later on, it was geared to enhancing the scalability of cryptocurrencies [29, 26, 34, 32, 28, 30], where utilizing off-chain processing to reduce on-chain traffic helps increase the transaction throughput at a lower overhead.
A payment channel is a contract between a customer and a merchant tied to a shared escrow fund. The ownership of this fund is adjusted over time based on the off-chain transactions, or local payments, made to date. Only two transactions are logged on the blockchain per channel, the opening transaction and the closing one that expresses the latest state of the fund ownership.
In general, payment channels and networks suffer from the high collateral cost of setting up multiple escrows when constructing payment paths between transacting parties. These costs may indirectly push the network towards centralization . This is because only wealthy parties can afford multiple escrows to establish payment channels, and hence, most users will rely on these parties, or hubs, to relay the off-chain transactions. In addition, each hub on the path charges a fee to relay payments. With micropayments, such a setup would be infeasible because these fees could be much larger than the payments themselves. Probabilistic approaches, on the other hand, are more flexible in allowing several parties to be paid using the same escrow. And by doing so, they reduce the collateral cost and eliminate any fees when exchanging lottery tickets. Hence, distributed probabilistic micropayments provide a better solution for handling small payments in cryptocurrency systems.
3 Threat Model
The reliance on off-chain transactions in distributed probabilistic micropayments creates the potential for various types of attacks. In this section, we outline a threat model that accounts for these attacks, which guided the design of MicroCash. In developing this model, we make the following assumptions:
No trusted party exists.
Participants are rational, meaning that they may follow the protocol without violation, or deviate from it, based on what will maximize their utility gain.
The underlying cryptocurrency scheme is secure in the sense that the majority of the mining power is honest. This means that the confirmed state of the blockchain contains only valid transactions, and that an attacker who tries to mutate or fork the blockchain will fail with overwhelming probability.
Hash functions are modeled as random oracles, and the hash values of the blocks on the blockchain are modeled as a uniform distribution.
Efficient adversaries cannot break the basic cryptographic building blocks (SHA256, digital signatures, etc.) with non-negligible probability.
Communication between customers and merchants takes place over a channel that provides integrity, confidentiality, and authenticity, such as TLS/SSL.
We used ABC  to build a threat model for MicroCash (a detailed version of this threat model is available online ). During this process, we identified the assets to be protected in distributed probabilistic micropayments, which include the escrows, the lottery tickets, and the lottery protocol. Then, by analyzing the security requirements of these assets, we produced the broad threat categories in such systems. Our list includes the following:
Escrow overdraft: A customer creates a payment escrow insufficient for honoring the winning lottery tickets, or creates a penalty deposit that does not cover the cheating punishment imposed by the miners. Such a threat could be the result of creating small balance escrows, or front running attacks in which a customer withdraws the escrows before paying.
Duplicate ticket issuance: A customer issues lottery tickets with the same sequence number to several merchants. This leads to issuing more tickets than the escrow can cover, allowing the customer to obtain more service than it pays for.
Invalid payments: A malicious customer hands merchants lottery tickets that do not comply with its payment setup or with the system specifications. Because these tickets will be rejected by the miners if they win the lottery, the customer can avoid paying merchants.
Unused-escrow withholding: An attacker prevents or delays a customer from withdrawing its unused escrows. For example, merchants may delay claiming their winning lottery tickets to keep the payment escrow on hold.
Lottery manipulation: An attacker attempts to influence the outcome of the lottery draw, and hence, bias the payment process.
Denial of service (DoS): This is a large threat category that threatens any distributed system. This work focuses on attacks related to the payment process. For example, an attacker may monitor the network and drop all lottery tickets to disturb the service.
Note that dealing with malicious merchants who collect lottery tickets and do not deliver a service is outside the scope of MicroCash. The same is true for dealing with malicious customers who may obtain the service without paying. In this work, we are concerned with the payment scheme design, rather than how to exchange service for a payment, which is part of an application design.
In addition, MicroCash does not address payment anonymity. Addressing this issue securely, while preserving the low overhead of MicroCash, is a direction of our future work.
4 MicroCash Design
Having outlined the security threats to probabilistic micropayments, and the limitations of existing solutions, this section presents the design of MicroCash, a concurrent micropayment system that addresses these issues. We start with an overview of the system, followed by a more detailed technical description.
A high level illustration of MicroCash, that also captures the remainder of this section’s organization, is found in Figure 1. As shown, during the payment setup (Step 1, Section 4.1), each customer issues a transaction creating two escrows: payment and penalty. The customer uses the former to make payments in the form of lottery tickets, while the miners use the latter to financially punish this customer if it cheats. Payment exchange starts as soon as the escrow transaction is confirmed on the blockchain. At that time, merchants can check the escrow setup before transacting with the customer (Step 2). In exchange for the delivered service, the customer issues these merchants lottery tickets according to a ticket issue schedule that limits the ticket issue rate over a set period (Step 3, Section 4.2). To redeem these payments, a merchant keeps each of its tickets until the lottery draw time of this ticket. It then observes a value derived based on the block mined at that time to determine if this ticket won (Step 4, Section 4.3). If it is a winning ticket, the merchant can claim currency from the customer’s escrow during the ticket redemption period (Step 5, Section 4.4). This interaction continues until the end of the escrow lifetime. At that time, and when all issued tickets expire, the customer can spend any remaining funds.
4.1 Escrow Setup
MicroCash introduces a novel escrow setup that allows multiple winning tickets to be redeemed, which enables both concurrent ticket issuance and reduces the amount of on-chain escrow-related data. This setup provides techniques to determine the needed escrow balance to cover all concurrent tickets, and to track the issuance of these tickets in a distributed way.
4.1.1 Escrow creation.
As an off-chain payment scheme, MicroCash must ensure that customers can and will pay. This includes honoring winning tickets, and, if caught cheating, complying with a stipulated financial punishment. To satisfy these requirements, each customer must create payment and penalty escrows with sufficient funds to cover both eventualities.
Given that each payment escrow must be tied to a penalty escrow, a customer sets up both using one creation transaction. This transaction provides funds to be locked under each escrow balance, where we refer to the payment and penalty escrow balances as and , respectively. It also configures a set of parameters that influence how the value of both and are computed, and how they are to be spent. These parameters, whose values are specified by the customer possibly after negotiating with the merchants, include the following:
The lottery winning probability .
The currency value of a winning lottery ticket .
The ticket issue rate , which is the maximum number of tickets a customer is allowed to hand out per round. This is used to calculate which ticket sequence numbers are valid within each ticket issuing round.
A lottery draw round length, denoted as , such that for some small system parameter . The customer has to configure , , and in a way that makes of an integer value (this is the number of winning tickets in a lottery draw).
The set of beneficiary merchants that can be paid using the escrow, where the size of this set is denoted as .
Computing and based on the above parameters proceeds as follows. To permit concurrent micropayments, must be large enough to pay all winning tickets tied to an escrow. Given that each winning ticket has a value of currency units, and that there are winning tickets per rounds, can be simply computed as follows (where is the escrow lifetime in rounds, and there are / lottery draws):
For , we compute a lower bound for this deposit using an economic analysis that accounts for the additional utility gain a customer may obtain by cheating. This bound is given by the following equation:
where is the lottery draw period in rounds, is the ticket redemption period in rounds, and such that and (more about these parameters in Section 4.3). This lower bound ensures that the financial punishment exceeds the additional utility gain of cheating, and hence, makes cheating unprofitable compared to acting honestly. The full details of deriving this bound are found in Section 5.
Verifying the correctness of a payment setup is performed by the miners upon receiving the escrow creation transaction. First, they verify that the customer owns the input funds. Then, the miners use to compute the escrow lifetime as = . After that, they check that both and are of integer values, is within the allowed range, and that is multiples of . Lastly, the miners verify that satisfies the bound given above. If all these checks pass, the miners add the escrow transaction to the blockchain. Otherwise, they reject the escrow by dropping its transaction.
4.1.2 Escrow management.
In MicroCash, the escrow funds can be spent only for a restricted set of transactions. This set includes claiming winning tickets, presenting proofs-of-cheating, and (after the escrow lifetime is over) enabling a customer to spend its unused escrow funds.
To track the locked funds, miners maintain a state for each escrow in the system. This state includes the following:
The ID of the escrow, which is a random value generated by the miner who adds the escrow creation transaction to the blockchain.
The balances of both the payment and penalty escrows.
The public key of the owner customer, which is used to verify all signed tickets that are issued using this escrow.
The values of , , , , , and the set of beneficiary merchants (both the public key of each merchant and a corresponding index).
An escrow refund time, denoted as , at which the customer can spend any remaining funds. Miners set this time to be equal to the expiry time of the tickets issued in the last round of an escrow lifetime.
Ticket issuance using an escrow must follow a schedule based upon the tickets’ sequence numbers. That is, if an escrow supports a rate of tickets per round, then in the first round tickets with sequence numbers to -1 may be issued. Then, in the second round tickets with sequence number range to -1 can be issued, and so on until the last round of an escrow lifetime. Merchants will accept tickets in the current round with sequence numbers that follow this assignment schedule. In order to deal with the fact that customers and merchants may have inconsistent views of the blockchain, and hence, may not agree about what the current round is (i.e., current height of the blockchain), merchants will also accept tickets from the prior and next round given that these tickets use the correct sequence number range.
An example of a ticket issuing schedule is found in Figure 2. As shown, the escrow creation transaction is published at round 10 and confirmed at round 16. This escrow has = 3 rounds, and allows a ticket issue rate of 1000 tickets per round. Thus, the customer has 3 ticket issuing rounds, starting at round 17, with the sequence number ranges shown in the figure.
The miners update the escrow state based on the escrow related transactions (mentioned earlier) they process. For example, redeeming a winning ticket reduces by coins, and receiving a valid proof-of-cheating against the customer causes the miners to burn the funds in . All these transactions are logged on the blockchain, which permits anyone to validate the state.
The miners discard an escrow state once all tickets tied to this escrow expire, which happens at time , or when an escrow is broken after receiving a valid proof-of-cheating (proof-of-cheating is discussed in Section 4.5). At that time, the customer may spend the remaining funds of its payment escrow (if any) and its penalty deposit (if not revoked).
4.2 Paying with Lottery Tickets
After the escrow is confirmed on the blockchain, a customer can start paying for service by giving merchants lottery tickets. A lottery ticket is a structure containing several fields as follows:
where is the recipient merchant index as listed in the escrow state, is the escrow ID, is the ticket sequence number, and is the customer’s signature. The field, along with , identifies a ticket, which also provides means for ticket tracking in the system. Note there is no need to include any information about the escrow setup or the parties’ public keys in the ticket itself. Merchants and miners can look these up on the blockchain using .
When issuing a ticket, the customer fills in the above fields and signs the ticket using the secret key tied to the public key the customer used when creating the escrow. The ticket can be any sequence number within the range assigned to the current ticket issue round. The customer can continue issuing lottery tickets, without waiting the lottery results of previously issued ones, until it finishes all sequence numbers in this range. After that, it must wait the next round to generate more tickets.
Upon receiving a ticket, a merchant verifies it as follows:
Check that the escrow is not broken
Check that its index , that appears in the ticket, is identical to the one listed in the escrow state.
Verify that is within the valid range based on the ticket issuing schedule. (As mentioned before, to handle inconsistencies in the blockchain view, tickets from the previous or next issuance round can be accepted.)
Verify over the ticket using the customer’s public key.
If any of the above checks fails (except the fourth one), the merchant drops the ticket. On the other hand, if the ticket has an out-of-range sequence number (i.e., larger than the maximum sequence number allowed by the escrow), the recipient merchant can issue a proof-of-cheating that will cost the customer its penalty deposit. Otherwise, if all the above checks pass, the merchant accepts the ticket and keeps it until its lottery draw time.
4.3 The Lottery Protocol
MicroCash introduces a lightweight lottery protocol that relies solely on secure hashing. This protocol does not require any interaction between the customer and the merchant. Instead, it utilizes only the state of the blockchain, where the lottery draw outcome is determined by a value derived from the block mined at the lottery draw time.
To specify the lottery draw time, MicroCash defines two system parameters, and mentioned earlier. represents the least number of rounds a ticket has to wait after its issue round (which we call ) until it enters the lottery. determines the number of consecutive ticket issuing rounds that will have all their lottery tickets enter the same lottery draw111Since affects of a ticket, MicroCash specifies a small interval for its possible values to prevent a customer from excessively delaying paying merchants.. Hence, if = 1, then the draw time of a ticket is computed as = + . On the other hand, if , then of a ticket is of the last ticket issuing round in the contiguous set of rounds.
A clarifying example of determining the lottery draw time is found in Figure 3. As shown, starting with the first ticket issuing round, which is 28 in the figure, each set of contiguous rounds enter the lottery together. For example, all tickets issued in rounds 28, 29, and 30 enter the lottery at round 40, which is 10 rounds after the last ticket issue round in this set.
Accordingly, whether a ticket wins or loses depends on a lottery draw value tied to the block mined at time . This value is computed using a simple verifiable delay function (VDF)  that is evaluated over this block. This evaluation takes a period of time, hence the name delay function, where this period is a system parameter. Consequently, when a miner mines the block at index , it cannot tell immediately which ticket will win or lose. This miner first has to compute the VDF over this block.
We instantiate this VDF using iterative hashing, where the number of iterations is set to a value that delays producing the output by the period specified in the system. In addition, we let the miners compute this function as part of the mining process. That is, when a miner mines a new block, it evaluates the VDF over the previous block. Therefore, the VDF value of the block at index appears on the blockchain when the block at index + 1 is mined.
Accordingly, in our protocol a merchant keeps a ticket until its lottery draw time . Then, after observing the VDF value of the block mined at that time, the miners, and any party in the system, can compute the set of winning sequence numbers for that round as follows. First, the hash of the VDF value along with the escrow ID is computed, which we call , and then is mapped to a sequence number within the assigned range of the ticket issuing rounds tied to . To obtain the second winning ticket sequence number, the hash of is computed to obtain , and then is mapped to a ticket sequence number in the given range. If a collision occurs, i.e., a previously seen sequence number is produced, it is discarded and the process proceeds with hashing to obtain , and so on. This continues until a set of distinct winning sequence numbers is drawn222We design a version of this lottery protocol with independent ticket winning events in Appendix I. This version can be used in case it is infeasible in some applications to configure to be an integer..
The previous process is clarified by the example depicted in Figure 4, which has the same setup as in Figure 3. As shown, and assuming that round 28 is the first ticket issuing round, the ticket has been issued at round 29, and hence, it entered the lottery at round 40. The VDF value of the block with index 40 appears inside block 41. By using this value, a set of winning sequence numbers is chosen, based on which the ticket in the figure is a winning one because its sequence number is within this set.
Note that the lottery draw involves only values that are part of the escrow state. In other words, it relies on parameters that the issuing customer cannot manipulate, which do not include the merchant recipient address. This means that a ticket’s chance of winning the lottery is not affected by who owns it. In addition, this means that if a customer issues tickets with duplicated sequence numbers to multiple merchants, all these tickets will win or lose together. If the tickets win, detecting cheating is trivial because both merchants will publish their winning tickets to the blockchain to redeem the tickets.
4.4 Claiming Winning Tickets
After the lottery draw, a merchant can collect currency from the customer’s escrow by redeeming its winning tickets (if any). This is done by issuing a redeem transaction that has the winning ticket as input, and has coins directed to the merchant’s address as output.
To allow the miners to resolve tickets and release escrow funds back to the customer in a reasonable timeframe, MicroCash specifies a redeem period for each ticket. This is done by defining a system parameter called that determines the number of rounds during which a ticket can be redeemed. After this period, a ticket expires, which happens at time = + . Thus, must be set to a value that allows merchants to redeem their winning tickets.
After receiving a redeem transaction, the miners process it as follows:
Check that the format of the transaction complies with the system specifications.
Verify the redeemed ticket as outlined in Section 4.2.
Verify that the ticket is a winning one by checking that its sequence number is among the winning set tied to time of this ticket.
Check that the ticket is not expired.
Verify the merchant’s signature over the redeem transaction using the public key corresponding to found in the escrow state. This is needed to prevent participants from redeeming tickets they do not own.
Check that no other ticket with the same sequence number and tied to the same escrow has already been redeemed. If it is, this is a proof of duplicate ticket issuance and is used as a proof-of-cheating against the customer.
If all these checks pass, miners approve the redeem transaction and update the escrow state accordingly. Otherwise, they drop an invalid transaction and, if a proof-of-cheating is produced, revoke the customer’s penalty deposit.
4.5 Processing Proof-of-cheating
A proof-of-cheating is a special transaction that can be presented to the miners by any party who witnesses a cheating incident. In MicroCash, such an incident could be issuing more tickets than what an escrow can cover, i.e., exceed the maximum an escrow may allow, or duplicate ticket issuance. A signed lottery ticket with an out-of-range sequence number or signed tickets with duplicated sequence numbers are publicly verifiable proofs against the issuing customer.
Upon verifying cheating, miners punish the customer by revoking the penalty escrow tied to its payment escrow referenced in the ticket as follows. In case of duplicate ticket issuance, the miners first pay all duplicated winning tickets from the payment escrow, if it is sufficient, and from the penalty deposit thereafter. Then, they publish an escrow break transaction containing the proof-of-cheating on the blockchain. This transaction burns the revoked penalty deposit rather than providing them to another party. This is done to mitigate the case that if the funds are provided to another party, that party may have colluded with the customer to receive those funds. Respecting the lower bound of , as specified by equation 2, ensures that all the aforementioned cheating behaviors are less profitable than acting in an honest way. Hence, it makes such behaviors unappealing to rational customers.
5 Computing a Lower Bound for
In this section, we compute a lower bound for the penalty deposit required to deter cheating. This is done using a game theoretic approach that quantifies the additional utility gain, or monetary profit, a malicious customer could accrue as compared to an honest one. By setting the penalty deposit to at least equal this additional utility, cheating becomes less profitable in expectation than acting honestly, and hence, becomes less unappealing to rational customers.
In what follows, we present this analysis including the
malicious strategies addressed, the game setup, and a definition for the utility
gain function. Finally, we state and prove a lower bound for .
Covered malicious strategies. In MicroCash, a penalty escrow is revoked upon the detection of two types of malicious events: issuing duplicated tickets or issuing invalid payments. The utility gain of any of these malicious strategies depends on the length of the cheating detection period, i.e., the time needed to detect a cheating incident. Throughout this period, the cheating customer is still perceived as honest by merchants, and so can continue cheat and increase its utility gain. Consequently, the longer the detection period lasts, the greater the accumulated additional utility.
Given that merchants verify each ticket immediately when
received, invalid payments are detected
instantly. On the other hand, duplicated tickets are not detected
until they are redeemed (if they win the lottery), which may happen
after several rounds in MicroCash. This means that the additional
utility gain of ticket duplication will be larger than one obtained by
issuing invalid payments. Therefore, setting the value of
the penalty deposit based on the additional utility gain of the former covers the latter as well.
For this reason, we consider only ticket duplication strategy
in our analysis.
Game setup. We posit a single player game in which a malicious customer applies the ticket duplication strategy. This strategy is defined as duplicating a sequence number among two or more tickets, up to tickets, where is the number of beneficiary merchants of an escrow.
Based on the design of MicroCash’s lottery protocol, these duplicated tickets will either all win the lottery or all lose because the lottery draw does not depend on the ticket recipient address (see Section 4.3). This means that duplication among fewer than merchants does not reduce the cheating detection probability. Therefore, a rational customer who decides to duplicate a specific ticket will always duplicate it among all merchants.
Moreover, under the fixed winning rate approach, a rational customer will not duplicate more than sequence numbers. This is because a number of winning tickets (or sequence numbers) will be selected at each round, and the rest of the tickets, i.e., tickets, will not win. Thus, duplicating more than sequence numbers guarantees that a duplicated ticket will win. Exceeding this number means that the cheating detection probability will be 1.
As mentioned previously, MicroCash requires any customer to specify the set of merchants who are beneficiaries of its escrow in advance. This is needed to be able to bound the additional utility gain of malicious customers . If this set is not specified, the additional utility cannot be bounded because we would not know the maximum number of duplicated tickets that could be issued.
Since MicroCash adds the parameter that groups several rounds together when entering the lottery, we refer to a list of contiguous rounds as a lottery round. Hence, the number of lottery rounds in an escrow lifetime is , and in each lottery round a customer can issue up to tickets333In case of a non-integer number of lottery rounds, we take the ceiling. This makes our bound more conservative, and hence, provides stronger motivation for acting honestly.. Based on these variables, the cheating detection period of all duplicated tickets issued in any lottery round in MicroCash is + rounds (the latter is in terms of simple rounds, where a round is the time needed to mine a block on the blockchain). That is, a malicious customer will be detected when any of the duplicated tickets is presented to the miners444We do not assume that merchants exchange any information about tickets they received.. This happens if duplicated tickets win the lottery and are then claimed by the merchants. Considering the worst case that this claim may take place in the last round of the redeem period, cheating will be detected after + rounds from a ticket issue time. At that time, the miners revoke the penalty escrow and the cheating customer leaves the system. Otherwise, if none of the duplicated tickets win, this customer stays and may continue cheating. To simplify the analysis, we will use lottery rounds to express the cheating detection period. That is, this period is expressed as ( + )/ lottery rounds. To ease the discussion, we use round to refer to a lottery round in the rest of this section.
|Utility gain function.|
|The number of tickets that can be issued per lottery round, such that and .|
|The lottery draw period measured in lottery rounds, such that and .|
|The ticket redemption period measured in lottery rounds, such that and .|
|Number of duplicated tickets in a lottery round , such that .|
|Number of beneficiary merchants, such that .|
|Lottery winning probability, such that .|
|Currency value of a winning ticket, such that .|
|The escrow lifetime measured in lottery rounds, such that and .|
Table 1 summarizes the notations we use in
this section, including shorter
abbreviations than those used earlier in this paper to
Utility gain function definition. We define the utility gain function of
any customer as the service value minus the payments made to
merchants. We compute the expected value of this function for an
honest customer and for a malicious one that
uses the ticket duplication strategy. In order to deter cheating, we
require the latter to be less than or equal to the former. This is achieved
by setting the penalty deposit to be at least equal to the maximum
additional expected utility gained by cheating.
Additional utility gain analysis. We now state and prove a lower bound for based on the above game setup.
For the game and escrow setup described above, issuing invalid or duplicated lottery tickets is less profitable in expectation than acting in an honest way if:
In MicroCash, a customer can create an escrow with a round lifetime. All tickets issued in a round enter the lottery after rounds, and all winning tickets will expire after rounds from the lottery draw time. In other words, for each round , all tickets issued in round will enter the lottery at round and will expire at round .
During each round of an escrow lifetime, an honest customer can issue up to tickets with unique sequence numbers. Each ticket has an expected value of coins, which corresponds to the service value a customer obtains from a merchant for handing out this ticket. We use this service value in computing the utility gain function, and hence, deriving a lower bound for .
In contrast, when applying the duplicated ticket issuance strategy, for each round a malicious customer would decide to duplicate tickets, where . If none of the duplicated tickets win, which happens with probability ,555The expression stands for . the customer stays in the system and obtains an additional utility gain of over what an honest customer would receive. This occurs because an honest customer will use a sequence number with one merchant only. The malicious customer uses a sequence number with merchants, and hence, it obtains service from an additional merchants by duplicating a sequence number.
On the other hand, if any of the duplicated tickets wins the lottery at round , which happens with probability , the malicious customer will be detected at round (the latest). This reduces its additional utility by since the penalty escrow will be revoked by the miners.
Note that when a duplicated ticket wins, meaning that cheating will be detected, the malicious customer will still have rounds to issue tickets. Therefore, as a rational behavior, this customer will choose to duplicate all tickets in these rounds because it must leave the system either way.
In order to compute the additional utility gain, we need to model the duplication decisions a malicious customer would make at each round of an escrow lifetime. We use a decision process diagram that captures a process evolution over time. Such a diagram contains states indicating the rounds, transition probabilities between these states computed based on the decisions made at each state, and the additional utility of being at each state, or round, in the system.
To clarify this concept, we consider a simple case where we have an escrow with 3 round lifetime, rounds, and round. The decision process for this setup is captured in Figure 5. As shown, a customer issues tickets for rounds 1 and 2 before any lottery draw takes place, in which it duplicates and tickets, respectively. All tickets issued during round 1 enter the lottery at the beginning of round 3 (or immediately after the end of round 2 as depicted in the figure). If none of these tickets win, the malicious customer obtains an additional utility gain of and proceeds to round 3. For this round, the customer decides to duplicate tickets. On the other hand, if any of the tickets wins, the customer knows that it will be detected at the end of round 3 (since ). Thus, it decides to duplicate all tickets in round 3 (i.e., ). The total additional utility the customer obtains in this case, which is displayed above the exit state since this customer will leave the system, is the sum of the utility gain of duplicating , , and tickets, where , minus the penalty deposit that will be revoked.
The same analogy is applied to the rest of the rounds, with the exception that at the very last rounds there are less than rounds that can be used at the exit state. In other words, the number of remaining rounds in the escrow lifetime could be less than , and hence, a customer will duplicate fewer than tickets. This is illustrated in the exit state after round in Figure 5.
Instead of analyzing a decision process for a round escrow directly, we formulate the expected utility gain of a malicious customer in a recursive way. That is, we use the expected utility gain in a round escrow to compute the expected utility gain in a round escrow, and so on. Intuitively, during the first round of a round escrow, a malicious customer will decide to duplicate tickets. If any of these tickets wins at round , cheating will be detected. In this case, and as mentioned earlier, the customer will duplicate all tickets for the next rounds and will pay the penalty . This means that with probability , the utility gain is .
If none of the tickets wins the lottery, the customer stays in the system. In this case, round 2 offers a fresh start in a round escrow. That is, after collecting the utility gain of duplicating tickets, the customer is just like starting fresh in a one round shorter escrow. This means that with probability , the utility gain will be , where the second term denotes the expected utility gain of a malicious customer in a round escrow.
Based on the above, we can express , which is the quantity of interest, as follows:
But we have since the penalty for a round escrow has been configured in a way that makes in order to deter cheating. Hence, and by requiring to make cheating unprofitable, we find that:
For any and value, the above quantity is maximized when for .666This is done by considering the terms in equation 6. For the first term, we used a simple iterative program to compute the value of that maximizes this term for , with an increment step of , and . We found that for all these values. The second term is maximized when is set to its maximum value, which is , for all . Substituting these in equation 6 produces the lower bound stated in the theorem, which completes the proof.777Equation 4 in Theorem 1 is reported in Section 4 as equation 2 after converting the lottery rounds into simple rounds using the original notations found in that section. ∎
6 Security Analysis
In this section, we analyze the resilience of MicroCash to the threats outlined in
Section 3. To defend against these threats, our scheme
utilizes cryptographic and financial techniques based on the threat type to
be addressed. This is discussed in the following paragraphs.
Escrow overdraft. This threat can be exploited using several strategies, including:
A customer creates a payment escrow with a balance that cannot cover all winning tickets, or a penalty escrow with a balance that cannot cover the financial punishment.
A customer issues more tickets than the specified in its escrow setup.
A customer performs a front running attack in which it withdraws the payment escrow before paying merchants, or withdraws the penalty escrow before paying the financial punishment when caught cheating.
The first strategy, in which a customer creates payment and penalty escrows with insufficient balances, is neutralized by the escrow setup of MicroCash. When processing an escrow creation transaction, the miners check that the payment escrow balance covers all winning tickets (see Section 4.1). In addition, they check that the penalty deposit meets the lower bound derived in Section 5. The miners will reject any escrow that does not satisfy these conditions.
The second strategy, i.e., issuing more tickets than can be covered by the escrow, cannot be performed because lottery tickets are tracked using their sequence numbers. When receiving a ticket, a merchant checks that a sequence number to be within the range assigned to a ticket issue round before accepting the ticket. Hence, if a customer exceeds in any round, merchants will detect that immediately. Merchants will reject any ticket outside of the current round (modulo one round to deal with desynchronized views of the blockchain).
As for the last strategy that covers front running attacks, such
attacks are mitigated by the
escrow spending mechanism and the lottery protocol implemented in
MicroCash. A customer does not control any of the escrows it owns. Instead,
fund release is triggered only by the receipt of a valid winning lottery ticket,
in the case of a payment escrow, or a valid proof-of-cheating, in the case of
a penalty escrow. Honest miners will enforce these rules in the system.
Duplicate Ticket Issuance.
MicroCash addresses this attack financially through a detect-and-punish
approach. Any party that detects two or more tickets issued using the same escrow
and carrying identical
sequence numbers can produce a proof-of-cheating
against the issuing customer. Miners publish this proof on the blockchain, which
burns the customer’s penalty escrow as a punishment. Setting the penalty deposit
as described in Appendix 5 makes cheating unprofitable,
which deters rational customers from attempting this malicious strategy.
To pursue this attack, a customer may issue tickets with invalid
format or invalid field values knowing that these tickets cannot be
claimed later if they win. An invalid ticket is one that uses
an invalid escrow (e.g., a broken one), has
an invalid tuple, or contains a
merchant index that is not listed in the escrow state. These events can be detected
instantly because merchants validate all lottery tickets before
accepting them. As mentioned previously, an invalid ticket is
dropped unless it has an invalid tuple.
As such a ticket can be used as a proof-of-cheating, the customer
loses the penalty escrow, which exceeds any
profit from cheating. This discourages rational customers from issuing
This threat is mitigated by the expiration rule of lottery tickets and
MicroCash’s escrow refund policy. Each ticket has a set redemption
period after which it expires. Hence, a
merchant who tries to put an escrow on hold by delaying a winning ticket
claim will lose its payment. Furthermore, when all
tickets tied to an escrow expire, i.e., when is approached, the
miners will allow the customer to spend the remaining funds
in its escrow. This prevents locking
unused escrow funds indefinitely on the blockchain.
DoS. As DoS is a large threat category, in this work we consider only the cases that are unique to the design of MicroCash. These include preventing customers from creating escrows, preventing merchants from claiming their winning lottery tickets, or controlling relaying blocks and transactions based on their content. Such situations may happen when miners disregard specific transactions or blocks, or when an attacker controls the network links and drops specific transactions or blocks.
The case of miners disregarding specific transactions/blocks may take place when an attacker controls a substantial portion of the mining power. This may work even under the assumption that the majority of the mining power is honest. That is, an attacker with of the mining power may still be able to perform harmful attacks, e.g., selfish mining . To protect against selective relaying, techniques that allow propagating blocks and transactions without disclosing their content can be employed, e.g., BloXroute .
The case of controlling the network links, which represents
attacks against network availability,
is a potential problem in any distributed system.
Deploying mechanisms to enhance network
connectivity, such as participants maintaining connections with large
number of miners, may reduce the impact of this attack. Such
mechanisms are independent of the design of MicroCash, and so it is
up to the parties themselves to adopt suitable solutions.
Lottery manipulation. This threat covers all strategies that could be used to manipulate the lottery draw, including:
An attacker, who could be any party inside or outside the system, tries to influence the hash used in a lottery draw in order to make specific tickets win or lose.
A malicious customer may issue winning lottery tickets, to itself or to malicious colluding merchants, to drain the escrow before other merchants can claim their winning tickets.
A malicious customer deliberately issues losing tickets to merchants to avoid paying them.
An attacker, insider or outsider, tries to issue lottery tickets to herself or others.
In the first strategy, an attacker tries to influence the lottery by controlling the hash used in the lottery draw. This can be done by either manipulating the ticket fields that impact the lottery, or by controlling the hash of the block mined at time . In the former, the issuing customer may tweak a ticket in order to influence its chance of winning the lottery. In the latter, a miner may forgo any block that does not produce a favorable lottery outcome (i.e., a favorable VDF value), or even publish an incorrect VDF value in order to bias the lottery draw outcome.
All these malicious behaviors are mitigated by the lottery protocol design. The ticket fields that impact the lottery draw include only the ones that appear in the escrow state, and these cannot be tweaked by the issuing customer, or by any other party. As for discarding unfavorable blocks, recall that the lottery draw is based on the VDF value of the block at index . Therefore, a miner who chooses to perform this computation and then announce a favorable block, is not likely to succeed in publishing this block on the blockchain. Computing the VDF takes time, and in the meantime other miners will announce their blocks immediately. These blocks are more likely to be adopted by the network, and hence, to be used in the lottery draw (under the assumption that the majority of the mining power is honest). Furthermore, publishing an invalid VDF value will not succeed because honest miners, who already computed this value while mining their blocks, will reject a newly received block with a VDF value that does not match their own. Consequently, such a malicious miner will not only fail in biasing the lottery, but also will lose the mining rewards.
In the second strategy, a malicious customer tries to withdraw an escrow indirectly by issuing winning tickets to itself, and claiming these tickets before merchants can claim their payments. To do so, a customer may wait until the block at index is mined and then print winning tickets to itself. This technique is mitigated by the lottery protocol design. As the ticket issue schedule specifies both issue and lottery draw time for each round, it will be too late for the customer to select winning sequence numbers after . After observing the block at time , this customer cannot do anything to produce winning tickets other than checking which sequence numbers are winning (assuming it did not use these sequence numbers to pay any merchant earlier). As mentioned previously, this customer cannot manipulate the ticket fields to make a losing sequence number win. Also, it cannot issue losing tickets using these sequence numbers to merchants because the issue time of these tickets was at least rounds earlier, and hence, merchants will not accept these tickets that lost the lottery. On the other hand, should a customer who saves some sequence numbers and uses them to issue tickets to itself have winning tickets, it will not affect the payments of other merchants. Such sequence numbers represent legitimate tickets and are therefore are covered by the payment escrow balance.
The third strategy, where a customer deliberately hands merchants losing tickets, will fail with overwhelming probability. In order to determine which ticket will lose the lottery, the customer needs to either predict the hash of the future block mined at time in order to compute its VDF value, or take a guess at the VDF value itself. Since hash functions are modeled as random oracles, predicting such values succeeds with negligible probability.
Lastly, the fourth strategy, in which an attacker tries to issue tickets tied to escrows she does not own, will not succeed due to the system’s use of secure cryptographic signatures. MicroCash requires customers to sign all lottery tickets they issue, which means that to issue a valid ticket an attacker needs to forge the customer’s signature. By using a secure digital signature scheme such an attack will fail with overwhelming probability.
7 Performance Evaluation
In order to understand the performance benefit of concurrent probabilistic micropayments, this section evaluates the computation, bandwidth, and payment setup costs of MicroCash. To do this, we conduct empirical experiments to answer the following questions:
How fast can customers, merchants, and miners process lottery tickets?
What is the bandwidth cost of exchanging these tickets?
What is the size of escrows on the blockchain?
How do the schemes compare using workload numbers derived from real world scenarios?
To put our results in context, we compare our scheme with MICROPAY . The rest of this section describes our methodology and discusses the significance of the obtained results.
To establish our benchmarks, we implemented the functions used for generating tickets, verifying these ticket, and performing a lottery draw. For MicroCash, we followed the design introduced in this paper. For MICROPAY, we tested its fully decentralized version, called MICROPAY1, with its non-interactive lottery protocol as outlined in . This protocol requires a merchant to publish the description of a verifiable unpredictable function to perform the lottery. For this function, we used the verifiable random function (VRF) construction introduced by Goldberg et al.  with its implementation over the NIST P-256 curve .
Two cryptographic primitives affect the implementation of both MicroCash and MICROPAY, namely, hash functions and digital signatures. For hashing, we used SHA256. For digital signatures, we chose to test the most common elliptic curve based constructions. These include ECDSA with secp256k1 curve (used in Bitcoin and most cryptocurrencies), ECDSA with P-256 curve (widely used and recommended by NIST), and EdDSA with Ed25519 curve  (of a great interest recently as its security and efficiency have encouraged several major cryptocurrencies to either use this scheme [18, 15] or prepare to switch to it [17, 11]).
We computed the performance metrics of interest as follows. The computation cost was measured as the rate at which customers, merchants, and miners can process lottery tickets. Bandwidth overhead was calculated by reporting on the size of tickets (in bytes) when exchanged between customers and merchants, and when claimed through the miners. To evaluate the effect of micropayment concurrency, we computed the number of escrows a customer would need to support the ticket issue rate in each of the tested schemes. Lastly, we studied two real life applications and computed the overhead of processing micropayments using workload numbers derived from these applications.
Our experiments were implemented in C on an Intel Core i7-4600U CPU @ 2.1 GHz, with 4 MB cache and 8 GB RAM, where each of the payment processing functions was called times.
7.2 Microbenchmark Results
7.2.1 Lottery ticket processing rate
We start by quantifying the computation cost of processing micropayments in both schemes. This is done by measuring the rate at which a customer can generate lottery tickets, the rate at which a merchant can process these tickets, which involves both validating a ticket and running the lottery888Although a merchant in MicroCash runs the lottery several rounds after validating a ticket, we report the cost of these two operations together. This is because such cost is the overhead per ticket incurred on the merchant side., and the rate at which miners validate claimed tickets and running the lottery for the escrows. The obtained results are found in Table 2.
|ECDSA (secp256k1)||ECDSA (P-256)||EdDSA (Ed25519)||ECDSA (secp256k1)||ECDSA (P-256)||EdDSA (Ed25519)|
As the table shows, customers in both schemes generate tickets at comparable rates because the operations performed are almost identical in MicroCash and MICROPAY. Given that the heaviest operation in this process is signing a ticket, the generation rates improve by using an efficient digital signature scheme (when replacing ECDSA (secp256k1) with ECDSA (P-256) and EdDSA (Ed25519), performance is boosted by around 17x and 14x, respectively).
The trend is different for the rates of merchants and miners. These parties in MicroCash are 1.7x, 4.2x, and 3.2x faster than in MICROPAY for the three digital signature schemes. This is because miners and merchants run and verify the lottery draw outcome. In MicroCash, this process involves only lightweight hash operations. On the other hand, the lottery in MICROPAY requires evaluating, and proving the output correctness, of a computationally-heavy VRF.
Furthermore, merchants and miners in MicroCash benefit more from the efficiency of the used digital signature scheme. This is because the heaviest operation these parties perform when processing a ticket in MicroCash is verifying a customer’s signature. However, in MICROPAY the bottleneck is evaluating a VRF and producing a proof that its output is correct on the merchant side, and verifying this proof on the miner side. As shown in the table, MICROPAY obtains only around 1.9x improvement when replacing ECDSA (secp256k1) with any of the other two schemes. In contrast, MicroCash achieves around 4.7x and 3.8x improvement when replacing ECDSA (secp256k1) with ECDSA (P-256) or EdDSA (Ed25519), respectively.
Key Takeaway: Compared to MICROPAY, MicroCash reduces the computational load on merchants and miners by a factor of 1.7-4.2x.
7.2.2 Lottery ticket bandwidth cost
In terms of bandwidth, MicroCash incurs less overhead than MICROPAY because its lottery tickets are smaller. A ticket sent from a customer to a merchant is 110 bytes in MicroCash, while it is 274 bytes in MICROPAY. A winning ticket sent from merchants to miners is also 110 bytes in MicroCash, while it is 355 bytes for MICROPAY because this ticket must be accompanied with a NIZK proof. This means that MicroCash incurs only 40 of the bandwidth overhead of MICROPAY between customers and merchants, and only 31 of the overhead between merchants and miners.
To put these numbers in context, we report on the transaction sizes in Bitcoin. The average size is around 500 bytes, where a transaction with one or two inputs is about 250 bytes . Adding a winning ticket as one of these inputs produces a claim transaction with a size of 360 bytes in MicroCash, which is less than the average Bitcoin transaction size. On the other hand, in MICROPAY the size of a claim transaction will be 605 bytes, exceeding the average size.
Key Takeaway: The use of efficient lottery protocol reduces not only the computation cost in MicroCash, but also the bandwidth cost of exchanging lottery tickets and the amount of data to be logged on the blockchain.
7.2.3 Size of escrows on the blockchain
One major difference between concurrent and sequential micropayment schemes is that the former need a new escrow after each winning ticket. Additionally, to issue tickets in parallel at a fast rate in sequential schemes, the customer needs a large number of escrows. This is because a new ticket cannot be issued using the same escrow until it is confirmed that the prior ticket did not win, which requires the customer to wait for the merchant to announce the lottery result. Hence, even if the customer is capable of generating tickets at a fast rate, it might slow down just because it does not have enough escrows to allow this rate. Furthermore, even if the customer is willing to create larger number of escrows, this dramatically increases the overhead. Each of these escrows requires an individual escrow creation transaction, which in turn requires paying a transaction fee and logging on the blockchain.
For example, to support the ticket issue rates reported in Table 2, a MICROPAY customer would need a large number of escrows. The exact number of escrows needed depends on the network latency and a merchant’s ticket processing rate. Using the average US RTT of 31 ms , and the processing time of the tickets, in the best case an escrow in MICROPAY can be used to issue 32 tickets per second (this is in case none of these ticket win or only the last one wins). Therefore, a customer in MICROPAY would need 60, 1019, or 653 escrows per second to support the generation rates for signature schemes ECDSA (secp256k1), ECDSA (P-256), or EdDSA (Ed25519), respectively, as found in Table 2. On the other hand, a customer in MicroCash would need only one escrow with the proper balance to pay at any given ticket rate. As such, MicroCash dramatically reduces the amount of data logged on the blockchain.
Key Takeaway: Supporting micropayment concurrency dramatically reduces the amount of escrow data on the blockchain.
7.3 Micropayments in Real World Applications
To ground our results in real world numbers, we examined two micropayment applications: online gaming and peer-assisted content delivery networks (CDNs). We computed the overhead of processing micropayments with parameter values derived based on the service price and workload in these applications. This is done for three cases: Bitcoin without employing any micropayment scheme, Bitcoin with MICROPAY, and Bitcoin with MicroCash.
To compute the overhead, we estimated the service costs and loads from real world sources. For online gaming, we used data from the popular game Minecraft as an example. The average mid tier cost of playing this game for 8 players is around $12 per month . We considered 1000 players distributed among 125 servers. This means that the service price is $0.034722 per minute (or $0.000579 per second) for the 1000 players.
For the peer-assisted CDN application, we considered a content publisher that hires peers as caches to distribute the content for its clients. Suppose a publisher wants to serve content at roughly 1Gpbs. Such a service costs around $17,312 monthly in the US , and hence, on average, the service cost per second is $0.006679. The publisher will provide a lottery ticket to a cache for each 1MB data chunk it serves. Thus, to support a rate of 1Gbps, the publisher will issue 128 tickets per second.
With these combined values, it is possible to compute the lottery winning probability and the currency value of a winning ticket . The former is done by determining the total transaction fee to be paid for the miners (per second), and then computing in a way that ensures the fees paid when claiming winning tickets (per second) do not exceed this value. We consider the fee to be 2% of the service cost paid per second  (at a minimum)999In both examples, we assume that the players and the publisher will pay at the same price offered by a gaming or CDN company.. For the fee of redeeming a winning ticket, we use the median transaction fee in Bitcoin, which is around $0.068 as of late January 2019 .
Based on the above, the fees per second are equal to the expected number of winning tickets per second multiplied by the transaction fee that the miners charge. So in Minecraft, can be computed as , where 16.67 is the number of tickets issued by all players per second (the 1000 players issue 1000 tickets per minute). Similarly, a publisher in our CDN example can compute as .
As for computing , it can be estimated by dividing the service cost by the number of winning tickets (both per second). In Minecraft, this produces , and it is $3.4 in the CDN application.
For the escrow setup, in Minecraft, we assume that each player creates one escrow per month. For the CDN application, we consider a publisher creating one escrow per day. In addition to that, in MICROPAY a new escrow must be created after each winning ticket101010To simplify the discussion in this section, and since the goal is to evaluate the financial and bandwidth cost of the payment setup rather than its computational cost, we allow MicroCash to operate with a non-integer number of winning tickets per round. This is done by adopting the lottery protocol with independent ticket winning events described in Appendix I..
It should be noted that in both the gaming and CDN examples, we only account for the cost of operating the service. Factors such as funding Minecraft’s development team (which was presumably supported by the initial purchase of the game) or produce the video content that was served by the CDN are not considered here. In practice, operational costs are minimal compared to the development cost which can run in the hundreds of millions of dollars .
We used this setup to compute overhead of micropayment processing for both applications, as shown in what follows.
7.3.2 Online Gaming Application
We used the configuration parameters outlined earlier to compute the transaction fees and the bandwidth cost of micropayment processing in this application. The results are found in Table 3.
|Winning tickets / sec||N/A||0.000167||0.000167|
|Escrows / sec||N/A||0.000552||0.000386|
|Transaction fees / round||$680||$0.029341||$0.022541|
|Bandwidth between customers and miners||3,333 bps||1.105 bps||1.009 bps|
|Bandwidth between customers and merchants||N/A||36,533 bps||14,667 bps|
|Bandwidth between merchants and miners||N/A||0.807 bps||0.523 bps|
|Delta blockchain size / round||2.38 MB||0.000137 MB||0.00011 MB|
We start with the number of transactions the miners process. In Bitcoin, all micropayments are processed as individual transactions. In contrast, with MICROPAY and MicroCash, only winning tickets and escrow creation transactions will be sent to the miners. MICROPAY is a sequential scheme, so every time a ticket wins the escrow breaks. Therefore, the number of escrows per round equals to the expected number of winning tickets per round. In MicroCash, however, a player may use one escrow for the duration of their subscription (a month in our case). Consequently, and as the table shows, MicroCash generates 25% fewer transactions, accounting both escrow and winning ticket redemption.
The number of transactions affects the amount of fees miners charge for processing. As the table shows, processing micropayments individually is expensive, costing $680 per round (a transaction costs around $0.068 as mentioned previously). However, in MicroCash and MICROPAY, the fees are much lower because they are paid only when claiming winning tickets or creating escrows. Furthermore, due to the reduced number of escrows, MicroCash incurs the least fees, costing around 75% of what MICROPAY incurs.
In calculating the bandwidth overhead, in Bitcoin players send all micropayments directly to the miners. They do not send anything to the servers nor do the servers send anything to the miners. On the other hand, in MICROPAY and MicroCash, all lottery tickets are exchanged locally between players and servers. Only escrows and winning tickets will be sent to the miners. Based on the average size of a Bitcoin transaction (around 250 bytes as mentioned earlier), the size of an escrow transaction in MICROPAY is around 250 bytes, wheares in MicroCash it is around 327 bytes. This is because our scheme adds additional fields to store the payment setup parameters as described in Section 4.1. For the size of a claim transaction, beside the transaction average size, we add the size of a winning ticket (110 bytes in MicroCash and 355 bytes in MICROPAY). As shown in Table 3, the bandwidth cost between players/servers and the miners in Bitcoin is more than 3000x the cost incurred in MICROPAY or MicroCash. This shows the great benefit of processing payments locally using a micropayment scheme.
The bandwidth cost of the miners can be used to quantify the increase in the blockchain size per round since all transactions sent to the miners are logged on the blockchain. As the table shows, logging all micropayments is prohibitive as it requires more than 2 MB per round. In Bitcoin, only one block of size 1MB can be published per round, meaning that paying at this relatively slow rate cannot be supported. On the other hand, this overhead is reduced to less than 0.00014 MB in MICROPAY and MicroCash.
7.3.3 Peer-assisted CDN Application
Because of the larger workload involved, our results show micropayment schemes offer even more dramatic benefits when used to serve CDN traffic. As Table 4 shows, in plain Bitcoin, miners process 128 transactions per second, which is the number of data chunks caches serve per second. This number drops to fractions in MICROPAY, and goes further down an 50% in MicroCash. This is reflected in both the transaction fees and the blockchain size.
|Winning tickets / sec||N/A||0.001964||0.001964|
|Escrows / sec||N/A||0.001976||0.000012|
|Transaction fees / round||$5,222||$0.160769||$0.08062|
|Bandwidth between customers and miners||256,000 bps||3.95 bps||0.165 bps|
|Bandwidth between customers and merchants||N/A||280,576 bps||112,640 bps|
|Bandwidth between merchants and miners||N/A||9.508 bps||6.16 bps|
|Delta blockchain size / round||18.31 MB||0.000963 MB||0.000452 MB|
Processing micropayments individually costs more than $5,000 per round, while these fees drop to cents when a micropayment scheme is employed. It also requires logging more than 18 MB per round on the blockchain. This overhead is reduced to around 0.001 MB in MICROPAY and 0.0005 in MicroCash. This shows the great advantage of employing a micropayment scheme for heavy loaded applications, and the benefit of supporting micropayment concurrency (where MicroCash reduced the additional blockchain size and the total fees by around 50%).
In terms of bandwidth overhead between participants, in plain Bitcoin the miners have at least 19,000x the cost when a micropayment scheme is employed. Moreover, MicroCash incurs almost no bandwidth cost between the publisher and the miners. This is despite the fact that in this application, an escrow creation transaction in MicroCash is larger than the one needed in MICROPAY (such a transaction is around 1,783 bytes in MicroCash, where we consider 45 beneficiary caches to support the rate of 1Gbps111111We use the average upload speed in the US , which is 22.79 Mbps. Hence, to serve 1Gbps, a publisher needs 45 caches.). Such a minimal cost for MicroCash is due to payment concurrency as it allows creating a one long-lifetime escrow instead of large number of escrows, as MICROPAY requires. Even for ticket exchange, MicroCash incurs a lower cost although both schemes have the same number of tickets. This is because a ticket (on-chain or off-chain) in MicroCash is substantially smaller than in MICROPAY.
Key Takeaways: Micropayments are absolutely critical to be able to process small transactions in modern applications. MicroCash is cost efficient enough to be used in online gaming and content distribution. Concurrent use of a single escrow decreases the total data added to the blockchain by roughly half.
In this paper, we introduce MicroCash, the first decentralized probabilistic framework that supports concurrent micropayments. The design of MicroCash features an escrow setup and ticket tracking mechanism that permit a customer to rapidly issue tickets in parallel using only one escrow. Moreover, MicroCash is cost effective as it implements a non-interactive lottery protocol for micropayment aggregation that is based solely on secure hashing. When compared to the sequential scheme MICROPAY, MicroCash has substantially higher payment processing rates and much lower bandwidth and on-chain traffic. This demonstrates the viability of employing our scheme in large-scale micropayment applications.
-  Amazon CloudFront Pricing. https://aws.amazon.com/cloudfront/pricing/.
-  At&t Network Averages. https://ipnetwork.bgtmo.ip.att.net/pws/averages.html.
-  Average Credit Card Processing Fees. https://www.cardfellow.com/blog/average-fees-for-credit-card-processing/.
-  Bandwidth upload speed in the US. https://www.recode.net/2017/9/7/16264430/fastest-broadband-speeds-ookla-city-internet-service-provider.
-  Bitcoin transaction fees. https://bitinfocharts.com/bitcoin/.
-  Bitcoinj. https://bitcoinj.github.io/working-with-micropayments.
-  BitInfoCharts, Bitcoin avg. transaction fee. https://bitinfocharts.com/comparison/bitcoin-transactionfees.html.
-  BloXroute: A Scalable Trustless Blockchain Distribution Network. https://bloxroute.com/wp-content/uploads/2018/03/bloXroute-whitepaper.pdf.
-  Board of Governers of the Federal Reserve System, press release June 2011. https://www.federalreserve.gov/newsevents/pressreleases/bcreg20110629a.htm.
-  Board of Governers of the Federal Reserve System, Regulation II. https://www.federalreserve.gov/paymentsystems/regii-about.htm.
-  EIP 665: Add precompiled contract for Ed25519 signature verification. https://eips.ethereum.org/EIPS/eip-665.
-  GameServers: Minecraft. https://www.gameservers.com/game_servers/minecraft.php.
-  ”lightning network will be highly centralized”. https://cointelegraph.com/news/lightning-network-will-be-highly-centralized-gavin-andresen.
-  Minecraft. https://minecraft.net/en-us/.
-  Monero: Privacy in the blockchain. https://eprint.iacr.org/2018/535.pdf.
-  NSEC5-Crypto. https://github.com/fcelda/nsec5-crypto.
-  Ripple to use Ed25519. https://ripple.com/dev-blog/curves-with-a-twist/.
-  Signatures in Stellar. https://www.stellar.org/developers/guides/concepts/multi-sig.html.
-  Supplemental Material. https://drive.google.com/file/d/1hAeTjMowyalt9pvJbmu1lGEXphFunFmQ/view?usp=sharing.
-  TradeBlock: Analysis of Bitcoin Transaction Size Trends. https://tradeblock.com/blog/analysis-of-bitcoin-transaction-size-trends.
-  Video Games Development Costs. https://en.wikipedia.org/wiki/List_of_most_expensive_video_games_to_develop.
-  Almashaqbeh, G., Bishop, A., and Cappos, J. Abc: A threat modeling framework for cryptocurrencies. In IEEE INFOCOM Workshop on Cryptocurrencies and Blockchains for Distributed Systems (CryBlock) (2019).
-  Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and Yang, B.-Y. High-speed high-security signatures. Journal of Cryptographic Engineering 2, 2 (2012).
-  Boneh, D., Bonneau, J., Bünz, B., and Fisch, B. Verifiable delay functions. In Annual International Cryptology Conference (2018), Springer.
-  Chiesa, A., Green, M., Liu, J., Miao, P., Miers, I., and Mishra, P. Decentralized anonymous micropayments. In Annual International Conference on the Theory and Applications of Cryptographic Techniques (2017), Springer, pp. 609–642.
-  Decker, C., and Wattenhofer, R. A fast and scalable payment network with bitcoin duplex micropayment channels. In Symposium on Self-Stabilizing Systems (2015), Springer, pp. 3–18.
-  Goldberg, S., Naor, M., Papadopoulos, D., and Reyzin, L. Nsec5 from elliptic curves: Provably preventing dnssec zone enumeration with shorter responses. IACR Cryptology ePrint Archive 2016 (2016), 83.
-  Green, M., and Miers, I. Bolt: Anonymous payment channels for decentralized currencies. Tech. rep., Cryptology ePrint Archive, Report 2016/701, 2016.
-  Heran, M., and Spilman, J. Bitcoin contracts. https://en.bitcoin.it/wiki/Contract, 2012.
-  Malavolta, G., Moreno-Sanchez, P., Kate, A., Maffei, M., and Ravi, S. Concurrency and privacy with payment-channel networks. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security (2017), ACM.
-  Micali, S., and Rivest, R. L. Micropayments revisited. In Cryptographers’ Track at the RSA Conference (2002), Springer, pp. 149–163.
-  Miller, A., Bentov, I., Kumaresan, R., and McCorry, P. Sprites: Payment channels that go faster than lightning. arXiv preprint arXiv:1702.05812 (2017).
-  Pass, R., and Shelat, A. Micropayments for decentralized currencies. In CCS (2015), ACM, pp. 207–218.
-  Poon, J., and Dryja, T. The bitcoin lightning network: Scalable off-chain instant payments. Technical Report (draft) (2015).
-  Rivest, R. L. Electronic lottery tickets as micropayments. In International Conference on Financial Cryptography (1997), Springer, pp. 307–314.
-  Rivest, R. L. Peppercoin micropayments. In International Conference on Financial Cryptography (2004), Springer, pp. 2–8.
-  Sapirshtein, A., Sompolinsky, Y., and Zohar, A. Optimal selfish mining strategies in bitcoin. In International Conference on Financial Cryptography and Data Security (2016), Springer.
-  Sasson, E. B., Chiesa, A., Garman, C., Green, M., Miers, I., Tromer, E., and Virza, M. Zerocash: Decentralized anonymous payments from bitcoin. In IEEE SP (2014).
-  Wheeler, D. Transactions using bets. In International Workshop on Security Protocols (1996), Springer, pp. 89–92.
I Lottery Protocol With Independent Ticket Winning Events
In this section, we describe a variant of our lottery protocol that follows the same paradigm found in previous works [39, 35, 33, 25]. That is, each lottery ticket enters the lottery independently of other tickets. Thus, there is a chance that all tickets in a round may win or all lose with an expected number of winning tickets of per round. This protocol can be used in applications where it is infeasible to set , , and in a way that produces an integer number of winning tickets per rounds, such as the real life applications discussed in Section 7. In this section, we first introduce this protocol variant, after which we derive bounds for the payment and penalty escrow balances, denoted as and , respectively, under the modified protocol setup.
i.1 Lottery Protocol Design
The lottery protocol with independent ticket winning events is similar to the one introduced in Section 4.3 in the sense that it is based solely on secure hashing, requires the miners to compute a VDF value that is used in the lottery draw, and defines parameters and to control when a ticket can enter the lottery, and when it can be redeemed if it wins.
However, this protocol differs from one with an exact win rate in three aspects. First, given that each ticket enters the lottery independently of others, there is no restriction that be an integer value. Hence, there is no need for the parameter . This also affects how the lower bound of is computed, as we will see in Section I.3. Second, given that there is a chance that more tickets than expected (i.e., ) may win, we require that the payment escrow cover all winning tickets with very high probability, at least for some small value such as . This affects how the value of is computed as we will see in Section I.2. And third, we need a different lottery draw mechanism to allow tickets to enter independently. We elaborate on this mechanism in what follows.
As before, a merchant keeps a ticket until its lottery draw time , which is exactly rounds after its issue time. Then, after observing the VDF value of the block mined at that time, the merchant computes the following quantity over the ticket (where is a hash function):
A ticket wins if the least significant word of is less than . Therefore, within the precision allowed by a 32-bit number, a ticket will have a chance of winning.
This process is clarified by the example depicted in Figure 6. As shown, the ticket has been issued at round 30, and hence, it entered the lottery at round 40. The VDF value of the block with index 40 appears inside block 41. Based on the value of , the ticket in the figure is a winning one.
As before, involves only the ticket fields that are part of the escrow state that the issuing customer cannot manipulate. These fields do not include the merchant recipient address, which means that a ticket’s chance of winning the lottery is not affected by who owns it. Hence, this protocol variant has the same security properties as the protocol with an exact ticket win rate.
In this section, we show how to compute the payment escrow balance for the lottery protocol with independent ticket winning events that satisfies the coverage rule. This computation is done using a probabilistic analysis that relies on modeling the payment process in MicroCash under this protocol. In what follows, we state and prove a formula to calculate this balance.
For an escrow with lifetime rounds, ticket issue rate , lottery winning probability , winning ticket currency value , and parameter , where , , and , the value of needed to cover all winning lottery tickets with probability at least under MicroCash setup with independent ticket winning events is given by:
Given that we work in the random oracle model, and that we model the block hashes on the blockchain as a uniform distribution, lottery winning events are independent and can be modeled as Bernoulli trials. This means that the total number of winning tickets tied to an escrow with lifetime rounds, ticket issue rate , and lottery winning probability
, is a binomial random variable parameterized byand a number of trials .
Requiring to cover all winning tickets with probability means that must contain sufficient currency to pay a number of winning tickets that hits the th percentile of the above binomial distribution, i.e., = . This number can be computed as:
where is the inverse of the cumulative distribution function (CDF) of the binomial distribution parameterized by and a number of trials at the value . Substituting this expression in = produces the formula stated in the theorem above, which completes the proof. ∎
i.3 Computing a Lower Bound for
In this section, we compute a lower bound for the penalty
deposit required to deter cheating under the lottery
protocol with independent
ticket winning events. This is done using a similar approach to the
one used in Appendix 5, as it applies the
same utility function definition and covered malicious strategies.
In what follows, we present this analysis, which includes stating and proving a
lower bound for .
Game setup. Similar to before, we have a single player game in which a malicious customer applies the ticket duplication strategy. However, we do not have the concept of fat rounds, where a round in this protocol is the exact time needed a single block on the blockchain. This means that the cheating detection period is + rounds. Furthermore, given that tickets enter the lottery independently of each other, there is a chance that none of the tickets will win. Thus, duplicating all tickets in a round is an option for a rational customer. For this reason, in each round of this game, a malicious customer may decide to duplicate sequence numbers, such that .
|The number of tickets that can be issued per round, such that and .|
|The lottery draw period in rounds, such that and .|
|The ticket redemption period in rounds, such that and .|
|Number of duplicated tickets in round , such that .|
|The escrow lifetime in rounds, such that and .|
Additional utility gain analysis. We now state and prove a lower bound for based on the above game setup.
For the game and escrow setup described above, issuing invalid or duplicated lottery tickets is less profitable in expectation than acting in an honest way if:
In MicroCash, a customer can create an escrow with an round lifetime. All tickets issued in a round enter the lottery after rounds, and all winning tickets will expire after rounds from their lottery draw time.
During each round of an escrow lifetime, an honest customer can issue up to tickets with unique sequence numbers. As before, each ticket has an expected value of coins, which corresponds to the service value a customer obtains for handing out this ticket.
On the other hand, for each round , a malicious customer would decide to duplicate tickets, where . If none of the duplicated tickets win, which happens with probability , this customer stays in the system and obtains an additional utility gain of over what an honest customer would obtain. On the other hand, if any of these tickets win the lottery at round , which happens with probability , the customer will be detected at round (the latest). This reduces its additional utility by since the miners will revoke its penalty escrow. At this time, the malicious customer still has rounds to issue tickets from the time of learning that it will be caught. Therefore, this customer will choose to duplicate all tickets in these rounds as described before.
Similar to Section 5, we use a decision process diagram that captures the decisions a malicious customer makes over an escrow lifetime. As an example, we consider a simple case where we have an escrow with a 3 round lifetime, rounds, and round. The decision process for this setup is captured in Figure 7.
As shown, the only difference from what we saw in Figure 5, beside dealing with normal rounds, is the cheating detection probability. So, this process follows the same logic for deriving the additional utility at each round based on the likelihood that the cheating will be caught.
We utilize the same recursive idea in analyzing the above decision process. During the first round of an round escrow, a malicious customer will decide to duplicate tickets. If any of these tickets wins at round , cheating will be detected. Thus, the customer will duplicate all tickets for the next rounds and will pay the penalty . This means that with probability , the utility gain is .
If none of the duplicated tickets wins the lottery, the customer stays in the system. This means that with probability , the utility gain of this customer will be , where the second term denotes the expected utility gain of a malicious customer in an round escrow.
Based on the above, we can express as follows:
As before, we have since the penalty for an round escrow has been configured in a way that makes cheating unprofitable. Hence, and by requiring to deter cheating, we find that:
As an example, consider an escrow with a 200 round lifetime, tickets, , coin, , , , and . Applying equation 8 produces coins, and applying equation 10 produces coins. Comparing these values to the ones obtained for the same example in Section 5, where coins and , we realize that these values re very close. This is because this example uses a long lifetime escrow and a larger ticket issue rate, which makes these values as close as possible to the expected values. Consequently, for short escrow lifetime and lower ticket issue rate, the difference will more dramatic. That is, the bounds for a lottery protocol with an exact win rate will be much lower, reducing the collateral cost for the customer.