sharky112065
|
|
March 26, 2012, 04:34:30 PM |
|
The average miner on p2pool (and thus the average share variance) is ~1.5GH/s You "could" do it as a 1 GH/s miner but you already have above average variance so I wouldn't. So a miner w/ 3GH/s @ 1,500 would have the same variance as the avg miner does @ target 750 (current min share diff). A miner w/ 15 GH/s @ 7,500 would have the same variance as a 1.5GH/s miner @ target 750 (current min share diff). While I don't suggest someone raise it that high the more hash power you have the more you can raise diff and still have better than avg variance. It would be nice if p2pool showed another chart/graph that suggests what to set it to. IMO more miners would be apt to make the change if it were easier to determine what it should be set at. Forrestv, any chance of that happening in the future?
|
Donations welcome: 12KaKtrK52iQjPdtsJq7fJ7smC32tXWbWr
|
|
|
|
|
|
|
|
Once a transaction has 6 confirmations, it is extremely unlikely that an attacker without at least 50% of the network's computation power would be able to reverse it.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
Panda Mouse
Member
Offline
Activity: 88
Merit: 10
Gliding...
|
|
March 26, 2012, 05:11:05 PM |
|
The average miner on p2pool (and thus the average share variance) is ~1.5GH/s You "could" do it as a 1 GH/s miner but you already have above average variance so I wouldn't. So a miner w/ 3GH/s @ 1,500 would have the same variance as the avg miner does @ target 750 (current min share diff). A miner w/ 15 GH/s @ 7,500 would have the same variance as a 1.5GH/s miner @ target 750 (current min share diff). While I don't suggest someone raise it that high the more hash power you have the more you can raise diff and still have better than avg variance. And I have now funny signature on the graphics: "username/3000+1" Panda Mouse.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
March 26, 2012, 06:33:10 PM |
|
Yeah someone has asked forrest to remove the /xxx+y from charts and reports.
thus "username/3000+1" = "username". Maybe in a future version.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
March 26, 2012, 07:16:14 PM |
|
Custom Fee Rules for p2pool (and solo) miners:As a p2pool miner would you like to be able to control which tx you include in a block? I created a bounty to modify bitcoind to allow a miner to set rules on which tx are included in the block they are working on. Luke Jr has created and published the source code. Code is open source licensed under MIT license (same license as bitcoin). As the block subsidy declines over time fees will play an important role in miner revenue. If users can get included in the next block w/ no fee they will never have an incentive to include a fee. The RPC calls allow a user to set the minimum fee they will accept and tx w/ smaller fee are excluded from the tx list that p2pool uses to build a block. p2pool miners also are unlikely to alter the fee dynamic but we can be part of the discussion. As pools (including p2pool miners) set fee requirements >0 confirmation times for free/low fee tx will increase. This will create an incentive for users to increase fees. We aren't talking massive fees but every bitcent helps. Luke has requested a pull into the "mainline" bitcoind here: https://github.com/bitcoin/bitcoin/pull/989Please don't comment at the link above unless you are an active client developer. Cluttering up this with "yeah add it" is bad form. I included the link to allow people to allows you to see the status on the pull. Here the "custom fee" git created by Luke https://github.com/luke-jr/bitcoin/tree/customfeeI will try to get some compilation instructions up for windows/linux for users who wish to try it out before it becomes part of the mainline. Non-developers can indicate support with a post in this thread: https://bitcointalk.org/index.php?topic=73941.0More support = quicker inclusion in mainline client.
|
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
March 26, 2012, 08:20:00 PM |
|
Custom Fee Rules for p2pool (and solo) miners:As a p2pool miner would you like to be able to control which tx you include in a block? I created a bounty to modify bitcoind to allow a miner to set rules on which tx are included in the block they are working on. Luke Jr has created and published the source code. Code is open source licensed under MIT license (same license as bitcoin). As the block subsidy declines over time fees will play an important role in miner revenue. If users can get included in the next block w/ no fee they will never have an incentive to include a fee. The RPC calls allow a user to set the minimum fee they will accept and tx w/ smaller fee are excluded from the tx list that p2pool uses to build a block. p2pool miners also are unlikely to alter the fee dynamic but we can be part of the discussion. As pools (including p2pool miners) set fee requirements >0 confirmation times for free/low fee tx will increase. This will create an incentive for users to increase fees. We aren't talking massive fees but every bitcent helps. Luke has requested a pull into the "mainline" bitcoind here: https://github.com/bitcoin/bitcoin/pull/989Please don't comment at the link above unless you are an active client developer. Cluttering up this with "yeah add it" is bad form. I included the link to allow people to allows you to see the status on the pull. Here the "custom fee" git created by Luke https://github.com/luke-jr/bitcoin/tree/customfeeI will try to get some compilation instructions up for windows/linux for users who wish to try it out before it becomes part of the mainline. Non-developers can indicate support with a post in this thread: https://bitcointalk.org/index.php?topic=73941.0More support = quicker inclusion in mainline client. It is interesting to note that there are 2 pools that avoid paying fees by putting the payment in the coinbase. P2Pool and Eligius (Luke-jr's pool) 2nd interesting point is that Eligius ignores every txn without fees. It is interesting that you'd make the comment about fees being the necessary evil on a pool that avoids paying them (by increasing the block size quite a lot)
|
|
|
|
bitclown
|
|
March 26, 2012, 09:43:57 PM |
|
So it has come to this. P2Pool miners joining the Mystery Miner in the transaction throttling attack. Bitcoin is still an experiment being bootstrapped. Gatekeepers asking for fees is not what we need to get the ball rolling. It's interesting that 'ol evil Deepbit now has the most liberal fee policy for standard transactions.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
March 26, 2012, 09:46:56 PM |
|
So it has come to this. P2Pool miners joining the Mystery Miner in the transaction throttling attack. Funny. Charging for a service = attack. In related news mining pools and Mt.Gox daily launch massive attacks on the Bitcoin economy. Also please don't slander p2pool. p2pool is made up of individual members. Saying p2pool is attacking Bitcoin makes no more sense than saying Bitcoin is attacking Bitcoin. Be a man and say DeathAndTaxes is attacking the network when you lie.I would say something like "cry bitclown cry, your freeloader tears only nourish me", but that would be trolling so I won't.
|
|
|
|
ChanceCoats123
|
|
March 26, 2012, 10:46:30 PM |
|
Am I the only one who doesn't understand why people join other's nodes instead of creating their own? If you can point your miner successfully at someone else's node, then you have the skills necessary to run your own. No drama should come from this. P2pool is fee free...if you use your own node. If you want to pay 0 fees then run your own got dang node...!
|
|
|
|
Krak
|
|
March 26, 2012, 10:58:14 PM |
|
Am I the only one who doesn't understand why people join other's nodes instead of creating their own? If you can point your miner successfully at someone else's node, then you have the skills necessary to run your own. No drama should come from this. P2pool is fee free...if you use your own node. If you want to pay 0 fees then run your own got dang node...!
If somebody has a slower internet connection, they might not want 10+ connections to other nodes (not to mention all the connections that bitcoind makes) slowing them down. And of course there's the 1GB+ blockchain download.
|
BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
|
|
|
bitclown
|
|
March 26, 2012, 11:27:15 PM |
|
Did you think I shouldn't have control over the hardware I've purchased, the electricity I pay for, or the software I run?
Of course you should, I was merely voicing my opinion. Sorry for trolling. In my defense, I am a clown. What this does is start the path towards the competition to secure the network and process transactions in exchange for a fee. This is required for Bitcoin to be sustainable in the long run. Obviously the most profitable miners will be the most successful in their endeavors wresting control away from those who are not. This is the free market at work, and it's going to continue to be a fantastic ride.
It'll indeed be a fantastic ride, and more thought-out fee policies are needed. My objection was to DaT's intention, as stated in the MM thread, to rise his fee threshold to 0.01 BTC right now. The current transaction traffic is minuscule. What we need is growth, and I don't see how fees higher than regular bank transfers will encourage new users to play with an experimental network. Fees will accumulate as the traffic increases. As a casual miner who are unlikely to mine many blocks on my own I'd rather take my hashing power to a pool whose operator share these views.
|
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
March 26, 2012, 11:53:46 PM Last edit: March 27, 2012, 02:29:24 AM by kano |
|
It is interesting that you'd make the comment about fees being the necessary evil on a pool that avoids paying them (by increasing the block size quite a lot) Could you provide some proof that traditional pool payouts have less of an impact on block size when compared to P2Pool payouts? I do believe this is what you are insinuating with the quoted comment. Just quickly browsing some blocks and this is what I find. A deepbit block with what I am assuming are deepbit pool payouts. (1VayNert is deepbit). http://blockexplorer.com/b/17300521.192 kB (may be slightly off, I did this manually and could have missed a payment or two) of transactions with the 1VayNert address. A P2Pool block with the obvious payout. http://blockexplorer.com/b/1730037.603 kB of P2Pool payout (at least this information is easy to audit). Is this conclusive? Obviously not. The reason I'm posting this is because I think you should provide some evidence before making veiled accusations that P2Pool or Eligius are adding to the size of the block chain at a rate that is greater than any other pool. Can you show that it isn't by design or can you only pick a simple example and not even understand what that example represents? (Also interesting that you ignored the point of the post and zeroed in on the extra bracketed text - I presume that means you have no comment on the point of the post?) Anyway ... P2Pool pays each person who provides at least one share every 3 blocks, the amount they are due every block no matter how small it is. Assuming a normal pool pays each person with a single transaction every block they mine, then yep a normal pool is using approximately 7.5 times the amount of blockchain space ... according to those 2 blocks (of course a normal pool doesn't pay everyone every time a block gets mined ... but anyway) I take that was the point of why you mentioned those 2 specific blocks but didn't bother to show any understanding of what they represent? Of course, you can't change that payment process with P2Pool - it's fixed by design. With any pool that deals with balances and payments, that can be reduced by simply aggregating payments (as normal pools already do) But of course they would need to have less than 1 payment per 7.5 blocks the pool mines per person (which I have no idea of the statistics - and by the looks of that block, DeepBit might not?) if they paid each person with a separate txn. Anyway ... if DeepBit people are being paid on average more than once every 7.5 DeepBit blocks then DeepBit is using more blockchain space than P2Pool Is this true? Feel free to apply some brain power ... However, the point being that it is possible on a standard pool to aggregate payouts and to pay multiple people per txn, but if normal pools are not aggregating payments and also not paying multiple people per txn then they too are wasting block space ... which can be changed, unlike P2Pool that cannot. The opposite way to consider it is imagine that every miner was using P2Pool (yeah OK P2Pool can't handle that - but what the hell just imagine it anyway - what certain P2Pool zealots have wet dreams about) then every person who generates a share on average once every 3 blocks or more will get on average a payment in every P2Pool block To put that in perspective: to receive on average one share per 3 blocks (at the moment roughly 14hrs) with a P2Pool share difficulty of roughly 670, you would require approx 60Mh/s ... to thus get a payment every P2Pool block. Based on P2Pool being roughly 330GH/s - that's roughly 4.5 blocks a day: Interesting, if P2Pool is making 4.5 blocks a day and a normal pool is paying every person on average once every 5/3 days, they are using roughly the same amount of block-chain space. Thus me saying a 'lot' is certainly an exaggeration. If pools pay single transactions per person and on average each person more often than once every 5/3 days then normal pools are using more blockchain space than P2Pool.
|
|
|
|
twmz
|
|
March 27, 2012, 01:33:18 AM Last edit: March 27, 2012, 03:22:29 AM by twmz |
|
The nice thing about p2pool is that DeathAndTaxes and I can disagree on this and we can each do what we want to with out own bitcoind instances. I personally, don't see any need to restrict transactions at this point in bitcoin's evolution.
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
NothinG
|
|
March 27, 2012, 02:26:41 AM |
|
The nice thing about p2pool is that DeathAndTaxes and I can disagree on this and we can each do what we want to with out own bitcoind instances. I personally, don't see any need to restrict transactions at this point in bitcoin's evolution.
I think it should be weighed at least. Like if transaction was sent with a 0.01 BTC Tx Fee, push it through TX as fast as you can. Like, preferred.
|
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
March 27, 2012, 02:31:06 AM |
|
Followup of my above post with some DeepBit numbers: so I asked DeepBit and he said that the auto payout feature is 1 payout per day (but 3 manual payouts are possible but most people use auto)
If we calculate based on the 1 payout per day, then since DeepBit is around 3500GH/s that's about 48 blocks a day so most people are getting at most 1 payment per 48 blocks so using 1/48 of the previous calculated ratio: P2Pool is using 6 (rounded down from 6.4 to compensate for some manual payouts) times as much blockchain space as DeepBit is using per miner.
Even if you make the wildly ridiculous claim that everyone on DeepBit is using manual payments 3 times a day - P2Pool is still using twice as much blockchain space as DeepBit is using per miner.
|
|
|
|
twmz
|
|
March 27, 2012, 03:22:18 AM |
|
The nice thing about p2pool is that DeathAndTaxes and I can disagree on this and we can each do what we want to with out own bitcoind instances. I personally, don't see any need to restrict transactions at this point in bitcoin's evolution.
I think it should be weighed at least. Like if transaction was sent with a 0.01 BTC Tx Fee, push it through TX as fast as you can. Like, preferred. It is already prioritized in the default bitcoin transaction selection algorithm. When there are too many transactions to fit in a block, bitcoin will choose transactions with the highest priority and tx fee is one way a transaction can get a higher priority.
|
Was I helpful? 1 TwmzX1wBxNF2qtAJRhdKmi2WyLZ5VHRs WoT, GPGBitrated user: ewal.
|
|
|
Red Emerald
|
|
March 27, 2012, 04:24:48 AM |
|
Followup of my above post with some DeepBit numbers: so I asked DeepBit and he said that the auto payout feature is 1 payout per day (but 3 manual payouts are possible but most people use auto)
If we calculate based on the 1 payout per day, then since DeepBit is around 3500GH/s that's about 48 blocks a day so most people are getting at most 1 payment per 48 blocks so using 1/48 of the previous calculated ratio: P2Pool is using 6 (rounded down from 6.4 to compensate for some manual payouts) times as much blockchain space as DeepBit is using per miner.
Even if you make the wildly ridiculous claim that everyone on DeepBit is using manual payments 3 times a day - P2Pool is still using twice as much blockchain space as DeepBit is using per miner.
How much of a problem is having a large number of small coinbase transactions? If blockchain bloat becomes a problem maybe pools like p2pmining.com will gain more popularity.
|
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
|
March 27, 2012, 04:26:58 AM |
|
Not a problem at all. The # of coinbases is fixed. As tx volume grows the coinbase as % of block size will continue to fall.
|
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
March 27, 2012, 04:40:21 AM |
|
Not a problem at all. The # of coinbases is fixed. As tx volume grows the coinbase as % of block size will continue to fall.
Um - so that's assuming the number of people mining P2Pool will never increase from the number it is today.
|
|
|
|
kjj
Legendary
Offline
Activity: 1302
Merit: 1024
|
|
March 27, 2012, 04:51:53 AM |
|
Not a problem at all. The # of coinbases is fixed. As tx volume grows the coinbase as % of block size will continue to fall.
Um - so that's assuming the number of people mining P2Pool will never increase from the number it is today. There is only one coinbase per block. The number of outputs in the p2pool coinbase increases with the number of shares earned*, but the p2pool difficulty adjusts too, so the number of outputs won't grow without limit. Also, there is a hard limit to the number of shares counted in p2pool. * Actually, with the number of addresses to be paid. There can be fewer addresses paid than shares, but never more.
|
17Np17BSrpnHCZ2pgtiMNnhjnsWJ2TMqq8 I routinely ignore posters with paid advertising in their sigs. You should too.
|
|
|
kano
Legendary
Offline
Activity: 4466
Merit: 1800
Linux since 1997 RedHat 4
|
|
March 27, 2012, 05:25:22 AM |
|
Not a problem at all. The # of coinbases is fixed. As tx volume grows the coinbase as % of block size will continue to fall.
Um - so that's assuming the number of people mining P2Pool will never increase from the number it is today. There is only one coinbase per block. The number of outputs in the p2pool coinbase increases with the number of shares earned*, but the p2pool difficulty adjusts too, so the number of outputs won't grow without limit. Also, there is a hard limit to the number of shares counted in p2pool. * Actually, with the number of addresses to be paid. There can be fewer addresses paid than shares, but never more. 8640 ~= 290K if 8640 people mined and each got a block ... though of course unlikely. However, that means if P2Pool ever actually had more than 2880 miners, some would certainly be be unhappy (and at 2880 it could ~= 99K)
|
|
|
|
|