Latest posts of: maqifrnswa

Quote from: Frizz23 on March 31, 2013, 08:12:43 PM

Quote from: willphase on March 31, 2013, 08:05:35 PM

I don't think there is any malice in what they are doing though, ...

Promise in September (2012) to ship in October (2012) when they had literally nothing (no ASICS, no prototype, not even a functional design), stringing people along month after month and make fun of the competition (that managed to deliver their products months ago) - you don't see and "malice" in this?

Hanlon's razor:

Never attribute to malice that which is adequately explained by stupidity.

Quote from: PatMan on March 29, 2013, 07:07:46 PM

Good for you,

Did Forrest mention anything about checking the whole stratum code in p2pool?

If you know of a problem, you can report it here:
https://github.com/forrestv/p2pool/issues?state=open

This will help you understand how you can help most efficiently:
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

you can also find the devs on #p2pool on freenode.net irc if you'd like to discuss something specific with them.

For the sake of p2pool, please stop publicly posting that there are problems with stratum, p2pool, and standard mining software without any data (logs, error messages, debug output). I'm not saying there are no problems, just that no one has reproduced what you are saying is a problem and shared it with developers. Therefore, no one can look into fixing it. If you share your evidence, then maybe we can fix it.

Quote from: infested999 on March 28, 2013, 07:20:27 PM

Can anyone do an experiment right now where you send with a .0005 fee, then with a .0004 fee, and so on until .0000 and see if how long it takes for each transaction to go through.

it's a little more complicated than that since miners might be looking at fees per kilobyte of data with some minimum thresholds for bitcoin-age.

Code:

How many bytes of the block should be dedicated to high-priority transactions,                                                                                                 
included regardless of the fees they pay                                                                                                                                 
blockprioritysize=27000

Minimum block size you want to create; block will be filled with free transactions                                                                                       
until there are no more or the block reaches this size:                                                                                                                  
blockminsize=0

Fee-per-kilobyte amount (in BTC) considered the same as "free"                                                                                                                    
Be careful setting this: if you set it to zero then                                                                                                                      
a transaction spammer can cheaply fill blocks using                                                                                                                      
1-satoshi-fee transactions. It should be set above the real                                                                                                              
cost to you of processing a transaction.                                                                                                                                 
mintxfee=0.0005

Not as complete as what you're looking for, but:
http://bitcoinstats.org/

Quote from: paraipan on March 29, 2013, 03:14:55 PM

Quote from: Gavin Andresen on March 29, 2013, 03:12:14 PM

So.... move too fast and we maybe introduce a forking bug or a security vulnerability.

Move too slow and maybe we get fired-- somebody faster at incorporating safe changes releases their own fork.

For me, "move slow" is the right answer.

But I would be completely happy contributing patches to somebody else running a fork who solves the "move fast but be safe" problem.

Ok, start a "Bitcoin-QT Poweruser" fork, and let people submit their heart's desire. Without you doing this it will have 0 credibility, including from me.

Edit: Hope you're not coming in from above just to go back again after you said only 2 words.

Why are you relying on your nanny-state oppressor to provide the fork you want when you can make one yourself and let people submit to their heart's desire? That is what is supposed to happen (see https://bitcointalk.org/index.php?topic=22434.0)

Galvin is gaining credibility amongst the community by not including every patch/feature people request.

Ok, continuing trying to find bugs:

2 bugs found, one regarding only avalons using avalon-branch cgminer problems with p2pool stratum, one regarding maximum difficulty:

The bug that has been reported regarding avalons, stratum, and p2pool is:
https://bitcointalk.org/index.php?topic=18313.msg1683442#msg1683442
"Avalon Cgminer without fix protocol connects on stratum but resends all work over and over. There's something wrong with the way it reads the stratum response. Someone, Jeff I think, said it has a problem with double byte responses that p2pool makes. On getwork, it just hammers the server and the DOA rate is >25%. Using a very high diff 3000-4000 helps a tiny bit. The highest p2pool would let me go is 6535. Any higher number just comes back as 6535.

Even soloing to a bitcoind alone will crash. It's too much. Hence the need to run a buffer like eloipool between it."

The workaround is:
https://bitcointalk.org/index.php?topic=18313.msg1690401#msg1690401
"So far the only thing that works is using fix-protocol and getwork with a very high diff. I've been using /4000+16. That seems the best balance. +32 is all late. You have to remember the "miners" are only 300mhash each. It will bring a 3930k running Ubuntu with 32gb of ram to its knees. It pegs 4 processors trying to keep up and eventually crashes as it runs out of memory. I also is 25-35% DOA. You loose 1/3 of your hashrate."

