--- Log opened Sun Mar 07 00:00:49 2021
00:17 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-activation
01:39 -!- rubikputer [~rubikpute@ip72-192-27-21.ri.ri.cox.net] has quit [Ping timeout: 246 seconds]
02:26 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 245 seconds]
02:37 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has joined ##taproot-activation
02:38 < h4shcash> can we please use block height activation not time. why regress on this after the work that went into bip8
02:46 < aj> h4shcash: because the work on bip8 is not finished / has not passed review, and the benefits of height vs time for a speedy trial are minimal
02:47 < h4shcash> aj height can be substituted outside of bip8 also. have a look at the github there are a dozen requests for height
02:48 <@michaelfolkson> aj: You will need to convince one of the BIP 9 authors to change the BIP. One of the authors (Rusty) has already declared BIP 9 "dead".
02:48 < aj> god, the bikeshedding here is fantastic
02:48 < h4shcash> we're already being pragmatic no need to get minimalistic. we do want to progress activation technology
02:49 < h4shcash> aj it's not bikeshedding - *look at the github* there's a vast majority asking for block height
02:49 <@michaelfolkson> aj: If you are intending on changing BIP 9 can you contact the authors (Pieter, Peter, Greg, Rusty) and see if one of them would be happy to change the BIP. If they wouldn't BIP 9 is indeed dead
02:49 < h4shcash> aj ps thanks for putting the work in to make the patch
02:50 < aj> michaelfolkson: whether it's called "bip 9" or "bip 42069" doesn't matter even slightly
02:51 <@michaelfolkson> aj: It doesn't but it causes confusion. We have had months of discussion and consensus around BIP 8 and there's no reason to try to revive BIP 9
02:52 < aj> michaelfolkson: there is very clear opposition to bip8, which by definition means there hasn't been months of consensus
02:52 <@michaelfolkson> aj: From you?
02:53 < aj> michaelfolkson: from Matt and more recently from Luke
02:53 <@michaelfolkson> Luke does not oppose BIP 8. So that just leaves Matt
02:53 < aj> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018498.html
02:54 <@michaelfolkson> He doesn't support LOT=false. BIP 8 can be used without LOT=false
02:55 <@michaelfolkson> Suhas doesn't support LOT=true. BIP 8 can be used without LOT=true
02:55 < aj> okay, i'm done with this channel
02:55 -!- aj [aj@cerulean.erisian.com.au] has left ##taproot-activation []
02:57 < h4shcash> aj no there is no opposition to bip8, there was lack of consensus on parameters for bip8
03:01 < h4shcash> just for the record https://github.com/bitcoin/bitcoin/pull/21377 has various levels of support for height from roconnor, benthecarman, JeremyRubin, michaelfolkson, harding
03:02 < h4shcash> plus people who have said the same thing here.
03:07 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
03:08 <@michaelfolkson> Can you ACK/NACK this please h4shcash? https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f
03:11 -!- nothingmuch [~nothingmu@unaffiliated/nothingmuch] has left ##taproot-activation []
03:12 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has quit [Remote host closed the connection]
03:15 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds]
03:44 <@michaelfolkson> I think on the BIP front we need a new BIP number luke-jr where he can put harding's email
03:46 <@michaelfolkson> I don't want to disrupt the development effort and if we can all refer to this new BIP we don't come up against this clinging to BIP 9, squeamishness about LOT thing
03:48 <@michaelfolkson> There is old BIP 9 code in the repo, that is true. But the block height thing is smoke and mirrors it appears. There seems broad consensus on block height
03:49 <@michaelfolkson> I think people just don't want to say they're using BIP 8. And as it stands ST doesn't fit into the template of BIP 8 so if that is what is causing all the drama let's have a new BIP for ST
03:49 <@michaelfolkson> Can you allocate a new BIP number luke-jr?
03:52 <@michaelfolkson> BIP 8 will be the BIP UASF goes to if and when it ever needs to release anything
03:53 <@michaelfolkson> And for longer deployments too e.g. 1 year
03:59 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 260 seconds]
04:37 <@michaelfolkson> I don't use Twitter but if someone could post this on Twitter it would be really helpful. Thanks https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f
05:10 -!- eoin [33255570@51.37.85.112] has joined ##taproot-activation
05:20 -!- eoin [33255570@51.37.85.112] has quit [Quit: Connection closed]
05:23 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
05:28 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 276 seconds]
05:32 -!- eoin [33255570@51.37.85.112] has joined ##taproot-activation
05:39 < pox> just putting it out there: "spaghetti activation" is a better name for a method whereby you throw something against the wall to see if it sticks.
05:44 <@michaelfolkson> pox: If you have a specific criticism of the proposal please outline it. I don't think the name should be the top priority personally
05:45 <@michaelfolkson> I actually preferred Trial Balloon but I lost out on that one unfortunately
05:48 < pox> no criticism. I like it. pretty sure I advocated for it in the first irc meeting...
05:49 <@michaelfolkson> pox: Ok cool. I was expecting some criticism. Can you ACK/NACK the gist if you haven't already?
05:50 < pox> but a catchy name goes a long way ;) I mean if we agree softfork activation methods lack a Schelling point...
05:56 < waxwing> been doing a little more reading, i can see there is some meaningful difficulty in figuring out the height vs time based, and bip9/bip8, but .. can we not consider that discussion orthogonal?
05:57 < waxwing> i mean, if there is agreement on ST, then surely that is a separate technical (uhh even more technical) question, that is best left to those devs actually involved in implementation
05:57 < waxwing> if it ends up causing a bit more delay, so be it, right, but it's a technical implementation issue as far as getting agreement on ST right?
05:57 < waxwing> or am i wrong?
05:59 -!- eoin [33255570@51.37.85.112] has quit [Quit: Connection closed]
05:59 < roconnor> It is orthongal.  The only reason not to do height-based is that it hasn't passed review, and it isn't Monday yet so Andy hasn't made a PR.
06:00 < roconnor> once it passes review, height-based will be good to go.
06:01 -!- eoin [33255570@51.37.85.112] has joined ##taproot-activation
06:02 -!- eoin [33255570@51.37.85.112] has quit [Client Quit]
06:07 <@michaelfolkson> Code wise I completely agree roconnor (and code is the most important thing). BIP wise (less important but still needs sorting out) it is a choice I think between adjusting BIP 8 or doing a new BIP with a new BIP number. I think the latter is preferable
06:07 <@michaelfolkson> I've asked Luke for a new BIP number
06:11 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
06:44 < roconnor> Techically the activation method goes into the taproot bip, and doesn't have to be BIP8 or BIP9.
06:44 < roconnor> It could be a whole cloth novel activation method.
06:44 < roconnor> It could be "BIP8 with an activation_height ...."
06:44 < roconnor> ... or it could be a new BIP number. :D
06:45 < roconnor> that's okay too.
06:46 <@michaelfolkson> I think it could be used again for another soft fork (regardless of whether it is used for Taproot). In which case it needs a new BIP number
06:46 < roconnor> needs is strong, but yes, it would be better.
06:46 <@michaelfolkson> Agreed
07:18 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
07:19 < luke-jr> "let's start review on something new from scratch so that we don't have to finish review on something else and sew FUD about it later" is not a convincing argument for ST
07:20 < luke-jr> frankly it's starting to feel similar to the "LOT=false now, LOT=True later" delay tactic from people who intend to never accept LOT=true anyway
07:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 276 seconds]
07:21 < mol_> luke-jr, how do you know they'll never accept lot true? this kind of negative attitude drives people away
07:22 < luke-jr> mol_: which are you asking about? the latter group already showed their true colours a week ago.. I think Matt even stated it explicitly at one point
07:23 < luke-jr> mol_: the former is lacking in any other apparent motivation
07:34 < mol_> luke-jr, Matt is only one individual, can you get past that and focus on how many others who would support lot true?
07:45 < luke-jr> mol_: that aspect is true with a height-based ST too
07:46 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
07:51 < roconnor> we should probably save the hand-wringing over height-based vs time-based activation until Tuesday, because we should have two PRs by then.
07:52 < mol_> roconnor, agreed
08:23 -!- jonatack [~jon@37.166.13.194] has joined ##taproot-activation
08:48 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Read error: No route to host]
08:49 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
08:50 < harding> michaelfolkson: did you not notice that in https://github.com/bitcoin/bitcoin/pull/21377/commits/ac32b42a4c9f950b87d86da087c4c08a506c942a , if you ignore the boilerplate and changes for the tests, the entirety of aj's main patch is one single conditional, 3 SLOC?  "if (pindexPrev->GetMedianTimePast() >= activation_time) { stateNext = ThresholdState::ACTIVE; }"  That's a much easier review than (all of BIP8 plus changes to BIP8) and it's
08:50 < harding> based on activation code that's already been used for two deployments.  (There's an additional change to lower the threshold from 95% to 90%, but that's a one-line diff and even more trivial to review.)
08:50 < jeremyrubin> harding: also that line can be changed, i believe, to use height instead without any issue
08:51 < jeremyrubin> so while the start/stop times might be time based, we could still activate at a given height
08:51 < harding> jeremyrubin: yes, I think so.  I'm not sure I understood the code correctly, but if I did, I described an advantage of using height for the minimum activation "time" on the PR.
08:51  * harding needs to test on regtest
08:55 < jeremyrubin> easier to be compatible with BIP8
08:57 < harding> jeremyrubin: not really?  Since a minimum activation parameter is outside of both, both require a change and both use the same cache (e.g. BIP8 has access to MTP as well, right?), so it's the same code in roughly the same place in either case, whether time or height is used.
08:57 < harding> outside of both BIP specifications*
09:09 -!- grubles [~unknown@unaffiliated/grubles] has quit [Quit: leaving]
09:17 -!- Netsplit *.net <-> *.split quits: harding, Ed0, kallewoof, Jackielove4u, meshcollider, common, felixweis, windsok, gambpang, jakesyl,  (+4 more, use /NETSPLIT to show all of them)
09:18 -!- GoldmanSats__ [sid428607@gateway/web/irccloud.com/x-pwoqqyjahamqotut] has joined ##taproot-activation
09:18 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-dbzehdhvocdorzdc] has joined ##taproot-activation
09:18 -!- wangchun_ [sid444603@gateway/web/irccloud.com/x-ebebzytnzwjmdvzd] has joined ##taproot-activation
09:18 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-vulfyaligsvkvsgx] has joined ##taproot-activation
09:18 -!- felixweis [sid154231@gateway/web/irccloud.com/x-evpcjxrvwezwuhkm] has joined ##taproot-activation
09:19 -!- Netsplit over, joins: harding
09:19 -!- elichai2_ [sid212594@gateway/web/irccloud.com/x-kihpwryyqmknulan] has joined ##taproot-activation
09:20 -!- Netsplit over, joins: Ed0
09:20 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-pujlhgfqfxywpwkm] has joined ##taproot-activation
09:20 -!- jamesob [sid180710@gateway/web/irccloud.com/x-dtaufpvopijylqfh] has joined ##taproot-activation
09:20 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-jljxbfujiusanifg] has joined ##taproot-activation
09:20 -!- windsok [~windsok@rarepepe.cash] has joined ##taproot-activation
09:20 -!- Netsplit over, joins: kallewoof, common
09:20 -!- elichai2 [sid212594@gateway/web/irccloud.com/x-pujlhgfqfxywpwkm] has quit [Max SendQ exceeded]
09:20 -!- elichai2_ is now known as elichai2
09:21 -!- Netsplit over, joins: gambpang
09:21 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-picdnuilgvdpnvxm] has quit [Ping timeout: 265 seconds]
09:23 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-activation
09:23 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-yxzngaxpgqqcgfbv] has quit [Ping timeout: 268 seconds]
09:24 -!- amptwo [segwitmatr@gateway/shell/matrix.org/x-jamlgibvzxfqznqg] has quit [Ping timeout: 246 seconds]
09:25 -!- timeerrr[m] [timeerrrma@gateway/shell/matrix.org/x-xhsqoicdwuaiusux] has quit [Ping timeout: 244 seconds]
09:45 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-tujdfngeuievwcwa] has joined ##taproot-activation
09:58 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-wbapbaqmnnrhcpph] has joined ##taproot-activation
09:58 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has joined ##taproot-activation
10:12 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has quit [Remote host closed the connection]
10:17 <@michaelfolkson> Core has always been code first, specification second. I don't think this will ever change because of what Satoshi left us.
10:18 <@michaelfolkson> I don't think (?) anyone is going to pick this apart because of what BIP we end up using. The most important thing is the code is optimal and well reviewed (assuming parameters aren't contentious which they don't seem to be)
10:20 <@michaelfolkson> However, on the topic of BIPs (in the world of words rather than code, not as important in my view) if BIP 9 is to be used it will need to be changed. That will need a PR to be opened and at least one ACK from a BIP 9 author (Rusty, Greg, Pieter, Peter)
10:21 <@michaelfolkson> If that isn't possible (and people don't want to change BIP 8 to be more flexible to incorporate ST) then it will need a new BIP number
10:22 -!- LRSN [d41dd2e6@212.29.210.230] has joined ##taproot-activation
10:22 <@michaelfolkson> I'm not saying that to be disruptive, I just want to lay out facts so we are all on same page and there are no surprises later
10:25 <@michaelfolkson> Reversing on the "BIP 9 is dead" Rusty statement I guess is possible. I didn't think we'd go that route but if that becomes a stumbling block I guess I wouldn't NACK it
10:27 -!- amptwo [segwitmatr@gateway/shell/matrix.org/x-nsoinruznghaombz] has joined ##taproot-activation
10:28 < harding> *Using* BIP9 doesn't mean we need to use BIP9 exactly as specified (ditto for BIP8).  Those are just mental starting points we can use to simplify description of the proposal.
10:29 -!- timeerrr[m] [timeerrrma@gateway/shell/matrix.org/x-zqbgdiqdobxznzrh] has joined ##taproot-activation
10:30 -!- nioc [sid298274@gateway/web/irccloud.com/x-ufgjfglutocgvhsy] has joined ##taproot-activation
10:31 < harding> I would not propose changes to either BIP9 or BIP8.  As roconnor said, the actual specification of activation parameters goes in the BIP for the change, e.g. https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Deployment .  If the changes we want for Speedy Trial are just small changes to BIP9 or BIP8, I think they can just go into https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#Deployment
10:32 <@michaelfolkson> harding: If they are small changes, agreed. The question is whether they are small changes
10:32 < harding> If people really want a BIP for Speedy Trial, then I can fork BIP9 or BIP8 (whatever we end up going with).  That's easy enough.
10:32 < harding> michaelfolkson: the changes are two lines of code!
10:33 < harding> I pasted one of them above.  The other is just: consensus.nRuleChangeActivationThreshold = 1815; // 90% of 2016
10:35 <@michaelfolkson> Let me read BIP 9 again and see whether the word changes to BIP 9 would be significant to fit ST into it
10:36 <@michaelfolkson> It doesn't fit into the process diagram of BIP 8 as is
10:36 < harding> Argggh, I agree with aj, this is ridiculous bikeshedding.
10:36 -!- harding [quassel@newmail.dtrt.org] has left ##taproot-activation ["http://quassel-irc.org - Chat comfortably. Anywhere."]
10:38 -!- rubikputer [~rubikpute@ip72-192-27-21.ri.ri.cox.net] has joined ##taproot-activation
10:39 <@michaelfolkson> I'll repeat. This is not a stumbling block and should not be a stumbling block. But we should be clear in a BIP exactly what has been implemented. We owe that to ourselves as well as future soft fork activations
10:40 <@michaelfolkson> If that is a new BIP so be it. harding has literally said "If people really want a BIP for Speedy Trial, then I can fork BIP9 or BIP8 (whatever we end up going with).  That's easy enough."
10:40 <@michaelfolkson> I don't know what the problem is
10:40 < mol_> michaelfolkson, great job to drive two devs away from this channel
10:41 <@michaelfolkson> Thank you for your encouragement mol_
10:41 < mol_> michaelfolkson, look in the mirror, that's the problem, you're sucking the air out of people
10:41 <@michaelfolkson> To say we should document what we've implemented? That is a problem?
10:42 < mol_> michaelfolkson, take a break, ffs
10:42 -!- mol_ [~mol@unaffiliated/molly] has left ##taproot-activation ["Leaving"]
10:45 < copumpkin> can't it be after-the-fact? I think folks are just dreading adding another blocker to a very very delicate situation where they've only barely gotten bare semblance of agreement in the middle of a contentious debate
10:46 <@michaelfolkson> "Core has always been code first, specification second"
10:47 <@michaelfolkson> "I don't think this will ever change because of what Satoshi left us."
10:48 <@michaelfolkson> That answers your question right copumpkin?
10:49 < copumpkin> ok :)
10:49 < copumpkin> maybe! I just want people to keep agreeing and stop storming out :) I don't actually care about what they agree about :P
10:50 <@michaelfolkson> I think we're fine too but maybe there are some private conversations that are going on that I'm not privy too
10:51 <@michaelfolkson> Or people are on edge. Maybe that
10:51 < copumpkin> guessing the latter :)
10:52 <@michaelfolkson> I want to be clear. There are zero spanners in the works here. I just want to make sure we do a good job on this so we don't look back and think what the hell was implemented
10:52 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
10:54 <@michaelfolkson> As Matt has said these are consensus changes. We should document what has been implemented after the fact
10:54 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
10:56 -!- RamiDz94 [~RamiDz94@61.152.197.181] has joined ##taproot-activation
10:57 -!- RamiDz94 [~RamiDz94@61.152.197.181] has quit [Remote host closed the connection]
10:58 -!- RamiDz94 [~RamiDz94@212.129.10.242] has joined ##taproot-activation
10:59 <@michaelfolkson> I have asked luke-jr for a BIP number. I'm waiting to hear back on that
10:59 < luke-jr> michaelfolkson: except that isn't true
10:59 <@michaelfolkson> luke-jr: What isn't? That I've asked?
11:00 <@michaelfolkson> luke-jr: I'm sure I had, I'll look back in the logs... regardless can we have a BIP number allocated for ST?
11:00 < luke-jr> every softfork Core has ever done, has had a BIP
11:00 < luke-jr> first
11:00 < luke-jr> asking for BIP numbers is not how BIPs work.
11:01 < luke-jr> when/if ST ever gets to that stage
11:02 <@michaelfolkson> Ah interesting, so we do have a spanner in the works. You won't give us a BIP number even if someone opens a PR with the contents of harding's email
11:02 < luke-jr> spanner?
11:02 <@michaelfolkson> That's a spanner in the works for ST
11:02 < luke-jr> what's a spanner?
11:02 <@michaelfolkson> Maybe that is a British phrase...
11:03 <@michaelfolkson> Erm ST has a problem
11:03 < luke-jr> not really, just needs to have something written up
11:03 < luke-jr> in the format laid out in BIP 2
11:03 <@michaelfolkson> It needs a BIP number and you won't give it one if someone opens a PR with the contents of harding's email?
11:04 < luke-jr> For assignment:        dev ML discussion;        technically sound;        has motivation;        addresses backwards compatibility;        keeps with Bitcoin philosophy
11:04 < luke-jr> to summarise BIP 2 in a tl;dr
11:05 < luke-jr> an email is not a valid BIP in itself
11:06 <@michaelfolkson> I know harding hated me for saying it but ST needs to be BIP 9, BIP 8 or a new BIP I think. A new BIP seems least contentious.
11:07 <@michaelfolkson> Let me look at BIP 2 then. I've never opened a BIP before
11:07 < luke-jr> it's fairly simple
11:08 <@michaelfolkson> But you don't in principle have a problem with a BIP for ST getting a BIP number right?
11:08 <@michaelfolkson> This isn't going to be a waste of my time?
11:08 < cguida1> michaelfolkson thanks for all your hard work so far on this. i'm not sure why everyone is being so mean
11:09 < luke-jr> michaelfolkson: I'd rather not assign a dozen BIPs to the various philosophising unless they're going to get used.
11:09 < luke-jr> michaelfolkson: if ST is going to happen, though, it should have a BIP
11:09 < luke-jr> michaelfolkson: see the BIP 100-109 range for what I mean
11:09 <@michaelfolkson> cguida1: Ha I've seen people be a lot meaner to Luke over the years. I can handle it :) Thanks though
11:10 <@michaelfolkson> luke-jr: Ok. So I think ST stands a good chance at this stage. So I'm going to work on getting it a BIP number and then drafting a BIP.
11:11 <@michaelfolkson> Hopefully I'm not wasting my time. But even if I am there are at least two or three other options assuming I fail to get a BIP number
11:11 <@michaelfolkson> Change BIP 9, change BIP 8 or have an activation section in the Taproot BIP
11:12 < luke-jr> I'd suggest just posting the BIP draft to the ML for comment, and waiting to get it a number until things are merged into Core
11:12 < luke-jr> or ready to merge
11:12 <@michaelfolkson> I'm going to pursue getting a BIP number. Others can pursue those others if they think I am wasting my time
11:12 < cguida1> michaelfolkson you weren't saying that the bip needed to be made *first*, just that it should probably be made at some point, which seems perfectly reasonable. luke-jr, I think, *is* saying that there needs to be a bip first, which, while it potentially blocks a release, it can be drafted in parallel to the code, by someone other than the people writing the code, so it doesn't seem that onerous. I'm not understanding the "
11:12 < cguida1> diculous bikeshedding" position
11:13 < luke-jr> tbh I think modifying BIP 8 might be a better route to go though
11:13 < luke-jr> it's still in draft stage after all
11:14 <@michaelfolkson> luke-jr: I'm going to pursue a new BIP number because I think you won't want BIP 9 to be changed and the anti LOT=true people won't want BIP 8 to be used.
11:15 < luke-jr> BIP 9 can't be changed at this point
11:15 <@michaelfolkson> As I've said before I'm really happy with BIP 8 as is. Assuming ST is deployed and fails, I'd go straight to BIP 8 at that point
11:15 < luke-jr> michaelfolkson: ST is still using heights as things stand, right?
11:16 < luke-jr> cuz using MTP might be a problem
11:17 < luke-jr> (it would likely blow up the patch size for the BA release
11:17 < luke-jr> (including a lot more review)
11:18 <@michaelfolkson> From what I've seen (and I'm treading on egg shells with some of the anger directed at me) block heights doesn't seem to be a problem. But we should see progress on the code next week
11:19 < cguida1> pox: ftr I love the name "spaghetti activation". Creates a mental image that really sticks in the mind
11:20 < RamiDz94> how many months it takes to get activated
11:20 < cguida1> RamiDz94: as long as it takes
11:20 < RamiDz94> if BIP 9 used
11:20 < luke-jr> …
11:20 < luke-jr> RamiDz94: BIP 9 is dead
11:21 <@michaelfolkson> luke-jr: When you say "BIP 9 can't be changed at this point" can you elaborate why?
11:21 < luke-jr> michaelfolkson: it is Final / has been used as-is
11:22 < roconnor> luke-jr: doesn't the activation method go into BIP-341?
11:23 < roconnor> which could be a reference to another bit, or a whole cloth decription or some mishmash of the two.
11:23 <@michaelfolkson> Ok, it appears I'm going to be studying BIP procedure for the next day or two (which is fine)
11:24 < luke-jr> roconnor: if you want to try to get ST+BIP8(True) in BIP 341 be my guest
11:27 <@michaelfolkson> I want to be clear that assuming ST has consensus (looks promising so far) and it progresses, BIP procedures should not block it. That would be a failure of the BIP process more than anything else
11:27 < luke-jr> I don't recommend opening that can tho. Seems likely there are worms inside :P
11:28 <@michaelfolkson> I'm happy to do the work to follow the BIP procedures though
11:28 < luke-jr> I suppose I should also run the concept by some of the "LOT=True matters more than Taproot" folks
11:29 <@michaelfolkson> At least some of them are in the ##uasf channel. I haven't received any NACKs yet
11:29 <@michaelfolkson> But sure, everyone should be consulted
11:29 <@michaelfolkson> (as far as is possible)
11:29 -!- maybehuman [b9f24c0f@185.242.76.15] has joined ##taproot-activation
11:30 < achow101> can y'all just wait 48 hours for me to get my entire proposal together
11:30 < maybehuman> maybe I'm missing something, but wouldn't it be enough to add one more parameter (min activation height) to bip8?
11:31 < roconnor> achow101++
11:31 <@michaelfolkson> achow101: Sure I'm happy to pause until whenever works for you
11:31 < brg444> i've acked the concept fwiw luke-jr
11:33 < luke-jr> achow101: another one? or ST still?
11:33 < luke-jr> maybehuman: AIUI yes
11:33 < achow101> luke-jr: height based ST
11:33 < achow101> with BIP mods and impl
11:33 < maybehuman> achow101 nice!
11:34 < luke-jr> ^
11:34 < luke-jr> michaelfolkson: see, you don't even have to do it :P
11:35 <@michaelfolkson> Ha. achow101 does all of our work for us
11:35 < achow101> the only answer to "do it my way" is to do it yourself
11:35 < achow101> so here we are
11:37 < luke-jr> oh well in that case imma just NACK it for the lulz /s jkdonthangme
11:37 < cguida1> achow101 just to confirm, "bip mods and impl" means you're proposing modifications to bip8 and also implementing in code?
11:38 <@michaelfolkson> I think the earlier anger is some people are worried that BIP technicalities will push ST off course. That mustn't happen. ST is not guaranteed at this stage but BIP technicalities definitely shouldn't be the reason for it failing
11:38 < RamiDz94> so here we r talking about which BIP to use for reducing the duration of activaion or to avoid fail
11:39 < achow101> cguida1: current plan is to modify BIP 8, modify BIP 341, review the BIP 8 PR, write height based ST
11:39 < achow101> and submit 5 or so PRs
11:39 <@michaelfolkson> (As a warning for anyone gearing up for a war on BIP technicalities)
11:39 < luke-jr> michaelfolkson: I don't think that has ever happened
11:39 < luke-jr> despite scamcoiner FUD
11:40 <@michaelfolkson> I'm just trying to understand why people were angry earlier
11:41 < achow101> michaelfolkson: because you are trying to shoehorn ST and ajs pr into an existing BIP
11:41 < cguida1> achow101: thanks, and thanks for your hard work!
11:42 < RamiDz94> fk CSW
11:43 < achow101> michaelfolkson: I believe the frustration is due to you being concerned about what it is called and whether it fits into the framework of an existing thing rather than the actual details and the fact that the bip numbers were only being used as a shorthand to refer to how the underlying implementation
11:43 < achow101> it doesn't matter that ajs PR is reliant on BIP 9 and it being so is not necessarily contradictory to the statement that BIP 9 is dead
11:45 < RamiDz94> ALL this work devs r doing,at the end he wants to sue them. good luck guys sorry for spoil the chat.
11:45 <@michaelfolkson> achow101: I'm not. I've since laid out the four options. BIP 8, BIP 9, new BIP number or section in Taproot BIP. I think new BIP number will be least contentious if people want to fight over technicalities
11:45 < maybehuman> in any case, the way I read it, it was mostly based on bip9 to keep the diff short, not as pat of some underhanded scheme to "unperson" lot true (which you seemed to imply at some point)
11:46 < cguida1> achow101: I believe the sticking point was height- vs time-based activation, not what the name or bip number was
11:46 <@michaelfolkson> It did take me a while to reverse out of the position that BIP 9 was dead. That was imprinted in my mind. Damn Rusty
11:47 < achow101> michaelfolkson: I believe the issue is with your statement "You will need to convince one of the BIP 9 authors to change the BIP"
11:47 <@michaelfolkson> achow101: But that is BIP procedure. Right Luke?
11:47 <@michaelfolkson> If BIP 9 is changed, an author needs to ACK it
11:48 <@michaelfolkson> Our get out if people want to play technicality wars is following the procedure to get a new BIP number (which I'm happy to do)
11:48 < maybehuman> but it's not like the bip police will come and arrest you if you don't follow the procedure to the letter
11:48 < AaronvanW> I don't know if this should be read as a NACK for ST, but I do think it's worth considering: https://twitter.com/rusty_twit/status/1368325392591822848
11:49 < achow101> it's just arguing over procedure and bureaucracy that I think some are finding to be a waste of time at the current moment
11:49 < achow101> we aren't really close to the point for figuring out what should happen and thus needs to be written down
11:49 < maybehuman> exactly. bips can be written post facto, it's mostly a documentation thing, no?
11:49 <@michaelfolkson> Ok understood. I'm just trying to make sure this doesn't unravel in a few days or weeks because of things like technicalities
11:49 < achow101> so trying to think about that at this time is a bit pointless
11:49 <@michaelfolkson> Ok
11:52 < achow101> maybehuman: usually bips are added before the implementation pr to core is opened. however implementation usually exist long before bips are written, just in people's personal repos
11:53 < achow101> really the only difference between now and past forks is that implementation work is being done even more in the open
11:54 < maybehuman> right, I guess I was more thinking of how bolts in lightning seem to work
11:55 < maybehuman> but luke has a point, there shouldn't be a bip for everything that was under consideration at some point. So modifying bip8 still seems the easiest
11:56 < cguida1> AaronvanW: I don't think ST is mutually exclusive with addressing Rusty's concerns. Whether ST succeeds or fails, a better activation plan can be implemented for next time, be that taproot or the next soft fork
11:57 <@michaelfolkson> I think new BIP will be least contentious maybehuman. I don't want a technicality war and I think BIP 8 is really solid as is
11:57 <@michaelfolkson> But whatever
11:57 < achow101> my current plan is to just add extra more parameters to bip 8
11:57 < maybehuman> actually, ST seems to follow the triumvirate setup he layed out in his blog post. I'm not sure by what he means by "without a plan"
11:58 < maybehuman> michaelfolkson I don't think a new param takes anything away from bip8 as is, no?
11:59 <@michaelfolkson> maybehuman: Look I'm not going to NACK it. But if this process thus far as taught me anything is that if something can go wrong it will go wrong.
11:59 < AaronvanW> cguida1: true, but I think his point is that if we make sure to get it right this time, that would be worth it, because next time(s) will be so much easier. (which would be good because consensus upgrades are expected to get harder and harder.)
11:59 -!- maybehuman [b9f24c0f@185.242.76.15] has quit [Quit: Connection closed]
12:00 <@michaelfolkson> maybehuman: I'd rather get out in front of it
12:00 < AaronvanW> harder and harder with a bigger user base I mean
12:02 < cguida1> AaronvanW: I definitely agree with that sentiment. But I think the purpose of ST is to gather the data of whether or not activation will happen with miner cooperation this time. That will inform and enhance whatever formalization of the process is written later.
12:02 < AaronvanW> maybehuman: ST is specifically intended to prevent a UASF, so in that sense it doesn't follow the triumvirate setup he layed out in his blog post.
12:02 < cguida1> michaelfokson: I agree, first step is to write a draft bip, bip-speedytrial, with an implementation. next step is to decide whether to give it a new bip number or modify bip8
12:04 <@michaelfolkson> AaronvanW: He just doesn't want Core developers releasing something that definitely activates. This fits. Core developers aren't releasing something that definitely activates
12:04 <@michaelfolkson> Miners can activate. Users can overrule
12:04 <@michaelfolkson> This fits
12:04 <@michaelfolkson> He didn't want Core releasing LOT=true
12:05 <@michaelfolkson> At least initially
12:06 -!- reallll [~belcher@unaffiliated/belcher] has joined ##taproot-activation
12:06 < cguida1> sorry, michaelfolkson, not michaelfokson xD
12:08 < AaronvanW> true, users can still overrule through redeployment. (or a rushed UASF.)
12:08 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
12:09 < AaronvanW> I don't know if he'd prefer "overrulling" within the same difficulty period, and if so, if he has a good reason for that.
12:10 <@michaelfolkson> If miners activate, the only reason for users to overrule is if they don't want Taproot to activate
12:10 <@michaelfolkson> If miners don't activate, users can run a UASF release after ST has failed
12:10 <@michaelfolkson> There really isn't a problem with Rusty's viewpoint
12:11 <@michaelfolkson> What he disliked was Core setting LOT=true such that it would activate without miners or users
12:13 <@michaelfolkson> That isn't happening here (to state the obvious)
12:32 -!- jonatack_ [~jon@37.171.116.163] has joined ##taproot-activation
12:35 -!- jonatack [~jon@37.166.13.194] has quit [Ping timeout: 245 seconds]
12:50 -!- LRSN [d41dd2e6@212.29.210.230] has quit [Quit: Connection closed]
13:09 -!- RamiDz94 [~RamiDz94@212.129.10.242] has quit [Remote host closed the connection]
13:15 -!- rubikputer [~rubikpute@ip72-192-27-21.ri.ri.cox.net] has quit [Ping timeout: 245 seconds]
13:23 -!- RamiDz94 [~RamiDz94@61.152.197.181] has joined ##taproot-activation
13:39 -!- RamiDz94 [~RamiDz94@61.152.197.181] has quit [Remote host closed the connection]
13:40 -!- RamiDz94 [~RamiDz94@61.152.197.181] has joined ##taproot-activation
13:49 -!- RamiDz94 [~RamiDz94@61.152.197.181] has quit [Remote host closed the connection]
13:50 -!- RamiDz94 [~RamiDz94@61.152.197.181] has joined ##taproot-activation
13:55 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has joined ##taproot-activation
13:56 -!- RamiDz94 [~RamiDz94@61.152.197.181] has quit [Remote host closed the connection]
14:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
14:24 -!- harding [quassel@newmail.dtrt.org] has joined ##taproot-activation
14:24 -!- reallll is now known as belcher
15:45 -!- rubikputer [~rubikpute@ip72-192-27-21.ri.ri.cox.net] has joined ##taproot-activation
15:54 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds]
16:01 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has quit [Quit: ZNC 1.8.1 - https://znc.in]
16:26 < luke-jr> michaelfolkson: LOT=true doesn't activate without miners or users
16:28 <@michaelfolkson> luke-jr: If users just blindly run what Core gives them then a Core release of LOT=true is activating at the end without miners or users making a conscious choice, I think that is Rusty's argument
16:29 <@michaelfolkson> A user running a UASF release is a conscious choice. It isn't saying UASF shouldn't do LOT=true, it is saying Core (at least initially) shouldn't release LOT=true
16:29 <@michaelfolkson> It is similar to the F7 argument
16:30 < luke-jr> users should never just blindly run what others give them
16:30 <@michaelfolkson> Right, but there are a lot of things that people shouldn't do but they still do them
16:31 < luke-jr> and miner involvement wouldn't make that any better
16:31 < luke-jr> arguably it makes it worse
16:31 <@michaelfolkson> Rusty would prefer miners or users to pull that final switch. Developers propose, miners activate, users overrule
16:32 < luke-jr> miners are no "better" than devs
16:32 <@michaelfolkson> Rather than developers proposing and activating with a LOT=true
16:32 < luke-jr> devs don't activate ever
16:32 <@michaelfolkson> Again I don't want to get in an argument just for trying to explain someone else's argument :)
16:33 < luke-jr> my point is that it's a false narrative
16:33 < luke-jr> the be an argument it needs premises and logical conclusions
16:33 <@michaelfolkson> But it is like a game of pass the parcel or pass the hot potato. Rusty would prefer the parcel/hot potato to be passed at least once or twice more (so that miners and/or users are making conscious choices)
16:34 <@michaelfolkson> Running a Core (LOT=true) blindly means it activates without a conscious choice from miners and users
16:35 < luke-jr> running a Core blindly means devs control the network period
16:35 <@michaelfolkson> But its Rusty's argument. I have annoyed enough people today. He can argue for his own argument if he wants
16:35 < luke-jr> Bitcoin might as well not exist in that scenario ;)
17:38 -!- h4shcash [~adam3us@2a01:4c8:41a:bd7d:6d80:e5df:2234:cdc7] has quit [Remote host closed the connection]
17:39 -!- roconnor [~roconnor@host-104-157-194-235.dyn.295.ca] has quit [Quit: Konversation terminated!]
17:55 -!- Teleportando [8eb30758@d142-179-7-88.bchsia.telus.net] has joined ##taproot-activation
18:05 -!- jonatack_ [~jon@37.171.116.163] has quit [Ping timeout: 245 seconds]
18:22 -!- ariel87 [c777eb96@199.119.235.150] has joined ##taproot-activation
18:27 < ariel87> I think it's unlikely that Speedy Trial will get 95% signaling within 3 months. Has anyone considered the Simple Majority Activated Soft Fork proposal? (SMASF)
18:33 -!- ariel87 [c777eb96@199.119.235.150] has quit [Quit: Connection closed]
18:46 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
19:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
19:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
20:20 -!- Ironhelix [~x@154.6.28.69] has quit [Ping timeout: 264 seconds]
20:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
20:46 -!- shesek [~shesek@164.90.217.137] has joined ##taproot-activation
20:46 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
20:46 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
21:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 264 seconds]
21:46 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
21:46 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds]
22:18 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
22:19 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
22:22 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
22:35 < pox> it may be better if it fails to activate with 95% signaling in 3 months, at which point we could ask pools why they haven't upgraded, and if no good answer is forthcoming out comes the hammer. this assumes 3 months is at least twice as much time as pools would need to upgrade from a technical standpoint. if it isn't, well, we'll find out.
23:42 -!- carlolo [90025de5@bbcs-93-229.pub.wingo.ch] has joined ##taproot-activation
23:56 -!- carlolo [90025de5@bbcs-93-229.pub.wingo.ch] has quit [Quit: Connection closed]
--- Log closed Mon Mar 08 00:00:51 2021