--- Log opened Tue Apr 20 00:00:31 2021
00:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
00:34 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Quit: Leaving]
01:16 -!- ctrlbreak [~ctrlbreak@159.2.165.130] has joined ##taproot-activation
01:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:47 -!- intx [intx@unaffiliated/intx] has left ##taproot-activation []
02:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
02:51 <@michaelfolkson> Some informative release notes from harding on the Core Taproot activation release https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.21.1-Release-Notes-draft
02:51 <@michaelfolkson> I think the only part I personally would dispute is "Should taproot not be locked in via Speedy Trial activation, it is expected that a followup activation mechanism will be deployed, with changes to address the reasons the Speedy Trial method failed."
02:52 <@michaelfolkson> I expect months of circular discussions like we had from February onwards. I think Core will find it hard to get consensus on anything.
02:54 <@michaelfolkson> If I had to guess the most likely scenario they would put out something compatible with the UASF release for say 6-12 months (but no LOT=true). Anything other than that would be highly controversial
02:54 <@michaelfolkson> But it is quite possible they don't release anything. There will be some serious disagreements
02:54 <@michaelfolkson> Re: "address the reasons the Speedy Trial method failed"
02:55 <@michaelfolkson> I'm not exactly sure what those reasons could be. Miners don't like Speedy Trial? Miners don't care about Taproot? Miners don't understand what is going on?
02:56 <@michaelfolkson> These reasons really should have been sought during the months of activation discussion. If we didn't get them then I'm not exactly sure how we are going to obtain miner feedback post Speedy Trial failing
02:57 <@michaelfolkson> Not signaling in itself provides zero feedback on the reasons for not signaling
03:02 <@michaelfolkson> Hence I think the interest in the UASF/ Core + Taproot (whatever it is called) will really pick up if Speedy Trial fails to activate. I suspect there will be a lot of people who will stay coy until that happens but then will vocally support it and run it
03:03 <@michaelfolkson> Choosing between repeating the circular arguments for months and just running UASF/ Core + Taproot seems like a no brainer to me
03:05 <@michaelfolkson> (Unless of course Core somehow managed to merge and release something extremely aggressive towards UASF / Core + Taproot. Possible but *extremely* unlikely imo)
03:10 -!- viaj3ro [1f114650@ip1f114650.dynamic.kabel-deutschland.de] has joined ##taproot-activation
03:10 -!- jonatack [~jon@88.127.52.83] has quit [Ping timeout: 240 seconds]
03:11 -!- jonatack [jon@gateway/vpn/airvpn/jonatack] has joined ##taproot-activation
03:13 <@michaelfolkson> To do that they would need to act unilaterally without consulting the community. That would be very, very bold
03:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:26 <@michaelfolkson> I think during Speedy Trial I will run both Core 0.21.1 and Core + Taproot in my attempted neutral stance. But if Speedy Trial fails to activate I would find it very hard to stay neutral (with the current information available)
04:02 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
04:03 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
04:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
04:18 < instagibbs> fingers crossed be back never :)
04:18 -!- instagibbs [~greg@119247204116.ctinets.com] has left ##taproot-activation ["Leaving"]
04:21 < fanquake> 🤞
04:39 < viaj3ro> michaelfolkson I just read the logs and saw your confusion with how belcher changed his mind. I have spent (wasted?) many days now reading all the logs and all the discussions on github, the mailing list and even reddit and I have to agree with belcher! I came into this with the assumption that BIP8 with LOT=True would be the obviously best way
04:39 < viaj3ro> forward. I even changed the name of my 20 BTC Lightning node SilentBob into "SilentBob Taproot BIP8(true, 1y)" for a long time: https://1ml.com/node/02e9046555a9665145b0dbd7f135744598418df7d61d3660659641886ef1274844/history
04:39 < viaj3ro> But after reading everything I could find I have to say that the other side just has the better arguments. Forced signaling has very real downsides. BIP8 has real downsides and clearly no consensus. Luke and you still insisting that it has, is very deceptive. Naming your alternative client core based is very deceptive and bordering into malicious,
04:39 < viaj3ro> not clearly stating all the risks of running this core incompatible client is VERY deceptive. For me, this movement has lost all credibility.
04:41 <@michaelfolkson> viaj3ro: No confusion on people changing their mind. Just enquiring on whether belcher had that view during the meeting and didn't say anything
04:42 <@michaelfolkson> viaj3ro: And on " Forced signaling has very real downsides. BIP8 has real downsides" I don't disagree with you that forced signaling has some downsides. Everything has some downsides. There is no magic bullet in my eyes
04:43 <@michaelfolkson> viaj3ro: "clearly no consensus" This is at best disputed. The community meetings in February had near universal support of using BIP 8
04:43 < viaj3ro> exactly. this is why still opposing ST and even releasing a deceptive alternative client is very questionable
04:44 -!- CARO2 [~Cesar@2804:7f4:c29e:157f:101:eee4:6455:2b6] has joined ##taproot-activation
04:44 -!- CARO [~Cesar@2804:7f4:c1a2:12ce:7c3a:c9c7:c1a3:9e77] has quit [Ping timeout: 260 seconds]
04:45 <@michaelfolkson> I am not opposing ST. I opposed Core using a mix of MTP and block heights in their ST and all the time wasted over that. I opposed no smooth PR review path on ST
04:45 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
04:46 <@michaelfolkson> The Bitcoin Taproot client (or whatever it is called) implements ST. So I don't know how it opposes it
04:46 < viaj3ro> maybe it had consensus at one point before there was discussion about what LOT value to chose. Now it clearly has no consensus anymore and most seem to prefer mixed hight and MTP. It clearly never had consensus around the LOT value. So still insisting it has consensus ist just plain wrong.
04:47 < viaj3ro> BIP8 I mean
04:47 <@michaelfolkson> With respect I disagree. Most reviewers expressed a preference for a consistent use of block height. On the PR only aj NACKed using a consistent use of block height
04:47 < aj> michaelfolkson: "I am not opposing ST" // "I'm a NACK on Speedy Trial" -- https://gist.github.com/michaelfolkson/92899f27f1ab30aa2ebee82314f8fe7f#gistcomment-3695024
04:47 <@michaelfolkson> aj: Read the rationale for it
04:48 < viaj3ro> all these people changed their mind after new information was available
04:48 <@michaelfolkson> I did not support all the time wasted over your insistence in using a mix of MTP and block height aj (as you well know)
04:48 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
04:49 < aj> michaelfolkson: yet you're continuing to waste time on it
04:49 <@michaelfolkson> viaj3ro: Incorrect. They ACKed the PR but they never changed their minds on their slight preference for consistent use of block height (on the PR at least)
04:50 <@michaelfolkson> aj: You are telling me I oppose Speedy Trial. I am explaining in response why I NACKed it. If I'm wasting time you're wasting time asking me about it
04:50 < viaj3ro> I agree that it was a bit weird that the BIP author opposed BIP8 due to testnets and @JeremyRubin just to throw a stick into any UASF efforts but it doesn't change that a mix of heights and MTP can mitigate real downsides of both, BIP9 and BIP8
04:50 < aj> michaelfolkson: i'm just pasting what you said, since you're lying about not opposing speedy trial
04:51 <@michaelfolkson> viaj3ro: I don't think it can mitigate any downsides. I haven't seen that rationale either
04:52 <@michaelfolkson> aj: I will be running Core and Bitcoin Taproot that implement Speedy Trial. If that is opposing it, sure
04:52 < viaj3ro> and that is why everyone is now supporting mix of hights and MTP and a few guys still claiming BIP8 has consensus is getting stranger and stranger by the day
04:53 < viaj3ro> the argument was made in the github discussion
04:53 < aj> viaj3ro: (if you're actually interested, there were multiple reasons why times are preferable -- smaller changes, easier backport, compatibility with testnet, ease of future implementation of deployments for signet; ease of selecting sane parameters in future)
04:53 < viaj3ro> only real downside left for the mixed approach is possibility of timewarp attacks which are super unlikely and can be easily fixed, if they should happen
04:54 <@michaelfolkson> viaj3ro: I just think that is narrative spinning personally but we can agree to disagree
04:55 <@michaelfolkson> Re: "claiming BIP8 has consensus is getting stranger and stranger by the day"
04:55 <@michaelfolkson> Nothing has happened to BIP 8. It has been revised to incorporate Speedy Trial which no other BIP has. If that is strange, well I don't know what to tell you
04:56 < viaj3ro> I read all the arguments for both sides. I don't have the technical knowledge to judge for myself but when >13 experienced developers agree with one side, and a single one disagrees for very questionable reasons I'm inclined to believe the vast majority
04:56 < aj> "which no other BIP has" is also a lie
04:56 < viaj3ro> This all seems like you and luke are just super pissed off that other people changed their minds
04:57 <@michaelfolkson> "13 experienced developers agree with one side" They expressed a slight preference for consistent block height. It was only aj who NACKed it :)
04:57 <@michaelfolkson> Maybe they'll all come out today and say they have changed their mind. But they didn't on the PR
04:57 < viaj3ro> well, they all changed their mind and now support hight & MTP. You just want to insist on them prefering purely hight while it isn't true anymore
04:58 <@michaelfolkson> viaj3ro: They haven't said they have changed their mind of consistent block height. They ACKed the PR despite a slight preference for consistent block height
04:58 <@michaelfolkson> No changing of mind declared
04:58 < viaj3ro> well, maybe they didn't even change their mind and just don't care about one tradeoff or the other since both are acceptable
04:59 <@michaelfolkson> They are free to all come out today and say they've changed their mind if they want to
04:59 <@michaelfolkson> aj: No activation BIP has been revised to incorporate Speedy Trial other than BIP 8 as we currently stand. Not a lie
05:00 <@michaelfolkson> viaj3ro: A competing PR was even opened because people didn't understand why aj was insistent on using mix of block height and MTP
05:00 < viaj3ro> why do you care so much? why repeating again and again how they all preferred hights at one point? everyone has moved on but you seem to be stuck in the paszt
05:00 <@michaelfolkson> viaj3ro: Because you are asking me about it. If you don't care don't ask me about it
05:01 < aj> michaelfolkson: bip 341 has been revised to document activation by speedy trial.
05:01 <@michaelfolkson> aj: Not a standalone activation BIP. That BIP outlines the soft fork changes.
05:01 < viaj3ro> well, I read the logs.... you keep repeating it everywhere. And now it has lead to a consensus incompatible client with a deceptive name which you also support
05:01 < viaj3ro> that's why I care
05:02 <@michaelfolkson> viaj3ro: Well maybe I care for same reasons you do. It is just I put the responsibility on one developer insisting on using a mix of block height and MTP
05:02 < viaj3ro> this will make it very difficult if miners indeed fail to activate ST. Almost nobody will run this rough client and core will most likely have to wait until this UASF fails in novemeber 22
05:02 < aj> michaelfolkson: you could also say "there hasn't been a bip authored by luke that documents it", but neither "authored by luke" nor "standalone" are important factors
05:03 < aj> viaj3ro: failure of ST is final by the time signalling ends, in mid-late august, so followup can begin then, it doesn't need to wait until november
05:03 <@michaelfolkson> aj: I asked you a month ago if you wanted me to work on a new BIP for Speedy Trial. You expressed no interest and said I was putting words in your mouth
05:04 < viaj3ro> anyway, I actually didN#t come here to waste even more time on this. I came here to ask, why luke is refusing to merge the BIP
05:04 < aj> michaelfolkson: yes, because i didn't think a separate bip was necessary or helpful, and it wasn't necessary. you've since demonstrated you're completely unhelpful...
05:04 < viaj3ro> and I also would like to understand why it is necessary that this BIP is merged (by luke)
05:04 < aj> viaj3ro: he claims to not be refusing to merge it, just to be otherwise occupied
05:05 < viaj3ro> https://github.com/bitcoin/bips/pull/1104 I mean
05:05 <@michaelfolkson> aj: Ok well it clearly was necessary (unless you think we should change a final BIP 9)
05:05 < aj> michaelfolkson: it is clearly not necessary, as the PR viaj3ro just referenced demonstates.
05:05 <@michaelfolkson> viaj3ro: I can't speak for Luke. I understand why it isn't an obvious merge. But I don't have merge access and tbh I'm not sure if it should be merged
05:05 < viaj3ro> @aj yeah I know. this claim sounds like bullshit to me
05:06 < viaj3ro> why does it need to be merged anyway?
05:06 < viaj3ro> RC1 is out already
05:06 <@michaelfolkson> aj: You want to use Speedy Trial again. You talked about signets with Speedy Trial for future soft forks. Therefore it needs to use a standalone activation BIP. I told you this a month ago
05:06 < aj> viaj3ro: so the expected behaviour is documented somewhere other than just in the code
05:06 < viaj3ro> does it need to be merged for a final release?
05:06 < aj> michaelfolkson: i wish you'd give me the same courtesy you give luke of not speaking for me.
05:07 < viaj3ro> @aj ah, I see. So it isn't strictly necessary? Just a nice to have?
05:07 <@michaelfolkson> aj: With regards to what specifically?
05:08 < aj> michaelfolkson: as i've said, probably repeatedly now, i do not think we should use precisely the same ST mechanism again, and i expect to improve on it prior to either a signet deployment of a new soft fork, or a UASF of taproot.
05:08 <@michaelfolkson> aj: Ok but that will need a new BIP right? Or do you think we should get in habit of shoehorning activation BIP changes into the soft fork BIPs that they are activating?
05:09 < aj> viaj3ro: the draft release notes reference the bip for the details of activation, so it will either need to be merged prior to then, or the release nodes will need changing. luke isn't the sole person with commit access from what i understand.
05:09 < viaj3ro> I see. Thanks for the xplanation
05:10 < aj> michaelfolkson: if the activation method is a one off, putting it in the sole BIP that it will be used for is perfectly reasonable, not "shoehorning", and there are more examples of doing it that way than there are of having a dedicated bip for an activation method
05:10 <@michaelfolkson> aj: I don't think I've said anywhere that you personally don't want to ever make changes to Speedy Trial (ie speaking for you)
05:10 < aj> "<michaelfolkson> aj: You want to use Speedy Trial again."
05:11 <@michaelfolkson> aj: That could be a revised Speedy Trial. Unless you want to change the name
05:17 < aj> it's software, "X could be Y" is almost always true. in this case it'd be a bad idea, since revising an activation bip that's already seen use on the network generally doesn't make sense -- once things are used on the network they get marked Final, and if you want to propose doing something different you draft a new BIP
05:27 <@michaelfolkson> We'll obviously sort out the Speedy Trial BIP at a later date (hopefully after Taproot has activated). But BIP 8 as it stands does incorporate Speedy Trial if block heights are used consistently. And as you know I (and others) think Core should have implemented consistent block heights independent of the BIP situation
05:53 -!- viaj3ro [1f114650@ip1f114650.dynamic.kabel-deutschland.de] has quit [Ping timeout: 240 seconds]
05:57 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
06:00 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
07:15 -!- duringo [ad004d11@173.0.77.17] has quit [Ping timeout: 240 seconds]
07:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
07:31 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
07:36 -!- duringo [ad004d53@173.0.77.83] has joined ##taproot-activation
08:00 -!- cguida [~Adium@2601:282:200:ae00:c0b3:1fe8:c368:43ba] has quit [Quit: Leaving.]
08:04 < luke-jr> [09:52:50] <michaelfolkson> I think Core will find it hard to get consensus on anything. <-- but the people in control of "Core" have just demonstrated they are willing to do things without consensus..
08:06 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
08:10 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
08:26 < Emcy> i had the same dispositional trajectory as viaj3ro fwiw
08:26 < Emcy> i think yall are on a folly currently
08:31 -!- cguida [~Adium@205.209.28.54] has joined ##taproot-activation
08:35 < luke-jr> Emcy: how? it's clearly nonsense
08:36 < Emcy> youre clearly nonsense my dude. i dont know what youre game really is.
08:37 < Emcy> are you just red teaming bitcoins processes or something?
08:37 < luke-jr> false premises all over viaj3ro's rant
08:37 < luke-jr> "now it has lead to a consensus incompatible client" <-- except that client is ST, not Core+Taproot
08:37 < luke-jr> "with a deceptive name" <-- it is exactly what it says it is
08:39 < luke-jr> unlike Bitcoin ST
08:39 -!- proofofkeags [~proofofke@97-118-239-55.hlrn.qwest.net] has quit [Ping timeout: 252 seconds]
08:40 < luke-jr> (calling itself "Core 0.21.1")
08:41 < Emcy> look im just telling you as a friend that people in bitcoin dev have always seen you as an esoteric character contributor to the project, and not unfondly, but now there is an opinion that youve gone rather too far this time with whatever point you are trying to make.
08:42 < Emcy> and frankly congratulations on keeping everyone on their toes, if thats what you want, because no one can seem to work out whether you are just red-teaming the project in some fashion, or if you actually believe that this little bubble of a handful of people you have ensconced yourself within represents 'consensus'
08:51 -!- cguida [~Adium@205.209.28.54] has quit [Quit: Leaving.]
08:51 < luke-jr> they're the ones disregarding the community outside their bubble.
08:53 -!- shesek [~shesek@164.90.217.137] has joined ##taproot-activation
08:53 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
08:53 -!- shesek [~shesek@unaffiliated/shesek] has joined ##taproot-activation
08:56 < copumpkin> out of curiosity, who other than you, mechanic, and taprooooga (who appears to be mechanic) has NACK'd it or spoken out against it?
08:56 < queip> aren't we all good? BC-btfc and BC0.21.1 have matching parameters, and especially if miners turn out to be good this time around all will go smoothly, right?
08:57 -!- Alexandre_Chery [9466b454@148.102.180.84] has joined ##taproot-activation
08:59 < luke-jr> copumpkin: not enough; but that's another topic
08:59 < luke-jr> copumpkin: even if the community accepts it post-hoc, it doesn't make disregarding the community and deploying it like this right
08:59 < luke-jr> copumpkin: much less the FUD campaign against BIP8 some of them have started
09:00 < copumpkin> luke-jr: I'm just trying to understand your position: you maintain that ST does not represent the consensus or community, but who is it not representing? you're an obvious example and that's unfortunate, but what would a successful ST launch have looked like to you? I think it's unrealistic to expect everyone to ACK, and if it hadn't been you disagreeing, I can imagine any number of other people NACKing something else, right?
09:01 < luke-jr> queip: well, I would consider miners "good" if they choose to wait until after ST to signal at this point; but possibly, if they take the other "good" of signalling right away
09:02 < luke-jr> copumpkin: BIP8 got conceptually reverted to BIP9 and rushed out by a handful of devs without even seeking any community support
09:02 < luke-jr> copumpkin: ST isn't the issue, BIP9 is
09:03 < Emcy> luke you cant just keep saying 'no u' about this, allright
09:04 < copumpkin> luke-jr: so what would a more correct process that led to BIP9 have looked like to you? more of adam3us's reddit posts polling people about whether MTP or height was the right thing? I'm just struggling a bit because I'm the community, Emcy's the community, there are lots of "non-devs" hanging out in here and opining on random stuff (probably more than we should tbh :P), so I'm not sure what more should have been done to make
09:04 < copumpkin>  the MTP thing legitimate in your eyes
09:04 < Emcy> its actually really unpleasant watching you self immolate your stature over this issue, seemingly over nothing at all. thats why people are wondering if youre got some ulterior motive with all this
09:06 < copumpkin> to put it differently: what's a process that makes a decision like that legitimate and community-based?
09:06 < copumpkin> and when is it warranted? do we have to raise questions about coding style?
09:06 < luke-jr> copumpkin: obviously not. this is a consensus-level change.
09:06 < copumpkin> most people would probably say no to that
09:06 < copumpkin> yeah, I know, that was rhetorical :)
09:07 -!- Alexandre_Chery [9466b454@148.102.180.84] has quit [Quit: Connection closed]
09:07 < luke-jr> copumpkin: frankly, I'm amazed that MTP was even considered seriously at all. it is strictly inferior, and has no real advantages. but having the public argument over BIP9 vs BIP8 *before* releasing it, would be what I would expect ethically
09:08 < luke-jr> instead of rushing BIP9 ST into 0.21.1 and starting a fight with the release
09:08 < luke-jr> ideally, it would also wait until the next softfork, since Taproot was already moving forward with BIP8
09:10 < copumpkin> but I'm just saying, you obviously think it's strictly inferior, but presumably there's a process by which the community could reach consensus in opposition to your thoughts on the matter?
09:10 < copumpkin> and I'm curious what that process would look like
09:10 < luke-jr> "but having the public argument over BIP9 vs BIP8 *before* releasing it, would be what I would expect ethically"
09:10 < luke-jr> [16:08:05] <luke-jr> instead of rushing BIP9 ST into 0.21.1 and starting a fight with the release
09:10 < copumpkin> I see
09:11 < Emcy> what has been rushed? taproot could have [should have?] been activated like 2 years ago already
09:12 < luke-jr> also, while nobody objected to BIP8 (until later), BIP9 has been contentious since 2017
09:12 < Emcy> from what i can gather the delays have been mostly borne of a kind of apathy
09:12 < luke-jr> Emcy: switching back to BIP9 was rushed
09:12 < copumpkin> and you do think average Joes could have an intelligent opinion on that question?
09:12 < copumpkin> I ask because I'm not sure I could, and I'm more involved than most of the community is
09:13 < luke-jr> copumpkin: that matters less than the principle of devs not deciding rules for everyone
09:14 < copumpkin> I do think it matters to some degree, because people break into factions very easily and pick opinions based on their preferred figurehead rather than any sort of technical merit, in the absence of technical understanding, and I don't think that's a good way to make decisions either
09:14 < Emcy> but they already dont
09:14 < mol_> luke-jr, you had almost 4 years to work on BIP8 but still couldn't get your supporters to agree on LOT parameters so i don't see how using BIP9 is a rush?
09:14 < Emcy> hold ign that core devs own/run bitcoin just because people are apathetic or whatever is bcasher logic
09:15 < luke-jr> copumpkin: even if we had to ignore some part of the community in the end, that is better than ignorign the community's input altogether
09:16 < luke-jr> copumpkin: but since BIP8 had broad support, there was never a need to ignore it either
09:17 < mol_> BIP8 had "broad support" only in theory
09:18 < mol_> it's like in theory i could fly a plane but in reality i can't
09:19 < copumpkin> I don't think it's ignoring it altogether though. The thinking went, as I understand it, "we can't agree on LOT true/false, so let's go for a speedy trial and if that fails we'll try something else: everyone seems to very tentatively agree on that; oh shit, we need to decide on trial activation too; shit, height-based will hurt signet, which would be sad, and MTP won't, but is a bit more complicated; most people would prefer
09:19 < copumpkin>  simpler but also don't want to hurt signet, so MTP isn't the end of the world and lets us move forward"
09:19 < Emcy> luke-jr i gave you an example of how bip8s 'broad support' [me, and that other guy up there] has changed in the meantime
09:19 < Emcy> and you dismissed it
09:19 < Emcy> and you dismissed him too
09:19 < queip> I would imagine community can mostly decisions like "privacy good - taproot good" based on experts saying taproot=privacy, and only can chime in with uprising in case if someone proves certain information from devels was not the full truth and recruits support
09:20 < luke-jr> copumpkin: BIP8 was already moving forward by then
09:20 < luke-jr> Emcy: [15:59:21] <luke-jr> copumpkin: even if the community accepts it post-hoc, it doesn't make disregarding the community and deploying it like this right
09:21 < copumpkin> luke-jr: but it kinda wasn't, as evidenced by all the drama and the fact that it didn't actually get merged. People realize stuff like "damn, the signet thing is unfortunate, if only there were another way" and that doesn't make it a big conspiracy to kill bip8
09:21 < luke-jr> copumpkin: it would have been just as easy to merge BIP8 ST as it was to merge BIP9 ST
09:22 < copumpkin> yes, with more deferred cost
09:22 < luke-jr> and the signet thing shouldn't even be a concern. if it's going to disrupt mainnet, we should remove signet.
09:22 < luke-jr> copumpkin: no cost at all
09:22 < copumpkin> or we can pay a bit more upfront cost and maintain the investment?
09:22 < queip> tbh I would say community does not really care about timebased or heightbased activation, this is a detail of a detail
09:23 < luke-jr> copumpkin: BIP9 is worse upfront and long-term
09:24 < copumpkin> luke-jr: the main cost of signet tbh seems to be the drama you're kicking up over the MTP-based ST :) almost everyone else was just like "oh yeah that would be a pity, let's just make the adjustment to keep it happy"
09:24 < queip> luke-jr: what it is that you are saying would be better here, to probe community opinions more before deciding to use MTP?
09:25 < luke-jr> copumpkin: that's not how it went.
09:25 < copumpkin> oh, sorry
09:25 < luke-jr> queip: as a bare ethical minimum, yes; but ideally MTP should never have even been considered
09:26 < copumpkin> there are other advantages to thinking in "human time" though, right? even if it can be off by a bit?
09:26 < luke-jr> copumpkin: you can do that with heights too
09:26 < luke-jr> UNIX epoch seconds are not any easier to work with than height
09:26 < queip> luke-jr: how can I determine if your opinion about MTP is so correct it is not even worth considering otherwise? MTP doesn't have any grave problems besides being a bit harder to  code, and somewhat less ellegant in a way?
09:27 < luke-jr> and BIP9 isn't *really* human time - it's just using human time (as claimed by miners) determine what heights to use
09:27 < queip> if I understood you guys, then arg for MTP is that the signet is ready for it, and we do not want to also mess with signet rn (many moving parts)?
09:27 < luke-jr> queip: it has several grave problems, which would require hacks to workaround
09:27 < copumpkin> yes, but that's the best proxy we have for human time, right? :P
09:27 < luke-jr> queip: and one which is insurmountable in this specific case
09:28 < luke-jr> copumpkin: ?
09:28 < queip> well blockchain prooves to be one of most uncorruptable clocks existing in internet (with ~  +-2 h granulity)
09:29 < queip> luke-jr: what are insurmountable critical problems with MTP usage here?
09:29 < luke-jr> queip: when I asked the other day, harding said it was viable to game BIP9's clock, and using BIP8 to implement ST would be dishonest
09:29 < luke-jr> queip: I cannot support both BIP9 ST and BIP8 as options within Knots. I am now forced to only support one activation option.
09:30 < luke-jr> BIP8 ST vs full BIP8, would have been trivial
09:30 < luke-jr> also note the signet concerns *do not even exist* for Taproot. they are strictly hypothetical for the next softfork after Taproot.
09:30 < luke-jr> Taproot has always been ALWAYS_ACTIVE on Signet
09:32 < queip> was this like of for/against arguments evaluated with other core developers? did it also ended at that there is no reason for MTP if you say signet doesnt need it after all?
09:32 < queip> *this line
09:33 < luke-jr> it was pretty much just aj pushing for MTP until the coinflip nonsense
09:34 < luke-jr> and none of this is new arguments; whether other devs evaluated it or ignored it, I can't say
09:35 -!- roconnor [~roconnor@host-45-58-216-246.dyn.295.ca] has joined ##taproot-activation
09:36 < queip> srsly no one talked with regular core devs about it before I asked just now?
09:36 < queip> aj: are there any arguments for SMT, if that is true that signet does not need it (which I now thought is the arg)?
09:37 < roconnor> The argument somehow consensus was reached on height over MTP in BIP8 is analogous to arguing that consensus was reach on a 1 year time out, and therefore Speedy Trial "must be going against consensus" because it is using a 3mo timeout instead of a 1y timeout.
09:38 < roconnor> Even if you accepted that somehow consensus was reached regarding BIP8 (something that I dispute) the fact that it didn't reach an agreement on the LOT parameter simply means that no consensus was reach at all at the time.
09:38 < queip> luke-jr: by gaming the clock, you mean that miners would game and permanently offset (e.g. few weeks ahead or something) the block timestamps?
09:38 < luke-jr> queip: not necessarily permanently
09:39 < queip> how this attack works? and what it achieves, I guess chaos? or something else too?
09:39 <@michaelfolkson> queip: If you want to look at what PR reviewers said on consistent block height versus mix of MTP and block height see this: https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277
09:41 <@michaelfolkson> queip: You can read what aj said on Andrew's PR. Today he also said this:
09:41 <@michaelfolkson> "<aj> viaj3ro: (if you're actually interested, there were multiple reasons why times are preferable -- smaller changes, easier backport, compatibility with testnet, ease of future implementation of deployments for signet; ease of selecting sane parameters in future)"
09:41 < luke-jr> queip: it would achieve making Core use heights different from the intended ones
09:41 < luke-jr> BIP9 ST Core*
09:42 <@michaelfolkson> <luke-jr> [09:52:50] <michaelfolkson> I think Core will find it hard to get consensus on anything. <-- but the people in control of "Core" have just demonstrated they are willing to do things without consensus..
09:42 < luke-jr> p.s. it was aj that made backporting BIP8 larger than it had to be - originally it was trivial
09:42 <@michaelfolkson> I disagree on this Luke. It had the ACKs to merge. I think a number of reviewers were frustrated by the delay due to aj insistence on using MTP and block height though
09:43 < luke-jr> michaelfolkson: it had NACKs. it had no community support.
09:43 < luke-jr> that isn't consensus.
09:43 <@michaelfolkson> Core reviewers ACKed it. It was up to them to assess whether they were happy it had community support or not
09:43 < roconnor> NACKs need to have reasons behind them.
09:43 < luke-jr> roconnor: which they did
09:44 < queip> uh, I guess anything might have "an NACK". I can log in rn to gh and add NACK to whatever, so can any e.g. altcoin troll
09:44 < luke-jr> michaelfolkson: that's just movign the goalposts
09:44 < queip> (saying in general) or did you meant some "more meritful" nack/ack
09:44 <@michaelfolkson> queip: These are regular Core contributors or at least long term developers in the ecosystem that are well known
09:44 < roconnor> the reason given was that "this PR doesn't have conensus" but in order to not have consensus a reason still has to be given.
09:44 <@michaelfolkson> queip: I didn't include random people I didn't know NACKs
09:45 <@michaelfolkson> queip: Not that there were any I don't think
09:46 <@michaelfolkson> roconnor: maaku's NACK for MTP had lots of commentary
09:46 <@michaelfolkson> roconnor: Not on the PR but I linked to it
09:46 < queip> luke-jr: how big of a problem it is in case if we would indeed and up few blocks sooner or later in terms of height compared to what was estimated, as long as everyone also uses MTP?
09:46 < luke-jr> queip: everyone is not using MTP in fact
09:47 < luke-jr> queip: and it wouldn't be a few blocks
09:47 < queip> sure, but there might.  if only problem in using MTP is label_1: that it will not use if not everyone uses it and not everyone should use it since goto label_1 then it's just cricular ;)
09:47 < luke-jr> queip: in the extreme case we saw in 2017, it could have easily been enough to prevent activation entirely
09:47 < queip> sure, but there might.  if only problem in using MTP is label_1: that it will not WORK if not everyone uses it and not everyone should use it since goto label_1 then it's just cricular ;)
09:48 < luke-jr> (and note that in non-extreme cases, the timeout time/height doesn't even matter at all)
09:48 < queip> ok preventing actication is obviously bad.. but can this happen in "current MTP first, then MTP + N blocks delay" model?
09:49 < queip> ok preventing actication is obviously bad.. but can this happen in current "MTP first, then MTP + N blocks delay" model?
09:49 <@michaelfolkson> This BIP 8 not having consensus thing... I understand what they are trying to do lol. But it is nonsense.
09:50 <@michaelfolkson> Everyone was happy with BIP 8 in the community meetings.
09:50 < queip> I'm felling we can get to the bottom of MTP/height rn
09:51 <@michaelfolkson> You can't say "Oh look we don't know what to set this parameter to therefore we need to throw out BIP 8 even though everyone was happy with it in community meetings and on the mailing list"
09:51 <@michaelfolkson> The twisted logic some people are attempting is actually quite funny
09:52 < luke-jr> queip: you expect them to stop this BIP9 ST release?
09:52 < luke-jr> if not, then no, we can't
09:53 < queip> luke-jr: well I can understand all the known arguments after getting them. is this actionable or not actionable can be seen right after
09:53 < roconnor> having an IRC meeting is not sufficent to get consensus by itself.
09:53 < luke-jr> afraid it isn't actionable at this point
09:53 < queip> no worries I just would like to understand it, if no one minds. also good education etc
09:53 < roconnor> The most you can do is get consensus amoung the attendees.
09:54 <@michaelfolkson> roconnor: True. It was very well attended though. There was an agenda on the mailing list and I wrote up notes afterwards for the mailing list. Ample opportunity to raise opposition to it for weeks
09:54 < luke-jr> roconnor: even if imperfect, it was still far better than the outright ignoring the need for consensus before pushing BIP9 back in
09:55 < roconnor> and then AJ and harding did raise concerns.
09:55 < luke-jr> not to mention, BIP9 didn't actually solve any of the issues surrounding BIP8
09:55 < luke-jr> roconnor: where?
09:55 < luke-jr> when AJ opened that PR, it was claimed that it was just a first-step, and heights would be merged after it
09:55 <@michaelfolkson> roconnor: When? AJ helped finalize BIP 8. He had ample opportunity to raise opposition to it
09:56 < roconnor> luke-jr: your concerns did not have actuals reasons behind them.  All you said was "I had an IRC meeting"
09:56 < roconnor> (exaggerating, sorry)
09:56 < luke-jr> lolwut
09:56 < queip> wait, aj was the only out of the ~12 developers who nacked/acked and resulted in switch to MTP?
09:56 < luke-jr> roconnor: that's just completely false
09:56 < luke-jr> queip: yes
09:56 < queip> lmao
09:56 <@michaelfolkson> queip: Indeed. He was the author of the PR that actually got merged and he NACKed Andrew Chow's PR
09:56 < roconnor> luke-jr: I appologize for my exageration. Sorry.
09:57 <@michaelfolkson> queip: But yes we have MTP because of aj as far as I can work out
09:57 < luke-jr> and several pretended that because achow took up BIP8 ST, that achow closing his PR was a death knell for BIP8
09:57 < roconnor> luke-jr: none the less I was never able to get anything more from you than "this goes against consensus" and that statement was never justified.
09:57 < queip> if that was a mistake then we should try to reverse it.  if we can't then no problem, will be more proactive next time
09:57 <@michaelfolkson> When clearly Andrew was just frustrated with aj insisting on MTP
09:57 < queip> *if*
09:57 < luke-jr> roconnor: I went over the reasons several times, as did others..
09:58 < roconnor> luke-jr: all I got from you was. statment like "it's obvious to everyone" and so forth.
09:58 < roconnor> It was very unconvincing.
09:59 <@michaelfolkson> I do think luke-jr NACKs could be improved with more commentary. But I collected together all the reviewer feedback if you were interested in why luke-jr opposed it roconnor
09:59 <@michaelfolkson> You only had to scan over the PR to see why others preferred block heights (including yourself)
10:00 < roconnor> my preference for heights never meant that I didn't find MTP acceptable.
10:00 < queip> interesting. I will get some (c++) devels and alike interested. over few days we can have a meeting maybe
10:02 <@michaelfolkson> roconnor: Indeed. I included you in the minor preference bucket https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-818758277
10:02 < roconnor> And even if there was consensus reached on the acceptablity of height based activation doesn't mean there was consensus reached on the unacceptability of MTP.
10:02 < queip> if we would all agree that ( height is better than MTP ) && ( it is worth putting effort into it ) then we can put out nice arguments and open issue with Core to reconsider. How long time we have to do that, I guess it must be accepted months before the start date right? so... before..... ?
10:02 < luke-jr> roconnor: the latter was reached in 2017 when it failed and we had to rush out BIP148
10:02 <@michaelfolkson> roconnor: Andrew opened his competing PR just for the fun of it did he?
10:03 < luke-jr> queip: I mean, that was pretty much already done, and ignored..
10:03 < roconnor> michaelfolkson: Andrew and AJ's PR were both considered acceptable to many people. And each author thought their PR was better than the other.
10:03 < roconnor> but that doesn't mean that Andy didn't find AJ's PR acceptable.
10:03 < queip> luke-jr: where is the best summary of arguments and discussion of them that was presented? sometimes arguments go in at 2nd attempt, e.g. better worded
10:03 <@michaelfolkson> roconnor: But what was the motivation for Andrew spending time to open a competing PR in the first place?
10:03 < luke-jr> queip: now that they've got a rc1, I doubt anything will stop it
10:04 < luke-jr> on my part, I've given up on trying to
10:04 <@michaelfolkson> roconnor: As I understood it, it was frustration at aj insisting on mix of MTP and block height
10:04 < roconnor> michaelfolkson: Because he thought it would be better, and if AJ found it acceptable along with a broad consensus then it would have been merged.
10:04 <@michaelfolkson> roconnor: Ok
10:04 < roconnor> eventually AJ's PR did incorporate part of Andy's PR (height based min-height).
10:05 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
10:05 < roconnor> When AJ and andy came together with an acceptable solution that they were both happy with, it was Andy's PR that was closed because AJ's PR happened to be the one that was easier to edit.
10:06 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation
10:06 <@michaelfolkson> Hmm. Andrew said he asked aj to use consistent block heights and he refused (presumably before opening his PR)
10:06 < luke-jr> >implying this was only between AJ and Andy
10:06 <@michaelfolkson> But whatever. We're stuck with mix of MTP and block height
10:07 < queip> this might be good list of arguments - "ST|BIP9|MTP is compatible with activating future soft forks on signet" and more, from harding on https://github.com/bitcoin/bitcoin/pull/21377#issuecomment-819896214
10:07 < luke-jr> unless ~everyone just ignores BIP9 ST releases
10:07 <@michaelfolkson> luke-jr: I don't necessarily agree with you that technical minutia needs to be discussed in community meetings. I think developers should handle that
10:08 <@michaelfolkson> luke-jr: Otherwise you get community meetings with few people doing coin flips and such like
10:08  * queip wishes he had taken more interest a month ago, on BH|MTP
10:08 <@michaelfolkson> But the fact is most reviewers preferred consistent block height and only aj NACKed it
10:08 < roconnor> the mix of MTP and block height addresses the most serious of concerns of both parties.  Using height based min-activation solve the concern about reorgs abruptly changing the activation time by 2 weeks (at or near activaiton time), and signet only needs the signalling start and end times to be date based and will use a minheight of 0.
10:08 < luke-jr> michaelfolkson: when it challenges something the community has already gone to the trouble to come to consensus on, it's different
10:09 <@michaelfolkson> luke-jr: Right it was very sneaky to include the BIP 9 option in the Speedy Trial proposal. I never envisaged someone would actually insist on using mix of MTP and block height
10:10 < queip> what is realistically at stake THIS TIME?  I get it that for future community should be more active
10:10 <@michaelfolkson> luke-jr: Given where we were discussing what the LOT parameter should be set to in BIP 8
10:10 < queip> -> lesson learned: start gathering community support and all 1 month faster. e.g. had this channel, this talks etc be done 1 month prior
10:10 < queip> *community interest
10:10 < luke-jr> queip: at stake is a bad precedent; I think that might be it practically speaking
10:11 < luke-jr> queip: also, I'm left with literally no good options for a Knots release
10:11 < queip> and this time, how realistic it would be that MTP can be really used to damage the process, like 0 activation period or not allowing it to activate etc
10:11 < luke-jr> queip: we did!
10:11 < queip> luke-jr: I mean 1 more earlier compared to what was done
10:11 < luke-jr> queip: BIP8 & params were chosen in February
10:11 <@michaelfolkson> quiep: We started end of January I think
10:11 < queip> luke-jr: I mean 1 month earlier compared to what was done. so, would need to be e.g. Nov 2020
10:12 < queip> community is slow etc *shrug* :)
10:12 < luke-jr> queip: this other nonsense all popped up after BIP8 activation was chosen etc
10:12 < queip> ok then I  guess lesson learned community needs to take interest faster
10:12 < roconnor> luke-jr: decisions aren't made at IRC meetings. Nothing was chosen.
10:12 < luke-jr> community isn't the problem
10:12 < luke-jr> niche of devs ignoring the communtiy is
10:13 < queip> well I'm the community and I "activated" too late in this discussion (due to real life things)
10:13 <@michaelfolkson> roconnor: I will repeat. Agenda on mailing list. Very well attended meeting (~100+). Meeting notes sent to mailing list. Open IRC channel 24/7 to discuss it.
10:13 < roconnor> luke-jr: also agreement on the acceptabliltiy of height based activation doens't imply agreement on unacceptablity of MTP.
10:13 < roconnor> michaelfolkson: still not how decisions are made.
10:13 < queip> luke-jr: besides precedent, and Knots, no real danger of somehow destroying the ST or taproot activation or something?
10:14 <@michaelfolkson> roconnor: I'm open to hearing your process on how decisions are made
10:14 < roconnor> michaelfolkson: not saying meetings aren't useful.  They are good.  They hammer out arguments, and can in some cases form consensus amoung the attendees.
10:14 <@michaelfolkson> roconnor: Especially when it comes to assessing community consensus. Perhaps you want to do some door knocking next time
10:14 < luke-jr> queip: only if miners act maliciously
10:16 < roconnor> The scaling bitcoin meetings in the past had a "no decisions will be made rule" and that is probably a model worth following.
10:16 <@michaelfolkson> roconnor: We also had taprootactivation.com for mining pools. We had AJ's developer survey. If you thought we did a bad job of assessing community consensus you should have stepped in and done some yourself
10:17 < roconnor> a meeting is a good tool for assesing community conesnsus.
10:18 < roconnor> I'm just saying that you cannot draw conclusions from that alone.
10:18 < roconnor> I even agree that height based activation does have broad community support.
10:19 < roconnor> but that doesn't mean that MTP based activation does not.
10:19 < roconnor> Any more than the fact that there was broad agreement for 1y signalling period implies that there isn't support for a 3m signaling period.
10:19 < luke-jr> roconnor: MTP based hasn't since 2017
10:19 < luke-jr> 3m is a subset of 1y
10:20 < roconnor> luke-jr: you keep making these statements about community support without providing justfication.  You are doing it again.
10:20 < luke-jr> people who want 1y can do 1y without contradicting 3m, provided BIP8 (or BIP9) is used for both
10:20 < luke-jr> roconnor: you were here back then.. -.-
10:20 <@michaelfolkson> I think its sneaky to try to avoid using BIP 8 after all that community outreach. Very sneaky
10:21 <@michaelfolkson> There was at least a month to raise objections to BIP 8 and multiple avenues to do so
10:21 < roconnor> height based activation having broad community support t doesn't mean that MTP based activation does not have support.
10:22 < roconnor> michaelfolkson: aj and harding did raise objections.
10:22 < luke-jr> roconnor: my point wasn't that MTP has zero support
10:22 -!- smurfjack [~smurfjack@101.85.87.130] has joined ##taproot-activation
10:23 <@michaelfolkson> roconnor: You have links? What date did they? aj helped finalize BIP 8 (prior to the Speedy Trial adjustment)
10:23 < roconnor> luke-jr: no your claim was that MTP doesn't have board community support, but your only justification provided was the claim that height-based does.
10:24 < roconnor> michaelfolkson: why does the date matter?
10:25 < luke-jr> roconnor: because BIP8 activation was already being prepared for release at that point
10:25 <@michaelfolkson> roconnor: Because I wasn't aware of them when we did that community outreach
10:25 <@michaelfolkson> roconnor: Generally it is better to raise objections before changes are merged rather than after
10:26 < roconnor> I agree.  You'll have to ask aj, but maybe he didn't consider the interaction with signet until development time.
10:27 <@michaelfolkson> roconnor: A test network? Throwing a spanner in activation on mainnet? Dear oh dear
10:28 < roconnor> Look, I don't agree with AJ's assesment myself as you well know, but I still respect that, until we have end-to-end formal verification, testability of code is a dimension that code is a consideration.
10:29 < roconnor> Things hadn't been merged.  It was a fine time to raise these considerations.
10:29 <@michaelfolkson> roconnor: Ok
10:29 < roconnor> I've raised considerations for consensus code even after it has been merged before.
10:30 <@michaelfolkson> Right and you should if you weren't able to raise them pre-merge for whatever reason
10:30 < roconnor> Yes, it would have been better if I had raised them earlier, and I'm sorry that I'm wasn't devoting 100% of my attention at all times to conesensus code mergers.
10:31 <@michaelfolkson> But aj wasn't a last minute reviewer on BIP 8. He was involved in activation discussion all the way
10:31 <@michaelfolkson> It is more understandable when you are a last minute reviewer and you haven't thought it through in advance
10:31 < roconnor> And signet feels exactly like the sort of consideration that wouldn't occur to someone until really digging into a real PR.
10:32 < roconnor> Because there you are finally looking and considering all the code paths that will traverse these changes.
10:32 < roconnor> and lo and behold signet is on that path.
10:32 <@michaelfolkson> Maybe. As I said it isn't a reason to NACK activation parameters on mainnet
10:33 < roconnor> AJ thinks it is.
10:33 < luke-jr> then we should revert Signet entirely
10:34 < roconnor> So we can either convince AJ he is wrong, or we can build consensus if the alterantive is still acceptable, without conceeding that his concerns are worthwhile.
10:35 <@michaelfolkson> Bonfire of signet for causing this headache. In reality I don't think that was actually the reason. I think it was a successful attempt to avoid using BIP 8 and trying to make a future UASF more difficult
10:35 <@michaelfolkson> But obviously no one is going to say that
10:35 <@michaelfolkson> So instead we're left with a rationale that signet somehow influences mainnet activation parameters
10:36 <@michaelfolkson> Which is an interesting perspective
10:39 < roconnor> I'm sorry that you think that aj's arguing in bad faith.  I don't think there is anything else I can add.
10:39 -!- roconnor [~roconnor@host-45-58-216-246.dyn.295.ca] has left ##taproot-activation ["Konversation terminated!"]
10:40 < jonatack> just passing through...but i love using signet. starts up in 3 secs for me versus 100 for testnet. a real network. steady block emission. it's my go-to for testing PRs that don't require mainnet.
10:41 < luke-jr> jonatack: regtest?
10:41 < jonatack> that startup time is a game changer for people who test PRs
10:41 < jonatack> regtest takes 12 seconds
10:41 < jonatack> (for me)
10:41 < luke-jr> wut
10:41 < luke-jr> did you make a huge blockchain or something? O.o
10:41 <@michaelfolkson> jonatack: Agreed. Signet is cool, when it isn't causing a month of unnecessary activation discussion anyway
10:42 < jonatack> not arguing, but signet is my go-to
10:42 < jonatack> luke-jr: not that i know of :)
10:42 < luke-jr> note I don't really have anything against Signet either, aside from it being wielded to create problems for mainnet
10:42 < luke-jr> jonatack: that's very strange; I wonder why regtest would be slower
10:43 < jonatack> luke-jr: maybe it's just me because i do bitcoin dev with a 4-core laptop hehe
10:43 < jonatack> haven't upgraded since 2017
10:43 < jonatack> and it's a purism so the chip was behind a few years
10:47 < luke-jr> jonatack: well, I would still think Signet requires more to do at startup than regtest
10:47 < luke-jr> regtest is typically a near-empty chain, while Signet constantly grows
10:51 < jonatack> yeah idk, i run all the chains continually and only restart them to test things, just restarted regtest and signet back-to-back and signet was up 15 sec faster. regtest does show a long list of wtx mempool submissions. hmmm maybe it's using a big wallet i made for testing things.
10:52 < luke-jr> XD
10:52 < jonatack> your first question could be it heh
10:57 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
10:58 < jonatack> luke-jr: thanks. fresh wallet on regtest is near-instant. it's been so long that i'd forgotten it could be different.
11:01 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
11:07 -!- smurfjack [~smurfjack@101.85.87.130] has quit [Remote host closed the connection]
11:37 -!- duringo [ad004d53@173.0.77.83] has quit [Quit: Connection closed]
11:59 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
12:33 -!- proofofkeags [~proofofke@c-75-70-131-96.hsd1.co.comcast.net] has joined ##taproot-activation
12:37 -!- cguida [~Adium@c-75-70-131-96.hsd1.co.comcast.net] has joined ##taproot-activation
13:08 -!- ironhelix [~d@154.6.28.63] has joined ##taproot-activation
13:18 < queip> luke-jr: "This remains Concept NACK. It is contrary to the community consensus around BIP 8, and a technically inferior solution. Developers do not get to strong-arm protocol changes any more than miners do." https://github.com/bitcoin/bitcoin/pull/21377#pullrequestreview-635862452
13:19 < queip> in this you object to MTP instead of block height? or...?
13:19 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
13:20 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
13:26 < luke-jr> queip: ? yes, it's about MTP vs height; no, it's not just me alone
13:37 < queip> thx, just confirming it is about this part only
13:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
13:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
13:52 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 252 seconds]
14:02 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
14:03 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
14:12 -!- graeme1 [~graeme@gateway/tor-sasl/welkinatdusk] has joined ##taproot-activation
14:21 < graeme1> speaking as an outside observer learning more about bitcoin technicals, the argument that a testnet like signet should not affect mainnet seems kind of strange to me. perhaps I don't understand the point... in most large software projects, testnets are extremely important. I understand that taproot is already active on signet due to the timing of everything, but wouldn't a future
14:21 < graeme1> softfork deploy on signet first? why isn't this a good idea?
14:21 < graeme1> the only argument I've seen so far is that testnet shouldn't matter, but that isn't very helpful for me trying to learn
14:22 < graeme1> is there a way for signet to be upgraded in such a way that it could be useful for a bip 8 style deployment? that to me seems like the more important point to elaborate on
14:36 < luke-jr> graeme1: nothing stops signets from using BIP8
14:37 < luke-jr> apparently the goal of BIP9 advocates, is to decide the protocol of all signets at once within Bitcoin Core
14:38 < luke-jr> (which is fine since they're testnets.. I wonder if somehow this is how the devs-decide mindset got extended to mainnet too..)
14:40 < mol> luke-jr, can you create your own signet?
14:40 < mol> i would love to see bip8 tested somewhere
14:42 < luke-jr> mol: shoo troll; BIP8 has automated regtest-based tests run alongside every other test
14:43 < mol> shoo troll? i haven't seen bip8 tested so im asking you
14:55 < robert_spigler> In the past few months, re: taproot activation, I've attended every IRC meeting, read all backlog, and all ML posts.  I was someone who was pushing for BIP8 LOT=true. I believe that BIP8 was gaining consensus, but with ongoing fights over the LOT parameter, ST was proposed. There was no binding process for BIP8. No one promised. No one signed a contract. I get it, it was a little disappointing. Sometimes
14:55 < robert_spigler> consensus requires not getting exactly what you want. With ST, it also seemed that achow's height based PR was getting more love. But all concerns were addressed with the mix of MTP and height. The only NACK was luke, who's argument was incredibly circular (it is NACK'd because the community supports it, which is obvious and everywhere and if you can't see it it's your fault). The consensus is fairly
14:55 < robert_spigler> obvious IMO, I have seen maybe 2 devs and 2 community members supporting the UASF client, and everyone else support the Core release.
14:56 -!- ironhelix [~d@154.6.28.63] has quit [Ping timeout: 265 seconds]
15:02 < graeme1> luke-jr: when you say using BIP9 decides the protocol of all signets within Bitcoin core what do you mean? is that different than if BIP8 was chosen?
15:05 < mol> from what i understand, signet is for private group testing, anyone can create their own signet, so im not sure what the problem is?
15:05 < graeme1> luke-jr: my understanding was that it is easier to bury deployments with BIP9? it sounds like you are saying it doesn't matter because individual signets can still test deployment with BIP8 either way, therefore the change to BIP9 makes no sense
15:08 < graeme1> this is all supremely confusing to sort out by the way. its very hard trying to sort through these technical arguments and make an informed decision, and posts that essentially just mock the idea of using signet for a deployment don't seem helpful at all... it implies that person has some special technical knowledge that is obvious to them
15:09 < graeme1> all I can say is that as a moderately technical bitcoin user I am having a ton of trouble sorting it out
15:18 < luke-jr> graeme1: there are an infinite number of signets, each potentially at completely different heights; so if BIP8 is used, each signet testing softfork activation needs to decide what heights to activate with; with BIP9, Core can set a time range to apply to all signets
15:19 < luke-jr> graeme1: and  no, it isn't any easier to bury BIP9
15:33 < aj> mol: if you've got a private trusted group, you can use regtest; signet is for collaborating more publicly with people you don't necessarily trust
15:33 < mol> aj, i see..
15:34 < Emcy> graeme1 you should understand that this debate, such as it is, doesnt appear to be soley based on technical considerations any more
15:34 < Emcy> so take care
15:34 < aj> mol: (the difference being that anyone can trivially reorg regtest; but you can only reorg signet if you have the signing key)
15:35 < mol> aj, can we create a signet to test luke's client?
15:37 < luke-jr> Emcy: yeah, unfortunately we're left guessing what the real motives are for shoving BIP9 back in :/
15:37 -!- ironhelix [~d@154.6.28.63] has joined ##taproot-activation
15:37 < aj> luke-jr: sure, that's the only option left after you rule out reading what people write
15:40 < aj> mol: you could change chainparams.cpp for signet on luke's client to use bip8 parameters instead of always active, then construct a signet using that client and signal activation. it wouldn't apply the same consensus rules as mainline code looking at the same signet (which always enforces taproot rules), and i don't think it'd give much benefit over using regtest to test it. if you wanted it to
15:40 < aj> work with multiple signets (ie, not just as a one-off test) you'd need to create some way of shipping around different bip8 parameters for different signets.
15:43 < Emcy> luke-jr no u
15:45 < mol> aj, i see..thanks for the explanation.. I guess regtest is sufficient
15:46 < luke-jr> aj: to date, I have not heard a plausible excuse. and arguments for BIP9 quickly turned into ad hominems and lies, so I don't have much reason to think one exists.
15:48 < queip> luke-jr: michaelfolkson <aj> says I think that MTP approach can avoid the attack with skipping over a period - https://github.com/bitcoin/bitcoin/pull/21392#issuecomment-808844563 - " mandatory signalling phase (UASF/bip148/bip91/etc) from being skipped entirely, even in the event of a substantial loss of hashrate. But those goals can be achieved with the MTP approach as well -- see the top commit on https://github.com/ajtowns/bitcoin/
15:48 < queip> commits/202103-bip9-uasf"
15:49 < queip> do we have here consensus that MTP avoid such attack?
15:51 < queip> that we can avoid this attack, following the direction currently undertaken by Core in recent version
15:51 < luke-jr> queip: every attack can have workarounds made. that's not a reason to avoid fixing it properly, and I would be completely shocked at this point if even the workaround got merged (as actual usage).
15:52 < queip> the current version in Core is vulnerable to it, luke-jr?
15:52 < luke-jr> especially when the fix is already done
15:52 < luke-jr> queip: yes, though it's not a real concern as-is
15:53 < queip> it IS vulerable? well, open bugreport/CVE?
15:53 < luke-jr> (because it'd be easier to just make it fail normally)
15:53 < aj> the current version in master is not vulnerable to skipping the signalling phase entirely in the way that bip9 potentially was; speedy trial does not have a mandatory signalling phase
15:57 < shinobiusmonk> MTP is just a general vulnerability, and timestamp logic in general still needs to be fixed
15:57 < shinobiusmonk> Mark Friedenbach has shown with his Forward Blocks "proposal" miners abusing timestamps can literally DoS the entire network into oblivion
15:58 < luke-jr> shinobiusmonk: miners can always do that..
15:58 < queip> aj: I start to think (maybe wrong) it was a mistake to jump to MTP while it has cons. if only you "voted" for it out of ~12 devels it doesn't help I guess
15:58 < shinobiusmonk> @luke-jr: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-August/016320.html
15:59 < shinobiusmonk> the timewarp attack needs fixing
15:59 < luke-jr> shinobiusmonk: fixing timewarp doesn't mean miners can't DoS the network..
15:59 < shinobiusmonk> it means they can't DoS it with effectively infinite data like Forward Blocks
15:59 < shinobiusmonk> that whole proposal is literally just about being able to spam nodes with blocks faster than they can validate and keep up with
16:00 < luke-jr> how is that any worse than just enforcing empty blocks?
16:00 < shinobiusmonk> because its not bloating the blockchain to the point that its literally impossible to validate
16:00 < queip> so... it was choosen to pick "easier usage of test network, but main network requires work (not yet fully done, pushed to future) to avoid future attacks" ?
16:01 < shinobiusmonk> Forward Blocks could
16:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:01 < luke-jr> shinobiusmonk: either way it becomes unusable
16:01 < shinobiusmonk> one becomes permanently unusable, one does not
16:01 < queip> we made testnet more secure against future problems (no need to config/sync params on testnets), instead of picking instead making mainnet more secure against future forks (need to fix timewrap) ?
16:01 < shinobiusmonk> consensus on miners doing that can change, shit tons of bloated data shoved into the chain can't just go away
16:03 < luke-jr> shinobiusmonk: both do, until action is taken, then neither do
16:03 < luke-jr> sure it can
16:03 < luke-jr> you reorg back to before the spam
16:04 < luke-jr> queip: that's the official story, anyway
16:04 < shinobiusmonk> good luck getting consensus on that luke-jr
16:05 < luke-jr> shinobiusmonk: I don't know why you expect that would be difficult
16:06 -!- proofofkeags_ [~proofofke@c-75-70-131-96.hsd1.co.comcast.net] has joined ##taproot-activation
16:06 -!- cguida1 [~Adium@c-75-70-131-96.hsd1.co.comcast.net] has joined ##taproot-activation
16:06 < queip> aj: if it is as above, why did we choose to attend more to security of testnet instead of mainnet? :o
16:06 < shinobiusmonk> @luke-jr: every block is a batch of completed economic transactions, good luck convincing people who transacted to undo that
16:06 < shinobiusmonk> plus all the miners block rewards, fee income, etc.
16:07 < shinobiusmonk> plus hell, any exchange transfers, etc.
16:07 -!- cguida [~Adium@c-75-70-131-96.hsd1.co.comcast.net] has quit [Ping timeout: 245 seconds]
16:07 < aj> queip: MTP doesn't have cons, unless you count "annoying luke-jr" as a con. it works fine for UASFs, though the whole point of "speedy trial" was to punt on the UASF approach until it's demonstrably needed; it's more predictable even in attack scenarios (a timewarp attack allows you to mine blocks quickly or keep the date in the past without boosting difficulty -- the former breaks height-based
16:07 < aj> activations as it doesn't give the economy time to upgrade their nodes; for mtp it only reduces the number of signalling periods)
16:07 -!- proofofkeags [~proofofke@c-75-70-131-96.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
16:08 < luke-jr> see, more lies
16:08 < luke-jr> and the point of ST was to be a compromise (which it no longer is)
16:08 < luke-jr> but I guess it's better you admit you violated the trust of everyone trying to compromise
16:12 < queip> MTP is now used (by Core) only for current TR-activation ST, that one thing is immune to any timewrap attacks, so in this case MTP is *not* inferior, or is attack still possible, luke-jr?
16:12 < aj> shinobiusmonk: man, hope collaorating with luke is more fun for you than it was for me
16:13 < shinobiusmonk> @aj: I don't take disagreements over things personally
16:14 < queip> aj: I think many of us need thicker skin. eg I have more problems and less understanding of the technical topic even at work often ;)
16:15 < copumpkin> this whole thick skin thing is misdirected. The community relies heavily on volunteers and if the answer to them getting demoralized is "grow thicker skin" you just shed good people (and arguably pick up people who gravitate to conflict)
16:16 < luke-jr> queip: it's not immune to timewarps. it just fails differently. and the difference is irrelevant in that scenario since the network in general is being attacked.
16:17 < luke-jr> queip: that's a case where regardless of any softforks in progress, you want to roll the chain back and fix it before the attack began.
16:19 < queip> luke-jr: allright, so... we can say that in THIS case, MTP is ok, while still remembering to possibly avoid MTP in other scenarios (e.g. in other parts of pushing for TR in case if ST would not work)?
16:19 < luke-jr> queip: it's not okay in this case either.
16:19 < queip> luke-jr: which problem remains here?
16:20 < luke-jr> queip: it's not strictly compatible with the LOT=True implementation, and as such not a compromise; it's the LOT=False camp forcing consensus problems for anyone who wants to use LOT=True
16:21 < luke-jr> queip: it's also impractical to put both options in the same codebase, so (eg) I cannot ship Knots supporting both BIP9/ST and BIP8 - I have to choose one or the other
16:21 < luke-jr> (or do the ST only and rely on shinobiusmonk to do a Knots-based Taproot Client)
16:22 < queip> luke-jr: but LOT=True vs LOT=False only matters when ST fails right?  then Core will have to roll out other attempt to activate TR, and in that case it is possible to choose bHeight instead MTP, this is on the table, right?
16:22 < luke-jr> queip: I'm talking about the situation today. Obviously when/if ST fails, these issues would go away.
16:22 < luke-jr> But by doing this, they are effectively trying to force LOT=False on everyone *today*
16:23 < queip> and when ST succeeds, both BC and BC-bTFC will activate TR and be in consensus?
16:23 < luke-jr> so long as miners don't screw with ST
16:23  * queip (sorry if not getting this fast enough)
16:23 < luke-jr> brb
16:25 < queip> faketoshi: is current BC-bTFC using MTP in such a way that doesn't preclude our compatibility with BC in both outcomes of BC's ST outcome?
16:31 < shinobiusmonk> @queip: if ST succeeds, both clients will activate in sync unless miners start playing timestamp games
16:33 -!- cguida1 [~Adium@c-75-70-131-96.hsd1.co.comcast.net] has quit [Quit: Leaving.]
16:34 < queip> so in both cases, we do not have a problem? so again what is the issue?
16:35 < shinobiusmonk> I see no legitimate issues here except communication to users so they understand the risks
16:35 < shinobiusmonk> I'm sure others disagree with me
16:36 < queip> shinobiusmonk: so the only risk is the scenario in which ST succeeds?  is the risk a thing that we can fix on our (BC-bTFC) software side?
16:38 < shinobiusmonk> no, if ST succeeds everything will work fun unless miners maliciously manipulate timestamps
16:38 < shinobiusmonk> the BIP8 client and Core with ST will both activate at the same time if ST succeeds in November
16:42 -!- duringo [ad004d0f@173.0.77.15] has joined ##taproot-activation
16:53 -!- dustinwinski [4a888a59@cpe-74-136-138-89.kya.res.rr.com] has joined ##taproot-activation
16:54 < dustinwinski> With Taproot, we will have a new address type called SegWit v1. This upgrade fixes a problem with Bech32. Can a wallet doing single sig  transactions that doesn't wan to do multisig stuff still use Segwit v1 instead of Segwit v0? Basically, is the new segwit v1 address type just for MAST use? Can I use it now as a simple, single sig user?
17:01 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
17:03 < aj> dustinwinski: yes, "simple, single sig user" is "key path spend" in taproot terms.
17:03 < dustinwinski> Thanks.
17:04 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds]
17:10 < dustinwinski> @aj Do you know how wallets will implement the change?
17:11 < dustinwinski> Will I have to manually send my funds to a v1 address and tell my wallet to just create v1 addresses from now on?
17:11 -!- belcher_ is now known as belcher
17:12 < aj> dustinwinski: i'd guess after it gets locked in, afaik there's only developer tools like btcdeb that deal with creating taproot txs
17:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
17:28 < luke-jr> dustinwinski: you shouldn't.. it's functionally the same as having both Segwit and non-Segwit funds in the same wallet
17:35 -!- proofofkeags_ [~proofofke@c-75-70-131-96.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds]
17:41 < dustinwinski> What if I wanted to just use Segwit v1?
17:49 < luke-jr> then you'd have to send your entire wallet to a new v1 address
17:49 < luke-jr> but I'm not sure there's a real reason to do this
17:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
17:55 < dustinwinski> luke-jr: Because it's newer :p ! But it fixes a malleability bug in bech32. Why would people play around with something that has a bug that could burn funds?
17:56 < dustinwinski> luke-jr: I would have to make a new wallet after my wallet software updates, correct?
18:04 < luke-jr> dustinwinski: not necessarily; but it depends on your existing wallet
18:05 < dustinwinski> luke-jr: Thanks
18:12 < faketoshi> robert_spigler: https://twitter.com/nvk/status/1384652704664915969?s=20
18:38 -!- dustinwinski [4a888a59@cpe-74-136-138-89.kya.res.rr.com] has quit [Quit: Connection closed]
18:54 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
18:54 -!- graeme1 [~graeme@gateway/tor-sasl/welkinatdusk] has left ##taproot-activation ["WeeChat 3.0"]
18:54 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
18:57 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 252 seconds]
19:07 -!- mips [~mips@gateway/tor-sasl/mips] has quit [Remote host closed the connection]
19:08 -!- mips [~mips@gateway/tor-sasl/mips] has joined ##taproot-activation
19:08 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has joined ##taproot-activation
19:17 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
19:18 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation
19:20 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
19:22 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
19:39 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
19:41 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
19:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
20:10 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
20:13 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
20:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
20:23 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
20:27 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
20:49 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
20:51 -!- jesseposner [~jesseposn@2601:645:200:162f:90c1:a4aa:8084:778b] has quit [Ping timeout: 258 seconds]
20:56 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
21:39 -!- RusAlex [~Chel@unaffiliated/rusalex] has quit [Ping timeout: 265 seconds]
22:05 -!- RusAlex [~Chel@unaffiliated/rusalex] has joined ##taproot-activation
22:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
22:30 -!- OP_NOP [OP_NOP@gateway/vpn/privateinternetaccess/opnop/x-41418994] has quit [Ping timeout: 240 seconds]
22:32 -!- mol [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
22:33 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
22:35 -!- grubles [~user@gateway/tor-sasl/grubles] has quit [Ping timeout: 240 seconds]
22:36 -!- grubles [~user@gateway/tor-sasl/grubles] has joined ##taproot-activation
22:49 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
22:53 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
23:12 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
23:14 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
23:14 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 245 seconds]
23:17 -!- jamesob [sid180710@gateway/web/irccloud.com/x-xevjkwlbwtvykusc] has quit [Ping timeout: 245 seconds]
23:17 -!- jamesob_ [sid180710@gateway/web/irccloud.com/x-olrrbpxquvlbjxay] has joined ##taproot-activation
23:17 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-qgrodqsqgsfrrrrm] has quit [Ping timeout: 245 seconds]
23:17 -!- bsm117532 [~bsm117532@unaffiliated/bsm117532] has quit [Ping timeout: 245 seconds]
23:17 -!- bsm1175321 [~bsm117532@unaffiliated/bsm117532] has joined ##taproot-activation
23:17 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection]
23:18 -!- Emcy [~Emcy@unaffiliated/emcy] has joined ##taproot-activation
23:19 -!- rodarmor [sid210835@gateway/web/irccloud.com/x-kheorctzcwqgctla] has joined ##taproot-activation
23:28 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined ##taproot-activation
--- Log closed Wed Apr 21 00:00:32 2021