Neither of these are tools to short BTC directly, but I'll mention them anyway, since you specifically mention a desire to "hedge" mining hardware costs: - There are "mining difficulty futures" sold on Bitfunder that pay out proportionally to the mining difficulty on their payout date. Lookup CoinBr.iDiff-O and CoinBr.iDiff-E.
- Just launched today on BTCT.co, there is DMS.SELLING, a fairly complex instrument that also should operate as a hedge against rising difficulty.
Both are somewhat complicated instruments; make sure you understand what you are buying before leaping in. |
|
|
|
And keep in mind that the PAJKA upgrade isn't dependent on the issuer receiving BFL hardware - he just uses this as a benchmark event to initiate the upgrade.
I don't quite follow this statement. From the OP:
The bonds will be upgraded for free to 15Mhash/s per bond when ordered ASICs are delivered to us.
What is the distinction you are trying to draw? |
|
|
|
|
Because of the flexible market control over total volume, this would be great for true price discovery on PMBs (and the .SELLING counterpart, whatever that asset is best conceptualized as) and for letting investors position themselves anywhere on the mining difficulty prognostication continuum. I would love to see this approved.
Regarding creation of additional DMS.PURCHASE units after the first dividends have been paid, do I understand correctly that would cheaper to, say, create 5000 DMS.PURCHASE units all at once rather than 2500 DMS.PURCHASE units on day 1, and then 2500 DMS.PURCHASE units on day 2, because the funds I used to create 2500 units from day 1 would now be baked into the NAV and increase cost on day 2 derived from the 1.05*(NAV/U) calculation?
|
|
|
|
Then if investors are smart, they'll bid up the price of TAT's bond to match the rate of return of PAJKA's within seconds of the issuance... The extra zero after the decimal in the share price for TAT means TAT pays better presently. I think hl5460 was trying to say TAT is a better deal and PAJKA is overpriced. But what complicates the comparison is the prospect that PAJKA will, at some future date uncertain, begin receiving a 5x multiplier to its dividend. TAT has no such prospect. |
|
|
|
|
If you are a windows user and want to run the coin, I'd wager it is more straightforward to install linux (e.g., Ubuntu 12.04) in a virtual machine and compile the coin there rather than try to compile a windows binary from the source code (relatively painful, from what everyone says). Virtualbox is free and works fine for this purpose.
With altcoin releases, this has the added benefit of "sandboxing" the new coin in a VM just in case there is harmful code designed to steal your wallets or what not.
|
|
|
|
I want to know ,when will you stop this IPO process??? if you always issuing new contracts...it make very difficult for us to selling our contract without loss....seems we are obligate to fee the 0.8% trading administration fee.... I do think if you would slightly issue less new contract it will be a good news for those earlier adopter...what you think here??
Conceptually, don't misunderstand the asset by thinking of the asset as a share in a business that will have some kind of protection against "dilution" farther down the road. That is probably one reason TAT is trying to hew to the word "unit" and rejected my casual use of the word "share" to describe the asset. It's much more like a bond. Well...it IS a bond. I can even see how calling its initial release an "IPO", although true in the technical sense, has a little potential to confuse people about what this is all about. This is not an IPO that lets "early adopters" fund a risk-taking venture and expect greater reward for doing so. It's just a bond with a structured payout. The reward for early adopters compared to later adopters, if there is one at all, is collecting dividends while difficulty is still (relatively) lower. I see little basis for the hope that unit prices will rise significantly in the open market, however, even if TAT chooses to limit further issurance of units from this point forward. |
|
|
|
No need. First counter of 5000 chips, are down to when he places the order (to shorten the queue for us), then there will be a new counter that closes batch 5.
I have suggested to indicate 5000 chips available until order of batch 5. that later updates into 5000 chips remaining until closing of batch 5.
Letīs see if it changes..
Ah, I have found this part very confusing... |
|
|
|
This is the one where %50 of all coins mined go to the dev. Are you on fucking glue? Leave dead coins, dead.
If you take a look at the eagleeye source code, new hardcoded addresses have been substituted that direct where that 50% siphon goes. So it is now being directed somewhere else, presumably no longer to solracx. One wonders if that is the motivation for "rereleasing" and hardforking the code in the first place. |
|
|
|
what controls how many will get put onto the market?, is there a limited amount of them,
As far as I can tell, TAT is free under the contract on Bitfunder to release more shares at any time, without advance notice, and to set any "fair market price" when doing so. In fact it looks like he has done so once already -- there were originally 100k shares released, but now it looks like there are 115k total shares released. I don't know if the additional 15k shares released at a later time were also sold at .007 or not, but TAT was probably not contractually obligated to set the price precisely at that level even if he happened to do so. It is also my understanding that TAT is currently looking into the process of launching the same investment on at least one if not two other exchanges (btct and Havelock). If successful, this would obviously result in the creation of more shares as well, albeit in a sister market. So scarcity of shares, in the sense of a stable and known number of shares where the share issuer does not arbitrarily create more, does not appear to be a feature of this asset. |
|
|
|
|
EKnaMqTzZ4iANobSKaTtiZbxHv4pMZRa6A
Thanks.
|
|
|
|
I got the following error when trying to compile the daemon in Ubuntu 12.04: In file included from netbase.h:10:0,
from util.h:30,
from alert.h:13,
from alert.cpp:8:
serialize.h:281:19: fatal error: gmpxx.h: No such file or directory
|
|
|
|
uhhh.
it's not even 1600, but i already got coins in my wallet.
not complaining though.
That's because the following in the OP: - block reward 0 until difficulty 1 (4900 blocks, this is to prevent a orphan fest at release, after 1 difficulty block rewards become 15 coins a block)
does not match the source code. This coin actually retargets every 250 blocks and blocks started giving out coins at block #1500. |
|
|
|
Where to find linux files for compiling?
I see no source code and no linux files in the zip file. EDIT: Ah, OP just edited the original post to add a second link. It wasn't there originally. |
|
|
|
I saw your post in the original thread. I think increasing the retarget frequency is probably a good idea. But if you are going to change the original subsidy formula int64 nSubsidy = ((1 + (diff / 24)) * COIN) / (1 + (nHeight / 194400));
I see no reason to change the constant, that just devalues any blocks mined so far (which have all had value of 1)...just change the divisor under the difficulty so the reward ramps up quicker as more people mine the coin. Something like: int64 nSubsidy = ((1 + (diff / 2)) * COIN) / (1 + (nHeight / 194400));
|
|
|
|
I think I may have figured this out. I had been bumping into the same problem (stalling at the P2P connection) on some coins but not others. I finally realized I was wrong in an initial assumption...the P2P_PREFIX setting in bitcoin/networks.py is in fact a coin-specific setting -- which is logical, as the other settings in that file are coin-specific as well. In fact, it looks like it is basically the "magic value" or "magic number" referred to in https://en.bitcoin.it/wiki/Protocol_specification, and after poking around in the code I think you can find it in main.cpp at pchMessageStart[4]=... Using this specific value as the P2P_PREFIX fixed the problem for me. So, for example, I haven't ever installed Dragoncoin myself, but looking quickly at the relevant line in main.cpp: unsigned char pchMessageStart[4] = { 0xfc, 0xd9, 0xb7, 0xdd };
Thus, for Dragoncoin, try setting P2P_PREFIX='fcd9b7dd'.decode('hex'),
and let us know if that gets you past stalling at the P2P connection. Hope this is helpful. |
|
|
|
|
Real miners do it with long poll.
|
|
|
|
|
As always, when hooking up with a new untested coin, please use protection.
|
|
|
|
|
J3GjzAxBsAYNyoMzRtRCKhajJKUHUrHFPS
|
|
|
|
|
Worked for a few minutes, then my payout address vanished from the list and payouts stopped even though the miners kept chugging.....(USCoin pool)
|
|
|
|
|
Show Posts
