Bitcoin Forum
May 26, 2024, 08:51:08 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 »
2641  Bitcoin / Mining / Re: Opportunistic mining in effect for the following pools on: July 24, 2011, 07:20:08 PM
You are right, pool-hopping is cheating.

I agree, except the part I quoted. It's not cheating.
Of course it is. Pooled mining means - everyone contributes, and gets a portion of the loot in proportion to his contribution.

With pool hopping, you get a larger part of the reward without a larger contribution, on the expense of others. This is cheating according to the standard usage of the word.

The fact that the proportional scoring method is defective by design and makes it easy to do doesn't mean it's not cheating, it just means we should stop using proportional.

By analogy, someone who leaves his house unattended with an open door and expensive jewelry inside, has only himself to blame if it gets stolen. But whoever stole it is still a thief.
2642  Bitcoin / Development & Technical Discussion / Re: Why can't the change be returned to itself? on: July 24, 2011, 07:12:41 PM
I think it's about anonymity, by creating a new address, an observer doesn't know which output is the recipient and which is the change.

The client always maintains a buffer of 100 addresses, when one is used another is generated.
2643  Bitcoin / Mining / Re: Opportunistic mining in effect for the following pools on: July 24, 2011, 07:06:29 PM
You know, pool hopping is cheating, plain and simple.

You're stealing from the honest miners who participate in those pools.

Pools are a zero-sum game. Your gain is someone else's loss. And since you haven't done anything positive to help find a block -- quite the opposite -- you're stealing the extra, not earning it.

And don't tell me you're using "math skills" to earn more money -- thieves and con men work at their trade as well. It's still theft.

Matthew
You are right, pool-hopping is cheating.

And it is perfectly fine to pool-hop, because:

1. Miners have been warned for ages about the dangers of proportional pools.

2. Viable hopping-proof scoring methods have been devised and implemented.

3. The only way to destroy the corrupt proportional pools is by publicly hopping en masse.
2644  Bitcoin / Mining / Re: Opportunistic mining in effect for the following pools on: July 24, 2011, 06:34:56 PM
That's not how it works. The solution space is virtually infinite, block finding is memoryless. If the pool spent 10 days trying to find a block it isn't any closer than it was in the beginning.

