Bitcoin Forum
May 28, 2024, 12:02:27 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 [50] 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ... 130 »
981  Economy / Securities / Re: [BTC-TC] Deprived Mining Speculation (DMS) on: June 19, 2013, 04:05:36 PM
Sold   1011
Swapped   0
Total   1011
Price   0.054589
Total   55.189479
Less Fee   55.07910004
Man Fee   1.652373001

BTC Balance (BTC-TC)    898.03505875
12500 LTC-ATF.B1    125.00000000
TOTAL ASSETS    1,023.03505875
   
Outstanding MINING   19450
Outstanding SELLING   19450
Outstanding PURCHASE   211
Effective Units   19661
   
Block reward   25
Difficulty   19,339,258
Hashes per MINING   5000000
   
Daily Dividend    0.00013002
50 days (Min Liquid)    0.00650111
100 days (Forced Close)    0.01300222
365 days (Buyback)    0.04745810
405 days (IPO)    0.05265898
400 days (Post SELLING div)    0.05200887
410 days (Pre SELLING div)    0.05330910
   
NAV Post MINING Div    1,020.47869257
NAV/U Post MINING Div    0.05190370
Days Dividend Post Div   399.19
SELLING Dividend    -         
NAV Post SELLING Div    1,020.47869257
NAV/U Post Selling Div    0.05190370
PURCHASE selling price    0.05449889
PURCHASE buy-back price    0.05086563
982  Economy / Securities / Re: [BTC-TC] Deprived Mining Speculation (DMS) on: June 19, 2013, 06:43:33 AM
There have been a couple of compromised accounts on BTC-TC lately - ones without 2FA of course.

I haven't stated it here (I have in other threads) but ALL accounts of mine which have 2FA available have 2FA enabled.

Where possible I use yubikey - where that isn't possible I use Google Authenticator.  My Google one-time passes are generated on a smart-phone NOT on any computer I use.

My yukikey is attached to the key-ring with my front-door key on and I carry my smartphone with me.  So even knowledge of my passwords AND physical access to the computers I use (none of which are public ones) would NOT allow access to my accounts.  Gaining access to an email account COULD allow changing/recovering a password but that would be useless without 2FA - which, of course, is why 2FA is absolutely essential.

Just clearing that up in case anyone was concerned.

EDIT: And I'm off to bed now - so any more transfers in won't get handled until an hour or so before today's dividend.
983  Economy / Securities / Re: [BTC-TC] Community Exchange w/ Options, DRIP, 2FA, API, CSV, etc. on: June 19, 2013, 06:25:22 AM
Burnside, have you considered maker/taker pricing?

Yeah.  I wouldn't mind doing something that shifted some of the fee to the maker, and reduced it on the taker.  Would be curious to hear from the masses what they think?

Hope you mean other way round.

Maker should get the lower or zero fee (for adding liquidity), taker the larger (or whole) fee for removing liquidty.  It's great for removing spreads - with people buying bidding 1 satoshi below ask rather than buying so as to avoid a fee.

The other way round (which you said) works to discourage people placing orders - leaving empty order books.
984  Economy / Securities / Re: Hashrates of mining securities on: June 19, 2013, 04:36:36 AM
Believe JAH on Bitfunder now pays significantly more than 1 MH per bond - he increased it for free.  Not logged into Bitfunder and can't remember exactly what he pays - but pretty sure he bumped it up a lot.

DMC can be removed - it's never been a mining company, just an investment fund.

I also wouldn't include ASICMINER or AMC - if you try to value them based on hashing you'd be doing the wrong thing.

Shares you CAN compare to PMBs - but any reinvestment percentage has to be treated as though it were paid out in dividends when working out the effective hash per share.  Exception being companies that produce (or claim to intend to produce) their own hardware - those can't reasonably be compared based on hashing power.
985  Economy / Securities / Re: Hashrates of mining securities on: June 19, 2013, 04:30:38 AM
And YABMC is only a bit over 0.6 MH/s per share not 1.  Contract says 1 - but two of the partners in it scammed so the only hashspower currently being paid out is from what the honest partner in it pays.

