Come again?

When you buy back shares (which are priced in LTC and on LTC-Global) you SPEND LTC ending up with LESS than before you bought back.  It CAN'T increase your LTC position.

If you've got more LTC now than before then it's because you converted some BTC to LTC or something - not because you bought back shares.

Buying back underpriced shares is fine - just make sure you're actually buying them back at below the current NAV/U (in LTC).  From a quick mental estimation it looks like you DID buy back just below NAV/U - but hard for me to be sure as I can't say with certainty what exchange-rates you used in your last accounts (as you didn't provide them).

This doesn't make sense.

To deterministically pair all miners you have to KNOW who all miners are.  If you have some unique identifier for ALL miners then it's pretty simple to pair them off in a verifiable manner.  But then that information MUST be saved - or noone can ever verify that data produced from those pairings was valid - a pre-requisite for validating past blocks.  All information needed to verify a block MUST be in the block-chain or noone can ever load a block-chain with any confidence in its correctness.

That's why details of all miners connected would need to be saved for every block.  You say this would be done via the bonds (i.e. connected miners would be defined as those who had paid a bond/deposit for that block).  That's where block-chain bloat would occur - as no sensible miner is going to pay a bond up front for more than 1 block given their ability to lose it due to a load of factors.

At various points you talk about "the system" working things out.  But what is this system if it isn't the miners?  Either you mean some centralised authority or you mean the miners - if the latter than ALL miners have to have ALL information or they can't collectively reach any decision.  Whilst in Bitcoin it's not an issue if a miner hasn't, for example, received a transaction, in this coin it WOULD be an issue if a miner didn't have information on ALL work done by ALL miners - as that would lead to them rejecting a block because it didn't contain the fee for a deposit they believed should be forfeited or a deposit return they believe should not be returned.  That makes network traffic proportional to N^^2 where N is the number of miners - as every miner has to have information about every other miner.

Similarly, if deposits are returned or converted to fees based on work done then that work done MUST be stored in the block-chain.  Otherwise how can blocks be verified?  Noone can sign those deposit refunds/fee charges other than a miner - so how does someone who connects to the network verify whether the refunds/fees in a block are valid?  What stops a miner who finds a block taking as fees  deposits that should be returned - and returning deposits that should be forfeited to their own sock-puppets?  The ONLY way to stop that is for ALL miners to have ALL information - otherwise noone would ever agree that anyone else's block was valid as it would be based on a different subset of information.

The deposits are transactions.  Given those are necessary for someone to mine, what incentive is there for miners to include deposits from other miners into their blocks?  By excluding other miners' deposits (i.e. leaving the transaction out of blocks you process) you can deny other miners the right to mine.  This gives the ultimate attack vector - where if a pool can even briefly get a good portion of the mining power they can progressively shut other miners out.  And even if 100 times their mining power connects, that 100 times their power has no way to mine - as it's impossible for them to submit a valid block without a deposit having been processed for them: and whoever managed to gain control has a serious financial incentive not to include any deposits in blocks.

If someone managed to hit that point then not only can they prevent anyone else mining, but they can also double-spend like crazy - with the only way for someone to unseat them being to create a new chain of greater length from a point some significant time in the past.

With a small number of honest miners the system would work fine - but it could never scale to a large size due to either an enormous increase in bandwidth/block chain AND/OR a loss of consensus causing massive chain splits.

That works - provided the expected return from the business exceeds the cost of the options/futures.  An alternative would be for the business itself to hedge in such a manner - that possibly makes more sense as the business is in a better position than investors to know what its degree of exposure is at any time.  But either route ends up with profits being significantly decreased if the hedge isn't needed - and for many businesses could end up pretty much guaranteeing a loss due to premiums on options/futures exceeding actual trading profit.

I don't disagree with any of that - but none of it alters the fact that investors would have been better off (whether measured in LTC OR fiat) had they just kept the LTC rather than bought your shares (of course there's a decent chance LTC will fall back down fast - in which case that will no longer be the case).  And that's what makes a lot of potential investors (myself included) wary of all businesses with signficant fiat assets (less so up to now for LTC investment than BTC - as LTC had previously tended to be pretty stable vs USD).

