 Show Posts
|
|
Pages: [1] 2 3 »
|
Something is wrong with BTC/EUR indication on the summary page.  |
|
|
|
|
Huobi doesn't seem to update for the last day or so.
|
|
|
|
My first piece of text is related to Companies House registry, you are right. HMRC doesn't have publicly accessible companies register...
...However I couldn't find them in the publicly accessible register neither here (the service cease on 31 of March 2013) nor here.
go here https://customs.hmrc.gov.uk/msbregister/search.do?type=newSearchthen in "Money Laundering Regulations registration number" field enter 12713897 (I took it from their site, you quoted it as well) in Postcode type EC1N 8SB click search then you will see a record but for another spelled company "Coin floor" (with a space, not Coinfloor) and with another address. my screenshots from the previous post show it clearly 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 have noticed one more strange thing On their site they claim that company registration number is 08493818 The company that is registered under this number is "COINFLOOR LIMITED" proof screeshot http://gyazo.com/a74370f84fa87eec4d879b9c9939dc83HMRC reg number they claim is 12713897, but on HMRC you will find another company "Coin Floor" with another address under this number... prooflink http://gyazo.com/d19183dc02a7d50308d0057f822249c1that simply means Coinfloor LTD has not been registered at HMRC as "Bureau de change". Both registries are public so I have just confronted the data from both of them and the data from their AboutUS page. thus, what they claim is not true. think yourself 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 LIMITEDC/O BUCKWORTH SOLICITORS 200 ALDERSGATE, LONDON, ENGLAND, EC1A 4HD Company No. 08493818Previous Names: Date of change 29/05/2013 Previous Name COIN FLOOR LTDSecondly, there is no company registered under number 12713897, which you mentioned. This is an HMRC certificate number which coinfloor do mention on their site: Coinfloor is a company registered in England and Wales registration number 08493818. We are a registered Bureau de Change. Her Majesty's Revenue and Customs certificate number 12713897. Our company is registered at 200 Aldergate C/O Buckworth Solicitors EC1A 4HD London, United Kingdom. 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 |
|
|
|
I know very well how it is resolved, the question is why the double spend appear in first place.
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. |
|
|
|
The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)
It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.
this is probably related to the current malleability attack on the bitcoin network (25% of transactions were affected today). it has nothing to do with your theft.
In addition to the above jgarzik is quoted on reddit to have said that one home PC could have done this. One home PC can screw up 25% of transactions! Hold on. Are there actually any reports of something being screwed, apart from couple of exchanges who stopped withdrawals as a precaution measure? |
|
|
|
The number of "double spends" (most of which I believe is mutated transactions) for the last 24 hours:
2014-02-11 16960
(will edit OP to reflect this)
It is slightly lower than I anticipated, as it was already above 16k 9 hours before the CET day ended (24 hours). Maybe the attack subsided, or someone is having a break.
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 really is not that much of a problem IMHO. If those change outputs will eventually confirm or not has nothing to do with mutated TxID. If someone wants to include unconfirmed change outputs as his new inputs that's his problem. .
it's not a matter of wanting to include unconfirmed change outputs, it's the fact that the satoshi client does this by default and you can't stop it without patching it. so user is vulnerable to getting their wallet messed up. >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? |
|
|
|
So does that mean if you saw a transaction floating around the network that has a TX signature with junk padding, you could copy it, remove the padding and resend so the benifactor of that transaction would get paid twice?
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. So just to be clear it is not possible to find an Unconfirmed Transaction on the Network with junk padding, copy it and change things like recipient, amount, remove padding and resend?
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. Jeez you would think Mt Gox would be looking for ways to speed up transactions, so you would think they would know Miners are rejecting their transactions with junk padding on the signatures and amend any script so as to remove the junk padding and speed up confirmation times. Crazy incompetence.
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. |
|
|
|
3. Not sure what you mean. But if gox really double paid some customers, they are the one to absorb the loss (or they will close and run)
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. |
|
|
|
The big question is how long has this been going on and has someone actively exploited it?
This is simply gox's problem, as they shouldn't follow the transaction flow this way in the first place. 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. |
|
|
|
The problem is, there is indefinite ways to alter a cheque without invalidate it. We need to live with transaction malleability and actually it's no big deal
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#SignaturesInstead 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 expect it to take a while for the reality to sink in and MK to swallow his pride and pay someone to fix/rewrite their custom client.
It's the same thing all over again as it was with the trading engine last year.
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. i hope i am wrong.
but i begin to think that they lost so much btc to this issue that they need to buy coins.
seems so.. |
|
|
|
I proposed a new txid type this morning that would contain only prevout,vout and address,amount pairs. It would only need to be used internally by companies vulnerable to this type of attack and doesn't require 99% of bitcoin users to change a thing. When creating a withdrawal, log the new id and do your lookups based on it when users complain.
The txid you propose could collide, should a spend be made from the same address to the same address in the same amount (a certainly foreseeable circumstance). Non-reuse of addresses after spending from them is simpler, requires no protocol change, and seems to be as Shatoshi himself suggested using the bitcoin protocol. It cannot collide because inputs (prevout,vout) can only be spent once. Only malleable transactions collide with each other, which is the goal. So this is essentially what gox is proposing 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
|
|
|
|
Another lie from MtGox:[10/02/14 15:08:48] <@ne0futur> epscy: the problem is ackowledged [10/02/14 15:09:04] <@ne0futur> <gmaxwell> 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] <epscy> 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] <ibtc> 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] <ibtc> 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] <ibtc> What, DER standard was documented in 2013??? [10/02/14 15:16:50] <ibtc> Do you actually understand what you are talking about? [10/02/14 15:40:24] <ibtc> "[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. 
|
|
|
|
|
