Bitcoin Forum

Now that (thanks to SatoshiDice) we've hit the 250k block size,  there is a great deal of interest about the transaction policies different pools have.

A pool op has messaged me and suggested that pool tx policies would be useful to have as a post, preferrably stickied. I agree. However this data won't fit in the original "Mining pools list"  without making it very messy, so I need to create a new "Mining pools transaction policy list".

The original "Mining pools list" informs miners of pool differences that directly affect their earnings. Pools are split into reward methods, and then other category columns added.

For a "Mining pools transaction policy list", I would recommend listing pools in alphabetical order (names linked to bitcointalk.org forum posts), with category columns.

So, what categories are important? How do pools differ in their tx preference policies?


Here's an example - please let me know if I have any of the explanations wrong.

Note: Since the block size induced hard fork yesterday, I've changed the values below until we have a fix for the problem (or all clients are 0.8.0 or later)

	Maximum	Minimum	Priority	Minimum	Transaction
Pool	block size	block size	block size	fee (BTC)	filtering
BTCGuild (http://bitcointalk.org/index.php?topic=49417.0)	NA	NA	NA	NA	NA
Slush (https://bitcointalk.org/index.php?topic=1976.0)	NA	NA	NA	NA	NA

 

• Maximum block size: the largest size block a pool will create.
• Minimum block size: the largest size block a pool will create that can include any tranaction based on priority and regardless of fee.
• Priority block size: block space given over to high priority and low or no fee transactions.
• Minimum fee: the minimum fee transaction a pool will include in a block.
• Transaction discrimination: a list of source transactions which a pool will refuse to include in a block.

The 5 main categories I see as being useful:
  1) Max block size
  2) Min block size (Any block not this big will include ANY transaction, based on priority, regardless of fee)
  3) Priority block size (Space reserved specifically for high priority+no/low fee transactions)
  4) Minimum fee
  5) TX Discrimination (like how a few pools refuse to include transactions sent to 1dice...)


BTC Guild Settings:
  1) 750,000
  2) 150,000
  3) 100,000
  4) Standard satoshi client fee processing and transaction prioritization
  5) No transactions blocked, ignored, or throttled

There were bottlenecks  in previous versions of bitcoind and increasing block size often caused higher ratio of orphaned blocks. I'd like to thanks bitcoin developers for recent speedups in official software. I played a bit with pool settings and current values on my pool are:

1) Max block size 990k
2) Min block size 50k
3) Priority block size 50k
4) Min fee 0.0001
5) No blocking

Yes, 0.8 is amazing at how fast it can process blocks, and additionally how fast it responds with a template for a new block after an LP.  One thing I've noticed specifically is with more pools moving beyond 250,000 bytes, the time it takes pools to push out new work at a block change has increased dramatically, because bitcoind isn't having to re-prioritize/select as many transactions that weren't included in the prior block.

Updated, with BTCGuild and Slush's pool added. Is this simple enough for everyone to follow?

A comment from fireduck on HHTT policies...

https://bitcointalk.org/index.php?topic=95378.msg1604552#msg1604552

No:

• This is biased to support SatoshiDice's DDoS attack against Bitcoin. Instead of "transaction discrimination", it should be "anti-flooding filter quality"
• There is no such thing as "Standard" transaction fee.
• The chart presupposes bitcoind 0.8 logic.

But couldn't you still publish the stat's that pertain to what your pools block criteria is?  If you disagree with the 2 of the five classifications you could still post the other 3? right?

He 'supposedly' doesn't have a pool ... but we all know that's FUD also ...

I disagree. If the standard previously was to include all sources of tx, then the change would be to refuse to include some tx based on the source. This is not the previous standard behaviour.

I'm not pushing one point of view over another. If you have a serious suggestion about how to name the category- for example "source filtering" would be ok - then try again.

This is the tx fee as recommended by the standard client. I didn't make that at all clear, sorry about that.


Could you clarify that response? It presupposes I know what the hell you're talking about ;)

