--- Log opened Thu Mar 04 00:00:46 2021
00:29 -!- brg444_ [uid207215@gateway/web/irccloud.com/x-nimakvacfthwvsmg] has joined ##uasf
00:29 -!- michaelfolkson2 [~michaelfo@2a03:b0c0:1:e0::23d:d001] has joined ##uasf
00:43 -!- Netsplit *.net <-> *.split quits: @michaelfolkson, brg444
00:43 -!- brg444_ is now known as brg444
00:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##uasf
01:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
01:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##uasf
01:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
01:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##uasf
02:57 -!- belcher_ is now known as belcher
03:10 < michaelfolkson2> Test
03:13 < michaelfolkson2> Test
03:15 < michaelfolkson2> Test
03:17 -!- michaelfolkson2 is now known as michaelfolkson
03:17 < michaelfolkson> Test
03:18 < michaelfolkson> Ok someone has taken my admin rights on this channel
03:18 < michaelfolkson> Just so people know
03:18 < michaelfolkson> Maybe it was belcher
03:19 < michaelfolkson> I might be kicked off this channel if it is only belcher with admin rights
03:23 < michaelfolkson> I'd feel more comfortable if luke-jr brg444 or me (ie someone who is onboard this UASF effort) has admin rights (It doesn't have to be me). belcher seems to want to rehash the flag day
03:26 < belcher> even though i disagree with this effort, i still believe in free speech so i wont kick off anyone, but if you're more comfortable i can hand over admin rights to someone else (fwiw mol_ also has admin rights)
03:26 < belcher> i think we made the channel back in 2017 thats why
03:26 < belcher> wait what.. i didnt take your admin rights
03:27 < michaelfolkson> Well someone gave me admin rights initially. And now someone has taken them away
03:27 < belcher> /cs access ##uasf list
03:27 < belcher> -ChanServ- Entry Nickname/Host          Flags
03:27 < belcher> -ChanServ- ----- ---------------------- -----
03:27 < belcher> -ChanServ- 1     molly                  +AFRefiorstv [modified 3y 46w 6d ago]
03:27 < belcher> -ChanServ- 2     belcher                +AFRefiorstv [modified 3y 46w 6d ago]
03:27 < belcher> -ChanServ- 3     Luke-Jr                +o [modified 1w 0d 13h ago]
03:27 < belcher> are you sure you had them?
03:27 < michaelfolkson> Look back at the logs of last couple of days
03:27 < belcher> oh you mean +o mode
03:27 < belcher> sec
03:28 < belcher> added you to chanserv's list, do /cs op ##uasf and chanserv will give you ops
03:29 < belcher> that works even after you disconnect (you most likely lost ops because your connection broke and you reconnected)
03:29 < michaelfolkson> I still have ops on ##taproot-activation despite reconnecting
03:30 < michaelfolkson> I'm a touch uncomfortable by this, not going to lie
03:30 < michaelfolkson> Especially if we encourage more people to join
03:30 < belcher> most likely on ##taproot-activation you have +O which means automatic op whenever you join
03:31 < belcher> i can remove founder rights from myself then?
03:31 < belcher> transfer to someone (luke-jr probably?)
03:31 < michaelfolkson> Yeah I'd be more comfortable with that
03:32 < michaelfolkson> It doesn't make sense for someone who disagrees with the effort to have the power start booting people from this channel. Especially if it grows
03:33 < michaelfolkson> (No offence. I wouldn't want you booted either)
03:33 < belcher> done, the access list is now:
03:33 < belcher> -ChanServ- Entry Nickname/Host          Flags
03:34 < belcher> -ChanServ- ----- ---------------------- -----
03:34 < belcher> -ChanServ- 1     molly                  +AFRefiorstv [modified 3y 46w 6d ago]
03:34 < belcher> -ChanServ- 2     Luke-Jr                +ARSefiorstv [modified 37s ago]
03:34 < belcher> -ChanServ- 3     michaelfolkson         +o [modified 5m 11s ago]
03:34 < michaelfolkson> Ok thanks, appreciated
03:34 < belcher> +S means successor, i wasnt able to add luke as +F founder for some reason, though mol_ is still founder
03:38 -!- mode/##uasf [+o michaelfolkson] by ChanServ
04:08 <@michaelfolkson> I'm stating the obvious but feel free to discuss flag day etc on other channels, mailing list, Reddit belcher. I feel it has all been done to death at this stage but no ideological purity is required (at least from my standpoint) here
04:24 -!- darosior [~darosior@194.36.189.246] has joined ##uasf
04:44 <@michaelfolkson> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018545.html
04:45 <@michaelfolkson> It would be nice to sketch out a timetable that we are happy with
04:52 <@michaelfolkson> Personally I think it is totally unacceptable to fail to give miners and users the opportunity to activate Taproot this year (2021). Whether that be a UASF (LOT=true), Core (LOT=false) release or both.
04:52 <@michaelfolkson> But I'd be interested to hear views
04:56 <@michaelfolkson> The startheight we initially had from the Taproot activation IRC meetings was July 2021 which would mean a MUST_SIGNAL phase in July 2022 (assuming miners failed to activate)
04:57 <@michaelfolkson> Personally (I know Luke disagreed) I thought this wouldn't give enough time for testing, code review. I also think it is important to get as much community support for it as we possibly can.
04:59 <@michaelfolkson> But any startheight later than end of 2021 is in my eyes totally unacceptable
04:59 -!- cguida [~cguida@2806:2f0:5020:433a:6233:c943:ef82:7985] has quit [Ping timeout: 258 seconds]
05:02 <@michaelfolkson> Some people on the mailing list seem to be trying to a revive a flag day set in Core which is perplexing to me as it clearly violates F7 https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
05:04 <@michaelfolkson> In addition it means much later activation in the case that miners are ready to activate from the startheight
05:04  * michaelfolkson shrugs
05:12 -!- cguida [~cguida@2806:2f0:5020:433a:1fe9:7c7b:dd55:7e3b] has joined ##uasf
05:15 <@michaelfolkson> If anyone supports a later startheight than the end of 2021 let me know. I highly doubt such an individual exists here :) In which case we're looking at second half of 2021 for startheight
05:25 <@michaelfolkson> It would be good too to get more people on this channel. I don't want this appear to be an effort that is ignoring the community having spent weeks/months getting community consensus around BIP 8 (1 year), 90 percent threshold, startheight of July (which may need to be pushed back)
05:40 < queip> michaelfolkson: how about 1 year from 2021.03.14 to 2022.03.14 (approx), with LOT=true at end
05:40 < queip> it's a nice round date too
05:42 <@michaelfolkson> queip: startheight of March? I don't understand. Earliest startheight would July (Luke wouldn't want to go earlier than that) and that would apparently mean a release by the end of this month (March) which would be rushed
05:44 < queip> ok. then release in April, start date at 2021-08-01
05:44 < queip> and flag day 1 year after start?
05:44 < queip> of course if miners would this time be not-malicious we will get it faster
05:45 <@michaelfolkson> MUST_SIGNAL phase 1 year after start, slightly different from a flag day
05:46 <@michaelfolkson> queip: Yeah I'd be happy with start date of 2021-08-01
05:47 <@michaelfolkson> Or 2021-09-01
05:47 <@michaelfolkson> No later than that
05:48 <@michaelfolkson> That would give miners 3 months to activate before the end of the year which sounds good to me
05:48 <@michaelfolkson> In all likelihood that gets the job done by the end of the year
05:52 <@michaelfolkson> Yeah I think giving miners 3 months before the end of the year to activate is optimal. They wouldn't be rushed to get it done before holidays (and of course if they aren't ready they don't activate by the end of the year)
05:54 <@michaelfolkson> I'm assuming a Western calendar of course, not a Chinese one, but that seems to work
05:55 < nothingmuch> why no later? i have no real opinion about this, just curious about the reasoning... not sure how one would estimate the likelyhood of a premature MASF
05:55 < nothingmuch> (premature = before enough nodes are ready to enforce)
05:56 <@michaelfolkson> I'm more thinking how much time will be needed for code review and testing pre-release
05:57 < queip> but how soon we "need" users to signal they support USAD?
05:57 < queip> USAF
05:57 < queip> if they start showing support even few months before 2021-08 then it's quite good right?
05:57 <@michaelfolkson> nothingmuch: But also the closer you get to the end of the year I would guess that sets an expectation that miners rush signaling before the end of the year. I could be totally wrong on that
05:59 <@michaelfolkson> queip: We only need users to enforce MUST_SIGNAL at the end of a BIP 8 (LOT=true). Which would be a year (minus 2 weeks) after the startheight
05:59 <@michaelfolkson> There really is no rush whatsoever for users. But it would be good to get as much community support as possible pre-release
06:01 <@michaelfolkson> I don't want this to look like we are ignoring the community (especially after all the work to get the community engaged over the past weeks and months)
06:01 <@michaelfolkson> If it is just say Luke and me enforcing what we think on everyone that is not good
06:02 <@michaelfolkson> I don't think it would be. The community just wants this done, that is blatantly obvious
06:02 < queip> yeah, let's have taproot
06:02 <@michaelfolkson> More delay and more pushback is just offending the community by now
06:07 < mol_> good morning
06:08 < mol_> just woke up :D
06:08 < mol_> michaelfolkson, belcher is pretty laid back guy, nobody would boot anybody on this channel except trolls and troublemakers
06:08 < belcher> its fair enough though i understand, dont trust verify after all
06:09 <@michaelfolkson> mol_: If he didn't remove my ops I apologize for the accusation. It was very weird that I lost them though
06:10 < cguida> Could do July 20, the anniversary of the bip91 lock-in. Or August 23, the anniversary of segwit lock-in :)
06:10 < mol_> i'm a long time freenode user, check my nick you'll see.. and on freenode there's a recommendation not to mod yourself visibly to reduce the temperature of the channel, i follow that suggestion
06:11 <@michaelfolkson> Cool
06:11 < mol_> michaelfolkson, afaik nobody removed your ops, i didn't, it could be you had a temporary mod status
06:12 <@michaelfolkson> Gotcha, if I did, I apologize. I am very on edge re censorship after Twitter etc
06:30 < mol_> michaelfolkson, i understand, we're not like that on twitter, we can discuss and disagree here, no problem
06:59 < queip> does anyone know gmax'es stance on USAF?
07:00 < queip> I do not remember. was he for it? is he for the current one?
07:00 < belcher> he was against BIP148 but was for BIP149
07:00 < queip> what was the difference?
07:00 < belcher> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014152.html
07:02 < queip> I think bip148 was a right choice, otherwise we would wait for miners forever
07:03 < queip> "We should have patience. Bitcoin is a system that should last for all ages and power mankind for a long time-- ten years from now a couple years of dispute will seem like nothing. But the reputation we earn for stability and integrity, for being a system of money people can count on will mean everything."
07:04 < queip> I do agree with that quote tho. For example, as for me, if taproot will happen next year - great! If it will happen in 2 years - I can totally live with it too
07:04 < belcher> bip148 was risky but many people (including me) thought the risk/reward was worth it.... miner fees were high and without segwit we couldnt get lightning, also there was asicboost would threatened to centralize mining and the segwit soft fork would stop that
07:09 < queip> how about this then: set a far away flag day, even 2 years. but instead, put maximum effort in getting users to signal such UASF, but also on miners to do it much faster.  (like we were pushing community, exchanges this time, for support of addresses, batching - such peer-pressure does work in the end I guess, and we have argument ultimatelly "OR ESLE we will UASF anyway")
07:10 < brg444> queip: note that if taproot activates in two years it will have taken 5 years from proposal to activation. if that were to happen, you should safely assume taproot to be the very last softfork bitcoin will ever have
07:10 < queip> well why first 3 years took long?
07:11 < queip> development?
07:13 <@michaelfolkson> Can conversation on anything other than BIP 8(true,1 year) move to ##taproot-activation please?
07:13 < brg444> well there was some debate on the underlying architecture as I remember, but yes, mostly development and testing. Specifically Schnorr integration I'd guess.
07:15 -!- michaelfolkson changed the topic of ##uasf to: Development of a BIP 8(1 year, LOT=true) Taproot activation implementation https://github.com/BitcoinActivation | logs http://gnusha.org/uasf/
07:16 < queip> ok. so only start date is the question? for me anything around 2021-6,7,8,9 sounds good
07:17 <@michaelfolkson> queip: At this point, yes. Everything else was discussed at previous meetings. I can give you links if you need them
07:19 <@michaelfolkson> July was previously agreed for startheight but (at least) I think this should be pushed back to beginning of Q4 2021
07:40 <@michaelfolkson> sipa has deliberately stayed out of the activation discussion (not a word impressively) but I sense some frustration from him. I wouldn't be surprised if gmax shares similar frustration with the lack of progress on activation
07:40 <@michaelfolkson> But pure speculation from reading Reddit etc
07:49 < luke-jr> the risk of BIP148 was the timeline
07:49 < luke-jr> and despite that it was still a perfect success - you couldn't get any better
07:50 < queip> some "Score" you can get regarding opinion. is bitcoin leadership in such things decentrlaized
07:52 < AaronvanW> luke-jr: I think BIP148 was a perfect success because it happened in the middle of a perfect storm. block size wars had been going on for years, NYA, covert AsicBoost scandal, Jihan acting like a villain on social media, etc. these are very different times; what worked then might not work as nicely now.
07:53 < luke-jr> AaronvanW: this time there's even less reason to expect any issues
07:54 < luke-jr> none at all, IMO
07:56 < belcher> bip148 was great for segwit but it stored up problems that we're dealing with now with taproot activation
07:56 < queip> luke-jr: the usual reasons
07:57 < queip> trolling to attack the leading coin, in hopes of shitcoin taking over
07:57 < queip> already there is this idiot on twitter saying taproot *decreases* privacy. probably paid by BCH
07:59 < queip> I wonder if miners, esp related to bitmain (after breaaking up?) are still hoping for that
08:00 < luke-jr> belcher: there are no problems tho, just FUD
08:03 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection]
08:03 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined ##uasf
08:07 < AaronvanW> queip: gmax commented on reddit a few weeks ago that he prefers LOT=false, although he's support LOT=true if there was consensus for it: https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/
08:08 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection]
08:08 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined ##uasf
08:18 <@michaelfolkson> belcher: I don't know how an effective rushed BIP 8 (lot = true) on top of a BIP 8 (1 year, lot=false) for SegWit was "great" but a well planned in advance BIP 8 (lot=true) on top of a BIP 8 (1 year, lot =false) is problematic
08:18 <@michaelfolkson> We don't even get close to the end of the year MUST_SIGNAL phase if miners activate early
08:20 <@michaelfolkson> AaronvanW queip: Right there are two aspects to LOT=true though. Many didn't want LOT=true in Core because of the F7 argument. This way there is no LOT=true in Core
08:24 < AaronvanW> michealfolkson: well, BIP148 worked great in retrospect :) (And like I said, I think that was to large extent thanks to a perfect storm.) I definitely wouldn't argue that it was a very safe idea, even at that time.
08:27 < AaronvanW> (it would have been relatively safe if a majority of hash power and/or economic majority committed to BIP148-- the latter was also the original plan. later it became more of an "intolerant minority thing", which had strong game theory behind it and the perfect storm I mentioned. but "safe", not imo.)
08:27 <@michaelfolkson> I just think the rushed nature is the key thing. This time it is anything but rushed. Everyone knows where they stand. If miners fail to activate for a year they know there is a small risk of a chain split in the last two weeks.
08:28 <@michaelfolkson> Everyone has months to prepare for that scenario if it looks like miners won't activate before then
08:29 <@michaelfolkson> And as that two weeks approaches, users will be clamoring to run LOT=true because they will be frustrated by lack of miner activation
08:30 <@michaelfolkson> You can't minimize the risk anymore. That's as good as it gets :)
08:31 <@michaelfolkson> That two weeks will be Q3 2022 (if we get there)
08:33 < AaronvanW> I can see the argument for LOT=false in Core and a community effort for LOT=true. However, it takes too to tango. If Core doesn't want LOT=false in the context that there will also be a community LOT=true client... I think it's going to be a really steep uphill battle to turn that community effort into a success.
08:33 < AaronvanW> *takes two to tango
08:34 <@michaelfolkson> Steep uphill battle, true but we have until Q3 2022 to get people to run it
08:34 <@michaelfolkson> However frustrated people are now, imagine how frustrated they will be by second half of 2022
08:35 <@michaelfolkson> As long as we don't screw something up, people will be desperate to run it I think
08:35 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
08:36 <@michaelfolkson> And if they don't people like Luke and me look stupid (but that's fine) :)
08:37 <@michaelfolkson> I would personally give up on Taproot activation at that point, I don't think there is anymore to try
08:37 <@michaelfolkson> Obviously others are free to try something else
08:37 < AaronvanW> steep uphill battle might not be the fastest path to Taproot.
08:38 <@michaelfolkson> At least it puts a year limit on it and gives miners the opportunity to activate as speedily as they wish
08:39 <@michaelfolkson> Better than flag day. You wait until the flag day with no hope of anything happening and then the flag day could still fail
08:39 < brg444> AaronvanW: under this perspective anyone can sabotage future SF by releasing incompatible software
08:41 < AaronvanW> brg444: only no MASF I think
08:41 < AaronvanW> (and yes I'm starting to think MASFs might now be dead.)
08:48 < brg444> i'm not particularly optimistic about the flag day rollouts as network grows so that's quite the predicament if it comes down to that
08:49 < AaronvanW> yeah
08:53 < mol_> brg444, what's the alternative to flagday then?
08:56 < brg444> Well I continue to think that a permanent independent implementation that mirrors Core releases and includes LOT=True defaults in the event of SF is probably the best way forward
08:56 < brg444> SF activation should be completely divorced from Core
09:01 < brg444> https://usercontent.irccloud-cdn.com/file/g20hBuHT/image.png
09:07 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##uasf
09:07 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has left ##uasf ["Bye!"]
09:13 < brg444> this is my motivation for originally setting the name of the repo bitcoinactivation fwiw
09:15 < brg444> I'm hoping it can create an sf-agnostic precedent we can build on
09:23 <@michaelfolkson> I wonder if UASFs should always be somewhat sporadic and grass roots though. Otherwise it suffers from the same institutionalism as Core. But that is most definitely a discussion for another day
09:31 < queip>  sf?
09:31 < _andrewtoth_> soft fork
09:36 < brg444> there's not really place for institutionalism to set in. the implementation just defaults to True
09:36 < brg444> the grass root effect is whether or not users adopt it
09:36 <@michaelfolkson> And when it gets released. When its ready, when its sufficiently reviewed and tested
09:51 < mol_> brg444, how do we get the majority of users to run a non-Core version?
09:51 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##uasf
09:52 < mol_> i think one of the main factors the UASF was successful last time because most economic nodes were already ready by running segwit Core versions
09:54 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 260 seconds]
09:54 < brg444> michaelfolkson: most of the review and testing would happen within core already is my assumption
09:55 < brg444> I don't expect Core to not release a compatible version but I'm assuming they'll continue to default to =false
09:57 < brg444> Overall I think if we can get through this successfully, demonstrating that a mix of activation parameters across the network is not the disaster some are making it to be, that'd be a big win
09:59 -!- stortz [b1982408@177.152.36.8] has joined ##uasf
10:05 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##uasf
11:03 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##uasf
11:06 < devrandom> it seems to me that a Core flag day and a UASF client that have the same timeoutheight are compatible and safe
11:07 < devrandom> in such a scenario, the UASF client actually adds MASF to the network
11:07 <@michaelfolkson> A BIP 8 (1 year, LOT=false) and a UASF
11:08 <@michaelfolkson> A flag day isn't compatible with a BIP 8
11:08 < devrandom> in what way isn't it compatible?
11:08 <@michaelfolkson> Flag day doesn't care about miner signaling. It activates at a particular date regardless of miner signaling
11:09 < devrandom> and so does the UASF client, right?
11:09 <@michaelfolkson> BIP 8(1 year, LOT=false) and BIP 8(1 year, LOT=true) are perfectly compatible until the last two weeks where MUST_SIGNAL kicks in for the LOT=true
11:09 < devrandom> I mean, they both are definitely active by timeoutheight
11:10 <@michaelfolkson> UASF is BIP 8(1 year, LOT=true) in this case
11:10 < devrandom> so they can't create a chain split
11:10 < devrandom> yes
11:10 <@michaelfolkson> There can be a chain split in the final two weeks but not before then
11:10 <@michaelfolkson> They can run perfectly happily side by side until the final two weeks
11:10 < devrandom> ah, yes, because of the signally period
11:11 < devrandom> *signalling
11:11 <@michaelfolkson> MUST_SIGNAL period. Miners can signal throughout the year
11:11 < devrandom> right, sorry I'm being overly terse
11:12 <@michaelfolkson> It is ok. I just need to make sure people get it :)
11:16 < devrandom> OK, so if Core releases flag day, then adding a MASF in a compatible way would require removing the MUST_SIGNAL period and just going to ACTIVE at timeoutheight.  hmm....
11:17 < devrandom> (by "adding MASF" - I mean via a competing client deployment)
11:17 <@michaelfolkson> You've got to be clear on terminology. A flag day isn't BIP 8
11:17 < devrandom> yes, of course
11:18 < devrandom> I'm talking about Matt's last proposal on bitcoin-dev
11:18 < devrandom> and looking at scenarios for alt-clients if Core releases that
11:18 <@michaelfolkson> A flag day isn't compatible with BIP 8
11:19 <@michaelfolkson> No signaling with a flag day. Just a date set for activation that wouldn't be in a BIP 8 implementation
11:19 <@michaelfolkson> If (big if as it would get NACKs) Core released a flag day, there would no compatibility whatsoever with a UASF BIP 8(1 year, LOT=true)
11:21 < devrandom> is a modified BIP 8 without MUST_SIGNAL too much of a change?
11:22 <@michaelfolkson> The BIP is unlikely to change. A LOT=false implementation has no MUST_SIGNAL code though
11:22 <@michaelfolkson> (or doesn't need any)
11:22 < devrandom> ah, good point
11:23 < devrandom> well, BIP 8(false) + flag-day in the same codebase would be pretty much what I'm trying to get at
11:23 <@michaelfolkson> This should be in ##taproot-activation channel btw
11:24 < devrandom> OK
12:37 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined ##uasf
12:39 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
12:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 264 seconds]
12:41 -!- lukedashjr is now known as luke-jr
13:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##uasf
13:08 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
13:09 -!- belcher_ is now known as belcher
15:18 < cguida> Has taproot activated on litecoin yet? I remember that happened with segwit and people were encouraged
15:21 < luke-jr> not afaik, but they did MimbleWimble with 75% BIP8 LOT=True
15:22 < cguida> that's a good sign for bip8 lot=true
15:22 < cguida> was it a pretty fast masf?
15:23 < cguida> Also, which pull request should I review, this one https://github.com/bitcoin/bitcoin/pull/19573 or this one https://github.com/bitcoin/bitcoin/pull/21334 ?
15:25 < luke-jr> no idea, I don't really follow scamcoins
15:26 < cguida> guess that's more of a #taproot-activation question
15:26 < luke-jr> cguida: #21334 is part of #19573
15:26 < cguida> haha, nah, litecoin isn't a scamcoin, it's a testnetcoin ;)
15:27 < cguida> luke-jr so both?
15:34 -!- cguida [~cguida@2806:2f0:5020:433a:1fe9:7c7b:dd55:7e3b] has quit [Ping timeout: 258 seconds]
15:45 <@michaelfolkson> cguida: #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
15:47 <@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:47 < luke-jr> michaelfolkson: a rebase would still be #19573
15:48 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has joined ##uasf
15:54 < luke-jr> I propose after cguida finishes his review (and any issues addressed), I do a final update to the BIP8 branch based on #21334, and we merge that into the BA repo
16:12 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined ##uasf
16:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
16:37 -!- Aaronvan_ is now known as AaronvanW
16:37 -!- stortz [b1982408@177.152.36.8] has joined ##uasf
17:11 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
17:12 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has quit [Read error: Connection reset by peer]
17:13 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has joined ##uasf
17:16 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
17:36 < jeremyrubin> For LOT=true, what do we think about lowering the threshold during MUST_SIGNAL
17:36 < jeremyrubin> this diffuses some of the concern about causing a chainsplit, while still being unambiguous
17:37 < jeremyrubin> (we can even use a different bit or overlapping deployments for the MUST_SIGNAL period with no mod to BIP8)
17:38 < jeremyrubin> we just need the # > 2016/2.
17:38 < jeremyrubin> I propose 65% threshold. This means that up to 35% of nodes could be not upgraded miners and we'd not invalidate any of their blocks during MUST_SIGNAL
18:07 < luke-jr> jeremyrubin: I suggested 50%+1 to Matt the other day
18:08 < jeremyrubin> and?
18:08 < luke-jr> he didn't like it because it was a "compromise"
18:08 < jeremyrubin> can you link me to the discussion?
18:08 < jeremyrubin> Forgive me for taking your summary with a grain of salt :)
18:08 < luke-jr> https://www.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/gpkejqt/
18:09 < luke-jr> jeremyrubin: note aj found another flaw with both of these: it means LOT=True nodes will no longer halt if the rest of the community doesn't go along with it
18:09 < luke-jr> in the reduced threshold, the problem is only partial
18:09 < jeremyrubin> that's why I'm proposing 65%
18:09 < jeremyrubin> it's enough that the momentum is on the side of an activation
18:10 < luke-jr> well, that's beside the issue raised ;P
18:10 < jeremyrubin> whereas 50+1 leaves some ambiguity
18:10 < jeremyrubin> I wouldn't rule out Matt over-literally interpreting 50+1
18:10 < luke-jr> the issue is that if the economy *doesn't* back LOT=True, you as a LOT=True user would want to halt and decide further action
18:11 < luke-jr> so it makes users less safe in a mixed network, for no real benefit
18:11 < luke-jr> (well, the only benefit being maybe we could get more people to agree to it..)
18:11 < luke-jr> if Matt would go for it, maybe it'd be an okay tradeoff
18:12 < luke-jr> but absent any benefit, LOT=True as-is seems best IMO
18:12 < luke-jr> (I'm using "Matt" to mean the most extreme anti-LOT=True position)
18:13 < jeremyrubin> it seems matt-aligned prefers SPV mining as an outcome to must_signal
18:13 < jeremyrubin> so with 65% you'd just have 35% spv mining
18:14 < luke-jr> well, even false signalling is fine during MUST_SIGNAL
18:14 < jeremyrubin> and that would take a malicious act from the 65% to trigger
18:14 < luke-jr> we no longer care what miners do at that point
18:14 < jeremyrubin> the issue with false signaling IMO is destructive interference with other overlapped activations
18:14 < jeremyrubin> that is a feature and a bug I guess
18:14 < jeremyrubin> it lets you detect if you actually had enough...
18:14 < luke-jr> ?
18:14 < jeremyrubin> but maybe "edge triggered negative signaling"
18:15 < jeremyrubin> if any prior period has at least 65%, then negative signal during final period
18:15 < jeremyrubin> (can be set up to happen using BIP8 relatively vanilla)
18:15 < luke-jr> seems annoyingly complex
18:16 < jeremyrubin> Ah
18:16 < jeremyrubin> Maybe you can do something bi-polar
18:16 < jeremyrubin> 90% yes --> activates via bip8=false
18:16 < jeremyrubin> 10% yes --> activates via bip8=true
18:17 < luke-jr> no, BIP8 should be internally consistent regardless of LOT
18:17 < luke-jr> that is, LOT=False nodes should activate if LOT=True do
18:17 < jeremyrubin> I think that's not quite possible, right?
18:17 < jeremyrubin> Well this way is actually
18:17 < luke-jr> in the scenario where miners are compliant with LOT=true
18:18 < jeremyrubin> You can remove LOT=true as a parameter
18:19 < jeremyrubin> hmmm maybe not?
18:19 < luke-jr> btw I think we're in the wrong channel for this topic :P
18:19 < jeremyrubin> oh
18:19 < jeremyrubin> ok
20:41 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 260 seconds]
21:02 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##uasf
22:08 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has quit [Ping timeout: 246 seconds]
22:13 -!- cguida [~cguida@2806:2f0:51c1:5cee:8d92:7ab2:1377:7bd0] has joined ##uasf
--- Log closed Fri Mar 05 00:00:47 2021