How it is getting fixed:
https://bitcointalk.org/index.php?topic=18313.msg1684865#msg1684865
Unfortunately, it appears that until avalan-branch cgminer merges into main-line cgminer it will be difficult to support. Maybe discussing this with Xiangfu ahead of time could be helpful. It might also be helpful to get forrestv/cgminer team avalons if someone cares about support for them.

Bug #2, maximum difficulty:
https://bitcointalk.org/index.php?topic=18313.msg1684832#msg1684832
using the username+difficulty -u flag, Aseras reported only being able to reach a maximum difficulty of 6535. I can repeat this, the maximum difficulty I can reach is 999 with both stratum and LP. This has been reported here:
https://github.com/forrestv/p2pool/issues/87

Quote from: mdude77 on March 28, 2013, 02:32:47 PM

I've been running p2pool on stratum for about a week with cgminer. I noticed the hash rate just isn't as high as it should be. Not significantly lower (2.4gh instead of 2.6), but still lower. Based on what was revealed about Avalon and stratum, I thought I'd try disabling stratum in cgminer. Guess what, my hash rate is back where it should be. Note that I don't have the hash rate degradation on a "conventional" pool with stratum.

Unfortunately while I can only salivate about the idea of having an Avalon, there does seem to be evidence that stratum isn't functioning up to par on p2pool.

M

THANK YOU! This is a legitimate starting point. This is something that can actually be looked into, do you mind filing an issue:
https://github.com/forrestv/p2pool/issues?state=open
(I think forrestv does some triage on this forum as well)

Quote from: PatMan on March 28, 2013, 07:33:42 AM

Although I'm sorry that you're not able to use your avalon on p2pool, (it must be very frustrating - & I was looking forward to seeing the results), it is actually quite a relief to finally get some confirmation that the stratum code on p2pool is borked after banging my head against a wall for so long, not to mention a few "experts" living in denial.

This is the problem: you keep citing the wrong numbers as evidence of a problem.

You think there is a problem with stratum, but you keep using "luck" as your evidence. Your argument is "it is impossible for luck to be this bad, therefore something must be broken." Your premise is false, and I proved it by demonstrating how common such bad luck is in reality. That isn't living in denial, but in reality.

However, this post presents new evidence: "stratum connection crashes p2pool." If that is true, that has nothing to do with luck (a crashed p2pool does not hash and does not contribute to luck). Your use of luck as a metric/evidence is still wrong.

I'm not saying there is nothing wrong with p2pool, I've been saying all along that your arguments are based on either the wrong data or wrong conclusions from data.

I like people putting money where their mouth is!

In traditional media the media company would run Josh's ad over yours even if you outbid him since the future income from Josh far outweighs the future income from this campaign. It'll be interesting to see if the threat of BFL advertisement boycott of bitcointalk outweighs the set rules of the ad auction. (Also interesting to see if BFL sees this as a long term threat or a minor inconvenience. They will boycott if it is a threat and ignore it if they think it is an inconvenience).

popcorn time...

Quote from: ewibit on March 25, 2013, 10:45:01 PM

Quote from: mdude77 on March 13, 2013, 12:37:59 AM

Aside from the fact p2pool's 90 day "luck" is at 88.5%, and 30 day "luck" is at 57.1%. Aside from that, yes, it's great.

is there anywhere a graph about the luck of p2pool from the last 90 days?
TIA

http://p2pool.info/luck/

7 day luck 136%
30 day luck 100%
90 day luck 96.4%

@Aseras: I'm really interested in hearing how the avalons work on p2pool, besides jgarzik i don't know of anyone that has one to even try yet. Congrats and good luck!

Quote from: Richy_T on March 25, 2013, 07:02:38 PM

Quote from: gektek on March 25, 2013, 06:54:07 PM

So...it would be swell if somebody could prove me wrong though...eh? eh? Any takers? Tongue

I have to think that it can't be that hard. Like you say though, it's about having the information. I wish I didn't already have too many projects that aren't getting attention because I'd like to get more into the Bitcoin infrastructure.

I think this is the only open source pool software:
https://bitcointalk.org/index.php?topic=61731.0
https://www.gitorious.org/bitcoin/eloipool

Why people don't do it:
1) Margins are razor thin
2) high liability (a popular pool lost a couple thousand dollars in a few minutes switching from bitcoind 0.7.2 to 0.8.0)
3) high technical know-how barrier to entry
4) existing pools just "work" and have good reputations (low variance, history of payout, low fee, high uptime, etc.)
5) hard to differentiate yourself (only so many ways to pay out...)
6) if you really want your own pool, p2pool "just works." those that want to mine their own pool can set it up themselves and use the --fee command line argument to charge those that mine on your pool a fee (or make it 0 and those that log into you will just get paid, great for a small pool of friends). You need similar hardware to run p2pool as you would your own mining pool, so why bother reinventing the wheel.

