kakolainen[m] has quit [Ping timeout: 268 seconds]
stratospher[m] has quit [Ping timeout: 268 seconds]
afmencken has quit [Remote host closed the connection]
afmencken has joined #bitcoin-core-dev
SpellChecker has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 248 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
SpellChecker has quit [Remote host closed the connection]
SpellChecker has joined #bitcoin-core-dev
B_1o1 has joined #bitcoin-core-dev
B_1o1 has quit [Quit: Leaving]
B_1o1 has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
B_1o1 has quit [Remote host closed the connection]
B_1o1 has joined #bitcoin-core-dev
B_1o1 has quit [Client Quit]
Kaizen_Kintsugi_ has quit [Ping timeout: 248 seconds]
_apex_ has quit [Ping timeout: 268 seconds]
mudsip has joined #bitcoin-core-dev
mudsip has quit [Client Quit]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
yanmaani2 has quit [Remote host closed the connection]
yanmaani2 has joined #bitcoin-core-dev
_apex_ has joined #bitcoin-core-dev
_apex_ has quit [Ping timeout: 252 seconds]
NorrinRadd has joined #bitcoin-core-dev
furszy has quit [Changing host]
furszy has joined #bitcoin-core-dev
NorrinRadd has quit [Ping timeout: 248 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 244 seconds]
_apex_ has joined #bitcoin-core-dev
cmirror has quit [Remote host closed the connection]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
cmirror has joined #bitcoin-core-dev
_apex_ has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has quit [Ping timeout: 248 seconds]
yanmaani2 has quit [Ping timeout: 258 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
_apex_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 244 seconds]
_apex_ has quit [Ping timeout: 268 seconds]
AaronvanW has quit [Quit: Leaving...]
yanmaani2 has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 248 seconds]
_apex_ has joined #bitcoin-core-dev
_apex_ has quit [Ping timeout: 248 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<hebasto>
is a fix of a translation bug, which causes an error on Transifex, supposed to be merged after "string freeze"? (context -- https://github.com/bitcoin-core/gui/pull/664, an my opinion is "yes")
Kaizen_Kintsugi_ has quit [Ping timeout: 244 seconds]
_apex_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
_apex_ has quit [Ping timeout: 248 seconds]
realies3 has joined #bitcoin-core-dev
yanmaani2 has quit [Ping timeout: 258 seconds]
realies has quit [Ping timeout: 260 seconds]
realies3 is now known as realies
lukedashjr has joined #bitcoin-core-dev
luke-jr has quit [Ping timeout: 244 seconds]
lukedashjr is now known as luke-jr
sipsorcery has joined #bitcoin-core-dev
yanmaani2 has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 248 seconds]
SpellChecker has quit [Remote host closed the connection]
<vasild>
I am looking at Erlay and the problem it is aiming to address - the inefficient flood-like tx propagation through the network. Is it the case that this flooding/inefficiency only happens for incoming INV/TX messages? That is - the transaction themselves seem to be sent only on request (ignoring unsolicited tx broadcast) which is efficient since we don't request the same tx from more than one peer
<vasild>
at a time, so no redundancy/waste of bandwidth. Also outgoing inv/tx messages are sent efficiently - we try not to send the same inv/tx to the same peer more than once. Is my understanding correct? gleb, sipa
<vasild>
I added some more counters to my node to measure traffic with more granularity.
<sdaftuar1>
vasild: yes, the issue is that as the number of (full tx relay) peers goes up, bandwidth for tx relay goes up as well even thougg transactions are generally only downloaded once per node
<sdaftuar1>
because of the inv overhead which is per connection
<sdaftuar1>
so erlay should make it easier for us to increase the default number of full tx relay peers a single node connects to
<vasild>
right, my public listening node (~120 connections, in+out) consumed about 450GB traffic last month, while my non listening node (just ~8 connections, all outbound) - about 15GB
<_aj_>
sdaftuar1: we should also increase the number of block-relay-only peers we allow to connect to us now too, no?
<sdaftuar1>
perhaps? i lost track of where we are on that
<_aj_>
sdaftuar1: yeah me too. i think #22778 solved the potential memory blow-out
<gribble>
https://github.com/bitcoin/bitcoin/issues/22778 | net processing: Reduce resource usage for inbound block-relay-only connections by jnewbery · Pull Request #22778 · bitcoin/bitcoin · GitHub
ghost43 has quit [Ping timeout: 258 seconds]
ghost43 has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 248 seconds]
NorrinRadd has joined #bitcoin-core-dev
dunxen has joined #bitcoin-core-dev
NorrinRadd has quit [Ping timeout: 248 seconds]
<vasild>
sdaftuar1: "so erlay should make it easier for us to increase the default number of full tx relay peers a single node connects to" -- this would only be relevant for non-listening nodes, because listening ones already have >100 connections (in or out is irrelevant for inv/tx flooding), right?
<vasild>
I mean increasing the number of out connections, for a listening node would have very little impact - e.g. from 120+8 it would go to 120+10
<_aj_>
vasild: (listening + non-listening) * outbound == listening * inbound -- you can't increase the outbounds without increasing the inbound number, so inbounds have to be able to cope with 200 (eg) instead of 120 connections
<vasild>
hmm, I assumed that listening nodes are not fully occipied, i.e. that it is _not_ the case that most listening nodes now at the cap
NorrinRadd has joined #bitcoin-core-dev
<_aj_>
if you have 1000 listening nodes and 14000 non-listening nodes; each node makes 8 outbound tx relay connections, that's 15000*8 outbound connections = 120,000 outbound connections --> 120,000 inbound connections, but there's only 1000 nodes listening for inbound connections, so then each gets 120 inbound connections
<_aj_>
if you then increase the outbounds from 8 to 12 (+50%) you increase the inbounds by 50% too, so instead of 120 each, you have 180 each
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
<_aj_>
for a total of 180 in + 12 out + 2 block-relay-only = 194 connections for each listening node, rather than 120+8+2 = 130
AaronvanW has joined #bitcoin-core-dev
<vasild>
right, do we have some metric for mainnet how many connections listening nodes have?
<_aj_>
whenever i look at my node it has ~100, and we limit it to 120-something?
Kaizen_Kintsugi_ has quit [Ping timeout: 244 seconds]
<_aj_>
that would imply 400-500 inbounds per listening node, though. could be due to counting nodes that are only online intermittently to sync up (a few hours a day?) i guess
<_aj_>
err, no it doesn't
<_aj_>
it implies 86 inbound connections per listening node, which is completely plausible
<vasild>
46k total, each making 8 outbound = 368000
<vasild>
divided by 4700 = 78
<_aj_>
or 107 inbound connections if you count 8-tx + 2-block-relay-only, which exactly matches my node when i looked a minute ago
<_aj_>
yeah, you're right, i'm very bad at maths
<vasild>
yeah and mine was at 117 IIRC before I shut it down yesterday, and now is at ~50
<_aj_>
anyway, there's a bunch of spy nodes out there which make way more than 8 outbound connections; and i think there's a few people who increase the limit above 125
<vasild>
alright, so the point is that if we increase outbound connections (currently 8) with X% that would increase inbound connections on listening nodes with X%, but up to 125. If a listening node is already at 125, then it would get no increase (which if commonspread could create a network-wide problems of not enough listening nodes)
szkl has quit [Quit: Connection closed for inactivity]
_apex_ has joined #bitcoin-core-dev
_apex_ has quit [Ping timeout: 244 seconds]
NorrinRadd has quit [Ping timeout: 248 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
dougefish has quit [Ping timeout: 268 seconds]
Copinmalin has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
mdguy has joined #bitcoin-core-dev
dougefish has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 260 seconds]
<lightlike>
vasild: yes, with the inbound eviction logic (we kick out someone else if we are full) it would lead to a network-wide ping-pong effect which is probably not good. Figure 3 in this paper https://arxiv.org/pdf/2108.00815.pdf suggests that many nodes are already at the maximum of incoming connections.
<lightlike>
at least most nodes that are reliably online - fwiw, a new node I started reached the maximum of inbound connections within ~1.5 months.
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 248 seconds]
_apex_ has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
_apex_ has quit [Ping timeout: 244 seconds]
brunoerg has joined #bitcoin-core-dev
<vasild>
yes
theStack has quit [Quit: theStack]
theStack has joined #bitcoin-core-dev
<vasild>
for now I am trying to verify this claim "transaction announcements account for 30–50% of the overall Bitcoin traffic" from the erlay paper (https://arxiv.org/pdf/1905.10518.pdf)
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
mdguy has quit [Quit: Leaving]
mdguy has joined #bitcoin-core-dev
Zenton has joined #bitcoin-core-dev
<instagibbs>
gleb, ^
AaronvanW has joined #bitcoin-core-dev
<sdaftuar1>
vasild: i think you can ballpark that ratio by looking at inv traffic per transaction versus average transaction size.
halosghost has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 260 seconds]
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #26040: doc: comment "add only reachable addresses to addrman" (master...onlynet_dns-comment) https://github.com/bitcoin/bitcoin/pull/26040
SpellChecker has quit [Remote host closed the connection]
AaronvanW has joined #bitcoin-core-dev
SpellChecker has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] furszy opened pull request #26053: rpc: bugfix, 'add_inputs' default value is true unless 'inputs' are provided (master...2022_rpc_wallet_fix_help_add_inputs) https://github.com/bitcoin/bitcoin/pull/26053
Kaizen_Kintsugi_ has quit [Ping timeout: 244 seconds]
SpellChecker has quit [Remote host closed the connection]
mdguy has quit [Quit: Leaving]
SpellChecker has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 248 seconds]
SpellChecker has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] brunoerg opened pull request #26054: test: verify active chaintip after invalidating an unknown block (master...2022-09-fix-test-invalidateblock) https://github.com/bitcoin/bitcoin/pull/26054