thats the biggest problem right now, as i see it. too many variables in the equation, too many unanswered questions. BFL and ASIC's in general... there are so many ways things COULD go, that we can't predict where they will with any certainty. my initial intent to buy some lancelots or other FPGA's may be evaproating until this all shakes out. i dun know.
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?
|
|
|
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
https://bitcointalk.org/index.php?topic=87934.msg974605#msg974605I 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
|
|
|
@Smoovious: I think it's the other way around. A centralized pool should have more latency than solo because first the pool needs to learn about the block, then it has to long-poll you. When solo mining you just need to learn about the block.
If I understand this right, you're talking about stale shares, not orphans. If I find a block on p2pool, but my bitcoind is only connected to 8 peers, it might take a while for the block I found to propagate through the network. Meanwhile Deepbit finds a block and sends it to 1000 different nodes all at once, orphaning my block. I don't know the workings of p2pool fully. Do they send newly found blocks to each other as well, to aid in propagating it? 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
|
|
|
Well, if a stale share happens to be a block, it is technically an orphan block, so this is still an increase in the orphan rate, depending on how you count it (maybe orphan blocks which are known to be orphaned when the pool receives them are not counted).
Agreed. So both situations actually affect p2pool negatively. Assuming that the average p2pool node has lower bandwidth and lower connectivity than a big pool, it will generally receive blocks and send out new blocks slower, resulting in more orphans overall. 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
|
|
|
Hi All! I wrote a utility for remote monitoring of p2pool working. Download it here. 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
|
|
|
Do they have their executives, PR and office staff on the floor putting rigs together, or in the shipping department packing boxes? 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
|
|
|
I've updated p2pool.stitthappens.com:8336 (BTC + NMC) and p2pool.stitthappens.com:10336 (LTC) to version 3.
Mine have been updated as well. -- 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
BTCGuild recently commented on this.Some months he makes money some he loses. 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
|
|
|
Thats why I get more form p2pool than any pps Bigger cake to cut I don't see how, an extra ~.25 per block in tranactions fee's doesn't compensate for the bad luck. I've made much more mining at a MtRed (0% Fee PPS) then I ever did mining at p2pool. 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
|
|
|
(though is there any pool that charges 10%?)
DeepBit PPS charges 10% and BTCGuild charges 8%. They're the highest I know of. An they taking transaction fees to, it is 0.2-0.8 btc now each block. 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
|
|
|
... I dont want any nmc ... 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
|
|
|
Here's what I get: My servers didn't appear in your pasted code listing... imperium.getmyip.com port 9332 & 9327 (btc & ltc) -- 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 yeah the plan was always to drop it *after* i got most of the big tasks automated. micro deposits are being auto-detected now, but there are still a few more things i'd like to automate before dropping the minimum account size from 10 down to 1. 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
|
|
|
I'm offline: thirdlight.dynalias.com
check_status, can you take it off the OP? Not likely to be back in the near future.
Thanks,
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
|
|
|
|