It seems to me, that if someone wants to improve the priority of a transaction, they do actually want to mine that transaction. What's the point of setting a priority of a transaction that you're not going to mine regardless?

The point is "increase priority" and "requires no fee" should, in my opinion, be independent notions. Somebody might want to bump up the priority of transactions from the Bitcoin Faucet a little because they like the idea of giving newbies a good bitcoin experience, but don't want to crowd out other high-priority/low-fee transactions.

I can take this out if you want me to, but I don't see the point. A priority bump of just 1 has no practical effect on the overall priority comparison, but could be used to whitelist against the fee requirements, and the priority is entirely ignored if a transaction doesn't meet the fee requirements, so it makes no sense to increase the priority while not overriding the fee requirements, IMO.

Re: Ignoring minfee: This call is by txid. If you don't like the fee, don't call it on the transaction. Ignoring minfee is the right thing to do here.

Though this should also have a fee delta, because we now prioritize above minfee txn by fee per KB. If someone is paying you behind the scenes to mine a transaction you should be able to add the amount you're being paid (or whatever) to the fee used in that calculation. e.g. prioritizetransaction .

Adding 16 bytes to every in-memory transaction to support a feature that will not be used by 99.9% of users seems like the wrong thing to do.

How about instead keeping a map<transaction_id, pair<priorityDelta,feeDelta> > in the memory pool class, and have prioritisetransaction add to that map?

Finally: need to check to see if the free transaction rate limiter code needs to take this into account (I assume you should be able to prioritisetransaction and then if you receive the transaction over the network it should sail through the limiter and make it into the memory pool -- or is it assumed that the transaction will get into the memory pool some other way, like a sendrawtransaction call?).

This pull does not merge cleanly onto current master
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.