--- Log opened Sat Feb 06 00:00:38 2021
01:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:49 < michaelfolkson> If we could try to refer to arguments in here from now on this would be really helpful to me as I can monitor the discussion on each argument https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
02:49 < michaelfolkson> If I am missing any in this email then this would also be useful to know
02:50 < michaelfolkson> Each argument is labelled T1, T2 etc for true and F1, F2 etc for false
02:51 < michaelfolkson> Either refer to say T2 or make it clear you think you have a new argument that isn't covered by T1, T2 etc in the email to the mailing list
02:51 < michaelfolkson> Thanks
02:53 < michaelfolkson> The "Core may not agree to set LOT=true" is deliberately not included as if there is clear consensus on LOT=true there is no reason not to propose it to Core
02:54 < michaelfolkson> All we can do is get clear consensus on it and propose it to Core. Then it is out of this channel's hands
03:11 < devrandom> re F6 - do we actually know of miners that believe that LOT=true is antagonistic?  has there been any communication about this either way?
03:11 < michaelfolkson> Personally no but I can ask
03:15 < devrandom> a related question - how would people feel about a BIP8(1y, false), but with a reduction of threshold to 75% or 50% after 6 months?  for me it captures a lot of LOT=true - prevent a small minority from stalling something that there is consensus for.
03:17 < michaelfolkson> So effectively Decreasing Threshold Soft Fork Activation but in one phase
03:18 < michaelfolkson> https://en.bitcoin.it/wiki/Taproot_activation_proposals#Decreasing_Threshold_Soft-Fork_Activation.2C_BIP8.28false.2C_6m.29.2BNoAction.281y.29.2BBIP8.28true.2C_2.5y.29
03:18 < michaelfolkson> Personally I'd like not to go back to the beginning of this whole discussion and start from scratch :)
03:19 < michaelfolkson> If that happens I'm stepping away and leaving to others
03:19 < michaelfolkson> But people are free to do that if they wish
03:21 < michaelfolkson> I see the next meeting at making a decision on LOT being true or LOT being false
03:21 < devrandom> SGTM
03:49 -!- CARO1 [~Cesar@2804:7f4:c19b:8c80:7c61:3803:a661:9c9e] has joined ##taproot-activation
03:57 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds]
04:33 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation
04:44 < waxwing> michaelfolkson, since this turned out to be pretty much the only contentious point, it might be worth somehow structuring the discussion to focus on whether people are *not* prepared to accept their second favorite option
04:44 < waxwing> i suspect i am in a large majority who is happy for it to go forward with the other option than the one i prefer
04:45 < michaelfolkson> Yeah I think we try that towards the end
04:45 < michaelfolkson> (of the meeting)
04:45 < michaelfolkson> Discussion of the arguments first
04:47 < michaelfolkson> The aim is for people to decide what their preferred option is and whether they would be willing to go with the second option instead
04:49 < michaelfolkson> Ignoring what their perception of the current state of consensus is initially
04:52 < michaelfolkson> I think my preferred option is LOT=true but I'm also happy with LOT=false. I will try to stay as neutral as I can though
05:02 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
05:02 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has left ##taproot-activation []
05:02 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
05:08 < maybehuman> Hello! I (mostly) read up on recent discussions and just wanted to drop this here:
05:08 < maybehuman> IMO lot=true puts an enormous amount of responsibility on the Core maintainers, because in the end it will be their actions that get taproot activated.
05:08 < maybehuman> luke-jr's counter argument to this seems to be that the maintainers are just executors of the community's will, but that's just another way to say "I was just following orders"
05:08 < maybehuman> So whatever else exists in the way of arguments, I don't think it's fair to put all this on so few shoulders
05:16 < maybehuman> To make an extremely weird analogy: In a firing squad, one of the rifles is usually loaded with blanks. That's what makes it psychologically bearable for the participating soldiers. lot=false has a similar effect (yes, it's a weird analogy, but I hope you know what I'm trying to say)
05:18 < michaelfolkson> I get your point and I think it is a good faith argument
05:19 < michaelfolkson> I would say the point of this channel (if there ie one) is to attempt to get clear consensus and then propose it to Core
05:20 < michaelfolkson> Remember Core contributors are allowed to engage in this discussion too
05:21 < michaelfolkson> If Core doesn't want to implement what we propose that is their prerogative
05:22 < michaelfolkson> I would personally strongly NACK a firing squad whether one of the rifles was loaded with blanks or not
05:23 < maybehuman> Sure, they can say no. But if you approach them saying "we've spent months discussing this and everyone is behind this idea" that puts a certain pressure on them to say yes
05:23 < michaelfolkson> And I would hope others would too so that Core is never asked to implement a firing squad of any form
05:23 < maybehuman> and if they say no, you're back to the drawing board
05:23 < michaelfolkson> Back to the drawing board is fine
05:24 < michaelfolkson> For my personal individual involvement in this discussion that is the end. But I really do not matter
05:25 < michaelfolkson> Someone else will pick up the discussion at a later point from the drawing board
05:26 < maybehuman> Well, like I said, I just wanted to drop this here as food for thought. IMO lot=true is asking too much of the maintainers. But I really do not matter either :-)
05:27 < michaelfolkson> Thanks for dropping by, it is an interesting challenge
05:28 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
05:56 < michaelfolkson> I guess the only other thing I'd say about that is if any Core contributors think asking Core to implement lot=true is any way comparable to implementing a firing squad please reach out (privately if necessary).
05:57 < michaelfolkson> Obviously I'd need a signed message to know you are representing the individual you say you are
05:58 < michaelfolkson> But I'd delete it and wouldn't make it public
06:03 < michaelfolkson> Gmail isn't great so here is a protonmail email
06:03 < michaelfolkson> taprootactivation@protonmail.com
06:06 -!- sturles [~sturles@unaffiliated/sturles] has joined ##taproot-activation
06:22 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
06:29 < maybehuman> michaelfolkson: Don't get disctracted by the (admittedly unsettling) imagery, my point was really about personal responsibility. lot=false gives you an out, as in "when I merge this, it might go this way or that. The odds may be 99:1, but it's not up to me". With lot=true it's inescapably on you (as the maintainer)
06:29 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
06:33 < luke-jr> >implying there's something wrong with "following orders" when those orders aren't wrong
06:33 < luke-jr> (not that the rest of the argument is sane either)
06:35 < michaelfolkson> We are going to start getting very philosophical and start hitting religion and all sorts at this point lol
06:35 < michaelfolkson> Not going there
06:36 < michaelfolkson> I think you are very certain what is right and wrong. I am less certain
06:37 < michaelfolkson> There are some things I am certain are wrong. There are other things I am not certain about
06:37 < michaelfolkson> I am not certain about this LOT=true or false decision
06:38 < michaelfolkson> I also don't think it is as important as you seem to think
06:38  * michaelfolkson shrugs
06:43 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
06:44 < maybehuman> BTWm I found it interesting to re-read some of the old bip-148 discussions, e.g. http://www.erisian.com.au/bitcoin-core-dev/log-2017-05-17.html and some of https://github.com/bitcoin/bitcoin/pull/10417  (lot=true is a bit like automatic uasf, no?)
06:50 < michaelfolkson> Thanks for the links
06:52 < michaelfolkson> SegWit activation was a very different scenario to Taproot activation. There wasn't the same overwhelming level of community consensus for SegWit (if you include businesses and miners) as there is Taproot
06:52 < michaelfolkson> Tbh from what I know from 2017 I wouldn't have supported BIP 148 in 2017
06:53 < belcher> yes, there was also issues like asicboost which made it much more do-or-die, lots of people felt that if asicboost wasnt solved then bitcoin would die and therefore they were willing to risk bitcoin dying over bip148
06:53 < belcher> or if not dying then at least having a damaging long-lasting chain split
06:56 < michaelfolkson> So my individual view. I would have NACKed BIP 148 in 2017 but I'm happy to ACK lot=true for Taproot today. And if a similar scenario to SegWit arose for a future soft fork I would consider NACKing lot=true then
06:57 < michaelfolkson> Obviously that is a sample size of 1
06:58 < michaelfolkson> (my individual view)
07:03 < belcher> many core developers in 2017 did indeed not support bip148
07:03 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
07:03 < belcher> it was never in core
07:03 < belcher> so that matches historically
07:10 < mol_> michaelfolkson, are you saying there's an overwhelming support for Taproot among miners and businesses? is there data somewhere we can see?
07:12 < michaelfolkson> mol_: For mining pools we do https://taprootactivation.com/
07:13 < michaelfolkson> We have had employees of businesses express support for Taproot. And no signs of opposition like we did in 2017 from business leadership
07:13 < michaelfolkson> Certainly no New York Agreement type stuff
07:16 < mol_> ah cool, thank you :)
07:40 < luke-jr> michaelfolkson: yes, there was the same level community support behind Segwit
07:40 < luke-jr> michaelfolkson: including miners
07:41 < luke-jr> belcher: because Core decided ALL devs had to support it to merge
07:42 < luke-jr> belcher: which is not a comparable situation to LOT=true
07:42 < luke-jr> michaelfolkson: NYA was long after Segwit activation began, and even after BIP148
08:06 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 258 seconds]
08:29 < michaelfolkson> And there were no signs of those business leaders' views months in advance of NYA hmmm
08:31 < michaelfolkson> I wasn't involved but it was painful to even follow. There seemed no end in sight for years
08:31 < michaelfolkson> Regardless... ancient history. Taproot activation is not the same challenge as SegWit activation. I am certain of that
08:33 < luke-jr> there are some differences, but most of the difference lies in the assumption we learned from 2017 and don't do LOT=false again :P
08:36 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
08:37 < maybehuman> Well, I would say segwit probably needed it and taproot probably won't
08:50 < luke-jr> it's like moore's law. you need it only when you don't have it. ;)
08:50 < luke-jr> maybe not moore.. I forget which
08:51 < luke-jr> murphey maybe
08:53 < maybehuman> Still, I wonder: If Core had actually intitally released segwit with the equivalent of lot=true, wouldn't that have made thigns only worse?
08:55 < mol_> maybehuman, segwit activation was based on bip9
08:56 < mol_> michaelfolkson, the community support for segwit was overwhelming by the count of nodes running the segwit code back then
08:58 < michaelfolkson> mol_: That was my impression too though I don't have data re nodes
09:00 < maybehuman> mol_ yes I know. I'm just wondering if it would have gone any smoother if it had been initially released with bip8(1y, true) or if that would have only made it worse
09:13 -!- jonatack [~jon@88.124.242.136] has joined ##taproot-activation
09:14 < michaelfolkson> I suspect Bitmain, other miner opposition would have just refused to run it
09:17 < michaelfolkson> It was always going to be a challenging activation, just the nature of the winds back then
09:18 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 265 seconds]
09:20 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
09:21 < luke-jr> maybehuman: no, strictly better
09:22 < luke-jr> michaelfolkson: refusing to run it wouldn't do them any good, so why wouldn't they run it?
09:23 < michaelfolkson> For SegWit? Because they wanted SegWit2x?
09:24 < luke-jr> doesn't matter, there would be nothing they could do to stop Segwit
09:24 < luke-jr> besides, 2X wasn't even a thing until very late
09:24 < mol_> and it didn't work lol
09:24 < luke-jr> probably it would never have been a thing if Segwit had LOT=true from the start
09:24 < mol_> off by one lol
09:25 < michaelfolkson> > probably it would never have been a thing if Segwit had LOT=true from the start
09:25 < michaelfolkson> That is a bold claim haha
09:25 < michaelfolkson> I can't disprove it but it is bold
09:27 < michaelfolkson> There was that whole "replace Core" narrative
09:29 < luke-jr> which became bcash
10:22 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
10:53 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 265 seconds]
12:03 -!- darosior [~darosior@194.36.189.246] has quit [Quit: Ping timeout (120 seconds)]
12:03 -!- darosior [~darosior@194.36.189.246] has joined ##taproot-activation
13:29 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
13:36 -!- rdymac [uid31665@gateway/web/irccloud.com/x-cefzuavjxtduzdso] has quit [Quit: Connection closed for inactivity]
13:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
17:24 -!- fiatjaf2 [~fiatjaf@2804:7f2:298a:709b:ea40:f2ff:fe85:d2dc] has quit [Ping timeout: 272 seconds]
17:26 -!- fiatjaf2 [~fiatjaf@2804:7f2:2a8c:9df7:ea40:f2ff:fe85:d2dc] has joined ##taproot-activation
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
20:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds]
22:40 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
--- Log closed Sun Feb 07 00:00:38 2021