Bitcoin Forum
December 09, 2016, 03:40:42 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 »  All
  Print  
Author Topic: P2Pool Server List  (Read 73757 times)
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
May 07, 2013, 12:50:51 PM
 #361

furball:  the latency is (from my experience) mostly determined by your maxblocksize.  set it to 5000 (so you can catch a few transactions that might have bloated fees)  and your latency should drop a lot.  less transactions = lower latency.   also less orphans

Thanks so much for the tip zvs, will definitely give that a go.
... and another p2pooler makes p2pool 100 times worse than using any of the top pools ...

He might well lose a bit of money with a maxblocksize so low but it's better than almost any other pool. If income is better on p2pool, the market decides to switch to p2pool.

So Kano, why don't you patch bitcoin for speeding up getblocktemplate to avoid this instead of harassing miners who don't have the knowledge to do it themselves?
No the problem is people using crap hardware and crap internet connections and then blaming bitcoin and setting their bitcoin setting 100x worse than the top pools.
Why don't the pools have this problem? Coz they don't use crap setups.
i.e. p2pool is way worse for bitcoin than the top pools ... for those doing this ... and everyone else also mining on p2pool is supporting those doing this by paying them in the share chain ...

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
1481298042
Hero Member
*
Offline Offline

Posts: 1481298042

View Profile Personal Message (Offline)

Ignore
1481298042
Reply with quote  #2

1481298042
Report to moderator
1481298042
Hero Member
*
Offline Offline

Posts: 1481298042

View Profile Personal Message (Offline)

Ignore
1481298042
Reply with quote  #2

1481298042
Report to moderator
1481298042
Hero Member
*
Offline Offline

Posts: 1481298042

View Profile Personal Message (Offline)

Ignore
1481298042
Reply with quote  #2

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

Posts: 1481298042

View Profile Personal Message (Offline)

Ignore
1481298042
Reply with quote  #2

1481298042
Report to moderator
rdponticelli
Sr. Member
****
Offline Offline

Activity: 326


Our highest capital is the Confidence we build.


View Profile
May 07, 2013, 05:18:32 PM
 #362

furball:  the latency is (from my experience) mostly determined by your maxblocksize.  set it to 5000 (so you can catch a few transactions that might have bloated fees)  and your latency should drop a lot.  less transactions = lower latency.   also less orphans

Thanks so much for the tip zvs, will definitely give that a go.
... and another p2pooler makes p2pool 100 times worse than using any of the top pools ...

Just for the record: It's not another, it's always the same one....
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 07, 2013, 07:59:18 PM
 #363

furball:  the latency is (from my experience) mostly determined by your maxblocksize.  set it to 5000 (so you can catch a few transactions that might have bloated fees)  and your latency should drop a lot.  less transactions = lower latency.   also less orphans

Thanks so much for the tip zvs, will definitely give that a go.
... and another p2pooler makes p2pool 100 times worse than using any of the top pools ...

He might well lose a bit of money with a maxblocksize so low but it's better than almost any other pool. If income is better on p2pool, the market decides to switch to p2pool.

So Kano, why don't you patch bitcoin for speeding up getblocktemplate to avoid this instead of harassing miners who don't have the knowledge to do it themselves?
No the problem is people using crap hardware and crap internet connections and then blaming bitcoin and setting their bitcoin setting 100x worse than the top pools.
Why don't the pools have this problem? Coz they don't use crap setups.

Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.

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
maqifrnswa
Sr. Member
****
Offline Offline

Activity: 454


View Profile
May 07, 2013, 08:43:50 PM
 #364

furball:  the latency is (from my experience) mostly determined by your maxblocksize.  set it to 5000 (so you can catch a few transactions that might have bloated fees)  and your latency should drop a lot.  less transactions = lower latency.   also less orphans

Thanks so much for the tip zvs, will definitely give that a go.
... and another p2pooler makes p2pool 100 times worse than using any of the top pools ...

He might well lose a bit of money with a maxblocksize so low but it's better than almost any other pool. If income is better on p2pool, the market decides to switch to p2pool.

So Kano, why don't you patch bitcoin for speeding up getblocktemplate to avoid this instead of harassing miners who don't have the knowledge to do it themselves?
No the problem is people using crap hardware and crap internet connections and then blaming bitcoin and setting their bitcoin setting 100x worse than the top pools.
Why don't the pools have this problem? Coz they don't use crap setups.

Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.

I agree, it has nothing to do with crap set us but simply the behavioural economics of  mining. Even someone with the best set-up in the world would do better with a zero transaction block than not.

Galvin has shown that for big pools it is more profitable to take more transactions (and transaction fees) at a risk of higher orphans than it would be to take zero transactions and lower orphans.

