Sorry for reviving this thread... You could also display a code/sentence on the screen rather than having the user select one. This more or less forces them to record it somewhere (and as you said, most people would record it on the paper). If you did this then you would probably want to have the user re-enter for accuracy.
I am not fond of brain wallets for many reasons (users are notoriously bad at choosing strong passwords, they are easily forgotten, you can attempt a brute force once the address hits the network, etc...) However, I like ErebusBat's idea of letting software pick a strong password to be displayed in addition to print out an encrypted secret on paper: - The password wil be strong - The user has no choice but to write it down, but can choose to write it down on a separate sheet. - Unlike brain wallets, it is not feasible to brute force until you have the secret stored on paper I would however still let the user choose to store the secret in plain on paper, and have this as an alternative option.  (it was part of a demo at the Bitcoin conference in May, and will be part of one of the next two major Armory upgrades) |
|
|
|
... so Armory will run again on my 4gig Ram Windows 8 x64 machine Haha, glad to see how much effort people are going to to use Armory! Luckily, I'm making lots of progress on the "persistent blockchain" upgrade (it's a big upgrade), so it should run with much more reasonable RAM requirements when I'm done. Though it may still be a few more weeks... On the other hand, if you're like me, I'm always looking for excuses to buy more RAM... Unfortunately now I'm at my limit of my motherboard: 32 GB. But I'm probably one of the rare people that actually needs that much RAM. |
|
|
|
I just had this issue happen myself. The bitcoinqt client crash just as I tried to send the bitcoins in Armory. Armory seems to think the transaction was sent but it doesnt exist in the blockchain. Is there a way I can either force armory to resend the transaction or a way to delete it so that I can create a new transaction?
Remove: [Windows] C:\Users\<username>\AppData\Roaming\Armory\mempool.bin
[Linux] /home/<username>/.armory/mempool.bin
[OSX] /Users/<username>/Library/Application Support/Armory/mempool.bin
Then restart Armory. |
|
|
|
Update: (25 June, 2013)Things have been hectic. Very hectic. I am quite aware about the usability issues, and I have been making some progress on the "persistent blockchain" update for Armory, but not at nearly the pace I had hoped. Other critical priorities have cropped up. I will explain more about these priorities in a week or two. I just wanted to assure those of you who still follow this thread that development does continue, despite things looking rather stagnant lately... On the persistent blockchain front: I have found myself in the awkward position of deciding to just make an identical version of Armory that uses LevelDB, or to actually upgrade huge parts of the codebase as long as I'm tearing it all up and putting it back together, anyway. It seems that the best solution is the latter -- I've always been a fan of short-term sacrifice for long-term gain. Even though it's slowing down the resolution of the RAM issues, a lot of what I am doing now will benefit multiple other things I have on my TODO list, including the new wallet stuff that will come shortly after persistent blockchain upgrades. What I'm talking about is things like properly handling and indexing multi-sig scripts, P2SH scripts, and compressed public keys. Additionally, I'm trying to make the whole thing easily extensible to both partial/lite/pruned operation (storing only data necessary for computing balance and creating transactions) and also super-node operation (maintaining a full address-lookup index for immediate balance/UTXO queries for any address). These are all things that I need to do eventually, anyway. For instance, I had claimed that the new wallet format was nearing completion before getting sidetracked by this stuff, but I was still going to have to upgrade a bunch of blockchain utilities and re-test it to be compatible with the new wallet functionality. I might as well kill 7 birds with one stone. It looks like I've found a coherent way to fit all this together. And it means that many of these changes can be implemented and tested in one rigorous round of testing, instead of rewriting and re-testing multiple times. More importantly, after the first persistent blockchain update, it will be much tougher to modify the blockchain utilities, because users will have persistent databases that will need to be rebuilt to accommodate changes. And that may be quite painful. If you were wondering why it was beneficial for me to do full scans on every load and not save any blockchain data between loads.... that is why (simple!). That's all I have for now. I'm excited that when I'm finally done with this, Armory will be miles ahead of where it was before. So many problems will go away. Until then... you'll all have to suffer while I take my time doing it right
|
|
|
|
Nice! I didn't notice that previously when looking at the downloads page. While I can't speak for all Armory users, I personally would rather you work on updating Armory itself than creating more versions of Armory for other versions of Ubuntu or one of the other half a billion Linux variants. At least it seems like there are that many, anyway. I'd say one is enough personally, but that's just me.
It used to be a lot of work, but now that I have most of release process scripted, I can do it much more easily. Rather, it used to be a lot of work to recreate and re-release each bundle, which is why I only did so every 4th version or so. Now that the process is scripted, I only have to put in effort once to create the original bundle, and then it's really not much extra work to include them on every release. Ubuntu 10.04 is becoming pretty seriously outdated, so I'd like to at least create one more 32/64-bit pair of bundles to support a more-modern Ubuntu version. After that, the one more bundle I need to [figure out] and create is a Raspberry Pi bundle. I finally even got a RPi, but have had zero time to play with it! One day, though... Don't worry, my efforts right now are focused on the new Armory version. It's kinda slow. But steady... |
|
|
|
Huh, neat. I didn't know you could do that. Wouldn't that be a lot more of a risk of acquiring viruses if it's installed on a flash drive than if it's a separate computer? Ideally my computer will never get compromised, but this seems somewhat less secure than the traditional method. I suppose there's a bit more security in that it's linux rather than Windows which I've got on my regular computer.
The only time it's at risk is when you download the linux image and then while you're installing armory -- from then on you disconnect the network and it's stand alone. So it's about as secure as you get without some craziness. If you install Ubuntu 10.04 then you can use the offline bundle from the downloads page that has 100% of the dependencies included. I've tested it: it installs successfully in a completely first boot fresh install of 10.04, without any internet connection. I will eventually make offline bundles for other versions of Ubuntu, but I picked that one because it will work no problem even on ancient hardware. It's just that it's a lot of work to setup an offline bundle, so I haven't gotten around to the other versions yet. |
|
|
|
|
Has Bitcoin-Qt fee logic changed recently? The fee logic I've implemented is pretty much minimal already (though, I screwed up the allowFree() logic and some tiny fraction of transactions may be required to pay a fee when the network wouldn't require it). It used to be 0.0005 BTC/kB but only if the tx >= 10kB.
I do plan to implement the minimum TxOut limit (the 5430 uBTC limit). But I thought that was the only thing that has changed...
P.S. - Not off-topic at all!
|
|
|
|
|
Unless D-Wave has changed their direction in the last 5 years (the last time I checked in with their progress), nothing they are doing actually constitutes a "real quantum computer". When I say "real," I mean one of those quantum computers that actually leverages quantum interference to solve problems, which could be used to break not just Bitcoin cryptography, but all the cryptography on which the internet is based. If this was a real problem, you can be sure that alarm bells would be ringing around the world, and for much more than just Bitcoin.
Real quantum computers aren't just faster -- they solve problems differently. Shor's algorithm takes integer factorization from O(ecuberoot(N)) on a classical computer to O(N2) on a quantum computer. This isn't just faster -- this makes a whole class of essentially-unsolvable problems, solvable (including the discrete logarithm problem on which Bitcoin crypto is based).
Yes, you can get a speedup on pure-guessing problems using Grover's algorithm -- from O(2N) to O(2N/2). That's a unique capability that QCs can exploit, but the least interesting in terms of breaking cryptosystems. Most crypto systems use key sizes big enough that even if you halved the keysize, it would still be secure. And the defense is to just double your keysizes, once, and the problem goes away. But not with Shor's algorithm -- the whole class of problems is compromised.
D-Wave has always been a joke in the world of QCs. What they are doing is cool, and they may be developing technology that is somewhat related to QCs, but they shouldn't be using the phrase "Quantum Computing" in their product name, because that terms is reserved for a whole new class of computing systems, not classical computers that use quantum bits to do things classically faster.
|
|
|
|
|
Super interesting. When he says "disconnected" wifi and bluetooth, I wonder if he means "simply not connected" or "actually disabled in the BIOS"...?
Certainly, we will need better methods for securing offline computers in the future. The USB keys are not ideal, but they are two orders of magnitude better than letting people use the hot-wallet-and-pray technique. QR-code video is something that I think has a lot of promise, and to work well with smartphones and netbooks, which already have cameras. It looks like someone else took a stab at doing it before I could get around to it. But I'll probably find a way to do it, anyway. Eventually.
The deterministic build process is something that Armory is going to struggle with. I wonder if it's really possible to do it with all the crazy tools I've had to use to blend programming languages. It's about to get even more complicated with LevelDB. At the very least, it will be possible to deterministically build the _CppBlockUtils.so/.dll/pyd and then bundle that with all the other static files. It's something to think about for the future, for sure.
|
|
|
|
For some reason, my armory stops at block 233400 and won't go any further. Then it says "Connected" and goes green: http://vvcap.net/db/wm35f-O3i1eDW_sRVbqI.htpIn the past, I was able to fix this by rebuilding blockchain (e.g.: start from scratch). That doesn't work anymore! This behavior goes with versions .87, .88 and .88+latest fix. I suspect you recently changed your Bitcoin home directory (--datadir)...? If so, it's because you changed where Bitcoin-Qt is maintaining the latest blockfiles, but left the old one intact where Armory finds it and thinks it's the correct one (and stops at 233400 because that's the last block in that directory). You either need to start Armory with the --satoshi-datadir=Z:\New\Path\to\bitcoinqt, or if you are in 0.88+, you can modify it in File->Settings. Let me know if that's not the problem. |
|
|
|
python-psutil was a dependency added to Armory in version 0.88+. You could try one of the earlier versions of Armory (0.87.2) or you could download the python-psutil package from here (I don't think it has any dependencies). I'm not sure why it wouldn't be satisfiable... |
|
|
|
|
Not that this doesn't achieve some level of security, but it's kind of backwards. If this is secure, it's because the user properly secures their private key for signing commands, plus a little bit extra "confusion" factor induced by the obscurity of the setup. But if you're going to secure that command-signing key well, why not just leave out server B entirely, and just secure the Bitcoin private key to use to sign transactions directly, instead of signing-comands-to-tell-some-other-system-to-sign-transactions?
If you're concerned about anonymity, you could still maintain server A and B and let server B find & broadcast the signed transaction for you from the hidden service. But there's no reason to have server B keeping the private data. In fact, what you posted here would be theoretically less secure, because if either the command-signing key or the hidden service Bitcoin private key is compromised, the coins are gone. That means you have two distinct, single points of failure, which has the security of the weakest one. You might as well limit to a single point of failure and secure that one point correctly.
|
|
|
|
The real answer to your question is this: if(isStandard() and isMine())
balance += value If the script does not match very simple (and small) set of standard scripts with known "unlock" conditions, then it's considered rogue and ignored by the wallet. If someone wants you to have money, they use a standard script. If someone wants to play game, or you want to experiment with scripts, you'll have to write your own software to experiment with them, because all the existing software will just ignore it. |
|
|
|
|
Update:
I still use this data to test the re-org logic in the Armory block utilities when I make changes. However, I had considered for a while that I could try to add a couple blocks to it to force a re-org back onto the original chain. That would really be nifty and represent an even-more-stressful situation that the block utilities should be able to handle.
Of course, all this time of procrastinating, I never realized it's already there (it seems kind of obvious in hindsight). The test was written with the intention of running the blocks through [1, 2, 3, 4, 3A, 4A, 5A] (where blue-underline represents a block that triggers a reorg). But there's no reason you can't do [1, 2, 3, 3A, 3, 4, 4A, 5A]. Then 3A is actually the "original", block 4 pulls you off of that branch, then 5A pulls you back to the original branch. It effectively exposes your code to a transaction that is valid, then double-spent, then reverted back to valid when the original chain becomes longest again.
Also, someone just posted a question about reorg testing, so I thought I would bump this thread, since it was written so long ago but still remains useful (at least, for me).
|
|
|
|
Whoa, weird. I never noticed that. There is actually two slashes prefixing each line in the HTML, but it very much looks like a single slash when the page is rendered by Chrome (at least). I'll play around with it. Though, the entire website will be overhauled, soon, anyway |
|
|
|
I'm sorry this is so confusing, but I blame bitcoin-qt for deviating from standard *nix command line arguments. Long-form arguments, with the argument names spelled out should always use two dashes "--satoshi-datadir=" and "--datadir=". Also "--testnet" and "--offline". You would only use one dash if you are using a short-form, such as "-t" or "-o" (which don't exist in Armory, I'm just making a point). Armory only has long-form arguments, so everything starts with two dashes. Also, if you specify the --datadir, you don't need to specify the --settingsPath unless you want the settings file to be somewhere other than the datadir. You should only need to call: Armory.exe --datadir=R:\Armory\data\Armory --satoshi-datadir=R:\bitcoin\data I don't see anywhere in the logfile where you tried starting Armory like that, so I can't evaluate why it didn't work. This should go without saying, but just make sure those directories exist before starting it. |
|
|
|
I think you'd want a one-click repeatable way to generate the test data as well. Some kind of program that would interact with bitcoind, for example, to generate the transactions and blocks. I'm not sure how much invalid data you could introduce directly using bitcoind, but you could also twiddle the bits after the fact to introduce errors.
This still gives the raw blocks, so other implementations don't need to depend on bitcoind at all for the test suite. But it means you could roll out updates to the test suite much more easily.
A long time ago I created a re-org unit test: https://bitcointalk.org/index.php?topic=46370.msg577556#msg577556I created a completely valid blockchain, with valid signatures and proof of work, an orphan chain and a double-spend. It's valid as long as you set your COINBASE_MATURITY to 1 (so coinbase blocks are immediately spendable). This has been wildly invaluable for me to test all kinds of different logic. The only thing I regret doing was not adding a couple more blocks to re-org back onto the original chain. That would've been even more stressful... |
|
|
|
|
Short answer: yes
I was actually planning on getting in touch with them soon, to discuss some way we could help each other out.
|
|
|
|
Thanks for the clarification on blockchain.info and the help!
I will give that a whirl, I believe you are correct that it will work in the event there are 0,1,2 "=" at the end of the string. My only concern now is that there won't be "=" embedded in the string (not the end) that get stripped out.
The "=" symbols are not part of the base64 encoding, other than identifying padding at the end of the string. The only two non-letter characters are "+" (%2B) and "/" (%2F). Since there are %2F sequences and "+",%2B signs in the string in both places, it looks like you are okay. The equals signs appear to be the only thing missing. |
|
|
|
|
Completely off topic. I was thinking that " Reiner-Friedenbach tree" is way too long and way too German. What about the "Freiner tree"? Too cheesy? It does seem to be an elegant mixture of Reiner, Friedenbach, and Freicoin.
I really wanted to rename this thread to something more appropriate, but I'm not sure what, yet.
|
|
|
|
|
Show Posts