Surely this is going to lead to HUGE block-chain bloat as ALL of the following have to be stored indefinitely:

1.  Wallet address and a bond transaction for EVERY miner on the network EVERY time they join it.
2   Each block, every miner has to have a transaction either paying from their wallet to the block finder or refunding to them.

Also, there's an issue with the idea of a bond for doing a fixed amount of work.  Either:

a) It's trivial to do - so serves no purpose to prevent anyone submitting loads of fake miners to lock other people into partnerships that will never finish.

or

b) It's hard enough to do that miners below a certain size legitimately won't be able to meet it sometimes : leading to increasing centralisation of mining.

Oh - and you do realise miners can choose which transactions to include?  The incentive would be for miners to try generating missing out other people's transactions until they found a set pairing them with a partner they wanted.  Then not only can they collude but they lock other perfectly valid miners out - as the other miners can't mine at all without a bond in the chain.

Ultimately all a miner has to do is generate a block with JUST bonds from himself and a partner - then noone else can ever join as they can't get a bond payment processed.  Or run a pool with a high fee that only includes deposits from its own members: the fee is worth it for members as once the pool finds a few blocks they gain a shot at locking everyone else out from mining.

I'm not convinced just how useful this is for starters.  It's pretty easy to detect whether a Mersenne number is composite - and it's definitely NOT in miner's interest to be checking a Mersenne number that may actually be a prime.  So miners would focus on numbers that definitely were NOT prime - and hence deliver absolutely nothing useful (or do you know of some use for the factors of a Mersenne number?).

Also, with a difficulty level, miners would be best served not checking below a prime of the requisite size (as no use to them finding it) and moving to a new candidate if/when it became more efficient than continuing to check the current one (the extent to which this is an issue depends on the method used to check primes).

Other problem I see is the allocation of work.  This has to be done to prevent offline generation of a bunch of results then a double-spend attack.

And of course a pool of miners can collude and store results which don't quite meet the difficulty requirement - then leave network to lower difficulty and submit them on rejoining (and mine offline in interim).

Biggest problem I immediately see with beeble's post is it's very hard to deal with things like assigning miners to groups when people are constantly joining and leaving the network.  Then there's the issue of how someone who just joined can have a bond somehow verified so they can start mining immediately.

Any system which requires EVERY node to know every other node in the network is just not going to work.  Any deterministic way of pairing people off based on wallet addresses NEEDS either that - or a centralised authority.

The former (knowing everyone else on the network) fails because above a certain size the participants in the network will change (or appear to change) far faster than a complete list can be circulated and agreed upon.  And not only does the list have to be agreed upon and propagated, it has to be stored forever - so it can be verified that a team claiming work were actually a valid team.

For that reason alone, I don't see anything which requires teams to be feasible.  And as you already realised (which is why you added teams I assume) it's totally exploitable without them.

Well we know that the fiat part of assets have more than halved in LTC value and the BTC part have about halved.  So it's reasonable to guess currently value of assets/shares is around 3.5-4.5 LTC.

Of course their value in fiat has increased (and their value in BTC decreased by not by so much).  But rather obvously the value of shares in LTC has dropped - as income/share will have dropped as well (assuming prices are set in fiat) as well as assets/share.

That's one of biggest issues with ALL businesses that have fiat-valued assets and income : if crypto rises then the value of shares falls faster than profit can make up for.

Pretty sure he's operating the BTCjam loan as per his schedule in the thread.  BTCjam loans are always horribly unclear anyway - there's plenty of examples of repayment terms ending up not being what the borrower thought they'd specified.

Don't get me wrong - I reckon there's a significant chance he's doing/done a hit and run : but the debatably late payment on BTCJam isn't an issue due to his intended payment schedule having been published well in advance on the BTCJam listing even being created.  Plus the stated purpose/use for the loan (as described from him in various places) isn't such that it would make sense for him to make repayments right away.

I wouldn't personally have loaned him anything on the information available when he was borrowing all over the place.  But nothing has changed since then to make the risk of scam any different.

Pretty sure you misread the thread.  Read it again.  No payment is due as described in that thread for another few weeks.

