Bitcoin Forum
June 29, 2024, 10:58:29 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 [120] 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 ... 233 »
2381  Bitcoin / Armory / Re: Extremely long engine initialization, v 0.95.1 on: November 25, 2016, 08:35:57 AM
Armory's db is matched to the copy of the blockchain it was built upon. You cannot split the 2. This means in your case you should rebuild your DB from scratch.
2382  Bitcoin / Armory / Re: Having Trouble sending Coins in Armory 0.95.1 on: November 25, 2016, 01:29:25 AM
Yes
2383  Bitcoin / Armory / Re: Having Trouble sending Coins in Armory 0.95.1 on: November 24, 2016, 02:10:31 PM
The test transaction actually took all fund from the test wallet sooo the fee was taken from the bugged address. Strange huh?

This is why you should try the DB_BARE mode.
2384  Bitcoin / Armory / Re: Having Trouble sending Coins in Armory 0.95.1 on: November 24, 2016, 01:09:53 PM
First, create a new folder and rebuild the DB in there with --db-type=DB_BARE, then try to spend your coins from that DB.

If that fails, the trouble shooting is gonna get a whole lot more complicated.

The simplest solution I can offer is for you to send me a watching only copy of your wallet for me to work on directly. That will come at the cost of your privacy though.

You also have the option to wait for 0.96 and the new signer code, which may or may not fix that issue.
2385  Bitcoin / Armory / Re: ArmoryDB in Dos Prompt every startup on: November 24, 2016, 04:55:37 AM
That's to convey the change in paradigm. I plan to hide it in the next version.
2386  Bitcoin / Armory / Re: Loading Armory takes like forever on: November 24, 2016, 01:43:54 AM
Ok, thanks all for your patience.
I somehow understand that my system is not the most powerful in the world, but hey... It is taking some time now, don't you think so?

Not really. The blockchain is bordering 90GB. With the amount of processing required for Core to verify the chain and Armory to parse it, we are in big data territory. Fitting that load on a home hardware is the tough part.

If you think you ought to get a smooth experience trying to setup a full bitcoin stack on what amounts to decade old low end consumer hardware, you need to reassess your expectations.

Quote
Just a question : does armoryDB allows the use of 2 options at a time ?
ie : --ram-usage=1   and --db-type=DB_BARE
What would be the correct format ? just a space between both options or something mixed like --ram-usage=1; db-type=DB_BARE ?

You can use any non contradictory combination of command line arguments. The specific command you want here is:

a) On Windows, browse to the executable path (in /program files x86/Armory by default), and type the following:

ArmoryDB.exe --db-type=DB_BARE --ram-usage=1

DB_BARE only works on an empty database folder, so you'll have to wipe your current DB, or use another folder.

b) On *nix, in the terminal, input the following:

ArmoryDB --db-type=DB_BARE --ram-usage=1

Quote
Is there any option to restore my BitCoins to another wallet once I have the keylists ?

What about the use of the bitcoin core wallet in combination with paper wallets to store BTC?
Basically I just want to have some control on my BTC mining revenue.
If I send this to a paper wallet with no other step in between I have no chance to check if there's something wrong while transferring

There are plenty of options as long as you have your private keys in hand. It mostly boils down to user choice. This isn't really the place to discuss these options and what they entail to. It boils down to this:

Any solution that runs off of a full bitcoin node requires a lot of bandwidth, storage and processing power to maintain. With that cost, you buy a full bitcoin experience.

Any solution that does not require a full node will have you give up a set of properties, first among which is your privacy.
2387  Bitcoin / Armory / Re: Having Trouble sending Coins in Armory 0.95.1 on: November 24, 2016, 12:31:01 AM
Does this always happen with the same wallet? For whatever reason some of the outpoints are empty. Use the coin control feature to try and isolate the culprits and report here.
2388  Bitcoin / Armory / Re: Loading Armory takes like forever on: November 24, 2016, 12:24:55 AM
You are going to have to mix option 2 & 3
2389  Bitcoin / Armory / Re: Extremely long engine initialization, v 0.95.1 on: November 22, 2016, 12:26:28 PM
I believe at this point you should take the discussion to Core specialists. I'm not too sure what is the bast place to get that info, I only know of the dev channels personally. If anything, a post in D&TD or Technical Support will put you on the right path:

https://bitcointalk.org/index.php?board=6.0

https://bitcointalk.org/index.php?board=4.0
2390  Bitcoin / Armory / Re: Extremely long engine initialization, v 0.95.1 on: November 22, 2016, 11:45:17 AM
Then you should consider finding a list of strong well known nodes (explorers, miners, high speed ones) and add them to your bitcoin.conf by IP just to finish bootstrapping.
2391  Bitcoin / Armory / Re: Loading Armory takes like forever on: November 22, 2016, 11:36:47 AM
You have a few choices:

1) Let it complete the tx hash scan. This is the last step of the original build & scan.

2) If it seems like it can't pass that stage, delete your DB and rebuild it with --db-type=DB_BARE to skip that part of the scan entirely.

