This is the preprint version. Please see ACM for the the final official version.

ZeroLender: Trustless Peer-to-Peer Lending Platform

Yi Xie† Joshua Holmes† Gaby G. Dagher∗ Computer Science Department Computer Science Department Computer Science Department Boise State University Boise State University Boise State University

ABSTRACT Peer-to-peer (P2P) economy, also referred to as sharing economy, Since its inception a decade ago, Bitcoin and its underlying is a decentralized business model whereby individuals deal with technology have been garnering interest from a large spectrum of goods or services directly with each other without any intermediary. financial institutions. Although it encompasses a currency, apay- P2P lending is an emerging branch of P2P economy that enables ment method, and a ledger, Bitcoin as it currently stands does direct matching of borrowers and lenders without holding the loan not support lending. In this paper, we present a platform on an intermediary balance sheet. P2P lending platforms generate called ZeroLender for peer-to-peer lending in Bitcoin. Our protocol revenue from origination fees that are charged to borrowers, service utilizes zero-knowledge proofs to achieve unlinkability between fees interest that are charged to lenders, as well as from additional lenders and borrowers while securing payments in both directions charges such as late fees [7]. The P2P leading model is illustrated against potential malicious behaviour of the ZeroLender as well as in Figure 1. the lenders, and prove by simulation that our protocol is privacy- preserving. Based on our experiments, we show that the runtime P2P Lending and transcript size of our protocol scale linearly with respect to the Platform number of lenders and repayments. Lend lend

Loan Principle + 1 INTRODUCTION Repayment Lenders/investors Interest Borrowers In the last decade, have emerged as the solution to low-fee decentralized banking with relatively quick settlement time. Prior to the introduction of blockchain, the main problem Figure 1: Illustration of the peer-to-peer lending model every payment network was concerned about is how to prevent double-spending, i.e., the same money cannot be spent in more Some P2P lending companies 2, such as BitBond 3 and BTCPOP 4, than one payment. In the traditional (centralized) banking systems, crowdsource loans from lenders around the world while offering double-spending is typically prevented using central databases that low interest rates to borrowers. Although these platforms accept log transactions and balance the ledgers. Bitcoin [15] is a peer-to- payments from lenders in bitcoin, the lending process is handled peer network that achieves consensus about its distributed ledger off-chain using fiat money, and requires the lenders to fully trust without a central authority. Transactions in Bitcoin are verified by the lending platform to manage their bitcoin assets. network nodes and recorded on a shared public ledger. Since Bitcoin In this paper, we present a trustless peer-to-peer lending platform was introduced, many other blockchain-based cryptocurrencies called ZeroLender. The borrower is assumed to be an established have been created [22][18][19]. Despite of the prosperity of altcoins, entity (e.g. business) that uses the ZeroLender platform to obtain Bitcoin still by far has the largest network adoption, as reflected in (borrow) an amount of bitcoins, and later returns the amount with its market cap. Currently, Over 100,000 merchants worldwide accept an agreed upon interest. The lenders are Bitcoin users who aim payments in bitcoins, including Microsoft online store, Subway, as to lend (invest) their bitcoins for a certain period of time to gain well as the online electronics retailer Newegg1. interest on the amount they are lending. Our platform ensures that individual lenders can access all lending opportunities and ∗Corresponding Author ( ) 1Places that accept Bitcoin: http://spendbitcoins.com/places/ securely transfer bitcoins to the borrowers and receive repayments back from the borrows through ZeroLender. Although this paper † These authors contributed equally. focuses on P2P lending, our protocol is not limited to this case, as it could be directly (or with minimal modifications) applied to other Permission to make digital or hard copies of all or part of this work for personal or related sharing economy models, such as crowdfunding [12] and classroom use is granted without fee provided that copies are not made or distributed group buying business [1]. Based on the characteristics of the P2P for profit or commercial advantage and that copies bear this notice and the full citation ZeroLender 5 on the first page. Copyrights for components of this work owned by others than ACM lending process, consists of three phases . First, the must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a 2Bitcoin Market Journal: https://www.bitcoinmarketjournal.com/bitcoin-borrowing/ fee. Request permissions from [email protected]. 3BitBond: https://www.bitbond.com/ CODASPY ’20, March 16–18, 2020, New Orleans, LA, USA 4BTCPOP: https://btcpop.co/home.php © 2020 Association for Computing Machinery. 5Since this paper focuses on the privacy of the transactions, some detailed P2P lending ACM ISBN 978-1-4503-7107-0/20/03...$15.00 processes such as borrower’s application acknowledge, credit, approval, and loan https://doi.org/10.1145/3374664.3375735 management are ignored. negotiation phase, where the borrower and ZeroLender agree on In this paper, ZeroLender protocol only utilizes the three most the required investment amount, loan interest, repayment term, common types of transactions: P2PKH, P2SH, and Multisig. payment addresses, repayment plan, etc. Second, the lending phase, where ZeroLender transfers to the borrower the requested loan 2.2 CoinSwap in return for simultaneously receiving the exact amount of bit- Greg Maxwell presented a protocol called CoinSwap [6], where coins from the lenders. Third, the returning phase, where for each Alice can pay Bob through Carol and Carol can not steal the coins scheduled repayment, and in order for the borrower to release the from either of them. The protocol requires four published trans- ZeroLender repayment bitcoins to , the latter must prove to the actions. All published transactions look like regular 2-of-2 escrow former that the appropriate amount of bitcoins was sent to each transactions (two escrow payments, two escrow releases) as long lender according to the repayment plan. as each party follows the protocol. CoinSwap has three phases: The proposed ZeroLender platform in this paper satisfies the (1) Escrow phase: Alice and Carol set up an escrow through 2-of-2 following properties: multisig account with Alice’s coins on the blockchain time- • No direct connection. The Borrowers announce their investment locked to a certain period of time window. Carol and Bob repeat opportunities and the lenders invest in projects and receive their the same process with carol’s coins but shorter time window. repayments through the ZeroLender platform, without any need (2) Warranty phase: Carol sends a transaction from the escrow ad- for interaction between the lenders and the borrowers. dress between her and Bob locked by a hash value, and without • Undeniability. ZeroLender can not , nor can it dictate or change posting it on blockchain. Similarly, Alice sends another trans- the amount the lender has invested. action from the escrow address between her and Carol locked • Fair Return. Each lender is guaranteed to receive a proportional by the same hash aforementioned value. If Bob gets paid from amount from each net repayment made by the borrower through Carol, Carol will be guaranteed to get payment from Alice. ZeroLender. Individual repayments are not necessarily equal, but (3) Payment phase: Carol signs and releases the transaction directly, instead fall in to an acceptable range to make them harder to then Alice does same. Both transactions will be posted to the track on the blockchain, and ZeroLender cannot decide who is blockchain. assigned which repayment plan. A key concept in this protocol is the warranty phase. Transactions • Unlinkability.There is no linkage between lenders’ accounts and are protected by the knowledge of the preimage of a hash. A varia- borrower’s accounts to the public (external hiding) or to each tion of the CoinSwap protocol integrating zero-knowledge proofs other (internal hiding). with the protocol is proposed in ZeroLender’s Lending phase. • Privacy. Only ZeroLender has knowledge of the individual loan amount of each lender, and the Bitcoin addresses of the lenders 2.3 Pedersen Commitment and borrowers . In this paper, Pedersen Commitment [16] is used to commit rel- Note that if ZeroLender is defined as a financial institution, it can evant messages such as investment amount, returning amount, satisfy the Know Your Customer (KYC) regulation by identifying and repayment receiving addresses from ZeroLender. The commit- and verifying the identities of its clients (lenders and borrowers). ments rely on two generators 𝑔 and ℎ such that no party knows Further regulation discussion is beyond the scope of this paper. the discrete log 𝑎 between 𝑔 and ℎ. The commitments hide 𝑥 using a random number 𝑟 ∈ Z𝑞, where 𝑞 is the order of the group used. Limitations. While our protocol is secure against malicious The commitments are constructed as follows6: lenders and ZeroLender, the borrower is assumed to be covert and must be held accountable outside the protocol for any dishonest 𝑥 = 𝑔𝑥 · ℎ𝑟 behavior. The borrower’s bitcoin addresses and transactions remain These commitments are perfectly hiding because for any pair private, but its business information is public to all lenders. In   (𝑥,𝑟) there exists an 𝑟 for every 𝑥 ∈ Z𝑞 that also fulfills this rela- addition, the borrower does not have the flexibility to make partial   tionship. However, finding another pair (𝑥 ,𝑟 ) without knowing 𝑎 nor early repayments. For more details, please see Section 6.0.2. is at least as hard as finding 𝑎 from 𝑔 and ℎ, i.e. the Elliptic Curve Discrete Log Problem. 2 BACKGROUND 2.1 Bitcoin 2.4 Zero-Knowledge Proof Bitcoin is a digital currency with no physical backing that can A zero-knowledge proof is a method by which one party can prove be sent electronically from one user to another, anywhere in the to another that a given statement is true, without conveying any world. The minimum denomination of Bitcoin is 0.00000001 bitcoin. additional information apart from the fact that the statement is The system is run by a decentralized network of nodes around the indeed true. In the Negotiation, Lending and Returning phases, world that keep track of all Bitcoin transactions. All transactions zero-knowledge proofs are used to prove each statement without ZeroLender must to be submitted to the network and be verified by at least half revealing related parties’ information. utilizes the Fiat- the network to be accepted as a part of a block in the blockchain. Shamir Heuristic [5] to make these protocols non-interactive. Currently, only five standard Bitcoin transactions are accepted by 6We utilize the elliptic curve used in Bitcoin, secp256k1, where 𝑔 is the standard the network: Pay To Public Key Hash (P2PKH), Pay To Script Hash Bitcoin generator. Though we use elliptic curves, we use the more conventional 𝑥 (P2SH), Multisig, Pubkey, and Null Data. notation 𝑦 = 𝑔 instead of 𝑌 = 𝑥 · 𝐺. 2.4.1 Schnorr’s Protocol. ZeroLender leverages one of the simplest Therefore, at least one of the proofs must be genuine. However, and frequently used protocols, Schnorr protocol [20] (Protocol 1). due to the nature of simulators, there is no method with which to 𝑥 It allows a party with a public value 𝑦 = 𝑔 , where 𝑥 is secret to differentiate the true proof from the simulated proofs. prove knowledge of 𝑥 without revealing any information about 𝑥. ZeroLender uses Schnorr’s protocol to prove that a Pedersen 3 PROTOCOL OVERVIEW commitment hides a specific value and to prove that a Pedersen In this section, we provide an overview of the three main phases of commitment hides the same value as another commitment. the ZeroLender protocol.