Which doesn't mean he's not scamming - but does mean that there's no evidence of it (if he has).

I'm not seeing anywhere in that thread that he intended to make any payments on March 8th.  I'm reading that he didn't intend to start paying back until the end of the month.

"Payment schedule as follows:

March 1- borrow 600
March 8-  owe 621
March 15- owe 642.735
March 22- owe 665.230725
March 29- owe 688.5138 / 8 = 86.0647 payment = 602.4491 leftover"

No payment until March 29th - where do you see in that thread him saying he'll pay anything on 8th?

I was about as suspicious as you about all the loans he's taking (and borrowing things to 'short', some of which it's basically impossible to short - e.g. BTC-BOND) but not seeing how we was expected to make any payment yet.

Yeah - the work needs to be much more the nature of finding a needle in a haystack (easy to verify it's a needle once it's found) than calculating the total length of all bits of hay in said haystack (only verifiable by duplicating the work). 

Whilst verifying a number is prime is obviously MUCH easier than finding the next prime number after X it has to be remembered that blocks need to be able to be verified by ALL users of the block-chain, so needs to be able to be done by someone using just an old CPU in a trivial amount of time.  That really does cut down the useful work that is feasible - as the work has to be divisible into parts that are individually easy to either compute or verify (which also means there have to be an immense number of such tasks available).

There's also the problem of duplication - you have to ensure that if valid work is done it isn't feasible for someone to submit something based on the same work again for a future block.  That means verifying involves checking against a list of all previously computer work contained in the block-chain.  And you then still have to deal with the problem that if the same work is being done outside the block-chain then results from that can also be submitted without the submitter having actually done the work at all.

The first of those "hard to do but easy to verify" isn't such a huge problem.

The second "no central delegator of work" is also not too big a problem in terms of making the concept work, but IS a major issue in terms of making the work efficient.

The real problem I encountered when I considered a similar issue is finding work which is useful AND which can't be done before the previous block is published to the chain.  Bitcoin gets around it by making data from the previous block the key element in the calculation - hence preventing someon stock-piling a bunch of solutions in advance then using them to double-spend later.

You can't get anywhere near a good solution by doing some hybrid (e.g. solving some useful problem then hashing it with the previous block) as either:

a)  The hashing part produces no protection due to being too easy (allowing stock-piling of results and double-spending)
or
b) The hashing part is very hard - making the 'useful' work just a cosmetic change with the bulk of the work being done just as in Bitcoin.  And even then it STILL reduces the power needed to double-spend.

There ARE ways to try to solve this - such as using the hash of the previous block plus the public key of the miner's wallet as the seed to generate a starting point for work (assuming work can be found which can be apportioned based on a key/hash - not too hard if you consider all work can conceptually be split into a number of pieces and any key can be converted into a number in a specific range).  You would then need a function which could take this combination of hash/key and generate a seed.  That seed would then be used as the starting point for a search in the target domain.  You'd then need some limit set on what was considered a reasonable depth from that starting point to be a valid result.

