How to send BitCoins with LOW TX FEE (Not No TX Fee)

[CIYAM]

That's not it - the default fee rules force fee payment on dust outputs.

If the output is old enough then no tx fee is necessary (even if it is only 1 Satoshi).

[1538086134]

1538086134

[1538086134]

1538086134

[1538086134]

1538086134

[gweedo]

They send it once a day, probably other external funds that are aged.

That's not it - the default fee rules force fee payment on dust outputs.

Not if aged, if aged long enough no fees are force, or even needed. This is prevent spamming the blockchain.

[Peter Todd]

Not if aged, if aged long enough no fees are force, or even needed. This is prevent spamming the blockchain.

No, CTxMemPool::accept() won't accept such a transaction into the mempool at all:

Code:

int64 txMinFee = tx.GetMinFee(1000, true, GMF_RELAY);
if (fLimitFree && nFees < txMinFee)
    return error("CTxMemPool::accept() : not enough fees %s, %"PRI64d" < %"PRI64d,
                        hash.ToString().c_str(),
                        nFees, txMinFee);

and CTransaction::GetMinFee():

Code:

// To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
if (nMinFee < nBaseFee)
{
    BOOST_FOREACH(const CTxOut& txout, vout)
        if (txout.nValue < CENT)
            nMinFee = nBaseFee;
}

Age has nothing to do with it.

[gweedo]

Not if aged, if aged long enough no fees are force, or even needed. This is prevent spamming the blockchain.

No, CTxMemPool::accept() won't accept such a transaction into the mempool at all:

Code:

int64 txMinFee = tx.GetMinFee(1000, true, GMF_RELAY);
if (fLimitFree && nFees < txMinFee)
    return error("CTxMemPool::accept() : not enough fees %s, %"PRI64d" < %"PRI64d,
                        hash.ToString().c_str(),
                        nFees, txMinFee);

and CTransaction::GetMinFee():

Code:

// To limit dust spam, require MIN_TX_FEE/MIN_RELAY_TX_FEE if any output is less than 0.01
if (nMinFee < nBaseFee)
{
    BOOST_FOREACH(const CTxOut& txout, vout)
        if (txout.nValue < CENT)
            nMinFee = nBaseFee;
}

Age has nothing to do with it.

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

https://en.bitcoin.it/wiki/Transaction_Fee#Technical_info

Fees are calculated using age.

[Peter Todd]

Read the code, not some wiki.

Priority is only used if the minimum fee is zero. If there is a dust output, the minimum fee calculated by GetMinFee() is not zero.

[gweedo]

Read the code, not some wiki.

Priority is only used if the minimum fee is zero. If there is a dust output, the minimum fee calculated by GetMinFee() is not zero.

You have no link to the code, I can't take your word for a snippet, but I am still 99.999999% sure that dust, that is aged can be sent without a fee, if aged. I coded a faucet, I kinda know what I am talking about in that sense, and the wiki is also pretty reliable.

[Peter Todd]

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L574

[CIYAM]

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L574

Didn't know you could add the line # to such source links - nice!

But just below that is the following:

Code:

if (fAllowFree)
    {
        if (nBlockSize == 1)
        {
            // Transactions under 10K are free
            // (about 4500 BTC if made of 50 BTC inputs)
            if (nBytes < 10000)
                nMinFee = 0;
        }
        else
        {
            // Free transaction area
            if (nNewBlockSize < 27000)
                nMinFee = 0;
        }
    }

And the call you showed to this function sets fAllowFree to true.

[Peter Todd]

The code you quoted sets nMinFee to zero if there is space left in the current block, or if the size is less than 10KB, depending on the value of the nBlockSize argument to the function.

However regardless of what nMinFee is set to the next part sets nMinFee to nBaseFee - either 0.0005 or 0.0001 depending on if the fee is being calculated for transaction relay or inclusion in a block - regardless of fAllowFree if there is a dust output.

[CIYAM]

Interesting - does this apply to both "sides" of the tx (i.e. the input UTXOs and the output UTXOs)?

[Peter Todd]

Interesting - does this apply to both "sides" of the tx (i.e. the input UTXOs and the output UTXOs)?

