They already said it'll be dynamic - so when shares sell out on one more will be released there until all are sold.  It's the only sensible way to do it - let demand determine how many get sold where and avoid the scenario of being sold out on one exchange whilst on another a bunch sit there unwanted.

I was referring specifically to the message they'll get when looking at the security of their euro-denominated deposits.  I don't dispute there are benefits in other areas - but the most critical one with deposits of any kind is knowing that they won't vanish/devalue.

Let me also explain why having your own exchange-rate that lags behind the market won't work : as you don't appear to have grasped the problem.  I'll use an example of BTC halving vs Euro in a short time-frame : remember that on the recent bubble (and on previous ones) it actually fell by a lot more than 50%.

BTC has bubbled up nicely and your internal rate is at 200 euros per BTC (other exchange-rates have gone higher but you haven't caught up - which adds a seperate problem that I won't bother discussing).

BTC then crashes to 100 euros per BTC.

With your 30-day average your rate only drops to 190 euros per BTC (obviously your buy and sell spread are either side of that).

Problem is that you accept BTC deposits.  If your rate doesn't also drop to around 100 euros per BTC then people can:

Buy BTC elsewhere
Deposit them with you into a BTC-denominated account
Withdraw from that account in euros - either in cash if allowed or if not via purchasing with your cards.

There's plenty of ways to convert cash on a card into physical cash/cash in a bank account - most have costs associated with them but with an 80%+ profit margin those aren't going to be much of a barrier.  Most of your merchants are going to want euros not BTC so you''re left with the problem of internally valuing BTC at 190 but having to settle them when you can only get 100 for them on the open market.  And that cash isn't going to just cycle through once - anyone who spots the opportunity is going to shovel as much cash as they can through it.

And then when BTC finally rises back elsewhere, your rate is going to lag behind on the climb again - at which stage they can deposit the last batch of euros with you into a BTC-denominated account then withdraw the BTC as BTC.

There's no way around it unless you either:

a) Run a MASSIVE spread - which would discredit you immediately (can you even imagine the response if you gave one rate on deposit and a rate that was 50% worse on purchases?)
b) Disable transactions in one direction after large-scale currency moves - i.e. not just put your own head in the sand put force all your customers heads in there too.
c) Forget the stupid idea of having a pretend exchange-rate and stay fairly close to market rates.

Problem with c) is, of course, that you then need heavy-duty hedging in place.  And that costs a lot and isn't very easy to do - in part because noone else is doing it extensively so there's noone supplying the facility at reasonable rates and high volume.

I guess there's theoretically an option d) which is that you don't publish rates at all and people just have to accept whatever you give them - but that's like option a) just worse as far as credibility is concerned.

Now you can MAYBE bluff your way through with most people - but it doesn't need too many understanding the problem for there to be a run on euro withdrawals any time BTC falls significantly.  As if your disclosed strategies are no more than "we'll hedge but we haven't disclosed how and there's no provision in our accounts for any costs of hedging" then noone with any sense is going to leave euro-denominated deposits with you backed by BTC with a lower market value than the euros if they can just withdraw the euros into cash.  And even a small run on euro-withdrawals makes the situation much worse - as in the process of filling those you reduce the BTC/euro cover for the rest.

Your idea of time-locked deposits that pay a percentage of the increase in BTC's price is interesting on the face of it however:

1.  If you're guaranteeing no loss (or, worse, guaranteeing a minimum return) then it means you have to hedge even more efficiently (as by giving away part of the gain when it rises you have less surplus from that to hedge with against any fall).
2.  If losses are passed on then rather obviously they'd be better off just buying BTC themself and keeping ALL the gain and none of the CP risk.  Think even the really stupid ones would spot that.  As they can't spend it none of the other benefits apply to mitigate.

It also follows from 1. that if they get a percentage of gains then you must have a transparent means by which your rates are set based on third-party sources.  You can't be making them up yourself arbitrarily if you're paying variable interest on deposits based on those rates.  Which totally limits your flexibility in terms of the burying-head-in-sand strategy.

