Handle and hardcode TorV3 peers (after #19954), see #20239
Bring back onion functionality past TorV3 switch
We need a source of non-hardcoded V3 peers, currently the only ones are hardcoded and the seeder hasn’t been updated to crawl v3 nodes yet (see sipa/bitcoin-seeder#92)
Consider increasing uptime requirements for Tor nodes from 10% as there appear to be enough
#7398 was a previous attempt to improve this script, but was abandoned, maybe some changes are useful.
laanwj added the label
P2P
on Oct 2, 2019
laanwj added the label
Scripts and tools
on Oct 2, 2019
maflcko
commented at 12:25 pm on October 2, 2019:
member
good first issue? :trollface:
laanwj added the label
good first issue
on Oct 2, 2019
solon referenced this in commit
0b1dcd32bf
on Oct 3, 2019
maflcko referenced this in commit
f1f284aa75
on Oct 3, 2019
sidhujag referenced this in commit
206951bc3b
on Oct 4, 2019
laanwj added this to the milestone 0.20.0
on Oct 15, 2019
brakmic
commented at 2:11 pm on November 21, 2019:
contributor
Hi,
Would it be acceptable to get the suspicious hosts from a URL instead of a file?
I expanded the makeseeds.py with a small example that gets them from Greg Maxwell’s page.
laanwj
commented at 7:46 pm on November 22, 2019:
member
Would it be acceptable to get the suspicious hosts from a URL instead of a file?
I expanded the makeseeds.py with a small example that gets them from Greg Maxwell’s page.
I don’t think the script should fetch from a URL automatically (this interferes with deterministic use), but telling the user to get it themselves is fine.
sanjaykdragon
commented at 0:39 am on December 29, 2019:
contributor
Updated your first point:
“Read suspicious hosts (and ASNs) from a file instead of hardcoding”
laanwj referenced this in commit
7e841f3f9b
on Jan 20, 2020
sidhujag referenced this in commit
ac6cf09572
on Jan 24, 2020
fanquake removed this from the milestone 0.20.0
on Apr 7, 2020
fanquake added this to the milestone 0.21.0
on Apr 7, 2020
vasild
commented at 7:49 pm on September 23, 2020:
contributor
Would it be acceptable to get the suspicious hosts from a URL instead of a file?
A file that comes with the release is signed. Because the release is made e.g. 1 month ago the user knows that this same exact file has been published 1 month ago and if there was some problem with it then somebody would have complained. Accessing a local file does not depend on a centralized service running (the web server).
A file that has to be downloaded is not signed (yes, we can sign it with the same keys as the release and make bitcoind verify the signature). The user never knows when the file was created, maybe the web server is supplying one content to one user and another content to another user. If the web server just bricks, then the file is not accessible.
laanwj
commented at 10:36 am on October 29, 2020:
member
Now that (since #20237) we get the full number of Tor seeds (512), we could look into increasing, or even normalizing the uptime requirement for onions:
0# Require at least 50% 30-day uptime for clearnet, 10% for onion.1 req_uptime = {
2'ipv4': 50,
3'ipv6': 50,
4'onion': 10,
5 }
maflcko removed this from the milestone 0.21.0
on Nov 1, 2020
maflcko
commented at 9:03 am on November 1, 2020:
member
Cleared the milestone for now. This can happen anytime but shouldn’t hold up the next release.
sidhujag referenced this in commit
54aa12fd8b
on Nov 10, 2020
ghost
commented at 11:21 am on February 23, 2022:
none
A. Filtering hosts with multiple ports can be removed IMO:
C. Recent observation which can be confirmed with:
0wget https://gitlab.com/api/v4/projects/33695681/packages/generic/nrich/0.1.1/nrich_0.1.1_amd64.deb
1sudo dpkg -i nrich_0.1.1_amd64.deb
2host -t a seed.bitcoin.sipa.be | sed -e 's/seed.bitcoin.sipa.be has address //g' | nrich -
Possible reasons for vulnerable machines used for bitcoin nodes:
False positives
Users not aware or don’t care
Attackers prefer using these for better results
Honeypots
Other reasons
Leaving 1 which won’t be true for all the results, filtering such nodes in makeseeds.py should make sense. Below is an example for one IP copied from suspicious_hosts.txt
russeree
commented at 6:44 am on April 10, 2022:
contributor
From “Read suspicious hosts (and ASNs) from a file instead of hardcoding (scripts: Read suspicious hosts from a file instead of hardcoding #17823 does this for suspicious hosts)”
I would like to tackle the (and ASNs) portion of this task. Firstly in regards to ASNs nothing seems to be hard coded into the generation process currently other than a parse to an external service. Currently each seed ip-address is parsed though xxx.xxx.xxx.xxx.origin.asn.cymru.com. Does this task imply that a complete list of ASNs should be stored locally and updated periodically? The current cost of a complete compressed list of ASNs and their IP address blocks is ~5.5MB.
Secondly does this mean there should be a suspicious ASNs file? I don’t think this is the correct interpretation.
If all my interpretations are incorrect please let me know.
RF5
commented at 7:55 am on April 12, 2022:
contributor
I’ve tried to address some of the more minor points of improvement in #24818 , namely differentiating max seeds per ASN for ipv4 and ipv6, with some more docs and a MIN_BLOCKS bump. Any feedback would be appreciated.
laanwj referenced this in commit
7da4f65a00
on Apr 15, 2022
laanwj
commented at 8:50 am on April 15, 2022:
member
Secondly does this mean there should be a suspicious ASNs file? I don’t think this is the correct interpretation.
No, a list of suspicious ASNs has not been proposed. To be honest I don’t think that’s very useful, neither is the list of suspicious hosts, it makes no sense to maintain that as part of this project. The more general rules “N hosts per ASN” make sense, though.
fanquake referenced this in commit
d2e04196b6
on Apr 18, 2022
Munkybooty referenced this in commit
ad766b68c3
on Jun 9, 2022
Munkybooty referenced this in commit
c04179d2fe
on Jun 21, 2022
Munkybooty referenced this in commit
0dfe999d0d
on Jun 25, 2022
Munkybooty referenced this in commit
5c21cac562
on Jun 28, 2022
Munkybooty referenced this in commit
e34c7fe83d
on Jul 6, 2022
Munkybooty referenced this in commit
94a2c574ac
on Aug 3, 2022
fernandezpablo85
commented at 3:40 pm on August 9, 2022:
contributor
Munkybooty referenced this in commit
07e7f2a7c8
on Aug 16, 2022
Munkybooty referenced this in commit
edfe46a5e6
on Aug 22, 2022
Munkybooty referenced this in commit
7ccdd9386e
on Aug 22, 2022
Munkybooty referenced this in commit
df6c5a30c0
on Aug 23, 2022
Munkybooty referenced this in commit
93d4768e99
on Sep 6, 2022
Munkybooty referenced this in commit
c685dbc502
on Sep 19, 2022
Munkybooty referenced this in commit
8ddd492e6b
on Oct 3, 2022
Munkybooty referenced this in commit
5aee25d674
on Oct 13, 2022
Munkybooty referenced this in commit
3909e38ecb
on Oct 13, 2022
Munkybooty referenced this in commit
d8e62ca6bf
on Oct 17, 2022
PastaPastaPasta referenced this in commit
8c6fb5622d
on Oct 17, 2022
russeree
commented at 2:29 pm on January 29, 2023:
contributor
The per ASN limit IS being enforce properly. I wrote a python script to validate the output of node_main.txt and the limits are being enforced. The previous thread is locked.
laanwj
commented at 9:10 pm on January 29, 2023:
member
Thanks, I ticked that one off. I’m fairly sure also that it was fixed in the latest round of changes.
willcl-ark
commented at 11:57 am on May 31, 2024:
member
[ ] Bring back onion functionality past TorV3 switch
[ ] We need a source of non-hardcoded V3 peers, currently the only ones are hardcoded and the seeder hasn’t been updated to crawl v3 nodes yet (see crawler: Collect Tor v3 and I2P addresses? sipa/bitcoin-seeder#92)
I think these two can be checked off post-https://github.com/bitcoin/bitcoin/pull/30008 ?
This is a metadata mirror of the GitHub repository
bitcoin/bitcoin.
This site is not affiliated with GitHub.
Content is generated from a GitHub metadata backup.
generated: 2024-11-17 12:12 UTC
This site is hosted by @0xB10C More mirrored repositories can be found on mirror.b10c.me