1441
|
Bitcoin / Armory / Re: 0.96.2 RC1
|
on: August 04, 2017, 09:18:03 AM
|
Can you elaborate on "Supernode DB mode"?
Tracks history for all addresses on chain. how to enable and configure it
Just create a DB with --db-type=DB_SUPER rough explanation of its resource requirements?
minimum reqs are: 1.5~2x blockchain size of storage space 8+ Cores 1000MB/s read and 300MB/s sequential disk I/O 32GB RAM
|
|
|
1443
|
Bitcoin / Armory / Re: Questions about data directory/files
|
on: August 04, 2017, 08:14:06 AM
|
I certainly didn't use that. To make doubly sure it's not PEBKAC, I just created a new testwallet and made an EDB when prompted -- still gives me a .rootpubkey file (though I've no idea if it's the file contents that are off or just the extension, of course). I couldn't have deleted anything by that point if I tried. (That's v0.96.1 official binaries on Windows, BTW).
Will look into it. Is there any way to test which it is, without moving small amounts of BTC back and forth? Can you reproduce it at all?
The security column in the lobby's wallet list tells you if your wallet is WO or has private keys (Encrypted or Unencrypted). Also, should the EDBs be bit-identical to their live wallets or is that just a red herring?
Backups of this nature do not carry comments nor labels IIRC. P.S.: Small buglet: after creating a new wallet, ArmoryDB logs "(BDM_supportClasses.cpp:497) Completed scan of wallet XXXXXXXX" pretty soonish, but GUI shows "Scanning: 0%" in the balance column until restart.
Show me armorylog.txt
|
|
|
1444
|
Bitcoin / Armory / Re: Guide: Bitcoin Cash (BCH) & Bitcoin (BTC) w/ Armory
|
on: August 04, 2017, 07:59:36 AM
|
Sure, that works. I just finished implementing the BCH signer, need to test it against the BCH chain now (it does create sigs that are invalid on the Bitcoin chain). With that part, you do not need to cycle your BTC wallet anymore to move your BCH, as you don't have to import your private keys into another piece of software.
|
|
|
1448
|
Bitcoin / Armory / Re: Questions about data directory/files
|
on: August 03, 2017, 09:49:04 PM
|
If the file has no pub keys, you're gonna end up with a copy of a WO, hence the .rootpubkey thing. Now I'm really confused ... That's a typo, I meant to write "no priv keys". why/when would that be the case and is it normal for a new wallet?
There's an option to delete the private keys in a wallet. Cryptic stuff, but the edge cases need covered in the GUI regardless. P.S.: The different extensions for Linux and Windows EDBs might just be cosmetic: The Linux file picker has .wallet as default extension for new backups but filters for "Root Pubkey Text Files" (so doesn't show old backups in the same folder), Windows has .rootpubkey for both. Could be a case of an extension not consistently changed.
rootpubkey backups were added by droark a couple years after the wallet code was written by etotheipi. The 2 years apart and 2 different devs could be the cause for some inconsistencies in file extention naming. If youfind an inconsistency, let me know. So I guess the question becomes, are my wallets and EDBs fine, even though they're not identical and "have no pub keys"?
Regardless of my reply, you should just test the backups to make sure. Ok, so delete all three, two will regenerate. Voight-Kampff test for timelords. Gotcha.
For what it's worth, the ID computations are different because the legacy one is tied to the Armory specific chain derivation algo, whereas the new wallets can maintain several derivation schemes within the same file.
|
|
|
1450
|
Bitcoin / Armory / Re: Questions about data directory/files
|
on: August 03, 2017, 07:05:28 PM
|
1) encrypted digital backups result in one *.wallet file (on Linux) but one *.wallet.rootpubkey file (on Windows). Why the different suffixes? Is the content of these backups the same (rootpubkey sounds suspiciously like it might be missing the private key)?
"Encrypted digital backup" is just a copy of your wallet file. If the file has no pub keys, you're gonna end up with a copy of a WO, hence the .rootpubkey thing. 2) Can the LMDB wallet be regenerated at will or should it be backed up as well? What kind of information does it (not) contain, compared to the legacy wallet, how sensitive is it privacy/security-wise?
They're created on the fly, they only contain public keys and the chaincode. 3) How can I tell which legacy wallet corresponds to which LMDB one, seeing as the 9-char-IDs are all different? For whatever reason I have 3 sets of .lmdb* files for 2 active wallets (1 online, 1 offline, in case it matters) -- normal, or left-over stale data from a past wallet-creation experiment?
You can't, the ID computation is different. The extra you got is a left over. 4) On Linux there's a file called "~/.wallet", even though datadir is default ~/.armory, that I did not, to my knowledge, create manually. Any idea how it could've gotten there? User error is most likely, but if there's a chance Armory writes wallets outside of its datadir, I'd like to know.
Armory only operates inside its datadirs. Some other process created that folder.
|
|
|
1451
|
Bitcoin / Armory / 0.96.2 RC2
|
on: August 03, 2017, 06:02:02 AM
|
Time to test 0.96.2: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.1.2Changes: v0.96.2 == Added == - Improved DB scan speed (~80% faster) and stability. - Reduced DB memory usage (~20% less). - Supernode DB mode. This isn't optimized for consumer grade computers, use at your own risk. - The MAX button in the Send dialog has been changed to a checkbox, effect is now binding. Maximum value will be calculated on any change. - You can now create OP_RETURN outputs from the Send dialog. This feature is only available in Expert mode. - You can now pick the signer of your choosing in Expert mode. - Added BCH on top of the legacy and 0.96 C++ signer. == Fixed == - Fixed benchmark timers on POSIX systems. - Fixed several Linux build configure bugs. - Properly update RPC state in GUI on connect/disconnect events. == Removed == - Removed armoryd from the repository. armoryd was moved to its own repository ( https://github.com/goatpig/armoryd) BCH miner howto: https://bitcointalk.org/index.php?topic=2070058.0Happy testing =)
|
|
|
1452
|
Bitcoin / Armory / Re: Armory and BCC chain
|
on: August 02, 2017, 10:40:50 PM
|
EDIT: I read elsewhere that Armory chokes when trying to send a Tx under Unlimited. I think this has to do with some networking changes made to Core after Unlimited split off. ABC might work but I haven't tried it yet. Maybe you will and you can report back? TL;DR: I didn't shit all over the Armory signer code to accommodate their rushed 2 way replay protection code (4 days from the split). I'll reassess this if their chain survives.
|
|
|
1453
|
Bitcoin / Armory / Re: Guide: Bitcoin Cash (BCH) & Bitcoin (BTC) w/ Armory
|
on: August 02, 2017, 10:38:58 PM
|
*** Update: Armory database with Bitcoin Cash blocks is working fine, but tx broadcast of Armory through Bitcoin Unlimited Cash isn't working though. I will try it with BitcoinABC and publish my results. ***
Of course it won't, BCH changed the sighash as part of the replay protection. Armory cannot create valid sigs for BCH at the moment.
|
|
|
1454
|
Bitcoin / Armory / Re: Armory 0.96.1 is out!
|
on: August 02, 2017, 07:53:24 PM
|
I certainly didn't mean to complain, sorry if it sounded that way. FWIW, I'm really happy with the direction Armory is going and the pace it's going there is incredible, especially for a one-man show.
I used the word complain in the sense that no one raised an issue with the build dependency, therefor I never gave it much attention. I simply grand fathered it from the legacy Makefile when I reworked the build process in autotools. I seriously have no idea why it was preferred over more common calls to copy files around, but when you've battled autohell for 2 weeks in a row, your bar for acceptable code has long moved from "ideal" to "if it works I'll take it". I'm guessing this is the state of mind etotheipi was in when he wrote his Makefile. As for the updated build dep instructions, that was PR'ed in, and that's more symptomatic of my build setup than anything else: My machines have had all the stuff I need to build for years now, therefor are dark areas of the build system in the sense that I just have no idea if the dependency is common to most distros or if it's something I'm shoe horning by negligence. * pathing 1: apparently, ArmoryDB is expected to be in $PATH (it's called just by name) -- maybe use the absolute path (from configure)? * pathing 2: the screen that shows the deck of cards seems to be very sensitive. It works, when launched in $PREFIX/share/armory (i.e., directly above img), otherwise I just get blank buttons, like under Windows -- some base path for resources not initialised correctly?
Will have to look into it. For whatever reason, the images in for the deck of cards are being read from the file system instead of the pyqt image resource. It's an easy fix, but again a symptom of stuff I overlook cause my build system is set in such a manner I just don't get to see this bugs. That and the small test coverage I get for GUI.
|
|
|
1455
|
Bitcoin / Armory / Re: Armory 0.96.1 is out!
|
on: August 02, 2017, 05:43:55 PM
|
I suppose the same rationale goes for the local copy of crypto++? I'm a bit weary of whole projects of source copied in verbatim in general -- it tends to either remain in the initial imported state forever or drain resources from the importing project (which has just one man, as it stands). Case in point, even Debian stable looks to have a newer version.
That's something I inherited from the previous maintainer. I want to move to libbtc. The build process is a bit byzantine, why does it need rsync at all and why is there so much code being built during make install ...
Inherited that too, no one has complained about it either. As for the stuff being built by make install, blame SWIG, or Python in general. * pathing 1: apparently, ArmoryDB is expected to be in $PATH (it's called just by name) -- maybe use the absolute path (from configure)? * pathing 2: the screen that shows the deck of cards seems to be very sensitive. It works, when launched in $PREFIX/share/armory (i.e., directly above img), otherwise I just get blank buttons, like under Windows -- some base path for resources not initialised correctly?
Will have to look into it.
|
|
|
1458
|
Bitcoin / Armory / Re: Armory 0.96.1 is out!
|
on: August 01, 2017, 05:31:49 PM
|
Thank you for --without-gui! That gets rid of all the QT and Python deps in one fell swoop. And since you're already fiddling with the build system, how about --without-online to build just the GUI part, for offline systems? ^^ That'd probably also make it easier to keep supporting older systems for offline-only use.
Oh, and why do you maintain your own version of libfcgi? Is it just build fixes or is there more? Since libfcgi is pulled in as a submodule after the fact it presumably isn't covered by the main repos signature checks, so if it works I'd rather install libfcgi-dev and be done with it.
libfcgi is statically linked in, and I've modified some of it. I'm looking to do web sockets at some point and get rid of fcgi eventually, so I don't want to struggle through dynamic linking it and all the build process mods. As for the --without-online part, that's kinda tricky with autotools. It would make the DB compilation part optional as well, and you need a constant baseline to do that optional compilation switching without large headaches. On the other hand, the DB is pure C++ and shares a few code files with the GUI, so if you can build the GUI, you can build the DB. Therefor, in terms of build process, the DB does not introduce more dependencies so it's the natural baseline. For offline systems, you'd want to remove the client with --offline anyways, therefor the effort required to allow this at the configure script level is not justified to begin with.
|
|
|
1460
|
Bitcoin / Armory / Re: System for Armory upgrade
|
on: August 01, 2017, 06:21:41 AM
|
You're conflating key pairs and Bitcoin scripts. You sign messages with a key pair. You receive coins to scripts and spend the coins by redeeming the scripts (usually involves a signature using the private key).
The wallets have not changed at the key pair level. The new stuff added extra scripts. The old signers cannot make sense of these scripts, so if you receive coins to new scripts, you need a new signer to create the redeeming script in order to spend.
The old DB cannot generate the new scripts, therefor it can't see coins on these scripts. If you receive coins to such scripts, you need to use a 0.96+ DB to see your balance in full.
|
|
|
|