Try asking gox if they lend you the 200,000 BTC to do that. On Fri, Mar 21, 2014 at 7:50 PM, Kelly John Rose <iam@kjro.se> wrote:

On Thu, Mar 20, 2014 at 11:25 PM, jim bell <jamesdbell9@yahoo.com> wrote:

...

http://www.engadget.com/2014/03/20/mt-gox-apparently-found-200-000-bitcoin-i...

"In a bit of news that's familiar to anyone who ever put on an old jacket and found $20 in the pocket, embattled Bitcoin exchange Mt. Gox has made a fortuitous discovery. The company announced (PDF)<https://www.mtgox.com/img/pdf/20140320-btc-announce.pdf> in Japan that it found 200,000 Bitcoin (worth nearly $116 million at the moment) in a wallet from 2011 that it no longer used. That's less than a quarter of the 850,000 Bitcoins CEO Mark Karpeles reported were missing, but at the moment, at least it's something. According to its statement, the coins were moved to online wallets on the 7th, and then to offline wallets on the 14th and 15th. The mystery of what happened to Mt. Gox's funds<http://www.engadget.com/2014/03/11/mt-gox-us-assets-frozen/> is still far from solved, but between this news and reports of updated balances for account holders<http://www.engadget.com/2014/03/17/mt-gox-login-page-returns/>, it seems possible that there's something to be recovered from the shuttered exchange. Next up, removing all of the cushions from the sofa and pulling it away from the wall."

If that doesn't inspire confidence in you, I don't know what will!

Honestly, I really wonder what would happen if some developers who understand financial cryptography and how banks properly work built a real bitcoin exchange. Considering how well it has done with incompetents like this, I'm betting a properly programmed and vetted system may be quite successful.

Too bad I don't have 200,000 BTC to do just that.

-- Kelly John Rose Twitter: @kjrose Skype: kjrose.pr Gtalk: iam@kjro.se MSN: msn@kjro.se

Document contents are confidential between original recipients and sender.

Try asking gox if they lend you the 200,000 BTC to do that.

If serious, ask the Winklevoss Twins. --dan

You're doing it wrong if you don't make your pitch as a series of blocks added to the blockchain. On 21/03/14 22:53, Kelly John Rose wrote:

Does anyone have their contact info?

On Fri, Mar 21, 2014 at 3:39 PM, <dan@geer.org> wrote:

...

...

Try asking gox if they lend you the 200,000 BTC to do that.

If serious, ask the Winklevoss Twins.

--dan

-- T: @onetruecathal, @IndieBBDNA P: +3538763663185 W: http://indiebiotech.com

On Fri, Mar 21, 2014 at 8:59 AM, rysiek <rysiek@hackerspace.pl> wrote:

Dnia piątek, 21 marca 2014 08:20:02 Kelly John Rose pisze:

...

On Thu, Mar 20, 2014 at 11:25 PM, jim bell <jamesdbell9@yahoo.com> wrote:

...

http://www.engadget.com/2014/03/20/mt-gox-apparently-found-200-000-bitcoin

...

-in-an-old-wallet-shoul/?ncid=txtlnkusaolp00000589

"In a bit of news that's familiar to anyone who ever put on an old jacket and found $20 in the pocket, embattled Bitcoin exchange Mt. Gox has made a fortuitous discovery. The company announced (PDF)<https://www.mtgox.com/img/pdf/20140320-btc-announce.pdf> in Japan that it found 200,000 Bitcoin (worth nearly $116 million at the moment) in a wallet from 2011 that it no longer used. That's less than a quarter of the 850,000 Bitcoins CEO Mark Karpeles reported were missing, but at the moment, at least it's something. According to its statement, the coins were moved to online wallets on the 7th, and then to offline wallets on the 14th and 15th. The mystery of what happened to Mt. Gox's funds<http://www.engadget.com/2014/03/11/mt-gox-us-assets-frozen/> is still far from solved, but between this news and reports of updated balances for account holders<http://www.engadget.com/2014/03/17/mt-gox-login-page-returns/ , it seems possible that there's something to be recovered from the shuttered exchange. Next up, removing all of the cushions from the sofa and pulling it away from the wall."

If that doesn't inspire confidence in you, I don't know what will!

