You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the case of AcceptToMemoryPool, this assumption filters out transactions which otherwise should have enough fees to get in to a block based on logic. A proper fix would be to calculate the minimum size of a block(a block with just coinbase and coinstake) and pass that to the CTransaction::GetMinFee as the block size. The rate-limiting loop beneath should also be removed as free transactions are disallowed and the code is never reached anyway.
In the case of CreateRestOfTheBlock, hard-coding of 1000 is illogical as the block size could easily be fetched using a GetSerializedSize call to the block being constructed. Another thing to note here is that theoretically if the block size is fetched before the transactions are added and the sizes of transactions are added afterwards to the stored block size, the calculated size of the block might not match the serialized size of the block. One unlikely case of this could happen if a block were to include 254 > transactions, the compact size of the block.vtx will be larger than initially recorded.
On a side note, I disagree with the current sort of transactions in the miner. The miner should be greedy and sort by fee rate(GRC/byte) to maximize it's gains in my opinion.
The text was updated successfully, but these errors were encountered:
Currently
CWallet::CreateTransaction
,AcceptToMemoryPool
andCreateRestOfTheBlock
all operate on the assumption that block size 1000 bytes when calculating transaction fees.AcceptToMemoryPool
, this assumption filters out transactions which otherwise should have enough fees to get in to a block based on logic. A proper fix would be to calculate the minimum size of a block(a block with just coinbase and coinstake) and pass that to theCTransaction::GetMinFee
as the block size. The rate-limiting loop beneath should also be removed as free transactions are disallowed and the code is never reached anyway.CreateRestOfTheBlock
, hard-coding of 1000 is illogical as the block size could easily be fetched using aGetSerializedSize
call to the block being constructed. Another thing to note here is that theoretically if the block size is fetched before the transactions are added and the sizes of transactions are added afterwards to the stored block size, the calculated size of the block might not match the serialized size of the block. One unlikely case of this could happen if a block were to include 254 > transactions, the compact size of theblock.vtx
will be larger than initially recorded.CWallet::CreateTransaction
is where this gets complicated. The miner sorts transactions based on the value and depth of the inputs which makes truly calculating the required fee impossible as the spot of the transaction and the total size of the earlier transactions might not be known. There are two ways to go from here, we could follow Bitcoin's approach of using fee rates and block inclusion times for transactions or we could roll something of our own, possibly by calculating the fee based upon average block sizes.On a side note, I disagree with the current sort of transactions in the miner. The miner should be greedy and sort by fee rate(GRC/byte) to maximize it's gains in my opinion.
The text was updated successfully, but these errors were encountered: