<_aj_>
robertspigler: maybe just means most i2p nodes aren't i2p-only (and thus make most of their outbound connections on ipv4/ipv6/onion)?
_apex_ has joined #bitcoin-core-dev
_apex2_ has joined #bitcoin-core-dev
_apex_ has quit [Ping timeout: 252 seconds]
gleb1068924 has quit [Quit: Ping timeout (120 seconds)]
gleb1068924 has joined #bitcoin-core-dev
dougefish_ has quit [Ping timeout: 244 seconds]
gleb10689249 has joined #bitcoin-core-dev
gleb1068924 has quit [Ping timeout: 252 seconds]
_apex2_ has quit [Ping timeout: 268 seconds]
<lightlike>
also, it could be a bit of a chicken-and-egg problem: If you start out with an addrman that has predominantly clearnet peers, your chance to pick an i2p peer for an outgoing connection is small. But if you don't make outgoing connections to i2p peers, you probably won't advertise your i2p address but your clearnet address, so that your i2p address won't propagate to other i2p peers. As a result you also won't get incoming i2p peers
<lightlike>
because others don't know you exist.
<robertspigler>
Makes sense
<robertspigler>
_aj_: Should there not be a preference to make atleast 1 i2p connection for network diversity sake
_apex2_ has joined #bitcoin-core-dev
<_aj_>
lightlike: that sounds suboptimal?
<_aj_>
robertspigler: i could see biasing addrfetch and the temporary block-relay-only connections to ensure connections are regularly made to each reachable net, to help maintain connectivity; but biasing a permanent connection might be risky?
dougefish has joined #bitcoin-core-dev
dougefish has quit [Remote host closed the connection]
<vasild>
what about this: try to maintain at least 1 outbound to each reachable network? so when choosing a peer to connect to, ask addrman to give us a random i2p peer if we dont have i2p out connections and i2p is reachable
<bitcoin-git>
bitcoin/master 8b2891a Vasil Dimov: i2p: use the same destination type for transient and persistent addresses
<bitcoin-git>
bitcoin/master 19526d9 fanquake: Merge bitcoin/bitcoin#26065: i2p: use the same destination type for transi...
<bitcoin-git>
[bitcoin] fanquake merged pull request #26065: i2p: use the same destination type for transient and persistent addresses (master...i2p_transient_addr_type) https://github.com/bitcoin/bitcoin/pull/26065
<bitcoin-git>
bitcoin/master 97f5b20 stickies-v: refactor: use std::string for thread names
<bitcoin-git>
bitcoin/master 200d84d stickies-v: refactor: use std::string for index names
<bitcoin-git>
bitcoin/master 26cf9ea stickies-v: scripted-diff: rename pszThread to thread_name
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #25971: refactor: Use std::string for thread and index names (master...baseindex-getname-string) https://github.com/bitcoin/bitcoin/pull/25971
<vasild>
MacroFake: any idea how to deterministically reproduce #25365? Putting sleep in BaseIndex::SetBestBlockIndex() does not trigger it, nor in MainSignalsImpl::Iterate()
<lightlike>
vasild: "indeed if addrman has just e.g. 5% i2p peers, then the chance of randomly selecting one is... well... 5%" - It could be less due to the Selection logic in AddrMan, where we flip a coin to choose from new or tried, and then pick a random peer from whatever we chose in the first step.
<lightlike>
E.g. if we just enabled i2p so that all known i2p addrs are still in the new table, the chance could be closer to 2.5%.
<vasild>
lightlike: ah, that too! :)
fjMSX has quit [Quit: Уш'лЪЬ їз єтой IRC сетї]
<sdaftuar1>
hi, do i need to request write access to edit the release notes wiki page? i was going to add a note regarding headers presync.
<fanquake>
sdaftuar: have invited you
<fanquake>
although I'm not sure if write access is needed to make edits? Maybe just being a member of bitcoin-core orgnanisation (which it doesn't look like you were a part of either)
<sipa>
It looks to me that being a member of the "frequent contributors" group on the bitcoin-core org is sufficient.
<fanquake>
Yes I think so. Have edited that invite to just be the "frequent contributors" group
<sdaftuar1>
thanks, i have an edit button now!
<bitcoin-git>
[bitcoin] yancyribbens opened pull request #26111: refactor: Simplify bnb coin_selection test params (master...simplify-bnb-test-params) https://github.com/bitcoin/bitcoin/pull/26111
chipxxx has joined #bitcoin-core-dev
_apex2_ has joined #bitcoin-core-dev
fjMSX has joined #bitcoin-core-dev
_apex2_ has quit [Ping timeout: 250 seconds]
Guyver2 has left #bitcoin-core-dev [Closing Window]
bcdarc has joined #bitcoin-core-dev
sdaftuar1 has joined #bitcoin-core-dev
F1nny has quit [Quit: Termd]
<jb55>
has anyone experienced not being able to sync headers? I'm on master and still have this issue.
<sipa>
jb55: that's concerning, you have any more details? Due to #25717 it may take longer to sync headers.
<jb55>
sipa: not sure maybe I'll try tracing. but it seems like it's just stuck and is not receiving any data from peers, even from a local node on my network.
<sipa>
Out of disk space should not result in database corruption.
<instagibbs>
TODO: Add out of disk space regression tests...
<jb55>
I'll open an issue
<sipa>
Database errors propagating up and being interpreted as (permanent) block invalidity was one of the contributing factors to the BDB/LevelDB fork in the 0.7/0.8 transition.
_apex2_ has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
bytes1440000 has joined #bitcoin-core-dev
_apex2_ has quit [Ping timeout: 252 seconds]
<bytes1440000>
Blockstream and Chaincodelabs should find a way to not mess with open source bitcoin core wallet