--- Log opened Thu Jul 16 00:00:23 2020
00:03 -!- jonatack [~jon@37.167.48.219] has joined ##taproot-activation
00:15 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has quit [Remote host closed the connection]
00:16 -!- provoostenator [~quassel@provoostenator.sprovoost.nl] has joined ##taproot-activation
01:30 -!- jonatack [~jon@37.167.48.219] has quit [Ping timeout: 265 seconds]
02:09 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
02:37 -!- graeme1 [~graeme@24.42.181.32] has quit [Quit: WeeChat 2.8]
03:31 -!- jonatack [~jon@37.167.121.211] has joined ##taproot-activation
03:38 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
04:09 -!- jonatack [~jon@37.167.121.211] has quit [Read error: Connection reset by peer]
04:30 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
04:30 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
04:30 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Remote host closed the connection]
04:30 -!- cato_ [~alec@gateway/tor-sasl/alec] has quit [Remote host closed the connection]
04:30 -!- cato_ [~alec@gateway/tor-sasl/alec] has joined ##taproot-activation
04:31 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
04:32 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
04:40 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined ##taproot-activation
04:44 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Remote host closed the connection]
04:45 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation
04:45 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Client Quit]
04:46 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation
04:50 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined ##taproot-activation
05:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
05:47 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
05:48 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has quit [Remote host closed the connection]
05:48 -!- sosthene [~sosthene@gateway/tor-sasl/sosthene] has joined ##taproot-activation
07:02 -!- somethinsomethin [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has joined ##taproot-activation
07:15 < somethinsomethin> Hello! I just found this channel and read the logs, espcially the part about "fighting the last war" and somebody mentioning that you have to do that or you'll lose the new one to the old tactics, and I just wanted to add that this is probably not a good way of looking at things
07:16 < somethinsomethin> first off (to stay in the metaphor), the old war was won (in the sense that segwit activated). Apart from traumatizing devs and splitting off a part of the community, the opponents achieved very little
07:17 < somethinsomethin> secondly, if we assume their goal was to gain control over the coin, they kind of achieved that by doing their own fork, so I'd say that their interest in bitcoin is probably diminished right now (they have their own coin to take care of)
07:19 < somethinsomethin> thirdly, I think everyone still remembers vividly all the tactics and discussions that took place, and saw how things turned out in the end. It's somewhat doubtful that significant parts of the community would fall for the same thing again
07:22 < somethinsomethin> tldr: If you look at this in the metaphor of "fighting a war", then you'd have to find out what the goals of adversaries might be. Since their takeover attempt last time failed, the best option for them right now would probably be to stall bitcoin as much as possible
07:23 < somethinsomethin> which would mean that super long activation periods would play right into their hands
07:23 < somethinsomethin> oh well, just my two cents. Feel free to ignore :-)
07:26 < zmnscpxj_> So BIP8 lockinontimeout=true 1 month, is what you are saying? :-)
07:56 -!- Netsplit *.net <-> *.split quits: meshcollider, instagibbs
07:56 -!- Netsplit *.net <-> *.split quits: takinbo, waxwing, wraithm
07:56 < cato_> IMHO the whole process needs clarifying before going into details such as specific time intervals
07:57 -!- Netsplit over, joins: wraithm, takinbo, waxwing, instagibbs, meshcollider
07:57 < cato_> some days ago, I was told that the measured hashrate was never intended as a vote. yet matt's post to the ML seems to indicate that to him it does, for he writes about "miners blocking changes to Bitcoin"
07:58 < zmnscpxj_> "never intende as a vote" does not preclude "accidentally becomes a vote"
07:58 < zmnscpxj_> just that the design does not reflect the intent
07:59 < cato_> zmnscpxj_: okay, but being explicit could not hurt
07:59 < cato_> I mean in the wording
07:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]
07:59 < zmnscpxj_> I generally think that "miners blocking changes to Bitcoin" is a bug, if the miners do not reflect the users intent
08:00 < cato_> that seems valid
08:02 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
08:02 < cato_> and in case users want something that hurts miners? (honest question) they get no veto?
08:03 < zmnscpxj_> Ideally, to the extent that miners "use" Bitcoin, is the only extent they should matter
08:03 < zmnscpxj_> I believe gmaxwell notes that some miners directly put their funds into exchange addresses, which implies they are not using Bitcoin actually
08:04 < zmnscpxj_> they just get paid for the PoW.
08:08 < cato_> that's one understandable way of looking at it
08:10 < zmnscpxj_> So what is rough consensus so far? BIP8 lockinontimeout=true 42 months, then we-the-developers precommit that if it does not lock in in 12 months, we consider whether we should softfork-out Taproot by disallowing SegWit v1? I believe that is what gmax is proposing?
08:18 < roconnor> I think we'd only soft fork out taproot in the unlikely case a soft-fork unrepairable issue raised about taproot. (Technically we only need to soft-fork out taproot and not the entire v1 space in such an unlikely scenario).
08:19 < zmnscpxj_> this softfork-out-taproot, basically we ban SegWit v1 outputs with witness length 32? leaves other witness lengths useable?
08:19 < zmnscpxj_> or something else?
08:20 < roconnor> I'd also add to that proposal that the developer be willing to soft fork in a requirement that block signal for activation (soft-fork activation activation) when there is seen to be wide spread user uptake in the face of miner appathy.
08:20 < zmnscpxj_> like a BIP91-over-again?
08:20 < roconnor> zmnscpxj_: yes, banning segwit v1 length 32 would be the ultimate abort technique.
08:21 < roconnor> Right, but without the last minute planning.
08:21 < zmnscpxj_> And NYA lol
08:21 -!- ksedgwic [~ksedgwic@157-131-108-129.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
08:22 < roconnor> But we can, and should, start the first phase deployment before necessarily deciding on the taproot activation activation plan.
08:22 < zmnscpxj_> sorry, what does that mean...?
08:22 < zmnscpxj_> "first phase deployment" is?
08:23 < roconnor> first phase is what you said (or what gmax said).
08:23 < zmnscpxj_> ah ok
08:23 < zmnscpxj_> timeout=42 months? really
08:23 < zmnscpxj_> ?
08:23 < roconnor> second phase is deciding we have seen user uptake in the presence of miner apathy.
08:23 < roconnor> well a 42 month timeout isn't so bad if we are thinking of forcing early activation.
08:24 < zmnscpxj_> ah, I guess that is agreeable
08:24 < zmnscpxj_> I think we have to make it clear that we are willing to consider force-earlier-activation, to preclude an independent UASF effort
08:24 < roconnor> Right.
08:25 < roconnor> I mean, I would be fine with 24 months or whatever.  I think the period doesn't matter too much if we are intending to deploy an early activation as contgency.
08:26 < zmnscpxj_> A BIP8 lockinontimeout=true 42 months seems to me quite simple as well, compared to Modern Softfork Activation variants
08:45 -!- ksedgwic [~ksedgwic@157-131-108-129.fiber.dynamic.sonic.net] has joined ##taproot-activation
08:57 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has joined ##taproot-activation
08:58 < somethingsomethi> So what is the reasoning behind lockinontimeout=true? Because it seems to me that would only drive apathy, no? In that you don't have to do anything, it'll activate on its own
09:02 < roconnor> on the contrary, miners risk mining invalid blocks if they don't upgrade and it activates on its own.
09:02 < somethingsomethi> but I thought we don't care about miners?
09:03 < somethingsomethi> (in that: If they don't follow the rules, they stop being miners)
09:04 < roconnor> Right, that that is what lockinontimeout=true entails.
09:04 < roconnor> whereas if lockinontimeout=false, then then miners don't have to worry about activation as long as the signaling rate says well below 95%.
09:05 < roconnor> And if one miner controls moderately more than 5% of the hash rate, they don't have to do anything at all.
09:05 < roconnor> And that is miner apathy.
09:08 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
09:09 < somethingsomethi> I'm asking because every proposal with lockinontimeout=true seems to run at least two years, whereas for lockinontimeout=false one year was considered sufficient
09:10 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
09:11 < roconnor> lockinontimeout=true generally needs a longer time period because a vast majority of users need time to upgrade their nodes to reject newly invalidated blocks that nonupgraded miners might produce.
09:12 < somethingsomethi> I just wonder if things wouldn't go faster with the false variant (maybe with a lower threshhold, since the changes are smaller than segwit)
09:12 < somethingsomethi> could be seen as "ok, miners, last time you didn't do so well, but we're giving you a second chance"
09:12 < roconnor> where as, so long as not too many miners are false signaling, miners that activate a soft fork are coordinating to that invalid blocks will never have the most proof of work for very long.
09:13 < roconnor> The long period only refers to the time out.
09:13 < somethingsomethi> Sure, it's a worst-case thing
09:14 < roconnor> so if miners are willing to activate the lockinontimeout=false within one year, I don't see why they wouldn't activate lockinontimeout=true within one year too, even if the timeout is 2 years or more away
09:14 < roconnor> what lockinontimeout=true says is that the miners are going to have to upgrade eventually anyways, so there is no point in ignoring it and making it go away.
09:16 < somethingsomethi> Maybe it's just a question of how to communicate it properly. I know it's silly, but the first time I saw the modern softfork proposal, my reaction was "ok, I guess I'll check back on taproot in 2025 then"
09:19 < somethingsomethi> I guess for me the difference is that the false version puts a bit more pressure on miners in the sense that if it doesn't activate, it'll be their fault. Which could be a motivation to do something or at least explain why you won't
09:20 < cato_> 18:17 < roconnor> so if miners are willing to activate the lockinontimeout=false within one year, I don't see why they wouldn't activate lockinontimeout=true within one year too, even if the timeout is 2 years or more away
09:20 < cato_> out of spite, for instance :)
09:20 < somethingsomethi> whereas with the 2-year true version they could just schedule it for the end of next year and if someone complains they can just point to the devs and say "don't blame use, we're working in the constraints given"
09:24 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
09:25 < cato_> one can always follow up on a failed lockinontimeout=false attempt with a shortened lockinontimeout=true attempt but not making it an automated process, which might send the wrong message
09:25 < roconnor> Well that's why I think we would should follow it up with a second soft-fork forcing the activation taproot if necessary.  And ideally be clear that we are planning to do so.
09:26 < cato_> that's sensible
09:26 < cato_> and is in line with the reasoning with BIP8 if I interpret it correctly
09:27 < cato_> 'lockinontimeout should be set to true for any softfork that is expected or found to have political opposition from a non-negligible percent of miners' because, to me, without a failed attempt, the question is how to anticipate oppositon
09:27 < roconnor> In the mean time we learn how fast user upgrades went (and that, in fact, users did upgrade).  Which lets us wait until there is broad user support and plan out how long the forced activation should take.
09:29 < roconnor> I personally don't really think the reasoning there is really that great, and I think we should just set it to true always.
09:30 < roconnor> But if we are planning to follow up with a forced activation, I'm not sure it matter too much if the timeout of first phase is set to true or false.
09:31 < roconnor> Generally speaking, the plan has always been to never hit the timeout.
09:31 < roconnor> It's just there to make sure version bits don't stay in limbo forever.
09:31 < cato_> I'm new, so I don't have all the facts. It's just my uninformed opionion. by having a discussion period after a failed lockinontimeout=false attempt before starting a lockinontimeout=true attempt, any doubts about intentions should be cleared
09:33 < roconnor> That is my understanding of what Matt think.  I personally think the chances of learning anything beyond the fact that miners are either apathetic or mysterious is extermely low.
09:33 < roconnor> Having a discussion period certainly wouldn't have informed us about covert ASICBOOST from the miners.
09:34 < roconnor> And again, it is worth pointing out that taproot is specifically designed to be unobjectionable.  It has almost no effect on users who don't wish to use it.
09:34 < cato_> roconnor: it wouldn't. but they couldn't have offered any serious criticism, either. so lockinontimeout=true wouldn't have been met with opposition by the community. at least that's the theory
09:35 < cato_> roconnor: I understand. but the activation discussion should be based on principles and indepentent of the actual changes, should it not?
09:35 < somethingsomethi> in reality, wouldn't the discussion already happen while the first period is still running anyways?
09:35 < roconnor> Right but alternatively we can have a 4-year phase 1 deployment, and have that discussion during the time we discussing a phase 2 forced deployment.
09:36 < roconnor> which I feel gets the same thing accomplished without locking ourselves into a fixed and lengthly timescale.
09:36 < cato_> that doesn't account for the miners bringing up valid reasons that result in the community rejecting the soft fork
09:36 < cato_> highly unlikely, but taking this route off the table just sends the message: your opposition (no matter whether political or technical) means nothing to us
09:37 < somethingsomethi> starting with the true variant would also entail an abort-softfork if something goes wrong, right?
09:37 < roconnor> To deal with the unlikely possibility of valid reasons to reject the soft-fork, I think we should instead softfork to bury taproot.
09:37 < roconnor> which is generally how we fix consensus bugs.
09:38 < roconnor> (realisticly we could probably fix taproot through a soft-fork too)
09:39 < cato_> my concern with that is that BIP8 does not have an explicit opposition phase as would be the base with a two-step approach. but again, that just my opinion
09:39 < roconnor> introducing a technical bug in taproot isn't any more likely than accidently introducing a consensus bug in any of the other code changes Core makes to the consensus critical code paths, whcih happens all the time.
09:39 < somethingsomethi> but do you think this kind of forking would also be necessary if a problem was detected during a false cycle?
09:40 < roconnor> cato_: I think we are in the explicit opposition phase right now.
09:41 < cato_> again, I'm new, but that feels like a subjective opinion
09:41 < cato_> a lot of the process feel informal to me. lurking in this channel, I'm not even sure how the 'rough consensus' will be decided
09:42 < roconnor> somethingsomethi: I mean, I would be okay with a false cycle.  But I think the chances of a technical error is pretty low.  I mean Core touches the conesnus critical code paths all the time but we don't explicitly plan for their failure.
09:42 < roconnor> cato_: As Alex B. points out consensus is a path, not a destination: https://twitter.com/bergealex4/status/1283086826002165760
09:44 < cato_> roconnor: I'm excited on how it'll turn out :)
09:44 < roconnor> we should make a good faith attempt to solicit comments on the proposal from stakeholders, and once we've everyone who we can think of reaching out to, we are at the end of the process.
09:44 < roconnor> Creating this channel and you finding out about it is this process at work.
09:46 < roconnor> And activation should only proceed when this process is complete;  and this lets us design an activation scheme with this in mind.
09:48 < roconnor> I understand that optech has been doing some reaching out to people and organizations as part of this process.
09:48 < roconnor> I hope they publish who they spoke to and what they heard back.
09:49 < somethingsomethi> this begs a bit the question, who decides when the process is complete and how
09:50 < roconnor> That's fair.  I think that before Core incorporates an activation PR, they should amoung the developers have consensus that they believe they process has been completed in good faith.
09:51 < somethingsomethi> and what we're doing here is coming up with that PR?
09:52 < roconnor> I think that is a fair statement.
09:53 < roconnor> That said, a Core PR is neither necessary nor sufficent for taproot deployment.
09:53 < roconnor> It isn't necessary because anyone can fork the repo and drum up support for users running their client.
09:54 < roconnor> Nor is it sufficents because users need to download the new Bitcoin Core software and actually run it.
09:55 < roconnor> So maybe it is more accurate to say the process is complete when everyone involved in the process beleives it is completed.
09:55 < somethingsomethi> yes, but the bitcoin core PR route is probably what people are generally aiming for
09:56 < somethingsomethi> also sounds a bit more actionable than let's everyone wait for everyone to believe we don't have to wait any more
09:58 < somethingsomethi> so, supposing for a moment this channel's purpose was to come up the the recipe for activation, any thoughts on how to measure consensus on that?
09:59 < roconnor> Right,  When it comes to a Core PR, naturally all the developers can do is ask themselves if they think the process has been completed in good faith.
10:01 < roconnor> And it if turns out that Core developers are so out of touch and no one runs Bitcoin Core anymore, then it doesn't really matter what they do.
10:01 < cato_> somethingsomethi: some people proposed starting a wiki, but this lead to a philosophical discussion about the ethics of soliciting opinions and went nowhere :)
10:02 < roconnor> somethingsomethi: I'm hoping that discussion here will expand and then narrow the set of canditate activation methods.
10:02 < somethingsomethi> cato_: Glad I missed that discussion :-)
10:03 < roconnor> So far we have ideas like (1) we can possibly emergency softfork out taproot to deactivate it before activation in case of problems
10:03 < somethingsomethi> roconnor: Is there a practical way to keep track of what the currently preferred alteratives are?
10:03 < roconnor> (2) we might be able to layer activation a la BIP91-style.  Taproot doesn't touch P2P logic making everything easier.
10:04 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack]
10:04 < roconnor> somethingsomethi: *lol* I think there is a certain type of people who excell at preparing those sorts of things, and if anyone here is that sort of person that would make a very valuable contribution I think.
10:07 < roconnor> (3) we raise the point that taproot is designed to be unobjectionable.  So, at least by design, there really shouldn't be any controversy. (and perhaps accordingly we shouldn't plan for controversy.)
10:08 < somethingsomethi> oh wow. I bet the person who came up with (3) is a mathematician by trade :-)
10:09 < roconnor> You got me.  I have a degree in pure mathematics.
10:09 < somethingsomethi> (no offense intended btw, it's just a line of reasoning that seems very familiar :-))
10:11 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation
10:13 < somethingsomethi> ok, so (1) seems more like a fallback in case anything goes wrong, (3) sounds more like a justification for an activation procedure (as opposed to than a procedure), and (2) mentions layering on top of something
10:13 < somethingsomethi> I feel like I'm missing some baseline here
10:15 < somethingsomethi> like, in practical terms it's going to be one or more bip8/bip9 cycles with or without automatic activation, right?
10:15 < roconnor> I think if we were deploying something that could be objectionable, Like disabling CODESEPARATOR in legacy and P2SH scripts, then that might influence the activation method.
10:15 < roconnor> (regarding (3))
10:17 < roconnor> somethingsomethi: I don't think anyone has proposed something that isn't a sequential or concurent set of bip8 cycles with our without activation on timeout.
10:18 < somethingsomethi> ok, that narrows it down somewhat. So the bip91 thing would work on top of that then (instead of doing another cycle?)
10:18 < roconnor> indeed it must.
10:18 -!- brg444 [uid207215@gateway/web/irccloud.com/x-evwsguqdkbxexhqp] has joined ##taproot-activation
10:19 < roconnor> I *think* the bip 91 could maybe be simply a flag day though.  It is something that isn't clear to me.
10:20 < somethingsomethi> so if we did a one-year bip8 (false) cycle and followed that up after 6 months with a bip91, we would have pretty much completed a reenactment of segwit (with slightly different tools)
10:21 < roconnor> oh I fogot there are some proposal for decreasing the activation threshold over time.
10:22 < somethingsomethi> yeah, I've read about those
10:24 < somethingsomethi> (but to me at least it seems silly to develop a whole new thing if we can achieve more or less the same with the tools that exist)
10:31 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer]
10:33 -!- benthecarman [~benthecar@185.123.143.222] has joined ##taproot-activation
10:36 < instagibbs> somethingsomethi, definitely agree, creating additional tooling is a time/attention/review hazard, we should avoid if possible imo
10:39 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
10:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
10:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
10:47 < instagibbs> not that my opinion matters but coming around to the "thou doth protest too much" aspect of deployment. Just bip8(true), long timeout to give plenty of time to abort in case of issue found, possible earlier activation.
10:48 < somethingsomethi> meh, I still think that gives people more excuse to drag their feet, but my opinion matters even less :-)
10:48 < roconnor> I mean, we don't really need a long time to abort in case an issue is found.  We can just quickly bury taproot if an issue is found.
10:50 < somethingsomethi> if it were up to me, I'd start with a shortish (say 1y) false period, if only to validate that the "miners are apathetic" hypothesis still holds
10:50 < roconnor> I don't think 1y counts as short.  Though some people do seem to think it is short.
10:51 < somethingsomethi> and then basically see how it goes. The community (both devs and users) won't just sit on their hands during that period, so alternative measures will come to be discussed organically
10:51 < instagibbs> The quesiton in my mind is how short can you go without forcing companies to do something they weren't going to do already(update their node)
10:51 < roconnor> And TBH, devs will sit on their hands when it comes to working on cross input signature aggregation
10:52 < roconnor> they may sit on their hands with respect to NOINPUT.
10:52 < instagibbs> Some people run old Core nodes that have address indexes/whatever. Yes, they can put up routing nodes, but stuff takes time.
10:52 < somethingsomethi> roconnor: and they wouldn't with a longer true period?
10:52 < instagibbs> getting a bip8(true) out the door means people will start building on top
10:52 < instagibbs> imo
10:53 < roconnor> somethingsomethi: I think with the knowledge that it will activate eventually they would start working on it.  Especially if there is a reasonable expecation of early forced activation.
10:53 < roconnor> early forced activation is all but impossible with a 1 year cycle.
10:54 < roconnor> it is just too short to both see the user deployment and to then take advantage of it.
10:54 < roconnor> (IMHO)
10:55 < somethingsomethi> slightly off-topic: For getting the ball rolling on development, wouldn't it be good to have some dedicated testnet for taproot?
10:55 < somethingsomethi> or is the thinking more that this shoudl come after the deployment process is agreed upon?
10:56 < roconnor> I'm not sure what the regtest status of taproot is.
10:56 < instagibbs> in the PR it's in regtest activated
10:56 < instagibbs> signet could be a good candidate
10:56 < instagibbs> kallewoof, interested? :)
10:58 < roconnor> somethingsomethi: based on past experience I think 1 year is both too short to do a BIP 91 like forced activation safely but long enough to seriously irritate the community if there is miner appathy. :D
10:59 < roconnor> a shorter time period would get it over with quicker, while a longer time period would give us better clearance for forced activation.
11:02 < somethingsomethi> well, if one year of apathy is going to irritate the community, do you really think waiting two or more years for forced activation will go over more smoothly?
11:03 < instagibbs> roconnor, forced by miner?
11:03 < instagibbs> oh nevermind misread
11:03 < roconnor> somethingsomethi: I think two or more years gives us better clearence for forced activation.
11:04 < somethingsomethi> Sure. I just mean the community aspect of it
11:04 < roconnor> oh yes I think it would.
11:04 < roconnor> I think much of the objections to BIP91 was due to the contrained time period.
11:05 < roconnor> I don't think there was much objection to the idea itself.
11:06 -!- _joerodgers [~joerodger@45.83.220.166] has quit [Remote host closed the connection]
11:06 -!- _joerodgers [~joerodger@45.83.220.166] has joined ##taproot-activation
11:07 < instagibbs> well, people can yell at miners to update
11:07 < instagibbs> directed energy
11:07 < roconnor> that was used with OP_CSV right?
11:07 < instagibbs> yep
11:07 < roconnor> I think BIP9 was working suspiciously poorly even back then.
11:13 < somethingsomethi> So, what is the current thinking on the 95% threshold? Would live be easier at 80%? There seems to be agreement that segwit was a much more involved change that warranted a high threshold, but could we go lower for taproot?
11:15 < somethingsomethi> (I just remembered there was something in the logs about that, sorry if that has been discussed before)
11:17 < gmaxwell> 95% had nothing to do with segwit. The specifics of the change don't matter much. It was chosen so that incompatible reorgs would be short.  It could be somewhat different but given hashpower distributions it's not likely to matter much if it's 95% of 90% or whatever.
11:23 -!- jeremyrubin [~jr@2601:645:c200:f539:cc9a:b428:d53:347b] has joined ##taproot-activation
11:24 < jeremyrubin> 10:52 < instagibbs> getting a bip8(true) out the door means people will start building on top
11:25 < somethingsomethi> gmaxwell: and is there like a minimum percentage of hash rate you'd like to implement the change "out of their own free will" before forcing it on the rest?
11:25 < jeremyrubin> BIP8 true is generally really good for *anyone* trying to build infra
11:26 < jeremyrubin> Without certainty it's chance of activating * chance of your thing working, and chance of your thing working is already generally small enough for most things.
11:27 < instagibbs> jeremyrubin, +1
11:27 < gmaxwell> somethingsomethi: hashrate is pretty meaningless for that purposes. 30% hashrate could just be one pool, or 1% hasrate could be a hundred thousand different miners.
11:28 < somethingsomethi> jeremyrubin: there is still the abort-softfork possibility though, so is it really that diffrent from bip8(false)?
11:28 < somethingsomethi> gmaxwell: Sure. I'm just trying to get a feel for what the parameter range might be
11:28 < jeremyrubin> E.g., segwit adoption in certain exchange wallets is poor because P(existing thing working) is high, and P(our implementation of new thing will not have a problem blocking release) is low. And that's mostly independent of P(bip8(false) ends up not activating), so it's those two P's multiplied.
11:29 < gmaxwell> jeremyrubin: we absolutely have seen before that businesses declined to work on implementing things until they were absolutely sure they would activate... part of this is that bip9 makes it remarkably easy to fud people into thinking that something won't activate.
11:29 < somethingsomethi> so bip8(false) is generally a bad idea then?
11:29 < jeremyrubin> Then you add in discounting probabilities for something that is seen as being far out (if it's 3.5 years, business value is close to 0 for many companies)
11:29 < benthecarman> somethingsomethi: going from bip(true) -> to bip(false) is much harder than going from bip8(false) -> bip8(true)
11:30 < jeremyrubin> benthecarman: I don't think it's harder
11:30 < jeremyrubin> it just requires a concrete reason
11:30 < roconnor> benthecarman: I think they are equally has hard.
11:30 < cato_> the question is should activation take people only building when sure about activation into account?
11:30 < roconnor> (unless you cound BIP91-like activation as bip8(false) -> bip8(true))
11:32 < roconnor> cato_: In as much as people raise the claim that "surely, the community (both devs and users) won't just sit on their hands during that period".
11:32 < jeremyrubin> I've actively had organizations decline to sponsor some of my work because changes to bitcoin are hard and uncertain, thus a bad allocation of resources, so it's not an abstract concern.
11:32 < cato_> I think it's not a good idea to let such externals influence the process
11:32 < cato_> after all, we've got segwit for years and adoption stalled
11:32 < roconnor> which for the record I think was a very legitmate question that somethingsomethi raised.
11:32 < jeremyrubin> cato_: via above they influence the process either way
11:32 < jeremyrubin> it's not just 'tight layers cleanly separated'
11:33 < jeremyrubin> the existence of infra and support on top helps provide evidence for both putting a change to a proposed activation
11:33 < jeremyrubin> and also makes it clear (as more integration work is done) if a change is safe
11:34 < jeremyrubin> We'd get higher quality results if people felt they could invest in supporting something ahead of activation
11:35 < cato_> that's definitively a positive effect
11:36 < cato_> I see a lot of different opinions here. maybe a list of proposals with the respective pros/cons would help?
11:37 < jeremyrubin> Also for a lot of orgs you have to bear in mind that they're general 2-3 years behind on deployment of new things. So if you have a process which can take 4 years, you look at seeing wide deployment something like 5-7 years later
11:38 < roconnor> I suppose I think that BIP8(false) with a 1y timeout simply won't activate but ultimately taproot will activate.  If I were not time sensitive then I would say, fine do it that way if it makes people happy.  But I am time sensitve for the infrastructure and other reasons.  So in that sense it matters.
11:39 < gmaxwell> I think for the most part opinion in here are pretty similar.  There is just a bit of people warming up to BIP8(true) though it seems people think both ways (that or BIP8(false) and phasing in a true, if needed) can work.
11:39 < roconnor> It's funny that I think BIP8(false)  1y is like a local minima.  I think shortening the timout makes it better.  I think lengthinging the timeout makes it better, and I think flipping false to true makes it better.
11:39 < jeremyrubin> I agree with that roconnor
11:39 < gmaxwell> roconnor: hah I have that impression too.
11:40 < jeremyrubin> this is sort of what I've been getting at with a minimum activation time
11:40 < cato_> gmaxwell: yeah, so the choice can probably be reduced to time-sensitive vs. ''being nice and offer an optional second round of discussion''
11:41 < jeremyrubin> bip8(false) 3 months, then 3 months, then bip8(true) 6 months is also relatively reasonable. But I think that BIP8(true) and cancel with a new deployment if there's a reason not to is probably fine
11:41 < gmaxwell> cato_: really the question there is how much uncertanty exists that this change is desirable by users. I think right now we have lots of reason to believe it is, and no reason to believe it isn't.
11:41 < somethingsomethi> ok, so everyone in development seems to prefer bip8(true) so that they can feel confident about their investments, but at the same time the required time period is too long for business cycles to actually make that investment. Quite the conundrum :-)
11:42 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
11:42 < gmaxwell> jeremyrubin: those time horizons are pretty short given how often people upgrade.
11:42 < jeremyrubin> gmaxwell: that's why the first one is false
11:42 < jeremyrubin> it's actually relatively equivalent to what can happen already under BIP8(true) 1 year
11:43 < roconnor> jeremyrubin: certainly better than BIP(false) 1y, but I think overlapping Bip91-style sctivation activations is strictly superiour.
11:43 < jeremyrubin> I suppose you could make it better as follows
11:43 < jeremyrubin> ah
11:43 < roconnor> (not certain yet, but I think so)
11:43 < jeremyrubin> was just going to say overlapping
11:43 < gmaxwell> jeremyrubin: I mean 6 months is kind of short for upgrades which happen without hashpower, unless you assume the very first release has that preprogrammed (and then it really is just a 1 year bip8(true))
11:43 < jeremyrubin> but I think that's basically a UASF
11:43 < instagibbs> so bip8(false)+bip8(true) xor bip8(true) xor bip8(false)+bip91-later are the concepts roconnor ?
11:44 < jeremyrubin> I think also irrespective of what the most fair process is, there is also value is a simple process. As a more complicated process just has more risk in user/deployment confusion
11:45 < roconnor> instagibbs: there are also some decrementing hashrate threshold proposals out there.  aj doesn't seem to be around at the moment to advocate for them.
11:45 < instagibbs> gmaxwell, I agree, I think it needs to be north of 6 months based on my experiences in industry
11:45 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
11:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 256 seconds]
11:45 < roconnor> Right I think we probably want 1 year for the BIP91-style layer of activation.
11:45 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
11:46 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined ##taproot-activation
11:46 < roconnor> although it could be shorter if we have already observed a lot of tarpoot excitement in the first depolyment.
11:46 < roconnor> but we'd want room for at least 1 year. which makes the bip8 layer a minimum of 2 year I feel.
11:47 < roconnor> instagibbs: I think there is merit to bip8(true)+bip91-later as well.
11:47 < instagibbs> to be clear, I'd prefer a nice long window between release + signaling start
11:47 < roconnor> instagibbs: as jeremyrubin would note, what you really want is a long window between release and activation.  Locking in early would be fine, and even a good thing.
11:48 < instagibbs> with no user uptake at all? disagree
11:48 < instagibbs> that said, sure there's a spectrum here
11:48 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has joined ##taproot-activation
11:49 < roconnor> If miners want to active soft forks amoung themselves there is little we can do to directly stop them.
11:49 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
11:49 < instagibbs> assuming they're not falsely signaling
11:49 < instagibbs> (no evidence to support that but hey)
11:49 < roconnor> an in the particular case of taproot, non-upgraded uses shouldn't use taproot.
11:50 < jeremyrubin> how about after the lock in, all coinbase outputs have to be v1 segwit :p
11:50 < jeremyrubin> skin in the game
11:50 < roconnor> Like I think someone else said, maybe miners already actived taproot and we just don't know it. :D
11:50 < instagibbs> roconnor, bro that's just temporary censorsihp ;)
11:51 < roconnor> right, I guess it doesn't count as activation if users aren't involved.
11:51 < jeremyrubin> The best way to UASF "mine this I dare you"
11:53 < jeremyrubin> FWIW I think a bunch of my argument can be made safer the earlier in a minor release preparation we announce BIP8 true is getting done
11:53 < jeremyrubin> E.g., if it's announced that the next release will be bip8 true today, the release is in 30 days, and then it's 30 days till start, that's much better than learning bip8 true is in the code on release day
11:54 < jeremyrubin> Especially as Release candidates and what not can be tested against internal infra
11:54 < roconnor> What is the next major minor release cycle expected dates?
11:55 < instagibbs> https://github.com/bitcoin/bitcoin/issues/18947
11:55 < instagibbs> every 6 months is target for major releases
11:55 < instagibbs> minor as needed
11:56 < jeremyrubin> TBH I think the "only minor releases contain SFs" is good technically, but not well understood enough by users for it to be valuable :(
11:57 < somethingsomethi> and how would this work, does the acivation procedure need to be defined before taproot itself gets merged, or could that go into the major release and then the rest gets done before the next minor?
11:57 < roconnor> 6 months is surprisingly narrow.  Where does a minor activation release come into play?  Just before a major release?  Half way?
11:57 < instagibbs> I always urge pretty blind updating of minor releases in case of cve lol
11:57 < jeremyrubin> yeah which is bad for SF stuff
11:57 < jeremyrubin> because you shouldn't take a SF thinking it's required
11:58 < jeremyrubin> but I guess bip8 true is required
11:58 < roconnor> even bip8(false) is required.
11:58 < jeremyrubin> roconnor: it gracefully tells you something activated and should update
11:58 < roconnor> the point is that you don't have to figure out your Sqllight updates at the same time.
11:58 < somethingsomethi> jeremyrubin: I mean by that logic you'd have to release two versions until the softfork is locked in
11:58 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined ##taproot-activation
11:59 < somethingsomethi> (in parallel I mean)
11:59 < jeremyrubin> so you don't need to update before bip8(false) activates
12:00 < roconnor> jeremyrubin: I think bip8(true) forces signaling which also tells you you should update.
12:00 < roconnor> and if bip8 doesn't do that it should be amended so that it does.
12:01 < jeremyrubin> i beleive it does
12:01 < jeremyrubin> note that you can adjust the signaling threshold because the second period requires true
12:01 < jeremyrubin> also makes a good argument for having 2 LOCKED_IN periods
12:01 < roconnor> so I think bip8(false) and bip8(true) have equal requirements to upgrade.
12:01 < roconnor> which I think is an argument in favour of bip8(true).
12:02 < jeremyrubin> is that if you lower the threshold, 2 LOCKED_IN periods guarantees that you have 2 weeks if you're on an older versionbits threshold to see that the change is happening and upgrade required
12:03 < roconnor> jeremyrubin: I'd have to look into it more, but that reasoning does seem sound.
12:03 < jeremyrubin> e.g. hits 50%, goes to LOCKED_IN. LOCKED_IN guarantees 100%. Fork activates
12:03 < jeremyrubin> v.s
12:03 < jeremyrubin> hits 50%, goes to LOCKED_IN. LOCKED_IN guarantees 100%. 2nd Locked in at 100%. Fork activates
12:03 < jeremyrubin> in the latter you can guarantee any client that understands versionbits 95% gets a warning
12:03 < roconnor> +1
12:04 < jeremyrubin> luke-jr: ^^^
12:04 < jeremyrubin> I think that also helps with instagibbs concern a bit too
12:04 < jeremyrubin> as you have 28 days from lock in to deploy if you need to make deploy changes after the upgrade locks in
12:05 < luke-jr> ?
12:05 < jeremyrubin> 2 locked in periods following the initial period which signals for a bit allows changing the threshold in the future to a lower value while still providing un-upgraded clients 2 weeks notice
12:08 -!- jnewbery [~john@164.90.178.190] has quit [Quit: Lost terminal]
12:08 < jeremyrubin> luke-jr: btw does BIP8 require that the last period does mandatory signaling? or does it just activate?
12:09 < jeremyrubin> That might be a stronger way of setting it because then it makes BIP8 true compatible with BIP8 false, and also sends signals to un-upgraded users
12:11 < luke-jr> jeremyrubin: LOCKED_IN is required to signal; FAILING checks if that is occurring
12:11 < luke-jr> the actual logic here might be reworked at some point to also handle changes to end time
12:11 < jeremyrubin> gotcha so at whatever height LOCKED_IN gets set
12:12 < jeremyrubin> and then following blocks will signal
12:12 -!- somethinsomethin [57bc93b7@p57bc93b7.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
12:16 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
12:25 < jeremyrubin> it probably makes sense to add a letter to releases or something, such that we have a letter version which is required to fully validate.
12:26 < jeremyrubin> e.g., 20.01.B and 19.12.B are required to fully validate the B network series
12:26 < jeremyrubin> whereas it's clear that 20.0.A is not B compatible
12:27 < roconnor> How about we use major version number. :D :D :D
12:30 < jeremyrubin> last time this was debated
12:30 < jeremyrubin> https://github.com/bitcoin/bitcoin/issues/9653
12:31 < instagibbs> "Finally, BitCoin is 1.0!"
12:32 < jeremyrubin> Honestly we can't go to 1.0
12:32 < jeremyrubin> people will be so confused
12:33 < roconnor> we should just go to verion 1.0 as a minor release for taproot activation.
12:33 < roconnor> That would vastly encourage upgrading.
12:35 < jeremyrubin> it's sort of a local minimum where everyone wants versioning to be better in one way or another and instead we're stuck with this crap...
12:35 < instagibbs> jeremyrubin, fine, 1.1
12:36 < jeremyrubin> you still run into the semantic issue with backports
12:36 < roconnor> Even the miners might be convinced:  Oh crap, bitcoin Core is at 1.0.  Sounds important.
12:37 < jeremyrubin> where 1.1, 1.2, 2.0, 2.1, 2.2 can all exist and it's not clear which ones are both not going to make breaking node changes and be able to validate new soft rules
12:37 < jeremyrubin> Hence wanting 1.1.A and 1.1.B and 1.2.B
12:38 < jeremyrubin> because then 2.0.B and 2.1.B and 2.2.B are also clearly maj upgrades, but the B tells you that all of 2.0 is compatible
12:38 < jeremyrubin> with B, but not required if you need to stay on 1 but need B validation
12:41 < jeremyrubin> kind of annoying but the only alternative that gives users an easy to understand thing would be to call them by longnames
12:41 < jeremyrubin> Bitcoin 1.1 now with 100% more Taproot
12:43 < jeremyrubin> you can eventually drop the compat notes after a major release or two or something.
12:47 -!- joerodgers [~joerodger@45.83.220.166] has joined ##taproot-activation
12:50 -!- _joerodgers [~joerodger@45.83.220.166] has quit [Ping timeout: 240 seconds]
12:58 < instagibbs> Bitcoin Serenity
12:59  * instagibbs ducks
13:13 < gmaxwell> 18:56 < jeremyrubin> TBH I think the "only minor releases contain SFs" is good technically, but not well understood enough by users for it to be valuable :(
13:13 < gmaxwell> users don't need to understand it for it to help.
13:14 < gmaxwell> The result of doing that just mean that when someone hears "You need to update for this consensus change" and they look to go do it, they're magically less likely to run into "the required upgrade breaks my stuff".
13:14 < gmaxwell> Thats true even if they have no idea why it's true.
13:15 < gmaxwell> (this happens because stuff, perhaps even their own stuff, has had more time to upgrade to be compatible with the new major version)
13:16 < gmaxwell> I haven't seen evidence of people going "it's a minor update, I don't need to apply it" -- because those versions are often released for serious bugfixes.
13:17 < gmaxwell> you also have the factor of some place that by policy will not run major.0 at all because they expect it to be more buggy based on expirence with other software, which activating in a minor addreses.
13:18 < gmaxwell> And merge in major/activate-in-minor also helps derisk the merge.  E.g. if merging a big change in major breaks stuff, at leat downgrading works because the consensus change hasn't been activated.
13:18 -!- benthecarman_ [~benthecar@185.123.143.206] has joined ##taproot-activation
13:18 < gmaxwell> If the activation was at the same time as the merge, downgrading is less of an option for dealing with merge induced collateral damage.
13:19 < gmaxwell> So, e.g. taproots changes include changes to fix quadratic behavior in if/else.  But what if those changes accidentally caused quadratic memory usage.  If this was noticed post release but preactivation, downgrading would be a workaround.
13:22 -!- benthecarman [~benthecar@185.123.143.222] has quit [Ping timeout: 246 seconds]
13:25 < jeremyrubin> [7/16/20 13:16] <gmaxwell> I haven't seen evidence of people going "it's a minor update, I don't need to apply it" -- because those versions are often released for serious bugfixes.
13:25 < jeremyrubin> I haven't seen evidence either way, and I would by default presume inaction
13:27 < gmaxwell> that isn't supported by upgrade patterns that we see. new major versions are adopted more slowly than new minor verions.
13:28 < jeremyrubin> Are the upgrade patterns documented/recorded from somewhere? Again, I haven't seen them at all, so just speculating.
13:32 < gmaxwell> jeremyrubin: https://bitnodes.io/dashboard/?days=730 second graph, a number of other parties do too.
13:32 < gmaxwell> many of them don't filter out the 0.16.x state sponsored chinese sybils, unfortunately.
13:38 < jeremyrubin> data is kinda hard to parse but I'm not sure i see the trend mentioned
13:38 < jeremyrubin> What I do see is that a bunch of new nodes come online with a new point release
13:40 < jeremyrubin> And that effect is even more pronounced with a new major release it looks even more pronounced
13:40 < jeremyrubin> (I find stacked charts really hard to read though so it may just be me)
13:43 < jeremyrubin> Maybe an explanation for more nodes coming on is people continue running the old one on the network?
13:48 < gmaxwell> hm? the total doesn't really go up much with new releases, though to the extent that it does I would assume its because people hear about a new release and restart a node that has gone offline.
13:55 < jeremyrubin> Ah I think it depends what you're filtering by you can see different trends.
13:56 < jeremyrubin> if you have all the boxes ticked in the graph, you're looking in a bigger pool where the totals are flatter
13:57 < jeremyrubin> But if you're just looking at 0.20, 0.19.1, and 0.19.0.1 you see something else
13:59 < jeremyrubin> but if you look total you do, for example, see 20% get reached in 1 month for 0.20 and only 10% in 1 month of 0.19.1
14:00 < jeremyrubin> So that does show faster uptake on a major version after release?
14:01 < gmaxwell> there isn't a 0.20.1 yet so you can't really compare 0.20.
14:01 < gmaxwell> Some majors have had faster adoption than others e.g. based on delays/features/etc.
14:01 < gmaxwell> this particular site doesn't really go back far enough anymore.
14:02 < gmaxwell> :-/
14:02 < jeremyrubin> I would agree. 0.19.01 isn't useful
14:02 < jeremyrubin> because the immediate re-release may have scared people
14:03 < jeremyrubin> Yeah if you do have data that goes further back interested to see it to be able to analyze similarly, but to the credit of the recent data, it is what happened most recently.
14:03 < jeremyrubin> Which is that within the last few months a minor update got to 10% in a month and a major 20% in a month
14:04 < jeremyrubin> So "presumably" were we to do another minor and then another major, we would see similar numbers.
14:04 < jeremyrubin> But I also agree it's different when a major/minor contains a SF, so we need data back to 0.13
14:04 < jeremyrubin> And that's also messy because of the forkwars crap
14:05 < jeremyrubin> It's also stale data because it was from years ago, so user trends have likely changed
14:06 < gmaxwell> what data we saw before was that non .0 tended to have a faster update than their parent versions. You see it there for 0.19.0.1 there vs 0.19... and this had been pretty consistent.  major vs major has always been pretty variable.
14:06 < gmaxwell> It's also not shocking because e.g. we know some places have a stated policy against running any .0 at all.
14:07 < gmaxwell> It's also not shocking because .0's frequently make breaking interface changes.
14:07 < jeremyrubin> I think you've lost the thread
14:07 < jeremyrubin> The point is that a minor version is a poor communication
14:07 < jeremyrubin> I'm not arguing a technical change
14:08 < jeremyrubin> it's purely a branding change
14:08 < gmaxwell> Better to have lost it than never had it in the first place?
14:08 < jeremyrubin> it doesn't matter if minor uptake is better than major. It matters if any amount aren't upgrading minor updates because it's crappy branding
14:09 < gmaxwell> Yet nothing I've ever seen (including that graph) supports that theory.
14:10 < jeremyrubin> I don't think the graphs here really support much of anything in either direction . I'd be interested to see someone actually analyze this or talk to users.
14:10 < jeremyrubin> actually analyze --> writeup on details and interpretation
14:11 < jeremyrubin> I'm sure we've both analyzed it and drawn different conclusions on the behavior that lead to the numbers seen
14:11 < gmaxwell> It's a fine /theory/ that people might not upgrade diligently to minor releases because they're 'minor', but we're not stuck navel gazing.  If there were a substantial effect there, it should be apparent.
14:11 < jeremyrubin> I'm not sure node count is it though; isn't it possible that the users we want to upgrade infrequently run their nodes?
14:12 < gmaxwell> And you're left with the fact that a user can pretty much always simply upgrade to a minor release, while a major release frequently breaks dependant software.
14:12 < jeremyrubin> Sure
14:12 < jeremyrubin> Again it's not a technical thing
14:13 < jeremyrubin> it's merely that major upgrades sound required, minor upgrades do not
14:13 < gmaxwell> Clearly, it's mostly about laying your thumb and imposing your opinion against existing practices.
14:13 < jeremyrubin> I'm not sure what that means
14:16 < gmaxwell> Do you agree with the point that I've made that sometime users _cannot_ upgrade to a new major version because it takes time for their dependant software (sometimes in house, sometimes third party) to get updated, and that this issue is largely non-existant for minor versions (except in-so-far as they couldn't also update for the parent major version)?
14:17 < jeremyrubin> yes this is completely uncontroversial
14:18 < gmaxwell> On that basis, even if minor versions were updated more slowly because branding-- something which doesn't appear supported from the data-- I argue its still better to activate in minor versions, and that this should be completely uncontroversial because it's important to maximize people's ability to do so.
14:18 < gmaxwell> Any consensus activation will come with an enormous amount of press, people will largely know they should upgrade... what remains is a question about how costly it is for them to do it.
14:19 < gmaxwell> Moreover, there is an existing, time tested practice which hasn't appeared to be a source of problems itself.  Changing it would be ill-advised without a clear justification.
14:20 < jeremyrubin> People have been dissatisfied with out versioning scheme for years! I've had to explain it in every conversation I've ever had about it, even when talking to well read people.
14:22 < gmaxwell> I have litterally never had that expirence and I know of at least two major exchanges that have a hard policy against running .0 versions, and I have encountered well over a hundred times when users had upgrading problems due to api changes (which also happens in minor versions though almot entirely because they also didn't upgrade major versions)
14:22 -!- brg444 [uid207215@gateway/web/irccloud.com/x-evwsguqdkbxexhqp] has quit [Quit: Connection closed for inactivity]
14:27 < jeremyrubin> An example is moneyball recently asked in core-dev if we could aim to do Taproot in v0.21
14:28 < jeremyrubin> And sipa had to clarify that isn't the usual release process, that changes go in minor versions and don't follow major release timelines
14:29 < jeremyrubin> now I get that moneyball isn't represented of say, all Bitcoin users. But I think he's pretty well read on it and if it's confusing for him than that's a problem IMO.
14:35 < gmaxwell> Not knowing something isn't itself a problem. Lots of things don't work how you might gues without it being a problem. :)
14:37 -!- brg444 [uid207215@gateway/web/irccloud.com/x-rryeyqbhjsquhmkx] has joined ##taproot-activation
14:37 < jeremyrubin> fwiw my twitter poll is currently leading with 42% of respondents reporting that they install all major releases and sometimes minor releases, and losing with 5.3% installing all minor and sometimes major
14:37 < jeremyrubin> all major and all minor updates is 34%
14:37 < gmaxwell> that quetion sounds confusing, also: it's *directly* contradicted by the data.
14:45 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has joined ##taproot-activation
14:46 < somethingsomethi> branding aside, we can probably all agree that not bundling a softfork activation with random unrelated api cahnges is a good idea
14:47 < somethingsomethi> in which case jeremyrubin's suggestion would amount to having two types of major releases: Those with breaking changes and those with softforks, which imho only makes the versioning scheme more confusing
14:48 < jeremyrubin> I think that you want a distinction between soft forks, security patches & small fixes, and breaking changes.
14:49 < somethingsomethi> I mean you can try to express all sorts of things with the version numbers, but at some point the users will have to read the release notes :-)
14:49 -!- gmaxwell [~procyonid@wikimedia/KatWalsh/x-0001] has left ##taproot-activation ["this channel is a waste of time"]
14:51 < jeremyrubin> ¯\_(ツ)_/¯, sure, fuck me for caring if users understand what software they should be running to match their intent.
14:53 -!- benthecarman__ [~benthecar@185.123.143.222] has joined ##taproot-activation
14:56 -!- benthecarman_ [~benthecar@185.123.143.206] has quit [Ping timeout: 240 seconds]
15:00 < somethingsomethi> I dunno. Coming up with a new versioning scheme seems like a bikeshedding blackhole, and this whole activation discussion is convoluted enough already. Maybe save it for the next time?
15:01 < somethingsomethi> (could also be interesting to see how that versioning logic would work if there are ever multiple softforks in parallel. But offtopic here I gues)
15:02 < instagibbs> yeah i think this is topic drift?
15:11 < roconnor> Sorry, I was joking about the bitcoin 1.0 taproot think.
15:11 < roconnor> *thing
15:16 -!- somethingsomethi [5dc33985@p5dc33985.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
16:16 -!- Netsplit *.net <-> *.split quits: meshcollider, instagibbs
16:16 -!- Netsplit *.net <-> *.split quits: takinbo, wraithm, waxwing
16:20 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
16:21 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
16:22 -!- wraithm [~wraithm@unaffiliated/wraithm] has joined ##taproot-activation
16:22 -!- takinbo [~takinbo@unaffiliated/takinbo] has joined ##taproot-activation
16:22 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined ##taproot-activation
16:22 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined ##taproot-activation
16:22 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-otyqznegmsqkmiol] has joined ##taproot-activation
18:36 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined ##taproot-activation
18:36 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
18:51 < zmnscpxj__> Would just like to point out to those saying "my opinion does not matter", but if you are here, you are interested in future of Bitcoin, and probably have a non-negligible stake in its success, so your opinion *does* matter
18:52 < zmnscpxj__> anyway, let us return to our bikeshedding of activation logic
19:01 -!- benthecarman__ [~benthecar@185.123.143.222] has quit [Remote host closed the connection]
19:04 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection]
19:04 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined ##taproot-activation
20:42 -!- brg444 [uid207215@gateway/web/irccloud.com/x-rryeyqbhjsquhmkx] has quit [Quit: Connection closed for inactivity]
20:57 < aj> so we can always soft fork out taproot/etc by saying "you can never spend to a taproot address"; but if we prepared for it in advance, we could also say something like "taproot will activate if we have 95% hashpower signalling, or after 2 years, provided we don't have the last two retarget periods of that 2 years having every block include a non-zero/non-dust "OP_PUSH "NO_TAPROOT" OP_DROP OP_TRUE"
20:57 < aj> output in the coinbase or something, so that there's no permanent cost to having to fail the soft-fork. (could do it via versionbits or similar too if we didn't want a definite cost/risk for miners)
20:59 < zmnscpxj__> do we really think there is a reason to abort Taproot? Would you estimate it at better than 1-out-of-32 chance that we will abort?
21:00 < zmnscpxj__> because we can still use SegWit v1, with a OP_1 <33 bytes>
21:00 < zmnscpxj__> so the cost of removing OP_1 <32 bytes> is the extra byte we have to add
21:02 < zmnscpxj__> (and we still have 14 other SegWit versions anyway, "14 versions should be enough for everybody" -- Bill Gates)
21:02 < aj> roconnor: "softfork to bury taproot" -- we call it "buried activation" when we say "this is always active after height X, no matter what signalling there might appear to be if the chain gets massively reorged", which i'm pretty sure is not what you meant there
21:03 < zmnscpxj__> better term maybe "softfork to abort taproot"?
21:03 < roconnor> no. I'll pick a new term
21:03 < jeremyrubin> zmnscpxj__: also good to point out that taproot can have a few different things go wrong and still be OK. Like you can soft-fork reject just the leaf version currently used
21:03 < roconnor> flush taproot. :P
21:03 < zmnscpxj__> huh, yeah
21:04 < jeremyrubin> that would enable just native schnorr, and then another soft fork down the line could add back in a new leaf version
21:04 < zmnscpxj__> we do have leaf version
21:04 < jeremyrubin> so you could "pick and choose"
21:04 < jeremyrubin> There's also op-successx
21:04 < jeremyrubin> So if you don't need to burn the leaf version
21:04 < zmnscpxj__> so that is a sub-option as well, where there is a problem in pay-to-contract but no problems with Schnorr
21:04 < jeremyrubin> you could just mandate the the picked taproot leaf must always start with success1
21:05 < roconnor> Right throwing out all of taproot is a worst case scenario.  Less drastic action is almost certainly going to be available depending on the nature of the hypothetical problem.
21:05 < jeremyrubin> so then you can completely redefine it if there were some other problem and you don't want to discard a whole leaf version
21:05 < zmnscpxj__> hmmm so this changes bip-taproot?
21:06 < zmnscpxj__> bip-taproot now requires op_sucess1 in every script?
21:06 < jeremyrubin> No it doesn't change the BIP so to speak?
21:06 < jeremyrubin> Only if you didn't want to burn the whole leaf version
21:06 < jeremyrubin> but just un-opsuccess prefixed types
21:06 < zmnscpxj__> Well, it seems unlikely that we will get a problem with SCRIPT interpretation and not a problem with the pay-to-contract+MAST constuction
21:07 < zmnscpxj__> I think
21:08 < jeremyrubin> In that case, I think you can just become native schnorr, but only if the problem is discovered before activation
21:08 < jeremyrubin> After activation people may have already set up
21:08 < jeremyrubin> So you'd probably need a hardfork to safely fix it, if possible. Or everyone using it loses funds'
21:09 < aj> if we were going to do a "x month lockinontimeout=false; if it fails; do something later" then x=3 or 6 months might be feasible; 3 was long enough for the uncontroversial CSV bips to activate via bip9, and 6 months was longer than it took to go from bip141 isn't working let's talk about UASF and end up with bip148 and bip91 pretty much written
21:10 < jeremyrubin> aj: this was discussed up a bit higher!
21:10 < jeremyrubin> roconnor: noted that overlapping BIP8's is superior
21:11 < jeremyrubin> just do a 1 year BIP8 default false, and then after 6 months add a default true
21:11 < zmnscpxj__> overlapping BIP8s as in: BIP8(false) for 6 months, BIP8(false) for 42 months?
21:11 < zmnscpxj__> ok
21:12 < jeremyrubin> reject 42 months
21:12 < zmnscpxj__> >.<
21:12 < zmnscpxj__> so BIP8(false) 12 months, BIP8(true) 18 months?
21:12 < zmnscpxj__> at the same time?
21:12 < jeremyrubin> I think BIP8false 3 months, BIP8 true 1 year
21:13 < jeremyrubin> sorry if I confused above
21:13 < jeremyrubin> as aj notes above, 3 months was sufficient for CSV
21:22 < aj> zmnscpxj__: i guess i think there's a better than 1/2 chance we reuse whatever we use for taproot for subsequent soft-forks and better than a 1/8 chance that one of those needs aborting after getting activation parameters
21:23 < aj> roconnor: also, taproots grow when you bury them -- "uproot taproot" would be thematically appropriate?
21:23 < zmnscpxj__> salt the earth?
21:24 < aj> soft-forking out just the leaf version risks burning funds -- if they were spent to a tapscript with a NUMS point for the internal key eg
21:24 < zmnscpxj__> presumably the uprooting is done before activation in the first place
21:24 < zmnscpxj__> so sending to a taproot address would not be safe anyway
21:25 < zmnscpxj__> is my understanding
21:26 < aj> yes, uprooting would imply you could replace it, fair point
21:30 < zmnscpxj__> aj: "fair point" refers to "salt the earth"?
21:31 < aj> yeah
21:36 < jeremyrubin> aj yep, hence only if discovered problem to burn leaf before activation
21:37 < aj> jeremyrubin: that sentence needs more verbs
21:38 < jeremyrubin> sorry
21:38 < jeremyrubin> Where you earlier said:
21:38 < jeremyrubin> [7/16/20 21:24] <aj> soft-forking out just the leaf version risks burning funds -- if they were spent to a tapscript with a NUMS point for the internal key eg
21:38 < jeremyrubin> it has been pointed out above that burning just leaf version must be done prior to activation
21:39 < jeremyrubin> [7/16/20 21:08] <jeremyrubin> In that case, I think you can just become native schnorr, but only if the problem is discovered before activation
21:39 < jeremyrubin> [7/16/20 21:08] <jeremyrubin> After activation people may have already set up
21:39 < aj> even then, someone could have shared a pre-signed transaction spending to a to-be-burnt address with nlocktime set to ensure it can't be published while the output is still anyone can spend
21:40 < zmnscpxj__> then we should warn users not to do this? This is still arguably a use of Taproot before activation
21:40 < jeremyrubin> I put that sort of concern on the level of "miners can censor you for arbitrary reasons", but sure, a theoretical user knowing with certainty taproot activates could do this.
21:41 < jeremyrubin> zmnscpxj__: yeah. something something people in America don't wear facemasks something my coins my choice something
21:41 < zmnscpxj__> "not your mask, not your health"
21:42 < aj> zmnscpxj__: setting lockinontimeout=true seems to me to be trying to assure them that it is safe to assume it will work; if you don't want to do that, don't set lockinontimeout=true
21:42 < zmnscpxj__> ah, I suppose that is a point
21:42 < aj> zmnscpxj__: if we soft fork out spends to all taproot addresses, that doesn't burn funds, so isn't a problem in the same way
21:42 < jeremyrubin> aj: I think the safe to assume is more for deploying engineering resources rather that using
21:43 < jeremyrubin> E.g., if the LN folks want to integrate taproot
21:43 < aj> (i mean, if they pre-signed a tx, then threw away the signing key it could be, but that's more obscure at least)
21:43 < jeremyrubin> witha set true, it's a good business decision to plan around that and be ready
21:43 < jeremyrubin> with set false, you'd wait till it's active to spend money on it
21:43 < aj> jeremyrubin: likely the engineering time to build taproot into LN which is then going to be wasted if it gets soft-forked out is more than you'd lose in burning random txs...
21:45 < aj> also, spending engineering time making new soft-forks work seems like a reason *to* activate the new features (and/or to be confident the new features are sane, useful, etc), so you want that done before the decision is certain anyway, if that's possible
21:47 < jeremyrubin> I'm taking that approach with CTV, as I think that's how forks should be motivated. But it's difficult to fund that kind of work.
21:48 < jeremyrubin> It's also not clear to me if it's wasted engineering effort if it does get soft forked out -- most likely something very similar gets added back (e.g., fixing a bug) and shipped
21:49 < jeremyrubin> you can think of BIP8 lockinontimeout's parameter as being a probability value
21:49 < jeremyrubin> but we only get one bit to set
21:54 < jeremyrubin> anyways to finish that thought... I think that the "setness" for taproot should be < 1/32 according to zmnscpxj__'s logic
21:54 < jeremyrubin> err 1-1/32
21:55 < zmnscpxj__> something like that
21:55 < jeremyrubin> So if we're saying it's a 95% chance that taproot activates, then BIP8 true is a closer estimation of what we think the probability is there's not a bug in it
21:56 < aj> you don't want lockinontimeout to be a probability value (at least one that's not arbitrarily close to 0 or 1) because if you do, that means there's non-zero odds the economy will get disrupted with some nodes following a non-most-work chain, which is then vulnerable to attack
21:56 < aj> (1/32 is 3.1%)
21:59 < jeremyrubin> (that's just the threshold for probabability where burning the byte is worth it, so taproot has to be above 1-1/32 certainty to take such approaches)
22:00 < jeremyrubin> Anyhow, the point is that if you set lockinontimeout false, you're saying it's unlikely to end up activated, and you run the risk of people getting upset and UASF'ing and causing a big politiking. If you set it true, you run the risk of having to soft fork it out if a bug is found.
22:01 < jeremyrubin> That's why I'm saying it's like a probability, you end up picking true/false based on what you think engendeds more negative EV to Bitcoin
22:02 < jeremyrubin> My sense is that BIP8 true is less harmful, but it's valid to think that BIP8 false is less harmful I guess.
22:03 < jeremyrubin> I do think it makes sense to think about them as probabilities we can only approximate as 0 or 1 though as it makes looking at the whole thing as EV optimizing make sense
22:03 < jeremyrubin> thanks zmnscpxj__for that insight
22:03 < zmnscpxj__> haha, you are welcome
22:10 < aj> lockinontimeout=false is saying either "there is some plausible chance it shouldn't be activated" or "the chaos that might be caused by forcing activation at that time if miners have not all upgraded by then isn't worth it"
22:12 < aj> i don't think it's great for devs to try to say "there is no plausible chance it shouldn't be activated" when merging activation params; and am not really convinced the "we've got some emergency plan where we can deal with it it happening" is enough to change from "implausible" to "unlikely"
22:13 < aj> the chaos one seems a really hard call. chaos for people who aren't paying attention is what sucks about the economy having to pay deep attention to central banks changing rates and the like; but delaying every change for years sucks too
22:31 < aj> zmnscpxj__: "pedantic" not "pedanty" </pedantry>
22:39 < jeremyrubin> aj: actually I think pedanty can be correct. A pedant is *person* who is pedantic. 2 possibilities: 1) A pedanty has a definition as a group of pedants. So the note is for the pedantic people, rather than being pedantic itself.  2) zmnscpxj__ is describing himself as being a pedant, but only a little bit. The -y is like the y in "nit-picky".
22:40  * zmnscpxj__ receives passive nerdsnipe achievement
22:40 < jeremyrubin> zmnscpxj__: what one was your intent
22:41 < zmnscpxj__> (1)
22:41 < zmnscpxj__> I think
22:44 < aj> (2) mezzopedantic, maybe
23:03 < jeremyrubin> i just want to know how gigapedantic is pronounced
23:13 < aj> gidja seems a good compromise
--- Log closed Fri Jul 17 00:00:22 2020