Bitcoin Forum
May 26, 2024, 12:08:20 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 »
2681  Bitcoin / Mining / Re: Pool Hopping: The SIMPLE Solution! on: July 19, 2011, 07:12:22 AM
Of course, the probability that the balance will be negative at some point during the year is higher, stay tuned...
Ok, according to my model, the probability is about 66%. This is reaffirmed by simulations I've run.

This is assuming the pool's proportion of the total network hashrate is as given, if it becomes higher the probability will increase.

I'm considering different ways to implement variations of PPLNS in my pool. I like the idea of PPLNM, but I think it is vulnerable to pool hopping, as some said earlier in this thread.

PPLNM (pay-per-last-N-minutes):
If you mine for one hour while hashrate is low and leave before it goes higher for one hour,
1. there are fewer proofs-of-work in your hour, so they are worth more, and
2. there is a high chance of payout on those proofs, because the hashrate is high in the second hour.
This should result in above average pay.

Mining for an hour with high hashrate, then leaving before others mine one hour with low hashrate, has opposite effects. This means below average pay.

If the pool hashrate goes up and down, and you only mine at the bottom of the curve, you get a bigger share of the payments, doing a smaller share of the work.
I don't think these will be the exact dynamics. There are two separate effects:

1. Stickyness: If you've already mined in this round, this increases your incentive to continue mining, since you'll raise the pool's hashrate and help it find a block before your old shares depreciate.
2. Opportunism: The probability that a block will be found before your new shares depreciate depends on the hashrate in the near future. On the other hand, their value if a block is found soon depends (inversely) on the average hashrate over the last N minutes. Thus, you are incentivized to mine when the hashrate is higher than the average.

What is the magnitude of the effect? Not too high, probably, but why take the risk when there is a purely advantageous alternative?
2682  Bitcoin / Pools / Re: [90 GH/s] EMC: 0 Fee/LP/API/PayPal Payout/Free SMS/US/EU/AU/Full 8 Payout/More on: July 19, 2011, 06:20:31 AM
I have c set to .01 for future scoring and I will change f to 0.
Good. But this means this is now a 1% fee pool, and you should pitch it as such.
2683  Bitcoin / Mining / Re: Pool Hopping: The SIMPLE Solution! on: July 19, 2011, 04:45:18 AM
Meni Rosenfeld, could you do some math for me, since you seem to like to do it and like to say that SMPPS is a bad method?

I understand that over an infinite time period, there is a certain probability that a SMPPS pool will be very negative (or very positive, etc.)  

However, I have a question.  Based on the current stats at https://arsbitcoin.com/stats.php, (SMPPS Buffer size, current hashrate).  And assuming that current hashrate is constant (lets say 210 GH/s), BTC reward per block stays at 50, difficulty is constant (if this matters), what is the probability that the SMPPS buffer will go below 0 in the next year?

I think it should be possible to calculate this, but I am not very qualified to do so.  It seems like you are.

It seems obvious to me that, for example, it IS less likely that the buffer will go negative, within a year, now that the buffer is ~685 BTC vs starting with a 0 BTC buffer. Sure, it is still possible to reach a very negative buffer, but the higher the buffer is, the longer this is likely to take, correct?

And I know that we are lucky.  I'm not saying that everyone should switch to SMPPS, because the buffer could just have likely gone to negative ~685 BTC as positive.  I'm just curious what the numbers say for my current situation.
I'll need to think a little about this, in the meantime I'll solve the easier problem of what is the probability the balance will be negative exactly one year from now (which would be 50% if we started at 0). With the current parameters, the pool will find in a year 210*10^9*86400*365.24 = 6.627*10^18 hashes, which is 6.627*10^18/2^32 = 1.543*10^9 shares, which is on average 1.543*10^9/1564057 = 986.5 blocks. Since this is distributed Poissonly, this is also the variance in the number of blocks found, so the standard deviation is sqrt(986.5) = 31.41. Our current balance is 685/50 = 13.7 blocks, so using the normal approximation to the Poisson, the probability that our balance will be less than 0 is the probability that a standard normal variable will be less than -13.7/31.41 = -0.4362, which is 33.13%. So the head start we have doesn't help too much.

