|
Your reward method is hoppable. The expected payout per vote when there are 30 votes already submitted is much higher than after, say, 200 votes.
B.
|
|
|
|
I think it's fine that there are pools and the pool operators make decisions on what they vote, not everyone needs to use p2pool. But we definitely should have a lot of pools and more than anything, aware miners who do change their pool if the pool operator of their current pool is making a bad decision regarding his vote on Bitcoin development.
The current situation is very unhealthy where the top 3 pools have over 50% of hashing power and most of their users are totally ignorant and unaware of the major developments that are being proposed to Bitcoin right now. They should be more aware and understand that they have voting power that matters.
So, what exactly is one of those 'major developments' that is threatening to bitcoin right now? Why are you spreading such fears? Oh, I see .... hmmm who is winning other than the network which seems to be so insecure at the moment? I get the feeling though there are valid concerns about the risk, the story isn't new at all. What's different now to put it on the agenda compared to one year ago? P2pool wants capitalize out of those fear. That's what's new. People could simply switch to smaller pools if they saw necessary. Honestly, it looks like spam to me. Or do you want to tell me p2pool has 0% fees? Let me guess, p2pool is so altruistic it uses the fees to make the network securer. I'm not going to switch to anywhere unless to some TOR pool service that is DDOSing proof in the future. And I'm not buying into the guilty conscience you want to give people who are not switching. Also, it's not gonna work anyway. Fear has never been a sound long term business strategy. The major development is the vote on P2SH, and the threat is that many miners are abstaining from it rather than supporting it. p2pool isn't just a name, it really is a p2p pool (to some degree, I think it makes use of a centralized service for some of its functions). Technomage isn't its inventor or operator. If you understand why Bitcoin is better than banks you should understand the advantages of p2pool over traditional pools. The claims that p2pool is healthy for the network definitely have a legitimate basis, even though most people are missing out on some of the subtleties. Split pools with smart miners are as valid a solution to the block construction centralization problem as p2pool is, and going forward p2pool will be used directly mostly by large miners and small PPS proxy pools. Some of the factors in the way of p2pool adoption are its greater technical difficulty, and its relatively small size (and harder shares) which leads to higher variance. |
|
|
|
|
This is very location specific, and you haven't specified your location. In US there are some good options. You could use bitinstant to facilitate the deposit as Yankee suggests. I think tradehill is a bit more newbie-friendly than mtgox but both can work.
If I may say so myself, in Israel it's fairly easy to buy bitcoins, too.
Credit cards are very problematic, but I don't think it has been proven conclusively that you can't make them work by taking the right precautions.
|
|
|
|
Hmm yeah I don't have a way to donate NMC directly. How would people feel about changing the NMC On/Off to just "donating" NMC instead of not mining it? That would be easy (just remove an if/else) to code.
If you do this, make sure to clarify that this is what this option does. |
|
|
|
Blocking possible client changes because you disagree with them and have a large percentage of the networks hashing power.
Is this OK for the Bitcoin network? Allowing one person's vote to influence the entire network?
The real problem here is that miners are being assigned to vote on protocol changes in the first place. This I think is not how Bitcoin was designed to work, and sets a very dangerous precedent. Decisions should be made by majority of users weighted by their economic power. If you break compatibility and convince the typical users, the exchanges and other big players to switch, then it doesn't matter what the majority of miners have to say, they'll have to switch if they don't want their mined coins to be worthless. This is a special case of the more general problem that someone with a certain share of the hashrate doesn't have his incentives as strongly aligned with the well-being of Bitcoin as someone who has a similar share in the entire economy, simply because going forward mining is supposed to be only a small part of the economy. |
|
|
|
Eclipse I think is different?
Eclipse uses c=0.01, o=0.99, f = -0.0101... Slush just want to voice my opinion here, I mined my very first Bitcoin on your pool (and sold it for 0.85 cents! ) and mined probably in total 200 coins with you. I personally think DGM sucks and will become less popular as the difficulty continues to go up. Yes it's pool hop proof and "fair" but only really fair to a person if they want to dedicate themselves to mining with that pool and that pool only 24/7 I like your modified proportional score system - a lot of people do and I think you should stay with it , and if you really have to change, change it to a pure PPS like BTCGuild is doing. thank you for listening  Did you take the time to understand how DGM works and then judged it based on its merits, or did you just arbitrarily decide that it penalizes intermittent miners? It does no such thing. Mining with multiple pools will not reduce your rewards (and could be a good way to reduce your variance), and if you're disconnected you will only lose the worth of the work you could have done during that time. For every share you submit you get on average (Block Reward / Difficulty), that's all there is to it. For a long time slush's method has been falsely accused of penalizing intermittent miners, so in a way it's kind of refreshing to hear you acquit it of this crime. But it looks like you've just found a new scapegoat in DGM. slush's method is high variance, less hoppable than proportional, but still significantly hoppable. Geometric method is similar to slush's method, also high variance, but completely hopping-proof. DGM is also hopping-proof, but much lower variance. In fact with DGM you can have the variance as low as you want, much lower than in proportional for example - it's all in the parameters. The easy way to reduce the variance is by increasing maturity time, which I think slush can pull off because it's a big pool, so even the increased maturity time will be pretty short. PPLNS, when properly implemented, is also hopping-proof and almost as low-variance as DGM. It can be used if DGM is too complicated. In particular, I think shift-PPLNS could work better with slush's parallel architecture than DGM. PPS is definitely a possibility, and I think PPS proxy pools are the way of the future. But until the substrate for it is developed, slush would have to take great risks, which he may not want to do without significantly raising the fees, reducing the long-term gains of miners. |
|
|
|
So we have one case so far. This is a bit disturbing but at the same time I could see a withdraw slightly below the threshold being viewed as suspicious.
Is a withdrawl slightly below slightly below the limit also suspicious? This is what I was referring to. If the limit on transactions for reporting to your local tax agency is $10k and you receive some transfers for $9999.99 then that would definitely raise some red flags. You didn't get 556j's joke. |
|
|
|
... There is also another type of 'orphan' block that most don't know about due to them being rare (and I don't know if the other miners show it, but cgminer does ... I wrote that code  - also 'orphan' is not the correct word but anyway) A rejected difficulty level block (cos it's late) yet, no doubt, they certainly do have no effect on the algorithm or payout. Do you have a reference for that? This isn't possible as far as I know. ... It's not an 'impossible' issue (as I said the word 'orphan' isn't actually correct) but it's very simple: If you calculate a share that's also a block but it's rejected coz it's late: an LP occurred while you were calculating it. Like ANY normal rejected share except in this case it's also a block level difficulty. I misunderstood what you meant, now I get it. For reference, by default the correct way to deal with rejected shares in the scoring method - shares which the pool knows are invalid the moment it receives them - is to ignore them completely, for purposes of both payout and decay, even if they happen to satisfy the full difficulty requirement. Decaying for invalid blocks is only if the pool thought at first this is going to be an accepted block but it happened to be beat by a different block. (Of course, the pool could offer payouts for rejected shares as a feature, but this would cause a loss unless the op takes a fee to compensate). |
|
|
|
Seriously?
You've taken what amounts to a block that does not exist and it counts in your algorithm?
I guess that explains why the earlier discussion died.
What earlier discussion? There is also another type of 'orphan' block that most don't know about due to them being rare (and I don't know if the other miners show it, but cgminer does ... I wrote that code - also 'orphan' is not the correct word but anyway) A rejected difficulty level block (cos it's late) yet, no doubt, they certainly do have no effect on the algorithm or payout. Do you have a reference for that? This isn't possible as far as I know. Until a block is confirmed (120 confirms) it does not exist.
If blocks that get orphaned do affect your DGM, then your DGM is faulty - especially when almost all orphaned blocks are known within 1 confirm.
Like I said, that's the correct way to do it. Do the math if you don't believe me. When I have the time I'll add the relevant math to the DGM post and AoBPMRS. |
|
|
|
I'd like to see difficulty drop again soon unless someone can help me reach above 400MHash/s on my HD6950 to eek out the most performance out of it (probably best to direct me to a thread that covers this already).
I think that we should work together to force difficulty to drop again when the trends show rises in difficulty.
There is no working together. We all share the same pie. If you drop out well that is a bigger slice for me. Gimmicks and half baked ideas of "cheating" the protocol don't address the reality that mining is a zero sum competitive game. I don't know why I didn't mention this earlier given the topic of the OP. But the attack that involves the off-by-one bug in the difficulty adjustment is one where someone with >50% of the hashrate can mess with the timestamps to artificially decrease the difficulty, so instead of generating the total prescribed 7200 BTC per day, they are generated much more rapidly. So if all miners collude, they can game the system to increase the pie. But you wouldn't do that, right? See also ArtForz's original post about the attack and this StackExchange question. |
|
|
|
I don't care one way or the other how the pool calculates the average, whatever is easier is fine, I was just curious as to how it was done. Regarding the less pay, maybe I read that in Meni's thread, but I thought it was in this one, because it seems like it possibly wasn't necessarily part of double-geometric, but was part of the previous method (and I didn't read THAT threa [presumably also of Meni's]). Doesn't really matter. Maybe I misintrepreted a comment and the idea is that the score from the invlaid block is still paid, but at a lower amount since it is paid on later blocks and has decayed. As far as invalid blocks go, they are part of it, an optional donation of 3% to get paid on invalids would be optional and therefore of free will, but probably require more coding. A 3% fee and paying on invalids might make some people happy and could theoretically earn (or perhaps cost) you more in the long run, but then you wouldn't be able to call the pool 0% (per your argument on the ABCPool thread).
You remember correctly, and I think this is implemented right in EMC even if Inaba isn't completely aware of why it's right (and even if I once erroneously commented on a PM that there's a problem in need of fixing). The previous method which was the geometric method, is a special case of double geometric, so the same issue with invalid blocks applied to it (and more strongly). But I hadn't yet examined invalid blocks thoroughly at that point, so what you're probably remembering are my comments in this thread about the current method. The thing is this - DGM features block decay, which means that whenever a block is found, every worker loses a portion of his score. So the question is whether to decay for invalid blocks as if they were normal blocks, or refrain from decaying as if there was never a block at all. Intuitively you might think that the block needs to be ignored. But a closer examination reveals that this would cause unfair losses to the operator (so on a 0-fee pool he would actually lose on average for running the pool). On the other hand, if blocks cause decay as if they were valid, the loss is shared equally between all parties. So if for example 1% of blocks are invalid, every miner will gain on average 1% less than he would have if all blocks were valid, and the pool op's profits, if the pool has fees, will also be reduced by 1% of the profit. This I think is the fair solution. It just so happens that the correct solution is also easier technically, so it is what we have by default. It should also be noted that with the parameters used in EMC, block decay is very weak so the issue has little consequence one way or the other. |
|
|
|
Maybe not in the Bitcoin software (and that should be fixed), but certainly in the Bitcoin network - if there are two transactions claiming the same output (and they're not replacements or some other valid thing), that's a double spend attempt. It doesn't matter which of the two transactions end up in a block, the fact remains that the customer tried to scam you and should be held up for questioning.
You don't need to passively wait to see if your peers are reporting a transaction - you can (again, maybe not with current software) proactively query, "hey, do you know of any transaction conflicting with this transaction I have here?". If anyone says yes you know there's a double spend attempt. If after some seconds everyone says no there's a very good chance there's no such attempt. There's no need to wait 10 minutes for a block (though that of course can reduce the risk even further).
If double spend transaction is published, you can try these techniques. That's why double spend transactions will have higher success rate if it's not public at all. Double spender could form a private relationship with a pool with 10% hashing power and send double spend transaction through an alternate channel. He could effectively have 10% bitcoins back on average on all 0-confirmation spends. Am I right? Sounds about right. But a pool who does this will be quickly exposed, and in the future pools will probably not have the power to decide what goes in a block. |
|
|
|
The way I think about a bitcoin transaction is that at t0 (time zero) the risk of a double spend is fairly high…after just a few seconds, the risk drops off substantially and over time the risk approaches zero. While we aren't doing it today, our plans are to use transaction radar (probably modified a bit to incorporate other risk assessment factors) and then immediately guarantee payment for the merchant for transactions up to a certain value that aren't showing any signs of being risky after a couple seconds. Right now, we only guarantee that the merchant will get paid after a full six confirmations. That can take up to an hour and in a few cases, many hours. The merchant can decide whether the act immediately or wait on 1 or more confirmations. We've yet to have a single instance of a double spend, but that doesn't mean there isn't a risk of it.
The only reason we haven't yet implemented these things is that we're still working on building other features that are more urgent.
Sure, what I'm trying to say is that you can get a better experience with a hybrid solution. Instead of having the customer wait 10 seconds until the risk you have a double spend is 0.01%, have him wait 1 second until the risk is 1%, and maintain the option to alert the merchant in case a double-spend is later detected - so he can sort it out with the customer. I agree completely that this kind of thing isn't a high priority right now. In the bitcoin network (and the bitcoin client software), there's nothing that tells you "this transaction is a double spend"…until there's a block that contains transactions that conflict with yours, you don't know for sure…you're just dealing with probabilities until then. If a significant number of peers aren't reporting a transaction, it's an indicator that they might consider the transaction invalid. There are other things you can look at to assess risk outside of the bitcoin network itself (perhaps it's a customer you've transacted with many times before…that would be another risk mitigator). What you describe is basically what we do today…the merchant has the option to accept a transaction immediately and we will alert him if we later determine a transaction to be invalid. It just that the merchant's risk doesn't go to zero until after 6 confirmations and we would like to dramatically shorten that timeframe in the future (such that for 99% of all transactions, the merchant's risk goes to zero in 3 seconds or less). Maybe not in the Bitcoin software (and that should be fixed), but certainly in the Bitcoin network - if there are two transactions claiming the same output (and they're not replacements or some other valid thing), that's a double spend attempt. It doesn't matter which of the two transactions end up in a block, the fact remains that the customer tried to scam you and should be held up for questioning. You don't need to passively wait to see if your peers are reporting a transaction - you can (again, maybe not with current software) proactively query, "hey, do you know of any transaction conflicting with this transaction I have here?". If anyone says yes you know there's a double spend attempt. If after some seconds everyone says no there's a very good chance there's no such attempt. There's no need to wait 10 minutes for a block (though that of course can reduce the risk even further). |
|
|
|
The way I think about a bitcoin transaction is that at t0 (time zero) the risk of a double spend is fairly high…after just a few seconds, the risk drops off substantially and over time the risk approaches zero. While we aren't doing it today, our plans are to use transaction radar (probably modified a bit to incorporate other risk assessment factors) and then immediately guarantee payment for the merchant for transactions up to a certain value that aren't showing any signs of being risky after a couple seconds. Right now, we only guarantee that the merchant will get paid after a full six confirmations. That can take up to an hour and in a few cases, many hours. The merchant can decide whether the act immediately or wait on 1 or more confirmations. We've yet to have a single instance of a double spend, but that doesn't mean there isn't a risk of it.
The only reason we haven't yet implemented these things is that we're still working on building other features that are more urgent.
Sure, what I'm trying to say is that you can get a better experience with a hybrid solution. Instead of having the customer wait 10 seconds until the risk you have a double spend is 0.01%, have him wait 1 second until the risk is 1%, and maintain the option to alert the merchant in case a double-spend is later detected - so he can sort it out with the customer. I agree completely that this kind of thing isn't a high priority right now. |
|
|
|
If BTC drops to 2-3$ again - the miners are screwed, they don't have an option to sell even if they see it coming - especially the ones who are buying FPGAs.
Perhaps the gold-rush miners (not to be confused with BTC miners) should take bitcoin for what it really is—a unit of account—and buy something with it rather than selling it via "market makers". If bitcoin today was treated more as a currency and less as a "perishable gold" (more on that in some other time), the transaction fees + bounty per block would keep the costs of mining well below $1.00 per bitcoin. Are you aware that mining cost is proportional to the difficulty, which is proportional to the total computation power of all miners, which is influenced by the profitability of mining? So if mining is too profitable, more people will mine, making it less profitable? It's a self-balancing adjustment mechanism. |
|
|
|
Well since you are physically in the restaurant while you are making this purchase, and doing it from your own mobile phone, I assume the restaurant will handle the situation just as if you tried to pass off a $3 bill or a Nigerian credit card.
That is to say, you could be:
1. taken out the back door and promptly beaten by the staff
2. kindly asked to pay another way
3. told never to come back again
or probably all of the above.
The restaurant can do all these things, but only if it knows you attempted a double-spend. Is the app able to detect double-spend attempts and inform the server of them? Successfully executing a double-spend from a mobile wallet, while you are face-to-face with the other party, is very difficult, but I suppose people will try. But we can monitor the network to watch transactions propagate. Merchants can choose to wait for 1 block or 6 blocks if they prefer, but for a low-risk in-person transaction, this is not really necessary. Yeah, I don't think it's a very big risk, but we can't write it off entirely. People can use a modified mobile wallet app which automatically tries to double spend, so even looking exactly at what they do you wouldn't know it. It takes only a few seconds to detect on the receiving end, but I think it's important (maybe not with v1 of the software, but eventually) that the detection is performed, so that when there is a double spend the app flashes "The customer double-spent! Get him!" |
|
|
|
Well since you are physically in the restaurant while you are making this purchase, and doing it from your own mobile phone, I assume the restaurant will handle the situation just as if you tried to pass off a $3 bill or a Nigerian credit card.
That is to say, you could be:
1. taken out the back door and promptly beaten by the staff
2. kindly asked to pay another way
3. told never to come back again
or probably all of the above.
The restaurant can do all these things, but only if it knows you attempted a double-spend. Is the app able to detect double-spend attempts and inform the server of them? |
|
|
|
This is ridiculous. Of the 3 people who posted after me in that thread:
remmy (the op) understood what I said, up to some technical details.
iamzill probably didn't understand. His loss, my suggestion solves his suggested failure mode and I explicitly addressed it.
BitOffer presumably understood what I suggested, as he referenced it.
My "overly complicating the idea" was written in a way that makes it precise who gets what in which conditions. It was designed to solve the problems raised earlier in that thread - some of which you will probably only realize after some more chats with your IRL friend.
Might wanna relook who the OP is. I meant the OP of that thread, who is of course distinct from the OP of this thread. |
|
|
|
What I was/am missing is the formula that says how the next target is calculated. I tried the wiki but didnt find it  did you take the calculation from the source code? N = New difficulty (at block 2016N) O = Old difficulty T2 = timestamp of block 2016N - 1 T1 = timestamp of block 2016N - 2016 N = O * (2 weeks) / (T2-T1) Of course, in actuality the calculation is based on target, new target = old * (T2-T1) / (2 weeks) and the difficulty derives from it. I didn't see the code for this but I'm guessing first an integer division by 1209600 (seconds in two weeks) is done and then the multiplication. There's also the [1/4, 4] limit. There's actually a bug in this calculation, it should have used T1 = timestamp of block 2016N - 2017, and this bug makes possible a form of attack. But at this point it is considered not worth correcting it. It's supposed to be explained at https://en.bitcoin.it/wiki/Difficulty#What_network_hash_rate_results_in_a_given_difficulty.3F but maybe it's not very explicit. Also see http://bitcoin.stackexchange.com/questions/855/what-keeps-the-average-block-time-at-10-minutes. EDIT: Here's the relevant piece of code (from main.cpp). It appears the bignum used can handle doing the multiplication first and then division: static const int64 nTargetTimespan = 14 * 24 * 60 * 60; // two weeks
static const int64 nTargetSpacing = 10 * 60;
static const int64 nInterval = nTargetTimespan / nTargetSpacing;
...
// Go back by what we want to be 14 days worth of blocks
const CBlockIndex* pindexFirst = pindexLast;
for (int i = 0; pindexFirst && i < nInterval-1; i++)
pindexFirst = pindexFirst->pprev;
assert(pindexFirst);
// Limit adjustment step
int64 nActualTimespan = pindexLast->GetBlockTime() - pindexFirst->GetBlockTime();
printf(" nActualTimespan = %"PRI64d" before bounds\n", nActualTimespan);
if (nActualTimespan < nTargetTimespan/4)
nActualTimespan = nTargetTimespan/4;
if (nActualTimespan > nTargetTimespan*4)
nActualTimespan = nTargetTimespan*4;
// Retarget
CBigNum bnNew;
bnNew.SetCompact(pindexLast->nBits);
bnNew *= nActualTimespan;
bnNew /= nTargetTimespan;
|
|
|
|
|
Show Posts
