Skip to content
This repository has been archived by the owner on Mar 13, 2019. It is now read-only.

Latest commit

 

History

History
62 lines (49 loc) · 2.43 KB

cip-0003.md

File metadata and controls

62 lines (49 loc) · 2.43 KB
CIP: 3
Title: Variable Slot-based Fees
Author: PoCC/rico666 <bots@cryptoguru.org>
Comments-Summary: No comments yet.
Comments-URI: https://github.com/PoC-Consortium/CIPs/wiki/Comments:CIP-0003
Status: Active
Type: Hard Fork
Created: 2018-04-26

Abstract

The slot-based transaction fee system allows for variable fees depending on the transaction load on the blockchain. As a secondary goal it prevents spamming blocks with lots of transactions with minimum fees.

Motivation

As of December 2017, the transaction cost structure comparison between Burstcoin and Bitcoin (1 BURST = ca. 150 Sat), shows 0.85 satoshi/Byte in the Burstcoin network and therefore a roughly 317x higher cost for Bitcoin block space and ca. 900x higher cost for network transactions, as a Bitcoin transaction is roughly 500 bytes in size.

In Fiat, this means that at a price of around 3 US-cent per BURST, one byte of payload costs 0.017 cent in the Burstcoin network and around 5.4 cent in the Bitcoin network. If the hardcoded tx cost for the Burst network was to remain at 1 BURST minimum, Burst would reach the same level of tx cost that Bitcoin has today at a price of 176 ∗ 5.4 = 950.4 US-cent, therefore around $9.50.

If we look at todays price levels, Burstcoin miners were ensuring the network for a maximum payment of 91800 Burst daily. On average, the network has been doing around 5000 tx/day. So in addition to the block reward, the transaction fee reward per day, for the whole Burstcoin network is around $150 in December 2017. In order to cope with future development of BURST price and transaction volume, a progressive tx fee structure guideline is proposes, where wallets can decide and priorize what transaction to include in the current block depending on the fill-state of the current block and memory pool backlog. The progressive approach opens the door for more on-chain scalability. Instead of limiting the max. number of transactions to 255, we could now theoretically have an open limit and solve much of the scalability issues blockchains have per se. Instead, a conservative extension of the max. number of transactions to 1020 (4-fold) is proposed.

Specification

Compatibility

This is a hard forking change, thus breaks compatibility with old fully-validating node. It should not be deployed without widespread consensus.

Memory-Related Parameters

  1. fee quant

Copyright

This document is placed in the public domain.