So the dividends received will all be passed through as dividends paid, and the changes in value of the holdings will only contribute to growth?
Yes. Hopefully this will have a steadier payment, and therefore a simpler valuation model for investors and traders of MU.  |
|
|
|
|
9th Payment
Calculation time: August 8, 02:53:19 forum time
Number of difficulty change: 0
Number of block reward change: 0
Time interval:
Starting from: August 1, 03:58:02
Ending at: August 8, 02:53:19
Total time: 600917
Difficulty: 2,036,671.09
Hashrate of this week: 1.25907MH/s
coupon/share = (1.25907*10^6)/(2^32)*(600917*50/2,036,671.09)=0.0043247
Number of Shares: 5153
Total Payment: 22.2851791
|
|
|
|
|
Update
It might be already noticed that we took a very unconventional way of calculating net gains from the start. After much consideration, we decided to use a more traditional approach.
Before: dividends = 35% of net gains (calculated against the average buying price)
NAV = market value of total assets + total BTC funds - dividends
After: dividends = 100% of dividends from total assets
NAV = market value of total assets + total BTC funds - dividends
By this method:
Investors could have more steady weekly payments.
Fund manager could feel more comfortable to do larger bulk of buying and selling without triggering too much investors' concerns.
A motion is raised for the shareholders to approve or disapprove this change of dividend structure. If disapproved, we will return to our original calculation from the next week.
|
|
|
|
|
Weekly Financial Disclosure
Time: 10:20 AM, Beijing time
Date: August 8, 2012
Funds of Last Week: -0.657BTC
Number of Total Shares in Circulation: 5000
Assets:
JLP-BMD
Holding: 1569shares 186.711BTC
Dividends Paid: 1.539BTC
YABMC
Holding: 1450shares 179.800BTC
Dividends Paid: 5.012BTC
PIMP
Holding: 1382shares 203.154BTC
Dividends Paid: 4.908BTC
MOVETO.FUND
Holding: 150shares 163.350BTC
Dividends Paid: 0.000BTC
BFLS
Holding: 74shares 81.400BTC
Dividends Paid: 1.408BTC
Cognitive
Holding: 184shares 137.816BTC
Dividends Paid: 0.505BTC
BDT
Holding: 87shares 91.350BTC
Dividends Paid: 2.610BTC
BTC
Holding: 34.455shares 34.455BTC
Holding After Dividends: 18.473BTC
Calculated Dividends: 1.539+5.012+4.908+0.000+1.408+0.505+2.610=15.982BTC
NAV: 186.711+179.800+203.154+163.350+81.400+137.816+91.350+34.455-15.982=1062.054BTC
Weekly NAV Growth: (1062.054-1117.706)/1117.706=-3.97%
|
|
|
|
|
Update
After further optimization and some trade-offs, we came up with this updated estimation results based on our improved design.
Hashrate: 1.00GH/s per chip
Area: 21.7mm^2 per chip
Power Consumption: 8.23W
Again remember that they are estimated from the RTL design and might have some differences to real products.
|
|
|
|
|
8th Payment
Calculation time: August 1, 03:58:02 forum time
Number of difficulty change: 1
Number of block reward change: 0
Time interval:
Starting from: July 25, 03:14:26
Ending at: July 30, 10:53:56
Total time: 459570
Difficulty: 1,866,391.31
Starting from: July 30, 10:53:56
Ending at: August 1, 03:58:02
Total time: 147846
Difficulty: 2,036,671.09
Hashrate of this week: 1.24797MH/s
coupon/share = (1.24797*10^6)/(2^32)*(459570*50/1,866,391.31+147846*50/2,036,671.09)=0.0046320
Number of Shares: 5540
Total Payment: 25.66128
|
|
|
|
|
Update
As you could see, the usable funds is temporarily negative. That's because we made our positions heavier therefore the left funds were not enough for the payment of dividends. Currently I covered the difference. You could see this as MU got an interest-free loan of 0.657BTC for a week from myself. Thanks.
|
|
|
|
|
Weekly Financial Disclosure
Time: 10:38 AM, Beijing time
Date: August 1, 2012
Funds of Last Week: 60.212BTC
Number of Total Shares in Circulation: 5000
Assets:
JLP-BMD
Original: 1569shares 393.819BTC
Bought in: 0shares 0.000BTC
Average Holding Price: 0.251BTC
Sold: 0shares 0.000BTC
Average Selling Price: N/A
Holding: 1569+0-0=1569shares 393.819BTC
Net Gain: 0.000BTC
Dividends Paid: 1.490BTC
YABMC
Original: 1450shares 377.000BTC
Bought in: 0shares 0.000BTC
Average Holding Price: 0.260BTC
Sold: 0shares 0.000BTC
Average Selling Price: N/A
Holding: 1450+0-0=1450shares 377.000BTC
Net Gain: 0.000BTC
Dividends Paid: 5.401BTC
PIMP
Original: 1000shares 198.000BTC
Bought in: 382shares 57.782BTC
Average Holding Price: (198.000+57.782)/(1000+382)=0.185BTC
Sold: 0shares 0.000BTC
Average Selling Price: N/A
Holding: 1000+382-0=1382shares 255.782BTC
Net Gain: 0.000BTC
Dividends Paid: 5.223BTC
MOVETO.FUND
Original: 150shares 150.000BTC
Bought in: 0shares 0.000BTC
Average Holding Price: 1.000BTC
Sold: 0shares 0.000BTC
Average Selling Price: N/A
Holding: 150+0-0=150shares 150.000BTC
Net Gain: 0.000BTC
Dividends Paid: 0.000BTC
BFLS
Original: 84shares 84.000BTC
Bought in: 0shares 0.000BTC
Average Holding Price: 1.000BTC
Sold: 4shares 4.400BTC
Average Selling Price: 1.100BTC
Holding: 84+0-4=80shares 80.000BTC
Net Gain: (1.100-1.000)*4=0.400BTC
Dividends Paid: 1.526BTC
Cognitive
Original: 203shares 127.890BTCBTC
Bought in: 0shares 0.000BTC
Average Holding Price: 0.630BTC
Sold: 15shares 11.850BTC
Average Selling Price: 0.790BTC
Holding: 203+0-15=188shares 118.440BTC
Net Gain: (0.790-0.630)*15=2.400BTC
Dividends Paid: 0.459BTC
BDT
Original: 0shares 0.000BTCBTC
Bought in: 87shares 87.000BTC
Average Holding Price: 1.000BTC
Sold: 0share 0.000BTC
Average Selling Price: N/A
Holding: 0+87-0=87shares 87.000BTC
Net Gain: 0.000BTC
Dividends Paid: 2.610BTC
Holding Funds=
60.212-0.000+0.000+1.490-0.000+0.000+5.401-0.000+0.000+5.223-0.000+0.000+0.000-0.000+4.400+1.526-
0.000+11.850+0.459-87.000+0.000+2.610=6.171BTC
Total Net Gain=
0.000+1.490+0.000+5.401+0.000+5.223+0.000+0.000+0.400+1.526+2.400+0.459+0.000+2.610=19.509BTC
Calculated Dividends: 19.509*35%=6.828BTC
Usable Funds: 6.171-6.828=-0.657BTC
Actual Dividends: 6.828BTC
NAV: -0.657+1569*0.129+1450*0.146+1382*0.195+150*1.138+188*0.769+50*0.650+87*1.000=1117.706BTC
Weekly NAV Growth: (1117.706-1233.619)/1117.706=-10.37%
|
|
|
|
Interesting information. Looking forward to the more optimized numbers. I'm sure you guys have thought of this before but, if you haven't, once you guys have a commodity chip you may want to chat with Enterpoint. They've shown interest in Bitcoin, appear to be working quite hard on their product, and their first hardware design was impressive given how little time it took to release. Sell the chips in bulk reels, provide the pinout and let Enterpoint create the PCB, VRM and controlling FPGA to handle a couple of these chips per board. Could be a great partnership and dramatically accelerate the time to market of such a product.
In the end I'm fairly certain you'll recover your costs faster by selling your chips than by mining them yourselves. Especially if you believe that BFL and Largecoin will deliver sometime in 2013.
Thanks. It sounds promising. We have thought of this but Enterpoint hasn't come into our mind before. We will definitely do some research on it. |
|
|
|
I tend to agree.
I have to ask. What will be the potential market share when pitted against BFL *if* BFL uses a 90 or 65nm process?
In my mind this would have to be a market battle fought on unit price.
Thanks for your question. There will indeed be a market battle. The question is how intense it will be and when we will reach a relatively stable equilibrium. In my opinion, there's still a long way to go before the market price falls down to the same magnitude to the margin cost. Before that, all ASIC vendors would be quite profitable. |
|
|
|
13 Watts is not that bad, and if you could improve it, brilliant, but it's still in the region of some of the more powerful Intel Atom chips and they are not hard to cool down. Also with going down to 65nm (and lower) designs eventually I assume you'll be going to very low single digits which is awesome, by the nature of scaling.
Great Job !
Thanks for your appreciation. We are on our way of lowering the power consumption down to less than 10W while keeping the same hashrate per mm^2. And please don't rely on the data too much because the back-end stage's power estimation makes more sense. |
|
|
|
You might not want to spend too much time on your own miners if your tape-out is successful. I'd do a reference PCB design, test it, and release it asap together with the chips. You'll make much more money selling the chips and maybe licensing the reference design, than by mining yourself. Time is your enemy here.
Of course, but product quality and customers' words of mouth are the life of a company. But we don't want to sell prototypes. We want to sell mining devices with a higher standard. We ourselves could probably handle second-digit rates of failure, some heat issues, and sketchy appearances. But we wouldn't want our customers to have to deal with them. |
|
|
|
|
Update
We decided to apply more manual optimizations to further increase the power efficiency. Since our chips will be mass produced, we believe some more time spent on making each chip better is worth it.
|
|
|
|
As long as your plan isn't to hold onto everyone's money for months, you'll sell a bunch of these. I'd buy a few units just to support the network and not give a crap about mining returns. I think many others would as well.
Also, if you really hope to have success selling these units, just get them ready before BFL and you're going to sell as many as you can produce.
We divide our business into two large stages. The first one is to make prototypes consumed by us. The second one is to design higher quality mining devices for selling. Or in the second stage we could find some partner to do the whole PCB/case/repairing/custom service/logistics for us. But both options need more time. So thanks very much for your expectation, but it will be later to deliver nice products for sale than deploying the first batch of chips for ourselves. |
|
|
|
Essentially the whole hashing chip is hot.
Yes, especially that the hashing units themselves take over almost all the chip area. What makes sense is to use a single chip with split clocks and split power supply. One clock and power for the "core" and one clock and power for the "I/O".
Yes. We made this decision from the start. The typical voltage for powering the I/O is way too high for the whole chip. The split you suggesting also makes sense for the "full custom" versus "cell library" choices. Use "full custom" for the core hashing round and "cell library" for all the glue logic. But I don't think that the fab the Block Erupter uses would allow them to do this. It seems like they are committed to the cell library only design.
Exactly. In fact the glue logic only occupies a tiny part of each chip, all the rest parts are for hashing. And a full custom design is too impractical for us. Thanks again for your link. |
|
|
|
13W at 17 square mm - seems like a significant mount of heat to deal with. When I was a kid, I used to have a 25W soldering iron and it was melting solder perfectly well. Well, directly decreasing both the voltage and the frequency will dramatically reduce the power consumption. But the hashing rate per wafer will also reduce. This statistics is basically a result of trying to drive the hashrate/area to the highest given our 130nm choice. We will fix the whole design in the earlier iteration of back-end, then we probably will get a better compromise. Yeah, I was just saying that one of your challenges will be how to drain the heat out of the tiny chips. Especially assuming that you'd probably want to have a single PCB with many of such chips working in parallel. This kind of heat density is not very common. The hardware implementation of SHA-2 involves too many unavoidable registers, and they all flip frequently. Larger heat sinks will do the work, but they reduce the density of chips on a single PCB. Also we have clock-lowering and the voltage-lowering as the last resort. Anyway this problem will definitely be tackled. Fortunately our first batch of chips will probably consumed by ourselves, so the requirements of PCB design will be lower than that of a full-fledged Rig design, and heat issues are more tolerable at this stage. Of course, making high-quality mining devices that's usable by retail buyers is another story, and more challenging. |
|
|
|
So about 5 times better than current LX150 chips/bitstreams in terms of hash rate per watt, is that about right? And this is on 130nm? Are you able to guess how much improvement might be had with a straight die shrink?
It's hard to give an accurate guess. But I believe that the power consumption is (way) proportional to total area if the circuit structure does not change. We haven't investigated die shrink from the foundry yet but currently anything beyond 130nm is also beyond our budget. |
|
|
|
13W at 17 square mm - seems like a significant mount of heat to deal with. When I was a kid, I used to have a 25W soldering iron and it was melting solder perfectly well. Well, directly decreasing both the voltage and the frequency will dramatically reduce the power consumption. But the hashing rate per wafer will also reduce. This statistics is basically a result of trying to drive the hashrate/area to the highest given our 130nm choice. We will fix the whole design in the earlier iteration of back-end, then we probably will get a better compromise. |
|
|
|
|
Update
Our RTL design, optimization and simulation are finished. We have some data to predict the specification of actual chips after they are manufactured.
Hashrate: 1.25GH/s per chip
Area: 17.5mm^2 per chip
Power Consumption: 13.3W
Note that they are calculated from the front-end design and not accurate enough. But of course the possible difference range won't be large. We will keep our updates.
|
|
|
|
Oops. I read 2012-07-24 23:41:46 as 2012-07-24 24:41:46
In any case, I bought mo(o)re!
Thanks. And sorry again for the confusion brought. |
|
|
|
|
Show Posts
