Relaying of free transactions: priority not a factor?

eyci

newbie

Activity: 20

Merit: 0

Quote from: deepceleron on September 10, 2014, 06:46:03 AM

The requirement for all outputs to be 0.01 or greater was dropped. Instead the dust prevention method is now a minimum of 546 satoshi (~1/3 of fee)
https://github.com/bitcoin/bitcoin/blob/master/src/core.h line 195

Thanks.

Quote from: deepceleron on September 10, 2014, 06:46:03 AM

Free transactions have a minimum priority that dictates relatively large BTC amounts or well-aged coins. People can't continuously spam with this rule because they will quickly run out of funds that can be sent for free.

I know this is true for mining, i.e. CreateNewBlock, but my question is specifically about relaying/admitting to mempool. From what I can see, no matter how high the tx priority is, if there is zero fee then it's subject to rate-limiting. This suggests that even high priority transactions may not get relayed properly if they don't include a fee. Just want to make sure that I'm interpreting it correctly.

deepceleron

legendary

Activity: 1512

Merit: 1036

The requirement for all outputs to be 0.01 or greater was dropped. Instead the dust prevention method is now a minimum of 546 satoshi (~1/3 of fee)
https://github.com/bitcoin/bitcoin/blob/master/src/core.h line 195

Free transactions have a minimum priority that dictates relatively large BTC amounts or well-aged coins. People can't continuously spam with this rule because they will quickly run out of funds that can be sent for free.

eyci

newbie

Activity: 20

Merit: 0

Hi I'm trying to understand the default behavior for relaying of zero fee transactions.

In AcceptToMemoryPool we have:

Code:

if (fLimitFree && nFees < ::minRelayTxFee.GetFee(nSize))
{
    static CCriticalSection csFreeLimiter;
    static double dFreeCount;
    static int64_t nLastTime;
    int64_t nNow = GetTime();

    LOCK(csFreeLimiter);

    // Use an exponentially decaying ~10-minute window:
    dFreeCount *= pow(1.0 - 1.0/600.0, (double)(nNow - nLastTime));
    nLastTime = nNow;
    // -limitfreerelay unit is thousand-bytes-per-minute
    // At default rate it would take over a month to fill 1GB
    if (dFreeCount >= GetArg("-limitfreerelay", 15)*10*1000)
        return state.DoS(0, error("AcceptToMemoryPool : free transaction rejected by rate limiter"),
                                 REJECT_INSUFFICIENTFEE, "insufficient priority");
    LogPrint("mempool", "Rate limit dFreeCount: %g => %g\n", dFreeCount, dFreeCount+nSize);
    dFreeCount += nSize;
}

There's no reference to tx priority; am I right in saying that all zero-fee transactions are subject to rate-limiting, regardless of their priority? I had the impression that this was not the case, given how it is often said that transactions with sufficiently high priority can be sent safely without fees.

An additional question: in the wiki it says that "A transaction may be safely sent without fees if ... all outputs are 0.01 BTC or larger". I'm not sure where this 0.01 BTC figure comes from, I couldn't find any reference to it in the code, could someone point it out for me?

Thanks.

Topic: Relaying of free transactions: priority not a factor? (Read 1419 times)