< bitcoin-git> [bitcoin] fanquake opened pull request #21672: doc: remove boostrap info from GUIX_COMMON_FLAGS doc (master...fixup_guix_options) https://github.com/bitcoin/bitcoin/pull/21672
< bitcoin-git> [bitcoin] fanquake pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/a1f0b8b62eb8...e7af2f35af95
< bitcoin-git> bitcoin/master 54569cc fanquake: refactor: move all signer code inside ENABLE_EXTERNAL_SIGNER #ifdefs
< bitcoin-git> bitcoin/master f4652bf fanquake: refactor: add missing includes to external signer code
< bitcoin-git> bitcoin/master 8fdbb89 fanquake: refactor: unify external wallet runtime errors
< bitcoin-git> [bitcoin] fanquake merged pull request #21666: Miscellaneous external signer changes (master...external_signer_followups) https://github.com/bitcoin/bitcoin/pull/21666
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21675: ci: Only cache depends/sdk-sources for macos task in cirrus (master...2104-ciSdkMacosOnly) https://github.com/bitcoin/bitcoin/pull/21675
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e7af2f35af95...b8e5bbdf93e5
< bitcoin-git> bitcoin/master fadbd99 MarcoFalke: test: Remove spurious double lock tsan suppressions by bumping to clang-12
< bitcoin-git> bitcoin/master fadea0b MarcoFalke: Revert "test: Add tsan supp for leveldb::DBImpl::DeleteObsoleteFiles"
< bitcoin-git> bitcoin/master b8e5bbd MarcoFalke: Merge #21669: test: Remove spurious double lock tsan suppressions by bumpi...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21669: test: Remove spurious double lock tsan suppressions by bumping to clang-12 (master...2104-tsanSupp) https://github.com/bitcoin/bitcoin/pull/21669
< bitcoin-git> [bitcoin] vasild closed pull request #21668: net: properly handle PF_NOBAN in CConnman::Bind() (master...fix_pf_noban_usage) https://github.com/bitcoin/bitcoin/pull/21668
< wumpus> jeremyrubin: i don't know i hope no one owns it and it's not governed" tbh
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21676: test: Use mocktime to avoid intermittent failure in rpc_tests (master...2104-testFixMocktime) https://github.com/bitcoin/bitcoin/pull/21676
< bitcoin-git> [bitcoin] practicalswift opened pull request #21677: fuzz: Avoid use of low file descriptor ids (which may be in use) in FuzzedSock (master...avoid-open-fds-when-fuzzing) https://github.com/bitcoin/bitcoin/pull/21677
< bitcoin-git> [bitcoin] hebasto opened pull request #21678: test: Fix TSan suppression (master...210414-deadlock) https://github.com/bitcoin/bitcoin/pull/21678
< bitcoin-git> [gui] laanwj merged pull request #260: Handle exceptions instead of crash (master...210326-ex) https://github.com/bitcoin-core/gui/pull/260
< bitcoin-git> [bitcoin] laanwj pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/b8e5bbdf93e5...03ecceedf6f1
< bitcoin-git> bitcoin/master af7e365 Hennadii Stepanov: qt: Make PACKAGE_BUGREPORT link clickable
< bitcoin-git> bitcoin/master 64a8755 Hennadii Stepanov: qt: Add BitcoinApplication::handleNonFatalException function
< bitcoin-git> bitcoin/master f7e260a Hennadii Stepanov: qt: Add GUIUtil::ExceptionSafeConnect function
< bitcoin-git> [bitcoin] jnewbery closed pull request #21533: mining: Remove unused extranonce logic (master...2021-03-extra-nonce) https://github.com/bitcoin/bitcoin/pull/21533
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/03ecceedf6f1...a12962ca8940
< bitcoin-git> bitcoin/master fa73ce6 MarcoFalke: Fix assumeutxo crash due to truncated file
< bitcoin-git> bitcoin/master a12962c MarcoFalke: Merge #21585: Fix assumeutxo crash due to truncated file
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21585: Fix assumeutxo crash due to truncated file (master...2104-assumeutxoCrash03) https://github.com/bitcoin/bitcoin/pull/21585
< prayank> harding: Request you to review this PR: https://github.com/bitcoin/bitcoin/pull/21157
< prayank> TL;DR - 1 commit. No code. Tor docs. Reviewed by 8 or more people in last 2 months.
< prayank> A. Highlight DNS requests part B. Add 1 example in the end C. Add 4 Privacy recommendations D. Mention about `onlynet=i2p`
< jeremyrubin> wumpus: that's not how trademarks law works
< wumpus> prayank: i'll take a look as well, good to see nyx (the tor node monitor) is still a thing
< bitcoin-git> [bitcoin] promag opened pull request #21679: rpc: Keep default argument value in correct type (master...2021-04-rpc-defaults) https://github.com/bitcoin/bitcoin/pull/21679
< prayank> wumpus: Thanks
< Kiminuo> Hi, I'm working on https://github.com/bitcoin/bitcoin/pull/21422. Would you mind saying "concept ACK" if you find it useful?
< bitcoin-git> [bitcoin] hebasto opened pull request #21680: test: Use called_from_lib to point uninstrumented libs to TSan (master...210414-tsan) https://github.com/bitcoin/bitcoin/pull/21680
< wumpus> #21422
< gribble> https://github.com/bitcoin/bitcoin/issues/21422 | Add feerate histogram to getmempoolinfo by kiminuo · Pull Request #21422 · bitcoin/bitcoin · GitHub
< _Sam--> Hi I just wanted to say thank you for doing all that work to make bitcoin. I appreciate you. I sit around and don't do anything, and make money just because of the work you did. Thanks dudes/girls. Have a nice day.
< wumpus> thank you!
< Kiminuo> :D
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a12962ca8940...8c867ed4ec6c
< bitcoin-git> bitcoin/master 11115c8 MarcoFalke: ci: Only cache depends/sdk-sources for macos/apk task in cirrus
< bitcoin-git> bitcoin/master 8c867ed MarcoFalke: Merge #21675: ci: Only cache depends/sdk-sources for macos/apk task in cir...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21675: ci: Only cache depends/sdk-sources for macos/apk task in cirrus (master...2104-ciSdkMacosOnly) https://github.com/bitcoin/bitcoin/pull/21675
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8c867ed4ec6c...773f8c1a7d56
< bitcoin-git> bitcoin/master f2ef5a8 Hennadii Stepanov: test: Fix TSan suppression
< bitcoin-git> bitcoin/master 773f8c1 MarcoFalke: Merge #21678: test: Fix TestPotentialDeadLockDetected suppression
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21678: test: Fix TestPotentialDeadLockDetected suppression (master...210414-deadlock) https://github.com/bitcoin/bitcoin/pull/21678
< achow101> #21377 rtm? Has 9 ACKs
< gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
< wumpus> i hope so it would be good to do the speedy trial thing, speedy i guess
< bitcoin-git> [gui] jarolrod opened pull request #281: qt: set shortcuts for console's resize buttons (master...mul-shortcuts-resize) https://github.com/bitcoin-core/gui/pull/281
< luke-jr> achow101: NACK
< luke-jr> Developers do not get to strong-arm protocol changes any more than miners do.
< luke-jr> stop with this NYA attempt
< sipa> as far as i can see based on comments on the bip change and implementation, there seems pretty wide community consensus
< sipa> i haven't followed all discussions everywhere of course
< sipa> but you can't just say "no community consensus" while only showing evidence of yourself disagreeing
< jamesob> fwiw I'm an unreported concept ACK on #21377 and am in the process of reviewing the code
< gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
< jeremyrubin> I also have asked previously for a definition of terms https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3701878 to elucidate what luke is saying when he says "X does not have community consensus but Y does"
< jeremyrubin> I'll reiterate here: luke-jr luke-jr can you give a definition for what consensus is? Is there a concrete and consistent definition you are applying that BIP8 LOT=true is satisfying that the current ST MTP start/stop + height of activation minimum is not meeting that can be applied here and in the future?
< luke-jr> sipa: there is wide community consensus around BIP 8
< sipa> where is that community?
< luke-jr> jeremyrubin: stop strawmanning
< luke-jr> sipa: all over the world?
< sipa> this seems like a pointless discussion
< jeremyrubin> I don't think that's a strawman? I've asked you to generalize. If you can't do that then I don't think anyone will listen
< luke-jr> yes, I don't know what there is to discuss. devs simply cannot force changes without communtiy support.
< luke-jr> jeremyrubin: I have never said nor implied LOT=True has consensus
< sipa> well someone makes a proposal, and as far as i can see, there seems agreement about that proposal
< luke-jr> jeremyrubin: and there is zero indication ST/MTP has any kind of consensus
< luke-jr> sipa: there is agreement on BIP8, yes
< wumpus> if merging anything with regard to taproot activation is 'forcing changes' that only leaves UASF
< luke-jr> sipa: 21377 is opposed to the agreement
< jonatack> jamesob: achow101: same, i'm still reviewing. did a first pass to get the code and bips in my head, need to do another one
< sipa> luke-jr: there are tons of ACKs on the BIP PR, and the implementation; isn't that indication?
< wumpus> it means core can no longer activate softforks by itself but it always needs a third party group to push their own client
< luke-jr> sipa: ACKs are developers
< sipa> luke-jr: yes, that's why i ask about other evidence
< luke-jr> sipa: talk to people?
< wumpus> i am somewhat disappointment that we could not reacha agreement around something everyone seems to want
< sipa> that's not my job
< wumpus> but that is how it is
< luke-jr> sipa: well, that's how you get evidence
< achow101> The only person who has expressed explicit discontent with 21377 is luke-jr
< jamesob> luke-jr: people who aren't following these PRs probably aren't the ones you'd want opining on activation strategy
< achow101> everyone else I have spoken to (in various meetings and elsewhere) are okay with 21377
< jamesob> if someone takes issue with a particular means of activation, there is nothing stopping them from commenting on 21377
< luke-jr> jamesob: I reject absolutely the premise that developers alone decide protocol changes.
< jamesob> nobody is saying that
< jeremyrubin> you either die a user or live long enough to become a developer
< luke-jr> GitHub and this channel are developer forums
< jamesob> jeremyrubin: lol
< wumpus> luke-jr: that is not the case anyhow, if there is widespread disagreement, they won't install the client version wit hthe softfork activation
< sipa> luke-jr: i don't think that's the case here
< jamesob> luke-jr: forums that are not gated in any way
< luke-jr> jamesob: actually, GitHub is, but let's not go off on that tangent
< luke-jr> wumpus: that doesn't mean it's okay to release such a thing
< wumpus> luke-jr: in any case, you are effectively blocking taproot activation right now
< luke-jr> wumpus: no, I am not
< wumpus> luke-jr: i do not know if that is your intent but you are doing it
< luke-jr> wumpus: I am helping users who are prepared to release something appropriate if Core will not
< michaelfolkson> I personally am very uncomfortable by this precedent
< luke-jr> instead of trying to strong-arm the community to using a flawed activation method
< michaelfolkson> One developer (aj) is preventing block heights from being used consistently
< achow101> luke-jr: you're the one trying to strongarm the community into using your preferred activation method
< jnewbery> michaelfolkson: please stop. That's clearly not the case
< luke-jr> achow101: liar
< jamesob> luke-jr: you are begging the question there; you seem to be the only person around here who thinks the method is flawed
< achow101> this is the billionth time we've had this discussion and it's absolutely pointless
< achow101> there is community consensus for 21377
< michaelfolkson> There is no reason to not use block heights consistently, it is farcical
< michaelfolkson> It will set a precedent for future Core versus alternative client battles over block height and MTP which are totally unnecessary
< jamesob> michaelfolkson: code churn on a consensus-critical part of the system seems like a pretty good reason
< sipa> michaelfolkson: as far as i can see, this is all a storm in a teapot, and my only concern is that there is a single proposal pushed forward to avoid fragmentation
< luke-jr> 21377 would make Core an enemy of Bitcoin
< michaelfolkson> The clear thing to do is ask aj to use block heights consistently
< jeremyrubin> [4/14/21 10:18] <luke-jr> jeremyrubin: I have never said nor implied LOT=True has consensus
< jeremyrubin> [Tuesday, March 9, 2021] [10:13:51 AM PST] <luke-jr> RusAlex: no consensus, but LOT=True has sufficient support to move forward
< michaelfolkson> The fact that no one is is just shocking to me
< achow101> michaelfolkson: YOU THINK I DIDN"T ASK?????
< michaelfolkson> Why risk a split network with Core and the alternative client over mix of block height and MTP? Totally nonsense
< jeremyrubin> [Saturday, March 13, 2021] [4:37:57 PM PST] <luke-jr> AaronvanW: but IMO we have(had?) basically consensus on everything but LOT, so we should just use that.
< sipa> michaelfolkson: wut?
< sipa> michaelfolkson: this is ridiculous
< achow101> michaelfolkson: why risk a split network by having an alternative client?
< jeremyrubin> I think it's accurate for you to say you haven't implied LOT has consensus, but by your actions you're forcing a release without consensus
< achow101> that's the qusetion for you to ask
< michaelfolkson> sipa: There is an alternative client implementing Speedy Trial (consistent block height) followed by BIP 8 (LOT=true, 1 year)
< sipa> michaelfolkson: where? pushed by whom?
< sipa> who will run it?
< luke-jr> achow101: because Core refuses to do the right thing and merge what has community consensus
< michaelfolkson> sipa: By using this dumb mix of MTP and block height in Core we are risking a split network
< michaelfolkson> It is just ridiculous
< achow101> in any case, assuming blocks are found at the rate that they have been found for the past several years, MTP ST and the alternative client will be in agreement
< jeremyrubin> achow101: +1
< sipa> michaelfolkson: you're the only one claiming that, as far as i can see (again, i have not seen all discussion)
< michaelfolkson> Because one developer (aj) with really weak rationale won't use block heights consistently?
< luke-jr> achow101: I agree, but ST/MTP still lacks community support and seems to outright be spitting on consensus
< achow101> luke-jr: the only one spitting on consensus is you refusing to accept that there is consensus for MTP ST
< luke-jr> achow101: there isn't
< sipa> michaelfolkson: i really don't care about aesthetical concerns; i care about what agreement there is on a path forward
< michaelfolkson> aj has his PR being used, someone please ask him to use block heights consistently to prevent risk of split network
< luke-jr> there are some developers trying to strong-arm it in without community support
< achow101> you keep asserting that but refuse to provide any such evidence
< mol> achow101, +1
< sipa> michaelfolkson: and as far as i can see, you're trying to turn an aesthetical argument as evidence of a risk for splitting
< michaelfolkson> AJ is literally only one opposing consistent use of block height https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277
< sipa> michaelfolkson: who cares? there is a proposal that seems people like
< achow101> and he has provided a rationale for it that is not addressed by a block height proposal
< michaelfolkson> Well do you care about the possibility of a split network?
< sipa> michaelfolkson: yes, absolutely, that's the only thing i care about
< luke-jr> sigh
< bitcoin-git> [bitcoin] jamesob opened pull request #21681: validation: fix ActivateSnapshot to use hardcoded nChainTx (master...2021-04-au-nchaintx-fix) https://github.com/bitcoin/bitcoin/pull/21681
< michaelfolkson> You have a contributor of 10 years who is probably the biggest expert on activation here, author of BIP 8, involved with UASF and he is NACKing this. Please just consider what you are doing
< achow101> I will restate my earlier statment: 21377 is rtm. It has 9 ACKs, and 1 unmotivated (no reason given) NACK. Said NACK can be ignored as it does not provide a reason
< achow101> a NACK with no reason provided can be ignored as stated in our contributor guidelines
< michaelfolkson> For what? AJ's test networks? Seriously....
< luke-jr> achow101: developer ACKs withotu community agreement isn't enough for protocol changes; and I gave reasons
< luke-jr> (as have many others including yourself!)
< jeremyrubin> luke-jr can you give a definition for what consensus is? Is there a concrete and consistent definition you are applying that BIP8 LOT=true is satisfying that the current ST MTP start/stop + height of activation minimum is not meeting that can be applied here and in the future?
< michaelfolkson> We are willing to risk a split network over AJ's test networks. I'm staggered
< luke-jr> jeremyrubin: stop spamming
< jeremyrubin> It's a legit question that you've ignored
< sipa> michaelfolkson: i cannot comprehend where this is coming from
< luke-jr> no, it isn't
< jnewbery> michaelfolkson: you've claimed in ##taproot-activation that your goal is for "21377 to be well reviewed and merged". Your actions over the last week have been completely contrary to that stated goal.
< jeremyrubin> Maybe remove BIP8 LOT=true?
< jeremyrubin> What is BIP8 LOT=? satisfying
< jamesob> michaelfolkson: can you dial back the hyperbole please?
< achow101> michaelfolkson: you are willing to risk a split network over a MTP vs height for a single paramter. I'm staggered
< sipa> ^
< jeremyrubin> michaelfolkson: i've personally found the thinking patterns in https://www.lesswrong.com/posts/GSQsAReasGjETP3e9/biases-of-intuitive-and-logical-thinkers helpful in development. Perhaps worth reflecting on
< michaelfolkson> Luke has been consistent throughout and he has expertise with activations. If you want to ignore that, go for it
< jeremyrubin> he's consistently failed to answer questions like "what is incompatible with ST" or "what definition of consensus are you using that passes BIP8 and not ST"
< sipa> sorry, this discussion is personally stressing me out too much; my intent isn't to weigh in on activation methods, just to assess to level of support the current proposal has
< michaelfolkson> All these NACKs and coin flips and test networks, I've just been shocked
< jeremyrubin> and you're literally arguing with sipa about expertise with activation
< sipa> i'm going to withdraw again
< jnewbery> michaelfolkson: yes you're shocked. We all understand that you're shocked.
< jnewbery> I'll echo the many people in #taproot-activation who have suggested you step back for a bit.
< jnewbery> You're no longer helping yourself or anyone else
< michaelfolkson> jnewbery: Everytime I do, everyone just piles on Luke or does dumb coin flips
< luke-jr> "get out of the way so we can strong-arm this in" is what I am hearing
< michaelfolkson> I stayed away for a week and look at all the nonsense that happened
< jnewbery> all the nonsense = actual progress on a compromise proposal and implementation
< mol> michaelfolkson, thank you for staying away for a week and that allowed us to get things done
< michaelfolkson> Just listen to Luke's views occasionally, that's all I ask. You can ignore me
< luke-jr> there's nothing compromise about it anymore; it's purely one-sided, against community majority
< michaelfolkson> mol: Right some great coin flips were done
< mol> you never know michaelfolkson you're a liability and a farce for luke-jr
< michaelfolkson> mol: Lol if he thinks that he can tell me privately
< jeremyrubin> I would love to listen to luke-jr michaelfolkson
< achow101> michaelfolkson: you are not asking us to listen to luke-jr. You are asking us to bow down to luke-jr and accept everything that he wants
< mol> he might not think so but luke-jr needs better help
< jeremyrubin> Luke, what test is BIP8 passing w.r.t. consensus that ST is not?
< * jeremyrubin> ears open
< luke-jr> jeremyrubin: ST is not MTP
< michaelfolkson> Ok I'm out too. Just please consider what you are doing. You are willing to risk a split network over AJ's test networks. Just so you are clear on that
< jeremyrubin> Ok please don't pedant over terms.
< luke-jr> ST/BIP8 had (has?) widespread support, not ST/BIP9
< jeremyrubin> What test is BIP8 passing that 21377 is not
< jamesob> michaelfolkson: it's hard not to listen to Luke's views occasionally :). Everyone here I think values his participation, input, and unique approach in a general sense, but this whole activation debate is wallowing in the mire. We all want taproot here.
< luke-jr> the community is almost unanimous in favour of BIP8
< jeremyrubin> Where are you observing this consensus
< jeremyrubin> SHOW DON'T TELL
< jeremyrubin> I have not seen it *anywhere*
< luke-jr> most have never even heard of 21377, and it is opposed to the community's consensus aroudn BIP8
< luke-jr> jeremyrubin: then you're not paying attention
< jeremyrubin> WHERE
< jeremyrubin> luke-jr: community's consensus aroudn BIP8 WHERE
< jeremyrubin> It should be fucking simple if it exists
< luke-jr> jeremyrubin: literally everywhere people talk about Bitcoin/Taproot/activation
< luke-jr> jeremyrubin: it is, but you refuse to look
< jeremyrubin> Then give me *one* example
< michaelfolkson> I can't leave can I....
< jeremyrubin> you can!
< luke-jr> go re-read the meeting logs; go look at Twitter or reddit; call up some people you know
< achow101> michaelfolkson: you can leave at any time
< michaelfolkson> achow101: As you know there were very well attended community meetings when we reviewed and finalized BIP 8 (using block heights)
< michaelfolkson> achow101: Not ten people doing a coin flip
< jeremyrubin> That didn't decide what happened, and you know that.
< achow101> And there were very well attended community meetings where we reviewed and finalized ST using MTP
< luke-jr> frankly asking for evidence at this point is just dishonest
< jeremyrubin> wtf
< luke-jr> as if it isn't all over the place
< michaelfolkson> achow101: We then had to decide on the LOT parameter. There wasn't clear consensus on the LOT parameter
< jeremyrubin> michaelfolkson: which meeting was this? The one scheduled 24 hours in advance?
< michaelfolkson> achow101: But that does not mean the community went f*** BIP 8, let's use no BIP and a mix of block height and MTP
< michaelfolkson> *let's not use BIP 8
< michaelfolkson> jeremyrubin: There were two with 10 days notice I think
< luke-jr> the fact that ST/MTP folks can't engage honestly is what makes this a waste of time
< michaelfolkson> achow101: We don't even know what BIP this MTP, block height is. That is what a shambles this is
< achow101> michaelfolkson: it's BIP 341
< michaelfolkson> Again all for AJ's test networks
< achow101> A PR has been opened to specify all of it in BIP 341
< michaelfolkson> We haven't worked out if it is going to be BIP 9 or a new BIP
< michaelfolkson> When Speedy Trial is sitting there neatly in BIP 8 and it has been reviewed
< achow101> It doesn't matter. It's specified in the place it matter: BIP 341
< achow101> the place it is going to be used
< michaelfolkson> It could be used again. It needs a BIP that isn't Taproot specific
< luke-jr> michaelfolkson: seems achow101's argument is that it's being special-cased in BIP 341 and therefore not expected to be used again
< michaelfolkson> achow101: It could easily be used again. Especially if it is a success
< luke-jr> it shouldn't be used once, much less again
< achow101> michaelfolkson: This is not the first time an activation mechanism was specified in the first BIP it were used, and then referred to again in subsequente soft forks
< achow101> see BIP 34
< achow101> and the later ISM forks that referred to the BIP 34 activation mechanism
< michaelfolkson> From a BIP perspective it is a mess currently imo
< michaelfolkson> Now if that was the only problem I would say ignore it
< michaelfolkson> But it is not
< luke-jr> anyway, how things get documented in BIPs is trivial in comparison to the real issues
< michaelfolkson> We have an alternative client using block height consistently
< michaelfolkson> We also have most reviewers preferring consistent use of block height and only one contributor NACKing it
< michaelfolkson> (for his test networks)
< michaelfolkson> It is just ludicrous
< jamesob> michaelfolkson: there are an infinite number of possible alternative clients; it doesn't make sense to defer to one that just popped up yesterday
< achow101> michaelfolkson: have you read https://tools.ietf.org/html/rfc7282? I highly suggest you read section 6 "One hundred people for and five people against might not be rough consensus" and section 7 "Five people for and one hundred people against might still be rough consensus"
< michaelfolkson> jamesob: That is fair, but luke-jr is involved. It is not like it is some joker coming out the woodwork trying to cause disruption
< mol> we gathered in the meeting for the 'alternative client' to make luke feel good but only 3 people might run it, the rest of the community will run Core :D
< michaelfolkson> He has also been consistent throughout but people just don't listen to him (even though this is his area of expertise)
< luke-jr> jamesob: it didn't "just pop up yesterday"; it's been an ongoing WIP originally intended for Core, but finally accepting a separate release due to these problems within Core
< jeremyrubin> reading through http://gnusha.org/taproot-activation/2021-02-02.log, based on which michaelfolkson bases claim that BIP9 is "dead" and therefore MTP can't be used, TBH I just don't see that being the emergent agreement
< jeremyrubin> I see people caring about the *properties* of BIP8 vs BIP9, not excluding MTP being used in the future
< michaelfolkson> jeremyrubin: They weren't my words, they were Rusty's words (an author of the BIP)
< michaelfolkson> A neutral observer at the meeting
< jeremyrubin> which meeting? i don't see him saying that in these logs
< michaelfolkson> In his summary after the meeting, his exact words
< michaelfolkson> I just think you like wasting people's time jeremyrubin
< michaelfolkson> But for this I'll find you the link
< jamesob> micahelfolkson: can we shy away from ad hominem?
< jeremyrubin> I'm doing what luke and you asked, which is reviewing the meetings for consensus
< michaelfolkson> jeremyrubin: Exactly, thank you
< jeremyrubin> I see, but it's *your job* as a summarizer to filter. And "dead" (not RIP) is a quote due to you
< michaelfolkson> The maintainers will essentially need to decide. I recommend they ask aj to use block heights consistently personally. But if he refuses it is up to them what they merge
< michaelfolkson> jeremyrubin: You are quibbling over RIP versus dead? Seriously?
< michaelfolkson> You are just trolling and wasting my time
< jeremyrubin> I'm just saying you seem to beleive rusty
< jeremyrubin> and you've extrapolated BIP9 RIP ==> MTP cannot be used
< michaelfolkson> I haven't
< michaelfolkson> This is torture
< michaelfolkson> I've said not to use BIP 9
< jeremyrubin> And are you in the chair or holding the bucket of water?
< michaelfolkson> And the only BIP that has been reviewed and includes Speedy Trial is BIP 8
< jeremyrubin> #21377 has been reviewed, as has the corresponding 341 BIP
< gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
< achow101> michaelfolkson: we aren't using BIP 9. MTP != BIP 9
< jeremyrubin> in fact at this point it probably has more review than any BIP8 anything has ever had
< achow101> jeremyrubin: he's in the chair dunking his own head into the bucket of water
< michaelfolkson> We. will. need. a. BIP. for. Speedy. Trial (that is not Taproot specific)
< jeremyrubin> can happen after the fact
< michaelfolkson> Sjors has opened a PR to change BIP 9
< achow101> A generalized BIP can happen afterwards
< jeremyrubin> BIPs are often descriptive
< jeremyrubin> not prescriptive
< jeremyrubin> (in fact, it's usually preferable to be descriptive otherwise we have useless BIPs clogging the numberspace)
< michaelfolkson> Whatever. As I've said the maintainers will need to make the decision. I would recommend they ask aj to change to block heights consistently.
< michaelfolkson> If he refuses we have the risk of a split network if it gets merged
< michaelfolkson> A small risk, but a risk nonetheless
< michaelfolkson> jeremyrubin: It is when people are going mad doing coin flips and whatever else
< jeremyrubin> Project maintainers have commit access and are responsible for merging patches from contributors. They perform a janitorial role merging patches that the team agrees should be merged. They also act as a final check to ensure that patches are safe and in line with the project goals. The maintainers’ role is by agreement of project contributors.
< michaelfolkson> When people are going mad doing coin flips the only people stopping dumb stuff from being merged is the maintainers
< jeremyrubin> If there is a safety concern, maintainers can raise it. But using their maintainer hat they aren't in the role of prescribing something else.
< achow101> michaelfolkson: you keep harping on about this coin flip thing as if it actually mattered
< achow101> do you actually think the coin flip was what decided which PR to close?
< michaelfolkson> I don't have anymore to add
< michaelfolkson> If you start piling on Luke again I'll come back
< mol> lmao
< achow101> you've had nothing more to add for a long time
< jeremyrubin> luke-jr is a big boy, he can handle himself
< michaelfolkson> Otherwise I'm out
< achow101> we've been having the same exact discussion for the past several weeks
< mol> bye
< roconnor> so, #21377 rtm then?
< gribble> https://github.com/bitcoin/bitcoin/issues/21377 | Speedy trial support for versionbits by ajtowns · Pull Request #21377 · bitcoin/bitcoin · GitHub
< jeremyrubin> roconnor: I'd like to play with the tests a bit more to go from cr-ack to tack, but that can happen after merge
< jeremyrubin> so rtm from me
< jonatack> roconnor: jamesob and i are still reviewing, idk about others, not to block anything tho
< jamesob> yeah I'm happy to continue review post-merge
< luke-jr> roconnor: no
< luke-jr> it's still unacceptable to ignore the community
< jnewbery> it's ready to merge
< luke-jr> it's abuse of position to merge
< jeremyrubin> noted
< jeremyrubin> I've gone and re-looked at the notes
< BlueMatt> roconnor: yep! 21377 looks ready to merge!
< jeremyrubin> I can see why luke-jr and michaelfolkson think there might be consensus on BIP8, but I think they are viewing the process as "gradient descent on a continuos surface" as opposed to a discontinuous process.
< jeremyrubin> There was never an inkling of consensus on a LOT=true parameter
< jeremyrubin> it was always hotly contested
< jeremyrubin> and BIP8 requires *a choice* of that
< jeremyrubin> so it seems inaccurate to me to label BIP8 as having consensus when a key parameter did not
< jeremyrubin> 21377, being a whole new thing, needs to be independently evaluated
< jeremyrubin> "but we already agreed to XXX for BIP8" doesn't hold when a keystone component of BIP8 (LOT) is what made ST a thing in the first place.
< jeremyrubin> Further, the type of consensus around BIP8 in these meeting logs (maybe it's somewhere else, figure the meetings are more relevant than twitter/reddit) is not super high quality IMO because it's mainly ACK'ing the properties of BIP8 as opposed to the specific implementation
< jeremyrubin> And it's less explicit ACKs as opposed to "sounds OK"
< jeremyrubin> (there was no, afaict, concrete PRs in the air?)
< harding> Re rtm status: I'm reviewing 21377 again today, but I've tested it quite a bit so far and not found any problems. I'll also continue reviewing post-merge if it gets merged today.
< jeremyrubin> In contrast, the ACKs on harding's proposal (which allows for middle space of BIP8 or BIP9) https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f is much more exhaustive and explicit
< jeremyrubin> 21377 being a concrete instantion of that suggests to me it is acceptable by the community
< jeremyrubin> Further in support of BIP8's consensus being questionable earlier on, I think harding has had a very good read on the community in general. I don't beleive he would have included BIP9 in his proposal as an option if he thought the community was decisive
< jeremyrubin> (harding don't let me assume your intent)
< luke-jr> jeremyrubin: BIP8 doesn't require LOT for ST any more than BIP9 does
< jeremyrubin> Overall I feel relativelty confident based on this review dismissing the notion that BIP8 has consensus and ST/MTP does not
< jeremyrubin> but others can do their own review of this summary independently
< jeremyrubin> Sorry if this is line noise for this channel -- but this is the best job I could do at breaking down the claim that BIP8 has consensus (LOT=?) and ST/MTP does not
< midnight> If someone +o me, I'll clean this channel up and then you can blame me.
< BlueMatt> fwiw, I do, like I think several others, have a weak but repeatedly-stated preference for MTP over height.
< jeremyrubin> midnight: I don't think there's a need, but if you're referring to me I'll put myself in timeout voluntarily. lunch time
< emzy> fwiw I was prefering bip8 and ok with bip9 in the beginning. And I think many thought the same at that time.
< emzy> (hight over MTP)
< emzy> *hight
< BlueMatt> emzy: right, people gonna disagree, cause people. trying to blow up progress because of a triviality, tho....
< provoostenator> The "BIP 8" (LOT=false) speedy trial PR #21392 is of similiar quality to the BIP 9 one IMO.
< gribble> https://github.com/bitcoin/bitcoin/issues/21392 | Implement BIP 8 based Speedy Trial activation by achow101 · Pull Request #21392 · bitcoin/bitcoin · GitHub
< emzy> BlueMatt: I agree.
< provoostenator> For BIP 8 itself the main issue was LOT=true but I don't think there was much objection to implemting the LOT=false version.
< provoostenator> It's a coin toss :-)
< provoostenator> (but not literally)
< BlueMatt> provoostenator: right, one of those trivialities that we generally just say "code author decides, cause it doesnt matter" :p
< jeremyrubin> of course, a literal coin toss wouldn't be provably fair over the phone ;)
< BlueMatt> or, if you really care, a coin toss
< Emcy> if its rtm, please merge it
< Emcy> no more peanut gallery
< provoostenator> Right, I was just responding to earlier discussion about BIP 8 being totally not in a review ready state. That's only true for LOT=true.
< jeremyrubin> provoostenator: I don't disagree on quality, 21377 has more acks/review though so closer to RTM
< provoostenator> Because that PR needs more work and more thinking
< provoostenator> jeremyrubin: it certainly does now
< BlueMatt> sounds like most of us are in agreement, its ready to merge 🎉
< jeremyrubin> Ah yes, provoostenator was commenting on my comment at [11:22:46 AM PDT]
< jeremyrubin> I'm looking back at the february meetings which were I think before any PR
< provoostenator> I like that it has a +1 from Voskuil too, who needs to deal with implemting this in libbitcoin.
< provoostenator> Aperently also support from Btcd.
< provoostenator> And so far no comment along the lines of "my goodness this is a nightmare to implement in [my favorite BTC client]"
< BlueMatt> plus voskuil *normally* disagrees very strongly on bitcoin fork activation stuff, so him agreeing is a pretty good "did we even slightly screw this up" check
< jeremyrubin> BlueMatt: don't let him catch you saying that
< BlueMatt> heh
< jonasschnelli> #proposedmeetingtopic short info/update on the "Bitcoin Core Code Signing Association" status.
< da2ce7_> wumpus: "<bitcoin-git> [gui] laanwj merged pull request #260: Handle exceptions instead of crash (master...210326-ex) https://github.com/bitcoin-core/gui/pull/260" the merge script seems to have a bug...
< gribble> https://github.com/bitcoin/bitcoin/issues/260 | Add esperanto translation. by TheBlueMatt · Pull Request #260 · bitcoin/bitcoin · GitHub
< wumpus> da2ce7_: how that?
< da2ce7_> well well; pull request is 260 is quite old...
< wumpus> it links to the GUI repo: https://github.com/bitcoin-core/gui/pull/260
< da2ce7_> ahhh. O.o; my bad then.
< wumpus> which has its own PR namespace, and started more recently, so the numbers are lower :)
< da2ce7_> I just clicked it via the github interface.
< wumpus> i see the issue now
< wumpus> it is supposed to do Merge bitcoin-core/gui#266
< gribble> https://github.com/bitcoin/bitcoin/issues/266 | Backport to wx2.8 and dynamically link most libs. by TheBlueMatt · Pull Request #266 · bitcoin/bitcoin · GitHub
< amiti> is anyone here admin for the bitcoin-dev mailing list? I've been trying to send an email and struggling :(
< wumpus> da2ce7_: I didn't *use* the script correctly, apparently, thanks for noticing
< michaelfolkson> amiti: I think RubenSomsen is
< michaelfolkson> amiti: What's the problem? There is sometimes a delay before it gets published if that's the concern?
< amiti> my emails are bouncing saying I'm not subscribed to the list, but I am
< michaelfolkson> Oh that is weird.. yeah I'm sure Ruben will be able to help (or at least point you to someone else who can help)
< amiti> ok, thanks
< da2ce7_> :)
< wumpus> amiti: or kanzure maybe
< amiti> wumpus: will check it out, thanks :)
< luke-jr> it's not triviality except to BIP9 advocates
< luke-jr> or to be more correct, people who don't consider it a triviality, are unanimously in favour of BIP8
< RubenSomsen> Problem solved, was able subscribe amiti to the mailing list manually to resolve it
< dergoegge> whats the easiest way to debug a test on windows without having a windows machine? (i am trying to figure out why the test i wrote in #21603 is failing on windows only)
< gribble> https://github.com/bitcoin/bitcoin/issues/21603 | log: Mitigate disk filling attacks by rate limiting LogPrintf by dergoegge · Pull Request #21603 · bitcoin/bitcoin · GitHub
< dergoegge> i have tried running "FILE_ENV="./ci/test/00_setup_env_win64.sh" ./ci/test_run_all.sh" but that keeps failing while building :/
< dergoegge> (i am on macOS if that makes a difference)
< jarolrod> windows virtual machine?
< phantomcircuit> dergoegge, iirc the windows test harness is pretty noisy
< phantomcircuit> oh
< phantomcircuit> dergoegge, you're assuming that LogPrintf("%s\n", std::string(1023, 'a')); results in 1024 bytes written, but on windows it might be 1025 cause of line endings
< dergoegge> jarolrod: yea i guess but i was hoping i could avoid setting up a vm from scratch, but that is probably the best way
< dergoegge> phantomcircuit: oh right, thats probably it, thank you
< kanzure> amiti: also you may have sent to bitcoin-discuss instead of bitcoin-dev
< amiti> kanzure: it was very odd, my email address wouldn't subscribe to bitcoin-dev, so per ReubenSomsen's suggestion we debugged by using bitcoin-discuss