BitShares Forum
Main => General Discussion => Topic started by: bytemaster on February 04, 2014, 11:49:42 pm
-
I am attempting to set the minimum transaction fee (per byte) and have opted for the following equation:
MIN_FEE = SHARE_SUPPLY *.5% / BLOCKS_PER_YEAR / TARGET_BYTES_PER_BLOCK
Then I was going to adjust the fee every block with the following equation:
NEXT_FEE_BASE = BLOCK_SIZE * PREV_FEE / TARGET_BYTES_PER_BLOCK
NEXT_FEE = (MIN_FEE * 99 + NEXT_FEE_BASE)/100
if( NEXT_FEE < MIN_FEE ) NEXT_FEE = MIN_FEE
Therefore as demand for transactions increases fees automatically go up, and as demand slacks fees go down. This should put a cap on the blockchain size.
Feedback appreciated.
-
To understand the first formula easier. It is equivalent to Min_Fee per year being 0.5% of Share_Supply, or initially 20 000 BTS per year. That seems fine for me.
After playing a bit with a spreadsheet it seems the formula has a very weak effect as long as Block_Size < 100*Target_Block_Size:
10*Target_Block_Size --> Fee=1.1*Min_Fee
40*Target_Block_Size --> Fee=1.65*Min_Fee
80*Target_Block_Size --> Fee=5*Min_Fee
Only once the average Block_Size >= 100*Target_Block_Size the fees start to run away.
The other effect is (maybe that was intended): Fees ramp up slowly with high block sizes but fall very quickly once only one small block occurs.
Maybe something like this:
NEXT_FEE_BASE = BLOCK_SIZE * PREV_FEE / TARGET_BYTES_PER_BLOCK
NEXT_FEE = (MIN_FEE + PREV_FEE * 98 + NEXT_FEE_BASE)/100
if( NEXT_FEE < MIN_FEE ) NEXT_FEE = MIN_FEE
-
There is still a MAX block size of 2*TARGET_BLOCK_SIZE, which I guess I didn't mention.
-
OK, this means a constant block size of twice the target block size will lead to fees of only 1.0102040816... times MIN_FEE
NEXT_FEE_BASE = BLOCK_SIZE * PREV_FEE / TARGET_BYTES_PER_BLOCK
NEXT_FEE = (MIN_FEE * x + NEXT_FEE_BASE * (100-x))/100
if( NEXT_FEE < MIN_FEE ) NEXT_FEE = MIN_FEE
Your formula is above code with x=99.
If you tweak it a little with x round about 50 you might get a stronger effect. Values above 50 will have a ceiling for NEXT_FEE, values below 50 will make the fees run away more or less quickly for constant large block sizes near 2*TARGET_BYTES_PER_BLOCK
PS: I assume BLOCKS_PER_YEAR and TARGET_BYTES_PER_BLOCK are constants?
-
NEXT_FEE_BASE = BLOCK_SIZE * PREV_FEE / TARGET_BYTES_PER_BLOCK
NEXT_FEE = (PREV_FEE * 99 + NEXT_FEE_BASE)/100
if( NEXT_FEE < MIN_FEE ) NEXT_FEE = MIN_FEE
My mistake... I meant to use PREV_FEE * 99 not MIN_FEE...
-
NEXT_FEE_BASE = BLOCK_SIZE * PREV_FEE / TARGET_BYTES_PER_BLOCK
NEXT_FEE = (PREV_FEE * 99 + NEXT_FEE_BASE)/100
if( NEXT_FEE < MIN_FEE ) NEXT_FEE = MIN_FEE
My mistake... I meant to use PREV_FEE * 99 not MIN_FEE...
With that one change the fees are 3.68x MIN_FEE after just 133 blocks at 2x the target.... and it will continue to grow as long as the block is above target.
-
NEXT_FEE_BASE = BLOCK_SIZE * PREV_FEE / TARGET_BYTES_PER_BLOCK
NEXT_FEE = (PREV_FEE * 99 + NEXT_FEE_BASE)/100
if( NEXT_FEE < MIN_FEE ) NEXT_FEE = MIN_FEE
My mistake... I meant to use PREV_FEE * 99 not MIN_FEE...
Yeah, that nearly looks like my first post :)
That one looks fine to me. It should pull the long term average block size towards below TARGET_BYTES_PER_BLOCK.
The reason I put 1% of MIN_FEE into my first post was to make it slowly forget too large blocks. After 100 blocks of 2x target yours needs, e.g., 1000 blocks of 0.9x target for the fee to reach MIN_FEE again. Mine would fall back slowly even if block_size remains at 1x target whereas yours would then stay at a constant higher fee level. I guess it doesn't really matter.
I crossed out the towards because of the MIN_FEE rule. It causes series of blocks smaller than target size preceding series of large blocks to be ignored. (Once the average block size is below the target size, saving space is not credited)
-
MIN_FEE = SHARE_SUPPLY *.5% / BLOCKS_PER_YEAR / TARGET_BYTES_PER_BLOCK
What is the reasoning for this particular equation using these particular constants?
NEXT_FEE_BASE = BLOCK_SIZE * PREV_FEE / TARGET_BYTES_PER_BLOCK
NEXT_FEE = (PREV_FEE * 99 + NEXT_FEE_BASE)/100
if( NEXT_FEE < MIN_FEE ) NEXT_FEE = MIN_FEE
What is the reasoning for using a 100-block moving average and not some other size window?
-
MIN_FEE = SHARE_SUPPLY *.5% / BLOCKS_PER_YEAR / TARGET_BYTES_PER_BLOCK
What is the reasoning for this particular equation using these particular constants?
NEXT_FEE_BASE = BLOCK_SIZE * PREV_FEE / TARGET_BYTES_PER_BLOCK
NEXT_FEE = (PREV_FEE * 99 + NEXT_FEE_BASE)/100
if( NEXT_FEE < MIN_FEE ) NEXT_FEE = MIN_FEE
What is the reasoning for using a 100-block moving average and not some other size window?
100 block is about 1 day of blocks and was a nice round number.
.5% of the money supply set the average transaction fee at a couple of cents assuming BTS were worth $1000 each.
-
Now that we're moving away from Ripple Consensus again, what will the transaction speed theoretically be?
-
Now that we're moving away from Ripple Consensus again, what will the transaction speed theoretically be?
An average of 512KB every 5 minutes and 256 bytes per transaction = 2000 transactions every 5 minutes or about 6-7 transactions per second.
The spend under Ripple Consensus would have had the same size restrictions, so the only thing that has changed is the average confirmation time. In 10 minutes you have more security than bitcoin gives you in 120 blocks.