Have you paid the import tax? It'll sit forever until you do.  Huh? I thought BFL paid the import tax. I've not heard of anyone in the UK having to paying import tax on BFL items. Expect to pay import VAT (20%) at a minimum. I think I had a small amount (like 1% or so) import duty on top of that. Plus the ParcelForce customs processing fee, of course. They'll contact you with details of how much to pay but it will take a few days. Expect the whole process to take around a week - maybe a little more. roy |
|
|
|
I don't think, that it is possible for a simple mass storage device to infect a pc just by plugging in (and not reading and interpreting any data on it). The circuit to read and write data on the drive is hardwired and can't be manipulated by software (correct me if I'm wrong). This should be true for the USB host interface in the mainboard, too. So as long as there is no data transfer it is impossible to infect anything. Things might change if data is transfered. However, even then, the hard wired host interface or the kernel code which handles the usb frames must be compromised by a malformed usb frame. This however should be prevented by the hard wired circuit on the drive itself.
Don't get me wrong, I think it is perfectly believable, that a system can be compromised by its USB subsystem. This has been demonstrated with the PS3. However, a special USB frame had to be crafted for this to happen. A simple mass storage device could not do this.
Yes, but a whole bunch of USB frames get exchanged when you plug a device in, to identify the device. As you say, a specially crafted USB frame could trigger a buffer overflow in the USB stack. (ETA: That's more a risk with a specially designed malicious device - it's less likely a standard USB stick could be made to do this.) Still, if you're going to dedicate an offline machine to Armory, then I think it's a reasonable precaution to spend a couple of extra bucks to buy a couple of brand new USB sticks and use them exclusively for moving Armory transactions about. Doesn't completely remove the risk, but is a good way to minimize it. |
|
|
|
Should I be concerned that vanitygen is a multi-threaded OpenSSL-based application that doesn't seem to call CRYPTO_set_locking_callback ?
Ah, maybe it gets away with it because the non-threadsafe calls to OpenSSL are inside other locking anyway.... |
|
|
|
|
Should I be concerned that vanitygen is a multi-threaded OpenSSL-based application that doesn't seem to call CRYPTO_set_locking_callback ?
roy
|
|
|
|
The paper does not consider multiple selfish mining pools fighting against one another.
They do say, in section 3.2: For simplicity, and without loss of generality, we assume that miners are divided into two groups, a colluding minority pool that follows the selfi sh mining strategy, and a majority that follows the honest mining strategy (others).
It's not immediately obvious to me how such an analysis could be without loss of generality, though. roy |
|
|
|
Would I be right in thinking that this attack is made easier by Bitcoin's rather relaxed approach to timestamps?
No. Timestamps don't come into this at all. (And most suggestions to tighten timestamps result in (usually minor) vulnerabilities) Ok, in the general case no.... And maybe the third bullet point was ill-advised. But favouring blocks with an accurate timestamp in the event of a near tie in block arrival time.... surely that makes premining hard - since if you're premining you don't know the time you will want to publish the block. ETA: It's not a complete fix, of course. It's an attempt to set gamma close to zero - meaning you can't get any advantage from selfish mining without 33% of the hash rate. |
|
|
|
Would I be right in thinking that this attack is made easier by Bitcoin's rather relaxed approach to timestamps? What would happen if we were to: - Use NTP-synchronized local clocks (most cryptographic protocols require this, after all)
- In the event of two new blocks received within, say, 10 seconds, prefer the block with the best timestamp (where a timestamp is better the closer it is the the local clock, except that timestamps more than, say, 2 seconds in the future are always regarded as worse than timestamps that are not)
- (Possibly) Refuse to relay blocks with a timestamp more than 2 seconds in the future
This would make it very hard for the attacker the win the race - essentially it means mining for immediate broadcast gives you an advantage in the race. roy ETA: Obviously the 2 and 10 are arbitrary, and not necessarily the best values. The '2' is a future fuzz value. Clearly you should never see anything from the future, but you want to make allowance for (small) clock errors, even if you are synchonising clocks (although NTP should synchronize within a few tens of milliseconds at worst). The 10 second value is related to the network propagation time - it needs to be long enough that you will always have seen both blocks in the attack scenario. But you don't want to make it too long as during this window someone can mine a new block and force you discard an existing, valid one. |
|
|
|
Their proposed solution, which is offered without extensive analysis, is to relay all blocks, even late ones, and then choose the preferred block in ties at random. Ignoring collateral vulnerabilities which a hasty implementations of forward-all might create, I believe this proposal has a problem in that it creates a selfishness advantage even without any sybil attack at all, so long as the selfish miner has enough hashrate.
But even without their fix, and assuming gamma=0 (i.e. the selfish pool never wins a block propagation race) then if I'm reading it right the authors' result purports to show that a pool with enough hash rate (more than a third of the total hash power) still has a selfishess advantage, which gets quite substantial as the size of the pool grows larger than that. (Not that I'm particularly supporting their change - just questioning the implication that could be drawn from your post that with the protocol as it stands today it's not possible to gain a selfishness advantage without mounting a sybil attack.) roy |
|
|
|
BTW, any plans to add BACS/FPS support for those of us in the UK? UK bank accounts don't always offer SEPA - and those that do generally charge fees for it. I guess that would mean supporting GBP though.
(Sorry if this has already been discussed - this thread is a bit long)
We do want to add GBP support. It's mostly a matter of finding a bank that will do it. But there's also an issue about whether we'd add GBP pairs or not. It'd be cool to have them, but it might fracture the already thin volume, so I think it'd be better if we could add GBP by way of a good GBP/EUR exchange rate, at least initially. I'm perfectly happy to use GBP (or EUR if I have to) to access whatever the most liquid market is (and if it's USD then so be it). Have you considered running a single multicurrency orderbook for each digital currency (i.e. like on Gox where any XBT buy order can match against any XBT sell order, regardless of the fiat currencies the orders were placed in). In this way the less popular fiat currencies still access the same liquidity pool. roy Yeah, I like that way of doing it, but I'm not sure how easy that would be to implement for us. I'll add it to my list of ideas though. Order matching gets complicated, I think, because one ( or both?) parties might end up paying a currency conversion fee for the (parts of) of their order that are matched against an order in a different currency - but presumably this should only ever happen where this is more advantageous then matching against orders in the same currency. It's not at all clear to me whether it's possible to come up with a well-defined definition of how this should work (although presumably it must be, since I believe Gox does something like this). ETA: The nice aspect is that, if done right, then worst case I'm no worse off in terms of fees than if I'd been forced to convert my GBP to EUR before buying XBT - but if I'm lucky and the native XBT/GBP liquidity is there I might do slightly better. |
|
|
|
BTW, any plans to add BACS/FPS support for those of us in the UK? UK bank accounts don't always offer SEPA - and those that do generally charge fees for it. I guess that would mean supporting GBP though.
(Sorry if this has already been discussed - this thread is a bit long)
We do want to add GBP support. It's mostly a matter of finding a bank that will do it. But there's also an issue about whether we'd add GBP pairs or not. It'd be cool to have them, but it might fracture the already thin volume, so I think it'd be better if we could add GBP by way of a good GBP/EUR exchange rate, at least initially. I'm perfectly happy to use GBP (or EUR if I have to) to access whatever the most liquid market is (and if it's USD then so be it). Have you considered running a single multicurrency orderbook for each digital currency (i.e. like on Gox where any XBT buy order can match against any XBT sell order, regardless of the fiat currencies the orders were placed in). In this way the less popular fiat currencies still access the same liquidity pool. roy |
|
|
|
|
BTW, any plans to add BACS/FPS support for those of us in the UK? UK bank accounts don't always offer SEPA - and those that do generally charge fees for it. I guess that would mean supporting GBP though.
(Sorry if this has already been discussed - this thread is a bit long)
|
|
|
|
I understand - margin trading is turned off by default for all trades. You have to toggle a button to turn it on, so it'd be pretty hard to do by accident I think. I don't think there's any liability issue involved with a settlement period, but I'll check on this.
I was imagining something like, I accidentally buy 10,000 bitcoins when I intended to buy $10,000 worth of bitcoins. And I get greeted with a message saying "Trade executed - please deposit $2,000,000 by close of business on 31 October in settlement" :-) I'm pretty sure in reality something like that could never happen. Thanks for all the other info. I've signed up now, and will add a yubikey some time soon. roy |
|
|
|
Still, can't you achieve something very close to what you want by allowing Armory to accept wallet encryption data from a USB key, and then applying FDE with a conventional passphrase?
Actually, how about this as an interesting variant: Allow offline Armory to access the wallet entirely off a USB drive, with no sensitive data ever hitting the hard drive of the offline computer. The obvious use case would be that the wallet is always kept in a safe deposit box, and you take the laptop with you to the safe deposit facility when you want to sign a transaction. This would reduce the exposure of the holder of a large wallet to being coerced into making a large transaction. The risk would then be not much worse than with a conventional bank account (i.e. the wallet holder would still have to visit a financial institution in person to obtain the wallet). This above works better than keeping the offline laptop in the safe deposit box because: - A safe deposit box large enough to put even a small laptop in is rather more expensive than a safe deposit box large enough to put a USB key in (although a holder of a large wallet might not be too price sensitive here)
- Although safe deposit facilities usually have private rooms within the facility where you can consult documents, etc, if you keep the laptop in the safe deposit box then you're reliant either on there being an available power socket in the private room, or on carrying a spare, charged battery (since the battery of a laptop kept in the safe deposit box would inevitably run down)
|
|
|
|
Many encrypted OS solutions also encrypt the swap, and doing so will disable suspend/hibernate. I recommend using that option. Alternatively, it should be possible to setup the offline system without swap. It will complain during installation about how important it is to have a swap partition, but I think it usually lets you do it anyway. Given how little resources are needed for the offline system, I wouldn't think twice about disabling swap. But I haven't actually tried this.
Actually, I thought Windows hibernation worked fine with Truecrypt FDE. Restoring from a hibernation goes through the normal boot process, so the key is prompted and the driver loaded just like for a normal boot. Some systems are nasty, though - e.g. OS X FileVault 2 FDE caches the keys in the EFI BIOS storage before suspending. (But then FileVault 2 also really, really wants to use your account login password as the FDE passphrase, too - despite most people not using account paswords that are long enough to be ideal for FDE.) ETA: It's hard, but not impossible, to set up FileVault 2 securely. I could provide some pointers if anyone is interested. Still, can't you achieve something very close to what you want by allowing Armory to accept wallet encryption data from a USB key, and then applying FDE with a conventional passphrase? roy |
|
|
|
Your wallet on the computer is already protected with a password, and using the same password for the disk encryption is mostly redundant (though it's better than nothing).
I disagree. It protects against problems with sensitive data getting accidentally written to disk (swap files, hibernation files, etc). I think best practice should be to use full disk encryption on the offline computer, even if Armory takes the best precautions it can to prevent such problems. I know it's possible to /dev/random data on a USB key, and have the bootloader use that as the FS encryption key. But it's been a long time since I've done that, so I don't remember how.
It will improve the "hardness" of the system if it is stolen, as long as you don't keep the USB key with the laptop. If they don't have the USB key, there's basically no way to even brute force the FS encryption. If the thief gets both the key and the system, well there's still the wallet password that has to be found (unless you wrote the unencrypted key data to disk; which should not happen with standard Armory operations, but it's nice to have the extra layer of protection).
If anyone has more details about doing this, I'd love to be reminded. I've been meaning to upgrade one of my offline systems to that method, but been too busy to go figure it out again.
If you're confident that the swap/hibernate problem is not a major problem, then surely you can solve the problem entirely within the Armory code. Just introduce an option to allow the wallet encryption key to be provided on a USB key. roy |
|
|
|
It appears that the standard terms and conditions require me to agree to terms relating to margin trades. Is it possible to open a non-margin account?
roy
Every account will be eligible for margin trading when margin trading becomes available, so we don't offer non-margin accounts. But margin trading wouldn't come up for you as an issue unless you chose to margin trade - it's entirely optional. And margin trading is currently disabled until we have more volume on the exchange. Trading accounts that can result in a liability exceeding the funds deposited always make me nervous, I'm afraid. It looks like I can use a yubikey, which would help reassure me against the risk of liability resulting from unauthorized margin trades... I just hope it's not going to be too easy to accidentally create a margin trade, though. (ETA: or any other trade which creates such liability, such as a trade with T+2 settlement.) roy |
|
|
|
|
It appears that the standard terms and conditions require me to agree to terms relating to margin trades. Is it possible to open a non-margin account?
roy
|
|
|
|
No command line options, everything is inside the ~/.cgminer/cgminer.conf
Oh, thanks, Pontius - I'd not even known that one can set arbitrary options in the conf file. That's just made my life complete roy |
|
|
|
I run BBF at 265 at 950mV!
Yeah, everyone's boards are different. I'm starting to realise you do need to run for quite a while to get an accurate picture of HW error rate so maybe I can drop it a little more.... But pretty sure my HW rate will be through the roof if I drop as low as 950mV. roy |
|
|
|
|
Show Posts
