Wikipedia:Reference desk/Archives/Computing/2014 March 6

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

March 6

Bitcoin and Mt Gox

The Bitcoin protocol makes the transfer of bitcoin totally transparent. So how come nobody know who stole the coins from Mt Gox? Also why can't those bitcoin be marked as "stolen" so that they cannot be used for any further transaction until they have been returned to the original Mt Gox account? Also if we do know whose accounts they have been transferred to, why can't the owners of those account be arrested? Unless Bitcoin protocol does not disclosed who the human owners of the thieving accounts are. 202.177.218.59 (talk) 01:32, 6 March 2014 (UTC)

Here's some coverage: [1][2][3]

It's not easy to get from a list of transactions that did happen to a list of transactions that should have happened, absent an evil bit to filter on. You need outside information, such as Mt Gox's internal logs in this case, and if they were as incompetent as it seems they were, that might be difficult.

Bitcoin transfers go to randomly-generated account numbers that aren't explicitly tied to any person, but the way you spend it may leave clues about your real-life identity. The culprits in this case might well be caught using those and other clues, but it won't happen instantly.

There are bitcoin laundering services: customers transfer bitcoin to them and they transfer the same amount of bitcoin back (less a fee) in a scrambled order, sort of like Mixmaster. If any of the stolen bitcoin was laundered, the next owner is a random user of the laundering service with no connection to the original theft. Since the theft has apparently been going on for years, I imagine a lot of it has been laundered, or simply gone through so many subsequent transactions that you can hardly blame any of the current owners anyway.

With those caveats, if the fraudulent transactions were found and published, individual bitcoin users could refuse to take payment in tainted bitcoin. But even those users would have to accept tainted third-party transactions in the block chain, because the protocol depends on all clients agreeing on what is a valid transaction. To globally block those transactions you would have to patch all clients, which is almost certainly impossible even if there were consensus that it would be a good thing. (Edit: never mind; protocol changes apparently do happen.) -- BenRG (talk) 08:39, 6 March 2014 (UTC)

Were they stolen? Couldn't it just be the case that Mt Gox is manipulating everyone? OsmanRF34 (talk) 17:52, 6 March 2014 (UTC)

While it's possible - the mechanism whereby Mt Gox claims the coins vanished is subtle and very real. Essentially, the bad guy would request a bitcoin (in exchange for, say, dollars) - then have his software report back that a bad transaction had happened. Mt Gox would then happily try again. The problem is that each time this happens, Mt Gox would send a DIFFERENT bitcoin on the retry than it sent the first time around. The bad guy would then have two valid bitcoin id's for the price of one. This was a known bug in the system that other sites had spotted and plugged. Flexcoin (who also failed under mysterious circumstances after 'theft') have had similar claims.

