For all we know, it could just be some troll pretending to be with BFL, trying to keep people from buying more hash power before the halving, to keep the difficulty from rising even faster while it is still at 50btc...

Can anyone confirm that guy is even legit at this point? Cuz... why would they keep making announcements on a forum that isn't even theirs, yet, not put corroborating info up on their own web site, saying the same things?

-- Smoov

edit: someone posted a paste that they're looking for someone to handle public relations... maybe that position, is that guy's position that just became open, and he's disgruntled, trying to cause problems for them by making promises they aren't endorsing? (yeah, yeah, I know, but this kind of stuff happens)

like... ~US$150-160? for 3.5GH/s!!? and taking in trade-ins for credit of the asics? where is their profit margin supposed to be?

I read that already... doesn't actually answer my questions... much in the same way half of what they said doesn't actually answer other people's questions...

I'd rather have them actually answer my questions, than be directed to a post I already read before... thanks for trying tho.

-- Smoov

forrestv added some protocol changes to aid this very thing, but we're still dealing with a distributed network for the daemon's connectivity, and a separate distributed network for p2pool's connectivity. We basically have another level of notification, letting us know to work on a new block, but we still have the latency of a distributed network, getting that notification propagated. I think I am understanding it right tho, that p2pool's notification, will go much faster, as it deals with less data in the transmission, and less sanity-checking at each node before it gets passed on.

The main difference, the way I see it tho, amounts to the way a centralized vs decentralized system handles how the data gets around. How much it is handled between hand-offs, and how many hand-offs between the finder and the rest of the pool.

Take deepbit as an example... when one of their miners find a block, it is a very short path for the rest of the pool to be notified...

miner1!deepbit!{miner2|...|minerA}

With P2Pool and no centralized bitcoin, and with forrestv's protocol change from last week, we have 2 paths, but they can be pretty long.

miner1!p2pool1!bitcoind!bitcoind2!bitcoind3!bitcoind4!p2pool2!miner2
or
miner1!p2pool1!p2pool2!p2pool3!p2pool4!p2pool5!miner2

The paths the data needs to take, through either route, can be even longer. The route via bitcoind would be slower, and via p2pool would be faster, but both would be much slower than the deepbit path above.

If I remember right, we (p2pool users), have orphaned one of our own blocks before. Something that couldn't happen at the centralized pools.

-- Smoov

Yeah... I think... and, I wasn't around in the early days, not beginning to mine until the last quarter of last year, so, dunno about the early intentions of bitcoin...  but...

When it was designed, I think the intention was for individual peers mining individually. Not sure if pooled mining was the intent from the start. (I'm sure I'll be corrected on this if I'm mistaken )

So, a higher level of orphaned blocks, when scaled up to a lot of peers, may have been an expected metric, and considered the normal situation. Perhaps P2Pool's orphan rate, better reflects the way this would have been, without the centralization of mining?

What the centralized pools did, was cut out the latency from when found blocks, propagated to the other people mining. Since they would inform the mining peers more or less, simultaneously, it would have the effect of near-instant propagation among a large number of peers. Since none of them would have to sanity-check the block against their own blockchain, avoiding the latency that would come with it while distributing it, and not having to pass it along to the next set of peers afterwards, you have a large segment of miners abandoning the current block and starting the new one, much sooner than would have been expected, had everyone been solo-mining. This alone, would have eliminated a portion of what would have been a normal orphan rate.

All of those mining peers, on a centralized pool, would be considered collectively, a single bitcoin peer as far as the network is concerned. Take the top 75% of the hashpower on the bitcoin network, and you end up with, what... a few dozen bitcoin peers? Perhaps a little more? Certainly a tiny fraction of all of the individual bitcoin peers that are mining as a whole, by node count.

I don't know how this could be reflected in useful data, but perhaps this has an affect on assumptions of expected levels of good blocks and orphans within a given period of time?

I think what I'm getting down to, is... perhaps instead of looking to the average pool results to find normal, the pool results, should be considered above-normal instead of the baseline, which would be pure solo mining on a more distributed network?

-- Smoov

Does the coffee warmer have to actually be a coffee warmer?

Or, are you just calling it that cuz of its size, and it isn't really a coffee warmer... (and will it be capable of being powered by the wall instead of the USB? I really don't wanna unplug my USB toaster...)

