why isn't p2pool more popular than it is?

[eleuthria]

With 500MHs/s your average reward should be around 0.04BTC per block found. You can pack several inputs in a transaction with a 0.0005 BTC fee so your loss from fees is less than 1% when you use p2pool mined coins.

So if the alternative is a pool with more than 1% fees you're automatically better off with p2pool.

Currently the fees earned by block mining are around 1-2%, so if the alternatives don't pay you network fees, that's more you lose vs p2pool.
And lastly, my 2 months performance on p2pool is 107,5% vs expected 100%PPS so p2pool seems to have a higher than average reward than most pools. I didn't even count some small downtimes in that period so it's a low estimate. This matches what http://p2pool.info/ reports: constant higher luck.

One explanation may be that p2pool is by its nature better connected to the bitcoin network than most pools: all P2Pool nodes quickly broadcast a p2pool found block on the bitcoin network which may lower orphan rate.

p2pool's luck is just that:  luck.  The smaller the pool size, the more varied that is.  90 days is hardly enough time for measuring it given it makes up less than 3% of the network.  For almost a year the p2pool luck was abysmal and anybody using it would've been better off with any decent sized pool.

That's a very helpful explanation.

So at 4 Bit Cents per block my 13 BTC example would have 325 inputs.  Would that really be only a 0.0005 BTC fee?

Does anyone have a real world example?
Thanks,
Sam

It's hard to give a real world example, but you'll have a very hard time ever sending 13 BTC with 325 different inputs.  In that kind of situation, you'd be better off sending your inputs into a separate wallet with larger chunks (keeping the transactions small while doing so).  Do that a few times, then wait for those to mature, then use those to make even larger chunks (keeping transaction size small while doing so) again once they've matured enough to not require a fee.  Note:  This will not work if your initial inputs aren't big/old enough to avoid transaction fees.  Each 0.04 input would have to be 25 days (I think) old prior to being merged.