However, with p2pool, it is more profitable to make 0 transaction blocks and have lower sharechain orphans than it is to have more transactions in a block. This is because if I choose to include transactions in a block, I don't see the profit since it is shared amongst the pool. If I choose to make 0 transaction blocks, I see an increase in profit but the rest of the pool sees a drop.

This assumes extreme selfishness (ignoring effects on the larger bitcoin network), which implies optimal efficiency.
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
May 07, 2013, 10:43:23 PM
 #365

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.
What has that to do with orphans?
The actual risk of having an orphan is only your bitcoind.
p2pool sends the blocks directly to bitcoind - that's why p2pool doesn't throw away valid blocks when they are rejected by the share chain.

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
Smoovious
Hero Member
*****
Offline Offline

Activity: 504

Scattering my bits around the net since 1980


View Profile
May 07, 2013, 11:20:29 PM
 #366

:facepalm:

and people wonder why we have a backlog of transactions...

it is because of people NOT PROCESSING TRANSACTIONS LIKE THEY'RE SUPPOSED TO BE DOING!!!

they're getting paid to do a job they're not doing...

-- Smoov
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 07, 2013, 11:41:21 PM
 #367

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.
What has that to do with orphans?

If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool.

The actual risk of having an orphan is only your bitcoind.

Not relevant to the problem some p2pool miners try to solve by lowering their block size.

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
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 07, 2013, 11:42:33 PM
 #368

:facepalm:

and people wonder why we have a backlog of transactions...

it is because of people NOT PROCESSING TRANSACTIONS LIKE THEY'RE SUPPOSED TO BE DOING!!!

they're getting paid to do a job they're not doing...

Actually they don't or Kano wouldn't throw a fit each time he reads about yet another p2pool miner lowering the max block size.

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
kano
Legendary
*
Offline Offline

Activity: 1932


Linux since 1997 RedHat 4


View Profile
May 08, 2013, 03:06:11 AM
 #369

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.
What has that to do with orphans?

If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool.

The actual risk of having an orphan is only your bitcoind.

Not relevant to the problem some p2pool miners try to solve by lowering their block size.
So what you are trying to tell me is that it's not orphan blocks that you are trying to reduce but orphan shares in the p2pool share-chain?
Seriously?
It's even worse?
You are trying to increase your share count at the detriment of the bitcoin network?

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
maqifrnswa
Sr. Member
****
Offline Offline

Activity: 454


View Profile
May 08, 2013, 01:16:02 PM
 #370

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.
What has that to do with orphans?

If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool.

The actual risk of having an orphan is only your bitcoind.

Not relevant to the problem some p2pool miners try to solve by lowering their block size.
So what you are trying to tell me is that it's not orphan blocks that you are trying to reduce but orphan shares in the p2pool share-chain?
Seriously?
It's even worse?
You are trying to increase your share count at the detriment of the bitcoin network?

exactly - this is the problem. Like I just posted above, there is no financial incentive for a single p2pool user to include transactions in their p2pool share.
It's game theory: if everyone includes transactions, everyone wins. But if one person chooses to make zero transaction p2pool shares, and everyone else chooses to make normal shares - the zero transaction share person wins.

EDIT: this is selfish, but it is the way it is. Pools do have a financial incentive to include transactions since transaction fees offset the increase in orphan rate. p2pool nodes, however, do not see the transaction fees they include (but only a tiny fraction of the fees), so there is more of an incentive to have lower latency than higher transaction fees.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 08, 2013, 01:57:07 PM
 #371

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.
What has that to do with orphans?

If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool.

The actual risk of having an orphan is only your bitcoind.

Not relevant to the problem some p2pool miners try to solve by lowering their block size.
So what you are trying to tell me is that it's not orphan blocks that you are trying to reduce but orphan shares in the p2pool share-chain?

Yes, although I don't use an extremely low blocksize: it's 100 000 in my configuration instead of 5 000 reported earlier because this is where bitcoind slows down enough for me to impact my mining efficiency noticeably.

Seriously?
It's even worse?
You are trying to increase your share count at the detriment of the bitcoin network?

Mining is a business for some, not a charity and I don't see any problem with that (in fact I think it's probably good and decentralizing mining power by using p2pool in the process is even better).

Don't remember the time before bitcoin 0.8 when some pools started reducing their own max blocksize or ignoring low fee transactions to deal with an orphans problem? It's the same problem on a different scale and the solution is the same: speed up the bitcoin RPC interface.

