Change Details

This adds virtualsize to the mempool, which will be used for modifying the mining/eviction priority of transactions (which matters under conditions of mempool congestion.) The virtual size is conceptually the actual transaction size with added fudge factors to represent consumption of other block-limited resources besides block space. Currently, just SigOps. In Core, they don't separately track virtual size but rather use virtual size in place of the size itself. (Core's virtual size = max(weight, sigops*20)/4) We cannot just copy Core for two important reasons: - Our sigops limit varies with block size -- see comment in miner.cpp which means if we used virtualsize everywhere then we could generate invalid block templates where it it thought it had more sigops than are actually available. (this problem will be addressed with sigchecks upgrade, where the limit is flat) - On BCH we do avoid suddenly changing basic policy rules, because we want to keep consistent mempool policy. If we changed the min feerate from sat/byte to sat/vbyte this would introduce an easy double spend vector just like if we were to suddenly raise the unconf chain length limit. (this Diff merely adds the virtualsize tracking, which is as-yet unused) Depends on D4896

This adds virtualsize to the mempool, which will be used for modifying the mining/eviction priority of transactions (which matters under conditions of mempool congestion.) The virtual size is conceptually the actual transaction size with added fudge factors to represent consumption of other block-limited resources besides block space. Currently, just SigOps. In Core, they don't separately track virtual size but rather use virtual size in place of the size itself. (Core's defines it as: size_mempool = virtualsize_mempool = max(virtualsize_bip141, sigopscount*20) ) We cannot just copy Core here for two important reasons: - Our sigops limit varies with block size -- see comment in miner.cpp which means if we used virtualsize everywhere then we could generate invalid block templates where it it thought it had more sigops than are actually available. (this problem will be addressed with sigchecks upgrade, where the limit is flat) - On BCH we avoid sudden changes in basic policy rules, because we want to keep consistent mempool policy. If we changed the min feerate from sat/byte to sat/vbyte this would introduce an easy double spend vector just like if we were to suddenly raise the unconf chain length limit. (this Diff merely adds the virtualsize tracking, which is as-yet unused) Depends on D4896

This adds virtualsize to the mempool, which will be used for modifying the mining/eviction priority of transactions (which matters under conditions of mempool congestion.) The virtual size is conceptually the actual transaction size with added fudge factors to represent consumption of other block-limited resources besides block space. Currently, just SigOps. In Core, they don't separately track virtual size but rather use virtual size in place of the size itself. (Core's defines it as: size_mempool = virtual sizesize_mempool = max(weightvirtualsize_bip141, sigopscount*20)/4 ) We cannot just copy Core here for two important reasons: - Our sigops limit varies with block size -- see comment in miner.cpp which means if we used virtualsize everywhere then we could generate invalid block templates where it it thought it had more sigops than are actually available. (this problem will be addressed with sigchecks upgrade, where the limit is flat) - On BCH we do avoid suddenly changinges in basic policy rules, because we want to keep consistent mempool policy. If we changed the min feerate from sat/byte to sat/vbyte this would introduce an easy double spend vector just like if we were to suddenly raise the unconf chain length limit. (this Diff merely adds the virtualsize tracking, which is as-yet unused) Depends on D4896