< bitcoin-git>
[bitcoin] hebasto opened pull request #16436: Do not create payment server if -disablewallet option provided (master...20190722-payment-server) https://github.com/bitcoin/bitcoin/pull/16436
< jb55>
how common are 500 errors when doing reviews. dang that is annoying
< dongcarl>
same here...
< hebasto>
and here...
< dongcarl>
jonasschnelli: Did you install from depends?
< dongcarl>
jonasschnelli: Did you install multilib fontconfig?
< jonasschnelli>
dongcarl: depends... yes. I only did "apt install xorg" on the x86 host.
< jonasschnelli>
How do I install multilib fontconfig?
< dongcarl>
jonasschnelli: You're on Ubuntu?
< dongcarl>
jonasschnelli: I think... `apt-get install libfontconfig1:i386`
< dongcarl>
Does `bitcoin-qt` start at least?
< dongcarl>
Or not even
< jonasschnelli>
dongcarl: I haven't tried... only make check with start that minimal qt tests
< jonasschnelli>
let me try libfontconfig1:i386
< dongcarl>
jonasschnelli: Let me know 1. If `bitcoin-qt` starts by itself 2. what the output of `ldd bitcoin-qt` is
< cfields>
gitian builders: detached sigs for v0.18.1rc1 are up
< jonasschnelli>
dongcarl: its running in the CI,... need to change things in order to do that... but let me check
< jonasschnelli>
thanks cfields
< hebasto>
gh seems down...
< cfields>
jonasschnelli: I'll close the PR when github decides to start doing stuff again.
< jb55>
I'll review someone's PR if they email me the patchset with git-send-email :]
< jb55>
*decentralized*
< jonasschnelli>
dongcarl: E: Unable to locate package libfontconfig1:i386
< dongcarl>
jonasschnelli: btw just so you're aware, we have #bitcoin-builds
< jonasschnelli>
dongcarl: oh. Yeah. I should join there I guess.
< dongcarl>
:-)
< Raystonn>
What's the current mindset on Rust? Any plans to analyze its potential use in portions of Core?
< jb55>
Raystonn: seems unlikely, the engineering effort required for maintaining two different compilers/languages/codebases would be super janky.
< provoostenator>
dongcarl: are the guix instructions supposed to work for 0.18.1 as well? Building Docker now, so can compare...
< dongcarl>
provoostenator: I haven't backported to 0.18.1 yet, but good reminder that I should allow building of any bitcoin git repo, not just the current tree!
< provoostenator>
Ok, just tag me if you need testing...
< dongcarl>
provoostenator: <3
< dongcarl>
will do!
< emilengler>
In which file/function the blockchain is being downloaded?
< dongcarl>
wumpus: In addrv2, couldn't we save 1 byte per address if we don't encode the `addr` as a `std::vector`? If I'm understanding correctly, encoding `std::vector` means encoding a VarInt for the length first, then the contents, but we can infer the size of `addr` from `networkID`, right?
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16437: Always connect NotifyEntryRemoved with MempoolEntryRemoved (master...1907-AlwaysNotifyMempoolEntryRemoved) https://github.com/bitcoin/bitcoin/pull/16437
< sipa>
dongcarl: the mapping between network id and length isn't known for unknown network ids
< sipa>
and old clients must be able to deserialize addresses of unknown network ids i think
< sipa>
elichai2: seems my math was off, 1B signature validations at 5us/sig is 50k seconds, not 500k seconds
< elichai2>
with or without libgmp?
< sipa>
not relevant :)
< sipa>
my math was off
< sipa>
by a factor 10
< luke-jr>
Raystonn: Rust can't be securely bootstrapped, so that seems like a bad idea for now
< cfields>
Uhh, I pushed the detached sigs to github, but I don't see them now. Maybe they got lost in the downtime?
< cfields>
Did anyone manage to fetch the v0.18.1rc1 tag from bitcoin-detached-sigs ?
< * cfields>
pushes again
< dongcarl>
sipa: Does this matter if we're going to be introducing a new message type? Old clients won't understand this new message type...
< sipa>
dongcarl: that's not what i'm talking about
< sipa>
i mean when say Torv4 is introduced
< dongcarl>
Right
< sipa>
post-addrv4 but pre-torv4 clients won't understand it
< dongcarl>
s/post-addrv4/post-addrv2/
< sipa>
yeah
< dongcarl>
If they don't understand it... why can't they just drop that address?
< sipa>
because they can't deserialize _anything_
< sipa>
you send them an addr with 1000 addresses in it, if there is only one torv4 in there, they can't deserialize the whole vectors
< dongcarl>
sipa: Ah! That would be unfortunate...
< luke-jr>
maybe the entire field (not just the address) should be given the length?
< dongcarl>
luke-jr: What would be the benefit of doing that?
< luke-jr>
dongcarl: you could skip each address object if you didn't understand it, whether the confusion is part of the address itself or anything else
< luke-jr>
elichai2: mrustc only works on backdoored CPUs
< sipa>
i think the biggest concern with rust is introducing a new programming language to the project few contributors are familiar with
< emilengler>
Can someone with permission restart this job?
< Raystonn>
luke-jr: I assume you mean only on Intel or AMD CPUs?
< luke-jr>
Raystonn: yes
< Raystonn>
luke-jr: Is your Bitcoin Core development platform running an ARM processor?
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #16438: travis: Print memory and number of cpus (master...1907-travisFreeProc) https://github.com/bitcoin/bitcoin/pull/16438
< luke-jr>
Raystonn: PPC64
< Raystonn>
What CPUs, or CPU manufacturers, do you trust?
< luke-jr>
IBM POWER9 in this case
< Raystonn>
If we really want to verify, we'd need to start with RISC-V, no?
< luke-jr>
afaik POWER is more open than RISC-V at the moment