And yet large pools find solutions in very finite time.  Because a pool *should* find a solution some time between average and average * 2 time far more often than never finding a solution at all still seems like jumping in once reward per share increases (after expected share #s are contributed) would increase total reward relative to everyone else in the pool.  Just like jumping out of a proportional pool.

I was under the impression that difficulty somehow relates to solution space size.  Some other pool finding a solution and causing the pool to start work on a new block shouldn't matter for large enough pools.

Anyway, guess I have a lot more learning to do.  Obviously I'm not a mathematician or statistician -- but it just seems like there must be some way to take advantage of increasing payouts in PPLNS pools.
Read up on memorylessness and Poisson process. And no, what you're suggesting is impossible.
2645  Bitcoin / Mining / Re: Opportunistic mining in effect for the following pools on: July 24, 2011, 05:47:04 PM
While it's impossible to determine when the pool will solve the block it is possible to avoid those pools until they searched a large portion of the solution space -- let's say 70%, meaning the solution is guaranteed to be in the remaining 30%.
That's not how it works. The solution space is virtually infinite, block finding is memoryless. If the pool spent 10 days trying to find a block it isn't any closer than it was in the beginning.
2646  Bitcoin / Mining / Re: Opportunistic mining in effect for the following pools on: July 24, 2011, 03:31:12 PM
Now I realize the theoretical opportunistic mining payout increase is only about 10%
Huh? For hopping with a single proportional pool the theoretical maximal increase is 28%. For 10 pools it's 156% (x2.56).

While I'm at it, for the slightly suboptimal strategy of always going with the freshest proportional pool even if they're all >43.5%, the speedup factor with n pools is (n ln(n))/(n-1). For n>8 this is virtually the same as having a fallback pool (up to 0.1% difference).

Hopping *into* a PPLS pool (e.g., eligius) at the end of the round is far more lucrative than hopping OUT of a PPS pool at 41.3%.
You don't know when a round will end, so you can't increase your expected payout by hopping into a pool at the end of a round. Also, you hop out of proportional pools, not PPS. I don't know what you mean by pay-per-last-share pools, but if you mean PPLNS then eligius isn't one.
2647  Bitcoin / Pools / Re: Deepbit PPS vs. smaller Pools on: July 24, 2011, 01:28:02 PM
?MPPS is not PPS so don't mislead people by presenting it as such.
Actually I believe I said "PPS variant".
You did, but you also said "there is no need to pay any fees (10% or 7%) for PPS". No point arguing this though.

ESMPPS has the same fundamental problems as SMPPS. If the balance is negative you will receive a low reward short-term. And since everyone will leave there's not going to be a long-term.
You are correct, there are sometimes delayed payments, but not to the extent that SMPPS or other *PPS variants offer. For that matter, even true PPS could pay less than 100%, notably if the pool operator goes bankrupt due to block withholdings. The point of ESMPPS is to offer payment to those who deserve it the most, that is the way the reward scheduling algorithm works.
You stop mining for the PPS pool when it goes bankrupt, which is exactly what you should do when an *MPPS pool goes red. The difference is that a PPS operator takes the fee required to prevent this from happening. In case of bankruptcy, if the operator is honest and takes the necessary planning, you will not lose payment for work already submitted.

If a PPS operator wants to eliminate block withholding risk, he can lobby for my oblivious shares proposal.
2648  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 24, 2011, 01:14:58 PM
Currently we can use our knowledge of the difficulty to estimate the total hashing power of the network and also the total hashing power of the pools by looking at how many blocks they generate over a period of time. The effectiveness of double spending attacks rely on people not knowing about the attack going on, because you need to get a merchant (or some other sap) to take your coins and exchange them for goods before you pull the rug out from under him and unspend those coins. Provided we keep alarms on the system to let people know 51% attacks would be unless. Everyone knows how many blocks are being generated per period of time, its broadcast, using this knowledge, combined with knowledge of major miners block generation rates every client could do the math on that information and determine weather 51% or more of the hashing power has been accommodated for or not. When a single entity has 51% everyone is informed by their client and Bitcoin spending stops, the moment the attacker breaches 51% everyone using Bitcoin is told not to spend or accept until such a time as the attack ceases. This is a really heavy handed move, and yes it would be bad for Bitcoin, but a 51% attack is bad regardless of what we do about it so why not take a course designed to destroy the attackers incentive.  
... Unless of course the attacker wants to destroy faith in Bitcoin (politics? Stake in current financial system? Short-selling?), in which case suspension of all Bitcoin activity would count as "mission accomplished".

We need a mechanism to prevent attacks whatever the motivation and strategy of the attacker is.
2649  Bitcoin / Pools / Re: Deepbit PPS vs. smaller Pools on: July 24, 2011, 01:03:18 PM
Just so everyone knows, there is no need to pay any fees (10% or 7%) for PPS. We just started offering a 0% PPS variant that rewards everyone fairly for their time.

The only pool where I consistently get 99-100% of my expected earnings in the long run is Eligius with their SMPPS system.
Good for you, just make sure to jump ship when their balance becomes negative and you won't get anywhere near that.

That is exactly why we went with ESMPPS instead of SMPPS. Unlike SMPPS, ESMPPS does not stop paying miners when the reserves get low. In fact, to a large extent, ESMPPS was designed with the idea that negative reserves are an inevitable.
?MPPS is not PPS so don't mislead people by presenting it as such.

ESMPPS has the same fundamental problems as SMPPS. If the balance is negative you will receive a low reward short-term. And since everyone will leave there's not going to be a long-term.
2650  Bitcoin / Pools / Re: Deepbit PPS vs. smaller Pools on: July 24, 2011, 11:27:10 AM
That's a myth, PPLNS doesn't punish anyone, it just gives everyone a fair payout in exact proportion to their work (on average).
It does, pool hoppers. Or maybe 'deter' is a better word. Nobody has an incentive to jump onto pools like mineco.in at any 'certain' time to gain a statistical advantage.
'Disarm' is an even better word. Hoppers are welcome to hop, but they won't receive more than normal (unlike proportional) but also not less.

Quote from: Meni Rosenfeld
just make sure to jump ship when their balance becomes negative and you won't get anywhere near that.
Fair enough, I'll be first to admit I would run if the balance went too much in the red. If enough people did this the SMPPS pool would die from a lack of miners and thus blocks towards paying off the 'debt'.
As an added bonus, if they don't take a fee to boost the reserve, with probability 1 it will eventually go too much in the red. Whether people will be smart enough to leave then is a different question.
2651  Bitcoin / Pools / Re: Deepbit PPS vs. smaller Pools on: July 24, 2011, 11:14:21 AM
The only pool where I consistently get 99-100% of my expected earnings in the long run is Eligius with their SMPPS system.
Good for you, just make sure to jump ship when their balance becomes negative and you won't get anywhere near that.

I've been using Eligius as well for some time now. Is mineco.in better if you mine 24/7?
Yes, the PPLNS payment method rewards 24/7 miners and punishes people who disconnect during a round (accidental, or pool hopping, it doesn't know or care)
That's a myth, PPLNS doesn't punish anyone, it just gives everyone a fair payout in exact proportion to their work (on average).

Yeah I know, the 10% fee is a lot but MtRed is coming out with 0% PPS in a few days because of all the pool hopping problems they've been having lately.
Did they decide what to write on the tombstone yet? You've got to plan ahead when you're committing suicide.

Unless it's not really 0% fee or not really PPS.
2652  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 24, 2011, 04:00:51 AM
the problem with this argument is that the system is set up to offer strong security now, and progressively weaker security later on. Apparently, most people only care about the current operation of the system. The fact that it is probably not sustainable doesn't bother anyone. I think it is just a seeing is believing issue. Depressingly similar to US gov't finances.

how will the security get weaker. if you want to continue using bitcoin you will mine for a few hours a day, its only common curtsey that you help secure the network you use.

i believe people are motivated by profit not anonymous acts of public service.

you profit because you pay less, would you rather pay visa 20+$ a month or simply run a client for a few hours a day totaling about 5-10?
This is nonsensical.
1. If Bitcoin is successful then most people won't and shouldn't know what mining is or how to do it (this is largely the case even now).
2. Those who do know can use Bitcoin without mining. It's not like the alternatives are "use Bitcoin and mine" and "don't use Bitcoin and don't mine".
3. Mining on the CPU with the Bitcoin client is worthless. You need either a GPU or a future dedicated hashing chip, and dedicated software.
4. Mining has a cost, it will require purchasing hardware most people don't have and operating it. It also requires setting up the software. People won't do it without being incentivized.
5. If Bitcoin succeeds then attacking the network can become much more lucrative, and a whole lot of mining will be required to prevent it. A few random contributors won't be enough.
6. Currently the network security is supported by the coinbase (generation of new coins). If you want to make the case that it will remain secure when the coinbase goes away, the onus of proof is on you.
2653  Bitcoin / Pools / Re: normalized Proportional Payout - Nearly identical to PP although hopper-proof! on: July 23, 2011, 06:49:19 PM
1) I appologize for interpreting PPLNS incorrectly. I see my error. I disagree that it is hopping-proof. Consider this (rigorous simulations coming later): A share submitted immediately after a pool finds a block has more opportunity to be counted for multiple blocks than one submitted late into a "pool round". When all possibilities are integrated over, the expectation value must be equal to one, hence, if the expectation value, per share, varies with time or round_shares, it is hoppable.
No, the number of shares per round follows the exponential distribution which is memoryless. The payout for a share depends only on the blocks found in the future, not in the past, which doesn't depend on the number of shares already submitted in the round.

3) This is interesting. I'll investigate further. Would you be kind enough to supply with such a proof?
Let B be the block reward minus fixed fees, and p=1/difficulty. Then every share must be paid on expectation pB. The first share has probability p to end the round, and in a naive scoring system this will means it earns the entire reward B. This contingency alone gives at an expectation pB, so it must receive 0 payout if it's not valid (otherwise the expectation would be more than pB). So if the second share is valid then it receives the entire reward, so the same argument applies, and by induction any share receives the entire block reward if it is a valid block, and 0 otherwise (so in fact the accurate statement is that the only naive hopping-proof scoring method is solo. Which is, by the way, the limit case of the geometric method when the variable fee is 0).
2654  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 23, 2011, 06:01:33 PM
the proof of steak idea not only would be hard to implement, it also is poorly thought out, introducing more complexity into the system would only make it more difficult to use bitcoin, unless i am missing something?
What you're missing is that it may be necessary, as in Bitcoin won't be able to work without it. So the fact that it adds complexity (which has no effect on regular users) is moot.

