[ATTN POOL OPS] List of pools' transaction policies.

[organofcorti]

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	NA	NA	NA	NA	NA
Slush	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.

[eleuthria]

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

[slush]

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

[eleuthria]

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:

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.

[organofcorti]

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

[JWU42]

A comment from fireduck on HHTT policies...

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

[Luke-Jr]

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.

[os2sam]

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?

[kano]

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

[organofcorti]

No:

• This is biased to support SatoshiDice's DDoS attack against Bitcoin. Instead of "transaction discrimination", it should be "anti-flooding filter quality"

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.

• There is no such thing as "Standard" transaction fee.

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

• The chart presupposes bitcoind 0.8 logic.

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

[Luke-Jr]

No:

• This is biased to support SatoshiDice's DDoS attack against Bitcoin. Instead of "transaction discrimination", it should be "anti-flooding filter quality"

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.

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.

• There is no such thing as "Standard" transaction fee.

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

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

• The chart presupposes bitcoind 0.8 logic.

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

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.

[organofcorti]

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.

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.

• There is no such thing as "Standard" transaction fee.

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

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

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

• The chart presupposes bitcoind 0.8 logic.

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

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.

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

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.

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

[organofcorti]

A comment from fireduck on HHTT policies...

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

"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.

[eleuthria]

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

[organofcorti]

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

Not according to Luke-jr:

• There is no such thing as "Standard" transaction fee.

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

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

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

[kano]

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

Not according to Luke-jr:

• There is no such thing as "Standard" transaction fee.

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

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

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

[JWU42]

A comment from fireduck on HHTT policies...

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

"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.

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

Code:

Block creation options:
 -blockminsize=<n>      Set minimum block size in bytes (default: 0)
 -blockprioritysize=<n> Set maximum size of high-priority/low-fee transactions in bytes (default: 27000)

We have asked FD to post here as well 

[eleuthria]

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.

[JWU42]

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

[organofcorti]

OP updated (a bit)