[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[Subo1977]

Default settings are:

Code:

mintxfee=0.0001
minrelaytxfee=0.0001

If you're suffering from high getblocktemplate latency, try to increase both. Don't go crazy, just slightly higher than default should work. The goal here is that your mempool doesn't accumulate spam transactions that other pools won't confirm.

These settings will get your getblocktemplate latency down:

Code:

mintxfee=0.0005
minrelaytxfee=0.0005

I think These Settings Must be in satoshis for the latest git

These settings need to be in floats as BTC. (https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp#L417). Will edit if someone corrects me.

Look at https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L51

The Parameter  Is In satoshi

[1714292446]

1714292446

[1714292446]

1714292446

[1714292446]

1714292446

[zvs]

So I'm wondering whether the current long round time is related to the high latency issue. I've clicked on over a dozen of the servers in the list at http://p2pool-nodes.info/ and every single one of them has had a getwork template latency of >10 seconds.

I'm currently running a reindex on my bitcoind. It found a heap of orphan transactions and is now re-downloading the blockchain from around height 100,000...

I think I'm also going to have to temporarily switch to a different pool, until this catches up.

mine is on there and doesn't have one over 10 seconds

i mean, the answer has already been posted on here multiple times

here:

http://blockchain.info/address/1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T

you fix this by raising your min relay fee

Sun May 19 2013 08:12:00 GMT-0500 (Central Daylight Time)   7.89m
Sat May 18 2013 15:24:00 GMT-0500 (Central Daylight Time)   0.0150
Fri May 17 2013 22:36:00 GMT-0500 (Central Daylight Time)   0.0124
Fri May 17 2013 05:48:00 GMT-0500 (Central Daylight Time)   7.61m
Thu May 16 2013 13:00:00 GMT-0500 (Central Daylight Time)   0.0184
Wed May 15 2013 20:12:00 GMT-0500 (Central Daylight Time)   9.67m
Wed May 15 2013 03:24:00 GMT-0500 (Central Daylight Time)   9.19m
Tue May 14 2013 10:36:00 GMT-0500 (Central Daylight Time)   0.0336
Mon May 13 2013 17:48:00 GMT-0500 (Central Daylight Time)   0.0317
Mon May 13 2013 01:00:00 GMT-0500 (Central Daylight Time)   8.21m
Sun May 12 2013 08:12:00 GMT-0500 (Central Daylight Time)   0.0193
Sat May 11 2013 15:24:00 GMT-0500 (Central Daylight Time)   0.0149
Fri May 10 2013 22:36:00 GMT-0500 (Central Daylight Time)   0.0130
Fri May 10 2013 05:48:00 GMT-0500 (Central Daylight Time)   0.0122
Thu May 09 2013 13:00:00 GMT-0500 (Central Daylight Time)   0.0180
Wed May 08 2013 20:12:00 GMT-0500 (Central Daylight Time)   0.0183
Wed May 08 2013 03:24:00 GMT-0500 (Central Daylight Time)   0.00
Tue May 07 2013 10:36:00 GMT-0500 (Central Daylight Time)   0.0110
Mon May 06 2013 17:48:00 GMT-0500 (Central Daylight Time)   8.49m
Mon May 06 2013 01:00:00 GMT-0500 (Central Daylight Time)   6.06m
Sun May 05 2013 08:12:00 GMT-0500 (Central Daylight Time)   7.25m
Sat May 04 2013 15:24:00 GMT-0500 (Central Daylight Time)   9.19m
Fri May 03 2013 22:36:00 GMT-0500 (Central Daylight Time)   5.98m
Fri May 03 2013 05:48:00 GMT-0500 (Central Daylight Time)   0.0133
Thu May 02 2013 13:00:00 GMT-0500 (Central Daylight Time)   0.0159
Wed May 01 2013 20:12:00 GMT-0500 (Central Daylight Time)   0.0103
Wed May 01 2013 03:24:00 GMT-0500 (Central Daylight Time)   7.86m

btw, again  for the nth time

raising mintxfee just raises the cost for any transactions that YOU create

[kano]

Default settings are:

Code:

mintxfee=0.0001
minrelaytxfee=0.0001

If you're suffering from high getblocktemplate latency, try to increase both. Don't go crazy, just slightly higher than default should work. The goal here is that your mempool doesn't accumulate spam transactions that other pools won't confirm.
...

Wrong ... that many other pools WILL confirm
... usual comments about how people (it seems often) make p2pool bad for bitcoin ...
... and when people do this, the rest of p2pool is supporting them by paying them in their blocks also ...

[svirus]

I added GetBlockTemplate Latency to http://p2pool.hostv.pl/
Just click "check" and your browser calculate this

[daemondazz]

What exactly do you mean by "catches up"? Will everybody need to update their bitcoind etc?

I meant for the re-index to complete and the daemon to then catch up with the network. I've got two servers which both required a reindex, not sure what's up with that.

you fix this by raising your min relay fee

And as I've posted, I tried to set minrelaytxfee to 0.0005 and also 5000 and neither made any difference, the latency kept going back up after some period of time, usually less than an hour.

[gyverlb]

Default settings are:

Code:

mintxfee=0.0001
minrelaytxfee=0.0001

If you're suffering from high getblocktemplate latency, try to increase both. Don't go crazy, just slightly higher than default should work. The goal here is that your mempool doesn't accumulate spam transactions that other pools won't confirm.
...

Wrong ... that many other pools WILL confirm
... usual comments about how people (it seems often) make p2pool bad for bitcoin ...
... and when people do this, the rest of p2pool is supporting them by paying them in their blocks also ...

Yeah right, looks like other pools are confirming these transactions:
http://blockchain.info/fr/unconfirmed-transactions

Currently that's 21MB worth of transactions which is at least 40 blocks with the default bitcoind settings (~500kB).

kano, just go embarass yourself elsewhere.

[gyverlb]

These settings need to be in floats as BTC. (https://github.com/bitcoin/bitcoin/blob/master/src/util.cpp#L417). Will edit if someone corrects me.

Look at https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L51

The Parameter  Is In satoshi

All values are stored in satoshi in the code (everything is done with integers, floats would have been a nightmare) but the configuration file parsing definitely is designed to parse a float.

[gyverlb]

btw, again  for the nth time

raising mintxfee just raises the cost for any transactions that YOU create

Do you have a link to code/documentation proving this?
AFAIK there's paytxfee for that, mintxfee is for what you accept in your blocks when you mine and minrelaytxfee is what you accept to relay to other nodes.

[gyverlb]

btw, again  for the nth time

raising mintxfee just raises the cost for any transactions that YOU create

Do you have a link to code/documentation proving this?
AFAIK there's paytxfee for that, mintxfee is for what you accept in your blocks when you mine and minrelaytxfee is what you accept to relay to other nodes.

So to avoid too much memory being eaten by the thousands of transactions currently waiting to be confirmed the only way is to raise both minrelaytxfee and mintxfee.

If the current situation continues it seems the time when low fees where usable is ending: people will have to compete to be included in a block. Currently there's 40 blocks worth of transation, this is a 6 to 7 hours backlog.

[daemondazz]

Yeah right, looks like other pools are confirming these transactions:
http://blockchain.info/fr/unconfirmed-transactions

Currently that's 21MB worth of transactions which is at least 40 blocks with the default bitcoind settings (~500kB).

Very useful link there. As a matter of interest, how big is the list of unconfirmed transactions normally?

[kano]

btw, again  for the nth time

raising mintxfee just raises the cost for any transactions that YOU create

Do you have a link to code/documentation proving this?
AFAIK there's paytxfee for that, mintxfee is for what you accept in your blocks when you mine and minrelaytxfee is what you accept to relay to other nodes.

So to avoid too much memory being eaten by the thousands of transactions currently waiting to be confirmed the only way is to raise both minrelaytxfee and mintxfee.

If the current situation continues it seems the time when low fees where usable is ending: people will have to compete to be included in a block. Currently there's 40 blocks worth of transation, this is a 6 to 7 hours backlog.

... so what happens during that 6 to 7 hours ?

[mdude77]

Default settings are:

Code:

mintxfee=0.0001
minrelaytxfee=0.0001

If you're suffering from high getblocktemplate latency, try to increase both. Don't go crazy, just slightly higher than default should work. The goal here is that your mempool doesn't accumulate spam transactions that other pools won't confirm.
...

Wrong ... that many other pools WILL confirm
... usual comments about how people (it seems often) make p2pool bad for bitcoin ...
... and when people do this, the rest of p2pool is supporting them by paying them in their blocks also ...

Yeah right, looks like other pools are confirming these transactions:
http://blockchain.info/fr/unconfirmed-transactions

Currently that's 21MB worth of transactions which is at least 40 blocks with the default bitcoind settings (~500kB).

kano, just go embarass yourself elsewhere.

This discussion has come up before.  I believe some pool ops are limiting transactions, but I know some aren't.  At least that's what was stated last time.

The future of bitcoin is transactions.  I fail to see how limiting transactions can be beneficial to bitcoin, especially as the value of BTC rises.  For example, if it was worth $1000 USD, there's no way I'd spend .01 on a transaction ($10).

M

[zvs]

What exactly do you mean by "catches up"? Will everybody need to update their bitcoind etc?

I meant for the re-index to complete and the daemon to then catch up with the network. I've got two servers which both required a reindex, not sure what's up with that.

you fix this by raising your min relay fee

And as I've posted, I tried to set minrelaytxfee to 0.0005 and also 5000 and neither made any difference, the latency kept going back up after some period of time, usually less than an hour.

5000 is too low, it would need to be 50000 if that's the way it works (5000 is 0.00005).  I've never modified the fees except via source code.

Transactions like this:

http://blockchain.info/tx/fe03d93a778f881d11a66c7d13c667701f24ff9b97d7d083d6dd3827aee0d553

will go into your queue if you don't raise the relay from 0.0001 (*pre 0.8.2, i think the 0.0000025 would get rejected by 0.8.2).   He's done a lot of transactions that comply with the 0.0001 fee, all these will be stored & increase your latency.

it's also the reason why ppl complain about how their latency creeps up over time (even before this nonsense).    bitcoind getmininginfo will show all the stored tx.  if your relay fee is set high enough, all of those get cleared out.  i think his coins are also old enough to qualify as priority transactions (which has a default 27000 limit, so your client will also store all of his transactions under 27000 bytes regardless of fee, unless you set blockprioritysize=0).

if these are set to default, with this horse person spamming crap, then you will have, well, more 99kb and 20-27kb transactions than you can shake a stick at being stored in memory, bitcoind getmininginfo will show this for bitcoind.  i never use bitcoin-qt

ed: btw, has anyone ever seen a 'CTxMemPool::accept() : free transaction rejected by rate limiter' in their log?

ed2: the unconfirmed transactions i check fairly frequently, very rarely has it been over 500KB in the last 3 months or so... during the times where difficulty was decreasing, it would occasionally be >1MB

ed3: it should be pretty apparent what most of the major pools are doing in regard to relay fees, just by looking at the latest blocks and the transactions contained within

[gyverlb]

Yeah right, looks like other pools are confirming these transactions:
http://blockchain.info/fr/unconfirmed-transactions

Currently that's 21MB worth of transactions which is at least 40 blocks with the default bitcoind settings (~500kB).

Very useful link there. As a matter of interest, how big is the list of unconfirmed transactions normally?

I didn't check this value for quite some time.
But if the rate of transactions is below the network's capacity (around 500kB every 10 minutes currently, could potentially rise to 1MB every 10 minutes depending on how miners setup their bitcoind), this value should be below 500kB most of the time (assuming blockchain.info only includes valid tx in this number which is probably the case).

[Amph]

still no bitcoin from the last time i mined(3 days ago)

[centove]

FWIW...

bitcoind - current git master (8.2.0) default (I changed nothing):

Code:

bitcoind getmininginfo
{
    "blocks" : 237053,
    "currentblocksize" : 249858,
    "currentblocktx" : 732,
    "difficulty" : 11187257.46136079,
    "errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications",
    "generate" : false,
    "genproclimit" : -1,
    "hashespersec" : 0,
    "pooledtx" : 1710,
    "testnet" : false
}

Latency climbing up to around 2 seconds....

http://ask.gxsnmp.org/

[gyverlb]

still no bitcoin from the last time i mined(3 days ago)

If you stopped mining 3 days ago and you are speaking of your p2pool rewards I don't see how it can be news.

[gyverlb]

FWIW...

bitcoind - current git master (8.2.0) default (I changed nothing):

Code:

bitcoind getmininginfo
{
    "blocks" : 237053,
    "currentblocksize" : 249858,
    "currentblocktx" : 732,
    "difficulty" : 11187257.46136079,
    "errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications",
    "generate" : false,
    "genproclimit" : -1,
    "hashespersec" : 0,
    "pooledtx" : 1710,
    "testnet" : false
}

Latency climbing up to around 2 seconds....

http://ask.gxsnmp.org/

2 seconds is not bad, people have seen 10+ seconds.

I have 0.13s with mintxfee and minrelaytxfee set to 0.001 with this result:

Code:

{
    "blocks" : 237057,
    "currentblocksize" : 99814,
    "currentblocktx" : 345,
    "difficulty" : 11187257.46136079,
    "errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications",
    "generate" : false,
    "genproclimit" : -1,
    "hashespersec" : 0,
    "pooledtx" : 1221,
    "testnet" : false
}

I'll set these two to 0.002 next time I have the chance.

[Amph]

still no bitcoin from the last time i mined(3 days ago)

If you stopped mining 3 days ago and you are speaking of your p2pool rewards I don't see how it can be news.

so those share are lost?

[rav3n_pl]

still no bitcoin from the last time i mined(3 days ago)

If you stopped mining 3 days ago and you are speaking of your p2pool rewards I don't see how it can be news.

so those share are lost?

Yes. PPLNS in P2pool is pyain for last 24hrs of mining. Up to 3 blocks per every share.