Something is wrong with BTC/EUR indication on the summary page.
https://i.imgur.com/2Sdnmm8.png

Huobi doesn't seem to update for the last day or so.

HMRC service doesn't work for me, don't know why. But if you were able to find HMRC money service registration, this just proves that they do have a valid certificate. They registered with HMRC at the same time as they changed their name, hence HMRC shows the old name.

HMRC website says (from your screenshot) Date registered: 01/06/2013
Companies house website says: Date of change 29/05/2013 Previous Name COIN FLOOR LTD
Probably they filed for both name change and money service certificate simultaneously.

"Trading address" for the bureau de exchange doesn't have to be the same as a company registration address. Company number and money service certificate number are different things altogether. Nothing shady here.

I think you misunderstood a few things here.

Firstly, HMRC doesn't have publicly accessible companies register. You are talking about Companies House, http://wck2.companieshouse.gov.uk//companysearch.

Here is what they've got in their register:
Name & Registered Office: COINFLOOR LIMITED
C/O BUCKWORTH SOLICITORS
200 ALDERSGATE, LONDON, ENGLAND, EC1A 4HD
Company No. 08493818
Previous Names:
Date of change 29/05/2013 Previous Name COIN FLOOR LTD

Secondly, there is no company registered under number 12713897, which you mentioned. This is an HMRC certificate number which coinfloor do mention on their site:


I guess this is a certificate of money service business registration. However I couldn't find them in the publicly accessible register neither here (the service cease on 31 of March 2013) nor here. Could be just a malfunctioning HMRC service.

Interesting enough, the only bitcoin exchange which operated in the UK to date since November 2013, bit121.co.uk, yesterday announced that they are closing down. Coincedence? By the way, they were descent enough.. They had no API, slow deposit/withdrawal, no even ticker. But they looked trustworthy and would be a nice option for those who don't trade often. It's a shame they are closing down.

Well.. it actually all makes sense. First there was a fatal fault in Bitcoin, all bitcoins were hacked, Bitcoin company went bankrupt, and now Bitcoin CEO commited suicide.
We just need to inform people, that we are not going to run out of Bitcoin CEOs any time soon, as there are many other.

When exporting address data into csv, please remove comma separator from big numbers (like 1,222.3404 BTC). These commas interfere with comma-separated file format

To start with, stop calling it a double-spend. It's not double spend until it's in the blockchain, it's double-spend attempts. And double spend is not possible.

Hold on. Are there actually any reports of something being screwed, apart from couple of exchanges who stopped withdrawals as a precaution measure?

LOL, isn't it MtGox with their custom client trying to re-submit failed transactions relentlessly?

Can you please post a couple of transactions to check what exactly was mutated? Many trivial mutations are already rejected by most nodes. Just want to see what's going on.

>it's not a matter of wanting to include unconfirmed change outputs, it's the fact that the satoshi client does this by default
is it a fact?

No, double-spending is not possible within bitcoin protocol. MtGox didn't see that original transaction went through and re-issued it (automatically or manually - I don't know) with different inputs.

You cannot change recepient or amount without breaking the signature and invalidating it. You can remove padding though - thus creating a good-looking transaction. If the inputs used in this transaction were not yet spent, you can get this transaction confirmed (included into a block). So basically you will do what originator of this transaction was intending to do anyway, the only difference is that you modify transaction in a way which may be unexpected by some outdated bitcoin software like MtGox's. And that is a known issue since 2011, so reference client and probably most custom clients don't rely on that and are not affected.


They became too big and important to care. Just like many banks.
This is my pure speculation, but probably their attempts to speed up transactions actually played role here too. They had partner miners, so they were able to send transactions directly to them, bypassing other nodes. "Network doesn't accept our transactions? Fuck the network, we will go straight to the miners". Until miners finally updated their software.

Actually they may try to recover some, if they are able to figure out who did that. But I wouldn't bet much on it.
Also they may go into liquidation in a civilized way. That would be the best option for everybody. Bitcoin foundation should use all their influence to pressure Mark to do that.

It's wrong to think this is just Gox's problem. It's a problem of Gox's customers (large part of bitcoin community), and this is a problem of Bitcoin public image. When "the oldest and at one point the biggest bitcoin exchange" is run by such moron, that taints the whole community.

Malleability is a potential and hypothetical issue nuisance, which only became possible to exploit at MtGox for two reasons: because Gox failed to correctly implement Bitcoin specification properly, and also because it failed to implement proper workarounds for this issue. You correctly pointed out second reason, but the first is more important to point out, in my opinion, because this is why other exchanges are much less likely to be affected, if likely at all.
Gox didn't follow the specification, which required tx signature to be encoded with ASN1/DER encoding. This requirement was specified in April 2011: https://en.bitcoin.it/wiki/Protocol_specification#Signatures
Instead they used some sloppy format which was not DER encoding but was still accepted by SSL library and old reference client. When tighter checks were implemented in bitcoin reference client (the main reason for which was actually to prevent malleability issue), their transactions, which violated bitcoin spec, were rejected. Basically, their transactions looked like what hackers would employ to exploit this issue. That allowed hackers to pick these rejected transactions up, malleate them to "fix" the signature format, and re-submit. Ironically, hackers were helping MtGox to propagate their malformed transactions through the network.
If MtGox submitted correct DER-encoded signature in the first place, hackers would have to figure out how to malleate the transaction without breaking the spec so that the transaction is still accepted by the network, and then outrace the originator of the transaction in propagating the malleated message to the miners, or use their own miner, and be lucky enough to mine the block before somebody else mined the original transaction. A lot of trouble - and all that just to modify tx id, which is already a published known issue, and can be easily detected with manual investigation or proper workarounds in place.