Yeah the key part is "the selling fund gets a more attractive purchase price" which obviously wasn't the case.  Had there been a block sale at .0014 - half the transaction fee then it would have made sense (as both the buyer and the fund would be better off than had it been done on the market).

Sold   906
Swapped   0
Total   906
Price   0.01208
Total   10.94448
Less Fee   10.92259104
Man Fee   0.327677731

BTC Balance (BTC-TC)   1552.757764
9071 LTC-ATF.B1    90.71000000
Coinlenders CD 27/9   201.5136136
Coinlenders CD 12/9   101.775672
Coinlenders Cash   3.95488561
Just-Dice Balance    247.00000000
TOTAL ASSETS    2,197.71193475
   
Outstanding MINING   182315
Outstanding SELLING   182315
Outstanding PURCHASE   8654
Effective Units   190969
   
Block reward   25
Difficulty   86,933,018
Hashes per MINING   5000000
   
Daily Dividend    0.00002892
50 days (Min Liquid)    0.00144625
100 days (Forced Close)    0.00289249
365 days (Buyback)    0.01055760
405 days (IPO)    0.01171460
400 days (Post SELLING div)    0.01156998
410 days (Pre SELLING div)    0.01185923
   
NAV Post MINING Div    2,192.18816732
NAV/U Post MINING Div    0.01147929
Days Dividend Post Div   396.86
SELLING Dividend    -         
NAV Post SELLING Div    2,192.18816732
NAV/U Post Selling Div    0.01147929
PURCHASE selling price    0.01205
PURCHASE buy-back price    0.01125
   
J-D House profit at report   6237

30% change in difficulty doesn't necessarily it means it's overvalued - it could have been undervalued before (not saying that's the case - just pointing out there's two options not one).

On your first paragraph, yes - volume is (a large part of) the long-term solution.  By which I (and I assume you) mean much more conversion between BTC/X for purposes other than speculating on the price of BTC/X.  That they're trying to move in that direction is great - but the problem is that they're trying to do it by speculating with the funds of depositors which is going to make finding depositors hard unless they hide/play down the fact that they ARE actually speculating with depositors' funds.

On your second paragraph the effect if they held most in euros would be to make their IPO a non-starter.  Their profit plan is, in a nut-shell, "bet other people's money on BTC rising vs Euro then hope it rises".  That's their main profit-source by orders of magnitude.  Remove that and they have no profit.

Thanks DT.

I didn't need to use a calculator to immediately see that the old table was wrong.  This one from very quick mental arithmetic makes sense.

This new table also makes plain that it's in the interests of existing investors for more shares to sell (by showing how initial hashes/share rises as more shares sell).

This remains the largest problem I see with this.

On the one hand they project having millions of euros deposited with them - and trading well enough to be handle a crash in the price of BTC.  But on ther other hand they project zero profit from their trading.

The profit projections also don't seem to include any cost for hedging.  Hedging costs to do.  When you hedge you aren't looking to make a profit - you're intentionally giving up some profit in order to protect against potential loss.

The other strategy mentioned is the Ostrich approach - use an internal rate to pretend the rate hasn't changed.  That's flawed horribly in a few ways - doubly so when they also allow euros to be deposited but stored as BTC.  There are rather huge problems if you use a trailing rate but then allow people to perform transactions in both directions and withdraw BTC.  Short of having a massive spread between their buy/sell rates (by massive I mean that if BTC doubles or halves you get a 100% spread) it leaves them wide open to massive arbitrage making the problem they're trying to pretend doesn't exist become even worse.

There are also problems I can see with the marketting of it to the public.  Remember their projectiosn are that nearly all customers will be depositing euros and keeping their account denominated in euros.  And remember they're selling in Cyprus where bank users just lost a load of cash due to banks speculating badly with their funds.  Here's what seems to be the honest sales pitch to depositors:

We're not a bank - we buy BTC with your euros and use those to ensure you can get your euros back at any time.
If BTC rise vs euros then we keep the profit.
If BTC falls vs euros then you have to hope we make enough profit from undisclosed trading/hedging by undisclosed experts using our own funds which are a lot less than what we hold on deposit.  This is backed up by us pretending the rate hadn't changed and hoping that it rises again before people notice and start doing mass withdrawals to be safe.

