Bitcoin.org does not distribute binaries without wallet functionality. Are you absolutely sure that you got this from bitcoin.org? Can you try downloading and installing the latest version from bitcoin.org? |
|
|
|
How I can fix this?
How did you install bitcoind? Did you compile it yourself? Or did you download it from bitcoin.org? Or was it built by someone else and given to you? |
|
|
|
I don't know anything, Password is totally vanished from my brain.
Then no wallet recovery tool or service will be able to help you unless you used a very weak password. Without any idea what your password is, it is extremely unlikely that you can recover it. |
|
|
|
$ bitcoin-cli getinfo
{
"version": 130200,
"protocolversion": 70015,
"blocks": 474554,
"timeoffset": 0,
"connections": 13,
"proxy": "",
"difficulty": 708659466230.332,
"testnet": false,
"relayfee": 0.00001000,
"errors": ""
} Your install of bitcoind does not have wallet functionality compiled into it. Thus none of the wallet RPC commands will work, and this includes getaddressbyaccount |
|
|
|
Am i need to copy these files > CURRENT, LOCK, LOG, LOG.old, MANIFEST-304323 that are located in chainstate folde?
Yes. The entirety of the blocks and chainstate folders must be copied. This includes any and all contents. |
|
|
|
Sorry, forget about the "GUI not appearing", obviously I was running the wrong command. Anyway, now the GUI appears but it still seems to be unable to sync (stuck at "Scanning Transaction History"): gaglia@mydomain:~$ armory
Gtk-Message: Failed to load module "canberra-gtk-module"
/home/gaglia
(ERROR) ArmoryUtils.py:3747 - Unsupported language specified. Defaulting to English (en)
/usr/lib/armory/armoryengine/Transaction.py:2790: SyntaxWarning: import * only allowed at module level
def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals):
(WARNING) SDM.py:403 - Spawning DB with command:ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/home/gaglia/.bitcoin/" --datadir="/home/gaglia/.armory/" --dbdir="/home/gaglia/.armory/databases"
(ERROR) ArmoryQt.py:1194 - 3 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:1199 - File mempool.bin does not exist. Nothing deleted.
(python2:14420): Gtk-CRITICAL **: IA__gtk_progress_configure: assertion 'value >= min && value <= max' failed
Can you post the armorylog.txt and dbLog.tst files from after you run it again and see the problem? |
|
|
|
Does that mean if you whitelist Core wallet in your antivirus program, you leave your Core wallet open to virus? If so, what is the answer?
AVG quarantined my wallet and I had to whitelist it to get back into it.
No. None of the data in the blockchain is ever executed, so even if there is a virus there, it cannot do anything to Core nor anything to your computer as it is never actually run. |
|
|
|
|
Mining used to be such that everyone who ran a node could mine. However the difficulty has significantly increased since those times and made it extremely uneconomical for people with just nodes to mine. They would be using their CPUs or GPUs to mine, and with the current difficulty, the probability that someone CPU or GPU mining will find a block is extremely low. As such, the return on that is very low and does not offset the cost of electricity, so people no longer CPU and GPU mine. You can still do so if you want to, you just won't find any blocks or make any money if you are mining with a pool.
The number of miners or the decentralization of mining has nothing to do with how quickly transactions are "processed" (I assume you mean confirmed when you say "processed"). The protocol adjusts the difficulty (aka amount of work required to mine a block) so that blocks are produced every ten minutes, on average. This is the same regardless of whether everyone with a node is CPU mining and difficulty is low or whether all miners use ASICs in large data centers.
|
|
|
|
|
Your transaction spends from a very long chain of unconfirmed transactions. Your transaction cannot confirm until the transactions that it spends from confirm as well. However this may take a while and the transactions may also simply never confirm.
|
|
|
|
|
Inbound connections are only made after nodes know about your node and attempt to make a connection to it. You shouldn't expect to get many (or any) inbound connections until your node has been up for a few days. It takes time for nodes to learn about your node and for the DNS seeder to learn about your node and decide that it is worthy of being given to other nodes for connections.
The bitnodes.21.co node is just a crawler and it makes temporary connections to see if your node is up. It isn't an actual nodes and other nodes don't use them to get nodes to connect to.
|
|
|
|
Put the directory in the exclude from scanning option. Virus scanners look for "signatures" including some BTC addresses and the block chain will at some point also contain random sequence of characters that will inadvertently trigger it.
It's actually not because of randomness. People have been intentionally embedding viruses (or their signatures) in the blockchain so that antivirus software are triggered. |
|
|
|
|
The walletrbf=1 option sets RBF for transactions made by the wallet. Createrawtransaction is not part of the wallet, so this option doesn't affect it. In createrawtransaction, there's an optional sequence field that you can set when specifying the inputs. To set a transaction to Opt into RBF, you need to set the sequence for at least one input to be 4294967293 or lower.
|
|
|
|
|
Do you have a log from a time that you saw this issue?
Also, it looks like you might have some corrupted blocks on disk as the dbLog.txt says that there is a merkle root mismatch. The only fix for corrupted blocks is to re-sync the entire blockchain.
|
|
|
|
Can you please post your log files? What version of Armory are you using? What version of Bitcoin Core? Why is my armory not 100% robust and flawless in scanning database when I load it?
Because all software has bugs and Armory doesn't have a lot of developers. There are only 3 developers that actively work on Armory, and only one does so full time. This means that there is a lack of testing and review so bugs usually slip through into releases. |
|
|
|
|
It sounds like you have a text file with base64 encoded data inside of it. Unfortunately I don't know of any wallets that make backups with Base 64 encoded data. Do you have any idea what wallet you used in 2013 that may have produced such a backup? I don't think Bitcoin Core will make such backups.
|
|
|
|
Thanks for the summary. I was specifically wondering about a comparison of the electricity usage of an Obelisk from Sia ( https://obelisk.tech) versus just running a computer all day (not even for mining). Is it 10x the usage or a 100x? Just wondering about an order of magnitude. In general ASIC miners draw probably 2 to 3 times more power than your normal desktop (1600 watt ASIC PSUs vs 500 watt desktop PSUs). However an ASIC can mine thousands of times faster than a desktop can. For example, the Antminer S9 has a 1600 watt PSU and mines at 13.5 TH/s while a super high end desktop with multiple GPUs might be able to pull off a few GH/s at best. |
|
|
|
The attack actually requires the hashrate of the malicious pool plus the hashrate of non-SW miners to be 51%. So, for example, if the malicious miner has 20%, then non-SW miners would need to have at least 31% for this attack to work.
But in order for segwit to even activate, 95% of the hashrate has to be signalling for segwit. SW could potentially activate with significantly less than 95% of miners supporting (and more importantly enforcing SW -- it is not clear that miners currently signaling for SW will enforce SW upon it's activation) SW via BIP 148.
If BIP 148 activates, then 100% of miners on the BIP 148 chain will, at the very least, be signalling for segwit. All miners who aren't will be forked off of the BIP 148 chain. Even if SW were to activate upon receiving 95% signaling, it's controversy will likely result in there always be a market for non-SW mining, and this market could potentially grow upon the activation of SW. Miners may signal SW "today" under the threat of a POW change, and return to non-SW mining once it activates.
Why? There's no logic in not mining SW if you were already supporting it after it activates. A miner would be losing money if they didn't support segwit. Also, why would there be a market for non segwit mining? Segwit being active doesn't preclude non-segwit transactions from being included in blocks. For those who don't support segwit at all and don't want it activated, then they would be using another chain entirely which is not a problem for the chain with segwit activated. Also, another thing to note is that stuff like Compact Blocks and XThin blocks would help to mitigate such an attack. Since many of the transactions in the block will already be known to nodes, nodes will know about the transactions already so they already have the witnesses and don't need to get the transactions from the block. They will just rebuild the block using the transactions from their mempool which will have the witnesses so they will recognize that the block is valid. |
|
|
|
Are you sure about it?
Assume you are pool admin. You see a block in old format height "x". You saw such blocks
a day ago, and you know that the valid block with the same header will come to you
in a couple of seconds. Why not to start mining empty block on top with height "x+1"?
Unless humans are actively monitoring their pool and watching what blocks are received, what blocks are mined, whether their node is accepting or rejecting some blocks, etc., that won't happen. In order for such a thing to happen, humans must be involved, and I would surprised if pool operators are actually that attentive to that sort of information. No  There was no infrastructure in past which was able to broadcast blocks with valid headers (suitable to mine on top of them) and invalid data (not suitable to insert into blockchain) faster than bitcoin network. Now we have such infrastructure How so? We have had the infrastructure to broadcast headers only since 0.10.0. You can broadcast a block with invalid data for every soft fork Bitcoin has ever had (assuming you send a valid header first). For every single soft fork that Bitcoin has had, post fork you could always create a block which non-upgraded nodes would accept but upgraded ones wouldn't. This didn't apply for when headers first didn't exist, but headers first broadcasting has existed for the OP_CLTV and OP_CSV soft forks. With these soft forks (and all previous ones), you could create a block which has a valid header and invalid data (include an invalid transaction), and with headers first, performed the attack described by Quickseller. There's nothing different or special about segwit that allows this. In fact, with segwit, the impact of such an attack is slightly reduced (very slightly). With segwit, the block is actually invalidated before being written to the disk (because the witness commitment wouldn't match). With all other soft forks, the block would be invalidated after being written to disk when transactions are being validated. |
|
|
|
To me, that sounds even worse. It would mean that miners, and nodes (and new of the same) would slowly move to an entirely new chain as they restart (or come online for the first time). It would also change consensus rules because nodes would be rejecting valid blocks. It would also create an attack vector (similar to malleability, but IMO worse), in which a (network of) well connected node(s) could listen for valid SW blocks, and quickly rebroadcast them with invalid signature data, causing SW miners and nodes to reject these valid blocks.
But this attack assumes that there are 51% of miners who are not enforcing segwit. This is one reason why there's an activation threshold that requires 95% of the hashrate to signal that they are enforcing the segwit rules. Also, such an attack is possible for any soft fork, not just segwit. But again, that is why soft forks still require 95% to activate. |
|
|
|
|
Show Posts
