Bitcoin Forum
December 09, 2016, 05:55:10 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
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 ... 82 »
  Print  
Author Topic: [Payout Updates] Bitcoinica site is taken offline for security investigation  (Read 145809 times)
genjix
Legendary
*
Offline Offline

Activity: 1232


View Profile
May 28, 2012, 06:04:52 AM
 #1

I will post information here as I receive it.

28 May 07:00: Discussion right now is centered on the nature of selecting payess. There is the question of what nature the system for choosing payees should take with different people favouring 1 of 2 approaches (one is fast and unreliable, the other slow and reliable). I can't say more than that for technical reasons. Everyone wants to pay everyone back, but have a differing opinion how it will work.

30 May 01:52: Consensus seems to have been reached. Waiting for final confirmation to move ahead so we can work out the actual payout implementation specifics.

30 May 23:30: We're going to proceed with payouts of the few people we have verified hopefully tomorrow for 80% of their claims (the remaining 20% will be refunded later). A more lengthy process will be applied to everyone else.

3 June 23:20: We're adding extra fields to the claims database (should be finished soon), we have received the funds from Tihan to make the initial payouts. Then once that's done, the first round of payments can be finished.

13 June 15:00: Initial payouts have been made to verified people for 50% of their claim.

Transisto is maintaining a helpful thread detailing all Bitcoinica posts and notable posts: https://bitcointalk.org/index.php?topic=89782.0

Claims can be made via: https://claims.bitcoinica.com/
For enquiries email: bitcoinica.reimburse@gmail.com
1481262910
Hero Member
*
Offline Offline

Posts: 1481262910

View Profile Personal Message (Offline)

Ignore
1481262910
Reply with quote  #2

1481262910
Report to moderator
1481262910
Hero Member
*
Offline Offline

Posts: 1481262910

View Profile Personal Message (Offline)

Ignore
1481262910
Reply with quote  #2

1481262910
Report to moderator
1481262910
Hero Member
*
Offline Offline

Posts: 1481262910

View Profile Personal Message (Offline)

Ignore
1481262910
Reply with quote  #2

1481262910
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481262910
Hero Member
*
Offline Offline

Posts: 1481262910

View Profile Personal Message (Offline)

Ignore
1481262910
Reply with quote  #2

1481262910
Report to moderator
genjix
Legendary
*
Offline Offline

Activity: 1232


View Profile
May 28, 2012, 06:06:08 AM
 #2

Historic posts detailing progress:

https://bitcointalk.org/index.php?topic=81045.0
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.

https://bitcointalk.org/index.php?topic=81045.msg921159#msg921159
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.

To the person above, here's what happened:
- Bitcoinica has an internet mailing list called info@bitcoinica.com
- It was the email for the website and all sensitive accounts.
- You could request a password for that email. In a production system, that should never be possible.
- Several people had access to this mailing list (non-admins and business people included).
- Patrick got added.
- His personal email was compromised. Normally this shouldn't be a big deal; I use my personal email at internet cafes and public computers.
- Attacker was able to request a new password and login to rackspace.

The assumption here was that info@bitcoinica.com did not have access to critical infrastructure.

Lastly, it was my fault Patrick's email server got compromised. I had a VPS for programming and development which many people had access to - randoms from #c++ IRC, people from this forum, beginners I was teaching .etc It's a public VPS for development. The SSH key on there was added to Patrick's server because we were developing the bitcoinconsultancy.com website on there (that's why it's now down). My SSH key was stolen and he ssh'ed into the box. Then had access to his emails.

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.

Close all bets, give us our money back.

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.

Any news on when people that are marked as "accurate" get (part of) their funds? You said some people already received 50% of their funds. How was it decided that they could get a payment, while other people with an account marked as "accurate" received nothing so far?

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

Transisto is maintaining a helpful thread detailing all Bitcoinica posts and notable posts: https://bitcointalk.org/index.php?topic=89782.0
Vladimir
Hero Member
*****
Offline Offline

Activity: 812


-


View Profile
May 28, 2012, 06:09:11 AM
 #3

I will post information here as I receive it.

28 May 07:00: Discussion right now is centered on the nature of payouts. There is the question of what nature the payout system should take with different people favouring 1 of 2 approaches (one is fast and unreliable, the other slow and reliable). I can't say more than that for technical reasons. Everyone wants to pay everyone back, but have a differing opinion how it will work.