-- Smoov
-- not liking the idea of keeping a cup of liquid on top of my asic

Um... perhaps something to consider...

When you were evaluating the other pools, one variable that didn't come into play, was the propagation of the new block among the miners.

Since with a centralized pool, long-polling delays aside, everyone is basically mining off of the same daemon.

With P2Pool, this is not the case. We're effectively all solo-miners, with pooled payouts. When one node finds a block, it takes time to propagate, so for a period of time, you would have part of the pool still working on one block, while a growing portion of the pool is working on the new block as the found block gets distributed.

As far as orphans go, a centralized pool is in itself, a single solo miner, albeit one with lots of connections, and bandwidth to distribute the new block efficiently. P2Pool, on the other hand, is a whole bunch of solo miners cooperating.

So, one thought that occurred to me, is when comparing stats, shouldn't solo mining be considered the normal, with the centralized pools, being above normal, due to the efficiency they have in their miners being notified that they should be working on the next block all at once? If they weren't pooled, all of those miners, would be notified at different rates, which may have an affect on orphan rates.

Perhaps, the orphans P2Pool have been experiencing were simply normal for solo mining...

(I'm no mathematician compared to your level, so, I may not be quite clear on what I'm getting at...)

-- Smoov

Very nice and thorough analysis... am impressed.

Small donation from a small miner, sent.

Will be interesting to see, if you do this again for p2pool, how forrestv's recent changes to increase propagation of found block info, affects the data. Given enough time of course.

-- Smoov

is the highlighting, user-defined?

cuz, if I tried to use that, with the colors your screenshot currently shows, I'd have to rip my eyes out.

-- Smoov

Judging solely by the long delivery times? I'd have to guess... "No, they don't".

-- Smoov

Probably shaves off at least 2 or 3 minutes off of his pizza delivery times...

-- Smoov

Mine have been updated as well.

-- Smoov

Yeah, that was the thread I was referring to in a previous post. On this one tho, I was asking about MtRed's. To compare against BTCGuild's. I only use BTCGuild as a backup now.

-- Smoov

Does MtRed ever say what they made, compared to what they paid out?

That's the thing about PPS... it can be good for the miner, but if the pool operator has a long enough string of bad luck, then he's screwed. The pool operator is gambling against the long-term odds.

-- Smoov

Well, the PPS pools also take all the risk on the variance/luck too. Dunno about DeepBit, but last I heard, BTCGuild took a big loss during the last cycle, so they lost money paying out all the shares, so kinda gotta take that into account too.

-- Smoov

So just create an account at Vircurex and sell off your NMC for BTC there.

They'll send email notifications when your coins arrive, and get traded, so once you have your account created, grab your NMC deposit addy from there, and set BTCGuild up to auto-payout to that addy.

Then, when the NMC payout happens, and Vircurex sends you the email about your deposit, just sell for BTC, and voila! Bonus BTC!

-- Smoov

edit: oh, and as for the DDoS threats, feel free to add my BTC P2Pool node (listed below) as a backup pool if any of you like. Use a BTC address as your username to get your payouts generated directly into your wallet, any password. Works same as solo mining, but based on PPLNS. Can't have too many backups

My servers didn't appear in your pasted code listing...

imperium.getmyip.com port 9332 & 9327 (btc & ltc)

-- Smoov

Good enough, will be waiting for that.

And, thanks for the offer, bitdragon, but to keep things simplest on my own end, I'll just wait for payb.tc to drop the minimum. Will give me time to get a whole coin together in my wallet, I got all my coin scattered around in different exchanges and investments right now

-- Smoov

Except for brief periods for updating and tweaking, mine will always be up, even if I'm not actively mining at the time.

imperium.getmyip.com

-- Smoov

Perhaps be able to log into our account and set an email address for notification? (since we can't change anything anyways, I don't see a risk to this)

Then, if there is an issue with one of our accounts, you know how to get a hold of the person linked to that account, and if one of our referral codes gets used, we could get a notification of that too, and can cross it off of our list?

-- Smoov

Will you be lowering your minimum deposit requirement later on? Once you have things more automated?

Being a small miner, getting 10btc at one time, will take months

-- Smoov