< bitcoin-git>
[bitcoin] prayank23 opened pull request #22316: doc: Add 5 privacy recommendations in tor.md (master...tor-privacy-recommend) https://github.com/bitcoin/bitcoin/pull/22316
< bitcoin-git>
[bitcoin] prayank23 opened pull request #22317: doc: Highlight DNS requests part in tor.md (master...highlight-dns-request) https://github.com/bitcoin/bitcoin/pull/22317
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20966: banman: save the banlist in a JSON format on disk (master...json_bans) https://github.com/bitcoin/bitcoin/pull/20966
< vasild>
* Added support for running Bitcoin Core as an [I2P (Invisible Internet Project)](https://en.wikipedia.org/wiki/I2P) service and connect to such services. See doc/i2p.md for details. (#20685)
< vasild>
it will only be a problem if some bitcoin node exists which uses SAM 3.2 and "listens" on port 8333 only (checks TO_PORT and drops the incoming connection if it is not 8333)
< vasild>
and it advertises itself as foo:8333 and we change that to foo:0
< jonatack>
sgtm. we need something like that if I2P addrs are valid with port number 0 only, which is unfortunate. i don't know of a way to remove or update the existing I2P addrman entries manually from 8333 to 0 (other than deleting peers.dat) so outbound and addnode connections work.
< jonatack>
and unfortunate that setting the port number to 0 or ignoring the port number would be necessary for SAM < 3.2, i wonder if the remedy is worse than having (short-lived) double connections
< fanquake>
That's annoying. Just another reason to bump the minimum required macOS version
< hebasto>
for 22.0 or later?
< fanquake>
Then we'll get std::unordered_map::merge and std::filesystem
< fanquake>
I would have thought our 10.14 build in the CI would have caught this, as it's building against a 10.15.x SDK, but setting the runtime version to 10.14.x
< vasild>
editing addrman's entries (changing ports) would require re-bucketing
< jonatack>
yes, as i wrote this morning: "i wonder if the remedy is worse than having (short-lived) double connections"
< vasild>
Why short-lived?
< jonatack>
only that i see that they are infrequent and don't last long
< jonatack>
e.g. less than 5 minutes, most often 1 or 2 minutes
< vasild>
I have no explanation for that, but short-lived or long-lived is not very important
< jonatack>
they seem to have become very rare as well (for me). i currently know of 14 i2p peers and am usually connected to 11-12 of them at a time, e.g. right now 6 outbound, 6 inbound
< jonatack>
(double connections become very rare, they used to be common)
< vasild>
the issue 21389 only happens when addnode is (mis)used
< vasild>
or -connect=...
< vasild>
(mis)used == addnode same i2p addr with different ports
< jonatack>
either same one in and out (both sides adding the other) or two in at once (maybe because addnode was used twice, with and with port)
< jonatack>
*with and without port
< vasild>
yes
< vasild>
maybe we played more with addnode before and recently have left it alone
< jonatack>
wait until SAM 3.2 then?
< vasild>
and do what if/when we start using SAM 3.2?
< jonatack>
that's probably true about less addnode use
< jamesob>
maintainers: anything else you'd like to see for #21526 to merge? once that goes in I can open a number of other smaller AU PRs
< jonatack>
looking at https://geti2p.net/en/docs/api/samv3, SAM 3.2 introduces options FROM_PORT and TO_PORT, and in SAM 3.3, "incoming packets and streams will be routed based on I2P protocol and to-port"
< bitcoin-git>
[bitcoin] theStack opened pull request #22330: test: use MiniWallet for simple doublespend sub-test in feature_rbf.py (master...202106-test-feature_rbf_use_miniwallet_for_doublespend) https://github.com/bitcoin/bitcoin/pull/22330