Sure. Do I need to uninstall the previous version or run the install over top of it?
Nope. You can always install over the previous version. All wallets and settings will remain untouched. |
|
|
|
I hate to be the hater, but I don't think he can charge for special addons or services, would depend on the bitcoind's license.
There's no licensing issues, even if I was distributing bitcoin-qt/bitcoind. Not only is bitcoin's license permissive, but I'm not even doing that -- the user still gets it themselves. There's almost never a problem with licensing if you are simply "linking" to the unmodified software. The licensing stuff usually kicks in when you make a modified version of their software, and don't want to release the source code for those modifications. Even if I modified their software, I would be happy to release the modifications. (but I don't have to do even that, just add attribution to their project/developers) |
|
|
|
Do I need to change
2013-04-03 12:51 (INFO) -- armoryengine.pyc:573 - Satoshi BTC directory : C:\Users\*\AppData\Roaming\Bitcoin\
to
2013-04-03 12:51 (INFO) -- armoryengine.pyc:573 - Satoshi BTC directory : C:\Users\*\AppData\Roaming\Bitcoin\blocks\ ?
No, that's fine. It will look in both the main directory and the blocks directory for those blk files. It will pick the ones with the latest timestamps. Though, the latest version has more debugging output. Can you try it? http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.87.9-testing_win64.msiIt might help me figure it out. |
|
|
|
I have not changed any settings. Just copy/pasted the old directory into the new and ran qt with -rescan. I messaged you what may be causing the problem, though I do not know how to fix it.
Try removing the blk*.dat in the base directory. Leave the blocks/ directory alone. Only delete blk*.dat and blkindex.dat in the base. |
|
|
|
A bit off-topic, etotheipi, I am fairly sure your software is becoming the basis of a potentially multi-billion dollars industry--bitcoin cold storage, consider the recent price.  Yeah... I need to monetize it in some way  I've actually got some ideas that I think will not "corrupt" it. Some more on that soon... You might start with one of these: http://redonate.net/Unfortunately, donations have not worked out. I don't think I can count on that for monetization. I get about $100/mo in donations. Don't get me wrong, I do appreciate it (and I've bought my fiancee a lot of very nice dinners ), but even if that went up 20x, I would have a tough time justifying doing Armory full time... |
|
|
|
Sent. Thank you for the fast response.
Are you using any non-standard settings for bitcoin-qt? A bitcoin.conf file? It looks like Armory is having a tough time communicating with it... |
|
|
|
A bit off-topic, etotheipi, I am fairly sure your software is becoming the basis of a potentially multi-billion dollars industry--bitcoin cold storage, consider the recent price. Yeah... I need to monetize it in some way I've actually got some ideas that I think will not "corrupt" it. Some more on that soon...
Check it out!  Finally got signing Windows installers working on my offline computer. The only problem is that <randomstring>.msi... not sure what's causing that. But the signature is valid. If someone knows how to avoid that <randomstring> thing... let me know! I updated the link on the previous update with the signed version. |
|
|
|
To start, computer specs:
AMD b55 quad core 3.8 ghz
16g ram
Win 7 64 pro
I'm using qt .8.1 and armory .87.2. I was originally running qt .7 on a different computer. I installed qt .8.1 on this computer, xferred the data files and rescanned. Qt is now showing my correct wallet balance, as well as being up to date (green check mark in bottom right). I then installed Armory and opened in online mode, and it has been showing "offline while scanning the blockchain" for hours, with "Connected (0 blocks)" showing in the bottom right corner. I have restarted Armory, restarted the computer, run in administrator mode, and nothing seems to work. Has anyone else experienced this issue, or been able to successfully pair Armory with qt v .8.1?
It's definitely supposed to work. I'm using it right now, in both Windows and Linux. Can you please export a log file (from the File menu) and email it or PM it to me? |
|
|
|
Perhaps I should have asked instead, how many trials would it take to theoretically reach 1.9% with a 95% confidence interval?
Well alright. Now I can say "I don't know" instead of "your question sucks" It's affected a lot by the big bets. The profit from thousands of small bets can be wiped out by a single lucky big bet (and vice versa). The question should have one more number. It should be phrased "95% chance that the house edge will be within 1.89-1.91%" or similarly. The size of the acceptable error there will greatly influence the result. And... I don't remember how to do a problem like that  It's complicated by the fact that with 1 trial, there is a 0% chance that the house will take within 1.89 to 1.91 percent. I think it can be assessed using Markov chains. Meni Rosenfeld's analysis of PPS pool bankruptcy probabilities ( AoBPMRS, Appendix c) examines a similar problem and uses a Markov chain model. I haven't studied them, maybe someone else more familiar with Markov chains could do the analysis. Markov chains are more useful when there's a relationship between the states of the system. In this case, it would be more like "losing 3 in a row changes your chances of winning the next one". Since we don't have that, you can use regular IID statistics. The way I wrote the script that dooglus is using right now, is taking advantage of the fact that for a sum of random variables, you can just add their expected values, and add their variances. Square-root the resulting variance ot get the standard-deviation. The result will be a mean and std-dev, which you can use to compute a 3-sigma bounding box (or 2-sigma, if you want 95% confidence). For binary systems like this (win or lose), you'd "normally" use different equations, but this construction is accurate as the number of trials gets large. SatoshiDice qualifies. |
|
|
|
Yup, I deleted my conf and just let armory make another one, it works perfectly now.
Where did that password come from? Should I expect other users to have '=' signs in their password? EDIT: nevermind ... it was a fairly easy update to accommodate that. Not pushed into the latest testing version yet, but it will be. |
|
|
|
|
@prezbo
Ack, I see the problem! You actually did have the rpcpassword in there... but the password contains '=' signs, which throws off the python reading of the password, assuming that line.split('=')[-1] is the password. In your case, there's an '=' in the password, so it only reads the last 1/3 and tries to use that as the password.
Okay, good bug. I'll make a note of that! Armory creates a 128-bit password for you, in base58, so that wouldn't happen if Armory created the bitcoin.conf file for you.
|
|
|
|
|
Ahh, the first problem. I assumed they either don't have bitcoin.conf file (in which case I create it), or I expect to find it and have rpcuser and rpcpassword fields. I hadn't considered that they have a bitcoin.conf already and do not have rpcuser and rpcpassword.
Now that you posted your RPC conf, I recommend you delete and let Armory create a new one for you (with a new randomly generated password). You can add your extra lines after that...
|
|
|
|
|
P.S. -- This is the 2,000th message in this thread! Wow!
|
|
|
|
Okay, I continue to battle this stupid auto-manage-satoshi upgrade. It's a real pain in the @$$. So far, only a couple people have tried it and claimed 0% success. But in all my testing, I can't find out where it fails. I know that non-standard configurations are like to mess this up. And I've done a bit of testing. Apparently not enough, though. PLEASE help me figure this out! I have just released the latest, 0.87.92, installation instructions below. Note that more than just auto-management has been added. I also made the little "(?)" icons clickable, and reduced the number of windows you have to click through to use offline wallets. Linux: -- Pull and switch branches: "git checkout managesatoshi" -- Must install python-psutil package. This is a new dependency to help with managing the background process. It will be added to the next offline bundle. -- Recompile Windows: -- http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.87.9-testing_win64.msi-- http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.87.9-testing_windows_all.msiThere's a good set of debugging output that happens automatically. If it doesn't work for you, send me a log file! Please try it and let me know! Try it on a new computer without Bitcoin-Qt ever installed. Try it on a system with Bitcoin-Qt already installed and sync'd. With Bitcoin running, without it. With non-standard Bitcoin-Qt directories. With the option to run it yourself instead of letting Armory do it (in the settings). Etc.  |
|
|
|
Maybe I am missing something. Does Armory have this already? Why do you want a change to the Bitcoin software if this be done by a wallet or plugin that sits on top of the main software?
Armory lets you control the source addresses, not the individual coins (but still called "Coin Control"). People requested "Coin control", I gave them that, and I haven't really heard any complaints. So I left it alone. I think I understand, maybe: Some people say that one Bitcoin is just like another (just like atoms in quantum mechanics where you can't distinguish one from another) but that is not really true. Each satoshi has a history which can be traced back to the point it was mined. With the Armory "coin control" it allows you to control the balances in the individual addresses but not each satoshi within each address. What coin control would do is allow control over each individual Satoshi. It seems to me that a wallet could do coin control without changing the main Bitcoin client but it would be a complicated programming task (but not impossible). However, it may be easier to implement coin control if the main client was changed to make it easier to have coin control. Is this the issue? If you never reuse addresses, it is identical. I wouldn't think of it as controling each satoshi... every time you receive X BTC, that's like an $X-bill (if $1/BTC) now sitting in your wallet. When you want to give someone 10 BTC (assuming X is more than 10), you sign a transaction that uses that $X-bill as input, and has two outputs: assigning 10 BTC to their address, and assigning X-10 to a change address you own. Now they have a 10-BTC bill in their wallet, and you have an (X-10)-BTC bill in your wallet. The original bill is "spent" (never to be used again). Really, your signature allows you to destroy X-BTC bills, and create new bills with new owners equal in size to the original (anything left over is claimed by the miner that mines the transaction as a fee). Armory coin control basically says "I only want to use bills from these N addresses, no others". The intent was to give users control over what addresses are linked when you create transactions. Some people want more than that, and want to control individual bills... Armory doesn't have that. |
|
|
|
This only helps when people use the system in a poor way that screws up the privacy design... and the opcodes and such are unnecessary: a pair of nodes can community however they agree to communicate— deflate encoding if they like— and whatever alternative transport you want could compress things.
We'd be unlikely to merge anything in the reference that improve efficiency only for cases where users give up privacy. Privacy is an essential part of any financial transaction system, and the privacy of Bitcoin users is unusually fragile.
No. OP_COPY_SCRIPTSIG does not degrade anonymity, since generally (but not always) a single transaction means that all the previns are owned by the same person. On the contrary OP_COPY_SCRIPTPUB does degrade anonymity, but why not let the users choose the level of anonymity they want? So we just implement OP_COPY_SCRIPTSIG and make a trailing OP_CODESEPARATOR standard. gmaxwell's point was that for OP_COPY_SCRIPTSIG to actually be useful, you must have massive amounts of address reuse. While some people do, it's not a "standard" usage of the network, and doing so degrades anonymity. Therefore, for this script code to be useful, you'd have to have a large number of people using the network in a non-anonymous way. In fact, if it saves them a fee because the transaction is smaller, then they are actually encouraged to reuse addresses. |
|
|
|
etotheipi: could you please confirm that higuys .app is 100% safe to use?
I've been using Red Emerald's solution for a while, then I've tested higuys solution which is also working very good. Just wanted to know if you would recommend definitely switching to higuys app while we wait for an official OSX release.
Hi Rampion, I can't confirm that. The only way I'll confirm it is if I made it myself, but I haven't done that yet. Luckily, I'm just about done with what I was doing, and have some time now to try the OSX building as higuys laid out for me. Let's see how far I get... Well, to be honest now I'm kinda worried of having used extensively higuy's solution. Not your fault of course. What I said shouldn't make you any more concerned than you were before. There's plenty of trustworthy people around here, I just don't trust anyone but myself to release my software. |
|
|
|
etotheipi: could you please confirm that higuys .app is 100% safe to use?
I've been using Red Emerald's solution for a while, then I've tested higuys solution which is also working very good. Just wanted to know if you would recommend definitely switching to higuys app while we wait for an official OSX release.
Hi Rampion, I can't confirm that. The only way I'll confirm it is if I made it myself, but I haven't done that yet. Luckily, I'm just about done with what I was doing, and have some time now to try the OSX building as higuys laid out for me. Let's see how far I get... |
|
|
|
bitaddress would be perfect but I want it to have some modifications:
1. bulk wallet (and paper wallet) using compressed keys.
2. QR code error options for both public and private keys.
I may end up manually generating compressed keys and manually loading them into some QR code generator with error correction level H (high or 30%). Then print a few per page or even one per page.
Brainwallet.org currently has no easily accessible options for QR code, I am guessing you had to play with the source files and do a little editing there.
If you install Armory on the offline computer, you can modify the python code to do what you want. Armory has QR codes everywhere -- and there's a simple wrapper around a python-qr library that says "give me the smallest qr code that holds these X bytes", and it spits out a NxN matrix of 1s and 0s which represents the QR code. In Armory, that NxN may equal 53x53, so I scale draw a bunch of 5x5 black and white boxes to make a 265x265 pixel QR code. Of course, that's already wrapped up, you can just put a QRCodeWidget anywhere with any data you want. Create a new dialog, or butcher one of the existing ones, add QR codes to it. (P.S. - if you're in Windows, ignore this... it's a total PITA to get Windows setup with all the dependencies to run the python scripts, and load Armory... it's fairly trivial in linux, though) |
|
|
|
Acer Aspire One AOD270-26Dkk 10.1" LED Netbook - Intel Atom N2600 1.60 GHz- im gonna get a cheap laptop for armory, this is the cheapest one, netbook will work too right? i dont no the diff between laptops n netbooks.
That doesn't have enough RAM to run Armory. Bitcoin-qt will work, although it'll be a bit slow. how much ram do i need to run armory, thanks for the help guys For reference, if you're buying the computer to be offline, you can use any system. 256 MB of RAM would be sufficient to run Armory offline. All the offline system does is create and manage your wallets, and provide an interface for reviewing and signing transactions. For this purpose, the cheapest damned thing you can find will work well for Offline Armory. Online Armory is a different story. You will need probably 4 GB of RAM, and Armory will suck up 2 GB of that. It's the consequence of services like SatoshiDice chasing me down sooner than I could get around to revamping the blockchain utilities. That will be "fixed" soon, but at the moment a 2 GB netbook won't cut it. See more details in the Armory Quick Start Guide |
|
|
|
|
Show Posts
