There's also some variance (caused by luck in future finding of blocks), not just delay. Of course, over the long run it should not be significant.

That's all you can say! That's all you can say, that's all you can say...

Take a look at this post about oblivious mixing transactions.

I agree that this FAQ answer is poorly worded. I guess it was intended as "relative to proportional". Proportional loses to hopping, DGM is indifferent, so cross-relatively, DGM gains from hopping - [(Hoppers in DGM - normal miners in DGM) - (Hoppers in Prop - Normal in Prop)] = [0 - negative] = positive.

This gives me an idea, it would be nice to see a chart of (exchange rate + total of dividend per share paid so far). This way we can see how well someone who bought a share at a given point in time fared.

Also the charts don't display the total number of shares issued, which is a handy piece of information. Maybe even a chart of total issued.

As far as I can see it's measured both ways. In the markets section, the 1d and 30d volumes are displayed in large font for number of shares, and in small font for number of BTCs. In summary there is "volume" which is number of shares, and "volume in currency" which is number of BTC. In the charts there's a checkbox to choose "volume in currency", which when unchecked gives shares.

The only problem I see is with the label, in "summary" the volume says "6 BTC" instead of "6 shares", but the number 6 is the number of shares.

Can you explain some of the deficiencies?

Is that wise? Bitcoincharts works and is familiar to the Bitcoin community. Why spend time on creating a charting platform?

In some sense, pretty much any reward system is similar to a capacitor if you stretch the analogy enough. But quantitatively, DGM behaves much more like a physical capacitor than other methods, which is why the analogy is more appropriate for it.

Notably, in hoppable methods the effect of shares on the capacitor depends on the pool's history, so some times are better than others.

DGM doesn't care about the pool's history. When you mine continuously the capacitor is at its full charge level (with some caveats irrelevant to the current topic). When you stop mining the capacitor starts discharging in a way that doesn't depend on the fact that 6.7M shares were already submitted in the round. What matters is not that you missed 20% of the block, but that you didn't mine for 1.7M shares, which with the current parameters is enough for your score to decay to the 40% level. Other hopping-proof methods are similar.

The mistake people make is thinking that the proportional method is some sort of gold standard other methods should measure up to. It's not, it's just a broken method. Looking at the % of shares submitted in the current round is meaningless.

If you take a look at the lending subforum you'll see people lending and borrowing at all sorts of interest rates.

And, as notme says, borrowing in Bitcoinica is only against collateral, and only for trading.

Strictly speaking you don't have to wait that long; you can put up a bid at a price which is attractive for you and hope some early adopter will want to cash out at a profit.

I will of course post when new bonds are issued.

I can't guarantee anything one way or the other, but I expect about 1 month from now to be the general timeframe for making another issue.

There will be some difficulty decrease at that point, because marginal miners will pull the plug when it swaps from profit to loss. But in addition there will be a slowing down of the increase before that, as people who would otherwise purchase hardware will avoid it due to the imminent decrease in profitability.

The price of BTC will also be affected; the simplest projection is that if you compare a short time before the halving with a short time after it, the difficulty will drop by 2^(1/3), the price will increase by 2^(1/3) and the fiat profit per hash will decrease by 2^(1/3).

The initial offering of 200 bonds is sold out.

I've also put up a bid myself to act as a baseline for liquidity.

I think it's healthy that the bonds are now in the hands of investors and that increases in exposure, trust and demand will drive up the price. What will really affect my bottom line is what the valuation will be when I issue larger amounts.

Did you ever hear about giving someone the benefit of the doubt? It means you don't immediately call someone a thief when there's a technical problem with their site.

Searching also isn't that hard, https://bitcointalk.org/index.php?topic=67022.0.

Others have also expressed this sentiment, and it's great to hear - but it's moot if not accompanied by people actually buying.

It could be argued that I'm being impatient, but it's a fast-paced world, and I don't really expect more uptake later on if there was little during the excitement of the original announcement.

