By the way, interesting lesson for you, I didn't even learn about it until sometime last year: the for-else loop in python.
Yes, it is weird. Useful, but weird. I vaguely remembered that it did something else than one would expect, the obvious expectation being that it gets run if the loop does not (iterates zero times). That is what I would expect from the syntax: loop over this, else do that. Instead, the else syntactically binds to the "for" loop, but its semantics binds to the "if ... break" inside it. Arguably far more useful, but one of the extremely rare cases in Python where a language construct does something else than the obvious. Thanks for your quick reply! |
|
|
|
Hi, Got the newest Raspbian for my Pi, and tried to install the 0.91.2_testing offline bundle. I finally managed, but along the way I ran into no less than four errors: 1. The install script does not work, it claims that the installer is not found. The problem is these lines: installer = None
for fname in os.listdir('.'):
if fname.startswith('armory'):
installer = fname
else:
print 'No installer found!'
exit(1)
Replacing "else" with "if installer is None" fixes this problem. 2. The file libmysqlclient18_5.5.33+dfsg-0+wheezy1_armhf.deb is empty! I had to download it from the Raspberry repository (where I found a slightly newer version, and needed the corresponding myqsl-common package 3. The script crashed on the line execAndWait('gksudo tar -zxf %s -C /' % installer)
where gksudo complained that there is no -z option. This makes little sense, perhaps it was really tar that was complaining?? 4. The tar file installed in the line above is not correct. It installed everything in /armory_0.92.2_raspbian_armhf/usr instead of in /usr I manage to install it by doing the steps of the script manually (using sudo instead of gksudo), transferring the missing .deb files from step 3, and moving the contents of /armory_0.92.2_raspbian_armhf/usr into place. I then confirmed that Armory started as it should. I will create an offline wallet tomorrow, it is past my bedtime  I should say that even with these errors, the offline bundle saved a lot of time for me! Thank you, Alan and co. |
|
|
|
This script requires making a fresh VM of the same OS,
Just out of curiosity: What do you use for the Raspberry Pi offline bundles? A VM/Emulator, or just another Raspberry Pi? |
|
|
|
Sorry for reopening this thread! If i make a normal backup with itunes, it will save my google authenticator codes?
Yes, I think so. You might want to select something about backing up app data. I haven't done it myself, but I have had many apps, with data backed up. BE CAREFUL: It will save your GA codes encrypted in a way so they can be restored ON THE SAME PHONE ONLY. If you lose your phone, you cannot restore as far as I know (although admittedly I have not tried). Write down the secret keys as you install them in GA, you cannot do it later. |
|
|
|
|
What is the recommended offline bundle for a Raspberry Pi? The 0.92.1 on the website; the 0.92.2-testing version posted here; or a newer version? I plan to set up a new offline computer for long-term storage.
|
|
|
|
Your setup is not secure at all. The greatest risk is not theft, but that your monitor catches fire and destroys both the paper backup and the harddisk. I am serious! Although theft is a possibility too. Paper wallet security has two aspects: the risk of theft and the risk of accidentally losing the wallet. Both are real, but the latter is probably the most common. A single paper backup in your home is pretty secure against theft, as most thieves will not sift through your "worthless" papers. But you are vulnerable to fire or other accidents ruining both the computer and the backup. Several copies of the backup helps, but now the risk of theft goes up. Don't store an extra copy in the office if you constantly tell your colleagues how great bitcoins are. The N-of-M backup is the most flexible. Good ways would be a * 2-of-3 with one copy in the home, and two copies with people you trust. Now they need to conspire to steal your coin (and no need to tell them where the other copies are). If one of them is careless and loses his copy, too bad. This is what I do. * 3-of-5 with one copy in the home, two in a safe in the bank, and two copies with trustworthy friends (or even one in the office, one with a friend/family). Now you can restore even if both your friends lose their copies. And neither your friends nor the bank can take your bitcoin. Of course most of us do not have the amounts of bitcoin requiring this kind of care. Unfortunately. How NOT to do it: A 6-of-6 backup, stored in six safe places. No-one can steal your coins, but if just a single copy is lost, all is lost. TL;DR: Make a mental list of good, independent (= not likely to burn in the same fire) places to keep your backup, and make an N-of-M backup accordingly. |
|
|
|
Just re-released 0.92 as 0.92.1.
Do I understand correctly that upgrading from 0.91 would require upgrading the offline wallets too? If that is the case, please put a warning on the website, upgrading the offline Armory may be significant work depending on the setup. I for one plan to wait till the dust has settled. I know that no new changes are expected in the communication protocol, but there will probably be many bug fixes. |
|
|
|
|
On the bottom of your main page, there are links to descriptions of most futures contracts, but BTCUSD-12.14 is missing.
|
|
|
|
We should always be aware that Bitfinex is not the only site for margin trading, there is also icbit.se, although their futures-based system takes some effort to understand. It is always worth it to compare the swap rate at Bitfinex with the contango at icbit. Right now their contango is equivalent to 0.13 %/day. You need to factor in that icbit has low volume and no stop-loss mechanism, you risk to get caught in an unfavourable position. On the other hand, the price spikes are smaller (and on purpose limited within a trading period), so they do not have the problem of sudden spikes that can trigger stop-losses in a way you regret later.
I think a bit more competition between the two sites would benefit us all.
We should always be aware that Bitfinex is not the only site for margin trading, there is also icbit.se, although their futures-based system takes some effort to understand. It is always worth it to compare the swap rate at Bitfinex with the contango at icbit. Right now their contango is equivalent to 0.13 %/day. You need to factor in that icbit has low volume and no stop-loss mechanism, you risk to get caught in an unfavourable position. On the other hand, the price spikes are smaller (and on purpose limited within a trading period), so they do not have the problem of sudden spikes that can trigger stop-losses in a way you regret later.
I think a bit more competition between the two sites would benefit us all.
Are you kidding me? Ente He forgot that he was logged into his sock puppet  I am not RDMINER. He must have copied my post - or tried to quote me and messed up. |
|
|
|
Simply put, while the you appear to be running a full node, you actually aren't, as you are missing block data. That does not sound right. Bitcoin-QT / bitcoind should be verifying its own data, so if block data is missing that verification should fail. Is the problem not rather that there is extra (defective) data in the local copy of the blockchain which is being ignored by bitcoin-QT / bitcoind but not by Armory? |
|
|
|
Remember, whenever you try a new wallet, place only a few milliBTC in it and test that you can spend them again. Move a tiny amount back and forth until you know the program. Delete your wallet with a tiny amount in it. Restore from backup and verify that the money is still there. Once you trust that it works reliable, dump your life savings in the program |
|
|
|
|
I have the same experience as PirateHat. I explicitly make a bid that matches an existing offer, and still don't get it. I suspected that it was rounding errors on the rate, and bid 0.001% more than the offer, still no match. After a while, the bid was met, though. I cannot reproduce it on demand, sometimes things work, sometimes they do not appear to work.
|
|
|
|
|
We should always be aware that Bitfinex is not the only site for margin trading, there is also icbit.se, although their futures-based system takes some effort to understand. It is always worth it to compare the swap rate at Bitfinex with the contango at icbit. Right now their contango is equivalent to 0.13 %/day. You need to factor in that icbit has low volume and no stop-loss mechanism, you risk to get caught in an unfavourable position. On the other hand, the price spikes are smaller (and on purpose limited within a trading period), so they do not have the problem of sudden spikes that can trigger stop-losses in a way you regret later.
I think a bit more competition between the two sites would benefit us all.
|
|
|
|
Derp. Forgot about the RPi build. I don't know if it'd work out of the box on the OP's computer, though. The OP could certainly try and see what happens. I would be surprised if it works out of the box - it is a raspbian build, and I do not know what that implies. But it means that OP could most likely build it himself, if he has the inclination and the knowhow. |
|
|
|
It only costs €2 per month to have a dedicated IP where I live.
And €2 is definitely worth it.
There have been cases of people having their static IP changed anyway. Typically some error on the ISPs side. Be prepared to have a secondary way to access your account if this happens to you (or your ISP goes broke, or you change ISP, or you suddenly need to move, or ...) |
|
|
|
Actually, I need to go back and edit what I wrote earlier. Armory may not run on the netbook after all. You have an ARM processor. Armory doesn't distribute a build that runs on an ARM processor. You could download the source code and try to compile Armory. I don't know if that would work.
Armory runs on a Raspberry Pi, at least older versions do (I have not upgraded the offline computer for quite a while). I think it has an ARM processor, so probably it will work. Of course, buying an x86 based computer is a safe bet. |
|
|
|
Online computer -> Create Transaction -> Load to SD card
Virus transferred from online computer to SD card 1 Put SD card on read only
Offline computer -> Enter SD card -> Load transaction to harddrive
Virus transferred to offline computer -Remove read only SD card
-Enter different SD card than the one used before to the offline PC
Offline PC -> Sign offline transaction on the new SD card (the one that came from the old read only sd card)
Virus transferred to SD card 2, now with the private keys. Take out SD card, put it on read only again
Insert it in the online pc, broadcast.
Virus transfers all funds to evil hacker. --------------------------------------------------
This would eliminate the risk of malware being able to write directly to the potentially infected storage device. What do you think?
I think this scenario of infected SD cards / USB sticks and custombuilt malware is so unlikely that one should not worry about it. But I cannot see that read-protecting the cards help at all (even if read-protecting was actually read-protecting and not just a software hint). |
|
|
|
So, what would be more secure, an "airgapped" usb-stick, which would be the only thing ever touching both the offline and online computer, or a direct connection via serial cable? How about a network connection, but the only service reachable on the (formerly) "offline" computer is a locked-down ssh daemon? The "offline" computer obviously wouldn't be airgapped nor offline, but the attack vector might be much smaller than with usb?
Ente
The serial line is probably as safe as it gets. The direct network connection would make me worry, it seems far far more risky than a USB. In particular if you only use your own USB stick that is never used for anything else, and a different OS on the online and offline computer. Theoretically, someone could write a USB virus to infect just the particular setup you are using, but if they go that specifically after you the " rubber hose attack" seems far easier to pull off. Any network connection will be vulnerable if there is a bug in the TCP stack or in the libraries the locked-down ssh demon uses (OpenSSL?) Edit: spelling |
|
|
|
I would be suspicious of your install. I use Avast! and I have never gotten any warnings for either Armory or Bitcoin-Qt. Make sure you are installing from official sites.
It was not the install that gave the false positive, but the blockchain data. And I have only heard about Microsofts own antivirus falsely detecting it. Either avast and the other don't use exactly the same signature, or they do not scan the blockchain data files (scanning them makes no sense anyway, since they are not executed). |
|
|
|
|
Show Posts
