I'm sure if his personal cut is dropping he'll fix that bug quickly.  Either that or halt the chain and then relase SC3 with even more premined coins, a higher tax and everything mined by super-nodes with random rewards given out to miners based on connection time (unless blocked by a super-node).  That would totally solve the 51% problem.

Don't make me look up the URL.  There was some conduit where you moved to a seperate account 2 or 3 million TBX and were releasing them to the conduit 50 at a time - so only 4000 (if it was 2 million) or 6000 (if it wasd 3 million) transfers needed to use up the escrowed coins (using the term escrow very loosely).

Which doesn't seem all that unlikely - if he isn't BCX then he's definitely hanging off his dick.

You "theoretically" having a way to decentralize control of your slush-fund is in no way the same as it being decentralized.  Once you no longer have control over it THEN you have the right to criticize SC2 (on that issue - you obv have the right to criticize it on all its other flawas already).

TBX and SC2 both have one person controlling a large number of pre-gernerated coins.  Spin it how you like - but until you no longer have the OPTION to sell/transfer them you're in the same boat.  Talk of how you 'could' lose control of them carries no weight with me: talk's cheap - action is what convinces me.

Yeah I'm in the camp that believes BCX had a big mouth but never actually did anything much - he just claimed responsibility whenever an alt-chain encountered difficulties with noone obviously claiming responsibility for it.  But plenty of credit to him for exposing just how lame all the pre-mined alt-chains actually are.

Have to say I think BCS is lieing through his teeth.  I think he gave up on attacking SC2 when he couldn't get the source-code.  Then when it struggled (due to piss-poor initial diff lvl) he tried to claim responsibility.

Nothing I've seen suggestshe's actually done anything to it.  Obviousl it's still an alt-currency with huge premined coins and noone should touch it with a barge-pol (other than miners who believe they may be able to cash out through exchanges before it finally dies).

BCX had a lot of interesting things to say but, ultimately, I think he was full of shit.

Only another 7700 bounties and you'll have used up the premined fund.

Obviously that ignores the 2 million (or was it 3 million) set aside to be released 50 at a time for the conduit - ony 4000 or 6000 releases before that's gone too.

I also have a suspicion (no more than that) that he may actually be well-intentioned rather than trying to scam - just unfortunate he manages to do everything in a way which screams "scammer!".

There's two big things which turn off a lot of people here:

1.  Concealing information (most obviously closed-source).
2.  Central control of pregenerated funds.

SC is obviously not the only one guilty of 2 - and, in at least one respect, SC2 is better than Tenebric for that.  SC has the OPTION of fully detailing all wallet activity relating to the pregenned coins (and has stated he intends to do so).  Tenebrix can never do that with a stated intent of the pregenned wallet being used for laundering purposes: if all transactions are described then laundering can't work, whilst if all aren't detailed then it can never be proven that the pregenned funds haven't been dumped on exchanges.

End of the day it's pretty obvious to everyone that there was no need to generate and funnel funds to defend against 51% attacks.  And if a fund was needed for something then it could have just been openly generated up front.  All of the obfuscation just LOOKS like an attempt to do it under the radar.

Bottom line (for me) is that "you have to trust me - my intentions are good" has never been a good selling point to me.  If someone's intentions are good then I tend to expect them to go out of their way to demonstrate it by removing their own ability to scam the system.  Talk of future oversight committees (or whatever they're called) is just that - talk.  If I trusted talk then there wouldn't need to be a committee.

So to be clear on this, the sole criteria to generate the alternate blocks (at difficulty 1) is that you have control of an address with a balance of 1 million+ SC2s.

And when clients verify the block they check the address signing it and scan the whole block-chain to make sure they have a balance of 1 million+ SC2?

That leads to two questions:

1. Isn't calculating the balance of addresses signing those blocks rather computation intensive?  Is there some short-cut to work out the bal;ance of an address that doesn't involve reading the whole block-chain?  If that's really what happens then isn't the network vulnerable to someone spamming 1 difficulty blocks signed with loads of different addresses - the time to parse the whole block-chain for an address is gonna be longer than the time to generate a 1 difficulty block.
2. If the client knows the addresses of the 1 million-holding accounts (to block spends from them) then I still don't see why yo udidn't have the criteria for generating the alternate blocks being "either it's one of these known addresses OR it holds 1 million+ SC2".  Down the line you could remove that code if you chose (meaning only the 'real' millionaires could make them) and there wouldn't be all this controversy about the pre-generated coins.

On an aside, I assume you still have the private keys for the super-node wallets (or we have to take your word for it that you deleted them)?  So saying you don't have control ofthem is misleading - as you have access to them and the ability to remove the hard-coded spend-block on them from the source-code.

I'm by no means totally opposed to the PRINCIPLE of how you're stopping 51% attacks - but the pre-genned coins seems needless and hence LOOKS like scam.  And there's a fair bit of hypocrisy in your comments elsewhere about exchanges providing RL info on their operators (to reduce the likelihood of them scamming), but you (with the ability - and a past record - of rewriting the block-chain) give no information at all on yourself and fail to identify who the trusted nodes are.

