I always use the tarball from https://github.com/bitcoin/bitcoin/releases. My wallet and 2 nodes are on Bitcoin Core 0.15.0.1. Today I want to upgrade them to Bitcoin Core 0.15.1. I usually ignore the notes on that github release page which says the following: Preferably use the above download link, not the below links to download the source tarball, as the release tarballs are generated deterministically and GitHub's are not. I always use the tarball on the "below links", not the "above download link". What is/are the differences between them actually? Thanks a lot in advance. |
|
|
|
Do you have a significant amount? If not, leave them until better times.
There are 24 addresses containing values below 4 mBTC in my wallet. I just ticked all of those addresses, and my Bitcoin-qt shows the total is only about 28 mBTC with the estimated total size of 3630 bytes and fee about of 36 mBTC. So I cannot even use them to buy something worth 10 mBTC. |
|
|
|
Just keep them and wait. There may come a time in the future when transaction fees become smaller, and value is higher. Perhaps someday in the future the 0.1 mBTC will be worth $100 and the fees to spend it will be only 0.01 mBTC ($10) so you can consolidate it and still keep $90 of value.
Thanks Danny, Yes, I guess this issue happens to anyone. So I am wondering why there is no solution for this, except hoping for the miners to take tiny amount of fees. For me, I don't have enough amount of BTC anymore on a single address to buy something I need. Those small amount of BTCs are mostly the remaining BTC from my previous transactions in which I always use maximum 2 addresses to reduce the fee. Well... I guess I have to start mining again to get more BTC into my wallet. |
|
|
|
|
Thanks for your responses lady Royal and AngelSky.
I forgot to mention that I am using Bitcoin-qt 0.15.0.1. So I don't think I can transfer all of those low amount of BTC into online wallet or somewhere else, due to the same issues.
|
|
|
|
|
Perhaps I didn't use the right term so I found no similar question on this forum. So I am sorry if I repeat the question.
I have several addresses in my wallet containing very small amount of BTC ranging from 0.1 mBTC to 3 mBTC. I cannot practically use them to buy anything, because the fee becomes much higher than the total of them as the transaction size becomes quite big when I combine them.
I don't think we can merge them into a single address offline (assuming that is possible) as they have to be included into the block chain.
What should I do with them? Does anybody have any suggestions?
Thanks in advance for your help.
|
|
|
|
How did you collect those IP addresses? I have implemented a quick and dirty workaround to block the nodes that I thought bad ones as I explained on this post. I am using a script to collect the IP addresses from the debug.log based on certain criteria, and I use iptables and ipset to block them accessing my nodes at my firewall. Bitcoin Core 0.15.0.1 does that kind of banning smartly at protocol level for the segwit2x nodes. But now, since the disguise feature was implemented, I am not sure what kind of criteria that we can implement at user level, to collect the IP addresses of those segwit2x nodes which use that feature. Does anybody else have any suggestions? |
|
|
|
I assume there are a lot more IP addresses of the nodes supporting segwit2x by now. Is this list of that IP addreses up to date? My 2 nodes have been on Bitcoin Core 0.15.0.1 since last month. But after the implementation of the disguise feature on this commit, I am not sure anymore how to ban the nodes running with that codes. I don't like the idea of this hard fork, so I don't want to let my nodes listen and propagate those nodes to the network. |
|
|
|
|
When I asked my friends and families on their opinions about Bitcoin and why they don't want to use it, all of them answered that they don't trust Bitcoin. One of the contributors on why ordinary people do not trust Bitcoin is this kind of confusing issues.
And this confusing issue is mainly caused by the egos of the programmers who do not care whether ordinary people trust Bitcoin or not. Those programmers are definitely smart people. But they are so ignorant on the actual social and economical impacts of their egos. I hate this kind of people. So the only thing I can do in protesting their actions is by not supporting them. One way I do that is by blocking any nodes with the Classic user agent to connect to my node, so that my node will not propagate them further.
|
|
|
|
Since I started to block peers with this offending user agents about 2 weeks ago, I have total unique IPv4 addresses of that peers added into my ipset blacklist which are blocked by my iptables firewall as below. root@ledzeppelin:~# cat added_peers_IPv4_with_invalid_user_agent.log | wc -l
1962
root@ledzeppelin:~#
The total unique IPv4 addresses on my ipset blacklist are actually more as I also block other peers which I don't want to access my node, like the peers with the wrong setup which pretend to access 127.0.0.1:8333 of my node. root@ledzeppelin:~# ipset list ipv4blacklist | grep -Ev "Name|Type|Revision|Header|Size|References|Members" | wc -l
6315
root@ledzeppelin:~#
|
|
|
|
|
I am really wondering as well. This seems to be because somebody distributed a pre-compiled modified Bitcoin (Classic?).
Since I posted yesterday, my "invalid peers" black list now contains 2414 unique IPv4 addresses, which are blocked by my iptables firewall. There were only 2168 IPv4 addresses of the "invalid peers" yesterday. Most of the additional blacklisted IPv4 addresses come from the peers with this "user agent" name.
|
|
|
|
It looks like this has just started about 2 days ago. According to my debug.log files, so far there are 256 unique IPv4 addresses with this offending "user agent". I recently just blacklisted the IPv4 addresses of all peers with this "user agent" on my iptables firewall as I mentioned on https://bitcointalk.org/index.php?topic=1371683.0. |
|
|
|
I have blocked 2168 unique peers IPv4 addresses until now. The black list of is growing everyday  A part from blocking the peers causing the messages on debug.log like below: receive version message: /Satoshi:0.11.2/: version 70002, blocks=398147, us=0.0.0.0:0
receive version message: /bcoin:1.0.0-alpha/: version 70002, blocks=370555, us=0.0.0.0:8333
receive version message: /bitcoinj:0.13.4/Bitcoin Wallet:4.46/: version 70001, blocks=400440, us=127.0.0.1:8333
I also blocked the peers which do not use valid (in my opinion) user agents like below: receive version message: : version 32100
receive version message: : version 40000
receive version message: Why? Because fuck u, thats why: version 70002
There seems to be no significant affect on my node by blocking those peers as it is still running fine with the connected peers still always above 50, 56 at the time of my writing. root@ledzeppelin:~# bitcoin-cli getinfo
{
"version": 120000,
"protocolversion": 70012,
"blocks": 400442,
"timeoffset": 0,
"connections": 56,
"proxy": "",
"difficulty": 163491654908.9593,
"testnet": false,
"relayfee": 0.00001000,
"errors": ""
}
root@ledzeppelin:~#
I hope by doing this my node will not relay the peers that are not serious in maintaining the integrity of Bitcoin network. |
|
|
|
Um, no, it is not wise to block connections to and from 0.0.0.0 and 127.0.0.1, though I don't think iptables affects non-routable addresses anyway. They're not invalid; ping them and see what happens. Notice the astonishingly low latency? Those are your IP addresses. That's what "us" means in the log.
The IP addresses 0.0.0.0 and 127.0.0.1 are the IP address of my full nodes that the peers thought to be able to connect to - notice the word us on the following messages for instance: .
2016-02-21 05:20:48 receive version message: /libbitcoin:2.11.0/: version 70001, blocks=399106, us=0.0.0.0:0, peer=2198, peeraddr=5.189.177.237:35504
2016-02-21 07:05:20 receive version message: /libbitcoin:2.11.0/: version 70001, blocks=0, us=0.0.0.0:0, peer=2549, peeraddr=85.93.88.92:53661
2016-02-21 08:53:08 receive version message: /libbitcoin:2.11.0/: version 70001, blocks=399106, us=0.0.0.0:0, peer=2919, peeraddr=5.189.177.237:60182
.
2016-02-21 10:06:58 receive version message: /bitcoinj:0.13-SNAPSHOT/DNSSeed:43/: version 70001, blocks=399428, us=127.0.0.1:8333, peer=3194, peeraddr=162.243.132.6:41992
2016-02-21 10:09:30 receive version message: /BitCoinJ:0.11.2/MultiBit:0.5.19/: version 70001, blocks=374614, us=127.0.0.1:8333, peer=3202, peeraddr=185.61.151.176:53738
2016-02-21 10:15:50 receive version message: /bitcoinj:0.13.4/Bitcoin Wallet:4.46/: version 70001, blocks=399428, us=127.0.0.1:8333, peer=3229, peeraddr=71.226.158.207:55651
.
So the IP addresses that I want to block are the IP addresses of the peers, i.e. the peeraddr. |
|
|
|
On my full nodes, I got a lot of "receive version message" on the debug.log with "us=0.0.0.0" and "us=127.0.0.1". There are only a few peers causing the messages with IP address 0.0.0.0 but hundreds of peers causing the messages with IP address 127.0.0.1. The peers which cause the messages with 0.0.0.0 IP address are using the following User Agents: /libbitcoin:2.11.0/: version 70001
/Satoshi:0.11.2/: version 70002
And the peers which cause the messages with 127.0.0.1 IP address are using the following User Agents: /BitCoinJ:0.11.2/MultiBit:0.5.18/: version 70001
/bitcoinj:0.12.2/: version 70001
/BitCoinJ:0.12SNAPSHOT/Aegis Wallet:1.0/: version 70001
/bitcoinj:0.13.2/Bitcoin Wallet:4.39/: version 70001
/bitcoinj:0.13.3/Bitcoin:1.04/: version 70001
/bitcoinj:0.13.3/Bitcoin Wallet:4.42/: version 70001
/bitcoinj:0.13.3/Bitcoin Wallet:4.43/: version 70001
/bitcoinj:0.13.3/Bitcoin Wallet:4.44/: version 70001
/bitcoinj:0.13.3/MultiBitHD:0.2.0/: version 70001
/bitcoinj:0.13.4/Bitcoin Wallet:4.45/: version 70001
/bitcoinj:0.13.4/Bitcoin Wallet:4.46/: version 70001
/bitcoinj:0.13/GetGems:1.0/: version 70001
/bitcoinj:0.13-SNAPSHOT/DNSSeed:43/: version 70001
/bitcoinj:0.13SNAPSHOT/DNSSeed:43/: version 70001
/Bither1.4.3/: version 70001
I am really wondering what causes this and what the impact of letting the peers which cause that keep coming in. Do you think it is wise to block those peers on my iptables firewall using ipset for instance? Thanks in advance for any answers and comments. |
|
|
|
I have just raised this issue on github as below. I have 4 IPv6 addresses on the eth0 interface of my VPS. I have set routings of all those IPv6 addresses using "ip -6 rule", "ip -6 route" and their corresponding fwmark label on ip6tables. I want all bitcoind packets for both outgoing and incoming connections to use one specific IPv6 address which is not the default outgoing IPv6 address. I set the externalip to that specific IPv6 address and the discover=0.
However, bitcoind keeps using the default IPv6 address for outgoing connection. I can force the outgoing packets from bitcoind to go out to its specific IPv6 address using ip6tables SNAT. But that is an ugly workaround. So I have no choice than to set the IPv6 address of bitcoind as the default outgoing IPv6 address.
What is the point to provide the possibility to set the external IP address, i.e. externalip parameter, if it is not being used for the outgoing connection? It does not really make sense if the externalip parameter is only being used for the incoming connection, because all peers only know how to connect to my full node base on the IP address that my full node uses for the outgoing connection. So if my full node is connecting to all peers with different IP address than the one it is expecting to receive the incoming connection, my full node will never have peers that can connect to it as the port 8333 is only opened on its specific IP address.
I saw similar issues on github, but I don't see any good answers for that. Does anybody have a workaround or a patch for bitcoind, so that bitcoind uses the externalip that we set for outgoing connection? |
|
|
|
|
I still suspect that there is something wrong in Bitcoin package related to the handling of IPv6.
I have installed and set up bitcoind on my PC at home that I am using as NAS backup. I set only to run on IPv6, i.e. onlynet=ipv6. It has been running for more than a day now. But there are only 2 IPv6 peers connected to it and all 8 outgoing connections have been used. This has happened after about an hour after restarting bitcoind, so no change after that. When I checked it just now, there were 29 unique IPv6 peers recorded on the debug.log. And out of that 29 IPv6 peers, 16 of them opened port 8333.
On IPv4, I usually get more than 20 peers (8 of them outgoing peers) within an hour after I restart bitcoind. I expected that my node gets more IPv6 peers than 10 after runing more than a day. So it looks like the propagation of peers on IPv6 is very much lower. But I still don't believe that it is because there are less IPv6 peers. But let's see how this look like in the next 2 days.
|
|
|
|
My implementation would be to connect to as many nodes as possible until there are none able to connect to or the outbound connections are full.
For example, with IPv6, it would search the local database for all IPv6 nodes and attempt to connect to all of them. Then it would ask for peers and connect to any IPv6 that it's peers gives to it. After either all 8 outbound connections are taken or there are no remaining IPv6 nodes that can be connected to after searching through the databases described above, it will make outbound connections to IPv4 nodes if any outbound slots are available. It would accept any incoming connections from both IPv4 and IPv6.
I would imagine that you need to modify a lot of other places in the current Bitcoin software. So the risk of breaking other parts in the system that might not even be related to the main purpose of the changes, will be higher. So I still think that the risk is lower if we would just separate the MAX_OUTBOUND_CONNECTIONS for individually IPv4 and IPv6. Because in this case, the parts that will be broken is very likely the additional ones related to IPv6. I hope that they will do very minimal modifications on the parts related to IPv4. |
|
|
|
I think that is actually a bad idea. You run into memory issues at some point and having more connections takes up more bandwidth. I tried setting MAX_OUTBOUND_CONNECTIONS to something really high before and it crashed the program. It just took up way to much memory.
I don' think you would have significant issues if you would increase MAX_OUTBOUND_CONNECTIONS to 16. But in any case as I previously mentioned, I am quite sure it will still not solve the problem that there are much more IPv4 peers than IPv6 peers connected to and from the node, unless the maximum outbound connections setting is being separated for each IPv4 and IPv6 addresses. I think it might be better to have an option to prioritize one network over another e.g. get as many IPv6 connections as possible before getting IPv4 connections.
I think I will try writing some code up and submitting a PR for that.
I think it will be more complex to implement that kind of network type prioritisation. Suppose that you want to prioritise IPv6 over IPv4. How do you manage the threshold of the number of IPv6 peers before you allow IPv4 peers to be connected to the node and being connected from the node? How about if the nodes would never reach that threshold, resulting you have less IPv6 peers and no IPv4 peer for a long time? Would you use a dynamic timer to avoid that issue? As the network is dynamic, would you keep maintaining the number of IPv6 peers to always above the threshold regularly? Or would you manage that base on the timer? And so on And if you manage to find the solution for that without increasing MAX_OUTBOUND_CONNECTIONS or the maximum outbound connection slots remain 8, the chances that the node will have less IPv4 peers for longer time than before the implementation of your solution is quite high. |
|
|
|
You clearly already know everything and don't need any help. Sorry to disturb you. Have a nice day!
Please don't get me wrong. If I knew the reasons of the problem, I would not ask the question in the first place. However, you didn't actually answer my main question, especially on why Bitcoin node does not automatically connect to the available IPv6 peers while I can manually force it to connect to the IPv6 peers. It has to do with how node discovery works. Your node has an internal database of nodes that it will try to connect to. That database is built by nodes that you have previously connected to (so it will include your IPv6 peers from the past) and nodes that your peers have announced to you. Given that you have only connected to a few IPv6 nodes, then your database of available IPv6 nodes is probably very small. Since you can only have 8 total outgoing connections, your node is unable to connect to other IPv6 nodes that it knows about once all 8 connections are taken. After that, you just have to wait for other IPv6 nodes to connect to you, and you have no control over that whatsoever. All you can do is hope that your peers announce you to its peers and that your IP address makes it onto a DNS seed so that new nodes may be able to see your IPv6 Address and connect to you. Basically it all really has to do with how there are significantly less IPv6 nodes than there are IPv4 nodes and that the addresses of those IPv6 nodes is not propagated through the network. To get more IPv6 nodes, you could force your node to only accept IPv6 connections or force it to get peers from the DNS seed which will probably return more IPv6 nodes for you to connect to. Thanks for your comment. That makes sense to me. I think the fundamental problem is that, Bitcoin software only allows maximum 8 outbound connections regardless how many available IP addresses on the node. A part from obsolete implementation, i.e. based on only IPv4 network, I think the intention is possibly also to avoid bad nodes with multiple IP addresses flooding the network. Due to that 8 outbound connections limitation, it is quite likely that my nodes always connect to IPv4 peers first and they will be quite fast occupying the whole 8 outbound connection slots. For the same reason, the likelihood for my nodes to get IPv6 peers to connect to them is also quite low as all of those IPv6 peers experience the same issue, i.e. 8 outbound connections limitation, unless they are solely running on IPv6. I think this is what causing the propagation of IPv6 nodes into the whole network very slow. I can easily change the MAX_OUTBOUND_CONNECTIONS on net.cpp and re-compile my bitcoind. But I am quite sure that will not solve the problem, because my nodes will first connect to the available IPv4 peers and occupy the whole outbound connection slots again. I think the solution is to separate the maximum outbound connections per IP address types. So that each IPv4 and IPv6 addresses individually get maximum 8 outbound connections as they are clearly on separate networks. For this reason I raised this feature request. Unfortunately, I am not a hard core programmer otherwise I would fork Bitcoin, create a patch and pull request it. |
|
|
|
You clearly already know everything and don't need any help. Sorry to disturb you. Have a nice day!
Please don't get me wrong. If I knew the reasons of the problem, I would not ask the question in the first place. However, you didn't actually answer my main question, especially on why Bitcoin node does not automatically connect to the available IPv6 peers while I can manually force it to connect to the IPv6 peers. |
|
|
|
|
Show Posts
