So when I am sending coins from any one of my wallets, Sometimes I have to keep hitting the unlock password button until it will actually send the coins. Then I looked in the error log and saw this 2013-03-09 18:28 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2060, in unlock
self.unlock(secureKdfOutput)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:28 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2060, in unlock
self.unlock(secureKdfOutput)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:28 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2060, in unlock
self.unlock(secureKdfOutput)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:28 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2060, in unlock
self.unlock(secureKdfOutput)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:28 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2060, in unlock
self.unlock(secureKdfOutput)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:29 (INFO) -- qtdialogs.py:5379 - Change address behavior: Feedback
2013-03-09 18:29 (INFO) -- qtdialogs.py:5379 - Change address behavior: Feedback
2013-03-09 18:29 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:29 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:29 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:29 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
2013-03-09 18:29 (ERROR) -- Traceback (most recent call last):
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/qtdialogs.py", line 62, in acceptPassphrase
self.wlt.unlock(securePassphrase=securePwd)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 8335, in unlock
addrObj.unlock(self.kdfKey)
File "/usr/local/Cellar/armory-qt/0.87-beta/share/armory/armoryengine.py", line 2091, in unlock
raise KeyDataError, "Stored public key does not match priv key!"
KeyDataError: Stored public key does not match priv key!
My version 2013-03-09 18:15 (INFO) -- armoryengine.py:571 - Armory Version : 0.87
2013-03-09 18:15 (INFO) -- armoryengine.py:572 - PyBtcWallet Version : 1.35
2013-03-09 18:15 (INFO) -- armoryengine.py:573 - Detected Operating system: Mac/OSX
Ack! That looks like a corrupted wallet! The only time I remember seeing that is when I was messing with a wallet file and destroyed some data. Unfortunately, the error doesn't lead to a very agreeable way for me to investigate further (unless you want to send me your private keys and wallet file so I can check on it...). Perhaps it got corrupted somehow on the way to being encrypted. I have the app restore from the parallel backup when it detects an error in the wallet file, but that error cannot be detected until you try to unlock your wallet, which happens after the check  Do you have a paper or digital backup? Can you try backing up the wallet manually (from your home directory), then remove it from Armory and restore from backup? Then try again signing again. Was there anything special about this wallet? Was it originally restored from a paper backup? From the new fragmented backup? Do you know what version created it, or when you created it approximately? |
|
|
|
For now, the brew solution is the easiest. To do it yourself without brew... sounded like a total bear!
I'm about to post a bounty thread in the Armory sub-forum, to encourage someone to help me make a distributable OSX package, once and for all. I have zilch OSX experience, and people who do have OSX experience are struggling with this -- so it's way too daunting for me.
You'll see a thread, soon. There will probably be $1,000 worth of bounty for it!
make sure you get a few indepnedants to verify it....for bugs and worse esp if you know zip about it. There will be thorough reviews of it before it's accepted and merged. Luckily, there's a lot of similarities between OSX and Linux... so it will be much easier for me to verify a correct solution than it will be to do it myself. I'll be taking the "recipe" that the bounty-taker provides, and redownload all the libraries, and re-package it before I sign it. I'll also make sure to get testing on a variety of systems. But once a decent solution is found, even if it's got some minor issues, I can figure out the rest of it myself. |
|
|
|
I'd like to know more about this and SatoshiDice may be willing to fund all or a large part of it. I know Alan and have great respect for him.
How much is needed to make this happen? And, do any core developers dislike Alan's plan, and why? I realize this has probably all been discussed somewhere... links or excerpts are appreciated.
Alan if I forget to respond on this thread, please contact me on gmail.
Unfortunately, I have some other very important, selfish priorities. I absolutely would love to work on this, but I don't see where I'd get the time in the next 6 months. On the other hand, if the blockchain could survive until then, I wouldn't mind working this into my priorities in about 6 months. There have been lots of discussion with the devs, though the most interesting ones I've had were on IRC. The biggest concern was expressed by gmaxwell, which was that he doesn't see it being acceptable to further expand the computational requirements of miners, despite the benefits that are offered by this idea. It risks creating further centralization, when miners with less-powerful hardware are pushed out. That doesn't mean it couldn't exist in a side-chain, it just means that he doesn't think it could ever be accepted into the core protocol -- which I think would be a desirable goal for this in the long term. On the other hand, actually getting this working in a side-chain, and exploring the dynamics of this solution (and the associated benefits), may start to change peoples' minds. If it turns out to work as expected, and 80%+ miners are supporting it anyway, then there may be a push for it to be adopted in the next hard-fork because of the benefits to the network. Personally, I'm of the opinion, that if it doesn't change the amount of work/resources required of miners by more than an order of magnitude, then it should be absolutely be done. This isn't just an "upgrade", it changes the nature of the network in dramatically positive ways. The trade-off between usability and security is effectively eliminated for regular users. Any device could boot up with a clean slate and get everything it needs to operate fully and securely, with a couple MB of download. Making this "service" part of the protocol, you are then giving miners a very good excuse to support this service that many miners will probably already be providing. This would just be a way of making it secure. |
|
|
|
are you sure you gave us the right tx? i only see 2 inputs.
You have to click "Show scripts & coinbase". There's only two input addresses, but there's 409 UTXOs being spent by the 12vNB address. |
|
|
|
|
For now, the brew solution is the easiest. To do it yourself without brew... sounded like a total bear!
I'm about to post a bounty thread in the Armory sub-forum, to encourage someone to help me make a distributable OSX package, once and for all. I have zilch OSX experience, and people who do have OSX experience are struggling with this -- so it's way too daunting for me.
You'll see a thread, soon. There will probably be $1,000 worth of bounty for it!
|
|
|
|
I'm advertising for BitcoinStore.com, because I'm quite pleased with this particular product and you can buy it from there with BTC. I've recently become more concerned about malicious printers, so I wanted to have a small, cheap printer to go with my crappy offline laptop. In the past, I used an existing printer temporarily disconnected from the internet and connected via USB, because printers aren't supposed to be able to remember anything. That Samsung vulnerability made me think otherwise... So here it is: the HP Deskjet 1000/j110A. It cost a whole 0.79 BTC including shipping. It's small, it's light, and it works with Ubuntu 10.04 with pre-installed drivers*, and it comes with quite a bit of ink. I suspect these printers are just old and being sold at "below value" to make room for newer products.
HP Deskjet J110A Inkjet Printer - Color - 4800 x 1200 dpi Print - Plain Paper Print - Desktop 
* NOTE: The default driver selected for this printer in Ubuntu is wrong. When it asks you which driver to use, select "HP", then DesignJet 110 (NOT "Deskjet"). Do not print a test page, since it will waste a ton of your precious ink! Test it by printing a backup!* NOTE2: This printer does not come with a USB device cable. BYOUSB. |
|
|
|
MY FAULT! I really had a typo I guess. Now it worked fine and I got a nice msg that the wallet is already imported  Thx! My fault, too: that's not an unusual kind of user-error -- I should definitely catch that! It's on my todo list for the next release! Thanks! |
|
|
|
Bug report: I just created my first paper wallet and tried to import it after printing it out on an offline machine (so I used the Armory Offline Client  ). I clicked "Restore from paper wallet" and typed in all the letters, I checked it three times for mistakes. After I clicked the OK button it happened nothing (Tried it with checked and unchecked "Encrypt wallet" checkbox.). I clicked one more time OK and the app gave me no feedback beside of the visual button click effect. Armory did not crash, I was able to click cancel and go back to the main window. Can it be that this did not work because my wallet was already imported? If yes I would expect a msg like "This wallet is already imported". Then I would also know that the import has worked and would not have to remove the wallet first, import and encrypt it again to ensure the functioning of my paper wallet and the import function) Armory version: 0.8.63 OS: Ubuntu 10.04 32bit You should've gotten a message like you suggested. I have billions of catches like that... Can you go check the /home/username/.armory/armorylog.txt file on that computer and look for some useful information. I know you can't send it to me from the offline computer, but the error message would be fine. Usually when a button is supposed to do something, but doesn't do anything, there's usually errors kicking around under the hood. Here we go. This must it be: 2013-03-09 10:35 (ERROR) -- Traceback (most recent call last): File "/usr/share/armory/qtdialogs.py", line 3706, in verifyUserInput rawBin = easyType16_to_binary( str(self.lineEdits .text()).replace(' ','') )
File "/usr/share/armory/qtdialogs.py", line 3872, in easyType16_to_binary
return hex_to_binary(''.join([base16_to_hex_map[c] for c in b16str]))
File "/usr/share/armory/armoryengine.py", line 897, in hex_to_binary
return bout.decode('hex_codec')
File "/usr/lib/python2.6/encodings/hex_codec.py", line 42, in hex_decode
output = binascii.a2b_hex(input)
TypeError: Odd-length string
It looks like you are missing some characters in the typed field. I guess I only catch errors in the typed letters, not missing letters. I'll add a condition to catch that... When you have typed enough letters, it should automatically respace the chars for you into blocks of 4 letters. There's a total of 9 blocks on each line, so 36 letters. If you don't have that.... let me know! |
|
|
|
However, you could really only use M-of-M backups... No arbitrary subsets.
What I described was a 2-of-3 backup, since any two parts would reproduce the entire sheet with a bit of overlap. I agree it is inferior to the method you are implementing, but while lacking a GUI interface to restore that, assembling two pieces of paper is at least hard to get wrong. Oh I get it... yeah, clever. My comment is still valid: it is "safe" since there's so much entropy in the current paper backup that even requiring brute-forcing any 1/4 of it is still prohibitive. So yeah, the terminal interface I produced is really a stop-gap, to make it available in some capacity until I get the new wallets implemented. However, you can feel good that it will remain supported, because I plan to be using it for a new-and-important wallet I'm creating |
|
|
|
Hi,
I'm using bitcoin-Qt client with a datadir different from the system default; I've just installed Armory, It is connected but the block number count is stuck at the size of the blockchain in the system default Bitcoin-Qt data directory.
How cain I make Armory read from the updated blockchain?
You can start Armory using the "--satoshi-datadir=/path/to/it" when you start Armory. If it's windows, just right-click the desktop icon for Armory and select properties, then add it to the end of the "Target:" line (with a space between the existing command and this one). |
|
|
|
The N-of-M scripts are a really good idea, and I will probably use them for my own use. However, it is a bit too complicated for my loved ones to do the restore. I know that will come soon to Armory, but in the mean time, what do you think of this "poor mans 2-of-3 paper backup": 1) Print two ordinary paper backups. Cut off the QR codes and destroy them. 2) Cut off the left 1/3 of one of the papers, and the right 1/3 of the other. 3) Store three envelopes in three places, each with 2/3 of the key. From any two envelopes, the entire sheet can be recovered. Clearly this lacks mathematical elegance, and gives no credit in the crypto community. Also, it leaks a significant amount of the key if just one part falls into the wrong hands. But with 256 bits in a key, that still leaves 85 bits for the average burglar to brute-force. And if there are both a root key and a chain key of 256 bits each I quess it will be more like 170 bits. Have I overlooked a problem with this method? That's wouldn't exhibit the awesome property I described about SSS giving no brute-force advantage to an attacker with less than M pieces. But there's four times as much data in the current backups than needed (theoretically), so even if you broke it into four pieces, each piece would still have sufficient entropy (128 bits each). However, you could really only use M-of-M backups... No arbitrary subsets. |
|
|
|
Bug report: I just created my first paper wallet and tried to import it after printing it out on an offline machine (so I used the Armory Offline Client ). I clicked "Restore from paper wallet" and typed in all the letters, I checked it three times for mistakes. After I clicked the OK button it happened nothing (Tried it with checked and unchecked "Encrypt wallet" checkbox.). I clicked one more time OK and the app gave me no feedback beside of the visual button click effect. Armory did not crash, I was able to click cancel and go back to the main window. Can it be that this did not work because my wallet was already imported? If yes I would expect a msg like "This wallet is already imported". Then I would also know that the import has worked and would not have to remove the wallet first, import and encrypt it again to ensure the functioning of my paper wallet and the import function) Armory version: 0.8.63 OS: Ubuntu 10.04 32bit You should've gotten a message like you suggested. I have billions of catches like that... Can you go check the /home/username/.armory/armorylog.txt file on that computer and look for some useful information. I know you can't send it to me from the offline computer, but the error message would be fine. Usually when a button is supposed to do something, but doesn't do anything, there's usually errors kicking around under the hood. |
|
|
|
If dust collection is ever going to happen it should be started as soon as possible, because each day a certain percentage of bitcoin users will die, lose their private keys, stop using bitcoins, or otherwise stop making new transactions. The sooner dust collection starts the less of those outputs will stay in the UTXO set forever.
Well I do agree, I would feel more inspired to optimize my dust collection algo in Armory, if it helped me avoid requiring my users to pay a fee.. |
|
|
|
True, it doesn't require any protocol changes... but it does require miners to care. At the moment they don't care, because they still use the full blockchain. No one uses the UTXO set. I was sure that I recently saw a pool operator vocally complaining about a certain service bloating the blockchain with unprunable outputs. Maybe I was just imagining it though. To say they "don't care" was perhaps too strong of a statement. I think everyone acknowledges that it will be important in the future, and would like to see a pleasant blockchain waiting for them when we get there. But I think UTXO-only nodes are not happening for a while, so their immediate priorities are different. |
|
|
|
Would it be hard to allow import of private keys in the minikey format, as well as full private keys?
<spam>Armory has this feature</spam> EDIT: In fact, if you really want it but don't want to use Armory, you could load Armory in offline mode, then import the mini private key, and immediately export it. Armory doesn't save the minified key, only the full key. Then you can import it elsewhere. |
|
|
|
Thanks a lot for the donation. I modified the script so that it saves its state between runs, so it only needs to search the new blocks each time I run it. The vast majority of the time it takes it loading the blockchain files, which is all done in C++ anyway. I guess if there was some way of just loading the newest bits of the blockchain that would speed it up a lot, but it's really not an issue at the moment to load the blockchain into your script once a day. All I do at the moment to load the blockchain is: TheBDM.setBlocking(True) TheBDM.setOnlineMode(True) Yeah, and there's no reason it can't collect the SD statistics as it does that first blockchain load. Then it'd be done before you run any code after "setOnlineMode". Unfortunately, it's not as simple as just adding the addresses to the initial scan wallet, because you need to ignore non-bet transactions. It would require altering the C++ scan loops, but I bet it wouldn't be too terrible... But other priorities call. If it is running okay, then why fix it if it ain't broken! |
|
|
|
Is it feasible to get such an improvement into an official version during 2013? Solo miners and pool operators could change how they prioritize transactions at any time. To make dust collection automatic it would require changes in the various client programs. Any client that can do coin control could do this manually. True, it doesn't require any protocol changes... but it does require miners to care. At the moment they don't care, because they still use the full blockchain. No one uses the UTXO set. But once they start transitioning, I'm sure we'll see fee "schedules" get stirred up to reflect their new priorities. Armory already does some degree of dust collection, but it doesn't do a very good job of it. The logic has been tested, but I think it doesn't work well in practice, unless you recycle addresses a lot. Part of it, is that I didn't want to reduce anonymity just to clean up dust, and frequently throwing in that dust would link more addresses on the input side, so I avoid it. Only if you have a default coin-selection that includes addresses that also have dust inputs, then it will throw it in there. Someone recently brought up the idea that I don't have to consider same addresses only.... I can consider dust from any address that is already linked to one of the addresses on the input side. There's no privacy issues if the addresses were already linked. But that's a much more complicated algorithm to figure that out. Maybe one day it will reach priority for me... |
|
|
|
Without any changes to the protocol itself miners could make it economical to create transactions which reduce the UTXO set by changing their transaction rules to favor transactions which reduce dust. Once this happens, clients could be programmed to do that automatically.
One way it could be done: if all outputs are above the dust cutoff, and if N inputs are below the dust cutoff, prioritize the transaction as if it included N*the minimum fee in addition to fees which are actually present.
I don't think the BTC-size of the inputs should matter. Simply look at whether it increases or reduces the global UTXO set all full nodes will have to track. Even huge transactions should be free if they combine dozens of inputs into a one or two outputs. As long as it is very expensive to go the other way. In fact, you could look at the contraction efficiency of a transaction: how many kB did it use to remove X UTXOs from the set? Above a certain efficiency, those tx should be free. Any neutral or negative tx will be charged a fee, with the highest fees going to those who dramatically expand the set. But the rules should be balanced so that it's not cheaper to send 100 single-output transactions instead of a single 100-output tx. |
|
|
|
This is great.
Side note: I just spent several minutes trying to come up with a A ∧ (B ∨ C) = (A ∧ B) ∨ (A ∧ C) scheme. The "DOH!" moment was when I realized that, since B ∧ C is useless, I might as well just set B = C and implement the scheme as K = A ⊕ B = A ⊕ C. No fancy geometry required!
While practically useless, I'm still interested to know if a A ∧ (B ∨ C) scheme is possible where each piece is independent (gives no information about any other piece) and (B ∧ C) gives no information about K.
I assume you're talking about trying to create "A or (B and C)" backups. My solution to this is quite simple: Create B and C. Backup copies of both B and C to wherever you were planning to backup A. |
|
|
|
|
Show Posts