It would still be horribly inefficient - as you couldn't track who'd done what work without finding a valid result (there'd be no incentive for miners to report work that found no result - as it would be against their interest to prevent others expending effort rechecking it on later blocks).  For a large enough domain of work that wouldn't be a huge issue.

The 1000 have sold.

Which means it now falls squarely into a gap in your revised contract which says:

"For under 1000 shares, the management fee shall be 3%.  For over 1000 shares, the management fee shall be 2%."

So what's the fee for exactly 1000?

Most recent information you'll find on here is at the link below:

https://bitcointalk.org/index.php?topic=138956.msg1598165#msg1598165

The 40 TH one is definitely a scam.

The 1 Petahash one could be real or could be scam - no way to know yet.  If some company bites on their offer then that company will find out based on whether they get given a demo or asked for some cash up front for some unforeseen problem that just cropped up.

Exchange-rate : .005
Adjusted NAV/U : 55.244 (as it's below last week's HWM it's same as unadjuested NAV/U of course)
Bid at : 52.5 (can't change it as LTC-Global not functioning)

LTC dropped a bit but has now gone back up above where it was when last I reported.  As you'll notice, our NAV/U has grown from then anyway - though is still about 3.6% down on where it started the week.  Ignoring the impact of exchange-rate movement we're up a bit over 7% from trading so far this week.  I'd settle for losing 3.6% of NAV and LTC rising by 2/3 in value EVERY week if given the choice.

Trading has been painful this week - with BTC-E down a lot of the time, issues with MPEx (CoinBR not reporting proper market data for most of yesterday and now reporting MPEx as offline for insfratructure upgrades) and now LTC-Global unusable for last 10 hours.  But we'll soldier on - and hopefully end the week at break-even or better on NAV/U but with a much more valuable LTC than we started the week.

The issues with BTC-E and MPEx have seriously crippled my ability to properly make is (and investors in our pass-throughs) money from buying/selling with the movements of LTC.  Luckily I've found some decent spots for trading on BTC.CO/BitFunder/LTC-Global - though have also had a few cases of buying with bad timing (inevitable with massive exchange-rate moves - but no big deal so long as the occasions I buy with good timing continue to outweigh them heavily).

They started adding this - I was one of the few accounts given that functionaility for a while (it seemed to work fine but never displayed the correct reserved funds).  But apparently some idiot on irc managed to convince them it doesn't add liquidity so they removed it (with some people it won't add liquidity, with others it will - but for very very few will it remove liquidity, so overall liquidity across all securities DOES increase as a result).  The main increase comes from those trading on multiple sites - who can move more funds in if some orders get filled but don't want to cover every order 100% all the time when most orders only have a small chance of being filled in any given week (many assets there's often days or weeks without any significant trading volume - making it hard to justify leaving funds there backing just an order on that asset).

The lqiudiity it adds could be improved if instead of totally cancelling orders it just scaled the quantities back to match available funds.  This avoidins the situation where I have enough cash for 199 shares, place orders for 100 on each of 2 different securities and when one fills the other gets totally cancelled - which is one of the few situations where it CAN remove liquidity, though only due to bad planning by the person placing orders.

If added back in, it should really be an optional feature - not everyone wants to use it.

400k shares were issued.

Original plan was for 200k to go to Bitfountain and other 200k to be sold on GLBSE.  But BTC rose vs USD so there was no need to sell 200k to raise the needed capital - so only 160k or so ended up being sold.

It makes no difference to dividends - as each share is entitled to 1/400,000th of profits, regardless of how many shares are sold (that's how the contract was written).  That acted as protection for investors - if extra capital had been needed to be raised then original investors' portion of profit would have been protected, with the equity given away for new shares taken from Bitfountain.  As it happens, it's ended up the other way round - and, of course, we now have a few greedy people who when they see the risk has gone would like the contract rewritten so they get 1/360,000th of profit instead of 1/400,000th.

The situation on voting is less clear - there I'd expect it's simply 1 share, 1 vote.

Because that way they make up to a few hundred thousand USD even if the site never works.

Making the web-site is the easy bit.  Sorting out fiat deposits/withdrawals and attracting a customer base is the hard part.

To get same volume as BTC-E they not only have to take a large part of BTC-E's business but also take some BTC/USD custom away from MtGox (or draw in a bunch of new trade not currently using exchanges at all).  I see no information on how this is going to be done - just a demo website, the visible part of which could be knocked up in under a day by a competent web-designer.

I'd like to see a new strong competitor to BTC-E myself - but i'm not a big fan of vaporware IPOs.  I struggle to think of a single BTC website-based business which sold shares before having any customers then ended up doing well for investors.  The few that have done well (for investors) waited until they were operational and had some sort of respectable trade before selling shares.

ANY sort of plan would be nice to see - not just "we'll build a website and make lots of money".

The approach of "I'd like to do something for the community - so please send me money" is getting rather old now, as well as being overused (by pretty much everyone asking for funds for something that doesn't actually exist yet).  They're all doing it for the community - not for the funds going into their pockets even if the project fails.  None of them need the money - it's just an unfortunate side-effect of them helping the community that everyone has to send them it.  Does ANYONE actually believe that?