|
The transaction fee is too low. Unfortunately you decided to use blockchain.info's wallet so there is not anything that can be done about.
|
|
|
|
Non segwit minority miners must still build on top of the longest chain that the rest of the network considers valid. Do you agree or disagree?
Yes, I agree. What are you trying to argue? |
|
|
|
Yes, because "blocks that you consider to be valid but which every segwit-enforcing node rejects"
will be orphaned as the longest chain prevails.
No, unmodified non-segwit miners will be producing valid blocks and their blocks will still be accepted. Segwit transactions are considered by non-segwit nodes as being non-standard. An unmodified non-segwit miner means that they have not changed any of the local node policy rules, which include the standardness rules. As long as they are following the standardness rules, they will not be mining segwit transactions and thus their blocks will not be invalid. These miners will not have their blocks orphaned unless they mine a segwit transaction, but that will only happen if they modify their standardness rules. You're not making sense. If blocks are rejected (per bitcoincore.org) then either they get orphaned, or there's a split. Their blocks only get rejected if and only if they include a segwit transaction, but they also consider segwit transactions to be non-standard so they won't include such transactions thus their blocks won't be rejected. |
|
|
|
Yes, because "blocks that you consider to be valid but which every segwit-enforcing node rejects"
will be orphaned as the longest chain prevails.
No, unmodified non-segwit miners will be producing valid blocks and their blocks will still be accepted. Segwit transactions are considered by non-segwit nodes as being non-standard. An unmodified non-segwit miner means that they have not changed any of the local node policy rules, which include the standardness rules. As long as they are following the standardness rules, they will not be mining segwit transactions and thus their blocks will not be invalid. These miners will not have their blocks orphaned unless they mine a segwit transaction, but that will only happen if they modify their standardness rules. |
|
|
|
2017-04-17 14:47:45 connect() to [2001:0:9d38:90d7:18cb:8a6:cb53:4418]:8333 failed: Network is unreachable (101) Well, there's your problem. No version of Bitcoin supports the packet-over-air protocol. Your node is stalling because your Internet connection keeps dropping out; it's nothing to do with your peers. No, that error is probably because their ISP does not give them IPv6 access. As you can see from the rest of the log, the node is clearly connected to other nodes and is receiving data. OP, the section of the log you posted contains benign errors unrelated to your node and is completely useless. If you want more help, please post your machine specs and the entire debug.log. |
|
|
|
I run newest bitcoin core, where i can find segwit partition?  There is no "segwit partition". What exactly are you trying to do? By running the latest version of Bitcoin Core, when segwit activates, your node will automatically switch to segwit rules. |
|
|
|
|
Make sure that your godaddy server allows outgoing connections to whatever rpcport you are using.
|
|
|
|
|
Download and install Bitcoin Core 0.13.1+ from bitcoin.org. The current version is 0.14.0 and that version also has segwit signalling and handling code in it.
Run Bitcoin Core.
Done.
|
|
|
|
I see. So both segwit and btu fork is not active yet. Thanks for the information
Anyhow regarding on either we will have btc or btu, is there a particular date where a decision will be made?
If yes, who made the decision on whether we will be going for btc, btu or even both?
Thanks
No, there is no entity or central group of people that decides whether we use one proposal or another. The closest thing we have to that are miners, but the miners are not a cohesive group of people. There is no date or deadline for one proposal to activate. |
|
|
|
I have been downloading coin wallets for 4 years and have downloaded many dozens of wallets and tested lots in virustotal and elsewhere.
I am highly suspicious that two different versions of bitcoind would come bundled in two installs at the same time from bitcoin.org, one testing hot the other not.
It tested bad on a specific trojan, not on heuristics. Something is not right.
Some people who are strongly anti-core have submitted some binaries of Core to antivirus vendors to list them as viruses in order to discourage people from using Core. Since they probably don't want to go through the effort of installing Core and then uninstalling it, they probably just used the binaries from the zip files. Because the binaries from the zip files are different from the ones in the installer due to NSIS, those are the ones that are flagged as viruses and not the ones in the installer. If you still think that it is a virus, you can check that it is not for yourself. Checkout the 0.14.0 source code and examine it for yourself that there is no virus in there. Then perform the same gitian deterministic build process and release process for yourself and see if the output matches. The way that gitian works is that it will always produce the same exact binaries for the same exact code (normally the binaries will differ even with the same code due to timestamps and other sources of non-determinism). If it matches, then there is no virus. If it does not match, then either you have done something wrong, or the binaries on bitcoin.org are not legitimate. However, that is likely not the case as the hashes of those on bitcoin.org matches the hashes built by the multiple independent gitian builders. |
|
|
|
is the blockchain already splitted?
As i can see the BTU Coins in coinmarketcap
No. No fork has happened yet. The BTU coins you see are not actual coins but rather promises of future BTU coins after a BU hard fork. |
|
|
|
My advice is that you fully verify that the binary is legitimate by downloading the SHA256SUMS.asc file, verifying the GPG signature with Wladimir's release key, and then check that the sha256 of the binary package you download matches what is in the SHA256SUMS.asc. If that all matches and verifies, then yes, ignore the antivirus and tell it that it is a false positive. This is not a new issue. This has happened for all versions of Bitcoin Core. Antivirus software will always flag Bitcoin Core as a virus, especially with new versions since people haven't reported the false positive for the new version yet. How many times do I need to repeat myself? If you fully verify that the download is legitimate, then the antivirus is wrong and it is a false positive. I have already stated why antivirus software do this. |
|
|
|
How can I do that if I'm not connecting to any peers? I tried the connection check that one uses when first installing to check node connectivity and it appears I now have none. This is odd as it's the same machine, and the same router.
Reindexing does not require any connections. Often times when people are unable to connect to the network, it is due to something corrupted in the database or in the blockchain data itself that prevents it from getting connections (i.e. disconnected by peers for bad data or something like that). Reindexing usually fixes it. Otherwise deleting the blockchain data lets your node restart completely from scratch. I can't see how it would need to be set up again. I've got some interesting new errors in the logs too;
2017-04-17 13:02:36 ProcessMessages(sendcmpct, 5 bytes) FAILED peer=27
2017-04-17 13:02:36 ProcessMessages(sendcmpct, 5 bytes): Exception 'CDataStream::read(): end of data' caught, normally caused by a message being shorter than its stated length
2017-04-17 13:02:36 ProcessMessages(sendcmpct, 5 bytes) FAILED peer=27
2017-04-17 13:02:52 ProcessMessages(version, 100 bytes) FAILED peer=28
2017-04-17 13:07:04 receive version message: /Snoopy:0.2.1/: version 70001, blocks=0, us=[2001:0:4137:9e76:3420:2fda:ae92:dc1e]:8333, peer=29
2017-04-17 13:10:27 GUI: OpenType support missing for script 11
2017-04-17 13:10:27 GUI: OpenType support missing for script 11
2017-04-17 13:10:27 GUI: OpenType support missing for script 11
2017-04-17 13:10:27 GUI: OpenType support missing for script 11
2017-04-17 13:10:27 GUI: OpenType support missing for script 16
2017-04-17 13:10:27 GUI: OpenType support missing for script 16
2017-04-17 13:10:27 GUI: OpenType support missing for script 16
2017-04-17 13:10:27 GUI: OpenType support missing for script 16
2017-04-17 13:12:18 receive version message: /Snoopy:0.2.1/: version 70001, blocks=0, us=[2001:0:4137:9e76:3420:2fda:ae92:dc1e]:8333, peer=30
2017-04-17 13:12:21 receive version message: /Satoshi:0.14.0/: version 70015, blocks=462289, us=[2001:0:4137:9e76:3420:2fda:ae92:dc1e]:55863, peer=31
2017-04-17 13:16:43 ProcessMessages(version, 111 bytes) FAILED peer=32
These errors are usually benign and have nothing to do with your node. |
|
|
|
You may need to reindex the blockchain, and possibly redownload the whole thing. First try reindexing it by adding -reindex to the startup command for Bitcoin Core. Incidentally, is it true one can torrent the whole blockchain these days?
No. The torrent is old and will be much slower than just letting Bitcoin Core sync normally. |
|
|
|
Anyone got notice (Request Queuing failed. Please try again.) ?
For sure, I also got the same message saying ( Request Queuing failed. Please try again.) Any suggestions, guys anyone??? Thank you. I am getting an error "Request Queuing failed. Please try again." every time I try
Fixed now. and what does member/merchant stand for ?
What "member"? Merchant means that some things will be hidden so that someone who is selling an account can link to the account stats without revealing the account itself. |
|
|
|
|
Yes. The data downloaded and created by previous versions will always be compatible with the latest version of Bitcoin Core. When you upgrade, you will not need to redownload or reindex anything.
|
|
|
|
1) This looks like a real virus https://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?name=Trojan%3aWin32%2fRundas.B&threatid=2147720787&enterprise=02) I downloaded several versions, the zipped, the installer etc. 3) The virus was found only in the zipped copy. 4) All were downloaded directly from the bitcoin.org website https://bitcoin.org/en/download5) It was the 'bitcoind' file specifically that Windows defender said had a problem. That was the part of the file that Armory used. I reinstalled the operating system now but still it seems like things are pretty low tech for a program that people are expected to trust a lot of money with. A bare minimum add on to bitcoin might be some program that automatically checks the hashes of certain files that don't change, like bitcoind. I've been using coins for a while but stopped using bitcoin wallets when they got above 10gb, the only reason I use it now is to get the functionality of Armory. If it were a false positive then it seems like it would have alerted on the other bitcoind files? Coins are great but a lot of people are going to be too trusting as they attach to strangers' computers to try and download 100+ gb. If the hash of the zip file matches the hash published on Bitcoin.org and the ones published here: https://github.com/bitcoin-core/gitian.sigs/tree/master/0.14.0-win-unsigned, then I can guarantee you that there is no virus whatsoever. The distributed binaries are built deterministically (meaning that everyone who builds it using the same build process will always get identical binaries) by multiple people, and the hashes are checked and signed by the PGP keys of those people. If the hash that you get from the download matches the hashes of the files built by everyone in the build process (including myself), then the download is genuine and there is no virus. If you don't trust that there is no virus there, you can even build it yourself and generate the same results. |
|
|
|
There are many problems with this idea that have been discussed before. Firstly, at what time do you consider someone's coins to be "lost"? How do determine coins to be lost? Is it that an output has not been spent from after a certain amount of time? If so, does the spending transaction have to be confirmed? If it does have to be confirmed, how do you prevent miners from blacklisting that output so that after the time limit is up they can claim the Bitcoin in that output? If it does not have to be confirmed, how do you ensure that everyone knows that that Bitcoin was "active" if the transaction never confirms? How do you differentiate between "lost" and "long term storage" coins? I was hoping you can translate the logging into account as synchronizing your wallet. But as I am not a programmer I am not sure if such a protocol can be implemented.
There are no such things as Bitcoin accounts, and synchronizing your wallet means nothing. Other nodes have no way to know that the wallet software in control of a certain address is in sync with the network, nor do they care. Furthermore, it is entirely possible and likely that people have fully synced wallets but have forgotten the password to their wallet and thus the coins are lost, but the wallet is still synced. This also applies to online wallets; the service (and thus the wallet) is fully synced but the owner of the Bitcoin has forgotten their password. |
|
|
|
256 bit is quite a big number. It is 7.734549710689605e+76 in decimal system. Question: Is each of this number a private key? Are there 7.734549710689605e+76 private keys? Or are only a fraction of this numbers private keys?
No, almost all are, but not all. The private key range goes from 0x0 to oxFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 which still encompasses an incomprehensibly large number of private keys. |
|
|
|
Thank you. This is a good explanation.
I have an other question:
Assumed I have generated an entropy which corresponds to the following number in the decimal system:
6179021094121108745210125512201665412
Does then the private key, which was created with this entropy, also have the following number in the decimal system:
6179021094121108745210125512201665412
(?)
No, it won't. Normally the entropy feeds into a Pseudo-Random Number Generator which is then used to actually generate your private key. However, because you are using BIP 39, it is directly encoded into the BIP 39 seed which is then converted using hashes and some other mathematical operations to get your private key. The operations only go one way, entropy to private key; you cannot go from private key back to the entropy data. |
|
|
|
|
Show Posts