Bumping this on the (very) unlikely chance that he overlooked what (I believe to be) serious questions addressing the very basis of the "trusted nodes" and pre-mined coins.

I'm pretty certain he's lieing at least on one thing:

His "white-paper" basically says the premined wallets are place-holders "until Solid-Coin does have real millionaires".

But elsewhere he's said that every other block has to be mined by a super-node/trusted-node - which get to mine at difficulty 1.

Unless super-node/trusted-node = SC2 millionaire then rather obviously one of those statements is a lie.

IF super-node/trusted-node DOES = SC2 millionaire then that would make another statement of his a lie - that there were multiple criteria to be met to become a trusted node (I suspect there's only two criteria - that your nick rhymes with loinmunter and that you're a scammer).

And as it's not open-source, how are we supposed to:

A.  Know that's the case.
B.  Know that any update doesn't change it?

If the answer to those is "you have to trust me" then WTF is the point of hard-coding it in the first place?

Well there's a few obvious questions that spring to mind from it:

1.  How does the network "know" that a node has more than 1 million SCs in a wallet?  Are all generated blocks somehow signed with the address of the largest wallet you own?
2.  How are these wallets with the 1 million coins not able to be used for transactions?  Are we suppsoed to just take SC's word for it - or is there some special functionailty about those accounts?
3.  With any reasonable answers to the above two questions it seems likely to me that the same could have been achieved without pre-genning the 1 mill coins in the wallet.  IF those 'special' accounts ARE somehow different to normal ones then surely the test could be that EITHER the node must hold 1 million coins OR it must own one of the special wallets (without them needing to actually hold 1 million coins).

Doubt we'll get straight answers to the above - but:

A.  If the answer to 2 is "we have to take his word" then obviously his white-paper is intentionally misleading due to him claiming the money "can't" be used rather than that he "won't" use it.
B.  If the answer to 2 is that those accounts are in some way different to other accounts then obviously it follows that there was no need to generate the coins - the special 'status' of those accounts could have been detected instead.  And any such special status HAS to be detectable - or the network wouldn't be able to tell to disallow any attempts to use the content of them.

If he's either lied about the status of those accounts OR has generated millions of coins where there's no reason to (unles he wants to pump and dump with them ofc) then seems like it's just a get rich quick scheme at the exense of anyone gullible enough to buy SC2s (though I find it hard to have any sympathy for anyone that stupid).

If making a claim without providing proof is reason to be banned, then surely SC should be banned for claiming SC2 is 51% attack-proof but not not offering proof (e.g. the source-code).

Note: I DON'T believe making a claim without substantiating it is a reason for banning.

I'm not even sure why SC is on here tbh.

Bitcoin is an open-source, decentralised, peer-to-peer currency.
SC2 is a closed-source, centralised, peer-to-trusted node (which may as well be servers for the non-existent disclosure about them), currency.

I guess that it uses cryptography is the only pont of relevance - but when it's not even disclosed what the cryptograph(s) used are then there's really little that can be usefully discussed.  In effect it's a commercial product (you can't get much more commercial than taxing currency at creation - irrespective of vague assertions of "good intent" with the taxed proceeds) using this forum for free advertising - with the stated intent of harming the product this forum was designed to support.

The real thing you need to hope for is that there are people dumb enough to buy your coins. An exchange is no use without buyers - and hard to see anyone buying at a price that will cover your power-costs (or the opportunity cost) until block generation is somewhere around where it's meant to be and there's some confidence SC won't close the chain and reopen a new one with more premined coins and a higher tax rate.

Can confrim I received my 0.2BTC bonus.

Sent.

You can send the 0.2 back to the address I sent from (14yTB7UpBAxDVEnQP2YL5f9TuQtWBpKMCy).

Would seem to me your best bet is to send to the first 10 addresses you receive from - as otherwise you have no way of knowing whether people who claim to have sent actually did.

Yeah - that's the sort of projections I was thinking about, though there's a few errors in them at moment.

Before you try to put them right you may want to wait to see if there's any interest from others in investing - as so far noone else seems to show much interest. Think most people here are more interested in speculating than investing.  Do note that whilst I AM making all these posts as a potential investor you're not likely to see a huge investment from me - probably only about $500ish - so you definitely need a bunch more interest.

Here's what I spotted as needing fixing so far:

1.  AS you already noted, hardware valuations are off.
2.  Electricty usage is wrong - look at first table month 2.  You add one rig but electricty cost drops by 5%+.  Even without adding any rigs it would only go down 1%ish due to BTC/US$ rate only going up by 1%.
3.  Net profit looks off to me after 1st month - e.g. in month 2 it's greater than gross earnings and in no month other than 1st is it equal to net earnings-elect cost.
4.  For comparison to wallet performance you need to compare it to 3500 BTC not 2500 BTC (and use a base value of 3500 BTC for project).  That's because investors are investing 2500 BTC but profits are shared as though there was 3500 BTC (due to you having 10k shares at start).  Obviously your own 2kBTC worth of hardware that's being added to the project should be included in initial hardware value.  That means that the project will start off being 800BTC in the red - which is correct, as if it was immediately liquidated you'd get 1/3.5 of the proceeds meaning investors would have taken a hefty loss (the projections need to value things from an investor's perspective).

