< 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
< 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
< 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
< 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
< _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.
< 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
< 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.
< 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
< achow101>
THEN PROVIDE SOME GODDAMN LINKS
< 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
< achow101>
michaelfolkson: WHY IS IT THAT YOU ASSUME THAT GOING WITH MTP ST MEANS FUCK 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
< achow101>
THIS ISN'T A BINARY BLACK AND WHITE DECISION
< 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
< 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
< 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
< jeremyrubin>
THAT IS NOT MAINTAINERS JOBS IT IS A DANGEROUS MYTH YOU ARE PERPETUATING
< 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
< 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>
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.
< 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...
< 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)
< 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