Quote from: mdude77 on March 22, 2013, 09:30:04 PM

I wouldn't call it nitpicking. The fact is under a week ago, 90+ day performance was < 90%. That is awful in my book. Is it really luck that suddenly changed this last week? While I find that hard to believe (and I'm not convinced), I'll defer to the mathematical experts who claim it's all variance and shut up.

M

I am a mathematical expert. If your hash rate solves 2 blocks every day over 90 days, there is a 9.4% chance that in any given 90 day period you'll have < 90% "luck"

If your hash rate solves 1 block every day, there is a 19% chance that you will have less than <90% luck in a 90 day window.

So when p2pool's hash rate was low the pool was more likely to have < 90% luck over 3 months than someone throwing a 6 on a 6 sided dice.

My point is that I'm kind of surprised people think something that has between a 1/10 and 1/5 chance of occurring is a sign it is broken.

Quote from: mdude77 on March 22, 2013, 04:21:40 PM

Solely looking at p2pool stats, not gut feeling. You said a week was bad, on what basis do you make that statement?

M

I said last week was bad based on the 7 day sliding average data presented on p2pool. I was comparing data from Sunday the 17th (the original date it was posted) GMT to data from the Thursday the 14th GMT. It's semantics and counterproductive to discuss what dates were chosen for the illustration.

What you're nitpicking really doesn't matter at all, this is not a discussion of whether or not we are lucky. I was just illustrating that people confuse "luck" with "it's broken." And I gave an example how over the course of one week we switched from "it's crap" to "it's the best pool in the history of the universe."

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining. If not enough people are mining on it, it will have huge variance. You were unlucky, but someone else who mined p2pool probably had inverse luck. For example, over the past 7 days (March 22), p2pool paid you 185% of what you would have gotten from PPS (including fees). Last week (March 15th), people mining on p2pool were only paid 85% compared to PPS (including fees). Variance (luck) is a problem for all pools that are underpowered and doesn't mean that it "pays out crap."

Quote from: GernMiester on March 16, 2013, 11:26:15 PM

Worked just fine but it was far from paying anywhere near what the PPS pool I left was making me even when it had donations out the wazoo. The hashrate is low and blocks are not solved often. You can go 1, 2 or even worse 3 days with zero payout.

I quit many moons ago due to horrible random payouts that never seem to be anywhere ear what any other pool will make you. Maybe I had it setup wrong or maybe it pays like crap.. It certainly paid me less than 1/3rd of what I could have mined at a PPS pool in the same time. Its a great idea no one seems to care for and it seems mostly because it pays like crap.

The mathematical fact still remains that a well tuned p2pool will out pay any other pool. In fact, it will approach solo mining. If not enough people are mining on it, it will have huge variance. You were unlucky, but someone else who mined p2pool probably had inverse luck. For example, over the past 7 days, p2pool out paid PPS by 15% (including fees). Last week, people mining on p2pool were underpaid by 15% compared to PPS (including fees). Variance (luck) is a problem for all pools that are underpowered and doesn't mean that it "pays out crap."

If you solo mine for a month and don't find a block, you will think it pays out crap compared to PPS.

Quote from: gyverlb on March 16, 2013, 08:37:03 PM

That's not something you download but something you configure using Linux, tmpfs, the standard bitcoind v0.8 and your skills as a sysadmin. I didn't do it myself because I don't have enough RAM to store the whole data directory (so it wouldn't work well for me) but I've met someone on IRC who claimed having done so with a getwork latency < 0.01s.

If someone can post instructions, I'll link to them.

Code:

mkdir -p /var/ramdrive
mount -t tmpfs -o size=10G,mode=0744 tmpfs /var/ramdrive

Tune it for you own mount location, desired size, and desired permissions. You may need to run the scone command as root, and if you do you'll need to chown the new mount point:

Code:

sudo chown user:user ~/ramdrive

