|
I don't touch users' root keys. You'd have to elaborate on the error you're experiencing and give me log files.
|
|
|
|
|
The SecurePrint password is the base58 of the first 7 bytes of the hash of your root key. Depending on the "integer" value of these 7 bytes, the length of the SP password may vary.
|
|
|
|
Still, I wonder how to regenerate the change address if this happened again... It might be useful to other users todo  An address expresses a public key with some added meta data. There can be several addresses for a given public key. In the case of Armory, there are three. When you get Armory online, or when you take a transaction to an offline signer, Armory will detect which public key was used. That is because it carries all address variations per public key. This change came later in Armory's life. At first Armory only had one address type, before P2SH was a thing even. Therefor, Armory's GUI was not built with that kind of future in mind. When I added the new address types (that was the segwit support release), I opted to let the GUI display a single address per public key and detect which address type was being used in the background. As a user, when you generate an address, it is assigned the default type as displayed in your settings. In Expert User mode, you can modify this address type on the fly in the new address creation dialog. In your specific case, you'd have to generate new addresses while you cycle through the 3 different types until you find what you're looking for. |
|
|
|
|
Disk IO is the primary bottleneck, then RAM, then CPU cores.
|
|
|
|
|
Do you know the change address? Does it start with a 3? At any rate, once Armory is online it will find the change the address.
|
|
|
|
|
Your logs suggest Armory is setup correctly. My guess at this time is that the address you are looking for is not part of the wallet your restored. Did you have other wallets? How is the address chain on this wallet your restored? It should be 1000 but maybe it's shorter. Do you have any other information on the address you used? Like when did you create it, using which version? Are you sure it is tied to this wallet? Did you have several Armory wallets in the past?
|
|
|
|
I don't know about building Armory on a R-Pi. I've always cross compiled it for Raspbian. You can lookup R-Pi cross compiling quite easily. Be warned, it's painfully annoying to get it to work. I may just buy a Pi4 and build straight on that. This OS is still on beta stage, and I suppose it also uses the latest python3 (not sure if it's also on QT5 or still QT4). It's therefore very likely the old stable branch of Armory couldn't run on it, and I should try compiling it from the development tree.
dev branch just went through the py3/qt5 migration, it's still quite unstable at this time. It doesn't build without manual intervention atm, you'd have to wait a little. My current near term project is to create and sign a mainnet tx with it. |
|
|
|
Armory spoofs itself as a node to your Core instance in order to get new mempool entries, new block notifications and push transactions. There is no ACK from a Core node when you send it a transactions through the p2p protocol. You can only query the node's mempool for your transaction's hash to figure whether it made it in. This is the timeout mechanic; Armory isn't gonna hang forever for the transactions to make it in. It doesn't mean Core didn't accept the tx. Core tends to batch transactions together before processing them and pushing them to other nodes. This can delay the entry of your specific tx in the mempool to the point that Armory just gives up and assumes the tx didnt make it in. Eventually, I added a fallback to use the RPC, which gives you an actual ACK. You have to consider that at the time this stuff was designed, the RPC was much harder to setup, so RPC broadcast never was considered a default. You still get the error message because ArmoryQt brokers the RPC connection so it hsa to be made aware of p2p broadcast fails in other to attempt a RPC push. 1. Why did the transaction not go through the first time, but did the second time? Possibly an actual timeout where Armory didn't deliver the tx to Core before the query window expired. To push a tx, Armory has to announce it has one, by hash, and Core has to ask for its body. This part of the exchange can timeout as well (Armory just waits 10 seconds before calling a timeout, it doesn't care which part of the process it failed at). Usually timeouts occur at the second half: Core took the tx body and Armory is polling Core's mempool to see if the tx made it in. What is the meaning of the error and how can I avoid it? You can't avoid this error in the current Armory. Even if you have RPC up, you will be notified of a p2p broadcast timeout if that actually happens. If your RPC is set up, the fallback should see you through regardless. The new broadcast code in the upcoming release deals with this stuff directly on the DB side (ArmoryQt doesn't talk to Core anymore, it's all handled by ArmoryDB). It also has a better way of handling Core mempool polling so the timeouts are less likely to occur. Is there anything else to keep in mind in this context? For example, are there any risks in accidentally broadcasting a "_SENT" multiple times? You can't rebroadcast a tx that is already in your node's mempool or the blockchain itself. Current version has poor verbose around this. Next version gives you a fuller error report in this kind of cases. There are no short term security concerns here. You can't modify a signed tx, just broadcast it. If your intent was to get this tx into the blockchain, you're fine. In the long term, you shouldn't leave a transaction you signed but didn't broadcast hang around on an online machine *if your intent is to not broadcast it in the future*. A valid, signed tx is as good as coins spent, you should either broadcast it or double spend one of the underlying utxos to invalidate it. |
|
|
|
I'm not asking you to show me your addresses, I'm asking you to check if the addresses you have flagged as having balance actually exist in your wallet. I still can't tell if that's the case or not. This would be the first place I'd look. Although it probably doesn't matter if I'm unable to see the address within the wallet itself or does any part of the scanning or recreation have the probability to not load all the correct address from the past?.
If the address is part of your wallet, it will be there. You cannot create one address without the previous one in the Armory wallet scheme. If you have any history at all, this wallet is most likely sound. You claim you setup Armory successfully but do you have evidence of that? Is there any history in the main ledger? Any balance? Do you have addresses listed as used in the wallet's properties dialog? Can you look at their individual history? How many transactions do they have? |
|
|
|
|
Do you have the addresses you expect funds on? Have you checked their balance on a blockchain explorer (disclaimer: that will leak some privacy)? Have you checked they exist within your restored wallet?
|
|
|
|
2021-01-26 18:44:03 (ERROR) -- BDM.pyc:197 - DB error: C:\Users\wmbev\AppData\Roaming/Bitcoin/blocks is not a valid path This line leads me to believe you have not setup your paths correctly. ArmoryDB cannot find the Core blockchain data. This suspicion is reinforced by your custom install folder: Noting that the lockbox multisig you mentioned provided the error that contained the address I was previously using - is it then possible that my file / backup is corrupt? What this error looks like is that you tried to load something that isn't unsigned transaction data in the unsigned transaction dialog. The log indicate your wallet loaded successfully. |
|
|
|
|
1) This error isn't related, this would happen when trying to sign for a lockbox (multisig)
2) How are you restoring this wallet? What's the source? How many addresses are in it?
3) Need to see the full logs.
|
|
|
|
Currently, I can't do anything. I've rescanned the database and had to cancel after waiting for a day each time. Don't know what to do now because obv I don't know if it is even "working", according to the taskmanager it uses < 0,1 CPU and I've been waiting for 24h before canceling it bc it felt odd to take this long.
Delete your Armory databases folder and try again. |
|
|
|
|
It doesn't have anything to do with RBF, it has to do with some of your UTXOs. How many are there? You can check that in the UTXO selection dialog?
|
|
|
|
|
How are you creating the transaction that leads to this error?
|
|
|
|
Please see the above post, when I try to open it the file is either empty or full of hashtags.
Top of the file may be filled by a lot of blanks as part of a log file truncation bug, the bottom half should have the data nonetheless. found another thing that made me curious, I'm trying to send to a SegWit address but apparently Armory uses the Legacy Armory addresses (P2PKH), could this be the reason why I'm not able to make transactions?
Where do you see that? At any rate the bug you're experiencing is most likely this: 2021-02-01 20:56:00 (INFO) -- TxFrames.pyc:827 - Change address behavior: NewAddr
2021-02-01 20:56:00 (ERROR) -- Traceback (most recent call last):
File "ui\TxFrames.pyc", line 948, in createTxAndBroadcast
File "ui\TxFrames.pyc", line 902, in validateInputsGetUSTX
File "armoryengine\Transaction.pyc", line 2513, in createFromTxOutSelection
File "armoryengine\Transaction.pyc", line 2414, in createFromPyTx
File "CppBlockUtils.pyc", line 3062, in getTxByHash
DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x0000000005F89C90> >
It's trying to grab the parent tx for the output being consumed but the DB can't find it. Is it ZC parent? Otherwise you should rescan your db. |
|
|
|
|
I wouldn't try to emulate x86 on ARM. Your best option is to build yourself from source.
|
|
|
|
|
You could build Armory straight for the target OS as an alternative.
|
|
|
|
|
Changes in the P2P layer are backwards compatible nd no existing calls are really ever deprecated (this is only relevant when commands are replaced over security concerns). It's a (somewhat) service based handshake so that part will probably never really break compatibility with Armory.
The on-disk format probably won't ever change, there isn't much room to gain there, it's simpler for Core to keep it as a raw block data dump. Put another way it's unlikely Core updates will break Armory compatibility, more like they'll introduce new stuff I'll have to catch up to.
|
|
|
|
|
Show Posts