And like I said there's more than one idea and they're all rough sketches, figuring out the optimal solution requires serious discussion.
2655  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 23, 2011, 05:39:59 PM
can someone fully explain the "stake" idea?
There are more than one stake ideas. Both cunicula and I described our respective stake ideas earlier in this thread (post #113, #116).
2656  Bitcoin / Pools / Re: normalized Proportional Payout - Nearly identical to PP although hopper-proof! on: July 23, 2011, 05:32:52 PM
This post is completely wrong. Virtually all of your premises and conclusions are incorrect.

1. PPLNS always pays out the last N shares, even if they are from previous rounds. It is hopping-proof.

2. The geometric method is hopping-proof without crossing round boundaries.

3. Your method is not hopping-proof. The speedup function is calculated based on the distribution of the number of shares on the round, and on the assumption that they all have a score of 1. Once you change the scoring function this assumption becomes invalid. Take the first share for example. If you score it based on your suggestion and keep the score of all other shares 1, it will indeed have expected payout 100%. But you also decrease the score of the next several shares, thus increasing its expected payout.

In fact it is fairly easy to prove that a hopping-proof scoring method can't be based entirely on distributing the block reward between the participants in the current round. You must do something like take into account previous rounds or give the operator a variable fee.
2657  Bitcoin / Pools / Re: [90 GH/s] EMC: 0 Fee/LP/API/PayPal Payout/Free SMS/US/EU/AU/Full 8 Payout/More on: July 21, 2011, 01:57:32 PM
It's not a trivial thing to implement... incidentally the "cheat proof scoring" system in Simplecoin is all sorts of broken, which was the base I was starting from and that has turned out to be a huge mistake.  I should have just written it from scratch like everything else.
This explains a lot. Some time ago someone started a pool and boasted a "cheat proof scoring". Upon asking, it became clear he had no idea what that meant and he just chose the "cheat proof" option from his pool software. I wondered if that was actually my geometric method, and if so, how come it was implemented painlessly after it has proven to be nontrivial to others who tried. So it looks like Simplecoin was the pool software, and that it didn't have a correct implementation after all.

There may be others who try to use it so I think we need to warn them.

... And it looks like I may be to blame for the error in Simplecoin, seeing as I misunderstood something I was asked about.

So, I'm close...... it looks like max is the previous row lscore value, is that right?
Yes.
2658  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 21, 2011, 12:25:25 PM
The idea behind transaction fees. is that by the time 2040 rolls around Bitcoin will have already failed, or be successful enough that the transaction volume can support the network with minimal fees. Currently 201600 BTC are issued per month for Bitcoin protection. And no, the current transaction rate could not support that same amount of security, if we assume that by 2040 Bitcoin will have either already failed, or be at least have as much trade as Visa handles currently, about 2000 transactions per second. At 2000tps if each trade pays a fee of .001 BTC (about 1/10th of a cent)  that adds up to 2 BTC per second, 120 BTC per minute, so at 10 minutes per block that's 1200 BTC per block reward. Thats 24 times more "network security" than we have today, at a trivial fee per transaction.
The current network hashing capacity is enough for securing a $100M economy. It is not enough to secure a $1T economy. It can be overrun by anyone with a multi-million dollar incentive to do so, be it double-spending of huge transfers, political sabotage, shorting, whatever. As Bitcoin grows its security requirement will grow, and I'm not sure it will be achievable with trivial transaction fees alone.
2659  Bitcoin / Bitcoin Technical Support / Re: wallet.dat lost and recovered, but balance flew away! on: July 21, 2011, 11:19:09 AM
And you do know that your backups need to be relatively recent, and that and old backup might not have any of your coins, right?
I know this even before wipe the file.
Ok, I was just concerned because you said "My backup was a bit old".

I simply think that rescanning is done by default...
Rescanning takes time, so shouldn't be done unless necessary. I guess future clients will intelligently determine when it is necessary.
2660  Other / Meta / Re: I miss the old days. on: July 21, 2011, 10:38:39 AM
I think the biggest problem is one of information organization, not "trying to bump post count".  There has already been a bit of joking about the fact that the forum has a very short memory.

The reason that there are so many topics and posts is mainly duplication. The thing that the new people generally do is rush to the "Create topic" button to ask one of the 10 most common questions. So make a FAQ (I know there is one on the wiki, that one can be used/extended).

In this case they should be pointed at a FAQ or duplicate topic as quickly as possible. Prevent the thread from becoming a lengthy political argument (especially if it was a technical question in the first place), and simply close it if it does.

Everyone can help with this (except for the closing) not just moderators. The key here is speed. Don't assume people are malignant, they are simply ignorant of everything that went before.
+10, if I only had more time I would spend so much of it on the wiki...

I think much of the clueless questions/rants can be eliminated with good information on the wiki, linked to in eye-catching stickies in the forum.

Good point. I would support not allowing people to post new topics until they have 100 posts or so.
Not everyone are in the forum for endless chatter, some just research Bitcoin on their own and have as their first post here a good question, a useful suggestion or an interesting project they've been working on.

More prudent would be a manual vetting system where established users can bestow to newbies posting rights if they see they're making good posts.

Pages: « 1 ... 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!