Bitcoin Forum
December 11, 2016, 12:31:12 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 [264] 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2035105 times)
PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
May 05, 2013, 12:45:27 PM
 #5261

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one  Wink

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

With respect, you've never seen any problems. That does not mean that there aren't any.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
1481416272
Hero Member
*
Offline Offline

Posts: 1481416272

View Profile Personal Message (Offline)

Ignore
1481416272
Reply with quote  #2

1481416272
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481416272
Hero Member
*
Offline Offline

Posts: 1481416272

View Profile Personal Message (Offline)

Ignore
1481416272
Reply with quote  #2

1481416272
Report to moderator
1481416272
Hero Member
*
Offline Offline

Posts: 1481416272

View Profile Personal Message (Offline)

Ignore
1481416272
Reply with quote  #2

1481416272
Report to moderator
1481416272
Hero Member
*
Offline Offline

Posts: 1481416272

View Profile Personal Message (Offline)

Ignore
1481416272
Reply with quote  #2

1481416272
Report to moderator
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
May 05, 2013, 12:47:38 PM
 #5262

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one  Wink

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

There is also an issue with p2pool not being to work properly with ASICs, even as small as a jalapeno.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
PatMan
Hero Member
*****
Offline Offline

Activity: 924


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
May 05, 2013, 12:51:35 PM
 #5263

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one  Wink

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

There is also an issue with p2pool not being to work properly with ASICs, even as small as a jalapeno.

M

Which highlights the desperate need of a complete rework.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
Amph
Legendary
*
Offline Offline

Activity: 1358



View Profile
May 05, 2013, 01:07:54 PM
 #5264

still the best duo for me is cgminer 3.0.1 and p2pool 11.2, much more efficiency and less reject than other

maqifrnswa
Sr. Member
****
Offline Offline

Activity: 454


View Profile
May 05, 2013, 02:54:38 PM
 #5265

regarding custom compiled bitcoind for "optimal" p2pool operation

he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu


This is an interesting point: should p2pool be changed so that we take away a miner's freedom to choose what transactions to accept in order to help the bitcoind network?

Summary: by custom tweaking bitcoin code, you can create 0 transaction blocks with tiny p2pool latency. That is great for the individual miner that does it (higher efficiency) but horrible for the bitcoind network (and for other p2pool miners who are "honest"). Galvin Anderson did some calculations to show that the 0 tx strategy is not profitable compared to accepting transactions for solo (or regular pooled) bitcoind mining. I wonder if it's true for p2pool...

Whether it was written in C or python (or intercal), this would be a problem and is a fundamental question.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 05, 2013, 03:15:11 PM
 #5266

regarding custom compiled bitcoind for "optimal" p2pool operation

he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu


This is an interesting point: should p2pool be changed so that we take away a miner's freedom to choose what transactions to accept in order to help the bitcoind network?

Summary: by custom tweaking bitcoin code, you can create 0 transaction blocks with tiny p2pool latency. That is great for the individual miner that does it (higher efficiency) but horrible for the bitcoind network (and for other p2pool miners who are "honest"). Galvin Anderson did some calculations to show that the 0 tx strategy is not profitable compared to accepting transactions for solo (or regular pooled) bitcoind mining. I wonder if it's true for p2pool...

Whether it was written in C or python (or intercal), this would be a problem and is a fundamental question.

Simply fix bitcoind instead of focusing on p2pool. Giving a block template for p2pool to use should be nearly instantaneous. The problem seems to be that bitcoind rebuilds the whole block template from scratch on each request instead of preparing it in the background. Fix that and nobody will have to tune bitcoind anymore.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Amph
Legendary
*
Offline Offline

Activity: 1358



View Profile
May 05, 2013, 05:38:42 PM
 #5267

the pool is growing pretty well

wtogami
Sr. Member
****
Offline Offline

Activity: 263



View Profile
May 05, 2013, 08:10:12 PM
 #5268

A mean average of 0.1 went up to a mean average of over 0.3.....

Which measure is this, the "Bitcoind GetBlockTemplate Latency"?  11.4 here with a mean of 0.0606s over the past 24 hours.

If you appreciate my work please consider making a small donation.
BTC:  1LkYiL3RaouKXTUhGcE84XLece31JjnLc3      LTC:  LYtrtYZsVSn5ymhPepcJMo4HnBeeXXVKW9
GPG: AEC1884398647C47413C1C3FB1179EB7347DC10D
kano
Legendary
*
Online Online

Activity: 1932


Linux since 1997 RedHat 4


View Profile
May 05, 2013, 09:11:56 PM
 #5269

...
he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

Of course he can.

But it also means that what is best for bitcoin is to NOT use p2pool.
The opposite of what is commonly argued.

