|
The forum occasionally is under a DDoS attack. This just disrupts service and does not actually affect your account.
|
|
|
|
install that very old version of the wallet again.and transfer those coins into new address. or try to take linux help because these types of problems generally occurs into window.
Please don't post when you don't know what you are talking about. The old versions of Bitcoin-qt are no longer available. This is not a problem limited to any OS because the wallet format has changed.
Op, try starting Bitcoin Core with the -upgradewallet option. See http://www.achow101.com/2016/07/Bitcoin-Core-Troubleshooting#option-startup for help on that. |
|
|
|
why is now bctalkaccountpricer can't use again
when is problem is fix and can use again
Should be working now. I also removed all old requests so if you need one, pm me. |
|
|
|
|
Eh. Why not?
16mT7jrpkjnJBD7a3TM2awyxHub58H6r6Z
|
|
|
|
|
There would certainly be a great deal of changes, but since I have not studied Litecoin (nor have any interest), I don't know the specifics. I don't think anyone working on Armory right now is interested in adapting it for altcoins.
At a minimum, there would need to be changes to the hashing algorithms for verifying blocks as Litecoin uses Scrypt and not SHA256d. The genesis block, magic bytes, and other blockchain parameters would also have to be changed as well.
|
|
|
|
The Genesis block isn't a block that you can request, it is hard coded into the software and never enters the database. Try a different block.
I test a different hash, but the node don't reply. not only "getheaders" message, I send "getaddr" message, the node don't reply. the node only reply "version" message. i found after i send "version" message, i will recieve "version" ,"verack", "inv"......"inv", "addr" message, sometimes, i will recieve "version" ,"verack","ping", "addr" message. then, i send any type message, the node don't reply. Did you complete the handshake; it seems that you did not. You first send the version message. Then you wait for both a verack from the node and the node's version message. Then you send a verack to the node. And then you can send your other messages. |
|
|
|
|
The Genesis block isn't a block that you can request, it is hard coded into the software and never enters the database. Try a different block.
|
|
|
|
|
No. They would end up overwriting each other and be extremely confused when something changes to the files that it didn't add. There is also a lockfile used to prevent this from happening.
|
|
|
|
Qt started spamming this -ERROR - 1470184862: (SocketObject.cpp:272) readFromSocketThread poll returned POLLNVAL, errnum: 0, errmsg: Success
Then it hung with this -ERROR - 1470184862: (SocketObject.cpp:139) POLLNVAL in writeToSocket
And then I had to kill it. The db had this error message -ERROR - 1470184739: (BDM_Server.cpp:637) caught isEmpty in Clients maintenance loop
Also, trying to view any transaction that I received gets me Traceback (most recent call last):
File "ArmoryQt.py", line 3626, in dblClickLedger
self.showLedgerTx()
File "ArmoryQt.py", line 3649, in showLedgerTx
DlgDispTxInfo( pytx, self.walletMap[wltID], self, self, txtime=txtime).exec_()
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5667, in __init__
self.data = extractTxInfo(pytx, txtime)
File "/home/andy/bitcoin/BitcoinArmory/qtdialogs.py", line 5594, in extractTxInfo
prevTx = TheBDM.bdv().getTxByHash(prevTxHash)
File "/home/andy/bitcoin/BitcoinArmory/CppBlockUtils.py", line 1276, in getTxByHash
def getTxByHash(self, *args): return _CppBlockUtils.BlockDataViewer_getTxByHash(self, *args)
RuntimeError
I think some transactions didn't make it into the db. |
|
|
|
I'm new to this, what happened? I know that after the transaction I had the balance showing in my wallet that now appears at the address starting with 1Mz
It's called a change address. Armory does not reuse addresses, as is recommended. So, when you spend from an address, you will have change, much like when using cash bills, you will have change. The change has to go somewhere, so the wallet sends it to a change address. It is still an address in your wallet so you still have those Bitcoins. Also in armory, I've restored my wallet but these transactions are not in my ledger.
Look at my post right above yours. log files
I don't think those are necessary. I'm 99% sure that they just have to generate more addresses. |
|
|
|
So I decided to go with Coinbase. It seems to have the biggest following. Seems like a pretty legit company. I uhh, feel more safe with my coins here then in my exchange. There software is very user friendly, and even I figured it out on my own. The desktop wallets requiring me to downloading the entire blockchain, is a little too high tech for me. Not to mention, they have live chat which was very useful.
I wouldn't recommend Coinbase (or any web wallet for that matter). Others have had issues in the past with Coinbase, particularly with Coinbase just closing accounts based upon your transaction history and where you are sending and receiving your Bitcoin from. Desktop wallets aren't that "high tech". All of them are just plug-and-play; install the software and run. Most will have detailed instructions and wizard stuff to guide you through the setup process. You can also use a wallet like Electrum which does not require you to download the entire blockchain. Now on to the ETC mess..... not sure exactly how to move that into a safe wallet.
Any suggestions?
With the markets today, I'm actually following the trend and dumping ETH and buying ETC.. hopefully I won't get hammered too hard.
Install both ETH and ETC wallets. Then just withdraw one of the cons. Check to see if you receive both ETH and ETC even though you only withdrew one coin. If you did, that's a problem. If not, that's great. Then withdraw the other coin and check again. If you do not receive both ETH and ETC for the withdrawal of one of the coins, then you are safe. Otherwise, you will need to be very careful when spending in order to not accidentally spend both coins when you only meant to spend one. Of course, if you do happen to receive both ETH and ETC on one withdraw, you could try to make a profit off of that by selling the other coin, but you could run into some issues. |
|
|
|
delete the content of your databases folder and try again
Then its back to the problem earlier where the DB crashes when Qt starts Let's go to IRC |
|
|
|
show me the log output too
-INFO - 1470159382: (main.cpp:24) Running on 8 threads
-INFO - 1470159382: (main.cpp:25) Ram usage level: 4
-INFO - 1470159382: (BlockUtils.cpp:1247) blkfile dir: /media/andy/Data/Programs/Bitcoin/data
-INFO - 1470159382: (BlockUtils.cpp:1248) lmdb dir: /media/andy/Data/Data/bitcoin/ArmoryData/databases
-INFO - 1470159382: (lmdb_wrapper.cpp:389) Opening databases...
-INFO - 1470159382: (BlockUtils.cpp:1447) Executing: doInitialSyncOnLoad_Rescan
-INFO - 1470159382: (BitcoinP2P.cpp:725) Connected to Bitcoin node
-INFO - 1470159382: (lmdb_wrapper.cpp:389) Opening databases...
-INFO - 1470159382: (DatabaseBuilder.cpp:166) Reading headers from db
-WARN - 1470159382: (lmdb_wrapper.cpp:1203) No headers in DB yet!
-INFO - 1470159382: (DatabaseBuilder.cpp:199) Found 1 headers in db
-INFO - 1470159382: (DatabaseBuilder.cpp:49) updating HEADERS db
-DEBUG - 1470159382: (Blockchain.cpp:232) Organizing chain
-INFO - 1470159382: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.000394s
-INFO - 1470159382: (DatabaseBuilder.cpp:103) scanning new blocks from #0 to #0
|
|
|
|
Current top is 423333. Check your top block on Core first
Top block on core is right. Top block on armory is not. Time for rebuild & rescan. It segfaults. I'll get a backtrace in a moment. Well that's not very helpful: (gdb) bt
#0 0x000000000044095e in ?? ()
#1 0x0000000000000000 in ?? ()
|
|
|
|
Current top is 423333. Check your top block on Core first
Top block on core is right. Top block on armory is not. |
|
|
|
DB isn't outputting any error. I'm assuming it is running just fine. You saying the clients isn't displaying the proper top block?
Yes. I think that these two lines: -INFO - 1470145634: (DatabaseBuilder.cpp:199) Found 422936 headers in db
...
-INFO - 1470145637: (DatabaseBuilder.cpp:103) scanning new blocks from #422824 to #422823 Are a bit concerning. The latest top when I ran it was 423... and it is only scanning from 422823 to 422824. |
|
|
|
You can attempt a Child-Pays-For-Parent transaction. Make a transaction that spends from this unconfirmed one. Make sure that you set the fee of that transaction to one that is sufficiently high to cover both this unconfirmed transaction and your CPFP transaction, and then add a little on top of that. You can use https://bitcoinfees.21.co/ to help you calculate a good fee. |
|
|
|
Start db individually, does it catch up?
No it does not catch up. Log file plz dbLog.txt latest run:
Log file opened at 1470145631: /media/andy/Data/Data/bitcoin/ArmoryData/dbLog.txt
-INFO - 1470145631: (main.cpp:24) Running on 8 threads
-INFO - 1470145631: (main.cpp:25) Ram usage level: 4
-INFO - 1470145631: (BlockUtils.cpp:1247) blkfile dir: /media/andy/Data/Programs/Bitcoin/data
-INFO - 1470145631: (BlockUtils.cpp:1248) lmdb dir: /media/andy/Data/Data/bitcoin/ArmoryData/databases
-INFO - 1470145631: (lmdb_wrapper.cpp:389) Opening databases...
-INFO - 1470145631: (BlockUtils.cpp:1438) Executing: doInitialSyncOnLoad
-INFO - 1470145631: (DatabaseBuilder.cpp:166) Reading headers from db
-INFO - 1470145631: (BitcoinP2P.cpp:725) Connected to Bitcoin node
-INFO - 1470145634: (DatabaseBuilder.cpp:199) Found 422936 headers in db
-INFO - 1470145637: (DatabaseBuilder.cpp:49) updating HEADERS db
-DEBUG - 1470145637: (Blockchain.cpp:232) Organizing chain
-INFO - 1470145637: (DatabaseBuilder.cpp:53) updated HEADERS db in 0.059381s
-INFO - 1470145637: (DatabaseBuilder.cpp:103) scanning new blocks from #422824 to #422823
-INFO - 1470145637: (BlockchainScanner.cpp:51) no history to scan
-INFO - 1470145637: (BlockchainScanner.cpp:802) no SSH to scan
-INFO - 1470145637: (DatabaseBuilder.cpp:153) scanned new blocks in 0.000986s
-INFO - 1470145637: (DatabaseBuilder.cpp:157) init db in 5.32062s
-INFO - 1470145637: (BlockUtils.cpp:1549) Enabling zero-conf tracking
-INFO - 1470145689: (BDM_Server.cpp:573) registered bdv: 893de640c6ee895d17ff
-INFO - 1470145736: (BDM_Server.cpp:604) unregistered bdv: 893de640c6ee895d17ff
|
|
|
|
Start db individually, does it catch up?
No it does not catch up. |
|
|
|
|
In what way does it not start? Does something pop up? Is there an error message? Does the window appear and then quickly disappear? Or does nothing happen when you try to start it?
|
|
|
|
|
Show Posts