Schnorr’s Protocol [20] 3.1 Negotiation Phase 𝑥 Input: Public: The exponential 𝑦 = 𝑔 This is the investment project’s initial setup phase. In this phase, Private : 𝑥, the discrete log of 𝑦 the borrower discusses the loan with ZeroLender, and if accepted, a (Prover) loan information is posted to the bulletin board BB by ZeroLender. 𝑥 Output: Public: Verification that the Prover knows . In addition, a unit-based raw repayment plan is agreed upon be- 𝑟 (1) The Prover generates a random number and calculates tween ZeroLender and the borrower to decide each repayment 𝑎 = 𝑔𝑟 amount in the returning phase. (2) The Prover sends 𝑎 to the Verifier. 𝑐 (3) The Verifier generates a random challenge and sends it 3.2 Lending Phase to the Prover. (4) The Prover computes 𝑧 = 𝑟 + 𝑐 · 𝑥. In this phase, our protocol integrates ZKP with the CoinSwap pro- ZeroLender (5) The Prover sends 𝑧 to the Verifier. tocol to detect if over-collect funds, given that there 𝑧 𝑐 (6) The Verifier accepts if 𝑔 = 𝑦 · 𝑎. is no linkage between the lenders and the borrower. The lending phase can be split into three main steps: Schnorr’s Protocol’s Simulator ZeroLender (1) The Prover* uses the Verifier’s random number generator to generate the (1) Fundraising. Each intended lender and creates Verifier’s challenge 𝑐. a 2-of-2 multisig escrow account with lender’s coin on the (2) The Prover* randomly generates the response 𝑧. 𝑧 −𝑐 blockchain and is timelocked to a certain period of time in (3) The Prover* calculates 𝑎 = 𝑔 · 𝑦 . (4) Run the protocol from protocol step 2, skipping step 4, instead using the case a party has to abort the protocol. When the total fund generated 𝑧. matches the requested loan amount, ZeroLender escrows re- quested loan amount to a timelocked 2-of-2 multisig account shared by ZeroLender and the borrower. ZeroLender commits Protocol 1: Schnorr’s Protocol the ID of each potential lenders, project ID, lending amount, repayment acceptance addresses, among other information, to BB. 2.4.2 Logical Composition of Zero Knowledge Proofs. Logical com- (2) Securing the fund. Lenders and ZeroLender setup a mutu- position allows us to answer more complicated questions. We ally signed redeeming hash-locked transaction from the escrow can logically compose any Zero Knowledge Proof using AND or account. Similarly, ZeroLender and the borrower setup a mutu- OR [8] [4]. ally signed escrow redeeming transactions that share the same hash-lock (not posted on blockchain). With all hash-locked Zero Knowledge AND. It is a construction where the same chal- transactions in hand, ZeroLender works with the lenders to lenge is shared between multiple proofs. To accomplish this, the generate the final repayment plan. Prover creates the initial communications of each proof, then re- (3) Deposition. ZeroLender directly signs the escrow account shared ceives the challenge, then computes the response for each proof. with the borrower, and then lenders also sign their escrow ac- The Verifier accepts if all the proof transcripts are valid. counts between them and ZeroLender. Zero Knowledge OR. Zero Knowledge OR is a more complicated construction. The Prover generates internal challenges for all but 3.3 Returning (Repayment) Phase one of the proofs and simulates the initial communications for these In this phase, the borrower starts to repay the loan to the lenders. proofs. The remaining proof must be the one that the Prover can The protocol consists of three main steps: actually prove, so the Prover calculates the appropriate initial com- munications. The Prover now receives the challenge and computes (1) Creating repayment transaction. ZeroLender created a trans- the remaining internal challenge for the true proof such that all action to each eligible lender to pay her according to her lending of the internal challenges XOR [8] [4] to the challenge. They then amount and the repayment amount. complete the simulated proofs and the real proof and the Verifier ac- (2) Proof of transaction. ZKP is used in this step for ZeroLender cepts if all the proof transcripts are valid and the internal challenges to prove to the borrower that it paid all lenders the proper XOR to the challenge. amount, and the total amount matches the repayment amount Since the Prover can not know all of the internal challenges in minus its fees. the initial communication phase, at least one of the proofs must (3) Finishing repayment transaction. If the borrower is able to have been executed without prior knowledge of that challenge. verify that ZeroLender prepaid each lender according to the protocol, the borrower sends a transaction to ZeroLender to 5.1 Negotiation Phase complete one repayment cycle. First, the borrower B submits its loan application to ZeroLender Z. Both of them agree on the following loan information: total 4 SECURITY MODEL amount of loan 푀, numbers of repayment (loan term) 푛푡 , and inter- Our security model is as follows: est rate 퐼. All these loan information along with B’s public entity Second Z • Lenders and borrowers are protected against malicious ZeroLender. information are posted to BB for lender’s review. , creates B Third • The lenders are malicious adversaries. Privacy of ZeroLender and 2-of-2 multisig escrow account addr(Z,B) with . , based the borrower from the lenders or external parties is preserved. on the interest rate and loan terms, a repayment plan must be set • The protocol is secure against collusion between ZeroLender and upfront. A typical P2P lending platform has fixed monthly repay- the lenders. ment calculated based on the interest rate and loan terms. After • The borrower is a covert adversary. Privacy of ZeroLender and lending platform gets a repayment from borrower, the platform lenders from the borrower is preserved. distributes the repayment to the lenders based on their lending amount. Using this model, the fixed amount transaction impacts 5 SOLUTION: ZeroLender PROTOCOL the privacy of all parties since these transactions have very obvi- ous patterns (fixed amount, fixed transaction timeline, etc.) onthe Our goal is to allow the lenders to transfer investment coins to the blockchain. To overcome this shortcoming, we introduce variable borrower, and the borrower distribute repayments to all lenders, T 푛 푏 ,푏 ,푏 ,...,푏  B repayment list of 푡 : 1 2 3 푛𝑡 agreed upon by both while achieving unlinkability. Without a loss of generality, we as- and Z, then committed and posted to BB. In T , each repayment sume there are 푛퐴 lenders and one borrower. We separate the pro- 푏 푗 varies in a certain range Δ, but the total repayment amount is tocol into negotiation phase, lending phase, and returning phase.We still equal to the desired repayment. Since Z can not predict the follow the notations summarized in Table 1. total number of lenders 푢A, we can not construct the repayment Symbol Description plan base on 푢A. Therefore, we choose to create the repayment Z ZeroLender plan based on a certain fixed denomination, unit of loan 푢, which A Lenders could be different in different loans (investment projects) basedon B Borrower the 푀 value. Each individual lending amount must be dividable by 퐵퐵 Bulletin board 푢. We denote by 푚 the number of units. According to the above 퐿 𝑖𝑑 Loan ID information, Z creates a raw payment table R (see Table 2), where ZID User’s ID row number 푛푢 = 푀/푢 and column number equals 푛푡 . Each cell L Intentional lenders list  푣푖,푗 is a committed repayment amount based on 푢. Each 푣푖,푗 also L lenders waiting list T Repayment list varies in a certain range with following condition: R Raw repayment table 푛𝑢 M Mapping table 푏 푗 = 푣푖,푗 (1) Rˆ R Consolidated repayment table 푖=1 addr (X,Y) Multisig account between X and Y TX𝑖 (X,Y) Transaction i from X to Y The total repayment 푟 of loan 푢: 푎푑푑푟 Bitcoin address 푛𝑡 휎 transaction amount 푟 = 푣푖,푗 (2) 푢A Number of lenders 푗= 푀 Total amount of loan 1 푛𝑡 Number of repayments (loan terms) 퐼 Interest rate 푏 푗 𝑗 Borrower’s repayment for time period Repayment Schedule 푢 Subtotal Unit of loan 1푠푡 2푛푑 3푟푑 ... 푛푡 푡ℎ 푚 Number of unit 푣  푣  푣  푣  푟 푚 A 1,1 1,2 1,3 ... 1,푛𝑡 𝑗 Number of unit of lender 𝑗 푣  푣  푣  푣  푟 2,1 2,2 2,3 ... 2,푛𝑡 푛𝑢 Total row numbers of R, where 푛𝑢 = 푀/푢 푣 푗 푖 ...... 𝑖,𝑗 Repayment for time period at row 푣  푣  푣  푣  푟 푛𝑢,1 푛𝑢,2 푛𝑢,3 ... 푛𝑢,푛𝑡 푣ˆ𝑘,𝑗 Final repayment for time period 푗 for lender 푘 M M 𝑖,𝑗 Plain element value of 푏  푏  푏  푏  푟 1 2 3 ... 푛𝑡 Total repayment in whole time period for R investment 푢 Table 2: Raw Repayment Table 푔,ℎ generator 푞 The order of the group Since each row is one unit of investment in 푛푡 periods, if the loan 푥 Committed value 푥 unit is 푚푗 , the lender will be assigned to 푚푗 rows. Further details Δ Repayment range about the assignment of rows in R will be explained in the lending 푁 Anonymity set of transactions phase. Table 1: Notations T and R are committed to BB, along with the proof transcripts. Z proves that R follows the above requirements in Protocol 2. after tw1, A푗 can reclaim her 푚푗 units of coins. Again, as men- Construction of Repayment Plan tioned before, 푚푗 must be multipliable of 푢. Similarly, other inter- (1) ZeroLender Z creates the Raw Repayment Table R of size 푛푢 ×푛푡 ested lenders individually escrow their desired investing amount: such that it follows the conditions defined in the Negotiation Phase. 푚1,푚2,푚3, ..., 푚푛,푚푛+1, ...on the blockchain via 2-of-2 escrow All the values in the table are committed. Z 푚 transaction with , upon the funded coins exceed the proposed • 푢 ·(퐼 + ) 푛푢 Every row adds to 1 in a certain of ratio, where 푚 = 푚푖 .WeletZ have a capability • 푗 푏 푛=1 Each column adds to 푗 of over-fundraising in case some lenders change their mind before • Each number is within the specified range Δ. • the deadline of fundraising and drop off this loan opportunity. Any other condition agreed upon. B Z 푚 (2) For each row i of R, use Schnorr’s Protocol to prove knowledge If ’s loan request is successfully funded, similarly escrows of the discrete log of the following with respect to ℎ: units of coins on the blockchain to the escrow address addr (Z,B)   푛푡 via a 2-of-2 escrow transaction denoted as TX2(Z,B) and TX2(Z,B) −푢·(퐼 + )  푣푖,푗  · 푔 1 is locked by time window tw2, where tw1 > tw2 and 푚 is amount  푗=1 after Z’s onetime origination fee, e.g. 푚 = 0.09 · 푚, where origi- R (3) For each column j of the , use Schnorr’s Protocol to prove knowl- nation fee is publicly known to all users. Transactions TX1(A푗 ,Z) edge of the discrete log of the following with respect to ℎ:   and TX2(Z,B) are confirmed on the blockchain. 푛푢 On first-come, first-serve basis, the first 푛A lenders whose in- −1 푣푖,푗  · 푏 푗  vestment coins equals 푀 list on the lending list L, extra lenders are 푖=  1 list in the waiting list L as backup. The commitment looks like: (4) For each cell in table R, use a range proof (adapted from [14]) to 푣  퐿 , ,푚 ,푢, , ,...,  prove that each commitment 푖,푗 is in the range agreed in the 푖푑 ZID푖 푖 addr A푗 ,1 addr A푗 ,2 addr A푗 ,푛푡 Negotiation phase, unconditionally above 0. ,..., A Where addr A푗 ,1 addr A푗 ,푛푡 are 푗 ’s repayments receiving ad- dresses. We encourage lenders provide the total number of receiving addresses at least equal to the total numbers of repayments, which Protocol 2: Proof of Proper Construction of Repayment Plan maximize lender’s privacy. Therefore, different repayment receiving address will be used at each returning circle. Z opens commitment to verifiers to prove posted information. If any of proofs fails, it Lenders ZeroLender Borrower Bulletin Board (BB) shows Z plays malicious. A aborts protocol.

