--- Log opened Fri Mar 05 00:00:47 2021
00:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
00:34 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##uasf
00:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
00:46 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##uasf
07:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
07:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##uasf
07:24 -!- mol [~mol@unaffiliated/molly] has joined ##uasf
07:26 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 245 seconds]
08:55 -!- ajonas [sid385278@gateway/web/irccloud.com/x-vbqmiwqebvrkdcvc] has joined ##uasf
10:54 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has quit [Ping timeout: 272 seconds]
11:06 -!- cguida [~cguida@2806:2f0:51c1:5cee:4183:71f4:847c:b4d9] has joined ##uasf
12:02 -!- stortz [b1982408@177.152.36.8] has joined ##uasf
12:08 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
12:15 -!- stortz [b1982408@177.152.36.8] has joined ##uasf
12:32 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
13:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
13:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##uasf
13:29 -!- Teleportando [8eb30758@d142-179-7-88.bchsia.telus.net] has joined ##uasf
13:42 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 245 seconds]
13:42 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
14:27 -!- Teleportando [8eb30758@d142-179-7-88.bchsia.telus.net] has quit [Quit: Connection closed]
14:46 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds]
14:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
14:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##uasf
14:53 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##uasf
14:53 < proofofkeags> which PR's need to be reviewed first?
14:56 < proofofkeags> afaik, the one in question was https://github.com/bitcoin/bitcoin/pull/19573
14:56 < proofofkeags> but it looks like there are conflicts with the target
14:58 <@michaelfolkson> proofofkeags: From earlier in the channel
14:58 <@michaelfolkson> "#19573 won't be merged into Core (I've recommended it be closed actually) but it is pretty much all the code that will eventually be merged into the UASF repo. So if you are interested in reviewing and testing UASF that is definitely good to look over"
14:58 <@michaelfolkson> "If you want to help Core move along #21334 is the first attempt at stripping out some of the commits in Luke's PR into separate PRs"
15:00 < proofofkeags> OK. I'm primarily interested in helping the UASF client along. Luke said that 19573 was the first course of action. If you think that is wrong, does that mean we need 21334 to go into core before rebasing the Activation fork?
15:02 <@michaelfolkson> The plan we have discussed so far is building on top of Core 0.21 release rather than Core's latest master
15:04 <@michaelfolkson> But if tests get merged into Core, we can cherry pick those test commits on top of 0.21
15:05 <@michaelfolkson> I don't think Luke is planning to rebase his Core PR on top of latest Core master if that's your question
15:06 <@michaelfolkson> Btw there is also a new activation method that is being discussed in ##taproot-activation currently which seems to be gathering some steam. No code yet though though the author (Russell O'Connor) has said he's happy to code it up
15:07 <@michaelfolkson> A fail fast (3 months) activation method so if it fails we could resume with the UASF plan
15:09 <@michaelfolkson> (without a long delay)
15:23 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
15:27 < proofofkeags> I'm supportive of that
15:29 <@michaelfolkson> Cool, we'll see where it goes in next few days. If it gathers momentum and looks like it could work we could pause the UASF plan until a point where that has failed (or looks like it will fail)
15:30 < proofofkeags> yeah my argument has always been that L=F is somewhat of a farce. but it does have the ability to activate, and if it appeases the conservative folks to the point where they are willing to sign onto a UASF afterwards, then let's do it
15:31 <@michaelfolkson> Agreed
15:32 < proofofkeags> in fact I think I even brought something like that up at one of the original taproot activation meetings, though I suggested 6mo/6mo. But this is better. short optimistic upgrade path, and longer timeline for the riskier play
15:33 < proofofkeags> in the mean time, so as not to stall out, I'm reviewing 21334 right now, and I'll take a look at roconnor's PR should it materialize
15:35 <@michaelfolkson> Cool, I think 21334 could be merged into Core even if this fail fast activation method was pursued. Still discussing details on whether it will be closer to BIP 8 or BIP 9
16:54 < luke-jr> proofofkeags: 21334 is part of 19573
16:54 < luke-jr> proofofkeags: best to review 21334 as-is, and review the rest of 19573 on top
17:09 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 260 seconds]
17:25 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
17:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##uasf
18:12 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined ##uasf
18:16 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 276 seconds]
18:26 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##uasf
18:28 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 265 seconds]
18:28 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 256 seconds]
19:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##uasf
19:06 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Read error: error:1408F10B:SSL routines:ssl3_get_record:wrong version number]
19:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##uasf
19:09 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
19:33 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Quit: leaving]
19:45 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
20:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
20:15 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##uasf
20:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
21:49 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 276 seconds]
22:49 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:49 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
23:27 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##uasf
23:28 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
23:55 < maaku> What's the logic of a 3-mo activation window? That's just weird to me.
23:56 -!- cguida [~cguida@2806:2f0:51c1:5cee:4183:71f4:847c:b4d9] has quit [Ping timeout: 272 seconds]
23:57 < maaku> A long LOT=false activation window still allows for a bip-91 like activation if/when UASF happens, or a conversion to LOT=true in a later release
23:58 < maaku> I mean, it seems sensible to do even a 5-year LOT=false activation window in Core, if they want to kick the can, which makes all more aggresive activation options safer
23:59 < maaku> UASF? force the bit to be set by the UASF deadline.
23:59 < maaku> change to LOT=true? force the bit to be set the window before LOT=true
--- Log closed Sat Mar 06 00:00:45 2021