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. |
|
|
|
If I am not mistaken, then if [malicious pool hashrate] + [non-SW hashrate] >51% of the network hashrate, then the malicious pool can trivially execute a 51% attack.
The malicious pool could find a valid SW block (block "n", block height "x"), release the valid block with invalid signature data (but would retain valid signature data). The SW miners would think the block is invalid and ignore the block, while the non-SW miners would ignore the signature data and build on top of the block. If a non-SW miner find a valid non-SW block, then the non-SW miners and the malicious miner would build on top of this n+1 block, and the rest of the SW miners would be still building on top of the n - 1 block. If another SW miner were to find a valid block (block "b"), and release the block with valid signature data, then the SW miners (less the malicious SW miner) would build on top of block b, which has a height of x, however the rest of the network would be building on top of a block height of x+1. This would continue until the chain containing block n has some positive number of blocks greater than the chain containing block x, and the malicious SW miner would release the valid signature data for his block n, along with the blocks already on top of his chain, causing a re-org.
That shouldn't be possible. The chain split could happen, but not the re-org, I think. This is because the SW miners and nodes will have received the block with invalid signatures, saved it to disk, and marked it as invalid. It should remember that a block with the hash of the invalid block was invalid. Then when the malicious miner tries to broadcast it again with valid signature data, the SW miners and nodes will see the block, see that the block hash is that of one it marked invalid, and ignore the block. |
|
|
|
You will need to copy the blocks and chainstate folders.
Okay. Am i need to copy database folder? No. |
|
|
|
|
You will need to copy the blocks and chainstate folders.
|
|
|
|
now here is where i get confused. can we use a real example. lets take this transaction that i got from blockchain.info 010000000118d68350c1dcda804cc1cf5d9137fea5ea90a2ec3ffee63c47881b42043197d301000 0006b483045022100b4004f6cc5fe81527b62b090a9c5cf0343e8d7e0092b749f797a0363cd1f8b9d022 03440e3f4dc6dc29f095b0a93eccf66b3fd9ac88713695bd71dc8ee61cc89776a012103424bf6a8 1b8b327631f044e11f18eb8fc665288739c5e72377614d3e7580721bffffffff0240933402000000001976a9140177884fc893f5264be7e424781f7574c7b3a6b788ac4 d3ed118000000001976a9141595049c14d3b94e24069e33480f9d182c518fea88ac00000000 i have made the scriptsig into bold. i am assuming this is what you call "the witness" correct? No. The scriptsig and witness are two separate things. The data that goes in the witness is the data that would go in the scriptsig if a witness output were a normal p2pkh or p2sh output. In this example transaction, if the output it is spending from was a pay-to-witness-pubkey-hash (p2wpkh), then the data that is in the scriptsig would be found in the witness. However, since the output is p2pkh, the data currently in the scriptsig would remain where it is even after segwit activates. my confussion is about where is this "field" really located. is it still inside the transaction?
Yes. It is still part of the transaction. The transaction format has been extended for segwit. if so then how will it look and how is it different?
Suppose that the example transaction you posted were spending from a p2wpkh output instead of a p2pkh output. The transaction would look like this: 0100000000010118d68350c1dcda804cc1cf5d9137fea5ea90a2ec3ffee63c47881b42043197d3010000006b00ffffffff0240933402000000001976a9140177884fc893f5264be7e424781f7574c7b3a6b788ac4 d3ed118000000001976a9141595049c14d3b94e24069e33480f9d182c518fea88ac02483045022100b4004f6cc5fe81527b62b090a9c5cf0343e8d7e0092b749f797a0363cd1f8b9d0 2203440e3f4dc6dc29f095b0a93eccf66b3fd9ac88713695bd71dc8ee61cc89776a012103424bf6 a81b8b327631f044e11f18eb8fc665288739c5e72377614d3e7580721b00000000 I have bolded the parts that have changed. The scriptsig is now empty, and what was in the scriptsig is now placed after the outputs. That field after the outputs is the witness. There is also a 0x0001 after the version number which lets us know that there is a witness field after the outputs. and also by "not counted" do you mean it is not included in the 1 MB block if so how can you verify the transaction later on?
The data in the witness is not counted as part of the 1 MB block. The transaction is still verified as it normally would be since any node that can understand segwit will require that the transactions it receives are in the segwit serialization format. This means that it must receive the witnesses or the transaction will be considered invalid. The same goes with blocks; all transactions in a block that have witnesses must be in the segwit serialization format otherwise the block will be considered invalid. so how will the new blocks look like?
They will look like they do now, but transactions that have witnesses will be in the segwit serialization format. will they take a larger space on the whole blockchain
Yes. After segwit activates, the amount of space that a block can take up is 4 MB. sorry if the questions are too newbish. i recently started getting a better technical understanding of bitcoin and reading the bitcoin wiki, ... i can easily understand things but when it comes to segwit, everything becomes complicated probably because i have not found anything as well written as the wiki and also there is no examples helping me "visualize it" The BIPs contain all of this information with some examples too. Segwit is specified by BIPs 141, 143, and 144 |
|
|
|
So could it take less time, if I do a transaction just before a block is finished and my transaction is one of the last to take place in this block, right?
But if I am unlucky I make a transaction when the miner starts a new block so that have to wait till this block with my transaction is finished.
(In both scenarios I pay enough fee to be in the first block after transaction)
Yes. If there is no comparing, how do the miner validate the transaction? Why do they know that the transaction is legit?
All nodes (and miners are a subset of nodes) validate transactions according to the consensus rules. They check that the transactions that a transaction spends from exists in the blockchain. They also check that the transaction is allowed to spend the outputs that it is spending. Nodes will check that a transaction is not attempting to spend from a transaction which was already spent from before (i.e. a double spend). The blockchain has nothing to do with the validity or legitimacy of transactions (besides that all transactions in the blockchain must be valid). A transactions validity is determined by what outputs a transaction is spending from and whether it is allowed to spend those outputs. And if the blockchain is not for comparing or checking if the transactions are valid, for what is it then there?
The blockchain is for resolving double spends. When there are two or more transactions which spend from the same output, only one of them is allowed in the blockchain. The blockchain is for letting everyone on the network know which of those conflicting transactions is the "real" one. All of the conflicting transactions are valid transactions until one of them confirms. |
|
|
|
|
Post the debug.log file. The apple crash logs are meaningless and useless.
|
|
|
|
Open the terminal and go to the folder where the .deb file is downlaoded. Then run where <filename> is the filename of the Armory .deb file. |
|
|
|
|
Show Posts
