--- Log opened Wed Jul 22 00:00:27 2020
01:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:25 -!- jeremyrubin [~jr@2601:645:c200:f539:c03f:40d9:1aa8:e444] has quit [Ping timeout: 260 seconds]
01:50 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has joined ##taproot-activation
01:56 -!- jonatack [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 256 seconds]
02:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
02:47 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
02:54 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
03:26 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation
03:43 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
03:53 -!- reallll [~belcher@unaffiliated/belcher] has joined ##taproot-activation
03:57 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
04:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Client Quit]
04:03 -!- reallll is now known as belcher
05:30 -!- drolmer_ [~drolmer@unaffiliated/drolmer] has joined ##taproot-activation
05:30 -!- drolmer_ is now known as drolmer
05:41 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Ping timeout: 246 seconds]
05:47 -!- horst1 [~ckarl@ip5f5a0425.dynamic.kabel-deutschland.de] has joined ##taproot-activation
05:57 -!- bobazY [~N_Ivarsso@82-197-218-97.dsl.cambrium.nl] has joined ##taproot-activation
06:18 -!- BananoStreet [b2399086@178.57.144.134] has joined ##taproot-activation
06:18 -!- BananoStreet [b2399086@178.57.144.134] has left ##taproot-activation []
06:18 -!- BananoStreet [b2399086@178.57.144.134] has joined ##taproot-activation
07:04 -!- slivera [~slivera@103.231.88.27] has quit [Remote host closed the connection]
07:22 -!- Davterra [~Davterra@37.120.208.245] has joined ##taproot-activation
07:24 -!- brg444 [uid207215@gateway/web/irccloud.com/x-wqssdnxhavmjjjhl] has joined ##taproot-activation
07:25 -!- BananoStreet [b2399086@178.57.144.134] has quit [Remote host closed the connection]
08:21 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined ##taproot-activation
08:25 < Victorsueca> Hi there, as per my message in #bitcoin and belcher's request to mention it here, I was wondering, isn't BIP8's activates-by-the-end-of-timeout a bit of a harsh method to activate a soft fork?
08:27 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has joined ##taproot-activation
08:27 < roconnor> There might be a couple things to be aware of.  As I understand BIP8(ture) (which is what we have been calling BIP8-activate-by-default-at-the-end-of-timeout) as written requires manditory version signaling period (at the time of LOCKIN?).
08:29 < belcher> from #bitcoin: <Victorsueca> After what happened with SegWit and miners using covert asicboost, it's clear that 5% of mining power can't be trusted to hold a feature hostage. So, I was reading about BIP8 and it got me wondering, what happens if a BIP8 soft fork activates by timeut, but only 50%-ish of users have upgraded their nodes to support it? Isn't activates-by-the-end-of-timeout a bit of a harsh method to activate a soft fork?
08:29 < roconnor> The second thing to be aware of is that users of Bitcoin are ultimately who is responsible for enforcing the consensus rules of Bitcoin, and miner signalling is simply a coordination measure that they use amoung themselves to avoid having their blocks orphaned.
08:29 < somethingsomethi> Victorsueca: If you look at the gist with the proposals currently under discussion, you'll see that except for one, they all start with a doesnt-activate-by-the-end-of-timeout stage. So I guess it's currently mostly viewed as a fallback
08:29 < belcher> even with just 50% of the economic user base there's still the intolerant-minority effects
08:29 < somethingsomethi> as in "we've tried to do this the nice way, but now we're stepping it up"
08:31 < roconnor> Thus if miners don't want to coordinate to avoid orphaning blocks, then that is their loss. (I mean it is also users loss too due to lower security.  The incentives are aligned here.)
08:31 < belcher> Victorsueca read this for an explanation of the intolerant minority https://medium.com/@alpalpalp/user-activated-soft-forks-and-the-intolerant-minority-a54e57869f57
08:32 < belcher> it predicts that miners will basically be forced to upgrade to a taproot-supporting full node even if just 50% of the economy wants it
08:33 -!- somethingsomethi [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
08:37 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
08:37 < Victorsueca> I can see how the economy can force miners to upgrade, but what if it's the more general part of the economy the ones that are not upgrading? Speaking of BIP8 as a general method for activating soft forks in the future and not just taproot, what if wallet developers were to push a BIP8 softfork that the general public doesn't want, but some people do, and to make matters worse, let's say that soft fork comes bundled with
08:37 < Victorsueca> important bugfixes that are never backported
08:37 < Victorsueca> Wouldn't that basically take us to the pre-BIP9 days?
08:38 < belcher> Victorsueca one way to defend against an evil soft fork is to deploy your own counter-soft-fork
08:38 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
08:38 < belcher> for example, in 2017 if the big blockers could've tried deploying their own UASF which made the first block after the bip148 1st august flag day be _required_ to not signal for segwit
08:39 < roconnor> Victorsueca: FWIW, I beleive Bitcoin Core has a policy of not bundling soft-fork activation with important bugfixes.
08:39 < belcher> i very much doubt they wouldve succeeded because big blockers never had much support in the full-node-using economy
08:39 < belcher> roconnor even so, one day the group called bitcoin core might become corrupted, so we bitcoiners cant just rely on their policy
08:40 < roconnor> Absoultely.  You should stop using Bitcoin Core if they do bundle soft forks with bugfixes (that aren't backported).
08:40 < belcher> yep, and presumably adopt the counter-soft-fork node software instead
08:40 < belcher> it always comes down to the fact that the definition of a coin is set by those who are willing to receive it as payment in exchange for something
08:41 < belcher> the bitcoin economy has to be on the lookout for evil soft forks and be ready to resist (fortunately it isnt too hard, just download a new node and start using it)
08:41 < roconnor> Victorsueca: the BIP8(true) timelines proposals are all 1 year or to help everyone coordinate themselves to guard against splits in the economy.
08:41 < belcher> but this concern of "what if someone uses UASF for bad things" is a common concern, but i dont think its very likely because the bitcoin economy will never support something thats bad for them
08:41 < roconnor> Victorsueca: It is worth noting that BIP9(false) doesn't really solve the split issue either.
08:42 < roconnor> Victorsueca: while miners might enforce the new rules among themselves, if users are not enforcing the rules, or if only half the economy is, then there is a perpetual risk that miners just stop enforcing the new rules.
08:49 < Victorsueca> Got it, but I'm still kinda worried about what I said back in #bitcoin. Say it's not miners the ones that we are trying to force into what the economy wants, but rather that it's the 50% of the users who want something and the other 50% that do not want it
08:50 < Victorsueca> basically, there is no notable majority in the economy, and even if the economy is supposed to impose what they want, it's not even clear what would that be
08:51 < Victorsueca> So, 50% of users grab theselves the soft-fork node, and the other 50% grab themselves the counter-soft-fork version of the node
08:52 < roconnor> Definitely a real concern.  I think there has been a bunch of outreach with respect to taproot itself (and it is worth emphasising that taproot is design to have almost no impact, or even positive impact, on those people who do not wish to use taproot), and nothing has been heard back.  Many of the activation proposals have an initial BIP8(false) period to observe uptake in the taproot-enable codebase.
08:52 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has joined ##taproot-activation
08:52 < roconnor> and wouldn't proceed with their BIP8(true) follow up or accellerated activation if such a split were observed.
08:53 < roconnor> er, I don't mean nothing has been heard back, not concerns have been heard back that haven't been addressed.
08:55 < belcher> Victorsueca well if 50% of a group completely disagree with the other 50% then no technology can save the group, they'll be a split
08:55 < roconnor> IIRC there was an anonymous post listing taproot concerns that was posted to the mailing list where their concerns were addressed, and I think mostly stemmed from some technical misunderstandings about taproot.
08:55 < belcher> fortunately we're nowhere near that situation
08:55 < somethingsomethi> I guess if the split was 50/50 between those who want it and those who don't, that would pretty much mean that the proposal will be abandoned, no?
08:56 < somethingsomethi> The interesting question would be what is the lowest amount of support that seems acceptable? (ignoring for the moment that this is hard to measure)
08:56 < belcher> in practice it might happen in the future in something like some regulated exchanges want a soft fork to add KYC to the protocol, and everyone else disagrees, and then we get this SF and counter-SF split... i think its unlikely though, exchanges would much rather just collect trading fees in peace
08:56 < roconnor> I think there is lots of evidince of nearly universal support for taproot and even after searching I don't think there is any evidice to the contrary.
08:56 < somethingsomethi> e.g. if say 30% were against it for some reason, but 70% want it, should it go ahead?
08:57 < belcher> somethingsomethi in bitcoin nobody can ever force other people to adopt something, so in your situation there'd be a split with 30:70
08:58 < belcher> the intolerant minority effect only works if the majority is apathetic
08:58 < roconnor> Given the great outreach that optech and others have done, I don't think there is any reason not to proceed.
08:58 < belcher> agreed
08:59 < belcher> this is an interesting discussion about hypothetical stuff, but its very very far away from the taproot situation
09:00 < somethingsomethi> belcher: well, the 70% could also decide it's not worth the trouble and that they'd rather keep the community whole
09:00 < somethingsomethi> but yes, I also think this discussion is very hypothetical
09:00 < belcher> thats just another way of saying they dont care enough, if they value unity over this new feature
09:00 < belcher> (or bug rather than feature, if they see it as an evil soft fork)
09:02 < Victorsueca> I can agree that there seems to be quite a positive ambien when it comes to taproot, including myself, after reading about it for a while I can say I like the idea too. But I'm pondeiring about BIP8 as an activation method for future soft forks where there may not be a notable consensus, or even worse, people are being missinformed into rejecting ideas that they would otherwise accept
09:03 < somethingsomethi> I think this will probably go more smoothly if we focus on the soft-fork at hand instead of trying to come up with a general solution for all potential future changes
09:05 < roconnor> I don't feel that taproots activation necessarily sets a precident for ALL future soft fork changes.  All softforks are unique and while it may establish precidents for similar soft forks, in this case simlar soft-forks seems to mean soft-forks that don't affect non-users of the feature, bring some benefits to non-suers of the feature, and appear to have universal support.
09:05 < somethingsomethi> maybe that's something that should be communicated once a decision has been reached. Something along the lines of "we believe this to be the best method for activating taproot. It is not meant as a template for all future soft forks. they should instead be evaluated on a case by cases basis"
09:06 < roconnor> sounds good to me.
09:07 < Victorsueca> Yep, considering which activation method should be used for each specific soft fork sounds like a good plan
09:12 < roconnor> I think there are a lot of people like you who are both in favour of taproot but are worried that no everyone else is.  I think that is a great and healthy attitude and I'm glad so many people have it.
09:13 < roconnor> However, it seems the people that do not support taproot that we are all concerned about cannot be found.
09:15 < roconnor> Furthermore there is also no known way for such people to be harmed if taproot is depolyed due to the nature of the taproot proposal.
09:16 < Victorsueca> I've been thinking reasons for why would someone not be in favour of taproot based on what I've read, but the only one I could think of is that they have been mislead about what it does or how it works
09:18 < somethingsomethi> I think it's mostyl an aftereffect of the whole segwit drama. Everyone is extra cautious to try to avoid a repeat of that
09:20 < somethingsomethi> too cautious, I would almost say. The (totally anecdotal and unscientific) feeling I get is rather that for many people taproot risks becoming something like the flying cars we were promised in the fifties, i.e. far away scifi stuff
09:20 < belcher> agreed, its been said that a lot of us have shell shock from 2017, which is unnecessary now
09:37 -!- jeremyrubin [~jr@2601:645:c200:f539:c03f:40d9:1aa8:e444] has joined ##taproot-activation
09:38 < aj> roconnor: "there has been a bunch of outreach with respect to taproot itself" "nothing has been heard back" -- there's been a bunch of things heard back, but (i believe) all of it's either had satisfactory explanations, or there's been changes to improve taproot so the concerns raised are addressed
09:39 < aj> roconnor: (there hasn't been a lot of outreach to non developers though)
09:45 < jeremyrubin> aj: recommend everyone join https://t.me/bips_activation which has 230 participants mostly non developers
10:03 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined ##taproot-activation
10:06 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 260 seconds]
10:07 < roconnor> aj: There has been pinned posts in reddit AFAIU.  There was that recent london bitcoin meetup taproot discussion (or is that devs)?
10:07 < roconnor> aj: optech AFAIU can reach exchanges and other businesses.
10:08 < aj> roconnor: it seemed pretty dev-y from the content? good point about reddit
10:08 < aj> i think of optech as pretty dev-y as well
10:08 < aj> maybe i have a broad definition of dev
10:08 < roconnor> Who isn't a dev and how can we reach them? :D
10:09 < aj> investors, business-side folks
10:09 < aj> no idea
10:09 < jeremyrubin> You either die a user or live long enough to become a dev
10:09 < roconnor> Bitcoin Magazine articles.
10:09 < roconnor> obviously they have had taproot articles.
10:10 < roconnor> Less sure about non-english language media.
10:12 < somethingsomethi> you think bitmex blog is something business types would read? Because I have a feeling jeremyrubin might know who to talk to to get something published there :-)
10:12 < somethingsomethi> congratz on the grant btw!
10:12 < jeremyrubin> I think they -- and really any excahnge -- would be unlikely to publish something about an activation
10:13 < jeremyrubin> best person to ask here is instagibbs most likely
10:13 < roconnor> are we talking about taproot out reach or taproot activation outreach?
10:14 < somethingsomethi> why not both?
10:14 < jeremyrubin> Either I guess? My experiences exchanges wish to remain apolitical and fork avoidant
10:15 < jeremyrubin> N.B. that the BitMEX grant is directed towards my mempool infrastructure work
10:16 < somethingsomethi> I mean the question is a bit if outreach should be part of the discussion of this channel at all. We could also say we separate concerns and really only deal with activation related stuff
10:16 < belcher> it should be said, iv seen talk by people on reddit who say they favour making sure everything is slow and steady in case the bitcoin network and value it protects is put at risk
10:17 < belcher> so that should rule out very fast activations like bip8(true, 1month)
10:17 < belcher> people on reddit who arent devs* i mean
10:19 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined ##taproot-activation
10:19 < jeremyrubin> It does generally point to that devs shouldn't worry as much about being conservative
10:19 < jeremyrubin> Because  users should/will take on that mantle
10:21 < somethingsomethi> belcher: Actually I think 1month activation cycle is not /that/ fast if you consider it probably will only start after the release of 0.21.1, i.e. 8 months or so from now. that's plenty of time to make preparations and have discussions and such
10:22 < roconnor> Is activation in 0.20.x off the table?
10:22 < jeremyrubin> I think we've discussed this before there's no reason taproot can't be in 20.x
10:22 < roconnor> asking for a friend. ;)
10:22 < roconnor> seems like it isn't off the table.
10:23 < somethingsomethi> if nobody else does it, I'll bring it up in tomorrow's bitcoin irc meeting
10:23 < somethingsomethi> (assuming I can even post there, I've never tried :-))
10:25 < somethingsomethi> (no wait, I actually tried once and it was shown on my client, but nowhere else. irc is weird..)
10:25 < aj> roconnor: depends on if the libsecp update is reasonable to backport, maybe?
10:25 < jeremyrubin> Is it a backport if 20.x is still the latest version?
10:26 < jeremyrubin> or you mean if it doesn't require breaking changes neccesitating it be in a maj release?
10:27 < aj> pulling patches from master into the current release is a backport terminology-wise aiui
10:28 < somethingsomethi> yeah, it's different branches that have diverged already
10:28 < aj> https://github.com/bitcoin/bitcoin/pull/18973 eg
10:28 < roconnor> aj: oh that's a good point.  I don't know.
10:29 < roconnor> If we could answer the question as to whether 0.20.x activation is feasible or not, that would be helpful to know.
10:30 < somethingsomethi> like I said, just bring it up at tomorrow's irc meeting in bitcoin-core-dev
10:32 < somethingsomethi> my guess would be it's a hard no, but I'd love to be proven wrong
10:34 < aj> roconnor: fwiw, i think backporting an updated secp release would be plausible for 0.20
10:36 < aj> https://github.com/bitcoin/bitcoin/pull/9340 was a secp backport for 0.13 but for a fix not a feature, i think?
10:45 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Quit: Gone frying asparagus or my Windows had a BSOD]
10:53 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
11:18 -!- roconnor [~roconnor@host-45-78-242-158.dyn.295.ca] has quit [Ping timeout: 264 seconds]
11:18 -!- roconnor_ [~roconnor@host-45-78-193-20.dyn.295.ca] has joined ##taproot-activation
11:21 -!- roconnor_ is now known as roconnor
11:52 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
12:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
12:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
12:35 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
12:40 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
13:05 -!- roconnor [~roconnor@host-45-78-193-20.dyn.295.ca] has quit [Ping timeout: 260 seconds]
13:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]
13:27 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
13:29 -!- roconnor [~roconnor@host-45-78-193-20.dyn.295.ca] has joined ##taproot-activation
14:05 -!- slivera [~slivera@103.231.88.27] has joined ##taproot-activation
14:05 -!- Tralfaz [~Davterra@37.120.208.253] has joined ##taproot-activation
14:06 -!- Davterra [~Davterra@37.120.208.245] has quit [Ping timeout: 240 seconds]
14:08 -!- Tralfaz [~Davterra@37.120.208.253] has quit [Read error: Connection reset by peer]
14:22 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
14:32 -!- joerodgers [~joerodger@141.98.255.152] has quit [Quit: Leaving]
14:37 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined ##taproot-activation
14:51 -!- Davterra [~Davterra@37.120.208.253] has joined ##taproot-activation
14:52 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
14:54 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
14:57 -!- zfrohardt [49539482@c-73-83-148-130.hsd1.wa.comcast.net] has joined ##taproot-activation
15:18 -!- horst1 [~ckarl@ip5f5a0425.dynamic.kabel-deutschland.de] has quit [Ping timeout: 260 seconds]
15:36 -!- zfrohardt [49539482@c-73-83-148-130.hsd1.wa.comcast.net] has quit [Remote host closed the connection]
15:46 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
16:02 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
16:03 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
16:15 -!- GoldmanSats_ [sid428607@gateway/web/irccloud.com/x-bfidrsrbunxbrmwi] has joined ##taproot-activation
16:21 -!- GoldmanSats_ [sid428607@gateway/web/irccloud.com/x-bfidrsrbunxbrmwi] has quit []
16:21 -!- GoldmanSats [sid428607@gateway/web/irccloud.com/x-uewlrukodyfemgkq] has joined ##taproot-activation
16:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds]
16:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:58 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
16:59 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
17:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
17:14 -!- slivera [~slivera@103.231.88.27] has quit [Remote host closed the connection]
17:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
17:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
17:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
18:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
18:27 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
19:37 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
19:50 -!- brg444 [uid207215@gateway/web/irccloud.com/x-wqssdnxhavmjjjhl] has quit [Quit: Connection closed for inactivity]
20:07 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
20:10 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
20:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
20:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
21:32 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation
21:36 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
22:00 -!- rottensox [~rottensox@unaffiliated/rottensox] has joined ##taproot-activation
22:26 < jonatack> I've been receiving requests from non-dev people who would like to know what they can do to help activate taproot
22:27 < jonatack> they see *years* from now as being despairingly slow
22:27 < jonatack> (talk of years, anyway)
22:39 < fanquake> aj: I also wouldn't mind another secp update (for master) so we can pull in the fix for: https://github.com/bitcoin-core/secp256k1/issues/768
22:40 < fanquake> somethingsomethi: if you want to propose  a meeting topic ahead of time, you can post a message like
22:40 < fanquake> #proposedmeetingtopic the-proposed-meeting-topic
22:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
22:54 < aj> roconnor: omg, i'm dense. backporting wtxid relay to 0.20 would probably be hard, and without that relaying taproot txs in 0.20 would probably be spammy, that's probably a bigget problem for taproot in 0.20 than secp. unless taproot in blocks but without actually relaying taproot spends at the mempool is an option for 0.20 maybe
23:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds]
23:29 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds]
--- Log closed Thu Jul 23 00:00:27 2020