This could equally well happen with a real bank - your bank branch could claim that all of your money got withdrawn through an ATM with a software bug - and you'd be reliant on their records to tell you whether your money was really stolen or whether they just decided to keep it for themselves. The reason it doesn't happen in real-world banking is that there are insurance policies to cover this and in the USA, the feds have a scheme in place to cover bank failures and such. There are also regulations forcing banks to keep records of transactions and so forth. For that reason, people don't usually lose much when this kind of thing happens in real banks - and we tend to go with banks that have big impressive buildings and a permanent presence. But the thing about BitCoin is that everybody does it specifically to AVOID government intervention and to avoid the need for banks. This works great, so long as you don't need government intervention and/or you don't go and use a goddamned bank! Banks have to be regulated for a reason - and the reason is so that everyone is covered when this kind of thing happens. Why people keep large amounts of bitcoin in a "bank" is anyone's guess. (Especially a bank who's previous experience is in helping "Magic the Gathering" fans exchange cards!) Neither of the two recently failed BItCoin banks offered their depositors interest payments - so why didn't people just do the electronic equivalent of stuffing dollar bills under their matresses by putting their bitcoins onto a memory stick (preferably with lots of backup copies) and burying them in the back yard? SteveBaker (talk) 16:09, 7 March 2014 (UTC)

The subtlety of the problem is important to understand. Because every Bitcoin transaction in the entire world needs to serialized into a strictly sequential bloxk-chain, it is very common for a bitcoin payment to fail and require a re-try. This is normal; it gets glossed over in descriptions about "miners" and "payment verification." But what it does is breed complacency about transaction retries.

Imagine if you were at the bank, and you saw a guy trying to use the ATM to make a withdrawal, and he keeps hitting the button over and over until finally the money comes out. That's how bitcoin transactions work normally. One user broadcasts a transaction to the network of peers, who (after some delay) confirm it or reject it; and the user re-tries until it finally makes it into the block chain.

So if that's normal, nobody raises any red flags when they see a guy furiously banging away on the ATM withdrawing money and (surreptitiously) hoping his cash comes out twice. The theft doesn't look suspicious until much later.

Steve's right about the attackers getting a "totally different bitcoin" on their retry; it'd be harder to pull off if the same bitcoin were sent on the retry. Again, a subtlety of bitcoin makes this almost mandatory. The "currency" in bitcoin is a signed hash of a transaction history. If a user's transaction failed, and needed to be re-tried, it's a near statistical certainty that new transactions will have occurred in the exchange; the transaction history will be different; so the "coin" will be different. The "security" of bitcoin is that all previous transactions are recorded - which is how you prevent double spending the same coin; so the "abstract entity" that has value - a "coin" - is embodied by a number that is constantly mutating. It necessarily contains the hash of its previous transaction history, plus the current block-chain state. If the number didn't constantly change, the same number could be sent to n different people, and there'd be no possible way to know which transactions were legitimate. So, this "malleability" isn't a "bug" - it's baked into the very protocol that makes bitcoin possible. The algorithm and its implementation works flawlessly! The "security bug" is assuming that you can trust the algorithm as a meaningful way to track valuable assets like U.S. dollars - and trading out U.S. dollars for transactions that aren't yet in the block chain history!

Obviously, to prevent the pay-out for aborted transactions, the exchange needed to wait until the transaction is confirmed before paying out. But, there's no way to guarantee that a transaction will ever get into a block history. It might never get confirmed, and might need to be retried. So, the exchange is stuck between a rock and a hard place: people who want to withdraw U.S. dollars either have to get the money prematurely, or risk getting the money weeks or months late, or never. Financial regulators don't allow banks to delay customer withdrawals indefinitely like that - because that behavior is indistinguishable from a bank who is embezzling its own customers' money! So, the exchange had to pay out for un-confirmed transactions.

The part that astonishes me is the insistence that this protocol is somehow "secure." Security isn't guaranteed by loads of cryptographic math. Even if the math were flawless and the code were bug-free, security evolves from a trust-relationship, not from any specific technology. Nimur (talk) 16:13, 9 March 2014 (UTC)

You say "loads of cryptographic math" is not sufficient to guarantee security, which is true of course, yet you explicitly and incorrectly blame technical details of the protocol in your post. Transaction malleability, which Mtgox implicated in their filing, exists because of some technical details of Bitcoin's design that are tricky to fix for backward-compatibility reasons. It's not a necessary part of how cryptocurrency works. You seem to be confusing it with Bitcoin's decentralized commitment to transactions, which is an important part of the design. Obviously, if the decentralization made it impossible to reliably avoid double payment as you suggest, no one would trust Bitcoin. But it doesn't. The bitcoin at an addressoutput has to be spent all at once and the output is never reused, so if the recipient claims that that transaction failed, you can safely initiate a new transaction spending the same output, knowing that at most one of them will commit.

The form of "money" involved is barely relevant here. Mtgox is apparently claiming that their transaction processing code had a bug that could be exploited for double payment. The bizarre thing is that this bug would leave a discrepancy in their ledger at the end of the day, yet they apparently never noticed, or noticed but didn't bother to do anything about it, for years. An alleged leaked internal document says "the cold storage has been wiped out due to a leak in the hot wallet" ([4]), which would appear to mean that the "till" was coming up short every day, and their response was to keep refilling it from the "vault", not noticing, or not caring, that the contents of the vault were gradually shrinking. The only special property of Bitcoin in this story is that it's not legally money, so Mtgox's incompetence in handling it might not be criminal (I'm not saying it wasn't, just that it's less clear). That's assuming that they're telling the truth about what happened—but I think they couldn't come out looking much worse no matter what really happened. -- BenRG (talk) 19:14, 9 March 2014 (UTC)

