--- Log opened Tue Feb 16 00:00:31 2021
00:01 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation
00:36 <@michaelfolkson> This seems like a reasonable option pox. We can't guarantee that Core (or any other implementation) will release (true,1y) exactly 3 months later though
00:38 <@michaelfolkson> We can make a recommendation that they do. But it may be that an independent party has to release that (true,1y) version like with UASF-BIP 148
01:23 -!- rdymac [uid31665@gateway/web/irccloud.com/x-wdrcfkkgnifmvmby] has joined ##taproot-activation
01:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:49 <@michaelfolkson> That applies also if we decide LOT should be set to true from the start. We can only recommend Core does it in a mailing list proposal. That doesn't guarantee Core (or other implementations) release a version with LOT set to true
01:55 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-poobjgzopnrlujqs] has quit [Quit: Connection closed for inactivity]
02:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
02:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:10 < devrandom> I want to offer the perspective that LOT=true is very similar to a decreasing activation threshold, where the threshold decreases to 0% on timeout
03:12 < devrandom> my main worry is that a small minority of miners might use their leverage during signalling for political advantage
03:13 < devrandom> that is why I lean towards LOT=true.  but I would be much more comfortable with LOT=false if the activation threshold was lower (e.g. 85%)
03:20 <@michaelfolkson> I'd prefer 90 percent than 95 percent on LOT=false. I don't think we'll be able to get consensus on going lower than that though from the developer survey
03:20 < devrandom> even 90% is much better than 95%
03:21 <@michaelfolkson> Right
03:21 < devrandom> just curious, what is your reasoning for the 90% minimum?  a technical issue?
03:23 <@michaelfolkson> Mainly expressed preferences by developers in AJ's developer survey http://www.erisian.com.au/wordpress/2020/10/26/activating-soft-forks-in-bitcoin
03:23 <@michaelfolkson> Search for "What do you consider a reasonable threshold for activation by hashpower supermajority?" in that link
03:25 <@michaelfolkson> Generally the higher the percentage, the more conservative it is (at least from the perspective of wanting as many miners to signal readiness as possible)
03:25 <@michaelfolkson> If you're more concerned with the political shenanigans angle, you could argue a lower percentage is more conservative
03:26 -!- Alexandre_Chery [9466baa1@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.161] has joined ##taproot-activation
03:26 < devrandom> but what is the actual downside if less miners are ready at activation?  the survey doesn't get into that
03:28 -!- Alexandre_Chery [9466baa1@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.161] has quit [Client Quit]
03:30 <@michaelfolkson> You want as many miners enforcing the Taproot rules at the point that it activates as possible (ideally)
03:30 <@michaelfolkson> Otherwise an invalid Taproot spend could creep into a block and miners wouldn't reject it. Just treat it as an anyone-can-spend
03:31 <@michaelfolkson> It would need a (small) re-org to get that invalid Taproot spend out of the blockchain
03:31 <@michaelfolkson> A small naturally occurring re-org
03:31 <@michaelfolkson> But you don't want a greater frequency of re-orgs than normal or larger re-orgs than normal
03:32 <@michaelfolkson> Ideally all miners are enforcing Taproot rules from the point it activates
03:33 < devrandom> there would be a large financial incentive to enforcing after activation (reward would be lost)
03:33 <@michaelfolkson> Right, if the miners are ready they wouldn't choose to not enforce Taproot rules
03:33 <@michaelfolkson> But maybe they aren't ready
03:34 < devrandom> even if there's a small fraction are unready, there's a large incentive to fix that within the last retarget period
03:34 < devrandom> (before activation)
03:35 -!- pox [~pox@141.226.243.49] has quit [Quit: pox]
03:35 <@michaelfolkson> There is. But certain readiness is better than likely readiness :)
03:36 <@michaelfolkson> A large incentive makes readiness likely. Signaling readiness in advance is (pretty much) certain readiness
03:37 <@michaelfolkson> I guess also it is rushed if you aren't ready but there is a large incentive to be ready
03:39 < devrandom> understood
03:45 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation
04:08 <@michaelfolkson> Thanks for the question devrandom. Posted this StackExchange question. I'm pretty sure Luke will have some suggested edits but that is my current understanding :)
04:08 <@michaelfolkson> https://bitcoin.stackexchange.com/questions/102684/what-is-the-point-of-miner-signaling-in-a-soft-fork-activation-mechanism-what-s/
04:13 <@michaelfolkson> Oh there was already a question from the SegWit days https://bitcoin.stackexchange.com/questions/52326/what-are-the-risks-of-a-lower-than-95-activation-threshold-for-soft-forks-part
04:22 -!- belcher_ is now known as belcher
04:32 <@michaelfolkson> That SegWit answer has the additional consideration of SPV clients being fooled by miners producing blocks deliberately or inadvertently with invalid Taproot spends in them
04:59 <@michaelfolkson> Will post links here for the meeting later (19:00 UTC)
05:00 <@michaelfolkson> Notes from previous meeting: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018379.html
05:01 <@michaelfolkson> Arguments for LOT=true and LOT=false https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
05:01 <@michaelfolkson> Additional argument for LOT=false from harding (F7) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
05:02 <@michaelfolkson> Activation parameters proposal Google Doc drafted by luke-jr: https://docs.google.com/document/d/1Ewnxxxc51_JWJLZQfqc5W55Pvkgcf9TEh6Ks3wiHbRk/edit?usp=sharing
05:04 <@michaelfolkson> Some aj math on the impact threshold percentage has on mined invalid block being in longest valid chain for different durations of time: https://twitter.com/ajtowns/status/1321277134225043457
05:05 <@michaelfolkson> If needed original harding wiki on the different activation proposals. We (hopefully) seem to have landed on BIP 8(1 year) https://en.bitcoin.it/wiki/Taproot_activation_proposals
05:06 <@michaelfolkson> UASF docs from 2017: https://github.com/OPUASF/UASF
05:07 <@michaelfolkson> luke-jr blog post on BIP 148 from 2017: https://medium.com/@lukedashjr/how-you-can-help-ensure-bip148-is-a-success-2fb63bf5114f
05:08 <@michaelfolkson> Matt Corallo on UASF and Taproot activation (TFTC podcast): https://diyhpl.us/wiki/transcripts/tftc-podcast/2021-02-11-matt-corallo-taproot-activation/
05:11 <@michaelfolkson> Andreas Antonopoulos on UASF (Let's Talk Bitcoin podcast, 2017): https://diyhpl.us/wiki/transcripts/lets-talk-bitcoin-podcast/2017-06-04-consensus-uasf-and-forks/
05:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
05:55 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
06:50 -!- jonatack_ [~jon@37.173.51.99] has joined ##taproot-activation
07:09 -!- viaj3ro [5b23d159@p5b23d159.dip0.t-ipconnect.de] has joined ##taproot-activation
07:09 < viaj3ro> what time the meeting starts? 17 UTC?
07:16 < viaj3ro> ok, according to bitcoinops it's 19 UTC if anyone else is wondering
07:16 <@michaelfolkson> Yup 19:00 UTC https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
07:24 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
07:31 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-kndjfmofvkutwjbp] has joined ##taproot-activation
07:41 < nickler> On reducing the threshold to 90%, I wrote a quick & dirty simulation showing that the probability of unupdated nodes to be on a >=2 block invalid chain is increased by about 4x.
07:41 < nickler> It assumes the worst case that lagging miners don't update after lock-in & accept non-standard transactions. https://github.com/jonasnick/bip8-tester/blob/master/threshold.py
07:45 <@michaelfolkson> Cool, thanks for this nickler
07:52 <@michaelfolkson> Added to this Pastebin of links to resources: https://pastebin.com/iT1Tp8qf
07:57 < luke-jr> pox: what is sensible about releasing code that isn't intended to be used?
07:57 < luke-jr> all it does is create risks
08:08 -!- jonatack_ [~jon@37.173.51.99] has quit [Ping timeout: 256 seconds]
08:08 -!- jonatack_ [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
08:14 -!- jonatack_ [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 256 seconds]
08:21 -!- jonatack [~jon@37.173.51.99] has joined ##taproot-activation
08:26 -!- jonatack [~jon@37.173.51.99] has quit [Ping timeout: 265 seconds]
08:33 -!- belcher_ is now known as belcher
08:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
08:42 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Quit: Ping timeout (120 seconds)]
08:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
08:50 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
08:52 < pox> luke-jr why won't it be used? isn't there a good chance it gets activated quickly, within a couple of months?
08:52 < luke-jr> pox: LOT=false is code that wouldn't be used
08:53 < pox> which code specifically are you talking about?
08:53 < luke-jr> the code to allow miners to cancel the activation\
08:55 -!- proofofkeags [~proofofke@97-118-232-73.hlrn.qwest.net] has joined ##taproot-activation
08:56 < pox> are there no legitimate reasons for miners to signal "no"?
08:57 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
08:58 < luke-jr> exactly
08:59 < pox> I guess it would be helpful to hear miners' answers to that question.
09:00 < viaj3ro> luke-jr I agree with you in principle but why not simply go with 1y false since that's what everyone is on board with and just go for a UASF if miners fail to activate it within a couple months
09:01 < pox> I mean, if the difference between approaches is that one says "please upgrade and signal, or else we'll sudo ask you more firmly after N months" and the other just says "sudo signal, you have 1 year", then both are ultimatums, and the difference is cosmetic.
09:01 < luke-jr> pox: not sure why; miners don't decide anything in this regard
09:01 < luke-jr> viaj3ro: it is false to say everyone is on board with it
09:01 < viaj3ro> I'd prefer 1y true but nothing we say or do will convince miners (and also many devs) that it's the way to go. It would only create unnecessary opposition
09:02 < viaj3ro> who is opposing it, besides you?
09:02 < luke-jr> pox: it's more of "Taproot is activating. Please accelerate it if you can"
09:02 < pox> luke-jr then who decides which release of bitcoin a miner deploys their hash power to?
09:03 < luke-jr> pox: it doesn't matter
09:03 < viaj3ro> a lot of people seem to oppose 1y true, MUCH less opposition for 1y, false
09:03 < luke-jr> viaj3ro: don't know where you get that perception
09:03 < pox> luke-jr I ask because you said something that's equivalent to "miners don't get to decide which version of core their run".
09:04 < luke-jr> pox: no, it isn't equivalent.
09:04 < luke-jr> pox: if miners don't produce Bitcoin blocks, they aren't Bitcoin miners
09:04 < viaj3ro> from following the discussions, reading the logs, bitcoinops etc
09:09 -!- Alexandre_Chery [946692c2@148.102.146.194] has joined ##taproot-activation
09:10 < pox> luke-jr I don't see how it's helpful to pivot the discussion to semantics. the core of the disagreement is on whether miners receive an ultimatum or not. the sentiment among some people is that the ultimatum should be avoided if it could. if things shake out according to the happy path, 95% signal within a couple of months and none of this matters. if not, then at least we learned (another) lesson about the dynamics of pursuing soft forks - even
09:10 < pox>  uncontentious ones - and all future forks would be flag days, so to speak.
09:11 < luke-jr> pox: it is not an ultimatum
09:11 <@michaelfolkson> pox: There doesn't appear to be any reason why miners shouldn't be willing and ready to activate within a year, no. None of us can read the future but that is where we think we stand today.
09:11 < luke-jr> it's not just semantics to point out an incorrect portrayal
09:12 -!- Alexandre_Chery [946692c2@148.102.146.194] has quit [Client Quit]
09:12 < pox> how is "upgrade your gear within 12 months or your blocks will be rejected" not an ultimatum?
09:12 < luke-jr> pox: their blocks won't be rejected
09:12 < luke-jr> unless they make invalid blocks
09:12 < luke-jr> but that's on them
09:12 < luke-jr> and they can make valid ones at any time
09:13 <@michaelfolkson> I agree with pox here actually Luke. I think it is semantics
09:13 < luke-jr> smh
09:13 < pox> "give me your money or this gun will shoot you" isn't an ultimatum, because you can choose to give me your money? ;)
09:13 < luke-jr> pox: nobody is shooting them or demanding their money
09:13 <@michaelfolkson> Under lot=true miners have to signal during MUST_SIGNAL phase
09:14 < luke-jr> so what? it's no different than saying they can't steal bitcoins
09:14 <@michaelfolkson> Both can be described as ultimatums. It is just the ultimatum is something they've expressed support for
09:14 < pox> @michaelfolkson true.
09:15 < luke-jr> dishonestly described as*
09:15 <@michaelfolkson> But if for some unknown reason they either pull their support for Taproot or decide they aren't ready within a year both lot=true and lot=false with a UASF provide effective ultimatums
09:15 < pox> wait, no. I didn't see miners express support for false-then-true... I thought most voted for (false,1y)...
09:16 <@michaelfolkson> On taprootactivation.com some expressed a preference for (false,1y) that is true
09:16 <@michaelfolkson> We don't know if they are also happy with (true,1y)
09:16 < luke-jr> seems to me if miners are asking for the freedom to cancel Taproot, that's a red flag that they might intend to do so
09:16 <@michaelfolkson> That's a valid concern I think
09:17 < pox> @michaelfolkson right, (false,1y) by itself is certainly not an ultimatum. it's an invitation (pardon the digression to semantics again)
09:17 <@michaelfolkson> If they definitely want it activated within a year, lot=true for this particular soft fork shouldn't be a problem for them
09:18 < pox> luke-jr I agree, and if they seem to be asking for that freedom, isn't that reason for concern when trying to push it forcefully despite that red flag?
09:18 <@michaelfolkson> pox: It is an invitation but when the UASF comes (which it likely will) that is the ultimatum.
09:18 <@michaelfolkson> And with lot=true there is a lot more clarity for miners
09:18 <@michaelfolkson> With lot=false they don't know when the possible UASF is coming
09:19 < luke-jr> pox: no, because they have no right to cancel it
09:19 < pox> @michaelfolkson not knowing when the UASF will come means uncertainty for miners - does that incentivize them to upgrade & signal sooner or later?
09:20 <@michaelfolkson> pox: I guess you'd have to ask them. A UASF rushing them within 3 months doesn't seem at all optimal
09:20 <@michaelfolkson> If we went with lot=false I'd want to do everything in terms of communications to make sure people didn't try a UASF in the first 3 months
09:22 < luke-jr> you mean timeoutheight=3m?
09:22 <@michaelfolkson> But obviously they are free to ignore those communications if they wish
09:22 < pox> @michaelfolkson I think there weren't any suggestions to rush any of the timelines to a point where it causes miner pain. nobody is suggesting (true,1w) :) the core of the disagreement revolves what luke-jr just said - do they get a say in the activation and its timetable or not
09:22 <@michaelfolkson> luke-jr: I mean we set lot=false but then there is a UASF movement to force through activation in the first 3 months independently
09:23 < luke-jr> pox: timetable is one thing. sabotaging it is another.
09:23 < luke-jr> michaelfolkson: do you mean the movement exists within 3 months, or the lockin within 3 months? I can guarantee you the former will exist.
09:24 < luke-jr> FYI I posted this poll https://twitter.com/LukeDashjr/status/1361724761139773447
09:24 <@michaelfolkson> The lockin within 3 months, I really think that shouldn't happen for any UASF on top of lot=false
09:24 <@michaelfolkson> The movement can exist but it really shouldn't try lockin in the first 3 months (assuming lot is set to false)
09:24 < luke-jr> the only way I see that happening, is when there's only 3 months remaining
09:25 <@michaelfolkson> So 9 months into a (1y, false)
09:25 <@michaelfolkson> That would be fine for a UASF on top of (1y, false)
09:25 <@michaelfolkson> (In my opinion)
09:26 < pox> maybe the survey that populated the table in taprootactivation.com needs to be augmented. based on the outcome of the discussion about activation methods, the same miners could be approached to ask whether they support (true,1y), and if not then for what reasons? if no good reasons are provided, then we know not to ask again. I figured the (false,3m)+(true, 1y) approach would be a more structured way of doing this, rather than informal and
09:26 < luke-jr> I wouldn't call it fine :P
09:26 < pox>  non-binding queries. if they all signal quickly and cooperatively, then great. if not, and no good reason is given, then they get 9 more months of lot=true.
09:26 <@michaelfolkson> If lot is set to false we have to give miners *at least* 3 months to activate before considering a UASF
09:26 < luke-jr> pox: (true,15m) is strictly superior to that
09:27 < viaj3ro> well, no matter how we look at it, there is no consensus for 1y,true. If we go with 1y,false, chances are, taproot is activated quickly. If not, can always do a UASF. So what exactly are you trying to achieve by opposing 1y,false luke-jr?
09:27 < luke-jr> viaj3ro: there is less consensus on 1y,false
09:27 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
09:27 <@michaelfolkson> viaj3ro: Luke thinks 1y,true is superior. If he does he should argue for it.
09:27 <@michaelfolkson> I've got no problem with that and I understand his argument
09:28 < darosior> luke-jr: what is the source ? It seems to me to be the opposite
09:28 < luke-jr> darosior: several twitter polls, some posted by me, some by others
09:28 < pox> luke-jr am I correct in understanding that your main point is that the choice of activation method serves two purposes: 1. activate as soon as possible, safely, and 2. demonstrate to miners that from this fork on they will never get a chance to sabotage or otherwise delay activation again?
09:29 <@michaelfolkson> At some point we have to assess where the consensus is. I'd prefer to do this towards the end of the meeting to give time for discussing all arguments
09:29 < luke-jr> pox: pretty much just 1 really
09:30 < darosior> Was going to be sarcastic but: i don't think Twitter poll are a good metric.
09:30 < luke-jr> michaelfolkson: sadly, only ~100 or so people showed up at the last meeting :/ though it is what it is
09:30 < luke-jr> darosior: let me know when you find a better one
09:30 < viaj3ro> michaelfolkson I understand his argument as well and I even agree. Unfortunately we can't force our opinion on others and ideally have to agree which approach to use. Seems like 1y,false has less resistance
09:30 < luke-jr> darosior: historically, they have proven quite accurate
09:30 < pox> if it's just 1 then you ought not to care much if the process looks like [3 months false, then 9 months true] vs. [12 months true]. wouldn't you agree? given that share the estimate that it would get activated in either case within 12 months.
09:31 < darosior> This meeting is imho a better one
09:31 < luke-jr> viaj3ro: https://twitter.com/LukeDashjr/status/1361724761139773447
09:31 < darosior> We'll see
09:31 <@michaelfolkson> luke-jr: I do think people who attend these meetings have considered the argument to a greater extent than a random Twitter account
09:31 < luke-jr> darosior: well, since the proposal is coming out of these meetings, it does make sense to (despite the lower turnout) only propose based on what people here think
09:31 <@michaelfolkson> We have a lot of devs, miners, informed users on these meetings
09:31 < viaj3ro> luke-jr not sure how twitter polls, especially worded like this, are of much use
09:32 < luke-jr> viaj3ro: this one was worded specifically to address your claim
09:32 < luke-jr> the vast majority appear to not only just support LOT=true, but also oppose LOT=false
09:32 <@michaelfolkson> viaj3ro: In the absence of anything better I've got no problem with Twitter polls either. But I do think there's more signal in these meetings than Twitter polls
09:32 < pox> seems like a lot of people that answered that poll are on the fence or don't feel strongly about it (>60%)
09:33 <@michaelfolkson> A vote in a Twitter poll from someone who hasn't considered the arguments isn't the same as a vote from someone like Luke, harding, Greg etc
09:33 < viaj3ro> greg made some fair points against true. so its more than just giving miners the ability to cancel. many developers view it as a way to reduce their own power
09:34 <@michaelfolkson> That's F7, yes
09:34 < viaj3ro> that's why I'd argue the wording of that poll is very biased
09:35 -!- roconnor [~roconnor@host-104-157-194-235.dyn.295.ca] has quit [Ping timeout: 272 seconds]
09:37 < luke-jr> viaj3ro: that implies devs have power, which we don'ty
09:37 < pox> the power to set defaults
09:38 <@michaelfolkson> Again, I disagree Luke. Your voice is more powerful than say mine for good reason. You understand these activation better than me
09:38 < viaj3ro> luke-jr many devs have a defferent perception, it appears
09:38 < luke-jr> viaj3ro: if true, that's a serious problem / danger in itself
09:39 < viaj3ro> pox exactly
09:39 < luke-jr> michaelfolkson: that's influence, not power
09:39 < viaj3ro> influence is power
09:39 <@michaelfolkson> luke-jr: I think this is semantics again
09:39 < viaj3ro> it's a sort of power
09:40 <@michaelfolkson> Your review on a Core PR also has more weight than my review on a Core PR (for good reason)
09:40 < viaj3ro> without influence you most definitely have less power than with influence. so yeah, semantics...
09:41 <@michaelfolkson> You don't have ultimate power (no one does) but those who understand the system better have more ability to guide it
09:41 < pox> luke-jr, viaj3ro, what do you think the likely outcome of [false 6m then true 6m] would be compared to [true 12m]?
09:41 < luke-jr> pox: users who think they have Taproot support actually don't, making them vulnerable and the network as a whole less secure
09:42 < pox> could you please explain in what way users would be vulnerable under the first option?
09:43 <@michaelfolkson> One of the problems is we can't guarantee true, 6 months will happen when you say it will
09:43 < viaj3ro> pox: I'm on board with that. not sure if many others would. 6m seem short when it comes to bitcoin forks
09:43 <@michaelfolkson> It could happen earlier, later, or not at all
09:43 <@michaelfolkson> It could be well coordinated and organized or it could be uncoordinated and chaotic
09:44 < pox> doesn't have to be that exact, since lot=false doesn't have horrible implications if activation fails.. right?
09:44 <@michaelfolkson> Well now you're saying it is a false 12m with no true ever
09:44 < viaj3ro> my personal preference is 1y,true and if there is bigger agreement for 1y,false it's better than delaying activation even longer by fighting over how to activate it
09:45 < luke-jr> pox: users who only upgrade to the first part won't enforce Taproot when the 2nd part activates it (not even via MASF!)
09:46 < luke-jr> btw, I'm trying to extend the rationales for LOT=true on https://docs.google.com/document/d/1Ewnxxxc51_JWJLZQfqc5W55Pvkgcf9TEh6Ks3wiHbRk/edit?usp=sharing if anyone wnats to help review
09:46 < pox> luke-jr oh I see, I assumed it would be possible to release one version that switches automatically between false and true at a given date.
09:46 < luke-jr> currently simplifying michaelfolkson's T# and F# stuff
09:46 < luke-jr> pox: huh? that doesn't make sense
09:46 < luke-jr> pox: that's just 1y,LOT=true
09:47 <@michaelfolkson> pox: To switch it either the user has to change it or a new release has to change it
09:47 <@michaelfolkson> An automatic switch as you describe is as Luke says a 1y,true
09:48 < luke-jr> michaelfolkson: please let me know if I'm losing any important details in yuor T/F :P
09:49 <@michaelfolkson> Ha ok, will take a look
09:49 < pox> right. so in that sense luke-jr is right that those users would find themselves taproot-blind while the network has already activated.
09:50 < pox> assuming those users aren't miners, how would that harm them?
09:50 < luke-jr> pox: they would cease to have full node security
09:51 <@michaelfolkson> pox: If I understand your question they wouldn't be validating Taproot spends but they wouldn't be forked off the chain either
09:52 <@michaelfolkson> Any pre-Taproot version doesn't get forked off (this is a soft fork).
09:52 < pox> luke-jr I'm not sure what you mean by that. they don't create blocks that get rejected. they might relay some that get rejected, but not sure if that's a lot of harm - that's true for any ancient pre-segwit node as well, e.g. any user who hasn't opened his core wallet in years.
09:52 < luke-jr> they would be forked off the chain if miners create an invalid chain
09:52 < luke-jr> pox: it's no different than using a light wallet
09:54 <@michaelfolkson> It is better than a light wallet as you are still validating non-Taproot spends but not as good as an upgraded full node validating Taproot spends
09:54 <@michaelfolkson> It is a spectrum
09:55 < pox> but that's not the scenario we were discussing. the scenario was early activation (within months), in which case there's no difference between true & false, since >95% of miners have signaled.
09:55 -!- bjarnem [~bjarne@58.pool85-57-231.dynamic.orange.es] has joined ##taproot-activation
09:55 < luke-jr> michaelfolkson: it isn't really, because even otherwise-valid spends in the invalid chain aren't canoncial
09:56 <@michaelfolkson> pox: If miners activate early, LOT isn't relevant full stop
09:56 <@michaelfolkson> lot is only there if miners fail to activate by the end of the year
09:56 < pox> "users who only upgrade to the first part won't enforce Taproot when the 2nd part activates it" I understood this to mean the 2nd part (lot=true) made the activation happen. which means 95% of miners signaled. so how are lot=false users at risk in that scenario?
09:58 <@michaelfolkson> You mean a scenario where lot=false was set initially and then there was an attempted UASF with lot=true released 6 months in?
09:58 < pox> @michaelfolkson yes
09:59 <@michaelfolkson> In that case, assuming the UASF was successful, Taproot would activate within the year but any miners who weren't signaling during the MUST_SIGNAL phase would lose their block reward
09:59 < pox> or for that matter, just users who plain never bothered to upgrade at all, and aren't miners. are they at risk once activation though lot=true happens?
09:59 <@michaelfolkson> There are lots of different scenarios in this case which makes the question hard to answer
10:00 < pox> @michaelfolkson understood re miners, but I was asking about non-miners. the argument that luke-jr made, as far as I understand it, is that those users would be harmed by installing a version that has lot=false, and I'm trying to understand in what way those non-mining users would be harmed.
10:00 <@michaelfolkson> Users who were transacting during the MUST_SIGNAL phase would struggle to know what chain their transaction was confirmed on
10:01 < luke-jr> pox: they are at risk even iwth LOT=false MASF
10:01 < pox> @michaelfolkson there are two chains during MUST_SIGNAL?
10:02 < luke-jr> michaelfolkson: I'm not sure what to do with F3 :P
10:02 <@michaelfolkson> There is if half the network is enforcing MUST_SIGNAL and half the network isn't
10:02 < luke-jr> pox: only if miners produce invalid blocks, so unlikely
10:02 <@michaelfolkson> Temporarily at least
10:02 <@michaelfolkson> Could be resolved with a big re-org
10:02 < luke-jr> I forget if any such occurrences happedn with BIP148, but it wasn't noteworthy if so
10:02 < devrandom> will the released software signal right away (March), or only at startheight (July)?
10:03 < luke-jr> startheight
10:03 < luke-jr> though miners tend to ignore signals from Core, and set their own anyway
10:06 -!- bjarnem [~bjarne@58.pool85-57-231.dynamic.orange.es] has quit [Quit: Leaving]
10:06 < devrandom> when we say 1 year, we are actually saying more like 16 months (from release of software)
10:06 < pox> @michaelfolkson thanks. then that's a strong argument in favor of lot=true indeed. I didn't see it mentioned in any of the write ups, IIRC. thanks for the education @luke-jr @michaelfolkson
10:08 <@michaelfolkson> pox: I would say it is covered by T2 in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
10:09 <@michaelfolkson> But it is a summary, granted
10:09 < pox> well, FWIW I did read that and did not understand the risk as was just explained here.
10:09 <@michaelfolkson> Fair enough. As I said, a summary
10:12 <@michaelfolkson> This risk applies to both lot=true and lot=false if the network is split after miners fail to activate. Luke would argue that fighting the end state of activation at the end of the year by trying to enforce lot=false doesn't make much sense
10:15 < proofofkeags> FWIW I agree with the claim that if you say "start with l=f, then if after the period it fails we try again with l=t", the difference is cosmetic and is reductively the same as l=t with a longer time horizon
10:17 < proofofkeags> If, as a community, we are not prepared to let miners veto the proposal altogether, it doesn't make much sense to do l=f.
10:19 < luke-jr> k guys, I'm done adding the T/F points as rationales to https://docs.google.com/document/d/1Ewnxxxc51_JWJLZQfqc5W55Pvkgcf9TEh6Ks3wiHbRk/edit?usp=sharing
10:19 < proofofkeags> also I feel obligated to mention that, since this is a soft fork, and it imbues a presently undefined script version with new semantics, if a miner produces an invalid block, it's because someone is legitimately trying to steal coins
10:19 < luke-jr> please review, ideally without the original T/F points open first
10:19 < luke-jr> to make sure the rationales stand on their own :P
10:22 -!- solairis [bbbe2660@fixed-187-190-38-96.totalplay.net] has joined ##taproot-activation
10:24 <@michaelfolkson> You got track changes on luke-jr?
10:24 <@michaelfolkson> I don't want to edit what you've written if you'll want to revert to what you had before
10:25 < luke-jr> michaelfolkson: I think edits by others are suggestions by default
10:25 <@michaelfolkson> Ok cool
10:25 < proofofkeags> Point of clarification, will unupgraded miners who produce blocks which do not contain segwitV1 txs EVER be able to lose a block due to L=T?
10:26 -!- whuha [4f99f264@100.red-79-153-242.dynamicip.rima-tde.net] has joined ##taproot-activation
10:26 < luke-jr> yes, and also with L=F
10:26 -!- whuha [4f99f264@100.red-79-153-242.dynamicip.rima-tde.net] has quit [Client Quit]
10:27 < luke-jr> softforks have always been mandatory for miners
10:27 -!- whuha [4f99f264@100.red-79-153-242.dynamicip.rima-tde.net] has joined ##taproot-activation
10:27 < proofofkeags> this is because of MUST_SIGNAL?
10:27 < luke-jr> no, it's because without upgrading, the miner isn't enforcing the rule
10:28 < proofofkeags> sure but if the block doesn't contain txs that could ever violate the rule, then you can't fail validation for not enforcing the rule
10:28 < proofofkeags> the rule is vacuously enforced in that case
10:28 < luke-jr> you can, because you'd build on top of such a block
10:29 < whuha> eh
10:31 < proofofkeags> I think my point here is that any invalid block in this case is definitively an example of attempted theft, no?
10:32 < proofofkeags> sorry, that was a leap. My point is that if the only situation in which a block is invalid as a result of TR is if it contains, or builds on a block that contains a transaction that is being spent by a witness inconsistent with the terms of the proposal
10:33 -!- lockinontimeout [b9c3e9a9@185.195.233.169] has joined ##taproot-activation
10:33 < pox> @michaelfolkson if lot=true and activation fails, all other nodes (lot=false, older nodes) would be in the same boat on their way to destination F-ed.
10:33 < luke-jr> proofofkeags: that is true so long as miners activate
10:33 < luke-jr> proofofkeags: regardless of LOT
10:34 < proofofkeags> It's true even if they don't activate
10:34 <@michaelfolkson> pox: I wouldn't say so. Remember short term chaos only really hurts miners. Nodes (as long as they don't need to transact during that time) can sit back and wait for the inevitable re-org
10:35 -!- fiach_dubh [68fe5c3d@104.254.92.61] has joined ##taproot-activation
10:35 < luke-jr> proofofkeags: not really
10:35 -!- gg34 [4641afdd@S0106d807b66f84ea.rd.shawcable.net] has joined ##taproot-activation
10:35 -!- dfmb [bc521ab1@bl17-26-177.dsl.telepac.pt] has joined ##taproot-activation
10:35 <@michaelfolkson> pox: The chains only permanently split if a proportion of the network refuse to allow an eventual re-org to the longest chain
10:36 < luke-jr> proofofkeags: if they don't activate on their own, LOT=true is then needed
10:36 -!- Ulrich [bd06eb21@189.6.235.33] has joined ##taproot-activation
10:36 -!- beetcoin34 [aec30819@25.sub-174-195-8.myvzw.com] has joined ##taproot-activation
10:36 < luke-jr> proofofkeags: whether that's set upfront or down the road, that outcome is the same
10:36 < luke-jr> not doing it upfront just makes it more chaotic
10:36 -!- Ulrich [bd06eb21@189.6.235.33] has quit [Client Quit]
10:37 -!- hsjoberg [~hsjoberg@c-45c772d5.445-1-64736c11.bbcust.telenor.se] has joined ##taproot-activation
10:37 < pox> @michaelfolkson I don't think anyone want to be in that short chaos period this time. so with lot=true: scary chaos with low probability, with lot=false some nodes are insecure during MUST_SIGNAL (according to T2) with high probability.
10:37 -!- datawhisperer [4dabc72e@77-171-199-46.fixed.kpn.net] has joined ##taproot-activation
10:37 < proofofkeags> I think maybe you are misunderstanding what I'm getting at. The bottom line is that there is ZERO "good reason" to not activate. Because anyone using TR script version expects the rules to be enforced, so not enforcing them is being complicit in theft. In that case, it seems to justify L=T.
10:37 < luke-jr> pox: the chaos is with LOT=false..
10:38 <@michaelfolkson> pox: I think I would agree. But remember we *expect* miners to activate well before the year is over and lot=true or lot=false kicks in
10:38 < pox> luke-jr there is higher probability of minor chaos with lot=false and low probability of severe chaos with lot=true
10:38 -!- Yiggs [418d6092@65.141.96.146] has joined ##taproot-activation
10:39 < luke-jr> pox: I don't agree
10:39 <@michaelfolkson> pox: The probability of miners not activating well before the year is over is low as it is (from the data in taprootactivation.com etc)
10:39 < luke-jr> pox: also keep in mind universal LOT=false _will not happen_
10:39 < luke-jr> LOT=false is really a mixed network running partial LOT=false and partial LOT=true
10:40 <@michaelfolkson> And by that Luke means by the end of the year at least some nodes will be running LOT=true whatever was initially set
10:40 < queip> michaelfolkson: wonder if LN is affected...
10:40 < pox> luke-jr which is exactly why lot=false means high probability of low-severity chaos.
10:40 <@michaelfolkson> There is no viable scenario (barring some catastrophe) where all the nodes on the network are running LOT=false at the end of the year
10:41 < luke-jr> pox: that doesn't follow
10:41 < pox> Is T2 not low-severity chaos?
10:41 < luke-jr> chaos is low probability either way IMO; but more severe for LOT=false
10:41 -!- datawhisperer [4dabc72e@77-171-199-46.fixed.kpn.net] has quit [Client Quit]
10:42 < virtu> wow, it says lot=true seems to have community consensus in the draft
10:43 -!- tomat_ [53e3556d@c-6d55e353.026-238-73746f71.bbcust.telenor.se] has joined ##taproot-activation
10:43 -!- innawoods [6422f0ef@pool-100-34-240-239.phlapa.fios.verizon.net] has joined ##taproot-activation
10:44 < proofofkeags> In a weird way it does. AFAIK everyone advocating for l=f supports l=t if the initial period fails.
10:44 < luke-jr> the word "consensus" isn't in the draft…?
10:44 < pox> I'm trying to assign severity and probability weights to each case. The harm in T2 (lot=false) is not big for most users, but if there's an intransigent minority running lot=true that harm happens at a higher probability than failed activation.
10:44 < virtu> I wonder whether it'll come down to a vote
10:44 < hsjoberg> quiep: What do you mean?
10:45 < hsjoberg> queip*
10:45 < luke-jr> I would like to begin the meeting by trying to convince everyone to support LOT=true, if that's okay
10:45 -!- eeb77f71f26eee [~jakob@c-9b25205c.044-240-6c756c1.bbcust.telenor.se] has joined ##taproot-activation
10:45 -!- Bitbreather [5e3d097a@122.9.61.94.rev.vodafone.pt] has joined ##taproot-activation
10:45 < luke-jr> seems more likely to be productive than back-and-forth style debating
10:45 < luke-jr> if I fail, perhaps someone else can try to do the opposite
10:46 < proofofkeags> I think letting people lay out a complete case is a good idea
10:46 < luke-jr> (not to imply I myself am the only one doing the convincing :P)
10:46 < proofofkeags> still, despite the fact that I side with L=T, I think it'd be better if "opening statements" are made by a single party
10:46 < darosior> luke-jr: +1 for me, i believe it would be productive (preparing a list rn to argue point by point Michael's point and a summary of why i disagree)
10:46 < hsjoberg> I agree with Luke, the last meeting ended with the perception that lot=false had lot of support. I still contest that, so it would be good so see the reaction
10:46 < virtu> I strongly object. Coming out with this idea on such short notice with no one there to argue in favor of LOT=false is highly questionable
10:47 <@michaelfolkson> virtu: There will be discussion on LOT=false afterwards
10:47 <@michaelfolkson> I promise you both sides with have similar time
10:47 -!- tomat_ [53e3556d@c-6d55e353.026-238-73746f71.bbcust.telenor.se] has quit [Quit: Connection closed]
10:48 < luke-jr> darosior: have you seen the GDoc?
10:48 -!- Yari7 [b99affbc@185.154.255.188] has joined ##taproot-activation
10:48 < darosior> Yes but wanted to answer here, should i direct the list there ?
10:48 -!- mrb07r0 [bb56805e@187.86.128.94] has joined ##taproot-activation
10:48 -!- marzig [6c235737@pool-108-35-87-55.nwrknj.fios.verizon.net] has joined ##taproot-activation
10:48 <@michaelfolkson> I think focusing on the T arguments first makes sense. Then we'll move onto the F arguments
10:48 < luke-jr> virtu: nobody is being excluded from these meetings
10:48 < darosior> Or maybe is it more up to date
10:48 < viaj3ro> luke-jr: Another argument for L=T imho is that supporting L=F only makes sense if taproot is given up of not activated within a year. Supporting L=F and then L=T as a fallback will create more issues than going with L=T in the first place.
10:48 < robert_spigler> can I get a link to the doc
10:48 -!- f35 [b14f6d39@177.79.109.57] has joined ##taproot-activation
10:48 < proofofkeags> viaj3ro, exactly
10:49 < luke-jr> https://docs.google.com/document/d/1Ewnxxxc51_JWJLZQfqc5W55Pvkgcf9TEh6Ks3wiHbRk/edit?usp=sharing
10:49 < virtu> luke-jr: that doesn't address the problem that you come prepared to argue in favor of lot=true and no one else prepared to argue in favor of lot=false
10:49 <@michaelfolkson> All links today are in this Pastebin: https://pastebin.com/iT1Tp8qf
10:49 < robert_spigler> luke-jr michaelfolkson thanks
10:49 < proofofkeags> michaelfokson, that pastebin is private it seems
10:49 -!- rogueplanet [~planet9@res-61381d.ppp.twt.it] has joined ##taproot-activation
10:49 < proofofkeags> michaelfolkson, that pastebin is private it seems
10:49 -!- f35 [b14f6d39@177.79.109.57] has quit [Client Quit]
10:49 -!- eeb77f71f26eee [~jakob@c-9b25205c.044-240-6c756c1.bbcust.telenor.se] has left ##taproot-activation []
10:50 < robert_spigler> same on my end
10:50 -!- innawoods [6422f0ef@pool-100-34-240-239.phlapa.fios.verizon.net] has quit [Quit: Connection closed]
10:50 -!- fueleh [53ff97fe@c83-255-151-254.bredband.comhem.se] has joined ##taproot-activation
10:50 < pox> the rationale section of the GDoc is getting very good, and imho convincing.
10:50 <@michaelfolkson> virtu: I am sure people will argue lot=false. I will argue for it if no one else does
10:51 <@michaelfolkson> If you don't think the arguments for it are as well prepared we can organize another meeting
10:51 < viaj3ro> virtu: I think the only point of this meeting is to determine whether to go with true or false
10:51 -!- AngryAgain [50834a92@p50834a92.dip0.t-ipconnect.de] has joined ##taproot-activation
10:51 < luke-jr> virtu: what?
10:51 < pox> since the uphill battle seems to be to convince most that lot=true is preferable, I think it makes sense to prepare ahead of time with arguments and get a chance to lay them out.
10:51 -!- eeb77f71f26eee [~jakob@c-9b25205c.044-240-6c756c1.bbcust.telenor.se] has joined ##taproot-activation
10:51 < solairis> Is not this meeting for code review?
10:51 -!- bjarnem [~bjarne@58.pool85-57-231.dynamic.orange.es] has joined ##taproot-activation
10:51 <@michaelfolkson> Sorry no solairis. Code review will be next week
10:51 <@michaelfolkson> We had to do this LOT discussion
10:51 -!- only-reading [49a24e05@c-73-162-78-5.hsd1.ca.comcast.net] has joined ##taproot-activation
10:51 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
10:51 < solairis> Thank you
10:52 -!- benthecarman [~benthecar@2600:1700:201:6e60:bb6:181e:1d18:789a] has joined ##taproot-activation
10:52 -!- tomat96 [53e3556d@c-6d55e353.026-238-73746f71.bbcust.telenor.se] has joined ##taproot-activation
10:52 < fjahr> michaelfolkson: I don't think there should be more meetings, if there is no consensus here the discussion may need to move to the mailing list without a specific suggestion
10:52 -!- tomat96 is now known as tomat_
10:52 -!- only-reading [49a24e05@c-73-162-78-5.hsd1.ca.comcast.net] has quit [Client Quit]
10:52 -!- Alexandre_Chery [946692c2@148.102.146.194] has joined ##taproot-activation
10:52 <@michaelfolkson> To be clear this meeting was announced two weeks ago. There has been enough time to form arguments. There are arguments laid out in that mailing list post
10:52 -!- sortof [341650fb@ec2-52-22-80-251.compute-1.amazonaws.com] has joined ##taproot-activation
10:52 <@michaelfolkson> And it has been discussed on this channel during that time also
10:53 < solairis> What would be the logic to reach a consensus on LOT true or false?
10:53 -!- innawoods [6422f0ef@pool-100-34-240-239.phlapa.fios.verizon.net] has joined ##taproot-activation
10:53 <@michaelfolkson> New attempt at a Pastebin. This is public? https://pastebin.com/kFxWapfV
10:53 < luke-jr> solairis: answer objections to either/both and hope we can convince people?
10:53 < luke-jr> "Error, this is a private paste or is pending moderation. If this paste belongs to you, please login to Pastebin to view it."
10:53 < darosior> Doing my homeworks, trying to structure my points from michaelfolkson's helpful summary
10:53 < darosior> I disagree with T1: i don't think there is any logical consequence in hardcoding LOT=true ensuring Taproot activation and even less ensuring no political shenanigans. We obviously need economic majority to run it and that would open way more political arguments that they bluntly take part in an UASF without any bad behaviour from miners.
10:53 < darosior> I believe T2 is true but not really an argument in favor of LOT=true: the opposite is equally true, a lot of users would *not* run the code with the hardcoded consensus change
10:53 < darosior> I disagree with T3: i do think that if LOT=true is to be considered to be released it should be as a rehash later in the year after activation with LOT=false is clearly going to fail. There would be more weight for UASF arguments and essentially more information to take this decision.
10:53 < darosior> I disagree with T4: i think setting LOT=true should instead be a reaction to miner failing to activate (therefore demonstrating bad will). But re T1: setting LOT=true does not imply it will activate, a release with LOT=true in the current context may be quite controversial
10:53 < darosior> I think T5 is the most convincing argument but that we can't really measure "community consensus" (w/e it means) therefore we should try to not make it worse by having an even smaller set of people making such a big decision (LOT=true)
10:53 < darosior> Regarding the points on my opinion i like F3 and F6 (with the amendment that it's distrusting to everyone, not only miners)
10:54 < mrb07r0> please don't revive segwit drama, please don't revive segwit drama, please don't revive segwit drama '=D
10:54 -!- mrb07r0 [bb56805e@187.86.128.94] has quit [Quit: Connection closed]
10:54 -!- beetcoin34 [aec30819@25.sub-174-195-8.myvzw.com] has quit [Quit: Connection closed]
10:54 < luke-jr> darosior: economic majority needs to run Taproot regardless of LOT for it to be safe to activate..
10:54 -!- innawoods [6422f0ef@pool-100-34-240-239.phlapa.fios.verizon.net] has quit [Client Quit]
10:54 < darosior> Yes but it's not an argument for LOT=true
10:55 -!- DonaldBitrump [1f00b52e@31.0.181.46] has joined ##taproot-activation
10:55 < benthecarman> michaelfolkson: private for me
10:55 <@michaelfolkson> Arguments for LOT=true and LOT=false https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
10:55 < darosior> Private for me too
10:55 <@michaelfolkson> Additional argument for LOT=false from harding (F7) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
10:55 <@michaelfolkson> Activation parameters proposal Google Doc drafted by luke-jr: https://docs.google.com/document/d/1Ewnxxxc51_JWJLZQfqc5W55Pvkgcf9TEh6Ks3wiHbRk/edit?usp=sharing
10:55 < criley> Private for me too
10:55 <@michaelfolkson> StackExchange question on the threshold percentage: https://bitcoin.stackexchange.com/questions/102684/what-is-the-point-of-miner-signaling-in-a-soft-fork-activation-mechanism-what-s/
10:55 -!- sortof [341650fb@ec2-52-22-80-251.compute-1.amazonaws.com] has quit [Client Quit]
10:55 <@michaelfolkson> Some aj math on the impact threshold percentage has on mined invalid block being in longest valid chain for different durations of time: https://twitter.com/ajtowns/status/1321277134225043457
10:55 < luke-jr> darosior: let's dig into those 1 by 1 when the meeting starts
10:55 <@michaelfolkson> nickler quick & dirty simulation showing that the probability of unupdated nodes to be on a >=2 block invalid chain is increased by about 4x. It assumes the worst case that lagging miners don't update after lock-in & accept non-standard transactions. https://github.com/jonasnick/bip8-tester/blob/master/threshold.py
10:56 <@michaelfolkson> If needed original harding wiki on the different activation proposals. We (hopefully) seem to have landed on BIP 8(1 year) https://en.bitcoin.it/wiki/Taproot_activation_proposals
10:56 <@michaelfolkson> \UASF docs from 2017: https://github.com/OPUASF/UASF
10:56 <@michaelfolkson> luke-jr blog post on BIP 148 from 2017: https://medium.com/@lukedashjr/how-you-can-help-ensure-bip148-is-a-success-2fb63bf5114f
10:56 <@michaelfolkson> Matt Corallo on UASF and Taproot activation (TFTC podcast): https://diyhpl.us/wiki/transcripts/tftc-podcast/2021-02-11-matt-corallo-taproot-activation/
10:56 < benthecarman> Is the plan for this meeting to debate lot false/true or to review luke-jr 's bip 8 PR to core?
10:56 <@michaelfolkson> Andreas Antonopoulos on UASF (Let's Talk Bitcoin podcast, 2017): https://diyhpl.us/wiki/transcripts/lets-talk-bitcoin-podcast/2017-06-04-consensus-uasf-and-forks/
10:56 < darosior> benthecarman: debate true
10:56 -!- tomat_ [53e3556d@c-6d55e353.026-238-73746f71.bbcust.telenor.se] has quit [Client Quit]
10:56 -!- observer36 [d049668c@208-73-102-140.fttp.usinternet.com] has joined ##taproot-activation
10:56 <@michaelfolkson> benthecarman: No. See https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
10:57 -!- satosaurian [b0c7d357@ip-176-199-211-87.hsi06.unitymediagroup.de] has joined ##taproot-activation
10:57 < luke-jr> benthecarman: the former, though better to debate LOT=true first, then only debate LOT=false if we fail to reach consensus on LOT=true
10:57 -!- observer36 [d049668c@208-73-102-140.fttp.usinternet.com] has quit [Client Quit]
10:57 < benthecarman> Thanks
10:57 <@michaelfolkson> No Luke. LOT=false gets the same chance
10:57 <@michaelfolkson> We will discuss consensus at the end
10:57 < proofofkeags> ^
10:57 -!- observer38 [d049668c@208-73-102-140.fttp.usinternet.com] has joined ##taproot-activation
10:57 <@michaelfolkson> But LOT=true advocates get same time as LOT=false advocates
10:58 < proofofkeags> it doesn't make sense to have a debate until opening statements from both sides get the chance to lay out a complete case
10:58 <@michaelfolkson> I'm happy to go to Luke first for LOT=true arguments
10:58 < virtu> michaelfolkson: so it'll be like 30m/30m?
10:58 <@michaelfolkson> Yup
10:58 < proofofkeags> we should leave time for back and forth
10:59 <@michaelfolkson> And then discussion on which is more likely to get consensus. Only after arguments have been discussed
10:59 < luke-jr> reminder that we do have other topics :P
10:59 < robert_spigler> Really like the google doc guys!
10:59 <@michaelfolkson> Ok we're starting in 30 seconds
11:00 <@michaelfolkson> #startmeeting
11:00 < luke-jr> should we talk about threshold first just to quickly get that out of the way? :p
11:00 -!- Kappa [b9d598af@185.213.152.175] has joined ##taproot-activation
11:00 <@michaelfolkson> Feel free to say hi
11:00 < darosior> hi
11:00 < CubicEarth> hello
11:00 < solairis> hi
11:00 < robert_spigler> hi
11:00 < emzy> hi
11:00 < virtu> luke-jr: good idea
11:00 < bjarnem> hi
11:00 < virtu> hi
11:00 < hsjoberg> Hey
11:00 < Kappa> Hi
11:00 < pox> hi
11:00 -!- jonatack [~jon@37.173.74.168] has joined ##taproot-activation
11:00 < harding> michaelfolkson: I suggest asking if anyone besides luke-jr wants to make an opening statement regarding LOT=true.  I haven't seen any dissatisfaction from LOT=true supporters with luke-jr's advocacy of it, but I also haven't looked that hard, so it's possible that thare are people who support LOT=true but want to say something different than Luke does.
11:00 < harding> hi.
11:00 < ghost43> hi
11:00 < fjahr> hi
11:00 < benthecarman> hi
11:00 < virtu> luke-jr: also startheight maybe
11:00 <@michaelfolkson> I can give you 5 minutes on threshold luke-jr. if it needs more than that we need to move on
11:01 <@michaelfolkson> The plan was to do that at the end
11:01 <@michaelfolkson> Actually let's keep to that plan
11:01 -!- Yiggs [418d6092@65.141.96.146] has quit [Ping timeout: 240 seconds]
11:01 <@michaelfolkson> Threshold, startheight at the end
11:01 -!- debit [~debit@195.181.160.175.adsl.inet-telecom.org] has joined ##taproot-activation
11:01 < achow101> hi
11:01 < hsjoberg> I'm leaning towards LOT=true but I can probably chime in with comments rather than having an opening statement
11:01 < debit> hi
11:01 < virtu> michaelfolkson: +1
11:01 -!- dres [b9e918cb@185.233.24.203] has joined ##taproot-activation
11:01 <@michaelfolkson> I'll give people some time to join but please refer to https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
11:01 -!- dres [b9e918cb@185.233.24.203] has quit [Client Quit]
11:02 < proofofkeags> hi
11:02 < viaj3ro> Hi
11:02 <@michaelfolkson> Ok. Anyone else want to do a statement on LOT=true besides Luke?
11:02 <@michaelfolkson> Personally I'm happy to leave to luke-jr
11:02 -!- Yiggs [418d6092@65.141.96.146] has joined ##taproot-activation
11:02 < jonatack> hi
11:02 < hsjoberg> One question before we start if I may... If we choose to go with lot=false as default, is it possible for the user to reconfigure their won node to be lot=true? Without re-compiling that is.
11:02 < proofofkeags> I could, but I anticipate Luke will make my points better than I can
11:02 < robert_spigler> harding: I believe I've been pretty vocal on my opinion for LOT=true, especially T2 and T6
11:02 < belcher> hi
11:03 < luke-jr> hsjoberg: worst case scenario, someone can recompile and share it. I will be happy to verify the builds
11:03 < harding> robert_spigler: indeed you have, from my perspective.
11:03 <@michaelfolkson> I'll hand over to Luke in 2-3 minutes
11:03 -!- Lintfree [b2d7c479@host-178.215.196.121-internet.zabrze.debacom.pl] has joined ##taproot-activation
11:03 < luke-jr> I suggest everyone start off reading the LOT=true rationales listed on https://docs.google.com/document/d/1Ewnxxxc51_JWJLZQfqc5W55Pvkgcf9TEh6Ks3wiHbRk/edit?usp=sharing
11:03 < hsjoberg> luke-jr: So it isn't configurable via bitcoin.conf -- you need to recompile?
11:03 -!- fiach_dubh72 [63f42379@cpe1033bfa9e0e7-cm1033bfa9e0e5.cpe.net.cable.rogers.com] has joined ##taproot-activation
11:03 < luke-jr> hsjoberg: there is nothing today period. Only time will tell what Core merges.
11:04 < luke-jr> the rationales in the GDocs are pretty much the only intro I can think of? :P  can we just move on (in a minute) to people proposing objections to answer? XD
11:04 < Murch> Hi
11:05 < hsjoberg> Because if it isn't, it could put is in a new shaolinfy scenario, where people has to run another node other than Core to make UASF. This puts in me more firmly in lot=true camp.
11:05 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined ##taproot-activation
11:05 < luke-jr> ie, anyone who *isn't* convinced LOT=true is okay, can start with reasoning for that, and we can try to convince him
11:05 <@michaelfolkson> Ok that works too
11:05 < virtu> luke-jr: Ensures activation within a year -> it does, but is activation more important than not splitting the chain?
11:05 -!- Yiggs30 [418d6092@65.141.96.146] has joined ##taproot-activation
11:06 -!- brg444 [c8448a0c@200.68.138.12] has joined ##taproot-activation
11:06 <@michaelfolkson> Please refer to T1 to T6 either in here or in the Google Doc https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
11:06 < luke-jr> virtu: LOT=true does not split the chain. It strictly reduces the liklihood of that.
11:06 -!- glozow [sid453516@gateway/web/irccloud.com/x-eecqfvkinqkxwjyj] has joined ##taproot-activation
11:06 -!- prayank [~andr0irc@2409:4053:219c:5e4:5428:b9d2:df47:53e3] has joined ##taproot-activation
11:06 < nickler> what's the difference between T and F "Rationales" in the docs?
11:06 < virtu> luke-jr: If miners do not upgrade, they'll end up on another chain than LOT=true nodes
11:06 -!- fiach_dubh [68fe5c3d@104.254.92.61] has quit [Ping timeout: 240 seconds]
11:06 -!- observer38 [d049668c@208-73-102-140.fttp.usinternet.com] has quit [Quit: Connection closed]
11:06 < robert_spigler> virtu: LOT=false has chainsplit risks, not LOT=true
11:06 < luke-jr> nickler: T began as arguments in favour, and F began as arguments against
11:06 < proofofkeags> they are addressing the points on the email that michaelfolkson sent out
11:07 < luke-jr> virtu: not necessarily, but that is a choice they can make no matter what we do
11:07 < proofofkeags> all Rationale's in the GDoc are arguments for LOT=true
11:07 <@michaelfolkson> nickler: My mailing list post has arguments T1-T6 and F1-F6. harding added F7
11:07 -!- gr-g [4db9759e@x4db9759e.dyn.telefonica.de] has joined ##taproot-activation
11:07 < pox> proofofkeags not quite in the same numbering though.
11:07 <@michaelfolkson> Luke's Google Doc argues for LOT=true
11:07 -!- Kappa [b9d598af@185.213.152.175] has quit [Quit: Connection closed]
11:08 < luke-jr> virtu: miners can always create invalid blocks, which is what they would be doing in that case
11:08 < harding> luke-jr: LOT=true only reduces the risk of chainsplit of software enforcing it is adopted by a reasonable percentage of economic full nodes (with none opposing it).  You can't know that will happen in advance.
11:08 <@michaelfolkson> I can go through each one if luke-jr would prefer I do that?
11:08 < virtu> luke-jr: that's twisting facts
11:08 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
11:08 < achow101> luke-jr: LOT=true appears as if the developers are forcing a change upon the community. while that may not necessarily be the case, the appearance of that happening is not a good thing. Given that we don't believe there will be any issues with activation, I would prefer LOT=false to avoid this view
11:08 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined ##taproot-activation
11:08 -!- Alan58 [54e364cd@adsl-84-227-100-205.adslplus.ch] has joined ##taproot-activation
11:08 -!- Yiggs [418d6092@65.141.96.146] has quit [Ping timeout: 240 seconds]
11:08 -!- lockinontimeout [b9c3e9a9@185.195.233.169] has quit [Quit: Connection closed]
11:08 < luke-jr> harding: softforks in general are only safe (even miner-activated) if an economic majority is enforcing them
11:08 < virtu> they are continuing to produce previously valid blocks that are rejected by LOT=true nodes that split from the network
11:08 < hsjoberg> Lot=false can still split the chain. Everyone has to upgrade in a fork.
11:08 <@michaelfolkson> Please refer to T1-T6 and F1-F7
11:08 < darosior> Ok, let's jump in. I disagree with T1: i don't think there is any logical consequence in hardcoding LOT=true ensuring Taproot activation and even less ensuring no political shenanigans (actually the opposite).
11:08 < virtu> you can argue that point in both directions
11:09 <@michaelfolkson> achow101's argument is F7
11:09 < hsjoberg> Lot=true would make sure upgraded nodes mandate a specific chain
11:09 < fjahr> achow101: agree
11:09 < proofofkeags> achow101, is there value to educating the community that that isn't what is happening, even in the L=T scenario?
11:09 < harding> luke-jr: I concur; that's true of all consensus rules, old or new.
11:09 < brg444> Did somebody bothered asking why we need consensus on this or whether it’s achievable at all
11:09 -!- Billy [9f020fd5@dhcp-213-15-2-159.pbband.net] has joined ##taproot-activation
11:09 -!- Alexandre_Chery [946692c2@148.102.146.194] has quit [Quit: Connection closed]
11:09 <@michaelfolkson> F7 is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
11:09 < virtu> brg444: why? I guess because core has to ship an activation mechanism
11:09 < achow101> proofofkeags: there may be, but it is easier for the anti-bitcoin crowd to jump on that argument to spread FUD. There are already people doing that with taproot itself and I fear this will lend them more fuel and credence
11:09 -!- evankaloudis [4b611f61@75.97.31.97.res-cmts.leh.ptd.net] has joined ##taproot-activation
11:10 <@michaelfolkson> brg444: If we don't get consensus we don't get consensus. This is an attempt to try to get consensus
11:10 -!- jonatack [~jon@37.173.74.168] has quit [Ping timeout: 264 seconds]
11:10 < darosior> brg444: debate is probably useful as much as consensus.
11:10 < luke-jr> achow101: it has no more appearance of that than LOT=false or even doing nothing would. on the contrary, if developers were to deploy LOT=false while the community has decided on Taproot, that would objectively be devs "forcing" a miner veto on the community
11:10 < robert_spigler> people will spread FUD regardless.  Let's stick to objectivity here.  LOT=true is safer
11:10 < brg444> It seems a very futile attempt
11:10 <@michaelfolkson> You're free to leave brg444 if you think it is a waste of time
11:10 < luke-jr> harding: therefore, we must estimate economic majority for the startheight, regardless of LOT=true/false
11:10 < viaj3ro> are there any good arguments for LOT= false besides fear of how it appears?
11:11 < benthecarman> Anecdotally it seems most people don't care about F7. From various twitter polls most people vote for lot=true
11:11 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
11:11 < achow101> luke-jr: that does not track. LOT=true means that it *will* activate, LOT=false gives everyone else in the community the ability to decide
11:11 < pox> @achow101 not having a discussion because it might become FUD fodder just means self censorship or making discussion private.
11:11 < brg444> No im trying to make the point that both parties are best served running whichever version they see fit and the outcome will be unnaffected anyway
11:11 < debit> brg444 node operators want some rough consensus because if we uncessarily split the chain -- pow is under applied to the diverging chains
11:11 <@michaelfolkson> viaj3ro: Please read the arguments in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
11:11 < luke-jr> achow101: LOT=false gives miners the ability to decide
11:11 < harding> robert_spigler: LOT=true is only safer if that's what many people use; the best evidence we'll have that people are willling to adopt taproot won't occur until software enforcing it has been released, which will be after we choose whether to use LOT=true or false for the initial deployment.
11:11 <@michaelfolkson> F1 - F7. We're focusing on T arguments now
11:12 < luke-jr> achow101: if the community hasn't already decided for Taproot, ANY activation deployment is premature
11:12 < viaj3ro> achow101 lot=false will guarantee that activation fails unless users take action which will crate many coordination issues
11:12 < robert_spigler> achow101:  If we haven't reached consensus, we shouldn't be discussing activation
11:12 -!- Alexandre_Chery [946692c2@148.102.146.194] has joined ##taproot-activation
11:12 < fjahr> luke-jr: and with LOT=True this channel has already decided?
11:12 < robert_spigler> MASF is merely for faster activation
11:12 <@michaelfolkson> achow101: LOT=false requires a UASF if miners don't activate
11:12 -!- KatieTheRussian [89672c46@static-137-103-44-70.fl.cpe.atlanticbb.net] has joined ##taproot-activation
11:12 < virtu> fjahr: yes, last meeting the majority was against LOT=true
11:12 -!- janoside [44eb2b54@68.235.43.84] has joined ##taproot-activation
11:12 <@michaelfolkson> achow101: LOT=true, everything is set in stone at the beginning
11:12 < brg444> not if enough people are also running lot=true
11:13 < achow101> if the community has already decided to activate, there's no need to LOT=true. Miners are part of the community.
11:13 < benthecarman> achow101: that's not how segwit worked out
11:13 < brg444> you do not need consensus on lot=true for it to achieve its purpose
11:13 < luke-jr> fjahr: this channel will only be making a recommendation.
11:13 < luke-jr> fjahr: there are far too few people here to speak for the community as a whole
11:13 <@michaelfolkson> achow101: There is a (low) probability that miners don't activate. We should plan for that
11:13 < hsjoberg> achow101: There's also need for letting miners activate it.
11:13 < darosior> michaelfolkson: requiring an UASF is a good thing imho, given that we were provided with the tool to do it more safely. Rather than doing it gratuitously
11:14 <@michaelfolkson> achow101: Otherwise we have a rushed UASF like with SegWit
11:14 < luke-jr> virtu: there was no voting done at the last meeting at all.
11:14 < waxwing> i have always been on the side of LOT=false principally for reason F5 , but i do not fundamentally object to LOT=true.
11:14 < robert_spigler> harding: we know people will run LOT=true regardless of the default, so it will be safer if LOT=true is made the default
11:14 < luke-jr> achow101: miners are an insignificant part of the community, with no special privileges.
11:14 -!- dfmb [bc521ab1@bl17-26-177.dsl.telepac.pt] has quit [Quit: Connection closed]
11:14 < viaj3ro> brg444 can still try to reach consensus now
11:14 -!- wampum [59244ebd@89.36.78.189] has joined ##taproot-activation
11:14 < brg444> the segwit uasf never activated and was not run by a majority of users
11:14 < hsjoberg> Any objections to taproot should have been raised years ago. Not now when the software is ready
11:14 < proofofkeags> luke-jr, I think treating miners as "insignificant" is a dangerous view, even if they shoulnd't have special privileges
11:14 -!- brg444 [c8448a0c@200.68.138.12] has quit [Quit: Connection closed]
11:15 <@michaelfolkson> luke-jr: I don't like the wording. Special privileges, no. But they are as significant as anybody else
11:15 < darosior> robert_spigler: the opposite is true as well
11:15 < harding> robert_spigler: there is no way to prove that we have reached consensus; all we can do is make a best guess.  If we guess there's consensus when there isn't, people using LOT=true are at increased risk of leaving the economic majority's chain.  If we choose LOT=false, then we get a chance to see whether people actually use the software or not, can see if miners will activate on their own, and can advocated for people using LOT=true if
11:15 < harding> necessary.
11:15 < benthecarman> proofofkeags I think he means as in size, not releveance
11:15 < virtu> robert_spigler: force the hand of all constituents because a few people might run a LOT=true node?
11:15 < luke-jr> michaelfolkson: collectively, they are less than 1%
11:15 < virtu> I think the majority will stick with what core will be shipping
11:15 <@moneyball> hi. sorry joining late.
11:16 < hsjoberg> BIP9 signaling is not supposed to be a vote. It's merely a coordination tool.
11:16 < luke-jr> harding: LOT=false does not actually provide any new information, though?
11:16 < devrandom> hi
11:16 -!- jonatack [~jon@37.173.74.168] has joined ##taproot-activation
11:16 -!- NoDeal [6b4dda22@mobile-107-77-218-34.mobile.att.net] has joined ##taproot-activation
11:16 < virtu> using LOT=true just sets a bad precedent. what prevents "users" from forcing changes disadvantageous to miners in the future?
11:16 <@michaelfolkson> Personally I think the strongest argument for LOT=true is that with LOT=false there is a lot of uncertainty about when a UASF should happen (if at all) and a lot more work to do if miners fail to activate
11:16 < darosior> luke-jr: a failed activation with LOT=false does provide the information that the miners have acted maliciously
11:16 -!- jonatack [~jon@37.173.74.168] has quit [Read error: Connection reset by peer]
11:16 < luke-jr> I'm getting lost in all the cross-discussion. Who here is OPPOSED to LOT=true (not merely prefer LOT=false)
11:16 < luke-jr> ?
11:16 -!- rogueplanet [~planet9@res-61381d.ppp.twt.it] has left ##taproot-activation ["Leaving"]
11:16 < virtu> miners are, no matter how much some people wish they weren't, an important part of the network
11:16 < hsjoberg> michaelfolkson: I agree
11:16 < harding> luke-jr: the local business owners in your home town probably also represent a minority of the population, but they're probably unusually committed to the future success of your hometown.  Miners with collectively billions invested in Bitcoin's healthy future should probably be given some level of respect, IMO.
11:17 < robert_spigler> harding:  LOT=false only (might) provide info about what miners are running
11:17 < benthecarman> michaelfolkson: agreed
11:17 < luke-jr> darosior: why give them the ability to act maliciously in the first place?
11:17 < waxwing> luke-jr, if we ask that we should also ask the opposite
11:17 -!- tomat40 [53e3556d@c-6d55e353.026-238-73746f71.bbcust.telenor.se] has joined ##taproot-activation
11:17 < fjahr> The LOT=True crowd seems to have an underlying assumption that a UASF will occur instead of something more orderly like Modern Softfork Activation suggested, why? I don't think chances of that happening are very high unless things play out similarly to Segwit but it doesn't look like that.
11:17 -!- tomat40 is now known as tomat_
11:17 < belcher> virtu UASFs can be made much more difficult with a counter-UASF.... UASFs like this one and segwit relied on intolerant-minority effects
11:17 < darosior> luke-jr: why treat them as malicious in the first place ?
11:17 < pox> @virtu that would be a precedent if the current change were indeed detrimental to miners.
11:17 < hsjoberg> That is the reason why I asked if lot would be configurable in bitcoin core
11:17 < luke-jr> waxwing: that is after the LOT=true discussion..
11:17 < darosior> luke-jr: better to expose to the world bad will, then "punish" rather than "punishing" gratuitously
11:17 < benthecarman> fjahr: I believe most people think it will be activated by miners, its just we should have a failsafe in the UASF just in case
11:17 < robert_spigler> virtu: it's not a few people, and only the LOT=false nodes are at wipeout risk
11:17 < luke-jr> darosior: not giving them special priviliges is not treatign them as malicious
11:17 <@michaelfolkson> fjahr: At the moment we are doing a BIP 8(1 year). If LOT is set to false and miners fail to activate there will be attempted UASFs
11:17 < luke-jr> darosior: LOT is not a punishment
11:17 < hsjoberg> If we go for lot=false, and miners play games. Users should not have to change software to do a UASF.
11:18 < harding> luke-jr: LOT=false does not; people choosing to run software that will enforce taproot under some reasonable circumstances provides the information.  LOT=false just reduces the risk of unexpected results from resulting in danger.
11:18 -!- rgrant [~rgrant@unaffiliated/rgrant] has joined ##taproot-activation
11:18 <@michaelfolkson> fjahr: With LOT=true, attempted UASFs are not necessary
11:18 < luke-jr> harding: LOT=false strictly increases the risks though..
11:18 < achow101> if you insist that LOT=true is necessary because miners are going to veto, then just cut out the miners entirely and flag day the activation instead
11:18 < robert_spigler> If we don't have consensus, we are premature in this conversation
11:18 < robert_spigler> Miners coordinate, not vote
11:18 < fjahr> michaelfolkson: how can you be so sure if there will be a UASF attempt?
11:18 < harding> luke-jr: please stop saying that, there are tradeoffs both ways.
11:18 < proofofkeags> UNLESS you intend to let a failed L=F activation be somewhat final, it doesn't make any sense to do L=F in the first place. If, in your head, you support the idea of doing L=F and then trying L=T if the first time fails, you are in support of L=T from the beginning, albeit with a longer time horizon.
11:18 < virtu> luke-jr: the risks of what?
11:19 <@michaelfolkson> fjahr: Because Luke and others have said there will
11:19 < belcher> isnt LOT=true technically a UASF?
11:19 < benthecarman> proofofkeags: +1
11:19 < fjahr> michaelfolkson: that sounds like keeping others hostage
11:19 < proofofkeags> belcher: yes
11:19 < virtu> belcher: yes
11:19 < benthecarman> belcher so long as the miners dont activate
11:19 <@michaelfolkson> belcher: A UASF where we know the timing and there is no further action necessary
11:20 < hsjoberg> belcher: lot=true is about the same as the SegWit UASF
11:20 < ghost43> proofofkeags: not necessarily because miners not activating within 1 year gives extra information. we would expect them to explain what happened, wouldn't we?
11:20 < pox> proofofkeags +1
11:20 <@michaelfolkson> fjahr: Anyone is free to set LOT=true in their software
11:20 < benthecarman> I see activation as a coordination problem, and lot=true will solve most coordination problems and incentives the most coordination from miners <> users
11:20 <@michaelfolkson> fjahr: Whatever Core and other implementations set it as, users can change it
11:20  * CubicEarth likes harding's points
11:21 < proofofkeags> ghost43 I'm saying that if you *can* be convinced that this is a bad thing for Bitcoin by a miner argument, then that's an argument for L=F. So presumably you're saying theres important information not yet reflected.
11:21 -!- brg444 [c8448a0c@200.68.138.12] has joined ##taproot-activation
11:21 < viaj3ro> proofofkeags: +1
11:21 -!- brg444 [c8448a0c@200.68.138.12] has quit [Client Quit]
11:21 < hsjoberg> The ease of doing UASF is at risk if it would require a new software. I think lot has to be configurable by the user.
11:21 < fjahr> michaelfolkson: of course, but that's not an argument for anything :)
11:21 < prayank> harding: I agree miners are important. I think people don't hate miners but anyone who does politics, drama, misinformation etc. and delays important things that almost everyone knows will improve Bitcoin and agree initially. Bad miners can be replaced with anyone. Example: People with more influence in Development or Exchanges etc. because they all are involved in mining as well to some extent and other discussion tha
11:21 < hsjoberg> The default could be false.
11:21 <@michaelfolkson> We will wrap up arguments on LOT=true in 10 minutes and focus on LOT=false arguments
11:21 < gg34> there was talk of precedent. is there no harm in handing the network sovereignty ultimately in the hands of individual node runners to miners? it almost encourages the backroom deals we saw last time. A lot of the danger in a UASF is not doing it upfront imo.
11:22 < benthecarman> gg34 +1
11:22 -!- jonatack [~jon@37.173.74.168] has joined ##taproot-activation
11:22 < hsjoberg> Well said.
11:22 <@michaelfolkson> Please stay to the end of the lot=false arguments so we can assess consensus
11:23 < rgrant> gg34: +1
11:23 < luke-jr> so I'll try again: who is positively opposed to LOT=true at this point?
11:23 < devrandom> a reminder that miners *already agreed to activate* verbally.  so failure to activate will most likely be a minority trying some political move.
11:23 < proofofkeags> gg34 +1. I will say though, that I think this discussion would have benefitted from having a more clear view of the community overwhelmingly supporting this. Off topic for this meeting, but anyone interested in how to get better data around this, I'd be interested to work with.
11:23 < hsjoberg> devrandom: The only thing I trust is them signaling with their blocks. Not some tweet.
11:23 -!- tomat_ [53e3556d@c-6d55e353.026-238-73746f71.bbcust.telenor.se] has quit [Quit: Connection closed]
11:23 < hsjoberg> The support for SegWit before it went political was fairly positive as well.
11:24 <@michaelfolkson> luke-jr: I think harding is opposed and will outline his arguments no doubt when we move onto false arguments.
11:24 < harding> proofofkeags: reasons it makes sense to do L=F in the first place, even if one supports L=T if necessary, is the ability to collect and propagate additional information during the time L=F was set.  Examples of collecting additional information is seeing whether miners are willing to *voluntarily* follow through with their commitments and seeing how fast people upgrade to taproot-enforcing software.  Examples of propagitng useful information
11:24 < harding>  include argument F7.
11:24 < debit> devrandom failure on miner's part may be due to infrastructure deployment issues
11:24 < waxwing> even signalling doesn't prove anything, unfortunately. which is another reason to remember it's only intended for cooperative coordination, not voting.
11:24 < belcher> to be fair even the signalling in the block thing can be false, that actually happened in bip66 and lead to some short chain splits in july 2015
11:24 < harding> luke-jr: I'm moderately opposed to starting with L=T.
11:24 < robert_spigler> harding:  why can't you do that in the 1 year before the timeout of LOT=true?
11:24 <@michaelfolkson> luke-jr: achow101 was opposed (I think)
11:24 < devrandom> debit: for 16 months?  (4 months to startheight + 1 year)
11:24 < luke-jr> harding: because of perception only?
11:24 < harding> luke-jr: no.
11:25 < evankaloudis> what's the argument against trying LOT=f for 6 months and going to a UASF in the form of LOT=t for the following 6 if not activated by miners? just higher chain split risk?
11:25 < proofofkeags> harding: I find that convincing. I'd like to make the timeout shorter if possible. If this is a data gathering exercise, shortening the feedback loop would be good. If it's coordination on activation, longer is better.
11:25 < luke-jr> please elaborate ._.
11:25 < nickler> To hardings point: A softfork should only activate when an overwhelming majority enforces it. One of the few estimators for adoption that the consensus protocol has is miner signalling.
11:25 <@michaelfolkson> luke-jr: I think Matt Corallo is opposed to LOT=true. Greg is opposed unless there is clear consensus on LOT=true
11:25 < nickler> Without additional assumptions or out-of-band information, less than 95% of miner signalling indicates that less than 95% of nodes have updated.
11:25 < debit> devrandom it would be surprising for them not to be able to deploy in the prescribed period but there's still the possibility
11:25 < hsjoberg> waxwing: It proves that it will get activated when it has reached the threshold
11:25 < hsjoberg> Which is quite different than a tweet
11:25 < proofofkeags> nickler: hashpower, not nodes
11:25 < harding> luke-jr: I will do.  I think michaelfolkson said he wanted to separate the discussion into segments.
11:26 -!- DonaldBitrump [1f00b52e@31.0.181.46] has quit [Quit: Connection closed]
11:26 <@michaelfolkson> harding: I do. We're still on LOT=true arguments currently
11:26 < luke-jr> harding: first segment is supposed to be convincing people to do LOT=true
11:26 < robert_spigler> nickler: miner signalling has nothing to do with node upgrades? And nodes need to upgrade regardless
11:26 < luke-jr> harding: to do that requires knowing the objections
11:26 < hsjoberg> belcher: Yes, that's why we moved the threshold to 95%.
11:26 -!- GreenmanPGI [greenman16@gateway/vpn/protonvpn/greenman16091559] has joined ##taproot-activation
11:27 < GreenmanPGI> hello
11:27 < belcher> hsjoberg yep and also added the 2 week lock-in period
11:27 < robert_spigler> I don't understand the argument of setting LOT=false, then setting LOT=true.  LOT=true with a long time frame is the same result, with less complexity
11:27 < robert_spigler> And without miners believing they have power that they don't
11:27 < prayank> michaelfolkson: Matt Corallo also had few thoughts about UASF which I don't agree to and even blocked some devs when we tried discussing. Not sure if it's part of this session right now.
11:28 < NoDeal> Is there any concern that (defaulting to) LOT=true now, means that we are disregarding anything we may learn over the next 1 year in the case that miners decide to go against what they've already verbally committed to? Miners changing their mind and failing to activate seems like it could indicate a problem, and mean we overlooked something. And in
11:28 < NoDeal> this case, we've already pre-emtivley made a decision. We seem to lose some optionality and ability to take in new information and make decisions based on reality
11:28 < proofofkeags> michaelfolkson, if I may summarize Corallo's argument, it was that the importance of signaling to the current and potential Bitcoin community that use cases are stable, is more important than activation, and the mechanics of flag day activations (UASF's) are not broadly understood
11:28 < luke-jr> NoDeal: miners have no choice if LOT=true
11:28 <@michaelfolkson> I agree with Matt on rushed, uncoordinated UASFs being risky, they are
11:28 < hsjoberg> robert_spigler: lot=true also makes it easier for the user, not having to change anything about their software.
11:28 <@michaelfolkson> The argument for LOT=true is to avoid a rushed, uncoordinated UASF
11:29 < CubicEarth> hsjoberg: I don't get 95%... why make the cost of blocking so low? That 5% can come from anyone in the world who spends some money to interfere
11:29 < robert_spigler> NoDeal: defaulting to LOT=false means that we are disregarding the lessons learned
11:29 < fjahr> robert_spigler: there may still be bugs or arguments coming up during the LOT=false phase
11:29 < benthecarman> I think starting with lot=true is the best way to not have an uncoordinated UASF
11:29 < rgrant> i view LOT=false (given a long timeframe) this way: it says we actually don't know if all of us want the feature or not.  if the soft fork doesn't go through, then we'd all sit down and think up a new feature, instead of planning a UASF.
11:29 < harding> luke-jr: objections I've raised above are F7 and that I don't find the argument that L=T is safer to be persuasive.  Additionally, a meta-objection is that I think it would take a long time to convince a sufficent number of people to support L=T for it to get merged into Bitcoin Core, which means even more delay for taproot (I'm happy to agree that this argument is perhaps inappropriate for a factual debate).
11:29 < robert_spigler> michaelfolkson: it's not rushed if we set LOT=true 2y
11:29 < hsjoberg> CubicEarth: The reason is what me and belcher talked about. There has been some false signaling in previous soft forks that caused chainsplits
11:29 -!- janoside [44eb2b54@68.235.43.84] has quit [Ping timeout: 240 seconds]
11:29 < proofofkeags> fjahr the bugs will not be discovered before activation, if they can be, they can already be discovered on signet
11:29 < belcher> CubicEarth if 5% was spun up for that purpose that would be more than enough justification for a UASF
11:29 < luke-jr> fjahr: if we are still unsure of Taproot, then we shouldn't deploy *any* activation
11:29 < robert_spigler> fjahr: we shouldn't be discussing activation if code review isn't finished
11:29 < debit> CubicEarth +1
11:30 < pox> @NoDeal what could miners possibly find out during this year before signaling that hasn't already been investigated? And a revert release could always be made available if any issue is found last minute.
11:30 <@michaelfolkson> robert_spigler: You don't understand my point. LOT=true is not rushed UASF. LOT=false and an uncoordinated UASF during LOT=false is rushed
11:30 < hsjoberg> CubicEarth: But I am in camp lot=true, so your argument resonates with me
11:30 < viaj3ro> best argument for LOT=false imho is that 91% of miners signaled support for LOT=false and might activate quickly if chosen. If LOT=true is chosen, they might refuse and we'll have to wait the full year
11:30 < CubicEarth> belcher: how would we know what the purpose was? We'd just see not reaching the 95%
11:30 < harding> robert_spigler: L=T is only the same result as (L=F, gather information, L=T) if nothing changes about our perspective during the "gather information" period.
11:31 < robert_spigler> michaelfolkson: Ah. Agreed
11:31 <@michaelfolkson> 5 minute warning and we'll move onto LOT=false arguments
11:31 < belcher> CubicEarth presumably it would happen at the same time as a social media blitz, but if not 94% miner support is enough to make a UASF pretty safe
11:31 < luke-jr> viaj3ro: that is not based in reality..
11:31 < CubicEarth> belcher: I don't see why even 80% wouldn't make a MASF safe?
11:31 < debit> proofofkeags the execution environment of a small testnet is not a replica of the execution environment of deployed nodes.  aka absence of evidence of bugs on signet is not evidence of absence of bugs on mainnet
11:32 < viaj3ro> it's an assumption, obviously. but still based on public information
11:32 < hsjoberg> viaj3ro: Well so be it, at least we get the Taproot for sure then. And most nodes will probably have upgraded by them which would lead to a safer softfork
11:32 <@michaelfolkson> LOT=true offers clarity to users (and miners) that an additional coordinated or uncoordinated UASF is not needed
11:32 < hsjoberg> then*
11:32 < proofofkeags> debit: that is true, but I'm not sure how you can discover bugs while the lockin period is still happening
11:32 < luke-jr> debit: once it's active on mainnet, this is all moot
11:32 < devrandom> did any miners actually express an opinion about LOT=true?
11:32 < benthecarman> viaj3roL that doesn't really make sense, if they support taproot  & are ready the will signal, I don't think they will not signal because of a planned UASF
11:32 < debit> belcher re: 5% amount of dark pow being spun up, the lower the amount of hashrate, the harder it is to detect if that hashrate is noise or genuine signal
11:32 < luke-jr> during activation, there is ZERO testing on mainnet
11:32 < harding> luke-jr: I don't know why you'd think viaj3ro's comment isn't based in reality.  I don't know what miners will do in that case, and I'm not sure you have a much better perspective than I do.
11:32 <@michaelfolkson> devrandom: Not yet, I've asked
11:32 < luke-jr> devrandom: wangchun_ said he is okay with it
11:33 < hsjoberg> benthecarman: It makes kind of sense, they might get disfranchised.
11:33 < pox> @debit even if the features aren't yet active?
11:33 -!- SHlTBLASTER6900 [463f93aa@rrcs-70-63-147-170.midsouth.biz.rr.com] has joined ##taproot-activation
11:33 < hsjoberg> Which was kind of the case with SegWit
11:33 < luke-jr> harding: 2017 was much more contentious and miners still complied
11:33 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Ping timeout: 256 seconds]
11:33 < proofofkeags> wangchun_ preferred false, but for optics reasons iirc
11:33 < CubicEarth> hsjoberg: I don't think I have strong position on either LOT true or false... I see this entire discussion as to far away from the fundamentals of how the network works. I think we have gone in circles three times to arrive at the current discussion point
11:33 < viaj3ro> benthecarman: all major pools are chinese. I think its naive to believe they will just agree to go with an activation method they never supported
11:34 <@michaelfolkson> Please stay until the end so we can gage consensus on both LOT options
11:34 < harding> luke-jr: I read viaj3ro point as miners making us wait until nearly the last minute to get taproot, which only requires ~10% of hashrate to be bitter.  That seems plausible to me.
11:34 < prayank> devrandom: Good point. Curious why mining pools don't participate in these discussions?
11:34 < luke-jr> harding: then they just prove it was necessary; doesn't make sense
11:34 <@michaelfolkson> prayank: They did in the previous meeting. Not today though it appears
11:34 < benthecarman> viaj3ro the mining pools dont just get to decide which activation method we use
11:34 < prayank> michaelfolkson: Cool
11:34 -!- Alan58 [54e364cd@adsl-84-227-100-205.adslplus.ch] has quit [Quit: Connection closed]
11:34 < harding> luke-jr: people being bitter normally doesn't make logical sense.
11:35 < harding> (In the short run, at least.)
11:35 < viaj3ro> benthecarmanthey are part of bitvcoin and have as much say as anyone else
11:35 <@michaelfolkson> Ok last thoughts on lot=true arguments?
11:35 < CubicEarth> Isn't LOT=True a gamble that miners won't call a bluff?
11:35 < CubicEarth> Can we all agree on that?
11:35 < luke-jr> harding: well, then it is more important we don't leave room for shenanigans :P
11:35 < whuha> Miners are selfish by definition
11:35 < luke-jr> CubicEarth: no
11:35 < benthecarman> viaj3ro they are equal to us, not more, not less
11:35 <@michaelfolkson> I think we could have presented them better tbh. The reading of the mailing list post and Google Doc hasn't worked great
11:35 < darosior> luke-jr: i believe opens the door for more sheningans, it's way more controversial
11:36 < darosior> LOT=true*
11:36 <@michaelfolkson> No real reference to T1-T6
11:36 < harding> luke-jr: I think viaj3ro's point is that there's still room for some amount of shenanigans even if we still eventually get taproot.
11:36 < viaj3ro> benthecarman: exactly. so they have the same say as us
11:36 < benthecarman> viaj3ro but youre saying we should do what they say
11:36 < harding> michaelfolkson: I think we probably should've published ~10 word summaries of each point for reference.
11:36 < fjahr> whuha: and a strong network helps them as well, so it's incentive compatible
11:36 < prayank> Do we have any arguments from miners in public yet against Taproot? Like in segwit few had issues with unfairly cheap etc.
11:36 <@michaelfolkson> LOT = TRUE ARGUMENTS OVER. WE ARE MOVING ONTO LOT = FALSE ARGUMENTS
11:36 < viaj3ro> harding: this and that there is currently no reason to believe they will not activate quickly if lot=false is chosen+
11:36 < hsjoberg> CubicEarth: lot=true is just another way to activate a softfork. SegWit showed us that it can ber gamed yes
11:36 <@michaelfolkson> Sorry prayank not on topic
11:37 < darosior> I believe setting LOT=true is an unnecessary demonstration of strength that may do more harm in setting a precedent. Starting with LOT=false *does not* prevent an UASF from happening and will help us make more informed decisions.
11:37 < proofofkeags> The strongest argument for L=T is that this is a non-invasive fork, and L=T has the cleanest chance of working properly
11:37 <@michaelfolkson> LOT = FALSE ARGUMENTS. F1 to F7
11:37 < rgrant> There are three different things that we expect miner signals to show us: node upgrades, political willingness, and approval of code quality.  We can remove the noise of political will if we are clear about UASF.
11:37 < debit> prayank the only real relevance pools have is reporting what their switching costs are for upgrading (which may be close to infinite e.g. the sell their mining equipment to another producer who wants to create blocks for the new consensus rule set)
11:37 <@michaelfolkson>  LOT = FALSE ARGUMENTS. F1 to F7
11:37 < proofofkeags> darosior, I would support an L=F data gathering period if we shortened the horizon to 6mo
11:37 <@michaelfolkson> harding: Happy to discuss at least F7?
11:37 < hsjoberg> darosior: Fool me once shame on you, fool me twice...
11:37 < debit> miners need a way to price what the market is for taproot-activated blocks, and will allocate hashrate accordingly
11:37 -!- samsepiol [8ff42e57@143.244.46.87] has joined ##taproot-activation
11:37 < achow101> darosior: agreed
11:37 <@michaelfolkson>  LOT = FALSE ARGUMENTS. F1 to F7
11:38 -!- KatieTheRussian [89672c46@static-137-103-44-70.fl.cpe.atlanticbb.net] has quit [Quit: Connection closed]
11:38 < benthecarman> debit they dont need new hardware, it is still just sha256
11:38 < harding> michaelfolkson: discuss, sure.  Like luke-jr, I don't think I have anything to say as preface.
11:38 < viaj3ro> benthecarman: no. I think we should go the path of least resistance
11:38 < darosior> proofofkeags: why ? We can still re-evaluate in 6 months and do a BIP8(6mo, true) and people running LOT=false will activate too without upgrading their node
11:38 <@michaelfolkson> F1 - F6 here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
11:38 < luke-jr> viaj3ro: that's LOT=true
11:38 < virtu> LOT=false is the only way to have an orderly upgrade
11:38 < darosior> proofofkeags: should it at all be required
11:38 < CubicEarth> darosior: +1
11:38 <@michaelfolkson> F7 here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
11:38 < virtu> because it relies of hashpower, which cannot be distorted
11:38 < proofofkeags> darosior that creates a lot of chaos with multiple fork heights in flight at the same time
11:38 -!- saturnine [c08f94bb@192-143-148-187.ip.airmobile.co.za] has joined ##taproot-activation
11:38 < hsjoberg> darosior: Make informed decisions afterwards is kind of the problem. It requires yet another software to be released and deployed. Last time Core wouldn't even release a UASF so we had to go with a fork...
11:38 < robert_spigler> harding: what data could be gathered during the LOT=false period that would then have you support LOT=true later
11:38 < debit> benthecarman indeed, but a miner way sell all their equipment to another miner who wants to produce blocks on the new rules
11:38 < robert_spigler> And would make it different than just setting LOT=true from the beginning
11:39 < virtu> measuring support for and against UASF is not possible
11:39 < viaj3ro> luke-jr technically maybe. but bitcoin has a social side to it as well.
11:39 < luke-jr> viaj3ro: socially too
11:39 <@michaelfolkson> Is anyone reading the arguments?
11:39 <@michaelfolkson> Maybe this is a waste of time
11:39 -!- Me [5152c905@d5152c905.static.telenet.be] has joined ##taproot-activation
11:39 < satosaurian> yes i am
11:39 <@michaelfolkson> Ok thanks
11:39 < darosior> proofofkeags: it would not, choose the same height
11:39 < achow101> it's a waste of time
11:39 < benthecarman> debit they can still produce blocks under the old rules, just dont include taproot txs
11:39 < robert_spigler> michaelfolkson: yes!
11:39 < harding> robert_spigler: basically (users_run_0.22.1 && no_problems && miners_don't_activate)
11:39 < solairis> yes
11:39 <@michaelfolkson> harding has a very good argument on F7
11:39 -!- Me is now known as Guest9641
11:39 < nickler> robert_spigler: How do you know for sure that 1.5 years before activation that 95%+ will run the new version?
11:39 < darosior> hsjoberg: it does not need everyone to upgrade if the UASF is compatible
11:39 < debit> benthecarman I don't think we disagree about anything
11:40 < hsjoberg> darosior: All forks always require all nodes to update to star safe.
11:40 < waxwing> F4 is a pretty good argument, in case (as i believe) the difference between false/true is pretty minor in this case.
11:40 < hsjoberg> stay*
11:40 <@michaelfolkson> Basically a precedent argument. That devs should not be pulling the final switch on this soft fork or future soft forks unless absolutely necessary
11:40 < nickler> *95% of economic nodes I mean
11:40 < proofofkeags> darosior, it vastly limits the parameters if you have multiple potential (conflicting) soft forks in flight at the same time
11:40 < darosior> hsjoberg: well, not in the event i detailed above.
11:40 < luke-jr> michaelfolkson: devs never are
11:40 < hsjoberg> Lot=true with deadline 1y would make sure most nodes already have the software installed when the fork activates
11:41 < proofofkeags> from a technical standpoint it seems far more dangerous than to have 2 non-overlapping timeout periods
11:41 <@michaelfolkson> luke-jr: When they merge a PR with lot set to false and release it they effectively are
11:41 < luke-jr> hsjoberg: it should be nearly all nodes, not just most
11:41 < hsjoberg> Yes sure
11:41 < luke-jr> hsjoberg: most should be the goal for startheight ;)
11:41 < harding> luke-jr: the email does mention that, but it points out that it's clearer to people who don't understand free software to see devs not "pulling the final switch".
11:41 < darosior> hsjoberg: if we go with BIP8(1y, false) and say after 6mo miners are blatantly trying to prevent activation we can do BIP8(6mo, true) and activate for both
11:41 < hsjoberg> Yeah then we are back in 2017 segwit scenario, which wasn't pretty
11:41 <@michaelfolkson> I don't feel like anyone wants to discuss F1 to F7 arguments which is unfortunate. Shall we move on?
11:42 < luke-jr> michaelfolkson: they effectively are when devs release something contrary to community fiat; whether that be LOT=false or LOT=true
11:42 <@michaelfolkson> To the expressing views and consensus part?
11:42 < proofofkeags> darosior, theres no reason to keep it at 1y at that point, it introduces unnecessary risk for no marginal benefit over an initial timeout of 6mo
11:42 < achow101> hsjoberg: the 2017 segwit scenario wasn't pretty only because we weren't prepared for it
11:42 < hsjoberg> Safer would be to just do lot=true and then most nodes would already have the correct software for the fork.
11:42 <@michaelfolkson> achow101: We aren't prepared for it this time either
11:42 < achow101> we now know what could happen and are preparing for that situation
11:42 -!- saturnine [c08f94bb@192-143-148-187.ip.airmobile.co.za] has quit [Client Quit]
11:42 < eeb77f71f26eee> To me the arguments against sound a bit weak. If we have consensus shouldn't we just go ahead as soon as the miners are ready? And if we are not convinced we have consensus then it shouldn't be merged at all?
11:42 < virtu> hsjoberg: I strongly doubt the majority of nodes will have upgraded after one year
11:42 < luke-jr> michaelfolkson: I don't think this debate style is productive, so +1 to move on
11:42 < hsjoberg> achow101: No that's not the only reason. It was also ugly because of the need to use shaolinfys fork of Bitcoin Core
11:42 < fjahr> michaelfolkson: of course, the possibility is already being discussed now
11:43 < benthecarman> lot=true is the prep
11:43 < achow101> michaelfolkson: having a LOT=true followup waiting in the wings is preparing for it
11:43 < hsjoberg> Because Core wouldn't merge UASF.
11:43 <@michaelfolkson> achow101: When is it released? Who releases it?
11:43 < hsjoberg> virtu: Not majority perhaps, but many more than should we relesae another software mid-way.
11:43 < achow101> michaelfolkson: released by core
11:43 <@michaelfolkson> achow101: Are there multiple uncoordinated UASF attempts?
11:43 < harding> hsjoberg: that's only safer if that's what most economic nodes actually run.  We can't be sure that will happen, we can only guess in advance.  Calling something based on guesses "safer" seems questionable to me.
11:43 < achow101> We are currently discussing the plan.. how is that not preparation?
11:43 <@michaelfolkson> achow101: We have no guarantee Core will release it
11:44 < virtu> hsjoberg: I think it's just messy to use nodes to measure consensus
11:44 -!- Guest9641 [5152c905@d5152c905.static.telenet.be] has quit [Client Quit]
11:44 < hsjoberg> virtu: It is messier, that's why the deadline should be long into the future.
11:44 < luke-jr> I would like to lock down startheight, timeoutheight, and threshold..
11:44 < debit> harding +1
11:44 <@michaelfolkson> achow101: We kick can down the road and try to work out who will release it and when when we don't know what uncoordinated UASFs there will be
11:44 < fjahr> michaelfolkson: there is no guarantee for anything at the moment, but there is time to prepare stuff, several months at least
11:44 < proofofkeags> virtu, the right way to measure it is to see how much fee burn there is in support or refute. But we don't have a mechanism for that right now, unfortunately
11:44 < hsjoberg> harding: Good point
11:45 <@michaelfolkson> fjahr: Try controlling various UASF movements
11:45 <@michaelfolkson> fjahr: Good luck
11:45 < belcher> how about using businesses to measure? back in 2017 we got several big bitcoin businesses like bitrefill, bittylicious and vaultoro to say they're running the bip148 UASF node
11:45 < virtu> proofofkeags: interesting thought
11:45 <@michaelfolkson> OK LET"S MOVE ON
11:45 < harding> belcher: miners are businesses.  :-)
11:45 < virtu> proofofkeags: but not ideal either, that way money will dictate everything
11:45 -!- erroneousNickNam [bb3fa187@187.63.161.135] has joined ##taproot-activation
11:45 < luke-jr> proofofkeags: that's inverted IMO
11:45 < hsjoberg> F4 is indeed the best argument for lot=false
11:45 < hsjoberg> IMO
11:45 < belcher> harding they dont accept bitcoin in exchange for something real, thats what i mean
11:45 <@michaelfolkson> THIS SECTION. WHICH IS YOUR PREFERENCE? ARE YOU HAPPY WITH SECOND PREFERENCE?
11:45 < debit> michaelfolkson what are we moving on to
11:46 < robert_spigler> harding: if we're not sure that there aren't going to be any problems yet, we shouldn't be discussing activation
11:46 < luke-jr> michaelfolkson: wut
11:46 < belcher> michaelfolkson i prefer LOT=false but i'm happy with LOT=true
11:46 < fjahr> michaelfolkson: what is the difference between that and people threatening to fork to get a certain feature
11:46 < benthecarman> pref: lot=true, happy with lot=false
11:46 < proofofkeags> luke-jr we should discuss in another forum
11:46 <@michaelfolkson> I prefer LOT=true but I'm happy with LOT=false
11:46 < waxwing> lot=false,happy with lot=true
11:46 < robert_spigler> sorry, reading old messages
11:46 < hsjoberg> I am fine with lot=false IF it is easy to change to lot=true. Not requiring a shaolinfry-like fork.
11:46 < fjahr> lot=false
11:46 < devrandom> prefer LOT=true, OK with LOT=false if threshold <= 90%
11:46 < darosior> My preference is starting LOT=false *because* i oppose LOT=true (but only as starting method)
11:46 < andrewtoth> prefer LOT=false, but whatever will get activation code merged and released
11:46 < luke-jr> anything other than LOT=true would be a mistake IMO, but probably not fatal; I'm not up for repeating 2017 though, so if we do LOT=false and it turns into a mess, LOT=false people can fix it <.<
11:47 < emzy> michaelfolkson: I prefer LOT=false but i'm OK with LOT=true
11:47 < viaj3ro> prefer LOT=true, OK with LOT=false
11:47 < proofofkeags> michaelfolkson +1
11:47 <@michaelfolkson> Please be clear if you are happy with second preference
11:47 < achow101> prefer with lot=false followed by lot=true, no second preference
11:47 < Murch> eeb77f71f26eee: The point is that there is no way to measure support of all network participants.
11:47 < virtu> prefer lot=false
11:47 < luke-jr> to be clear: I am not happy with LOT=false
11:47 < proofofkeags> I prefer LOT=TRUE, but can live with LOT=FALSE
11:47 < Murch> There are very few things that are objectively measurable
11:47 < nickler> lot = false, then lot = true
11:47 <@michaelfolkson> achow101: You are definitely not happy with LOT=true at the outset?
11:47 -!- erroneousNickNam is now known as newNickName
11:47 < satosaurian> i prefer lot=true because I cant seem to find the arguments for lot=false convincing and I think lot=false would be a mistake because it could turn into a mess and would give miners power they don't have
11:47 < eeb77f71f26eee> prefer lot=true
11:47 < hsjoberg> michaelfolkson: Wow is that a change of opinion, I thought you preferred lot=false
11:47 < achow101> michaelfolkson: I have now been convinced that LOT=true is bad at the outset
11:47 < Murch> We can talk all we want on IRC, Twitter and Reddit, but that doesn't necessarily give us an accurate picture of the support landscape
11:48 <@michaelfolkson> Thanks achow101, that's useful
11:48 < gg34> prefer lot=true, if you make lot=false please make it as easy as possible for node runners like me to express our sovereignty.
11:48 < robert_spigler> I prefer LOT=true but would compromise with Modern Soft Fork
11:48 < hsjoberg> I prefer LOT=true, I am okay with LOT=false if it easy to for the user to change to LOT=true
11:48 < luke-jr> Murch: all we can do here is make a proposal for the rest of the community to consider
11:48 < gr-g> prefer LOT=false but OK with LOT=true
11:48 < harding> I prefer LOT=false to start with.  I won't quit Bitcoin if Bitcoin Core starts with LOT=true, but I will need to take time to understand why they made a decision I wouldn't expect
11:48 < jonatack> prefer lot = false, then lot = true
11:48 < pox> slight preference for LOT=true
11:48 < solairis> seems like LOT true is getting a majority support
11:48 < Billy> Prefer LOT=true, with no strong objection to LOT=false
11:48 <@michaelfolkson> luke-jr is strongly against false. achow101 is strongly against true. Any other strong opposition?
11:48 < proofofkeags> FWIW, a shortened timeout horizon would make me happier with LOT=FALSE
11:49 < hsjoberg> (Yep said that last time as well.)
11:49 < evankaloudis> I prefer lot = false. LOT=true is ok thought because the vast majority of miners have already indicated support
11:49 < virtu> strongly against starting with true
11:49 < luke-jr> would a longer timeoutheight make anyone happier with LOT=true?
11:49 < criley> I too prefer LOT=true but I'm fine with LOT=false. I compile each time anyway, so it is easy to flip.  I think everyone wants it activated as soon as possible, it is just a question of the best way.
11:49 < proofofkeags> I STRONGLY oppose multiple in flight fork attempts at the same time
11:49 < CubicEarth> I would like to see 90% or 85% threshold
11:49 < Murch> luke-jr: Right, so if it's a proposal, why should we force a date? Isn't it better to propose something that will benignly dissipate without anyone needing to upgrade if activation is not achieved?
11:49 -!- xxxxbtcking [5565c5ac@85.101.197.172] has joined ##taproot-activation
11:49 < harding> luke-jr: not me.
11:49 -!- Yari7 [b99affbc@185.154.255.188] has quit [Quit: Connection closed]
11:49 <@michaelfolkson> harding: You would be happy(ish) with LOT=true?
11:49 < fjahr> michaelfolkson: pretty strong for starting with lot=false
11:49 < prayank> LOT = true only based on what I have read about everything involved
11:49 < evankaloudis> proofofkeags: we need to strongly define the time frames. they shouldn't overlap
11:49 < achow101> luke-jr: no
11:49 < darosior> michaelfolkson: i'm strongly against starting with true
11:49 < harding> michaelfolkson: definitely not happy, just not unhappy enough to quit Bitcoin (which is everyone's ultimate recourse to decisions they don't like).
11:49 <@michaelfolkson> Greg Maxwell said he would only support LOT=true if clear consensus
11:50 < hsjoberg> Makes sense
11:50 < viaj3ro> an easy configurable switch would make me happier with LOT=false
11:50 < hsjoberg> viaj3ro yep agree
11:50 <@michaelfolkson> Matt is (presumably) strongly against LOT=true
11:50 < luke-jr> Murch: the community needs to accept or reject the proposal, but if accepted, it should not fail
11:50 < debit> I prefer lot=false then true with short time periods
11:50 < proofofkeags> evankaloudis: 100%. If we do a sequenced L=F >> L=T, they should be non-overlapping, and I would add that we should shorten the time horizon for the L=F attempt so as to increase the rate at which said data gathering can occur
11:50 <@michaelfolkson> Strong opposition I think is key at this point
11:50 < Murch> I'm also unconvinced that LOT=True is a good idea, in case it's not clear.
11:50 < hsjoberg> lot=false is fine if we can prevent 2017-scenarion. If it isn't easily configurable we have learnt nothing since 2017.
11:51 < Murch> luke-jr: Right, but you can only measure actual sentiment once activation code is deployed
11:51 < luke-jr> 10 minutes left (unless we go longer than an hour); can we move on to the more critical params? :P
11:51 < belcher> in 2017 we got many bitcoin merchants (i.e. those who accept bitcoin as payment for something real) to say they support the UASF, since LOT=true is a UASF would it be useful to ask some of those businesses again? would that make people who disagree with LOT=true change their mind?
11:51 < luke-jr> Murch: I don't agree.
11:51 <@michaelfolkson> We have presumably Matt, darosior, achow101 (and presumably Greg) strongly against lot=true
11:51 < harding> belcher: it would not change my mind on the parameters for initial deployment.
11:51 < luke-jr> michaelfolkson: Matt isn't here.
11:52 <@michaelfolkson> luke-jr: We can ask him. I am pretty sure what he would say
11:52 < ghost43> I prefer lot=false, with modern soft fork activation as follow-up if it fails to activate. I think that's a conservative option without any drawbacks except possible delay
11:52 < hsjoberg> michaelfolkson: Well Greg isn't strongly against as you said. Only if there isn's consensus
11:52 < harding> belcher: argument F7 is important to me, and merchant support for UASF wouldn't affect that.
11:52 < proofofkeags> luke-jr Matt laid out a pretty comprehensive case against it on TFTC
11:52 < luke-jr> michaelfolkson: if he won't participate in the group, IMO he shouldn't be considered for the group's recommendation, especially while actively refusing to discuss
11:52 <@michaelfolkson> hsjoberg: Is there clear consensus on lot=true? I don't think so
11:52 < belcher> harding how so? anyone saying "core devs decided" would be easily shown wrong because of the records of merchant support
11:52 < robert_spigler> agreed
11:53 < hsjoberg> michaelfolkson: I don't know
11:53 < debit> belcher if the market better understood that bitcoin core is just a code-endorsement group and doesn't control what node software that people who pay for block production, that would change my mind
11:53 <@michaelfolkson> hsjoberg: If there isn't clear consensus on lot=true Greg is against
11:53 < achow101> belcher: debuning bullshit is an order of magnititude harder than it is to spread it
11:53 < fjahr> michaelfolkson: agree with luke, even if the opinion was made public I think the discussion here should be contained
11:53 < robert_spigler> There is not clear consensus on LOT=true
11:53 < hsjoberg> Well you said strongly against. So to be pendantic
11:53 <@michaelfolkson> No robert_spigler
11:53 < belcher> achow101 fair point
11:53 < fjahr> *matt's opinion
11:53 < hsjoberg> sorry*
11:53 < virtu> I think we're done with the 'what's everyone's preference' part
11:53 < waxwing> i think lot=false will lead to faster activation too
11:54 <@michaelfolkson> OK NEW SECTION OTHER PARAMETERS
11:54 <@michaelfolkson> Go for it luke-jr
11:54 < viaj3ro> yeah, I see no clear consensus for LOT=true
11:54 < hsjoberg> Here's Greg's UASF post btw. 2017 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html
11:54 < luke-jr> startheight=691488 puts MASF beginning around July 9th
11:54 < rgrant> An argument against harding's F7 is that we should have been making patchsets easier to apply by users over the last ten years.  Bitcoin Knots is the only major software that does so well.  This feature is not the time to force these issues on users.
11:54 -!- brg444 [bdb179f7@189.177.121.247] has joined ##taproot-activation
11:54 < harding> belcher: we also have records of miner support, so L=T isn't needed, but requiring it may demonstrate we didn't trust them.  If we didn't trust one type of business (miners); what argument do we have for trusting a different type of business (merchants)?
11:54 < Murch> I'm also for LOT=F <consideration> potential LOT=T
11:54 < luke-jr> this means the earliest activation would be August 1st, which is approximately when Bitcoin Core 0.20 ends maintenance
11:54 < viaj3ro> what about the activation percentage threshold?
11:54 <@michaelfolkson> NEW SECTION OTHER PARAMETERS
11:55 <@michaelfolkson> PLEASE KEEP TO SECTIONS
11:55 < robert_spigler> luke-jr ACK
11:55 < luke-jr> that helps avoid needing to backport Taproot to 0.20
11:55 < benthecarman> I'd hope we could get the start time sooner
11:55 < achow101> luke-jr: target 0.21.1 for April then?
11:55 < luke-jr> however, the primary factor we should look at is when we expect the economic majority to be upgraded
11:55 < luke-jr> I'm not sure if July is too soon for that?
11:55 < belcher> how about a round number for the block height? 692000 say
11:55 < ghost43> I think start time should be at least 4 retarget periods after software release, am fine with more
11:56 < robert_spigler> luke-jr mid-march is expected release?
11:56 < luke-jr> belcher: it needs to be a multiple of 2016
11:56 < benthecarman> belcher it needs to be a difficulty adjustment block
11:56 < proofofkeags> round numbers are easier to remember and communicate
11:56 < luke-jr> robert_spigler: it's released whenever
11:56 < Murch> Seems actually fairly long to allow start of signaling
11:56 < luke-jr> for reference: as of today, only 18% of nodes have upgraded to Core 0.21
11:56 < robert_spigler> luke-jr I was thinking 6 months after release, how else do we decide?
11:56 < pox> q: do exchanges run core or other implementations that would require more time to upgrade?
11:56 < belcher> i noticed the last 4 numbers of startheight=691488 are 14/88 which has political meaning that we'd best avoid
11:56 < luke-jr> 34 days after release
11:56 -!- TristanLamonica [4c474157@bras-base-otwaon238vw-grc-02-76-71-65-87.dsl.bell.ca] has joined ##taproot-activation
11:56 < nickler> do we have good data on the distribution of bitcoin versions right now?
11:56 < debit> 692e3 % 2016 = 512
11:57 < luke-jr> belcher: ⁈
11:57 < prayank> michaelfolkson: It's hard to know clear consensus here unless we ask for Yes or No. Example: Prefer LOT= True, Yes or No
11:57 < benthecarman> In the past wasn't normally 1-2 months after release when activation would begin?
11:57 < harding> I don't care about the absolute values, only the relative ones, e.g. 2-3 months adoption window, expires 1 year after that.
11:57 < debit> luke-jr yes it has a racist meaning
11:57 < proofofkeags> belcher: wat
11:57 < virtu> nickler: http://btc.virtu.llc
11:57 < belcher> luke-jr https://en.wikipedia.org/wiki/Fourteen_Words
11:57 < luke-jr> nickler: I have graphs, but I can't tell economic use
11:57 <@michaelfolkson> prayank: We've moved on, sorry
11:57 < luke-jr> https://luke.dashjr.org/programs/bitcoin/files/charts/historical-pretaproot.html shows adoption of the newest releases
11:57 < achow101> nickler: the survey I'm running could provide some useful data there
11:57 < luke-jr> in days since release
11:58 < pox> belcher WTF??!
11:58 < debit> does choosing a block height that takes into account difficulty adjustment height have any value?
11:58 < proofofkeags> belcher: thanks for sharing...who knew?
11:58 < benthecarman> debit it needs to for bip
11:58 < luke-jr> debit: it's required by BIP 8
11:59 < luke-jr> https://luke.dashjr.org/programs/bitcoin/files/charts/branches.html may also be helpful
11:59 < xxxxbtcking> Hello everyone, I just want to add one perspective to bitcoins upgrade debates? While long term the stability of bitcoin node software is the backbone for sustained trust in the ecosystem. Why is an innovation like taproot with schnoor and MAST when it’s so amazing benefits for the users being debated ? The point is the ling term power of who can
11:59 < xxxxbtcking> enforce changes into bitcoin is at question here, I beleive that we are at a historic cross roads and how this is handled will set the tone for years to come and how btc will face the future.
11:59 < devrandom> belcher is correct, please avoid 14/88
11:59 < virtu> luke-jr: your proposal sounds good. one q, though: what was the delta between release and earliest activation in the past?
11:59 < hsjoberg> belcher: Interesting coincidence. I don't we should care about politics when deciding parameters though
11:59 < robert_spigler> How many months do people think is enough for economic majority to upgrade?
11:59 < robert_spigler> I'd say 6 at least
11:59 < benthecarman> imo all these params should fall back to historical values, 1-2 months after release & 1yr timeout
11:59 <@michaelfolkson> xxxxbtcking: Sorry, off topic
12:00 < luke-jr> adding 2016 more blocks is no big deal imo
12:00 < CubicEarth> robert_spigler: Why is that needed?
12:00 < virtu> if 1-2months after release is the historical average, then 6mo should be fine
12:00 < devrandom> luke-jr: thank you
12:00 < belcher> yeah or subtracting
12:00 < virtu> benthecarman: take note of the backporting issue
12:00 < luke-jr> I don't like subtracting - it already seems potentially too soon
12:00 < debit> 2 weeks?
12:00 < benthecarman> virtu was segwit backported?
12:01 < virtu> benthecarman: https://docs.google.com/document/d/1Ewnxxxc51_JWJLZQfqc5W55Pvkgcf9TEh6Ks3wiHbRk/edit rationale #1
12:01 -!- Jetlag [5ed1470e@94-209-71-14.cable.dynamic.v4.ziggo.nl] has joined ##taproot-activation
12:01 < virtu> for startheight
12:01 < achow101> release + 2 months, lot=false timeout of 9 months, 3 month eval period, lot=true timeout of 6 months.
12:01 < proofofkeags> achow101, we really shouldn't have two attempts in flight at the same time, should we?
12:01 -!- mpenga [c5fae077@197.250.224.119] has joined ##taproot-activation
12:01 < viaj3ro> I have to go. I don't have an opinion on any of the other parameters besides activation threshold. I'm fine with 85% or 90% no strong preference.
12:01 < achow101> proofofkeags: they're not at the same time. that statement is in order
12:01 < hsjoberg> achow101: Are you suggesting two different deployments?
12:02 < luke-jr> achow101: very much opposed to multiple non-overlapping deployments
12:02 < harding> achow101: that seems to remove the benefit of BIP8.
12:02 < CubicEarth> viaj3ro: +1
12:02 -!- bjarnem [~bjarne@58.pool85-57-231.dynamic.orange.es] has quit [Quit: Leaving]
12:02 < hsjoberg> I also strongly oppose multiple deployments
12:02 < proofofkeags> achow101, sorry the numbers seemed to line up so perfectly
12:02 <@michaelfolkson> And how confident are you that Core will agree to that achow101?
12:02 < achow101> michaelfolkson: how confident are you that core will agree to whatever is decided here?
12:02 < belcher> the alternative would be just abandoning taproot? that seems even less likely
12:03 < luke-jr> any objections to proposing heights 693504-745920 ?
12:03 < harding> achow101: which is that early adopters with L=F don't need to re-upgrade if other people are successful at using L=T to activate.
12:03 < debit> I'm unsure of the value in speculating about endorsement
12:03 < benthecarman> belcher i think the alternative would be like a showlinfry client
12:03 <@michaelfolkson> I think Core would implement lot=false with clear consensus. Not sure about lot=true
12:03 < hsjoberg> luke-jr: Yes why was the start increased?
12:03 < achow101> harding: my proposal is the modern soft fork activation one with a shorter timeframe
12:03 -!- kiwi_73 [32f36641@gateway/web/cgi-irc/kiwiirc.com/ip.50.243.102.65] has joined ##taproot-activation
12:03 < luke-jr> hsjoberg: politics
12:04 < virtu> is it old+=2016?
12:04 < luke-jr> yes
12:04 <@michaelfolkson> SegWit precedent for Core is lot=false
12:04 < virtu> then I'm fine with it
12:04 < achow101> michaelfolkson: then the lot=true discussion here is pointless
12:04 -!- Yiggs30 [418d6092@65.141.96.146] has quit [Quit: Connection closed]
12:04 < achow101> if you think core isn't going to merge it
12:04  * luke-jr ignores LOT talk at this point
12:04 < hsjoberg> luke-jr: I don't think that should play any role in parameters whatsoever.
12:04 < harding> achow101: yeah, I recognize that.  I believe the discussion from two weeks ago found strong support for using BIP8 qua BIP8.
12:04 <@michaelfolkson> achow101: I don't know. All we can do is propose
12:04 < belcher> those heights seem fine to me, some time in July seems ok
12:04 -!- bullbitcoin [c9cb06b8@201.203.6.184] has joined ##taproot-activation
12:04 < virtu> luke-jr: given there's no way to measure the majority of "economic nodes", ~6mo should be more than enough time
12:04 -!- bullbitcoin [c9cb06b8@201.203.6.184] has quit [Client Quit]
12:04 < luke-jr> hsjoberg: can you accept it just to get consensus? :P
12:05 < ghost43> luke-jr: I think only relative heights can be debated meaningfully; but assuming there is a software release before say end of April, those dates look perfectly reasonable to me
12:05 -!- trtvitor [415d6c93@bras-base-hmtnon1497w-grc-36-65-93-108-147.dsl.bell.ca] has joined ##taproot-activation
12:05 <@michaelfolkson> achow101: If I knew Core wouldn't merge lot=true and release it, sure I wouldn't bother
12:05 < hsjoberg> Aargh...
12:05 < luke-jr> virtu: so you want later?
12:05 < waxwing> michaelfolkson, i like this point, but are we in danger of flipping topics again :)
12:05 < hsjoberg> Okay there's better fights to take I guess.
12:05 <@michaelfolkson> You're right. Topics are overlapping :)
12:05 < virtu> luke-jr: no, I'm good with those numbers
12:05 < waxwing> i'm ok with the height suggestion for what (very little) it's worth :)
12:05 < luke-jr> virtu: ~Oct 31 ? :/
12:05 < proofofkeags> numbers are fine
12:05 -!- const_cast [c196d657@c193-150-214-87.bredband.comhem.se] has joined ##taproot-activation
12:05 < debit> 6*2*2016 = 24 192
12:06 <@michaelfolkson> So where are we with parameters. I think 90 percent vs 95 percent threshold needs discussion
12:06 < luke-jr> virtu: oh ok
12:06 < virtu> luke-jr: no, anything that avoids the backporting issue, I guess
12:06 < hsjoberg> What would 693504 put the start date to?
12:06 < benthecarman> There is no talk of threshold, I see luke-jr recommends deviating from the normal 95% and going to 90%, are others in favor of this?
12:06 < proofofkeags> 90, 95 makes it too cheap to block IMO
12:06 < luke-jr> so once again: any remaining objections to proposing heights 693504-745920 ?
12:06 < debit> 12*2*2016 = 48 384
12:06 < robert_spigler> I'm good with 90
12:06 < waxwing> 90 is my preference but i'm fine with 95 because we had it before.
12:06 < luke-jr> that's July 23 + 1 year
12:06 < belcher> hsjoberg approximately july 2021
12:06 < CubicEarth> proofofkeags: Yes
12:06 < harding> I'm fine with 90%.
12:06 < xxxxbtcking> Lot = true means that miners have to upgrade and if they don’t they can stall the upgrade ? Sorry if it’s a simple question
12:06 <@michaelfolkson> nickler quick & dirty simulation showing that the probability of unupdated nodes to be on a >=2 block invalid chain is increased by about 4x. It assumes the worst case that lagging miners don't update after lock-in & accept non-standard transactions. https://github.com/jonasnick/bip8-tester/blob/master/threshold.py
12:06 < hsjoberg> What was the threshold on the fork that caused chainsplit? 80%?
12:06 < CubicEarth> What is the risk with going with say 80% or 85?
12:07 < satosaurian> fine with proposed heights
12:07 < virtu> I see no reason to deviate from 95%. I get the argument that 5% can block, so what? in case of 90%, 10% can block
12:07 < fjahr> Ok with 90%
12:07 < hsjoberg> CubicEarth: We've been over this
12:07 < debit> michaelfolkson I agree the 90% or 95% threshold needs discussion as well
12:07 < luke-jr> I am okay with 85-95%, but 90% seems to be the lowest with consensus IMO
12:07 <@michaelfolkson> CubicEarth: https://bitcoin.stackexchange.com/questions/102684/what-is-the-point-of-miner-signaling-in-a-soft-fork-activation-mechanism-what-s/
12:07 < hsjoberg> belcher: Thanks
12:07 < devrandom> I strongly prefer 90%
12:07 < CubicEarth> virtu: 10% block is 2x more expensive than a 5%
12:07 < debit> luke-jr I agree
12:07 < darosior> light ack 90% (did not research this topic much)
12:07 -!- Lintfree [b2d7c479@host-178.215.196.121-internet.zabrze.debacom.pl] has quit [Quit: Connection closed]
12:07 < hsjoberg> I think 90% should be fine. Below that doesn't make any sense to me
12:07 < virtu> CubicEarth: just seems arbitrary
12:07 < proofofkeags> anyone thing that 90 is BAD?
12:07 < whuha> ok 90%
12:07 < harding> hsjoberg: BIP66's full activation occurred at 95% using ISM, which has much higher variance than BIP8/9 measuring due to sampling frequency.
12:07 < ghost43> ok with 90%; a decrease from 95 that makes "veto" harder but still sounds safe. but ok with 95% too due to precedence
12:08 < debit> IMO 95% is too high to allow adversarial miner to attempt to nerf or block uprades
12:08 <@michaelfolkson> proofofkeags: I think nickler would prefer 95 based on his analysis
12:08 < achow101> ok with 90
12:08 < hsjoberg> 90% also puts us on path to MASF, if we can go with the miner tweets.
12:08 < virtu> I prefer to stick with 95% but I'm ok with 90%, too
12:08 < belcher> also bip66 didn't have a lock-in period, the new rules just took effect straight away after the ISM threshold was reached
12:08 < achow101> let's split the difference and do 92.5
12:08 < emzy> I like 90% but 95% is OK.
12:08 < robert_spigler> damn, that's good data michaelfolkson nickler
12:08 < robert_spigler> I now prefer 95% but am good with 90
12:08 -!- Bitbreather [5e3d097a@122.9.61.94.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]
12:08 < nickler> I don't think 90 is bad, but 95% is clearly quite a bit safer
12:08 < benthecarman> achow101 lol
12:08 < luke-jr> 0.9375% then
12:08 < pox> 92.5% it is then :)
12:08 <@michaelfolkson> I'd prefer 90 personally. taprootactivation.com has 90 percent response rate
12:08 < prayank> xxxxbtcking: Not true according to this: https://twitter.com/LukeDashjr/status/1357017429080170497
12:08 < CubicEarth> virtu: The absolute costs are arbitrary, but it's a fact about the 2x more expensive
12:08 < luke-jr> that's 15/16
12:08 < evankaloudis> I prefer 90%
12:09 -!- Jan72 [05844214@20-66-132-5.ftth.glasoperator.nl] has joined ##taproot-activation
12:09 < hsjoberg> Actually not, we have 88% of the hashrate, so almost.
12:09 <@michaelfolkson> Any strong opposition to 90?
12:09 < hsjoberg> harding: What does ISM stand for?
12:09 < proofofkeags> michaelfolkson, nickler, do we have evidence that anyone uses 2conf finality in economic decisions?
12:09 < achow101> hsjoberg: that's the old activation method, see BIP 34
12:09 < virtu> well, now I have one, michaelfolkson , seeing how some argue that we have an estimated 88% in favor of taproot
12:09 < harding> hsjoberg: IsSuperMajority, the soft fork activation mechanism used for several forks before BIP9 was finalized.
12:09 < robert_spigler> proofofkeags: I know people who still use 0confs...
12:09 < proofofkeags> all LN impls afaict use 3confs by default
12:09 < nickler> proofofkeags: no it's just a number I picked
12:09 < virtu> we shouldn't chose the threshold based on such numbers
12:09 <@michaelfolkson> virtu: Ha!
12:09 -!- xxxxbtcking [5565c5ac@85.101.197.172] has quit [Quit: Connection closed]
12:10 < benthecarman> proofofkeags I think coinbase only requires 2 confs for deposits
12:10 <@michaelfolkson> Any other strong opposition to 90?
12:10 -!- xxxxbtcking [5565c5ac@85.101.197.172] has joined ##taproot-activation
12:10 < hsjoberg> harding: Ah right
12:10 < debit> proofofkeags IIRC there are some exchanges that have ~2 block as confirmed
12:10 < benthecarman> ack on 90
12:10 -!- lums [5cd4267c@ipservice-092-212-038-124.092.212.pools.vodafone-ip.de] has joined ##taproot-activation
12:10 < proofofkeags> if coinbase uses 2conf deposits, we can't do 90
12:10 < andrewtoth> ack on 90
12:10 < debit> but that's there speculation / loss
12:10 < luke-jr> wait, was there opposition to 90?
12:10 < hsjoberg> ACK 90%
12:10 < proofofkeags> NACK 90 IFF coinbase uses 2conf deposits
12:10 <@michaelfolkson> luke-jr: I'm asking if there is strong opposition to 90
12:11 < CubicEarth> proofofkeags: or they shouldn't do 2 conf deposits!
12:11 < belcher> am i missing something, how is 90% vs 95% related to 2conf?
12:11 <@michaelfolkson> proofofkeags: Ok that is useful. We need to understand if Coinbase does then
12:11 -!- rgrant [~rgrant@unaffiliated/rgrant] has quit [Ping timeout: 240 seconds]
12:11 < devrandom> coinbase can increase their confirmation threshold if they have a concern
12:11 < hsjoberg> I don't understand the connection either.
12:11 < waxwing> strong NACK to taking Coinbase into account.
12:11 < harding> IMO, Coinbase and other exchanges should be expected to run full nodes that enforce the latest consensus rules (at least as gateway nodes).
12:11 < luke-jr> proofofkeags: why does that matter?
12:11 <@michaelfolkson> belcher: nickler's analysis I shared
12:11 < proofofkeags> I don't disagree, but splitting coinbase off of the network is a huge risk that people should take very seriously
12:11 < CubicEarth> belcher: I don't understand either
12:11 <@michaelfolkson>  nickler quick & dirty simulation showing that the probability of unupdated nodes to be on a >=2 block invalid chain is increased by about 4x. It assumes the worst case that lagging miners don't update after lock-in & accept non-standard transactions. https://github.com/jonasnick/bip8-tester/blob/master/threshold.py
12:11 < nickler> belcher: being on a 2 block invalid chain with an unupgraded node is 4x higher (~5%) with 90%
12:11 < ghost43> belcher CubicEarth  due to numbers at bottom of https://github.com/jonasnick/bip8-tester/blob/master/threshold.py
12:11 < xxxxbtcking> There is no way bitcoin should allow taproot to be lot=false if miners are given the freedom block. It’s ridiculous they should have that right
12:12 < luke-jr> proofofkeags: threshold doesn't split anyone off
12:12 < debit> proofofkeags the network does not cater the finality requirements of an individual business
12:12 < newNickName> what does coinbase have to do with anything
12:12 < virtu> I just don't see the upside of changing 95% to 95%-x
12:12 <@michaelfolkson> Off topic xxxxbtcking, sorry
12:12 < devrandom> there's no way that coinbase will be unupdated
12:12 -!- lums [5cd4267c@ipservice-092-212-038-124.092.212.pools.vodafone-ip.de] has quit [Client Quit]
12:12 < proofofkeags> nickler's analysis says that you can get a >= 2 block invalid follow with ~4% probability
12:12 -!- rgrant_ [~rgrant@unaffiliated/rgrant] has joined ##taproot-activation
12:12 < devrandom> or any other serious exchange
12:12 -!- Jetlag [5ed1470e@94-209-71-14.cable.dynamic.v4.ziggo.nl] has quit [Ping timeout: 240 seconds]
12:12 < waxwing> indeed this is silly
12:12 <@michaelfolkson> So 90 regardless of Coinbase?
12:12 < CubicEarth> virtu: Why not 99% then? Can you see that 99% would enable a hostile actor to block at almost no expense?
12:12 < achow101> 90
12:13 < harding> 90
12:13 < robert_spigler> yep
12:13 < satosaurian> +
12:13 < nickler> I mean, if people don't upgrade after lock in they shouldn't run a Bitcoin business
12:13 < CubicEarth> y
12:13 < belcher> nickler +1
12:13 < benthecarman> nickler +1
12:13 < proofofkeags> fair opint
12:13 < belcher> its two whole weeks
12:13 <@michaelfolkson> Ok I'm hearing no strong opposition to 90
12:13 <@moneyball> luke-jr regarding "would a longer timeoutheight make anyone happier with LOT=true?" isn't a concern with something like bip8(2y, true) that there would be political shenanigans in which miners get pissed about true, do not signal, then we have to wait 2 years. otoh, miners might have signaled with bip8(1y, false) and we get taproot in 2021?
12:13 < TristanLamonica> nickler yup
12:13 < belcher> the bip66 situation happened because the new rules took effect straight away, in the middle of the night for some people
12:13 < hsjoberg> Everyone should update regardless if the threshold is 90% or 99%
12:13 < ghost43> taking coinbase into consideration might be a bad precedent; so yes, ignore them
12:13 <@michaelfolkson> Any other parameters need discussing luke-jr?
12:13 -!- rgrant_ is now known as rgrant
12:13 < hsjoberg> So basing it of Coinbase not upgrading is silly.
12:13 < harding> nickler: (thanks for doing the math!)
12:13 < CubicEarth> ghost43: So that calculation is for the moment of split? But not a recurring risk?
12:14 <@michaelfolkson> Yeah thanks nickler
12:14 < robert_spigler> does no one else think startheight needs longer time for economic majority to upgrade?
12:14 < proofofkeags> nickler, thank you for the math
12:14 <@michaelfolkson> I think that's all parameters. No agreement on LOT=true vs LOT=false
12:14 < CubicEarth> robert_spigler: I don't understand the risk if people don't upgrade right away
12:14 < benthecarman> imo it should be sooner but its fine as is
12:14 < luke-jr> michaelfolkson: preparing a wiki page with results
12:14 -!- mpenga [c5fae077@197.250.224.119] has quit [Quit: Connection closed]
12:15 < harding> robert_spigler: IMO, we only need a strong economic minority with no significant opposition for the remainder of the economy.
12:15 < robert_spigler> CubicEarth: nodes ultimately need to enforce all rules, not rely on miners to do it for them
12:15 < prayank> nickler: +1 or maybe interested in delaying things and it's possible. Considering the response I got from Greg Maxwell and my assumption about % of vulnerable nodes running right now according to pie charts shared by luke-jr
12:15 < nickler> proofofkeags: feel free to double check :)
12:15 <@michaelfolkson> Before we wrap up I am more confident that Core would implement lot=false than lot=true even though I personally prefer lot=true
12:15 < debit> harding +1
12:15 < benthecarman> michaelfolkson agreed
12:15 < CubicEarth> robert_spigler: All the rules they want to support... I don't see the risk if people don't bother to enforce a rule they presumably don't care about
12:15 < robert_spigler> harding: right now we have ~5 months?
12:15 < harding> robert_spigler: basically, if a block is produced that violates the rules, it should be clear to miners that they need to reorg that out of the chain ASAP.
12:16 <@michaelfolkson> I don't know whether that should factor in to what we propose to the mailing list
12:16 < darosior> michaelfolkson: "No agreement on LOT=true vs LOT=false" i believe the majority is in favour of LOT=false, but i'm probably biased :)
12:16 < pox> that shouldn't matter
12:16 < achow101> michaelfolkson: I expect that the core devs who care are currently in this meeting. the rest are ambivalent
12:16 < virtu> michaelfolkson: without having counted, I think preferences were balanced
12:16 < harding> robert_spigler: IMO, 2 months is ok given the adoption data from luke-jr's stats.
12:16 < achow101> so whatever is proposed from this meeting will be merged
12:16 < gg34> the majority present seemed in favor of lot=true.
12:16 < luke-jr> harding: how so?
12:16 < proofofkeags> darosior, not today
12:16 < robert_spigler> CubicEarth: they could follow an invalid chain without knowing
12:16 < luke-jr> https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
12:16 -!- kiwi_73 [32f36641@gateway/web/cgi-irc/kiwiirc.com/ip.50.243.102.65] has quit [Ping timeout: 260 seconds]
12:16 <@michaelfolkson> Who was strongly against lot=true in summary in the meeting? fjahr achow101 darosior
12:16 < proofofkeags> majority today was L=T, last week it was L=F
12:17 < luke-jr> please take turns editing :P
12:17 < harding> robert_spigler: (assuming people really do want taproot as much as they typically want a new Bitcoin Core release.)
12:17 < pox> gg34 seems to me to be a tie
12:17 < CubicEarth> robert_spigler: But they themselves define what is valid and not!
12:17 < virtu> michaelfolkson: I wouldn't factor core's preference(s) in. just objectively report the results
12:17 < CubicEarth> So I don't see that happening
12:17 < xxxxbtcking> What is the worst case for saying lot false vs true? Is it just the miners ability to not upgrade ?
12:17 < luke-jr> darosior: majority is clearly in favour of LOT=true IMO
12:17 < belcher> michaelfolkson harding as well i believe(?)
12:17 < robert_spigler> harding: thanks
12:17 -!- const_cast [c196d657@c193-150-214-87.bredband.comhem.se] has quit [Quit: Connection closed]
12:17 < waxwing> i expect meaningfully more delay if we choose lot=true. it's debatable if that matters, but there can easily be a contingent of miners that see this badly.
12:17 < prayank> luke-jr: knots will have LOT= true?
12:17 <@michaelfolkson> belcher: lot=false was harding preference but not strong opposition to lot=true
12:17 < belcher> ah
12:18 < luke-jr> prayank: at least an option
12:18 < rgrant> waxwing: this seems pessimistic.  Do we know they would object?
12:18 <@michaelfolkson> I'm effectively seeing whether there is clear consensus for lot=true or not. If there isn't Greg is against
12:18 < andrewtoth> LOT=true is pessimistic
12:18 < waxwing> rgrant, perhaps. i think it *highly* unlikely any of them will see a negative, if we choose lot=false.
12:18 < waxwing> they've already indicated as much en masse.
12:18 < luke-jr> andrewtoth: no, LOT is just not reintroducing a bug
12:18 < xxxxbtcking> Lot = true is a balance in power and choice for bitcoin upgrades
12:18 < proofofkeags> the only person at this meeting that I recall saying they were strongly opposed to LOT=TRUE, was achow101
12:18 < luke-jr> LOT=true*
12:19 < CubicEarth> proofofkeags: Other people were too
12:19 < rgrant> michaelfolkson: Greg isn't here because he's trying to not be responsible for stuff like this.  Let him not be here.  :)
12:19 < Billy> michaelfolkson: Majority was L=T, but majority of strong opposition was against L=T I believe. I didn't see clear consensus either way
12:19 <@michaelfolkson> fjahr darosior strongly opposed too proofofkeags
12:19 < luke-jr> BTW the channel is always here if people want to discuss LOT more outside the meeting
12:19 < proofofkeags> other people preferred L=F, but would accept L=T, CubicEarth
12:19 < proofofkeags> ok
12:19 < proofofkeags> apologies for misremembering
12:19 < CubicEarth> Billy: Yes
12:19 < darosior> proofofkeags: i'm opposed too to starting with LOT=true
12:19 < achow101> y'all got some serious recency bias going on
12:19 < brg444> Good luck getting Core to push a lot=true release
12:20 < luke-jr> having everything *except* LOT at least allows people to release/run with either way
12:20 < hsjoberg> Billy: Seems about right
12:20 <@michaelfolkson> rgrant: I'm glad Greg isn't here but we should listen to his view. Similarly with Matt
12:20 < belcher> achow101 recency bias about 2017?
12:20 < waxwing> should we now be debating on the 1yr parameter? or is that consensus now?
12:20 < proofofkeags> michaelfolkson: yes, Matt presents a very good case, even though I ultimately find it insufficient to convince me
12:20 < debit> have we stopped talking about parameters  and gone back to LOT?
12:20 <@michaelfolkson> 1 yr was strong consensus in last meeting waxwing
12:20 < achow101> belcher: no, about how many people support lot=true
12:20 < hsjoberg> 1y was discussed last time
12:20 < xxxxbtcking> What’s the downside of a quicker upgrade period ?
12:20 < hsjoberg> With strong consensus for it
12:20 < waxwing> michaelfolkson, ok
12:21 < debit> Did we finish talking about parameters?
12:21 <@michaelfolkson> Ok I'm going to wrap up if there is nothing more to discuss
12:21 < belcher> whats the next steps?
12:21 < luke-jr> debit: I think so
12:21 < debit> +1 belcher
12:21 < xxxxbtcking> Like when you say that 1y that’s the maximum time to activation. ?
12:21 <@michaelfolkson> Next week is code review belcher
12:21 < harding> achow101: I've wondered if this meeting also has a self-selection bias, but that's also an easy excuse when one is in the minority.  :-)
12:21 < proofofkeags> only if L=T, it could be never if L=
12:21 < Murch> I'm also opposed to LOT=true
12:21 < fiach_dubh72> smile for youtube devs
12:21 < achow101> belcher: I would say the reaction to 2017 is more PTSD
12:21 <@michaelfolkson> Strongly Murch?
12:21 < luke-jr> I guess someone can format https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102 for a ML recommendation
12:22 < debit> xxxxbtcking I think arguments for 1Y vs 6 Months is miner software upgrade timing
12:22 < hsjoberg> rgrant: Responsible move would be to keep Core devs out of this actually.
12:22 < proofofkeags> achow101, lol yeah, definitely PTSD
12:22 <@michaelfolkson> A light opposition or a literal NACK Murch?
12:22 < luke-jr> it's not really a full proposal, but at least it minimises chaos
12:22 < luke-jr> short of consensus on LOT
12:22 < prayank> achow101: Or being prepared for the worst
12:22 < xxxxbtcking> Debit thank you
12:22 < rgrant> hsjoberg: sure, not opposed to just reading the responses.
12:23 <@michaelfolkson> harding: I think there is a lot of light opposition to both LOT=true and LOT=false
12:23 < darosior> iirc rusty was also against starting with LOT=true but can't comment for him on the strength
12:23 < hsjoberg> Is recency bias supposed to be bad?
12:23 < jonatack> michaelfolkson: strong preference for L=F for me, but like harding, L=T would not drive me away from bitcoin
12:23 < xxxxbtcking> Is 6 months not reasonable for a software upgrade ?
12:23 < Murch> I think it's a bad idea
12:23 < brg444> Has anyone considered that lot=true flag day activating is THE worst case scenario
12:23 < Murch> More NACK than slight opposition
12:23 < luke-jr> I'm inclined to roll a 0.21.0 with proposal + LOT=true after the meeting.
12:23 < proofofkeags> darosior, correct, but rusty supported possibly going to L=T after L=F, so I'd infer it was a weak opposition from that
12:23 < harding> michaelfolkson: that seems like a fair summary.
12:23 <@michaelfolkson> Strong preference for LOT=false Murch?
12:23 < darosior> proofofkeags: i do too
12:23 <@michaelfolkson> Thanks jonatack. That is a pretty strong preference (like harding) ;)
12:24 < benthecarman> It seems most people are either supportive or okay with lot=false besides a few ppl
12:24 < hsjoberg> luke-jr: nice
12:24 -!- gr-g [4db9759e@x4db9759e.dyn.telefonica.de] has left ##taproot-activation []
12:24 < xxxxbtcking> What is the game theory benefit in long term ecosystem balance of lot = true ?
12:24 < Murch> Like jonatack and harding, I guess
12:24 < xxxxbtcking> Sorry false
12:24 < luke-jr> meh, better to wait and see I guess
12:24 < debit> is anyone in favor of Core releasing LOT=True? IIRC no one supports that
12:24 < luke-jr> debit: most people
12:24 < belcher> brg444 do you mean because of a risk of reorgs?
12:24 -!- trtvitor [415d6c93@bras-base-hmtnon1497w-grc-36-65-93-108-147.dsl.bell.ca] has quit [Quit: Connection closed]
12:24 < benthecarman> debit i would
12:24 < satosaurian> yes debit
12:24 < xxxxbtcking> Yes i support
12:24 < proofofkeags> debit: I would
12:24 < Murch> Whatever those categories are supposed to mean ¯\_(ツ)_/¯
12:25 < debit> ok my mistake 0:)
12:25 <@michaelfolkson> Ok I'm going to wrap up. Thanks for coming. Code review next week, same time
12:25 < Murch> luke-jr: I think that's a misrepresentation.
12:25 < brg444> belcher I mean because that would imply that miners incentives are absolutely out of whack
12:25 < prayank> debit: Yes
12:25 < achow101> debit: presumably all of the people in favor of lot=true want core to release lot=true
12:25 <@michaelfolkson> I'll write something up for the mailing list
12:25 < hsjoberg> debit: What do you mean? The whole meeting today is about Core releasing lot=true. (Not saying _they_ would accept it though)
12:25 < proofofkeags> thank you, michaelfolkson, for moderating
12:25 <@michaelfolkson> #endmeeting
12:25 < andrewtoth> thanks michaelfolkson
12:25 < darosior> Thanks everyone for coming, thanks michaelfolkson for organising and moderating
12:25 < luke-jr> Murch: pretty much every LOT poll has been in strong favour of LOT=true and against LOT=false
12:25 < belcher> thanks michaelfolkson
12:25 < xxxxbtcking> Thank you
12:25 < benthecarman> appreciate it michaelfolkson
12:25 <@michaelfolkson> Feel free to continue discussion even though meeting has ended
12:25 < hsjoberg> Thanks michaelfolkson
12:25 < achow101> luke-jr: that's literally not true
12:25 < robert_spigler> Thank you michaelfolkson
12:25 < devrandom> +1
12:25 < satosaurian> thanks, good evening everyone
12:25 < debit> thanks everyone
12:25 < luke-jr> achow101: yes it is
12:25 < virtu> Murch: what luke is saying is not correct
12:25 < waxwing> this meeting hasn't discussed much whether we have it configurable in the software, i guess if that was normalized it would end the impasse on lot=?
12:25 < harding> michaelfolkson: thanks for organizing!
12:25 < luke-jr> achow101: show me a single one contradicting it
12:25 < proofofkeags> yeah, luke-jr, as much as I support L=T, that is pretty revisionist
12:25 < pox> michaelfolkson thank you very much for organizing and moderating.
12:26 -!- Alexandre_Chery [946692c2@148.102.146.194] has quit [Quit: Connection closed]
12:26 -!- satosaurian [b0c7d357@ip-176-199-211-87.hsi06.unitymediagroup.de] has quit [Quit: Connection closed]
12:26 < achow101> the lot=true crowd are being more vocal here during the discussion, but in the section where preferences were being stated many preferred lot=false
12:26 < virtu> Murch: last meeting's preference was in favor of LOT=false (see ML posts)
12:26 < proofofkeags> the majority of the meeting from 2 weeks ago was opposed to L=T fairly strongly
12:26 < harding> luke-jr: what about aj's poll of developers?
12:26 < Murch> I mean, given that there were numerous people slightly opposed and multiple strongly opposed that doesn't seem like a fair summary
12:26 < achow101> (that's also why I said recency bias)
12:26 < debit>  hsjoberg maybe I missed some points, I was tracking the discussion around people preferences around T vs F but not as it related to core's release.  Maybe I didn't follow accurately
12:26 < hsjoberg> achow101, and lot=false was more vocal against lot=true last time
12:26 < robert_spigler> achow101: every poll I've seen has favored LOT=true
12:26 < proofofkeags> there was a much larger support for L=T today than two weeks ago, but still not overwhelming
12:26 < virtu> this week was undecided at best, not 'most in favor of LOT=true'
12:26 < luke-jr> harding: developers are not the community
12:26 < hsjoberg> It's very messy
12:26 < hsjoberg> debit: No worries
12:26 < luke-jr> virtu: last meeting had no polling at all
12:27 <@michaelfolkson> My view for what it is worth is that there is more strong opposition to lot=true than lot=false
12:27 -!- Alexandre_Chery [946692c2@148.102.146.194] has joined ##taproot-activation
12:27 -!- Alexandre_Chery [946692c2@148.102.146.194] has left ##taproot-activation []
12:27 < harding> luke-jr: you didn't say "poll of the community".
12:27 < xxxxbtcking> This has greater user benefits than anything else
12:27 < robert_spigler> achow101: But I agree there definitely isn't consensus
12:27 <@michaelfolkson> More effective NACKs against lot=true
12:27 < brg444> Has anyone considered that the Bitcoin Core project does not owe it to the community to release code according to "polls"?
12:27 < proofofkeags> michaelfolkson, I'd say that is pretty clear, yes
12:27 < benthecarman> every twitter poll I see is in favor of lot=true
12:27 < Billy> thanks michaelfolkson
12:27 < brg444> sorry, the "community"
12:27 < hsjoberg> debit: I think most people joining these meetings want Core to accept a proposal being discussed here
12:27 < luke-jr> harding: that's implied by being all that matters
12:27 -!- Billy [9f020fd5@dhcp-213-15-2-159.pbband.net] has quit [Quit: Connection closed]
12:27 < achow101> robert_spigler: I never said there was. there clearly isn't
12:27 -!- eeb77f71f26eee [~jakob@c-9b25205c.044-240-6c756c1.bbcust.telenor.se] has quit [Quit: leaving]
12:27 < brg444> hsjoberg I don't
12:27 < virtu> michaelfolkson: should be quantifiable with today's logs
12:27 < harding> luke-jr: I'm glad you implied it, but I didn't infer it.
12:27 < darosior> benthecarman: Bitcoin twitter is not representative of the Bitcoin community imho..
12:27 < belcher> brg444 from what i see the F7 point convinces many people
12:27 < hsjoberg> bgr444: then why are you here?
12:28 < belcher> core devs are the ones who would have to put up with the FUD
12:28 < belcher> put up with people thinking they control bitcoin
12:28 < jonatack> ^
12:28 < benthecarman> darosior: agreed, but is still a data point
12:28 < luke-jr> darosior: historically it has been fairly accurate
12:28 < proofofkeags> Twitter is a weak signal
12:28 < pox> @michaelfolkson that's not my impression, but maybe going through the chat history more closely could settle this.
12:28 < debit> F7 is very persuasive
12:28 < rgrant> belcher: F7 should be grown into.  We should have more infrastructure and more frequent decisions on similar issues.
12:28 < proofofkeags> debit: agreed
12:29 <@michaelfolkson> The Core repo is reviewed with strong NACKs holding sway
12:29 < xxxxbtcking> Taproot is an historic upgrade and it needs swift and non chaos within the community
12:29 < achow101> time to go back to the preferences section and more closely tally the preferences
12:29 < proofofkeags> F7 was the strongest argument I've seen to sway me towards L=F
12:29 < rgrant> (rather than strting F7 as a thing today)
12:29 < brg444> because I'm here to voice that opinion. that the bitcoin core project has its own decision making process and its code has never been and should not be the result of a "community" decision
12:29 <@michaelfolkson> I'm hearing more strong NACKs against lot=true
12:29 < brg444> I missed the earlier part. What is F7
12:29 < waxwing> F7 is very strong agreed, but F5 is already a good argument.
12:29 < waxwing> F7: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
12:29 <@michaelfolkson> It would help if you did some limited pre-reading brg444 :)
12:30 <@michaelfolkson> Rather than just complain
12:30 < luke-jr> michaelfolkson: depends on who leaves the NACK. some of us get ignored.
12:30 < debit> I don't sense any chaos with taproot's viability, I sense everyone wants to smoothly coordinate on it's activation
12:30 < robert_spigler> I'd feel better with LOT=false if it was bundled with LOT=true as a second period afterwards (modern soft fork, not necessarily those parameters)
12:30 < achow101> brg444: Core has it's code review process, but I believe that the maintainers have stated that specific parameters are up to the community to decide, and whatever those parameters are will be merged
12:30 < debit> brg444 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html is F7
12:30 < hsjoberg> brg444: Ah I understand, makes sense
12:30 < hsjoberg> That's not what they believe regarding softforks though.
12:31 < newNickName> taproot's activation method has more controversy than taproot itself
12:31 -!- AngryAgain [50834a92@p50834a92.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
12:31 < proofofkeags> for real, lol
12:31 < waxwing> F7 is also strongly related to my earlier (complete conjecture) that lot=false will likely lead to faster activation. taking away the perspective of control.
12:31 < belcher> newNickName +1
12:31 < luke-jr> I suppose there's a question.. if the devs with strong NACKs, will ACK if they are convinced the community wants LOT=true
12:31 -!- xxxxbtcking [5565c5ac@85.101.197.172] has quit [Quit: Connection closed]
12:31 < hsjoberg> They have been very clear in the past that they want softforks to be up to the community
12:31 < belcher> newNickName which makes sense, activation is all about everyone agreeing that at the same time they will start to enforce a new rule
12:31 < hsjoberg> And it's probably why we don't have Taproot already
12:31 < brg444> Oh, well yeah F7 is obvious
12:31 < brg444> That's what I've been advocating all along
12:31 < luke-jr> "Even if this recommendation is adopted by developers, it must still be accepted by the community in the form of actively choosing to run the software which includes the activation. So long as the activation is clearly and prominently documented, users have taken the action to accept the protocol change. Furthermore, this proposal is being recommended on the belief that the community has already demonstrated a clear and undisputed
12:31 < luke-jr> support for the activation of Taproot."
12:31 < brg444> Stop trying to bully Core into doing what Twitter want
12:32 < debit> and many others too brg444
12:32 < proofofkeags> we don't have a reliable way to assess community support
12:32 < proofofkeags> that seems to be the crux of the problem
12:32 < luke-jr> proofofkeags: if that is true, then ossification is the answer immediately
12:32 < hsjoberg> We are not bullying anybody.
12:32 < brg444> Them releasing lot=false won't make any different on the outcome
12:32 < luke-jr> and ossification kills Bitcoin
12:32 < proofofkeags> not necessarily, we can work towards more reliable collection of that info
12:32 < luke-jr> brg444: that's not true
12:32 < luke-jr> brg444: LOT=false allows miners to activate even without community support
12:32 < brg444> If everyone in this room claiming to support lot=true strongly run lot=true code the outcome is set
12:33 < debit> proofofkeags info is worthless, consumers and producers need to pay each other
12:33 <@michaelfolkson> I feel very uncomfortable asking Core to implement something that is counter to what they did with SegWit and with a greater number of strong NACKs
12:33 < brg444> luke-jr there is community support, you've said so yourself
12:33 < rgrant> brg444: lot=false is dangerous to UASF when UASF is necessary.  It leaves us more passive.
12:33 < Murch> proofofkeags: And even when many people say they want it, there is a large number of people who will just be completely silent and inactive
12:33 < CubicEarth> luke-jr: They can enforce any rules at anytime....
12:33 <@michaelfolkson> Strong NACKs from Core contributors I would add
12:33 < proofofkeags> Murch: that's my poing
12:33 < newNickName> CubicEarth no
12:33 < luke-jr> brg444: with community support, LOT=true is the logical conclusion
12:33 < brg444> rgrant it's not because a successful UASF is one that never activates
12:33 < luke-jr> CubicEarth: no
12:33 < waxwing> i still don't NACK lot=true, i've always just preferred false for the above reasons.
12:33 <@michaelfolkson> I think it is regrettable because I think LOT=true is superior for this one off soft fork activation
12:33 -!- xxxxbtcking [5565c5ac@85.101.197.172] has joined ##taproot-activation
12:34 -!- Massif [ae77b5a9@gateway/web/cgi-irc/kiwiirc.com/ip.174.119.181.169] has joined ##taproot-activation
12:34 < pox> @luke-jr why does ossification kill bitcoin?
12:34 <@michaelfolkson> But harding argument is persuasive longer term over multiple soft forks
12:34 < proofofkeags> debit: yes I'd prefer a means of fee burning to signal support from users.
12:34 < luke-jr> pox: because Bitcoin is not mature/developed enough to survive against superior competition
12:34 < waxwing> i mean if you want a market signal you could have a futures market
12:34 < darosior> Let's just start with LOT=false and reconsider after 3/4 months
12:34 < brg444> i will repeat, you only need a strong minority to run lot=true for lot=true to achieve its desired effect. If lot=true activates on flag day we have much bigger problems on our hands than the all network nodes not being in sync
12:34 < proofofkeags> luke-jr, 100%
12:34 -!- jonas [53e25b2a@c-2a5be253.117-2-64736c12.bbcust.telenor.se] has joined ##taproot-activation
12:34 < darosior> And maybe take a decision after 6
12:34 < waxwing> such futures markets happened around segwit2X for example
12:34 < darosior> ?
12:34 < debit> proofofkeags fee burning is not ideal, you want a bond or derivative
12:34 < luke-jr> pox: ossification means competition can take and keep a significant lead
12:34 < Murch> I think LOT=false will activate faster, gives miners a chance to "redeem" their standing and is safer. LOT=true just pours oil in the fire before there is any need by signaling explicit distrust to miners.
12:35 < CubicEarth> We actually don't even know what unknown rules miners might be enforcing right now. We wouldn't know until we tried to do something we thought was allowed and it was rejected
12:35 < rgrant> pox: because there's a lot of narrative that you need other coins to do things, and if we can grow and adapt then that's less true and we get more value into Bitcoin.
12:35 < xxxxbtcking> Murch why do you want to signal trust to miners
12:35 < debit> reusable proofs of work > proofs of work / burns
12:35 < harding> brg444: what's the probablem of activation on flag day?
12:35 < luke-jr> CubicEarth: enforcing "rules" beyond that of full nodes, reduces full nodes to light wallet security, and is an attack on the network making it centralisede
12:35 < brg444> There does _not_ need to be consensus at the network level for any activation method for the desired outcome
12:35 < Murch> At least that's how I think it wuold be taken
12:35 -!- jonas [53e25b2a@c-2a5be253.117-2-64736c12.bbcust.telenor.se] has quit [Client Quit]
12:35 < CubicEarth> luke-jr: That doesn't mean they can't
12:35 < darosior> Murch: +1 it does all that without removing the possibility to make an UASF should it be needed
12:36 < luke-jr> CubicEarth: it's an attack, not a softfork
12:36 < Murch> xxxxbtcking: The absence of signaling distrust is not "signaling trust"
12:36 < brg444> harding fundamentally broken incentives system.
12:36 -!- dergoegge [sid453889@gateway/web/irccloud.com/x-vpggjtvyxjofpnen] has joined ##taproot-activation
12:36 < newNickName> CubicEarth that's absolutely impossible
12:36 < harding> brg444: I don't understand.
12:36 < luke-jr> Murch: LOT=true does not signal distrust
12:36 < CubicEarth> newNickName: Huh?
12:36 < debit> waxwing yes I think we should ask some exchanges to open futures / derivatives for taproot hedging / speculation
12:36 <@michaelfolkson> I will summarize data on weak NACK and strong NACKs. I think my conclusion will be it will be hard to propose LOT=true to Core
12:36 < whuha> The miners have already earned the mistrust of the community with segwit
12:36 < luke-jr> Murch: LOT=false DOES signal trust
12:36 < xxxxbtcking> Murch true but also it’s better to be concrete than left to inference
12:36 < Murch> luke-jr: It's my expectation how miners will perceive it from what they have told us
12:37 < brg444> harding if lot is set to =true and miners don't activate then they are actively working against users and actively risking their income
12:37 < proofofkeags> whuha, the miners today are not the same as the miners in 2017
12:37 < luke-jr> michaelfolkson: I think at this point we need to simply leave LOT out of the proposal
12:37 < CubicEarth> newNickName: Miners could already be enforcing a narrow rule that blocks spends from one of your utxos. We might now be aware of that rule until you tried to spend it.
12:37 < luke-jr> Murch: then clarify with them better.. it isn't.
12:37 < rgrant> Murch: any links?
12:37 < brg444> if lot=true activates there will be a network split
12:37 <@michaelfolkson> luke-jr: Ok
12:37 < hsjoberg> luke-jr: What do you mean by leaving LOT out?
12:37 < proofofkeags> luke-jr how is the proposal complete without a LOT value
12:37 < xxxxbtcking> Miners provide very valuable service to the network but also they get paid so it’s an economic incentive, but why does an upgrade to software that isn’t touching the mining algorithm much of their concern
12:37 < harding> brg444: oh, I see.  I was confused by your use of "activation", which we usually use to mean the soft fork itself activates.
12:37 -!- TristanLamonica [4c474157@bras-base-otwaon238vw-grc-02-76-71-65-87.dsl.bell.ca] has quit [Quit: Connection closed]
12:38 < luke-jr> hsjoberg: just say we couldn't come to a conclusion? dunno
12:38 < hsjoberg> It has to be decided somehow
12:38 < hsjoberg> Okay
12:38 < luke-jr> hsjoberg: it is admittedly not a solution
12:38 < luke-jr> proofofkeags: it isn't
12:38 < proofofkeags> k
12:38 < Murch> rgrant: look at Taprootactivation.com almost all only support "false" if they even made any determination
12:38 < xxxxbtcking> Murch that’s because it’s a power play
12:38 < luke-jr> I don't know/have a solution
12:38  * pox likes xxxxbtcking's point
12:38 < brg444> I can't understand anyone honestly considering miners not activating and then suddenly falling in line post flag day
12:38 < luke-jr> Murch: that's more reason to insist on true
12:38 < brg444> It's all a bit silly
12:38 < waxwing> Murch, ah thanks. there is actually evidence, then :)
12:38 < debit> brg444 miners who don't activate after flag day cannot know if nodes will buy / use their blocks, they can only speculate
12:39 < luke-jr> Murch: a miner saying "I want power to veto" is a miner threatening to veto
12:39 < belcher> brg444 well miners are in it for the money, right?
12:39 < proofofkeags> yeah
12:39 < proofofkeags> there's no way they don't fall in line if theres a UASF
12:39 < xxxxbtcking> Like-jr for sure
12:39 < hsjoberg> brg444: They don't have a choice with lot=true
12:39 < brg444> lol
12:39 < brg444> you guys are missing the point
12:39 < waxwing> brg444, that's exactly what happened in aug 2017, they just pretended it didn't.
12:39 < waxwing> but we don't need to go down this road here.
12:39 < belcher> brg444 so explain it to us
12:39 < rgrant> luke-jr: +1
12:39 < xxxxbtcking> This upgrade is too history to give miners veto I think everyone needs to digest it
12:39 < waxwing> this is not really contentious
12:39 < hsjoberg> Exactly, BIP91 was to "prevent" UASF
12:39 < brg444> debit So they're gonna sit on their hands until the flag day THEN and only then will they upgrade their node
12:40 < brg444> What's the play here?
12:40 < brg444> If they are forced to fall in line anyway, why would they not activate it
12:40 < proofofkeags> that's luke-jr's point
12:40 < luke-jr> anyone want to just move on to code review? :P
12:40 < brg444> waxwing We didnt get to flag day activation in 2017
12:40 -!- trtvitor [415d6c93@bras-base-hmtnon1497w-grc-36-65-93-108-147.dsl.bell.ca] has joined ##taproot-activation
12:40 < belcher> brg444 yes we did, my node activate
12:40 < belcher> activated*
12:40 < pox> @brg444 because it doesn't cause them anything?
12:40 < hsjoberg> brg444: They would obviously upgrade far before that
12:41 < whuha> proofofkeags: It is an argument similar to saying: today's politicians are more honest than previous ones (it doesn't matter when you read this) they are politicians, their nature does not change, the same thing happens with miners
12:41 < xxxxbtcking> Miners hold btc no? They also get the benefits of taproot so it’s not an issue for the upgrade but an issue of their voice in each software change
12:41 < brg444> belcher the miners activated it before
12:41 < belcher> brg444 "The supreme art of war is to subdue the enemy without fighting."
12:41 < brg444> exactly my point
12:41 < belcher> we got the thing we wanted, and the costs were much lower
12:41 < hsjoberg> xxxxbtcking: The democgraphics of miners are unclear for me.
12:41 < proofofkeags> whuha, that analogy is not good. Jihan openly fought against segwit in 2017, we don't have miners openly campaigning against TR today
12:41 < hsjoberg> It could also just be outsiders that want monmey
12:41 < Murch> robert_spigler: By having two activation attempts we learn in the first round how many node operators upgraded and can actually learn whether node operators support in action as well as "twitter polls"
12:42 < luke-jr> proofofkeags: only AFTER the activation was deployedf
12:42 < luke-jr> proofofkeags: before that, Jihan said he was onboard
12:42 < brg444> miners will capitulate and activate therefore the notion that we need all the network nodes to be in sync on lot=true because of split risk on flag day is egregious
12:42 < proofofkeags> was the NYA public?
12:42  * pox likes Murch's point
12:42 < belcher> proofofkeags who cares :D
12:43 < xxxxbtcking> Look bitcoin needs to get better at executing software upgrades if it wants to be competitive especially if its not touching issuance and mining algo
12:43 < brg444> What forces miners hands with a UASF is NOT the post-flag day block rejection. It's the risk of network split. That is the real damage to their bottom line
12:43 < proofofkeags> belcher It's important to understand how miners defecting happened in 2017
12:43 < belcher> xxxxbtcking theres also great benefits to knowing that your money is hard to change
12:43 < proofofkeags> iirc Jihan supported segwit because he was a member of the NYA
12:43 < brg444> An intolerant minority of lot=true nodes guarantees a network split.
12:43 < debit> brg444 why is miner capitulation inevitable with this SF but not all other arbitrary SF? say OFAC block list SF?
12:43 < prayank> proofofkeags: True. There should not be issues with Taproot. I think it's now just about improving on doing someone better than 2017 to upgrade and set better examples for future.
12:43 < proofofkeags> which traded segwit for a 2x fork
12:44 < brg444> Unless they activate
12:44 < brg444> Which they'll do
12:44 < CubicEarth> brg444: And that is fine...
12:44 < prayank> *something
12:44 < xxxxbtcking> Belcher true in a way but money isn’t changing just the way you can spend is
12:44 < hsjoberg> Good day!
12:44 < brg444> debit because no one in the community supports hthis
12:44 -!- hsjoberg [~hsjoberg@c-45c772d5.445-1-64736c11.bbcust.telenor.se] has quit []
12:44 < CubicEarth> intolerant minorities are free to leave the consensus
12:44 < belcher> proofofkeags the history went that many miners said they wouldnt activate segwit, then the UASF movement appeared, then this NYA thing appeared... so clearly NYA was just face-saving
12:44 < xxxxbtcking> You don’t have to move your coins to taproot addresses
12:44 < luke-jr> proofofkeags: NYA was long after
12:44 < brg444> CubicEarth if that's fine why are some so set on trying to get Core to release lot=true
12:44 < proofofkeags> OK thank you, that's why I asked
12:44 < luke-jr> proofofkeags: BIP148 was already locked in before NYA
12:45  * debit looks at mining groups proudly signaling they block OFAC addresses and don't mine blocks with OFAC txns in them,  seems like "an intolerant minority"
12:45 < proofofkeags> I came on scene in the middle of that mess
12:45 < CubicEarth> brg444: I'm just saying they are free to leave
12:45 < belcher> debit not the same because the censoring miners earn less miner fees
12:45 < debit> belcher yes valid
12:45 < xxxxbtcking> Cant miners activists taproot and then say we won’t let taproot transaction into the chain ?
12:45 < luke-jr> xxxxbtcking: yes, that's fine
12:45 < luke-jr> well
12:45 < proofofkeags> a soft fork for OFAC is different than miners self censoring
12:45 < belcher> xxxxbtcking sure, 51% of miners could censor anything
12:46 < luke-jr> so long as they don't attack
12:46 < belcher> xxxxbtcking but they'd earn less miner fees doing so, so it seems unlikely
12:46 < brg444> debit i'm referring to an intolerent minority of users
12:46 < proofofkeags> belcher only if they formalize it with a soft fork
12:46 -!- beetcoin59 [aec404c8@200.sub-174-196-4.myvzw.com] has joined ##taproot-activation
12:46 -!- evankaloudis [4b611f61@75.97.31.97.res-cmts.leh.ptd.net] has quit [Quit: Connection closed]
12:46 < brg444> If there is consensus on the proposal, only a minority willing to risk splitting the network is enough to align miners incentive
12:46 < belcher> proofofkeags a 51% attack is just a soft fork that you dont like
12:46 < brg444> that's the bottom line
12:46 < belcher> proofofkeags in effect anyway, in enforcement slightly different
12:47 < xxxxbtcking> I’m out thanks everyone ✌🏼
12:47 < proofofkeags> if there was total collusion then yes
12:47 -!- xxxxbtcking [5565c5ac@85.101.197.172] has quit [Quit: Connection closed]
12:47 < CubicEarth> me too... bye for now
12:47 -!- rgrant [~rgrant@unaffiliated/rgrant] has left ##taproot-activation []
12:47 < proofofkeags> but if 51% of miners independently self-censor for things like OFAC, it creates a different net result than if they flat out reject blocks with OFAC txs
12:47 < brg444> The more weight around lot=true the better but there simply isn't a need to get software level consensus about it
12:48 < belcher> brg444 i still think it would be productive to get some merchants running lot=true
12:48 < brg444> So the real risk here is alienating Core contributors and wasting a whole lot of time trying to shove lot=true down their throat
12:48 < brg444> belcher agreed
12:48 < proofofkeags> belcher which Merchants matter?
12:48 < brg444> just get Saylor to run it
12:48 < proofofkeags> Start9 would for sure run L=T
12:48 < brg444> And that'll be it
12:49 < belcher> proofofkeags well for me personally, if some merchants dont accept my bitcoins then i cant eat
12:49 < belcher> for sake of argument
12:49 < belcher> now suppose i was a miner, it would be even worse
12:49 < debit> TR seemingly will increase the utility of blockspace and provide greater revenues for miners, absent any hidden costs associated that have been yet to be disclosed (some modern version of ASICBOOST), I would argue that UASF makes miner capitulation inevitable unlock OFAC SF
12:49 < proofofkeags> I think your argument is getting away from me, are you saying you want merchants to run L=T?
12:50 < debit> give OFAC SF decreases the marginal utility of block space and hashrate
12:50 < debit> given*
12:50 -!- solairis [bbbe2660@fixed-187-190-38-96.totalplay.net] has quit [Quit: Connection closed]
12:50 < prayank> belcher: Anyone from btcpayserver team here right now?
12:50 < belcher> proofofkeags yes that would be helpful, although it seems likely that miners will just signal the bip8 bit and that will be that
12:50 < belcher> prayank btcpayserver just connects to the user's own full node, and that backing full node could run either of lot=true or false
12:51 < belcher> btcpayserver isnt centralized, they cant just change the node and change everyone's btcpay out there
12:51 < proofofkeags> belcher, btcpay does have full node deployments that they do though on behalf of their users
12:51 < proofofkeags> this is a matter of defaults in the end
12:51 < prayank> belcher: so btcpayserver merchants will use whatever core will have by default?
12:51 < belcher> does it auto-update? it does it only affect new users
12:51 < proofofkeags> most likely, yes
12:52 < proofofkeags> belcher I'm not sure if core will autoupdate, but btcpay has an in-UI update flow
12:52 < belcher> auto-update? really? so if someone hacks btcpayserver's site and replaces the node with one that awards them 1 billion bitcoins, then every btcpay instance out there will accept it?
12:52 -!- jonatack [~jon@37.173.74.168] has quit [Ping timeout: 260 seconds]
12:53 < proofofkeags> lol when you put it that way it makes me want to check. I have no idea how it manages updates for Core. I KNOW, there is an update flow for btcpay itself in the btcpay UI
12:53 < belcher> yes check, auto-updating would be a very bad idea
12:53 < benthecarman> I imagine the btc pay server has to update core as well if it is using the rpc
12:54 -!- newNickName [bb3fa187@187.63.161.135] has quit [Quit: Connection closed]
12:54 < benthecarman> It might do what bisq does and verifying signatures for you, in app
12:54 -!- gg34 [4641afdd@S0106d807b66f84ea.rd.shawcable.net] has quit [Quit: Connection closed]
12:54 < belcher> verifying signatures just means the hack im talking about is harder
12:54 -!- jonatack [~jon@37.173.74.168] has joined ##taproot-activation
12:55 < proofofkeags> alright, need to eat lunch. Peace out.
12:55 -!- proofofkeags [~proofofke@97-118-232-73.hlrn.qwest.net] has left ##taproot-activation ["Leaving"]
12:55 -!- trtvitor [415d6c93@bras-base-hmtnon1497w-grc-36-65-93-108-147.dsl.bell.ca] has quit [Quit: Connection closed]
12:55 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
12:55 -!- stortz [bb3fa187@187.63.161.135] has left ##taproot-activation []
12:55 -!- lugaxker [8ff43898@143.244.56.152] has joined ##taproot-activation
12:57 -!- lugaxker [8ff43898@143.244.56.152] has quit [Client Quit]
12:58 -!- samsepiol [8ff42e57@143.244.46.87] has quit [Quit: Connection closed]
12:59 -!- fiach_dubh72 [63f42379@cpe1033bfa9e0e7-cm1033bfa9e0e5.cpe.net.cable.rogers.com] has quit [Quit: Connection closed]
12:59 -!- marzig [6c235737@pool-108-35-87-55.nwrknj.fios.verizon.net] has quit [Quit: Connection closed]
13:01 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
13:02 -!- trtvitor [415d6c93@bras-base-hmtnon1497w-grc-36-65-93-108-147.dsl.bell.ca] has joined ##taproot-activation
13:03 -!- jonatack [~jon@37.173.74.168] has quit [Read error: Connection reset by peer]
13:03 -!- trtvitor [415d6c93@bras-base-hmtnon1497w-grc-36-65-93-108-147.dsl.bell.ca] has quit [Client Quit]
13:03 -!- jonatack [~jon@37.173.74.168] has joined ##taproot-activation
13:05 -!- stortz [bb3fa187@187.63.161.135] has quit [Client Quit]
13:08 -!- fueleh [53ff97fe@c83-255-151-254.bredband.comhem.se] has quit [Quit: Connection closed]
13:08 -!- prayank [~andr0irc@2409:4053:219c:5e4:5428:b9d2:df47:53e3] has quit [Remote host closed the connection]
13:14  * luke-jr ponders if Core could (or should) release such that there is a GUI-accessible option for LOT, and without it being set one way or the other, no activation is active at all.
13:15 -!- Jan72 [05844214@20-66-132-5.ftth.glasoperator.nl] has quit [Quit: Ping timeout (120 seconds)]
13:16 -!- jonatack [~jon@37.173.74.168] has quit [Read error: Connection reset by peer]
13:18 -!- jonatack [~jon@37.173.74.168] has joined ##taproot-activation
13:19 -!- SHlTBLASTER6900 [463f93aa@rrcs-70-63-147-170.midsouth.biz.rr.com] has quit [Quit: Connection closed]
13:19 < ghost43> how do you expect non-technical users to set that? if we want mass adoption of bitcoin, we need defaults.
13:20 -!- duringo [ad004d5a@173.0.77.90] has joined ##taproot-activation
13:22 < ghost43> consensus parameters should only be tweaked by users who definitely know what they are doing
13:22 -!- jonatack [~jon@37.173.74.168] has quit [Read error: Connection reset by peer]
13:24 -!- jonatack [~jon@37.173.74.168] has joined ##taproot-activation
13:24 < achow101> luke-jr: I expect that few people would end up setting it
13:27 -!- pinheadmz [~pinheadmz@mobile-107-107-59-49.mycingular.net] has joined ##taproot-activation
13:29 < luke-jr> ghost43: the only way to have defaults is with consensus or centralisation. since there's no consensus, you're only leaving failure as an option.
13:30 -!- jonatack [~jon@37.173.74.168] has quit [Ping timeout: 260 seconds]
13:32 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Quit: Ping timeout (120 seconds)]
13:33 -!- jonatack [~jon@37.173.74.168] has joined ##taproot-activation
13:33 < ghost43> luke-jr: I think if there is no consensus on a not too important parameter, the more conservative value for it should be the default. I think if there is no consensus on LOT, then LOT=false is the conservative default; as e.g. it allows not activating the fork, and as makes sense to transition from false to true mid-activation but not the other way around
13:34 -!- jonatack [~jon@37.173.74.168] has quit [Read error: Connection reset by peer]
13:34 < luke-jr> ghost43: the more conservative rule is LOT=true
13:35 < luke-jr> because it doesn't give miners an ADDITIONAL ability
13:35 -!- jonatack [~jon@37.173.74.168] has joined ##taproot-activation
13:37 -!- NoDeal [6b4dda22@mobile-107-77-218-34.mobile.att.net] has quit [Quit: Ping timeout (120 seconds)]
13:38 < ghost43> well I would argue the most conservative option would be to not do any additional soft forks. then, the next less conservative option is to do soft forks but in such a way that activation is not guaranteed. then the even less conservative option is to enforce soft fork on participants
13:38 -!- whuha [4f99f264@100.red-79-153-242.dynamicip.rima-tde.net] has quit [Quit: Connection closed]
13:39 -!- jonatack [~jon@37.173.74.168] has quit [Read error: Connection reset by peer]
13:41 < ghost43> but my opinion hasn't really changed since  "[2020-10-16 17:07:29 +0200] <ghost43>	we could just do BIP8(false, 1y) and keep debating while the clock is at least running :P"  i.e. let's just start the clock already
13:50 -!- viaj3ro [5b23d159@p5b23d159.dip0.t-ipconnect.de] has quit [Quit: Ping timeout (120 seconds)]
13:51 -!- jonatack [~jon@37.173.87.1] has joined ##taproot-activation
13:52 < achow101> I've gone through the preferences section and tallied up everyone who stated a preference at that time: https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
13:52 < achow101> This group was fairly split, however LOT=false has a small majority
13:54 < achow101> counting "prefer but ok with" as ok with either, LOT=false comes out more in the lead
13:55 < luke-jr> achow101: thanks, that's helpful
13:55 <@michaelfolkson> Thanks achow101
13:58 -!- pinheadmz [~pinheadmz@mobile-107-107-59-49.mycingular.net] has quit [Quit: pinheadmz]
13:58 < luke-jr> lolwut https://youtu.be/vpl5q1ovMLM
13:58 -!- brg444 [bdb179f7@189.177.121.247] has quit [Quit: Connection closed]
14:02 < elichai2> Did the meeting converge on a proposal for the actual timeline of the activation? or was it mostly on LOT or not LOT?
14:02 -!- benthecarman [~benthecar@2600:1700:201:6e60:bb6:181e:1d18:789a] has quit [Ping timeout: 260 seconds]
14:03 < darosior> elichai2: it did converge on all the parameters except LOT. The idea would be to do 693504-745920 with 90%
14:06 -!- benthecarman [~benthecar@2600:1700:201:6e60:bb2:e5f9:7c21:6d4b] has joined ##taproot-activation
14:07 < elichai2> darosior: so potentially 5-6 months, then depending on the miners until timeoutheight and then debating on lockinontime gotcha
14:07 < elichai2> (hopefully it will activate a few weeks after startheight and this whole discussion is for nothing :D )
14:08 < darosior> Well i believe no matter how quick it activates (which i strongly believe it will) it's for something :)
14:08 < darosior> elichai2: btw do you have an opinion regarding LOT ?
14:09 < elichai2> Not really, I never really dived into the different BIP signaling techniques and I don't feel informed enough on that to have a firm opinion
14:10 < roasbeef> late to the party, but I plan to start coding up a bip8 impl for btcd w/ lot=false, i like aj's notion of information gatehring if/after the timeout occurs, imo having flags or gui options for lot=true is the same as BU's "emergent consensus", so TL;DR let's give it a shot and revise afterwards if stuff actually happens
14:11 < roasbeef> I see no evidence that there's a vocal contingent that'll trigger "stuff happening", imo ppl have PTSD from segwit and/or just want to see more excitement as some uasf commando, let's try to move back to normalizing smooth softforks so the system can continue to evolve
14:11 < luke-jr> roasbeef: LOT=true is normal/smooth
14:11 < roasbeef> ideally between now and then a much smaller soft-fork would've happend to restore normalcy, but that failed to happen for various reasons
14:11 < luke-jr> re-"normalising" miner veto is not smooth
14:12 < elichai2> I do agree that we don't have to decide quite yet and we can see how it goes.
14:12 < elichai2> If we see problems coming we can change course. I'd rather start with whatever is least controversial and escalate into more controversial if there are problems
14:12 < luke-jr> elichai2: both are controversial
14:12 < elichai2> But I have a feeling both sides see the other one as controversial?
14:12 < elichai2> Lol exactly
14:13 < roasbeef> luke-jr: you keep saying that w/o looking at the tradeoffs on either side, things aren't black and white, it's destructive to always attempt to make soft forks some massive thing that needs to be defended against, given we've seen no vocal opposition on the miner side
14:13 < roasbeef> if things do happen, then ppl can react just as they did last time
14:13 < roasbeef> otherwise it's no different from other chains that just set some blockheight to activate a hardfork
14:13 < luke-jr> roasbeef: LOT=false is making it require defense against..
14:13 < luke-jr> LOT=true doesn't - it just works
14:14 < roasbeef> "just works" is disingenuous, you pre-suppose a series of events that may or not actually happen, and also opposition that doesn't seem to really exist
14:14 < luke-jr> "just set some blockheight to activate a hardfork" is more or less fine so long as there is community support
14:14 < elichai2> luke-jr: but there is community support
14:14 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
14:15 < roasbeef> if that's the case then why don't we just always do hard forks luke-jr?
14:15 < roasbeef> soft forks have been done in the prior fashion for a reason...
14:15 < luke-jr> roasbeef: higher threshold of support is needed for a HF
14:15 < elichai2> I've heard no opposition(except that one email in the ML)
14:16 < roasbeef> elichai2: yeh taht's teh thing, ppl are being preemtively defensive for seemingly no reason other than they're afraid of past events that now seem to have a low probability of actually occuring again, the prior fissure aleady happened
14:16 < roasbeef> what's left is those willing to loosely coordinate
14:16 -!- asdsadasdas [bc7a1463@nat2-2.finemedia.pl] has joined ##taproot-activation
14:16 -!- asdsadasdas [bc7a1463@nat2-2.finemedia.pl] has quit [Client Quit]
14:16 < elichai2> Not that I'm against LOT, I'm also fine with the other extreme, UASF, but only if I believe there's a "fight" to be fought
14:16 < roasbeef> pulling this off smoothly will also serve to further increase confidence in the system, it seems odd to me that some are "hungry for blood" when no battlefield even exists
14:17 < roasbeef> elichai2: exactly, and afaict there's no sort of fight to be fought, just a hypoehtical one in ppl's imaginations
14:17 < luke-jr> let's just reintroduce the inflation bug, since it's unlikely miners will allow inflation
14:17 < maybehuman> The way I see it is that it would be nice if we could take the miner veto away, but the only way to do that is to put even more responsibility on the shoulders of the maintainers, and that's not a good trade-off
14:18 < luke-jr> maybehuman: we already took it away; LOT=false would be giving it back
14:18 < elichai2> maybehuman: or users doing it themselves if they see a fight coming
14:18 < roasbeef> no, uasf was just deterrence, it didn't actually happen
14:18 < maybehuman> elichai2 yes, that's how it should be. And it worked once beofre
14:18 < roasbeef> simply having the option, is enough
14:18 -!- beetcoin59 [aec404c8@200.sub-174-196-4.myvzw.com] has quit [Quit: Connection closed]
14:19 < roasbeef> so there's no need to make every soft-fork activate via the procedure from here on, given it's just a back up plan, it's deterrence
14:19 -!- Massif [ae77b5a9@gateway/web/cgi-irc/kiwiirc.com/ip.174.119.181.169] has quit [Quit: Connection closed]
14:19 < maybehuman> luke-jr Core gave it to them last time, others took it away.
14:20 < elichai2> luke-jr: what if we make the default non LOT and a few devs will have patches on standby for people who want to be more active?
14:20 < roasbeef> maybehuman: that isn't correct, nothing was given, soft-forks had always activated in a similar fashion in the past, the differnce this time was vocal opposition, that opposition now has 2+ chains they used instead, what's left is those willing to coordinate
14:20 < roasbeef> elichai2: that's all that's needed, once again uasf is just deterrence, a smoother update via the existing methods is preferable
14:20 < roasbeef> let it ride out, if things timeout, then re-asses, it's simple
14:21 < luke-jr> elichai2: that's unreasonable
14:21 < luke-jr> roasbeef: no, that's not true..
14:21 < elichai2> roasbeef: I agree. I'm just trying to find a common ground so we can get taproot soon  :)
14:21 < maybehuman> roasbeef: I just meant it was in bip9 which was used by Core for segwit
14:21 < luke-jr> roasbeef: most softforks in the past didn't give miners a choice
14:21 -!- benthecarman [~benthecar@2600:1700:201:6e60:bb2:e5f9:7c21:6d4b] has quit [Ping timeout: 260 seconds]
14:22 < roasbeef> luke-jr: in the end, if you want to run w/ lot=true, you can do it, if things activate as normal it's the same as if you didn't, you should try to see the nuance and stop making such blanket statements
14:22 < harding> roasbeef: thanks for commenting and especially for planning to implement BIP8 in btcd.
14:23 < luke-jr> roasbeef: that makes no sense. it's "as if you didn't use LOT=false" just as equally
14:23 < maybehuman> like someone said earlier, I think lot=true would work even if it is not set by default by core
14:23 < maybehuman> So why try to push it?
14:23 < luke-jr> roasbeef: perhaps moreso
14:23 < roasbeef> maybehuman: if it comes down to it yeh, it's just deterrence
14:23 < roasbeef> maybehuman: boom
14:23 < luke-jr> maybehuman: and if we re-add the inflation bug, miners might not inflate..
14:23 < luke-jr> so why not re-add it?
14:24 < maybehuman> luke-jr: Nobody can steal or devalue my coins just because taproot doesn't activate as soon as I'd like
14:24 < elichai2> If you're so worried about miners why even use miners signaling? Why not just set a height and get it over with?
14:25 < maybehuman> I asked the same thing a coupe of days ago :-)
14:25 < elichai2> IIUC(which I might not be) its in the end very similar to LOT at the end height day
14:25 < roasbeef> maybehuman: attempts to push it seems rooted in a desire to remove miners 100% from any sort of activation process, which is just PTSD really, you can learn from history without always trying to be "battle ready"
14:26 < darosior> achow101: thanks for the tables, tried to add the summary to https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102 (limited mediawiki / pandoc skills here)
14:26 < roasbeef> elichai2: yep that's what I mentioned above, it just falls back to block height activation essentially, why even add the other ceremoney around that if that's how ppl want to activate stuff
14:26 < roasbeef> uasf is just deterrence, just having the option is enough
14:27 < darosior> I wonder if we should update the table with opinion of people not here during the meeting? I think roasbeef's one would be valuable too.
14:27 < roasbeef> just look at the history of the cold war
14:27 -!- jonatack [~jon@37.173.87.1] has quit [Ping timeout: 240 seconds]
14:27 < roasbeef> bbl
14:28 < luke-jr> roasbeef: misrepresenting LOT=true doesn't get us anywhere
14:28 < luke-jr> elichai2: "just set a height and get it over with" is fine, but slow; having MASF as an early activation option gets it sooner
14:29 < harding> luke-jr: I don't think he did.
14:29 < luke-jr> [22:25:43] <roasbeef> maybehuman: attempts to push it seems rooted in a desire to remove miners 100% from any sort of activation process, which is just PTSD really, you can learn from history without always trying to be "battle ready"
14:29 < elichai2> luke-jr: I'm interested to hear why it's  misrepresentation
14:30 -!- jonatack [~jon@37.173.87.1] has joined ##taproot-activation
14:30 < luke-jr> elichai2: because it's not true?
14:30 < harding> luke-jr: that's only missing the ability to activate prior to timeout, which is a nice but (IMO) minor feature.  I don't see the misrepreestation.
14:32 < luke-jr> then maybe that's your problem
14:32 <@michaelfolkson> Noted darosior: I agree
14:32 < luke-jr> if LOT=false advocacy is just based on falsehoods, perhaps there's some way to overcome it
14:33 < elichai2> luke-jr: what is? I'm trying to understand if I misunderstand LOT or not. Assuming miners won't active, is LOT the same as just setting a height and that's it?
14:33 < elichai2> (ie in the worse case)
14:34 <@michaelfolkson> I think Matt, Rusty and darosior and only Lightning people who have been vocal at all so far (correct me if wrong). So good to hear your view roasbeef
14:34 < maybehuman> luke-jr: Don't you think that true turns the maitainers into this weird kind of priests that divine the will of some unmeasureable entitiy named "community"?
14:35 < luke-jr> maybehuman: no
14:35 < maybehuman> If true comes about as some grass-roots setting people actually perform, that's something concrete
14:36 < maybehuman> but if you just have to lobby a handful of people that what you're saying is in fact the will of the community, that doesn't sound good
14:36 < luke-jr> which nobody suggested
14:37 < maybehuman> I mean a true now would create precedent, no?
14:39 < harding> maybehuman: I think we're at a crossroads and whatever choice is made will set a precedent if it results in a clean activation.
14:39 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
14:39 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds]
14:40 < darosior> I agree
14:40 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Ping timeout: 268 seconds]
14:40 < elichai2> darosior: for your question. Assuming I understand correctly and LOT without miners cooperation does mean the same as setting a height and not doing any signaling.
14:40 < elichai2> Then I'm OK with both but prefer LOT=false
14:41 < maybehuman> harding: I think the activation will probably be clean either way, unless we manage to offend enough people with this lot business..
14:41 < harding> maybehuman: I agree that's certainly possible.
14:42 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation
14:42 < darosior> elichai2: technically LOT=true would *force* the signaling (or they get forked off) which a pure flagday would not
14:42 < maybehuman> dariosor: but only for two weeks
14:43 < maybehuman> or rather, one retarget period (which could run a lot longer if many miners are thrown out)
14:44 -!- jonatack [~jon@37.173.87.1] has quit [Ping timeout: 246 seconds]
14:44 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
14:46 -!- jonatack [~jon@37.173.87.1] has joined ##taproot-activation
14:49 < luke-jr> harding: that assumes *any* choice is made; as things stand, it won't be
14:50 < maybehuman> luke-jr if taproot fails because of an inability to decide of this parameter, that would be a precedent
14:51 < darosior> maybehuman: but still better than bluntly going with (hardcoded) LOT=true imho
14:51 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
14:52 < maybehuman> dariosor: just wanted to clarify. "forked off" always sounds very final to me
14:53 < elichai2> darosior: really? That's a deal breaker for you?
14:53 < elichai2> (that's actually an interesting question, how many people would rather not have taproot if it's not via their preferred LOT config)
14:53 < darosior> elichai2: if there is no blatant misbehaviour from miners, going with LOT=true i believe sets a pretty bad precedent
14:54 <@michaelfolkson> elichai2: I tried to get at that when I asked about strong opposition, strong NACKs. That may have been a better way to word it
14:55 < elichai2> darosior As core devs? Sure. As a community? I disagree. (disclaimer, I've ran UASF back in the segwit days)
14:55 < jonatack> achow101: thanks for the preferences summaries at https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
14:55 < harding> luke-jr: I suspect public tolerance for the inability of this group to make a decision will soon evaporate and one or more decisions (possibly conflicting) will be made by groups without our input.
14:55 < jonatack> achow101: maybe add roasbeef to it
14:55 < darosior> I'm biased, too. As people surely need Taproot more than i do. But i'd prefer not to have it rather than having it with a few dozens of people on IRC (assuming no Sybil) could push a hardcoded consensus change to the reference implementation. An UASF should require more
14:56 < darosior> At least to have public and blatant bad will from miners
14:56 < darosior> Which they are very likely going to have anyways
14:56 -!- GreenmanPGI [greenman16@gateway/vpn/protonvpn/greenman16091559] has quit []
14:57 < darosior> not going to*
14:57 <@michaelfolkson> harding: Agreed. I think we have to go with lot=false and plan for the scenario where miners don't activate within say 3 months
14:57 < elichai2> achow101: feel free to also add me as prefer false but OK with both.
14:57 < darosior> jonatack: he was aded to the wiki
14:57 < maybehuman> I mean in the end the activation can't proceed without picking a value, right?
14:58 < darosior> elichai2: adding you to the wiki
14:58 < maybehuman> so failure to pick one would mean it fails
14:58 < harding> maybehuman: the only alternatives to picking a value are giving up on taproot or using a different activation method (e.g. BIP9).
14:58 <@michaelfolkson> I don't see how we can propose lot=true to Core at this point. I think the arguments for lot=true were stronger than some people understood them to be but at some point we have to make a decision
14:59 < maybehuman> but bip9 would basically be picking false, no?
14:59 < jonatack> darosior: which wiki, please? i'm looking at https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
14:59 < elichai2> maybehuman: not necessarily, different people can provide their own patches and users will run different configurations, but I'd really love to avoid that
14:59 < harding> maybehuman: it would certainly be similar.
14:59 < darosior> jonatack: https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
15:00 < maybehuman> elichai2: yes, asking users to pick the value themselves is just begging for a community war
15:00 < jonatack> darosior: thanks
15:00 <@michaelfolkson> As I said earlier today we need to think through that scenario where miners don't activate speedily because getting Core to release lot=true later is going to be just as hard
15:00 <@michaelfolkson> I think it will need to be a UASF community effort again to get a lot=true out
15:01 < maybehuman> michaelfolkson you don't think true could work as a grass-roots effort?
15:01 < elichai2> michaelfolkson: agreed. I talked about it before, having non-Core patches ready
15:01 < maybehuman> i.e. core stays at false and an intolerant minority turns up the heat later if deemed necessary?
15:01 <@michaelfolkson> maybehuman: Not initially if Core is releasing a lot=false version
15:01 <@michaelfolkson> maybehuman: Heat later, exactly
15:02 <@michaelfolkson> Not heat at the same time as the Core release of lot=false
15:02 < darosior> michaelfolkson: " I think the arguments for lot=true were stronger than some people understood them to be" => what do you think about F7, and more generally about setting a precedent ? What benefits do you think would overcome that with LOT=true ?
15:03 <@michaelfolkson> darosior: I think F7 is the strongest argument. If I'm honest I lean on that if looking longer term across multiple soft forks of which we know nothing today
15:03 < roasbeef> maybehuman: yep, it's no diff from BU's "emergent consensus" B.S -- uasf is just applying deterrence theory to soft fork activation, you just need to have the ICBM's ready and within striking range, having them set to fire independent of real world considerations is just promoting warlike thinking in the absence of any real war
15:03 < harding> Dr. Strangelove or how I learned to love LOT=true?
15:03 <@michaelfolkson> darosior: But lot=true makes Taproot as a one-off soft fork much smoother
15:04 < achow101> If you leave you're preference as a comment on the gist, I'll update it to include it
15:04 <@michaelfolkson> (in the case that miners don't activate)
15:04 < roasbeef> lot=false also gives all the service providers and biz's time to prep for more turblent chain conditions if it comes to that
15:04 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
15:05 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
15:05 <@michaelfolkson> roasbeef: I'd actually argue that it is easier to plan around lot=true. No motivation for community coordinated UASFs
15:05 < achow101> darosior: fyi nickler is ok with lot=true, so update the table with that. (I misinterpreted his statement)
15:06 < darosior> achow101: noted
15:06 < maybehuman> michaelfolkson I might have missed that part, why does true make taproot in particular smoother?
15:06 < harding> roasbeef: I don't see that if there's agreement to switch from lot=false to lot=true without changing the other deployment parameters.
15:06 <@michaelfolkson> If we get 6 months into a lot=false it is going to be a pain trying to coordinate a community led UASF (I don't think Core will release lot=true even then)
15:07 <@michaelfolkson> I could be wrong on Core
15:07 -!- debit [~debit@195.181.160.175.adsl.inet-telecom.org] has quit [Ping timeout: 240 seconds]
15:07 < roasbeef> there was never even a release for uasf stuff, it was just all deterrence
15:08 <@michaelfolkson> Whatever, I think it is time to move on with lot=false and prepare as best we can for worst case scenario of miners failing to activate within 3-6 months
15:08 < roasbeef> but then there was an actual tangible "threat"
15:08 < achow101> michaelfolkson: if doing a lot=true is committed to _now_ (with the conditions for doing so partially laid out), then I expect Core will make such a release
15:08 < roasbeef> ppl are just shadow boxing casper rn lol
15:08 < darosior> Arguably we would not even need a release should an UASF be required in 6 months to keep up to the 1y deadline
15:08 < achow101> *doing a lot=true after lot=false
15:08 < achow101> roasbeef: we're suffering from ptsd as a community
15:08 < roasbeef> achow101: bingo, I really don't get it
15:08 < roasbeef> there's no actual threat, just a possible threat in ppl's imaginations
15:08 <@michaelfolkson> I asked about it after a Core dev meeting achow101 and the signs weren't positive for committing to future consensus changes
15:09 <@michaelfolkson> Changing lot to true would be a consensus change
15:09 <@michaelfolkson> Obviously the hope is it is never needed. But you have to prepare for worst in case it happens
15:09 < roasbeef> it's been years ppl, those that impeded things in the past now have 2+ chains they reside on, what's left is those willing to loosely coordinate
15:10 < roasbeef> every soft fork doesn't need to be some commandos on deck type thing
15:10 <@michaelfolkson> It won't be commandos on deck if miners activate of their own accord whether lot is set to true or false
15:10 < darosior> We could still try to agree on some decent threshold. I don't have a non arbirtrary value
15:10 < achow101> michaelfolkson: I think youre question was too general. As I said "with the conditions for doing so partially laid out".
15:10 < darosior> <20% signal in 4month past start ?
15:11 <@michaelfolkson> No commandos on deck in best and likely case roasbeef :)
15:11 < maybehuman> yes, let's leave the commandoes below deck until they're needed
15:13 < maybehuman> like roasbeef said, it's enough to know they're there
15:14 < elichai2> I'm going to sleep. I hope I won't wake up to an active warzone lol
15:15 <@michaelfolkson> Night elichai2
15:17 < maybehuman> yeah, metoo. Good luck figuring it out y'all!
15:17 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
15:18 < jonatack> roasbeef: I agree with you
15:21 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Quit: Ping timeout (120 seconds)]
15:25 -!- brg444 [bdb179f7@189.177.121.247] has joined ##taproot-activation
15:32 -!- benthecarman [~benthecar@2600:1700:201:6e60:215a:15f4:8d5f:c7e3] has joined ##taproot-activation
15:32 -!- benthecarman [~benthecar@2600:1700:201:6e60:215a:15f4:8d5f:c7e3] has quit [Remote host closed the connection]
15:32 < brg444> +1 on everything roasbeef said. glad someone else gets it
15:32 -!- benthecarman [~benthecar@2600:1700:201:6e60:c780:b228:aa09:5ca2] has joined ##taproot-activation
15:34 -!- viaj3ro [5b23d159@p5b23d159.dip0.t-ipconnect.de] has joined ##taproot-activation
15:35 < brg444> the option of UASF and the precedent that comes with last time it was used as a deterrent is just as effective as a code implementation
15:35 < luke-jr> I already have a business out of the blue asking to fund specifically developing/releasing a LOT=true node FWIW
15:35 < luke-jr> [22:58:51] <michaelfolkson> I don't see how we can propose lot=true to Core at this point. I think the arguments for lot=true were stronger than some people understood them to be but at some point we have to make a decision <-- LOT=true is a decision, *just as much* as LOT=false would be
15:36 < brg444> it's a sword of damocles that sits on miners head at a social level regardless of nodes actively running it
15:37 < luke-jr> brg444: that's a flawed concept
15:38 -!- brg444 [bdb179f7@189.177.121.247] has quit [Quit: Connection closed]
15:48 -!- brg444 [bdb179f7@189.177.121.247] has joined ##taproot-activation
15:50 < belcher> luke-jr it would be good if that business would publicly state its view/intention to run code, that information is really valuable
15:52 < brg444> it's not. UASF simply pulled the veil of illusion about mining power of users. Now that the collective understanding of this balance of power has elevated, it's unlikely we'll ever need to enforce UASF again because the incentive system has been set straight already
15:53 < brg444> A few reminder in the form of splint groups of users running lot=true is probably well advised but a network consensus deployment is an absolute waste of time
15:57 < belcher> brg444 yeah thats what i mean, if a business is running lot=true it would be good to know about it publicly, so blocking miners who what they're up against
15:58 < brg444> well the beauty of it is we can make it basically make it up
15:58 < brg444> I know it sounds stupid but how is one to verify
15:58 < belcher> presumably the merchant will put a notice on their website or something
15:59 < brg444> Yeah, and they could still run lot=false in the back if for whatever reason if they're not comfortable with whatever implications of lot=true are
16:01 < brg444> That's what it boils down to, as long as miners get the vague impression that a not-insignificant portion of the network is running lot=true the incentives for them to activate are practically the same as if the entire network does.
16:01 < brg444> For that reason I must insist that Core releasing lot=false is a win win win
16:02 < brg444> Maintains a sane relationship between the developers and miners
16:02 < brg444> Does not alienate valuable Core contributors
16:02 < brg444> Emphasize the user sovereignty/governance narrative
16:04 < belcher> yep thats probably what will happen
16:06 < brg444> I encourage everyone to keep up with their lot=true crusade, especially luke-jr. I would just ask that people consider that we DON'T need Core to buy into this for it to succeed
16:09 -!- syperf [~danie@unaffiliated/syperf] has joined ##taproot-activation
16:10 -!- syperf [~danie@unaffiliated/syperf] has quit [Client Quit]
16:13 <@michaelfolkson> One is allowed to argue for something and discuss something without it being a "crusade".
16:14 < brg444> With all due respect michael it's obvious that some are foaming at the mouth to get the UASF hats out of the closet whatever the reason is
16:15 < brg444> I'd venture to say most of them didn't understand it the first time around so it's not unsurprising they're "out for blood" again because that somehow gives them a false sense of empowerment
16:17 < brg444> Most of what you read is "miners bad/must punish/whip". Granted the PTSD is real but I don't think it's inaccurate to refer it to a crusade the way it's talked about on various venues
16:17 <@michaelfolkson> Maybe some people do want a repeat of 2017, I think you are right there. With lot=false they could (with low probability) still get it. But setting lot=true at the start of a year long period wouldn't have been dramatic or in any way exciting
16:18 < brg444> They could not and it's not reasonable to suggest so. It's just the shell shocked mentality talking.
16:19 <@michaelfolkson> I've mainly been on this channel and the discussion here has been good. I haven't been on Twitter
16:19 < brg444> Gotcha. Fair enough
16:20 <@michaelfolkson> If there is a different vibe on Twitter then we're probably talking at cross purposes
16:20 < brg444> I do agree it seems a little more sane on here although I havent gotten around to participate much unfortunately
16:20 -!- benthecarman [~benthecar@2600:1700:201:6e60:c780:b228:aa09:5ca2] has quit [Ping timeout: 240 seconds]
16:27 <@michaelfolkson> I think you'd have been pleasantly surprised if you had. Calm and reasoned discussion. Meetings are hard once you get into tens or even hundreds of people
16:27 -!- brg444 [bdb179f7@189.177.121.247] has quit [Quit: Connection closed]
16:36 -!- brg444 [bdb179f7@189.177.121.247] has joined ##taproot-activation
16:45 -!- wampum [59244ebd@89.36.78.189] has quit [Quit: Connection closed]
16:50 -!- jonatack [~jon@37.173.87.1] has quit [Read error: Connection reset by peer]
16:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
16:54 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has joined ##taproot-activation
17:04 <@moneyball> Apologies for my question at the wrong section of the meeting earlier, but I am curious to hear the answer. luke-jr mentioned "would a longer timeoutheight make anyone happier with LOT=true?" Isn't a concern with something like bip8(2y, true) that there could be political shenanigans in which miners get pissed about true, do not signal, then we have to wait 2 years for activation.
17:05 <@moneyball> IOW isn't an argument for lot=false is that we'd expect faster activation due to it being less miner-hostile?
17:05 -!- AsILayHodling [1808e479@c-24-8-228-121.hsd1.co.comcast.net] has quit [Quit: Connection closed]
17:10 < harding> moneyball: I think that was discussed in the meeting under slightly different premises.  Let me see if I can extract the relevant log entries.
17:15 < brg444> In the former scenario I'd fully expect a contingent of users to roll out an version with precipitated enforcement if there are any indications the miners are sitting on their hands
17:19 -!- brg444 [bdb179f7@189.177.121.247] has quit [Quit: Connection closed]
17:20 < harding> moneyball: https://gist.github.com/harding/4cad67840f386bfa8bca0b6f325eb6e9
17:30 <@moneyball> harding: thank you. despite my best attempt at following all comments in the meeting that eluded me. this seems like a valid point to me that should be represented in michaelfolkson's summary, perhaps F8?
17:31 < harding> That was a very busy IRC meeting; I'm sure I missed things myself.
17:33 < harding> I think that, if we're going to debate this much further, we probaly need a further subdivision of the points, such as each point having a summary, a list of evidence supporting it, and a list of evidence challenging it.  Though if we end up writing the summa theologica of soft fork activation, I think I'm going to have to find a new hobby.
17:39 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
17:46 < achow101> I expect that any further discussion on lot=true vs false is going to end up going nowhere and just talking in circles
17:46 < achow101> that's almost what happened today
17:50 < stortz> at least we're not gonna get a hard fork called TrueLOTBitcoin
17:56 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed]
18:03 < harding> achow101: agreed.
18:14 < luke-jr> moneyball: I don't agree it is less miner-hostile, and think anyone spreading FUD that it's anti-miner or something should stop or be ignored :/
18:14 < luke-jr> achow101: I think the format was fundamnetally broken today
18:15 < luke-jr> there might be productive ways to discuss it further, but that wasn't going to work
18:15 -!- brg444 [bdb179f7@189.177.121.247] has joined ##taproot-activation
18:20 -!- brg444 [bdb179f7@189.177.121.247] has quit [Client Quit]
18:45 <@moneyball> luke-jr: you think miners will react equally to true or false?
18:46 < luke-jr> moneyball: I don't see why not
18:46 < luke-jr> if not, only because false gives them another option (abort)
18:58 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]
18:59 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
19:45 <@moneyball> luke-jr: right. independent of the argument over whether or not they should have that option, if they feel like it is being taken away, it could have this affect...argument F8
20:34 < luke-jr> moneyball: no, the inverse
20:36 <@moneyball> luke-jr: if miners dislike true, they might then pull political shenanigans and delay activation until the 1 year elapses. in the scenario we're discussing, the miners would've activated much sooner, perhaps inside of 6 months, if false were chosen.
20:49 -!- benthecarman [~benthecar@2600:1700:201:6e60:7e:8074:bcb9:dfe7] has joined ##taproot-activation
20:59 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
22:25 -!- duringo [ad004d5a@173.0.77.90] has quit [Ping timeout: 240 seconds]
23:05 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
23:09 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
--- Log closed Wed Feb 17 00:00:02 2021