now copy over your blocks to ~/ramdrive and it will be super fast. Note that you'll need > 7GB for your blockchain, I don't know how many consumer level machines are around with that much (but Sub's 64GB will rock)

You need to remount it every boot, or you can put the following at the end of your /etc/fstab

Code:

tmpfs /var/ramdrive tmpfs size=500M,mode=0777 0 0

it's going to be root owned, so you can tune the permissions as you wish

take from http://kvz.io/blog/2007/07/18/create-turbocharged-storage-using-tmpfs/

This is great! Thank you!

If someone tries tmpfs for the data directory, and they lose power, they will lose the blockchain (and wallet). Extra care has to be taken to make sure no important addresses are in that wallet (since p2pool will create one unless you specify another address) and that the blockchain should be backed up to disk to prevent re-downloading every boot.

Quote from: mdude77 on March 14, 2013, 01:28:23 AM

p2pool coincidentally went south after stratum support was added. It's been down, quite a bit, since then, with no signs of coming back.

It could be all horrible luck. But the longer it goes on, the less likely it is bad luck.

http://p2pool.info/

M

Thanks - my point is that it doesn't help to keep posting there is a problem without actually finding what the problem is (or if there even is a problem). It's all open source yet no one can find a problem with the code. While the luck charts make it look like something is wrong, other analysis shows that it may be working ok:

Quote from: organofcorti on February 28, 2013, 09:00:57 AM

As a follow up to my last post, here's a better way of judging luck:

My point is to not assume something is wrong just because it feels wrong. It's your money, and can mine how you like - I just wanted to point out that there are no comments because as far as anyone can tell there is no problem.

Quote from: PatMan on March 14, 2013, 12:27:43 AM

Quote from: PatMan on January 18, 2013, 07:30:15 PM

Quote from: Subo1977 on January 18, 2013, 07:16:34 PM

No comments?

Indeed. It's also a shame, because if nothing is said or discussed about this problem P2pool will continue to lose miners and cease to exist. That would be a crying shame, because I believe it can work so much better than it is. This was my first and favorite pool, I like the idea of it very much, but at the moment - it's broken.

If it gets fixed, and I hope it does, I will have no problem joining it again.

And, look where we are now.......

Comments about what? What problem needs to be fixed? Is there a bug (besides increased variance combined with increased expected time to solve blocks)?

Quote from: kano on March 13, 2013, 03:49:56 AM

Sorry, you are incorrect, since you have ignored pointing out the 2nd part of the reject issue:

The problem with 10-15% rejects is that means others on p2pool with 4-5% rejects are getting a greater proportion of each block vs their hash rate.

Yes if EVERYONE was mining at 10% rejects, then everyone would get the same proportion of income vs their hash rate.

However, those with better reject rates get a proportionately better payment rate and that extra comes from those with the worse reject rates.

That's true, and needs to be understood. Even so, I frequently am trying to explain p2pool to people that are getting just 4-5% rejects (that is, they are doing well compared to the network), and they still think they are losing money compared to other pools (when they are actually making more compared to other pools for being more efficient than others on p2pool).

All I was trying to emphasize is that reject rate on p2pool does not mean the same thing as reject rate on other pools.

Quote from: organofcorti on March 13, 2013, 07:05:45 AM

If the last n blocks are sufficiently unlucky that for 95 runs of n block solvings out of 100 those n blocks will have required fewer shares to solve, then by definition, the next n blocks will have a 95% probability of being "luckier" than the last n blocks.

Ha, yes, if you are unlucky a lot, your next blocks are expected to be luckier than your unlucky blocks. It doesn't mean that your expected value changes, just your return compared to previous blocks. If I buy two lotto tickets, and lose the first one, my expected outcome of the second one is greater than the known result of the first one.

Quote from: lenny_ on March 12, 2013, 12:08:29 PM

Can you please share your settings with me? cgminer is able to get similar results?

Many people have said this, but I want to make sure lenny_ understands: The 10-15% "rejects" you see in p2pool have nothing to do with a decrease in income nor with wasted work. 10-15% rejects on p2pool is the same as 2-2.5% rejects on any other pool. The reason is that the p2pool sharechain is different (in behaviour) than the bitcoin blockchain.

I'm periodically fighting FUD of "p2pool sucks because they have a ridiculous reject ratio." I then explain it to people, with examples showing how you make more money with a 10-15% reject rate on p2pool than you would on a 2% reject rate on another pool. A few days later, someone else pops up and says the same thing.

The 10 second LPs have nothing to do with lost income and does not create a disaster, the sharechain is different than the blockchain.

This is a phenomenal description of p2pool:

Quote

I think p2pool is for geeks who like to setup and tune everything themselves. When you can host a node properly (for me this means locally on a host with a good CPU, 2GB RAM on a Linux server dedicated to bitcoind+p2pool, a SSD to store bitcoind's data and with a good QoS setup so that both bitcoind and p2pool don't suffer from other traffic on your WAN connection) and configure a backup pool it's arguably the most reliable and profitable option.

It's not for everyone, but if you are a serious miner and have the network connection and hardware available it's simply the best solution.