zhoutong

Hero Member



Offline



Activity: 490

Merit: 502







VIPHero MemberActivity: 490Merit: 502 A public apology to Donald, Patrick and Amir ("Intersango guys") May 17, 2012, 11:10:39 PM #1



Quote from: zhoutong on May 17, 2012, 08:05:55 AM Quote from: RandyMarsh on May 17, 2012, 07:54:01 AM Thanks in advance to all the wonderful people of this forum, and at the risk of biting the hand that once sort of fed me, Bitcoinica, wtf dudes? at least put up a place holderpage at bitcoinica.com to explain your position, very unprofessional, is this show still being run by a 17 year old? Cause I remember 17, I wasn't a financial wizard, I was in the back of a night club dry humping some girl I barley know.



Nope. I wouldn't handle things like this.

Nope. I wouldn't handle things like this.

Undoubtedly, I felt upset about some confusing commenters. I objectively disagreed with Intersango guys' ways of doing things and I think if Bitcoinica is still under my control, some of our customers' immediate issues can be addressed in a more timely manner.



However, I want to express my sincere apology to the General Partners of Bitcoinica LP, because I should not have criticized them when I should bear part of the responsibility by not doing my best in securing the system. The direct cause of the issue is not important, we shouldn't argue about "if someone didn't do X this thing wouldn't have happened", instead, we should say more about "if I did X this thing could be prevented". In this case, I can express these statements:



- If I have firewalled the wallet server properly (like web production servers), this thing could be prevented.

- If I have spent enough time on the re-implementation of the bitcoin client, this thing could be prevented.

- If I have set up strict access policies, and proactively communicate with Rackspace to disable certain insecure features, this thing could be prevented.



Respect for teammates is extremely crucial to achieve productivity. Everyone's reputation has been damaged badly in this event, and we shouldn't criticize each other due to the differences in the way we work. Even though I have announced that I would leave the Bitcoin economy a few days ago, I'm still actively monitoring our customers' feelings and communicating with the General Partners about the progress.



I am also extremely grateful for the Limited Partner (an investment group) of Bitcoinica LP for exceeding their legal obligation to bear the full cost of both recent attacks. Without their active support, Bitcoinica couldn't have survived until today to serve our customers well.