As the thread title says: Decentralized, DoS-resistant, Hop-Proof pool

Pool mining on a pool that has a block size limit of 500k or 5k, which is better for bitcoin?

So the answer to that is ... it is better for bitcoin to NOT use p2pool since p2pool seems to require it's users to restrict transactions dramatically.

It's a very simple argument.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
May 05, 2013, 09:36:26 PM
 #5270

...
he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

Of course he can.

But it also means that what is best for bitcoin is to NOT use p2pool.
The opposite of what is commonly argued.

As the thread title says: Decentralized, DoS-resistant, Hop-Proof pool

Pool mining on a pool that has a block size limit of 500k or 5k, which is better for bitcoin?

So the answer to that is ... it is better for bitcoin to NOT use p2pool since p2pool seems to require it's users to restrict transactions dramatically.

It's a very simple argument.

I function just fine w/o having to restrict transactions at all.  Must be something with his environment.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
Krak
Hero Member
*****
Offline Offline

Activity: 591



View Profile WWW
May 05, 2013, 09:39:57 PM
 #5271

I function just fine w/o having to restrict transactions at all.  Must be something with his environment.

M
He seems to think there's an orphan problem. There's only been 2 orphans in the past 3 months. Roll Eyes

BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
Smoovious
Hero Member
*****
Offline Offline

Activity: 504

Scattering my bits around the net since 1980


View Profile
May 05, 2013, 09:42:30 PM
 #5272

...
he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

Of course he can.

But it also means that what is best for bitcoin is to NOT use p2pool.
The opposite of what is commonly argued.

As the thread title says: Decentralized, DoS-resistant, Hop-Proof pool

Pool mining on a pool that has a block size limit of 500k or 5k, which is better for bitcoin?

So the answer to that is ... it is better for bitcoin to NOT use p2pool since p2pool seems to require it's users to restrict transactions dramatically.

It's a very simple argument.
Honestly, the orphan thing has more to do with too many connections on bitcoind than it does on p2pool...

p2pool already goes out of its way to help facilitate found blocks getting distributed as fast as possible, but there is no way you're going to be 100% orphan free with the way the bitcoin network itself operates.

Processing transactions is what mining is all about. Too many have forgotten that, believing that mining is about getting coin, and if you can throw in some transactions while you do it, why not.

But... processing the transactions is what our sole purpose as miners, actually is.

Probably be better off to keep the connection counts down to 2-4 on bitcoind, and low connections on p2pool as well, so we're sending data to less people, allowing them to be sent, faster, and let the meganodes with the bandwidth to handle it, focus on the wide redistribution.

It does no good for a node with a residential-quality upstream, to pass along block data to 50 nodes, if it takes 10 seconds to do it.

The torrent community fights about this too, and the best nodes you find that are sending to you fast, are the ones who aren't trying to keep 500 connections open, giving each peer just a few kB/s at a time, making block propagation just drag out forever, much longer than it should, with extra wasted overhead.

Block propagation suffers the same way. Less really is sometimes more.

-- Smoov
kano
Legendary
*
Online Online

Activity: 1932


Linux since 1997 RedHat 4


View Profile
May 05, 2013, 09:48:53 PM
 #5273

...
he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

Of course he can.

But it also means that what is best for bitcoin is to NOT use p2pool.
The opposite of what is commonly argued.

As the thread title says: Decentralized, DoS-resistant, Hop-Proof pool

Pool mining on a pool that has a block size limit of 500k or 5k, which is better for bitcoin?

So the answer to that is ... it is better for bitcoin to NOT use p2pool since p2pool seems to require it's users to restrict transactions dramatically.

It's a very simple argument.

I function just fine w/o having to restrict transactions at all.  Must be something with his environment.

M
Good counter argument Smiley

Edit: meaning - then - that the problem is him and being detrimental to bitcoin to solve his problem and advertising others to do that is really ... not ideal at all.

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
centove
Full Member
***
Offline Offline

Activity: 194


View Profile
May 05, 2013, 10:00:24 PM
 #5274

For what it's worth...

