Predicting confirmation times of Bitcoin transactions

Gundlach, Rowel; Gijsbers, Martijn; Koops, David; Resing, Jacques

doi:10.1145/3466826.3466833

Cited by 16 publications

(5 citation statements)

References 28 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Technically speaking, there is the possibility that the Mempools seen by the miners are not exactly the same. The Bitcoin Network Monitor 7 [10] shows that within 16 s at least 90% of the miners are ready to announce a newly generated transaction (so they have surely received it before) and the block propagation delay is within 2 s. Thus, these delays are reasonably small to support our assumption coherently with other works in this field [18,19,21,23,24]. Another aspect that we should bare in mind is that the protocol does not specify which transactions a miner has to select from the Mempool.…”

Section: Remark 1 (Do All the Miners See The Same Mempool?)supporting

confidence: 84%

See 1 more Smart Citation

Analysis of the Confirmation Time in Proof-of-Work Blockchains

Rossi¹,

Malakhov²,

Marin³

2022

SSRN Journal

View full text Add to dashboard Cite

Section: Remark 1 (Do All the Miners See The Same Mempool?)supporting

confidence: 84%

“…In [24,25], the authors propose to use the process named Cramer-Lundberg to evaluate the confirmation time of transactions. Similarly to our contribution, the authors take into account the initial state of the Mempool and assume a homogeneous Poisson process for the block generation counting.…”

Section: Related Workmentioning

confidence: 99%

Analysis of the Confirmation Time in Proof-of-Work Blockchains

Rossi¹,

Malakhov²,

Marin³

2022

SSRN Journal

View full text Add to dashboard Cite

“…It might be the case, indeed, that a fork happened and another maintainer received the same confirmation for a transaction located in the other block. As for the settlement of financial transactions in bitcoin, 41 it is necessary to wait for a number of confirmations , that is, blocks chained over the one where the transaction appears, in order to make a reliable decision for the advancement in the workflow. In MaaS, we implement this by simply using a timer triggered by the watchdog on the chain and a second read after this timer expires to confirm the decision.…”

Section: Maas: Design and Architecturementioning

confidence: 99%

Machine‐as‐a‐Service: Blockchain‐based management and maintenance of industrial appliances

Tran

Lenssens

Kassab

et al. 2022

Engineering Reports

View full text Add to dashboard Cite

Machine‐as‐a‐Service (MaaS) is an emerging service model for industrial appliances. With MaaS, machines are rented instead of being acquired, and their lifecycle is handled by an ecosystem of specialized actors, such as different independent maintenance companies certified for interventions on specific hardware. As the number of actors, clients, and providers involved in a MaaS ecosystem grows, maintaining mutual trust relationships between all involved parties and orchestrating MaaS operations in centralized fashion quickly becomes intractable. We present a blockchain‐based approach to providing MaaS in industrial settings where rented machines are equipped with IoT sensors, and where MaaS operations are orchestrated in a transparent, decentralized, and scalable way using a collection of smart contracts deployed over an infrastructure combining the Ethereum and InterPlanetary File System decentralized services. We detail the operations of MaaS, such as the lifecycle of management operations, and report on the performance of a prototype implementation deployed in the cloud.

show abstract

“…One way to estimate confirmation times is to use statistical models, such as [8]. However, this approach requires estimating the parameters of the models involved, which can introduce bias on the results.…”

Section: Modeling Layer-1 Congestionmentioning

confidence: 99%

Mass Exit Attacks on the Lightning Network

Sguanci¹,

Sidiropoulos²

2022

Preprint

View full text Add to dashboard Cite

The Lightning Network (LN) has enjoyed rapid growth over recent years, and has become the most popular scaling solution for the Bitcoin blockchain. The network consists of payment channels that hold different amounts of BTC in their capacity. The security of the LN hinges on the ability of the nodes to close a channel by settling their balances, which requires confirming a transaction on the Bitcoin blockchain within a pre-agreed time period. This inherent timing restriction that the LN must satisfy, make it susceptible to attacks that seek to increase the congestion on the Bitcoin blockchain, thus preventing correct protocol execution.We study the susceptibility of the LN to mass exit attacks, in the presence of a small coalition of adversarial nodes. This is a scenario where an adversary forces a large set of honest protocol participants to interact with the blockchain. We focus on two types of attacks: (i) The first is a zombie attack, where a set of 𝑘 nodes become unresponsive with the goal to lock the funds of many channels for a period of time longer than what the LN protocol dictates. (ii) The second is a mass double-spend attack, where a set of 𝑘 nodes attempt to steal funds by submitting many closing transactions that settle channels using expired protocol states; this causes many honest nodes to have to quickly respond by submitting invalidating transactions.We show via simulations that, under historically-plausible congestion conditions, with mild statistical assumptions on channel balances, both of the attacks can be performed by a very small coalition. For example, a coalition of just 30 nodes could lock the funds of 31% of the channels for about 2 months via a zombie attack, and could steal more than 750 BTC via a mass double-spend attack, if the watchtowers algorithms do not make use of sophisticated strategies.To perform our simulations, we formulate the problem of finding a worst-case coalition of 𝑘 adversarial nodes as a graph cut problem. Our experimental findings are supported by a theoretical justification based on the scale-free topology of the LN. We emphasize that the proposed attacks should not be considered as an issue of the protocol design, but rather as an inherent issue of payment channels network without general computability on layer-1. CCS CONCEPTS• Security and privacy → Distributed systems security.

show abstract

Predicting confirmation times of Bitcoin transactions

Cited by 16 publications

References 28 publications

Analysis of the Confirmation Time in Proof-of-Work Blockchains

Analysis of the Confirmation Time in Proof-of-Work Blockchains

Machine‐as‐a‐Service: Blockchain‐based management and maintenance of industrial appliances

Mass Exit Attacks on the Lightning Network

Contact Info

Product

Resources

About