Problems with USB hard drive

I have two identical LaCie 1 TB USB hard drives, which I use to backup all my photographs with rsync. I alternate between the two drives when making backups. Lately I have discovered that one drive works much more slowly than the other. I took about 2000 photographs in the last week or two, and when I backed them up on one drive a couple of days ago, it took about twenty minutes. Now I'm backing them up to the other drive, and the rsync backup has been running for almost two hours, and isn't even half-way through yet. What could be wrong with the drive? Can I somehow fix it? Would running fsck on it help? JIP | Talk 19:56, 6 March 2014 (UTC)

Are they plugged into the same port (alternately) or are they on different ports and you just rsync to them alternately? It may be that the apparently fast disk is plugged into a USB2 port and the apparently slow one is plugged into a USB1.1 port; if this is the old Athlon computer you asked about in another question, it may have some usb1.1 and some usb2 ports. Also, what filesystems does mount report for each (not necessarily what filesystem you think they're formatted for)? -- Finlay McWalterჷTalk 20:39, 6 March 2014 (UTC)

They're plugged into different ports. I have an automatic script that detects whichever drive is currently powered up, mounts it, runs the backup and unmounts it. But I believe the ports are identical. This is the same computer as in my previous question. I think I have formatted both disks as ext3, but I'll have to check in the morning. I'll have to let the backup run its course first. JIP | Talk 20:44, 6 March 2014 (UTC)

The nice thing (well, one of the many many nice things) about rsync is it is interruptable; you can safely ctrl-c it and then resume it and the only duplicated effort is redoing the file it was working on. -- Finlay McWalterჷTalk 20:46, 6 March 2014 (UTC)

You can test performance with something like time dd if=/dev/zero of=/mnt/somedisk/foo bs=1024 count=4096K and compare the results for the different disks. Strictly this blurs the distinction between the disk+interface and the filesystem (you could destructively write to /dev/somediskid instead, but you'd zap your partitions and data) but mostly filesystems will pass big block writes through pretty efficiently. And obviously it's a good idea to check the SMART data (sudo smartctl -a /dev/sdX), as a disk that's dying may start to run very slowly. -- Finlay McWalterჷTalk 20:59, 6 March 2014 (UTC)

Here is what mount reports for both drives: /dev/sdb1 on /lacie type ext3 (rw,nosuid,nodev,noexec,relatime,seclabel,data=ordered,user=jip). The dd reports show a drastic difference, almost 20 times:

4194304+0 records in
4194304+0 records out
4294967296 bytes (4.3 GB) copied, 178.655 s, 24.0 MB/s

4194304+0 records in
4194304+0 records out
4294967296 bytes (4.3 GB) copied, 3577.11 s, 1.2 MB/s

It appears that one drive is either becoming broken or has its filesystem in a broken state. I'll have to try the smartctl check too, and also do the same checks again after swapping the cables, to see if the ports are any factor in the problem. JIP | Talk 17:38, 7 March 2014 (UTC)

If you haven't swapped the cables, you can't assume one drive is to blame. If you haven't done smartctl, you can't assume that one disk is failing. -- Finlay McWalterჷTalk 11:46, 8 March 2014 (UTC)

I decided to run fsck on the slow drive. The process has been running for over three hours now, and is still saying: "Pass 1: Checking inodes, blocks, and sizes". How many passes are there going to be? JIP | Talk 10:29, 8 March 2014 (UTC)

If a disk has a hardware defect, you shouldn't fsck it, because more activity is just going to risk making things worse. fsck.ext3 has five passes, but the first is overwhelmingly the time consuming one, taking ~90% of the time. -- Finlay McWalterჷTalk 11:46, 8 March 2014 (UTC)

I did run smartctl before fsck, but it didn't report any problems for either drive, so I decided to run fsck anyway. The first pass finished in six hours, all the other passes in about ten to twenty minutes. It didn't report any problems either, but it did report 35% non-contiguous files. I swapped the cables, and the problem turned the other way around - the fast drive and the slow drive switched places. Then I plugged the drive that was now slow into another port, and it also reported over 20 MB/s transfer speed. I'll keep it this way now for a few days and see if it has fixed the problem. JIP | Talk 16:13, 8 March 2014 (UTC)

With both drives connected, run lsusb -t and will will display the usb hierarchy; it sound to me like the "slow" disk is on a port on a usb1.1 hub. You can see the specifics of all usb devices, including hubs, with lsusb -v where the bcdUSB field shows the speed each device and hub supports. Remember that all ports hang off a hub, even the computer's built-in ports (they're off a hub that's built into the USB host controller in your computer's southbridge). -- Finlay McWalterჷTalk 17:39, 8 March 2014 (UTC)

Here is what lsusb printed out:

Rather long output copy-pasted.
The following discussion has been closed. Please do not modify it.
$ lsusb -t /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ohci_hcd/10p, 12M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/10p, 480M |__ Port 1: Dev 32, If 0, Class=stor., Driver=usb-storage, 480M |__ Port 5: Dev 2, If 0, Class=>ifc, Driver=rtl8187, 480M $ lsusb -v Bus 001 Device 032: ID 059f:1018 LaCie, Ltd Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x059f LaCie, Ltd idProduct 0x1018 bcdDevice 0.01 iManufacturer 10 iProduct 11 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Bus 001 Device 031: ID 059f:1018 LaCie, Ltd Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x059f LaCie, Ltd idProduct 0x1018 bcdDevice 0.01 iManufacturer 10 iProduct 11 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xc0 Self Powered MaxPower 2mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 6 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Bus 001 Device 002: ID 0bda:8187 Realtek Semiconductor Corp. RTL8187 Wireless Adapter Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x8187 RTL8187 Wireless Adapter bcdDevice 1.00 iManufacturer 1 iProduct 2 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 39 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 0 (Defined at Interface level) bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 5 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0002 2.0 root hub bcdDevice 3.09 iManufacturer 3 iProduct 2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0004 1x 4 bytes bInterval 12 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass 9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize0 64 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice 3.09 iManufacturer 3 iProduct 2 iSerial 1 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255

JIP | Talk 18:02, 9 March 2014 (UTC)

Google vs. Firefox

This is a very specific problem that I'm not sure can be answered but if anyone has some ideas. On my laptop I have Ubuntu and Windows 7 while the desktop has Windows 8. My son has 7 on his laptop and the grandson has 7 on his desktop. Sometimes when using FF Google can't be reached and all that comes up is a blank "New Tab". Other times it works fine. On the other had Chrome will always go to Google search. This only happens at home as when we take the laptops elsewhere Google is fine with FF. Any ideas as to where I should start looking? CambridgeBayWeather (talk) 20:05, 6 March 2014 (UTC)

Are you saying you have the same problem on all machines? I would start by checking your settings at Firefox > Tools > Options > General.--Shantavira|^{feed me} 09:15, 7 March 2014 (UTC)

Yep it's all four machines. There doesn't appear to be anything out of the ordinary in the general tab. My two have about:startpage but I never open on that. This is more about when using the search or address bar. CambridgeBayWeather (talk) 15:15, 7 March 2014 (UTC)