--- Log opened Mon Mar 08 00:00:51 2021
00:45 -!- b10c [~b10c@2a01:4f8:200:1036::1] has joined ##taproot-activation
01:15 -!- Teleportando [8eb30758@d142-179-7-88.bchsia.telus.net] has quit [Quit: Connection closed]
01:36 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
01:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
01:39 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
01:40 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
02:26 -!- ariel57 [d062df66@208.98.223.102] has joined ##taproot-activation
02:26 -!- p0x [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
02:27 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Remote host closed the connection]
02:31 < ariel57> pox: if you're expecting a hasty trial is going to fail because it's too hasty then that's a bad reason to go for it. When it fails then what? A 50% threshold? A long 2 year UASF? Any solution after a failure will be worse than the Super Majority proposal. Depending on these hasty trials gives leverage to big pools and neglects small ones. Hurting
02:31 < ariel57> decentralization.
02:31 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
02:31 -!- p0x [~pox@gateway/tor-sasl/pox] has quit [Ping timeout: 268 seconds]
02:43 -!- rubikputer [~rubikpute@ip72-192-27-21.ri.ri.cox.net] has quit [Ping timeout: 256 seconds]
02:52 < maaku> ariel57: 50% activation is the worst possible outcome, safety wise. guaranteed trouble.
02:54 < ariel57> Are you familiar with the proposal? It's 95% threshold for a year and then drop threshold to 51% during MUST_SIGNAL
02:55 < ariel57> Much better than either LOT=true or LOT=false or speedy trial.
02:55 < maaku> this issue actually exists for lower thresholds generally.  e.g. a 75% threshold might sounds safe, but a mere 26% of mining power can false signal to force activation and then back out to cause a majority against the fork'
02:57 < maaku> are you saying 51% *after* it has been locked in already by 95%? then I don't get the point, sorry.
02:59 < ariel57> Not after locked in. 51% during MUST_SIGNAL which only happens if LOCKED_IN doesn't happen for a year
03:01 < ariel57> The expectation is that if there is a 6% miner minority stalling. The worst they can do is delay activation for a year because after a year threshold drops to 51% and 94% signaling can comfortably activate.
03:04 -!- jonatack [~jon@37.166.102.70] has joined ##taproot-activation
03:04 < maaku> Then what I said above applies.
03:05 < maaku> This is really, really unsafe. There's lots of writeups about soft fork safety--see the BIP9 and BIP8 documents for a starter, and the discussion of activation requirements back in the 2014-2016-ish timeframe
03:09 < ariel57> No worries I've read the BIPs. If a 51% false signals and then backs out they lose all blocks during LOCKED_IN. What you're saying is no different than 51% miners going back 100 blocks and doing a reorg.
03:11 < ariel57> That's something that's always available. Not a new capability caused by this proposal
03:13 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
03:15 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
03:22 -!- ariel57 [d062df66@208.98.223.102] has quit [Quit: Connection closed]
03:23 -!- ariel83 [d062df66@208.98.223.102] has joined ##taproot-activation
03:30 < ariel83> Your explot depends on 25% of miners being apathetic and not upgrading. If after a year of activation so many miners haven't upgraded then they are a liability because they are complicit in the 26%'s false signaling attack. It's not much different than all 25%+26% of them conspiring to do a big reorg.
03:40 < ariel83> The big difference between this proposal and the 2014-2016 activation threshold discussions is that with this proposal there is a long period for miners to *decide* to upgrade or not upgrade. Any miners not wanting to be complicit in an attack had no reason to not upgrade during a year.
03:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
04:08 -!- ariel83 [d062df66@208.98.223.102] has quit [Quit: Connection closed]
04:09 -!- ariel30 [d062df66@208.98.223.102] has joined ##taproot-activation
04:12 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-jljxbfujiusanifg] has quit [Remote host closed the connection]
04:40 -!- ariel30 [d062df66@208.98.223.102] has quit [Quit: Connection closed]
04:43 -!- Teleportando [8eb30758@d142-179-7-88.bchsia.telus.net] has joined ##taproot-activation
04:56 -!- jtimon [~quassel@90.166.158.146.dynamic.jazztel.es] has joined ##taproot-activation
04:58 < jtimon> how can people be against bip8(true) but in favor of flag day? I really don't get it
04:58 < jtimon> since my arguments on the mailing list seems to be ignored, I guess I'll try to debate here
04:59 < jtimon> unless you believe miners should decide the rules, bip8(false) makes no sense. it is just bip9. it's not using bip8 at all
04:59 < belcher> jtimon the main objection seems to be that bip8 incentivizes brinksmanship
04:59 < belcher> see my email called "making the case for flag day" where i write about this argument
04:59 < jtimon> people against taproot should do a patch that forks if it gets signaled for activation, not settle for a bip8(false)
05:00 < jtimon> brinksmanship? what is that?
05:00 < belcher> its what happened in 2017
05:00 < belcher> "upgrade to this or we'll blow bitcoin up"
05:00 < jtimon> many things happened in 2017, can you be more specific?
05:01 < belcher> the UASF movement in 2017 worked so well because much of the regular economy was running the bip9 activation which allowed for miner-activation of segwit
05:01 < jtimon> belcher: people can claim that whatever activation we use for taproot. you mean someone doing a nyc kind of thing using bip(true) too, right? my first comment on activation explicitly contemplates that possibility
05:01 < belcher> so if the UASF were successful it would give segwit to everyone in the economy, not just people who upgraded to their own UASF client
05:02 < belcher> now the downside of that was the risk of a chain split
05:02 < belcher> hence "upgrade to this or we'll blow up bitcoin"
05:02 < belcher> and theres a strong current in bitcoin which wants to take things safe and conservative, so they are against that kind of risk and therefore are against MASFs which allow UASF brinksmanship looks like
05:03 < jtimon> if everyone does bip8(true) there's no risk of split, why would anybody chose bip8(false) to poptentially cause a split? that argument is circular
05:03 < belcher> well yeah if everyone agreed there would be no split, thats the whole point isnt it
05:03 < belcher> it everyone agreed with bip8(false) or flag day there would also be no split :)
05:03 < jtimon> again bip8(false) is just bip9 again, I thought we acknologed bip9 was flawed already
05:03 < belcher> apparently not
05:04 < jtimon> if anyone agrees there is not split -> the split cannot be an argument in favor of bip8(false) and against bip8(true)
05:04 < AaronvanW> jtimon: LOT=true could still cause problems (reorgs) for non-upgraded nodes, if too many miners are too late to upgrade.
05:04 -!- ariel25 [d062df66@208.98.223.102] has joined ##taproot-activation
05:05 < jtimon> AaronvanW: how could LOT=true cause reorgs if nobody does bip8(false)?
05:05 < jtimon> that sounds like the part I may be missing
05:05 < ariel25> LOT=true threatens unupgraded nodes by doing big reorgs on them
05:06 < jtimon> ariel25: in a way LET=false doesn't? I don't understand
05:06 < ariel25> That's right. But like you say LOT=false allows a miner minority to cancel activation
05:07 < jtimon> to non upgraded nodes bip8(false) and bip8(true) look just the sme on activation
05:07 < jtimon> ariel25: which brings us back to the question: why would anybody chose bip8(false)? what is the supposed advantage?
05:08 < jtimon> all I hear is "it is not forced" kind of nonsense
05:08 < ariel25> It isn't an advantage it's a tradeoff.
05:08 < AaronvanW> jtimon: if >50% of miners don't upgrade, LOT=true nodes fork off into their own minority chain. Non-upgraded nodes follow the longer chain created by non-upgraded miners. But then the LOT=true chain overtakes the non-upgrded chain (eg. because more miners upgrade), and the non-upgraded chain is reorged away.
05:09 < jtimon> ariel25: a tradeoff is compromosing in some disadvatages to get some advantages. what advantages do we get with bip8(false) you mean a compromise with people who don't want taproot? no, it's not.
05:09 < jtimon> again, people who don't want taproot should simply explicitly forbid chains which signal its aactivation
05:10 < ariel25> That's the bip8(false) advantage. That there won't be a chain split. The disadvantage is that it can be easily cancelled
05:10 < jtimon> if there are people who don't want taproot a split is unavoidable, but it can be at least a clean split with only 2 chains
05:11 < belcher> there isnt anybody who doesnt want taproot or is neutral to it
05:11 < jtimon> ariel25: that's not an advantage of bip8(false), with bip(false) there can be split if nobody choses that just the same as the other way around.
05:11 < belcher> the disagreement isnt about taproot itself but the activation method
05:11 < ariel25> I much more like Simple Majority activation where Taproot activates if either 95% signals for a period of one year and then after a year the threshold drops to 51% for a MUST_SIGNAL period
05:12 < jtimon> belcher: then it is not compromising with people who oppose taproot, then it has to have some advantage
05:12 < belcher> ariel25 the p2sh soft fork used a 55% threshold but that produced chain splits for the next few months
05:12 < belcher> hold on ill find you a link ariel25
05:12 < belcher> ariel25 https://www.reddit.com/r/Bitcoin/comments/34mrtj/eli5_why_is_peter_todd_important_and_why_do_some/cqxfkdh/?context=1
05:12 < ariel25> This is different though
05:13 < jtimon> again, all the supposed advantages of bip8(false) seem based on misconceptions or logical fallacies
05:13 < ariel25> The 95% leadup allows miners to upgrade well into high percentages
05:14 < jtimon> ariel25: bip8(true) allows that too. remember the advantage of bip(false) has to be something that isn't also true for bip8(false)
05:15 < ariel25> Bip8(false) can't cause a chain split and bip8(true) can. That's the advantage. The disadvantage is that it can be cancelled
05:16 < darosior> jtimon: "all the supposed advantages of bip8(false) seem based on misconceptions or logical fallacies" -> there is more nuance to this though. A lot of us who argued in favour of *starting* with LOT=false were not against using LOT=true should it be necessary. I personally believe using our last-resort deterrent (uasf) as a demonstration of force
05:16 < darosior> is clumsy and would do more harm than good.
05:16 < AaronvanW> but that cancelation can be overruled by users.
05:16 < belcher> and just because an activation didnt succeed once doesnt stop us trying again
05:17 < ariel25> No it can't just automatically be overridden by users. It's not that easy as you say
05:17 < belcher> people have gotten it into their heads that you can only attempt to activate once, which isnt true
05:17 < ariel25> bip8(true) can cause chain splits
05:17 < AaronvanW> ariel25: how hard or easy it is depends in large part on how hard or easy developers want to make it for users to do so.
05:19 < ariel25> No even if developers are all for it you never know if a social movement is going to succeed. bip8(true) can cause chain splits if a UASF fails
05:20 < AaronvanW> sure but you agree developers could make it a lot easier, right?
05:20 < AaronvanW> it'd always be "the hard way" compared to miners just activating.
05:21 < ariel25> Yes sure the bigger the movement the more likely it will succeed but it doesn't change that bip8(true) can cause chain splits and bip8(false) can't
05:24 < AaronvanW> I could make the case that developers making it harder for users to succeed ultimately increases the chance of chain splits because users will grow impatient and try it even without the best possible tools. (tools that could have been provided by devs, eg. a configuration switch in Bitcoin Core.)
05:24 < ariel25> Personally I think a Simple Majority activation with a 95% threshold for one year and then 51% for a MUST_SIGNAL period doesn't have the disadvantages of either LOT=true or LOT=false
05:25 < belcher> ariel25 what do you say to the argument that p2sh activation which used 55% threshold caused loads of chain splits, and therefore your simple majority thing would also cause chain splits
05:25 < belcher> i told you this a few minutes ago but you seem to have ignored it, you just said "this is different though"
05:26 < belcher> incorrectly saying bip8(false) cant cause chain splits, but it can if the threshold is 50%
05:27 -!- meshcollider [meshcollid@gateway/shell/ircnow/x-ddmqaipvovndqpkj] has joined ##taproot-activation
05:30 < ariel25> Every proposal is vulnerable to miners SPV mining. I don't see why that's a new problem here
05:32 < belcher> its not about SPV mining
05:33 < belcher> but about the statistics of mining, even if you had 60% hash power you could still get invalid chains with lengths of 5 or 6 confirmations much of the time just by chance
05:36 < ariel25> My understanding is that the reason only 60% hash power was enforcing the rules was because of SPV mining or false signaling
05:38 < ariel25> That's why I'm saying that hey if 40% hash power isn't ready to enforce rules then it doesn't matter what activation you use.
05:38 < jtimon> darosior: what is the advantage of "starting with bip9, then perhaps move to bip8(true)"?
05:38 < belcher> hash power doesnt enforce the rules, it just activates them, full node wallets (i.e. the economy) enforces the rules ariel25
05:39 < jtimon> darosior: see? this "demonstration of force" argument is based on the wrong assumptions that miners should decide the rules
05:40 < darosior> jtimon: miners can not decide the rule if there is no activation logic coded in the first place...
05:40 < jtimon> bip148 could have done more harm that good, because another activation was already widely deployed and it was rushed. starting with bip9 sets us up for the same thing being repeated, perhaps next time we're not so lucky
05:40 < ariel25> I know but here you seem to be saying that the activation method needs to be concerned about months of reorgs due to false signaling? That's not something that an activation method can fix
05:41 < belcher> not due to false signalling, just due to not signalling at all
05:41 < jtimon> darosior: miners have no say in what the rules should be. we users decide. and bip8(true) it's also better for those who oppose taproot if anyone, because it makes it easier for them to coordinate too
05:41 < belcher> as i said in the p2sh soft fork 45% of miners just didnt signal when the threshold was crossed
05:42 < ariel25> The threshold was too low.
05:42 < darosior> jtimon: (re bip148) we are both prepared for this technically (no rushed specification of the forced activation) and as a community (most users know that we may have to force activation if it turns out to be necessary)
05:43 < ariel25> What I'm suggesting is completely different than just setting 51% threshold. Which is that I suspect you think I'm suggesting
05:43 < jtimon> AaronvanW: providing an option for bip9 vs bip8 makes no sense. nobody benefits from that. what would perhaps make sense would be to provide a pro-taproot option (bip8) and an anti-taproot option (forbids chains signaling activation)
05:43 < belcher> ariel25 what are you suggesting then?
05:44 < belcher> and how is it different
05:44 < jtimon> ariel25: how does a 51% thereshold make any sense? that's way more risks of unintented forks. and what does it help with? "forcing miners less"? miners have no say in the rules!
05:44 < AaronvanW> jtimon: I think it makes perfect sense, Rusty explains it here: https://rusty.ozlabs.org/?p=628
05:45 < belcher> AaronvanW isnt it the same as BU's configurable consensus rules
05:46 < ariel25> belcher: having 95% for a year to allow time for miners to upgrade. Then at the end of the year threshold drops to 51%. I'm expecting that at the moment the threshold drops. A much higher number than 51% would be upgraded. The say 88%
05:46 < belcher> someone setting a config flag differently to everyone else could lose money because they end up on another coin]
05:46 < jtimon> "Giving every group a chance to openly signal for (or against!) gives us the most robust assurance that we actually have consensus" bip9 is not giving users the option to be against, this is based on faulty assumptions
05:46 < belcher> also, rusty's plan of having users do forced-signalling UASFs is opposed by people like bluematt, because of the risk to the network
05:47 < AaronvanW> belcher: BUs configurable option was supposed to activate hard forks, which could in turn be reorged away. this configuration would activate soft forks, which can't be reorged away.
05:47 < belcher> AaronvanW even so they are consensus failures, i.e. if you're on another chain you cant send "bitcoins" to someone else using "bitcoin"
05:48 < jtimon> bip9 (aka bip8(false)) doesn't give you the option to be against. I'm all for giving users that option, but bip8(false) ain't it
05:48 < belcher> btw i found an old thread from the bip148 era, worth a read https://old.reddit.com/r/Bitcoin/comments/6d7dyt/a_plea_for_rational_intolerance_extremism_and/
05:48 < belcher> quotes:
05:48 < darosior> jtimon: i believe that you are also overlooking an aspect of hardcoding a rule change in the reference implementation. I strongly believe that a lot of us would *not* run such a client (it was said there and also said to me outside) and it would create more chaos. Let's just use BIP9 which is optimal for the happy path activation, should the path
05:48 < darosior> not be happy we can force the activation. Sure, this gives miners a **temporary** veto but who said changing Bitcoin should be easy ? It seems to me that a blunt start with LOT=true is just "move fast and break things" which is not how i think Bitcoin should evolve, at all.
05:48 < belcher> "The risk profile of supporting BIP148 vs supporting the legacy chain in a chain split scenario is skewed in favor of BIP148. Much of the risk is borne by the network as a whole, rather than by the BIP148 supporters themselves."
05:49 < jtimon> it's only giving users the option to potentially cause forks between groups of users that both want taproot
05:49 < belcher> and this meme https://imgur.com/a/uOq2k
05:49 < AaronvanW> belcher: users can always fork off. that not something devs can stop.
05:49 < belcher> with the snake holding a grenade saying "i swear to god ill kill us all if you fuck with me", the grenade says bip148
05:49 < AaronvanW> *can't
05:49 < harding> belcher: lol
05:49 < jtimon> there should be only one fork between people who want taproot or don't care about it and those who actively oppose it (if anyone)
05:50 < jtimon> why would you want to let 2 groups who both want taproot to end up in different chains?
05:50 < belcher> i suppose interesting to see how UASF worked well in 2017 but stored up problems for later that we're dealing with today
05:50 < AaronvanW> jtimon: BIP9 still allow users to not upgrade at all.
05:50 < jtimon> but the rules of the chain wiull still be upgraded whether they upgrade or not
05:51 < belcher> harding dont shoot the messenger :)
05:51 < AaronvanW> jtimon: not true
05:51 < jtimon> and again bip(true) allows that too
05:51 < AaronvanW> users enforce the rules
05:51 < AaronvanW> if users don't upgrade, there are no new rules
05:51 < jtimon> what do you mean not true? if the change gets activated the rules are changed in my chain whether I validate those rules or not
05:52 < AaronvanW> if users don't pgrade, the change isn't activated
05:52 < jtimon> if some users validate the new rules and some do not upgrade, I mean
05:52 < AaronvanW> then some users may end up on a minority chain. that's their choice and risk to take.
05:52 < jtimon> but again, we're discussing things that don't work differently in bip8(false) vs bip9(true). I'm stil lwaiting for some positive claim about bip8(false) that is not also true for bip8(true)
05:52 < harding> jtimon: if too few people upgrade, then a block violating the rules can cause a chain split as some nodes accept it and some don't.
05:53 < jtimon> but a solid one, not a vague "demosntration of power" one assuming miners have a say in the rules
05:53 < jtimon> harding: that's true for both bip9 and bip8(true)
05:54 < harding> jtimon: LOT=false only activates if miners have signaled their intention to help keep us all on the same chain.  LOT=true will activate for its users even if it will put its users on a minority chain.
05:55 < jtimon> harding: I know. the question is, has bip8(false) any advantage over bip8(true)? which advantage would that be?
05:55 < harding> jtimon: if you know why did you say just moments ago, " I'm stil lwaiting for some positive claim about bip8(false) that is not also true for bip8(true)"?
05:56 < jtimon> are you conting not doing changes because miners oppose them or don't care enough as an advantage? because I see it as a clear disadvantage
05:56 < jtimon> harding: because I know how it works, but I don't believe bip8(false) has a single advantage over bip(true)
05:57 < jtimon> because I'll I've heard so far in favor of bip8(false) were flawed arguments
05:57 < AaronvanW> jtimon: from Rusty's post: "Developers should not activate. They’ve tried to assure themselves that there’s broad approval of the change, but that’s not really a transferable proof. We should be concerned about about future corruption, insanity, or groupthink. Moreover, even the perception that developers can set the rules will lead to attempts to influence them as Bitcoin becomes more important. As a (non-Bitco
05:57 < AaronvanW> in-core) developer I can’t think of a worse hell myself, nor do we want to attract developers who want to be influenced!"
05:57 < jtimon> but perhaps there's a reasonable one I've missed
05:57 < harding> jtimon: what was flawed about my argument?
05:58 < jtimon> AaronvanW: again, this option doesn't give users any choice. and anti-activation option would do. but bip8(false) is not it
05:58 < harding> The argument that it's safer for users to be on a chain shortly after activation that miners have signaled they intend to prevent from splitting?
05:58 < AaronvanW> jtimon: again, users ultimately always have the choice not to upgrade.
05:58 < belcher> AaronvanW if developers cant activate, and miners dont get the chance to activate, and users wont activate then we wont get taproot... looks like we'll just have to accept that :\
05:59 < jtimon> harding: what is your argument? you just described how it works. perhaps my question "are you counting..." is relevant? can you answer it, please?
05:59 < belcher> "users" nowadays mostly means exchanges
05:59 < ariel25> belcher there's nothing that can be done about 45% of hash power not enforcing newly activated rules regardless of how they were activated. If the 45% hash power likes losing money by mining orphaned/invalid blocks then so be it. We can't let their apathy prevent Taproot activation. The Simple Majority proposal gives them as much chance as possible
05:59 < ariel25> for that 45% hash power to upgrade. If they were too lazy then that's on them.
05:59 < jtimon> AaronvanW: not upgrading doesn't allow users to oppose the changes
05:59 < belcher> ariel25 its also the rest of us because we lose part of our hash power security
05:59 < jtimon> if you're against taproot and taproot is activated, not validating it is of not help to you
06:01 < jtimon> if you oppose the change, you want to end up in a different chain with the other users who oppose the chain
06:01 < jtimon> swho oppose the change, sorrry
06:01 < ariel25> belcher if they don't want to dump asics down the drain they'll upgrade. Simple Majority proposal gives them as much chance as possible
06:01 < belcher> in reality it looks like 89% of hash rate said it would activate taproot anyway
06:02 < harding> jtimon: I would certainly like to have the support of miners.  If we try to activate taproot without the support of the majority of miners, they can censor taproot transactions, making it useless unless we perform a PoW change, which is a radical step I'd prefer not to take.  That said, if we had to do it, we'd have to do it.
06:02 < belcher> our problem isnt that hashrate doesnt support this
06:02 < harding> jtimon: but that's not the argument I was trying to make.
06:02 -!- eoin [6d4f18ef@109.79.24.239] has joined ##taproot-activation
06:03 < ariel25> I agree. I think 89% will be signaling when threshold drops to 51%
06:03 < harding> My argument is that it's safer for users in the weeks after an activation if it was activated with the support of an overwhelming majority of hashrate because the miners will either prevent or quickly heal any chainsplits.
06:04 < belcher> ariel25 so what problem does your proposal solve? if we have information anyway that 89% said they would signal
06:06 < ariel25> It solves the ability to set initial threshold to a safe 95% instead of bip8(false) with a 88.99% threshold or less
06:07 < AaronvanW> jtimon: "if you're against taproot and taproot is activated, not validating it is of not help to you" <- 1) it's not activated if users don't upgrade. 2) is most users do upgrade, yes now you're on a Taproot chain which you're not fully validating yourself. But that's true for any soft fork mechanism we choose, isn't it?
06:08 < ariel25> belcher: If you're more in favor of bip8(true) then my proposal solves the ability to cancel if a bug is found
06:08 < ariel25> It solves problems from both the true and false proposals
06:10 < ariel25> It also solves bip8(true) antagonistic nature because a miner majority is needed (at minimum) instead of completely ignoring them
06:15 < ariel25> belcher the worst possible outcome with my proposal is that 49% doesn't signal and we get reorgs for a while until the 49% decide to stop losing money. But that's way worse than the worse outcomes of bip8(true) which is a chain split or bip8(false) which is a veto and then the need to run bip8(true) anyway.
06:16 < AaronvanW> jtimon: if you want to give users an explicit option to counter-soft fork so they opt-out of Taproot entirely and end up on a different chain, I don't think I'd have a problem with that.
06:17 < AaronvanW> jtimon: but that could still result in big rorgs for non-upgraded nodes.
06:17 < ariel25> I meant to say "but that's way *better* than the worst outcomes of bip8"
06:18 < belcher> the safest outcome of all is not soft fork attempt at all,
06:18 < belcher> so saying "proposal X is safer than proposal Y" still doesnt convince the hardcore safety conservatives, because they can always say "well lets do nothing at all"
06:19 < belcher> (to be clear, i prefer taproot, so dont shoot the messenger, but if you're going to make proposals they have to make sense if they are to get consensus)
06:19 < ariel25> That's not the worst outcome of not activating anything. The worst outcome of that is another bch. So my proposal is better than that
06:20 < belcher> why is another bcash so bad? that altcoin is irrelevant
06:21 < belcher> if people want to switch to an altcoin to get privacy improves but lose the network effect of bitcoin there are far better altcoins than bitcoin-with-taproot
06:21 < AaronvanW> belcher: "no soft fork attempt at all" is not a realistic option imho, because anyone if free to attempt anything they want, and some obviously will.
06:21 < belcher> AaronvanW ill rephrase to "no soft fork attempt which a big part of the economy runs"
06:22 < ariel25> No soft fork at all is worse than my proposal
06:22 < belcher> and you need that to genuinely add taproot to bitcoin... if not then money in taproot addresses could be stolen and sent to exchanges which dont enforce the taproot rules
06:22 < ariel25> You don't want to split the community my proposal's worse case can't split up the community
06:23 < AaronvanW> belcher: "big part" of the economy is a fuzzy definition.
06:24 < ariel25> The worst it can do is small reorgs due to stubborn or extremely lazy miners.
06:24 < ariel25> But the community stays together
06:24 < belcher> for example, if kraken, coinbase.com, bitstamp, and some exchanges in russia or iran dont enforce taproot then someone could steal coins in taproot addresses and send them to one of those exchanges to sell and get other money in exchange
06:24 < belcher> meaning nobody will trust their money to taproot addresses, meaning we de facto dont have taproot
06:25 < belcher> sure you can make your own little community which enforces taproot, but it also loses the network effect of bitcoin (and if you're willing to do that you may as well go use an altcoin)
06:25 < ariel25> That's temporary until the minority of miners decide to stop losing money
06:25 < jtimon> AaronvanW: right, non upgrades nodes would go with the most work chain, so that could result in some switching from chain a to chain b until it's more or less clear which one has the most work. assuming there's an anti chain at all. but I don't see how things can be done better for unupgraded users. my point is the bip8(false) option only provides a false sense of choice. there the choice is not "do you want this change, yes
06:25 < jtimon>  or not?" the choice is "do you want to give miners veto power over this change yes or not?"
06:26 < belcher> AaronvanW hopefully what i said above clarifies what i meant by "big part of the economy" ?
06:26 < AaronvanW> belcher: the flip side of that argument is that the Taproot UASF chain could always reorg the non-Taproot chain away. Would you really trust getting paid on that chain?
06:26 < jtimon> I don't see how giving users the option to give miners veto power is an advantage at all
06:27 < jtimon> belcher: sure, the safest option is not to change anything, but that sucks. forget about taproot, this conversation should be simply generalized to any consensus rule change proposal
06:27 < belcher> AaronvanW you might be right... let me think
06:27 < jtimon> AaronvanW: no, the anti-taproot chain would never reorg into the taproot one if the software is actualyl giving a choice to users as a propose
06:27 < jtimon> as I propose
06:28 < belcher> AaronvanW the other flip side is that the taproot UASF chain might have very slow blocks, so you could ask would you really use it? imagine trading bitcoin for cash in person but instead of waiting 10 minutes for a confirmation you have to wait 3 hours
06:28 < belcher> although, today with such high fees most people probably wait a long time for confirmations anyway if they pay low fees
06:29 < AaronvanW> jtimon: right, I wasn't talking about your opt-out soft fork idea.
06:29 < ariel25> belcher I think we would all agree that if there is considerable hash power not wanting to enforce taproot rules then exchanges shouldn't be trusting the feature until said mining minority gets in line. In the meantime those miners will be getting reorged and losing money. This is all regardless of activation
06:31 < jtimon> AaronvanW: so you agree now that giving users the option of bip9 vs bip8 is not really giving them anything. just the power to let miners veto the change and the ability to ge split from chains also in favor of the change
06:31 < jtimon> people are talking as if not giving miners veto power over changes was equivalent to "developers imposing things", it is not. that's a false assumption
06:32 < harding> jtimon: asking miners to activate something is not the same as giving them veto power over it.
06:32 < jtimon> bip8(false)/bip9 gives them veto power
06:32 < AaronvanW> jtimon: I'll need to think about your opt-out soft fork idea a bit.
06:33 < ariel25> jitmon the Simple Majority proposal wouldn't give veto power and it also avoids chain split risks
06:33 < harding> jtimon: no it does not.  If it did, we wouldn't have segwit.
06:33 < jtimon> ariel25: I think there are many arguments against the simple majority idea, and, yes, it still gives miners veto power
06:34 < jtimon> harding: really? uasf had nothing to do with segwit's activation?
06:34 < belcher> wow this channel lol
06:34 < jtimon> this shouldn't even be controversial, of course bip9 gives miners veto power
06:34 < harding> jtimon: UASF certainly did have something to do with segwit's activation.
06:34 < ariel25> No it doesn't give them veto power. How so? jtimon
06:35 < jtimon> it is obvious bip9 gives miners veto power: if miners don't signal it, it won't be activated.
06:35 < belcher> if bip9 gives miner veto power, and in 2017 miners "used that veto" on segwit, then why do we have segwit today?
06:35 < jtimon> ariel25: simple: if users want the change but miners don't, the change won't happen
06:35 < ariel25> Unless you think 51% against you is a veto lol
06:36 < jtimon> belcher: thety backdown out of fears od uasf and they DID NOT used their veto power, obviously
06:36 < jtimon> if they had used it, bip148 would have caused a fork
06:36 < AaronvanW> belcher: I think futures markets would signal which chain will be more valuable before it ever gets to a split. this basically avoids the hard problem of having to figure that out in a context of slow blocks, replay attacks, etc.
06:36 < jtimon> ariel25: what if 100% users are for the change but 100% miners  are against?
06:37 -!- harding [quassel@newmail.dtrt.org] has left ##taproot-activation ["I need better hobbies than debating about what happened in 2017"]
06:37 < jtimon> does it get activated yes or no?
06:37 < jtimon> AaronvanW: I don't care about which chain is more valuable to others, I care about being able to chose which chain is more faluable FOR ME as a user
06:37 < belcher> AaronvanW its worth a try i suppose
06:39 < ariel25> jtimon if 100% of users are for the change and 100% of miners are against then the change is way too controversial . Something like canceling block rewards
06:40 < jtimon> how is it controversial if 100% of the users agree? that's the opposite of controversial
06:40 < ariel25> jtimon in that case users need to do a hard fork anyway to change PoW protect themselves from disgruntled miners anyway.
06:41 < jtimon> if the current miners don't want to mine the chain with the change every user wants, then other miners who want the reward wil lcome
06:41 < jtimon> ariel25: I disagree
06:41 < AaronvanW> jtimon what would you think of a cpnfiguration with three options. 1) default, LOT=false 2) LOT=true 3) opt-out (anti-LOT=true)
06:41 < jtimon> let's say the change is to reduce the subsidy
06:41 < ariel25> It's controversial because it's not a blockchain if there are no miners
06:42 < jtimon> do we need to hardfork pow to reduce the subsidy just because some miners won't lkike it? no, of course not
06:42 < jtimon> AaronvanW: I still don't see how option LOT=false helps with anything.
06:43 < ariel25> Yes you 100% will need to do a hard fork so old miners can't attack you
06:43 < jtimon> AaronvanW: why would you want different groups of users who all want the change to end up in different chains?
06:43 < AaronvanW> jtimon: no perception of devs deciding
06:43 < jtimon> ariel25: I guess we will just have to agree to disagree
06:44 < ariel25> You think old miners are going to roll over if you reduce the subsidy? jtimon
06:44 < jtimon> AaronvanW: only option 3 can save you from that, LOT=false doesn't help with that at all. devs allow you to decide whether you want miners to have veto power or not? that doesn't sound like a real choice to me
06:45 < jtimon> ariel25: I think they'll keep mining the new chain if 100% of userrs are in it, yes
06:45 < jtimon> what do you think they will do in that case? waste millions in electricity for revenge?
06:46 < jtimon> I don't think so
06:46 < AaronvanW> jtimon: defaults matter when it comes to that perception
06:46 < ariel25> No they won't they'll attack the chain close the door and get jobs in data centers.
06:46 < jtimon> AaronvanW: ok, but I still don't see how LOT=false gives users any real meaningful choice.
06:47 < AaronvanW> they can switch to LOT=true
06:47 < AaronvanW> that's the choice
06:47 < ariel25> What makes you think you can force people around like that? jtimon
06:47 < jtimon> ariel25: attacking the chain costs a lot of money. why would they do that if they're going to quit mining anyway? you're assuming miners are economically irrational
06:49 < jtimon> ariel25: miners are just employees here. they work for us, the users. imagine a school agrees to paint the bus orange but the bus driver doesn't like it. well, if he doesn't like the bus being orange, he can resignate and drive an orange bus or find another job. the school can hire another bus driver, no problem
06:49 < ariel25> jtimon they pay for electricity in advance. They can and probably will attack. And likely sell and make profit shorting. Please be more realistic. You can't just screw your miners like that
06:49 < jtimon> miners don't decide the rules, I don't see why they should have veto power over changes
06:50 < AaronvanW> that's why it should be easy to overrule the veto jtimon
06:50 < AaronvanW> as easy as possible imo
06:50 < jtimon> ariel25: so we can't never reduce the subsidy because miners wouldn't like it? sorry, I just disagree
06:51 < jtimon> AaronvanW: the simplest way to overrule the veto is overruling it from the start by not giving them bveto power at all
06:52 < ariel25> jtimon it doesn't matter whether you agree. What matters is that your chain can get destroyed if you screw the miners to much.
06:53 < AaronvanW> jtimon: yes but that can't be done without the perception of "devs decide".
06:53 < ariel25> Your view seems so extreme to me to think you can literally do anything without consequences
06:54 < jtimon> AaronvanW: I disagree. first of all, that perception is unjustified and, secondly, the LOT=false doesn't help removing that perception unless you assume people are stupid. only the option to opose the change could reasonably change that perception
06:55 -!- roconnor [~roconnor@host-104-157-194-235.dyn.295.ca] has joined ##taproot-activation
06:56 < roconnor> People have argued that the mere perception of devs deciding the rules put their lives in danger.
06:57 < jtimon> unless of course devs want to perpetuate the misconception that is neither devs nor users but miners who decide the rules
06:57 < jtimon> roconnor: well, people argue lots of stupid things. devs don't decide the rules
06:57 < roconnor> In the last 200 days, the argument that this percetpion is both unjustified and LOT=false won't remove this perception have been argued and appear to not have swayed that position.
06:57 < jtimon> it is free software, remember?
06:58 < roconnor> and while you can keep trying to sway that opion, I'm not optimisitic it will change in the next 200 days.
06:58 < jtimon> people claiming such things should just be pointed to a richard stallman talk or something
06:58 < roconnor> activation code is transient and thus doesn't have to be the best activation method.  Instead we need an activation method that is broadly concerned acceptable.
06:58 < AaronvanW> jtimon: that misconception is solved by giving users the option to overrule miners. 2017 showed that clearly. users still celebrate "bitcoin independence day".
06:58 < jtimon> roconnor: but with LOT=false it will?
06:59 < jtimon> AaronvanW: no, the option you're giving is really the option to give miners veto power
06:59 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds]
07:00 < AaronvanW> veto power that can easily be overruled, in turn only showing the true power of users. but anyways we're going in circles. getting some fresh air.
07:00 <@michaelfolkson> To attempt to summarize, there is no opposition to the Speedy Trial proposal here right? It is just that it isn't an individual or two's top choice?
07:01 < ariel25> Yes there is
07:01 < roconnor> With ST, the most damage the miners can do is delay things by 3 months, and not even that, becuase I don't think it would push the activation date of any UASF movement by even 3 month.
07:01 <@michaelfolkson> Can you summarize exactly what that opposition to Speedy Trial is please ariel25? Sorry I'm trying to do 5 things at once
07:02 < jtimon> AaronvanW: not so easily, we were lucky we didn't have a fork with bip148. how does giving users the option to give miners veto power (LOT=false) make users feel they are more in control than not giving that option? that's the part I'm missing
07:02 < ariel25> With a short timeframe it's unlikely the 95% threshold will be reached so its setting up LOT=false for failure. Then we'll be back to arguing
07:02 < roconnor> ariel25: 90%
07:03 <@michaelfolkson> ariel25: Right, 90 percent. And on taprootactivation.com we have 90 percent approx of mining pools signed up to the Taproot upgrade
07:04 < AaronvanW> BIP148 was rushed, too many people didn't understand the risks, there was no good way of signaling users support (best we had were hats on twitter profile pics). and despite all that, it still worked. now imagine making something like that much easier to do (eg configuration switch instead of alt client), with plenty of lead time, proper user signaling though futures markets. etc
07:04 < roconnor> also we don't have to stop arguing.
07:04 < ariel25> Sorry 90%. But even that is maybe too high since only 89% miners have verbally supported
07:04 <@michaelfolkson> ariel25: I'm also in the process of trying to get mining pool feedback on this proposal.
07:04 < jtimon> roconnor: yeah, perhaps more importantly, that. the issue keeps lingering forever causing confusing among users and devs
07:05 < roconnor> ariel25: okay, but it might not be to high, and we can still argue even while ST is running.
07:05 <@michaelfolkson> ariel25: I don't want to put words in your mouth but it sounds like you're an ACK, you'd just prefer a lower threshold.
07:06 <@michaelfolkson> ariel25: But you can use your own words on this gist: https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f
07:06 < jtimon> AaronvanW: yes, we were very lucky it worked. I don't think we should push our luck with more experiments. what we learned (cough, some of us already knew) is users decide. so maintaining this mining veto thing makes no sense imo
07:06 <@michaelfolkson> Feel free to NACK if you oppose Speedy Trial. That is absolutely fine
07:07 < jtimon> it is users and not miners should be given tools to oppose the proposals
07:07 < roconnor> jtimon: you argument is resolving the activation procedure in all possible scenarios is more important than activing taproot?
07:07 < jtimon> michaelfolkson: I nack anything LOT=false, for the reasons exposed
07:08 < AaronvanW> jtimon: I think our disagreement boils down to the "perception of devs deciding" part. I think default matter in that regard. but now I'm really going to get some fresh air, bbiab :)
07:08 <@michaelfolkson> jtimon: Ok please post on the gist with an explanation ideally. I don't want to do your argument a disservice
07:09 < ariel25> michaelfolkson I NACK because if the signaling period is too long it allows time for a UASF and if it's too short then the chance of success drops.
07:09 < jtimon> roconnor: it's not about taproot, it's about changing in general. and it's not my proposal, we don't even need to code that. users can code that themselves or find someoen to do it for them. my main point is LOT=false doesn't give users any meaningful choice. it doesn't help get the proposal activated (be it taproot or any other) and I think I've dismantled all arguments in favor  of LOT=false, perhaps I missed some
07:09 < jtimon> arguments in favor?
07:10 <@michaelfolkson> ariel25: I have not heard a single supporter of UASF argue for trying a UASF during a Speedy Trial deployment. If you find someone, please let me know
07:10 <@michaelfolkson> (let us know0
07:11 < jtimon> that proposal is just for the people who argue "LOT=true gives the perception is devs but not users who decide". if we're  really worried about that perception, that's how you solve it, not with LOT=false. LOT=false does nothing to solve that perception unless it is used in combination with irrational arguments
07:11 < roconnor> clearly ST "helps get the proposal activated" in that there exists a scenario that it gets activated in.
07:12 < jtimon> roconnor: sorry, what? how does LOT=false compared to LOT=true help activation again?
07:12 <@michaelfolkson> But I'll repeat if you have made up your mind please post on that gist. That would be helpful to all of us. Thanks
07:12 < roconnor> I'm not arguing that LOT=false is better than LOT=true.  We don't need the best activation method.  We need one that will pass Core review.
07:13 < jtimon> roconnor: well, I think if core review is rational, LOT=true should pass it
07:13 < roconnor> If you think it will pass Core review I recommend making a PR.
07:14 < roconnor> I would probably support it, but I strongly doubt it will pass review.
07:14 < roconnor> at this stage at least.  Maybe after a failed ST attempt it would have a better shot.
07:14 < ariel25> michaelfolkson hehe sure there doesn't seem to be anyone for UASF right now but I'm thinking long term. I do agree that the biggest selling point of ST is that luke-jr thinks it's too risky to attempt a UASF but I don't think that makes the proposal any better today or any better for future soft forks.
07:15 < roconnor> again, not looking for the best activaiton method.  It doesn't have to be the best.  It just has to be acceptable.
07:16 < jtimon> roconnor: I have not followed the taproot development process, not even the bip process, all I know about it it's what was known at the beginning. So I don't think I'm the most adecuate person to lead the PR, but I will consider it. certainly I think I can defend the LOT=true vs LOT=false notions in a general sense, independently of taproot
07:17 < roconnor> A consequnce of the desing of ST is that *everyone* thinks there is a better activation method.
07:17 < roconnor> *design
07:17 < ariel25> roconnor I agree
07:17 < jtimon> yeah, I guess it's a pain in the ass to answer to all the "what about x instead" posts, lol
07:17 < roconnor> but when what everyone thinks is a better activation method is all different, it isn't that helpful.
07:18 <@michaelfolkson> jtimon: I do need to go. But Core review has always been a process where if there are 3 PRs (A, B, C), A has a small number of NACKs from contributors (and long term contributors) and B,C have many NACKs from contributors (and long term contributors), the only one that stands a chance to be merged is A
07:18 <@michaelfolkson> I don't know how maintainers would manage the PR process otherwise
07:19 < jtimon> I will consider opening a PR, is there not a PR with LOT=true already? with some coservative timeframe like 2 years or something?
07:19 <@michaelfolkson> There will always be an individual contributor or two who thought say B or C were better. But I don't see a better way personally
07:20 < roconnor> jtimon: step 1 is to get https://github.com/bitcoin/bitcoin/pull/19573 through review.
07:20 <@michaelfolkson> jtimon: There is not, no. And you are welcome to. I would warn you that my personal assessment is that you would be wasting my time (only personal assessment though)
07:21 < jtimon> roconnor: thanks, I guess I'll review that instead then
07:21 < roconnor> Currently achow101 is planning to break that into pieces for easier review.
07:21 <@michaelfolkson> *wasting your time
07:21 <@michaelfolkson> Not wasting *my time ;)
07:21 < roconnor> You might want to wait for that to shake out (today or tomorrow) before deciding how best to proceed.
07:21 < jtimon> michaelfolkson: well, I have free time, perhaps I will. I didn't realize there weren't people already doing it given the discussions
07:23 <@michaelfolkson> Follow roconnor advice for now. You will get NACKs if you open it, I promise you that. Just so you know that going in. I don't want you to come back angry saying you've wasted your time :)
07:29 < ariel25> michaelfolkson have you considered my Simple Majority proposal? 95% threshold for one year (with Taproot signaling would either activate or get to 89%) and after a year the threshold drops to 51%. If signaling is below 51% activation is cancelled (like if a bug is found)
07:29 < jtimon> oh, it looks like luke-jr is already doing a neveractivate option, awesome
07:29 < jtimon> michaelfolkson: sure, I'll get nacks, the questions is what will the arguments behind the nacks be and how well I can answer them, I guess
07:30 < jtimon> ariel25: simple majority means it is very easy to get reorgs and stuff, I would say it's a non starter
07:31 < jtimon> plus what's supposed to be the advantage? miners don't decide the rules, let's stop pretending they do
07:31 < ariel25> It's better than the worst cases of bip8 false or true
07:34 < ariel25> Miners can decide what they mine and if a large majority of them don't agree with the new rules, they can attack the chain. That's the issue with bip8(true) and the "miners don't decide anything" view
07:40 < ariel25> michaelfolkson with the Simple Majority proposal it's unlikely to get reorgs since miners have plenty of time to upgrade. The worst case is small reorgs until the miner minority falls inline. The worst cases of bip8 are much worse. With lot=true the worse case is a chain split and with lot=false is a veto and then attempt flag day or bip8 which at
07:40 < ariel25> worst a chain split. So the advantage of Simple Majority is that at worst it's only reorgs instead of chain splits.
07:42 < ariel25> And Simple Majority at best is better than ST since MASF threshold can be set to a safer 95%
07:43 < roconnor> jtimon: one advantage is supposed to be not giving the appearance of devs deciding conensus rules which could endanger their lives.
07:43 < roconnor> jtimon: I'm not claiming this is or is not reasonable, just what sort of NACKs you are liable to get.
07:43 < jtimon> roconnor: again, only to irrational observers who think miners decide the rules
07:45 < ariel25> roconnor did someone actually threaten a dev?
07:46 < jtimon> giving users the option of giving miners veto power doesn't empower users at all. if you're super worried about perception, then give users the option to be against the change directly
07:49 < jtimon> seriously, if you were against taproot, how does LOT=false help you as a user? and if you're in favor of taproot, same question, how does LOT=false help you as a user
07:49 < jtimon> the answer is LOT=false does never help you as a user whether you're for or against the change
07:51 < ariel25> jtimon yes it does please stop being so extremist
07:51 < ariel25> It doesn't help the discussion
07:52 < AaronvanW> ariel25: fwiw I think Simple Majority is always true, regardless of whether or not it's made explicit in the code. (A simple majority can always orphan non-signaling blocks.)
07:53 < ariel25> AaronvanW I agree
07:56 < ariel25> The problem with lot=false is that this isn't made explicit unless a new client is released. I'm proposing just bundle reality explicitly in one release.
08:01 -!- eoin [6d4f18ef@109.79.24.239] has quit [Quit: Connection closed]
08:07 < jtimon> ariel25: great ad hominem fallacy. how does it help me as a user if I'm for the change? how does it help me as a user if I'm against the change? less insults and morea arguments, please
08:10 < roconnor> jtimon: giving the users the option to be against the change directly runs counter to the faction who have "publicily committed to avoiding divergent consensus rules on the network" which is an entirely different faction you will also have to contend with in Core review.
08:11 < ariel25> jtimon You're just being so extreme. Of course lot=false helps you as a user because it has a chance of activating. You're not arguing in good faith if you say lot=false literally does *nothing* for users.
08:11 < jtimon> roconnor: well, allowin LOT=false does that too. so I guess that faction is just against being worried about vague concerns of false user perceptions
08:12 < ariel25> The ad hominem is well placed if you argue in bad faith
08:12 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has quit [Quit: Lost terminal]
08:12 < roconnor> a three month LOT=false mitigates that concern.
08:12 -!- eoin [6d4f18ef@109.79.24.239] has joined ##taproot-activation
08:14 < jtimon> ariel25: you know what doesn't help the discussion? calling me extremist because you don't know how to answer my questions. the question is obviously "compared to LOT=true". now, put your answer in that context and listen to your own answer. you're saying "giving users the option of chosing LOT=false helps users because LOT=false has a chance of it being activated" as if LOT=true didn't had a chance. do you realise why your
08:14 < jtimon> answer to my question makes no sense?
08:14 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:2075:9321:d3a2:809] has quit [Read error: Connection reset by peer]
08:14 < jtimon> ariel25: I'm not arguing in bad faith, and no, your ad hominems never help any discussion that intends to be rational. please, stop it
08:15 < jtimon> roconnor: w 3 month LOT mitigates what concern?
08:15 -!- ksedgwic [~ksedgwic@192-184-130-48.fiber.dynamic.sonic.net] has joined ##taproot-activation
08:15 -!- cguida [~Adium@2806:2f0:51c1:5cee:55a3:2da7:21ec:b3ad] has joined ##taproot-activation
08:16 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
08:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
08:16 < roconnor> the concern about diveregent consensus rules on the network.
08:16 < jtimon> so does 2 years LOT=true
08:17 < roconnor> Yes, this but that runs into the faction of "the appearance of developers deciding rules puts their lives in danger".  These factions are not the same but they will both be represented in Core review.
08:17 < roconnor> *not necessarily the same people
08:18 < jtimon> well, that second faction is not being rational. if users get wrong perception, we need education, not trying to fool users by telling them "no, look, it's not the devs who decide because it is the miners who decide"
08:19 < jtimon> that's counterproductive
08:19 < jtimon> and arrogant, it's basically thinking "we need to lie to users, because they're dumb and they wouldn't udnerstand"
08:20 < ariel25> jtimon Don't move goal posts. You didn't say anything about LOT=true when you say categorically "LOT=false does never help you as a user whether you're for or against the change". You're arguing in bad faith and dragging down the quality of the discussion.
08:20 < roconnor> We can either spend 3 months convincing them they are wrong, something that hasn't happened in the last 200 days, or we can run ST while spending 3 months convincing them they are wrong.
08:20 < jtimon> ariel25: I'm going to start ignoring you. you're being disrespectful and are using irrational arguments
08:21 < jtimon> and have the nerve to tell me I'm dragging down the quality of the discsusison while throwing your ad hominem falalcies at me. have a nice day
08:21 < ariel25> I'm being disrespectful because I don't tolerate your bad faith arguments.
08:22 < jtimon> ariel25: I couldn't care less about what you "tollerate", again, have a nice day
08:23 < jtimon> and stop saying my arguments are in bad faith, liar
08:23 < ariel25> jtimon I agree that's your choice to ignore me
08:24 < jtimon> I may stop ignoring you when you have rational arguments instead of insults and fallacies
08:26 < ariel25> I see so many bad arguments in this whole activation discussion that it's driving away the rational arguments. We're never going to agree on anything if that continues. At some point someone needs to call out the bad arguments for just being bad.
08:28 < jtimon> right, so the solution is to call people who disagree with you "extremists" and repeating they're arguing in bad faith. brilliant
08:28 -!- eoin87 [6d4f18ef@109.79.24.239] has joined ##taproot-activation
08:30 < ariel25> Honestly yes. It takes way too much energy debunking irrational arguments. Energy that could be used having a rational discussion
08:30 < jtimon> no more questions, your honor
08:31 < jtimon> we should embrace irrationality because using reason and logic is just too painful, sigh
08:32 -!- eoinm [6d4f18ef@109.79.24.239] has joined ##taproot-activation
08:33 < ariel25> I'm not trying to be mean. I actually think I was being fairly polite when I say that it's extremist to say something that is obviously not true.
08:34 -!- eoin [6d4f18ef@109.79.24.239] has quit [Quit: Connection closed]
08:35 < ariel25> And I said please
08:37 -!- eoin87 [6d4f18ef@109.79.24.239] has quit [Ping timeout: 240 seconds]
08:39 -!- eoin [6d4f18ef@109.79.24.239] has joined ##taproot-activation
08:46 -!- eoinm [6d4f18ef@109.79.24.239] has quit [Ping timeout: 240 seconds]
08:47 -!- eoin [6d4f18ef@109.79.24.239] has quit [Quit: Connection closed]
09:01 < pox> The only argument I've seen against "let's see what happens if we give it 3 months, no force applied" is "why bother coding something that might not activate". It's not a convincing argument, because bother (effort) is cheaper than risk. Absolutely nothing gets sacrificed by ST (Spaghetti Trial, see if it sticks, sorry couldn't help myself) aside from a bit of patience and optimism. If it fails, that most likely would sway a large part of
09:01 < pox>  the community debating the activation in favor of LOT=true. in which case insisting on LOT=true is just impatience - not a bitcoin value.
09:03 < pox> if you think lot=true is the least risky way to move forward now, then you're still going to think so after a failed 3-month ST, the only difference would be more people would move to your side, so I don't see why the impatience.
09:15 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:c47:230d:8185:8bec] has joined ##taproot-activation
09:19 -!- cguida [~Adium@2806:2f0:51c1:5cee:55a3:2da7:21ec:b3ad] has quit [Ping timeout: 260 seconds]
09:24 < ariel25> pox I agree that is the main argument against ST.
09:25 < maaku> belcher: I sincerely don't want taproot--naked pubkeys open up the potential to widespread theft and destruction of the entire ecosystem with quantum compute capabilities
09:25 < maaku> and there are plenty of people publically neutral on taproot
09:25 < ariel25> In addition I also point out that the margin of safety was relaxed from 95% to 90% to balance likely hood of activation with negative side effects. I think it's possible to keep a 95% threshold while removing the ability of 6% hash power to cancel activation with the Super Majority proposal.
09:25 < maaku> just don't discount the opinions of people not in this channel is all I'm saying
09:26 < belcher> agreed on dont discount people who arent there
09:26 < belcher> maaku have you read pwuille's argument about quantum computers? that they would destroy the ecosystem anyway, most coins are held on addresses for which the pubkeys are known
09:30 < maaku> roconnor: devs can't have it both ways.  you can't both block activation methods (which itself blocks activation) while also maintaining that devs don't control bitcoin...
09:31 < belcher> doing nothing is the default
09:31 < belcher> devs can block activation because anyone can block activation
09:31 < jtimon> pox: to me is not about taproot concretely but about removing the confussion on who decides the rules and settle this year long discussion once and for all
09:33 < maaku> belcher: something like 15%-ish of coins are old never-moved coinbases (Satoshi's coins) on naked keys. those being stolen would move the price but not destroy bitcoin
09:33 < jtimon> re QC: there's a path for the rest to become "quantum resitant" with lamport signatures, no? isn't there an equivalent for taproot?
09:33 < maaku> other sources of known coins are more transitory (key reuse, contracts like LN, etc.) and doesn't feed into that argument quite as well.
09:34 -!- roconnor [~roconnor@host-104-157-194-235.dyn.295.ca] has quit [Ping timeout: 264 seconds]
09:34 < maaku> so no i think that's a rather lazy argument
09:35 < belcher> maaku coins on reused addresses do in fact destroy your argument :) they can be stolen same as the old 50btc coinbases
09:35 < maaku> there's a qualitative difference between "some people opt into usage schemes which reveal the pubkey behind the hash" and "you MUST reveal your pubkey to access any new features"
09:35 < belcher> not to mention theres also all the hardware wallets which sync by sending their xpub to the wallet manufacturer's server
09:35 < ariel25> pox: one issue with ST is that even though luke-jr thinks a UASF in three months is too short I think there are likely others at a different level of dev experience than Luke that will think three months is plenty of time.
09:35 < belcher> fact is right now QC kills bitcoin and we'd need to soft fork in post-quantum signatures to fix it
09:36 < maaku> belcher: I listed those as transitory. reused addresses are slowly going away as people upgrade to better storage mechanisms
09:36 < belcher> and even then a huge proportion of all coins still get stolen most likely
09:36 < belcher> maaku iv seen numbers that show the other direction, a huge proportion of coins live on reused addresses
09:37 < belcher> also theres another argument, a quantum computer would likely work fast enough so that miners could run it and steal coins from unconfirmed transaction inputs
09:37 < belcher> hash functions protecting public keys to quantum-vulnerable schemes is not a method of post-quantum cryptography
09:37 < pox> jtimon for me as well. taproot is a very nice to have feature that I'm looking forward to, but not at the price of even the slightest risk to consensus. which is why advocating for forceful activation when force isn't obviously needed makes no sense to me.
09:38 < belcher> and of course, someone concerned about QC and who thinks hash functions help can always store their coins on a pre-taproot address
09:38 < pox> if we can't find a way to make even the least controversial softforks happen smoothly with negligible risk then maybe the time for softforks is over.
09:38  * belcher bbl
09:39 < pox> ST seems the least controversial and risky to me, so I support it.
09:40 < maaku> no QC scheme I'm aware of is that fast
09:41 < maaku> short of a time machine to the future, there's no way the first QC large enough to reverse secp256k1 will be able to do so on the scale of 1 day, let alone 10 min block windows
09:42 < pox> QC are not on-topic wrt activation AFAICT
09:42 < maaku> so having the hash function (which presents a high minimum work for QC) available as a line of defense is really important
09:42 < ariel25> pox: I think there is a less risky alternative that won't require multiple releases, can activate with a safe 95% threshold, and doesn't have a risk of chain splits.
09:42 < maaku> fine. the point is that there are people who don't want taproot, or are at least of mixed opinion, and that factors into taproot activation discussion
09:42 < maaku> the details are off topic
09:43 < pox> maaku I disagree - the merits of taproot are offtopic. those that are against it should just not run it. the topic was clearly defined as methods of activation, not debate on merit.
09:44 < pox> ariel25 multiple releases are not a risk. they're a cost.
09:46 < ariel25> pox: that's true but in the worst case ST will require an additional release so I include the risk of that undecided mechanism (lot=true or flag day) in the risk of ST
09:47 < maaku> pox: way back in the scrollback belcher was arguing that unlike with segwit there is literally noone that doesn't want taproot, with the context that a more aggressive activation method is therefore appropriate
09:47 < pox> that's risk reduction. if ST fails we have more knowledge than now and better chances or agreeing on how to move forward. I estimate the chances of it failing are very low.
09:48 < maaku> *implication that
09:48 < pox> maaku that's a true observation - it's less controversial. but the debate revolves around what the long-term default should be for softfork activation methods.
09:49 < maaku> pox: so I stood up and said "me, right here, I'm an example: I don't want taproot"
09:49 < pox> if there's no sensible, uncontroversial default option, then it makes sense to keep looking for one than to try to jam taproot through. taproot isn't as important as consensus.
09:50 < maaku> now I'm not trying to block taproot, but it is not crazy to think that there might be other factions who will
09:50 < pox> maaku fine, I'm not trying to silence anyone. just remarked that the discussion strayed from the topic so we can get to it.
09:50 < pox> maaku if there are, a ST would flush them out.
09:52 < ariel25> pox: sure I don't mind the definitions. I know of an activation mechanism that is less risky, safer, higher chance to activate, the best best-case scenario,  and the best worst-case scenario.
09:52 < ariel25> And less cost
09:52 < cguida1> jtimon one major difference between bip9 and bip8(true) is that bip8 uses heights rather than times
09:52 < maaku> ariel25: there are worst-case scenarios you are ignoring
09:53 < cguida1> Also I'd like to voice my disagreement to the notion that "not activating taproot is the safest option". It most certainly is not the safest option. Sure, we'll stay in consensus, but if we can't activate a proposal that everyone wants, the protocol will decay and die, and other protocols will replace it.
09:54 < ariel25> maaku Maybe. The only one I'm aware of is the risk of small reorgs which no activation mechanism is immune from
09:55 < maaku> ariel25: your "less risky" mechanism is simple-majority fallback, right?
09:55 < maaku> once you're in the simple-majoirty regime it takes only a single false-signaling miner with some thresholds to cause a chain split for unupgraded nodes
09:56 < ariel25> Yes and small reorgs are always possible if 40% of miners decide to just never upgrade to Taproot no matter what
09:57 < pox> cguida1 protocol ossification is kind of inevitable. no reason to think we're there yet, but to deduce that it spells doom for bitcoin is a stretch. if you think a feature race with other coins is what bitcoin has to do to win, then I think you'll find strong disagreement in the community.
09:57 < maaku> ariel25: my point is that 51% can never upgrade.
09:58 < ariel25> You're describing a risk that is intrinsic to soft forks not the activation mechanism
09:58 < maaku> pox: that contradicts your stance on QC above--protocol upgrades are absolutely necessary in the long term
09:59 < maaku> ariel25: with simple majority is requires epsilon false-signaling. with 75% it requires 25% false signalling. with 95% it requires 45% false-signaling
09:59 < maaku> these are safety margins and it's why those high margins are used
10:00 < maaku> ossification risks obsolescence
10:03 < ariel25> maaku: what you're describing is true for any activation's worst case including any bip8 proposal, ST, or a flag day
10:03 < maaku> ariel25: no the numbers are not the same.
10:03 < maaku> bip8(false) with 95% requires >45% hash power to be false signaling for that outcome
10:04 < maaku> that's a hell of a difference from >1% with 51% threshold
10:04 < ariel25> If only 49% of miners support the soft fork and 2% are false signaling they can trigger a reorg regardless of activation
10:04 < maaku> but they can't trigger activation in the first place when there is a higher threshold
10:04 < maaku> hence all the current proposals use high thresholds
10:06 < ariel25> maaku: no it's not fair to only consider bip8(false) 's best case. Consider its worst case which is to not activate and need some other risky activation
10:07 < maaku> not activating > false activation (<50% enforcement)
10:07 < maaku> not activating at all is the much less risky alternative
10:08 < AaronvanW> maaku: users who are concerned about their coins getting stolen by QC can just choose not to use taproot addresses.
10:08 < ariel25> No you can't just ignore the fact that if it fails with 51% miner support an UASF will be attempted right after
10:10 < ariel25> You must consider what happens if bip8(false) fails you can't just ignore it and say there's no risk.
10:10 < maaku> ariel25: UASF is less risky than false activation though
10:10 < maaku> UASF is opt-in risk. false activation is community-assumed risk
10:10 < ariel25> No it isn't
10:11 < maaku> ariel25: we might have to drop this debate.  I have work to do.
10:11 < maaku> AaronvanW: that becomes increasingly less of a real option the more we built on top of schnorr signatures, which you MUST opt into taproot to use.
10:11 < ariel25> Well it is based on what you consider a worse outcome. Reorgs or chain splits.
10:12 < maaku> my point is that if we make naked pubkeys an option for their space-saving benefits, it ought to be truly optional. which it isn't in current taproot.
10:13 < jtimon> cguida1: sure, like I wanted bip9 to be from the beginning, by height. I forgot that, thanks
10:13 < AaronvanW> I don't think I understand the difference between "optional" and "truly optional" you allude to.
10:14 < AaronvanW> yeah you get neither taproot or schnorr in that case. still sounds optional to me though.
10:17 < jtimon> there's no need for chain splits between the users who agree on the change or agree to oppose it
10:18 < jtimon> only a split between the two sides is unavoidable
10:19 < ariel25> maaku Simple Majority fallback has reorg risk (intrinsic to Soft Forks) and no chain split risk. UASF has reorg risk (for non-upgraded users) and it does have chain split risk. You say UASF has no reorg risk but that's only if you don't care about non-upgraded users. Sorry to bother you while you're working.
10:19 < pox> maaku QCs are mostly science fiction AFAIK. in any case, a method for uncontroversial and non-urgent softforks has very little to do with the ability to fork in case of a cryptographic catastrophe that we'll likely see coming a decade in advance.
10:20 < maaku> AaronvanW: we could have upgraded P2WSH or a P2WSH-like construction to use schnorr signatures instead of ecdsa
10:20 < maaku> with naked pubkeys being just an optional shorthand
10:20 < jtimon> pox: how can you know whether a change is controversial or not before you see if it produces a split because some users oppose it or not?
10:21 < maaku> with the current approach if you need Schnorr then you have no choice but to expose your pubkey
10:23 < maaku> pox: we are unlikely to see QC coming in advance. there's a lot more non-public money being put into this research, by actors who wouldn't think twice about grabbing half the bitcoins at once
10:23 < jtimon> box: but I tend to agree that I'm kind of skeptical on quantum computers
10:25 < maaku> (and btw it is probably less than a decade out. if you're not seeing the writing on the wall, you're not paying attention. you shouldn't assume these are going to be clearly telegraphed until it is too late!)
10:26 < pox> maaku again, this is offtopic. my point is that uncontroversial soft forks should have uncontroversial activations.
10:27 < pox> happy to continue discussing QCs on #bitcoin
10:27 -!- ariel25 [d062df66@208.98.223.102] has quit [Quit: Connection closed]
10:28 < maaku> but we agree that taproot is not uncontroversial?
10:28 -!- ariel7 [d062df66@208.98.223.102] has joined ##taproot-activation
10:30 < pox> maaku disagree. anyone who thinks there's any amount of non-negligible opposition to taproot should not be discussing activation methods. they should be campaigning against taproot and educating.
10:30 < maaku> ok then
10:30 -!- maaku [~quassel@ec2-54-186-10-232.us-west-2.compute.amazonaws.com] has left ##taproot-activation ["https://quassel-irc.org - Chat comfortably. Anywhere."]
10:30 < jtimon> pox: but again, how can you know a fork is uncontroversial a priori?
10:32 < jtimon> you cannot, what defines whether a change is controversial or not is whether there are users who really oppose it (ie who will keep using a system without the change), and you can't really know that until activation
10:33 < jtimon> miners' signaling also can't tell you whether something is controversial or not
10:34 < jtimon> so this "let's give it 3 months to see what miners think about it"...what miners think shouldn't be relevant, that shouldn't be the reason to use miners' signaling
10:34 < ariel7> @maaku Since Taproot is opt-in only that helps to make it uncontroversial and why we've reached the activation phase
10:35 < AaronvanW> jtimon "how can you know a fork is uncontroversial a priori?" <- futures markets
10:37 < jtimon> AaronvanW: I don't think so, even if the price is low for the anti-change side, that doesn't mean it won't exists. anyway, even accepting that, are there any future markets on taproot now to be able to assure taproot is uncontroversial?
10:37 < jtimon> we hope taproot to be uncontroversial, that's it
10:38 < AaronvanW> jtimon: no futures markets now, but I'd expect futures markets when we see a UASF effort.
10:38 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 265 seconds]
10:39 < jtimon> AaronvanW: but not with bip8(false)? why?
10:39 < ariel7> AaronvanW I agree with jtimon it's just hope. A futures market will reflect that hope too.
10:39 < AaronvanW> maaku: I may agree that would have been better, but afaik there's no code or BIP for that, so...
10:40 < AaronvanW> jtimon: hmm maybe then as well, haven't really thought about that.
10:41 < jtimon> whether people are going to oppose taproot or not doesn't depend on bitcoin core proposeing to activate it with bip8(false) or bip8(true). if people oppose taproot there will be a split wether it is activated by mining signaling or "UASF"
10:41 < jtimon> AaronvanW: I recommend you reading bip99 :p
10:43 < pox> jtimon you're right that measuring how controversial a change is would require some sort of voting system, but bitcoin doesn't have one, so we're left with free discussion in public forums. it ain't perfect, but perfect is the enemy of good. so far it doesn't seem like there are any significant voices opposing taproot. if you disagree, you can provide evidence to the contrary.
10:46 < jtimon> pox: well, users "vote" with their nodes, by chosing which software they use. it's better than democracy, it's free software! with free software, every user can get what they want. but you cannot know what they will want a priori unless you ask every single user in the world. after the change is activated, if nobody opposed it and there was no fork, you can say it was uncontroversial
10:47 < jtimon> perhaps I should update bip99 for bip8 and this discussion
10:47 < pox> jtimon bitcoin isn't democratic. it's not "one node one vote". and for good reason. I don't have to ask every user of bitcoin if they think raising the block limit to 1GB is a good idea.
10:48 < jtimon> pox: I know, that's what ?I'm saying. it's not democracy, it is free software, which is better, because everyone can get what they want
10:48 < pox> that's a lovely sentiment. this is how BSVers "got what they wanted" :)
10:49 < jtimon> pox: yes, bcash was actually a good thing. nobody was preventing them from hardforking. they just wanted to force everyone else to accept their change, but that's not possible with free software
10:50 < pox> I agree.
10:50 < jtimon> the whole blocksize debate was why I wrote bip99
10:51 < jtimon> in the same way, bitcoin core cannot impose taproot if some users oppose it, nor miners. not with bip8(false) nor with bip8(true)
10:52 < ariel7> If everyone had exactly what they wanted I don't think a cominity would be able to gather around a shared blockchain. It would be forever fracturing into smaller and smaller groups until we reach the family or the individual.
10:52 < jtimon> and if some users don't udnerstandf that, they just need to be explained, pretending miners decide doesn't improve the confussion, it makes it worse IMO
10:53 < jtimon> ariel7: in free software, when you don't like something, you can have it modified.
10:53 < jtimon> checkout this introductory talk to free software: https://www.youtube.com/watch?v=Ag1AKIl_2GM
10:54 < pox> jtimon not in a p2p consensus network. you cannot modify it as a negligible minority. you can only fork it. that's like saying BCH modified BTC. it did not.
10:55 < jtimon> well, if they can keep their own chain, they're not negligible, are they?
10:55 < ariel7> I know what free as in libre software is but it doesn't work like that on a blockchain
10:55 < pox> jtimon lol they most certainly are. but I'm going to stop here because this is way off topic.
10:55 < jtimon> yes, BCH modified BTC, and since many people opposed that change, there was a split
10:56 < ariel7> It doesn't work like you say in literally any network
10:56 < jtimon> well, we don't need to talk about big block changes or taproot, we can talk about changes in general, which is actually what I would prefer
10:57 < jtimon> ariel7: "you're wrong because it doesn't work like you say it does". ok, buddy
10:57 < ariel7> You can change the node by yourself but you can't change the network by yourself. And the whole point of having a node is using the network
10:58 < jtimon> I know
10:58 < jtimon> I've read a thing or two about these blockchain things, you know?
10:59 -!- rubikputer [~rubikpute@ip72-192-27-21.ri.ri.cox.net] has joined ##taproot-activation
10:59 -!- rubikputer [~rubikpute@ip72-192-27-21.ri.ri.cox.net] has quit [Client Quit]
11:00 < ariel7> To compare the customizable property of libre software (vlc, or a calculator)  with the ability to change a network. There's just no comparison
11:01 < jtimon> well, I'm sorry if you don't understand how properties of free software applies to blockchain related free software too
11:01 < AaronvanW> jtimon I just read BIP99. Is there anything specific I said that made you recommend that?
11:02 < jtimon> AaronvanW: the fact that you said you haven't though about the possibility of a bip8(false) activation can result in a split too
11:03 < AaronvanW> jtimon: I didn't say that. and yes I know. I just hadn't thought about futures markets in the context of bip8(false).
11:03 < AaronvanW> or how that would/could affect things.
11:04 < ariel7> It only makes sense with some other maybe quantum level reality. You can't change your own software by yourself in a network when you're considering actual reality
11:05 < AaronvanW> well no actually I have, and I think futures market would be very affective in that case jtimon. I just always assumed that a bip(false) would also see a bip(true) client running besides it.
11:05 < jtimon> AaronvanW: oh, then I misunderstood, sorry
11:06 < AaronvanW> because *someone* will release a bip(true) client if there is a bip(false) core release.
11:07 < jtimon> AaronvanW: no, not because of that, but because someone may oppose the proposal whether it is activated with bip8(true) or with bip8(false)
11:07 < AaronvanW> jtimon: yes your anti-LOT=true idea for users that want to opt-out. yeah you could have futures markets for that as well.
11:08 < jtimon> AaronvanW: but yeah, I think your prediction is accurate. otoh, if core releases  bip8(true) version, why would anyone release an alternative bip8(false) version and what would there be their arguments?
11:08 -!- stortz [b1982779@177.152.39.121] has joined ##taproot-activation
11:08 < AaronvanW> jtimon: I don't know if that would happen, indeed I don't see a good reason for it.
11:09 < jtimon> I mean, bitcoin core doesn't need to explicitly support the anti-antivation option. if people oppose the change, that or something analogous but worse will appear. it's not hard to code, I think
11:10 < AaronvanW> right
11:10 < jtimon> AaronvanW: but if core releases a bip8(false) version, some users have legitimate reasons to release a bip8(true) one, ie "we users decide, not miners"
11:14 < AaronvanW> sorry, I think I was confused after all jtimon. what you mean is that lot(false) could lead to a split because some users may deploy a counter-UASF to resist the upgrade. correct?
11:15 < jtimon> right, they can do that with either bip8(false) or bip8(true), that's my point, bip8(false) doesn't protect you against that
11:16 < ariel7> Why not a Simple Majority Fallback version where you won't split the chain if somehow you can't attract 51% of your miners to secure you're chain
11:16 < jtimon> the only thing that protects you against that is nobody wanting to do that, which since the feature is opt-in, wouldn't be surprising
11:16 < ariel7> your*
11:17 < jtimon> simple majority just gives more power to miners and introduces unreasonable risks
11:17 < jtimon> there's nothing good about it
11:18 < ariel7> It safer than what you're proposing
11:18 < jtimon> we should stop debating it altogether
11:18 < jtimon> no, it's not
11:18 < ariel7> It's simple majority fallback at the end of 95%threshold
11:19 < jtimon> it has no advantage
11:19 < ariel7> Ok then what risk are you saying exists in SMF and not in lot=true?
11:20 < jtimon> you've been explained by maaku more accurately than I could. I already explained it to you in simpler terms
11:21 < ariel7> I see chain split as a risk and that's why I'm saying it's less risky
11:21 < jtimon> it produces more reorgs for no good reason
11:21 < jtimon> what's supposed to be the advantage of simple majority?
11:21 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-activation
11:21 < jtimon> compared to bip8(true) ?
11:22 < ariel7> UASF produces reorgs on the 49% that don't want to upgrade
11:22 < jtimon> what?
11:22 < ariel7> The advantage is no chain splits
11:22 < jtimon> oh, sorry, you mean miners could decide to do an anti-change chain, they can do it either way
11:23 < jtimon> ariel7: no, permanent conscious chain splits depend on people opposing the change or not, not on the activation mechanism
11:23 < jtimon> as explained in bip99
11:24 < ariel7> Yes they can do it either way regardless of activation mechanism so that's why I was saying it wasn't introducing new risks.
11:24 < jtimon> if there are people who oppose it you'll get the split no matter what. otherwise bcash could have been forced on us using your proposed activation mechanism, no?
11:25 < ariel7> That's right
11:25 < jtimon> then the disadvantage of bip(true) can't be "it will cause a split if people oppose the change", that's true for EVERY activation proposal
11:26 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds]
11:26 < jtimon> if people oppose a change, neither bitcoin core nor miners can impose it, and that's a good thing
11:26 < AaronvanW> jtimon: the disadvantage if bip(true) is also that it can cause a split if miners/users don't pay attentiom.
11:27 < ariel7> No bip8 causes a chain split even if miner signaling is below 50%
11:27 < AaronvanW> and don't upgrade or too late
11:27 < ariel7> bip8true*
11:28 < ariel7> SMF can't cause a chain split
11:28 < jtimon> AaronvanW: true, I guess that's the only disadvantage, but fair enough, that's one
11:28 < AaronvanW> jtimon: the other one is "devs control" perception.
11:28 < AaronvanW> but we're not going to agree on that one today I think.
11:29 < jtimon> AaronvanW: nah, that's not a thing bip8(false) or any other activation can solve. that's not specific to bip8(true), that's just people not understanding they can't be forced to accept a change
11:29 < jtimon> AaronvanW: fair enough, let's not discuss that point further there
11:29 < jtimon> then
11:31 < jtimon> AaronvanW: not only if miners oppose the change but also if they're just not paying attention there can be a split. I haven't thought about the non paying attention possibility for miners, I guess
11:35 -!- ariel7 [d062df66@208.98.223.102] has quit [Quit: Connection closed]
11:50 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
12:04 -!- stortz [b1982779@177.152.39.121] has quit [Quit: Connection closed]
12:13 -!- eoin [6d4f18ef@109.79.24.239] has joined ##taproot-activation
12:15 -!- eoinm [6d4f18ef@109.79.24.239] has joined ##taproot-activation
12:20 -!- eoin [6d4f18ef@109.79.24.239] has quit [Quit: Connection closed]
12:20 -!- belcher [~belcher@unaffiliated/belcher] has joined ##taproot-activation
12:21 -!- stortz [b1982779@177.152.39.121] has joined ##taproot-activation
12:23 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 260 seconds]
12:28 -!- eoinm [6d4f18ef@109.79.24.239] has quit [Quit: Connection closed]
12:31 < luke-jr> jtimon: while it's important that neveractivate exist and be simple, I also have no interest in actually coding it up :P
12:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
12:33 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
12:39 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
12:40 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined ##taproot-activation
12:41 < cguida1> jtimon AaronvanW I think futures markets would be less likely to exist with only bip8(false) because there's no risk of a chainsplit, so one of the outcomes is guaranteed to be worthless. Markets were eager to add segwit2x because there was a chance it would actually exist afterwards
12:43 < AaronvanW> cguida1: at least a "normal" year-long LOT=false deployment would probably be matched with a LOT=true UASF client, so then there's reason for a futures market to exist. but yeah if it's obvious that miners will activate then there probably still won't *actually* be a futures market. only when miners stall.
13:01 -!- Teleportando [8eb30758@d142-179-7-88.bchsia.telus.net] has quit [Quit: Connection closed]
13:07 -!- LRSN [d41dd2e6@212.29.210.230] has joined ##taproot-activation
13:12 -!- Teleportando [8eb30758@d142-179-7-88.bchsia.telus.net] has joined ##taproot-activation
13:14 < luke-jr> AaronvanW: LOT=True is the normal
13:15 < AaronvanW> luke-jr: "mormal" referred to year-long.
13:16 < luke-jr> i c
13:22 < cguida1> AaronvanW: yeah, if and when uasf gets going, you can bet markets will be scrambling to add both tokens
13:23 -!- jonatack_ [~jon@37.166.102.70] has joined ##taproot-activation
13:24 -!- jonatack [~jon@37.166.102.70] has quit [Read error: Connection reset by peer]
13:26 < luke-jr> cguida1: what "both tokens"? UASF doesn't have a new token
13:26 < luke-jr> hence why there was never a BIP148 "token" on any markets (aside from one fraudulent market)
13:28 < cguida1> luke-jr: well, i guess exchanges won't necessarily be scrambling, if it looks like the uasf will definitely succeed. but if it looks like it might split hash power down the middle, there will indeed be two resulting chains, and thus two resulting tokens
13:31 < cguida1> but, if i were a miner i wouldn't be want to be caught mining the old chain
13:36 -!- stortz [b1982779@177.152.39.121] has quit [Quit: Connection closed]
13:49 -!- jonatack__ [~jon@37.167.56.19] has joined ##taproot-activation
13:52 -!- jonatack__ [~jon@37.167.56.19] has quit [Client Quit]
13:52 -!- roconnor [~roconnor@host-45-58-192-182.dyn.295.ca] has joined ##taproot-activation
13:52 -!- jonatack [~jon@37.167.56.19] has joined ##taproot-activation
13:52 -!- jonatack_ [~jon@37.166.102.70] has quit [Ping timeout: 260 seconds]
13:57 < achow101> what do want for testnet activation params?
14:04 < cguida1> good question. you're doing height-based activation, correct? i'm guessing we'll want a shorter window so we don't have to wait 6 months for it to activate? just throwing that out there
14:07 -!- jonatack [~jon@37.167.56.19] has quit [Ping timeout: 245 seconds]
14:08 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 245 seconds]
14:09 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
14:09 < luke-jr> I am okay with full retard on testnet ? :p
14:10 < achow101> I just did speedy trial at double the speed
14:10 < luke-jr> (aka .SetAlwaysActive)
14:10 < achow101> and 1 retarget period sooner
14:11 < achow101> I'm sure even with that, we can get it active in 2 days
14:13 < jtimon> luke-jr: fair enough I may catch up from what you have, it seems the only missing part is making the block invalid when that happens if I read your code right (but I read it very fast, just a glance)
14:15 < jtimon> cguida1: if people oppose taproot, there will be a split with bip8(false) or with bip8(true). it has zero effect on people opposing the proposal
14:17 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Quit: jb55]
14:18 < luke-jr> jtimon: IMO the only rational positions for a user/node to take, are "Taproot activation is invalid" and "Taproot activation is enforced" (ie, LOT=True)
14:18 < luke-jr> LOT=False's "Taproot activation is .. based on the weather" is silly, especially when reorg risk is considered
14:19 < jtimon> luke-jr: I agree 100%. if you're agaisnt the proposal, LOT=false is of no use to you. and if you're for the proposal, you prefer LOT=true
14:19 < jtimon> luke-jr: the worst part is it's not based on the wheather, it's perpetuating the false notion that miners decide the consensus rules
14:21 < jtimon> some people say "with LOT=true people will think developers decide", well those same people, without education, with LOT=false wil lthink that dev + miners decide. how is that any better? they will be wrong either way if they're not explained
14:38 < luke-jr> "implemente.d"
14:59 < AaronvanW> jtimon give users a LOT=true configuration option and it'll be obvious.
15:00 < jtimon> I don't think so, you mean an anti-change option?
15:00 < AaronvanW> no
15:00 < luke-jr> AaronvanW: point is that LOT=false isn't a sane option to choose from
15:01 < jtimon> because giving users the TOL option only increases the confusion
15:11 < AaronvanW> if the perception part isn't a problem, you're right. (but I'm not sure that it isn't.) (an opt-out option would help with that as well though, you're right about that too.)
15:14 <@michaelfolkson> I'm wondering if discussion on Taproot activation PRs should be in here or in #bitcoin-core-dev. Or maybe we can gatecrash #bitcoin-core-pr-reviews
15:14 <@michaelfolkson> If people want to continue high level discussion here I don't think this is great for PR discussion
15:17 <@michaelfolkson> achow101 livestreamed coding of "Speedy Trial" here: https://www.twitch.tv/videos/941955839
15:25 <@michaelfolkson> I think #bitcoin-core-pr-reviews. John can always boot us. And leave Wednesday for the PR review club PR
15:27 < luke-jr> this channel is slow enough for both
15:27 <@michaelfolkson> There was a lot of high level stuff today
15:27 <@michaelfolkson> But maybe you're right
15:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
15:39 -!- harding [quassel@newmail.dtrt.org] has joined ##taproot-activation
15:40 < cguida1> jtimon: what? bip8(false) can't lead to a chain split, because it just drops the activation if not enough miners are signaling, and everyone goes back to their lives as if nothing happened. or am i missing something?
15:58 < jtimon> cguida1: what if miners activate it but some or most users oppose it?
15:59 < jtimon> if bcash had been deployed as bip8(false), would it had lead to a split?
15:59 < AaronvanW> jtimon: I think the opt-out counter-UASF causes the split in that case, not bip(false)
16:00 < jtimon> @AaronvanW but it's free software, you can prevent people from opposing a change. and you shouldn't try, specially if you're concern about optics
16:00 < AaronvanW> jtimon: no it's fine, I wouldn't oppose them splitting.
16:01 < jtimon> again, controversial changes are going to cause splits no matter the activation method
16:02 < AaronvanW> I do still think the opt-out counter-UASF causes the split in that case, not bip9(false).
16:03 < jtimon> well, it's the proposal being controversial what causes the split
16:03 < AaronvanW> yes, best to avoid that.
16:03 < jtimon> it's people not wanting the same rules what causes the split
16:03 < jtimon> AaronvanW: how is software supposed to prevent people from wanting different things?
16:03 < AaronvanW> well unless the added value of the forks is greater than the pre-fork coins perhaps.
16:04 < AaronvanW> jtimon: it doesn't.
16:04 < jtimon> no, if I don't want change X, it doesn't matter what other people want and how much are they willing to pay for it, I still don't want it
16:04 < rusty> There is always a strong tendency to try to avoid considering hard questions, in the hope they don't happen.  Unfortunately, being unprepared is also a way of inviting these things to happen.
16:05 < jtimon> right, people are only thinking from the perspective of a change they want, not from the perspective of a change they don't want
16:05 < jtimon> the right solution should be right for both cases
16:05 < AaronvanW> jtimon: that's ok too. my point wasn't about what's desirable, just about who/what I think would be causing the split in that case.
16:07 < harding> rusty: I wanted to learn more about your concerns with Speedy Trial but didn't hear back from you on Mastodon.  Did you want to converse here instead?  https://hash.social/@harding/105850276827608357
16:07 < jtimon> if bip8(false) can't cause splits, what are we going to do with the IMF proposes a softfork with bip8(false) activation, guys?
16:07 < AaronvanW> jtimon: split
16:07 < harding> jtimon: let it fail?  Change PoW if miners start censoring txes?
16:08 < jtimon> AaronvanW: but then bip8(false) activation can cause splits!
16:08 < AaronvanW> no jtimon, we would be causing that
16:08 < AaronvanW> with out counter-UASF
16:08 < rusty> harding: I'd love to, but I have a meeting in 5.  Hope it'll be < 1 hr though.
16:09 < AaronvanW> *with our
16:09 < harding> rusty: I'll be around for the next 6 hours or so.
16:09 < jtimon> AaronvanW: whatever, then bip8(true) can't cause splits either, it would be the opponents of the change or miners not paying attention, but not bip8(true) activation
16:09 < jtimon> I can play your same semantics game
16:15 < AaronvanW> jtimon: if we split because of IMF LOT=false, that's our choice, our problem if there's no hash power, etc. we wouldn't be harming anyone else. "or miners not paying attention" <- this could cause unupgraded users to lose money if/when miners switch after the fork, causing harm to unupgraded users.
16:17 < cguida1> >if bcash had been deployed as bip8(false), would it had lead to a split?
16:18 < cguida1> No, unless there was at least some hashing power behind the original chain
16:18 < cguida1> jtimon
16:21 < cguida1> but yeah, you're right that there could be a split if users aren't in favor, but that would require a scenario in which the devs and miners are trying to force changes on the users that the users don't want, and that's clearly not what's happening here
16:22 < cguida1> but yeah, i was wrong, bip8(false) can theoretically lead to a chain split
16:23 < AaronvanW> hmm I guess unupgraded users could also lose money if miners switch to the anti-IMF chain after the fork.
16:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
16:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
16:48 < jtimon> AaronvanW: so when it's "our" choice it is not the activation mechanism what causes the split, but hwen it's somebody else's choice, then it is bip8(true) that cuased the split, not "their choice"? sorry, man, that's not consistent
16:49 < jtimon> cguida1: I'm saying if proposed with bip8(false) and supported by miners, if that wasn't obvious
16:49 -!- isuldor [~isuldor@23.234.203.222] has quit [Quit: leaving]
16:50 < jtimon> cguida1: my point users disagreeing with the change is the one and only requirement for the split. bip8(false) vs bip8(true) is NOT what determines if there's going to be a split or not, but whether the change is controversial or not
16:51 < jtimon> with bip(false) but not being activated by miners, it is obvious there is no split, but also no activation
16:52 < jtimon> if activated, both can cause a split IF AND ONLY IF people oppose the change or miners aren't paying attention
16:52 < AaronvanW> jtimon: that's not exactly what I said, but I do think you're right that in the case of a SF v. SF split, both sides "caused" it, hence BIP8(false) can lead to splits.
16:53 < jtimon> cool
16:53 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 240 seconds]
18:05 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
18:09 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
18:10 -!- grubles [~unknown@96.30.199.172] has joined ##taproot-activation
18:10 -!- grubles [~unknown@96.30.199.172] has quit [Changing host]
18:10 -!- grubles [~unknown@unaffiliated/grubles] has joined ##taproot-activation
18:11 < cguida1> jtimon: ok, I guess I was assuming that the change was uncontroversial because taproot is uncontroversial. But sure other soft forks could be controversial and in those cases bip8(false) could cause a split
18:12 < jtimon> cguida1: that's why I'm saying we should talk about any change in general. and again, how can you know a priori whether a change is controversial or not?
18:13 < jtimon> and if it is not controversial, then bip8(true) won't cause a split either
18:13 < rusty> harding: OK, so ST is kinda the blind monkey solution.  As in, a blind monkey could activate Taproot, so why not use it?  There are two main problems with ST.  The minor (ha) one is that signalling is now so divorced from actual upgrades that instead of miners activating then signalling, it's practically begging them to signal now, activate later.  But the greater problem is that it begs the question, which I know is awkward
18:13 < rusty>  but I don't think should be deferred: what if miners say no?  It really does beg the question because we're deeply confident they'll say yes.  This puts us back to the pre-SW days, where one day miners ever fail to activate, we scramble without a Schelling point, without a plan, and entrench uncertainty.
18:14 < cguida1> i disagree. bip8(true) could cause a split because it could incentivize bad actors from outside the system to mess with activation, in order to hurt bitcoin
18:15 < cguida1> wait, that's wrong, i'm tired haha
18:15 < jtimon> cguida1: why bad actors can't interfere with bip8(false) but they can with bip8(true)? I don't understand
18:15 < rusty> cguida1: if there's a civil war, it will be messy: this is axiomatic.  In a larger sense, if Bitcoin's economic users cannot be relied upon, then Bitcoin is a fragile system just waiting to break.
18:16 < jtimon> no problem, but people keep using arguments against bip(true) that also apply to bip(false) and arguments in favor of bip(false) that also apply to bip(true)
18:16 < rusty> I like the idea that Bitcoin users should be sovereign individuals, and we should empower and enshrine their role as final arbiter.
18:18 < cguida1> i meant: bip8(true) could cause a split because only half the mining power has switched over to the new rules at activation. that doesn't necessarily require the change to be controversial, it just requires miners to be unmotivated
18:18 < cguida1> rusty: me too
18:19 -!- LRSN [d41dd2e6@212.29.210.230] has quit [Ping timeout: 240 seconds]
18:19 < harding> rusty: ok, I'm going to ignore the problem with false signaling since (1) you think that's the lesser problem and (2) I did clearly describe that in my summary of the proposal to the mailing list, so it's at least not a surprise to me.  We can certainly come back to that.
18:20 < jeremyrubin> FWIW rusty, if miners don't upgrade they are just SPV mining so it takes one of the miners mining a bad block for things to go wrong
18:20 < jeremyrubin> they won't put taproot txns in their mempool
18:21 < rusty> jeremyrubin: yes, I am aware.  And if the majority don't upgrade you get to steal taproots and watch chaos erupt.
18:22 < cguida1> rusty: if they say no, we have to make sure there isn't a good reason, and if there is, we fix the problem, and if there isn't, then we do LOT=true
18:22 < harding> I'm still not sure I understand your question about what to do if miners say "no".  It seems clear to me that the thing to do in that case is to try to learn *why* they said "no" and then base our response on that information, which is something we can't do in advance (although we can, and probably should, game out possible reactions).
18:22 < jeremyrubin> well chaos would erupt anyways if only 51% even -- still would make for a lot of slowdown/reorgs
18:23 < rusty> harding: "talk more" is not a plan.
18:23 < jeremyrubin> rusty: you want to do one of my taproot bet contracts
18:23 < jeremyrubin> https://blog.bitmex.com/taproot-you-betcha/
18:24 < jeremyrubin> that's the best "sovereign individuals" type of path
18:24 < harding> rusty: why isn't "talk more" a plan?
18:24 < rusty> harding: compare the "devs propose, miners activate, users override", as per a (hidden) option for LOT=true.
18:25 < harding> rusty: you don't need a hidden option for LOT=true to have a propoose, activate (maybe), activate (force) workflow.
18:26 < rusty> harding: yeah, actually from a practical perspective you really do.  People ignore the infrastructure which has accreted around bitcoin core releases; trying to replace this is fraught and risky, and doing it under time pressure even worse.
18:26 < jeremyrubin> rusty: out of curiosity what does LOT get you that a flag day doesn't?
18:26 < harding> (I'm not I oppose such an option myself, although I can understand why others do, but I just want to point out that it's not necessary to pre-commit to including such an option in software to achieve that outcome.)
18:26 < rusty> Again, that's lack of a plan.
18:26 < rusty> You return to "this is too hard, let's get the devs to activate it!"
18:27 < rusty> https://en.m.wikipedia.org/wiki/Si_vis_pacem,_para_bellum
18:27 < jeremyrubin> me? or harding?
18:27 < rusty> jeremyrubin: (sorry, was replying to harding)
18:27 < jeremyrubin> in the situation where users override I don't see why the miners signalling or not matters
18:27 < harding> rusty: trying to figure out why something you expected to happen didn't happen seems like much better engineering to me than, "if it doesn't do what you expect, automatically put more pressure on it".
18:29 < rusty> If you genuinely believe that bitcoin is most robust system is the triumverate system, then you need to spell that out.  It provides both Schelling points and vastly reduces uncertainty.  Knowing the path reduces the chance of stumbling into a conflict.
18:29 < harding> rusty: yeah, I'm aware of that slogan and I'm also aware that Rome waged nearly constant war for its entire existence.  It's a great slogan for the John Wick francise; I'm not sure it's great for making engineering decisions.
18:30 < rusty> harding: separation of powers is actually important, here.  You've handwaved over who would do this analysis and what they'd do with it.
18:31 < jeremyrubin> In defense of having something automatic happen if ST fails, a hardfork to disable bad softfork signaling isn't the worst outcome.
18:31 < rusty> Because if miners understand the next step is users enabling LOT=true en-masse, they'll be sure to make their objections heard.
18:31 < cguida1> or: devs are the legislative, miners are the executive, and the users are the judicial
18:31 < jeremyrubin> rusty: do you have thoughts on how bad a hard fork is if it's to disable a future soft fork?
18:32 < rusty> jeremyrubin: you wouldn't, at least for taproot, you'd burn out v1 with a SF.
18:32 < jeremyrubin> If the thinking is that a majority of the network hasn't upgraded yet, a hard downgrade fork doesn't seem cataclysmic
18:32 < jeremyrubin> rusty: you can either burn V1 or mandate non activating signal levels
18:32 < jeremyrubin> both should be safe
18:33 < harding> rusty: my email about the ST proposal specifically says that, if it fails, it should inform the decision to move to a mandatory activation scheme.  I'm not specific about what scheme or even whether we necessarily need to move to that because I feel very strongly that we should not be commiting to future decisions unnecessarily when there's still a chance that we might receive data that will inform our decisions.
18:33 < rusty> FWIW, one natural response to miner reluctance is to place more power in the hands of the developers.  I believe this is a mistake.
18:34 < rusty> harding: But you don't really care because you know it won't happen.  Phew.  Don't have to have that uncomfortable conversation!
18:34 < harding> rusty: as achow101 pointed out the other day, that's basically Matt's modern soft fork activation idea: try, if fail(reflect), if_necessary(try harder).
18:35 < harding> rusty: please don't attribute thoughts to me.
18:36 < harding> rusty: I'm having an uncomfortable conversation right now that I sought out after hearing that you had concerns.
18:36 < rusty> Clearly, you don't see the clear separation of responsibilities as important; you simply don't think in those terms.  That's ok, but it's not a very useful conversation.
18:38 < jeremyrubin> to me the "developers / users" divide has always seemed false
18:38 < jeremyrubin> if you're looking for a triumvirate system I think that users / developers are basically the same groups
18:38 < belcher_> whats so good about separation of responsibilities? some people have also argued that the rules are entirely controlled by the economy and the history is entirely controlled by the miners, and that dont they exist in some "balance of powers" state as i understood your blog post
18:38 < rusty> I think I've been as clear as I can be that the steps post-miner activation failure should be explicitly placed in the hands of the nodes, that the developers should do this as soon in the process as possible, and that it is the robust system moving forward because it recognizes the actual power structure involved.
18:39 < rusty> jeremyrubin: all groups are fluid, ofc, but absolutely not.  Developers are no longer the major economic users of the system.
18:39 < harding> rusty: when I was a kid, I learned about the ultimatium brinkmanship that started WWI and I clearly remember learning the lesson then that ultimatiums are something to be really careful about, so I try to not to make them.  This has served me reasonably well in life and I think the lesson also applies here.  Pre-commiting to having users mandatory activate a soft fork can easily result in a disproporionate response to a failure to activate.
18:40 < rusty> harding: that's exactly what you're missing.  You can't pre-commit to *anything*.
18:40 < rusty> "The users will have to enforce this" is exactly not pre-committing.
18:41 < jeremyrubin> rusty: I think that's not quite true -- "majority economic users" are more engaged in development now than historically (except maybe very early days) Bitmex, Coinbase, Saylor, OkCoin, Kraken, etc are all paying for developer time, conceivably to represent their views
18:42 < harding> Ok, that's fair.  But telling users that, if miners fail to activate something, that it's up to the users to force miners to do something is something akin to pre-committing (at least in my mind).
18:42 < rusty> harding: well, yes, it's precommitting to a process :)
18:42 < rusty> jeremyrubin: a worthy thought indeed, but I think that we're a long way from developer capture :)
18:43 < harding> rusty: yes, and I think maybe the process could use at least one extra step in there of "reflect on why activation didn't happen".
18:43 < rusty> harding: let's be clear, users may choose not to.  Miners might have a valid reason, or users may not want the risk.
18:43 < rusty> harding: but giving the users tools to make a determination makes it very clear *who* will "reflect on why activation didn't happen".
18:44 < harding> rusty: I'm confused by that last statement.
18:44 < rusty> harding: hidden LOT=true option, sorry.
18:44 < harding> How does giving users a configurable LOT give them the tool to reflect on a "why"?
18:45 < rusty> harding: giving them a genuine voice is, I think, the key.
18:45 < rusty> After all, you can't force anyone to actually think.
18:45 < harding> true dat
18:47 < rusty> Anyway, as I said, we can YOLO activate taproot, I think we're missing an opportunity to enshrine the lessons learned from SW, and with that leaving ourselves unprepared for future issues.  I think the lack of certainty of process, itself, leaves us less confident and united against future threats which we know are coming.
18:48 -!- jr_ [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
18:48 < rusty> And I think organizing will only get harder; we probably will activate the next few SF without any issues.
18:48 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds]
18:49 -!- jr_ [~jr@024-176-247-182.res.spectrum.com] has quit [Client Quit]
18:49 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
18:50 < harding> rusty: Ok.  I'm going to think about what you said for a couple minutes and then try to summarize what I think is your position in my own words to see if I understand it.
18:50 < jeremyrubin> sorry my client bounced
18:50 < jeremyrubin> I think my msg got dropped
18:50 < harding> rusty: also, let me know if you wanted to come back to the earlier point about encouraging false signaling.
18:51 < jeremyrubin>  [Monday, March 8, 2021] [6:45:33 PM PST] <jeremyrubin>  rusty: I still don't see why LOT=true gives users superior voice v.s. flag     day. To cleanly pick which network they are on?
18:51 < jeremyrubin>  [Monday, March 8, 2021] [6:45:41 PM PST] <jeremyrubin>  LOT=true is redelegating to miners
18:51 < jeremyrubin>  [Monday, March 8, 2021] [6:45:49 PM PST] <jeremyrubin>  to actually start producing a chain regularly
18:51 < rusty> harding: TBH, I find these conversations really taxing.  I really like my fellow bitcoiners, and hate being "that guy".
18:51 < jeremyrubin>  [Monday, March 8, 2021] [6:46:04 PM PST] <jeremyrubin>  if users want to force hand, they should flag day and start using taproot
18:52 -!- stortz [b1982779@177.152.39.121] has joined ##taproot-activation
18:52 < rusty> jeremyrubin: it drags along LOT=false, by design.  Otherwise LOT=false thinks it timed out, flag day thinks it's active, and we can split again?
18:53 < jeremyrubin> Well, there's only one split, yeah? If you have LOT=false + flag day you split on invalid spend
18:54 < jeremyrubin> LOT=false + Lot=true splits on signalling
18:54 < jeremyrubin> But in the event you are trying to use LOT=true, and you only get let's say 5% of hashrate to join you, you have a bad time
18:55 < rusty> jeremyrubin: yeah, sometime way in the future for random nodes though.
18:55 < jeremyrubin> so LOT=true sorta ends up re-delegating that decision of which chain to build to miners
18:55 < jeremyrubin> Whereas the uncertainty around no signaling favours users
18:56 < jeremyrubin> since it's just "active" and the miners don't have a default way* of counter signaling (other than building on a badtx block)
18:57 < jeremyrubin> (I agree with your synopsis that LOT is just coordinating when the fork happens, not if)
18:58 < rusty> jeremyrubin: yes, LOT=true is most effective signalled before the fork.  If you get to the fork point, it always gets messy, but at least it's messy on schedule.  If enough nodes are upgraded, miners get their blocks disrupted, which tips in favor of LOT=true miners.  Otherwise, you get a split after 201 blocks (assuming literally no miners signalling), but LOT=true ppl know they're kinda screwed.  And within 6 hours they'll
18:58 < rusty>  know for sure.  I expect if that happened, most would cave TBH.
18:59 < rusty> jeremyrubin: the difference (generally) is that nodes can handle a fork, miners start bleeding immediately if they pick the wrong side.  So the pressure is asymmetric.
18:59 < rusty> (I would really love someone to test the network after activation by producing taproot-invalid spends, but I'm gonna need a couple of whales and mining pools to do it :)
19:00 < rusty> (Even a credible threat to create such a block would have the same effect, I think, but for it to be credible next time you need to actually do it this time...)
19:01 < jeremyrubin> rusty: based on that, methinks that you might find giga-signaling periods (let's say 1 month?) better
19:01 < jeremyrubin> as they give more than 1.5 days notice of impending LOT=true fork
19:02 < rusty> jeremyrubin: more time isn't *always* better though.  By this stage you've had 12 months....
19:02 < jeremyrubin> sure sure
19:03 < jeremyrubin> I do think harding raises a good point that the incentives for a miner based on your para above are to false signal and SPV mine
19:06 -!- stortz [b1982779@177.152.39.121] has quit [Quit: Connection closed]
19:06 -!- virtu [~virtu@gateway/tor-sasl/virtu] has quit [Remote host closed the connection]
19:06 -!- virtu [~virtu@gateway/tor-sasl/virtu] has joined ##taproot-activation
19:08 < rusty> jeremyrubin: weird, I don't see anything from harding since 16 minutes ago?
19:08 < harding> rusty: summary: Speed Trial fully prepares for the case where miners activate taproot but it does nothing to suggest the appropriate response to a failure to activate.  We have an opportunity with the activation of taproot to create a template for future activations that will clearly define the rules and responsiblities for devs, miners, merchants , investors, and end users in all the ways an activation can progress, not just the best-case
19:08 < harding> outcomes.  We should not now take the expedient path that simplifies things for us today if it means that it could complicate things for us in the future, especially since Bitcoin's growth means anything we need to do in the future will need to be done at greate scale and so greater difficulty.
19:08 < harding> s/rules/roles/
19:09 < harding> rusty: does that seem fairly reflective of your main position?
19:13 < rusty> harding: Well, it's a description, but it misses the actual proposal.  I'm not saying "we should say what should happen", I'm saying what we should say, if that makes sense?
19:13 < rusty> harding: let me see if I can do that without adding words, since brevity is wit....
19:17 < rusty>  Speed Trial fully prepares for the (likely) case where miners activate taproot but it does nothing to codify lessons learned from Segwit's failure to timely activate.  We have an opportunity with the activation of taproot to create a template for future activations that will clearly define the rules and responsiblities for devs, miners, merchants , investors, and end users in the an activation can progress, not just the bes
19:17 < rusty> t-case outcomes; in particular enabling and enshrining the final arbiter role that Bitcoin's economic users hold by definition.  Defining this will only get more difficult in future, both because we'll only do so when we're already in crisis, and Bitcoin's growth means agreement needs to be done at greater scale and so greater difficulty.
19:18 < rusty> Otherwise it sounds like "rusty wants someone to give certainty" which, yeah, is kinda easy to dismiss?
19:18 < harding> Sorry, I didn't mean it that way.
19:19 < rusty> harding: oh no, your summary was accurate!  Was just trying to misread it with fresh eyes :)
19:19 < rusty> I think the ' the activation of taproot' can probably be omitted in the second sentence, too, since the first one sets context?
19:20 < harding> rusty: maybe I just like saying taproot?  :-)
19:20 < rusty> harding: who doesn't?!?
19:20 < jeremyrubin> tarpoot
19:20 < rusty> jeremyrubin: is it sad that I actually LOLd?
19:20 < harding> rusty: thank you for taking the time to help me understand your position!
19:21 < jeremyrubin> rusty: means you need to take a break :p
19:21 < rusty> harding: thanks for your patience :)
19:22 < jeremyrubin> rusty: to me it sounds a little bit hopelessly romantic. I think we can only codify roles through observing and responding to failures. Perhaps there is some of that from segwit, but it seems the only thing we'll be able to codify is that "it varies"
19:22 < jeremyrubin> I also agree that a more codified process would be less corruptible via emergency powers stuff
19:22 < jeremyrubin> But I think the kind of leg work we'd need to see for that to happen this time around would involve setting up e.g. formal professional organizations
19:23 < rusty> jeremyrubin: all of bitcoin is a hopelessly romantic project, too.  I mean, would users actually rise up and oppose the miners?  Even if it were as simple as possible, and widely supported?  Dunno?
19:23 < jeremyrubin> rusty: this is why we can't codify it
19:24 < jeremyrubin> It probably won't happen with a ST, and if it does, then we'd likely give up on ST as a mechanism in the future anyways
19:24 < rusty> jeremyrubin: no, because if we place responsibility on the users and it fails, we learn something valuable about bitcoin, too.
19:24 < rusty> jeremyrubin: oh, ST will pass.  We've done the all the steps to make it so, including making it easy for miners to say "yes".
19:25 < rusty> (Actually, there's one we omitted: we could invert the bit and make them signal *against* activation :)
19:25 < jeremyrubin> Would you be happy with: "Should ST fail, Core will never again release coordination parameters except via burried deploy, responsibility for activation will fall to users"
19:25 < rusty> jeremyrubin: no, because it won't, so it's a doubly-empty promise?
19:26 < jeremyrubin> What's a double empty?
19:27 < jeremyrubin> I'm just saying, magically, were that the plan is that the sort of clarification you're looking for?
19:27 < jeremyrubin> *the never again is meant to be bound for this specific upgrade, not forall
19:27 < copumpkin> I may be misreading, but it sounds like rusty wants precedent for activating other stuff, and ST doesn't get that regardless of whether it works for taproot or not?
19:27 < rusty> 1.  It won't happen because ST doesnt' fail.  2. we have never done it before, and we're not doing it this time, but we'll totally commit our successors to doing it without debate next time.
19:29 < rusty> You put the code in, for every upgrade.  Maybe it's never used and stays a weird thing that Luke turns on and everyone ignores, but the principle of "devs propose, miners activate, users override" is enshrined so it's there if and when.
19:29 < jeremyrubin> rusty: so I just don't see how what you want is actionable
19:29 < jeremyrubin> you just want configurable params?
19:29 < rusty> jeremyrubin: er, yeah.  My position hasn't changed?
19:30 < jeremyrubin> Do they need to be in the binary?
19:30 < jeremyrubin> Or can they be compile time?
19:31 < jeremyrubin> I'd love to see your "uncanny valley" of user configurability -- what's too hard?
19:31 < rusty> jeremyrubin: Yes, I think so.  There's so much infrastructure around shipping core binaries now, you would fall back on "we'll just ship new binaries with different defaults" which violates "devs propose".
19:31 < jeremyrubin> What if they're all shipped at the same time?
19:32 < rusty> jeremyrubin: you still need to upgrade, it's a non-starter.  All those embedded nodes...
19:32 < rusty> But it really requires developers to decide that they really really don't want this power, and I'm not sure that we're there?
19:34 < jeremyrubin> rusty: I think it's just more a practical matter that trying to test M parameters is O(prod choices_{param_i}) hard
19:35 < jeremyrubin> maybe it seems like a small enough number now?
19:36 < rusty> jeremyrubin: sure, absolutely.  It *is* an additional requirement, but that kinda leads back to "how much do you prioritize user activation power"?
19:36 < roconnor> A user configurable parameter is very hard to implement correctly so that it can be turned on and off.  Also it probably won't pass core review because it will be opposed by the faction who have "publicily committed to avoiding divergent consensus rules on the network"
19:36 < jeremyrubin> I think the main thing is that if users want it, they can pay for it (by paying developers to work on how to do it safely)
19:37 < rusty> roconnor: yeah, you need to force a reindex (I think) if you are above the activation height.
19:37 < jeremyrubin> Why aren't users patrons to such work?
19:37 < jeremyrubin> I guess maybe they gh sponsor luke-jr?
19:37 < jeremyrubin> but that doesn't get them user configurability, just another binary
19:39 < rusty> roconnor: sure, it may be opposed, but that's kind of a separate question from "what is right" I think.  I know your opinion is that activation is what matters, mechanisms are transient, but that makes me sad.
19:40 < roconnor> Not simply opposed.  I think it won't pass core review.
19:40 < roconnor> I could be wrong.
19:41 < rusty> roconnor: you could also be right.
19:41 < luke-jr> jeremyrubin: if only my gh sponsors care about it, … lol XD
19:42 < roconnor> This is where I normally suggest that people try to make a PR ... but configurable softfork rules ... that's a dozy of a PR.  I'm not even so sure it can pass core review even if there were no opposition. :D
19:43 < rusty> roconnor: perhaps a PR to remove invalidateblock then? :)
19:43 < luke-jr> jeremyrubin: (not lol @ my sponsors; lol @ the few #)
19:43 < roconnor> ha.  Maybe I'm too worried about complexity.
19:44 < jeremyrubin> ./bitcoind -lot=taproot:$RANDOM
19:44 < jeremyrubin> taproulette
19:45 < roconnor> TBH, invalidateblock is probably simpler.
19:46 < luke-jr> not for most users
19:46 < jeremyrubin> I did put a script for that on mailing list
19:47 < roconnor> sorry I mean the implementation of invalidate block is simpler than the implemantion of user configurable soft-fork rules.
19:47 < rusty> roconnor: hmm, not sure what beyond "you changed it, please reindex?" is needed, but I'd have to actually test?
19:48 < luke-jr> roconnor: not really
19:48 < luke-jr> roconnor: in a mixed network, you really probably want intelligent peer finding etc
19:49 < luke-jr> rusty: that's post-activation, which is broken for all softforks
19:49 < rusty> luke-jr: so, safest is to discard blocks back to the activation point and re-get?
19:50 -!- criley [~criley@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
19:50 -!- wumpus2 [~ircclient@pdpc/supporter/professional/wumpus] has joined ##taproot-activation
19:51 < roconnor> you'll need to implement a way to tell if you've changed it.
19:51 < luke-jr> rusty: most softforks don't need to go that far
19:51 < luke-jr> rusty: but again, this isn't a user-configurable thing, it's a post-activation upgrade thing
19:51 < jeremyrubin> rusty: did you, by the way, see the "LOT=true via invalidateblock" script?
19:52 < jeremyrubin> it's part of why I ask about your uncanny valley of configurability
19:52 < roconnor> then you have to reindex back to the manditory activation point.
19:52 < roconnor> advertize your preferences on peering
19:52 < roconnor> use advertized peer info to inform peering.
19:52 < jeremyrubin> technically the way I implemented the script you leave it running all the time when your node is running
19:52 < luke-jr> roconnor: I think we should save info on what detail we've validated every block
19:53 < rusty> roconnor: this peering thing is weird.  I think people misunderstand the point of UASF: if it comes to it, I will fake signalling to tarpit opposing nodes.
19:53 < roconnor> luke-jr: seems like a good idea.
19:53 < jeremyrubin> roconnor: oh wasn't sure if that was for me
19:53 < rusty> The idea is to force the miners, not to have a friendly split.
19:53 < roconnor> oh I'm just musing on what would be required for a Core implementation.
19:54 < luke-jr> roconnor: it shouldn't be required
19:54 -!- pigeons_ [~pigeons@androzani.sysevolve.com] has joined ##taproot-activation
19:54 < luke-jr> never has been for any other softfork
19:54 -!- pinheadmz_ [~pinheadmz@hns-contributor.dev] has joined ##taproot-activation
19:54 -!- andytosh1 [~apoelstra@unaffiliated/andytoshi] has joined ##taproot-activation
19:54 < roconnor> what shouldn't be required, an conf option?
19:54 < luke-jr> handling all unexpected edge cases gracefully
19:54 < rusty> luke-jr: yeah, the part which handles it changing should be a part of a PR which makes it an option, clearly.
19:55 < jeremyrubin> rusty: ICYMI https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg09536.html
19:55 < rusty> luke-jr: you mean a reorg which undoes activation is not handled gracefully today?
19:55 -!- livestradamus_ [~quassel@95.179.151.101] has joined ##taproot-activation
19:55 -!- jtimon_ [~quassel@90.166.158.146.dynamic.jazztel.es] has joined ##taproot-activation
19:55 < rusty> jeremyrubin: oh yeah, not helping :)
19:55 < luke-jr> rusty: I mean upgrading a node after activation isn't
19:56 < rusty> luke-jr: oh really?  Hmm, that's fucked,
19:56 < luke-jr> Segwit did have something for that, but that was because of refetching needed
19:56 < jeremyrubin> luke-jr: oh because of caching and stuff?
19:57 < luke-jr> jeremyrubin: yeah, we never recheck the old blocks typically
19:57 < luke-jr> except to a limited extent after a reorg
19:57 < jeremyrubin> luke-jr: but doesn't a soft fork make this safe?
19:58 < luke-jr> jeremyrubin: not if you've accept an invalid block..
19:58 < luke-jr> the other way is actually safer
19:59 < roconnor> ... maybe we should fix this before writing a configuration option ...
19:59 -!- matt1 [~matt@178.128.230.221] has joined ##taproot-activation
19:59 -!- meshcoll- [meshcollid@gateway/shell/ircnow/x-fxgnvsfciueukqqj] has joined ##taproot-activation
19:59 < luke-jr> if we reject a block early enough (as with LOT=True), we recheck the header every time a node tries to sell us on it
19:59 -!- Netsplit *.net <-> *.split quits: wumpus, pigeons, andytoshi, bob333, criley_, RusAlex, meshcollider, livestradamus, pinheadmz, mblackmblack,  (+3 more, use /NETSPLIT to show all of them)
19:59 < luke-jr> roconnor: why?
19:59 -!- Netsplit over, joins: bob333
19:59 < luke-jr> again, it's never been a blocker for other softforks..
20:00 < roconnor> I don't know.  If I were late upgrading, I'd like to recheck the chain.
20:00 < luke-jr> roconnor: most users already don't with assumevalid :/
20:01 -!- Netsplit over, joins: nickler
20:02 -!- Netsplit over, joins: RusAlex
20:02 < jeremyrubin> I don't see how you could accept an invalid block tho
20:02 < jeremyrubin> WHen would that happen ?
20:02 < luke-jr> your old node
20:03 < roconnor> luke-jr: oh right people use assumevalid.
20:05 < jeremyrubin> but people don't update assumevalid params often?
20:05 < jeremyrubin> luke-jr: I think this isn't about an old node, this is about a new node that has activation rules
20:07 < roconnor> jeremyrubin: if a chain following that doesn't follow the new soft fork rules has more total work, and you are late upgrading your node, you will have already accepted invalid blocks and when you finally upgrade your new node you will be stuck until the "correct chain" catches upto you, which may not even happen if subsequent blocks on the invalid chain happen to be valid according to the new soft-fork rules.
20:08 < roconnor> Um I meant to start that with "if a chain that doesn't follow"
20:09 < jeremyrubin> roconnor: so mostly an issue with switching on LOT=true
20:11 < roconnor> for this particular scenario, I think you are correct.
20:11 < jeremyrubin> FWIW the script caches are OK
20:11 < jeremyrubin> they commit to the consensus flags used
20:11 < jeremyrubin> therefore as long as a soft fork uses consensus flags, we won't accept invalid txns as a result
20:15 -!- niftynei [~niftynei@104.131.77.55] has joined ##taproot-activation
20:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
20:47 -!- shesek [~shesek@164.90.217.137] has joined ##taproot-activation
20:47 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
20:47 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
21:12 -!- CARO1 [~Cesar@2804:7f4:c29a:f13:7c3a:c9c7:c1a3:9e77] has joined ##taproot-activation
21:13 -!- CARO [~Cesar@2804:7f4:c29a:f13:c98:64f5:b539:ca3a] has quit [Ping timeout: 272 seconds]
21:29 -!- otoburb [~otoburb@unaffiliated/otoburb] has joined ##taproot-activation
21:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 245 seconds]
22:04 -!- jtimon_ [~quassel@90.166.158.146.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds]
23:00 -!- cguida1 [~Adium@2806:2f0:51c1:5cee:c47:230d:8185:8bec] has quit [Quit: Leaving.]
23:05 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
23:29 -!- jonatack [~jon@37.166.110.136] has joined ##taproot-activation
23:49 -!- jonatack [~jon@37.166.110.136] has quit [Read error: Connection reset by peer]
23:50 -!- jonatack [~jon@37.166.110.136] has joined ##taproot-activation
23:55 -!- pox [~pox@gateway/tor-sasl/pox] has quit [Quit: pox]
23:55 -!- pox [~pox@gateway/tor-sasl/pox] has joined ##taproot-activation
--- Log closed Tue Mar 09 00:00:51 2021