--- Log opened Mon Feb 15 00:00:31 2021
01:02 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Quit: WeeChat 2.7.1]
01:10 -!- jonatack [~jon@37.167.240.187] has quit [Read error: Connection reset by peer]
01:14 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
02:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:04 -!- pox [~pox@141.226.243.49] has joined ##taproot-activation
03:12 < pox> If the reason to start with LOT=false for a while is, for lack of a better word, optimism that miners will cooperate in a timely fashion to signal their readiness, then it only makes sense for that time period to be relatively short. If the assumption is that there's already a critical mass of hash power that support activation, and that given the chance miners may positively surprise us and signal much earlier than 1y, then it should be very easy
03:12 < pox>  for them to do the same under a much shorter time constraint (say 2 months), before switching to lot=true. It's just signaling, after all. AFAIK it shouldn't be a huge burden technically to make it happen as a pool operator. IOW, it makes sense to have this period of "cooperative voting", out of good will towards miners, but if it's just a vote then there's no reason to let the process drag on for months.
03:13 < pox> If enough signal during that cooperative period - great. No need to bring out the stick. If not, then that should end the debate about how much good will is really out there, and users and devs should push the change more forcefully with lot=true.
03:13 < pox> just my 2 sats
03:14 <@michaelfolkson> I'm asking everyone to try to compare their thoughts to the arguments in this https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
03:15 <@michaelfolkson> I think you're leaning on F1 and F3
03:17 <@michaelfolkson> Regardless there seemed to be clear consensus on 1 year in the first meeting. So the next meeting to discuss lot=true versus lot=false within a BIP 8(1 year)
03:18 <@michaelfolkson> Core or an independent party can release a lot=true version within that year
03:18 <@michaelfolkson> (assuming lot is initially set to false)
03:19 < pox> I think I'm agnostic about F1. I guess my statement was conditional - *if* there seems to be agreement that this fork won't be as contentious, then it makes sense to limit gestures of good will to some reasonable time frame in which voting can take place, which I think is much shorter than 1y. And yes to F3.
03:21 < aj> pox: a longer timeout allows the deployment to be reconfigured with lockinontimeout=true
03:23 < pox> aj I'm not sure I follow. the version that gets released has lot=false by default and users can change it if they wish. how does a voting system improve by letting members delay their vote for 1 year?
03:24 < aj> none of this is a voting system
03:24 < pox> signalling, sorry
03:25 < aj> miners upgrade their systems to enforce the new rules; and start signalling when they've done so
03:25 <@michaelfolkson> I think you're effectively arguing for "Let's see what happens" in this pox https://en.bitcoin.it/wiki/Taproot_activation_proposals
03:26 < aj> lockinontimeout=true sets nodes to reject blocks that would prevent the soft-fork from activating in the current deployment
03:26 <@michaelfolkson> At least in this iteration we're trying to get consensus around BIP 8(1 year) based on prior discussions and prior meetings
03:27 < aj> with lockinontimeout=false and a long timeout, there is time to evaluate whether things are working sensibly that way, and, if they're not change lockinontimeout to true without changing the timeout, and doing so is compatible between nodes that make that change and nodes that don't
03:28 < pox> and with (false,2m) + (true,1y) miners have 14 months to upgrade (correct?). Isn't that more than enough? (false, 1y) + (true, 1y) gives them 24 months to do the same. IANA miner, but that seems like a rather long time.
03:28 < aj> with lockinontimeout=false and a short timeout, you lose that option, which means that if activation fails, you need to spend time redoing the deployment: waiting for the timeout to be reached to avoid confusion, choosing new startheight/timeoutheight parameters, getting new releases out with those parameters, getting those things installed on miners and economically active nodes that are going to
03:28 < aj> enforce the rules -- essentially all the work you did getting everyone upgraded to the code with the first deployment was wasted and you ahve to do it again
03:28 <@michaelfolkson> You could have a (false, 1 year) and 6 months into that 1 year period Core or an independent part release lot=true version
03:30 < aj> (false, 2021-04) + (true, 2022-04) is essentially the same as just doing (false, 2022-04) to start with then switching that to (true, 2022-04), except if you keep the same timeoutheight nodes that don't upgrade will enforce the rules too
03:30 <@michaelfolkson> Even with (false, 1 year) Taproot could be activated by miners or in an effective UASF before that year is over
03:30 < aj> (false,1y) + (true,1y) means the *same* year, not consecutive ones
03:31 < aj> (start=2020-07, timeout=2021-07, lockin=false) -> (start=2020-07, timeout=2021-07, lockin=true)
03:33 <@michaelfolkson> The start dates wouldn't be the same right?
03:33 < AaronvanW> Think of how the BIP148 client was rolled out to help trigger Segwit activation, _before_ the regular Segwit activation year was over pox.
03:34 <@michaelfolkson> The start of the (true,1y) would be say 6 months later than the start of the (false,1y)
03:35 < pox> sorry, I thought that the notation (false,1y) + (true,1y) implied that the start time of the second period would be 1y after the first.
03:36 <@michaelfolkson> pox: What you describe is an option too with (false,1y) but not the only one
03:37 -!- jonatack [~jon@37.167.240.187] has joined ##taproot-activation
03:37 < aj> michaelfolkson: i wouldn't change the start date. you could bump it past blocks that didn't have enough signalling, but why bother?
03:38 <@michaelfolkson> aj: I guess I'm defining start date as like "release date". Not as how it is defined in the BIP
03:38 < aj> michaelfolkson: ... that seems confusing
03:39 <@michaelfolkson> For people who are using BIP terminology, right I agree
03:39 < aj> much like time handling, omg
03:40 <@michaelfolkson> But the point is that (true,1y) would be released at a later date than (false,1y)
03:40 <@michaelfolkson> Maybe before the 1 year of the (false,1y) is over, maybe not
03:42 < aj> i've been assuming everytime we've talked about changing (false,1y) -> (true,1y) we've been talking about keeping the same startheight and timeoutheight
03:43 < aj> in which case releasing (true,1y) after the 1y is over would be impressively pointless
03:46 < pox> but what point do we agree to switch false to true, if the start height is the same?
03:47 < pox> we don't want to allow miners to delay endlessly, but we also don't want to hurt legitimate stragglers who simply did not upgrade as quickly as the majority
03:47 < aj> when progress has stalled and there's not good reason for it?
03:49 <@michaelfolkson> As much as I hate to say it, if lot=false is chosen we should probably have another meeting to discuss what we think the plan should be for a future lot=true release
03:49 <@michaelfolkson> Who we think should release it and when
03:49 < pox> @michaelfolkson why should it require a different release? isn't it going to be a config flag?
03:50 < pox> aj thanks, I think you've convinced me that (f,1y) makes sense.
03:51 < aj> it's a dangerous thing to set -- if you set it, but most people don't, and the soft-fork doesn't activate, you may find yourself on a dead chain. so providing a "-shoot-myself-in-the-foot=true" config option isn't unanimously liked
03:51 < aj> it's *potentially* a dangerous thing to set, i mean
03:52 <@michaelfolkson> pox: Providing safe defaults is a good idea. And if you are going to change the default it needs a new release
03:52 <@michaelfolkson> Users can change those defaults if they wish (and know what they are doing). But I think most users and miners just want clarity rather than confusion
03:52 < pox> oh you mean a default-changing release, not an option enabling release. got it.
03:53 <@michaelfolkson> If lot=false is set, my preference would be a new release with lot=true set at a later date, right
03:55 <@michaelfolkson> And ideally communication on when that lot=true release will likely be released and by whom
03:56 <@michaelfolkson> But as I said that is probably a topic for another meeting if we choose lot=false in Tuesday's meeting
04:38 < virtu> I prefer to give users an easy option to switch to lot=true to have a core release with lot=true
04:39 < virtu> *to having
04:46 <@michaelfolkson> The downsides to that are some users potentially getting forked off the chain and higher risk of chain splits
04:47 <@michaelfolkson> I get the upsides of that approach (user autonomy over developer authority)
04:47 <@michaelfolkson> User coordination is a very hard problem
04:48 < virtu> I could be wrong, but imo lot=true is a pr disaster waiting to happen
04:49 < virtu> worst case, media goes 'core devs take over bitcoin network by using de-facto monopoly of their software'
04:49 <@michaelfolkson> Discussion for another meeting I think (assuming lot=false is chosen)
04:49 <@michaelfolkson> I get your argument
04:50 <@michaelfolkson> It may be that we think Core should never release lot=true under any circumstances for Taproot or any future soft fork
04:54 <@michaelfolkson> Making decisions based on media perceptions seems terrible to me. But there are valid arguments other than media perceptions for Core not releasing lot=true
04:58 -!- jonatack [~jon@37.167.240.187] has quit [Read error: Connection reset by peer]
05:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
05:54 <@michaelfolkson> What was the history around the release of Bitcoin Core 0.16.3(UASF-SegWit-BIP148)? Did you release this luke-jr?
05:55 <@michaelfolkson> How would I have obtained it if I wanted to run it?
06:02 -!- jonatack [~jon@37.167.240.187] has joined ##taproot-activation
06:14 < waxwing> one thing i do remember is that there were two things people were doing - one was compiling that BIP148 version, and the other was simply changing the version string.
06:15 < waxwing> i remember compiling and running it but sadly i don't remember where i got it from.
06:17 < aj> https://github.com/OPUASF/UASF sounds like the sort of advice that was being passed around, and points to https://github.com/UASF/bitcoin/releases
06:19 <@michaelfolkson> Ok thanks both waxwing aj
06:19 < waxwing> huh  interesting, segwit.party now redirects to buybitcoinworldwide.com/segwit/
06:20 < waxwing> the information on there is mostly correct, happily, apart from some wrong stuff about segwit2x
06:20 < waxwing> sorry that's OT, i know you were just interested in the BIP148 history but got sidetracked :)
06:20 <@michaelfolkson> Ha it is ok
06:20 <@michaelfolkson> I'm looking at https://github.com/OPUASF/UASF. They did a good job on docs and communication
06:21 < waxwing> uasf.co is the same. both those websites were in some sense i now forget, consolidation points of information during the drama. maybe.
06:21 <@michaelfolkson> The shark image is perhaps unnecessary :)
06:22 <@michaelfolkson> But apart from that it seems very good
06:22 < aj> https://web.archive.org/web/20170707062640/http://www.bitcoinuasf.org/ was the site luke linked to in https://medium.com/@lukedashjr/how-you-can-help-ensure-bip148-is-a-success-2fb63bf5114f but all it's download links are redirects the web.archive didn't capture
06:22 < waxwing> i mean we have to wait until he responds, but if i was forced to decide, my memory is that *maybe* luke was the one who hosted a link to the actual BIP148 compatible source that you could compile (??)
06:23 < waxwing> ah that was it, thanks aj
06:46 < luke-jr> virtu: LOT=false while the community says LOT=true would *actually* be Core devs taking over the network; what's worse? FUD (that we're likely to get regardless) or true criticism?
06:46 < luke-jr> michaelfolkson: I think Shaolinfry released Bitcoin Core UASF
06:47 < luke-jr> michaelfolkson: I contributed some fixes, becuase a mixed LOT=false/LOT=true network requires much more code than a pure LOT=true network
06:47 < luke-jr> to ensure the LOT=true nodes can find each other and also safely reorg LOT=false nodes
06:48 < luke-jr> waxwing: I remember lots of people who thought simply changing the version string was enough, and didn't realise they had to upgrade the software too.. that's another scenario in which changing LOT later is dangerous
06:49 < luke-jr> michaelfolkson: I did release Knots with a -bip148 option though
06:51 < harding> luke-jr: how would Bitcoin Core releasing LOT=false when "the community" wants LOT=true being devs taking over the network?  Are you saying that you actually believe devs have the power to take over the network?
06:52 < luke-jr> harding: "attempting to", by releasing rules incompatible with what the community has decided
06:53 < aj> luke-jr: "LOT=false while the community says LOT=true would *actually* be Core devs taking over the network" -- that is absurd
06:54 < luke-jr> aj: it's no different than (eg) including 2X without community support
06:54 < aj> luke-jr: lot=false is strictly superior to not setting activation parameters at all, and not setting activation params would not be taking over the network either
06:54 < harding> Also, when did devs stop being part of the "the community"?
06:54 < luke-jr> harding: part of != entirety of
06:55 < harding> luke-jr: duh, but "the community says" implies speaking with a singular voice.
06:55 < luke-jr> aj: releasing code that is intentionally different from the protocol the Bitcoin economy has chosen, is an attempted hardfork without support
06:56 < luke-jr> harding: that's the nuance; keep in mind my statement is a "what if"
06:57 < luke-jr> harding: it holds only IF "the community says LOT=true"
06:58 < luke-jr> presumably any argument for a LOT=false release should at least include, if not be rooted, in disputing that premise
06:58 < aj> luke-jr: "the community" decided 2x was essential -- they had a meeting about it and got signatures -- and then the core devs rudely refused to implement the upgrade
06:58 < luke-jr> aj: that's a lie
06:59 < harding> luke-jr: that's a perspective without nuance, just like your original statement.
06:59 < aj> luke-jr: do you know how scare quotes work?
07:07 -!- Aliz [~Aliz@46.224.73.163] has joined ##taproot-activation
07:07 -!- Aliz [~Aliz@46.224.73.163] has left ##taproot-activation []
07:12 < sturles> aj: It wasn't an upgrade, it was a hard fork.  I.e. a new coin.  It was implemented – badly – by someone else.
07:16 < aj> sturles: Garzik's company was one of the NYA signatories
07:18 < sturles> There were multiple implementations with various blocksizes, goals and varying success.  Further discussion in #bitcoin-forks.
07:48 -!- jonatack [~jon@37.167.240.187] has quit [Read error: Connection reset by peer]
07:48 -!- jonatack [~jon@37.167.240.187] has joined ##taproot-activation
08:07 <@michaelfolkson> Re "the community": All we can do is what we've done. Reach out to as many people as possible, encourage different people to engage in the discussion, set up meetings encouraging the community to come forward with arguments
08:09 <@michaelfolkson> No single individual can claim to speak for the community. Nor can a single individual claim they know exactly what the community wants
08:10 <@michaelfolkson> So without being certain on what the community wants we attempt to find the most conservative option
08:12 <@michaelfolkson> My personal view is *as a one-off soft fork* LOT=true is more conservative as it avoids the discussion (and follow up meeting(s)) on what should happen assuming miners fail to activate
08:15 <@michaelfolkson> But I understand the argument for looking longer term over multiple soft forks and pushing that bar for setting LOT=true as high as possible and doing everything possible to avoid Core needing to set LOT=true every time
08:17 <@michaelfolkson> It also appears to me that harding, Matt, aj, Greg all prefer LOT=false unless there is overwhelming consensus
08:18 <@michaelfolkson> So from a consensus perspective it seems setting LOT=false is more likely at this point in time
08:26 < luke-jr> sturles: hardforks are not new coins
08:27 < luke-jr> michaelfolkson: I don't see how that follows. LOT=false doesn't have overwhelming consensus either..
08:28 <@michaelfolkson> I guess the choice is setting LOT=true, LOT=false or concluding there is no consensus and resuming again in a few weeks/months time
08:30 < luke-jr> :/
08:31 < luke-jr> or just propose the more popular of the two, and hope the rest of the community says "meh good enough" ? <.<
08:31 <@michaelfolkson> You said you were open to harding's F7 argument and you would think about it before luke-jr. Do you think it is without merit on reflection?
08:32 < luke-jr> not sure still. though even assuming it has merit, I'm not sure it is worth the additional problems LOT=false includes
08:34 <@michaelfolkson> I think that is a reasonable conclusion to come to. Others (Greg, harding) disagree of course
08:36 < harding> I don't think luke-jr being "not sure" is unreasonable.  It sounds very reasonable to me to be even willing to consider alternatives to one's preferred option.
08:40 <@michaelfolkson> Assuming LOT is set to false there is discussion and work to do thinking about how and when a UASF might happen (in the eventuality of miners failing to activate). I hope you'd be willing to help with that in that scenario luke-jr because I have no experience of 2017
08:42 <@michaelfolkson> That's what I mean when I discuss the "cost" of setting LOT to false
08:43 <@michaelfolkson> I get why people argue for it but it has a cost and that cost is likely to fall on the shoulders of who were involved with the UASF of 2017
08:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
08:56 < luke-jr> michaelfolkson: there's a lot more cost than just that
08:56 < harding> I think it'd probably be sufficient just to set the date for a discussion, e.g. 2.5 months after earliest possible activation.  I don't think there's any need to plan further ahead of that until we have actual data about what's happening.  And, besides, there are only limited options thanks to BIP8's recent updates preparing ahead for such eventualities: (1) do nothing because it's become clear that taproot will never activate; (2) do
08:56 < harding> nothing so this attempt at activation fails but try again with a new deployment (e.g. because a bug was found or we need more time to upgrade); (3) encourage people to set LOT=true with existing parameters, including perhaps doing so in Bitcoin Core.
09:02 <@michaelfolkson> We'd want to advise users/the community to not attempt a UASF before that 2.5 month point though right? Attempt that at your own risk type thing
09:02 <@michaelfolkson> This is the second part of that "cost" that Luke refers to :)
09:03 <@michaelfolkson> That's why kicking can down the road and saying we'll work something out after 2.5 months isn't optimal
09:04 <@michaelfolkson> If we could provide a stronger message than that that has been thought through and was well communicated to users/community surely that would be preferable
09:06 <@michaelfolkson> I don't know. Maybe the message "Give miners at least 3 months to activate before considering doing a UASF. At that point we will discuss our options" is sufficient
09:25 < luke-jr> michaelfolkson: no, I meant the costs to changing later, and to having a potential mixed network
09:25 < luke-jr> michaelfolkson: with universal LOT=true, it's as simple as having it set
09:25 < luke-jr> to change it later requires a temporary service bit, and care to node disconnection rules, at the very least
09:26 < luke-jr> as well as educating users on why they need to upgrade to TaprootUASF instead of just Taproot version
09:26 <@michaelfolkson> Gotcha
09:26 < luke-jr> not to mention hightened risk of a shorter deployment timeframe
09:27 < luke-jr> and I bet at least some LOT=false pushers would also fight setting it to true later or ever too
09:27 <@michaelfolkson> I think "pushers" is a touch antagonistic but I agree some would
09:28 <@michaelfolkson> Going to try to be better at highlighting gentle antagonism :)
09:28 < luke-jr> as opposed to those who merely prefer it, not sure a better word
09:29 < luke-jr> oh, another cost: setting it later is actually arguably antagonistic toward miners, and might be harder to get them to run
09:29 <@michaelfolkson> LOT=false enthusiasts
09:29 < luke-jr> or push them back into a face-saving nonsense
09:29 < harding> It seems sufficent to me for Bitcoin Core's release notes to say something like: "The parameters for taproot activation included in this release allow it to expire without activation at block height xxxxxx (approximately <month> 2021).  It is possible to change these parameters in a later release, or in an alternative implementanion, to require activation by that block.  We don't currently think that will be necessary, but we have scheduled
09:29 < harding> a meeting for 2020-mm-dd hh:mm UTC in ##taproot-activation on Freenode to discuss the situation based on the latest available information.  Anyone who chooses to use an alternative implementation that mandates activation is encouraged to take the time to thoroughly understand the risks they are undertaking."
09:30 < luke-jr> harding: that implies LOT=true is risky, which is the opposite
09:30 < luke-jr> LOT=false is risky
09:31 < harding> luke-jr: LOT=true is risky if only a small minority choose it.
09:31 <@michaelfolkson> The point is we can't agree Luke. Some think LOT=true is risky long term, some think LOT=false is risky short term
09:31 < harding> (And miners don't activate.)
09:31 <@michaelfolkson> I think that statement is very good personally harding
09:32 < luke-jr> harding: which is more likely with that action/notice
09:32 < luke-jr> LOT=false is similarly risky no matter what
09:33 <@michaelfolkson> You mean that notice makes it more likely that miners don't activate?
09:33 < harding> Ok.  I've been reminded that I have stuff due today, so I'm gonig to leave.  FYI: this is just to avoid being distracted, not a rage quit or anything.
09:33 -!- harding [quassel@newmail.dtrt.org] has left ##taproot-activation ["http://quassel-irc.org - Chat comfortably. Anywhere."]
09:33 < luke-jr> michaelfolkson: more likely that only a small minority choose LOT=true
09:34 < luke-jr> michaelfolkson: LOT=false is risky both short AND long term
09:35 <@michaelfolkson> That is your view Luke, I know. But others disagree when comparing the relative risks of lot=true versus lot=false
09:37 <@michaelfolkson> The point of the statement is to advise people not to attempt an uncoordinated UASF for say the first 3 months unless they know what they are doing and understand the risks
09:38 <@michaelfolkson> (assuming lot has been set to false)
09:39 <@michaelfolkson> If lot has been set to true, the statement is much less important (maybe even unnecessary) as there won't be a motivation to do an uncoordinated UASF
09:39 <@michaelfolkson> Everyone knows it will activate within a year anyway
09:40 <@michaelfolkson> But at the moment we are struggling to get consensus on either
09:41 < luke-jr> michaelfolkson: that's bad advise
09:42 < luke-jr> even if Core releases with LOT=false, it is still safer for users to just set it true
09:42 <@michaelfolkson> You're going to have to be more specific. What is bad advice? That they should be encouraged to try an uncoordinated UASF within the first 3 months (assuming lot has been set to false)
09:42 < luke-jr> and doing so is automatically coordinated
09:43 < luke-jr> moving the timeoutheight without coordination could be dangerous, but simply setting LOT=true wouldn't be
09:43 <@michaelfolkson> Oh I see what you mean, right. If they just change lot=false to lot=true then they only risk getting forked off at the end of the year
09:44 <@michaelfolkson> The important thing is to not tamper with timeoutheight without coordination, right
09:44 -!- jonatack_ [~jon@37.172.71.30] has joined ##taproot-activation
09:44 < luke-jr> LOT=false has a risk of being forked off too
09:45 <@michaelfolkson> If LOT has been set to false, then everyone changes LOT to true apart from somebody who keeps LOT as false, yes
09:45 <@michaelfolkson> (everyone is a simplification but just trying to make your argument clearer)
09:46 < luke-jr> that part of the risk is identical to both LOT options
09:46 < luke-jr> LOT=false has a heightened risk besides that because of reorg risk etc
09:47 <@michaelfolkson> I don't understand increased reorg risk. Can you explain?
09:48 <@michaelfolkson> In the case of LOT being set to false, there is an increased reorg risk than if LOT had been set to true. How?
09:48 -!- jonatack [~jon@37.167.240.187] has quit [Ping timeout: 272 seconds]
09:48 < luke-jr> michaelfolkson: if the miners split the chain, such that there is a Taproot chain and a non-Taproot chain, the LOT=false miners will follow the non-Taproot chain under some conditions, but abandon it and re-split every time the Taproot chain gets ahead
09:48 < luke-jr> LOT=true nodes will always adhere to the Taproot chain period
09:49 < luke-jr> eg, if anti-Taproot miners have 60% hashrate, their chain split will be followed by LOT=false nodes at first
09:49 < luke-jr> but after N blocks, the Taproot chain will likely push ahead for a bit, and reorg out that entire chain for LOT=false nodes
09:50 < luke-jr> the LOT=false miners will then start a new chain split from that Taproot chain again
09:50 < luke-jr> rinse, repeat, new non-Taproot chain splits every N blocks
09:50 <@michaelfolkson> Ok thanks, I need to think this through. Give me some time to digest please :)
10:17 -!- jonatack_ [~jon@37.172.71.30] has quit [Remote host closed the connection]
10:17 < luke-jr> as for harding's F7, I think it would be resolved and perhaps even better than with LOT=false, to simply publish 0.20.1 in two builds/flavours, one without Taproot activation at all and one with LOT=true
10:17 -!- jonatack_ [~jon@37.172.71.30] has joined ##taproot-activation
10:30 < queip> luke-jr: might want to coordinate that perhaps with distros, for distros that roll out updates
10:31 < queip> then bitcoin package is left as it is, and two separate packages appear, bitcoin-I-want-taproot, bitcoin-I-dont-like-taproot ?
10:40 <@michaelfolkson> Or two builds/flavours LOT=true and LOT=false?
10:41 <@michaelfolkson> There's clear consensus on Taproot activation. Just not on LOT (it appears)
10:54 <@michaelfolkson> I get your suggestion addresses F7 though
11:24 < luke-jr> queip: we actively discourage distros from packaging Bitcoin full nodes, for this and other reasons
11:24 < luke-jr> michaelfolkson: if there is clear consensus, then there is no excuse for LOT=false at all (F7 argues consensus isn't clear)
11:27 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
11:43 -!- jonatack_ [~jon@37.172.71.30] has quit [Remote host closed the connection]
11:47 -!- jonatack [~jon@37.172.71.30] has joined ##taproot-activation
11:54 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
12:06 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
12:07 < maybehuman> luke-jr The point of F7 is more that false relieves Core of having to determine consensus (and of having the final say)
12:10 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Client Quit]
12:11 < luke-jr> O.o
12:11 < luke-jr> but it doesn't
12:11 < luke-jr> it doesn't relieve anything, nor does Core have final say ever
12:15 < luke-jr> all it does is remove a (misguided) blame if Core were to error
12:16 < luke-jr> whoever releases it still needs to determine that there is consensus (regardless of LOT)
12:16 < luke-jr> and for it to have any effect, users still need to choose to upgrade to it
12:18 < luke-jr> tbh if there is an error with devs determining consensus honestly, blame really belongs with the objectors who failed to raise attention to their objection; but to the extent that anyone else can be blamed, it's no more devs than it is users regardless of LOT
12:19 < luke-jr> so I guess in a sense, F7 is a kind of washing our (devs) hands of responsibility, but doesn't really change the responsibility XD
12:55 -!- Alexandre_Chery [9466a0bc@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.160.188] has joined ##taproot-activation
12:56 -!- Alexandre_Chery [9466a0bc@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.160.188] has quit [Client Quit]
14:09 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
14:41 -!- harding [quassel@newmail.dtrt.org] has joined ##taproot-activation
14:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
14:54 -!- Alexandre_Chery [9466a0bc@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.160.188] has joined ##taproot-activation
14:55 -!- Alexandre_Chery [9466a0bc@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.160.188] has quit [Client Quit]
15:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
15:49 -!- belcher_ is now known as belcher
16:09 -!- Alexandre_Chery [9466a0bc@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.160.188] has joined ##taproot-activation
16:13 -!- Alexandre_Chery [9466a0bc@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.160.188] has quit [Client Quit]
17:00 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
17:01 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
17:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
17:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
17:59 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:02 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
18:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
18:50 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 268 seconds]
18:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]
18:55 -!- mol [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
18:56 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
19:47 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has quit [Quit: ZNC 1.8.0 - https://znc.in]
19:48 -!- sanket1729 [~sanket172@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation
20:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
21:20 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
21:44 -!- jonatack_ [~jon@37.173.9.3] has joined ##taproot-activation
21:47 -!- jonatack [~jon@37.172.71.30] has quit [Ping timeout: 264 seconds]
22:17 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
22:19 -!- _0x0ff- [~potatoe@163.172.166.225] has joined ##taproot-activation
22:19 -!- _0x0ff [~potatoe@unaffiliated/0x0ff/x-1210984] has quit [Read error: Connection reset by peer]
22:21 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
22:23 -!- _0x0ff- [~potatoe@163.172.166.225] has quit [Client Quit]
22:24 -!- _0x0ff [~potatoe@163.172.166.225] has joined ##taproot-activation
22:24 -!- _0x0ff [~potatoe@163.172.166.225] has quit [Changing host]
22:24 -!- _0x0ff [~potatoe@unaffiliated/0x0ff/x-1210984] has joined ##taproot-activation
22:25 < pox> aside from the subtle issue of not activating too early in case there's a very sudden rush to activate by an overwhelming % of hash power (i.e. just setting a minimal blockheight for activation, so legitimate laggards have time to upgrade), it seems sensible to me to release the first (false, 1y) version at time T, and announce that exactly 3 months later, unless activation has already occurred, a version with (true, 1y) is going to be released.
22:26 < pox> this equates to (correct me if I'm wrong): miners have at least 3 months to upgrade, but at most 1y before the upgrade is forced on them. whoever wants to change lot=true earlier could, but 99.9% of users won't even know about it and wouldn't.
23:07 -!- jonatack_ [~jon@37.173.9.3] has quit [Ping timeout: 256 seconds]
23:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
23:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
23:59 -!- pox [~pox@141.226.243.49] has quit [Quit: pox]
--- Log closed Tue Feb 16 00:00:31 2021