In Visual Studio all you need to do is right-click on the executable project and do "Add->Resource->Icon". Visual Studio will generate the resource script (*.rc) for you and automatically invoke the resource compiler (rc) and add the compiled resource file (*.res) to the linker's input.
The problem with these solutions is that the final executable is not created by the compiler/MSVS. It is created by py2exe. MSVS is only compiling a DLL that gets bundled into the final distributable with the python code (containing the C++ blockchain utilities). However, as I was writing this response, I realized that I bet py2exe has a solution for this. Sure enough, this page shows that it's pretty simple. So yeah, I wish I'd realized that before... Haven't tried it yet, but this looks pretty damned easy... |
|
|
|
Just started using Armory and have an offline copy running on an offline computer and on online copy on an online computer with a "Watch Only Waller".
I notice that the option under Wallet Properties: "Backup Individual Keys" is available on the online computer as well as the Offline computer. If you click on this and put in the password won't this spit out the private keys that are supposed to be only on the
Offline Computer? If so isn't this a significant vulnerability? (If a hacker gained access to the online computer and were able to
brute force guess the password wouldn't he be able to spend the bitcoins?) --or am I missing something--I hope.
Thanks
There are no private keys at all in the watching-only wallet file, so there is nothing to be revealed. If you're really ambitious you can open your watching-only wallet file with a hex editor and compare the data against the documented format. You'll see that the private key fields are all zeros  What you get when you click that button is the ability to see your public keys and/or addresses, which some users might want for a variety of reasons (mostly advanced users). |
|
|
|
You should add a "message" or "label" to the "Click to Pay" URL. Perhaps something like "Bitcoinstore.com order# 18272542". Then you are autodocumenting the transactions for the users, and you'll appreciate them having easy access to the order number when they contact you for various reasons.
Technically it should go in the "message" field, but I think Bitcoin-Qt doesn't really use that field, so I think it has to go under "label." I've talked to them about making the "message" field useful (marking the transaction, instead of the address), but they don't do it, yet.
This sounds like more of a comment for Bitpay.com since the checkout is handled by them. I don't see it as much of a problem currently since all the information is emailed to the customer as soon as they place their order. The issue is not that the user needs the information in their Bitcoin client, but they can't just leave the label blank or else they'll never know what any of their addresses or transactions were used for. Some are too lazy to type in their own description, and if they don't, they'll have fun trying to find old emails at a later time to cross-reference against their BTC transaction history. Most importantly, when the merchant does it, they get a nice uniform labeling that clusters all their purchases together when they sort their tx history by label. On top of that, it's stupid simple to implement, and it makes shopping with BTC literally a few clicks (plus maybe an encryption passphrase). I'd hate to see something so simple and useful go unused. I can email BitPay about it, but I'm not a customer of theirs. I figured I'd persuade you to see the value and request it yourself |
|
|
|
If anyone wants to donate time to me, you can help me figure out how to script Resource Hacker to add the Armory icon to the Armory.exe file in Windows. The icon is in the img/armory48x48.ico. It needs to be attached to the ArmoryStandalone/Armory.exe file (which is created by the bulld process). I guess you you don't need the specifics, I just need to be able to add a *.ico file to a *.exe file from the command line, and then I can add to my MSVS post-build scripts to do it automatically on each build. I have tried this a couple times, but it never worked. It returned no errors, it just failed to change the Armory.exe icon. Here's a reference for the ResHack command line: http://www.autoitscript.com/forum/topic/47720-reshack-command-line-option/Right now, I have to manually open resource hacker, "Add Resource", then navigate to that icon, then name the resource and save it. This is just an extra step in a multi-step process to create Windows .msi installers, and anything that makes that easier means more readily creating releases in Windows. Right now, in Linux, I only execute "python dpkgfiles/make_deb_package.py" and I get a Debian installer that is ready for distribution (minus the signature, which is done offline). |
|
|
|
|
You should add a "message" or "label" to the "Click to Pay" URL. Perhaps something like "Bitcoinstore.com order# 18272542". Then you are autodocumenting the transactions for the users, and you'll appreciate them having easy access to the order number when they contact you for various reasons.
Technically it should go in the "message" field, but I think Bitcoin-Qt doesn't really use that field, so I think it has to go under "label." I've talked to them about making the "message" field useful (marking the transaction, instead of the address), but they don't do it, yet.
|
|
|
|
etotheipi, it looks great, thanks! Exactly what was needed I got one more feature request I don`t know how exactly should that look like, but it would be great not just put "[[ Change received ]]" in comment to change address but point out the source address (or comment of this address) of that change. Hmm... that's a bit of extra logic, but it can be done. I presume you'd like to see this on the wallet properties address list, too? It's a bit easier if I do it only on the coin-control dialog, because I don't have to worry about the efficiency/speed of the search operation (if you have thousands of addresses, it will execute this search on every refresh and could slow down wallets with a a lot of addresses).
So I think I have enough little extra features and bug fixes to be worth an official-but-minor release, 0.86.1... or 0.86.2...? Maybe I should finally figure out how to do automatically-incrementing build numbers so that there will no longer be any conflict between different builds of the same 0.XX.Y. So far, I've just been manually incrementing the version number, but I should be using that fourth version number ... such as incrementing it every time I start up Armory for testing. Actually, I'm going to do that! Anyways, if there's any other little bugs or minor features you'd like in the 0.86.X release, let me know. I'll probably send out a request for testing to my testers email list, and try to do a real release on Tuesday. Most importantly, I want that disappearing-address bug to go away. |
|
|
|
P.S. I`m a bit confused with your branches...where is the latest Coin control branch for now? And please don`t forget to add labels to CC`s selection window Just updated the "dev" branch with comments in the coin-control dialog, and the dialog auto-sizes now, too. Please try it out. |
|
|
|
I just realized something that will need to be addressed with any such scheme that is used: how will a soon-to-be-full-validation-but-pruned node bootstrap off the network? Sure, we can say that at block X, the entire set of UTXOs is well-defined and compact (in whatever tree structure we're talking about). But any new node that jumps onto the network will have download that entire UTXO set, and surely peers will have updated their internal UTXO set/tree in at least once while the node is downloading.
The prevailing idea is that you download the block chain from "archive nodes", which are nodes that retain the full blockchain. I'm not talking about downloading the entire blockchain. I'm talking about downloading just the pruned UTXO-tree. Every pruned-full node knows what the UTXO-tree looks like at a given time, but before it can finish telling you what it looks like, it's updating itself with new tx and blocks and changing it. I'm not seeing a clean way to transfer pruned-blockchain data from a node that is constantly updating its own meta tree. Ultimately, it's because knowing what the network looked like at block X (from the pruned blockchain perspective), does not mean it's easy/possible to tell me what it looked like at block X-30. And it's probably a lot of data and complexity to accommodate taking a "snapshot" just for helping other full nodes catch up. You could say: well they should just download the entire transaction history and build the UTXO set themselves. I'm sure some users will do that, either out of paranoia, or for historic reasons, etc. But it most definitely shouldn't be a requirement to download 100 GB of history just to get 2 GB worth of UTXOs. The data needed to become a pruned-but-still-full-validation node is a fraction of the entire-and-ever-growing history, and it would be a pretty significant waste of resources to not be able to download the raw UTXO list to get up and running. As I said, the simplest is probably to have nodes just spend the space on a snapshot at every retarget, and let nodes synchronize with that (or perhaps every 500 blocks or something, as long as all pick the same frequency so that you can download from lots of sources simultaneously). After that, they can download the few remaining blocks to update their own tree, appropraitely. This could affect pruned-lite nodes, too. If there are updated meta-chain hashes every block, then even transferring small "address branches" to lite nodes could be "interrupted" by new tx/blocks coming in that changes the seeder's UTXO-tree before it's finished. |
|
|
|
I have a feature request: the password I have to encrypt the wallet is quite long and I use it really infrequently (I have not put time into finding out how to use the offline functionality yet so this is my main protection). Sometimes I would like to enter the passphrase and Armory should tell me whether the passpahrase is correct. Right now this can only be done when making a transaction or when changing the passphrase. Could this functionality be added?
One thing you can do is click on "Print paper backup" or "Backup Individual Keys". That will ask you for your passphrase and tell you if you entered it correctly. |
|
|
|
Here's exactly how it works: Let's say you modify your wallet in some way, such as importing an address to it. Here's exactly what Armory does: (a) import address into .wallet file, (b) import address into _backup.wallet file, (c) report success to user. The user is not notified until the update is written to both files, and no matter which nanosecond the power goes out, one of the two files will be uncorrupt and automatically restored. Along with single-bit error correction in every wallet field, this is why I claim "corruption-resistant" wallets
There may be some interference depending on how exactly OS/Bios handles writing of files (as in, file #1 write is being cached, reported completed, file #2 is being written upon, reported completed, power goes down, nothing was committed). Even so, this is a nice feature. Even so, if Armory encounters errors reading one file, it will restore from the other one. If, somehow, both are corrupt... That's why you have a paper backup :-) (and for reference, I'm not aware of anyone suffering wallet corruption, yet). I do recognize that the disk writes are not guaranteed, but at least there is an fsync called after each write, so there's a good chance it will. |
|
|
|
Unless you implement SOCKS support into Armory, you won`t be able to run Armory itself over Tor. But maybe you were asked how to connect to Bitcoin net over Tor. In that case you will have to start bitcoind or bitcoin-qt with "-proxy=127.0.0.1:9050" or whatever host Tor is running. Also maybe you should start Armory with "--skip-online-check" parameter.
Sorry, I meant: Bitcoin-Qt is running over Tor, but Armory cannot connect to it while it is in this state. How is this resolved? Do you have to change the ports in Armory? skip-online-check is something else that needs to be done... forgot about that... P.S. I`m a bit confused with your branches...where is the latest Coin control branch for now? And please don`t forget to add labels to CC`s selection window Coin-control has been merged into master already. So just getting the current master branch will have coin-control (or downloading from the website, 0.86-beta). I recommend switching to the "dev" branch, though, which has a bunch of bug fixes and needs testing (0.86.1). I guess I should clean up all these one-time-use branches I created in the past... If you missed it the first time, I did put labels in the mouse-over text for each address in the coin-cointrol window. I intended to add a column, I just forgot it in 0.86.1. Would it be acceptable to add a very narrow comment field, that only shows you the first 16 characters of the comment, and then you can mouseover for the full comment? I like the compactness of the CC window, but it's not critical. |
|
|
|
|
I just realized something that will need to be addressed with any such scheme that is used: how will a soon-to-be-full-validation-but-pruned node bootstrap off the network? Sure, we can say that at block X, the entire set of UTXOs is well-defined and compact (in whatever tree structure we're talking about). But any new node that jumps onto the network will have download that entire UTXO set, and surely peers will have updated their internal UTXO set/tree in at least once while the node is downloading. This means that even if a node can start supplying the UTXO set at block X, within an hour that node will be on X+3, or something like that. Branches and leaves of the tree will have changed, and that node will not recognize the branches and leaves of the previous state (well, most will be the same, but you get the point).
This is resolved in the main network by having persistent, authenticated information that can be downloaded in chunks (i.e. blocks in the blockchain), which are still valid, no matter how long it's been since that block was created. Each block can be downloaded quickly, and checked directly against the header chain. However, in this case, the entire tree is to be authenticated against a block header, and you pretty much have to download the entire tree before you can confirm any part of it. Seems like this could be a problem...
One idea, which doesn't seem ideal, is that the node simply stores a "snapshot" at every retarget event. Every new node will have a two week window to download the UTXO set from the latest retarget, and then download the block history that has occurred since then. If the new node also has a wallet, it can use the absolute latest meta-header to get its own balance and UTXO list and let the user manage their wallet using the still-secure address branches, it just won't be able to fully sync and start full validation until it's done downloading the latest retarget tree.
That's not an ideal solution, but it's food for thought...
|
|
|
|
|
Someone just asked me about how to run Armory over Tor. I realized that not only do I have no idea, but I've heard users claim they have done it, and I never paid attention. Can someone please explain how to do it? I will add the description to the webpage once I see a consensus.
|
|
|
|
Nice, just downloaded and am playing with it. Some questions.
1. If I did not print a paper backup when it first launched, can I do so later and if so how?
2. Assume that the file armory_blahblah_backup.wallet is my digital wallet backup correct? If I store this somewhere secure and my computer gets destroyed/stolen/etc, that is all I need to get my coins back would be to install a new version of Armory, point it to this file and enter the same passphrase I entered originally? This file is encrypted correct? So if I sent it through email it should be safe unless someone knows my passphrase?
3. How is the armory_blahblah_wallet file different from armory_blahblah_backup.wallet?
4. Is there any sort of user manual that explains how to use all the features?
Looks great so far. Thanks for the effort. Will send some btc your way
- (1) Yes, you can print a paper backup at any time. It always prints the root key and chaincode, which is always capable of reproducing every non-imported key in your wallet, ever. Just double click on the wallet (or select it and click "Wallet Properties"), and there is a button on the right that says "Make Paper Backup."
- (2) The *_backup.wallet file should be an exact copy of your main wallet file, used for consistency checking. Let's say you modify your wallet in some way, such as importing an address to it. Here's exactly what Armory does: (a) import address into .wallet file, (b) import address into _backup.wallet file, (c) report success to user. The user is not notified until the update is written to both files, and no matter which nanosecond the power goes out, one of the two files will be uncorrupt and automatically restored. Along with single-bit error correction in every wallet field, this is why I claim "corruption-resistant" wallets. I have even have unit-tests that involve interrupting the write process and verified they work as intended.
- (3) See above
- (4) There is no manual. The best I've got is a tutorial on using the offline wallets feature. I've been meaning to come up with more how-tos and tutorials, but I'm a one-man show, and I've been more focused on development. However, I am very good at baking descriptions and warnings into the app, so I hope a lot of it is self explanatory (Armory yells at you when you're about to dangerous things).
Glad you like the app! Thanks! |
|
|
|
FYI: I decided that my queue of bug fixes and polishing requests was big enough to be worth taking a temporary vacation from my RAM reduction, and update master. And by updating "master," I mean branching it into the "dev" branch and fixing a bunch of bugs there. That will be 0.86.1. For those wondering about my branching behavior -- I tend to work on branches appropriately named for the hardcore upgrade I'm doing. However, if I'm just fixing bugs or doing minor enhancements, I stick to the "dev" branch. Sorry if it makes it difficult to follow the latest testing code! I will be adding more stuff to the dev branch in the next week. Mainly handling bug reports and more polishing. I also need to fix single-threaded mode... I intended to be able to say "TheBDM.setBlocking(True)" and have scripts be able to operate as if everything was a single thread, but it turns out I missed a few things, and I broke some of my code samples. So version 0.86.1 has: - -Fixed addresses disappearing and reappearing. The "alreadyUsed" variable is no longer erased from recent addresses on a restart.
- -Full sorting of the transaction ledger is restored (and optimized!).
- -New warning dialog for offline transactions, reminding users to verify tx details before signing (I have run into a few people who didn't realize they should manually verify tx before signing -- it's not secure just because the keys are offline!)
- New right-click menu on main ledger.
Switch to dev branch right now if you want to get the new stuff! I'm not sure how I'm going to handle the Bitcoin-Qt 0.8 update... it's going to be kind of complicated to accommodate pre-0.8 and post-0.8 in the same code base (because I have to modify the under-the-hood, optimized C++ loops). I might just have to compile separate versions  (and maybe I should add a warning message to the upcoming release that the user should check the website for Armory updates if they plan to user Bitcoin-Qt 0.8 )
By the way, I'll be attending the East Coast Bitcoin Summit in Philadelphia tomorrow. It sounds like it's shaping up to be a big event, so if you live on the east coast (US), then you should join us. I received a late invitation so I won't be presenting anything, but the organizer did invite me to be on a Q&A panel at the end. Looking forward to it |
|
|
|
My apologies for "reposting" thanke's idea. I read through 2/3 of the paper and a lot of the comments and apparently I didn't have the attention span to recognize that they were essentially the same solution (clearly related, though). If nothing else, this is a much-more-concise version of it. I had posed this question to roconner and he came up with a nice clean solution, so I thought it should be posted. The extra cost to the merchant for the multi-domain cert might not be worth the incremental security benefit; if they have good monitoring (which they should), then they should detect an attacker's intrusion within minutes and so their potential loss might be tiny.
I'm not convinced that the incremental security is tiny. Visa and Mastercard and Paypal, all have fairly locked-down systems that provide lots of information about anyone who is registered with the system, and the funds may be recoverable depending on how soon you detect it. But in Bitcoin, you're talking about pseudo-anonymous, irreversible transactions -- every dollar lost to this kind of attack is really gone. And this isn't just profit, this is gross income -- you can be sure that the customer will still expect their stuff, since they didn't do anything wrong. Also, maybe resourceful/large companies can pay to have a good monitoring of their own webserver. But maybe some smaller companies can't. Or their IT team isn't that good -- a lot of companies get by with mediocre support. It wouldn't surprise me if such a small company went a full business day without noticing. Hardware devices are cool, and I think they offer a lot of potential but not nearly as versatile as a SW solution. First, the HW solution proprietary and not everyone can make one, so it costs extra money. And the physical security becomes more vulnerable having to keep the HW with the server -- with this method, the business owners could keep the cert/key in their safety-deposit box (or at home?). Unfortunately, I don't know that much about the X.509 infrastructure (other than the low-level cryptography aspects), and did not know that the certificates were restricted in what they could sign. This is why I haven't contributed much to the payment protocol discussion, because I'm not sure I have anything to contribute (but lots to learn). I was intrigued by the concept that a signature on the root key could be proven in the child keys, and was hoping someone else would answer about the feasibility. If truly was feasible, I'd hope that we'd consider folding it into the currently-discussed payment protocol somehow... |
|
|
|
That makes a lot of sense now. Sipa never told me about this because he assumed I watched for block messages on the network instead of watching the files. Oh well.
Why not listen for blocks on the network? Two reasons: (1) Armory doesn't hold raw block information. It only stores pointers to where the data is in the blk000X.dat files, using std::map<Hash, FileDataPtr>. So, it doesn't make sense to get it from the network when I have to eventually find it on disk, anyway. (2) Doing it this way, allows me to build blockchain utilities/tools using armoryengine.py without having to use any of the networking code. Once you bring networking into the mix, the scripts get dramatically more complicated, because you're now operating in a python-twisted event loop. The way it is, you can create super-simple "watcher" scripts without any concept of networking: Pseudo-code: loadWallets()
registerWallets()
loadBlockchain()
while(True):
newBlks = TheBDM.readBlkFileUpdate()
if newBlks>0:
doCoolStuff()
sleep(1)
|
|
|
|
I proposed this problem on IRC, and roconner came up with a very simple answer. I've heard the devs say that "compromised web-servers are out of scope" -- this solution very well makes it in-scope. The availability of such solutions should be strongly considered. Problem: How can we prevent the situation that a webserver is compromised, and all payment addresses are replaced with those of the attacker. We want deterministic wallets, and we don't want to have to give every customer our entire public key chain. Using SSL/PKI/etc is assumed necessary here, since we assume no prior relationship between merchant and customer, and communication is happening over an insecure channel (i.e. -- the internet). Solution: This solution has the following properties: (1) Signing certificate (X.509, GPG, Bitcoin private key, whatever), can be offline and remain offline forever -- it is never connected, by any means to an online computer (1a) Signing certificate is trusted because it bears a CA's signature (2) Uses deterministic wallets without revealing the entire chain, and without signing each individual key (3) The certificate is used only to sign the root public key of the deterministic wallet, once. All derived/child keys can be proven to part of that public chain without revealing the chaincode. Consider a deterministic wallet such that you have a root public key, PubKey(0), and have a deterministic way of producing a sequence of chain codes, ChainCode(i), which are not public. Then if you use: PubKey(i) = Hash(ChainCode(i)) * PubKey(0)
InvoiceID = Hash(ChainCode(i)) Customer is presented with (InvoiceID, certificate-signed PubKey(0), CA-signed certificate). The customer verifies the certificate is signed by a trusted CA. Then they verify that PubKey(0) bears the signature of that certificate. Then they confirm that InvoiceID*PubKey(0) indeed matches the address they were requested to pay. Since the invoice is the hash of the Chaincode, there is no way for the customer to produce any other keys (despite having the root public key, which would remain unused so it could be used for this authentication). Privacy is preserved. Simple, straightforward, and right down the same alley as deterministic wallets, themselves. Even if the webserver is compromised, the only addresses it can distribute that would be accepted by the customer, would be ones derived from PubKey(0). Granted, it could distribute addresses using arbitrary 32-byte chaincodes, but at least the attacker wouldn't have a way to insert his own address, which removes about 98% of the motivation for the attack to begin with. (and in the case of arbitrary 32-byte codes, the merchant only needs to retrieve the InvoiceID from the customer to get access to the funds). Thanks to roconner for the straightforward-in-hindsight solution to this.
Update: I wanted to point out that this is possible without changing anything, if you are using BIP 32 wallets. If you look at how the address chaining works, you see that to go from Root-->Child: I = HMAC_SHA512(RootChain, RootPubKey || ChildID) I is 64 bytes and then split into ChildMult = Ileft = I[:32]
ChildChain = Iright = I[32:]
ChildPubKey = ChildMult * RootPubKey
Therefore, the child public key can be derived from the root public key using a multiplier which is not related to the chain code. This means that you can sign RootPubKey with your offline certificate (but don't give out the chaincode!) and then I left can be used as the "InvoiceID" above. It fits perfectly into BIP 32. |
|
|
|
etotheipi, I think the "parseNewBlockData did not get enough data..." error is coming from this loop. while(bsb.streamPull())
{
while(bsb.reader().getSizeRemaining() > 8)
{
...
BinaryRefReader brr(bsb.reader().getCurrPtr(), nextBlkSize);
parseNewBlockData(brr, fnum-1, bsb.getFileByteLocation(), nextBlkSize);
blocksReadSoFar_++;
bytesReadSoFar_ += nextBlkSize;
bsb.reader().advance(nextBlkSize);
}
} @chrisrico I just talked to sipa on IRC and now I know what's going on. They not only changed the filenames and location, but they changed the write operations too to reduce fragmentation. Your observation makes so much more sense, now... bitcoind/-qt now will now pre-allocate the blk files using 16MB of zeros. When the 16MB is filled, it appends another 16MB, etc. Understandably, this wreaks havoc on my block utilities which pay attention only to file size to be notified of new blocks, and hence why you never saw any updates. Sipa pointed out that since each block starts with the magic bytes, simply watching the next four bytes after the next block is a good way to catch new blocks. It means rewriting the loop slightly, and the "readBlkFileUpdate()" function. So much for a smooth transition to 0.8! Sipa never told me about this because he assumed I watched for block messages on the network instead of watching the files. Oh well. |
|
|
|
|
Show Posts