Few other points:

1.  Looks to me like you're assuming about 900W/hr per rig power usage - is that correct?

2.  Cases I'd say to focus modelling on realistically are the feasible ones (e.g. I wouldn't worry about difficulty going up a lot AND BTC falling). No point doing ones with +/- 1% of either as it really won't change anything much and just makes verifying figures harder.  Here's the ones I'm most interested in:

a) Steady State - no real change in anything.  0% diff increase, 0% change in exchange rate. 
b) Increased mining but no growth.  10% diff increase, 0% change in exchange rate.  This one represents other people doing what you're doing but no real growth in BTC.  I'm not actually fussed about diff increase AND drop in exchange rate as I don't see that as likely.
c) BTC growth (exchange driven) : 10% exchange increase, 5% diff increase.  Would expect this one to be fairly good and if exchange rate starts to go up decently it's likely diff increase will lag behind.  I don't personally expect any huge increase in BTC exchange rate in the short-medium term but steady growth wouldn't surprise me.  This is my realistic optimistic view of things.  Better is obviously possible - but not worth modelling as we already know if this one's good anything better will be even better.
d) Slow BTC decline.  -10% exchange, -5% diff.  Both across all months.  If BTC value keeps falling I'd expect diff to drop as well - but nothing like as fast.
e) BTC Crash. -25% exchange, -5% diff.  Both across all months.  I wouldn't be surprised if this actually outperforms wallet - even though I'd guess it would end up with the rigs being turned off.  This one really represents one or more early adopters giving up on BTC and offloading - with the downward trend continued by miners selling off rather than hoarding.  This is pretty much the worst I'm interested in looking at - and I don't see this as too likely tbh.

3.  You may want to include insurance premiums into expenses - doubt 40 rigs would be covered on household insurance.
4.  You need to consider currency exchanging - not sure how you plan to turn BTC unto USD but likely some % of value will be lost doing so (both in having to sell below mid-rate and possibly then in withdrawal fees).  Have you actually planned how you'll be able to withdraw $22.5k from 2500 BTC?  Pretty sure MtGox (for example) only allows some small amount per day.

Anyway, I'm off out for rest of day - will check back tonight for updates.

Well broadly speaking (ignoring the terminology of how it's defined) there's two ways of doing it:

1. A binary system - where each debt is either valued at full or written off.  This is similar to the "direct write-off" system in your link - with the same weakness that it leads to overvaluing of accounts receivable (as deliquent debt is treated as full value until it's totally clear it'll never be paid off).

2.  Writing the debt down over a period of time.  This is similar to the "allowance method" in your linked system - where accounts receivable are amrked down based on various factors over time (and eventually totally written off).


Method 2 is (imo) clearly the better - and is what my spread-sheet is a simplistic version of.  Simplistic, as the only factor I used is amount of time the debt was overdue by.  Had no option but to simplify in this fashion - as there's no other information (I had) to allow valuation of individual debts based on a wider range of criteria.  It is a safe assumption that the longer a debt has been delinquent for, the lower it should be valued (unless there are other factors indicating a specific exception).  So that's where I started.

I do agree with you that a debt doesn't even need to be overdue to be written-off (or written down).  An obvious example would be if someone took a loan then stated they were scamming and logged off for good.

It's not my argument that what my quick spreadsheet does was the ideal way to account for delinquent loans.  My point was that they must be accounted for in some way - and currently weren't.  They definitely have a value below the principal loaned - and that needs to be reported in some way.  The way in which IBB handles them is likely to be different to the way in which they're dealt with "normally" for a few reasons:

1.  Usually a large portion of deliquent loans would be sold off to debt-collectors at a discount.  It's doubtful that could be the case here.
2.  Normal requirements for reporting are based upon tax and accounting requirements.  Which I'd guess aren't going to be especially relevant here.  Hence we can (if we choose) report things in a fashion which focusses on reporting (as much as possible) the "real" value of delinquent loans rather than complying with tax/accounting requirements.

Do bear in mind that a significant part of recent economic troubles was CAUSED by banks etc over-valuing investments/debts that were unlikely to ever be realised at listed value.  There's no reason to be doing the same here.

I DO agree that the delinquency rate should drop with the much tigher requirements to get loans.  Were I doing the record-keeping I'd also be tempted to keep stats relating to each loan - things like number of posts/number of good references etc.   Then, down the line, you could actually start looking at what (if any) correlation there was between certain factors and delinquency.   It's entirely possible, for example, that certain requirements could actually have a correlation in the wrong direction.