--- Log opened Sat Feb 13 00:00:28 2021
00:15 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
00:15 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
00:49 -!- Netsplit *.net <-> *.split quits: sturles, bitconner, queip, drolmer, meshcollider, sanketcell, devrandom, nehan, schmidty, gwillen,  (+6 more, use /NETSPLIT to show all of them)
00:52 -!- nkuttler [~nkuttler@unaffiliated/nkuttler] has joined ##taproot-activation
00:52 -!- hebasto [sid449604@gateway/web/irccloud.com/x-diwgzwdyfnohchvk] has joined ##taproot-activation
00:52 -!- sturles [~sturles@unaffiliated/sturles] has joined ##taproot-activation
00:52 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation
00:52 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-iztdehhgiceanbhh] has joined ##taproot-activation
00:52 -!- schmidty [sid297174@gateway/web/irccloud.com/x-xvvlfkntomjeacbw] has joined ##taproot-activation
00:52 -!- nehan [~nehan@41.213.196.104.bc.googleusercontent.com] has joined ##taproot-activation
00:52 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-ztbgtmmgbhzmstiq] has quit [Ping timeout: 240 seconds]
00:52 -!- devrandom [~devrandom@unaffiliated/niftyzero1] has joined ##taproot-activation
00:52 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined ##taproot-activation
00:52 -!- willcl_ark [~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net] has joined ##taproot-activation
00:52 -!- yunier2002 [~yunier200@c-73-85-126-91.hsd1.fl.comcast.net] has joined ##taproot-activation
00:52 -!- niftynei [~niftynei@104.131.77.55] has joined ##taproot-activation
00:52 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-rnsccjsdeotbttyd] has quit [Ping timeout: 244 seconds]
00:53 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-txzphximekrisacx] has quit [Ping timeout: 268 seconds]
00:53 -!- nkuttler [~nkuttler@unaffiliated/nkuttler] has quit [Max SendQ exceeded]
00:53 -!- queip [~queip@unaffiliated/rezurus] has quit [Max SendQ exceeded]
00:53 -!- jamesob [sid180710@gateway/web/irccloud.com/x-zrkgoizuznjfbmdh] has quit [Ping timeout: 264 seconds]
00:56 -!- jamesob [sid180710@gateway/web/irccloud.com/session] has joined ##taproot-activation
00:56 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation
00:56 -!- bitconner [~root@138.68.244.82] has joined ##taproot-activation
00:56 -!- drolmer [~drolmer@unaffiliated/drolmer] has joined ##taproot-activation
00:56 -!- sanketcell [~sanketcel@ec2-100-24-255-95.compute-1.amazonaws.com] has joined ##taproot-activation
00:56 -!- jamesob [sid180710@gateway/web/irccloud.com/session] has quit [Changing host]
00:56 -!- jamesob [sid180710@gateway/web/irccloud.com/x-pzwbgahsafxohxhq] has joined ##taproot-activation
00:59 -!- nkuttler [~nkuttler@unaffiliated/nkuttler] has joined ##taproot-activation
01:01 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-euyphuspntddllnf] has joined ##taproot-activation
01:02 -!- nkuttler [~nkuttler@unaffiliated/nkuttler] has left ##taproot-activation []
01:26 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-tjesrlazvsywizfs] has joined ##taproot-activation
01:27 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-taqsizgbtpmoxcnx] has joined ##taproot-activation
01:34 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-oxastgasszlqmlqv] has joined ##taproot-activation
01:42 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-oxastgasszlqmlqv] has quit [Ping timeout: 240 seconds]
01:42 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-tjesrlazvsywizfs] has quit [Ping timeout: 246 seconds]
01:43 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-taqsizgbtpmoxcnx] has quit [Ping timeout: 268 seconds]
02:38 -!- robert_spigler [robertspig@gateway/shell/matrix.org/x-ygwwwiqyielnmezr] has joined ##taproot-activation
02:48 -!- ensuremoonrise[m [ensuremoon@gateway/shell/matrix.org/x-jmrwwjyvkvilovot] has joined ##taproot-activation
02:53 -!- mitjavoll[m] [mitjavollm@gateway/shell/matrix.org/x-zszrofkcdwmtfrcy] has joined ##taproot-activation
03:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:48 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
05:08 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
05:09 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
05:19 <@michaelfolkson> Do we want to share and look at your Google Doc during the meeting on Tuesday luke-jr? Or should we wait until it is completed before distributing more widely?
05:21 <@michaelfolkson> Oh you've already suggested this "Thoughts on polishing this at the meeting, for publication as the proposal?"
05:21 <@michaelfolkson> Ok cool, let's look over it after the LOT discussion
05:22 <@michaelfolkson> (in the meeting)
06:04 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
06:04 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
06:13 -!- jonatack [~jon@37.164.198.87] has joined ##taproot-activation
06:18 <@michaelfolkson> "I'm actually writing a reply to the mailing list post right now with one or two additional "F" points.  :-)" Is this mailing list post going to be sent before Tuesday harding?
06:18 <@michaelfolkson> I keep checking the mailing list for it :)
06:18 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
06:51 -!- jonatack [~jon@37.164.198.87] has quit [Read error: Connection reset by peer]
06:51 -!- jonatack [~jon@37.164.198.87] has joined ##taproot-activation
07:05 <@michaelfolkson> I'm sure my answer to this could be improved. I'll try to improve it but feel free to suggest edits or provide an alternative answer https://bitcoin.stackexchange.com/questions/102585/what-is-the-benefit-of-forced-signaling-in-a-soft-fork-activation-mechanism/
07:15 < harding> michaelfolkson: isn't the MUST_SIGNAL forced signaling to activate the soft fork in all nodes using LOT=false?
07:15 < harding> activate enforcement*
07:18 <@michaelfolkson> Oh... you mean Core set LOT=true but some users change the software to LOT=false and so MUST_SIGNAL forced signaling is there to make sure those users don't stop the soft fork from activating?
07:18 < harding> E.g. I run a node with LOT=false; everyone else runs a node with LOT=true. At block xxxxxx, y'all start enforcing taproots rules, but I never saw any signal, so I continue treating taproot transactions as anyone-can-spend, which is bad for me personally.  If there are a lot of people with LOT=false, it also makes it unclear whether taproot is really being enforced, increasing the risk that miners may try to steal funds send to taproot
07:18 < harding> outputs.
07:19 <@michaelfolkson> Ok... that makes more sense
07:19 <@michaelfolkson> Thanks
07:20 < harding> And, yeah, I'll try to finish up my mailing list post.  Sorry for the delay.
07:21 <@michaelfolkson> It is ok. Would be good to have them before Tuesday so they can be discussed in that meeting. Thanks
08:12 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
08:13 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
08:24 -!- jonatack [~jon@37.164.198.87] has quit [Ping timeout: 256 seconds]
08:29 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
08:33 < harding> michaelfolkson: email sent (usually takes a few minutes to go through).
08:34 <@michaelfolkson> harding: Great, will discuss here after I've seen it
08:38 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has quit [Ping timeout: 272 seconds]
08:41 -!- jonatack [~jon@37.164.198.87] has joined ##taproot-activation
08:47 -!- jonatack [~jon@37.164.198.87] has quit [Ping timeout: 256 seconds]
08:47 -!- jonatack [~jon@37.164.198.87] has joined ##taproot-activation
09:18 < luke-jr> michaelfolkson: the primary purpose is to definitively indicate the softfork is active on the chain. while it still relies on enforcement, this ensures there is no dispute over what the correct rules are.
09:19 < luke-jr> and as a side effect also makes it easy for any group of dissenters to reject the new rules
09:20 < luke-jr> (the intent of a softfork should never be to literally force new rules on anyway - that would be malice)
09:27 <@michaelfolkson> Ok thanks luke-jr. Will add this to the answer
09:31 <@michaelfolkson> So there is a touch of disagreement with your two answers here. I will include both but harding said "to activate enforcement"
09:32 <@michaelfolkson> I'll include both and make it clear that they aren't entirely in alignment
09:34 < luke-jr> michaelfolkson: disagreement how? note I am saying these are *in addition* to the points Harding made
09:34 < luke-jr> the signal accomplishes multiple things; I expect there are probably a few more I am overlooking atm
09:35 <@michaelfolkson> Maybe just a misunderstanding on my part then
09:35 <@michaelfolkson> I have "makes it easy for any group of dissenters to reject the new rules" from you and "activate enforcement" when there is LOT=false dissent from harding
09:36 < luke-jr> LOT=false is not dissent
09:36 < luke-jr> neither is non-upgrading
09:36 < luke-jr> dissent is like the bcashers, who absolutely rejected Segwit
09:36 <@michaelfolkson> Dissent against the actual soft fork, rather than dissent against lot=true
09:36 <@michaelfolkson> Ok gotcha
09:36 < luke-jr> right
09:37 < luke-jr> if you *really* reject Segwit, and the community decides to activate it anyway, you can fork off to a new chain by rejecting the signalling chain
09:38 <@michaelfolkson> This is one point that I liked from the Matt Corallo podcast. Differentiating between the actual soft fork consensus changes and the activation mechanism consensus changes. You could dissent to either, none or both
09:39 < luke-jr> but dissenting to the activation mechanism only makes sense when the mechanism fails; it's silly to say "I want Segwit active, but I refuse to use the chain it's active on because of pedantics" :P
09:40 < luke-jr> in that case, you're fighting against yourself more than anyone else XD
09:41 <@michaelfolkson> Ok updated answer: https://bitcoin.stackexchange.com/questions/102585/what-is-the-benefit-of-forced-signaling-in-a-soft-fork-activation-mechanism/
09:43 < luke-jr> michaelfolkson: would prefer not tying the activation method to Bitcoin Core like that
09:43 <@michaelfolkson> Ok... it is a simplification, granted but in essence that's what we care about. What Core sets the parameter to
09:43 < luke-jr> Bitcoin Core shouldn't be treated as some kind of authority over the network
09:44 <@michaelfolkson> Do you agree that it is the "reference implementation"?
09:44 < luke-jr> no
09:45 <@michaelfolkson> Or just the most widely used implementation of the Bitcoin protocol?
09:45 < luke-jr> it would be nice if it was, but it hasn't been for a long time
09:45 < luke-jr> clearly, and that's a bad thing that one implementation has such extensive use :P
09:50 < harding> It doesn't make sense to have multiple implementations unless people significantly disagree about how an implementation should work.  Otherwise you're just duplicating work and splitting review resources.
09:50 < harding> (Assuming all implementations are free software.)
09:52 < luke-jr> harding: at least when using the same codebase, reviews can be shared
09:52 < luke-jr> harding: and when Core is forcing exclusive politics, there should be more disagreement about it
09:57 < harding> luke-jr: I think that (if true, which I don't think it is) is covered by my point that "it doesn't make sense to have multiple implementations unless people significantly *disagree about how an implementation should work*."
09:57 < nothingmuch> what does "exclusive politics" mean in this context?
09:58 < luke-jr> nothingmuch: eg, forcing miners to use Core's big-block feerate biases, and excluding any options that are actually good for the network
09:59 < nothingmuch> thanks
10:07 < nothingmuch> something that is perhaps out of scope but i've been wondering about - i can't recall and don't really know how to search for dissenting opinions re activation, not even bad faith ones. am i just not looking in the right places?
10:08 < luke-jr> ?
10:08 < nothingmuch> i've seen a bit of FUD about Taproot, but basically only saying that it's not as good as the hype
10:08 < harding> nothingmuch: you mean people who don't want taproot?
10:08 < nothingmuch> yeah, i can't recall a single anti-Taproot opinion (regardless of whether or not i think it's valid or not)
10:09 < nothingmuch> even what I would consider FUD is basically "yeah it's good but not that good"
10:09 < luke-jr> there's some FUD out there claiming Taproot hurts privacy
10:09 < luke-jr> which is complete nonsense ofc
10:10 < nothingmuch> but even that criticism conceded that it's nothing technical and expected to be transient if it does get adopted
10:11 < harding> nothingmuch: here's the only technical criticism I'm aware of: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017618.html .  I'd briefly summarize it as "taproot would be better as MAST+Schnorr separately".  A longer summary is here: https://bitcoinops.org/en/newsletters/2020/02/19/#discussion-about-taproot-versus-alternatives
10:11 < luke-jr> nothingmuch: eh?
10:11 < nothingmuch> luke-jr: if i remember the original twitter thread about it, you could substitute "taproot" for literally anything else that might reduce the usage of other address types
10:12 < nothingmuch> harding: thanks!
10:12 < nothingmuch> luke-jr: in this sense i don't think it was criticism of Taproot itself, but (bad faith) criticism of *any* kind of change
10:13 < midnight> w 17
10:15 < nothingmuch> erm, any kind of change that introduces a new address type
10:15 < luke-jr> sure
10:18 < midnight> The anti-taproot idiot is the blockchair guy who happens to be involved with chainalysis type block analysis.
10:19 < midnight> The theory of taproot being anti-privacy is exactly his, and began with him.
10:31 <@michaelfolkson> harding thoughts on LOT=true versus LOT=false: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
10:33 <@michaelfolkson> I think the challenge to "defaulting to LOT=false makes non-activation possible even if people run the code that developers provide" is should LOT=true *ever* be set in an implementation like Core?
10:34 <@michaelfolkson> I can see the argument if you think it never should
10:35 <@michaelfolkson> If it ever can the question becomes what is that bar for LOT being set to true?
10:36 < luke-jr> harding:  i might suggest changing "makes non-activation possible" to "doesn't activate" - not only is it possible, but it *requires* third-party action to make it happen
10:37 < luke-jr> it's an interesting argument. I will need time to digest it.
10:37 < luke-jr> (curiously enough, I didn't get that out of gmaxwell's post!)
10:38 <@michaelfolkson> One thing you said earlier in on this channel harding (which basically inspired T3 funnily enough) is you don't think users should be put in situation where they are forced to make informed judgements when developers understand issues better
10:39 <@michaelfolkson> (paraphrasing, I'll find the exact quote)
10:41 <@michaelfolkson> So that leaves Core (or another implementation) always setting LOT=false. Users shouldn't be expected to change LOT from false to true. Which only leaves an independent party releasing a LOT=true software version in the case that miners continuously fail to activate
10:41 < harding> luke-jr: yeah, "makes non-activation possible" is also unweildly to write.  I chose that phrasing because I feel like saying "doesn't activate" or some more concise variation might incorrectly give the impression that we only get one try to activate a particular soft fork, whereas any failure for political or fixable technical reasons is just a temporary setback IMO.
10:42 < luke-jr> harding: well, anything to activate without a third-party actor would defeat the point you made ;)
10:42 < harding> michaelfolkson: yeah, I noticed that about T3.  :-)
10:43 < luke-jr> [18:38:57] <michaelfolkson> One thing you said earlier in on this channel harding (which basically inspired T3 funnily enough) is you don't think users should be put in situation where they are forced to make informed judgements when developers understand issues better <-- that's just a developer oligarchy, which is just as problematic as a miner oligarchy
10:43 <@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
10:43 <@michaelfolkson>  released with LOT=true."
10:44 <@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."
10:44 <@michaelfolkson> Those are the original harding quotes
10:44 < luke-jr> *ever* releasing with LOT=true defeats the argument of F7
10:47 <@michaelfolkson> Yeah that is the challenge. It is either never (regardless of circumstances) or a question of what bar needs to be reached for it to be ok
10:47 < harding> I'd agree that it seriously weakens it.  However, if there are a significant numbef of users requesting it, and perhaps many already running a BIP148-like fork of the software that has LOT=true in response to miner non-signaling in absent of actual problems, then I think it doesn't completely undermine the argument that there's strong evidence of non-developers making decisions about fundamental protocol changes.
10:49 < luke-jr> harding: well, I would say there needs to be such evidence before releasing *any* activation ;)
10:51 < luke-jr> devs *shouldn't* ship a protocol change, not even miner-activated, if there is a question about community acceptance
10:52 < luke-jr> otherwise it's essentially just devs conspiring with miners, very similar to NYA
10:53 < luke-jr> michaelfolkson: on another note, I wonder if part of Matt's disagreement stems from a misunderstanding of these meetings - that we're just forming a proposal, rather than deciding anything here
10:53 < harding> luke-jr: one piece of evidence I don't think can be completely obtained before releasing activation-ready software is whether users will actually run the code.  They might say they will, but so also are miners saying they'll activate taproot.  Until we know that many people are actually running economically relevant code that will actually enforce taproot's rules (if an activation signal is received/executed), do we actually know for sure
10:53 < harding> that we have consensus?
10:53 < luke-jr> (I think I phrased the last part backward, but hopefully you get what I mean)
10:54 < luke-jr> harding: we don't need consensus, just sufficient community support. and if they lie to us, that's on them :p
10:54 < nothingmuch> the political component of F7 feels symmetric to me, but i think there's a crucial difference which is that if the default is LOT=true then we would learn that people explicitly opted out of activation only after the fact
10:57 < harding> luke-jr: isn't it on the users of the taproot-enforcing software (LOT=true||false) if they start enforcing the rules as a very small minority and then miners violate the rules and steal their taproot outputs?
10:58 < luke-jr> harding: what scenario are you thinking of? I'm not hearing Taproot from merely a small minority..
11:01 < harding> Just the case where we have bad information.  The businesses and miners who supported S2X thought they'd be successful, I assume, so it seems possible to me that we could also misgauge our situation.
11:03 < harding> My point is just that seeing people actually upgrade to 0.21.1 (or whatever) is an additional piece of strong evidence, but not one that we can possibly have before choosing the parameters that software will use.
11:05 < harding> (Many things doomed S2X, but I think one of the points that persuaded its proponents that it was dead was that almost nobody ran jgarzik's software.  In that sense, it was an effective realty check, and maybe it's a realty check Bitcoin Core devs would want to use before setting LOT=true and committing any users of it to a possible minorty hashrate chain.)
11:05 < luke-jr> NYA knew their position was controversial
11:06 < luke-jr> how could they not?
11:19 < harding> I'm not sure they knew how controversial it was at the time they signed.  And, sure, that's in part because (AFAIK) they seemed to be actively avoiding talking to anyone outside of the business or mining segments.  But I'm not sure how many of the people I've talked to about taproot actually run economic full nodes, so it's possible I also have a blind spot.  Seeing people upgrade their nodes to 0.21.1 would be useful evidence IMO (though
11:19 < harding> how many of those nodes are economic nodes, we won't know).
11:33 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
11:49 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
11:53 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
11:54 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 256 seconds]
13:13 -!- jonatack_ [~jon@37.164.57.52] has joined ##taproot-activation
13:16 -!- jonatack [~jon@37.164.198.87] has quit [Ping timeout: 256 seconds]
13:47 -!- CARO1 [~Cesar@2804:7f4:c19d:f7fa:8873:33e8:2101:7f5f] has joined ##taproot-activation
13:48 -!- CARO2 [~Cesar@2804:7f4:c19d:f7fa:bdc8:d47e:8c15:d22a] has quit [Ping timeout: 272 seconds]
13:58 -!- CARO1 [~Cesar@2804:7f4:c19d:f7fa:8873:33e8:2101:7f5f] has quit [Quit: Leaving.]
14:31 -!- jonatack_ [~jon@37.164.57.52] has quit [Quit: jonatack_]
14:32 -!- jonatack [~jon@37.164.57.52] has joined ##taproot-activation
14:48 -!- jonatack [~jon@37.164.57.52] has quit [Read error: Connection reset by peer]
14:48 -!- jonatack_ [~jon@37.164.57.52] has joined ##taproot-activation
14:56 -!- jonatack_ [~jon@37.164.57.52] has quit [Read error: Connection reset by peer]
14:56 -!- jonatack__ [~jon@37.164.57.52] has joined ##taproot-activation
15:03 -!- jonatack__ [~jon@37.164.57.52] has quit [Quit: jonatack__]
15:03 -!- jonatack [~jon@37.164.57.52] has joined ##taproot-activation
15:34 -!- jonatack [~jon@37.164.57.52] has quit [Read error: Connection reset by peer]
15:36 -!- jonatack [~jon@37.164.57.52] has joined ##taproot-activation
15:37 -!- jonatack [~jon@37.164.57.52] has quit [Read error: Connection reset by peer]
15:37 -!- jonatack_ [~jon@37.164.57.52] has joined ##taproot-activation
15:42 -!- jonatack_ [~jon@37.164.57.52] has quit [Read error: Connection reset by peer]
15:43 -!- jonatack_ [~jon@37.164.57.52] has joined ##taproot-activation
16:00 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Write error: Connection reset by peer]
16:00 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Read error: Connection reset by peer]
16:00 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Read error: Connection reset by peer]
16:06 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation
16:17 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
16:27 -!- jonatack__ [~jon@37.164.57.52] has joined ##taproot-activation
16:28 -!- jonatack_ [~jon@37.164.57.52] has quit [Read error: Connection reset by peer]
16:28 -!- jonatack__ [~jon@37.164.57.52] has quit [Client Quit]
16:29 -!- jonatack [~jon@37.164.57.52] has joined ##taproot-activation
17:09 < aj> "<luke-jr> NYA knew their position was controversial" -- (a) segwit was also controversial to a similar degree, but we didn't withdraw it as a result of the controversy; (b) at least initially, i think they many of them did sincerely believe the objections to 2x were about the same level as current objections to taproot; ie people complaining on social media without any real merit to their
17:09 < aj> objections; i think we've fixed things (via optech and more embedded devs and the like) so that we won't have quite the same miscommunication in future at least
17:13 < luke-jr> aj: the controversy was fundamentally different
17:13 < luke-jr> 2X was opposed by users whom it harmed
17:14 < luke-jr> Segwit did similar harm, but wasn't opposed for that reason
17:14 < aj> luke-jr: segwit was opposed by users who it harmed, they just never explained why they were harmed
17:14 < aj> luke-jr: and by the time other people figured it out, there was too much anger to want to do them any favours
17:15 < aj> ("users" being "asicboost using miners/asic-manufacturers")
17:16 < luke-jr> hmm
17:17 < luke-jr> I think that harm was pretty exclusively on the mining side, though, not the user side
17:17 < aj> miners are users imo
17:21 < luke-jr> they are also users, but this is clearly the miner role, not the user role
17:21 < luke-jr> additionally, the "loss" was stolen - they weren't supposed to be able to cheat
17:23 < aj> hmm, asicboost patent had a "final rejection mailed" on 29th sept 2020, but there's interview things as of 27/29th jan 2021 :(
17:24 < aj> us pto application number is 15/141,063
17:26 < luke-jr> on what grounds was it rejected?
17:30 < harding> I see it as still in pending here: https://patents.google.com/patent/US20170243176A1/en
17:32 < aj> https://www.uspto.gov/patents/apply/checking-application-status/check-filing-status-your-patent-application  -> public PAIR -> 15/141063 as application number -> transaction history
17:33 < aj> there's no useful details
17:36 < aj> apparently asicboost patent got granted in south korea and europe?
17:38 -!- amptwo [segwitmatr@gateway/shell/matrix.org/x-ynpwvsgwktrqaqpi] has joined ##taproot-activation
17:41 < aj> seems like it got granted in europe in august https://register.epo.org/application?number=EP14864642&tab=main&lng=en
17:45 < aj> and ebang's suing samsung over it in korea https://www.streetinsider.com/Press+Releases/EBON%3A+becoming+Qualcomm+to+the+Mining+Hardware+Industry/17751714.html as of end of december just gone
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer]
17:58 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
20:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
21:25 -!- jonatack [~jon@37.164.57.52] has quit [Ping timeout: 264 seconds]
22:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
23:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 272 seconds]
--- Log closed Sun Feb 14 00:00:29 2021