< 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
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e2b55cd20103...18cf1c51652f
< bitcoin-git> bitcoin/master f152c1a fanquake: build: libevent 2.1.12-stable
< bitcoin-git> bitcoin/master 18cf1c5 MarcoFalke: Merge bitcoin/bitcoin#21991: build: libevent 2.1.12-stable
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21991: build: libevent 2.1.12-stable (master...libevent_2_1_12) https://github.com/bitcoin/bitcoin/pull/21991
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/18cf1c51652f...1cc38d3e01c7
< bitcoin-git> bitcoin/master 793b268 Anthony Towns: txmempool: add thread safety annotations
< bitcoin-git> bitcoin/master 1cc38d3 MarcoFalke: Merge bitcoin/bitcoin#22003: txmempool: add thread safety annotations
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22003: txmempool: add thread safety annotations (master...202105-mempoolguards) https://github.com/bitcoin/bitcoin/pull/22003
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/1cc38d3e01c7...ac5f7f47c16f
< bitcoin-git> bitcoin/master 393992b practicalswift: fuzz: Terminate immediately if a fuzzing harness ever tries to create a TC...
< bitcoin-git> bitcoin/master ac5f7f4 MarcoFalke: Merge bitcoin/bitcoin#21936: fuzz: Terminate immediately if a fuzzing harn...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21936: fuzz: Terminate immediately if a fuzzing harness tries to create a TCP socket (belt and suspenders) (master...terminate-on-tcp-socket) https://github.com/bitcoin/bitcoin/pull/21936
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ac5f7f47c16f...eb4df9a628bd
< bitcoin-git> bitcoin/master bbbb518 MarcoFalke: fuzz: Speed up transaction fuzz target
< bitcoin-git> bitcoin/master eb4df9a MarcoFalke: Merge bitcoin/bitcoin#22004: fuzz: Speed up transaction fuzz target
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22004: fuzz: Speed up transaction fuzz target (master...2105-fuzzTx) https://github.com/bitcoin/bitcoin/pull/22004
< 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
< vasild> Approach ACK :)
< Kiminuo> https://github.com/bitcoin/bitcoin/pull/21850/checks?check_run_id=2637023151 - Guys, is this a genuine error or is it that timeout issue? I tend to think it's an error on my side but I can see "Test function timed out" and that confuses me a bit.
< 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 :)
< bitcoin-git> [bitcoin] hebasto opened pull request #22014: Make m_cs_fee_estimator non-recursive (master...210521-fees) https://github.com/bitcoin/bitcoin/pull/22014
< 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
< vasild> https://tox.chat/faq.html may be relevant - it is decentralized p2p chat
< vincenzopalazzo> Another alternative can be https://matrix.org/
< 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
< hebasto> achow101: \o/
< provoostenator> achow101: 0.19 is end of maintenance: https://bitcoincore.org/en/lifecycle/
< 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
< achow101> wallet meeting?
< achow101> #startmeeting
< core-meetingbot> Meeting started Fri May 21 19:02:57 2021 UTC. The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< achow101> #bitcoin-core-dev Wallet Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd phantomcircuit promag
< achow101> provoostenator ryanofsky sdaftuar sipa vasild wumpus
< provoostenator> briefly hi
< achow101> anyone have anything wallet to talk about?
< provoostenator> Mmm, maybe 1 topic: RBF
< provoostenator> Not related to the recent isseu
< provoostenator> I couild use feedback on #21576
< gribble> https://github.com/bitcoin/bitcoin/issues/21576 | rpc: bumpfee signer support by Sjors · Pull Request #21576 · bitcoin/bitcoin · GitHub
< provoostenator> And #22007
< gribble> https://github.com/bitcoin/bitcoin/issues/22007 | wallet: add destination (output) and bump fee · Issue #22007 · bitcoin/bitcoin · GitHub
< achow101> interesting
< provoostenator> And we still need to figure out how to allow fee bumping without change address.
< achow101> I thought we already did that?
< provoostenator> I don't believe so, there's no subtract_fee_from_output like option
< achow101> oh, you mean when the transaction used subtract fee from outputs
< provoostenator> Yes, e.g. when sending a single UTXO to another wallet or exchange.
< achow101> yeah, it assumes that the recipient amounts remain unchanged
< provoostenator> I guess that would be a simple matter of adding such an option
< achow101> right
< achow101> perhaps the wallet should also track this information so it doesn't require the user to provide it all the time?
< provoostenator> The only ambiguity is whether to inlcude the change output in the count.
< provoostenator> And I think we shuffle outputs?
< achow101> no, outputs aren't shuffled
< provoostenator> I also think tracking which output is intended as change helps.
< provoostenator> But we can also just tell
< achow101> we need better tx metadata in general
< provoostenator> The descriptor tells us which address is inside the wallet.
< jonatack> hi
< achow101> we would need to track that for the gui bumpfee to work
< provoostenator> The GUI bumpfee can also use the dscriptors to figure out which output is change?
< achow101> we already figure out which output is change
< provoostenator> (probably hidden away by the wallet interface)
< achow101> There's an IsChange function somewhere that works ok
< achow101> but I meant subtract fee from outputs
< provoostenator> Right, which we can't know for sure.
< provoostenator> So indeed would have to track.
< achow101> yeah, we're oging to need some tx tracking changes, so this could be a larger project
< provoostenator> Meh.... but yeah
< achow101> any other topics?
< provoostenator> Regarding #21576
< gribble> https://github.com/bitcoin/bitcoin/issues/21576 | rpc: bumpfee signer support by Sjors · Pull Request #21576 · bitcoin/bitcoin · GitHub
< provoostenator> I find the distinction between bumpfee and psbtbumpfee not ideal for external signers
< provoostenator> But maybe someone can suggest something int he comments.
< achow101> the idea of external signer support is that all of the normal wallet things should work as if normal
< achow101> so it makes sense to me that it would be part of bumpfee
< achow101> and bumpfee should just be calling the signer directly, like send
< provoostenator> Ok, well that's what the PR does
< provoostenator> Code reuse could be improved perhaps, but that's another matter.
< achow101> sure
< provoostenator> Alright, other topic
< provoostenator> (I don't have one)
< achow101> only thing I've got is that I opened up a few PRs yesterday for more coin selection changes
< achow101> I'm almost done with my coin selection overhaul
< achow101> but we first need #17331 since everything depends on that. if people could review it, that would be great
< gribble> https://github.com/bitcoin/bitcoin/issues/17331 | Use effective values throughout coin selection by achow101 · Pull Request #17331 · bitcoin/bitcoin · GitHub
< jonatack> achow101: nice. i'm sorry to have been remiss in reviewing, am in week three of five weeks of chaincode study groups.
< jonatack> provoostenator: achow101: feature freeze in 3 weeks. what are your targets for inclusion?
< provoostenator> I'll see if I can bring up the courage and mental energy to review coin selection PR's again :-)
< achow101> jonatack: my current target is 17331
< jonatack> that one will be in v22 it seems, but after?
< provoostenator> I'd like to see HWW GUI support make it in, but we'll see.
< achow101> I'd like to close out the coin selection project and move back to descriptor wallet migration
< jonatack> good to know
< provoostenator> sipa: when taproot wallet rebase?
< achow101> any other topics?
< sipa> provoostenator: right now!
< sipa> i just noticed
< achow101> it'd be nice to get taproot wallet for 22.0, do you think we can get it before feature freeze?
< provoostenator> At least on signet it would be nice
< provoostenator> We should probably mark those descriptors as experimental though.
< provoostenator> Or maybe not, it's simple enough.
< provoostenator> I'll give it a review soon(tm).
< achow101> same
< luke-jr> isn't 22.0 before Taproot activates?
< provoostenator> Just needs musig(2) and add_sig support
< achow101> luke-jr: yes
< provoostenator> luke-jr: it's active on signet
< fjahr> hi (spam made me ignore notifications)
< provoostenator> Which is a nice place to test wallets
< achow101> luke-jr: I think we discussed at the last meeting that tr() descriptors can only be imported, and only after activation
< provoostenator> Might need a footgun shield on testnet and mainnet.
< achow101> anything else?
< jonatack> link to the discussion conclusion ^
< achow101> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Fri May 21 19:33:26 2021 UTC.
< 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