Jumping on anybody reducing the max blocksize accusing him/her of antisocial behaviour is a waste of time, most will simply ignore you.
The only productive action is studying why the software takes more than 0.01s transmitting 100kB of data locally and bog down the CPU in the process (that's not like p2pool users run their nodes on 8086 CPUs...).

If you really think that ignoring what's probably a performance bug to pester users go ahead and waste your time: users always find ways to circumvent software limitations. That's real life, deal with it.

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
zvs
Legendary
*
Offline Offline

Activity: 1386



View Profile WWW
May 08, 2013, 08:47:14 PM
 #372

...
Now you are just playing dumb. Normal pools have much more tolerance for bitcoind latencies: their target is a 10mn window: a latency of ~0.2-0.5s instead of 0.01s during which orphan blocks can be produced is nothing for them. P2Pool is 60 times faster with a target of 10s: orphan shares produced for 0.2-0.5s instead of 0.01s matters for the miners.

Bitcoind getblocktemplate interface slows down with the number of transactions to include in a block, period. This is only an implementation choice, period. Arguing against these facts is just ignoring reality and making you look like a fool.
What has that to do with orphans?

If you want to put the blame on p2pool users instead of the slow bitcoin RPC interface you might want to learn what an orphaned share in P2Pool is and what its consequences are. You can read the guide in my signature to understand this and related information about P2Pool.

The actual risk of having an orphan is only your bitcoind.

Not relevant to the problem some p2pool miners try to solve by lowering their block size.
So what you are trying to tell me is that it's not orphan blocks that you are trying to reduce but orphan shares in the p2pool share-chain?
Seriously?
It's even worse?
You are trying to increase your share count at the detriment of the bitcoin network?

exactly - this is the problem. Like I just posted above, there is no financial incentive for a single p2pool user to include transactions in their p2pool share.
It's game theory: if everyone includes transactions, everyone wins. But if one person chooses to make zero transaction p2pool shares, and everyone else chooses to make normal shares - the zero transaction share person wins.

EDIT: this is selfish, but it is the way it is. Pools do have a financial incentive to include transactions since transaction fees offset the increase in orphan rate. p2pool nodes, however, do not see the transaction fees they include (but only a tiny fraction of the fees), so there is more of an incentive to have lower latency than higher transaction fees.

that's not true, either.   people with better systems win out in the 'everyone includes every transaction' theoretical.

i'll throw this out there:  people saying to include all these transactions are being greedy.  you want to increase your own "efficiency" rate at the expense of people with slower systems.  for someone to have >100%, someone else has to have <100%

Dacentec, best deals for US dedicated servers. They regularly restock $20-$25 Opterons with 8-16GB RAM & 2x1-2TB HDD's (ofc, usually lots of other good stuff to choose from).  I did a Serverbear benchmark of one of my $20/mo Opteron (June last year), it's here.  Have had about a half dozen different servers with Dacentec, & none have failed to sustain at least 40MB/s (burst higher). My favorite is a 12-month rent-to-own ZT Systems 2XL5520 16GB 2x2TB SATA for $40/month (got lucky with the 'off-brand', haven't seen a RTO 2xL5520 for under $50/mo since -- at least for monthly contracts).  wholesaleinternet.com has some ancient 2-core intel CPUs @ $10/mo sometimes (I got an Intel Core 2 6300 @ 1.86GHz, with a 250GB HDD with 46000 hours on it, LOL. $20 @ Dacentec is much better, if you can grab one). joesdatacenter.com (same location as Wholesale Internet) also occasionally has specials (or if you don't want to wait, it has an AMD Opteron 170 @ $16/mo).
maqifrnswa
Sr. Member
****
Offline Offline

Activity: 454


View Profile
May 08, 2013, 09:59:19 PM
 #373


that's not true, either.   people with better systems win out in the 'everyone includes every transaction' theoretical.

i'll throw this out there:  people saying to include all these transactions are being greedy.  you want to increase your own "efficiency" rate at the expense of people with slower systems.  for someone to have >100%, someone else has to have <100%


In the presence of a health p2pool network strength, the theoretical optimal strategy of a p2pool node operator is to have the have the best system, lowest latency, you can get. That includes:
1) have a top notch fast system
2) limit transactions

Following (2) to its logical conclusion (i.e. zero transaction blocks) is bad for the network. Following (1) isn't necessarily bad for the network (unless you say it discourages smaller p2pool nodes, but they can just mine the bigger/faster public ones if it gets bad). However, I think there is some happy medium where (2) could be beneficial for the bitcoin network. In exchange for adding the hashrate of many small p2pool miners you get some smaller blocks. That is could be an acceptable trade-off. Going to zero-transactions, however, is not acceptable.

My point is that the optimal p2pool strategy is bad for the bitcoin network. Is there something that can be done? Force p2pool shares to contain a certain number of transactions? A number small enough that doesn't kill small pool latency but big enough to help the network?
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 08, 2013, 10:37:39 PM
 #374

Is there something that can be done? Force p2pool shares to contain a certain number of transactions? A number small enough that doesn't kill small pool latency but big enough to help the network?

See my previous posts...