No, only outputs.

[CIYAM]

No, only outputs.

Aha - then I am not quite sure what the OP's problem is if you look at something like this:

https://blockchain.info/tx/0e058abfe294c051262610ff689a75577f5884529cc1cfcc108cd491b0d6b64f

[gweedo]

https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L574

That is the min fees, you do realized that? So age still can bypass that...

[BitHits]

wait...so you mean to tell me the age of my coins is the primary factor? I thought it was the size of the transaction that was the main driver...

I'm assuming when sending coins using Official Client its automatically using the oldest coins first...

Code:

priority = sum(input_value_in_base_units * input_age)/size_in_bytes

so the total value of the transaction * the age / size of tx....

you would think a larger transaction....would have a smaller fee then

and if that formula is taken literally, the OLDER the coins, the higher the fee....

Assuming a tx value of 0.04 and an age of 1 day and 4 days, with a 20,000 byte size

$calc(0.04 * 1)/20000) = 0.04 fee to send 0.04

$calc(0.04 * 4)/20000) = 0.16 fee to send 0.04

at the same time, thats not the fee thats calculated Thats the priority, so a lower priority would incur a larger fee and a higher priority would incur a lower fee....

so really 0.04 priority on 1 day old coins and 0.16 priority on 4 day old coins.

So....those calculations are not exact or accurate at all, but proportionately they should be close. As I'm sure the number formats I'm using are not the same passed in the protocol or used in actual calculation...


Using the real values, what would be the ideal age/size for a transaction of 0.0208 lets say to 2600 Addresses for a size of about... 100kb (0.000008 to each addr)

[BitHits]

No, only outputs.

Aha - then I am not quite sure what the OP's problem is if you look at something like this:

https://blockchain.info/tx/0e058abfe294c051262610ff689a75577f5884529cc1cfcc108cd491b0d6b64f

40686 size
0.94498248 input

fees came out to 0.0205

1191 addresses paid...

majority of that transaction was to 1CQxknB3zDS6tCLJUP7ZBfTS8yfRmABjhT 0.94497058 BTC

I've thought about included a larger input to an affiliate or something usually like 400uBTC if i process a 4 day payout, could try to process like 14 days at a time, but would have to be broken up into many transactions

Also the larger input was probably added later by the network, ive seen that happen on some of my payout transactions.

[Gavin Andresen]

Straight Bitcoin isn't designed for really small transactions.  If you're sending less than something like $1 worth of bitcoins, you should expect to pay 10% or more in fees. More if you're trying to send $0.10 or less.

There is no magic fairy wand we can wave and make Bitcoin suddenly great for gazillions of tiny transactions; plan your businesses accordingly. As transaction volume increases, there will be more competition for space in blocks and fees are likely to rise.

And please avoid filling your customer's wallets with "dust" that they'll pay huge fees to spend; a payout should be at least a couple of cents, not a fraction of a penny. I think there is pretty good consensus among the core developers that sooner or later we'll make "dust" outputs non-standard, so they are not relayed or mined by default (details to be worked out, we need to implement a good algorithm for auto-adjusting the definition of "dust").

[BitHits]

Straight Bitcoin isn't designed for really small transactions.  If you're sending less than something like $1 worth of bitcoins, you should expect to pay 10% or more in fees. More if you're trying to send $0.10 or less.

There is no magic fairy wand we can wave and make Bitcoin suddenly great for gazillions of tiny transactions; plan your businesses accordingly. As transaction volume increases, there will be more competition for space in blocks and fees are likely to rise.

And please avoid filling your customer's wallets with "dust" that they'll pay huge fees to spend; a payout should be at least a couple of cents, not a fraction of a penny. I think there is pretty good consensus among the core developers that sooner or later we'll make "dust" outputs non-standard, so they are not relayed or mined by default (details to be worked out, we need to implement a good algorithm for auto-adjusting the definition of "dust").

Wow! For someone to get $1 worth of bitcoins...at current rate....using many of the Faucet sites.... They'd have to max out their limit on my site for 25 days straight...That would also mean I would need to process a months worth of transactions at a time.....

And your doing this...by design!?

