--- Log opened Tue Apr 06 00:00:19 2021
00:19 -!- steve000 [458940e1@c-69-137-64-225.hsd1.tn.comcast.net] has quit [Quit: Connection closed]
00:19 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
00:43 -!- cguida1 [~Adium@174.78.10.131] has quit [Read error: Connection reset by peer]
00:43 -!- cguida [~Adium@174.78.10.131] has joined ##taproot-activation
01:05 -!- instagibbs [~greg@119247204116.ctinets.com] has joined ##taproot-activation
01:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
01:13 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
01:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:44 -!- cguida1 [~Adium@174.78.10.131] has joined ##taproot-activation
01:46 -!- cguida [~Adium@174.78.10.131] has quit [Ping timeout: 240 seconds]
02:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
02:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:43 -!- cguida [~Adium@174.78.10.131] has joined ##taproot-activation
02:46 -!- cguida1 [~Adium@174.78.10.131] has quit [Ping timeout: 268 seconds]
02:49 -!- cguida [~Adium@174.78.10.131] has quit [Ping timeout: 260 seconds]
02:56 -!- cguida [~Adium@174.78.10.131] has joined ##taproot-activation
03:03 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
03:03 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
03:43 -!- cguida1 [~Adium@174.78.10.131] has joined ##taproot-activation
03:45 -!- cguida [~Adium@174.78.10.131] has quit [Ping timeout: 268 seconds]
04:43 -!- cguida [~Adium@174.78.10.131] has joined ##taproot-activation
04:43 -!- cguida1 [~Adium@174.78.10.131] has quit [Read error: Connection reset by peer]
05:05 <@michaelfolkson> I'm a NACK for Speedy Trial https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3695024
05:05 <@michaelfolkson> I think once we get more NACKs we need to set a date for restarting the UASF discussion
05:06 <@michaelfolkson> [22:43:06]  <roconnor> I am speechless.
05:06 <@michaelfolkson> I think if roconnor NACKs his own proposal we can move on
05:07 <@michaelfolkson> I'm appalled, not just speechless
05:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
05:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
05:16 <@michaelfolkson> I won't be attending the meeting later. The next activation meeting I'll attend (if I attend any) is a meeting to discuss UASF
05:20 <@michaelfolkson> [22:43:06]  <roconnor> I am speechless.
05:20 <@michaelfolkson> [22:43:34]  <jeremyrubin> ¯\_(ツ)_/¯
05:20 <@michaelfolkson> Tells you all you need to know really
05:34 <@michaelfolkson> I guess we could discuss UASF releasing Speedy Trial but I know Luke will be against
05:36 <@michaelfolkson> I think it is done. Some people are determined to make this a slog so a slog it must be
05:44 -!- cguida1 [~Adium@174.78.10.131] has joined ##taproot-activation
05:46 -!- cguida [~Adium@174.78.10.131] has quit [Read error: Connection reset by peer]
06:02 -!- reallll is now known as belcher
06:13 -!- cguida1 [~Adium@174.78.10.131] has quit [Quit: Leaving.]
07:28 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
07:39 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation
07:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
07:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
08:01 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
08:03 < copumpkin> > Tells you all you need to know really
08:04 < copumpkin> does it? a ton of ACKs and a couple of people making noise are enough to NACK it?
08:05 < copumpkin> we know it's a large community that can barely agree on anything. There will be noise, even on uncontroversial things, so why be surprised when it happens and act like it's a big deal against ST?
08:24 <@michaelfolkson> So far AJ has Approach NACKed Andrew's Speedy Trial PR on the PR. Jeremy has effectively Approach NACKed (but not on the PR). Matt will Approach NACK anything. I'm not exactly sure who mol is but whoever they are, they will Approach NACK it
08:26 <@michaelfolkson> Core maintainer(s) to merge Andrew's PR will need to merge despite Approach NACKs from AJ and likely Jeremy and Matt
08:28 <@michaelfolkson> Maybe Core maintainers can merge Andrew's PR with just those 3 Approach NACKs. But if others add Approach NACKs, Andrew's PR can't be merged imo
08:29 <@michaelfolkson> If they do merge it I'm expecting a fuss from Jeremy and Matt
08:32 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
08:33 < copumpkin> Corallo?
08:33 <@michaelfolkson> Yeah
08:36 < belcher> where did matt corallo write approach nack?
08:36 < copumpkin> michaelfolkson: I don't think you're right on that
08:37 < copumpkin> or if you are, curious what makes you think he'll be against it
08:37 < jeremyrubin> My approach NACK is over merging ST in core while valued contributors prepare a simultaneous UASF client. Maybe walk down the MAD stance? Technically, either height or MTP can work fine for activation on mainnet, AJ introduced new ideas that make MTP relevent for discussion again
08:38 < jeremyrubin> michaelfolkson: injecting anxiety and angst into discussion is unhelpful
08:38 <@michaelfolkson> belcher copumpkin: Matt seems very upset about everything. I'm not exactly sure what would make him happy
08:38 < copumpkin> michaelfolkson: I think statements like that are what makes him upset, fwiw :)
08:38 < copumpkin> michaelfolkson: last I heard, ST was what he considered the path forward
08:39 <@michaelfolkson> copumpkin: Maybe but he's probably the one person I've followed the most to try to understand what would make him happy re activation. I haven't got to the bottom of what he would be happy with
08:39 < belcher> do you have a link to a comment by him?
08:40 < copumpkin> anyway, before assuming what he'd say, I'd probably just ask him. I don't think you're right on this one, fwiw
08:41 <@michaelfolkson> I can link to a mailing list post where he was unhappy with an activation mechanism if an incompatible UASF could be run in parallel (which is literally every single activation mechanism on earth)
08:41 < belcher> and yet he said ST was good (to me at least)
08:42 <@michaelfolkson> He did if you could guarantee no incompatible UASF in parallel (which obviously no one can)
08:42 < belcher> luke also at one point said UASF was the only way forward, yet he also agreed with ST
08:43 < belcher> ST is somewhat of a compromise, so not everyone is 100% happy with it but they're still going with it
08:44 < belcher> regarding UASFs happening in parallel, we could ask prominent UASF supporters what they think of ST and if they support ST then thats strong evidence that they wont attempt a parallel UASF deployment... and also the timeline of ST is very short so its hard to make a UASF attempt successful
08:44 <@michaelfolkson> We've already done that
08:44 < belcher> i said "we could ask", we already did ask back in march and people like luke were happy with ST
08:44 < belcher> snap
08:45 <@michaelfolkson> It is block height and BIP 8 or MTP and BIP 9 (will it be revised? who knows...)
08:47 < jeremyrubin> belcher: luke-jr said he would be preempting ST with a UASF client, which is what I approach nack'd
08:48 <@michaelfolkson> That's an Approach NACK for both Andrew's PR and AJ's PR then from you Jeremy
08:48 < belcher> maybe bitcoin would benefit if we just let the UASFers fail
08:48 < jeremyrubin> belcher: possibly
08:48 <@michaelfolkson> Unless luke-jr provides some sort of guarantee that he won't do that for you
08:48 < belcher> fork themselves off onto an irrelevant altcoin and come back to bitcoin a few months later
08:49 < jeremyrubin> it would show that a group trying to sieze power & co-opt a development process for their own egos won't succeed
08:49 < jeremyrubin> we've shown that before though
08:49 <@michaelfolkson> Haha. If you think the community is supportive of all this nonsense you are deluded
08:49 <@michaelfolkson> But we can find out
08:50 -!- jonny1000 [1f33335f@host31-51-51-95.range31-51.btcentralplus.com] has joined ##taproot-activation
08:50 <@michaelfolkson> Good luck getting that flag day in Core to sabotage the UASF
08:50 < jeremyrubin> most people i've talked to think it's silly, but in a "leave it alone" way
08:50 < jeremyrubin> i don't think anyone is chomping at the bit for nuclear options
08:52 < jeremyrubin> there's a meeting at 19:00 UTC where I think we have a good shot at technical consensus
08:52 < jeremyrubin> I don't see why you're throwing in the towel on that before it even happens
08:52 <@michaelfolkson> Giving users the right to activate a soft fork is not a "nuclear option". Especially if Core can't release anything
08:53 <@michaelfolkson> I'm getting rather sick of this giving power to users is "nuclear"
08:53 < jeremyrubin> michaelfolkson: BIP 8 LOT=true is a bit worse than that because users only find out if it works by risking a chainsplit
08:53 < jeremyrubin> if you want users decide with less technical risk you could do coin voting or something else
08:55 < luke-jr> [12:05:41] <michaelfolkson> I think once we get more NACKs we need to set a date for restarting the UASF discussion <-- no need to restart, just move forward
08:55 < AaronvanW> belcher "fork themselves off onto an irrelevant altcoin and come back to bitcoin a few months later" <--- I think you're making a big assumption there on how miners will act in such an event. I think it's pretty likely they'll just go along with the UASF. (but I do agree with the greater point of just letting UASFers do their thing and see what happens.)
08:56 < belcher> AaronvanW even if they do go along, nobody would actually use taproot because 51% of miners could steal their coins
08:56 < AaronvanW> belcher: I don't think miners will want to risk mining a chain that can be reorged away.
08:56 < belcher> AaronvanW right but if they can steal tens of thousands of bitcoins it will be worth it
08:57 < AaronvanW> either way, futures markets will probably inform us on this kind of stuff long before there is an actual fork.
08:57 <@michaelfolkson> We have tried everything to get something into Core. I stupidly thought Speedy Trial would be smooth given the level of community consensus. I think users will be just as disgusted as me at the hold up
08:57 < jeremyrubin> I think you're too "in it" michaelfolkson
08:57 < AaronvanW> belcher: well only if these tens of thousands of coins are worth something. would you hold (value) coins on a chain that can be reorged away?
08:58 < jeremyrubin> speedy trial was proposed 1 month ago
08:58 < belcher> AaronvanW miners dont have to hold the coins, they could immediately transact them to an exchange (which we're assuming hasnt adopted the UASF altclient) and sell them
08:58 < luke-jr> [15:49:10] <jeremyrubin> it would show that a group trying to sieze power & co-opt a development process for their own egos won't succeed <-- that is what the anti-UASFers are doign
08:58 < jeremyrubin> how fast do you think non-urgent consensus changes to bitcoin should be picked up?
08:59 <@michaelfolkson> There was a proposed timetable that can't be adjusted until a PR is picked
08:59 < jeremyrubin> michaelfolkson: and I don't see why you're having a fit *before* the scheduled meeting today
08:59 < jeremyrubin> what's the point of that?
09:00 < AaronvanW> belcher: 1) they have to hold the coins for 100 blocks. 2) exchanges will presumable make a difference between coins on both sides of the split. not consider both "bitcoin" or "btc".
09:00 < luke-jr> we should just move the BIP8(True) release forward at the meeting; forget ST
09:01 <@michaelfolkson> jeremyrubin: Because a meeting is not going to pick a PR, it is just a waste of time. The only thing we need is a PR to be picked.
09:01 < jeremyrubin> And you think trying to make the meeting about ditching ST and doing a UASF is the best way to accomplish that?
09:01 < luke-jr> ST is dead
09:02 < belcher> AaronvanW 1) they would only be held for that 100 block period if they took the coins as block rewards, im talking about them spending coins in taproot addresses, which has no timelock 2) maybe miners could sell them on bisq, or OTC, or to anyone who accepts coins and uses a full node wallet
09:02 <@michaelfolkson> jeremyrubin: It is a waste of time. No one at the meeting has the authority to pick a PR. And you know that as well as I do.
09:02 <@michaelfolkson> jeremyrubin: Just more delay and more nonsense
09:03 < jeremyrubin> RIP ST, March 5th 2021 - April 6th 2021?
09:03 < jeremyrubin> Get real
09:03 < luke-jr> jeremyrubin: even you're NACKing it now..
09:03 <@michaelfolkson> jeremyrubin: Feel free to ACK both PRs jeremyrubin
09:03 <@michaelfolkson> If you want to keeo it alive
09:03 <@michaelfolkson> You won't because you are playing dumb games
09:04 < jeremyrubin> "dumb games" --> acking after reviewing?
09:05 <@michaelfolkson> Approach ACK both PRs? You've had enough time to do that right?
09:05 <@michaelfolkson> Or Approach NACK Andrew's PR? Whatever
09:06 < AaronvanW> belcher: both sides of the split would be "full node" of their own coin. yeah maybe some un-upgraded users can be tricked by miners, but will that really bring in enough value to make it worth mining a chain that can be re-orged? I really don't think so.
09:06 <@michaelfolkson> Approach NACK because MTP is better for test networks
09:06 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/21392#pullrequestreview-606866335
09:06 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-809708651
09:07 < jeremyrubin> "jeremyrubin NACK of ST Height: if using height means that we'd see a marketed push to launch a UASF client before ST is given a chance, ST fails its goal for avoiding contentious forks"
09:07 < jeremyrubin> you're acting in a deluded manner here michaelfolkson.
09:08 <@michaelfolkson> Lol at making decisions based on speculation for marketing strategies. That was a good one
09:08 <@michaelfolkson> I enjoyed that one
09:08 <@michaelfolkson> Have a good meeting, I think it is a waste of time. We need to pick a PR
09:11 < copumpkin> I'd urge folks to step back and recognize that these sorts of back and forth meta-exchanges are all part of the big picture of consensus here, and are exhausting and end up causing attrition and selecting for folks who find it less exhausting or have more time for discussion. Insisting on ideals when half the participants are on the verge of ragequitting (figuratively) is a good way to get your way while making the entire
09:11 < copumpkin>  system weaker
09:11 < luke-jr> jeremyrubin: ST was only ever okay because the normal client can release compatible with it
09:11 < luke-jr> jeremyrubin: if your explicit goal is to disrupt a normal release, then nothing you are okay with will ever be acceptable
09:12 < jeremyrubin> Which is true irrespective of MTP or Height
09:12 < jeremyrubin> so your logic doesn't even make sense anyways on that point
09:13 < jeremyrubin> also please avoid normative statements
09:13 < jeremyrubin> they're not helpful because what you consider normal v.s. someone else is always different
09:13 < jeremyrubin> de gustibus no disputandum
09:14 <@michaelfolkson> copumpkin: I've Approach ACKed both PRs even though I have preference for block height (it is better for mainnet and is part of BIP 8)
09:15 <@michaelfolkson> copumpkin: But I agree. It is totally exhausting and ridiculous
09:15 < jeremyrubin> you did just NACK ST at all though, to be clear
09:15 <@michaelfolkson> The problem is some people seem to enjoy it
09:16 < jeremyrubin> so your approach ACKs are invalidated if I'm interpreting you correctly
09:16 < jeremyrubin> unless you wish to clarify otherwise
09:16 < copumpkin> I'm not pointing at anyone in particular, just saying that even from the sidelines it's exhausting to watch and it must be far more if you have a horse in the race. Just want folks to realize that debate isn't some lofty ideal to strive for, and at some point we realize that we're not going to get anywhere close to our ideals and we just settle for good enough because that's better than worse-than-nothing (not nothing, because
09:16 < copumpkin>  nothing => significant ragequitting and frustrating about even the most uncontroversial stuff being frozen in gridlock, etc.), and move on.
09:17 <@michaelfolkson> jeremyrubin: Your games are so dumb lol. As I said I'm out. Enjoy your meeting
09:34  * jeremyrubin https://www.youtube.com/watch?v=DYivGrFkgIk
09:36 < AaronvanW> funky
09:53 -!- Alexandre_Chery [946686a4@148.102.134.164] has joined ##taproot-activation
09:56 -!- Alexandre_Chery [946686a4@148.102.134.164] has quit [Client Quit]
10:00 < copumpkin> michaelfolkson: chatted with Matt and he said he's still fine with ST
10:02 <@michaelfolkson> copumpkin: The two Speedy Trial PRs are waiting for Approach ACKs if he is fine with either block height or MTP
10:05 <@michaelfolkson> MTP and BIP 9 PR: https://github.com/bitcoin/bitcoin/pull/21377
10:05 <@michaelfolkson> Block height and BIP 8 PR: https://github.com/bitcoin/bitcoin/pull/21392
10:06 <@michaelfolkson> If he was to give Approach ACKs to both of those, that would be one concern lifted
10:25 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined ##taproot-activation
10:29 < roconnor> aj: Since activation burial is height based, won't every Signet eventually need their own "custom binary" in the end anyways to mark their burial height?
10:33 < harding> aj: roconnor corrects an error of mine and makes good points here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018740.html ; I wonder if it'd be reasonable to lockin at the next block after the min_lockin_time?  Is there a reason besides compatibility with BIP9 that lockin and activation need to happen on retarget boundaries?
10:42 < achow101> locking in on the next block after the lockin time would require a significant change to the state machine code
10:46 -!- vic3k [25789c4c@37.120.156.76] has joined ##taproot-activation
10:48 < harding> Ok.  That seems unlikely.  Having predictable times was my favorite reason for using MTP, but a two week ambiguity undermines that benefit IMO, leaving signet activations as the only reason I know of to desire MTP.  I'll wait until after the meeting to see if anything comes up and post to the mailing list that I accept my argument was flawed (thanks roconnor!).
10:50 < achow101> The signet argument remains unconvincing to me
10:51 < achow101> not to mention that it doesn't really make sense to me to hold up a current mainnet activation for future test network activations
10:51 < achow101> and other signets are going to have to carry around a bunch of config stuff anyways
10:51 < luke-jr> Suggest we redirect discussion of activation methods toward OP_NOINPUT ;)
10:51 < roconnor> Not only that, but if burial requires custom signet binaries anyways, then you might as well do custom height or flag-day based activation from the start on signets.
10:53 < achow101> luke-jr: at this point, I kind of agree. I think it might be better to punt the discussion for the "perfect activation method" to after taproot, but before the next soft fork is even significantly worked on. Clearly we need more time to figure out activations, and doing it when there isn't one hanging over our heads might be better
10:54 < achow101> since there are currently things at stake, emotions and impatience for the new thing are significantly affecting the discussion
10:54 < jeremyrubin> achow101: I think that a better thing is to not punt it to the next soft fork, but to just let it happen when it does
10:55 < jeremyrubin> and to actually work on it
10:55 < jeremyrubin> because I don't want to gate CTV on figuring out an unrelated issue
10:55 < achow101> jeremyrubin: moreso punt to a time where there isn't a currrent soft fork hanging over our heads.
10:55 < achow101> if we wait for it to come up again, it'll just be when we're ready to activate the next soft fork and we'll be back in the same discussion
10:55 < jeremyrubin> when I've already had to gate CTV pushing CTV out on taproot
10:57 -!- criley [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
10:58 -!- bjarnem [~bjarne@58.pool85-57-231.dynamic.orange.es] has joined ##taproot-activation
11:00 < luke-jr> no need to punt, we can continue discussion today without blocking Taproot on it
11:01 < harding> I'm not sure we expect most signets to live long enough for a soft fork to be buried (I think we currently wait at least a year after activation to do that?); however, every signet active at a time when a soft fork looks like it'll be activated will probably want to enable testing with the new rules.
11:04 < roconnor> I too thought that we would wait at least a year after activation to do a burial.  However a segwit burial was purposed a few weeks after activation, and it seems more like apathy rather than policy lead to the delay on segwit burial.  I'll have to review my logs here to find aj's research on the topic.
11:04 < jeremyrubin> harding: there is value for super-long header chain signets, but I suppose those can be backdate mined?
11:04 < luke-jr> roconnor: well, Segwit was an unusual case - Core would have had to merge BIP148 or bury, to stay in consensus
11:04 < jeremyrubin> e.g. we should run bignet with +5 years more blocks :)
11:05 < luke-jr> bury was simpler
11:06 < roconnor> luke-jr: I don't follow. What's the relevence of BIP148.  Weren't both nodes in effective consensus (baring a massive Bitcoin-killing reorg)?
11:09 < luke-jr> roconnor: right, the parenthesied bit ;)
11:09 < harding> jeremyrubin: I think the desire for a super long header chain signet runs counter to your desire to kill testnet3, which is exactly that.  :-)
11:09 < luke-jr> a reorg would have led Core nodes to an invalid chain, but burying avoided that without actual BIP148 enforcement
11:10 < roconnor> I don't get it.  Such a massive Bitcoin-killing reorg would bring burial and pre-burial nodes out of consensus too, so buring doesn't save anything in that situation.
11:11 < luke-jr> roconnor: only if the reorg respected Segwit's rules?
11:12 < luke-jr> and then it would arguably *be* consensus, not take them out of consensus
11:12 < luke-jr> (the value incentivising such a reorg would be to steal Segwit coins)
11:12 < roconnor> The problem with testnet3 isn't that it has a long header:  The problem is that it is broken: https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/ and randomly *actually* resets to difficulty 1.
11:12 < roconnor> er, difficulty 4.
11:12 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
11:13 < roconnor> luke-jr: Okay.  Um I'd have to think about that some more. ... but the obtuseness of the scenario makes me both not want to think about it any more, and also makes me think that this wasn't the reason for burial.
11:14 < luke-jr> roconnor: eh, I don't consider that broken - "works as designed"
11:14 < luke-jr> roconnor: I don't see a reason to delay burying in any case
11:14 < luke-jr> once we know when it's active, why wait?
11:15 < roconnor> luke-jr: the design was for only the next block to have difficutly 1 after 20 minutes (also a bad design but not as catastrophic as this bug), not litreally reset the difficult to 4 on a retargeting period whose previous block took longer than 20 mintues to mine.
11:16 < roconnor> luke-jr: harding was the one who was arguing that burials won't happen until 1 year after activation.  I agree with you that I don't think that is actually a policy.
11:16 < roconnor> (even though perhaps I would personally like it to be policy)
11:17 < luke-jr> IMO as soon as it's active, there's no reason to leave the door open to reorg games and can be buried in the very next release
11:17 < harding> roconnor: FWIW, I'm also in the testnet-should-go-away camp.  I was just teasing jeremyrubin.
11:18 < luke-jr> some testnet is desirable
11:18 < luke-jr> random Joes who want to test BitPay with MtGox should be able to do so without special interaction between the two
11:18 < roconnor> Right.  My remaining open question is how MTP helps signet activation if burial by height will cause issues anyways.  Harding attempted to answer that by suggesting signets will be destoryed before burial.  I'm not sure I find that argument pursausive.
11:18 < harding> I think default/prime signet is better for testing, assuming it's administered well (and people can switch to something else if it isn't).
11:20 < luke-jr> unless you're literally testing activation, IMO <all softforks> should just always be active on any test network
11:21 < achow101> is testing activation on a public testnet any better than testing in regtest?
11:21 < roconnor> That seems to be what was done with taproot.  Doesn't seem to have been a problem.
11:21 < luke-jr> achow101: IMO no
11:21 < achow101> imo if you want to make sure that your own node implementation handles activation correctly, it makes more sense to do it within regtest where you can control everything
11:22 < achow101> i suppose roasbeef can provide some insight on that
11:22 -!- Alexandre_Chery [946686a4@148.102.134.164] has joined ##taproot-activation
11:24 < roconnor> I'll add a second question:  It seems for taproot we just switched on taproot by default for all signets.  Why not just do this for all future softforks?  Is there some sort of problem with how we handled taproot?
11:25 < achow101> roconnor: in case someone makes a future soft fork invalid spend before it exists?
11:25 < achow101> but even then, that only happens if the signet operator allows it into a block, in which case, they've signed themselves up to have a hard time
11:25 -!- Alexandre_Chery [946686a4@148.102.134.164] has quit [Client Quit]
11:30 < jeremyrubin> Meetings starting in 30, recommend everyone take a quick breather before hand; calm minds and all
11:32 < copumpkin> om :)
11:35 < harding> roconnor: if IsStandard() relay rules are changed to allow relay of additional transactions at activation time (which has been done for several soft forks), then anyone who upgrades to an default activated node before the signet operator upgrades their node will relay and store in their mempool txes that will never get mined; you could use that to bandwidth flood everyone.  That said, signet coins have no value, so flooding RBF fee bumps
11:35 < harding> should also be possible?
11:38 < roconnor> This applies to taproot right? Taproot adds taproot spends to IsStandard()?
11:38 < harding> Yes, AFAIK.
11:38 -!- benthecarman [~benthecar@2600:1700:201:6e60:e785:240c:ef4b:cc0e] has joined ##taproot-activation
11:38 < roconnor> Good. Just making sure I'm on the same page.
11:40 < harding> (And P2TR outputs are already standard since 0.19 IIRC, so you could create the outputs you need for the spends.)
11:40 -!- rgrant [~rgrant@unaffiliated/rgrant] has joined ##taproot-activation
11:40 < achow101> it's always standard to create the outputs
11:41 < roconnor> I underand that pay to any witness version is standard.
11:41 < achow101> it is nonstandard to spend them until after activation
11:41 < harding> achow101: it was previously non-standard to use future witness versions.
11:41 < achow101> right, that was a bug
11:41 < harding> That was deliberate, but it was changed.
11:42 < roconnor> both a bug and delibrate.
11:42 < harding> :-)
11:43  * harding takes the recommended break; bb for the meeting
11:46 -!- Alexandre_Chery [946686a4@148.102.134.164] has joined ##taproot-activation
11:56 -!- shaunapps [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has joined ##taproot-activation
11:56 < Emcy> can you guys just deploy the speedy trial already
11:56 < Emcy> please
11:57 < Emcy> do you know how badly bitcoin needs to deploy fungibility improvement work?
12:00 < jeremyrubin> #startmeeting
12:00 < jeremyrubin> Hi!
12:00 < harding> hi
12:00 < robert_spigler> hi
12:00 < roconnor> Hi.
12:00 < OP_NOP> hi
12:00 < emzy> hi
12:00 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has joined ##taproot-activation
12:00 < bjarnem> hi (silent participant)
12:00 < rgrant> hi
12:01 < jeremyrubin> Welcome to the 2nd fortnightly taproot activation meeting hosted by yours truly
12:01 <@aj> hi
12:01 < jeremyrubin> We have 3 topics for discussion today as per the agenda
12:01 < luke-jr> hi
12:01 < ksedgwic> hi
12:02 < jeremyrubin> Before we begin, I want to encourage everyone to keep it friendly
12:02 < jeremyrubin> I also want to remind everyone of the rough schedule fleshed out last week
12:02 < achow101> hello
12:03 < jeremyrubin> If we want to stick to that (which is debatable, for sure), it's important that we work open mindedly today towards consensus on the codebase
12:04 < jeremyrubin> Lastly, before we get into the thick of it, thanks to everyone in attendence for your dilligence in coming here at all hours from all around the world and putting in the energy and work to make Bitcoin resilient
12:04 < benthecarman> hi
12:04 < jeremyrubin> Don't lose track that we're on the same team :)
12:04 < jeremyrubin> ok enough preaching for me
12:04 < harding> I second that thanks.
12:04 < jeremyrubin> #topic 1 AJ's update to MTP time.
12:05 -!- Alexandre_Chery6 [9466a499@148.102.164.153] has joined ##taproot-activation
12:05 < jeremyrubin> If you haven't followed, since our last meeting AJ has been making some compelling arguments to favor MTP over height.
12:05 < jeremyrubin> I think that AJ's best comments explaining it are in response to today's agenda as well as
12:06 -!- Alexandre_Chery6 [9466a499@148.102.164.153] has quit [Client Quit]
12:06 < luke-jr> non-compelling*
12:06 < jeremyrubin> https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-813896241
12:07 -!- Alexandre_Chery [946686a4@148.102.134.164] has quit [Ping timeout: 240 seconds]
12:07 < jeremyrubin> luke-jr: please keep it polite; you are free to argue them on the merits but I do not appreciate a correction denigrating the work AJ has put in. let's put pithy sarcasm aside and work together
12:07 -!- Alexandre_Chery [9466a499@148.102.164.153] has joined ##taproot-activation
12:07 < jeremyrubin> aj: is there anything else you would like to share comment wise to introduce the topic?
12:07 < luke-jr> Signet is not Bitcoin and should not be considered relevant to Bitcoin activation.
12:08 < jeremyrubin> luk-jr: that's topic 2
12:08 < jeremyrubin> in this topic it's to discuss things like LAST_CHANCE and if the changes are generally acceptable
12:08 < robert_spigler> What is aj's response to https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018740.html
12:09 < luke-jr> MTP is not generally acceptable in the first place
12:09 < jeremyrubin> a claim I'd like to discuss: is MTP technically compatible with mandatory activation
12:09 < rgrant> luke-jr: What is it about AJ's MTP changes, in their current form, that doesn't work for you?
12:10 < benthecarman> I still think block height is superior, but if MTP is chosen AJs improvements make me feel better about it.
12:10 < rgrant> robert_spigler: My response is that you should have an activation party on both weekends.
12:10 -!- real_or_random [~real_or_r@173.249.7.254] has joined ##taproot-activation
12:10 -!- gr-g [4dbeaeb3@x4dbeaeb3.dyn.telefonica.de] has joined ##taproot-activation
12:11 < jeremyrubin> rgrant: or a party through the entire period; why skimp :)
12:12 < robert_spigler> Joking aside, it was my impression that people believed that MTP was more accurate in predicting the activation time, but this turns out to not be true. Since this is the case, are there other arguments besides signet for MTP?
12:12 < copumpkin> (it would be nice if all objections to XYZ, whatever XYZ is, be qualified with "this is a hypothetical that seems unlikely, but isn't ideal" vs. "this is going to destroy civilization as we know it"; it may be obvious to the author of the objection, but to the countless silent readers it can be difficult to sort theoretical minor issues from major issues)
12:13 -!- Yerzhan [89dc490b@137.220.73.11] has joined ##taproot-activation
12:13 < harding> robert_spigler: FYI, that post by roconnor just went up a couple hours ago, and I believe it's extremely early in aj's timezone, so he may not have had a chance to think about it yet.
12:13 < rgrant> So, my take on NACKs is that if I don't understand it, then it does not affect my interpretation of rough consensus.  I have a duty to work to understand NACKs, but I don't care who sends them.  Only the reasons matter.
12:13 < achow101> roconnor pointed out on the mailing list that there is still significant uncertainties in predicting the actual activation time with mtp
12:13 < robert_spigler> harding: thanks
12:13 < jeremyrubin> the +/- 2 week thing is a mostly hypothetical concern, on top of a minor issue for a 3 month MTP if mid-period times are used
12:13 < achow101> this is in line with the other mtp uncertainty issues that have been pointed out in the past
12:14 < achow101> jeremyrubin: I think it has a significant real world concern, not purely hypothetical
12:14 < roconnor> FWIW, I don't think this is a catastrophic issue for MTP. I still concept ack it. But predicability of activation time isn't an argument that favours MTP, it favours height.
12:15 < achow101> in addition to the fact that we can't have good predictions until the lock in time. with height, it becomes more and more predictable
12:15 < harding> I agree with what roconnor just said (given my present understanding).
12:16 < achow101> agreed
12:16 < jeremyrubin> we'll switch to topic 2 shortly
12:16 < benthecarman> Has anyone done an analysis of how accurately you can predict the middle of a adjustment period that is 3 months out
12:16 < jeremyrubin> sorry to be dictatorial but let's keep this section on topic 1
12:16 < OP_NOP> Is there a link where I can read more about why predictability is actually that important, or a huge concern?
12:16 < achow101> jeremyrubin: can you link to the topics
12:16 < jeremyrubin> I'm very curious to hear luke-jr justify concrete unacceptability
12:17 < jeremyrubin> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018725.html
12:17 < benthecarman> OP_NOP: it's nice to have it on a predictable day so users and buissnesses know when to be ready
12:17 < harding> +1 for staying focused
12:17 <@aj> (i'm replying to roconnor's mail, which came through at something like 3am local time)
12:18 < robert_spigler> aj: sorry, didn't realize
12:18 < jeremyrubin> thanks AJ -- when it's done please pastebin it here since email can be slow
12:18 < rgrant> Can anyone state why time-range uncertainty matters?  Does it interfere with the goals of the mandatory activation (UASF) group?
12:18 < achow101> rgrant: it makes it difficult to inform people when they need to be upgraded by
12:18 < robert_spigler> I don't think what another group (UASF or otherwise) should matter in these decisions
12:19 < jeremyrubin> based on my undestanding (aj please correct) LAST_CHANCE can be added post-hoc and is compatible
12:19 < jeremyrubin> The notion of "hard to know when to upgrade" is for people who need to treat it (e.g. for infra) like a flag day
12:19 < achow101> IIUC aj's latest proposal allows for a UASF
12:19 < OP_NOP> benthecarman: That makes sense, but it doesn't seem like a show-stopper. Shouldn't Bitcoin businesses be expected to know that block heights & times are variable?
12:19 < robert_spigler> But predictiablity is important
12:19 < jeremyrubin> because for people who can upgrade software we already have the min active gap
12:19 < rgrant> achow101: Yeah, but you can give them an answer two weeks earlier if it's MTP, and if it's block heights then the estimate converges.  Doesn't seem like NACK material.
12:19 < jeremyrubin> so it's only if you have to flip a switch manually for some infra reason
12:20 < OP_NOP> Most businesses are probably not going to turn on support that close to the activation, and if they do, then they are probably sophisticated enough to understand variance
12:20 < benthecarman> OP_NOP: the concern isn't with block heights, but with using the timestamp in the block, it can give a +- 2 week window for activation
12:20 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined ##taproot-activation
12:20 < achow101> rgrant: indeed. this is merely an argument for which is better
12:20  * rgrant notes time.
12:20 < jeremyrubin> luke-jr: last chance to rebutt?
12:21 < OP_NOP> benthecarman: Yeah, heights are much better on that front, IMO
12:21 < jeremyrubin> otherwise it seems that aj's argument on LAST_CHANCE stands uncontested?
12:21 < achow101> so in terms of predictability, the heights proposal is actually better
12:21 < jeremyrubin> achow101: please wait a few minutes
12:21 < jeremyrubin> we'll compare the two shortly
12:21 < luke-jr> jeremyrubin: I am not interested in this topic, and consider discussing it further a waste of time. It has less community support than BIP8(True) and merging it would be an abuse of power.
12:21 -!- suntsu8 [d5c8ec17@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has joined ##taproot-activation
12:21 < harding> luke-jr: could you please stay silent or leave, then?
12:21 < luke-jr> harding: I'm trying to stay silent, but people keep nagging me to comment.
12:22 < harding> luke-jr: ok.
12:22 < benthecarman> OP_NOP: agreed
12:22 < jeremyrubin> Ok, so I think the effect of LAST_CHANCE is that it's possible to have a mandatory signalling period (not BIP8 LOT=true, but similar)
12:22 < jeremyrubin> AJ has also prepared code for such, so it shouldn't be an issue for UASF planners
12:22 < roasbeef> michaelfolkson chill dude, you seem to be presuming a lot, at times in software things can stay in the design phase for a while and that's fine
12:22  * rgrant thanks luke-jr
12:23 < jeremyrubin> roasbeef: he's not in the meeting
12:24 < rgrant> roasbeef: +1
12:24 < jeremyrubin> Ok anything else on this topic? Anyone have any issues with AJ's proposed changes to MTP?
12:24 < achow101> istm that aj's latest changes have made 21377 harder to review (in terms of analyzing mtp behavior) which negates the argument that mtp is easier to review
12:24 < harding> No issues.
12:24 < jeremyrubin> achow101: +1
12:24 < jeremyrubin> I no longer think MTP has a major mergeability advantage
12:24 < luke-jr> same issues remain.
12:24 < achow101> but conceptually, it's fine
12:24 <@aj> what do you think is hard to review about it?
12:25 < jeremyrubin> aj: it's not hard to review, just hard*er*
12:25 < jeremyrubin> we can talk about that more as topic 2
12:25 < benthecarman> I wouldn't say hard to review, but equal to review scale as achow101's pr
12:25 <@aj> ...
12:25 < jeremyrubin> Ok, topic2 time
12:25 < rgrant> aj: Yer baby's not ugly.
12:25 < jeremyrubin> #topic 2 Selecting between MTP and Height
12:26 -!- TechMiX [~techtux@188.126.217.46] has joined ##taproot-activation
12:26 < jeremyrubin> We are super lucky that both achow101 and aj are such competent developers that we have not one but two fantastic PRs to look at
12:26 <@aj> what do you think's harder to review about it than the previous patch?
12:26 < jeremyrubin> At the same time, we have two PRs to look at
12:26 <@aj> apart from additional tests it changes about as many lines in almost the exact same place
12:26 < jeremyrubin> aj: mo state machine changes mo problems
12:26 < roasbeef> achow101: imo yeah re testing on a public testnet, particularly for other implementations, you're getting new inputs that may have not been covered in your regtest env, and also it's easier to have others test out your tools/apps
12:26 < achow101> aj: convincing myself that the new behavior around the minimum lock in time doesn't have some edge case that I haven't thought of due to mtp
12:27 < achow101> changes to that state machine requires more analysis, and so it is on the same magnitude of review burden as the state machine changes to support heights
12:28 < benthecarman> achow101 +1
12:28 < jeremyrubin> In this section I'd like to remind people to check dug-in opinions at the door, what matters here is if we can agree on a plan of action and get the bulk of everyone on the same page. That said, there are nuanced technical points to examine that favour either approach
12:28 < jeremyrubin> I think the differences between MTP and height are less important than working towards a single PR to review
12:28 < rgrant> I'd like to point back to April 4th, where a coin toss was proposed.  I would accept a coin toss and feel we're very close.
12:29 < kanzure> coin toss can be done by blockhash bits
12:29 < jeremyrubin> kanzure: discussed in backlog
12:29 < luke-jr> NACK MTP
12:29 < achow101> I have a few technical issues with mtp, and one social issue
12:29 < harding> aj: I know you haven't had a chance to reply to roconnor yet, but do you think the +/- 2 weeks unpredictability around activation is something that's fundamental, or do you think it's something that you might be able to address?
12:29 < OP_NOP> Given two choices, I'd prefer the one with fewer edge cases and fewer total states, if that's possible
12:30 < harding> (fundamental to MTP)
12:30 < robert_spigler> My understanding: Predictability favors Height. Mergability is tied, Signet favors MTP. I don't quite understand the Signet argument, since I'd think that you'd want signet to test the ideal mainnet, but I'm not a Core developer
12:30 < jeremyrubin> The other argument for MTP is that you *actually* want wall clock time to upgrade
12:31 < jeremyrubin> and MTP can make it come late, but not early?
12:31 < roconnor> robert_spigler: I still haven't figured out how Signet is supposed to deal with burial of activation.
12:31 <@aj> harding: every time i address a complaint, i get met with "this is a farce" or "this is now way too hard to review, not that i'm going to review it anyway"...
12:31 < harding> robert_spigler: the signet argument is about signets (plural), e.g. making it easy for people to run a variety of test networks.
12:31 < TechMiX> why not both?
12:31 <@aj> harding: "to run a variety of test networks, with the same binary, without extra per-signet consensus configuration" perhaps
12:31 < jeremyrubin> aj: I think there are enough people silently considering open handedly, but loud individuals grandstanding
12:32 < achow101> aj: other signets will require conesnsus configuration anyways, no?
12:32 < achow101> at the very least, signetchallenge needs to be different
12:32 < roconnor> aj: how can you bury activations on signet with the same binary?
12:32 < jeremyrubin> achow101: the difference is if it's set-and-forget or requires updates
12:32 < OP_NOP> jeremyrubin: I think most people just want to move forward with something, hence the growing consensus around a coin flip
12:33 < jeremyrubin> OP_NOP: acknowledged
12:33 < BlueMatt> what is the practical likelyhood that a height-based activation activates significantly far off from the target date?
12:33 < luke-jr> OP_NOP: there's effort to move forward with BIP8(True) no matter what happens (or doesn't) with ST
12:33 < achow101> aj: I recommend ignoring those who are making "this is a farce" statements
12:33 < BlueMatt> (and please define "significantly" for me in your response)
12:33 < roasbeef> benthecarman: no major services will use softforks on day 1, so the activation likely will just gate requirements gathering w.r.t their eventual roll out, also the nature of the update is that it's mostly meta, so will likley have a longer uptake period than tapproto for services not doing fancier stuff w/ script
12:34 < OP_NOP> roasbeef: +1
12:34 < rgrant> achow101: You said you have technical arguments against MTP.  Can you remind us which ones?
12:34 < achow101> BlueMatt: defining significantly as "more than 1 week", I think the likelihood is low, but I have not done the analysis
12:34 <@aj> roconnor: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-809011351
12:34 < benthecarman> roasbeef: yeah but they will want the ability to verify taproot txs in the case that someone broadcasts a taproot spend. They don't want to end up on the wrong chain on accident
12:34 < BlueMatt> achow101: thanks, I'd appreciate some formal check on that, it does seem to be a part of the discussion
12:34 < harding> aj: I'm sorry about that.  I'm asking because predictability of activation time was my favorite benefit for using MTP, but it appears that was based on my misunderstanding.  I'm wondering if we can reasonably get that attribute.
12:34 < achow101> especially if calculations are done with 9.7 minute block time
12:34 < jeremyrubin> If you are on board with a coinflip, you can do '/me coinflip' and we'll look at block tip 678059+20 for the last bit, where 1 ==> MTP 0 ==> Height
12:34 < robert_spigler> Doesn't running a custom signet require administrative work? How difficult is it to do so with extra config files etc?
12:35 < robert_spigler> I truly don't know
12:36 < OP_NOP> luke-jr: That's right, thanks
12:36 <@aj> BlueMatt: for the 3 month speedy trial timeline, there's about a 2 day window where times and height could conceivably result in different results, based on the selected targets from the other week as per some bitcoin-dev emails
12:36 < roconnor> aj: are you saying we'd bury a taproot deployment on mainnet via MTP then? Or we would have signet and mainnet bury in different ways?
12:36 < achow101> rgrant: the lack of predictability, and the uncertainty in exact times of state transitions due to reorgs
12:36 -!- vic3k [25789c4c@37.120.156.76] has quit [Quit: Connection closed]
12:37 -!- vic3k [25789c4c@37.120.156.76] has joined ##taproot-activation
12:37 < achow101> s/time/height
12:37 < roasbeef> jeremyrubin: RNGesus take the wheel
12:37 <@aj> roconnor: those are the only two options i've come up with, yeah
12:37 < robert_spigler> achow101: are you saying reorgs are more dangerous with MTP?
12:38 < roconnor> aj: my other question for you was, given that taproot was simply activated on default signet, why not continue to do that for activations?
12:38 < achow101> robert_spigler: reorgs can change mtp which can change when certain things happen
12:38 < roconnor> er I mean for future softforks.
12:38 < BlueMatt> robert_spigler: I believe its a comment about how, in theory, you could have taproot activate, then have a reorg which decreases the MTP at the activation block, which is no longer an activation block, and have to wait 2 weeks
12:38 < luke-jr> inb4 uasf to restrict MTP to ensure activation occurs 2 weeks sooner <.<
12:39 < roasbeef> I like height since it just goes up, so it's easy to think about, but at this point seems like perfect is the enemy of good, and we're getting into diminishing returns at the tail end
12:39 < robert_spigler> achow101: BlueMatt thanks
12:39 < roasbeef> roconnor: +1 signet is basically just a private regtest, ppl can change at will, the number of ppl using it is like < 100 or something
12:40  * roasbeef coinflip
12:40 -!- jonny1000 [1f33335f@host31-51-51-95.range31-51.btcentralplus.com] has quit [Quit: Connection closed]
12:40 < harding> roasbeef: once again, this is about making it easy for people to operate a variety of signets, not the main signet
12:40 -!- jonny1000 [1f33335f@host31-51-51-95.range31-51.btcentralplus.com] has joined ##taproot-activation
12:40 < harding> this argument for MTP*
12:40 < OP_NOP> roasbeef: height number go up is easy to understand. Around the UASF / Cash fork time, there was widespread confusion around MTP and fork activation
12:40 < roasbeef> it's easy given you can just detroy it and redo it right? harding, compared to testnet which has more intertia
12:40 < rgrant> achow101: Once the states are set, then the activation moment is predictable.  It's just that we won't know until late.  I agree this is not as great as the way block heights converge.
12:40 < roasbeef> OP_NOP: yep, height number go up
12:41 < robert_spigler> if predictability and safety favor height, mergability is tied, and signet is used by so few (and seems to be still debated),  height seems the objective winner to me
12:41 < roconnor> harding: you are saying that activating taproot by default on signet has made it harder to operate a variety of signets?
12:41 < harding> roasbeef: I expect most signets will be relatively easy to destroy and recreate, but it'll be a pain for some of them
12:42 < BlueMatt> robert_spigler: its also unclear if predicability and safety favor height in the abstract, only maybe now because of the compressed timeline. in an abstract fork with a year or more timeline, there's a stronger argument for MTP.
12:42 < roasbeef> I guess "pain" here is relative, particularly if only a hand ful of ppl around the world need to update, and there's no risks given it's just regtest
12:42 < harding> roconnor: no, because I believe the same Bitcoin Core release that first included signet (0.20) also had it default activated with taproot.
12:42 < roasbeef> fwiw btcd doens't have signet at all rn, so we just wouldn't impl w/e signet checks in the state machine that are added
12:42 < luke-jr> 0.20 didn't even have Taproot
12:42 < robert_spigler> BlueMatt: but we're not discussing ideal activation methods right now, just ST
12:42 <@aj> roconnor: for concreteness, suppose we're talking about ANYPREVOUT (APO). we write some code, and activate APO on signet (by whatever method). we then find there's bugs, and want to make incompatible changes to the APO implementation and redeploy. the new signet activation height needs to be greater than the original APO activation height, to avoid forcing the signet chain to reorg out any
12:42 <@aj> transactions made under the first set of APO rules
12:42 < achow101> I would like to point out that Greg Sanders (the meeting is not at a good time for him) has pointed out that other signets will likely need to carry around a bunch of configuration parameters anyways. This position comes from his experience with operating the Elements and Liquid networks.
12:43 < harding> roconnor: sorry, 0.21.0, and I've confirmed that with the release notes: https://bitcoincore.org/en/releases/0.21.0/
12:43 < emzy> signet should not considered for this decision.
12:43 < BlueMatt> robert_spigler: I understand that, but merging a ton of code which changes how core works, only to later revert it for future soft forks is *really* not a great way to do development.
12:43 <@aj> roconnor: with MTP based activation, it's easy to just pick a future MTP for the second activation, since no signet will have a block at that MTP yet
12:43 < roconnor> harding: thank you.
12:43 < roasbeef> aj:  or just hardfork the signet lol
12:43  * rgrant notes time.
12:43 < harding> roconnor: "This release adds support for signets [...] Experimentation with Taproot can be done on signet, where its rules are already active"
12:44 < luke-jr> BlueMatt: it's not terrible either. better than spending extra time upfront finding the perfect
12:44  * benthecarman coinflip
12:44 < achow101> aj: is that not a hard fork anyways?
12:44 < roconnor> aj: what is the likelyhood that the bugfixxed APO will be a softfork?
12:44 < BlueMatt> luke-jr: indeed, both are largely fine with me.
12:44 < jeremyrubin> \me TIME: we'll run the meeting until 20:30 (1.5 hours)
12:44 <@aj> roconnor: "incompatible" == not a soft fork vs the previous implementation of APO
12:44 < achow101> if a new iteration of APO is incompatible, then the old one has to be disabled and that's a hard fork
12:45 < roasbeef> lol it's a private multi-sig network, the operator can do w/e they want, ppl can move to another one if the opeerator does weird stuff or breaks things
12:45 < roconnor> achow101: +1
12:46 <@aj> achow101: an incompatible change to an experimental feature on signet means it's a "hard fork" for anyone using the feature -- they have to upgrade their node software from the previous version, but remains a soft fork for anyone not using the feature -- their node software continues following the chain
12:46 < luke-jr> it's a test network. who cares?
12:46 < harding> roasbeef: correct, but that doesn't mean it isn't useful to make it easy for people to administer and use such a network, which lets us test out a variety of possible changes independently from each other.
12:46 < harding> luke-jr: I thought you were trying to stay silent?
12:46 < robert_spigler> "the new signet activation height needs to be greater than the original" vs "it's easy to just pick a future MTP"  Why is the later easier than the former?
12:47 < luke-jr> harding: topic 1 is long over
12:47 < jeremyrubin> I think that Signet has abstract value in that we want to get to a point where we have all our vbits used at once
12:47 < benthecarman> imo no reason to bike shed over signet activation when taproot is already default on for the network
12:47 < jeremyrubin> if there are changes that make it easier to have all the vbits used then I support that
12:47 < jeremyrubin> i'd love to e.g. do a vbit for experimental CTV signet tomorrow
12:48 < roconnor> jeremyrubin: maybe you should be using the ASICBOOST area on signet for experimental vbits.
12:48 < achow101> robert_spigler: heights will be different across all signets, whereas mtp is the same
12:49 < jeremyrubin> Question: are we worried about using heights if the period falls around a halving?
12:49 < robert_spigler> achow101: ah, got it thanks
12:49 <@aj> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018741.html
12:49 < jeremyrubin> achow101: ^^ maybe you can answer. I think MTP there is no issue, but you could see a big hashrate decrease (which would be bad) at a halving
12:49 < rgrant> It seems like Greg Sanders' take on this as reported by achow101 is the most informed.  Signet shouldn't matter.
12:49 < jeremyrubin> Should height based activations avoid that period?
12:50 < roconnor> jeremyrubin: might be an issue for softforks that relate to coinbase outputs.
12:50 < achow101> jeremyrubin: why would a halving matter?
12:50 < benthecarman> I thought this had to with taproot activation?
12:50 <@aj> BlueMatt: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018720.html was numbers for matching mtp/height params for speedy trial
12:50 < harding> aj: thanks!
12:50 < achow101> benthecarman: the argument for mtp with signets revolves around future soft forks
12:51 < robert_spigler> I just don't understand why future soft forks matter for this conversation
12:51 < benthecarman> ^
12:51 < jeremyrubin> core devs are lazy and don't want to have to do review more changes later
12:51 < jeremyrubin> :)
12:51 < robert_spigler> There's no indication ST will be used in the future, and I thought everyone wanted to continue discussion towards ideal activation methods
12:51 < OP_NOP> robert_spigler: +1
12:51 < roasbeef> harding: sure, ppl can just make a new one right? and just port over the utxo state or w/e
12:51 < achow101> robert_spigler: benthecarman whatever we do now will set precendence (and existing code) for future soft forks
12:52 < jeremyrubin> robert_spigler: I think that's like it's not certain, but it's likely absent something much better
12:52 < jeremyrubin> so it will be used until the better thing is made
12:52 < jeremyrubin> but the better thing won't block others from using it again
12:53 <@aj> from my perspective, ripping out the MTP signalling code now, means i'll need to do a patch in future to bring it back in to do APO on signet
12:53 <@aj> (probably, presuming no one comes up with some genius better idea)
12:53 < harding> roasbeef: anyone can make a new one, although part of the goal here is making it run with an unmodified Bitcoin Core (or other node) binary, which would not be compatible with porting over the UTXO state (since coinbase txids would differ, so you could'nt just replay txes).
12:53 < roconnor> aj: or you can do a FLAG day APO activation for default signets
12:53 < jeremyrubin> aj: what if we just forked the logic and allowed either MTP or Height?
12:53 < jeremyrubin> roasbeef took that approach with BTCD
12:54 < roconnor> I don't know why I wrote flag in all caps ...
12:54 < roasbeef> jeremyrubin: yeh, they're more or less compatible-ish, rn we support both as it just EndTime(blockHeader)
12:54 <@aj> roconnor: why would i do that when i could do something that actually works with custom signets, particularly given every soft fork is likely to be tested on a custom signet before being merged?
12:55 < roconnor> flag days work with custom signets.
12:55 < achow101> flag days are essentially mtp buried deployments
12:55 < achow101> or could be implemented in the same way
12:56 <@aj> roconnor: oh, are you talking about MTP flag days not buried-by-height?
12:56 < Emcy> please dont let minutia concerns about signet hold up taproot deployment? wtf
12:56 < roasbeef> roconnor: +1
12:57 < roconnor> aj: I mean, I would just activate APO like taproot, but I'm saying that reimplementing MTP signaled activation for APO is not your only choice here.
12:57 <@aj> jeremyrubin: (because that would be even harder to review?)
12:58 <@aj> roconnor: we treated taproot as if it were already active on mainnet, that doesn't work for testing future soft forks
12:59 < roconnor> oh right, because signet and taproot were released at the same time.
13:00 <@aj> roconnor: because taproot was merged well before signet and had already its incompatible changes finished (eg the 33->32 byte pubkeys)
13:00 <@aj> had already had
13:00 < robert_spigler> Should we choose a riskier and less predictable mainnet activation method to allow for testing it easier? How difficult is it really for custom signet operators?
13:02 < achow101> aj: is it necessary to have signets do a versionbits deployment?
13:02 < BlueMatt> can we just put aj and achow101 in a room until one closes his pr?
13:02 < robert_spigler> lol
13:02 < harding> robert_spigler: for every soft fork, every user of a signet who wants to relay transactions made possible by the fork, will need to add a custom setting to their bitcoin.conf, which is a coordination headache, especially when some people will be running on multiple signets.
13:03 < harding> BlueMatt: I think that's the "coinflip" option.
13:03 <@aj> BlueMatt: no, australians aren't allowed to travel out of the country
13:03 < BlueMatt> harding: eh, I like making the two authors figure it out :)
13:03 < jeremyrubin> what about into the country
13:03 < BlueMatt> aj: I'll overnight you a vax
13:03 <@aj> BlueMatt: you say that like it makes a difference
13:04 < benthecarman> do you guys have VR headsets?
13:04 < jeremyrubin> let's keep it focused here
13:05 < robert_spigler> harding: ok thanks
13:05 < luke-jr> Anyone who wants to actually get Taproot activated instead of endless second-guessing over the bikeshed colour… Care to help out toward deploying BIP8(start = Apr 30; min activate = Nov 12; timeout = 2022 Nov 11; LOT=True) ?
13:05 < robert_spigler> harding: even after buried?
13:06 < benthecarman> I think test networks should accommodate to mainnet, not the other way around. Arguing over what works with signet doesn't seem like the best use of time
13:06 < achow101> if signets do a mtp flag day, what's the problem with heights based versionbits for mainnet?
13:06 < jeremyrubin> luke-jr: so time based? why didn't you use heights lol
13:06 < luke-jr> aka Plan Y discussed a few weeks ago
13:06 -!- Yerzhan [89dc490b@137.220.73.11] has quit [Quit: Connection closed]
13:06 < luke-jr> jeremyrubin: BIP8 is heights
13:06 < achow101> jeremyrubin: BIP8 == heights based
13:06 <@aj> achow101: what's the benefit?
13:06 < jeremyrubin> "BIP8(start = Apr 30; min activate = Nov 12; timeout = 2022 Nov 11; LOT=True)"
13:07 < jeremyrubin> anyways
13:07 < achow101> aj: mtp flag day doesn't conflict with heights versionbits
13:07 < harding> robert_spigler: burying seems to be an unresolved issue with soft forks on signet.
13:07 < robert_spigler> harding: thanks
13:07 < robert_spigler> if signet remains unresolved, I agree with benthecarman:
13:07 <@aj> achow101: ugh, reading is hard
13:07 < achow101> and I think we have established that mtp versionbits has no clear benefits over heights versionbits now for mainnet
13:08 < robert_spigler> I think test networks should accommodate to mainnet
13:08 < jeremyrubin> I think the state machine could be generic to either height or time. What if we base off of the MTP version and patch on the ability to tag the deploy to heights?
13:08 < robert_spigler> and predictability and safety favors heights
13:08 <@aj> achow101: mtp signalling on signet is important to allow signets not to automatically be enforcing rules that are entirely experimental or not available on mainnet at all
13:09 < harding> I think both MTP and heights are fine for mainnet, so one of them having an advantage for test networks seems worth considering.
13:09 <@aj> achow101: s/mtp//
13:09 < rgrant> This topic seems to be winding down.  I'm hearing: that signet configuration isn't a dealbreaker but there is technical debt incurred if we ignore it; MTP-based activation (read: celebration parties) can be known weeks in advance if parameters are chosen well; and that code reviews matter.  Coinflip seems to be winning.
13:10 < jeremyrubin> Ok let's maybe switch to a poll topic for 5 minutes to just collect where people are actually at:
13:10 < jeremyrubin> #topic 2.a poll
13:10 < jeremyrubin> NACKs
13:10 -!- proofofkeags [~proofofke@97-118-239-55.hlrn.qwest.net] has joined ##taproot-activation
13:10 < achow101> aj: let me think on that for a bit. we may be able to find a solution
13:11 < jeremyrubin> count luke-jr NACKing MTP
13:11 < jeremyrubin> any other NACKS for anything?
13:11 < TechMiX> NACK MTP
13:11 < robert_spigler> no NACK from me
13:11 < jeremyrubin> TechMiX: who are you?
13:11 < rgrant> TechMiX: your reason?
13:11 < BlueMatt> jeremyrubin: lets give aj and achow101 a minute to figure out if they can agree on something
13:12 < rgrant> BlueMatt: +1
13:12 < jeremyrubin> rgrant's question is better, I just want to link it to any other former opinion
13:12 < jeremyrubin> Ok
13:12 < robert_spigler> 🤞
13:12 < jeremyrubin> good point
13:12 < jeremyrubin> #topic only AJ and achow101 to discuss, others please keep quiet
13:13 < jeremyrubin> (if you don't want to be on the spot we can not do this here and now, but it's important before topic 3 in any case)
13:13 < TechMiX> rgrant: timechain has it's own way of labeling events and it's called block height. I don't understand why should we use the seconds past 1970 for an event in bitcoin
13:16 < rgrant> TechMiX: this seems like a preference for one form of setting the activation moment over another, but most other people in the meeting consider either acceptable.  AFAICT, the people who are NACKing something at this point are frustrated with the process and are not giving reasons why the other way can't work.
13:16 < jeremyrubin> TechMiX: it's technical misunderstanding there; MTP is used for difficulty adjustments
13:18 < jeremyrubin> i've been told theres some pming going on, in case anyone is in suspense
13:18 < robert_spigler> 😀
13:18  * roasbeef suspense increases 
13:18 < BlueMatt> does anyone care to do a tap dance for us?
13:18 < luke-jr> rgrant: rather, the reasons were already given in excess
13:18 < BlueMatt> maybe a drumroll?
13:18  * copumpkin does a tap dance
13:18 < jeremyrubin> taproot dance?
13:18 < robert_spigler> nice
13:19 < BlueMatt> in other news, if anyone ever wants to insert flowspec rules into their linux router using xdp, have *I* got a project for youuuuuu https://github.com/TheBlueMatt/flowspec-xdp
13:19 < jeremyrubin> BlueMatt: if we're doing shameless plugs, follow my soundcloud learn.sapio-lang.org
13:20 < jeremyrubin> Ok, so I know there's some PM-ing going on, but I did promise the meeting would end in 10 minutes.
13:20 < rgrant> luke-jr: But with the pull requests changing, and with the MTP people claiming that the activation is predictable enough to schedule a UASF against (because it ends in block height), I think the burden of proof shifts back to you.
13:21 < Emcy> im happy to wait
13:21 < benthecarman> i can wait
13:21 < robert_spigler> I unfortunately have to go, but I will be back to read the backlog
13:21 < jeremyrubin> if you want, we can take a coinflip poll in the meantime. Let's use harding's script:
13:21 < harding> Maybe come back in 40 minutes, 21:00 UTC?
13:21 < luke-jr> rgrant: it doesn't anymore
13:21 < robert_spigler> Thank you for the meeting!
13:21 < jeremyrubin> bitcoin-cli getblockhash 123456 | cut -b64 | grep -q '[02468ace]' && echo MTP || echo height
13:21 < jeremyrubin> with the blockheight I mentioned previously
13:22 < jeremyrubin> And coinflip will be (either AJ and Achow agree on a path || coinflip)
13:22  * jeremyrubin conflip
13:22  * harding (either AJ and Achow agree on a path || coinflip)
13:22  * benthecarman coinflip
13:23 < benthecarman> what block height
13:23 < jeremyrubin> i said prior... 1 sec
13:23 < jeremyrubin> 678059+20
13:23 < BlueMatt> block 700,000? nice round number
13:24 < jeremyrubin> (btw there's a reason I'm picking a height and not an MTP :p)
13:24 < BlueMatt> lets debate block height!
13:24 < rgrant> luke-jr: Accepting that for the moment, can't UASF still run the MTP logic and then pick a reasonable block height that's past the activation date?
13:25 < luke-jr> rgrant: that doesn't make sense
13:25 < jeremyrubin> startheight: whatever block the MTP ended being, stopheight so far in the future it doesn't matter
13:25 < jeremyrubin> Any other coinflippers (roasbeef assuming you're on board still?)
13:25 < roasbeef> yeh it's just a time bound
13:27 < jeremyrubin> I think a rough plan is that everyone who signed up to coinflip should review carefully, and then, barring any concerns, ACK the relevent PR.
13:28 < rgrant> Maybe this is a communication issue.  luke-jr has clear code to run, and people (including me) are saying he could write other code, but it's all abstract.
13:28 < jeremyrubin> If AJ and achow101 agree to advocate something else that's simple, great, we can evaluate that
13:29 < jeremyrubin> #topic 3 Timeline
13:29 < jeremyrubin> W.r.t. the above, I think if we collect ACKs on one of the proposals we can stick to the timeline from last week
13:30 < rgrant> +1
13:30 < jeremyrubin> If AJ and Achow come up with something in the next day or so, we can do that.
13:30  * rgrant goes AFK.
13:30 < jeremyrubin> Otherwise, we should just proceed with picking sane params
13:30 < jeremyrubin> rgrant: are you coinflip?
13:30 < benthecarman> Can the PRs be merged that quickly?
13:31 -!- bjarnem [~bjarne@58.pool85-57-231.dynamic.orange.es] has quit [Quit: Leaving]
13:31 < jeremyrubin> benthecarman: I think it's conceivable if we have everyone who coinflipped commit to reviewing this week
13:31 < jonatack> hi, have been reading up. back in a bit to see `what achow101 and aj come up with || coinflip` to settle on a patch to review
13:31  * harding runs watch 'bitcoin-cli getblockhash $((678059+20)) | cut -b64 | grep -q '[02468ace]' && echo MTP || echo height'
13:32 < rgrant> jeremyrubin: Yes, where coinflip now includes the option for AJ+AChow consensus.
13:32 -!- prayank [~andr0irc@2402:8100:206c:37a3:4b5d:8093:f69b:fcf7] has joined ##taproot-activation
13:32 < jeremyrubin> jonatack: the script that harding set determines a group consensus on people who care more about timeline for taproot than mtp/height for ST
13:32  * emzy gets "Block height out of range" as a result. :)
13:33 < jeremyrubin> emzy: operatively, it's a height for later today
13:33 < emzy> I see height. ;)
13:33 < jeremyrubin> Anyone have anything else to say in the meeting? aj? achow101?
13:33 < benthecarman> jeremyrubin: cool, have ACKed achow101's PR so will spend some time reviewing ajs
13:33 < jeremyrubin> (feel free to go with the coinflip plan even if you don't want to publicly commit to it)
13:34 < jeremyrubin> will end the meeting at 13:40 if there's nothing else
13:34 < Emcy> was there a third topic
13:34 < jeremyrubin> that was it; basically if we can keep timeline or not
13:35 < jeremyrubin> with enough people on the coinflip plan, we probably can as an expeditious release
13:35 < Emcy> k then
13:35 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::3] has left ##taproot-activation ["Leaving"]
13:36 < jeremyrubin> (coinflip being either a compromise between aj/achow101 in the next short period, or we go with harding's script)
13:36 < harding> ACK trying to keep previous schedule.
13:36 < jeremyrubin> If we don't have enough dev muscle behind coinflip, then we'll fail to get a release out and then we'll prolly slip schedule
13:37 < roasbeef> ACK re schedule and RNGesus
13:37 < jeremyrubin> previous discussion noted not wanting a release beyond early may, and not wanting minheight to fall after Nov 20th and before Chinese new year
13:37 < jeremyrubin> so it means we'd likely slip several months
13:37 < Emcy> maybe dont do that
13:38 < jeremyrubin> Emcy: hence coinflip, if you want to break stalemate and move on
13:38  * jonatack coinflip
13:38 < luke-jr> or just work on BIP8(True)
13:38 -!- stortz [bb3fbd57@unaffiliated/stortz] has joined ##taproot-activation
13:38 < jeremyrubin> BTW; if someone chooses to orphan a block to have a 50% chance at changing the coinflip, I would encourage you to just use the money to pay a developer instead
13:39 < luke-jr> lol
13:39 < jeremyrubin> We'll finalize the coinflip +6 blocks after it for the avoidance of any uncertainty
13:40 < Emcy> just flip a fucking coin on camera
13:40 < jeremyrubin> Emcy: where's your sense of fun
13:40 < benthecarman> lol does this coinflip create a perverse incentive for miners
13:40 < jeremyrubin> Ok this concludes the meeting.
13:40 < luke-jr> what kind of coin
13:40 < jonatack> jeremyrubin: thanks, great job
13:40 < jeremyrubin> Thanks everyone for coming and having a good faith discussion of the options
13:41 < benthecarman> thanks as always jeremy!
13:41 < luke-jr> next week's meeting will be to finalise BIP8(True) params/code
13:41 < jeremyrubin> I would have loved to have reached a technical preference, but I feel satisfied that we have a community direction to proceed with
13:41 < harding> jeremyrubin: thanks for running the meeting!
13:42 < jeremyrubin> There is no meeting scheduled for next week, but in 2 weeks we can hopefully discuss the merged code and any other RC1 testing needing
13:42 < jeremyrubin> congrats!
13:42 < jeremyrubin> #endmeeting
13:42 < luke-jr> jeremyrubin: there is now
13:42 < emzy> thank you jeremyrubin!
13:44 < luke-jr> adding a coinflip in and pushing "dev muscle" against NACKs and lack of community support just makes this road more farcical than it was before today, not less
13:45 < jeremyrubin> people selecting coinflip because they think the interest in timeline outweighs any individual perceived technical benefit
13:45 < jeremyrubin> it's not a don't care, it's a recognition there are two decent proposals with different tradeoffs
13:45 < jeremyrubin> and a desire to break stalemate on it mutually and voluntarily
13:45 < luke-jr> there aren't.
13:45 < jeremyrubin> if you can't accept that then
13:45 < jeremyrubin> stay mad
13:48 < jeremyrubin> jonatack pointed out I said "conflip", so for the avoidance of doubt
13:48  * jeremyrubin coinflip
13:48 < luke-jr> "con" was more accurate.
13:49 < roasbeef> luke-jr: if you want have your node just start enforcing in a year ofc you're free to do that
13:49 < jeremyrubin> luke-jr: so what? If coinflip means people review height ST you won't recognize those reviews + ACKs as having social merit?
13:49 < copumpkin> IMO coinflip is more of an acknowledgment that the two CRs differ largely in shed color and that we all want the shed, and don't care as much about its color
13:49 < BlueMatt> roasbeef: at this point, just ignore luke-jr
13:49 < roasbeef> copumpkin: +1, it's about progress
13:49 < jeremyrubin> roasbeef: actually I know one person is already running taproot and sync'd no problem
13:49 < benthecarman> see yall in ~3 hours
13:49 < BlueMatt> what copumpkin said
13:49 < jeremyrubin> so some would say it's already active
13:50 < copumpkin> (not to minimize the differences between them, but gotta keep the big picture in mind and not die on hills that don't need dead people on them)
13:50  * copumpkin disappears back into the shadows
13:51 < luke-jr> jeremyrubin: achow101's PR already has sufficient review to merge a week ago
13:52 -!- Alexandre_Chery [9466a499@148.102.164.153] has quit [Quit: Connection closed]
13:52 < stortz> why hasn't it been merged then
13:52 -!- Alexandre_Chery [9466a499@148.102.164.153] has joined ##taproot-activation
13:52 -!- suntsu8 [d5c8ec17@23.236.200.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Quit: Connection closed]
13:52 -!- Alexandre_Chery [9466a499@148.102.164.153] has quit [Client Quit]
13:52 < luke-jr> the MTP trolling
13:56 -!- gr-g [4dbeaeb3@x4dbeaeb3.dyn.telefonica.de] has left ##taproot-activation []
14:00 -!- prayank [~andr0irc@2402:8100:206c:37a3:4b5d:8093:f69b:fcf7] has quit [Quit: irc thread exit]
14:01 -!- jonny1000 [1f33335f@host31-51-51-95.range31-51.btcentralplus.com] has quit [Quit: Connection closed]
14:04 -!- CriptoLuis [be9ba048@190.155.160.72] has joined ##taproot-activation
14:06 < Emcy> luke-jr stop trying to blow up whatever small consensus has been achieved today
14:06 < Emcy> yes the whole thing was pretty stupid overall, but continuing to point that out will only prolong it at this point. just let it pass.
14:07 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
14:07 <@aj> Emcy: blowing up any approach other than bip8(lot=true) is luke's preferred outcome
14:08 -!- CriptoLuis9 [be9ba048@190.155.160.72] has joined ##taproot-activation
14:09 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
14:09 < BlueMatt> aj: yea, we know :/
14:10 -!- CriptoLuis [be9ba048@190.155.160.72] has quit [Ping timeout: 240 seconds]
14:11 < Emcy> i honestly dont give a flying fuck the exact manner of activation, what i do know is that activation does need to happen and preferably sooner rather than later
14:12 < Emcy> https://sethsimmons.me/posts/fungibility-graveyard/ these are the stakes [ignore the monero shilling and just look at the incident list]. These fungibility incidents are only going to get worse, and i think its going to get worse rather quickly. bitcoin needs taproot.
14:15 < Emcy> TechMiX so what the hell is 'timchain'
14:17 < stortz> I don't know if taproot will help with fungiblity problems
14:18 <@michaelfolkson> Although beating up on luke-jr is everyone's favorite pastime he hasn't Approach NACKed a Speedy Trial PR because test networks considerations somehow hold sway over mainnet. That has got to be the most absurd thing I've read so far
14:18 <@michaelfolkson> (And there have been a lot of things to compete with that over the weeks and months)
14:19 < luke-jr> Emcy: no consensus was achieved today in the first place
14:19 < roasbeef> chill m8, you're on 11, everyone else is chilling at 2.1
14:21 < luke-jr> Emcy: ignoring everyone who disagrees isn't consensus, it's NYA-style malice
14:21 < Emcy> >everyone
14:21 < Emcy> its mainly just you
14:22 < luke-jr> no, it isn't. trying to spin it as just me is also malice
14:22 <@michaelfolkson> roasbeef: Talking to me? I'd love to chill. I have nightmares that this channel will still be going round in circles later in the year :)
14:22 < Emcy> assume what you like about my motivations
14:23 < Emcy> i think i just made them clear in any case
14:24 < OP_NOP> michaelfolkson: ##taproot-activation-4-eva
14:24 <@michaelfolkson> If people are still arguing over block height vs MTP or whatever other iteration months later when this was supposed to be "Speedy" Trial that would be ironic
14:24 < roasbeef> michaelfolkson: idk what to tell you if you're having nightmares lol, but as I mentioned above ppl can just start enforcing taproot today w/ their nodes if they really want to, your tone lately comes across as overly standoffish and doesn't seem to be really productive fwiw
14:25 < Emcy> michaelfolkson why did did nack your own pr then
14:25 <@michaelfolkson> roasbeef: That's fair. You have had the luxury of dipping in and out of this nonsense over the last 2-3 months. So I would encourage you to consider that :)
14:26 <@michaelfolkson> Some of us have decided not to take that luxury
14:26 <@michaelfolkson> (and regret that)
14:27 < jeremyrubin> everyone has that luxury -- blink twice if someone is making you work on this
14:27 < roasbeef> yeh you seem a bit too "in" to it as mentioned above
14:27 < roasbeef> you decide what to do w/ your time
14:27 <@michaelfolkson> Sunk cost fallacy :)
14:28 <@michaelfolkson> Emcy: If Speedy Trial isn't speedy then there really is no point to it. A Speedy Trial in 6 months or a year is just dumb
14:28 <@michaelfolkson> Emcy: The whole point was to do something relatively quickly. If it isn't going to be quick it has been a waste of time
14:29 < Emcy> right now itll still be speedier than several more months of bullshit discourse, so nacking yourself was premature as hell imo
14:30 <@michaelfolkson> If people are going to Approach NACK a PR based on test networks it is dead
14:30 < roasbeef> stepping back a bit would prob do you a lot of good michaelfolkson, you're disingenuously characterizing past discussions w/ hyperboles
14:31 < BlueMatt> ^ +1
14:32 <@michaelfolkson> I sat out the meeting didn't I? :) Knew it was going to be a waste of time
14:32 <@michaelfolkson> Personal progress
14:34 -!- CriptoLuis9 [be9ba048@190.155.160.72] has quit [Ping timeout: 240 seconds]
14:36 < jeremyrubin> You know, if AJ had said "MTP or height are ok, but if we pick height then I will spend roughly 1 month of engineering time working on signet features that I wouldn't need to if we picked MTP, and otherwise I can spend that time working on other major contributions to bitcoin like AOP" that would be a good 'nuff reason for me :p
14:37 <@aj> APO?
14:37 < jeremyrubin> oops
14:37 < jeremyrubin> yep
14:37 < BlueMatt> he means AOP for Android Open Source Project
14:37 < BlueMatt> but missed the S
14:37 < BlueMatt> :shrug:
14:38 < jeremyrubin> actually i meant AOPS
14:38 < jeremyrubin> AJ solving all our problems
14:38 <@aj> that would require making an estimate on how long it'd take to do stuff...
14:38 < BlueMatt> :+1:
14:38 <@aj> and then moneyball would make a bet based on my estimate, and then where would be
14:38 < jeremyrubin> anyways notes are up https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018742.html
14:43 < harding> Meeting notes look like a good summary to me.
15:01 < Emcy> jeremyrubin you know im not a 'contributor' right
15:01 < Emcy> im nobody
15:02 < Emcy> my only provenance is that ive been hanging around a long time
15:03 < jeremyrubin> tbh I thought you and emzy are the same person
15:03 < roasbeef> lol same tbh
15:03 < jeremyrubin> don't know, don't care, just counting who showed up
15:03 < jeremyrubin> that's all that bitcoin core is, whoever shows up
15:03 < copumpkin> we need an emsy too, for maximum confusion
15:03  * harding also confused Emcy and emzy
15:04 < Emcy> my lawyer is writing up dox for emzy for trademark infringement
15:04 < jeremyrubin> and an MC for the activation party
15:05 < stortz> lol
15:08 < Emcy> https://youtu.be/h4jKTM2MwCo?t=139
15:38 -!- p0x [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
15:39 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 240 seconds]
15:42 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has joined ##taproot-activation
15:43 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has quit [Client Quit]
15:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
15:54 -!- stortz [bb3fbd57@unaffiliated/stortz] has quit [Quit: Connection closed]
16:02 < emzy> Emcy: I thought we settled that in 2013 or so. ;)
16:10  * roasbeef block waiting time intensifies 
16:11 < emzy> 2 blocks to go.
16:11 < jeremyrubin> did the miners really just protest and shut off
16:11 < jeremyrubin> damn
16:11 < jeremyrubin> :p
16:13 < belcher> wait so the coin flip is happening now?
16:13 < roasbeef> it's already underway...
16:13 < roasbeef> the biggest coin of them all
16:14 < jeremyrubin> belcher: you got about 20 minutes to precommit
16:14 < roasbeef> inb4 insta block after insta block
16:14 < roasbeef> watch it be an empty block, kek
16:15 < jeremyrubin> btw, I'm going to make coinflip cookies for bitcoin 2021; oatmeal raisin or snickerdoodle
16:15 < roasbeef> snickerdoodle
16:16 < jeremyrubin> bitcoin-cli getblockhash 123456 | cut -b64 | grep -q '[02468ace]' && echo "you get taproot" || echo "you get taproot"
16:16 < jeremyrubin> oops gotta update that block #
16:16 < roasbeef> blockHeight++
16:17 < belcher> its like waiting for the halvening :D
16:19 < jeremyrubin> it's flipped!
16:20 < emzy> Next block!
16:21 < jeremyrubin> nope it's this one your node doesn't have it yet?
16:22 < emzy> <jeremyrubin> 678059+20
16:22 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
16:22 < jeremyrubin> i'm just trolling
16:23 < emzy> HAHA. I have many nodes, so I can check more then one :)
16:25 < jeremyrubin> now for real
16:25 < jeremyrubin> 00000000000000000000a6bcbf09849fe895b5d18ed884e8d558a57fc4f5e95c
16:25 < jeremyrubin> ends in c
16:26 < jeremyrubin> Well, looks like MTP it is.
16:26 < luke-jr> no, it isn't still.
16:26 < roasbeef> btcctl getblockhash $((678059+20)) | cut -b64 | grep -q '[02468ace]' && echo MTP || echo height
16:26 < rgrant> MTP
16:27 < jeremyrubin> will take a few blocks to settle that there's no reorgs
16:28 < robert_spigler> I vote snickerdoodle jeremyrubin
16:30 -!- TechMiX [~techtux@188.126.217.46] has left ##taproot-activation []
16:33 <@michaelfolkson> I honestly can't tell the difference between a serious proposal and performance art anymore
16:33 < jeremyrubin> if you think that a coinflip to avoid bikeshedding is worse than a client which can cause a chainsplit then you should reexamine your priorities my friend
16:34 <@michaelfolkson> We could raise the stakes and put enabling CTV as a soft fork to a coin toss
16:34 < roasbeef> michaelfolkson: once again you're mischaracterizing
16:34 < jeremyrubin> fallacy of the excluded middle --> coinflips are neither always good or always bad
16:34 <@michaelfolkson> If it is bikeshedding Approach ACK both PRs and stop wasting everyone's time
16:34 < jeremyrubin> they have a place and a time
16:35 < luke-jr> jeremyrubin: FUD
16:35 < roasbeef> > 16:48 < copumpkin> IMO coinflip is more of an acknowledgment that the two CRs differ largely in shed color and that we all want the shed, and don't care as much about its color
16:35 < luke-jr> BIP8(True) does NOT cause a chainsplit any more than any other activation method
16:35 < luke-jr> claiming it does is dishonest
16:35 <@michaelfolkson> It either matters or it doesn't matter. If it doesn't matter don't call a meeting to discuss it. If it matters don't do a coin toss on it
16:35 < jeremyrubin> https://tools.ietf.org/html/rfc7282
16:35 < roasbeef> luke-jr: nothing stops you from releasing that w/ Knots and running it
16:36 < jeremyrubin> if ST with MTP is such a bad thing for bitcoin then just make sure you set your versionbits to 0 so it fails
16:36 < achow101> luke-jr: michaelfolkson: Can you articulate technical reasons why you are opposed to MTP? I get that heights were agreed upon previously, however things are not static. There have been changes proposed to the MTP implementation that would allow for a UASF.
16:36 < luke-jr> jeremyrubin: miners don't decide
16:37 < roasbeef> luke-jr: I think that's been discussed ad nauseam
16:37 < jeremyrubin> we've used a coin flip to break a stalemate so people feel comfortable spending review energy, and then the proposal isn't "decided" it's then put forth for clients to upgrade to, and even then it's not final, miners have to signal
16:37 < luke-jr> jeremyrubin: achow's PR is already 100% reviewed
16:37 < luke-jr> there is also zero reason to even cosnider MTP
16:37 < achow101> luke-jr: why?
16:38 <@michaelfolkson> https://bitcoin.stackexchange.com/questions/103854/should-block-height-or-mtp-or-a-mixture-of-both-be-used-in-a-soft-fork-activatio
16:40 < rgrant> luke-jr: NACKing because something else is already reviewed isn't logical.
16:40 < achow101> timewarp is a risk, but timewarp also fucks with a ton of other things, so is unlikely to be performed
16:44 < robert_spigler> achow101: how did the discussion go with aj on an attempted compromise?
16:44 < instagibbs> luke-jr, what does 100% reviewed even mean
16:45 < achow101> robert_spigler: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-814494847
16:45 < robert_spigler> achow101: thanks
16:46 < jeremyrubin> achow101: that seems fine to me, was a bit counterintuitive that a min_active_height has no impact on signets overall, so might be worthwhile to clarify that in the comment for folks
16:46 < jeremyrubin> E.g., they can always be set to 0 for signets so there's no delay period
16:46 < jeremyrubin> seems like a fine solution, great work
16:48 < robert_spigler> I like MTP w/ min_activation_height
16:49 < luke-jr> instagibbs: it should have already been merged a week or more ago
16:50 <@michaelfolkson> Ironic they did the coin toss using a specified block height rather than time. Says it all really
16:51 < rgrant> jeremyrubin: You said you had special reasons for block height based coinflip.  Shorter command line?
16:52 <@michaelfolkson> Best of 3, using time for the second one and then a coin toss on whether to use time or block height for the third coin toss
16:52 < instagibbs> MTP means time munging on jq I bet :P
16:52  * rgrant lol
16:53 < jeremyrubin> rpc getblockatheight
16:53 < jeremyrubin> could add rpc getfirstblockaftertime
16:53 < jeremyrubin> but it doesn't exist now
16:54 < jeremyrubin> in fact, if we're comparing to the discussion at hand, it's an argument for MTP since it's what already exists in bitcoin core :p
16:54 < roasbeef> RGNesus has spoken
16:55 < rgrant> Amen.  And we know what code to write for 2022/04/01.
16:55 <@aj> roasbeef: RNGesus?
16:55 < jeremyrubin> say it aloud
16:55 < roasbeef> aj: https://knowyourmeme.com/memes/rngesus
16:56 <@aj> different to RGNesus
16:56 < roasbeef> kek yeh
16:56 < roasbeef> random generated number
16:56 < roasbeef> keyboards are hard
17:04 < jeremyrubin> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018746.html
17:05 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]
17:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
17:16 < harding> Yay!
17:16 < robert_spigler> Great message, and I agree.  Thank you to everyone who have been working so hard!
17:17 < harding> aj: I know you hate making predictions, but do you think you'll be able to convert back to min_activation_height today?  If so, I'll put resuming testing on 21377 as my primary goal for tomorrow.
17:22 <@aj> harding: should be able to, doing the "DEFINED->FAILED transition is removed" part atm
17:22 <@aj> harding: the first three commits (tests, no functionality change) aren't changing
17:22 < harding> aj: awesome.
17:24 < robert_spigler> 🥳
17:29 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
17:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
17:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
17:55 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined ##taproot-activation
18:16 -!- shaunapps [shaunsun@gateway/vpn/privateinternetaccess/shaunsun] has quit [Ping timeout: 260 seconds]
19:02 -!- rgrant [~rgrant@unaffiliated/rgrant] has left ##taproot-activation []
19:06 -!- benthecarman [~benthecar@2600:1700:201:6e60:e785:240c:ef4b:cc0e] has quit [Ping timeout: 250 seconds]
19:10 -!- stortz [bb3fbd57@unaffiliated/stortz] has joined ##taproot-activation
19:35 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 240 seconds]
19:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
19:39 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
20:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]
20:22 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
20:24 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]
20:32 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
20:35 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
20:48 -!- stortz [bb3fbd57@unaffiliated/stortz] has quit [Quit: Connection closed]
20:50 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
21:07 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
21:07 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
21:51 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 260 seconds]
21:54 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
21:55 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
22:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
22:22 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
22:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
22:46 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
22:47 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 260 seconds]
23:25 < jeremyrubin> aj: code looks good to me in matching the changes requested by achow101
23:57 -!- p0x [~pox@gateway/tor-sasl/pox] has quit [Quit: p0x]
23:58 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
--- Log closed Wed Apr 07 00:00:19 2021