Honestly, I really wonder what would happen if some developers who understand financial cryptography and how banks properly work built a real bitcoin exchange. Considering how well it has done with incompetents like this, I'm betting a properly programmed and vetted system may be quite successful.

I'm betting the exactly other way. "First to the market" and some snakeoil usually, unfortunately, win by leaps and bounds with "well-designed and properly implemented".

-- Pozdr rysiek

Snakeoil will be good at sucking money out of suckers with more dollars than sense. Bitcoin, or some other cryptocurrency, really does have potential as a way to grease the gears of international finance or micropayments, but not really as a complete currency replacement in my opinion. The problem here is that there is no legitimate or reasonable way to buy into the market without going through these snakeoil-like dealers. -- Kelly John Rose Twitter: @kjrose Skype: kjrose.pr Gtalk: iam@kjro.se MSN: msn@kjro.se Document contents are confidential between original recipients and sender.

Message du 22/03/14 17:28 De : "Troy Benjegerdes" If you think you need 'money' to write a better exchange, then you are just another crypto-snake-oil salesman, and are WORSE than Gox, who at least gave us a good example of failure.

However, if you want to put your code (and failures) where your mouth is, I'll give you free room and board if you show me good code, and an honest effort to learn from failure. Nowhere in this exchange is money involved.

Most of the guys willing to create a new exchange are figuring they need to pay a team of professional C programmers if they want their system working without hacks, because lately 90% of coders barely get through with Python, lol.

On Sat, Mar 22, 2014 at 4:15 PM, Kelly John Rose <iam@kjro.se> wrote:

Financial cryptography is expensive to do mostly because ... make sure the engineering is done correctly the first time

