|
Holy moly that was easy! All I had to do was modify one call to compute the balance and utxoList differently if Coin Control was selected, and it seems to work flawlessly! It treats your coin-selection as if it was your wallet, yet the dialog pretty clearly identifies that you are in CC mode.
If anyone in Linux or OSX wants to try it right now, you can do so by checking out the "coincontrol" branch. You don't even need to recompile (well, you do if you haven't upgraded to 0.85 yet). It is only available under "Expert" usermode. I recommend running it in the terminal, so that you can see the output when you hit the "Send" button. It will dump the coin-selection to the terminal so you can verify that the selection was made correctly. Alternatively, you can click "Create Unsigned Transaction", copy the tx to the clipboard, then re-enter it on the next window and then "Click here for more information about this transaction."
Test this thing! Tell me if something doesn't work or if it's missing something. If it's stable enough, I'll make it official ASAP. There's been so much demand for it over the past year, that I think it deserves its own release!
|
|
|
|
perfect, but still the ugly ubuntu 10.04 look  why no upgrade to the real (maverick and later) ones, i already send ya a PM. thanks for this, gonna love it  Yeah, thanks for the PM, but I'm actually quite fond of the 10.04 theme, so I don't really have any incentive to switch. But thanks for the offer. Got a few more things to work out before it actually works. But so far, it's going much faster than I expected... |
|
|
|
Amazing! Now that I have all this experience with PyQt and a super-versatile library under-the-hood, making the interface was not hard at all! How's it look?   That's purely the interface, showing you all non-zero-balance addresses, and updating the send-BTC dialog to show you the result of your selection. It doesn't actually work yet (it still selects from all addr). Getting that part working is my project for after dinner... |
|
|
|
Integrating a web of trust that doesn't have any roots at all isn't quite so easy. Unless you have access to the full trust graph, you can't build a chain between yourself and the counterparty to prove you own the identity/nym which you are asserting. So the question is how do you build a protocol that lets two parties who don't know each other find enough common connections and then how do you calculate the trustworthyness of those connections. When you have a short chain back to an organization that you axiomatically accept is competent and trustworthy it's easy (until your assumptions are violated, of course). If you don't have that, you need new protocols and bootstrapping mechanisms.
It's a problem easily solved: forget centralized certification and commoditize the actual trust itself. Like eBay feedback points. Every transaction completed to the satisfaction of both parties then credits each party with a new unit of "trust". You would make a public record of it, to establish a picture of how trust in major transaction hubs changes over time. At least then the relative trustworthyness of actors in the system is given an actual value, instead of the current situation of a qualitative notion of trust in the certificate authorities. ...and then people set up fake merchant identities and countless fake customer identities, and bump up their own trust ratings as high as they want before each scam. The best way to prevent this from happening is to elect third parties that are trusted by lots of people, to check identities before letting them into the system... oh wait, I just described the CA system... The CA system isn't perfect, but those who succeed in breaking it are usually high profile (like Mike Hearn was saying: state-sponsored, etc), and they're not going to waste their time stealing the $42 I paid BitBrew for some coffee. But using self-signed certificates, anyone in the coffee shop with me can MitM me if they, perhaps, set up their system with the same SSID and I mistakenly connect through them when making my purchase. Anything that is big enough to be worth stealing on a massive scale is usually done through direct merchant-customer interaction -- you don't usually buy a $17,000 car on the internet with your credit card... such large transactions usually use a second-level (or more-reliable) form of authentication beyond CAs. For "regular"-sized purchases, it makes complete sense to piggyback off of a "complete" system that is already in place, for which everyone who's ever bought anything on the internet is already capable of using. One good thing about Bitcoin is that there is not something like a credit card number to steal. The worst someone can do is redirect a given transaction, but nothing like getting your CC number and draining your available credit, leaving you to spend hours on the phone with credit agencies trying to restore your "trust." Therefore, a passive eavesdropper who is able to decrypt the payment stream cannot directly benefit like they would with credit card transactions: with CC, they decrypt and steal databases of CC numbers and sell them on the black market (probably with BTC). But getting a database of past transactions executed in this way (via BTC) does not offer the attacker anything. |
|
|
|
Then, I guess we might as well start using http:// for credit cards transactions and email now. Since there's no value added by the CA system... That's a false dichotomy and dishonest. The relevant question is how much value the CA system adds compared self-signed certificates, not compared to unencrypted traffic. The answer is: it makes MitM attacks dramatically more difficult to execute by an arbitrary attacker. Self-signed certificates are useless against MitM attacks. I consider that a huge benefit for an irreversible payment system, even if it's not 100%. |
|
|
|
Just because there have been security breaches, doesn't mean that the system is useless. Of course it does. If you can't rely on it you don't have security. "This fire extinguisher doesn't always fail, only when I try to use it. It's fine most of the time." Then, I guess we might as well start using http:// for credit cards transactions and email now. Since there's no value added by the CA system... If you are doing things that require ultimate security, at the risk of millions of dollars, I agree with you. But for sending $23 over the internet to pay for your water bill, it does exactly what it is supposed to do. |
|
|
|
Just because there have been security breaches, doesn't mean that the system is useless. While the system could be improved, the alternatives are terrible. If you don't use an established system, then you need to build up a whole new "web of trust", and users and merchants will be doing a lot of work, outside an established system, just to accommodate this use case (Bitcoin payments). If what you suggest is true, then credit card payments on the internet are a joke, too. Really, it's not quite black and white like that... |
|
|
|
Don't know nothin about any mailing list, but this scares me: "Requests for payment (Invoices) are tied to authenticated identities using the only widely-deployed identity authentication system we have right now (X.509 certificates signed by root certificate authorities)"
I'm certainly no expert on bitcoin's protocol or code, but it sounds like a bad idea to add any sort of centralization. I've never really trusted 'root certificate authorities' and I have heard of exploits being successful against them.
Why does anyone need identities when invoicing? Or more accurately, why must every invoice have an identity attached?
I too, felt uncomfortable about using the CA system. It feels like a psuedo-centralized, corporate-privileged system that milks little guys for high profits. I feel like it's not "in the spirit" of Bitcoin... But then reality set in -- which is that the CA system does provide quite a bit of value. Regardless of how much you get pay to get a signed a certificate to run your website from some "corporate overlord," you are getting security against MitM attacks. And that is important, especially for invoices and payment requests with irreversible Bitcoin transactions. This protocol can slide right into the existing CA infrastructure, and instantly provide on the protections that the system already gives to most other security-sensitive internet services. In that sense, it is a massive boon to be able to piggyback off the existing infrastructure, since Bitcoin already has enough hurdles to get wider acceptance. This won't be one of those hurdles. |
|
|
|
that would be awesome, do you accept a DVC tip?
What is a DVC tip? I always accept tips Given the magnitude of implementation complexity, I guess it makes sense to jump into coin-control now... compared to how long it will take to do the new wallets, it looks like noise... |
|
|
|
So I am running Armory while the blockchain is still loading in the Satoshi client. This is somewhat annoying but there is a balloon in the OS that pops in and out and says Armory is "Disconnected" and "Connented" in the lower right corner. This happens a lot while the Satoshi client is loading the blocks. Once the Satoshi client is done the balloon continues popping out in and out.
I am using Windows Vista 64bit and Armory 64bit.
EDIT: I restarted Armory when the blockchain was loaded in Satoshi and it works fine.
Btw, the latest version should have a warning window pop up now, telling you it detected this condition, and please stop Armory until Bitcoin-Qt is sync'd. It's not the best solution. But it makes the user aware that the bizarre behavior is not a "feature." |
|
|
|
Ok, I found something that's broken. When I try to sign a message with a key that's in a watching only wallet, it crashes hard with this in the debug log: Well then, don't do that!  To be fair, it sounds like I need to put some more protections on some of the dialogs when the user is using a watching-only wallet. I thought I had caught a lot... but I guess not yet. Getting people to test has been hard, so I keep finding stupid stuff like this that has been in there months. Perhaps I need to start offering 0.1 BTC bounties for finding bugs in the software -- I bet I'd get a lot of people digging in hard! Or I might go broke... What about killerstorm's changes to support colored coins? Might those be a starting point?
He actually already contacted me and I suggested that there will be room in the new wallet format for including "extra attributes" with the addresses. I don't plan to mess with colored coins myself, but it might make it easily extensible by others. Armory does not support coin-control, but I think it will not be terribly difficult to support. I just have some other priorities. I *do* plan to add it when I'm feeling stuck with some major other feature upgrade damnit, im looking for such a client :S and i really like armorys design. You're not the first person, by far, who has asked for this. I suppose I could bump it on the priority list for after beta -- because not only is it in high demand, I don't think it will be that hard. I think I already know how to do it, I just need to devote a day or two to implementing and testing. Luckily, the underlying libraries already have all the hooks I need (I just create a new wallet in RAM with only the specified addresses, and retrieving its balance and creating transactions with it is trivial). And I think I already know how to create the window to let you select the set of addresses from which you want to spend coins... Maybe I'll do it this weekend! I am already kinda stuck with the new wallet format, while I wait for feedback about my design ideas... |
|
|
|
Armory does not support coin-control, but I think it will not be terribly difficult to support. I just have some other priorities. I *do* plan to add it when I'm feeling stuck with some major other feature upgrade |
|
|
|
can i recommend a lite/liter version of armory?
You wouldn't be the first. Right now, this is the cost of the features that come with Armory. However, I should be able to pull down the system req'ts after I'm done with the wallets (at the expense of using more HDD space). And eventually I want to have an actual-lite version (also known as "Standard usermode" -- it would be a purely pruned version, and only track your balance, not the transaction history) |
|
|
|
That works for me and am satisfied just by that you understand what I propose well enough to decide whether it's appropriate for inclusion in your client, even if the answer is no.
The answer is: you just seeded an excellent discussion about the far future of Bitcoin escrow/contracts, but I think that future hasn't arrived yet. And when it does arrive, I'd love to see that discussed and developed into an inter-client standard. Until then, the M-of-N cases are dramatically simpler, and can actually be used right now, thus it warrants a separate [simpler] treatment (plus, there will probably be some lessons learned from M-of-N execution to be applied to the more-general case) |
|
|
|
Another Mac OS X bug  I exercised the newest Armory from the threading branch, almost everything works fine, although it does tend to exhibit brief "freezes" when you expect a window to open or close, and nothing happens for 5-10 seconds (while one core of the CPU runs at 100%). There is however a rare but important function that fails on Mac OS X: Printing a paper backup. Again the problem is that Qt pops up a native print dialog, and it is dead. However, in this case there is no non-native dialog to fall back upon, apparently the native print dialog is always used on Windows and Mac OS. In this case I was actually able to open a second print dialog by pressing the Print button again while the dead first dialog was open. That was followed by a segfault a second later. It suspiciously looks like a Qt bug, which would make it really hard for you to work around it. Personally, I can live with this bug. I can print any paper backup from the offline computer (running Linux). But it is annoying, and I will continue to investigate. This is really unfortunate. I'm not sure why threading is causing such problems, since it doesn't seem to have anything to do with the multi-threading I implemented. I definitely cannot setup a print dialog myself, I most definitely need Qt to help with that. I wonder if there's any other dialogs that cause this problem...
Unless I hear something compelling, I think I've made my last change for beta. It was an update to signature encoding that the Bitcoin-Qt devs would like to make more rigorous... and I pulled in the terminal-signing-script for offline computers ("python extras/cli_sign_script.py wallet.file some.unsigned.tx"). It seems I've already had 300 downloads of the version I posted a couple days ago! People must be using it, and it can't be that bad if I haven't gotten any real bug reports yet (besides the OSX issues). If you've been using 0.84.5, please post here and let me know that you have been, and any comments about it, with regards to my plan to make it beta! I am looking for that boost of confidence I need to pull the trigger on it! P.S. -- While looking at the new wallet format I want to create, I figured out how I'm going to integrate unicode support. It won't be part of beta, but it will definitely be part of the new wallet release. Sorry to all you non-US that use all those weird characters in your tx comments and filenames That support is coming! |
|
|
|
|
@Casascius,
I recognize that you are proposing something of ultimate flexibility and versatility. And I actually really like the idea for arbitrarily complex transaction types. But M-of-N transactions are a degenerate case of that large space of possible transaction types. Combined with the fact it will be spectacularly more-common than those other cases, I think it's not unreasonable to have a separate "shortcut" method for setting them up.
However, I do like where your idea is going, and worth some further discussion. I'd really like to have a way to document and execute these crazy transaction types, I just think a fully developed solution for that is out-of-scope for now. I think I will leave room in my design to accommodate "relationship" entries in the wallet. When it is fully developed, I can switch all multi-sig tx over to that...
Though, why can't such relationships be developed by a central organizer? Rather than distributing the relationship object and letting each person pick a place... there is at least one person that already knows how it should be setup. Have everyone send that person a public key/wallet, and he will set it all up. Perhaps the final result can be signed by the private keys of all included public keys, or something like that.
But for now, I think it makes sense to shortcut the couple degenerate cases of 1-of-2, 2-of-2, 2-of-3, 3-of-3, and handle all the details automatically for the user. A user simply wants the transaction to require 2 of 3 signatures, and has his own private chain and the other two public chains. He doesn't care about the internal ordering of keys, but he does require everyone to use the same ordering. He also wants to avoid address collisions in the event that multiple parties try to create transactions at the same time with the same ordering. I think this technique resolves all of that, and can be represented quite simply to the user.
The issue with look-ahead in deterministic wallets is an annoying problem. Most regular users, really don't need more than 10 addresses lookahead, 100 to be safe. However, e-commerce users/merchants might need significantly more lookahead than that. For that reason, I defaulted to 100 address lookahead with Armory, and added a button to let users extend the lookahead as far as they want. I expect that any business users interested in this application, will have the knowledge to know which knobs to tweak -- i.e: set lookahead to 10,000 addresses & disable second chain.
Therefore, Armory users using two-factor auth as I have described, only have 100 extra addresses in their wallet. One time. If the second chain is never used, then it never increases. The way Armory scans the blockchain, search time is O(log N) in the number of addresses in the wallet (because they're stored in a BST in RAM, so that's how long it takes to check if an address is in your wallet). As such, 100 extra addresses is trivial, both in HDD space, and extra computation time. If the user needs more than 100 lookahead, they are also likely knowledgeable enough to know what options to change for their application.
|
|
|
|
While you're doing a rewrite, you may consider adding support for output "attributes". E.g. projects like the colored bitcoins would vastly benefit from code like that ( https://bitcointalk.org/index.php?topic=106373.0), because their algorithms needs to keep track of the color state of individual outputs. I already have an "extraAttributes" field which is intended to accommodate non-Armory addresses and address chains. I don't know who else would be leveraging the code base, but at least it gives me room to, say, import and maintain an Electrum-deterministic wallet chain and store any necessary extra information in that field that doesn't fit into the Armory-specific structure. I'm not sure of exact implementation details, yet, but I do want to try to leave room for things I haven't thought about, yet. I suppose colored-coin attributes could go there, too. |
|
|
|
With regard to ordering of wallets I never imagined this to be a problem. Mainly because in my mind, somebody would be proposing the relationship with a specific number of vacancies which may or may not be equivalent in purpose. If A were to propose (A AND B) OR C, someone entering that relationship needs to explicitly be choosing slot B or slot C, there would be no ambiguity as to what party is in what slot and they cannot just simply take the first available slot. Further, I imagine that when the relationship was defined, each of the roles would either be allowed or not allowed to generate addresses. (If B is just a smartphone validating A's transactions, then it would be a waste of resources to assign a chain for B it will never use, but which A will have to walk up and down that chain looking for transactions at great CPU expense just in case it somehow did).
If I use those assumptions, then the field containing the list of parties able to generate addresses would dictate a fixed order and also dictate how to manage the chains so that all parties know where they generate from, assuming they are set to be able to.
I have more reading to do on the contracts and chains and how they work, so it is probable that my assumptions reflect a deficient understanding of those.
My understanding is that we don't have real capability to do ((A and B) or C) yet (or at least, it's not standard), and that only M-of-N multisig is really enabled. I know you could execute any arbitrary script if you find a miner to do it for you, but that's not in scope for me -- I'm sticking with transactions that will be accepted by the network without special actions. (I just confirmed with Gavin that non-M-of-N transactions are not standard; redeeming such a P2SH script would require a miner's help) However, I agree that the design here should be extensible to these cases, when they become available in the future. But it also seems unnecessary to require extra user-interaction for regular M-of-N transactions where the specific ordering is actually irrelevant to the users, as long as it is deterministic and accessible to all participants. As a user entering a 2-of-3 wallet with two other parties, I don't actually care what order they go in, and asking the user to specify a totally arbitrary ordering is not only confusing, but ripe for people to do it wrong -- i.e. user A chooses {A,B,C}, but user B accidentally sets up their wallet with {B,A,C}, and then things get all out of whack... Also, I don't see a reason why there should be a special case for desktop+second-factor (smartphone) vs shared-spouse-wallets. Just have all 2-of-2 wallets pretend that both chains could be used, because the resource usage of watching for a few extra addresses is trivial. If it's really a concern, there can be an option in "Expert" usermode to disable the second device chain if you know it won't be used. |
|
|
|
I was under the impression that P2SH was intended for all multi-sig transactions, though you are right there is no reason plain-text multi-sig can't be used (is there? they were probably never added to isStandard...). One reason for desiring P2SH, in general, is that very long scripts become part of the TxIns instead of the TxOuts. This means that they will never bloat a pruned version of the blockchain. If everyone only used P2SH, then no TxOut script would ever be longer than 22 bytes.
You can use plain multisig if you like, they WERE added to IsStandard. Ahh, so it does make sense to use P2SH for paired/linked wallets, and regular multi-sig for escrow tx, etc. For some reason, I was under the impression that P2SH was intended for everything. I do prefer plain multi-sig for those escrow tx. @Mike, I'm not sure the payment protocol changes this much. It means that the decision about which form to use will be irrelevant to those using the payment protocol, but there will still be users who will do it the "old" way, which should still be accommodated. Though it sounds like we already have a consensus ... it makes sense to use P2SH for linked wallets, and regular multi-sig for isolated escrows and contracts.
@Casascius: I was just about to post an expanded idea for linked wallets, but I think you already did it. I'll restate it, though, for clarity, and maybe add a little. Let's say I make wallet A/j, and my spouse creates wallet B/j. We exchange the root of the external/internal chains. Meaning, we exchange the data needed to not just generate one chain of addresses, but both the primary chain and change chain. So, I give her A'/j and she gives me B'/j. All addresses generated by my wallet will be of the form 2of2([A'/j/0/x, B'/j/0/x]) and all change will go to 2of2([A'/j/1/y, B'/j/1/y]) -- external chain is 0, internal chain is 1. The order will be switched for her wallet: she will create addresses of the form 2of2([B'/j/0/x, A'/j/0/x]) and change will go to 2of2([B'/j/1/y, A'/j/1/y]). So each wallet will only generate addresses from its own two chains, but watching for addresses on all four chains. I'm pretty sure that's very similar to what you suggested. EDIT: to avoid ordering issues for 3+ wallets, the addresses should be ordered by wallet fingerprint order, and each wallet always generates addresses starting with their own in that list, wrapping around. So if the wallet fingerprints end up ordering the wallets B, A, C, then all 2-of-3 addresses generated by wallet B will be {B,A,C}, wallet A will be {A,C,B} and wallet C will be {C,B,A}. That makes sure there are only N possible address orderings (one per party), instead of N-factorial |
|
|
|
hi two things i noticed after trying armory.
#1. my computer freezes sometimes, i have a quad core cpu and 4 gb of ram, this shouldn't happen.
#2. i cannot delete wallets without deleting the .dat file
#3. have you considered making it easier to delete wallets for one time use purposes?
#4. what is the difference between bitcoin-qt encryption and armory encryption, seems the same?
(1) You're right, computer freezes should not happen. The whole computer freezes? Or just Armory? For how long? If you do experience it, can you please email me a copy of the log file? (File --> Export Log File) (etotheipi at gmail dot com) (2) There are no .dat files in Armory. What are you deleting? And please don't delete any files in the .armory directory -- that's a good way to lose stuff you didn't want to lose -- everything you need to be able to do should be accessible from Armory itself. At least make paper backups of your wallets before you delete anything... (3) Wallets are very delete-able -- just open the wallet properties and click on "Delete/Remove Wallet" on the right-hand side. (4) Bitcoin-Qt encrypts your wallet by hashing your passphrase 25,000+ times, and using the result as an AES256 encryption key (this is called key-stretching). This slows down an attacker trying to brute-force your password quite a bit. However, hashing and AES can be implemented very efficiently on GPUs, so any Bitcoin miner could use his mining rig to brute force an encryption passphrase fairly efficiently. On the other hand, Armory key-stretching uses a process that not only requires a lot of computation, but also requires multiple megabytes of cache/RAM. GPUs are super fast because they have thousands of threads working in parallel, but each thread usually only has a tiny amount of fast local/shared memory. If each thread needs 8MB of cache, it just won't be able to do the computation at all --- or the GPU must run with dramatically-reduced parallelization so that it can allocate that much memory to each thread. This is what is meant by "GPU-resistant key stretching." |
|
|
|
|
Show Posts
