With the appearance and gain in value of Bitcoin Cash, a new risk appears for Bitcoin.
Indeed, for miners, it can be much more profitable to do migratory rounds between crypto-currencies. Let me explain how and why.
Bitcoin, Bitcoin Cash and other crypto-currencies will adapt mining difficulty after a number of blocks (2016 blocks, or every 2 weeks). This means that if a lot of mining power comes in right after the difficulty change, it’ll take 2016 blocks for difficulty to reflect the increase of mining power.
Now let’s suppose we have multiple mining groups agree to a migratory plan. Mine at full power on one crypto-currency until reaching the difficulty change, for example mining two weeks worth of blocks in one week only, then switch to another currency while it takes 4~5 weeks for the previous currency to see difficulty return to normal.
With an optimal migratory plan and enough high-valued crypto-currencies to migrate to, this group could be continuously mining blocks at higher speed than planned (until difficulty is re-calculated), then move to another target while confirmations for that crypto-currency become slow.
Requirements for this to work include:
Each crypto-currency using the same proof of work hash algorithm
Having enough crypto-currencies to migrate to while waiting for others to see their difficulty resume to normal
Each crypto-currency should have a high enough value so it’d be profitable to switch mining from one to another
At this time I do not believe any mining pool operates such migratory operations, but with the appearance of Bitcoin Cash, this became more likely. Of course during cool down confirmations times are longer (up to twice as long) so it may affect the value of the crypto-currency on the long term, but mining operators may prioritize short term profits.
There are of course ways to limit the impact of such activity by making it less profitable, but these may not be so easy to implement anytime soon.
The best way would be to see merged mining implemented between such currencies, as it would improve the security of all involved coins by sharing mining power while giving miners the required incentive (increased profits) to join in.
The big news today is the arrest of Alexander Vinnik (38) in Greece on suspicion of money laundering of some $4bn USD worth of Bitcoins.
This is an event I have been waiting, as well as various persons, because it means we can finally disclose a lot of elements we have been working on which we had to keep undisclosed until recently because it could have prevented this arrest from happening.
Vinnik was just arrested in Greece, which means this case is finally in a state where disclosing information is not going to compromise his arrest. I am guessing US law enforcement convinced him to come to Greece one way or another as it is quite often the case (for example, in the book Crack99, a US prosecutor explains how they trapped the webmaster of a site selling cracks by promising him money and having him travel overseas - I am guessing a similar method was used here, unless Vinnik was already planning to travel to Greece with a different goal in mind).
Anyway the point is until now, disclosing what we know could have tipped him into not leaving Russia. Most countries in the world will not extradite their own citizens, which makes sense but for this specific case prevents anything to be done.
Now the question is to know how long it will take for him to be moved to the US. Depending on local laws and on Vinnik himself, it could take from hours to months.
One thing a lot of people have been asking is why was Vinnik arrested only for money laundering, and not theft. I am guessing there are many reasons for this, but the main reason is likely because it was easiest to build a case based on money laundering. When a country asks another country for extradition of an individual there are various steps to be taken, and usually both countries will need to agree there was indeed a crime. It means the requesting country will need to prove its case and provide enough evidence.
As such I am guessing we will see other charges brought up after Vinnik is on US soil, and in the meantime more details may be made public. Either way the MtGox theft has been flowing to wallets controlled by Vinnik from the very beginning, without any wallet in between, and there is no evidence of any other party being involved.
Evidence points without much doubt to Vinnik being not only behind the money launderer of those coins, but the actual theft.
For MtGox creditors this means a lot. It means justice will finally be brought against the actual criminal behind this case, but also that there is a chance, however small, to see some coins recovered.
As for the actual theft, there is still a lot to be investigated. Evidence so far points toward one of MtGox’s bitcoind based wallet being stolen sometime in Sept 2011, and being used afterward to steal bitcoins. We do not know yet how this wallet was stolen, and at the time MtGox still ran on rental servers from a cheap hosting provider. From there the theft went in small increments over time, making it difficult to detect, focusing on newly deposited coins from users who have been re-using bitcoin addresses issued by MtGox.
Because at first nobody knew exactly how the bitcoins were stolen, the focus had been on the way bitcoins moved in/out of MtGox on the blockchain. It is a multiyear effort by various parties - from law enforcement to investigators hired by the MtGox trustee to third party independent investigators - which finally bore fruits some 3 years and half later.
Considering the efforts that went into this investigation and were required to reach this point, I dare say that there was little chance for us at MtGox to detect this at the time, especially considering the fact we were already fighting on various fronts, from compliance to daily hacking attempts to various other issues. At the time of my arrest the Japanese police was still convinced there was no theft of Bitcoins at all from MtGox. Only few people suspected there could be an actual theft at the time, and my arrest was seen for a bit at the final point of the MtGox saga.
And yet, here we are. I must say this is something I have been waiting for this since that day of February 2014 when I stood in front of the cameras to announce the bankruptcy of MtGox. As far as I am concerned the MtGox thief has been finally arrested. He stole some 630,000 BTC from MtGox (according to Wizsec), but he also stole much more from everyone involved.
Just some thoughts I’m posting here for future reference.
Reading a lot about Quantum theory (including some recent developments) I’ve come to wonder if the way time works is not similar to gravity. A specific future event with enough mass to attract us all toward it, influencing our vision of time as something linear in the same way someone falling feels there is no way to go up, only down. Going sideway may affect falling speed.
I was talking about the Bitfinex vs Wells Fargo case (iFinex Inc. et al v. Wells Fargo & Company et al) filed in the California Northern District on April 5th, however plaintiff filed a voluntary dismissal (docket 28) on April 11th.
The reason why Bitfinex decided to dismiss the case isn’t clear yet.
“A few years ago, MtGox had its international wires blocked by an intermediate bank. This caused a lot of additional costs as it was difficult to work around such blocks, and intermediate banks would also pressure our Japanese banks to close our accounts (unlike in the US, in Japan a bank cannot close a customer bank account of its own accord without a good reason).
At the time, our lawyers strongly advised against any legal action against the bank, however it seems that Bitfinex decided to go that way, and filed a lawsuit with the California Northern District being heard by Judge Hon. Maxine M. Chesney, filed as 3:17-cv-01882-MMC iFinex Inc. et al v. Wells Fargo & Company et al.
In the original complaint, Bitfinex et al explain that as of Friday, March 31st 2017 Wells Fargo stopped processing outgoing wires without providing any kind of warning or explanation, which “will cause great and irreparable harm to plaintiffs.” They ask for the transfers to not be blocked anymore, and damages in excess of US$75,000.
So far, Wells Fargo only submitted a single response (Docket 20), explaining they ask for time to file Opposition, and oppose the Temporary Restraining Order plaintiffs asked for as forcing processing of wire transfers would, among other things, “place an affirmative duty on Defendants where none currently exists.”
The following schedule has been set Friday, April 7th 2017:
By April 12th: Opening brief
By April 20th at 2:00pm: Opposition
On April 25th at 10:00am: Motion Hearing
This means that by April 20th at 2:00pm (usually this kind of things are filed just before they are due, so most likely around that date and time) Wells Fargo will file its opposition to the Plaintiffs’ complaint.
Under US law, a bank can choose who it is doing business with and has a lot of leeway in how it can proceed. At the time of MtGox it was not rare to hear of US customers that their bank had closed their account. They would receive a letter saying something similar to “Your bank account has been closed as <a few days ago>. We may send you a check of your balance within 60 days.”
For intermediate banks, blocking transfers is rare, and usually happens because the bank has strong reasons to believe the transfers is linked to some kind of criminal activity. MtGox processed hundreds of international wires per day for years, and we’ve had only a handful of blocked wires until we got blocked ourselves.
Anyway based on the only two pages filed by Wells Fargo so far, it seems obvious they have absolutely no intention of resuming wires. Most likely they will try to make things last as long as possible and get other banks onboard in blocking such wires, slowly strangling plaintiffs. More than anything, the complaint didn’t mention any legal precedent or basis for forcing Wells Fargo to process wires, and that might be difficult to do in the future because of the way things work in the US.
Bitcoin’s blockchain is an interesting concept of decentralized database. There are various new blockchains created out there, and different levels of blockchain, some not using proof of work mining but instead some other protocol (such as raft).
Some people claim these are not actual “blockchain”, and should be named differently. Actually the concept used in Bitcoin can be found in a much older piece of software, git, in which people also build blockchain (if you consider a commit to be a block) which contains a tree linking to objects (bitcoin has a merkle tree of transactions), all of which referenced by hashes. Git allows developers to sign commits or tags, resulting in something similar than the Bitcoin blockchain (a signed commit also includes the hash of the previous commit, etc, and hash of the tree with has hash of all included files, meaning the signature results in the whole history being secured - as much as sha1 hash algorithm used by git allows).
Anyway the question I’ve come to is to define what is a blockchain and what isn’t. Is it wrong to have a blockchain without mining? Without addresses and value? What’s stopping you from calling a git repository a blockchain?
The definition for “blockchain” given by Google is: “a digital ledger in which transactions made in bitcoin or another cryptocurrency are recorded chronologically and publicly.” That is of course the current definition, but gives some basic guideline. It should be a public cryptocurrency ledger with chronological storage.
This definition is however a bit too narrow, I think. A public database recording only hashes in blocks, for example, could very well be called a blockchain. Why not?
So instead I looked at the word itself. Blockchain. A chain of blocks. So a blockchain is a database of blocks where each block contains the hash of the previous block, and where the creator of the software decided to call that a blockchain. So no you cannot call a git repository a blockchain (unless git’s creator decided to, in which case it’d be perfectly valid), and yes, all the people using the blockchain term for all sort of non-bitcoin stuff (private databases, etc) are perfectly allowed to.
Apple Pay is probably nice and all, and having been a user of Mobile Suica in the past (on Android), I know many of the benefits of using a Suica card on mobile device, however this October 25th launch of Apple Pay in Japan has been botched.
Of course, first thing after opening the service, the Suica servers failed. The load caused by all those users simultaneously trying to switch to the new system must have been way too much, and nobody seems to have guessed putting ads all over the metro stations would cause everyone to try to switch. Well, load and crash is one thing, recovery is another. The service stopped working around 7:30am, however Apple’s System Status reports it started slightly before 9:30am...
You’ll notice the text in Japanese. “Apple Pay, a part of the users affected. There are times where adding a Suica card to Apple Pay will not work”. The last part, especially the “there are times” (”できないことがあります”) is especially light. I’ve tried at various times of the day, and it still doesn’t work, despite...
You probably guessed it. According to Apple, the problem is solved. I can confirm however that it still doesn’t work.
So yeah. So much for testing Suica on iPhone. The conclusion is simple: doesn’t work, actual test will have to be done another time. Note that when you use an iPhone, it is not possible anymore to use Mobile Suica services such as EX-IC (reservation of Shinkansen), Bank Charge, Credit Card Charge (all charge needs to be done through Apple Pay or at locations supporting charge such as convenience stores) most likely because Apple’s contract with JR/Suica includes some exclusivity on payment processing.
And of course, support of Apple Pay for payment methods other than Suica is fairly limited as it doesn’t even include VISA, and so far it seems that even with a supported card issuer, payment via Apple Pay are not possible (only via the supported iD system, in my case).
Despite the day going through the issue hasn’t been resolved. Not only adding cards is broken, but charging too, and this includes also other devices according to Twitter/news websites. The idea of “moving” your Suica card to your mobile phone was quite cool, it’d be even better if it actually worked.
I’ll probably do a new post on Apple Pay with Suica once this works and detail the result. I did hear somewhere that JR is planning at some point in the future to switch all its Suica system on a centralized architecture (ie. each Suica use checked in realtime against a database instead of only using the card itself), if this happens in the same way Suica for Apple Pay launch happened we’re up for some trouble times in Tokyo’s metro.
Yep, the programming language, by Google. In the past weeks I have been working on a new project using Go, and I must say thing is hella stable, and great to use.
One thing I wanted to do is have the HTTP server run with custom connections. I accept connections from a net.TCPListener and pass these to http.Serve after doing whatever needs to be done.
This required use of a custom Listener object to be passed to http.Serve which instead listened on a chan where I’d push connections ready to be served, requiring skillful use of both goroutines and channels.
The real power of goroutines comes also in the fact that writing non-blocking code is no longer required. No need for complex state machines, handling of events and so on as one would do in C. This makes code that much easier to read, and reduces the risk of bugs.
I’m still a bit reserved about Go’s way of handling errors. Passing along error variables is great and all, but one ends checking if an error happened at each function call (3 lines each time). A sort of macro/builtin that would “eat” the last return value of a given function (provided it is of type error) and return it from the current function if not nil (and all other return values if any would be set to nil) would be very, very helpful.
So yep, I’m back and can use a computer again. It took time to restore some stability by getting some work, and this kept me busy for the past months, but I’ll be writing again, no matter if people like what I write or not. If you don’t, just browse away, nobody is forcing you to read this.
So a lot happened and still remain to happen, so there are many subjects I am not able to talk about. One thing I will say however is that there are a lot of disinformation out there. Nothing new you’ll tell me, but there are a few things I’d like to say because this is starting to get old.
I have no specific interest in Magic The Gathering
This may come at a shock, but the MtGox name came from its previous owner, and not me. I did read about Magic The Gathering online so I know basically what it is, but I never played any trading card game, so I am unsure of how that actually works. In my time we played with marbles (and pogs).
Strangely enough people tend to associate me with the game, so let it be said that no, nope.
I use source version control
That one came up again earlier on twitter, so I’ll clarify. I’ve been using source control for more than 10 years. Started with cvs, then moved to subversion (a huge improvement, especially when it came to renaming/deleting files) and now git (and its overly vague specifications - but that’s something I’ll cover some other time).
Point is people seem to have the idea source code at the company was not version controlled, which is wrong. Not only that but we had branches, and an automated deployment system that involved running tests before deployment can happen.
There’s probably a whole lot more crap going on out there, and trying to say otherwise may not work, but at least let whoever tries to get to the truth reach it. I’m back to zero, bankrupt and with a huge minus in terms of image. Getting out from there is an uphill battle, but I’m not one to give up easily. I am guessing the full story will become known eventually, so I’ll wait until my time comes.
I am still investigating the elements made available with the arrest of Shaun Bridges (USSS) and Carl Mark Force IV (DEA), but at this point I already noticed some interesting facts.
We know that both agents have been investigating Silk Road since at least 2012. Based on news reports investigations of Silk Road presumably started around June 2011 since it appeared in the news, however there is no telling if it was Baltimore, and if either agent was involved until at least 2012.
based on the available documentation, it is also difficult to know precisely since when both have been conspiring. The following relevant information can be gathered from the original criminal complaint filed on March 25 2015 and published by the US DOJ a few days later.
P4L2: Force sold to DPR “information about the government’s investigation into Silk Road” for approximately $100,000
P5L21: Bridges was still using MtGox services two days before serving as the affiant the MtGox seizure warrant
P12L4: Communications between Force and DPR spanned throughout 2012 and 2013.
P20L24: We learn more about the information sold to DPR (see P4L2), and P21L2 lets us know that my name was given to DPR between August 26th and September 14th 2013 (as also shown in this document, paragraph 18).
P35L5: Force wants to bully a company by seizing funds “à la BRIDGES and [M.M.]”
P38L7: In April 2014, it seems that Bridges covered Force’s acts with Bitstamp.
P43L18: On January 23, 2013, Force emails Bridges regarding their suspicious activity. This means that Force and Bridges have known each other and have been conspiring since at least this date.
P45L28: Shows that a seizure warrant is not an overnight thing and takes “several days, if not longer”, putting suspicion on the MtGox seizure warrant.
Also relevant is the fact that while MtGox had more than US$5 million seized, as far as I know and as of today no other unlicensed Bitcoin exchange had anything seized in the US nor was ever prosecuted in any way.
Now, if we add to this the transcript of the Ross Ulbricht’s trial (2014-cr-68), we can also find a few links, especially on the page 492 and following where elements are relevant. We know the defense attorney (Dratel) was barred from mentioning Bridges and Force, but we can still notice how he pushed the case of HSI Baltimore. I will have to re-read all of that, but among other things we learn that HSI Chicago and HSI Baltimore (where Bridges and Force were) were both investigating me as the mastermind behind Silk Road, and that HSI Chicago was against doing anything that could raise suspicion on my part that I was being investigated.
Despite that fact, 3 seizure warrants were executed against MtGox.
It should also be noted that the affidavit contains a lie that was repeated a few times in the news. In “IV Probable Cause”, the affidavit says I filled a MSB form and explicitly said that Mutum Sigillum LLC was not a Money Services Business.
It should be known registered and opened this bank account remotely. All the required documents were sent to me by email, and I sent them back all duly filled and signed. As such I have a copy of ALL the documents I filled, and I can say for sure that the affidavit statement “Karpeles answered these questions[...]” is false.
I’ve been pondering for a while whether I should write about this or not. It sounds paranoid in the same way some online conspiracy groups are, however it becomes increasingly difficult to simply ignore the amount of available evidence.
Right now I see two main possibilities behind the 2013 funds seizure:
The goal was to destroy MtGox to erase any record of the sale of Bitcoins done by Bridges, thus making it very difficult to track funds stolen from Silk Road back to his company.
Someone paid Bridges and/or Force to harm MtGox. While extensive documentation is available on the exchanges between Force and DPR, not much is said about exchanges with other Silk Road users, and I have elements showing that some of them (Silk Road vendors) have been targeting MtGox since as early as 2011, notably because we were blocking accounts involved in illegal activity.
(of course, some could argue this was actually an attempt by the US government to act against Bitcoin, but while the possibility exists, at this time I have nothing supporting this scenario)
I also recently learned that SR1.0 vendors discussed various ways to harm MtGox, including “freak signatures” and x690 (now known as transaction malleability) and that it was “about stealing BTC”. There is no doubt those vendors would have at that time more than enough budget and motivation to hire hackers and others, and the chances of finding any of them are close to none as they are already hiding successfully from law enforcement.
I still have a mountain of elements that needs to be analyzed before any conclusion can be taken, however there seem to be some hope.
Also, the fact that Force, as a special agent at the DEA, sold information regarding the investigation to DPR is irregular. I am not an expert in US laws, but I believe there is something I can do, so I’m investigating what kind of options are available, and will do whatever is appropriate.
Even without being into Japanese animation, it is hard to not know about the recurring theme of giant robots: Gundam, Mazinger, Evangelion, and more.
So it sounds appropriate if a Japanese company, using today’s technology, would be working on giant robots. I am of course talking about Suidobashi Heavy Industry’s Kuratas.
Now, in the US, different companies are also building robots. While Boston Dynamics is thinking mobility and numbers with their big dog and others, MegaBots built their own in the most american way: with very big guns and a look that would fit just right in post apocalypse movies.
One week ago, MegaBots issued a challenge to Suidobashi Heavy Industry:
To which the reply was of course a big “WE ACCEPT”:
Of course it’s big news, and like a lot of people here in Japan I’m hoping to see an epic giant robots fight where both sides do their best to show us what these hold for the future.
The only thing that’ll be missing should this even actually be held somewhere is a proper live after the fight. And what would be more appropriate than Germany’s Compressorhead:
Installing Oracle Java8 requires accepting the license. Usually you probably already have accepted it a lot already previously, and the process of having to click “yes” is an issue for automated server deployment.
EDIT: it seems that doing it this way is actually better:
The recent controversy around the block size limit saw a lot of oppositions, especially from China.
It makes sense for mining to be brought to locations in China where electricity is cheap, but which might not have access to the best Internet access.
You could ask why don’t mining farms in China use mining pools? It might be a question of trust (I guess it would make sense if you’re able to find several blocks a day) but whatever the reason might be, we might want to have a solution for them.
So here comes the idea of mining intermediate servers. This might look similar to a mining pool, except it is not. When joining a mining pool, you need to trust the pool for sending you your share. This idea here requires no trust at all.
By using the stratum protocol, this makes things easy too. The stratum protocol works exactly how we want and is already widely supported in many mining applications.
In the initialization phase, we let the server know where we want mined bitcoins to be sent (for example as part of the authentication). Then when we receive the coinbase transaction, we can easily check if it is indeed the case, or reject the transaction and the server - and try to use a different server.
This also means that if the client agrees to it, the server can take a fee that would allow paying for bandwidth/etc.
The software would be easy to implement too, since it just requires a stratum mining pool server software with some changes:
Do not generate mining pool coinbase. Instead coinbase is generated per client, with a single (normal) or two (with server fee) outputs.
Difficulty is the actual network difficulty, not mining pool difficulty
Remember to send client new difficulty each time it changes (every 2 weeks)
It would also be possible to have a specific piece of software that would stand between a given server and miners on a LAN, and would check the coinbase transaction by itself and let miners on your LAN simply get work from that machine (it could even support other protocols other than stratum and should work with stratum-enabled mining pools too).
This could actually make a mining farm such as the ones we see in China be able to work with a 56kbps connection (in theory it should take less than 100ms to go through, however even if it takes 200ms, I would guess we are still safe).
Yesterday, I posted a small message on Twitter that got quite a bit of attention. Despite what happened more than one year ago to MtGox, most Bitcoin exchanges are still running in a way where they hold customer funds and coins. I’m not saying it is simple or cheap to make things different, but I’m surprised nothing happened at all.
Well, not exactly nothing. Decentralized exchanges are starting to appear but still have a long way to go…
Decentralized exchanges
Creating a decentralized exchange is a good idea, except for the fact that you are not able anymore to perform checks to avoid stolen property (funds or coins) to be used (this problem also exists on services like LocalBitcoins or Gyft).
You can of course have a trusted third party handle the AML checks (for example Coinffeine currently works with Okpay according to their FAQ) but this is not exactly decentralized anymore and might not be enough if the third party is not aware of the nature of the transaction. You could be using multiple third parties, but doing so will increase risks - and even as things are right now, I wouldn’t be surprised seeing people using Coinffeine to get Bitcoins out of stolen Okpay accounts in transactions that will subsequently be investigated by law enforcement, and maybe reversed at a loss for the seller.
Bitcoin has an inherent financial nature that makes operating an exchange that much more complex. Usually AML procedures can help dealing with most issues, but won’t work in a decentralized context as things are today.
Based on my own experience the best option for a decentralized exchange would be to allow exchange only between existing crypto-currencies (”alt coins”), which would create a lot of new possibilities in terms of value for said coins while potentially helping offload the Bitcoin blockchain.
Current exchanges
Currently, most if not all crypto-currency exchanges hold all funds on behalf of their customers, and will perform balance settlement for each trade themselves.
While it is easier (and cheaper) to do so, there are other ways of operating as an exchange that would limit the need for the exchange to hold coins and funds, thru limiting risks and liabilities. It would even be possible for an exchange to operate without holding anything, should the appropriate structures exist.
The structures in question would be kind of settlement third parties, for both Bitcoin and fiat currencies.
One entity would be specialized in handling of coins. It would focus mostly on security, and could also offer processing for other things than exchanges (I’m thinking about Lightning, for example). Existing wallet services are probably in a good position to start working on this kind of solutions.
The other would be specialized in handling of fiat currencies. This would mean complying with the appropriate financial service regulations and we could easily have multiple such entities covering different parts of the world as regulations differ.
After each executed trade, the financial entity would move funds to escrow, then the coin entity would process the transaction, which once cleared would trigger the release of funds to the seller.
This might even open new possibilities:
The crypto-currency entity could, instead of holding bitcoins, track liabilities and have their members provide proof of holding by signing messages from their addresses - or by running a wallet software where the customer-side holds the private keys. Once a trade is executed, the customer would be requested as part of settlement to sign the outgoing transaction. Of course the user might decide to refuse, but then it would just mean the settlement failed for a specific trade and funds escrow returned to buyer. The exchange could refuse to work with this seller in the future.
This would also open the door for more competition in the exchanges market by lowering the hurdle of standing there. AML would be typically handled by the financial entity, so an exchange could focus solely on providing the best technology possible without having to setup a 24/7 security response team and spend millions in financial institution registration. There is still a need for lawyers and to make sure the exchange would be legally able to work without any kind of registration (or what needs to be done). Please remember that this blog does not provide any kind of legal advice.
We might see new kinds of business appear we didn’t think of yet.
Conclusion
As Bitcoin gets bigger, the need for more solid solutions increases.
I know how difficult it can be for an existing exchange to switch to a new process in terms of settlement of trades, however the current situation is nothing but another disaster waiting to happen (and that’s the last thing anyone wants).
There are various available solutions, so I am a bit surprised no exchange has moved in that direction yet. Securing customers funds has a huge cost, and so much can be gained by providing this kind of services to the whole community.
