You didn't specify which pool this is. It's possible that the pool hasn't found a block in 12 hours and therefore the figure wasn't updated.

What is this quantity supposed to represent? It looks like you consider it to be meaningful but I just don't see it. Sn itself is the number of shares submitted in n rounds, isn't this what you're trying to analyze?

Also, if by the LHS you mean "probability that X is in the set {S1,..., Sn}", why would it be equal to the RHS?

FYP.

Nefario, please do something like only make a captcha after a failed login, or make an opt-out in the settings. It's not much help anyway, if the password is any good it can't be brute-forced.

@kano I suggest you look up the word "Large". Since you clearly have no interest in carrying out a reasonable discussion and would rather play dumb and ignore what your interlocutor says, I'll refrain from further responding to you.

For reference, here is my previous correspondence with kano about this issue.


I'll clarify one thing. In operator-risky methods like PPS, geometric method, DGM, the operator can either gain or lose on a round. These movements are in the operator's personal funds. Just like a riskless pool (like PPLNS) can collect fees for the service, so can a risky pool collect high or negative fees on a per-round basis. The variability in the operator's income is a risk he is willing to take in order to make the pool more attractive.

For his own personal accounting, the operator would do well to set aside a portion of his funds as the pool's "reserve". This makes sure that technically the funds have a place to come from, and allows a better handle on profits or loss. He could share information on his reserve if he wants. But this is still his own funds, which he can take away or add to as he pleases. The current reserve has no effect on the attractiveness, in terms of expected reward, variance and maturity time, of mining in the pool.

If the reserves run out, it is the operator's choice whether to allocate more of his funds to the pool, or to shut the pool down. Other than having to look for a new pool (which is not to be taken lightly), this has no ill effects on the miners - the debt to them, expressed as unrealized score, will be cashed out immediately based on the expected reward for it. Since the total possible debt is bounded (the bound can be controlled with parameters), the operator can simply set aside the necessary amount as an "emergency fund". There is no risk of growing an unbounded debt and then not being able to repay.

DGM settles good and bad luck on time and vents it as miner reward variance (or in the worst case, only likely with aggressive parameters, a clean bankruptcy). This allows it to continue in a sustainable steady state. SMPPS defers having to deal with luck indefinitely, until one day the debt grows so large it can no longer continue.

I have already provided Nefario with some identifying information and will provide more. He is still processing it.

In case this question was inspired by the Goat issue, Nefario has multiple channels to communicate with me, and I will be actively looking for ways to minimize the probability of someone cracking my account, and to keep the potential damage in this contingency at a level I can absorb. (eg, I may request Nefario to only allow changing my password if I ok it over the phone, or to stiffen the conditions under which new bonds can be issued.)

It will probably be on Thursday or Friday.

WTF???

In SMPPS the buffer affects the attractiveness of mining. Low (highly negative) buffer = miners will leave.

In DGM the "buffer" does not affect the attractiveness of mining. Thus there is no reason to know it, it's a property of the pool operator, not of the pool. I don't tell you how many bitcoins I own either.

In SMPPS there is debt which can go arbitrarily high. If the pool collapses while it is still in debt to you you are screwed (and this will happen when everyone leaves due to low buffer).

In DGM the debt is bounded and so the pool can (and should) pay back the debt if it closes for any reason.

In SMPPS the variance of the buffer is 100%, in DGM it can be controlled with a parameter.

The claim that DGM "attempts to be SMPPS" is outrageous.

As I said before, I'm extremely weary of having to deal with your hostility and explaining the same thing over and over again multiple times.



Anyway, as long as I'm here:

You talk about the maturity time, but it should be emphasized that the value I'm analyzing is the time of average payback, not the time of being paid in full. For example, if you get 50% of the debt back in 1 round and the other 50% in 3 rounds, your maturity time is 2 rounds.

