Content uploaded by Mariusz Nowostawski
Author content
All content in this area was uploaded by Mariusz Nowostawski on Feb 06, 2019
Content may be subject to copyright.
Split Payments in Payment Networks
Dmytro Piatkivskyi(B
)and Mariusz Nowostawski
NTNU, Trondheim, Norway
{dmytro.piatkivskyi,mariusz.nowostawski}@ntnu.no
Abstract. Traditional blockchain systems, such as Bitcoin, focus on
transactions in which entire amount is transferred from one owner to the
other, in a single, atomic operation. This model has been re-used in the
context of payment networks such as Lightning network. In this work,
we propose and investigate new payment model, called split payments,
in which the total amount to be transferred is split into unit-amounts
and is transferred independently through the same or different routes. By
splitting the payments this way, we achieve an improved total liquidity of
the payment network, simplify the route advertising, reduce the amount
of funds needed to be locked in the channels, and improve the privacy
properties.
1 Introduction
The scalability problem of Bitcoin has received considerable attention by the
community. Various solutions have been proposed [1–3] and one of the most
promising is the utilization of off-chain transactions, for example through the
Lightning network [4]. Off-chain payment network is based on the concept of
state channels that can operate offline, consulting the blockchain only when
opening or closing a channel. The state channels form a payment network which
allows for peer-to-peer instantaneous transactions.
The payment networks ultimately solve the inherent blockchain scalability
limitation, however, the payment networks themselves are limited in many ways.
They require careful consideration and appropriate balancing of multiple, often
competing, trade offs. Many properties of the network will depend on the way
the network organizes itself. Implementation choices will make a great difference.
In this paper we demonstrate how to better organize the network. In particular,
we suggest to abandon the idea of single atomic payments and to embrace the
concept of money flows, and the use of split payments. We show that splitting
payments into a number of unit payments improves a number of important
properties, such as liquidity, funds lock-in, and privacy.
2 Background and Past Work
The Lightning network is a payment protocol built on top of the Bitcoin proto-
col. It allows for transaction throughput scaling by keeping and updating Bit-
coin transactions off-chain. A Lightning network transaction is processed within
c
Springer Nature Switzerland AG 2018
J. Garcia-Alfaro et al. (Eds.): DPM 2018/CBT 2018, LNCS 11025, pp. 67–75, 2018.
https://doi.org/10.1007/978-3-030-00305-0_5
68 D. Piatkivskyi and M. Nowostawski
Lightning channels which are actually Bitcoin transactions. The idea is that two
users mutually fund a Bitcoin transaction, the Fun d i n g transaction, and spend it
returning the invested funds with the Commitment transaction. They both sign
the commitment transactions, but only publish the funding transactions on the
blockchain. Once a channel is established, i.e. the funding transaction reaches the
blockchain, funds can be moved within the channel (up to the channel capacity)
by simply updating the commitment transaction. When any participant wants
to spend funds outside the payment network, the channel is closed by publishing
the current state of the commitment transaction to the blockchain.
One can route a payment through intermediate nodes. For example, if there
is a channel between Alice and Bob and a channel between Bob and Charlie,
Alice can send funds to Charlie through Bob. The technique that makes payment
routing possible is called Hashed Timelock Contract (HTLC). For more details
on its implementation the reader should refer the original paper [4].
Payment networks are not a new concept. They are studied under different
variations of the notion – trust networks [5–7], credit networks [8], path-based
transaction (PBT) networks [9] and Payment-Channel Networks (PCN) [10].
There were efforts undertaken to improve the Lightning network. Flare [11]
suggests maintaining routing tables to be able to discover paths in the network.
Roos et al. [9] proposed an alternative routing scheme that is privacy preserving.
Grunspan and P´erez-Marco [12] put forward an idea of ant routing where path
lookup requests are passed from node to node in the network. Decker et al. [13]
suggested an improvement over the Lightning transaction update mechanism.
Malavolta et al. [14] studied the mechanism which binds transactions together,
so they can be routed. Another paper from this research group [10] demon-
strated a rather surprising trade off between privacy and concurrency in PCNs,
and impossibility to achieve both simultaneously. In the later parts of this article,
we will show that our proposed mechanism addresses and mitigates the prob-
lem. Piatkivskyi et al. [15] brought attention to the problem of colluding nodes
and discussed how it influences forensics of the Lightning network. Herrera-
Joancomarti et al. [16] gave an overview on the state of the art in privacy issues
of payment networks.
3 Split Payments
3.1 Payment Splitting Proposal
The core idea of our proposal is to split payments into a number of smaller
sub-payments of equal amounts, i.e. a number of payments of unit amounts,
and send them independently, not preserving the atomicity property. There are
various ways to split payments up. One way of doing so is amounts of the orders
of 10. If a user wants to pay 23 k satoshi, she splits the payment into 2 sub-
payments of 10k satoshi and 3 sub-payments of 1 k satoshi.
Split payments are to be sent independently. At the moment of payment ini-
tiation, the sender calculates the cheapest path and begins establishing HTLCs
by that path starting with the larger sub-payments. If at any point of time an
Split Payments in Payment Networks 69
HTLC establishment fails, or the sender receives a fee update, she suspends the
sub-payments for which HTLCs have not yet been established and re-calculates
the cheapest path again. Then the suspended sub-payments are resumed to be
sent by the new cheapest path. It may happen that for some larger sub-payment
there is no path of needed capacity. In such a case the sub-payment has to be
further split. If there is no capacity to route any payments in the needed direc-
tion, the whole sub-payment queue is suspended for a timeout. After the timeout
is elapsed, an attempt to send the sub-payment is repeated. This process could
continue indefinitely until the payment is complete. The user sets a time frame
within which the payment is expected to execute. We call such parameter time
to live (TTL). Obviously, some payments have to be carried out instantly,
while other can wait. It will make a trade off between the time it takes to com-
plete a payment and the fee paid for that payment. A payment is considered
successful if all sub-payments are successfully delivered within the set TTL.Ifa
payment has not been delivered within the set TTL, it is marked as failed, even
though it could have been partially sent. Such payments are not sent back, con-
sequentially failed payments change the balances of the nodes en route. Partial
transitions are further discussed in the following sections.
3.2 Atomic Multi-path Payments
Atomic multi-path payments (AMP) [17] are the implementation of the concept
of flows in a flow network. There are number of principal differences that sets
AMP and split payments apart. The main difference is that the whole AMP
flow executes atomically, that is either all of the sub-payments are sent at once
or none. For that, each extended sub-payment remains pending until all sub-
payment flows are extended. That increases the duration of funds being locked.
The superiority of split payments success rate comes from the fact that an
AMP fails if maximum flow between two nodes is less than the payment amount.
Split payments still attempt to execute. As sub-payments are timely spread,
there is a chance that within the execution window some payments will pass
in the opposite direction increasing the maximum amount that can be sent.
A substantial disadvantage is that a payment can be only partially executed.
Notwithstanding the transaction acknowledgement complications, we deem par-
tial payments harmless as the rest of the payment can be sent on-chain using
splicing [18], if to be sent from a Lightning channel. We stress that partially exe-
cuted payments do not introduce additional inconvenience. If a payment cannot
be executed, it has to be sent in any other way anyway. The non-executed part
of a payment can be sent the very same way the whole failed payment would
have to be sent.
70 D. Piatkivskyi and M. Nowostawski
3.3 Network Analysis
Privacy. The privacy benefits of the proposed strategy are many. First of all,
there is no need for routing nodes to disclose current channel capacities. Instead,
the paying node, knowing the static topology, can simply request unit pay-
ments. The probability that a particular path is able to route a payment is
relatively high, given the small unit payment amount. Besides, the fact that all
the payments could only be of a certain unit amount makes the payment cor-
relation analysis difficult. Timing analysis will be significantly complicated as
there expected to be a large number of such unit payments in the network.
Security. In our proposal the collateral risk is relatively low with split payments
because all the actual payments are of unit amount only. If a sub-payment gets
stuck, the sender stops using the routing node that failed. Moreover, as there
exists a threat of losing money to colluded receiver and a node en route [15],
the maximum loss is limited by the amount of the largest sub-payment. If the
sender loses money to the colluding nodes, it can simply stop casting the flow.
Concurrency. Split payments transform the problem of possible occurrence of
a deadlock into a performance bottleneck. While deadlocks are still theoretically
possible, for it to happen a number of sub-payments totaling to the channel
capacity have to conglomerate simultaneously at two nodes. We consider the
chance of such a deadlock negligible, resolving the trade-off between privacy and
concurrency in payment networks described in [10].
Lower fees. The described use of network will presumably yield lower fees for
transactions. First of all, it may happen that the cheapest path is not able to
process the whole payment due to capacity limitation. Secondly, since payments
are sent sequentially, it may happen that a cheaper path will appear some time
after the payment has been issued. Most importantly, the more efficient network
will naturally drive the transaction cost down.
4 Simulation
A massive effort have been invested into developing a Lightning network simula-
tor called Blyskavka (a Ukrainian word for Lightning). The simulator is meant to
be open source, yet making it public requires certain preparations which hinders
the release. Blyskavka is a multi-agent simulator that was built for general pur-
pose payment network simulations. It is written in java and uses MASON [19]as
a simulation engine. Blyskavka simulates the Lightning network operation rather
than the Lightning network itself, meaning it does not simulate the actual trans-
actions being signed and the blockchain communication. It does open and close
channels that are modelled as graph edges. It also simulates HTLC’s by blocking
and then releasing amounts on the path.
Split Payments in Payment Networks 71
The simulation works with the Newman-Watts–Strogatz model of the small-
world network family, the uniform random graph model and a custom model
that we call peripheral.Theperipheral graph model differentiates between the
core network that consists of routing nodes and the wallet nodes that connect
to the core network — the peripheral network. The core network is generated
following any other model. Having generated the core network, the wallet nodes
are added, choosing randomly Krouting nodes to connect to.
The simulation is discrete event based. Each simulation step a node decides
what to do—whether to send a payment or not. In all the experiments the
payment frequency for each node is once every 25 simulation steps. If a node
decides to transfer money, it randomly with uniform distribution selects the
destination node and the payment amount within the set range—between 0.1
and 20. As a result, nodes create uniform and symmetric traffic in the network.
As payments can be delayed, they are scheduled as well. Each step a payment
makes an attempt to execute itself – atomic payments at once, split payments
a unit amount sub-payment at a time. If a payment cannot be executed, it is
scheduled for the next step until it is out of time to live (TTL). The simulation
is flexible on what metrics it can take measurements of. For the purpose of the
described research, only success rate was of interest.
For this research we generate both, hub-and-spoke and organic topologies.
Hub-and-spoke topology correspond to the peripheral graph model, organic
topology is described by either the Newman-Watts–Strogatz model or by the
uniform random graph model.
In our experiments we study networks of 1000 and 10000 nodes with different
level of connectivity, defined by the parameter K. The small network size is
dictated by the poor scalability of the simulator. Hub-and-spoke network has the
core network consisting of 20 nodes for the network size of 1000 nodes and 50
nodes for the network size of 10000 nodes. The numbers are chosen deliberately
so that the success rate starts low enough to show its increase with TTL value.
Each node, regardless if it is a routing or wallet node, has Kchannels with initial
capacity of 5 on each side. For this research channel cost is disregarded.
Intuitively, and then proven experimentally, the organic topology efficiency
grows with the number of channels in the network. Organic topology with K=2
is very inefficient, hence we set K=4. To match the total funds invested into
the hub-and-spoke network under scrutiny, the initial channel capacities should
remain 5. We also generate higher connectivity networks with K=4 for hub-
and-spoke network and K=8 for organic network.
5 Experiments
It is hard to study the effects a change of a variable causes in the various net-
work properties. For that, all variables that could also affect the success rate of
the network have to be fixed, while still conserving the adequate liveliness and
soundness of the network. To reduce the number of confounding variables, we
randomly generate an instance of a particular network topology, with a given
72 D. Piatkivskyi and M. Nowostawski
fixed properties. Any comparison is done then for exactly the same network
configuration.
In the experiments described in this article TTL is an independent variable,
i.e. we study the dependency of success rate on the TTL value. For that, TTL
is being varied from 50 simulation steps (where slight TTL increase brings a
considerable difference in success rate) to 2000 simulation steps (where there is
no longer any substantial increase in success rate with growing value of TTL).
That demonstrates how the network improves with longer TTL.
The experiments were performed within a strictly defined framework. Each
run lasts at least N=3∗TTL simulation steps and repeated multiple times
to investigate the variance across runs. Furthermore, network topologies were
generated randomly and for the same configuration there were generated multiple
instances of the same topology, to compensate for a particular instance favouring
one or the other model, just out of pure chance of the connectivity of a given
instance.
The ultimate benchmark for the network we deem the success rate. To ade-
quately measure it, we run the simulation for a number of steps N, but stop
accounting transactions into statistics TTL steps before it finishes. This leaves
each transaction enough time to either complete or fail. The transactions in
the network, however, are continuously generated and they continue creating
traffic (Fig. 1).
5.1 Split payments vs. AMP
The core of the experiments was focused on the comparison of split payments
and AMPs. The first thing to notice is the striking difference the splitting makes
across all charts, particularly in case of the organic topology. With TTL > 1000,
0 500 1000 1500 2000
0.0 0.2 0.4 0.6 0.8 1.0
Hub−and−spoke topology, K=2
TTL
Success rate
split
non−split
0 500 1000 1500 2000
0.0 0.2 0.4 0.6 0.8 1.0
Hub−and−spoke topology, K=4
TTL
Success rate
split
non−split
Fig. 1. A 20-1k hub-and-spoke network.
Split Payments in Payment Networks 73
the difference is above 35%. The hub-and-spoke network also shows a signifi-
cant improvement which is more constant and makes up over 10% improvement,
reaching 20% difference for TTL > 1000. Those experimental results demon-
strate the superiority of split payments when it comes to liquidity. Apart from
proving the better performance of split payments these graphs provide hints
about what network configurations are more efficient. Even though promising,
those hints are not to be considered facts and need to be verified in a more
rigorous manner.
Better connectivity networks. In all of the experiments we keep the amount
invested in the network at the same level to make the comparisons meaningful.
Therefore, when increasing the number of channels Ktwofold, we divide the
average channel capacity by 2. All the figures suggest that it is better to invest
less in a single channel and have more channels established. In other words, the
more interconnected the network the greater its performance.
Hub-and-spoke topology efficiency. Hub-and-spoke topology is by far out-
performing the organic topology, even when the latter has twice as many chan-
nels (of half capacity, so the total investment in the network remains constant).
Important to note that wallet nodes in the hub-and-spoke topology are not con-
sidered when routing. If they take part relaying payments, the efficiency, hence
the liquidity, grows considerably. This suggests that in spite of all the shortcom-
ings, some form of centralization will be present as it constitutes a major factor
to the network efficiency.
High intensity traffic. Having the same core network, but increased number
of wallet nodes increases the success rate in the hub-and-spoke network. The
organic network, on the other hand, suffers from the growing number of nodes.
On the other hand, the splitting strategy shows the best efficiency for larger
organic topologies making the difference of about up to 65%, taking up 34%
0 1000 2000 3000 4000 5000
0.0 0.2 0.4 0.6 0.8 1.0
Organic topology, K=4
TTL
Success rate
split
non−split
0 500 1000 1500 2000
0.0 0.2 0.4 0.6 0.8 1.0
Organic topology, K=8
TTL
Success rate
split
non−split
Fig. 2. An organic topology of 1000 nodes.
74 D. Piatkivskyi and M. Nowostawski
success rate of atomic multi-path payments to 99% of split payments. This is a
rather considerable improvement over the atomic baseline.
200 400 600 800 1000
0.0 0.2 0.4 0.6 0.8 1.0
Hub−and−spoke topology, K=2
TTL
Success rate
200 400 600 800 1000
0.0 0.2 0.4 0.6 0.8 1.0
Organic topology, K=8
TTL
Success rate
split
non−split
Fig. 3. Networks of 10000 nodes.
6 Conclusions
We have introduced the area of research focusing on payment networks and
money flows. We have investigated an improvement in the design of the pay-
ment network, based on the split payment model. The new strategy has been
experimentally demonstrated to substantially increase the liquidity of payment
network. We have investigated what payment network topological characteristics
tend to yield better liquidity. Another important contribution is the Lightning
network simulator, named Blyskavka, that has been designed to be general-
purpose and we expect it to be used in the future research work on payment
networks.
References
1. Poelstra, A.: Mimblewimble, 06 October 2016
2. Back, A., et al.: Enabling blockchain innovations with pegged sidechains (2014).
http://www.opensciencereview.com/papers/123/enablingblockchain-innovations-
with-pegged- sidechains
3. Decker, C., Wattenhofer, R.: A fast and scalable payment network with bitcoin
duplex micropayment channels. In: Pelc, A., Schwarzmann, A.A. (eds.) SSS 2015.
LNCS, vol. 9212, pp. 3–18. Springer, Cham (2015). https://doi.org/10.1007/978-
3-319-21741-3 1
4. Poon, J., Dryja, T.: The Bitcoin Lightning Network: Scalable Off-Chain Instant
Payments. Draft version 0.5.9.2, 14 January 2016
Split Payments in Payment Networks 75
5. Ghosh, A., Mahdian, M., Reeves, D.M., Pennock, D.M., Fugger, R.: Mechanism
design on trust networks. In: Deng, X., Graham, F.C. (eds.) WINE 2007. LNCS,
vol. 4858, pp. 257–268. Springer, Heidelberg (2007). https://doi.org/10.1007/978-
3-540-77105-0 25
6. Karlan, D., Mobius, M., Rosenblat, T., Szeidl, A.: Trust and social collateral*. Q.
J. Econ. 124(3), 1307–1361 (2009)
7. Resnick, P., Sami, R.: Sybilproof transitive trust protocols. In: Proceedings of the
10th ACM Conference on Electronic Commerce, EC 2009, pp. 345–354. ACM, New
York (2009)
8. Dandekar, P., Goel, A., Govindan, R., Post, I.: Liquidity in credit networks: a little
trust goes a long way. In: Proceedings of the 12th ACM Conference on Electronic
Commerce, EC 2011, pp. 147–156. ACM, New York (2011)
9. Roos, S., Moreno-Sanchez, P., Kate, A., Goldberg, I.: Settling payments fast
and private: efficient decentralized routing for path-based transactions. CoRR,
arXiv:abs/1709.05748 (2017)
10. Malavolta, G., Moreno-Sanchez, P., Kate, A., Maffei, M., Ravi, S.: Concurrency
and privacy with payment-channel networks. In: Proceedings of the 2017 ACM
SIGSAC Conference on Computer and Communications Security, CCS 2017, pp.
455–471. ACM, New York (2017)
11. Prihodko, P., Zhigulin, S., Sahno, M., Ostrovskiy, A., Osuntokun, O.: Flare: An
approach to routing in lightning network (2016)
12. Grunspan, C., P´erez-Marco, R.: Ant routing algorithm for the Lightning Network.
ArXiv e-prints, June 2018
13. Decker, C., Russell, R., Osuntokun, O.: eltoo: A Simple Layer2 Protocol for Bitcoin.
https://blockstream.com/eltoo.pdf (2018)
14. Malavolta, G., Moreno-Sanchez, P., Schneidewind, C., Kate, A., Maffei, M.: Multi-
hop locks for secure, privacy-preserving and interoperable payment-channel net-
works. IACR Cryptology ePrint Archive, 2018:472 (2018)
15. Piatkivskyi, D., Axelsson, S., Nowostawski, M.: A Collusion Attack on the Light-
ning Network – Implications for Forensics (2017)
16. Herrera-Joancomart´ı, J., P´erez-Sol`a, C.: Privacy in bitcoin transactions: new chal-
lenges from blockchain scalability solutions. In: Torra, V., Narukawa, Y., Navarro-
Arribas, G., Ya˜nez, C. (eds.) MDAI 2016. LNCS (LNAI), vol. 9880, pp. 26–44.
Springer, Cham (2016). https://doi.org/10.1007/978-3-319-45656-0 3
17. Osuntokun, O.: AMP: Atomic Multi-Path Payments over Lightning, 06 February
2018
18. Reducing the number of blockchain transactions used by the LN, and the fees paid
to confirm them, 21 December 2017
19. Luke, S., Cioffi-Revilla, C., Panait, L., Sullivan, K., Balan, G.: MASON: a multi-
agent simulation environment. Simulation 81(7), 517–527 (2005)