It's not a sales pitch that would fill me with confidence that I'd be better off than just shoving the euros under my mattress.

A lot of what they're trying to do is great - but the whole revenue model seems to revolve around a belief that BTC will steadily rise vs Euros (if they're using a 30-day average or whatever as is claimed in this thread then even short-term spikes/dips will be exploitable by people arbitraging vs their own rate).  If they really are going to use an internal rate and a credible spread (like 5%) then there'll be some serious cash to be made from them until they wake up and realise you can't use a pretend price when you allow trades both ways and have to buy/sell from the market yourself if there's significant net trade in one direction.

I thought DT allowed smaller transfers than that - though I could be wrong on that as I've never tried moving any out myself (only ASICM transfer I've done was a single deposit of them from direct shares into BTC-TC).

I'd read Ukyo's view as being that he was going to disallow smaller trades - if he wanted to remove even the 250+ then that would need a contract change.  Then he'd have to offer everyone a chance to transfer out (even smaller amounts) before such a change went live (there's no provision for changing the contract so everyone would need to be offered a fair exit if he wanted to change it).

Due to various cockups/delays it's not possible to withdraw ASICM shares from Bitfunder.  That makes them like USD on Gox - not able to be withdrawn/converted into the real thing, so trading at a discount to those able to be converted.

It also makes arbitrage impossible - which is the means by which the gap would usually be closed.

Ukyo appears to be creating a feed-back loop on it as well.  He doesn't want arbitrage to occur - which causes the gap to widen, which increases the demand for arbitrage, which increases the workload he'd have if he allowed arbitrage, which makes him even less keen on allowing it etc.

I don't think it's a scam either.

But your explanation is incorrect.  We aren't talking about private shares (the ones that don't receive dividends unless .0016 is ever reached) but about public shares that were sold off-market at below the official price.  It's debatable whether that was allowed by the contract (contract allowed changing price of batches but nowhere allows undocumented sales at below the stated price) but it's not something worth making a huge fuss over.

That could well explain it.

I've done a news item announcing the motion - which I set to email to all SELLING investors, but not to post as news on the front page (as it would just be spam to anyone not holding SELLING).

Sorry - but the math just doesn't add up.  Let me explain why in more detail.

At the minimum (current level) you say:

20k BTC raised from public sales is being paid to Hashfast (on top of that there's 4400 BTC being used for infrastructure).

If it reaches the next tier your table says:

27.5K BTC raised from public sales is being paid to Hashfast (presumably the infrastructure costs are at least as much given there's now more hardware to be deployed).

So 7.5K more BTC from public sales is being paid to Hashfast.

But your table shows only 4 million more public shares having been sold.  4 million shares at .0016 is only 6400 BTC.  So even if all shares are sold on the market with zero fee you just aren't actually 7.5k more BTC from public sales.

The same problem exists but even worse for the last batch of shares.

I can think of various explanations for this and the NICEST one is that there's an error in the table (either in the numbers or in the labelling of the columns).  One such explanation would be that private investors are only putting cash in if the extra batches sell - and that their cash is listed as being as "Raised from Public" which is clearly wrong (and which would explain why your explanation of the numbers appears to include $0 from private investors if there are no future sales).  So the answer could simply be that the column titled "Raised from Public" should be titled "Paid to Hashfast" and includes payments from private investors that depend on the extent of future sales.

Think you misunderstood my point here.

I wasn't talking about later shares being more expensive - I understand why you did that (though I don't necessarily agree with the reasoning).

I was talking about you getting less hash/USD from Hashfast.

You get more hashes (over 10% more) per BTC (and in absolute terms) according to the table for the next 7500 BTC you raise than for the final 7500 BTC after that.

Sold   1347
Swapped   0
Total   1347
Price   0.01209
Total   16.28523
Less Fee   16.25265954
Man Fee   0.487579786

BTC Balance (BTC-TC)   1547.659394
9071 LTC-ATF.B1    90.71000000
Coinlenders CD 27/9   201.3930587
Coinlenders CD 12/9   101.7114081
Coinlenders Cash   3.95265895
Just-Dice Balance    246.80000000
TOTAL ASSETS    2,192.22652020
   
Outstanding MINING   181398
Outstanding SELLING   181398
Outstanding PURCHASE   8665
Effective Units   190063
   
Block reward   25
Difficulty   86,933,018
Hashes per MINING   5000000
   
Daily Dividend    0.00002892
50 days (Min Liquid)    0.00144625
100 days (Forced Close)    0.00289249
365 days (Buyback)    0.01055760
405 days (IPO)    0.01171460
400 days (Post SELLING div)    0.01156998
410 days (Pre SELLING div)    0.01185923
   
NAV Post MINING Div    2,186.72895876
NAV/U Post MINING Div    0.01150528
Days Dividend Post Div   397.76
SELLING Dividend    -         
NAV Post SELLING Div    2,186.72895876
NAV/U Post Selling Div    0.01150528
PURCHASE selling price    0.01208
PURCHASE buy-back price    0.01128
   
J-D House profit at report   6143

Nice profit on J-D today - together with the weekly LTC-ATF.B1 dividend that meant NAV/U hardly dropped at all today (it doesn't drop a lot anyway but today it only fell by about 1/3 of the MINING dividend).

The transfer bot wasn't working for a few hours.  Problem was me not the bot - I restarted the computer then when I set the bot running again I accidentally left it in read-only mode (where it doesn't actually send).

Just noticed it whilst auditing prior to dividends/report and have set it running properly again plus got it to process the back-log (there were 4 transfers in that hadn't been processed).

All transfers should now be up to date and the bot's running as usual..

Noone's compelled to vote again.  And I've never tried to pressure anyone into agreeing with me - just into voting.  If there'd been more NO votes than YES (even if a lot less than 50%) I'd have dropped this one.

The majority of people who voted, voted Yes.  I can't start assuming people who didn't vote meant 'NO' - the most obvious conclusion is they had no interest in the outcome OR weren't around to vote.

My comments on further investment are simply that if there aren't enough active investors willing to vote on motions then there's no point me putting up short-term motions on things which are time-critical.  I'd still put up long motions on things without the same time element - but there just aren't any of those around (Coinlenders was one - as it had unlimited supply of investment at face value so for something like that I could put up a long-term motion).

The real problem is there's a lack of suitable investments - things with a near-guaranteed face-value (in BTC) and where there's good disclosure of what the funds are being used for.  So when such things do show up they tend not to be available for long.

Well the contract says "For the first two of these only a simple majority of DMS.SELLING is required".

There's no quorum defined in the contract but in practical terms at least 50% of shares have to vote for a simple majority to be achieved.  No votes, abstains and not voting don't have exactly the same effect.

Abstains reduce the number of Yes votes required - it's a means by which someone can indicate that their shares don't count towards the vote at all.

A large number of NO votes means I abandon whatever was being voted on.  If the same shares didn't vote instead then I'd put the motion back up again (as may have happened here) as there wasn't any indication of opposition to the motion.  So voting NO and not voting has identical impact on the outcome of a motion - but a different impact on how I interpret the results and thus act going forward.

There's no point even discussing changing the voting rules - as that would require a vote to pass by an even larger majority (and not just on SELLING but on MINING as well).   And any change that requires less than a proper majority would need other changes as well - such as defined minimum voting periods (which would have to be significantly longer).

The motion to allow investment in CIPHERMINE bonds didn't receive enough votes for an outcome to be determined (although a clear majority of those voted went for YES it needs to break the 50% mark to be a valid result).  Basically there wasn't a valid quorum.

I've put the motion up again for slightly longer this time - but if the majority of investors aren't around then obviously it'll not receive sufficient votes again.  In which case at least I know not to spend time trying to find investment opportunities (suitable investments are generally not going to available at face price for too long - so leaving a motion up for weeks isn't a viable option).

Yeah - and they're very convenient ones as well : effectively Bitcoin profits don't have to be declared for tax until they're converted to fiat.  Which allows payment of dividends to virtual shareholders pre-tax.