Slow method i.e. mailing cheques or certified cheques could just work, just let users to chose among 3 major currencies (USD, GBP, EUR) you likely have all the bank accounts for that, convert at cost. Just a suggestion.




-
M4v3R
Hero Member
*****
Offline Offline

Activity: 607



View Profile
May 28, 2012, 06:15:32 AM
 #4

That's not an option for me. I live in Poland and realizing cheques would be MUCH pain to me. I once tried to do this with Google Adsense cheque, before they started to sending international wires. It took TWO freakin' months to complete. Not everyone's live in the US you know. MtGox reedem codes for USDs and Bitcoin transfers for BTCs please.
genjix
Legendary
*
Offline Offline

Activity: 1232


View Profile
May 28, 2012, 06:21:01 AM
 #5

I was deliberately vague. It isn't which payment system to use, but which method of selecting payees (people to be paid) to ensure accurate or fast delivery (it is a bit of a sliding scale). Maybe I can post more specifics, but I want to ask first in case I somehow jeopardise the prospect of a speedy recovery for everyone. Also I'd want to make sure what I write is correct.
proudhon
Legendary
*
Offline Offline

Activity: 1148



View Profile
May 28, 2012, 06:24:48 AM
 #6

I will post information here as I receive it.

28 May 07:00: Discussion right now is centered on the nature of selecting payess. There is the question of what nature the system for choosing payees should take with different people favouring 1 of 2 approaches (one is fast and unreliable, the other slow and reliable). I can't say more than that for technical reasons. Everyone wants to pay everyone back, but have a differing opinion how it will work.

I think you should favor higher reliability.  If that means that the process will be slower, so be it.
chunglam
Donator
Full Member
*
Offline Offline

Activity: 221



View Profile
May 28, 2012, 06:29:06 AM
 #7

I will post information here as I receive it.

28 May 07:00: Discussion right now is centered on the nature of selecting payess. There is the question of what nature the system for choosing payees should take with different people favouring 1 of 2 approaches (one is fast and unreliable, the other slow and reliable). I can't say more than that for technical reasons. Everyone wants to pay everyone back, but have a differing opinion how it will work.

I think you should favor higher reliability.  If that means that the process will be slower, so be it.

+1, accuracy should be top priority and be fair to everyone.
ThePok
Full Member
***
Offline Offline

Activity: 137


View Profile
May 28, 2012, 06:54:38 AM
 #8

And pay the big fishes with a lot of Bitcoins and Dollars first  Smiley (Iam not one of tham  Embarrassed  )
S3052
Legendary
*
Offline Offline

Activity: 1946


BTC Up or Down? go to www.bullbearanalytics.com


View Profile WWW
May 28, 2012, 07:03:49 AM
 #9

And pay the big fishes with a lot of Bitcoins and Dollars first  Smiley (Iam not one of tham  Embarrassed  )

+1

>15years analysis experience

Always do your own due diligence & consult your financial advisor. Never invest unless you can afford to lose your entire investment.

http://twitter.com/BitcoinAnalyst

Subscribe here
XVacant
Newbie
*
Offline Offline

Activity: 23



View Profile
May 28, 2012, 07:09:08 AM
 #10

I will post information here as I receive it.

28 May 07:00: Discussion right now is centered on the nature of selecting payess. There is the question of what nature the system for choosing payees should take with different people favouring 1 of 2 approaches (one is fast and unreliable, the other slow and reliable). I can't say more than that for technical reasons. Everyone wants to pay everyone back, but have a differing opinion how it will work.

How unreliable and how slow are these 2 approaches? Please give us a estimation.
I'd hope the slow approach won't take too loooooooooong time.
naima53
Hero Member
*****
Offline Offline

Activity: 616



View Profile
May 28, 2012, 07:21:07 AM
 #11

That's not an option for me. I live in Poland and realizing cheques would be MUCH pain to me. I once tried to do this with Google Adsense cheque, before they started to sending international wires. It took TWO freakin' months to complete. Not everyone's live in the US you know. MtGox reedem codes for USDs and Bitcoin transfers for BTCs please.
+1
a rapid method for those who have the email-notification (number of the transaction, the date, time, how much), slow - for those who have not. Please MtGox-code (became the de facto standard for USD) and transaction Bitcoin for Bitcoin.

