Would it be safe to assume this is pretty much done by now?

That's a bit confusing.  If all that was lost was 20% of Bitcoins on hand it should have been possible to pay everyone out 80% (the initial round of payouts) without receiving funds from Tihan - additional capital should only have been required to replace the lost Bitcoins.  You should have still been in possession of 100% of USD and 100% of Mt Gox deposits.  Or were you still waiting on capital to enable you to replace Bitcoins which were lost in the Linode intrusion as well as additional funds to cover the most recent loss?

Do you mean there will be another claim form to fill out, or are you just speaking about finalizing the current one?

Genjix, is it okay if I use your public PGP key to encrypt the data before sending it to verify@bitcoinica.com?
And if so, what public key would you like me to use? Thanks.

In general, I support the hybrid approach.

I support expediting those people who have verifiable information and reputations.

I do not now, nor have I really ever, regarded "number of forum posts" as any sort of legitimate indicator of the trustworthiness of any individual. OTC ratings, yes. Verifiable forum trades, yes. Number of times some fool wrote "sub" in a thread? Not very worthwhile.

I do not support expediting those with largest balances. In most cases, I suspect, this is disproportionate with the actual need. I also do not support expediting those with the smallest balances, for the same basic reason. (ofc, in the cases where the largest/smallest balances are the most verifiable, w/ best reps, hopefully, /obviously/ the latter applies more)

I do not really support you keeping 20% for any longer on accounts you can verify with a reasonable degree of accuracy. We've made a long enough forced loan to you. I'm sure you've made enough off the interest to start paying the legal bills from this escapade.

I do not support the continued lack of communication with your customers. A forum thread is, at this point far less than sufficient, or acceptable. I'm really sick of having to dig around to find out what the hell is going on. Is it really that harmful to your process to send a damn email?

I'm also sick to death about hearing the badmouthing on forum and irc from the bitcoinica players. On the forum one side speaks, and on irc the other.  Just keep it to yourselves.

Anyhow....I'll believe the money when it's really seen, by more than just the bitcoinica owner's friends and favorites. Until then, this is just more in a long line of words.

* How many claims has Bitcoinica received? How does this stack up against the total amount of customers?
* Does the amount of claims exceed the amount of deposits? If so by what margin?

No part of the claim form asked for a link to any other community.  Please explain how you are securely linking claims to "community reputation".

Define 'A high rating in the community'

...

Smacks like favoritism to me.

if you guys would like wire transfer numbers I have mine somewhere for nearly the exact amount in my account (minus fees), if that helps speed up the process I'll gladly send that along.

Were they given preferential treatment?

it is necessary or not to send to the verify@bitcoinica.com notification of the мтгокс? or (I have to write verify@bitcoinica.com information confirming my account \ translations?)  is it safe? please comment on officials

Today, we have discovered a suspicious Bitcoin transaction that doesn't seem to be initiated by any one of the company owners. Some of them are not online at the moment so this is not conclusive.

Suspicious transaction:

  {
        "account" : "",
        "address" : "182tGyiczhXSSCTciVujNRkkMw1zQxUVhp",
        "category" : "send",
        "amount" : -18547.66867623,
        "fee" : 0.00000000,
        "blockhash" : "00000000000003f6bfd3e2fcbf76091853b28be234b5473a67f89b9d5bee019c",
        "blockindex" : 1,
        "txid" : "7a22917744aa9ed740faf3068a2f895424ed816ed1a04012b47df7a493f056e8",
        "time" : 1336738723
    },

We have contacted Rackspace to suspend all our servers and lock down our accounts. All your trading and financial data is safe (as far as I know), apart from the Bitcoin loss.

Thank you for your patience and understanding while we investigate this issue in detail.

No database backups. Sorry for avoiding the question.

I hoped someone else could clarify this. I don't have all the full details, and would hate to make incorrect statements. I also didn't want to jeopardise efforts to refund people.

From what I gather, there are no backups of the database. Only partial records for accounting which is being used to extrapolate balances. I'm not sure of the exact details, but I think they need a full view of the claims before payouts begin (like a big jigsaw puzzle) to properly cross match records. Hopefully someone better informed will post more details.

zhou: ah, ok. I don't know the exact details and I'll avoid commenting further.
I think Patrick assumed they were not critical hence me saying: "The assumption here was that info@bitcoinica.com did not have access to critical infrastructure.". I do appreciate that several times, you told people I wasn't involved with Bitcoinica in this thread. I always assume good faith which is why I think it was a fatal miscommunication between team members.

