--- Log opened Wed Feb 17 00:00:02 2021
--- Day changed Wed Feb 17 2021
00:00 -!- benthecarman [~benthecar@2600:1700:201:6e60:7e:8074:bcb9:dfe7] has quit [Ping timeout: 264 seconds]
00:07 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 256 seconds]
00:32 -!- commmon [~common@unaffiliated/common] has quit [Read error: Connection reset by peer]
01:21 < virtu> michaelfolkson: not that it matters, but I appear twice in the tally at the end of the wiki
01:21 < virtu> should be 19:25
01:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
01:51 -!- setpill [~setpill@unaffiliated/setpill] has joined ##taproot-activation
02:18 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
02:25 -!- tobi40 [b2efad2c@178.239.173.44] has joined ##taproot-activation
02:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
02:37 -!- hsjoberg [~hsjoberg@c-45c772d5.445-1-64736c11.bbcust.telenor.se] has joined ##taproot-activation
02:41 <@michaelfolkson> moneyball: I don't see the upsides of 2y personally. 1y is more than long enough for readiness. I don't see why if miners aren't ready after 1 year that they'll be in ready in 2
02:42 <@michaelfolkson> moneyball: The upside of true was even if miners delay because they don't like true that it definitely activates after a year. Miners could delay for multiple reasons though (hopefully they won't)
02:43 <@michaelfolkson> I agree with achow101 on further discussion being not productive
02:44 <@michaelfolkson> moneyball: It would be very petty of miners to delay entirely because after a year a soft fork they have pledged support for activates. It is possible I guess...
02:46 <@michaelfolkson> luke-jr: It wasn't a great meeting, I agree. But I've heard from enough individuals that are moderately or strongly opposed to lot=true to make my mind up personally
02:48 <@michaelfolkson> luke-jr: You are free to try other things but short of those individuals changing their mind I think it is over. At least personally I don't want to engage or organize any more lot discussions
02:51 -!- viaj3ro [5b23d159@p5b23d159.dip0.t-ipconnect.de] has quit [Ping timeout: 240 seconds]
02:56 <@michaelfolkson> It would be good to get stats from the first meeting presented in the same form as achow101 doc https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
02:57 <@michaelfolkson> lot wasn't discussed in depth but there appeared to me majority support for (false,1y) at that stage too
02:59 <@michaelfolkson> Rusty had "Majority consensus for lockinontimeout false, though Luke Dashjr strongly opposed."
02:59 <@michaelfolkson> virtu had "to me it seemed like 10:3 in favor of lot=false"
03:00 <@michaelfolkson> My hope was that we could get into depth on the T1-T6 F1-F7 arguments in the second meeting so people could come to a more informed judgement
03:01 <@michaelfolkson> But you can't do anymore than laying out those arguments in succinct summaries and organizing a meeting to discuss them
03:01 <@michaelfolkson> With two weeks to prepare
03:02 <@michaelfolkson> Plus mining pools expressed a preference for lot=false on taprootactivation.com and didn't appear to show for the meeting on lot
03:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
03:12 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
03:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
03:25 -!- setpill [~setpill@unaffiliated/setpill] has joined ##taproot-activation
03:27 -!- setpill [~setpill@unaffiliated/setpill] has quit [Client Quit]
03:30 -!- setpill [~setpill@unaffiliated/setpill] has joined ##taproot-activation
03:35 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
04:07 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
04:31 < waxwing> well to whatever extent we want to hear from mining pools on the topic, they have clearly made an effort via that website. not that surprising that they don't engage in this kind of forum, all things considered.
04:43 -!- duringo [ad004d0f@173.0.77.15] has joined ##taproot-activation
04:52 -!- setpill [~setpill@unaffiliated/setpill] has joined ##taproot-activation
04:52 -!- duringo [ad004d0f@173.0.77.15] has quit [Ping timeout: 240 seconds]
04:59 -!- tobi40 [b2efad2c@178.239.173.44] has quit [Ping timeout: 240 seconds]
05:01 <@michaelfolkson> waxwing: Agreed, that wasn't a criticism. That taprootactivation.com website was better than we could reasonably expect at the start of all this
05:06 -!- jonatack [~jon@37.171.131.157] has joined ##taproot-activation
05:10 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
05:42 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
06:59 -!- hsjoberg [~hsjoberg@c-45c772d5.445-1-64736c11.bbcust.telenor.se] has quit [Remote host closed the connection]
07:23 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
07:25 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
07:26 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
07:27 <@michaelfolkson> My personal view on where we stand after yesterday on LOT: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html
07:27 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 268 seconds]
07:27 <@michaelfolkson> Feel free to disagree and feel free to discuss whatever you wish on this channel. Personally I'll be focusing on the code review for next week's meeting
07:29 <@michaelfolkson> Tuesday February 23rd at 19:00 UTC for code review on Bitcoin Core PR #19573
07:30 -!- benthecarman [~benthecar@107-138-24-110.lightspeed.austtx.sbcglobal.net] has joined ##taproot-activation
07:41 -!- benthecarman [~benthecar@107-138-24-110.lightspeed.austtx.sbcglobal.net] has quit [Ping timeout: 246 seconds]
07:42 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
08:01 < nothingmuch> i suspect a lot of the LOT disagreements are implicitly related to two parameters that have already been decided
08:02 -!- common [~common@unaffiliated/common] has joined ##taproot-activation
08:02 < nothingmuch> namely that there was consensus about 1y because that value seemed acceptable assuming LOT=false or LOT=true for different people
08:03 < nothingmuch> e.g. bip8(1.5y, false) now with overlapping bip8(1y, true) in 6 months is kind of off the table because of 1y being assumed as a start point
08:04 < jonatack> michaelfolkson: thanks, excellent summary
08:05 < nothingmuch> not sure that's a productive direction to discuss, but most of what i read from the last few days' logs seemes to suggest that people generally agree on making MASF possible earlier rather than later, and generally also agree on LOT=true eventually if MASF fails, but most disagreement is how/when to commit to that
08:06 < nothingmuch> i.e. wait until it's clear that early MASF didn't happen, or preempt
08:18 < luke-jr> michaelfolkson: timeoutheight isn't for miners; it's for the economy as a whole
08:23 <@michaelfolkson> nothingmuch: Feel free to start from scratch again :) That was my effort
08:24 <@michaelfolkson> luke-jr: We've discussed that before. Miners are users and part of the economy. Their voices shouldn't dictate but they should be heard
08:24 < luke-jr> michaelfolkson: my point stands.
08:25 < luke-jr> the fact that miners *might* also be part of the economy does not change the fact that timeoutheight is for the economy
08:26 < luke-jr> it gives the economy time to upgrade ~100% so that no matter what miners do, they are prepared to enforce Taproot
08:27 < nothingmuch> michaelfolkson: yeah from scratch is obviously silly...
08:28 <@michaelfolkson> nothingmuch: There was overwhelming consensus for 1 year in that first meeting. It made sense to continue under the assumption of 1 year
08:28 < nothingmuch> but i think it still might be constructive to figure out what timeout LOT=false proponents might find acceptable for LOT=true and vice versa
08:28 < nothingmuch> yep, i read the logs =)
08:28 < nothingmuch> i don't think rehashing is worth it
08:29 < nothingmuch> but i do think disagreements about what is acceptable are dependent on that prior agreement
08:29 < nothingmuch> since the main qualitative difference appears to be whether or not there's a LOT=true contingency plan from the get go, or "let's wait and see about LOT=true"
08:31 < nothingmuch> put another way, bip8(x, false) sequentially followed by bip(x, true) is different from bip8(x, false) and with eventual bip8(x - y, true) before x expires
08:32 < nothingmuch> and x, y, and x-y all need to be sufficiently long to allow safe upgrades
08:37 -!- mol_ [~mol@unaffiliated/molly] has joined ##taproot-activation
08:37 -!- benthecarman [~benthecar@2600:1700:201:6e60:5bcd:8959:44a3:e182] has joined ##taproot-activation
08:40 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
08:42 < nothingmuch> FWIW even though I'd prefer LOT=true, and I'd prefer if everyone did, I think LOT=false is perfectly acceptable because if MASF doesn't happen quickly, concurrent LOT=true deployment is possible
08:48 -!- mdrollette [~mdrollett@cpe-70-123-125-237.tx.res.rr.com] has quit [Quit: bye]
08:52 -!- maybehuman [57bc9331@p57bc9331.dip0.t-ipconnect.de] has joined ##taproot-activation
08:52 -!- benthecarman [~benthecar@2600:1700:201:6e60:5bcd:8959:44a3:e182] has quit [Ping timeout: 264 seconds]
08:56 -!- manj-gnome [~manjaro-g@37.163.174.113] has joined ##taproot-activation
08:57 < maybehuman> one thing that just ocurred to me: lot=true is in a way a hardcoded UASF, so it would be more accurate to call it a developer activated softfork (DASF)
08:58 < nothingmuch> maybehuman: i don't think that's true because soft fork upgrades are minor releases to FLOSS software, users can opt in without mixing up other considerations
08:59 -!- iodize [~iodize@195.181.160.175.adsl.inet-telecom.org] has joined ##taproot-activation
08:59 -!- iodize [~iodize@195.181.160.175.adsl.inet-telecom.org] has left ##taproot-activation []
08:59 < maybehuman> nothingmuch in theory yes, but in practice most will update sooner or later. the Power of Defaults and all that
09:01 < nothingmuch> yeah, in this regard an even purer approach would be to ship e.g. v0.x.y-{masf,uasf} corresponding to LOT=false and LOT=true respectively
09:02 < nothingmuch> or other variations on this (e.g. no taproot at all vs. LOT=true)
09:02 < nothingmuch> that way users would be forced to make a choice, even those who may be consenting to the change without being fully informed about it would still have to decide
09:03 < nothingmuch> my counterpoint would be that if users just blindly upgrade without even reading release notes then they might just google "which is the right variant") and do what the first search result tells them
09:06 < maybehuman> I think forcing users to choose is just asking for trouble
09:08 < nothingmuch> well, they are choosing at some point, tacitly or explicitly
09:08 < nothingmuch> if they choose tacitly, either they are still exercising choice, but it might not be rational/well informed, or they are choosing to trust someone to decide for them
09:09 < nothingmuch> F7 as i understand is precisely about the moral hazard of making it easier to delegate that choice to developers
09:09 < luke-jr> maybehuman: except it's not developer, it's user
09:10 -!- manj-gnome [~manjaro-g@37.163.174.113] has quit [Quit: Leaving]
09:10 < maybehuman> luke-jr: I don't follow
09:12 < luke-jr> maybehuman: framing it as developer-activated is completely false, in other words
09:12 < maybehuman> nothingmuch: what I'm trying to say is that with lot=true in core, you don't know if users actively choose it or if they are just blindly following. If lot=true is run by some people on their own initiative, that's a much clearer signal and can be called without ambiguity user activated
09:13 < maybehuman> luke-jr: How so?
09:14 < luke-jr> maybehuman: just as miners must comply to rules, developers also must release code enforcing the rules. as users have already decided.
09:14 < maybehuman> luke-jr: but you can't really prove in any strict sense that users have decided
09:15 < luke-jr> sure you can. if users choose to use that software, that's proof
09:15 < nothingmuch> maybehuman: i mostly agree with that, and i think that even strengthens the deterrent of LOT=true if there really is a critical mass of users opting in. but isn't that an argument for forcing a choice?
09:15 < maybehuman> I must be missing something: Whether or not users run the software can only be known after it's released. the decision to merge or not is before release
09:16 < nothingmuch> sorry, forcing users to choose
09:17 < maybehuman> nothingmuch: Like I said, I think that would be asking for trouble. Just imagine the discussion here with 1000x the participants and probably less knowledge
09:17 <@michaelfolkson> Ideally users would decide everything. But (we assume) many are uninformed, hard to identify and hard to contact
09:18 <@michaelfolkson> The best we have so far seems to be IRC meetings and Twitter polls
09:19 < luke-jr> maybehuman: nobody is objecting, so
09:20 < nothingmuch> maybehuman: by forcing users to choose i mean having two downloads
09:20 < maybehuman> nothingmuch: but don't you think that will inevitably degrade into some holy war as to which version is the real true Bitcoin?
09:21 < luke-jr> having LOT=false at all runs that risk
09:21 < nothingmuch> the choice is still there, users upgrade or don't upgrade
09:21 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed]
09:21 < nothingmuch> personally i don't think two downloads is very productive because if users don't bother reading the release notes, then yes they are likely to be confused by such holy wars
09:22 < nothingmuch> but maybe it's still better because if you have a named variant at least there isn't an implied numerical order like with version numbers
09:23 < maybehuman> The not upgrading argument would be a lot stronger if the activation period would be shorter than a release cycle
09:23 < nothingmuch> and luke-jr's point is important here - is the choice between LOT=false and LOT=true, or no activation code at all and LOT=true? or all 3?
09:23 < nothingmuch> there's different risks based on the variants offered
09:23 < maybehuman> because if users signal no to taproot, they would have to wait almost until the end of the maintenance window before they can get new features and improvements again
09:24 < maybehuman> *signal by not upgrading
09:24 < nothingmuch> yep, i think that's the strongest argument for named variants... but it also increases maintenance burdens
09:25 < maybehuman> to me, that would be the worst possible outcome of this debate
09:25 <@michaelfolkson> I guess it is worth emphasizing that yesterday was discussing what should be proposed to Core. It sounds like luke-jr will be enabling a lot = true, false switch on Knots and roasbeef said yesterday he'd be setting lot=false on btcd
09:26 < maybehuman> yes, I'm only talking about core
09:29 < maybehuman> my preferred solution for core would be default false with the option to change to true by config. If that doesn't work then just go with true if you have to (and we all get to say "I told you so" when it comes back to haunt us). worst case for me would be forcing users to choose, because that will totally degenerate into flamewars over nothing
09:29 < luke-jr> michaelfolkson: proposal isn't for Core, it's for the community
09:30 < luke-jr> Core has no licit choice but to do what the community wants
09:30 <@michaelfolkson> Well in practice most alternative implementations have small teams
09:30 < luke-jr> it's not about implementations
09:30 <@michaelfolkson> You have to assess what the community wants when you make the decision on Knots
09:30 < luke-jr> it's about what people in the Bitcoin economy want to do
09:30 < luke-jr> yes
09:31 <@michaelfolkson> Which you assess. Whether that assessment is right or not we don't know
09:31 < maybehuman> will you have a default for lot in Knots?
09:31 <@michaelfolkson> roasbeef has assessed the community wants lot=false
09:31 <@michaelfolkson> (for btcd)
09:31 < luke-jr> maybehuman: dunno
09:31 < luke-jr> the people  here seem split
09:32 < luke-jr> the people on Twitter seem to overwhelmingly favour LOT=true
09:32 < luke-jr> but that's all just a fraction of the people relevant
09:32 < luke-jr> maybe it will prompt on upgrade or something
09:33 < luke-jr> Knots 0.21 added GUI configuration of assumevalid for a similar purpose
09:33 < luke-jr> I guess logically there are 4 options
09:35 < luke-jr> "Reject Taproot" (the 1815th block signalling during any period is invalid), "Reduce security to light wallet if Taproot activates", "Upgrade to Taproot if miners say so", and "Upgrade to Taproot"
09:38 < maybehuman> can you translate what these would mean technically?
09:38 < luke-jr> option 1 might simply dialog "Knots won't support this, sell your bitcoins lol"
09:38 <@michaelfolkson> ha
09:38 < luke-jr> but if implemented, Reject would split off any chain that activates Taproot by rejecting it
09:39 < luke-jr> "Reduce" would ignore Taproot entirely, as 0.21 is today
09:39 < luke-jr> "Upgrade if miners say so" is LOT=false
09:39 < luke-jr> "Upgrade" is LOT=true
09:39 < maybehuman> ok, got it
09:40 < maybehuman> it's slightly confusing because with true you'd also upgrade to taproot if miners say so before the flag day
09:40 < luke-jr> with true, you upgrade period
09:40 < luke-jr> which is what it says
09:41 < maybehuman> 3 could be "upgrade unless miners fail to coordinate"
09:42 < luke-jr> I was thinking perhaps "Go along with Taproot if miners upgrade"
09:42 < luke-jr> though even that needs qualifiers
09:43 < luke-jr> "upgrade unless miners fail to coordinate" is erroneous because minority miners running LOT=true is still coordination
09:44 < maybehuman> "fail to reach the threshold" then
09:44 < luke-jr> it doesn't fail with LOT=true
09:44 < luke-jr> it *does* reach the threshold guaranteed ;)
09:45 < maybehuman> that also applies to all your alternative wordings, no?
09:46 < luke-jr> dunno, point is to have something normies can understand
09:46 -!- maybehuman [57bc9331@p57bc9331.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
09:47 < luke-jr> hard to do that with options that really make no sense ;P
09:48 -!- maybehuman [57bc9331@p57bc9331.dip0.t-ipconnect.de] has joined ##taproot-activation
09:49 < maybehuman> that is why I think making them choose is a bad idea to begin with
09:49 < maybehuman> How to explain this in lay peoples' terms..
09:49 < nothingmuch> can't make an omlette without breaking eggs
09:50 < nothingmuch> if the goal is to ensure a meaningful change to a thing that is hard to change happens, there is risk which must be accepted by interested parties
09:50 -!- molz_ [~mol@unaffiliated/molly] has joined ##taproot-activation
09:50 -!- mol_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
09:52 -!- maybehuman [57bc9331@p57bc9331.dip0.t-ipconnect.de] has quit [Client Quit]
10:01 -!- duringo [ad004d07@173.0.77.7] has joined ##taproot-activation
10:05 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
10:07 < maybehuman> luke-jr: also, I find it strange you would implement features that make no sense in your opinion. If you're certain there is only one correct choice, why not just implement that? Users are always free to use another software or fork if they don't agree
10:08 <@michaelfolkson> maybehuman: If the community wants something that Luke thinks makes no sense I think his perspective is to give it to them
10:08 < luke-jr> michaelfolkson: indeed
10:08 <@michaelfolkson> It really depends on your perspective with that. Some would want to be paternalistic and not give it to them
10:08 < luke-jr> although maybehuman has a point too - Knots is small enough that "just don't use Knots" isn't a terrible option
10:09 < luke-jr> or even "set a bitcoin.conf  option"
10:09 <@michaelfolkson> I guess it depends on who your users are. If they have no clue what they are doing you might want to try to protect them from themselves
10:10 <@michaelfolkson> I'd guess Knots users would know what they are doing in a way Core users may not
10:10 < maybehuman> but there's got to be a limit to how far you would bend if the community wants it, right? I mean if the community wants a dobuling of the supply, surely you wouldn't implement that, right?
10:12 <@michaelfolkson> I think Luke would say that they were then requesting something that wasn't Bitcoin
10:13 <@michaelfolkson> But you can get philosophical. What Luke thinks is or isn't Bitcoin may not be shared by Knots users or the broader community. It gets complicated
10:13 < maybehuman> what I'm trying to get at: Not getting your way with lot does not seem to be a reason to rage-quit
10:13 < maybehuman> so in the end no biggie
10:14 < maybehuman> it would just be a case of "the community is wrong and I am right, but whatever"
10:15 <@michaelfolkson> I don't think he is sure for certain that the community wants the opposite to him (and is "wrong")
10:16 < maybehuman> well if he was this discussion would not happen
10:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined ##taproot-activation
10:23 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
10:28 < maybehuman> Re-reading what was posted above, what really doesn't work for me is this assumption that core is somehow bound to do as "the community" says. Is that the consensus view here?
10:28 < maybehuman> I can't imagine that's in the original whitepaper or in any formalized charter or something
10:29 < maybehuman> and it's not like you can rid yourself of responsibilty for your own actions by saying "xyz told me to do it", especially if xyz is just some abstract entity
10:36 <@michaelfolkson> maybehuman: You'd have to ask Core contributors individually on that. There is no official Core view. I think many Core contributors would NACK something that they thought would reduce the security of Bitcoin or harm it in some way even if the entire community wanted it
10:37 < maybehuman> ok, so it's basically just Luke's opinion then?
10:38 <@michaelfolkson> It appears (from what Luke has said on this channel) that he thinks if the community wants LOT=true Core should implement it regardless of Core contributor/developer views. (He can correct me if I'm misrepresenting his view)
10:39 < maybehuman> ok, I just wanted to clarify since nobody seemed to react to that
10:40 <@michaelfolkson> However that F7 argument is one on setting precedent for future soft forks and potentially the long term security of Bitcoin. I think some Core contributors would therefore think they can NACK LOT=true even if the entire community wanted it
10:40 < maybehuman> yes, I think so, too
10:41 <@michaelfolkson> I have not been sure through this process that even if we proposed LOT=true to Core whether they would implement it or not
10:41 < maybehuman> but still we can't bring ourselves to just play it safe and propose false then?
10:41 <@michaelfolkson> However my view was that if it was what the community wanted we should propose it to Core and let them NACK it
10:42 < maybehuman> at this point, either proposal would be better than none at all or "force users to set it themselves"
10:43 <@michaelfolkson> Where I've landed personally is that we have to propose LOT=false to Core to implement https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018425.html
10:43 <@michaelfolkson> Others may (and probably will) disagree
10:46 < maybehuman> I guess the best would be for someone to just open a pr then (the other party is always free to open a competing one, and probably will)
10:46 < luke-jr> maybehuman: false is not safe
10:47 < luke-jr> true may not be perfect, but it is certainly much safer than false
10:48 < maybehuman> luke-jr: Well, like I said, maybe just open a PR then and put that in the rationale
10:48 < maybehuman> if false is not safe, then the opinion of the community is a bit irrelevant
10:51 < luke-jr> [18:28:23] <maybehuman> Re-reading what was posted above, what really doesn't work for me is this assumption that core is somehow bound to do as "the community" says. Is that the consensus view here? <-- think of it with any other rule; would you consider it appropriate for devs to remove the block size limit without community backing?
10:52 < luke-jr> [18:48:53] <maybehuman> if false is not safe, then the opinion of the community is a bit irrelevant <-- it is never irrelevant, since the community is the decision-makers
10:53 <@michaelfolkson> You don't get the community to assess literal security vulnerabilities though right? You just fix them.
10:53 < maybehuman> also, I'm a bit unclear on what exact rule is removed by false?
10:55 <@michaelfolkson> I think he just means adding or removing a rule
10:55 < maybehuman> but adding is different from removing
10:55 < maybehuman> imo at least
10:55 <@michaelfolkson> LOT is a parameter and needs to be set to either true or false
10:55 <@michaelfolkson> Well these Taproot soft fork rules are *adding* rules
10:56 <@michaelfolkson> Removing the block size limit would be removing a rule
10:57 <@michaelfolkson> So yeah I guess the difference between a soft fork and hard fork
10:57 < maybehuman> yes, exactly. One is something that is part of the consensus that everybody abides to. The other is just some proposal at this stage
11:15 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has joined ##taproot-activation
11:32 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
11:35 < stortz> what would be the default for BIP8, LOT=false or LOT=true
11:48 < stortz> if there is one
11:49 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined ##taproot-activation
11:52 -!- andrewtoth [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 268 seconds]
11:54 -!- criley [49e07d3a@c-73-224-125-58.hsd1.fl.comcast.net] has quit [Quit: Ping timeout (120 seconds)]
11:57 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection]
11:57 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
12:08 < luke-jr> michaelfolkson: with some things, the community already has an expectation :p
12:09 < luke-jr> michaelfolkson: failure to add a rule, is the same as removing a rule
12:09 < luke-jr> sturles: IMO true
12:10 < luke-jr> stortz: BIP8 was originally true-only, and "false" adds a new behaviour on top of the expected one
12:22 -!- molz_ [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
12:22 <@michaelfolkson> stortz: You mean the default set in say a Core software release for Taproot activation or the default for (future) soft forks generally?
12:23 <@michaelfolkson> stortz: The answer to the first question is effectively what we've been discussing over the last few weeks https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
12:23 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 246 seconds]
12:25 <@michaelfolkson> stortz: The answer to the second question is I don't think there is one. The parameter has to be set to true or false. Maybe what it is set to for Taproot will end up being somewhat a precedent, I don't know
12:26 < stortz> thanks folkson
12:26 <@michaelfolkson> stortz: No problem
12:27 -!- queip [~queip@unaffiliated/rezurus] has joined ##taproot-activation
12:29 < stortz> the fact that it was originally true-only makes me want to vote for LOT=ture
12:29 < stortz> true*
12:29 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: setpill]
12:29 < stortz> probably a power play as well
12:31 < luke-jr> stortz: I do regret making it configurable :P
12:33 < stortz> it's a pain now, but a precedent where there was a discussion on it makes for a better one IMHO
12:34 < stortz> too bad people are busy commemorating the usd value and not discussing this
12:50 -!- jonatack_ [~jon@37.173.29.80] has joined ##taproot-activation
12:53 -!- jonatack [~jon@37.171.131.157] has quit [Ping timeout: 260 seconds]
12:56 -!- bluudz [~bluudz@103.108.94.40] has joined ##taproot-activation
12:58 -!- jonatack_ [~jon@37.173.29.80] has quit [Read error: Connection reset by peer]
12:59 < luke-jr> per meeting conclusions, I have opened https://github.com/bitcoin/bips/pull/1069
13:01 -!- mol [~mol@unaffiliated/molly] has joined ##taproot-activation
13:09 < luke-jr> Also opened https://github.com/bitcoin/bips/pull/1070 which clarifies language but makes no technical changes
13:14 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed]
13:25 -!- duringo [ad004d07@173.0.77.7] has quit [Quit: Connection closed]
13:26 -!- stortz [bb3fa187@187.63.161.135] has joined ##taproot-activation
13:52 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
13:54 < maybehuman> 12:09 < luke-jr> michaelfolkson: failure to add a rule, is the same as removing a rule <-- So a failed soft fork is the same as a hard fork?
14:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
14:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
14:14 < luke-jr> maybehuman: how do you figure?
14:17 < maybehuman> I mean, that's literally how soft and had forks are defined in https://en.bitcoin.it/wiki/
14:18 < belcher> maybe you're confusing chain split with (hard|soft) fork
14:21 < maybehuman> luke's original example was removing the block size limit, that would be a hard fork, no?
14:21 < belcher> yes you're right, excuse me
14:23 < maybehuman> stortz: Out of curiosity (and boredom :-)) I looked for the oldest bip8 version I could find online: https://gist.github.com/shaolinfry/0f7d1fd22743bb966da0c0b1682ea2ab/b7c66bd6e06b35903427528407987882daa46fa7
14:24 < stortz> maybehuman nice
14:24 < maybehuman> there, it's called "an extension to BIP9" so you could argue it was meant as optional (as in it doesn't say "supersedes bip9")
14:30 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
14:32 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has joined ##taproot-activation
14:33 < maybehuman> also, here's a description ba shaolinfry: https://www.reddit.com/r/Bitcoin/comments/5zsk45/i_am_shaolinfry_author_of_the_recent_user/
14:34 < stortz> which now is BIP8
14:37 -!- maybehuman [4ff5ee83@p4ff5ee83.dip0.t-ipconnect.de] has quit [Quit: Connection closed]
16:31 -!- emzy [~quassel@unaffiliated/emzy] has quit [Quit: No Ping reply in 180 seconds.]
16:32 -!- emzy [~quassel@2a01:4f8:192:628a::83] has joined ##taproot-activation
16:41 -!- emzy [~quassel@2a01:4f8:192:628a::83] has quit [Changing host]
16:41 -!- emzy [~quassel@unaffiliated/emzy] has joined ##taproot-activation
16:57 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined ##taproot-activation
16:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
17:53 -!- belcher_ [~belcher@unaffiliated/belcher] has joined ##taproot-activation
17:56 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
18:59 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 240 seconds]
18:59 -!- CubicEarth_ [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined ##taproot-activation
19:14 -!- stortz [bb3fa187@187.63.161.135] has quit [Quit: Connection closed]
19:41 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 264 seconds]
19:53 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined ##taproot-activation
20:01 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Quit: ZNC - http://znc.sourceforge.net]
20:02 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined ##taproot-activation
20:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined ##taproot-activation
21:21 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
21:21 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
22:28 -!- ghost43_ [~daer@gateway/tor-sasl/daer] has joined ##taproot-activation
22:32 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
22:46 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 265 seconds]
23:33 -!- jonatack_ [~jon@37.167.103.144] has joined ##taproot-activation
--- Log closed Thu Feb 18 00:00:36 2021