Abstract
Lightning Network (LN), the most widely deployed payment channel for Bitcoin, requires channel parties to generate and store distinct revocation keys for all n payments of a channel to resolve fraudulent channel closures. To reduce the required storage in a payment channel, eltoo introduces a new signature type for Bitcoin to enable payment versioning. This allows a channel party to revoke all old payments by using a payment with a higher version number, reducing the storage complexity from \(\mathcal {O}(n)\) to \(\mathcal {O}(1)\). However, eltoo fails to achieve bounded closure, enabling a dishonest channel party to significantly delay the channel closure process. Eltoo also lacks a punishment mechanism, which may incentivize profit-driven channel parties to close a payment channel with an old state, to their own advantage.
This paper introduces Daric, a payment channel with unlimited lifetime for Bitcoin that achieves optimal storage and bounded closure. Moreover, Daric implements a punishment mechanism and simultaneously avoids the methods other schemes commonly use to enable punishment: 1) state duplication which leads to exponential increase in the number of transactions with the number of applications on top of each other or 2) dedicated design of adaptor signatures which introduces compatibility issues with BLS or most post-quantum resistant digital signatures. We also formalise Daric and prove its security in the Universal Composability model.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
Pay-to-Witness-Script-Hash: Used to lock bitcoin to a SegWit script hash.
- 2.
Pay-to-Witness-Public-Key-Hash: Used to lock bitcoin to a SegWit public key hash.
References
Lightning channels - top capacity. https://1ml.com/channel?order=capacity
eltoo: A simplified update mechanism for lightning and off-chain contracts (2018). https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-June/001313.html
Using per-update credential to enable eltoo-penalty (2019). https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002068.html
Bolt 5: Recommendations for on-chain transaction handling (2021). https://github.com/lightningnetwork/lightning-rfc/blob/master/05-onchain.md
Aumayr, L., Ersoy, O., Erwig, A., Faust, S., Hostáková, K., Maffei, M., Moreno-Sanchez, P., Riahi, S.: Generalized channels from limited blockchain scripts and adaptor signatures. In: Tibouchi, M., Wang, H. (eds.) ASIACRYPT 2021. LNCS, vol. 13091, pp. 635–664. Springer, Cham (2021). https://doi.org/10.1007/978-3-030-92075-3_22
Aumayr, L., Maffei, M., Ersoy, O., Erwig, A., Faust, S., Riahi, S., Hostáková, K., Moreno-Sanchez, P.: Bitcoin-compatible virtual channels. In: 2021 IEEE Symposium on Security and Privacy (SP), pp. 901–918. IEEE (2021)
Aumayr, L., Thyagarajan, S.A., Malavolta, G., Moreno-Sanchez, P., Maffei, M.: Sleepy channels: Bitcoin-compatible bi-directional payment channels without watchtowers. Cryptology ePrint Archive (2021)
Avarikioti, G., Litos, O.S.T., Wattenhofer, R.: Cerberus channels: Incentivizing watchtowers for bitcoin. Financial Cryptography and Data Security (FC) (2020)
Bamert, T., Decker, C., Elsen, L., Wattenhofer, R., Welten, S.: Have a snack, pay with bitcoins. In: IEEE P2P 2013 Proceedings, pp. 1–5. IEEE (2013)
Canetti, R.: Universally composable security: a new paradigm for cryptographic protocols. In: Proceedings 42nd IEEE Symposium on Foundations of Computer Science, pp. 136–145. IEEE (2001)
Canetti, R., Dodis, Y., Pass, R., Walfish, S.: Universally composable security with global setup. In: Vadhan, S.P. (ed.) TCC 2007. LNCS, vol. 4392, pp. 61–85. Springer, Heidelberg (2007). https://doi.org/10.1007/978-3-540-70936-7_4
Decker, C., Russell, R., Osuntokun, O.: eltoo: A simple layer2 protocol for bitcoin. White paper. https://blockstream.com/eltoo.pdf (2018)
Decker, C., Towns, A.: Bip 118: Sighash_anyprevout for taproot scripts (2017). https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki
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
Dziembowski, S., Eckey, L., Faust, S., Hesse, J., Hostáková, K.: Multi-party virtual state channels. In: Ishai, Y., Rijmen, V. (eds.) EUROCRYPT 2019. LNCS, vol. 11476, pp. 625–656. Springer, Cham (2019). https://doi.org/10.1007/978-3-030-17653-2_21
Dziembowski, S., Eckey, L., Faust, S., Malinowski, D.: Perun: virtual payment hubs over cryptocurrencies. In: 2019 IEEE Symposium on Security and Privacy (SP), pp. 106–123. IEEE (2019)
Dziembowski, S., Faust, S., Hostáková, K.: General state channel networks. In: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pp. 949–966 (2018)
Khabbazian, M., Nadahalli, T., Wattenhofer, R.: Outpost: a responsive lightweight watchtower. In: Proceedings of the 1st ACM Conference on Advances in Financial Technologies, pp. 31–40 (2019)
Lind, J., Naor, O., Eyal, I., Kelbert, F., Sirer, E.G., Pietzuch, P.: Teechain: a secure payment network with asynchronous blockchain access. In: Proceedings of the 27th ACM Symposium on Operating Systems Principles, pp. 63–79 (2019)
Mirzaei, A., Sakzad, A., Yu, J., Steinfeld, R.: FPPW: a fair and privacy preserving watchtower for bitcoin. In: Borisov, N., Diaz, C. (eds.) FC 2021. LNCS, vol. 12675, pp. 151–169. Springer, Heidelberg (2021). https://doi.org/10.1007/978-3-662-64331-0_8
Mirzaei, A., Sakzad, A., Yu, J., Steinfeld, R.: Daric: a storage efficient payment channel with punishment mechanism. Cryptology ePrint Archive, Report 2022/1295 (2022). https://eprint.iacr.org/2022/1295
Mirzaei, A., Sakzad, A., Yu, J., Steinfeld, R.: Garrison: a novel watchtower scheme for bitcoin. Cryptology ePrint Archive, Report 2022/1300 (2022). https://eprint.iacr.org/2022/1300
Pickhardt, R.: Does eltoo eliminate the need to watch the blockchain/implement watchtowers (2019). https://bitcoin.stackexchange.com/questions/84846/does-eltoo-eliminate-the-need-to-watch-the-blockchain-implement-watchtowers
Poon, J., Dryja, T.: The bitcoin lightning network: Scalable off-chain instant payments (2016)
Sompolinsky, Y., Zohar, A.: Accelerating bitcoin’s transaction processing. Fast money grows on trees, not chains (2013)
Spilman, J.: [bitcoin-development] anti dos for tx replacement (2013). https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-April/002433.html
Todd, P., Harding, D.A.: Bip 125: Opt-in full replace-by-fee signaling (2015). https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki
Author information
Authors and Affiliations
Corresponding author
Editor information
Editors and Affiliations
A Ideal Functionality
A Ideal Functionality
This section defines an ideal functionality \(\mathcal {F}(T)\) with \(T>\varDelta \) that achieves the desired properties stated in Sect. 5.2. To simplify the notations, we abbreviate \(\mathcal {F}:=\mathcal {F}(T)\). The ideal functionality \(\mathcal {F}\) stores a set \(\varGamma \) of all the created channels and their corresponding funding transactions. The set \(\varGamma \) can also be treated as a function s.t. \(\varGamma (id)=(\gamma ,\texttt{TX})\) with \(\gamma .\textsf{id}=id\) if \(\gamma \) exists and \(\varGamma (id)=\perp \) otherwise. Before presenting the ideal functionality \(\mathcal {F}\) in details, we briefly introduce its different phases and explain the way \(\mathcal {F}\) achieves the desired properties.
a) Create: In this phase, \(\mathcal {F}\) receives messages \((\texttt{INTRO},\gamma ,tid_{P})\) and \((\texttt{CREATE},\gamma .\textsf{id})\) from both parties in rounds \(\tau _0\) and \(\tau _0+1\), respectively, where \(tid_P\) specifies the funding source of the user P. Then, if the corresponding funding transaction appears on the ledger \(\mathcal {L}\) within \(2+\varDelta \) rounds, \(\mathcal {F}\) sends the message \((\texttt{CREATED},\gamma .\textsf{id})\) to both parties and stores \(\gamma \) and the funding transaction in \(\varGamma (\gamma .\textsf{id})\). If the \(\texttt{CREATE}\) message is not received from both parties but the funding transaction appears on \(\mathcal {L}\) within \(2+\varDelta \) rounds, \(\mathcal {F}\) outputs \(\texttt{Error}\). Since the message \(\texttt{CREATED}\) might be sent to the parties only if they both have sent the message \(\texttt{CREATE}\) to \(\mathcal {F}\), the ideal functionality achieves “consensus on creation”.
b) Update: One of the parties, denoted by P, initiates this phase by sending the message \((\texttt{UPDATE},id,\mathbf {\theta },t_{stp})\) to \(\mathcal {F}\), where id is the channel identifier, \(\mathbf {\theta }\) is the new channel state and \(t_{stp}\) is the number of rounds needed to prepare prerequisites of the channel update (e.g. preparing the needed HTLCs). Due to disagreeing with the new state or failure in preparing its prerequisites, party Q can stop it by not sending the message \((\mathtt {UPDATE-OK},id)\) in step 2. Abort by P or Q in next steps causes the procedure \(\texttt{ForceClose}(id)\) to be executed. The property “optimistic update” is satisfied because if both parties act honestly, the channel can be updated without any blockchain interaction. Furthermore, if P or Q disagree to update the channel, they can stop sending the \(\texttt{UPDATE}\) or \(\mathtt {UPDATE-OK}\) messages, respectively. This stops the channel update process without changing the latest channel state. Also, in cases where either P or Q stop cooperating, the procedure \(\texttt{ForceClose}(id)\) is executed. This procedure takes at most \(\varDelta \) rounds to complete. This also guarantees “consensus on update”.
c) Close: If \(\mathcal {F}\) receives the message \((\texttt{CLOSE},id)\) from both parties, a transaction \(\texttt{TX}\) is expected to appear on \(\mathcal {L}\) within \(\varDelta +1\) rounds. This transaction spends the output of the funding transaction and its outputs equal the latest channel state \(\gamma .\textsf{st}\). If the \(\texttt{CLOSE}\) message is received only from one of the parties, \(\mathcal {F}\) executes the procedure \(\texttt{ForceClose}(id)\). In both cases, output of the funding transaction must be spent within \(\varDelta +1\) rounds. Otherwise, \(\mathcal {F}\) outputs \(\texttt{Error}\).
d) Punish: If a transaction \(\texttt{TX}\) spends the funding transaction’s output of a channel \(\gamma \), one of the following events is expected to occur: 1) another transaction appears on \(\mathcal {L}\) within \(\varDelta \) rounds where this transaction spends output of \(\texttt{TX}\) and sends \(\gamma .\textsf{cash}\) coins to the honest party P; or 2) another transaction whose outputs correspond to the channel state \(\gamma .\textsf{st}\) or \(\gamma .\mathsf {st'}\) appears on \(\mathcal {L}\) within \(T+\varDelta \) rounds. Otherwise, \(\mathcal {F}\) outputs \(\texttt{Error}\). According to its definition, “bounded closure with punish” is achieved, if \(\mathcal {F}\) returns no \(\texttt{Error}\) in the close and punish phases.
We describe the ideal functionality below. Normally, once \(\mathcal {F}\) receives a message, it performs several validations on the message. But to simplify the description, we assume that messages are well-formed. Data exchange between \(\mathcal {F}\) and other parties is represented by directed arrows. If \(\mathcal {F}\) sends the message m to party P in round \(\tau _0\), we denote it with . Similarly, if \(\mathcal {F}\) is supposed to receive the message m from party P in round \(\tau _0\), we denote it with .
Rights and permissions
Copyright information
© 2022 The Author(s), under exclusive license to Springer Nature Switzerland AG
About this paper
Cite this paper
Mirzaei, A., Sakzad, A., Yu, J., Steinfeld, R. (2022). Daric: A Storage Efficient Payment Channel with Punishment Mechanism. In: Susilo, W., Chen, X., Guo, F., Zhang, Y., Intan, R. (eds) Information Security. ISC 2022. Lecture Notes in Computer Science, vol 13640. Springer, Cham. https://doi.org/10.1007/978-3-031-22390-7_15
Download citation
DOI: https://doi.org/10.1007/978-3-031-22390-7_15
Published:
Publisher Name: Springer, Cham
Print ISBN: 978-3-031-22389-1
Online ISBN: 978-3-031-22390-7
eBook Packages: Computer ScienceComputer Science (R0)