It's for people to resist the temptation of re-using the "offline" system for other things. After all, it's a general computer and that's pretty expensive to have just sitting in a corner holding a wallet.
This is why I recommend using an ancient about-to-be-junked laptop. I got a throwaway from work for free. You can get something on ebay or craigslist for about $50. Anything with 256 MB of RAM or more will run Armory in offline mode. Most users will have no interest in using a slow-as-dirt laptop that can hardly load a browser, for anything else but cold storage  I think you may under-estimate how secure a good old fashioned network connection can be. If you are careful to avoid buffer overflows and other parsing errors, the "offline" computer could just have an open network socket that receives signing requests.
The problem with this is that the online computer will likely need to have two ethernet ports (unless it uses wifi for its primary connection). But, it's an excellent suggestion: ethernet is obviously well-supported on all systems, and if it's easy enough, I could just do it for the users that can use it. I just have to do some work to figure out crossover cables and initiating connections, exchanging, etc (I've never done much networking like this before...) |
|
|
|
^ Is there a stable Linux version to put on an offline machine somewhere? I can only see instructions on building from git with Linux. Is this as good as the official releases?
Yes, the master branch is always the latest, stable, release. By running those six commands while internet connected, Armory will be fully ready to run. If your computer started as an offline computer, then you might have to move some packages over -- I know there's a way to provide a list of packages on the CLI and it will download all of them plus dependencies, to be taken to an offline computer, but I don't remember what it is. Alternatively, you could compile it on any system of the same architecture, and then transferred (really, the only thing that needs to be compiled and transferred is the _CppBlockUtils.so and CppBlockUtils.py). I was overly concerned about binaries being a hassle to produce and then ultimately not working on all Linux systems. But now I see that creates a problem for those that would use Armory on an already-offline Linux system... I'll see what I can do about packaging up the linux stuff, one for 64-bit and one for 32-bit, and others can try it and report whether it works. |
|
|
|
Hi etothepi, I just tried my first offline broadcast (0.55 online PC, 0.50 offline PC) and happy to say it worked perfectly I did get a message that the txn had not been broadcast to the network, but I instantly saw the txn reported by the wallet I sent it to so I know it worked. Well done, very impressed Fantastic! Update your online Armory to 0.56 (just released yesterday) and the send-tx error will go away. I'm so happy to see more people trying it out -- and especially having it work! |
|
|
|
A quick overview of Armory's offline wallets to setup the discussion for how to improve it (and for those that aren't familiar): Setup Offline Wallet:(1) Create a wallet on a never-to-be-connected-to-the-internet-again laptop (2) Create a watching-only-copy of the wallet (no private keys), copy to online computer via USB key (3) Generate addresses and receive/verify payments online the same as any other wallet, but cannot send (and neither can an attacker) Spending Bitcoins:(1) Create a transaction like normal, but "Send" button is disabled, instead "Create Unsigned Transaction" (2) Save unsigned transaction to USB key, take it to offline system (3) Review transaction and sign it, and take it back to online system via USB key (4) Broadcast! This is the concept of "cold-storage", using BIP 0010 and a USB drive to initiate outgoing transactions. So far the offline wallets interface in Armory has been delightfully successful! And I believe it is two orders-of-magnitude better security than maintaining a wallet connected to the internet! But it's not 100% security . A very specialized USB autorun-based virus could compromise the offline system, getting it to sign different transactions than the user thinks he's signing, or copying private keys to the USB device and transmitting back to the attacker when connected online again. Let me be clear: I believe that this attack vector is very complicated and difficult to execute, but it's theoretically possible. And if it ever happens, it will be because USB drivers and behaviors are complicated and vulnerable. If you think Linux doesn't have these vulnerabilities, think again. (for those using offline wallets, I suggest looking up ways to disable autorun/autoplay on both computers to minimize this risk, especially the offline system -- here's one useful action you can take) Improvements: I believe that we can achieve 100% security (under the assumption that the wallets and software were setup securely), but we'll need a medium that can transfer the data between computers without any risk of remote code execution. The transfer of data doesn't have to be secure (only tx data and signatures being transfered, no private data), and generally only moves a couple kB, but potentially up to 100 kB if it turns out to be an enormous sweep of a long-used wallet. It's acceptable for the transfer to take 30 seconds under the rare circumstances that a huge transaction is being transferred, but should nominally be less than 5s for a few kB. It also preferably be simple. If the user is confused by the process, they might just go to USB keys again, or skip offline wallets altogether. Here's a list of different "media" with pros and cons: - QR code + Webcams:
+ QR codes are easy to generate
+ Plenty of existing software for scanning QR codes
+ Many laptops come with webcam, and can also be purchased inexpensively
- Requires manually moving cameras and screens around to get QR codes into view
- QR codes may not hold enough data: may need to use multiple codes
- Need to design webcam-based UI, with feedback and possible UI for flipping&scanning multiple QR codes
- Webcam support on all platforms is flaky (but it could be up to the user to get their webcam supported) - Infrared (IR) Tx/Rx:
+ Many laptops already have IR receivers (transmitters, too?)
+ IR tx/rx devices are ridiculously cheap
- Need transmit and receive on both systems, but might require manually enabling & disabling correct direction on each system (don't want a device rx'ing its own tx). This can be confusing
- May not be trivial to create custom IR tx/rx encoding/decoding, error correction, initiation, etc
- Bluetooth: (I know very little about how Bluetooth works: can it be setup solely for data transfer?)
+ Newer devices come with Bluetooth hardware, and drivers already included in OS
+ Data transfer should be fast
- Older devices will need Bluetooth USB device (or other interface to offline system)
- May allow remote code execution due to driver vulnerabilities
- Serial Ports:
+ Should transfer bits very efficiently without code execution risk
+ I believe that it could be coded cross-platform easily
- Most newer systems do not have serial ports - Audio Transmission (using direct audio cables: audio-out-to-mic-in):
+ Will transfer bits very efficiently without code execution risk
+ Cross-platform
+ May be able to use existing modem software/firmware
+ Would work with smartphone-to-smartphone, smartphone-to-computer, computer-to-computer
- Audio/signal processing might be a lot of work - Trusted Platform Module (TPM):
+ No need for offline system at all: all signing done on the device for which there is no functionality to read the private keys (can only sign data with them)
- Probably expensive to create a custom TPM device, supporting ECDSA and has a display for display and verification of transaction
- No flexibility to manage wallets & keys ... probably get to include one wallet ever (how does the wallet get on there?)
I would like to discuss various ways that this 100% security could be achieved, without requiring too much inconvenience for the user. But all solutions seem like mediocre ones. Perhaps the best solution is just looking up the most advanced ways to protect the offline system from autorun vulnerabilities and continue using USB keys (that's certainly the most convenient solution). But I don't know how much risk you can actually reduce this way -- you'll never know for sure whether it's 100%. |
|
|
|
Not working here, win7 /32bit, offline, with or without bitcoinind. /
Download link 64 bit not working (to try on win xp 64)
Looking forward to use this cool wallet asap
------------
Faulting application name: ArmoryQt.exe, version: 0.0.0.0, time stamp: 0x49180193
Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace5b9
Exception code: 0x40000015
Fault offset: 0x0005beae
Faulting process id: 0x1bac
Faulting application start time: 0x01cd00650e6dd98e
Faulting application path: C:\Users\bitcoin\Armory_Win32_0.56-alpha\ArmoryQt.exe
Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll
Report Id: 5298621d-6c58-11e1-be76-90e6ba122374
-------------
Ack! This is the second time my github links have failed. I updated the link on the webpage, and then also added a link to the download page: https://github.com/etotheipi/BitcoinArmory/downloadsAs for why it didn't work on Win32... do you have a blockchain file on that system? I recommend running with the --noblockchain option to make sure it doesn't even try to load it (which always causes a crash for me). I will be fixing that in a future update. (actually it will be fixed by just bringing down the RAM requirements...happening soon) |
|
|
|
Thanks, nice illustration. I think I've got it more or less working. Only struggling with the endians.
Endianness is a royal PITA in Bitcoin. I don't know if it helps at all, but I have a working implementation of merkle-root calculation here in C++ and here in Python. There doesn't appear to be any endianness switching in the calculations, so you just need to make sure the endianness is correct on the input and everything else show work out. |
|
|
|
Here's a diagram I created a long time ago when I was starting to illustrate BTC concepts for a presentation that I ended up not giving. The parent of two nodes (in the diagram) is created by concatenating the two child nodes (such as "0f3e32d0af34332d") and then hashing that. If a level has an odd number of nodes, you copy the last node. to make it even: i.e. if a level has 3 nodes: A, B, C, you just make it A,B,C,C and then carry on.  |
|
|
|
Home from vacation and a bug-fix release!I had introduced a nasty bug into Armory just before leaving for a week, probably causing all sorts of confidence issues for first time users. Those issues have been fixed! --Sending transactions work as expected (ledger updates immediately with number of confirmations) --Signing offline transactions no longer fails if there is a blockchain file on the offline system (weird problem, but fixed now) Thanks for your patience! Download the updated version 0.56-alpha at: http://bitcoinarmory.com/index.php/get-armory
|
|
|
|
Armory version 0.56 -- Bugfixes!- Fixed the send-tx bug -- you should now see transactions show up in the ledger as soon as you send them (no error)
- Fixed the problem causing an offline system to fail to sign tx if it has a stale blockchain file (yes, weird, but it's fixed now)
Windows 32-bit (md5: 1b3e2ccd0fa06d3ac62d578da33f4a1b) Windows 64-bit (md5: 779f18c1e3cdaa4aae898852b4b7aac5) Second bug is that both the messages blocks you've posted, that are supposed to verify that you made these messages, produce a dialog saying "The supplied signature is not valid!". There are no errors on the command line after doing this check. Both these messages fail to validate:
Now that I'm home, I'm following up on this bug report. Between 0.55-alpha-RC2 and 0.55 I updated the message signing interface to improve security a little bit. It necessarily broke previous signatures. I botched the previous signature block because it said 0.55 but was actually 0.55- RC2. I have a 0.55 signature block that will work, but there's no point anymore because I just released 0.56: -----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address: 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message: "Armory version 0.56 was released 2012-Mar-11 01:"
"07am. The Win32 zip file has the following md5s"
"um: 1b3e2ccd0fa06d3ac62d578da33f4a1b. The Win6"
"4 zip file has the following md5sum: 779f18c1e3c"
"daa4aae898852b4b7aac5. Please do not use zip-fi"
"les that do not have hashes that match the above"
" strings!"
PublicKey: 0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
7571cbe492a7222442b75df75b9a84
Signature: 92652a4f31be8f524a0fc00328fa7b0d496d30e217c2dc9c3d
05a6f8a08e620cea11f4c5486851e842d42cec76de1822a47e
17676836b0f5edf802cb336e0c9d
-----END-SIGNATURE-BLOCK--------------------------------------- Please tell me if that doesn't work. And I'm done messing with the signature block code, so everything after 0.55 should work.
|
|
|
|
Thanks so much Holliday! I'm glad you finally got it working. Then I followed the instructions to create an offline transaction. Creating and importing a watching only wallet was a breeze. I created the transaction and plugged the USB key into my offline computer.
This is where I ran into my second problem. The offline computer refused to sign the transaction. After sending a few message to etotheipi he figured out that I had a partial block chain on my offline computer and it was interfering with the transaction signing process. The partial block chain was from creating offline Satoshi wallets. Anyway, I deleted that per etotheipi's instructions and I was able to sign the transaction!
FYI: this problem is a bug Holliday helped me find -- if there is a blockchain file on the offline computer (~/.bitcoin/blk0001.dat) then it will load it and skip some other code that is needed for offline transactions. If the system is never going to touch the internet again, you might as well just delete the blk0001.dat file, or run setup your Armory shortcut with the --noblockchain option. (the blk0001.dat file is usually found at C:\Users\<username>\AppData\Roaming\Bitcoin\blk0001.dat on Windows, /home/<username>/.bitcoin/blk0001.dat on linux) I will be fixing this bug (along with the send-tx bug) in version 0.60, hopefully by the end of tomorrow. So, this "hack" will only be necessary until then. If there's anyone else who has successfully setup offline wallets and used them, please let me know. Up until now, Holliday is the only user who has given me direct feedback on it. |
|
|
|
way to go Holliday. you're doing what i want to do but haven't gotten around to.
can't wait to get my laptop eto!
cypherdoc, I'll work on the laptops first thing Monday. I didn't consider that my donors might want them ASAP I'm making a cumulative to-do list, and will have all of Sunday to test and fix everything I broke before I left. That'll teach me a lesson about releasing software before a vacation! I also will implement a more rigorous testing-checklist, to execute before every release. Unfortunately, there's a ton of features, so it's quite tedious to re-check everything, but I really need better quality control now that I'm marketing the app to a wider audience (hopefully it can avoid stupid things like transactions not sending properly, ugh). Thanks for your patience! -Eto |
|
|
|
So, for some reason my offline client does not think it has the private keys to sign the transaction.
Sad day  I wonder if the fact that it's an imported address has anything to do with it. It shouldn't matter, but it shouldn't behave like this either, so something is obviously awry. On the window where you load the unsigned transaction, isn't there a button in the bottom right corner that says something like "Click here for more information about this transaction" ...? Does it show you anything? I suspect there may be an error condition popping up, but if you are using the ArmoryQt.exe, there's no way to get that information. I've been meaning to implement a logging system for exactly this purpose, but up until now, I've always had pseudo-binaries and the errors popped up on the console window. (Maybe there's an ArmoryQt.exe.log?) Try one thing for me: generate a new offline address and send it 0.1 BTC. After it gets one confirmation, try to execute an offline transaction with that. I want to verify that the problem is an imported-address problem and not an any-address problem. I've executed dozens of offline transactions myself, but I guess I never did with imported addresses... they were always part of the wallet's deterministic chain. If you have the same problem, I probably injected yet another bug into version 0.55 before release (wouldn't be the first). If you feel like battling this further, the next thing to try would be version 0.51, which requires installing the extra packages and running ArmoryQt.py. Download the zipfile. Unfortunately, you'll have to install python-twisted ( 32bit or 64bit), run the zope script (included in zip file) and then the PyQt installer ( 32bit or 64bit). At least it can all be done without deleting 0.55, just close 0.55 before running 0.51. There's a good chance 0.51 will just work. And I'll have to debug 0.55 on my own. But if you get the same problem, you'll see an error on the console window popup. Thanks for your patience with this. Please continue this conversation via PM or email (etotheipi_gmail_com) and I'll feed the results back into this thread later. I'll be back on my development computer soon, and will get a chance to tackle all this stuff myself, soon. |
|
|
|
I knew it! (my girlfriend tells me I'm clairvoyant ) I know I'm sending you on a scavenger hunt here, but you can probably use the compiled CppBlockUtils.py and _CppBlockUtils.pyd found in version 0.51-alpha (when I still released pseudo-binaries): https://github.com/etotheipi/BitcoinArmory/downloadsDownload the zip file for 0.5.1-alpha 32-bit, and use the CppBlockUtils files from that. I bet it will work. If not... well you'll have to wait I think my first priority after getting back from vacation tomorrow will be fixing the send-tx/network bug, and then integrating this functionality into Armory so that it doesn't have to be a hacky script. Sounds like I better get permission from Joric to include his code as an "add-on" to Armory... Those two files did the trick! It seemed to import successfully. One step closer to offline transactions! Thanks. Great! I'm kind of surprised that it worked, but I guess there's no reason for it not to (meshing different versions of compiled code together frequently has unexpected behavior). Perhaps I'll add a migration-tool download for 32-bit... EDIT: I just added it to the download page. Download the Win32 wallet migration tool
One thing I noticed, and I'm sure it's been mentioned already, but it's a long thread and I figure no harm in mentioning it again. Mined transactions are showing as spendable as if they were a typical transaction.
Interesting. I definitely made an attempt to fix that, but I was never able to set up a test case for it, because I've never mined a block directly with with an Armory address. I bet this is P2Pool coinbases... Right? I haven't setup P2Pool yet, but I should. Then I can test it with my own addresses... |
|
|
|
But for some reason it didn't find CppBlockUtils.py & _CppBlockUtils.pyd. If those are in the same directory as you are running the script from, then it's failing to load the .pyd... is it a 32-bit system? Because _CppBlockUtils.pyd is compiled for 64-bit systems. It wouldn't surprise me if your offline computer was old and running 32-bit Win XP. Or possibly 64-bit but running 32-bit python...?
I released what I could because I'm on my girlfriend's Win 7 64 bit laptop, but when I get home tomorrow night, I'll compile and release for 32-bit, too.
If that's not it, I don't know what is. You might get more information by going to that same directory and typing "C:/Python27/python.exe" then typing "import CppBlockUtils". It should give you a more-specific error. I thought I had fixed Armory so that it would give this extra information without doing these extra steps, but this armoryengine.py file is a slightly-older version.
Yes, my offline computer is running a 32-bit system, so I suppose that's the problem. I went ahead and did what you suggested anyway, and after a bunch of stuff it says: ImportError: DLL load failed: %1 is not a valid Win32 application. I knew it! (my girlfriend tells me I'm clairvoyant ) I know I'm sending you on a scavenger hunt here, but you can probably use the compiled CppBlockUtils.py and _CppBlockUtils.pyd found in version 0.51-alpha (when I still released pseudo-binaries): https://github.com/etotheipi/BitcoinArmory/downloadsDownload the zip file for 0.5.1-alpha 32-bit, and use the CppBlockUtils files from that. I bet it will work. If not... well you'll have to wait I think my first priority after getting back from vacation tomorrow will be fixing the send-tx/network bug, and then integrating this functionality into Armory so that it doesn't have to be a hacky script. Sounds like I better get permission from Joric to include his code as an "add-on" to Armory... |
|
|
|
Please let me know if something doesn't work quite right.
I managed to pull the keys from my wallet on my offline computer but when I try to import them, I get the following error: ***Error C++ block utilities not available. Make sure that you have the SWIG-compiled modules in the current directory (or added to the PATH) Specifically, you need: CppBlockUtils.py and _CppBlockUtils.pyd Traceback (most recent call last): File "C:Users\User\Desktop\Armory_MigrateWallet\ArmoryBulkImport.py", line 1 , in <module> from armoryengine import * File "C:Users\User\Desktop\Armory_MigrateWallet\armoryengine.py", line 333, in <module> TheBDM = Cpp.BlockDataManager().getBDM() NameError: name 'Cpp' is not defined Those files are in the same folder as ArmoryBulkImport.py on the desktop where I originally extracted it. I notice that it looks at the directories where the Satoshi block chain info resides. Do I need the block chain for this to work? No, you don't need the blockchain. It autodetects the directories for a full, online Armory instance for your OS, but doesn't use them for offline mode. But for some reason it didn't find CppBlockUtils.py & _CppBlockUtils.pyd. If those are in the same directory as you are running the script from, then it's failing to load the .pyd... is it a 32-bit system? Because _CppBlockUtils.pyd is compiled for 64-bit systems. It wouldn't surprise me if your offline computer was old and running 32-bit Win XP. Or possibly 64-bit but running 32-bit python...? I released what I could because I'm on my girlfriend's Win 7 64 bit laptop, but when I get home tomorrow night, I'll compile and release for 32-bit, too. If that's not it, I don't know what is. You might get more information by going to that same directory and typing "C:/Python27/python.exe" then typing "import CppBlockUtils". It should give you a more-specific error. I thought I had fixed Armory so that it would give this extra information without doing these extra steps, but this armoryengine.py file is a slightly-older version. -Eto |
|
|
|
let's assume the BTC price stays constant at $5 and mining reward drops to 12.5 BTC/block in 5 years
IMO this is not a reasonable assumption ... In 5, 10 or X years, when the block reward drops, Bitcoin value either rises considerablly, or drops to zero. Its value today hinges on the speculation that it becomes a major world currency "sometime in the future". If people see that this is not the case, they will exit the market. I don't think it's a reasonable assumption either. But some assumption has to be made to even start putting numbers into the analysis, and using the current state is at least a feasible one (since it's currently at this state). And in the end, it doesn't change the fact that the network may need $100k/day to maintain healthy miner participation. I'm looking for an order-of-magnitude more than anything: getting $100k/day of contributions may be tough, and fitting them in with NACs will be painful for the blockchain. It might be better to focus solely on transactions fees, the way they were intended. |
|
|
|
Violently awesome! Does the migration process support the satoshi client's new compressed pubkeys?
Ahhhh crap. Thanks for reminding me that I don't support compressed public keys, yet. My understanding is that the private keys are going to have an extra byte to identify if it's to be used as a compressed address, and I don't have either implemented yet. I'm going to have to do a bit of work when I get home to support that (luckily, Crypto++ which is the underlying library I use, has native support for compressed public keys, but I have to adjust some of my blockchain scanning code to recognize them). So, to answer your question: no it does not support them. This will only import regular addresses: it will likely, silently skip any private keys used for compressed addresses. I need to add compressed public keys to my high-priority to-do list... |
|
|
|
|
I am finding it difficult to believe in the concept that some rich people will essentially fund then network. I'm just doing a back-of-the-envelope calculation here. Unfortunately, this is all dependent on BTC price: if price jumps to $100/BTC because all of online betting/gambling and MMORPG trading adopts Bitcoin, then miners would still have incentive even if generation dropped to 2.5 BTC/block right now. I know it's not that simple, but the point is that looking at raw BTC/block generated makes for a somewhat arbitrary measure of how much miner support there will be.
But let's assume the BTC price stays constant at $5 and mining reward drops to 12.5 BTC/block in 5 years. Then the NAC as described by Mike Hearn would have to support about 30 BTC/block of miner incentive, to guarantee that miners still find it profitable to continue mining (because at $5/BTC and 50 BTC/block, miners are incentivized, but making less than 100% profit). That means that there needs to be buy-in for $150 per block to keep the network going. That's $900 per hour, or about $20k per day. That seems doable in a sense of a one-time crowdfunding effort -- but this is every day til the end of time. If you look at how the variables change, an increase in price will require a lower BTC reward to be profitable, so I see $20k/day as a decent right-order-of-magnitude number that is needed to keep the network going at the current generation rate. And it will get larger, though only slightly as the generation continues halving.
Although, ideally we'd have at least 3x the hashing power we do now, as I believe that governments and botnets are in range using existing resources to attack the network (but I dont' want to get distracted on that part). The point is, I believe that for a good equilibrium to be reached, we're looking at about $50k-$100k per day to be added to fees or NACs to keep a healthy network running.
If there are 50k users who all pledge $1/day, or $30/mo, that's obviously ideal. I'm sure some people would step up to contribute more and make it less expensive for others. But it's still a tremendous amount of money. And still an unsolved problem. Mike has talked about using NACs to incentivize miners, but using OP_CHECKMULTISIG for even 1000 public keys is a lot of blockchain bloat. And no matter how you do it, those 1000 public keys will end up in the blockchain trying to get money into an address that can fund the NAC to begin with.
Put all this together, and I feel like we would need some rich folks to fund it (which is stupid expensive for anyone), or we should be focusing on transactions fees carrying the incentive, since they are already part of the network (or somehow create out-of-band non-BTC incentives...)
|
|
|
|
|
Show Posts
