Author

Topic: [ATTN POOL OPS] List of pools' transaction policies. (Read 3460 times)

legendary
Activity: 2576
Merit: 1186
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.
sr. member
Activity: 334
Merit: 250
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.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
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.
legendary
Activity: 1078
Merit: 1005
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.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
No:
  • This is biased to support SatoshiDice's DDoS attack against Bitcoin. Instead of "transaction discrimination", it should be "anti-flooding filter quality"
agreed, "discrimination" has a negative connotation to it.

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

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

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

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 Sad
http://blockchain.info/block-index/358797/00000000000001ba4bd010816667d2706fc0ddb3b258835c7d40d2a8c4d2b6a9
617kB from HHTT

HHTT has figured out bdb's limits, and is using those?
vip
Activity: 980
Merit: 1001
No:
  • This is biased to support SatoshiDice's DDoS attack against Bitcoin. Instead of "transaction discrimination", it should be "anti-flooding filter quality"
agreed, "discrimination" has a negative connotation to it.

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

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

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

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 Sad
http://blockchain.info/block-index/358797/00000000000001ba4bd010816667d2706fc0ddb3b258835c7d40d2a8c4d2b6a9
617kB from HHTT

donator
Activity: 2058
Merit: 1007
Poor impulse control.
No:
  • This is biased to support SatoshiDice's DDoS attack against Bitcoin. Instead of "transaction discrimination", it should be "anti-flooding filter quality"
agreed, "discrimination" has a negative connotation to it.

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

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

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

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.
legendary
Activity: 1078
Merit: 1005
Bitparking is currently using all the default settings from the 0.7.2 client.
legendary
Activity: 2058
Merit: 1452
No:
  • This is biased to support SatoshiDice's DDoS attack against Bitcoin. Instead of "transaction discrimination", it should be "anti-flooding filter quality"
agreed, "discrimination" has a negative connotation to it.

change it to "transaction filtering" or "ignored transactions"
sr. member
Activity: 263
Merit: 250
Pool operator of Triplemining.com
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
donator
Activity: 2058
Merit: 1007
Poor impulse control.
OP updated (a bit)
legendary
Activity: 1666
Merit: 1000
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
legendary
Activity: 1750
Merit: 1007
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.
legendary
Activity: 1666
Merit: 1000
A comment from fireduck on HHTT policies...

https://bitcointalksearch.org/topic/m.1604552


"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=      Set minimum block size in bytes (default: 0)
 -blockprioritysize= Set maximum size of high-priority/low-fee transactions in bytes (default: 27000)

We have asked FD to post here as well  Smiley
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
For clarity, I'd define the "default/standard" for BTC Guild fee policy as:  Satoshi Client (0.Cool 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 ...
donator
Activity: 2058
Merit: 1007
Poor impulse control.
For clarity, I'd define the "default/standard" for BTC Guild fee policy as:  Satoshi Client (0.Cool 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.
legendary
Activity: 1750
Merit: 1007
For clarity, I'd define the "default/standard" for BTC Guild fee policy as:  Satoshi Client (0.Cool Default.  IE:  We do not impose a non-standard fee requirement, just whatever the most current client defaults to.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
A comment from fireduck on HHTT policies...

https://bitcointalksearch.org/topic/m.1604552


"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.
donator
Activity: 2058
Merit: 1007
Poor impulse control.

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 Wink
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:

Quote
Minimum block size: the largest size block a pool will create that can include any tranaction based on priority and regardless of fee.

Quote
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.
legendary
Activity: 2576
Merit: 1186
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 Wink
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.
donator
Activity: 2058
Merit: 1007
Poor impulse control.
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 Wink
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
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 ...
legendary
Activity: 3583
Merit: 1094
Think for yourself
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?
legendary
Activity: 2576
Merit: 1186
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.
legendary
Activity: 1666
Merit: 1000
A comment from fireduck on HHTT policies...

https://bitcointalksearch.org/topic/m.1604552
donator
Activity: 2058
Merit: 1007
Poor impulse control.
Updated, with BTCGuild and Slush's pool added. Is this simple enough for everyone to follow?
legendary
Activity: 1750
Merit: 1007
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.
legendary
Activity: 1386
Merit: 1097
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
legendary
Activity: 1750
Merit: 1007
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
donator
Activity: 2058
Merit: 1007
Poor impulse control.
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)

MaximumMinimumPriorityMinimumTransaction
Pool            block size    block size    block size    fee (BTC)       filtering
BTCGuildNANANANANA
SlushNANANANANA

 
  • 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.
Jump to: