--- Log opened Sat Mar 06 00:00:45 2021
--- Day changed Sat Mar 06 2021
00:00 < maaku> luke-jr: wouldn't framing it this way address your concerns about LOT=false?
00:01 < maaku> it's not ceding any control to the miners. it's just saying we haven't chosen *yet* by which mechanism we'll force activation, if need be
00:05 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
00:07 -!- cguida [~cguida@2806:2f0:51c1:5cee:5aed:6fc2:e93a:5ee0] has joined ##uasf
00:08 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
00:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
00:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
00:51 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
00:52 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
01:32 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:33 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
01:41 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:41 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
01:46 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:46 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
01:54 < nothingmuch> maaku: if it's long, isn't it more logical to set LOT=true?
01:58 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
01:58 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
02:10 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
02:10 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
02:25 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
03:21 <@michaelfolkson> maaku: Before this "fail fast" proposal for Core we were kind of in this bind where Core didn't want to lay out a timetable (or were unable to) but also didn't want to have a timetable dictated to them from say UASF.
03:22 <@michaelfolkson> maaku: A couple of days ago "brinksmanship" and "game of chicken" were being discussed
03:23 <@michaelfolkson> maaku: Personally I don't think it is helpful. We've had open to all meetings engaging the community for this very reason
03:25 <@michaelfolkson> maaku: But, whatever. With this "fail fast" proposal if it fails we go back to the situation we were in a couple of days ago with UASF happy to release a BIP 8(1 year, LOT=true) and Core deciding whether they want to release a BIP 8(1 year, LOT=false) that runs in parallel or not
03:28 <@michaelfolkson> And in that scenario we've only lost 3 months. In that time UASF can prepare a release for the end of those 3 months or just wait those 3 months out
04:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##uasf
04:16 -!- belcher_ is now known as belcher
04:16 <@michaelfolkson> Taproot activation proposal "Speedy Trial" on the mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018583.html
04:17 <@michaelfolkson> Personally I ACK it. I think proofofkeags ACKs it. If you have opposition to it please raise it in ##taproot-activation or on the mailing list.
05:43 < _andrewtoth_> maaku I suggested a BIP8 infinite timeout as well. People object to Core releasing software that will allow other users to be unwitting pawns in a uasf is my view of why.
05:47 -!- mol_ [~mol@unaffiliated/molly] has joined ##uasf
05:50 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
06:13 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
08:24 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
09:51 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##uasf
10:07 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
10:14 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
11:09 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
11:09 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
11:12 -!- stortz [b1982408@177.152.36.8] has joined ##uasf
12:45 <@michaelfolkson> If you support ST (Speedy Trial) proposal please ACK this so we can log the level of support for this proposal https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f
14:05 -!- adam3us_ [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has joined ##uasf
14:06 -!- adam3us_ is now known as hashcash
14:12 -!- hashcash is now known as h4shcash
14:35 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has quit [Remote host closed the connection]
14:38 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has joined ##uasf
14:54 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
14:54 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
15:13 < maaku> I don't have skin in this game, but I think it's a waste
15:13 <@michaelfolkson> maaku: What's a waste?
15:14 < maaku> waste of time and effort. the "speedy trial" thing
15:15 <@michaelfolkson> maaku: Because you think it has a good chance of failing?
15:16 < maaku> Yes it has a nontrivial chance of failing at which point you have to reset all the engineering & process effort for a new set of parameters
15:18 < maaku> rather than a longer LOT=false window which basically says "IF tapoot activates, it will be by high-threshold MASF signalling. But whether that is done by miners or forced by a lower threshold lockin or window ending forced activation or UASF, is TBD"
15:35 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Remote host closed the connection]
15:35 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has quit [Remote host closed the connection]
15:58 <@michaelfolkson> maaku: Maybe you're right, who knows. We can have a UASF ready for the end of "Speedy trial".
15:58 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 245 seconds]
15:59 <@michaelfolkson> At this point, even giving the miners a chance to activate will be a win. I'm exhausted
16:01 -!- mol [~mol@unaffiliated/molly] has joined ##uasf
16:10 < windsok> Thanks for all of your efforts @michaelfolkson,  it's appreciated
17:12 < luke-jr> michaelfolkson: considering ST seems to not have reached consensus anyway, IMO we should just push forward with the original plan
17:44 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
17:45 < jeremyrubin> luke-jr: the only thing I'd recommend is to at least give it a week or two to form consensus, that LOT=true UASF might proceed anyways during ST seems to be a chief complaint about ST, no need to fuel the flames
17:57 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined ##uasf
18:00 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 276 seconds]
18:09 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##uasf
18:09 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
18:10 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##uasf
18:11 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 264 seconds]
18:55 < luke-jr> jeremyrubin: another week and the current LOT=True activation parameters are no longer reasonable
19:00 < jeremyrubin> hmm
19:06 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
19:06 -!- belcher [~belcher@unaffiliated/belcher] has joined ##uasf
19:07 < luke-jr> michaelfolkson: maybe Mon/Tue we should have a meeting to discuss revising the parameters in light of non-progress (with a note that no topics other than BIP8(True) will be entertained unless they have evidence of potentially broader community support?)
19:18 < nothingmuch> jeremyrubin: isn't the concern with a UASF that forces signalling during the ST activation window?
19:28 < nothingmuch> to be clear, it's not the deployment of a UASF during ST that is the problem, is it?
19:30 < nothingmuch> if i'm not mistaken bip8(1y, true) modified with minimum activation height should be compatible, because by the time MUST_SIGNAL kicks in ST will have failed, but if ST works then this bip8 variant should follow the ST chain
19:30 < AaronvanW> nothingmuch: matt's concerned about UASF before the end of ST, but that hasn't been considered in this channel afaik.
19:32 < nothingmuch> AaronvanW: still ambiguous, sorry.. i understood Matt's concern as a UASF that times out/forces signalling before the end of ST - but i don't think such a UASF was considered here, right?
19:33 < AaronvanW> right
19:35 < mol> i think for now UASF should just back off and let ST play out
19:36 < nothingmuch> mol: for perception or technical reasons?
19:36 < mol> both
19:37 < nothingmuch> so please explain the latter, as i don't see a technical argument against (but i do understand the perceptions based argument)
19:37 < mol> doesn't ST take care of the technical part?
19:40 < nothingmuch> what i mean is a UASF could ship now, so long as during the ST activation period it activates in the same way (min activation height change), and the UASF-ness would only play out long after ST timed out
19:40 < nothingmuch> so anyone running such a UASF client would be supporting ST
19:42 < mol> then maybe put it under a different name than UASF?
19:43 < nothingmuch> sure, and there's other perceptions reasons to consider not shipping that
19:43 < luke-jr> mol: "UASF" was never really in the name :P
19:43 < luke-jr> this channel just happened to be open to planning purposes
19:46 < nothingmuch> one technical issue is startheight vs. startdate - for bip8+min-activation-height to be compatible with ST they would need to consider the same signalling periods
19:47 -!- stortz [b1982408@177.152.36.8] has joined ##uasf
19:47 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has joined ##uasf
19:48 < nothingmuch> roconnor's mailing list post used bip8 parameters, but aj's PR keeps bip9, seems like compatibility between a longer timeout bip8 and ST would be to make sure ST uses block height
19:49 < nothingmuch> sorry, compatibility between a longer timeout bip8+min-activation-height and ST
19:53 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has quit [Ping timeout: 272 seconds]
20:49 < jeremyrubin> nothingmuch: I think we can use a activation height instead of time
20:50 < jeremyrubin> ST = BIP9 + active height would work with BIP8
20:50 < nothingmuch> jeremyrubin: i thought so too initially but i think startheight is also potentially an issue, if the 1st signalling period doesn't match
20:54 < nothingmuch> e.g. suppose ST starts before bip8 startheight, and locks in during that period
20:57 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
20:58 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
21:27 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
21:54 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 260 seconds]
22:00 -!- cguida [~cguida@2806:2f0:51c1:5cee:5aed:6fc2:e93a:5ee0] has left ##uasf []
22:03 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:2075:9321:d3a2:809] has joined ##uasf
22:30 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has joined ##uasf
22:35 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has quit [Ping timeout: 260 seconds]
23:17 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
23:33 -!- mol [~mol@unaffiliated/molly] has joined ##uasf
23:35 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has joined ##uasf
23:39 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has quit [Ping timeout: 258 seconds]
23:41 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
--- Log closed Sun Mar 07 00:00:49 2021