|
Jared, does Paxum shield you guys from fraud? In other words, will they uncredit a user to user transfer if the ACH transfer was reverted? (like what Dwolla did)
|
|
|
|
The problem is bitcoin is a hard currency, and any attempts to hook it up to the soft currency system (a.k.a. banks where almost everything can be charged back) means that there are going to be gaps created that people will take advantage.
This is an issue/problem with the current banking system, a lot of the fraud that happens today is only possible because of the current broken banking system.
There's actually no reason the banks couldn't create a system where transactions really are irreversable. The trouble is that no-one would want to use it: either they'd have to require all transactions to be made at branches after presenting proof of ID and paying a fee to cover the associated costs, or customers would have to accept that their account could be emptied out by crooks at any time for reasons beyond their control. There's no way they could swallow the cost of fraud otherwise. It turns out that it's cheaper for everyone involved if they skip the really expensive security measures and just include a way to reverse transactions. Ironically, that's exactly what bitcoins is trying to solve. Transferring bitcoins is non-reversible. But then that also means if someone breaks into your wallet and steals your coins, you are screwed. I'm not sure if there will ever be a solution that can satisfy both needs at the same time. |
|
|
|
21k is the next difficulty.
Nope, look at the post just above yours  Well, when he checked, it showed 21k. But that was not my point, so I didn't bother fixing that number and confuse the issue. |
|
|
|
This will be the last post I make in this thread.
Best of luck BitcoinEXpress, I'm glad you took the advice. LOL! Now that was funny! |
|
|
|
It's that I want people to think I know more, it's just that I do know more about the VC world than 99.99999% of you posting here.
Wouldn't a VC be aware of the significance of each digit? There are not one hundred thousand people posting here - should have simply put 100%. The fact that you made up a number shows me you know little about money, and in fact are just a troll trying to protect Dwolla's fraud. PSY, I wish you would determine this guy's forum worth as a mod, and act on it.  Actually 99.99999% means that out of 10 million people, he would know the most about the VC world. Let's see... population of US is a bit over 300 million. That means in all of US, there's only about 30 people that knows more about the VC world than him. I call bullshit!  BitcoinEXpress, either your math is bad or you are a super VC. If the latter, who are you, and which VC firm do you work for? If the former, then try not to fund a startup a billion dollars when you meant to fund them a million dollars. :p |
|
|
|
The current difficulty (94k) makes NMC really not worth mining... why still do it??
Where do you see current nmc diff is 94k ? According to http://dot-bit.org/tools/nextDifficulty.php it is just 21k Am i missing something ? There's a reason why that site is called nextDifficulty. Though I do agree that the site is a bit confusing. 21k is the next difficulty. Look at the first row for the current difficulty. |
|
|
|
Maybe I missed while skimming the thread, but has anyone tried this on 69xx series hardware?
Curious if this gets around the 'memory clock must be >= gpu clock - 125mhz' issue..
Someone indicated in another thread they were able to use it successfully on a 6990, I'm more curious about 6950 / 6970's
I've tried this on my 6970 and no, it doesn't get around that issue. I still have to set memory clock >= gpu clock - 125. But this tool is definitely easier to use than aticonfig. |
|
|
|
|
I just got it running on my Mac. I needed to install the latest python and change the login credentials in main.py.
Looks good!
|
|
|
|
A *MPPS pool with a positive buffer is always better than one with a negative buffer if all else is equal. I'm not denying that. RSMPPS makes it better, but it's still a problem.
All payout methods has their own problems. If there was a perfect one, we wouldn't be discussing this anymore. But in my opinion, *MPPS pools are more fair and RSMPPS does the best job at not causing miners to quit when the buffer goes negative.
Well, the only problem with geometric scoring is that it is not really user friendly (hard to understand for average users), and a bit processor intensive for the server. The only problem with PPLNS is a little weirdness around difficulty changes. If you account for this with some pretty easy scoring, it works perfectly. And I think PPLNS is quite user friendly. So I contend that there is better out there. PPLNS might be better in terms of easy to understand and no disadvantage for previous bad luck. I still have the issue with it where it feels unfair for non-fulltime miners. |
|
|
|
|
A *MPPS pool with a positive buffer is always better than one with a negative buffer if all else is equal. I'm not denying that. RSMPPS makes it better, but it's still a problem.
All payout methods has their own problems. If there was a perfect one, we wouldn't be discussing this anymore. But in my opinion, *MPPS pools are more fair and RSMPPS does the best job at not causing miners to quit when the buffer goes negative.
|
|
|
|
I am specifically looking for waterblocked cards, but I do have two Koolance reference version 1.1 waterblocks for 6970/6950s. Will your cards work with this waterblock? http://www.koolance.com/water-cooling/product_info.php?product_id=2021To save on shipping/weight/etc., it would be awesome if you could remove the current cooling units. I won't need them. I'm hoping for a win-win with someone who is getting out of mining and has liquid cooled kit that can be difficult to move on Craigslist. I'd like to save some money due to the heavy use of pre-owned mining cards and the fact that waterblocks are super-overpriced because of the low production volumes but they don't re-sell very well. I think if I had a set of DWG/DXF files I could source and mill the waterblocks myself for a lot less. :-) I'm ranting now, and as a software guy, I understand that the incremental costs are low but the up-front cost is high. The market is the market! Thank you! Sorry for misreading. My cards are not waterblocked. I don't know if they will work with your waterblocks or not. I am in the SF bay area also. So we could meet up if you are interested. |
|
|
|
|
I'm in the market to purchase a few 5970s. Anyone selling? Or want to trade for 6970s?
|
|
|
|
True.
In a *MPPS pool you get paid the expected payout in the best case and less in the worst case.
On Prop. you get paid far more than expected in the best case and far less in the worst case (which evens out if there are no hoppers).
Scored/PPLNS is similar, you can have "lucky" shares and "unlucky" shares that are worth more/less than others, it's just not predictable, so you can't hop.
All in all:
As soon as a *MPPS pool gets close to 0, better make a run for the hills and switch pools (if you are a careful miner). RSMPPS seems especially dangerous at the beginning of a loss period (when approaching 0 buffer).
Please explain why RSMPPS is especially dangerous. |
|
|
|
To clarify, this may be what people are missing.
You think that it is fair because at worst, you end up getting paid as if it were a proportional pool.
However, proportional pools are fair because you get the benefit of short rounds to even out the pain of the long rounds.
PPS is fair because you get paid 'what you deserve' even during long rounds, but you actually lose out on short rounds.
So a pool that gives you the payment of a PPS pool on short rounds with the payment of a proportional pool on long rounds should be avoided at all costs.
And that is exactly what a *MPPS pool is if it is significantly 'behind'.
This is only the case for the worst case scenarion. Let's use an example where L is for long rounds and S is for short rounds and we have even luck for this whole time frame. And assume the pool has a huge negative buffer (i.e. significantly behind). If the scenario is SSSSSSSSSSLLLLLLLLLL (10 short rounds, then 10 long rounds) Then yes, all the initial short rounds will be paid at PPS and the extras will be used to payoff the negative buffer. In this worst cast scenario, those short rounds are paid only PPS. And the long rounds are only paid proportional. If the scenario is LLLLLLLLLLSSSSSSSSSS (10 long rounds, then 10 short rounds) Then the long rounds will be paid proportional and the difference will be added to the negative buffer. When we hit those short rounds, the extras (over PPS) will be used to pay off the recent long rounds. So in the end, you will paid the PPS reward for each share in this timeframe. And for the average case of LSLSLSLSLSLSLSLSLSLS It works out well too since each short round would pay for the last long round. So yes, a negative buffer is not good (because the next short round will be used to payoff the buffer), but it's not as bad as you think. |
|
|
|
If you do traditional PPLNS (without scoring) it is still quite fair (compared to things like *MPPS and Proportional), and it doesn't obfuscate anything. It is incredibly simple.
I would love *MPPS as a miner, because I know exactly which pools to mine from, but I would never run one, since it will just take one bad string of luck to put you out of business if your miners are looking to maximize profits.
I agree that PPLNS is simple and quite fair, but as a miner, I'm wary of mining at a PPLNS pool. Although I believe it's statistically fair, I don't like the fact that if I don't mine 24/7, my luck will play a lot into my earnings. I will be constantly afraid to take my miners down b/c the pool my run into 5 blocks in a row after N/2 shares (or however many) and I will be paid nothing. As a miner, I would actually prefer a RSMPPS pool (even with negative buffer) than a PPLNS pool, but that's just me. |
|
|
|
So I may have missed something in the last three pages, but I don't see how this really fixes anything.
You correctly pointed out the issue with SMPPS, but even with your system, I don't see the difference.
Let's say you are running a RSMPPS pool that 'is behind'. I am a miner that is looking to be paid fairly.
There is another SMPPS pool out there that 'is ahead' (or some other cheat proof pool, or solo mining, or whatever).
Which am I going to choose?
This round there is a 50% chance that we will solve a block in < N time (where N is difficulty).
There is also a 50% chance that we will solve a block in > N time.
If I enter the 'fair pool' (cheatproof or SMPPS that 'is ahead') my expected earnings from mining here are exactly what they should be.
If I enter the RSMPPS pool, my expected earnings are lower because:
+ If we solve the block in more than N time, I will be underpaid for my shares
+ Not only that, but if we solve several blocks in a row slowly, it makes it even less likely that I get paid what I am owed in a reasonable amount of time.
+ Not only that, but a logical person would never mine at a *SMPPS pool that 'is behind', because of point 1 and 2, so they would quit and you would actually end up NEVER getting paid.
Does this make sense, or am I missing something?
You argument is flawed b/c if you assume that you are solving blocks slowly for an extended time, you will get paid just like a proportional pool. How is that worse than a normal prop pool? Yeah, sure it might take a while (until pool gets lucky) for you to get paid your total PPS reward, but at least there's a chance you will get paid. The problem with any *SMPPS pool is that if there is a bunch to choose from, you would always choose the one that has a positive buffer. So it may lead to pool hopping due to buffer size. RSMPPS does a better job in alleviating that but not fully. |
|
|
|
Vlad offers to mine for any pool for 0 variance + 10% extra with up to 50 GH/s. It would hurt any pool, yes - but most of them just for a short time: PPLNS for N shares, Prop + Scored for 1 round, pure PPS would just hurt the operator... But with *SMPPS the whole pool gets hurt for quite some time potentially.
Your point is valid against SMPPS but no so much against RSMPPS. With RSMPPS, the rewards are paid out to recent miners first. So the pool is not burdened by old debt. The only downside with a negative buffer is that if you get lucky in the future, you will payoff the old miners instead of building up a positive buffer for the future. In reality, I cannot imagine anyone would do this to a pool. In order to cause a pool to build up a negative buffer, that person would have to pay Vlad that same amount plus 10%. So if you wanted to cause a SMPPS to get a negative 100 btc buffer, on average you would have to pay Vladimir to mine 2 blocks worth of work + 10%. So that's 110 btc or $1500. Even then, a negative buffer of 100 btc is not that much to recover from statistically. |
|
|
|
So if you stop mining, you know exactly how much you lose out (expected share * reward per share). But if you keep mining you never know when (if?) you get paid fully. (only "eventually") Also a serious withholding attack (can be done right now by writing a proxy and paying Vladimir to point 50 GH/s your way) will lower the reward per share significantly (down to prop.), if I got the concept right. You will get paid fully on the next block, unless it's a long round and there's no saved up buffer. In that case, you will get paid when the pool gets lucky again. In the RSMPPS case, if that never happens, you at least got paid as much as you would have if it was a proportional pool. So are you saying Vladimir can mine at this RSMPPS pool and withhold winning shares? Basically sabotage the pool such that Vladimir will never help find the winning block. So chances are that it will lead to a long round. And miners will only get paid proportionally. In that case, it hurts Vladimir also. And why would Vladimir wanted to do that? And if someone else is paying Vladimir to do that, yes that would hurt the pool. But tell me which pool wouldn't be hurt by this withholding attack? |
|
|
|
|
Show Posts
