19:00:29 <wumpus> #startmeeting 
19:00:29 <core-meetingbot> Meeting started Thu Feb 18 19:00:29 2021 UTC.  The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:29 <core-meetingbot> Available commands: action commands idea info link nick
19:00:34 <sipa> hi
19:00:34 <achow101> hi
19:00:35 <warren> hi
19:00:41 <wumpus> hi
19:00:49 <glozow> hi
19:00:59 <wumpus> #bitcoin -core-dev 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
19:01:01 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:01:15 <fanquake> HI
19:01:19 <MarcoFalke> hi
19:01:21 <meshcollider> hi
19:01:21 <wumpus> no proposed meeting topics in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
19:01:28 <MarcoFalke> fanquake !!!
19:01:34 <wumpus> any last minute proposals?
19:01:49 <fanquake> MarcoFalke: !!
19:02:01 <MarcoFalke> So many Australians lately
19:02:02 <fjahr> hi
19:02:36 <luke-jr> hi
19:02:39 <wumpus> #topic High priority for review
19:02:40 <core-meetingbot> topic: High priority for review
19:02:55 <achow101> proposed topic: would we merge a proposal from the taproot activation meetings?
19:02:59 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  has 6 blockers, no bugfixes, 2 chasing concept ACK
19:03:26 <jnewbery> hi
19:03:48 <wumpus> anything to add/remove/ready for merge? (except for #16546 which is almost there)
19:03:50 <gribble> https://github.com/bitcoin/bitcoin/issues/16546 | External signer support - Wallet Box edition by Sjors · Pull Request #16546 · bitcoin/bitcoin · GitHub
19:03:57 <midnight> HI!
19:05:01 <glozow> can i haz #21146 please? I need for #20833
19:05:03 <gribble> https://github.com/bitcoin/bitcoin/issues/21146 | validation/coins: limit MemPoolAccept access to coins cache + make it responsible for uncaching by glozow · Pull Request #21146 · bitcoin/bitcoin · GitHub
19:05:09 <gribble> https://github.com/bitcoin/bitcoin/issues/20833 | rpc/validation: enable packages through testmempoolaccept by glozow · Pull Request #20833 · bitcoin/bitcoin · GitHub
19:05:20 <fanquake> I would like to leave a few comments on #16546 yet. (tomorrow)
19:05:24 <gribble> https://github.com/bitcoin/bitcoin/issues/16546 | External signer support - Wallet Box edition by Sjors · Pull Request #16546 · bitcoin/bitcoin · GitHub
19:05:33 <MarcoFalke> can i hax #20556? It is blocking my progress on rpc docs
19:05:35 <gribble> https://github.com/bitcoin/bitcoin/issues/20556 | rpc: Properly document return values (submitblock, gettxout, getblocktemplate, scantxoutset) by MarcoFalke · Pull Request #20556 · bitcoin/bitcoin · GitHub
19:05:40 <wumpus> glozow: added
19:05:56 <glozow> wumpus: thank you!
19:06:34 <wumpus> MarcoFalke: added
19:06:40 <MarcoFalke> thx!
19:07:23 <wumpus> anything else?
19:07:59 <wumpus> we've been almost running out of blockers this week :)
19:09:00 <wumpus> #topic would we merge a proposal from the taproot activation meetings (achow101)
19:09:00 <core-meetingbot> topic: would we merge a proposal from the taproot activation meetings (achow101)
19:09:26 <achow101> A question that came up during the taproot activation meetings was whether we would merge whatever activation parameters were decided
19:09:39 <achow101> notably the question was whether a lockinontimeout=true parameter would be merged
19:10:21 <sdaftuar> that seems like an odd question -- woulnd't we just follow our usual practice of review and discussion?
19:10:34 <luke-jr> achow101: also questionable if LOT=false would be merged
19:10:36 <fjahr> I guess someone can open a PR with the meeting results as an argument and then it goes through review?
19:10:38 <wumpus> right, simply PR it
19:10:46 <provoostenator> (hi)
19:10:49 <luke-jr> sdaftuar: protocol changes are not for developers to decide, only follow; same as with miners
19:10:50 <achow101> I have no doubt that the code itself would go through the normal review process
19:11:06 <sdaftuar> luke-jr: no one here is obligated to accept decisions from anyone else
19:11:06 <achow101> I suppose what I'm asking is more of would developers have opinions about the parameters themself
19:11:27 <achow101> that would prevent the merging of the params if all the code was fine
19:11:31 <wumpus> no, i have no opinions about that
19:11:41 <luke-jr> sdaftuar: to implement a protocol distinct from what the Bitcoin community defines for Bitcoin would constitute ceasing to be a Bitcoin implementation
19:11:48 <provoostenator> achow101: no floats
19:11:52 <luke-jr> provoostenator: lol ☺
19:12:20 <bitcoin-git> [bitcoin] fanquake closed pull request #21225: doc: Remove dead whitepaper link from README (master...doc_remove_whitepaper_link) https://github.com/bitcoin/bitcoin/pull/21225
19:12:59 <michaelfolkson> I'd like to make clear that multiple Bitcoin Core contributors effectively NACKed lot=true in the meeting and as far as I could make out only one Bitcoin Core contributor effectively NACKed lot=false
19:13:17 <sdaftuar> luke-jr: PRs that have consensus get merged. i don't understand what we are discussing -- proposing that we merge something that doens't have consensus?
19:14:27 <meshcollider> I don't think there's any world in which this won't be a controversial PR somehow
19:14:30 <luke-jr> sdaftuar: Segwit did not have consensus.
19:14:36 <provoostenator> (off topic: feature_blockfilterindex_prune.py is consistently failing on master for macOS CI)
19:14:49 <sipa> just open a PR, details can be discussed there
19:14:55 <MarcoFalke> provoostenator: File an issue? ;)
19:15:03 <provoostenator> So much for "once we get rid of Travis, paradise"
19:15:10 <provoostenator> Doing so
19:15:12 <luke-jr> O.O
19:15:17 <jonasschnelli> hi
19:15:53 <MarcoFalke> provoostenator: Bugs in our tests can't be fixed by the platform the run on
19:15:58 <MarcoFalke> *they
19:16:48 <jeremyrubin> things like "timeout lack of output" can be tho tbf
19:17:12 <jeremyrubin> but I guess it's semantic on what you consider the bug in the test
19:17:20 <luke-jr> all we can do is fix it and prioritise review of the fix
19:17:32 <achow101> sdaftuar: my question is to inform whether, during the taproot activation meetings, we should be considering whether the activation parameters that get decided on would not be merged due to opinions of those parameters by developers who were not present in those meetings
19:17:55 <sdaftuar> achow101: i would think that the whole community's views should be considered, including those of people not present
19:18:55 <michaelfolkson> The advice given (I think by achow101) was that if Core contributors had strong views either way they would have attended the meeting. I don't think this is necessarily the case if they didn't think it was a productive use of time
19:18:56 <achow101> i agree they should be considered, but I don't think that they should be only considered at the time a pr is proposed
19:19:01 <luke-jr> sdaftuar: but refusing to speak up publicly, either there or here, makes that impractical ;)
19:19:06 <jeremyrubin> as someone who was not present, but has a view, I felt that I've made my views relatibvely clear beforehand and did not need to attend a meeting
19:19:30 <achow101> and such an opinion could nack that pr and cause it to not be merged
19:19:33 <luke-jr> jeremyrubin: I have no idea what your views are fwiw
19:19:42 <michaelfolkson> Tbf I haven't heard your view either on LOT jeremyrubin
19:19:58 <jeremyrubin> Ok
19:20:10 <luke-jr> and I doubt most at the meetings did
19:20:44 <jeremyrubin> I'm just lending credence to the notion that non participation at the meeting != would have attended meeting
19:21:28 <michaelfolkson> Basically strong views exist but they weren't present to voice them at the meeting (I'm hearing)
19:21:39 <michaelfolkson> Which is fine, that is what I assumed
19:23:01 <luke-jr> (otoh even among the ~100 who did go to the meeting, consensus seems impractical, so I'm not sure adding more people to the mix is going to help anything at this point)
19:23:15 <achow101> What I want to avoid is having activation parameters be proposed in a pr that gets shot down by someone with strong opinions who didn't participate in various discussions about those parameters
19:24:20 <michaelfolkson> Again, I can only voice my personal opinion from what I've heard so far which is if LOT is going to be set in Core the only viable option at this stage is false (based on effective NACKs)
19:24:45 <wumpus> i don't think you can avoid that in practice, if you open a PR there's going to be discussion there
19:25:05 <wumpus> no one can pre-bless anything
19:25:08 <jeremyrubin> I think that if something is to be read as nacked, a PR should just be opened for it so people can leave a formal comment
19:26:25 <provoostenator> I think IRC meetings are good for brainstorming and maybe exchanging some ideas, but mailinglist seems more appropriate
19:26:58 <michaelfolkson> provoostenator: Agreed, strong views welcome on the mailing list
19:27:23 <sdaftuar> achow101: i think if a proposal really has consensus this should not be a big concern. details can be worked out if a proposal is fundamentally reasonable. just my two cents.
19:29:24 <wumpus> are there such disparete, incompatible ideas about activation parameters then, that there's fear no one will find agreement?
19:30:16 <luke-jr> wumpus: it seems there is consensus on everything except LOT
19:31:07 <luke-jr> (which is fairly even split)
19:31:53 <michaelfolkson> luke-jr wumpus: Again in terms of effective NACKs from Core contributors it was more one sided in favor of LOT=false
19:31:53 <wumpus> right
19:32:22 <michaelfolkson> But agreed, no clear community consensus
19:32:26 <wumpus> it didn't seem it would be so difficult for taproot
19:32:38 <luke-jr> I don't think it's even related to taproot itself at this point
19:33:24 <wumpus> i suppose everyone discussing activation parameters at leas has in common that they want it activated :)
19:33:43 <jeremyrubin> luke-jr: sorry was looking for my last comments; back on july 17th 2020 I agreed that LOT=true makes much more sense
19:34:19 <jeremyrubin> i haven't seen any arguments since then to have changed my mind substantially
19:34:27 <jeremyrubin> (in ##taproot-activation)
19:34:32 <michaelfolkson> Lots of light support for LOT=true in the meeting too jeremyrubin. Would you effectively NACK LOT=false?
19:34:47 <sipa> can we keep the discussion itself elsewhere?
19:35:05 <michaelfolkson> Sure. To ##taproot-activation if you have views
19:35:14 <sipa> someone come up with a proposal, send it to the list, and open a PR
19:35:31 <wumpus> yes
19:35:41 <wumpus> any other topics?
19:37:06 <wumpus> #endmeeting