Elastic Block Caps Meni Rosenfeld

Slides:



Advertisements
Similar presentations
Lecture 5 Memory Management Part I. Lecture Highlights  Introduction to Memory Management  What is memory management  Related Problems of Redundancy,
Advertisements

Variance reduction techniques. 2 Introduction Simulation models should be coded such that they are efficient. Efficiency in terms of programming ensures.
G. Alonso, D. Kossmann Systems Group
Stats for Engineers Lecture 6 Answers for Question sheet 1 are now online Answers for Question sheet 2 should be.
COMS 486 Iowa State University Introduction to Bitcoin A P2P Electronic Cash System.
Silberschatz, Galvin and Gagne  2002 Modified for CSCI 399, Royden, Operating System Concepts Operating Systems Lecture 19 Scheduling IV.
Wireless Capacity. A lot of hype Self-organizing sensor networks reporting on everything everywhere Bluetooth personal networks connecting devices City.
A Row-Permutated Data Reorganization Algorithm for Growing Server-less VoD Systems Presented by Ho Tsz Kin.
Cumulative Violation For any window size  t  Communication-Efficient Tracking for Distributed Cumulative Triggers Ling Huang* Minos Garofalakis.
Brown, Suter, and Churchill Basic Marketing Research (8 th Edition) © 2014 CENGAGE Learning Basic Marketing Research Customer Insights and Managerial Action.
Integrated Regulation for Energy- Efficient Digital Circuits Elad Alon 1 and Mark Horowitz 2 1 UC Berkeley 2 Stanford University.
Cmpt-225 Simulation. Application: Simulation Simulation  A technique for modeling the behavior of both natural and human-made systems  Goal Generate.
Bitcoin 2013, San Jose Meni Rosenfeld Bitcoil 5/19/2013Written by Meni Rosenfeld1.
Efficient Network-Coding-Based Opportunistic Routing Through Cumulative Coded Acknowledgments Dimitrios Koutsonikolas, Chih-Chun Wang and Y. Charlie Hu.
Frame by Frame Bit Allocation for Motion-Compensated Video Michael Ringenburg May 9, 2003.
A Really Bad Graph. For Discussion Today Project Proposal 1.Statement of hypothesis 2.Workload decisions 3.Metrics to be used 4.Method.
Colombian Firm Energy Market: Discussion and Simulation Peter Cramton (joint with Steven Stoft and Jeffrey West) 9 August 2006.
CY2003 Computer Systems Lecture 09 Memory Management.
Analysis of Simulation Results Chapter 25. Overview  Analysis of Simulation Results  Model Verification Techniques  Model Validation Techniques  Transient.
On Distinguishing the Multiple Radio Paths in RSS-based Ranging Dian Zhang, Yunhuai Liu, Xiaonan Guo, Min Gao and Lionel M. Ni College of Software, Shenzhen.
1 Nasser Alsaedi. The ultimate goal for any computer system design are reliable execution of task and on time delivery of service. To increase system.
Advanced Spectrum Management in Multicell OFDMA Networks enabling Cognitive Radio Usage F. Bernardo, J. Pérez-Romero, O. Sallent, R. Agustí Radio Communications.
Scalable Computing on Open Distributed Systems Jon Weissman University of Minnesota National E-Science Center CLADE 2008.
Ensembles. Ensemble Methods l Construct a set of classifiers from training data l Predict class label of previously unseen records by aggregating predictions.
Competitive Queue Policies for Differentiated Services Seminar in Packet Networks1 Competitive Queue Policies for Differentiated Services William.
SOFTWARE ENGINEERING1 Introduction. SOFTWARE ENGINEERING2 Software Q : If you have to write a 10,000 line program in C to solve a problem, how long will.
© 2008 Morningstar, Inc. All rights reserved. 3/1/2008 LCN Role of Immediate Annuities in Retirement.
Securing Passwords Against Dictionary Attacks Presented By Chad Frommeyer.
 Probability in Propagation. Transmission Rates  Models discussed so far assume a 100% transmission rate to susceptible individuals (e.g. Firefighter.
A Transaction Fee Market Exists Without a Block Size Limit* Peter R Montreal Scalability Workshop September 12, 2015 *Provisos: (1) Inflation rate is nonzero.
Submission doc.: IEEE 11-12/535r1 May 2012 Jarkko Kneckt, NokiaSlide 1 Scanning and FILS requirements Date: Authors:
SCP: A Computationally Scalable Byzantine Consensus Protocol for Blockchains Loi Luu, Viswesh Narayanan, Kunal Baweja, Chaodong Zheng, Seth Gilbert, Prateek.
Your Logo Here Do You Know Your Odds? Presented by: Your Name Here.
Chance Constrained Robust Energy Efficiency in Cognitive Radio Networks with Channel Uncertainty Yongjun Xu and Xiaohui Zhao College of Communication Engineering,
Chapter 8 Estimation ©. Estimator and Estimate estimator estimate An estimator of a population parameter is a random variable that depends on the sample.
1 Potential for Parallel Computation Chapter 2 – Part 2 Jordan & Alaghband.
-1/16- Maximum Battery Life Routing to Support Ubiquitous Mobile Computing in Wireless Ad Hoc Networks C.-K. Toh, Georgia Institute of Technology IEEE.
Algorithm Complexity is concerned about how fast or slow particular algorithm performs.
Mingze Zhang, Mun Choon Chan and A. L. Ananda School of Computing
these are protocols used for changing the bitcoin network protocols
Route Metric Proposal Date: Authors: July 2007 Month Year
Memory Management.
Data Transformation: Normalization
Performance Study of Congestion Price Based Adaptive Service
PJM Load Product (Consumption Product)
Instability Of Bitcoin Without the Block Reward.
What Stops Social Epidemics?
Andy Wang CIS 5930 Computer Systems Performance Analysis
Principles of Investing FIN 330
System Control based Renewable Energy Resources in Smart Grid Consumer
Evaluation Model for LTE-Advanced
SWARNAM S/UNIT 1/RISK & RETURN - CBS
Main Memory Management
CS61C : Machine Structures Lecture 6. 2
Scheduling in Wireless Communication Systems
Process management Information maintained by OS for process management
Yu Su, Yi Wang, Gagan Agrawal The Ohio State University
Providing Secure Storage on the Internet
Determining the Peer Resource Contributions in a P2P Contract
Chapter 5: Software effort estimation
Offset-Time-Based QoS Scheme
ECE232: Hardware Organization and Design
Incentives 26 September 2018.
Lecture 28: Index 3 B+ Trees
Chapter 11 Risk & Return in Capital Markets.
Replica Placement Heuristics of Application-level Multicast
Route Metric Proposal Date: Authors: July 2007 Month Year
Chapter 8 Estimation.
COMP755 Advanced Operating Systems
Blockchain Mining Games
Presentation transcript:

Elastic Block Caps Meni Rosenfeld Israeli Bitcoin Association Scaling Bitcoin 2019 Tel Aviv “Yesod” בס"ד

The problem: Variable fees

The problem: Variable fees

Background: Block Size limit Easier to run a node Higher Miner Reward Faster propagation - Fewer orphans Less reliance on 3rd parties Reduced Mining Gap Lower Fees More network throughput Less reliance on 3rd parties

Easier to run a node Lower peak throughput Weaker CPU/RAM/infrastructure possible Less peak bandwidth Lower average/aggregate throughput Less total power consumption Less consumed bandwidth Less storage Faster Initial Block Download

Mineshaft Mining Gap Assume negligible inflation If blocks are big enough to fit all transactions… Then after a block is found, the mempool is empty No gain from mining honestly Possibility: Miners stop mining, giving more power to attackers Possibility: Miners ignore leaf block and mine their own Better a chance of orphaning than 100% certainty of no reward Instability and more power to attackers Actual risk to network, not just “harder to run a node”

Varying network load – One size doesn’t fit all “Too big” and “too small” are relative High load = blocks are too small. Excessive fees, low usability Low load = blocks are too big. Enough room for everyone, so fees nosedive. Txs are included cheaply, not respecting externalities. Reduced miner payment and security, even though users are willing to pay. Mining Gap Fees are variable Difficulty planning personal economic activity Difficulty planning network upgrades

Elastic Block Caps Block size limit is variable Higher limit during high load, lower limit during low load Fees will depend on load, but not as much Same aggregate throughput, lower fee variability

Related work Similar ideas go by names such as Proposals by Dynamic block limit Flexcaps Excess size penalty Proposals by 2013 - Nicolas van Saberhagen (CryptoNote, Monero) 2015: Greg Maxwell aka nullc Mark Friedenbach aka maaku Meni Rosenfeld

What the proposal is not Not a fire-and forget, long-term block size adjustment Not based on voting Not based on actual size of previous blocks Elastic, not Plastic

Network load metrics #Transactions not a reliable load metric A trillion floating transactions at 0.1 sat/vB is spam, not load Load is when users are actually willing to pay and still can’t get in Good load metric = Block inclusion threshold = Minimal block feerate

Elastic Block Cap f = Smallest feerate in a block (measured in sat/vB) Block limit = Some function 𝑆(𝑓) (measured in MWU) Preferably, S has lower and upper bounds Current: 𝑆(𝑓) = 4 Suggestion: 𝑆 𝑓 =𝑈 − 𝑈−𝐿 𝑓 0 𝑓+ 𝑓 0 . Parameters: 𝐿=2, 𝑈=6, 𝑓 0 =20

Gameability No benefit from lower-than-min fake tx No benefit from higher-than-min fake tx No benefit from out-of-band payments Reverse out-of-band payment – miner pays user? No freedom for miner to insert his own txs Mitigation – use 0.1% quantile instead of minimum

Simulation methodology Transaction rate follows Brownian motion with restoring force 𝑑𝑉= 𝜎𝑑 𝐵 𝑡 + 𝛼 𝑉 − 𝛽 𝐻−𝑉 𝑑𝑡 Each tx has a random value 𝑟 ~ 𝑈 0,1 𝑣= 10 −1+ 1 1−0.98𝑟 Each tx has random priority (desired distance from tip) Fee is chosen to match desired depth. Discarded if higher than value 10% of txs are precommitted – inclusion decided by past mempool Parameters chosen to resemble historical data Simulation code in C#, results analyzed with Mathematica

Results Model Params: 𝐻=16000 tx min , 𝜎= 2.5𝐻 day , 𝛼=𝛽= 𝐻 2 16day 𝑑𝑉= 𝜎𝑑 𝐵 𝑡 + 𝛼 𝑉 − 𝛽 𝐻−𝑉 𝑑𝑡 Model Params: 𝐻=16000 tx min , 𝜎= 2.5𝐻 day , 𝛼=𝛽= 𝐻 2 16day Baseline: 𝐿=𝑈=4 Average fee: 45.8 Average txs per block: 1000 Fee variance: 256.2 Elastic: 𝐿=2, 𝑈=5 Average fee: 44.47 Fee variance: 177.0

Results By implementing elastic block caps with a modest range, fee variance can be reduced by 30%, while maintaining the same average fee and throughput (Standard deviation reduced by 16%)

Older idea – penalty based on block size Equivalent to size based on min-fee More “free-market” Much more complicated to implement and reason about Messes with inflation

The problem with proportional penalty %Penalty based on %Block size difference Doesn’t actually adapt block size to network load When inflation is negligible Block size should be tied to extrinsic scale 𝐹 𝑆 = Total fees with size S 𝐷 𝑆 = PoW difficulty with size S 𝑆 0 = argmax 𝑆 𝐹 𝐷 Invariant to multiplicative constant 𝑑𝐹 𝐷=𝐹 𝑑𝐷

Deployment So simple even I could implement it Current: 𝐿=4, 𝑈=4 But I probably shouldn’t Willing to support implementation efforts Current: 𝐿=4, 𝑈=4 Soon-ish: Soft fork with 𝐿=3.5, 𝑈=4 Later: Hard fork increasing 𝑈 Long-term: Hard fork should include growth schedule E.g. 20% per year Size growth to match hardware improvements and network growth If too small, hard fork again. If too big, soft fork.

Acknowledgements Mike Hearn Jochen Hoenicke aka Johoe Got me thinking about this problem (but everything he said was wrong) Jochen Hoenicke aka Johoe Provides the incredibly valuable mempool stats webpage Nadav Ivgi aka shesek Helped obtain data, insightful conversations Mark Friedenbach aka maaku Fruitful discussion

Questions?