using the coin control feature and it seems I found why such an error.
Describe it step by step. The number u put into field above must not exceed that one put into Manual fee/byte in File=>Settings=>Fee and Address Types. So in my oppinion the option that allows to change the fee in Select Fee Type subwindow is missleading
Defaults do not override user inputs. You need elaborate on what you are doing or I cannot figure out what the issue is. And one more view. 0.93.3 was allowing to see all addresses available and the fund on each of them. It was very convinient. It seems that 0.96 does not allow this and all addresses are hidden as u must to double click to make visible at least one of them but not all in bunch . i.e Wallet Properties window in 0.96.0.1 does not show all addresses available. It is not convinient
You have to widen the first column. |
|
|
|
|
Your mix of fee and spend value is more than what you can actually spend. Are you using the coin control feature or are you spending very low amounts?
|
|
|
|
I am unsure what you mean with "build yourself", something different than what I did?
0.96 could not build on old CPUs cause of the broken cryptopp makefile. I assumed you were using builds instead of building from source because of that. |
|
|
|
|
I don't get what you are referring to.
|
|
|
|
|
Build the client yourself and try with that.
|
|
|
|
Build 0.96.1 and try again.
All the same segfault with v0.96.0.1-testing. Ente You mean the invalid instruction issue? |
|
|
|
|
How can CBC even work with on disk encryption? If it's done by using part of the storage device to hold the IVs, no wonder it's damn slow. You should stick XTS.
|
|
|
|
There haven't been any sync issues (even with a slow/encrypted HDD), nice job! :-)
This is all you, I have not had time to go over the block delay. Actually it would confirm DB is doing fine on AES128 but chokes on 256 |
|
|
|
but I have gotten a merkle root mismatch again, BUT without any block deser exception
Getting this error alone is a false positive. The code tests no disk blocks all the time, sometimes they are partial and it won't proceed further. When it's paired with a deser error, it means a block expected to be valid was not. That's the result you want to avoid. However during the build&scan process no exception occured what-so-ever, although my ArmoryQt crashed once and after the next start ArmoryQt was 100's of blocks smarter (above) Core...
If you did it while Core was still syncing, the code found the headers but does not yet have the block data, as Core will write the headers first, reserve the size for the block data, and commit that last part eventually. |
|
|
|
|
Build 0.96.1 and try again.
|
|
|
|
So what is the cause of this? What would be the worst possible outcome?
This means the incoming Tx is RBF flagged or spends from a unconfirmed output. Worst outcome is the original output is double spent and you end up with no coins. ELI5 is wait on a confirmation. |
|
|
|
Third testing builds are out. ------------------ Binaries:https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.0.4Fixes/Changes: v0.96.1
== Added ==
- Split unit tests building from default autotools setup. To build tests, use:
./configure --enable-tests.
- You can now disable GUI in the autotools build system. Use:
./configure --without-gui
- When spawned with a cookie file, the DB now randomizes its listen port to (49150 + [0-15000]) and reports it in the cookie file.
- Added --fcgi-port command line argument to the DB.
== Fixed ==
- ZC parsing will no long occur while the BDM is initializing
- Wait on cookie file creation before connection to auto managed DB
- Fixed registration/callback premature garbage collection
- Translation patch issues
- Fixed "Fund from wallet" lockbox GUI
- Fixed TxIn/Out pretty printing
- Tied init phase spinning icon rotation to progress notifications. The icon will not spin when no progress data is received, correctly
indicating the DB is hanging.
- Fixed cryptopp build against older CPUs (no AES or PCLMUL archs)
- Fixed RBF bumping with no change
== Removed ==
- Python-twisted dependency. This should remove the underlying openSSL dependency as well.
-------------- Linux users:If the build fails to run on your setup (unknown instructions), it means your CPU is missing SSE4/AES/PCLMUL instructions. There will be a fail safe gcc4.7 build without any of those instructions for the actual release, but for the testing phase, you'll want to build the code directly on your machine. The build process has been fixed so you should have an easy time with it. -------------- OSX users:Added a build for this version. |
|
|
|
I put into the 'Bitcoin Home Dir' field the location of another Bitcoin installation on an external drive (HD).
So you have 2 copies of the chain to begin with? |
|
|
|
Hi thanks for replying that fast. I'm impressed.
Just browsing the forums while I have my morning tea. Thank the tea. To get startet Again I created a new directory (g:\Armory1) and currently it is Building Again. Just to be sure - Is it still a demand to run BitcoinD and not BitcoinQT to make it Work?
You don't need a node to be running while you build & scan (this will lower the resource requirement during that phase). You need the node running afterwards to keep your chain up to date. The file is more that 64000 chr. I will paste the faulty part
Use pastebin next time. -ERROR - 1494766991: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters:
-ERROR - 1494766991: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash
-ERROR - 1494766991: (..\BlockchainScanner.cpp:1407) Skipping this block
-ERROR - 1494766991: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters:
-ERROR - 1494766991: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash
-ERROR - 1494766991: (..\BlockchainScanner.cpp:1407) Skipping this block
-ERROR - 1494766992: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters:
-ERROR - 1494766992: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash
-ERROR - 1494766992: (..\BlockchainScanner.cpp:1407) Skipping this block
-ERROR - 1494766992: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters:
-ERROR - 1494766992: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash
-ERROR - 1494766992: (..\BlockchainScanner.cpp:1407) Skipping this block
-ERROR - 1494766993: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters:
-ERROR - 1494766993: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash
-ERROR - 1494766993: (..\BlockchainScanner.cpp:1407) Skipping this block
-ERROR - 1494766993: (..\BlockchainScanner.cpp:1405) Block deser error while processing tx filters:
-ERROR - 1494766993: (..\BlockchainScanner.cpp:1406) raw data does not match expected block hash
-ERROR - 1494766993: (..\BlockchainScanner.cpp:1407) Skipping this block
This is an issue I think is fixed in 0.96.1. Wait for a few hours, I'll be releasing the testing builds sometimes tonight. Then rebuild your DB using that version. |
|
|
|
Just a short simple question.
Would it be possible to make in 0.96.1 in wallet properties when I click on balances, comments, tx count or addresses and so it would order them (highest, alphabetical, etc)? It doesn't seem to work right now and i'm searching my ass off when i look for a particular address or balance.
Thank You for considering
Will think about it. This folder exists, but it's empty
Why is it empty? Do you not run your node against that folder? |
|
|
|
edit/ I mean shouldn't those blk...dat files be regenerated by bitcoin core?
They should have been. Let me look at dbLog.txt. Also, are you building the db with DB_BARE? |
|
|
|
Would you need some log files from me?
I'd like to see dbLog.txt |
|
|
|
Don't I have to specify in the config files, that ArmoryQt has to use this custom BDM exclusively?
Client looks for a DB on localhost:9001. If there is one, it will use that instead of spawning its own. Because actually if a rebuild and rescan flag has een set, BDM should recognize it and so so, but it just doesn't.
The flag is given to the client. The client needs to spawn the DB itself to pass it the flag. In your case, you should spawn your DB with --rebuild, or wipe the /databases folder |
|
|
|
|
No, the uninstall just gets rid of installation files. It won't touch any user files.
|
|
|
|
|
Show Posts