Of course, the probability that the balance will be negative at some point during the year is higher, stay tuned...
2684  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 19, 2011, 03:58:12 AM
@Vandroiy suggests that proof-of-stake may be part of the solution and I think he is probably right.
He did? I suggested it in this thread, and this is an idea I got from QuantumMechanic.

What I had in mind is this - once in a while (say, every day) holders of bitcoins will use their private key (or a related private key) to digitally sign a recent block. A block with signatures of holders of >50% of the bitcoins at the time will trump a competing block with a longer chain but no signatures. If someone tries to sign two incompatible blocks, the earlier signature will count. This way, once a block gets >50% signatures is guaranteed to be set it stone, no matter how long a chain an attacker tries to build. Holders will be incentivized to do this because they want to protect the network security and hence the value of their holdings, and it may also be possible to include a "signature fee" in the transactions.

So, if someone sends a large transaction (large enough to be worth double-spending), he only needs to wait a day for it to be confirmed. This means mining will only be needed in a quantity sufficient to thwart casual attacks of low amounts, thus not a whole lot of it will be needed. That amount can be sustained with low transaction fees.

This is similar to the current checkpoint system, except it's clearer who decides the checkpoints and harder to fake, so can be done more frequently and automatically.

Adding proof-of-stake to proof-of-work would have a major negative impact on people currently invested in mining,
while benefiting those currently holding coins; Essentially some mining rights are transferred to coin holders and miners would need to buy them back or sell their equipment.
The change should have a very small short-term effect on the miners, especially if implemented while new coin generation is significant.
2685  Bitcoin / Pools / Re: [90 GH/s] EMC: 0 Fee/LP/API/PayPal Payout/Free SMS/US/EU/AU/Full 8 Payout/More on: July 19, 2011, 03:48:07 AM
Ok... Block 22 and 23 will be paid on proportional. With the changes Meni suggested, there is just no easy way to get the scoring numbers right for the calculations. Blocks 19, 20 and 21 were effectively already paid on proportional due to the c being wayyy too small (I thought I was saving you guys money, guess I was just making it proportional doh!).
It was proportional because of the bug, not because c was low.

If you keep f = -c/(1-c), then the average fee is 0 no matter what c is. With this invariant increasing c purely increases your own variance and decreases the participant's variance. And I think it's better to have a little fee if it helps keeping the variance low, so if f=-0.01, c=0.01 becomes unbearable, consider f=0, c=0.01.


perhaps the WebMonkey scoring system might be a better "fit"

instead of applying weight to shares and then devaluing said weight as the round goes on, a simpler, lighter approach:

based soley on time in round.

100% time spent mining in round = 100% of miner's estimated payout.
10% time spent mining in round = 10% of miner's estimated payout.

not only does this discourage people from leaving during the "1st half" of the round, but also discourages entering during the "2nd half" of the round.

now, i realise that is very simple (and very light) but a percent here or there could be tweaked to allow a tiny variance of miner reboot or even server outtage.
(round = round - outtage) BEFORE calculation of payout.
* WebMonkey crawls back into his way out of touch hermit hole and turns on the 80s pop music

'monkey
This is basically the same as proportional.
2686  Other / Beginners & Help / Re: How to read BlockExplorer Transactions on: July 18, 2011, 07:46:19 PM
This is the change, see also https://en.bitcoin.it/wiki/Transactions.
2687  Bitcoin / Pools / Re: [90 GH/s] EMC: 0 Fee/LP/API/PayPal Payout/Free SMS/US/EU/AU/Full 8 Payout/More on: July 18, 2011, 07:31:45 PM
So, does this mean if I can't mine 24/7, I don't get paid? Huh
Your average payout per share is the same no matter when you mine or in what pattern. But your variance will be higher for intermittent mining. For example, if you mine 1 hour per day, if you're lucky and a block is found at or near this hour you'll get a "jackpot" (reward much higher than the normal reward for mining an hour), but if not you'll get nothing.