Also adding an option to voluntarily declare your output non-standard and pay no tx fee or a fee with a reasonable calculation based on tx input would be a great option! I'm paying 1000% in fees currently. So fuck 10% would be awesome!

[jaywaka2713]

Actually, I'm trying to run a BitCoin Faucet/PTC Site.

www.BitHits.info

The fees are becoming ridiculous thou!

Try only paying out once a day by grouping every transaction together.

[BitHits]

These are the payouts I've done so far.

1 day

http://blockchain.info/tx/1bac0affe468940a679576f1dcdb687355560892600228c69c12ca914b4fd34f
http://blockchain.info/tx/36567fb8b3a76a4dd29e08800fc50300c6dc8348a190c9e7454ac1116e281575

1 day

http://blockchain.info/tx/1e559d53134e26acd259e6c314e540c4313734dc71961646c07d6941fe2b38ca

1 day

http://blockchain.info/tx/d6f664ba78d003680416fb0f63c3dbd0d7a4e5aa7adb18de44db62506aefd372

1 day

http://blockchain.info/tx/db90637b4a7107b3abcfee3669357770f26ddbf2d7231317154a1d9ce98e1346

2 days

http://blockchain.info/tx/63628dcf1800fd0c26bee6f3fdab777e7fe71075054cc343e1e4cbe059157304

2 days

http://blockchain.info/tx/3b7021f03e745fdba2aafee65dc30d07dd3d88644fc4030792187fa64e2ef917

1 day

http://blockchain.info/tx/251683372fe66d45444f34969813a4223f57f2fdab5f067d8ba2e000b2ea44a2

2 days

http://blockchain.info/tx/7307b81ad1953c1ce7a82c76d3d53986afb682f5b949f25a81aef943f5c28f72

2 days

http://blockchain.info/tx/3748bdd0392802c665134e55186d06010a314bb7f6a6d4c23129313913cd8349

2 days

http://blockchain.info/tx/59665fd8ff4e9c68cba72fe25be9b68f6fa0f9e5dc87e0e7c6639c0e69bcedec

2 days

http://blockchain.info/tx/46af1219713b0bddac9e02529d20d211c15f46425d764e23594bc25b4d5082c9

1 day

http://blockchain.info/tx/7b02ac50314c928beb9011eecf096aaecf264026a1948f7dadbff412e23e3427

4 days

http://blockchain.info/tx/24ee838c252c39b131f33202874b379e363e0d4e0d620581959a711dfaa84f05

And then there was a bit of an experiement on the recent payout, tried multiple tx sizes

Code:

2013-03-16 23:27:18 0.008114 BTC
Transaction fee: -0.005 BTC

http://blockchain.info/tx/330b923327d27 ... b36a90b644

2013-03-16 23:44:17 0.016626 BTC
Transaction fee: -0.006 BTC

http://blockchain.info/tx/fc47b7e6d24df ... 6751062a48

2013-03-16 23:54:44 0.004200 BTC
Transaction fee: -0.004 BTC

http://blockchain.info/tx/7279d51294fd8 ... a7f6be8386

2013-03-17 00:32:29 0.006314 BTC
Transaction fee: -0.006 BTC

http://blockchain.info/tx/41f4e6d77f66a ... afb9bdb788

2013-03-17 02:35:49 0.004216 BTC
Transaction fee: -0.004 BTC

http://blockchain.info/tx/0c23fd4da5023 ... 46113caaae


2013-03-17 02:48:25 0.006305 BTC
Transaction fee: -0.006 BTC

http://blockchain.info/tx/09f7e90e3e79c ... a8b24ce3fd

I'll sum up the total amount sent and the total fees to sent said amount in the next few minutes and update.

Total Sent: 0.043105
Fees          0.111

257% in amount sent paid in fees.

[jaywaka2713]

Some send once a week. Try asking other faucet admins about their methods and see if you can pick up a script to automate sendmany for you. I'm sure their servers contain such scripts. If anything, try looking at the source code of a faucet site and see if the input area for the Bitcoin Address sends the input to a script, and if so, rip the script and reverse it for your server. I'm sure asking for it would be much easier though.