If you're going to jump straight in to the real world of real money, yes. But you can take baby steps, running a service with limited clients and limited amounts, or with play money. Wasn't that part of the appeal of MtGox, that it had been running as an exchange for years, before getting into the BitCoin world? I think the assumption was that they seemed to know what they were doing, so it was safe enough to use them for trading BTC and "real" money. (Note that I never had anything to do with MtGox, or indeed with BitCoin. This was not so much a matter of crypto paranoia as a matter of mortgage, three kids, and a wife who won't stop spending.) -- Neca eos omnes. Deus suos agnoscet. -- Arnaud-Amaury, 1209

Kelly John Rose <iam@kjro.se> writes:

Having worked on some complex banking and accounting systems before, I know there is a lot more to the equation than simple coding up some crappy ruby code and putting fixes in place whenever it doesn't quite do what you want.

Financial cryptography is expensive to do mostly because there is a strong need to not only implement good code, but also make sure the engineering is done correctly the first time and that it has the expensive physical security to back it up.

Absolutely. Some time ago I had a long chat with someone who worked on large- scale financial processing systems. Among other things his organisation tends to act as a stress test for any hardware or software they use since they push it beyond what anyone else ever manages (and no, it's not HFT, just standard banking clearing). Their prime directive is that financial value can never be created or destroyed, so you can never have a situation in which a failure anywhere will result in one blob of financial value being recorded in two locations, or no locations. Saying that you'll address this by rolling back transactions won't fly both because no standard database can handle the load they work at, and because the financial world isn't going to stop and wait while you perform a rollback. To give some examples of what this entails, they only use the outer sets of tracks on their disk arrays to maximise data throughput/minimise head movement, if they were to use the entire platter the system couldn't keep up. Cacheing doesn't help, they did try it with the most exotic cacheing technology that EMC could provide them and found that after X hours throughput dropped to a fraction of what it had been. Although EMC had simulated this situation they never expected that anyone would be able to do it in real life. They also managed to figure out the computing power of a USG agency using a certain type of architecture because, when they wanted to buy the entire production run of a particular just-introduced CPU for several months they found that an unnamed US customer had already bought six months worth of production ahead of them. I think this is about as far from hacking together "some crappy ruby code" as you can get while still remaining on the same planet. Peter.

So how do they do that? If there's power failure on a specific box...

There is transactional integrity where you're good until the failure, then you halt and fix/failover/etc. It's relatively cheap and popular.

I can imagine mitigating this by redundantly processing everything

Then there are things called non-stop-computing where the whole system is transactioned. Some of that happens in systems like these. How close these things get to being bulletproof I've not looked into. https://en.wikipedia.org/wiki/IBM_System_z Also Sun, HP, Fujitsu and the like. Look into what NASDAQ runs...

=?UTF-8?Q?Lodewijk_andr=C3=A9_de_la_porte?= <l@odewijk.nl> writes:

So how do they do that? If there's power failure on a specific box, what happens? Are all transactions synced to disk before commit, thus minimal rollbacks? A minimal rollback takes a very small margin of what would happen in case of power failure on a box. Maybe they have several boxes advocating a single transaction, so that expectible failures would never crash a system completely.

This was a software guy (quoting what he knew about some of the special hardware features), so he didn't go into that much detail on this sort of thing, but in any case it's problem that's been (mostly) solved for decades, just look for discussions of high-availability systems (https://archive.org/details/reliablecomputer00siew is one good starting point). It's not for nothing that, for example, Tandems are sold under the name NonStop (they're covered in a case study in the book referenced above). I was in a Tandem shop some years ago when it experienced a rapid sequence of power glitches. The mass of IT gear in the building needed everything from a reboot to a reinstall to hardware replacement to get working again. One of their techies took me into the mainframe room to the Tandem console, which had a series of reports "Power lost / Power restored / Power lost / ...". Apart from that there had been no effect. There's a story that during the Loma Prieta earthquake a data centre containing a Tandem machine was damaged in the quake. It continued running, lying on its side surrounded by debris, until they could bring in heavy equipment to push it upright again. Peter.

Message du 23/03/14 02:46 De : "Lodewijk andré de la porte" A : "Troy Benjegerdes" Copie à : "cypherpunks@cpunks.org" Objet : Re: "Whew, wondered where we'd put those 200,000 BTC!"

2014-03-22 16:55 GMT+01:00 Troy Benjegerdes :

...

If you think MtGox is incompetent, then show me the fucking code of a better exchange, or shut the fuck up. If you think you need 'money' to build such a thing, then you have even less of a grasp on the human factors than the banks do on cryptographic secrets.

The sad part is that I got scared away from the exchange business because I thought it would be nearly impossible to get it 100% secure. And if it were less then 100% secure, how could I take people's money?

I spent days feeling sick because I couldn't figure out a way to do exchanges distributed over sufficiently geographically disperse points to avoid trouble with a single government going mad. Then I realized the Megaupload situation means that any US-ally country is susceptible to a planned US-exercise.

Once I found that I cannot trust maybe 150 countries in the world with the rest being mostly unsuitable, that turned into a bit of a problem. Suddenly you find yourself thinking about how to get servers up in Iran, Irak, India?, Morocco?, Laos?, Vietnam?, Cuba, Russia, China, North Korea (scratch that) and maybe Iceland and some micronations.

You're thinking you can't trust others to set up the server, and you don't want the costs, exposure and actual unsafety that comes with visiting all America's enemies so you'll end up shipping wholesome servers to be loaded straight into a rack.

Then you realize you're still not physically secure. The server itself is a hotbox of 100% exposure. It's exceedingly unusual to want a physically dispersed leaderless secure computing cluster with hot failover of a large portion of servers (>49% is impossible, can't determine if you're being fucked in the BGP).

If you let the box call homes first (homes is the list of other servers) it can use it's already present crypto to prevent any possible MITM or listening in. So that's good. Problem is a little liquid nitrogen, connection on a bus or firewire port, etc. is enough to make the server bleed information faster than the Titanic ate water. So you have to cut the firefire connections (USB is okay and convenient AFAIC) and heat-conductive epoxy the motherboard, RAM and a good margin around the CPU too (use a taller and wider cooler than usual). Maybe even run some wires through it to measure breach.

I have some additional ideas that are better obscure than open, but you get the level of obnoxious. It's still not secure yet though, and that bothers me a lot.

Then you find out Intel's chips have all sorts of hyperintelligence on it to allow "remote administration" which just blew my fucking mind halfway across the galaxy. "Dear NSA, have a backdoor into any PC that has a NIC. Thank you for making us the industry leader, Kind regards\nX\nIntel". So I'm thinking you'll probably want the beefiest ARM processor or maybe even AMD (have to do more research). Of course a wiretap could expose the magic packets, to prevent the NSA from being able to launder the exploit as some more simple hack that doesn't point the finger at them. And then their ability here couldn't be used because they want to reserve it for, you know, WW3 time (hey China).

Once you have your physical platform you have to make sure the software is okay. I found that it's entirely impossible to not trust your compiler. And the likelihood of cutting yourself is way too high with low level languages. I've so far permitted myself to use Node.js, and I feel plenty bad about that. You can not trust your SSL unit. You can not trust any library or database software. But you have to, because you can't do better. (I did go for OpenBSD, although many things required hand compilation which I wasn't familiar with )

By now I'm a week further in worrying and researching, I'm sweating more at night, I don't feel comfortable using my own computer anymore, I don't understand why the world isn't a chaotic place where no computer ever is not hacked out of it's guts. I realize it's probably because nobody is motivated and smart enough to go through the effort, and then also doesn't get caught except for those that'd pay a high price to hide their capabilities, which is why you'd never notice.

Knowing all this I quite damn well decided I couldn't make a secure and reliable centralized exchange. No distributed exchange would earn me a profit, which I'd need to produce more software to help other people's life better, so that wouldn't really help either. Aside from the fact that it would not be popular because it'd be slower and less easy than a "central" exchange.

Overall I decided I respect greatly the people that take on this challenge. This was over a year ago.

Looking at the hacks that happen I'm mostly shocked to find the level of stupidity. Shocked as much to see how long things just go on without significant trouble. MtGox failing because money dissapeared over the years... That was shocking at an unbelievable level. The first thing would be a BIG CLOCK in the office, showing total supposed amount of Bitcoin according to the servers and the total amount supposedly in wallets according to the Blockchain. If not that than at least an alarm on a dedicated phone, e-mails and a message on the admin interface (if you have one). Somehow they had none of those. I'm amazed. This is just an aspect. They run Ubuntu (thick stack linux) and PHP (thick stack webserver), which are illogical choices. The list goes on.

So I think I'm capable of making an exchange platform that's far better than what's out there right now. And I will once I have time (I really don't have it right now, life is such a fuzz).

I still question if it'd be used by anyone. But at least I can try.

I can't answer to all your concerns separately as it seems you have got one very big problem: you are into computers, but you have trouble compiling - merely compiling - programs for OpenBSD. You are in the same boat of Karpeles and Ulbricht, they also were barely able to code some interpreted language and they were overwhelmed by the intricacies of the systems they were building. Until they finally brought disaster for themselves and everyone that depended on them. In order to grasp the seriousness of things, you gotta start with something simpler which doesn't require so many security skills, like games. Then you build up your knowledge until one day you can make your own exchange. But until that point, it is irresponsible to try as you have well noticed. Regarding the rest of your concerns, everything can be dealt with properly, but it takes years of learning. There's a reason computer security professionals are amongst the most well paid employees which big corporations and rich governments only can hire.

Message du 23/03/14 03:56 De : "Lodewijk andré de la porte" A : tpb-crypto@laposte.net Copie à : "Troy Benjegerdes" , "cypherpunks@cpunks.org" Objet : Re: "Whew, wondered where we'd put those 200,000 BTC!"

2014-03-23 3:14 GMT+01:00 :

...

I can't answer to all your concerns separately as it seems you have got one very big problem: you are into computers, but you have trouble compiling - merely compiling - programs for OpenBSD.

Given the amount of unix knowledge involved I don't think that judges me at all. Maybe you judge me for my lack of unix skills, which I would easily admit are lacking.

...

You are in the same boat of Karpeles and Ulbricht, they also were barely able to code some interpreted language and they were overwhelmed by the intricacies of the systems they were building. Until they finally brought disaster for themselves and everyone that depended on them.

I don't feel comfortable being put at the advanced PHP magic level. I doubt it's fair to my skill. Ulbricht actually did pretty well. Bringing disaster is also avoidable on many different levels.

...

In order to grasp the seriousness of things, you gotta start with something simpler which doesn't require so many security skills, like games. Then you build up your knowledge until one day you can make your own exchange.

Making games will not help you learn security at all. It might make you learn coding fast and dirty. They're totally different styles.

...

But until that point, it is irresponsible to try as you have well noticed.

Do or do not. There is no try.

...

Regarding the rest of your concerns, everything can be dealt with properly, but it takes years of learning. There's a reason computer security professionals are amongst the most well paid employees which big corporations and rich governments only can hire.

It's most likely the lack of appeal of a security job. It takes more than learning actually, it takes inventing.

Many people think that if Facebook and Wikipedia use PHP, then PHP may be secure enough to work with money. Meanwhile raw money provides a much bigger bounty than hacking Facebook or Wikipedia, which probably have security holes in numbers that are orders of magnitude more than any small Bitcoin exchange. That's why properly coded C and Cobol are used by most financial institutions, yes Cobol, as incredible is it may seem, it powers most financial transactions behind fancy web browsers. Because even if a banking system is simpler than a Wikipedia, its security will be tried many, many, many more times than Wikipedia. While a hack into Wikipedia is something to be concerned about, it won't destroy it, while taking all the money away will destroy a business. When I referred to games, I was referring to simpler and non-serious systems that people will try to hack in for fun. If you build such system, any system, that's training for some serious stuff in the future. Ulbricht only knew some PHP coding and looked for help in order to create more advanced stuff, worse yet he had his servers discovered and mirrored and probably exploited before he would even notice it. How can one be so low in their opsec that he doesn't ship a server for colocation with its USB ports desoldered and plied away? Or at least disabled in the firmware? All your concerns are valid, meanwhile think about how you could work around every single one of them and note them down. Then once in a while you review your list, until you have solved most theoretical issues. Then you build a non-serious system and offer bounties for finding exploits and people will find them, because you will never manage to plug all holes and the invader has just to find one hole open.

It were write that:

You are in the same boat of Karpeles and Ulbricht, they also were barely able to code some interpreted language and they were overwhelmed by the intricacies of the systems they were building. Until they finally brought disaster for themselves and everyone that depended on them.

True but inevitable. Humans can design systems more complex than they can then operate. The financial sector's "flash crashes" are one, but only one, public proof-by-demonstration of that fact. I predict that the fifty interlocked insurance exchanges for Obamacare will be another. It is likely that any cryptocurrency exchange that is center-free and self-mobile is harder still. The HTTP Archive says that the average web page now makes out-references to 16 different domains as well as making 17 Javascript requests per page, and the Javascript byte count is five times the HTML byte count. Above some threshold of system complexity, it is no longer possible to test, it is only possible to react to emergent behavior. Even the lowliest Internet user is involved -- on the top level page for a major news site, I found 400 out-references to 85 unique domains each of which is similarly constructed. If you leave those pages up, then because most such pages have an auto-refresh, moving your ass to a new subnet signals to every single advertising network that you have done so. --dan

...

It were write that:

...

You are in the same boat of Karpeles and Ulbricht, they also were barely able to code some interpreted language and they were overwhelmed by the intricacies of the systems they were building. Until they finally brought disaster for themselves and everyone that depended on them.

True but inevitable. Humans can design systems more complex than they can then operate. The financial sector's "flash crashes" are one, but only one, public proof-by-demonstration of that fact. I predict that the fifty interlocked insurance exchanges for Obamacare will be another. It is likely that any cryptocurrency exchange that is center-free and self-mobile is harder still. The HTTP Archive says that the average web page now makes out-references to 16 different domains as well as making 17 Javascript requests per page, and the Javascript byte count is five times the HTML byte count.

Above some threshold of system complexity, it is no longer possible to test, it is only possible to react to emergent behavior. Even the lowliest Internet user is involved -- on the top level page for a major news site, I found 400 out-references to 85 unique domains each of which is similarly constructed. If you leave those pages up, then because most such pages have an auto-refresh, moving your ass to a new subnet signals to every single advertising network that you have done so.

--dan

Your comments naturally lead us to think how to make simple systems, yet functional enough for the purpose we are building them.

We are up to a revival in self-made purpose-specific web servers. Learning the few needed protocols and building from the ground up using open-source tools seems the way to go.

Notwithstanding hardware issues, using things out of intel and amd seems also to become a trend.

If you focus on user-experience, simplicity, and minimal dependencies you might end up writing an exchange in python and running it on this: http://micropython.org/ , and then getting an insurance company to underwrite customers for any loss, including hacks. Next step is make it run on a cpu you can audit the VHDL for... http://yasep.org/ -- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash

If you focus on user-experience, simplicity, and minimal dependencies you might end up writing an exchange in python and running it on this: http://micropython.org/ , and then getting an insurance company to underwrite customers for any loss, including hacks.

Next step is make it run on a cpu you can audit the VHDL for... http://yasep.org/

I appreciate your ideas, how much would they scale? Can one squeeze 300 customers per unit and link many parallel units?

Message du 24/03/14 16:38 De : "Lodewijk andré de la porte" A : tpb-crypto@laposte.net Copie à : "Troy Benjegerdes" , "cypherpunks@cpunks.org" Objet : Re: "Whew, wondered where we'd put those 200,000 BTC!"

2014-03-24 16:22 GMT+01:00 :

...

I appreciate your ideas, how much would they scale? Can one squeeze 300 customers per unit and link many parallel units?

I've yet to see a multiprocessor trade matching engine.

Seems like the only way to know, is to try. But if you don't program C already, building a processor using VHDL and another chip to interpret Python, then fitting them together with some USB and ethernet ports seems to be quite a daunting task. The money would pay out, but the starting capital is in the thousands of programming hours specifically for embedded systems.

On Mon, Mar 24, 2014 at 04:38:37PM +0100, Lodewijk andré de la porte wrote:

2014-03-24 16:22 GMT+01:00 <tpb-crypto@laposte.net>:

...

I appreciate your ideas, how much would they scale? Can one squeeze 300 customers per unit and link many parallel units?

I've yet to see a multiprocessor trade matching engine.

Do https://github.com/PhantomPhreak/counterpartyd and https://ripple.com/guide-to-currency-trading-on-the-ripple-network/ count as trade matching engines? Why in the world do we need a centralized trade matching engine when the commodities (corn) and customers (grocery stores) are fundamentally distributed anyway? If someone wants the absolute best price possible in the world for their stock trade, then they can spend a gazillion dollars on brokers and HFT and microsecond latency to the exchange floor. But I want to be able to execute corn futures trades and physical delivery contracts from the server in my combine that knows to-the-bushel how much I'm pulling out of the field. I mean, I've got to have *something* to do while the babysitting the GPS guidance system .... -- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed.org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash

<hozer@hozed.org> wrote:

Why in the world do we need a centralized trade matching engine when the commodities (corn) and customers (grocery stores) are fundamentally distributed anyway?

Get big or get out. -- Earl Butz, Sec of Agriculture for Jimmy Carter ( Do you have an autopilot on your receiver truck? ) --dan

On Mon, Mar 24, 2014 at 05:28:29PM -0300, Juan Garofalo wrote:

--On Monday, March 24, 2014 2:56 PM -0500 Troy Benjegerdes <hozer@hozed.org> wrote:

...

Why in the world do we need a centralized trade matching engine when the commodities (corn) and customers (grocery stores) are fundamentally distributed anyway?

Good question.

...

I mean, I've got to have *something* to do while the babysitting the GPS guidance system ....

Isn't gps completely centralized and run by you-know-who?

You-know-who costs me significantly less money than JpGoldKochMorgan's centralized high-frequency trading. Besides you-know-who would rather tax the middle class to buy fuel from me than have to send more kids to drive fuel tankers over IEDs.

2014-03-23 3:28 GMT+01:00 Juan Garofalo <juan.g71@gmail.com>:

--On Sunday, March 23, 2014 2:14 AM +0100 Lodewijk andré de la porte <l@odewijk.nl> wrote:

...

Looking at the hacks that happen I'm mostly shocked to find the level of stupidity. Shocked as much to see how long things just go on without significant trouble. MtGox failing because money dissapeared over the years... That was shocking at an unbelievable level.

Unbelievable because it's bullshit. Just like the last piece of news saying that they magically 'found' 200k btc.

It's easy to think it's a big scam, but it doesn't make sense. If magicaltux wanted to "walk away with the money" he would do better hiring someone else as CEO and then just doing whatever the hell he wanted with his financial returns. In at most 20 years he'd have all the money he just stole, with none of the crime, shaming, etc, legally! He'll truly never be able to launder those "stolen" Bitcoin. The leaked info is incredible, but it's all quite coherent. I haven't made up my mind yet. We'll see it play out.