--- Log opened Fri Feb 05 00:00:36 2021
00:30 -!- Belieffresh [~belieffre@titan.pathogen.is] has quit [K-Lined]
01:08 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
01:09 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
01:10 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
01:11 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
01:45 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
01:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
02:24 < AaronvanW> Benefits of LOW=false outlined bu gmaxwell: https://old.reddit.com/r/Bitcoin/comments/lcjhl6/taproot_activation_pools_will_be_able_to_veto/gm2l02w/
02:24 < AaronvanW> *LOT=false
02:28 < michaelfolkson> Thanks for sharing this AaronvanW
02:34 < michaelfolkson> Another pro for LOT=false I would add is if miners did delay Taproot activation for a year with no rationale LOT=false would never be used again. And this discussion for any future soft forks would not need to happen
02:35 < michaelfolkson> But "If the community happened to be immediately unified behind LOT=true, I wouldn't have any problem supporting it." I agree with
02:36 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has quit [Quit: Quit]
02:37 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined ##taproot-activation
02:43 < nickler> if only there were better methods of measuring community support
02:45 < michaelfolkson> I don't see a path forward (that avoids a long sustained discussion personally I'd like to avoid) other than trying to convince another meeting of LOT=true.
02:47 < michaelfolkson> Especially on the assumption that Core will want clear consensus on LOT=true to include it in a release
02:48 < michaelfolkson> If it is split 60/40 in either direction I think we have to propose LOT=false to the mailing list
03:20 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
03:33 < devrandom> if > 50% of mining power agrees to LOT=true, would that eliminate the arguments against it?
03:50 < michaelfolkson>   I would say no as it depends on whether the minority of the mining power is in strong opposition to it or is apathetic. In my opinion the more data to support LOT=true the better but Luke would say mining preferences are irrelevant
03:52 < michaelfolkson> If you had > 90 percent of mining pools supporting Taproot and supporting BIP 8(true) that would be a stronger signal (at least from the mining pool side, only one constituent)
03:54 < michaelfolkson> But again if users and all the other constituents (eg developers, businesses etc) would prefer LOT=false we should go LOT=false even if miners would prefer LOT=true
03:56 < devrandom> well, a majority of miners being OK with LOT=true seems to remove the chain-split argument against it.  super-majority would be better of course.
03:58 < devrandom> it seems like if the chainsplit argument goes away, then everybody can get on board with it
04:05 < devrandom> I would say the story is: "Taproot is ready, and there's wide consensus.  The activation period is just for coordination to make sure that it doesn't activate before everybody is ready.  1 year is plenty of time for people to be ready, and since we have wide consensus (including > 50% verbal confirmation from miners), there's no risk in activating at the 1 year mark even if 10%-20% are
04:05 < devrandom> asleep at the wheel."
04:27 -!- rdymac [uid31665@gateway/web/irccloud.com/x-cefzuavjxtduzdso] has joined ##taproot-activation
05:05 -!- pinheadm_ [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has quit [Quit: pinheadm_]
05:06 -!- pinheadmz [~pinheadmz@pool-71-105-114-182.nycmny.fios.verizon.net] has joined ##taproot-activation
06:50 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation
06:52 < devrandom> nice summary email michaelfolkson!
06:59 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
07:00 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
07:00 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
07:01 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
07:13 < michaelfolkson> Thanks devrandom
07:13 < michaelfolkson> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
07:22 -!- belcher_ is now known as belcher
07:42 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
07:42 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
07:44 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
07:45 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
07:45 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
07:46 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##taproot-activation
08:28 -!- whuha [4f99f264@100.red-79-153-242.dynamicip.rima-tde.net] has joined ##taproot-activation
08:37 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
08:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
09:15 -!- th0th [~th0th@gateway/tor-sasl/th0th] has left ##taproot-activation ["Leaving"]
09:30 < dr_orlovsky> aj: thank you for the PR https://github.com/bitcoin/bips/pull/1063. LGTM. michaelfolkson: will be nice to review it on the next meeting
09:42 -!- bob333 [~bob@46.28.204.21] has joined ##taproot-activation
10:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
10:07 < michaelfolkson> Sounds good dr_orlovsky
10:17 -!- whuha [4f99f264@100.red-79-153-242.dynamicip.rima-tde.net] has quit [Quit: Connection closed]
10:28 -!- norisgOG [~norisgOG@dslb-088-066-245-006.088.066.pools.vodafone-ip.de] has quit [Ping timeout: 240 seconds]
10:44 < dr_orlovsky> General consideration after reading rounds of discussion.
10:45 < dr_orlovsky> 1. We should be frank. If activating taproot IS a MADE decision, than LOT=true. Playing "we don't what users to feel that it is pushed by devs" does not makes sense, since it implies voting and the fact that the decision to activate WAS NOT MADE!
10:47 < dr_orlovsky> 2. If you'd like to say "let's community decide whether to activate taproot" THAN (and only than) you should provide a WAY of setting the flag for LOT explicitly: in GUI, in command line; do not provide defailt value and require the flag to be present
10:49 < dr_orlovsky> so either the decision to activate taproot is made => and than LOT=true and can't be changed by users
10:50 < dr_orlovsky> - or decision on activation is left to the community (not miners), and there is no LOT flag default
10:55 < darosior> dr_orlovsky: I don't get the purpose of forcing LOT=true given the current situation where miners are willing to activate Taproot. As a demonstration ? IMHO it's a pretty bad demonstration, everything is shown already: BIP8 is here and fixes BIP9 vulnerabilities. We can use emergency triggers if an exploit is attempted, no incentive for bad actors
10:55 < darosior> to even try it. At this point i believe that circular bikeshedding to use LOT=true instead of a conservative LOT=false is going to create more friction than anything else.
10:58 < dr_orlovsky> I said nothing about proposing LOT=true. I said that there is a logic, either one or the second. Otherwise the position looks "iesuitic". I am not saying somebody has that position, I am just pointing out that on the internal inconsistency in arguments "decision is made, but LOT=false" and "community should vote, LOT=false|true"
10:58 < dr_orlovsky> Simple algorithm:
10:59 < dr_orlovsky> is decision is made on taproot activation? If yes, than it must activate, so LOT=true. Decision IS made
10:59 < dr_orlovsky> otherwise, be frank: there is no decision
10:59 < dr_orlovsky> sp if you don't want to challenge miners, it implies they have a right to vote and you just trust them to vote in a right way this time
11:01 < darosior> I believe it's a nuance: i find LOT=true to be a stronger decision (made by whom??) than LOT=false
11:02 < dr_orlovsky> I think there might be three decision-making processes around bitcoin softforks:
11:03 < dr_orlovsky> 1) decision by the community based on active participation in discussions/review/BIP review/Bitcoin Core PR review/mailing list. If there is no opposition and convergence in opinion of those, who participated, this is the first type of decision
11:03 < dr_orlovsky> its mostly informal, but very obvious fact (at least in case of Taproot)
11:04 < dr_orlovsky> 2) decision by all nodes using their flags and upgrading. This is decision by all of the community
11:04 < dr_orlovsky> 3) decision by miners hash-power
11:04 < dr_orlovsky> (2) and (3) IS the voting
11:05 < dr_orlovsky> So I think we need to decide which kind of taproot activation decision Bitcoin Core - or broad community - is looking for
11:05 < dr_orlovsky> before discussing LOT=true|false further
11:06 < dr_orlovsky> There might be a complex setups, like "we take Bitcoin Core changes basing on (1), but let miners vote (3) leaving users opportunity to veto that vote (2) with LOT=true automatic UASF"
11:06 < dr_orlovsky> but this IS NOT "a decision to activate is made", it is "we have a complex governance process involving all parties, including miners"
11:07 < dr_orlovsky> and "would like to take the responsibility off from Bitcoin Core team"
11:07 < dr_orlovsky> that is fine! But than a default value for LOT MUST NOT BE SET by Bitcoin Core team! Otherwise you contradict to yourself!
11:29 < luke-jr> dr_orlovsky: if users haven't decided, then even a MASF is unacceptable ;)
11:29 < luke-jr> darosior: LOT=false was *the* major BIP9 vulnerability
11:38 < dr_orlovsky> like-jr: these three de-facto existing decision options of course can be inconsisted with each other, leaking to different forms of chain splits & value loss
11:39 < dr_orlovsky> users always can veto with choosing which software to run, whether not to upgrade, writing their own software
11:39 < dr_orlovsky> miners can always veto but not mining blocks under certain conditions
11:40 < dr_orlovsky> active community (=devs in a more broad sense than simply Bitcoin Core) can always veto by stopping contributing and leaving network without development, moving to other alternative implementations/chains
11:41 < dr_orlovsky> so all can veto. The question is rather what they are willing to take as a risk in case they will reach inconsistent state, the chain will split and who will loose value
11:41 < dr_orlovsky> and here where the search for the consensus begins as with each non-zero sum game
11:42 < dr_orlovsky> UASF is a move in the game that made obvious to miners that they will loose more than they are willing to loose - and withdraw their veto
11:42 < dr_orlovsky> (under that specific historical conditions)
11:43 < dr_orlovsky> As far as I understand, Bitcoin Core as a part of "active community" (a) does not take the responsibility for all active community decision even if there was a consensus according to the (1) process above
11:44 < dr_orlovsky> why? Because it wants to feel miners and users unforced, i.e. leaving decision to them and withdrawing the right to decide from the active community which already made a decision
11:46 < dr_orlovsky> LOT=false says "Miners and users are more important in decision process than active developers & contributors community and they have to vote on the support. If they will vote inconsistently or vote agains we will use our power to force them to witthdraw, but will not push them at the beginning to the correct decision which we already took"
11:46 < dr_orlovsky> this looks ... odd
11:47 < dr_orlovsky> If you'd like to give power to bitcoin node users, leave LOT unset and ask on the first launch which value should be used for it
11:48 < dr_orlovsky> Thus, I find reasons behind LOT=true and LOT=unset, but LOT=false seems like a way to provoke future contradictions and increase the risk of inconsistent community state - or using UASF after
12:04 < michaelfolkson> If we can get clear consensus on LOT=true I am happy with it, Greg said he was happy with it on Reddit, obviously Luke is happy with it, sounds like you would be happy with it too dr_orlovsky
12:05 < dr_orlovsky> I will be happy with a clear decision making process, when the game theory model does not get into clash because on political correctness reasons
12:05 < michaelfolkson> If we can't get clear consensus on it we are asking Core to set LOT=true against recent historical precedent and without clear consensus
12:06 < dr_orlovsky> I still belive that not setting default for LOT is also a valid option
12:06 < dr_orlovsky> strange that is not being considered
12:06 < michaelfolkson> harding (I agree) doesn't like leaving it up to users when Core are best qualified to make the judgement
12:06 < michaelfolkson> I'll paste his argument here, give me a sec
12:06 < dr_orlovsky> well, than you have to make a decision!
12:07 < dr_orlovsky> and the decision is ether not to activate at all or LOT=true
12:07 < michaelfolkson> I really don't like the idea of forcing users to have to choose variables.  I think the dev team, with their superior knowledge of the technical situation, should choose reasonable defaults.  For early taproot deployment, when there's reasonable belief that miners will activate taproot, LOT=false seems like a reasonable default to me.  If a few months pass and that proves not to be the case, a new minor version can be
12:07 < michaelfolkson>  released with LOT=true.
12:07 < michaelfolkson> Although I'm not opposed to making it a configuration variable from the start, I think for the same reason it doesn't need to be an option initially.  If it seems like the default should be changed, then the configuration variable can be introduced then in the same minor version.
12:07 < dr_orlovsky> LOT=false is NOT a decision but delegation of the decision to miners/users with ability to force miners to users decision later
12:09 < michaelfolkson> I am sympathetic to that argument. If you can get clear consensus on it we haven't got a problem
12:09 < dr_orlovsky> IF bitcoin_core_mades_decision THAN made_decision() ELSE IF minders_decide() != users_decide() THAN uasf() ELSE miners_decide() END
12:09 < michaelfolkson> Speaking for myself now. The previous messages were harding quotes
12:11 < dr_orlovsky> * IF bitcoin_core_makes_decision THAN make_decision() /* meaning LOT=true */ ELSE miners_decision = minders_decide(); IF miners_decision != users_decision() THAN uasf() ELSE miners_decision END
12:11 < michaelfolkson> The decision that Taproot should be activated has already been made in my opinion. This isn't a decision on whether to activate, it is a decision on the exact timing of the activation and who makes that final decision
12:12 < dr_orlovsky> michaelfolkson: abolutely agree. I don't believe in voting. If you'd like to participate, became active part of the community and come here, to GitHub, bitcoin-dev mail list etc
12:12 < dr_orlovsky> I belive into >1) decision by the community based on active participation in discussions/review/BIP review/Bitcoin Core PR review/mailing list. If there is no opposition and convergence in opinion of those, who participated, this is the first type of decision
12:13 < dr_orlovsky> You will face "developers decides"? Answer "yes, we decide". Why? Because we act.
12:14 < dr_orlovsky> If you 'd like to decide, re-compile without that flag. Fund dev team that will do it for you. Split off the chain - since we are willing to take that risk with UASF anyway
12:14 < dr_orlovsky> that is how I'd answer if I were part of the Bitcoin Core
12:16 < michaelfolkson> We are just individuals dr_orlovsky :) We can't speak for Core or the community more broadly
12:16 < michaelfolkson> Convince the community, get clear consensus, go to Core with clear consensus on LOT=true
12:18 < dr_orlovsky> That's what I am doing :)
12:18 < michaelfolkson> Haha agreed
12:28 < dr_orlovsky> Few days ago I had no position on LOT. Now, my logic moves to "I need more privacy in bitcoin. Thus, I need taproot. It's against the world trend, so there is a danger. The active community converged on taproot activation. Thus, we must act: the active part of the community. Acting implies making activation invietable and leaving governments no chance to intervene and push miners or users. UASF is a mess. Thus, LOT=true"
12:28 < luke-jr> dr_orlovsky: miners cannot veto; if they stop mining, someone else will start
12:29 < dr_orlovsky> they can provoke split which is the only form of veto avalaible in bitcoin for anybody
12:29 < luke-jr> michaelfolkson: FWIW, my Twitter poll seems to have LOT=true 2x vs LOT=false
12:32 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
12:32 < michaelfolkson> Can you post a link luke-jr? I can't seem to find it. A data point to bring up in the LOT meeting
12:33 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
12:34 < michaelfolkson> https://twitter.com/LukeDashjr/status/1356705119983857665?s=20
12:38 < luke-jr> wow, 75% now
12:38 < luke-jr> err, that's only looking at the delay alternative
12:38 < luke-jr> still, almost 3x ☺
13:39 < nickler> twitter polls... really?
13:41 < michaelfolkson> Any data is better than zero data
13:41  * michaelfolkson shrugs
13:42 < michaelfolkson> We all understand the limitations of Twitter polls
13:44 < belcher> my peer review on that poll is the question seem a bit biased, we know how a question is worded can change the outcome substantially
13:46 < michaelfolkson> If there is robust opposition in that scheduled meeting I don't think LOT=true can happen regardless of Twitter polls
13:46 < belcher> its worth doing another one that emphasises the point about core devs being perceived as forcing it onto users, not sure of the exact wording but something like "have core devs activate taproot? yes/no"
13:47 < belcher> i just realized now that even if a huge amount of users want LOT=true, core devs might still want to set LOT=false to protect themselves from being attacked due to perceived centralization.... users dont have to put up with those attacks but core devs do
13:48 < michaelfolkson> It is possible, I keep saying there needs to be clear consensus on LOT=true for it to stand a chance imo
13:49 < michaelfolkson> But all we can do is try to get that clear consensus and propose it to Core and the mailing list
13:58 < devrandom> it seems to me that consensus has already been achieved for taproot, and the consensus already *includes miners*.  There was plenty of time to object during the development process and PR reviews.  there were no objections and in fact there are > 80% verbal indications by hash power.  given that, we are merely coordinating the timing of the activation.  however, we can't be assured of any
13:58 < devrandom> particular threshold signalling activation because of the potential for politics entering into it or other extraneous reasons.  there could be, for example, hidden pressure on miners that we are not aware of.  or some fraction could be busy with other things.  given that there is already consensus, it seems like that should be embodied in a commitment to activate.
13:58 < waxwing> "UASF fallback" is not a way to characterize lot=true, considering exactly what was discussed in the meeting, i.e. that people could UASF later after lot=false was chosen at the start as the default.
13:58 < waxwing> so unless i misunderstood something, luke-jr that poll doesn't really say anything about lot=true?
13:59 < waxwing> hmm on reflection i think i must indeed have misunderstood the thread of what's being said here.
14:00 < darosior> devrandom: why do you think it should necessarily be embodied in a commitment to activate?
14:01 < devrandom> it seems strange that there is a consensus to activate, yet we are configuring the software so that it may fail to activate
14:02 < devrandom> (if, let's say, 15% of mining power for some reason doesn't or can't signal)
14:02 < darosior> It seems strange to me to put a commitment to force activation if there is no need to
14:03 < darosior> (In addition, we can still add a commitment later it's not as if setting LOT=false was ruining the opportunity to react to a (highly hypothetical) attack)
14:14 < devrandom> darosior: why not force activation if it is globally agreed that activation is desired?  doesn't that embody the will of the community better?
14:15 < devrandom> is some option kept open by doing that?  (I don't see what that option is)
14:17 < darosior> devrandom: to me forcing a consensus rule change in the software is a nuclear option. Not that LOT=false leaves more options (though it arguably does) but it is just less scary as a first shot
14:19 < devrandom> darosior: are you referring to potential bugs in taproot?  or are you concerned that some entities are against taproot but have not come out and said it?
14:20 < darosior> Neither
14:20 < darosior> i just feel like it would be setting a precedent
14:23 < devrandom> you mean a future soft-fork that doesn't have universal support, but people would feel obligated to activate?
14:28 < darosior> Yes as well as more globally anything enabled by "we already did it once" (and obviously SegWit and 8y-old soft forks don't have the same context) and slowly shifting to something normal.
14:28 < darosior> I like to think of Bitcoin as being hard to change :)
14:31 < devrandom> if you have an unpopular feature incorporated into a release with lot=true, the community can fight back with a different release that will cleanly fork once the other activates
14:32 < devrandom> hopefully devs listen to the community and this shouldn't ever happen
14:33 < devrandom> (cleanly fork = different soft fork, not hard fork)
14:35 < devrandom> Core, or any other group, can't dictate what the users run
15:56 < luke-jr> waxwing: LOT=true *is* the fallback UASF..
15:56 < luke-jr> nickler: Twitter polls have been amazingly reliable historically
15:57 < luke-jr> belcher: a poll emphasising a falsehood is not a useful poll ;)
16:02 < luke-jr> especially a falsehood like that where the exact opposite *is* true (devs deploying a miner veto without community support WOULD be the devs forcing it on users)
16:04 < luke-jr> darosior: giving miners a veto power is a nuclear option
16:17 < belcher> its not a veto because it can be overriden
16:25 < luke-jr> belcher: it makes no sense to set it false and then override
16:25 < luke-jr> why deploy code to do X at time Y, when you fully intend to deploy with !X at time Y before time Y?
16:26 < luke-jr> the only reason is if there's an intent to actually do X
16:31 < belcher> one argument is we might not know who is "you", its a decentralized system after all
16:31 < luke-jr> that's not an argument, it's pedantics
16:31 < belcher> if "you" is the core devs then they have that argument that they'd be seen as deciding the protocol rules
16:32 < luke-jr> not any more than shipping a MASF, or LOT=false
16:33 < luke-jr> or even doing nothing at all, as we've seen
16:50 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
17:06 -!- rotten [~rottensox@unaffiliated/rottensox] has quit [Quit: rotten]
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
18:14 -!- belcher_ is now known as belcher
22:08 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
23:30 -!- CARO1 [~Cesar@2804:7f4:c19b:8c80:f1e9:6184:953b:115d] has quit [Ping timeout: 272 seconds]
--- Log closed Sat Feb 06 00:00:38 2021