|
Does it work with 0.94.1?
|
|
|
|
|
Your bitcoin node keeps crashing for some reason. You need to figure out why.
|
|
|
|
That seems to have solved it! Wish I'd noticed that that site wasn't the real one. They've got good SEO :/
Thanks!
The site you posted is the original site of armory, but they no longer maintain it. I don't own that page, it belongs to ATI, the former Armory maintainer. |
|
|
|
|
Alright guys, thanks for covering for me, but sometimes the criticism is due. Clearly there is better to do with the follow up on DB mismatch detection. This latest outburst is only proof of that.
For that matter, I'll try to add a couple mechanics in the next version:
1) Make sure that an auto managed DB detects its parent client has terminated, so that it may clean up on its own.
2) Add a .conf for both client and DB. This should make life easier for people to setup, modify and maintain custom paths across versions. Since upcoming versions will have to change the DB to an extent once again, the effort wont be wasted.
3) Some GUI to manage custom paths from the client would be nice, and DB mismatches can then fall back to that instead of just terminating the client.
All in all, I believe with these changes and blocks over p2p, Armory's initial setup should get a lot closer to plug and play.
-------------------------
micalith:
I'm addressing this part to you directly because this is your thread, but this goes for all users in general. If something frustrates you with the software, lay out what it is and what you feel would make the experience better. I understand you feel the need to vent, and for what it's worth, I'm sorry for the inconvenience.
Now, on your end, you should consider my perspective. If your thread is all spite and venom, I simply won't feel like dealing with it. My life is shitty enough as it is, I don't have the bandwidth to help out pissed off people. So meet me in the middle.
Software engineering is an incremental process for the most part. Believe it or not, if you make an effort of laying out what is broken and what is stupid, I'll make an effort to improve it. I'm not pretending Armory will ever have a buttery smooth initial setup, but certainly there are places that could use some help.
Do not get the wrong idea though, under my reign UX is secondary in Armory. Developing a robust and powerful platform that delivers the full Bitcoin experience comes first. A man has to have his priorities.
|
|
|
|
I am assuming that armorydb does what I ask about in the OP
Yes. No TLS though, I'll be using BIP151 for encryption in a later version. |
|
|
|
Feel free to PR the change to the TODO list. |
|
|
|
Just a few fixes, listed in the changelog: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.1v0.95.1
== Added ==
- Pass client datadir to auto spawned DB
== Fixed ==
- Fixed coin control GUI
- Fixed base58 decode edge case
- Fixed db version detection
- Fixed db error message reporting in GUI
- Fixed explicit db port overwrite in testnet
|
|
|
|
|
I'm aware of this, fix coming for 0.95.2
|
|
|
|
What is it about the Armory program that causes it to stop adding blocks?
Armory reads block data straight from disk. Since Core 0.10, that data is no written sequentially anymore, and there can be large gap in between consecutive elements headers of the chain, preventing Armory from detecting additions to the longest chain. 0.95 is better at dealing with this particular issue. I saw somewhere that you have a v0.95 Armory version out. Is it ready for prime time?
You should wait for 0.95.1, which will come with a set of minor fixes. This is scheduled for sometimes this week, still working on one last bug report. |
|
|
|
Great, I just realized my response was never posted, thanks to the DDoS episode. A few minor things; dbLog.txt didn't get created while I was testing the Db building with Whonix/Qubes.
The first line the db outputs in the terminal is the db log path. Double check against that and let me know. That drew my attention to the progress bars: headers stage is too indecisive/imprecise in it's estimates, and the Tx hash resolution stage has a kind of crazy strobe effect as well as supremely eccentric estimates (started at 10 seconds, stayed there for 10 seconds, stayed at 1 second for a minute etc).
The progress bars were designed in 0.92 when the DB was much slower. I did not change anything to the underlying ETA code, just plugged it into the existing code. I will have overhaul that stuff at some point. Not a priority right now though. One last minor: uncommented tx's used to inherit the label of the address they're associated with instead of just being fully blank.
That and the other minor features that were not replicated in this version will be fixed in 0.95.2. For now, I have one user reporting a crash. I am waiting on his input in order to fix that one, then I'll release 0.95.1 |
|
|
|
2016-10-30 22:54 (INFO) -- ArmoryQt.py:3121 - Current block number: 432617
...
2016-10-30 23:07 (INFO) -- Networking.pyc:159 - StartHeight: 436677
Your db is some 4k blocks lagging behind your node. I suggest you rebuild & rescan. |
|
|
|
|
Need your Armory logs, not your Core logs.
|
|
|
|
Hi Goat, thanks for the response.
So, I have 2 lines with 36 hexadecimal characters each after I convert them.
What is that exactly? I'm learning everything related to Bitcoin coding using NBitcoin, so I kinda grasp the most important concepts but not all.
Thank you!
It is the wallet's root private key, a 32 bytes binary string, from which Armory wallets are derived. Hi! Armory doesn't use the standard derivation path or it uses a different algorithm altogether?
Armory HD wallets predate BIP32. As a matter of fact, the design in Armory was part of the inspiration for BIP32. Now, I am in the process of adding BIP32 support to Armory, and that is scheduled for the next major release. For now though, there is no such functionality available in Armory. To compute chained addresses, Armory first derives what is called the chaincode from the wallet's root private key. You can see the Python code here: https://github.com/goatpig/BitcoinArmory/blob/dev/armoryengine/ArmoryUtils.py#L3489Using the chain code, Armory can then derive the address chain sequentially, each new key pair N+1 resulting from the exponentiation of the key pair N and the chaincode. The exact procedure can be seen in the code here: https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/EncryptionUtils.cpp#L825https://github.com/goatpig/BitcoinArmory/blob/dev/cppForSwig/EncryptionUtils.cpp#L749 |
|
|
|
Sorry, I'm not familiar with the procedure. Do you mean test for the bug in the next release and report accordingly? Please elaborate.
I mean pull the code from dev, build from source and test for the bug again. If you can't build from source, you're left with crossing your fingers and waiting for the next build. |
|
|
|
First pick from a multi input address respects the users choice (which is fixed compared to previous behaviour). Changing one's mind after hitting accepts reveals the bug, and it seems similar to before: all the inputs from the address of the intended selected input appear to get selected, but quickly scrolling down the list shows that not quite all the inputs in fact are selected. It seems that random inputs (only at the same address as any inputs picked originally by the user) are left unselected, but whether that does really conform to some pattern I can't say.
Correct. The DB won't put its log file (dblog.txt) in the explicit datadir (which I usually refer to as the alternate location/directory/path) as specified in the arg. Furthermore, if it cannot detect an "Armory" folder still at the default location to put the dblog.txt file into, that's when it hangs. It requires it.
Both these should be fixed in dev, please test and report. |
|
|
|
With the above setup, ArmoryQt runs just fine and properly spawns ArmoryDB but with a caveat: an "Armory" folder must still exist at the default location (i.e. C:\Users\username\AppData\Roaming\Armory) because it insists on having the "dblog.txt" file reside there. Otherwise, it hangs as before.
That's quite a different situation here from what I had understood. Are you saying the DB won't put its log file in the explicit datadir? That's a bug, not a design choice. I'll try to reproduce on my end and fix it for the point release. |
|
|
|
|
Show Posts
