< mischa010> hi!
< mischa010> do peers remember which peers were fastest in sending them data, how does this work? are INV's sent to the 'top ranked' peers first? where is the relevant code?
< sipa> mischa010: invs are sent to all peer, period
< sipa> if multiple peers announce the same tx/block to us, we only getdata one of them
< gmaxwell> though inv/getdata is used rarely for blocks and is slow...
< gmaxwell> tx invs are queued to all peers and then the queues are drained at random times.
< gmaxwell> MarcoFalke: re https://github.com/bitcoin/bitcoin/pull/15451 I assume that we broke some altcoin that has other kinds of invs, and the PR author is trying to suggest a comment change that would have avoided his confusion.
< gmaxwell> (other kinds handled via generic getdata-anything-inved logic and not handled by special cases as we do)
< fanquake> promag around today?
< IZooo> hello
< wumpus> helllo
< promag_> fanquake: hi, need something?
< warren> https://github.com/bitcoin/bitcoin/pull/15277 Hoping people can help with what is hopefully a simple environment difference between Ubuntu and this other distro. dongcarl is really close to a deterministic replacement for gitian's toolchain. It may only be a matter of figuring out this linker issue then writing a wrapper around the entire thing.
< luke-jr> warren: FWIW, our current binaries aren't actually portable, so I'm not sure how important a 1:1 match on linkage is
< luke-jr> (I can't run the ones gitian makes)
< warren> luke-jr: oh did you report the issue? what distro are you running on?
< luke-jr> Gentoo, IIRC someone reported it years ago
< warren> are you still using that oddball x32 arch?
< luke-jr> no, never migrated to it, only had it in a chroot for testing (and since gave up on it and deleted)
< luke-jr> I'm pretty sure it's something to blame Gentoo for, but who knows
< warren> I'm guessing this isn't more widespread?
< luke-jr> the glibc ebuild seems to carry some weird patch touching __chk_fail stuff
< luke-jr> dunno
< warren> We should be more concerned about the reason why we've wanted a deterministic toolchain to replace gitian.
< fanquake> promag_ a few thoughts/questions about 15204, but might just put them into the PR
< promag_> #15204
< gribble> https://github.com/bitcoin/bitcoin/issues/15204 | gui: Add Open External Wallet action by promag · Pull Request #15204 · bitcoin/bitcoin · GitHub
< promag_> go ahead
< fanquake> promag_ One is wether we should just be creating a new "wallet" in any directory selected from that menu.
< fanquake> It's not exactly obvious that's what will happen (or if it should be the default behaviour), rather than a "No wallet to load popup/error".
< promag_> it should not create
< fanquake> Right. At the moment I can select any directory on the system, wallet directory or not, and if it's not, it's turned into one.
< promag_> later create wallet can have a "select other destination" or something
< promag_> yeah I know
< promag_> I want to be able to just open, not createOrOpen
< fanquake> Yea, that would be the preferred behaviour
< wumpus> luke-jr: it's also not portable to systems that don't use glibc at all-in my experience the gitian-produced executables work on a wide range of systems in the wild, but undoubtly there's always a limit to portability
< wumpus> and we all know that full static linking has its own slew of issues
< wumpus> the modern way of shipping portable applications for linux are these universal package things such as snap, flatpak, appimage
< wumpus> it prevents issues from the variance in possible environments by running in a predictable environment with predictable versions of libc and other libraries
< gmaxwell> IIRC years ago I tried using bitcoind on a uclibc system (or musl?) but I think I couldn't get boost working.
< luke-jr> I think at least musl has improved a lot since then
< promag> alpine uses musl iirc
< bitcoin-git> [bitcoin] ken2812221 opened pull request #15468: wallet: Use fsbridge::ifstream to fix Windows path issue (master...win-wallet-fix) https://github.com/bitcoin/bitcoin/pull/15468
< mischa010> hi, im trying to understand how peers are ranked, for example, do peers that take less time to transmit things get priority somehow? what's the relevant bit of code?
< mischa010> gmaxwell? :)
< gmaxwell> priority for what?
< mischa010> sending an inv for example
< mischa010> or getting headers
< mischa010> what determines which peer gets one first
< gmaxwell> transaction invs are batched and are done at totally random times... the only real priority there is that the random times are more frequent for outbound peers.
< mischa010> why is it random instead of immediately?
< gmaxwell> because immediately would be toxic for privacy and would waste more bandwidth from INVs crossing in flight (so two peers would INV each other the same txn, which happens quite rarely now)
< mischa010> interesting
< sipa> mischa010: the delay is in the order of a few seconds usually
< mischa010> and blocks? those aren't delayed right?
< sipa> indeed
< mischa010> but there'
< sipa> they're relayed as fast as possible
< mischa010> but there's no peer priority/ranking in relaying blocks? so it's possible a block is relayed to a slow peer instead of the n fastest ones?
< sipa> usually blocks are relayed using compact blocks, which are just a few kb
< sipa> which is too little to cause much contention on most uplinks
< mischa010> but outbound nodes have priority in some cases right?
< mischa010> there's a comment in net_processing.cpp about 'nice' peers
< mischa010> in this thread it's claimed that compact blocks does indeed rank peers by their speed? https://www.reddit.com/r/Bitcoin/comments/5zo2ku/how_do_i_configure_my_node_to_use_highbandwidth/
< mischa010> is this true>
< mischa010> ?
< sipa> every node picks 3 peers which it asks to send compact blocks directly, instead of having them first announce the block
< captjakk> Does anyone know why I would be getting a "connection refused" when connecting my lnd to my remote bitcoind instance
< captjakk> to be clear, I'm talking about the zmq port
< captjakk> also zmq isn't refusing connections from localhost
< captjakk> ufw (ubuntu) has been set to allow the zmq ports as well
< captjakk> looks like my zmq interface was set only to 127.0.0.1
< echeveria> you really don’t want to bind ZMQ to anywhere but local host.
< echeveria> if anyone is telling you otherwise, they’re probably being insanely stupid.
< captjakk_> even if i want to subscribe to zmq updates from a different machine?
< jimpo>
< sipa>
< echeveria> captjakk_: like, don’t.
< echeveria> it’s not authenticated. it’s not secure. it has a large attack surface. use a VPN if you have to.
< sipa> echeveria: within a local network it's fine
< sipa> but don't exoose it to the internet...
< gmaxwell> ZMQ also requires both end be running the same library version, so that also makes it not so attractive for things that aren't very tightly coupled.
< gmaxwell> mischa010: thats why I asked you to be specific earlier.
< gmaxwell> 11:14:57 < mischa010> hi, im trying to understand how peers are ranked, for
< gmaxwell> example, do peers that take less time to transmit things
< gmaxwell> get priority somehow? what's the relevant bit of code?
< gmaxwell> 11:15:20 < mischa010> gmaxwell? :)
< gmaxwell> 11:15:38 < gmaxwell> priority for what?
< gmaxwell> 11:15:46 < mischa010> sending an inv for example
< gmaxwell> INVs aren't used for relaying blocks except as a backwards compatible fallback.
< gmaxwell> Peers request the last three distinct peers to first provide them a block to request to compact blocks to them without first asking (alowing 0.5 RTT transmission in most cases).
< gmaxwell> when a block comes in, those requests are services first-- in partcular because they can be serviced prior to validation.
< gmaxwell> The 'order' doesn't really matter (at least not much) because CB messages are very small (10kb or so), and transmission is non-blocking.
< gmaxwell> I tried before trying to sort sends by the nodes own CB preference, but I was unable to measure an improvement even in a pretty contrived setup, so it wasn't worth PRing.