The conversion to configurable size for high priority transactions did not include fee calculations. It seems like it should. Consolidates another magic number.
Free tx area should be configurable for fee calculation, also #2750
pull jgarzik wants to merge 2 commits into bitcoin:master from jgarzik:free-tx-area changing 3 files +24 −17-
jgarzik commented at 1:11 PM on June 7, 2013: contributor
-
Move block size parameter setting from main.cpp to init.cpp. 30fffe51bc
-
GetMinFee now notices configurable size of free TX area. 9309a8edfc
-
BitcoinPullTester commented at 4:24 PM on June 8, 2013: none
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/9309a8edfc7e0d8946792839b8dfc11b7c9d08c4 for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.
-
gavinandresen commented at 9:33 PM on June 8, 2013: contributor
ACK
-
wtogami commented at 8:49 AM on June 9, 2013: contributor
+unsigned int nBlockMaxSize = MAX_BLOCK_SIZE_GEN/2; +unsigned int nBlockMinSize = 0; +unsigned int nBlockPrioritySize = 27000;
Why are these defined here and the defaults again defined in init.cpp?
-
mikehearn commented at 12:02 PM on June 13, 2013: contributor
Could someone merge BlueMatts refactoring of the fee code and then rebase this on top of it? Matt's pull makes things a lot easier to follow and removes some pointless duplication.
-
-
wtogami commented at 6:49 PM on June 26, 2013: contributor
Possible bug: In our testing we found strange behavior when nBlockPrioritySize was set to 10000. Incoming zero fee transactions like 99XX bytes with sufficient priority would be accepted by nodes with nBlockPrioritySize 27000 but rejected by otherwise identical code with nBlockPrioritySize of 10000 with "not enough fees". The mempool in both nodes had a few small 225 byte high priority transactions. Wouldn't you expect the node with nBlockPrioritySize of 10000 to accept a 99XX byte transaction and keep it in the memory pool until there is room in a later block?
-
-
jgarzik commented at 3:35 PM on October 2, 2013: contributor
Even though this was ACK'd... don't care about this enough to continue rebasing and maintaining it. Closing.
- jgarzik closed this on Oct 2, 2013
-
mikehearn commented at 3:39 PM on October 2, 2013: contributor
:( it seems like this should be merged ... what happened?
-
jgarzik commented at 3:47 PM on October 2, 2013: contributor
@mikehearn "don't care about this enough to continue rebasing and maintaining it" Following Gavin's ACK, more work was piled on top. Not interested in constant rebasing on top of someone else's code as suggested up-thread.
-
Diapolo commented at 12:26 PM on October 3, 2013: none
I think this is an example, where our merge-process could be smoother, so devs do not get frustrated with constant rebasing...
- jgarzik deleted the branch on Aug 24, 2014
- DrahtBot locked this on Sep 8, 2021
