You don't have to be good at shuffling: just play 52-card pickup with yourself  Or less chaotic, just put all the cards on the floor or table and swirl them around for 60 seconds then put them back together. The ordering of a deck of cards has 225 bits of entropy which is technically overkill anyway: 128 bits is generally accepted as forever-secure. You'd have to be trying hard to "cheat" to end up with less. Alternatively, you can roll a 6-sided die 50 times to get approximately 128 bits of entropy. I'd recommend doing 160 to be safe, but 128 really is sufficient (technically a 256-bit private key has about 128 bits of entropy, anyway). |
|
|
|
My recommendation is to use a deck of cards. Shuffle it to your heart's content, then type in the order of the cards into a string, such as "Ah9d3s3h...". Hash that and use the resulting 32 bytes as your seed. You can use armoryengine to do the conversions: hash256() to hash the string, and "makeSixteenBytesEasy()" to convert each half of the string to a line that can be entered into the wallet restore window. The order of a deck of cards has 225 bits of entropy, which is plenty big enough. I tried the dice thing before, but it's a lot of dice rolls and it makes a lot of noise. The deck of cards is much more pleasant |
|
|
|
Fairly new to Armory and I'm just testing things out sending a small amount between wallets just to learn. I broadcast one transaction with success, but the second one keeps failing.
So I create the transaction in online armory and sign it on offline computer. Load the signed transaction on the online and it says "All Signatures Valid!" Armory shows "Connected 309XXX Blocks", but when go to broadcast I get a taskbar error message pop up saying something like "Connection to BitcoinQT Lost, Armory can't send the transaction until you reconnect" and then it says "Connection to Bitcoin QT re-established" and it does this a couple of times. Finally I get a pop up window in Armory saying "Invalid Transaction - Transaction not accepted by the bitcoin network, due to a bug with Armory..."
I've restarted Armory a couple of times and tried broadcasting a number of times to no avail. Again this is the second transaction I am trying, the first went off without a hitch, so I'm not sure what the issue could be. Any thoughts would be much appreciated!
Did you create the two transactions at the same time? It's possible that the first transaction turned out to be a double spend of the second-- this happens because Armory doesn't keep track of what outputs have potentially already been spent when creating a new transaction, unless that transactions is broadcast already. This would match your symptoms, too: Bitcoin Core sees you broadcast a tx spending inputs that have already been spent, flags you as misbehaving and disconnects you. You can be sure about it by looking the Bitcoin Core logs... it usually tells you why it disconnected. Or simply create a new offline transaction, sign and broadcast. As long as the previous one has been broadcast by the time you create the next, everything will be fine. |
|
|
|
Re the title. just to explain a bit more detail... Im saying that the title of the App has changed from being called Armory to Python. i.e.: previous Mac builds of Armory, the application was called 'Armory' and when you had to Force Quit it, in the list of Apps it was called Armory.. and it said Armory in the window's title bar (at the top of the screen). Now the app seems to be called 'Python', and in the Force Quit window its called Python, and the Window title bar says Python, so I'm assuming something has accidentally changed the name of the App to be called Python. And if this isn't the case when you run it and you're not seeing what I'm seeing, then that may be an issue.
Note on this: because it takes a few hours to do a full redownload and rebuild of all the depedencies, I typically don't do it. However, it's entirely possible that there is residuals from the last build that are causing issues, and I should stop taking the shortcut and always do a rebuild. On a sidenote, I have a 3D printer and use Makerware for slicing and sending to the printer. I noticed during install it looks like they do the exact same thing as us: bundled python with PyQt. However, I think they use Qt5. They use virtual-env, which I don't think our OSX solution uses. It might be worth digging a bit into what they are doing, because it sounds like they've done almost the same thing, but much more robustly. |
|
|
|
|
Okay, one more try! I just uploaded an identical copy of 0.91.99.8-beta, except that the Windows version now has all the print statements removed. Otherwise, it should be identical to the previously-available 0.91.99.8.
Just be aware that since the file is named the same (it's literally the same except for irrelevant print statements removed), that the secure downloader signature verification will fail for the next 30-60 minutes, or until you go to the "Announcements" tab and click "Check for Updates". You can't get the wrong one though, since you'll get an error and Armory will refuse to save the file.
P.S. - In case it wasn't clear: this 0.91.99.8 re-do seeks to solve the "Bad File Descriptor" error.
|
|
|
|
Im using Armory offline and the button (collect sigs and broadcast) say (must be online to broadcast). But I can click on the button.
Different of:
The button (create spending Tx) say I must be online to spend. But because Im in offline mode, the button is INACTIVE.
I actually have a comment in the code explicitly discussing this: https://github.com/etotheipi/BitcoinArmory/blob/devel/ui/MultiSigDialogs.py#L1101 # The 'MergeSigs' button is the only one that kinda makes
# sense to not work offline, but there may be isolated
# cases where the user would merge without intending to
# broadcast. Having it disabled in offline mode would
# make them go mad. So I'm going to explicitly make sure
# that just that button is always enabled, even though
# it might look like a bug.
The gist of it is: the button is still potentially useful in offline mode, but only for collecting and merging signatures. Broadcasting requires being online, but I couldn't separate out that functionality. Obviously it's not entirely clear and does actually look like a bug... hmm |
|
|
|
2- I don't understand why is possible to edit a created lockbox.
Already got you covered on this: - If you edit the lockbox metadata, nothing changes, it just updates the meta data and everything is the same.
- If you edit M, N or any of the public keys, it gives you the warning below
You originally loaded lockbox (%s) but the edits you made
have caused it to become a new/different lockbox (%s).
Changing the M-value, N-value, or any of the public keys
will result in a new lockbox, unrelated to the original.
*If you click "Ok" a new lockbox will be created* instead
of replacing the original. If you do not need the original,
you can go the lockbox browser and manually remove it. |
|
|
|
|
There does continue to be an error related to print statements in Windows. I believe that once Armory passes through py2exe, that stdout no longer exists and therefore any print/pprint statements will fail with "Bad File Descriptor". CircusPeanut: I assume you are trying to reproduce from python-executed code, correct? Try running from the installed version and/or rebuilding from the MSVS project and using the .exe.
I thought I had removed all the print statements. They are never necessary, usually just left over debugging artifacts that should be harmless. After all, there should always be a stdout, right? I will go over it again and make sure there are no remnants left.
|
|
|
|
Please add one of your many awesome Question marks with tool tip. No need for a Manual with armory. These things explain almost everything and you learn a lot about the Bitcoin protocol and more.
Yeah, that's one of those things that should be under super-expert feature. There limited uses for using regular multisig over P2SH, but they do exist (having transparent public keys in the blockchain can assist with automated tools that are tracking multisig addresses they are signers for). I'll add a (?) thingy "Cannot be signed by you" However, both watching-only wallets are marked as "mine". Therefore the comment should rather be that the signature cannot be given from this instance of Armory, and then explain the conditions (keys are not here or not your wallet). Whatever, doesn't seem 100% correct. Maybe a "light" green would be good in case you can even cover it with the architecture.
Yeah, I don't use the "is mine" or "belongs to someone else" distinction here. If we can come up with something clean to say, I'll change it. Otherwise, I'm sure the user will figure it out What about Simulfunding of normal single key addresses? What about if I want to set up a 10 party 0.1 BTC simulfund to give to Armory?
I struggled with simulfunding of regular addresses -- there's no reason the same code can't be used for it, but it didn't fit cleanly into the lockbox dashboard. So I added a "Multisig" menu to the main window, and you can do arbitrary simulfunding from there. I want to unify the interface somehow, but not quite sure yet how to do it. Either way, feel free to try out all the same features from that menu instead. (by the way, "arbitrary" means arbitrary recipients. But not arbitrary inputs: I still haven't found a good way to build into the UI the ability to simulfund with Lockboxes... shouldn't be too hard though) |
|
|
|
So if we dont share the lockbox, then they cant create a transaction but they can still sign the transaction created by us? Correct?
Heh, kinda. If you "Use Bare Multisig (no P2SH)", Armory should be able to recognize its own key and be able to sign without the lockbox. I think. Testers: try it! Otherwise, it uses P2SH which is totally opaque and you must have the lockbox in order to even recognize it's relevant to you. |
|
|
|
No, What I mean is can all the members of the multisig group create a new transaction or can it be only made by the initial author?
Anyone can create the transaction as long as they have imported the lockbox. They don't even have to be a signer. The lockbox block is basically a watching-only wallet for your multi-sig. |
|
|
|
Final note, I like the new dashboard, but a the address isn't on it. To me the address is one of the most important pieces of information, but it is hidden on the Info tab. This took me a minute or 2 to discover so that I could request testnet coins from the faucet.
You're absolutely right about the address! I should put it on the funding row. There's plenty of space when the "Simul" checkbox is not checked. Thanks (definitely deserves a bounty!) How does this look?  |
|
|
|
Looks like only 1 out of my 2 bugs got fixed.
When I add the same public key to the same lockbox and click sign, it now signs for all the same public keys. Cool, that's good.
Now when I add a custom change address that is not actually the lockbox, it shows the change address as a receiving address. Cools, that's better than before. The bug I am seeing now is that in this state, when I try to click "Broadcast" it doesn't do anything. It is a 2 of 3 lockbox and all 3 keyholes have a green check mark next to them, so I believe I should be able to broadcast the transaction.
Edit: Oh, this might not be related to the change address... I just tried a normal transaction without a custom change address and got the same behavior.
Final note, I like the new dashboard, but a the address isn't on it. To me the address is one of the most important pieces of information, but it is hidden on the Info tab. This took me a minute or 2 to discover so that I could request testnet coins from the faucet.
If you ever hit a button and it doesn't do anything, there's an error being thrown under the hood. Please check the logfile and post the error or copy the logfile to pastebin or something. You're absolutely right about the address! I should put it on the funding row. There's plenty of space when the "Simul" checkbox is not checked. Thanks (definitely deserves a bounty!) I just fixed the pathing bugs, and was about to release it as *.8, but maybe I'll put in that address display widget. Then I'll do .8 later tonight. |
|
|
|
Bug report:
Stuck with multiple Armory icons in the task bar.
Steps:
Launch Armory (Mainnet)
Launch Armory (Testnet)
Testnet Armory complains that it is already running and exits automatically, but the icon stays in the taskbar.
The Testnet icon is unresponsive to any clicks.
Looks like Testnet Armory didn't actually exit completely. I had to kill it from taskmanger.
Edit:
Scratch that, it looks like Testnet is completely broken. I try to launch it and it creates the tray icon, but never comes up. If I look in taskmanager, I can see that it launches bitcoind with the testnet parameter.
2014-06-29 13:03 (ERROR) -- ArmoryUtils.pyc:1159 - Determined that exec dir is C:\Program Files (x86)\Armory\armoryengine but it does not exist
2014-06-29 13:03 (ERROR) -- Traceback (most recent call last):
File "ArmoryQt.py", line 7280, in <module>
File "armoryengine\Timer.pyc", line 99, in inner
File "ArmoryQt.py", line 503, in __init__
File "ArmoryQt.py", line 875, in loadArmoryModules
File "ntpath.pyc", line 96, in join
TypeError: object of type 'NoneType' has no len()
There's actually two things going on here: (1) Do not use auto-bitcoind in testnet mode. I've tried a couple times to get that working, but it's non-trivial. For testnet, you'll have to run Bitcoin Core manually and disable the option in the menu. This is good anyway, if you plan to run multiple Armory instances -- you can have all of them connect to the same Core instance. (2) I see the problem with the path... I have that path in my exec directory, but didn't realize that lacking that path causes it to hard fail. Very easy to fix, and will make sure I have that in the next iteration. For now, to run in testnet use --disable-modules. Actually, on the second one above: can you check your testnet log file for an error that looks like this and tell me what it is? ERROR: Determined that exec dir is ______ but it does not exist |
|
|
|
Also, what branch did you pull?
I pulled from 0.91-dev I'll take a glance at it tonight. Admittedly, those scripts have not been maintained as well as they should be. I believe the public key map is just scrAddr->rawPubKey. The signing device will need to know the public key to put into the sigscript, and it was simpler to have it passed through the data structure like this. I think it's something like pubKeyMap = dict([[SCRADDR_P2PKH_BYTE+hash160(pk), pk] for pk in pubKeyList]) Awesome, I'll see what I can do with that. Not promising I won't be back with more questions but it's a start. Thanks! Please work on the devel branch ,which will shortly be merged into master (maybe 1-2 weeks). If you figure out how it needs to be updated to work, you'll be saving us some time! But I'm not sure what I posted above will work. I forgot how 0.91 handles things... |
|
|
|
I'll take a glance at it tonight. Admittedly, those scripts have not been maintained as well as they should be. I believe the public key map is just scrAddr->rawPubKey. The signing device will need to know the public key to put into the sigscript, and it was simpler to have it passed through the data structure like this. I think it's something like pubKeyMap = dict([[SCRADDR_P2PKH_BYTE+hash160(pk), pk] for pk in pubKeyList]) |
|
|
|
I'm using Armory 0.91.1 on Windows 8.1 to download 0.91.2 (Testing unstable) 64-bit for Ubuntu 14.04 using Secure Downloader. When checking "Save with offline-verifiable signature" the file is saved as: armory_0.91.2-rc1_ubuntu-64bit.deb.signed.exe, I didn't expect an exe file and it looks weird ending with a comma. Next I select Verify Signed Package and select the file. I have to manually change to display all file types since there's no *.signed file. Armory asks me if I'd like to overwrite the original file to which I selected Yes. Armory explains that the installer was extracted to the same location (armory_0.91.2-rc1_ubuntu-64bit.deb.signed.exe,) however that file is now missing. It seems Armory removed the .exe, file but didn't extract any installer first. Now I'm back at the Verify Signed Package window where I click "Select file to save to...". Now Armory suggests a file name of armory_0.91.2-rc1_ubuntu-64bit.deb. I'll make sure to give this some TLC before the next release. Obviously the comma is an error. And obviously it should show you .exe/.deb/etc in the file select dialog. Also, try clicking "No" for overwriting and then click the button on the small dialog to specify where to save it. EDIT: I just tested this on my linux box, and I didn't run into either problem. When you do the download originally, it asks you where you want to save it. Are you sure you didn't accidentally type a comma in there? And you didn't see it on the list because of the comma -- it definitely shows you all ".signed" files, but not ".signed," files (with a comma). |
|
|
|
|
Show Posts