The second chart, giving the PDF of the pool debt after n rounds, looks completely wrong, I have no idea how you got that. The pool debt, assuming constant difficulty, is (X/D - n)*B, where X is the number of shares it took to get n blocks, which is distributed negative binomial. So it's really a shifted negative binomial, which doesn't have the cusp we see.

I don't think mining should be sensationalized. It's an important job that needs doing, and those who have the skills, opportunities and willingness to do it are rewarded for it. If you don't do it someone else will. Specifically, by refraining from mining, you would decrease the difficulty, making it profitable enough for someone else who would otherwise not mine (or mine in lesser capacity). The new equilibrium will be at a lower global hashrate (hence, lower network security), but the decrease is less than your own capacity.

This. The whole point is that your payments do not depend in any way on anything that I do. If you buy 50 bonds you get 50MH/s worth of payments according to a deterministic (up to external conditions) algorithm.

So buying my own bonds has no functional effect, though it could have perception effects. In any case I only keep a symbolic amount for testing purposes.

I bought 10 bonds, mostly for testing purposes.

Yeah, demand had some time to build up while we were waiting for issuing to be implemented.

On that note, I no longer consider this a proof of concept, there's serious money involved, and I plan to issue more bonds over the next 6 weeks.

For now, I will issue 1000 more bonds later this week.

I have issued 500 new bonds (a total of 1000), at 0.36 BTC per bond.

Coupon payment summary for March 2012 (total 0.020971201 BTC per bond):

Sounds about right, though I'm not sure step 1 is necessary.

You didn't interpret investopedia correctly.

Stop: Either sell if the price is below a point, or buy if the price is above a point.
Trailing stop: Like stop, except the price is dynamic. If the current price is $5 and you put a trailing stop sell for $4, if the price goes up to $10 your new stop point will be $9 (or $8 if you defined it as a percentage). Likewise for buys.

Don't look at the source code, look at BlockExplorer, that's the best way to understand how it works.

Again, this can be included in a new protocol (which allows forcibly merging several outputs of the same address), but in the current protocol, knowing the balance of every address is useless.

Is that possible? And more importantly, why on earth would I want to do that? Making an IPO is cumbersome and costly. Having to keep track of two equivalent tickers until they are merged, and the merger itself, are sources of difficulty and confusion.

PS Ways to split and merge assets are going to be useful for an unrelated asset I have in mind.

SMPPS is not hopping-proof and is not sustainable.

Shift- versions of PPLNS and DGM are probably more scalable.

I think the fact that Bitcoin works on outputs, rather than addresses, is lost on you. An address is merely a representation of the terms under which an output can be spent.

If your client wants to work with the existing network, it needs to understand the language of outputs, and it needs to only accept a transaction if the network will agree that its inputs are valid, unspent outputs.

If your client receives an incoming transaction, even if it knows that the sending address has a positive balance, if it doesn't know where the balance came from, it can't tell if the new transaction is really a re-spending of an old output which was spent long ago. If it is the network will not accept the transaction.

As far as I can tell this is only possible with a fundamental protocol break, which may have many unintended consequences, and is of questionable utility. I wouldn't bet on it being implemented in Bitcoin ever, and definitely not in the next few years. It might work for an alt though.

FWIW, I myself am a proponent of some fundamental protocol breaks which I hope will be made one day, but for those I can make a very strong case for their necessity.

@Dabs: If you're not changing the protocol, can you specify exactly what can your client do that a standard lightweight client can't? In case the answer is "verify that incoming transactions are valid", how exactly does it do that if it doesn't know what are the outputs contributing to a summary, and thus can't know if the same output is spent twice?

Yes.

I don't think the current system allows the market to be efficient in setting the price. Each issue upsets the balance and bidders need to worry that if there's an issue their bids will be much more lossy than with normal market movements.

There's information disparity in announcing new issues in advance based on when people browse the forums. If someone learns of the issue before the bidders, he can execute their bid planning to buy back at the issue. This still means that bidders can't safely bid when future issues are a big unknown.

It is slightly better than if I hadn't announced in advance with the current system; but ideally, I should be able to issue new shares without any prior announcement.