--- Log opened Tue Mar 02 07:44:27 2021
07:44 -!- gnusha [~gnusha@unaffiliated/kanzure/bot/gnusha] has joined ##uasf
07:44 -!- Topic for ##uasf: Development of a Taproot activation implementation with default LOT=true https://github.com/BitcoinActivation
07:44 -!- Topic set by michaelfolkson [~michaelfo@2a03:b0c0:1:e0::23d:d001] [Mon Mar  1 03:07:30 2021]
07:44 [Users ##uasf]
07:44 [@ChanServ      ] [ AaronvanW] [ ghost43] [ luke-jr       ] [ qubenix       ] [ waxwing] 
07:44 [@michaelfolkson] [ belcher  ] [ gnusha ] [ nothingmuch   ] [ queip         ] [ windsok] 
07:44 [ _0x0ff        ] [ brg444   ] [ grubles] [ nvk           ] [ robert_spigler] 
07:44 [ _andrewtoth_  ] [ DeanGuss ] [ jcorgan] [ peterrizzo_136] [ RusAlex       ] 
07:44 -!- Irssi: ##uasf: Total of 22 nicks [2 ops, 0 halfops, 0 voices, 20 normal]
07:44 -!- Channel ##uasf created Mon Apr 10 08:31:48 2017
07:44 -!- Irssi: Join to ##uasf was synced in 1 secs
07:44 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined ##uasf
07:45 < kanzure> logs http://gnusha.org/uasf/
07:45 -!- bcf2c2w3 [5f5bd70a@ip5f5bd70a.dynamic.kabel-deutschland.de] has joined ##uasf
08:03 -!- bcf2c2w3 [5f5bd70a@ip5f5bd70a.dynamic.kabel-deutschland.de] has quit [Quit: Connection closed]
08:03 -!- mode/##uasf [+o belcher] by ChanServ
08:03 -!- mode/##uasf [+g] by belcher
08:03 <@belcher> ty kanzure
08:04 -!- belcher changed the topic of ##uasf to: Development of a Taproot activation implementation with default LOT=true https://github.com/BitcoinActivation | logs http://gnusha.org/uasf/
08:04 -!- mode/##uasf [-o belcher] by belcher
08:04 -!- peterrizzo [~peterrizz@ool-44c18924.dyn.optonline.net] has joined ##uasf
08:05 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has joined ##uasf
08:06 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has quit [Client Quit]
08:06 -!- nvk1 [~nvk@37.120.244.210] has joined ##uasf
08:06 -!- nvk [~nvk@68.71.244.34] has quit [Read error: Connection reset by peer]
08:20 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined ##uasf
08:23 < windsok> .
08:29 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has quit [Remote host closed the connection]
08:33 -!- nvk1 [~nvk@37.120.244.210] has quit [Quit: Leaving.]
08:33 -!- nvk [~nvk@68.71.244.78] has joined ##uasf
08:39 -!- mol [~mol@unaffiliated/molly] has joined ##uasf
08:41 < mol> queip, the slack group was the most dynamite for our last battle for segwit activation
08:47 -!- nvk1 [~nvk@194.59.250.202] has joined ##uasf
08:47 -!- nvk [~nvk@68.71.244.78] has quit [Read error: Connection reset by peer]
08:47 -!- nvk1 [~nvk@194.59.250.202] has quit [Client Quit]
09:24 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has joined ##uasf
09:25 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has quit [Read error: Connection reset by peer]
09:32 -!- prayank [~Prayank@2409:4053:2e1b:69dd:ad75:b355:dcd:efff] has joined ##uasf
09:54 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##uasf
09:56 -!- nvk [~nvk@static-198-54-132-86.cust.tzulo.com] has joined ##uasf
10:00 -!- nvk_ [~nvk@89.36.78.150] has joined ##uasf
10:00 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Quit: Connection closed]
10:01 < RusAlex> sorry I might be stupidly sound with my question. But I heard that LOT=true is the most safe way to update for any user in any environment. Even when lots of people will run LOT=false , LOT=false chain will have a long reorg when one day (and it's seems inevitable) LOT=true become longer
10:02 <@michaelfolkson> RusAlex: Not stupid at all. Can you ask in ##taproot-activation though and I'll answer you there? This channel is focused on development of the UASF LOT=true implementation
10:03 -!- nvk [~nvk@static-198-54-132-86.cust.tzulo.com] has quit [Ping timeout: 260 seconds]
10:03 <@michaelfolkson> We'll start the kick off meeting in just under a hour https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018515.html
10:07 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has joined ##uasf
10:07 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has quit [Read error: Connection reset by peer]
10:08 -!- lightlike [~lightlike@p200300c7ef19540068eed5afea095ef2.dip0.t-ipconnect.de] has joined ##uasf
10:10 -!- lightlike [~lightlike@p200300c7ef19540068eed5afea095ef2.dip0.t-ipconnect.de] has left ##uasf []
10:10 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has joined ##uasf
10:10 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has quit [Client Quit]
10:15 -!- taproot_observer [5f5bd70a@ip5f5bd70a.dynamic.kabel-deutschland.de] has joined ##uasf
10:21 -!- random94726 [44961646@S0106f8a097f03715.ed.shawcable.net] has joined ##uasf
10:24 -!- jonny1000 [51934b9f@host81-147-75-159.range81-147.btcentralplus.com] has joined ##uasf
10:24 -!- jonny1000 [51934b9f@host81-147-75-159.range81-147.btcentralplus.com] has left ##uasf []
10:24 -!- jonny1000 [51934b9f@host81-147-75-159.range81-147.btcentralplus.com] has joined ##uasf
10:37 -!- taproot_observer [5f5bd70a@ip5f5bd70a.dynamic.kabel-deutschland.de] has quit [Ping timeout: 240 seconds]
10:46 -!- stortz [b1982408@177.152.36.8] has joined ##uasf
10:50 -!- Guest95662 [50390e8e@g14142.upc-g.chello.nl] has joined ##uasf
10:51 -!- nvk_ [~nvk@89.36.78.150] has quit [Ping timeout: 276 seconds]
10:51 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##uasf
10:52 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Client Quit]
10:53 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##uasf
10:53 -!- taproot_observer [5f5bd70a@ip5f5bd70a.dynamic.kabel-deutschland.de] has joined ##uasf
10:53 -!- taproot_observer [5f5bd70a@ip5f5bd70a.dynamic.kabel-deutschland.de] has quit [Client Quit]
10:56 -!- occupier [~occupier@195.181.160.175.adsl.inet-telecom.org] has joined ##uasf
10:58 -!- devrando1 [~devrandom@unaffiliated/niftyzero1] has joined ##uasf
10:58 < occupier> What's the argument against doing a rather short LOT=false and if it fails to activate, deduce why it didn't activate and if it's not compelling reason, do another short activation period with LOT=true?
10:58 -!- devrando1 is now known as devrandom
10:59 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Quit: Connection closed]
10:59 < luke-jr> occupier: if there was a compelling reason, doing LOT=False is wrong too
10:59 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##uasf
10:59 < luke-jr> anyway, IMO LOT debates are off-topic here
11:00 <@michaelfolkson> #startmeeting
11:00 < stortz> #taproot-activation
11:00 <@michaelfolkson> OK.... say hi if you're here for the UASF kick off meeting
11:00 < jonny1000> hi
11:00 -!- nvk [~nvk@37.120.205.214] has joined ##uasf
11:00 < occupier> hi
11:00 < stortz> hi
11:00 < luke-jr> hi
11:00 < prayank> hi
11:00 < devrandom> hi
11:00 < Alexandre_Chery> Hi
11:01 <@michaelfolkson> It was announced rather last minute so I am expecting we'll start off small (which is fine)
11:01 < AaronvanW> hi
11:01 < belcher> hi
11:01 <@michaelfolkson> Ok so depending on who is here do we need to revisit the reasons why we are here? It might be good to clarify some things first off
11:02 <@michaelfolkson> Everyone been following the LOT discussion? No explanations required on that?
11:02 <@michaelfolkson> We have a revised BIP 8, we have consensus on all the parameters apart from LOT basically
11:03 < occupier> I was told my question about two rounds of LOT values was OT but I'm still interested in hearing arguments against it
11:03 <@michaelfolkson> Yeah sorry occupier. Feel free to ask in ##taproot-activation
11:03 <@michaelfolkson> This project is aiming to ship a LOT=true release
11:04 < jonny1000> occupier: I dont think it makes sense. because we can just do LOT false with a long period, then halfway though there could bee a cmapaign to combine LOT true with the end of the original LOT false period
11:04 < occupier> I've dropped the question in ##taproot-activation feel free to discuss there if interested
11:04 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##uasf
11:04 < devrandom> michaelfolkson: is the aim to run LOT=true with otherwise the same parameters as others in the ecosystem that are running LOT=false?
11:05 < luke-jr> FWIW, I threw together a webpage at https://bitcointaproot.org/taproot.html that can be polished up, and I'm happy to help prepare/sign the code - but not willing to do it literally all myself and don't want to give naysayers/lawyers an opportunity to claim this is just me doing it ;)
11:05 < luke-jr> devrandom: IMO the ideal is to never have a LOT=False release anywhere
11:05 < nvk> +1
11:05 < luke-jr> ie, this would be "the Taproot release"
11:05 <@michaelfolkson> devrandom: Exactly but we'll get onto the parameters in a bit. Only parameter that will be changed is LOT
11:05 < devrandom> seems like there's some disagreement on this
11:06 < luke-jr> who is changing LOT?
11:06 < occupier> anyone who wants to
11:06 <@michaelfolkson> Ok give me a second to explain please :)
11:06 <@michaelfolkson> So I'll outline where I see Core at the current time. Personally (and I know at Luke will disagree with some of this) I can't see Core shipping a default LOT=true release at this stage. Too many contributor NACKs
11:06 <@michaelfolkson> So from where I'm sitting Core will either ship a default LOT=false or it won't ship anything
11:07 <@michaelfolkson> Personally I'm more concerned about the latter than the former (but again others will disagree)
11:07 <@michaelfolkson> In terms of what Core does, that is almost entirely irrelevant from this project (in my view)
11:08 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: leaving]
11:08 <@michaelfolkson> We can all argue about that on ##taproot-activation
11:08 < nvk> If Core doesn't ship anything would help avoid confusion and false positives for "False" preference.
11:08 < luke-jr> personally I plan to NACK any LOT=False; but I doubt I would need to at this point (devs pushing against LOT=True seem to be off shed-painting other bad ideas now)
11:08 < jonny1000> Michael, so you are developing a conditional plan? If Core does LOT false then we do A, if Core does nothing, then we do B?
11:08 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##uasf
11:08 <@michaelfolkson> In terms of Core that is a discussion for another place
11:09 < luke-jr> k
11:09 < AaronvanW> LOT=true needs hash power and/or economic majority to succeeed. wouldn't it be good (better) to first try and get a hash power/economic majority on board before shipping a LOT=true client?
11:09 <@michaelfolkson> jonny1000: The plan (whatever Core does) is to ship a default LOT=true in a similar style project to the UASF project in 2017
11:09 < stortz> the client comes first
11:10 <@michaelfolkson> If Core ships LOT=false we will be offering a LOT=true alternative. If Core ships nothing we will be offering activation code in a release
11:10 -!- lightlike [~lightlike@p200300c7ef19540068eed5afea095ef2.dip0.t-ipconnect.de] has joined ##uasf
11:10 <@michaelfolkson> Either way this project is needed. If Core ships nothing this project becomes immensely important. Taproot wouldn't activate without it
11:10 < luke-jr> AaronvanW: at least one major miner has already said they will run it
11:10 < jonny1000> But it makes a big difference... If Core releases with LOT=False andd the economy runs that, and this UASF LOT=true is shipped, then this could force the economy to activate taproot. If Core ships nothing, then LOT=true doesnt force the rest of the economy to do anything
11:11 < luke-jr> AaronvanW: as well as a few businesses
11:11 < luke-jr> after launch I expect more will commit
11:11 < luke-jr> jonny1000: nobody is forced in any case
11:12 < nvk> AaronvanW: although not possible to validate, there seems to be a lot of support atm
11:12 -!- temp345903485 [9a15d844@154.21.216.68] has joined ##uasf
11:12 <@michaelfolkson> jonny1000: If Core ships nothing Taproot doesn't activate unless the economic majority run this LOT=true code
11:12 < occupier> Is there any code the group has put out to handle LOT=true and LOT=true block production doesn't occur?
11:12 < jonny1000> Well, it means the economy that doesnt run this LOT=true client, wont enforce taproot rules
11:12 < luke-jr> occupier: what? it will occur
11:13 < AaronvanW> nvk: is there anything specific you're referring to? some sort of wiki that lists support, as we saw in the case of segwit and bip148 would be very useful.
11:13 < devrandom> +1
11:14 -!- nvk_ [~nvk@89.36.78.182] has joined ##uasf
11:14 < stortz> AaronvanW here https://taprootactivation.com
11:14 < luke-jr> stortz: that's just miners
11:14 <@michaelfolkson> I do want to reiterate that this UASF is *very* different from 2017. 90 percent of mining pools have pledged support for Taproot, one (F2Pool) have said they're happy with either LOT=true or LOT=false
11:15 < belcher> back in 2017 a huge part of the economy was enforcing segwit, they all adopted bitcoin core 0.13.1
11:15 < AaronvanW> stortz: zero lot=true supporters there, only f2pool says either is fine. (which could mean they'll keep running core, not a lot=true client)
11:15 < occupier> luke-jr the scenario I'm envisioning is, a user runs LOT=true, if there isn't taproot enforcing blocks being produced, those nodes will fracture of the network (say because various reasons, not enough economic demand for taproot enforcing blocks)
11:15 < nvk_> AaronvanW: sorry connection issues... see the site above. But I also recommend reaching out to parties and asking yourself, from my experience it's been mostly support.
11:15 < luke-jr> AaronvanW: F2Pool says they will run a BitcoinActivation release
11:16 < AaronvanW> ok
11:16 <@michaelfolkson> AaronvanW: Many responded weeks ago before the LOT discussion kicked off
11:16 -!- nvk [~nvk@37.120.205.214] has quit [Ping timeout: 240 seconds]
11:16 < AaronvanW> does that mean they'll run this lot=true client luke-jr? have they said that?
11:16 < luke-jr> AaronvanW: yes
11:17 <@michaelfolkson> AaronvanW: I wouldn't expect anyone to say they'll definitely run anything until they can inspect the code
11:17 < luke-jr> (initially it was "the download links are broken" :P)
11:17 -!- nvk_ [~nvk@89.36.78.182] has quit [Client Quit]
11:17 -!- nvk [~nvk@89.36.78.182] has joined ##uasf
11:17 < luke-jr> michaelfolkson: sure, but the intent/purpose is clear
11:18 -!- proofofkeags [~proofofke@205.209.24.233] has joined ##uasf
11:18 < proofofkeags> hi
11:19 < luke-jr> IMO two things should happen in parallel next: 1) people talk to businesses and get their ACK to list on the website as a supporter; 2) finish merging the code and produce a release
11:19 < prayank> +1
11:19 <@michaelfolkson> This is obviously starting small. But we have to start somewhere. Personally I'll be trying to get as much code review (eventually) from say Core contributors not formally contributing to this project as is possible
11:19 < luke-jr> they can be in parallel - coders work on code, non-coders work on supporters
11:20 < stortz> this website, correct https://github.com/BitcoinActivation/BitcoinTaproot.org
11:20 < proofofkeags> is there a bunch of code that has to be written for a UASF lot=true or just setting the parameter?
11:20 < temp345903485> Will there be a time in the future when Core actually ships a soft fork, or have we seen the last one?
11:20 < stortz> parameter
11:20 < luke-jr> stortz: yeah, visible at https://bitcointaproot.org/taproot.html
11:20 < luke-jr> stortz: can be used to showcase the plan
11:20 <@michaelfolkson> And if Core ends up going round in philosophical discussions rather than code and code review we'll be a positive force
11:21 < luke-jr> temp345903485: seems Segwit was the last one activated via mainline Core
11:21 < luke-jr> this is essentially Core + activation at this point
11:22 -!- bitentrepreneur [2578d1d4@37.120.209.212] has joined ##uasf
11:22 < bitentrepreneur> hi
11:22 <@michaelfolkson> Hey bitentrepreneur. Thanks for stopping by :)
11:22 < luke-jr> takes any appearance of liability off devs too
11:22 < bitentrepreneur> hey of course michaelfolkson sorry for being late
11:23 < luke-jr> (and miners)
11:23 < AaronvanW> bitentrepeneur: I think a good thing to ask miners is if they would run an independent LOT=true client.
11:23 < temp345903485> I think the main takeaway that I'm getting is that consensus is Hard (TM)
11:23 < AaronvanW> (which is what is being discussed here.)
11:23 < AaronvanW> miners/mining pools
11:23 <@michaelfolkson> In terms of code (Luke may disagree) I'm hoping the diff between the eventual Core activation code (assuming they ship something that is) and our repo is minimal
11:23 < belcher> economic support is more important than miner support for a UASF (but of course miner support helps in a way)
11:23 <@michaelfolkson> The scope of this project (at least from a code standpoint) is pretty small
11:23 < luke-jr> nah, I agree minimal is best - not sure it's practical if mainline Core does a release though
11:24 < bitentrepreneur> well f2pool already said they would support both lot false and lot true
11:24 < occupier> Because it wasn't addressed, it's my understanding that BitcoinActivation repo won't have code to warn users that taproot enforcing blocks aren't being produced.  Please correct me if I'm wrong
11:24 < AaronvanW> so not just if they prefer "true" or "false", but if they would actually run a non-Core LOT=true client.
11:24 -!- adam3us_ [~adam3us@2a01:4c8:68:a227:657c:5177:b2f5:179f] has joined ##uasf
11:24 < proofofkeags> miner support guarantees work which guarantees convergence assuming the rules are backwards compatible which they are
11:24 < bitentrepreneur> poolin wants to activate taproot so whatever the consensus is, i don't see it being a problem for poolin
11:24 < occupier> belcher +1
11:24 < luke-jr> AaronvanW: miners have to run whatever the community wants
11:24 < luke-jr> bitentrepreneur: can we list Poolin as explicitly supporting tho?
11:24 < AaronvanW> luke-jr: it's still useful info imo.
11:24 <@michaelfolkson> No code whatsoever has been written or merged so far on this project. This is a kick off meeting. We haven't even finalized repo controls etc
11:24 < belcher> without economic support, i could put coins in a taproot address, someone could steal them because from their point of view they are anyonecanspend and they could send those coins to coinbase.com and coinbase's full node would accept them
11:24 -!- criley94 [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##uasf
11:24 < luke-jr> michaelfolkson: repo controls aren't very important IMO
11:25 < bitentrepreneur> any answer from poolin must be discussed internally beforehand luke-jr
11:25 -!- rabidus [~rabidus@dsl-olubng12-54fa17-92.dhcp.inet.fi] has joined ##uasf
11:25 < luke-jr> bitentrepreneur: makes sense
11:26 <@michaelfolkson> I wasn't involved in the UASF of 2017 nor have I released Knots but I'd want to aspire to have similar controls to Core
11:26 -!- adam3us_ [~adam3us@2a01:4c8:68:a227:657c:5177:b2f5:179f] has quit [Read error: Connection reset by peer]
11:26 < luke-jr> either way, some volunteers are needed to do the merging/code review/etc
11:27 < proofofkeags> I can do review
11:27 < luke-jr> as things stand, hsto opened a PR for BIP 8, but it hasn't been merged yet
11:27 < luke-jr> and I don't want to do merging. :p
11:27 < luke-jr> wait, ben opened the PR, my bad
11:27 < luke-jr> https://github.com/BitcoinActivation/bitcoin/pull/1
11:28 <@michaelfolkson> The code diff is likely going to be relatively small but it is consensus code (I absolutely agree with say Matt here)
11:28 <@michaelfolkson> I'm happy to do merging in an administrative capacity. I certainly won't be merging anything though until I'm happy with the people who have reviewed it
11:29 < proofofkeags> Yeah the success of uptake of this change is highly contingent on having rigorous processes
11:29 < occupier> michaelfolkson "matt's position" being what?
11:29 < luke-jr> michaelfolkson: at the end of the day, that policy just means the project is stalled indefinitely it seems
11:30 < luke-jr> occupier: basically discriminating between reviewers
11:30 <@michaelfolkson> occupier: There's a lot to get into there. But one thing I do agree with him on is this is consensus code and Core take that very seriously (for good reason)
11:30 < devrandom> shouldn't we encourage Core to release an activation for taproot, even if they release it with LOT=false?  it increases the chance of activation overall.  e.g. 60% on LOT=true + 35% on LOT=false passes the activation threshold for everybody.  strictly better than just 60% on LOT=true.
11:30 < luke-jr> unless I misunderstood michaelfolkson
11:30 <@michaelfolkson> occupier: We should also take code and code review of consensus code very seriously too
11:30 < luke-jr> devrandom: not necessarily
11:31 < luke-jr> devrandom: if mainline Core releases LOT=False, it could end up with less running LOT=True, which is worse
11:31 < stortz> there was already encouragement
11:31 < luke-jr> michaelfolkson: IMO we should do the best we can do, but still get it done
11:31 < occupier> michaelfolkson ok if I understand you correctly: "Spend a high number of work-hours on consensus code review"
11:31 < prayank> I will try and prepare a list of businesses and mining pools that dont have issues with running LOT=True, also arguments against it if any. Was also trying to prepare a flow chart with a user deciding to use LOT=True or False and everything that may happen until Taproot Activation.
11:31 <@michaelfolkson> devrandom: We'll try to avoid that discussion on this channel as this is a separate project from Core. I would agree with you but Luke disagrees with that view
11:32 < jonny1000> devrandom: I agree
11:32 < luke-jr> prayank: IMO ideal if we just forget LOT=False entirely ;)
11:32 < devrandom> I see.  it seems that limited collaboration with Core would be good even if we disagree on some things.
11:32 < occupier> luke-jr why is it worse if the community has easily accessible binaries / code for whichever LOT value they want? Choice is good IMO
11:32 <@michaelfolkson> The other thing to appreciate is that even if initial take up of the LOT=true release is slow, imagine what happens if miners don't activate within say 3-6 months. There will be interest in running this release
11:32 < jonny1000> why cant this group push as hard as they can for LOT=true on this client, but why oppose Core releasing LOT=false?
11:33 < luke-jr> occupier: not for consensus rules; if people don't want Taproot, they can of course fork an anti-Taproot version
11:33 < nvk> LOT=False will give a false sense of choice concensus
11:33 < proofofkeags> it has to do with Core's soft influence on the protocol
11:33 < jonny1000> All of that will help activate Taproot in the end
11:33 < stortz> why should this venture here care about what core releases
11:33 <@michaelfolkson> jonny1000: As I said separate issues. I agree with you, Luke disagrees. But this channel isn't for discussing Core. Go to ##taproot-activation for that
11:33 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has joined ##uasf
11:33 < prayank> luke-jr: Important to share things so that users do not blindly follow what core uses as default or read few things on social media or elsewhere. Trade-offs involved and why this project matters is important for everyone to understand including our intentions.
11:34 < luke-jr> prayank: as things stand, Core is not releasing any activation
11:34 < stortz> is there even tradeoffs for taproot
11:34 < luke-jr> right now, LOT=True is the only taproot activation in progress
11:34 <@michaelfolkson> As a last point on Core :) to get the smallest diff between this project and Core's ideally Core would write and release activation code. If they release nothing the diff is bigger
11:34 -!- uasf [~uasf@2604:a880:2:d0::1bda:1001] has joined ##uasf
11:35 < devrandom> +1
11:35 < luke-jr> michaelfolkson: yes, that's the one downside
11:35 <@michaelfolkson> Ideally I'd like that code diff to be as small as possible
11:35 < luke-jr> michaelfolkson: but the raw diff matters less than code review
11:35 <@michaelfolkson> Less review needed, less chances for bugs with small diff
11:35 <@michaelfolkson> (within a context that this is consensus code and will need strong review regardless)
11:37 <@michaelfolkson> I lied. Last, last point on Core. I will still be following Core PRs, reviewing very closely. This is definitely not a Core versus us thing. Absolutely not
11:37 <@michaelfolkson> But just let's discuss Core on other channels than this one. This project needs to meet its objectives regardless of what Core does
11:38 <@michaelfolkson> Ok... what else
11:38 < occupier> Is this endeavor only going to issue a formal tagged release if a certain threshold of economic demand signals for LOT=true?
11:38 < proofofkeags> fwiw I'm a very new contributor to Bitcoin, and I wouldn't be surprised if many others here were as well. So while more review is more better, the reviews of veteran core contributors are likely to be more able to catch subtle bugs. Making sure the diff is small means that the review of those of us who are not veterans can be sufficient.
11:38 < luke-jr> anyway, if we wait on extra review for BIP 8, we're just stuck IMO
11:38 < luke-jr> keep in mind also that if any new issues *are* found, it's not impossible to fix them
11:38 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has quit [Read error: Connection reset by peer]
11:39 < proofofkeags> right, the risk is about the ones that *aren't* found
11:39 < proofofkeags> assuming they exist, of course
11:39 <@michaelfolkson> proofofkeags: Agreed but I will be doing my best to get veterans to review our code (even if they don't want to publicly). Also Luke is a veteran :)
11:39 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has joined ##uasf
11:39 < luke-jr> proofofkeags: so we just do nothing and Taproot sits inactive forever?
11:39 < proofofkeags> no, of course not. I'm just saying that the smaller we keep the diff the better, but we should proceed without getting stuck
11:39 < luke-jr> k
11:40 <@michaelfolkson> I just think we've had enough philosophical debates now. Code and code review. And high standards and patience for those, just not philosophy, high level stuff
11:40 < proofofkeags> ^
11:41 < stortz> how should we ask economic nodes if they are willing to run this UASF
11:41 <@michaelfolkson> It is what Core should be doing imo but unfortunately there are some who want more philosophy, high level stuff at the moment
11:41 < luke-jr> stortz: link the draft page and ask if we can count on their support?
11:41  * michaelfolkson shrugs
11:41 < stortz> "Businesses
11:41 < stortz> Open an issue on GitHub to add to the list!"
11:41 < AaronvanW> stortz: big players like exchanges are a good place to start.
11:42 < luke-jr> stortz: when we actually publish the page, IMO we should hide the whole supporters section until we have at least 10-20 to list
11:42 < stortz> no, I'm asking what question do we formulate? to copy paste
11:42 < proofofkeags> Alright I'm starting a review, but I should note many of them might be dumb questions.
11:42 <@michaelfolkson> I would say, let's not rush approaching people yet. We can have follow up meetings
11:42 < luke-jr> proofofkeags: for BIP 8, please do reviews on the Core PR, not the BA PR
11:43 < proofofkeags> ok
11:43 <@michaelfolkson> Core PR is here: https://github.com/bitcoin/bitcoin/pull/19573
11:43 < proofofkeags> Bip8 is purely structural right?
11:43 < proofofkeags> as in, taproot agnostic
11:43 < luke-jr> IMO we should have a bit of a rush; first, we don't want to have to push the heights further into the future; second, we don't want to give LOT=False an opportunity to gain traction
11:43 < luke-jr> proofofkeags: yes
11:44 <@michaelfolkson> In terms of timetable, this is a tricky one. Can we talk timetable?
11:44 < proofofkeags> please
11:44 <@michaelfolkson> This is what you initially proposed luke-jr: https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
11:44 < stortz> "Given the opportunity, will you run a LOT=True node client fork of Bitcoin Core? "
11:45 < luke-jr> michaelfolkson: eh?
11:45 <@michaelfolkson> Weeks ago :)
11:45 < luke-jr> that was the group, not me :P
11:45 <@michaelfolkson> Oh I thought they copied it off your Google Doc?
11:45 <@michaelfolkson> Ok sorry, my mistake
11:45 < luke-jr> yes, which the group reviewed
11:46 <@michaelfolkson> Timetable is hard. This is where Core comes back into the picture...
11:46 < luke-jr> anyway, the non-resolution of LOT kinda pushes urgency up
11:46 <@michaelfolkson> I really did lie about not discussing Core
11:46 < luke-jr> and I expect it will take a week from tagging to sort out builds
11:46 < occupier> luke-jr "we don't want to give LOT=False an opportunity to gain traction" so it's bad that users have choice? These arguments read to me as extremely anti-user
11:47 < _andrewtoth_> give the user a choice to activate or not activate
11:47 < luke-jr> occupier: then you're reading them wrong; are you just here to argue?
11:47 < stortz> you'll have a chainsplit if someone spends coins that were supposed to be pay-to-tapscript
11:47 < _andrewtoth_> false or true will just confuse more people
11:47 <@michaelfolkson> Ok... if Core releases some activation code (most likely LOT=false) I really think we should attempt to propose a timetable that Core can align with
11:47 <@michaelfolkson> And I know Luke disagrees....
11:48 < nvk> occupier: whatever Core releases will be perceived as the majority preference, which doesn't seem to reflect current reality
11:48 < occupier> I am here to participate, correct me if I'm wrong but this is a discussion of peers, not decrees or mandates
11:48 < luke-jr> occupier: it's a discussion with the premised topic of a LOT=True activation
11:48 <@michaelfolkson> Let's reduce a heat a touch please occupier luke-jr
11:48 <@michaelfolkson> *reduce the heat
11:48 < stortz> nobody is forcing anyone to run a UASF ...
11:48 < jonny1000> I agree Michael, we should  look to collaborate with others trying to activate taproot in a potentialy compatible way, not rush so that they cant gain traction
11:49 <@michaelfolkson> To get the small diff with Core we need to give Core time to write and review some code
11:49 <@michaelfolkson> If we don't give them time we are giving up on the small diff and just writing it ourselves
11:49 < luke-jr> michaelfolkson: seems at least some are intentionally refusing to review to try to sabotage this effort
11:49 -!- adam3us_ [~adam3us@213.205.198.124] has joined ##uasf
11:49 < luke-jr> Core has had like 6 months already
11:50 <@michaelfolkson> But this is a possible plan. We sketch out a timetable where Core can (if they want to) align with if they choose
11:50 <@michaelfolkson> The alternative is we give up on Core entirely
11:50 < luke-jr> we already got consensus on a timetable..
11:50 <@michaelfolkson> I just don't think that makes sense
11:50 < stortz> isn't the consensus 1Y
11:51 < luke-jr> stortz: Aug-Aug yes
11:51 < stortz> that's a huge window IMO
11:51 <@michaelfolkson> As long as there is code being written and reviewed on Core I'd like to give them enough time to get to a point where they are happy releasing activation code
11:51 < prayank> occupier: There are lot of arguments made already on mailing list, reddit, twitter, IRC meetings etc. earlier. "Traction" IMO just refers to if more people are convinced about what is said for it or against LOT=True by few devs and users. Users are free to do whatever they like. This project just offers an alternative and shares the positives of using LOT=True.
11:51 < proofofkeags> michaelfolkson, 1y was a very strong consensus
11:51 < luke-jr> michaelfolkson: we're already past that point
11:51 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has quit [Read error: Connection reset by peer]
11:51 < occupier> regarding timetable are people referring to achow's summarization from the last taproot activation meeting?
11:52 <@michaelfolkson> If they are spending months on philosophical debates and not opening PRs, doing code review that is a different thing entirely
11:52 < proofofkeags> I don't see the reason to do the other activation parameters differently from Core, (sorry michaelfolkson).
11:52 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has joined ##uasf
11:52 < proofofkeags> or what was recommended out of the last activation meeting
11:52 < proofofkeags> which may or may not make it to Core
11:52 <@michaelfolkson> proofofkeags: No you aren't understanding my point
11:53 <@michaelfolkson> I am saying exactly same parameters as Core apart from LOT. But one of those parameters is startheight
11:53 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has quit [Read error: Connection reset by peer]
11:53 < proofofkeags> exactly
11:53 < luke-jr> michaelfolkson: Core has no parameters
11:53 <@michaelfolkson> If Core hasn't written, reviewed or released anything in advance of startheight what do we do then?
11:54 < luke-jr> michaelfolkson: if nothing has been released by startheight, startheight must be changed to +6 months at least
11:54 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has joined ##uasf
11:54 < proofofkeags> they can do it ex post facto
11:54 <@michaelfolkson> That's why I say sketch out something that can viably work for Core. If they choose to spend that time on philosophical debates then we give up on that aspiration
11:54 < proofofkeags> theres no requirement that the release happens antecedent to the start height is there?
11:54 -!- nilsment [~nilsment@dynamic-002-247-243-253.2.247.pool.telefonica.de] has quit [Read error: Connection reset by peer]
11:54 < luke-jr> michaelfolkson: the BIP 8 PR was opened 8 months ago
11:55 < luke-jr> proofofkeags: yes..
11:55 < luke-jr> proofofkeags: by startheight, the majority of the economy must be upgraded
11:55 <@michaelfolkson> We have to be prepared to release without Core. But I still think the best path is sketching out something that can work for them from today
11:55 < luke-jr> well, it doesn't have to be mainline Core; this would be enough
11:55 -!- cguida [~cguida@2806:2f0:51c0:df27:bdff:1df2:b3db:8ad3] has joined ##uasf
11:55 < proofofkeags> why does the start height matter, isn't the UASF only relevant at timeout
11:56 < luke-jr> proofofkeags: MASFs require economic majority too
11:56 < luke-jr> proofofkeags: otherwise you have a 51% attack that compromises the network security
11:56 < jonny1000> michaelfolkson: What do you mean? A LOT=true client with a timeline such that Core have time to release a LOT=false client with the same end date?
11:56 <@michaelfolkson> The parameter agreed for timeout was 1 year. Another parameter is startheight. Core and UASF should (ideally) be in parallel otherwise you have to adjust parameters
11:57 < luke-jr> michaelfolkson: if Core insists on breaking compatibility, that's on them
11:57 <@michaelfolkson> We have to set a start and end date basically with a year in between. Ideally they should be the same for UASF LOT=true and Core
11:58 < jonny1000> michaelfolkson: Maybe have a 1 year activation period, starting in several montsh time, then you hope Core release there 1 YR LOT=False clienty within those several months, such that the timetable aligns?
11:58 <@michaelfolkson> But we can't rush them luke-jr. We can give them something that they can work with and they can choose to either work with it or not
11:58 < luke-jr> IMO the community already settled on start/end heights, and I'm not really interested in revisiting it, so ping me when that's over
11:58 < luke-jr> michaelfolkson: already did that
11:58 < proofofkeags> I don't think it is critical that Taproot be fully guaranteed to be activated by next July, I think the main issue is the feeling of no progress. So if we set a start height 6mo from now and then timeout 1y after that, that gives core enough time to decide how or whether they are going to be compatible
11:59 < jonny1000> proofofkeags: Yes, that makes sense
11:59 <@michaelfolkson> luke-jr: The code has to be ready to release. What was the plan for the release date?
11:59 <@michaelfolkson> Agreed proofofkeags
12:00 <@michaelfolkson> I am sure some people would rather have 12-24 months of philosophical debates rather than accepting there is no way round a very small chain split risk
12:01 < jonny1000> It is good that there are risks around these softforks, that makes softforks hard to do, which is a feature not a bug
12:01 <@michaelfolkson> No progress on code, no progress on code review. That's the most important thing. But users should also have a LOT=true option there if they want to run it
12:01 -!- criley94 [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Quit: Connection closed]
12:02 <@michaelfolkson> Ok any other questions or topics? I think the timetable is probably the most important thing at this stage.
12:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
12:02 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined ##uasf
12:03 <@michaelfolkson> There is also a repo for the website: https://github.com/BitcoinActivation/BitcoinTaproot.org
12:03 < brg444> -_-
12:03 <@michaelfolkson> ?
12:03 < proofofkeags> I don't have a diff-adj clock on hand, but I'd say target start for Sept or something around there
12:03 < proofofkeags> someone said Aug, which also seems fine
12:04 <@michaelfolkson> Right, I need to confirm what Luke thinks. Personally I agree with you proofofkeags
12:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##uasf
12:04 < devrandom> I think there was already a starttime that came out of the last ##taproot-activation meeting?
12:04 <@michaelfolkson> startheight=693504 (~2021 July 23rd)
12:05 <@michaelfolkson> But that has release end of March... not going to happen :)
12:05 <@michaelfolkson> https://en.bitcoin.it/wiki/Taproot_activation_proposal_202102
12:05 < devrandom> I see
12:05 <@michaelfolkson> https://docs.google.com/document/d/1Ewnxxxc51_JWJLZQfqc5W55Pvkgcf9TEh6Ks3wiHbRk/edit
12:05 < brg444> Reading through but what's holding up an end of march release? That doesn't seem totally implausible
12:06 <@michaelfolkson> brg444: Testing and code review
12:06 <@michaelfolkson> I'm certainly not comfortable merging things for an end of March release
12:06 <@michaelfolkson> 100 percent not
12:07 <@michaelfolkson> But I don't know what latest release date is possible for that startheight. Question for luke-jr
12:07 < occupier> end of march is 18 work days
12:08 <@michaelfolkson> I'm a NACK for that. Personally I wouldn't want to be involved if that's the timing
12:09 <@michaelfolkson> A lot of the long term contributors of Core haven't even started looking at activation from what I can see
12:09 < proofofkeags> NACK end of march
12:09 <@michaelfolkson> If we want some long term Core contributors to review it that timing is impossible
12:09 < nothingmuch> michaelfolkson: i don't remember the date but i think that was discussed ~3-4 weeks ago in ##taproot-activation, based on data about the share of user agent strings observed on the network after releases
12:09 < brg444> michaelfolkson: A lot of the long term contributors of Core have so far shown no intention to even engage in that discussion
12:10 < proofofkeags> brg444: they may have no choice
12:10 <@michaelfolkson> brg444: That is true. But this goes to my earlier point. We put a stake in the ground and say the focus from now on should be code and code review. If Core want to continue not doing that and do the philosophical circles we can't do anything
12:11 < luke-jr> so who is?
12:11 < brg444> The point of this exercise was to stop sitting on our hands waiting for Core to put an honest step forward.
12:11 < luke-jr> lol
12:11 <@michaelfolkson> Today was promising. Sjors, AJ and Marco started looking at the activation PR
12:12 < proofofkeags> yes, but you still want to create an environment where they could follow up with a compatible release.
12:12 <@michaelfolkson> Of course that could end tomorrow but that is better than before
12:12 < luke-jr> proofofkeags: nothing is stopping them
12:12 <@michaelfolkson> To be clear AJ has written a large part of the PR so I shouldn't include him in the reviewers
12:12 <@michaelfolkson> But Sjors and Marco started looking at it
12:12 < proofofkeags> luke-jr an end of march release date requirement might
12:13 < stortz> who said end of march
12:13 < luke-jr> proofofkeags: so long as the economic majority runs Core+Taproot we release in a week or two, Core has a year to get ready
12:13 < occupier> stortz brg444 suggested end of march
12:13 < occupier> I believe
12:13 < brg444> I did not
12:13 < luke-jr> if Core is ready before August, even better, but not necessary
12:13 < proofofkeags> do we have any reason to believe that the economic majority can move that quickly?
12:14 < luke-jr> proofofkeags: if not, then startheight is chosen wrong
12:14 < occupier> brg444 my apologies
12:14 < proofofkeags> sorry, I misunderstood I get it now
12:14 <@michaelfolkson> I thought the plan should be that we give Core enough time to release something at the same time we do
12:14 < proofofkeags> you're saying, release the UASF client in 1-2 weeks, not put the startheight at 1-2 weeks from now
12:14 < proofofkeags> michaelfolkson +1
12:14 <@michaelfolkson> startheight=693504 (~2021 July 23rd)
12:14 < luke-jr> michaelfolkson: the opposite
12:15 <@michaelfolkson> Well then 0 percent chance of minimizing the diff
12:15 < luke-jr> michaelfolkson: that would be harmful
12:15 -!- moneyball [sid299869@gateway/web/irccloud.com/x-dgnnglpoxudmwpsz] has joined ##uasf
12:15 < luke-jr> michaelfolkson: BIP 8 + parameters is minimised
12:15 < luke-jr> michaelfolkson: the moment Core does anything incompatible, things necessarily get bigger
12:16 <@michaelfolkson> If Core releases anything it will be LOT=false. That is only incompatible with LOT=true if miners fail to activate for a year
12:16 < proofofkeags> luke-jr why does releasing in such a way that core could be compatible harmful? it seems to me strictly worse.
12:16 < luke-jr> michaelfolkson: then all the more improtant to release this as far in advance as possible
12:17 -!- felixweis [sid154231@gateway/web/irccloud.com/x-hldbcxhyvspmjqje] has joined ##uasf
12:17 < cguida> we'd want to keep the uasf client up-to-date with any other changes core puts out, right?
12:17 <@michaelfolkson> Core will be very slow regardless
12:17 <@michaelfolkson> Very, very slow
12:17 < luke-jr> proofofkeags: Core can be compatible if we release next week, with the current plan
12:17 < luke-jr> cguida: yes
12:17 < proofofkeags> ok
12:17 <@michaelfolkson> To beat them to a release will not be hard
12:18 <@michaelfolkson> There is no rush whatsoever if the goal is to get our release out well before Core
12:18 < luke-jr> the rush is to get it well out before startheight
12:18 < proofofkeags> especially if Core's default position is to not move on this right now
12:18 < luke-jr> once March is over, I'm not sure I'm comfortable with the current parameters
12:18 < brg444> luke-jr: +1
12:19 <@michaelfolkson> So if we miss March what would you think of changing the startheight to?
12:19 < luke-jr> dunno, I might just throw up my hands and figure Taproot isn't happening
12:19 < luke-jr> let someone else deal with it
12:19 <@michaelfolkson> That would be sad
12:20 <@michaelfolkson> And leave the floodgates open for years of philosophy
12:20 < luke-jr> might even imply Bitcoin ossification, which opens the door to an altcoin replacing it for real
12:21 < proofofkeags> luke-jr I wouldn't go that far
12:21 -!- RubenSomsen [sid301948@gateway/web/irccloud.com/x-ukeiamoftqdxfbvz] has joined ##uasf
12:21 < luke-jr> not sure Taproot is enough to get people to abandon Bitcoin, but eventually new stuff will pile up
12:21 < proofofkeags> from my POV I only started getting involved in this effort a week or so ago
12:21 < occupier> what's the downside by adjusting the start height by (core review end date - march 2021) ?
12:21 <@michaelfolkson> Hmm ok let's wrap up then and give people some time to think on this March question. I hope you reconsider luke-jr. You are our best hope of beating the years of philosophy at this point
12:21 < luke-jr> occupier: so never?
12:21 < occupier> I don't follow
12:21 < nothingmuch> occupier: nobody knows when that is
12:22 < luke-jr> michaelfolkson: so let's just get it done
12:22 < occupier> I'm sorry
12:22 < luke-jr> occupier: as things stand, Core won't be releasing anything
12:22 < occupier> I wrote a typo
12:22 < occupier> s/core/code
12:22 < luke-jr> occupier: the code is pretty much reviewed
12:22 < luke-jr> just nobody wants to move forward
12:23 <@michaelfolkson> I'll think it over overnight. But I'm not comfortable personally merging PRs in for an end of March release. Sorry. If I was as experienced as you I might be more comfortable
12:23 < stortz> hasn't the PR been reviewed already for 8 months
12:23 < nothingmuch> btw worth pointing out that the uasf repo is based on 0.21 with backported master if i'm not mistaken (as opposed to master)
12:24 < luke-jr> nothingmuch: ?
12:24 < nothingmuch> s/backported master/backported taproot/;
12:24 < luke-jr> Taproot was merged before 0.21
12:24 < nothingmuch> my bad
12:24 <@michaelfolkson> stortz: Mainly inexperienced reviewers (such as myself)
12:24 < nothingmuch> but my point is that it doesn't entail a large diff, i believe that is michaelfolkson's concern re a tighter schedule?
12:24 <@michaelfolkson> Only today Sjors and Marco started looking at it
12:24 < luke-jr> michaelfolkson: again, remember if other people keep reviewing it, we can always merge the fixes in too
12:25 < cguida> I'll help test
12:25 <@michaelfolkson> Merge the fixes in post release?
12:25 < brg444> at this point only another pushed release will stop Core from tergiversating
12:25 < luke-jr> michaelfolkson: also possible, yes
12:25 < luke-jr> michaelfolkson: but if we're looking to start the release process in a week, that's a week of review pre-release too
12:25 < brg444> we should start now
12:25 <@michaelfolkson> A developer release? Run at your own risk?
12:26 < brg444> if we can't make it by the end of march then so be it
12:26 < luke-jr> michaelfolkson: sure, maybe we can call it a pre-release if that's what people like
12:26 < luke-jr> a rc1 makes sense
12:26 < proofofkeags> I can take a first pass review before EOD tomorrow.
12:26 < brg444> But if we signal a commitment I think it's inevitable more eyes will gravitate to it and confidence can grow from there
12:27 <@michaelfolkson> Again, I'm sorry. Maybe if I was Luke, I'd be comfortable with that turnaround. I'm not.
12:27 <@michaelfolkson> And no long term contributors from Core would look at it before then either
12:27 < proofofkeags> I don't see how giving ourselves more time to review/release is the same as stalling
12:27 -!- adam3us_ is now known as hashcash
12:27 < brg444> Setting another meeting to "discuss the March" issue is philosophy-ing
12:27 < luke-jr> 0.21.0+taproot0.1 rc1 with a warning that future upgrades may be necessary if bugs are found
12:27 < hashcash> michaelfolkson: so suggest a time-frame end april?
12:28 < cguida> michaelfolkson if we release something that has bugs a year before it matters, we'll probably have time and help to find the bugs
12:28 < hashcash> luke-jr: not that much point having people run unreviewed code
12:28 < nothingmuch> cguida: MASF may make it matter a lot sooner
12:28 <@michaelfolkson> But also we get the "look at those UASF guys releasing software with bugs in it"
12:28 < luke-jr> hashcash: it is already reviewed
12:28 < luke-jr> hashcash: and begins the process of building economic enforcement and support
12:28 <@michaelfolkson> It isn't Luke, not from long term contributors
12:28 < hashcash> luke-jr: the activation code not schnorr
12:29 < luke-jr> hashcash: both
12:29 <@michaelfolkson> (apart from you, AJ, Sjors for a day)
12:29 < luke-jr> michaelfolkson: again, if they find any issues we can fix them
12:29 < hashcash> michaelfolkson: end april?
12:29 <@michaelfolkson> Can you work with end of April luke-jr?
12:29 < hashcash> luke-jr: that's not exactly confidence inspiring .. review the flight control system while flying
12:29 <@michaelfolkson> Or too late for that startheight?
12:30 < proofofkeags> hashcash +1
12:30 < luke-jr> michaelfolkson: that's only 3 months for a supermajority of the economy to adopt it
12:30 < hashcash> michaelfolkson: add 30days to heights
12:30 < proofofkeags> ACK +30d
12:30 < hashcash> luke-jr: why? it has until aug 2022
12:30 <@michaelfolkson> I'm more comfortable with hashcash suggestion
12:31 < luke-jr> hashcash: no, startheight is this year Aug
12:31 < cguida> nothingmuch: true, I guess we'd want the miners to help test before they decide to signal
12:31 <@michaelfolkson> brg444: To be clear code review and testing is not philosophizing. That is critical.
12:31 < proofofkeags> ^
12:31 < stortz> miners testing what
12:31 < hashcash> michaelfolkson: brg444 what he said review & testing is important
12:32 <@michaelfolkson> There is world of difference between philosophy and releasing secure software
12:33 < hashcash> luke-jr: thats what others proposed - assuming they considered aug 2021 an ok start height
12:33 < hashcash> luke-jr: they knew this code and review would be needed
12:33 < luke-jr> …
12:33 < cguida> stortz: the uasf code, since it will lock in once the timeout has been hit
12:33 < nothingmuch> cguida: it's more that if miners MASF before economic majority upgrades to enforce those rules
12:33 < luke-jr> hashcash: again, it is reviewed
12:33 <@michaelfolkson> Remember if Core release nothing, we're asking the entire economy to run this software. We release with a bug and our reputation is shot
12:33 < luke-jr> michaelfolkson: where's Core's reputation after the inflation bug?
12:34 < luke-jr> that was in *production* releases for years
12:34 <@michaelfolkson> A few years ago now...
12:34 < luke-jr> and Core handled it poorly
12:34 < hashcash> luke-jr: either way. better if it's done on a time-frame that core can review within
12:34 < proofofkeags> Bitcoin was several orders of magnitude smaller then than it is now
12:34 < luke-jr> you're letting the perfect become the enemy of the good
12:34 < proofofkeags> it's not comparable
12:34 <@michaelfolkson> Agreed hashcash. They can choose not to review of course. But we need to give them opportunity to
12:34 < luke-jr> proofofkeags: no, it wasn't.
12:35 < hashcash> luke-jr: this is why review people can miss things for looking.
12:35 < hashcash> and why more reviewers is good.
12:36 <@michaelfolkson> I don't think we've got consensus on the timetable and I don't think we're going to get it tonight. Shall we revisit again next week?
12:36 < brg444> michaelfolkson: what I mean is that next meetings should preferably focus exactly on that, not Code review. maybe then we can have an even better take on what date can realistically be set
12:37 < brg444> sorry s/Not/
12:37 < hashcash> so if release was april then does startheight stay at aug 2021? or +30days also?
12:37 < brg444> should focus on code review*
12:37 <@michaelfolkson> We can have a meeting next week on the timetable brg444, sure
12:37 < luke-jr> have fun
12:38 < proofofkeags> hashcash, I would prefer delaying to +30 in that case
12:38 <@michaelfolkson> Hopefully you'll feel different tomorrow, I'm really hoping you will luke-jr
12:38 < proofofkeags> the point is not that we need imminent activation, we just can't stall without progress
12:39 <@michaelfolkson> It is a lot of work to get to this point and then give up because the timetable isn't quite as brisk as you wanted luke-jr
12:39 < hashcash> assuming startheight september schnorr would probably be activated by miners by end of year
12:39 < nothingmuch> if #1 is merged, what remains before an rc would be possible? is it just the parameters?
12:39 < luke-jr> nothingmuch: yes
12:39 < luke-jr> nothingmuch: unless LOT=False becomes a bigger threat
12:40 <@michaelfolkson> Tests, default user agent string
12:40 < hashcash> luke-jr: core will change to LOT=True before it becomes relevant
12:40 < nothingmuch> that would mean peering code, right?
12:40 < luke-jr> hashcash: unlikely
12:40  * michaelfolkson looking over PRs from UASF 2017
12:40 < hashcash> luke-jr: it's not relevant until closer to aug 2022
12:40 < luke-jr> hashcash: true
12:41 < proofofkeags> yeah, let's not forget that the most likely outcome is still an MASF
12:41 < occupier> maybe this question is too far into the future but what's the intended processes for BA regarding verifiable builds? is the intension just to release a client but not have verified builds?
12:41 < hashcash> so it's like all moot. just do something reasonable that others will have confidence in timeframe and then review
12:41 <@michaelfolkson> proofofkeags: If Core releases something that's true
12:41 -!- hudoo3 [c3ceb7d4@195.206.183.212] has joined ##uasf
12:41 < luke-jr> occupier: hopefully many will build them
12:42 < luke-jr> although Core 22.0 is switching from gitian to snake-oil which may make it harder - I may not even be able to build it
12:42 < hashcash> make a PR for core with LOT=false
12:42 < luke-jr> hashcash: I will NACK it
12:42 < hashcash> luke-jr: one problem at a time
12:42 < luke-jr> LOT=False is strictly harmful
12:42 < hashcash> luke-jr: no you should make the PR! and a LOT=true on this github
12:43 < hashcash> luke-jr: they will change it later before it becomes relevant
12:43 < luke-jr> better for Core to release nothing
12:43 < cguida> nothingmuch: It will probably matter if the MASF looks like it's going to fail
12:43 < luke-jr> hashcash: no, they won't.
12:43 < luke-jr> it makes no sense at all to release LOT=False then LOT=True later
12:43 < luke-jr> the only reason they would release LOT=False is if there is an intent to never do LOT=True
12:43 < occupier> I disagree
12:44 < bitentrepreneur> i also disagree
12:44 < hashcash> luke-jr: it's not better because many will only run core. and then MASF will risk delay. so for MASF you want MASF in core so reasonable timeframe they would consider review
12:44 <@michaelfolkson> I highly doubt Core will ever release LOT=true either
12:44 < nothingmuch> cguida: is that re scheduling? if MASF happens immediately and economic majority hasn't upgraded, as luke-jr said that's a 51% attack not a soft fork
12:44 <@michaelfolkson> I think it will need to be a community effort to get the LOT=true out
12:44 < luke-jr> hashcash: fewer would run Core+Taproot if they think Core mainline has Taproot
12:45 < hashcash> michaelfolkson: some active developers already said they would support LOT=true, if miners stalled MASF
12:45 < nothingmuch> cguida: so the relevant height start, not timeout
12:45 < hashcash> they are saying lets try LOT=false first, not LOT=false or give up
12:45 <@michaelfolkson> hashcash: Saying that and forcing through against opposition from Matt and others is a different thing
12:45 < proofofkeags> I find it less likely that Core will just concede usership to an alt client than eventually ship L=T
12:45 < occupier> hashcash +1
12:46 < hashcash> luke-jr: that's fine "fewer would run Core+Taproot" so long as both have compatible MASF parameters
12:46 < hashcash> it will activate faster with both versions being MASF compatible
12:46 < luke-jr> hashcash: it's just a delaying tactic
12:46 < luke-jr> hashcash: no, it isn't fine
12:46 < occupier> michaelfolkson are you saying Matt's opposition will indefinitely stall LOT=true if after lot=false doesn't work
12:47 < luke-jr> proofofkeags: then Core is malicious
12:47 < proofofkeags> luke-jr how do you figure?
12:47 < occupier> I don't see if luke-jr
12:47 < occupier> s/if/it
12:47 <@michaelfolkson> occupier: If I had to bet, yes. I don't know for sure. He wants a multi phase, multi year activation thing like Modern Soft Fork Activation
12:48 <@michaelfolkson> He's happy for this to go on years (or at least that is my understanding from what he has said publicly)
12:48  * occupier shrugs
12:48 < proofofkeags> michaelfolkson, that's my read as well
12:48 < luke-jr> proofofkeags: think about what possible motives could justify such an attitude
12:48 <@michaelfolkson> Some people will say do it after 6 months, others 9 months, others 11 months. It just becomes a mess
12:48 < hashcash> michaelfolkson: that will look like core indecision and driver ecosystem support for Core+Taproot LOT=true
12:49 < occupier> Feeling I have is Core doesn't want to lead with LOT false but is willing to LOT true if need be but maybe I'm projecting
12:49 <@michaelfolkson> hashcash: But they'll need a LOT=true client to run. And I don't think Core will release it
12:49 < proofofkeags> luke-jr the motives would be, to realize they were wrong about consensus, and then rejoin consensus
12:49 < hashcash> it is likely moot though if MASF is just released rest can change later
12:49 <@michaelfolkson> It is easier to suggest that occupier than actually do it
12:49 < occupier> valid
12:50 < nothingmuch> luke-jr: risk aversion is a rational and non malicious explanation, if perceived risk of chainsplit appears worse than opportunity cost of not activating,
12:50 < luke-jr> proofofkeags: ok, I misunderstood you I think
12:50 -!- Guest95662 [50390e8e@g14142.upc-g.chello.nl] has quit [Quit: Connection closed]
12:50 < nothingmuch> (not a defense of that relative risk assessment)
12:50 <@michaelfolkson> nothingmuch wants another 10 years of philosophy :)
12:50 < luke-jr> proofofkeags: history shows that isn't true tho
12:50 < nothingmuch> michaelfolkson: no, i really don't, i support LOT=true and i think the opportunity cost is worse, i just don't think ascribing malice is helpful
12:50 < luke-jr> mainline Core never included BIP148 even after the community switched to Core+BIP148
12:50 < proofofkeags> maybe, I'm just advancing a hypothesis, but I'd make a modest bet that with significant support they would
12:51 < occupier> If only we had prices to help us decide what the market wants
12:51  * occupier scratches chin
12:51 <@michaelfolkson> nothingmuch: Ok agreed on the malice part
12:51 < AaronvanW> I think this is off-topic, but since it's already being discussed... the most likely scenario IF Bitcoin Core release LOT=false is still that Taproot activates within a year (imo). (and thus, lot=true in Core wouldn't be necessary.)
12:51 <@michaelfolkson> Big IF AaronvanW if Core continues down the philosophy rabbithole
12:52 <@michaelfolkson> Anyway I'm leaving. Thanks for attending everyone. Feel free to continue discussion.
12:52 < stortz> bye michael
12:52 <@michaelfolkson> I may organize a follow up for next week. I'll see what people feel about discussing a timetable
12:52  * luke-jr goes off to do productive things
12:52 < proofofkeags> I'm also out, I'll have a review into the Bip8 PR by tomorrow evening US
12:52 < occupier> ty for organizing michaelfolkson
12:52 <@michaelfolkson> Sorry luke-jr
12:52 <@michaelfolkson> #endmeeting
12:53 < hashcash> michaelfolkson: it was productive
12:53 < devrandom> thank you michaelfolkson
12:54 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Quit: Connection closed]
12:54 < brg444> thanks michaelfolkson
12:54 < prayank> Thanks everyone
12:54 < bitentrepreneur> yes thanks michaelfolkson
12:54 < nothingmuch> proofofkeags: you might be interested in https://twitter.com/benthecarman/status/1365171232132509709 (haven't looked at the details)
12:55 < proofofkeags> I'm behind the times on DLC's rn
12:55 -!- Teleportando [8eb30758@d142-179-7-88.bchsia.telus.net] has joined ##uasf
12:55 < prayank> nothingmuch: Interesting
12:56 < proofofkeags> but yeah, having functioning prediction markets/fork futures would help break gridlock I think
12:56 -!- proofofkeags [~proofofke@205.209.24.233] has quit [Quit: Leaving]
12:57 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has joined ##uasf
12:57 -!- Alexandre_Chery [9466ba64@gateway/web/cgi-irc/kiwiirc.com/ip.148.102.186.100] has quit [Client Quit]
12:58 -!- hashcash [~adam3us@213.205.198.124] has quit [Remote host closed the connection]
12:58 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
12:59 < luke-jr> except there's no fork
13:01 < occupier> I think the intension was "a derivative contract to enable price discovery for taproot enforcing blocks"
13:02 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 240 seconds]
13:02 < luke-jr> but that makes no sense
13:03 < luke-jr> it's just Bitcoin
13:03 < nothingmuch> afaik there is no market per se for these, but if people want to bet on activation outcomes that's still potentially a useful piece of information
13:03 < occupier> nothingmuch +1
13:03 -!- zndtoshi [5b490e1d@91.73.14.29] has joined ##uasf
13:03 < nothingmuch> s/no market/no prediction market/ # p2p bets are still a market
13:04 < occupier> luke-jr people want and need prices
13:05 < occupier> If I offer to give someone 5% of a bitcoin if a softfork doesn't get merged if they give me 95% of a bitcoin if it does get merged, we can coordinate on the utility of the new consensus rules
13:06 < stortz> ?
13:06 < cguida> IIUC, if a lot of people are running lot=true and a lot of people are running lot=false when timeout hits, that will fork the blockchain once someone sends a transaction that is valid on one client but not the other. At that point, if exchanges added both tokens, I think I know which token I would hold
13:08 < stortz> that alone wouldn't cause chainsplit
13:08 < nothingmuch> cguida: ideally it wouldn't come to that, and it appears there's no reason it should since there are no reasonable objections to taproot thus far
13:08 < nothingmuch> even if many LOT=false clients run, MASF would still prevent that kind of split
13:09 < cguida> stortz: what did i miss?
13:09 < luke-jr> occupier: merges mean nothing in themselves
13:09 < luke-jr> and predicting an outcome doesn't mean you support the outcome
13:10 < occupier> sorry activated
13:10 < stortz> you would need a pay-to-taproot that is marked as anyoneCanSpend, then someone spending that and the spent being included inside a block
13:10 < luke-jr> cguida: LOT=False won't have a reliable token if miners attack them (and if miners don't attack, they both work with BTC)
13:11 < occupier> cguida chainsplit doesn't mean coins on either chain are unspendable on the other chain
13:11 < cguida> stortz: ok, thanks, missed the part about it being included in a block
13:12 < temp345903485> What do you guys think would be the requisite conditions for Core to actually publish an activation path?
13:12 < luke-jr> a market between Taproot and anti-Taproot would work, but I'm not aware of anyone actuvely making an anti-Taproot fork
13:12 < nothingmuch> with mandatory signalling exchanges could offer a no-taproot token
13:12 < luke-jr> temp345903485: what makes you think it's possible?
13:13 < luke-jr> nothingmuch: only if a no-taproot chain is created
13:13 < temp345903485> I'm trying to learn under what conditions it is possible
13:13 < belcher> temp345903485 from what iv seen core want to see that the economy will all be running the same consensus rules
13:13 < luke-jr> nothingmuch: LOT=False isn't enough for that
13:13 < belcher> right now the concern is that some of the economy will run one thing and another part run something else, and then theres a consensus failure / chain split
13:13 < luke-jr> temp345903485: magically convince Matt to support LOT=True I guess
13:13 < bitentrepreneur> a valid concern
13:14 < nothingmuch> luke-jr: agreed, i suppose if an exchnage is interested in offering that then they would support the development of such a client, but it seems very doubtful
13:14 < temp345903485> Matt is not Core
13:14 < luke-jr> belcher: Core is making that happen :P
13:14 < belcher> i think thats why they dont want to release even LOT=false, because they fear they'll be a UASF movement that has some people supporting LOT=true
13:14 < belcher> luke-jr i disagree with you when you say that its all the other sides fault
13:14 < belcher> luke-jr its takes two to tango, every disagreement has two sides
13:14 < luke-jr> belcher: the alternative is ossification
13:14 < temp345903485> Seems like the "other side" now is the past
13:15 < belcher> luke-jr thats what we're heading for unless we find an agreement
13:15 < luke-jr> belcher: or just move forward without unanimity
13:15 < temp345903485> Ossification is not the worst outcome
13:15 < luke-jr> Taproot via BIP8(True) has enough community support
13:15 < luke-jr> would unanimity be ideal? sure. But this is good enough.
13:15 < belcher> maybe if you live in a filter bubble :p
13:15 < luke-jr> ossification is fatal
13:16 < belcher> and ignore the mailing list and these meetings which had all those people saying they prefer MASF
13:16 < luke-jr> belcher: BIP8(True) is MASF
13:16 < occupier> The protocol will change as frequently as users demand it to
13:16 < cguida> nothingmuch: completely agreed, but, as an analogy, things shouldn't come to court hearings, fines, and jail time either, but sometimes people misbehave. the possibility of the worse outcome encourages cooperation. we have them there so we don't have to use them. so, the bad outcome that we all want to avoid is a chainsplit. but, if there is a chainsplit, we know which fork will be more valuable.
13:16 < belcher> nope, it is MASF followed by UASF
13:16 < luke-jr> it's MASF without a veto loophole
13:17 < temp345903485> luke-jr, how is ossification fatal? (beyond the 32-bit timestamp running out in a hundred years)
13:17 < belcher> it seems what will happen is core wont release anything, a UASF alt-node will maybe be released by someone else but nobody will adopt it, nothing will happen for at least a year or two
13:17 < nothingmuch> cguida: agreed, afaik prediction markets give good information about future outcomes. but whether or not that information is worth the requirement to support an anti-taproot chain is unclear to me.
13:17 < luke-jr> temp345903485: if an altcoin can present a compelling superiority to Bitcoin, Bitcoin will be replaced
13:18 < belcher> altcoins cant beat bitcoin's network effect and long history
13:18 < belcher> plenty of altcoins already have better features than bitcoin, but its not about the features its about the collective delusion, in other words its about the money
13:18 < luke-jr> no, they don't.
13:18 < temp345903485> Agree with belcher on that. Is there a list somewhere of innovations from altcoins that have made their way into Bitcoin?
13:18 < nothingmuch> belcher: isn't the point that the failed to beat unossified-bitcoin?
13:18 < cguida> nothingmuch: are there any decentralized prediction markets that work reasonably well?
13:19 < belcher> btw im reminded of the arguments from 2016 when people said "we need to fork to a larger block size otherwise some altcoin will overtake us"
13:19 < nothingmuch> cguida: i honestly have no idea if that's even possible... but DLCs allow people to make bilateral bets settled by an oracle, see the twitter link above for one such oracle provided by benthecarman
13:19 < luke-jr> belcher: if the Bitcoin devs give up on improving Bitcoin and make a new altcoin, you really think Bitcoin stands a chance?
13:20 < temp345903485> nothingmuch Taproot makes DLCs so much easier :-D
13:20 < nothingmuch> just one more reason for LOT=true ;-)
13:20 < cguida> belcher: those people were wrong, the market has spoken! ;)
13:21 < belcher> luke-jr regardless of whether its a good or bad thing, it seems we're hurtling towards ossification right now
13:21 < cguida> i have no idea why the market would support a coin without taproot more than one with taproot. it doesn't make sense. it was the same with segwit
13:22 < stortz> just because altering blocksize wasn't relevant, doesn't mean ossification isn't either
13:22 < prayank> cguida: greed and misinformation. Maybe LOT=False will motivate someone to become next Jihan and say things like: Taproot is unfairly XYZ
13:23 -!- lightlike [~lightlike@p200300c7ef19540068eed5afea095ef2.dip0.t-ipconnect.de] has left ##uasf ["Leaving"]
13:23 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
13:24 < cguida> nothingmuch: sweet, thanks. that would be super interesting if bitcoin used an ethereum contract or something to update its consensus rules xD
13:24 -!- stortz [b1982408@177.152.36.8] has joined ##uasf
13:24 < cguida> prayank: yeah, there was that one guy on the mailing list who was like "taproot is TOO PRIVATE"
13:24 < luke-jr> cguida: while linking his mixer XD
13:24 < cguida> hahaha
13:24 < temp345903485> I need to start going by HIS EXCELLENCY
13:25 < luke-jr> temp345903485: seems like a good way for people to not take you seriously tbh
13:25 < luke-jr> credibility of "temp345903485" > credibility of "HIS EXCELLENCY"
13:25 < prayank> temp345903485: Taproot helps improve lot of things and will be better for lot of projects. Also almost everyone agrees Taproot is good for Bitcoin. Problem is politics and drama around activation and this can lead segwit 2.0 imo
13:25 < nothingmuch> gnusha: YEEEEET
13:25 < temp345903485> luke-jr lolol
13:25 < prayank> guida: looked like a troll
13:26 < luke-jr> pretty sure it wasn't his first post
13:26 < nothingmuch> fwiw if i understood that mixer is not just custodial, it's by design transparent to KYC
13:26 < temp345903485> prayank I agree. My question is how to reduce the drama / stress / politics level. What conditions would make things more favorable?
13:27 < prayank> temp345903485: LOT=True fixes this
13:27 < temp345903485> Go on...
13:27 < zndtoshi> luke-jr can you address belcher's point that if core doesn't release anything we're heading to ossification?
13:27 < temp345903485> zndtoshi My take: most large economic players won't run non-
13:27 < stortz> more like we're heading for a different development team
13:27 < belcher> thats not necessarily true
13:27 < temp345903485> non-Core code
13:28 < nothingmuch> gnusha: sorry, that was re cguida's joke
13:28 < belcher> in theory the entire bitcoin economy could adopt an alt-node instead of core's code
13:28 < temp345903485> in theory, yes
13:28 < nothingmuch> oh wait i'm talking to a bot right? ;_;
13:29 < luke-jr> zndtoshi: that's assuming nobody uses this Core+Taproot
13:29 < stortz> if core chooses to not develop any more node tech, someone else will pick up the torch, just like core took the torch from mike
13:30 < luke-jr> stortz: Mike Hearn? He never did anything special
13:30 < luke-jr> "Core" took the torch directly from Satoshi
13:31 < cguida> luke-jr he helped upgrade us to leveldb, that was pretty special
13:31 < luke-jr> lol
13:31 < stortz> gavin, mike, whatever
13:32 < stortz> gavin was in core
13:32 -!- bitentrepreneur [2578d1d4@37.120.209.212] has left ##uasf []
13:32 < luke-jr> stortz: anyway, you missed the point
13:33 < luke-jr> this scenario isn't "Core deciding not to develop any more node tech"
13:33 < luke-jr> it's the community rejecting more node tech, and Core developing it anyway - just for an altcoin now
13:36 < prayank> People should start using other implementations anyways. This does not mean Bitcoin Core is bad or I dont like Core contributors. It will be good for decentralization of Bitcoin. Atleast we will have more maintainers, contributors etc. around the world in different projects that can improve things in their own ways. Wasabi uses Knots and few other projects use non-core nodes.
13:37 < cguida> luke-jr but again, no one thinks bitcoin with taproot would be an altcoin. in the presence of both, bitcoin without taproot would be the clear altcoin, just like bitcoin without segwit was the clear altcoin
13:37 < prayank> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018462.html
13:37 < luke-jr> prayank: but the scenario being discussed was ossification and the impact it would have
13:38 < cguida> prayank: would be interesting if alternate implementations started stepping up. imagine if libbitcoin, btcd, bcoin, etc all released lot=true
13:38 < stortz> who are the maintainers of those
13:39 < prayank> luke-jr: People can have their own opinions about that term "ossification". IMO Bitcoin has scope for lot of improvement.
13:39 < luke-jr> prayank: ossification means Bitcoin no longer improves
13:40 < prayank> luke-jr: Bitcoin Core may not improve. Bitcoin will always improve as long as someone in community wants to improve.
13:40 < cguida> stortz: not sure, check their github repos
13:40 < luke-jr> prayank: ossification means Bitcoin no longer improves
13:40 < luke-jr> anything else isn't ossification
13:41 < prayank> Okay but I do not believe that is good atleast at this moment
13:41 < luke-jr> well, that's my point: ossification would be fatal to Bitcoin
13:43 < prayank> cguida: It will be interesting but according to piecharts on luke-jr website core is used by 90% nodes
13:43 < luke-jr> 99+%
13:43 < prayank> :-(
13:43 < luke-jr> haven't figured out why newbies aren't using other nodes more diversely
13:43 < cguida> prayank: i bet core releasing lot=false and the other implementations implementing core=true would change that
13:44 < prayank> Possible
13:44 < luke-jr> cguida: using Core+Taproot is still using Core
13:44 < cguida> luke-jr: why? because other implementations haven't implemented taproot yet?
13:45 < luke-jr> because it's still just Core (with Taproot support added)
13:45 < occupier> cguida prayank btcd has signaled they will release lot=false
13:45 < luke-jr> and how could other implementations do Taproot when we're now second-guessing the parameters again?
13:45 < cguida> luke-jr i'm not sure what you mean. running btcd with lot=true would not be running core
13:46 < luke-jr> cguida: I just mean people swtiching to Core+Taproot would not be the same as switching to other impls
13:46 < cguida> i agree...
13:47 < luke-jr> it would help get Taproot activated, but wouldn't help node diversity
13:47 < cguida> oh, that's all i was saying. i wasn't saying that node diversity would increase
13:48 < cguida> prayank was saying that other implementations don't matter because no one uses them. i was just pointing out that, *specifically for taproot activation*, they could matter
13:49 < cguida> the whole point of this channel is to discuss an alternate client with lot=true, right?
13:50 < cguida> michaelfolkson was saying he wasn't comfortable being in charge of that effort with short timelines. but maybe there are alternate implementation maintainers who would be
13:51 < luke-jr> impossible now
13:51 < luke-jr> yesterday, I could have quietly added a -taproot option to Knots
13:51 < luke-jr> but now I can't because we no longer know startheight/timeoutheight
13:52 < cguida> why is the value from yesterday invalid? if you released it, people would probably run it
13:53 < luke-jr> because the value from yesterday was with the assumption of a release within a week or two
13:54 < luke-jr> if nobody else is willing to participate in the release, it just won't happen
13:56 -!- peterrizzo_136 [44c18924@ool-44c18924.dyn.optonline.net] has quit [Quit: Connection closed]
13:56 < cguida> >because the value from yesterday was with the assumption of a release within a week or two
13:56 < cguida> sorry, i guess i missed that part of the conversation. what "release" are you referring to? this is just the release of the client that signals lot=true, correct? if you could release it yesterday, why not today?
13:57 < cguida> luke-jr: yeah, CSW is such a comic-book villain. there needs to be better protection for devs. has anyone started a legal defense fund yet?
13:58 < prayank> luke-jr: What if CSW says he is against LOT=false? Will Core maintainers and long term contributors change their opinion, use LOT=True? Core can't even add a link to Bitcoin Whitepaper in the implementation used by 99% people
13:59 < prayank> cguida: Thats why we need more implementations where maintainers can just ignore what scammers say
14:00 < cguida> yeah, that's why shaolinfry had the right idea
14:00 < luke-jr> cguida: today people here decided we don't know when there will be a release, and therefore don't know the parameters
14:01 < cguida> isn't the reason why "we don't know when there will be a release" because people weren't comfortable with releasing something on such a short timescale? so, if someone is comfortable releasing something on a short timescale, isn't that point moot?
14:01 < luke-jr> cguida: IF, yes
14:02 < luke-jr> cguida: the past week has suggested that isn't the case
14:06 -!- guest23024084 [ad441c94@pool-173-68-28-148.nycmny.fios.verizon.net] has joined ##uasf
14:07 -!- hudoo3 [c3ceb7d4@195.206.183.212] has quit [Ping timeout: 240 seconds]
14:11 < luke-jr> not sure what the point of waiting for Core is when it's clear Core is dysfunctional in this regard and won't release it without the community migrating to another release
14:11 -!- nvk [~nvk@89.36.78.182] has quit [Ping timeout: 246 seconds]
14:18 < zndtoshi> Luke if Core released a version with lot=false it wound't be Bitcoin anymore?
14:20 < stortz> it would be bitcoin with a veto risk, again
14:20 < zndtoshi> There is no veto. Only a delay risk!
14:23 < zndtoshi> luke-jr can I fork Bitcoin and add a Taproot flag day tomorrow with LOT=True and say that's the real Bitcoin because Taproot has consensus?
14:24 < prayank> luke-jr: I also wanted to know if LOT=True or LOT=False affects vulnerable nodes shown here in long term: http://luke.dashjr.org/programs/bitcoin/files/charts/security.html
14:25 < prayank> I had asked few questions on reddit about vulnerable nodes earlier: https://www.reddit.com/r/Bitcoin/comments/lb6dpi/vulnerable_bitcoin_nodes/ but still not clear why do these exist(reasons)?
14:35 < prayank> https://twitter.com/murchandamus/status/1366876405309538311 LOL
14:47 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined ##uasf
15:00 -!- jonny1000 [51934b9f@host81-147-75-159.range81-147.btcentralplus.com] has quit [Quit: Connection closed]
15:05 -!- stortz [b1982408@177.152.36.8] has quit [Quit: Connection closed]
15:20 -!- peterrizzo [~peterrizz@ool-44c18924.dyn.optonline.net] has quit [Quit: peterrizzo]
15:21 -!- peterrizzo_ [~peterrizz@ool-44c18924.dyn.optonline.net] has joined ##uasf
15:22 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
15:27 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 256 seconds]
15:32 -!- peterrizzo_ [~peterrizz@ool-44c18924.dyn.optonline.net] has quit [Quit: peterrizzo_]
15:33 -!- random94726 [44961646@S0106f8a097f03715.ed.shawcable.net] has quit [Quit: Connection closed]
15:34 < brg444> maybe that'll work provided it gets enough Nacks to see where they actuall stand
15:35 < luke-jr> interesting thought
15:40 < prayank> I have started working on things I mentioned earlier in meeting. Hopefully complete in next few days. If anyone wants to help me, please DM: https://twitter.com/prayankgahlot/status/1366891802515574785
15:41 -!- prayank [~Prayank@2409:4053:2e1b:69dd:ad75:b355:dcd:efff] has left ##uasf []
15:58 -!- hudoo3 [c3ceb7d4@195.206.183.212] has joined ##uasf
16:05 -!- hudoo3 [c3ceb7d4@195.206.183.212] has quit [Quit: Connection closed]
16:31 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
16:36 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 264 seconds]
16:47 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:55 < luke-jr> https://twitter.com/achow101/status/1366902121405251585 just goes to show we should move faster if this is going to happen
17:10 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 245 seconds]
17:10 -!- belcher [~belcher@unaffiliated/belcher] has joined ##uasf
17:24 -!- peterrizzo [~peterrizz@ool-44c18924.dyn.optonline.net] has joined ##uasf
17:40 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
17:45 -!- guest23024084 [ad441c94@pool-173-68-28-148.nycmny.fios.verizon.net] has quit [Quit: Connection closed]
17:45 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 260 seconds]
18:01 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##uasf
18:04 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds]
18:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##uasf
18:30 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##uasf
18:32 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
18:34 -!- peterrizzo [~peterrizz@ool-44c18924.dyn.optonline.net] has quit [Quit: peterrizzo]
18:49 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
18:57 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 240 seconds]
18:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
19:08 < kanzure> michaelfolkson: belcher: any of y'all want to donate older logs?
19:20 < luke-jr> kanzure: this wasn't a logged channel before; also see PM
19:32 < kanzure> alright fair enough
20:00 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
20:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##uasf
20:05 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##uasf
20:07 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds]
20:09 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
20:17 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 260 seconds]
20:23 -!- occupier [~occupier@195.181.160.175.adsl.inet-telecom.org] has quit [Quit: occupier]
20:26 -!- nvk_ [~nvk@89.36.78.246] has joined ##uasf
20:26 -!- nvk_ [~nvk@89.36.78.246] has quit [Client Quit]
20:49 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
20:56 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 245 seconds]
20:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##uasf
21:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
21:31 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
21:36 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 260 seconds]
22:11 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
22:18 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 276 seconds]
22:42 -!- zndtoshi [5b490e1d@91.73.14.29] has quit [Quit: Connection closed]
22:52 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
22:59 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 245 seconds]
23:24 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 256 seconds]
23:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##uasf
23:34 -!- hashcash [~adam3us@213.205.198.124] has joined ##uasf
23:39 -!- hashcash [~adam3us@213.205.198.124] has quit [Ping timeout: 240 seconds]
23:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds]
--- Log closed Wed Mar 03 00:00:45 2021