If nothing can be done to speed up bitcoind which would clearly be the better solution as it would benefit everyone, there are at least several relatively complicated approach p2pool could use:

  • allow a share to "adopt" an orphan share (ie: reference two shares instead of one), which would greatly reduce latency impacts on the miner's efficiency, this has often been discussed but never been implemented, probably quite complex
  • for each miner, compute the fees associated with each share and distribute fees proportionately to all submitted shares (unlike the block reward itself which would remain in proportion to the number*complexity of shares submitted). I'm not sure if it's doable in a secure way, I'm not familiar enough with the sharechain implementation, but if it's doable it's probably not trivial to get right.
  • the simplest would be to punish shares with fewer transactions when a fork happens in the sharechain by always building on the share with the largest number of transactions but I'm not sure it would be enough

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
zvs
Legendary
*
Offline Offline

Activity: 1386



View Profile WWW
May 09, 2013, 02:37:58 AM
 #375

#2, not sure.  Also I don't think that'd be incentive enough to risk p2pool orphans with.

#1 and #3, I think would cause problems for people using p2pool with high latency. 

The current reward for solving a share is .5%, right?  So .125 (+ some small bit from transaction fees)?  Average block has maybe .2 to .5 in transaction fees?  I still just think changing the reward to the transactions is the best way to solve the problem.

... and it can be changed if and when transaction fees become a more significant portion of blocks (when reward drops to 12.5, or some other event)

I don't see why ppl complain about that

Dacentec, best deals for US dedicated servers. They regularly restock $20-$25 Opterons with 8-16GB RAM & 2x1-2TB HDD's (ofc, usually lots of other good stuff to choose from).  I did a Serverbear benchmark of one of my $20/mo Opteron (June last year), it's here.  Have had about a half dozen different servers with Dacentec, & none have failed to sustain at least 40MB/s (burst higher). My favorite is a 12-month rent-to-own ZT Systems 2XL5520 16GB 2x2TB SATA for $40/month (got lucky with the 'off-brand', haven't seen a RTO 2xL5520 for under $50/mo since -- at least for monthly contracts).  wholesaleinternet.com has some ancient 2-core intel CPUs @ $10/mo sometimes (I got an Intel Core 2 6300 @ 1.86GHz, with a 250GB HDD with 46000 hours on it, LOL. $20 @ Dacentec is much better, if you can grab one). joesdatacenter.com (same location as Wholesale Internet) also occasionally has specials (or if you don't want to wait, it has an AMD Opteron 170 @ $16/mo).
gyverlb
Hero Member
*****
Offline Offline

Activity: 896



View Profile
May 09, 2013, 02:53:28 AM
 #376

#2, not sure.  Also I don't think that'd be incentive enough to risk p2pool orphans with.

#1 and #3, I think would cause problems for people using p2pool with high latency.

I don't see why #1 would, it would allow a window averaging 10s after a share to submit a share based on the previous one. Unless your latency is several seconds larger than the other miners you shouldn't be penalized by your latency in any noticeable way.

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
chances
Newbie
*
Offline Offline

Activity: 14


View Profile
May 09, 2013, 03:04:26 AM
 #377

Hey all,
Just opening up our new p2pool to everyone. My buddy and I have been testing it and everything is working great.
There is 0% fee at the moment and only LTC mining.
We're working on adding many more scrypt coins to the server in the very near future.
The server is hosted on the east coast of Australia in a data center, connection and ping for Aussies should be ideal!

Address is - p2pool.net.au

Brisbane::Australia::http://p2pool.net.au:9327/::0%::LTC::p2pool.net.au::chances

Username is your wallet address and password is anything.

By the end of next week we should have some more coins available and a frontpage for all the pools.

Any suggestions would be appreciated Wink
Smoovious
Hero Member
*****
Offline Offline

Activity: 504

Scattering my bits around the net since 1980


View Profile
May 09, 2013, 07:29:44 PM
 #378

(deleted response, as it was unclear if the fees to what I was replying to, were also going to be paid out PPLNS or Proportional, and if Proportional, then that negated the assumption of PPLNS I was making)

-- Smoov


nesociety
Newbie
*
Offline Offline

Activity: 8



View Profile WWW
May 11, 2013, 08:23:30 PM
 #379

Montreal::Quebec::Canada::http://mine-a-coin.com:9327/::1%::LTC::Mine-a-coin.com::NS
PatMan
Hero Member
*****
Offline Offline

Activity: 924


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


View Profile WWW
May 12, 2013, 07:51:14 PM
 #380

Montreal::Quebec::Canada::http://mine-a-coin.com:9327/::1%::LTC::Mine-a-coin.com::NS

Cool avatar my man - Pans Labyrinth - a classic  Grin

"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/
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 »  All
  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!