No, the behaviour of bitcoind has always been to try to filter out floods/spam.
To date, the algorithms used in releases include coin age, output sizes, transaction data size, and fees included.

That varies by branch/version, especially on the miner end.

While "maximum block size" has a well-defined meaning, the others do not.
"Minimum block size" by its literal meaning is obviously something like 140 bytes for all pools - so I presume you mean something else.
"Priority block size" makes no sense until you define what "priority" is - and this is (intentionally) not well-defined even in bitcoind.

OK, I can change the category to "Source filtering". I don't think anyone would mind, and I think you're right in that it doesn't have the same negative connotation that "Transaction discrimination" does.


In this case the minimum fees may need to be made explicit.


Minimum block size and priority block size are both explained in the OP quite clearly:




You are welcome to suggest another name for either of them if these category names are not sufficiently intuitive.

"Default" isn't the right answer to a few of those categories, I think. Either way, I'd like pool ops to post their policies explicitly so I don't get it wrong.

For clarity, I'd define the "default/standard" for BTC Guild fee policy as:  Satoshi Client (0.8) Default.  IE:  We do not impose a non-standard fee requirement, just whatever the most current client defaults to.

Not according to Luke-jr:



Is this statement correct or not? I can't judge.

Luke said it.
If you bet it was either a twisting of fact or a dictionary definition that is incorrect in any but Luke's magic fairy dictionary, then you'd be right more often than wrong.

As for his actual answer, it is nonsense.

The miners have nothing to do with it since there are no 'standard' miners that include the option to mess with transactions.

Yes the standard bitcoind client has different rules over time - however, Luke also makes tests of his own that he thinks should be called standard - but are just simply him making releases that are full of rejected code.
Luke' definition of standard includes anything that flies out of his ass ...

OK - then "not specified" which would fall to the bitcoind (believe he is running 0.8.0) default for everything except mintxfee


We have asked FD to post here as well  :)

At least for the time being, the above settings no longer apply for BTC Guild (and probably the few other pools that responded).  Hopefully 0.8.1 comes soon so we can still increase block size, without worrying about creating a fork due to the 0.7 bug.

+1000

OP updated (a bit)

Triplemining currently does everything with default settings from the 0.7.2 client.  So no filtering, 250kb blocks etc etc
At least for now, I'm waiting for 0.8.1 before I start playing again with the values

agreed, "discrimination" has a negative connotation to it.

change it to "transaction filtering" or "ignored transactions"

Bitparking is currently using all the default settings from the 0.7.2 client.

Fixed. I was getting around to doing it, then that stupid Berkeley database ruined everything and I forgot.


Thanks, doublec.

I'm not planning on updating the OP until there's a patch or there's no bdb clients left - until then block sizes will be limited to default for pretty much everyone. Although I suppose I could keep the "tx filtering" updated.

Looks like not all pools are on the defaults despite all that has happened this week :(
http://blockchain.info/block-index/358797/00000000000001ba4bd010816667d2706fc0ddb3b258835c7d40d2a8c4d2b6a9
617kB from HHTT

HHTT has figured out bdb's limits, and is using those?

They might be doing what I'm doing. My 0.8.0 stratum server node is connected behind a 0.7.2 node so if it sends a bad block the 0.7.2 node will stop it before propagating it to the network. My stratum server is at the defaults though since I'd rather not orphan a block and halt my 0.7.2 getwork node.

If fireduck is doing what you are but with the 0.8.0 server at accepting larger blocks, he will want to fix that fast - a PPS pool does not want orphans.

Now that 0.8.2 is out, perhaps pool operators can start updating the list, especially that the default minimum low-priority fee in pre-0.8.2 is 0.0005 BTC/kB and from 0.8.2 is 0.0001 BTC/kB, so its quite important to see which pools use which policies.

Not quite. I'm pretty sure the 0.0005 BTC was only for sending fees.
The reason behind reducing it was that miners were already accepting the lower fees anyway.