In the end, I would like to request everyone who cares about the community to be objective about this matter. I am no longer legally associated with Bitcoinica and I had no control over the attacked system. However, other team members are working in their greatest ability to deliver a fair solution to everyone. I have the advantage in understanding our customers (because I'm more familiar everyone using Bitcoinica) so I keep contributing some ideas as well. Please appreciate their hard work and understand the difficulties in resolving a serious security attack. We have already assured you the full compensation.



Thank you everyone for showing your support, understanding and patience.



PS. You can claim your Bitcoinica account at I have violated my promise (of "not to post anything [about Bitcoinica]") yesterday, by posting this in the emergency announcement thread:Undoubtedly, I felt upset about some confusing commenters. I objectively disagreed with Intersango guys' ways of doing things and I think if Bitcoinica is still under my control, some of our customers' immediate issues can be addressed in a more timely manner.However, I want to express my sincere apology to the General Partners of Bitcoinica LP, because I should not have criticized them when I should bear part of the responsibility by not doing my best in securing the system. The direct cause of the issue is not important, we shouldn't argue about "if someone didn't do X this thing wouldn't have happened", instead, we should say more about "if I did X this thing could be prevented". In this case, I can express these statements:- If I have firewalled the wallet server properly (like web production servers), this thing could be prevented.- If I have spent enough time on the re-implementation of the bitcoin client, this thing could be prevented.- If I have set up strict access policies, and proactively communicate with Rackspace to disable certain insecure features, this thing could be prevented.Respect for teammates is extremely crucial to achieve productivity. Everyone's reputation has been damaged badly in this event, and we shouldn't criticize each other due to the differences in the way we work. Even though I have announced that I would leave the Bitcoin economy a few days ago, I'm still actively monitoring our customers' feelings and communicating with the General Partners about the progress.I am also extremely grateful for the Limited Partner (an investment group) of Bitcoinica LP for exceeding their legal obligation to bear the full cost of both recent attacks. Without their active support, Bitcoinica couldn't have survived until today to serve our customers well.In the end, I would like to request everyone who cares about the community to be objective about this matter. I am no longer legally associated with Bitcoinica and I had no control over the attacked system. However, other team members are working in their greatest ability to deliver a fair solution to everyone. I have the advantage in understanding our customers (because I'm more familiar everyone using Bitcoinica) so I keep contributing some ideas as well. Please appreciate their hard work and understand the difficulties in resolving a serious security attack. We have already assured you the full compensation.Thank you everyone for showing your support, understanding and patience.PS. You can claim your Bitcoinica account at https://claims.bitcoinica.com/ now.



Donations for my future Bitcoin projects: 19Uk3tiD5XkBcmHyQYhJxp9QHoub7RosVb Founder of NameTerrific ( https://www.nameterrific.com/ ). Co-founder of CoinJar ( https://coinjar.io/ Donations for my future Bitcoin projects: 19Uk3tiD5XkBcmHyQYhJxp9QHoub7RosVb

AWARD-WINNING

CASINO CRYPTO EXCLUSIVE

CLUBHOUSE 1500+

GAMES 2 MIN

CASH-OUTS 24/7

SUPPORT 100s OF

FREE SPINS PLAY NOW ertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here. Advertsed sites are not endorsed by the Bitcoin Forum. They maye unsafe, untrustworthy, or illegal in youjurisdiction

gmaxwell

Legendary



Offline



Activity: 3192

Merit: 4308









StaffLegendaryActivity: 3192Merit: 4308 Re: A public apology to Donald, Patrick and Amir ("Intersango guys") May 17, 2012, 11:36:17 PM #4 Quote from: zhoutong on May 17, 2012, 11:10:39 PM - If I have spent enough time on the re-implementation of the bitcoin client, this thing could be prevented.



This is the second time you've suggested that the Bitcoin reference code is responsible for your robbery. I inquired about this claim before and I don't believe I got a reply:



I fail to see how any system which has private keys for online realtime 'hot wallet' usage could be defended against an attacker which has root access to the selfsame systems. Even if you used a multisignature wallet and machines inside separate security domains an attacker with that level of access could simply impersonate the web application's legitimate withdraws.



That said if there is some flaw or omission in the reference client which could make high value installations more secure all the developers would love to hear about it.



What I am reasonably confident of is that while you're quite possibly smarter and have more time on your hands than any one of the people developing the publicly available reference software, you're not smarter than all of them combined. ... And a bug that sends 18kBTC into a black hole (as MTGOX's custom code did with a few thousand BTC) is no better than having code stolen.



There are significant advantages in working with a larger user base to test out and harden code before putting it on mission critical systems, and those advantages almost certainly outweigh the many troubles and limitations in the reference client. Moreover, many aspects of Bitcoin security require that you be a part of the majority clique even if the majority is "wrong", if you can be moved onto a minority chain you can be robbed. Because the significant super-majority of the network (users and miners) are using the reference client, its critical that any client be bug for bug compatible with the block rejection rules in the reference client or be at increased risk. So it very much is in your own interest to invest resources in improving the publicly available software than reinventing the wheel.

This is the second time you've suggested that the Bitcoin reference code is responsible for your robbery. I inquired about this claim before and I don't believe I got a reply: https://bitcointalk.org/index.php?topic=81045.msg899922#msg899922 Luke-jr also expressed skepticism: https://bitcointalk.org/index.php?topic=81045.msg899911#msg899911 I fail to see how any system which has private keys for online realtime 'hot wallet' usage could be defended against an attacker which has root access to the selfsame systems. Even if you used a multisignature wallet and machines inside separate security domains an attacker with that level of access could simply impersonate the web application's legitimate withdraws.That said if there is some flaw or omission in the reference client which could make high value installations more secure all the developers would love to hear about it.What I am reasonably confident of is that while you're quite possibly smarter and have more time on your hands than any one of the people developing the publicly available reference software, you're not smarter than all of them combined. ... And a bug that sends 18kBTC into a black hole (as MTGOX's custom code did with a few thousand BTC) is no better than having code stolen.There are significant advantages in working with a larger user base to test out and harden code before putting it on mission critical systems, and those advantages almost certainly outweigh the many troubles and limitations in the reference client. Moreover, many aspects of Bitcoin security require that you be a part of the majority clique even if the majority is "wrong", if you can be moved onto a minority chain you can be robbed. Because the significant super-majority of the network (users and miners) are using the reference client, its critical that any client be bug for bug compatible with the block rejection rules in the reference client or be at increased risk. So it very much is in your own interest to invest resources in improving the publicly available software than reinventing the wheel.

zhoutong

Hero Member



Offline



Activity: 490

Merit: 502







VIPHero MemberActivity: 490Merit: 502 Re: A public apology to Donald, Patrick and Amir ("Intersango guys") May 17, 2012, 11:51:20 PM #6 Quote from: gmaxwell on May 17, 2012, 11:36:17 PM Quote from: zhoutong on May 17, 2012, 11:10:39 PM - If I have spent enough time on the re-implementation of the bitcoin client, this thing could be prevented.



This is the second time you've suggested that the Bitcoin reference code is responsible for your robbery. I inquired about this claim before and I don't believe I got a reply:



I fail to see how any system which has private keys for online realtime 'hot wallet' usage could be defended against an attacker which has root access to the selfsame systems. Even if you used a multisignature wallet and machines inside separate security domains an attacker with that level of access could simply impersonate the web application's legitimate withdraws.



That said if there is some flaw or omission in the reference client which could make high value installations more secure all the developers would love to hear about it.



What I am reasonably confident of is that while you're quite possibly smarter and have more time on your hands than any one of the people developing the publicly available reference software, you're not smarter than all of them combined. ... And a bug that sends 18kBTC into a black hole (as MTGOX's custom code did with a few thousand BTC) is no better than having code stolen.



There are significant advantages in working with a larger user base to test out and harden code before putting it on mission critical systems, and those advantages almost certainly outweigh the many troubles and limitations in the reference client. Moreover, many aspects of Bitcoin security require that you be a part of the majority clique even if the majority is "wrong", if you can be moved onto a minority chain you can be robbed. Because the significant super-majority of the network (users and miners) are using the reference client, its critical that any client be bug for bug compatible with the block rejection rules in the reference client or be at increased risk. So it very much is in your own interest to invest resources in improving the publicly available software than reinventing the wheel.



This is the second time you've suggested that the Bitcoin reference code is responsible for your robbery. I inquired about this claim before and I don't believe I got a reply: https://bitcointalk.org/index.php?topic=81045.msg899922#msg899922 Luke-jr also expressed skepticism: https://bitcointalk.org/index.php?topic=81045.msg899911#msg899911 I fail to see how any system which has private keys for online realtime 'hot wallet' usage could be defended against an attacker which has root access to the selfsame systems. Even if you used a multisignature wallet and machines inside separate security domains an attacker with that level of access could simply impersonate the web application's legitimate withdraws.That said if there is some flaw or omission in the reference client which could make high value installations more secure all the developers would love to hear about it.What I am reasonably confident of is that while you're quite possibly smarter and have more time on your hands than any one of the people developing the publicly available reference software, you're not smarter than all of them combined. ... And a bug that sends 18kBTC into a black hole (as MTGOX's custom code did with a few thousand BTC) is no better than having code stolen.There are significant advantages in working with a larger user base to test out and harden code before putting it on mission critical systems, and those advantages almost certainly outweigh the many troubles and limitations in the reference client. Moreover, many aspects of Bitcoin security require that you be a part of the majority clique even if the majority is "wrong", if you can be moved onto a minority chain you can be robbed. Because the significant super-majority of the network (users and miners) are using the reference client, its critical that any client be bug for bug compatible with the block rejection rules in the reference client or be at increased risk. So it very much is in your own interest to invest resources in improving the publicly available software than reinventing the wheel.

Thanks for the idea.



This is what I wanted to do:



- Drop the Bitcoin official client and re-implement one.

- Store private keys in the database, AES encrypted with a master key (that is associated with the user).

- Store master key in the database, AES encrypted with another hash of the user password (such as the SHA512 hash in place of the BCrypt hash).



This will be effectively a segregated account for the user. Of course we need to solve some problems (like forget password and forced settlements) but this is the general idea.



I'm a web developer so I feel much more comfortable securing the database rather than the wallet.dat. I never trust direct filesystem operations. Thanks for the idea.This is what I wanted to do:- Drop the Bitcoin official client and re-implement one.- Store private keys in the database, AES encrypted with a master key (that is associated with the user).- Store master key in the database, AES encrypted with another hash of the user password (such as the SHA512 hash in place of the BCrypt hash).This will be effectively a segregated account for the user. Of course we need to solve some problems (like forget password and forced settlements) but this is the general idea.I'm a web developer so I feel much more comfortable securing the database rather than the wallet.dat. I never trust direct filesystem operations.



Donations for my future Bitcoin projects: 19Uk3tiD5XkBcmHyQYhJxp9QHoub7RosVb Founder of NameTerrific ( https://www.nameterrific.com/ ). Co-founder of CoinJar ( https://coinjar.io/ Donations for my future Bitcoin projects: 19Uk3tiD5XkBcmHyQYhJxp9QHoub7RosVb