A friendly plea to pool operators...

[Kermee]

As of August 4th, 2011, 2:06:53 AM UTC:

There are 803 unconfirmed transactions (252105 bytes):

There are 756 low priority transactions.

Can you guys up the limit of low-priority/free TX's that are included with solved blocks?

Cheers,
Kermee

[1713559985]

1713559985

[1713559985]

1713559985

[1713559985]

1713559985

[1713559985]

1713559985

[Graet]

https://en.bitcoin.it/wiki/Transaction_fees says:
If a mining node (pool or solo miner) receives a transaction that should include a transaction fee but doesn't, they may refuse to include it in their blocks. It might be included in a later block if someone is willing to accept it. Generators can't force a certain fee on transactions -- they can only accept or reject the transaction's “fee offer”.

I know some pools are "refusing" to accept free transactions.
I make free transactions and think it would be hypocritical of me and bad for Bitcoin generally if I were to refuse to include free transactions in my pools blocks.

[Kermee]

I know some pools are "refusing" to accept free transactions.
I make free transactions and think it would be hypocritical of me and bad for Bitcoin generally if I were to refuse to include free transactions in my pools blocks.

From Blockexplorer, I see solved blocks which don't include any free transactions at all.

I understand the logic behind fee and no-fee transactions, but when nearly 95% or more of the solved blocks are coming from the Top 4-5 pool operators because they aggregate to being 95% of the total network hash rate... Those 4-5 people are the ones controlling what transactions are being processed and which ones aren't.

There are 937 unconfirmed transactions (304627 bytes):

There are 868 low priority transactions.

Cheers,
Kermee

[Jine]

Is there a public patch available for latest stable bitcoind which makes it accept no-fee transactions?
I'd be glad to apply it to our 6 bitcoind-nodes.

[Sukrim]

For just a few cents fee you can more or less ensure that your transaction will be in the next block.

Also in the future, transaction fees will be a requirement, as there is a cost connected with transactions and it will be the sole source of income for miners (and already is for many pools).

There is a patch to make bitcoind require only _very_ low fees (but always) afaik. by luke-jr. If you include any transaction, you just help spamming the network. There's a good reason, why these transactions are not included.

Nearly no pool operator has patched bitcoind himself, so I doubt that any pool besides Eligius actually uses rules different from vanilla bitcoind, and Eligius makes it very cheap to include "spammy" transactions.

[phorensic]

For just a few cents fee you can more or less ensure that your transaction will be in the next block.

Also in the future, transaction fees will be a requirement, as there is a cost connected with transactions and it will be the sole source of income for miners (and already is for many pools).

There is a patch to make bitcoind require only _very_ low fees (but always) afaik. by luke-jr. If you include any transaction, you just help spamming the network. There's a good reason, why these transactions are not included.

Nearly no pool operator has patched bitcoind himself, so I doubt that any pool besides Eligius actually uses rules different from vanilla bitcoind, and Eligius makes it very cheap to include "spammy" transactions.

BitcoinMonkey and a few others are using Joel Katz' patches to bitcoind.

[Xephan]

Is it possible for pool operators to accept no-fee transactions through a particular node like what Luke has set up, AND subsequently process this in a block for whitelisted address/users so that legit usage for what looks like a "spammy" transaction can still be carried out within a reasonably short time?

The whitelist could simply be the receiving address of miners mining for the pool, and those who abuse to spam the network without providing a reason to the pool admin would simply get struck off the whitelist.

This would help those of us who need to work on things that uses small transactions and can't afford/conveniently (Paypal anybody?) buy BTC just to keep paying fees that are easily more than amount sent.

[Jine]

Nearly no pool operator has patched bitcoind himself, so I doubt that any pool besides Eligius actually uses rules different from vanilla bitcoind, and Eligius makes it very cheap to include "spammy" transactions.

I don't think there is a larger pool then 300-400Gh that has NOT applied patches to bitcoind.

[Sukrim]

For just a few cents fee you can more or less ensure that your transaction will be in the next block.

Also in the future, transaction fees will be a requirement, as there is a cost connected with transactions and it will be the sole source of income for miners (and already is for many pools).

There is a patch to make bitcoind require only _very_ low fees (but always) afaik. by luke-jr. If you include any transaction, you just help spamming the network. There's a good reason, why these transactions are not included.

Nearly no pool operator has patched bitcoind himself, so I doubt that any pool besides Eligius actually uses rules different from vanilla bitcoind, and Eligius makes it very cheap to include "spammy" transactions.

BitcoinMonkey and a few others are using Joel Katz' patches to bitcoind.

emphasis added...

The patch is from Joel Katz, not from the pool operators.
I haven't seen yet a sophisticated patch to bitcoind that allows more freely definable transaction policies than what Luke-Jr posted.

It might be possible for example to create a patch that always accepts transactions signed by certain keys. Then hand out these keys + the patch to pool operators and everyone participating can always send free transactions latest when the next block of a participating pool is found. It might be even worth setting up a bounty for this, depending on how many transaction fees pools really pay (I don't know that).

[AnnihilaT]

Is there a public patch available for latest stable bitcoind which makes it accept no-fee transactions?
I'd be glad to apply it to our 6 bitcoind-nodes.

Mainframe would also be delighted to apply such a patch to our nodes.   While i agree that users need to get used to the idea of paying fees,  completely "locking out" their transactions may not be the best way to go about this.   At least for the foreseeable future,  we would be happy to run any stable and tested patch which implements this functionality.

[Zoomer]

Perhaps free transactions should be lowest priority, and possibly delayed? However, given the early stage of bitcoin development, forcing all transactions to carry a fee seems premature.

[Fiyasko]

Perhaps free transactions should be lowest priority, and possibly delayed? However, given the early stage of bitcoin development, forcing all transactions to carry a fee seems premature.

Everything you just said is common knowledge by now. I see the fee's as "Go fast, or go slow, Take your pick" The point of MANDITORY minimum fees is so that someone cant FLOOD the fuck out of the blockchain with .0000001 transactions, Effectivly slowing Anyone else not paying fees for transactions

[drawoc]

In main.h, there are 2 lines around line 35 that look like:

Code:

static const int64 MIN_TX_FEE = 50000;
static const int64 MIN_RELAY_TX_FEE = 10000;

The first being the minimum fee for a transaction to be included in a block, the second being the minimum fee for one node to forward it to another node. Both numbers are in satoshis.

All of the logic for calculating the fee is in the function GetMinFee() around line 527.
There's a certain area of each block that free transaction are allowed to be in. That number is defined around line 574:

Code:

// Free transaction area
if (nNewBlockSize < 27000)
    nMinFee = 0;

In the example, 27,000 is the free area (in bytes), where the maximum block size is 500,000. (It's probably a bad idea to set this to 250,000 or higher.)

I believe that the OP was suggesting that you increase the size of the free area, so more feeless transactions can go through.

Whether changing this is a good idea or not is another discussion. Always test on testnet before modifying production servers, don't sue me, etc etc.