xujiahuayz
    • Create new note
    • Create a note from template
      • Sharing URL Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Customize slides
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Engagement control Commenting, Suggest edit, Emoji Reply
    • Invite by email
      Invitee

      This note has no invitees

    • Publish Note

      Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

      Your note will be visible on your profile and discoverable by anyone.
      Your note is now live.
      This note is visible on your profile and discoverable online.
      Everyone on the web can find and read all notes of this public team.
      See published notes
      Unpublish note
      Please check the box to agree to the Community Guidelines.
      View profile
    • Commenting
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Suggest edit
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
    • Emoji Reply
    • Enable
    • Versions and GitHub Sync
    • Note settings
    • Note Insights New
    • Engagement control
    • Make a copy
    • Transfer ownership
    • Delete this note
    • Save as template
    • Insert from template
    • Import from
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
    • Export to
      • Dropbox
      • Google Drive
      • Gist
    • Download
      • Markdown
      • HTML
      • Raw HTML
Menu Note settings Note Insights Versions and GitHub Sync Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
Engagement control Make a copy Transfer ownership Delete this note
Import from
Dropbox Google Drive Gist Clipboard
Export to
Dropbox Google Drive Gist
Download
Markdown HTML Raw HTML
Back
Sharing URL Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Write
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Engagement control Commenting, Suggest edit, Emoji Reply
  • Invite by email
    Invitee

    This note has no invitees

  • Publish Note

    Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

    Your note will be visible on your profile and discoverable by anyone.
    Your note is now live.
    This note is visible on your profile and discoverable online.
    Everyone on the web can find and read all notes of this public team.
    See published notes
    Unpublish note
    Please check the box to agree to the Community Guidelines.
    View profile
    Engagement control
    Commenting
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Suggest edit
    Permission
    Disabled Forbidden Owners Signed-in users Everyone
    Enable
    Permission
    • Forbidden
    • Owners
    • Signed-in users
    Emoji Reply
    Enable
    Import from Dropbox Google Drive Gist Clipboard
       Owned this note    Owned this note      
    Published Linked with GitHub
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    # PNAS Nexus Title: "How the interplay between power concentration, competition, and propagation affects the resource efficiency of distributed ledgers" Tracking #: PNASNEXUS-2025-01298-T Authors: Barucca et al. Dear Dr. Barucca, Thank you for submitting your manuscript, titled "How the interplay between power concentration, competition, and propagation affects the resource efficiency of distributed ledgers," for consideration at PNAS Nexus. We apologize for the delay in rendering a decision on your submission. The expert who is serving as the editor for your manuscript [MS# PNASNEXUS-2025-01298-T] has obtained 3 reviews, which are included below. Upon reviewing these comments, the editor requests that you constructively address the reviewers’ concerns in a revised manuscript due by February 17, 2026. To ensure that revisions are made in a timely fashion, PNAS Nexus allows up to 60 days to revise for a major revision. If you require additional time, please contact our Editorial Office at pnasnexus.editorialoffice@oup.com. As you revise your materials, please ensure that your files adhere to our editorial requirements, as shared with you at the end of this email. Along with your revised manuscript, please include a point-by-point response to the reviewers' comments and a marked manuscript file to highlight the changes made. The revision cover letter should contain a list of the files that have been revised, along with a brief description of the changes made to each file. You may submit the revised manuscript here: https://pnasnexus.msubmit.net/cgi-bin/main.plex?el=A6QV1Erji5A2NlFR1I2A9ftdWIJWQ8SdDTDMToq6BsADAgZ. Please note that removing or reordering your coauthor list, if any, requires approval from all coauthors. If you wish to add an additional corresponding author, please note the addition in the "Comments for Editorial Staff" box, when completing your revision. Multiple revisions are rarely granted, and there is no guarantee that the revised paper will be accepted. PNAS Nexus is a fully open access journal, and all content published in the journal is made available to readers online under an open access license. Please note that there are charges associated with open access publication which you can find in the https://academic.oup.com/pnasnexus/pages/general-instructions#Open%20Access>information for authors. We look forward to receiving your revision. Thank you for submitting your paper to PNAS Nexus. Sincerely, Yannis C. Yortsos PNAS Nexus Editor-in-Chief ********************* Editor comments: Please provide a point by point reply letter detailing all actions taken. Reviewer comments: Reviewer #1: Overall Quality: Yes Justified Conclusions: Yes Diverse Audience of Scientists: Yes Repeatable Procedures: Yes Supplemental Material: Yes Significance Statement: Yes Sufficient data/samples?: Yes Comments for the Author: This manuscript presents a quantitative analytical model examining how power concentration, competition, and propagation delay jointly influence the resource efficiency of distributed ledgers, particularly Proof-of-Work (PoW) blockchains. By combining closed-form derivations with empirical calibration against Bitcoin data (2015–2025), the authors estimate the impact of fork probability on energy waste, concluding that natural network asynchrony and concentration may account for roughly 14 GW of dissipated power. The work is technically rigorous and intellectually engaging, elegantly unifying perspectives from network theory, statistical physics, and blockchain economics. The manuscript’s mathematical modeling is internally consistent and visually supported by clear, instructive figures. The work bridges disciplines through quantitative analysis and connects micro-level protocol dynamics to macro-level sustainability implications. However, the work’s core phenomena are not conceptually novel, and some of the language risks overstating originality. - [ ] The interplay between mining centralization, network asynchrony, and consensus inefficiency has been extensively studied in earlier literature--most notably in the series of papers by Saad et al. in ACM CCS 2021 and IEEE/ACM ToN 2022–2023. What this paper does, and does well, is to formalize and unify those known dynamics into an analytical efficiency law with explicit quantitative interpretation. The authors’ achievement is thus one of integration and synthesis, rather than first discovery. > @paolo to cite these Strengths 1. Analytical elegance: The probabilistic treatment of fork probability under heterogeneous miner distributions is mathematically sound and intuitively clear. The derivations around Eq. (4)–(6) are well justified, and the resulting scaling relationships between Δ0, λi, and fork rate are both tractable and insightful. 2. Cross-disciplinary framing: The connection between micro-level consensus properties and macro-level energy economics is a clear strength. The discussion of "energy waste as an emergent inefficiency law" (Section 4.2) is particularly compelling and fits Nexus’s interdisciplinary readership. 3. Presentation and writing quality: The manuscript is remarkably well structured, with precise notation, polished prose, and visual clarity. Figures are explanatory rather than decorative, and the text maintains a high level of scientific readability. 4. Conceptual synthesis: The paper effectively unifies strands of prior work that have often remained siloed between blockchain security, network measurement, and energy modeling. The result is a single coherent framework that bridges these perspectives. Weaknesses and Areas for Improvement - [ ] 1. Overstated novelty. The abstract and introduction employ first-discovery language, e.g.: "To the best of our knowledge, this is the first quantitative characterization of how mining concentration and network delay jointly shape energy inefficiency in Proof-of-Work blockchains." This claim is inaccurate in light of prior work. HashSplit (ACM CCS 2021) [1] and SyncAttack (ACM CCS 2021) already established that asynchronous propagation and miner centralization naturally yield forks, synchronization failures, and wasted effort, albeit from a security perspective. Exploring Partitioning Attacks on the Bitcoin Network (IEEE/ACM ToN 2022) [3] and Root Cause Analyses for the Deteriorating Bitcoin Network Synchronization (IEEE ICDCS 2021) further documented empirically that network topology and relay dependence exacerbate those delays. > @pb / @cc to claim novelty and to cite The current paper’s true novelty lies not in discovering this interplay, but in formalizing it quantitatively and linking it to aggregate energy loss. The authors should reframe the contribution accordingly, emphasizing synthesis and quantification. - [ ] 2. Modeling assumptions and realism. The analytical framework assumes independent miners with fixed hash shares (λi) and a homogeneous propagation delay (Δ0) within epochs. These simplifications are reasonable for tractability but omit empirically verified heterogeneity and burstiness (see ToN 2022/ICDCS 2021 by Saad et al.). The paper would benefit from a short subsection acknowledging these limitations explicitly and discussing how relaxing them might affect the results. > @pb claim benefit - [ ] 3. Empirical validation. The comparison between predicted and observed orphan-block frequencies provides a sanity check but not a full validation. The data are limited to Bitcoin; even a small comparative analysis (or a sensitivity test over Δ0 distributions) would strengthen credibility. The energy-waste figure (14 GW) should be described as an order-of-magnitude estimate, not a precise measurement. > already in fig 3(a) and 6 ...(additional tests done with modified interval) So, all in all, the most compelling contribution of this paper is its reframing of network asynchrony and centralization, long viewed primarily as security risks, as thermodynamic inefficiencies with measurable energy consequences. This cross-domain translation is intellectually valuable and policy relevant. By quantifying how propagation delay and concentration jointly reduce energy efficiency, the paper makes a meaningful contribution to understanding the sustainability and economics of decentralized systems. If appropriately repositioned, this manuscript could serve as an analytical capstone to nearly a decade of research diagnosing Bitcoin’s synchronization degradation, providing a unifying efficiency law where prior works offered localized observations. [1] https://dl.acm.org/doi/abs/10.1145/3460120.3484561 [2] https://dl.acm.org/doi/10.1145/3460120.3484568 [3] https://ieeexplore.ieee.org/document/9521569 [4] https://ieeexplore.ieee.org/document/9546455 Reviewer #2: Overall Quality: Yes Justified Conclusions: Yes Diverse Audience of Scientists: Yes Repeatable Procedures: Yes Supplemental Material: Yes Significance Statement: Yes Comments on Significance Statement: The Significance Statement clearly describes the research direction and maps it to the widely known energy consumption and environmental problem, well known to society. Sufficient data/samples?: Yes Comments for the Author: Overall assessment. The paper makes a significant contribution to the holistic scientific understanding of the multiple factors influencing the efficiency of PoW blockchains. Previous research results have mainly analyzed only specific inputs, such as block propagation delay in p2p networks, or separate miners' strategies. This paper combines network delays, network topology options, varying delivery times for different participants, hashpower concentration into a single model and validates it using real-world data from the Bitcoin network. Key results of the paper. 1. Estimated the empirical distribution of hash rates and evaluated its evolution over time using reliable sources of Bitcoin data. 2. Modeled consensus propagation within a heterogeneous network. 3. Formulated analytical conditions for fork generation based on mining and network data, and validated both analytical and empirical results. 4. Extended and analytically linked the Herfindahl-Hirschman Index to measure blockchain decentralization. 5. Applied various parameter distributions to analyze their influence on orphan block generation and associated energy wastage. 6. Established efficiency criteria for blockchain based on block propagation time and hash rate concentration to reduce the occurrence of orphan blocks. 7. Developed tools for the empirical analysis of blockchain data. Possible improvements of the paper. - [x] 1. From the mining node implementation point of view, a fork is present in the blockchain network until one of the next block(s) is mined, and honest miners accept the single chain (the longest one). This is much beyond t_4 in Fig. 1 (definitely, it is not only time interval between t_3 and t_4). > yes we agree this is a simplification that we have to make ... add in discusion xxxxx... for our purpose of measuring e.g. energy wastage, this suffices @cc - [x] 2. It lacks arguments why authors consider a period of 20,000 blocks (~4.5 months) to be approximately stationary. It seems that the difficulty adjustment period (2016 blocks, or 2 weeks) seems more appropriate. > @xujiahuayz to rerun with ~14 day interval, ideally sync with difficulty adjustment every 2016 from block 0 (multiples of 2016) > We have rerun the empirical analysis with a period equaling one difficulty epoch (2,016 blocks) and the conclusions still stand. Note that as a shorter window results in more unstable empirical estimates of fork occurance and small miner mining a block -- due to their infrequent nature -- we also in supplementary data show alternative scenarios with a time window equal to 4, 5, 10 difficulty blocks. Reviewer #3: Overall Quality: Yes Justified Conclusions: No Diverse Audience of Scientists: Yes Repeatable Procedures: Yes Supplemental Material: Yes Significance Statement: Yes Sufficient data/samples?: Yes Comments for the Author: Overall, the paper presents an interesting analysis of block propagation delay and its impact on fork race occurrence. The derived equations in Section “Modeling consensus propagation in a heterogeneous network” are insightful, showing how mining power decentralization can influence fork rates. With some revisions, particularly improving precision in claims and conclusions, the paper has strong potential for publication. Main Concerns: - Unsubstantiated Claims: - [x] The paper makes several strong claims (e.g., “we can infer hidden concentrations of mining power around 2016 in the Bitcoin network”, “miners not acting independently”), but these are not rigorously proven. The only justification provided is the mismatch between empirical and theoretical HHI values, which is insufficient. A more likely explanation could be the inaccuracy of the assumed Δ₀ parameter. As the authors mention, mining pool leaders are usually well-connected, meaning the actual Δ₀ is likely smaller. This effect would have been more pronounced before the Compact Block Relay (BIP 152) update, when block propagation was more heterogeneous. These claims should either be supported by stronger evidence or removed. > @cc stress that we tested also smaller Δ₀. revisit/ tone down claims, mention "Compact Block Relay (BIP 152) update" - see if it can be used to interpretate some of the results. - Definition of Power/Energy Wastage: - [x] I think the authors should provide a very precise definition of power wastage. In the introduction, they claim that “this paper estimates the mining power wasted in producing blocks that did not end up in the canonical chain.” However, in the relevant section, they actually calculate “the wasted energy used to mine on top of the outdated block.” These definitions are not consistent with each other. > @xujiahuayz make consistent .. We thank the reviewer for spotting the inconsistency. We indeed refer to the latter. We have modified everywhere where the concept of wastage is mentioned, and add a explanatory note where "wastage" is first computed: "Note that we consider all the power used to mine on top of the latest block to be “useful”, as it is needed by the design of the PoW consensus mechanism. Wastage only arises after a new block is mined, but other miners in the network continues to attempt the incorrect PoW puzzle unknowingly while the information on the newly mined block is still being transmitted." The most natural way, I assume, to calculate energy waste is to count the number of orphaned blocks and estimate how much energy was consumed to generate them. Since the number of orphans is quite limited, I suspect this amount should be much lower than what is reported by the paper. > @xujiahuayz having blocks not ending up in the final canonical chain is ok -- that is part of PoW. However, mining continuously on top of one - we consider that to be wasteful, that is not needed by PoW but caused by propagation delay. We are counting every wasted hash due to network delays. According to the paper’s definitions, the wastage is the amount of electricity consumed on outdated blocks, even if they did not lead to mining an actual block. I am not saying the calculations are incorrect, but rather that the definition of energy wastage differs from the natural or standard one. For example, one could also define energy wastage as the energy consumed in unsuccessful attempts to find a valid nonce and report an even higher number. > we clarified the definition Therefore, I expect the authors to be precise in their definition of energy wastage, clearly state it, and, if possible, compare it with other wastage calculations existing in the literature. Minor Comments: - [x] - The paper uses the term “soft fork” to describe forks caused by propagation delays. However, in blockchain terminology, a soft fork refers to a backward-compatible protocol update. A different term should be used to avoid confusion. > @cc we changed the terminology to "accidental fork" to avoid confusion - [x] - When writing functions, ensure there is no space between the function name and parentheses (e.g., θ(t′−t)), to make it clear that θ is a function, not a separate variable. > @cc we amended the typesetting - [x] - It would enrich the paper to discuss how attacks such as selfish mining or block withholding might affect the presented model. - [x] - The effect of the Compact Block Relay (BIP 152) update on block propagation delay and the paper’s analysis could be discussed further. > @cc we added a comment on this in relation to the delta zero estimates around 2016 - [ ] - Consider citing related work, such as “Mining Power Destruction Attacks in the Presence of Petty-Compliant Mining Pools”, which also examines mining centralization and fork races. > @pb we added the citation Suggestions for Future Work: - [x] - The current model assumes a single propagation delay Δ₀. A more precise analysis could consider heterogeneous propagation delays between pairs of mining pool managers, potentially leading to more accurate results. > @cc we added a comment, same argument as above ------- # WINE We sincerely thank the reviewers for their valuable comments. We appreciate the positive comments on the novelty of our reverse inference method and the solid experimental analysis. We are confident we can address the reviewers' questions and concerns by clarifying the existing material in our paper (without adding significantly new material). Below, we respond to the points raised. ## Fitness for WINE (Reviewers A&C): We respectfully believe our work is a good fit for WINE. Game-theoretical modeling is not a requirement for the fitness of a paper, and we observed papers on related topics (e.g. [1] on bitcoin mining) that do not cover game theory published in past conference proceedings. In addition, the conference itself has been evolving over the past years – "Blockchains and their applications" has been explicitly included as a topic in scope since the conference's 2023 iteration, suggesting a more inclusive scope in the blockchain field, in which we believe our paper fits perfectly. ## Historical fork data (Reviewers A&B): We argue that using different sources is a strength rather than a weakness. We observe a great overlap of fork records from different sources (corroborating their validity), with some records only observed by single sources. This is peculiar to the distributed nature of the bitcoin network, leading to different nodes observing different versions of the ledger state (hence the necessity of consensus). Synthesizing various sources (used by well-published academic papers) would give us a more comprehensive view, which could not be replaced by running an own node. While running multiple nodes can partially resolve this, we would only be able to collect raw data onwards (and would need to run for multiple years for the exercise to be meaningful); yet we would still need to rely on secondary sources for historical data. We also want to stress that the rescaling (with a factor of 1.476) is only moderate, far away from altering the values' order of magnitude. It was applied transparently to reconcile an inherent under-reporting issue against a peer-reviewed academic standard, ensuring our baseline is grounded in the literature. ## Statistical significance (Reviewer A): In Fig 3(b) (and later Fig 5) we plot the 90% confidence band surrounding the historically measured fork rates (as it is -- by design of distributed ledgers -- almost impossible to accurately measure empirical fork rates, as discussed in the response above), and show that the model estimation under certain parameter settings falls largely within the band. ## Data sources (Reviewer A): Data sources are all clearly documented in Appendix. In particular, data for Fig 2 are described in detail in A.3. We shall add a direct cross-reference in the main text to make this clearer. ## Model assumptions (Reviewer B): We candidly disclosed those assumptions in Discussion (Section 4) but argue their necessity for a simple and elegant mathematical model. We believe those assumptions do not jeopardize the validity of our theoretical model, as these factors turn out to have limited relevance in the estimation of fork rates (which ultimately can be approximated with block propagation time and mining time; both can be accurately measured). In addition, our assumptions are reasonable and fairly realistic (e.g. normalized total hash rate is relatively stable due to the automatic difficulty adjustment mechanism of bitcoin, hence the constant assumption) and / or common in established literature (e.g. [2] treats a mining pool as one entity when examining the competition between miners). ## 'Power concentration' vs 'lack of competition' (Reviewer A): Indeed, those two concepts are intertwined, as suggested at the bottom of page 8 (higher power concentration ~ lower competition). We choose to include both terms in the title, as power concentration is more quantifiable (through e.g. HHI, number of miners), whereas "competition" is broader, describing additionally the relative topological position of various nodes in the network (e.g. its connectivity with other nodes), which we touch upon in Discussion (Section 4). ## Model implications (Reviewers A&C): Our model's main contribution is not to prescribe a single "optimal" network configuration or to offer a policy recommendation, but to provide a rigorous, quantitative framework to analyze the fundamental trade-offs in blockchain design. Reviewer C correctly notes that forks can signal healthy decentralization, while our results show they are resource-inefficient. Our model formally quantifies this trade-off, connecting hash rate concentration (HHI), network latency (Δ₀), and energy wastage. This allows for an evidence-based discussion of the cost-benefit of bitcoin. The 14,000 MW wastage figure is not an argument for eliminating forks at all costs (e.g., by encouraging centralization). Rather, it serves as a stark, empirical grounding for ongoing debates about Bitcoin's environmental impact and the search for more efficient consensus mechanisms (more on that below). Our work provides the tools to ground these often philosophical debates in concrete data. ## Comments/ references on regarding decentralization vs resource (Reviewer C): This concept is somewhat connected to the established blockchain trilemma: decentralization, scalability (which is, ceteris paribus, positively correlated to resources), security. It is conventionally believed that at a certain level of security, a higher level decentralization will mean a higher level of energy consumption, a viewpoint that we also mentioned in the paper. However, very recently (after WINE submission) we see publications refuting the trilemma [3], and proposing novel consensus mechanisms that defeat the trilemma [4]. These new studies provide further evidence for the meaningfulness of our study: high resource consumption does not need to be an inherent feature of a highly distributed ledger; low resource and high decentralization CAN co-exist. Our paper demonstrating the empirical high energy consumption and wastage of Bitcoin will prompt more studies on novel design of blockchains that are resource-efficient and decentralized at the same time. [1] Socially Optimal Mining Pools https://link.springer.com/chapter/10.1007/978-3-319-71924-5_15 [2] Block withholding game among bitcoin mining pools https://www.sciencedirect.com/science/article/pii/S0167739X17330686 [3] A Formal Refutation of the Blockchain Trilemma https://arxiv.org/abs/2507.05809 [4] Rewriting blockchain: A hybrid consensus that defeats the trilemma paradox https://www.sciencedirect.com/science/article/abs/pii/S0045790625004379 https://wine2025.hotcrp.com/paper/245 WINE 2025 Paper #245 Reviews and Comments =========================================================================== Paper #245 How the interplay between power concentration, competition, and propagation affects the resource efficiency of distributed ledgers Review #245A =========================================================================== Paper summary ------------- The paper develops a model for estimating fork rates depending on hash rate concentration and propagation times. It studies it against the historical fork rate data of Bitcoin in the last ~10 years and finds it generally matches it. The model can also be used in reverse inference to identify irregularities in hash rate concentration / propagation times based on fork rate behavior. Strengths: - The paper is well-written, many aspects of the model are examined, and it spans over 10 years of data. Many nice graphs - The reverse inference, where measurement of fork rates can be used to infer hash rate concentration, and possibly detect collusion between miners, is super interesting and valuable / creative / original. Weaknesses: - The data collection for forks (which are the main issue here) seems a bit ragtaggy, using 3 different sources, normalizing to some data point in a paper, and so on. Ideally you would have a setup where you monitor the Bitcoin network over some time (maybe with servers in different locations) and thus have your own raw data. > We'd argue that using different sources is a strength not a drawback. we observe a great overlap of forks from different sources (corroborating their validity), but some are only observed by single sources. This is parculiar to the distributed nature of bitcoin leading different node observing a different version of the ledger state (hence the necessity of concensus) Combing those data would give us a more comprehensive view, which could not be replaced by running an own node. While running multiple nodes can partically resolve this, we'd only be able to collect raw data onwards and would still need to rely on secondary sources for historical data. - I didn't see a formal hypothesis testing of the model / statistical significance. Maybe I missed it. > In Fig 3(b) (and later Fig 5) we plot the 90% confidence band surrounding for the historically measured fork rates, and show that the model estimation under certain parameting setting falls largely within the band. - I am undersold on some of the implications of the model, e.g. with respect to electricity waste. The calculation of about 14k MWs wasted on forks: That’s part of the price of running the network, unless there’s some recommendation for how to waste less on forks, but what is this recommendation? Especially since there are less forks when the hash rate is more concentrated, so we need to have more concentrated hash rate? > While we appreciate the revier's request on a cleaer policy recommendation to be derived from the model, we beg to differ philosophically. The direct takeaway/result of the paper is a rigorous framework for the quantification of both total energy as well as energy spent in forks and the canonical chain, in relationship with network topological features. This provides more evidence-based argumatentation when people debate over the the cost-benefit of bitcoin, and when they examine the trade-off between concentration and energy wastage. - I’m not sure whether the paper is a good fit for WINE (no game theoretical model). It seems like a better fit to AFT / FC / WWW. > We believe game theoretical models are not the necessary requirement for the fitness of a paper and we observed papers on related topics (e.g. [1] on bitcoin mining) that does not rely on game theoretical modeling published in the conference proceeding. In addition, the conference itself has been evolving -- "Blockchains and their applications" has been explicitly included as a topic in scope since the conference's 2023 iteration, suggesting a more inclusive scope in the blockchain field, which we believe our paper fits perfectly. [1] Socially Optimal Mining Pools https://link.springer.com/chapter/10.1007/978-3-319-71924-5_15 Overall merit ------------- 4. Weak accept -- above the threshold but not in the top 50% of the papers Reviewer expertise ------------------ 2. Some familiarity Comments for authors -------------------- - It’s not always clear if the data in some figures is your new data using the new methods, or existing known data. For example in Figure 2 > Data sources are all clearly documented in Appendix. In particular, data for Fig 2 are described in detail in A.3. We shall clarify this more clearly in the main text through cross-referencing in the revised version. - Is there really a difference between ‘power concentration’ and ‘lack of competition’ in the paper? Both the title and in the text you use both terms, but as far as I can tell they are just interpreted as opposites to each other? It’s a bit confusing because the title suggests these are two different elements. > There is indeed overlap in those two concepts, as suggested at the bottom of page 8 (higher power concentration ~ lower competition). We choose to include both terms in the title, as power concentration is more quantifiable (through e.g. HHI, number of miners), whereas "competition" is more broad, describing additionally the relative topological position of various nodes in the network (e.g. its connectivity with other nodes), which we discussed in Section 4. Review #245B =========================================================================== Paper summary ------------- The paper develops and validates a mathematical model to predict the rate of "forks" (competing blocks) in a Proof-of-Work blockchain like Bitcoin. The model connects the fork rate to three key factors: the number of miners, the concentration of mining power (hash rate distribution), and the time it takes for a new block to propagate across the network. The model confirms that the fork rate is well-approximated by the simple ratio of block propagation time to the average block mining time . The model's primary contribution is to formally quantify the additional impact of miner heterogeneity. It demonstrates that a higher concentration of mining power (a higher HHI) leads to a lower fork rate. By inverting the model, the authors can infer unobservable network properties. For example, by using the historically measured fork rate and propagation times, they can calculate an "implied" power concentration, finding discrepancies with observed data around 2016 that suggest hidden network asymmetries or coordination . The model is used to estimate the energy wasted due to forks. This wastage is substantial and growing, reaching approximately 14,000 MW in the most recent year, an amount the authors compare to half of the UK's power generation capacity. The authors claim their model provides several key benefits: The model offers a "theoretical foundation" for the empirically observed relationship between fork rates, propagation time, and mining time, while also capturing the additional impact of miner inequality. It establishes a "robust mathematical setting for investigating factors often unobservable from existing empirical data," such as power concentration and network asymmetries. The model can be used to "infer hidden concentrations of mining power and structural network asymmetries" by comparing its predictions to real-world data. **weakness** The model's mathematical tractability relies on several simplifying assumptions that do not perfectly reflect reality, such as treating mining pools as single entities with no internal latency, assuming constant hash rates over long periods, and positing that all miners begin mining at the exact same time. I am not an expert, I an not fully sure how strong these assumptions are and to whayt extend they simplify things. > We candidly disclosed those assumptions in Discussion section but argue their necessity for a simple and elegant mathematical model. We belive those assumption do not jeopardize the validity of our theoretical model, as these factors turn out to have limited relevancy in the estimation of fork rates (which ultimately can be approximated with block propagation time and mining time; both can be accurately measured). In addition, our assumptions are either reasonable and fairly realistic (e.g. normalized total hash rate is relatively stable due to the automatic difficulty adjusment mechanism of bitcoin, hence the constant assumption) and / or common in established literature (e.g. [2] treats a mining pool as one entity when examining the competition between miners). [2] https://www.sciencedirect.com/science/article/pii/S0167739X17330686 In addition, the historical fork rate data is compiled from multiple sources, including a crowd-sourced repository that likely under-reports forks, which required the authors to apply a single, constant rescaling factor to the entire dataset, introducing a potential source of error. > A strength to use multiple sources. We also want to stress that the rescaling (with a factor of 1.476) is only moderate, and far away from altering the values' order of magnitude. The data sources used are also from used by well-published acadamic papers. In addition, we believe the accurate, first-handed measurement of empirical fork rate itself would be a saparate research project requiring multiple devices (as suggested by Reviewer 1) and multi-year obverstaion as well as careful reconciliation of data, which we believe would not be a focus of the current paper. Overall merit ------------- 4. Weak accept -- above the threshold but not in the top 50% of the papers Reviewer expertise ------------------ 1. No familiarity Review #245C =========================================================================== Paper summary ------------- Bitcoin competing mining pools give rise to (rather frequent) soft forks: When two nodes nearly at the same time solve a puzzle and are entitled to produce the next (unique) block. The (empirical) frequency of these soft forks is important per se and, as this paper studies, can also be used to determine other parameters (or to relate it to other hidden parameters). This work enhances a prior model [12], which assumes equal (hashing) power of miners, with the new model able to better fit existing empirical data. Roughly speaking, the different hash rates determine the Poisson probability distribution that a block is mined at time t for miner i. These determine the (conditional) probability that a particular gap between the fastest and the second-fastest miner occurs, and the later can be further approximated by the Herfindahl-Hirschman Index (HHI). I find this part, and the other empirical analysis and method of the paper rather compelling and interesting. The experiment are quite solid and convincing. My doubts concern the audience and the fit of this paper to WINE (for example, there is essentially no game theory involved/needed, neither any of the other main topics in WINE call for paper). In my humble opinion, > We believe it's a good fit - same argument as for reviewer 1. Overall merit ------------- 4. Weak accept -- above the threshold but not in the top 50% of the papers Reviewer expertise ------------------ 3. Knowledgeable Comments for authors -------------------- While I think measuring the frequency of soft forks and related quantities is important, I am not fully convinced that competition (frequent soft forks) are necessarily bad (and that the energy "waste" is something to minimize). The reason is that soft forks seem to denote a certain (minimal) decentralization, that is, there are at least two independent pools trying to produce the next block. > Philosophical difference on the takeaway of the paper. We are not trying to solve the debate, but try to provide a solid foundation for people participating the debate. Same argument as for reviewr 1. In general, decentralization and resource optimization are in contrast with each other (as decentralization is based on redundant computation/resources) and this seems not an exception. I wonder if you could comment on this and maybe offer a different view (or even references) on this aspect. > This concept is somewhat connected to the established blockchain trilemma: decentralization, scalability (which is, ceteris paribus, positively correlated to resources), security. It is conventionally believed that at a certain level of security, a higher level decentralization will mean a higher level of energy consumption, a viewpoint that we also mentioned in the paper. However, very recently (after WINE submission) we see publications refuting the trilemma [3], and proposing novel consensus mechanism that defeats the trilemma. These new studies provide further evidence on the meaningfulness of our study: high resource consumption does not need to be an inherent feature of a highly distrbuted ledger; low resource and high decentralization CAN co-exist. Our paper demonstrating the empirical high energy consumption and wastage of Bitcoin will prompt more studies on novel design of blockchains that are resource-efficient and decentralized at the same time. [3] A Formal Refutation of the Blockchain Trilemma https://arxiv.org/abs/2507.05809 [4] Rewriting blockchain: A hybrid consensus that defeats the trilemma paradox https://www.sciencedirect.com/science/article/abs/pii/S0045790625004379 ------------------ #### Figure 2: hetereogeneity #### Figure 3: distribution Based on previous research concerning fat-tails etc previous models assume homogeneity - we propose a model that accomodates heterogeneity as well as being parsimonious about network structure assumptions (basically only looks at delay) we go through the derivations etc get to eq 7 (conditional), 9 (approx of conditional) and then 10-12 (full) #### fig 4 to appendix - simulations are not worth the space, they just confirm that our calculations are correct #### subsection on implied vs empirical given the model we can calculate the implied fork rate, implied HHI (change name not to confuse stupid reviewer #2) and implied delta0, given 2 you get the 3rd. fig 6b shows that the implied HHI can go negative - that's because delta0 might be too low since we're using 50% bpt. It's still an effective measure of mining concentration. Figure implied block propagation - expected time to replace fig 6a main points about fig 5-7: - distribution may not seem that important - however HHI is a consequence of the distribution, and at second order the differences become sharper (fig 7 - probably move up before 5) - the model is still useful to understand the factors that go into forks: network location and hashrate concentration - generally, fork rates are consistent with miners being in the 50% best connected nodes (fig 5), so miners are "core-y" (like in tx nets) - the implied HHI can point to undetected concentration (or distribution) of hashrates (including selfish/cartel behaviour), while implied delta0 can point to variations in geographic/network localization of miners #### Figure 8: thanks to the model we extrapolate and plot the isolines that are consistent with the empirical fork rate for a given delta0 and exploring the hashrate distributions space generally find that fork rates decrease with increasing heterogeneity and number of miners, as one could expect. the relation between s and N is nonlinear and changing the null distribution can change the impact of N and s significantly

    Import from clipboard

    Paste your markdown or webpage here...

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lose their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template has been removed or transferred.
    Upgrade
    All
    • All
    • Team
    No template.

    Create a template

    Upgrade

    Delete template

    Do you really want to delete this template?
    Turn this template into a regular note and keep its content, versions, and comments.

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in with Wallet
    Wallet ( )
    Connect another wallet

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Help & Tutorial

    How to use Book mode

    Slide Example

    API Docs

    Edit in VSCode

    Install browser extension

    Contacts

    Feedback

    Discord

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions and GitHub Sync
    Get Full History Access

    • Edit version name
    • Delete

    revision author avatar     named on  

    More Less

    Note content is identical to the latest version.
    Compare
      Choose a version
      No search result
      Version not found
    Sign in to link this note to GitHub
    Learn more
    This note is not linked with GitHub
     

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub
        • Please sign in to GitHub and install the HackMD app on your GitHub repo.
        • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
        Learn more  Sign in to GitHub

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Include title and tags
        Available push count

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully