--- Log opened Sun Apr 25 00:00:36 2021
00:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
00:34 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection]
00:35 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
01:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:48 -!- Guest26781 [sid301948@gateway/web/irccloud.com/x-enkekiwnhjplxzfp] has quit []
01:48 -!- Guest26781 [sid301948@gateway/web/irccloud.com/x-tobmrpijmzrelnsy] has joined ##taproot-activation
01:49 -!- Guest26781 [sid301948@gateway/web/irccloud.com/x-tobmrpijmzrelnsy] has quit [Client Quit]
01:49 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-csbjmecfzclgtpfc] has joined ##taproot-activation
02:09 -!- matviy [45b56c08@c-69-181-108-8.hsd1.ca.comcast.net] has joined ##taproot-activation
02:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
02:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:19 <@michaelfolkson> Listening to AaronvanW and provoostenator on their Taproot activation update https://www.youtube.com/watch?v=SHmEXPvN6t4
04:20 <@michaelfolkson> provoostenator says "There is a problem with reusing the same bit number within a short period of time. Because it would be exactly the week after in the scenario we talked about it may not be possible to use the same bit."
04:20 <@michaelfolkson> What is the problem with reusing the same bit number?
04:22 <@michaelfolkson> This is the scenario in which Speedy Trial has failed to activate and Bitcoin Core chooses to either deploy another Speedy Trial or a BIP 8/9 signaling after Speedy Trial has failed. Why can't it use the same bit number as was used in the original Speedy Trial that it deployed (and failed) immediately afterwards?
04:48 < AaronvanW> michaelfolkson: yeah, while re-listening the podcast, I also noticed that I should have asked that, because I don't know the answer myself.
04:48 < AaronvanW> (and I would also like to know.)
04:51 -!- rdymac [uid31665@gateway/web/irccloud.com/x-srabrhsdhxpnpipi] has joined ##taproot-activation
04:55 <@aj> there's no issue if it's the same code; the only reason for it to matter is if there's ~12 soft forks to deploy simultaneously
05:00 <@michaelfolkson> Deploying a soft fork activation overlapping with another soft fork activation when activation mechanisms and activation parameters are disputed would be reckless beyond belief
05:00 <@michaelfolkson> But agreed it is theoretically possible
05:01 < AaronvanW> thanks aj
05:02 <@michaelfolkson> Indeed, thanks aj
05:17 -!- matviy [45b56c08@c-69-181-108-8.hsd1.ca.comcast.net] has quit [Quit: Connection closed]
05:27 <@michaelfolkson> Another provoostenator quote "I think the rule is at the end of the difficulty period you start counting and if the result is a failure then if it is after August 11th you give up but if it is not yet August 11th you enter the next round."
05:27 <@michaelfolkson> "I think it used to be the other way around where you first check the date but if it was past the date you would give up but if it was before the date you would still count. Now I think it is the other way round, it is a bit simpler."
05:28 <@michaelfolkson> I thought MTP had the same number of signaling periods as block height or less. There wasn't a scenario where MTP could have *more* signaling periods than block height
05:29 <@michaelfolkson> Was I wrong or do I just misunderstand the provoostenator quote?
05:29 <@michaelfolkson> Don'
05:30 <@michaelfolkson> Don't mean to keep picking on provoostenator btw :) The vast majority of stuff he has said is correct and he certainly explains it better than I could
05:36 <@aj> of course mtp can have more periods than height -- all you need is for more blocks to arrive prior to the timeout than was expected when you did the mtp <-> height conversion
05:40 <@michaelfolkson> The time warp attack can not only reduce the number of signaling periods of MTP (compared to block height) but it can also increase the number of signaling periods of MTP (compared to block height)?
05:41 <@aj> the time warp attack can only delay hitting starttime which would reduce signalling periods (it's already been hit, so this is not possible without a many-hundred block reorg), or delay hitting timeout which would give more signalling periods (still possible)
05:42 <@aj> the above wasn't assuming an attack, just hashrate variation
05:43 <@michaelfolkson> Gotcha, thanks
05:44 < AaronvanW> can't a timewarp attack also "skip over" the signaling period almost entirely? eg. if miners now start pretending it's august 12th?
05:49 <@michaelfolkson> That's my understanding. The attacker(s) would probably need to mine all 11 blocks that make up the MTP calculation
05:49 <@michaelfolkson> Or at least the majority
05:50 <@michaelfolkson> You'd need the median to be post August 12th I think...
06:12 < AaronvanW> btw bcman already mentioned it, but Pete Rizzo and I are indeed putting together a Clubhouse room to discuss soft fork activation, Speedy Trial, LOT=true/false, etc. This Tuesday, 17:00 UTC. If anyone reading this would like to join, DM me? (I'm not a big Clubhouse user myself, but there are a lot of people who prefer informing themselves through audio, Q&A type of sessions instead of reading IRC logs :))
06:16 <@michaelfolkson> AaronvanW: And ideally you are looking for someone to argue against the LOT=true release (its existence or what is contained in it) as bcman is obviously a proponent of it
06:17 <@michaelfolkson> AaronvanW: If you don't find anyone I'll do it. So surely that is a motivator for someone
06:20 < AaronvanW> my hunch is that Clubhouse is the type of domain where you'd find "UASF type of people" moreso than Core devs ;) And yes it would be ashame if that results in more of a one-sided discussion.
06:23 <@michaelfolkson> I think Matt and roasbeef have discussed Clubhouse before. And don't Lightning Labs do a Clubhouse session?
06:29 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation
06:32 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 252 seconds]
07:09 -!- liberliver [~Thunderbi@46.101.127.98] has joined ##taproot-activation
07:10 -!- liberliver [~Thunderbi@46.101.127.98] has quit [Client Quit]
07:55 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
07:56 -!- rdymac [uid31665@gateway/web/irccloud.com/x-srabrhsdhxpnpipi] has quit [Quit: Connection closed for inactivity]
07:59 -!- commmon [~common@unaffiliated/common] has quit [Ping timeout: 268 seconds]
08:06 -!- harding [quassel@newmail.dtrt.org] has joined ##taproot-activation
08:19 < harding> luke-jr: I noticed that you've merged multiple PRs in the BIPs repository, closed at least one, and are commenting on other BIPs that were opened after 1104 was opened and received ACKs from all its co-authors.  Could you please stop stalling and either merge 1104 or explain on the PR why you're not merging it.
08:23 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 252 seconds]
09:38 < queip> AaronvanW: what is a clubhouse room? is it like Mumble but needlessly closed source or centralized? and I thought idea to use Slack/discord/whatever was the worst. it's iOs only?
09:39 < AaronvanW> quiep: yes
09:39 < queip> I guess what ever fows one's boat, but don't except most of community there
09:39 < AaronvanW> I know.
09:43 < luke-jr> harding: how about you stop making false accusations and demands for special treatment, and I'll get to it in due time?
09:44 < luke-jr> all you're doing is convincing me you're engaging in bad faith
09:48 < harding> luke-jr: you are clearly stalling, which is negative special treatment and an abuse of your authority.  Please address your failing or resign as BIPs editor.
09:48 < luke-jr> harding: liar
09:49 < harding> luke-jr: which part, that you're stalling or that your stalling is an abuse of your authority?
09:50 < luke-jr> as I already told you, I am not stalling.
09:50 < harding> luke-jr: liar.
09:50 < luke-jr> I don't lie.
09:51 < harding> luke-jr: liar.
09:52  * queip is stalling
09:52  * luke-jr is ignoring harding now
09:52 < mol> LMAO
09:53 < queip> guys pls
09:53 < mol> harding, in my opinion the bip process should be aborted, but that's something to be discussed another day :D
09:54 < luke-jr> of course, since you seem to think certain Bitcoin Core devs should simply dictate Bitcoin's protocols
09:54 < harding> mol: past luke-jr seems to agree with you about that.  He was concerned that having an editor intermediary would stifle BIP editing.  It seems he's proving his own point!  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/003804.html
09:55 < queip> tbh over 8 years people's opinion can honestly change, sometimes to the better
09:56 < harding> queip: indeed, that's why I prefaced my remark with "past luke-jr".
09:57 < queip> harding: last point at which I "left" topic, was that in fact bloch height is superior, and in case of TR activation.. maybe not directly, but no reason to use it since it is generally worse (meta...)
09:58 < queip> and we have meta² that - if I get it correctly as non-developer just small user - luke rly doesn't like when somewhat inferior thing is moved forward for not good reason
09:58 < luke-jr> no, I think I still agree with that: it doesn't make sense to have to check every BIP change, and having it on a wiki avoided that
09:58 < luke-jr> I think someone recent suggested a bot as a middle ground, that might make sense
09:58 < queip> maybe it is good idea to return to height based thing.   in Core with LOT=false,  in BC-bTFC with LOT=true
09:59 < mol> harding, past luke-jr knew what could happen then, the man knows his own heart.lol jk
09:59 < harding> luke-jr: you said you were ignoring me, but now you seem to have read the link I provided.  Were you lying then?
09:59 < mol> harding, but really i think this process doesn't seem necessary?
10:01 < queip> harding: how about such return to height?
10:02 < queip> as I understand it is minimally, inferior in theory and not at all in this case, but it is kind of a statement that even minutea decissions aren't pushed without wider consensus... I guess?
10:05 < harding> queip: every solution I've seen involves tradeoffs and there is no clear way to weight the different tradeoffs, meaning any solution is going to involve subjective values.
10:05 < Emcy> New Luke sucks, the people demand Luke Classic back
10:06 < harding> queip: I don't think it would be appropriate to use height based signaling because the BIP editor is stalling on a merge.
10:07 < queip> harding: mu question was unrelated, just result of reading more about this debate few days ago
10:07 < harding> queip: ok.
10:09 -!- bcman is now known as faketoshi
10:09 < harding> queip: then I'll reinterate that I don't think there's any evidence that heights alone are superior in every way over MTP or over a combination of MTP and heights.  Each solution has different advantages and disadvantages; our objective should be to get as much advantage as possible with the fewest disadvantages.
10:10 < queip> harding: only disadv for BH was about signnet, while some mainnet concerns exist for MTP?
10:10 < harding> queip: BH has other problems, such as no guarantee on the minimum amount of upgrade time for nodes before enforcement begins.
10:11 < queip> harding: like gigantic rise in hashrate?
10:11 < harding> queip: the current compromise solution doesn't do a good job of guaranteeing that either IMO, but I think maybe we'll be able to do a better MTP solution in the futuer.
10:11 < harding> queip: yeah.
10:13 < harding> queip: I think if things hadn't become so heated and if it didn't look like people were going to start releasing their own software, we could've interated a bit more and developed a solution that would address nearly all concern.  The only advantage of heights that I think MTP can never fully address is that pure heights is probably the easiest to analyze.
10:15 < harding> (To be clear, IMO it's fine for people to release their own software; I'd just be concerned about them releasing it with the claim that the community process had become deadlocked.)
10:24 < harding> It might help to review other cases where luke-jr has fetishized technical elegance (like pure heights) over practical considerations (like signet compatibility).  E.g., his strong objections to P2SH that likely caused a consensus failure leading to loss of miner funds.  Greg Maxwell summized luke-jr's position as, "Unfortunately,  Luke has taken this position that I consider weird:  That P2SH is bad because it's a special case instead of
10:24 < harding> being a regular opcode that executes arbitrary code, and this special-caseness makes it inelegant."  https://bitcointalk.org/index.php?topic=58579.msg690093#msg690093  The consensus failure is mentioned in https://github.com/bitcoin/bitcoin/issues/925
10:27 < harding> Again, to be clear, there's nothing wrong with technical elegance, nor do I think there's any fundamental problem with pure heights---I agreed to the coinflip and, if we had used it and if it had chosen heights, I would've put the same amount of reviewer effort into that as I did the MTP-hybrid solution (which was more effort than I think I've ever given to a Bitcoin Core PR before).  I just think it's also ok to consider solutions with less
10:27 < harding>  elegance but other benefits.
10:36 < queip> luke-jr: it would be best btw if devels wouldn't ignore each other ;)
10:37 < queip> harding: btw ignoring sometimes means other things than pure /ignore
10:37 < queip> back to topic at hand - harding, doesn't Core's current solution also have the problem with timewrap to skip over activation period, since it does MTP first, then BH?
10:38 < queip> so in case of BH+BH versus MTP+BH
10:38 < luke-jr> queip: it would be best if devs didn't engage in bad faith and try to strongarm the community
10:39 < harding> queip: sure, but within the space of a few minutes he said he doesn't lie and that he was ignoring me, and then he replied to a link that only I posted.  Whether he meant technical /ignore or social ignore, he seemed to be lying about his intent.
10:39 < harding> (And thus he was also lying about not lying.)
10:39 < queip> luke-jr: what constitutes strongarming in this cases, should there be more discussion before any decission about TR activation in Core?
10:40 < harding> queip: nope, the current solution is resistant to timewarp skipping; it also doesn't provide any incentive to timewarp.
10:40 < queip> harding: dunno, sometimes I "ignore" people as in not helping them or such
10:41 < luke-jr> queip: there should be community involvement and general consensus among the community before, yes
10:41 < queip> luke-jr: is the current solution of MTP,BH in Core TR resistant to timewarp skipping? e.g. because: it doesn't provide any incentive to timewarp
10:41 < queip> harding: what about skipping just to mess up Bitcoin?
10:41 < harding> queip: it's resistant to timewarp skipping because it guarantees at least one signaling period.
10:41 < luke-jr> queip: technical /ignore makes it too easy for bad actors; I was responding to you above
10:42 < luke-jr> queip: nothing [in this context] provides an incentive to timewarp. it's not a real-world danger.
10:43 < luke-jr> queip: and if a timewarp occurred, nothing the activation method does matters, because the whole timewarped chain should be thrown out anyway
10:43 < harding> queip: skipping over all signaling periods is impossible in the current implementation, so if skipping is impossible then skipping just to mess up Bitcoin is impossible.  Obviously, timewarp attacks can do lots of damage unrelated to soft forks (and so we should fx them).
10:43 < queip> luke-jr: so in general Core should had discussed for a month or few, more, before releasing any code with TR ST?
10:43 < harding> queip: the merged TR ST PR was open for a month.
10:44 < luke-jr> queip: ST in general had support, but the last minute switch to BIP9 didn't
10:44 < harding> (Although its implementation did change a few times during that period.)
10:44 < luke-jr> queip: BIP8 ST would have been fine alongside a Core+Taproot release
10:46 < queip> the switch was in timing (BH->MTD,BH) or in LOT or both
10:46 < queip> nm, in both.
10:46 < queip> luke-jr: although.. this is only a trial
10:47 < luke-jr> queip: it's a consensus change without community support, and sustained objections
10:48 < luke-jr> queip: it's also one impractical for me to add to Knots in a reasonably safe manner
10:48 < luke-jr> queip: LOT doesn't apply to ST at all
10:48 < luke-jr> ST merely precedes a real activation method, or shaves off the early period of one
10:49 < queip> though all of this outcomes are "good" right?  this PR will activate consensus change on live chain if miners do signal right?
10:52 < queip> so TL;DR luke-jr is being extra pedantic about getting very strong support even to technical details (that how ever can result in a bit different consensus, e.g. when TR activates exactly if it does by ST) even of just a trial (because the trial can lead to consensus change) even though if the general outcome (TR activation) is good, because the timing and way of that activation had comparably little discussion/support?
10:53 -!- proofofkeags [~proofofke@97-118-239-55.hlrn.qwest.net] has joined ##taproot-activation
10:54 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
10:57 < luke-jr> queip: with both ST nodes and BIP8 nodes on the network, miners signalling during ST's period will cleanly activate, yes
10:57 < harding> queip: ST-MTP was heavily discussed (look at all this drama!) and, more importantly, heavily reviewed on https://github.com/bitcoin/bitcoin/pull/21377
10:57 < luke-jr> queip: however, ST nodes are vulnerable to miner attacks, and it is impractical for software to support both ST and BIP8 as options
10:59 < harding> I don't know what miner attacks ST nodes are vulnerable to that BIP8(True) isn't, unless luke-jr considers non-signaling to be an attack.
11:00 < queip> luke-jr:  what miner attacks ST nodes are vulnerable to that BIP8(True) isn't, unless luke-jr considers non-signaling to be an attack.
11:01 < luke-jr> queip: miner veto is indeed an attack, but ST's start/timeout can also be manipulated by miners by playing minor timestamp games (not necessarily a timewarp)
11:02 < luke-jr> though IMO it's probably too late to meaningfully do so for Taproot now since we're past start_time in MTP; and messing with the timeout is pointless
11:03 < luke-jr> (since BIP8 extends beyond the timeout regardless, and a miner messing with timestamps can probably just as well ensure 11% non-signal)
11:04 < harding> In short, there is no attack.
11:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
11:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
11:52 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-skoxfvjrvkkolcfy] has quit [Ping timeout: 245 seconds]
11:58 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-blxwwhnewjrneslj] has joined ##taproot-activation
12:10 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Remote host closed the connection]
12:11 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
12:33 < Emcy> luke-jr how well do you know me
12:37 < luke-jr> off-topic here, feel free to PM
13:36 <@michaelfolkson> For people who think the activation parameters merged into a BIP are utterly irrelevant (some even calling for an end to the BIP process) they don't half seem to care what is merged (and when) into this one
13:37 <@michaelfolkson> One of life's quandaries I guess. The BIP is totally irrelevant yet I am going to get really angry when what I want to be merged isn't merged as fast as I want it to be
13:40 < harding> michaelfolkson: I don't think anyone is angry about the overall speed of merging (although only once a month merges is slower than I think anyone would like); I think the anger is about the BIPs editor deliberately stalling on merging certain PRs, which indicates a broken process---the BIP editor is supposed to be a pure functionary, not someone with control over BIP content.
13:41 < luke-jr> but that's just a lie
13:42 <@michaelfolkson> harding luke-jr: Both of you I don't want to hear anymore accusations of lying and liars. Let's just assume we are all liars from now on
13:42 < harding> luke-jr: it's abundantly clear that you're stalling.
13:44 <@michaelfolkson> But you are asking him to merge in activation parameters that don't perfectly align with the parameters in an alternative release he is contributing to harding.
13:44 < luke-jr> I've made multiple efforts to speed things up fairly, yet the ST trolls keep obstructing them
13:44 <@michaelfolkson> I think I would be uncomfortable doing that. Especially given how much people seem to care about this particular merge
13:44 < harding> michaelfolkson: if I see someone clearly lying in this room, I will say so.  If you decided to /kick me for that, that will be your choice.
13:45 <@michaelfolkson> I'm not kicking you harding. Just respectfully asking you not to continuously call each other liars
13:46 <@michaelfolkson> I do think also the anti BIP 8 people will point to this merge and say "BIP 8 wasn't used for Taproot's Speedy Trial. BIP 8 should never be used."
13:46 < harding> michaelfolkson: it shouldn't matter if it makes you uncomfortable; the job of the BIPs editor to merge content that meets the BIPs guidelines is clear.  If you don't feel you could do that, then I would recommend you don't volunteer as BIPs editor.
13:47 <@michaelfolkson> It seems to me kallewoof will resolve this situation. Maybe not as fast as people would like
13:49 <@michaelfolkson> <@michaelfolkson> I do think also the anti BIP 8 people will point to this merge and say "BIP 8 wasn't used for Taproot's Speedy Trial. BIP 8 should never be used."
13:49 <@michaelfolkson> ^ That's why people care so much I think. They say the activation parameters in the BIP are irrelevant but they don't actually think they are irrelevant
13:49 <@michaelfolkson> You don't care this much about something that is irrelevant
13:50 < harding> michaelfolkson: kallewoof may resolve the situation regarding 1104; I don't think it will resolve the situation that a current BIPs editor has engaged in stalling that was only resolved through a large expenditure of contributor time that could've been put to productive uses.  I think the dissatisifaction from that will last a long time.
13:54 <@michaelfolkson> harding: Maybe. If there is a discussion afterwards on whether a soft fork BIP author should be able to "finalize" the activation BIP and activation parameters used then it won't be a complete waste of time
13:56 <@michaelfolkson> I think the model that sipa tried (until recently) of staying out the activation discussion completely should be the model going forward
13:57 <@michaelfolkson> AJ is a BIP co-author, he is the reason we have a MTP Speedy Trial, he is the reason we're not using BIP 8 and he is essentially finalizing the activation parameters
13:57 <@michaelfolkson> I don't think that should be the model going forward whatever people's frustrations with Luke
13:58 <@michaelfolkson> Of course Luke shouldn't be asked to merge activation parameters that are different to the parameters in his own release either. But that is solved by getting kallewoof as a second BIP editor
14:00 < harding> michaelfolkson: what are you talking about, BIP authors have the right to change their BIPs.  I haven't heard luke-jr or anyone dispute that.
14:02 <@michaelfolkson> harding: They do have that right, they currently can do anything. Including potentially adding activation details and activation parameters that don't have community consensus
14:02 <@michaelfolkson> harding: I'm not saying that is the case here btw
14:03 <@michaelfolkson> harding; But they could in future. That isn't great
14:03 < luke-jr> michaelfolkson: see BIP 10x
14:04 < luke-jr> (I haven't recently, but I expect they will be relevant to consult for precedent when I get to the PR in question)
14:05 < harding> michaelfolkson: it's necessary to get people to write documentation.  if the choice for a developer is between writing a document where some third party gets to veto your choices or not writing documentation (or publishing to your own site), I suspect almost all developers will choose not to write or to use their own site.  Giving authors control over their own documentation is necessary to ensure we can have a central collection of
14:05 < harding> documentation.  The BIPs editor exists to prevent BIP number collisions and to prevent spam.
14:07 <@michaelfolkson> harding: Ok fair, makes sense. But why include activation details in BIPs if they can be disputed? Why not just add later whether they were activated or not?
14:08 < harding> michaelfolkson: because activation details are necessary for coordination, and coordination is the point of the standardization process.
14:08 <@michaelfolkson> harding: AJ essentially here (in my view) is attempting to use his position as a soft fork BIP author to set precedent that BIP 8 shouldn't be used for future soft forks.
14:09 <@michaelfolkson> I don't know why a soft fork BIP author should be able to do that
14:10 <@michaelfolkson> Unless the only activation details we care about are what is in Core
14:10 <@michaelfolkson> In that case every soft fork BIP should just state what activation parameters, BIP were used in Core
14:10 < roasbeef> any future soft fork can use w/e method it wants, this is so ridiculous, you keep bending over backwards to attempt to post hoc rationalize the current situation
14:11 < harding> michaelfolkson: I don't know how you came to that conclusion and I don't know how you think he'd accomplish that.  Even if BIP341 explicitly said "BIP8 is bad", which nobody has proposed, it's still just a document.  There are lots and lots of terrible ideas documentet in the BIPs repository, they don't prevent us from doing something different.
14:11 < roasbeef> if luke's client wants to add a new BIP to describe how they wish to activate w/e soft fork they propose, they're free to do that
14:11 <@michaelfolkson> roasbeef: Precedent isn't forced for future soft forks but it isn't irrelevant. If Speedy Trial works brilliantly it will be considered for the next soft fork. That is without doubt.
14:12 < roasbeef> it may be considered sure, but there's no requirement that it be used again
14:12 <@michaelfolkson> Not forced but will be a strong candidate (if it works brilliantly)
14:12 < roasbeef> i don't understand why you're so attached to this at the hip, there're literially < 10 active nodes of that client, for practical purposes it's irrelevant in this context
14:13 < queip> roasbeef: who? which client?
14:13 < roasbeef> luke's new client
14:15 <@michaelfolkson> roasbeef: I'm not attached to anything at the hip. People seem to *really* care that this is merged. And I come to my computer and people are calling each other liars. I'm not rigidly fixed to anything. I see what I see
14:15 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
14:15 < roasbeef> ofc they care it's merged, all the authors have approved the chagnes to the BIP
14:16 < roasbeef> BIPs just describe how things can be done, they don't say that they _should_ be done
14:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 240 seconds]
14:16 < roasbeef> if you had a BIP you were tyring to update, and the updates weren't being merged in, you'd feel the same way
14:16 < luke-jr> michaelfolkson: if you don't like the change as-is, I suggest a followup PR adding BIP8 params. Maybe sipa will accept it - who knows.
14:16 < roasbeef> ^ srsly, make your own PR to update things, or just make a new BIP all together
14:16 < luke-jr> michaelfolkson: but if you do, please note I expect to take another month break after I'm caught up - so better to get it PR'd sooner
14:18 <@michaelfolkson> luke-jr: I don't want to pour oil onto the fire. If people think a followup PR adding BIP8 params is helpful I am happy to do it
14:18 <@michaelfolkson> luke-jr: I don't think AJ will want it merged though and I'm almost certain sipa won't want to get involved
14:18 < luke-jr> michaelfolkson: worst case they reject it *shrug*
14:21 <@michaelfolkson> luke-jr: Worst case it stays open, no one touches it and everyone thinks I'm troublemaking
14:24 < roasbeef> oh ppl already think you're troublemaking at this point, so no worries there
14:26 <@michaelfolkson> If AJ states here he'll happily ACK a separate PR to the BIP with the alternative client's parameters I'll open the PR
14:26 < Emcy> holy shit do you guys understand that the bips process is just a record of what has happened. like a court transcript.
14:26 < Emcy> the stenographer cannot just refuse to record something because he doesnt like it or whatever. this is absurd.
14:27 < luke-jr> Emcy: not even that
14:27 < Emcy> there is no power that lies in the bips process
14:27 < roasbeef> michaelfolkson: no need to wait, just do it, luke merges the BIP like he has several others last week, and we can all just move on w/ our lives
14:27 <@michaelfolkson> roasbeef: Luke can't merge it without an author ACKing it
14:27 < luke-jr> roasbeef: I can't merge it without sipa or AJ ACKing
14:28 < roasbeef> cmon
14:28 < roasbeef> https://github.com/bitcoin/bips/pull/1104#issuecomment-819082812
14:28 < roasbeef> oh by merge I meant the OG one
14:28 < roasbeef> ppl would review w/ folkson puts up as normal
14:29 <@michaelfolkson> [22:27:46]  <@michaelfolkson> roasbeef: Luke can't merge it without an author ACKing it
14:29 < luke-jr> michaelfolkson: roasbeef was talking about 1104
14:29 <@michaelfolkson> Yeah I was referring to a speculative PR that I would be opening here
14:29 <@michaelfolkson> luke-jr: Right
14:37 <@michaelfolkson> I think kallewoof will save the day. If people just stay calm and patient and stop calling each other liars we'll be fine
14:39 < luke-jr> Greg NACK'd Kalle, so that's a dead end :/
14:39 < luke-jr> besides, I'll be done long before then anyway
14:40 <@michaelfolkson> So what is Greg proposing? Getting rid of you and replacing him with Kalle?
14:40 < mol> luke-jr, i'd nack it too but i don't bother
14:41 <@michaelfolkson> What is wrong with Kalle becoming a second editor and merging it?
14:41 < luke-jr> michaelfolkson: Greg's proposal (from other contexts as well) appears to be "paint Luke like he's doing something wrong and remove him"
14:42 <@michaelfolkson> luke-jr: Do you want to stay on as BIP editor?
14:43 < luke-jr> I don't want to feed the attempted takeover of Bitcoin.
14:43 <@michaelfolkson> I don't know how I'm the troublemaker. I was happy with Kalle as a second editor
14:44 < luke-jr> I'm not saying you are
14:44 <@michaelfolkson> roasbeef did
14:44 <@michaelfolkson> [22:24:36]  <roasbeef> oh ppl already think you're troublemaking at this point, so no worries there
14:45 < roasbeef> yep, and I think many others woudl agree, for the past month or so, you've been crying over spilled milk and have attempted to impede forward progress since you're caught up in some theoretical zero sum game
14:46 < roasbeef> luke-jr: if you think there's some takeover going on, then I think the main thing you can do is garner adoption of your new client
14:46 < Emcy> michaelfolkson people have noticed. trust me on that.
14:46 <@michaelfolkson> roasbeef: What spilled milk have I been crying over?
14:47 <@michaelfolkson> I haven't been comfortable with everyone hounding Luke
14:47 <@michaelfolkson> I didn't like the bikeshedding over MTP and block height and avoidance of using BIP 8 for no reason
14:47 < roasbeef> I think you're well aware, tbh I think it's super sad that you've essentially burnt w/e social capital you may have built up over time for something so inconsequential
14:48 < roasbeef> as has been said before, luke is a big boy, he can speak for himself, and given the opportunity he's failed to substantiate his objections
14:48 <@michaelfolkson> I'm not well aware. I'd like you to point out what spilled milk I've been crying over
14:48 < queip> tldr ppl are getting angry at being too anal about details of protocol?
14:49 <@michaelfolkson> Especially having worked hard to get progress on Taproot activation only to see whatever "social capital" I had burnt
14:49 <@michaelfolkson> I'm all ears
14:49 < roasbeef> even in the face of that, rough consensus moves forward as it should
14:49 <@michaelfolkson> The spilt milk? Exactly please
14:49 < queip> maybe I'm in minority but Im ok with consensus changes being discussed a lot
14:58 <@michaelfolkson> Unless I'm told exactly what the spilt milk is I'm going to assume it is stating opinions people don't like and agreeing with Luke on some things. If that burns social capital I guess I'll have to burn social capital
14:58 <@michaelfolkson> I'm not particularly interested in social capital if it means you can't state opinions and can't agree with Luke on some things
14:59 < roasbeef> aaand BIP merged, thx luke-jr
14:59 -!- matviy [45b56c08@c-69-181-108-8.hsd1.ca.comcast.net] has joined ##taproot-activation
15:00 < roasbeef> michaelfolkson: feel free to open your PR now either making a new standalone BIP or updating the existing one with w/e additional activation params you wish to add/modify
15:01 <@michaelfolkson> roasbeef: I'm worried that will lose me even more social capital than I've already lost
15:01 < roasbeef> up to you m8
15:04 -!- commmon [~common@unaffiliated/common] has joined ##taproot-activation
15:05 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 260 seconds]
15:08 -!- common [~common@unaffiliated/common] has quit [Ping timeout: 252 seconds]
15:10 < queip> roasbeef: can you clarify what michaelfolkson is doing wrong, re that capital thing
15:11 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
15:13 -!- commmon [~common@unaffiliated/common] has quit [Ping timeout: 245 seconds]
15:25 < rocket_fuel_> yes, I'd like to hear that as well.
15:58 -!- CryptoSiD [SiD@CryptoSiD.DonSiD.net] has quit [Quit: .]
15:59 -!- CryptoSiD [SiD@CryptoSiD.DonSiD.net] has joined ##taproot-activation
16:01 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
16:01 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
16:16 <@michaelfolkson> I don't think we're going to get an answer from roasbeef. Perhaps Emcy you could let me know what "people have noticed"
16:16 <@michaelfolkson> [22:46:31]  <Emcy> michaelfolkson people have noticed. trust me on that.
16:18 <@michaelfolkson> I'm looking for more details on troublemaking, crying over spilt milk, burning social capital and doing some things that "people have noticed"
16:18 <@michaelfolkson> All sounds very ominous and I have no idea what any of it is referring to
16:19 < harding> http://gnusha.org/taproot-activation/2021-04-09.log
16:20 <@michaelfolkson> harding: Anything specific or am I to trawl through looking for evidence of troublemaking?
16:21 <@aj> AaronvanW: "timewarp attack also "skip over"" -- yes, but only by delaying starttime then not delaying timeout compared to real time. bip 341 starttime has already passed, so it's too late to delay it.
16:21 < harding> michaelfolkson: there is an extended discussion on that day between you, roasbeef, and I (and others) about your confusing behavior and lack of apparent progress towards a positive goal.
16:22 <@michaelfolkson> 13:07 < harding> michaelfolkson: it sounds like your goal is something different than "#21377 being well reviewed and merged", maybe a goal that involves impressing people?  Would you like to try again to state your goal?
16:23 <@michaelfolkson> harding: Who do you think I was trying to impress?
16:24 < harding> 13:05 <@michaelfolkson> There are a number of people who aren't impressed, not just me
16:24 < AaronvanW> aj: if miners *now* start pretending it's august 12th, wouldn't that mean there's only one signaling period? (instead of six, or so.)
16:25 < harding> harding: I was trying to help you state your goal.  You stated one, and then immediately wrote things that conflicted with it.
16:25 <@aj> AaronvanW: that would violate the "nTime can only be ~3h > than current real time" and their blocks would be rejected
16:25  * harding is going to quite for now about michaelfolkson so aj and AaronvanW can talk about on-topic stuff
16:26 < harding> quiet
16:26 <@aj> harding: it's okay, i can ignore you :)
16:26 < harding> aj: as well you probably should!
16:26 < AaronvanW> yeah and that answered my question anyways, thanks aj
16:27 <@aj> AaronvanW: (3h = nTime can only be 2h greater than adjusted time + adjusted time can only be ~70 minutes (iirc) greater than local clock time)
16:27 < rocket_fuel_> I am very impressed how a fairly low impact opt-in change can generate this much drama.
16:28 < rocket_fuel_> I thought all of this would be fairly non-contentious. Strange.
16:28 < AaronvanW> aj: just to make sure I'm not confused about this, if I would change my computer's clock, my bitcoin core node could start rejecting otherwise invalid blocks?
16:28 < AaronvanW> *otherwise valid
16:29 <@aj> AaronvanW: if you backdate it <70 minutes (eg, get daylight savings configured wrong), the adjusted time stuff should sync your time with your peers' time, and you'll stay in sync
16:30 <@aj> AaronvanW: if you backdate it by more than 70 minutes, blocks should still generally be within the 2h limit; if you backdate it by more than 2h, i think you'll start rejecting tip; not sure if that will self-correct occassionally
16:31 < AaronvanW> right; thanks
16:31 < Emcy> rocket_fuel_ it really should have been non contentious, but bitcoin has a slight autoimmune disorder
16:31 < rocket_fuel_> slight?
16:32 < harding> rocket_fuel_: the drama isn't about the change itself, but about how we activate it.  It kind of makes sense, changing the consensus rules is like amending a constitution---you want to make sure you do that right.
16:32 < Emcy> bcash was the big one
16:32 < queip> ---> https://s3.amazonaws.com/theoatmeal-img/comics/design_changes/12.png
16:32 < luke-jr> harding: therefore after we've already decided to do it right, a few devs step in and throw it all out for doing it wrong /s
16:33 < rocket_fuel_> @harding
16:33 < harding> luke-jr: I don't know who "we" is in your sentence.
16:33 < rocket_fuel_> oops.
16:34 < rocket_fuel_> @harding, I get it. I've been following this from day one and run the parallel group on Telegram. I think we are suffering from typical "perfect enemy of the good", unfortunately
16:35 <@michaelfolkson> I very much doubt people would throw the same BS they're throwing at me to Rusty but Rusty has influenced my thinking quite a bit
16:35 <@michaelfolkson> https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3667311
16:36 < harding> rocket_fuel_: yeah.
16:36 < belcher> by my reading its not about perfectionism or bikeshedding, but about using taproot as a sports ball to further people's own agenda of what they think bitcoin should be
16:36 <@michaelfolkson> You really should resolve things during "peacetime" in case the next soft fork is messier
16:36 < belcher> some people have (wrongly IMO) taken the lesson from 2017 that you can force rule changes onto bitcoin even if you dont have consensus
16:37 <@michaelfolkson> A template where we just assume there will be a UASF (whether it be released by Luke or a cowboy) is grounded in reality in my view
16:37 < belcher> right now the divide is between people who want to talk with everyone and find as much agreement as possible vs those who want to push their own rule changes regardless of how many people disagree with them
16:38 <@michaelfolkson> People are very squeamish about alternative clients to Core and BIP 8 (stupidly in my view)
16:38 < belcher> its wrong to say its only bikeshedding or "perfect enemy of the good", its a real genuine controversy... although by my reading the consensus-rule-forcers are very few, as someone earlier said there's maybe less than 10 nodes which run luke's client out there
16:38 < luke-jr> belcher: why are you inverting it?
16:38 < luke-jr> also, it isn't my client
16:38 < luke-jr> ST are the "consensus-rule-forcers"
16:39 < belcher> well i refuse to call it "bitcoin core", so what other name do you want
16:39 < luke-jr> belcher: quite a few seem to like "based"
16:40 < luke-jr> but the real issue is you're presenting it backward
16:41 < belcher> even before ST was invented you and a few others were pushing for alt-clients, thats what i mean by pushing for unilateral action regardless of the consensus out there
16:41 < AaronvanW> belcher: why do you call them "forcers"? (who's forcing who?)
16:41 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
16:42 < belcher> AaronvanW so for example bip148 had forced signalling (which at the time i agreed with because to me it seemed like bitcoin would die without it because of asicboost and other things)
16:42 < luke-jr> belcher: there is consensus on Taproot
16:42 < queip> belcher: I think we have consensus now... no? we have on TR itself right?
16:42 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
16:42 < belcher> (also bip148 was actually adopted by actual exchanges and merchants and users)
16:42 < luke-jr> forced signalling means any disagreeing users have a choice
16:42 < belcher> queip taproot and a soft fork activation method are different things
16:42 < AaronvanW> belcher: what's your definition of "force"?
16:44 < harding> belcher: following convention, I call the scammily-named client "Tapcash".
16:44 < belcher> AaronvanW https://imgur.com/a/uOq2k
16:44 < belcher> harding xD
16:44 < queip> maximum trolling xd
16:45 < luke-jr> harding: the scammily-named one is Bitcoin ST, passing itself off as "Bitcoin Core"
16:45 < queip> harding: do you mean the one discussed here?  if yes, then well we decided to call it bitcoin core *-based* taproot [forcing] client which imo is truthful, is it not?
16:45 < belcher> AaronvanW a better phrase is possibly "unilateral action" (i.e. trying to change the rules without consensus) rather than "force", and the meme i just linked from 2017 should show how it risks damage to bitcoin... its the same argument against Bitcoin Classic
16:46 < luke-jr> belcher: but that's what ST is doing, not Core+Taproot
16:46 < robert_spigler> In 2017 devs lost time and energy fighting miners and businesses trying to fork the protocol.  I have a strange feeling that this time around, devs will have lost time just fighting themselves, where an outside attack never happened.
16:47 < AaronvanW> belcher: yeah I don't think that dynamic works anymore in a context with futures markets. I take it you disagree, since we already discussed this.
16:47 < luke-jr> there is consensus for Taproot; there is consensus for BIP8; there is no consensus for BIP9 or giving miners a veto
16:47 < AaronvanW> (But I'm not sure why.)
16:47 < queip> robert_spigler: maybe better that then become ok with creeping "whatever someone 1 guy will decide"
16:47 < queip> *that, instead of becoming
16:48 < rocket_fuel_> One guy?
16:48 < belcher> you're right we did already talk, i think(?) the disagreement came down to me saying futures markets dont remove all the risk, while you said they remove the risk
16:48 < robert_spigler> queip: I believe we have full consensus except for two devs, and ~5 community members
16:48 < belcher> also those two devs cant provide reasons
16:48 < belcher> they just NACK and then fall silent when asked why
16:48 < robert_spigler> None of which can provide reasons
16:48 < belcher> at least by my reading
16:48 < robert_spigler> belcher: exactly
16:49 < luke-jr> robert_spigler: there's literally more Core+Taproot nodes than that, and I haven't even upgraded mine yet
16:49 < belcher> i suppose they already explaining "we dont want to give miners a veto" but that was already debunked and convinces nobody
16:49 < queip> I think most of the disagreement now comes from the fact that the change from BH into MTP,BH was done basically by 1 guy, aj - by that I mean that it was his one NACK on the BH, while ~10 devels were present, that seemed to made decissions to switch BH -> MTH,BH - if Im reading all this comments correctly
16:49 < queip> rocket_fuel_: ^
16:49 < AaronvanW> belcher: what risk did Bitcoin Classic represent in your view?
16:49 < belcher> queip hardly done by one guy when basically every core dev agreed in the end, if you look aj's PR had dozens and dozens of reviews
16:50 < queip> robert_spigler: on the taproot itself, sure.  As for BH vs MTP,BH, I think it looks like if that was kind of "pushed" by aj (sorry) without proper discussion - which leads to the meta problem
16:51 < queip> I know this is very anal, but tbh obsessing about heaving proper talk about every detail is not without merit (even if in this one case it didn't mattered much)
16:51 < luke-jr> robert_spigler: many reasons have been provided
16:52 < belcher> AaronvanW Classic would have made all the SPV wallets follow it, so they would be using classic coins rather than bitcoins
16:52 < queip> belcher: I refer to the one where there was just one 1 NACK, from aj. do you have the link at hand maybe?
16:52 < belcher> queip that sounds like achow's PR, and even though at the start it was one NACK when aj explained his reasons he managed to convince basically all the other devs
16:52 < AaronvanW> belcher: that's assuming they would have had majority hash power, of course.
16:52 -!- harding [quassel@newmail.dtrt.org] has left ##taproot-activation ["extrapolating from current growth rates, the logs from this channel are anticipated to consume the world's available storage capacity by 2035"]
16:52  * queip posts the log to BSV
16:53 < robert_spigler> luke-jr: I respect you so much (you have taught me so much in this space, and you are the developer I have donated the longest to (and will continue to do so)). I also am glad Bitcoin has a developer that will never be influenced by social pressure. But I strongly disagree with you on this.
16:53 < AaronvanW> belcher: while if UASF has majority hash rate there is no split. So doesn't seem like the same risk to me at all?
16:53 < luke-jr> robert_spigler: disagree that reasons have been provided? or that you just don't like the reasons?
16:53 < robert_spigler> queip: There were pros and cons for both BH and MTP, in the end, aj and achow101 got together and agreed on a mixture, where all devs then ACKED
16:54 < queip> robert_spigler: can you link me the one with lots of ACKs from devs?
16:54 < luke-jr> robert_spigler: no, I did not ACK. I NACK'd
16:54 < luke-jr> achow cannot agree for the entire community
16:54 <@michaelfolkson> robert_spigler: It is a nice story to tell but people don't open competing PRs if they are happy with the original PR
16:55 < belcher> achow didnt agree for everyone, rather everyone agreed they would review the PR which achow and aj agreed to
16:55 <@michaelfolkson> robert_spigler: A number of us had a preference for consistent block height but only Luke and maaku felt strongly enough to NACK it
16:56 < robert_spigler> luke-jr: IMO the reasons have been very circular (the community has chosen BIP8, the evidence is that it is obvious, if you can't see it it is because you aren't looking, etc)
16:56 <@michaelfolkson> I Approach NACKed AJ's PR at one point because I wanted review to be focused on one PR and so did Andrew
16:56 < robert_spigler> queip: They both had lots of ACKS, the one that was chosen finally was aj's.  Give me a second and I will link
16:56 < belcher> by that same reasoning you could NACK achow's PR too? so that all review would be focused on AJ's
16:57 < luke-jr> michaelfolkson: didn't you have a link somewhere where you summarised all the arguments for heights?
16:57 < luke-jr> robert_spigler: chosen by a handful of devs, not the community
16:57 < queip> so some people (maybe small amount) fell BH idea was not give enough review. .... then can we just re-review it.  ignoring "drama" and is it merged or not, just clean review?
16:57 <@michaelfolkson> luke-jr: Indeed, here we go https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277
16:57 < robert_spigler> queip: this is aj's PR https://github.com/bitcoin/bitcoin/pull/21377
16:58 <@michaelfolkson> And the above link is why I Approach NACKed AJ's PR rather than Andrew's belcher
16:58 < luke-jr> robert_spigler: ^
16:59 < robert_spigler> here is where achow offers his suggestiosn: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-814494847
16:59 < robert_spigler> here is where aj implements changes: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-814768715
16:59 < mol> queip, what's "BH"?
17:00 < mol> i keep thinking you mean "BCH"
17:00 < belcher> michaelfolkson by my reading the reason you NACK is that you list all those names which prefer something else... but a few days later basically all those names you mention decided to go for MTP
17:00 < belcher> so if almost all those names changed their mind why dont you?
17:00 <@michaelfolkson> belcher: Nope they ACKed the PR despite their slight preference for block height. Presumably they were as frustrated as I was
17:00 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has quit [Quit: ZNC 1.8.1 - https://znc.in]
17:01 < luke-jr> belcher: because there was not a rationale for changing their mind
17:01 < robert_spigler> At prior points, Achow and Michael NACKd, but then rescinded their NACK.  Everyone in the end ACKd
17:01 < luke-jr> TIL I'm noone
17:01 < robert_spigler> queip: ^^
17:01 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
17:02 < robert_spigler> luke-jr: . Sorry.  Everyone but luke
17:02 <@michaelfolkson> And maaku (not on the PR)
17:02 < robert_spigler> true
17:02 <@michaelfolkson> So essentially it had 4 NACKs at one point
17:03 < luke-jr> robert_spigler: but those ACKs are reviews, not reason to merge alone
17:03 <@michaelfolkson> And Andrew's PR only ever got 1 NACK (from AJ)
17:03 < robert_spigler> michaelfolkson:  Doesn't matter.  It only had 1 or 2 NACKs at merge time (and how many ACKs? Probably ~10)
17:03 < luke-jr> the process for Bitcoin Core merging a consensus change up until 2021 was that it needed community support
17:04 < luke-jr> this didn't have that
17:04 < queip> mol: BH is my shortcut for Block-Height [based activation]
17:04 < luke-jr> it was rushed out anyway because they wanted to sabotage Core+Taproot usage
17:04 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
17:04 <@michaelfolkson> robert_spigler: Agreed. I am not disagreeing with it being merged when it did. I am disagreeing with your and belcher telling of the story that everyone suddenly realized the error of their ways re block height vs MTP
17:05 < robert_spigler> luke-jr: I'm all for UASF's when they are necessary, safe (as possible), and realistic.  This current one is anything but
17:06 < luke-jr> robert_spigler: what? it is the safest option on the table
17:06 < luke-jr> and completely realistic
17:06 < queip> robert_spigler: yea, I think this is basically "why aj+someone got together, decided they think X is best, and then ignored NACKs from long standing devs like luke-jr"
17:06 < luke-jr> we can't know if necessary until at least a month from now; and that's no reason to introduce a known vulnerability
17:06 < queip> maybe if leading dev nacks we should discuss a bit more with community.  maybe that was done but so far I don't see it in these logs
17:07 < mol> luke-jr, it's like you want to build up the troops at the canadian border in case Trudeau decides to invade US? but il n'y a pas de guerre, luke
17:07 <@michaelfolkson> Luke does need to do better at explaining his NACKs with explanations
17:07 < luke-jr> mol: except it isn't at all like that
17:07 < mol> luke-jr, come on :LOL:
17:07 < luke-jr> mol: there is literally no comparison
17:08 <@michaelfolkson> I think often I've been explaining Luke's thought process and now my social capital has shrunk to the same as Luke's
17:09 < robert_spigler> luke-jr I agree, and still favor BIP8 LOT=true as the default.  But if you are attempting an alternative client, there needs to be outreach, broad support for the UASF, and an existing LOT=false default (like there was in 2017) , otherwise the alt-client will just fork off
17:09 < queip> ok look like
17:09 < robert_spigler> What is happening right now is just dangerous
17:09 < queip> we here HAVE consensus that
17:09 < queip> BH as well as MTP,BH are both okey for this TR ST right?
17:10 < queip> on this we can now here agree? that both are tolerable? putting aside perhaps too speedy push of that PR?
17:10 < robert_spigler> We haven't met any of the pre-reqs for a safe UASF
17:10 < mol> luke i still agree with the past luke-jr that bip process is burdening and i think it should be abolished
17:11 -!- belcher_ is now known as belcher
17:11 < robert_spigler> queip: yes, they were both ok.  Both had pros cons. That's why it really didn't matter
17:11 < queip> robert_spigler: I think the objection here is, that maybe decision was correct, but it was rushed without discussion
17:11 < rocket_fuel_> @mol really? and what should it be replaced with then?
17:11 < luke-jr> robert_spigler: there was outreach and broad support; there does not need to be a LOT=False
17:12 < queip> so how to fix it, what is actionable? reopen a PR as if the choise wasn't yet made and discuss BH vs MTP,BH properly?
17:12 < luke-jr> robert_spigler: and the timeline is set far out to ensure there is plenty of time
17:13 < luke-jr> robert_spigler: eg (one of many) https://twitter.com/brian_trollz/status/1380973341591363588
17:22 < mol> rocket_fuel_, what?
17:23 < mol> rocket_fuel_, oh that... none? why can't bip authors store their bips in their museum?
17:25 < mol> rocket_fuel_, harding showed me this link earlier:  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-December/003804.html
17:27 < robert_spigler> queip: There were multiple IRC meetings, ML posts, etc.  I think in the end, people were just going to be unhappy
17:28 < queip> luke-jr: since we (afaik) agree BH,MTP is not a problem in itself (for this fork), then how would you like to see this process done to be happy that it is along with community consensus?
17:31 < luke-jr> queip: what? MTP is a problem
17:33 < queip> luke-jr: I thought you said the other day that in this TR activation, MTP can not be used to actually attack and is not a danger?
17:34 < luke-jr> as for what should happen - community should be aware of it and objections not be ignored
17:34 < luke-jr> queip: miner veto is still an attack for ST in general; and just because there isn't an attack doesn't mean there isn't a problem
17:35 < luke-jr> queip: I still have no path forward for Knots, because ST is fundamentally incompatible with the main activation
17:35 < luke-jr> queip: I could simulate ST with BIP8, but harding says that's not close enough to call compatible with MTP ST
17:35 < queip> but minero veto is not issue in choosing time of activation right?
17:35 < mol> luke-jr, antpool and viabtc hold quite a bit of hash rate do you think they might not activate TR even though they said they would?
17:35 < luke-jr> queip: yes it is
17:36 < luke-jr> queip: if miners don't go along with ST, Taproot won't activate at all
17:36 < luke-jr> (from the perspective of ST)
17:37 < queip> luke-jr: is {ST done with MTP,BH as in Core} less secure than {same ST but with BH (still LOT=false)}?
17:38 < luke-jr> not significantly in this case IMO
17:38 < queip> allright
17:38 < luke-jr> but it remains a problem for other reasons mentioned
17:39 < queip> there are other problems in this choice of time?
17:39 < luke-jr> ?
17:39 < luke-jr> brb
17:42 -!- gevs [~evias@194.red-81-33-44.dynamicip.rima-tde.net] has quit [Ping timeout: 252 seconds]
17:46 <@aj> robert_spigler: "there needs to be .. an existing LOT=false default" -- luke promised to NACK lot=false PRs early last month, search for NACK in http://gnusha.org/uasf/2021-03-02.log
17:49 < robert_spigler> To be fair, there only needs to be an existing LOT=false default if the LOT=true is the alt-client.  I think luke preferred LOT=true to be the default. (At least, that is what I was arguing for at the time).  The point I'm making, is right now, LOT=true is the alt-client, and there is no LOT=false default, which is dangerous
17:51 < mol> but luke said LOT=false is dangerous and shouldnt be used: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
17:52 < robert_spigler> I am now a bit partial to the arguments that LOT=true would give ammo to the people saying that devs 'control' bitcoin, and now have no idea what the ideal activation process is.
17:52 < mol> there's no "ideal" activation
18:01 -!- gevs [~evias@67.red-88-6-131.staticip.rima-tde.net] has joined ##taproot-activation
18:07 < luke-jr> robert_spigler: after all this, it seems clear that ideal is that Bitcoin Core works on code, and the community does BIP8(LOT=True) separately
18:07 < luke-jr> no activation in Core
18:08 <@aj> "after all this" is an interesting way of saying "i still believe the same thing i did 9 months ago"
18:09 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
18:14 -!- duringo [ad004d09@cam4-7.as22384.net] has quit [Quit: Connection closed]
18:18 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
18:19 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation
18:21 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
18:23 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
18:27 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
18:30 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
18:39 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
18:54 -!- proofofkeags [~proofofke@97-118-239-55.hlrn.qwest.net] has quit [Ping timeout: 260 seconds]
18:55 -!- stortz [c8b9c69a@unaffiliated/stortz] has joined ##taproot-activation
18:56 < stortz> so ST started yesterday, right?
18:56 < stortz> any way to track it's progress?
18:57 < stortz> is there any way to track it's progress?*
18:57 < Emcy> good question
19:01 < luke-jr> stortz: no, it didn't.
19:01 < stortz> start time was set for 24th
19:01 < stortz> that was tomorrow
19:01 < stortz> sorry I mean
19:01 < stortz> that was yesterday
19:01 < luke-jr> not until block 681408
19:02 < luke-jr> but it doesn't start until the first adjustment after that
19:03 < luke-jr> at current pace, that won't be until Apr 30 or May 1
19:05 < stortz> this is why a mix of MTP and blockheight is so weird
19:05 < luke-jr> XD
19:06 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
19:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
19:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
19:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
19:44 -!- faketoshi [~quassel@static-198-54-131-76.cust.tzulo.com] has quit [Ping timeout: 252 seconds]
19:48 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
19:48 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
19:54 < jeremyrubin> robert_spigler: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018833.html
19:54 < jeremyrubin> I had a go at trying to figure out what the "ideal process" might look like based on versionbits (which in general I don't like)
19:55 < jeremyrubin> make sure you load the image as it won't make sense otherwise
19:57 < jeremyrubin> I think the main point of contention I've had in trying to reconcile this with the current UASF people is the notion that preparing a UASF requires a commitment to either a PoW Change or some other hardfork to make the threat credible
19:59 < jeremyrubin> (bear in mind BIP148 community had this on the table https://bitcoinmagazine.com/technical/countdown-segwit-these-are-dates-keep-eye)
19:59 < stortz> you don't like versionbits, what would be your alternative to it
20:00 < jeremyrubin> stortz: that's a story for another time
20:00 < stortz> meanwhile we stick with what we got then
20:00 < jeremyrubin> you can watch https://www.youtube.com/watch?v=J1CP7qbnpqA where I break down what I think the core issues are and describe a possible solution
20:00 < luke-jr> PoW change can't be automated. Everything up until that can and should be.
20:00 < jeremyrubin> Well you can have the code tested in advance
20:01 < jeremyrubin> and you could implement a gradual pow change as desc in my post
20:01 < luke-jr> "gradual" is a fundamentally broken idea
20:02 < jeremyrubin> ok then don't do it
20:02 < luke-jr> maybe someoen should rebase https://github.com/BitcoinHardfork/bitcoin sometime
20:02 < jeremyrubin> But I'm glad you at least recognize it's a part of the story
20:03 < jeremyrubin> maybe you should update your website to clarify under which conditions it would be required, and what you would propose it be switched to
20:03 < luke-jr> only in some extremity that is unlikely to happen
20:03 < jeremyrubin> making such decisions during an emergency leads to suboptimal outcomes
20:03 < jeremyrubin> Sometimes not having a plan makes them more likely to happen
20:03 < luke-jr> making a decision in advance leads to it becoming suboptimal
20:04 < luke-jr> eg, someone secretly prepares an ASIC for the new algo, then intentionally triggers it
20:05 < jeremyrubin> that's easily solvable IMO
20:05 < jeremyrubin> Make the design randomly selected from the tip hash when the fork happens
20:06 < jeremyrubin> gtg
20:07 < jeremyrubin> (could do tip hash, tip - 100, etc, just so that you can get consensus and prevent a wide class of a priori asics)
20:22 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
20:22 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
20:25 -!- stortz [c8b9c69a@unaffiliated/stortz] has quit [Quit: Connection closed]
20:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
20:53 -!- bcman [~quassel@192.252.212.44] has joined ##taproot-activation
20:57 -!- bcman is now known as faketoshi
20:57 -!- faketoshi [~quassel@192.252.212.44] has quit [Client Quit]
20:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
21:19 -!- bcman [~quassel@192.252.212.44] has joined ##taproot-activation
21:19 -!- bcman is now known as faketoshi
22:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
23:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
23:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
--- Log closed Mon Apr 26 00:00:37 2021