dwolla was key to mtgox's popularity, without dwolla, mtgox is just another hard to get fiat into exchange.
Good point. |
|
|
|
What is this divergence you speak of? They look like they are following each other very closely... ?
A/D has maintained a stronger uptrend than OBV. |
|
|
|
Now that I've had some time to think about it I'm convinced my idea for equalizing variance won't work without punishing new address when they first show up on the network. Without such a probationary period, people could mine to as many separate addresses as they want. Even with a probationary period it might make sense to mine to several addresses if we don't get the incentives quite right. If you are badly connected to any pool you will have many stales. I still don't see how p2pool is any worse in this respect. I'll concede it has problems with SOME ASICs.
I'm afraid this is not true. Regular pools give you 30 seconds to submit a share. p2pool uses the first share it finds of a certain difficulty, and you have to build on top of that. So you need to race to be the first in p2pool in rounds that last 10 seconds. You have 30 seconds on a regular pool and you don't have to race any peers. p2pool is greatly affected by your connectivity, regular pools are not Those who get the shares first will always have an advantage. I'm not sure it is possible to remove this advantage unless you somehow punish peers who have low latency. Increasing the share time to 30 seconds would address the other concern. But, yes, it is harder to maintain a sufficiently connected p2pool instance. It is really easy to be sufficiently connected to a centralized pool or a particular p2pool instance. The reason I've been making all my posts are simple: My message to you is think outside the box: Do not make just another bitcoin clone. p2pool did it, and it works fine but we see it has some drawbacks. If you're going to create another implementation of the same basic idea, you're going to end up with the same problems. I am not telling you I know the answer. This is a difficult question to solve. But if you want to start an alternative to p2pool, make sure you use a totally different way of thinking so you will have a product that doesn't work the same way so you have your own advantages (and perhaps disadvantages) over p2pool. Let me be clear. I'm not here to replace p2pool. I believe that most of the problems people have with p2pool are possible to overcome without changing the fundamental design. My posts are to help you guys understand the technicalities of what you are attempting to do. |
|
|
|
You need to think of the glass half full instead of half empty.
If the price completely bottomed out all the way to $2 again we would all get to buy more coins and see the Winklevoss twins on TV with some seriously brown stains on their underwear. LOL
1/2 water, 1/2 air The glass is always full. |
|
|
|
Nobody likes bitcoins anymore. It turns out they were a dumb idea  . |
|
|
|
If you are badly connected to any pool you will have many stales. I still don't see how p2pool is any worse in this respect. I'll concede it has problems with SOME ASICs.
I'm afraid this is not true. Regular pools give you 30 seconds to submit a share. p2pool uses the first share it finds of a certain difficulty, and you have to build on top of that. So you need to race to be the first in p2pool in rounds that last 10 seconds. You have 30 seconds on a regular pool and you don't have to race any peers. p2pool is greatly affected by your connectivity, regular pools are not Those who get the shares first will always have an advantage. I'm not sure it is possible to remove this advantage unless you somehow punish peers who have low latency. Increasing the share time to 30 seconds would address the other concern. But, yes, it is harder to maintain a sufficiently connected p2pool instance. It is really easy to be sufficiently connected to a centralized pool or a particular p2pool instance. |
|
|
|
"The great achievements of civilization have not come from government bureaus. Einstein didn’t construct his theory under order from a bureaucrat. Henry Ford didn’t revolutionize the automobile industry that way." - Milton Friedman
My point is that looters won't beat Satoshi. He is the man who said that he would stop the looters of the world.
And he did.
The notable exception is of course the Internet. The government commissioned it after the universities developed their networks. |
|
|
|
Wow I hope you're enrolling your kid in college early and getting him violin lessons. That's impressive that at age 2 he can already comprehend bitcoin and general market dynamics. A lot more than can be said about a lot of the members of this forum  This. Your son is a genius. |
|
|
|
Fundamentally, it comes down to a tradeoff between high stales and high variance. If you slow down the share rate, it is much harder to find a share and variance will go through the roof. In order to keep everyone happy from big miners to small, we need a tiered system. This is actually what I am working towards with my proxy project, but you seem to want to throw out everything already built and start from scratch rather than work incrementally towards a system that suits everyone. Yes, I want the lower tiers to eventually be decentralized, but I need to work out the kinks in just proxying to an unmodified p2pool for now. Ultimately, we need to allow multiple addresses to take credit for p2pool shares rather than a single address per share. Once this is in place, we can have second tier pools that submit p2pool shares that pay out based on their easier share chain. A centralized proxy is just a first step towards this vision and will help us understand a part of the target system that is achievable today. Then there is the issue of BFL ASICs. Once we have a tiered system, we will be able to lengthen the share time on p2pool to something acceptable for all hardware and the second tier pools can provide easier shares and lower variance.
|
|
|
|
|
Contradicting myself, one possibility if we did throw out p2pool would be to have the pool hand out per address difficulty requirements and then ensure the share rate from that address matches what they expect. Then we allow a constant number of shares per address per time, regardless of how much hash power is producing it. If course, there will be variance in the share rate, and that means that it we will have to use stochastic models to "ensure the share rate matches what we expect". This might leave the payout system open to some sort of gaming, but I need to think about it some more.
This would result in every participant seeing the same variance no matter their size, but every new participant raises the variance for everyone.
|
|
|
|
p2pool's high "stales" actually don't hurt payout one bit. If a block is found, but it is "stale" for p2pool, it is still a valid bitcoin block. It will still be broadcast and p2pool miners will earn the reward. As long as you don't have more stales than the average p2pool miner you will not lose because of the higher level of stale p2pool shares.
There is however an issue with BFL miners because they can only change work once every 5 seconds. From what I've read the other ASICs work fine with p2pool and I can confirm no issues with ASICMiner hardware.
I don't agree. Yes indeed, if the block is "stale" for p2pool it can still be a valid bitcoin block. Therefore this particular issue doesn't hurt p2pool in regards to what the pool will earn in bitcoin (altough the 2nd post I did should influence) But regardless, if you are badly connected to p2pool, you will have many stales, so yes, the bitcoin blocks you find will not be punished by that effect, but the p2pool shares will be. And if you can find less p2pool shares, then you will automatically earn fewer coin.... If you are badly connected to any pool you will have many stales. I still don't see how p2pool is any worse in this respect. I'll concede it has problems with SOME ASICs. Fundamentally, it comes down to a tradeoff between high stales and high variance. If you slow down the share rate, it is much harder to find a share and variance will go through the roof. In order to keep everyone happy from big miners to small, we need a tiered system. This is actually what I am working towards with my proxy project, but you seem to want to throw out everything already built and start from scratch rather than work incrementally towards a system that suits everyone. Yes, I want the lower tiers to eventually be decentralized, but I need to work out the kinks in just proxying to an unmodified p2pool for now. Ultimately, we need to allow multiple addresses to take credit for p2pool shares rather than a single address per share. Once this is in place, we can have second tier pools that submit p2pool shares that pay out based on their easier share chain. A centralized proxy is just a first step towards this vision and will help us understand a part of the target system that is achievable today. Then there is the issue of BFL ASICs. Once we have a tiered system, we will be able to lengthen the share time on p2pool to something acceptable for all hardware and the second tier pools can provide easier shares and lower variance. I still don't understand why we should throw the baby out with the bathwater when there is a clear path to achieving the variance and stale share characteristics we desire for every size miner. |
|
|
|
One of the "problems" with bitcoin is block propagation. Once a block is found, every other node needs to receive the block and mine on top of it. If you don't mine on top of the longest chain, you will loose, and basicly, your block will become stale (sometimes called orphan)
To calculate the chance of this happening - anyone can jump in and correct my math: we have the following formulla: p/i
p would be the time it takes to propagate a block over the network, and i would be the interval time. If we look at bitcoin, the value for i would be (on average) 600 seconds, as every 10 minutes a block is found. Let's say it takes 5 seconds to propagate over the network: we would have 5/600, which means 0.8% of the time you are mining, that you are at risk of not being on the longest chain, and that you will create orphans, and if you find a block the same happens in reverse, someone else might build upon your block and causing your block to have a chance to be orphanned.
p2pool uses the same algorithm as bitcoin, only in a smaller version, their "blockchain" has an interval of 10 seconds. Since the network is smaller, the propagation times are lower/better, but still, if it would take 1 second, you're down to 10% chance of finding a stale.
So unless my math is wrong, it is clear that shorter rounds will lead to higher stales.
So, anything "new" should find a way to use longer rounds inside the p2p network to make sure the stales are reduced.
p2pool's high "stales" actually don't hurt payout one bit. If a block is found, but it is "stale" for p2pool, it is still a valid bitcoin block. It will still be broadcast and p2pool miners will earn the reward. As long as you don't have more stales than the average p2pool miner you will not lose because of the higher level of stale p2pool shares. There is however an issue with BFL miners because they can only change work once every 5 seconds. From what I've read the other ASICs work fine with p2pool and I can confirm no issues with ASICMiner hardware. |
|
|
|
|
This is targeted at those who don't want to maintain a bitcoin daemon and p2pool instance. I can potentially spin up as many proxies as I want that point to as many different p2pool instances as I want. I just need to aggregate the share records to calculate the payment. This will allow for more ddos resistance than any individual p2pool instance or centralized pool.
|
|
|
|
|
I suggest you put together a list of weaknesses you see in p2pool. Other than the fact is is written in python, I don't see why we should completely throw it out. If there are fundamental problems with the design how do you intend to overcome them?
Overall, I'm not opposed to a separate p2pool effort, however it would need significant advantages over the existing p2pool to be viable. Currently p2pool is struggling to produce 5 blocks a week., so I'm not sure there is as much demand as you suggest.
|
|
|
|
But we have already had that! It bottomed at $54.25, then some days afterwards also at $50.01
Anyone wanting to buy below $60 should be fully loaded up.
I never said I agreed we would see a repeat of 2011, just explained how it would play out if we did. I've got a little more fiat to deploy, but I'm happy if it rises from here. If the bears find some favor, that's cool with me too. |
|
|
|
no impossible
this could be 2011 all over again.  what do you guys think right now? it could be, right? Previous ATH before 2011 run up was $1. Bottom after was $2. If we repeat 2011, $60-64 is the bottom. But that all depends on the bears being able to break $92. |
|
|
|
I am developing some mining proxy software that allows me to pool p2pool shares from multiple users together to the same address. This allows miners with less hashing power to use p2pool with less variance. This is alpha quality software and I will be doing manual payouts for now. Payouts will be proportional. Please do not use this pool without a fallback since I may restart it frequently. There are no public stats at the moment, but that is certainly on the TODO list. At the moment, the best you can do is monitor the pools genearation address (1B1kSM3KfcP9BvGDC1G3cxZAV9LbxovpQi), which will include everybody's hashpower:: http://pool.yrral.net:9339/static/graphs.htmlThe goal of this project is to bring more interest to p2pool and also keep it accessible to small miners. In order to mine, connect to pool.yrral.net:9339 with your bitcoin address as your username. Password can be anything. If you are using cgminer, you will see "Accepted untracked stratum share" instead of the normal message, but rest assured your shares are being tracked. Also, if I restart the proxy you may see a message about shares being lost that you can safely ignore. Fine print: My p2pool instance is currently set to collect a 2% fee. Payments will be made biweekly on Mondays and Thursdays at noon EST and will include any p2pool payout that has reached 120 confirmations. If your payout is below the dust limit for the bitcoin network, your payouts will be accumulated until they exceed the limit (if a transaction has an output that is too small it will not be relayed or included in blocks by most nodes). |
|
|
|
I nominate a query about mining a small amount on p2pool in order to keep it finding at least a block a day. In fact, with p2pool, if they are able to mine more efficiently than the average, they can potentially earn more than solo mining.
P2pool currently has a 30.2 hour average block time. Helping keep p2pool alive is beneficial to the community and if the operators can achieve lower latency than the average the payout should beat solo mining[1]. 1. http://p2pool.me/payment-system/ |
|
|
|
So jalapeno p2pool yes or no?
No (see my guide for why). And... that's even worse.... *looks for guide* EDIT: OK, so the main problem with using BFL ASICs is the latency, which is made an issue by p2pool's 10-second share window. I don't know how popular the other ASICs are, but I would think p2pool needs as much hardware (especially powerful hardware) as it can get if it's going to remain a viable option. Has anyone brought up the idea of increasing the share window, even up to a full 1 minute? Wouldn't this effectively squash the hardware latency issue (and fix one or two other issues as well?) Pooled proxies would allow p2pool to operate with larger difficulty shares and maintain low variance for end users. |
|
|
|
Anybody noticed that p2pool's hash rate has plummeted by about 30% in the last week ? Even more significant is the decline in the number of participants.
Beginning of the end of Bitcoin ?
Well, that sucks. I just got my Jalapeno today. It's hooked up to BitMinter at the moment (I liked their fees and policies) but I had planned on figuring out how to use p2pool with it. And really, I see little reason not to still do so, provided the collective hash rate doesn't drop too low. I'd probably be fine with one or two blocks a day. I know I won't be generating much soon anyway, but I'd still like to support the concept of p2pool for as long as possible. *rolls up sleeves* The reason I asked the question above is because I'm working on a mining pool proxy for p2pool. Basically, it records the shares you submit under your address, but it actually submits them to p2pool under the pools address. When p2pool finds a block, I can make payouts based on shares submitted. The aim is to help increase the total hashpower of p2pool by giving smaller miners the ability to contribute and receive reasonable variance. I'm running some tests now, but hopefully I will open it up to a few testers within the next week. |
|
|
|
|
Show Posts
