Hah, you learn something new everyday.
In c++, variables can be changed by passing them to functions, thanks to the reference notation.
This is something you need to pay attention to when reading the method declaration. const& is used to avoid copies when passing arguments, and means the arg is an "in". Plain & implies the method is supposed to modify this reference, in which case it's considered an "out" argument. This is common practice when you want to use the return value of the method as a status report. Typically your return an int, with 0 for success and negative values for error codes. You can also use this approach if the method has to provide several results, but that style is mostly for C. In C++ you tend to report errors by throwing, and write a class/struct for return types that require several members. As seen in the code you linked to, the style is actually confusing: the semantics do not outright suggest ReadLastBlockFile takes a reference, as it is not being checked for a status return. This kind of semantics suggest you are setting some internal value for object pblocktree instead. The following snippet would be a little easier to read: int result = pblocktree->ReadLastBlockFile(nLastBlockFile)
if(result != 0)
{
//error handling
}
//do something with nLastBlockFile
With that in mind, the change in BU could very well be a mistake that led to a benign change in behavior, assuming the author of the change did not bother to acquire a broad understanding of this code before modifying it. He possibly saw a global variable changed by a local object and figured that's bad style, correcting for style without caring for the substance. |
|
|
|
Not sure where that 71t5T98T wallet came from or why I recognize it and why it has the same root key.
With 1.35, the chaincode is not related to the root key. This is why it is added to the backup string. With 1.35c, the chaincode is a HMAC of the root key, therefor only the root key is necessary. The Wallet ID is derived from the first key pair, which is computed from the root key and the chaincode. Different chaincode, different ID, different address chain. So "Total leaving wallet" is unsettling to say the least, but I suspect this is just a change address and it's really the total leaving the address where this bitcoin is. Correct? That 3Btalvivm... address is unsettling too, because I can't see all of it! It's also concerning because I have more than x btc in the wallet, but I guess they are associated with other addresses?
In Bitcoin, you spend whole coins, which is why there is a change mechanism to begin with. This dialog is telling how much in coins are being used in this transaction. From your perspective, it doesn't mean you're spending that much (since you're receiving coins back in the change output), what it means is that this much value is tied up in this transaction. Think about it terms of cash. If you're buying a $1 candy bar with a $10 bill, $10 is leaving your wallet. Your $10 is tied up in the transaction to buy the candy bar. Once the transaction is over, you're getting $9 back in change. If I don't hear back today, have a Happy Thanksgiving!
Time to find a turkey sammish hmm |
|
|
|
works on mainnet, but ArmoryDB doesn't connect to testnet bitcoin nodes. Maybe something to do with the satoshi-port option?
Botched the defaults for testnet/regtest, you'd have to force the proper port with the new cli arg. |
|
|
|
|
71t5T98T cannot sign for 2cP2BUXi7. Restore 2cP2BUXi7 on your laptop.
|
|
|
|
|
Do not delete anything. Does 71t5T98T show balance? What are you trying to do by restoring 2cP2BUXi7? Get something else than a watching only wallet?
|
|
|
|
|
Blocks over P2P would actually fix this, because it would get the longest chain from your node, then grab block data by hash from that chain of headers, all over the P2P socket, completely ignoring the on disk file structure. I initially wanted this change for security reasons: Core needs to be exposed to the WAN but Armory does not need the WAN unless you want to connect to the DB remotely, and even then you could tunnel to it or put it behind a daemon. Limiting ArmoryDB's interactions with Core to just a couple sockets (P2P and RPC) would make way for more secure setups. Dodging this edge case is an added bonus now.
|
|
|
|
|
Sounds like you mixed and matched the restore types. From the looks of it, you mistakenly restored your wallet as a 1.35c on your laptop. This is probably what is confusing you atm.
The most important question at the moment is which wallet shows your coins?
|
|
|
|
|
Are you using SecurePrint?
|
|
|
|
A solution would be to keep a record of "last-checked time" and then re-scan any old blk files that have a modified time greater or equal to the last-checked time. This check could be run any time a new block notification is received.
Once it writes to a blk file, it never checks files lower than that anymore. That is a RAM variable though, so it gets set back to zero each time a node is restarted.
Why would it need to check for previous files appends on new blocks? If the issue only happens on fresh node start (when free space in older block files is eligible), as long as Armory sees that one new block, it will work. Armory does not expect blocks to appear in order in files. It will check block data on disk from the last known block to have extended the chain. Therefor if you have up to blk01000.dat and the last top is in blk00997.dat, it will check #977 to #1000 on every new block notifications until it finds a block that extends the chain again. Would re-scanning already scanned blk files cause problems for Armory?
DB is designed to whistand being written over. Rescanning is fine. As a matter of fact, on each start Armory rewinds back 100 blocks from the last known top to account for long reorgs occuring while it wasn't running. You can see it here: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/DatabaseBuilder.cpp#L55 //rewind the top block offset to catch on missed blocks for db init
auto topBlock = blockchain_->top();
auto rewindHeight = topBlock->getBlockHeight();
if (rewindHeight > 100)
rewindHeight -= 100;
else
rewindHeight = 1;
auto rewindBlock = blockchain_->getHeaderByHeight(rewindHeight);
topBlockOffset_.fileID_ = rewindBlock->getBlockFileNum();
topBlockOffset_.offset_ = rewindBlock->getOffset();
LOGINFO << "Rewinding 100 blocks";
You can increase this value to try and confirm your theory. On Bitcoin a blk file is ~100 blocks, on BCH idk, try much larger stuff. The ultimate solution would be blocks over P2P, but idk what kind of mess BCH will be by the time I'm done with that. Chances are Armory won't be compatible anymore at that point. |
|
|
|
|
You have to use the restore version that is indicated on your wallet. If it says 1.35, that's the only restore version you can use.
|
|
|
|
|
Start BitcoinQt manually.
|
|
|
|
This is a minor release with a lot of bug fixes and a couple new features: - Spend to bech32 addresses - Set DB dir in GUI (File > Settings menu) Note Recent updates to the MSVC compiler broke CryptoPP's AES-CBC optimized decryption. This affects restoring SecurePrint backups on Windows with 0.96.4 only. All backups made with 0.96.4 are valid. Optimizations for CryptoPP have been disabled on Windows. I'm looking to replace it with libbtc sooner rather than later as a result. Changelogv0.96.5
== Added ==
- You can now set the database path from the Settings menu.
- You can now spend to bech32 addresses.
- Added support for satoshi-port CLI argument in ArmoryDB.
== Fixes ==
- Improved bitcoind path detection.
- Properly carry thread-count and ram-usage command line arguments from client to automated db process.
- Custom paths set in the GUI will now properly overrule custom paths from armoryqt.conf.
- Fixed spending from lockboxes.
- Fixed deleting lockboxes.
- Fixed Simulfund promisory note creation and signing.
- Fixed preview dialog for unconfirmed transactions.
- Fixed previewing unsigned transactions in offline mode.
- Fixed SecurePrint decryption on Windows.
- Recent updates to the MSVC compiler resulted in invalid decryption of AES-CBC packets. This issue only
affects the decryption of SecurePrint encrypted backups. Encryption still operates as expected, no
SecurePrint backups created with the incriminated builds are faulty. Wallets are not concerned, as they
use AES-CFB.
The solution was to turn off all optimizations in MSVC when buidling CryptoPP. This may impact DB boostrapping
performance.
This issue affects all Windows builds of 0.96.4.
Binaries: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.4.99Test away! |
|
|
|
|
First, you should try the current state of the testing branch. If that fails, I can at least fix the errors at tx creation with the WO wallet or the public keys for the relevant outputs. Otherwise try to these tx without using the MAX feature.
|
|
|
|
|
Fixed in testing, will be in the RC for 0.96.5
|
|
|
|
|
Fixed in testing, will be in the RC for 0.96.5
|
|
|
|
1) When are these tx failing? At signing? At creation? Are these offline transactions? 2) The second error seems to have to do with the use of the MAX feature. Try turning that off, see if you can create the tx. I'm still receiving on that wallet else I would be okay to send it to you so you could easier debug
Depending on when the bugs occur, I could possibly fix this with just a watching only wallet. I could try to import the privkeys in a new armory wallet and see if it will work then, but not sure if armory would "create" the p2sh version then or just p2pkh...
Import aren't scanned for p2sh schemes, only p2pkh. |
|
|
|
|
You are showing 2 errors, are both of these happening together?
|
|
|
|
|
What version are you using?
|
|
|
|
|
I wanted the logs to see if the client was forwarding the argument to the db to begin with.
A quick look at the db code shows this argument is ignored as a whole. I'm about to push the RC for 0.96.5, I'll add it in there.
|
|
|
|
|
Show Posts
