Bitcoin Forum
December 03, 2016, 01:46:47 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 ... 744 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2029004 times)
daemondazz
Sr. Member
****
Offline Offline

Activity: 280



View Profile
July 01, 2013, 04:14:20 AM
 #5941

The USB version doesn't run standalone.

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
1480772807
Hero Member
*
Offline Offline

Posts: 1480772807

View Profile Personal Message (Offline)

Ignore
1480772807
Reply with quote  #2

1480772807
Report to moderator
1480772807
Hero Member
*
Offline Offline

Posts: 1480772807

View Profile Personal Message (Offline)

Ignore
1480772807
Reply with quote  #2

1480772807
Report to moderator
1480772807
Hero Member
*
Offline Offline

Posts: 1480772807

View Profile Personal Message (Offline)

Ignore
1480772807
Reply with quote  #2

1480772807
Report to moderator
There are several different types of Bitcoin clients. Server-assisted clients like blockchain.info rely on centralized servers to do their network verification for them. Although the server can't steal the client's bitcoins directly, it can easily execute double-spending-style attacks against the client.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Krellan
Member
**
Offline Offline

Activity: 105


View Profile
July 01, 2013, 06:01:14 AM
 #5942

* Delay payout calculation 1 share so that payouts can be calculated ahead of time, reducing latency between a new share being received and work being distributed to miners

Good idea to precalculate the blocks that will be worked on, to reduce latency.  However, curious how this works.  If blocks are now precalculated, delayed by 1 share, then where will the most recent winning share be stored in the sharechain?  I thought it worked now by each miner creating a new block containing their payout address, and trying to solve that, until finding a winning solution, at which point the block becomes a valid share in the sharechain.  If this isn't the case, then where will the payout addresses be stored now?  I hope this doesn't open up an opportunity for a miner to cheat.  Or, do I have it all wrong here?  Thanks!


1JUZr4TZ5zuB4WdEv4mrhZMaM7yttpJvLG Smiley
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
July 01, 2013, 06:03:37 AM
 #5943

* Delay payout calculation 1 share so that payouts can be calculated ahead of time, reducing latency between a new share being received and work being distributed to miners

Good idea to precalculate the blocks that will be worked on, to reduce latency.  However, curious how this works.  If blocks are now precalculated, delayed by 1 share, then where will the most recent winning share be stored in the sharechain?  I thought it worked now by each miner creating a new block containing their payout address, and trying to solve that, until finding a winning solution, at which point the block becomes a valid share in the sharechain.  If this isn't the case, then where will the payout addresses be stored now?  I hope this doesn't open up an opportunity for a miner to cheat.  Or, do I have it all wrong here?  Thanks!

