<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small;color:#000000">We had a very productive meeting today. Here is a summary of the meeting -- I've done my best to<br>summarize in an unbiased way. Thank you to everyone who attended.<br><br>1. On the use of a speedy trial variant:<br><br>- There are no new objections to speedy trial generally.<br>- There is desire to know if Rusty retracts or reaffirms his NACK in light of the responses.<br>- There is an open question of if Rusty's NACK remains if it is sufficiently addressed.<br>- There is no desire to wait for Rusty's response if he does not respond (but please don't leave us in suspense).<br><br><br>2. Selecting between heights and MTP:<br><br>- There is not robust consensus on either<br>- There are two NACKs, one (luke-jr) against MTP, one (jeremyrubin) against height. More on this in<br> agenda item 5.<br>- No one has an issue with the technical safety of MTP/heights on their own.<br>- There is an open question of the additional review required to ensure height based activation is<br> safe.<br><br>3. Parameter Selection<br><br>- There is broad agreement that we should target something like a May 1st release, with 1 week from rc1<br> starttime/startheight, and 3 months + delta stoptime/stopheight (6 retargetting periods), and an<br> activation time of around Nov 15th.<br>- If we select heights, it looks like the first signalling period would be 683424, the stop height<br> would be 695520.<br>- If we select times, we should target a mid-period MTP. We can shift this closer to release, but<br> currently it looks like a 1300 UTC May 7th start time and stop time would be 1300 UTC August 13th.<br>- The activation height should be 707616 (about Nov 15th) for either proposal.<br><br>(please check my math, if anyone is superstitious we can add a day to times...)<br><br>4. Parameter Flexibility<br><br>- We may wish to adjust the schedule a little bit -- either back 1 signal, or up 1 signal.<br>- There's concurrence that regardless of pushing the start or stop dates, we should hold the<br> November 15th date steady as slipping past Thanksgiving turns to Christmas turns to New Years<br> turns to Chinese New Year and we're looking at March as the next date people would want to<br> schedule.<br>- There's concurrence that as long as we're getting to a release sometime in May (with a very strong<br> preference for Mid-May as opposed to End of May) that we don't need to re-evaluate. There's<br> limited belief that we could stretch this into June if needed.<br>- There's belief that we should be able to get a release with ST Taproot on the timeline suggested<br> by topic 3.<br><br>5. Simultaneous UASF*<br><br>- luke-jr believes that a UASF client must be able to release before the ST client releases in<br> order for people to use it<br>- no one else in attendance seemed to share this sentiment, a UASF can proceed independently of ST.<br>- UASF is compatible with a MTP based ST by selecting whatever height the ST MTP started at<br> (and a stop height farther in the future with LOT).<br>- luke-jr NACK of ST MTP: ST with MTP means that UASF must release after ST releases, which limits<br> UASF adoption.<br>- jeremyrubin NACK of ST Height: if using height means that we'd see a marketed push to launch a<br> UASF client before ST is given a chance, ST fails its goal for avoiding contentious forks.<br><br>* For the avoidance of doubt, theUASF client would include logic to be compatible with ST's minimum<br> activation height and may be variously called a "UASF", "BIP8 LOT=true w/ minactiveheight for ST<br> compatibility", "ST + BIP8", or some other combination of phrases in different places<br><br>Best,<br><br>Jeremy</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">--<br><a href="https://twitter.com/JeremyRubin" target="_blank">@JeremyRubin</a><a href="https://twitter.com/JeremyRubin" target="_blank"></a></div></div></div></div>