This type of scoring gives the incentive not to pool hop, and has the unfortunate side effect of negatively impacting the part time miner as they will need to stay until the round finishes if they hope to be paid.  The part time miner would probably become a thing of the past if this scoring method takes root, but pools would probably stabilize as pool hopping becomes unprofitable.
Not really, part-time miners are welcome, it's only the variance that increases. The long-term average is the same. In particular, if you mine for some time and no block is found, there's no reason to stick around longer than you planned - that would be a version of the sunk cost fallacy.

PPLNS is an alternative hopping-proof scoring method which has less variance, but with its own disadvantages.
2688  Bitcoin / Development & Technical Discussion / Re: Question : Transaction fees when mining block worth 6.25 BTC or less on: July 18, 2011, 07:24:12 PM
There's been discussion, for example http://forum.bitcoin.org/index.php?topic=6284.

My current stance is that using proof-of-stake as an extra safety net will allow making do with less mining, the cost of which is supportable by tx fees.
2689  Bitcoin / Pools / Re: [90 GH/s] EMC: 0 Fee/LP/API/PayPal Payout/Free SMS/US/EU/AU/Full 8 Payout/More on: July 18, 2011, 07:09:49 PM
It would be nice to have Meni in here to comment (hint hint)
Well, if you insist Smiley.

If you stopped mining at share 700000 and the round lasted 1.9M your payout should be virtually 0 (and I mean something like 0.0000000001, give or take a few places), if it's not it definitely means there is a problem.

I found the bug which caused this and PMed Inaba about it.
2690  Bitcoin / Pools / Re: Will we need a pool for smaller pools? on: July 18, 2011, 06:32:26 PM
it's called multiclone, see the thread
Multiclone is something completely different.
2691  Bitcoin / Bitcoin Discussion / Re: [If tx limit is removed] Disturbingly low future difficulty equilibrium on: July 18, 2011, 03:48:19 PM
Economics professor who sees a serious problem here.  I have a background in industrial organization which is the relevant subfield.

Recommendation: Hire an academic economist specializing in Industrial organization to model the problem and propose possible solutions.

No one will trust me so hire someone at random.

Mike Hearn, if you can chat with Hal Varian at google, do so. He has the appropriate expertise. I think they pay him a mint though so it may be hard to get some of his time.

Final comment: This is a complez system. Analysis requires a formal mathematical model. Don't trust hand-waving and argument by analogy.
I doubt this is a problem anyone can single-handedly solve, even if he has credentials. And while I'm not much familiar with the field of industrial organization, I'm sure it provides only one piece of the puzzle and that many other fields have to be involved.

A discussion among several people with relevant skills, in a venue with higher signal-to-noise ratio than this forum, seems more appropriate.

And I'll take this opportunity to say that I think the inclusion of proof-of-stake to augment proof-of-work will be key to the resolution, by allowing a high level of security without much mining.
2692  Bitcoin / Mining / Re: Possible alternative for miners/idle hardaware? on: July 18, 2011, 02:12:07 PM
Finally, a competitor to http://parabon.com/ which accommodates individuals. I've been waiting for this for years. (Not that I'm sure I'll actually do anything with it now.)
2693  Bitcoin / Pools / Re: Pool hopping shouldn't be relevant. on: July 18, 2011, 12:29:17 PM
There is a very simple way to see why pool hopping works.

If you mine normally, you will get for every share on average B/d (block reward divided by difficulty).
Now let's say a proportional pool already has 2*d shares in the current round, and you consider mining for it now. No matter what happens, you will get less than B/(2d) for every share. Thus you'll want to mine for another pool instead.
And, since mining both early and late gives you on average B/d, and mining late gives you less than B/d, it follows that mining early give you more than B/d per share on average. Thus pool-hopping is profitable.

It's very simple mathematics here.

Let's say a pool has so far 99 shares submitted in the current round.  The very next share submitted will be worth an expected value of (1/100) * 50 toward the current reward, or 0.5 BTC.  

Now let's say a pool has 999,999 shares submitted so far in the current round.  The next share submitted is only worth (1/1,000,000) * 50, or 0.00005 BTC.  In other words, the expected value of each individual share submitted decreases as the round progresses.  
Not quite. The very next share will be worth 0.5 BTC if the round ends with this share. But on average the round ends much later than that share. Thus the expected payout will be closer to log(difficulty/100) times the normal reward.


Now let's say a pool has 999,999 shares submitted so far in the current round.  The next share submitted is only worth (1/1,000,000) * 50, or 0.00005 BTC.  In other words, the expected value of each individual share submitted decreases as the round progresses.  

Which is why PPS based payment schemes & it's variants (like on mineco.in and eligius & deepbit, 3 different PPS methods)
are superior and will eventually prevail over the long term.

When all shares are of equal value, you get paid for the work you do; Not for being opportunistic. Doesn't matter if the CDF is 0.1% or 99.9%, if the round has taken 2 minutes or 20 hours.
You don't need PPS for that, you just need a non-defective scoring method, like the geometric method or PPLNS.
Edit: eligius uses a defective method called SMPPS. It looks like minecoi.in uses PPLNS.
2694  Bitcoin / Pools / p2pool - Decentralized, Absolutely DoS-Proof, Pool Hopping-Proof Pool [archival] on: July 18, 2011, 12:05:40 PM
Shares are now generated with variable difficulty to keep the rate of shares at about one every 5 seconds. Rewards are split over the last 3*n shares. n = the number of shares that have an equivalent work to the generation of one block.
Can you explain more about this point?

Do I understand correctly that if a share (or several shares in a row) takes a long time to be found, the difficulty for the next share will decrease? If so, will the payout per share be proportional to the difficulty? How will this synergize with the 3*n rule? Also, how will you handle updates of the global difficulty mid-round? If not done correctly these matters can make the pool prone to hopping.

Also, won't communication latency be a major problem with a share per 5 seconds?
2695  Bitcoin / Development & Technical Discussion / Re: alternative cheat-proof method? on: July 18, 2011, 10:18:54 AM
First you should keep in mind that any scoring method where the score depends on time, is prone to hopping based on hashrate fluctuations. So to make your suggestion a candidate for analysis, we should replace it with the score being equal to the number of shares already submitted (this gives the same results as the time-based method if we assume that the hashrate is constant).

So, for this scoring method, a share submitted after t*difficulty others, gives an expected return of approximately 2(1-t*exp(t)*gamma(0,t)) times the normal reward. Thus, shares submitted at the beginning of the round have twice the normal value, and it remains >100% up to the point where 61% * difficulty shares were submitted.
2696  Economy / Economics / Re: Simple, escrow-based Bitcoin payment system on: July 18, 2011, 08:19:51 AM
If the vendor already offers gift cards, this can be and is done (eg http://spendbitcoins.com/ and http://www.bitcoinexchange.cc/).

If not, you'll have to talk them into accepting this service, which isn't much easier than convincing them to accept bitcoins directly.

If the vendor offers gifts but not gift cards, it will probably be against their ToS to offer such a service single-sidedly.
2697  Bitcoin / Pools / Re: Will we need a pool for smaller pools? on: July 18, 2011, 08:11:05 AM
In the not so distant future when finding block in a somewhat decent time requires several TH/s The creation of a new successful pool will be extremely difficult and ineffective. Do you think we will need a service which can join multiple smaller pools into a single larger pool to help control the variance?
Yes. (Semi-)decentralized pools like p2pool should work nicely as the larger pool.
2698  Bitcoin / Development & Technical Discussion / Re: alternative cheat-proof method? on: July 18, 2011, 04:47:44 AM
Your method is not hopping-proof. There are two hopping-proof methods, the geometric method and PPLNS (look them up).


To those who think pool hopping is not a problem, please consider two points:

1. What would happen if everyone did it? (Hint: proportional pools would stop getting any shares at all once they reach 43.5% of the difficulty).
2. Increasing megahashes with better hardware/software means you increase your contribution to the network security, and your reward increases proportionally. Pool-hopping means you increase your reward without any increase in your contribution (at the expense of other miners).
2699  Other / Meta / Re: Humor subforum on: July 18, 2011, 04:34:56 AM
There aren't too many... But when there are I don't think they belong on the current forums.
2700  Other / Meta / Humor subforum on: July 17, 2011, 07:21:03 PM
I think we need a "humor" or "jokes" subforum. (Bitcoin-related, so doesn't belong on Off-topic.)
Pages: « 1 ... 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!