Skip to content

JSON-RPC method: prioritisetransaction <txid> <priority delta> #1583

Merged
merged 1 commit into from Jun 26, 2014

9 participants

@luke-jr
Bitcoin member
luke-jr commented Jul 11, 2012

Accepts the transaction into mined blocks at a higher (or lower) priority

@jgarzik
Bitcoin member
jgarzik commented Jul 11, 2012

Code seems ACK-worthy.

Use cases?

@luke-jr
Bitcoin member
luke-jr commented Jul 11, 2012

Various people (@gmaxwell and @gavinandresen included) expressed interest in this - one example was to allow captcha-solving as an alternative to fees.

@Diapolo Diapolo commented on an outdated diff Jul 11, 2012
src/main.h
@@ -396,6 +399,9 @@ class CTransaction
mutable int nDoS;
bool DoS(int nDoSIn, bool fIn) const { nDoS += nDoSIn; return fIn; }
+ double dPriorityDelta;
+
@Diapolo
Diapolo added a note Jul 11, 2012

Have 2 empty lines a special meaning in the code?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@gavinandresen gavinandresen and 1 other commented on an outdated diff Jul 12, 2012
src/main.h
@@ -540,6 +547,9 @@ class CTransaction
int64 GetMinFee(unsigned int nBlockSize=1, bool fAllowFree=true, enum GetMinFee_mode mode=GMF_BLOCK) const
{
+ if (dPriorityDelta > 0)
@gavinandresen
Bitcoin member

What's the logic here? Why would setting a >0 delta automatically imply a minimum fee of zero?

@luke-jr
Bitcoin member
luke-jr added a note Jul 12, 2012

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?

@gavinandresen
Bitcoin member

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.

@luke-jr
Bitcoin member
luke-jr added a note Jul 13, 2012

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@gavinandresen gavinandresen commented on an outdated diff Jul 12, 2012
src/main.h
@@ -92,6 +92,9 @@
bool SendMessages(CNode* pto, bool fSendTrickle);
bool LoadExternalBlockFile(FILE* fileIn);
void GenerateBitcoins(bool fGenerate, CWallet* pwallet);
+bool PrioritiseTransaction(const uint256 hash, const std::string strHash, double dPriorityDelta);
+bool PrioritiseTransaction(const uint256 hash, double dPriorityDelta);
+bool PrioritiseTransaction(const std::string strHash, double dPriorityDelta);
@gavinandresen
Bitcoin member

Three versions of this is excessive. Less code, please.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@gmaxwell

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 .

@luke-jr
Bitcoin member
luke-jr commented Aug 13, 2012

Updated with suggestions. Also, is it intentional that GetMinFee with GMF_BLOCK is never used anymore?

@luke-jr luke-jr referenced this pull request Aug 13, 2012
Closed

next 2012-08-13 #1671

@BitcoinPullTester

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/2c63ef9156288b3cc72668fdb6ce44ec3a440076 for binaries and test log.

@sipa
Bitcoin member
sipa commented Aug 13, 2012

@luke-jr Which commit removed the call to GetMinFee with GMF_BLOCK?

@luke-jr
Bitcoin member
luke-jr commented Aug 13, 2012
@sipa sipa and 1 other commented on an outdated diff Aug 13, 2012
@@ -3349,6 +3349,23 @@ class COrphan
};
+bool PrioritiseTransaction(const uint256 hash, const string strHash, double dPriorityDelta, int64 nFeeDelta)
+{
+ if (!mempool.mapTx.count(hash))
+ {
+ printf("PrioritiseTransaction: cannot find %s\n", strHash.c_str());
+ return false;
+ }
+
+ CTransaction &txn = mempool.mapTx[hash];
@sipa
Bitcoin member
sipa added a note Aug 13, 2012

This needs a LOCK on mempool.cs, imho. Even if it's somehow already safe because of the lock on cs_main, I'd prefer having it there, for when RPC locks get pushed down.

@luke-jr
Bitcoin member
luke-jr added a note Aug 13, 2012

Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@gmaxwell

Needs a rebase

@luke-jr
Bitcoin member
luke-jr commented Nov 14, 2012

rebased

@gavinandresen gavinandresen and 1 other commented on an outdated diff Feb 13, 2013
@@ -477,6 +479,10 @@ class CTransaction
std::vector<CTxOut> vout;
unsigned int nLockTime;
+ double dPriorityDelta;
+ int64 nFeeDelta;
@gavinandresen
Bitcoin member

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?).

@luke-jr
Bitcoin member
luke-jr added a note Feb 13, 2013

With the deltas stored on CTransaction, applying them to not-received ones was impractical. Obviously using a map as you suggest solves this problem too - will do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@luke-jr
Bitcoin member
luke-jr commented Apr 12, 2013

Ok, finally redid this using a map.

@gavinandresen , look good?

@jgarzik
Bitcoin member
jgarzik commented May 30, 2013

No objection... though I still prioritize with the 'z' :) Who the heck uses an 's'? :)

@laanwj laanwj commented on an outdated diff May 30, 2013
src/main.cpp
@@ -574,6 +574,16 @@ bool CTransaction::CheckTransaction(CValidationState &state) const
int64 CTransaction::GetMinFee(unsigned int nBlockSize, bool fAllowFree,
enum GetMinFee_mode mode) const
{
+ {
+ LOCK(mempool.cs);
+ uint256 hash = GetHash();
+ double dPriorityDelta = 0;
+ int64 nFeeDelta = 0;
+ mempool.ApplyDeltas(hash, dPriorityDelta, nFeeDelta);
@laanwj
Bitcoin member
laanwj added a note May 30, 2013

I don't like all these side-effects in a const getter function

Edit: hmm, never mind, ApplyDeltas does not actually change anything in the mempool object.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@luke-jr
Bitcoin member
luke-jr commented Aug 21, 2013

It occurs to me that the map should be cleaned at some point. Any opinions on when to remove a txid from it?

@gmaxwell

Check it when removing transactions from the mempool?

@luke-jr
Bitcoin member
luke-jr commented Aug 21, 2013

Probably don't want to lose priority adjustments if your block gets knocked off the main chain...

@petertodd

@luke-jr Set a expiry height after they get knocked off the main chain and remove them from the map after n blocks? If n=100 is reached we have bigger problems...

@gavinandresen
Bitcoin member

Rebase needed.

@luke-jr
Bitcoin member
luke-jr commented Oct 25, 2013

Rebased. For purging from the map.. how about when we see a block confirm a transaction using it as an input?

@luke-jr
Bitcoin member
luke-jr commented Dec 3, 2013

Rebased and added mapDeltas pruning when transactions are removed from the memory pool (ie, included in a block).

@laanwj
Bitcoin member
laanwj commented Jun 3, 2014

This pull has been open for almost two years now.
What still has to be done for this to me merged? (apart from a rebase)

@jgarzik
Bitcoin member
jgarzik commented Jun 3, 2014

ACK -- appears to be done, to me, modulo a rebase.

This is IMO important to merge. We want to give miners controls like this, so that they may innovate and compete.

Related: Miners also need an "accept this TX even if it's non-standard" RPC or RPC flag.

@BitcoinPullTester

Automatic sanity-testing: FAILED MERGE, see http://jenkins.bluematt.me/pull-tester/p1583_4427dc5e6a6fd0f7349e6ea3e0d6a084491cf265/ for test log.

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.

@laanwj laanwj commented on an outdated diff Jun 25, 2014
src/miner.cpp
@@ -77,6 +79,35 @@ class COrphan
};
+void CTxMemPool::PrioritiseTransaction(const uint256 hash, const string strHash, double dPriorityDelta, int64_t nFeeDelta)
@laanwj
Bitcoin member
laanwj added a note Jun 25, 2014

These implementations should be in txmempool.cpp.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@luke-jr luke-jr JSON-RPC method: prioritisetransaction <txid> <priority delta> <prior…
…ity tx fee>

Accepts the transaction into mined blocks at a higher (or lower) priority
2a72d45
@luke-jr
Bitcoin member
luke-jr commented Jun 26, 2014

Rebased with @laanwj 's change.

@laanwj laanwj merged commit 2a72d45 into bitcoin:master Jun 26, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.