To be honest I was hoping to attract "old" investors who are currently invested in other mining assets. Also, GLBSE has its faults but I don't think the barrier of entry is too large. For me as an issuer it was a bit intimidating until I realized the "contract builder" is completely irrelevant. Once one creates an account it gets the job done.

Anyway, the trading platform used is one of the components that go into the measurement of level of interest. If there is interest but not on this platform, it subtracts from the valuation.

No idea, I think this is some sort of legacy thing. When GLBSE 2.0 is live I'll make more effort to get some relevant exposure.

Thank you for your support. I'm still learning.

Well, it appears that the streamlined, deterministic nature of this bond isn't attracting that much interest. So I'd like to press further the advantage of the offering in terms of pure performance numbers. Re-evaluating my strategy of utilizing BFL products, it seems safe to offer bonds at a new, low price of 0.28 BTC. Since I'm still only issuing a small number of shares, I'm willing to take the risk that I'm wrong.

Once again I do not want early adopters (and current bidders) to be worse off than buyers at the new price. Given that there already are bids at 0.35 BTC, my exact order of operations was:

1. Pay a bonus 0.05 BTC per bond.
2. Issue at 0.35 BTC.
3. Pay a bonus 0.07 BTC per bond.
4. Issue at 0.28 BTC.

ROI projections for the new price:

Issue price - 0.28 BTC
Difficulty - 1496979 (recently increased by 9%)
Block reward - 50 BTC
Daily return - 672 uBTC (0.24% ROI) = 86400 * 50 * 10^6 / (2^32 * 1496979)
Weekly ROI - 1.68% (linear, non-compounded) = 7 * 0.24%
Monthly ROI - 7.32% (linear, non-compounded) = 30.5 * 0.24%
Annual ROI - 138% (compunded weekly) = 1.0168 ^ (365/7) - 1

This means that, if the current network parameters remain unchanged, the investment will more than double in a year. Of course, the parameters will not remain unchanged, so this will not be fully realized.

I will mention again that I am making a personal commitment to do whatever it takes to abide by the contract, regardless of the success of any mining operations I may have.

In principle, negative timespans which result from inaccurate timestamps can be solved by sorting the 2016 timestamps, taking differences between the sorted values, and setting a minimum value for the spans.

My comment (which is about timestamps coming from an exact, theoretical Poisson process) wasn't completely accurate. The fact that 1/E[1/X]=0 is only relevant if the number of timestamps is arbitrary. For the fixed number 2016, E[H] has a finite value, which is approximately 0.109*(10 minutes). For the geometric mean, E[G] = exp(E[log(X)]) = exp(-gamma)*E[X], independent on the number of intervals.

With multisig, will it not be possible to have two independent servers, where each of them can sign a transaction, but checks that it makes sense first? This is a solution which is both fully automated and more secure than keeping keys on a single server, even if encrypted.

Also there could be a multi-tiered approach. The hot server will have a small amount of coins for immediate use, requiring just local keys. In addition a larger amount of coins will be in a 2-of-2 address with keys in the hot server and a lukewarm server (which is more secure than just a key in the lukewarm server). If the hot server is close to running out, he polls the lukewarm server to send it some coins, which it will agree to only if the transaction makes sense, is in a limited amount, and it notifies the operator. This obviates the need for manual intervention in each and every transfer, while still offering damage control.

No, this isn't what this is, there really are serious display errors in blockchain.info. Neither blockexplorer nor blockchain.info have a habit of displaying tx fees paid to the miner as "negative tx fees". http://blockchain.info/block/0000000000000765555944646925edf0449cb6d33c7d8ecf335b01aec1d94ace is a summary of block 168425 which claims that the total transaction fees paid is negative, which is impossible. And if you look at the transactions in the block, many are displayed as having no input.

I wonder what kind of bug caused this, things are pretty messed up.

No, that's normal, tx fees are included in the coinbase transaction.

This is probably a bug in blockchain.info.

Coupon payment summary for February 2012:


In addition, 0.0015423250 BTC coupon for block 169343 was paid today.