The sharechain has some P2Pool-specific data (including the winner's payout address) within each share, along with everything needed to compute the current block being mined. So no, this is a very safe change.

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Krellan
Member
**
Offline Offline

Activity: 105


View Profile
July 01, 2013, 06:30:08 AM
 #5944

I'm not sure how Erupter blades behave with P2Pool, please give us a quick report when your reach 25 total shares then 50 (the more you have the more we will know for sure how your setup behaves).

Up to 50 shares now!

Not exactly Nasty, but still chugging along nicely, for only a single Erupter.

I increased the number of outgoing connections to the maximum allowed of 10, and that seemed to have helped a lot.  Having more network connections helps keep my node "in the loop" so that it is not the last to find out about the newest blocks.

P2Pool webpage:

Code:
Node uptime: 8.525 days Peers: 10 out, 10 in
Local rate: 344MH/s (0.0% DOA) Expected time to share: 4.97 hours
Shares: 52 total (8 orphaned, 0 dead) Efficiency: 102.5%

P2Pool console dump:

Code:
2013-06-30 23:23:42.542263 P2Pool: 17325 shares in chain (17329 verified/17329 total) Peers: 20 (10 incoming)
2013-06-30 23:23:42.542394  Local: 379MH/s in last 10.0 minutes Local dead on arrival: ~0.0% (0-7%) Expected time to share: 4.6 hours
2013-06-30 23:23:42.542474  Shares: 52 (8 orphan, 0 dead) Stale rate: ~15.4% (8-28%) Efficiency: ~102.5% (87-112%) Current payout: 0.0137 BTC
2013-06-30 23:23:42.542560  Pool: 774GH/s Stale rate: 17.4% Expected time to block: 1.4 days

BFGMiner console header text:

Code:
--------------------------------------------------------------------------------
 5s: 87.3 avg:335.9 u:326.3 Mh/s | A:55990 R:1012+0(1.8%) HW:507
 ST: 1  GF: 0  NB: 1397  AS: 0  RF: 0  E: 0.06  U:4.6/m  BS:274k
 Connected to localhost diff 1 with stratum as user P2Pool
 Block: ...4592a33c #244201  Diff:21.3M (152.7Th/s)  Started: [23:25:51]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 169.5/335.9/326.3Mh/s | A:55990 R:1012+0(1.8%) HW:507
--------------------------------------------------------------------------------

BFGMiner pool information:

Code:
Queued work requests: 78282
 Share submissions: 56993
 Accepted shares: 55981
 Rejected shares: 1012 + 0 stale (0.02%)
 Accepted difficulty shares: 55981
 Rejected difficulty shares: 1012
 Efficiency (accepted * difficulty / 2 KB): 0.06
 Stale submissions discarded due to new blocks: 0
 Unable to get work from server occasions: 0
 Submitting work remotely delay occasions: 0

It's been nicely stable.  I need to upgrade Bitcoin to 0.8.3 (from 0.8.2) and BFGMiner to 3.1.1 (from 3.1.0), so will restart it soon for that.

1JUZr4TZ5zuB4WdEv4mrhZMaM7yttpJvLG Smiley
baloo_kiev
Sr. Member
****
Offline Offline

Activity: 476


View Profile
July 01, 2013, 07:54:22 AM
 #5945

Why would they fix this only in the usb version?

Usb version is controlled by third-party mining software like cgminer and others. Blades are controlled by closed-source software written (poorly!) by some AM's partner company. I guess the only thing can be done here is waiting until AM fixes its dumb software for its smart chips.

PGP: 6EC48BA7
Welcome to my p2pool: BTC
daemondazz
Sr. Member
****
Offline Offline

Activity: 280



View Profile
July 01, 2013, 08:26:20 AM
 #5946

I would not be surprised if one of the biggest changes to their "next generation" blade will be the firmware. The first version of the blade's I think really were the quick and dirty to get them going. Version 2 will be the time to fix the problems.

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
centove
Full Member
***
Offline Offline

Activity: 194


View Profile
July 01, 2013, 10:17:01 AM
 #5947

Is it normal for a node with 2GH/s?
No. You just step on memory leak. Git pull and restart node.
Updated and restarted, looks better now: 300 MB of memory used.
Does it increases with the hashrate or not?
It seems to be correlated to the # of peers/workers connected.

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

Activity: 1320


Don`t panic! Organize!


View Profile
July 01, 2013, 12:43:44 PM
 #5948

From my observation it is some leak in tcp/ip twisted/zope connectors.
Lak occurs when there is some switching in connected nodes and connected miners.
Probably something is "hanging" connections buffers that are spawned in next created connections and making cascade eat of ram.
Found some articles about that. Looks like connections that are not closed "directly" are moved to new instance by default and then even after connection finally drops memory is "eaten" and GC is not freeing it.

1Rav3nkMayCijuhzcYemMiPYsvcaiwHni  Bitcoin stuff on my OneDrive
My RPC CoinControl for any coin https://bitcointalk.org/index.php?topic=929954
My SatoshDice bot https://bitcointalk.org/index.php?topic=897685
Boing7898
Sr. Member
****
Offline Offline

Activity: 266


View Profile
July 01, 2013, 04:07:27 PM
 #5949

After updating to the last git, I'm starting to get a lot of "Couldn't bind: 24: too many open files"
What's the problem?
I have to restart p2pool each time it happens..

Also wtf, is this normal? That looks like a Litecoin address to me.. I'm hosting a Bitcoin pool.

2013-07-01 12:15:46.267753 Worker Lcn8gbjgv3L9V3WQMEgxxRBrbmEbCVNCF3 submitted share with hash > target:
2013-07-01 12:15:46.267822     Hash:   3509665dafb744bfcfcc932d7cf29052e51c4afe763165b4e3e1f80ec85286a1
2013-07-01 12:15:46.268389     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Ohai.
GRC: FtWgehaapGH5cKSmMPEH91sVzxLUioNZ3s
forrestv
Hero Member
*****
Offline Offline

Activity: 510


View Profile
July 01, 2013, 04:16:57 PM
 #5950

After updating to the last git, I'm starting to get a lot of "Couldn't bind: 24: too many open files"
What's the problem?
I have to restart p2pool each time it happens..

Also wtf, is this normal? That looks like a Litecoin address to me.. I'm hosting a Bitcoin pool.

2013-07-01 12:15:46.267753 Worker Lcn8gbjgv3L9V3WQMEgxxRBrbmEbCVNCF3 submitted share with hash > target:
2013-07-01 12:15:46.267822     Hash:   3509665dafb744bfcfcc932d7cf29052e51c4afe763165b4e3e1f80ec85286a1
2013-07-01 12:15:46.268389     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff


Can you pastebin one of the "too many open files" tracebacks?

And that error is just someone using a Litecoin miner on your pool...

1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
Boing7898
Sr. Member
****
Offline Offline

Activity: 266


View Profile
July 01, 2013, 05:23:03 PM
 #5951

After updating to the last git, I'm starting to get a lot of "Couldn't bind: 24: too many open files"
What's the problem?
I have to restart p2pool each time it happens..

Also wtf, is this normal? That looks like a Litecoin address to me.. I'm hosting a Bitcoin pool.

2013-07-01 12:15:46.267753 Worker Lcn8gbjgv3L9V3WQMEgxxRBrbmEbCVNCF3 submitted share with hash > target:
2013-07-01 12:15:46.267822     Hash:   3509665dafb744bfcfcc932d7cf29052e51c4afe763165b4e3e1f80ec85286a1
2013-07-01 12:15:46.268389     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff


Can you pastebin one of the "too many open files" tracebacks?

And that error is just someone using a Litecoin miner on your pool...
Here it is: http://pastebin.com/iyPupJnp

Oh.. is there a way to block Litecoin addresses/miners? It's just spamming the console.

Ohai.
GRC: FtWgehaapGH5cKSmMPEH91sVzxLUioNZ3s
freshzive
Sr. Member
****
Offline Offline

Activity: 447


View Profile
July 02, 2013, 02:23:02 AM
 #5952

so does p2pool work properly with bitcoind 0.8.3? wanted to double check before i upgrade

quote author=forrestv link=topic=18313.msg2562076#msg2562076 date=1372036660]
In the next couple days, I'm going to release a hard-forking change to P2Pool that will make the following changes

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)
[/quote]

also...this hasn't been done yet, right?

baloo_kiev
Sr. Member
****
Offline Offline

Activity: 476


View Profile
July 02, 2013, 04:20:55 AM
 #5953

Bitcoin network
* Increase SHARE_PERIOD (average time between shares) from 10 seconds to 30 seconds, in order to make it more fair for high-latency miners (read: ASICs)

also...this hasn't been done yet, right?

I think it has been done but switch to new share version will occur when most hashrate upgrades. P2pool graphs show only 1% new version now.

PGP: 6EC48BA7
Welcome to my p2pool: BTC
baloo_kiev
Sr. Member
****
Offline Offline

Activity: 476


View Profile
July 02, 2013, 09:34:11 AM
 #5954

Another possible solution to AMblade-p2pool issue here!

Blade owners could just fork their own p2pool. The only 4 lines of code which need to be changed are share period, p2pool network identifier (prefix), bootstrap nodes, and optionally chain length. As blade's "effective latency" is about 6 seconds, reasonable values for share period are 5 or 10 minutes.

The hardest part is involving miners. You need about 100 blades in total to reach mean rate of 1 block per day. At this hashrate, 1 blade's expected time to share will be 8 and 17 hours for 5 and 10 minute share period correspondingly (or even less if multiple-blade miners adjust their difficulty properly). Maybe someone should make announcements here and in AM blade discussion threads to get feedback and estimate how many blades will support this.

PGP: 6EC48BA7
Welcome to my p2pool: BTC
Boing7898
Sr. Member
****
Offline Offline

Activity: 266


View Profile
July 02, 2013, 09:40:25 AM
 #5955

After updating to the last git, I'm starting to get a lot of "Couldn't bind: 24: too many open files"
What's the problem?
I have to restart p2pool each time it happens..

Also wtf, is this normal? That looks like a Litecoin address to me.. I'm hosting a Bitcoin pool.

2013-07-01 12:15:46.267753 Worker Lcn8gbjgv3L9V3WQMEgxxRBrbmEbCVNCF3 submitted share with hash > target:
2013-07-01 12:15:46.267822     Hash:   3509665dafb744bfcfcc932d7cf29052e51c4afe763165b4e3e1f80ec85286a1
2013-07-01 12:15:46.268389     Target: ffffffffffffffffffffffffffffffffffffffffffffffffffffffff


Can you pastebin one of the "too many open files" tracebacks?

And that error is just someone using a Litecoin miner on your pool...
Here it is: http://pastebin.com/iyPupJnp

Oh.. is there a way to block Litecoin addresses/miners? It's just spamming the console.

Ugh.. I keep getting this error each 1.5 hours.. making me restart p2pool each hour or so.

Ohai.
GRC: FtWgehaapGH5cKSmMPEH91sVzxLUioNZ3s
svirus
Member
**
Offline Offline

Activity: 72


View Profile WWW
July 02, 2013, 12:27:23 PM
 #5956

in command line:
ulimit -n 8192
and run p2pool

and check later if errors show.

Open files in linux-like system is also opened connections.


Boing7898
Sr. Member
****
Offline Offline

Activity: 266


View Profile
July 02, 2013, 12:30:18 PM
 #5957

in command line:
ulimit -n 8192
and run p2pool

and check later if errors show.

Open files in linux-like system is also opened connections.


I edited /etc/security/limits.conf with limits of 10000 and I've been running p2pool for nearly 3 hours without a crash.
Weird though, because before I upgraded p2pool it was working, even with the limit set at 1024. Maybe it's because more users joined my pool?
Who knows.  Huh

Ohai.
GRC: FtWgehaapGH5cKSmMPEH91sVzxLUioNZ3s
daemondazz
Sr. Member
****
Offline Offline

Activity: 280



View Profile
July 02, 2013, 01:00:41 PM
 #5958

Oh.. is there a way to block Litecoin addresses/miners? It's just spamming the console.

I think it would actually be a good idea to block all users that are not a valid address for the network except for whitelisted exceptions (eg, my miners are xxx.worker1, xxx.worker2, etc). This way someone can't get upset if they use an invalid username and hence donate their hashrate to their host.

This would mean bitcoin addresses on bitcoin nodes, litecoin addresses on litecoin nodes, etc. Should be an easy enough thing to add using the 'validateaddress' RPC command.

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
centove
Full Member
***
Offline Offline

Activity: 194


View Profile
July 02, 2013, 01:19:10 PM
 #5959

in command line:
ulimit -n 8192
and run p2pool

and check later if errors show.

Open files in linux-like system is also opened connections.


I edited /etc/security/limits.conf with limits of 10000 and I've been running p2pool for nearly 3 hours without a crash.
Weird though, because before I upgraded p2pool it was working, even with the limit set at 1024. Maybe it's because more users joined my pool?
Who knows.  Huh
Code:
$ lsof -c python | wc -l

On the node will tell you how many files p2pool has opened.

Give me Btc: 1BRkf5bwSVdGCyvu4SyYBiJjEjbNiAQoYd Mine on my node: http://ask.gxsnmp.org:9332/
Boing7898
Sr. Member
****
Offline Offline

Activity: 266


View Profile
July 02, 2013, 02:11:18 PM
 #5960

in command line:
ulimit -n 8192
and run p2pool

and check later if errors show.

Open files in linux-like system is also opened connections.


I edited /etc/security/limits.conf with limits of 10000 and I've been running p2pool for nearly 3 hours without a crash.
Weird though, because before I upgraded p2pool it was working, even with the limit set at 1024. Maybe it's because more users joined my pool?
Who knows.  Huh
Code:
$ lsof -c python | wc -l

On the node will tell you how many files p2pool has opened.
1494 files, wow.
That's why it was crashing, the limit was at 1024 before.
Thanks for the tip!

Ohai.
GRC: FtWgehaapGH5cKSmMPEH91sVzxLUioNZ3s
Pages: « 1 ... 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 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 ... 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!