Soo the problem is solved. I noticed that ArmoryDB.exe (probably from an older version of Armory) was still running. I ended that process, moved log files, and now Armory is working. Thanks for the help.  |
|
|
|
Is that the full path where the blockchain resides? It's not in D:\Bitcoin\blocks or something similar?
No, D:\Bitcoin\ is the home directory, and then D:\Bitcoin\blocks\ is where the blockchain resides. I tried it the other way, no change: 2018-01-16 06:18:41 (INFO) -- ArmoryUtils.pyc:1301 - satoshiHome : D:\Bitcoin\blocks
...
2018-01-16 06:18:44 (ERROR) -- BDM.pyc:197 - DB error: C:\Users\[user]\AppData\Roaming/Bitcoin/blocks is not a valid path |
|
|
|
I started Armory with --satoshi-datadir="D:\Bitcoin" and it's not connecting to my Bitcoin Core node. The log looks like it reads this, but then looks for the DB in the wrong place: 2018-01-15 22:07:29 (INFO) -- ArmoryUtils.pyc:1301 - satoshiHome : D:\Bitcoin
2018-01-15 22:07:32 (ERROR) -- BDM.pyc:197 - DB error: C:\Users\[user]\AppData\Roaming/Bitcoin/blocks is not a valid path Let me know if I should provide full logs or do something different. |
|
|
|
You're going about this the wrong way. What you want is to store the long part of the key in an easily-accessible form, but then have a small password that you know that secures it. There's actually a standard way to do this that is secure (well, as secure as your password): BIP38 encryption. Here are some sites that let you generate a BIP38-encrypted key: (I can't vouch for either of them personally, but they look decent enough) https://bitcoinpaperwallet.com/bitcoinpaperwallet/generate-wallet.htmlhttps://bit2factor.com/BIP38 uses scrypt as a key stretcher, so that it's harder to guess your password (still, you should choose a good one, e.g. 8 random characters, not just a word or name). |
|
|
|
|
Why is this a problem, exactly?
|
|
|
|
nope. if you'd like to sweep coins from a privkey, your fsck'd.
As I understand it, a pruned node still has the UTXO set (this is the database of unspent transactions, keyed by txid, that is necessary for knowing if tx's that come across the client are valid and should be relayed or not). Assuming Armory is written to support it (not yet, I'm sure, but it could be), you can still sweep/import a private key, and receive and spend bitcoins. The biggest difference is that you won't be able to know the history of old, already-spent transactions. Also, this might be an issue as Armory may have a harder time figuring out how many addresses to generate from your wallet, if it doesn't know that the first e.g. 150 addresses are already used and spent from. |
|
|
|
I got this on my supernode Armory 0.93.2 on Win 7. -DEBUG - 1436566509: (..\Blockchain.cpp:211) Organizing chain
-INFO - 1436566509: (..\BlockUtils.cpp:1532) Loading block data... file 297 offset 99540140
-INFO - 1436566509: (..\BlockUtils.cpp:589) Reading raw blocks finished at file 297 offset 99701505
-WARN - 1436566509: (..\BlockUtils.cpp:1116) Scanning from 364762 to 364762
-DEBUG - 1436568498: (..\Blockchain.cpp:211) Organizing chain
-INFO - 1436568498: (..\BlockUtils.cpp:1532) Loading block data... file 297 offset 99701505
-ERROR - 1436568498: (..\StoredBlockObj.cpp:325) Merkle root mismatch! Raw block data is corrupt!
-ERROR - 1436568498: (..\BlockUtils.cpp:581) Error parsing block (corrupt?) - block header valid (hash=00000000000000001096f3b0f76c4abf3ba3e238801a36a5fa4461c1b5509356) (error encountered processing block at byte 99701505 file C:\Users\[redacted]\AppData\Roaming\Bitcoin\blocks/blk00297.dat, blocksize 934205)
-INFO - 1436568498: (..\BlockUtils.cpp:589) Reading raw blocks finished at file 297 offset 100635718
-WARN - 1436568498: (..\BlockUtils.cpp:1116) Scanning from 364763 to 364763
-DEBUG - 1436569234: (..\Blockchain.cpp:211) Organizing chain
-INFO - 1436569234: (..\BlockUtils.cpp:1532) Loading block data... file 297 offset 100635718
-INFO - 1436569234: (..\BlockUtils.cpp:589) Reading raw blocks finished at file 297 offset 101262735
-WARN - 1436569234: (..\BlockUtils.cpp:1116) Scanning from 364764 to 364764
-ERROR - 1436569234: (..\lmdb_wrapper.cpp:2954) Tried to get StoredTxOut, but the provided key is not of the proper size. Expect size is 8, this key is: 2
-ERROR - 1436569234: (..\StoredBlockObj.cpp:1032) Requesting DB key for incomplete STXO
And now every time I try to reopen Armory, it chokes again on the STXO: -ERROR - 1436578700: (..\lmdb_wrapper.cpp:2954) Tried to get StoredTxOut, but the provided key is not of the proper size. Expect size is 8, this key is: 2
-ERROR - 1436578700: (..\StoredBlockObj.cpp:1032) Requesting DB key for incomplete STXO I switched to a different database, running fullnode, and it works there, so I don't think Bitcoin Core actually has a bad block, just that Armory somehow pulled it in wrong. Is there a clean way to recover this supernode DB, or do I need to scrap it and restore a backup I've got (4 months old, lots of reprocessing to do, but better than a full rebuild)? |
|
|
|
The main reason - Armory's master key generated by Armory's algorithm. If the algorithm will be compromised, or will be picked up initial conditions for key generating, then your coins will be at stake. In addition, I think it is not easy to find out (and remember) a phrase for existing key.
I just like idea that you may use your favorite phrase to restore wallet anywhere anytime. Just select strong passphrase. In addition you may create paper fragmented backup if you like.
1. You're underestimating the security of Armory's random number generator. The non-technical version is that computers and algorithms are actually pretty great at generating a limited number of securely random bits. For more details, read this comment in the source code (it captures a lot of info about your mouse clicks, key presses, system files, and a screenshot of your desktop for extra entropy). 2. You can generate a phrase for any given key/number following grammatical structure pretty easily, even if it might not make perfect semantic sense (but that's okay, it doesn't need to be sensical, just memorable). 3. You're overestimating the security of a person thinking up a "strong passphrase". This is what everyone in this thread has been trying to tell you. Bottom line: If your brain came up with it, it's bad! (not 100% of the time, but often enough that that's the advice I'll give you) If you want to memorize your Armory key, what I'd recommend is making an algorithm that can convert between the easy base 16 format and a passphrase format. There should be a one-to-one-to-one correspondence between valid 128-bit keys, valid 128-bit base 16 encodings, and valid 128-bit passphrases. |
|
|
|
Bump. Still available! Prices reduced from $400 to $335 and from $80 to $70.
Does the purchase get made in your name or the buyers? I believe EVGA's 10 year warranty is very dicey for this kind of situation. The purchase would have to happen through my account, so it will happen in my name. This means that the products will be covered under EVGA's terms for a secondary owner, which clearly give you a 3 year warranty. The power supply normally has a 10 year warranty, and the mouse normally has a 3 year, so the mouse is the same, but the power supply's warranty is reduced from 10 years to 3 years (not uncertain/dicey, but reduced). ( their site is down at the moment, but I read it at Google's cache of it) I wasn't aware of this before, but I've added this detail to the post. |
|
|
|
|
Bump. Still available! Prices reduced from $400 to $335 and from $80 to $70.
|
|
|
|
New in box, shipped directly from EVGA (shipped from US; add'l charges may apply if shipping internationally), ground shipping included. Buy both for $15 off! Item 1: EVGA SuperNOVA 1600 T2 Power Supply. Super efficient (higher rating than platinum), 1600W, modular power supply. MSRP $449.99, will accept BTC equivalent of US$335 (1.236 BTC currently) or best offer. ( Edit: Note that, since you won't be the original purchaser as far as EVGA is concerned, you will have a 3 year warranty instead of a 10 year warranty.) Item 2: EVGA TORQ X10 Carbon Gaming Mouse. 8200 DPI, 9 programmable buttons, adjustable weight and size. MSRP $99.99, will accept US$70 (0.2584 BTC currently) or best offer. Escrow through Monbux or other acceptable escrow. If you're interested in a different power supply or mouse from EVGA, contact me with the model number for pricing details. I'm trying to make the best use of a discount offer after a recent graphics card purchase, so I listed the top-of-the-line models in each. |
|
|
|
The difference between "watch-only" and "offline" is whether you have told Armory that you own the full wallet with the private keys ("offline"), or that it is somebody else's wallet you watch (watch-only). I think.
You've got it. |
|
|
|
I copy/pasted an address from a page, and it included the character U+2028 (LINE SEPARATOR) at the end. When I clicked Send, it did nothing visible and logged this: 2015-04-07 20:19 (ERROR) -- Traceback (most recent call last):
File "ui\TxFrames.pyc", line 758, in createTxAndBroadcast
File "ui\TxFrames.pyc", line 429, in validateInputsGetUSTX
UnicodeEncodeError: 'ascii' codec can't encode character u'\u2028' in position 33: ordinal not in range(128) Being a whitespace character, and having no visible error message, it wasn't easy to realize that I had an extra character at the end. I would expect it either to work or to tell me there's a problem with the address. |
|
|
|
Though those change addresses dont help privacy in my opinion. I think they lead to a wrong feeling of security because they look like fresh addresses.
Because they are (by default) fresh addresses. The fact that they might later be combined with other inputs of yours doesn't change this. Lets say someone has a wallet, he receives coins from someone and sends some of them to another address. This happens more than once and at one point the coins from these change addresses are sent out too. Now you can pretty easily connect all the dots and you know with a high certainty that all the addresses that sent to those changeaddresses, belong to this one wallet. You might find out that this user has an investment in this or that security. And so on. Because the one who sent you coins first knows one of your addresses. If he can identify one of the sending addresses belongs to an exchange (there are tools for it out there) then he knows your other address is a change address. Since nothing other normally wipes out all the coins on the sending address. And when the coins from this change address are sent with other change addresses then he can identify even more of your wallets addresses. Not only the other change addresses.
The normal change addresses are a tool to connect addresses in one wallet. Thats why i dont use them because i dont know anymore where the coins came from. Where the are connected to. When i send coins to a FRESH deposit address on an exchange and receive the coins back to a fresh address on my wallet only then can i say that this address is secure. Of course you need an exchange with fresh deposit addresses. There are services out there that only provide one address for lifetime. Its way to easy then to connect all the addresses.
I do see that you have a point, which is stronger when addresses are reused. But I also think that you're overestimating how easy it is to know which address in a transaction is the change address and which is the other recipient(s), and overestimating the amount you should trust the third-party exchange to protect your privacy (sure, the blockchain no longer shows that your addresses are maybe connected, but now Bitfinex and anyone able to hack or subpoena them knows your addresses are definitely connected). |
|
|
|
Is there a plugin or something that automatically can create a new deposit address on bitfinex and send all change, which normally would go to change addresses, to bitfinex, then withdraws it to a fresh address?
Im asking because i do this manually when i think its needed to keep my privacy. Bitcoin wallet addresses can be connected way to easy otherwise.
In Armory, you can specify a change address. You may need to choose Expert mode, then when you send check the "Use an existing address for change" box and "Specify a change address". Granted, this may mean more manual work than you were envisioning, but it is all built-in. It's also worth pointing out that Armory chooses inputs in a privacy-conscious way, to preserve as much privacy as possible in a simple wallet scenario. |
|
|
|
|
As a workaround-ish solution, here's what I did to solve this: create a symbolic link from your %appdata% folder to your other folder. In an administrator command prompt:
mklink /D %appdata%\Armory X:\armory_directory
You can do the same for Bitcoin if you want to.
|
|
|
|
Hex is suitable.
Get the arithmetic right, and you get the encoding right.
Just don't use base64.
Base64 is a big-endian file encoding scheme that takes the data to be encoded and splits it up into groups of 24 bits (3 words of 8 bits). If there's any slop, base64 encoding pads it on the little end. Emphatically not what you want.
 This is basically nonsense. If you use it right then just like base58 and hex, base64 is a perfectly valid way to encode any bytes at all, including a private key represented in the usual way. The padding on the end ensures that you can decode the exact same bytes that you encoded despite the grouping. That said, its character set is a superset of base58's (+/O0Il are the extra chars), and since he doesn't "have the means to use all the base58 charset", base64 will be an even worse option. And maybe if you wanted to encode the private key as a number, without specifying how that's turned into bytes, things could go awry? But really, [some bytes in] == [same bytes out]. I'd recommend the casascius or brainwallet options that luv2drnkbr linked to (I haven't used pybitcointools, but I'd expect that's a good option, too). Be sure to test encoding/decoding/decrypting before you move any real money to something like this. |
|
|
|
It probably would be better to have a gradual reduction but don't waste time thinking about it. It will never happen. A hard fork requires a super majority of users including miners. So for the sake of the argument lets assume everyone except miners already supports this by a massive majority. For the forked chain to be secure it needs a majority of the hashrate so the developers put into the code a phase-in once a certain percentage of miners support the change. To avoid confusion and chaos it needs most of the hashrate something like 80% to 90% not just 50%.
So imagine the code is deployed right now. Miners can either mine ver 3 blocks (25 BTC) or they can mine a ver 4 block which will start the subsidy decay. Once 80% of the last 1000 blocks are ver 4 the change in subsidy will be implemented (say 24.9 BTC). You are asking the miners to vote on if they would prefer to receive 25 BTC or 24.9 BTC. Same work, same effort, same cost less Bitcoins and they need to vote to make it happen. If they don't vote for it they keep getting 25 BTC if they do they get less. It hardly matters that in the long run it will all even out. The miner who would need to 'vote' for the change (by mining the version which reduces the block reward) may not even still be mining by the next subsidy halving.
Who votes to give themselves a paycut when they don't need to? Nobody.
If you implement it in the first ~100,000 blocks after a halving, the reward will actually go up in the short term, so miners will prefer the change, assuming they'd rather have more BTC now. It would be cleanest to implement this at the start of a halving IMO (so it doesn't jump around so much), which would e.g. mean that miners get to mine 17 BTC blocks instead of 12.5 BTC. To understand why, understand that since we still want it to end at the same time, with the same number of Bitcoins mined, each 4 year block will still mine just as many Bitcoins: blocks 420k-630k will still mine 2625000 BTC (12.5 BTC/block, avg) altogether. But instead of "BTC per block" being a flat line for those 210,000 blocks, it'd be an exponentially(?) decaying curve, so it will start out higher and then go lower: for the first almost-half of the blocks, the smoothly-decaying curve is higher than the flat line. |
|
|
|
You shouldn't worry about potential corruption because you should backup your private key propoerly
Right. Then at worst, corruption means you have to redownload the blockchain, you lose comments on your transactions, etc. Importantly, it means you do not lose any bitcoins. |
|
|
|
|
Show Posts
