It appears I am the only one testing this platform.
Till now I have none replies on my emails regarding issues.
Is it safe to liquidate my position without any loss?
Not sure how you reached this conclusion. Your last two posts are about 1 hour apart, it's unrealistic to expect 24/7 live support from a 1-man crew. |
|
|
|
The meetup will take place tomorrow. |
|
|
|
Anyway, I dont think it hurts to point out these issues like the OP does because clearly, investors didnt and dont really understand what they are buying.
That would have been great if that's what the OP was doing. But he's too focused on his witchhunt on the concept of perpetual deterministic mining instruments (or PDMIs) to discuss in any reasonable way the factors that go into their valuation. But I also dont think it makes sense to blame the issuers or the instrument itself for such investor myopy.
FWIW I think I have clarified in every possible way in the PureMining OP that it does not have a fixed BTC-denominated face value, it does not have fixed BTC-denominated returns, it is affected by block reward halving and hardware advances, and that the investor should consider this. Sorry Meni, I don't think logic is going to work on bob.
Right but I was replying to littleshop. An anti mining contract would just hold BTC.
No, that would be 100% going long on BTC - mining is a combination of going short (by buying stuff in USD) and a little bit long (by generating + paying out BTC). Anti-mining would need to go long (by holding BTC) and a bit short (maybe selling an amount equal to mining output on an exchange?). Maybe one could put it like this: Sell shares for 1000 BTC. Then on dividend day, calculate how many USD these would be and pay out 0.1 USD (converted to BTC) per share or so from the raised capital. I don't really see how this model can be in any way attractive though, since you could just invest into a non-mining fund (e.g. lending operations) etc. or just hold BTC yourself. A PDMI is going long on mining profitability. It correlates with changes in BTC price because of the lag between price and difficulty, so in a way it is longer on BTC than USD but not as long as BTC. But mining profitability is its own thing, affected by hardware developments and such so it can't be equivocated with holding either USD or BTC. I've spent some thought on how to do an anti-PDMI, and I don't think there's a very elegant solution. If it doesn't have to be elegant it's easy to do. |
|
|
|
I also don't buy the suggestion that quick confirmations aren't necessary in Bitcoin. Your proposal is very interesting, but there are lots of tradeoffs involved, including trusting an established payment processor, and putting funds in escrow. These are serious considerations, and if there's a way to do this using the elegance of the blockchain idea, while retaining low trust requirements and no escrow, I think that would be a big win.
I don't know how much you've followed the suggestion but it does not require you to trust the processor. The funds tied up on the channel are not at the mercy of the processor, the customer gets them back even if the processor is malicious or negligent. The amount that is trusted with the processor is the amount of a single payment by a single customer - or even less, if the customer splits the payment to multiple pieces and receives confirmation from the seller on every one (since payments are direct this isn't expensive). I was just pointing out that there are tradeoffs to each system. I didn't say you had to trust the processor for the entire escrow, I said you had to trust the processor, and you do, for the amount of a single transaction. That's still trust. If you didn't need to trust the processor, you wouldn't need the processor at all, the recipient could just be the processor. You're trusting the recipient anyway to deliver the goods. You don't use the processor because you trust him, you use him because he allows you to send payments everywhere with a single channel, without knowing in advance who you're going to pay. EDIT: Since my main motivation is time resolution, it doesn't matter if the minor blocks are a priori authoritative, only that they reliably fix the ordering of transactions in time once the major block is broadcast. Even so, I find talk about Finney attacks and 51% attacks a bit distracting. Finney attacks are almost impossible to reliably pull off, and 51% attacks are common to every Bitcoin modification I've heard of. The real issue is race attacks, which are certainly feasible. Minor blocks would make race attacks a lot more expensive than they currently are because you'd have to put in the effort to solve minor blocks (assuming the merchant is willing to wait an average of 10 seconds). That's means they can't be used to get a free cup of coffee at a cafe. If you're buying a car, the dealer can wait for a few major blocks. On the other hand, it would be great if you didn't have to hang around the dealership for half an hour waiting for the payment to clear.
I don't see how it really helps security against race attacks. With the current system you can query each of your peers if they know of a conflicting transaction. In none do you can be pretty sure the network recognizes the transaction. Also, proof of stake proposals strive to make the network immune to >50% hashrate attacks. I've had a discussion about PoS lately and I think I have a new framework to think about it, your suggestion could fit in as well. There are advantages to the hybrid minor/major block approach (high time resolution, faster confirmations, while retaining the longer term safety of the major blocks), but I'm not at all convinced a Bitcoin fork with a 10 second interval couldn't work better. Maybe I'm missing something but the wasted hash power (assuming 7% orphan blocks) and header overhead don't seem like a huge deal to me.
Header overhead is a pretty big deal. Most people won't run full nodes, and hopefully they'll choose the more secure lightweight clients over eWallets. The resource cost of this is proportional to the number of headers. |
|
|
|
|
I think it makes sense that the customer will pay the difference. A business owner knows how much he needs to receive; the customer chooses his preferred payment method and pays whatever extra it costs.
Anyway, hopefully in the future the differences will shrink as the market becomes large enough to attract triangle arbitrage bots.
|
|
|
|
I also don't buy the suggestion that quick confirmations aren't necessary in Bitcoin. Your proposal is very interesting, but there are lots of tradeoffs involved, including trusting an established payment processor, and putting funds in escrow. These are serious considerations, and if there's a way to do this using the elegance of the blockchain idea, while retaining low trust requirements and no escrow, I think that would be a big win.
I don't know how much you've followed the suggestion but it does not require you to trust the processor. The funds tied up on the channel are not at the mercy of the processor, the customer gets them back even if the processor is malicious or negligent. The amount that is trusted with the processor is the amount of a single payment by a single customer - or even less, if the customer splits the payment to multiple pieces and receives confirmation from the seller on every one (since payments are direct this isn't expensive). |
|
|
|
The OP is completely nonsensical.
Buying mining equipment has two components - choosing and operating hardware, and speculating on the future of price/difficulty ratio.
Having these two components as a bundle is inefficient.
Mining bonds allow each component to be carried out most efficiently - one side buys bonds thus investing in the concept of mining profitability without having to physically operate hardware, and the other side uses the money to buy equipment without taking speculative risk.
The OP is right. You are making the mistake that he pointed out. It looks like he has facts on his side. These instruments may be efficient (for the seller??) but that does not make them BONDS. A bond has a specific meaning, and no matter how many times it is used wrong, that does not make it right. I am not commenting on the usefulness of the instruments, just the terminology. They are not bonds. Calling them such makes them sound much safer then they really are. If you're commenting on terminology you should have quoted the part of my reply where I talked about terminology. Are BTC-denominated bonds with a specified BTC face value and returns "safe"? No, because BTC itself is highly speculative, volatile, and could crash any minute. Mining bonds have a fixed face value and return denominated in MH/s, which is also speculative. From Wikipedia: In finance, a bond is a negotiable certificate that acknowledges the indebtedness of the bond issuer to the holder. It is negotiable because the ownership of the certificate can be transferred in the secondary market. It is a debt security, in which the authorized issuer owes the holders a debt and, depending on the terms of the bond, is obliged to pay interest (the coupon) to use and/or to repay the principal at a later date, termed maturity.
A mining bond fits the definition. It pays coupons which, according to the terms of the bond, are tied to mining. Why are we doing this again? Bitcoin is not officially a currency, Bitcoin banks are not really banks, Bitcoin wallets are not really wallets, mining isn't really mining. We want to use familiar terminology and expand to an entirely new domain, it will have to take on meaning which steps slightly outside what we're used to. I think calling them perpetual mining contracts would probably be the most appropriate.
+1 Contract makes sense. To me contract seems more descriptive of what Vladimir et al were offering, which was not publicly tradeable. A publicly tradeable debt instrument is a bond. |
|
|
|
They're not competing it's the same bunch behind both.
Not really, Bitdaytrade is Alberto's project, he used to do development work for kronos' group but he's no longer associated with them.
..so you think we might indeed get two competing platforms? For the community and the ecosystem this would be good news. I suppose it's possible. |
|
|
|
|
If any of the investors wish to try out the platform that will generate the income for this bond, please PM me about joining the private beta of BTC/USD trading.
|
|
|
|
Bitdaytrade is preparing CfD in beta test, Kronos.io is doing -- nothing
Just conincidence, or some kind of coordination? Not sure if there would be large revenues when there were two competing CfD platforms.
Well, just guessing here.
Anyway, the next bubble is building up and what the community really needs are multiple, reliable, proven ways to hedge positions when the bubble is about to burst.
They're not competing it's the same bunch behind both. Not really, Bitdaytrade is Alberto's project, he used to do development work for kronos' group but he's no longer associated with them. |
|
|
|
I don't think this works. Either the minor blocks are authoritative or they're not. If they are then it's just like having block frequency of 10 seconds with all the disadvantages (wasted hashpower, block header resource cost). If they're not then they do not add to security, a Finney attacker could just hold on to a double-spending major block, and then release it no matter how many minor blocks have been found in the mean time, likewise for >50% attacker. By the way, p2pool is a way to reduce mining variance with fair reward distribution. It was never touted as a way to get faster security for transactions, and it probably won't work for this purpose for the reasons outlined above. Also, having very quick confirmations isn't necessary, the blockchain is for final settlement and actual payments will more likely be in some form of Trustless, instant, off-the-chain Bitcoin payments. Related ideas are Dynamic block frequency and Unfreezable blockchain. |
|
|
|
Are you high? You are mixing up debt and equity and some of your references make no sense at all. Obviously you have no idea wtf you are talking about. But keep at it. vps likes this crap because you help to confuse the issue.
Right, debt and equity are not the same but the difference is irrelevant to the point I was making. |
|
|
|
|
The OP is completely nonsensical.
Buying mining equipment has two components - choosing and operating hardware, and speculating on the future of price/difficulty ratio.
Having these two components as a bundle is inefficient.
Mining bonds allow each component to be carried out most efficiently - one side buys bonds thus investing in the concept of mining profitability without having to physically operate hardware, and the other side uses the money to buy equipment without taking speculative risk.
To say that buying (or selling for that matter) mining bonds is "bad" because the returns are not fixed in some arbitrary denomination reflects no understanding at all of economics. It's the equivalent of saying bitcoins shouldn't be bought because they're not backed by a specified amount of dollars, or that any commodity or stock shouldn't be bought because its future price is unknown. It's called "risky investment" and if one doesn't like it he can sit it out, as long as he doesn't complain about those who profit from thought out risky investments.
It's all a matter of the offered price. If the traded price of a bond is high enough it is a bad decision to buy it, if it is low enough it is a good decision, in the middle there's uncertainty and the one making the best decisions wins. The OP can argue that the bonds at some specific time are overvalued but it doesn't seem like that's what he's trying to do.
Mining bonds are called "mining bonds" precisely because unlike usual bonds they are not tied to some currency but rather to mining hashrate. But the OP can call them whatever he wants (except for the term he's used which is offensive).
|
|
|
|
I've forwarded this to Alberto. In general the best way to resolve such issues is emailing info@bitdaytrade.com. |
|
|
|
Alberto has found and is fixing an issue that could be related to what Ichthyo is seeing. You alas Ichthyo alas possible bitdaytrade shill.  You keep using that word. I do not think it means what you think it means. |
|
|
|
|
Wasting 50% of the network hashrate on orphans is hardly optimal (making attacks twice as easy since they build on their own blocks), as is making lightweight clients have to record several block headers per minute.
|
|
|
|
IPO shares are sold out
They are indeed. Thank you to all investors. |
|
|
|
Coupon payment summary for July 2012 (total 0.017129391 BTC per bond): Block number Timestamp Timestamp (Unix) Elapsed time Difficulty Block reward Coupon Bonds Total Status
191519 Jul 30 2012 10:53:56 1343645636 172741 1866391.30500 50 0.0010774643 20000 21.5492860 Paid
191183 Jul 28 2012 10:54:55 1343472895 171117 1866391.30500 50 0.0010673346 20000 21.3466920 Paid
190847 Jul 26 2012 11:22:58 1343301778 177745 1866391.30500 50 0.0011086765 20000 22.1735300 Paid
190511 Jul 24 2012 10:00:33 1343124033 192874 1866391.30500 50 0.0012030429 20000 24.0608580 Paid
190175 Jul 22 2012 04:25:59 1342931159 202379 1866391.30500 50 0.0012623299 20000 25.2465980 Paid
189839 Jul 19 2012 20:13:00 1342728780 191829 1866391.30500 50 0.0011965248 20000 23.9304960 Paid
189503 Jul 17 2012 14:55:51 1342536951 191514 1751454.53534 50 0.0012729513 20000 25.4590260 Paid
189167 Jul 15 2012 09:43:57 1342345437 179959 1751454.53534 50 0.0011961478 20000 23.9229560 Paid
188831 Jul 13 2012 07:44:38 1342165478 203218 1751454.53534 50 0.0013507452 20000 27.0149040 Paid
188495 Jul 10 2012 23:17:40 1341962260 183059 1751454.53534 50 0.0012167528 20000 24.3350560 Paid
188159 Jul 08 2012 20:26:41 1341779201 181850 1751454.53534 50 0.0012087169 20000 24.1743380 Paid
187823 Jul 06 2012 17:55:51 1341597351 195975 1751454.53534 50 0.0013026026 20000 26.0520520 Paid
187487 Jul 04 2012 11:29:36 1341401376 186253 1726566.55919 50 0.0012558278 20000 25.1165560 Paid
187151 Jul 02 2012 07:45:23 1341215123 209159 1726566.55919 50 0.0014102736 20000 28.2054720 Paid
I have recalled 4000 bonds I have left which are unlikely to be sold before the ASIC dust settles. |
|
|
|
|
Show Posts
