Related ideas previously submitted by me;

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-March/013885.html

Title: Block size adjustment idea - expedience fees + difficulty scaling proportional to block size (+ fee pool) 

Den sön 7 apr. 2019 17:45simondev1 via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> skrev:
Dear bitcoin developers,
 
 
==Abstract==
Logarithm of transaction fee limits block size.
 
==Motivation==
Keep block space small.
Waste less with spam transactions.
Auto balance Fees: Increase very low fees, Descrease very high fees.
Allow larger size when sender pays a lot.
Allow wallets to calculate/display how much average free block space there is for each fee price.
Allow senders to have more control about how the fee/priority of their transaction will behave, especially in the case of increased adoption in the future.
 
==Specification==
Every transaction has to fit into the following block space:
Input variable 'FeeInSatoshiPerByte': Must be positive or 0
type: double
unit: Satishi per byte
Output:
type: uint
unit: bytes
Formula:
floor( log10( 1.1 + FeeInSatoshiPerByte ) * 1024 * 1024 )
 
==Implementation==
Sort transactions by FeeInSatoshiPerByte (lowest first)
For each transaction starting from lowest FeeInSatoshiPerByte: Sum up the bytes of space used so far. Check if summed up bytes of space used so far is smaller or equal than the formula result.
If this is valid for each transaction then the blocksize is valid.
 
==Backward compatibility==
Soft fork: If applied AND old hardcoded block size limit is kept.
Hard fork: If applied AND old hardcoded block size limit is removed.

Regards, simondev1
 
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev