1. Go to https://bitcointalk.org/watchlist_posts.php and click "Do it". 2. Make sure that replied-to threads are automatically added to watchlist (I think this is the default but doesn't hurt to check). 3. Unwatch all unwanted threads. 4. Forget that "Updated Topics" ever existed. Use the watchlist. Also, the proper subforum for this is "Meta". "Technical Support" is for support with Bitcoin. |
|
|
|
|
Ripple+Fiat doesn't have all the advantages of Bitcoin. It probably doesn't even have most of them. Ripple+Bitcoin might be a powerful combination though.
If something came up which is superior to Bitcoin hands-down, it could "destroy" Bitcoin and it would be perfectly fine.
|
|
|
|
It seems broken to me: a = 0.8 fee = 3% share cap = 1.5 share diff = 56 work diff = 8PPS percent = 100.42% share diff = 56 work diff = 1PPS percent = 519.67%  It means the ratio between what you would get for a share with this work difficulty between PoT and normal PPS. With a lower work difficulty you get a lower absolute payout, but higher as a ratio of PPS (because the gap between work difficulty and share difficulty is higher). |
|
|
|
As expected unless you hit some 1M+ shares...
LOL, 17% less than PPS? .. I dont think thats, "expected" .. "expected" would be hovering around 100% pps.. and deviate from that up n down .. if I can maintain a 117% pps for just as long a period, then I will retract my statement that the formula is broken...till that time, its broke =P The Pay-on-Target payout distribution is highly asymmetric. You don't get roughly equal numbers of above-average and below-average shares; rather, you get (with a = 0.8 ) 87% of the shares to be lower than average, then once in a while you hit the jackpot. Maybe you will soon get that big win that will bring you back to the black, maybe not. This of course does not rule out the possibility of an issue with the implementation. |
|
|
|
Oh, I'm only using a lone BFL Single, but my varr diff is manually set to 2. Would that affect my earnings much? From what I can tell, a manually set work_difficulty makes for higher-paying high-diff shares, but fewer low-paying low-diff shares. Is this correct?
Sort of. You get paid the same as if the shares you submitted were only half the difficulty the are(since vardiff = work_difficulty =2), but multiplied by 2. Think of it like this: Reward per share = function(share_difficulty/work_difficulty) * work_difficulty So playing around with Kano's calculator (Thanks, btw! Just what I was looking for), it seems that manually setting work_difficulty to a higher value does increase the payout per share by a bit, at almost any share_difficulty. How is this offset? Just the fact that fewer shares are submitted? Yes. By upping the work_difficulty, shares which are less than the new value will not be paid at all. This offsets the higher payment for the shares that are paid. I understand your first formula (the on in the OP) pretty well, the second I'm having a harder time wading thru. At this point, I'm just trying to figure out practical applications.
The second formula is what allows you to maintain the same average fee while capping the payout. It's more complicated, and that's part of the reason I'm not so enthusiastic about capping. heh well I guess I need to check what OzCoin is using at the moment - coz that's what matters
(I'm not sure they've updated it yet to whatever the next version of the calculation is)
I put the equations I'm using at the moment at the bottom of the web page
(and the cap I'm using is simply a cap on 'Your Share Difficulty')
Edit: i.e. I'm using the OP post equation
Well if Graet is capping the shares but hasn't updated the formula, he's effectively taking 4% extra fee on top of the advertised fee. I hope this will be fixed soon. |
|
|
|
Meanwhile ...  Rather than typing numbers into my desktop calculator over and over ... I wrote this: http://tradebtc.net/potcalc.phpThe defaults (which you can change before you press 'Calculate' are a=0.8 Cap=1.5 Fee=3%) I'll change the defaults to whatever Graet sets them to ... when I notice they've changed I don't think you used the constant factor that corrects for share capping. Yeah I was applying it to share count  I've changed it to cap the share value ... hopefully that's correct. I'm not sure we're on the same page, the formula for payout is [(1-a)/(1-a*wd^(1-a)*X^(a-1))]*(wd*B/D)*(min(X,sd)/wd)^a So letting a = 0.8, wd = 1, sd = 10, D = 3370181.7992778, X = 1.5D you should get 9.42407*10^-6 Rather than 9.08*10^-6 as in the site. He's including the 3% fee, which makes it closer. When are you applying the fee, kano? Sorry, I included the fee too, ETA. The calculator simply uses the (1-a) factor rather than the [(1-a)/(1-a*wd^(1-a)*X^(a-1))] factor. |
|
|
|
Meanwhile ... Rather than typing numbers into my desktop calculator over and over ... I wrote this: http://tradebtc.net/potcalc.phpThe defaults (which you can change before you press 'Calculate' are a=0.8 Cap=1.5 Fee=3%) I'll change the defaults to whatever Graet sets them to ... when I notice they've changed I don't think you used the constant factor that corrects for share capping. Yeah I was applying it to share count I've changed it to cap the share value ... hopefully that's correct. I'm not sure we're on the same page, the formula for payout is [(1-a)/(1-a*wd^(1-a)*X^(a-1))]*(wd*B/D)*(min(X,sd)/wd)^a So letting a = 0.8, wd = 1, sd = 10, D = 3370181.7992778, X = 1.5D, B = 24.25 you should get 9.42407*10^-6 Rather than 9.08*10^-6 as in the site. |
|
|
|
Meanwhile ... Rather than typing numbers into my desktop calculator over and over ... I wrote this: http://tradebtc.net/potcalc.phpThe defaults (which you can change before you press 'Calculate' are a=0.8 Cap=1.5 Fee=3%) I'll change the defaults to whatever Graet sets them to ... when I notice they've changed I don't think you used the constant factor that corrects for share capping. |
|
|
|
|
Alberto has paid additional 25 BTC, and says more should come soon.
In other news, I got a full list of bondholders from Nefario. A few payment addresses are still missing which I am working on reconstructing by mailing the bondholders. In a few days I should finish integrating the new data and dispense the latest payment to previously and newly confirmed bondholders.
|
|
|
|
Bitcoin addresses stored for notification purposes have been deleted. Addresses are now stored as a SHA 256 hash of the address, which removes the ability to lookup a wallet by bitcoin address.
It does not. If that address has received any payment, it's trivial to brute force SHA256 hashes of all addresses on the blockchain until you find a match. If you're serious about preventing lookup by address, use a slow hash. The secret salt used in the hash should prevent brute force of all addresses. . . . Addresses are hashed with a secret. With access to the secret it would be possible to hash every bitcoin address with a none zero balance and use that to compare against subscribed hashes to determine addresses in a wallet. The sacrifice of some anonymity when notifications are enabled has always been stated https://blockchain.info/wallet/anonymity. However it is no longer possible for admins to lookup an arbitrary wallet by address. My comment didn't make sense anyway, I got the process reversed. If the secret is unknown to admins it should work. |
|
|
|
I ready your paper and got most of it. I have to admit my knowledge of binomial distributions and such is a little rusty, but I get your points. Of course, rhetorically speaking, what is the optimal balance between the proof of work difficulty and the target time between blocks? Why not reduce the target time to 30 seconds instead of 10 minutes? Great paper, though, and thank you for your contribution, certainly worth a donation.
Finding out an optimal tradeoff would require more analysis. Essentially, about t/T of the honest network's total hashrate is lost due to forking, where T is the time between blocks and t is the typical time to propagate a block on the network. If we assume t = 10 sec, then for T=10 min 1.7% is wasted, and for T=30 sec 33% is wasted. How this compares with the ability to get more confirmations in a unit of time depends on the specific scenario. The additional resource cost to SPV clients (inversely proportional to T) should also be considered. I had a suggestion once for self-adjusting dynamic block frequency but I don't think it's really going to work. Even with a static system 2-3 minutes is probably better than 10, but I doubt this will be changed for Bitcoin. Thank you for the donation. |
|
|
|
You don't need proof of anything to tell if there were double-spends - if there are two transactions spending the same output there's a double spend. (And a computer would be much better than a human in finding that out.) Yeah, I guess the part that I don't quite understand is what is the incentive for a proof of stake signer to verify the correctness of a series of blocks that he didn't participate in? Signature fees. Like the transaction fees we know, but payable to stakeholders providing signatures. Also, signing should be fairly cheap. |
|
|
|
|
I have some good news; I have received from Nefario a full list of PureMining bondholders. All bonds are accounted for, however, apparently some users did not file a claim and are thus identified only by an email address and no Bitcoin address.
Over the next week I will try to contact these people to obtain a payment address, check the list for consistency, integrate it into my current records and move forward with the payment plan.
|
|
|
|
If this is the wrong thread to ask this please point me in the right place but how on earth can "Proof of Stake" work in an automated way? Or does it require that the stakeholder (a human) go through all the recent blocks and make sure there's no double spending attacks?
You don't need proof of anything to tell if there were double-spends - if there are two transactions spending the same output there's a double spend. (And a computer would be much better than a human in finding that out.) Proof of work/stake/X exists to signal "this set of transactions is valid and any transaction that is a double-spend on any of them is invalid" in a way that guarantees that everyone agrees on the same set of transactions. As to how this is achieved you'll have to read the specific proposals (e.g. at https://en.bitcoin.it/wiki/Proof_of_Stake), the point is that the stakeholder's computer signs messages that affirm his support of a specific block, and the collection of such signatures is the signal. |
|
|
|
There may be some wisdom in the KISS method
(1-a)*(wd*B/D)*(sd/wd)^a is simpler than [(1-a)/(1-a*wd^(1-a)*(1.5D)^(a-1))]*(wd*B/D)*(min(1.5D,sd)/wd)^a. a^2/(1-2a) is simpler than -1+((-1 + a)^2 X (-wd^(2 a) X + 2 a wd X^(2 a)))/((-1 + 2 a) (-wd^a X + a wd X^a)^2). The expression for the variance is what you need to truly bound your risks. by putting a reasonable cap on max reward as opposed to taking a "1 in a quintillion" chance of something astronomically bad happening.
Have any of us said "the chance of X happening is so remote that we don't need to worry about it?" I have, and far too many times I've had to follow up by saying "ain't never seen that before".
You should distinguish 1. Hunches that something is unlikely, or derivation of probabilities based on strong assumptions of dubious truth value from 2. Probability derivations for essentially pure random processes where there are virtually no relevant assumptions. #1 are only as good as your process - in other words, usually not very good. #2 Really do mean something. Something that has a true probability of 1 in a billion to cause, say, my own death, is really nothing to worry about. |
|
|
|
Personally I'd prefer a smaller a which would make the cap unnecessary.
The maximum value of a share is still effectively unbounded, even for smaller a, so a single share can still bankrupt the pool. This seems to me to be a different type of risk from that which a PPS operator takes, for example - where the rate at which the pool can lose money is clearly bounded. Yes, but it's a " so you're telling me there's a chance" can. With a=0.4 and wd=1, the chance that a share will cause a loss of more than a reward of a single block is about 1 in a quintillion, I think they can handle it. |
|
|
|
Another issue that's bugging me is the effect vardiff has on share payment. It is totally reasonable that if the base diff is 10x higher then the value of diff 10 shares is different to diff 10 shares for diff 1 miners, but when the diff is above 10, the value of each share should actually converge (at some point, not sure where) from both diff 1 and diff 10 miners.
Not sure that I agree. Edit: It should be fixable but it will greatly complicate the calculations. I'd need to figure out how. |
|
|
|
ooc mentioned we have now inadvertently introduced an effective fee with the cap, will have to look at the value of this and work out best way to handle it.
.. and Meni just did all that: If you cap sd so that it is never more than X, you should use instead
[(1-a)/(1-a*wd^(1-a)*X^(a-1)]*(wd*B/D)*(sd/wd)^a
and it only took a few minutes, too (insert jealous grumbling here). It would have taken more without my silicon overlord. Or less if it did a better job with the final simplification. I don't think it would be off topic if you showed us how you derived that?
Wlog we assume wd*B/D=1. The pdf of sd for sd>=wd is wd/sd^2 and the payout is (sd/wd)^a. So without a cap and without a constant factor, the expected payout is \int_{wd}^{\infty}(wd/sd^2)(sd/wd)^a\ sd This is 1/(1-a), and thus we need a constant factor of (1-a) to make this equal to 1. With sd capped to X the integral becomes \int_{wd}^{X}(wd/sd^2)(sd/wd)^a\ sd + \int_X^{\infty}(wd/sd^2)(X/wd)^a\ sd The second term is (X/wd)^(a-1) and the first term (by subtracting the primitive function at the endpoints) is (1-wd^(1-a)*X^(a-1))/(1-a). Add to get [(1-a*wd^(1-a)*X^(a-1))/(1-a)], so the constant term should be [(1-a)/(1-a*wd^(1-a)*X^(a-1))]. Meni has already done this for standard PPS, but I'm not sure if his derivation applies to random variables with infinite variance.
It's not. It would be interesting to figure out if it's possible to bound the bankruptcy probability with infinite variance, I'm inclined to think that it's impossible. Now I'm not sure if the probability of bankruptcy is 1, or if it is bounded but only polynomially. Discussion of the variance of this will follow.
With solo mining, the relative variance is roughly D/wd. With the uncapped pay-on-target payout, it is a^2/(1-2a). With the capped formula, the variance is -1+((-1 + a)^2 X (-wd^(2 a) X + 2 a wd X^(2 a)))/((-1 + 2 a) (-wd^a X + a wd X^a)^2) Which for a>1/2 grows like X^(2a-1). Whatever the variance, as long as it is finite it can be plugged into the PPS safety net analysis. With a cap you can even make a greater than 1. Solo mining is essentially this with a = infinity and X = D. Normal PPS is X = wd and a can be anything. |
|
|
|
Looking at feedback, thinking, talking with others our next experiment will be at a= 0.8 which brings back in high variance but share value will be capped at 1.5*D (5055272) to reduce chance of pool going broke Personally I'd prefer a smaller a which would make the cap unnecessary. But if you do place a cap you need to tweak the constant factor, let me work on it... Edit: The current formula is (1-a)*(wd*B/D)*(sd/wd)^a. If you cap sd so that it is never more than X, you should use instead [(1-a)/(1-a*wd^(1-a)*X^(a-1))]*(wd*B/D)*(sd/wd)^a And then you will again have an expected payout of wd*B/D per share. Discussion of the variance of this will follow. Meni has already done this for standard PPS, but I'm not sure if his derivation applies to random variables with infinite variance.
It's not. It would be interesting to figure out if it's possible to bound the bankruptcy probability with infinite variance, I'm inclined to think that it's impossible. |
|
|
|
The long point is, PoW is working and we can see that it does work. There is no evidence, at the present, that it would not continue to work well. Whereas there is a lack of evidence that PoX methods offered can actually live up to their promises. Don't fix what ain't broke.
We can see that if we sponsor PoW with 25% annual monetary inflation it works, yes. Hypothetical scenarios for how it can work in the future are hypothetical. Anyway, we'll do just what you suggested - research new solutions and try them out in alts, so if it ever is broken we'll be ready with a fix. Edit: Actually quite a few things are wrong with this Walmart thing, but the main issue is - even if it does make strategic sense for them to mine, this will incur a cost, and to maintain the same level of profitability they will have to increase the prices. So the customers still pay indirect transaction fees as a result of the need to sponsor mining, TANSTAAFL. How much exactly is a subject for a different debate. |
|
|
|
|
Show Posts
