< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #20962: Alter the ChaCha20Poly1305@Bitcoin AEAD to the new specification (master...2020/12/aead_v2) https://github.com/bitcoin/bitcoin/pull/20962
< shesek>
not sure if worth fixing, but v0.21 appears to use a generic error code of -1 when the deprecated `generate` command is called with arguments, rather than the -32601 code (RPC_METHOD_NOT_FOUND)
< wumpus>
I was doubtful about it but also about any action to 'fix' it now, this is purely a user-facing message, it should be irrelevant to software, which shouldn't already have been calling that RPC for years :)
< wumpus>
(but apparently it does!)
< wumpus>
just a surprise to me
< shesek>
wumpus, rust-bitcoincore-rpc's integration tests call it and explicitly check that it works in <18.0, returns a deprecation message in <19.0 and a 'not found' error for newer versions
< wumpus>
(see discussion with jeremyrubin around 2021-01-13 21:27:34)
< shesek>
its not actually used for anything, just tests that it got deprecated properly
< shesek>
what does 'unreachable' mean as the network in getpeerinfo?
< wumpus>
jonatack etal: does anyone know what gitian signer name "Nils Schneider" used (subdirectory name in gitian.sigs)? I think he goes by "tcatm" but can't find anything
< wumpus>
looking at the history of both gitian.sigs and contrib/gitian-keys/keys.txt in the repository didn't help me
< wumpus>
if there's nothing, we should delete the fingerprint from keys.txt
< wumpus>
but likely there is, I could try batch verifying *all* signatures in gitian.sigs and seeing if the fingerprint turns up
< wumpus>
shesek: where do you see that?
< wumpus>
shesek: it would be really strange to see that, after all, if you have a peer it's reachable by definition, so if you see it that's a bug (can't find it with a grep in the codebase though)
< shesek>
it was 'unroutable' rather than 'unreachable'
< wumpus>
uhm... that's unexpected, please report an issue
< wumpus>
my gut feeling is that it's based on a confusion between 'what P2P addresses we want to gossip' and 'what is a valid network address'
< aj>
"unroutable" is what it returns for local addresses (127.0.0.1, ::1) ?
< wumpus>
yes, that's a possibility, which would be understandable but strictly wrong :)
< aj>
strictly it'd be correct, though? you can't *route* a local address, even if you can deliver it? :)
< wumpus>
internal routing in the OS is still routing (imo)
< aj>
well, code seems to choose NET_UNROUTABLE for IsLocal() pretty deliberately. NET_LOCAL would seem a lot saner to me
< wumpus>
it depends on what you see as definition of *network*, I mean if it's things like IPv4, IPv6, Tor, i2P, then returning 'local' is weird as it's not a network nor addressing scheme
< wumpus>
but a policy decision
< wumpus>
any address can be local if it's configured like that at the OS level, we don't know
< wumpus>
likely what someone wants to see in 'network' in the peers list is through what *kind of networking* the connection happens, at least, i would, a local connection on IPv4 is IPv4
< wumpus>
if we'd have a UNIX socket for local connections it's be 'unix'
< wumpus>
then again I suppose that's subjective up to a point, it would be just my expectations, i'm not sure this is constructive :)
< shesek>
I would personally be fine either way, as long as this gets documented :)
< aj>
well, "why does a connected peer get listed as `unroutable`" and "how should a connection to localhost be described, given we treat it special (for net groups at least)" are different questions...
< wumpus>
we treat it as special for gossiping in the P2P network
< wumpus>
obviously we want to gossip only globally routable addresses
< wumpus>
I agree that's a completely different thing from *what network is this*, that was my point
< aj>
how quickly we disconnect it when we've got lots of peers, too, i think
< wumpus>
yes, another policy decision
< vasild>
/// Addresses from these networks are not publicly routable on the global Internet.
< vasild>
NET_UNROUTABLE = 0,
< vasild>
according to this definition 127.0.0.1 or 10.0.0.1 is not routable
< wumpus>
not *publicly* routable
< wumpus>
it's an important distinction
< shesek>
it would be nice if 'wallet already loaded' errors had a unique error code. the error message changed in v0.21 so now my code needs to check for two messages >_<
< shesek>
though, if you do a new error code and I want to retain backwards compatibility, my code will have to check for two error messages plus an error code, which isn't better I guess lol
< bitcoin-git>
[bitcoin] laanwj opened pull request #20963: gitian-linux: Build binaries for 64-bit POWER (continued) (master...2021-01-power) https://github.com/bitcoin/bitcoin/pull/20963
< wumpus>
huh i'm seeing really weird behavior on github when editing my post lately: the post first appears edited, then quickly snaps back to the old version, but a reload of the page does show the new version
< wumpus>
shesek: agree, feel free to add more error codes if that helps, parsing messages should be avoided at all costs
< wumpus>
do not rely on RPC messages, they for human consumption only and are not part of what is considered the interface
< shesek>
right, I am using the error code when possible, this is the only case I had to resort to identifying the string
< wumpus>
if you really have to match on the message, i think it's best to match on the *entire* message, not try to do fuzzy matching, this makes it immediately apparent if something changed in a future version
< wumpus>
anyhow let's add a RPC code
< jonatack>
wumpus: re Nils Schneider, git grepping i see many "tcatm" but git grep -ni, say, for "nil\|schn\|eid" doesn't turn up much of use IIUC ... so I dunno
< jonatack>
wumpus: i'm afraid i was confused about the alias names though
< wumpus>
jonatack: Nils is the only person i cannot find in gitian.sigs at all
< wumpus>
for the others i found out what name they used for adding to gitian.sigs
< wumpus>
so the question re: #20958 would be: remove his entry, or keep it like this without a known signer alias
< jonatack>
shesek: i'm responsible for both issues you reported :) i recently added a functional test for NET_UNROUTABLE in test/functional/feature_proxy.py that does assert on getpeerinfo#network returning "unroutable". maybe it should be added to the getpeerinfo help that currently states "Network (ipv4, ipv6, or onion) the peer connected through"...along with i2p and cjdns maybe as well
< jonatack>
...as they are already in enum Network too
< jonatack>
and maybe netbase.cpp:GetNetworkName() should return something more helpful than just "unroutable"
< bitcoin-git>
[bitcoin] laanwj opened pull request #20964: rpc: Add specific error code for "wallet already loaded" (master...2021-01-wallet-already-loaded-rpc) https://github.com/bitcoin/bitcoin/pull/20964
< wumpus>
shesek: ^^
< shesek>
wumpus, that's great, thank you!
< shesek>
I'm using this in bitcoin wallet tracker and not rust-bitcoincore btw
< wumpus>
this is weird, I force-pushed a change to change the code from -20 (which was already used) to -35, but github is not picking it up *shrug*
< wumpus>
github is not my friend today
< vasild>
s/today//
< vasild>
I have lost some (long) text I entered in github comments' box. It is good idea to ctrl+a ctrl+c after entering some text and before clicking anything on the github ui
< wumpus>
same, i always copy/paste longer spans of text into an editor just in case, that's far from just github though :)
< wumpus>
the web has always been great at making text input disappear
< wumpus>
i've never had it miss a push though
< wumpus>
oh it's there now (checking on another pc)
< vasild>
that's true :)
< vasild>
I use a browser extension which fires an external editor to edit a textbox and leaves the temp file afterwards
< vasild>
that is - after quitting from the editor the contents appears in the textbox and there is also some temp file on the filesystem somewhere
< bitcoin-git>
[bitcoin] jonatack opened pull request #20965: net, rpc: return NET_UNROUTABLE as not_publicly_routable, update rpc helps (master...update-network-info) https://github.com/bitcoin/bitcoin/pull/20965
< jonatack>
shesek: ^^ ... proposed NET_UNROUTABLE to be returned in the RPCs as "not_publicly_routable" and updated the getpeerinfo and getnetworkinfo helps
< shesek>
jonatack, awesome, thanks :)
< wumpus>
vasild: heh I too had an extension for that a loong time ago, but there's so much drift in browsers and extensions and what they can do (e.g. firefox added all kinds of protections, dunno if launching an external process is allowed?), nowadays i just do it manually
< wumpus>
not_publicly_routable makes sense
< vasild>
wumpus: actually, my experiense is the same - I used vimperator for a long time until firefox made some changes and broke it beyond repair.
< wumpus>
i still think *routability* is a bit of a weird response for a network type, then again, if the point of RPC is to expose some internal state that already exists it makes sense
< wumpus>
shesek: btw something to keep in mind is that the duplicate load message currently only exists for bdb wallets, not mysql ones
< wumpus>
sqlite*
< wumpus>
sqlite wallets have no way to detect duplicate wallets at the moment, and it's unclear whether they will have this, as this is a bit of a point of controversy
< bitcoin-git>
[gui] prusnak opened pull request #189: qt: drop workaround for QTBUG-42503 which was fixed in Qt 5.5.0 (master...qtbug-42503) https://github.com/bitcoin-core/gui/pull/189
< wumpus>
nah given how long that PR is already in the backlog :)
< wumpus>
if no one is impatient about it, it'll likely never make it in
< wumpus>
jonatack: I ran *all* the .sig files in gitian.sigs through gpg --verify; none of them is signed with Nils' key. I suggest we remove his entry from keys.txt.
< luke-jr>
I'd have gotten around to it after 0.21 ;)
< wumpus>
and retweeted it from my main and bitcoincoreorg's account on twitter, so that should distribute it pretty widely
< achow101>
thanks!
< phantomcircuit>
achow101, your survey is too long to get responses from 99% of people
< sipa>
"good, less results to read through!"
< achow101>
phantomcircuit: perhaps. I trust that the actual researchers I worked on this with know what they're doing and understand optimal survey lengths
< phantomcircuit>
achow101, likely they're used to conducting paid surveys or surveys over the phone where people feel trapped
< phantomcircuit>
i got bored and i was only 30% of the way through it
< achow101>
the percentage things are really misleading
< achow101>
there's only 2 pages of actual questions
< sipa>
When you run into problems with your Core Node, how do you usually troubleshoot those problems? *This question is required.
< sipa>
is "add printf's" a good answer?
< achow101>
sure
< achow101>
or "by myself without external help"
< belcher>
let us know about the results
< achow101>
belcher: that's the plan
< phantomcircuit>
sipa, git blame | grep jgarzick
< phantomcircuit>
that's no joke the first thing i do when i run into a bug in something
< sipa>
i don't think "Scripting / automation" or "RPC restore" mean much to people who don't already have detailed understandingh
< achow101>
phantomcircuit: ha
< wumpus>
yea same here, either gdb (in case of a crash) or adding logging (in csae of something that's harder to narrow down)
< wumpus>
in rare cases enabling one of the current logging flags is enough
< fanquake>
wumpus / sipa: can you block samsungbiologics if not already
< jonatack>
achow101: filled out the survey. seems pretty advanced but i imagine it's hard to calibrate. thanks for doing this, curious to see the results.