mi units BTC 5.2.2 Securing the fund. To secure the loan transaction, B gener- Escrow Transaction Commits & Proves (ZKP) 푥 Lender’s Lending information ates a random number with 256 bits of entropy and hashes it with TX1 (by time t1) 퐻 = ℎ(푥) B 퐻 Step 1: m’ BTC the SHA-256 function, creating a hash value . signs Fundraising Escrow Transaction and posts to BB. B keeps preimage of 퐻 as a secret. Z informs all TX2(by time t2) intended lenders to secure the loan. We assume Lender A푗 indeed mi units BTC want to invest on this project. Then A푗 sends Z a Hashed Timelock Transaction TX3 locked by h(x) ^ Contract (HTLC) transaction with 푚푗 units of coins from escrow Commits & Proves (ZKP) Mapping table Non-anouncement M ^

Step 2: Consolidated repayment Table R Z m’ BTC address addr (A푗 ,Z), which stipulates may claim the funds by

Securing the fundSecuring the presenting a valid preimage 푥 of the hash digest 퐻 before given Transaction TX4 locked by h(x) timeout 푡푤 . However, this transaction TX (A ,Z) is not broad- Non-anouncement 3 3 푗 post Preimage x casted on the blockchain. Similarly, all rest of assured lenders create Z 퐻 Transaction TX6 similar HTLC transaction to locked by the same hash value .If 푇푋 has not been presented before the deadline for creating 푇푋 .In Step 3: Transaction TX5 3 3 Deposition m’ BTC A case 1, if lender 푗 fail to send TX3(A푗 ,Z), whose committed infor-  mi units BTC mation should be omitted from L, then lenders from L moves to L A Z ; in case 2, lender 푗 sends the TX3(A푗 ,Z), but trustless omits Figure 2: Lending phase A푗 information from L. To solve this security issue, ZeroLender  updates L by deleting failed lenders and moving lenders from L  5.2 Lending Phase to L, B generates a new hash value 퐻 and restarts this step. This In this phase, we integrate the CoinSwap model with zero-knowledge stops A푗 from blocking the protocol while also stopping Z from proofs at different steps, as shown in Figure 5. stealing 푚 Z B If the total amount of TX3(A푗 ,Z) reaches the , sends  5.2.1 Fundraising. After lenders compare borrower’s project infor- a HTCL transaction with 푚 unit of coins from escrow address  mation and interest rate on BB, we assume lender A푗 wants to lend addr (Z,B), where 푚 is the amount after origination fee. Then B 푚푗 units of coins to B through Z. A푗 asks Z set up a payment may claim the fund by present created preimage 푥 before timeout A 푚 푡푤 푡푤 > 푡푤 channel. 푗 escrows 푗 on the blockchain to the escrow address 4, where 3 4. This transaction TX4(Z,B) is not broad- addr (A푗 ,Z) via a 2-of-2 escrow transaction denoted as TX1(A푗 ,Z) casted on the blockchain either. that 푚푗 can be claimed by any transaction signed by both A푗 and At the end of this step, Z should have all A’s lending information Z L Z M M . TX1(A푗 ,Z) is locked by by time window tw1, which means based on . now creates a mapping table , see Table 3. In , Lender A A A A 1 2 3 ... 푛퐴 Assignment of Repayment Plan         0 0 1 ... 0 (1) Z creates a committed Mapping table M of size 푛푢 × 푛퐴. The         1 0 0 ... 0 table is created with the following conditions:         0 1 0 ... 0 • Each row 푖 adds to 1.         1 0 0 ... 0 • Each column 푗 adds to 푚푗 ...... • Each number in the table is either a 0 or a 1.         0 0 0 ... 1 (2) Each A푗 creates a row-wise permutation of M and posts a com- 푚  푚  푚  푚  1 2 3 ... 푛퐴 mitment to their permutation. Table 3: Mapping Table: M is created by Z ,Where rows are (3) Each A푗 opens their commitments of the permutation on BB. mapping to rows in Raw Payment Table R. Each column • If any parties refuse to open their commitments, go to step 2, mapping to individual lender A푗 . Each cell is committed as except any lender that failed to open their commitment is barred 0 or 1 with conditions: Each row only have one 1 and each from contributing a new permutation. (4) M is shuffled following the lenders’ permutations, resulting in column adds to 푚푗 , the number of lending unit of A푗 . Mˆ . (5) Z proves the following on Mˆ : • Each row 푖 adds to 1. This is proved by using Schnorr’s protocol row 푖 maps to same row position in R and each row have and only to prove knowledge of the discrete log of the following with have one committed 1, which means mapped row in R is assigned respect to ℎ:   푛퐴 to the lender A푗 and the sum of column 푗 equals A푗 ’s lending units − Mˆ 푖,푗  ·(푔 1) 푚푗 M . Therefore, in : 푗=1 푛퐴 • Each column 푗 adds to 푚푗 . This is proved by using Schnorr’s M푖,푗 = 1 (3) protocol to prove knowledge of the discrete log of the following 푗= with respect to ℎ: 1   푛푢 −푚 Mˆ 푖,푗  ·(푔 푗 ) 푛푢 푖=1 M푖,푗 = 푚푗 (4) 퐴 Z 푗 Mˆ 퐴 푗 푖=1 (6) For each investor 푗 , opens column of to 푗 . On that , for each 푖 such that Mˆ 푖,푗 hides 1, Z opens row 푖 of R to 퐴푗 . where plain cell value M푖,푗 is either 1 or 0. Z commits M to BB along with proof transcript. Z proves knowledge of Equation 3 and 4 according to Protocol 3. Protocol 3: Assignment of Repayment Plan To prevent Z dictate which lender is assigned which unit in the repayment plan with any bias, each A푗 permutes row of M then commits permutation to BB. After all A open permutations, the final shuffled mapping table Mˆ is released. If any A푗 fails to Repayment schedule Lender open their permutation commitment, the lenders each create and 1푠푡 2푛푑 3푟푑 ... 푛푡 푡ℎ A 푣  푣  푣  푣  commit a new permutation except the parties who failed to open 1 ˆ1,1 ˆ1,2 ˆ1,3 ... ˆ1,푛푡 A 푣  푣  푣  푣  their commitments, as they are now excluded from this process. 2 ˆ2,1 ˆ2,2 ˆ2,3 ... ˆ2,푛푡 The reasons and implications for this are discussed in Section 7...... A 푣  푣  푣  푣  The Protocol 3 shows the process of Mˆ construction. 푛퐴 ˆ푛A,1 ˆ푛A,2 ˆ푛A,3 ... ˆ푛A,푛푡 Now we need to combine the tables R and M. We first transform Consolidated Repayment Table Rˆ 푏  푏  푏  푏  R to a 3-dimensional table by adding the third dimension 푘 to the 1 2 3 ... 푛푡 T table R, where 푘 is column of the table M. If the value in M hides Total Monthly Repayment Table Rˆ 0, then value in 3-dimensional table equals 0, otherwise, equals to Table 4: Consolidated repayment table : each row match re- A 푣 the value hidden in R. Second, The newly generated values 푣푖,푗,푘 lated lender 푗 . ˆ푖,푗 is consolidated repayment value, where 푛푢 푏 푗 = 푣푖,푗 are committed to BB. Z proves this intermediary 3-dimensional 푖=1 ˆ . table by following Protocol 4. 5.3.1 Creating repayment transactions. Z create each individual Finally, to increase the ZKP efficiency, all commitments belong repayment transaction to related 퐴푗 according to Rˆ. The receiving to same lender are homomorphically added together, which trans- address shall match one of the committed receiving address in L. forms previous 3-dimensional table back to 2-dimensional table Rˆ. The finial consolidated repayment assignment table Rˆ is shown 5.3.2 Proof of transaction. Without loss of generality, we assume in Table 4. The consolidation of repayment plan is illustrated in Z generates 푛푇푋 repayment transactions and send total 푣ˆ푖,푗 coins Protocol 4. to lender A푗 for repayment time period 푗. Z commits 푣ˆ푖,푗 and A푗 ’s receiving address 푎푑푑푟 to BB. 5.3 Returning phase For each transaction TX푖 in the anonymity set 푁 , Z commits 휎 Z 푎푑푑푟 Before repayment due date, B prepares to pay back to Z according transaction amount 푖 if TX푖 is from ’s address to A푗 , other- to repayment list T that is set up in the Negotiation Phase. wise, it commits 0. Z submits the proof transcription to BB. 5.3.3 Finishing repayment transaction. B verifies each individual Consolidation of Repayment Plan repayment transaction which shall match the value committed 푖 ∈ Z 푘 ∈ Z (1) For each unit 푛푢 and each lender 푛퐴 : in Rˆ. If all verifications are true, B sends Z 푏 푗 coin to close this • 푗 ∈ Z 푣 For each 푛푡 , 푖,푗,푘 be defined as follows: repayment circle. (a) If Mˆ 푖,푘 hides 0, then 푣푖,푗,푘 = 0. (b) If Mˆ 푖,푘 hides 1, then 푣푖,푗,푘 is equal to the value hidden in the commitment 푣푖,푗  from R 6 SYSTEM DISCUSSION 푣 휇 (c) 푣푖,푗,푘 is committed as 푣푖,푗,푘 = 푔 푖,푗,푘 ℎ 푖,푗,푘 where random 휇 In this section, we discuss more about role of borrower and different number ℎ 푖,푗,푘 ∈ Z푞 payment situations. • Prove the following: Either (Mˆ 푖,푘 hides 1 AND for each 푗 ∈

Z푛푡 , 푣푖,푗,푘 hides the same value 푣푖,푗 in R)OR(Mˆ 푖,푘 hides 0 AND for each 푗 ∈ Z푛푡 , 푣푖,푗,푘 hides 0). 6.0.1 Covert Borrower. We assume borrowers are covert, meaning (2) All the commitments associated with lender 푘 for time period 푗 that they are willing to deviate from the protocol, but they are are homomorphically added. The resulting table Rˆ is posted to unwilling to get caught. In fact, borrower can play malicious, col- BB as the Consolidated Repayment Table. lude with ZeroLender. For example, Verifying the repayments from (3) Create a 푛퐴 × 푛푡 table called 푅ˆ: ZeroLender to the lenders is irrelevant to borrower’s repayment. • 푘 ∈ Z 푗 ∈ Z For each 푛퐴 and 푛푡 : To find methods to protect against potential malicious behavior of 푛푢   푛푢 푣 푛푢 휇 the borrower would be an interesting future direction to take this 푣  = 푣  = 푔 푖=0 ˆ푖,푗,푘 ℎ 푖=0 푖,푗,푘 ˆ푘,푗 푖,푗,푘 work. Due to the nature of the protocol, it is impossible to protect 푖=0 푣ˆ 휇 against a fully malicious adversary, as the borrower can simply 푣ˆ푘,푗  = 푔 푘,푗 ℎ 푘,푗 refuse to repay ZeroLender. However, it may be possible to make the protocol secure against covert borrowers, where the borrowers are willing to cheat but unwilling to get caught. Protocol 4: Consolidation of Repayment Plan On the other hand, P2P lending platforms in the market put all risks on lenders. Lenders have to choose to trust platform’s risk Finally, a homomorphic addition of commitments all 휎푖 evaluation, credit report, etc. If borrower is in financial insolvency, 푛 the only lost for platform is service fee. Our model bind platform  훽  = 휎ˆ푖  with lenders. If borrower is insolvency, ZeroLender loses one re- 푖=0 payment since it is pre-paid to lenders, which may lead ZeroLender Z uses Schnorr’s protocol to prove Z follows the above require- do more rigorous screening on borrowers. ments in Protocol 5. 6.0.2 Early payoff or partial payment. Some types of loan can be paid off early and there are a few different ways to go about it. Proof of Transaction Borrowers may choose make larger monthly payment, multiple 훽 훼 (1) Begin with a commitment of the total value 훽 = 푔 ℎ and a payments each billing cycle, or-if available they may even choose 푎푑푑푟  = 푔푎푑푑푟 ℎ훾 commitment to the output address, to pay off the loan in one lump sum. Similarly, if borrower onlyhas 푛 (2) For each transaction TX푖 in the anonymity set of size : capability to make part of repayment, it will cause payment penalty. (a) Let 휎푖 be defined as follows: All these activities involve in interest and repayment recalculations. • If TX푖 is from Z to the committed lender A푖 ’s account, then More details can be found in [11]. Though it is a limitation that 휎푖 is set to the amount in the transaction going to the output. • Else, 휎푖 = 0 we assume that the borrower is capable of paying, the protocol is (b) Pick a random number 푟푖 ∈ Z푞 capable of handling variable repayment plans where the interest 휎 푟 (c) Create a commitment 휎푖  = 푔 푖 ℎ 푖 is payed monthly and they can choose multiple repayments. To (d) Z proves the following: Either (Z knows the private key(s) accomplish this, the rows of the R add to 푢 · 퐼 instead of 푢(퐼 + 1) associated with the input address AND the value committed and the columns would contain the repayment amount times the in 휎푖  is equal to the output amount AND the commitment interest as well. The plans are then mapped to lenders and the table 푎푑푑푟  휎  is equal to the destination address) OR 푖 hides 0. is consolidated as prescribed in the Lending phase. Interest is cal- 휎  (3) Homomorphically combine all the 푖 : culated by taking every non-payed column from the consolidated 푛  푛 푛   휎푖 푟푖 훽 푟 and homomorphically adding them, resulting in total interest. If 훽  = 휎푖  = 푔 푖=0 ℎ 푖=0 = 푔 ℎ 푖=0 the Borrower wishes to repay multiple repayments, they can say (4) Use Schnorr’s protocol to prove knowledge of the discrete log of so a month in advance. They then take values in the selected re- the following with respect to ℎ: payment columns and homomorphically divide it by the interest (퐼 −1 mod푞 훽 · 훽−1 (푣ˆ푖,푗 ), which results in the amount of the repayment. This is added to the interest, and Z is required to repay the interest as prescribed in the table, the homomorphic addition of the row plus the repayment of part of the principle. Using a similar method, Protocol 5: Proof of Transaction we can also support partial repayments, though such repayments would harm the privacy of the transactions. 7 SECURITY ANALYSIS (2) For each unit 푖 and each repayment 푘, S uses the simulator for the zero knowledge proof used to prove the following 7.1 Privacy by Simulation ˆ  statement Either (M hides 1 AND for each 푗 ∈ Z푛푡 , 푤푖,푗,푘 Now, we will prove that privacy is maintained against a covert 푖,푘 푣 R Mˆ B and a malicious A푗 through the protocols. Recall that, though hides the same value 푖,푗 in )OR( 푖,푘 hides 0 AND for 푗 ∈ Z 푤 this model allows for a malicious Z, they are required to have the each 푛푡 , 푖,푗,푘 hides 0). 푤 details (accounts information) of both the A and the B so that (3) The 푖,푗,푘 values are homomorphically combined as pre- direct secure communication is not required. If a party wishes to scribed in Protocol 4 to produce Rˆ. have privacy from ZeroLender, they can use a mixing service, e.g.  TumbleBit [9], to achieve privacy. Theorem 7.3. Privacy is preserved against a malicious A푗 in the B Theorem 7.1. Privacy is preserved against a covert in the Ne- Lending phase. gotiation phase. To prove Theorem 7.3, we need to prove that both Protocol 3 To prove Theorem 7.1, we provide a simulator S that can simulate and 4 of the Lending Phase can be simulated. a valid transcript of Protocol 2.  (1) S generates the Raw Repayment Table R populated with Lemma 7.3. Privacy is preserved against a malicious A푗 in the random group elements. Assignment of the Repayment Plan (Protocol 3). (2) S uses the simulator for Schnorr’s protocol (in Protocol 1) to 푢 ·(퐼 + ) To prove Lemma 7.3, we provide a malicious simulator that simulate the proof that the product of the rows hide 1 . A (3) S uses the simulator for Schnorr’s protocol that the product is able to extract 푗 ’s inputs and use them to simulate a view 푏 T indistinguishable from the ideal model. of the columns hide the same values as 푗 in . A (4) S runs the simulator for the range proof (Adapted from [14]) Define the ideal model as follows: The 푗 ’s input is his permu-  on each group element in R . tation. Based on that permutation, the Trusted Third Party (TTP)  returns the values of the rows they were assigned, as well as the re- sult of the total permutation. A lack of a permutation is interpreted Theorem 7.2. Privacy is preserved against a covert B in the Lend- as the primitive permutation 푝 (1 → 1, 2 → 2, etc).  ing Phase. (1) A푗 generates R using random group elements, as detailed in Theorem 7.1’s proof. To prove Theorem 7.2 we need to prove that both Protocols 3  (2) A푗 has Z generate a fake M with random group elements. and 4 of the Lending phase are privacy preserving.  (3) S has the all lenders commit permutations of M . Lemma 7.1. Privacy is preserved against a covert B in the Assign- (4) If A푗 fails to post a commitment, S extracts the primitive ment of the Repayment Plan (Protocol 3) permutation 푝. A To prove Lemma 7.1, we provide a simulator S to simulate the (5) If 푗 posted a commitment to a permutation: B •Shas the lenders open their commitments. view of . • A S 퐶 A If the 푗 does not open the commitment: (1) creates random group elements 푗 for each lender 푗 (a) S extracts the primitive permutation 푝. representing their 푚푗  (b) S uses 푝 as A푗 ’s input to the TTP and obtains A푗 ’s (2) S has all the lenders approve the commitments on BB. S Z M outputs. (3) has generate a fake mapping table with random (c) S rewinds to the construction of the Raw Repayment group elements.   Table R and constructs it to match the TTP outputs. (4) S has lenders commit permutations of M .  Specifically, the rows that will be assigned to A푗 contain (5) S has lenders open their permutation commitments of M .  committed values to be given to A푗 . (6) M is shuffled according to the permutations, resulting in (d) S proceeds exactly as before to the point where A푗 Mˆ  . refused to open their permutation commitment. S (7) uses the simulator for Schnorr’s protocol to prove that the (e) S has the simulated lenders create permutations that, product of the rows each hide 1. when combined, it is equivalent to the TTP’s permuta- S (8) uses the simulator for Schnorr’s protocol to prove that the tion. product of each of the columns hides the same value as its (f) S had the simulated lenders open their commitments. 퐶   respective 푗 . (g) All parties shuffle M using the permutation Mˆ   (h) S opens the lender’s column of Mˆ , as well as their R Lemma 7.2. Privacy is preserved against a covert B in the Consol- assigned rows from and the protocol concludes. • S idation of Repayment Plan (Protocol 4). If the permutation is invalid, extracts the primitive per- mutation 푝. S To prove Lemma 7.2, we provide a simulator to simulate the • Else, S extracts the A푗 ’s permutation 푝. B view of . (6) S uses the permutation 푝 as A푗 ’s input to the TTP. (1) S chooses a random group element 푤푖,푗,푘 for each supposed (7) S rewinds to the construction of the Raw Repayment Table  commitment 푣푖,푗,푘. R and constructs it to match the TTP outputs. Specifically, the rows that will be assigned to A푗 by the total permutation •A푗 confirms that the bitcoins have been transferred tohis will contain commitments to the values to be given to A푗 . account.   (8) S continues to the construction of M . S constructs the table • For each lender, there exists a random group element 푣ˆ푖,푗 A  so that the 푗 ’s column will, after the total permutation, in the Repayment Table Rˆ representing the repayment A result in the appropriate rows being assigned to 푗 . amount. S (9) has the simulated lenders construct permutations such • For each lender A푗 푝 that the result combined with the permutation . – For each transaction in the anonymity set 푁 S A  (10) has the 푗 ’s commit their permutation. (1) S chooses a random group element 휎 S A 푖 (11) has the 푗 ’s open their commitments. (2) S uses the simulator for the Zero Knowledge Proof used   (12) All parties shuffle M using the permutation Mˆ to prove the following statement: Either (S knows the  (13) S opens the lender’s column of Mˆ , as well as their assigned private key(s) associated with the input address AND R  rows from . the value committed in 휎푖 is equal to the output amount   AND the commitment 푎푑푑푟 is equal to the destination  address) OR 휎푖 hides 0. Lemma 7.4. Privacy is preserved against a malicious A푗 in the   – S uses Schnorr’s protocol’s simulator to prove that 휎푖 Consolidation of the Repayment Plan (Protocol 4).  hides the same value as 푣ˆ푖,푗. A푗 has no inputs nor a role in for the Consolidation of the  Repayment Plan, therefore they have no inputs or interactions in which they can be malicious in this step. Therefore, we use the 7.2 Fund Security same simulator as the borrower for Protocol 4.  As lenders, one of the most concerns is that ZeroLender steals or Theorem 7.4. Privacy is preserved against a covert B in the Re- occupies funds/repayment. We analyze fund security in several turning Phase. cases. S To prove Theorem 7.4, we provide a simulator to simulate the 7.2.1 ZeroLender Z is corrupt. We want to show that desired B 푖 view of in Protocol 5 for repayment . bitcoins from all lenders A can be passed to borrower B.Inthe • In the Lending Phase, each of the the simulated lenders Lending phase, if fund is successfully raised, which means securing  approved a random group element 훼 representing a com- the fund step is done, CoinSwap paradigm guarantees that B get mitment their address for this repayment. correct loan. Otherwise, B will not post preimage of the hash value • 푣  For each lender, there exists a random group element ˆ푖,푗 after the TX3 and TX4. If fund is partially raised, then Z only gets  in the Repayment Table Rˆ representing the repayment some TX3s, there is no reason for Z to continue to create TX4 since amount. Z will lose coins if this fundraising fails. • For each lender A푗 Moreover, ZKPs for table R, Rˆ, M and Mˆ guarantees all repay- – For each transaction in the anonymity set 푁 ment are fair to A. Even though Z joins lender’s party as a real  Z (1) S chooses a random group element 휎푖 lender, can not operate hidden value in these tables since tables (2) S uses the simulator for the Zero Knowledge Proof used are shuffled by A. In the Returning phase, Protocol 5 requires Z to prove the following statement: Either (S knows the prepay all repayments before Z get repayment from B. Therefore, private key(s) associated with the input address AND Z can not deny planed repayment in the Returning phase.  the value committed in 휎푖 is equal to the output amount  7.2.2 Lender A푗 is corrupt. We want to show that malicious A푗 AND the commitment 푎푑푑푟 is equal to the destination  can not claim he does not receive repayment or repayment amount address) OR 휎푖 hides 0.   is not correct. First, in the Negotiation phase, A푗 committed his – S uses Schnorr’s protocol’s simulator to prove that 휎 푖 receiving addresses on the lending list L; second, in the Lending 푣ˆ푖,푗 hides the same value as Rˆ  phase, final repayment plan has decided repayment amount, last, in the Returning phase, any verifier can verify if the repayment Theorem 7.5. Privacy is preserved against a malicious A푗 in the matches information in the L and Rˆ. Returning phase. In the Lending phase, securing the fund step, there are two places, A푗 may play malicious: (1) A푗 refuses to send TX to Z and (2) if To prove Theorem 7.5, we provide a malicious simulator S to 3 A푗 is the last one to open the permutation of M, he may refuse to simulate the view of A푗 in Protocol 5 for repayment 푖. open the permutation. Our solution is to reboot the securing the We assume that the block chain contains the transactions to the fund step. For the case one, A푗 will be replaced by the lender in lender’s account and that these transactions are in the anonymity the waiting list. A푗 wastes his transaction fee for the TX ; for the set. However, S does not know the private keys associated with 1 case two, A푗 losses his shuffling right in the new securing the fund the sending accounts. step. Our Protocols guarantee that the permutation is valid if one • In the Lending phase, each of the the simulated lenders ap-  of the lenders are honest. proved a random group element 훼 representing a commit- ment his address for this repayment. At the same time, A푗 7.2.3 Lenders A and Z collude. Now suppose A푗 and Z collude confirmed his receiving address commitment 푎푑푑푟 try to harm other honest A. Basically, this can be treated as two cases above. Since our protocol is designed to allow Z as a valid Consolidation of the Table. The consolidation of the table Rˆ con- lender, moreover, Z as a platform knows all related information, sists of a proof on every cell of the 푚푎푡ℎ푐푎푙푅ˆ ,a푛푡 by 푛푢 table, with collusion can not make it get extra information. each investor, resulting in a complexity of O(푛푢 · 푛A · 푛푡 ). Then, each investor’s commitments from the proofs are homomorphically 8 PERFORMANCE ANALYSIS added together, resulting in O(푛푢 ·푛A ·푛푡 ) additions. Thus, the run- O(푛 · 푛 · 푛 ) 8.1 Theoretical Analysis time complexity of the consolidation of the table is 푢 A 푡 . Therefore, the runtime complexity of the Lending Phase is O(푛푢 · Theorem 8.1. The Negotiation Phase has a runtime complexity of 푛A · 푛푡 ).  O(푛푢 · 푛푡 ·|Δ|). Theorem 8.3. One return period of the Returning Phase protocol Proof. This protocol consists of three distinct sections. The com- has a runtime complexity of O(푛푢 · 푛A). mitment of the table, the proofs that the rows and columns add Proof. This phase consists of a constant series of proofs for each to their appropriate values, and the proofs that each repayment is elements in an anonymity set 푁 for each investor. If the size of within the range proof. the anonymity list is |푁 |, then the complexity of this section is To populate the plaintext Raw Repayment Table R, it requires O(|푁 |·푛퐴) for each repayment.  an operation of order O(푛푢 · 푛푡 ). Then, each value needs to be O( ) committed. Since each commitment is 1 , this total operation is 8.2 Experimental Evaluation O(푛푢 · 푛푡 ). ZeroLender After this, ZeroLender must prove each row adds up to 푢 ·(퐼 + 1). We have developed a proof-of-concept implementation of To do this, first all the commitments from each row must beho- to test the performance of our protocol in Java 1.8. Bouncy Cas- momorphically added. Homomorphically adding one row is O(푛푡 ). tle [13], a standard cryptographic library for Java is used to handle Since this operation happens on each row, it results in a O(푛푢 · 푛푡 ). the elliptic curve operations. We performed our tests on a PC with Similarly, the column proofs also has a O(푛푢 · 푛푡 ). i7-6700 CPU @ 3.4GHZ and 32GB RAM. The range proofs now have to be executed. Since the range proof All results are measured in computational time rather than real is executed on each value in the table, 푛푢 · 푛푡 range proofs must time to show computational work. Many of these protocols contain be executed. Each individual range proof has a O(|Δ|). Therefore, significant portions of embarrassingly parallel computations, so this the complexity of the range proofs is O(푛푢푛푡 ·|Δ|). It should be can be multithreaded for performance. To reflect the amount of noted that it would be perfectly reasonable for a service to have computational work required, we used a single threaded implemen- a constant unit size and a constant range. If that were the case, tation. ZeroLender then the range proofs would be constant and the result would be In difference phase of , we choose different variables O(푛푢 · 푛푡 ). to show the ZKP construction time, verification time, and proof This results in O(푛푢 · 푛푡 ·|Δ|) for the entire construction phase. size of the ZKP transcript.  8.2.1 Negotiation phase. In this phase, we have tested the Proto- 푢 Theorem 8.2. The Lending Phase has a runtime complexity of col 2 by varying numbers of repayments 푡 (6, 12, 24, 36 month) 푚 O(푛푢 · 푛A · 푛푡 ). and number of unit (100, 200, 300, 400, 500). Figure 3.a and 3.b show protocol computation time of construction and verification Proof. The Lending phase consists of two major sections: The As- respectively. Figure 3.c shows proof transcript size. As expected, signment of the Repayment Plan (Protocol 3) and the Consolidation the computation time and transcript size increase linearly with the of the Repayment Plan (Protocol 4). number of repayments. Moreover, computation time and transcript size also increase linearly with the number of units. By comparing The Assignment of the Repayment Plan. This section consists of construction computation in Figure 3.a and verification computa- three major parts: The creation and committing of the mapping tion in Figure 3.b, we notice verification is more expensive than table M, the shuffling of the M, and proving the rows and columns construction computation. add to the appropriate values. The creation and committing of the table requires the choosing 8.2.2 Lending phase. In this phase, using same setting in the Ne- and commitment of 푛푢 ·푛A bits, therefore, this step has O(푛푢 ·푛A). gotiation phase plus constant lenders (푛퐴 = 60), we have tested the The shuffling of the table consists of two minor steps. Each lender Protocol 3 and 4. Figure 4 also shows the computation time and has to create a permutation, which takes O(푛푢 ). The method we transcript size increase linearly with the number of repayments. employed to commit these permutations takes O(푛푢 ) time. After Again, computation time and transcript size also increase linearly this, all the parties have to open all the other lender’s commitments, with the number of units. Also, verification is more expensive than which means that each party has to run O(푛A · 푛푢 ). Then, the construction computation. Comparing to the Negotiation phase, permutations are applied, which requires 푛푢 row repositions for the proof of Lending phase is a more expensive operation. One each lender, resulting in O(푛푢 · 푛A), though this part has a very thing to note about these experiments is that the slopes on the small coefficient associated with it. graphs in Figure 4 do not converge at 0 due to the performance of The proofs that the rows and columns add to the appropriate the permutations not being effected by the number of repayments. values both have O(푛푢 · 푛A), much like the similar proofs in the R In Figure 5, we hold the number of repayments (푛푢 = 24 months), analysis. number of units (푚 = 300) constant, vary the number of lenders. Therefore, the creation and shuffling of M is O(푛푢 · 푛A) This figure demonstrates the linear scaling of computation time 5 5 120 500 units 500 units 500 units 400 units 400 units 400 units 4 4 300 units 100 300 units 300 units 200 units 200 units 200 units 100 units 80 100 units 3 100 units 3 60 2 2 40 Run time (min) time Run 1 (min) time Run 1

Transcript size (MB) size Transcript 20 0 0 0 0 6 12 18 24 30 36 0 6 12 18 24 30 36 0 6 12 18 24 30 36 Number of repayments Number of repayments Number of repayments

(a) Construction Time (b) Verification Time (c) Proof Size

Figure 3: Performance for Protocol 2 (Construction of repayment plan) in Negotiation phase

30 30 500 500 units 500 units 500 units 400 units 25 25 400 units 400 units 300 units 300 units 400 300 units 200 units 200 units 200 units 20 100 units 20 100 units 300 100 units 15 15 200 10 10

Run time (min) time Run (min) time Run 100

5 5 (MB) size Transcript 0 0 0 0 6 12 18 24 30 36 0 6 12 18 24 30 36 0 6 12 18 24 30 36 Number of repayments Number of repayments Number of repayments

(a) Construction Time (b) Verification Time (c) Proof Size

Figure 4: Performance for Protocols3&4intheLending phase (the number of lenders is held constant at 60).

a set of transactions and a list of committed values representing 25 Total the amount each investor is owed. We then execute Protocol 5 Verification 20 Construction on each account and investor. The results are shown in Figure 6. 15 These graphs showcase the linear scaling with both the number 10 of investors and the number of transactions. It should be noted

Run time (min) Run 5 that, in the context of ZeroLender as a whole, this portion can be

0 executed over the course of an entire month as the blocks come in. 020406080 ZeroLender can choose the anonymity set by choosing transactions Number of lenders from the blocks as they are created, given enough time to be assured that the block isn’t on a terminating branch. Figure 5: Performance with different joined lenders and size of transcript with respect to number of lenders. It should 9 RELATED WORK be noted that this is the most time sensitive section of the pro- tocol. The Negotiation phase can have the proofs pending while In Bitcoin, if an address is ever linked to a user’s identity, all related ZeroLender gathers lenders and the Returning phase can be gener- transactions will be linked to the user as well. To avoid such prob- ated and verified throughout the month as the blocks are addedto lem, mixing service [21] are used to mix bitcoins and obscure the ZeroLender the blockchain. The Lending phase is the only set of proofs where trail back to the fund’s original source. Even though ZeroLender the proofs can not be created beforehand and there is no other work is not a mixing service, closely related work. In the ZeroLender that can be done in the protocol while the proofs are being verified. lending phase, is related to mixing services [2][9][17], To reduce the delay at this point, the consolidation phase, can be where a mixing address receives coins from multiple clients and spread out across the months. The experimental results demon- forwards them to fresh addresses. Mixcoin [2] uses a Trusted Third strate Protocols 3 and 4 scale linearly in construction, verification Party (TTP), which could steal users’ bitcoins. TumbleBit [9] uses time and proof size to its inputs: the proof of Protocol 2 scales with RSA-puzzle solving protocol which enables sender to pay the re- number of repayments. the proof of Protocol 3 and 4 scales with ceiver one denomination unit. However, TumbleBit requires the number of repayments and number of lenders. The verification of sender and the receiver to interact with each other and to exchange the protocol require more time to the construction of the proof. puzzle information. Moreover, to achieve anonymity, every trans- action has to be set to an equal denomination. CoinShuffle17 [ ]is 8.2.3 Returning Phase. In this phase, we simulate the execution secure against thefts but suffering the Bitcoin’s maximum transac- of a single month of returning transactions. To do this, we use tion size (100KB) limits, which has scalability issue. In our lending 350 350 8000 80 investors 80 investors 80 investors 300 300 7000 60 investors 60 investors 60 investors 40 investors 40 investors 6000 40 investors 250 250 20 investors 20 investors 20 investors 5000 200 200 4000 150 150 3000 100 100 2000 Run Time (min) Time Run Run Time (min) Run Transcript Size (MB) Size Transcript 50 50 1000

0 0 0 0 20000 40000 60000 80000 100000 0 20000 40000 60000 80000 100000 0 20000 40000 60000 80000 100000 #Transactions in anonymity set #Transactions in anonymity set #Transactions in anonymity set

(a) Construction Time (b) Verification Time (c) Proof Size

Figure 6: Performance for Protocols 5 being run with 20, 40, 60, and 80 investors with a range of transactions. phase, the activity of ZeroLender collecting investment and for- 486–504. warding to the borrower is similar to a mix service, but all these [3] Gaby G. Dagher, Benedikt Bünz, Joseph Bonneau, Jeremy Clark, and Dan Boneh. 2015. Provisions: Privacy-preserving Proofs of Solvency for Bitcoin Exchanges. aforementioned mixing services either need interactive commu- In Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communi- nication between senders and receivers or the mixing service has cations Security (CCS). 720–731. Σ to be trusted. Furthermore, some mix services such as TumbleBit [4] Ivan Damgard. 2010. On -protocols. http://www.cs.au.dk/~ivan/Sigma.pdf. [5] U. Feige and A. Shamir. 1990. Witness Indistinguishable and Witness Hiding has unusual transaction script which may expose Bitcoin addresses Protocols. In the Twenty-second Annual ACM Symposium on Theory of Computing. involved in mixing activities through blockchain. 416–426. [6] Maxwell Gregory. 2013. CoinSwap: Trasnsaction graph disjoint trustless trading. Zero-knowledge proof (ZKP) allows a prover to assure a Verifier https://bitcointalk.org/index.php?topic=321228.0/. that they have knowledge of a secret or statement without revealing [7] Olena Havrylchyk and Marianne Verdier. 2018. The Financial Intermediation Role the secret itself [10]. Participated parties prove they are following of the P2P Lending Platforms. Comparative Economic Studies (2018), 115–130. [8] Carmit Hazay and Yehuda Lindell. 2010. Efficient Secure Two-party Protocols. the protocol properly without revealing their secrets [3]. Schnorr Springer. proposed first efficient Σ-푝푟표푡표푐표푙 [4], which is simple to prove [9] Ethan Heilman, Leen Alshenibr, Foteini Baldimtsi, Alessandra Scafuro, and security with a simulator. Comparing to ZeroLender, Zcash uses Sharon Goldberg. 2017. TumbleBit: An Untrusted Bitcoin-Compatible Anony- mous Payment Hub. In 24th Annual Network and Distributed System Security zero-knowledge succinct non-interactive argument of knowledge Symposium. (zk-SNARKs) [19] to provide enhanced privacy and recently, later, [10] Markus Jakobsson and Ari Juels. 2000. Mix and Match: Secure Function Evaluation via Ciphertexts. In Advances in Cryptology — ASIACRYPT 2000. 162–177. Ethereum integrated zk-SNARKs in the form of smart contracts. [11] Leslie Jane, Federer Vaaler, and James Daniel. 2009. Mathematical Interest Theory. To mitigate or avoid vulnerability of the exchange system, Dagher The Mathematical Association of America. et al. [3] presents Provision which is a privacy-preserving proof of [12] Venkat Kuppuswamy and Barry L. Bayus. 2018. Crowdfunding Creative Ideas: The Dynamics of Project Backers. 151–182. solvency for Bitcoin exchanges without revealing Bitcoin addresses, [13] Legion of the Bouncy Castle Inc. [n.d.]. Bouncy Castle Crypto APIs. total holding and liabilities. Inspired by Provision, ZeroLender uses [14] Wenbo Mao. 1998. Guaranteed correct sharing of integer factorization with ZKP in all three phases. In the negotiation phase, ZKP is used to off-line shareholders. In Public Key Cryptography. 60–71. [15] . 2008. Bitcoin: A peer-to-peer electronic cash system. http: prove the raw repayment plan. In the lending phase, ZKP is used to //www.bitcoin.org/bitcoin.pdf. prove final (consolidated) repayment plan. Finally, in the returning [16] Torben Pryds Pedersen. 1992. Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing. In Advances in Cryptology - CRYPTO ’91. 129–140. phase, ZKP is used to prove proper repayment distribution from [17] Tim Ruffing, Pedro Moreno-Sanchez, and Aniket Kate. 2014. CoinShuffle: Practical ZeroLender. Decentralized Coin Mixing for Bitcoin. In 19th European Symposium on Research in Computer Security. 345–364. [18] Nicolas van Saberhagen. [n.d.]. CryptoNote v2.0. https://github.com/monero- 10 CONCLUDING REMARKS project/research-lab/blob/master/whitepaper/whitepaper.pdf. ZeroLender [19] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, In this paper, we have presented , a trustless P2P lending Eran Tromer, and Madars Virza. 2014. Zerocash: Decentralized anonymous platform in Bitcoin. We developed a proof-of-concept implemen- payments from bitcoin. In 2014 IEEE Symposium on Security and Privacy. 459– tation to test the performance of our protocol. Our experiments 474. [20] C. P. Schnorr. 1990. Efficient Identification and Signatures for Smart Cards.In demonstrate that the computation time and storage size overhead Advances in Cryptology - CRYPTO’ 89. 239–252. are linear with respect to number of payments. Finally, although we [21] Usman W. Chohan. 2017. The Tumblers: Risks, Legality and Oversight. SSRN Electronic Journal (2017). have focused on the P2P lending platform in this paper, our model [22] Gavin Wood. 2014. Ethereum: A secure decentralised generalised transaction is compatible with other sharing economy, e.g. group buying and ledger. http://gavwood.com/paper.pdf. Crowdfunding, with minor modifications. Also, these concepts can be used on other similar cryptocurrencies.

REFERENCES [1] Krishnan S. Anand and Ravi Aron. 2003. Group Buying on the Web: A Comparison of Price-Discovery Mechanisms. Management Science (2003), 1445–1615. [2] Joseph Bonneau, Arvind Narayanan, Andrew Miller, Jeremy Clark, Joshua A. Kroll, and Edward W. Felten. 2014. Mixcoin: Anonymity for Bitcoin with Ac- countable Mixes. In 18th Int. Conf. Financial Cryptography and Data Security.