The "bag of pennies" scenario is a significant problem for small miners on p2pool.  Not so bad for larger ones.  But the larger p2pool becomes, the worse this problem is.  It's a hidden fee for using p2pool.  You get your money faster than some pools, though there are many pools that don't require waiting for blocks to mature (or PPS where you don't even have to wait for a block).  However, the larger p2pool becomes, the more frequently you'll be forced to pay txfees when spending coins.



p2pool's concept is great, but the payment method and share chain prevent it from becoming a major "pool".  Unless it gets turned into a series of supernodes which people mine through, which would end up being worse than the current pool system due to high stale rates using a remote node that has longpolls every 10 seconds.

[mdude77]

With 500MHs/s your average reward should be around 0.04BTC per block found. You can pack several inputs in a transaction with a 0.0005 BTC fee so your loss from fees is less than 1% when you use p2pool mined coins.

So if the alternative is a pool with more than 1% fees you're automatically better off with p2pool.

Currently the fees earned by block mining are around 1-2%, so if the alternatives don't pay you network fees, that's more you lose vs p2pool.
And lastly, my 2 months performance on p2pool is 107,5% vs expected 100%PPS so p2pool seems to have a higher than average reward than most pools. I didn't even count some small downtimes in that period so it's a low estimate. This matches what http://p2pool.info/ reports: constant higher luck.

One explanation may be that p2pool is by its nature better connected to the bitcoin network than most pools: all P2Pool nodes quickly broadcast a p2pool found block on the bitcoin network which may lower orphan rate.

p2pool's luck is just that:  luck.  The smaller the pool size, the more varied that is.  90 days is hardly enough time for measuring it given it makes up less than 3% of the network.  For almost a year the p2pool luck was abysmal and anybody using it would've been better off with any decent sized pool.

What you say is true.  However, for the last 90+ days, the 90 day history has been > 105%.  Yes, for at least the last 180 days it's been better than average.

M

[TechCF]

Another piece of software to set up and maintain on my different platforms. I think the increased earnings will go to waste with the downtime involved when upgrading. So I'm sticking with a regular stable pool with port 80 support, and using a backup pool in case of netsplits or attacks...

[mdude77]

Another piece of software to set up and maintain on my different platforms. I think the increased earnings will go to waste with the downtime involved when upgrading. So I'm sticking with a regular stable pool with port 80 support, and using a backup pool in case of netsplits or attacks...

From what I've seen on the threads for the other pools.. none of them are fully stable.

M

[khal]

It's hard to give a real world example, but you'll have a very hard time ever sending 13 BTC with 325 different inputs.  In that kind of situation, you'd be better off sending your inputs into a separate wallet with larger chunks (keeping the transactions small while doing so).  Do that a few times, then wait for those to mature, then use those to make even larger chunks (keeping transaction size small while doing so) again once they've matured enough to not require a fee.  Note:  This will not work if your initial inputs aren't big/old enough to avoid transaction fees.  Each 0.04 input would have to be 25 days (I think) old prior to being merged.

The "bag of pennies" scenario is a significant problem for small miners on p2pool.  Not so bad for larger ones.  But the larger p2pool becomes, the worse this problem is.  It's a hidden fee for using p2pool.  You get your money faster than some pools, though there are many pools that don't require waiting for blocks to mature (or PPS where you don't even have to wait for a block).  However, the larger p2pool becomes, the more frequently you'll be forced to pay txfees when spending coins.

Maybe we can propose a change to the fee rules that put less fees on transactions that reduce the number of unspent tx. With bitcoin 0.8, it'll be even more important (bitcoin nodes can download only a list of unspent tx, which reduces the blockchain size to something like 200MB).

[os2sam]

Maybe we can propose a change to the fee rules that put less fees on transactions that reduce the number of unspent tx.

Transaction fees are a very important part of Bitcoin, so I would NOT advocate mucking with it.

I don't know what you mean by "unspent tx".  Whats your definition of an unspent transaction?
Sam

Edit: forgot one little word

[Luke-Jr]

With bitcoin 0.8, it'll be even more important (bitcoin nodes can download only a list of unspent tx, which reduces the blockchain size to something like 200MB).

This is not a planned feature of 0.8. While it will only use an unspent tx database, it still needs to download (and at present, store) the full blockchain. Just FYI.

[mdude77]

It's hard to give a real world example, but you'll have a very hard time ever sending 13 BTC with 325 different inputs.  In that kind of situation, you'd be better off sending your inputs into a separate wallet with larger chunks (keeping the transactions small while doing so).  Do that a few times, then wait for those to mature, then use those to make even larger chunks (keeping transaction size small while doing so) again once they've matured enough to not require a fee.  Note:  This will not work if your initial inputs aren't big/old enough to avoid transaction fees.  Each 0.04 input would have to be 25 days (I think) old prior to being merged.

The "bag of pennies" scenario is a significant problem for small miners on p2pool.  Not so bad for larger ones.  But the larger p2pool becomes, the worse this problem is.  It's a hidden fee for using p2pool.  You get your money faster than some pools, though there are many pools that don't require waiting for blocks to mature (or PPS where you don't even have to wait for a block).  However, the larger p2pool becomes, the more frequently you'll be forced to pay txfees when spending coins.



p2pool's concept is great, but the payment method and share chain prevent it from becoming a major "pool".  Unless it gets turned into a series of supernodes which people mine through, which would end up being worse than the current pool system due to high stale rates using a remote node that has longpolls every 10 seconds.

Hmm.  If transaction fees are required, why does the client default to not providing any?  I know more than once I've accidentally sent a payment, all from p2pool, without a transaction fee because that setting wasn't on.  Never had a problem with them going through quickly or getting confirmations either.

Not that I'm advocating sending transactions without fees, just stating they aren't as required as people make them out to be.

M

[Luke-Jr]

It's hard to give a real world example, but you'll have a very hard time ever sending 13 BTC with 325 different inputs.  In that kind of situation, you'd be better off sending your inputs into a separate wallet with larger chunks (keeping the transactions small while doing so).  Do that a few times, then wait for those to mature, then use those to make even larger chunks (keeping transaction size small while doing so) again once they've matured enough to not require a fee.  Note:  This will not work if your initial inputs aren't big/old enough to avoid transaction fees.  Each 0.04 input would have to be 25 days (I think) old prior to being merged.

The "bag of pennies" scenario is a significant problem for small miners on p2pool.  Not so bad for larger ones.  But the larger p2pool becomes, the worse this problem is.  It's a hidden fee for using p2pool.  You get your money faster than some pools, though there are many pools that don't require waiting for blocks to mature (or PPS where you don't even have to wait for a block).  However, the larger p2pool becomes, the more frequently you'll be forced to pay txfees when spending coins.



p2pool's concept is great, but the payment method and share chain prevent it from becoming a major "pool".  Unless it gets turned into a series of supernodes which people mine through, which would end up being worse than the current pool system due to high stale rates using a remote node that has longpolls every 10 seconds.

Hmm.  If transaction fees are required, why does the client default to not providing any?  I know more than once I've accidentally sent a payment, all from p2pool, without a transaction fee because that setting wasn't on.  Never had a problem with them going through quickly or getting confirmations either.

Not that I'm advocating sending transactions without fees, just stating they aren't as required as people make them out to be.

They're optional right now because blocks have subsidies; Bitcoin also benefits from being the cheapest way to spend money online, which encourages its adoption and drives the market price upward (which is beneficial to the miners of course too). As designed, Bitcoin block subsidies will eventually drop below the break-even point for miners, at which point mining will be dependent on the transaction fees more immediately - though the longer we can afford to provide confirmations without a fee, the more likely Bitcoin's successful adoption is.

[khal]

With bitcoin 0.8, it'll be even more important (bitcoin nodes can download only a list of unspent tx, which reduces the blockchain size to something like 200MB).

This is not a planned feature of 0.8. While it will only use an unspent tx database, it still needs to download (and at present, store) the full blockchain. Just FYI.

Thanks for the explaination.

[mdude77]

It's hard to give a real world example, but you'll have a very hard time ever sending 13 BTC with 325 different inputs.  In that kind of situation, you'd be better off sending your inputs into a separate wallet with larger chunks (keeping the transactions small while doing so).  Do that a few times, then wait for those to mature, then use those to make even larger chunks (keeping transaction size small while doing so) again once they've matured enough to not require a fee.  Note:  This will not work if your initial inputs aren't big/old enough to avoid transaction fees.  Each 0.04 input would have to be 25 days (I think) old prior to being merged.

The "bag of pennies" scenario is a significant problem for small miners on p2pool.  Not so bad for larger ones.  But the larger p2pool becomes, the worse this problem is.  It's a hidden fee for using p2pool.  You get your money faster than some pools, though there are many pools that don't require waiting for blocks to mature (or PPS where you don't even have to wait for a block).  However, the larger p2pool becomes, the more frequently you'll be forced to pay txfees when spending coins.



p2pool's concept is great, but the payment method and share chain prevent it from becoming a major "pool".  Unless it gets turned into a series of supernodes which people mine through, which would end up being worse than the current pool system due to high stale rates using a remote node that has longpolls every 10 seconds.

Hmm.  If transaction fees are required, why does the client default to not providing any?  I know more than once I've accidentally sent a payment, all from p2pool, without a transaction fee because that setting wasn't on.  Never had a problem with them going through quickly or getting confirmations either.

Not that I'm advocating sending transactions without fees, just stating they aren't as required as people make them out to be.

They're optional right now because blocks have subsidies; Bitcoin also benefits from being the cheapest way to spend money online, which encourages its adoption and drives the market price upward (which is beneficial to the miners of course too). As designed, Bitcoin block subsidies will eventually drop below the break-even point for miners, at which point mining will be dependent on the transaction fees more immediately - though the longer we can afford to provide confirmations without a fee, the more likely Bitcoin's successful adoption is.

The next halving is in a little under 4 years, right?  Isn't that plenty of time to figure this out?

M

[Syke]

My biggest complaint about p2pool is the maintenance required to keep a p2pool node up and running. That said, the advantages to p2pool are enough to keep me on it.

[mdude77]

My biggest complaint about p2pool is the maintenance required to keep a p2pool node up and running. That said, the advantages to p2pool are enough to keep me on it.

Is it any different from making sure the conventional pool is working?

I just saw someone griping the pool he was using didn't tell him his miner was offline for 10 days.  I saw another one who was complaining the stats are wrong.  It seems to me the upkeep is the same between conventional and unconventional.

M

[zvs]

How is the block 'bonus' calculated for the person who solves a block?  Maybe if the person that solved it got *all* the transaction fees, it would encourage people to include the transactions?

I think it may already work something similar to this, but only a portion of the transaction fees?

Right now I have my block size limit set to 30000 because of all the orphans I was getting with the 200kb block sizes.... but, if the person that solves the block got all the fees included in that block, it'd be worth the extra 5% orphans..

[Krak]

How is the block 'bonus' calculated for the person who solves a block?  Maybe if the person that solved it got *all* the transaction fees, it would encourage people to include the transactions?

I think it may already work something similar to this, but only a portion of the transaction fees?

Right now I have my block size limit set to 30000 because of all the orphans I was getting with the 200kb block sizes.... but, if the person that solves the block got all the fees included in that block, it'd be worth the extra 5% orphans..

The block solver gets a 0.5% bonus while the rest of the 99.5% is split to all the miners. I still don't know what you're talking about with these orphans, there hasn't been an orphaned block since just over 2 weeks ago. If you're talking about shares, 5% is perfectly within the acceptable range.

[K1773R]

My biggest complaint about p2pool is the maintenance required to keep a p2pool node up and running. That said, the advantages to p2pool are enough to keep me on it.

Is it any different from making sure the conventional pool is working?

I just saw someone griping the pool he was using didn't tell him his miner was offline for 10 days.  I saw another one who was complaining the stats are wrong.  It seems to me the upkeep is the same between conventional and unconventional.

M

Syke is just a troll, simply put him on ignore. Despite the fact that there is already a public script who auto updates p2pool in combination with cron.

[jl2012]

OK, I'll try to restate again

I mine 500Mhs/s on p2pool and get a bunch of small payments per block and get 13 BTC and pre order a Jalapeno.

I mine another 13 BTC, say on Deepbit, with a 1 BTC threshold to a different wallet and pre order another Jalapeno.  Will the 13 BTC from p2pool require higher transaction fee to spend because they comprise a bunch of small input transactions?
Thanks,
Sam

With 500MHs/s your average reward should be around 0.04BTC per block found. You can pack several inputs in a transaction with a 0.0005 BTC fee so your loss from fees is less than 1% when you use p2pool mined coins.

So if the alternative is a pool with more than 1% fees you're automatically better off with p2pool.

Currently the fees earned by block mining are around 1-2%, so if the alternatives don't pay you network fees, that's more you lose vs p2pool.
And lastly, my 2 months performance on p2pool is 107,5% vs expected 100%PPS so p2pool seems to have a higher than average reward than most pools. I didn't even count some small downtimes in that period so it's a low estimate. This matches what http://p2pool.info/ reports: constant higher luck.

One explanation may be that p2pool is by its nature better connected to the bitcoin network than most pools: all P2Pool nodes quickly broadcast a p2pool found block on the bitcoin network which may lower orphan rate.

That's a very helpful explanation.

So at 4 Bit Cents per block my 13 BTC example would have 325 inputs.  Would that really be only a 0.0005 BTC fee?

Does anyone have a real world example?
Thanks,
Sam

Why not using a MtGox deposit address. It is free to receive and withdraw so you can combine your dust outputs to bigger ones

[smracer]

If ASIC's work with p2pool I will be adding 2.4TH to the network as soon as my first order arrives.

[zvs]

How is the block 'bonus' calculated for the person who solves a block?  Maybe if the person that solved it got *all* the transaction fees, it would encourage people to include the transactions?

I think it may already work something similar to this, but only a portion of the transaction fees?

Right now I have my block size limit set to 30000 because of all the orphans I was getting with the 200kb block sizes.... but, if the person that solves the block got all the fees included in that block, it'd be worth the extra 5% orphans..

The block solver gets a 0.5% bonus while the rest of the 99.5% is split to all the miners. I still don't know what you're talking about with these orphans, there hasn't been an orphaned block since just over 2 weeks ago. If you're talking about shares, 5% is perfectly within the acceptable range.

like this:

with maxblocksize at 0, i get much fewer orphans than with maxblocksize at 300,000.   it doesn't matter if my efficiency is (bordering) on 100% with maxblocksize at 300,000.  when it's at 0, it's 110% or more.  the *possible* .5 or so more from fees (of which i'd get around 4 or 5% (ed: more like 3%)) doesn't come close to making that up...   it doesn't take high level maths to figure out that you're worse off by including transactions

[Graet]

How is the block 'bonus' calculated for the person who solves a block?  Maybe if the person that solved it got *all* the transaction fees, it would encourage people to include the transactions?

I think it may already work something similar to this, but only a portion of the transaction fees?

Right now I have my block size limit set to 30000 because of all the orphans I was getting with the 200kb block sizes.... but, if the person that solves the block got all the fees included in that block, it'd be worth the extra 5% orphans..

The block solver gets a 0.5% bonus while the rest of the 99.5% is split to all the miners. I still don't know what you're talking about with these orphans, there hasn't been an orphaned block since just over 2 weeks ago. If you're talking about shares, 5% is perfectly within the acceptable range.

like this:

with maxblocksize at 0, i get much fewer orphans than with maxblocksize at 300,000.   it doesn't matter if my efficiency is (bordering) on 100% with maxblocksize at 300,000.  when it's at 0, it's 110% or more.  the *possible* .5 or so more from fees (of which i'd get around 4 or 5% (ed: more like 3%)) doesn't come close to making that up...   it doesn't take high level maths to figure out that you're worse off by including transactions

Which is a shame, as mining is about verifying transactions for the bitcoin network.