I recently purchases this microscope from amazon, and started looking at everything I can get my hands on at 40-150x. One such thing was the hologram on the back of a casascius physical Bitcoin. I believe this is actually only 10x and 40x, but 40x was enough to see what I didn't know was even there: four rings of "CASASCIUS" just inside where it says "ORIGINAL" on the coin. Looking at it by eye, I can barely identify the bigger outer ring, and definitely can't identify the smaller three inner rings. This is impressive: casascius really put a lot of quality into these holographic films!    |
|
|
|
I'm new to Armory, but been watching it for a while. I have a "Brainwallet" savings address based on a very long password. I'm having trouble figuring out how to make it work in a watching-only wallet. What I want to do is import only the PUBLIC key into Armory without exposing the private key. I originally generated the private key on a non-networked boot of Ubuntu Privacy Remix and it has never been used on a networked computer. Now it seems my current options are:
1) Boot my computer into non-networked Linux to generate the Armory wallet (but I would have to go online to download libraries and build from source).
2) Boot my computer into my normal Windows install without networking to generate the Armory wallet (but I strongly distrust Windows and the security of doing this).
3) Boot some other non-networked Windows install to generate the Armory wallet and wipe the disk (but I have no such "expendable" installations on hand).
So is there a better way to do this? With Electrum I was able to import a "junk" keypair and then replace the public key only with my savings address to accomplish the same thing. However, it looks like the Armory wallet format is not human readable.
There's some security issues with being able to import arbitrary public keys for watching-only purposes. The best thing to do is to import it into your offline wallet and then re-make your watching only wallet. Remove the old watching-only wallet from your online system, and re-import the new one. It will destroy any comments you currently have in the file, but that is something I'm going to fix in the upcoming wallet format. Alternatively, I kind of like your idea for over-writing a junk key pair. I documented the file format, here: http://bitcoinarmory.com/index.php/armory-wallet-filesThough, to do it your way you have to start with a watching-only wallet with a junk keypair. I would recommend make a new wallet, import a junk address, then make a watching only wallet, and remove the full wallet. The imported key will be at the end of the file. You have to change the first 24 bytes to be [Address20 + checksum] and change the 65+4 bytes where the public key is (the last four is also a checksum). The checksums are just the first four bytes of the double-sha256 hash of the data. That's probably not what you were hoping for. Sorry I couldn't make this easier... |
|
|
|
This looks like the major contributor to the most recent SD profits - another martingale disaster:
I wish I could remember the quote I once read about martingale betting -- it was something like: Martingale betting is a fun concept, but it doesn't work. In order to guarantee success, a Martingale bettor needs access to an infinite bankroll... and infinite balls. Unfortunately for the bettor, all bankrolls are finite but infinite balls is very, very possible. I've scoured the internet, and I can't find any (relevant) quotes with "infinite balls" in it. So I guess I can claim credit for it  (though, the original version had a much better delivery) |
|
|
|
Running into the hell of compiling Armory on OSX.... What if you required brew for OSX? I know that is not 'ideal' but it is loads better than what we have today. Then users could install your custom formula and just brew install armory https://github.com/mxcl/homebrew/wiki/Formula-CookbookThat is a super interesting idea! You're right, it's not ideal, but it would dramatically improve the situation -- users that really want it, can get it. I'm getting lost in my attempts to split blockchain loading into a background thread. Multi-threaded programming comes with all sorts of headaches. When I'm done with this implementation, I'll release it for testing and look at this OSX idea while the Win and Linux users beat on the new version. EDIT: Scratch that: I'm going to look at py2app first. Red Emerald's link for "py2app hell" may very well help me avoid all the things I was worried about. If that turns out to be trouble, I'll take a shot at your idea |
|
|
|
I attempted to follow the OSX build instructions on the site; however I keep getting an odd error: ...
i686-apple-darwin11-llvm-g++-4.2: /usr/lib/libpython2.7.a: No such file or directory
...
As you can see libpython2.7.a does indeed exist (although I had to manually symlink it). My gut feeling is that it has something to do with the PyArg_ParseTuple erro, but I do not have the skills to troubleshoot this. Thanks. I may not be much help here. I just wanted to add a frustrating lesson I learned recently that made me think I was going insane: I was trying to execute a binary file that very obviously existed. Asked a Linux guru of mine about the issue, and he did all sorts of tracing on the error and discovered it was an architecture thing -- I was trying to run a 32-bit binary on a system that had only 64-bit libraries installed. The "No such file or directory" error was actually referring to the absence of the 32-bit glibc binaries needed to run the 32-bit app. |
|
|
|
Great work putting this together, thanks.
The link to the code you refer to in the initial post "sample_armory_code.py", is no longer working. I'd love to check it out and try building/running it myself. Is there anywhere else where the code is posted?
Okay, I had never updated the script with the latest under-the-hood changes. I just updated it now and committed it to the master branch. Checkout/pull and try again. Btw, did you compile the C++ libraries? |
|
|
|
I'm surprised to see MikeHearn and etotheipi saying to send back to sending addresses.
I would be really upset if I used my bitcoins to donate to Mark and they ended up in MtGox or instawallet's slush fund.
There isn't a way to safely return bitcoins and I don't think Mark blasting off what people gave him to who knows where in order to maybe satisfy potential bureaucrats complaints is terrible. Worse than never accepting them at all by long shot.
How about this:
Bureaucrat says: Mark we see what you did, pretending to return all of those coins by sending them to the sending address recorded in the blockchain, now you need to prove to us that you don't own any accounts which are attached to those receiving addresses. For all we know you made deposits to 1000 instawallets and 5000 MtGox deposit addresses before announcing that you were accepting bitcoin donations. You fully knew that some people would be paying from those popular wallet services and chances are that some of the coins would be paid from accounts with addresses associated to your accounts. So you 'returned' the coins to some of your own addresses. It's clever Mark, but not clever enough. The possibility that you retained any of those coins invalidates your campaign for breach of XXXX regulation.
Mark: .......
I don't understand. Those sending addresses are not black holes. The coins are not lost. It just has to be sorted out with Gox customer support, etc. Having a transaction ID and a signed message from Mark should be enough. Plus, this is a condition that shouldn't happen -- there should be a huge warning on the donation page about it. If donors don't pay attention to the warning, then their punishment is dealing with Mt Gox support to recover the funds. Perhaps for donations that happened so far, before people realized this, they can be returned via user-supplied address. That would be justifiable as "growing pains" of figuring out this process -- especially because it's not a ton of money Mark has received so far. However, future donations should follow this policy, and there should be some explicit warnings about it on the donation page. |
|
|
|
Another possible web server setup that is possible with Armory (that I've actually thought of setting up myself), is having the web server connect via USB to a small Linux ARM device (just something cheap) that has a USB OTG port (allowing the device to act as a USB client). This USB client device stores the private keys and only responds to request over USB. With this setup, it's possible to simply send transaction requests to the web server that are signed with a certain private key, let the web server forward the request to the device, and then let the device - connected only via USB and not connected to the Internet - verify that request with the corresponding public key, and only return a signed transaction over USB if the signature on the request can be verified with the public key on the device.
This should - if implemented correctly - make the wallet unhackable. The only thing an attacker can do - even if he gains full access to the web server - is send request over the USB connection to the device that hold the keys, but without the proper private key the device will ignore the requests.
This could be useful for use cases such as an exchange needing to transfer coins from its cold storage wallet to it's online wallet. The exchange owner simply has to make sure that the private key used to sign requests is inaccessible to attackers.
Another use case could be a company exchanging fiat currency for bitcoins. Here the bank is in possession of the private key. It promises to sign all incoming wire transfers with this private key. If the wire transfer - in a comments-field of some sort - includes a receiving address, it's possible to let someone wire a certain amount of fiat currency to the business owners account, and let the business send out coins to that person - completely securely - given that the customer includes the send-to address in the wire transfer. If the bank can keep the private key secure, this - again - prevents an attacker from being able to do anything were he to gain full control of the web server.
This seems like a good idea to post on the Improving Offline Wallets Thread. I like the hardware idea, except I don't understand where the private key & signature comes from? It's not stored on the online system, is it? Why do you need any signing? Why not just use that device to facilitate passing ASCII-only between the two systems? Any non-ASCII buffers are rejected, and the offline computer will do nothing except collect the data and wait for the user to act on the received data. Really, it would just behave like a serial port. Damnit! I wish I could make the serial port idea work... |
|
|
|
Armory will open immediately and operate like offline mode while the blockchain data is loading. Then switch to online mode when it's done. I already have a proof-of-concept for this, I just need to redesign some of the interface to accommodate mixed-online-offline mode. This is perfect! Splash screens are a strange concept, I think. It definitely adds to the user experience to see the user interface as soon as possible. One thing you could do when the app shows up immediately, but hasn't loaded the block chain, is disable (grey out) all the items in the GUI that show information that hasn't been loaded yet, and then superimpose some sort of animation on top of it. I like this type of animation (but maybe that's just because I'm used to Linux): ... Animations, in my opinion, lets the user know that something is going on, and, coupled with a time estimate, it will provide a greater user experience. I already think your client has the best GUI of all clients, and this would really add to it. On a different note: how is it going with making Armory independant of the Satoshi client? I remember you mentioned something about it being a lot of work. I guess the better solution would be for the Satoshi client-developers to separate out the protocol-specific functionality into a library, so other clients can use it. Developing your own implementation seems like a waste of time, if you ask me (although it might be an interesting/fun experience). Do you know if the developers have any plans on doing this? Separating out the protocol implementation from the GUI of the Satoshi client? I think this would really spur development of alternative clients, including yours. I'll look into doing some kind of animation. I was actually thinking I'd have a progress bar, based on MB of blockchain read so far, but the C++ code would need some modification to make that work (currently a C++ black box that python has no internal access to). I just talked to gmaxwell today about this very topic (networking&validation engine). I really don't want to reimplement that part of the protocol and was hoping that I could cannibalize pieces of the bitcoind library. gmaxwell suggested that they are considering doing something similar with bitcoin-qt: abstract out the wallet from everything else, and have a lite-weight daemon running in the background for any wallet application to use (via sockets and RPC). I have a tough time believing they'll be able to get the non-wallet pieces of it to be "light-weight" enough that people won't complain... but if it is that could great for all developers. I'm envisioning it would be like like the .NET libraries: it's a prerequisite that needs to be installed for other Bitcoin apps to functions -- users will grumble about it, but they'll do it and then forget about it once everything is working. For now, I'm going to work on a better loading experience, OSX support, and update wallets to support multi-sig, compressed keys, branched wallets, etc. I think that will add more value right now than independent networking -- and maybe this landscape will look a little easier by that time |
|
|
|
Yeah, if Armory could specify the port it uses to connect to bitcoin-qt, I think we could continue to use Tor and Armory. Anyway, that wasn't the cause of my problem. I hadn't changed the datadir, but it looks like my blkxxxx.dat files must have been corrupt. I wiped out my datadir, redownloaded the whole blockchain (what a PITA!!) and now Armory comes up Online with the correct number of blocks. And, it shows my 0.05 BTC balance. Now I can start digging into this app. So far, it looks very impressive.
I've already added a " --satoshi-port=X" option to the command-line arguments. It's in one of my development branches and will be part of the next release. Please PM/email/post any feedback you have about the program. I'm always interested in how people are using it and what could be improved. Update: I've got most of the code-reshaping done. Armory will now readily switch between online, offline, and rescanning modes, and will start up immediately in rescanning mode (also will go into rescan mode when you import wallets or addresses). Appropriate functionality will be enabled or disabled based on the mode. I shouldn't be bragging about it until I finish implementation, but I'm pretty excited about it. Usability will improve by one order of magnitude! |
|
|
|
|
Consider Armory. Despite the load times, Armory is pretty darned stable now and handles an arbitrary number of wallets -- in addition to all the other features (wouldn't you like it if you only needed to backup each wallet, once?). It's technically still "alpha" but it will be officially Beta soon, and most users treat it like it's Beta+ already.
EDIT: I agree, it needs to be in the main client. But until then, looking into alt clients might save you the nausea
|
|
|
|
After all, it's a general computer and that's pretty expensive to have just sitting in a corner holding a wallet.
What is you opinion on using a virtual machine, booted from an encrypted image that offers the single service that signs transactions? I'm not too familiar with how VMs work, but I was under the impression that the host OS can access the VM memory space pretty easily. That means it could just reach in and grab the key when its unencrypted. However, there are some lower-level virtualization configurations that might offer a lot of security. Someone contacted me to suggest Qubes OS which relies on Xen Hypervisor. My naive understanding of it is that all the OS's are "guests" of the Xen Hypervisor, which keeps them completely sandboxed and unaware of each other. So you have network on one, offline Armory on the other. This would definitely be better than a VirtualBox/VMWare guest, but I can't really endorse it since I've only scratched the surface reading about it. Who knows, maybe it would be better than a separate computer and USB key. However, you might need a separate computer to use it, since most users probably wouldn't want to switch their host OS to this obscure distribution (even if it virtualizes Windows well, most users wouldn't want to deal with this obscure OS). Anyone know about this? |
|
|
|
etotheipi, I think you're trying to put the cart before the horse. Yes, there are plenty potential use-cases for it, but very few of those use-cases are wanted/needed/used by anyone right now. I don't hear any merchants clamoring to have customers sign their physical address information with their payment address - for the merchants, it is plenty good enough to just have the user fill out their address information into a normal HTML form at the time of purchase (and really, why wouldn't that be good enough?).
I half-agree. If it's easy enough, why wouldn't you? The purpose is for the merchant to know for sure, that the same person who paid for the merchandise just told them where to send it. Just like Bitcoin is beneficial for merchants to avoid chargebacks, this can also avoid transaction hijacking, and also enable better communication between parties that are operating more anonymously than with fiat transactions. How is a site going to verify that their semi-anonymous customer really wants their refund sent to address X, or wants to change shipping address to Y, or invest all their money in fund Z? Maybe "specify shipping address" is not the best example. And, it may not be a critical feature for everyone at all times, but it is definitely a feature that can improve security without too much inconvenience (if it's done right). |
|
|
|
There was some discussion about earlier on IRC.
Right now, message signing is a very low-level function. It has very interesting applications, but in its current form, you're not going to use it unless someone tells you to, or know what it does.
The one point where it makes sense, and the only way I see it being intuitive, easy and useful, is as part of a payment protocol. By which I mean this: an address is a URL or something e-mail like, and the client connects and requests payment information (such as the public key/script to send to, the amount, maybe a message, maybe an order id), the client constructs a transaction and sends it directly to receiver or his payment processor. When such an address is selected, the client could enable a text input field for a message to attach to it, and it would travel together with the transaction directly to the one who cares, with a signature that it comes from the payer.
At that point, it absolutely should be a first-class feature. But right now, it's obscure and unclear.
I think if this could be added to the URI spec, it would be useful and easy to use. For instance: (1) I want to buy a widget, so I got to the widget merchant website (2) Enter in my shipping address and details (3) Click on the link to pay -- client pops up asking if the payment details are correct (4) Merchant site detects the payment and gives a link: "Please confirm payment details" (5) Client pops up saying: "Please confirm shipping address for your order: Name: ... Address: ... Email: ..." (6) User clicks "sign" and sends it back It would be even better if the message signing URI included an IP address so that the client would just dump the signed message where it needs to go after signing and the user doesn't have to do anything other than click "Sign". In this particular use-case, the user doesn't even need to realize they're "signing a message." They are just confirming transaction details. If it's handled under-the-hood like this, merchants can get the benefit of authenticated messages without much inconvenience to the user. |
|
|
|
Please post comments&objections to the return-to-sender advice I posted (at the end of the first page of this thread). I think it is a really important concept to iron out. But I am not just bumping this thread, I wanted to propose a top-level CONOPs (concept of operations) I proposed to Mark's campaign via email. Additionally, I have recommended my own program (Armory) for this recommendation, because no other program currently supports deterministic wallets and watching-only wallets and has an intuitive user interface for them (am I wrong?). I'd appreciate if some other Armory users provided some independent feedback about Armory, so this doesn't look like just a shameless plug for my own software. In reality, this will become the norm in the far future, but Armory can uniquely enable it right now. - (1) Arbitrary political campaign creates a deterministic wallet, offline.
- (2) Campaign creates a watching-only copy of the wallet, registers it with an oversight committee
- (3) Potential donor accesses the campaign website, commits their personal details, and gets a donation address
- (4) Donor can put the address into the website of the oversight committee, which will confirm it is one of the officially-registered addresses
- (4a) If it's not, the donor can report the campaign for shady campaign financing practices
- (5) Donor sends money to received address
- (5a) Donor sends the final tx ID and amount to the campaign website/email (maybe not necessary, since the donation address was unique)
- (6) Once every X months, oversight committee aggregates the list of donations sent to that wallet, and requests the identifying information for each one (they have the watching-only wallet, so they can see every donation)
- (7) Campaign submits the appropriate documentation for each donor, or issues a return transaction back to the sending address for ones they can't identify
This process seems like it would not only satisfy the spirit of campaign financing laws, but might actually improve transparency. Donors can verify that the address they are donating to is a monitored address, and the oversight committee can see every donation without actually having spendable access to it. Even better, donors don't need to use Armory, only the campaign and the oversight committee. |
|
|
|
|
Message signing is appropriate as a core feature of the Bitcoin client. Once it is easy to use, it has a variety of uses which further demonstrate the power of Bitcoin. For instance, you order stuff from the internet and need it shipped. Receiver's address should be signed by the address that paid for it, to guarantee that the same person that paid is the same person that's getting it (or deciding where it's going). I could even see this being used for authentication for online services: the first payment address you ever used would be the one used for authentication. "Please sign the following message to confirm your action..." (which could be a massive withdrawal). Hell, I could see some users using it instead of GPG signatures for non BTC stuff, solely because they already have it and understand how to use it.
Message signing will not only be a powerful feature, but a core feature. I'm sure there's a dozen other use-cases, and they all justify having this part of the core functionality -- merchants should be able to request signed data from the user without having a separate "How to setup message signing" page.
|
|
|
|
Everything aside, I think this might be a good idea to support. Is there a reason standard PGP doesn't work, though? You mean ASCII-armored? It could work, though I personally prefer something more compact and human-readable. |
|
|
|
I would be all for message-signing if it was a user-friendly feature in Bitcoin-Qt. Can we spec out something for using "signature blocks" like I implemented in Armory? Last I checked, Bitcoin-Qt message signing/verification is a really poor experience for the user. Handling random blobs of hex, manually copying the various pieces around, and possibly mis-copying the messages causing signature verification to fail, i.e. an extra space at the end of the message would cause the verification to fail. NOTE: Armory's message-signing interface is a bit cluttered, because it's merged with a ECDSA calculator, but I had no motivation to clean it up and make it a first-class feature, because it's not terribly useful without Bitcoin-Qt supporting it. I'll update it in a heartbeat if we can interoperate. I'll be happy to compromise -- I will let you guys redefine the idea "signature blocks" (hopefully with similar properties) and I will support it in Armory -- and then Bitcoin-Qt will implement it? After that, I think it will be a feature worthy of "first-class". Example: -----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address: 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message: "Armory version 0.60-alpha was released 2012-Mar-"
"19 07:40pm. Windows binaries have been released "
"in zip files with the following MD5 hashes: [Wi"
"n32::7b6e3dd0e9114523e303db304a87c0d6] [Win64::e"
"930159411483428da40c127f654bf69] Please do not u"
"se any zip files whose hash values do not match!"
PublicKey: 0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
7571cbe492a7222442b75df75b9a84
Signature: 842590674c06b8712bd9aa04ae7e3fd4c09410f6881ec5a361
fcab55433f1d28f569b3771216754f400a5674e24984943d62
9079a8d56b3c5285ee533f8f4f16
-----END-SIGNATURE-BLOCK--------------------------------------- (if you're running Armory right now, you can open Tools-->Message Signing then click on "Import Signature Block" -- copy that text in, and it will verify it) Includes a Base58 address and public key (which must match), the exact message that was signed, and the signature. Select your address, write a message, then sign --> Gives you a signature block Copy a signature block into the box, press "verify" --> Confirmation of address, message and signature Extra Credit: Expand the "bitcoin:" URIs to handle signature requests. This would dramatically improve the process for click-to-authenticate, if the message will fit in a URL string... |
|
|
|
Random update: after two months of working my ass off at work-work and getting engaged (  ), I am finally getting some time to dive back into Armory development. For real. And the first thing I'm doing is... not fixing startup times... but I'm fixing the startup experience by putting the blockchain loading into a background thread. Armory will open immediately and operate like offline mode while the blockchain data is loading. Then switch to online mode when it's done. I already have a proof-of-concept for this, I just need to redesign some of the interface to accommodate mixed-online-offline mode. This should be a massive, all-around usability improvement for Armory. Especially if you only want to load it in order to get a new receiving address. This will not only improve startup experience, but it'll be better for key-importing, too (which will probably switch you to offline mode while you wait for the scan to finish, but you can still use offline-capable features). I'm going to spend a large chunk of this weekend doing that, and maybe I'll even be able to look at OSX packaging (pending py2app behaving itself). Hell, if I got both those done, I think that would be enough for me to be comfortable declaring Beta!
|
|
|
|
Probably the approach necessary will be to have anyone that wishes to have the funds refunded send to you a signed message proving they truly are the owner of that address. The bitcoin-qt client suports this -- you simply pick one of the adresses that the transaction was from and do Sign Message. Anyone can then verify. And if they do that, you might as well just ask them for identity and just keep the payment if that's provided.
While I think signing messages with a particular address for the purposes of identifying one's self is a great idea in concept, I don't see how it's currently possible (unless everyone was using Armory). Last I saw, the message-signing interface in Bitcoin-Qt was weak -- it's not easy to communicate exactly what you were signing, and it's not easy to verify a signature. The person can send you the message they signed, but it won't work if they accidentally added an extra space at the end, or forgot a punctuation mark. I made progress on this by creating "signature blocks" in Armory, but it isn't compatible with any other program. I was waiting for Bitcoin-Qt upgrade theirs so I could help design a cross-client implementation. However, I still believe this is a valid, useful use-case, so I'd love it if the core devs would make this feature easier to use, and then I would make it compatible. The specific recommendation I was making was that you not only sign a message, but you have a signature block that clearly identifies the signature and the data that was signed. In Armory, it looks like this: -----BEGIN-SIGNATURE-BLOCK-------------------------------------
Address: 1ArmoryXcfq7TnCSuZa9fQjRYwJ4bkRKfv
Message: "Armory version 0.60-alpha was released 2012-Mar-"
"19 07:40pm. Windows binaries have been released "
"in zip files with the following MD5 hashes: [Wi"
"n32::7b6e3dd0e9114523e303db304a87c0d6] [Win64::e"
"930159411483428da40c127f654bf69] Please do not u"
"se any zip files whose hash values do not match!"
PublicKey: 0411d14f8498d11c33d08b0cd7b312fb2e6fc9aebd479f8e9a
b62b5333b2c395c5f7437cab5633b5894c4a5c2132716bc36b
7571cbe492a7222442b75df75b9a84
Signature: 842590674c06b8712bd9aa04ae7e3fd4c09410f6881ec5a361
fcab55433f1d28f569b3771216754f400a5674e24984943d62
9079a8d56b3c5285ee533f8f4f16
-----END-SIGNATURE-BLOCK--------------------------------------- You only have to copy that block into the Armory message signing dialog and click "Verify" and it will pop up a window like this. I pushed for this a long time when I first made it, but there was little interest in it. Maybe this is an excellent time for bitcoin-qt to implement something like it so that high-profile use cases (like campaign financing) can leverage it. |
|
|
|
|
Show Posts
