Bitcoin Forum
May 25, 2024, 05:47:10 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 [132] 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 »
2621  Bitcoin / Mining / Re: Pool hopping... ethical or n on: July 27, 2011, 01:10:05 PM
You've still not addressed my question, you say that I've entered an agreement with business partners when I mine on a pool. But no one has made clear the parameters of that supposed agreement (other than what is laiad out in proportional payment structure)? When am I allowed to back out? When can I switch? Once I enter into this so called agreement am I bound to it forever? Can I never change my mind?

The problem with "implied agreements" is that there is no clear basis to them. Your side of the agreement is not the same as mine unless we explicitly state it as so. If I can switch pools after 24 hours, why not 12, or 6, or as often as I want? Where is the line, how are you defining it?
I don't think there's a "line", there are various courses of action each with its own degree of "unethicalness". But I think that if you start mining for a pool with the intention of obtaining payouts in proportion to the contribution, and then for whatever reason you decide the pool is not for you, you're free to go. The problem starts when the reason you joined the pool in the first place is to obtain a payout greater than your contribution. Clearly if you use hopping software to hop dozens of times a day then this is your intention.

As for the namecoin hopping, a major difference is the lack of a reference "fair" reward. For pooled mining as a phenomenon in the larger Bitcoin mining world, it is clear that the fair payout per share is pB, and that any amount above it is freeloading (remembering that every share submitted to a pool ultimately translates to increased security of the Bitcoin network). But Namecoin and Bitcoin between them are not part of a larger context which defines what the fair payout is. Furthermore, a decrease in a blockchain's difficulty generally means that its security is lesser now, and hence adding capacity to it is more beneficial. So it is acceptable for market forces to drive capacity to where it's most valuable.

Everything you do in bitcoin to enhance your stake diminshes someone elses.
...While creating value. Buying Bitcoins leaves the other party with dollars which he finds more valuable than Bitcoins, and buying mining rigs increases Bitcoin's security.