If anyone wonders why ASIC.COOP is so cheap the issuer of it also ran a bond - which he defaulted on.  Supposedly the cash from bonds was being used for various things - including mining.  When he defaulted it turned out he had no mining (or had some and lied saying he didn't).  Not sure how it turned out as he stopped responding in the forums.  But potential investors should be aware there IS a reason why it looks such a good deal (aside from it being pre-orders anyway).
986  Economy / Securities / Re: Hashrates of mining securities on: June 19, 2013, 04:26:32 AM
It may be useful to note which ones are already paying dividends and which are still waiting for hardware before they start.
987  Economy / Securities / Re: [ANN]BTCT:BFMINES - PMB - Escrow until operation start - Bonus divs first months on: June 19, 2013, 04:06:23 AM
I realize that since I designed this and put it up for vote, DMS.Mining has dropped in price, but I believe that is a somewhat different asset as it effectively is a double-exposure asset because in difficulty drops, people will buy .Purchase to sell .Selling and keep .Mining and vice-versa. I find it an extremely fascinating combo, but one that carries additional risk and complexity that 'regular' investors may not easily understand.

.b

I'm not sure it's correct to say DMS.MINING carries additional risk - it has risks other PMBs don't, but also misses lacks risks in PMBs with physical miners.  In all likely scenarios it will pay out the same as a PMB for a long time.  The single notable exception is if difficulty stays the same, drops or rises by only a  tiny amount for a protracted period of time - when after about a year it would close down with a final lump payment of 100 weeks.  But if that happens it would almost certainly mean you never got your hardware - as its hard to see a scenario in which your miner gets shipped but difficulty isn't rising much.

Anyway, good luck with the asset.  The contract's clear - and it's certainly better value than a lot of other 'PMBs' around.  I'm not a moderator but if I was I'd vote yes - but with a note that it is NOT a  loan and that capital will NOT be repaid (there's no guarantee of it ever being fully returned - just a definition of a buyout option).  Beyond that investors have to do their own valuations and comparison shopping.
988  Economy / Securities / Re: [ANN]BTCT:BFMINES - PMB - Escrow until operation start - Bonus divs first months on: June 19, 2013, 12:53:53 AM
Well, technically, the bond will be repaid at some point (following one of the clauses in the contract). However, the full principal will not be repaid.

Nah it won't be repaid.  It'll be bought out.  Not the same thing.
989  Economy / Securities / Re: [ANN]BTCT:BFMINES - PMB - Escrow until operation start - Bonus divs first months on: June 19, 2013, 12:52:38 AM
What I do know, and have argued in a follow-up article (http://coin.furuknap.net/are-perpetual-mining-bonds-scams-not-really/), is that perpetual proportional growth isn't possible.

We see a meteoric rise now for the past few months of around 400% since February. If extrapolated, this would mean a quadrupling of difficulty every four months, and would mean network hashing power reaches 600 TH in September, 2.4 PH/s in December, and 9.6 PH/s in February.

To put that into perspective, the most powerful miner on the horizon now, the Jupiter from KnC, runs at 350GH/s and costs $8,000. KnC would need to sell 28,000 such devices to reach such a number, which would cost the market US$220 million. That's the absolute lowest number using current technology, and that number must be invested to get to a market which is US$131 million per year (at $100 per BTC). With equipment lifespan of 2 years tops, that means a massive investment with huge risks for a possible 8.5% yield per year, and even this assumes that difficulty rise stops in February, which is far kinder than a lot of the predictions the fear-mongerers claim. Go another four months with the doom-and-gloom predictions and you're at a point where you write June 2014 and the market would need to invest four times any possible return to keep the difficulty growth up.

I'd certainly agree that there's people who over-estimate the likely growth of difficulty as well as those who underestimate it.  Most of those argue based on a period of time starting when ASICs began arriving - and ignore the much flatter period before it.

I think it would be a mistake, however, to assume costs now reflect where prices will be in 6 months time or even in 3 months time.  Pricing now is set to try to cover NRE - and to try to milk as much cash as possible from the shortage of actual ASICs (as opposed to vapourware ones).  Once NRE is recovered, costs per unit after that are pretty tiny compared to current prices - so there's definitely scope of heavy price cuts.  And those who have recovered NREs are likely to make such cuts - in part to cripple any attempts from others to enter the market.

The argument that people would need to spend more than the value (in terms of output) of ASICs would warrant is meaningless.  Just look at what's happening right now - people are happily buying bonds, shares and hardware that will never pay for itself.  Don't underestimate the willingness of Bitcoiners to throw away coins in pursuit of the delusion that mining is automatically profitable.

And don't discount the possibility of a rise in price of BTC - which changes all the math.

But yes - there are overly pessimistic views as well as the (far more common) overly optimistic ones.

As you make no claims that investors will make a profit that isn't, in my view, an issue in assessing whether you can list or not.  Investors have to make their own decision on that.

One last point.  If you're listing now but escrowing until hardware arrives (and refunding if it doesn't arrive) then what benefit is there to investors in buying shares now rather than when the hardware arrives?  If you waited until then you could look at ACTUAL difficulty and adjust your price in either direction to compete with the market - and likely output - rather than having to guess now.  Plus avoid all the lost transaction fees on sales if the hardware never arrives.  And the investors would have the cash to use - with no CP risk - for that period rather than it sitting around idle earning noone anything.
990  Economy / Securities / Re: [ANN]BTCT:BFMINES - PMB - Escrow until operation start - Bonus divs first months on: June 19, 2013, 12:40:59 AM
You may want to consider NOT calling it a bond - if you call it a bond it'll definitely make it harder for you to get moderator approval.

That's because it is NOT a bond - nowhere is there mention of returning capital at the end.  A few moderators will vote NO on anything that isn't a bond but calls itself one - as it gives the misleading impression that capital is secure and will be returned ('real' bonds have a face vaue that doesn't change - and which in nearly all cases eventually gets repaid).  Yeah I've heard the arguments that it IS a bond but is denominated in hashes - which fails the smell test immediately when the selling price isn't defined in hashes.

I very much agree, I would like to call it something else, but bond is the closest thing available as a definition.

I don't think it is.  I'd say fund is the closest of the three available (I agree it isn't exactly any of them).

Bonds are debt - you certainly aren't selling debt.

You're selling equity in hashing power owned by the company.  If you consider the hashing power to be an asset then investors are buying it and being paid based on its performance (albeit an idealised performance rather than an actual one).

If you look at what the key elements of bonds are this (and other PMBs) don't match at all.  A fund is closer - as each share represents ownership of an (intangible) asset which will vary (usually downwards) in value over time and generate income.

It's by no means the only term being widely abused.  Just look at how ROI is being widely misused.  A few people use it incorrectly (apparently believing it means Return OF Investment), sheep trying to look clever parrot that use without any real knowledge and now it's widely used to mean the period it take for investment to be returned.  When of course it stands for Return ON investment and cannot be specified as a period of time.
991  Economy / Securities / Re: [BTC-TC] Community Exchange w/ Options, DRIP, 2FA, API, CSV, etc. on: June 18, 2013, 10:19:02 PM
As an example, I place a bid order for 0.0335 BTC per share, which is the top bid by a non-trival margin (say the best before was 0.033 or so). I then get outbid by a bid of 0.033501, which is 0.003% above my bid. For all intents and purposes, it is the same bid. With volumes being in the dozens at most typically, the extra cost incurred by the person placing the second bid are negligible (one-hundreth of a dollar-cent per share), yet it does ensure that the other bidder gains priority when the bid is filled. This scenario has happened several times today while trading DMS.SELLING, at slightly different values, but the order of magnitude is correct.

This kind of bidding behavior doesn't help with price discovery, it doesn't narrow the bid-ask spread and it doesn't provide the market with more liquidity. It's, in my eyes, exploiting a feature of the trading platform to get your order fulfilled before others with the same order and such an advantage is big in markets where trades happen infrequently.

I disagree with some of this.  It DOES add liquidity because, even if we consider his bid to be the same as yours, by placing his bid he's increased liquidity at that price-point.  Problem with arbitrary limits is they add more serious problems - not the least of which is that valid orders can get rejected if someone else makes the same valid order at the same time.

Well, with an increased minimum increment the other bidder either has to place the same bid that I placed, and therefore not have priority on order execution (at least, that's how I assume it work. Burnside, can you confirm that if 2 orders are placed at the same price, the oldest is executed first if a market order comes in?) or at an increased price that actually has a non-trivial markup over my bid.

Quote
If it's too small to make a difference (i.e. they have to bid .03351 instead of .033501) then it's pointless.
But at the other extreme where it makes too big a difference (e.g. they have to bid .0345) then it distorts the market - as you can place a bid which allows profitable arbitrage and at the same time blocks others narrowing the margin.
I agree that the we should err on the side of caution when increasing the increment. It should not be so large that the market is distorted. Currently, there is 0.2% fee on each trade, so I would say that the minimum increment should be somewhere between 0.05% and 0.1% or so. But there is at least a lot of improvement to be had from the current situation where you can have 0.003% increments (or less).

The number-of-decimals solution that Burnside proposed looks to be the most effective way to address the issue. It also avoid the problem that you rightfully pointed out (and that I didn't quote) of bid increments only applying to the top bid (or bottom ask) and that bots can circumvent it by placing a dummy top bid and taking it down directly after.

I don't like the solution that was posted above, where a minimum total bid value (measured in BTC or LTC) is required to overbid the top bid. Small players should be able to set their price just like big players (and it still doesn't limit well-designed bots). Overbidding is an essential part of the market, but we should make sure that people (or bots) are actually overbidding and not just abusing the system to get priority on execution by placing what comes down to effectively the same order with a little trickery.

With multiple orders on exact same price the oldest DOES get filled first.

I'm fine with limiting decimals based on price - that doesn't have any obvious flaws (provided it allows reasonable definition).  I'm still not seeing what the big problem is - other than people being offended that they weren't outbid by much.  The only time you have the right to top bid is if you place a bid that noone else is willing to beat.  That's rarely the case - usually if you get top bid it's because noone else was around or paying attention, not because they wouldn't go higher.  I don't see the change actually achieving much other than maybe narrowing spreads slightly faster (which is good) - bots (and low-income people who can sit there refreshing) will still outbid you all the time you're below their maximum bid price.  Just by slightly more.
992  Economy / Securities / Re: [BTC-TC] Community Exchange w/ Options, DRIP, 2FA, API, CSV, etc. on: June 18, 2013, 10:00:11 PM
What about this one:
https://forum.litecoin.net/index.php/topic,551.msg29947.html#msg29947

Quote
I am sure you can improve liquidity if you do not allow tiny orders (worth less than X LTC) to set their own Bid or Ask price. Lets say this limit is set at 20 LTC

If the orderbook looks like:
Code:
Shares |  Bid    Ask  | Shares 
10     | 1.2   | 1.3  | 20
20     | 1.1   | 1.4  | 40
30000  | 1.0   | 1.45 | 50


Now, if I had 5 shares of BLAH and like to sell those, I have 2 options:
Place my order at any available Ask, or sell at market (what ever is available on Bid side)

If I had <10 20 LTC and I like to buy shares of BLAH, I can only execute a market order (from Ask side) or add my Bid to any existing Bid available.

What happens if 17 shares is bought at 1.30? Nothing unusual - 3 shares will stay there and this will be the Ask as it's today.  (as those 10 at 1.2 on bid side)

Yes, this will probably not help to narrow the bid/ask spread but 1 share at 1.1 is no good to anyone anyways. Smiley

There is no need to invent a wheel. Only way you can narrow the spread is if you have several market makers for any stock or bond. Their job is to keep some type of spread and level of liquidity. (read up on "market maker" and or "specialist")

So if I want to put a small bid I just put a large fake one, put my small one on top then cancel the large one.

And if there's no bids at all you can't put one if it's small?

Really not seeing why so many people think they have some entitlement not to be over-bid.  Making it harder for higher bids to be placed isn't helping anyone or adding liquidity.

You've given a solution - but not explained what problem it is solving or how it solves it.

EDIT: Let me explain one of the problems with this solution (assuming it actually solves something).  A not uncommon scenario is a share with an enormous spread between bid and ask - usually after someone panic sold.  With this solution noone could put up a small bid at anywhere near a reasonable price - they'd either have to pile on the 10,0000 units at .00001 bid or buy from the ask.  With a tight spread it would do no harm (and no good) - with a wide spread it's positively terrible.  The only person who benefits is whoever has the top bid - who now can't be outbid by small traders no matter how ridiculously low their bid is.  For everyone else the bid is either neutral or bad.
993  Economy / Securities / Re: [BTC-TC] Community Exchange w/ Options, DRIP, 2FA, API, CSV, etc. on: June 18, 2013, 07:32:49 PM
I don't have problems with people (or bots) outbidding me, my point was more that they really aren't outbidding me at all. The bid increments are so tiny that they're far below any reasonable margin that you would consider in your price/profit calculations.

As an example, I place a bid order for 0.0335 BTC per share, which is the top bid by a non-trival margin (say the best before was 0.033 or so). I then get outbid by a bid of 0.033501, which is 0.003% above my bid. For all intents and purposes, it is the same bid. With volumes being in the dozens at most typically, the extra cost incurred by the person placing the second bid are negligible (one-hundreth of a dollar-cent per share), yet it does ensure that the other bidder gains priority when the bid is filled. This scenario has happened several times today while trading DMS.SELLING, at slightly different values, but the order of magnitude is correct.

This kind of bidding behavior doesn't help with price discovery, it doesn't narrow the bid-ask spread and it doesn't provide the market with more liquidity. It's, in my eyes, exploiting a feature of the trading platform to get your order fulfilled before others with the same order and such an advantage is big in markets where trades happen infrequently.

On the other hand, making a bot does sound like fun. I might just dive into that in the future. If you can't beat em, join em Smiley

Yeah, the scaling decimal limits per security would solve this.  For instance, imagine the following table:

highest biddecimals allowed
>10000
>1001
>102
>13
>0.14
>0.015
>0.0016
>0.00017
all else8

We'd clearly display in the interface the max decimals allowed on each individual security page.



Yes - that's about the only sane way of doing it.  I'm not convinced it's a real problem myself - but I'd actually benefit from it so certainly don't object (only bots and people in low-income countries can afford to sit there constantly updating orders).
994  Economy / Securities / Re: [BTC-TC] Community Exchange w/ Options, DRIP, 2FA, API, CSV, etc. on: June 18, 2013, 07:30:58 PM
As an example, I place a bid order for 0.0335 BTC per share, which is the top bid by a non-trival margin (say the best before was 0.033 or so). I then get outbid by a bid of 0.033501, which is 0.003% above my bid. For all intents and purposes, it is the same bid. With volumes being in the dozens at most typically, the extra cost incurred by the person placing the second bid are negligible (one-hundreth of a dollar-cent per share), yet it does ensure that the other bidder gains priority when the bid is filled. This scenario has happened several times today while trading DMS.SELLING, at slightly different values, but the order of magnitude is correct.

This kind of bidding behavior doesn't help with price discovery, it doesn't narrow the bid-ask spread and it doesn't provide the market with more liquidity. It's, in my eyes, exploiting a feature of the trading platform to get your order fulfilled before others with the same order and such an advantage is big in markets where trades happen infrequently.

I disagree with some of this.  It DOES add liquidity because, even if we consider his bid to be the same as yours, by placing his bid he's increased liquidity at that price-point.  Problem with arbitrary limits is they add more serious problems - not the least of which is that valid orders can get rejected if someone else makes the same valid order at the same time.

Increasing minimum increment will either make a difference or it won't.

If it's too small to make a difference (i.e. they have to bid .03351 instead of .033501) then it's pointless.
But at the other extreme where it makes too big a difference (e.g. they have to bid .0345) then it distorts the market - as you can place a bid which allows profitable arbitrage and at the same time blocks others narrowing the margin.

On an aside it's a total waste of time anyway as it wouldn't stop anything.  I'd better explain why - as it isn't entirely obvious.

Any restriction on Bid increments could only be applied to the TOP bid - not to bids elsewhere in the book.

So you have you bid at .0335 and I want to bid .033501 but can't - as I have to bid more.

Fine my bot bids for 1 unit at .034, places my real order at .033501 (now legal as .0335 isn't top bid) then cancels my .034 order.  The system can't start cancelling existing bids if they would break the rules if new - or I could UNDERbid you by .000001 and force YOUR order to be cancelled.

Reducing the precision allowed on bids is what burnside tried - but that has its own problems.  Not the least of which is that if BTC rises anything with an underlieing USD element is going to need those extra digits.  Every time difficulty rises by a factor of 10 all mining bonds SHOULD have their value shifted 1 place to the right, needing 1 more digit.

The best hope for it to stop is actually for MORE bots to join - and let them keep outbidding one another until the spread closes to nothing.  Then just give them a nudge in the right direction with a temporary bid and let them trade with one another at a spread below the exchange's fees.

Also it's worth looking at what they respond to.  Some only respond to overbids worth more than X - and can be fooled into not adjusting price just by staggering your own bids in chunks just under X.  Also once you know X and know the size of their bid you can work out the potential cost of trying to force them into a bid you'd willingly fill.  All of which reminds me I really need to get my own GLBSE bot converted - though with BTC-TC's caching it won't be practical to strip cash from bots as efficiently as you could on GLBSE (a bot to raid other bots would need to read market data from uncached web-pages rather than cached API).
995  Economy / Securities / Re: [BitFunder] [TAT.VIRTUALMINE] Virtual Mining - Hash Without Hardware! on: June 18, 2013, 07:12:26 PM
UPDATE

Due to ASICMINER's decline in hashing for several days now, I am pausing any new issuance of TAT.VIRTUALMINER units, and I will begin to find alternate backing for the hashes AM has taken offline.

Since it is likely that this is a temporary lull in hashrate from AM, I will not be securing new backing aggressively, but I will be buying other hashing assets at a modest pace until AM gets back up to a speed that covers TAT.VM's hashes, or I until I buy enough alternate hashes to exceed what is required for backing TAT.VM.

Any alternate hashing that is purchased will likely be held permanently as backing for TAT.VM hashes.

Once the dust has settled, I will issue a new TRANSPARENCY REPORT, showing all holdings used as backing, etc.

Thanks!

Does this mean that the BTC/share should go up from where it is now instead of continuing down, or am I misunderstanding what you mean?

It probably won't affect things much on BTCT.co. If I issue new units anywhere, it can slow price growth or depress the price. However, the volume hasn't been that high on BTCT.co, so the price never was able to get as high as on BitFunder, and thus I have not issued nearly as many.

Ohh, my question was in relation to the dividends (sorry I didn't specify).

The only thing that affects dividends is the current mining difficulty. My work to secure additional backing is unrelated. The backing just serves as additional insurance that dividends will get paid reliably.

Think what he was asking is whether ASICMINER's hashing reducing would affect difficulty - and hence dividends.  Answer to that is if ASICMINER's hashing stays low then difficulty will increase by less than had that hashing power been working.  Whether that's enough for difficulty to actually fall is debatable - at present, if hashing doesn't rise from other sources (and ASICMINER's hash-rate stays depressed), next difficulty change would be a miniscule rise and so a tiny drop in dividend/day.  Without knowing WHY ASICMINER's hash-rate has fallen there's no way to know how long it will stay low - and whether there's any likelihood of it falling further. 

Most reasons why ASICMINER hashing power has dropped would only generate a short-term drop -e.g. relocating or upgrading some equipment, but there are some possible reasons that could lead to a greater reduction - e.g. chips failing or enforcement action against them.  The short-term ones seem the most likely to me.
996  Economy / Scam Accusations / Re: [PONZI SCAM] CloudHashing scam on: June 18, 2013, 05:38:52 PM
Lying on the expected return is a scam in my book. As you said, those projections WON'T HAPPEN, and very likely their "investors" won't even get back the money they put in this venture. So, cloudhashing has two options:

1) run a one time, "hit-and-run" business, cashing in the huge mark-up they have on the hardware (1GH/s costs them aprox. $20 and they are selling it for $149, PLUS the commision of 10%), and screwing up the first investors that will very soon realize they are getting peanuts for their $. In this case new money will stop flowing in as soon as they start hashing and the clueless people who invested start spreading the word that they are receiving much less than they expected.

2) be very greedy and start making payments according to their fairy-tale projection using the huge mark-up they have on the machines, so people start spreading the word that this indeed is a business that gives you 500% return per year, and new investors pour in en masse.

1 or 2 it's not so different for me. From a legal point of view, probably 1) is not considered an outright scam, while 2) is a ponzi, so I agree that they will likely just go for 1). It not be a *scam* from a legal point of view, but it's a scam in my book, as they are sucking in money with blatantly false assumptions.

They can't really do 2 - as everyone can work out what they should be paying for the hashing power per contract.  That's why it almost certainly isn't a ponzi - as they won't ever be paying out the 500% to anyone.

Hit and run would be if they took in the money and didn't pay anything.  That's also unlikely in the short-term - as they make more by paying out and continuing to sell more contracts.  Don't underestimate the stupidity of people here - they'll continue reinvesting in crap that will never make a profit even after the proof it won't make a profit has been rubbed in their face by the tiny returns they've actually got.

I'd bet investors on this forum have lost more BTC investing in mining companies than they've lost in all the actual scams put together (including Pirate).  If you run a mining company you don't have to steal - you just skim a big margin off turnover leaving investors with a loss.  Mining is only marginally profitale most of the time - it's impossible for investors to make a profit if the operator takes any sort of significant cut from turnover rather than from profit.  There HAVE been a few exceptions to that - but anything that isn't already mining (or manufacturing chips) isn't one of them at this point in the cycle.

It IS possible that they will make a 'profit' (in USD) for investors if BTC rises a lot.  But that's deceptive and irrelevant for users of this forum (returns need to be compared to just buying and holding BTC - with 0 counter-party exposure to both cloudhashing AND their hardware suppliers).  For those buying in USD it may be more relevant - but is still horrible value compared to buying and holding BTC.
997  Economy / Scam Accusations / Re: [PONZI SCAM] CloudHashing scam on: June 18, 2013, 05:17:50 PM
As you are selling the units at a huge markup (350GH/s cost $7,000 or less and you are selling them between $52,000 and $35,000), you will pay old investors with new investors money in order to suck more money into your scheme until it collapses. There is no legitimate business that give investors a 500% return in one year, apart from PONZI SCHEMES -> that's what you are going to run.

Anybody believing otherwise is a fool.

Actually it almost certainly is NOT a ponzi.

Nowhere do they promise to pay out 500% - that's just the fairy-tale projection they make.  They can pay out what they actually promise (output of X hashes) and still pocket a load of cash - no need to be paying from future investments.

Of course their projections are total bullshit - investors will be lucky if they ever even get back what they invested.  But that doesn't actually make it a scam - as that's true of nearly all mining companies (just not to such a great extent).  Where it probably IS a scam is because they give projections which are totally implausible - but try convincing Trading Standards of that if you make a complaint.

Ponzi - No.
Profitable - No.
Scam - Depends on how you define it.  Of course they COULD just run and pay out nothing - but that makes little sense, at least until sales dry up.
998  Economy / Securities / Re: [BTC-TC] Community Exchange w/ Options, DRIP, 2FA, API, CSV, etc. on: June 18, 2013, 04:34:54 PM
One thing I would like to see on BTCT is some sort of minimum granularity of prices. Right now, what happens all the time is that someone undercuts (or overbids) your ask or bid order by something silly like 0.01% or even less. So while you have functionally equivalent orders, the other one gets executed first since it's better by a negligible margin. Which means that with volumes being relatively low, you have to constantly babysit your order to ensure that it's at the right spot in the order book if there's one of those jokers going around constantly outbidding you by 1 uBTC.

In the low volume trades that occur on BTCT, these tiny fractions of a % have no meaning, but they serve to frustrate those trying to keep a competitive bid/ask in the books. A minimum granularity of in the price would help a great deal in overcoming this issue as it would force users that want to have the top order in the book to actually beat the current best price by a non-trivial (though still small) amount.

A lot of the time it's bots doing that.  There are a few bots that are just trading the spread with small volumes.

Annoying though it can be, I disagree with you.  If you want top bid or lowest ask then put a price that they won't outbid/undercut.  Alternatively you can force them to a price where you're happy to fill their order then move your own order.  Once you figure out their ranges it isn't hard to outmanouver them - for example on Bid side the most active bot won't outbid anything that's within 20% of the lowest Ask - so you can either bid at 19.9% below lowest ask or put a 1 unit ask yourself to reduce that range.  On very illiquid securities with large spreads you can even force the bots into selling to you then buying back at a higher price - and repeat until the owner notices.

Reason I disagree is simply that the process of outbidding - even at tiny increments - is a discovery process.  It's working out who won't go higher (or lower).  If you have a problem because of it, it means you aren't bidding/asking near the edge of your range.  If that's the case for both of you then reducing the minimum won't stop it happening - it'll just reduce the number of iterations before you get to the edge (the point where one of you won't change their order any more).  Either of you can already speed up that process - by using larger increments themselves.

0.1% may sound tiny - but that's half the trading fee.  i.e. it's half the cost that needs to be covered to make an arbitrage opportunity break-even or profitable.  If you were to raise the limit to 1% then you'd end up in a situation where someone could bid 1.1% below the arb point and, despite there being a 0.9% profitable range left noone else could outbid them without risking loss.

Because of that, if limits were to be imposed they'd need to be based on a percentage of SPREAD not PRICE.  So where the spread was small minimum overbids would be fine - where spread was large a more significant increment would be demanded.  But that makes it hard to understand.  And any such limit is a real pain on any active security - as if two or more people are trying to adjust prices at the same time, some of them may have orders rejected even though they met the criteria based on the information they had when they were entering their order.

In short I'd say No.  If another trader's actions are annoying then either:

1.  Live with it - the market IS (in part) for making profit from other traders.  On most trades someone is losing money (IPO sales aside) - a bit of butt-hurt is irrelevant compared to that.
2.  Do the same thing but better.
3.  Exploit it.
4.  Prevent it by being more aggressive in your own orders - force them to make hard decisions rather than just letting them keep outbidding in tiny increments.
999  Economy / Securities / Re: [BTC-TC] Deprived Mining Speculation (DMS) on: June 18, 2013, 04:02:52 PM
Sold   2415
Swapped   0
Total   2415
Price   0.054609
Total   131.880735
Less Fee   131.6169735
Man Fee   3.948509206

Management fee of 3.948 transferred

BTC Balance (BTC-TC)    847.03313166
12500 LTC-ATF.B1    125.00000000
TOTAL ASSETS    972.03313166
   
Outstanding MINING   18423
Outstanding SELLING   18423
Outstanding PURCHASE   227
Effective Units   18650
   
Block reward   25
Difficulty   19,339,258
Hashes per MINING   5000000
   
Daily Dividend    0.00013002
50 days (Min Liquid)    0.00650111
100 days (Forced Close)    0.01300222
365 days (Buyback)    0.04745810
405 days (IPO)    0.05265898
400 days (Post SELLING div)    0.05200887
410 days (Pre SELLING div)    0.05330910
   
NAV Post MINING Div    969.60821791
NAV/U Post MINING Div    0.05198972
Days Dividend Post Div   399.85
SELLING Dividend    -         
NAV Post SELLING Div    969.60821791
NAV/U Post Selling Div    0.05198972
PURCHASE selling price    0.05458920
PURCHASE buy-back price    0.05094992
1000  Economy / Securities / Re: [BTC-TC] Deprived Mining Speculation (DMS) on: June 18, 2013, 04:59:51 AM
Wow people are sure dumping mining, even more than I expected. It is interesting that MINING+SELLING is cheaper than buying PURCHASE right now -- I think maybe SELLING is undervalued? It seems the price dropped by the full amount of the dividend, but the MINING side should be bearing some of that decline.

If the market pricing was correct then ALL of the dividend would have gone off the SELLING price afterwards.

I'm not seeing that MINING+SELLING is cheaper than PURCHASE.  Yeah - the Bids are, but the Asks aren't - you can't buy a MINING+SELLING for less than a PURCHASE.  You need to compare bids to bids and asks to asks.

The big drop in MINING isn't at all unexpected - I'd actually expected it to drop lower before recovering.  The prices of these are going to swing around a LOT more than for PMBs - as people can sell MINING or SELLING without having ever bought one : and the potential for panic selling is far higher.

With a normal PMB, if someone thinks its losing value or they paid too much they can just try to sell slightly below the Issuer's price.  You can see that happening on TAT.VM - where people are trying to sell just under his own .007 Ask (and pray he doesn't decide to sell cheaper himself of course).  They can't afford to wait and try to do that on MINING if they decide they paid too much as :

1.  There's no issuer's Ask wall to put Asks below.  I only sell PURCHASE - I've never sold MINING or SELLING and there's never been an official price for them.
2.  Anyone who thinks MINING is overpriced can just buy PURCHASE, split it and sell MINING - there's no restriction on who can undercut you so far more chance of it happening.  
3.  With TAT.VM (And all PMBs) all shares were bought at the initial price - so if they're sold below it then someone has made a loss on it.  With MINING that isn't the case - it could be a share straight from a split where the seller believes they're making (or locking in) a profit on the sale.

In short - the market will move to a new range much more quickly and stay there all the time that's where the general belief is that it belongs.  That makes it potentially far more profitable if you get it right - but also far more brutal when you get it wrong.

The price also can't be fixed in the same way it can on some PMBs.  Having a small number of shares issued allows someone with a good chunk of them to move the range to where they want.  That just can't be done on MINING and SELLING - as if you move the price to a wrong range then anyone who wants can just buy in and clear out your walls that were artifically propping the price up.  Usually such fixes are to raise the price after accumulating a lot - where noone else can break down your bid walls as there aren't enough shares.  That forces trading to be above the walls - making it look like it's the real range and fooling those not paying attention into believing the market set the price.

The only way that could be done here is if I was in on it - and I think if I refused to sell more PURCHASE or to split them there'd soon be threads pointing out that I was fixing the market by limiting supply.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 [50] 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 ... 130 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!