< bitcoin-git>
[bitcoin] achow101 opened pull request #22009: wallet: Decide which coin selection solution to use based on waste metric (master...cs-waste-2) https://github.com/bitcoin/bitcoin/pull/22009
< bitcoin-git>
[bitcoin] ajtowns opened pull request #22013: net: ignore block-relay-only peers when skipping DNS seed (master...202105-ignoreblockrelayfordnsskip) https://github.com/bitcoin/bitcoin/pull/22013
< wumpus>
it doesn't seem that the IRC bot (https://github.com/gkrizek/ghi) currently supports notification to multiple different IRC servers, so it's going to be a hard switch-over at some point
< wumpus>
after next week's meeting maybe
< vasild>
< jonatack> and working on removing v2 support
< Kiminuo>
'Error: Specified blocks directory "" does not exist." this probably leads to the timeout
< Kiminuo>
other PRs pass tests, so it's my issue most likely. nvm
< wumpus>
vasild: imo the simplest one "rip out v2 support completely, drop existing v2 addresses from addr.dat, stop relaying them", no options (either compile time or runtime) and other added complexity unless there is a very good reason, which i don't think there is
< Kiminuo>
right, my bad
< wumpus>
Kiminuo: glad you managed to figure it out so quickly :)
< vasild>
wumpus: I agree - no options that later need to be deprecated and removed themselves.
< wumpus>
right
< vasild>
s/addr.dat/peers.dat/
< Kiminuo>
It's my bad. Too many boolean changes.
< wumpus>
we're already pretty late, a longer and more subtle transition period might have made sense if it would be years, but not now
< vasild>
right
< wumpus>
vasild: correct
< vasild>
"dropping torv2 support" - is this a feature that needs to go in before Jun 15? Is removing a feature a feature itself? ;-)
< vasild>
it is not a bugfix, maybe the changes to the code will be non-trivial, I guess should be subject to feature freeze?
< wumpus>
yes, though it may be one of the few things important enough to delay the feature freeze if it is not in by then
< wumpus>
let's just make sure it is
< wumpus>
at least it's something where the direction is clear and would be good to put this behind us :)
< jonatack>
vasild: wumpus: agree, drop v2 addrs from peers.dat, stop relaying them, no options
< vasild>
+ ignore incoming torv2, relayed to us
< vasild>
or ban the peer who relayed the junk to us :-D
< jonatack>
right :)
< jonatack>
was in touch with ggus, asking for any update if the deprecation schedule changes and he's prepared to coordinate with bitcoincore.org, optech, etc. on announcements. reminder from him to send your email for invite to next friday's online AMA if interested
< jonatack>
"Next Friday, May 28th, 1600 UTC, we will have a Tor AMA about v2 onion services deprecation. It's an invite-only event with some onion services operators and developers."
< jonatack>
"we really want to support your community to migrate smoothly to v3 (or less traumatizing as possible). We can coordinate with the Tor Comms team to have social media posts when v2 onion support is removed from bitcoin core."
< real_or_random>
aj: I think your git command is equivalent to git rebase -i --keep-base origin/master ... so --keep-base takes care of this
< vasild>
Is there an IRC alternative that we can use that is e2e encrypted by default? For public channels it is irrelevant, but would be nice to have for direct/private messages
< hebasto>
vasild: signal?
< vasild>
that would be one possibility, I guess
< vasild>
actually, I guess, the problem would be to have everybody to agree on a particular one
< jonatack>
yeah signal (for now), unfortunately it is based on a phone number, and it wants your phone contacts
< vincenzopalazzo>
That is super accessible in my opinion
< wumpus>
the (new) IRC channel could be bridged with matrix if people are interested in that
< wumpus>
i do use matrix for some things
< wumpus>
i'm not sure "being more accessible" is a goal for this particular channel though
< wumpus>
but for say, the gui dev channel it makes sense
< vincenzopalazzo>
wumpus, yeah I read somethings about the brige between IRC channel and matrix
< wumpus>
yes many FOSS project's channels are bridged
< vincenzopalazzo>
I think that the accessibility should be a good things in any case. Give the possibility to all the people to join e read all the event that happen in bitcoin dev is a good starting point I think
< wumpus>
this is very much an internal development channel, we've been quite good at keeping it on-topic and specific
< vasild>
I think IRC is autmatically filtering people that find it hard to setup from joining here and suggesting bitcoin switches to POS or changes the 21M supply...
< wumpus>
that
< wumpus>
for a more support-ish channel it makes sense
< vincenzopalazzo>
Yep I only propose this stuff, sometimes the accessibility doesn't mean "Know how configure" but give the possibility to the people that have to use a external device to read. It is not related much to know how to, but to give the possibility. I think that this was a good moment to point out this "problem"
< vincenzopalazzo>
Want be clear, any problem I'm happy with the IRC filter set up :)
< wumpus>
i would surprised if IRC is inaccessible to screen readers, it's an old, well-known standard with many clients
< wumpus>
fully text based
< wumpus>
modern web app based systems are a much larger challenge to make accessible *in that particular sense*
< vincenzopalazzo>
The web app (know to me) doesn't maintain the state and it is a very common use case when you have some problem and you need an external device to read, you must make double work. here the problem is not IRC that it is not accessible, but the client aren't
< wumpus>
pretty sure people were using IRC with braille terminals and such even when i was a kid
< wumpus>
blind people are also a fairly large share of those playing text-based interactive fiction games; the modern internet focused on video, pictures, avatars, fancy formatting etc isn't *that great* for them
< wumpus>
in any case, getting off topic here sorry
< vincenzopalazzo>
Oh, not a problem! I repeat myself, for me IRC is ok.
< provoostenator>
In case anyone cares: there's a lot less taproot signalling on testnet and it hasn't activated yet.
< provoostenator>
(or locked in)
< achow101>
finally got the windows codesigning cert, should I backport it to all branches or just 0.20 and 0.21?
< achow101>
oh, I guess 0.19 needs a re-release too
< bitcoin-git>
[bitcoin] Sjors opened pull request #22016: rpc: add period_start to version bits statistics (master...2021/05/versionbits_period_start) https://github.com/bitcoin/bitcoin/pull/22016
< provoostenator>
Though not end of life. Might be worth making sure we *can* issue a new release if something really bad needs backporting.
< achow101>
0.19.2 uses the revoked cert
< provoostenator>
I guess it's also nice to have a non-revoked cert on something that's not yet end of life.
< provoostenator>
No idea if I can still gitian build that ancient stuff though.
< bitcoin-git>
[bitcoin] achow101 opened pull request #22017: Update Windows code signing certificate (master...2021-win-codesign-cert) https://github.com/bitcoin/bitcoin/pull/22017
< jonasschnelli>
i missed yesterdays meeting,... as for the codesigning certificate (achow101), the swiss association registration made progress and I think it should be in the register within the next two weeks.
< jonasschnelli>
The question is, if it still makes sense to continue with the Swiss association (have some redundancy)
< jonasschnelli>
The association required a physical address (a service) which costs >1000$/year.
< jonasschnelli>
Happy to keep it and funding is probably not an issue.
< achow101>
it makes sense to have some redundancy if a CA decides to just refuse to issue a cert to one of the orgs. But if it's a requirements change like what we just had, then it might be that both end up being in a position where neither can get a cert
< achow101>
so what probably really needs to happen is that we (I) need to keep an eye on CA/B Forum guideline changes. e.g. in June, it seems like there might be stricter requirements that we will need to follow
< bitcoin-git>
[gui] hebasto opened pull request #342: wallet: Move wallets loading out from the main GUI thread (master...210521-wallet) https://github.com/bitcoin-core/gui/pull/342
< bitcoin-git>
[bitcoin] achow101 opened pull request #22019: wallet: Introduce SelectionResult for encapsulating a coin selection solution (master...selectionresult) https://github.com/bitcoin/bitcoin/pull/22019