3) If your RAM is still the bottleneck, you can shutdown the bitcoin node while the DB is going through its initial build & scan. That should free enough resources to get through the though part.
2392  Bitcoin / Armory / Re: Extremely long engine initialization, v 0.95.1 on: November 22, 2016, 11:31:57 AM
Code:
2016-11-16 03:17 (INFO) -- ArmoryUtils.pyc:1263 -    Total Available RAM   : 7.89 GB
2016-11-16 03:17 (INFO) -- ArmoryUtils.pyc:1264 -    CPU ID string         : Intel64 Family 6 Model 42 Stepping 7, GenuineIntel
2016-11-16 03:17 (INFO) -- ArmoryUtils.pyc:1265 -    Number of CPU cores   : 8 cores
2016-11-16 03:17 (INFO) -- ArmoryUtils.pyc:1266 -    System is 64-bit      : True
2016-11-16 03:17 (INFO) -- ArmoryUtils.pyc:1267 -    Preferred Encoding    : cp1250
2016-11-16 03:17 (INFO) -- ArmoryUtils.pyc:1268 -    Machine Arch          : amd64
2016-11-16 03:17 (INFO) -- ArmoryUtils.pyc:1269 -    Available HDD (ARM)   : 87 GB
2016-11-16 03:17 (INFO) -- ArmoryUtils.pyc:1270 -    Available HDD (BTC)   : 87 GB

That's a decent CPU. The drive size suggests SSD. I'm guessing the machine isn't the issue. Could be you are getting connected a lot of weak/bad nodes.

You should consider actively managing your connections. I'd ban any node that:

- has >500 ms ping
- is not Core
- has a version number <10.0
2393  Bitcoin / Armory / Re: Loading Armory takes like forever on: November 22, 2016, 01:14:25 AM
You basically have too little RAM to let ArmoryDB run with defaults. You need to run Armory with --ram-usage=1.

You also need to get rid of your 0.93 DB, or point Armory to a fresh db folder using the --dbdir="somenewpath" cli arg.
2394  Bitcoin / Armory / Re: Loading Armory takes like forever on: November 22, 2016, 12:48:51 AM
Post your log files.
2395  Bitcoin / Armory / Re: Armory Stuck after Factory Reset on: November 21, 2016, 11:40:40 PM
1) Yes

2) Yes

3) It does not matter how long after you start ArmoryQt as long as ArmoryDB was spawned first. ArmoryDB.exe is what you are looking for.

4) Open the command line prompt, browse to your Armory installation folder, run the following:

ArmoryDB.exe --ram-usage=1
2396  Bitcoin / Armory / Re: Armory Stuck after Factory Reset on: November 21, 2016, 11:05:28 PM
1) Delete /databases

2) Run ArmoryDB alone with --ram-usage=1

3) Start ArmoryQt

Get back to me if it fails.
2397  Bitcoin / Armory / Re: Armory Stuck after Factory Reset on: November 21, 2016, 09:32:33 PM
That was the first suggestion which I have tried and still get the errors posted in the log above.

Bitcoind runs fine itself and is fully up to date before I start armory.

This is not what your log file suggests:

Code:
2016-11-17 12:26 (INFO) -- SDM.pyc:460 - Called startBitcoind
2016-11-17 12:26 (INFO) -- ArmoryUtils.pyc:651 - Executing popen: ['C:\\Program Files\\Bitcoin\\daemon\\bitcoind.exe', u'-datadir=C:\\Users\\John\\AppData\\Roaming\\Bitcoin\\']
2016-11-17 12:26 (INFO) -- SDM.pyc:574 - PID of bitcoind: 29000
2016-11-17 12:26 (INFO) -- SDM.pyc:575 - PID of armory:   24552
2016-11-17 12:26 (INFO) -- ArmoryUtils.pyc:651 - Executing popen: ['.\\guardian.exe', '24552', '29000']
2016-11-17 12:26 (INFO) -- SDM.pyc:756 - Creating proxy in SDM: host=127.0.0.1, port=8332
2016-11-17 12:26 (INFO) -- ArmoryQt.py:5542 - Dashboard switched to auto-InitSync
2398  Bitcoin / Armory / Re: Armory Stuck after Factory Reset on: November 21, 2016, 08:16:36 PM
Turn off auto bitcoind, run Core manually.

2399  Bitcoin / Armory / Re: Extremely long engine initialization, v 0.95.1 on: November 18, 2016, 10:56:57 PM
The log file does not show any evidence of that, so something is failing either way. Try these settings and let me know.
2400  Bitcoin / Armory / Re: Extremely long engine initialization, v 0.95.1 on: November 18, 2016, 09:09:27 PM
Quote
However, the new bitcoind path is apparently working as the blocks files are saved into the new directory etc.

Code:
-WARN  - 1448972888: (..\BlockUtils.cpp:1140) Scanning from 386224 to 386224

I was referring to Armory not seeing that at all.
Pages: « 1 ... 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 [120] 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 ... 233 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!