Hopping isn't stopping anyone else from doing anything, it is not some secret ploy, does not rely on deception or coercion or any other inherently unethical practice.
It relies on taking advantage of people who don't know any better. But as I said it's not black and white, and hopping is acceptable if it is accompanied by genuine attempts to educate the public.
2622  Bitcoin / Mining / Re: Pool hopping... ethical or not? on: July 27, 2011, 10:16:35 AM
As interesting as the points have been so far between both sides (and I am now thoroughly confused as to what I personally feel on the subject), it's only an issue for slow pools and thus virtually irrelevant.  If you were always on deepbit, you'd be 'pool hopping' for what-- 10 seconds?
If deepbit is half the network, average round length is 20 minutes. So when a round starts (if a block is found from an unknown source, it's probably deepbit), you stick around for 8 minutes which is plenty.

You don't hop one pool, you hop between all proportional pools simultaneously.

Those who earn x2 or so of the normal income will disagree that it's irrelevant.

So you just disconnect automatically every 1 minute and connect to the next pool, then back and forth, over and over again?
You always mine for the pool with the lowest number of shares in the current round. If all pools have >43.5%*difficulty you mine in a fair pool or solo. This is all done automatically of course, using something like the python pool hopping proxy.
2623  Bitcoin / Mining / Re: Pool hopping... ethical or not? on: July 27, 2011, 09:18:57 AM
As interesting as the points have been so far between both sides (and I am now thoroughly confused as to what I personally feel on the subject), it's only an issue for slow pools and thus virtually irrelevant.  If you were always on deepbit, you'd be 'pool hopping' for what-- 10 seconds?
If deepbit is half the network, average round length is 20 minutes. So when a round starts (if a block is found from an unknown source, it's probably deepbit), you stick around for 8 minutes which is plenty.

You don't hop one pool, you hop between all proportional pools simultaneously.

Those who earn x2 or so of the normal income will disagree that it's irrelevant.
2624  Bitcoin / Mining / Re: help me with the folks on: July 27, 2011, 09:02:53 AM
why do i want to mine? (help me find the best answer)
1. Because you want to be a part of an incredible new technology that could change the world.
2. Because you want to utilize your existing resources to receive a source of income.

im worried it will slow our internet down (can someone help me with this?
It shouldn't slow down your internet at all, the bandwidth needed for pooled mining is negligible.
2625  Bitcoin / Mining / Re: Pool hopping... ethical or n on: July 27, 2011, 08:45:46 AM
you are not getting 40x (your shares/total shares) while the hopper is getting 50(his shares/total shares) plus 10 (you shares/total shares). it just aint happening.
If you count all shares across different rounds together, then this is definitely what's happening, you get 40 x (your shares/total shares) while the hopper gets 60 x (his shares/total shares)

you go into a pool with the expectation of getting 50x (your shares/total shares) which is what you get and what hoppers get.
And with the expectation that this arrangement will lead to the same ratio when calculated for pool work in total, not just within rounds. Just because people are ignorant and don't understand that you're scamming them doesn't mean it's ok.

you assume people join a pool for aligned interests? and not to reduce their personal variance and get more frequent payouts? People arent aligned they are utilizing each others powers to make money right now. You see it all the tme "WHY DIDN'T I MINE SOLO" people upset they found a block and had to share it with teh pool. DOES THAT SOUND LIKE ALIGNED INTERESTS? It isnt. People arent in it for some kind of global effort, no they still want their BTC. Otherwise they would mine and donate it all back to the pool
"Aligned interests" means your interests (of obtaining a steady income, say) are aligned with those of others (that is, there are scenarios where the satisfaction of everyone's interests are improved). It has nothing to do with altruism.

Your peers in the pool are your business partners, you've entered a mutually beneficial agreement to reduce everyone's variance. By hopping you are defrauding your partners of their due reward.
2626  Bitcoin / Mining / Re: Pool hopping... ethical or not? on: July 27, 2011, 07:32:40 AM
This is exactly the sort of thing I was talking about. If this guy doesn't care if I hop even after being told it will lose him coins, then how can it be unethical to hop?
This is exactly the sort of thing I was talking about. This guy is ignorant about the consequences of pool-hopping, and we should educate him, not take advantage of him. But I agree that we've tried talking and it didn't work, so it's the time to educate by action.

but when the pool has a track record of finishing a block for an extended time...i might or might not jump to it...
This is (the reverse of) the gambler's fallacy. Unless there's something wrong with how a pool is run, a track record of longer than expected blocks has no bearing whatsoever on the length of future rounds.
2627  Bitcoin / Mining / Re: Pool hopping... ethical or not? on: July 27, 2011, 04:37:42 AM
alright, I read the info and I think this is a myth.  The first strategy is to mine until 43.5% then hop off the pool and solo mine?

At the current difficulty, you have a 0.001239% (rounded) probability of finding a block within 10 minutes at 300 MH/s.  So basically you're wasting time that you could have spend contributing to the pool and getting a higher split.  Then if you beat the pool and find the block solo, you get 50 BTC but lose all the progress in the current pool.  And that's like betting on red and black at the roulette table except if the payments were less than your bet.  One is going to lose and you're betting your mining time on opposites.  If you thought you could beat the pool solo, you should solo the entire time.

The same goes for mining until 43.5% of what I assume is the estimated completion time of a block since there is no "progress" or "completion percentage."  You bet on two pools, only one can win, you're losing your mining time on whatever pool loses.  It doesn't seem logical.
You're wrong, but thanks for proving my point about the existing confusion.

Tell me this. Let's say the proportional pool has (2*difficulty) shares in the current round. If you mine for it now, then no matter what happens, you will get less than (Block reward)/(2*difficulty) per share you submit. So why do it instead of, say, a PPS pool which gives you (Block reward)/(1.1*difficulty) per share you submit?
2628  Bitcoin / Pools / Re: [90 GH/s] EMC: 0 Fee/LP/API/PayPal Payout/Free SMS/US/EU/AU/Full 8 Payout/More on: July 26, 2011, 07:49:44 PM
So, Im curious... I noticed something, I seem to get rewarded the same amount no matter how long a block takes to solve by the pool, whether its 15hrs or 3days
If you're 1% of the pool, you'll always get on average 1% of the reward of every block, which is 0.5 BTC. But if a block took longer, it means you got 0.5BTC for a longer period of mining, so it's less per unit of time.

Does this mean a given block is higher in difficulty vs one that is fairly simple?
Difficulty only changes once every 2016 blocks. But finding blocks is random so some times it takes longer than others.
2629  Bitcoin / Pools / Re: Hybrid Payment scheme on: July 26, 2011, 07:26:00 PM
Apart from the possible processing load, is there any technical reason why no pool uses a hybrid payment system?

e.g. 80% PPLNS + 20% PPS so that those who contributed during a round would get some value, especially for those who don't mine 24/7. However, this portion is not enough to be worth pool hopping due to the PPLNS portion which would encourage miners to stick out a long round.
Did you mean Proportional instead of PPS?

You're misunderstanding how hopping-proof methods work. They don't encourage anyone to stick out a long round. They just give the same average payout for future shares without regard to the past. So in a long round, the PPLNS part will give normal payment while the proportional part will give less than normal, so the total will be less than normal and a hopper will hop.

Hybrid schemes are possible but they tend to have the disadvantages of both components, plus the complexity disadvantage, without much of their respective advantages.

And, it is a myth that PPLNS has some horrible disadvantage for intermittent miners. They have the same expectation with only a slight increase in variance.
2630  Bitcoin / Mining / Re: Pool hopping... ethical or not? on: July 26, 2011, 03:51:20 PM
PPS pools
Proportional. PPS is something else entirely.

In my opinion, the near-perfect analogy to pool-hopping is a game of poker where some people know the odds and the others don't. The ones with the knowledge (who put it to use) have a clear advantage.

Similarly, in both cases, the more people maximize their expected value by playing the odds optimally, the less there is to win. Ultimately, if everyone pool-hopped, the PPS pools would simply halt and the EV would drop to 0.
So it's not like Poker at all. You can still play poker if everyone knows the odds, you can't mine in prop if everyone hops.
2631  Bitcoin / Pools / Re: A proposal for Recent Shared Maximum PPS on: July 26, 2011, 03:45:21 PM
No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.
Your mistake is assuming that the goal of a pool is to reward each share with the statistical average, exactly.

The real goal of a pool is, however, to reward each share with the statistical average, on average (while reducing variance as much as possible). On the one hand you have PPS, which is 0 variance for the miner (with maximal risk to the operator); on the other hand, solo mining which has the highest variance; and a variety of methods in between.

PS. If MPPS is what I think it is, then it is just as bad as the *SMPPS.
*MPPS fit with your "real goal" much better than any other system currently.
This is of course false, given that
1. *MPPS does not fit the goal.
2. Other systems such as PPLNS and the geometric method fit the goal.
2632  Bitcoin / Pools / Re: A proposal for Recent Shared Maximum PPS on: July 26, 2011, 03:30:16 PM
No matter what reward method is used, when a pool is down to zero buffer on a long round, it must either underpay or create debt for the pool owner. That is an inevitable fact of pooled mining. Nothing can stop it. *MPPS attempts to mitigate it by offering to make up for the loss later.
Your mistake is assuming that the goal of a pool is to reward each share with the statistical average, exactly.

The real goal of a pool is, however, to reward each share with the statistical average, on average (while reducing variance as much as possible). On the one hand you have PPS, which is 0 variance for the miner (with maximal risk to the operator); on the other hand, solo mining which has the highest variance; and a variety of methods in between.

PS. If MPPS is what I think it is, then it is just as bad as the *SMPPS.
2633  Bitcoin / Mining / Re: Pool hopping... ethical or not? on: July 26, 2011, 03:16:54 PM
Pooled mining is an agreement among miners to jointly work on finding blocks and splitting the rewards in proportion to the contribution of each, with the pool operator as middleman. Pool-hopping is an attempt to gain more than the fair share of a pool's rewards for the work done, breaching the agreement, and as such is unethical.

The claim that "people were warned and still mine for proportional pools, so they consent to it" is understandable, but problematic because:
1. Not everyone reads the forum. I wouldn't be surprised if most of the users of Deepbit have never looked at its forum thread. You are taking advantage of those users who don't know any better.
2. Pool-hopping is hard enough to understand as it is. I think there is virtually nobody who has commented about the statistical properties of mining and isn't guilty of having made an error at some point. Add to it the people who actively deny that it works or is harmful to honest miners (rarer these days) and the FUD against hopping-proof methods, and an average miner doesn't know if to believe Random Internet User A or Random Internet User B. It is clear that anyone would avoid proportional pools if he had a good understanding of pool-hopping and the alternatives, so staying with the pool should not be seen as consent to pool-hopping.

However.

It is clear that the real problem is not with the hoppers, but with the pool operators who allow this to happen and deceive their customers. Abstaining from hopping will not solve the problem, as there will always be those won't even be bothered by the question of whether this is ethical, and silently eat at the due rewards of miners.

The only way to expose the corrupt proportional pools for what they really are is to openly mount a massive pool-hopping attack, demonstrating a statistically significant drop in the payouts of honest miners. One would hope that this will create an outcry leaving operators with no other choice than to back down and adopt an unbroken scoring method (such as PPLNS). To the extent that openly pool-hopping helps bring about this brighter future, I would say that it is acceptable.
2634  Bitcoin / Pools / Re: A proposal for Recent Shared Maximum PPS on: July 26, 2011, 12:15:56 PM
Does this make sense, or am I missing something?
You are correct. This is a fundamental problem with all *MPPS pools. When the balance is negative, miners know that their payment has a good chance to be delayed. It doesn't matter if the pool pays recent first (RSMPPS), strives for equal payment for all shares (ESMPPS) or pays all unsaturated shares every round (SMPPS). And, since this should quickly cause the collapse of the pool, "delayed" really means "gone forever".
2635  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 25, 2011, 10:58:22 AM
I should point out, yet again, that it would be trivial to change the attack protection function from a multiplier to an exponent.  If nodes refused to revert the block chain unless the change in difficulty was more than 2^(n-5) times the current difficulty when n>6, a vendor could wait a few of hours for a big transaction and be sure that all of the computing power in the galaxy would be unable to reverse it.
This throws away exactly what the "longest chain" rule was supposed to prevent - a node being unable to catch up with the rest of the network after a period of isolation. You'll want some way to recover by checking which branch is the real one... From a "trusted" source, whose signature you'll want. So might as well make it part of the design.
You need to think this scenario through a bit more.  Ask yourself what circumstances must occur for a node to be unable to rejoin the world after a network split.  I'll give you two hints.  For the network to get stuck, there needs to be mining power on both sides of the split.  And the duration necessary for the split to become permanent is directly related to the split ratio in a way that makes an honest split of sufficient size and duration to be extremely unlikely.
I need to research this more, yes. But what I had in mind is a targeted attack against a particular node, trying to isolate it from the network and feeding it blocks distinct from those known to the rest of the network. I think it's possible to do that, and while I don't know if such an attack can be lucrative, the victim node can never recover if it adheres to your protocol rigorously.

But if it turns out to be a viable means for increasing security of large transfers (for which a day of waiting would be acceptable) then by all means, proof of stake won't be needed.

This would make undoing transfers very difficult, but you could still hold the network hostage. Short-selling strategies could still be profitable.
You're right, actually I didn't think a lot about solution to this problem, I was focusing on preventing double-spending. In any case I think solving this will be easier if we solve double-spending via other means.

I'm not sure I understand about large transfers. How does this apply to them in particular? Also can't large transfers be easily disguised by breaking them up into numerous small transfers?
If you need to receive a large transfer from someone, you know that it may be profitable for him to mount a >50% attack in other to double-spend it, so you need some sort of guarantee that the transaction is secure before you accept it.

When you receive a smaller transfer it is much less likely that the sender will be willing or able to double-spend it, and much less risky if he does.
2636  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 25, 2011, 09:48:10 AM
You're saying the current security is 7.5%. Is that too much? Too little?
We don't know. I estimate it's higher than necessary. But the security sustainable without either coinbase or prohibitive tx fees will be much, much lower, and we don't want to roll the dice thinking maybe the sustainable amount will be sufficient.

I'm re-reading the thread from the beginning anyway, to see the stake-proof proposal a like more.
I think you'll be disappointed, AFAIK this was mentioned late in this thread. You may want to search for the post about proof of stake by QuantumMechanic, from which I got the general idea.


I should point out, yet again, that it would be trivial to change the attack protection function from a multiplier to an exponent.  If nodes refused to revert the block chain unless the change in difficulty was more than 2^(n-5) times the current difficulty when n>6, a vendor could wait a few of hours for a big transaction and be sure that all of the computing power in the galaxy would be unable to reverse it.
This throws away exactly what the "longest chain" rule was supposed to prevent - a node being unable to catch up with the rest of the network after a period of isolation. You'll want some way to recover by checking which branch is the real one... From a "trusted" source, whose signature you'll want. So might as well make it part of the design.
You need to think this scenario through a bit more.  Ask yourself what circumstances must occur for a node to be unable to rejoin the world after a network split.  I'll give you two hints.  For the network to get stuck, there needs to be mining power on both sides of the split.  And the duration necessary for the split to become permanent is directly related to the split ratio in a way that makes an honest split of sufficient size and duration to be extremely unlikely.
I need to research this more, yes. But what I had in mind is a targeted attack against a particular node, trying to isolate it from the network and feeding it blocks distinct from those known to the rest of the network. I think it's possible to do that, and while I don't know if such an attack can be lucrative, the victim node can never recover if it adheres to your protocol rigorously.

But if it turns out to be a viable means for increasing security of large transfers (for which a day of waiting would be acceptable) then by all means, proof of stake won't be needed.
2637  Bitcoin / Pools / Re: Deepbit PPS vs. smaller Pools on: July 25, 2011, 07:37:08 AM
How does having a CPU or other weak miner always mining for you under your account while pool hopping with your primary miner get handled by the various schemes? It would seem PPS wouldn't be affected at all but these others might be skewed a bit if you dumped a lot of hashing power early on then moved on to another pool while leaving say 20MH at the original pool. Yes/No?
No. With hopping-proof methods (geometric, PPLNS) the expected payout per share is the same no matter when it was submitted.
2638  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 25, 2011, 04:27:12 AM
I should point out, yet again, that it would be trivial to change the attack protection function from a multiplier to an exponent.  If nodes refused to revert the block chain unless the change in difficulty was more than 2^(n-5) times the current difficulty when n>6, a vendor could wait a few of hours for a big transaction and be sure that all of the computing power in the galaxy would be unable to reverse it.
This throws away exactly what the "longest chain" rule was supposed to prevent - a node being unable to catch up with the rest of the network after a period of isolation. You'll want some way to recover by checking which branch is the real one... From a "trusted" source, whose signature you'll want. So might as well make it part of the design.

For starters, it requires the largest wallets in the world to be online, and they are exactly the sorts of wallets that you want to keep offline.
As I mentioned you don't need the private key required to sign proof-of-stake to be the same one needed to send coins. You'll keep your sending key well hidden offline, while the stake key will be online doing signatures. If someone steals your stake key, you just move the coins to a new address.

  And the problem of gathering, distributing, and verifying signatures corresponding to 3.5 million BTC (and growing every day) is hardly unsolvable, but still immense.
Given the distribution of bitcoins, I don't think 3.5M BTC is that many addresses.
2639  Bitcoin / Pools / Re: Deepbit PPS vs. smaller Pools on: July 25, 2011, 03:51:59 AM
Is block withholding (which essentially removes the hash rate of the withholder) the only risk left in a "pure" PPS pool?
Of course it's not the only risk. But the risk due to to variance can be calculated and planned for.

It should be detectable by the way, if you are willing to invest a few coins for that (or cheat a tiny bit on your miners) - as soon as someone has solved a valid block you send out that getwork manually to all of your miners connected at that time and kickban everyone that doesn't send a reply. If they send a reply back, you can either choose to pay them for their honesty or just treat this share as stale and not pay it.
Could work, but it will probably have a lot of false positives, and what stops the attacker from creating a new account once in a while?
2640  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 25, 2011, 03:45:34 AM
and the over 50% hashing power flaws.
That's what we're talking about.

if you know of some amazing loop hole or something then by all means, exploit the network and set it in ruins. i in fact encourage it, i do not want to use a currency with fundamental issues at the core.
I don't have millions of dollars to fund this experimental attack.
Pages: « 1 ... 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 [132] 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!