It's not malleability per se which is the reason for MtGox failure, but failure to properly implement bitcoin specification + malleabiiliy + failure to implement workaround + lack of attention to abnormal behaviour in their system + inability to react quickly when the issue became glaringly apparent+not testing their system with reference implementation+....
Or, in other words, lack of competence, unacceptable for the only golden member of Bitcoin Foundation.
There was so may ways this could have been alright - and only utter stupidity and incompetence allowed this to go wrong.

I believe the reason they are doing that is because they simply don't have enough coins, and they are trying to win time under a false pretext and force their users to sell bitcoins cheaply (to them). They can then sell those coins somewhere else, and buy more, until they become solvent. No matter how shitty their developers are, they should still be able to fix their bug in some shitty way, which would be enough to restart "normal" operation. Also they could provide manual withdrawal option at a premium - but they don't do that. They simply don't have enough coins.


seems so..

They are not even using reference client, why the hell they are fucking everybody's brain? Your system failed to track transactinos - so go and fix your system, and then go ahead and propose a patch in the reference client if you believe this is necessary/reasonable. I don't understand why core developers even take this seriously. That's like negotiating with terrorists - just encouraging them.

>Now for 99.999% of your transactions (if you are competent and not doing things like double spending your own coins, paying insufficient fees on masive spammy txs, and spending immature coins) the tx will go through fine.


...and signign with non-canonical signatures, after it's a known issue for two years

It was discussed back in 2011
 https://bitcointalk.org/index.php?topic=8392.0

The patches were submitted in late 2012: https://github.com/bitcoin/bitcoin/blame/master/src/script.cpp

The protocol specification was updated in April 2011:
https://en.bitcoin.it/w/index.php?title=Protocol_specification&oldid=7624
Edited on 24 April 2011:
"Signatures use DER encoding to pack the r and s components into a single byte stream (because this is what OpenSSL produces by default). "

MtGox is a bunch of liars (should make this a signature, probably).

Another lie from MtGox:

[10/02/14 15:08:48] <@ne0futur> epscy: the problem is ackowledged
[10/02/14 15:09:04] <@ne0futur> Oh there is a “problem” in the Bitcoin protocol, known since at least 2011 (see the link I gave). But for normal applications, not involving unconfirmed transactions, it shouldn’t cause any severe problems because wallets can handle it locally.
[10/02/14 15:09:07] ne0futur: what does that mean?
[10/02/14 15:09:12] <@ne0futur> http://www.cryptocoinsnews.com/2014/02/10/mt-gox-blames-bitcoin-core-developer-greg-maxwell-responds/
[10/02/14 15:09:31] <@ne0futur> the disagreement is on how to fix it
[10/02/14 15:10:06] <@ne0futur> one option is putting much more load on the client who cant trust the transaction hash on the blockchain
[10/02/14 15:10:10] <@ne0futur> as I understand it
...
[10/02/14 15:15:16] ne0futur the problem was acknowledged in May 2011: https://bitcointalk.org/index.php?topic=8392.0. The patches were submitted in late 2012: https://github.com/bitcoin/bitcoin/blame/master/src/script.cpp. Stop repeating "the problem was acknowledged" - it sounds really pointless
[10/02/14 15:15:50] <@ne0futur> ibtc: https://en.bitcoin.it/w/index.php?title=Transaction_Malleability&action=history
[10/02/14 15:15:53] MtGox had a sloppy implementation for transaction signature format which made it vulnerable
[10/02/14 15:16:00] <@ne0futur> but documented only in 2013 for client developpers
[10/02/14 15:16:35] What, DER standard was documented in 2013???
[10/02/14 15:16:50] Do you actually understand what you are talking about?
[10/02/14 15:40:24] "[10/02/14 15:16:00] <@ne0futur> but documented only in 2013 for client developpers" <- yet another lie from MtGox. https://en.bitcoin.it/w/index.php?title=Protocol_specification&oldid=7624     Edited on 24 April 2011: "Signatures use DER encoding to pack the r and s components into a single byte stream (because this is what OpenSSL produces by default). "

Specification was updated in April 2011, clarifying that the format for the signatures is DER encoding (which, when strictly followed, would always produce the correct signature accepted by all clients, not just OpenSSL ones). Apparently, MagicalTux didn't know about that. And I highly doubt he learn about it any time earlier than a few days ago.

What a bunch of liars. All of them.