bitcoinBullbear: that's fine. It does annoy me a little that people assume that a decentralised system like Bitcoin consists of a single piece of kosher software. bitcoin.org lists several clients. When security flaws were found, me, Mike Hearn and justmoon helped fix problems on the internal security mailing list. justmoon in fact was very instrumental in many cases for clarifying and proposing fixes for BIP 16. There was a long technical history that led to libbitcoin's creation and it has taken 8 months so far.

That picture is funny. I like it.

rjk, nope. Everyone had root. One person was installing a database, another installed Jenkins.

The anger here is justified. If this happened to me, then I would be extremely mad. I was very pissed at MtGox when they had their problems. It sucks to be no better than MtGox.


Bitcoinica took us on to help secure them.

We decided it was bad practice to make sudden disruptive changes overnight to a production system. Instead the theory was a very gradual replacing of the system while observing changes. Bitcoinica was already very fragile. I still think that was a good decision.

Step 1 - fix the code.

Flaws were already being found in the code. That was the logical first step. That the environment ended up being exploited is simply hindsight. I would prefer not changing a working environment until after knowing how the code operates. An example is that another website accidentally made out a 500 BTC payment when the file permissions were too strict. Similarly changing an aspect of Bitcoinica without proper insight could have had grave consequences.

First you understand the code. Then you run the code. You experiment with a test system. Make improvements. Deploy changes. Change production environment.

The Bitcoinica plan was to do the above while creating a new platform to replace it in the long term.

No database, a huge mass of data (much of it useless) and a number of false claims that could push out legitimate claims. The data makes sense only as a whole which makes payouts difficult (you have to build a case and gather evidence based on the known data). Being careless and paying people without being sure is stupid as you cannot reverse payments if more evidence later ends up contradicting your early guess.

That's why the initial payouts so far have been for only 50%. And only for people we're highly certain of. I support extending that to more, but the others are understandably taking more caution. If people are paid out, then it's realised there is a mistake in our assumptions, that means legitimate people will not get paid (the pool of money for payouts is limited). $1 erroneously paid out, is $1 of someone else's money. The honest and correct decision here is being as certain as possible for people you pay out, and no amount of shouting will speed up the process. The records for making the payouts are incredibly bad and inefficient. It might take 15 mins to check a single person before you realise that the records on hand for that person are useless/contradictory. Now multiply this by 100s of people.

Someone earlier mentioned hiring people but that's not an option here. I would not trust a relative unknown with this data and the time/effort involved with finding a new person who would be competent does not make it a positive tradeoff.

People are divided into different classes depending on how certain we are of their claim. As we move through verifying accounts, we become more certain. Once everyone is refunded for 50% we then double back through all refunds and refund the last 50% at the very end.

I want to explain the logic behind 50% initial payments:

For each claim you have a certainty of its validity. You have the sum of funds from before the site had the database stolen which is equal to the site's previous balance. This sum must be distributed among claims somehow.

Ideally you would mark claims that you thought were accurate and those that weren't (based on what the data indicates to us). Then you would end up with some total value which you compare to the total funds available.

If less than the total funds, then be more permissive and allow certain more claims in. Repeat the above step.

If more than the total funds, then knock out low certainty claims and maybe redistribute funds among lower certainty claims (better that someone who is maybe legitimate, gets something rather than nothing).

You then end up with claims that are refunded with a best-fit according to the available data.

However people demand funds quickly. So as a compromise, we make 50% payouts initially (for claims we are highly certain are accurate). This allows an error margin so that in the final step we can still juggle balances around to resolve payments for everybody. The only downside is that you cannot decide to pay someone 0% after you've paid them 50%.

Then once people have been refunded for 50% and the final balances are decided, the process goes back over payees and refunds them for the remaining amount. I assume the final step should not take long given that it's just making payments out for known beneficiaries.

Anyways shorts close @ 4.9 longs @ 5.1

Right, here is a VC backed company with Bitcoin developers and "with specialisation in information security" CTO on board who own and operate a service that got hacked. And you think that it is all fault of a 17 yo who they have hired and who was an employee and later got effectively fired.

Good luck convincing any judge or anyone with a modicum of common sense.