--- Log opened Mon May 03 00:00:45 2021
00:25 -!- b10c [~b10c@static.55.136.76.144.clients.your-server.de] has joined ##taproot-activation
02:47 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
02:47 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
02:53 -!- TechMiX [~techtux@188.126.217.46] has joined ##taproot-activation
02:53 < TechMiX> Hi, how did we decide on the 90 percent threshold for this upgrade?, why was it 95 percent for segwit? Why did we lowered that threshold?
02:57 < darosior> TechMiX: Hi, see this channel logs. There were extensive discussions about this.
03:16 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined ##taproot-activation
03:16 < riclas> hi. if there are 2016 blocks signaling for taproot before 11 august there is no "early activation" i suppose?
03:26 -!- nathanael [~nathanael@unaffiliated/nathanael] has joined ##taproot-activation
03:49 < mips> riclas, it needs 1815 blocks in a single difficulty epoch.
03:52 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
03:53 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined ##taproot-activation
03:59 < TechMiX> darosior: Okay. Thank you. I found the answer to my questions except that why was it 95 percent for segwit?
04:10 -!- Alexandre_Chery [94668a0b@148.102.138.11] has joined ##taproot-activation
04:12 -!- Alexandre_Chery [94668a0b@148.102.138.11] has quit [Client Quit]
04:31 <@aj> TechMiX: segwit was 95% because bip9 recommended 95%, bip9 recommended 95% because earlier IsSuperMajority soft-forks used 950/1000 blocks, they used 95% because (a) prior upgrades with a 55% threshold had caused problems, and (b) since every block would have to advertise the higher nVersion after the fork activated, it pretty much guaranteed 5% of hashrate would get orphaned upon activation, so
04:31 <@aj> you want that to be really small
04:32 <@aj> TechMiX: it's lowered here to 90% because there didn't seem to be any reason to think 90% created any problems (there's a higher chance of eg coinbase accepting invalid txs after 3 confirmations with lower percentages like 80% or 85% though they're still small) and because allowing 10% of hashpower to delay rather than just 5% seemed more plausible. 90% is roughly how much hashpower indicated
04:32 <@aj> they'd signal on bitcoinactivation.com as well.
04:49 < TechMiX> Thank you aj :) it's clarified for me now.     I guess you meant taprootactivation.com
04:50 <@aj> err yeah
05:02 -!- r1clas [~riclas@77.7.37.188.rev.vodafone.pt] has joined ##taproot-activation
05:03 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]
05:45 <@michaelfolkson> TechMiX: Also https://bitcoin.stackexchange.com/questions/52326/what-are-the-risks-of-a-lower-than-95-activation-threshold-for-soft-forks-part
05:48 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds]
06:10 < TechMiX> michaelfolkson: thank you michael.
06:10 < TechMiX> I know this is not the best place to ask this, As far as I understood, "cross input signature aggregation" is different from "multi-party signature aggregation". With taproot activated, we can do the later but not the former. Correct? I mean we can have addresses that are in control of many people, but they appear as normal addresses and spending from those addresses won't leak that information.
06:12 <@michaelfolkson> TechMiX: We can do key aggregation on a particular input post Taproot (e.g. MuSig). So say a 5-of-5 multisig where only one key and one signature goes onchain rather than 5 keys and 5 signatures
06:13 <@michaelfolkson> TechMix: What we can't do with Taproot is aggregate signatures across multiple inputs. Maybe in a future soft fork
06:14 <@michaelfolkson> https://bitcoin.stackexchange.com/questions/100216/what-makes-cross-input-signature-aggregation-complicated-to-implement
06:14 -!- cec [aedb0b09@9.sub-174-219-11.myvzw.com] has joined ##taproot-activation
06:21 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
06:21 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Remote host closed the connection]
06:21 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined ##taproot-activation
06:21 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
06:53 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
06:55 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
06:56 -!- cec [aedb0b09@9.sub-174-219-11.myvzw.com] has quit [Quit: Connection closed]
07:24 -!- proofofkeags [~proofofke@97-118-239-55.hlrn.qwest.net] has joined ##taproot-activation
07:30 -!- cec [aedb0b09@9.sub-174-219-11.myvzw.com] has joined ##taproot-activation
07:31 -!- cec [aedb0b09@9.sub-174-219-11.myvzw.com] has quit [Client Quit]
07:47 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined ##taproot-activation
07:59 -!- proofofkeags [~proofofke@97-118-239-55.hlrn.qwest.net] has quit [Ping timeout: 240 seconds]
08:07 < TechMiX> michaelfolkson: thank you very mich michael :) that cross input sig would be very cool to have. I didn't fully understand why we are not going to have it for this upgrade
08:15 <@michaelfolkson> murch: Luke doesn't like LOT=false. Other people don't like LOT=true. So if you are going to use the logic that neither LOT=true or LOT=false should be used then we should never do miner signaling again
08:16 <@michaelfolkson> murch: Speedy Trial is LOT=false, there is no forced signaling with Speedy Trial
08:17 <@michaelfolkson> You either lockinontimeout or you don't. If you don't want either then just do flag days every time
08:19 -!- valwal [~valwal@96.224.58.144] has joined ##taproot-activation
08:20 <@michaelfolkson> Where I think BIP 8 really excels is when there are parallel deployments, say Core with LOT=false and an alternative release with LOT=true. They are entirely compatible until the last 2 weeks where it depends what the economic majority is running
08:21 <@michaelfolkson> This is much better than say Core releasing a flag day and an alternative release with miner signaling. These are not compatible whatsoever.
08:23 <@michaelfolkson> Re: https://twitter.com/murchandamus/status/1388990419623628801?s=20
08:24 <@michaelfolkson> By attempting to claim BIP 8 should never be used you are effectively saying that Core should always release flag days and there will never be an alternative release with different activation mechanism, activation params to Core
08:25 <@michaelfolkson> Both of these make no sense to me whatsoever
08:25 < AaronvanW> michaelfolkson: they could still be compatible if miners signal.
08:25 < AaronvanW> But I agree that parallel deployment would be a much cleaner and better compatibility.
08:25 <@michaelfolkson> AaronvanW: There is no miner signaling with a flag day
08:26 < AaronvanW> michaelfolkson: doesn't matter if miners enforce the taproot rules.
08:26 < AaronvanW> flag day nodes wouldn't *mind* the signaling.
08:27 <@michaelfolkson> AaronvanW: The whole point is coordination on when they start enforcing Taproot rules
08:27 < AaronvanW> "But I agree that parallel deployment would be a much cleaner and better compatibility."
08:28 <@michaelfolkson> AaronvanW: I get the possibility that somehow a flag day *could* end up being compatible with miner signaling by chance. But the majority of the time they would not be compatible
08:28 < AaronvanW> WHy do you think that?
08:28 <@michaelfolkson> A flag day activates on say June 1st 2023
08:29 < AaronvanW> as long as miners enforce the rule until then (and after), compatible.
08:29 < AaronvanW> by compatible, I mean no chain split.
08:29 <@michaelfolkson> If miners meet signaling threshold in the months before June 2023 then they will enforce Taproot rules before the flag day
08:30 <@michaelfolkson> So you will have some miners enforcing Taproot rules before June 2023 and other miners waiting until June 2023 to enforce Taproot rules
08:30 < AaronvanW> michaelfolkon: if they only meet the signaling threshold in 2023, they didn't comply with the UASF.
08:31 -!- nathanael [~nathanael@unaffiliated/nathanael] has quit [Ping timeout: 276 seconds]
08:31 < AaronvanW> when I say "miners" I mean "a majority of miners".
08:32 < AaronvanW> If miners comply with the UASF, there's no chain split. If eg. Core has a flag day later, it just means eg Core would start enforcing the Taproot rules later. But there shouldn't be a chain split in the mean time.
08:33 -!- proofofkeags [~proofofke@205.209.28.54] has joined ##taproot-activation
08:33 <@michaelfolkson> AaronvanW: You're not responding to what I've said
08:34 <@michaelfolkson> AaronvanW: I'm talking about miner signaling meeting a threshold before the flag day set in Core
08:35 < AaronvanW> you mean after october 2022, but before flag day 2023, right?
08:35 <@michaelfolkson> murch says don't use BIP 8 because some people don't like LOT=true and some people don't like LOT=false
08:36 <@michaelfolkson> Ok... well that means you are using a flag day
08:36 < AaronvanW> or nothing
08:36 < AaronvanW> but go on
08:36 <@michaelfolkson> A flag day (unless you are extremely lucky) is not compatible with miner signaling (LOT=true or LOT=false)
08:36 < AaronvanW> can you define "compatible" for me
08:37 < AaronvanW> we might be using the same word for different things.
08:37 <@michaelfolkson> Compatible = will activate at the same time, will start enforcing soft fork rules at the same time
08:37 < AaronvanW> ok then I agree
08:37 <@michaelfolkson> BIP 8(LOT=true) and BIP 8(LOT=false) are compatible until the final two weeks
08:38 < AaronvanW> I am/was defining compatible as "will follow the same chain".
08:38 <@michaelfolkson> BIP 8(LOT=true or LOT=false) is not compatible with a flag day from beginning to end (unless you are lucky)
08:38 < AaronvanW> under your definition of compatible, yes
08:40 <@michaelfolkson> A flag day would be Core telling miners and users exactly when to start enforcing soft fork rules
08:41 < AaronvanW> but you agree that a mix of LOT=true nodes and flag day nodes could still end up following the same chain, right?
08:41 <@michaelfolkson> If you are lucky. If somehow miners don't meet signaling threshold until 2 weeks before the flag day and then they do meet the threshold. Would be quite the dance
08:42 < AaronvanW> No not just if you're lucky. Simply if miners comply with the UASF.
08:43 <@michaelfolkson> So you are assuming the flag day is set at the end of forced signaling
08:43 < AaronvanW> In other words, if miners follow economic incentives.
08:43 <@michaelfolkson> But miners could meet threshold of signaling many weeks, months before the forced signaling
08:43 < AaronvanW> No the flag day could be before or after.
08:43 <@michaelfolkson> Not if you want everyone to start enforcing soft fork rules at exactly the same time
08:44 <@michaelfolkson> Which was my definition of compatibililty
08:44 < AaronvanW> yes I agreed with that :)
08:44 < AaronvanW> do you also agree with me that nodes would stay on the same chain is miners comply with the UASF?
08:44 < AaronvanW> because that's also true.
08:44 <@michaelfolkson> In the scenario where there is a flag day and a BIP 8(LOT=true) deployed in parallel?
08:45 < AaronvanW> yes
08:45 <@michaelfolkson> It would depend when the flag day was set
08:45 < AaronvanW> why?
08:45 <@michaelfolkson> If the flag day is set months before forced signaling then the flag day could activate but the BIP 8 may not have reached the threshold on signaling
08:45 <@michaelfolkson> So again not compatible
08:46 < faketoshi> The issue is that one is a UASF and the other is a MASF that can start whenever miners want
08:46 < faketoshi> I don't think they can be compatible
08:46 < AaronvanW> miners would have to comply with both the flag day and mandatory signaling in that case. (or isStandard should do the trick until mandatory signaling.)
08:47 <@michaelfolkson> A flag day would be a very authoritative move from Core. It would be saying Core decides when soft fork rules should be enforced. Very bold
08:47 <@michaelfolkson> I would be very surprised if Core *ever* released a flag day. (Despite murch not liking LOT=true or LOT=false)
08:47 < faketoshi> The only thing that can ever happen imo is core releases something non-committal and an alt client enforces that it works
08:48 < faketoshi> we can't do that with ST because it would be too rushed - which is part of the reason I am against ST
08:48 < AaronvanW> michaelfolkson: that's a very different argument though.
08:48 <@michaelfolkson> AaronvanW: Indeed different argument to the compatibility argument
08:49 <@michaelfolkson> AaronvanW: You don't have to worry about compatibility if Core have the authority to set the block height for when soft fork rules are enforced
08:49 < AaronvanW> michaelfolkson: Core doesn't have that authority
08:49 <@michaelfolkson> Well then they shouldn't ever release a flag day
08:49 < AaronvanW> users _always_ decide which software to run
08:49 < AaronvanW> so do miners
08:50 < AaronvanW> michaelfolkson: I'm not arguing in favor of a flag day, just explaining how different nodes can be compatible, where I define compatible as "follow the same chain".
08:51 <@michaelfolkson> AaronvanW: To "follow the same chain" they need to enforcing the soft fork rules from the same point in time/block height
08:51 <@michaelfolkson> Or at least to ensure that is certain
08:51 < AaronvanW> no that's not accurate
08:51 < AaronvanW> yes to ensure that it's certain, that's accurate
08:51 <@michaelfolkson> You don't want to rely on luck for things like this
08:52 < AaronvanW> it's not luck, it's incentives
08:52 <@michaelfolkson> No one knows what is happening. Who is enforcing the soft fork rules and who isn't
08:52 < AaronvanW> miners have an incentive to prevent a chain split. (imo)
08:52 <@michaelfolkson> They could all get together and decide on a flag day themselves (theoretically)
08:53 < AaronvanW> they could
08:54 <@michaelfolkson> But without central coordination (Core deciding on flag day or miner communication) you need miner signaling and potentially forced signaling if miners don't signal
08:54 <@michaelfolkson> So no flag day results in going back to LOT=true vs LOT=false discussion
08:55 <@michaelfolkson> The discussion is infinitely circular
08:56 <@michaelfolkson> Yet it appears way too many people *still* haven't realized this and somehow think avoiding BIP 8 solves all their problems
08:56 <@michaelfolkson> Maybe one day they'll get to this realization
08:58 <@michaelfolkson> Just a few more rounds on the merry-go-round
09:02 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 252 seconds]
09:06 < AaronvanW> well, you need a Schelling point to decide when the new rules are active. but even if different users use different schelling points, it doesn't need to result in a chain split. that depends on what miners do.
09:07 < AaronvanW> I'm not saying that is a good idea, just saying that it is the case.
09:07 <@michaelfolkson> It is relying on luck to avoid a chain split. And presumably miners don't know what other miners are doing (at least without central coordination)
09:08 < AaronvanW> not (just) luck, (also) incentives.
09:08 <@michaelfolkson> The only thing they can do to act on "incentives" is central coordination
09:09 < AaronvanW> They can start enforcing the Taproot rules *now* and signal *now*, and I think there will be no chain split in (almost) any scenario.
09:09 < AaronvanW> eg
09:10 <@michaelfolkson> All miners need to know whether all other miners are enforcing soft fork rules. You only avoid that with signaling, forced signaling or central coordination of miners
09:11 <@michaelfolkson> Signaling and forced signaling is the only information to act on (assuming no central coordination of miners)
09:11 < AaronvanW> I guess the safest bet is to comply with the first schelling point?
09:11 <@michaelfolkson> No one knows when that is
09:12 <@michaelfolkson> If there is any disagreement on that "schelling point" you are relying on luck to avoid a chain split
09:12 < AaronvanW> I guess that makes the first schelling point *the* schelling point...
09:13 <@michaelfolkson> Assuming everyone agrees when that first schelling point is
09:13 <@michaelfolkson> Which they won't
09:13 < AaronvanW> first schelling point is to start enforcing when 90% signals in one difficulty window.
09:13 <@michaelfolkson> That's not a schelling point. That is defined in Speedy Trial
09:13 < AaronvanW> or if that doesn't happen, when the flag day is reached
09:14 < AaronvanW> "That's not a schelling point. That is defined in Speedy Trial" <--- that makes is a schelling point?
09:14 < AaronvanW> *makes it
09:14 < AaronvanW> but the same is still true after ST.
09:15 <@michaelfolkson> If everyone is following Speedy Trial we follow the rules of Speedy Trial
09:15 < AaronvanW> yes, great.
09:15 <@michaelfolkson> If no one knows what the activation mechanism or activation parameters are then no one will agree on when schelling points are
09:15 <@michaelfolkson> So the schelling point is pretty useless as a concept
09:16 < AaronvanW> if miners signal 90% in september this year, I still think that's a pretty clear schelling point. at least for miners. you don't?
09:16 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
09:16 <@michaelfolkson> You need certainty. Something that "schelling points" and "incentives" as concepts don't provide.
09:16 < luke-jr> [15:25:49] <michaelfolkson> AaronvanW: There is no miner signaling with a flag day <-- there can be
09:17 < AaronvanW> yes, there can be, and I think that's a superior idea than flag day without MASF.
09:17 <@michaelfolkson> AaronvanW: It depends on what Core has released and whether miners/users are running the alternative client
09:17 <@michaelfolkson> AaronvanW: Re the September scenario
09:18 < AaronvanW> michaelfolkson: Bitcoin works thanks to incentives.
09:18 < AaronvanW> if they don't provide, we have a much bigger problem.
09:19 <@michaelfolkson> AaronvanW: We should all just sit back and let the "incentives" solve all the problems for us
09:19 < AaronvanW> I think we should figure out the incentives. (that's what I'm trying to do anyways.)
09:19 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation
09:19 <@michaelfolkson> AaronvanW: The "incentives" will decide the "schelling point". No need to worry or discuss anything. Leave it to the "incentives"
09:20 <@michaelfolkson> Our work is done
09:21 <@michaelfolkson> The incentives are that we care and we are here trying to avoid a chain split. But the "incentives" don't provide a magic wand solution
09:22 <@michaelfolkson> At the moment the "incentives" are just generating replayed circular arguments
09:23 < luke-jr> AaronvanW: I meant simply including a mandatory signal with the flag day
09:26 < AaronvanW> "No need to worry or discuss anything" <--- quite the opposite imo
09:26 < luke-jr> on another note, "Core" releasing ST is turning out to be worse than I would have expected. Had I known all these problems, I would have NACK'd BIP8 ST too. :/
09:26 < luke-jr> there's apparently so much centralisation around Core that people are de facto being forced to use ST and blocked from using BIP8
09:26 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
09:27 <@michaelfolkson> luke-jr: Rusty was right all along
09:27 < luke-jr> michaelfolkson: that's not very surprising tbh; Rusty is smart
09:27 < AaronvanW> 'But the "incentives" don't provide a magic wand solution' <--- no but I do believe they provide a solution if we can figure them out.
09:28 < murch> michaelfolkson: Don't twist my words. I specifically said that "neither `BIP8/LOT=true` nor `BIP8/LOT=false` had consensus". That's neither a statement generally about LOT=t/f nor about my personal preference.
09:28 <@michaelfolkson> luke-jr: I thought at the time he had a weak argument. How wrong I was. The anti BIP 8 thing has shown that people haven't understood the basics or have their heads in the sand
09:29 <@michaelfolkson> murch: So let me summarize your view. You prefer LOT=false to LOT=true. Ok great. Noted
09:29 <@michaelfolkson> murch: Not a view on BIP 8
09:31 <@michaelfolkson> Hence in answer to your tweet, a BIP can have a consensus but there not be consensus on what a single parameter should be set to
09:32 <@michaelfolkson> This isn't rocket science
09:33 < AaronvanW> This is much harder than rocket science.
09:33 <@michaelfolkson> Ha it shouldn't be
09:35 < AaronvanW> Keeping a decentralized network with autonomously acting individuals in consensus is pretty damn hard.
09:36 <@michaelfolkson> This argument that because there is no consensus on what a single parameter should be set to hence we should throw out the whole BIP is nonsense that some people seem determined to cling onto
09:36 <@michaelfolkson> It has been going on for the best part of 2 months now
09:36 < AaronvanW> (I did say it half in jest, and it's something I remember BTC Drak saying.)
09:39 -!- Alexandre_Chery [94669daa@148.102.157.170] has joined ##taproot-activation
09:42 -!- Alexandre_Chery [94669daa@148.102.157.170] has quit [Client Quit]
09:43 <@michaelfolkson> Trying to kill BIP 8 is essentially trying to kill the concept that Core and an alternative release can run in parallel and be compatible until the last two weeks
09:43 <@michaelfolkson> Which essentially is trying to kill the concept of a UASF
09:43 < murch> michaelfolkson: Since the key feature of BIP8 vs BIP9 is LOT, it kinda seems droll that you think BIP8 can have consensus while neither of the two options `BIP8/LOT=true` and `BIP8/LOT=false` are palatable.
09:45 <@michaelfolkson> murch: You can have everything defined in one BIP (BIP 8) or two BIPs. Two BIPs is an attempt to prevent an alternative release (with LOT=true) running in parallel with Core (LOT=false)
09:45 <@michaelfolkson> murch: That attempt fails because it is impossible. And it makes it harder for parallel deployments
09:46 < murch> What are you even talking about?
09:47 <@michaelfolkson> murch: We could have a LOT=true BIP and a separate LOT=false BIP to keep you happy
09:47 <@michaelfolkson> Its only purpose would be to try to stop LOT=true running in parallel with LOT=false
09:47 < murch> The whole point of an activation proposal is to converge on one methodology
09:48 <@michaelfolkson> And that is the philosopher's stone
09:48 < murch> So why would anyone want that.
09:48 -!- roconnor [~roconnor@host-45-58-195-183.dyn.295.ca] has joined ##taproot-activation
09:48 <@michaelfolkson> Because a BIP 8(1 year, LOT=true) is compatible with a BIP 8(1 year, LOT=false) until the final two weeks
09:49 < murch> Yes and then it behavior is undefined because nobody can measure how many people are running either
09:49 <@michaelfolkson> You get the best part of a year where they are totally compatible. And anti LOT=true and anti LOT=false are happy until those two weeks
09:49 < murch> yes, but that is exactly what NOBODY WANTS.
09:49 <@michaelfolkson> murch: Hate to break it to you but if miners aren't going to signal for a soft fork you get into a UASF scenario
09:49 < murch> Maybe
09:50 <@michaelfolkson> murch: Better to define when that will be than not
09:50 < murch> But that's what we're currently measuring. If ST locks in Taproot, good. If not, another proposal can be made.
09:50 <@michaelfolkson> Assuming you ignore the alternative release, yes
09:51 < luke-jr> murch: LOT=True is more than palatable
09:51 < murch> I don't understand how you know what happens next. Cuz it sure as hell isn't waiting another 12 months if ST just barely didn't get enough signal.
09:51 < AaronvanW> murch: "The whole point of an activation proposal is to converge on one methodology" <--- I think some people will definitely run LOT=true. So either everyone converges on LOT=true, or there will be several methodologies. (I say this as an observer, I don't currently run LOT=true, nor do I know if I will.)
09:52 < luke-jr> murch: even if ST fails, the main BIP8 release still continues and can trigger activation the very next period
09:52 < murch> AaronvanW: Right, so running LOT=true if ST fails is _one option_. And some people might. But there might also be another proposal.
09:52 <@michaelfolkson> murch: The alternative release has attempted to define that period that "NOBODY WANTS" to November 2022
09:52 < AaronvanW> murch: I'm all ears :)
09:52 <@michaelfolkson> murch: Core can choose to fit within that or release something that isn't compatible
09:53 <@michaelfolkson> I do love a good philosopher's stone. Endless entertainment
09:54 -!- jonatack [~jon@88.127.52.83] has quit [Ping timeout: 252 seconds]
09:55 < murch> Let's say, that e.g. 0.21.1 were widely deployed among the node population and ST failed to activate with 88% signal in the end. Some options that would be on the table would be to deploy a flagday activation for 709632. Or another 3 month signaling window, with ST/LOT=true.
09:56 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
09:56 < murch> It would seem pointless to wait until November 2022 in that case, imho.
09:56 <@michaelfolkson> murch: There are infinite options. The problem is getting consensus around one
09:56 <@michaelfolkson> murch: You may be happy with that. Somebody else won't
09:56 < murch> If there are other concerns, it might make sense not to try to activate this proposal at all.
09:56 < luke-jr> murch: so long as you're ignoring everyone who disagrees with you..
09:57 < murch> Well, I guess we'd find that out then, no?
09:57 < luke-jr> (one nice thing with BIP8 is that the date can be moved forward tho)
09:58 <@michaelfolkson> murch: We'll find out everyone disagrees, sure
09:58 < AaronvanW> murch: "If there are other concerns, it might make sense not to try to activate this proposal at all." <--- again, I think some people will definitely run LOT=true
09:58 < luke-jr> murch: why wait to find out? the BIP9 ST path is already ignoring disagreement
10:01 < murch> AaronvanW: Maybe, but that's their prerogative. Might not be the emerging schelling point, though.
10:01 < AaronvanW> murch: but it does mean that "not to try to activate this proposal at all" is off the table.
10:01 < AaronvanW> unless you think you can convince them otherwise
10:02 < AaronvanW> in which case, go ahead
10:02 -!- rotten [~rottensox@unaffiliated/rottensox] has quit [Remote host closed the connection]
10:02 -!- rotten [~rottensox@unaffiliated/rottensox] has joined ##taproot-activation
10:02 < murch> Well, I would assume that if e.g. an actual problem were discovered with the BIPs as currently proposed, that might be sufficiently convincing.
10:02 < AaronvanW> (not sure who you should speak to exactly, some LOT=true people are probably not even in this channel or on social media etc)
10:03 < AaronvanW> "Well, I would assume that if e.g. an actual problem were discovered with the BIPs as currently proposed, that might be sufficiently convincing." <--- in that case maybe yes
10:03 < AaronvanW> assuming you mean taproot itself?
10:03 < murch> yes
10:05 <@michaelfolkson> A bug is an emergency scenario where the activation mechanism discussion gets thrown out the window. It shouldn't be activated at all regardless of activation mechanism
10:05 < luke-jr> alternatively, it could possibly still be on  the same schedule
10:05 < luke-jr> same as when a bug is found in active rules
10:06 < luke-jr> though it depends on the bug ofc
10:06 < murch> Sure
10:21 < robert_spigler> In the debate on signalling, I understand that some people don't want to lose hashpower. But shouldn't miners be aware of the current full ruleset, and wouldn't we be more likely to lose hash power if miners aren't given the heads up about consensus changes by signalling?
10:22 < robert_spigler> But maybe less people will use light wallets if miners aren't 'trusted' to enforce all rules...
10:22 < murch> AaronvanW: Maybe a more relatable scenario. Let's say a small but impactful optimization improvement for the Taproot construction is discovered during the ST. Activation attempt is aborted and the BIPs are amended before another activation attempt.
10:23 < AaronvanW> murch: dunno
10:23 < murch> robert_spigler: I don't follow. Is this a question about mandatory signaling?
10:23 < AaronvanW> I'm reasoning from the perspective that Taproot itself has consensus.
10:24 < murch> That is my perception as well
10:25 < robert_spigler> murch: mandatory signalling / flag day with no signalling
10:25 <@michaelfolkson> murch: Luke's argument (which I agree with) is that you don't attempt an activation until you think all optimizations have been found
10:25 < murch> but let's say adding one byte in the output script for something unlocked a whole major usecase. The BIP authors withdraw their proposal and submit a new one that supersedes it. Do you think people would continue to run LOT=true for the old rule update?
10:25 < luke-jr> robert_spigler: if signal is required for validity, miners will signal, even if it means "false signalling"
10:26 <@michaelfolkson> Difference between committing towards an activation with an emergency backout and only halfheartedly committing towards an activation (thinking you might call it off due to new optimizations found)
10:27 <@michaelfolkson> If you think those optimizations will be found don't submit the soft fork for an activation yet
10:27 < luke-jr> murch: once the activation is rolled out, I'm not sure authors should be updating the spec incompatibly (but I don't see anything to stop them)
10:28 < luke-jr> murch: if the community moves forward with the original version, it might make sense to duplicate the BIP with new champions/"authors"
10:28 < murch> Well, the activation their BIP proposed would have failed at that point
10:28 < AaronvanW> robert_spigler: with LOT=true, we may lose hash power to non-signaling miners during the signaling phase. Non-upgraded miners can always mine invalid blocks after activation, regardless of activation mechanism, but (if they use isStandard) only if they build on top of invalid blocks, or mine an invalid block intentionally.
10:28 < luke-jr> murch: well, this is a flaw in the BIP specifying a different activation than that the communtiy is using
10:28 < murch> luke-jr: Yes, the new BIP would likely have a different activation mechanism and signal on a different BIP
10:28 < AaronvanW> (I'm not saying we will lose hash power during mandatory signaling phase, just that it's possible.)
10:29 < murch> But I'm trying to point out some downsides of having two separate activation proposals for the same rulechange
10:30 < murch> luke-jr: Could you please point out the BIP that "the community" is trying to activate and which BIP specifies the activation parameters?
10:30 < luke-jr> murch: I'm not aware of a BIP for it at this time, but annoyingly the backlog on BIP PRs has grown a lot already again
10:30 < luke-jr> murch: hardly relevant to the point though
10:30 < luke-jr> it *should* have simply been added to the Taproot BIP
10:30 <@michaelfolkson> murch: You know there isn't one
10:31  * michaelfolkson eye rolls
10:31 < luke-jr> michaelfolkson: dunno, I think shinobiusmonk said he was going to submit one
10:31 <@michaelfolkson> We have the Core parameters in the BIP and the parameters in the alternative release are not in any BIP
10:31 < murch> michaelfolkson: I wonder why it is that the BIP authors specified the activation proposal that they propose for use with their soft fork proposal in their own BIP
10:32 <@michaelfolkson> murch: I'm not sure if you are being sarcastic or not
10:32 < murch> Maybe that's how the BIP process works, that BIP authors propose an improvement
10:32 <@michaelfolkson> murch: If you aren't being sarcastic I agree with you. I don't think the BIP authors should decide how their soft fork gets activated
10:32 < murch> lol.
10:32 < roasbeef> double lol
10:33 < murch> michaelfolkson: So, you're saying that BIP authors cannot propose BIPs?
10:33 <@michaelfolkson> triple lol
10:33 < murch> Pretty sure it says in BIP2 that BIP authors own their BIP
10:33 <@michaelfolkson> I'm saying soft fork BIP authors shouldn't decide how their soft fork gets activated
10:34 < murch> Well, they proposed a BIP and it includes an activation mechanism, the one that they propose
10:34 <@michaelfolkson> Otherwise Mallory comes along and says I am going to do a BIP 8 (LOT=true, 2 weeks)
10:34 < murch> I don't see another BIP proposing anything.
10:34 < murch> michaelfolkson: I'm reminded of that Ricky Gervais quote.
10:34 < roasbeef> mallory can do w/e they want, ppl can run thier client if they want to or not, any random client can attempt a soft fork
10:34 <@michaelfolkson> murch: Which one?
10:35 < murch> BIPs are like copyright registrations. Anyone can propose what they want, as long as it fulfills the minimum standards for a BIP (Luke, please correct me if I am wrong)
10:36 < murch> During the process of creating a BIP, they should be circulated for whether they seem acceptable and useful.
10:36 <@michaelfolkson> I don't think a soft fork BIP needs activation params in it. Seems pointless if they are going to be disputed
10:37 <@michaelfolkson> Have all that drama and time waste that we had over the Luke merge
10:38 < robert_spigler> AaronvanW: So that's my point - does avoiding miner signalling really save hash power, if non-upgraded miners will still build invalid blocks after, say, a flag day activation (I assume not all miners use IsStandard, some miner might be evil, or make an invalid block accidentally where any non-upgraded miner can build on top of)
10:38 -!- cguida [~Adium@2806:2f0:51c1:5cee:ec19:8226:6316:751c] has joined ##taproot-activation
10:39 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:1c7f:f6c1:f066:8fa4] has joined ##taproot-activation
10:41 <@michaelfolkson> People keep asking about a BIP PR with the alternative release's parameters so I suspect as the troublemaker I should open it
10:41 <@michaelfolkson> See what happens
10:41 <@michaelfolkson> Happy to do it
10:42 <@michaelfolkson> luke-jr: Let me know if shinobious would rather he did it or I did it. I don't mind either way
10:42 <@michaelfolkson> *shinobiousmonk
10:42 <@michaelfolkson> * shinobiusmonk
10:43 -!- cguida [~Adium@2806:2f0:51c1:5cee:ec19:8226:6316:751c] has quit [Ping timeout: 260 seconds]
10:45 <@michaelfolkson> A dress rehearsal for when Mallory gets a BIP 8(2 weeks, LOT=true) merged into her soft fork BIP and everyone disputes that activation mechanism
10:46 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:1c7f:f6c1:f066:8fa4] has quit [Ping timeout: 260 seconds]
10:50 < murch> michaelfolkson: Who is disputing the ST activation parameters? Even the proposal you champion went out of its way to be compatible with them.
10:51 < luke-jr> murch: there is a requirement that BIPs "keep with Bitcoin philosophy", but I don't think many (if any) have ever been rejected on those grounds; I think a proposal to (eg) make Bitcoin infinitely inflationary would perhaps qualify for that
10:52 < luke-jr> michaelfolkson: we already had that for BIP 101 I think
10:52 < luke-jr> https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#Deployment
10:53 < AaronvanW> robert_spigler: it might at least safe hash power during the must signal phase.
10:53 < luke-jr> "Activation is achieved when 750 of 1,000 consecutive blocks in the best chain have a version number with the first, second, third, and thirtieth bits set (0x20000007 in hex)."
10:53 <@michaelfolkson> murch: Can you stop asking questions you already know the answer to please? The activation params are MTP rather than block height and don't use any BIP rather than BIP 8 as you well know.
10:53 <@michaelfolkson> murch: In that sense they are disputed
10:55 <@michaelfolkson> murch: Plus what am I championing just so I know? BIP 8?
10:55 <@michaelfolkson> murch: It would be good to know what I am championing
10:55 -!- cguida [~Adium@2806:2f0:51c1:5cee:ec28:28d8:7d26:5683] has joined ##taproot-activation
10:59 < murch> michaelfolkson: yes, it would indeed be a great idea, if you knew something about what you're championing.
11:00 <@michaelfolkson> murch: As far as I know I'm not championing anything. But please let me know if you have more information than I do
11:01 <@michaelfolkson> I feel like I'm championing Taproot activation (though that may be disputed)
11:01 < robert_spigler> AaronvanW: that makes sense, don't know how useful that is in the long term though
11:03 < yevaud> luke-jr: objectively bip42 changed the currency issuance of Bitcoin substantially.
11:04 < luke-jr> yevaud: but in agreemetn with the philosophy
11:05 < luke-jr> yevaud: also, that's disputable in hindsight
11:05 < yevaud> disputable that it changed anything?
11:05 < luke-jr> yes
11:05 < luke-jr> nSubsidy was 64-bit
11:06 < luke-jr> so that's 64 halvings, times 4 years approx each = 256 years
11:06 < luke-jr> 2009+256=2265
11:06 < luke-jr> any block dated after AD 2106 is a hardfork
11:07 < luke-jr> I suspect if someone did the math, it is impossible for the bug scenario to ever occur
11:07 < yevaud> there's a few of those.
11:08 < luke-jr> ?
11:08 < yevaud> I never did work out if 0.1.5 was a hard fork or not when nLockTime was changed from a int64 to a uint64.
11:09 < luke-jr> sounds like a softfork, without looking into it
11:09 < luke-jr> https://en.bitcoin.it/wiki/Consensus_versions documents it as a softfork too
11:09 < yevaud> we couldn't come up with any values that would cause it to be a hard fork, but it obviously doesn't matter.
11:10 < yevaud> heh that page misses like, 20 hard forks :)
11:11 < luke-jr> https://bitcoin.stackexchange.com/questions/90229/nlocktime-in-bitcoin-core/99104#99104
11:11 < luke-jr> yevaud: does it?
11:11 < yevaud> yes, OP_VER used to push the version number of the validating node to the stack.
11:11 < murch> https://blog.bitmex.com/bitcoins-consensus-forks/ has a pretty decent overview, IIRC
11:11 < luke-jr> yevaud: was that a bug or hardfork? :P
11:11 < yevaud> every version from 0.1  > 0.3.6 is a hard fork.
11:12 < yevaud> luke-jr: I think it was a misguided attempt to add upgradable scripts without quite considering what allowing branching on a local condition would do.
11:13 < luke-jr> an OP_VERIF might be interesting
11:13 < yevaud> that existed too.
11:13 < luke-jr> well, not in a safe way
11:13 < luke-jr> I'm thinking more of OP_SUCCESS_IF_VERSION_LESS_THAN
11:13 < AaronvanW> robert_spigler: me neither. I suspect not very useful/important.
11:13 < yevaud> luke-jr: so, a OP_NOP :P
11:14 < luke-jr> yevaud: no, OP_NOP doesn't stop the script
11:15 < luke-jr> more like Tapscript's OP_SUCCESS*
11:15 < luke-jr> but you could pop a version off the stack
11:17 < luke-jr> actually, it'd be essentially the witness version number
11:18 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 265 seconds]
11:34 < robert_spigler> AaronvanW: BlueMatt had the strongest opinion on it, so I wonder what his response to the above would be
11:43 -!- duringo [2d57d6c5@45.87.214.197] has joined ##taproot-activation
11:44 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
11:50 -!- Alexandre_Chery [94669daa@148.102.157.170] has joined ##taproot-activation
11:53 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
11:56 -!- Alexandre_Chery [94669daa@148.102.157.170] has quit [Quit: Connection closed]
12:53 -!- Netsplit *.net <-> *.split quits: justinmoon_, CubicEarth, belcher, da2ce7
12:55 -!- Netsplit over, joins: belcher, justinmoon_, CubicEarth, da2ce7
12:57 -!- bcman [~quassel@192.252.212.38] has joined ##taproot-activation
12:59 -!- faketoshi [~quassel@192.252.212.14] has quit [Ping timeout: 240 seconds]
14:02 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
14:02 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
14:06 < AaronvanW> robert_spigler: he'd have to be convinced that there's material benefit in mandatory signaling.
14:18 -!- openoms [~quassel@gateway/tor-sasl/openoms] has quit [Remote host closed the connection]
14:18 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined ##taproot-activation
14:30 -!- rotten_ [~rottensox@unaffiliated/rottensox] has joined ##taproot-activation
14:31 -!- rotten [~rottensox@unaffiliated/rottensox] has quit [Read error: Connection reset by peer]
14:55 -!- gevs [~evias@67.red-88-6-131.staticip.rima-tde.net] has quit [Ping timeout: 246 seconds]
14:56 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Remote host closed the connection]
14:57 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
14:58 -!- gevs [~evias@67.red-88-6-131.staticip.rima-tde.net] has joined ##taproot-activation
15:00 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
15:02 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
16:23 < AaronvanW> aj -> https://twitter.com/adam3us/status/1389195408660893696 (not meant to be an argument from authority, just relevant in light of our discussion from a few days ago.)
16:25 < AaronvanW> oh I missed that you're in that thread, ha!
16:31 -!- miguelmedeiros [~miguelmed@2804:14c:8785:cde5:dcbb:32df:e8e7:370e] has joined ##taproot-activation
16:36 < murch> AaronvanW: Something failing to activate by a specific time isn't a veto.
16:37 < AaronvanW> something failing to activate at all because miners don't want it is.
16:39 < murch> by a specific time != at all
16:40 < murch> Coordinating with the miners is how soft forks get deployed faster and more safely.
16:40 < murch> It doesn't mean that there aren't other ways.
16:40 < belcher> right, thats the answer to adam3gs's question of "i don't understand why one would ever want to re-introduce miner veto"... because MASFs are safer and quicker, so worth trying at first
16:41 < AaronvanW> Do you think it is a problem to plan ahead for these other ways murch?
16:42 < murch> No
16:43 < AaronvanW> Do you think LOT=true is a good backup plan?
16:44 < murch> Potentially, yes.
16:44 <@aj> AaronvanW: switching from lot=false to lot=true is a reasonable plan, but not if lot=false is controversial too.
16:45 <@aj> AaronvanW: (my opinion)
16:45 < AaronvanW> What if ST fails?
16:46 < AaronvanW> That's essentially LOT=false, right? Just in its BIP9 form.
16:47 <@aj> AaronvanW: "switching from lot=false to lot=true" == "keeping the same bit, starttime/height, timeout/stopheight, so that the existing set of lot=false clients also start enforcin the rules if lot=true has majority hashrate"
16:47 <@aj> AaronvanW: doing that for ST was specifically out of scope
16:49 <@aj> AaronvanW: if ST fails, a UASF (probably) makes sense, but lot=true would needlessly loose hashpower compared to other approaches, which (again my opinion) isn't reasonable
16:50 < AaronvanW> "switching from lot=false to lot=true" <- wouldn't that be "boycotting" non-signaling blocks? why is it different in this case? or wouldn't it? (I don't agree with the term boycott in this context, but you know that.)
16:53 < murch> Depending on the circumstances of the activation failure, I would expect either the proposal to get amended, or another activation attempt. A LOT=true activation would then probably be the most attractive since it still allows early activation.
16:55 < murch> I could also see a flagday activation be on the table.
16:59 <@aj> AaronvanW: yes, it would be boycotting non-signalling blocks; it'd be reasonable (in my opinion, not others) because it was only done after proven to be necessary and because it'd drag a substantial pre-existing installed base of lot=false nodes along
17:00 < AaronvanW> murch: that's reasonable. LOT=true people are planning ahead with a LOT=true backup plan. I don't think that's unreasonable. it can always be abandoned or ignored if something better is proposed later.
17:01 <@aj> "it can always be abandoned or ignored" -- that's not the way to write/release consensus software
17:02 < robert_spigler> is Adam saying that he favors LOT=true? confused by the wording in that tweet
17:02 < murch> AaronvanW: I am not against the concept of users enforcing a soft fork, my misgivings are specifically with this approach
17:03 < AaronvanW> "it'd drag a substantial pre-existing installed base of lot=false nodes along" <- I think I'd probably consider that more of a bonus than an argument in and of itself, but thanks for clarifying.
17:03 < AaronvanW> robert_spigler: yes
17:04 < murch> :s/approach/effort
17:06 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 252 seconds]
17:06 < AaronvanW> aj: I'm speaking for myself. IMO this is free software -- people are free to copy, change, etc -- and see if users want it. If you're right, users probably won't want it. LOT=true people seem to be convinced that nothing better will be proposed though, hence why they started working on a backup plan.
17:09 < murch> That's not how it's being marketed, though.
17:09 < AaronvanW> murch: different people have been marketing it differently.
17:10 < AaronvanW> they don't all agree on that.
17:10 < AaronvanW> but yeah you're partially right.
17:11 < murch> Cling together, swing together.
17:11 < AaronvanW> apes together strong
17:11 < murch> My misgivings especially are:
17:12 < robert_spigler> I wonder if Adam is supporting a LOT=true main or alt client in that tweet?
17:12 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
17:12 < AaronvanW> robert_spigler: ST for now I think.
17:12 < robert_spigler> I never quite understood the argument of starting with LOT=false, and following with LOT=true, what can we really learn from a failed attempt, do we really want to encourage an environment where we reach out to mining pools (centralization), etc.  Might as well start with LOT=true as the Core default.  But as that failed to get consensus, I think ST was a reasonable compromise.  I still believe a LOT=true
17:12 < robert_spigler> alt-client w/o a LOT=false main client is too dangerous
17:13 < robert_spigler> AaronvanW: makes sense
17:15 < luke-jr> switching makes no sense. if your intent is to activate, it shouldn't need switching
17:17 -!- faketoshi [~quassel@192.252.212.36] has joined ##taproot-activation
17:19 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
17:20 -!- bcman [~quassel@192.252.212.38] has quit [Ping timeout: 265 seconds]
17:22 < AaronvanW> 1) users shouldn't harm miners, because miners secure the network, so if miners are harmed, users are harmed, and users shouldn't be harmed. 2) users shouldn't harm miners, because miners are also users and users shouldn't be harmed. <- aj am I correct that 2 reflects your views accurately?
17:23 < AaronvanW> or is 1 more accurate?
17:24 < AaronvanW> (feel free to write it even more accurately in your own words, ofc.)
17:25 -!- yanmaani1 is now known as yanmaani
17:25 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 240 seconds]
17:34 -!- r1clas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 246 seconds]
17:51 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined ##taproot-activation
18:07 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Read error: Connection reset by peer]
18:09 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
18:21 < luke-jr> miners are not harmed by mandatory signalling, though
18:26 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Quit: Leaving]
18:33 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
18:42 < AaronvanW> well it means they can't leave their machine running and go travel the world for two years luke-jr. (or at least, no more than 10% can do that.)
18:42 < AaronvanW> other than that, I think I'd agree.
18:48 -!- yanmaani1 [~yanmaani@gateway/tor-sasl/yanmaani] has joined ##taproot-activation
18:51 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 252 seconds]
18:51 -!- yanmaani [~yanmaani@gateway/tor-sasl/yanmaani] has quit [Ping timeout: 240 seconds]
18:54 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation
18:58 -!- yanmaani1 is now known as yanmaani
18:59 <@aj> robert_spigler: "what can we really learn" -- 1) whether miners are willing/able to upgrade in a timely fashion -- if so, we can optimise for miners upgrading so activation can happen earlier; if not we should optimise for nodes upgrading which takes longer, but not as long as if we spend time worrying about miners upgrading first; 2) whether people have been ignoring taproot until it gets
18:59 <@aj> "released" and if they'll find any bugs; 3) how fast users/businesses/exchanges/etc will deploy new software enforcing taproot, which also impacts how long things will take; 4) if there's other random controversy and where it comes from
19:00 <@aj> AaronvanW: ideally *nobody* should be harmed
19:00 <@aj> AaronvanW: or stronger, ideally nobody should be even mildly inconvenienced
19:05 <@aj> AaronvanW: ("ideally" is doing some work there -- making bitcoin better harms people who're trying to have altcoins beat bitcoin maybe; and having to read comments on twitter alone can mildly inconvenience people...)
19:08 < AaronvanW> aj: if you could be convinced that mandatory signaling has material benefits (eg: they would better allow for futures markets), could that sway your opinion?
19:09 < AaronvanW> (f)
19:09 < AaronvanW> (if)
19:10 < AaronvanW> your opinion on LOT=true I mean.
19:10 < AaronvanW> versus flag day
19:11 <@aj> AaronvanW: the material benefit is dragging along the existing installed base of lot=false users
19:12 < AaronvanW> aj: does it matter who would have released the LOT=false client?
19:12 < belcher> maybe lot=false users dont want to be dragged along
19:12 < AaronvanW> belcher: then they shouldn't run LOT=false?
19:12 <@aj> AaronvanW: i spent a bunch of time arguing with matt about futures markets; at this point i'm convinced you can set them up without signalling at all (ie, just based on whether txs gets mined that violate the soft fork rules themselves) -- which is good, because futures markets shouldn't be dependent on details of the code
19:13 < belcher> AaronvanW or even nack it being merged into core
19:13 < luke-jr> AaronvanW: mining was never guaranteed to be set-and-forget - and last I checked, required much more maintenance anyway
19:13 < AaronvanW> belcher: wasn't talking about Core per se
19:13 < luke-jr> AaronvanW: besides, they could also hire someone to do the maintenance, or remotely do it
19:14 < luke-jr> belcher: the only safe way to reject a softfork, is to softfork-invalidate the signal; to do that also happens to depend on mandatory signalling for UASFs
19:15 < belcher> you can also safely reject a soft fork by breaking its rule, for taproot that would mean requiring the mining of a taproot-invalid transaction
19:15 < AaronvanW> aj: so I spent some time arguing with Matt as well, and I think we're talking about two different types of futures markets. Futures markets on whether or not Taproot will activate isn't what I have in mind. Is this what you have in mind?
19:15 < luke-jr> (there might be softfork-specific cases like mining an invalid transaction, but besides being tied to the specific softfork, they're also immensely more complicated to arrange)
19:16 <@aj> AaronvanW: perhaps you'd like to explain what you have in mind then?
19:16 < AaronvanW> oof it's getting late here, was just about to head for bed.
19:16 < AaronvanW> past 4AM.
19:16 < AaronvanW> I'll get back to this.
19:16 < luke-jr> boo, I was hoping to read the answer too :P
19:23 < AaronvanW> as a last remark, I still have a really really hard time understanding this position belcher; "maybe lot=false users dont want to be dragged along" <--- you DO want Taproot, you DO want activation code to be triggered by miners, but you for some reason you don't want it to be triggered if there are also LOT=true clients on the network... The "for some reason" part is honestly something I haven't been able to wrap my h
19:23 < AaronvanW> ead around.
19:24 < belcher> you do want taproot but dont want extra risk of reorgs
19:24 < belcher> it might be that you dont mind about taproot either way, but dont want stop taproot if other people want it... and certainly dont want reorg risk so you fear that risk more than you like taproot
19:25 < AaronvanW> who has extra risk of reorgs? you (as a LOT=false user), or someone else?
19:25 < luke-jr> belcher: the extra risk of reorgs comes entirely from not using LOT=True yourself
19:26 < luke-jr> using LOT=False doesn't change that
19:26 < luke-jr> (vs no activation at all)
19:27 < AaronvanW> oh, during the must signal phase. yeah that risk also exists if you don't run LOT=false. so I don't understand what you think the difference is.
19:28 < AaronvanW> (what Luke said.)
19:28 < luke-jr> if you want to avoid reorgs, you run LOT=True yourself, even if you don't care about Taproot
19:29 < luke-jr> the only time it makes sense to run something other than LOT=True, is if you actively wish to reject Taproot - in which case, you need to find a way to reject it cleanly (which the mandatory signalling ensures you have)
19:29 < AaronvanW> to be clear, I agree with you luke-jr. my last comment was for belcher.
19:30 < luke-jr> yes, I'm just elaborating
19:30 < luke-jr> I wonder if BIP8 should really document the "reject a softfork" logic too
19:35 < AaronvanW> yes I think that would be good luke-jr.
19:36 < AaronvanW> and exactly what the futures market I have in mind would need.
19:36 < AaronvanW> I'm still up, I'll try to explain.
19:37 < AaronvanW> I think a futures market would/should essentially offer a choice between "Taproot coin" and "non-Taproot coin".
19:37 < AaronvanW> If there is a split, those who bought Taproot-coin will get Taproot-coin after the split, those who bought non-Taproot coin will get non-Taproot coin.
19:37 < AaronvanW> We don't _want_ this scenario to play out, we prefer no split at all, but that's how the futures market should be designed.
19:38 <@aj> "as a last remark"
19:38 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
19:38 < AaronvanW> If miners activate and there is no split, anyone who bought Taproot-coin, will get BTC after the split. After all, that's Taproot-coin. Those who bought non-Taproot coin get nothing. Because there is no non-Taproot coin.
19:38 <@aj> these conversations should come with warnings from the surgeon general or something
19:40 <@aj> AaronvanW: how is that different to a "taproot activation future's market" ?
19:40 < AaronvanW> There is a small problem here, because if there should be a split but non-Taproot coin is less valuable, there will probably be no non-Taproot coin. Because miners mine the valuable chain, and the non-Taproot chain is reorged away.
19:41 < AaronvanW> So the futures market is biased in favour of Taproot.
19:42 < AaronvanW> Therefore, for Taproot-opponents to bet on Taproot coin, they should be confident that they can bet on it even if it becomes a minority coin. That's only fair.
19:43 < AaronvanW> So I think this needs reject-a-soft fork logic.
19:45 <@aj> AaronvanW: ohhhh, you're contrasting this to a prediction market, bet it activates get $x if it does, but it doesn't activate get $1/x if it doesn't?
19:45 < AaronvanW> For a futures market to be implemented, it needs to be based on something objective. Like a signal on the blockchain, that will provide a definitive answer to whether a coin is Taproot-coin or not.
19:45 <@aj> AaronvanW: you can do reject-a-soft-fork logic without 90% mandatory signalling -- eg, "rejected if 90% signals against" or "rejected if a tx violates the new rules"
19:46 < AaronvanW> aj: yes there are other ways to do it.
19:46 < AaronvanW> as long as it's objective it should work, I think...
19:47 < AaronvanW> But you can't have a chain that continues to exist in quantum state, where different client have different ideas of what the chain is.
19:47 <@aj> AaronvanW: (if you can't construct a block that violates the soft fork rule, is it really a fork at all?)
19:47 < AaronvanW> aj: in that case the contract just expires after a year or whatever and you get nothing.
19:47 <@aj> AaronvanW: i'd say you *always* have a chain which exists in a quantum state -- what if there's a 100% consensus hardfork later that does away with taproot?
19:48 < AaronvanW> that's what happened with 2X futures I think.
19:48 < AaronvanW> aj: Matt brought up a similar point, and I haven't thought about that long enough and it's too late here to do that now :p
19:48 <@aj> AaronvanW: (2x futures expired 2017/12/31, but were "decided" early nov)
19:49 < AaronvanW> But I wonder if luke-jr has a good answer for that.
19:50 < AaronvanW> aj: I think the difference may be 1) technical, 2) legal. technically, yeah always quantum state(?) Legal: you just get paid on the chain that signaled, what nodes actually enforce is irrelevant in that context.
19:52 <@aj> AaronvanW: you're resolving the futures market based on the history of the chain up to that point -- you can decide what you'll accept in future, but there's never certainty about what everyone else will accept
19:52 < AaronvanW> aj: and yes I should probably start using prediction markets instead of futures markets shouldn't I...
19:52 < AaronvanW> aj: right. that makes sense, no?
19:53 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
19:53 < luke-jr> later hardforks are irrelevant afaict?
19:53 <@aj> AaronvanW: nVersion signalling is a super-easy thing to look at for the history of the chain, so if we can use it, that's great. but it doesn't need to be >90%-1-bits, it could be <90%-1-bits (that's the revocable flag day), or something different. and nVersion's only adding convenience there
19:53 < AaronvanW> I think I agree luke-jr
19:53 < luke-jr> your future isn't "Taproot remains active" after all
19:54 < luke-jr> aj: I did suggest inverted signalling and 50%+1 a few months ago, but nobody seemed interested, and it lost other features of BIP8, so ..
19:55 < AaronvanW> aj yes I think it can be any of these things. it just can't be simple flag day.
19:55 <@aj> AaronvanW: futures markets imply coin split tokens to me; prediction markets are "one of these outcomes will occur (not both!) and you'll get paid a "dollar" if you guess right"
19:55 <@aj> luke-jr: yeah, i saw
19:55 < AaronvanW> aj: then I guess it's a bit of both, which explains why I've been conflating terms.
19:56 <@aj> luke-jr: it loses the "pull lot=false implementations along for the ride" but nobody's doing that anymore
19:56 <@aj> AaronvanW: "futures markets" is a pretty general term
19:56 < luke-jr> aj: well, it also loses "pull a later LOT=true along" ;)
19:56 < luke-jr> as well as, "If there's going to be a split, it'd be better to have it immediately" or such (I forget the other objection specifically, but it was something liek thsi)
19:57 <@aj> luke-jr: it doesn't lose "pull a later revocable flag day along" if the earlier flag day forbids "later" signalling?
19:57 < luke-jr> aj: what do you mean?
19:57 <@aj> luke-jr: revocable flag day -- activation at X, revoking period at Y
19:58 < luke-jr> what I meant is, if the community decides 2022 Nov is too late, right now they can move timeoutheight to 2022 Aug or such, and the nodes using 2022 Nov will follow along
19:58 <@aj> luke-jr: earlier revocable lag day -- activation at X, revoking period at Y-k, adds additional rule that signalling in Y is invalid
19:58 <@aj> yeah, can't bring actual activation earlier
19:59 <@aj> if speedy trial activates, will be interesting to see how much complaining there is about the wait 'til ~nov
19:59 < luke-jr> hmm, what you're saying sounds like something I was discussing with AaronvanW the other day: maybe more time is needed to react to an unwelcome activation
20:00 < luke-jr> eg, your node sees 75% signalling on a bit you don't like - you have very limited time to reject that activation with BIP8 today
20:00 < luke-jr> if that's the final 75% of the period, no time at all
20:00 <@aj> 75% ?
20:01 < luke-jr> that didn't get into ST? reducing the warning threshold..
20:01 < luke-jr> if not, put 90% there
20:01 < luke-jr> even more likely users won't see that in time :P
20:01 <@aj> current core still has warning and activation threshold equal
20:02 < roasbeef> reject it? it's a soft-fork so you just don't need to use it
20:02 < luke-jr> roasbeef: you need to reject it or enforce it, otherwise you lose full node security
20:02 < luke-jr> and not all hypothetical softforks are optin
20:02 < roasbeef> or you just shutdown your node I guess, but even then you have no way of knowing how many on going softforks actually exist, given they can be done at anytime
20:03 < luke-jr> roasbeef: 51% attacks are distinct from softforks
20:03 <@aj> if you only get a warning when it's locked in, you can't ever do anything about it -- except ignore it and hope miners do the same and it's irrelevant, or hard/soft fork it out, or not use the features and not care about them
20:03 < roasbeef> so you think soft forks can only be done via versionbits or something? any random client can get together w/  hash rate to enforce some soft fork
20:03 <@aj> s/do anything about it/do anything to prevent it/; you could upgrade your node and enforce the new rules, obviously
20:03 < luke-jr> roasbeef: beside the point
20:03 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 265 seconds]
20:04 < luke-jr> roasbeef: being able to easily reject softforks is a feature of the activation mechanism, in this context BIP8
20:04 < roasbeef> you may not even know they're happening, that's kinda how they work
20:05 < AaronvanW> roasbeef: but WE are not trying to attack users (I think?), we DO want everyone to know what's happening so users ca opt-out if they want.
20:05 < roasbeef> the whole point of soft forks is that updates can happen w/o needing get the entire ecosystem to update
20:06 < AaronvanW> roasbeef: they still don't NEED to. (IMO -- luke-jr disagrees)
20:06 < roasbeef> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html
20:06 < robert_spigler> aj: "1) whether miners are willing/able to upgrade in a timely fashion" That just doesn't compute for me.  If ST fails, miners obviously aren't willing/able.  We won't be able to figure out why the reason is.  LOT=true allows us to "optimise for miners upgrading so activation can happen earlier" while also "optimise for nodes upgrading which takes longer"
20:09 <@aj> robert_spigler: if they're not able to upgrade in a timely fashion, i'd expect to see bug reports or requests for help sometime this month, and i'd expect them to be resolved fairly quickly, and not cause ST to fail. if pools take a day to upgrade, or a week, or a month, that's useful information both for improving the client, and potentially for miners to decide which pools are well run and which
20:09 <@aj> aren't
20:10 < AaronvanW> roasbeef: users who don't upgrade will just follow the majority. they can say "I don't know what this upgrade is, I'll just follow whatever the rest of ya'll are doing." (and maybe upgrade later when it's clear what the majority does.)
20:10 <@aj> robert_spigler: if they're not willing to upgrade in a timely fashion, we might see rational reasons for it that make objective sense, and can address them; or it might just be stonewalling with weird complaints that don't make sense, in which case there's probably no point trying to get miners to upgrade fast in future. what % doesn't upgrade quickly might be useful information for setting the
20:10 <@aj> threshold in future
20:11 < luke-jr> btw, it's funny to think some suggest miners can be expected to be there to voluntarily signal, yet at the same time magically need to be on isolated vacation during MUST_SIGNAL :P
20:11 <@aj> luke-jr: if miners are around to voluntarily signal, ST works; if they're on isolated vacations instead, MUST_SIGNAL causes problems
20:12 <@aj> ST is not the end of the story, there's the ORY part as well
20:12 <@aj> mental note to self: make up an activation method that has ORY as its acronym
20:12 <@aj> AaronvanW: why are you still awake?
20:13 < AaronvanW> get off my back mom
20:13 <@aj> AaronvanW: i just want to know you're taking care of yourself
20:14 < AaronvanW> I'm switching timezones in two days so it's probably fine actually.
20:14 < AaronvanW> get in the rhythm
20:15 < roasbeef> AaronvanW: not exactly, they'll continue to validate what they already know how to, if they don't use the new tx types, or increase the uncertainty of any transactions that pass thru a next script/tx type, then not much changes for them
20:15 < robert_spigler> aj: but you're assuming miners are acting in good faith, and this works during LOT=true as well (miners filing requests for help)
20:15 <@aj> i remember switching timezones
20:15 < AaronvanW> lol it will be my first time in... 18 months or so?
20:15 < robert_spigler> LOT=true includes a MASF, so I just don't understand why not start out with it.  I haven't heard of a scenario where we learn something that was worth it
20:16 < AaronvanW> roasbeef: that doesn't contradict what I said.
20:16 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Quit: brb]
20:17 < roasbeef> "follows majority" == "continue to validate the chain from their PoV"?
20:18 < AaronvanW> roasbeef: we're talking about a potential soft fork v soft fork split.
20:18 < robert_spigler> scenario: ST fails.  some miners file help requests. Most miners don't. Great - what have we learned? We assume they need more time? We try again with a lower threshold? Should have just started with LOT=true in the main client
20:18 < robert_spigler> (I hope ST succeeds)
20:19 < roasbeef> robert_spigler: I think aj already answered "what would we learn" above
20:19 < roasbeef> 21:58
20:20 -!- sturles [~sturles@unaffiliated/sturles] has quit [Ping timeout: 240 seconds]
20:20 < AaronvanW> did you just assume my timezone?
20:20 < AaronvanW> (robert_spigler's timezone)
20:21 < robert_spigler> lol
20:21 < robert_spigler> ""1) whether miners are willing/able to upgrade in a timely fashion" That just doesn't compute for me. If ST fails, miners obviously aren't willing/able. "
20:21 < robert_spigler> So you don't really learn anything
20:21 -!- liberliver [~Thunderbi@46.101.127.98] has quit [Ping timeout: 260 seconds]
20:22 -!- sturles [~sturles@sauron.uio.no] has joined ##taproot-activation
20:22 -!- sturles [~sturles@sauron.uio.no] has quit [Changing host]
20:22 -!- sturles [~sturles@unaffiliated/sturles] has joined ##taproot-activation
20:22 < robert_spigler> "2) whether people have been ignoring taproot until it gets
20:22 < robert_spigler> "released"" -> We shouldn't be discussing activation if taproot hasn't had sufficient analysis
20:22 < robert_spigler> "3) how fast users/businesses/exchanges/etc will deploy new software enforcing taproot" -> we've already set min_activation height, so if we are off about this, we're screwed
20:23 -!- liberliver [~Thunderbi@46.101.127.98] has joined ##taproot-activation
20:23 < robert_spigler> "4) if there's other random controversy and where it comes from" -> that's kind of my entire question. What are we learning?
20:25 < robert_spigler> * lol was to AaronvanW , not about aj's response, that sounded rude *
20:30 <@aj> robert_spigler: provided 90% of hashpower is voluntarily enforcing taproot rules, there's ~0 risk to users who don't upgrade. if there's a UASF to overrule miner opposition/carelessness, there's potentially huge risks to users who don't upgrade
20:32 < robert_spigler> I agree (to a point, the UASF, if adopted in the main Core client, I believe would force miners to enforce Taproot)
20:33 < robert_spigler> But we need Taproot, if MASF never succeeds, what else do we do?
20:33 < robert_spigler> eh, signal Taproot atleast*
20:35 <@aj> modern soft fork activation, decreasing threshold activation, flag day activation, revocable flag day activation are all alternatives that have been proposed, and a lot of people who've disagreed with lot=true now have agreed that if activation doesn't occur via ST then some sort of UASF is reasonable
20:38 <@aj> other random controversies; eg i don't think anyone expected to see something along the lines of  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-April/018868.html . maybe in future every attempt to improve bitcoin will see some important part of the infra break under the stress :-/
20:44 < robert_spigler> I see modern soft fork activation as an unnecessary subset of LOT=true.  I guess a MASF with a lower threshold (say 50%), would have less reorg risk than a LOT=true UASF with 50% miners enforcing
20:44 < robert_spigler> Yeah
20:44 < robert_spigler> Ok that makes sense
20:49 <@aj> masf != msfa
20:52 < robert_spigler> Yes, I was moving on to your second point: "decreasing threshold activation"
20:53 < robert_spigler> (going to bed for the night) thank you for the discussion!
21:58 -!- rotten_ is now known as rotten
22:14 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 252 seconds]
22:29 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
22:39 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
23:21 -!- rotten [~rottensox@unaffiliated/rottensox] has quit [Remote host closed the connection]
23:27 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
--- Log closed Tue May 04 00:00:46 2021