Donate me) 16f6iWHHkVEnDReeBQPT9GwCNwUfPTXrp2
XVacant
Newbie
*
Offline Offline

Activity: 23



View Profile
May 28, 2012, 07:54:56 AM
 #12

That's not an option for me. I live in Poland and realizing cheques would be MUCH pain to me. I once tried to do this with Google Adsense cheque, before they started to sending international wires. It took TWO freakin' months to complete. Not everyone's live in the US you know. MtGox reedem codes for USDs and Bitcoin transfers for BTCs please.
+1
a rapid method for those who have the email-notification (number of the transaction, the date, time, how much), slow - for those who have not. Please MtGox-code (became the de facto standard for USD) and transaction Bitcoin for Bitcoin.

+1
MtGox-code for BTC is fine too.
ninjarobot
Hero Member
*****
Offline Offline

Activity: 755


Mine Silent, Mine Deep


View Profile
May 28, 2012, 08:38:50 AM
 #13

When dealing with money, please favor accuracy over speed.

Zhou mentioned funds were highly concentrated, so work your way down from the fat part to the long part of the long tail. This way you are less likely to get sued (assuming those people with large accounts are more likely to mount legal action against Bitcoinica LP).

Most important: Keep your customers informed. This thread is a good start.
tritium
Member
**
Offline Offline

Activity: 86


View Profile
May 28, 2012, 08:56:24 AM
 #14

it depends on how unreliable the quick payments are, personally i would prefer the more reliable approach but hope it wouldn't take too long

also can we choose what method of payment we want, some might prefer cheques some might like wires, some mtgox codes etc. I would like it to be paid into my intersango acc if possible

1FCzN34C1xCLsDaLxfY7yB5CQKN74ruGHV
kokjo
Legendary
*
Offline Offline

Activity: 1050

You are WRONG!


View Profile
May 28, 2012, 09:02:57 AM
 #15

sup

"The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell
faidsaid
Jr. Member
*
Offline Offline

Activity: 43


View Profile
May 28, 2012, 09:27:12 AM
 #16

bus

“There are two novels that can change a bookish fourteen-year old's life: The Lord of the Rings and Atlas Shrugged. One is a childish fantasy that often engenders a lifelong obsession with its unbelievable heroes, leading to an emotionally stunted, socially crippled adulthood, unable to deal with the real world. The other, of course, involves orcs.”
― John Rogers
waspoza
Hero Member
*****
Offline Offline

Activity: 602


Firstbits: 1waspoza


View Profile
May 28, 2012, 09:30:41 AM
 #17

plane
realnowhereman
Hero Member
*****
Offline Offline

Activity: 504



View Profile
May 28, 2012, 09:53:24 AM
 #18

Surely it's possible to order or group the claims in order of uncertainty?

Surely also, an email out to the customers who've made a claim asking for additional evidence where there is still uncertainty?

It's difficult to offer suggestions without knowing what was in the database that the hacker has access to, and hence can't be trusted.  Two things spring to mind: (a) MTGOX deposit/withdrawal codes (b) MTGOX deposit withdrawal reference numbers.  If either of those wasn't stored in the Bitcoinica database, then they can be trivially used to verify identity and probably trivially used to verify deposits.  Bitcoinica will have access to their own Mt.Gox account history, as will the rest of us.  That can be used to get information only known to two legitimate parties: the account owner and Bitcoinica (via their Mt.Gox account).

Isn't that quick and reliable?  Quick and reliable aren't necessarily exclusive.

1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
WhatsHappening
Newbie
*
Offline Offline

Activity: 23


View Profile
May 28, 2012, 10:26:48 AM
 #19

That's not an option for me. I live in Poland and realizing cheques would be MUCH pain to me. I once tried to do this with Google Adsense cheque, before they started to sending international wires. It took TWO freakin' months to complete. Not everyone's live in the US you know. MtGox reedem codes for USDs and Bitcoin transfers for BTCs please.

+1.

IMHO returning funds should be realized ONLY through mtgox codes. I'm very confident that we need a trusted third party (as an intermediary)  in this process.
deego
Donator
Sr. Member
*
Offline Offline

Activity: 317


1MCoX64q6ks2Fvx8wybGYonfvEoTPpMhhR


View Profile WWW
May 28, 2012, 12:34:59 PM
 #20

watching

1MCoX64q6ks2Fvx8wybGYonfvEoTPpMhhR
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 ... 82 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!