My node (http://ask.gxsnmp.org:9332/) has:
P2Pool - Peers   8 out, 29 in
Bitcoind:  "connections" : 51,
             "currentblocksize" : 66063,

Getwork Latency -Mean: 0.695s

And it seems to be doing fine.

Uptime: 11.257 days.

That's @ all the 'default' settings

Could it be better? Probably.. I'm just not really sure what to tweak to make it better, it seems to be working and I get payouts whenever a block is found.

Give me Btc: 1BRkf5bwSVdGCyvu4SyYBiJjEjbNiAQoYd Mine on my node: http://ask.gxsnmp.org:9332/
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
May 05, 2013, 10:13:30 PM
 #5275

Processing transactions is what mining is all about. Too many have forgotten that, believing that mining is about getting coin, and if you can throw in some transactions while you do it, why not.

But... processing the transactions is what our sole purpose as miners, actually is.

Probably be better off to keep the connection counts down to 2-4 on bitcoind, and low connections on p2pool as well, so we're sending data to less people, allowing them to be sent, faster, and let the meganodes with the bandwidth to handle it, focus on the wide redistribution.

It does no good for a node with a residential-quality upstream, to pass along block data to 50 nodes, if it takes 10 seconds to do it.

The torrent community fights about this too, and the best nodes you find that are sending to you fast, are the ones who aren't trying to keep 500 connections open, giving each peer just a few kB/s at a time, making block propagation just drag out forever, much longer than it should, with extra wasted overhead.

Block propagation suffers the same way. Less really is sometimes more.
-- Smoov

+1

I was trying to indicate bandwidth limitations earlier.  I don't have any ports forwarded at all, to p2pool or bitcoind.  I get 8 in on p2pool, and 9 in on bitcoind (atm).  I'm also running namecoind and ixcoin for merged mining, I'd imagine they have 8 each as well.  No problems at all, and my stale rate is usually lower than the pool, sometimes significantly moreso.  When I start forwarding ports, that's when things get out of control.

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
maqifrnswa
Sr. Member
****
Offline Offline

Activity: 454


View Profile
May 05, 2013, 10:15:03 PM
 #5276

For what it's worth...

My node (http://ask.gxsnmp.org:9332/) has:
P2Pool - Peers   8 out, 29 in
Bitcoind:  "connections" : 51,
             "currentblocksize" : 66063,

Getwork Latency -Mean: 0.695s

And it seems to be doing fine.

Uptime: 11.257 days.

That's @ all the 'default' settings

Could it be better? Probably.. I'm just not really sure what to tweak to make it better, it seems to be working and I get payouts whenever a block is found.

you're doing fine, but your efficiency is not has high as someone with 0.003 s getwork latency.
Your expected DOA due to getblocktemplate latency: .7/10 = 7%
Someone with a 0 tx fee blocks (3ms) .003/10= 0.03%

assuming everything else equal: if your efficiency is 100%, theirs can be 107%.

They get 7% more profit than you by choosing to not process any transactions at all.

Thus Kano's argument that if the optimal p2pool setup is to process 0 tx, then p2pool (as it stands with standard bitcoind) hurts the network
mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
May 06, 2013, 01:46:09 AM
 #5277

Another example where things aren't working optimally:

I unpacked the latest git into a new folder, and fired it up.  A number of times as it was "processing xxx shares from [...]" it would take so long that when it finished, a bunch of errors would be thrown because things timed out.  I don't know Python very well at all, but it doesn't seem like p2pool is multithreaded.  I know multithreading isn't a trivial task.  Am I missing something, or is p2pool multithreaded and I'm just not seeing it?

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
daemondazz
Sr. Member
****
Offline Offline

Activity: 294



View Profile
May 06, 2013, 03:59:04 AM
 #5278

Is there any way of getting the per-miner stats from p2pool as JSON or even just a raw number? I want to set up Nagios to alert me if any of my miners stop working.

Something like:
http://cryptominer.org:9332/miner/<username>

Returning (hash rate and dead/stale):
516.12312 12.1451

Currently getting familiar with the code, so I can add this if not already in place.

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
Amph
Legendary
*
Offline Offline

Activity: 1358



View Profile
May 06, 2013, 06:51:36 AM
 #5279

it seems that the latency is better now, i get 0.06ms, before was 0.290 or something

when he say" lost 8 share due to connection lost" it's equal to= i lost 8 transiction?

mdude77
Legendary
*
Offline Offline

Activity: 1358


View Profile
May 06, 2013, 09:59:07 AM
 #5280

Is there any way of getting the per-miner stats from p2pool as JSON or even just a raw number? I want to set up Nagios to alert me if any of my miners stop working.

Something like:
http://cryptominer.org:9332/miner/<username>

Returning (hash rate and dead/stale):
516.12312 12.1451

Currently getting familiar with the code, so I can add this if not already in place.

I think http://localhost:9554/local_stats is as close as you can get. 

M

MMinerMonitor author, monitor/auto/schedule reboots/alerts/remote/MobileMiner for Ants and Spondoolies! Latest (5.2). MPoolMonitor author, monitor stats/workers for most pools, global BTC stats (current/nxt diff/USD val/hashrate/calc)! Latest (v4.2) 
Buyer beware of Bitmain hardware and services.
Pages: « 1 ... 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 [264] 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 ... 744 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!