Author Topic: Minimum Transaction Fee  (Read 3032 times)

0 Members and 1 Guest are viewing this topic.

Offline bytemaster

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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Bitcoinfan

  • Sr. Member
  • ****
  • Posts: 240
    • View Profile
Now that we're moving away from Ripple Consensus again,  what will the transaction speed theoretically be?

Offline bytemaster

Code: [Select]
MIN_FEE = SHARE_SUPPLY *.5% / BLOCKS_PER_YEAR / TARGET_BYTES_PER_BLOCK

What is the reasoning for this particular equation using these particular constants?

Code: [Select]
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. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline vikram

Code: [Select]
MIN_FEE = SHARE_SUPPLY *.5% / BLOCKS_PER_YEAR / TARGET_BYTES_PER_BLOCK

What is the reasoning for this particular equation using these particular constants?

Code: [Select]
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?

Offline Markus

  • Sr. Member
  • ****
  • Posts: 366
    • View Profile
Quote
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)




Offline bytemaster

Quote
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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline bytemaster

Quote
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...

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Markus

  • Sr. Member
  • ****
  • Posts: 366
    • View Profile
OK, this means a constant block size of twice the target block size will lead to fees of only 1.0102040816... times MIN_FEE

Code: [Select]
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?

Offline bytemaster

There is still a MAX block size of 2*TARGET_BLOCK_SIZE, which I guess I didn't mention.



For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline Markus

  • Sr. Member
  • ****
  • Posts: 366
    • View Profile
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:
Code: [Select]
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

Offline bytemaster

I am attempting to set the minimum transaction fee (per byte) and have opted for the following equation:
Code: [Select]
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:

Code: [Select]
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.


For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.