Guest38 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
brunoerg has quit [Ping timeout: 248 seconds]
lowhope has quit [Ping timeout: 258 seconds]
jetpack has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in]
jetpack has joined #bitcoin-core-dev
lowhope has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Guest38 has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 272 seconds]
brunoerg has joined #bitcoin-core-dev
Guest38 has quit [Ping timeout: 248 seconds]
<bitcoin-git>
[bitcoin] fanquake opened pull request #25394: build: add *_STANDARD vars to depends gen_id (master...cache_bust_cxx_c_standard) https://github.com/bitcoin/bitcoin/pull/25394
brunoerg has quit [Ping timeout: 272 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
sipsorcery has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 255 seconds]
sipsorcery has joined #bitcoin-core-dev
kexkey has quit [Ping timeout: 248 seconds]
kexkey has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 248 seconds]
flooded has quit [Read error: Connection reset by peer]
brunoerg has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
Guest51 has joined #bitcoin-core-dev
Guest51 has quit [Client Quit]
aielima has joined #bitcoin-core-dev
aleggg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
szkl has quit [Quit: Connection closed for inactivity]
evanlinjin has quit [Ping timeout: 240 seconds]
evanlinjin has joined #bitcoin-core-dev
real_or_random_ has quit [Quit: ZNC 1.8.2 - https://znc.in]
real_or_random has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 252 seconds]
aielima has quit [Quit: Leaving]
belcher has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
AaronvanW has quit [Quit: Leaving...]
sipsorcery has joined #bitcoin-core-dev
<vasild>
I wonder about this strange behavior: both NET_UNROUTABLE and NET_INTERNAL are set to "reachable" (as in IsReachable() returns true) by default and that cannot even be changed by SetReachable(NET_INTERNAL, false);
<vasild>
Why is that? I do not think they should be reachable or even more - I do not think we should ever call IsReachable(NET_UNROUTABLE) or IsReachable(NET_INTERNAL)
<vasild>
So, it is probably irrelevant whether they are reachable or not because we never ask, except in the LimitedAndReachable_NetworkCaseUnroutableAndInternal unit test
szkl has joined #bitcoin-core-dev
furszy has joined #bitcoin-core-dev
aleggg has quit [Ping timeout: 240 seconds]
<vasild>
ok, at least IsReachable(NET_UNROUTABLE) could be called from PeerManagerImpl::ProcessMessage() if we receive an address from unknown addrv2 network
realies has quit [Ping timeout: 256 seconds]
evbosats has joined #bitcoin-core-dev
<sipa>
vasild: Uh, my guess would be that it's just "these can't be updated because they're irrelevant", and this logic predates BIP155.
esats has quit [Ping timeout: 252 seconds]
<vasild>
sipa: I added assert(net != NET_UNROUTABLE); assert(net != NET_INTERNAL); inside IsReachable(). unit tests did not fail, but some functional tests failed, e.g. p2p_invalid_messages.py
<vasild>
So, my assumption that we never call IsReachable() on those 2 nets is wrong.
<vasild>
Its probably possible to avoid that but would require some effort.
furszy has quit []
evbosats has quit [Ping timeout: 240 seconds]
yanmaani has quit [Remote host closed the connection]
yanmaani has joined #bitcoin-core-dev
realies has joined #bitcoin-core-dev
ajonas_ has quit []
ajonas has joined #bitcoin-core-dev
evanlinjin has quit [Remote host closed the connection]
<lightlike>
Though I don't think we rely on them being reachable, I'd suspect that if we set the default to non-reachable, everything should still work, and we'd save some time by not attempting to add these addresses to addrman (the point at which they are discarded now).
evanlinjin has joined #bitcoin-core-dev
evanlinjin has quit [Remote host closed the connection]
<achow101>
There are no pre-proposed wallet meeting topics. Does anyone have anything to discuss?
<provoostenator>
Not really
<kanzure>
hi
<achow101>
any prs we should be prioritizing?
brunoerg has joined #bitcoin-core-dev
<achow101>
or does anyone want to talk about what they're working on?
<fjahr>
hi
utzig_ has left #bitcoin-core-dev [#bitcoin-core-dev]
<Murch>
I have found a coin selection approach that looks very promising in that it outperforms anything with Knapsack except in keeping the UTXO pool tiny.
<fjahr>
maybe #25351 could get a 24.0 milestone tag? The predecessor had 21/22 tags.
<Murch>
However, Knapsack is notorious for being too aggressive in consolidating.
<achow101>
fjahr: added to the milestone
<instagibbs>
Murch, still spends negative effective value, yeah?
<fjahr>
achow101: thanks!
<achow101>
Murch: Is the change in utxo pool explainable by not spending negative ev?
<Murch>
Working on writing it up so that I hopefully can convince it does better or equally well in other regards while removing a bunch of worst case-outcomes we've seen in the past.
brunoerg has quit [Ping timeout: 255 seconds]
jarolrod_ is now known as jarolrod
<Murch>
instagibbs: My idea is to allow that only at feerates < 2 ṩ/vB, while adding a FIFO selector.
<Murch>
That way it does happen, but not when it hurts by paying 10× as much than necessary
mudsip has quit []
<Murch>
Knapsack would often just tack it on with the next best transaction (since it reduces the change amount, and knapsack optimizes for smallest change)
<Murch>
So, be it 10 ṩ/vB or be it 200 ṩ/vB, knapsack would grab it.
<achow101>
have you simulated at low and high fee rates?
<Murch>
Yeah, I have simulated with the peak-and-tail and the 2019–2020 scenario
<achow101>
what about different scenaiors?
<Murch>
I used the tiny bustabit scenario, though, so it's from the perspective of a wallet that gets twice as many deposits as it makes payments. I still need to run on other scenarios, although they're generally easier, because they are less imbalanced towards building a huge UTXO pool
<Murch>
Anyway, if someone wants to seed some concerns that I should address, I'd be happy to hear you what your bar for convincing a change in the coin selection strategies would be ;)
brunoerg has joined #bitcoin-core-dev
<achow101>
cool, any other topics?
<furszy>
from my side, have been implementing your suggestion in 25297
<furszy>
and.. jumping across the sources a bit
<furszy>
found few things doing it
<achow101>
furszy: that's great, looking forward to those changes
brunoerg has quit [Ping timeout: 260 seconds]
<furszy>
yeah :), I still owe you finish 24914 review. It's at the top of my list.