Yes, Armory will not show you any tx that don't satisfy "isFinal()" conditions. A transaction is considered not final if: (1) Locktime+OneDay is in the future (2) Any TxIns have non-0xFFFFFFFF sequence numbers Why is one day added to the locktime? Because I was being ultra-conservative, and wasn't 100% positive that I was handling the timezones correctly (which would open up an attack vector to pay someone using Armory then retract it). Therefore it should show up by tomorrow. I would've been smarter about it, but I didn't have the patience to go hand-craft some transactions and mess with my locale to test the timezones, just to handle a case that 99.99% of users will never hit. Congrats on being in the top 0.01%  |
|
|
|
I will mark this as resolved. The test paper backup defaulted on version 1.35C, and I had to manually select 1.35A. What does this mean? Is my wallet an older version or something? Does it need to be updated? I was under the impression that it defaulted to the correct version I was using. So paper test is %100.
The wallet files are identical for all backup types -- it's the version of the backup not the wallet. In version 0.90-beta, we were able to reduce backup size in half without breaking backwards compatibility (because the saved .wallet is indistinguishable). Hence why they are all "1.35", just with another letter. But we can't tell what version it is without seeing the wallet's private keys: hence why you have to select it yourself. Absolutely nothing to be concerned about The next version will use checkboxes instead of a dropdown box, which will make it more obvious that it may be required. |
|
|
|
|
Well this is why there's a test-backup feature. We've never seen an example of it not working, it's usually a problem with the way it's typed in. Have you selected the proper backup version? Did you enter the SecurePrint code? (does your backup have one?)
Unfortunately, without seeing the paper backup, there's only so much we can do to figure out what's wrong (I'm not encouraging you to send me the backup, btw, I just don't know how much I can do for you).
If you did not use SecurePrint, you can go to make a backup, and under the "More Backup Options" go to "Export Key Lists." In this window it will display the non-SecurePrint paper backup root (and chaincode, but if your backup is 1.35c, you can ignore the chaincode if displayed). This should match what you have on the sheet of paper -- but only if the backup does not user SecurePrint. I don't know if there's any way to show the SecurePrint version.
Also, if an Armory wallet file is encrypted, it will only ever write the encrypted data to disk. The decryption happens in RAM only and immediately zeroed out as soon as the data is no longer needed. The only way to end up with unencrypted data on disk is if you explicitly remove the encryption through wallet properties.
|
|
|
|
I suppose a better alternative would be to hold the key data in RAM until your tx is confirmed, and sign a new transaction with the new txid, if the first one is mutated. Perhaps even broadcast the first one, but immediately sign and broadcast the replacement if the first one is invalidated. I prefer the first one though (where the software just waits before doing anything), which is a bit cleaner.
Interesting. In my example ( https://bitcointalk.org/index.php?topic=459678.msg5113081#msg5113081) where the customer's donut purchase is invalidated because his coffee purchase was malled, the wallet would realize this and then send out a new transaction to remedy the situation [which may occur after the customer has left the store and without his knowledge]. So, the customer could still pay instantly, even if they have no confirmed outputs. Provided the customer is honest (which we already need to assume), the merchant will still get paid even if the parent transaction gets malled by an attacker: the wallet just checks for malling and, if so, sends a replacement TX to fix the problem. My concern with this is that the customer turns off their phone or turns off their computer, and the replacement tx never gets sent. Yet, they saw the "This invoice has been paid" message and didn't realize that it wasn't guaranteed. I'd rather they see nothing positive until the tx is done. But that also assumes that all tx will be mutated. Thus there's no point to doing the first tx. If the standard case is no mutations, it might work. But I am deeply concerned that people will find themselves accidentally reversing paying for their doughnut, and then refusing to allow the replacement tx to go through. i.e. They pay, turn off their device, turn it back on later, and it tells them the payment never went through, please re-type your password to re-send... "hmm, if I just don't type my password, that was a free doughnut!" It's one of those things, that makes me feel like the empirical reliability of zero-conf tx allowed too many businesses to build services around them, which can't be supported now. Technically, you could do an ETF from your bank to pay for your doughnut, or pay with gold flakes, but we don't because the timelines and convenience make it infeasible. I would argue that Bitcoin should be treated somewhat the same way, and it was only a matter of time before the illusion fell apart. Bitcoin is fantastic for a whole lot of things, but Point-of-Sale doesn't seem to be one of them. |
|
|
|
It sounds to me like the way for wallets to handle this (like Armory), is to popup a warning if a user sends one transaction, and then later attempts to send a second transaction that requires unconfirmed change. -- If they are not spending unconfirmed change, nothing needs to be done. User is not inconvenienced. -- If they are, pop up a message to the effect of: This transaction may have problems reaching its intended recipient(s) if you send it right now. You might have to re-create and sign a replacement unless you wait for your previous transactions to be confirmed by the network.
To avoid these issues, please wait until all previous transactions in the ledger have at least one confirmation, and then restart the "Send Bitcoin" procedure as before.
[Send Anyway] [I'll Wait]
I suppose a better alternative would be to hold the key data in RAM until your tx is confirmed, and sign a new transaction with the new txid, if the first one is mutated. Perhaps even broadcast the first one, but immediately sign and broadcast the replacement if the first one is invalidated. I prefer the first one though (where the software just waits before doing anything), which is a bit cleaner. This transaction may have problems reaching its intended recipient(s) if you send it right now. You must wait for your previous transactions to become confirmed. If you click "Send when Ready", Armory will queue the transaction to be sent at that time. If you close Armory before you see it appear in the transaction ledger, you will have to re-send it next time you start Armory.
[Cancel] [Send when Ready]
|
|
|
|
It isn't a security issue it is a usability issue. Traditional double spends require the SENDER to be malicious. That is a rather narrow security scope. For a duplicate tx to break a subsequent tx which uses unconfirmed change output only requires that a single third party on an anonymous global decentralized network is malicious. That is a rather asininely large security scope. It becomes "Are there any bad/mean people in the world right now? If no then you are fine nobody can break your tx. If yes then your tx might break randomly".
...
The user is honest, he is following the rules, creating a valid tx (proper fee, no spam, etc), the merchant is being safe and waiting for a confirmation, essentially both parties are doing the "right thing". However the payment just breaks due to the actions of a third party. Can it be resolved? Sure delete Tx "C", create a new Tx "D" which is identical to C except it uses the change output from "B" not "A" and send again. Now try to explain why you "randomly" need to do that sometimes to a non-technical user.
To a non-technical user it simply looks like the Bitcoin network "breaks" randomly and then you need to pay again, sometimes. Not exactly confidence building huh. Sometimes after you pay it will just break and then you need to pay again. On top of that imagine you believe you paid a merchant and then they ask you to pay them again because Bitcoin broke. It seems suspicious right? I just makes the tx flow counter intuitive.
Until transaction ids are immutable, allowing users to spend unconfirmed change outputs is just going to cause chaos.
Where we are differing is the fact that the alternative is also quite confusing to the user. They spend 0.3 BTC and suddently 54.3228 of their Bitcoins are unspendable. Perhaps it's a better alternative, than the confusion you mention. But I was also responding to people requesting the ability to optionally make unconf change unspendable, i.e. through an option in the menu or CLI argument. That doesn't solve either problem, it just allows knowledgeable users to avoid accidentally double-spending when doing a chain of transactions, but regular users have the same problem. At least with Armory, it already scores CoinSelection solutions spending unconfirmed-change lower than any other solutions. Meaning, it would rather pay a fee and/or bundle extra inputs, rather than include any zero-conf UTXOs (though it will count the ZC UTXOs in your spendable balance, and it will use them if there are no other options). Even though it may not have been necessary, I didn't care much for ZC outputs, which is why I deprioritized them so heavily. It appears to have made Armory as resistant as possible to this problem, without inconveniencing the user (though I admit, it was kind of coincidental that I the criteria I chose happened to be the correct one to minimize the malleability issues). |
|
|
|
|
Can someone please elaborate why the unconfirmed-change-spending issue is a real problem? To me, it sounds like it may cause some users to accidentally reverse subsequent zero-confirmation transactions, and that's it. But the community has been pretty darn vocal about telling people/merchants not to accept zero-conf tx, and there's plenty of ways to intentionally double-spend them without this bug/quirk. It seems that this particular part of the problem is simply making it (more) painfully obvious why they shouldn't be accepting zero-conf tx.
What am I missing?
(Of course I know there's bigger problems with transaction mutability than just spending unconf change, but that seems to be the only issue Armory currently has ... if it's a real issue)
|
|
|
|
|
Basically, I would recommend maintaining and tracking a "pre-signed" ID. This is the hash of the tx without any script-sigs. It is fairly straightforward to take a transaction and compute both IDs instantaneously. Simply create a map/dictionary of PreSignID <--> TxID for all tx that you care about. When new blocks come in, check the TxID as usual, but also compute the PreSignID and check whether you have a TxID associated with it. If you do, treat that object as the original TxID (update your databases and the map).
Similarly, if you are querying directly whether a particular transaction is confirmed -- well you shouldn't have to do anything because you already updated the above map and DBs when you originally processed the tx. For instance, if you were an exchange, above you would reassociate the new TxID with the customer account, and there would be no issue.
I am particularly fond of this because we it will help with multi-signature transactions, for parties to be able to reference particular unsigned/partially-signed transactions, while collecting signatures. Though I'm pretty sure the payment protocol has some mechanism for this already... (does it?)
Also, if you are writing software that handles customer accounts, withdrawals etc. You should have an explicit reissue/replace transaction function -- you would select the txID that you want to "reissue" and you would be sure to double-spend the original one, so that only one of them can be valid. However, this has to be an explicit operation, since simply creating a new transaction with no context would, of course, not want to double-spend any unconfirmed tx.
|
|
|
|
Is it possible to, using Ubuntu 13.10, verify the windows installer? I'm a Linux n00b, so here's my effort: $ dpkg-sig --verify armory_0.90-beta_winAll.exe
E: We can only work on debs and changes files.
Yes, it's easier to do it from linux than anywhere else. From the windows download page, download the Version 0.90-beta signed hashes of installers (or just click that link). That file is signed with the same GPG key: gpg -v armory_0.90-beta_sha256sum.txt.asc
That verifies the hashes in the file are valid, now you just have to hash the windows installer and make sure it matches: sha256sum armory_0.90-beta_winAll.exe Or on mac: shasum -a 256 armory_0.90-beta_winAll.exe Make sure the output of the above line matches what's in the hash file you just verified. |
|
|
|
Any plans to add an option for users to elect to require confirmation of change before spending.
This would be lovely. Obviously an advanced/expert option, but I think it may relatively easy. The C++ backend supplies the UTXOs to the GUI which does the balance calculations, etc, and it currently passes all confirmed and all unconfirmed-sent-to-self UTXOs. It would be almost trivial to implement with a CLI flag, so that the app can reject all unconfirmed regardless of source. Keep in mind that this makes the wallet really weird, since now you spend 0.1 BTC, and 53.87 become unspendable temporarily. That would confuse the hell out of people... thus probably should be an experts-only option. I'll spend a little time today looking at how easy that would be. I think it may as simple as toggling a flag in the UTXO-collection code so that isSpendable() returns false for all unconfirmed UTXOs. |
|
|
|
That means it is immune to one of the two problems facing most clients listed here. A well earned kudo on that. https://bitcointalk.org/index.php?topic=460944.0However what about the issue of breaking transactions which rely on unconfirmed change output. Does Armory not spend unconfirmed change outputs? Does it provide an option to require a certain number of confirmations before change outputs are unlocked for spending? Armory follows Bitcoin-Qt on that one, in that it allows spending of unconfirmed change outputs (but not regular unconfirmed outputs), but only if there are no other coins to spend. Armory favors not spending zero-conf tx over all other criteria, and therefore will not use those change outputs if it doesn't need to. But you are correct it's possible for a subsequent transaction to spend such change. |
|
|
|
|
Indeed, when you encrypt your wallet, Armory attempts to replace the unencrypted keys with the encrypted keys, in-place, hoping that the OS will overwrite the originals on disk. Unfortunately, this is not guaranteed, and it's probably a PhD-level project to figure out how to guarantee overwrite/delete of such data. But it's the best we can do when you start with an unencrypted wallet on disk, and any subsequent copies to other places/devices are guaranteed not to have the unencrypted data. An attacker would need low-level access to your disk to look for sectors that were marked deleted but not actually overwritten (luckily, there's a chance that Armory's operations do work, but it's far from guaranteed).
I guess the best thing to do in this situation is to encrypt the HDD of your offline computer so that the initial restore will still be encrypted on disk (even though Armory is doing it unencrypted). Or restore to a RAM disk, etc, that never touches the harddrive. Then encrypt the wallet and copy the encrypted version to your harddrive. Definitely not the most convenient but probably the best you can do without us fixing this...
|
|
|
|
In my opinion having to share the SecurePrint code among all fragments in an M-of-N fragmented backup scenario, is a security flaw. If an adversary manages to get access to all the fragments without the SecurePrint code (e.g by MITM the printer) he will only have to get a hold of one of the fragments to be able to get the SecurePrint code and restore the wallet.
I don't consider this to be a critical security flaw, but still something worth considering and maybe fixing for a future release.
This was intentional. Multiple codes are not required to protect the fragments from the printer. What you describe is still a multi-point attack, which is the point of fragmented backups in the first place. A compromised printer alone will not result in theft, and a compromised single fragment will not result in theft either. If someone has access to both your printer, and at least one of your fragments, they are targeting you (and have a lot of access to your life), and will probably find ways to compromise you anyway. It achieves its goal of mitigating casual threats, which may attack thousands of people at once (such as malware), and take whatever is easy and unprotected, and forego complex, physical, targeted attacks on any particular person. |
|
|
|
|
Sorry guys, I haven't been seeing notifications on these threads, and I've been on travel so I hadn't noticed it..
Armory does not have any problems with transaction malleability.
There are no security issues with this. Armory does not rely on transaction IDs for anything except transaction comments. If the transaction ID changes out from under you, Armory will silently replace the transaction in the list, and the only thing that will be different will be TxID you see when you double-click on it.
The one problem someone might have is that if it's an outgoing transaction and you created a comment/label for it, that label will not show up on the mutated transaction. Note, that this already happens with offline transactions, because Armory doesn't know what the final comment/label will be until the signatures are added. I had actually thought about using the pre-broadcast ID to store comments to solve this problem for offline transactions. It would also solve it for mutated transactions.
When I first learned about malleability 1.5 years ago I did a review of the code and determined there was nothing to be done. When Armory sees a new transaction in the blockchain that conflicts with a zero-confirmation transaction in the memory pool, the blockchain tx wins and the conflicting mempool tx is removed. It all comes down to the fact that Armory only pays attention to TxIns and TxOuts for computing balances, etc, not TxID.
|
|
|
|
Hi, I recently installed the Offline Bundle for Ubuntu on an dedicated offline computer.
The bundle contained 3 applications:
1) Armory (Test Network)
2) Armory
3) Armory (Offline)
I think I understand what 1) is for (Testnet transactions), but what is the difference between 2) and 3)? They seem identical except for the names.
Thank you!!!
They are the same when on an offline computer. The "offline" version is really just for your online computer, if you want to force it to load in offline mode (there's a few reasons to do this, though most users don't require it). When Armory is installed, it has no way to know whether this is an offline computer, so it installs both anyway. |
|
|
|
Hi, I'm a college student currently studying computer science and am extremely fascinated by bitcoin. I am interested in developing new applications and software involving bitcoin, but can't help but feel that I'm in over my head. Where would be a good place to start if I'm looking to learn how to write code that speaks bitcoin and also learn more about how the bitcoin protocol works in general?
Thanks,
Reed
Do what I did to 2 years ago: write a program that parses the blk*.dat produced by Bitcoin-Qt/bitcoind, and calculates the balance of an arbitrary address/script. That "simple" task will show you the entrance to the rabbit hole The blk*.dat files are just a simple concatenation of blocks, each one is: Magic Bytes (4)
Block Size (4)
Header (80)
NumTx (VAR_INT)
Tx0
Tx1
...
TxN We recently started hiring employees for my company, and this is basically what I've had them doing to get initiated. P.S. - Also developing your love-hate relationship with the available documentation on these things. The above task can be completed mostly with just the documentation at the following links: https://en.bitcoin.it/wiki/Protocol_specificationhttps://en.bitcoin.it/wiki/Transactions |
|
|
|
By my standards, stealth addresses are pretty concrete. But yeah, part of why I was interested in working with someone was to nail down some of the implementation issues in a real-world client, speed being one of them. My basic idea was to have a bandwidth/speed/privacy tradeoff, and there's some interesting ideas being discussed right now on what's the best way to do that. One key implementation question is can the Armory codebase handle addresses where to pay them you have to make a transaction with not just one, but two specific txouts? Once we have an address format and a recipe for converting/calculating the correct values, it will be "easy." Sending to two txouts is not complex at all, it's identifying them which may take a little work, since the code base currently assumes everything it needs to know about a TxOut is contained in that TxOut. But of course, I'll make it happen if this is a popular idea. Excellent! Sorry for the late reply, but I finally got a chance to try that branch out. Looks fine to me, although I see the odd IndexError on the console, not sure if it's related:
(ERROR) Traceback (most recent call last):
File "/home/pete/src/bitcoin/BitcoinArmory/qtdialogs.py", line 9301, in showContextMenuTx
idx = self.addrBookTxView.selectedIndexes()[0]
IndexError: list index out of range
Nice timing, I just merged a whole bunch more changes into 0.91-dev. I think most things are functional, including sending to and displaying P2SH addresses. If you have scripts that spend P2SH outputs, please try it out, since I don't yet have a way to test if my P2SH TxOuts are valid (though they are so simple, I don't know how I'd get it wrong, but of course nothing beats seeing it work). The error looks like you somehow right-clicked to get a context menu without selecting an address in the addr book to show. Perhaps you right-clicked in an empty area of the address book? Either way, it's nothing to worry about. |
|
|
|
Thank you for the help. I appreciate it.
When you say, "you need to up the trust level" what exactly does that mean? Can you point me in the right direction for upping the trust level?
Thanks Again!
Since GPG has no certificate authorities who check IDs, GPG is especially paranoid about making sure you trust the source of the public keys. The idea was to have a huge web of trust of people checking each others' IDs, so that you always have a trusted signature on a new key for someone you don't know. If there are no trusted signatures, then it complains that it doesn't trust it, and it could've been replaced by an attacker's key. Or rather, before it trusts it, you have to explicitly tell GPG that you trust it and have verified it's the correct key. Of course you don't know that for sure, except that it would've been tough for an attacker to replace all instances of the key and fingerprints you are exposed to, and all the downloads/installers that are signed with it. In general, for most users, getting the key from the keyserver is sufficient. If you are holding millions of dollars and consider yourself to be a target, you might do more paranoid checks. So the real answer to your question is: you actually already did it. It says: gpg: Signature made Tue 26 Nov 2013 01:31:01 PM EST using RSA key ID 98832223gpg: Good signature from "Alan C. Reiner (Offline Signing Key) < alan@bitcoinarmory.com>" ... It verifies the signature matches the key, it's just complaining that you've done nothing to identify you actually trust that key. If you want to set the trust explicity, you can do so from the command line: $ gpg --edit-key 98832223
...
gpg> trust
...
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision? 5
Do you really want to set this key to ultimate trust? (y/N) y
|
|
|
|
|
When you select "Backup Wallet", one of the options is "Export key lists". You can get everything you want from that.
|
|
|
|
|
Show Posts
