Blockchain and cryptocurrencies such as Bitcoin  have disrupted the banking industry, enabled new business models, and helped in designing new, efficient financial infrastructure. A blockchain is an append-only distributed ledger, where users post messages or transactions, which are usually considered immutable. Blockchains have enabled the growth of IOU (I Owe You) credit networks in recent years. A credit network is a decentralized peer-to-peer lending network, where users lend out financial credit based on social trust. Credit networks provide the means to do path-based payments between two users, where the payment is routed through multiple intermediate users. Credit networks offer several advantages over traditional banks, such as low end-to-end transaction time, lower routing fees, and the ability to perform cross-currency transactions in the order of seconds. Some examples of real-world credit networks are Ripple  and Stellar .
Credit networks are usually modeled as a directed graph with vertices and weighted edges/links. The vertices represent the various users in the system and the weight on a link is the credit a user is willing to offer to an adjacent user. The directionality of the link is used to denote the lender and borrower, e.g., denotes has extended 20 units of credit to . Payments are routed along (and in the direction of) credit links, and once a payment is made from a sender to receiver, the link weights are decremented along the transaction path.
There has been growing interest in finding solutions for efficient routing, and enabling private and secure transactions in credit networks [18, 9, 16] but not much work has been done in the area of rebalancing link weights of a user that has run out of credit, and cannot participate in transactions. Rebalancing in credit networks is a significant problem to study, since, if the credit on a given link gets exhausted, i.e., if the weight on a link connecting two nodes drops to zero, no transactions can be done on any path containing those nodes until the link is refunded, a process which involves expensive on-chain transactions. Such nodes will be unable to participate in any transaction due to their inability to transfer or flow money, and will eventually be shunned by other nodes in the network. Networks which have large sections of such dormant nodes will eventually become inefficient, have progressively low throughput and may not even remain operational. In this paper, we study the problem of rebalancing links in an efficient way, while making minimal use of the blockchain, with the goal of avoiding mining and blockchain write fees.
We propose a two-step rebalancing process wherein a node whose link weights are low or close to zero, can create fresh incoming links in a process called balance transfer, and then create fresh outgoing links in a process called as bailout. Upon completion of these two steps, the poorly connected node will become an active participant in the network, become involved in high throughput transactions, thus enabling it to collect routing fees. At a high level, balance transfer involves existing nodes moving outstanding debt to a new lender, incentivized by lower interest rates, and bailout involves the lender temporarily being assisted by a bank, who infuses capital into them to shore up their credit reserves. Once their earnings exceed their debts, the bank exits the system.
Balance Transfer in Credit Networks: Balance transfer in the real world occurs when the outstanding balance of one credit card (or several credit cards) is moved to another credit card account. This is often done by consumers looking for lower interest rates. Many credit card issuers offer introductory balance transfer APRs that are lower than the standard rates. Another advantage of balance transfer is that it makes financial management easier by transferring consolidated balances to a new credit provider. Although lending in blockchain has become quite common, the idea of doing balance transfers in credit networks has not been explored. In this paper we design a system where any lending node with low connectivity can advertise a lower interest rate, and thus gain more borrowers.
Bailout in Credit Networks: A bailout is a process where an organization or a government injects capital into a failing business to save it from bankruptcy, and to help make the business competitive again. In the context of credit networks, a bank does a “bailout” of a user, Alice, with no outgoing credit links by lending credit to her, and temporarily helps her by connecting her with other users with whom Alice can establish permanent links. Once she establishes permanent links with other users, the bank exits the network, possibly after collecting a small fee from Alice.
Our Contributions: In this paper, we give a new approach for rebalancing depleted credit links in credit networks.
1) We propose a two-step approach for rebalancing consisting of balance transfer and bailout. In the balance transfer step, a poorly connected node, called as requestor, will establish incoming links with other nodes in the network by advertising a lower interest rate. This enables the requestor to become a lender to other nodes. In the bailout step, a well-known party such as a bank will infuse capital into the requestor node, by helping it connect to, and establish outgoing links with several other nodes in the network. After the requestor node establishes outgoing connections with other nodes, the bank will leave the network, possibly after collecting a fee from the requestor. At the end of this process, the requestor node will have several incoming and outgoing links, which will enable it to help facilitate several transactions, thus increasing the overall throughput and robustness of the credit network.
Ii Related Work
In this section, we review literature on credit networks, payment channels, and rebalancing and loaning in credit networks.
Credit networks: Fulgor and Rayo  were the first to setup a peer-to-peer payment channel network that provides provable security and privacy properties, with Rayo being the first payment network that enforces non-blocking transactions. Fulgor and Rayo, both, establish a path between sender and receiver, assuming all users in the path to be honest, and users have at least partial knowledge about network topology. Unlike Fulgor and Rayo, in our system, the entire network topology is not known to the users and we do not assume all the users in the path to be honest. Also, we do not propose any payment operations, instead focus only on rebalancing credit links.
SilentWhispers  presents a decentralized credit network (DCN) architecture which consists of subsets of paths between the sender and receiver calculated via several trusted entities called landmarks. PathShuffle  presents a path mixing protocol for Ripple network providing complete anonymity. PathShuffle leverages existing infrastructure from Ripple  to create and maintain consistent credit links with users in the networks. Both  and  present solutions for routing payment in a secure and privacy-preserving way in credit networks, and neither tackle the challenge of rebalancing depleted credit links. Our goal is to design a mechanism for rebalancing credit links.
We leverage the concept of landmark nodes proposed in  in our system to assist the requestor node in our bailout phase. The landmark node is a well connected node such as a bank, and hence, can potentially help the requestor node contact several other nodes in the network for establishing outgoing links. We use the landmarks in our system to assist the requestor node establish outgoing links without placing enormous trust on landmarks, unlike . Roos et al  used graph embedding for efficient routing with concurrent transactions overcoming some inefficiencies in . They too do not focus on the rebalancing problem. Malavolta et al , recently proposed a novel linkable ring signature scheme for refund transactions natively in Monero  and extend the same scheme into having scalable off-chain transactions by establishing payment channels using Monero. Our system could be deployed in such kind of payment channel network to enable the system to be more competitive and enhance the connectivity in such channels simultaneously achieving rebalancing within the network.
Panwar et al.  proposed a DCN system where users can perform path-based transactions that preserves sender, receiver and value privacy but involves a significant number of blockchain writes in the course of a normal, successful transaction (more in the case of transaction rollbacks, re-tries, and other edge cases). Our system also involves blockchain writes, but in our system, a single blockchain write is done only after the completion and execution of the entire rebalancing protocol, unlike , which would help it scale much better.
Rebalancing: REVIVE  is a payment network that allows users to rebalance their channel without having to communicate with the blockchain. Although very efficient in rebalancing bidirectional networks (i.e., cyclic networks), REVIVE does not present any solution for rebalancing in a unidirectional (acyclic) credit network, which is our use-case scenario. REVIVE has a leader elected in the network who stays online all the time in order to facilitate rebalancing requests. We do not place trust in any leader or centralized entity to establish new incoming or outgoing links in the system although we make use of landmark nodes to assist the requestor node temporarily in our bailout step. Lightning network  is a highly scalable payment channel network that is constructed on top of Bitcoin. Lightning network does re-balancing off-chain, but again only for cyclic networks. To rebalance a credit link, a node does a payment in cyclic path to itself and such payments usually comes with a fee for each node in the circular path. In our approach, a node establishes new incoming and outgoing credit links, without having to pay every node in a payment path.
Ripio Credit Network (RCN)  is a peer-to-peer global credit network protocol based on cosigned smart contracts and blockchain technology. A user can join as a lender, cosigner or borrower in the network. A cosigner will act as a go-between a borrower and a lender in the network. In case a borrower defaults, the cosigner works out an alternative mechanism for managing debt collection. However, this places a great responsibility on the cosigner, and if they are incapable of actually enforcing debt collection for any reason, the overall value of the network would decrease.
Iii System Design
Credit networks are usually dense networks, e.g., Ripple 
, with several incoming and outgoing links from the nodes. If a node has depleted credit links, then, intuitively, one way for it to rebalance its links would be to extend credit to, and borrow from new users. This could be problematic for several reasons: the new users might not be trusted, or at the moment when a node’s credit links are depleted there might not be enough new users in the system. Ultimately, whether to lend or borrow from a user, we believe, should be a matter of choice, and no new node should be compelled to accept credit from, or lend credit to an existing user, simply because the existing user needs to rebalance their credit links. With this design goal in mind, we introduce the concept of balance transfer and bailout where any existing node can transfer its credit links to a new lender who offers a lower rate of interest, and an existing use can actively look for credit lenders in the system, with some help from a partially-online trusted bank. We now give an overview of the two steps that comprise our system.
Balance transfer: Figure 1 shows how the balance transfer process takes place in a credit network. Here any user can disconnect from an existing lender and transfer credit links to a new lender node offering a lower rate of interest.
In Figure 1 Part a) denotes a simple credit network where is a highly connected node. is a poorly connected node and would need to send requests to establish new incoming connections. To this end, first raises a request to add incoming nodes, by advertising a lower rate of interest, which will incentivize some of the nodes in the network to transfer their credits from their existing lender to . It is important to note here that, in our design, every node that wants to transfer to would have to transfer their full credit that exists with the current lender, and nodes are not allowed to establish an incoming link to with partial amount. This closely models the real-world balance transfer mechanisms where a user either transfers their debts (to a new lender) in the debt’s entirety, or not at all, but cannot partially transfer debts. Figure 1 Part b) depicts the network after two of ’s borrowers, have voluntarily transferred their balances to node , after severing their links with , thus has established several incoming links. At this point, all affected nodes will locally store their new links and link weights. After the bailout step, the changed network topology will be written to the blockchain.
Bailout: In the bailout process, a trusted, highly connected party such as a bank, or a credit union temporarily lends credit to node , so that can establish outgoing connections. We refer to this trusted party as a landmark, or . The high-level idea is that will use the fact that is is highly connected, and temporarily connect with several other nodes in the network with whom has a direct connection. will then request each of these nodes if they would like to lend credit to , thus establishing outgoing links form to them. Note that any or all nodes can decline ’s request, at which point will connect with a fresh set of nodes.
Figure 2 Part a) shows the bailout phase where the link between and other nodes are established after the balance transfer state. At this point, the poorly connected node has two incoming links after the execution of the balance transfer step. In order to make an active participant in transactions in the credit network, also needs outgoing links. After the balance transfer scenario, node sends request to the highly connected node, . provides a list of nodes, , that can potentially establish a outgoing link with , i.e., willing to lend credit to . will then send request to all of these nodes for an outgoing link. If none of the neighboring nodes are willing, helps to establish an outgoing link with any of the newer nodes that joined the system, or will give a fresh list of nodes. Figure 2 Part b) shows the network after nodes and agree to ’s request for outgoing links, establishes outgoing links with , at which point exits the network.
Iv Adversarial Model
In our system, we assume that any adversary can corrupt a single or a set of users in the network. The corrupted user(s) can be either the requester, who raises a rebalancing request, the nodes that respond to the request, or any intermediate node. During the bailout phase, we need a trusted landmark, , who is temporarily assists the requestor node. We assume the adversary cannot corrupt the node. Each user has her own signing and verification key pair and an encryption, decryption key pair . Once any user is corrupted, their corresponding signing and verification keys are compromised, the adversary can misreport the credit link between a user and her neighbor, not respond to any request, respond selectively to requests and relay fraudulent balance transfer requests to its neighbors. We assume that an adversary cannot corrupt all users in the network, and thus may know partial network topology, but does not know the entire network. We now give the desired security/privacy properties of a payment network that enables balance transfers and bailouts.
Iv-a Privacy and Security properties
Link privacy: Link privacy is achieved when an adversary only knows the value of links adjacent to her and will not have access to other nodes’ links, even if they were part of the balance transfer or bailout steps.
Corrupted users: We now discuss which users could possibly get corrupted, what can a corrupted user do, and how to mitigate the situation.
1) Corrupt balance transfer requestor node: Any user who sends the balance transfer request and can act maliciously, by claiming to have committed to one value (credit limit) in the request tuple, and later reneging on their commitment. The requestor node could also refuse to provide a low rate of interest, as advertised.
2) Corrupt responder node: Any node that responds to the balance transfer request can act maliciously by claiming to have responded with a different amount than the actual amount linked to the request id.
3) Corrupt intermediaries: Any user along the route from requestor to responder can be a malicious. Such adversarial users can either drop messages with or without making an entry into their logs, or mis-direct messages to other collaborating nodes in the network.
Accountability: Any malicious user should not be able to misreport her link value. In our system, each user maintains a record of their link weights with their next-hop neighbors in a local hash table. Each user involved in a rebalance transaction also holds signed contracts containing the current and updated link weights as a proof of link weight update. In case where any user behaves maliciously, the honest peers would be able to detect such malicious activity, also third-party arbiters can adjudicate based on the signed contracts. An arbitrator can be any law enforcing authority who on receiving a complaint can enforce legal punitive action according to local laws, or revoke nodes’ access to network. The exact nature of the remedial action taken by arbitrators is beyond the scope of this paper.
V Routing in Balance Transfers
In this section we discuss two different routing protocols we use for balance transfers in credit networks: prefix embedding  and Chord , and analyze and compare their efficiency. Note that these routing algorithms are not used for routing payments among nodes in our system, rather only for doing a balance transfer.
V-a Routing using Prefix Embedding
The first part of the balance transfer algorithm is the Find Route phase in which the responder node finds a route from itself to the requester. We make use of prefix embedding  and VOUTE  to establish a route after which rebalancing occurs. Prefix based embeddings are a part of greedy embeddings  . They are, in general, created by embedding a spanning tree into a suitable metric space. An ID is assigned to the root node, and the tree consists of several child nodes where each child computes the ID based on the ID of its parent node. Prefix embedding is an adaptation of PIE embedding for unweighted graphs. The idea is that, every node is assigned an ID using a custom metric space such that the node ID is equivalent to the hop distance or the depth of a spanning tree. A child’s id is essentially the ID of the parent, an additional coordinate equal to the index of the child. The prefix embedding algorithm uses the following equation to find the length of the shortest path between node and node , where is the common prefix length.
V-B Routing using Chord
Chord  is a routing algorithm built using distributed hash tables for peer-to-peer networks, without any centralized monitoring authority. Chord uses a pair to map to a specific node across the system. The keys are assigned to nodes using Consistent Hashing  across the network. Consistent hashing in Chord reduces the load in the system, since each node in a network requires the same number of keys and requires little movement of keys when nodes leave or join the system, making the system dynamically compatible.
Chord assigns a pair to each of the nodes in the system, where the key is the identifier using SHA-1 
and maps the keys to the nodes that are responsible for them. A peer identifier is chosen by hashing the data key. The length of the identifier is usually large to ensure the probability of keys hashing to the same identifier is negligible. The identifiers are arranged fromto , where is the digest size of the hash function used. Key is assigned to the first peer whose identifier is equal to or follows in identifier place and the first peer, clockwise from is called the successor peer of , represented by . When a peer joins or leaves the system, the keys that previously belonged to , is reassigned to successor. This enables maintaining consistent hashing in the system. For helping users join and leave the Chord network, we run a stabilization protocol at regular intervals that updates the finger table stored at each node. The finger table (FT) stored at each node is a table containing the IDs of its successors. Due to space constraints, we do not elaborate further on the working of prefix embedding and Chord; below we briefly compare their efficiency in terms of routing efficiency and network restrictions.
V-C Prefix Embedding vs. Chord
Routing efficiency: The main advantage using a Chord-based routing algorithm is that the number of hops to receiver is reduced, based on the density of the network. A peer leaving or joining the system does not involve too many changes to the key distribution to the system, although the successor pointers of some peers need to be changed. In prefix embedding, although, the users finds the shortest path, the worst case scenario for routing efficiency would be to find a route that traverses along the entire depth of the network.
Network Restrictions: A peer leaving or joining the system does not involve too many changes, although the successor pointers of some peers need to be changed. It is important to ensure that the successor pointers are up to date otherwise, the routing will fail in such a system. Hence there is a need to constantly update the finger table, as and when a change occurs. When peers fail, it is possible that a peer does not know its new successor, and that it has no chance to learn about it. Hence, the efficiency at which the finger tables are updated are ( is the number of nodes). In prefix embedding or VOUTE, the network need not monitor their nodes constantly and there is no maintenance cost incurred. The users can join and leave when they want making the network more adaptable and does not involve handing over keys, updating peers about leaving the system etc.
In this section, we describe the construction of our system, comprising of the balance transfer and bailout steps. We first present two different ways of doing the balance transfer step: using prefix embedding-based routing, and using Chord-based routing. Then we present our algorithms for the bailout step.
Vi-a Balance Transfer using Prefix Embedding
In this step, a responder node responds to a balance transfer request broadcast by another node in the network. The requester node broadcasts the amount available for accommodating the incoming nodes and the rate of interest. Any user who wants to transfer to user , needs to find a route to , and then initiate the balance transfer. This process is depicted in Algorithm 1.
In Algorithm 1, the parties involved are the requestor node, , the responder node, , and other intermediate nodes along the length of the response path. Node raises a balance transfer request by broadcasting the tuple . The tuple consists of the amount that can offer as credit, interest rate and a response time until when can accept responses from different nodes in the system (line 1,2). In line 3, finds the length of the route path using prefix embedding, where . Node finds the nearest node on the route, and computes hash of it’s co-ordinates in line 5. This hashed co-ordinates are used in prefix embedding to find the next neighbor and is computed using the common prefixes between and next node . Node computes in line 7, and creates a signature . Node does a and in line 8 of this algorithm. By using hashed coordinates, the address of the users are not made public, and the actual addresses are only available to the next-hop neighbors on the path. Then, sends a response to . In line 11-13, waits to ensure that does a of next address along the path, which ensures that the response is sent to the hashed address that is written to the shared hash-table between and its neighbors. If finds a malicious entry on the shared hash-table, can choose to send the response through a different route. Node receives responses in line 15 of this algorithm. Node saves all responses in if the responses are received within time and the amount in response in lines 16, 17. In line 19 of this algorithm, source node is set to , , and . For every response that receives, verifies if updated , and calls algorithm in line 21 and produces contract . The function creates shared, signed contracts between two adjacent nodes; we do not give the algorithm here due to space constraints. Once initiates the algorithm, node pays the amount lent by in line 22. Then, node updates her hash-table after receiving and deletes the hash-table entry with . Node deletes her entry in hash-table and they sign an acknowledgement of the update (line 24, 25), and produces . The operation returns , which is written to blockchain by in line 26 of this algorithm.
Vi-B Balance Transfer Algorithm using Chord
In this section, we discuss the balance transfer process using Chord for routing, Algorithm 2. The first phase of this algorithm consists of the Find Route phase, where the user , referred to as the responder node, responds to a request raised by a requestor node . Node raises a request in line 2 of this algorithm with a tuple = , where, is the amount that is extended as credit, is the rate of interest offered, is the time period within which the response is accepted and which is used in finding the route to the user in a chord network. Node broadcasts the request to all users in line 3. Node responds to by first locating the of , in line 4. If node is an immediate neighbor of from its finger table , responds with in line 6. If node is not among ’s immediate neighbors, finds the nearest node from and sends the response in line 9 of this algorithm. Every intermediate node along the length of the path , does a lookup(key) in their corresponding in line 11. Every node does the steps 6 to 13 until the reaches node (requester). Node receives all responses accepted within time and stores in in line 16. In line 18, source node is set to , , and . For every response that saved, verifies if updated , calls the Multisig algorithm in line 20, produces contract . Each node in then updates the link weight between and to 0 in line 21. The node signs of , produces in line 22 of this algorithm, verifies and creates in line 23, and in line 24, the nodes and delete their corresponding hash table entry. The node writes to blockchain in line 25. Once the MultiSig operation is complete, node repositions itself in the Chord ring after informing the successors and predecessors in the Chord in line 27 and 28. Every node from ’s previous position to new position, update their finger table by calling the function to update their respective finger table entries. also calls the function to update her finger table with new successors after relocating in line 32.
Vi-C Bailout Phase
The bailout step is the final step in the rebalancing process and is given in Algorithm 3. Node , in this algorithm requests for outgoing nodes through the node. The main aim of this algorithm is to connect with multiple outgoing nodes successfully with the help of the landmark node (). In line 2 of this algorithm, node sends a request to to connect or find nodes that would ideally, like to establish an outgoing link with . returns a list of identities, where . waits for a response time within which atleast one outgoing link is established and this is done in line 4. In line 6, calls the to through . In line 7 of this algorithm, if any responds with a “val”, then calls the function. If all nodes respond with a “, then responds with a new set of in line 11 of this algorithm. In line 13, calls . In line 16, writes to blockchain. In line 17, exits the network after collecting a small fee from , which is computed based on the number of links established. In the unlikely event that none of the nodes in the list sent by is interested in establishing a outgoing connection from , does steps 2-13 again with a new list of .
Vii Implementation and Evaluation
We simulated Chord-based routing using  as a base, and implemented cryptographic primitives in Charm . For signatures, we used ECDSA on curve prime192v2 and used RSA 2048 for encryption. Our experiments were run on a desktop class computer with Intel(R) Core(TM) i3-7100 CPU @ 3.90GHzx4 and 8GB RAM on Ubuntu-18.04 platform. Table I shows time taken for cryptographic operations in every phase.
|Operation||Signature (msec)||Verification (msec)||Encryption (msec)|
|Balance Transfer (Prefix Embedding)||3.355||3.7733||0.1707|
|Balance Transfer (Chord)||1.9678||2.2786||-|
In order to simulate the chord network, we have made use of  simulator. The experiment was run on an intel i-3 generation-7 desktop with 8GB of RAM. We recorded the time taken for setting up the chord ring, broadcasting a message and we also calculated the minimum and maximum number of hops it takes for a source to reach its destination. In the “Setup” operation, we record time taken for setting up the Chord network ring for a total of 1000 nodes. The “Lookup” operation involves finding the route by performing a from the finger table. Time taken for response phase is the total time taken for doing a and respond to the broadcast message. “Re-assign and Stabilize” is the final operation which involves updating finger tables for all the successors and predecessors of the re-positioned node, after the balance transfer operation has been carried out. The time taken for setup varies linearly with the number of users added to the Chord network.
|Setup (1000 users)||23.0650 sec|
|Broadcast BT||13.913 sec|
|Lookup and Response||20.7730 sec|
|Re-assign and Stabilize||10.6676 sec|
We give the timings for balance transfer using prefix embedding in Table III. We used the GTNA package  to implement balance transfer using Prefix Embedding. The time taken for “Setup” which involves, creating a network of 1000 users, assigning links and link weights and creating embedding co-ordinates is given in table III. The “Broadcast BT” represents the time taken for a requester sending out a BT (Balance Transfer) request tuple, which contains the position and amount for balance transfer. “FindRoute and Respond” operation is the process of finding route between a requester and responder, and also includes the time taken for sending out the response which is the encrypted value of the amount that any user is willing to balance transfer with the requester. This also includes the time taken for the user to establish an edge with the requester (create an edge between two nodes in the graph). The setup time increases linearly with increase in number of users, as expected. For “Find Route and Response”, the time taken to route from the first node to the farthest node in the graph is given here, since that would be the longest routing path, a node would encounter. Since the graph generated by GTNA is unstructured, and randomly generated each time, we give the average value of 100 runs for 1000 users in Table III.
|Setup (1000 users)||26.64 msec|
|Broadcast BT||0.144 msec|
|FindRoute and Response||25.38 msec|
Table IV shows the time for bailout operation after performing balance transfer. We recorded time for setting up the network from 1000 to 10000 users. Here the setup refers to establishing connections from landmark to all the other nodes in the network. For 1000 users, the setup time for Bailout is seconds and the value increases with increase in number of users.. ’Create Edges’ involves establishing edge and edge weights between the requester and other nodes who are willing to extend credits. The time taken for FindRoute is the total time taken for all the 10 nodes selected by landmark node to route to requester node.
|Number of Users||Setup (time in msec)||FindRoute (time in msec)||Create Edges (time in msec)|
Figure 3 shows the time taken for operations in balance transfer in prefix embedding. We obtain the values for 1000, 2000, 4000, 8000, 10000 users by taking a average on 100 values for each operations. We plotted the time taken for operation against number of users and the time for all the operations (except broadcast) with increasing number of users. The time taken for broadcast will not vary or increase with the number of users since, this operation involves creating a balance transfer tuple and sending it out into the network, regardless of the number of users in the network.
Viii Conclusion and future work
In this paper, we have proposed a new technique for rebalancing in credit networks that would help a poorly connected node rebalance its links, and become an active participant in the network, thus making the network robust, more competitive, and increasing the overall throughput of the network. Our method involves a poorly connected node creating incoming links using a process called balance transfer and creating outgoing links using a process called bailout. We present the high-level ideas and and prototype them in this paper; as a part of future work, we envision to implement the idea on a real world credit network such as Ripple .
-  (2013) Charm: a framework for rapidly prototyping cryptosystems. J. Cryptographic Engineering 3 (2), pp. 111–128. Cited by: §VII.
-  (2015) Ripple: overview and outlook. In International Conference on Trust and Trustworthy Computing, pp. 163–180. Cited by: §I, §II, §III, §VIII.
-  (2004) Peer-to-peer computing in distributed hash table models using a consistent hashing extension for access-intensive keys. In Agents and Peer-to-Peer Computing, Third International Workshop, AP2PC, 2004, New York, NY, USA, July 19, 2004, Revised and Invited Papers, G. Moro, S. Bergamaschi, and K. Aberer (Eds.), Lecture Notes in Computer Science, Vol. 3601, pp. 185–192. External Links: Cited by: §V-B.
-  Https://ripiocredit.network/. Cited by: §II.
-  (2011) PeerSim: an efficient & scalable testbed for heterogeneous cluster-based p2p network protocols. In Proc. of the 2011 UKSim International conference on modeling and simulation, pp. 420–425. Cited by: §VII, §VII.
-  (2017) Revive: rebalancing off-blockchain payment networks. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, pp. 439–453. Cited by: §II.
-  (2010) Some results on greedy embeddings in metric spaces. Discrete & Computational Geometry 44 (3), pp. 686–705. External Links: Cited by: §V-A.
-  (2017) Concurrency and privacy with payment-channel networks. In Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security, pp. 455–471. Cited by: §II.
-  (2017) SilentWhispers: enforcing security and privacy in decentralized credit networks.. In NDSS, Cited by: §I, §II, §II.
-  (2019) DLSAG: non-interactive refund transactions for interoperable payment channels in monero. IACR Cryptology ePrint Archive 2019, pp. 595. External Links: Cited by: §II.
-  (2017) Pathshuffle: credit mixing and anonymous payments for ripple. Proceedings on Privacy Enhancing Technologies 2017 (3), pp. 110–129. Cited by: §II.
-  (2008) Bitcoin: a peer-to-peer electronic cash system. Working Paper. Cited by: §I.
-  (2008) Stellar. https://www.stellar.org. Cited by: §I.
-  (1995) 180-1: secure hash standard. April. Cited by: §V-B.
-  (2016) Monero research lab.“. Ring Confidential Transactions.” Ledger 1, pp. 1–18. Cited by: §II.
-  (2019) BlAnC: blockchain-based anonymous and decentralized credit networks. In In Ninth ACM Conference on Data and Application Security and Privacy (CODASPY’19), Cited by: §I, §II.
-  (2016) The bitcoin lightning network: scalable off-chain instant payments. Cited by: §II.
-  (2016) Flare: an approach to routing in lightning network. White Paper. Cited by: §I.
-  (2016) VOUTE-virtual overlays using tree embeddings. External Links: Cited by: §I, §V-A.
-  (2017) Settling payments fast and private: efficient decentralized routing for path-based transactions. arXiv preprint arXiv:1709.05748. Cited by: §II.
-  (2014) Enhancing compact routing in CCN with prefix embedding and topology-aware hashing. In Proceedings of the 9th ACM Workshop on Mobility in the Evolving Internet Architecture, MobiArch 2014, Maui, HI, USA, September 11, 2014, R. L. Aguiar and K. Guo (Eds.), pp. 49–54. External Links: Cited by: §V-A, §V.
-  (2013) GTNA 2.0 - a framework for rapid prototyping and evaluation of routing algorithms. In 2013 Summer Simulation Multiconference, SummerSim ’13, Toronto, Canada - July 07 - 10, 2013, pp. 23. Cited by: §VII.
-  (2003) Chord: a scalable peer-to-peer lookup protocol for internet applications. IEEE/ACM Trans. Netw. 11 (1), pp. 17–32. External Links: Cited by: §I, §V-B, §V.